Idea
Change the auto-dev tick model so every tick does both grooming and a build, rather than the current "execute the first step that has work, then stop." Concretely, each tick would:
- Reconcile finished work.
- Advance any open PRs that need it (CI fixes, review responses).
- Groom the backlog — triage new issues, post plans, ask questions, handle park proposals.
- Claim the oldest approved (
auto:ready) issue and build one PR — as long as it's under the in-flight cap.
The next tick does the same and claims the next issue, so the queue drains one built PR per tick while earlier PRs await the maintainer's merge.
Why
Today a tick stops at the first step with work, and triage only runs on ticks that would otherwise idle. That was fine under the one-PR-in-flight rule, but with an N-PR-in-flight cap (recently raised to 6 in obsidian-gemini — see allenhutchison/obsidian-gemini#1083) and an hourly scheduler, we want each tick to make maximal forward progress: keep the backlog groomed and keep building, every tick, until the in-flight cap is reached.
Key design points / open questions
- Phase ordering within a tick: cheap-and-safe first, expensive-and-mutating last — reconcile → advance PRs → triage → build. Build goes last so that if it consumes the run's time budget, the grooming already happened.
- Bounding: triage stays capped (e.g. 5 issues/tick) and the build claims exactly one issue, so a tick stays finite even though it now runs all phases.
- Natural throttle: because building is gated on being under
MAX_PRS_IN_FLIGHT, "build every tick" self-limits — it builds each tick only until the cap is reached, then ticks just groom + advance until the maintainer merges.
- Overlap risk: every-tick builds increase the chance a long build overruns the schedule interval. The orphan age-gate (
ORPHAN_RECLAIM_MINUTES) mitigates duplicate builds, but if builds routinely exceed the interval, revisit cadence or add a proper lock.
- Migration note: this supersedes the "first step with work, then stop" language in the auto-dev SKILL.md tick algorithm section — that whole section needs a rewrite (phases run in order every tick; only a preflight failure exits early).
Context
Discussed interactively while raising the in-flight cap for obsidian-gemini. The cap change (obsidian-gemini#1083) is the minimal step; this issue captures the fuller model to implement in maintainerd, which is where auto-dev is migrating.
Idea
Change the auto-dev tick model so every tick does both grooming and a build, rather than the current "execute the first step that has work, then stop." Concretely, each tick would:
auto:ready) issue and build one PR — as long as it's under the in-flight cap.The next tick does the same and claims the next issue, so the queue drains one built PR per tick while earlier PRs await the maintainer's merge.
Why
Today a tick stops at the first step with work, and triage only runs on ticks that would otherwise idle. That was fine under the one-PR-in-flight rule, but with an N-PR-in-flight cap (recently raised to 6 in obsidian-gemini — see allenhutchison/obsidian-gemini#1083) and an hourly scheduler, we want each tick to make maximal forward progress: keep the backlog groomed and keep building, every tick, until the in-flight cap is reached.
Key design points / open questions
MAX_PRS_IN_FLIGHT, "build every tick" self-limits — it builds each tick only until the cap is reached, then ticks just groom + advance until the maintainer merges.ORPHAN_RECLAIM_MINUTES) mitigates duplicate builds, but if builds routinely exceed the interval, revisit cadence or add a proper lock.Context
Discussed interactively while raising the in-flight cap for obsidian-gemini. The cap change (obsidian-gemini#1083) is the minimal step; this issue captures the fuller model to implement in maintainerd, which is where auto-dev is migrating.