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

Rewrites all 7 backend 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/0005-two-separate-repositories.md

@@ -1,24 +1,46 @@
-# ADR 0005: Frontend and Backend in Separate Repositories
+# Maintain frontend and backend in separate repositories
 
-**Date:** 2026-04-26
-**Status:** Accepted
+* Status: accepted
+* Date: 2026-04-26
 
-## Context
+## Context and Problem Statement
 
-The frontend (Angular SPA) and backend (Express API) are distinct deployment units with different runtimes, dependencies, and release cycles. Two organisational options exist:
+The frontend (Angular SPA) and backend (Express API) are distinct deployment units with different runtimes, dependencies, and release cycles. Should they live in the same repository or in separate ones?
 
-- **Monorepo** — single repository containing both applications, possibly managed with Nx or Turborepo.
-- **Separate repositories** — each application in its own repository with independent versioning.
+## Considered Options
 
-## Decision
+* Separate repositories (`adastra_app` and `adastra_api`)
+* Monorepo (managed with Nx or Turborepo)
 
-Maintain two separate repositories: `adastra_app` (frontend) and `adastra_api` (backend). Both are treated as a single product during development — tasks that span both (e.g. adding a new API endpoint and its frontend consumer) are handled in a single working session across both repos.
+## Decision Outcome
 
-## Consequences
+Chosen option: "Separate repositories", because the two applications have independent dependency trees and deployment lifecycles, and the current scale does not justify the tooling overhead of a monorepo.
 
-- **Positive:** Independent dependency management. Frontend and backend `package.json` files don't interfere with each other.
-- **Positive:** Simpler CI/CD pipeline per repo when production deployment is set up.
-- **Positive:** Each repo's git history reflects only its own changes.
-- **Negative:** No shared type definitions between frontend and backend. API contract changes must be coordinated manually.
-- **Negative:** Cross-repo changes require two separate commits/PRs. A monorepo would allow atomic cross-boundary commits.
-- **Tooling note:** The Angular frontend's `CLAUDE.md` declares `adastra_api` as an additional working directory so that cross-repo tasks can be handled in a single session.
+Both repositories are treated as a single product during development: the Angular frontend's `CLAUDE.md` declares `adastra_api` as an additional working directory so that cross-repo tasks can be handled in a single session. Tasks that span both (e.g. adding an endpoint and its frontend consumer) are handled together.
+
+### Positive Consequences
+
+* Independent dependency management — `package.json` files don't interfere with each other.
+* Simpler per-repo CI/CD pipeline when production deployment is configured.
+* Each repo's git history reflects only its own changes.
+
+### Negative Consequences
+
+* No shared type definitions between frontend and backend. API contract changes must be coordinated manually.
+* Cross-repo changes require two separate commits. A monorepo would allow atomic cross-boundary commits.
+
+## Pros and Cons of the Options
+
+### Separate repositories
+
+* Good, because independent dependency management and deployment.
+* Good, because clean git history per application.
+* Bad, because no shared types — API contract drift must be caught manually.
+* Bad, because cross-repo changes require coordinated commits in two places.
+
+### Monorepo (Nx or Turborepo)
+
+* Good, because atomic cross-boundary commits and shared type definitions.
+* Good, because single place to run all tasks (build, test, lint).
+* Bad, because significant tooling overhead not justified at the current scale.
+* Bad, because requires migrating both repos and learning monorepo tooling.