| A | B | C | D | E | F | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W | X | Y | Z | |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
1 | AEGIS LINK — TEAM BACKLOG · 80 Items · 4 Sprints · 8 Weeks · Plain HTML/CSS/JS · Team of 5 | |||||||||||||||||||||||||
2 | Sprint | ID | Category | Priority | Title | User Story / Task | Acceptance Criteria | Status | Notes / Comments | |||||||||||||||||
3 | Sprint 1 · Design, Infrastructure & Core Encrypted Chat · Weeks 1–2 · 24 items | |||||||||||||||||||||||||
4 | Sprint 1 | DES-001 | Design | Must | Wireframes — All Screens | As a team, we need wireframes for every screen so that developers have a clear blueprint before building. | Wireframes cover Home, Setup, Chat Room, Group Chat, Contacts, Settings. Reviewed and approved by team. | Done | All 6 screens wireframed and team-approved. Foundation for all page builds. | |||||||||||||||||
5 | Sprint 1 | DES-002 | Design | Must | Design System (Colours, Typography, Spacing) | As a developer, I want a shared design system so that the UI is consistent across all pages. | Colour palette, font sizes, spacing scale, and icon set documented. Available to all team members. | Done | CSS variables file created. Shared with all devs. Ensures visual consistency. | |||||||||||||||||
6 | Sprint 1 | DES-003 | Design | Must | Shared Component Designs (Buttons, Inputs, Modals) | As a developer, I want designed reusable components so that I can build them once and use them everywhere. | Button states, text inputs, modal overlay, toast notification, and avatar all designed and agreed. | Done | Reusable component spec agreed. Prevents duplication across pages. | |||||||||||||||||
7 | Sprint 1 | PAGE-001 | Page | Must | Build: Home / Landing Page | As a user, I want a clear home page so that I understand what the app does and how to get started. | Page renders correctly. Includes app name, brief description, 'Start Chat' and 'View Contacts' CTAs. Responsive on mobile and desktop. | Done | Landing page complete and responsive. Core entry point for all users. | |||||||||||||||||
8 | Sprint 1 | PAGE-002 | Page | Must | Build: Setup / Key Exchange Page | As a user, I want a dedicated setup page so that I can generate or import keys and initiate a secure session. | Page includes: generate key button, paste/import partner key field, session ID display, and Connect button. Blocked until keys exchanged. Responsive. | Done | Setup page complete. Route guard enforced — chat inaccessible until keys exchanged. | |||||||||||||||||
9 | Sprint 1 | PAGE-003 | Page | Must | Build: Chat Room Page | As a user, I want a chat room page so that I can send and read messages in a clear interface. | Page includes: message list, message input, send button, self-destruct timer indicator, and edit/delete controls. Scrollable history. Responsive. | Done | Chat room page complete. Full P2P encrypted chat UI in place. | |||||||||||||||||
10 | Sprint 1 | FE-001 | Feature | Must | CSS Framework & Global Stylesheet | As a developer, I want a global stylesheet and CSS variables set up so that all pages share a consistent base style. | CSS variables for colours, fonts, and spacing defined. Reset/base styles applied. Shared across all pages. | Done | Partially implemented. CSS variables defined but not applied uniformly across all pages yet. | |||||||||||||||||
11 | Sprint 1 | FE-002 | Feature | Must | Client-Side Routing Setup | As a developer, I want client-side routing so that users can navigate between pages without full page reloads. | Navigation between Home, Setup, Chat, Contacts, and Settings works. Active route highlighted. Back/forward browser buttons work. | Planned | Hash-based routing planned. Implementation blocked by FE-001 completion. | |||||||||||||||||
12 | Sprint 1 | FE-003 | Feature | Must | Reusable HTML/CSS/JS Component Library | As a developer, I want reusable component functions so that I do not duplicate code across pages. | Components built: PrimaryButton, TextInput, Modal, Toast notification, Avatar. Used consistently across all pages. | Started | Core components started. PrimaryButton and TextInput done. Modal and Toast pending. | |||||||||||||||||
13 | Sprint 1 | BE-001 | Backend | Must | Signalling Server Setup | As a developer, I want an ephemeral signalling server so that clients can establish WebSocket connections. | Server starts, accepts WebSocket connections, handles connect/disconnect events. No message content stored. | Done | Node.js/ws server live. Accepts connections and handles events. Zero storage confirmed. | |||||||||||||||||
14 | Sprint 1 | BE-002 | Backend | Must | Room / Session Management | As a developer, I want the server to manage session rooms so that only the right users are connected. | Sessions created/joined via unique ID. Third connection rejected. Session destroyed on disconnect. | Not Started | Depended on BE-001. Room logic not yet implemented. Blocks AL-004 private sessions. | |||||||||||||||||
15 | Sprint 1 | BE-003 | Backend | Must | Message Relay (No Storage) | As a developer, I want the server to relay encrypted payloads only so that no message content is stored. | Server forwards messages without logging or storing content. Confirmed via server inspection. | Done | Relay-only mode confirmed. Server inspection shows zero message content stored. | |||||||||||||||||
16 | Sprint 1 | AL-001 | Feature | Must | Solution Setup | As a developer, I want the application structure ready so that I can start building quickly. | App builds, client opens, setup guide included. | Done | Project scaffold complete. Build process working. Setup guide in repo. | |||||||||||||||||
17 | Sprint 1 | AL-002 | Feature | Must | Peer-to-Peer Messaging | As a user, I want to send and receive messages so that I can communicate securely. | Messages sent/received correctly in real-time. | Done | Real-time P2P messaging confirmed via WebSocket relay. | |||||||||||||||||
18 | Sprint 1 | AL-004 | Feature | Must | Private Chat Session | As a user, I want each chat to be a separate session so that only my partner can read messages. | Session create/join works, isolated sessions, session ID shown. | Done | Session isolation verified. Cross-session message bleed confirmed absent. | |||||||||||||||||
19 | Sprint 1 | AL-005 | Feature | Must | Secure Message Format | As a developer, I want consistent message structure so that encryption works reliably. | Messages include session ID, encrypted payload, version. | Done | Message envelope schema defined and in use. Version field present. | |||||||||||||||||
20 | Sprint 1 | AL-006 | Feature | Must | Key Exchange (ECDH) | As a user, I want to exchange keys securely so that only my partner can read messages. | Keys generated locally, shared secret derived, never sent to server. | Done | ECDH via Web Crypto API. Private key confirmed never transmitted. | |||||||||||||||||
21 | Sprint 1 | AL-007 | Feature | Must | End-to-End Encryption (AES-256-GCM) | As a user, I want all messages encrypted so that no one else can read them. | Messages encrypted before sending, decrypted only by recipient. | Done | AES-256-GCM encryption verified end-to-end. Server sees only ciphertext. | |||||||||||||||||
22 | Sprint 1 | AL-013 | Feature | Must | Cryptographically Strong Session IDs | As a user, I want session IDs to be unguessable so that no one can join without permission. | IDs random, collision-resistant, URL-safe. | Done | UUID v4 via crypto.randomUUID(). Collision resistance confirmed. | |||||||||||||||||
23 | Sprint 1 | AL-014 | Feature | Must | Two-Peer Session Enforcement | As a user, I want only two people in a session so that third-party access is blocked. | Third join rejected, users notified. | Done | Merged into BE-002. Third connection rejection logic in signalling server. | |||||||||||||||||
24 | Sprint 1 | AL-015 | Feature | Must | Ephemeral Session State | As a user, I want messages to exist only in memory so that no data persists after session ends. | Session state cleared on disconnect, no database writes. | Done | All messages in JS memory only. Confirmed no localStorage/DB writes for messages. | |||||||||||||||||
25 | Sprint 1 | AL-016 | Feature | Must | Zero Logging | As a user, I want no server logs so that my session cannot be traced. | Logging disabled for all ephemeral events. | Done | Server logs connect/disconnect only. Message events excluded. Verified in server output. | |||||||||||||||||
26 | Sprint 1 | TST-001 | Test | Must | Unit Tests — Encryption Functions | As a developer, I want unit tests for ECDH and AES-GCM so that crypto logic is verified correct. | Tests cover key generation, shared secret derivation, encrypt/decrypt round-trip. All pass. | Started | Partial unit tests written for ECDH. AES-GCM round-trip test pending. | |||||||||||||||||
27 | Sprint 1 | TST-002 | Test | Must | Integration Test — P2P Message Flow | As a developer, I want an integration test for the full message flow so that send-to-receive is verified. | Client A sends encrypted message, client B decrypts correctly. No server copy confirmed. | Done | Integration test passing. Full send/receive encrypted flow verified. | |||||||||||||||||
28 | Sprint 2 · Security Hardening, Contacts Page & Core Features · Weeks 3–4 · 21 items | |||||||||||||||||||||||||
29 | Sprint 2 | DES-004 | Design | Must | Security & Warning UI Patterns | As a designer, I want consistent patterns for warnings and confirmations so that users understand security prompts. | Modal, inline warning, and toast components designed. Used consistently across all security screens. | Planned | Design spec pending. Required before implementing SAS fingerprint and key lifecycle UIs. | |||||||||||||||||
30 | Sprint 2 | DES-005 | Design | Must | Contacts Page Design | As a designer, I want a contacts page layout so that developers can implement add/delete contact features. | Contacts list, add flow, delete confirmation, and nuke option all wireframed and approved. | Done | Full contacts page wireframe approved. Covers list, add, delete, and nuke flows. | |||||||||||||||||
31 | Sprint 2 | PAGE-004 | Page | Must | Build: Contacts Page | As a user, I want a contacts page so that I can view, add, and remove saved contacts. | Page renders contact list from localStorage. Includes add contact button/form, delete confirmation, and empty state. Responsive. | Done | Contacts page live. localStorage-backed. Add/delete/empty state all functional. | |||||||||||||||||
32 | Sprint 2 | BE-004 | Backend | Must | Group Session Room Logic | As a developer, I want the server to support multi-user rooms so that group messaging is possible. | Room supports 3+ users. Join/leave handled. Ephemeral keys distributed correctly. | Done | Multi-user room logic implemented. Tested with 3 simultaneous connections. | |||||||||||||||||
33 | Sprint 2 | BE-005 | Backend | Must | Server Hardening & Security Headers | As a developer, I want security headers configured on the server so that the app is protected from common attacks. | CSP, X-Frame-Options, HSTS all set. Verified via browser devtools. | Done | Helmet.js security headers applied. CSP, X-Frame-Options, HSTS confirmed via devtools. | |||||||||||||||||
34 | Sprint 2 | AL-008 | Feature | Must | Setup Screen — Gate Logic | As a user, I want to complete security setup before chatting so that my session is protected. | Chat page blocked until keys exchanged. Clear setup flow enforced. | Done | Route guard active. Chat page inaccessible until shared secret derived. | |||||||||||||||||
35 | Sprint 2 | AL-010 | Feature | Must | Import Partner Key | As a user, I want to scan or paste a partner's key so that I can connect securely. | Key accepted if valid, invalid rejected, shared secret derived. | Done | Paste-based key import working. Validation in place. Invalid format shows helpful error. | |||||||||||||||||
36 | Sprint 2 | AL-012 | Feature | Must | SAS Fingerprint Confirmation | As a user, I want to confirm a short code so that I can detect MITM attacks. | Both devices compute same code, must confirm match before chatting. | Not Started | Security-critical MITM prevention. Deferred in PoC but required for full product release. | |||||||||||||||||
37 | Sprint 2 | AL-017 | Feature | Must | Key Lifecycle & Zeroise | As a user, I want keys deleted after session so that memory exposure is minimised. | Keys cleared after inactivity, tab close triggers cleanup. | Done | Key zeroise on tab close and session end implemented. Memory exposure minimised. | |||||||||||||||||
38 | Sprint 2 | AL-018 | Feature | Must | CSP & Security Headers (Client) | As a user, I want headers to reduce attack risks so that my session is safer. | CSP headers set, inline eval restricted. | Done | Client-side CSP headers set. Inline eval blocked. Verified in browser Security tab. | |||||||||||||||||
39 | Sprint 2 | AL-027 | Feature | Must | Add Contact | As a user, I want to save contacts so that I can reconnect easily. | Contacts saved to localStorage only. Visible on Contacts page. | Done | Add contact functionality complete. Persisted to localStorage only. | |||||||||||||||||
40 | Sprint 2 | AL-028 | Feature | Must | Delete Contact | As a user, I want to remove contacts so that I can manage my list. | Contact removed from localStorage. Page updates immediately. | Done | Delete contact with confirmation modal. localStorage updated. Page reactive. | |||||||||||||||||
41 | Sprint 2 | AL-029 | Feature | Must | Self-Destruct Messages | As a user, I want messages to auto-delete so that sensitive data does not remain. | Timer removes message from UI and memory. No server copy. | Done | Fixed 30s timer planned for PoC. Adjustable timer deferred to full product. | |||||||||||||||||
42 | Sprint 2 | AL-023 | Feature | Must | Edit Messages | As a user, I want to edit messages so that I can correct mistakes. | Edits reflected to both parties in real time. | Done | Inline edit UI not yet started. Required for Sprint 3 PoC delivery. | |||||||||||||||||
43 | Sprint 2 | AL-024 | Feature | Must | Delete Individual Messages | As a user, I want to delete messages so that I can remove unwanted content. | Messages removed from view and memory. No server copy. | Done | Delete button not yet implemented. Both-sides removal required. | |||||||||||||||||
44 | Sprint 2 | AL-039 | Feature | Must | Auto-Correct / Spell Check | As a user, I want spelling suggestions so that my messages are clearer. | Misspellings highlighted via browser spellcheck API. Suggestions offered. | Not Started | Browser-native spellcheck attribute — trivial to add. Pending. | |||||||||||||||||
45 | Sprint 2 | AL-043 | Feature | Must | Low Latency Messaging | As a user, I want messages delivered fast so that conversation feels natural. | Messages appear within acceptable time under normal network conditions. | Done | Sub-1s delivery confirmed on local network. No artificial delays. | |||||||||||||||||
46 | Sprint 2 | AL-046 | Feature | Must | Error-Tolerant Key Entry | As a user, I want key entry to handle small mistakes so that I can connect without frustration. | Minor formatting errors handled, guidance shown. | Done | Validation with helpful inline error messages in place on Setup page. | |||||||||||||||||
47 | Sprint 2 | TST-003 | Test | Must | Unit Tests — SAS & Key Lifecycle | As a developer, I want tests for SAS fingerprint and key zeroise so that security-critical paths are verified. | SAS match/mismatch tested. Key cleared from memory on session end confirmed. | Done | Blocked by AL-012 (SAS) not started. Key zeroise test can proceed independently. | |||||||||||||||||
48 | Sprint 2 | TST-004 | Test | Must | Security Header Tests | As a developer, I want automated checks for security headers so that misconfiguration is caught early. | Tests verify CSP, HSTS, X-Frame-Options present on all responses. | Not Started | Automated header checks not yet written. Can be done with supertest/fetch assertions. | |||||||||||||||||
49 | Sprint 2 | TST-005 | Test | Must | Unit Tests — Self-Destruct Timer | As a developer, I want tests for the self-destruct timer so that messages are provably wiped on schedule. | Timer fires at correct interval. Message irrecoverable after expiry. | Planned | Blocked by AL-029 (self-destruct) not started. Must implement before testing. | |||||||||||||||||
50 | Sprint 3 · Group Chat, Settings Page & Should-Have Features · Weeks 5–6 · 22 items | |||||||||||||||||||||||||
51 | Sprint 3 | DES-006 | Design | Must | Group Chat Page Design | As a designer, I want a group chat layout so that developers can implement multi-user messaging correctly. | Group creation flow, member list, and group chat UI all wireframed. Approved by team. | Planned | Group chat UI wireframe in progress. Must be approved before PAGE-005 build begins. | |||||||||||||||||
52 | Sprint 3 | DES-007 | Design | Should | Settings Page Design | As a designer, I want a settings page design so that developers can implement all user preferences in one place. | Settings layout covers: mode switch, storage toggle, dark/light mode, font size. Wireframed and approved. | Done | Settings wireframe approved. Covers all preference controls. | |||||||||||||||||
53 | Sprint 3 | PAGE-005 | Page | Must | Build: Group Chat Page | As a user, I want a group chat page so that I can message multiple people in a shared secure room. | Page renders shared message list, member list/count, group name, message input, send button. Encrypted messages displayed. Responsive. | Planned | Blocked by DES-006 approval. Build ready to start once wireframe approved. | |||||||||||||||||
54 | Sprint 3 | PAGE-006 | Page | Should | Build: Settings Page | As a user, I want a settings page so that I can manage all preferences in one place. | Page includes: mode switch, storage consent toggle, dark/light mode toggle, font size control, generate new keys button. Preferences persist in localStorage. Responsive. | Started | Basic settings page scaffold in place. Mode switch and key generation buttons functional. Toggles pending. | |||||||||||||||||
55 | Sprint 3 | BE-006 | Backend | Must | Connection Drop & Reconnect Handling | As a developer, I want the server to handle dropped connections gracefully so that sessions close cleanly. | Disconnect detected within 5s. Partner notified. Session state cleared. Reconnect handled without error. | Not Started | Graceful disconnect logic not yet implemented. Partner notification on drop missing. | |||||||||||||||||
56 | Sprint 3 | BE-007 | Backend | Must | Encrypted Image Payload Relay | As a developer, I want the server to relay encrypted image payloads so that image messaging works end-to-end. | Base64 encoded encrypted image relayed correctly. No image stored server-side. | Not Started | Image relay depends on AL-025 (image messaging). Both not started. | |||||||||||||||||
57 | Sprint 3 | AL-025 | Feature | Must | Image Messaging | As a user, I want to send images securely so that I can share visual content safely. | Images encrypted via AES-GCM, sent inline in chat. Only recipient can view. | Not Started | Deferred in PoC (text-only sufficient). Required for full product. | |||||||||||||||||
58 | Sprint 3 | AL-026 | Feature | Must | Group Messaging | As a user, I want to chat with multiple people so that I can communicate in groups. | Group created, all members receive messages securely. | Planned | Group room logic (BE-004) done. Frontend group messaging UI pending DES-006. | |||||||||||||||||
59 | Sprint 3 | AL-044 | Feature | Must | Group Scalability | As a user, I want large groups to perform well so that communication remains smooth. | Multi-user group tested with no noticeable slowdown or key distribution failure. | Not Started | Post-PoC testing goal. Basic group works; scale testing deferred. | |||||||||||||||||
60 | Sprint 3 | AL-045 | Feature | Must | Intuitive UI Polish | As a new user, I want the app easy to understand so that I can use it without technical knowledge. | New user can start a secure chat without external instructions. Guided prompts and clear icons throughout. | Done | Guided prompts and iconography applied. New-user walkthrough confirmed working. | |||||||||||||||||
61 | Sprint 3 | AL-021 | Feature | Should | Mode Switch (Ephemeral / Audit) | As a user, I want to switch modes so that I can control data handling. | Mode toggle visible on Settings page. Behaviour changes accordingly. | Not Started | Single ephemeral mode sufficient for PoC. Full mode switch deferred to full product. | |||||||||||||||||
62 | Sprint 3 | AL-022 | Feature | Should | Optional On-Device Storage | As a user, I want to optionally store messages on my device so that I can keep a local record. | Only stores if both parties consent. Uses localStorage/IndexedDB. No server storage. | Not Started | Deferred. Ephemeral-only mode sufficient for PoC. | |||||||||||||||||
63 | Sprint 3 | AL-030 | Feature | Should | Adjustable Self-Destruct Timer | As a user, I want to set message duration so that I control how long messages are visible. | Timer dropdown available in chat. Messages removed after selected duration. | Done | Fixed 30s timer used in PoC. Adjustable timer is post-PoC enhancement. | |||||||||||||||||
64 | Sprint 3 | AL-031 | Feature | Should | Generate New Encryption Keys | As a user, I want to generate new keys so that I can replace potentially compromised ones. | New keypair generated locally via Web Crypto API. Old keys zeroised. | Done | Key regeneration button on Settings page functional. Old keys cleared on trigger. | |||||||||||||||||
65 | Sprint 3 | AL-032 | Feature | Should | Automatic Key Detection | As a user, I want the app to detect valid keys automatically so that connecting is easier. | Pasted key format validated client-side. User prompted to confirm before connecting. | Done | Paste flow is sufficient for PoC. Auto-detection is a polish enhancement. | |||||||||||||||||
66 | Sprint 3 | AL-033 | Feature | Should | Consent Warning for Local Storage | As a user, I want a warning before storing chat locally so that I understand data is being kept. | Modal warning shown. User must confirm before any local storage write occurs. | Done | Consent modal shown before any localStorage write. GDPR-aligned. | |||||||||||||||||
67 | Sprint 3 | AL-040 | Feature | Could | Dark Mode | As a user, I want a dark theme so that I can use the app comfortably at night. | Dark theme toggled from Settings page. CSS variables swap correctly. Preference saved in localStorage. | Done | Dark mode implemented via CSS variable swap. Preference persisted in localStorage. | |||||||||||||||||
68 | Sprint 3 | AL-041 | Feature | Could | Light Mode | As a user, I want a light theme so that I can choose my appearance preference. | Light theme selectable alongside dark mode. | Not Started | Light theme CSS variables not yet added. Trivial once dark mode base is confirmed. | |||||||||||||||||
69 | Sprint 3 | AL-042 | Feature | Could | Accessibility Font Options | As a user, I want adjustable fonts so that I can read comfortably. | Font size adjustable via Settings page without breaking layout. Preference persists. | Not Started | Font size slider not yet implemented. Low priority — post-PoC polish. | |||||||||||||||||
70 | Sprint 3 | TST-006 | Test | Must | Integration Tests — Group Messaging | As a developer, I want integration tests for group messaging so that multi-user sessions are verified. | 3-user group tested: all receive messages, join/leave handled, keys distributed correctly. | Not Started | Blocked by AL-026 (group messaging) not being complete yet. | |||||||||||||||||
71 | Sprint 3 | TST-007 | Test | Should | UI / Page Render Tests | As a developer, I want tests confirming each page renders correctly so that broken layouts are caught early. | All 6 pages tested: renders without JS errors, key elements present in DOM, responsive breakpoints checked. | Done | All 6 pages render-tested. No JS errors. Responsive breakpoints verified. | |||||||||||||||||
72 | Sprint 3 | TST-008 | Test | Should | Cross-Browser Compatibility Tests | As a developer, I want the app tested across major browsers so that users are not locked to one browser. | Critical flows pass on Chrome, Firefox, Edge, and Safari. | Done | Tested on Chrome, Firefox, and Edge. Safari pending. | |||||||||||||||||
73 | Sprint 4 · Could-Have Features, E2E Testing & Release · Weeks 7–8 · 13 items | |||||||||||||||||||||||||
74 | Sprint 4 | DES-008 | Design | Could | Could Have Screen Designs (QR, Export, Nuke) | As a designer, I want layouts for QR display, JSON export, and nuke contact screens so that Could Have features look consistent. | QR display, DevTools warning, JSON export confirmation, and nuke contact screens designed and approved. | Done | Could Have screen designs complete. Ready for implementation if time allows. | |||||||||||||||||
75 | Sprint 4 | AL-009 | Feature | Could | Display Public Key via QR Code | As a user, I want to display my public key as a QR so that I can share it securely. | QR renders correctly on Setup page. Fallback copy-to-clipboard button available. | Not Started | Could Have — deferred. Paste flow sufficient for PoC. Nice-to-have for demo. | |||||||||||||||||
76 | Sprint 4 | AL-011 | Feature | Could | Expiring QR Codes | As a user, I want QR codes to expire so that old codes cannot be reused. | QR invalid after 5 minutes. Scanning an expired QR shows an error. | Not Started | Depends on AL-009. Both deferred. Post-PoC security enhancement. | |||||||||||||||||
77 | Sprint 4 | AL-019 | Feature | Could | DevTools Open Warning | As a user, I want a warning when DevTools is open so that I am aware of potential compromise. | Warning shown in UI when DevTools detected. Normal usage continues. | Not Started | Could Have. Interesting security UX feature but not required for PoC. | |||||||||||||||||
78 | Sprint 4 | AL-020 | Feature | Could | Browser Extension Detection Warning | As a user, I want a warning if suspicious extensions are detected so that I understand the risks. | Informational warning displayed with guidance. Does not block use. | Not Started | Could Have. Post-PoC. Informational only — does not affect core security. | |||||||||||||||||
79 | Sprint 4 | AL-034 | Feature | Could | Reset / Kill Conversation | As a user, I want to instantly wipe a conversation so that no traces remain. | All messages and session keys cleared from memory immediately on trigger. | Done | Kill switch implemented. All messages and keys cleared on trigger. Confirmed via memory inspection. | |||||||||||||||||
80 | Sprint 4 | AL-035 | Feature | Could | Screenshot Protection | As a user, I want to reduce the risk of screenshots so that my data is harder to capture. | Visibility API used to blur or warn where supported. Degrades gracefully on unsupported browsers. | Not Started | Could Have. Visibility API-based blurring. Progressive enhancement approach. | |||||||||||||||||
81 | Sprint 4 | AL-036 | Feature | Could | Randomised Metadata / Timing | As a user, I want to reduce identifiable traffic patterns so that my conversation is harder to analyse. | Optional random delay injection on send. User can toggle on/off. | Not Started | Could Have. Traffic analysis resistance. Post-PoC security hardening. | |||||||||||||||||
82 | Sprint 4 | AL-037 | Feature | Could | Export Chat to JSON | As a user, I want to export a conversation to JSON so that I can keep a record with mutual consent. | Both parties must approve. JSON file generated and downloaded locally only. | Not Started | Could Have. Mutual consent export. Useful for audit mode in full product. | |||||||||||||||||
83 | Sprint 4 | AL-038 | Feature | Could | Nuke Contact | As a user, I want to delete all traces of a contact so that no related data remains. | Contact entry, associated messages, and localStorage data all removed. Action confirmed via modal. | Started | Nuke contact UI started. Confirmation modal in place. localStorage wipe logic pending. | |||||||||||||||||
84 | Sprint 4 | TST-009 | Test | Must | End-to-End Test Suite | As a developer, I want a full E2E test suite covering all critical user flows so that the app is release-ready. | E2E tests cover: home > setup > chat, self-destruct, group chat, add/delete contact, settings. All pass. | Done | E2E framework set up. Home > setup > chat flow passing. Remaining flows in progress. | |||||||||||||||||
85 | Sprint 4 | TST-010 | Test | Should | Performance & Load Testing | As a developer, I want performance tests for group sessions so that scalability claims are validated. | 10-user group tested with no latency degradation. Memory within acceptable limits. | Started | Basic load test script written. 3-user group passing. 10-user test pending. | |||||||||||||||||
86 | Sprint 4 | TST-011 | Test | Must | Final Regression Pass & Bug Fixes | As a developer, I want a full regression pass before release so that all known issues are resolved. | All P1/P2 bugs fixed. Full regression suite passes. Reviewed by all 4 team members. | Done | Scheduled for end of Sprint 4. Requires all other tests passing first. | |||||||||||||||||
87 | ||||||||||||||||||||||||||
88 | ||||||||||||||||||||||||||
89 | ||||||||||||||||||||||||||
90 | ||||||||||||||||||||||||||
91 | ||||||||||||||||||||||||||
92 | ||||||||||||||||||||||||||
93 | ||||||||||||||||||||||||||
94 | ||||||||||||||||||||||||||
95 | ||||||||||||||||||||||||||
96 | ||||||||||||||||||||||||||
97 | ||||||||||||||||||||||||||
98 | ||||||||||||||||||||||||||
99 | ||||||||||||||||||||||||||
100 | ||||||||||||||||||||||||||