What stands between where Stele is today — a published standalone package the engine consumes — and Stele complete: a library a stranger can clone, mount, run working sign-up and sign-in against, and learn entirely from its own plain-English documentation, with zero Loomworks dependency.
What this document is. A map of everything left to finish the Stele package. Stele is the identity substrate — the passkey ceremony, the principal mint, sessions, credentials, recovery codes, TOTP. Phase 7 is the arc that turns it from engine-internal code into a standalone product. The first slice (P7-1) is done. This names what remains.
What changed in v0.2. Documentation is promoted to a first-class deliverable group. A complete package is not just code that runs — it is code a stranger can understand and use from the package's own documentation. The API reference, the integration guide, the generator documentation, and the worked examples are named as their own deliverables, each built alongside the code it describes.
What decision it asks of you. None immediately — it is an orientation document. The next live decision is whether to open the P7-2 drafting chat (the mountable router), already prepared and waiting.
Scope. In: the remaining Phase 7 work (P7-2, P7-3), the documentation set, and the two parked threads that must close before “complete” is true. Out: P7-1 (done), and the broader Loomworks roadmap beyond Stele.
Phase 7 is sequenced as slices, each with a done-bar a stranger could check. One is landed; two remain. Documentation runs alongside both. Two threads sit parked.
The landed floor — what a stranger already gets when they clone the repository.
Stele is a published private repository, DUNIN7/stele. It carries nine core modules — the passkey ceremony engine, the principal mint and lookup, sessions, the credential store, recovery codes, TOTP, and the shared base. It has its own dependency manifest, pinned to the versions the engine resolved, so a fresh install pulls exactly the right libraries and nothing from Loomworks. It has its own database migration: one consolidated revision that builds its three tables — principals, webauthn_credentials, recovery_codes — against a clean database, carrying none of the engine's history.
The engine now consumes Stele as an installed package rather than as code living inside it. The TOTP secret is encrypted on a key-direct path, so Stele ships three tables, not four — no separate key-store table comes along.
What Stele does not have yet: an HTTP surface of its own, a way to learn it from the package, and a worked example of it running. Today the engine wires Stele's primitives into its own routes by hand, and anyone wanting to understand Stele reads the engine's code. A stranger who clones Stele gets working tables and nothing telling them what to do next. Closing those gaps is the rest of Phase 7.
The slice that gives Stele a surface to mount and an interface to import. The bar: a stranger mounts the router and calls a primitive.
This slice rests on a resolved decision. Stele could have shipped the full sign-up and sign-in flows as routes — but those flows compose Stele's primitives with host-owned work (creating the account, granting credit, joining the commons), and putting them in Stele would force Stele to call back up into the host. That was set aside. Stele ships primitive-level routes only; the host composes sign-up and sign-in over them. The reference app (P7-3) demonstrates that composition. This keeps Stele a substrate the host builds on, not a product surface that reaches back into its host.
The clean, documented set of functions a host imports to use Stele — the ceremony, mint, session, credential, recovery, and TOTP operations — with the contract for how Stele receives what it needs made explicit. Today Stele reaches for its database session and its secret key in ways that assume the engine around it. The SDK surface formalizes those as things the host supplies, not things Stele reaches for. That is what makes Stele mountable anywhere, not just inside the engine.
The hard call this slice carries: a mounted router cannot assume the host's way of identifying the current user. Stele must either ship its own current-principal resolution over its own session, or define the interface the host fills. Naming that contract is the centre of the work.
A router built inside Stele — constructed fresh, since Stele has none today — carrying the direct-primitive endpoints: passkey enrollment (begin, complete, list, revoke), recovery-code regeneration and status, TOTP rotation (begin, confirm), and session issue. The host mounts it; the router receives its database session and config by injection rather than by reaching into the host.
The slice that makes Stele runnable, not just mountable. The bar: a stranger clones and runs working sign-up and sign-in.
Because P7-2 deliberately keeps sign-up and sign-in host-side, the reference app carries more weight here than a sample usually would. It is where the headline flows are actually demonstrated — and therefore where the “clone and run” promise is kept.
A minimal host that mounts the Stele router, supplies the session and config, and wires the full chain — ceremony to mint to session to onboarding — into working sign-up and sign-in. This is the clone-and-run proof. Under the primitives-only decision it is a first-class deliverable, not a sample: it is where a stranger sees the whole thing work.
A small generator that produces the host-side configuration a mounting application needs — the secret key, the session and cookie settings, the injection values. The smallest code deliverable, named for completeness: it removes the last bit of guesswork from standing a host up. Its own documentation (D6c) explains what it produces and what each value means.
A first-class deliverable group, not a footnote. A complete package is one a stranger can understand and use from its own documentation — without reading the engine's code, without asking anyone. Every piece is plain English, every example runs, and every description is sourced from the code so the docs cannot drift from what the code actually does.
This follows the same discipline as the engine's own API-documentation effort: descriptions live in the code as the single source of truth, generated into a concise reference and authored into a plain-English narrative. Stele's documentation is built alongside the code it describes — the API reference grows as P7-2 builds the router; the integration guide and generator docs land with P7-3; the examples are the same ones the reference app runs. Documentation is therefore not a slice that waits until the end; it is written as each surface is built, so it is never reconstructed from memory after the fact.
Every primitive function and every router endpoint, in plain English: what it does, what it takes, what it gives back, and what it assumes the host has already done. The nine modules' functions are documented as they stand today; the router endpoints are documented as P7-2 builds them. Each entry reads as a person would explain it — not a type signature dressed up, but a sentence a non-specialist can follow — with the precise signature shown beneath for the implementer who needs it.
The “how do I actually use this” document. How a stranger installs Stele, mounts its router, supplies the session and config, resolves the current principal, and wires the headline flows — ceremony to mint to session to onboarding — into working sign-up and sign-in. This is the document that turns the primitives and the router from a pile of parts into a thing someone can stand up. It walks the whole path once, in order, in plain English, with the reasoning for each step.
What the config generator is for, how to run it, what it produces, and what each produced value means — the secret key, the session and cookie settings, the injection values. Written so a stranger who has never seen Stele can run the generator, read its output, and understand every line of the config it hands them, without having to reverse-engineer what each setting controls.
Examples that actually run, not illustrative snippets — covering sign-up, sign-in, mounting the router, generating config, and the passkey ceremony end to end. The passkey ceremony gets the most careful treatment, because the browser-side half is the piece hardest to infer from primitives alone and the place a stranger is most likely to get stuck. The examples are the same code the reference app runs, so they are proven, not aspirational.
Neither blocks P7-2 or P7-3, but both must close before “complete” is honestly true. Recorded here so they are walkable, not lost.
Today the engine depends on Stele by a relative file path — the two repositories sit side by side on the build machine, and the engine points next door. That works on the build machine and is exactly what P7-1 committed to. But it means the engine will not build somewhere that path does not exist. Retiring it — publishing Stele as a real installable package the engine pulls by name and version — is the thread that makes Stele deployable anywhere, not just beside the engine.
While landing P7-1, we found something unexpected: the development database held no TOTP secrets encrypted the old envelope way — all of them were already on the key-direct path. The migration we planned to convert them turned out to have nothing to convert. That was the best possible outcome for that step, but it raised a question worth answering later: were those secrets supposed to be envelope-encrypted? If an earlier change meant to put them there and never did, that is a fact about that earlier change's true landed state — not a Stele problem, but a thread someone should walk to be sure nothing is half-done upstream.
The finish line, stated plainly, so it is recognizable when reached.
Stele is complete when a stranger — no DUNIN7 access, no Loomworks knowledge — can clone the repository, install it by name, mount its router into their own application, supply a session and config from the generator, follow plain-English documentation whose examples run, and stand up working passkey sign-up and sign-in — learning the whole thing from the package itself, with no one to ask. The engine consumes that same published package by name, not by a path to the repository next door. And the one upstream thread (were those TOTP secrets meant to be envelope-encrypted) has been walked and closed.
The deliverable count: three done or in the landed floor (D1–D3), two code deliverables in P7-2 (D4, D5), two in P7-3 (the reference app and the generator), and the four-part documentation set running alongside (D6a–D6d) — plus the two parked threads. The next step is a single decision: open the P7-2 drafting chat, which is already prepared and waiting with its full input set.