docs(adr): convert all ADRs to MADR 2.1.2 format

Rewrites all 12 frontend ADRs from a custom structure to the MADR 2.1.2
template required by the VS Code ADR Manager extension: bullet metadata
(Status/Date), standardised section headings, "Chosen option: X, because Y"
wording, and explicit Pros/Cons blocks per option.

docs/decisions/0011-feature-domain-organisation.md

@@ -1,32 +1,46 @@
-# ADR 0011: Feature Domain Organisation
+# Organise code by functional domain
 
-**Date:** 2026-04-26
-**Status:** Accepted
+- Status: accepted
+- Date: 2026-04-26
 
-## Context
+## Context and Problem Statement
 
-The application covers four independent functional areas, each with its own data model, API backend, and user audience:
+The application covers four independent functional areas with distinct data models, API backends, and user audiences: Skydive, CMS, E-commerce, and Hero Wars. Without explicit organisational boundaries, code from different domains would intermingle, making each area harder to reason about independently. How should the codebase be structured?
 
-- **Skydive** — jump logbook, statistics, QCM exam preparation.
-- **CMS** — articles, pages, user profiles.
-- **E-commerce** — product catalogue by category.
-- **Hero Wars** — analytics dashboard for a game guild (static weekly snapshots).
+## Considered Options
 
-Without an explicit organisational boundary, code from different domains would intermingle, making it harder to reason about and maintain each area independently.
+- Domain-based organisation (one folder per functional area)
+- Flat feature-based organisation (one folder per component type)
 
-## Decision
+## Decision Outcome
 
-Services, routes, and API prefixes are organised by domain:
+Chosen option: "Domain-based organisation", because it mirrors the backend's route grouping, making the full-stack data flow traceable, and allows each domain to be understood and modified independently.
 
-- Services under `src/app/core/services/<domain>/`
-- Routes composed from `auth.routes.ts` and `noauth.routes.ts`, with domain-specific guards (`authGuard`, `adminGuard`)
-- API service domains: `/skydive`, `/cms`, `/ecommerce`, `/herowars`
+Services are placed under `src/app/core/services/<domain>/`, API prefixes are `/skydive`, `/cms`, `/ecommerce`, `/herowars`, and routes are composed from `auth.routes.ts` and `noauth.routes.ts` with domain-specific guards.
 
-This structure mirrors the backend's route grouping (`src/routes/api/<domain>/`), making the full-stack data flow traceable.
+### Positive Consequences
 
-## Consequences
+- Each domain can be understood and modified independently.
+- Consistent mapping between frontend service paths and backend API routes simplifies debugging.
 
-- **Positive:** Each domain can be understood and modified independently.
-- **Positive:** Consistent mapping between frontend service paths and backend API routes.
-- **Negative:** Cross-domain features (e.g. shared auth, user profile) must be placed in `core/` to avoid circular dependencies.
-- **Note:** Hero Wars uses static JSON data files (`src/files-data/`) rather than live API calls, which is intentional — the data is updated manually via weekly snapshots.
+### Negative Consequences
+
+- Cross-domain features (shared auth, user profile) must be placed in `core/` to avoid circular dependencies.
+
+## Pros and Cons of the Options
+
+### Domain-based organisation
+
+- Good, because domain boundaries are explicit and enforced by directory structure.
+- Good, because mirrors the backend route grouping — frontend `core/services/skydive/` maps to backend `src/routes/api/skydive/`.
+- Bad, because shared cross-domain concerns need a neutral `core/` layer.
+
+### Flat feature-based organisation
+
+- Good, because all components of the same type are co-located.
+- Bad, because domain boundaries are invisible — mixing domains is too easy.
+
+## Links
+
+- Hero Wars uses static JSON files (`src/files-data/`) rather than live API calls — weekly snapshots updated manually. This is intentional and not a gap in the domain structure.
+- Related to backend [ADR 0004](../../adastra_api/docs/decisions/0004-route-organisation-by-domain.md)