* fix: snapshot review state so progress comment cleanup actually fires
postReviewCleanup deletes toolState.review as its second statement, so
the defense-in-depth `if (toolState.review && progressCommentId)` branch
right after never saw a truthy value. This left an orphaned progress
comment alongside the submitted review whenever the agent called
report_progress despite Review/IncrementalReview mode instructions
(seen in the wild on colinhacks/zod#5767).
Snapshot the boolean before postReviewCleanup runs.
* move progress-comment cleanup into create_pull_request_review
The previous commit snapshotted toolState.review to work around
postReviewCleanup deleting it before the cleanup branch could read it.
That fixed the symptom but kept a fragile design: the rule "review
submitted → progress comment is noise" was enforced from the bottom of
main.ts via a flag set in one place and consumed in another, with a
helper between them that mutated the same flag for unrelated reasons.
Move the rule to its natural owner. create_pull_request_review now
calls deleteProgressComment immediately after the review is persisted,
so the cleanup is atomic with submission. This:
- closes the catch-block hole — a review submitted right before a
timeout/crash now still cleans up its progress comment.
- removes the dead "defense-in-depth" branch in main.ts that was the
original bug surface.
- relies on the existing progressCommentId=null no-op path in
reportProgress to make any later report_progress call a no-op (so
the misbehavior path can't re-create the orphan).
- only fires for Review/IncrementalReview in practice — those are the
only modes that call create_pull_request_review, and both are
prompted not to call report_progress. Build/AddressReviews/Plan
never reach this code path, so their progress comments remain
untouched.
Stranded-comment cleanup in main.ts is unchanged and still handles
the truly orphaned case (no review, no report_progress).
Colin McDonnell
8cee07d388