# Changelog

> **This is the PUBLIC form of this artifact. Findings are listed in full, but the details of SECURITY findings — which rule fired, in which file, on which line, and how to fix it — are deliberately withheld, and any secret-scanner results are excluded entirely. Where detail is absent here it was REMOVED FOR PUBLICATION; it is not missing from the analysis. The complete artifact is available from the repository owner.**

## Score

- CAI 47 → 41 (-6.0)
- Rubric changed (rubric-2026.10.1 → rubric-2026.10.5) — scores are not directly comparable.

## Lenses

- Code Health 98 → 72 (-25.6)
- Architecture 69 → 69 (+0.0)
- Maturity 49 → 43 (-5.9)
- Readiness 45 → 45 (+0.0)
- Security 98 → 97 (-1.0)
- Accessibility 37 → 28 (-8.2)

## Resolved (3)

- Duplicate intent across layers. Author.commits_sum_by_date() calculates the data, while AuthorsCharts.commits_sum_by_author_by_date() appears to do the same calculation but is located in the View/Chart layer. This violates the separation of concerns, as the View layer should consume data, not calculate it.
- Inconsistent command execution API surface. Repo exposes both a raw runner and a parser, while a dedicated CommandRunner class exists. Users must choose between Repo.run (which likely returns raw output) and Repo.run_and_parse (which implies parsing), but the existence of CommandRunner suggests the parsing logic is separated elsewhere, creating confusion about where execution vs parsing responsibilities lie.
- Inconsistent naming convention for data formats. Some methods return arrays (e.g., by_hour_array, by_wday_array, by_month_array) while others return hashes or other structures (e.g., by_date, by_hour, by_wday). The distinction between 'array' and non-array suffixes is not immediately obvious from the method names alone without documentation, and it breaks the pattern of having a single canonical method per dimension.

## New (7)

- Duplication of aggregation logic between Domain and View layers. `Activity` provides raw aggregation methods (e.g., `by_date`), while `ActivityCharts` provides identical methods (e.g., `activity_by_date`) that likely perform the same grouping. This violates DRY principles and creates two sources of truth for the same data transformation.
- Inconsistent naming and scope for author-based aggregations. `Repo` has a method for counting commits by author, while the View layer has a method for summing commits by author by date. The naming conventions differ (`commits_count` vs `commits_sum`), and the scope (total count vs time-series sum) is not clearly distinguished by naming, leading to potential confusion about which method to use for specific reporting needs.
- Medium: security finding (details withheld)
- Orphaned file (lib/git_stats/git_data/repo.rb)
- Orphaned file (lib/git_stats/stats_view/charts/chart.rb)
- Orphaned file (lib/git_stats/stats_view/view.rb)
- Redundant execution interfaces. Repo exposes both a direct `run` and a `run_and_parse` method, while also exposing a dedicated `CommandRunner` component. The `CommandRunner` class exists to encapsulate execution logic, but `Repo` duplicates this capability directly, creating confusion about whether to use the component or the direct method.

## Architecture

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