Repository navigation
OpenChamber 'Queue lane (scheduled) - code' tasks still prescribe the removed repo-queue.py #5422
Description
Problem
Twelve enabled OpenChamber scheduled tasks named "Queue lane (scheduled) - code" on the laptop still prescribe ~/hatch/tools/repo-queue.py — the legacy Python tool removed in the binary-direct migration (code#5362, 2026-11-04). Each task's stored prompt references repo-queue.py 12 times.
Evidence (2026-11-04, laptop OpenChamber store ~/.config/openchamber/projects/path_L2hvbWUvdXNlci9naXQvY29kZQ.json): task ids 8ac61616, 9aca43b4, c29174f1, 262eb403, 335a5d1f, 7b47536b, 1a180ae5, 02cafe76, bf419306, ec118cad, c8b9355e, aea12c82 — all enabled, each with 12 repo-queue.py references.
This is the same missed-consumer class that broke the opencode-claimant (code#5414, fixed): the migration swept the sandbox fleet tree but not consumers defined in the code repo / installed into OpenChamber.
Impact
Unknown until checked: if these tasks run queue verbs (claim/checkpoint/complete) through the missing file, their fires fail closed the way the claimant's did. If they are a superseded lane installation (the sandbox cron lanes A-Z are the fleet's active lane system), they should be retired rather than repaired.
Acceptance
- Identify what these 12 tasks do and whether they are still a live execution path.
- If live: migrate their prompts to the
repo-queuebinary (direct-broker transport per code#5414) at their definition source and reinstall; verify a fire performs its queue verbs. - If superseded: disable/remove them and note the retirement here.
Acceptance criteria
- already stated in the issue body: the 12 OpenChamber scheduled tasks are identified as live or superseded, and either migrated to the repo-queue binary with a verified fire or retired with a note here.
- No regression: existing tests/checks for the touched area remain green, and the change lands via PR referencing this issue.
- Evidence (PR link, test/CI output, or verification note) is posted on this issue before it is closed.
Activity
developing-today commentedon Nov 4, 2026
CODE-1316
dezren39 commentedon Nov 4, 2026
🤖 Agent note · triage complete
~/.config/openchamber/projects/path_L2hvbWUvdXNlci9naXQvY29kZQ.jsonholds 12 enabled "Queue lane (scheduled) - code" tasks (ids 8ac61616, 9aca43b4, c29174f1, 262eb403, 335a5d1f, 7b47536b, 1a180ae5, 02cafe76, bf419306, ec118cad, c8b9355e, aea12c82; cron*/40, America/Chicago), each prompt with exactly 12repo-queue.pyreferences prescribingpython3 ~/hatch/tools/repo-queue.py. That file does not exist on the laptop and norepo-queuebinary is on the laptop PATH or in~/hatch/tools— the code#5362 migration never reached this consumer (same class as code#5414). Not superseded: the prompts state they run ADDITIVELY alongside the Muse cron lanes, and the lanes are registered indoc/fleet-schedule-registry.md. They are firing — lastRunAt 2026-11-04T12:00Z (9aca43b4 12:20Z), nextRunAt 12:40Z — but every fire endslastStatus=error,lastError='fetch failed'(~10s), as does the claimant task f1b4a33b in the same store, so there is also a current OpenChamber scheduled-launch failure to diagnose; even with launches fixed, the lanes would fail at their first queue verb against the missing helper.repo-queuebinary (direct-broker transport per code#5414), diagnoses thefetch failedlaunch error, and verifies one lane fire end-to-end. Issue OpenChamber 'Queue lane (scheduled) - code' tasks still prescribe the removed repo-queue.py #5422 stays open for that fix.dezren39 commentedon Nov 4, 2026
Intake review
🤖 Agent note · state: filed
Related: none identified in this bounded pass.
Risks: Low for the intake pass itself; implementation risk lives in the issue body.
Suggested approach: Triage through the queue in dependency order, verifying each step's acceptance evidence before closing.
dezren39 commentedon Nov 4, 2026
Fixed and verified 2026-11-04.
Scope was larger than filed: 15 OpenChamber scheduled "Queue lane" tasks referenced the removed helper — 12 "Queue lane (scheduled) - code" tasks in the code project store (
~/.config/openchamber/projects/path_L2hvbWUvdXNlci9naXQvY29kZQ.json) plus the opencode/openchamber/nix lane tasks in the user project store (path_L2hvbWUvdXNlcg.json). Each prompt carried 12 references: the helper-definition line, the Step-0healthgate, a doc mention, and barerepo-queue.py <verb>invocations — every fire since the binary-direct migration (#5362) died at the gate.Repair (on the laptop, both store files; backups saved as
<store>.bak-20261104-5422):python3 ~/hatch/tools/repo-queue.py→repo-queue~/tools/repo-queue.py→repo-queuerepo-queue.py→repo-queuerepo-queueresolves via~/.local/bin/repo-queuewith the direct queue-broker config — the same path claimant sessions use.Two structural notes:
doc/fleet-schedule-registry.md, installed 2026-11-03). Future migrations that rename/remove fleet CLIs must grep the OpenChamber stores too.openchamber.servicewas restarted (done 13:26Z, came up clean, session API 200). The 13:20Z fire in between still ran the old cached prompt and failed at the gate, as expected.Verification — the 13:40Z fires: three "Queue lane (scheduled) - code" sessions inspected directly. All invoke the bare
repo-queuebinary (repo-queue health,repo-queue claim,checkpoint,park) — norepo-queue.pyreference, no missing-helper failure. One session worked task 8500 (#2306) claim → checkpoint → park end-to-end; another exited cleanly on a null claim. The follow-up task 9485 is discharged by this fix.