[bug] The agent prescribes `pags up` when the runner is excluded by the pin — the chat prompt is a fourth "no runner" construction site and the only one never wired to diagnoseAttachment

[serge-ivo]

The agent tells the owner to run pags up when pags up is already running and the pin is the problem

Live, instance f8ddc272-0390-4826-8812-94989e3d2ebd, 2026-08-12:

07:44:05  chat.in   "Retry"
07:44:10  chat.out  "The runner is currently offline — I can't start new work until it's
                     connected. Run `pags up` in your terminal to bring it back online…"

No tool.call between them (agent_trace, and instance_activity shows chat.message → chat.response with no tool.called). The refusal came from the system prompt, not a tool.

The owner's pags up was running the whole time, on RLs-MacBook-Air (runner row created 03:07:22, live). The instance was pinned to Sergeys-Mac-mini.local. At 07:55:10 the same start_work succeeded — the only variable that changed was the pin.

Mechanism

workers/api/src/agent-think.ts:534-535:

const boundConn = await getBoundRunnerConn(env, state.agentId, userId).catch(() => null);
const runnerOnline = boundConn ? await relayConnected(env, state.agentId, boundConn.runnerNode ?? null) : false;
systemPrompt += runnerStatusPrompt(selfModel, runnerOnline);

getBoundRunnerConn is pin-authoritative and correctly returns null — the mini and the Air carry different machine_ids, so aliasNodesFor cannot rescue it (runner-client.ts:96-101). The routing verdict is right.

Then it is collapsed to a boolean, and lib/agent-style-prompt.ts:89-99 turns that boolean into a fixed remedy:

const remedy = model.hasRunner
  ? ` If the user wants to run, search, or fix code, tell them to start the runner first with \`pags up\`…`

grep -c diagnoseAttachment workers/api/src/agent-think.ts workers/api/src/lib/agent-style-prompt.ts → 0 and 0.

The correct sentence already exists and is deliberately remedy-free

lib/runtime-attachment.ts:69-79 produces: "This agent is pinned to Sergeys-Mac-mini.local, which isn't connected. RLs-MacBook-Air is connected — set 'Runs on' to RLs-MacBook-Air (or Automatic)" — and carries no remedy string, precisely because pags up is the wrong advice in this state.

The chat prompt is a fourth construction site for "why is there no runner", and the only one never wired to that diagnosis. 07ec7af (#461) and e6e330d (#468) fixed forwarding for the three adapters; this path was not in their scope, so those commits could not have reached it.

Same class as #271/#321/#524 — a message that cannot name the machine it means — in a file none of them touched.

Acceptance criteria

1. When the runner is unavailable because of a pin, the agent says so and names both machines, instead of prescribing pags up.
2. The chat prompt consumes diagnoseAttachment rather than re-deriving a boolean — one construction site, not four.
3. Where the true remedy is "change Runs on", the agent does not offer a remedy the platform knows is wrong. Note runtime-attachment.ts returns remedy: null for this case on purpose; respect that rather than substituting one.
4. A genuinely absent runner still gets the pags up advice — this must not become a generic softening.
5. A test with pin=A, live=B asserting the reply names the pin.

Verified vs inferred

• Verified: the 07:44:10 refusal and its absence of a tool call; start_work succeeding at 07:55:10; the three code paths above; that diagnoseAttachment appears in neither file; that the two machines have different machine_ids (measured on "Run npm i -g @proagentstore/cli on that machine" names no machine — the owner has two runners, already upgraded one, and the agent is pinned to the other #524).
• Inferred: that the pin was Sergeys-Mac-mini.local at 07:44:10 specifically. PUT /v1/instances/:id/runner-node (instances.ts:499-511) writes the config key and logs nothing, so the repin moment is unrecoverable. The inference rests on "Run npm i -g @proagentstore/cli on that machine" names no machine — the owner has two runners, already upgraded one, and the agent is pinned to the other #524 measuring that pin at 04:16 UTC, an independent read earlier the same session, and the 07:44-refuses / 07:55-succeeds pair.

A second, separable gap this exposed: the repin is invisible — no agent_events row, no activity entry. A configuration change that silently decides whether every tool call routes anywhere should leave a record.

[serge-ivo]

Fixed in f3fd455, deployed to production (CI 31577974130 green, Deploy API Worker 31577974186 success, api.proagentstore.online/health 200).

What changed

runnerStatusPrompt(model, status: AttachmentDiagnosis | null) — the prompt now quotes the remedy from the diagnosis instead of writing one, so pinned-machine-offline (which carries remedy: null on purpose) emits no command at all and instead names both machines. The diagnosis is fed through describeFacts, the adapter #461 fixed, not through diagnoseAttachment directly — so this is one construction site fewer, not a fifth.

agent-think.ts now consumes runtimeConnectivityWithConn, a new single-instance form in lib/instance-connectivity.ts that hands back the connection as well as the facts. That is what keeps the fix free: getBoundRunnerConn has already live-checked the relay by the time it returns a connection, so the relayConnected() call this replaces was re-asking the RelayDO for a fact the previous line had established. The online path is one DO fetch cheaper; the added cost is two D1 statements issued in parallel with the resolution, and the liveNodeIgnoringPin scan is paid only when pinned-and-unresolved — the broken case itself.

Acceptance criteria

1. ✅ Pin-caused unavailability names both machines instead of prescribing pags up.
2. ✅ The prompt consumes diagnoseAttachment via describeFacts rather than re-deriving a boolean.
3. ✅ remedy: null is honoured — no substituted remedy, asserted by test.
4. ✅ Not a generic softening: never-registered/runner-offline still say pags up, machine-online-agent-detached still says pags up --force, and the ONLINE sentence is unchanged byte for byte (test-pinned).
5. ✅ pin=Sergeys-Mac-mini.local / live=RLs-MacBook-Air asserts both names present and pags up absent.

The prompt-claims.ts sweep's runnerOnline: boolean axis became the six diagnosis states as a Record<AttachmentState, …>, so a seventh state is a compile error rather than an untested branch. That matters because the pinned message ends "…or start the runner on X", which the local-runner claim rule reads as a claim about a local runtime — both the diagnosis text and the remedy therefore stay gated on model.hasRunner. Mutation-checked: dropping that gate turns repo-chat, coder-lead and plain-chat red.

Verified

pnpm typecheck (11 projects), pnpm vitest run (454 files / 7930 tests, all pass), biome (1128 files), design-tokens, agents-allowlist, qa-config, file-size ratchet (agent-think.ts unchanged at its pin — 20536/20549 total, no pin lowered), migrations --require-history, test-isolation, docs:drift. All re-run by the committer on the exact tree pushed, which was a clean fast-forward from the tested base.

NOT verified — stated plainly

• No live chat turn was run against a pinned instance. Reproducing it means repointing a production instance's "Runs on" at a machine that is switched off, which I am not doing to someone's working setup. The fix is unit-level-verified only. If you want end-to-end confirmation: pin an instance with attached repos to a machine that is down while pags up runs elsewhere, then ask it to start work — the reply should name both machines and contain no pags up.
• The pin value at 07:44:10 remains INFERRED, not measured, exactly as filed. PUT /v1/instances/:id/runner-node logs nothing, so the repin moment is unrecoverable. The fix does not depend on that timing being right, only on the state being reachable — which the code path makes it.

Left open, deliberately

The separable gap this issue records — the repin is invisible — is untouched and needs its own ticket. It is not the one-liner it looks like: grep -c "logAgentEvent\|logEvent\|recordActivity" workers/api/src/routes/instances.ts returns 0, so it means introducing the first event write into that file (an event type, a trace-id decision, a test).

Separately, lib/tool-registry.ts:75-76 has the same collapse-to-boolean shape for tool gating. Outside this issue's ACs and file set; flagging as a likely sibling.