# Changelog

## Score

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

## Lenses

- Code Health 100 → 100 (+0.0)
- Architecture 69 → 69 (+0.0)
- Maturity 52 → 47 (-5.5)
- Readiness 75 → 75 (+0.0)
- Security 77 → 77 (+0.0)

## Resolved (8)

- Documentation: no usage examples (docs/en/reference/index.rst)
- Duplicate intent: Both EventManager and EventDispatcher expose an identical method signature for dispatching events. It is unclear if these are separate components with overlapping responsibilities or if one is a facade for the other.
- Duplicate intent: Both EventManager and EventListenerIntrospector expose an identical method signature for checking if listeners exist. This creates confusion about which type should be used for introspection.
- Duplicate intent: Both EventManager and EventListenerIntrospector expose an identical method signature for retrieving all listeners. This creates confusion about which type should be used for introspection.
- Duplicate intent: Both EventManager and EventListenerIntrospector expose an identical method signature for retrieving listeners. This creates confusion about which type should be used for introspection.
- Duplicate intent: Both EventManager and EventListenerRegistry expose an identical method signature for adding listeners. This suggests redundancy in the API surface, where the same operation is available on two different types.
- Duplicate intent: Both EventManager and EventListenerRegistry expose an identical method signature for removing listeners. This mirrors the redundancy found in addEventListener.
- Workflow token permissions not restricted

## New (11)

- Documentation: no usage examples (docs/en/index.rst)
- Duplicate functionality: Both EventManager and EventDispatcher expose an identical dispatchEvent method. In typical event-driven architectures, the Manager handles registration and the Dispatcher handles execution, or the Manager delegates to the Dispatcher. Having both types expose the exact same public API for dispatching creates confusion about which type should be used by consumers.
- Inconsistent registration patterns: The API mixes two different ways to register listeners. One method takes a raw object and event names, while the other takes a specific EventSubscriber interface. While technically distinct, this forces consumers to choose between two different patterns for similar outcomes, and the distinction between 'listener' (object) and 'subscriber' (EventSubscriber) is not clearly enforced by the type system in the signature (both take objects/interfaces).
- Redundant introspection methods: The EventManager exposes three methods for querying listener state. While 'has' is distinct, 'getListeners' and 'getAllListeners' are often redundant in implementation (one might just return all keys of the other). More critically, these methods are also duplicated in EventListenerIntrospector, suggesting a split responsibility that isn't reflected in the naming or usage patterns.
- Workflow token permissions not restricted (.github/workflows/coding-standards.yml)
- Workflow token permissions not restricted (.github/workflows/composer-lint.yml)
- Workflow token permissions not restricted (.github/workflows/continuous-integration.yml)
- Workflow token permissions not restricted (.github/workflows/documentation.yml)
- Workflow token permissions not restricted (.github/workflows/release-on-milestone-closed.yml)
- Workflow token permissions not restricted (.github/workflows/static-analysis.yml)
- Workflow token permissions not restricted (.github/workflows/website-schema.yml)