# Changelog

## Score

- CAI 70 → 67 (-2.7)
- Rubric changed (rubric-2026.10.1 → rubric-2026.10.5) — scores are not directly comparable.

## Lenses

- Code Health 100 → 77 (-23.0)
- Architecture 100 → 100 (+0.0)
- Maturity 82 → 77 (-4.5)
- Readiness 54 → 54 (+0.0)
- Security 78 → 78 (+0.0)

## Resolved (4)

- Confusing naming overlap in environment configuration: `Falcon.Environment.Serve` has `configuration_path` (singular), while `Falcon.Environment.Configured` has `configuration_paths` (plural) and `resolved_configuration_paths`. It is unclear if `Serve.configuration_path` is the raw path, the resolved path, or if it's redundant with `Configured` methods. The distinction between `configuration_path` and `configuration_paths` is ambiguous.
- Duplicate intent: Two distinct types (GreeterService and Greeter) expose the exact same method signature for the same logical operation. It is unclear if these are interchangeable, if one is a legacy alias, or if they serve different contexts (e.g., RPC vs local).
- Inconsistent command interface: Most commands (Serve, Redirect, Proxy, Top, Virtual, Host) implement a `call` method. However, `Paths` does not have a `call` method, instead exposing `resolved_paths` and `configuration`. This breaks the uniform command pattern expected in CLI frameworks.
- Inconsistent naming for lifecycle hooks: `MyService` uses `setup` for initialization/configuration, while `Falcon.Service.Server` and `Falcon.Service.Virtual` also use `setup`. However, `MyApplication` and `Application` use `initialize`. While `setup` is consistent among the Service types, the presence of `MyService` (which appears to be a user-defined or example service) using `setup` alongside standard services using `setup` is consistent, BUT `MyApplication` uses `initialize`. More critically, `Limited.Semaphore` uses `initialize` for construction, while `Falcon.Service.Server` uses `initialize` for construction but `setup` for lifecycle. The inconsistency is primarily between `MyService` (generic) and the framework's `Falcon.Service.*` types if `MyService` is intended to be a standard service interface. However, the bigger issue is `MyApplication.call` vs `Application.call` vs `SimpleApp.call` vs `WebSocketApp.call`. These are consistent. The real inconsistency is `MyService.setup` vs `Falcon.Service.Server.setup`. They are consistent. Let's look closer. `MyService` is likely a user example. The inconsistency is between `MyService` and `Falcon.Service` hierarchy? No, they match. Let's look at `Limited.Semaphore` vs `Limited.Semaphore.Token`. `Semaphore` has `initialize`, `Token` has `initialize`. Consistent. What about `Falcon.Rackup.Handler` vs `Rackup.Handler.Falcon`? These are likely aliases or duplicates. `Falcon.Rackup.Handler` and `Rackup.Handler.Falcon` both exist. Similarly `Falcon.Railtie` vs `Rackup.Handler`? No. `Rackup.Handler` and `Rackup.Handler.Falcon`? `Rackup.Handler.Falcon` exists. `Falcon.Rackup.Handler` exists. This is a duplication of the handler class under different namespaces.

## New (4)

- Confusing ownership semantics: `Semaphore` has a `release` method, and `Token` (which is acquired from the semaphore) also has a `release` method. It is unclear if `Semaphore.release` releases a specific token or the semaphore itself, or if it's a typo for `acquire`. Typically, only the token holder releases the lock.
- Duplicate intent: Two distinct types (GreeterService and Greeter) expose the exact same method signature for the same logical operation. It is unclear if these are interchangeable, if one is a legacy alias, or if they serve different underlying implementations.
- Inconsistent command interface: Most commands implement `call()`, but `Paths` does not have a `call` method, instead exposing `resolved_paths` and `configuration`. This breaks the uniform command pattern expected in CLI frameworks.
- Inconsistent naming for lifecycle hooks: `MyService` uses `setup` for initialization/configuration, while `Falcon.Service.Server` and `Falcon.Service.Virtual` also use `setup`. However, `MyApplication` and `Application` use `initialize` for their constructors/setup. The mix of `initialize` (constructor) and `setup` (post-constructor lifecycle) is inconsistent across service types.

## Architecture

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