Problem

PR #960 shipped sprint and ceremony data models (SprintConfig, SprintCeremonyConfig, Sprint, VelocityRecord) and #724 wires them into builtin templates. But there is no runtime scheduler that actually triggers ceremonies, manages sprint lifecycle transitions, or enforces sprint boundaries.

More importantly, the current ceremony model is calendar-based (MeetingFrequency: DAILY, WEEKLY, BI_WEEKLY, PER_SPRINT_DAY) and sprint duration is measured in wall-clock days (duration_days). This creates a fundamental mismatch with synthetic agents that operate orders of magnitude faster than humans -- agents can complete thousands of tasks before a single weekly retro fires.

Issues to Solve

1. No ceremony trigger mechanism

SprintCeremonyConfig declares what ceremonies exist and how often they should run, but nothing in the engine actually schedules or triggers them. Ceremonies are inert config today.

2. Calendar time vs agent throughput mismatch

A 14-day sprint with bi-weekly retros assumes human pace. Synthetic agents can finish an entire sprint backlog in minutes. This means:

• Velocity tracking (story_points / duration_days) becomes meaningless -- velocity is effectively infinite
• Ceremonies fire long after the work they should reflect on is done
• Sprint boundaries create idle time (agents waiting for a calendar tick) or are ignored entirely

3. Sprint lifecycle is passive

Sprint.with_transition() supports the status state machine (PLANNING -> ACTIVE -> ... -> COMPLETED), but nothing drives transitions automatically. Who/what moves a sprint from ACTIVE to IN_REVIEW when all tasks complete?

4. Ceremony frequency granularity

MeetingFrequency only has calendar units. There's no way to express "after every N task completions" or "at sprint midpoint by task count" or "when the board state changes significantly."

Design Options

Option A: Task-driven sprint cadence

Sprints complete when their tasks reach terminal status, not on a timer. Ceremonies trigger at task-count milestones:

sprint:
  mode: "task_driven"           # vs "time_boxed" (current default)
  ceremonies:
    - name: "sprint_planning"
      trigger: "sprint_start"   # fires when sprint transitions to ACTIVE
    - name: "standup"
      trigger:
        every_n_completions: 5  # fires after every 5 task completions
    - name: "retrospective"
      trigger: "sprint_end"     # fires when all tasks complete

Pros: natural fit for agent speed, no idle time, ceremonies are always relevant
Cons: new trigger model, unpredictable ceremony timing, velocity needs a different unit

Option B: Virtual time / simulation clock

Introduce a configurable time-compression factor. A "day" in the synthetic org might map to N real-world minutes:

simulation:
  time_scale: 100               # 1 virtual day = ~14 real minutes

Pros: preserves existing calendar-based model, familiar Agile concepts
Cons: adds complexity, arbitrary scaling factor, still disconnected from actual work throughput

Option C: Hybrid -- calendar default with throughput overrides

Keep calendar-based scheduling as default but add throughput-based ceremony triggers as an overlay. Whichever fires first wins:

sprint:
  duration_days: 14
  auto_complete_on_tasks_done: true  # end sprint early when backlog clears
  ceremonies:
    - name: "standup"
      frequency: "per_sprint_day"
      also_trigger_every_n: 10       # or after 10 task completions, whichever is first

Pros: backward compatible, graceful degradation, works at any agent speed
Cons: two competing scheduling models to reason about

Option D: Event-driven ceremonies (no schedule)

Ceremonies are not scheduled at all. Instead, the engine emits events (sprint_started, task_completed, board_state_changed, sprint_backlog_empty) and ceremony triggers are event subscriptions:

ceremonies:
  - name: "retrospective"
    on: "sprint_backlog_empty"
  - name: "standup"
    on: "task_completed"
    debounce: 5                   # batch: fire once per 5 events

Pros: most flexible, naturally composable with the message bus
Cons: requires robust event system, harder to predict when ceremonies happen

Scope

• Sprint lifecycle automation (auto-transition on task completion or time boundary)
• Ceremony trigger mechanism (integrate with meeting protocol system)
• Velocity tracking adaptation for non-calendar cadences
• MeetingFrequency extension or replacement for task-driven triggers
• Engine integration: who owns the scheduler loop? (AgentEngine? dedicated service?)

Dependencies

• feat: implement Kanban board and Agile sprints workflow types #960 -- Sprint and Kanban models (shipped)
• feat: update templates with workflow configs after Kanban/Sprints ship #724 -- Template workflow configs (in progress)
• Meeting protocol system (communication/meeting/)

Open Questions

• Should different templates be able to mix modes (e.g. startup uses task-driven, enterprise uses time-boxed)?
• How does ceremony triggering interact with multi-agent coordination waves?
• Should velocity tracking normalize to "points per sprint" regardless of duration, or keep a time dimension?