You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
feat(evolution): run processing chain every 4h (raise throughput vs backlog growth)
The pipeline generates ~25 issues/day (research+issues+introspection) but
the once-daily processing chain landed only ~1-2/night (analysis caps at 8,
most triage out / don't land cleanly), so the open backlog grows ~20/day —
the recurring 'again many unprocessed issues'.
Run the PROCESSING chain every 4h instead of daily (generation stays daily):
- analysis: 0 1,5,9,13,17,21 * * * (was 0 21)
- implementation: 0 2,6,10,14,18,22 * * * (was 0 22, +1h after analysis)
- integration: 0 3,7,11,15,19,23 * * * (was 0 23, +1h so CI settles)
This is ~6x processing passes/day. Mechanically safe: reports are
date-keyed (overwritten each run, latest wins) and the implementation
freshness gate is date-based ('today's analysis = fresh'), so intra-day
re-runs don't break the chain; the accepted-label + dedup prevent
re-processing already-handled issues.
Watchdog: STAGES now mirrors the FIRST daily slot (analysis=1, impl=2,
integration=3) — 'a report for today must exist by then' (reports are
date-keyed). Mirror test updated to read the first hour of a multi-slot
cron; stage-report tests made slot-aware. 35 watchdog tests pass.
NOTE: takes effect after the server re-registers cron (register_evolution_cron
on next 'hermes update'/pull). Cost ~6x the processing agent runs/day — dial
to every 6h/8h if needed. Complementary generation backlog-cap still
recommended to fully converge (generation ~25/day > even 6x processing).
0 commit comments