Change Request — Create stage door 3: "here's my specification" (document to foundation) — v0.1

Document: cr-create-stage-door-3-v0_1 Version: v0.1 Date: 2026-06-28 Type: Phase change request — Operator Layer frontend + small glue. The door-3 piece of the create stage. No new engine extraction/create capability — the document→commitments→commit spine exists (Phase 53 /seed/extract + the shared compose→commit terminal); door 3 feeds it the Operator's document and adds a review surface. Consumer: Claude Code (executor). Branch base: OL main @ 3f2fca8; engine main @ 5ccc3d7 (engine touched only if Step 0 finds a gap in the existing document path — lean is reuse, no new engine route). Depends on door 1 (the conversation as the fallback finishing room for gaps) and shares door 2's spine (extract_seed_fields_from_text → draft → induct → commit). Build after door 1. Governing scoping note: loomworks-create-stage-door-3-scoping-note-v0_1. Grounding: the door-3 inspection (the existing upload pathway, extract_seed_fields_from_text, the reusable review patterns) + the me_create_engagement.py converged-spine grounding (one shared spine; discovery_record branch already uploads markdown → Phase 53 /seed/extract → extract → draft → induct) — engine 5ccc3d7, OL 3f2fca8.

Plain-language summary

Door 3 is for the Operator who has already written their specification — a PRD, a brief, a statement of work — and wants it mapped to the Loomworks foundation, not talked through. They upload their document, the system reads it and extracts the five commitments (what the work is, who it's for, the voice, the constraints, what success looks like), and shows the mapping for the Operator to confirm or adjust each one — because they brought finished work, they review a mapping rather than answer questions. Then it opens the create conversation for any gaps and the Operator commits. The product already has the upload that reads documents and the AI logic that extracts the commitments — so this is mostly assembling existing pieces, plus one small new thing: a way to edit an extracted value before confirming it.

What's true today (grounded) — door 3 is close to already-built

• The document→commitments→commit path exists. The me_create_engagement.py discovery_record branch uploads composed markdown via the upload pathway, then delegates to Phase 53 /seed/extract, which calls extract_seed_fields_from_text (document text → the five commitments) → draft_seed → induct — reaching the same shared commit terminal as the conversation. The engine already extracts a seed from an uploaded document. Door 3's job is to feed it the Operator's document instead of the composed conversation, plus a review surface.
• The upload pathway reads document contents, authenticated, in-product. POST /engagements/{id}/uploads (uploads.py:721, auth get_resolved_actor) runs transformation skills (PDF/text/OCR) → transformed_content_inline (a string). No anonymous path, no marketing origin — the PRD Operator is signed in, uploading their own document.
• The extraction takes a string, not a file — extract_seed_fields_from_text(document_text: str, …). The upload's transformed_content_inline is exactly that string. A document body slots in, no adapter.
• Reusable review patterns exist — SeedViewer's Field component + the five-commitment render (the viewer built this session); the held-card Confirm/Dismiss idiom (MemoryRoom/WorkCard); inline-card render below a turn (DraftSpecification/UploadResultCard).
• The one genuine UI gap — no existing component lets the Operator edit an extracted field value inline before confirming (the viewer displays read-only; the held card confirms but doesn't field-edit). This editable-review affordance is door 3's one real new build, and it is small.
• Create-path upload is gated off — the OL upload button is behind projectId (ChatView.tsx:581-586), which create mode lacks. Re-gating for the create path is minor.

What the grounding corrected / confirmed (the converged-spine + don't-rebuild)

Same finding as door 2: there is one shared compose→commit spine, and the document path already reaches it (discovery_record → /seed/extract). Do NOT scope a "door-3 document-to-seed subsystem" — it would rebuild extract_seed_fields_from_text + draft_seed + induct + commit that Phase 53 and the spine already provide. Door 3's real work is: get the Operator's document to the existing extraction, review the result, and feed the reviewed commitments to the conversation/commit. No new engine extraction capability.

Decisions (settled by grounding)

1. No new engine capability. Door 3 feeds the existing document-extraction path; it does not rebuild it.
2. Reuse the existing document path — the Operator's uploaded document's transformed_content_inline feeds extract_seed_fields_from_text (via the discovery_record//seed/extract mechanism the spine already uses), instead of the composed conversation transcript.
3. The review surface is the door-3 finishing step — the Operator reviews and adjusts the extracted commitments (confirm/adjust), because they brought finished work; this is "finishing step matches the door" (door 3 finishes by mapping-review, not conversation). Built from SeedViewer's display + the held-card confirm + the one net-new editable field.
4. Gaps drop to the conversation — if the document is thin or the extraction surfaces a gap (the voice is the usual one), door-1's opening mount is the fallback finishing room. For a complete PRD, review-and-commit may need no conversation.
5. Extract-to-open vs. extract-to-commit (same seam as door 2) — the extraction opens the review surface (and, on confirm, can open the conversation for gaps); commit is the existing Operator-authority terminal after review/refinement, not an immediate commit at upload.
6. No marketing origin, no boundary, no credits/token — the Operator is signed in, in-product, uploading their own document.

The Step-0 imperative — door 3 may be PARTLY BUILT (ground the existing path first)

me_create_engagement.py's discovery_record branch and Phase 53 /seed/extract already do document→extract→draft→induct. Step 0 MUST trace exactly what these do before scoping new work — door 3 may be largely "wire the Operator's document into an existing path + a review surface," not a build. Scope only the genuine gap against the real path; do not re-import what exists.

The build — steps

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

Step 0 — inspect before building (no code) — ground the existing document path

Confirm against engine 5ccc3d7 / OL 3f2fca8:

1. Branch bases; door 1 built (the conversation fallback for gaps).
2. The existing document-extraction path (the imperative). Trace me_create_engagement.py's discovery_record branch + Phase 53 /seed/extract end to end: what it takes (a file? an uploaded event id? the transformed_content_inline?), what it returns (the extracted commitments? a draft? a committed seed?), and whether it commits or just extracts. This decides how much of door 3 exists. If /seed/extract returns the extracted commitments without committing, that IS door 3's extract-to-review step — reuse it directly.
3. The upload → extraction wiring — how does transformed_content_inline reach extract_seed_fields_from_text today (in the discovery_record branch)? Door 3 feeds the Operator's uploaded document's transformed text where the composed-conversation markdown goes today. Confirm the seam.
4. Create-path upload — re-gating the existing upload button (ChatView.tsx:581-586, behind projectId) for the create surface. Confirm what create-mode needs to accept an upload (it has no projectId/engagement yet — does the upload pathway need an engagement to attach to, and if so, is a candidate engagement created first?). This is a real seam — the upload pathway attaches to an engagement; create mode has none yet. Confirm how a pre-engagement document upload works (a candidate engagement? a create-scoped upload?).
5. The review surface — SeedViewer's Field (display), the held-card confirm idiom, and the net-new editable-field component. Confirm the inline-render seat (below a turn, per DraftSpecification/UploadResultCard).

Report findings — especially 2 (what the existing path does) and 4 (pre-engagement upload) — then build.

Step 1 — Create-path document upload

Re-gate / extend the upload affordance for the create surface (per Step-0.4 — including how a pre-engagement upload attaches, e.g. to a candidate engagement). The Operator uploads their specification document; the existing pathway transforms it to text.

Suite expectation: the create surface accepts a document upload; the document is transformed to text via the existing pathway.

Step 2 — Document text → extraction → review surface

Feed the uploaded document's transformed_content_inline to the existing extraction (extract_seed_fields_from_text via the /seed/extract/discovery_record mechanism per Step-0.2/0.3 — reuse, don't rebuild). Render the extracted five commitments in the review surface: SeedViewer's Field display + per-field confirm/adjust (the held-card confirm idiom + the net-new editable-field component). The Operator reviews and adjusts each commitment.

Suite expectation: an uploaded document is extracted to the five commitments via the existing path; the review surface renders them; the Operator can confirm or edit each field.

Step 3 — The editable-review field (the one net-new component)

The small new OL component: an extracted commitment value the Operator can edit inline before confirming (extends/siblings SeedViewer's Field so read and edit share vocabulary). Constraints-as-list editing per the viewer's list idiom.

Suite expectation: a field renders editable; an edit updates the value; confirm captures the adjusted value.

Step 4 — Review → commit (gaps drop to conversation)

The reviewed-and-adjusted commitments commit the seed through the existing Operator-authority terminal (the spine). If the document was thin / a commitment is a gap (the voice especially), drop to the create conversation (door-1's mount) to fill it before commit. For a complete PRD, review→commit directly.

Suite expectation: a reviewed document commits a seed via the existing spine carrying the (possibly adjusted) commitments; a gap drops to the conversation; no new commit path was built.

Acceptance

• The "here's my specification" door works — an Operator picks it, uploads their document, sees the five commitments extracted, reviews and adjusts the mapping, and commits — reviewing finished work rather than conversing.
• No new engine capability — the document-extraction and commit spine is unchanged; door 3 fed it the Operator's document and added a review surface. Verify the extraction/spine code is untouched (or only minimally seamed per Step 0).
• The review-not-converse posture — door 3 finishes by mapping-review; the conversation is only the fallback for gaps. (The PRD Operator's finished work is honored — not forced through a discovery conversation.)
• Doors clearly identified — "here's my specification" is visibly distinct from "talk it through" (door 1) and "I'll tell you" (door 2).
• Gaps handled honestly — a missing commitment (e.g. the voice, absent from many PRDs) drops to the conversation, not a fabricated value.
• Real data, end-to-end (standing lesson) — verified live with a real document: upload a PRD, watch the commitments extract, adjust one, commit a real seed. Not a green suite alone.
• Suite green at each step; OL tsc + vocab-wall clean; no new lint debt.
• No imported machinery — confirm: no marketing origin, no boundary, no credits/token, no new extraction subsystem. (Trap-check as acceptance.)

Provenance (flagged, not built)

Door 3 brings a real external source (the uploaded document). Under trust-axis = tie-to-source, the seed's commitments could thread an outward provenance link to the source document (the upload pathway already writes UploadEventReceived with provenance — the source event exists to thread from). An enhancement, not v1 core — named, deferred.

What this completes

• The create-stage three-door set — door 1 (conversation opening), door 2 (foundation questions), door 3 (document) — three text inputs to one shared compose→commit spine. Door 3 is the lightest in genuinely-new work (almost all reuse + one small editable component), once Step 0 confirms how much the existing discovery_record//seed/extract path already provides.

DUNIN7 — Done In Seven LLC — Miami, Florida Change Request — Create stage door 3: "here's my specification" (document to foundation) — v0.1 — 2026-06-28 Door 3 uploads the Operator's specification document, feeds its transformed text to the EXISTING document-extraction path (Phase 53 /seed/extract → extract_seed_fields_from_text → the shared commit spine — already built), and renders the five extracted commitments in a review surface (SeedViewer display + held-card confirm + one net-new editable-field component) the Operator confirms or adjusts — reviewing finished work rather than conversing. Gaps drop to the conversation; commit is the existing Operator-authority terminal. No new engine capability — the document→seed path exists. Step 0 imperative: the discovery_record / /seed/extract path may already provide most of this — ground it before scoping; and confirm pre-engagement upload (create mode has no engagement to attach to yet). Depends on door 1. Base OL 3f2fca8, engine 5ccc3d7.