ci: wire Claude + Gemini AI review (ai-review-prompts callers)

[heskew]

What

Wires @harperfast/rocksdb-js into the AI review pipeline — the Phase-1 expansion target from the 07-02 retro (52 PRs/30d, highest risk-per-line of the candidate repos). Three thin callers of the ai-review-prompts reusables, pinned to main 1255f2e (#72 — the repo-type/native-addon layer written for this repo):

• claude-review.yml — layers: universal + repo-type/native-addon; repo-specific checks for the pnpm/oxlint/oxfmt toolchain, vendored-RocksDB bumps, the three-runtime-deps bar, and the harper-core consumer coupling (MaybePromise / key-encoding changes need a core reference).
• gemini-review.yml — mirrors the Claude caller; opt-in via gemini-review label unless GEMINI_ALWAYS_ON=true.
• validate-caller-workflows.yml — SHA-pin + shadow-job guard.

Already done outside this PR: repo:rocksdb-js label in ai-review-log; claude-review / gemini-review labels here.

Setup needed on merge (repo settings — can't be done from a PR)

1. Secrets: add ANTHROPIC_API_KEY (required); GEMINI_API_KEY + AI_REVIEW_LOG_TOKEN (optional — missing keys skip cleanly; the log token reuses the existing fine-grained PAT). Add this repo to the visibility list of the org-level HARPERFAST_AI_CLIENT_ID / HARPERFAST_AI_APP_PRIVATE_KEY secrets.
2. Variable: set CLAUDE_ALWAYS_ON=true to auto-review trusted-author PRs (or leave unset for label-only opt-in while calibrating).
3. Required check: make validate / validate a required status check on main.
4. ai-review-log README "Reviewed repos" table — follow-up PR there once this lands.

Note: the Claude review check on this PR will fail with the expected "workflow file must match default branch" guard (it always does on PRs that introduce the caller workflows — claude-code-action's anti-tamper). Ignore it; it clears after merge.

---

🤖 Generated with Claude Code

[gemini-code-assist]

Note

Gemini is unable to generate a review for this pull request due to the file types involved not being currently supported.

[github-actions]

📊 Benchmark Results

get-sync.bench.ts

getSync() > random keys - small key size (100 records)

Implementation	Rank	Operations/sec	Mean (ms)	Min (ms)	Max (ms)	RME (%)	Samples
🥇 lmdb	1	24.39K ops/sec	40.99	39.55	495.236	0.115	121,970
🥈 rocksdb	2	11.57K ops/sec	86.45	83.39	4,272.201	0.173	57,839

getSync() > sequential keys - small key size (100 records)

Implementation	Rank	Operations/sec	Mean (ms)	Min (ms)	Max (ms)	RME (%)	Samples
🥇 lmdb	1	28.81K ops/sec	34.71	33.49	645.776	0.104	144,042
🥈 rocksdb	2	12.22K ops/sec	81.81	79.36	547.193	0.057	61,118

ranges.bench.ts

getRange() > small range (100 records, 50 range)

Implementation	Rank	Operations/sec	Mean (ms)	Min (ms)	Max (ms)	RME (%)	Samples
🥇 lmdb	1	24.15K ops/sec	41.42	35.90	1,966.942	0.286	120,728
🥈 rocksdb	2	17.03K ops/sec	58.70	52.36	2,034.108	0.139	85,173

realistic-load.bench.ts

Realistic write load with workers > write variable records with transaction log

Implementation	Rank	Operations/sec	Mean (ms)	Min (ms)	Max (ms)	RME (%)	Samples
🥇 rocksdb	1	450.99 ops/sec	2,217.368	156.221	50,912.027	11.48	903
🥈 lmdb	2	26.52 ops/sec	37,710.856	449.105	1,186,037.427	136.428	64.00

transaction-log.bench.ts

Transaction log > read 100 iterators while write log with 100 byte records

Implementation	Rank	Operations/sec	Mean (ms)	Min (ms)	Max (ms)	RME (%)	Samples
🥇 rocksdb	1	35.50K ops/sec	28.17	13.60	14,071.101	0.588	177,476
🥈 lmdb	2	441.54 ops/sec	2,264.816	123.468	18,449.349	1.49	2,208

Transaction log > read one entry from random position from log with 1000 100 byte records

Implementation	Rank	Operations/sec	Mean (ms)	Min (ms)	Max (ms)	RME (%)	Samples
🥇 rocksdb	1	722.34K ops/sec	1.38	1.21	4,640.409	0.241	3,611,685
🥈 lmdb	2	449.85K ops/sec	2.22	1.21	677.038	0.277	2,249,275

worker-put-sync.bench.ts

putSync() > random keys - small key size (100 records, 10 workers)

Implementation	Rank	Operations/sec	Mean (ms)	Min (ms)	Max (ms)	RME (%)	Samples
🥇 rocksdb	1	833.62 ops/sec	1,199.589	1,041.158	1,997.525	0.323	1,668
🥈 lmdb	2	1.14 ops/sec	873,660.034	790,439.559	931,414.349	3.39	10.00

worker-transaction-log.bench.ts

Transaction log with workers > write log with 100 byte records

Implementation	Rank	Operations/sec	Mean (ms)	Min (ms)	Max (ms)	RME (%)	Samples
🥇 rocksdb	1	21.32K ops/sec	46.91	29.80	564.579	0.525	42,634
🥈 lmdb	2	822.56 ops/sec	1,215.719	202.103	15,266.447	5.26	1,646

---

Results from commit dabae25

[kriszyp]

LGTM — clean add-only AI-review CI wiring. Correct pull_request trigger (not pull_request_target), SHA-pinned action refs, and a fail-closed prompt validator, so no fork-PR token-exposure path. Reviewed via review-queue.

— Claude (Sonnet 5)

[heskew]

Follow-ups from the review feedback here, for the paper trail:

• Caller permissions fixed in this PR (2753ede) and now being retrofitted fleet-wide: ci(review): explicit caller-job permissions on the Claude review caller harper#1790 and a matching harper-pro PR (oauth already had the block). Pattern documented upstream in caller hygiene: document job-level permissions + validate gemini callers ai-review-prompts#74 so future wirings can't drop it.
• Validator gemini-caller gap fixed upstream in caller hygiene: document job-level permissions + validate gemini callers ai-review-prompts#74 (glob extended to gemini-*.yml); consumers pick it up on their next validate-pin bump.
• Both trace back to Audit and tighten GITHUB_TOKEN permissions on CI workflows harper#568 (the standing token-permissions audit) — the AI-review-caller slice of that issue closes with these.

[kriszyp]

Thin AI-review callers look safe — pull_request (not pull_request_target), explicit per-secret passing (no blanket inherit), job-level least-privilege perms, and dual 40-char SHA pins. One thing to file as a follow-up (not blocking): the shadow-job/mutable-ref validator globs only claude-*.yml, so the gemini-review.yml caller with the same write + id-token grants isn't covered — an upstream ai-review-prompts limitation. Approving.

🤖 Reviewed with KrAIs (Claude Opus 4.8)