burndown-full

# Burndown Full ## What problem this solves A coding agent is given a plan, generates it, starts executing, and then **stops before the change is actually complete across the codebase**. The user is left with a half-migrated repo. This is not a motivation problem — it is a well-documented set of failure modes in long-horizon LLM agents: - **Context rot / long-context degradation.** Model reasoning quality drops as the input grows, *even within the advertised window*. Information in the middle of a long context is attended to least reliably ("lost in the middle"). So as execution proceeds, the agent's grip on "what's left to do" erodes. - **Premature termination.** When tool outputs and history get pruned or summarized to save context, agents lose task-level awareness ("how many items remain, am I near done?") and declare completion early. The fix shown in the research is to keep a *condensed, persistent record of remaining work* visible at all times. - **Plan-as-boundary error.** A plan is a *hypothesis* about scope produced before the repo was fully explored. The real set of affected files is almost always larger than the plan's list (barrels, tests, stories, configs, re-exports, dynamic usages). Treating the plan's file list as the boundary guarantees an incomplete burndown. The countermeasures below are drawn from how robust coding agents (Claude Code's TodoWrite, etc.) actually achieve reliable completion: **enumerate before executing, externalize the worklist to a fi...