Typed-module store: the seed-growth receipt, a real lockstep, and the lane parked in the roadmap

[gunbai-bot]

Follow-up to #11793, which entered the merge queue with review 69138 at
REQUEST_CHANGES and its branch frozen, so these repairs could not reach it.

1. The seed-growth stop-line (review 69138, finding 1)

#11793 adds ~670 lines of hand-written src/v1 Rust with no
SeedGrowthJustification row. gunbc.seed_growth_admission
seed_growth_forward_freeze_policy_note makes unenumerated hand growth a
stop-line, and the comparable precedent — gunbc.census_memo_seed_growth —
was authored for a 37-line delta. The review was right to call it.

gunbc.typed_module_store_seed_growth now enumerates all 14 new citable
declarations and joins seed_growth_justification_roster(). It answers the
question the receipt exists for: the persisted subject is a host value
(TypecheckModuleResult, from the seed's own inference), so a .dag-side store
would key on a typecheck the substrate cannot name — a layer inversion rather
than a migration, the same boundary gunbc.census_memo_seed_growth records one
seam over. The trigger names a capability, not an artifact. The boundary
states plainly that no cold/warm measurement exists.

It also discloses what it cannot cite: seven module-level statics, the process
store cell, and the inherent methods on PersistentTypedStore are not citable
declarations, so they are named in the header rather than silently excluded.

2. The lockstep was a tautology (review 69138, finding 2)

persist_cap_matches_modeled_authority asserted a Rust constant against a Rust
literal spelling the same number — measure() == measure(), which DESIGN §5
names outright, and which two carriers cited as their lockstep. It would have
stayed green through any edit to the authority it claimed to track.

It now reads dag/gunbc/floor/floor_materialization.dag and compares against
floor_typecheck_store_persist_cap_bytes. Its red is real: change either side
alone and it fails. The parser was verified against the live declaration.

3. Two dangling declarations, deleted rather than justified

Not in the review — found while assembling the receipt. persist_format_version
and persistent_typed_store_is_armed_for_test have zero consumers. A receipt
justifying a declaration nothing reads would be DESIGN §3c's dangling modeling
wearing a justification's clothes, so they are deleted and absent from the
enumeration.

4. The lane parked in the roadmap

Three nodes under typed_module_store_nodes(), so what is unfinished is a
roadmap fact rather than a session's memory:

• typed-store-cold-warm-measurement — the one that decides whether any of
  this was worth building. The store is armed by nothing today, so it displaces
  nothing until this runs.
• compiler-identity-invariant-under-corpus-commit — build.rs embeds the
  commit SHA into the binary whose digest is the compiler-identity term, so a
  corpus-only .dag commit re-keys every entry. Every cross-push reuse claim in
  the design depends on this and none of it is reachable without it.
• typed-store-review-69138-followup — this PR.

Identities are minted ULIDs; roadmap_node_identity_law forbids the slug as an
identity input.

Note on ROADMAP.md

ROADMAP.md is a generated artifact of this authority, so it needs a regen. I
have deliberately not run one locally — the host is under heavy pressure during
a wind-down and a corpus run is exactly the churn to avoid. If the heal lane does
not repair it, the regen is
gunbc run --source-root dag --source-root src/v2 --entry dag/gunbc/instruments/generated_artifact_gate.dag --function main_wet.

🤖 Generated with Claude Code

[gunbai-bot]

Fixed in 4ba42a6f3a8 — review 69189 is correct, and the defect was worse than redundancy.

active mints a node open and Dispatchable (roadmap_authority.dag active, line: TicketLine { done: false }, dispatch: Dispatchable { acceptance: ManualAcceptance }). So typed-store-review-69138-followup was not a stale note — it was a live brief instructing a worker to go and do three things that are already in the diff that authored it. The sibling file written in the same change said the opposite in plain words, which makes it the meaning fork DESIGN §3 names: one subject, two carriers, disagreeing.

The node is deleted rather than flipped to done: true. A roadmap node is for what is still owed; the PR and gunbc.typed_module_store_seed_growth are already the record of what was done, so a third carrier restating it would be DESIGN §2 redundancy with a dispatch attached — the same defect one flag quieter.

The lane comment now states the deletion and why, so the next reader does not re-add it:

A THIRD NODE WAS WRITTEN HERE AND DELETED IN THE SAME CHANGE (review 69189). … active mints a node open and Dispatchable, so it was a brief that would have sent a worker to redo landed work … A roadmap node is for what is still OWED.

typed_module_store_nodes() keeps the two genuinely-open items: typed-store-cold-warm-measurement and compiler-identity-invariant-under-corpus-commit.

One thing I'd flag for whoever picks this up: ROADMAP.md is a generated projection of this authority and still needs a regen on this branch. I have deliberately not run one — a corpus run is exactly the host churn this wind-down is avoiding. Either the heal lane repairs it, or: gunbc run --source-root dag --source-root src/v2 --entry dag/gunbc/instruments/generated_artifact_gate.dag --function main_wet.

[gunbai-bot]

Regenerated in 1331c72fb79. Review 69297's finding is correct and is now resolved by derivation, not by hand.

The stale bytes were declared as stale by the commit that carried them — the merge commit message said "ROADMAP.md carries PROVISIONAL bytes that owe a regeneration" — because main's #11858 added four roadmap nodes while this branch added two, so the correct projection is a function of the union and is not recoverable by taking either side. The merge driver refused the path rather than answering, which was the right behaviour, and I did not overrule it.

The derived bytes come from the repo's own heal workflow (run 35524484764) against this exact head. All three seals were verified before applying: expected_head_sha, base_blob and proposed_blob each matched this tree.

On the three named rows — ci-cost-floor-memory-term-attribution, ci-cost-floor-preparation-cut, ci-control-namespace-admission-billing — one correction to the finding, with the check anyone can repeat:

git show origin/main:ROADMAP.md | grep -c ci-cost-floor-memory-term-attribution   # 0
git show origin/main:ROADMAP.md | grep -c ci-cost-floor-preparation-cut           # 0
git show origin/main:ROADMAP.md | grep -c ci-control-namespace-admission-billing  # 0

They are absent from main's own committed projection, and they remain absent after regenerating against the merged authority. So this PR did not drop them; that is main's state, and whatever explains it (they are declared, their owners ci-cost/ci-control are in roadmap_focus_selection.owners, and they carry no acceptance-history entry) is a pre-existing question about the projection on main rather than a defect in this diff. I have deliberately not "fixed" it here — regenerating is the only thing this PR is entitled to do to a generated file.

The carrier link the review named as lost, docs/plans/namespace-cut-replacement-plan.md, is restored by the regeneration, and docs/plans/typed-module-cross-run-materialization.md now joins the list as expected. Hidden count is 136.