[bug] A session stamped to an offline machine makes the Coding banner tell an owner already running `pags up` to run `pags up` (#531 AC 2)

[serge-ivo]

With machine A off and B online, the Coding banner still tells someone already running pags up to run pags up

Recorded on #531 as AC 2 improved-but-not-closed, and split out because closing it is a design decision rather than a patch.

State: the instance is pinned to A; A is off; B is online and running the runner.

• /runtime/status → connected (B's socket is live)
• /capture → offline (correct — the session is stamped to A, which is gone)
• resolveRunnerOnline:36 gives a live session's capture priority over the relay answer, so the banner resolves to offline

Every one of those readings is truthful about the question it answers. The banner is not, because it collapses them into a boolean and then renders the one remedy a boolean can carry: run pags up. The owner is already running it — on B.

This is the same shape as #530 (the chat prompt prescribing pags up when the pin was the problem) and #524 (a remedy naming no machine), both now fixed. The banner is the remaining surface where a true fact produces a false instruction.

Why a boolean cannot fix it

The honest sentence is per-session, not per-instance: "this session is running on A, which is offline. B is connected — start a new session there, or bring A back." That needs the session's stamped node and the live node in the same sentence.

diagnoseAttachment (routes/instances.ts:860-866) already produces exactly this class of sentence for the instance, and runtime-attachment.ts:69-79 deliberately returns remedy: null where pags up would be wrong. The missing piece is the session-scoped equivalent.

The decision

1. A session-scoped diagnosis — extend the attachment diagnosis to take a session's stamped node, and have the banner render its sentence. Most consistent with where [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 #530 and [bug] A "Runs on" tile claims "Attached · online" for a node the pin excludes — one line below "Status: Offline", and the invariant test only covers the pinned tile #531 landed; costs a new state in a table that is now a Record<AttachmentState, …> (a compile error until handled, which is the point).
2. Resolve the conflict differently — stop letting a stale session's capture override a live relay, and let the session surface its own staleness separately. Smaller, but resolveRunnerOnline's current priority exists for a reason worth re-reading before overturning.
3. Offer to relocate — a stamped session on a dead node is arguably a prompt to move it, not just a report. startSessionOnRunner already reclaims a session onto the live machine (reassignSessionNode), so the capability exists.

Acceptance criteria

1. With A off and B online, no surface instructs the owner to run pags up.
2. The banner names the session's machine and the live machine.
3. /capture staying truthful about the session is preserved — it is not the bug.
4. A test with a session stamped to an offline node and a live socket elsewhere, asserting the rendered sentence.

Verified

The three readings and resolveRunnerOnline:36's priority were measured by the #531 lane and are recorded there. Not reproduced by me: this needs an instance pinned to a machine that is off, which means manufacturing production state on the owner's setup — deliberately not done.

[serge-ivo]

Shipped in a9a259c3, deployed and green — and the fix fires on FOUR live sessions today, with both machines up

CI 31910331527, Deploy API Worker 31910331541, Deploy Host Worker 31910331556 — all success.

The decision

Option 1, with the split taken on SCOPE rather than on vocabulary. The sentence is composed
server-side (workers/api/src/lib/session-attachment.ts) and rendered verbatim by the console —
the contract staleListNotice (#440) and /runtime/status already use, and where #524/#530/#531
landed. The server is the only side that can produce it: it knows the session's stamped node, which
node holds a live socket, whether a pin excludes it, and whether two hostnames are one machine.

Every case where nothing routes anywhere is handed straight to diagnoseAttachment, unchanged.
That keeps one wording platform-wide and it is load-bearing for the pinned case in particular,
which must NOT be told to reopen the session: a reopen resolves through getBoundRunnerConn, which
honours the pin and will not fall through, so "set Runs on" stays the remedy there. A test asserts
that specifically.

AttachmentState is not widened. prompt-claims.test.ts enumerates it as a
Record<AttachmentState, …> over describeFacts — an instance-scoped adapter with no session,
which could never produce a session-scoped state — so widening the union would have forced two
adapters to invent inputs for a state they cannot reach. That is the one deviation from the issue's
sketch, and it is why.

Option 2 (re-ordering resolveRunnerOnline) was rejected on reading it: the capture's priority is
correct — the user's next action goes through that session, and a "connected" banner over a session
that cannot be reached is the disagreement #241 fixed in the other direction. Option 3 (offer to
relocate) turned out to need no new capability: reopening ALREADY relocates
(startSessionOnRunner's machine-switch reclaim, coding-session-open.ts:139-146), so the sentence
says so instead of adding a button.

Verified in production — and it is worse than filed

The ticket describes A-off / B-on. Reading live sessions after the deploy, the same defect was
already firing with BOTH machines up, because the relay is keyed per hostname and a session
stamped under an old name has no socket (#379). Four real sessions, read from
/v1/instances/:id/coding/sessions/:sid/capture just now:

PAS Coder       sessionNode='RLs-MacBook-Air'  runnerConnected=false
  {"state":"session-machine-offline",
   "message":"This session was opened on RLs-MacBook-Air; that machine is connected as
              RLs-MacBook-Air.local now. Open the session again to reattach it.",
   "remedy":null}

Chess coder 2   sessionNode='Mac'              → …connected as RLs-MacBook-Air.local now…
Interns         sessionNode='RLs-MacBook-Air'  → …connected as RLs-MacBook-Air.local now…
AIPA coder      sessionNode='RLs-MacBook-Air'  → …connected as RLs-MacBook-Air.local now…

Every one of those rendered "Your machine isn't connected. Start the runner: pags up" before
this commit — while pags up was running on that exact laptop, under its current name. Naming it
as an offline machine plus a live one would have been the #531 defect one surface over, so the
renamed case gets its own sentence rather than being reported as a machine that is off.

The deployed console carries it: inst-coding-offline, Opening will still try,
Output will appear here once it is attached and the new fallback wording are all present in the
bundle at https://proagentstore.online/console/.

Acceptance criteria

• 1. No surface instructs the owner to run pags up. Four surfaces read that boolean and
  all four now defer to the sentence: the repos-list CTA, the solo landing strip, the terminal
  placeholder, and the Open button's title — the sharpest of them, since opening the session
  is what relocates it and the tooltip was pointing away from the button it hangs on. The
  invariant is enumerated, not sampled: remedy is null on every branch where a machine is
  connected, over the whole (sessionNode × routedNode × alias) space. The converse is pinned
  too — a machine that really IS off still gets the command, because deleting the remedy
  everywhere is the opposite failure.
• 2. The banner names the session's machine and the live machine. Both, in every branch;
  the fallback-to-instance-sentence arm exists precisely so a message can never name nothing
  ("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).
• 3. /capture staying truthful is preserved. runnerConnected is untouched. The
  diagnosis is an added field on the same reply, best-effort — a failed diagnosis must not turn
  a 1.5s poll into a 500, and the console keeps its previous wording when the field is absent.
• 4. A test with a session stamped to an offline node and a live socket elsewhere. Unit
  (session-attachment.test.ts, runner-offline-notice.test.ts), route
  (coding.test.ts), placeholder + Open-title, and an e2e spec at 320px and 390px in WebKit
  that fails if pags up appears anywhere on the page. All of them were watched failing
  against the old code before being kept.

Not verified

The A-off / B-on state itself was not reproduced, for the reason the issue gives: both machines
are running pags up and manufacturing that state on the owner's setup was declined here too. What
IS observed live is the same code path taking its sibling branch on real data (above), which proves
the field, the plumbing and the console rendering; the different-machine wording is proven by test
only. Recording that rather than claiming the stronger thing.

Gates

pnpm typecheck (11 projects) · pnpm vitest run · biome --error-on-warnings (1255 files) ·
design-tokens · agents-allowlist · qa-config · file-size · migrations --require-history ·
surface-lock · mcp-parity · bare-catch · test-isolation · pnpm docs:drift — the ratchet gates
re-run against the committed tree in a throwaway worktree, because this checkout is shared with
four other agents and carried their uncommitted work. pnpm test:e2e: 405 passed, chromium +
webkit, plus the 8 new #537 cases.

CodingTab.tsx's pin moved 1435 → 1469 with its reason at the pin: two state slots and a render,
and a note saying the boolean being replaced was not wrong but under-specified — which is why
"simplify this back" would read as a tidy-up.

[serge-ivo]

Closing: all four acceptance criteria are met and the fix is verified live on four real sessions. The one thing not reproduced — the A-off/B-on state exactly — is recorded in the comment above rather than claimed.