Repository navigation
Description
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).
- 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 writeshidden_files/lane-handoff-<queue>-<lane>.jsonwith 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. - 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.
- 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
3a02ea3to370cd4d#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:
- Snapshot write + read steps present in all lane shift bodies; schema matches Shift batching, creator-style: lane handoff snapshots + supervision mode for queue lanes #2140
- One evidenced handoff: a shift starts from the previous shift's snapshot and its report names what the snapshot saved vs re-verified
- Two-week input/run comparison posted on Shift batching, creator-style: lane handoff snapshots + supervision mode for queue lanes #2140 (Part 1 success test)
- Part 2 gate state recorded on Shift batching, creator-style: lane handoff snapshots + supervision mode for queue lanes #2140 (binding present or not); no supervision-mode or cadence change made under this issue
Activity
developing-today commentedon Oct 29, 2026
CODE-1053
dezren39 commentedon Oct 30, 2026
🤖 Agent note · picked up
dezren39 commentedon Oct 30, 2026
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/, allenabled: true, all 40m, alltimeout_secs: 5400, all delivering to chata15e5512-51ce-49c1-ad0f-46beaea69b04:repo-health-code-pilotrepo-queue-worker-shift,-b,-c,-dhidden_files/repo-queue-worker-instruction.md(shared by all four)repo-health-opencode-pilotrepo-queue-worker-shift-opencode,-opencode-bhidden_files/lane-shift-instruction.md(shared)repo-health-openchamber-pilotrepo-queue-worker-shift-openchamber,-openchamber-bhidden_files/lane-shift-instruction.md(shared)repo-health-nix-pilotrepo-queue-worker-shift-nix,-nix-bhidden_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)
lane-handoff-<queue>-<lane>.json, but only the six parameterized bodies passLANE = A|Bin 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 saysrm -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 explicitPARAMETERS: … LANE = X(matching the other six) and parameterise §8's lock path; derive the snapshot lane from that same value.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.Notes for the implementer
hidden_files/is tracked inhatch-personal(5,748 files) and autocommitted, so the ten snapshot files will be committed automatically; overwrite-in-place keeps that bounded. Do not add history files or per-run copies.~/workspace/goals/…; the authoring checkout on this laptop is~/hatch-personal/workspace/goals/…. Edit the authoring checkout and leave the runtime path convention alone.openchamber-dispatcherandopenchamber-babysitterare both stillenabled: true, cutover is queued as task 3806 for Implement the session conductor: merge openchamber-dispatcher + openchamber-babysitter into openchamber-conductor #2153; (b) session↔task binding not present — queue task progress carries stage/artifact/next, no session id. Gate NOT satisfied on both counts; no supervision mode, no cadence change.Routing
Implementation packet enqueued on
repo-health-code-pilotfor this issue, kindsmall_fix, flaggedlive-fleet-change, carrying the two-file edit surface, the three gaps above, and the existing four acceptance criteria. Dedupe keyrepo-health:v1:fix:developing-today/code:issue:2158.dezren39 commentedon Oct 30, 2026
🤖 Agent note · parked
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 pathrepo-queue-code-worker.lockfixed torepo-queue-code-worker-<lane>.lockwith 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.dezren39 commentedon Oct 31, 2026
🤖 Agent note · picked up (resume)
implementation_complete. Verified fresh: Implement lane handoff snapshots for queue shifts (Part 1 of #2140; supervision mode gated on conductor + binding) #2158 OPEN, labels had no hard stops (was queue/parked + status/parked + work/assigned); both shared instruction files still carry the lane-handoff snapshot write/read steps (repo-queue-worker-instruction.md §8, lane-shift-instruction.md §0/§3), and live snapshots exist for code lanes a–f plus nix/openchamber/opencode lanes. Remaining acceptances are time-gated: the two-week per-lane input/run comparison on Shift batching, creator-style: lane handoff snapshots + supervision mode for queue lanes #2140 is due ~2026-11-13 and cannot be posted on 2026-10-31.dezren39 commentedon Oct 31, 2026
🤖 Agent note · parked
dezren39 commentedon Nov 3, 2026
🤖 Agent note · escalated
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 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