# Changelog

## Score

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

## Lenses

- Code Health 83 → 66 (-16.2)
- Architecture 95 → 96 (+0.5)
- Maturity 56 → 33 (-23.2)
- Readiness 78 → 78 (+0.0)
- Security 73 → 73 (+0.0)
- Domain Modelling 100 → 100 (+0.0)

## Resolved (6)

- Documentation: contradicts the code (docs/security.md)
- Inconsistent transport initialization: `FastMcp` provides high-level middleware factories (`rack_middleware`, `authenticated_rack_middleware`), while `Server` provides a lower-level `start_rack`. This splits the responsibility of setting up the HTTP transport between the facade (`FastMcp`) and the core component (`Server`), leading to potential configuration drift or confusion about which method to use for different deployment scenarios.
- PR-triggered workflow without a permissions block
- Redundant API surface: The `FastMcp` class exposes `register_tool`/`register_resource` methods that duplicate the functionality of `Server.register_tool`/`Server.register_resource`. Since `FastMcp` likely wraps or holds a `Server` instance, exposing both levels of registration creates confusion about which object is the source of truth and violates the principle of least surprise.
- Redundant notification method: `FastMcp` exposes `notify_resource_updated` which duplicates `Server.notify_resource_updated`. This forces users to choose between the facade and the underlying server for a specific action, risking inconsistent state if the facade's implementation is not perfectly synchronized with the server's.
- Workflow holding a long-lived secret is unscoped

## New (15)

- Ambiguous getter/setter pattern. `Resource` exposes `uri(value)` as a method, implying it can be used as both a getter (no args) and setter (with args). While this is a common Ruby idiom, it is inconsistent with other properties like `description(value)` and `description()` which are listed separately. More importantly, `Resource.uri()` is also listed as a method, creating redundancy with the getter behavior of `uri(value)`. This suggests a lack of clarity on whether `uri` is a property or a method.
- Duplicate notification API surface. Both `FastMcp` and `Server` expose `notify_resource_updated`. This mirrors the registration issue, offering two ways to trigger the same internal event, potentially leading to redundant notifications or race conditions.
- Duplicate registration API surface. Both the top-level `FastMcp` class and the internal `Server` class expose identical `register_tool` and `register_tools` methods. This creates confusion about whether the user should interact with the facade (`FastMcp`) or the underlying component (`Server`), and risks double-registration or inconsistent state if both are used.
- Duplicated block (6 lines × 2) (examples/rails-demo-app/db/cable_schema.rb)
- Duplicated block (8 lines × 2) (examples/rails-demo-app/db/queue_schema.rb)
- Duplicated block (8 lines × 3) (examples/authenticated_rack_middleware.rb)
- Inconsistent server startup/middleware patterns. `FastMcp` offers two distinct methods for Rack middleware (`rack_middleware` vs `authenticated_rack_middleware`), while `Server` offers `start_rack`. It is unclear if `Server.start_rack` is equivalent to one of the `FastMcp` methods or a lower-level primitive. The naming convention (`_middleware` vs `start_`) suggests different abstraction levels that are not clearly documented or separated in the public surface.
- Orphaned file (lib/fast_mcp.rb)
- Orphaned file (lib/mcp/resource.rb)
- Orphaned file (lib/mcp/server.rb)
- Orphaned file (lib/mcp/tool.rb)
- Orphaned knowledge (lib/mcp/transports/rack_transport.rb)
- PR-triggered workflow without a permissions block (.github/workflows/ci.yml)
- PR-triggered workflow without a permissions block (.github/workflows/rubocop.yml)
- Workflow holding a long-lived secret is unscoped (.github/workflows/release.yml)

## Architecture

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