Skip to content

Babysitter live: interval rounds over all OpenCode sessions with verdicts, quota, and pool attribution #1338

Open

Description

@dezren39

Work (Drew, 2026-10-27)

Stand up the babysitter as a live scheduled job (openchamber- babysitter, every 20m), implementing #1185's design with #1192's
detector:

  • Every round: enumerate ALL sessions at the laptop OpenChamber
    location (and any future locations), bound or unbound, and give
    each a verdict: progressing / stalled / done-unreported / blocked
    / walled (402-class) / idle.
  • Stall rule (from Pilot: session stall taxonomy — observable signatures of stalled vs healthy long sessions #1192's census): suspect when ≥20 min since the
    session's last activity AND no live CI on its bound PR; confirm on
    a second suspect round or on expiry-equivalent silence. Nudge at
    most twice (message injection where the API shape is verified —
    verify by the session's next assistant message), then escalate to
    the fleet as a stuck-holder case.
  • Report per round only what changed: new stalls, nudges sent,
    harvests ready (done-unreported sessions whose PR merged or work
    completed → the owning queue task gets completed by its lane, the
    babysitter flags it), quota snapshot per pool in use, and which
    pool each active session is drawing on + whether that choice looks
    effective (progress per the session's own checkpoints).
  • Data out: append round observations to the babysitter log in the
    goal workspace (the pool-intelligence and meta-reviewer jobs read
    it); unbound sessions are observed, never driven.

Acceptance criteria

  • The job exists and has completed three rounds with per-session
    verdicts recorded.
  • One real (or synthetic) stall is detected inside two rounds
    of the rule's threshold.
  • Every report names each active session's pool; a session on a
    walled pool is flagged the round it happens.

Extends #1185; depends on openchamber#524 for the clean last-activity
field (rounds poll what's available until then). Child of the pool &
routing intelligence epic. Filed by Muse (operator) 2026-10-27.

Activity

  1. developing-today commented on Oct 27, 2026

    @developing-today
    Contributor
  2. added
    queue/queuedHas a queued task in the Supabase agent queue
    area/infraInfrastructure, deployment, and operations
    effort/mMedium: expected under 1 day of work
    meta/enrichedIntake review done: acceptance criteria, links, and normalized labels added
    on Oct 27, 2026
  3. added
    work/assignedQueue worker lifecycle state
    queue/claimedQueue worker lifecycle state
    and removed
    queue/queuedHas a queued task in the Supabase agent queue
    on Oct 31, 2026
  4. 26 remaining items

  5. developing-today commented on Nov 3, 2026

    @developing-today
    Contributor

    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 7230 (triage, queued, priority 50) 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

  6. added
    work/assignedQueue worker lifecycle state
    queue/claimedQueue worker lifecycle state
    and removed
    queue/queuedHas a queued task in the Supabase agent queue
    on Nov 3, 2026
  7. dezren39 commented on Nov 3, 2026

    @dezren39
    MemberAuthor

    🤖 Agent note · picked up

  8. dezren39 commented on Nov 3, 2026

    @dezren39
    MemberAuthor

    🤖 Agent note · escalated

    Triage findings — the babysitter was built, ran, and worked; it is currently switched off

    What exists (verified fresh this pass):

    • The job openchamber-babysitter exists (interval 20m, goal-owned) and ran from 2026-10-28 through 2026-10-30: 245 round sections in hidden_files/babysitter-log.md, per-session verdicts (progressing / stalled / done-unreported / blocked / walled) every round.
    • Its dependencies are all closed: issue OpenChamber babysitter v1: one worker, session rounds, quota + progress report (report-only) #1185 (design) CLOSED, issue Pilot: session stall taxonomy — observable signatures of stalled vs healthy long sessions #1192 (stall taxonomy) CLOSED, openchamber#524 (session-activity last-activity field) CLOSED.
    • Acceptance 1 (three rounds with verdicts): met many times over.
    • Acceptance 2 (a stall detected inside two rounds): met — e.g. 2026-10-30: suspects raised at 15:17 confirmed at 15:37; task 3943 went suspect → confirmed across consecutive rounds; confirmed stalls were escalated as stuck-holder cases per the rule.
    • Acceptance 3 (pool named per active session; walled pool flagged the round it happens): met in the rounds — every round carried a per-pool quota snapshot and named the pool active sessions were drawing on; walled pools (opencode-go monthly 100%, cline-pass monthly 100%, openrouter 100%, antigravity weekly 100%) were flagged round after round.
    • Nudges: none were ever sent — every confirmed stall had no live bound session to inject into, so the rule's escalation path was used instead. The message-injection half of the design remains unexercised, not disproven.

    The blocker: the job is disabled. Last successful run Fri 2026-10-30 17:12 CDT; the saved definition also reads enabled: false. Nothing I found this pass records who disabled it or why (the Oct 30 watchdog entries still show it healthy earlier that day), so I am not treating the disable as a considered retirement of the function — and I am not silently reversing it either, because re-enabling changes live fleet behavior.

    Decision for Drew — options:

    1. Re-enable as-is (20m). Restores the only per-session stall detection + harvest flagging layer the fleet has had; its rounds repeatedly caught real evaporated claims the queue lanes could not see. Cost: a 20-minute agent round, which was also a notable token consumer.
    2. Re-enable at a slower cadence (e.g. hourly). Keeps stall/harvest detection with ~1/3 the rounds; stall confirmation takes proportionally longer (two-round rule → up to ~2h).
    3. Retire it and close issue Babysitter live: interval rounds over all OpenCode sessions with verdicts, quota, and pool attribution #1338 as superseded. Only sound if another job now does per-session verdicts — the fleet monitor and watchdog reconcile queue/GitHub state and job health, but neither enumerates OpenChamber sessions or attributes pools per session, so retiring loses that function outright.

    Recommendation: option 1 or 2 — the acceptance criteria were met by the running system, and the stalls it caught (evaporated claims at max attempts with open PRs) are exactly the failure class the queue fleet still produces. If token cost was the reason for the disable, option 2 keeps the detection at a third of the price.

    Until that decision lands, issue #1338 stays open as user/escalated: the work is done and proven, the switch is Drew's.

  9. added
    user/escalatedQueue or user escalation state
    and removed
    queue/claimedQueue worker lifecycle state
    work/assignedQueue worker lifecycle state
    on Nov 3, 2026
  10. dezren39 commented on Nov 3, 2026

    @dezren39
    MemberAuthor

    🤖 Agent note · escalated (supplement to the triage above)

    • Agent: queue worker (repo-worker-code), lane code-d
    • Session / ID: task 7230

    Correction and completion of the picture, from the fleet backlog (lane E triage record, 2026-10-31) plus a fresh check just now:

    The decision for Drew is unchanged in shape but narrower: re-enable the conductor (the current home of the babysitter function, per the #2153 merge) — or retire both jobs and close this issue as superseded. My recommendation stands with that amendment: re-enable the conductor, at 20m or hourly; the stall/harvest detection it carries has no other live replacement.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

area/infraInfrastructure, deployment, and operationseffort/mMedium: expected under 1 day of workkind/featureNew feature or capability requestmeta/enrichedIntake review done: acceptance criteria, links, and normalized labels addedpriority/highImportant and time-sensitivesource/creatorFiled by the new-issue-creator jobtask/triageQueue packet kind: verify, reproduce, and route this itemuser/escalatedQueue or user escalation state

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions