explain-like-im-newlisted

# Explain like I'm new Two explanations fail in opposite directions: the one that stays abstract and teaches nothing actionable, and the one that dives into files and never says why any of it exists. The fix is to give all three levels, in order, so the reader can stop at the depth they needed. Anchor every claim to a path. An explanation without file paths cannot be checked, and cannot be used to actually go and look. ## Level 1 — What it is for Three to five sentences, business-first. Who uses this, what job it does for them, and how it relates to the neighbouring apps. No framework names. The test: someone who does not write code understands what the app is for. Sources: the UI itself (run it and look, via `visual-verify`'s tooling), route names, i18n strings, the glossary, ticket history. Route names and translation files describe the domain far better than the module structure does. ## Level 2 — How it works One end-to-end trace of the single most representative user action, from click to pixel. Concrete, named, with paths: ``` User clicks "Auftrag freigeben" (orders.release) → apps/orders/.../release-button.component.ts:34 → OrdersFacade.release() — libs/domain/orders/.../orders.facade.ts:88 → POST /api/v2/orders/{id}/release — generated client, libs/api/orders → optimistic update of the orders store, rollback on error → the row re-renders as "Freigegeben"; a toast confirms ``` Then the map around it: where state lives, where the API boundary is, how