diff --git a/.github/workflows/test.yml b/.github/workflows/test.yml
index 53d1e32..abd3a88 100644
--- a/.github/workflows/test.yml
+++ b/.github/workflows/test.yml
@@ -56,6 +56,9 @@ jobs:
         working-directory: ./website
         run: npx playwright install --with-deps chromium
 
+      - name: Generate llms.txt and all-anchors.adoc
+        run: node scripts/generate-llms-txt.js
+
       - name: Copy documentation files to public directory
         run: |
           mkdir -p website/public/docs
diff --git a/docs/all-anchors.adoc b/docs/all-anchors.adoc
new file mode 100644
index 0000000..0c8d96b
--- /dev/null
+++ b/docs/all-anchors.adoc
@@ -0,0 +1,156 @@
+= Semantic Anchors — Complete Reference
+:toc:
+:toc-placement: preamble
+:toclevels: 2
+
+include::about.adoc[leveloffset=+1]
+
+<<<
+
+== Communication & Presentation
+
+include::anchors/bluf.adoc[leveloffset=+2]
+
+include::anchors/chatham-house-rule.adoc[leveloffset=+2]
+
+include::anchors/mece.adoc[leveloffset=+2]
+
+include::anchors/pyramid-principle.adoc[leveloffset=+2]
+
+<<<
+
+== Design Principles & Patterns
+
+include::anchors/dry-principle.adoc[leveloffset=+2]
+
+include::anchors/fowler-patterns.adoc[leveloffset=+2]
+
+include::anchors/solid-principles.adoc[leveloffset=+2]
+
+include::anchors/spot-principle.adoc[leveloffset=+2]
+
+include::anchors/ssot-principle.adoc[leveloffset=+2]
+
+<<<
+
+== Development Workflow
+
+include::anchors/bem-methodology.adoc[leveloffset=+2]
+
+include::anchors/conventional-commits.adoc[leveloffset=+2]
+
+include::anchors/mental-model-according-to-naur.adoc[leveloffset=+2]
+
+include::anchors/semantic-versioning.adoc[leveloffset=+2]
+
+include::anchors/sota.adoc[leveloffset=+2]
+
+include::anchors/timtowtdi.adoc[leveloffset=+2]
+
+include::anchors/todotxt-flavoured-markdown.adoc[leveloffset=+2]
+
+<<<
+
+== Dialogue Interaction
+
+include::anchors/socratic-method.adoc[leveloffset=+2]
+
+<<<
+
+== Documentation
+
+include::anchors/diataxis-framework.adoc[leveloffset=+2]
+
+include::anchors/docs-as-code.adoc[leveloffset=+2]
+
+<<<
+
+== Meta
+
+include::anchors/what-qualifies-as-a-semantic-anchor.adoc[leveloffset=+2]
+
+<<<
+
+== Problem Solving
+
+include::anchors/chain-of-thought.adoc[leveloffset=+2]
+
+include::anchors/devils-advocate.adoc[leveloffset=+2]
+
+include::anchors/feynman-technique.adoc[leveloffset=+2]
+
+include::anchors/five-whys.adoc[leveloffset=+2]
+
+include::anchors/morphological-box.adoc[leveloffset=+2]
+
+include::anchors/rubber-duck-debugging.adoc[leveloffset=+2]
+
+<<<
+
+== Requirements Engineering
+
+include::anchors/ears-requirements.adoc[leveloffset=+2]
+
+include::anchors/problem-space-nvc.adoc[leveloffset=+2]
+
+include::anchors/user-story-mapping.adoc[leveloffset=+2]
+
+<<<
+
+== Software Architecture
+
+include::anchors/adr-according-to-nygard.adoc[leveloffset=+2]
+
+include::anchors/arc42.adoc[leveloffset=+2]
+
+include::anchors/c4-diagrams.adoc[leveloffset=+2]
+
+include::anchors/clean-architecture.adoc[leveloffset=+2]
+
+include::anchors/domain-driven-design.adoc[leveloffset=+2]
+
+include::anchors/hexagonal-architecture.adoc[leveloffset=+2]
+
+include::anchors/madr.adoc[leveloffset=+2]
+
+<<<
+
+== Statistical Methods & Process Monitoring
+
+include::anchors/control-chart-shewhart.adoc[leveloffset=+2]
+
+include::anchors/nelson-rules.adoc[leveloffset=+2]
+
+include::anchors/spc.adoc[leveloffset=+2]
+
+<<<
+
+== Strategic Planning
+
+include::anchors/cynefin-framework.adoc[leveloffset=+2]
+
+include::anchors/impact-mapping.adoc[leveloffset=+2]
+
+include::anchors/jobs-to-be-done.adoc[leveloffset=+2]
+
+include::anchors/pugh-matrix.adoc[leveloffset=+2]
+
+include::anchors/wardley-mapping.adoc[leveloffset=+2]
+
+<<<
+
+== Testing & Quality Practices
+
+include::anchors/iec-61508-sil-levels.adoc[leveloffset=+2]
+
+include::anchors/mutation-testing.adoc[leveloffset=+2]
+
+include::anchors/property-based-testing.adoc[leveloffset=+2]
+
+include::anchors/tdd-chicago-school.adoc[leveloffset=+2]
+
+include::anchors/tdd-london-school.adoc[leveloffset=+2]
+
+include::anchors/testing-pyramid.adoc[leveloffset=+2]
+
+<<<
diff --git a/scripts/extract-metadata.js b/scripts/extract-metadata.js
index e5e4e4d..02549f3 100755
--- a/scripts/extract-metadata.js
+++ b/scripts/extract-metadata.js
@@ -21,6 +21,18 @@ if (!fs.existsSync(OUTPUT_DIR)) {
   fs.mkdirSync(OUTPUT_DIR, { recursive: true });
 }
 
+/**
+ * Decode HTML entities to plain Unicode characters
+ */
+function decodeHtmlEntities(str) {
+  if (!str) return str;
+  const named = { amp: '&', lt: '<', gt: '>', quot: '"', apos: "'" };
+  return str.replace(/&#(\d+);|&([a-z]+);/gi, (match, num, name) => {
+    if (num) return String.fromCharCode(parseInt(num, 10));
+    return named[name] || match;
+  });
+}
+
 /**
  * Parse a single anchor file
  */
@@ -31,7 +43,7 @@ function parseAnchorFile(filePath) {
   // Extract attributes
   const attributes = doc.getAttributes();
   const id = path.basename(filePath, '.adoc');
-  const title = doc.getDocumentTitle();
+  const title = decodeHtmlEntities(doc.getDocumentTitle());
 
   // Parse comma-separated attributes
   const parseList = (attr) => {
diff --git a/scripts/generate-llms-txt.js b/scripts/generate-llms-txt.js
new file mode 100644
index 0000000..2b5fee7
--- /dev/null
+++ b/scripts/generate-llms-txt.js
@@ -0,0 +1,175 @@
+#!/usr/bin/env node
+/**
+ * Generate docs/all-anchors.adoc and website/public/llms.txt
+ *
+ * all-anchors.adoc: AsciiDoc include-based full reference document
+ * llms.txt:         Clean Markdown for LLM consumption
+ *
+ * Usage: node scripts/generate-llms-txt.js
+ */
+
+const fs = require('fs')
+const path = require('path')
+
+const ROOT = path.join(__dirname, '..')
+
+const categories = JSON.parse(
+  fs.readFileSync(path.join(ROOT, 'website/public/data/categories.json'), 'utf-8')
+)
+
+// ─── AsciiDoc → Markdown converter ──────────────────────────────────────────
+
+function adocToMarkdown(adoc) {
+  let md = adoc
+
+  // Remove document attributes (:key: value)
+  md = md.replace(/^:[a-z][a-z0-9-]*:.*$/gm, '')
+
+  // Headings: = → #, == → ##, etc.
+  md = md.replace(/^(=+) (.+)$/gm, (_, eq, title) => '#'.repeat(eq.length) + ' ' + title)
+
+  // [source,lang] + ---- → ```lang / ```
+  md = md.replace(/\[source(?:,([^\]]*))?\]\s*\n----/g, (_, lang) => '```' + (lang ? lang.trim() : ''))
+  md = md.replace(/^----\s*$/gm, '```')
+
+  // [quote] block: [quote]\n____\ntext\n____ → > text
+  md = md.replace(/\[quote[^\]]*\]\s*\n_{4}\s*\n([\s\S]*?)\n_{4}/g, (_, body) =>
+    body.trim().split('\n').map((l) => '> ' + l).join('\n')
+  )
+
+  // Sidebar blocks **** → remove delimiters
+  md = md.replace(/^\*{4}\s*$/gm, '')
+
+  // Collapsible: [%collapsible] + ==== delimiters → remove markers, keep content
+  md = md.replace(/^\[%collapsible\]\s*$/gm, '')
+  md = md.replace(/^====\s*$/gm, '')
+
+  // Tables |=== → remove delimiters
+  md = md.replace(/^\|===\s*$/gm, '')
+
+  // Table rows: |cell content → keep, clean up leading pipe
+  md = md.replace(/^\|(.+)$/gm, (_, row) => {
+    const cells = row.split('|').map((c) => c.trim()).filter(Boolean)
+    return '| ' + cells.join(' | ') + ' |'
+  })
+
+  // Remove block attribute lines
+  md = md.replace(/^\[(?:horizontal|sidebar|cols[^\]]*|options[^\]]*|%\w+[^\]]*)\]\s*$/gm, '')
+
+  // Definition lists: term:: description → **term**: description
+  md = md.replace(/^([^:\n|#`>]+)::\s*(.*)$/gm, (_, term, desc) =>
+    desc.trim() ? `**${term.trim()}**: ${desc.trim()}` : `**${term.trim()}**`
+  )
+
+  // Links: link:url[text] → [text](url)
+  md = md.replace(/link:([^\[]+)\[([^\]]*)\]/g, '[$2]($1)')
+
+  // Cross-references: <<id,text>> → text, <<id>> → `id`
+  md = md.replace(/<<([^,>]+),([^>]+)>>/g, '$2')
+  md = md.replace(/<<([^>]+)>>/g, '`$1`')
+
+  // Bold: **text** stays, *text* → **text**
+  md = md.replace(/(?<![*\w])\*([^*\n]+)\*(?![*\w])/g, '**$1**')
+
+  // Ordered list items: ". item" → "1. item"
+  md = md.replace(/^\. /gm, '1. ')
+
+  // Trailing whitespace and normalize blank lines
+  md = md.replace(/[ \t]+$/gm, '')
+  md = md.replace(/\n{3,}/g, '\n\n')
+
+  return md.trim()
+}
+
+// ─── Generate docs/all-anchors.adoc ─────────────────────────────────────────
+
+function generateAllAnchorsAdoc() {
+  const lines = [
+    '= Semantic Anchors — Complete Reference',
+    ':toc:',
+    ':toc-placement: preamble',
+    ':toclevels: 2',
+    '',
+    'include::about.adoc[leveloffset=+1]',
+    '',
+    '<<<',
+    '',
+  ]
+
+  for (const category of categories) {
+    lines.push(`== ${category.name}`)
+    lines.push('')
+    for (const anchorId of category.anchors) {
+      const filepath = path.join(ROOT, 'docs/anchors', `${anchorId}.adoc`)
+      if (fs.existsSync(filepath)) {
+        lines.push(`include::anchors/${anchorId}.adoc[leveloffset=+2]`)
+        lines.push('')
+      }
+    }
+    lines.push('<<<')
+    lines.push('')
+  }
+
+  const output = lines.join('\n')
+  fs.writeFileSync(path.join(ROOT, 'docs/all-anchors.adoc'), output, 'utf-8')
+  console.warn(`Generated: docs/all-anchors.adoc (${categories.length} categories)`)
+}
+
+// ─── Generate website/public/llms.txt ───────────────────────────────────────
+
+function generateLlmsTxt() {
+  const totalAnchors = categories.reduce((n, c) => n + c.anchors.length, 0)
+  const lines = [
+    '# Semantic Anchors — Complete Reference',
+    '',
+    `> ${totalAnchors} well-defined terms, methodologies, and frameworks`,
+    '> that serve as precision reference points when communicating with LLMs.',
+    '> Source: https://github.com/LLM-Coding/Semantic-Anchors',
+    '> Website: https://llm-coding.github.io/Semantic-Anchors/',
+    '',
+    '---',
+    '',
+  ]
+
+  // Introductory content from about.adoc
+  const aboutAdoc = fs.readFileSync(path.join(ROOT, 'docs/about.adoc'), 'utf-8')
+  lines.push(adocToMarkdown(aboutAdoc))
+  lines.push('')
+  lines.push('---')
+  lines.push('')
+
+  // Anchors by category
+  for (const category of categories) {
+    lines.push(`## ${category.name}`)
+    lines.push('')
+
+    for (const anchorId of category.anchors) {
+      const filepath = path.join(ROOT, 'docs/anchors', `${anchorId}.adoc`)
+      if (!fs.existsSync(filepath)) continue
+
+      const raw = fs.readFileSync(filepath, 'utf-8')
+      const titleMatch = raw.match(/^= (.+)$/m)
+      const title = titleMatch ? titleMatch[1] : anchorId
+
+      lines.push(`### ${title}`)
+      lines.push('')
+
+      const body = raw.replace(/^= .+\n/, '')
+      lines.push(adocToMarkdown(body))
+      lines.push('')
+    }
+
+    lines.push('---')
+    lines.push('')
+  }
+
+  const output = lines.join('\n')
+  fs.writeFileSync(path.join(ROOT, 'website/public/llms.txt'), output, 'utf-8')
+  const kb = Math.round(Buffer.byteLength(output, 'utf-8') / 1024)
+  console.warn(`Generated: website/public/llms.txt (${totalAnchors} anchors, ~${kb} KB)`)
+}
+
+// ─── Main ────────────────────────────────────────────────────────────────────
+
+generateAllAnchorsAdoc()
+generateLlmsTxt()
diff --git a/scripts/package.json b/scripts/package.json
index b753eb0..eced2aa 100644
--- a/scripts/package.json
+++ b/scripts/package.json
@@ -4,7 +4,8 @@
   "description": "Build scripts for Semantic Anchors project",
   "scripts": {
     "extract-metadata": "node extract-metadata.js",
-    "split-readme": "node split-readme.js"
+    "split-readme": "node split-readme.js",
+    "generate-llms-txt": "node generate-llms-txt.js"
   },
   "dependencies": {
     "@asciidoctor/core": "^3.0.4",
diff --git a/website/public/data/anchors.json b/website/public/data/anchors.json
index 2ce4f80..c2a8559 100644
--- a/website/public/data/anchors.json
+++ b/website/public/data/anchors.json
@@ -202,7 +202,7 @@
   },
   {
     "id": "devils-advocate",
-    "title": "Devil&#8217;s Advocate",
+    "title": "Devil’s Advocate",
     "categories": [
       "problem-solving"
     ],
@@ -267,7 +267,7 @@
   },
   {
     "id": "dry-principle",
-    "title": "DRY (Don&#8217;t Repeat Yourself)",
+    "title": "DRY (Don’t Repeat Yourself)",
     "categories": [
       "design-principles"
     ],
@@ -360,7 +360,7 @@
   },
   {
     "id": "hexagonal-architecture",
-    "title": "Hexagonal Architecture (Ports &amp; Adapters)",
+    "title": "Hexagonal Architecture (Ports & Adapters)",
     "categories": [
       "software-architecture"
     ],
@@ -892,4 +892,4 @@
     "tags": [],
     "filePath": "docs/anchors/what-qualifies-as-a-semantic-anchor.adoc"
   }
-]
+]
\ No newline at end of file
diff --git a/website/public/data/categories.json b/website/public/data/categories.json
index c8f731b..72fac65 100644
--- a/website/public/data/categories.json
+++ b/website/public/data/categories.json
@@ -121,4 +121,4 @@
       "testing-pyramid"
     ]
   }
-]
+]
\ No newline at end of file
diff --git a/website/public/data/metadata.json b/website/public/data/metadata.json
index 203dc50..c29f0d1 100644
--- a/website/public/data/metadata.json
+++ b/website/public/data/metadata.json
@@ -1,5 +1,5 @@
 {
-  "generatedAt": "2026-02-17T02:06:50.606Z",
+  "generatedAt": "2026-02-20T19:58:22.989Z",
   "version": "1.0.0",
   "counts": {
     "anchors": 50,
@@ -12,4 +12,4 @@
     "anchorsWithTags": 4,
     "anchorsWithRelated": 3
   }
-}
+}
\ No newline at end of file
diff --git a/website/public/data/roles.json b/website/public/data/roles.json
index 89827eb..b1789eb 100644
--- a/website/public/data/roles.json
+++ b/website/public/data/roles.json
@@ -230,4 +230,4 @@
       "user-story-mapping"
     ]
   }
-]
+]
\ No newline at end of file
diff --git a/website/public/llms.txt b/website/public/llms.txt
new file mode 100644
index 0000000..05b339e
--- /dev/null
+++ b/website/public/llms.txt
@@ -0,0 +1,2415 @@
+# Semantic Anchors — Complete Reference
+
+> 50 well-defined terms, methodologies, and frameworks
+> that serve as precision reference points when communicating with LLMs.
+> Source: https://github.com/LLM-Coding/Semantic-Anchors
+> Website: https://llm-coding.github.io/Semantic-Anchors/
+
+---
+
+# About Semantic Anchors
+
+## What are Semantic Anchors?
+
+**Semantic anchors** are well-defined terms, methodologies, and frameworks that serve as reference points when communicating with Large Language Models (LLMs). They act as shared vocabulary that triggers specific, contextually rich knowledge domains within an LLM's training data.
+
+Think of them as **shortcuts to rich context** - instead of explaining a complex methodology from scratch, you can invoke a semantic anchor and the LLM will activate its entire knowledge base about that concept.
+
+### Example
+
+Instead of saying:
+> "Write tests before writing code, use mocks to isolate dependencies, and design from the outside in."
+
+You can say:
+> "Use **TDD, London School** approach."
+
+The LLM understands this activates:
+
+* Mock-heavy testing methodology
+* Outside-in development approach
+* Interaction-based verification
+* The teachings of Steve Freeman and Nat Pryce
+* Designing through collaboration tests first
+
+## Why Use Semantic Anchors?
+
+### 🎯 Precision
+Semantic anchors provide **unambiguous communication**. When you reference "SOLID Principles," both you and the LLM understand exactly which five principles you mean.
+
+### 🧠 Depth
+A single semantic anchor can activate **dozens of related concepts**. "Domain-Driven Design" brings in bounded contexts, ubiquitous language, aggregates, value objects, and much more.
+
+### ⚡ Efficiency
+Instead of writing lengthy explanations, you can **reference established methodologies** that the LLM already knows deeply.
+
+### 🔄 Consistency
+Different people using the same semantic anchor will get **similar, predictable results** from the LLM, because the anchor refers to well-documented concepts.
+
+## Quality Criteria
+
+Not every term makes a good semantic anchor. We maintain high quality standards:
+
+### Precise
+References a **specific, established body of knowledge** with clear boundaries.
+
+✅ "Hexagonal Architecture" (specific architectural pattern)
+
+❌ "Good architecture" (vague, subjective)
+
+### Rich
+Activates **multiple interconnected concepts**, not just a single instruction.
+
+✅ "Behavior-Driven Development" (scenarios, Gherkin, living documentation, outside-in)
+
+❌ "Write tests" (single instruction, no depth)
+
+### Consistent
+Different users invoking it get **similar conceptual activation**.
+
+✅ "Test-Driven Development" (widely documented, consistent understanding)
+
+❌ "Modern testing" (different interpretations)
+
+### Attributable
+Can be **traced to key proponents, publications, or documented standards**.
+
+✅ "arc42" (Gernot Starke, Peter Hruschka)
+
+❌ "Best practices" (no specific source)
+
+## What is NOT a Semantic Anchor?
+
+Not every well-known term qualifies as a semantic anchor. Understanding what **doesn't** work helps clarify what does.
+
+### Common Counter-Examples
+
+These terms are frequently used but **lack the depth and definition** required for semantic anchors:
+
+| ❌ Not a Semantic Anchor | Why Not? |
+
+| **"TLDR"** |
+| Underspecified instruction with no defined structure or methodology. Just means "be brief" without any framework for how. |
+
+| **"ELI5"** (Explain Like I'm 5) |
+| Vague target level with no pedagogical framework. What does "5-year-old level" mean technically? No consistent interpretation. |
+
+| **"Keep it short"** |
+| Pure directive with no conceptual depth. It's an instruction, not a methodology. |
+
+| **"Best practices"** |
+| Too vague and not attributable. Whose best practices? Based on what research or authority? |
+
+| **"Modern approach"** |
+| Ambiguous and inconsistent. "Modern" means different things to different people and changes over time. |
+
+| **"Make it simple"** |
+| No reference to specific simplification frameworks (unlike KISS principle or Occam's Razor which **are** semantic anchors). |
+
+### Comparison: Good vs. Bad
+
+**Example 1: Testing Instructions**
+
+❌ **Bad**: "Write good tests"
+
+**Problem**: Vague instruction, no methodology
+**Result**: Inconsistent interpretations
+
+✅ **Good**: "Test-Driven Development, London School"
+
+**Activates**: Mock-heavy testing, outside-in design, interaction-based verification
+**Proponents**: Steve Freeman, Nat Pryce
+**Result**: Consistent, rich implementation
+
+---
+
+**Example 2: Communication Style**
+
+❌ **Bad**: "Keep it short"
+
+**Problem**: No structure, just a preference
+**Result**: Arbitrary length decisions
+
+✅ **Good**: "Pyramid Principle"
+
+**Activates**: Start with conclusion, group ideas, logical ordering
+**Proponent**: Barbara Minto
+**Result**: Structured, repeatable communication pattern
+
+---
+
+**Example 3: Code Quality**
+
+❌ **Bad**: "Best practices"
+
+**Problem**: Not attributable, no specific practices
+**Result**: Everyone has different "best practices"
+
+✅ **Good**: "SOLID Principles"
+
+**Activates**: Five specific design principles (SRP, OCP, LSP, ISP, DIP)
+**Proponents**: Robert C. Martin
+**Result**: Concrete, testable guidelines
+
+### The Key Difference
+
+**Semantic Anchors** activate **rich, interconnected knowledge domains** from the LLM's training data.
+
+**Simple Instructions** just tell the LLM **what to do**, without providing conceptual framework or methodology.
+
+Think of semantic anchors as **nouns** (methodologies, frameworks, principles) rather than **verbs** (instructions, directives).
+
+### Testing a Potential Anchor
+
+Before proposing a new semantic anchor, ask an LLM:
+
+```
+What concepts do you associate with '<your term>'?
+```
+If the response includes:
+
+* ✅ Multiple interconnected concepts
+* ✅ Key proponents or publications
+* ✅ Specific techniques or practices
+* ✅ Clear scope and boundaries
+
+→ It's likely a good semantic anchor!
+
+If the response is:
+
+* ❌ Just a simple definition
+* ❌ No attributed source
+* ❌ Vague or inconsistent interpretations
+* ❌ Just instructions without depth
+
+→ It's probably not a semantic anchor.
+
+## How to Use This Catalog
+
+### Browse by Category
+
+The catalog is organized into 12 categories:
+
+* Communication & Presentation
+* Design Principles & Patterns
+* Development Workflow
+* Dialogue & Interaction Patterns
+* Documentation Practices
+* Meta (about this catalog itself)
+* Problem-Solving Methodologies
+* Requirements Engineering
+* Software Architecture
+* Statistical Methods & Process Monitoring
+* Strategic Planning & Decision Making
+* Testing & Quality Practices
+
+### Filter by Role
+
+Select your professional role to see anchors most relevant to you:
+
+* Software Developer / Engineer
+* Software Architect
+* QA Engineer / Tester
+* DevOps Engineer
+* Product Owner / Product Manager
+* Business Analyst / Requirements Engineer
+* Technical Writer / Documentation Specialist
+* UX Designer / Researcher
+* Data Scientist / Statistician
+* Consultant / Coach
+* Team Lead / Engineering Manager
+* Educator / Trainer
+
+### Search
+
+Use the full-text search to find anchors by:
+
+* Title (highest priority)
+* Proponents and key people
+* Tags and keywords
+* Content and descriptions
+
+## Using Semantic Anchors with LLMs
+
+### In Prompts
+
+Reference semantic anchors directly in your prompts:
+
+```
+"Refactor this code following SOLID Principles."
+
+"Design this API using RESTful constraints as defined by Roy Fielding."
+
+"Write these scenarios in Gherkin format per Behavior-Driven Development."
+```
+### In Context Setup
+
+Set up your LLM conversation with semantic anchors:
+
+```
+I'm working on a project where we follow:
+- Test-Driven Development (TDD, Chicago School)
+- Hexagonal Architecture
+- Domain-Driven Design
+- SOLID Principles
+
+Please keep these in mind when suggesting code changes.
+```
+### In Code Reviews
+
+Ask the LLM to review code against specific methodologies:
+
+```
+Review this code for violations of:
+- Single Responsibility Principle
+- Dependency Inversion Principle
+- Law of Demeter
+```
+### Testing Recognition
+
+Before relying on a semantic anchor, test if the LLM recognizes it:
+
+```
+What concepts do you associate with 'MECE'?
+```
+If the LLM provides accurate, detailed information, it's safe to use that anchor.
+
+## Contributing
+
+We welcome proposals for new semantic anchors! See our [Contributing Guide](../CONTRIBUTING.adoc) for details on:
+
+* How to propose a new anchor
+* Quality criteria and testing methodology
+* Automated validation with GitHub Copilot
+* The review and publication process
+
+Click [Propose New Anchor](https://github.com/LLM-Coding/Semantic-Anchors/issues/new?template=propose-anchor.yml) to get started!
+
+## About This Project
+
+**Semantic Anchors** is an open-source catalog maintained by the LLM Coding community. The project aims to:
+
+* Document effective communication patterns with LLMs
+* Establish shared vocabulary for AI-assisted development
+* Provide a curated, quality-controlled reference
+* Enable more precise and efficient human-AI collaboration
+
+### Technology
+
+* **Website**: Vite + Vanilla JavaScript
+* **Styling**: Tailwind CSS
+* **Content**: AsciiDoc
+* **Visualization**: Card Grid with category organization
+* **Hosting**: GitHub Pages
+* **Automation**: GitHub Actions + Copilot
+
+### License
+
+This project is open source. See the [LICENSE](https://github.com/LLM-Coding/Semantic-Anchors/blob/main/LICENSE) file for details.
+
+### Source Code
+
+View the source, report issues, or contribute:
+
+https://github.com/LLM-Coding/Semantic-Anchors
+
+---
+
+Ready to explore? [Browse the catalog →](#/)
+
+---
+
+## Communication & Presentation
+
+### BLUF (Bottom Line Up Front)
+
+**Full Name**: BLUF (Bottom Line Up Front)
+
+**Also known as**: Direct Answer Format, Conclusion-First Communication
+
+**Core Concepts**:
+
+**Conclusion First**: State the main point, decision, or recommendation immediately
+
+**Inverted Pyramid**: Most important information first, supporting details follow
+
+**Action Orientation**: Lead with what needs to happen or what was decided
+
+**Busy Reader Optimization**: Enable time-pressed readers to get key information instantly
+
+**Supporting Evidence Follows**: Detailed rationale, data, and background come after the conclusion
+
+**Scannable Structure**: Clear hierarchy enables readers to stop at their needed depth
+
+**Clarity Over Suspense**: No narrative buildup or delayed conclusions
+
+**One Sentence First**: Ideally, the BLUF itself is a single, clear sentence
+
+**Key Proponents**: US Military (Army writing standards), adopted broadly in business and government
+
+**Historical Context**: Standardized in military communication where rapid decision-making is critical; now standard in business writing (McKinsey, consulting, executive communication)
+
+**When to Use**:
+
+* Executive summaries and briefings
+* Status reports to leadership
+* Email to busy stakeholders
+* Incident reports requiring immediate action
+* Any high-stakes communication where the reader needs the conclusion first
+* Technical documentation for time-constrained readers
+
+**Relationship to Other Anchors**:
+
+* Related to Pyramid Principle but more narrowly focused on conclusion-first structure
+* Complements MECE by providing the organizational principle for grouped information
+* Contrasts with narrative or exploratory writing styles
+
+**Counter-example**: Academic papers (which build to conclusions) or storytelling (which uses suspense)
+
+### Chatham House Rule
+
+**Full Name**: Chatham House Rule
+
+**Core Concepts**:
+
+**Information Sharing**: Participants are free to use information received, but neither the identity nor the affiliation of the speaker(s) may be revealed
+
+**Confidentiality of Source**: "When a meeting, or part thereof, is held under the Chatham House Rule, participants are free to use the information received, but neither the identity nor the affiliation of the speaker(s), nor that of any other participant, may be revealed"
+
+**Open Discussion**: Encourages frank and honest dialogue by removing attribution concerns
+
+**Trust Building**: Creates psychological safety for participants to express controversial or sensitive views
+
+**Knowledge Transfer**: Allows insights to be shared widely while protecting individual sources
+
+**Single Rule Format**: Unlike other frameworks, it's a single, clearly defined rule
+
+**Attribution Separation**: Distinguishes between "what was said" (shareable) and "who said it" (protected)
+
+**Context Independence**: Applies equally to small meetings, large conferences, or online discussions
+
+**Key Origin**: Established by Chatham House (Royal Institute of International Affairs) in London, 1927
+
+**Historical Context**: Originally created to enable diplomats and government officials to discuss international affairs candidly; now widely adopted across business, academia, and technology sectors
+
+**When to Use**:
+
+* Strategic planning sessions where sensitive business information is discussed
+* Retrospectives where team members need to speak candidly about problems
+* Cross-organizational meetings where participants represent competing interests
+* Executive briefings on sensitive topics
+* Security discussions involving vulnerabilities or incidents
+* Research interviews where anonymity encourages honesty
+* Board meetings discussing confidential matters
+* Community forums where psychological safety is needed
+
+**Common Misunderstandings**:
+
+* ❌ "Everything is off the record" - Information CAN be shared, just not attributed
+* ❌ "Nothing can be quoted" - The content is shareable, but without attribution
+* ❌ "Conversations are confidential" - The rule protects identity, not information
+* ✓ "You can use the insights, just don't say who said them" - Correct understanding
+
+**Related Concepts**:
+
+* Psychological safety in teams
+* Non-disclosure agreements (NDAs) - more restrictive than Chatham House Rule
+* Off-the-record conversations
+* Anonymous feedback systems
+
+**Example Invocation**:
+
+```
+This retrospective will be conducted under the Chatham House Rule.
+You may share the insights we generate, but don't attribute comments
+to specific team members.
+```
+
+### MECE Principle
+
+**Full Name**: MECE (Mutually Exclusive, Collectively Exhaustive)
+
+**Core Concepts**:
+
+**Mutually Exclusive**: Categories have no overlap - each item belongs to exactly one category
+
+**Collectively Exhaustive**: Categories cover all possibilities - nothing is left out
+
+**Framework for organization**: Systematic approach to structuring information and problems
+
+**Prevents duplication**: Mutual exclusivity ensures no redundant coverage
+
+**Prevents gaps**: Collective exhaustiveness ensures complete coverage
+
+**Clear boundaries**: Unambiguous categorization with well-defined criteria
+
+**Hierarchical application**: Can be applied recursively at multiple levels
+
+**Validation approach**: Check both dimensions independently (exclusivity and exhaustiveness)
+
+**Key Proponent**: Barbara Minto (McKinsey & Company, late 1960s)
+
+**When to Use**:
+
+* Problem decomposition and analysis
+* Software architecture and component design
+* Module boundary definition to avoid overlapping responsibilities
+* Requirements organization and breakdown
+* API endpoint structure and design
+* Decision tree construction
+* Issue tree development
+* Organizing complex information
+* System design and modular architecture
+
+**Related Concepts**:
+
+* Foundational to the Pyramid Principle
+* Supports Single Responsibility Principle
+* Enables Separation of Concerns
+* Used in logic trees and issue trees
+
+### Pyramid Principle according to Barbara Minto
+
+**Full Name**: The Minto Pyramid Principle according to Barbara Minto
+
+**Core Concepts**:
+
+**Governing Thought**: Single key message at the top of the pyramid
+
+**SCQ Framework**: Situation → Complication → Question → Answer structure for setting context
+
+**MECE Principle**: Mutually Exclusive, Collectively Exhaustive grouping of ideas
+
+**Vertical Logic**: Each level answers "Why?" of the level above it
+
+**Horizontal Logic**: Arguments at the same level grouped deductively or inductively
+
+**Top-Down Delivery**: Present conclusion first, then supporting arguments
+
+**Pyramid Structure**: One central idea supported by groups of three supporting ideas
+
+**BLUF**: Bottom Line Up Front - lead with the conclusion
+
+**Deductive vs. Inductive Reasoning**: Choose appropriate logic for horizontal grouping
+
+**Key Proponent**: Barbara Minto (McKinsey, "The Minto Pyramid Principle", 1987)
+
+**When to Use**:
+
+* Executive presentations and briefings
+* Written reports and proposals
+* Complex arguments requiring clear structure
+* Stakeholder communication where time is limited
+* Business cases and recommendations
+* Consulting deliverables
+* Any situation requiring persuasive, structured communication
+
+---
+
+## Design Principles & Patterns
+
+### DRY (Don't Repeat Yourself)
+
+**Full Name**: Don't Repeat Yourself Principle
+
+**Core Concepts**:
+
+**Single representation**: Every piece of knowledge should have a single, unambiguous representation
+
+**Avoid duplication**: Eliminate duplicate code, logic, and knowledge across the system
+
+**Abstraction**: Extract common patterns into reusable components
+
+**Maintenance efficiency**: Changes require modification in only one place
+
+**Knowledge duplication vs. code duplication**: Focus on avoiding duplicate knowledge, not just duplicate code
+
+**Normalized data**: Apply DRY to data structures and schemas
+
+**Configuration management**: Centralize configuration and avoid scattered settings
+
+**Key Proponent**: Andy Hunt and Dave Thomas ("The Pragmatic Programmer", 1999)
+
+**When to Use**:
+
+* Refactoring codebases with repeated logic or patterns
+* Designing APIs and libraries to minimize client code duplication
+* Creating maintainable systems where changes are frequent
+* Establishing coding standards and best practices
+
+**Related Concepts**: SPOT, SSOT, WET (Write Everything Twice - deliberate exception to DRY)
+
+### Patterns of Enterprise Application Architecture (PEAA)
+
+**Full Name**: Patterns of Enterprise Application Architecture according to Martin Fowler
+
+**Also known as**: Fowler patterns, PEAA patterns, Enterprise patterns
+
+**Core Concepts**:
+
+**Domain Logic Patterns**: Transaction Script, Domain Model, Table Module, Service Layer
+
+**Data Source Architectural Patterns**: Table Data Gateway, Row Data Gateway, Active Record, Data Mapper
+
+**Object-Relational Behavioral Patterns**: Unit of Work, Identity Map, Lazy Load
+
+**Object-Relational Structural Patterns**: Identity Field, Foreign Key Mapping, Association Table Mapping, Dependent Mapping, Embedded Value, Serialized LOB, Single Table Inheritance, Class Table Inheritance, Concrete Table Inheritance
+
+**Object-Relational Metadata Mapping Patterns**: Metadata Mapping, Query Object, Repository
+
+**Web Presentation Patterns**: Model View Controller, Page Controller, Front Controller, Template View, Transform View, Two Step View, Application Controller
+
+**Distribution Patterns**: Remote Facade, Data Transfer Object
+
+**Offline Concurrency Patterns**: Optimistic Offline Lock, Pessimistic Offline Lock, Coarse-Grained Lock, Implicit Lock
+
+**Session State Patterns**: Client Session State, Server Session State, Database Session State
+
+**Base Patterns**: Gateway, Mapper, Layer Supertype, Separated Interface, Registry, Value Object, Money, Special Case, Plugin, Service Stub, Record Set
+
+**Key Proponent**: Martin Fowler ("Patterns of Enterprise Application Architecture", 2002)
+
+**When to Use**:
+
+* Designing complex enterprise applications with data persistence
+* Building layered architectures with clear separation of concerns
+* Working with object-relational mapping and database interactions
+* Designing web applications with proper presentation layer patterns
+* Managing distributed system communication
+* Handling concurrency in multi-user enterprise systems
+* Creating maintainable and testable enterprise code
+
+**Related Anchors**:
+
+* Domain-Driven Design - Complements PEAA with domain modeling approach
+* Hexagonal Architecture - Architectural style emphasizing ports and adapters
+* Clean Architecture - Layered architecture pattern with dependency rules
+
+### SOLID Principles
+
+**Full Name**: SOLID Object-Oriented Design Principles
+
+**Core Concepts**:
+
+**Single Responsibility Principle (SRP)**: Each class should have one responsibility
+
+**Open/Closed Principle (OCP)**: Entities should be open for extension, closed for modification
+
+**Liskov Substitution Principle (LSP)**: Subtypes must be substitutable for their base types
+
+**Interface Segregation Principle (ISP)**: Clients should not be forced to depend on interfaces they do not use
+
+**Dependency Inversion Principle (DIP)**: Depend on abstractions, not concrete implementations
+
+**Key Proponent**: Robert C. Martin ("Uncle Bob")
+
+**When to Use**:
+
+* Designing maintainable and scalable object-oriented systems
+* Refactoring legacy code to improve structure
+* Building systems where flexibility and testability are important
+* Teaching or enforcing good software design practices
+
+### SPOT (Single Point of Truth)
+
+**Full Name**: Single Point of Truth
+
+**Core Concepts**:
+
+**Implementation pattern**: Focuses on where and how data/logic is stored and accessed
+
+**Centralized location**: Each piece of information resides in exactly one place
+
+**Reference relationships**: Other locations reference the single point rather than duplicate it
+
+**Data consistency**: Eliminates synchronization issues and conflicting data
+
+**Update propagation**: Changes at the single point automatically affect all references
+
+**Clear ownership**: Explicit responsibility for maintaining each piece of truth
+
+**Code-level practice**: Applied at the code and system design level
+
+**When to Use**:
+
+* Implementing functions and utilities to avoid code duplication
+* Database schema design to eliminate redundant data
+* Configuration management across distributed systems
+* State management in applications
+* API design where data flows from a single endpoint
+
+**Difference from SSOT**: SPOT emphasizes the implementation detail of where data lives, while SSOT emphasizes the authoritative, trusted nature of that data source
+
+**Related Concepts**: DRY, SSOT, Normalized databases, Master data management
+
+### SSOT (Single Source of Truth)
+
+**Full Name**: Single Source of Truth
+
+**Core Concepts**:
+
+**Conceptual principle**: Focuses on establishing trust and authority for data
+
+**Authoritative source**: One canonical, trusted location for each piece of data
+
+**Data integrity**: All consumers reference the same trusted source
+
+**Version control**: Single source ensures consistent versioning
+
+**Derived data**: Other representations are derived from the single source
+
+**Trust and reliability**: The source is the definitive version when conflicts arise
+
+**System of record**: The primary data store for critical business information
+
+**Organizational practice**: Applied at the architecture and business process level
+
+**Key Application Areas**:
+
+* Version control systems (Git as SSOT for code)
+* Database design and data warehousing
+* Documentation and knowledge management
+* Configuration management
+* Master data management (MDM)
+
+**When to Use**:
+
+* Designing data architecture for enterprise systems
+* Establishing documentation standards and knowledge bases
+* Building data pipelines and ETL processes
+* Implementing microservices with clear data ownership
+* Creating audit trails and ensuring compliance
+* Resolving conflicts between multiple data sources
+
+**Difference from SPOT**: SSOT emphasizes the authoritative, trusted nature of a data source and is used at the architecture/organizational level, while SPOT focuses on the implementation pattern
+
+**Related Concepts**: DRY, SPOT, Event sourcing, Data lakes, Master data management
+
+---
+
+## Development Workflow
+
+### BEM Methodology
+
+**Full Name**: Block Element Modifier (BEM) (S)CSS Methodology
+
+**Core Concepts**:
+
+**Motivation**: Solve CSS specificity wars, naming conflicts, and stylesheet maintainability issues in large codebases
+
+**Block**: Standalone component that is meaningful on its own (e.g., `menu`, `button`, `header`)
+
+**Element**: Part of a block with no standalone meaning (e.g., `menu__item`, `button__icon`)
+
+**Modifier**: Flag on blocks or elements that changes appearance or behavior (e.g., `button--disabled`, `menu__item--active`)
+
+**Naming convention**: `block__element--modifier` structure
+
+**Independence**: Blocks are self-contained and reusable
+
+**No cascading**: Avoid deep CSS selectors, use flat structure
+
+**Explicit relationships**: Clear parent-child relationships through naming
+
+**Reusability**: Components can be moved anywhere in the project
+
+**Mix**: Combining multiple BEM entities on a single DOM node
+
+**File structure**: Often paired with component-based file organization
+
+**Naming Examples**:
+
+* Block: `.search-form`
+* Element: `.search-form__input`, `.search-form__button`
+* Modifier: `.search-form--compact`, `.search-form__button--disabled`
+
+**Key Proponents**: Yandex development team
+
+**When to Use**:
+
+* Large-scale web applications with many components
+* Team projects requiring consistent (S)CSS naming conventions
+* When (S)CSS maintainability and scalability are priorities
+* Projects where developers need to quickly understand (S)CSS structure
+* Component-based architectures (React, Vue, Angular)
+
+### Conventional Commits
+
+**Core Concepts**:
+* A specification for adding human and machine readable meaning to commit messages
+* Determining a semantic version bump (based on the types of commits landed)
+* Communicating the nature of changes to teammates, the public, and other stakeholders
+**Schema**: <type>[!][(optional scope)]: <description> + optional body/footer
+
+**Common Types**: * **feat:** - introduce new feature to the codebase (-> Semver Minor)
+* **fix:** - patches a bug in your codebase (-> SemVer Patch)
+* **docs:** - documentation improvements to the codebase
+* **chore:** - codebase/repository housekeeping changes
+* **style:** - formatting changes that do not affect the meaning of the code
+* **refactor:** - implementation changes that do not affect the meaning of the code
+** **!* - BREAKING CHANGE (-> SemVer Major)
+
+* **BREAKING CHANGE:** introduces a breaking API change
+
+**Key Proponents**: Benjamin E. Coe, James J. Womack, Steve Mao
+
+**When to Use**:
+
+* everything-as-code paradigm targeted
+* team-/community-communication
+* repository quality improvements
+
+### Mental Model according to Naur
+
+**Full Name**: Programming as Theory Building (Mental Model) according to Peter Naur
+
+**Core Concepts**:
+
+**Theory building**: Programming is creating a mental model, not just writing code
+
+**Theory of the program**: Deep understanding of why the program works and how it relates to the problem domain
+
+**Knowledge in people**: The real program exists in developers' minds, not in the code
+
+**Theory decay**: When original developers leave, the theory is lost
+
+**Documentation limitations**: Written documentation cannot fully capture the theory
+
+**Maintenance as theory**: Effective maintenance requires possessing the theory
+
+**Communication is key**: Theory must be shared through collaboration and conversation
+
+**Ramp-up time**: New team members need time to build the theory
+
+**Code as artifact**: Code is merely a representation of the underlying theory
+
+**Key Proponent**: Peter Naur (Turing Award winner, 1978)
+
+**Original Work**: "Programming as Theory Building" (1985)
+
+**Application in Software Development**:
+
+* Understanding why knowledge transfer is challenging
+* Emphasizing pair programming and mob programming
+* Justifying time for onboarding and code walkthroughs
+* Explaining technical debt accumulation when teams change
+* Supporting documentation practices that capture "why" not just "what"
+* Advocating for team stability and continuity
+
+**Contrast with Other Views**:
+
+* Programming as text production → Focus on code output
+* Programming as problem solving → Focus on algorithms
+* Programming as theory building → Focus on understanding
+
+### Semantic Versioning (SemVer)
+
+**Full Name**: Semantic Versioning Specification
+
+**Core Concepts**:
+
+**Version format**: +
+**MAJOR**: : Incompatible API changes (breaking changes)
+**MINOR**: : Backward-compatible functionality additions
+**PATCH**: : Backward-compatible bug fixes
+**Pre-release versions**: : Append hyphen and identifiers (e.g., 1.0.0-alpha.1)
+
+**Build metadata**: Append plus sign and identifiers (e.g., 1.0.0+20241111)
+
+**Version precedence**: Clear rules for version comparison
+
+**Initial development**: 0.y.z for initial development (API unstable)
+
+**Public API declaration**: Once public API declared, version dependencies matter
+
+**Key Proponent**: Tom Preston-Werner
+
+**When to Use**:
+
+* Libraries and APIs consumed by other software
+* Software with defined public interfaces
+* Projects requiring dependency management
+* Communication of change impact to users/consumers
+
+### SOTA (State-of-the-Art)
+
+**Full Name**: State-of-the-Art
+
+**Core Concepts**:
+
+**Latest approaches**: Focus on the most current, cutting-edge methods and techniques
+
+**Research-grounded**: Reference current research papers, benchmarks, and empirical results
+
+**Comparative analysis**: Compare new approaches with existing or previous methods
+
+**Performance-focused**: Emphasize benchmark-leading and best-performing solutions
+
+**Up-to-date information**: Provide current, grounded information rather than outdated practices
+
+**Evidence-based**: Support claims with recent studies, benchmarks, and real-world implementations
+
+**Contextual awareness**: Consider the specific domain and timeframe for "state-of-the-art"
+
+**Usage Patterns**:
+
+* "Learn SOTA for [topic]" - triggers research and comprehensive information gathering
+* "What's SOTA for [topic]?" - requests current best practices and approaches
+* "Give me the SOTA approach for [problem]" - asks for cutting-edge solutions
+
+**Example Usage**:
+
+* "Learn SOTA for RAG implementations"
+* "What's SOTA for code generation in 2024?"
+* "Give me the SOTA approach for semantic search"
+* "What's the SOTA in transformer architectures?"
+
+**Key Proponent**: Widely used in ML/AI research community
+
+**When to Use**:
+
+* Researching current best practices in a technical domain
+* Comparing different approaches to solve a problem
+* Staying updated with rapidly evolving fields (AI/ML, web technologies)
+* Making technology decisions based on current benchmarks
+* Learning about cutting-edge implementations
+* Avoiding outdated or deprecated approaches
+
+**Why It Works**:
+
+* Heavily represented in ML/AI papers, benchmarks, and technical discussions
+* Consistent meaning across contexts: "best performing" and "most current"
+* Concise trigger for comprehensive research behavior
+* Activates research-oriented response patterns in LLMs
+
+### TIMTOWTDI
+
+**Full Name**: There Is More Than One Way To Do It
+
+**Also known as**: Tim Toady
+
+**Core Concepts**:
+
+**Multiple valid approaches**: Acknowledges that problems can be solved in different, equally valid ways
+
+**Developer freedom**: Trust developers to choose the right approach for their context
+
+**Expressiveness**: Languages and tools should support diverse problem-solving styles
+
+**Context-dependent decisions**: The "best" solution depends on constraints, team, and situation
+
+**No single canonical form**: Resist dogma — flexibility over prescription
+
+**Trade-off awareness**: Different approaches have different trade-offs; none is universally superior
+
+**Pragmatism over purity**: Practical results matter more than theoretical elegance
+
+**Collaborative decision-making**: When working with others, discuss approach rather than assume
+
+**Key Proponent**: Larry Wall (Perl programming language)
+
+**Contrast**:
+
+* Python's Zen: "There should be one-- and preferably only one --obvious way to do it" (opposite philosophy)
+* TIMTOWTDI favors flexibility and expressiveness over enforced uniformity
+
+**When to Use**:
+
+* Choosing between multiple valid architectural or design approaches
+* Code reviews where different styles achieve the same goal
+* Team discussions about tooling, frameworks, or methodologies
+* LLM-assisted development: ask for alternatives rather than accepting the first suggestion
+* Avoiding premature standardization before understanding trade-offs
+* Resisting "one true way" dogma in technology choices
+* Architecture Decision Records (ADRs): documenting why one approach was chosen over other valid alternatives
+* KonsenT-based decisions: finding solutions with no objections rather than forcing one "right" way
+
+### todo.txt-flavoured Markdown
+
+**Full Name**: todo.txt-flavoured Markdown Task Lists
+
+**Also known as**: Enhanced Markdown Tasks, Markdown with todo.txt conventions
+
+**Core Concepts**:
+
+**Markdown task lists**: Standard GitHub-flavoured markdown syntax (`- [ ]` uncompleted, `- [x]` completed)
+
+**Priority markers**: Uses todo.txt priority notation `(A)`, `(B)`, `(C)` where `(A)` is highest priority
+
+**Project tags**: Prefixed with `+` to group related tasks (e.g., `+website`, `+semantic-anchors`)
+
+**Context tags**: Prefixed with `@` to indicate location/tool/context (e.g., `@computer`, `@home`, `@research`)
+
+**Key-value metadata**: Structured data pairs like `due:YYYY-MM-DD`, `priority:high`, or custom fields
+
+**Date tracking**: Creation dates and completion dates in ISO format (YYYY-MM-DD)
+
+**Human readability**: Plain text format that remains readable without special tools
+
+**Tool-agnostic**: Can be processed by both markdown renderers and todo.txt tools
+
+**Searchable and filterable**: Easy to grep/search by tags, priorities, or metadata
+
+**Pattern Structure**:
+
+```markdown
+- [ ] (Priority) Task description +project @context key:value
+- [x] YYYY-MM-DD (Priority) Completed task +project
+```
+**Example Usage**:
+
+```markdown
+- [ ] (A) Review PR for +website @computer due:2024-02-03
+- [x] 2024-02-01 (B) Update documentation +docToolchain
+- [ ] (C) Research new feature +semantic-anchors @research
+- [ ] Call team meeting @phone +project-planning due:2024-02-05
+- [x] 2024-01-30 Fix bug in authentication +backend @computer
+```
+**Key Proponents**: Combines GitHub-flavoured Markdown task lists with Gina Trapani's todo.txt format
+
+**Original References**:
+
+* GitHub-flavoured Markdown task lists
+* todo.txt format specification by Gina Trapani
+
+**When to Use**:
+
+* Task management in markdown documentation
+* Project planning and tracking in README files
+* GitHub issues and pull request descriptions requiring structured task lists
+* Personal productivity systems using plain text
+* Documentation that combines narrative with actionable tasks
+* When you need both human readability and programmatic parsing
+* Team collaboration where tasks need clear priorities and contexts
+* Generating consistent task list formats with LLMs
+
+**Benefits**:
+
+* Leverages two well-established, widely recognized standards
+* Renders nicely in GitHub, GitLab, and other markdown viewers
+* Remains fully functional in plain text editors
+* Enables rich metadata without sacrificing readability
+* Facilitates both manual and automated task tracking
+
+---
+
+## Dialogue Interaction
+
+### Socratic Method
+
+**Full Name**: Socratic Method (also Socratic Dialogue, Elenchus)
+
+**Core Concepts**:
+
+**Guided Discovery**: Lead learners to insights through questions rather than direct instruction
+
+**Elenchus**: Cross-examination technique to expose contradictions in beliefs
+
+**Maieutics**: "Midwifery of ideas" – helping others give birth to knowledge they already possess
+
+**Aporia**: State of productive confusion that motivates deeper inquiry
+
+**Question Hierarchy**: Progress from clarifying questions to probing assumptions to exploring implications
+
+**Dialectic Method**: Structured dialogue to arrive at truth through reasoned argument
+
+**Non-assertive Teaching**: Teacher claims ignorance, guides through questions
+
+**Assumption Surfacing**: Make implicit beliefs explicit through systematic questioning
+
+**Logical Consistency**: Test ideas for internal coherence and contradictions
+
+**Key Proponent**: Socrates (via Plato's dialogues, ~400 BCE)
+
+**Historical Context**: 2400+ years of philosophical tradition, foundational to Western philosophy and critical thinking education
+
+**When to Use**:
+
+* Teaching complex concepts where understanding must be constructed, not transmitted
+* Helping someone work through a problem without giving direct answers
+* Uncovering hidden assumptions in arguments or designs
+* Exploring the implications of a decision or belief
+* Encouraging deeper thinking about a topic
+* Code review or design review where understanding, not compliance, is the goal
+
+**Related Concepts**:
+
+* Cognitive apprenticeship
+* Constructivist learning theory
+* Critical thinking pedagogy
+
+---
+
+## Documentation
+
+### Diátaxis Framework
+
+**Full Name**: Diátaxis Documentation Framework according to Daniele Procida
+
+**Core Concepts**:
+
+**Four documentation types**: +
+**Tutorials**: : Learning-oriented, lessons for beginners
+**How-to guides**: : Task-oriented, directions for specific goals
+**Reference**: : Information-oriented, technical descriptions
+**Explanation**: : Understanding-oriented, conceptual discussions
+
+**Two dimensions**: * Practical vs. Theoretical
+* Acquisition (learning) vs. Application (working)
+
+**Separation of concerns**: Each type serves a distinct purpose
+
+**User needs**: Different users need different documentation at different times
+
+**Quality criteria**: Each type has specific quality indicators
+
+**Systematic approach**: Framework for organizing any documentation
+
+**Key Proponent**: Daniele Procida
+
+**When to Use**:
+
+* Organizing technical documentation
+* Improving existing documentation
+* Planning documentation structure
+* Evaluating documentation quality
+* Complementing Docs-as-Code approaches
+
+### Docs-as-Code according to Ralf D. Müller
+
+**Full Name**: Docs-as-Code Approach according to Ralf D. Müller
+
+**Core Concepts**:
+
+**Plain text formats**: AsciiDoc, Markdown
+
+**Version control**: Documentation in Git alongside code
+
+**Automated toolchains**: Build pipelines for documentation
+
+**Single source of truth**: Generate multiple output formats from one source
+
+**Diagrams as code**: PlantUML, Mermaid, Graphviz, Kroki
+
+**Continuous documentation**: Updated with every commit
+
+**Developer-friendly**: Use same tools and workflows as for code
+
+**Review process**: Pull requests for documentation changes
+
+**Modular documentation**: Includes and composition
+
+**Key Proponent**: Ralf D. Müller (docToolchain creator)
+
+**Technical Stack**:
+
+* AsciiDoc/Asciidoctor
+* docToolchain
+* Gradle-based automation
+* Kroki for diagram rendering
+* Arc42 template integration
+
+**When to Use**:
+
+* Technical documentation for software projects
+* When documentation needs to stay synchronized with code
+* Distributed teams collaborating on documentation
+* Projects requiring multiple output formats (HTML, PDF, etc.)
+
+---
+
+## Meta
+
+### The Spectrum of Semantic Anchors
+
+### What Qualifies as a Semantic Anchor
+
+A term qualifies as a semantic anchor when it activates a rich, well-defined conceptual framework in the LLM's training data. The key differentiator is **definition depth** – not whether the anchor is about domain knowledge or interaction patterns.
+
+A good semantic anchor is:
+
+**Precise**: It references a specific, established body of knowledge or methodology with clear boundaries
+
+**Rich**: It activates multiple interconnected concepts, not just a single instruction or directive
+
+**Consistent**: Different users invoking it will get similar conceptual activation across contexts
+
+**Attributable**: It can be traced to key proponents, publications, established practices, or documented standards
+
+Semantic anchors exist on a spectrum from domain-heavy to interaction-heavy:
+
+```
+Domain-heavy ◄──────────────────────► Interaction-heavy
+   arc42          Pyramid Principle        Socratic Method
+   SOLID          Rubber Duck Debugging    BLUF
+   DDD            Five Whys                Chain of Thought
+```
+The distinction isn't a strict category but rather a matter of emphasis. Most anchors have **both** dimensions:
+
+**Pyramid Principle**: Domain knowledge about structured communication + behavior change in how output is structured
+
+**TDD, London School**: Domain knowledge about testing + behavior change in how code is written
+
+**Socratic Method**: Interaction pattern for dialogue + domain knowledge from philosophical tradition
+
+The quality bar is the same across this spectrum – all anchors must be well-defined, rich, and activatable.
+
+#### Counter-Examples
+
+Well-known terms that are **not** semantic anchors because they lack definition depth:
+
+**"TLDR"**: Underspecified, no defined structure or methodology, vague instruction to "be short"
+
+**"ELI5"**: Vague target level, no pedagogical framework, no consistent interpretation
+
+**"Keep it short"**: Pure instruction, no conceptual depth or established methodology
+
+**"Make it simple"**: Ambiguous directive without reference to specific simplification frameworks
+
+These terms may be useful in conversation, but they don't activate rich conceptual frameworks the way true semantic anchors do.
+
+Below is a curated list of semantic anchors useful for software development, architecture, and requirements engineering. Each anchor includes related concepts and practices.
+
+The catalog is organized into the following categories:
+
+* Testing & Quality Practices
+* Architecture & Design
+* Design Principles & Patterns
+* Requirements Engineering
+* Documentation
+* Communication & Presentation
+* Decision Making & Strategy
+* Development Practices
+* Statistical Methods & Process Monitoring
+* Interaction & Reasoning Patterns
+
+---
+
+## Problem Solving
+
+### Chain of Thought (CoT)
+
+**Full Name**: Chain of Thought Prompting
+
+**Core Concepts**:
+
+**Step-by-Step Reasoning**: Explicitly show intermediate reasoning steps before reaching a conclusion
+
+**Reasoning Transparency**: Make the thought process visible, not just the final answer
+
+**Intermediate Representations**: Break complex problems into smaller, manageable steps
+
+**Error Reduction**: Exposing reasoning allows detection of logical errors mid-process
+
+**Complex Task Decomposition**: Handle multi-step problems that cannot be solved in one jump
+
+**Zero-Shot CoT**: Simple prompt like "Let's think step by step" to trigger CoT behavior
+
+**Few-Shot CoT**: Provide examples with reasoning chains to guide the model
+
+**Self-Consistency**: Generate multiple reasoning paths and select most consistent answer
+
+**Key Proponents**: Wei et al. (Google Research, 2022), "Chain-of-Thought Prompting Elicits Reasoning in Large Language Models"
+
+**Historical Context**: Breakthrough in LLM prompting research, significantly improved performance on reasoning tasks (math, logic, common sense)
+
+**When to Use**:
+
+* Complex reasoning problems (multi-step math, logic puzzles)
+* When you need to verify the reasoning process, not just the answer
+* Debugging incorrect LLM outputs by seeing where reasoning went wrong
+* Teaching or explaining complex topics where steps matter
+* Problems requiring planning or strategy
+* Any task where intermediate steps provide value
+
+**Related Research**:
+
+* Tree of Thoughts (ToT): Extension allowing branching and backtracking
+* Self-Consistency: Sample multiple reasoning paths
+* Least-to-Most Prompting: Build up from simple to complex
+
+**Example Prompt Pattern**:
+
+```
+Problem: [Complex question]
+Let's solve this step by step:
+1. [First step]
+2. [Second step]
+...
+Therefore: [Conclusion]
+```
+
+### Devil's Advocate
+
+**Full Name**: Devil's Advocate (Latin: **Advocatus Diaboli**)
+
+**Core Concepts**:
+
+**Systematic Counter-Argumentation**: Present opposing viewpoints even if not personally held
+
+**Assumption Challenging**: Question premises and surface hidden assumptions
+
+**Stress-Testing Ideas**: Identify weaknesses before they become problems
+
+**Steelmanning**: Present the **strongest** version of the opposing argument, not a strawman
+
+**Intellectual Honesty**: Separate idea evaluation from ego or political concerns
+
+**Pre-Mortem Thinking**: Imagine failure scenarios to prevent them
+
+**Dialectical Reasoning**: Thesis + Antithesis → Synthesis
+
+**Risk Identification**: Surface potential problems proactively
+
+**Key Origin**: Catholic Church canonization process (Promotor Fidei role, formalized 1587), secularized in critical thinking and decision-making
+
+**Historical Context**: 400+ years as formalized practice in the Church, adopted widely in law, philosophy, business strategy, and red teaming
+
+**When to Use**:
+
+* Critical design or architecture decisions where failure is costly
+* Security threat modeling (red teaming)
+* Evaluating business strategies or proposals
+* Pre-mortems before launching significant initiatives
+* Code review where you want to challenge assumptions
+* Risk assessment and contingency planning
+* Any high-stakes decision where being wrong is expensive
+
+**Related Concepts**:
+
+* Red teaming (security context)
+* Pre-mortem analysis
+* Dialectical reasoning
+* Critical thinking frameworks
+* Steelmanning (vs. strawmanning)
+
+**Example Prompt Pattern**:
+
+```
+I propose [idea/design/decision].
+Play devil's advocate: What are the strongest arguments against this approach?
+```
+
+### Feynman Technique
+
+**Full Name**: Feynman Technique (also Feynman Learning Method)
+
+**Core Concepts**:
+
+**Explain Simply**: Teach the concept in simple language as if to a beginner (traditionally "explain to a 12-year-old")
+
+**Identify Gaps**: When you struggle to explain, you've found gaps in your understanding
+
+**Return to Source Material**: Go back and re-learn the parts you couldn't explain clearly
+
+**Simplify and Use Analogies**: Refine explanation using plain language and concrete examples
+
+**Iterative Refinement**: Repeat the cycle until you can explain clearly and simply
+
+**No Jargon Hiding**: Inability to avoid jargon signals lack of true understanding
+
+**Active Learning**: Transform passive reading into active teaching
+
+**Metacognition**: Become aware of what you don't know
+
+**Key Attribution**: Richard Feynman (Nobel Prize-winning physicist, 1965), famous for making complex physics accessible
+
+**Historical Context**: Feynman was renowned for his teaching ability and his belief that deep understanding meant being able to explain simply. The "technique" is a formalization of his learning approach.
+
+**When to Use**:
+
+* Learning new technical concepts or frameworks
+* Validating your understanding before using knowledge in practice
+* Preparing to teach or present a topic
+* Debugging conceptual confusion
+* Code review where you explain your design choices simply
+* Documentation writing (if you can't explain it simply, you don't understand it)
+
+**Four Steps (Canonical Form)**:
+
+1. **Choose a concept**: Pick the topic you want to understand
+1. **Teach it to a child**: Write an explanation in simple terms
+1. **Identify gaps and review**: Where you struggle, study more
+1. **Simplify and analogize**: Refine your explanation, use examples
+
+**Related Concepts**:
+
+* Rubber Duck Debugging (explaining to understand)
+* Learning by teaching
+* Active recall
+* Elaborative interrogation
+* Plain language movement
+
+**Quote**: "If you can't explain it simply, you don't understand it well enough." (Often attributed to Einstein, but embodies Feynman's philosophy)
+
+### Five Whys (Ohno)
+
+**Full Name**: Five Whys Root Cause Analysis
+
+**Core Concepts**:
+
+**Iterative Causal Analysis**: Ask "Why?" repeatedly (typically ~5 times) to drill down to root causes
+
+**Root Cause vs. Symptom**: Distinguish between surface symptoms and underlying causes
+
+**Causal Chain**: Each answer becomes the subject of the next "Why?" question
+
+**Actionable Root Cause**: Continue until you reach a cause that can be acted upon
+
+**Simplicity**: No complex tools or statistical analysis required
+
+**Team-Based Investigation**: Collaborative exploration of causal relationships
+
+**Avoiding Blame**: Focus on process failures, not individual fault
+
+**Countermeasure Identification**: Once root cause is found, design interventions
+
+**Key Proponent**: Taiichi Ohno (Toyota Production System, 1950s)
+
+**Historical Context**: Core tool in Lean Manufacturing and Toyota Production System (TPS), foundational to continuous improvement (Kaizen)
+
+**When to Use**:
+
+* Incident post-mortems in software/DevOps
+* Debugging when surface fixes don't resolve the issue
+* Process improvement initiatives
+* Understanding recurring problems
+* Quality defect analysis
+* Any situation where symptoms are clear but causes are not
+
+**Related Concepts**:
+
+* Kaizen (continuous improvement)
+* Root Cause Analysis (RCA)
+* Fishbone Diagram (Ishikawa) – complementary tool
+* A3 Problem Solving (Toyota)
+* DevOps post-mortem culture
+
+**Pitfall to Avoid**:
+
+* Stopping too early at a symptom rather than root cause
+* Pursuing a single causal chain when multiple factors contribute (use Fishbone Diagram for complex causality)
+* Blame-focused questioning rather than system-focused
+
+**Example Application**:
+
+```
+Problem: Website is down
+Why? → Database connection failed
+Why? → Connection pool exhausted
+Why? → Long-running queries not timing out
+Why? → No query timeout configured
+Why? → Default configuration was never reviewed for production
+Root Cause: Configuration review process missing
+Countermeasure: Establish pre-production configuration checklist
+```
+
+### Morphological Box
+
+**Full Name**: Morphological Analysis / Morphological Box (German: Morphologischer Kasten)
+
+**Core Concepts**:
+
+**Multi-dimensional decomposition**: Break complex problem into independent parameters/dimensions
+
+**Variant enumeration**: Identify possible values/options for each parameter
+
+**Matrix construction**: Organize parameters and variants in table/box form
+
+**Combinatorial exploration**: Systematically examine combinations of variants
+
+**Constraint filtering**: Eliminate infeasible or contradictory combinations
+
+**Novel solution discovery**: Find non-obvious solutions through systematic recombination
+
+**Complete solution space**: Ensure all possibilities are considered
+
+**Structured creativity**: Systematic approach to innovation and ideation
+
+**Key Proponent**: Fritz Zwicky (1940s-1960s, California Institute of Technology)
+
+**Historical Context**: Developed for aerospace engineering problems (jet engines, spacecraft propulsion), now widely applied in product development, system design, and innovation management.
+
+**When to Use**:
+
+* Exploring design alternatives for complex systems
+* Product feature combination analysis
+* Technology selection with multiple dimensions
+* Architecture decision-making with independent parameters
+* Innovation workshops and ideation sessions
+* Requirements engineering for product variants
+* Solution space mapping before evaluation
+
+**Example Application**:
+
+```
+Problem: Design a developer documentation system
+Parameters:
+├─ Format: Markdown, AsciiDoc, reStructuredText, API-first
+├─ Hosting: GitHub Pages, Netlify, Read the Docs, S3+CloudFront
+├─ Generator: Static (Hugo, Jekyll), Dynamic (Docusaurus), Custom
+└─ Versioning: Git-based, Version selector, Branch-per-version
+
+Matrix generates 4 × 4 × 3 × 3 = 144 possible combinations
+Filter by constraints (e.g., "AsciiDoc + Hugo not well-supported")
+→ Identify ~20 feasible solutions for evaluation with Pugh Matrix
+```
+**Related Concepts**:
+
+* MECE Principle (for parameter independence)
+* Pugh Matrix (for evaluating generated alternatives)
+* Design of Experiments (DOE)
+* Combinatorial design
+* Solution space exploration
+
+**Complementary Tools**:
+
+* Use **Morphological Box** to generate alternatives
+* Then apply **Pugh Matrix** to evaluate and select best option
+* Use **MECE** to ensure parameter independence
+
+**Pitfalls to Avoid**:
+
+* Parameters that are not independent (violates combinatorial logic)
+* Too many parameters leading to combinatorial explosion
+* Stopping at matrix creation without exploring combinations
+* Forgetting to filter out infeasible combinations
+
+### Rubber Duck Debugging
+
+**Full Name**: Rubber Duck Debugging
+
+**Core Concepts**:
+
+**Explain to Understand**: Articulating a problem aloud surfaces gaps in understanding
+
+**Step-by-Step Verbalization**: Force yourself to go through code/logic line by line
+
+**Assumption Surfacing**: Speaking aloud exposes implicit assumptions that may be wrong
+
+**No Expertise Required**: The "listener" (rubber duck, colleague, LLM) need not be an expert
+
+**Slowing Down**: The act of explaining forces a slower, more deliberate thought process
+
+**External Cognition**: Verbalizing creates an external representation that aids debugging
+
+**Self-Directed Learning**: Often the explainer solves the problem before finishing the explanation
+
+**Teaching to Learn**: Related to the Feynman Technique and learning-by-teaching principle
+
+**Key Origin**: "The Pragmatic Programmer" by Andrew Hunt and David Thomas (1999), referencing earlier programmer folklore
+
+**Historical Context**: Decades-old practice in programming culture, formalized and named in influential software engineering literature
+
+**When to Use**:
+
+* Debugging stubborn problems where you're stuck
+* Code review where explaining to a colleague reveals issues
+* Learning new concepts by teaching them to someone (or something) else
+* Validating understanding of complex systems or algorithms
+* When rubber-ducking to an LLM, explicitly adopting this frame to trigger step-by-step explanation
+
+**Related Concepts**:
+
+* Pair programming (where explaining is continuous)
+* Feynman Technique (learning by simple explanation)
+* Socratic Method (when the duck asks questions back)
+
+---
+
+## Requirements Engineering
+
+### EARS-Requirements
+
+**Full Name**: Easy Approach to Requirements Syntax
+
+**Core Concepts**:
+
+**Ubiquitous requirements**: "The <system> shall <requirement>"
+
+**Event-driven requirements**: "WHEN <trigger> the <system> shall <requirement>"
+
+**Unwanted behavior**: "IF <condition>, THEN the <system> shall <requirement>"
+
+**State-driven requirements**: "WHILE <state>, the <system> shall <requirement>"
+
+**Optional features**: "WHERE <feature is included>, the <system> shall <requirement>"
+
+**Structured syntax**: Consistent templates for clarity
+
+**Testability**: Requirements written to be verifiable
+
+**Key Proponent**: Alistair Mavin (Rolls-Royce)
+
+**When to Use**:
+
+* Safety-critical systems
+* Regulated industries (aerospace, automotive, medical)
+* When requirements traceability is essential
+* Large, distributed teams
+
+### Problem Space NVC
+
+**Full Name**: Problem Space in Nonviolent Communication
+
+**Core Concepts**:
+
+**Observations**: Concrete, objective facts without evaluation
+
+**Feelings**: Emotions arising from observations
+
+**Needs**: Universal human needs underlying feelings
+
+**Requests**: Specific, actionable requests (not demands)
+
+**Empathic connection**: Understanding before problem-solving
+
+**Separating observation from interpretation**: Avoiding judgment
+
+**Needs-based conflict resolution**: Finding solutions that meet everyone's needs
+
+**Key Proponent**: Marshall Rosenberg
+
+**Application in Software Development**:
+
+* Requirements elicitation that uncovers real user needs
+* Stakeholder communication and conflict resolution
+* User story formulation focused on needs
+* Retrospectives and team communication
+
+### User Story Mapping
+
+**Full Name**: User Story Mapping according to Jeff Patton
+
+**Core Concepts**:
+
+**Narrative flow**: Horizontal arrangement of user activities
+
+**User activities**: High-level tasks users perform
+
+**User tasks**: Steps within activities
+
+**Walking skeleton**: Minimal end-to-end functionality first
+
+**Release planning**: Horizontal slices for releases
+
+**Prioritization by value**: Vertical ordering by importance
+
+**Shared understanding**: Collaborative mapping builds team alignment
+
+**Big picture view**: See the whole journey, not just backlog items
+
+**Opportunity for conversation**: Stories as placeholders for discussion
+
+**Key Proponent**: Jeff Patton ("User Story Mapping", 2014)
+
+**When to Use**:
+
+* Planning new products or major features
+* When backlog feels overwhelming or fragmented
+* Release planning for incremental delivery
+* Onboarding team members to product vision
+
+---
+
+## Software Architecture
+
+### ADR according to Nygard
+
+**Full Name**: Architecture Decision Records according to Michael Nygard
+
+**Core Concepts**:
+
+**Lightweight documentation**: Short, focused records
+
+**Standard structure**: * Title
+* Status (proposed, accepted, deprecated, superseded)
+* Context (forces at play)
+* Decision (what was chosen)
+* Consequences (both positive and negative)
+
+**Immutability**: ADRs are never deleted, only superseded
+
+**Version control**: ADRs stored with code
+
+**Decision archaeology**: Understanding why past decisions were made
+
+**Evolutionary architecture**: Supporting architecture that changes over time
+
+**Key Proponent**: Michael Nygard
+
+**When to Use**:
+
+* All software projects (low overhead, high value)
+* Distributed teams needing shared understanding
+* When onboarding new team members
+* Complex systems with evolving architecture
+
+### arc42 Architecture Documentation
+
+**Full Name**: arc42 Architecture Documentation Template
+
+**Core Concepts**:
+
+**12 standardized sections**: From introduction to glossary
+
+**Section 1**: Introduction and Goals
+
+**Section 2**: Constraints
+
+**Section 3**: Context and Scope
+
+**Section 4**: Solution Strategy
+
+**Section 5**: Building Block View
+
+**Section 6**: Runtime View
+
+**Section 7**: Deployment View
+
+**Section 8**: Crosscutting Concepts
+
+**Section 9**: Architecture Decisions (ADRs)
+
+**Section 10**: Quality Requirements
+
+**Section 11**: Risks and Technical Debt
+
+**Section 12**: Glossary
+
+**Pragmatic documentation**: Document only what's necessary
+
+**Multiple formats**: AsciiDoc, Markdown, Confluence, etc.
+
+**Key Proponents**: Gernot Starke, Peter Hruschka
+
+**When to Use**:
+
+* Medium to large software projects
+* When stakeholder communication is critical
+* Long-lived systems requiring maintainability
+
+### C4-Diagrams
+
+**Full Name**: C4 Model for Software Architecture Diagrams
+
+**Core Concepts**:
+
+**Four levels of abstraction**: +
+**Level 1 - Context**: : System in its environment (users, external systems)
+**Level 2 - Container**: : Applications and data stores that make up the system
+**Level 3 - Component**: : Components within containers
+**Level 4 - Code**: : Class diagrams, entity relationships (optional)
+
+**Zoom in/out**: Progressive disclosure of detail
+
+**Simple notation**: Boxes and arrows, minimal notation overhead
+
+**Audience-appropriate**: Different diagrams for different stakeholders
+
+**Supplementary diagrams**: Deployment, dynamic views, etc.
+
+**Key Proponent**: Simon Brown
+
+**When to Use**:
+
+* Communicating architecture to diverse stakeholders
+* Onboarding new team members
+* Architecture documentation and review
+* Replacing or supplementing UML
+
+### Clean Architecture
+
+**Full Name**: Clean Architecture according to Robert C. Martin
+
+**Core Concepts**:
+
+**The Dependency Rule**: Dependencies only point inward
+
+**Concentric circles**: Entities → Use Cases → Interface Adapters → Frameworks & Drivers
+
+**Independent of frameworks**: Architecture doesn't depend on libraries
+
+**Testable**: Business rules testable without UI, database, or external elements
+
+**Independent of UI**: UI can change without changing business rules
+
+**Independent of database**: Business rules not bound to database
+
+**Independent of external agencies**: Business rules don't know about outside world
+
+**Screaming Architecture**: Architecture reveals the intent of the system
+
+**SOLID principles**: Foundation of the architecture
+
+**Key Proponent**: Robert C. Martin ("Uncle Bob")
+
+**When to Use**:
+
+* Enterprise applications with complex business logic
+* Systems requiring long-term maintainability
+* When team size and turnover are high
+* Projects where business rules must be protected from technology changes
+
+### Domain-Driven Design according to Evans
+
+**Full Name**: Domain-Driven Design according to Eric Evans
+
+**Core Concepts**:
+
+**Ubiquitous Language**: Shared vocabulary between developers and domain experts
+
+**Bounded Context**: Explicit boundaries where a model is defined and applicable
+
+**Aggregates**: Cluster of domain objects treated as a single unit
+
+**Entities**: Objects defined by identity, not attributes
+
+**Value Objects**: Immutable objects defined by their attributes
+
+**Repositories**: Abstraction for object persistence and retrieval
+
+**Domain Events**: Significant occurrences in the domain
+
+**Strategic Design**: Context mapping, anti-corruption layers
+
+**Tactical Design**: Building blocks (entities, value objects, services)
+
+**Model-Driven Design**: Code that expresses the domain model
+
+**Key Proponent**: Eric Evans ("Domain-Driven Design: Tackling Complexity in the Heart of Software", 2003)
+
+**When to Use**:
+
+* Complex business domains with intricate rules
+* Long-lived systems requiring deep domain understanding
+* When business and technical teams need close collaboration
+* Systems where the domain logic is the core value
+
+### Hexagonal Architecture (Ports & Adapters)
+
+**Also known as**: Ports and Adapters, Onion Architecture (variant)
+
+**Core Concepts**:
+
+**Hexagonal structure**: Core domain at the center, isolated from external concerns
+
+**Ports**: Interfaces defining how the application communicates
+
+**Adapters**: Implementations that connect to external systems
+
+**Dependency inversion**: Dependencies point inward toward the domain
+
+**Technology independence**: Core logic doesn't depend on frameworks or infrastructure
+
+**Primary/Driving adapters**: User interfaces, APIs (inbound)
+
+**Secondary/Driven adapters**: Databases, message queues (outbound)
+
+**Testability**: Easy to test core logic in isolation
+
+**Symmetry**: All external interactions are treated uniformly
+
+**Key Proponent**: Alistair Cockburn (2005)
+
+**When to Use**:
+
+* Applications requiring high testability
+* Systems that need to support multiple interfaces (web, CLI, API)
+* When you want to defer infrastructure decisions
+* Microservices with clear domain boundaries
+
+### MADR
+
+**Full Name**: Markdown Any Decision Records
+
+**Core Concepts**:
+
+**Structured template**: Well-defined format with specific sections
+
+**Standard fields**: * Title (short noun phrase)
+* Status (proposed, accepted, rejected, deprecated, superseded)
+* Context and Problem Statement
+* Decision Drivers (forces influencing the decision)
+* Considered Options (alternatives evaluated)
+* Decision Outcome (chosen option with justification)
+* Pros and Cons of the Options (trade-off analysis)
+* Links (related decisions, references)
+
+**Markdown format**: Uses standard Markdown for wide compatibility
+
+**Clear structure**: More detailed than basic ADRs, includes explicit alternatives
+
+**Trade-off documentation**: Explicitly captures pros/cons of each option
+
+**Version control**: Stored with code, immutable like other ADRs
+
+**Lightweight yet comprehensive**: Balances completeness with maintainability
+
+**Key Proponents**: Oliver Kopp, Olaf Zimmermann (and MADR community)
+
+**Reference**: https://adr.github.io/madr/
+
+**When to Use**:
+
+* When you need more structure than basic ADRs
+* Projects requiring explicit documentation of alternatives
+* Teams that need to justify decisions with detailed trade-offs
+* Organizations using Markdown-based documentation workflows
+* When LLM assistance is needed to generate consistent decision records
+* Complementing arc42 Section 9 (Architecture Decisions)
+
+---
+
+## Statistical Methods & Process Monitoring
+
+### Control Chart (Shewhart)
+
+**Full Name**: Shewhart Control Chart
+
+**Also known as**: Process Control Chart, SPC Chart
+
+**Core Concepts**:
+
+**Time series diagram**: Measured value plotted over time
+
+**Centerline (CL)**: Process mean
+
+**Upper/Lower Control Limit (UCL/LCL)**: Typically at ±3σ from the mean
+
+**Zones A/B/C**: Division into 6 areas (each 1σ wide) for pattern recognition
+
+**Common Cause Variation**: Inherent, random fluctuation of a stable process
+
+**Special Cause Variation**: Assignable, correctable deviation
+
+**Chart Types**: * X-bar Chart: Subgroup means
+* R-Chart: Subgroup ranges
+* I-MR Chart: Individual values and moving range
+* p-Chart: Defect proportions
+* c-Chart: Defect counts per unit
+
+**In-Control vs. Out-of-Control**: Core decision based on rules (Nelson, Western Electric)
+
+**Normal distribution assumption**: Control limits are based on normally distributed data
+
+**Key Proponent**: Walter A. Shewhart (1920s, Bell Labs / Western Electric)
+
+**Key Work**: "Economic Control of Quality of Manufactured Product" (1931)
+
+**Relationship to Other Anchors**:
+
+**Nelson Rules**: 8 rules for pattern recognition on Control Charts
+
+SPC:: Control Charts are the central tool of Statistical Process Control
+
+**Six Sigma**: Control Charts are used in the Control phase of DMAIC
+
+**When to Use**:
+
+* Process monitoring in manufacturing and production
+* Quality assurance using statistical methods
+* Detection of process shifts and trends
+* Foundation for rule-based anomaly detection in time series
+* Conceptual basis — even when different terminology is used in IT monitoring
+
+### Nelson Rules
+
+**Full Name**: Nelson Rules (Tests for Special Causes)
+
+**Core Concepts**:
+
+* **8 rules** for detecting non-random patterns in Control Charts
+**Rule 1**: One point beyond 3σ (Outlier)
+
+**Rule 2**: 9 consecutive points on the same side of the mean (Shift/Bias)
+
+**Rule 3**: 6 consecutive points steadily increasing or decreasing (Trend)
+
+**Rule 4**: 14 points alternating up and down (Oscillation)
+
+**Rule 5**: 2 out of 3 points beyond 2σ on the same side
+
+**Rule 6**: 4 out of 5 points beyond 1σ on the same side
+
+**Rule 7**: 15 points within 1σ (suspiciously low variance)
+
+**Rule 8**: 8 points outside ±1σ, but none beyond ±3σ (systematic oscillation)
+
+**Common Cause vs. Special Cause**: Distinguishing inherent from assignable variation
+
+**Zones A/B/C**: Dividing the Control Chart into 6 zones (each 1σ wide)
+
+**False Positive Trade-off**: More active rules = higher sensitivity, but more false alarms
+
+**Key Proponent**: Lloyd S. Nelson (1984, Journal of Quality Technology)
+
+**Relationship to Other Anchors**:
+
+**Control Chart (Shewhart)**: Nelson Rules are applied to Control Charts
+
+SPC:: Nelson Rules are a tool within Statistical Process Control
+
+**Western Electric Rules**: Predecessor; Nelson Rules extend these with Rules 5-8
+
+**When to Use**:
+
+* Detecting non-random patterns in time series data
+* Process monitoring in manufacturing, pharmaceuticals, healthcare
+* Potential application in IT monitoring (memory leaks, performance degradation)
+* Quality assurance in Six Sigma / DMAIC Control Phase
+
+### SPC (Statistical Process Control)
+
+**Full Name**: Statistical Process Control
+
+**Core Concepts**:
+
+**Process monitoring**: Systematic statistical monitoring of running processes
+
+**Common Cause Variation**: Inherent, random fluctuation — stable and predictable
+
+**Special Cause Variation**: Assignable cause — unstable, correctable
+
+**Control Charts**: Central visual tool (see dedicated anchor)
+
+**Detection rules**: Nelson Rules, Western Electric Rules (see dedicated anchors)
+
+**Process Capability**: Indices Cp, Cpk (short-term) and Pp, Ppk (long-term)
+
+**In-Control**: Process exhibits only Common Cause Variation
+
+**Out-of-Control**: Special Cause detected — intervention required
+
+**Continuous Improvement**: SPC as a foundation for ongoing process improvement
+
+**DMAIC Control Phase**: SPC tools secure improvements within Six Sigma
+
+**Key Proponents**: Walter A. Shewhart (founder), W. Edwards Deming (dissemination), Western Electric Company
+
+**Relationship to Other Anchors**:
+
+**Control Chart (Shewhart)**: Central tool within SPC
+
+**Nelson Rules**: Detection rules for Special Causes on Control Charts
+
+**Six Sigma**: Uses SPC particularly in the Control phase
+
+**Testing Pyramid**: Conceptual parallel — different levels of quality assurance
+
+**When to Use**:
+
+* Monitoring manufacturing and business processes
+* Quality management per ISO 9001, IATF 16949, Six Sigma
+* Pharmaceutical Continuous Process Verification (CPV)
+* Conceptual foundation for anomaly detection in IT systems
+* When the question is: "Is my process stable, or has something changed?"
+
+---
+
+## Strategic Planning
+
+### Cynefin Framework
+
+**Full Name**: Cynefin Framework according to Dave Snowden
+
+**Core Concepts**:
+
+**Five domains**: +
+**Clear (formerly "Simple")**: : Best practices apply, sense-categorize-respond
+**Complicated**: : Good practices exist, sense-analyze-respond
+**Complex**: : Emergent practices, probe-sense-respond
+**Chaotic**: : Novel practices needed, act-sense-respond
+**Confused (center)**: : Don't know which domain you're in
+
+**Domain transitions**: How situations move between domains
+
+**Safe-to-fail probes**: Experiments in complex domain
+
+**Complacency risk**: Moving from clear to chaotic
+
+**Decision-making context**: Different domains require different approaches
+
+**Facilitation tool**: Helps teams discuss and categorize challenges
+
+**Key Proponent**: Dave Snowden (1999)
+
+**When to Use**:
+
+* Understanding what type of problem you're facing
+* Choosing appropriate decision-making approaches
+* Facilitating team discussions about complexity
+* Strategic planning in uncertain environments
+
+### Impact Mapping
+
+**Full Name**: Impact Mapping according to Gojko Adzic
+
+**Core Concepts**:
+
+**Four levels**: Goal → Actors → Impacts → Deliverables
+
+**Goal**: Business objective (Why?)
+
+**Actors**: Who can produce or prevent desired impact? (Who?)
+
+**Impacts**: How can actors' behavior change? (How?)
+
+**Deliverables**: What can we build? (What?)
+
+**Visual mapping**: Mind-map style collaborative diagram
+
+**Assumption testing**: Make assumptions explicit
+
+**Scope management**: Prevent scope creep by linking to goals
+
+**Roadmap alternative**: Goal-oriented rather than feature-oriented
+
+**Key Proponent**: Gojko Adzic ("Impact Mapping", 2012)
+
+**When to Use**:
+
+* Strategic planning for products or projects
+* When stakeholders disagree on priorities
+* Aligning delivery with business outcomes
+* Avoiding building features that don't serve business goals
+
+### Jobs To Be Done (JTBD)
+
+**Full Name**: Jobs To Be Done Framework (Christensen interpretation)
+
+**Core Concepts**:
+
+**Job definition**: Progress people want to make in a particular context
+
+**Functional job**: Practical task to accomplish
+
+**Emotional job**: How people want to feel
+
+**Social job**: How people want to be perceived
+
+**Hire and fire**: Customers "hire" products to do a job, "fire" when inadequate
+
+**Context matters**: Jobs exist in specific circumstances
+
+**Competition redefined**: Anything solving the same job is competition
+
+**Innovation opportunities**: Unmet jobs or poorly served jobs
+
+**Job stories**: Alternative to user stories focusing on context and motivation
+
+**Key Proponents**: Clayton Christensen, Alan Klement, Bob Moesta
+
+**When to Use**:
+
+* Product discovery and innovation
+* Understanding why customers choose solutions
+* Identifying true competition
+* Writing more meaningful user stories
+* Market segmentation based on jobs, not demographics
+
+### Pugh-Matrix
+
+**Full Name**: Pugh Decision Matrix (also Pugh Controlled Convergence)
+
+**Core Concepts**:
+
+**Baseline comparison**: Compare alternatives against a reference solution
+
+**Criteria weighting**: Assign importance to evaluation criteria
+
+**Relative scoring**: Better (+), Same (S), Worse (-) than baseline
+
+**Structured evaluation**: Systematic comparison across multiple dimensions
+
+**Iterative refinement**: Multiple rounds to converge on best solution
+
+**Team decision-making**: Facilitates group consensus
+
+**Hybrid solutions**: Combine strengths of different alternatives
+
+**Key Proponent**: Stuart Pugh
+
+**When to Use**:
+
+* Multiple viable alternatives exist
+* Decision criteria are known but trade-offs are unclear
+* Team needs to reach consensus
+* Architecture or technology selection decisions
+
+### Wardley Mapping
+
+**Core Concepts**:
+
+**Value chain**: Map components from user needs down
+
+**Evolution axis**: Genesis → Custom → Product → Commodity
+
+**Movement**: Components naturally evolve over time
+
+**Situational awareness**: Understanding the landscape before deciding
+
+**Gameplay patterns**: Common strategic moves
+
+**Climatic patterns**: Forces that affect all players
+
+**Doctrine**: Universal principles of good strategy
+
+**Inertia**: Resistance to change in organizations
+
+**Strategic planning**: Visual approach to strategy
+
+**Build-Buy-Partner decisions**: Based on evolution stage
+
+**Key Proponent**: Simon Wardley
+
+**When to Use**:
+
+* Strategic technology planning
+* Build vs. buy decisions
+* Understanding competitive landscape
+* Communicating strategy visually
+* Identifying opportunities for disruption
+
+---
+
+## Testing & Quality Practices
+
+### IEC 61508 SIL Levels
+
+**Full Name**: IEC 61508 Safety Integrity Levels
+
+**Also known as**: Functional Safety Levels, SIL Classification
+
+**Core Concepts**:
+
+**Four Safety Integrity Levels**: +
+**SIL 1 (lowest)**: : 10^-2^ ≤ PFD < 10^-1^ (tolerable risk reduction)
+**SIL 2**: : 10^-3^ ≤ PFD < 10^-2^ (moderate risk reduction)
+**SIL 3**: : 10^-4^ ≤ PFD < 10^-3^ (substantial risk reduction)
+**SIL 4 (highest)**: : 10^-5^ ≤ PFD < 10^-4^ (maximum risk reduction)
+
+**Risk-based classification**: SIL level determined by hazard analysis and risk assessment
+
+**Safety lifecycle**: Systematic approach from concept to decommissioning
+
+**Hardware requirements**: Architectural constraints and systematic capability
+
+**Software requirements**: Development methods, verification, and validation techniques
+
+**Probability of Failure on Demand (PFD)**: Key metric for safety function reliability
+
+**Safety instrumented systems (SIS)**: Protection layers implementing safety functions
+
+**Verification and validation**: Independent assessment of safety claims
+
+**Systematic failures**: Focus on preventing design and specification errors
+
+**Random hardware failures**: Statistical analysis and fault tolerance
+
+**Key Standard**: IEC 61508 "Functional Safety of Electrical/Electronic/Programmable Electronic Safety-related Systems" (first edition 1998, second edition 2010)
+
+**Related Standards**:
+
+* IEC 61511 (Process industry)
+* ISO 26262 (Automotive)
+* EN 50128 (Railway)
+* IEC 62304 (Medical devices)
+
+**When to Use**:
+
+* Developing safety-critical embedded systems
+* Assessing risk in industrial automation and control systems
+* Certifying safety instrumented systems
+* Designing fail-safe mechanisms and redundancy
+* Establishing software development processes for safety applications
+* Conducting hazard and operability (HAZOP) studies
+* Implementing functional safety management systems
+
+### Mutation Testing
+
+**Also known as**: Mutation Analysis, Fault-Based Testing
+
+**Core Concepts**:
+
+**Test quality assessment**: Evaluate how effective tests are at detecting bugs
+
+**Code mutations**: Deliberately introduce small, syntactic changes (mutants) into source code
+
+**Mutation operators**: Rules for creating mutants (e.g., change `>` to `>=`, flip boolean, remove statement)
+
+**Killed mutants**: Mutations caught by failing tests (good)
+
+**Survived mutants**: Mutations not detected by tests (indicates test weakness)
+
+**Equivalent mutants**: Mutations that don't change program behavior (false positives)
+
+**Mutation score**: Percentage of killed mutants: `(killed / (total - equivalent)) × 100%`
+
+**First-order mutations**: Single atomic change per mutant
+
+**Higher-order mutations**: Multiple changes combined
+
+**Weak mutation**: Test only needs to create different internal state
+
+**Strong mutation**: Test must produce different final output
+
+**Test adequacy criterion**: "Are tests good enough?" not just "Is coverage high enough?"
+
+**Key Proponents**: Richard Lipton (theoretical foundation, 1971), Richard DeMillo, Timothy Budd
+
+**Key Tools**:
+
+* PITest (Java)
+* Stryker (JavaScript/TypeScript, C#, Scala)
+* Mutmut (Python)
+* Infection (PHP)
+* Mull (C/C++)
+
+**When to Use**:
+
+* Evaluating test suite quality beyond coverage metrics
+* Identifying gaps in test assertions
+* Critical systems requiring high test confidence
+* Complementing code coverage as a quality metric
+* Refactoring legacy code with existing tests
+* Teaching effective testing practices
+* Continuous improvement of test effectiveness
+
+**Practical Challenges**:
+
+**Computational cost**: N mutations × M tests = expensive
+
+**Equivalent mutant problem**: Hard to automatically detect functionally identical mutants
+
+**Time investment**: Can be slow on large codebases
+
+**Mitigation strategies**: Selective mutation, mutation sampling, incremental analysis
+
+**Relationship to Other Practices**:
+
+**Code coverage**: Mutation testing reveals that high coverage ≠ good tests
+
+**TDD**: Strong TDD often produces high mutation scores naturally
+
+**Property-based testing**: Orthogonal but complementary approaches
+
+**Fault injection**: Similar concept applied to production systems
+
+### Property-Based Testing
+
+**Also known as**: Generative Testing, QuickCheck-style Testing
+
+**Core Concepts**:
+
+**Properties**: Invariants that should always hold
+
+**Generators**: Automatic test data creation
+
+**Shrinking**: Minimizing failing test cases to simplest form
+
+**Universal quantification**: Testing "for all inputs"
+
+**Specification testing**: Testing high-level properties, not examples
+
+**Edge case discovery**: Finds cases you didn't think of
+
+**Complementary to example-based**: Works alongside traditional unit tests
+
+**Stateful testing**: Testing sequences of operations
+
+**Model-based testing**: Compare implementation against simpler model
+
+**Key Tools**: QuickCheck (Haskell), Hypothesis (Python), fast-check (JavaScript), FsCheck (.NET)
+
+**When to Use**:
+
+* Testing pure functions and algorithms
+* Validating business rules and invariants
+* Testing parsers and serializers
+* Finding edge cases in complex logic
+* Complementing example-based TDD
+
+### TDD, Chicago School
+
+**Also known as**: Classicist TDD, Detroit School
+
+**Core Concepts**:
+
+**State-based testing**: Verify the state of objects after operations
+
+**Minimal mocking**: Use real objects whenever possible; mock only external dependencies
+
+**Inside-out development**: Start with core domain logic and build outward
+
+**Simplicity focus**: Emergent design through refactoring
+
+**Red-Green-Refactor**: The fundamental TDD cycle
+
+**YAGNI**: You Aren't Gonna Need It - avoid premature abstraction
+
+**Key Proponents**: Kent Beck, Martin Fowler
+
+**When to Use**:
+
+* Domain-driven design projects
+* When business logic is central
+* Smaller, cohesive modules
+
+### TDD, London School
+
+**Also known as**: Mockist TDD, Outside-In TDD
+
+**Core Concepts**:
+
+**Mock-heavy testing**: Heavy use of test doubles (mocks, stubs) to isolate units
+
+**Outside-in development**: Start from the outermost layers (UI, API) and work inward
+
+**Interaction-based testing**: Focus on verifying interactions between objects
+
+**Behavior verification**: Test how objects collaborate rather than state
+
+**Interface discovery**: Use tests to discover and define interfaces
+
+**Walking skeleton**: Build end-to-end functionality early, then fill in details
+
+**Key Proponents**: Steve Freeman, Nat Pryce ("Growing Object-Oriented Software, Guided by Tests")
+
+**When to Use**:
+
+* Complex systems with many collaborating objects
+* When designing APIs and interfaces
+* Distributed systems where integration is costly
+
+### Testing Pyramid
+
+**Full Name**: Testing Pyramid according to Mike Cohn
+
+**Core Concepts**:
+
+**Three layers**: * **Unit tests** (base): Many fast, isolated tests
+* **Integration tests** (middle): Moderate number, test component interaction
+* **End-to-end tests** (top): Few, test complete user journeys
+
+**Proportional distribution**: More unit tests, fewer E2E tests
+
+**Cost and speed**: Unit tests cheap and fast, E2E tests expensive and slow
+
+**Feedback loops**: Faster feedback from lower levels
+
+Anti-pattern: Ice cream cone:: Too many E2E tests, too few unit tests
+
+**Test at the right level**: Don't test through UI what can be tested in isolation
+
+**Confidence gradient**: Balance confidence with execution speed
+
+**Key Proponent**: Mike Cohn ("Succeeding with Agile", 2009)
+
+**When to Use**:
+
+* Planning test strategy for projects
+* Balancing test types in CI/CD pipelines
+* Evaluating existing test suites
+* Guiding team testing practices
+
+---