# Changelog

## Score

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

## Lenses

- Code Health 77 → 64 (-13.7)
- Architecture 97 → 97 (+0.0)
- Maturity 37 → 52 (+14.4)
- Readiness 58 → 58 (+0.0)
- Security 63 → 74 (+10.5)

## Resolved (4)

- Inconsistent parameter naming convention. One method uses descriptive parameter names (args, options) while the other uses generic placeholders (_args, _options).
- Inconsistent return intent naming. 'fetch_user_info' implies a complex object, while 'fetch_user_uuid' implies a single string. While distinct, the prefix 'fetch_user_' is repetitive and could be unified under a 'User' context or differentiated by action (e.g., 'get_user_info' vs 'get_user_uuid'). However, the primary inconsistency is the lack of a unified 'User' class or namespace, forcing these into ClassMethods.
- Off-boarding risk: anonymized user #1
- PR-triggered workflow grants a write-scoped token

## New (12)

- Duplicate intent: CLI delegates to BuildIpa, but the signatures differ significantly. CLI takes a single `args` object (likely a hash/struct), while the internal class takes separate `_args` and `_options`. This suggests the CLI layer is not just a thin wrapper but performs argument transformation, creating a disconnect between the public entry point and the actual implementation signature.
- Duplicate intent: Similar to IPA, the CLI `build_apk` takes `args` while the internal `BuildApk` class takes `args` and `options`. This inconsistency in how arguments are passed from the CLI layer to the business logic layer is repeated across build commands.
- Inconsistent naming and parameter structure: `Info.info` takes generic `args`, while specific parsers like `ipa_info`, `aab_info`, and `apk_info` take a specific `path` and `options`. This forces the user to understand that `info` is a dispatcher while the others are specific implementations, but the naming doesn't clearly distinguish between 'get general info' and 'parse specific file type'.
- Inconsistent naming convention: `Apk` uses `full_info` and `basic_info`, while `Ipa.App` uses `full_info`, `basic_info`, AND `info`. The presence of `info` in `Ipa.App` alongside `full_info` is redundant, whereas `Apk` does not have this redundancy. This inconsistency makes the API feel uneven across similar parser types.
- Off-boarding risk: anonymized user #1
- Orphaned file (lib/fir/cli.rb)
- Orphaned file (lib/fir/patches/concern.rb)
- Orphaned file (lib/fir/patches/try.rb)
- Orphaned file (lib/fir/util/build_common.rb)
- Orphaned file (lib/fir/util/mapping.rb)
- PR-triggered workflow grants a write-scoped token (.github/workflows/docker-image.yml)
- Redundant methods: `App.full_info` and `App.info` appear to do the same thing. In many Ruby/Rails contexts, `info` might be a shorthand for `full_info`, but having both exposed creates ambiguity about whether `info` returns a subset or the same data.