Loomworks — Stele Phase 7 P7-3 CR-Drafting Handoff — v0.2

Version. 0.1 Date. 2026-06-19 Author. Marvin Percival (DUNIN7 Operator) with Claude.ai (scoping) on DUNIN7-M4. For. A fresh Claude.ai chat — the CR-drafting role. This chat's product is the P7-3 change request: the final Stele Phase 7 slice — the ceremony lift + the reference app + browser ceremony + config generator + docs. Status. CR-drafting handoff. Both P7-3 forks are resolved (lift + env-scaffolding). The asymmetry-dissolution recording shape is settled (forward-note, not a 115 amendment — §5 below). This chat drafts the P7-3 CR only. Markdown primary (technical consumer / next-session orientation). v0.2 change. Locks the forward-note decision (was an open Step-0 item in v0.1). Supersedes the filed v0.1; this is the copy to read.

Plain-language summary

What this chat does. Drafts the P7-3 CR — the final Phase 7 slice that takes Stele to the clone-and-run-and-use bar. Five deliverables: (1) lift the add-passkey ceremony into stele.webauthn (dissolving the P7-2 asymmetry — a clean extraction, not a split); (2) a standalone reference app that mounts stele.router; (3) the browser WebAuthn ceremony closing the ceremony-gap; (4) an env-scaffolding config generator; (5) docs. Both forks are resolved going in — this chat does not re-open them.

The state going in (settled — do not re-establish).

• P7-2 (CR-2026-115) landed across all three repos: stele 1077803 (mountable router + SDK + STELE_SECRET_KEY rename), loomworks-engine 08e89c5 (consumes stele + mount-verify test), loomworks-record 45ac2f1 (CR + completion record + manifest v0.67 + P7-3 Step 0 report/brief).
• Fork 1 resolved: LIFT. The ceremony moves into stele.webauthn; the injection slot disappears; the engine re-points.
• Fork 2 resolved: ENV-SCAFFOLDING-ONLY. The config generator emits a .env template, no code-gen.

Read first (this chat's orientation, in order)

All in loomworks-record:

1. This handoff — the frame.
2. The P7-3 scoping note (...-p7-3-scoping-note-v0_1.md) — the commitment frame. The five deliverables, both resolved forks with their trajectory, the two §D decisions to make at the CR's Step 0, the sequencing (lift first), what's held out.
3. The P7-3 Step 0 inspection report (...-p7-3-step-0-inspection-report-v0_1.md, record 45ac2f1) — the ground. §A (the persons/signup.py tangle — the clean-extraction facts the lift rests on), §B (the live mount surface — 8 routes, 9 slots, SDK/mount/delivery mechanics), §C (what a real mount requires — the config-gen sizing), §D (reference-app shape signals — Postgres/JSONB, browser front, login-as-host-composition, the TOTP-verify gap).
4. The P7-2 completion record (...-p7-2-completion-record-v0_1.md) — the as-built floor: the injection contract, the §4 asymmetry named as correction-in-waiting (which this CR dissolves), the banked lessons.
5. CR-2026-115 v0.2 (change-requests/cr-2026-115-...-v0_2.md) — the P7-2 CR whose §4 named the asymmetry this CR's lift dissolves. Recording shape is settled (Operator decision, 2026-06-19): a forward-note in the P7-3 CR pointing back to CR-2026-115 §4 — NOT a 115 v0.3. Reason: 115 is closed and as-built; its v0.2 correctly records the asymmetry as it stood at 115's close. Amending a closed record to carry future events muddies what 115 was. The dissolution belongs to P7-3's record, with a pointer back, keeping each record true to its own moment and the trajectory walkable. Do not re-open this.
6. The seed (loomworks-candidate-seed-v0_12.md) — the authentication framework (no email as identity) and authorization substrate (Stele authenticates, host authorizes). The reference app's login composition must honor both.
7. The current-status manifest (current-status-manifest-v0_67.md) — live state.

What the P7-3 CR must commit to

The CR drafts the five deliverables from the scoping note + inspection report, opening with its own Step-0-of-the-CR grounding pass (CC re-confirms the lift's clean-extraction facts against live code, and resolves the two §D decisions + the store-slot fate against the live surface, before committing to the build).

The CR's Step 0 must resolve:

• The store-slot fate (§D Decision 1) — post-lift, does provide_add_passkey_store become Stele-internal (scoping lean: yes if clean) or stay a host slot? Confirm against the live store binding.
• The login-TOTP composition gap (§D Decision 2) — host-composition (scoping lean, B-first-consistent) or add a Stele TOTP-verify primitive? If the latter, name it as a fifth small Stele deliverable.
• The lift's shared-symbol handling — PENDING_TTL, PendingRegistrationNotFound: confirm they move with the ceremony or become Stele-owned, leaving the signup flow intact.
• The reference-app home — stele examples/, a separate repo, or record-adjacent (Operator filing call; surface it).
• The full webauthn-config field set — what the config generator must scaffold (confirm against the live WebauthnConfig shape).

The build sequence the CR commits:

1. The lift (both repos, add-and-verify, engine suite green) — first, because it shrinks the slot set.
2. Reference app + browser ceremony + config gen.
3. Docs.
4. Record (completion + manifest; the 115 asymmetry-dissolution recorded as a forward-note in the P7-3 CR/record, per the settled decision above).

Standing disciplines to carry in

• The lift is a clean extraction, not a split — the inspection proved it; the CR re-confirms but builds on it. Do not re-litigate Fork 1.
• Two-repo add-and-verify for the lift; engine suite green throughout.
• Seed-alignment — the reference app must not introduce email-as-identity; login composes over passkey/TOTP/recovery credentials.
• The reference app needs real Postgres (JSONB) — not SQLite.
• The browser ceremony is the gap-close — a real navigator.credentials round-trip, not synthetic payloads.
• CC instruction blocks in fenced code blocks, commentary outside.
• Document format — the P7-3 CR is technical (Markdown primary); the adopter-facing docs deliverable is HTML primary + Markdown source. Lands in loomworks-record (CR at change-requests/; reference-app home per Step 0).

The CR-number question (resolve at draft time)

P7-3 is likely CR-2026-116 (P7-2 was 115). Confirm against the live ledger at draft time — CC checks the highest cr-2026-NNN in change-requests/; don't assume from this handoff.

The arc from here

1. This chat drafts the P7-3 CR (with its own Step-0 grounding pass + the two §D resolutions).
2. CC executes, slice by slice, inspect-first, halt-before-push, two-repo add-and-verify (the lift first).
3. P7-3 closes Phase 7. After it: the published-package path and the CR-2026-102 SCOPE_TOTP thread remain as parked, walkable threads — not Phase 7.

Two-role division holds: CR-drafting (this fresh chat) separate from execution (CC). Fresh chat per role.

Open items riding alongside (not P7-3 blockers)

• CR-2026-098 (engine 5472335) — four boundary findings, A3 privilege-model HALT, awaiting CC. Orthogonal.
• API documentation effort — ~200 routes + ~1,000 fields. Orthogonal (though the P7-3 docs deliverable may inform its approach).
• Published-package thread and CR-2026-102 SCOPE_TOTP thread — parked, walkable.

DUNIN7 — Done In Seven LLC — Miami, Florida Loomworks — Stele Phase 7 P7-3 CR-Drafting Handoff — v0.2 — 2026-06-19