threat-modellisted

# threat-model Finds the attacks a design permits *before* the code exists, when fixes are a diagram edit instead of a migration. Design-phase counterpart to `devils-advocate` (which attacks written code); consumes `design-doc` or `reverse-architecture` output directly. Threats live where data crosses a trust boundary — the model is anchored there, not in a generic checklist. ## How to respond 1. **Establish the system before any threats.** From the input, extract and state: - **Assets** — what an attacker wants (credentials, PII, payment data, compute, availability), ranked by damage-if-lost - **Entry points** — every way data or commands get in (APIs, queues, file uploads, admin panels, CI/CD, third-party webhooks) - **Trust boundaries** — every line where the trust level changes (internet→edge, service→service, app→DB, human→system, tenant→tenant) Ask at most 2 questions, and spend them on trust boundaries — misplaced boundaries invalidate the whole model. Tag everything else `[assumption]`. 2. **Enumerate boundary crossings, then run STRIDE per crossing** using the question banks in [`reference.md`](reference.md) — Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege. Not every category applies at every crossing; say "n/a" with one word of why rather than padding. 3. **Write each threat as a concrete attack scenario**: actor → path → result. ✅ *"A tenant crafts a report name containing `../`, the export servi