From 632375faf1c585987a635ec6c79b062001f0b200 Mon Sep 17 00:00:00 2001 From: Brendan Clement Date: Wed, 3 Jun 2026 14:11:33 -0700 Subject: [PATCH] docs: add cross-SDK parity guidance for code review (#3464) Adds a REVIEW.md at the repo root with cross-SDK parity guidance for automated code review. The Claude Code review feature automatically loads `REVIEW.md` as review-only context. This is intentionally a semantic nudge, not a deterministic check, it relies on the reviewer reading the sibling SDK, so it will catch most gaps. --- REVIEW.md | 26 ++++++++++++++++++++++++++ 1 file changed, 26 insertions(+) create mode 100644 REVIEW.md diff --git a/REVIEW.md b/REVIEW.md new file mode 100644 index 000000000..65aab71c6 --- /dev/null +++ b/REVIEW.md @@ -0,0 +1,26 @@ +# Code review guidelines + +Repo-specific guidance for automated PR reviews. + +## Cross-SDK parity + +LanceDB exposes the same core (`rust/lancedb`) through Python, TypeScript (`nodejs`), +and Java bindings. Behavioral drift between SDKs is a recurring problem, so watch for +parity gaps when reviewing — but only flag real ones: + +* If the change adds or modifies user-facing API or behavior in the shared core + (`rust/lancedb`), check whether each binding that should expose it (`python`, + `nodejs`) does. A core change with no corresponding binding update is worth a note. +* If the change adds or modifies a public API in one SDK but not the other, open the + sibling SDK's corresponding module and state whether an equivalent exists. If not, + note it as a possible parity gap and suggest a follow-up issue. +* For bug fixes, first read the sibling SDK's analogous code path to check whether the + same bug exists there. Only raise parity if it actually does. Do not ask to "port" a + fix for a bug that only ever existed in one binding. +* Stay silent on internal-only refactors, tests, docs, and changes with no cross-SDK + surface. +* Parity expectations apply to the Python and TypeScript (`nodejs`) SDKs. Java currently + implements only the remote table, not the local/embedded backend, so it is expected to + be partial — do not flag Java for missing local-only functionality. +* Keep parity feedback to a short, clearly-labeled note (e.g. "Possible SDK parity + gap: …"). It is advisory, not a merge blocker.