Version. 0.44
Date. 2026-08-08
Charter. standing-notes/dunin7-standing-authorization-charter-v0_1, ratified 2026-07-30.
Author. Claude Code (execution session). Operator: Marvin Percival.
Supersedes. v0.43 at record 9531013. All earlier versions stand as siblings.
Changes from v0.43. §7 only: the engine's continuous-integration run for 3bcf4f6 completed green, and this version records it. v0.43 stands unchanged, still saying the run was in flight — which is what was true when it was filed.
> Why this is a whole version for one line, and the precedent worth keeping. The line was written as explicitly provisional, so the executing session proposed amending v0.43 in place and gave its reasoning: resolving a line that announced itself as unresolved is the line doing what it was written to do, not a change of position. The reasoning was plausible. The rule held anyway. > > The judgment is not the editing party's to make about its own edits. A versioning rule that admits "this particular change isn't substantive" has a hole in it exactly the size of whoever is arguing. The next plausible exception will look just like this one — which is the reason to record that this one was declined, with its reasoning intact, rather than to record only the outcome. (Operator ruling, 2026-08-08: "the rule doesn't get exceptions.")
Changes from v0.42, carried. The two-change-request run 189–190. Both landed. One of them was meant to add a database constraint and instead found that the system's recovery path does not work — and has not for some time. Build list moved v0.41 → v0.43.
This is not a build item. It is a discovered fact about the system's current state.
When numbering was introduced in Phase 36, migration 0054 filled in the existing records by updating the two projections directly. The event log was left alone — correctly, because the log is append-only and rewriting history is not available. But that left the number living only in the derived copy.
So rebuilding an engagement's shapes or renders from the log loses their numbers.
| playground_dev, 2026-08-08 | no number in the log | total |
|---|---|---|
| shape events | 63 | 64 |
| render events | 27 | 28 |
Nearly the entire history. One event of each type postdates Phase 36.
Ordinary operation is safe, and for a specific reason. The projection's write is COALESCE(existing, incoming) — a number already on a row survives every later event about that object. Confirmations, retirements and invalidations do not null it out. The current views are complete and correct: zero unnumbered rows.
> Both facts are true at once, and the pairing is the finding. The view is correct, and cannot be rederived.
The loss appears only on a full rebuild — which is to say, only when something has already gone wrong. Rebuild is the repair tool: what you reach for when a projection is damaged. The repair silently discards data the damaged copy still held.
And the deeper problem is the inversion. The derived thing carries information its source does not — the one relationship the whole substrate is built to prevent.
The constraint did not cause this. It exposed it. Legacy engagements were already in this condition before anyone touched B-54, and would have stayed there indefinitely.
> "The constraint breaks rebuild" leads somewhere specific and wrong: drop the constraint, call it fixed, and leave a lossy recovery path in place with nobody looking for it.
Filed as B-70. The remedy is to put the numbers into the log as new events recording what 0054 computed — append-only, invents nothing, and makes rebuilding correct rather than making it something to avoid.
One remedy is ruled out firmly, not declined. Having the projection assign a number when the log lacks one would make the derived copy a writer of facts rather than a reader, would let two rebuilds disagree with each other, and inverts log-is-truth / view-is-derived. The convenience is real; the cost is the substrate's central guarantee.
B-54's database half is deferred behind B-70, not judged unnecessary. Every path that creates a record now assigns a number — in production (CR-2026-176) and in the tests (CR-2026-190). The rule that would make the database itself require it waits. Somebody still owes it, and the build list says so, because deferred and unnecessary look identical in a closed item a year later.
The interim is written down rather than assumed: a standing note, and the limitation stated inside both rebuild functions, where someone reaching for the recovery path will meet it instead of finding it in another repository's notes.
This is the transferable part. Two checks; one was incomplete in a way worth naming, one was correct and answered a different question than the one that mattered.
It asked: is any failure a production path rather than a fixture? 226 tests failed, all the same violation, and every production construction site was read directly rather than inferred. The answer — all fixtures — was correct.
Several of those failing tests exercised rebuild, which is production code. They failed for a fixture reason. So they were classified as fixtures and their fixtures were fixed — which made them green and removed the only signal that the path underneath them was also broken.
What surfaced the defect was the one test whose fixture was not a defect: it modelled a genuine pre-Phase-36 payload faithfully, so there was nothing in it to fix.
> A check that could fail, did fail 226 times, and named its invariant precisely — and was still incomplete. Fixing the defect it covered masked the defect it did not.
Now a third mode in the observe-the-failure standing note (v0.3). The first two modes are about checks that cannot fail. This one is about a check that can, does, and is answered by repairing the wrong thing. The practical warning: fixing your way to green through a large uniform failure set destroys evidence as it goes — fastest at the start, when confidence is highest.
Before any migration, the change request required confirming zero unnumbered rows in live data. It came back 0 of 33 shape rows and 0 of 21 render rows, and that is accurate.
It counted rows in the view. The defect is that the view can no longer be reconstructed — which no count of the view can see, however carefully it is run.
> Not a flawed check. A correct answer to a question adjacent to the one that mattered. Worth recording because the adjacent question felt like the same question right up until the difference appeared.
A stale organized picture could not be rebuilt at all; now it can, behind a consent step the Operator approves. Nothing rebuilds on its own.
The consent names no price, and says so plainly. The only cost figure in the system needs the whole prompt assembled — the foundation document plus every settled note — which is most of the work done twice, to estimate the work. It names what it can: the balance the spend draws from, and what actually moved.
Twice, an amendment was needed because the change request named fields that arrive from the call being authorized. The consent step was to show what had changed since the picture was built — from a response that only exists after the metered call runs. A consent built on it would have been a receipt.
> Recorded as a correction, not a refinement. "I named them without checking where they live… asserted from a plausible model, not read." Third instance of that class this run.
It surfaced only because wiring the panel forced the question the change request's prose never had to answer: what is available at the moment of the decision? The right source turned out to be better on the merits anyway — free, already fetched, scoped to events after the derivation point, and excluding the seed's own creation so it counts genuine amendments.
The seed-mutability instruction has been riding along with every change request since it was filed. These two runs gave it a taxonomy with closure rules, which turns it from a waiting list into two actionable lists and a coverage map.
| | | Remedy | Closeable? | |---|---|---|---| | Kind A | awareness that stops at a boundary — the engine computes a seed signal, nothing downstream carries it | show what is already there | yes, as found — surfacing an existing signal is not designing for an open question | | Kind B | code that assumes a seed cannot move | unknown | no — its remedy is the decision B-69 exists to make | | Kind C | checked, no contact | none needed | yes — but it must be written, or it is indistinguishable from never having looked |
Kind A was not anticipated when the item was filed, and both of CR-2026-189's entries are Kind A — two seed signals computed server-side on independent paths, neither displayed anywhere. Both are now shown.
**Kind C exists because an inventory holding only hits cannot distinguish no dependency from never looked. When B-69 is finally scoped the question will be what was examined**, and a list of hits answers that only by accident.
The instruction changed shape, not just wording: every change request now records its check including when the answer is no contact. A null finding is an entry.
And Kind C carries a worked example to keep it honest. seed_version_at_production stamps the seed version in force when a shape was produced — genuinely seed-aware, and not seed-dependent, because numbering never reads it and nothing about it changes if the seed moves. Seed-adjacent is not seed-dependent. Without that line, Kind C fills with every field whose name mentions a seed until the inventory means nothing.
loomworks-engine) — 3bcf4f6
| Tag | Subject |
|---|---|
| cr-2026-190-b54-fixtures | every test fixture assigns a number; both rebuild functions carry the limitation |
Suite 3360 passed + 226 failed → 3586 passed, 0 failed, 68 skipped both times. The arithmetic closes exactly — nothing was deleted or skipped to reach green.
loomworks) — c5919b4
| Tag | Subject |
|---|---|
| cr-2026-189-b32-rederive-manifestation | a stale organized picture can be rebuilt, by an Operator act |
loomworks-record) — 38d21a9Build list v0.41 → v0.43. Two completion notes. One change-request amendment. Two standing notes — the legacy-rebuild limitation, and observe-the-failure v0.3.
All three repositories clean and origin-verified. Every tag push-verified when cut.
Four items want you. None blocks anything being built.
B-70 — the log-reconstruction item. New, and the largest thing these two runs produced. Its shape is settled and its wrong answer is already ruled out; what it needs is scheduling.
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. Now has three entries and a taxonomy. The standing instruction stays in force until it resolves.
The engine's continuous-integration run for 3bcf4f6 completed green, confirming the local result: 3586 passed, 0 failed, both gates clean. v0.43 filed this line while the run was in flight and declined to claim the gate before seeing it; this version records the outcome.
Otherwise nothing. Engine 3bcf4f6, surface c5919b4, record 38d21a9 — all clean, all origin-verified. Build list at v0.43. No session in flight.
DUNIN7 — Done In Seven LLC — Miami, Florida DUNIN7 — status brief — v0.44 — 2026-08-08