t1093: Intelligent daily routine scheduling — Phase 14 AI-driven routine frequency adaptation#1619
t1093: Intelligent daily routine scheduling — Phase 14 AI-driven routine frequency adaptation#1619marcusquinn merged 2 commits intomainfrom
Conversation
Summary of ChangesHello @marcusquinn, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request significantly enhances the supervisor's operational efficiency by introducing an AI-driven adaptive scheduling mechanism for various background routines. Instead of running tasks on rigid, predefined schedules, the system now intelligently assesses the current project health and activity to determine if a routine should execute, be skipped, or deferred. This change aims to optimize resource usage, prioritize critical tasks, and reduce unnecessary operations, leading to a more responsive and self-healing autonomous agent. Highlights
Changelog
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
|
Warning Rate limit exceeded
⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. WalkthroughIntroduces Phase 14, an intelligent routine scheduler that gates execution of supervisor Phases 9–13 based on project signals and historical state. A new Changes
Sequence DiagramsequenceDiagram
actor Pulse as Supervisor Pulse
participant P14 as Phase 14<br/>Routine Scheduler
participant State as State<br/>JSON
participant Signals as Signal<br/>Refresh
participant Decide as Decision<br/>Engine
participant Phases as Phases 9–13
Pulse->>P14: run_phase14_routine_scheduler()
P14->>State: routine_scheduler_init()
P14->>Signals: routine_refresh_signals()
Signals-->>P14: critical_issues, recent_failures
P14->>Decide: should_run_routine() × N
Decide->>State: routine_state_get()
Decide-->>P14: run/defer/skip decision
P14->>State: routine_record_run() / routine_defer()
P14-->>Pulse: export ROUTINE_DECISION_* vars
Pulse->>Phases: execute Phases 9–13
Phases->>Phases: check ROUTINE_DECISION_*
Phases-->>Pulse: conditional execute/skip/defer
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ 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 |
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request introduces an intelligent routine scheduler, a significant improvement over hardcoded time intervals. The implementation is well-structured, but I've identified a few issues that need attention. There's a critical bug in routine-scheduler.sh related to capturing routine decisions, which has been highlighted with a reference to robust parameter expansion practices. Additionally, the new script is missing a required set -euo pipefail line, as per repository style. In pulse.sh, calls to routine_record_run are missing for a few routines, which would prevent the scheduler from tracking their state correctly. I've added comments for the affected areas visible in the diff. Please also ensure Phase 10b (task_creation) is updated similarly. Addressing these points will ensure this valuable new feature functions as intended.
marcusquinn
force-pushed
the
feature/t1093
branch
from
a1f5f68 to
2bb445e
Compare
🔍 Code Quality Report�[0;35m[MONITOR]�[0m Code Review Monitoring Report �[0;34m[INFO]�[0m Latest Quality Status: �[0;34m[INFO]�[0m Recent monitoring activity: 📈 Current Quality Metrics
Generated on: Wed Feb 18 02:32:22 UTC 2026 Generated by AI DevOps Framework Code Review Monitoring |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 7
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (2)
.agents/scripts/supervisor/pulse.sh (2)
1800-1834:⚠️ Potential issue | 🟡 MinorPhases 12 and 13 never call
routine_record_run— scheduler state permanently shows "never run"Neither the Phase 12 (MODELS.md) nor Phase 13 (skill update) execution paths call
routine_record_run, so theirlast_runandrun_countentries inroutine-scheduler-state.jsonare always0. Theroutine_scheduler_statuscommand will perpetually display both as "never run", and the min-interval floor inshould_run_routine()is trivially satisfied for every pulse (elapsed =now - 0).Both phases have their own stamp files for throttling so functionality is unaffected, but the scheduler state is misleading for observability. A
routine_record_run "models_md" -1/routine_record_run "skill_update" -1call (inside the respectiveif decision == "run"branches, after execution) would keep the scheduler state accurate.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.agents/scripts/supervisor/pulse.sh around lines 1800 - 1834, Phase 12 and 13 never update the scheduler state because they don't call routine_record_run after running; add a call to routine_record_run "models_md" -1 at the end of the Phase 12 branch where the decision == "run" (after MODELS.md generation/commit/push logic) and similarly add routine_record_run "skill_update" -1 at the end of the Phase 13 branch where its decision == "run" (after the skill update execution), ensuring these calls occur regardless of success/failure so the last_run and run_count in routine-scheduler-state.json reflect the attempt.
1596-1729:⚠️ Potential issue | 🟡 MinorPhase 10b never calls
routine_record_run— task_creation scheduler state permanently staleAfter the task-creation+push block completes,
tasks_addedholds the exact findings count needed for adaptive scheduling (0= clean run,>0= tasks found), butroutine_record_run "task_creation"is never called. Consequences:
last_runstays0forever →routine_scheduler_statusshows task_creation as "never run"consecutive_zero_findingsstays0forever → "skip after 2 empty runs" never triggers- The min-interval floor in
should_run_routine()is bypassed (elapsed from epoch0is always > any interval)The call should go after
should_run_task_creation=truecompletes, using$tasks_addedas the findings count:# After the git push / "No new tasks" block, inside "if [[ "$should_run_task_creation" == "true" ]]": routine_record_run "task_creation" "$tasks_added" 2>/dev/null || true🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.agents/scripts/supervisor/pulse.sh around lines 1596 - 1729, The task-creation path never records its run, leaving scheduler state stale; after the Phase 10b task-creation logic that computes tasks_added and either commits/pushes TODO.md or logs "No new tasks to create", call routine_record_run with the "task_creation" name and the tasks_added count (handle failure quietly, e.g. redirect errors or ignore return) so should_run_task_creation, consecutive_zero_findings, and last_run are updated; locate the block guarded by should_run_task_creation, find the variable tasks_added and the commit/push / "No new tasks" branches, and insert the routine_record_run "task_creation" "$tasks_added" invocation at the end of that block before it returns/continues.
🧹 Nitpick comments (2)
.agents/scripts/supervisor/routine-scheduler.sh (2)
466-467: Unusednowvariable
now=$(date +%s)is assigned but never referenced inrun_phase14_routine_scheduler(). Eachshould_run_routine()call fetches its own timestamp internally.- local now - now=$(date +%s) - # Evaluate memory_audit (Phase 9)🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.agents/scripts/supervisor/routine-scheduler.sh around lines 466 - 467, Remove the unused timestamp variable in run_phase14_routine_scheduler(): the local now and its assignment now=$(date +%s) are never used because should_run_routine() obtains its own time; delete the declaration and assignment of now to avoid dead code and potential lint warnings while leaving the existing should_run_routine() calls unchanged.
377-388:routine_defer()is defined but never calledNone of the three files in this PR invoke
routine_defer(). The signal-driven deferral paths inshould_run_routine()only echo"defer"without settingskip_until. If the intent is for callers to explicitly defer a routine for a cooldown period, this function should be wired up; if it's a future utility, a comment would clarify intent.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.agents/scripts/supervisor/routine-scheduler.sh around lines 377 - 388, The helper routine_defer() is never used: update the signal-driven deferral paths in should_run_routine() (where they currently echo "defer") to call routine_defer with the routine name and appropriate cooldown seconds (e.g., routine_defer "$routine_name" "$cooldown") so skip_until is written via routine_state_set, or if this was intended as a future utility add a short comment above routine_defer describing its purpose and when callers should invoke it; reference the routine_defer, should_run_routine, and routine_state_set symbols to locate the change.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In @.agents/scripts/supervisor-helper.sh:
- Around line 753-756: Add a help entry for the new subcommand by updating
show_usage() to include a brief description of "routine-status" (the subcommand
wired in main() that invokes routine_scheduler_status); locate show_usage() and
add a line matching the style/format of other subcommands (e.g., "routine-status
Show Phase 14 intelligent routine scheduling state") so that
supervisor-helper.sh help displays this command and its purpose.
In @.agents/scripts/supervisor/pulse.sh:
- Around line 1529-1534: Phase 9 and 10 always call routine_record_run with -1
(unknown), preventing consecutive_zero_findings from ever incrementing; change
the successful-run case to pass 0 instead of -1 so a clean exit counts as zero
findings (locate the Phase 9 block using audit_script and "memory_audit" and the
Phase 10 call that invokes coderabbit-pulse-helper.sh), and where available
update the Phase 10 invocation to accept and forward the actual findings count
from coderabbit-pulse-helper.sh (e.g., parse its stdout/exit metadata and pass
that integer into routine_record_run) so the streak logic in
should_run_routine() can progress.
In @.agents/scripts/supervisor/routine-scheduler.sh:
- Around line 1-14: The header claims an "API budget pressure" decision signal
but the functions routine_refresh_signals() and should_run_routine() do not
implement it; either remove that bullet from the file header or implement budget
tracking: in routine_refresh_signals() collect a budget metric (e.g., from an
API-usage endpoint, monitoring service, or an env var like API_BUDGET_REMAINING)
and populate a signals.api_budget_pressure boolean/score, then update
should_run_routine(routine, signals) to check signals.api_budget_pressure and
defer non-critical routines (use routine.priority or routine.critical flag) when
pressure is high; add clear signal names (signals.api_budget_pressure,
signals.api_budget_remaining) so future reviewers can find and test the change.
- Around line 443-444: The header comment stating "# Called from cmd_pulse()
after Phase 13" is incorrect because pulse.sh inserts Phase 14 before Phases
9–13; update the comment in routine-scheduler.sh at the function header that is
invoked from cmd_pulse() to accurately reflect that it is called during Phase 14
(which runs before Phases 9–13) — e.g., change the line to indicate "Called from
cmd_pulse() during Phase 14 (runs before Phases 9–13)" so the comment matches
pulse.sh behavior.
- Around line 181-187: The IN clause in the DB query references a non-existent
state 'error' so the condition is effectively redundant; update the query inside
the failure_count assignment to only check valid states (remove 'error') or use
the actual valid state name from VALID_STATES in supervisor-helper.sh (e.g.,
keep only 'failed') so the SELECT in db "$SUPERVISOR_DB" ... WHERE status IN
(...) correctly matches real task statuses.
- Around line 206-210: Update the misleading comment and align the log message:
change the docstring to state that returning "defer" is a transient signal-only
decision (no state mutation) because the code only echoes "defer" and never
calls routine_defer(), and change the coderabbit clean-streak log that currently
says "deferred" to say "skipped" so it matches the actual "skip" return;
reference the places that echo "defer" and the routine_defer() helper as well as
the coderabbit clean-streak log/return to ensure consistency.
- Around line 168-176: The gh CLI invocation that populates critical_count (see
gh_repo and critical_count) incorrectly uses a single --label with
comma-separated labels which does not produce OR semantics; update the command
to use --search with GitHub label: syntax (e.g., --search 'label:"bug" OR
label:"critical" OR label:"P0"...') or perform separate gh issue list calls per
label and deduplicate, and then assign the numeric result back to
critical_count; ensure you preserve the existing fallback (|| echo 0) and keep
the command inside the same conditional that checks gh_repo.
---
Outside diff comments:
In @.agents/scripts/supervisor/pulse.sh:
- Around line 1800-1834: Phase 12 and 13 never update the scheduler state
because they don't call routine_record_run after running; add a call to
routine_record_run "models_md" -1 at the end of the Phase 12 branch where the
decision == "run" (after MODELS.md generation/commit/push logic) and similarly
add routine_record_run "skill_update" -1 at the end of the Phase 13 branch where
its decision == "run" (after the skill update execution), ensuring these calls
occur regardless of success/failure so the last_run and run_count in
routine-scheduler-state.json reflect the attempt.
- Around line 1596-1729: The task-creation path never records its run, leaving
scheduler state stale; after the Phase 10b task-creation logic that computes
tasks_added and either commits/pushes TODO.md or logs "No new tasks to create",
call routine_record_run with the "task_creation" name and the tasks_added count
(handle failure quietly, e.g. redirect errors or ignore return) so
should_run_task_creation, consecutive_zero_findings, and last_run are updated;
locate the block guarded by should_run_task_creation, find the variable
tasks_added and the commit/push / "No new tasks" branches, and insert the
routine_record_run "task_creation" "$tasks_added" invocation at the end of that
block before it returns/continues.
---
Nitpick comments:
In @.agents/scripts/supervisor/routine-scheduler.sh:
- Around line 466-467: Remove the unused timestamp variable in
run_phase14_routine_scheduler(): the local now and its assignment now=$(date
+%s) are never used because should_run_routine() obtains its own time; delete
the declaration and assignment of now to avoid dead code and potential lint
warnings while leaving the existing should_run_routine() calls unchanged.
- Around line 377-388: The helper routine_defer() is never used: update the
signal-driven deferral paths in should_run_routine() (where they currently echo
"defer") to call routine_defer with the routine name and appropriate cooldown
seconds (e.g., routine_defer "$routine_name" "$cooldown") so skip_until is
written via routine_state_set, or if this was intended as a future utility add a
short comment above routine_defer describing its purpose and when callers should
invoke it; reference the routine_defer, should_run_routine, and
routine_state_set symbols to locate the change.
… (t1093) Adds routine-scheduler.sh module that evaluates project state signals to decide whether each routine (Phases 9-13) is worth running now, instead of relying solely on hardcoded time intervals. Decision signals: - Consecutive zero-findings runs: skip CodeRabbit after 3 clean days (still forced weekly), skip task creation after 2 empty runs - Open critical issues: defer MODELS.md regen and skill updates when >= 3 critical/bug issues are open (prioritize bug fixes) - Recent task failure rate: defer skill updates when >= 3 failures in 24h (system is struggling, prioritize self-healing) - Minimum interval floor: AI can defer but never run before the floor State tracked in SUPERVISOR_DIR/routine-scheduler-state.json: - Per-routine: last_run, consecutive_zero_findings, skip_until, run_count - Project signals: critical_issues_count, recent_failure_count (cached 10min) New command: supervisor-helper.sh routine-status (inspect scheduling state) Decisions exported as ROUTINE_DECISION_* env vars, consumed by each phase. Defaults to 'run' when routine-scheduler.sh is unavailable (safe fallback). Closes #1618
marcusquinn
force-pushed
the
feature/t1093
branch
from
2bb445e to
e2b4b90
Compare
🔍 Code Quality Report�[0;35m[MONITOR]�[0m Code Review Monitoring Report �[0;34m[INFO]�[0m Latest Quality Status: �[0;34m[INFO]�[0m Recent monitoring activity: 📈 Current Quality Metrics
Generated on: Wed Feb 18 02:43:27 UTC 2026 Generated by AI DevOps Framework Code Review Monitoring |
marcusquinn
dismissed
coderabbitai[bot]’s stale review
Auto-dismissed: bot review does not block autonomous pipeline
- Fix critical: use `|| true` + `${var:-run}` pattern so skip/defer decisions
from should_run_routine() are not overwritten by the fallback echo
- Fix critical: use --search with label: OR syntax for gh issue list to correctly
count critical/bug issues (comma-separated --label is AND, not OR)
- Fix: remove invalid 'error' state from SQL query (only 'failed' is valid)
- Fix: routine_record_run now passes 0 (clean run) instead of -1 (unknown) for
Phase 9 and 10, allowing consecutive_zero_findings streak to advance
- Fix: add routine_record_run calls for Phase 10b (task_creation), Phase 12
(models_md), and Phase 13 (skill_update) so scheduler state stays accurate
- Fix: remove unused `now` variable from run_phase14_routine_scheduler()
- Fix: remove unimplemented 'API budget pressure' from file header
- Fix: correct function header comment (Phase 14 runs before, not after, Phases 9-13)
- Fix: align 'deferred' log message to 'skipped' to match actual 'skip' return
- Fix: update 'defer' docstring to clarify it is signal-driven, not state-persisted
🔍 Code Quality Report�[0;35m[MONITOR]�[0m Code Review Monitoring Report �[0;34m[INFO]�[0m Latest Quality Status: �[0;34m[INFO]�[0m Recent monitoring activity: 📈 Current Quality Metrics
Generated on: Wed Feb 18 03:07:21 UTC 2026 Generated by AI DevOps Framework Code Review Monitoring |
|
1 participant
Summary
routine-scheduler.sh— a new supervisor module that evaluates project state signals to decide whether each routine (Phases 9–13) is worth running now, replacing purely hardcoded time intervals with adaptive schedulingpulse.shbefore Phases 9–13, exportingROUTINE_DECISION_*env vars consumed by each phase (safe fallback: defaults torunwhen module unavailable)supervisor-helper.sh routine-statuscommand to inspect scheduling stateDecision Signals
State Tracking
Persisted in
$SUPERVISOR_DIR/routine-scheduler-state.json:last_run,consecutive_zero_findings,skip_until,run_countcritical_issues_count,recent_failure_count(cached 10 min)Routines Covered
Quality
bash -n)runif Phase 14 is unavailableRef #1618
Summary by CodeRabbit
routine-statusCLI command to check the state of automated routine scheduling.