> 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/prd_phase_17.md). # PRD Phase 17: Notice Board Coordination Parity **Status**: Complete **Sessions**: 10 **Estimated Duration**: 20-40 hours **Progress**: 10/10 sessions (100%) *** ## Overview Port the historical Notice Board coordination system from `EXAMPLES/` into the current FactionOS runtime. The Notice Board is a required cross-hero coordination system, not a passive demo feed and not a static UI panel. This phase replaces the current local stub with the recovered system while keeping current APIs as compatibility adapters. It restores first-class agent and human coordination messages, historical `/notice-board` REST routes, realtime events, room-scoped storage, targeting, resolution, context generation, pruning, persistence, CLI and hook access, automatic status and completion posts, War Room relay catch-up, and resolution propagation. This phase PRD embeds the full Notice Board port charter. The former ongoing-project note `docs/ongoing-projects/notice-board-coordination-recovery.md` has been absorbed into this phase PRD and its session stubs; no requirements, source evidence, data-model details, acceptance checks, or session split details remain exclusive to that note. Source charter date: 2026-06-02. *** ## Ongoing Project Map This phase absorbs the Notice Board ongoing-project thread. The other ongoing-project files remain separate active concerns. | File | Active concern | | --------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `project-readiness-audit.md` | Remaining readiness todos for local security, env loading, Cloudflare posture, release hygiene, outbound privacy, analytics, and future hosted surfaces. | | `project-readiness-audit-context.md` | Evidence behind the readiness list: local-first posture, package inventory, env variables, Cloudflare checks, quarantined `EXAMPLES/` inventory, media generation policy, validation snapshots, and analytics provider decision. | | `synthetic-sound-map.md` | Audio replacement plan for the file-backed bark engine, remaining SFX sourcing, and lobster voice-line gap. | | `notice-board-coordination-recovery.md` | Former mandatory port plan for the historical Notice Board coordination system, now absorbed into this Phase 17 PRD and its session stubs. | *** ## Progress Tracker | Session | Name | Status | Est. Tasks | Validated | | ------- | ------------------------------------------------- | --------- | ---------- | ---------- | | 01 | Protocol Notice Contract Parity | Completed | \~16-24 | 2026-06-05 | | 02 | Server Notice Manager Persistence And Context | Completed | \~18-25 | 2026-06-05 | | 03 | Server Routes And WebSocket Parity | Completed | \~18-25 | 2026-06-05 | | 04 | Web Store And Cockpit Notice Board | Completed | \~18-25 | 2026-06-05 | | 05 | CLI Notice Commands | Completed | \~14-22 | 2026-06-05 | | 06 | Hook Context And Provider Skill Parity | Completed | \~14-22 | 2026-06-05 | | 07 | War Room Worker Relay And Catchup | Completed | \~18-25 | 2026-06-05 | | 08 | Local War Room Bridge And Room Notice Convergence | Completed | \~18-25 | 2026-06-05 | | 09 | Automatic Mission Lifecycle Posts | Completed | \~14-22 | 2026-06-06 | | 10 | Validation Documentation And Handoff | Completed | \~18-25 | 2026-06-06 | *** ## Completed Sessions * Session 01: Protocol Notice Contract Parity completed on 2026-06-05. * Session 02: Server Notice Manager Persistence And Context completed on 2026-06-05. * Session 03: Server Routes And WebSocket Parity completed on 2026-06-05. * Session 04: Web Store And Cockpit Notice Board completed on 2026-06-05. * Session 05: CLI Notice Commands completed on 2026-06-05. * Session 06: Hook Context And Provider Skill Parity completed on 2026-06-05. * Session 07: War Room Worker Relay And Catchup completed on 2026-06-05. * Session 08: Local War Room Bridge And Room Notice Convergence completed on 2026-06-05. * Session 09: Automatic Mission Lifecycle Posts completed on 2026-06-06. * Session 10: Validation Documentation And Handoff completed on 2026-06-06. *** ## Upcoming Sessions * None. This phase is complete and archived. *** ## Apex Workflow And Split Rules Each session must be expanded with `plansession` before implementation, then follow `plansession -> implement -> validate -> updateprd`. After all sessions in this phase complete, follow the Apex phase-transition cadence: `audit -> pipeline -> infra -> carryforward -> documents`, followed by manual QA and LLM audit before creating or starting the next phase. Split a planned session before implementation if: * The task checklist exceeds 25 tasks. * The objective includes two unrelated outcomes. * The session touches more than 2-3 packages. * War Room relay, local server bridge, and web UI work begin to overlap in one implementation pass. * Privacy or data-transfer validation cannot be closed inside the same 2-4 hour window. *** ## Objectives 1. Replace the current in-memory Notice Board stub with the recovered room-scoped coordination system. 2. Restore canonical historical routes, realtime events, persistence, targeting, context lookup, resolution, automatic lifecycle posts, CLI access, hook context, and War Room relay behavior. 3. Preserve current `/notice`, `/notices`, `post_notice`, and `warroom_room_notice` compatibility surfaces through explicit adapters. 4. Maintain the established privacy boundary: notice-board messages may be shared, but raw prompts, transcripts, terminal output, file contents, secrets, command bodies, absolute paths, logs, exports, replay buffers, scans, media drafts, diagnostics, backups, and quarantined historical content must not be shared. *** ## Prerequisites * Phase 16 completed. * Current FactionOS runtime, web, CLI, hooks, protocol, and War Room packages are available in the monorepo. * `docs/ongoing-projects/notice-board-coordination-recovery.md` has been studied and its details are embedded here. * `EXAMPLES/` remains available as quarantined reference-only evidence. *** ## Source Evidence `EXAMPLES/` remains quarantined reference material. Behavior is studied and ported into current source; old source is not copied blindly. | Evidence | Required port behavior | | --------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `EXAMPLES/findings/api-routes.txt` | Restore the `/notice-board`, `/notice-board/:id/resolve`, and `/notice-board/context` route family. | | `EXAMPLES/findings/websocket-events.txt` | Preserve `notice_board_hydrate`, `notice_board_message`, and `notice_resolved` as runtime events. | | `EXAMPLES/findings/BUILD_LINKS.md` | Replace the current minimal `noticeBoardManager` mapping with parity behavior. | | `EXAMPLES/package-0.4.1/plugin/skills/notice-board/SKILL.md` | Provide first-class agent commands for posting and listing notices before, during, and after work. | | `EXAMPLES/package-0.4.1/plugin/skills/notice-board/scripts/post_notice.sh` | Support typed posts to `/notice-board` with session id, author name, and `authorType: "agent"`. | | `EXAMPLES/package-0.4.1/plugin/skills/notice-board/scripts/list_notices.sh` | Support listing unresolved notices, `forSession` targeting, `limit=20`, and type filtering. | | `EXAMPLES/package-0.4.1/server/dist/noticeBoardManager.js` | Restore persistence, 500-message cap, room filtering, target filtering, resolution, context cache, auto-post dedupe, stale pruning, and critical retention. | | `EXAMPLES/package-0.4.1/server/dist/index.js` | Restore request validation, safe related-file normalization, local broadcast, War Room relay forwarding, resolve forwarding, collaboration instructions, and automatic mission status/completion posts. | | `EXAMPLES/package-0.4.1/server/dist/warRoomClient.js` | Restore relay paths for notice-board messages, notice resolution, and notice catch-up. | | `EXAMPLES/package-0.4.1/plugin/hooks/agentcraft-hero-active.js` | Restore bounded notice context lookup and the agent reminder to post brief Notice Board updates. | | `EXAMPLES/package-0.4.1/plugin/skills/agentcraft-guide/SKILL.md` | Preserve the privacy boundary: notice-board messages are shared; file contents, prompts, transcripts, and terminal access are not. | *** ## Product Contract The Notice Board coordinates active multi-agent work in a shared hall or room. It answers: "What must the other active heroes and humans know before they keep working?" Required message behavior: * Agents post a `status` notice when starting work. * Agents post a `completion` notice when finishing work, including safe relative file references when available. * Agents post `question`, `review`, `announcement`, and `conflict` notices when work needs attention. * Agents read unresolved notices before starting so they do not collide with another hero or miss a blocker. * Humans can post into the same board as `human` authors. * The board carries coordination data only. It never carries raw prompts, transcripts, terminal output, secrets, absolute local paths, or file contents. Required notice types: | Type | Ported use | | -------------- | ------------------------------------------------------------ | | `status` | Share active work. | | `question` | Ask a human or another agent for input. | | `review` | Request review of a branch or change. | | `announcement` | Broadcast important shared state such as a broken build. | | `conflict` | Flag merge conflict, file contention, or collaboration risk. | | `completion` | Announce task completion and affected files. | | `human` | Represent user-authored messages in the same channel. | *** ## Required Data Model The current `packages/protocol/src/notices.ts` model must expand from the small `body`/`severity` shape to the recovered message model. Current fields stay as aliases during migration so existing UI and tests keep working. | Field | Requirement | | ------------------ | ----------------------------------------------------------------------------------------- | | `id` | `notice__` or equivalent stable unique id. | | `type` | One of the recovered notice types. | | `priority` | `normal`, `low`, or `critical`; unsupported input maps to `normal`. | | `content` | Canonical message text, capped at 2000 characters. | | `body` | Compatibility alias for `content`. | | `tags` | Up to 10 short strings, defaulting to `[type]`. | | `authorMachineId` | Local machine id for room provenance. | | `authorSessionId` | Author session id, capped at 100 characters. | | `authorName` | Display name, capped at 100 characters. | | `authorAvatarUrl` | Human or relay avatar URL after existing auth/identity sanitization. | | `authorType` | `agent` or `human`. | | `targetSessionIds` | Up to 20 sessions allowed to see a targeted notice. Empty means all sessions in the room. | | `targets` | Compatibility alias for `targetSessionIds`. | | `parentMessageId` | Reply/thread parent id, capped at 100 characters. | | `relatedFiles` | Up to 20 safe repository- or worktree-relative paths. | | `roomCode` | Active War Room code or the local standalone room id. | | `createdAt` | Millisecond timestamp for ordering, filtering, context, and pruning. | | `postedAt` | ISO compatibility alias for `createdAt`. | | `expiresAt` | Expiration timestamp used by auto-posted notices. | | `resolved` | Boolean resolution state. | | `resolvedAt` | ISO compatibility timestamp when resolved. | | `resolution` | Resolution text for compatibility clients. | Visual `severity` remains a UI compatibility field derived from `type` and `priority`. It is not the workflow type. *** ## Required Server Behavior `apps/server/src/managers/noticeBoard.ts` must become a parity manager: * Persist state to `notice-board.json` under `FACTIONOS_HOME` or the current local state root used by server storage helpers. * Load persisted state on startup and flush saves on shutdown. * Debounce saves around the recovered 500 ms pattern. * Cap stored messages at 500. * Prune every five minutes. * Remove stale non-critical messages after roughly two hours. * Keep critical notices until resolved or explicitly pruned. * Remove expired notices after `expiresAt`. * Store unresolved and resolved notices. * Filter by room, type, `since`, target session, expiration, offset, limit, and include-resolved state. * Return newest-first lists and total counts. * Cache context lookups for roughly five seconds. * Invalidate context cache on post, ingest, batch ingest, resolve, prune, and load changes. * Deduplicate `autoPost` for the same room, author session, and type inside the recovered 30 second window. Room behavior is set: * The canonical Notice Board is room-scoped. * When connected to War Room, `roomCode` is the active War Room code. * When running standalone locally, the server uses a local room id so the bottom-right board works without mock mode. * Compatibility `/notice` posts are stored in the active room id and continue to appear in the cockpit. *** ## Required Routes Canonical routes: * `GET /notice-board` * `GET /notice-board/context` * `POST /notice-board` * `POST /notice-board/:id/resolve` Compatibility routes: * `GET /notices` * `POST /notice` `GET /notice-board` accepts `type`, `since`, `forSession`, `limit`, `offset`, `includeResolved`, `roomCode`, and `debug=1`. It returns `{ messages, total }`. `GET /notices` returns `{ notices }` using the same manager. `GET /notice-board/context?sessionId=` returns `{ context }`. The context contains only new unresolved messages for that session in the active room, excludes messages authored by that same session, honors `targetSessionIds`, and uses the recovered heading: ``` ## Notice Board (New Messages) ``` `POST /notice-board` validates and stores: * `type` and `content` are required. * `type` must be one of the recovered notice types. * `content` is capped at 2000 characters. * `authorName`, `authorSessionId`, `authorType`, `authorAvatarUrl`, `priority`, `tags`, `targetSessionIds`, `parentMessageId`, and `relatedFiles` are normalized exactly as the recovered route did. * `relatedFiles` are accepted only when they normalize to safe relative paths inside the current project/worktree boundaries. * Posts emit `notice_board_message` locally and through the War Room relay when connected. `POST /notice-board/:id/resolve` marks a notice resolved only in the active room, emits `notice_resolved` locally, forwards resolution through the War Room relay, and returns `{ success: true }`. *** ## Required Realtime And Relay Behavior Local WebSocket behavior: * New clients receive `notice_board_hydrate` with current active-room notices. * New local posts emit `notice_board_message`. * Resolution emits `notice_resolved`. * The web store handles both `notice` and recovered `message` payload keys for compatibility during migration. * Hydration no longer erases a useful local board with an empty mock-only replacement when persisted active-room notices exist. War Room behavior: * Restore relay support for `notice_board_message`. * Restore relay support for `notice_resolved`. * Restore relay support for `notice_board_catchup`. * Ingest remote notices once by id and record debug provenance. * Forward local posts and resolutions to the relay when connected. * Hydrate connected web clients after catch-up ingestion. * Preserve the existing safe Worker contract by treating `warroom_room_notice` as an alias that creates a sanitized `announcement` notice in the active room. *** ## Required Agent Access The historical notice-board skill must be represented in current FactionOS by first-party CLI and hook helpers. Required CLI commands: * `factionos notice post ` * `factionos notice list` * `factionos notice list --type ` * `factionos notice resolve ` * `factionos notice context --session ` Required command behavior: * Use `FACTIONOS_SERVER_URL` with fallback to `http://localhost:2468`. * Use `FACTIONOS_AUTH_TOKEN` when configured. * Use `FACTIONOS_SESSION_ID`, provider session id, or `unknown`. * Use configured hero/session display name with fallback `Agent-`. * Post `authorType: "agent"` for agent commands. * Print unresolved notices with timestamp, type, author, content, priority, and first three related files. * Return a clear "No active notices on the board." message when empty. Required hook behavior: * `apps/hooks/src/factionos-hero-active.js` fetches `/notice-board/context?sessionId=` on prompt start. * Provider-safe hook output includes the bounded Notice Board context and the reminder to post brief updates. * Hook output never includes raw prompts, transcripts, terminal output, secrets, absolute paths, or file contents. * Providers without a safe additional-context contract receive command-access parity through the CLI. *** ## Required Automatic Posts The recovered server did more than wait for manual posts. It also created bounded automatic coordination notices: * On mission name generation, call `autoPost("status", "Started: ", ...)` with an expiration around 30 minutes. * On mission summary generation, call `autoPost("completion", "Done: ", ...)` with an expiration around one hour. * Use the same room, author session, author name, machine id, avatar, related files, and dedupe rules as the recovered implementation. * Broadcast and relay each generated notice exactly like a manual notice. * Keep automatic posts concise and coordination-only. Normal raw hook events remain separate telemetry. The Notice Board receives manual coordination posts plus the recovered bounded automatic status and completion posts. *** ## Required Web Experience `apps/web/src/components/NoticeBoard.tsx` remains the bottom-right cockpit surface, but it must become a real coordination board: * Render active-room notices, newest first. * Support historical `type` labels in addition to severity tint. * Show priority, author, age, content, target state, related files, and resolved state in compact form. * Enforce target visibility for the active session/hero. * Handle `notice_resolved` without a refresh. * Provide a clear empty state for "no active notices" in real mode. * Provide clear disconnected and filtered-out states. * Keep the six-item compact cockpit list and allow expansion through an existing drawer or detail surface when more history is available. War Room panel notices and cockpit Notice Board entries converge through the canonical notice manager. The current `warroom_room_notice` form remains usable and produces a sanitized `announcement` notice. *** ## Current Implementation Gaps | Current path | Gap to close | | ------------------------------------------ | ------------------------------------------------------------------------------------------------------------- | | `packages/protocol/src/notices.ts` | Expand from `body`/`severity` to the recovered notice model and retain aliases. | | `packages/protocol/src/events.ts` | Ensure hydrate/message/resolve events carry expanded notices and compatibility keys. | | `apps/server/src/managers/noticeBoard.ts` | Replace in-memory 200-item list with persisted parity manager. | | `apps/server/src/routes/heroes.ts` | Add canonical `/notice-board` routes and keep `/notice` adapters. | | `apps/server/src/ws/handlers.ts` | Hydrate active-room notices, accept expanded `post_notice`, emit resolution, and accept compatibility shapes. | | `apps/web/src/store/useGameStore.ts` | Normalize expanded notices, handle `notice_resolved`, and target-filter board state. | | `apps/web/src/components/NoticeBoard.tsx` | Render type/priority/author/related-file/resolved details. | | `apps/web/src/components/WarRoomPanel.tsx` | Send room notices through canonical notice creation. | | `apps/web/src/lib/warRoomFederation.ts` | Map safe room notices into canonical announcement notices. | | `apps/warroom/src/index.ts` | Add Notice Board relay/catch-up/resolution behavior. | | `apps/cli/src/index.js` | Add `factionos notice` commands. | | `apps/hooks/src/factionos-hero-active.js` | Restore context fetch and update reminder. | *** ## Why The Board Is Blank Today The cockpit board renders local server notices. On WebSocket connect, `notice_board_hydrate` replaces client seed data with `ctx.notices.list()`. With `FACTIONOS_MOCK=false`, the mock generator is off. The current real hook events do not post Notice Board messages, the current hooks do not fetch board context, and the current CLI has no notice command. The server list is empty, so the bottom-right surface is blank. This phase fixes the root cause by restoring real post paths, automatic recovered mission lifecycle posts, persisted state, context lookup, and War Room relay behavior. *** ## Session Plan Session 01 - Protocol Notice Contract Parity: * Expand `Notice`, request, and event types. * Add canonical and compatibility notice aliases. * Add protocol validation helpers for notice type, priority, related files, safe targets, and event payload shapes. * Add protocol tests for all recovered data-model fields and compatibility event forms. Session 02 - Server Notice Manager Persistence And Context: * Implement persistent `NoticeBoard` manager with recovered filters, cache, pruning, resolution, ingest, batch ingest, and auto-post behavior. * Persist under `FACTIONOS_HOME`. * Add manager unit tests for all fields, filters, pruning, persistence, targeting, resolution, context, and dedupe. Session 03 - Server Routes And WebSocket Parity: * Add canonical `/notice-board` routes. * Keep `/notice` and `/notices` as adapters. * Add request validation for type, content, tags, targets, related files, priority, author metadata, and room id. * Emit and handle hydrate/message/resolve events. * Add server route and WebSocket tests for real-mode posting without mock mode. Session 04 - Web Store And Cockpit Notice Board: * Normalize expanded notices in the web store. * Handle `notice_resolved`. * Update the bottom-right Notice Board UI for type, priority, author, target, related files, resolved state, empty state, disconnected state, and filtered state. * Add store and component tests. Session 05 - CLI Notice Commands: * Add `factionos notice` command group. * Wire auth token and server URL handling. * Implement post, list, type-filtered list, resolve, and context commands. * Add CLI tests covering empty board, post, list, resolve, context, and auth. Session 06 - Hook Context And Provider Skill Parity: * Restore hero-active context lookup and reminder output. * Keep hook output bounded and provider-safe. * Ensure hooks never emit raw prompts, transcripts, terminal output, secrets, absolute paths, file contents, or unsafe command data. * Add hook tests covering context, no-context, malformed server response, auth, timeout, and safe output. Session 07 - War Room Worker Relay And Catchup: * Add Worker/protocol support for notice-board message relay, resolution relay, and catch-up. * Keep Worker frames bounded, redacted, sender-excluded, and validated. * Add War Room tests for catch-up, relay, resolution, sanitization, sender exclusion, and bounded history. Session 08 - Local War Room Bridge And Room Notice Convergence: * Wire local server War Room client send/ingest paths for Notice Board relay. * Hydrate local web clients after remote catch-up ingestion. * Convert current `warroom_room_notice` frames into sanitized `announcement` notices in the canonical manager. * Add bridge tests for provenance, dedupe, resolution, and compatibility. Session 09 - Automatic Mission Lifecycle Posts: * Restore recovered mission-start `status` auto-post. * Restore recovered mission-summary `completion` auto-post. * Enforce dedupe, expiration, related-file safety, room scoping, local broadcast, and relay forwarding. * Add tests that prove real sessions populate the board without static demo or mock mode. Session 10 - Validation Documentation And Handoff: * Document CLI usage, REST contracts, event contracts, privacy boundaries, and real-mode behavior. * Add end-to-end coverage for `FACTIONOS_MOCK=false` posting, hydration, resolution, targeting, persistence, War Room relay, and automatic posts. * Run focused package tests, then broader repo gates. * Update phase docs, security notes, and carry-forward posture. *** ## Technical Considerations ### Architecture * Protocol leads cross-package work. Shared notice types, event types, and validation helpers must land before package-specific behavior. * Server owns canonical Notice Board state, persistence, filtering, context, resolution, and automatic lifecycle posts. * Web owns cockpit rendering and local store normalization, but must not own canonical filtering rules that belong on the server. * CLI and hooks provide first-class agent access so real sessions can use the board without mock mode. * War Room relay remains optional external transfer and must keep the local server as the canonical local state owner. ### Technologies * TypeScript protocol and server packages. * Express REST routes. * WebSocket events. * Cloudflare Worker and Durable Object War Room package. * React web cockpit and Zustand stores. * JavaScript CLI and hook packages. * Vitest package tests and focused integration tests. ### Risks * Cross-package contract drift: mitigate by implementing protocol helpers first and testing compatibility shapes. * Privacy leakage through shared coordination: mitigate with allowlists, blocked-field tests, relative-path normalization, bounded payloads, and no raw prompts/transcripts/commands/files. * Room-scope confusion: mitigate by using active War Room code when connected and a local standalone room id when not connected. * Compatibility breakage: mitigate by keeping `/notice`, `/notices`, `post_notice`, `notice` payload keys, `message` payload keys, `body`, `content`, `targets`, `targetSessionIds`, `postedAt`, and `createdAt` adapters during migration. * War Room boundary drift: mitigate by treating Worker relay as optional external transfer and preserving all no-claim language around hosted identity, public collaboration safety, production auditability, and trusted erasure. ### Relevant Considerations * \[P03-packages/protocol] **Protocol leads cross-package work**: Notice Board types and event contracts must land in `packages/protocol` before wiring server, web, CLI, hooks, or Worker behavior. * \[P06-apps/warroom+apps/web] **War Room federation is optional and redacted**: Notice Board relay may share coordination messages only; it must not imply hosted identity, public collaboration safety, production auditability, certification, or full erasure. * \[P07] **Redaction is boundary-specific**: Every REST, WebSocket, Worker, CLI, hook, replay, export, log, and diagnostic boundary needs explicit minimization. * \[P03-apps/server] **Local server boundary must stay conservative**: Keep loopback binding, optional auth, CORS/WS origin checks, request validation, rate limits, body-size caps, and explicit unavailable states intact. * \[P03] **Stable docs are the current contract**: `EXAMPLES/` is evidence only; current docs and code become source of truth after this phase. *** ## Success Criteria Phase complete when: * [ ] All 10 sessions completed. * [ ] With `FACTIONOS_MOCK=false`, `factionos notice post status "Working on X"` appears in the bottom-right Notice Board without a refresh. * [ ] `POST /notice-board` returns a stored notice and emits `notice_board_message`. * [ ] `GET /notice-board?forSession=` hides notices targeted to other sessions. * [ ] `GET /notice-board/context?sessionId=` returns only new unresolved relevant messages and excludes that session's own messages. * [ ] `POST /notice-board/:id/resolve` updates all connected clients through `notice_resolved`. * [ ] Persisted notices survive server restart under `FACTIONOS_HOME`. * [ ] Non-critical stale notices prune on schedule and critical notices remain. * [ ] Related files display only safe relative paths. * [ ] War Room catch-up hydrates local clients and does not duplicate notices. * [ ] Current `/notice`, `/notices`, and `post_notice` compatibility paths still work. * [ ] Current `warroom_room_notice` input creates a sanitized `announcement` notice. * [ ] Mission name generation creates a deduped `status` notice. * [ ] Mission summary generation creates a deduped `completion` notice. * [ ] No Notice Board path shares raw prompts, transcripts, terminal output, file contents, secrets, or absolute local paths. * [ ] Stable docs and package docs state that Notice Board is explicit coordination, not an automatic raw event log. *** ## Dependencies ### Depends On * Phase 16: Quality, Deployment, And Launch Handoff. * Archived Phase 03: protocol-led local runtime and orchestration patterns. * Archived Phase 05 and Phase 06: optional War Room and redacted collaboration boundaries. ### Enables * Real cross-agent coordination in local and optional War Room sessions. * Removal of the temporary ongoing-project Notice Board charter after this phase PRD is committed. * Later collaboration polish that can build on canonical Notice Board state instead of mock or static demo behavior. --- # 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/prd_phase_17.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.