Skip to content

Panel-confirmed queue starts + harness-config lockdown for deployed agents - #574

Merged
thellert merged 2 commits into
mainfrom
feature/bluesky-panel-confirmed-start
Aug 12, 2026
Merged

Panel-confirmed queue starts + harness-config lockdown for deployed agents#574
thellert merged 2 commits into
mainfrom
feature/bluesky-panel-confirmed-start

Conversation

@thellert

Copy link
Copy Markdown
Collaborator

What

1. Panel-confirmed start requests for tokenless agents — deployed web terminals never hold the Bluesky launch token (by design), so the agent's queue_start used to dead-end in a refusal that read like a config bug. Now it files a start request:

  • Bridge: ungated POST/DELETE /queue/start-request park/withdraw a request record published on the queue summary + SSE stream. The only start path remains the token-gated POST /queue/start, which consumes the request; the writes kill switch still refuses before a request is filed.
  • Panel: the BLUESKY queue panel renders the pending request beside the queue it would drain, with Confirm start (the panel's own token-carrying start) and Dismiss.
  • MCP: tokenless queue_start returns {started: false, start_request, message} telling the agent the human's confirmation is waiting in the queue panel.
  • Messaging swept for one consistent story across the operating/writing skills, tool docstrings, refusal hints, deploy hints, and the bluesky how-to pages: the agent never holds the token in a deployed terminal, the human's click is the arming decision, config surgery is never the fix.

2. Harness-config lockdown — rendered settings.json switches off the CLI's bundled harness-configuration skills (update-config, keybindings-help, fewer-permission-prompts) via skillOverrides, and setup-mode (whose setup_patch can edit config.yml/.mcp.json) leaves the operator preset's default roster — it stays in the artifact catalog for admin profiles. Preset hash pins re-pinned; deployed projects report staleness once, as intended.

Testing

  • 10 new bridge wire-contract tests (filing, replacement, refusals, dismiss idempotency, clear-on-start, SSE frames, never-arms negative controls)
  • MCP tool tests for the request flow, gate order, and emit sites
  • Sidecar relay + write-surface inventory tests for the two new routes; vitest coverage for the panel's pure helpers
  • Settings render test for the skill overrides; docs build clean

Local targeted suites are green; full validation left to CI.

Deployed web terminals never hold the scan launch token, so a tokenless
queue_start previously dead-ended in a refusal that read like a config
bug. It now files a start request the bridge publishes on the queue
summary and SSE stream; the BLUESKY queue panel renders it beside the
queue it would drain with Confirm start (the panel's own token-gated
start) and Dismiss controls. The request routes are ungated and arm
nothing — the only start path remains the token-gated POST /queue/start,
and the kill switch still refuses before a request is filed.

Skill guidance, tool docstrings, refusal hints, deploy hints, and the
bluesky how-to pages now all state the posture consistently: the agent
never holds the token in a deployed terminal, the human's panel click is
the arming decision, and config surgery is never the fix.
Rendered settings.json now switches off the CLI's bundled
harness-configuration skills (update-config, keybindings-help,
fewer-permission-prompts) via skillOverrides: a deployed operator agent
must never edit its own permissions, env vars, hooks, or keybindings —
harness changes are admin work done through the profile and regen.

The setup-mode skill leaves the control-assistant preset's default
roster for the same reason: its setup_patch can modify config.yml and
.mcp.json. It remains in the artifact catalog for admin-facing profiles
to opt into. Preset hash pins re-pinned accordingly; already-deployed
projects will report staleness once, which is the intended signal.
Comment on lines +96 to +98
"This operation arms hardware motion and needs the bridge's launch token, "
"which this agent does not hold — in deployed control rooms the token stays "
"with the operator's BLUESKY queue panel, by design.",
Comment on lines +99 to +100
"Hand the action to the operator: arming is done from the queue panel by a "
"human. Never edit config.yml, .env, or settings to obtain a token.",
Comment on lines +101 to +102
"Only if this deployment has no token configured ANYWHERE (details say so) "
"does an operator need to set one — that is operator work, not yours.",
Comment on lines +106 to +107
"Stage the plan with set_draft and add it with queue_add first, then ask "
"for the start again.",
@thellert
thellert merged commit 21e825a into main Aug 12, 2026
49 checks passed
@thellert
thellert deleted the feature/bluesky-panel-confirmed-start branch August 12, 2026 14:07
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant