# Changelog

## Score

- CAI 64 → 64 (+0.9)
- Rubric changed (rubric-2026.09.11 → rubric-2026.09.18) — scores are not directly comparable.

## Lenses

- Code Health 100 → 100 (-0.2)
- Architecture 91 → 98 (+6.1)
- Maturity 49 → 49 (+0.0)
- Readiness 55 → 58 (+3.4)
- Security 100 → 100 (+0.0)

## Resolved (1)

- Documentation: no installation or build instructions (README.md)

## New (5)

- Dependency hygiene PARTLY measured — SwiftPM pinning read, dependency currency NOT established
- Duplicated block (8 lines × 2) (Sources/Schedule/Plan.swift)
- Inconsistent input types for the same operation. `every` accepts `Interval`, `Period`, and `String` to define recurrence. `Interval` and `Period` are both time durations but have different internal structures (nanoseconds vs date components). `String` is a parser. This forces users to know which type to use for what kind of schedule (e.g., 'every 5 seconds' vs 'every 5 days').
- Redundant comparison methods. These are logically equivalent to using the standard comparison operators (<, >) or the existing `compare` method. Providing specific boolean predicates for length comparison duplicates the intent of the comparison operators and adds API surface without distinct semantic value.
- Verbosity and inconsistency with standard library patterns. While distinct, having 8 separate methods for unit conversion is verbose. More importantly, `Interval` stores data as `nanoseconds: Double`. The existence of `asNanoseconds` alongside the property `nanoseconds` is redundant. Furthermore, Swift standard library conventions often prefer a single `components` or `description` approach, or extension-based conversions, rather than hardcoding every unit into the core type.