Version. 0.1
Date. 2026-07-31
Author. Claude.ai (drafting). Operator: Marvin Percival.
Executed by. Claude Code on DUNIN7-M4, one engine session.
Target. /Users/dunin7/loomworks-engine at main a317051, annotated tag registry-completeness-v0_1.
Status. Read-only inspection. Establishes ground for three build-list items. Produces no code change and no change request.
Build-list items served. B-29 (the provenance field fabricated everywhere), B-27 (the door that cannot be closed, walk-audit finding W-2), B-5 (the Manifestation screen — its engine-side contract only).
Evidence base. standing-notes/dunin7-build-list-v0_8; scoping-notes/loomworks-completion-scoping-note-v0_2; inspection-briefs/loomworks-b25-sizing-sweeps-findings-v0_1; current-status/current-status-manifest-v0_76; candidate-seeds/loomworks/loomworks-candidate-seed-v0_12. Record read at 403790a.
Read-only throughout. No fixes. No branches. No commits. No stashes. No rebases. No dependency installs.
No database connection of any kind. playground_dev is the live production database — a standing naming trap recorded at manifest Entry 127. playground_test and playground_walkaudit are equally out of scope for this session.
No test-suite run. A suite run connects to a database.
No live-perimeter call. The :8000 engine serves the live app.dunin7.com perimeter. Its correspondence with a317051 was established at manifest Entry 126 on 2026-07-30 and is taken as given here. Nothing in this brief needs a request against it.
Working tree. Confirm clean before starting and report anything unstaged. Do not clean it.
Halt on anything that would write. If a question cannot be answered without a write, a run, or a connection, say so and stop on that question rather than working around the fence.
State only what you have read back.
This applies to sessions, not only to screens. It is the same rule the completion arc enforces on surfaces, turned on the session doing the reading.
In one working day, six positions were asserted to the Operator and then withdrawn — recorded at completion scoping note v0.2 §3, under corrections to positions taken during this note's own drafting. Every one was an inference made where a read was available.
Three requirements follow, and they apply to every answer in the report:
What B-29 is. provenance.wasGeneratedBy is declared at memory/base.py:147 with a trailing comment stating its meaning: the memory event id that produced this version. append_event mints its own event identifier internally at memory/events.py:171 and never back-patches the object; the payload is serialised from the object as the caller built it. Eighty-three sites across thirty-six files stamp an unrelated generated value into the field; three sites in persons/personal_engagement.py are reported to do it correctly.
What this question must establish. What the seam change actually entails, and what the eighty-three sites look like — so the change request knows whether they need touching at all.
Read append_event end to end in memory/events.py. Establish:
append_event. If such a path exists, the seam is not one seam.append_event has any callers that pass provenance wholesale rather than field by field.
Read the provenance declaration at memory/base.py:147 and its surrounding type. Establish:
wasGeneratedBy is required or optional.Sweep to ground the count:
grep -rn "wasGeneratedBy" --include=*.py .
grep -rn "was_generated_by" --include=*.py .
Report both spellings separately. The findings counted one; a second spelling in the tree would change the number.
Read all three sites in persons/personal_engagement.py that thread a real identifier into the field.
Do not assume they are correct. The sizing findings describe them as threading "the real seed, cycle and engagement event identifiers." A seed event, a cycle event and an engagement event are plausibly the events that caused the version, not the event the append is currently producing. Those are different meanings, and the field's comment names only the second.
Establish, per site:
This is the single most likely place this brief's evidence base is wrong. Treat it as the question, not the confirmation.
Establish whether anything consumes wasGeneratedBy today:
memory/projector.py — whether it copies, derives from, or ignores the field.A field nothing reads has a different repair cost from one with live consumers.
Establish whether the field enters any hashed, signed or anchored payload — FORAY emission at the substrate seams, or any digest computed over the serialised object. If it does, changing what gets stamped changes payload composition going forward, and the change request needs to know at which boundary.
B-25's eleven sites and B-29's eighty-three live in some of the same files, and both are edits to how a record's authorship and provenance are constructed at the same call sites. This map sizes that collision.
For each of B-25's eleven, report whether the same site also stamps wasGeneratedBy, and whether a B-29 seam change would touch the same lines:
| B-25 site | Path |
|---|---|
| 1 | api/routers/engagements.py:285 |
| 2 | api/routers/engagements.py:347 |
| 3 | api/routers/engagements.py:392 |
| 4 | api/routers/considerations.py:195 |
| 5 | api/routers/seed_commit_from_brief.py:271 |
| 6 | api/routers/me_create_engagement.py:393 |
| 7 | api/routers/me_create_engagement.py:728 |
| 8 | api/routers/seed_extraction.py:246 |
| 9 | api/routers/seed_extraction.py:283 |
| 10 | orchestration/router.py:359, orchestration/router.py:3292, orchestration/routers/converse.py:1378, against api/deps.py:1176 |
| 11 | orchestration/routers/converse.py:690 |
Also check engagement/assertions.py:404, the hardcoded companion name compounding site 10.
Line numbers are as recorded at a317051 in the sizing findings. If a line has moved, report the current line alongside the recorded one rather than silently substituting.
The findings name two repairs: append_event accepts the identifier from its caller, or append_event stamps the field itself before serialising.
Report what each would cost — which files change, which call signatures change, which tests would need to move, and whether either is foreclosed by what §3.1 finds about ordering and mutability.
Do not choose between them. The choice belongs to the change request and to the Operator. This brief establishes the ground it is made on.
What B-27 is. Walk-audit finding W-2. The terminal commit route for creation doors 1 and 2 was found uncallable: it returns a validation failure demanding a path parameter its own route does not declare, arriving through a dependency chain. The Operator's browser pass on 2026-07-30 appears to have created an engagement through door 1 and amended its foundation, which suggests creation completed.
Why the two readings can both be honest. The environments differed. The walk audit ran against engine 1aac815; the browser pass ran against the current engine. Manifest Entry 126 records that CR-2026-158 shipped, among other things, "the create-from-conversation rider resolved by removal" — which cannot be interpreted without reading that change request.
Why it is load-bearing. The completion arc's acceptance gate cannot be run while W-2 stands, because the walk cannot complete. It is the first Step 0 item of change request A, and B-5 is the front of the build-list queue.
Locate the terminal commit route for doors 1 and 2. Read its decorator, its path, and every declared parameter. Read every dependency in its chain and establish which one demands a path parameter the route does not declare. Name the dependency, its file and its line.
Establish, statically: is the route callable as declared at a317051? This is decidable from the route and dependency signatures. It does not need a call.
git log --oneline 1aac815..a317051
Then diff the route file, the dependency file, and anything CR-2026-158 touched on that path:
git diff 1aac815..a317051 -- <route file> <dependency file>
Establish whether the defect was present at 1aac815, and whether anything between the two commits removed or altered it.
Read docs/phase-crs/ or the equivalent in-repo location for CR-2026-158, and the record copy at change-requests/cr-2026-158-memory-registry-completeness-v0_2.md if it is present locally. Establish what "the create-from-conversation rider resolved by removal" removed, and whether the removal touched this route or its dependency chain.
Also read the completion record at completion-records/cr-2026-158-checkpoint-a-report-v0_1 if locally available.
Report one of three, with anchors:
a317051. B-27 is real and blocks the acceptance gate.a317051, and name what resolved it and when.What B-5 needs. The Manifestation room must show the derived Manifestation, its version, what it was derived from, and whether Memory has moved since. That is face 3 of the completion arc's governing rule, and it is the seed's commitment at the Manifestation section: prior Manifestations are preserved but superseded.
What this question must establish. Whether the engine already returns what that room needs, or whether B-5 needs engine work — and if it does, how much.
Locate every Manifestation-related route in the engine. For each, report path, method, parameters, and response schema. Specifically establish whether these exist:
Walk-audit finding W-16 states the last of these does not exist, while the equivalent for assertions does and works correctly. Confirm or overturn, with anchors, and read the assertion-side version route as the pattern the Manifestation route would follow.
For the current-Manifestation read, establish field by field whether the response carries:
The completion arc's state contract requires that a populated room value carry both its derivation version and the current version of its source, because that is what makes staleness computable rather than optional. Establish whether both are obtainable, and from how many calls.
Something computed the figure that engagement E0005's newest Manifestation is twenty-five versions stale. Manifest Entry 126 records the number and names it as handed to the completion arc, unfixed.
Find what computed it. Establish whether it is a reusable engine read, a query written once for the CR-2026-158 investigation, or an arithmetic done by hand from two separate reads. The answer decides whether B-5's staleness marker is a wire or a build.
Where the engine falls short of what the room needs, size it: which routes are missing, which response fields are missing, whether a migration would be implicated, and roughly how large the change is.
Do not propose the change and do not draft it. Any engine work question three finds queues behind B-29 — see §7. Recording it as sized-and-queued is the whole of this section's output.
The Operator Layer side of change request A's Step 0 is not in this brief and remains owed: the real shape of the room components and their current data fetching, and the RoomView.tsx vocabulary wall against the seed's plain-terms discipline. Both are reads in /Users/dunin7/loomworks and need their own brief.
Manifest v0.76 §5 records that every number in its Substrate state block predates 2026-06-11, and says the refresh "should ride the next session that touches the engine rather than standing as its own errand." This is that session, so it rides — restricted to what a file read can settle.
In scope:
main at a317051.stele repository front: current main commit and any tag on it.Excluded, and why:
playground_dev — needs a database connection.99f7f64 — different repository, and they need a run.Report the two in-scope numbers plainly. The manifest's residue stays open for the excluded ones; say so in the report rather than letting a partial refresh read as a whole one.
The session running this brief is not building anything, but its findings feed three items whose order is settled. Recording it here so the report frames its own findings correctly.
The engine belongs to B-29 for the duration. Any engine change question three finds queues behind B-29 rather than opening a second engine front. Two sessions building the same engine at once makes a green suite meaningless, and this project verifies against the live database at each step, not the suite alone.
B-29 lands before B-25 and before the completion arc's engine rider, not merely alongside them. It changes a seam every engine write path uses, and both of those items are engine writes in some of the same files. Their change requests may be drafted while B-29 builds; they must not be built concurrently.
Where a read overturns a position in the evidence base, name the prior position alongside the current one. Do not smooth it. Two are already visible before the session starts, and both are recorded here so the report inherits them rather than rediscovering them.
Prior position — completion scoping note v0.2 §4 and §5. "CR-B may run in parallel with CR-A — different repository, no shared surface," and "three fronts can move at once without collision, provided the record-writing discipline holds."
Current position, Operator ruling 2026-07-31. The parallel-track claim holds across repositories but not within the engine. The engine rider, B-25 and B-29 are all engine work, and B-29 crosses a seam the other two touch in shared files. One engine front at a time, B-29 first. The note's §5 sequencing diagram is superseded and owes an amendment at its next bump.
Prior position — B-25 sizing findings v0.1 §5. Three sites in persons/personal_engagement.py "do it correctly," and that "three sites prove the field means what its comment says."
Current position — unsettled, and §3.3 is the read that settles it. The findings inferred the semantics of those three sites from what they thread rather than from what the field means at the moment of the append. If they pass a causing event rather than the produced event, the framing of eighty-three wrong against three right does not hold in the form it was filed.
Anything further the session overturns is added to this section in the findings document, in the same shape.
Produce one findings document. Markdown primary, technical consumer.
Path. inspection-briefs/loomworks-b29-b27-b5-engine-inspection-findings-v0_1.md in loomworks-record.
Also drop a copy in ~/Downloads so Claude.ai can read it without a second retrieval round trip. Standing retrieval convention.
Structure, in this order:
Halt before pushing. Commit locally, report the SHA, and wait. The Operator authorizes the push.
Re-verify the record HEAD immediately before writing. Multiple sessions may write to loomworks-record in the same period. Prefer a new sibling file over any history-editing operation.
DUNIN7 — Done In Seven LLC — Miami, Florida Loomworks — combined engine inspection brief — B-29, B-27, B-5 — v0.1 — 2026-07-31 Read-only. One engine session. Three questions, one ride-along, two corrections carried in.