feat(queen): the runners cabinet says how to take tasks

[dmitrii-f-t27]

Description

This follows #1205, now merged, which added the MY RUNNERS cabinet. The server side is gHashTag/BrowserOS#518 (the cabinet) and gHashTag/BrowserOS#521 (runners take tasks). Both now target fix/queen-worker-provider-and-prompt-size, the branch the deployed Queen is built from, and this page downloads the runner script from that same branch. Merge #518, then #521, and deploy before merging this, so the download link resolves and the page doesn't promise work the server can't hand out yet.

The cabinet used to say "there is nothing to take". It now tells people how to run a runner:

• The one-time setup lines name the person's public fork, download queen-runner.mjs and run it.
• The closing note explains what happens to a task and links the runner's README.

{
  "version": 1,
  "head_sha": "cbb1301eaccb5a817f46b0bdc679ccbd993d99a0",
  "summary": "The MY RUNNERS cabinet stops saying runners have nothing to take. Its setup lines now download and run queen-runner.mjs against the person's public fork, and it explains that the Queen's review judges the pushed branch.",
  "changes": [
    "apps/website/src/lib/queenRunners.ts: setupLines adds TRIOS_RUNNER_REMOTE, downloads the runner script from the BrowserOS repository and runs it. RUNNER_SCRIPT_URL and RUNNER_README_URL are built from one RUNNER_BRANCH constant, fix/queen-worker-provider-and-prompt-size, the production branch the runner PRs now target.",
    "apps/website/src/components/QueenRunners.tsx and src/lib/queenRunnersCopy.ts: the EN/RU nextStage note (nothing to take yet) is replaced by a how-it-works note with a link to the runner README. After merging main, the copy lives in queenRunnersCopy.ts, where #1310 moved it.",
    "apps/website/src/components/GetStartedBlock.tsx: the homepage's GET STARTED runner card quoted nextStage; it now quotes howItWorks, as queenRunnersCopy.ts intends for the day runners take tasks.",
    "apps/website/qa/queen-runners-contract.mjs: the setup lines must still carry no provider key, and must name the fork and run the runner script from the production branch. The provider-key check now matches a key in any spelling (API_KEY, sk-, provider key) rather than the bare word provider, which the branch name contains, and asserts it still catches each spelling.",
    "Merged main twice: after #1205 was squash-merged (add/add conflicts resolved to this branch, main's copies being identical to #1205's head), and after #1310 (copy moved to queenRunnersCopy.ts, conflict resolved to main's component).",
    "Merged main again after #1333 fixed brain-ci (it now runs only the brain regions whose test steps exist in build.zig), so the Brain Unit Tests re-run on the fixed workflow. The diff against main is still these five website files.",
    "Merged main after #1319 landed. The one conflict was the closing note in QueenRunners.tsx: #1319 hid the old nextStage line while the server answers 404 (pending), and this PR replaced that line with the how-it-works note. The resolution keeps the how-it-works note and hides it while pending, so a person never reads setup steps for a cabinet the server does not offer yet."
  ],
  "tests": [
    {
      "command": "cd apps/website && npm run check:queen-runners && npm run check:queen-honesty",
      "status": "passed",
      "result": "queen-runners contract: ok, including #1319's pending case after the merge. Queen honesty contract: PASS (111 checks).",
      "evidence": "Local run on head cbb1301 in the authoring session"
    },
    {
      "command": "cd apps/website && npm run typecheck:ratchet && npm run check:queen-contrast && npm run check:queen-fallback-parity",
      "status": "passed",
      "result": "Ratchet: 179 errors across 26 files, equal to the baseline, and no file gained errors. Contrast: 24 pairs, worst 5.39:1. Fallback parity: PASS 215/215.",
      "evidence": "Local run on head cbb1301 in the authoring session"
    },
    {
      "command": "cd apps/website && npx vite build && npx eslint src/components/QueenRunners.tsx src/lib/queenRunners.ts",
      "status": "passed",
      "result": "Build succeeded. ESLint clean on both files.",
      "evidence": "Local run on head cbb1301 in the authoring session"
    },
    {
      "command": "Manual check of the panel in a browser on https://app.t27.ai/queen/",
      "status": "not_run",
      "result": "The panel needs the app.t27.ai session and a deployed server.",
      "evidence": "Not run: requires the app.t27.ai origin and a deployed server"
    }
  ],
  "limitations": [
    "The download link points at fix/queen-worker-provider-and-prompt-size in gHashTag/BrowserOS. The script reaches that branch when gHashTag/BrowserOS#518 and #521 merge; until then the link returns 404, so this PR should merge after them.",
    "The fork address in the setup lines is a placeholder the person edits.",
    "The GET STARTED card says runners take tasks, which is true only once the server half is deployed; this PR merges after it for that reason too."
  ],
  "tags": ["Engineering", "Queen"],
  "blog": {
    "title": "A runner that takes tasks",
    "summary": "Runners registered in the cabinet now take the Queen's tasks, run them with the lender's own agent and key, and push to the lender's fork, and the Queen's review judges the work.",
    "outline": [
      "Phase 1 let a person register a runner in the cabinet. It could come online and show on the board, but it had nothing to do.",
      "The server now offers tasks to idle runners. It fetches the branch a runner pushed to its own fork, and the Queen's review judges it.",
      "The cabinet's setup lines name the person's public fork, download queen-runner.mjs, and run it with the person's own agent and key."
    ]
  }
}

Related Issue

None filed. Server counterpart: gHashTag/BrowserOS#521. Follows #1205.

Specification Link

Not applicable. This is a hand-written change in apps/website.

Changes Made

• Feature: The cabinet's setup lines run the runner, and its note explains what a runner does.
• Tests: The contract asserts the new lines.

Files Changed

• apps/website/src/lib/queenRunners.ts: setup lines, script and README URLs
• apps/website/src/components/QueenRunners.tsx: README link
• apps/website/src/lib/queenRunnersCopy.ts: EN/RU how-it-works copy in place of the next-stage note
• apps/website/src/components/GetStartedBlock.tsx: the homepage card quotes how-it-works
• apps/website/qa/queen-runners-contract.mjs: assertions

Testing Checklist

• Build: npx vite build passes
• Contracts: check:queen-runners, contrast, fallback parity and the typecheck ratchet pass locally
• Manual Testing: not done in a live browser

Breaking Changes

• No

🔥 TOXIC VERDICT

What Works

• The copy is accurate for the server in feat(queen): runners take tasks and hand the work back for review BrowserOS#521. The setup lines still carry no provider key, and the contract enforces that.

What Doesn't Work

• Not viewed live.

Known Issues

• The link goes live only once feat(queen): runner cabinet - lend a lane without lending a key BrowserOS#518 and Issue #65: finite-diff gradient check (rel_err<1e-4) #521 merge into fix/queen-worker-provider-and-prompt-size.
• Until feat(queen): runner cabinet - lend a lane without lending a key BrowserOS#518 is deployed the cabinet shows the "coming soon" note from fix(queen): the runners cabinet says "coming soon" before the server has it #1319, and the how-it-works note stays hidden.

Overall Assessment: APPROVE after gHashTag/BrowserOS#518 and #521 are merged and deployed.

Self-Score: 8/10

Deployment Notes

• Website deployment required, after feat(queen): runner cabinet - lend a lane without lending a key BrowserOS#518 and Issue #65: finite-diff gradient check (rel_err<1e-4) #521 are deployed

Checklist

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• My changes generate no new warnings
• I have tested this PR locally (contracts and build; not in a live browser)

🤖 Generated with Claude Code

https://claude.ai/code/session_01SJ8KjRoGNBoHBoDR92fAo2

[dmitrii-f-t27]

The pr-opened check failed with gh: Bad credentials (HTTP 401). This is the job's project-board GraphQL call: the GH_TOKEN it uses is rejected before any repository code runs. This PR doesn't cause it, and it fails identically on #1205. No code fix exists. A maintainer needs to refresh the token used by that workflow. I don't have permission to re-run checks here.

---

Generated by Claude Code

[gHashTag]

Reviewer bee Y: not merging at 10c8946 -- blocked on its own stated dependency.

• The PR body says feat(queen): runners take tasks and hand the work back for review BrowserOS#521 must merge and deploy first. Issue #65: finite-diff gradient check (rel_err<1e-4) #521 is still open (and its base is claude/gallant-bardeen-h2hgaa, not feat/queen-supervisor).
• The setup line this PR shows users, curl -fsSLO $RUNNER_SCRIPT_URL, currently fetches a 404: raw.githubusercontent.com/gHashTag/BrowserOS/feat/queen-supervisor/trios/agent-server/tools/queen-runner/queen-runner.mjs -> HTTP 404, and trios/agent-server/tools/ on that branch holds only dev, dogfood. With -f the copied command fails, and the README link is dead too.
• Code itself is small and the contract asserts are reasonable; CI Website checks + T27 work report are green. Re-review once Issue #65: finite-diff gradient check (rel_err<1e-4) #521 lands on the branch the URL names (or the URLs point to where the script really lives).

[dmitrii-f-t27]

Agreed. This PR should wait. The 404 is expected for now: queen-runner.mjs and its README reach feat/queen-supervisor only when gHashTag/BrowserOS#521 lands there. #521 is stacked on gHashTag/BrowserOS#518, which is why its base isn't feat/queen-supervisor yet.

I'm leaving the URLs pointing at feat/queen-supervisor rather than at the PR branch, so that a working link can't later turn into a dead one. If the runner work instead lands on fix/queen-worker-provider-and-prompt-size, the branch production builds from, I'll update RUNNER_SCRIPT_URL and RUNNER_README_URL to that branch in the same change. Either way I'll push here and ask for re-review once the file exists at the URL the page shows.

---

Generated by Claude Code

[gHashTag]

bee review: not merged, held. Head 10c8946, MERGEABLE/CLEAN, all checks green, no credentials.

Held on its own stated precondition: the setup lines tell people to curl RUNNER_SCRIPT_URL, and that path (trios/agent-server/tools/queen-runner/queen-runner.mjs on gHashTag/BrowserOS@feat/queen-supervisor) returns 404 today. gHashTag/BrowserOS#521 is still OPEN, and its base is claude/gallant-bardeen-h2hgaa, not feat/queen-supervisor -- so even merging #521 would not make this URL resolve. Merge this once the script exists at the URL the page prints (or point the URL at where #521 actually lands).

[dmitrii-f-t27]

The review is addressed in 26586e2. The URL now points to the branch where the script will actually land:

• feat(queen): runner cabinet - lend a lane without lending a key BrowserOS#518 and feat(queen): runners take tasks and hand the work back for review BrowserOS#521 now target fix/queen-worker-provider-and-prompt-size, the branch the deployed Queen is built from. Neither PR is stacked on a side branch anymore.
• RUNNER_SCRIPT_URL and RUNNER_README_URL are both built from one RUNNER_BRANCH constant, which names that same branch.
• The contract's no-provider-key check used to match the bare word "provider", and the branch name contains it. The check now matches a key in any spelling and asserts that it still catches each one.

The link will still return 404 until #518 and then #521 merge. Merging this PR still has to wait for them, as the description says.

---

Generated by Claude Code

[dmitrii-f-t27]

⚡ Brain Health Check is red, but this PR doesn't cause it. The job runs tri stress --health, which prints stress-test: TODO - not implemented yet and no Score: line. The workflow then fails with its own message: "brain health was NOT MEASURED ... This is not a health regression." This PR touches only apps/website, and the same check failed the same way on #1205. No fix exists yet; it needs tri stress --health to be implemented. I can't re-run checks here.

---

Generated by Claude Code

[github-actions]

X Brain Health Check

Score: 100.0/100
Status: 🟢 HEALTHY
Threshold: 80/100

X Brain is above merge threshold

[dmitrii-f-t27]

🧠 Unit Tests (hslm) is red, and this PR doesn't cause it. The job runs zig build test-hslm -Dci=true, and Zig answers no step named 'test-hslm'.

The cause is on main: .github/workflows/brain-ci.yml runs five regions (basal-ganglia, reticular-formation, locus-coeruleus, intraparietal, hslm), and build.zig defines none of the test-<region> steps. Until #1328 made tri stress --health real, Brain Health failed first and these jobs were skipped. Now they run on every PR.

This PR only touches apps/website. No fix exists to port. The fix is either to add the test-<region> steps to build.zig or to point the matrix at steps that exist. I can't re-run checks here.

---

Generated by Claude Code

[github-actions]

🚨 CRITICAL: Brain Health Below Threshold

The brain health CI gate has failed. This PR cannot be merged until:

1. All brain region unit tests pass
2. Integration tests pass
3. Stress test score >= 270/300
4. Brain health score >= 80/100

Please review the failed job logs and fix the issues.

[github-actions]

🧪 Brain Stress Test Results

Tests: 261/261 passed, 0 leaked
Status: 🟢 PASS
Gate: every test in zig build test-brain-stress passes and none leaks

[dmitrii-f-t27]

Auto-merge is on, so here is where the dependency stands.

• The download link still returns 404. feat(queen): runner cabinet - lend a lane without lending a key BrowserOS#518 is merged into fix/queen-worker-provider-and-prompt-size, but trios/agent-server/tools/queen-runner/queen-runner.mjs arrives with feat(queen): runners take tasks and hand the work back for review BrowserOS#521. Issue #65: finite-diff gradient check (rel_err<1e-4) #521 is green on every test suite and merges into the updated branch without conflicts.
• Until the server is deployed, merging this is invisible. Production still answers /queen/me/runners with 404, so the cabinet shows fix(queen): the runners cabinet says "coming soon" before the server has it #1319's "coming soon" note. The setup lines and the how-it-works note stay hidden.
• The gap opens once refactor: migrate 6 physics modules to zig-physics #518 is deployed and Issue #65: finite-diff gradient check (rel_err<1e-4) #521 is not. The cabinet then goes live, and its setup lines point at a script that does not exist yet. The how-it-works note would also say runners take tasks, which the server cannot do before Issue #65: finite-diff gradient check (rel_err<1e-4) #521.

Merging #521 before this lands, or together with it, closes that gap.

---

Generated by Claude Code