architecture-health-checklisted

# Periodic Architecture Health Check Perform a **read-only** architecture health check of the codebase. Do **not** modify any code. The deliverable is a report, nothing else. This is a long-lived, AI-maintained application. The goal is to find the places where many individually reasonable changes have gradually made the architecture worse — not to grade it against a textbook. ## Scope - If the invocation passed a path, subsystem name, or git range as an argument, focus there. - Otherwise focus on the parts that have **changed or grown significantly** since the last review. There is no stored review marker, so establish "recent" from history — e.g. `git log --since=... --stat`, `git log --stat -- <path>`, or the last few dozen commits — and weight the churny, growing files. Say in the report what window you used. ## Start from what the repo already documents Before inspecting code, read the two hand-maintained sources of intent: - **README.md** — the architecture and the module map. - **TODO.md** — open decisions, "Decisions worth revisiting", and "Won't do without a reason". Several apparent problems are deliberate and explained there; do not re-flag a documented, intentional trade-off as drift. If a finding contradicts a TODO decision, say so and treat the decision as the baseline unless you have concrete evidence it has since broken. ## Understand the architecture first Before evaluating anything, inspect the relevant code and establish: - The ma