# Changelog

## Score

- CAI 67 → 64 (-2.9)
- Rubric changed (rubric-2026.10.1 → rubric-2026.10.5) — scores are not directly comparable.

## Lenses

- Code Health 99 → 75 (-23.9)
- Architecture 86 → 98 (+12.8)
- Maturity 62 → 58 (-4.4)
- Readiness 62 → 62 (+0.0)
- Security 70 → 70 (+0.0)

## Resolved (9)

- Ambiguous terminology. `needy_flags` is non-standard terminology for CLI flags. It likely means `required_flags` or `flags_with_dependencies`. Having both `needy_flags` and `required_flags` suggests they might be different, but the naming is confusing.
- Inconsistent filtering semantics. Same issue as Commands and Flags. Redundant naming between `public` and `visible` for environment variables.
- Inconsistent filtering semantics. Same issue as Commands. `flags` vs `public_flags` vs `visible_flags` creates ambiguity about what each returns. `public` and `visible` are often synonyms in CLI contexts, leading to potential redundancy.
- Inconsistent filtering semantics. `commands` likely returns all, but it's unclear if it includes hidden/private ones. `public_commands` and `visible_commands` suggest different filtering criteria (e.g., visibility vs. API exposure). `deep_commands` adds recursion. The distinction between 'public' and 'visible' is not immediately obvious and risks duplication if they filter the same set.
- Inconsistent naming for argument filtering. `args` is vague. `default_args`, `required_args`, `whitelisted_args` are specific. The relationship between `args` and these subsets is unclear.
- PR-triggered workflow without a permissions block
- Projects may be oversized for their cohesion
- Redundant methods with ambiguous distinction. Similar to SettingsCompletions, `validate?` likely duplicates `validate` or acts as a boolean check. In Ruby, `validate` usually performs the action and may raise or return status, while `validate?` implies a non-mutating check. Having both suggests unclear intent or duplication.
- Redundant methods with ambiguous distinction. `completions?` in Ruby typically denotes a predicate (boolean), but here it likely returns the same data as `completions` or a subset. Having both without clear semantic distinction (e.g., one for checking existence, one for fetching) is confusing.

## New (8)

- Ambiguous naming for validation methods. `validate()` and `validate?()` likely perform the same or very similar validation logic, with the `?` suffix potentially indicating a boolean return or a side-effect-free check, but the distinction is unclear from signatures alone.
- Duplicated block (16 lines × 2) (lib/bashly/libraries/render/markdown/render.rb)
- Overlapping retrieval methods for commands. `commands()`, `deep_commands()`, `public_commands()`, and `visible_commands()` all retrieve collections of commands but with different filtering/scoping logic. While distinct, the naming convention is inconsistent (some imply depth, some visibility, some access level) without a clear hierarchy or base method.
- PR-triggered workflow without a permissions block (.github/workflows/static-analysis.yml)
- PR-triggered workflow without a permissions block (.github/workflows/test.yml)
- Proliferation of filtered environment variable lists. Same pattern as flags and commands, leading to API bloat and potential confusion about which list to use.
- Proliferation of filtered flag lists. Similar to commands, there are multiple methods returning subsets of flags with unclear distinctions between 'public', 'visible', and 'default'.
- Redundant accessor methods for boolean settings. The class provides both a generic `enabled?(feature)` method and specific `enable_<feature>()` methods for each boolean setting. This duplicates intent and API surface.