feat: add Business Rules (BR-IDs) to Use Cases, workflow, and contracts

- Add numbered Business Rules (BR-xx-yyy) to 8 of 10 Use Cases where
  domain logic exists (UC-04 and UC-09 are pure navigation, no rules)
- Update Step 4 (Specification) to include Business Rules as fifth
  required Use Case element
- Update Prompt Cheat Sheet and Semantic Contract accordingly
- Update brownfield workflow reverse-engineering prompt

Business Rules make implicit validation constraints, calculation logic,
and domain invariants explicit — preventing AI from inventing or
skipping validation during implementation.

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

Author: raifdmueller

docs/brownfield-workflow.adoc

@@ -64,7 +64,7 @@ The output is a set of use cases that describe the *existing* behavior -- not wh
 .Prompt
 ----
 Read the code in [bounded context path]. Extract the existing behavior as Use Cases.
-For each Use Case: ID, Trigger, Actors, Preconditions, Main Flow, Alternative Flows, Postconditions.
+For each Use Case: ID, Trigger, Actors, Preconditions, Main Flow, Alternative Flows, Postconditions, Business Rules.
 Save as docs/specs/use-cases-[context-name].adoc.
 ----
 

docs/spec-driven-workflow.adoc

@@ -210,7 +210,7 @@ From the PRD, generate a full specification:
 [source]
 ----
 Create a detailed specification from the PRD. Include:
-- Use Cases (Trigger, Main Flow, Alternative Flows, Postconditions)
+- Use Cases (Trigger, Main Flow, Alternative Flows, Postconditions, Business Rules)
 - Activity Diagrams for all flows (not just the happy path)
 - Acceptance criteria in Gherkin format
 Save as .adoc files in src/docs/specs/.
@@ -224,6 +224,9 @@ Without a trigger, neither the AI nor a tester knows when the use case begins.
 * *Alternative Flows*: Named branches (A1, A2, ...) for error handling, validation failures, and edge cases.
 * *Postconditions*: The guaranteed system state after successful completion.
 Postconditions are what your tests assert.
+* *Business Rules*: Numbered rules (BR-001, BR-002, ...) that capture validation constraints, calculation logic, or domain invariants.
+Business rules make implicit knowledge explicit.
+Without them, the AI invents its own validation logic -- or skips it entirely.
 
 This structure follows Alistair Cockburn's Use Case format, which LLMs recognize reliably.
 The more precise the use case, the less the AI has to guess during implementation.
@@ -457,7 +460,7 @@ The essential one-liners for each phase, with the Semantic Anchors they activate
 |link:#/anchor/plain-english-strunk-white[Strunk & White]
 
 |Specification
-|`Create a detailed spec with Use Cases (Trigger, Main Flow, Alternative Flows, Postconditions), Activity Diagrams (all paths), and Gherkin acceptance criteria.`
+|`Create a detailed spec with Use Cases (Trigger, Main Flow, Alternative Flows, Postconditions, Business Rules), Activity Diagrams (all paths), and Gherkin acceptance criteria.`
 |link:#/anchor/gherkin[Gherkin]
 
 |Architecture

docs/specs/01_use_cases.adoc

@@ -47,6 +47,10 @@ stop
 * URL enthält Filter-Parameter (für Deep-Linking)
 * Filter-Auswahl wird in localStorage persistiert
 
+=== Geschäftsregeln
+* **BR-01-001**: Ein Anker kann mehreren Rollen zugeordnet sein. Filterung zeigt alle Anker, die mindestens eine der ausgewählten Rollen enthalten.
+* **BR-01-002**: Bei Auswahl von "All Roles" oder leerem Filter werden alle Anker ohne Einschränkung angezeigt.
+
 === Fehlerszenarien
 * **F1**: Keine Anker für ausgewählte Rolle → System zeigt "Keine Anker gefunden für diese Rolle"
 * **F2**: Browser-localStorage nicht verfügbar → Filter wird nicht persistiert, aber funktioniert während Session
@@ -100,6 +104,10 @@ stop
 * Treemap ist interaktiv und responsive
 * Kategorien sind proportional zur Anzahl ihrer Anker dargestellt
 
+=== Geschäftsregeln
+* **BR-02-001**: Kategorie-Größe in der Treemap entspricht der Anzahl der enthaltenen Anker.
+* **BR-02-002**: Kategorien ohne Anker (nach Filterung) werden nicht dargestellt.
+
 === Fehlerszenarien
 * **F1**: Metadata-Datei nicht gefunden → System zeigt Fehlermeldung "Kategorien können nicht geladen werden"
 * **F2**: Sehr kleine Bildschirmgröße → Treemap wird zu vereinfachter Liste
@@ -151,6 +159,11 @@ stop
 * Suchergebnisse sind nach Relevanz sortiert
 * URL enthält Suchquery (für Deep-Linking)
 
+=== Geschäftsregeln
+* **BR-03-001**: Suche durchsucht Anker-Namen, Proponenten, Core Concepts und Tags. Andere Felder werden nicht durchsucht.
+* **BR-03-002**: Suche wird debounced (min. 150ms Verzögerung) um übermäßige Anfragen zu vermeiden.
+* **BR-03-003**: Suchbegriffe werden auf maximal 100 Zeichen begrenzt.
+
 === Fehlerszenarien
 * **F1**: Suchindex nicht geladen → System zeigt "Suche vorübergehend nicht verfügbar"
 * **F2**: Sehr lange Suchbegriffe → System limitiert auf 100 Zeichen
@@ -249,6 +262,11 @@ stop
 * Sprachpräferenz wird bei nächstem Besuch beibehalten
 * `<html lang="...">` ist korrekt gesetzt
 
+=== Geschäftsregeln
+* **BR-05-001**: Unterstützte Sprachen: Englisch (EN) und Deutsch (DE). Englisch ist die Standardsprache.
+* **BR-05-002**: Nur UI-Texte (Navigation, Labels, Buttons, Tooltips) werden übersetzt. Anker-Inhalte bleiben in der Originalsprache.
+* **BR-05-003**: Fehlende Übersetzungen fallen auf Englisch zurück, niemals auf leere Strings.
+
 === Fehlerszenarien
 * **F1**: Übersetzung fehlt → System zeigt Fallback auf Englisch
 * **F2**: localStorage nicht verfügbar → Sprache nur für aktuelle Session
@@ -295,6 +313,10 @@ stop
 * Theme-Präferenz wird persistiert
 * Alle Komponenten (inkl. Treemap) respektieren Theme
 
+=== Geschäftsregeln
+* **BR-06-001**: Theme-Ermittlung folgt der Priorität: 1. localStorage, 2. `prefers-color-scheme`, 3. Light als Default.
+* **BR-06-002**: Theme-Wechsel erfolgt ohne Seiten-Reload und ohne visuelles Flackern.
+
 === Fehlerszenarien
 * **F1**: localStorage nicht verfügbar → Theme nur für Session, reagiert auf prefers-color-scheme
 * **F2**: Theme-CSS nicht geladen → Fallback auf System-Theme
@@ -362,6 +384,11 @@ stop
 * Automatisches Feedback ist gepostet (bei Validation)
 * Bei Approval: PR ist erstellt mit generiertem Content
 
+=== Geschäftsregeln
+* **BR-07-001**: Jeder vorgeschlagene Anker muss die vier Qualitätskriterien erfüllen: Precise, Rich, Consistent, Attributable.
+* **BR-07-002**: Vorschläge, die reine Instruktionen ohne konzeptuelle Tiefe sind (z.B. "TLDR", "ELI5"), werden abgelehnt.
+* **BR-07-003**: Duplikate bestehender Anker werden abgelehnt mit Verweis auf den existierenden Eintrag.
+
 === Fehlerszenarien
 * **F1**: GitHub Actions Workflow schlägt fehl → Issue bleibt ohne Auto-Comment, manueller Review nötig
 * **F2**: Copilot API nicht verfügbar → Maintainer erstellt Entry manuell
@@ -420,6 +447,10 @@ stop
 * Issue hat passendes Label
 * Contributor hat klares Feedback
 
+=== Geschäftsregeln
+* **BR-08-001**: Validierungs-Score basiert auf einer 10-Punkt-Skala. Score > 7 gilt als "validated".
+* **BR-08-002**: Die vier Bewertungskriterien sind: Precise, Rich, Consistent, Attributable — gleichgewichtet.
+
 === Fehlerszenarien
 * **F1**: Copilot API Timeout → Workflow posted "Validation failed, manual review required"
 * **F2**: Issue-Body unlesbar → Workflow posted "Cannot parse issue, please use template"
@@ -519,6 +550,11 @@ stop
 * URL ist share-bar (kopierbar)
 * State (Filter, Language) ist in URL kodiert
 
+=== Geschäftsregeln
+* **BR-10-001**: Gültige Deep-Link-Formate: `#/anchor/<anchor-id>` (Hash-basiert).
+* **BR-10-002**: Anker-IDs sind case-sensitive und müssen exakt mit der ID in der Anchor-Datei übereinstimmen.
+* **BR-10-003**: Filter- und Sprachparameter aus der URL werden beim Laden angewendet.
+
 === Fehlerszenarien
 * **F1**: Anker-ID ungültig → 404 Seite mit Suchfunktion
 * **F2**: Alter Link (nach Rename) → System zeigt Redirect-Hinweis oder 301 Redirect

website/public/data/contracts.json

@@ -6,8 +6,8 @@
     "description": "What we mean when we say 'spec'",
     "descriptionDe": "Was wir meinen, wenn wir 'Spec' sagen",
     "anchors": ["gherkin", "bdd-given-when-then"],
-    "template": "When we talk about a \"specification\" or \"spec\", we mean:\n- Use Cases with Trigger, Main Flow, Alternative Flows, and Postconditions\n- Activity Diagrams for all flows (not just the happy path)\n- Acceptance criteria in Gherkin format (Given/When/Then)",
-    "templateDe": "Wenn wir von einer \"Spezifikation\" oder \"Spec\" sprechen, meinen wir:\n- Use Cases mit Trigger, Hauptablauf, Alternativabläufe und Nachbedingungen\n- Activity Diagrams für alle Abläufe (nicht nur der Happy Path)\n- Akzeptanzkriterien im Gherkin-Format (Given/When/Then)",
+    "template": "When we talk about a \"specification\" or \"spec\", we mean:\n- Use Cases with Trigger, Main Flow, Alternative Flows, Postconditions, and Business Rules (BR-IDs)\n- Activity Diagrams for all flows (not just the happy path)\n- Acceptance criteria in Gherkin format (Given/When/Then)",
+    "templateDe": "Wenn wir von einer \"Spezifikation\" oder \"Spec\" sprechen, meinen wir:\n- Use Cases mit Trigger, Hauptablauf, Alternativabläufe, Nachbedingungen und Geschäftsregeln (BR-IDs)\n- Activity Diagrams für alle Abläufe (nicht nur der Happy Path)\n- Akzeptanzkriterien im Gherkin-Format (Given/When/Then)",
     "category": "requirements"
   },
   {