# Changelog

## Score

- CAI 61 → 62 (+0.3)

## Lenses

- Code Health 95 → 95 (+0.0)
- Architecture 93 → 91 (-1.3)
- Maturity 51 → 52 (+0.8)
- Readiness 55 → 55 (+0.0)
- Security 72 → 72 (+0.0)
- Performance 100 → 100 (+0.0)

## Resolved (7)

- Ambiguous or redundant method overloads for `animation`. `UIBinding` has two distinct methods named `animation` that accept different platform-specific animation types (`AppKitAnimation` vs `UIKitAnimation`). While technically distinct due to parameter types, this can be confusing for users who might expect a single `animation(Animation)` method if a common `Animation` protocol existed, or it highlights the lack of a unified `Animation` type in the public API.
- Documentation: no installation or build instructions (README.md)
- Documentation: no usage examples (README.md)
- Inconsistent animation API surface between AppKit and UIKit. AppKit exposes a single, simplified `animate` method that abstracts away platform-specific parameters (like delay, spring damping, options). UIKit exposes multiple overloads exposing low-level UIKit animation parameters. This forces users to handle platform-specific logic differently or creates a disparity in feature parity.
- Inconsistent method naming for lifecycle updates. AppKit uses `updateNSView` while UIKit uses `updateUIView`. While this mirrors the underlying `NSView` vs `UIView` types, it breaks symmetry in the protocol-like structure of the library, requiring developers to remember different method names for the same conceptual lifecycle event.
- Off-boarding risk: anonymized user #1
- Workflow token permissions not restricted

## New (5)

- Off-boarding risk: anonymized user #1
- Orphaned file (Sources/AppKitNavigation/UITransaction.swift)
- Workflow token permissions not restricted (.github/workflows/ci.yml)
- Workflow token permissions not restricted (.github/workflows/format.yml)
- Workflow token permissions not restricted (.github/workflows/release.yml)