serde-code-review

Serde Code Review

Review Workflow

1. Check Cargo.toml — Note serde features (derive, rc), format crates (serde_json, toml, bincode, etc.), and Rust edition (2024 has breaking changes affecting serde code)
2. Check derive usage — Verify Serialize and Deserialize are derived appropriately
3. Check enum representations — Enum tagging affects wire format compatibility and readability
4. Check field attributes — Renaming, defaults, skipping affect API contracts
5. Check edition 2024 compatibility — Reserved gen keyword, RPIT lifetime capture changes, never_type_fallback
6. Verify round-trip correctness — Serialized data must deserialize back to the same value

Gates (before reporting findings)

Run in order. Do not write a finding until the step that applies has passed.

1. Serde context on disk — Pass when: You have read the relevant Cargo.toml (crate or workspace root) and can state Rust edition, serde / serde_derive features if non-default (derive, rc), and which format crates apply (serde_json, toml, bincode, etc.) for the code under review. Then apply edition-specific checklist items (e.g. gen, RPIT/never_type_fallback) only when that file supports them.

2. Per-finding evidence — Pass when: Each issue cites [FILE:LINE] from the current tree for the struct/enum, Serialize/Deserialize impl, or attribute block in question (not from memory, docs-only, or another branch).

3. Category check vs protocol — Pass when: For the finding type (derive attrs, enum tagging, flatten, custom impl, sqlx + serde alignment), you ran the matching checks from the review-verification-protocol skill (e.g. full type definition + serde attrs before “wrong representation”; confirmed edition in Cargo.toml before edition-2024-only findings). Then add the finding.

4. Output shape — Pass when: The report lines match Output Format below (severity + description).