# Changelog

## Score

- CAI 63 → 63 (+0.0)
- Rubric changed (rubric-2026.08.18 → rubric-2026.08.19) — scores are not directly comparable.

## Lenses

- Code Health 100 → 100 (+0.0)
- Architecture 99 → 99 (+0.0)
- Maturity 86 → 86 (+0.0)
- Readiness 36 → 36 (+0.0)
- Security 100 → 100 (+0.0)
- Domain Modelling 79 → 79 (+0.0)

## Resolved (10)

- Consequences/trade-offs are cut by the clip marker and not flagged as missing; only context/problem and decision are visible (docs/architecture-decisions/0007-api-first.md)
- Context and decision are both present but the body is cut mid-sentence by a clip marker inside the Decision bullet list ('...after successful transaction.'), so the trade-offs/consequences section (and review process) fall past the scanner boundary (docs/architecture-decisions/0002-integration-events-implementation.md)
- Context is a bare 'The idea from CQRS - do not return anything from command processing. But in some cases...' with no problem statement and decision body identical (returns generated identifiers after processing) then clipped (docs/architecture-decisions/0008-result-from-comand-handlers.md)
- Context lists only the two alternatives (same model vs separate models) and a decision that is restated as 'it will be used' with no rationale or trade-offs; the referenced links give nothing about CQRS in this context (docs/architecture-decisions/0003-cqrs.md)
- Context lists three solutions but never states which one is chosen and the trade-offs of each; Decision only names the always-valid approach with no consequences (docs/architecture-decisions/0004-validation.md)
- Context lists two alternatives but the decision is restated verbatim ('rich domain model solution will be used...') with no trade-offs; the title is uninformative (docs/architecture-decisions/0006-rich-domain-model.md)
- Decision is a boilerplate list with links citing design sources but no context/problem and no consequences/trade-offs (docs/architecture-decisions/0001-bounded-contexts-communication.md)
- Decision is narrow and consequences are absent: it only states which keys should be used (natural keys or uuids) without banning primary keys for communications with external systems and no trade-offs of preferring natural keys (docs/architecture-decisions/0005-identifier-between-modules.md)
- No consequences/trade-offs section (e.g. learning curve, tooling cost, operational complexity of the Axon event-store layer) (docs/architecture-decisions/0011-use-axon-event-publishing-mechanism.md)
- No consequences/trade-offs section describing what happens when the application moves away from Spring (e.g., loss of Spring-specific features) and how Quarkus integration is verified (docs/architecture-decisions/0012-make-application-framework-independent.md)

## New (9)

- Context and decision are both present but the body is clipped mid-sentence ('We can add custom features to Spring functionality when it's needed.') before any consequences/trade-offs or a review link appear (docs/architecture-decisions/0002-integration-events-implementation.md)
- Context lists only the two alternatives (same model vs separate models) and a decision that is restated as 'it will be used' without explaining why CQRS was chosen over those options (docs/architecture-decisions/0003-cqrs.md)
- Context lists three solutions but never states the problem being solved (e.g. data inconsistency across requests) and the decision is restated verbatim without consequences (docs/architecture-decisions/0004-validation.md)
- Context lists two alternatives but the decision is restated as a tautology ('rich domain model solution will be used') with no rationale or trade-offs (docs/architecture-decisions/0006-rich-domain-model.md)
- Decision is a boilerplate list with links citing design sources but no context/problem and consequences are couched in the decision's own wording ('it's forbidden to create a transaction which spans more than one bounded context') (docs/architecture-decisions/0001-bounded-contexts-communication.md)
- Decision is narrow and consequences/trade-offs are absent: only that primary keys must not be used for cross-module/external identifier exchange; no mention of why uuids/good natural keys are preferred over each (docs/architecture-decisions/0005-identifier-between-modules.md)
- No consequences/trade-offs are stated (e.g., loss of Spring-specific features like data persistence or security) (docs/architecture-decisions/0012-make-application-framework-independent.md)
- No consequences/trade-offs section describing the cost of adopting Axon (e.g. learning curve, configuration complexity) and benefits such as event sourcing (docs/architecture-decisions/0011-use-axon-event-publishing-mechanism.md)
- Uninformative title and the decision is restated verbatim as Context (docs/architecture-decisions/0008-result-from-comand-handlers.md)