feat: add 8 verified semantic anchors

Adds eight anchors that passed verification against the catalog's quality
criteria (precise, rich, consistent, attributable) plus the recognition
test, each with EN + DE docs, metadata, changelog and AgentSkill catalog
entries:

- Conway's Law (#506) — software architecture
- CAP Theorem (#508) — software architecture
- Fallacies of Distributed Computing (#507) — software architecture
- Law of Demeter (#509) — design principles
- First Principles Thinking (#510) — problem-solving
- Postel's Law / Robustness Principle (#512) — design principles
- Goodhart's Law (#513) — strategic planning
- Inverted Pyramid Style (#538, proposed by @mhchem) — communication

Borderline proposals (Inversion #511, One sentence per line #539,
TDD Hamburg School #458) and the counter-example YOLO (#443) were left
out pending rework/decision.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Author: raifdmueller

docs/anchors/cap-theorem.adoc

@@ -0,0 +1,49 @@
+= CAP Theorem
+:categories: software-architecture
+:roles: software-architect, data-scientist, devops-engineer
+:related: event-driven-architecture, fallacies-of-distributed-computing
+:proponents: Eric Brewer, Seth Gilbert, Nancy Lynch
+:tags: cap, distributed-systems, consistency, availability, partition-tolerance, pacelc
+:tier: 3
+
+[%collapsible]
+====
+Full Name:: CAP Theorem (Consistency, Availability, Partition tolerance)
+
+Also known as:: Brewer's Theorem
+
+[discrete]
+== *Core Concepts*:
+
+The three properties:: *Consistency* (every read sees the most recent write), *Availability* (every request gets a non-error response), *Partition tolerance* (the system keeps working despite dropped/delayed messages between nodes)
+
+The trade-off:: When a network partition occurs, a distributed system must choose between consistency and availability — it cannot have both during the partition
+
+Partitions are not optional:: Real networks partition, so P is a given; the genuine design choice is CP vs AP behaviour *while partitioned*
+
+Common misreading:: "Pick 2 of 3" is a simplification; outside a partition a system can be both consistent and available
+
+PACELC extension:: Else (no partition), trade Latency against Consistency — captures the everyday tuning that CAP alone omits (Abadi, 2012)
+
+Key Proponents:: Eric Brewer (2000 conjecture, PODC keynote); formally proved by Seth Gilbert & Nancy Lynch (2002); PACELC by Daniel Abadi (2012)
+
+[discrete]
+== *When to Use*:
+
+* Choosing or evaluating a distributed datastore (CP vs AP behaviour)
+* Framing a concrete consistency/availability trade-off for a feature
+* Reasoning about behaviour during network partitions and failover
+* Explaining why strong consistency costs availability or latency
+
+[discrete]
+== *When NOT to Use*:
+
+* For single-node systems with no replication (no partitions to tolerate)
+* As a crude "2 of 3" slogan — prefer the partition-time framing or PACELC
+
+[discrete]
+== *Related Anchors*:
+
+* <<event-driven-architecture,Event-Driven Architecture>> — eventual consistency as an AP design choice
+* <<fallacies-of-distributed-computing,Fallacies of Distributed Computing>> — the network assumptions CAP makes explicit
+====

docs/anchors/cap-theorem.de.adoc

@@ -0,0 +1,49 @@
+= CAP Theorem
+:categories: software-architecture
+:roles: software-architect, data-scientist, devops-engineer
+:related: event-driven-architecture, fallacies-of-distributed-computing
+:proponents: Eric Brewer, Seth Gilbert, Nancy Lynch
+:tags: cap, distributed-systems, consistency, availability, partition-tolerance, pacelc
+:tier: 3
+
+[%collapsible]
+====
+Vollständiger Name:: CAP-Theorem (Consistency, Availability, Partition tolerance)
+
+Auch bekannt als:: Brewers Theorem
+
+[discrete]
+== *Kernkonzepte*:
+
+Die drei Eigenschaften:: *Consistency* (jeder Read sieht den letzten Write), *Availability* (jede Anfrage erhält eine Nicht-Fehler-Antwort), *Partition tolerance* (das System arbeitet trotz verlorener/verzögerter Nachrichten zwischen Knoten weiter)
+
+Der Trade-off:: Bei einer Netzwerkpartition muss ein verteiltes System zwischen Consistency und Availability wählen — während der Partition geht nicht beides
+
+Partitionen sind nicht optional:: Reale Netze partitionieren, also ist P gesetzt; die eigentliche Designwahl ist CP- vs. AP-Verhalten *während* der Partition
+
+Häufiges Missverständnis:: „2 von 3 wählen" ist eine Vereinfachung; ohne Partition kann ein System gleichzeitig konsistent und verfügbar sein
+
+PACELC-Erweiterung:: Else (keine Partition) Latency gegen Consistency abwägen — bildet das alltägliche Tuning ab, das CAP allein auslässt (Abadi, 2012)
+
+Key Proponents:: Eric Brewer (Vermutung 2000, PODC-Keynote); formal bewiesen von Seth Gilbert & Nancy Lynch (2002); PACELC von Daniel Abadi (2012)
+
+[discrete]
+== *Verwendung*:
+
+* Auswahl/Bewertung eines verteilten Datenspeichers (CP- vs. AP-Verhalten)
+* Konkreter Consistency-/Availability-Trade-off für ein Feature
+* Verhalten bei Netzwerkpartitionen und Failover durchdenken
+* Erklären, warum starke Konsistenz Verfügbarkeit oder Latenz kostet
+
+[discrete]
+== *Nicht verwenden*:
+
+* Für Ein-Knoten-Systeme ohne Replikation (keine Partitionen zu tolerieren)
+* Als plumpe „2 von 3"-Parole — besser die Partitions-Sicht oder PACELC
+
+[discrete]
+== *Verwandte Anker*:
+
+* <<event-driven-architecture,Event-Driven Architecture>> — Eventual Consistency als AP-Designwahl
+* <<fallacies-of-distributed-computing,Fallacies of Distributed Computing>> — die Netzannahmen, die CAP explizit macht
+====

docs/anchors/conways-law.adoc

@@ -0,0 +1,50 @@
+= Conway's Law
+:categories: software-architecture
+:roles: software-architect, team-lead, product-owner, consultant
+:related: domain-driven-design, cohesion-criteria, vertical-slice-architecture
+:proponents: Melvin E. Conway
+:tags: conways-law, organization, architecture, team-topologies, communication-structure, sociotechnical
+:tier: 3
+
+[%collapsible]
+====
+Full Name:: Conway's Law
+
+Also known as:: The Mirroring Hypothesis
+
+[discrete]
+== *Core Concepts*:
+
+Homomorphic force:: "Any organization that designs a system will produce a design whose structure is a copy of the organization's communication structure" — system boundaries mirror team boundaries
+
+Communication paths:: Interfaces in the software appear wherever two teams must coordinate; the cost and friction of cross-team communication shapes where modules are split
+
+Inverse Conway Maneuver:: Deliberately structure teams to match the desired architecture, rather than letting an accidental org chart dictate the system
+
+Team Topologies:: Modern operationalization (Skelton & Pais) — stream-aligned, platform, enabling, and complicated-subsystem teams sized for a manageable cognitive load
+
+Sociotechnical view:: Architecture is not purely technical; org design and system design are two sides of the same decision
+
+Key Proponents:: Melvin E. Conway ("How Do Committees Invent?", Datamation 1968); popularized by Fred Brooks ("The Mythical Man-Month"); modern form in Matthew Skelton & Manuel Pais ("Team Topologies", 2019)
+
+[discrete]
+== *When to Use*:
+
+* Planning team structure for a new system or a re-architecture
+* Diagnosing why module boundaries are awkward or why integration is painful
+* Justifying microservice/bounded-context splits along team lines
+* Reviewing whether the org chart is fighting the intended architecture
+
+[discrete]
+== *When NOT to Use*:
+
+* As a deterministic prediction — it is a strong tendency, not a law of physics
+* For tiny single-team systems where there is only one communication path
+
+[discrete]
+== *Related Anchors*:
+
+* <<domain-driven-design,Domain-Driven Design>> — bounded contexts as team-aligned boundaries
+* <<cohesion-criteria,Cohesion Criteria>> — module cohesion that team boundaries should respect
+* <<vertical-slice-architecture,Vertical Slice Architecture>> — slices that map to stream-aligned teams
+====

docs/anchors/conways-law.de.adoc

@@ -0,0 +1,50 @@
+= Conway's Law
+:categories: software-architecture
+:roles: software-architect, team-lead, product-owner, consultant
+:related: domain-driven-design, cohesion-criteria, vertical-slice-architecture
+:proponents: Melvin E. Conway
+:tags: conways-law, organization, architecture, team-topologies, communication-structure, sociotechnical
+:tier: 3
+
+[%collapsible]
+====
+Vollständiger Name:: Conway's Law (Gesetz von Conway)
+
+Auch bekannt als:: Mirroring-Hypothese
+
+[discrete]
+== *Kernkonzepte*:
+
+Homomorphe Kraft:: „Organisationen, die Systeme entwerfen, bringen Entwürfe hervor, deren Struktur die Kommunikationsstruktur der Organisation abbildet" — Systemgrenzen spiegeln Teamgrenzen
+
+Kommunikationspfade:: Schnittstellen in der Software entstehen dort, wo zwei Teams sich abstimmen müssen; Kosten und Reibung der teamübergreifenden Kommunikation bestimmen, wo Module getrennt werden
+
+Inverse Conway Maneuver:: Teams gezielt nach der gewünschten Architektur schneiden, statt ein zufälliges Org-Chart das System bestimmen zu lassen
+
+Team Topologies:: Moderne Ausprägung (Skelton & Pais) — stream-aligned, platform, enabling und complicated-subsystem Teams, dimensioniert auf eine bewältigbare kognitive Last
+
+Soziotechnische Sicht:: Architektur ist nicht rein technisch; Organisations- und Systemdesign sind zwei Seiten derselben Entscheidung
+
+Key Proponents:: Melvin E. Conway („How Do Committees Invent?", Datamation 1968); popularisiert durch Fred Brooks („The Mythical Man-Month"); moderne Form bei Matthew Skelton & Manuel Pais („Team Topologies", 2019)
+
+[discrete]
+== *Verwendung*:
+
+* Planung der Teamstruktur für ein neues System oder eine Re-Architektur
+* Diagnose, warum Modulgrenzen ungünstig liegen oder Integration schmerzhaft ist
+* Begründung von Microservice-/Bounded-Context-Schnitten entlang der Teamgrenzen
+* Prüfung, ob das Org-Chart gegen die beabsichtigte Architektur arbeitet
+
+[discrete]
+== *Nicht verwenden*:
+
+* Als deterministische Vorhersage — es ist eine starke Tendenz, kein Naturgesetz
+* Für winzige Ein-Team-Systeme mit nur einem Kommunikationspfad
+
+[discrete]
+== *Verwandte Anker*:
+
+* <<domain-driven-design,Domain-Driven Design>> — Bounded Contexts als teamgerechte Grenzen
+* <<cohesion-criteria,Kohäsionskriterien>> — Modulkohäsion, die Teamgrenzen respektieren sollten
+* <<vertical-slice-architecture,Vertical Slice Architecture>> — Slices, die auf stream-aligned Teams abbilden
+====

docs/anchors/fallacies-of-distributed-computing.adoc

@@ -0,0 +1,48 @@
+= Fallacies of Distributed Computing
+:categories: software-architecture
+:roles: software-architect, software-developer, devops-engineer
+:related: cap-theorem, event-driven-architecture, hexagonal-architecture
+:proponents: L. Peter Deutsch, James Gosling
+:tags: distributed-systems, networking, reliability, latency, fallacies, resilience
+:tier: 3
+
+[%collapsible]
+====
+Full Name:: The Eight Fallacies of Distributed Computing
+
+Also known as:: Deutsch's Fallacies, Fallacies of Networked Computing
+
+[discrete]
+== *Core Concepts*:
+
+The eight false assumptions:: (1) The network is reliable. (2) Latency is zero. (3) Bandwidth is infinite. (4) The network is secure. (5) Topology doesn't change. (6) There is one administrator. (7) Transport cost is zero. (8) The network is homogeneous
+
+Why it matters:: Each assumption is comfortable in local development and false in production; building on them produces systems that fail under real network conditions
+
+As an audit checklist:: Invoke the list to interrogate a distributed design — for each fallacy, ask what happens when the real-world opposite is true (retries, timeouts, backpressure, encryption, service discovery, capacity limits, protocol negotiation)
+
+Mitigation cues:: Reliability → retries/idempotency; latency → batching/locality; security → zero-trust; topology → service discovery; homogeneity → explicit contracts and versioning
+
+Key Proponents:: L. Peter Deutsch (first seven, Sun Microsystems, c. 1994); James Gosling added the eighth ("the network is homogeneous"); early items credited to Bill Joy and Tom Lyon
+
+[discrete]
+== *When to Use*:
+
+* Reviewing or hardening a distributed/microservice design
+* Writing resilience requirements (timeouts, retries, circuit breakers)
+* Onboarding developers moving from monolith to distributed thinking
+* Post-incident analysis of network-related outages
+
+[discrete]
+== *When NOT to Use*:
+
+* For purely in-process, single-machine logic with no network calls
+* As a substitute for measuring your actual network's behaviour
+
+[discrete]
+== *Related Anchors*:
+
+* <<cap-theorem,CAP Theorem>> — the consistency/availability consequence of partitions
+* <<event-driven-architecture,Event-Driven Architecture>> — async patterns that assume unreliable networks
+* <<hexagonal-architecture,Hexagonal Architecture>> — isolating network adapters behind ports
+====

docs/anchors/fallacies-of-distributed-computing.de.adoc

@@ -0,0 +1,48 @@
+= Fallacies of Distributed Computing
+:categories: software-architecture
+:roles: software-architect, software-developer, devops-engineer
+:related: cap-theorem, event-driven-architecture, hexagonal-architecture
+:proponents: L. Peter Deutsch, James Gosling
+:tags: distributed-systems, networking, reliability, latency, fallacies, resilience
+:tier: 3
+
+[%collapsible]
+====
+Vollständiger Name:: Die acht Trugschlüsse des verteilten Rechnens
+
+Auch bekannt als:: Deutsch's Fallacies, Fallacies of Networked Computing
+
+[discrete]
+== *Kernkonzepte*:
+
+Die acht falschen Annahmen:: (1) Das Netzwerk ist zuverlässig. (2) Latenz ist null. (3) Bandbreite ist unendlich. (4) Das Netzwerk ist sicher. (5) Die Topologie ändert sich nicht. (6) Es gibt einen Administrator. (7) Transportkosten sind null. (8) Das Netzwerk ist homogen
+
+Warum es zählt:: Jede Annahme ist in der lokalen Entwicklung bequem und in Produktion falsch; darauf aufgebaute Systeme scheitern unter realen Netzbedingungen
+
+Als Audit-Checkliste:: Die Liste nutzen, um einen verteilten Entwurf zu hinterfragen — pro Fallacy fragen, was passiert, wenn das reale Gegenteil zutrifft (Retries, Timeouts, Backpressure, Verschlüsselung, Service Discovery, Kapazitätsgrenzen, Protokollverhandlung)
+
+Mitigations-Hinweise:: Zuverlässigkeit → Retries/Idempotenz; Latenz → Batching/Lokalität; Sicherheit → Zero-Trust; Topologie → Service Discovery; Homogenität → explizite Contracts und Versionierung
+
+Key Proponents:: L. Peter Deutsch (die ersten sieben, Sun Microsystems, ca. 1994); James Gosling ergänzte den achten („das Netzwerk ist homogen"); frühe Punkte werden Bill Joy und Tom Lyon zugeschrieben
+
+[discrete]
+== *Verwendung*:
+
+* Review oder Härtung eines verteilten/Microservice-Entwurfs
+* Formulieren von Resilienz-Anforderungen (Timeouts, Retries, Circuit Breaker)
+* Onboarding von Entwicklern vom Monolithen zum verteilten Denken
+* Post-Incident-Analyse netzbedingter Ausfälle
+
+[discrete]
+== *Nicht verwenden*:
+
+* Für rein In-Process-Logik auf einer Maschine ohne Netzaufrufe
+* Als Ersatz dafür, das Verhalten des echten Netzes zu messen
+
+[discrete]
+== *Verwandte Anker*:
+
+* <<cap-theorem,CAP Theorem>> — die Consistency-/Availability-Folge von Partitionen
+* <<event-driven-architecture,Event-Driven Architecture>> — Async-Muster, die unzuverlässige Netze annehmen
+* <<hexagonal-architecture,Hexagonal Architecture>> — Netz-Adapter hinter Ports isolieren
+====

docs/anchors/first-principles-thinking.adoc

@@ -0,0 +1,50 @@
+= First Principles Thinking
+:categories: problem-solving
+:roles: software-architect, consultant, educator, product-owner
+:related: feynman-technique, socratic-method, five-whys
+:proponents: Aristotle, René Descartes
+:tags: first-principles, reasoning, decomposition, problem-solving, assumptions
+:tier: 3
+
+[%collapsible]
+====
+Full Name:: First Principles Thinking
+
+Also known as:: Reasoning from First Principles, Reasoning from Fundamentals
+
+[discrete]
+== *Core Concepts*:
+
+Reduce to fundamentals:: Break a problem down to the basic truths that cannot be deduced from anything more fundamental, then reason upward from those
+
+Reason vs. analogy:: Contrast with reasoning by analogy ("we do it this way because that's how it's done") — first principles rebuild the answer from the ground up
+
+Challenge inherited assumptions:: Each "requirement" or "constraint" is interrogated: is it a law of nature, or merely convention/legacy that can be discarded?
+
+Ground-up synthesis:: After identifying the irreducible elements, recombine them into a solution unconstrained by how the problem was solved before
+
+Cost of the method:: Powerful but expensive — reserve it for high-stakes or stuck problems; reasoning by analogy is fine for routine decisions
+
+Key Proponents:: Rooted in Aristotle (the "first cause"/archē); sharpened by René Descartes' methodical doubt; popularized in modern engineering discourse (e.g. Elon Musk's cost-of-batteries example)
+
+[discrete]
+== *When to Use*:
+
+* A problem feels blocked because "that's just how it's done"
+* Re-examining requirements, cost structures, or architecture constraints
+* High-stakes design decisions where analogy may mislead
+* Teaching learners to separate fundamental truths from convention
+
+[discrete]
+== *When NOT to Use*:
+
+* Routine decisions where established patterns are good enough — the method is costly
+* When proven best practices already encode hard-won fundamentals
+
+[discrete]
+== *Related Anchors*:
+
+* <<feynman-technique,Feynman Technique>> — explain from fundamentals to expose gaps
+* <<socratic-method,Socratic Method>> — question assumptions to reach bedrock
+* <<five-whys,Five Whys>> — drill from symptom toward a root cause
+====