fix(chatgpt-review): detect completion by content, not DOM element count

[BorisTyshkevich]

Summary

Found live while running /ship against a long ChatGPT review conversation (4+ rounds).

• ChatGPT virtualizes/prunes older turns out of the DOM in long conversations. browser.mjs's completion and recovery-vs-fresh-submission decisions were both built on assistantCount(page) > before, a raw element count assuming the DOM only ever grows. Once pruning kicks in, that count plateaus (or drops), which:
  • made waitForCompletion wait out the full --timeout and throw timed_out with an empty response_text, discarding a real, complete answer that was sitting there the whole time;
  • made review()'s recovery-vs-fresh decision go the wrong way and submit a duplicate message into the conversation instead of recovering the existing one. Confirmed live: at least one redundant resubmission generated unwatched, and the same plan file got uploaded 9 times under one literal name, which is why ChatGPT's own upload UI started collision-renaming it (plan-590(9).md).

Fix

Track a SHA-256 fingerprint of the current last assistant message's text instead of a count — content identity, not DOM position, so it's immune to how many turns happen to be mounted.

• review()'s recovery decision now compares the live tail's fingerprint against session.lastResponseFingerprint (persisted on every successful pass).
• waitForCompletion's before is now either the pre-submission baseline text (fresh submission: accept only a tail that differs from it) or null (recovery: accept whatever is already there).
• Each pass's upload is now named with the real pass number (plan-590-pass4.md) via a same-content temp copy, rather than re-uploading the plan/diff file's own literal path (which must never move — it's the review-session identity) every time.
• state.mjs's session record gains lastResponseFingerprint alongside passCount.
• Removed the now-fully-unused assistantCount().

Test plan

• Added two tests simulating a pruned DOM (the assistant locator always returns exactly one element, with different content across submit/recovery) proving both paths detect the new response correctly regardless of mount count.
• Updated the plan-mode upload test for the new pass-numbered filename.
• node --test tests/*.test.mjs — 30/30 pass.
• Verified live against the actual broken session from tonight's run: invoking the fixed script with --session <handle> correctly recovered a real, complete, previously-stuck review (status: "completed", proper trailing VERDICT: REVISE line, passCount and lastResponseFingerprint persisted correctly).

🤖 Generated with Claude Code