> 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_01_protocol_notice_contract_parity.md).

# Session 01: Protocol Notice Contract Parity

**Session ID**: `phase17-session01-protocol-notice-contract-parity` **Package**: packages/protocol **Status**: Not Started **Estimated Tasks**: \~16-24 **Estimated Duration**: 2-4 hours

***

## Objective

Define the canonical Notice Board protocol model, compatibility aliases, request types, event shapes, and validation helpers required by every later package.

***

## Scope

### In Scope (MVP)

* Expand `packages/protocol/src/notices.ts` from the current `body`/`severity` model to the recovered Notice Board model.
* Add canonical notice types: `status`, `question`, `review`, `announcement`, `conflict`, `completion`, and `human`.
* Add canonical priority values: `normal`, `low`, and `critical`.
* Keep compatibility aliases: `body` for `content`, `targets` for `targetSessionIds`, `postedAt` for `createdAt`, and `severity` as UI tint.
* Define fields for `id`, `type`, `priority`, `content`, `tags`, `authorMachineId`, `authorSessionId`, `authorName`, `authorAvatarUrl`, `authorType`, `targetSessionIds`, `parentMessageId`, `relatedFiles`, `roomCode`, `createdAt`, `expiresAt`, `resolved`, `resolvedAt`, and `resolution`.
* Define request and response types for `GET /notice-board`, `GET /notice-board/context`, `POST /notice-board`, `POST /notice-board/:id/resolve`, `GET /notices`, and `POST /notice`.
* Ensure `notice_board_hydrate`, `notice_board_message`, and `notice_resolved` event interfaces support expanded notices and compatibility payload keys.
* Add helpers to derive `severity` from `type` and `priority`.
* Add parsers or guards for notice type, priority, author type, target session arrays, related file arrays, and event payload compatibility.
* Update protocol README or generated docs references when protocol tests require it.
* Add protocol tests covering canonical fields, aliases, invalid values, event compatibility, and helper behavior.

### Out of Scope

* Server persistence.
* REST route implementation.
* Web rendering.
* CLI, hooks, Worker relay, and automatic mission posts.

***

## Prerequisites

* [ ] Phase 17 PRD reviewed.
* [ ] Current `packages/protocol/src/notices.ts` and `packages/protocol/src/events.ts` reviewed.
* [ ] Historical Notice Board fields from `EXAMPLES/package-0.4.1/server/dist/noticeBoardManager.js` reviewed as evidence.

***

## Deliverables

1. Expanded protocol Notice Board model.
2. Compatibility aliases for current clients and tests.
3. Notice Board REST and WebSocket event type definitions.
4. Validation and normalization helpers for later packages.
5. Focused protocol tests.

***

## Task Expansion Guidance

When expanded with `plansession`, keep the checklist to 16-24 tasks covering:

* Current type inventory.
* Recovered field mapping.
* Notice type constants.
* Priority constants.
* Author type constants.
* Request and response interfaces.
* Event interface updates.
* Compatibility alias helpers.
* Severity derivation helper.
* Target validation helper.
* Related file list guard.
* Event parser compatibility tests.
* README or docs update.
* Focused protocol test run.

***

## Success Criteria

* [ ] `Notice` contains all recovered fields and current aliases.
* [ ] Invalid notice types, priorities, author types, targets, and compatibility event payloads fail closed.
* [ ] Existing current event consumers can still compile against compatibility fields.
* [ ] Protocol tests cover expanded canonical and compatibility shapes.


---

# 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_01_protocol_notice_contract_parity.md?ask=<question>&goal=<endgoal>
```

`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.