# Changelog

## Score

- CAI 63 → 66 (+3.0)

## Lenses

- Code Health 98 → 98 (+0.0)
- Architecture 97 → 97 (+0.0)
- Maturity 52 → 61 (+8.2)
- Readiness 57 → 57 (+0.0)
- Security 80 → 80 (+0.0)

## Resolved (5)

- Inconsistent parameter types for margin. The API mixes `UIEdgeInsets` (iOS-specific, physical) with `NSDirectionalEdgeInsets` (iOS 11+, logical) and raw `CGFloat`/`FPercent` values. This forces users to choose between physical and logical insets without a unified abstraction. Additionally, having 10 overloads for margin is excessive and hard to maintain.
- Redundant directional properties with overlapping intent. `left`/`right` and `start`/`end` are semantically similar (logical vs physical axes), but exposing both as distinct methods creates confusion. Similarly, `top`/`bottom` are physical, while `start`/`end` are logical. Users may not know which to use for RTL support. Furthermore, `horizontally` and `vertically` appear to be aliases or subsets of setting left/right/top/bottom simultaneously, creating further redundancy.
- Redundant size setting methods. `size(CGFloat)` sets both width and height to the same value, which is a common convenience, but `size(CGSize?)` allows setting both independently. However, `width` and `height` are already available. The existence of `size(CGFloat)` is fine, but `size(CGSize?)` overlaps with setting width and height separately. More importantly, `basis` is a flex-specific property that also affects size, which might confuse users about when to use `width`/`height` vs `basis`.
- Same inconsistency as margin: mixing `UIEdgeInsets` and `NSDirectionalEdgeInsets` with raw numeric types. This creates a fragmented API where the user must know which edge inset type to use for logical vs physical padding.
- Workflow token permissions not restricted

## New (1)

- Workflow token permissions not restricted (.github/workflows/github-actions-ci.yml)