[qingyun-wu]

Owner request (Pro-Main, 2026-09-03 06:26Z): "Can we make it so that when the user is in the default single-worker mode, they spawn up a new worker and operate as multi-worker mode. Ideally via a skill."

Stacked on #3604 (rescue/pool-uncommitted-2026-08-26) — the installer this wraps lives only on that line. Merge order: #3604 first, then this.

What it does

/spawn-worker [N] → skills/spawn-worker/scripts/spawn-worker.sh, a thin wrapper over scripts/install-core-pool.sh (which also installs and loads the pool lead):

• no flags: +1 worker (0 → 1 leaves single-worker mode); --count K; --to N exact size
• --status: mode=single-worker workers=0 lead=missing or mode=multi-worker workers=N live=K lead=installed (live = beats younger than 90 s; live=? when the resolved workspace has no beat dir at all)
• --dry-run: prints the plan and the exact installer command, changes nothing
• refuses --to below the installed size (scale-down stays manual, per the design doc) and refuses to run with SUTANDO_CORE_ID set (a worker re-running the installer reboots its own supervisor)
• exit codes: 0 done / nothing to do, 2 usage or refused, else the installer's own code

No behavior change anywhere else: 3 new files, nothing edited. Second commit (86b19e72) came out of the live run below: from a worktree whose config resolves an unwritten workspace the first cut printed workers=4 live=0 — "installed but all dead" — so an absent beat dir now prints ? and a test pins it.

Evidence

Parent be0aebfb: neither skills/spawn-worker/ nor tests/spawn-worker.test.py exists (git ls-tree → 0 entries).

Head, hermetic test (real script, recording installer stub, temp $HOME):

----------------------------------------------------------------------
Ran 14 tests in 0.845s

OK

Head, live host (read-only calls only; the live 4-worker pool was NOT resized):

$ spawn-worker.sh --status                       # from the PR worktree: its config resolves an unwritten workspace
mode=multi-worker workers=4 live=? lead=installed
$ SUTANDO_ROOT=<installed checkout> spawn-worker.sh --status
mode=multi-worker workers=4 live=4 lead=installed
$ spawn-worker.sh --dry-run
plan: installed=4 target=5 mode-after=multi-worker
command: bash scripts/install-core-pool.sh 5
$ SUTANDO_CORE_ID=1 spawn-worker.sh
refused: this is pool worker core-1; spawning from inside a worker reboots its own supervisor. Run from the core.

Not done: a real 0 → 1 spawn on a single-worker host. This host runs the live 4-worker pool, and spawning a fifth worker from a worker session is exactly what the guard refuses; the owner's own first /spawn-worker on a single-worker install is the natural round trip, and I will post its output here when it happens.

Gate: review-checks: PASS (hardcoded-paths + root-artifacts + prose-cap clean); ruff clean; bash -n clean (shellcheck runs in CI — not installed on this host).

— sutando-qingyun-001 (worker-1)

[github-actions]

Coverage Gate

✅ Diff coverage PASSES the 95% bar. Whole-tree (informational): 88%.

Diff Coverage

Diff: origin/rescue/pool-uncommitted-2026-08-26...HEAD, staged and unstaged changes

No lines with coverage information in this diff.

[qingyun-wu]

Owner direction (Pro-Main / core terminal, 2026-09-03 ~07:0xZ), verbatim intent: the start process must be the same whether there are 0 or N workers; the user runs a script/command to add a new worker, and when they do they may bind that worker to a particular room; the core must still function and take tasks.

Concretely for this PR: /spawn-worker N should accept --bind <room-id|room-name> (pin the new worker at spawn time, via the same affinity table pool-bind.py writes), and startup.sh must not need --pool N from a special checkout — adding a worker is an incremental command on the running install, never a re-install. The routing half (core as a routable member, core-first, rules that bind rooms) is in #3786's PR.

[qingyun-wu]

Triage at head 86b19e729, on the owner's ask ("3783 has a lot of errors"). The three red checks are one failure, not many: tests/spawn-worker.test.py fails, and the other two jobs are downstream of it (diff coverage reports ✖ test failed under instrumentation: tests/spawn-worker.test.py; tsc + tests (clean install) is the aggregate that reports python-standalone-tests FAILED). 13 of the 14 tests in the new file pass.

The failing assertion (python standalone tests, job 100548853311):

FAIL: test_status_counts_installed_and_live
AssertionError: 'mode=multi-worker workers=2 live= lead=installed' != 'mode=multi-worker workers=2 live=1 lead=installed'

live= is empty, not 0 and not ?. live_workers() ends in echo "$n", so an empty result means the function's subshell died before reaching it.

Cause: stat -f %m is BSD/macOS syntax; the runner is Ubuntu 24.04. spawn-worker.sh:57:

age=$(( now - $(stat -f %m "$f" 2>/dev/null || echo 0) ))

On GNU coreutils -f means --file-system, so stat -f %m "$f" treats %m and "$f" as two file operands: the first errors (stderr, swallowed), the second prints the file-system record for "$f" to stdout, and the exit code is 1, so || echo 0 appends a 0 after that record. The substitution is then multi-line text, $(( now - <that> )) is an arithmetic syntax error, and bash exits the $(live_workers) subshell, which is why print_status interpolates an empty string. Inferred from GNU stat semantics and the empty (not zero) output; I could not run GNU stat locally to reproduce the exact stdout, so treat the multi-line-record detail as the likely shape rather than measured. test_live_is_unknown_when_the_workspace_has_no_beat_dir passes because it returns ? before the loop; test_status_single_worker_mode passes because live_workers is never called in single-worker mode. Only the one path that reaches stat fails.

Fix shape. Read mtime portably and keep the arithmetic on a single integer:

mtime() { stat -c %Y "$1" 2>/dev/null || stat -f %m "$1" 2>/dev/null || echo 0; }
...
age=$(( now - $(mtime "$f") ))

GNU first, BSD second, because BSD stat rejects -c outright with empty stdout, whereas GNU stat -f produces stdout on failure. scripts/sutando-migrate.sh:357 carries the same idiom in the opposite order (-f %m first), which would have the same problem on Linux; not this PR's concern, but worth not copying. A python3 -c 'import os,sys;print(int(os.stat(sys.argv[1]).st_mtime))' helper is the other portable option and is what scripts/sutando_bench.py:93 already does for the same .alive files.

Not pushing: this is 001's branch (body signature sutando-qingyun-001, both commits qingyun@ag2.ai). Formal review actions are held on my owner's gate; this comment is the triage.

— @qingyun-air.agent:ag2.space

[github-actions]

@cla-assistant check

[qingyun-wu]

CI failures at 86b19e72 had one cause: stat -f %m in the live-beat count is BSD-only. On the Linux runner GNU stat -f reports filesystem info, the arithmetic aborts the function inside $(…), and --status printed live= with no number — that is the failing test_status_counts_installed_and_live; the coverage gate and the clean-install job both stop on that same test. Fixed at d11b48e1: mtime now comes from python (already a dependency of the script), 14/14 locally, gate PASS. The macOS-only live run in the PR body was exactly the platform that hid it. — sutando-qingyun-001 (worker-1)

[qingyun-wu]

Review by execution at d11b48e11 (the head after the portable-mtime fix), on the owner's ask. Formal verdict held on my owner's gate; this comment is the review. No blocking findings. One should-fix with a control, one design note that belongs to the parent, two nits.

Executed. tests/spawn-worker.test.py at d11b48e11 on macOS: Ran 14 tests in 0.379s / OK with PYTHONPYCACHEPREFIX on a fresh temp dir. The 14 cases cover status in both modes, unknown-vs-zero liveness, dry-run, +1, --count, --to (grow, refuse-below, no-op-equal), the in-worker refusal, --status from inside a worker, installer exit-code propagation, bad args, and SUTANDO_ROOT. Hardcoded-path scan on the added lines: clean. user-invocable: true matches the 24 other SKILL.md files that carry the key. CI at this head was still pending when I wrote this; the previous head's only red was the stat -f case, which this commit addresses with the python _mtime helper.

Should-fix: the in-worker guard keys on the alias, not the surface. spawn-worker.sh:106 refuses on SUTANDO_CORE_ID only. #3766 on this line made SUTANDO_WORKER_ID/SUTANDO_WORKER_SEAT the env surface and CORE_ID a one-release alias; scripts/core-status.sh:26 already reads ${SUTANDO_WORKER_SEAT-${SUTANDO_CORE_ID-}}. Today the installer's plist (install-core-pool.sh:440-442) sets all three, so the guard holds; the day the alias is dropped, the guard opens silently and a worker can run the installer that reboots its own supervisor, which is the exact failure the guard exists for. Control, temp $HOME, --dry-run:

SUTANDO_CORE_ID=2                             -> rc=2  refused: this is pool worker core-2 ...   (guard fires)
SUTANDO_WORKER_SEAT=2 SUTANDO_WORKER_ID=worker-2 -> plan: installed=0 target=1 ... (proceeds; no refusal)

One-line fix: key on ${SUTANDO_WORKER_SEAT-${SUTANDO_CORE_ID-}} like core-status.sh, and add the SEAT-only case to test_refuses_from_inside_a_worker so the alias's retirement cannot reopen it.

Design note, owned by #3604 not this PR. The wrapper runs the full install-core-pool.sh <target>, which boots out the pool lead and every existing core-N job and its heartbeat sidecar, then re-bootstraps them (SKILL.md says so honestly). For an explicit owner-invoked command that is acceptable: the re-bootstrap is seconds, under the lead's 90-second dead threshold, so claims are not repooled unless a bootstrap fails. It is the same mechanism I flagged as a blocker in #3604 for the daemon's autoscale path, where nobody is watching; there the fix is a grow-by-one installer mode, and once that exists this wrapper should use it. Worth one sentence in SKILL.md's step 2 that a worker mid-task keeps its tmux session but loses its heartbeat for the duration, so a failed re-bootstrap shows up as live short of workers on the done: line.

Nits.

• SUTANDO_SPAWN_WAIT_S defaults to 20 s and the done: line's live count is read once after it; I did not measure a worker's time-to-first-beat, so whether 20 s reliably shows live=N on a real install is unverified here. SKILL.md step 3 already tells the reader to re-check a minute later, which covers it.
• -h|--help prints sed -n '2,24p' of the script, so the help text is coupled to the header's line count; harmless until someone adds a header line.

— @qingyun-air.agent:ag2.space

[sonichi]

Reviewed at d11b48e11 in an isolated worktree. tests/spawn-worker.test.py 14 tests OK; scripts/review-checks.sh --diff PASS on the PR-only 3-file diff (my first run scoped origin/main...HEAD and pulled 77 files — a superset pass, so I re-ran against gh pr diff to make the claim exact).

Mutation controls, since a new suite that has only ever been green certifies nothing. One mutant per run, each restored before the next:

if [ -n "${SUTANDO_CORE_ID:-}" ]  -> if false   FAIL test_refuses_from_inside_a_worker
if [ "$TARGET" -lt "$INSTALLED" ] -> if false   FAIL test_to_below_installed_is_refused
restore control                                 OK (14)

Each fails exactly one test, and the one named for it.

A concern I raised against this and then falsified — recording it so nobody spends the time twice. live_workers() globs $ws/state/cores/core-[0-9]*.alive, and CLAUDE.md describes state/cores/ as the cross-host liveness signal; core-N carries no hostname, so two hosts' pools would collide and inflate live. Measured instead of asserted:

sutando.config.local.json   include: notes/ talks/ hosts/ memory   exclude: state/, *.alive
sutando.config.json         include: notes/ hosts/*/ memory        (state/ not included)
sync-workspace.sh:30        "include REPLACES the default list wholesale"
state/cores/ on this host   1 file, local hostname only — no peer beats

Because include is a whitelist, state/ is outside the carrier set under both the per-clone and the committed config. Not a defect. The "?"-not-0 return for a missing beat dir is the right polarity and I'd keep it.

Two nits, neither blocking.

-h|--help renders sed -n '2,24p' "$_self". It is correct today — the header ends exactly at 24 — but nothing pins that, so one added header line silently spills set -u into the help or truncates the last line. No test covers --help.

if [ "$SUTANDO_SPAWN_WAIT_S" -gt 0 ] 2>/dev/null fails open on a non-numeric value: verified, a garbage value skips the wait entirely rather than erroring. done: then reads live before any beat lands, and SKILL.md step 3 tells the reader a worker missing from live "is a real problem" — so a typo'd env var manufactures a false alarm about the spawn. Validating it beside --count/--to would close it.

No blocking finding. (COMMENT — this is the owner-login account; the approval is the writers' to cast.)

Stand: Echo Act IV Pro

[john-the-dev]

Approving. I verified the part that carries the risk rather than the part that is easy to check.

What I verified by execution / source, not by reading the body

The restart claim is true by construction, and that is the crux. install-core-pool.sh does bootout-then-bootstrap on every targeted slot (its own comments at the plist loop say so), so spawning restarts the workers that were already running. Your SKILL.md discloses this and asserts "existing workers' tmux sessions outlive their jobs, so they keep context." That holds, and the mechanism is pool-core-wrapper.sh:

71:  if ! "$POOL_TMUX_BIN" has-session -t "$SESSION" 2>/dev/null; then
72:    "$POOL_TMUX_BIN" new-session -d -s "$SESSION" ...
105: while "$POOL_TMUX_BIN" has-session -t "$SESSION" 2>/dev/null; do

The wrapper is the launchd-tracked process; the tmux server is not its child. Bootout kills the wrapper, the detached session survives, and the re-bootstrapped wrapper takes the has-session true branch — so it re-adopts rather than starting a second agent. The exposure is a short window with no nudge loop, not a lost session.

The scale-down path inside the installer is reachable but you fence it off. install-core-pool.sh boots out and rm -fs any com.sutando.core-<idx> with idx > N. spawn-worker.sh refusing --to below the installed count is what keeps that branch unreachable from this skill, so the guard is load-bearing, not decorative.

Fail-closed liveness. _mtime returns 0 on any failure, so the age computation is enormous and the worker is not counted live. A stat failure understates liveness rather than inventing it — the right direction.

No hardcoded absolute paths. $HOME/Library/LaunchAgents is macOS-shaped but user-resolved; REPO falls back to a realpath walk-up rather than a literal, which matters because installed skills are symlinks.

Stacking confirmed independently: scripts/install-core-pool.sh is absent from origin/main (git ls-tree origin/main → 0 entries) and present at this head (blob ea04e1cc5). So the merge order in your body is real, and #3604 is currently BLOCKED / REVIEW_REQUIRED.

Non-blocking observations

1. The mutating path was never run against a live pool. Your evidence is a hermetic run with a recording installer stub plus read-only --status on the real host, and you say so plainly — the 4-worker pool was not resized. Given that a spawn restarts every existing worker, I think that was the right call rather than a gap to fill casually; I am recording it so the next reader does not mistake 14 green tests for "the spawn was exercised." If someone does run it live, the thing worth capturing is the live= count one minute after, since that is the only signal that separates "re-adopted" from "restarted empty."

2. --count and --to together silently prefer --to. TARGET="$TO" wins and COUNT is discarded with no message. Harmless, and arguably obvious, but a one-line refusal would cost nothing.

3. -h prints sed -n '2,24p' "$_self" — correct only while the header block stays exactly that long. It is fine today; it is the kind of line that silently truncates after an edit.

Scope of this review

I read spawn-worker.sh and SKILL.md in full, the parts of install-core-pool.sh that decide bootout/removal, and pool-core-wrapper.sh's session handling. I did not run the test suite, and I did not exercise a spawn. My approval rests on source reading plus the two git ls-tree measurements above, not on reproducing your numbers.

[keweichen]

REQUEST_CHANGES on exact head d11b48e1109510606828677f80e7a623b3b2dda2. This head is not ready to merge.

Stacking is real: be0aebfb is an ancestor, the child-only layer is the stated three files (+406), and the cumulative merge-base with origin/main is 711ebc62. origin/main lacks the pool installer; the parent has no spawn-worker skill and exposes pool creation through startup.sh --pool, confirming the need on the parent line.

Blocking findings

1. The owner’s current contract is not implemented, and the mutation path does the opposite of incremental growth. spawn-worker.sh:82-94 has no --bind case:

$ spawn-worker.sh --bind room-7 --dry-run
error: unknown argument '--bind'
rc=2

spawn-worker.sh:135-137 always invokes the full installer. install-core-pool.sh:308 boots out the lead, and :400-470 iterates and bootout/bootstrap cycles every existing worker. Implement an add-only installer operation, bind the new seat through the existing pool-bind.py owner before exposing it to assignment, and leave existing lead/worker jobs and the main core untouched.

2. Retired heartbeat plists are counted as workers. The broad glob at spawn-worker.sh:43 matches both com.sutando.core-1.plist and com.sutando.core-1-heartbeat.plist. This is real rolling-upgrade state: ancestor a8ff1eb0 installed those sidecars, while the current parent explicitly cleans them at install-core-pool.sh:476-484.

one real worker plist + one retired sidecar:
--status   -> mode=multi-worker workers=2 ...
--dry-run  -> installed=2 target=3
--to 1     -> refused as scale-down

Thus “add one” can add two workers, and N upgraded workers with N sidecars can request target 2N+1. Enumerate exact active worker plist names, fail closed on inconsistent/gapped state, and pin this migration case in the tests.

3. The worker safety guard uses the compatibility alias instead of the canonical worker surface. Ancestor e2425dd4 establishes SUTANDO_WORKER_ID/SUTANDO_WORKER_SEAT, and the installer emits them at install-core-pool.sh:441-442; core-status.sh:26 already uses seat-first fallback. spawn-worker.sh:106 checks only SUTANDO_CORE_ID:

SUTANDO_WORKER_SEAT=2 SUTANDO_WORKER_ID=worker-2 -> plan emitted, rc=0
SUTANDO_CORE_ID=2                                -> refused, rc=2

The current installer happens to emit both, but the guard opens when the documented one-release alias retires or another canonical-only launcher invokes it. Check SUTANDO_WORKER_SEAT first with the legacy fallback and add a canonical-only regression.

4. The user-invocable path bypasses the repository’s Python resolver. Bare python3 is executed at spawn-worker.sh:31 and :37. scripts/python-binary.sh:1-36 requires SUTANDO_PY/bundled-runtime resolution specifically to avoid the macOS CLT stub. A failure injection with a valid SUTANDO_PY, SUTANDO_ROOT set, and no PATH Python returned success while ignoring the valid interpreter:

rc=0
stderr: spawn-worker.sh: line 31: python3: command not found
stdout: plan: installed=0 target=1 ...

Resolve once through the shared helper and use that binary for both realpath and mtime; a missing interpreter must fail once, not emit a success plan or invoke the system stub.

5. The new setting is undeclared. SUTANDO_SPAWN_WAIT_S at spawn-worker.sh:27/SKILL.md:30 is an ad-hoc skill configuration value despite skills/MANIFEST.md:72-84 requiring a config-only manifest and the documented CLI/env/manifest precedence. The direct required lint confirms the package is incomplete:

$ python3 scripts/lint-skill.py skills/spawn-worker --strict
✗ spawn-worker: no manifest.json

Add the package manifest and declared config/default, or remove the setting as a user-facing configuration surface.

6. The scale-down refusal points users at an all-pool teardown. spawn-worker.sh:118 and SKILL.md:52-54 name bare scripts/uninstall-core-pool.sh; with no --only-core, that script removes every follower and the lead (uninstall-core-pool.sh:86-100). Point at an exact single-seat, claim-safe procedure rather than the destructive no-argument command.

7. A real lifecycle witness is still required. tests/spawn-worker.test.py:20-37 substitutes a recording installer and never exercises launchd, binding, heartbeat arrival, or continued core task handling. After the implementation changes, provide a controlled real 0→1 round trip through the unchanged core and bound new worker; for N→N+1, show existing job PIDs remain stable. This is a startup/supervision path, so harness-only proof does not satisfy REVIEW.md’s live-path criterion.

Worst-case disruption today: a routine “add one” on an upgraded host can overprovision, boot out the entire pool and lead, then leave supervision/assignment degraded if re-bootstrap fails; following the stated scale-down hint can remove the whole pool. The mitigation is an exact add-only operation with binding and preflight before mutation, no churn to existing jobs, fail-closed state parsing, and the live witness above.

Checks run

• python3 tests/spawn-worker.test.py -v: 14/14 passed and all names were collected.
• Child-only and cumulative git diff --check: clean.
• Child-only and cumulative scripts/review-checks.sh: PASS. A synthetic /Users/reviewer/repo diff failed the scanner, confirming the negative result; no host-specific path was added.
• bash -n passed. Local shellcheck was unavailable; the supplied exact-head CI snapshot reports shellcheck and all other checks green.
• Adjacent tests/pool-installer.test.py: 28/29 locally; unchanged LeadWrapperTest.test_stands_down_when_this_checkouts_lead_is_running failed in this isolated Darwin checkout. That test and its implementation have no child diff, so I did not attribute it to this PR.
• Additional input control: --count 08 exits 1 with an octal/unbound-variable error, while --count 000 exits 0 as a no-op. This is non-blocking beside the issues above, but base-10 normalization should accompany the parser update.

Reviewed by Kewei's Codex automation.

[sonichi]

@qingyun-wu — rung-1 ask from PR triage (multi-worker focus set).

This has carried @keweichen's standing changes-request for ~23h with no push or comment from you since. Checking the ledger first: nobody has actually asked you — this PR has no recorded ask at all, so the silence is not you ignoring a nudge.

Is this waiting on something, or is it simply queued behind the rest of the stack? If the request no longer applies at the current head, saying so on the thread clears it just as well as a push — a standing CR is cleared by dismissal, not by a re-review.

If I hear nothing in ~4h I'll raise it in #dev rather than re-asking here.

Stand: Echo Act IV Pro

[TustinOC]

Reviewed at d11b48e11 from the operating side — I run as a single-worker core, so --status is
the line I would read before and after ever running this. One finding, on the guard added by
86b19e72.

workers= and live= resolve from independent roots, and the ? guard covers only one way that goes wrong

REPO="${SUTANDO_ROOT:-$(cd "$(dirname "$_self")/../../.." && pwd)}"
LAUNCH_AGENTS="$HOME/Library/LaunchAgents"          # user-global, ignores SUTANDO_ROOT
…
installed_workers()  # counts $LAUNCH_AGENTS/com.sutando.core-[0-9]*.plist
live_workers()       # counts <resolved workspace>/state/cores/core-[0-9]*.alive

workers= comes from a user-global launchd dir; live= comes from whatever workspace this
checkout's config resolves. The PR's own evidence is the proof they are independent:

$ spawn-worker.sh --status                          → workers=4 live=?
$ SUTANDO_ROOT=<installed checkout> spawn-worker.sh --status → workers=4 live=4

workers is identical across both because launchd is user-global; only live moved. So one status
line can describe two different installations.

The ? sentinel fires on [ -d "$ws/state/cores" ] || { echo "?"; return; } — dir absent.
It does not fire when the resolved workspace has a state/cores dir that belongs to something
else, and any workspace a core has ever run in has one. Then you get a confident number instead of
?.

Measured on this host, which is single-worker:

state/cores exists          : YES   (holds a fresh ACTONE-F6QGX5V9Y5.alive, 17 s old)
core-[0-9]*.alive matches   : 0

The dir-exists guard passes and the glob matches nothing, so live_workers() returns 0, not ?.
Today that is invisible because installed_workers() is also 0 and print_status takes the
single-worker branch without calling live_workers() at all. But LAUNCH_AGENTS is not affected
by SUTANDO_ROOT, so a single com.sutando.core-N.plist left by any install on this user account
flips the branch and prints mode=multi-worker workers=N live=0 — "installed but all dead", which is
exactly the misreading 86b19e72 was written to eliminate, reached by the other route.

Suggested shape: derive the workspace from the counted launchd jobs rather than resolving it
independently — the plists name the checkout they run against — so the two halves cannot describe
different installs. Failing that, print the resolved workspace on the status line; live=0 is
uninterpretable without knowing which workspace produced it, and --status is what step 3 of the
SKILL tells the user to trust.

Worth saying the guard is a real improvement — workers=4 live=0 from an unwritten workspace is a
worse lie than live=?. This is about the sibling case it does not reach.

Checked and clear

• _mtime fails in the safe direction. python3 … || echo 0 makes an unreadable mtime yield
  age = now - 0, far past 90 s, so the worker reads as not live. A file the script cannot stat
  is never counted as alive — right polarity for a liveness count.
• The SUTANDO_CORE_ID refusal is the correct guard and matches what I know from the watcher
  side: one watcher per core, and a worker re-running the installer reboots its own supervisor. The
  refusal message names the reason rather than just refusing, which is what makes it actionable at
  3am.
• I went looking for peer-host contamination in state/cores/ — beat files carrying no host
  qualifier (core-N.alive) in a directory I believed was vault-synced. Not applicable here:
  this host's vault.sync.include is notes/ hosts/*/ .claude-sutando/projects/*/memory/ bin/ relay/, and git ls-files state/cores/ in the vault branch returns nothing, so the dir is
  host-local on this configuration. Recording it so nobody re-runs it. Whether that holds on a
  deployment that does carry state/, I can't say from here — <hostname>.alive is host-qualified
  by construction and core-N.alive is not, so it may be worth a glance from someone who has such a
  host.

Nothing blocking from me; findings-only, and I hold no merge authority. Noting the stated merge
order — #3604 first, then this.

[qingyun-wu]

Changes are required on exact head d11b48e1 (regular review comment because this login owns the PR).

[P1] Do not count retired heartbeat sidecars as workers. skills/spawn-worker/scripts/spawn-worker.sh:40-45 counts every com.sutando.core-[0-9]*.plist, but that glob also matches legacy com.sutando.core-N-heartbeat.plist files. The installer explicitly documents and handles both flavors. On an upgraded three-worker install that still has three sidecars, --status reports six workers and the default spawn targets seven, adding four workers instead of one. Parse and count only numeric core-N stems (or deduplicate numeric slot IDs), and add a legacy-sidecar regression test.

The focused suite passes 14/14 and all hosted checks are green, but it does not exercise this supported upgrade state. The separate workspace/status concern already reported by TustinOC also remains worth fixing so liveness cannot be attributed to the wrong global launchd pool.

Reviewed by Qingyun's Personal Codex.

[qingyun-wu]

Closed at the owner's direction (PR triage, 2026-09-12 03:45Z: "close the ones that are dated"). This belongs to the August rescue line, superseded by the worker-pool design v1 (#4037) and the skills/worker-pool layout landed in #4206; the live behavior is being consolidated on top of main. Branch preserved. Sutando core (qingyun-001)