task-brief: an unclosed fence makes one task's brief absorb every later task, at exit 0 (Claude Code)

• I searched existing issues and this is not a duplicate (searched: task-brief, brief fence, fence, task-brief over-capture; closest: #2304 "task-brief: track fence character and length so fenced examples cannot end a task early" — see "Relationship to #2304" below)

Environment (required)

Is this a Superpowers issue or a platform issue?

• I confirmed this issue does not occur without Superpowers installed

The reporter has not tried reproducing without superpowers. The affected code is skills/subagent-driven-development/scripts/task-brief, which ships with superpowers; the reproduction below invokes that script directly, with no model involvement.

What happened?

task-brief toggles an in-fence flag on any line beginning with three backticks, and uses it to avoid treating a Task heading inside a fenced example as a real task boundary. When a task section contains an unclosed fence — an odd number of fence markers, e.g. an author deletes a closing fence while editing a code block — the flag stays true for the remainder of the file. Every subsequent real Task heading is therefore invisible, intask is never cleared, and extraction runs to EOF.

The script's only guard is that the output is non-empty:

if [ ! -s "$out" ]; then
  echo "task ${n} not found in ${plan} (no heading matching 'Task ${n}')" >&2
  exit 3
fi

So the over-captured brief exits 0 and is reported as a normal success (wrote <path>: <n> lines). Nothing in the output or the exit status indicates that the brief now contains several tasks.

Observed in real use during an 11-task plan: a 177-line task extracted as a 1159-line brief containing tasks 6 through 10. It was noticed only because the line count was implausible; a two-task over-capture would plausibly have gone unnoticed, and the brief is handed to an implementer as "your requirements."

Reproduced deterministically on both installed versions (6.3.0 and 6.4.1), identical results.

Steps to reproduce

1. Create a plan whose first task contains an unclosed fence, with two later tasks:

# Example Plan

### Task 1: First task

- [ ] **Step 1: Write the test**

```typescript
const x = 1
```

- [ ] **Step 2: Oops, this block never closes**

```typescript
const y = 2

### Task 2: Second task

TASK-2-MARKER: this must not appear in Task 1's brief.

### Task 3: Third task

TASK-3-MARKER: nor this.

1. Ask for task 1:

bash skills/subagent-driven-development/scripts/task-brief plan.md 1 out.md
echo "exit=$?"
grep -c '^### Task' out.md     # task headings in task 1's brief
grep -c 'MARKER' out.md        # later tasks' content present

1. Close the fence (the only change) and repeat.

Measured, same script, same plan but for that one line:

Expected behavior

A brief for one task contains one task. When the extractor cannot establish a task boundary — because an unclosed fence has made every later heading invisible — it should fail loudly rather than return a multi-task brief at exit 0, so the caller does not hand a subagent requirements belonging to tasks it must not touch.

Actual behavior

Exit 0, success message, and a brief containing the requested task plus every task after it. The caller has no signal. In the observed case the over-captured brief contained five tasks' worth of requirements, including scope fences for work explicitly assigned to later tasks.

Relationship to #2304

#2304 (open PR) makes fence detection CommonMark-correct: fence character and length, ~~~, a four-backtick fence wrapping a three-backtick block, indented fences, CRLF. Every case it lists causes extraction to stop early — a fenced heading is read as a real boundary and the task's tail is lost —. #2406 explicitly draws the boundary between itself and that PR with the sentence "Fence handling is out of scope here (#2304 covers it)".

This report is the opposite direction: extraction runs long. The trigger is a fence that is genuinely never closed, which no refinement of fence detection can close, so the over-capture survives a correct parser. Caveat: I have not checked out or tested #2304's branch, so this is an argument from its stated scope and from the mechanism, not a tested claim about its patch. If #2304 already adds an output sanity check, this is a duplicate and should be closed as such.

Also adjacent, both exit 0 while returning the wrong content: #2405 (unanchored task-number regex) and #2406 (a non-Task heading cannot end a task).

Debug log or conversation transcript

Session id: 227f4bf2-daa4-46ea-875e-8382d9074a66. Delivered local archive: none built. Attached bundle: no claim.

Superpowers involvement per the diagnosis report: likely — the evidence is a deterministic reproduction of the shipped script, run directly with no model calls, with a single-line control (table above). The reproduction does not depend on the transcript, so no transcript line citations are offered and no session bundle was built; the original occurrence is recorded in the session above. This report does not propose a fix.

Filed with the diagnosing-superpowers skill. Model, harness, harness version, and installed plugins are listed above.