Loomworks — create stage door 2: product-native foundation generator — scoping note — v0.1

Document: loomworks-create-stage-door-2-scoping-note-v0_1 Version: v0.1 Status: scoping note — precedes a CR. Supersedes the drafted cr-generator-create-bridge-v0_1, which is withdrawn (it solved an imported problem — see "What this corrects"). Grounded in the create-stage three-door design and the Example-Generator inspection. Date: 2026-06-28 Origin: Door 2 of the three-door create stage ("I'll tell you" — for the Operator who can articulate the work but hasn't written it down). The first draft routed the deployed marketing Example Generator into the product, which dragged in two boundary crossings, a claim-token, and credit machinery. The Operator corrected the framing through a sequence of strippings: leave the generator where it is and copy its intent; no credits; run it the way any AI logic runs in Loomworks; use whatever model is most appropriate for the task. Each stripping removed imported machinery. This note records door 2 at its true, small size.

Plain-language summary

Door 2 is for the Operator who knows what the work is and can answer a few questions about it, 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 the system composes a foundation from the answers, which opens the create conversation. From there they refine it and commit the seed, the same way every door ends. That's all door 2 is: ask the foundation questions, compose a draft, hand it to the conversation. It runs inside the product, for a signed-in Operator, using the same way Loomworks runs any AI task. The marketing Example Generator stays exactly where it is — door 2 copies what it does, not how it's deployed.

What this corrects (the trajectory — preserved, because the strippings are the lesson)

The first door-2 draft (cr-generator-create-bridge-v0_1) is withdrawn. It was not bad work — it correctly traced real seams — but it solved a problem we don't have, created by one wrong assumption: route the deployed marketing generator into the product. That assumption imported, in sequence, machinery that all dissolved once the assumption was dropped:

• Imported: the anonymous→authenticated boundary → a draft made by an anonymous prospect needing to survive sign-in. Dissolved by: "copy the intent, leave the generator on marketing." Door 2 runs for an already-signed-in Operator. No anonymous moment, no boundary.
• Imported: the claim-token → a coat-check ticket to carry the draft across the sign-in gap. Dissolved by: there is no gap. The token only existed to bridge anonymous→authed; remove the boundary, remove the token. (Credits/claim-tokens belong in the credit flow, where there genuinely is an anonymous-to-account gap — not here.)
• Imported: the marketing→product crossing (PUBLIC_ENGINE_API_URL, exposing server-only fields, the request-credits idiom) → getting the marketing artifact's output into the product. Dissolved by: the intent runs in the product; nothing crosses.
• Imported: the Cloudflare/Haiku implementation → marketing runs its generator as a static-site function on Haiku. Dissolved by: the product has its own AI-logic methodology; door 2 uses that, not a transplant of marketing's infrastructure.
• Imported: a pinned model → almost wrote "uses Haiku" into the scope. Dissolved by: the model is whatever is most appropriate for the task, chosen by the same mechanism Loomworks uses for any AI logic. Door 2 names a task, not a model.

The lesson, recorded: we learn from work that has been done; that it does not match exactly what we want now does not mean it was not good. The Example Generator taught us the right questions, the honest-draft posture, the structured-output discipline. Door 2 copies that intent. It does not import the generator's deployment, infrastructure, or model choice — those were answers to marketing's problem, not ours.

What door 2 is (at its true size)

A product-native foundation generator: inside the create stage, for a signed-in Operator who chooses "I'll tell you," ask the foundation questions, compose a foundation from the answers, hand it to the create conversation as its opening state.

• Input: the foundation questions, asked of the Operator in the create stage. The Example Generator's set, plus the one it misses — 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 (the voice). (The marketing generator never asks the voice; door 2 does, because the seed requires it and the Operator is right here to answer.)
• Logic: compose a structured foundation from the answers — the Example Generator's proven elicit-and-compose intent, run on Loomworks's established AI-logic methodology (the same way the Companion composes, the same way any AI task runs in the product).
• Model: whatever is most appropriate for the task, selected by the product's existing model-selection mechanism. Door 2 specifies a task, not a model. (Naming a model would import marketing's choice.)
• Output: the composed foundation opens the create conversation — door-1's mount, fed the composed draft instead of a blank greeting.
• Then: the conversation refines and the Operator commits the seed, the same Operator-authority path every door ends on. (Because the voice is asked here, door 2 may produce a more-complete foundation than the marketing generator — possibly all five commitments — but the commit still happens in the conversation, Operator-approved.)

What door 2 is NOT (the imported machinery, named so it stays out)

• No credits, no claim-token, no anonymous→authed bridge — there is no anonymous moment; the Operator is signed in throughout.
• No marketing→product crossing, no PUBLIC_ENGINE_API_URL, no marketing-side change — the Example Generator is untouched on marketing, doing its prospect-facing demo job.
• No bespoke generator subsystem — it's an application of the product's existing AI-logic methodology, not new infrastructure.
• No pinned model — task-appropriate, chosen by the existing mechanism.

Relationship to the marketing Example Generator

Two instances of one intent at two locations, sharing intent and nothing else:

• Marketing Example Generator — anonymous, prospect-facing, dead-ends honestly ("made real inside Loomworks"), runs on its own static-site infrastructure. Unchanged. Its job is to show prospects what Loomworks does.
• Door 2 (product) — authenticated Operator, create-stage, composes a foundation that becomes a real engagement through the conversation. Runs on the product's AI-logic methodology.

They are siblings, not a pipeline. No wire between them. The marketing one taught door 2 the questions; door 2 asks them where they can become a seed.

Seed alignment

Aligned. Door 2 elicits the seed's commitments and hands them to the conversation, which commits the seed (Operator-authority, corrections-preserved). Because door 2 asks the voice (which the marketing generator omits), it can produce a complete-enough foundation — but the commit remains the conversation's Operator-approved act, never an auto-commit. No boundary, no anonymous origin, so no provenance-across-identity concern (unlike door 3's external document). It is the seed's own authoring, in the product, by the Operator.

Open questions for the CR (small)

1. Where door 2's foundation-questions surface — as a distinct mode the Operator picks in the create stage ("talk it through" vs. "I'll tell you"), or as a structured-input affordance within the create surface. (The three-door design says the doors are clearly identified; confirm the door-2 entry's shape at CR grounding.)
2. How the composed foundation feeds the conversation — door-1's mount, draft-fed branch (the same hook door 1 establishes for an opening turn). Confirm the create-conversation opening accepts a composed-foundation context, same as it will for door 3.
3. The AI-logic methodology's actual shape — the CR grounds which established path composes the foundation (the converse/responder path the Companion uses, or a dedicated compose call), so door 2 plugs into the real methodology rather than a described one. This is the only real grounding the CR needs — everything else is settled by this note.
4. Voice handling — door 2 asks the voice (the marketing gap); confirm whether door 2 collects all five at the door, or collects four and the voice opens the conversation. Lean: ask all five at the door (the Operator is here; it's the "I'll tell you" door); the conversation refines rather than fills.

Dependencies / sequencing

• Depends on door 1 (the create-conversation opening mount) — door 2 feeds that mount a composed foundation instead of a blank greeting. Build door 1 first.
• Smaller than originally scoped — with the boundary-crossing machinery gone, door 2 is: a foundation-question elicitation + a compose-via-existing-AI-logic call + the draft-fed opening (shared with door 1). No marketing change, no engine boundary work, no token mechanism.
• Sets up door 3 through the same lens — door 3 ("here's my specification") should be re-checked for the same trap (am I importing machinery, or applying the product's own methodology to "map a document to a foundation"?). The door-3 re-scope follows.

DUNIN7 — Done In Seven LLC — Miami, Florida Loomworks — create stage door 2: product-native foundation generator — scoping note — v0.1 — 2026-06-28 Door 2 ("I'll tell you") is the Example Generator's intent run product-native: a signed-in Operator answers the foundation questions (including the voice the marketing generator omits), the product's own AI-logic methodology composes a foundation with the model most appropriate for the task, and it opens the create conversation. No credits, no token, no anonymous→authed bridge, no marketing→product crossing, no pinned model — all of that was machinery imported by the withdrawn bridge CR's wrong assumption (route the deployed generator). The marketing Example Generator stays untouched; door 2 copies its intent, not its deployment. Depends on door 1.