app-business-docslisted

# App business logic documentation (English) ## Purpose Keep a single **English** narrative so humans (and future LLM turns) can understand **what the app does** and **why**, without reading every file. **Canonical file:** `docs/en/business-logic.md` Create `docs/en/` if it does not exist. ## When to use this skill 1. **After business-logic changes** — routes, validation, state machines, permissions, multi-step flows, integrations, or copy that reflects real rules. 2. **Revalidation** — the user asks to refresh the doc from the codebase, or debugging shows the doc (or mental model) is wrong or stale. 3. **Onboarding** — initial fill after an app or app reaches a coherent shape. Do **not** treat this as API reference: no exhaustive endpoint lists unless they carry domain meaning. Prefer flows, invariants, and “if user does X then Y”. ## Document structure (adapt as needed) Use clear headings, for example: - **Product overview** — who uses it, primary job-to-be-done. - **Glossary** — domain terms. - **Actors & roles** — visitor, member, admin, system, etc., aligned with real authz. - **Main scenarios** — numbered happy paths (step-by-step). - **Edge cases & failure behavior** — errors, empty states, retries, idempotency. - **Data & ownership** — what lives in dashboards vs Gate vs isolated stores (if any), at a conceptual level. - **Code map** — short table: scenario or area → primary paths (`apps/...`, `backend/...`). ## Workflow 1. **Read** the current `docs/en/b