document update

docs/00-CORE.md

@@ -40,6 +40,7 @@ erp-monorepo/
 └── docs/                         # ALL documentation
     ├── 00-CORE.md                # ← you are here (hub)
     ├── 01-DOC-GUIDE.md           # documentation map + tracking conventions
+    ├── 02-SECURITY.md            # accepted-risks register + per-feature security checklist
     ├── 10-BACKEND-PHASE1.md      # backend spec: SRS + ER/entities + tech + architecture
     ├── 11-BACKEND-PHASE1.md      # backend API reference (complete req/res)
     └── 20-FRONTEND.md            # frontend user-flows + architecture rules + validation posture
@@ -336,6 +337,7 @@ All frontend work is governed by `20-FRONTEND.md`.
 | Requirements, business rules, entities, ER model, data types, architecture detail | **`10-BACKEND-PHASE1.md`** |
 | API endpoints, request/response shapes, error catalog, enums | **`11-BACKEND-PHASE1.md`** |
 | Frontend user-flows, screen flow, architecture rules, validation posture | **`20-FRONTEND.md`** |
+| Security risks per feature, accepted-risk register, pre-ship checklist | **`02-SECURITY.md`** |
 | Understanding the doc system, reading order, tracking conventions | **`01-DOC-GUIDE.md`** |
 | Recording backend changes made | **`Backend/PROGRESS.md`** |
 | Recording frontend changes made | **`Frontend/PROGRESS.md`** |
@@ -344,6 +346,7 @@ Quick resolver:
 - *"Where is the model / an entity defined?"* → `10-BACKEND-PHASE1.md` (schema is authoritative there).
 - *"What does this endpoint accept/return?"* → `11-BACKEND-PHASE1.md`.
 - *"How should the UI flow / what do I validate where?"* → `20-FRONTEND.md`.
+- *"What security risks / checks apply to this feature?"* → `02-SECURITY.md`.
 
 ---
 
@@ -355,6 +358,8 @@ Two checklists track what has actually been built, and travel with code via git:
 
 These are **Claude-maintained**: whenever a change is made on either side, the corresponding `PROGRESS.md` must be updated (tick items, add entries). The format and rules for these files are defined in **`01-DOC-GUIDE.md` §Tracking**. Both files must exist before feature work begins.
 
+> **Security gate:** before ticking any data-mutating feature `[x]`, run its checklist in **`02-SECURITY.md`** (Part C) plus the foundational controls (Part B). Accepted Phase-1 exposures are recorded in `02-SECURITY.md` Part A — do not "fix" them ad-hoc.
+
 ---
 
 ## 9. Documentation maintenance rule