Opus 4.8 agentic coding: given a sequential workflow (ordered series), agent jumps to the high-value/terminal step and skips the intermediate steps that make it valid

Summary

When the task is a defined sequential workflow — an explicitly ordered series of steps where each step depends on the prior ones — the agent (Claude Code, Opus 4.8) skips to the high-value / terminal step instead of executing the steps in order. It treats "this step produces the payoff" as a license to jump past the intermediate steps, even though those intermediate steps are exactly what make the payoff step valid.

This is the inverse of an earlier failure (fixating on a zero-value setup step). Here it over-corrects to the opposite extreme — jumping straight to the end — without internalizing the single governing principle: a series is executed in order.

Repro (generic)

1. The process is a numbered series: Step 1 → 2 → 3 → … → N, where the final steps are the "compare / verify / produce the result" payoff and the middle steps are prerequisites (discover/verify inputs, capture the baseline, check wiring, etc.).
2. Only Step 1 is complete.
3. Asked for the next step, the agent goes straight to a late step (the verification/comparison), reasoning that it's "the high-value action," skipping Steps 2…N-1.
4. User points out the workflow is a series and the agent jumped. The agent acknowledges — having already attempted the terminal step out of order.

Why this matters

• The terminal step's correctness depends on the intermediate ones (e.g., you can't validly compare outputs before the inputs/baseline the comparison needs have been established). Jumping to it produces a result that looks like progress but rests on missing prerequisites.
• Combined with the opposite failure mode (doing only low-value setup), it shows the agent isn't reasoning about dependency order at all — it swings between "do the cheap ceremony" and "do the exciting endpoint," neither of which is "do the next step in the defined sequence."
• The user has to babysit ordering on a process that already states its own order.

Expected behavior

• For an explicitly ordered workflow, determine the first incomplete step and do that one — never skip to a later step because it's higher value.
• Respect declared dependencies: if step K's validity requires steps < K, refuse to start K until those exist, and say so.
• "High value" ranks which workflow to run or what to prioritize among independent items — it does NOT reorder a sequential series.

Suggested guardrails

1. When a process is presented as an ordered series, compute the first-incomplete-step and constrain the next action to it; block proposals that target a later step while earlier ones are open.
2. Detect both failure poles (jump-to-end and stuck-on-setup) as the same root: not following dependency order. Always answer "what's next" with the next sequential step, not the most/least valuable one.
3. Before acting on a late step, assert its prerequisites exist; if not, stop and name the earliest missing prerequisite.

Environment

• Claude Code, model Opus 4.8 (1M context), agentic coding session on Windows.
• Same session as #69491, #69499, #69500, #69502, #69503 — this report is the jump-to-terminal-step / ignores sequential ordering facet (the over-correction opposite of #69502).