Skip to content

Implement lane handoff snapshots for queue shifts (Part 1 of #2140; supervision mode gated on conductor + binding) #2158

Open

Description

@dezren39

Implementation follow-on from the #2140 triage (queue task 3169, 2026-10-29). Parent design: #2140 (snapshot schema + supervision gating recorded there); fleet epic: #2055; conductor: #2153.

Two parts, independently landable — do Part 1 now; Part 2 is gated and must not be half-started.

Part 1 — per-lane handoff snapshots (no gate).

  1. Add a snapshot step to every queue-lane shift body (all repo-queue-worker-shift* jobs, all four pilot queues): at exit, after the signal refresh, the lane writes hidden_files/lane-handoff-<queue>-<lane>.json with the schema from Shift batching, creator-style: lane handoff snapshots + supervision mode for queue lanes #2140 (generated_at, queue health counts, worked list with terminal states + PR links, in-flight claims with PR/CI pointers, infra notes with first-seen times, next-task leads). Overwrite in place; one file per lane, no history accumulation.
  2. Add the read step: a shift reads its own lane's snapshot after the Step 0 gate, treats every entry older than one cadence or contradicted by a fresh check as a lead only, and re-verifies consequential facts (claims, CI, labels) exactly as today — the snapshot replaces search, never verification.
  3. Measure: daily token check-in reports per-lane input/run for the two weeks after landing vs the 6–13M check-in Bump build/buck/preludes/buck2-prelude from 3a02ea3 to 370cd4d #5 range; success = median shift input/run down with tasks/shift held or rising.

Part 2 — supervision mode (GATED, do not start until both hold).
Gate: (a) the session conductor (#2153) is cut over, and (b) session↔task binding is recorded on queue tasks (a claimed task names its OpenCode session id in progress). When both hold, file the activation as a fresh follow-on from #2140: lanes batch-supervise 15–20 dispatched sessions per shift (checkpoints, stall nudges via the conductor's ladder, hand-backs) instead of executing tasks directly, and only then evaluate the 40m → 2h cadence change — a rate change, which needs Drew's explicit word even then, with before/after tokens-per-completed-task from the daily check-in as the evidence pack.

Acceptance:

Activity

  1. developing-today commented on Oct 29, 2026

    @developing-today
    Contributor
  2. dezren39 commented on Oct 30, 2026

    @dezren39
    MemberAuthor

    🤖 Agent note · picked up

  3. dezren39 commented on Oct 30, 2026

    @dezren39
    MemberAuthor

    Triage verdict — scope CONFIRMED and narrowed: the edit surface is 2 instruction files, not 10 job bodies

    Queue task 3183 (triage, repo-worker-code, OpenChamber scheduled lane), 2026-10-30T04:5xZ. Read-only: no instruction file was edited by this triage.

    Live lane-shift scope re-verified

    Ten lane shift jobs exist in ~/hatch-personal/workspace/goals/keep-the-four-repos-healthy/crons/minutely/, all enabled: true, all 40m, all timeout_secs: 5400, all delivering to chat a15e5512-51ce-49c1-ad0f-46beaea69b04:

    Queue Jobs Instruction source
    repo-health-code-pilot repo-queue-worker-shift, -b, -c, -d hidden_files/repo-queue-worker-instruction.md (shared by all four)
    repo-health-opencode-pilot repo-queue-worker-shift-opencode, -opencode-b hidden_files/lane-shift-instruction.md (shared)
    repo-health-openchamber-pilot repo-queue-worker-shift-openchamber, -openchamber-b hidden_files/lane-shift-instruction.md (shared)
    repo-health-nix-pilot repo-queue-worker-shift-nix, -nix-b hidden_files/lane-shift-instruction.md (shared)

    Scope narrowing (the main finding): #2158 says "add a snapshot step to every queue-lane shift body". The bodies do not carry the protocol — they carry the gate, the bundle budget and the delivery line, and delegate to one of two shared instruction files. So Part 1 is two instruction edits (code: §8; parameterized: §3), covering all ten lanes at once, plus at most a one-line pointer per body. That makes Part 1 smaller and less risky than the issue's wording implies; it also means a half-done edit would hit six lanes at once, so the two files must land together.

    Three concrete gaps the implementation must close (found in live files, not in the issue)

    1. Lane identity is missing where the filename needs it. The snapshot path is lane-handoff-<queue>-<lane>.json, but only the six parameterized bodies pass LANE = A|B in their PARAMETERS line. The four code bodies name the lane only in prose ("You are LANE A…") and in their lock path (repo-queue-code-worker-a.lock); the shared code instruction's §8 still says rm -f ~/hooks/state/repo-queue-code-worker.lock — no lane letter, stale against all four bodies. Without a fix, the four code lanes either collide on one filename or write …-undefined.json. Fix: give the code bodies an explicit PARAMETERS: … LANE = X (matching the other six) and parameterise §8's lock path; derive the snapshot lane from that same value.
    2. The write step needs a defined trigger and order. §8 already orders signal → lock release; the snapshot goes between them (after the signal refresh, before rm). Define the trigger explicitly: a shift that gates out at Step 0 writes nothing (nothing changed, and a stale-looking empty snapshot is worse than none); a shift that claimed at least one task, parked/blocked one, or learned an infra fact writes/overwrites. Otherwise a gated-out shift will overwrite a good snapshot with an empty one and the next shift loses exactly the state this feature exists to carry.
    3. Acceptance 2 is currently unobservable. "One evidenced handoff: a shift starts from the previous shift's snapshot and its report names what the snapshot saved vs re-verified" needs a slot in the delivery line of both instruction files; today both delivery rules are fixed text ("one compact line per task…"). Add one required sentence to the report template — otherwise the evidence never appears and the acceptance cannot be checked.

    Notes for the implementer

    Routing

    Implementation packet enqueued on repo-health-code-pilot for this issue, kind small_fix, flagged live-fleet-change, carrying the two-file edit surface, the three gaps above, and the existing four acceptance criteria. Dedupe key repo-health:v1:fix:developing-today/code:issue:2158.

  4. 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 30, 2026
  5. dezren39 commented on Oct 30, 2026

    @dezren39
    MemberAuthor

    🤖 Agent note · parked

    • Agent: queue worker (repo-worker-code), lane B shift
    • Session / ID: queue task 3812
    • Found via: queue claim
    • Task: Part 1 implemented; parked for the evidence acceptances. Done this shift: (1) hidden_files/repo-queue-worker-instruction.md §8 — snapshot write step added between signal refresh and lock removal (trigger: claimed/parked/blocked ≥1 task or learned an infra fact; a Step-0 gate-out writes nothing), snapshot read step + the required report sentence (what the snapshot saved vs re-verified), the Shift batching, creator-style: lane handoff snapshots + supervision mode for queue lanes #2140 schema inlined, and the stale lane-less lock path repo-queue-code-worker.lock fixed to repo-queue-code-worker-<lane>.lock with the lane derived from the lock file the shift's Step 0 named (this closes the lane-identity gap for the four code lanes without editing their bodies — their Step 0 already names the lane's lock). (2) hidden_files/lane-shift-instruction.md — snapshot read added at §0 step 4, snapshot write + report sentence added at §3, covering the six parameterized lanes. Both files verified by grep after editing. (3) Part 2 gate state recorded on Shift batching, creator-style: lane handoff snapshots + supervision mode for queue lanes #2140: NOT satisfied on either count (dispatcher + babysitter both still enabled, cutover = task 3806; no session↔task binding in queue progress). No supervision mode, no cadence change. This shift also writes Lane B's first snapshot at exit, per the new §8.
    • Expectation: resume = (a) verify the next Lane B shift's report carries the evidenced-handoff sentence against this shift's snapshot (acceptance 2), and (b) after ~2026-11-13, post the two-week per-lane input/run comparison on Shift batching, creator-style: lane handoff snapshots + supervision mode for queue lanes #2140 (acceptance 3) and complete.
    • Links: Shift batching, creator-style: lane handoff snapshots + supervision mode for queue lanes #2140 (gate state recorded there) · triage verdict by task 3183 on this issue
  6. added
    queue/parkedQueue task is parked (waiting on CI, time, or an event)
    status/parkedDeliberately paused with a recorded resume condition
    queue/claimedQueue worker lifecycle state
    and removed
    queue/claimedQueue worker lifecycle state
    status/parkedDeliberately paused with a recorded resume condition
    queue/parkedQueue task is parked (waiting on CI, time, or an event)
    on Oct 30, 2026
  7. dezren39 commented on Oct 31, 2026

    @dezren39
    MemberAuthor

    🤖 Agent note · picked up (resume)

  8. added
    queue/parkedQueue task is parked (waiting on CI, time, or an event)
    status/parkedDeliberately paused with a recorded resume condition
    and removed
    queue/claimedQueue worker lifecycle state
    on Oct 31, 2026
  9. dezren39 commented on Oct 31, 2026

    @dezren39
    MemberAuthor

    🤖 Agent note · parked

  10. added
    user/reviewNeeds a user-look: Muse reviews first and handles what it can
    on Nov 3, 2026
  11. dezren39 commented on Nov 3, 2026

    @dezren39
    MemberAuthor

    🤖 Agent note · escalated

    • Agent: fleet monitor (repo-fleet-monitor)
    • Session / ID: repo-fleet-monitor run 2026-11-03 04:12 CST
    • Found via: monitor reconciliation (in-progress tracker, protocol §6)
    • Task: ESCALATION — this item carries a work/* assignment label but shows no activity (comments, commits, CI) for ~59h against an effort/s expectation of 2h (past the 2× deadline with no activity). It is probably stuck. Holder: please checkpoint, park, or hand off; otherwise the fleet monitor recommends requeueing this item so the pool stays truthful.
    • Expectation: holder responds with a checkpoint/handoff, or the item is requeued on a later monitor pass.
  12. added
    queue/queuedHas a queued task in the Supabase agent queue
    source/creatorFiled by the new-issue-creator job
    task/triageQueue packet kind: verify, reproduce, and route this item
    on Nov 3, 2026
  13. 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 3812 (small_fix, parked, priority 30) 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

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

Metadata

Metadata

Assignees

Labels

queue/parkedQueue task is parked (waiting on CI, time, or an event)queue/queuedHas a queued task in the Supabase agent queuesource/creatorFiled by the new-issue-creator jobstatus/parkedDeliberately paused with a recorded resume conditiontask/triageQueue packet kind: verify, reproduce, and route this itemuser/reviewNeeds a user-look: Muse reviews first and handles what it canwork/assignedQueue worker lifecycle state

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions