Runtime V2 fails completed tasks as no-progress and records doneFileFound false despite .DONE

[mathebrito]

Bug: Runtime V2 fails completed tasks as no-progress and records doneFileFound: false despite .DONE

Summary

Taskplane Runtime V2 repeatedly fails completed documentation tasks as No progress after 3 iterations. The failure occurs even when all STATUS.md checkboxes are complete and, in DEVOPS-015, even when the worker-created .DONE marker exists in the lane worktree.

Reproductions

DEVOPS-014 — complete checklist, no .DONE

• Flat 7-checkbox task.
• Worker obeyed runtime-owned .DONE rule and did not create .DONE.
• STATUS.md complete, report exists, git clean.
• Runtime failed task as No progress after 3 iterations.

DEVOPS-015 — complete checklist, .DONE present

• Flat 8-checkbox task.
• Worker explicitly created .DONE as final marker.
• Lane verified .DONE exists.
• Final batch state still persisted doneFileFound: false and failed as No progress after 3 iterations.

Expected

A task with all tracked checkboxes complete and .DONE present should be marked succeeded. The no-progress intercept should not override already observed completion.

Actual

Batch ends paused/failed:

{
  "status": "failed",
  "doneFileFound": false,
  "exitReason": "No progress after 3 iterations"
}

Suspected areas

• Runtime V2 .DONE path lookup may be checking the wrong task folder/worktree path.
• Completion marker detection may happen before final worker commits and then be cached.
• Exit-intercept/no-progress state may override success state.
• UI/status can briefly show succeeded before final persisted state flips to failed.

Local evidence

See /Users/mlab/devops/docs/devops/20260523[DEBUG]taskplane_runtime_completion_bugs.md.

[HenryLach]

¡Gracias por el reporte tan detallado! Thank you for taking the time to write this up — the structure (two contrasting reproductions, expected vs actual, three concrete suspect areas) is genuinely helpful and shows you understand the runtime/worker ownership rules around .DONE better than most reporters. The suspect areas you listed map to real code paths (execution.ts:986 for the .DONE detection and lane-runner.ts:1269 for the no-progress intercept), so you're looking in the right places.

We've worked through a few similar Runtime V2 completion-detection bugs in the past — see #537 (worker spinning when STATUS / review state diverged), #501 (monitor poll resolving STATUS.md against the wrong path in workspace mode), and #461 (ghost-running workers after silent subprocess death) — and each one fell to the same diagnostic pattern: pair the user-visible symptom with the actual on-disk state and runtime logs at the moment of failure. If you can provide the details below, we're confident we'll be able to remediate this one as well.

What we'd need to get from "plausible hypothesis" to "confirmed root cause"

Critical

1. Taskplane version (taskplane --version) and OS. Runtime V2's .DONE detection and no-progress logic have shifted across recent releases, so pinning the exact version is essential.
2. Full batch-state.json from the failed batch (the lane object specifically, with iterations[], observedStatusHistory, worktree path, and branch). The three-field snippet in the issue is the final state — what we need is the trail of every poll across the 3 iterations.
3. Filesystem proof for DEVOPS-015. ls -la <lane-worktree>/.DONE output, alongside any log line where the runtime said it checked a .DONE path. If those two paths differ, that's the bug; if they match, the bug is somewhere else.
4. The lane worker's session log / stderr across those 3 iterations. Was the worker idle? Committing work that didn't land before the next poll? That distinguishes a polling race from a path bug from a parser bug.
5. STATUS.md content exactly as on disk at the moment of failure (both tasks). The runtime parses checkbox state via regex; subtle format drift (- [X] vs - [x], BOM, trailing whitespace) reads as "complete" to a human but unparsed to the runtime.

Helpful

6. The PROMPT.md for both tasks. This matters because of a deliberate code path at execution.ts:1053:

   const doneAcceptedAsAuthority =
     doneFileFound && !(multiSegmentContext && multiSegmentContext.isFinalSegment === false);

   .DONE is intentionally ignored mid-segment for multi-segment tasks. If DEVOPS-015's .DONE landed during a non-final segment, the observed behavior would be expected — but the runtime wouldn't tell you that's why. Confirming whether either task is multi-segment is a fast disambiguator.

7. Whether the batch is workspace-mode / polyrepo. Worktree path resolution behaves differently in workspace mode (that's exactly what Monitor poll re-resolves STATUS.md path with isWorkspaceMode=false — breaks all workspace tasks #501 fixed). Your /Users/mlab/devops/... path hints at a layered repo structure, so it's worth confirming.

8. Reproducibility on retry. Does re-running the same task fail the same way every time, or only sometimes? Deterministic → logic bug. Intermittent → polling/race.

9. The contents of 20260523[DEBUG]taskplane_runtime_completion_bugs.md, pasted (redacted as needed). It's referenced at the bottom of the issue but isn't attached, and it likely already contains most of the items above.

Why this much detail

We've found that for Runtime V2 completion bugs, attempting to debug from symptoms alone usually leads to fixing the wrong code path. With the artifacts above, your three hypotheses (.DONE path lookup, completion-detection caching, exit-intercept overriding success) are mutually distinguishable — we won't have to guess which one is firing.

Whenever you can paste the items above (especially batch-state.json, the ls -la, and the STATUS.md files), we'll dig in. ¡Gracias de nuevo!