Repository navigation
fix(roadmap): comment on pull request when implement stops #3997
Description
Problem Description
When ImplementRun stops on a task group before completion (such as when it hits a token budget limit or a test fails), _push_passed() pushes the commits of completed groups to the branch on GitHub. end_stopped() writes a status comment to the issue (self.number), but it writes no comment to the pull request (self.pull) unless self.amendments is not empty. In addition, a staged pull request keeps its staging title (docs(openspec): plan #...) and body. The GitHub Actions workflow Plan Check then runs on the pushed code commits and fails, while human reviewers see no explanation on the pull request.
Reproduction Steps
- Start an implement run for a staged item with 3 task groups.
- Complete group 1 and group 2.
- Stop group 3 due to token limit or a failed command.
- Inspect the pull request on GitHub:
_push_passed()pushed commits for group 1 and 2, but the pull request has no comment and its title still starts withdocs(openspec): plan #. CIPlan Checkruns and fails.
Expected vs Actual Behavior
Expected: When ImplementRun stops after pushing commits to a pull request, it writes a status comment to self.pull that names the stopped step and the failure class.
Actual: ImplementRun writes no comment to self.pull, leaving the pull request without status information.
Environment Diagnostics
- DevOps CLI Version: 0.80.0
- Python Version: 3.14.10
- Execution Environment: Kubernetes runner pod
Activity
dan-petty commentedon Nov 7, 2026
Intake placed this item to the backlog: intake puts every new item in the backlog. A person plans the milestones.
fixprefix of the title gives the type.(roadmap)scope of the title gives the scope.Reviewers and CI get no explanation on the PR, which blocks debugging, but the system still pushes commits and does not crash.Improves observability for human reviewers and reduces failed CI confusion, but does not change core functionality.The code already writes a comment to the issue in end_stopped; extending it to write a comment to self.pull is a small addition.Both deal with the pull request state after ImplementRun stops and _push_passed runs, but #3991 updates the PR title, body, and labels while the candidate adds a status comment naming the stopped step.dan-petty commentedon Nov 7, 2026
Answer from project standards: the fault is wider than a stop in a group. In implement_run.py, the
stopmethod posts to the pull request only whenself.pullis set andself.amendmentsis not empty. So a stop in the verify phase, the scoped checks, the push or the publish phase also leaves the pull request with no comment.Cover these phases in the acceptance criteria. A test for a stop in each phase must find one comment on the pull request. The comment names the step and the failure class. It holds a marker line for the run id, so a rerun updates it and posts no empty comment.
This item stays the owner of the comment on a stop. The issue "feat(roadmap): implement keeps phase marks and the spend of a killed Job" (part of #3027) adds the marker line. It also adds the update of the comment of a run. It does not post the stop comment.
dan-petty commentedon Nov 7, 2026
Evidence from pull request #4031 (issue #2163):
When group 2 failed in the runner pod,
ImplementRun.end_stopped()commented on issue #2163 and set marks in roadmap state.However, it did not update or comment on draft pull request #4031. PR #4031 remained open on GitHub in draft state with the initial placeholder body:
Closes #2163\n\nThe job is not finished. It replaces this body when it finishes.Reviewers saw a draft PR with no diagnosis or explanation of the failure until manual evaluation. Updating the pull request body or commenting on
self.pullinend_stopped()is necessary to communicate the failure diagnostic directly on the PR.