# Changelog

## Score

- CAI 60 → 58 (-2.4)
- Rubric changed (rubric-2026.10.1 → rubric-2026.10.5) — scores are not directly comparable.

## Lenses

- Code Health 99 → 75 (-23.9)
- Architecture 69 → 69 (+0.0)
- Maturity 59 → 54 (-4.7)
- Readiness 51 → 51 (+0.0)
- Security 79 → 79 (+0.5)

## Resolved (3)

- Ambiguous ownership of the 'lookup' operation. `LoadPath.find` and `Resolver.resolve` both take a logical path and return an asset (or nil). The API exposes both the low-level collection (`LoadPath`) and the high-level interface (`Resolver`) with nearly identical signatures for the same intent (finding an asset by name).
- Redundant methods for adding entries to the manifest. One accepts an Asset object, the other a ManifestEntry. This forces the caller to know whether to construct an entry or pass the asset directly, creating two paths for the same logical operation.
- Workflow token permissions not restricted

## New (3)

- Inconsistent naming for the primary lookup operation. `LoadPath` uses `find`, while its consumers (`Resolver`) use `resolve`. While these are different types, the semantic action 'look up an asset by logical path' is named differently across the API surface, suggesting a lack of a unified interface or consistent verb choice for asset retrieval.
- Redundant methods for adding entries to the manifest. `push_asset` likely wraps an asset into an entry and calls `push`, or performs the same logical operation. Having two distinct methods for the same intent (adding a manifest entry) creates confusion about which to use.
- Workflow token permissions not restricted (.github/workflows/ci.yml)

## Architecture

- 0 containers · 1 bounded contexts · 0 dependency edges (baseline)