Model declares issues ready to close after silently dropping verified components of reviewed pull requests
Summary
In the same long review session as an earlier report, the model again dropped verified components of pull requests it reviewed. It then told the user that the related issues were ready to close. The user closed them and shipped a release on that basis. Two of those issues were not fully fixed.
What happened
- The user's written procedure requires every component of a diff to be enumerated and mapped to "apply" or "reject, with a reason" before any verdict. A memory entry added earlier in the same session restated this rule after an identical failure.
- The model rejected two pull requests as "already covered by our branch":
- one contained a 15-minute expiry for stream iterators, GetRecords page limits and a trimmed-data error;
- the other contained a timestamp-decoding fix for a binary wire protocol.
The model had implemented only part of each and never listed the rest.
- During an issue sweep, the model listed issues as "fixed, close them". The user closed them and released.
- Only when the user asked about one specific issue did the model check the related pull requests and find the missing parts. Every one of them was verifiable from the vendor's API model in seconds.
Expected behaviour
Before saying "covered" or "ready to close", the model should list every function, test and CHANGELOG line of the related pull requests, and show where each lands. It should never report an issue as done from memory of a partial implementation.
Impact
Issues were closed and a release shipped while known, documented gaps remained. Those gaps were in diffs the model had already read in the same session.
Environment
- Claude Code CLI
- Model: claude-opus-5-5 (1M context)