Summary

The first pass of learning maintenance is now handled by LearningMaintenanceScheduler, with session-close extraction/indexing kept on the hot path and heavier consolidation/mining/trend detection deferred.

This issue tracks the next follow-up steps that should not block #127 / PR #214 but should be addressed afterward.

Follow-up scope

1. Stale historical index rebuild

   • Detect missing/corrupt/out-of-date HistoricalLogIndex state
   • Add a rebuild pass that can reconstruct index state from retained session artifacts when needed
   • Make rebuild safe to run from maintenance without corrupting active indexing

2. Optional CronScheduler integration for time-based maintenance

   • Keep LearningMaintenanceScheduler as the orchestrator for multi-signal triggers
   • Evaluate wiring the pure time-based trigger through CronScheduler instead of the local tick loop
   • Preserve session-count / size / idle triggers regardless of the final time-trigger implementation

3. Downstream integration for mined signals

   • Feed consolidated cross-session signals into the next learning consumers
   • Candidate targets:
     • skill proposal inputs
     • future trend consumers
     • richer validation/refinement signals
   • Keep this separate from the core maintenance scheduler so the scheduler remains focused on orchestration and execution boundaries

Non-goals

• Do not move SessionAnalyzer into the deferred maintenance pipeline. It is intentionally part of the synchronous session-close extraction path.
• Do not block the current scheduler rollout on CronScheduler adoption.

Why separate issue

Qodo correctly pointed out that these are meaningful next steps, but they are follow-up architecture work rather than correctness blockers for the current maintenance scheduler implementation.

Related:

• feat(learning): Consolidation Scheduler — auto-trigger memory maintenance #127
• PR feat(learning): schedule consolidation maintenance #214