Loomworks — Stage 3 (representatives, content, consequences) — Scoping handoff — v0.2

Version. 0.2 Date. 2026-07-19 Author. Claude.ai, on Operator direction. Status. Scoping handoff. Orients a fresh chat for Stage 3 scoping. Supersedes v0.1 for orientation; v0.1 is preserved as the pre-close draft. Reads with. The Stage 2 completion report (loomworks-record/completion-records/, c79dc08), the security incident record (loomworks-record/security/), loomworks-stage-2-build-brief-v0_2, loomworks-dunin7-perimeter-session-handoff-v0_4, CR-2026-152 (v0.26 in the record).

Change from v0.1

v0.1 was drafted while Stage 2 was still closing. Stage 2 is now closed and pushed. This version folds in: the entry condition being met, the authentication-bypass incident and its three follow-ons, the pending display-name rename, and an inbound second tool (FORAY Integration Example Generator) the Operator has named.

Plain-language summary

Stage 1 built the door. Stage 2 moved the sales generator inside — metered, capped, gated at representative standing, reachable from the surface the Operator lands on, proven live on a real passkey session. Stage 3 lets people in and improves what they find: provision identities for Aldous, Warwick, and test users; advance the generator content past the v0.23 freeze; land the consequences of representatives existing; and close the config-posture gap the Stage 2 incident exposed.

Entry condition — MET

Stage 2 closed in the record: five gated routes on the job pattern, per-principal metering, runaway ceiling, tools affordance reachable from the arrival surface, live UI proof on a production-posture passkey session, completion report and security incident filed and pushed. All four repos in sync (engine 2a0cf71, OL fbc576e, record c79dc08, marketing 1735b6f). The fresh chat verifies this against loomworks-record before scoping — it is already true, so this is a confirmation, not a blocker.

First-up small items (do these before the workstreams)

Display-name rename (Operator-directed, "soon"). The tools card reads "Sales perspective generator." Rename to "Loomworks Sales Perspective Generator" — subject-prefix pattern (the prefix names the product the tool's perspectives serve), matching the inbound "FORAY Integration Example Generator." Display-string only: the card title in the tools registry / strings.ts. Does not touch route paths, the tool key in metering rows (sales.analyze etc. — internal identifiers, renaming breaks parity with existing usage rows), or the gate. A one-line change plus a test; no Step-0 needed.

Inbound: second tool (Operator-named, scope in Stage 3)

FORAY Integration Example Generator. A second perimeter tool, parallel to the sales generator. Not yet built. When scoped, it inherits the whole Stage 2 pattern for free — the job transport, the representative gate, the metering, the ceiling, the tools menu, the sibling key resolver — because that pattern is now the road every such tool runs on. What it needs of its own: its content (prompts, validators, budgets) and its parity discipline (mechanical extraction, hash-pinning, differential testing) exactly as the sales tool got. Naming pattern is settled by the rename above: subject-prefix. Treat it as a content-and-parity effort on a proven substrate, not a new architecture.

Workstream 1 — People (the core of Stage 3)

Provision representative identities: Aldous (Miami/London), Warwick Halcrow (Sydney), and test users.

The open scoping question, and it is the big one: enrollment. Sign-in is passkey-based; identity is the system UUID; there is no email-based identity or recovery, by seed commitment. Today the only enrolled person is the Operator. Aldous and Warwick are remote. The fresh chat's first job is a Step-0 inspection: what enrollment paths exist in the engine and Stele v0.4.0 today (invitation flow? add_passkey ceremony reachability? anything from Phase 48's operator sign-in work?), and what the gap is between what exists and "a person in Sydney enrolls a passkey against app.dunin7.com without the Operator's hands on their device." The Stele Phase 7 material (CR-2026-116, the ~100-line add_passkey ceremony lift) is prior art to inspect, not assume.

Representative standing: today a declared list (system_config key dunin7_representative_person_ids). Stage 3 is the named point where this moves to a host_account column — representatives become administered, not declared. Scope the migration and the admin surface (who grants standing, through what UI, with what Operator approval step — Operator-authority applies to standing grants).

Person-tier keys: the sibling resolver's tier 2 means a representative with their own Anthropic key pays their own way; otherwise the system key pays. Default recommendation: system key for both Aldous and Warwick at Stage 3 start — cost attribution is what the metering is for, and asking a pilot prospect to bring an API key is friction with no upside. Operator confirms or overrides in the fresh chat.

Workstream 2 — Content (unfreezing v0.23)

v0.25: sits on cr-2026-152-sales-v0_25-wip (d8a718a, marketing repo) — the seventh landscape section, a new leave-behind budget, reversals of v0.21/v0.22 rules from the second real client run (2026-07-17). First content action: review whether that work is finished or mid-thought, finish it deliberately, and land it into the engine's sales_tools package — the marketing branch is history now; the engine is where content lives. Prompt changes re-run the parity discipline: hashes update, the design commentary updates with them, recorded as a content version, not a silent edit.
v0.26 and decision B: as recorded in CR-2026-152 v0.26 — the fresh chat reads that CR before scoping content work.
The dropped plain-example fallback: if a lightweight mode is wanted, it gets scoped here deliberately (recorded Stage 2 deviation, decision 1).

Workstream 3 — Consequences of representatives existing

Marketing generator teardown. Ruled at Stage 2 close: stays up until Stage 3. Trigger is not "Stage 3 starts" but "Aldous and Warwick are enrolled and using the perimeter version" — teardown when the audience has moved, and the marketing Worker's separate Anthropic key retired with it.
Quota calibration. Deferred by Operator ruling until diversified usage data exists. Stage 3 generates it; the quota ruling is a later Operator decision on that data — likely after Stage 3, not within it. The metering and the loose ceiling (2M tokens/24h) stand until then. Note when quotas are set: truncated calls undercount input tokens (recorded in the completion report) — harmless for a runaway guard, wrong for billing. The day quotas become real is the day this undercount stops being harmless; fix it as part of quota work, not before.
Onboarding surface. Representatives arriving see the Operator Layer built for the Operator. Scope the minimum: first-sign-in surface at representative level, what they can and cannot reach (only-show-what-is-available handles the menu), and whether anything Operator-only currently leaks to representative level — a Step-0 inspection item.

The incident's standing follow-ons (Stage 3 owns the first, watches the rest)

The Stage 2 authentication-bypass incident (production posture defeated by an explicit LOOMWORKS_ENV=development when public hostnames were pointed at a former dev box; live ~1 day; contained, swept clean with limits stated) left three queued items:

Dev/production config split — the root-cause shape, still live even though the symptom is closed. One .env serves two postures; posture must not be a value someone remembers to change when a machine's role changes. The structural fix (config split, or a startup refusal to serve public origins in development posture) is guarantees-in-code applied to deployment posture — belongs in Stage 3's Step-0 inspection scope, because representative onboarding will multiply the cost of getting posture wrong.
Access-log timestamps — uvicorn access lines carry none; the incident sweep could count hits but not time-bound them. Cheap fix, upgrades the next sweep from correlation to evidence.
CF-Connecting-IP propagation — with the caution recorded: trustworthy only while the tunnel is the sole path in; otherwise it becomes an attacker-controlled field that looks like evidence, worse than absent. Fix couples to the tunnel-only guarantee.

Inherited queue (standing items, not Stage 3 blockers)

From the completion report §14 and prior handoffs: b0dc30b classifier prompt (cherry-pick, test the three contrast cases plus the "Set the pH to 6.5" control, land-or-discard); secrets-hygiene sweep (.dev.vars key still live); session-scoped-list scoping (/engagements 200-empty vs 401); Node symlink maintenance (~/.local/bin/loomworks-node repoint after nvm upgrade); test_stele_router_mount (harness-only, test-correctness priority); VPS cutover (the standing fix for login-dependent availability — the job pattern and launchd services were built to inherit it, and it must recreate the machine state named below, not carry development forward); and the two branch merges (engine and OL stage-2-sales-relocation → main, clean fast-forwards when last checked, perishable).

Machine state a cutover must recreate (never carried forward from development): LOOMWORKS_ENV=production, LOOMWORKS_SESSION_MIN_ISSUED_AT (the incident epoch), and the three system_config seeds (sales_tools_ceiling_tokens=2000000, sales_tools_ceiling_window_hours=24, sales_tools_job_stale_minutes=15).

Standing discipline (unchanged)

Two-role: Claude.ai scopes and writes; Claude Code executes, inspects against live code, halts before every push. Fresh chat per work type. Step-0 inspection before build briefs. Corrections preserved, not smoothed. Verification checks fail on missing input and anchor to controls that can disagree — now filed methodology with nine recorded instances across Stages 1–2, the canonical example being the Stage 1 perimeter check that verified the lock and never tried the other door, under which the bypass sat live for a day.

What the fresh chat does first

Confirm the Stage 2 close in the record (entry condition — already met).
Apply the display-name rename (first-up small item).
Draft the Stage 3 Step-0 inspection brief: enrollment paths (engine + Stele), representative-standing storage and admin seams, first-sign-in surface at representative level, the dev/production posture split, and the v0.25 WIP branch's finished-or-mid-thought state.
Findings return; the Stage 3 build brief drafts from them with the open decisions above put to the Operator.

DUNIN7 — Done In Seven LLC — Miami, Florida Loomworks — Stage 3 scoping handoff — v0_2 — 2026-07-19