Repository navigation
Closed
Labels
area/infraInfrastructure, deployment, and operationsInfrastructure, deployment, and operationseffort/mMedium: expected under 1 day of workMedium: expected under 1 day of workkind/featureNew feature or capability requestNew feature or capability requestmeta/enrichedIntake review done: acceptance criteria, links, and normalized labels addedIntake review done: acceptance criteria, links, and normalized labels addedpriority/highImportant and time-sensitiveImportant and time-sensitive
Description
Problem (found by pilot #1188, 2026-10-26)
There are two scheduling systems in the house and they don't know
about each other:
- The fleet's: Supabase
agent.tasksqueues + cron-driven lane
shifts / babysitter, with the lifecycle protocol (claims, parks,
terminal states, monitor reconciliation). - OpenChamber's own: per-project scheduled tasks
(/api/projects/:projectId/scheduled-tasks, with/runand loop
files) that fire sessions on their own schedule.
If both can start work on the same repo, the fleet gets a new class of
double-assignment the protocol can't see (an OpenChamber-scheduled
session and a queue worker fixing the same issue), and two places
claim to be the schedule of record.
Work
- Inventory what OpenChamber scheduled tasks exist today on the
laptop (which projects, what they run, whose work they do). - Decide the integration shape, one of: (a) OpenChamber scheduled
tasks become a producer that enqueues repo-task packets (the
Phase 3 pattern) and never starts work directly; (b) the fleet
treats OpenChamber scheduled tasks as an external holder in the
monitor's tracker (labelled, watched, never double-claimed);
(c) scheduled tasks are retired in favor of the queue. Recommend
with reasons; Drew decides ties. - Encode the decision in the lifecycle protocol doc so the monitor's
duties cover whichever surface remains.
Acceptance criteria
- An inventory of live OpenChamber scheduled tasks exists.
- A decision is recorded (issue comment + protocol doc update)
naming the single scheduling system of record. - The monitor's tracker shows OpenChamber-scheduled work in
whichever form the decision requires — no invisible holders.
Child of epic #1234. Filed by Muse (operator) 2026-10-26.
Metadata
Metadata
Assignees
Labels
area/infraInfrastructure, deployment, and operationsInfrastructure, deployment, and operationseffort/mMedium: expected under 1 day of workMedium: expected under 1 day of workkind/featureNew feature or capability requestNew feature or capability requestmeta/enrichedIntake review done: acceptance criteria, links, and normalized labels addedIntake review done: acceptance criteria, links, and normalized labels addedpriority/highImportant and time-sensitiveImportant and time-sensitive
Activity
developing-today commentedon Oct 27, 2026
CODE-397
37 remaining items
dezren39 commentedon Oct 30, 2026
🤖 Agent note · parked
dezren39 commentedon Oct 30, 2026
agent-note:v1 — parked, queue task 1650 (repo-worker-code, openchamber-scheduled-lane, 2026-10-30 23:39Z).
Not started. The core deliverable is a section in files/agent-lifecycle-protocol-2026-10-25.md in the keep-the-four-repos-healthy goal workspace, plus verification reads of the laptop project scheduled-task stores — both live outside this lane's reach (~/workspace/goals does not exist on the laptop; this lane must not write sandbox-workspace files). The GitHub-comment halves (#1273 closing comment, epic #1234 link) depend on the doc section existing first, so no partial was posted. Needs a shift with goal-workspace access: re-read the laptop project stores at write time (triage's empty-inventory finding is from 2026-10-28), land the producer-only section, then post the two links.
dezren39 commentedon Oct 31, 2026
🤖 Agent note · done
files/agent-lifecycle-protocol-2026-10-25.mdin the keep-the-four-repos-healthy goal workspace): the fleet queue is the single scheduling system of record for claiming work; OpenChamber scheduled tasks are a recognized external holder (option b as built) that may start sessions only for queue-claimed work (origin stampopenchamber-scheduled-lane) or work exclusively theirs; issue-layer claiming uses Drew's first-claim-comment-wins protocol. Per Drew's 2026-10-29 decision this SUPERSEDES the triage's producer-only option (a); option (c) rejected. §10 also extends the fleet monitor duties (§6): inventory the laptop project stores and list OpenChamber-scheduled lanes as external holders in the tracker — their held items already appear there as queue tasks, with the origin stamp as join key (babysitter log verifies origin-stamped claims in practice).~/.config/openchamber/projects/*.json, 2026-10-31): 3 enabled scheduled tasks, all "Queue lane (scheduled)" lanes from OpenCode scheduled tasks: migrate the Muse→OpenCode cron wrappers into OpenChamber scheduled tasks (waves, monitoring gates) #2174 — project /home/user: opencode lane (*/40 * * * *); project /home/user/git/code: code lane ×2 (*/40 * * * *,20,40 * * * *), all America/Chicago. No other OpenChamber scheduled tasks exist. No OpenChamber config was created/edited/deleted.