Loomworks — engagement create stage: three doors to one seed — scoping note — v0.1

Document: loomworks-create-stage-three-doors-scoping-note-v0_1 Version: v0.1 Status: scoping note — precedes one or more CRs. Captures a settled design shape, not a build plan. Grounded in the Example-Generator inspection (loomworks-marketing @ 3328a61), the create-page inspection (the empty create conversation), and the seed-viewer/seed-editor grounding. Several build details are deliberately left to per-CR grounding. Date: 2026-06-28 Origin: Began as "the create page doesn't invite activity" (a screenshot of the deprecated create page — old menu-bar shell). Developed through: the page is abandoned → build create fresh → it should conclude in the generator or the seed → is seed creation a conversation or a generator? → two doors → the resultant seed is official, therefore editable → a third door for the already-documented Operator (PRD). This note preserves that trajectory because the destination only makes sense against the path.

Plain-language summary

Creating an engagement means producing its seed — the foundation document (what the work is, who it's for, the voice, the constraints, what success looks like). Operators arrive in different states, so there should be three clearly-marked ways in, all ending at the same committed seed:

• Talk it through — for when you're still figuring out what the work is. You and the Companion discover it in conversation.
• I'll tell you — for when you know it but haven't written it down. You answer a few structured questions and the system drafts the foundation.
• Here's my specification — for when you've already written it (a PRD, a brief, a statement of work). You hand over your document and the system maps it to the seed format for your review.

All three end in one seed. The moment you commit it, the seed is official — and an official seed can be viewed and revised. Creating, viewing, and editing a seed are one continuous lifecycle, not three separate features.

The two conditions that govern the whole design

The Operator set two non-negotiables, and every part of this note answers to them:

1. The paths in are identified clearly. Three distinct, named doors — never one ambiguous surface that murkily does all three. The Operator always knows which door they're in, because what they bring to each is different (a question, some answers, or a document).
2. The path out is one merged resultant seed. All doors converge on the same five commitments, the same Operator-authority commit, the same prior-preserved versioning. The seed does not remember which door made it — it is the engagement's foundation, full stop. (Provenance threads may record the origin without the seed's identity depending on it.)

The trajectory (preserved — the corrections matter)

This shape was reached by correcting earlier positions, and the rejected paths are part of the record:

• Rejected: patch the existing create page. The screenshot that started this was the deprecated create surface (old horizontal menu bar — Dashboard/Inbox/Library — not the new lens-home chrome). Fixing its opening turn would have invested in an abandoned surface. Superseded by: build create native to the new surface.
• Rejected: "the generator becomes the preferred path." The tempting assumption that generation is the future and conversation the legacy. Corrected by the Operator: many Operators arrive already clear, even already documented — for them the generator's questions are friction (re-typing what they know or have written). Generation serves one state, not all.
• Rejected: two doors (conversation vs. generator). Incomplete — it had no home for the Operator who arrives with a finished specification. Superseded by three doors.
• Rejected: "one finishing room — the conversation — all doors funnel through it." Over-unified. Corrected by the PRD insight: forcing a confident, already-documented Operator through a conversational "let me confirm what I read" treats their finished spec as a rough draft. The finishing step must match the door, not be a single conversational hub.

The destination — three doors, finishing-step matched to door, one resultant seed — is what survived these corrections.

The three doors (each an Operator state and confidence level)

The doors are not three implementations of one act. They serve three genuinely different starting materials and three levels of pre-formed confidence — and the finishing step matches the confidence level.

Door 1 — Talk it through (conversation)

• Operator state: still-forming. "I don't fully know what this is yet."
• Starting material: intent only. The Companion's questions do real discovery work — surfacing the constraint you hadn't named, the success condition you hadn't articulated.
• Finishing step: the conversation is the work. You stay in the conversational finishing room throughout, because the talking is the figuring-out.
• Exists today: yes — the create-engagement conversation (ChatView mode="create-engagement"). But it currently opens empty (a regression — see below), which is the immediate defect.

Door 2 — I'll tell you (the Example Generator)

• Operator state: articulable-but-unstructured. "I know it, I can say it, but I haven't written it down."
• Starting material: spoken/typed answers to a few structured questions.
• Finishing step: light refinement. The generator composes a foundation draft; the Operator refines it and supplies what the questions didn't capture (notably the voice).
• Exists today: yes — the Example Generator (loomworks.doneinseven.com/example-generator). Four questions (work / audience / done / constraints), a server-validated structured foundation-draft JSON capturing 4 of the 5 commitments. But it dead-ends — "persists NOTHING, no engine call, no engagement"; copy/download/print only. The boundary to the product is uncrossed for this feature (though the request-credits page already crosses with the PUBLIC_ENGINE_API_URL idiom — so the pattern is proven).

Door 3 — Here's my specification (document / PRD converter) — NET-NEW

• Operator state: already-documented. "I've written it; here's the document." System designers and technical PMs are fluent in PRDs — a PRD is a native, deliberate, complete artifact to them, not rough input.
• Starting material: an existing document in the Operator's own format (PRD, statement of work, brief, proposal).
• Finishing step: mapping review — NOT a conversation. The system maps the document to the five commitments and presents the mapping for the Operator to confirm or adjust. Forcing a conversational "let me check I understood your spec" would insult finished work. Conversation is available if the document is thin or the mapping surfaces gaps — but it is not imposed. The door flexes to the document's completeness.
• Exists today: no. No document upload on the create path, no extraction-to-commitments mapping, no mapping-review surface. This is the heaviest, newest capability of the three.

The key correction: finishing step matches the door

Earlier in the trajectory the conversation was cast as the single finishing room all doors funnel through. The PRD insight corrected this. The finishing step varies by the Operator's confidence in what they brought:

| Door | Pre-formed confidence | Finishing step | |---|---|---| | Talk it through | low (discovering) | converse (the talking is the work) | | I'll tell you | medium (roughed in) | light refinement + supply the voice | | Here's my specification | high (finished spec) | mapping review; converse only if thin |

All three still converge on one merged resultant seed — the finishing step differs, the destination does not.

What "merged resultant seed" means (Condition 2, precisely)

• Every door produces the same five commitments (what_the_work_is, who_consumes_the_work, voice_of_the_work, constraints, success_conditions).
• Every door concludes at the same Operator-authority commit — the machine assembles material; the Operator approves; the seed is written, prior-preserved (corrections-preserved discipline).
• "Merged" also means the doors are not strictly mutually exclusive where it's natural: a generator draft or a document extraction can flow into a conversation when something is missing (typically the voice), and the resultant seed merges the carried material with the conversational completion. The conversation is the common fallback finishing mode — not mandatory, but always available to complete a thin door-2 or door-3 result.

The lifecycle close: official → viewable → editable

The Operator's closing point: because the resultant seed is official, it is available for editing. This makes create / view / edit one continuous lifecycle of a single object:

• Create (any door → merged seed → Operator commit) — the seed comes into being and becomes official.
• View (the seed viewer — built, verified) — the official seed is read.
• Edit (the conversational seed editor — CR'd) — the official seed is revised; version-bumped; prior preserved.

The same five commitments, three moments: formed → read → revised. The instant a seed is official (committed), it is viewable and editable — no limbo. And the create conversation (door 1) and the edit conversation are the same conversational mechanism (propose → Operator approves → commit → prior-preserved, via the considerations machinery) pointed at a forming seed vs. an existing one. Create writes version 1; edit writes version N+1. This is why "only show what's available" holds across the lifecycle: before a seed is official there is nothing to view or edit (those affordances don't appear); the moment it's official they become available, because now there's something to act on.

The empty-create-conversation regression — dissolves into this design

The create conversation opening empty (no greeting, no priming — the screenshot's bare box) was found to be a frontend wiring gap over a ready engine: the engine's create_engagement_entry template is built to speak first (greet + ask the first question), but ChatView never fires the opening converse call on mount (it only sends from handleSend, which requires a typed message). The old Workshop surface also had a static greeting the rebuild dropped. So the conversation door's "empty" state is a real defect — but it is not a separate bug to fix in isolation. The conversation is the finishing room that all three doors feed; it must handle arriving empty (door 1 — fire the opening greeting), arriving with a generated draft (door 2 — the draft is the opening state), and arriving with a document extraction to review (door 3 — though door 3's primary finish is the mapping-review surface, not the conversation). Fixing the empty open and building door 1's warm start are the same work.

Boundary crossing (doors 2 and 3 touch the marketing→product line)

The Example Generator lives on the marketing domain; the product is the operator app. A door-2 or door-3 flow that carries material into the product crosses that boundary. It is not the first crossing — request-credits.astro already POSTs to the engine via an env-var-gated URL (PUBLIC_ENGINE_API_URL) with a graceful unset-fallback (Phase 51 alpha posture). Any door-2/door-3 crossing should follow that proven idiom, not invent a new mechanism.

The "deliberately not a seed" guard is a design ally

The generator refuses (in code, three layers) to call its output "a seed" — its hardcoded label says the output is "a draft toward the engagement's Foundation Document … made real inside Loomworks, through the create-engagement conversation." This is not an obstacle; it names the exact bridge this design formalizes. The generator already models its own relation to the seed correctly: it produces material; the seed is committed in Loomworks, by the Operator. Doors 2 and 3 both honor this — they carry material across; the commit remains a Loomworks-side, Operator-authority act.

Provenance note (door 3 specifically)

Door 3 is the 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 ("voice = warm, derived from [the uploaded PRD]"). This is provenance doors 1 and 2 don't naturally produce. Whether to thread document-provenance into the seed is a design question for the door-3 CR — flagged, not settled.

Seed alignment

Aligned. The seed is the engagement's foundation; this names three ways to author it, all converging on the seed's committed, versioned, Operator-authority form. "Only show what's available" governs the lifecycle (view/edit appear when the seed is official). Operator-authority governs the commit (machine assembles, Operator approves — no auto-commit on any door). Corrections-preserved governs versioning (every door's commit is version-aware; edit preserves priors). The document door's provenance thread is the trust-axis principle applied to an external source. No apparent conflict with the seed's commitments — this elaborates how a seed is authored, which the seed does not constrain.

Scope boundary / staging (for the CRs, not settled here)

This note captures the shape. The build is large and should stage. A natural ordering (to confirm per-CR):

1. Door 1 finishing room — fix the empty create conversation (fire the engine's opening greeting on mount; one greeting source; keep the create-mode history-skip). Small, fixes the regression, and stands up the finishing room the other doors feed.
2. Door 2 bridge — carry the generator's structured foundation-draft across the boundary (the request-credits idiom) into the create conversation as its opening state; collect the voice in the conversation; commit. The real new-capability for door 2.
3. Door 3 converter — net-new: document upload on the create path, extraction-to-commitments mapping, the mapping-review surface (the door-3 finishing step), optional conversational completion for thin documents, optional source-provenance thread. The heaviest piece; scoped last.

Each stage is its own CR with its own Step-0 grounding. The seed editor (CR'd, dcd25bb) and seed viewer (built) are the lifecycle's view/edit stages and are not part of this note's build — they're the destination this create stage feeds into.

Operator decisions before the CRs

1. Confirm the three-door shape and the two conditions (settled this session — confirm).
2. Confirm finishing-step-matched-to-door (conversation / refinement / mapping-review) — the key correction.
3. The build staging order (lean above: door-1 fix → door-2 bridge → door-3 converter). Confirm or reorder.
4. Door 3: does the mapping-review thread document-provenance into the seed (the trust-axis question)? — can defer to the door-3 CR.
5. Door 2/3 flavor where a result is thin: flow into the conversation to complete (lean) — confirm the conversation is the universal fallback finish.

DUNIN7 — Done In Seven LLC — Miami, Florida Loomworks — engagement create stage: three doors to one seed — scoping note — v0.1 — 2026-06-28 Creating an engagement's seed has three clearly-identified doors matched to the Operator's state: talk it through (conversation, for the still-forming), I'll tell you (the Example Generator, for the articulable), and here's my specification (a net-new PRD/document converter, for the already-documented). The finishing step matches the door — converse / refine / mapping-review — but all three converge on one merged resultant seed, Operator-committed. The moment it's official it is viewable and editable: create, view, and edit are one lifecycle of one object. The empty-create-conversation regression dissolves into door 1's finishing room. Boundary crossings follow the proven request-credits idiom. Build stages: door-1 fix → door-2 bridge → door-3 converter.