Summary / 07. Task decomposition and planning / Document
Paper 2026-09-05
Shared copy: the operator's name and machine names are replaced by roles. Nothing else is changed.
Rendering…
# The Executable Schedule: Adaptive, Dependency-Aware, Externally-Stateful Task Decomposition and Planning for a Weak-Model Coding Harness *Component 07 of 27 — Coding-Harness Program. This document specifies the planning stage: the executive function that sequences the whole request into an ordered, revisable, executable schedule of modifications and validation checkpoints. It sits after component 06 (dependency and impact analysis), which projects forward what an edit will break, and before component 08 (context construction), which will assemble the evidence each scheduled step needs. Where impact analysis answers *if I change this, what else breaks?*, planning answers *in what order, against which checkpoints, and who carries the plan?* It is written to drive a reversible build; the executable specification follows in a companion document.* --- ## Abstract Planning is the executive stage of the coding-harness program: reconnaissance orients, retrieval gathers, localization searches backward to the fault site, impact analysis projects forward from an edit to what it breaks, and planning sequences the entire request into an ordered schedule of modifications and validation checkpoints, each small enough to be executed and checkable in isolation. This paper argues that task decomposition should be adaptive, dependency-aware, executable, and externally stateful. The user request and the repository evidence produced by components 03 through 06 are converted into a machine-readable graph of change and validation obligations; only the currently actionable obligation is exposed to the model; the graph is updated as edits create or satisfy dependencies; each completed node is validated locally; and only the affected subgraph is replanned when evidence invalidates an assumption. The paper further argues that planning mechanisms themselves must be ablated, because additional or poorly aligned planning can perform worse than no explicit plan at all. The central architectural claim is stated as a slogan the whole design obeys: the LLM does not carry the plan — the harness does. Every stage of the pipeline except the single semantic-decomposition decision is deterministic software, so the schedule is built, revised, and audited on CPU; the model contributes one schema-constrained decomposition call, and the harness owns the graph and its state from then on. ## 1. Introduction The coding-harness program decomposes software engineering into a sequence of questions, and components 01 through 06 answered the opening six: how to *interact* with code (01), how to *choose* an action (02), what the repository *is* (03), what context is *relevant* (04), *where the fault is* (05), and *what an edit will break* (06). This paper answers the question that sits between the answer to 06 and any further code: *in what order should the whole request be executed, and against what checkpoints?* Component 07, task decomposition and planning, consumes the user request together with the evidence that reconnaissance, retrieval, localization, and impact analysis have produced, and converts them into an ordered, revisable graph of modifications and validation obligations that the harness executes and revises. Planning is the executive function of the pipeline, and the distinction from its five predecessors is one of *scope and of direction*. Reconnaissance, retrieval, localization, and impact analysis each answer a question about a *candidate* — what exists, what is relevant, where the fault lies, what one edit would break. Planning is the only stage that must hold the *entire request* in view at once and decide how the many candidate edits interleave. It is also the stage that turns the pipeline's analytical outputs into an *executable schedule*: a partial order over modifications and checks such that the repository stays consistent after every step, not merely at the end. In the vocabulary of the program's spine, the preceding stages orient, gather, and project; planning is what sequences the work into something that can actually be run. The central fact of the problem is that a user request is *not a to-do list*. "Make the session timeout configurable" is, in the repository, an edit *set*: a schema change, a consumer change, a default-preservation constraint, a parsing change, and a set of validation obligations — each with dependencies on the others, each with its own checkable predicate. A naive agent collapses this set into a single unverifiable mega-diff and executes it in one shot; a planning stage instead compiles it into an ordered schedule in which the type is widened before the consumer is rebound, the default preserved before it is depended upon, and the old-default test re-run before the new-configuration test is trusted. The sequencing decisions — *what must exist before what* — are planning decisions, not code-generation decisions, and CodePlan's defining property of *temporal consistency*, a repository that is valid after every step, is precisely a plan-quality criterion [1]. A second, subtler fact is that plans are *forgotten and contradicted*. The From Plan to Action study, the empirical outlier in this area, analyzed 21,120 SWE-agent trajectories across four models and eight plan variants and found that agents drift from their plans as context fills, that periodic re-injection every few steps restores compliance, and — most importantly — that a bad or misaligned plan can be *worse than no plan at all* [2]. Planning therefore cannot be treated as an unalloyed good that one adds because it sounds sensible; it must be measured, ablated, and, where the model is the weak point, *enforced by the environment rather than remembered by the model*. A third fact concerns *who owns the state*. The literature consistently rewards moving control flow out of the prompt and into the runtime. Runtime-Structured Task Decomposition showed that static decomposition — a fixed chain of LLM subtasks written into the prompt — actually *increased* retry cost over a monolithic prompt, because a failure anywhere forced downstream stages to be re-run, and that only when the runtime owned the execution flow did the cost fall, by rerunning only the failed portion [3]. The design implication is architectural and blunt: the LLM should perform bounded judgment tasks — propose the decomposition, decide the next edit — while the harness owns the schedule, its dependencies, its state transitions, and its recovery. The LLM does not carry the plan; the harness does. The thesis follows from these observations. **Task decomposition should be adaptive, dependency-aware, executable and externally stateful: convert the user request and repository evidence into a machine-readable graph of change and validation obligations; expose only the currently actionable obligation to the model; update the graph as edits create or satisfy dependencies; validate each completed node locally; and replan only the affected subgraph when evidence invalidates an assumption. Planning mechanisms themselves must be ablated, because additional or poorly aligned planning can perform worse than no plan at all. The LLM does not carry the plan — the harness does.** The paper proceeds as follows. Section 2 reviews five lines of prior work plus honourable mentions and the classical roots, each with its claims, numbers, and weak-model implication. Section 3 derives seven design principles. Section 4 specifies the architecture, labeling every node deterministic (D) or learned (L). Section 5 states the recursive self-improvement protocol. Section 6 gives the measurement plan. Section 7 concludes. ## 2. Related Work The literature divides into five modern lines — an adaptive-planning anchor, an SOP-decomposition result, a planning-as-search result, a runtime-ownership result, and an empirical plan-following study that functions as the group's outlier — plus a set of honourable mentions and the classical roots beneath all of them. Each answers one question the planning stage must resolve: what is the plan representation, how are artifacts typed, what happens when the first plan is wrong, who owns execution flow, and whether plans even get followed. ### 2.1 The adaptive-planning anchor: CodePlan **CodePlan** [1] is the anchor for this component, and it appears *differently* here than it did in component 06. There, the transferable mechanism was the *dependency oracle* — the change-type-aware traversal that projects what an edit will break. Here, the transferable mechanism is the *plan representation*: an adaptive plan graph whose nodes are `(location, edit-intent)` pairs, extended on the fly as each edit's consequences surface, executed so that the repository remains valid after *every* step — the temporal-consistency property that distinguishes CodePlan from end-state-only planning [1]. CodePlan's central reframing is repository-level coding as a *planning problem* over a partially observable state, not a sequence of independent code generations. A conventional plan might read "modify Foo, modify Bar, modify Baz, run tests," but repository change is not knowable completely in advance: a seed modification surfaces, impact analysis turns its consequences into new obligations, those obligations are performed, new dependency and change evidence spawns further obligations, and the plan is updated until the obligation set is exhausted [1]. The plan *evolves as the repository changes*; it is never emitted once and followed blindly. The published evaluation involved repository changes spanning 2 to 97 files, with CodePlan passing validity checks on five of six repositories (the arXiv abstract reports 5/6; the camera-ready reports 5/7) while baselines given comparable context but no planning machinery passed none [1]. Two weak-model lessons follow. First, planning that is *adaptive* — revised by observed effects after each action — is strictly more capable than a plan written up front, because the world is partially observable and the plan's job is to close the gap. Second, and this is the decision this paper adopts outright, the plan should be a machine-readable state object owned by the harness, not prose maintained in the context window. Asking a weak model to hold an evolving multi-step schedule "in mind" while also editing is asking it to do two unreliable things at once. The plan graph and its state belong to the harness; the model proposes semantic modifications and is handed the next actionable node. ### 2.2 SOP-driven decomposition and typed artifacts: MetaGPT **MetaGPT** [4] contributes the second idea: complex work should be decomposed by an explicit, process-shaped template that emits *typed intermediate artifacts*, rather than improvised action-by-action inside one conversation. MetaGPT encodes the Standardized Operating Procedures (SOPs) of a software organization into a multi-agent assembly line — product manager, architect, engineer, QA — where each role consumes and produces structured, schema-constrained artifacts rather than free chat: requirement document, design, task list, code, test reports [4]. The anti-cascade insight is that unstructured multi-agent chat accumulates hallucinations — agents confidently build on one another's errors — whereas forcing each stage's output into a standard artifact grounds the downstream stage and localizes error [4]. The numbers are reported on greenfield code generation with a strong model: 85.9% and 87.7% Pass@1 on the HumanEval and MBPP benchmarks — the pair reported together, with the per-benchmark split shown in a figure rather than labeled in prose — plus a SoftwareDev benchmark of 70 software-development tasks (scopes include mini-games, image processing, and data visualization) [4]. The weak-model lesson is not the multi-agent organization — this paper deliberately does *not* copy a Planner, Architect, Engineer, and QA agent, because that multiplies LLM calls and failure surfaces. The transferable discipline is the *typed artifact pipeline*: a requirement artifact feeds a change-obligation artifact feeds a dependency order feeds implementation and validation obligations, each with a schema, so the downstream stage is grounded by what the upstream stage committed to, not by a vague memory of it. That discipline costs nothing to keep in a single-model harness. An honest greenfield caveat must be recorded in the same breath. MetaGPT is a *greenfield* decomposition — requirements to design to code across roles — and it says little about turning a request into edits to an *existing* repository. Its artifact discipline transfers; its assumption that code begins empty does not. This paper adopts the former and discards the latter. ### 2.3 Planning as search: SWE-Search **SWE-Search** [5] attacks the weakness that CodePlan-style linear plans share: *what happens when the plan is wrong?* Many agents follow a single trajectory — plan, then action, action, action, failure — and their earlier decisions become effectively irreversible. SWE-Search instead frames software-engineering work as a *search tree* and uses Monte Carlo Tree Search over the action space, with a value model to evaluate intermediate states and a discriminator to compare candidate trajectories, enabling backtracking and redirection of effort toward promising branches [5]. Across five tested model backbones, it reports a 23% relative improvement over the corresponding open-source agents without its machinery [5], and — in a pattern this program has seen in earlier components — the gains *shrink as the base model improves*: explicit planning scaffolds help most where the model's own planning is weakest. The weak-model implication is architectural and forward-looking. This paper does not put full MCTS into the first planning implementation — that is expensive and its value accrues mainly to strong, capable planners. But SWE-Search's finding says that the plan's *internal representation* must support alternatives, checkpoints, failure states, rollback, replacement hypotheses, and branch scores *from the beginning*, even if round 1 follows only the highest-ranked branch. A plan is not necessarily a sequence; it is a DAG or a tree with state. Encoding the plan as such from the start gives the harness somewhere to grow — a place to attach branch scores or to restart from a checkpoint when a hypothesis is falsified — without redesigning the planner later. The cost of the richer representation is paid once, in the schema; the cost of not having it is paid every time a single-trajectory plan fails and the only recovery is to restart from the top. ### 2.4 Runtime owns execution: Runtime-Structured Task Decomposition **Runtime-Structured Task Decomposition for Agentic Coding Systems** [3] is a recent preprint, so its numerical claims should be treated as less established than the ICLR and FSE results — but architecturally it may be the single most relevant result in this group. The authors compare three approaches: a *monolithic* prompt controlling everything; *static decomposition*, a fixed chain of LLM subtasks written into the prompt; and *runtime-structured* decomposition, in which software controls the workflow and the LLM performs bounded judgment tasks. Their result is counterintuitive: *decomposition by itself can make things worse*. On a Kubernetes root-cause workload, static decomposition required 1,632 ± 145 retry tokens versus 904 ± 17 for the monolithic approach, because downstream stages had to be re-run wholesale when an earlier stage failed, whereas runtime-structured decomposition cut the cost to 436 ± 132 by rerunning only the failed portion [3]. The same behavior appeared in their multi-file debugging task. The weak-model lesson is the strongest architectural statement in this section, and it agrees with the pattern established across earlier components: the harness should own mechanics and state; the LLM should supply judgment. Decomposition implemented as *text inside a prompt* — "First analyze. Then plan. Then modify A. Then modify B. Then test. If something fails, reconsider everything" — hands control flow to a model that will forget it, contradict it, and — on failure — re-run far more than it should. Decomposition implemented as *executable control logic* — a graph where a failed node reruns only that node and its true dependents — localizes failure and recovery. Planning, done right, is control logic, not prose. ### 2.5 The outlier, and the group's most important warning: From Plan to Action **From Plan to Action** [2] proposes nothing; it *measures*. That is why it is the outlier. It analyzes 21,120 SWE-agent trajectories across four models (including GPT-5 mini, DeepSeek-V3, DeepSeek-R1, and Devstral-small) on SWE-bench Verified and SWE-bench Pro under eight plan variants, and reports four findings that jointly govern this component's design. First, a *useful* plan genuinely helps: removing the explicit plan reduced success, because agents without one fall back on internal workflows learned during training that can be incomplete or inconsistent [2]. Second — the most important warning in the entire group — a *bad* plan can be *worse than no plan*: subpar or misaligned plans damaged performance more than giving no plan at all [2]. Third, adding apparently sensible stages can *hurt*: extra phases such as additional regression testing and change summarization decreased performance when they conflicted with the model's internal problem-solving strategy [2]. Fourth, agents *forget* plans: periodic re-injection of the plan every roughly five trajectory steps reduced violations and improved performance [2]. The weak-model lesson is not "remind the model more often." It is that the harness can do something stronger than reminding. Instead of injecting "you still need to follow your plan," the environment can *continuously present the currently active obligation* — its preconditions, its permitted next actions, and its required validation — so the model never has to remember the plan at all. And because a bad or over-elaborate plan is measurably worse than none, every planning mechanism in this paper's architecture is subject to the ablation discipline of Section 3 and the measurement of Section 6. A plan is not a virtue; it is a hypothesis about the request that must earn its place. ### 2.6 Honourable mentions Three further works sharpen specific design decisions without anchoring the component. **HyperAgent** [6] supplies the mechanistic reason for role-based decomposition that MetaGPT's "SOPs are nice" leaves implicit: when a Planner delegates to Navigator, Code Editor, and Executor children, removing any child and forcing the planner to absorb its role raises cost and lowers resolution — the largest drop comes from removing the Navigator (full text §6.2, Table 5) — and the drop is worst when the planner absorbs roles that require continuous environment interaction, because those roles demand long context. Decomposition's reason is *context isolation*, not ceremony. **Hybrid-Gym** [7] contributes the most surprising *form*-of-plan result: training on decomposed subtasks transfers when the fix plan lives as a comment in the codebase but *not* when the plan is generated in a message — evidence that *where a plan lives* is a measurable design variable with real effect, not a UX nicety. **Latent Programming Horizons** [8] probes whether planning is latent in the model's residual stream *before the changes are materialized (written on disk)* — representations running ahead of the agent's own edits by up to roughly 25 steps — alongside trajectory analyses showing successful and failed runs are structurally distinguishable — together suggesting a harness could one day detect a bad plan from activations before the agent burns its budget executing it. It is a two-month-old preprint, so its specifics are provisional. ### 2.7 The classical roots The modern lines rest on four classical results, cited here for lineage rather than numbers. Plan-and-Solve [9] replaced chain-of-thought's opaque step-by-step with an explicit two-stage plan-then-solve decomposition — the direct ancestor of every coding agent that writes a plan before acting. Tree of Thoughts [10] reframed reasoning as deliberate search over branches with lookahead and backtracking — the ancestor of SWE-Search's search over software trajectories and of this paper's decision to encode the plan as a DAG rather than a list. ReAct [11] established the minimal plan-act-observe loop and the finding that interleaving reasoning with acting beats static plans — the ancestor of the plan as a living artifact revised on execution feedback. And Reflexion [12] showed that verbal self-reflection on a failed attempt improves the *next* plan — the ancestor of the per-node local-validation-and-replan loop of Section 4. These four appear throughout later components; here they are the substrate the modern lines stand on. ## 3. Design Principles Seven principles follow from the review, each tied to the evidence above. **P1 — Externally-stateful plan.** The plan is a machine-readable graph — a `PlanNode {id, target_entity, obligation, caused_by, dependencies, evidence, status, validation}` record and the edges among records — owned by the harness, never prose maintained in the context window. CodePlan's machine-readable adaptive plan [1] is the warrant, and the weak-model argument is decisive: a model that must hold an evolving multi-step schedule in mind while also editing is doing two unreliable things at once. The state lives where it can be diffed, re-read, and audited. **P2 — Adaptive and dependency-aware.** The plan evolves as edits change the repository; obligations are causally derived and updated when consequences surface, never fixed at emission. CodePlan's adaptive plan, extended node-by-node as each edit's effects are observed [1], is the warrant. The anti-CodePlan failure is a *frozen* plan that keeps asserting an assumption the repository has already falsified; adaptation is the mechanism that keeps the schedule honest against a partially observable world. **P3 — Typed intermediate artifacts.** Every stage emits a schema-constrained artifact — requirement, change obligation, dependency order, implementation task, validation obligation — that grounds the downstream stage. This is MetaGPT's artifact discipline [4], adopted without its multi-agent cost and without its greenfield assumption. The anti-cascade insight transfers whole: schema-constrained intermediate output localizes error the way free-form intermediate prose propagates it. **P4 — Plan-as-search-space.** The internal representation is a DAG or tree carrying alternatives, checkpoints, failure states, rollback, replacement hypotheses, and branch scores, even if round 1 follows only the highest-ranked branch. SWE-Search's search-over-trajectories result [5] is the warrant, and the reasoning is that the representation costs little up front but buys the ability to restart from a checkpoint or follow a falsified hypothesis's sibling without redesigning the planner. **P5 — Runtime owns execution.** Control flow lives in executable orchestration, not in prompt text; a failure reruns only the affected subgraph, never the whole plan. Runtime-Structured Task Decomposition's retry-token result — 436 ± 132 for runtime-structured versus 1,632 ± 145 for static decomposition and 904 ± 17 for monolithic [3] — is the quantitative warrant that prompt-embedded decomposition is actively *worse* than monolith and that only runtime ownership realizes the benefit of decomposing at all. **P6 — Plans are measured and ablated.** A bad plan can be worse than no plan; extra stages that conflict with the model's internal strategy can hurt; so no planning mechanism is added merely because it sounds sensible. From Plan to Action's second and third findings [2] are the warrant, and the discipline is that every mechanism of Section 4 must survive the ablation of Section 6 — removal without degradation of the honest metrics, or rejection. **P7 — The environment presents the plan; the model doesn't remember it.** The harness exposes only the currently actionable obligation — its preconditions, its permitted next actions, its required validation — and never relies on the model recalling the wider schedule. From Plan to Action's fourth finding, that agents forget plans and degrade without re-injection [2], is the warrant; the design goes beyond periodic reminding to *structural* presentation, so the active obligation is a property of the environment the model reads, not a fact the model holds. ## 4. The Architecture The pipeline is a sequence of stages; every node is labeled D (deterministic software) or L (a learned model). The invariant that governs the whole is: *the L column contains exactly one entry — the semantic decomposition call — and every upstream and downstream step is deterministic software on CPU.* The concrete inputs are the user request and the evidence the earlier components already produced: the repository recon graph of component 03, the retrieved context of component 04, the localization of component 05, and the impact DAG and its downstream change and validation obligations from component 06. The flow, from request to executing schedule: 1. **Task canonicalization [D].** The user request is normalized into a typed requirement artifact with checkable acceptance criteria: what behaviour, test, command, or observable state proves the task done. A plan must terminate at a checkable predicate, never at a vibe; if the request does not name one, canonicalization derives candidates and marks them for confirmation. This stage is deterministic text normalization plus schema validation of the requirement artifact. 2. **Semantic decomposition [L].** The single learned node: the LLM converts the requirement artifact and the evidence from components 03–06 into the *initial* typed set of change and validation obligations — modify, preserve, validate — emitted as schema-constrained JSON in one call at temperature zero. The schema constrains the output to obligation records of the form P1 describes, so the downstream deterministic stages receive well-formed input rather than free-form prose. This is the sole entry in the L column. It is *re-invoked* on replan, but each re-invocation is scoped to an affected subgraph — it remains the single conceptual learned decision, never a planner that runs continuously. 3. **Dependency graph over obligations [D].** The obligation set is assembled into a dependency graph, reusing the relation edges of component 06 and the recon graph of component 03. Each obligation's `dependencies` field is resolved against the repository structure: a type-widening obligation precedes the consumer-rebinding obligation that precedes the compilation obligation; a preserve-default obligation precedes anything that would rely on the new default. Shared types precede consumers, migrations precede usage, tests are defined early to anchor success. This stage makes the *order* of the schedule explicit and checks it for temporal consistency — no node's obligation can be discharged in an order that leaves the repository invalid [1]. 4. **Plan-DAG scheduler [D].** The dependency graph is compiled into a plan DAG with three states per node — **ready**, **blocked**, and **alternative** — and checkpoints inserted between steps so the schedule can be resumed, rolled back, or abandoned from a known-good state. The scheduler emits the executable partial order: the set of currently-ready nodes, the blocked set waiting on dependencies, and the alternative branches (per P4) that could substitute if a hypothesis is falsified. Round 1 executes the top-ranked branch, but the DAG, its checkpoint markers, and its alternative set are all present from the start. 5. **Execution driver [D].** The driver exposes *only the currently actionable obligation* to the model: its preconditions, its permitted next actions (read, edit, test, and their bounds), and its required validation. The model never sees the whole schedule; it sees the one node it may discharge now. This is P7 made structural: the environment presents the plan, the model does not remember it, and context pressure cannot evict a decision the model was never asked to hold [2]. The driver consumes the downstream next-edit decision from component 08's construction and the tool layer of component 01, and marks a node's preconditions satisfied as the edits land. 6. **Local validation gate [D].** Each completed node is validated locally — the prescribed test runs, the prescribed build check compiles, the acceptance predicate evaluates — before the next ready node is exposed. A *pass* marks the node complete and advances the scheduler. A *fail* triggers a scoped replan of the affected subgraph only: the failed node and its true dependents are re-decomposed and re-scheduled, while siblings and nodes upstream remain untouched unless the dependency graph says otherwise. This is P5 executed: a failure reruns the failed portion, not the whole plan [3]. 7. **Adaptive revision trigger [D].** The impact analysis of component 06 feeds back into the running schedule. When an edit's observed effect contradicts the schedule's assumptions — a dependency the plan did not foresee, a change obligation it did not list — the trigger adds or removes obligations and re-walks the affected dependency edges. This is P2 executed: the plan is a living artifact revised when reality disagrees, not a contract frozen at emission [1]. 8. **Plan-state persistence and audit [D].** The plan — its obligation graph, per-node status, checkpoints, branch scores, and revision history — is serialized to a persistent, externally visible artifact and audited as it changes. Persistence buys resumption (a wedged run can be restarted from the last checkpoint), auditability (each accepted edit is traceable to the obligation that caused it), and the honesty the whole program demands: the plan is not a hidden scaffold the model improvises over, but a visible, diffable object that the measurement of Section 6 can score directly. The target is explicit and checkable: the L column holds exactly one entry — the semantic decomposition call — and every stage before and after it is deterministic software on CPU. Any proposed addition that would put a language model elsewhere in the pipeline is a regression against P1–P7 and must clear the same bar as in earlier components: beat the deterministic stage on the honest metrics of Section 6, on held-out repositories, at a defensible cost, or be rejected. ## 5. Recursive Self-Improvement Protocol Component 7 of 27 follows the program's uniform protocol: the executable specification is written to 100%, round 1 lands at approximately 80% of the specified behavior, and later rounds close the gap. Each round is A/B-gated against the honest metrics of Section 6 — never the end-to-end resolve rate, which would let execution quality mask planning quality. The deterministic stages (1, 3–8) improve by direct engineering, measured by ablation against the fused baseline. The single learned stage (2) improves only if a candidate model beats the deterministic decomposition baseline on held-out repositories. And because P6 holds that planning mechanisms can actively hurt, a *removal* is as much an improvement as an addition: any stage that fails its ablation — the honest metrics do not degrade when it is switched off — is removed, and the roadmap's design rule holds throughout: make the environment better at programming rather than prompting the model harder. The plan artifact itself is versioned as it changes, so a planner regression is visible in the artifact's diff long before it surfaces as a failed resolve. ## 6. Measurement & Evaluation Planning is measured *separately* and *honestly*, in four instruments, because a phase that cannot be scored apart from its consumer cannot be diagnosed apart from it. **Plan-compliance / temporal-consistency rate.** The fraction of intermediate states — after each executed node — in which the repository remains valid. CodePlan's temporal-consistency property [1] is the criterion: a plan is good if the repository is buildable-and-testable after every step, not merely at the end. A plan that reaches a valid end-state through a broken middle has failed this instrument even if its final patch lands. This is the plan-quality analogue of component 06's pass-to-pass regression rate: temporal consistency counts the damage *during* the schedule, before the final validation can mask it. **Retry-token cost.** The key planning instrument, inherited from Runtime-Structured Task Decomposition: the tokens burned re-running failed stages [3]. The planned path must *lower* this cost versus a monolithic prompt that re-derives everything on failure, and versus a static decomposition whose fixed chain re-runs downstream stages wholesale when one fails. The instrument directly scores P5: a schedule that localizes failure to the failed subgraph scores low on retry tokens; one that forces re-execution from the top scores high. The comparison set is explicit: monolithic, static-decomposition, and runtime-structured runs of the same requests. **Resolve rate / cost / tokens.** The end-to-end regression guard: does the planned run actually resolve the request, at what dollar-and-token cost, and with what intermediate-state validity? This is the coarse instrument kept for parity with the program's other components, and it is deliberately *not* the gate for planner changes, because resolve rate cannot separate planning quality from execution quality. It catches gross regressions; the instruments above diagnose them. **Ablation.** The instrument that enforces P6: remove each planning mechanism in turn — the externalized plan, the typed artifacts, the dependency ordering, the local validation gate, the adaptive revision trigger — and measure the honest metrics with it absent. From Plan to Action's finding that a bad or over-elaborate plan can be worse than none [2] is the warrant that ablation is not a formality but a safety check: any mechanism whose removal does not degrade the honest metrics is a candidate for deletion, and a mechanism whose *addition* degrades them is a demonstrated harm. The discipline is the title of the instrument: never add a planning mechanism because it sounds sensible; prove it earns its tokens. Two honest caveats close the section. First, the strong-model-transfer caveat: the headline numbers of Section 2 — MetaGPT's 85.9%/87.7% Pass@1 on HumanEval/MBPP [4], SWE-Search's 23% relative improvement over open-source agents [5] — were obtained with strong models, and a weak model should not be expected to reproduce them; this architecture's deterministic stages carry the load precisely because the learned stages will underperform, and the retry-token and temporal-consistency instruments are the ones that will show whether the deterministic scaffolding is doing so. Second, the held-out and memorization caution inherited from the earlier components: a model that has memorized a repository's shape will score well on in-benchmark planning without having decomposed anything general, so all planning metrics must be reported on held-out and out-of-benchmark repositories, exactly as impact and localization metrics were. ## 7. Conclusion Task decomposition and planning is the executive stage that turns the user request and the repository evidence into an ordered, revisable, executable schedule — and the schedule must be adaptive, dependency-aware, executable, and externally stateful. This paper has argued that the request and evidence should be converted into a machine-readable graph of change and validation obligations; that only the currently actionable obligation should be exposed to the model; that the graph should be updated as edits create or satisfy dependencies; that each completed node should be validated locally; and that only the affected subgraph should be replanned when evidence invalidates an assumption. It has further argued, on the strongest empirical warning in its review, that planning mechanisms must themselves be ablated, because additional or poorly aligned planning can perform worse than no explicit plan at all. The single learned decision is the semantic decomposition of the request into typed obligations; everything after it — the dependency graph, the plan DAG, the execution driver, the local validation gate, the adaptive revision trigger, and the persistent audit trail — is deterministic software on CPU. For a weak model, the consequence is the design's slogan made concrete: the LLM does not carry the plan — the harness does — and the honest metrics of Section 6, not the vibes, decide whether the plan is earning its place or quietly making things worse. --- ## References 1. Ramakrishna Bairi, Atharv Sonwane, Aditya Kanade, Vageesh D C, Arun Iyer, Suresh Parthasarathy, Sriram Rajamani, B. Ashok, and Shashank Shet. *CodePlan: Repository-level Coding using LLMs and Planning.* Proceedings of the ACM on Software Engineering (PACMSE), FSE 2024 (5/6 in the arXiv abstract; 5/7 in the camera-ready). arXiv:2309.12499. 2. Shuyang Liu, Saman Dehghan, Jatin Ganhotra, Martin Hirzel, and Reyhaneh Jabbarvand. *From Plan to Action: How Well Do Agents Follow the Plan?* arXiv:2604.12147. ACM DOI 10.1145/3832783.3834400. *(ASE 2026 is not named in the arXiv record — only the ACM DOI is given. Findings and direction verified; numerical details of the four reported findings not independently re-verified against the full paper.)* 3. Shubhi Asthana, Bing Zhang, Chad DeLuca, Hima Patel, and Ruchi Mahindru. *Runtime-Structured Task Decomposition for Agentic Coding Systems.* ACM Conference on AI and Agentic Systems 2026, Agentic Software Engineering workshop. arXiv:2605.15425. *(Workshop paper; numerical claims treated as less established than the ICLR/FSE results.)* 4. Sirui Hong et al. *MetaGPT: Meta Programming for a Multi-Agent Collaborative Framework.* ICLR 2024 (oral). arXiv:2308.00352. 5. Antonis Antoniades et al. *SWE-Search: Enhancing Software Agents with Monte Carlo Tree Search and Iterative Refinement.* ICLR 2025. arXiv:2410.20285. 6. *HyperAgent: Generalist Software Engineering Agents to Solve Coding Tasks at Scale.* 2024. arXiv:2409.16299. *(Authors and full title not independently verified.)* 7. *Hybrid-Gym: Training Coding Agents to Generalize Across Tasks.* February 2026. arXiv:2602.16819. *(Preprint; authors and full title not independently verified.)* 8. *Latent Programming Horizons in Coding Agents.* July 2026. arXiv:2607.05188. *(Two-month-old preprint; specifics provisional. Authors and full title not independently verified.)* 9. Lei Wang, Wanyu Xu, Yihuai Lan, Zhiqiang Hu, Yunshi Lan, Roy Ka-Wei Lee, and Ee-Peng Lim. *Plan-and-Solve Prompting.* ACL 2023. arXiv:2305.04091. 10. Shunyu Yao, Dian Yu, Jeffrey Zhao, Izhak Shafran, Thomas L. Griffiths, Yuan Cao, and Karthik Narasimhan. *Tree of Thoughts: Deliberate Problem Solving with Large Language Models.* NeurIPS 2023. arXiv:2305.10601. 11. Shunyu Yao, Jeffrey Zhao, Dian Yu, Nan Du, Izhak Shafran, Karthik Narasimhan, and Yuan Cao. *ReAct: Synergizing Reasoning and Acting in Language Models.* ICLR 2023. arXiv:2210.03629. 12. Noah Shinn, Federico Cassano, Edward Berman, Ashwin Gopinath, Karthik Narasimhan, and Shunyu Yao. *Reflexion: Language Agents with Verbal Reinforcement Learning.* NeurIPS 2023 (externally true, though not declared in the arXiv record). arXiv:2303.11366.