feat(loop): automated watch-CI skill + loop-log observability (delivery-loop hardening #4+#5)#143
Conversation
…ry-loop hardening #4+#5) Turn delivery-loop step 8 into a bounded, self-logging loop. New dikw-web-watch-ci skill: gh pr checks --watch → classify → route real failures to the fresh-context fixer → re-push, gated by MAX_ROUNDS=3 + a same-failure circuit breaker + a one-rerun budget for the known graph.spec.ts Pixi flake; always pulls review prose before merge; merges explicitly (never --auto, which outraces the review). scripts/loop-log.mjs appends one structured JSON line per transition to a gitignored .loop-log.jsonl so an autonomous run is diagnosable. Wires into dikw-web-delivery-workflow step 9 + CLAUDE.md; ADR 0005 items 4+5.
|
Warning Review limit reached
Next review available in: 29 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (9)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
1 participant
What
Two coupled items from the delivery-loop hardening effort (
docs/adr/0005-delivery-loop-hardening.md), combined since #5 exists to feed #4:#4 —
dikw-web-watch-ciskill. Turns delivery-loop step 8 ("monitor CI and PR comments; resolve then merge") from prose into a bounded, executable loop:gh pr checks <N> --watch→ classify a failure → route a real one to the fresh-contextfixer→ re-push → re-watchgraph.spec.tsPixi)reviews/pulls/{N}/comments/issues/{N}/comments) before merge, and merges explicitly (--squash --delete-branch, never--auto, which outraces the review)#5 —
scripts/loop-log.mjs. Appends one structured JSON line per transition ({ts, event, detail}) to a gitignored.loop-log.jsonl, so an autonomous/background run is diagnosable after the fact (which of the four loop deaths happened — runaway / stuck / flake / silent death). The watch-ci skill logsiter_start/flake_rerun/fixer/ci_fail/merged.Why
Implements Delba Oliveira's bundled "watch CI and fix failures as they come in" plus h100envy's loop-engineering brakes (iteration cap, circuit breaker, structured log). Fixes the real timing bug where an independent review is outraced by
--auto. This is the last pair of the 5-item plan (item #1 reward-hacking gate and item #3 measured perf/a11y already merged; #2 was resolved by #140).Test / verification
scripts/loop-log.test.mjs— 4 unit tests (TDD): single-line JSON, multi-line detail escaping, default detail, JSONL append accumulation.npm run check:gatepasses with no label (touches no verification machinery — a clean demonstration of the normal path).🤖 Generated with Claude Code