Widen the deployed-tree exclusions to the host-state prefixes rsync was shipping

[gunbai-bot]

What happened

An operator deploy of srv1 (live_deploy_apply_srv1_operator_wet) refused at admission:

CandidateCheckoutNotClean: the deploying checkout's working tree does not equal HEAD, and the
source sync ships the working tree — so this deploy would install bytes the revision does not
name and every later comparison would agree with itself.
staged=(none) tracked=(none) untracked-deployed=(none)
ignored-deployed=.claude/settings.local.json, .claude/worktrees/agent-a08ba29cba32fef1b/, …×9

The refusal is correct and fired before any mutation, exactly as
live_deploy_candidate_observed_at_launcher_note promises. Nothing was touched.

Why the fix is a widening rather than a cleanup

The working-tree leg of the source sync is rsync, which does not read .gitignore. An ignored
path outside deployed_tree_excluded_prefixes is therefore copied to the host under a revision
that does not name it. candidate.dag already names the two remedies for that arm — widen the
exclusions, or remove the file — and already listed .claude/ as a known member of the class.

Four prefixes take the first remedy because they are host state by construction: agent
session state and local tool/build caches that no revision ever names. Shipping one is never the
intent, so refusing on one is pure friction.

deployed_tree_excluded_prefixes goes ["target", ".git"] → + .claude, .gunbc, target-codex, .cargo-home.

What deliberately stays refused

The .env family. The repo ignores .env, .env.local, .env.*.local. The third is a
wildcard, and both path_is_deployed and rsync's --exclude /<p> match a literal segment.
Listing the two spellable forms would silence admission on them while .env.*.local kept
shipping — partial cover on the one class where the shipped bytes are secrets, strictly worse
than the present loud refusal on all three.

src/v2/test/claim/manual/sg2_scratch_probe.dag, for a different reason: it sits inside a
source root the graph reads, so excluding it would change what the host compiles, not merely
what it stores.

Not derived from gunbc.gitignore_authority, on purpose

That authority answers must not be tracked; this one answers must not be shipped, and the
sets genuinely differ — a tracked file ships and is not ignored. Deriving would also let an
ordinary .gitignore edit silently change what a deploy installs, and would put an import edge
into a module held leaf for the acyclicity reason its own header states. Flagging it as a
question rather than acting on it.

Witnesses

dag/test/claim/live_deploy/candidate_checkout_witness_test.dag, 21 → 24 claims:

• the existing one-home pin moves to the six-prefix list (it pinned == 2 / "target,.git")
• the observed blocker as a claim — the exact .claude paths that refused
• a control that the residue stays loud — .env, .env.local, .env.production.local and
  the scratch probe must still read as deployed, so a later widening cannot silence them unnoticed
• segment matching over the appended dotted prefixes — .claudex/, dag/.claude/,
  target-codexish/ are the easy regression into a character run

Scope

Prose in candidate.dag that read "the two prefixes deployed_tree_scope names" is updated in the
same commit; leaving it would be the stale-citation class §3 names.

[gunbai-bot]

Validated by execution before flipping out of draft: claim_batch --entry dag/test/claim/live_deploy/candidate_checkout_witness_test.dag --functions <all 24> on srv1 (aarch64) at e63c4ed7d0 — 24/24 PASS, 0 FAIL.

The first run at bd8da1ac7b had exactly one red, and it is worth recording because it is the one-home pin doing its job rather than a test needing appeasement: the_ignored_scan_keeps_deployed_paths_and_drops_excluded_ones asserted .gunbc/ledger.json on the KEPT side, correct under ["target", ".git"] and wrong once local tool state is excluded. Second commit moves it to the dropped side and adds .claude/settings.local.json beside it, so the observed blocker appears in the both-directions claim too.

Provenance of the subject: the refusal quoted in the description is from a real operator deploy attempt against srv1, not a constructed fixture — it fired before any mutation and the host was left untouched.

[gunbai-bot]

CI red fixed at 397359fcc2, and the failure was a real consequence of this change reaching outside its own module rather than a flake.

What the floor caught. deployed_tree_rsync_exclude_flags() renders one --exclude /<p> per prefix directly into gunbc-srv1-green-tree-sync.service's first ExecStart, and those bytes are pinned by live_deploy_unit_emission_oracle_witness. Two prefixes to six changed emitted unit bytes, so the_tree_sync_unit_matches_the_deployed_bytes went red. That is the oracle doing exactly its job: a change to the exclusion set must not move deployed unit bytes silently. The floor run was passed=8831 known_red_held=306 failed=1 — this was the only red in 9,138 claims.

Two fixes, because the name was also wrong. After this change ..._matches_the_deployed_bytes is literally false: the host carries the two-prefix spelling and reconverges only after the next deploy of that slot. A claim asserting agreement with deployed bytes while deliberately disagreeing with them is the named-for-X-claims-Y shape, so it is now ..._matches_the_deployed_bytes_plus_the_exclusion_widening, with the delta, its derivation and its closing condition on the row. No roster referenced the old name.

Why this is a declared divergence, not a blind re-pin. The base bytes remain the independent 2026-08-19 srv1 transcription; the one field that moves is the one the exclusion list computes. The second ExecStart is untouched on purpose — the .git leg carries its own include/exclude set and does not read the list — so its bytes staying byte-identical is the control proving the widening reached the leg it should and no other.

Validated by execution on srv1 (aarch64) at 397359fcc2 before pushing: oracle module 6/6 PASS, candidate module 24/24 PASS, zero FAIL.

— sent from nimble-fox-671