source-control:babysit-prs + loop: /loop 15m fires overlap in-flight fan-out cycles when batch-cap-10 dispatch runs long

[kyle-sexton]

Lane

babysit (safe tier, /loop 15m /source-control:babysit-prs)

Triggering example

Same session, observed 3 times across 2 cycles:

• Cycle 1 (5 workers dispatched): cron fired at +15m and again at +30m while the original cycle's workers were still running (total cycle wall-clock ~47 min for 5 parallel Opus workers, longest single worker took ~26 min).
• Cycle 2 (10 workers dispatched, batch cap): cron fired again at +15m while 6 of 10 workers were still outstanding.

Each overlapping fire re-invoked the full /source-control:babysit-prs skill (a large prompt/context load), and the only useful action taken was: recognize the queue lease is already held by this same run, heartbeat it, and wait — no new snapshot, no new dispatch. The skill has no explicit instruction for this case; I inferred "heartbeat and wait" from the lease-contention mechanics in reference/orchestration.md, not from any stated re-entrant-invocation contract in SKILL.md.

Observed vs expected

• Observed: a 15-minute loop interval against a fan-out that can legitimately take 30-45+ minutes (10 workers × several-minute Opus rounds each, sequenced through lease acquisition + readiness-gate verification) causes routine overlap, not an edge case. Each overlapping fire burns a full skill-load + context re-read for a session that does nothing but heartbeat and wait.
• Expected: either (a) SKILL.md's operational runbook explicitly documents the re-entrant case — "if the queue lease is already held by this session, heartbeat and return immediately without re-snapshotting" — as a first-class step, not something the orchestrator must infer; or (b) the /loop skill / this skill's own guidance recommends an interval scaled to babysit_worker_concurrency_cap (e.g. batch-cap-10 fan-out warrants ≥30m, not the commonly-suggested 15m in SKILL.md's own examples: Looped worker: /loop 15m /source-control:babysit-prs worker).

Category

operational

Note

This is also a rule-8 "manual course correction" candidate in the strict sense — I was not given explicit instructions and had to infer the right re-entrant behavior on the fly. No user redirect occurred (I inferred correctly and no harm resulted), so filing here rather than as a separate rule-8 issue since it's the same underlying instruction gap.

[kyle-sexton]

This was generated by AI during triage.

Triage → T2 planning complete · confidence: high. Pure doc-surfacing — the re-entrant "heartbeat and wait" behavior already runs on shipped scripts (the reporter performed it by hand); no new mechanism, no script/orchestration.md change. Labeling status: ready.

Re-entrant babysit fire is an undocumented no-op-heartbeat; loop interval isn't scaled to the concurrency cap

Root cause

/loop 15m /source-control:babysit-prs <tier> re-fires the full skill on a fixed 15-min clock while the prior cycle's fan-out (up to 10 parallel Opus workers through batch lease acquisition + readiness gates) is still running 30–45+ min. Following the runbook literally, the re-fire walks toward acquire → prune → snapshot → dispatch — when the only correct action is to heartbeat the queue lease this session still holds and return. That behavior is fully supported by existing scripts but is inferable only from the lease/heartbeat mechanics in reference/orchestration.md, never stated as a runbook step in SKILL.md. Two complementary doc fixes: (a) makes an overlapping fire safe (primary); (b) makes it rare and cheap.

Behavioral contract

1. A re-entrant fire is a first-class, documented no-op-heartbeat. When the same /loop session re-fires while it still holds its own queue lease and its prior cycle's workers are in flight, it heartbeats the retained queue token and returns immediately — no prune/snapshot/dispatch. Stated runbook step, not inferred.
2. The loop interval scales to the worker-concurrency cap. Bare /loop (self-pacing) is preferred; a fixed interval scales to the cap — at the default cap 10, >=30m.

Current text (verifiable)

SKILL.md operational runbook has exactly one lease step (acquire + heartbeat + --steal-stale/skip on exit 3) — describing a foreign-holder collision path, not the same-session self-held path. The same-session "heartbeat my own live lease and return" is derivable only from reference/orchestration.md's heartbeat semantics ("Heartbeat the matching scope and token … while waiting on background workers"; a token-mismatch heartbeat = superseded → stop). No runbook step names it.

/loop 15m examples to correct — three: the common-flows worker line, the common-flows autopilot line, and the Autopilot section run-it-looped example. (The interval-less /loop … forms in the frontmatter description and Purpose paragraph are the preferred self-pacing form — leave unchanged.)

Fix (a) — first-class re-entrant runbook step (SKILL.md)

Insert as a new step in "Operational runbook (engine-backed cycle)", immediately after lease-acquire and before prune/snapshot, in the runbook's imperative voice:

Re-entrant fire (same session, prior cycle still in flight). Before acquiring or pruning anything, check whether this /loop session already holds the queue lease from a prior cycle whose background workers have not all integrated. If it does, heartbeat the retained queue token — python "${CLAUDE_PLUGIN_ROOT}/skills/babysit-prs/scripts/manage_babysit_lease.py" heartbeat --scope queue --token <retained-token> --state-dir <state-dir> (same --repo used to acquire) — and return immediately without re-snapshotting, re-pruning, or re-dispatching: the in-flight cycle owns this queue and its workers are still running. A successful heartbeat means the lease is still yours; keep polling the outstanding workers on the heartbeat cadence and let them finish. A heartbeat returning exit 3 (token does not match) means another run stale-took the scope — stop every mutation for it and do not resume (see reference/orchestration.md). Distinct from the foreign-holder path below (a different session hitting a live lease → bare acquire → exit 3 → --steal-stale refuses a fresh holder → skip); this one is this session re-firing while it still holds its own token.

Grounding: the step assembles entirely from the already-documented heartbeat semantics (all scopes) — it does NOT rely on acquire-with---token self-reaffirm, which orchestration.md documents only for the worker scope. Faithful surfacing of existing behavior.

Fix (b) — interval guidance scaled to the concurrency cap (SKILL.md)

Add one guidance line near the looped-flow examples and correct the three /loop 15m examples:

Loop interval. Prefer bare /loop /source-control:babysit-prs <tier> — it self-paces off the snapshot's recommended_cadence (reference/cadence.md). When you pin a fixed interval, scale it to the worker-concurrency cap: a full fan-out at the default cap of 10 can run 30–45+ min, so a fixed interval should be >=30m at cap-10 (longer for larger caps). A shorter fixed interval doesn't run the queue faster — an overlapping fire only heartbeats the live lease and returns (see the runbook re-entrant step) — it just re-loads the skill for no work.

Corrected examples → self-pacing preferred form (/loop /source-control:babysit-prs worker, … autopilot), noting a fixed /loop 30m … at cap-10 as the fallback.

Acceptance criteria

• SKILL.md runbook has a re-entrant step before prune/snapshot: heartbeat the retained queue token + return without re-snapshotting when this session still holds the queue lease with workers in flight.
• The step is grounded on the queue heartbeat mechanic (not queue-scope acquire-with---token) and distinguishes itself from the foreign-holder --steal-stale/skip path.
• All three /loop 15m occurrences updated to self-pacing and/or a cap-scaled interval; the interval-less /loop forms in description + Purpose left unchanged.
• Interval guidance names the concurrency cap + the >=30m anchor at cap-10, states self-pacing as preferred.
• No script changes and no reference/orchestration.md change — surfaces existing behavior only.

Notes

• Resolved soft spot: orchestration.md documents acquire-with---token self-reaffirm only for the worker scope; source-control:babysit-prs + loop: /loop 15m fires overlap in-flight fan-out cycles when batch-cap-10 dispatch runs long #472 is the queue scope. The step avoids that gap by grounding on the heartbeat mechanic (all scopes). Making queue-acquire self-reaffirm by token would be a real script change — out of scope, not needed.
• Design-consistency: reference/loop.md + cadence.md frame the skill as /loop-native self-pacing (Active 5m / Normal 15m / Quiet hourly), so a blunt 15m→30m swap would fight that — hence "bare self-pacing preferred; cap-scaled fixed interval as fallback."

[kyle-sexton]

Routing to out-of-band interview (wayfind: interview); removing status: ready so the autonomous work-lane won't dispatch a guess.

Decision the fix needs (not answered by the issue): the loop/fan-out concurrency model — how a /loop 15m firing should behave when the prior cycle's batch dispatch is still in flight. This is a design/contract call, not a mechanical fix.

Candidate models the interview should choose among:

1. Skip-if-running guard (RECOMMENDED) — a lightweight lease/lockfile; a firing that sees an in-flight cycle no-ops and lets the next tick pick up. Simple, no overlap, minimal state.
2. Dynamic self-pacing — drop the fixed 15m cron; the loop reschedules its own next wake only after the current cycle drains. No overlap by construction; changes the invocation contract.
3. Bounded overlap — allow overlap but cap total concurrent workers across cycles via a shared semaphore. Most throughput, most state/complexity.

Blast radius: touches the babysit-prs + loop contract, so it wants a human before implementation.