CR-2026-237 — The Manifestation Write Through Conversation — v0.1

Version: v0.1 Date: 2026-08-26 Status: Drafted in-session under completion-program P-1 (ruled: yes). Markdown primary — the consumer is Claude Code, and the drafting session is the executing session per the program's kickoff block. Occasion: B-78 (standing-notes/dunin7-build-list-v1_07), rank 2 of the completion program's Wave 1. Split from B-8 slice two by Operator ruling 2026-08-10, with the intended shape named in the filing: stated-facts-before-the-call, per CR-2026-189 — the pattern transfers; the component does not. Cites: the B-8 slice-two scoping read; CR-2026-189 (the surface's RederiveConsent and the stated-facts discipline); CR-2026-197 §0.1 (per_action_only Tier-1 posture); CR-2026-200 (grant rendering + in-project scope default); CR-2026-201/204 (server-composed replies, composition stamping); CR-2026-177 (the spend gate actually runs on the preview path).

Plain-language summary

The Operator can already ask the Companion to draft a specification or produce a report in conversation. They cannot ask it to organize the project's memory — the Manifestation derivation — because that act has no name in the delegation vocabulary, no classified intent, and no dispatcher. The only door is the Manifestation room's own button.

This CR gives the act its conversational door, built to the same consent standard the room's button already meets: the consent names what is knowable free of charge — the change counts since the last organization — and does not claim a price, because the only honest cost figure needs the assembled prompts. The approval card is that consent. Approving it runs the metered organization and stores exactly what that organization produced, in one dispatch — mirroring what the room's own confirm does in one press.

1. Step 0 — what the code says, read at `a0da312`

The spend is in preview, not derive — confirmed. preview_manifestation calls organize_assertions (metered since CR-2026-177) when committed assertions exist; derive_manifestation calls no model — it stores the ordering verbatim and appends events.
The adjacency question is settled by the surface's own behavior. ManifestationRoom.tsx's runRederive chains previewRederive → commitRederive(previewed.proposedOrganization) in one press — the Operator consents to stated facts, and the derive stores what the preview it authorized produced, without a separate review of the ordering. The conversational flow that mirrors this is therefore ONE approval card whose dispatch runs preview→derive adjacently, echoing the previewed ordering verbatim. The build-list entry's adjacency constraint is satisfied the same way the surface satisfies it: consent ↔ preview ↔ derive are one bound act.
The pause-machinery exclusion is not a blocker for this shape. _PAUSEABLE_ROOMS excludes manifestation because the room runs synchronously in-request. The approval card is not the pause machinery — the card is the decision, taken before the spend; nothing needs to park mid-flight. The 402 path (system-key spend refused) surfaces as a failed execution result on the card, honestly reported.
The delegation machinery is fully generic. verify_companion_authorization, create_approval_card, process_approval (which builds a companion ActorRef whose id is the approving person and whose capability_ref is the delegation), and dispatch_action all key on the capability string. Only the vocabulary rows and the handler are missing.
Free facts have a free source. get_memory_status (Phase 12) computes the six-category change counts with no model call — the same source the surface's consent reads.

2. The change

New capability — delegation/schema.py: CAPABILITY_DERIVE_MANIFESTATION = "derive_manifestation", in TIER_1_CAPABILITIES; grant phrases added to _ACTION_CAPABILITY in the room's own vocabulary ("organize memory", "organize the memory", "organize my notes", "reorganize memory", "derive a manifestation", + gerund forms). delegation/rendering.py: _CAPABILITY_PHRASES entry — "organize this project's memory".

New classified intent — request_manifestation: classifier.py IntentLabel (the intent_hint Literal derives automatically per Phase 55 §5.1); taxonomy entry in prompts/intent_classifier.md ("Organize the memory again" / "Rebuild the summary" / "Derive a new manifestation" — distinct from ask_about_manifestations, which only reads); instruction template prompts/intent_instructions/request_manifestation.md modeled on request_draft.md, carrying {operation_result}.

New route — router.py _route_request_manifestation, the _route_request_draft shape with the stated-facts card body:

no_project → responder asks which project.
denied → server-composed _denied_reply; _GRANT_SUGGESTIONS entry ("organize this project's memory" / "you can organize memory" — a sentence extract_delegation_grant recognizes, per the B-87 discipline).
approval_card (per-action, or pre-authorized forced per-action by the dispatcher) → the card's body states the free facts from get_memory_status — the change counts since the last organization, or that none exists yet — and states that the exact cost cannot be known in advance rather than staying silent about price. Server-composed _approval_card_reply.
executed unreachable in practice (per_action_only forces the card) but handled by the shared formatter per CR-2026-199 member 2.

prompt.py: request_manifestation joins the _format_delegation_action dispatch (with target_description) and OPERATION_RESULT_INTENTS.

New dispatcher — companion_room_dispatchers.py derive_manifestation_dispatch, registered per_action_only=True (CR-2026-197 §0.1 posture): resolves the engagement LLM via resolve_room_llm(engagement_id, person_id=actor.id, secret_key=kek_provider().current_kek_material()); graceful _failed when no key resolves; builds a RoomSpendContext when the key source is system (the metered, gated path — a spend refusal surfaces as a failed execution result, not a silent skip); runs preview_manifestation then derive_manifestation(derived_by=actor, organized_groups=preview.proposed_ordering) — the echo is verbatim, which is the adjacency guarantee — and returns the new Manifestation's id and counts.

3. Tests

extract_delegation_grant: "you can organize memory" → derive_manifestation, in-project scope (CR-2026-200 ruling 1).
Route outcomes: no_project; denied with the server-composed reply and recognized suggestion; approval_card with action_type="derive_manifestation" and a body that names the counts and contains no numeric price claim.
Dispatcher: stubbed LLM — the stored Manifestation's organized_groups equals the preview's proposed ordering exactly (the adjacency pin); no-key → {"status": "failed"} with a reason naming the key.
Grant rendering: the sentence names "organize this project's memory".
validate_intent_templates covers the new template via OPERATION_RESULT_INTENTS membership (startup + suite).

4. What this CR does not do

No pause-machinery change; no sync→job re-architecture (the room's own gap, room_gate.py:85-87, stands as filed).
No pre-authorized immediacy — per_action_only=True, same slice posture as the other three Tier-1 dispatchers.
No frontend change: the card renders through the existing approval-card surface.
No price estimation — the consent's refusal to name a price IS the CR-2026-189 pattern, not a gap.

DUNIN7 — Done In Seven LLC — Miami, Florida CR-2026-237 — The Manifestation Write Through Conversation — v0.1 — 2026-08-26