# Changelog

## Score

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

## Lenses

- Code Health 100 → 76 (-24.2)
- Architecture 69 → 69 (+0.0)
- Maturity 50 → 49 (-0.5)
- Readiness 70 → 70 (+0.0)
- Security 71 → 71 (+0.0)

## Resolved (3)

- Inconsistent naming convention for inverse operations. While 'link' and 'unlink' are standard Unix terms, other pairs in the API use different patterns (e.g., 'track' vs no explicit 'untrack', 'destroy' vs no explicit 'create'). Specifically, 'destroy' is used for removal of a castle, while 'unlink' is used for removing a link. This mixes domain concepts (the castle itself vs the symlink/link).
- PR-triggered workflow without a permissions block
- Redundant abstraction layer with divergent signatures. CLI.clone acts as a high-level orchestrator, while GitActions.git_clone is a low-level wrapper. The parameters differ significantly (uri/destination vs repo/config), suggesting they handle different concerns or that the CLI method delegates to a different internal logic than the direct Git action. This creates confusion about whether a user should call the CLI method or the Git action directly.

## New (3)

- Inconsistent naming convention for state-changing operations. 'link' and 'unlink' are standard Unix terms, but other operations use 'track'/'destroy' or 'commit'/'push'. While 'link/unlink' is internally consistent with each other, it is inconsistent with the broader project's naming if 'track' is used for similar registration concepts. However, looking at 'track(file, castle)' vs 'link(name)', 'track' seems to be for adding files to a castle, while 'link' is for installing the castle. This is a domain distinction, not a redundancy. No inconsistency here.
- PR-triggered workflow without a permissions block (.github/workflows/ci.yml)
- Redundant abstraction layer with divergent signatures. CLI.clone acts as a high-level orchestrator, while GitActions.git_clone is a low-level git wrapper. The parameters differ significantly (uri/destination vs repo/config), suggesting the CLI method does not simply delegate to the Git action but performs its own logic, or the Git action is not the sole implementation of cloning. This creates confusion about where the actual cloning logic resides and makes testing/mocking difficult.
