DUNIN7-M4 — INFRASTRUCTURE CHANGE REQUEST

CR-2026-189 — B-32: re-derive a stale Manifestation (v0.2)

Version. 0.2 · Date. 2026-08-08 · Author. Claude.ai (v0.1 drafting) / Claude Code (v0.2 amendment) / Marvin Percival (approving). Supersedes. v0.1 at record 5c6f760, which stands as a sibling. Target. /Users/dunin7/loomworks. Surface only — Step 1 found no engine gap. Baseline. Engine ad83960, surface 0dd7dd9.

What changed from v0.1. Step 1 established that the cost of a re-derive is not knowable before the call, which §3 assumed it was. §3 is corrected below. §5's seed-mutability check produced a concrete finding that becomes part of the build rather than only of the record.

1. Correction to §3: the spend cannot be named, and asking for a figure would cost more than it is worth

v0.1's §3 said: "Before a re-derive runs, the Operator sees what it will cost and confirms… the point is the spend, and the spend should be named."

Written assuming a figure existed. It does not, and cannot be produced without duplicating the work.

The only cost figure in the system is _compute_spend_cap (credit/room_gate.py:117), and it requires system_prompt and user_prompt — the actual assembled prompts. It runs inside gated_room_complete at park time. Two consequences:

• It never runs for Manifestation, which is excluded from _PAUSEABLE_ROOMS because a synchronous room cannot await an Operator decision without the Phase B sync→job re-architecture.
• Producing one ahead of the call would mean assembling the seed and every committed assertion into the organize prompt — most of the preview's own work, done twice, for a figure that is an estimate anyway (~4 chars/token).

> Operator, 2026-08-08: "Spending real compute to estimate the cost of spending compute is a bad trade for a figure that's an estimate anyway."

Also rejected: holding B-32 for the Phase B re-architecture. "B-32's defect is that a stale Manifestation cannot be rebuilt at all. Holding that behind the Phase B re-architecture to get a better number is the wrong ratio."

What the consent step names instead

Not a price — but not nothing, and not a generic "are you sure." Two real things:

1. The balance the spend draws from. Readable today via fetchMeCredits().
2. What has changed since the Manifestation was built — from changes_since_last_manifestation, which the engine already computes: engagement-version delta, assertion-count delta, relationship-count delta.

The Operator decides against real information, just not a price.

2. Additionally: surface seed_version_changed

changes_since_last_manifestation already carries seed_version_changed. It is displayed nowhere.

It is the most decision-relevant part of the staleness signal, because it means the organizing purpose changed — not merely that more material arrived. A re-derive triggered by a seed change produces a differently-organized Manifestation for a different reason than one triggered by new notes, and the Operator should be able to tell those apart before spending.

This is now part of the build, not only of the record.

3. Seed-mutability impact — B-69's first contact point, and it is concrete

Re-deriving reads the seed, and the seed shapes the result. _seed_for_value() resolves the seed pinned by the Manifestation's seed_ref, and organize_assertions embeds its content in the prompt — the engine's own comment: "the organization prompt embeds the Seed so the LLM understands the engagement's purpose."

So a changed seed alters a re-derived Manifestation for reasons unrelated to Memory moving. The grouping and its rationale derive from the seed's stated purpose.

The contact point is not a hidden assumption. It is a flag the engine already computes and nobody displays — seed_version_changed. The engine anticipated that a seed shift is a reason to re-derive; the surface never carried it.

Recorded under seed-mutability impact in the completion record, per B-69. Not designed for, not built around — surfacing an existing flag is displaying what is there, not building for a decision nobody has made.

4. Unchanged from v0.1

§3's Operator-authority point (nothing re-derives automatically on a staleness signal — the system surfaces and signals; the Operator approves), only-show-what-is-available, the failure requirement following B-37's pattern, §4's exclusions, and §7's remaining gate items all stand.

Step 1's halt did not trigger — no engine work is needed. This CR is surface-only.

5. Revised build steps

| Step | What | Mode | State | |---|---|---|---| | 0 | Pre-flight, both repos | Auto | done | | 1 | Read per §2; halt if engine work needed | Auto, conditional halt | done — no halt | | 2 | Consent step: balance + what changed + seed_version_changed + tests | Auto | pending | | 3 | Re-derive control, shown only when stale + tests | Auto | pending | | 4 | Failure path per §3 + test | Auto | pending | | 5 | Surface sweep; gates clean | Auto | pending | | A | Checkpoint | Checkpoint | pending | | 6 | Tag cr-2026-189-b32-rederive-manifestation. Push. | Auto | pending |

6. Revised acceptance gate

1. A stale Manifestation can be re-derived, and only by an Operator act.
2. The consent step names the balance and what has changed — including seed_version_changed. It does not claim a cost, and does not imply one.
3. No control appears when there is nothing to re-derive.
4. A failed re-derive is visible where the Operator was looking.
5. Seed-mutability contact point recorded per §3.
6. Suites green, both gates clean.

DUNIN7 — Done In Seven LLC — Miami, Florida CR-2026-189 — B-32 re-derive a stale Manifestation — v0.2 — 2026-08-08