Change Request — Create stage door 2: "I'll tell you" (product-native foundation questions) — v0.1

Document: cr-create-stage-door-2-v0_1 Version: v0.1 Date: 2026-06-28 Type: Phase change request — Operator Layer frontend + a thin input adapter. The door-2 piece of the create stage. No new engine extraction/create capability — the compose→commit spine exists and is shared; door 2 feeds it different input. Consumer: Claude Code (executor). Branch base: OL main @ 3f2fca8; engine main @ 5ccc3d7 (engine touched only if the input adapter needs an engine seam — see Step 0; lean is frontend + transcript-synthesis, no new engine route). Depends on door 1 (cr-create-conversation-opening-turn-v0_1) — door 2's composed foundation opens the create conversation via door-1's mount. Governing scoping note: loomworks-create-stage-door-2-scoping-note-v0_1 — superseded in one respect by this CR's grounding (see "What the grounding corrected"). Grounding: the door-2 scoping note + the me_create_engagement.py converged-spine grounding (the create conversation's commit terminal IS the extraction; one spine, shared — engine 5ccc3d7, OL 3f2fca8).

Plain-language summary

Door 2 is for the Operator who knows what the work is and can answer a few questions but hasn't written it down. They answer the foundation questions — what the work is, who it's for, what done looks like, what to get right or avoid, and how it should feel to read — and those answers open the create conversation already populated, where they refine and commit. The key thing this CR establishes: the product already has the whole machine that turns material into a seed (it's how the create conversation commits). Door 2 doesn't rebuild any of that. It just collects answers and feeds them into the machine that already exists. Frontend work plus a thin piece of glue; no new engine capability.

What the grounding corrected (the converged-spine finding)

The door-2 scoping note named extract_seed_fields_from_text as the compose path. The grounding went deeper and found something that reshapes this CR: that skill is not a standalone compose endpoint — it is the commit terminal of the create conversation itself. me_create_engagement.py (POST /me/engagements/create-from-conversation) reads the conversation transcript, runs extract_seed_fields_from_text on it, drafts the seed, inducts, and commits. The conversational create flow reaches it through converse → create_engagement_commit → create_engagement_from_conversation. "Conversation-create" and "extract-create" are one converged spine — there is no second path.

Consequence for door 2 (and the trap this CR must avoid): do NOT scope a new "door-2 compose endpoint." It would rebuild extract_seed_fields_from_text + draft_seed + induct + commit that the spine already provides. The spine's input today is conversation turns. Door 2's only real work is producing input the spine already accepts, from answers — plus the question UI. No new engine extraction/create capability.

What's true today (grounded)

• The compose→commit spine is fully built and shared — text → extract_seed_fields_from_text → draft_seed → induct_seed → convergence check → commit_engagement(_divergent) → re-parent turns + creation assertions + engagement_created_from_assistance event → state="active". With a findings gate (open findings + no override → early-return candidate, no commit — Operator-authority preserved).
• Its input is conversation turns — me_create_engagement.py reads get_recent_turns filtered to the contiguous creation-mode block, composes markdown, extracts. (Two output_path branches — brief inline, discovery_record via Phase 53 /seed/extract — reconverge at the same terminal.)
• No OL surface calls it directly — the create conversation reaches the spine only through converse (ChatView → /operator/converse → create_engagement_commit → create_engagement_from_conversation). Door 2 has no frontend today.
• The voice gap — the generator's questions (the marketing Example Generator's intent door 2 copies) capture four commitments; the voice (voice_of_the_work) is the one door 2 must add. The Operator is right here to answer it.

Decisions (settled by grounding)

1. No new engine capability. Door 2 feeds the existing spine; it does not rebuild compose/extract/draft/induct/commit.
2. Feed via option (a) — produce transcript text from the answers so it flows through the existing path, rather than (b) generalizing the endpoint to accept answers directly. Reuses the converged terminal wholesale; minimal new engine surface. (Confirm at Step 0 — (b) is the fallback if (a)'s transcript synthesis proves lossy.)
3. Ask all five at the door (incl. the voice). The "I'll tell you" Operator is present and articulate; ask the full set (what / who / done / constraints / voice), and let the conversation refine rather than fill.
4. The composed foundation opens the create conversation (door-1's mount, draft-fed branch) — door 2 is not an immediate commit; it seeds the conversation's opening state, where the Operator refines and commits via the existing spine. (See the extract-to-open vs. extract-to-commit seam below.)
5. No credits, no token, no marketing change, no boundary crossing, no pinned model — all withdrawn (the door-2 note's strippings); the Operator is signed in, in-product, and the model is the spine's own (task-appropriate, not specified here).

The extract-to-open vs. extract-to-commit seam (Step-0 load-bearing)

The grounding flagged the real architectural seam: the spine commits straight to active (with the findings gate). But door 2 wants the answers to become the conversation's opening state for refinement, not an immediate commit. Two moments, same core:

• Extract-to-open: a lighter call that composes the foundation from the answers and seeds the create conversation's opening turn (the Operator then refines).
• Extract-to-commit: the existing full spine, at the end, when the Operator commits the refined seed (the conversation's normal create_engagement_commit path — already built).

Step 0 must confirm how to get extract-to-open without triggering commit — likely the answers become the opening turns (synthesized transcript) that door-1's mount presents, and commit happens later through the normal conversational commit (the spine) once refined. The door must NOT drive create_engagement_from_conversation at door-entry (that commits); it drives it at the end, through the conversation, like every other create. Confirm the exact mechanism.

Scope boundary — what this does NOT do

• No new engine extraction/create capability — the spine exists; door 2 feeds it.
• No immediate commit at the door — the answers open the conversation; commit is the conversation's existing Operator-authority terminal.
• No marketing change, no credits/token/boundary — withdrawn machinery; the Example Generator stays untouched on marketing.
• No door 1 or door 3 — door 1 (the opening mount) is its own CR and a dependency; door 3 (document) is its own CR.

The build — steps

Per-step commits, suite green at each, halt-before-push.

Step 0 — inspect before building (no code) — the seam is load-bearing

Confirm against engine 5ccc3d7 / OL 3f2fca8:

1. Branch bases; door 1 built (the draft-fed opening mount is the landing).
2. The extract-to-open vs. extract-to-commit seam (Decision 4 / the seam section). How does material become the create conversation's opening state without committing? Trace: does door-1's opening mount accept seeded opening turns? Can the answers be synthesized into the contiguous creation-mode turn block that get_recent_turns reads, so the existing spine sees them at commit time (the end), while the opening is just those turns presented? This is the crux — confirm before building.
3. Option (a) transcript synthesis — what shape must the answers take to read as creation-mode turns the spine accepts unchanged? (The spine reads get_recent_turns filtered to creation-mode; door 2's answers must land as turns in that block — likely as the Operator's own turns + the Companion's question turns, so the transcript reads naturally.) Confirm (a) is lossless; if not, (b) (a new input branch) is the fallback.
4. Whether any engine seam is needed — lean is frontend-only (synthesize the answer-turns client-side, send through the normal converse path). Confirm whether producing the opening turns needs an engine assist or is purely a frontend composition fed to door-1's mount.
5. The door-2 entry shape — how the Operator picks "I'll tell you" vs. "talk it through" in the create stage (the three-door "doors clearly identified" requirement). And the five-question UI.

Report findings — especially 2 and 3 — then build.

Step 1 — The five-question UI (door-2 entry)

The "I'll tell you" door: a structured question set — what the work is, who it's for, what done looks like, what to get right or avoid (optional), and the voice (how it should feel to read). Plain-terms, in the create-stage surface, clearly distinct from "talk it through" (door 1) per the three-door design. The voice question is the one the marketing generator omits and door 2 adds.

Suite expectation: the question UI renders; the door-2 entry is distinct from door 1; answers are collected.

Step 2 — The answers → opening-state adapter (option (a))

Turn the collected answers into the create conversation's opening state — per the Step-0 seam, synthesize them as the creation-mode opening turns that door-1's mount presents (the Companion's foundation framing + the Operator's answers), so the conversation opens populated with the foundation and the Operator refines from there.

Suite expectation: answers produce the opening state; the conversation opens populated (not the generic greeting, not an immediate commit); the synthesized turns read as a natural creation-mode opening.

Step 3 — Refine + commit through the existing spine

Confirm (test + the live check) that after door-2's opening, the Operator refines in the conversation and commits through the existing create_engagement_commit path — the spine extracts the five commitments from the (now refined) transcript and commits, exactly as a talk-it-through create does. Door 2 changed the opening, not the commit.

Suite expectation: a door-2-opened conversation commits a seed via the existing spine; the committed seed carries the five commitments (incl. the voice the Operator gave); no new commit path was built.

Acceptance

• The "I'll tell you" door works — an Operator picks it, answers the five foundation questions (incl. the voice), and the create conversation opens populated with their foundation, ready to refine.
• No immediate commit — the answers open the conversation; the seed commits through the existing conversational terminal after refinement (Operator-authority).
• No new engine capability — the compose→commit spine is unchanged; door 2 fed it different input (answers-as-opening-turns). Verify the spine code is untouched (or only minimally seamed per Step 0).
• The voice is captured — the one field the marketing generator omits is asked at the door and reaches the committed seed.
• Doors clearly identified — "I'll tell you" is visibly distinct from "talk it through" on the create surface.
• Real data, end-to-end (standing lesson) — verified live: answer the door-2 questions, watch the conversation open populated, refine, commit a real seed with the given commitments. Not a green suite alone.
• Suite green at each step; OL tsc + vocab-wall clean; no new lint debt.
• No imported machinery — confirm: no credits, no token, no marketing change, no new compose endpoint. (The trap-check, made an acceptance criterion.)

What this shares / sets up

• Shares the spine with door 1 (and door 3) — extract_seed_fields_from_text → draft → induct → commit. The create stage is three text inputs to one compose→commit terminal.
• Door 3 follows the same shape — a document's transformed text as the input (via the existing /seed/extract discovery_record branch) + a review surface. Door 2 establishes the answers-to-opening-state adapter; door 3 the document-to-opening-state one. Both feed the same spine.

DUNIN7 — Done In Seven LLC — Miami, Florida Change Request — Create stage door 2: "I'll tell you" (product-native foundation questions) — v0.1 — 2026-06-28 Door 2 collects the five foundation questions (incl. the voice the marketing generator omits) and feeds them as the create conversation's opening state, where the Operator refines and commits through the EXISTING converged compose→commit spine (extract_seed_fields_from_text → draft → induct → commit, which is the create conversation's own terminal). No new engine capability — the grounding found the spine already built and shared; door 2 produces input it already accepts (option (a): answers → opening turns). The load-bearing seam (Step 0): extract-to-OPEN the conversation for refinement, not extract-to-COMMIT at the door. No credits, no token, no marketing change, no pinned model — all withdrawn. Depends on door 1. Base OL 3f2fca8, engine 5ccc3d7.