MemberChanged{from,to}: declaration-owned occurrence identity and typed replacement classification

[gunbai-bot]

Splits MemberAction's collapsed upsert into the four arms of the operator ruling, mints occurrence identity at the declaration, and lands the classification table that makes MemberChanged useful.

The arms

= MemberAdded          { to: M }
| MemberChanged        { from: M, to: M }
| MemberRemoved        { from: M }
| MemberRemovalRefused { from: M, cause: TeardownRefusalCause }

The discarded from was the load-bearing loss, not a tidiness point. Every safe realization of a change consumes the prior value: an SCM ref update is a compare-and-swap that names the expected prior (git update-ref <ref> <new> <old>), and a host resource whose address moved needs the prior endpoint to retire. With only to in hand, the sole reachable realization is the unconditional write — the atomicity the underlying capability already offers cannot be reached. MemberEffect splits the same way (EffectAdd / EffectReplace{from,to} / EffectRemove) so the apply grain can retire a prior realization rather than overwrite it blind.

MemberRemovalRefused is a first-class action, not an absence — that keeps a refusal countable rather than a hunk that silently did not appear.

Identity: minted, not derived

gunbc.host_resource carries HostResourceIdentity{host, occurrence} and HostResource<R,V>{identity, role, value}. The occurrence is allocator-minted at declaration; unit name, FIFO, storage path and configuration are mutable value fields; role is a type parameter, so a new role is an instantiation rather than an edit to a central enum.

This is the closed-system answer to renames: git does not track renames, it infers them from content similarity after the fact, and DESIGN §4 rules a heuristic never necessary in a closed system — a content- or path-derived key_of is that same inference wearing a bundle. Because the occurrence is allocated, a rename is one MemberChanged whose sides share an identity.

Why not std.occurrence_identity (decided by reading, recorded in-carrier): that module is specifically about source occurrences — OccurrenceCategory enumerates callable/type/field/method, its allocator is coupled to AuthoredTokenOrdinalSpace. Its subject-agnostic residue is only an Int counter, and sharing one Int space across two subjects would let occurrence_id_eq answer true on a numeric coincidence — the cross-family comparison the ContentHash family grounding closed. The subject-parameterized extraction is registered as a trigger, not built under a load-bearing module with stage0 work in flight.

The classification table

subject / condition	realization
SCM ref update	atomic compare-and-swap
source declaration move	atomic SCM tree transformation
host resource, same runtime address	in-place update
host resource, changed host address	staged replacement with declared intermediates

Kills a live conflation: a .dag module re-home is an SCM tree transformation, not a host migration — that is what made an ordinary source cleanup look like it needed an operational migration plan. The converse error is the dangerous one: renaming a systemd unit or moving a FIFO is a host replacement.

StagedIntermediates is head+tail, so an empty intermediate plan has no constructor; an undeclared one refuses, typed and located, rather than degrading to an overwrite. That is the srv4 lesson — its build-cache server died with its cgroup, never unlinked its socket, and ran uncached for weeks — made unwritable instead of sitting in prose where no machine can read it.

A wall I built and withdrew

An earlier draft also refused a Modified hunk whose from was not Owned, claiming a live fail-open in 5 of 7 consumers. Refuted by execution and withdrawn. gunbc.ownership defines Ensured as "requires present but does NOT own (never torn down)" — a constraint on removal. tool_readiness classifies every pin Ensured and exists to re-install drifted pins; the wall broke it where it fired and was unreachable where it did not. The original asymmetry was correct.

Per DESIGN §4c a carrier note is not evidence, so the withdrawal is enrolled: w_ensured_member_converges_but_refuses_removal puts one Ensured member through both arms in one plan.

Discriminating, not merely green

Each new guard was verified by planting the exact regression it claims to catch:

planted regression	result
reintroduce the change-refusal arm	w_ensured_member_converges_but_refuses_removal RED, others green
reintroduce the collapse (Modified -> MemberAdded{to})	both-sides + effect-replace rows RED, add/unchanged green
staged-replacement refusal -> InPlaceUpdate fallback	srv4 row RED alone

Caught during migration

repo_local_git_config's apply fold has a _ => acc wildcard for its construction-unreachable removal arms — MemberChanged would have fallen into it, silently dropping exactly the drift that module exists to converge. Both write arms are now explicit and routed through one fn. live_deploy's EffectReplace is structurally unreachable at both degenerate poles, so it emits a loud typed poison per that module's discipline rather than a fabricated no-op.

Verification

• membership_reconcile 10/10 · change_realization 8/8 · live_deploy 44/44 byte-identity goldens · tool_readiness, repo_local_git_config, workflow_reconcile, srv3, host_phase_status, roadmap_belt, host_axis_caps all green
• corpus compile carries the same 10 pre-existing diagnostics as main, none mine (verified by stashing)
• DESIGN.md regenerated from gunbc.design_document; four plan docs' now-stale symbol citations corrected

Not in scope

The (key_of, key_eq, value_eq, ownership_of) bundle still parameterizes the spine, so existing consumers are unchanged and the Added arm's behavior is untouched — the srv3 capacity lane is not blocked by this.

🤖 Generated with Claude Code

[gunbai-bot]

⚠️ This PR has ZERO executed checks — checks: none is NOT satisfied here

Flagging explicitly so the two approvals are not mistaken for readiness.

Correction to an earlier version of this comment. I first wrote that pull_request triggering was down repo-wide, sampling gh run list --limit 8. That sample landed entirely inside the queued-backlog window and the phrasing was wrong. A count of the last 40 runs is 27 pull_request / 11 workflow_dispatch / 1 schedule / 1 push — the webhook has clearly worked today.

What is actually going on, executed: sort every pull_request-triggered run in this repo by creation time. The most recent one anywhere is 2026-08-06T19:36:59Z. Not one has been created repo-wide since. This PR opened at 20:50:02 and I pushed a real synchronize commit at 21:11 — both after that cutoff. So all 27 of those runs are real and all 27 predate it.

It is not a quiet window: four PRs were opened after this one — #7936, #7937, #7939, #7940 — and every one has zero pull_request runs. A freshly opened PR firing nothing is unambiguous. Fifteen open PRs have been touched since the cutoff.

So this is a time-bounded repo-wide stop, not a property of this branch. Ruled out by execution rather than assumed: not a draft (isDraft=false, base main); not concurrency: cancel-in-progress (a cancelled run would still appear — this branch has exactly one run ever, my dispatch); not the session/ prefix (other session/* branches have pull_request runs, all from before the cutoff); and not self-inflicted — I checked whether my generated-artifact regen had rewritten .github/workflows/ci.yml into something unschedulable, and the diff against main for .github/ is empty.

I have not established the upstream cause of the 19:36:59 stop and am not going to name one. It is consistent with the Actions incident, but consistent-with is not executed-against. The queue is separately backed up, with runs sitting queued 1h+.

Dispatched run for this branch: https://github.com/gunb-ai/gunbc/actions/runs/31128148527

The caveat that matters: a workflow_dispatch run is a branch run, not a pull_request event, so it cannot attach to this PR as a check. Even once it goes green, gh pr checks and the dashboard merge summary will still read checks: none. The evidence will exist and be linkable from here, but it will not populate the field a merger looks at.

So: do not merge on the approvals. The absence of a check here means could not determine, not nothing blocking — and the affected-set run is exactly what would tell us whether 25 changed files break a consumer nobody read, given this touches live_deploy, workflow_reconcile, tool_readiness and host_axis_caps.

What HAS executed, locally and green

subject	result
live_deploy byte-identity goldens (the oracle for the effect split)	44/44
membership_reconcile witnesses	10/10
change_realization witnesses	8/8
tool_readiness, repo_local_git_config, workflow_reconcile, srv3, host_phase_status, roadmap_belt, host_axis_caps	all green
corpus compile	same 10 pre-existing diagnostics as main, verified by stashing

Plus each of the three new guards verified discriminating by planting the exact regression it claims to catch. That is real evidence, and it is not the floor — it is not a substitute for the affected-set run.

I will update here with the dispatched run's result.

— sent from jolly-swift-846

[gunbai-bot]

Dispatched run: SUCCESS — and the floor genuinely executed against this branch

Run 31128148527 — completed / success, 21:12 → 23:20 (most of that queued behind the backlog).

job	result
build	success, 17/17 steps
regen	success, 10/10 steps
ci (.dag witnesses + gates)	success, 13/13 steps
heal_generated_artifacts	skipped (failure-only)
deploy_dashboard_srv1	skipped (main-only)

I did not take the green at face value. A dispatch run could have narrowed affected-set selection to nothing and still gone green — the empty-observation narrow DESIGN names — so I pulled the log and confirmed my witnesses actually ran rather than being selection-skipped:

• test.claim.membership_reconcile_witness — 10/10 ✓, including w_ensured_member_converges_but_refuses_removal, the control holding the withdrawn Ensured-on-change wall withdrawn
• test.claim.change_realization_witness — 8/8 ✓, including the srv4 w_staged_replacement_without_declared_intermediates_refuses row
• both modules also show up in [compile-clean-cost] module_typecheck, so they were compiled, not skipped
• zero ✗ in the entire run

So the affected-set floor has now executed against these 25 changed files, and the consumers I could not check by hand — live_deploy, workflow_reconcile, tool_readiness, host_axis_caps — are covered by it.

The caveat still stands

This is a workflow_dispatch run, so it is a branch run and does not attach as a PR check. gh pr checks and the dashboard merge summary will still read checks: none. That field being empty here means could not determine, not nothing blocking — the evidence is this comment and the linked run, not the checks field.

— sent from jolly-swift-846

[gunbai-bot]

Closing: this lane is consolidated into #8016 (omega-runner-capacity), which carries this branch's content as a merge commit.

#7939's carriers are the one unresolved item — they conflict add/add with this lane's on apply.dag, fleet_runner_connectivity.dag, runner_capacity_plan.dag and their witnesses, which is a §3 single-authority decision, not a textual merge. That decision is tracked on #8016.

— sent from deep-badger-594