Loomworks — create stage door 3: document to foundation (true size) — scoping note — v0.1

Document: loomworks-create-stage-door-3-scoping-note-v0_1 Version: v0.1 Status: scoping note — precedes a CR. Re-scopes door 3 from the "heaviest net-new capability" framing in the three-door note (loomworks-create-stage-three-doors-scoping-note-v0_1) down to its true size, applying the door-2 machinery-import discipline. Grounded in the door-3 inspection (the existing upload pathway, extract_seed_fields_from_text, the reusable review patterns — engine 5ccc3d7, OL 3f2fca8). Date: 2026-06-28 Origin: Door 3 of the create stage ("here's my specification" — for the already-documented Operator, e.g. a system designer fluent in PRDs). The three-door note scoped it as "the heaviest, newest capability — document upload, extraction, mapping-review, a marketing→product boundary, provenance threading." That framing carried the same route-external-things-through-pipelines fingerprints that bloated door 2. Re-checked through the door-2 lens — am I importing machinery, or applying the product's own methodology to "map a document to a foundation"? — door 3 collapses to a small piece. The product already has every engine part, including the document-text→five-commitments skill.

Plain-language summary

Door 3 is for the Operator who has already written their specification — a PRD, a brief, a statement of work — and just 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. They brought finished work, so they review a mapping rather than answer questions. Then it opens the create conversation for any gaps and the Operator commits the seed. 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.

The big finding: all three doors share one compose path

The door-3 grounding surfaced the deepest unification of the create stage, and it reframes everything:

extract_seed_fields_from_text(document_text: str, …) (seed_extraction_core.py:189, model claude-sonnet-4-6) is a single AI call that takes plain text and returns the structured five commitments. It is door 2's compose path AND door 3's compose path — the same skill, different text input:

• Door 1 (talk it through) — a conversation produces text → the five commitments.
• Door 2 (I'll tell you) — structured answers produce text → extract_seed_fields_from_text → the five commitments.
• Door 3 (here's my specification) — a document produces text (via the upload pathway's transformation) → extract_seed_fields_from_text → the five commitments.

The three doors are three text inputs to one extraction skill. They are not three capabilities — they are three adapters to one compose path that already exists. The create stage has a spine, and the product already implements it. This also resolves door-2's open-question #3 (which established AI-logic path composes the foundation): it is extract_seed_fields_from_text. Door 2 can go to CR on this finding.

What this corrects (the door-2 discipline applied)

The three-door note's door-3 framing imported machinery that does not apply:

• Imported: "a marketing→product boundary." Door 3 has no marketing origin — the PRD Operator is signed in, in the product, uploading their own document. The upload endpoint requires get_resolved_actor (auth + engagement membership, uploads.py:447); no anonymous path. No credits, no claim-token, no anonymous→authed crossing — the door-2 boundary machinery simply never applied to door 3. (Stated explicitly so the trap does not recur.)
• Imported: "a bespoke document-extraction subsystem." The product already extracts the five commitments from document text — extract_seed_fields_from_text, which takes a string, not a file. The upload pathway's transformed_content_inline is exactly that string. A document body slots straight in, no adapter. "Extract the commitments from a document" = the existing compose path pointed at a document input, not a new subsystem.
• Imported: "the heaviest, newest capability." It is the lightest of the three doors' new work, not the heaviest — almost entirely assembly of existing pieces.

The lesson (same as door 2): we learn from work that has been done. The upload pathway, the extraction skill, the seed viewer's display, the held-card confirm — all already built, for other reasons, all reused here because they fit the intent, not contorted to fit. Door 3 imports no machinery; it applies the product's own methodology to a document input.

What door 3 is (at its true size)

A signed-in Operator with a document: upload → extract the five commitments → review the mapping (confirm/adjust) → open the conversation for gaps → commit.

• Input: the Operator's document, uploaded in the create stage (their PRD/brief/SOW).
• Read: the existing upload pathway transforms the document to text (execute_upload → transformed_content_inline; PDF/text/OCR skills already run).
• Extract: extract_seed_fields_from_text (the shared compose path) maps the document text to the five commitments + gaps. Model: most appropriate for the task (the skill uses claude-sonnet-4-6 today; the CR inherits the product's model choice, does not pin one).
• Review (door 3's distinguishing feature): the Operator reviews the extracted commitments and confirms or adjusts each — because they brought finished work, they review a mapping rather than converse. This is the door-3-specific posture (the three-door note's "finishing step matches the door": door 3 finishes by mapping-review, not conversation).
• Gaps → conversation: if the document is thin or the extraction surfaces a gap (the voice is the usual one), the conversation is the fallback finishing room (door-1's opening mount) — but for a complete PRD, review-and-commit may need no conversation at all.
• Commit: the reviewed commitments commit the seed via the conversation's Operator-authority path. Corrections-preserved.

Reuse vs. net-new (from the grounding)

Reused (existing, fits the intent):

• Upload that reads + transforms document contents, authenticated, in-product (uploads.py/executor.py).
• Document-text → five commitments (extract_seed_fields_from_text — the shared compose path).
• The five-commitment schema (DraftSeedRequest/Seed).
• Review-surface display — SeedViewer's Field component + the five-commitment render (incl. constraints-as-list) — the viewer we just built.
• Review-surface confirm — the held-card Confirm/Dismiss idiom (MemoryRoom/WorkCard).
• Inline-card render below a turn (DraftSpecification/UploadResultCard) — the review lands inline, no new overlay machinery.
• Conversation fallback for a thin document — door-1's create-mode opening hook.

Genuine net-new (small):

• An editable review field — no existing component lets the Operator adjust an extracted value inline before confirming (the seed viewer displays read-only; the held card confirms but doesn't field-edit). This editable affordance is door 3's one real new build, and it is small.
• Create-path upload — minor: re-gate the existing upload button, today gated behind projectId (ChatView.tsx:581-586), which create mode lacks.
• The glue — transformed_content → extract_seed_fields_from_text → review surface. Small orchestration.

The Step-0 imperative — door 3 may be PARTLY BUILT

me_create_engagement.py already calls extract_seed_fields_from_text. So a document-to-create path may already exist in some form. The CR's Step 0 MUST run down exactly what that route does before scoping any new work — or the CR will re-import what is already there, the exact trap this whole re-scoping exercise is guarding against. Ground on the existing route first; scope only the genuine gap (likely just the editable-review component + create-path upload + glue, but confirm against the real route, not this note's assumption).

Provenance (flagged, not built)

Door 3 is the one door that brings a real external source (the uploaded document). Under the trust-axis = tie-to-source principle, the resultant seed's commitments could carry an outward thread to the source document. This is an enhancement, not v1 core — named for the CR to consider, deferred by default. (The upload pathway already writes UploadEventReceived with provenance, so the source event exists to thread from if wanted.)

Open questions for the CR

1. What me_create_engagement.py already does (the Step-0 imperative) — the load-bearing unknown. Door 3 may be a small completion, not a build.
2. The editable-review component shape — extends SeedViewer's Field to be editable, or a new sibling? Lean: extend/sibling the viewer's display so the read and edit surfaces share vocabulary.
3. Where the upload affordance sits on the create surface — the door-3 entry ("here's my specification") and how it presents alongside door 1 (talk) and door 2 (tell). The three-door note's "doors clearly identified" governs.
4. Voice handling — a PRD may or may not encode the voice; the review surface shows it as extracted-or-gap; a gap drops to the conversation. Confirm the gap→conversation handoff is the same door-1 hook.

Dependencies / sequencing

• Depends on door 1 (the conversation fallback for gaps) and shares door 2's compose path (extract_seed_fields_from_text).
• Smaller than the three-door note implied — not the heaviest; almost entirely assembly. The genuine new work is one editable-review component + create-path upload re-gating + small glue, pending the Step-0 finding on the existing route.
• The create stage, re-understood: three doors = three text inputs (conversation / structured answers / document) to one compose path (extract_seed_fields_from_text) → the five commitments → the create conversation → the Operator-committed seed. The spine exists; the doors are adapters. This is the architecture the three-door note groped toward, now confirmed against the real code.

DUNIN7 — Done In Seven LLC — Miami, Florida Loomworks — create stage door 3: document to foundation (true size) — scoping note — v0.1 — 2026-06-28 Door 3 ("here's my specification") re-scoped from "heaviest net-new capability" to its true small size: a signed-in Operator uploads a document, the existing upload pathway transforms it to text, the existing extract_seed_fields_from_text skill (door 2's compose path too) maps it to the five commitments, the Operator reviews-and-adjusts the mapping (reusing SeedViewer's display + the held-card confirm), gaps drop to the conversation, the Operator commits. Genuine net-new is one editable-review component + create-path upload re-gating + small glue. No marketing boundary, no bespoke subsystem. The big finding: all three doors are text inputs to ONE compose path — the create-stage spine already exists. Step 0 imperative: me_create_engagement.py already calls the extraction skill — door 3 may be partly built; ground the real route before scoping.