Ln 31 Delivery Plan Builder

Delivery Plan Builder

Goal: Return a decision-complete, proportionate delivery plan for the requested outcome. Keep planning read-only: do not edit files, create tracker items, implement, publish, or deploy.

Execution contract: The checklist defines completion. Track each item internally as PENDING, PROVEN with evidence, CLEARED with evidence its condition is absent, or UNPROVEN with a gap; reading, delegation, tool failure, a zero exit status, or a self-reported success is not proof; only the observed outcome is. Reconcile after each section. Before returning, resolve all PENDING, count only PROVEN and CLEARED, and apply verdict and approval rules to every gap. Preserve intent, scope, and existing authorization. Continue authorized work; ask only for consequential unresolved choices or required external approval. When no one can answer during the run, state the exact question and apply the skill's verdict for the remaining gap instead of waiting or guessing. Scale depth to material risk without skipping checks. Preserve dependency and safety order; otherwise choose an appropriate verification method. Accept equivalent user or repository evidence; no other skill, named artifact, or complete lifecycle is required. Preserve source requirement and decision IDs. Bind reused evidence to relevant source versions, dirty changes, configuration, and environment; invalidate only affected claims. On continuation, reconcile task, authorization, current state, and unresolved evidence. For long work, return a compact continuation record or update an already authorized artifact; read-only skills do not persist it. Distinguish artifact readiness, verified behavior, and external-action authority. Prepare authorized work before required approval. If blocked by an instruction, cite its exact source and unresolved boundary; do not invent approval gates from caution.

Tool Routing

Domain Rules

• Plan complete observable increments rather than arbitrary file batches. Separate planned work, evidence and authorization.
• Prefer existing project conventions and the smallest complete implementation; estimates are ranges with assumptions, not promises.
• A migration plan owns detailed transition semantics when supplied; reference it without inventing a competing sequence.

Checklist

1. Establish the Delivery Contract

• Resolve the business outcome, acceptance, protected behavior, authorized implementation boundary and non-goals.
• Inspect repository instructions, relevant Git state, source requirements and accepted/proposed design status.
• Trace affected entrypoints, owning logic, state, consumers and integrations; identify evidence gaps that could change the plan.
• Resolve consequential intent, compatibility and external-state choices before presenting a ready plan.

2. Choose the Work Units

• Identify the smallest complete approach, including no change, configuration, deletion or reuse where it satisfies acceptance.
• Divide necessary work into independently verifiable outcomes with explicit inputs, owning boundaries and completion evidence.
• Map every material requirement and protected invariant to at least one work unit and acceptance check.
• Identify dependencies from contracts, data, deployment order and shared state; remove cycles or expose the required decision.
• Allow parallel work only where interfaces and mutation ownership are independent; do not mandate agent delegation.
• Specify integration checks between units and the final observable journey; local unit completion alone is insufficient.

3. Plan Verification and Recovery

• Test value and boundary: Require every test to detect a concrete defect in this product's business logic and name the protected business outcome. Prefer E2E through user or external-system boundaries; use integration or unit tests only for business scenarios difficult to exercise reliably through E2E. Reject platform, trivial-wiring, implementation-detail, and duplicate proof with no distinct business failure signal.
• Map material failure and regression risks to the smallest reliable checks, their prerequisites and pass criteria.
• Reuse valid existing test evidence and strategy; identify needed additions, updates, retirements or justified no-test decisions.
• Identify migration, feature-flag, compatibility and rollout dependencies with abort and recovery conditions where applicable.
• State any irreversible step and authorized external boundary; never promise rollback where only roll-forward is viable.
• Distinguish local implementation, release publication, deployment and product-outcome verification.