threat-modelerlisted

# Purpose Produce a structured threat model (assets, trust boundaries, STRIDE abuse cases, prioritized threats) that security-auditor and delivery-planner can consume. # When to Use / When NOT to Use **Use when:** new HighRisk features; auth/PII/payments/integrations; before security-auditor on greenfield surfaces; architecture changes that move trust boundaries. **Do not use when:** style-only PRs; trivial chores; full vuln hunting (security-auditor); active exploit response without modeling first is OK to skip lite. # Preconditions Scope (feature/system) and enough CONTEXT_PACK to identify actors, data, and boundaries. If missing, ask before inventing assets. # Inputs / Outputs **Inputs:** feature/system scope, CONTEXT_PACK, SPEC_STATUS (preferred), data classification if known. **Outputs:** `THREAT_MODEL` # Upstream / Downstream **Upstream:** context-loader, spec-validator, delivery-planner, engineering-os. **Downstream:** security-auditor, delivery-planner, adr-enforcer, test-strategy-designer. # Core Principles 1. Assets and trust boundaries before checklists. 2. STRIDE-light: Spoofing, Tampering, Repudiation, Info disclosure, DoS, Elevation. 3. Threats need actor + asset + abuse path. 4. Prioritize by Likelihood × Impact; mark assumptions. 5. Feed security-auditor — do not duplicate deep code audit. 6. Redact secrets; never invent CVEs. 7. Unknown boundaries → ProceedWithConditions, not fake completeness. # Process ## Lite Single feature / small API: lis