docs(plans): scope #102 channel-first missions — projection-first, 5 slices, D-1/D-2/D-3 settled

[devin-ai-integration]

Summary

Scope verdict for #102, plan only. Docs-only diff under
plans/20260811-channel-first-missions/. Nothing implemented, no D-number taken,
nothing merged.

The finding that shapes the whole epic:

Everything a Mission displays is already durable on the relay — except the fact
that it is a Mission.

Mission fact	Durable today?	Where
thread root / channel / assignment	yes	NIP-10 e + h + p (buzz-sdk/src/builders.rs:179-239)
human decision pending/answered/resolved	yes	46040/46041/46042 (buzz-acp/src/elicitation.rs:853-956)
terminal result	yes	46043 (buzz-acp/src/pool.rs:5544-5589)
owner accept/reject	yes	NIP-25 kind 7 (shipping; extended by #128)
Project / PR / CI context	yes	30617/30621, 1630-1633
"this thread is a Mission"	no	—
cancelled / reopened	no	—

So the design is not "add a mission store". It is a pure projection over events
that already exist, plus exactly one durable promotion marker:

durable relay events (already exist)  +  ONE promotion marker
        └──────────────► missionState(threadRoot) ──► in-thread strip
                          (pure, no writes, no TTL, no authority)

Equally load-bearing: the plan forbids by name the stores a naive implementation
would reach for, because each would make a Mission silently un-complete itself —
conversationOutcomeLedger.ts:11-51 (4h TTL), needsYouStore.ts:12,35-50 (30m TTL),
activeAgentTurnsStore.ts:83-106, projectThreadWorkspaceStore.ts (cap 256). A
RED contract asserts a Mission reconstructs with all three empty.

Two things the issue assumes that the code contradicts, surfaced instead of faked:

• DoD step 5 (worktree for a promoted thread) is unreachable in an ordinary
  channel — provisioning is fail-closed on trusted buzz://project-workspace?
  metadata (pool.rs:3019-3078, thread_workspace.rs:244-270,141-148). Settled by
  D-3 below: promotion is still allowed there, and the strip must say so plainly.
• DoD steps 9-12 depend on receipts, which are off by default
  (config.rs:1495) → spike Q3 before any UI work.

Slices (spike → RED → implement → verify each): 00 reality-check spike (4
pre-declared PASS/FAIL questions) · 01 promote in place, gated on restart
reconstructs the strip from the relay alone · 02 live state + inline decision ·
03 review from a durable receipt, reusing the existing ✅ accept path · 04
cancel/reopen/retry. Slice 00 is runnable today and gates slice 01.

Founder decisions — now settled (this PR still takes no D-number)

The plan escalated three product decisions rather than guessing them; the founder has
since decided all three, and the plan records them as settled inputs:

• D-1 = tagged ordinary message. Owner-authored kind 9 with the normal h +
  NIP-10 e tags, carrying ["crew-mission","promote"] and
  ["crew-mission-goal","<title>"]. No new event kind. Rejected alternatives and
  their trade-offs stay recorded.
• D-2 = the marker is not the board schema D-037(2) defers, because it is
  thread-scoped with no lane, column, order or priority. The agreed tripwire is
  now written into §3, the non-goals, slice 01's review checklist and its DoD: the
  moment anyone wants priority or ordering on a Mission, the work stops and returns to
  the founder as a fresh decision — an implementer may not settle it.
• D-3 = promote anywhere. Outside a Project you get durable Mission state and
  decisions but no isolated checkout, and slice 01 must state that limitation in
  plain language in the strip rather than failing mysteriously — with a RED contract
  (ordinary_channel_mission_explains_no_worktree) so it cannot be skipped.

Promotion is a manual human toggle, now a hard invariant: a Mission is never
inferred from a worktree, a receipt, ACP telemetry, or any other side effect. The
valid marker is the only Mission authority (red-team RT-11 moves from "rejected on the
plan's judgement" to "ruled out by the founder").

Composition (§3): Mission carries no assignee (that stays @mention + roles,
#120), no accept button (that stays NIP-25 kind 7, #128), no readiness state
(#134), and the strip must live in new Crew-owned components — MessageRow.tsx
is 980/1000 against the ratchet and D-022 forbids raising MAX_LINES.

Respecting #140/D-037: board schema stays deferred and the work-overview lens
stays out of scope — both are explicit non-goals, and the lens is a future consumer
of missionState(), not part of this epic.

Red team: 12 findings — 9 applied, 3 rejected with reasons (new 30xxx kind;
infer-instead-of-promote; ship the suggestion card in slice 01).

Still open, deliberately unwritten: the founder also wants a message inside a
thread to be promotable, not just a thread root. That changes the projection's
identity key (what a Mission is anchored to, and what happens when both a message and
its enclosing thread are promoted), so it is being worked out with him rather than
guessed — every statement in this diff keeps today's thread-root identity wording.

Related issue

#102. Related in-flight, none merged: #140 (D-037), #124 (STATE baseline used here),
#128 (#121 evidence/acceptance), #120 (#116 roles/routing), #134 (#119 readiness),
#129/#131 (Projects E2E). Duplicate search: no open issue or PR covers thread→Mission
promotion.

Testing

Docs-only; no code paths touched, no shipped state changed (so no STATE.md edit —
this PR ships a plan, not behavior).

• . ./bin/activate-hermit
• pnpm --filter buzz check — pass (Biome 2,195 files; file-size, px-text and
  pubkey-truncation checks pass)
• git diff --check — clean

Every path:line in the plan was verified against origin/main @ 35af74019. No
screenshots: no visual change.

Link to Devin session: https://app.devin.ai/sessions/fd898bfdc6044b479eff8cb4ff1b96a0
Requested by: @oscarlehuu

[devin-ai-integration]

🤖 Devin AI Engineer

I'll be helping with this pull request! Here's what you should know:

✅ I will automatically:

• Address comments on this PR. Add '(aside)' to your comment to have me ignore it.
• Look at CI failures and help fix them

Note: I can only respond to comments from users who have write access to this repository.

⚙️ Control Options:

• Disable automatic comment, CI, and merge conflict monitoring