# Changelog

## Score

- CAI 68 → 70 (+2.0)
- Rubric changed (rubric-2026.09.11 → rubric-2026.09.18) — scores are not directly comparable.

## Lenses

- Code Health 89 → 89 (-0.0)
- Architecture 100 → 99 (-1.0)
- Maturity 55 → 55 (+0.5)
- Readiness 79 → 81 (+2.3)
- Security 73 → 82 (+9.0)

## Resolved (1)

- Hotspot: src/parse.rs (src/parse.rs)

## New (9)

- Confusingly similar method names with unclear distinction. `to_writer` and `to_io_writer` appear to do the same thing (writing to a writer), as do `to_writer_pretty` and `to_io_writer_pretty`. The prefix `io_` suggests a distinction, but the signatures are identical (`writer: W`), making the duplication unnecessary and confusing.
- Dependency hygiene PARTLY measured — Cargo dependencies read, no committed lock to grade for currency
- Documentation: no installation or build instructions (README.md)
- Documentation: no usage examples (README.md)
- Inconsistent naming pattern for deserialization constructors. The methods `from_reader`, `from_str`, and `from_bytes` exist alongside `from_reader_seed`, `from_str_seed`, and `from_bytes_seed`. The `_seed` suffix is non-standard and unclear. It is not obvious why some methods require a 'seed' and others do not, or if 'seed' implies a different deserialization strategy. This breaks the consistency of the `from_*` naming convention.
- Inverted test pyramid
- Low cohesion: Options (LCOM4 8) (src/options.rs)
- Redundant entry points for deserialization. The module-level functions `de.from_str` and `de.from_bytes` perform the exact same operation as `Deserializer.from_str` and `Deserializer.from_bytes`. This creates two different ways to achieve the same result, confusing users about which API to prefer.
- Redundant entry points for serialization. The module-level functions `ser.to_string` and `ser.to_string_pretty` duplicate the functionality of `Options.to_string` and `Options.to_string_pretty`. Users can serialize via the `Options` struct or directly via the module, leading to inconsistent usage patterns.