# Changelog

## Score

- CAI 63 → 54 (-8.8)
- Rubric changed (rubric-2026.10.1 → rubric-2026.10.5) — scores are not directly comparable.

## Lenses

- Code Health 100 → 75 (-24.2)
- Architecture 93 → 94 (+1.1)
- Maturity 49 → 34 (-15.1)
- Readiness 66 → 66 (+0.0)
- Security 75 → 75 (+0.0)

## Resolved (5)

- Documentation: no architecture or design documentation
- Inconsistent argument structure for creating comments. The high-level `Pronto.Bitbucket` class accepts a single `comment` object, while the lower-level `BitbucketClient` requires explicit decomposition into `slug`, `sha`, `body`, `path`, and `position`. This duplication of intent (creating a comment) with different signatures breaks the abstraction layer.
- Inconsistent naming for fetching comments based on context. `Github` uses `pull_comments` and `commit_comments` to distinguish context, while `Gitlab` uses `commit_comments` and `pull_comments`. While the names are similar, the underlying API semantics differ (GitLab often uses a single endpoint with different scopes or different object types). More critically, `Pronto.Bitbucket` has `pull_comments(sha)` and `commit_comments(sha)`, but `BitbucketClient` has `pull_comments(slug, pull_id)` and no direct `commit_comments` equivalent exposed in the same way (it has `create_commit_comment`). This creates a fragmented experience for implementing new providers.
- Inconsistent parameter semantics for retrieving pull comments. Bitbucket and BitbucketServer clients use a commit SHA (`sha`) to fetch comments, whereas the dedicated `BitbucketClient` uses a `slug` and `pull_id`. This forces consumers to know the specific implementation details of each client to construct the correct arguments, rather than a unified interface.
- PR-triggered workflow without a permissions block

## New (10)

- Inconsistent parameter semantics for retrieving pull comments. Bitbucket and BitbucketServer clients use a commit SHA (`sha`) to fetch comments, whereas the dedicated `BitbucketClient` uses a `slug` and `pull_id`. This forces consumers to know the specific implementation details of the client to call the correct method signature, rather than a unified interface.
- Orphaned file (lib/pronto/cli.rb)
- Orphaned file (lib/pronto/config.rb)
- Orphaned file (lib/pronto/formatter/git_formatter.rb)
- Orphaned file (lib/pronto/git/repository.rb)
- Orphaned file (lib/pronto/github.rb)
- Orphaned file (lib/pronto/gitlab.rb)
- PR-triggered workflow without a permissions block (.github/workflows/pronto.yml)
- PR-triggered workflow without a permissions block (.github/workflows/specs.yml)
- While the method name `pull_comments` is consistent, the semantic meaning of the argument `sha` is ambiguous and likely inconsistent across providers. For GitHub/GitLab, comments are often tied to a specific commit or pull request ID, not just a SHA. For Bitbucket, it might be the same. However, `Pronto.Github` also has `create_pull_comment(comment)` while `Pronto.Gitlab` has `create_pull_request_review(comments)`. The naming difference (`pull_comment` vs `pull_request_review`) suggests different underlying API models that are not abstracted away, leading to inconsistent usage patterns for similar actions.