# Changelog

## Score

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

## Lenses

- Code Health 99 → 75 (-23.9)
- Architecture 100 → 100 (+0.0)
- Maturity 53 → 45 (-7.7)
- Readiness 70 → 70 (+0.0)
- Security 88 → 81 (-6.3)

## Resolved (5)

- Ambiguous naming for command execution contexts. `run_command` exists on the Backend (low-level execution), Recipe context (DSL usage), and Resource context (DSL usage). While the domains differ, the name `run_command` in DSL contexts is misleading as it implies direct shell execution rather than resource definition or helper utility, creating confusion with the backend's actual execution method.
- Inconsistent terminology for file transfer operations. `Itamae.Backend` uses `receive_file` and `send_file`, while `Specinfra.Backend` (which Itamae likely delegates to for some operations) uses `receive_file`. The directionality is confusing: `send_file` implies the caller sends, `receive_file` implies the caller receives. In `Itamae.Backend.Base`, `receive_file(src, dst)` suggests the backend receives from src, but `send_file` suggests the backend sends. This creates a mental model mismatch between 'sending' and 'receiving' relative to the backend vs the user.
- Off-boarding risk: anonymized user #1
- Overloaded `run` method across different layers of abstraction. `Recipe.run`, `RecipeChildren.run`, and `Runner.run` all perform execution but at vastly different scopes (single recipe, group of recipes, full orchestration). This makes it difficult to infer the scope of execution from the method name alone without understanding the object's state.
- Workflow holding a long-lived secret is unscoped

## New (16)

- Ambiguous lookup methods for recipes. `Recipe.find_recipe_in_gem` and `RecipeChildren.find_recipe_by_path` both resolve recipe locations, but the distinction between 'in gem' and 'by path' is not immediately clear from the signature alone. It is unclear if `find_recipe_by_path` is a general resolver that handles gems, or if `find_recipe_in_gem` is a specialized fallback. This suggests a potential duplication of lookup logic or a confusing split of responsibilities between the `Recipe` class and `RecipeChildren`.
- Off-boarding risk: anonymized user #1
- Orphaned file (lib/itamae/backend.rb)
- Orphaned file (lib/itamae/cli.rb)
- Orphaned file (lib/itamae/logger.rb)
- Orphaned file (lib/itamae/recipe.rb)
- Orphaned file (lib/itamae/resource/base.rb)
- Orphaned file (lib/itamae/resource/gem_package.rb)
- Orphaned file (lib/itamae/resource/git.rb)
- Orphaned file (lib/itamae/resource/http_request.rb)
- Orphaned file (lib/itamae/resource/remote_directory.rb)
- Orphaned file (lib/itamae/resource/user.rb)
- Orphaned file (lib/itamae/runner.rb)
- Redundant/Confusing naming for file transfer operations. `Itamae.Backend.Base` exposes both `receive_file` and `send_file`, while `Specinfra.Backend.*` classes only expose `receive_file`. In the context of a configuration management tool running on a target, 'receive' usually implies receiving from the client (uploading to target), while 'send' implies sending to the client (downloading from target). The presence of both verbs in Itamae's base backend, contrasted with the singular 'receive' in Specinfra (which Itamae likely delegates to), creates ambiguity about directionality and intent. Specifically, `send_file` in Itamae likely does what `receive_file` in Specinfra does (or vice versa depending on perspective), but the naming is not aligned across the abstraction layers.
- Workflow holding a long-lived secret is unscoped (.github/workflows/test.yml)
- Workflow holding a long-lived secret is unscoped (.github/workflows/test_main.yml)

## Changes since last survey

- 1 commits — 1 feature/other, 0 fixes

## By area

- (repo) — 1 commit

## Notable commits

- change: Merge pull request #455 from itamae-kitchen/dependabot/github_actions/ruby/setup-ruby-1.326.0