Version. 0.45
Date. 2026-08-09
Charter. standing-notes/dunin7-standing-authorization-charter-v0_1, ratified 2026-07-30.
Author. Claude Code (execution session). Operator: Marvin Percival.
Supersedes. v0.44 at record c912478. All earlier versions stand as siblings.
Changes from v0.44. The two-change-request run 191–192. Both landed. The consequential act was neither of them: it was settling a principle three migrations had already relied on without anyone ever putting the question. Build list moved v0.44 → v0.45.
Two migrations landed this run. The decision underneath them mattered more than either.
> An operational identifier that did not exist when the object was created is not an audit-trail fact. > > The record is ABOUT content, state and commit facts. A display number is what the record is ADDRESSED BY. Adding a handle is not editing the account.
The boundary travels with it, and was written before the permission:
> This covers identifiers that are derived, verifiable, and determined by facts already in the log — where the fill-in computes what was always true. > > It does not cover content, state, commit facts, attribution, or any value that is a judgment rather than a computation. > > A future migration wanting to write something that cannot be recomputed from the log does not inherit this answer.
The test is not "is this an identifier." It is can the value be recomputed from the log, and would it have been the same had the field always existed — a question with an answer, which is what makes the boundary enforceable rather than rhetorical.
| Migration | | |
|---|---|---|
| 0041 (Phase 16) | stated the claim in its docstring | wrote log + projection |
| 0055 (Phase 38) | relied on it | wrote log + projection |
| 0094 (CR-2026-121) | relied on it | wrote log + projection |
| 0054 (Phase 36) | — | wrote the projection only |
Three migrations acted on a principle that had never been ratified, and the fourth skipped the step its siblings took deliberately. Filed as a standing note rather than left inside the change request, because the next migration should not have to rediscover it — and because the boundary is the part that gets lost when a permission is inherited without its reasoning.
Two reasons, both recorded. The counterfactual test: had the number existed from the start, every object would carry exactly the one that was filled in — verified, all fifty-four, zero drift. A content edit has no such counterfactual; absent the assertion there is no fact of the matter. And the alternative failed its own standard: recording the numbers as new events would have kept the letter of never-editing-the-record while writing fifty-two revisions that never happened into a record whose purpose is truthfulness about what happened.
The log could not reproduce the view.
Migration 0054 backfilled display numbers into the two projections and never into the event log. The projector reads the number from the payload; a rebuild deletes the engagement's rows and replays from the log. So rebuilding a legacy engagement returned nulls.
| | no number in the log | total | |---|---|---| | shape events | 63 | 64 | | render events | 27 | 28 |
Ordinary operation was never affected — the projection's write preserves a number already on a row. The loss appeared only on a full rebuild, which is the repair tool: what you reach for when a projection is already damaged. The repair silently discarded data the damaged copy still held.
> The constraint did not cause this. It exposed it. Rebuild-from-scratch was already broken for legacy engagements before anyone touched B-54, and would have stayed that way. "The constraint breaks rebuild" leads somewhere specific and wrong: drop the constraint, call it fixed, leave a lossy recovery path in place with nobody looking for it.
Closed by CR-2026-191. The log now holds what the views hold: zero payloads missing the key across 92 events and 54 current objects, and zero mismatches against the view — the second check being the one that matters, since a backfill writing some number everywhere would also drive "missing" to zero.
Both were plausible. That is why they are recorded as arguments rather than outcomes.
CR-2026-191 §1 named the remedy as "settled already, and not reopened here." It was not settled; it was asserted. Step 1 found the remedy had no precedent in this system and that a different one had three.
It also had a structural cost the CR had not stated: the log's uniqueness constraint means a compensating event cannot attach a fact to an existing version — it must mint one. Fifty-two objects gaining a version, every shape reading as revised by a repair that changed nothing. And no honest author existed — all four actor kinds are in live use, none is the system. No actor did anything, which is the schema saying the event should not exist.
> Fourth instance this run of a premise asserted from a plausible model rather than read, after the credentials list, the Shape response, and CR-2026-189's consent fields. > > The Operator named the tell, and it is cheap enough to apply every time: "The pattern shows up when a document says a thing is settled and names no source." Settled is a claim about the past, so it can always be cited. An uncited settledness claim is the tell — and the sentence itself is the evidence, before any code is read.
0054 backfill tests
When the constraint made three tests of migration 0054's backfill unwritable, I recommended keeping them alive under a fixture that drops and restores the constraint, arguing they "test historical behaviour that still matters."
Overruled, and the argument is better. On any fresh database the ordering is: column created nullable → 0054 backfills → constraint applied. The backfill processes zero rows, because nothing has been inserted yet. I weighed whether the behaviour mattered without asking whether it could recur. It cannot. That made the coverage ceremonial and the machinery a real cost paid for it — and CR-2026-191 had already produced stronger evidence by recomputing 0054's exact formula against the live views.
A check the Operator asked for either way then removed the counterweight entirely: the suite does not run tests in a rolled-back transaction, so such a fixture's schema change would be committed state. A hard crash between drop and restore would leave the constraint off for the rest of the run, with the suite green while enforcing nothing. Building that deliberately, to protect a path that cannot execute again, would have been the worst version of the failure this whole sequence keeps finding.
The retired tests are kept where they were, with their reasoning attached, rather than deleted — "deleting the file would be smoothing", the corrections-not-smoothed rule applied to a test file.
Observe-the-failure went v0.3 → v0.5 this run. The fourth mode is the one worth carrying forward, because it does not look like a mistake while it is being made.
Vacuity introduced by a deliberate improvement. Reframing a test to match the constraint's new behaviour produced an assertion that the rebuild raises — strictly better on its face, and satisfied by any constraint failure in the schema. A foreign key, an unrelated index, a fixture that stopped producing valid rows. The test would have gone green while the property it exists to protect went unchecked.
> The care was real and pointed somewhere else — at whether the assertion matched the new behaviour, not at whether the new assertion could distinguish anything. Written while actively reasoning about the test's rigour, inside a change request whose entire subject was classifying tests carefully. > > Rot and carelessness are the modes people look for. This one hides inside an upgrade, and the upgrade's own justification is what makes it feel finished.
The rule it produced: a rewrite is a new check. Break-and-observe does not carry over from the version it replaced. The shape to recognise: an expected-failure assertion with no claim about which failure — the broader the expected error, the more ways there are to pass without testing anything.
loomworks-engine) — ae58d34
| Tag | Subject |
|---|---|
| cr-2026-191-b70-log-reconstruction | the log now holds what the views hold; a rebuild reproduces them |
| cr-2026-192-b54-not-null | the database requires a display number |
Suites: 3586 → 3591 → 3590 passed, 0 failed. The dip is accounted for: −4 retired, +3 new. Nothing was deleted or skipped to reach green, and the arithmetic closes at each step.
B-54 closes entirely, after three deferrals — live paths, then fixtures, then rebuild. Each was recorded with what it waited on, which is the only reason it reached the end of the queue rather than quietly becoming something nobody required.
loomworks-record) — 2cd7c9dBuild list v0.43 → v0.45. Two completion notes. One inspection brief. Two change-request amendments and one new change request. Three standing notes: the operational-identifier ratification, and observe-the-failure v0.4 and v0.5.
All repositories clean and origin-verified. Every tag push-verified when cut. Engine CI green on ae58d34.
Newly known: the record repository runs continuous integration of its own, and it is passing on 2cd7c9d. This session had been treating that repository as document-only and not reporting it. Noted as a correction to how it gets reported from here, not as a result.
Three items want you. None blocks anything being built.
B-65 — the four scaffolded sections await your content. Held at your instruction. Until they hold something, the foundation document's pointer stays deliberately uncorrected.
B-63 — marking model-written answers. A new commitment if adopted, not a forgotten one.
B-69 — seed mutability. Three entries and a taxonomy with closure rules. The standing instruction rides every change request until it resolves, and now requires an entry even when the answer is no contact.
Nothing. Engine ae58d34, surface c5919b4, record 2cd7c9d — all clean, all origin-verified, all continuous integration green. Build list at v0.45. No session in flight.
DUNIN7 — Done In Seven LLC — Miami, Florida DUNIN7 — status brief — v0.45 — 2026-08-09