Repository navigation
feat(keeper): binding-aware supervision for queue-spawned OpenCode sessions (OpenCode-half step 3) #1656
Description
Part of the OpenCode-half redesign (design: files/opencode-half-redesign-2026-10-28.md in the keep-the-four-repos-healthy goal workspace; tracking: #1425). Drew's order, 2026-10-28: at least half of fleet tasks execute via OpenCode sessions.
Scope
Make keeper (jules-review) and babysitter (openchamber-babysitter) supervision explicitly binding-aware for queue-spawned OpenCode sessions:
- Sessions launched by queue shifts carry a binding (session id ↔ task id ↔ issue) recorded in the task's progress at launch. The babysitter's rounds already enumerate every session at the laptop location; add the queue binding to its per-session record so queue sessions are distinguishable from dispatcher-launched and interactive ones.
- Keeper retry/failover rules apply to queue sessions (error-stopped: one retry, then model failover per the registry ladder) — but question-answering does NOT: a queue session waiting on a question is reported to its owning shift's lane, never answered by the keeper (the shift owns the packet context and the claim).
- Intervention caps: queue-session interventions are counted separately in the keeper state file so a burst of queue-session failures cannot silently consume the whole run's intervention budget; overflow is reported, not dropped.
Acceptance criteria
- Babysitter round output identifies queue-spawned sessions with their task/issue binding for 100% of sessions launched under the executor mode.
- An error-stopped queue session receives the standard retry/failover treatment and the intervention is logged with its binding.
- A queue session waiting on a question is never answered by the keeper; it appears in the keeper report as owned-by-shift.
- Keeper state separates queue-session interventions from Jules/OpenChamber ones.
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 addedFollow-up spun out of earlier workOrdinary priority (the default)Filed directly by a humanQueue packet kind: verify, reproduce, and route this item
Activity
developing-today commentedon Oct 28, 2026
CODE-670
dezren39 commentedon Oct 28, 2026
Intake review
## Acceptance criteriasection, so no body edit was made. The binding it relies on (session id ↔ task id ↔ issue, recorded in task progress at launch) is produced by feat(fleet): shift executor mode — launch + shepherd OpenCode sessions for opencode-lane tasks (OpenCode-half step 2) #1655's executor mode — sequence after that.priority/normal,effort/m,source/human,status/needs-triage,area/infra,meta/enriched.dezren39 commentedon Oct 31, 2026
Status — owner order 2026-10-28, stalled, re-surfaced 2026-10-31 (supersession check vs #2132).
Verdict of the owed supersession check, 2026-10-31:
NOT superseded by #2132 — partial overlap on one surface only. #2132 / its implementation #2153 merge the OpenChamber dispatcher + babysitter into the session conductor, so the babysitter-facing half of this step (per-session records on supervised sessions) will land in the conductor after cutover, not in the retiring babysitter job. Everything else in this step is outside #2132/#2153's scope and still owed:
jules-review) retry/failover rules applied to queue sessions, with the explicit rule that a queue session's questions are never answered by the keeper (the owning shift answers them);Queue state, verified by direct read 2026-10-31: live triage task 2619 (repo-health-code-pilot, queued, priority 50, attempts 0/3). No duplicate packet enqueued. Triage note: read #2153's current state first and aim the babysitter-facing piece at the conductor.
dezren39 commentedon Nov 1, 2026
agent-note:v1 — holder: repo-worker-code (OpenChamber scheduled lane), since 2026-11-01. Picked up queue task 2619 for triage; validating the live issue and current main before routing a scoped follow-up or closing with evidence.
15 remaining items
dezren39 commentedon Nov 3, 2026
🤖 Agent note · triaged (re-derived scope; verdict: still owed, split across two owners)
developing-today/code. It does not — only aggregator feed representations ofjules-reviewexist here (pm-stack/aggregator/src/sources/jules.ts,model.ts). The keeper/babysitter runtime is not in this repo, so a code-repo packet could never close it. This verdict replaces that premise instead of repeating thepacket_defectblock.What is already done (verified on current main, prerequisites #1654 and #1655 both CLOSED):
pm-stack/opencode-claimant(README "The launch binding is one atomic helper call", migration 0021,repo-queue.py bind) writessession_id↔ task id ↔ issue into the task ledger +progress.session_idat launch. AC-1's producer half is therefore delivered.What is still owed, and to whom:
GET /api/session-activityin the OpenChamber fork exposes exactly five per-session keys —type,lastActivityAt,status,model,toolInFlight(packages/web/server/lib/opencode/DOCUMENTATION.md, contract v1) — with no queue/task/issue binding. The babysitter (an external poller of that contract) therefore cannot identify a queue-spawned session at all. Filed the correctly-scoped issue observability: expose queue task/issue binding on session-activity entries developing-today-forks/openchamber#1473 ("expose queue task/issue binding on session-activity entries", additive within v1, conformance fixture + docs) and enqueued it as task 8495 onrepo-health-openchamber-pilot.jules-review/openchamber-babysitterruntime, which is outside all four fleet repos — and the 2026-10-31 supersession check already established that the babysitter-facing half moves into the session conductor (Design: session conductor — merge OpenChamber dispatcher + babysitter into one job (implements #2021 as the merged job) #2132, still OPEN design) after cutover. Implementing it in the retiring babysitter now would be throwaway work, so no packet was enqueued for it.AC status: AC-1 producer done / consumer in openchamber#1473; AC-2 and AC-3 and AC-4 remain, sequenced after #2132. This issue stays open as the umbrella for step 3; no duplicate code task was created.
Expectation: when #2132 settles, its conductor work absorbs AC-2/AC-3/AC-4 and the #1473 binding key satisfies AC-1's consumer half. Re-triage this issue against the conductor implementation rather than against this repo.
developing-today commentedon Nov 3, 2026
agent-note:v1
state: reviewed (coverage loop-back)
Coverage pass 2026-11-03, loop-back review: this issue was re-reviewed (drift / overlap / already-handled / stale / blockers / ordering) so every open issue in the four repos is reviewed and in the system. Verdict: still live; in the system as task 8602 (triage, queued, priority 40) in repo-health-code-pilot. Labels audited and synced. If it is already handled at current main, its triage closes it with evidence; if oversized, the triage files the split; blockers belong on this issue.
Found via: coverage loop-back 2026-11-03
dezren39 commentedon Nov 3, 2026
agent-note:v1 — holder: repo-worker-code (OpenChamber scheduled lane 02cafe76-eafd-4d0b-aaa6-2b7a737d68dc), since 2026-11-03T22:01:00Z. Picked up queue task 8602 for triage; revalidating issue #1656 and linked implementation/follow-up artifacts against current main before routing or closing.
dezren39 commentedon Nov 3, 2026
Loop-back triage — still live, partially delivered (task 8602)
Verified against current code
mainate425b6af52c35067a452c0c4526fef47f00c7f01on 2026-11-03. Issue #1656 is OPEN; no open PR is linked to it. Keep this issue open.What is delivered
pm-stack/opencode-claimantbinds the session id in the task ledger and writesprogress.session_id/launched_by(migration 0021).1174a7921a5bfa23bed86d45d0414d8f929acf04), which adds thequeuefield to session-activity entries.What remains
queue: null. The acceptance requires identifying 100% of queue-launched sessions, so the consumer hookup remains required. The OpenChamber PR/issue did not include that integration; its completion note points this remainder back here.~/hatch-personal/workspace/goals/keep-the-four-repos-healthy/hidden_files/openchamber-conductor-instruction.md). It has generic error recovery and waiting-session handling, but no queue-binding-specific retry/failover log, separate queue-intervention budget with overflow reporting, or explicit owned-by-shift rule. The old babysitter was superseded by the conductor cutover tracked in Design: session conductor — merge OpenChamber dispatcher + babysitter into one job (implements #2021 as the merged job) #2132/Implement the session conductor: merge openchamber-dispatcher + openchamber-babysitter into openchamber-conductor #2153.Ordered next steps
The remaining implementation spans OpenChamber and the external goal-workspace supervisor, not
developing-today/codealone. No code PR or duplicate follow-up task was created by this triage; the issue remains the tracking item until the owning implementation surface is routed.agent-note:v1 — holder: repo-worker-code; state: triaged; task: 8602; lane: 02cafe76-eafd-4d0b-aaa6-2b7a737d68dc. Verdict: still live; AC1 consumer hookup plus AC2–4 remain, with the AC3 ownership rule to reconcile before implementation.