complete-slice reopens completed task on inherited/order-dependent e2e failure (regression of #6112)

Problem

complete-slice reopens an already-complete task when slice-level verification catches an inherited / order-dependent failure that is not caused by the task itself. Reopen deletes T##-SUMMARY.md, then dispatcher re-derives execute-task for the same task ID; the re-dispatched task exits in <1s / $0 (nothing left to do), auto-mode exits, and the loop repeats on next resume. Symptom is identical to closed #6112 but recurs on the broad-scope e2e verification path.

Root Cause (suspected — installed runtime v3.0.0)

Same class of bug as #6112 / PR #6113, but the fix appears not to cover the case where slice-level verification runs a broad command (full e2e sweep) whose failures are:

• order-dependent across specs (shared Redis throttle, JWT blacklist, tenant fixture state)
• not attributable to any single task in the slice

complete-slice still interprets any red signal as "the last task didn't really finish" and issues gsd_task_reopen, which unconditionally deletes the task summary. auto-recovery then sees the missing artifact and forces retry.

Relevant paths in installed runtime (~/.gsd/agent/extensions/gsd):

• prompts/complete-slice.md — reopen prompt, no branch for "inherited baseline drift / cross-spec pollution"
• tools/reopen-task.js — unconditional SUMMARY.md delete
• auto-recovery.ts verifyExpectedArtifact — treats missing summary as retry signal

Expected Behavior

Slice-level verification that surfaces cross-spec / order-dependent failures should:

1. Not reopen a task whose own verification was green.
2. Either mark the slice as needs-remediation (route to reassess-roadmap) or record a KNOWN_BASELINE_DEVIATION on the slice summary, rather than unconditionally invalidate the last task artifact.
3. gsd_task_reopen should refuse to delete T##-SUMMARY.md if the task has no distinct failing verification evidence attached (defense-in-depth against the prompt calling reopen for the wrong reason).

Environment

• GSD version: 3.0.0
• Model: claude-opus-4-7
• Failing unit: execute-task M031/S09/T04 (repeatedly re-dispatched after complete-slice M031/S09)
• Related closed issue: #6112 (PR #6113)

Reproduction Context

• Phase: complete-slice on M031/S09 (rollout / e2e sweep slice)
• T04 reasoning explicitly reported order-dependent Jest failures: "run 1 = 3 suites/13 tests failed, 7 suites/27 tests passed; run 2 diverged to 7/23 failed, confirming order-dependent cross-spec state pollution (shared Redis throttle, JWT blacklist, tenant fixture ...)"
• complete-slice then issued reopen of T04, dispatcher re-derived execute-task M031/S09/T04, which exited in 327ms / $0.

Forensic Evidence

Journal flow chain (2026-07-12T00:00:45Z → 00:03:28Z):

iteration-start        flow=06175c21
dispatch-match         rule=summarizing → complete-slice unit=M031/S09
unit-start             unit=M031/S09
unit-end               unit=M031/S09
post-unit-finalize-start unit=M031/S09
artifact-verification-retry unit=M031/S09     ← the trigger
post-unit-finalize-end unit=M031/S09
iteration-end          unit=M031/S09
iteration-start        flow=ecb38a75
dispatch-match         rule=executing → execute-task unit=M031/S09/T04   ← reopened
unit-start             unit=M031/S09/T04
terminal               flow=auto-orc
unit-end               unit=M031/S09/T04     (327ms, $0)
auto-exit              flow=37100019

Recent-unit cost pattern (matches "zero-cost re-dispatch after reopen"):

complete-slice activity log (seq 680): 18 tool calls, no errors, last reasoning "Slice S09 needs execution follow-up." — the fingerprint of the reopen path.

Forensic report also flags 47 stuck-loop anomalies across the project, all matching this pattern (dispatch → complete → verify-retry → reopen → re-dispatch).

Regression note

PR #6113 addressed the task-level version. The M031/S09 case shows the same failure mode via the broad slice-level verification path (full e2e sweep across specs the failing task didn't touch). Please consider whether #6113 fully covers slice-scope verification, or if the reopen decision needs a "was this task actually the cause" gate.

Auto-generated by /gsd forensics