Loomworks — Stele Extraction Phase 4→5 Session Handoff — v0.1

Version. 0.1 Date. 2026-06-15 Author. Marvin Percival (DUNIN7 Operator) with Claude.ai (scoping/CR) on DUNIN7-M4. Status. Session handoff. Phase 4 (CR-2026-107) is complete, merged, and published. This document orients the next session (new Claude.ai chat; likely new CC session) on the current build state and the Phase 5 starting point. It does not re-tell Phase 4 — that lives in the completion record (see "Read first"). Markdown primary (technical consumer / next-session orientation).

Plain-language summary

Phase 4 split the sign-up flow into mint (Stele) + onboard (host), with an orphaned-principal state that heals on sign-in. It is fully landed: merged to engine main, the CR stack and completion record are published, the branch is deleted. Nothing is in flight. The next phase is Phase 5 — credential lifecycle. This handoff says where everything sits right now and what to read before starting Phase 5.

Read first (orientation pair + the Phase 4 record)

Before doing anything in the next session, read these, in order, from loomworks-record (record.dunin7.com, behind Cloudflare Access — if a file can't be reached directly, ask CC to fetch it):

1. The highest-versioned current-status-manifest-vN_M in current-status/ — the recent state. (At this writing the highest filed is v0.57, but do not assume — read the highest actually present; the manifest may have been bumped to fold in Phase 4.)
2. The highest-versioned loomworks-candidate-seed-vN_M in candidate-seeds/loomworks/ — the foundation document (canonical at this writing: v0.12).
3. The Stele Phase 4 completion record — phases/stele-extraction-phase-4/loomworks-stele-phase-4-completion-record-v0_1.md (loomworks-record ae3775f). This is the full Phase 4 story: what moved, the four-version CR trajectory, the two build-caught corrections, the two-half database-truth proof, the two logged limitations, the Phase 5 handoff section. The handoff you are reading now is the thin pointer; the completion record is the substance.
4. CR-2026-107 v0.4 — change-requests/cr-2026-107-stele-extraction-phase-4-v0_4.md (loomworks-record 1d8aef8) — the governing CR, if the next session needs the executable detail behind the record.
5. The Stele body-of-work brief and the integration design (their canonical locations as named in prior handoffs) — for the Phase 5 row and the mint/credential contracts.

Current build state (verified, as of 2026-06-15)

| Ref | Hash | State | |---|---|---| | engine origin/main | 9be25fd | Phase 4 merged; alembic 0084 | | engine local main | 9be25fd | == origin (in sync) | | loomworks-record origin/main | 1d8aef8 | CR v0.3, completion record, CR v0.4 (all pushed) | | playground_dev alembic | 0084 | matches main code | | playground_test alembic | 0084 | matches main code | | Phase 4 branch | — | deleted (local + remote); main carries the full series |

Suite at Phase 4 close: 2921 passed / 46 skipped / 0 failed. Runs from main consistently (code 0084, dev DB 0084).

Nothing is in flight. No open branch, no uncommitted work, no pending CC halt. The next session starts clean from main at 9be25fd.

What Phase 4 put in place (one-paragraph recap — full detail in the completion record)

Sign-up is now two-phase: mint_principal (Stele, stele/registry.py) creates the identity (person row, encrypted TOTP secret, passkey credential, recovery codes) and commits; onboard (host, persons/onboard.py) does commons/org membership, personal engagement, system saved filters, and the credit-grant claim, and commits separately. A new onboarding_complete boolean on the person row (migration 0084, inverted backfill) marks the state between them. If onboard fails after the mint commits, the principal is an orphan; _heal_if_orphaned (in both login routes, post-gate, pre-cookie) runs onboard to completion on the next sign-in. create_person remains a separate bare credential-less test/utility primitive. The host-seam principle holds: Stele owns the identity primitives, the host owns the policy around them.

Phase 5 — the starting point

Phase 5 = credential lifecycle. The brief's Phase 5 row: second-passkey enrollment, passkey-revoke, TOTP-rotate, recovery-code surfacing — the credential-management operations that belong to Stele's identity surface but were deferred while the mint/resolve/split spine was built.

Scoping note before drafting: an account-recovery amendment already landed separately on the Companion functional spec (§10.3: second-passkey enrollment, recovery-code surfacing with soft-invalidation, a unified /me/security/ router, the OneTimeSecretsDisplay component). Phase 5 must be scoped against what that amendment already did and did not cover — do not re-build what's already there. The first Phase 5 task is to establish, from the real code, what /me/security/ currently provides versus what the Phase 5 row still needs. (Mechanism 3, founder authority, was deferred and bound to A3 in CR-2026-098 — a separate thread, not Phase 5's concern unless it surfaces.)

Standing disciplines to carry into Phase 5 (the Stele-extraction method, hardened across Phases 0–4)

• Ground before drafting — now covering signatures and placements, not just function inventory. Phase 4's two corrections (mint signature wrong; heal placement before the gate) both came from an instruction written against a design site without checking the real code there. Before drafting Phase 5 steps: read the real bodies of the credential operations being added/moved and the real call-sites where they'll be placed (especially anything with a gate, a transaction boundary, or a layer split between where a value is produced and where it's used). A signature is derived from the real body it relocates; a placement is checked against the real code at the placement site. A coordinate/line-number check confirms what you look at; it does not surface what you did not think to look for.
• Step 0 pre-flight is read-only — confirm baseline (HEAD, suite, alembic), report the inventory, lock the gating decisions with the Operator; do not branch or commit in Step 0. The first executing step archives the CR into the engine and cuts the branch.
• Per-step (and per-sub-step where load-bearing) commits; suite green at every commit; halt before push. Phase 4's 4.3 was split into 4.3a/b/c so the load-bearing two-commit cut was isolated and revertable alone.
• Verify against playground_dev, not the suite alone. Drive the real production path (HTTP routes through real get_db_session, real transaction semantics; stub only crypto verify as the suite does). The test suite can pass on a harness pattern the production path doesn't use — prove the real path in the real database.
• Inspect-first on any cut where a moving step is followed by must-stay logic, or where a new step lands near a gate/commit/layer boundary. Report the seam; stop-and-report if it can't separate cleanly.
• Never fixture-patch a test green when its premise is now false. Skip-with-reason (explicit, pointing at the re-point step) and re-point; un-skip when the new behaviour lands. Carry-forward obligations are tracked, not optional. (Phase 4 did this five times across 4.2/4.3/4.4 and left zero stale skips.)
• Surface decisions with a lean and explicit reasoning; the Operator confirms or redirects. When a build finding contradicts a locked decision or the Operator's stated mental model, STOP and surface it before mutating anything outward (push, merge, delete) — the benign-direction discrepancy at the Phase 4 merge is the example (origin/main was behind, not ahead; CC checked the real ref rather than trusting the stated precondition).

Two logged limitations carried forward (not Phase 5's obligation unless it chooses them)

Both on the failed-signup-with-claim path, same root (pending record discarded at mint-commit): (1) failed-signup UX gap — a user whose onboard fails has no session and no pending record, and heal only fires on sign-in, so a brand-new user may not know to sign in; (2) orphaned claim — a failed signup with a credit claim heals without the auto-claim (the grant survives unclaimed in the credit system). Candidates for a later heal/recovery-UX pass. Detailed in the completion record §6 and the queued-directions document.

A correction to the repo working-model (recorded so it isn't repeated)

Through all of Phase 4, engine origin/main sat at d3acd84 (the Phase 3 endpoint) — the bcb59f5 "Archive CR v0.2" commit lived only on local main and the branch, never independently pushed, until the Phase 4 merge fast-forwarded origin/main to 9be25fd. Do not assume local main == origin/main between phases; intermediate main commits may be local-only until a merge pushes them. Check the real ref.

Pending Operator items (none on the execution path)

• Manifest fold-in: if the current-status manifest has not yet been bumped to record Phase 4's close, that update is the natural first artifact of the next session (or whenever the Operator chooses). Phase 4 is fully landed but the manifest may still show it in-flight depending on when it was last written.
• This handoff lands in loomworks-record (suggested: phases/stele-extraction-phase-4/ beside the completion record, or the handoffs location the manifest names).

DUNIN7 — Done In Seven LLC — Miami, Florida Loomworks — Stele Extraction Phase 4→5 Session Handoff — v0.1 — 2026-06-15