# Changelog

## Score

- CAI 52 → 55 (+2.8)
- Rubric changed (rubric-2026.10.1 → rubric-2026.10.5) — scores are not directly comparable.

## Lenses

- Code Health 72 → 61 (-11.0)
- Architecture 69 → 69 (+0.0)
- Maturity 30 → 41 (+11.1)
- Readiness 71 → 71 (+0.0)
- Security 90 → 90 (+0.0)

## Resolved (12)

- Documentation: no installation or build instructions (README.md)
- Duplicate lifecycle method with identical signature across related types. Both `Base` and `Progress` expose a `start` method that appears to perform the same initialization action, creating ambiguity about which type should be used for state management.
- Duplicate lifecycle method with identical signature. Both `Base` and `Progress` expose a `finish` method, mirroring the `start` inconsistency and suggesting redundant state management logic.
- Duplicate lifecycle method with identical signature. Both `Base` and `Progress` expose a `reset` method.
- Duplicate method across strategy implementations. While this is a common pattern for strategy patterns, the lack of a shared interface or explicit documentation that these are interchangeable implementations can lead to confusion. However, this is less severe than the `Base`/`Progress` duplication.
- Duplicate mutation method with identical signature. Both `Base` and `Progress` expose `decrement`.
- Duplicate mutation method with identical signature. Both `Base` and `Progress` expose `increment`.
- Duplicate query method with identical signature across different domains (Progress vs Timer). While domains differ, the naming `stopped?` is ambiguous when both a progress bar and a timer can be stopped. It is unclear if `stopped?` refers to the progress bar being halted or the timer being stopped.
- Duplicate query method with identical signature. Both `Base` and `Progress` expose `finished?`.
- Duplicate setter with identical signature. Both `Base` and `Progress` expose `progress=`.
- Duplicate setter with identical signature. Both `Base` and `Progress` expose `total=`.
- Workflow token permissions not restricted

## New (17)

- Combinatorial explosion of methods: Four methods exist for percentage display, varying by justification and precision. This is a classic API inconsistency where simple variations are exposed as distinct methods rather than parameters.
- Duplicate lifecycle control: Both `Base` and `Progress` expose a `reset` method. This suggests duplicated state reset logic or ambiguous responsibility for what 'reset' entails (does it reset the timer? the progress count? both?).
- Duplicate lifecycle control: Both `Base` and `Progress` expose a `start` method with identical signatures. Since `ProgressBar` inherits from `Base` and likely composes or delegates to `Progress` for state management, having two public `start` methods creates ambiguity about which state machine is being triggered.
- Duplicate lifecycle control: Similar to `start`, both `Base` and `Progress` expose a `finish` method. This redundancy confuses users regarding whether calling `finish` on the bar updates the progress tracker, the timer, or both.
- Duplicate state mutation: Both `Base` and `Progress` expose `increment` and `decrement`. Since `ProgressBar` is the public-facing class inheriting from `Base`, users might call `increment` on the base class, unaware it might not update the `Progress` component's internal state if delegation is missing or inconsistent.
- Duplicate state mutation: Both `Base` and `Progress` expose a setter for `progress`. This creates two entry points for the same state, risking inconsistency if one setter updates the other and the other does not.
- Duplicate state mutation: Both `Base` and `Progress` expose a setter for `total`. Same risk as `progress=`.
- Fragmented API for similar intent: There are five distinct methods for calculating/displaying estimated time, each handling a different edge case or format. This forces users to choose the correct method based on internal state knowledge rather than providing a single flexible method.
- Inconsistent interface implementation: `NonTty` and `Tty` implement `clear()`, but `Null` also implements `clear()`. While this might be intentional for interface consistency, `Null` typically implies no-op behavior. If `Null` is a valid output strategy, it should be clear that `clear` is a no-op. However, the bigger issue is that `NonTty` and `Tty` have divergent method sets (e.g., `NonTty` has `last_update_length` and `bar_update_string`, while `Tty` does not).
- Inconsistent naming and parameterization: One method takes a format string, the other implies precision handling. This suggests two different ways to achieve similar output formatting.
- Orphaned file (lib/ruby-progressbar/base.rb)
- Orphaned file (lib/ruby-progressbar/components/time.rb)
- Orphaned file (lib/ruby-progressbar/progress.rb)
- Workflow token permissions not restricted (.github/workflows/labels.yml)
- Workflow token permissions not restricted (.github/workflows/linting.yml)
- Workflow token permissions not restricted (.github/workflows/locking.yml)
- Workflow token permissions not restricted (.github/workflows/testing.yml)