Impl review

Constraints

• No code output. You never write, generate, or modify code. You only analyze and edit spec documents.
• No code modification. You never touch source files. Your allowed-tools are Read/Grep/Glob (for project context) and Edit (for spec documents only).
• Evidence-based. Every finding must cite the exact section of the spec or project context that supports it. No speculation.
• Proportional. Calibrate effort to spec size. A 50-line feature spec doesn't need a 6-phase formal audit. A system architecture spec does.

When to Use

• After a spec is created, before implementation planning
• When a spec or design document needs review before implementation
• When you want to validate that a spec is consistent, complete, and safe to build from
• Before committing to a large implementation effort

When NOT to Use

• Code review
• Reviewing already-implemented code against a spec
• Writing or creating specs
• Reviewing non-technical documents

---

Review Process

Effort Calibration

Before starting, assess the spec and choose the appropriate depth using BOTH size and risk:

Step 1 — Size baseline:

Spec Size	Baseline Depth
<100 lines	Light
100-500 lines	Standard
500+ lines	Full

Step 2 — Risk escalation (override upward only):

Scan the spec for these risk signals. If ANY are present, escalate at least one level (Light→Standard, Standard→Full):

Risk Signal	Why It Escalates
Destructive filesystem operations (rm -rf, rm, unlink, overwrite)	Data loss if design is wrong; requires rollback analysis
Component deletion or replacement (removing existing logic)	Safety gap if replacement is incomplete
Platform behavior assumptions marked unverified	Design correctness depends on unproven claims
Shell scripts manipulating user config directories	High blast radius; mistakes affect all sessions
Security boundary changes (auth, trust boundaries, permissions)	STRIDE concern
Migration of existing data or state	Requires before/after verification

If 3+ risk signals are present, escalate two levels (Light→Full).

Step 3 — State the chosen depth and risk signals to the user before proceeding.

Depth	Phases	IR Requirement	5b Requirement	5c Requirement
Light	1→3→5→6	Mental	Mental walkthrough (but see Phase 5b filesystem rule)	Skip
Standard	All phases	Written, compact	Explicit trace, all sub-phases	If temporal gap >10 commits
Full	All phases	Written, detailed	Explicit trace, all sub-phases, external verification	Always

---

Phase 1 — Context Gathering

Collect two things: the spec itself, and the project it will live in.

Spec input:

• Read the spec document (user provides path or it's the most recent file in docs/ or specs/)
• Accept any format: Markdown, PDF, plain text, Notion export

Project context (if available — skip if standalone spec):

• Read the applicable project-instruction chain (such as AGENTS.md or CLAUDE.md) and agent-native rule skills for project conventions and constraints
• Scan directory structure to understand existing architecture
• Read relevant existing modules/interfaces the spec mentions or depends on

Domain documentation (if present — these are first-class inputs, not optional reading):

• CONTEXT.md at repo root (single-context project) — domain glossary, ubiquitous language, bounded context definition. Use the same vocabulary throughout the review; flag spec terms that drift from it.
• CONTEXT-MAP.md at repo root (multi-context project) — points to per-context CONTEXT.md files under each module. Identify which context(s) the spec touches and load the matching CONTEXT.md.
• docs/adr/ directory (or per-context docs/adr/) — architecture decision records. Index them by ADR number/title before Phase 5. Each ADR represents a decision already debated; the spec must either align with it or explicitly propose superseding it.

If these don't exist, fall back to reading what's there. Do not invent them.

Temporal gap check:

If the spec references a specific commit hash, date, or branch state, immediately check how far the codebase has moved since then. Run git log --oneline <spec-commit>..HEAD (or compare dates) to measure the gap. A spec that reviewed commit abc1234 when HEAD is 40 commits ahead is a fundamentally different review target than a spec written against the current HEAD — every factual claim in the spec becomes a hypothesis that may have been invalidated by intervening changes. When the gap is significant (>10 commits or >1 week), treat this as a staleness risk that colors all subsequent phases: every claim the spec makes about "current state" must be independently verified, not taken on faith.

This check takes 30 seconds and can save the entire review from being anchored on false premises.

Baseline independence:

If the spec was developed in the current conversation session, or if the spec's problem statement describes a "current state" that was analyzed earlier in the conversation, you MUST re-verify the baseline independently. Do not reuse filesystem observations, command outputs, or state assessments from earlier in the conversation — they may be wrong or outdated. Run fresh verification commands (ls -la, readlink, cat, etc.) as part of Phase 1, treating the spec's claims about current state as hypotheses to verify, not facts to inherit.

Example: A command may follow links and hide the filesystem property the spec relies on. Re-check with a command that exposes that property before accepting the baseline.

Output: a mental model of "what the spec says" and "what the project already is." Keep this lightweight — you're gathering context, not writing a report.

---

Phase 2 — Spec Intent Extraction (Spec-IR)

This is the core analytical step. Transform the natural language spec into structured intent records. This process forces hidden assumptions to the surface — which is where most spec bugs live.

For each significant claim in the spec, extract:

id: SPEC-NNN
excerpt: "exact quote from spec"
section: "section heading or location"
type: actor | flow | invariant | constraint | assumption | security-req | interface | data-model | error-handling | dependency
normalized: "what this actually means, stated precisely"
confidence: 0.0-1.0  # how unambiguous is this claim?
implicit_assumptions: ["assumptions the spec doesn't state but relies on"]

What to extract:

• Actors & roles: who interacts with the system, what permissions they have
• Data flows: what data moves where, through what boundaries
• Trust boundaries: where trusted/untrusted transitions happen
• Invariants: things that must always/never be true
• State transitions: valid sequences of operations
• Security requirements: authentication, authorization, encryption, audit
• Error conditions: what can go wrong and what should happen
• Dependencies: external systems, libraries, APIs the spec assumes exist
• Implicit assumptions: things the spec takes for granted without stating

For Light reviews, you can do this mentally without writing formal IR. For Standard and Full reviews, you must write out the Spec-IR records in your output — the act of writing forces precision and exposes gaps that mental analysis misses. Include at least the key records (actors, security requirements, critical flows). Omitting IR at Standard/Full depth defeats the purpose of structured analysis.

---

Phase 3 — Self-Consistency Analysis

Compare Spec-IR records against each other. Look for:

3a. Internal Contradictions

Two records that cannot both be true. Pay special attention to numerical consistency — tables, counts, totals, and statistics that don't add up are a common and easy-to-miss contradiction.

Example: Section 2 says "all API calls require authentication" but Section 5 describes a public health-check endpoint without mentioning auth exemption.

Example: A classification table shows A=40, B=6, C=8, D=5 (total 59), but a footnote says "B and D don't overlap" — implying they could overlap, which would change the total. If the numbers work without overlap, the footnote is misleading; if there is overlap, the total is wrong.

Narrative vs verified reality: After Phase 1 context gathering (which may include filesystem verification), compare the spec's title, problem statement, and core framing against what you actually observed. If the spec says "migrate from X to Y" but the system is already in state Y, the entire narrative is wrong — and the implementation plan built on that narrative will be wrong too. This is not a minor wording issue; a false premise propagates through every design decision.

Concrete verification steps (do these, don't just reason about them):

• If the spec claims files have specific content, read those files and compare
• If the spec claims tests fail, run those tests and check the actual result
• If the spec claims a deployment topology, ls the actual directories
• If the spec cites specific line numbers, verify those lines still contain what the spec says
• If the spec claims something is "broken" or "missing", check if it was fixed since the spec date

Example: A migration spec describes moving from state X to state Y, but direct verification shows the system is already in state Y. The problem statement and migration steps are therefore built on a false premise.

Example: A remediation spec cites failing tests, but running the current test suite shows they now pass after intervening changes. The remediation plan may no longer be needed.

Goals vs own caveats: Check whether the spec's goal-state descriptions or guarantees are contradicted by its own risk, assumption, or limitation sections. Specs often write aspirational goals first ("zero data loss", "automatic for all projects") and then add caveats later ("platform assumption: may not work for new projects"). If the caveat means the goal is unachievable, the goal section must be qualified — otherwise implementers and reviewers will rely on the unqualified claim.

Example: The goal promises automatic coverage for every newly created resource, while the risk section acknowledges that resources created after initialization are not covered. The goal contradicts the acknowledged limitation.

Guarantee claims under concurrency: When a spec makes a strong guarantee ("zero loss", "no downtime", "exactly-once", "always consistent"), don't accept the guarantee at face value. Verify it holds under ALL known concurrent actors in the system, not just the single path the spec analyzes. If the system has competing consumers, parallel workers, or async background tasks that touch the same state, check whether the guarantee accounts for their interference.

Example: A spec claims zero loss and proves it for the primary consumer, but a secondary consumer can hold an in-flight item when shutdown begins. The guarantee is overstated unless that parallel path is also covered.

Name/semantics consistency: When a spec introduces a new field, counter, or state variable, verify that its name implies the correct lifecycle. "Lifetime" implies surviving restarts; "persistent" implies disk storage; "global" implies cross-process. If the actual mechanism is an in-memory field that resets on process restart, the name is misleading and will cause implementers to rely on guarantees the mechanism can't deliver.

Example: A field is described as a lifetime counter but is stored only in memory and resets when its runtime state is recreated. The name promises persistence the mechanism cannot deliver.

3b. Ambiguity

Records where the same text can be reasonably interpreted two different ways, leading to different implementations.

Example: "Users can access their own data" — does "their own" mean data they created, or data about them that others created?

3c. Circular or Unresolvable Dependencies

Component A depends on B, B depends on C, C depends on A — or a dependency that doesn't exist yet with no plan to create it.

3d. Completeness Gaps

Things the spec must address given its scope but doesn't:

If the spec describes...	It should also address...
User-facing API	Authentication, rate limiting, error responses
Data storage	Retention policy, backup, migration
Multi-step workflow	Failure/retry at each step, partial completion
External integration	Timeout, fallback, version pinning
Concurrent access	Locking strategy, conflict resolution
Sensitive data	Encryption at rest/transit, access audit, PII handling
Multiple actors/roles	Each actor has a defined authentication flow
Phased execution plan	Each phase's rollback is independent of later phases
Downloaded binaries/deps	Integrity verification (checksum/signature)
Polling loop / consumer loop	Every branch path yields control (await/sleep); what happens when a message is rejected mid-loop (claim→reject→retry cycle)
Shared queue with filtered consumer	Filter mechanism (source-level query vs post-claim check); post-claim filter + retry = potential busy loop if the same message is re-claimed
Competing consumers on shared state	Not just multi-consumer races, but single-consumer self-loops (claim→can't process→release→re-claim same item)
Component migration/rename	All references updated (slash commands, table entries, prose text, description fields); governance checkpoints preserved; runtime dependencies still resolve; rollback covers every destructive step
Validation/verification step	Checks actually catch the failures they claim to prevent (grep patterns match all residual forms, not just one)
Fix/patch for a specific code path	Whether the fix interacts with parallel code paths that handle the same data differently — e.g., one path already paginates at the SQL layer while another paginates at the application layer; applying the same pagination to both causes double-application. When a spec proposes multiple alternative implementations ("approach A or approach B"), verify they are compatible; if mutually exclusive, the spec must choose one
Decision justified by external rule/standard	Source is identified with enough specificity (full file path or URL) for a reader unfamiliar with the project to independently locate and verify the cited rule
Error detection / catch-based recovery	The assumed error actually occurs on the described trigger path. Trace the code from trigger to catch: does the path pass through auto-creation layers (ensureDir, mkdirSync({recursive}), CREATE IF NOT EXISTS), retry wrappers, or fallback constructors that would swallow or prevent the error before it reaches the catch? A catch block that never fires is a safety net with no net.
Refactoring / code extraction	When the spec extracts, reorganizes, or replaces a code region, ALL branches in the original region are accounted for — not just the ones the spec names. Read the actual source lines being refactored; specs often describe 3 of 5 branches, and the 2 unnamed ones silently break. Adjacent logic (within ~20 lines of the described region) is especially likely to be missed.

3e. Vague Specification

Language that gives implementers too much freedom in security-critical areas:

• "appropriate security measures" — what specifically?
• "should handle errors gracefully" — what does graceful mean here?
• "may optionally support" — will it or won't it?
• "similar to X" — in what exact ways?

---

Phase 4 — Security Design Review (STRIDE)

Apply STRIDE threat categories to the spec's design, not to code. For each significant component or data flow described in the spec, ask:

Threat	Question for the Spec
Spoofing	Does the spec define how actors prove their identity? Can one actor impersonate another given this design?
Tampering	Does the spec protect data integrity in transit and at rest? Can messages/data be modified between components?
Repudiation	Does the spec include audit trails? Can actors deny performing actions?
Information Disclosure	Does the spec control who sees what? Are there data flows that cross trust boundaries without encryption/filtering?
Denial of Service	Does the spec address resource limits? Can any actor exhaust system resources?
Elevation of Privilege	Does the spec enforce least privilege? Can any actor gain permissions beyond their role?

Also apply Sharp Edges analysis to any API or configuration interface described in the spec:

• Are defaults secure?
• Can the "easy path" lead to insecurity?
• Are there dangerous configuration options without validation?
• Can parameters be confused or swapped?

For Light reviews, do a quick mental STRIDE pass — mention any relevant threats in your findings but don't produce a formal table. For Standard and Full reviews, you must produce a STRIDE summary table in the output showing which threats apply and which are adequately addressed by the spec. This structured output prevents "I thought about STRIDE but didn't write it down" — if it's not in the output, it didn't happen.

4b. Liveness & Control Flow Analysis

Skip 4b if the spec has no polling loops, queues, retry patterns, or competing consumers. Only read references/liveness-and-control-flow.md if the spec contains these patterns — don't load it for specs that only describe one-shot operations.

STRIDE misses self-inflicted availability failures. When the spec describes polling loops, shared queues, claim-process-confirm patterns, competing consumers, or retry/circuit breakers, check that every branch yields control and no deterministic infinite loops exist.

For details and pattern-specific questions, read references/liveness-and-control-flow.md.

---

Phase 5 — Project Alignment Check

Compare the spec against the existing project reality. This catches the "great design, wrong project" problem.

Check	What to Look For
Convention mismatch	Spec proposes patterns that contradict project AGENTS.md or rules
Dependency conflict	Spec assumes libraries/services that aren't available or conflict with existing ones
Interface incompatibility	Spec defines interfaces that don't match existing module signatures
Scope creep	Spec quietly introduces responsibilities that belong to existing modules
Naming inconsistency	Spec uses different terminology than the existing codebase for the same concepts
Infrastructure gap	Spec assumes infrastructure (message queue, cache, auth service) that doesn't exist
ADR drift	Spec proposes a decision that contradicts an existing ADR without acknowledging it (see §5a below)
Domain language drift	Spec terms diverge from CONTEXT.md vocabulary for the same concept

Skip this phase if there's no project context (standalone spec review).

Phase 5a — ADR Drift Detection

If docs/adr/ (or per-context docs/adr/) was indexed during Phase 1, check whether the spec's design decisions are consistent with documented architecture decisions.

For each ADR loaded during Phase 1:

1. Identify the decision. ADRs typically have a "Decision" or "Decision Outcome" section stating what was chosen and what was rejected.
2. Map to spec content. Find any spec section that touches the same area (technology choice, pattern, boundary, protocol, storage backend, auth mechanism, etc.).
3. Detect drift. Three drift modes:
   • Silent contradiction — Spec proposes the opposite of the ADR without mentioning the ADR. Severity: HIGH or CRITICAL. This is the worst case — the author either didn't know or chose to ignore the documented decision.
   • Implicit supersession — Spec proposes a different approach but doesn't formally supersede the ADR. Severity: HIGH. Even if the new approach is better, the ADR should be updated (status → Superseded) or a new ADR drafted, so future readers don't get conflicting signals.
   • Outdated ADR — Spec correctly identifies the ADR is no longer applicable (context changed, constraint lifted). Severity: MEDIUM, advisory. Recommend an updated/superseding ADR be drafted alongside this spec.

Output format (for each drift found):

[<severity>] ADR Drift — ADR-<NNNN> "<title>"
- ADR decision: <what the ADR concluded>
- Spec proposes: <what the spec proposes, with section reference>
- Drift mode: silent contradiction | implicit supersession | outdated ADR
- Recommendation: <update ADR / draft superseding ADR / acknowledge in spec / revise spec>

If docs/adr/ doesn't exist or wasn't indexed, skip this sub-phase.

---

Phase 5b — Execution Simulation

Phases 1-5 are auditor perspective — checking that the spec is internally consistent and externally aligned. This phase switches to operator perspective — walking through the spec as if you are the person executing it, step by step, looking for operational pitfalls that structural analysis misses.

Execution simulation catches operational gaps that structural analysis alone can miss, including governance checkpoints, runtime verification, rollback coverage, and validation sufficiency.

For Light reviews, do a quick mental walkthrough. For Standard and Full reviews, explicitly trace through each step.

Filesystem verification rule (all depths including Light): If the spec's premises describe or depend on the current state of files, directories, symlinks, or permissions, you MUST verify that state with actual commands before proceeding. Use ls -la for symlink detection (not file or stat, which follow symlinks). Use readlink for symlink target verification. Use cat to verify file contents the spec claims exist. A "mental walkthrough" does not exempt you from verifying the starting conditions — the walkthrough is only valid if its premises are true.

Skip 5b if the spec describes a static artifact without execution steps (e.g., API interface definition, data model schema, type system design). Execution simulation only applies to specs that prescribe a sequence of actions.

5b-1. Governance Compliance

Read the project's AGENTS.md and rules for [MUST] behavioral rules — not code conventions, but process mandates like "always ask user before X", "never do Y without confirmation". These are invisible to grep-based reference checks because they constrain actions, not code.

For each step in the spec, ask: does this step comply with all governance rules, or does it silently violate one?

Example: A project rule requires an explicit approval or synchronization checkpoint after installing a component, but the migration workflow omits that checkpoint.

5b-2. Runtime Dependency Verification

For each component the spec creates, modifies, or moves, ask: does it depend on something that only works at runtime (script paths, require() resolutions, external tool availability, environment variables)?

Static verification (frontmatter correct, line count reasonable) does not catch runtime breakage. If the spec includes a validation step, check whether it would actually catch a broken require() path or a missing external binary.

Example: A component depends on a dynamically resolved runtime script. Moving the component does not change its file content, but may change runtime resolution; only executing it reveals the breakage.

5b-3. Rollback Coverage Analysis

For each destructive action in the spec (delete, overwrite, rm -rf), ask:

1. What backup exists at this point?
2. If a problem is discovered after this action, can we recover?
3. Is there a window where all copies are destroyed simultaneously?

Pay special attention to specs with phased cleanup — phase N may delete the backup that phase N-1 relied on for rollback.

Example: A spec deletes the local backup after quality gates pass, then deletes the remote sync copy. If a problem surfaces after both deletions, there is no recovery source. A pre-cleanup snapshot closes this gap.

5b-4. Verification Sufficiency

For each validation/verification step in the spec, ask: would this check actually catch the failures it's supposed to prevent?

Common insufficiencies:

• Grep for path X but the actual residual is a slash-command name that doesn't contain X
• "Run tests" but the tests don't cover the specific migration concern
• "Verify frontmatter" but the real risk is runtime behavior

Example: A migration check searches for one path form, but stale invocation names do not contain that path. The check passes while residual references remain.

5b-5. Residual Artifact Consistency

When the spec removes references to a component (deletes imports, drops field declarations, removes call sites) but explicitly keeps the component's source file, ask:

1. Does the component's documentation (AGENTS.md, inline docs) still describe it as active or part of the architecture?
2. Does the component have its own test file that tests an outdated contract?
3. Does the component contain parallel logic that has diverged from the main system, such as normalization or validation code that lacks later fixes?

A component disconnected from its consumer but left in the repo will drift silently and become a trap for future developers who assume it reflects the current design.

Example: A spec disconnects a component from its consumer but keeps its source, tests, and documentation. The retained component contains parallel logic that has diverged from the live implementation, leaving a misleading zombie implementation in the repository.

---

Phase 5c — Scope Gap Analysis

Phases 1-5b ask "is what the spec says correct?" This phase asks the complementary question: "what important things does the spec NOT say?"

Structured review can create tunnel vision by focusing only on the spec's stated claims. A separate scope-gap pass must also inspect important adjacent architecture that the spec does not mention.

A spec that is internally consistent, externally aligned, and operationally sound can still be dangerously incomplete if the codebase has moved in directions the spec doesn't acknowledge.

When to run this phase

• Always for Full reviews
• For Standard reviews when Phase 1's temporal gap check found >10 commits or >1 week of divergence
• Skip for Light reviews and standalone specs without project context

How to find scope gaps

1. Compare spec scope against project state: Read the project's AGENTS.md, recent git log --oneline (last 20-30 commits), and architecture docs. Identify major features, subsystems, or capabilities that the spec's domain touches but doesn't mention. If adjacent execution paths share the same pipeline but are absent from the spec, the spec has a coverage gap.

2. Check for architectural changes since the spec date: If the spec was written at a specific point in time, scan commits between then and now for themes beyond what the spec covers. The spec may have correctly identified 3 problems, but if 5 other significant changes happened in the same period, the spec's picture of the project is incomplete.

3. Identify adjacent subsystems: Every spec has a scope boundary. Look at what's just outside that boundary — components that interact with the spec's subject but aren't reviewed. If a spec reviews "project isolation" but doesn't assess the resolution algorithm that determines which project a request belongs to, that's a meaningful gap.

Severity for scope gaps

Scope gaps are typically MEDIUM findings ("missing coverage"), not HIGH or CRITICAL — the spec is not wrong about what it says, it just doesn't say enough. Escalate to HIGH only if the missing coverage represents a real risk that the spec's recommendations would miss.

Output

Add a "Missing Coverage" or "Scope Gaps" section to the report listing what the spec should have addressed given its domain. For each gap, briefly explain why it matters and what the spec would say if it covered it.

---

Phase 6 — Report and Resolution

Issue Classification

Classify each finding by severity:

Severity	Criteria	Examples
CRITICAL	Would cause security vulnerability or data loss if built as-is	Missing auth on sensitive endpoint; trust boundary with no validation
HIGH	Would cause significant implementation problems or architectural debt	Internal contradiction; major completeness gap; wrong data model
MEDIUM	Would cause confusion or rework during implementation	Ambiguous requirement; vague error handling; naming inconsistency
LOW	Minor issues unlikely to cause real problems	Style inconsistency; minor terminology drift

Report Structure

Present findings as:

## Implementation Readiness Review: [Spec Name]

**Review depth:** Light | Standard | Full
**Spec path:** [path]
**Findings:** N critical, N high, N medium, N low

### CRITICAL

#### [C1] [Short title]
- **Location:** [spec section]
- **Issue:** [what's wrong]
- **Evidence:** [exact quote or reference]
- **Risk:** [what would happen if built as-is]
- **Recommendation:** [specific fix]

### HIGH
...

### Recommendations Summary
[Prioritized list of changes to make to the spec before implementation]

Resolution

After presenting findings:

1. Discuss with user — some findings may be intentional design choices
2. Apply approved fixes — use Edit to update the spec document directly
3. Re-check — after edits, do a quick pass to ensure fixes don't introduce new issues

---

Rationalizations to Reject

These are shortcuts that lead to missed findings. Resist them.

Rationalization	Why It's Wrong	Do This Instead
"The spec is short, so it's probably fine"	Short specs hide assumptions in what they don't say	Extract implicit assumptions explicitly
"This is just an internal tool"	Internal tools get promoted to production; internal attackers exist	Apply STRIDE proportionally but don't skip it
"The implementation will handle that"	If the spec doesn't specify it, implementations will diverge	Make the spec specify it, or explicitly mark it as implementation-defined
"That's an edge case"	Edge cases are where security bugs live	Document the expected behavior for every edge case
"I'll note it as low severity"	Low severity findings get ignored; be honest about impact	Classify accurately — if it could cause a real problem, it's not low
"The spec author probably meant..."	You're inferring, not reviewing	Quote the text; if it's ambiguous, flag it as ambiguous
"There's a rollback strategy section, so rollback is covered"	Having a section ≠ having complete coverage. Check if rollback covers every destructive step, including post-cleanup failures	Trace each destructive action and verify its specific recovery path
"The validation step exists, so it will catch problems"	A validation that checks X doesn't catch Y. Verify the check actually matches the failure mode	Ask: "if the specific failure I'm worried about happened, would this grep/test/check detect it?"
"The spec references the project rule, so it's compliant"	Referencing a rule ≠ embedding a compliance checkpoint in the workflow	Verify each [MUST] rule has a corresponding step in the execution flow, not just a mention in the design principles

---

Anti-Hallucination Rules

• Every finding must cite a specific spec section or project file
• If you're unsure whether something is a problem, classify it as MEDIUM with explicit uncertainty, not CRITICAL with false confidence
• Never infer what the spec "probably means" — if it's unclear, that IS the finding
• Do not invent threats that the spec's scope doesn't cover (e.g., don't STRIDE-analyze a logging spec for DoS unless logging could actually cause DoS)
• Distinguish between "the spec doesn't address X" (completeness gap) and "the spec addresses X incorrectly" (design flaw) — these have different severities