# Changelog

## Score

- CAI 66 → 61 (-4.6)
- Rubric changed (rubric-2026.10.1 → rubric-2026.10.5) — scores are not directly comparable.

## Lenses

- Code Health 98 → 75 (-23.3)
- Architecture 100 → 100 (+0.0)
- Maturity 54 → 49 (-5.3)
- Readiness 65 → 65 (+0.0)
- Security 78 → 78 (+0.0)

## Resolved (6)

- Duplicate extension methods on different types with identical signatures and intent. While technically distinct types, exposing `deep_clone` on both `Array` and `Hash` suggests a lack of a unified utility module or mixin for deep cloning, leading to API fragmentation.
- Off-boarding risk: anonymized user #1
- Redundant definition of the same property. Similar to `allow_duplicates`, `interactive_resolution` is defined as both a Property and a Method, creating API ambiguity.
- Redundant definition of the same property. The type `Settings` defines `allow_duplicates` as both a Property and a Method. In most languages, this is either a conflict or implies one is a getter and one is a setter, but the signature `allow_duplicates()` suggests a method call, while `Property: allow_duplicates` suggests direct access. This creates confusion on how to access the value.
- Semantic overlap in conflict resolution. `resolve_conflicts` likely handles the output of a merge, while `three_way_merge` performs the merge. However, the naming is inconsistent with standard Git-like terminology where 'merge' often implies conflict resolution or at least the attempt. If `resolve_conflicts` is a post-merge step, the naming is acceptable, but if `three_way_merge` can also resolve conflicts, the distinction is unclear. More critically, `resolve_conflicts` takes a `changes_output_path`, implying it operates on a diff/patch file, whereas `three_way_merge` takes project paths. This suggests two different workflows for similar outcomes (resolving project state), which may confuse users.
- Workflow token permissions not restricted

## New (9)

- Ambiguous workflow separation. `apply_change_to_project` suggests a single operation, but `resolve_conflicts` is a separate step. It is unclear if `apply_change_to_project` handles conflicts internally or if it always delegates to `resolve_conflicts`. The naming does not clearly indicate if these are sequential steps in a single pipeline or independent operations.
- Duplicate utility method on core types. Both Array and Hash expose a `deep_clone` method. While these operate on different types, the duplication suggests a lack of a shared mixin or base class for deep cloning logic, leading to code duplication and inconsistent maintenance.
- Off-boarding risk: anonymized user #1
- Orphaned file (lib/kintsugi/cli.rb)
- Orphaned file (lib/kintsugi/conflict_resolver.rb)
- Orphaned file (lib/kintsugi/merge.rb)
- Redundant method definitions alongside properties. The `Settings` type defines `allow_duplicates` and `interactive_resolution` as both Properties and Methods. In most languages, if a property exists, a separate method with the same name is either redundant (if it just returns the property) or confusing (if it has side effects).
- Workflow token permissions not restricted (.github/workflows/release.yml)
- Workflow token permissions not restricted (.github/workflows/tests.yml)