# Changelog

## Score

- CAI 55 → 58 (+2.8)
- Rubric changed (rubric-2026.10.1 → rubric-2026.10.5) — scores are not directly comparable.

## Lenses

- Code Health 74 → 62 (-12.3)
- Architecture 97 → 97 (-0.3)
- Maturity 35 → 46 (+11.4)
- Readiness 69 → 69 (+0.0)
- Security 75 → 75 (+0.0)

## Resolved (6)

- Ambiguous relationship between TTY detection and output truncation. `tty_output?` checks if output is a TTY, while `truncate_output?` likely determines if output should be truncated. These are closely related concepts (truncation usually depends on TTY status), but having separate methods with similar semantic weight suggests potential duplication of logic or unclear responsibility.
- Excessive and redundant methods for determining terminal width. `terminal_columns` (property) and `terminal_width` (method) likely return the same value. `dynamic_width` and its platform-specific helpers (`dynamic_width_stty`, `dynamic_width_tput`) expose internal implementation details that should be encapsulated.
- Inconsistent naming and granularity in exception display methods. `display_exception_details` is vague compared to the more specific `display_exception_message_details` and `display_exception_backtrace`. It is unclear if `display_exception_details` is a composite method or a duplicate of one of the others.
- Inconsistent naming convention for filtering methods. Ruby convention typically uses `!` for destructive operations or methods that raise errors, but `existing!` likely filters the list to only existing files, similar to `existing`. The distinction between `existing` and `existing!` is not clear from signatures and may be confusing.
- Off-boarding risk: anonymized user #1
- Redundant and confusingly named methods for loading the Rakefile. `Rake.load_rakefile` is a top-level convenience, while `Application` has two distinct methods `load_rakefile` and `raw_load_rakefile` that likely perform similar or overlapping loading logic (one possibly with preprocessing/normalization, the other raw). The distinction is not clear from signatures alone, creating ambiguity about which to use.

## New (18)

- Confusingly similar predicates. `tty_output?` checks if the output is a TTY, while `truncate_output?` likely checks if truncation should occur (often based on TTY status). Having two separate boolean checks for what might be logically coupled or derived properties forces the user to understand the internal dependency between 'is TTY' and 'should truncate'.
- Inconsistent bang notation usage. In Ruby, `!` often implies mutation or a more aggressive action. Here, `existing` and `existing!` likely filter the list to only existing files. If `existing!` mutates the receiver and `existing` returns a new list, this is standard. However, without seeing bodies, the distinction is unclear compared to other methods like `sub` vs `sub!`. If they do the same thing (filter), one is redundant.
- Off-boarding risk: anonymized user #1
- Orphaned file (lib/rake.rb)
- Orphaned file (lib/rake/cpu_counter.rb)
- Orphaned file (lib/rake/dsl_definition.rb)
- Orphaned file (lib/rake/ext/string.rb)
- Orphaned file (lib/rake/file_list.rb)
- Orphaned file (lib/rake/file_utils.rb)
- Orphaned file (lib/rake/file_utils_ext.rb)
- Orphaned file (lib/rake/linked_list.rb)
- Orphaned file (lib/rake/packagetask.rb)
- Orphaned file (lib/rake/task.rb)
- Orphaned file (lib/rake/task_arguments.rb)
- Orphaned file (lib/rake/task_manager.rb)
- Orphaned file (lib/rake/thread_pool.rb)
- Overly granular and inconsistent display methods. There are four distinct methods for displaying parts of an exception, with no clear pattern (e.g., `display_exception_details` vs `display_exception_message_details`). This suggests a lack of abstraction for exception reporting.
- Redundant and ambiguous loading methods. `Rake.load_rakefile` is a convenience wrapper, but `Application` exposes both `load_rakefile` and `raw_load_rakefile` without clear distinction in naming convention (e.g., is `raw` just bypassing some hook?). Additionally, `Application.init` also appears to handle setup/loading logic, creating confusion about the entry point for loading the Rakefile.

## Changes since last survey

- 6 commits — 6 feature/other, 0 fixes

## By area

- (repo) — 3 commits
- .github/workflows — 3 commits

## Notable commits

- change: Bump ruby/setup-ruby from 1.327.0 to 1.328.0
- change: Bump ruby/setup-ruby from 1.328.0 to 1.329.0
- change: Bump step-security/harden-runner from 2.21.1 to 2.22.1
- change: Merge pull request #770 from ruby/dependabot/github_actions/ruby/setup-ruby-1.328.0
- change: Merge pull request #771 from ruby/dependabot/github_actions/step-security/harden-runner-2.22.1
- change: Merge pull request #772 from ruby/dependabot/github_actions/ruby/setup-ruby-1.329.0