fix(executing-plans): ledger the test summary, not the trailing duration - #2348

Who is submitting this PR? (required)

What problem are you trying to solve?

Fixes #2342, reported by @koreankop with logs from a real executing-plans session.

scripts/task-done fills the ledger's result field with the last non-blank line of the test log. For TAP output the last line is the duration. task-done always redirects the test command to a file, and node --test emits TAP when stdout is not a TTY, so every completion line in such a run records the runtime instead of a result:

ledger: Task 1: complete (commits 0937a72..0937a72, tests: node --test test/slugify.test.js → # duration_ms 117.7202)

This is not a correctness bug — task-done gates on exit status, so a failing run still records nothing. The cost is that the field stops being evidence. SKILL.md tells the executor to trust the ledger over its own recollection after compaction, and documents this field as → 1/1 pass (line 343). With node --test it cannot distinguish a passing run from any other run, and it silently hides shortfalls: a run of 2 passing plus 1 skipped looked identical to a clean run.

I did not hit this in my own work first. I reproduced it by following the reporter's steps on a throwaway repo (Windows 11 / Git Bash, Node v22.14.0) and got the output above, consistent with their report.

What does this PR change?

task-done now reads the run's own TAP summary counts (# tests / # pass) and records them as <passed>/<total> pass, the shape SKILL.md already documents. Runners that print no TAP summary fall back to the previous last-line behaviour. The exit-status gate is untouched. Adds a regression test to tests/claude-code/test-executing-plans-scripts.sh.

Relationship to #2388, which landed on the same line

#2388 changed the exact line this PR replaces, adding an empty-log guard so grep exiting 1 under set -euo pipefail can no longer abort task-done and drop the ledger line entirely:

last=$(grep -v '^[[:space:]]*$' "$log" | tail -n 1) || last="(no output)"

This PR is rebased onto that and deliberately carries the guard onto the fallback branch:

else
  last=$(grep -v '^[[:space:]]*$' "$log" | tail -n 1) || last="(no output)"
fi

That is load-bearing, not cosmetic. Resolving the conflict the obvious way — keeping this PR's version of the line — silently reintroduces #2385, and none of this PR's own assertions would catch it. I verified that directly; see the third row of the verification table below. The two fixes are complementary: #2388 stops the fallback from aborting, this one makes the TAP path report an actual result.

Is this change appropriate for the core library?

Yes. task-done is core executing-plans infrastructure that Superpowers ships, and the ledger contract it writes is core to how execution survives compaction. The change is not tied to a project, team, or third-party tool: it reads TAP, a cross-language test output format, and leaves every non-TAP runner byte-identical. It adds no dependency.

What alternatives did you consider?

1. Record the exit status (→ exit 0; <last line>), as the issue suggested. I tried this first and it does not work: task-done returns early on a non-zero status, so rc is always 0 by the time the result field is built. It would record a constant, not evidence.
2. Parse ok / not ok lines and count them. Rejected as redundant and more fragile — TAP already prints the totals, and counting result lines has to handle subtests, # SKIP and # TODO directives correctly to avoid being wrong in exactly the cases that matter.
3. Special-case node --test. Rejected as too narrow. Keying on TAP means any TAP-emitting runner benefits, and nothing is node-specific.
4. Let the caller pass a result extractor per runner. Rejected as scope creep: it changes task-done's interface and pushes work onto every caller to fix a default that can simply be correct. Worth revisiting only if TAP parsing proves insufficient.
5. Emit pass 4 fail 0. Rejected in favour of 4/4 pass to match the documented format.

Does this PR contain multiple unrelated changes?

No. One problem, one behaviour change, plus the regression test covering it.

Existing PRs

• I have reviewed all open AND closed PRs for duplicates or prior art
• fix(executing-plans): task-done no longer aborts when a passing test prints nothing #2388 (merged) — touches the same line for a different bug (executing-plans: task-done aborts silently after a passing test command that prints nothing (grep exit 1 under pipefail) #2385). This PR is rebased onto it and preserves its guard; see the section above.
• fix(executing-plans): ledger the test summary, not the trailing duration #2346 (closed) — my own earlier attempt at this same fix, which I closed myself. This PR supersedes it.
• Other prior art in this area, none of it overlapping: Rebuild executing-plans as a first-class inline (Native) execution mode #2318 (merged) introduced these scripts; fix(sdd): plan-scoped workspace — per-plan artifact dirs, self-identifying ledger, end-of-plan cleanup #1943 (merged) made the workspace plan-scoped; fix(sdd): record in-flight tasks in the ledger to prevent re-dispatch of committed work #2322, fix(sdd): record dispatches in the ledger so outages do not re-dispatch committed work #2297, feat(sdd): ledger Discoveries section carries cross-task findings across compaction #2274 (open) change what the ledger omits (in-flight tasks, dispatches, cross-task findings). None touches the content of the tests: … → <result> field. I searched open and closed PRs for duration_ms, task-done, ledger, and tap.

Environment tested

Shell/OS for the runs: Windows 11, Git Bash (scripts ran under bash via their shebang), Node v22.14.0. I have not tested on macOS or Linux; the reporter's original session was macOS 26.6.2 / zsh.

New harness support

Not applicable — this PR does not add support for a new harness.

Evaluation

• Initial prompt. I was reading this repo's issue tracker, asked my agent to explain executing-plans: task-done ledgers the last log line as the test result, so node --test runs record # duration_ms … instead of pass/fail #2342, and then asked it to fix it. The change is grounded in a reproduction that was actually run, not in reasoning from documentation.
• Eval sessions. None, and I would rather say that plainly than pad this section: this is a deterministic shell-script fix, not behaviour-shaping skill content. No SKILL.md prose changed, so there is nothing for a skill eval to measure. The appropriate verification here is deterministic, and that is what was run.

Behaviour of the result field, measured on a throwaway repo:

The skipped case is the most useful one: 2/3 pass surfaces a shortfall the duration line hid entirely.

Each assertion was checked against the code it is meant to guard, so that none of them can pass vacuously:

The third row is why the guard is called out above: the naive conflict resolution passes every assertion this PR adds while re-breaking #2385, and only #2388's tests catch it.

Full suite is green, 14/14, with no pre-existing failures. (An earlier revision of this PR disclosed one unrelated Git Bash failure in task-start prints the brief path; 49b1db5 fixed it upstream, so that no longer applies.) The sibling tests/claude-code/test-sdd-workspace.sh also passes.

The regression test feeds a TAP fixture through printf, so it adds no Node dependency and runs wherever the suite runs.

Rigor

• If this is a skills change: I used superpowers:writing-skills and completed adversarial pressure testing — not applicable: this is a script + test change, no skill content modified
• This change was tested adversarially, not just on the happy path — verified the non-TAP fallback, the empty-output path, the failing-command gate, a skipped-test shortfall, and the three-way assertion matrix above
• I did not modify carefully-tuned content (Red Flags table, rationalizations, "human partner" language) without extensive evals showing the change is an improvement — none of that content is touched

Human review

• A human has reviewed the COMPLETE proposed diff before submission