Planner agent is slow (~100s/run) — gate latency dominates small features

[n1arash]

Summary

The planner agent is slow (~100 s/run), so gate latency dominates the wall-clock of small features — especially with a re-plan cycle.

Evidence (dogfood campaign)

• Planner runs logged at 73–113 s each on haiku / effort=low (see dogfood/TIMELINE.md: 109.0s, 99.8s, 113.6s, 95.3s, 89.8s, 73.4s, 72.7s, 148.2s, 137.8s …).
• With a re-plan cycle that's ~3–4 min before grill even starts.

Why it matters

For small features the planning gate is a large fraction of total wall-clock, hurting the pipeline's perceived responsiveness.

Proposed fix

Mostly downstream of model/effort choice, but consider a lighter planning prompt for small features (tie into the triage/fast-path work) so trivial requests don't pay full planning latency.

Acceptance criteria

• Small/trivial features use a lighter planning path (shorter prompt or condensed plan).
• Planner wall-clock for a trivial feature drops measurably from the ~100 s baseline.
• Non-trivial features retain the full planning depth.

Source: dogfood/ITERATION_REPORT.md MINOR-9; dogfood/TIMELINE.md.