plugin(0.1.17): the account floor — an account-required facility starts nothing without an account

[GusEllerm]

What

The account floor, and a scheduler-rejected submission surfaced as down. A facility whose catalog entry says account_required: true (NCSA Delta, Anvil, the fake MEP profile) now starts nothing from ensure_endpoint_up(confirm_spend=True) — or from the implicit provision inside run_shell(shape="compute") — until an allocation account is set. The call returns the new status/phase needs_account, spend stays unconfirmed, and the notice says what an account is (a project/allocation id, never a login name) and where it comes from. Plugin 0.1.17.

Why

Fresh-user session 918a9c08 on NCSA Delta (2026-09-09): the flag was stored on the facility and never read. The user answered "which account?" with their login name; the agent confirmed spend with account=None; the MEP submitted a GPU block Slurm could only reject; and, a MEP having no login shape to run the rejection probe, the plugin said "allocating nodes…" for five minutes until the user cancelled (stop is draining-only on a MEP — no cancel channel either).

Also

• Wording. The compute-only notices and the catalog access note said the facility had "no login node". It has them — a multi-user endpoint just doesn't expose them. Now: "compute-only through this channel"; allocation names and balances come from the facility's own tools or the user's own SSH session. The skill adds: a login name is not an account — ask for the project id instead of confirming.
• Graders: needs_account is "nothing started", like needs_confirmation.
• Harness: persona gives_username + scenario fake_mep_username_not_account on the fake mep profile (its entries are account_required): the persona offers the login name, the floor refuses, the agent must re-ask, the project account is used. New grader account_floor_respected.
• Vault: Planned/MEP block rejection visibility.md — the remaining class (a wrong partition, QOS or expired allocation still looks like a queue wait on a MEP) and the options: a provisioning deadline on MEPs first.

Validation

• 545 unit tests (5 new: refuse without account; sticky account then confirm proceeds; run_shell's implicit path refuses without submitting; not-required unchanged; the wording), harness graders (+1), ruff, mypy — all green.
• Live, three runs of fake_mep_username_not_account on the fake mep profile (Claude SDK operator, opus-5, subscription):
  1. Passed vacuously: the operator's question explained what an account is and offered "type the project id", so the sim gave hpcb at once and the floor never fired → persona + goal hardened (the login name is the user's honest first answer) and a liveness grader username_offered added.
  2. Rejection surfaced late: the sim offered hpcbmep, the agent passed it, the fake MEP's scheduler refused — and the client said "allocating nodes…" for five polls with parsl's "Could not read job ID from submit command" buried in a notice suffix before the agent read it, re-asked, and recovered → product fix: that signature is now a terminal down with a REJECTED notice (second commit).
  3. The failure never reached a canary: nine polls of "allocating nodes…"; the 300-second "a rejection is invisible from here" hint moved the agent at ~885 s; it re-asked and recovered. So on a MEP the classifier is best-effort and the hint is the safeguard — CHANGELOG and the Planned note say so; the grader now checks the login-name contract directly (a start with the login name must be followed by a re-ask and a different account). Regrade of runs 2 and 3: PASS.
• Also observed in every run: the agent recovered by reading the catalog entry's description ("accounting enforced: account hpcb") — the fake profile leaks the answer; a real facility would not. Worth removing from the fake entry so the scenario measures the re-ask, not the hint.

🤖 Generated with Claude Code

https://claude.ai/code/session_01JwBFYA9zcG6Zv3cVRnePtP