Derive supported-version list from single source of truth (#25)

[Liorrr]

What

The "Unsupported format version" error in load_binary (crates/shrimpk-memory/src/persistence.rs) hardcoded "(supported: 1, 2)" as a string literal. That literal had to be hand-edited whenever a new format version was added — easy to forget (the P2 future-proofing concern in #25).

Changes

• Add const SUPPORTED_VERSIONS: &[u8] = &[1, 2] next to FORMAT_VERSION as the single source of truth for the error message. Documented to stay in sync with the version_byte match arms in load_binary / validate_binary.
• Build the error string from it via .join(", "), preserving the exact "1, 2" wording the existing header_validation_wrong_version test asserts.

Why scoped to the message only

The v1/v2 detection arms are asymmetric — v1 requires the legacy u32 layout check (version_byte == 1 && data[5..8] == [0,0,0]) while v2 is a plain byte[4] == 2. They can't be folded into a uniform SUPPORTED_VERSIONS.contains(...) without changing behavior, so the constant is the source of truth for the human-readable list only. This narrows the dual-maintenance to a documented one-line constant, matching the P2 scope of the issue.

Verification

• cargo fmt -p shrimpk-memory — clean
• cargo check -p shrimpk-memory — passes
• cargo test -p shrimpk-memory — 392 + 11 passed, 0 failed, 21 ignored (model-gated)
• cargo clippy -p shrimpk-memory -- -D warnings — clean

The existing header_validation_wrong_version test (asserting version 99 errors, lists supported: 1, 2, and hints "update your binary") passes unchanged and keeps asserting the literal string, so it remains an independent check that the constant renders the right text.

Closes #25

🤖 Generated with Claude Code

[Liorrr]

Independent review (clean-context agent)

Reviewed gh pr view 32, gh pr diff 32, and gh issue view 25 fresh, then read the surrounding code in crates/shrimpk-memory/src/persistence.rs (the load_binary arms, validate_binary, and the header_validation_wrong_version test). I did not write this code.

Summary

The PR replaces the hardcoded "supported: 1, 2" literal in the "Unsupported format version" error with a constant SUPPORTED_VERSIONS: &[u8] = &[1, 2] rendered via .iter().map(u8::to_string).join(", "). This is exactly the P2 future-proofing fix requested in #25, scoped (correctly) to the human-readable message only.

Correctness verification

• Constant value matches reality — load_binary (persistence.rs:471, 481) accepts version_byte == 1 (with the legacy u32 layout check) and version_byte == 2; validate_binary (persistence.rs:943, 968) accepts the same two. &[1, 2] is accurate.
• Rendered string is byte-identical — [1u8, 2].iter().map(u8::to_string).collect::<Vec<_>>().join(", ") yields "1, 2", so the message reads (supported: 1, 2) — unchanged from before. The header_validation_wrong_version test (persistence.rs:1204) asserts err_msg.contains("supported: 1, 2") and still passes unchanged, serving as an independent render-check. Confirmed no behavior change.
• u8::to_string as a function path is valid idiomatic Rust and clippy-clean.
• Scope claim is honest — validate_binary returns Ok(false) for unknown versions and never emits this message, so it correctly does not reference the constant. The PR's rationale about the asymmetric v1/v2 detection arms (v1 needs the data[5..8]==[0,0,0] legacy check, v2 is a plain byte compare) is accurate; folding into a uniform .contains() would change behavior, so leaving the arms as-is is the right call.
• Grep confirms "supported: 1, 2" exists only at the old error site and the test assertion — no other copy of the list elsewhere in the codebase.

Findings

P1 — none. The change is correct and behavior-preserving.

P2 — none material.

P3 (nit) — doc comment overstates what the constant enforces. persistence.rs:60-63 says "Keep in sync with the version_byte match arms in load_binary / validate_binary." The constant is only consumed in load_binary's error branch; it does not drive the match arms in either function. When v3 is added, a maintainer must (a) bump SUPPORTED_VERSIONS and (b) hand-add a version_byte == 3 arm in both functions — the constant cannot enforce (b). The comment is a reasonable convention reminder, but it reads as if the constant links the arms, which it does not. Optional: reword to "this list is display-only; adding a version also requires new match arms in both functions." Non-blocking.

Verdict

Minimal, well-reasoned, behavior-preserving change that does exactly what #25 asks within the stated P2 scope. Tests pass per the PR (392+11, 0 failed) and the assertion logic confirms the string is preserved.

Confidence Score: 5/5 — correct, in-scope, no behavior change, existing test independently validates the rendered output.