# Changelog

## Score

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

## Lenses

- Code Health 81 → 64 (-17.1)
- Architecture 89 → 89 (+0.0)
- Maturity 54 → 48 (-6.9)
- Readiness 67 → 67 (+0.0)
- Security 90 → 88 (-1.6)
- Accessibility 66 → 66 (+0.0)

## Resolved (9)

- Ambiguous method naming with different signatures. 'api' and 'api!' are often used to denote destructive vs non-destructive operations, but here they have completely different argument structures (path/method vs just desc/options). This is confusing for DSL users.
- Duplicate intent. 'param' and 'property' have identical signatures and likely identical functionality (defining a parameter/property in the schema). This forces users to choose between two names for the same concept.
- Duplicate public API surface between Apipie and Application. The Application class exposes the same serialization methods (to_json, to_swagger_json) with nearly identical signatures as the top-level Apipie module. This creates confusion about whether to call the module method or the Application instance method.
- Further sole-owners (lower concentration)
- Inconsistent naming pattern for validation methods. One uses 'api_base_url_version_valid?' and the other 'app_info_version_valid?'. While the subjects differ, the pattern 'X_version_valid?' is not applied to other potential validation methods (e.g., no 'checksum_version_valid?'), suggesting an arbitrary naming convention.
- Inconsistent verb spelling. 'analyse' (British) is used for env, controller, and response, while 'analyze' (American) is used for functional_test. This is a clear inconsistency in the same class.
- Off-boarding risk: anonymized user #1
- Signature inconsistency for schema generation. The Apipie module method does not accept a 'version' argument, while the Application class method does. This implies different default behaviors or error handling for versioned APIs.
- Workflow token permissions not restricted

## New (29)

- Duplicate API surface between Apipie module and Application class. Both expose identical methods for generating JSON and Swagger output. The `Apipie` module methods appear to be thin wrappers or duplicates of the `Application` class methods, creating confusion about which entry point to use.
- Inconsistent naming of configuration validation methods. The methods `validate_value`, `validate_presence`, and `validate_key` are instance methods on `Configuration` that likely perform specific checks. However, they are named as actions rather than predicates (e.g., `validate_value?` or `is_value_valid?`), which is inconsistent with Ruby conventions for boolean checks, especially when compared to `reload_controllers?` and `force_dsl?` which use the `?` suffix.
- Off-boarding risk: anonymized user #1
- Orphaned file (app/controllers/apipie/apipies_controller.rb)
- Orphaned file (lib/apipie-rails.rb)
- Orphaned file (lib/apipie/apipie_module.rb)
- Orphaned file (lib/apipie/application.rb)
- Orphaned file (lib/apipie/configuration.rb)
- Orphaned file (lib/apipie/extractor.rb)
- Orphaned file (lib/apipie/extractor/collector.rb)
- Orphaned file (lib/apipie/extractor/recorder.rb)
- Orphaned file (lib/apipie/extractor/writer.rb)
- Orphaned file (lib/apipie/generator/swagger/config.rb)
- Orphaned file (lib/apipie/generator/swagger/method_description/parameters_service.rb)
- Orphaned file (lib/apipie/generator/swagger/param_description/builder.rb)
- Orphaned file (lib/apipie/generator/swagger/param_description/type.rb)
- Orphaned file (lib/apipie/generator/swagger/warning.rb)
- Orphaned file (lib/apipie/method_description.rb)
- Orphaned file (lib/apipie/param_description.rb)
- Orphaned file (lib/apipie/resource_description.rb)
- …and 9 more

## Architecture

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