feat(agents): add thinking model guidance reference files (#1722) (#1820)

Combines implementation by @davesienkowski (inline @-reference wiring at
decision-point steps, named reasoning models with anti-patterns, sequencing
rules, Gap Closure Mode) and @Tibsfox (test suite covering file existence,
section structure, and agent wiring).

- 5 reference files in get-shit-done/references/ — each with named reasoning
  models, Counters annotations, Conflict Resolution sequencing, and When NOT
  to Think guidance
- Inline @-reference wiring placed inside the specific step/section blocks
  where thinking decisions occur (not at top-of-agent)
- Planning cluster includes Gap Closure Mode root-cause check section
- Test suite: 63 tests covering file existence, named models, Conflict
  Resolution sections, Gap Closure Mode, and inline wiring placement

Closes #1722

Co-authored-by: Tibsfox <tibsfox@users.noreply.github.com>
Co-authored-by: Rezolv <davesienkowski@users.noreply.github.com>
Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>

agents/gsd-debugger.md

@@ -957,6 +957,9 @@ Gather symptoms through questioning. Update file after EACH answer.
 </step>
 
 <step name="investigation_loop">
+At investigation decision points, apply structured reasoning:
+@~/.claude/get-shit-done/references/thinking-models-debug.md
+
 **Autonomous investigation. Update file continuously.**
 
 **Phase 0: Check knowledge base**

agents/gsd-executor.md

@@ -95,6 +95,9 @@ grep -n "type=\"checkpoint" [plan-path]
 </step>
 
 <step name="execute_tasks">
+At execution decision points, apply structured reasoning:
+@~/.claude/get-shit-done/references/thinking-models-execution.md
+
 For each task:
 
 1. **If `type="auto"`:**

agents/gsd-phase-researcher.md

@@ -461,6 +461,9 @@ Verified patterns from official sources:
 
 <execution_flow>
 
+At research decision points, apply structured reasoning:
+@~/.claude/get-shit-done/references/thinking-models-research.md
+
 ## Step 1: Receive Scope and Load Context
 
 Orchestrator provides: phase number/name, description/goal, requirements, constraints, output path.

agents/gsd-plan-checker.md

@@ -80,6 +80,9 @@ Same methodology (goal-backward), different timing, different subject matter.
 
 <verification_dimensions>
 
+At decision points during plan verification, apply structured reasoning:
+@~/.claude/get-shit-done/references/thinking-models-planning.md
+
 ## Dimension 1: Requirement Coverage
 
 **Question:** Does every phase requirement have task(s) addressing it?

agents/gsd-planner.md

@@ -1022,6 +1022,9 @@ cat "$phase_dir"/*-DISCOVERY.md 2>/dev/null  # From mandatory discovery
 </step>
 
 <step name="break_into_tasks">
+At decision points during plan creation, apply structured reasoning:
+@~/.claude/get-shit-done/references/thinking-models-planning.md
+
 Decompose phase into tasks. **Think dependencies first, not sequence.**
 
 For each task:

agents/gsd-verifier.md

@@ -57,6 +57,9 @@ Then verify each level against the actual codebase.
 
 <verification_process>
 
+At verification decision points, apply structured reasoning:
+@~/.claude/get-shit-done/references/thinking-models-verification.md
+
 ## Step 0: Check for Previous Verification
 
 ```bash

get-shit-done/references/thinking-models-debug.md

@@ -0,0 +1,44 @@
+# Thinking Models: Debug Cluster
+
+Structured reasoning models for the **debugger** agent. Apply these at decision points during investigation, not continuously. Each model counters a specific documented failure mode.
+
+Source: Curated from [thinking-partner](https://github.com/mattnowdev/thinking-partner) model catalog (150+ models). Selected for direct applicability to GSD debugging workflow.
+
+## Conflict Resolution
+
+**Fault Tree and Hypothesis-Driven are sequential:** Fault Tree FIRST (generate the tree of possible causes), Hypothesis-Driven SECOND (test each branch systematically). Fault Tree provides the map; Hypothesis-Driven provides the discipline to traverse it.
+
+## 1. Fault Tree Analysis
+
+**Counters:** Jumping to conclusions without systematically mapping failure paths.
+
+Before testing any hypothesis, build a fault tree: start with the observed symptom as the root node, then branch into all possible causes at each level (hardware, software, configuration, data, environment). Use AND/OR gates -- some failures require multiple conditions (AND), others have independent triggers (OR). This tree becomes your investigation roadmap. Prioritize branches by likelihood and testability, but do NOT prune branches just because they seem unlikely -- unlikely causes that are easy to test should be tested early.
+
+## 2. Hypothesis-Driven Investigation
+
+**Counters:** Making random changes and hoping something works -- the "shotgun debugging" anti-pattern.
+
+For each hypothesis from the fault tree, follow the strict protocol: PREDICT ("If hypothesis H is correct, then test T should produce result R"), TEST (execute exactly one test), OBSERVE (record the actual result), CONCLUDE (matched = SUPPORTED, failed = ELIMINATED, unexpected = new evidence). Never skip the PREDICT step -- without a prediction, you cannot distinguish a meaningful result from noise. Never change more than one variable per test -- if you change two things and the bug disappears, you don't know which change fixed it.
+
+## 3. Occam's Razor
+
+**Counters:** Pursuing elaborate explanations when simple ones have not been ruled out.
+
+Before investigating complex multi-component interaction bugs, race conditions, or framework-level issues, verify the simple explanations first: typo in variable name, wrong file path, missing import, incorrect config value, stale cache, wrong environment variable. These "boring" causes account for the majority of bugs. Only escalate to complex hypotheses AFTER the simple ones are eliminated. If your current hypothesis requires 3+ things to go wrong simultaneously, step back and look for a single-point failure.
+
+## 4. Counterfactual Thinking
+
+**Counters:** Failing to isolate causation by not asking "what if we changed just this one thing?"
+
+When you have a hypothesis about the root cause, construct a counterfactual: "If I change ONLY this one variable/config/line, the bug should disappear (or appear)." Execute the counterfactual test. If the bug persists after your targeted change, your hypothesis is wrong -- the cause is elsewhere. If the bug disappears, you have strong causal evidence. This is more powerful than correlation ("the bug appeared after deploy X") because it tests the mechanism, not just the timeline.
+
+---
+
+## When NOT to Think
+
+Skip structured reasoning models when the situation does not benefit from them:
+
+- **Obvious single-cause bugs** -- If the error message names the exact file, line, and cause (e.g., `TypeError: Cannot read property 'x' of undefined at foo.js:42`), fix it directly. Do not build a fault tree for a null reference with a stack trace.
+- **Reproducing a known fix** -- If you already know the root cause from a previous investigation or the user told you exactly what is wrong, skip hypothesis-driven investigation and go straight to the fix.
+- **Typos, missing imports, wrong paths** -- If Occam's Razor would immediately resolve it, apply the fix without invoking the full model. The model exists for when simple checks fail, not to gate simple checks.
+- **Reading error logs** -- Reading and understanding error output is normal debugging, not a "decision point." Only invoke models when you have multiple plausible hypotheses and need to choose which to test first.

get-shit-done/references/thinking-models-execution.md

@@ -0,0 +1,50 @@
+# Thinking Models: Execution Cluster
+
+Structured reasoning models for the **executor** agent. Apply these at decision points during task execution, not continuously. Each model counters a specific documented failure mode.
+
+Source: Curated from [thinking-partner](https://github.com/mattnowdev/thinking-partner) model catalog (150+ models). Selected for direct applicability to GSD execution workflow.
+
+## Conflict Resolution
+
+**Forcing Function and First Principles both push toward "do it now".** Run First Principles FIRST (understand the constraint), Forcing Function SECOND (create the mechanism). Sequential, not competing.
+
+## 1. Circle of Concern vs Circle of Control
+
+**Counters:** Executor trying to fix things outside its scope -- upstream bugs, unrelated tech debt, infrastructure issues.
+
+Before modifying any code not explicitly listed in the plan's `<files>` section, ask: Is this in my Circle of Control (plan scope) or my Circle of Concern (things I notice but shouldn't fix)? If Circle of Concern: document it as a deviation note or deferred item, do NOT fix it. The executor's job is to build what the plan says, not to improve the codebase. Scope creep from "while I'm here" fixes is the #1 cause of executor overruns.
+
+## 2. Forcing Function
+
+**Counters:** Deferring hard decisions to runtime instead of resolving them at build time.
+
+When you encounter an ambiguous requirement or unclear integration point, create a forcing function that makes the decision explicit NOW rather than hiding it behind a TODO or runtime check. Examples: use a TypeScript `never` type to force exhaustive switches, add a build-time assertion for required config values, create an interface that forces callers to handle error cases. If a decision truly cannot be made at build time, document it as a `checkpoint:decision` deviation -- do not silently defer.
+
+## 3. First Principles Thinking
+
+**Counters:** Copying patterns from existing code without understanding whether they fit the current task.
+
+Before copying a pattern from another file or phase, decompose WHY that pattern exists: What constraint does it satisfy? Does your current task have the same constraint? If not, the pattern may be cargo cult. Build your implementation from the task's actual requirements, not from the nearest existing example. When in doubt, the plan's `<action>` steps define what to build -- derive the implementation from those, not from adjacent code.
+
+## 4. Occam's Razor
+
+**Counters:** Over-engineering simple tasks with unnecessary abstractions, generics, or future-proofing.
+
+Before adding an abstraction layer, generic type parameter, factory pattern, or configuration option, ask: Does the plan REQUIRE this flexibility? If the plan says "create a function that does X", create a function that does X -- not a configurable, extensible, pluggable framework that could theoretically do X through Y through Z. The simplest implementation that satisfies the plan's `<done>` condition is the correct one. Add complexity only when the plan explicitly calls for it.
+
+## 5. Chesterton's Fence
+
+**Counters:** Removing or modifying existing code without understanding why it was written that way.
+
+Before removing, replacing, or significantly modifying existing code that the plan touches, determine WHY it exists. Check: git blame for the commit that introduced it, comments explaining the rationale, test cases that exercise it, the PLAN.md or SUMMARY.md that created it. If the purpose is unclear, keep it and add a comment noting the uncertainty -- do NOT remove code whose purpose you don't understand. If the plan explicitly says to remove it, still document what it did in the deviation notes.
+
+---
+
+## When NOT to Think
+
+Skip structured reasoning models when the situation does not benefit from them:
+
+- **Straightforward task actions** -- If the plan says "create file X with content Y" and the action is unambiguous, execute it directly. Do not invoke First Principles to analyze why you are creating a file the plan told you to create.
+- **Following established project patterns** -- If the codebase has a clear, consistent pattern (e.g., every route handler follows the same structure) and the plan says to add another one, follow the pattern. Chesterton's Fence applies to removing patterns, not to following them.
+- **Trivial file edits** -- Adding an import, fixing a typo, updating a version number. These are mechanical changes that do not involve design decisions.
+- **Running verify commands** -- Executing the plan's `<verify>` steps is procedural. Only invoke models if a verify step fails and you need to decide how to respond.

get-shit-done/references/thinking-models-planning.md

@@ -0,0 +1,62 @@
+# Thinking Models: Planning Cluster
+
+Structured reasoning models for the **planner** and **roadmapper** agents. Apply these at decision points during plan creation, not continuously. Each model counters a specific documented failure mode.
+
+Source: Curated from [thinking-partner](https://github.com/mattnowdev/thinking-partner) model catalog (150+ models). Selected for direct applicability to GSD planning workflow.
+
+## Conflict Resolution
+
+Pre-Mortem and Constraint Analysis both analyze risk at different granularities. Run Constraint Analysis FIRST (identify the hardest constraint), then Pre-Mortem (enumerate failure modes around that constraint and the rest of the plan).
+
+## 1. Pre-Mortem Analysis
+
+**Counters:** Optimistic plan decomposition that ignores failure modes.
+
+Before finalizing this plan, assume it has already failed. List the 3 most likely reasons for failure -- missing dependency, wrong decomposition, underestimated complexity -- and add mitigation steps or acceptance criteria that would catch each failure early.
+
+## 2. MECE Decomposition
+
+**Counters:** Overlapping tasks (merge conflicts) or gapped tasks (missing requirements).
+
+Verify this task breakdown is MECE at the REQUIREMENT level: (1) list every requirement from the phase goal, (2) confirm each maps to exactly one task's `<done>`, (3) if two tasks modify the same file, confirm they modify DIFFERENT sections or serve DIFFERENT requirements, (4) flag any requirement not covered by any task.
+
+## 3. Constraint Analysis
+
+**Counters:** Deferring the hardest constraint to the last task, causing late-stage failures.
+
+Identify the single hardest constraint in this phase -- the one thing that, if it doesn't work, makes everything else irrelevant. Schedule that constraint as Task 1 or 2, not last. If the constraint involves an external API or unfamiliar library, add a spike/proof-of-concept task before the main implementation.
+
+## 4. Reversibility Test
+
+**Counters:** Over-analyzing cheap decisions, under-analyzing costly ones.
+
+For each significant decision in this plan, classify as REVERSIBLE (can change later with low cost) or IRREVERSIBLE (changing later requires migration, breaking changes, or significant rework). Spend analysis time proportional to irreversibility. For irreversible decisions, document the rationale in the plan.
+
+## 5. Curse of Knowledge Counter
+
+**Counters:** Plan-to-executor ambiguity from compressed instructions.
+
+For each `<action>` step, re-read it as if you have NEVER seen this codebase. Is every noun unambiguous (which file? which function? which endpoint?)? Is every verb specific (add WHERE? modify HOW?)? If a step could be interpreted two ways, rewrite it. Include file paths, function names, and expected behavior in every action step.
+
+## 6. Base Rate Neglect Counter
+
+**Counters:** Planners ignoring low-confidence research caveats.
+
+Before finalizing the plan, read ALL `[NEEDS DECISION]` items and LOW-confidence recommendations from SUMMARY.md. For each: either (a) create a `checkpoint:decision` task to resolve it, or (b) document why the risk is acceptable in the plan's deviation notes. LOW-confidence items that are silently accepted become undocumented technical debt.
+
+## Gap Closure Mode: Root-Cause Check
+
+**Applies only when:** Planner enters gap closure mode (triggered by `gaps_found` in VERIFICATION.md).
+
+Before writing the fix plan, apply a single "why" round: Why did this gap occur? Was it a plan deficiency (wrong task), an execution miss (correct task, wrong implementation), or a changed assumption (environment/dependency shift)? The fix plan must target the root cause category, not just the symptom.
+
+---
+
+## When NOT to Think
+
+Skip structured reasoning models when the situation does not benefit from them:
+
+- **Single-task plans** -- If the phase has one clear requirement and one obvious task, do not run Pre-Mortem or MECE analysis. Write the task directly.
+- **Well-researched phases** -- If RESEARCH.md has HIGH-confidence recommendations for every decision and no `[NEEDS DECISION]` items, skip Base Rate Neglect Counter. The research already resolved uncertainty.
+- **Revision iterations** -- When revising a plan based on checker feedback, focus on fixing the flagged issues. Do not re-run the full model suite on every revision pass -- apply only the model relevant to the specific issue (e.g., MECE if the checker found a coverage gap).
+- **Boilerplate plans** -- Configuration changes, version bumps, documentation updates. These do not have failure modes worth pre-mortem analysis.

get-shit-done/references/thinking-models-research.md

@@ -0,0 +1,50 @@
+# Thinking Models: Research Cluster
+
+Structured reasoning models for the **researcher** and **synthesizer** agents. Apply these at decision points during research and synthesis, not continuously. Each model counters a specific documented failure mode.
+
+Source: Curated from [thinking-partner](https://github.com/mattnowdev/thinking-partner) model catalog (150+ models). Selected for direct applicability to GSD research workflow.
+
+## Conflict Resolution
+
+**First Principles and Steel Man both expand scope** -- run First Principles FIRST (decompose the problem), then Steel Man (strengthen alternatives). Don't run simultaneously.
+
+## 1. First Principles Thinking
+
+**Counters:** Accepting surface-level explanations without decomposing into fundamental components.
+
+Before accepting any technology recommendation or architectural pattern, decompose it to its fundamental constraints: What problem does this solve? What are the non-negotiable requirements? What are the physical/logical limits? Build your recommendation UP from these constraints rather than DOWN from conventional wisdom. If you cannot explain WHY a recommendation is correct from first principles, flag it as `[LOW]` regardless of source count.
+
+## 2. Simpson's Paradox Awareness
+
+**Counters:** Synthesizer aggregating conflicting research without checking for confounding splits.
+
+When combining findings from multiple research documents that show contradictory results, check whether the contradiction disappears when you split by a hidden variable: framework version, deployment target, project scale, or use case category. A library that benchmarks faster overall may be slower for YOUR specific workload. Before resolving contradictions by majority vote, ask: "Is there a subgroup split that explains why both findings are correct in their own context?"
+
+## 3. Survivorship Bias
+
+**Counters:** Only finding successful examples while missing failures and abandoned approaches.
+
+After gathering evidence FOR a recommended approach, actively search for projects that ABANDONED it. Check GitHub issues for "migrated away from", "replaced X with", or "problems with X at scale". A technology with 10 success stories and 100 quiet failures looks great until you check the graveyard. Weight negative evidence (migration-away stories, deprecation notices, unresolved issues) MORE heavily than positive evidence -- failures are underreported.
+
+## 4. Confirmation Bias Counter
+
+**Counters:** Searching for evidence that confirms initial hypothesis while ignoring disconfirming evidence.
+
+After forming your initial recommendation, spend one full research cycle searching AGAINST it. Use search terms like "{technology} problems", "{technology} alternatives", "why not {technology}", "{technology} vs {competitor}". For each piece of disconfirming evidence found, either (a) refute it with higher-confidence sources, or (b) add it as a caveat to your recommendation. If you cannot find ANY criticism of your recommendation, your search was too narrow -- widen it.
+
+## 5. Steel Man
+
+**Counters:** Dismissing alternative approaches without giving them their strongest possible form.
+
+Before recommending against an alternative technology or approach, construct its STRONGEST possible case. What would a passionate advocate say? What use cases does it serve better than your recommendation? What trade-offs favor it? Present the steel-manned alternative alongside your recommendation with an honest comparison. If the steel-manned alternative is competitive, flag the decision as `[NEEDS DECISION]` rather than making a unilateral recommendation.
+
+---
+
+## When NOT to Think
+
+Skip structured reasoning models when the situation does not benefit from them:
+
+- **Locked decisions from CONTEXT.md** -- If the user already decided "use library X", do not run Steel Man analysis on alternatives or First Principles decomposition of the choice. Research how to use X well, not whether X is the right choice.
+- **Standard stack lookups** -- If you are simply checking the latest version of a well-known library or reading its API docs, do not invoke Survivorship Bias or Confirmation Bias Counter. These models are for evaluating contested recommendations, not for factual lookups.
+- **Single-technology phases** -- If the phase involves one technology with no alternatives to evaluate (e.g., "add ESLint rule X"), skip comparative models (Steel Man, Confirmation Bias Counter). Just research the implementation.
+- **Codebase-only research** -- If the research is purely internal (understanding existing code patterns, finding where a function is called), structured reasoning models add no value. Use grep and read the code.

get-shit-done/references/thinking-models-verification.md

@@ -0,0 +1,55 @@
+# Thinking Models: Verification Cluster
+
+Structured reasoning models for the **verifier** and **plan-checker** agents. Apply these during verification passes, not continuously. Each model counters a specific documented failure mode.
+
+Source: Curated from [thinking-partner](https://github.com/mattnowdev/thinking-partner) model catalog (150+ models). Selected for direct applicability to GSD verification workflow.
+
+## Conflict Resolution
+
+**Inversion** and **Confirmation Bias Counter** both look for failures but serve different purposes. Run them in sequence:
+
+1. **Inversion FIRST** (brainstorm): generate 3 ways this could be wrong
+2. **Confirmation Bias Counter SECOND** (structured check): find one partial requirement, one misleading test, one uncovered error path
+
+Inversion generates the list; Confirmation Bias Counter is the discipline to verify items on it.
+
+## 1. Inversion
+
+**Counters:** Verifiers confirming success rather than finding failures.
+
+Instead of checking what IS correct, list 3 specific ways this implementation could be WRONG despite passing tests: missing edge cases, silent data loss, race conditions, unhandled error paths. For each, write a concrete check (grep for pattern, test with specific input, verify error handling exists). Additionally, check whether any documented DEVIATION in SUMMARY.md changes the meaning or applicability of a must-have. If a must-have was written assuming approach A but the executor used approach B, the must-have may need reinterpretation, not literal checking.
+
+## 2. Chesterton's Fence
+
+**Counters:** Flagging purposeful code as dead or unnecessary.
+
+Before flagging any existing code as dead, redundant, or overcomplicated, determine WHY it was written that way. Check git blame, comments, test cases, and the PLAN.md that created it. If the reason is unclear, flag as "purpose unknown -- recommend keeping with WARNING, not removing" and include the git blame hash for the commit that introduced it.
+
+## 3. Confirmation Bias Counter
+
+**Counters:** Verifiers primed by SUMMARY.md claims to see success.
+
+After your initial verification pass, do a DISCONFIRMATION pass: (1) find one requirement that is only partially met, (2) find one test that passes but does not actually test the stated behavior, (3) find one error path that has no test coverage. Report these even if overall verification passes.
+
+## 4. Planning Fallacy Calibration
+
+**Counters:** Accepting over-scoped plans as reasonable (plan-checker).
+
+For each task estimated as "simple" or "small", check: does it touch more than 2 files? Does it require understanding an unfamiliar API? Does it modify shared infrastructure? If yes to any, flag as likely underestimated. Plans with >5 tasks or tasks touching >4 files per task are over-scoped.
+
+## 5. Counterfactual Thinking
+
+**Counters:** Plans that assume success at every step with no error recovery (plan-checker).
+
+For each plan, ask: "What would happen if the executor followed this plan EXACTLY as written but encountered a common failure: dependency version mismatch, API returning unexpected format, file already modified by prior plan?" If the plan has no contingency path and the `<action>` steps assume success at every point, flag as WARNING: "No error recovery path for task T{n}."
+
+---
+
+## When NOT to Think
+
+Skip structured reasoning models when the situation does not benefit from them:
+
+- **Re-verification of previously passed items** -- When in re-verification mode, items that passed the initial check only need a quick regression check (existence + basic sanity), not the full Inversion + Confirmation Bias Counter treatment.
+- **Binary existence checks** -- If a must-have is "file X exists with >N lines" and the file clearly exists with substantive content, do not run Counterfactual Thinking on it. Reserve models for ambiguous or wiring-dependent must-haves.
+- **Straightforward test results** -- If `<verify>` commands produce clear pass/fail output (e.g., test suite exits 0 with all tests passing), accept the result. Only invoke models when test results are ambiguous or when you suspect the tests do not actually test what they claim.
+- **INFO-level issues** -- Do not apply structured reasoning to decide whether an INFO-level observation is actually a BLOCKER. INFO items are informational by definition and never trigger gates.

tests/thinking-model-guidance.test.cjs

@@ -0,0 +1,231 @@
+/**
+ * Thinking Model Guidance Reference Tests
+ *
+ * Validates that all 5 thinking model reference files exist with required
+ * sections, and that each of the 6 relevant agent files references its
+ * thinking model guidance doc via inline @-reference wiring placed inside
+ * the specific step/section blocks where thinking decisions occur.
+ */
+
+'use strict';
+
+const { describe, test } = require('node:test');
+const assert = require('node:assert/strict');
+const fs = require('fs');
+const path = require('path');
+
+const REFERENCES_DIR = path.join(__dirname, '..', 'get-shit-done', 'references');
+const AGENTS_DIR = path.join(__dirname, '..', 'agents');
+
+const THINKING_CONTEXTS = ['debug', 'execution', 'planning', 'research', 'verification'];
+
+// Sections present in #1791-style content (named models with anti-patterns, not generic schema)
+const REQUIRED_SECTIONS = [
+  '## Conflict Resolution',
+  '## When NOT to Think',
+];
+
+// Sections present in all files regardless of approach
+const UNIVERSAL_SECTIONS = [
+  '## When NOT to Think',
+];
+
+// Named models expected in each file (from #1791 content)
+const NAMED_MODELS = {
+  'debug': ['Fault Tree Analysis', 'Hypothesis-Driven Investigation', 'Occam\'s Razor', 'Counterfactual Thinking'],
+  'execution': ['Circle of Concern vs Circle of Control', 'Forcing Function', 'First Principles Thinking', 'Occam\'s Razor', 'Chesterton\'s Fence'],
+  'planning': ['Pre-Mortem Analysis', 'MECE Decomposition', 'Constraint Analysis', 'Reversibility Test'],
+  'research': ['First Principles Thinking', 'Simpson\'s Paradox Awareness', 'Survivorship Bias', 'Confirmation Bias Counter', 'Steel Man'],
+  'verification': ['Inversion', 'Chesterton\'s Fence', 'Confirmation Bias Counter', 'Planning Fallacy Calibration', 'Counterfactual Thinking'],
+};
+
+// Sequencing rules are documented in Conflict Resolution sections
+const SEQUENCING_CONTEXTS = ['debug', 'execution', 'planning', 'research', 'verification'];
+
+// Gap Closure Mode is only in planning
+const GAP_CLOSURE_CONTEXT = 'planning';
+
+// Inline wiring: agent -> { refFile, wiredInsideBlock }
+// wiredInsideBlock is a string that should appear BEFORE the @-reference in the agent file,
+// confirming the reference is inside a specific step/section (not at top-of-agent)
+const AGENT_WIRING = {
+  'gsd-debugger': {
+    refFile: 'thinking-models-debug.md',
+    wiredInsideBlock: 'step name="investigation_loop"',
+    wiredInsideText: 'At investigation decision points, apply structured reasoning',
+  },
+  'gsd-executor': {
+    refFile: 'thinking-models-execution.md',
+    wiredInsideBlock: 'step name="execute_tasks"',
+    wiredInsideText: 'At execution decision points, apply structured reasoning',
+  },
+  'gsd-planner': {
+    refFile: 'thinking-models-planning.md',
+    wiredInsideBlock: 'step name="break_into_tasks"',
+    wiredInsideText: 'At decision points during plan creation, apply structured reasoning',
+  },
+  'gsd-phase-researcher': {
+    refFile: 'thinking-models-research.md',
+    wiredInsideBlock: 'execution_flow',
+    wiredInsideText: 'At research decision points, apply structured reasoning',
+  },
+  'gsd-plan-checker': {
+    refFile: 'thinking-models-planning.md',
+    wiredInsideBlock: 'verification_dimensions',
+    wiredInsideText: 'At decision points during plan verification, apply structured reasoning',
+  },
+  'gsd-verifier': {
+    refFile: 'thinking-models-verification.md',
+    wiredInsideBlock: 'verification_process',
+    wiredInsideText: 'At verification decision points, apply structured reasoning',
+  },
+};
+
+// ─── Reference File Existence ────────────────────────────────────────────────
+
+describe('thinking model reference files exist', () => {
+  for (const context of THINKING_CONTEXTS) {
+    test(`thinking-models-${context}.md exists`, () => {
+      const filePath = path.join(REFERENCES_DIR, `thinking-models-${context}.md`);
+      assert.ok(fs.existsSync(filePath), `Missing reference file: thinking-models-${context}.md`);
+    });
+  }
+});
+
+// ─── Reference File Universal Sections ──────────────────────────────────────
+
+describe('thinking model reference files have required sections', () => {
+  for (const context of THINKING_CONTEXTS) {
+    describe(`thinking-models-${context}.md`, () => {
+      const filePath = path.join(REFERENCES_DIR, `thinking-models-${context}.md`);
+      let content;
+
+      try {
+        content = fs.readFileSync(filePath, 'utf-8');
+      } catch {
+        content = '';
+      }
+
+      for (const section of UNIVERSAL_SECTIONS) {
+        test(`contains "${section}"`, () => {
+          assert.ok(
+            content.includes(section),
+            `thinking-models-${context}.md missing section: ${section}`
+          );
+        });
+      }
+
+      test('contains Conflict Resolution sequencing rules', () => {
+        assert.ok(
+          content.includes('## Conflict Resolution'),
+          `thinking-models-${context}.md missing ## Conflict Resolution section (sequencing rules)`
+        );
+      });
+    });
+  }
+});
+
+// ─── Named Reasoning Models ──────────────────────────────────────────────────
+
+describe('thinking model reference files contain named reasoning models', () => {
+  for (const [context, models] of Object.entries(NAMED_MODELS)) {
+    describe(`thinking-models-${context}.md`, () => {
+      const filePath = path.join(REFERENCES_DIR, `thinking-models-${context}.md`);
+      let content;
+
+      try {
+        content = fs.readFileSync(filePath, 'utf-8');
+      } catch {
+        content = '';
+      }
+
+      for (const model of models) {
+        test(`contains named model "${model}"`, () => {
+          assert.ok(
+            content.includes(model),
+            `thinking-models-${context}.md missing named model: ${model}`
+          );
+        });
+      }
+
+      test('each named model documents what failure mode it counters', () => {
+        assert.ok(
+          content.includes('**Counters:**'),
+          `thinking-models-${context}.md: named models must document what failure mode they counter via **Counters:** prefix`
+        );
+      });
+    });
+  }
+});
+
+// ─── Gap Closure Mode (planning only) ────────────────────────────────────────
+
+describe('thinking-models-planning.md contains Gap Closure Mode section', () => {
+  const filePath = path.join(REFERENCES_DIR, `thinking-models-${GAP_CLOSURE_CONTEXT}.md`);
+  let content;
+
+  try {
+    content = fs.readFileSync(filePath, 'utf-8');
+  } catch {
+    content = '';
+  }
+
+  test('contains Gap Closure Mode section', () => {
+    assert.ok(
+      content.includes('Gap Closure Mode'),
+      'thinking-models-planning.md missing Gap Closure Mode section'
+    );
+  });
+
+  test('Gap Closure Mode section references gap closure trigger condition', () => {
+    assert.ok(
+      content.includes('gaps_found') || content.includes('gap closure mode'),
+      'thinking-models-planning.md Gap Closure Mode section missing trigger condition reference'
+    );
+  });
+});
+
+// ─── Inline Agent Wiring (decision-point placement) ──────────────────────────
+
+describe('agent files use inline @-reference wiring at decision points', () => {
+  for (const [agent, wiring] of Object.entries(AGENT_WIRING)) {
+    describe(`${agent}.md`, () => {
+      const agentPath = path.join(AGENTS_DIR, `${agent}.md`);
+      let content;
+
+      try {
+        content = fs.readFileSync(agentPath, 'utf-8');
+      } catch {
+        content = '';
+      }
+
+      test(`references ${wiring.refFile} via inline @-reference`, () => {
+        assert.ok(
+          content.includes(wiring.refFile),
+          `${agent}.md does not reference ${wiring.refFile}`
+        );
+      });
+
+      test(`wiring is placed inside the correct block (${wiring.wiredInsideBlock})`, () => {
+        assert.ok(
+          content.includes(wiring.wiredInsideBlock),
+          `${agent}.md does not contain expected block: ${wiring.wiredInsideBlock}`
+        );
+
+        // Confirm the decision-point annotation appears alongside the reference
+        assert.ok(
+          content.includes(wiring.wiredInsideText),
+          `${agent}.md missing decision-point annotation: "${wiring.wiredInsideText}"`
+        );
+      });
+
+      test('does NOT use <required_reading> block (inline wiring only)', () => {
+        assert.equal(
+          content.includes('<required_reading>'),
+          false,
+          `${agent}.md uses <required_reading> block — should use inline @-reference wiring instead`
+        );
+      });
+    });
+  }
+});