Architecture Decision Records

Each ADR captures one significant technical decision — its context, what was decided, and the trade-offs accepted. They describe the system as it is built. Where a decision has proved questionable in hindsight, that is recorded in a Retrospective section rather than hidden.

ADR	Decision	Theme	Status
001	Hexagonal (ports & adapters) architecture, enforced by ArchUnit	Backend structure	Accepted
002	Reactive stack: Spring WebFlux + R2DBC	Backend runtime	Accepted
003	Kotlin on the JVM, Java 25 toolchain	Language	Accepted
004	Delegated authentication via OIDC (resource server + confidential client)	Security	Accepted
005	Database-driven, project-scoped RBAC via a custom PermissionEvaluator	Authorization	Accepted
006	PostgreSQL with Flyway migrations and pg_trgm trigram search	Persistence	Accepted
007	Frontend runtime configuration injection (one immutable image)	Frontend delivery	Accepted
008	NGXS for frontend state management	Frontend state	Accepted
009	Distroless container delivery with semantic-release	Build & release	Accepted
010	Retention purges as scheduled, permission-gated endpoints	Data retention	Accepted
011	PrimeNG with runtime theming	Frontend UI	Accepted
012	Per-instance authentication rate limiting with Caffeine, not a shared store	Security	Accepted

Format

# ADR NNN — Title

## Status
<Badge type="tip" text="Accepted" />

## Context
What problem or constraint triggered this decision?

## Decision
What was decided?

## Consequences
Positive and negative trade-offs, and why the alternatives were rejected.

## Retrospective   (optional)
How the decision has held up in practice, including regrets.

The Status badge uses one of:

Badge	Meaning
Accepted	Decided and in effect
Proposed	Drafted, not yet decided
Rejected	Considered and turned down
Superseded by ADR NNN	Replaced by a later ADR (or Deprecated)