Version. 0.19
Date. 2026-08-03
Charter. standing-notes/dunin7-standing-authorization-charter-v0_1.
Author. Claude Code (execution session). Operator: Marvin Percival.
Supersedes. v0.18 at record 32e7afe. All earlier versions stand as siblings; v0.3 remains deliberately absent.
Changes from v0.18. B-41 verification run and closed. Migrations run against three throwaway databases, created and dropped this session. Both target repositories read-only throughout. playground_dev and playground_test never connected to. Findings filed.
B-41 verification brief, filed at inspection-briefs/loomworks-b41-verification-brief-v0_1.md (drafted prior to this session).
B-41 verification findings, filed at inspection-briefs/loomworks-b41-verification-findings-v0_1.md, copy in ~/Downloads. loomworks-engine main ffc29af and stele main 689de41 (tag v0.4.0), both read-only throughout, both clean, neither edited, branched, or committed to. Three throwaway databases (b41v1_engine, b41v2_stele, b41v3_sequence) created and dropped this session; playground_dev and playground_test never connected to.
Question one — is the stamp safe: yes. alembic stamp 0001_baseline followed by alembic upgrade head, run with Stele's own config against the database the engine's own chain built to head, succeeded with no error, twice — once in isolation, once as the last step of the full sequence — and principals.totp_last_step exists afterward with the correct type both times. D-1 (the scoping note's Option B) survives. The chain's break at 0034 was confirmed exactly as the findings predicted, and the table diff across all three shared tables (principals, webauthn_credentials, recovery_codes) found exactly one difference — totp_last_step — exactly as predicted, with no further discrepancy in type, default, index, or constraint anywhere else.
Question two — does the full sequence produce a working database: yes. Engine chain to 0033, the bootstrap (invoked by the same minimal one-liner means the brief authorized), engine chain to head, Stele's stamp and upgrade — all four/five steps succeeded on a fresh throwaway. Verified working three ways: the test suite's own table-count precondition passes, the application boots against it and /healthz reports the database reachable and the administrative engagement present, and both chains' alembic heads match their repositories' declared heads.
A finding neither grounding document stated: alembic upgrade head's failure at 0034 rolls back the entire invocation, not just the failing revision. Run from empty in one shot, the database is left with zero tables after the failure — indistinguishable at a glance from nothing having run. The chain has to be walked to 0033 in its own invocation for that progress to survive a subsequent failure at 0034. This reshapes the documented sequence: it is not "run to head, then bootstrap," but "run to an explicit intermediate revision, then bootstrap, then run to head" — the ordering is load-bearing, not cosmetic.
A second finding: LOOMWORKS_SECRET_KEY was needed by three migrations and was supplied — silently, by .env's own fallback inside each migration's _fernet_encrypt helper — without this session ever setting it inline for the migration runs themselves. A deployment without that .env entry would hit the documented, recoverable RuntimeError.
A third: the playground database role cannot CREATE DATABASE. Every throwaway had to be created under a role with that privilege and owner-reassigned afterward — not previously written down anywhere.
The written sequence, its five-or-six-command shape, and five concrete traps a person or agent would hit following it without help are recorded in full in the findings, per the brief's Question three.
No contradiction of the step-0 findings or the scoping note was produced. Every prediction named for confirmation was confirmed. What this run adds beyond both documents is recorded in the findings' §5 and §6, not folded into either grounding document's own claims.
R-4 verification run, held to its fences throughout. Both repositories read-only — no fix, no branch, no commit, no dependency install in either. Every migration ran against one of three throwaway databases, each created for this run and dropped at its end (confirmed dropped by listing databases afterward). .env untouched. playground_dev and playground_test never connected to. No merge, no tag, no push to either target repository.
A failure was treated as a result, not worked around, per the brief's fence: the 0034 break was recorded with its exact error text and the transaction-rollback behavior it produces, rather than being routed around silently — the same shape B-9's workarounds are named as having gotten past improperly.
Discipline clause held. Every claim in the findings names the command run and quotes its output. The chain-length figure was not re-carried from either grounding document without re-deriving it independently where it mattered to this session's own claims.
R-1 for two filings, each on a clean pre-flight: the findings and this status brief.
DUNIN7 — Done In Seven LLC — Miami, Florida DUNIN7 — status brief — v0.19 — 2026-08-03 The stamp is safe, the sequence works, and the two facts neither grounding document could state without running it are now recorded.