CR-2026-236 — Register the Shape-Confirmed Dispatch Hook — 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-79 (standing-notes/dunin7-build-list-v1_07), rank 1 of the completion program's Wave 1. Decision W-1 ruled on the completion-program decision sheet: "Confirm names its outputs before the press and enqueues exactly those." Cites: the B-8 slice-two scoping read (2026-08-10, recorded in B-79's entry); CR-2026-021 v0.1 Step 9 (the hook's own CR); CR-2026-163 (the surface's consequence line); CR-2026-225 (the lifespan-registration precedent — and the pattern this CR refuses to repeat).

Plain-language summary

Confirming a shape is supposed to start production of everything declared downstream of it. The machinery for that exists, is tested, and is correct — and has never once run in production, because the one line that switches it on was only ever written inside tests.

The surface already does its half. Since CR-2026-163, the Confirm control names the output types a confirmation maps to, before the press, in words carefully chosen to match what the engine's own selector walks. The surface was built to a behavior the engine does not perform: its comment says the engine "fires a post-append hook on confirmation that enqueues production," and that sentence is false today. This CR makes that sentence true — one registration call at startup, plus the test whose absence is how the gap survived.

1. What is true today — Step 0, read at 2f41aa7

1. The hook is complete and correct. shape_confirmed_post_hook (engagement/shape_confirmed_dispatch.py) guards on event-kind, guards re-entry via ContextVar, no-ops silently for engagements with no RenderDispatchAgent (rendering not adopted), warns-and-skips on a malformed non-confirmed payload, and walks dispatch_for_shape_confirmed — one queued render_jobs row per active DeclaredRenderType matching the shape's type that has a registered specialist. Specialist-less matches are skipped and surfaced via GET /renders/candidates (§12.2). Registration (register_shape_confirmed_dispatch_hook) is idempotent by registry-membership check.
2. Nothing in src/ or scripts/ calls the registrar. Only tests do — test_render_pipeline_acceptance.py and three siblings, which register it explicitly and cover the full Memory → Shape → Render chain. Re-verified by grep at 2f41aa7.
3. The lifespan registers everything around it and not it. Materializers, companion-room dispatchers, spend-pause dispatchers, shaping bootstrap, render-specialist bootstrap, and — since CR-2026-225 — the embedding-dispatch post-append hook, which registers against the same registry twenty lines from where this hook should be.
4. The surface's naming half is already shipped. ShapingRoom.tsx renders shape-confirm-consequence before the press; shape.ts's outputTypesForShape mirrors the engine selector (active DRTs matching the shape's type) and its wording is deliberately an upper bound: "naming the types is supported by the data, counting the results is not" — which is exactly right, because the engine skips specialist-less matches. No frontend change is needed or made.
5. How the gap survived: the hook's behavior is thoroughly tested — with manual registration. No test pins that the application registers it. CR-2026-225 added its hook to the lifespan the same way and also left registration untested; it happened to be written correctly. The defect class is "registration exists only where tests put it," and the missing test is the half of this CR that prevents recurrence.

2. The ruled meaning of "confirm", and how this CR satisfies it

W-1: confirm names its outputs before the press and enqueues exactly those.

• Names before the press: already true (CR-2026-163, §1.4).
• Enqueues exactly those: true by construction once the hook is registered, because the surface's naming and the hook's walk read the same selector semantics — active declared render-types whose source shape-type matches. The one asymmetry — specialist-less types are named (as types) but not enqueued — is already inside the surface's chosen wording, and the skip is visible at the candidates endpoint. This CR does not narrow the naming to specialist-backed types; that would require exposing specialist registration to the surface, which CR-2026-163 considered and declined, and no decision has reopened it.

3. The change

src/loomworks/api/app.py — in the lifespan, immediately after the render-specialist bootstrap block (the hook's per-event lookup resolves the dispatch agents that bootstrap registers): call register_shape_confirmed_dispatch_hook(), with a comment naming B-79 and the two sibling registrars deliberately not registered:

• register_shape_produced_dispatch_hook — auto-opens confirmation considerations and fires drift checks; the confirm/retire routes already open their own consideration, and switching auto-open on is a behavioral decision nobody has ruled.
• register_drift_dispatch_hook — dispatches LLM drift agents on every append event; registering it is a spend and behavior change far outside W-1's scope.

tests/conftest.py — one entry appended to the lifespan-substitute registry comment, recording that this hook is deliberately not substituted: tests own post-append hook state explicitly (the established register/unregister-in-teardown pattern), and substituting it would silently enqueue render jobs in any test that registers a dispatch agent for other reasons.

New test — tests/test_cr_2026_236_confirm_dispatch_registration.py:

1. The registration pin: parse src/loomworks/api/app.py with ast and assert a call to register_shape_confirmed_dispatch_hook exists. This is the test whose absence let B-79 live: the property that failed was precisely "no call site in the application," and the pin is on that property, not on behavior (behavior is already covered by the acceptance suite). Observed failing before the fix.
2. Idempotence: registering twice leaves exactly one instance in the registry (guards a lifespan re-run and the test/app double-registration overlap).

Nothing else changes. No migration, no schema, no frontend, no new endpoint.

4. What this changes in production, stated because the deploy carries it

From the first restart carrying this CR, confirming a shape on any engagement that has (a) an active declared render-type for that shape's type and (b) a registered specialist for it will enqueue and dispatch render production automatically, spending against that engagement's key, with trigger="declared_auto_on_shape_confirmed" and the §12.3 system actor as triggered_by. Engagements without rendering wired are untouched (silent no-op). This is the ruled behavior, not a side effect — but it is a live-behavior change and belongs named in the deploy request.

5. What this CR does not do

• Does not register the produced/drift hooks (§3 — their own decisions).
• Does not change the naming surface or expose specialist registration.
• Does not touch Q-7 (conversational confirm — deferred until this has shipped and been walked, per the sheet's F-2).
• Does not address B-114 (agent-executor shapes vs grammar completeness), which this CR's Step 0 confirmed is on the Wave-1 walk path — reported separately to the wave record.

DUNIN7 — Done In Seven LLC — Miami, Florida CR-2026-236 — Register the Shape-Confirmed Dispatch Hook — v0.1 — 2026-08-26