# Changelog

## Score

- CAI 59 → 62 (+2.6)
- Rubric changed (rubric-2026.09.8 → rubric-2026.09.17) — scores are not directly comparable.

## Lenses

- Code Health 94 → 94 (+0.0)
- Architecture 100 → 95 (-4.9)
- Maturity 40 → 61 (+20.4)
- Readiness 66 → 50 (-16.2)
- Security 73 → 78 (+4.5)

## Resolved (1)

- Documentation: no architecture or design documentation (README.md)

## New (7)

- Inconsistent high-level API entry points. `run_ping` takes raw command and arguments, while `ping` and `get_pinger` take structured `PingOptions`. The existence of `run_ping` suggests a low-level execution path, but `ping` and `get_pinger` are ambiguous: `ping` likely executes immediately, while `get_pinger` returns a `Pinger` instance (which must then be started). This mixes imperative execution with builder patterns without clear distinction.
- Inconsistent use of `Color` type for arguments. `with_raw_arguments` and `run_ping` both use `Color` (likely a typo for `Vec<String>` or similar) for arguments, but `PingOptions` also has `raw_arguments: f32`. This is a type mismatch: `f32` cannot hold raw string arguments. This is a critical inconsistency in the API design.
- Off the main sequence: pinger
- Outdated: clap
- Outdated: rand
- Outdated: thiserror
- Redundant constructors with inconsistent parameter types and naming. `new` and `new_ipv4`/`new_ipv6` accept `impl ToString` for the target, while `from_target` accepts a concrete `Target` type. This creates confusion about which constructor to use and why `from_target` exists alongside the `new` family. Additionally, having separate `new_ipv4` and `new_ipv6` constructors is redundant if the `PingOptions` struct already has a `mode: PingMode` field that can be set via `with_mode`.

## Changes since last survey

- 1 commits — 1 feature/other, 0 fixes

## By area

- (root) — 1 commit

## Notable commits

- change: Add WinGet installation instructions (#597)