DUNIN7 · LOOMWORKS · RECORD
record.dunin7.com
Status Current
Path phases/phase-14-person-layer/loomworks-phase-14-person-layer-scoping-handoff-v0_1.md

Loomworks Phase 14 — Person layer scoping handoff v0.1

Version. 0.1 Date. 2026-04-25 Status. Handoff into a fresh chat for Phase 14 scoping. The person layer: identity, self-service signup, real passkey auth, designations, and the substrate migration from engagement-scoped contributors to person + membership.

What this hands off

Scoping for Phase 14 — the person layer. The substrate (Phases 2–12, plus Phase 13's two endpoints and contributor registration) has no concept of a person that exists outside of engagement-scoped contributor rows. Phase 14 introduces the person as a first-class entity: one human, one identity, one set of credentials, memberships in engagements with stackable designations.

This is the phase where the "Sign in with passkey" button becomes real WebAuthn, the dev-token bridge is retired, and Loomworks becomes usable by more than one person.

What to read first, in order

  1. current-status-manifest-v0_11.md — the orientation artifact. Absorbs Phase 13 and Phase 13A. Names two repos, all tags, the engagement-count correction, and the four structural residues.
  1. loomworks-person-layer-discovery-v0_1.md — the Discovery record from the session that produced this handoff. Eight decisions settled: person layer first, self-service signup, welcome page, stackable designations, domain declaration with AI-assisted topology, unrecoverable accounts (no admin backdoor), three onboarding paths, and substrate migration. Names what was considered and rejected alongside what was settled.
  1. loomworks-brand-README-v0_1.mdloomworks-design-md-v0_1.mdloomworks-brand-guide-v0_15.html — the brand system. The welcome page and signup flow are ceremonial surfaces (vertical lockup register). Three brand-compliance passes were needed in Phase 13 — the new chat should render against the brand guide HTML side-by-side from the start.
  1. what-dunin7-is-building-v0_17.docx — the methodology document. The person layer introduces concepts (designations, domain expertise, recognition) that must be consistent with the methodology's vocabulary and principles.
  1. loomworks-candidate-seed-v0_3.md — the Loomworks engagement's own candidate seed. Not directly in scope for Phase 14, but relevant context: the Loomworks engagement is still uninducted and has eleven declared render-types. The person layer may interact with the Loomworks engagement's eventual induction.

Settled decisions from the Discovery record

These are settled. The scoping session should consume them, not relitigate them.

Self-service signup

Anyone can create a Loomworks account. Signup collects: name (required), passkey (required, real WebAuthn), TOTP (required, second factor), email and/or mobile (optional — person is told no outbound communication is possible without them), recovery codes (generated, person stores them).

Welcome page after first signup

Not the dashboard. A ceremonial arrival page (vertical lockup) explaining what Loomworks is, what they've gained access to, and what doors are open: create an engagement, enter an invitation code, go to the dashboard.

Designations are per-engagement and stackable

Operator, Contributor, Domain Expert — independent flags on the membership, not a single enum. A person can hold multiple designations on the same engagement. Extensible beyond three.

Domain declaration

Person-declared, AI-assisted, Operator-recognized. Person declares in their own words → AI agent examines the domain graph, surfaces overlaps/sub-domains, pre-populates a description → person approves → recognition comes later per-engagement from Operators. The AI doesn't gatekeep.

Account recovery

No admin backdoor. Your credentials are your responsibility. Multiple passkeys + TOTP + recovery codes in standard credential stores (LastPass, 1Password). If all are lost, the account is unrecoverable. Product surface makes this clear at signup.

Invite authority is distributed

An Operator on an engagement can invite people. They don't need DUNIN7's approval.

What the scoping session needs to decide

S1 — Phase 14 scope boundary

How much in Phase 14? Candidates:

(a) Person layer + real passkey + migration only. The person table, WebAuthn registration and sign-in, TOTP migration from contributor to person, the four existing contributor rows repointed, the dev-token bridge retired. No invitation flow, no domain declaration, no engagement creation through the UI. The welcome page shows "create an engagement" and "enter invitation code" as doors that don't open yet.

(b) Person layer + passkey + migration + invitation. Everything in (a) plus: an Operator can invite a person to an engagement by email/handle. The invited person receives a link, creates an account (or signs in), and lands in the engagement with the designations the Operator specified.

(c) Person layer + passkey + migration + invitation + engagement creation. Everything in (b) plus: a person can create an engagement through the UI. They become its Operator.

S2 — Membership table design

The current contributor table has: id, engagement_id, person_id (currently NULL — to be populated), kind (human/agent), display_name, commit_authority, bearer_token_hash, totp_secret. The membership redesign needs to:

S3 — WebAuthn library and implementation

WebAuthn requires a server-side library (e.g., py_webauthn for Python). The registration flow (create credential) and authentication flow (get assertion) need substrate endpoints. The frontend needs the WebAuthn browser API (navigator.credentials.create(), navigator.credentials.get()). This is real cryptographic protocol work — the scoping session should decide whether to use a library that handles the ceremony or implement from the spec.

S4 — Domain declaration agent

Is the domain-declaration agent in scope for Phase 14, or deferred? It requires: a domain table, the AI agent with the domain-graph examination behavior, the pre-populated description flow, and the per-engagement recognition mechanism. This might be better as Phase 15 after the person and membership layers are proven.

S5 — Deployment

Phase 13 runs on M4 with LAN access from M5. Does Phase 14 change this? Real passkey auth requires HTTPS (WebAuthn mandates a secure context). Local development can use localhost (which browsers treat as secure), but LAN access from M5 via IP address will need a self-signed certificate or a tunnel. The scoping session should decide the approach.

Substrate state

Operator preferences in play

First-message guidance for the new chat

> I want to scope Phase 14 — the person layer. Read the handoff at [this document], then read the Discovery record and the manifest. The five decisions in the handoff (S1–S5) are the agenda. The eight settled decisions from the Discovery record are not up for relitigation — absorb them and build on them.


DUNIN7 — Done In Seven LLC — Miami, Florida Loomworks Phase 14 — Person layer scoping handoff — v0.1 — 2026-04-25