feedback_planning_sequence_not_hours_capacity_flexible

Planning discipline — sequence + dependencies, not hours

Rule (Rich-directive 2026-05-20 in strategy session):

“claude is very bad at estimating how long it will take it to do coding work. for instance, it often tries to defer doing a small spike, as it thinks it will take longer than it does. when planning, i would like to try and build our plan without too much focus on hours of work. i just want to look at the sequence of tasks, and dependencies and focus on getting things done. i can get more developers if i need them.”

Why

• Claude consistently over-estimates hours for its own coding work. The pattern shows up at every planning moment: I propose “~15-20 min”, “~2-3h”, “~6-10h” estimates that the empirical work then completes 2-10× faster (see [[feedback-batch-compression-lowers-defer-threshold]] — empirically 5-10× compression across BATCH π/σ/χ/ρ/ω etc.).
• Over-estimates produce wrong decisions: small spikes get deferred because they “look too long” — when they actually take 5-15 min. This compounds badly because spike-substrate fuels downstream decisions ([[feedback-spikes-inline-not-tasked]]).
• Rich’s capacity is flexible — he can hire developers, dispatch parallel sessions, or delegate. Hours-as-budget is the wrong constraint shape. The right constraints are: substrate-quality, dependency-correctness, and the external clocks (acquirer-DD trigger, Channon response window, Anthropic 12-24mo wills-entry).
• Plans focused on hours produce conservative, narrow plans. Plans focused on sequence + dependencies produce comprehensive, well-ordered plans. The latter scales with more developers; the former doesn’t.

How to apply

• Drop hour-estimates from plan recommendations unless Rich explicitly asks for an effort estimate. Default plan output: ordered task list with dependency graph + “what gets unblocked when X completes” — NOT durations.
• Surface dependencies up-front. What does each task depend on (substrate / library substrate / prior Q-locks / external state)? What does each task unblock?
• For spikes specifically: do inline unless the spike requires >2h sustained substrate-research. The previous “≤30 min spike → do inline” threshold in [[feedback-spikes-inline-not-tasked]] was already too conservative. Expand to “do inline unless this needs deep external substrate-research that I can’t get from WebSearch + context7 + ~/off-github/library/”.
• When Rich asks “should we do X?”: answer in terms of dependencies + sequence + substrate impact, not effort. “X depends on Y; if Y is locked, X unblocks Z and W” is the right shape. “X takes ~2h” is the wrong shape.
• Plans should scale with parallel work. Identify which tasks can run concurrently in separate developer-sessions vs which are strictly sequential. The plan output should answer “if we had 3 developers, how would we split this?”
• Existing research library substrate is fuel. ~/off-github/library/indexed/ (~99 books) + ~/off-github/library/projects/inherit/T1-T82 (T-files) + spike outcomes + cumulative-state docs + Tier-2 pgvector index — when planning new work, walk the library inventory FIRST to identify what’s already been researched (per [[feedback-check-t-files-first-for-any-inherit-v2-work]]). The research has been done; the failure mode is not utilising it.
• Substrate quality is the optimisation function. Plans optimise for: substrate depth + correctness + audit-grade discipline + jurisdictional coverage. NOT: hours, sprints, “developer happiness”, or feature-breadth.

Anti-patterns to avoid

• Proposing “~Xh” / “~X-Y min” effort estimates in plan recommendations.
• Asking “do you want me to do this in N hours or defer to later batch?” — that’s hours-as-budget thinking.
• Sequencing tasks by “what fits today’s available hours” rather than by dependency-correctness.
• Deferring spikes because “the WebSearch + analysis + write-up will take ~30-60 min” — empirically these run 5-15 min and unblock major downstream decisions.
• Failing to walk the T-file + library inventory before recommending new research investment.

Companion memories

• [[feedback-spikes-inline-not-tasked]] — parent rule; this refines it
• [[feedback-batch-compression-lowers-defer-threshold]] — empirical evidence for over-estimate pattern
• [[feedback-do-now-over-task-list-addition]] — DO-NOW discipline (this is its planning-side mirror)
• [[feedback-check-t-files-first-for-any-inherit-v2-work]] — research library inventory discipline
• [[feedback-defer-cost-arithmetic-in-recommendations]] — ω′.1 lens; defer-cost arithmetic naturally drops hour-estimates and elevates dependency-cost
• [[project-strategic-direction-locked-build-and-sell-2026-05-20]] — strategic context; substrate quality is the optimisation under build-and-sell