[bug] The Coder Lead refuses to delegate, citing a runner that is online — subordinate_status reports no connectivity at all

[serge-ivo]

Live test, 2026-08-06

Asked the Coder Lead (5fab318d) to delegate a read-only typecheck to any one of its four repo
coders. It replied:

• FAS platform — idle, coding session completed. No active runner.
• FWS platform — idle, coding session completed. No active runner.
• FGS platform — coding session failed/orphaned. No active runner.
• PAS Coder — idle, coding session completed. No active runner.

None of the four agents have a live coding session right now, so I cannot delegate the typecheck
job to any of them. You need to start a coding session (and run pags up) on at least one agent
before I can delegate anything.

Both halves of that are wrong.

1. The runner was online — and subordinate_status never mentions runners

coding_diagnostics for FAS (964594b6), same moment:

runnerOnline: true   runnerStatus: online   relayConnected: true   reachable: true
runnerVersion: 0.4.32   lastSeenAt: 2026-08-06 05:33:36   health.ok: true
activeSessions: 0

pags up was running the whole time. The Lead inferred "No active runner" from
activeSessions: 0 — two different things.

It had no choice but to guess, because the tool it read gives it nothing about connectivity.
observeSubordinates (lib/connectors/supervision.ts:94) composes exactly three sources:

subordinateSummaries(...)        // roster + SUBSCRIPTION state
recentWorkForInstances(...)      // board/work items
recentRunsForInstances(...)      // loop runs

No relayConnected, no runtime row, no node. So a supervisor asked "can they work?" has no
grounded answer, and fills the gap with the nearest available signal.

2. A live session is NOT a precondition for delegating

delegate_goal's handler has no runtime check and no session check — it starts a run. The
executor creates its own session.

Proven on this very instance two hours earlier: the FAS Coder had zero active sessions, called
start_work, and the Pilot created csess_a3f04e45 at 03:44:50 and ran the job. The Lead's stated
precondition is contradicted by its own subordinate's history.

Why this matters

This is the third instance of the same class (#254 told it cannot act, #255 not told what it owns),
and the most expensive: the supervisor refused work it could have done and told the user to
perform setup that was already done. A supervisor that under-reports capability is worse than no
supervisor — the human now has to verify every refusal.

Fix

Give the supervisor the signal. Add per-subordinate connectivity to the subordinate_status
view — live relay state (not the stale instance_runtimes row; see #238), node name, and runner
version. relayConnected already exists and is what coding_diagnostics uses.

Correct the precondition. delegate_goal's description should state that delegation does not
require a live session — the executor starts one — and that the only real blocker is no connected
runner for a subordinate whose work needs one. A cloud-only subordinate needs no runner at all.

Distinguish the two states in the summary. "idle, no active session" and "no runner connected"
must not render as one line, because the first is normal and the second is blocking.

Verification

• With pags up running and no sessions, the Lead delegates successfully.
• With the runner genuinely offline, it says so specifically and names the machine.
• subordinate_status output contains a connectivity field per subordinate; the model is never
  asked to infer it.

[serge-ivo]

Correction — I got one of the two claims wrong

I wrote "a live session is NOT a precondition for delegating" and cited FAS session csess_a3f04e45 as proof that start_work creates one. That was wrong. Checking the timestamps:

csess_a3f04e45 startedAt   03:44:50   ← already open
user message               03:45:12
Loop → engine (step 1)     03:45:23
csess_a3f04e45 endedAt     03:45:36   ← the Pilot closed it

The session pre-existed the request by 22 seconds. start_work consumed it; it did not create it.

A live session IS a hard precondition, and always has been — lib/loop-drivers.ts:116:

const session = await getActiveSessionForRepo(env, instanceId, userId, repo.id);
if (!session) return { ok: false, status: 409, error: `${repo.name} has no live coding session…` };

Introduced with the driver in 7fc9f5e (#210), not a recent regression.

Retested just now on FAS with the runner online: start_work fired correctly (the #254 fix works — the agent handed off instead of denying) and the executor returned fas/platform has no live coding session.

What remains valid here, and it is the important half

subordinate_status still reports no connectivity of any kind. observeSubordinates
(supervision.ts:94) composes roster + work + loop runs, nothing else. The Lead said "No active
runner" for four agents while runnerOnline: true, relayConnected: true, reachable: true, v0.4.32 — it inferred a runner state it was never given. That is the bug.

The fix narrows usefully: the supervisor needs two signals it currently lacks — is a runner
connected, and does this subordinate have a live session — because with a correct precondition the
second one is exactly what determines whether delegate_goal can succeed. Right now it has
neither and guesses both.

Retitling in spirit: not "the precondition is wrong" but "the supervisor cannot see either
precondition."

[serge-ivo]

Fixed in 03f79b7 (fix(coder): the Lead can see connectivity, and delegation stops being single-use (#259, #271)).

Verified at HEAD before building — both claims in the report were still true. observeSubordinates (lib/connectors/supervision.ts) composed exactly the three sources named and nothing about connectivity; delegate_goal's handler had no runtime or session check.

What shipped

The tool's data, not its prompt. Every subordinate in subordinate_status (and in check_delegation's no-run-id branch, which shares the same view) now carries:

"connectivity": {
  "requiresRunner": true, "state": "attached", "canWork": true,
  "node": "macbook", "runnerVersion": "0.4.32", "lastSeenAt": "…",
  "message": "Runner connected on macbook — you can delegate work to it now, whether or not it is currently busy.",
  "remedy": null
}

Three things worth naming:

• It reuses diagnoseAttachment ([bug] A rejected relay socket retries forever and the console shows only an unexplained amber dot #237), as suggested — not a fourth notion of connectivity. New pure module lib/subordinate-connectivity.ts wraps it and adds the one case that diagnosis cannot see: requiresRunner: false for a cloud-only agent (capabilities.runtime: null), which previously would have been classified "never-registered → pags up" for a machine that was never part of its design.
• The live probe is getBoundRunnerConn (lib/instance-connectivity.ts) — the same resolver callRunner/delegation actually route through, not the instance_runtimes.status column (which is never cleared on disconnect, [bug] /runtime/status reports the stale default row's node, so the console's connected dot can be flatly wrong #238). So what the Lead reads cannot disagree with what happens when it acts. Registrations are read from instance_runtimes + instance_runtime_nodes in one statement; relay probes are capped at 16 per call.
• A legend line rides in the payload, not only in the tool description: "connectivity.canWork is the ONLY field that says whether an agent can be given work now. Empty work/runs means IDLE — which is normal and ready, not offline." The description is far away by the time the model reads the JSON, and the failure being prevented is precisely reasoning from an empty board.

The precondition is corrected, as asked. delegate_goal's description now states that delegation needs no open coding session — the executor starts one — that the only blocker is connectivity.canWork: false, and that a cloud-only subordinate needs no runner. That is now true rather than aspirational, because #271 shipped in the same commit: the driver opens a session on demand.

Tests

lib/subordinate-connectivity.test.ts (7) covers the classification: connected-but-idle is delegable; cloud-only never gets a pags up remedy; offline names the machine; never-registered vs stopped stay distinct; a live machine with a detached agent gets --force, not pags up; blank runner_node (NOT NULL DEFAULT '', migration 0030) reads as absent rather than an empty machine name. Plus 4 new cases in connectors/supervision.test.ts asserting the field reaches the tool output.

Not done

I did not touch how the Lead phrases its answer — no prompt engineering. The premise of the report is that a model asked to infer connectivity will keep getting it wrong, so the fix is that the correct answer is now readable rather than deducible.