REVIEWED_TREE: 4d6a982968de8e11d2665976fc91587730a4767d /home/user/.capy/work/gst986-wt
{"severity":"INFORMATIONAL","path":"docs/troubleshooting.md","line":3307,"summary":"The RECEIPT_INVALID entry still describes the old AND rule: it says write refuses when the read commit's product patch is not the receipt's AND a later change carries a targeted class. The fixed code at lib/ship-receipt-depth.ts:153 refuses on either one. So a user who hits the refusal after a docs-only or TODOS.md commit (the Step 14 and 14.5 commits) finds no matching cause in this entry. docs/review-policy.md and the changelog fragment were updated; this entry was not."}
{"severity":"INFORMATIONAL","path":"lib/ship-receipt-depth.ts","line":153,"summary":"The fix list calls this main's rule, but it isn't. On origin/main, parseReviewTargeted(value, productPatchId) takes no head and binds any record. So under this change, every money, gate, auth or secret ship whose Step 14 or 14.5 commits after the Step 11 read now stops at Step 19 with RECEIPT_INVALID. That is the same outcome pass 1's Red Team flagged. Step 19's prose (ship/sections/pr-body.md:247, 'fix that input file and rerun') doesn't say to rerun the targeted reader on HEAD; only the tool's own error message does. The guard fails closed, and the code deliberately defers the docs-only case to GST-1031, so this is not data loss. It is a known extra stop in unattended /ship runs."}
{"severity":"INFORMATIONAL","path":"lib/ship-receipt-depth.ts","line":153,"summary":"When the product patches are equal and only classesSince refuses (a test edit after the read that skips a case), the message prints the same patch id twice: 'whose product patch X is not this receipt's X'. This was already true before the fix and the fix kept it. The message misstates the cause; the decision itself is correct."}

I found nothing at the blocking floor. The OR guard fails closed in the right places: it refuses when the product patch differs, when classesSince returns null (unreadable), and when a class shows up after the read. Its only production caller, bin/gstack-ship-receipt:227, passes the same arguments as before. The test change does replace the old docs-binds assertion with a refusal, but that matches the intended new rule; it doesn't weaken coverage. The new no-money-token regression test covers the CRITICAL fix. I reran the three focused files at this tree: 34 pass, 0 fail, 403 expect() calls.
