DUNIN7 · LOOMWORKS · RECORD
record.dunin7.com
Status Current
Path change-requests/cr-2026-189-loomworks-b32-rederive-manifestation-v0_3.md

DUNIN7-M4 — INFRASTRUCTURE CHANGE REQUEST

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

Version. 0.3 · Date. 2026-08-08 · Author. Claude.ai (v0.1) / Claude Code (v0.2, v0.3 amendments) / Marvin Percival (approving). Supersedes. v0.2 at record fb2ada4. v0.1 and v0.2 stand as siblings. Target. /Users/dunin7/loomworks. Surface only.

What changed from v0.2. v0.2 named the wrong data source for the consent step. Corrected below, with the right one — which is also better on the merits.


1. Correction: the fields v0.2 named arrive from the call the consent authorizes

v0.2 said the consent step would show "what has changed since the Manifestation was built — from changes_since_last_manifestation", and added seed_version_changed to the build.

Both live on the preview response. Preview is the metered call. So a consent step built on them could not show them before consenting — it would be a receipt, not a consent.

> Operator, 2026-08-08, recorded as a correction rather than a refinement: "I named changes_since_last_manifestation and seed_version_changed without checking where they live. They arrive from the call being authorized, so a consent step built on them would be a receipt. That's the same class as my 'existing credentials list' and 'Shape response' premises — asserted from a plausible model, not read."

Third instance of that class in this run, and the pattern is now explicit: a field named from a plausible model of where data lives, rather than from reading where it actually lives. Found here only because wiring the panel forced the question of what was available at the moment of the decision.

2. The right source, and it is better on the merits

memory-statusalready fetched, free, and powering the staleness block — carries changes: MemoryChangeCounts, which already counts seed amendments:


SUM(CASE WHEN object_type = :seed_type
         AND event_kind != :seed_init_kind
    THEN 1 ELSE 0 END) AS seed_amendments
WHERE engagement_version > :bookmark   -- the picture's derivation point
  AND engagement_version <= :current

Better on four counts, not merely available: free; scoped exactly to events since the derivation point; excludes the seed's initial creation, so it counts genuine amendments rather than the seed existing; and it yields a count rather than a boolean.

The consent step therefore uses:

3. seed_version_changed is kept, at a different moment and for a different job

Shown after the preview returns, as confirmation of what the re-derive actually reflected.

The two are not redundant — they answer different questions at different moments:

| | When | Says | |---|---|---| | seedAmendments (free) | before consent | the seed was amended N times since this was built | | seed_version_changed (metered) | after preview | the rebuild used a different seed version |

Both true; different moments; neither substitutes for the other.

4. Seed-mutability impact — the entry is stronger than v0.2's

Two seed signals reach the surface and both were dropped — one free, one metered.

The engine anticipated on two independent paths that a seed change is a reason to re-derive. The surface carried neither.

The completion record's seed-mutability impact entry records both contact points and which one this build used for which purpose. Per B-69: recorded, not designed for.

5. Unchanged

v0.2's §1 (no price can be named, and why), Operator authority, only-show-what-is-available, the failure path, and the acceptance gate all stand — except that gate item 2's "what has changed" is now sourced per §2.


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