review: ground SDK contract blockers in the exact method implementation #220

Confirmed false-positive review

On 2026-09-22, a Gemini code review of a delegated Python SDK adapter returned two blocking findings based on an incorrect external API premise.

• Review request: ded5ca41-922b-461c-a429-89806d7beec3.
• The reviewer claimed Bitwarden SDK secrets().list() and get() required uuid.UUID objects through a UniFFI .bytes interface.
• It proposed changing both calls and adding fake-client assertions enforcing UUID objects.
• Exact supplied SDK source instead declares get(self, id: str) and list(self, organization_id: str). The adjacent create() method uses UUID objects; its argument type cannot be generalized to the other methods. The implementation is a JSON-command wrapper.
• Adjudication request 0ef07365-8203-499a-9532-6075e55aa8ca read the supplied method bodies, withdrew both blockers, and returned PROCEED. The primary also had successful real read-only calls, but such credentialed checks should not be necessary to refute a source-level type claim.

Both native review executions succeeded. This was a substantive review-grounding failure, not a transport failure.

Root cause

The reviewer asserted a remembered/generalized SDK contract without establishing it from the exact supplied methods, then proposed tests that would encode the same false premise. The authoritative references were already in the review repository; adding more reviewers or a dependency layer would not address the failure.

The supplied SDK 2.1.0 reference has get at line 96, create at line 145, and list at line 189. Local artifacts retain the full first review and its adjudication. No private application source or credentials are included here.

Smallest proposed fix

Amend the existing review guidance:

1. For a blocker involving an external API signature, cite the exact supplied/installed implementation or matching official version-specific documentation for the method being called.
2. Check wrapper serialization and overloads before asserting a native/FFI type requirement.
3. If that evidence is unavailable, state the uncertainty and the minimal verification needed rather than presenting an unverified premise as a demonstrated runtime failure.
4. When proposing fake-client assertions, ensure they mirror the real interface rather than merely restating the reviewer's hypothesis.
5. Keep ordinary caller adjudication: concrete contradictory source evidence should resolve the finding without modifying correct production code.

Acceptance

Use a small reviewer regression case with intentionally asymmetric method signatures: get/list(str) and create(UUID). A correct review preserves the read calls and does not demand false UUID assertions. Pair it with a genuinely incorrect call to verify that evidence-grounded blockers are still reported.

No SDK compatibility framework, automated verdict classifier, mandatory extra review round, new provider route, dependency pin, or live-secret test requirement. This issue concerns the review instructions and regression example; it does not authorize implementation, release, or deployment.