/sequence-execution-plan

name: sequence-execution-plan
description: Build dependency-aware plans from goals, incidents, backlogs, or priorities. Use when priority conflicts with execution order and Codex must test prerequisites or mitigations, preserve absorbed-work traceability, or explain why lower-priority work happens first.

Sequence Execution Plan

Turn a flat request or priority list into a small dependency graph and then into an executable sequence. Optimize first for meaningful risk reduction, then durable completion, while controlling effort, uncertainty, and planning churn.

Preserve the Core Distinctions

Keep these fields separate. Never use one as a substitute for another.

| Field | Question it answers | |---|---| | Outcome priority | How important or damaging is the unmet outcome? | | Current impact | What is happening while the outcome remains unmet? | | Mitigation status | Has the immediate impact been reduced? | | Durable resolution | Has the required outcome actually been achieved? | | Execution order | What should be done next, considering dependencies and risk? |

Allow a P2 prerequisite to execute before a P0 durable fix when the prerequisite is genuinely necessary. Keep the P0 outcome open until its acceptance criteria are satisfied. If active damage continues, place the smallest safe mitigation before the prerequisite.

Build the Plan

1. Frame the Required Outcome

Restate the request as an observable result rather than a proposed implementation.

Capture:

• the desired outcome;
• who or what benefits;
• current impact and cost of delay;
• constraints, deadlines, SLAs, and non-goals;
• acceptance evidence that proves durable completion.

Separate known facts from assumptions. Ask only for information whose answer could materially change the first committed action; otherwise state a reasonable assumption and continue.

Example: Replace “build a retry service” with “failed payment notifications are retried without duplicate charges, and operators can prove delivery or terminal failure.” The retry service is one candidate implementation, not the outcome.

2. Decompose into Outcome and Work Items

Create the smallest work items that produce independently verifiable progress. Include investigation only when it resolves a named uncertainty.

For each item, record:

• **Result:** observable state produced by the item.
• **Type:** outcome, mitigation, prerequisite, implementation, validation, rollout, or cleanup.
• **Done evidence:** test, metric, artifact, decision, or observed behavior.
• **Estimate:** relative size or time range when useful.
• **Uncertainty:** low, medium, or high, with the unknown named.
• **Current state:** ready, blocked, in progress, or done.

Avoid vague items such as “improve architecture,” “handle edge cases,” or “test everything.” Replace each with a bounded result.

3. Map Cause-and-Effect Relationships

Express each relationship as a sentence before drawing an ordering conclusion:

• `A blocks B`: B cannot start or finish until A is complete.
• `A enables B`: A makes B cheaper, safer, or possible but may not be mandatory.
• `A mitigates B`: A reduces B's active impact without durably resolving B.
• `A overlaps B`: some acceptance criteria are shared.
• `A replaces B`: completing A satisfies every required criterion of B.
• `A validates B`: A supplies evidence that B works.

Do not infer dependency from preference. “The code would be cleaner after A” does not prove that B is blocked by A.

4. Test Every Proposed Foundation

Classify a foundation as exactly one of:

• **Necessary:** the target cannot be completed correctly, safely, or within a binding constraint without it.
• **Useful:** it reduces effort or improves maintainability, but a direct solution can still meet acceptance criteria.
• **Speculative:** its value depends on unproven future work.

Before scheduling a foundation first, answer:

1. Which acceptance criterion becomes impossible or unsafe without it? 2. What evidence shows the direct path is inadequate? 3. How long can the foundation take, including uncertainty? 4. What impact continues during that delay? 5. Can its scope be narrowed to the capability the target actually needs? 6. Does it unlock other committed outcomes?

Schedule a necessary foundation before the durable fix. Prefer the direct path over a merely useful foundation unless the measured enablement value justifies the delay. Exclude speculative foundations from the committed horizon.

5. Handle Active High-Severity Impact

When severe impact is active, split response from resolution:

1. Contain damage with the smallest safe reversible action. 2. Add observability needed to verify the containment. 3. Build any proven prerequisite. 4. Implement and validate the durable resolution. 5. Remove the temporary measure after the durable fix is proven.

Do not let a large foundational project delay containment. Do not describe a mitigation as resolution.

6. Generate Candidate Paths

Compare at least the plausible paths rather than defending the first decomposition:

• direct target;
• prerequisite, then target;
• mitigation, prerequisite, target, cleanup;
• mitigation and prerequisite in parallel, then target;
• replacement item only, with the target's criteria transferred;
• investigation, then choose between direct and prerequisite paths.

For each candidate, estimate:

• time to first meaningful risk reduction;
• time to durable completion;
• continuing impact during the path;
• effort and reversibility;
• key uncertainty and failure mode;
• enablement value for other committed work.

Reject a path when it violates a binding constraint or leaves an acceptance criterion uncovered. Choose the remaining path that reduces meaningful risk earliest and reaches durable completion with controlled effort and uncertainty.

7. Order into Commitment Horizons

Produce three horizons:

• **Now:** one or two ready actions the team can start without another plann