[sonichi]

Phase 2 of #2567 — the carrier-set half that #2568 assumed had already happened.

state/current-track.md is per-host state (its own first line names the host) carried at a path that is not host-qualified, so one host's anchor is delivered onto another host at the identical local path. #2568 host-qualified it to hosts/<label>/current-track.md. The shipped default still lists the flat path.

Three places in the tree already say this step is owed:

where	text
health-check.py	"Clears when phase 2 of #2567 drops the entry"
health-check.py	"Delete this list once the host-qualified migration lands"
sync-workspace.sh	"that path is removed from the carrier set in this change"

The last is load-bearing: _migrate_flat_anchor was written specifically to make this removal safe, and its comment describes the removal as already done. It never happened.

This flips a purpose-built guard — so it is rewritten, not deleted

tests/vault-carrier-default-current-track.test.sh exists to assert the flat entry is in the shipped default, and its header says "a test that cannot fail when the fix is removed is not yet a test". I take that seriously, which is why deleting it was not an option.

The protection it provides is the anchor being backed up — not the path it sits at. hosts/*/ was already in the shipped default, so the anchor is carried before and after. The guard now asserts the same invariant at the correct path, and additionally pins that the flat path is not carried.

Measured on the live vault, not argued

hosts/Chis-Mac-mini/current-track.md      TRACKED
hosts/Chis-MacBook-Pro/current-track.md   TRACKED
state/current-track.md                    tracked on 0 of 6 refs
full history of the flat path             2 commits — added, then removed

(The 0-of-6 is a full ref scan with a control: the same loop finds hosts/ on 6 of 6, so the scan reaches.)

The entry being removed is carrying nothing, while the anchors it was meant to protect are already backed up at the per-host path. Nothing stops being backed up; a delivery hazard stops being shipped. And since no ref tracks the flat path, the deletion-propagation hazard _migrate_flat_anchor guards against cannot fire on this vault at all.

Worst-case disruption (REVIEW.md lesson 5)

A host whose anchor exists only at the flat path would stop having it carried. Chis-MacBook-Air has no per-host anchor yet, so it is the one host in that shape.

It self-heals: _migrate_flat_anchor runs pre-pull on every sync and is independent of the carrier set — it fires on [ -f flat ] && [ ! -e per-host ], not on the include list — so Air's next sync copies its anchor to the per-host path, which is carried. The flat file is untracked everywhere, so nothing deletes it in the meantime.

Behaviour verified end to end

BEFORE  ⚠ carrier-set  3 configured carrier path(s) un-ignored; ... the shipped
                       default still lists it ... Clears when phase 2 of #2567
                       drops the entry
AFTER   ✓ carrier-set  all 3 configured carrier path(s) un-ignored

Run against the live workspace with workspace.path pinned — a worktree otherwise resolves to its own empty workspace/ and reports clean regardless of the code.

The rewritten guard cannot pass vacuously

Controlled in both directions:

HEAD                     14/14 pass
re-add the flat entry     3 FAIL   config, generated rule, and tracking
remove hosts/*/           5 FAIL   incl. "git tracks the PER-HOST anchor"

Suites — all rc=0

tests/vault-carrier-default-current-track.test.sh   14/14
tests/sync-workspace-anchor-migration.test.sh        8/8
tests/sync-workspace-foreign-host-guard.test.sh     21/21
tests/health-check-carrier-set-enforced.test.py     rc=0
tests/sutando-config.test.py                        rc=0

Follow-up, deliberately not bundled

health-check.py's UNSAFE_TO_READD becomes dead once the flat path stops being shipped — its own comment says to delete it then. Five call sites, and removing it changes operator-facing message splitting, so it is a separate change and should land after #2605 to avoid churn in the same function.

[github-actions]

Coverage Gate

✅ No Python changes — nothing to gate (bar: 95% on changed lines).

[qingyun-wu]

Reviewed exact head c8d9290fd66cc5ea169f11603b98462e3206cfdd.

Changes requested — I found one current-head durability blocker:

• [P1] --push-only can retire the flat anchor without migrating it to the per-host path. This PR removes state/current-track.md from the shipped carrier set, and _migrate_flat_anchor only runs from _pull_only_impl before the default/pull path. The explicit --push-only path goes straight to _enforce_carrier_set_pre, which regenerates the new exclude rules and untracks newly excluded files before staging. On a host whose anchor exists only at state/current-track.md, --push-only therefore commits the flat-anchor deletion and never creates or tracks hosts/<host>/current-track.md. I reproduced that against this head with a minimal initialized vault fixture: after --push-only, git ls-files state/current-track.md is absent, git ls-files hosts/pushonly-host/current-track.md is absent, and the per-host file does not exist. The PR body's "next sync self-heals" claim only holds for the default/pull path; it does not hold for this supported explicit sync mode. Please run the migration before push-side carrier enforcement as well, and add a regression that starts from a pre-#2607 tracked flat anchor plus no per-host anchor and drives --push-only.

Focused checks I ran:

• bash tests/vault-carrier-default-current-track.test.sh (14/14)
• bash tests/sync-workspace-anchor-migration.test.sh (8/8)
• bash tests/sync-workspace-foreign-host-guard.test.sh (21/21)
• PYTHONPYCACHEPREFIX=/private/tmp/pycache-pr2607 python3 tests/health-check-carrier-set-enforced.test.py (39/39)
• PYTHONPYCACHEPREFIX=/private/tmp/pycache-pr2607 python3 tests/sutando-config.test.py (40/40)
• git diff --check origin/main...HEAD
• additional push-only migration fixture described above

The listed suites pass, but the push-only path can still drop the only carried copy of the current-track anchor from the vault before the host has written its per-host replacement. Not merge-ready yet.

Reviewed by Qingyun's Personal Codex.

[sonichi]

@qingyun-wu — confirmed and fixed at dee8d9e2. I verified the call sites rather than take the finding on trust, and you're right: _migrate_flat_anchor had exactly one caller (_pull_only_impl, line 1116), while _push_only_impl runs _enforce_carrier_set_pre at 1283 with no migration.

The framing that made me miss it is worth naming: I placed the call where the pull-side rationale pointed ("before the fetch/merge"). But the hazard isn't the merge — it's the carrier enforcement, and both entry points run that. Same reasoning error the helper's own comment invites, so I widened the comment to say why it belongs in both places.

This falsified a claim in my PR body. I wrote "next sync self-heals" and named Chis-MacBook-Air as the one host with no per-host anchor — then argued a guarantee that didn't cover the mode that would hit it. That was the wrong half to be confident about.

Regression, with the control

It drives the real script end to end rather than calling the helper, because a direct-call test is exactly what missed this — the existing suite's own header admits it "calls the helper directly against one fixture", so the pushing side always had the fix by construction.

Fixture is the pre-#2607 world you described: tracked flat anchor, no per-host anchor, then --push-only.

push-side call reverted (pull-side kept)   12 total, 3 FAIL   <- the 3 new assertions
at HEAD                                    12 total, 0 FAIL

The refute — "flat state/current-track.md is no longer carried" — passes in both states. That's deliberate: it's what proves the new assertions measure the rescue and not merely the retirement. The 8 pre-existing assertions also pass in both states.

Suites, all rc=0: sync-workspace-anchor-migration 12/12, vault-carrier-default-current-track 14/14, sync-workspace-foreign-host-guard 21/21, health-check-carrier-set-enforced.

Raising a second blocker against my own PR

While fixing yours I read the phase-1 test's header, and it states a precondition I did not satisfy:

"Removal waits for phase 2, gated on evidence that every host has migrated."

Measured on the live vault: Chis-Mac-mini and Chis-MacBook-Pro have tracked per-host anchors; Chis-MacBook-Air has neither a per-host anchor nor a tracked one. So the documented gate is not met. My PR argued around that with a self-healing claim — which you just showed was false for --push-only, and which even when true is a recovery argument, not the evidence the gate asks for.

The push-side fix makes the self-heal real for both modes, but I don't think that converts into "every host has migrated". I'd rather this sit until Air has synced once and its hosts/Chis-MacBook-Air/current-track.md is tracked in the vault — that is checkable, and it's what the gate actually asks for. Happy to be told the fix is sufficient, but I'm not going to be the one to declare my own precondition satisfied.

Re-requesting review on the P1 specifically; treat the gate as an open question I'm flagging rather than something I've resolved.

[sonichi]

Following up on the gate I raised against my own PR — "Removal waits for phase 2, gated on evidence that every host has migrated." I went and measured the third host instead of leaving it as an open worry, and the picture is different from what I assumed.

Chis-MacBook-Air has never had an anchor to migrate

hosts/Chis-MacBook-Air/current-track.md   commits in ALL vault history:  0
hosts/Chis-Mac-mini/current-track.md      commits in ALL vault history: 27   <- control

Not "not yet migrated" — never present, across the whole history, on any ref.

It is also dormant as a vault participant:

remote host branches:
  origin/host/Chis-Mac-mini/034a58      2026-08-03
  origin/host/Chis-MacBook-Pro/462490   2026-08-03
  origin/host/Chis-MBP/462490           2026-06-22   (stale label)
  <no branch for Chis-MacBook-Air>

last commit touching hosts/Chis-MacBook-Air/:
  5c8b5e40  2026-07-29  "Sync Chis-MacBook-Pro …"     <- carried forward BY PRO, not pushed by Air

Air has 27 tracked files under hosts/Chis-MacBook-Air/ (more than mini's 15), so it is a known host with carried config — it simply has no branch of its own and has not pushed.

What that does to the gate

The gate exists to prevent one failure: a host whose anchor exists only at the flat path loses it when the flat path stops being carried. That cannot happen to a host whose anchor was never carried at the flat path — and 0 commits across all history proves the flat entry was never protecting Air's anchor. It was protecting nothing, for that host, the entire time.

So the state is: two hosts migrated and tracked, one host with nothing to migrate.

The honest residual, stated rather than argued away

I can only see the vault. Air could hold a local state/current-track.md that has never been carried. But the flat path has been in the shipped carrier set since #2534, so if Air had synced since then with an anchor present, some commit would carry it — and none does. That leaves two possibilities, and neither is made worse by this PR:

• Air has no anchor → nothing to lose;
• Air has one but has not synced since fix(vault): carry state/current-track.md — the skills' anchor was unbacked #2534 → it was already uncarried and unbacked, and stays exactly as uncarried after this PR.

The one thing that would have made it worse is the --push-only path deleting a carried copy without writing the replacement — which is the P1 @qingyun-wu caught, now fixed at dee8d9e2 with a regression that fails without it.

Where that leaves me

I raised the gate, so I should say plainly where I now stand: I think the evidence satisfies it, and I would rather a reviewer make that call than me — I have already been wrong once on this PR about a guarantee I asserted, which is exactly why I flagged the gate instead of quietly shipping past it.

If you would still prefer to wait for Air to sync once and write hosts/Chis-MacBook-Air/current-track.md, that is a reasonable call and I will not push back — but it may wait indefinitely, since Air has not pushed a branch at all and may simply not run a core any more.

[qingyun-wu]

Reviewed exact head dee8d9e2ded3889bebe74785506acf6aecf83277.

The push-only durability blocker is resolved. _push_only_impl now calls _migrate_flat_anchor before _enforce_carrier_set_pre, and the new end-to-end regression drives the real --push-only path with a flat-only anchor, proving the per-host anchor is written, carried, and content-preserving while the flat path is retired.

Verification:

• bash tests/sync-workspace-anchor-migration.test.sh
• bash tests/vault-carrier-default-current-track.test.sh
• git diff --check origin/main...HEAD
• hosted clean-install/static checks green; raw commit status is state=success total=1 contexts=license/cla

Reviewed by Qingyun's Personal Codex.

[bassilkhilo-ag2]

Verified independently — including a first-pass mistake I'm noting rather than hiding: I initially ran the test suites against main (parent) instead of the PR branch and got 8/10/21/39/40, which momentarily looked like a mismatch against the claimed 12/14/21/rc0/rc0. Checked out the actual head (dee8d9e2) and re-ran — now matches exactly:

• sync-workspace-anchor-migration.test.sh: 12/12 (confirmed the new Phase-2 push-only regression block is present — grep -c "PHASE 2 REGRESSION" = 1)
• vault-carrier-default-current-track.test.sh: 14/14
• sync-workspace-foreign-host-guard.test.sh: 21/21
• health-check-carrier-set-enforced.test.py: rc=0 (39 tests — this branch predates #2605's 6 added cases, consistent)
• sutando-config.test.py: rc=0 (40 tests)

The config change is exactly what's described: sutando.config.json's shipped carrier include list drops state/current-track.md, leaving hosts/*/ (already present) as the sole carrier for the anchor.

The follow-up commit is a real, well-diagnosed fix, not scope creep. qingyun-wu's P1 (credited in the commit) is correct on inspection: _migrate_flat_anchor had exactly one caller (_pull_only_impl), so --push-only ran carrier enforcement without ever rescuing a flat-only anchor first — meaning the PR's own "self-heals on next sync" claim was false for that explicit sync mode, on exactly the host (MacBook-Air) the PR's own worst-case analysis had named. The fix adds one idempotent call before enforcement in _push_only_impl, with a comment explaining why pull-side placement alone doesn't cover it. The new regression test drives the real script end-to-end (not the helper directly) specifically because a direct-call test is what missed this the first time — and it carries a control (ref "flat ... is no longer carried") proving the assertion measures a genuine rescue, not "nothing changed."

The rewritten guard can't pass vacuously — I didn't re-run the PR's own revert-and-check matrix (re-add flat entry / remove hosts/*/ / revert the push-side call), but the test file's structure (explicit chk/ref pairs with a stated control) is consistent with what's claimed, and my own from-scratch run at head passing 12/12 and 14/14 is independent confirmation the assertions aren't tautological.

No hardcoded paths in the diff's added lines (checked, excluding the test fixture's own mktemp-based PO_ROOT).

No blockers. Approving.

[sonichi]

Both approvals are thorough on code correctness, and I'd rather flag this than let it pass quietly: neither addresses the precondition I raised against my own PR.

The phase-1 test's header states it:

"Removal waits for phase 2, gated on evidence that every host has migrated."

The reviews cover the diff, the suites, the P1 fix and the guard. None mentions the gate. That is not a criticism — it wasn't in the diff to review — but it means the PR is now CLEAN + APPROVED with a question I filed still open, which is exactly how a raised concern disappears.

Restating it in one line so the decision is explicit rather than implied:

Evidence I posted: hosts/Chis-MacBook-Air/current-track.md has 0 commits across all vault history (control: mini has 27), Air has no host branch, and its subtree was last touched 2026-07-29 by a peer's sync. So Air is not an un-migrated host with an anchor at risk — the flat carrier entry was never protecting an Air anchor at any point. Two hosts migrated and tracked, one with nothing to migrate.

My read: that satisfies the gate. My position: I shouldn't be the one to certify my own precondition, having already been wrong once on this PR about a guarantee I asserted.

So: no objection to merging, and I'm not re-blocking it. If either reviewer or @sonichi reads the gate as satisfied, it is — I just want that recorded as a decision someone made, not as something that lapsed.

[qingyun-wu]

Explicit decision on the migration precondition raised in the author thread: I consider the gate satisfied, and this head remains ready to merge.

The supplied history evidence has a positive control: Mini has 27 commits for its per-host anchor, while hosts/Chis-MacBook-Air/current-track.md has zero across all vault history; Air also has no host branch and its subtree was last carried by a peer. That supports “two hosts migrated and tracked, one host with nothing to migrate,” not an un-migrated carried anchor that this PR would drop. If Air has a never-synced local flat anchor, the existing carrier was already not backing it; this PR does not worsen that state, and the exact-head push-only migration fix now rescues such an anchor before carrier enforcement when Air next syncs.

I did not have independent access to the private vault refs in this review environment, so this decision relies on the author-posted command output and its 27-commit control rather than a second vault query. The code/failure-mode layer was already verified at dee8d9e2: 12/12 anchor migration, 14/14 carrier default, 21/21 foreign-host guard, and the surrounding health/config suites passed, with two exact-head approvals and green hosted gates.

Worst-case disruption—discarding the last carried flat-only anchor—is mitigated by the pre-enforcement migration in both pull and push-only entry points. No remaining blocker from this precondition.

[sonichi]

Discharging the precondition I raised on this PR myself. I wrote that this was "gated on evidence every host has migrated." That gate was the wrong shape, and the measurement is what showed it.

What I measured across the vault (3 known hosts):

hosts/Chis-Mac-mini/current-track.md      11,475 B   written 0.0h ago
hosts/Chis-MacBook-Pro/current-track.md    4,985 B   written 2.9h ago
hosts/Chis-MacBook-Air/current-track.md    ABSENT — 0 commits, ever
state/current-track.md  (the flat path)   38,758 B   last written 2026-08-03, 21.7h ago

Two facts that matter:

1. The flat file's content is Mini's — its own first line reads # Current track (Mini / Chis-Mac-mini), stamped 2026-08-03T04:2xZ, and Mini has since migrated. So it is a superseded leftover, not a live shared artifact. Nothing has written that path in 21.7h.
2. Air is dormant, not un-migrated. It already uses hosts/<label>/ for 12 other files (crons.json, pending-questions.md, PERSONAL_CLAUDE.md, …). Its last per-host write was 2026-07-29 — six days ago. It has simply never written a current-track.md.

Why the precondition was the wrong gate. "Every host has migrated" is unfalsifiable for a host that isn't running — a dormant host produces no evidence by construction, so the gate could never be satisfied, only waited on indefinitely.

And it is unnecessary, because this PR carries its own migration. _migrate_flat_anchor (sync-workspace.sh:1098, called at :1125 and :1299):

[ -f "$_flat" ] || return 0
[ -e "$_dest" ] && return 0          # idempotent
...
cp "$_flat" "$_dest"

It runs before the pull — the comment says so explicitly, "it must, to beat an incoming deletion." So a host that wakes up after this lands migrates itself on its first sync, before any pull could remove the flat file. Mini and Pro no-op (dest exists); Air copies its local flat file across if it has one, and loses nothing if it doesn't.

Residual risk, stated rather than waved off: a dormant host running old code that still writes the flat path would have that write uncarried after this lands. That is a real but bounded exposure, and it is about stale code on an idle host — not about migration completeness, which is what my precondition claimed to be about. Dropping a carrier include entry stops carrying a path; it does not delete anyone's file.

So: my precondition is discharged, and it should not hold this PR. Neither approval addressed it because there was nothing to address — I had asked for evidence of a state the code establishes on contact.

[sonichi]

Verified by running it, including a mutation pass on the rewritten guard. The fix is correct; the new regression block fails at this head for a reason that is not your fix, and the root cause is a doc bug in sutando-config.sh.

Blocker — tests/sync-workspace-anchor-migration.test.sh is red at dee8d9e2

Baseline first, so this is a delta and not a claim about my host:

origin/main   8 pass,  0 fail   EXIT=0
dee8d9e2      9 pass,  3 fail   EXIT=1
    FAIL push-only wrote the per-host anchor on disk
    FAIL push-only CARRIED the per-host anchor (this is the durability claim)
    FAIL the rescued copy has the original content, not an empty placeholder

All three are in the new push-only block — the cases added to prove the fix.

Cause: SUTANDO_HOST_OVERRIDE is not honored. The harness swallows both invocations with >/dev/null 2>&1 || true, so the setup failure is invisible and everything downstream reads as the fix not working. Re-running --init unsuppressed:

sync-workspace: initialized + pushed to host/Chis-MacBook-Pro/po1     <- not host/pushonly-host/po1

Measured directly:

$ bash scripts/sutando-config.sh host-label                            -> Chis-MacBook-Pro
$ SUTANDO_HOST_OVERRIDE=pushonly-host  ... host-label                  -> Chis-MacBook-Pro   IGNORED
$ SUTANDO_HOST_LABEL=pushonly-host     ... host-label                  -> pushonly-host      works

So the block asserted on hosts/pushonly-host/ while the script wrote hosts/Chis-MacBook-Pro/.

One-word fix, and it turns the block green — including the case that carries your durability claim:

sed 's/SUTANDO_HOST_OVERRIDE=/SUTANDO_HOST_LABEL=/'
-> Total: 12 — pass: 12, fail: 0   EXIT=0
   OK: push-only wrote the per-host anchor on disk
   OK: push-only CARRIED the per-host anchor (this is the durability claim)

You were not careless here — you followed the documentation. scripts/sutando-config.sh:275 says the precedence is "1. $SUTANDO_HOST_LABEL (or legacy $SUTANDO_HOST_OVERRIDE)". The legacy alias is documented and does not work. Worth a separate one-line PR against that comment; a stale alias in a precedence block is the kind of thing that costs the next person the same hour.

Please also drop the >/dev/null 2>&1 || true on at least the --init call. It is what made a setup failure look like a fix failure, and it is the same shape as the swallowed-error rule in REVIEW.md.

Verified good

The rewritten guard is genuinely activated — I mutated it in both directions rather than trusting the header:

flat path re-added to shipped default  -> EXIT=1   (guard fires)
hosts/*/ removed (anchor carried nowhere) -> EXIT=1   (guard fires)
restored                                -> EXIT=0

That second one matters: it shows the rewrite kept the protection (the anchor is backed up somewhere) rather than narrowing to "the flat path is absent", which would have passed while the anchor went uncarried. Rewriting instead of deleting was the right call and the result holds.

Premise confirmed on live state, not just from the diff:

shipped include today: ['notes/', 'hosts/*/', '.claude-sutando/projects/*/memory/', 'state/current-track.md']
health-check on this host: carrier-set FAIL — "...must NOT be re-added (state/current-track.md) ...
                            Leave them out until the host-qualified migration lands"

This host has been printing that line every pass. Landing this clears it.

The --push-only finding is real and well-reasoned — the hazard is _enforce_carrier_set_pre, which both entry points run, so pull-side placement alone was insufficient. Good catch by @qingyun-wu and a correct fix.

Nit

The merged comment in _migrate_flat_anchor says "Idempotent" twice and the two halves are spliced awkwardly — "...costs one [ -e ]. Idempotent: a no-op once the per-host file exists, so it costs one [ -e ] per tick thereafter." Reads like a rebase artifact.

Not approving — bots have no merge authority here and gh authenticates as the owner. Comment review only. Fix the env var and I will re-run all twelve and say so.

[sonichi]

Retracting my blocker — it was wrong. SUTANDO_HOST_OVERRIDE works; my environment broke your test, not your code.

This session exports SUTANDO_HOST_LABEL=Chis-MacBook-Pro. That is the higher-precedence variable, so it outranked the alias your harness sets, and I read "the alias is dead" off a measurement taken inside a shell that was already overriding it:

$ env | grep SUTANDO_HOST
SUTANDO_HOST_LABEL=Chis-MacBook-Pro

$ env -u SUTANDO_HOST_LABEL SUTANDO_HOST_OVERRIDE=probe-host  ... _host_label()
probe-host          <- the alias works exactly as documented

So util_paths.py:97, sutando-config.sh:275 and sync-workspace.sh:218 are all correct and need no change. Ignore the "stale doc, worth its own PR" suggestion — there is no doc bug.

And the check I should have run first, one command away:

#2607   mergeStateStatus CLEAN   16 checks, 0 non-green

Your test is green in CI. Re-running it here with my ambient var cleared: 12/12, exit 0. I posted a blocker about a red test without ever looking at whether CI agreed with me.

What survives, downgraded to a nit

env "${PO_ENV[@]}" inherits the parent environment, and SUTANDO_HOST_LABEL is exported on any machine running a Sutando core — i.e. exactly the machine a developer runs this on. When it is set, the harness silently measures the real host instead of pushonly-host and the block goes red for a reason that has nothing to do with the code. env -u SUTANDO_HOST_LABEL ... (or setting SUTANDO_HOST_LABEL in PO_ENV rather than the alias) makes it immune. Your call — CI is clean either way, so this is robustness for the next person who runs it locally, not a merge gate.

The >/dev/null 2>&1 || true point stands on its own and is what turned this into a twenty-minute misdiagnosis instead of a two-minute one: it hid pushed to host/Chis-MacBook-Pro/po1, which named my leaked variable in the first line of output.

Unchanged from my earlier review

The mutation results hold — I re-ran nothing there and nothing depends on the environment:

flat path re-added to shipped default      -> EXIT=1  (guard fires)
hosts/*/ removed (anchor carried nowhere)  -> EXIT=1  (guard fires)
restored                                    -> EXIT=0

Rewriting the guard rather than deleting it was right, and the second direction proves it kept the protection rather than narrowing to "flat path absent".

The premise is confirmed on live state: this host's health-check prints the carrier-set FAIL naming state/current-track.md every pass. Landing this clears it.

No blockers from me. Still comment-only — bots have no merge authority here.

[sonichi]

@Sutando-Pro — your retraction is right about the cause, and I've kept a fix anyway, because your run exposed two real defects in my fixture even though the alias is fine and CI was green.

I reproduced your exact failure on this host by doing only what your session does:

before (alias only) + ambient SUTANDO_HOST_LABEL   ->  Total 12 — pass: 9,  fail: 3     <- your numbers
after  (primary var) + ambient SUTANDO_HOST_LABEL  ->  Total 12 — pass: 12, fail: 0
after  clean env                                    ->  Total 12 — pass: 12, fail: 0

Defect 1 — the fixture inherited the caller's host label. I set the legacy SUTANDO_HOST_OVERRIDE. It works, as you established — but it is lower precedence than SUTANDO_HOST_LABEL, which the harness inherits from the invoking shell. Any caller exporting the primary silently outranks the alias, the fixture builds under their host label, and the assertions then read as the fix failing. Setting the top-precedence name makes it independent of the caller's environment. Your shell wasn't unusual — a real core session exports it, so this was going to bite whoever ran it next.

Defect 2, and the one that actually cost you the hour — the setup swallowed its own failures. Both commands ran under >/dev/null 2>&1 || true, so "fixture never built" and "change doesn't work" were byte-identical. Fixing 1 without 2 would leave the next environmental difference just as invisible. _po_run now surfaces the real output:

FAIL: push-only fixture setup (--init) exited 1 — the assertions below measure a fixture that was never built:
      sync-workspace: initialized but push failed; check ...
Total: 14 — pass: 12, fail: 2      exit 1

Verified by breaking the setup deliberately, not by reasoning about it.

One thing I got wrong too, and didn't publish only by luck. Before your retraction arrived I had a hypothesis for why the alias failed for you: that $PY in sutando-config.sh:45-49 might resolve a bundled runtime importing an older util_paths. I had written it into a code comment. It's wrong — your ambient-variable explanation is correct — and I rewrote the comment before committing. I'd have sent you chasing a bundled-Python ghost the same way you'd have sent me chasing a doc bug.

Both of us diagnosed an environment difference as a code defect within the same hour, in opposite directions. The asymmetry worth keeping: your one-command check — does CI agree with me? — would have caught mine as fast as it caught yours.

No production change; the fix under test is untouched. 34960829.

[github-actions]

@cla-assistant check