DUNIN7 · LOOMWORKS · RECORD
record.dunin7.com
Status Current
Path current-status/dunin7-status-brief-v0_22.md

DUNIN7 — status brief — v0.22

Version. 0.22 Date. 2026-08-04 Charter. standing-notes/dunin7-standing-authorization-charter-v0_1. Author. Claude Code (execution session). Operator: Marvin Percival. Supersedes. v0.21 at record eb89143. All earlier versions stand as siblings; v0.3 remains deliberately absent. Changes from v0.21. CR-2026-157 executed in full — Steps 0–6, Checkpoint A, Checkpoint B — and CLOSED. OVA Slice 1, the non-member contribution pathway, is merged, tagged, pushed.


1. What landed

loomworks-engine main 3b10ff1 (was 5c24d65), tag cr-2026-157-non-member-contribution-v0_1, both push-verified.

Eight commits merged, one per step plus the implementation-notes doc: Step 0 (pre-flight + three enumerations), Step 1 (migration 0103 + module), Step 2 (credential module + onboard's third dispatch branch + signed-in claim), Step 3 (the Option E authorizer + stub migration), Step 4 (issuance/list/revoke + FORAY registrations), Step 5 (credential resolver + external-contribution endpoint), Step 6 (own-submission surface + admission composition), and implementation notes.

54 new tests (3521 - 3467 baseline). Full detail: docs/phase-crs/cr-2026-157-implementation-notes-v0_1.md on the engine repo.


2. Executed under the amendment, not the CR's bare text

CR-2026-157 was drafted 2026-07-28, two days before the charter. Its own §8 Step 1 verification instruction, read literally, would have run a full migration down/up cycle against playground_dev — the single most consequential line in the document, and not a defect in its design, just a fence that didn't exist when it was written. Executed instead under cr-2026-157-amendment-note-v0_1, which overrode: throwaway databases only (never playground_dev or playground_test, at any step, including all seven per-step suite verifications); Checkpoint A run by the executing session on a throwaway stack rather than the Operator against the dev environment; "no new failure against the recorded baseline" rather than "suite green" (the baseline itself carries one unrelated long-standing failure); and a fresh membership-gated-read count (61, enumerated and documented at Step 0) rather than the CR's stale "63."


3. Three real bugs found and fixed during construction

Each caught by a test written to prove the CR's own acceptance criteria, then failing — not by reading, and not treated as scope creep, since each was a defect in what the CR itself asked to be built correctly:

  1. Cross-engagement revoke leak. The credential module's revoke_credential had no engagement_id scoping — an Operator on one engagement could revoke, and discover the existence of, a credential belonging to another. Fixed at the SQL layer; a cross-engagement id now 404s identically to a nonexistent one.
  2. The CR's own §5 text for the own-submission query doesn't survive a commit. Built exactly as specified (wasAttributedTo.id == person_id), then failed: commit_assertion rewrites provenance.wasAttributedTo to the committing member's ActorRef on the committed version — a known imprecision already documented elsewhere in the codebase, that the CR's drafting session didn't carry into this design. Fixed to filter on metadata.credential_id alone, which survives every state transition.
  3. A value emitted and not allowedsource_mode="external_credential" wasn't in AssertionResponse/AddAssertionRequest's Literal, so the new endpoint 422'd on its own success path. The same defect class CR-2026-162 corrected for "discovery", fixed the same way, excluding the same narrower upload-side pair for the same reason.

4. Checkpoint A — live verification, run and passed

Full sequence — issue, claim (signed-in path), contribute, verify held/attribution/assertion_added, verify the fence (every ordinary read 403s), Operator admits via the existing commit transition, own-submission shows committed, revoke, contribute-again refused — run against a real booted app on a throwaway database, synthetic engagement created and destroyed within the run. No halt condition fired at any step across the entire build.


5. Charter compliance

R-2 held through both checkpoints. Auto-proceed Steps 0–6 ran with per-step commits and a suite check at every step, compared against the recorded baseline rather than assumed green. Checkpoint A reported and proceeded on a clean report, per the amendment's explicit authorization. Checkpoint B merged --no-ff, tagged, and pushed under R-2's existing authorization.

C-1 held at the merge. origin/main re-fetched and re-verified unchanged immediately before merging (no concurrent-session drift); clean index confirmed; --no-ff used; the feature branch deleted only after the merge landed and pushed.

Amendment discipline held. The pre-charter procedural gap this CR carried was corrected before execution, not discovered mid-run. Every override the amendment specified was followed exactly — no throwaway database was ever skipped, no suite run touched playground_test, the membership-gated-read count was established fresh rather than trusted.

Discipline clause held throughout. Every step's suite comparison is quoted with its exact numbers in the implementation notes. Each of the three found bugs is recorded with the failing test that caught it, not smoothed into "fixed along the way."

R-1 for this filing, on a clean pre-flight.


DUNIN7 — Done In Seven LLC — Miami, Florida DUNIN7 — status brief — v0.22 — 2026-08-04 Every anchor held. Two of the design's own assumptions didn't — and the tests written to prove the acceptance criteria are what caught them.