# Changelog

## Score

- CAI 42 → 41 (-1.0)
- Rubric changed (rubric-2026.10.1 → rubric-2026.10.5) — scores are not directly comparable.

## Lenses

- Code Health 70 → 57 (-13.3)
- Architecture 98 → 98 (+0.0)
- Maturity 30 → 34 (+3.6)
- Readiness 27 → 27 (+0.0)
- Security 90 → 90 (+0.0)

## Resolved (3)

- Ambiguous duplication in alias lookup. `getContactByAlias` likely returns a full contact object, while `getUsernameByAlias` returns just the username string. While return types differ, the naming convention is inconsistent with other methods in the class (e.g., `Contacts` uses `getUsernameBy...` for strings). It creates confusion about which method to use for simple ID resolution.
- Inconsistent method naming for similar operations. `getGroupsByNickname` searches for groups, while `getMembersByNickname` searches for members within a group. The prefix `get` is used, but the scope (group vs member) is embedded in the method name rather than the class structure. This is less severe but inconsistent with `Contacts.getUsernameByNickname`.
- Redundant `update` methods across Contact sub-types. `Friends` and `Groups` are subsets of `Contacts`. The `update` method signature is identical across all three, suggesting that `Contacts` should be the single source of truth for contact updates, or that the sub-types should delegate to the parent rather than duplicating the implementation.

## New (23)

- Inconsistent API execution pattern. `BaseApi` defines a `handle` method, and its subclasses `Search` and `Send` also define `handle`. However, `BaseApi` also has `execute` and `validate`. It is unclear if `Search.handle` overrides `BaseApi.handle` or if `BaseApi.execute` is the intended entry point. The presence of `validate` and `needParams` in `BaseApi` but not clearly in the flow of `Search`/`Send` suggests an inconsistent lifecycle management between the base class and its specific API handlers.
- Inconsistent error handler signatures. `ExceptionHandler` and `HandleExceptions` both have `handleError` methods with slightly different signatures (different number of parameters, specifically `context`). This suggests two different error handling mechanisms or layers that are not aligned, potentially leading to confusion about which handler is invoked in which context.
- Orphaned file (src/Contact/Contacts.php)
- Orphaned file (src/Contact/Friends.php)
- Orphaned file (src/Contact/Groups.php)
- Orphaned file (src/Core/ContactFactory.php)
- Orphaned file (src/Core/MessageFactory.php)
- Orphaned file (src/Core/MessageHandler.php)
- Orphaned file (src/Core/Server.php)
- Orphaned file (src/Core/Sync.php)
- Orphaned file (src/Extension/AbstractMessageHandler.php)
- Orphaned file (src/Extension/MessageExtension.php)
- Orphaned file (src/Foundation/ExceptionHandler.php)
- Orphaned file (src/Foundation/Kernel.php)
- Orphaned file (src/Foundation/Vbot.php)
- Orphaned file (src/Message/Card.php)
- Orphaned file (src/Message/Emoticon.php)
- Orphaned file (src/Message/File.php)
- Orphaned file (src/Message/Message.php)
- Orphaned file (src/Message/Traits/Multimedia.php)
- …and 3 more