Driver

Proper STRIDE threat modelling starts with a Data Flow Diagram identifying trust boundaries, processes, data stores, and the data crossing each boundary. The threats are then generated per-element from the DFD, not invented ad-hoc.

The current threat-model template (templates/audits/threat-model.md, shipped in #222) has an STRIDE category table and an attack-surface count, but no DFD section. The "Notes" section mentions trust boundaries in prose only. This makes the threat catalogue feel ad-hoc rather than systematic.

Scope

• Add a ## Data Flow Diagram section to templates/audits/threat-model.md, BEFORE the attack-surface count and STRIDE table. Section contains:
  • A Mermaid flowchart skeleton showing the standard STRIDE shapes (external entity → process → data store → external service) with trust boundaries drawn as dashed subgraphs
  • Annotations on each arrow indicating what data crosses the boundary (e.g. "auth token", "user PII", "transaction record")
  • Brief instructions: "Replace with your system's actual entities. Each crossing of a trust boundary is where STRIDE threats apply most acutely."
• Update .claude/skills/threat-model/SKILL.md Step 1 ("Map the attack surface") to reference the DFD section as the natural starting artefact and instruct the operator to populate it before the STRIDE walk
• Optional: cross-link to templates/architecture/dfd.md if [Feature: Architecture vision + DFD + sequence templates] (sibling ticket) ships first

Acceptance Criteria

• templates/audits/threat-model.md has a ## Data Flow Diagram section with a Mermaid skeleton (trust boundaries as dashed subgraphs, data labels on arrows)
• .claude/skills/threat-model/SKILL.md Step 1 references the DFD as the starting artefact
• Mermaid syntax renders correctly in GitHub markdown preview (no parse errors on the skeleton)

Risks / Dependencies

• Low: template-only change.
• May supersede / be partially redundant with sibling [Feature: Architecture vision + DFD + sequence templates] if that ships a generic DFD template — in which case threat-model can reference it instead of having its own. Either order is fine; the two tickets coordinate via the cross-link AC above.