Stage 4.1: the Chief convenes a temporary meeting and archives what it decided #1731

Written-by: Chief
Part of #1550, first slice of Stage 4. Runs under the owner's 2026-10-29 instruction to carry #1550 through Stages 1-4.

Depends on

2.1 Project record (d5347032), 2.2 task identity (554d939e), 2.4 Project State reader (aafb8d74), 2.5 Project Assistant (d34e4e62), and 3.1's typed record (taskClass, handoff, evidence) from #1720. Decisions land in the decisions/ file set Stage 1 created.

Why

Stage 4 exists so an unresolved architecture conflict does not need a human to hand-draw workflow branches. Today the Chief can open an issue and ask Bots in a group; nothing records that a meeting happened, who argued what, what dissent stood, and which tasks came out of it. Without that record a "meeting" is indistinguishable from a chat, and a decision cannot be audited later.

What to build

1. A meeting is a record with a lifecycle. open → deliberating → decided | blocked, bound to one Project and to the issue or question that triggered it; created by the Chief through one host path (no UI-only flow). A meeting has participants (Bots, and a human where one was invited), and at most one open meeting per question.
2. Governance-valid outcome. A meeting can close decided only when: every invited participant recorded a position (or is recorded as not answering), the decision names its owner, and either no dissent stands or the dissent is written down with its owner. Otherwise it closes blocked — explicitly, with the blocking question in one sentence. The check is code, not prose in a prompt.
3. Archived decision. decided writes one decision file in the Stage 1 shape (decisions/<date>-<slug>.md) carrying: the question, the options, each position with its Bot name, the dissent, the owner, and the evidence shas. blocked writes nothing to decisions/ and stays on the meeting record.
4. Linked tasks. A decided meeting produces tasks through the 3.1 write path (taskClass: 'meeting' for the meeting's own follow-up is not required; the produced tasks are work), each carrying the decision file path as evidence. A blocked meeting produces none.
5. Assistant participation. A Project's assistant may take a position when invited, and its position is recorded under its own name; it may not write the decision file (the Chief or the owner does) and may not close the meeting.

Acceptance

• Tests in core/test/: a decided meeting requires every position and a named owner, and refuses without them; dissent without an owner refuses; blocked writes no decision file and no tasks; a decision file carries each participant's name and the evidence shas; two open meetings on one question are refused.
• An ambiguous architecture conflict is driven end to end in a test: question → participants → positions → decided → one decision file → linked tasks with the file as evidence.
• No second store; npm run verify green at the tip (TZ=UTC); subsystem docs updated (core-host.md, and the governance doc if the meeting shape belongs there) or a valid Docs-not-needed: in both places.
• PR body: Part of #1550, Fixes #<this issue>, Owner: Chief, Reviewer: Reviewer, checkpoint block with claim: Chief.

Out of scope

Personalized digests, quiet hours and per-user authorization (Stage 4.2), and any change to how a group chat works today.