Repository navigation
Dispatcher v1 live: scheduled launches of OpenCode/OpenChamber sessions for queued issues #1337
Description
Work (Drew, 2026-10-27)
Stand up the dispatcher as a live scheduled job (openchamber- dispatcher, every 30m), implementing #1187's design:
- Pull dispatchable work from the fleet queues (issues whose tasks
are sized/routed for an OpenCode session: effort/m or /l code work
first), pick the pool by the routing tiers (Workhorse default,
Frontier only on evidence or for design, Fast for mechanical),
subject to admission control: free session slots at the target
location AND the POOL MAP measurement gate (quota read ≤60 min
old; pool ≥85% of window → finishing work only). - Launch the session via the OpenChamber API at the laptop location
(paired client per Babysitter access: enroll a paired OpenChamber client for sandbox → laptop, and document the credential home #1271; until that lands, runs record the reach
failure as data and prepare the dispatch packet instead — never a
fake launch). - Bind the session to its queue task (session id in task progress +
issue comment) so the babysitter can shepherd it; hand-backs when
saturated are a parked task with reasonexecutor-saturatedplus
an issue note — never a silent backlog. - Verify every launch by assistant-message CONTENT in the session,
not by API acceptance.
Acceptance criteria
- The job exists and runs; its first three dispatches (or
recorded reach failures, if Babysitter access: enroll a paired OpenChamber client for sandbox → laptop, and document the credential home #1271 still blocks) are visible in
its reports with session bindings. - Saturation produces a park + issue note, demonstrated once
(live or synthetic). - No session is ever launched against a pool failing the
measurement gate; the gate read is quoted in the run report.
Extends #1187. Child of the pool & routing intelligence epic. Filed
by Muse (operator) 2026-10-27.
Metadata
Metadata
Assignees
Labels
Infrastructure, deployment, and operationsMedium: expected under 1 day of workNew feature or capability requestIntake review done: acceptance criteria, links, and normalized labels addedImportant and time-sensitiveQueue or user escalation stateFiled by the new-issue-creator jobQueue or user escalation stateQueue packet kind: verify, reproduce, and route this item
Activity
developing-today commentedon Oct 27, 2026
CODE-441
dezren39 commentedon Oct 27, 2026
Correction (Drew, 2026-10-27, after the first dispatch run): the measurement gate as first written was GLOBAL — Meta unreadable + a rate-limited Claude read blocked all dispatch despite free slots and fresh reads for the other pools. That behavior was wrong and is fixed in the dispatcher instruction: (1) the gate is now PER POOL — a pool with a fresh ≤60m picture is open; a failed/stale read closes only that pool, named in the report; global stop only if session enumeration fails or no pool is verifiable; a partially-blocked run still does its full other work. (2) Laptop concurrency cap raised 4 → 12 (a ceiling, not a target; admission still gates on pool headroom). (3) The sandbox OpenCode server is removed as a data source everywhere (dispatcher, babysitter, steward): it is off by Drew's choice; Meta is read from the laptop side. The same per-pool scoping was applied to the steward's decision rule.
dezren39 commentedon Oct 28, 2026
Reprioritization (operator, 2026-10-28, Drew-confirmed): the targeted claim/bind verb owed under this issue is now the fleet's top structural priority, ahead of new feature work. Its queue task 1321 is raised to priority 90 (sibling task 1648 for #1272 to 70).
Why now — the binding gap's cost, measured today: dispatcher-dispatched tasks stay
queued, so lanes claim the same work sessions are already doing. On 2026-10-28 alone this produced five duplicate PRs (openchamber #707/#712 and #708/#714, opencode #748/#751 and #750/#753), each contained by hand before merge, plus live double-work on opencode #652, and a documented claim race on 2026-10-27 (lane claimed task 1511 thirty seconds after the dispatch binding comment). Every dispatch cycle pays this tax in CI runs, lane time, and operator dedupe.Deliverable: an atomic claim/bind — when the dispatcher launches a session for a task, the task leaves
queuedin the same write (claimed/bound to the session identity), so no lane can pick it up as unassigned; the babysitter/monitor reconciliation then treats the session as the holder of record. Acceptance: a dispatch and a simultaneous lane claim cannot both take the same task; the 2026-10-27 race replays as a single ownership.dezren39 commentedon Oct 28, 2026
Binding scope addition (Drew, 2026-10-28): the claim/bind verb must also work for sessions using just GitHub. Not every session is dispatcher-launched or queue-claimed — a session started by hand or by another tool works from GitHub alone and never touches the queue, so the bind needs a GitHub-native form and a catcher.
Requirements added to this issue's deliverable:
queue/claimed+work/assigned+status/in-progress(orwork/self-assigned), anagent-note:v1naming the holder, a fleet-convention branch naming the issue, and a PR that references the issue.Acceptance addition: simulate an out-of-band session (branch + PR from a bare gh workflow, no queue contact) — the monitor's next run must bind it and name it as out-of-band in its summary.
dezren39 commentedon Oct 28, 2026
First-run evidence for the claim/bind deliverable (fleet monitor Duty 1B, 2026-10-28 16:19 CDT run): the monitor verified 11 PR-to-queue bindings across code and opencode - including all six long-stuck code fix tasks (1387/#1402/PR #1777, 1434/#1430/#1774, 1873/#1624/#1775, 1924/#1704/#1776, 1848/#1607/#1786, 1856/#1613/#1798) and one genuinely out-of-band pickup (code #1406, PR #1410, a Jules session that never labelled or noted anything). It posted binding notes for all of them.
What it could NOT do: move any of those tasks out of queued. repo-queue.py claim takes the next task in a queue by priority - there is no targeted claim or park by task id, and park requires the task to already be claimed by the calling worker. So the six tasks remain mechanically queued (attempts 0) with note-level bindings only; a lane claiming one fresh would have to notice the note during revalidation to avoid rework.
Requirement this adds to the deliverable: a TARGETED bind - claim/park a named task id in one operation (the monitor and the operator both need it; the dispatch race in this issue's body is the other half). Acceptance: given a queued task id and a verified PR, the monitor takes that exact task to parked with stage pr_opened and the PR linked, without claiming any other task, and a simultaneous lane claim on the same task loses.
dezren39 commentedon Oct 31, 2026
Status — owner order 2026-10-28 (priority 90 reprioritization), stalled unbuilt, verified live 2026-10-31.
Drew's 2026-10-28 reprioritization put this issue at priority 90, with the targeted claim/bind verb requirement + acceptance pinned in comment 6481657040 on this issue. The Oct-28 left-on-the-ground remediation verified the queue row by direct read, 2026-10-31:
queued, priority 90 — the packet does carry Drew's reprioritized priority — attempts 0/3,not_beforenull, no lease. Live and claimable; no repair was needed.Re-surfaced here so the triage routes the claim/bind verb implementation out of this issue rather than the workaround becoming permanent. Queue signal refreshed as part of the remediation.
27 remaining items
dezren39 commentedon Nov 3, 2026
agent-note:v1
state: triaged (coverage pass)
Coverage pass 2026-11-03: reviewed in the fleet-wide per-issue pass (drift / overlap / already-handled / stale / blockers / ordering). Verdict: still live; queued in repo-health-code-pilot as triage at priority 50 (priority/high). Stale queue/claimed label removed — it had no live task behind it. If this is already handled at current main, the triage closes it with evidence; if it needs splitting, the triage files the split.
Found via: coverage pass 2026-11-03
dezren39 commentedon Nov 4, 2026
agent-note:v1
event: picked_up
task: 7561 (triage, repo-health-code-pilot; repo-worker-code; OpenChamber scheduled lane 335a5d1f-bfc1-4831-99ea-850c8939a727)
state: Resumed from the prior handed_off checkpoint. Fresh view shows #1337 OPEN with claim labels already present and no hard-stop label; #3026 is CLOSED. The issue history says the old dispatcher was superseded, while targeted claim/bind remained as task 6669; no code or PR work started here.
next: verify #3026’s closure and task 6669’s blocker from current issue evidence, then record whether #1337 stays open for the targeted-bind remainder.
dezren39 commentedon Nov 4, 2026
agent-note:v1
event: triaged
task: 7561 (triage, repo-health-code-pilot; repo-worker-code; OpenChamber scheduled lane 335a5d1f-bfc1-4831-99ea-850c8939a727)
verdict: The original openchamber-dispatcher launch design is superseded by the current laptop OpenChamber claimant/cutover. Fresh GitHub state: #3026 is CLOSED; its record documents the claimant launch/bind hardening, 11/11 bound launches in the post-hardening window, stand-down, and post-cutover launches. Relevant implementation PRs #3032, #3262, #4461, #4469, #4490, and #4493 are MERGED. Do not re-enable the retired dispatcher path.
remaining scope: #1337 should stay OPEN, narrowed to the targeted claim/bind-by-task-id behavior. Existing task 6669’s note records it as blocked
packet_defect: its authoritative helper/RPC source is in developing-today/hatch, while the claimed code packet excluded that repo and named an absent migration path. This remains unimplemented; the current PR search found no competing fix PR. No code or PR work was done by task 7561.resume: repair the packet/source-repo scope and migration/test-harness references for the already-tracked task 6669, then implement and test the named atomic claim/park behavior. No new duplicate packet filed.
dezren39 commentedon Nov 4, 2026
agent-note:v1
event: done (triaged)
task: 7561 (triage, repo-health-code-pilot; repo-worker-code; OpenChamber scheduled lane 335a5d1f-bfc1-4831-99ea-850c8939a727)
state: Queue task completed as triaged; #1337 stays OPEN for the targeted by-id claim/bind remainder. The old dispatcher request is superseded by the #3026 claimant cutover.
labels: removed work/assigned, queue/claimed, status/in-progress; set queue/blocked and status/blocked for the already-recorded packet_defect on task 6669. Classification/priority labels remain.
resume: re-scope task 6669 to the authoritative developing-today/hatch helper/RPC repository and its migration/test harness; no duplicate packet was filed.