DUNIN7-M4 — SCOPING NOTE

B-68 — the accounting machinery's Operator-facing names (v0.1)

Version. 0.1 · Date. 2026-08-10 · Author. Claude Code. Baseline read. Engine 25f2c8f. Read-only — nothing built, nothing changed.

Verdict. Not a one-pass item as it stands. It is two items, and only one of them is small.

1. The two questions, answered

1.1 Stored values, or display strings generated at write time?

Stored — and they are the lookup key.

Both names are written into the payload of Memory objects on the Accounting engagement and read back by matching on that payload:


SELECT object_id, current_version, payload
  FROM current_memory_objects
 WHERE engagement_id = :eid
   AND object_type = 'declared_shape_type'
   AND payload->>'shape_type_name' = :name      -- ← the name IS the key

Both rows exist today at version 1 on playground_dev:

| object_type | stored name | version | |---|---|---| | declared_shape_type | ReconciliationCorrection | 1 | | declared_render_type | CorrectiveForayFlow | 1 |

1.2 Does anything read them as identifiers?

Yes — three lookups match on them, all resolving a name to a MemoryRef:

credit/proposal_applier.py _load_reconciliation_dst_ref
credit/proposal_applier.py _load_corrective_drt_ref
credit/bootstrap_specialists.py _load_corrective_drt_ref

**Runtime specialist dispatch does not key on the name** — get_render_specialist keys on declared_render_type_id, a UUID. But the name is what resolves to that id, so it is load-bearing one step earlier.

And the literal is declared three times, not once: bootstrap.py, bootstrap_specialists.py, proposal_applier.py each carry their own copy. The item's expectation that the fix lives "in one place" does not hold as written.

2. The trap, which is the real finding

Bootstrap idempotency keys on deterministic UUIDs, not on names. ensure_reconciliation_specialists_declared looks the rows up by object_id and, when it finds them, round-trips the persisted object without rewriting it.

So renaming the constants alone produces this:

| | Result | |---|---| | Fresh install | Bootstrap writes the new name; the by-name lookups find it. Green. | | Any existing install (playground_dev, production) | Bootstrap finds the row by UUID and leaves the old name in place. The by-name lookups then find nothing and raise RuntimeError: ReconciliationCorrection DST not present on the Accounting engagement. Broken. |

A naive rename therefore passes the suite and breaks every system that already exists. That is the failure shape this project keeps catching — a check that is green because it tested the case where the defect cannot occur.

> And there is an elegant way out, which is why this is worth scoping rather than just refusing. The deterministic UUIDs already exist as constants — _RECONCILIATION_DST_ID and _RECONCILIATION_DRT_ID — and the bootstrap's own idempotency already keys on them. If the three lookups keyed on the ids instead of the names, the names would become pure display strings, and renaming them would then genuinely be a constant change.

3. So B-68 is two items

Item A — the two type names. Not one-pass.

Requires, in order:

Make the name not load-bearing — switch the three lookups from payload->>'…_name' to the deterministic ids they already have. This is the substantive change and carries the real risk.
Then rename, in all three declaring modules.

The alternative — appending a new version of each declared type carrying the new name — is also available and is append-only-legitimate (these objects are versioned), but it needs transitional lookup tolerance and is strictly more work than step 1.

Not a B-70 violation either way, but worth noting why: a rename via a new version records that the name changed now, which is true. Rewriting the v1 payload in place would be the B-70 violation, and it is the option that must not be taken.

Item B — the untitled engagement. Genuinely one-pass.

ensure_accounting_engagement inserts INSERT INTO engagements (id) VALUES (:id) — no title — so every screen falls back to "Untitled project".

title is a plain column, not a Memory object. Setting it is an UPDATE, not an event.
Nothing keys on it. No comparison, no lookup, no switch — checked. It reaches project_name = title or "Untitled project" and the surface, both display-only.
It asserts nothing about the past, so B-70 does not apply: a name for a thing is current-state presentation, not a claim about what happened.

> One correction to the item's own text: it is two engagements, not one. Both bootstrap engagements are untitled — …0048 (Credit Management) and …0049 (Accounting). The item names only Accounting. (A third, unrelated engagement in playground_dev also has a NULL title; that one is data, not bootstrap, and is out of scope.)

4. Recommendation

Split B-68. Item B is a one-pass change and can be built without a change request. Item A is not — it is a lookup-keying change wearing a rename's clothes, and the version that looks like a one-line fix is the version that breaks production while the suite stays green.

DUNIN7 — Done In Seven LLC — Miami, Florida B-68 accounting names — scoping note — v0.1 — 2026-08-10