> 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_17/session_10_validation_documentation_and_handoff.md). # Session 10: Validation Documentation And Handoff **Session ID**: `phase17-session10-validation-documentation-and-handoff` **Status**: Not Started **Estimated Tasks**: \~18-25 **Estimated Duration**: 2-4 hours *** ## Objective Validate the full Notice Board port end to end, update stable documentation, and leave phase-close evidence that the ongoing-project note is no longer needed. *** ## Scope ### In Scope (MVP) * Add or update stable docs for Notice Board purpose, privacy boundary, REST routes, WebSocket events, CLI commands, hook context behavior, War Room relay, room notice convergence, and automatic posts. * Ensure docs state that Notice Board is explicit coordination, not an automatic raw event log. * Ensure docs state that notice-board messages may be shared but raw prompts, transcripts, terminal output, file contents, secrets, commands, absolute paths, logs, exports, replay buffers, scans, media drafts, diagnostics, backups, and quarantined historical content must not be shared. * Document canonical routes: * `GET /notice-board` * `GET /notice-board/context` * `POST /notice-board` * `POST /notice-board/:id/resolve` * Document compatibility routes: * `GET /notices` * `POST /notice` * Document CLI commands: * `factionos notice post ` * `factionos notice list` * `factionos notice list --type ` * `factionos notice resolve ` * `factionos notice context --session ` * Add or run end-to-end coverage proving `FACTIONOS_MOCK=false` manual post, hydrate, resolve, targeting, persistence, War Room catch-up, room notice conversion, automatic `status`, and automatic `completion` behavior. * Verify persisted notices survive server restart under `FACTIONOS_HOME`. * Verify non-critical stale notices prune and critical notices remain. * Verify related files display only safe relative paths. * Verify current `/notice`, `/notices`, and `post_notice` compatibility paths still work. * Verify current `warroom_room_notice` input creates a sanitized `announcement` notice. * Verify no Notice Board path shares raw prompts, transcripts, terminal output, file contents, secrets, or absolute local paths. * Run focused package tests, then broader repo gates appropriate for the final phase validation. * Update phase validation, security-compliance notes, and carry-forward posture. * Remove or archive the temporary ongoing-project note only after its contents are fully represented in Phase 17 PRD/session artifacts and stable docs. ### Out of Scope * New Notice Board features not recovered from `EXAMPLES/`. * Hosted account identity, hosted storage, analytics capture, public replay, remote execution, Docker execution, or trusted unified erasure claims. * Formal mobile/accessibility certification. *** ## Prerequisites * [ ] Sessions 01-09 completed. * [ ] Focused package tests from Sessions 01-09 are passing or failures are documented as blockers. * [ ] Stable docs targets are identified. *** ## Deliverables 1. Stable Notice Board documentation. 2. End-to-end validation evidence. 3. Security and privacy validation notes. 4. Phase closeout docs proving ongoing-project charter content has been folded into durable spec/docs artifacts. *** ## Task Expansion Guidance When expanded with `plansession`, keep the checklist to 18-25 tasks covering: * Stable docs inventory. * API docs update. * WebSocket docs update. * CLI docs update. * Hook docs update. * War Room docs update. * Privacy docs update. * Real-mode manual post validation. * Hydration validation. * Resolve validation. * Targeting validation. * Persistence validation. * Pruning validation. * Related-file safety validation. * Compatibility validation. * Room notice conversion validation. * Automatic status validation. * Automatic completion validation. * No sensitive payload validation. * Focused test runs. * Broader repo gate run. * Phase validation notes. * Security-compliance notes. * Ongoing-project note disposition. *** ## Success Criteria * [ ] Stable docs fully describe the implemented Notice Board system. * [ ] All Phase 17 acceptance checks are verified or recorded as blockers. * [ ] The ongoing-project Notice Board note can be deleted without losing source evidence, requirements, acceptance checks, or session split details. * [ ] No new hosted identity, hosted storage, analytics, public replay, remote execution, Docker execution, or trusted erasure claims are introduced. --- # 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_17/session_10_validation_documentation_and_handoff.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.