# Changelog

## Score

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

## Lenses

- Code Health 71 → 61 (-10.8)
- Architecture 69 → 69 (+0.0)
- Maturity 49 → 55 (+6.6)
- Readiness 67 → 69 (+1.7)
- Security 79 → 79 (+0.0)

## Resolved (1)

- Workflow token permissions not restricted

## New (6)

- Ambiguous naming for CI-specific checks. `isTag` likely refers to the current CI environment's tag status, while `isTravisTag` explicitly targets Travis CI. This creates confusion about whether `isTag` is a generic abstraction or just an alias for Travis, and duplicates the intent of checking tag status across different contexts.
- Inconsistent naming convention for CI-specific data retrieval. While `isTravisTag` and `isTravisBranch` (implied by `isTravisSecure`/`isTravisTag` pattern) would be consistent, the presence of `travisTag()` and `travisBranch()` as raw data getters alongside boolean checks suggests a mix of 'is' and 'get' patterns. More critically, if `releaseTag()` and `currentBranch()` exist as generic versions, having `travisTag()` and `travisBranch()` as specific overrides creates redundancy without clear distinction in purpose (e.g., does `releaseTag()` return the tag for the current CI or a generic one?).
- Redundant boolean checks. `isSecure()` likely delegates to or is equivalent to `isTravisSecure()` given the context of the plugin. This forces users to know which method to call for the same logical state.
- Workflow token permissions not restricted (.github/workflows/ci.yml)
- Workflow token permissions not restricted (.github/workflows/release-drafter.yml)
- Workflow token permissions not restricted (.github/workflows/release.yml)