> For the complete documentation index, see [llms.txt](https://faction-os.gitbook.io/faction-os-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://faction-os.gitbook.io/faction-os-docs/.spec_system/archive/phases/phase_23/session_08_validation_and_documentation.md). # Session 08: Validation And Documentation **Session ID**: `phase23-session08-validation-and-documentation` **Package**: apps/web **Status**: Not Started **Estimated Tasks**: \~16 **Estimated Duration**: 2-4 hours *** ## Objective Complete the phase with focused verification, privacy review, fun audit, exit-criteria review, and post-validation documentation updates. *** ## Scope ### In Scope (MVP) * Run the focused web test command from the Legion I plan. * Run `npm --workspace apps/web run typecheck`. * Run `npm run format:check`. * Run broader tests if shared store, Quest Board, or battlefield behavior changes outside the planned files. * Audit privacy, security, persistence, replay, reconnect, mock mode, Banish, and reduced-motion behavior. * Update shipped documentation and game phase ledgers only after validation passes. ### Out of Scope * Recording aspirational behavior as shipped before validation. * Closing hosted identity, production-hosted validation, formal certification, or trusted unified erasure no-claims. * Adding new features beyond fixes required by validation inside this phase scope. *** ## Detailed Requirements * Add focused tests before broad regression. * Run: ```bash npm --workspace apps/web test -- legionCamps.test.ts gameProjection.test.ts gameProjectionStore.test.ts Battlefield.test.tsx QuestBoard.test.tsx questBoardActions.test.ts SettingsScan.test.tsx npm --workspace apps/web run typecheck npm run format:check ``` * Run broader tests if shared store, Quest Board, or battlefield behavior changes outside the listed files. * Audit the implementation against privacy and security requirements: * Store only safe issue ids, relative sector labels, HP, tier, counters, and timestamps in projection state. * Do not store raw issue messages, suggested prompts, mission prompts, transcripts, replay entries, event bodies, terminal output, provider payloads, file contents, absolute paths, environment values, or secrets in projection state. * Continue to rely on existing local projection persistence and browser-local erasure. * Do not add a new storage key. * New UI labels must use existing safe file-label helpers or equivalent compact relative labels. * Do not change trusted-erasure claims. * Do not claim hosted, cross-device, or unified trusted erasure for camp state. * Camp inspection may show richer issue details because Quest Board already owns those cards; projection state must not copy those details. * Perform the fun audit: 1. Glance test: a viewer looking at the board for one second can classify the state as clean, Legion present, scan in progress, or scan failed. 2. Source test: every camp can be clicked or keyboard-activated into the real issue set that created it. 3. Honesty test: replay, reconnect, mock mode, and Banish cannot create progress, rewards, camp kills, or persisted synthetic camps. 4. Silence test: an event-free board with no current issues still looks like a calm state, not a broken or empty app, and emits no urgency signal. 5. Reduced-motion parity: the same information is available without flicker, travel, pulse, looping motion, or motion-only meaning. * Fix validation regressions inside the touched phase scope. * Update shipped documentation and the game phase ledgers only after validation passes. *** ## Exit Criteria * A real scanner snapshot with codebase issues creates visible battlefield camps within the normal event flow. * Every rendered camp maps to at least one real current issue id. * Large issue sets coalesce into a bounded set of readable sector camps. * Sector labels are compact, relative, and safe. * Visible copy frames fronts, sectors, and current camp counts rather than an overwhelming total remaining debt number. * Entrenched camps are quieter but remain inspectable, and they do not create boss, reward, Dawn Report, or progress behavior. * Clicking a camp opens the relevant Quest Board issue set. * Banish dismisses real issues through existing Quest Board actions and gives no game reward. * One-hero and two-hero rosters show a small prioritized camp set, not the full census. * A clean scan shows Golden Age instead of fake enemies. * A not-yet-scanned state does not masquerade as Golden Age. * Reduced-motion mode has complete static equivalents. * Replay cannot mutate or persist camp progress. * Mock mode can show camps in memory but cannot persist them. * No new protocol event, storage key, hosted dependency, or trusted-erasure claim is introduced. * No camp stores raw issue text, prompts, transcripts, terminal output, file contents, absolute paths, environment values, or secrets. * Focused tests, web typecheck, and formatting checks pass. *** ## Prerequisites * [ ] Sessions 04, 05, 06, and 07 are implemented. *** ## Deliverables 1. Passing focused verification, or documented residual failures with in-scope fixes applied. 2. Privacy, security, persistence, replay, mock, Banish, and reduced-motion audit notes. 3. Updated stable docs and game phase ledgers reflecting implemented scanner camp behavior. 4. Final validation notes for the phase. *** ## Dependencies / Notes * Depends on Sessions 04, 05, 06, and 07. * Documentation updates should wait until behavior is validated to avoid recording aspirational behavior as shipped. *** ## Success Criteria * [ ] Focused tests, web typecheck, and formatting checks pass, or any failure is clearly tied to a blocker outside this phase scope. * [ ] No new protocol event, storage key, hosted dependency, or trusted-erasure claim exists. * [ ] All phase exit criteria are satisfied or explicitly called out as incomplete before handoff. * [ ] Every camp can be inspected into the real issue set that created it. * [ ] Replay, reconnect, mock mode, and Banish cannot create progress, rewards, camp kills, or persisted synthetic camps. * [ ] No new protocol event, storage key, hosted dependency, or trusted-erasure claim exists. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://faction-os.gitbook.io/faction-os-docs/.spec_system/archive/phases/phase_23/session_08_validation_and_documentation.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.