# Changelog

> **This is the PUBLIC form of this artifact. Findings are listed in full, but the details of SECURITY findings — which rule fired, in which file, on which line, and how to fix it — are deliberately withheld, and any secret-scanner results are excluded entirely. Where detail is absent here it was REMOVED FOR PUBLICATION; it is not missing from the analysis. The complete artifact is available from the repository owner.**

## Score

- CAI 55 → 51 (-4.2)
- Rubric changed (rubric-2026.10.1 → rubric-2026.10.5) — scores are not directly comparable.

## Lenses

- Code Health 83 → 63 (-20.3)
- Architecture 86 → 87 (+1.4)
- Maturity 65 → 62 (-3.6)
- Readiness 79 → 79 (+0.0)
- Security 73 → 76 (+3.0)
- Accessibility 35 → 31 (-3.5)
- Performance 85 → 85 (+0.0)

## Resolved (6)

- Ambiguous distinction between parsing sources. It is unclear if `parse` handles file paths and `parse_string` handles raw strings, or if they are redundant entry points for different input types. Without clear naming convention (e.g., `parse_files` vs `parse_string`), users may confuse which method to use for string inputs.
- Documentation: written for insiders (docs/WhatsNew.md)
- Duplicate functionality across types. Both `CodeObjects.Base` and `Docstring` have `has_tag?(name)`. Since `Docstring` is often associated with a `CodeObject`, users might be confused about which one to query. If `CodeObject` delegates to its docstring, this is fine, but if both are independent, it's redundant.
- Inconsistent naming for CLI command execution. Most CLI commands use `run(args)`, but `YRI` (a CLI tool) also uses `run(args)`. However, `YARD.CLI.CommandParser` uses `run(args)` while `YARD.CLI.Config` uses `run(args)`. The inconsistency is subtle but present in the hierarchy: `YARD.CLI.Command` is a base class/interface pattern, but `YRI` is a standalone class that mimics this pattern. More critically, `YARD.CLI.Config` has both `run(args)` and `description()`, while other commands like `Help` only have `run(args)` and `description()`. The main issue is that `YARD.CLI.Config` seems to be a configuration object that also acts as a command, whereas `YARD.CLI.Config` in `YARD.CLI.Config` namespace is distinct from `YARD.Config`. This creates confusion between the configuration *data* object (`YARD.Config`) and the configuration *CLI command* (`YARD.CLI.Config`).
- Inconsistent parameter naming and intent for docstring access. The getter `docstring(locale)` takes an optional locale, while the setter `docstring=(comments)` takes raw comments. This asymmetry is confusing: one expects a parsed Docstring object (or locale), the other expects raw text. It is unclear if `docstring` returns a `Docstring` object or a string.
- Workflow token permissions not restricted

## New (13)

- Ambiguous distinction between parsing sources. It is unclear if `parse` handles file paths and `parse_string` handles raw strings, or if they are redundant entry points for different input types. The naming convention does not clearly delineate the input domain (e.g., `parse_files` vs `parse_string` would be clearer).
- Documentation: no usage examples (docs/GettingStarted.md)
- Duplicate intent across different layers. Both `Base` (CodeObject) and `Docstring` have `has_tag?(name)`. Since `Base` likely delegates to its `Docstring`, having the method on both creates redundancy. Users might call `object.has_tag?` or `object.docstring.has_tag?` interchangeably.
- Duplicate intent across different layers. Similar to `has_tag?`, both `Base` and `Docstring` expose `tags(name)`. This creates confusion about whether to query the code object or its docstring directly.
- Inconsistent naming for CLI command execution. Most CLI commands use `run(args)`, but `YRI` (a CLI tool) also uses `run(args)`. However, `YARD.CLI.Config` uses `run(args)` while also having a `description()` method. The primary inconsistency is that `YARD.CLI.Config` appears to be a configuration object rather than a CLI command, yet it exposes `run(args)` and `description()`, blurring the line between configuration data and executable commands. Additionally, `YARD.CLI.CommandParser` uses `run(args)` which suggests it executes the parsed commands, whereas `YARD.CLI.Command` subclasses also use `run(args)`. This is consistent, but `Config` being a 'Command' is semantically confusing.
- Inconsistent naming for docstring access. The getter is `docstring(locale)` which takes an optional locale, while the setter is `docstring=(comments)`. This is standard Ruby, but `Base.docstring` is also a property. The method signature `docstring(locale)` implies it's a method, but it's listed as a Property in some contexts or Method in others. More importantly, `Docstring` class has `docstring` as a property, but `Base` has it as a method/property hybrid. This is minor but worth noting for clarity.
- Medium: security finding (details withheld)
- Orphaned file (lib/yard/cli/i18n.rb)
- Orphaned file (lib/yard/i18n/pot_generator.rb)
- Orphaned file (lib/yard/i18n/text.rb)
- Orphaned file (lib/yard/rubygems/hook.rb)
- Workflow token permissions not restricted (.github/workflows/ci.yml)
- Workflow token permissions not restricted (.github/workflows/gem.yml)

## Architecture

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