Merge pull request #489 from raifdmueller/feat/contracts-vertical-slicing-refactoring

feat(contracts): add Vertical Slicing and Refactoring, extend Requirements Discovery

Author: rdmueller

website/public/data/contracts.json

@@ -16,9 +16,9 @@
     "titleDe": "Anforderungsermittlung",
     "description": "How we clarify requirements before writing specs",
     "descriptionDe": "Wie wir Anforderungen klären, bevor wir Specs schreiben",
-    "anchors": ["socratic-method", "mece", "prd"],
-    "template": "Clarify requirements using the Socratic Method:\n- Ask at most 3 questions at a time, challenge assumptions\n- Use MECE to ensure questions cover all areas without overlap\n- Keep asking until you fully understand the requirements\n- Document as a PRD (problem, goals, personas, success criteria, scope)",
-    "templateDe": "Anforderungen mit der Sokratischen Methode klären:\n- Höchstens 3 Fragen gleichzeitig, Annahmen hinterfragen\n- MECE nutzen, um alle Bereiche überlappungsfrei abzudecken\n- Weiterfragen bis die Anforderungen vollständig verstanden sind\n- Als PRD dokumentieren (Problem, Ziele, Personas, Erfolgskriterien, Scope)",
+    "anchors": ["socratic-method", "mece", "prd", "impact-mapping", "user-story-mapping"],
+    "template": "Clarify requirements using the Socratic Method:\n- Ask at most 3 questions at a time, challenge assumptions\n- Use MECE to ensure questions cover all areas without overlap\n- Keep asking until you fully understand the requirements\n\nFrame the scope before writing it down:\n- Impact Mapping connects deliverables to business goals and actors — so you build what moves a goal, not just what was asked.\n- User Story Mapping lays stories along the user's journey and exposes a coherent first slice.\n\nDocument the result as a PRD (problem, goals, personas, success criteria, scope).",
+    "templateDe": "Anforderungen mit der Sokratischen Methode klären:\n- Höchstens 3 Fragen gleichzeitig, Annahmen hinterfragen\n- MECE nutzen, um alle Bereiche überlappungsfrei abzudecken\n- Weiterfragen bis die Anforderungen vollständig verstanden sind\n\nDen Scope rahmen, bevor er aufgeschrieben wird:\n- Impact Mapping verbindet Lieferobjekte mit Geschäftszielen und Akteuren — damit man baut, was ein Ziel bewegt, nicht nur was gefragt wurde.\n- User Story Mapping ordnet Stories entlang der Nutzerreise an und legt eine sinnvolle erste Scheibe offen.\n\nDas Ergebnis als PRD dokumentieren (Problem, Ziele, Personas, Erfolgskriterien, Scope).",
     "category": "requirements"
   },
   {
@@ -71,6 +71,17 @@
     "templateDe": "EPICs und User Stories als GitHub Issues aus der Spezifikation erstellen.\n- User Stories folgen den INVEST-Kriterien (Independent, Negotiable, Valuable, Estimable, Small, Testable)\n- Priorisierung mit MoSCoW (Must/Should/Could/Won't)\n- Abhängigkeiten zwischen Issues markieren\n- Backlog regelmäßig groomen",
     "category": "development"
   },
+  {
+    "id": "vertical-slicing",
+    "title": "Vertical Slicing",
+    "titleDe": "Vertikale Schnitte",
+    "description": "How we build the first increment and grow the system in thin end-to-end slices",
+    "descriptionDe": "Wie wir das erste Inkrement bauen und das System in dünnen End-to-End-Scheiben wachsen lassen",
+    "anchors": ["walking-skeleton", "tracer-bullet", "thin-vertical-slice", "spike-solution"],
+    "template": "Build the first increment as a walking skeleton: a deployable end-to-end slice that wires every architectural layer together and does almost nothing else.\n\nGrow the system as thin vertical slices — each slice cuts through all layers and delivers one small piece of user value. Slices are tracer bullets: kept and refined, never thrown away.\n\nWhen a technical unknown blocks a slice, run a spike solution first — a timeboxed, throwaway experiment that removes the risk. Spike code is discarded; only its lesson carries into the slice.",
+    "templateDe": "Das erste Inkrement als Walking Skeleton bauen: eine deploybare End-to-End-Scheibe, die alle Architekturschichten verbindet und sonst fast nichts tut.\n\nDas System in dünnen vertikalen Scheiben wachsen lassen — jede Scheibe geht durch alle Schichten und liefert ein kleines Stück Nutzerwert. Scheiben sind Tracer Bullets: behalten und verfeinert, nie weggeworfen.\n\nWenn ein technisches Unbekanntes eine Scheibe blockiert, zuerst eine Spike Solution durchführen — ein zeitlich begrenztes Wegwerf-Experiment, das das Risiko beseitigt. Spike-Code wird verworfen; nur seine Erkenntnis fließt in die Scheibe ein.",
+    "category": "development"
+  },
   {
     "id": "implement-next",
     "title": "Implement Next",
@@ -87,6 +98,17 @@
     "templateDe": "Für jedes Issue:\n- Feature-Branch für das EPIC erstellen\n- Nächstes Issue aus dem Backlog wählen (Abhängigkeiten beachten)\n- Analysieren und Analyse als Kommentar am Issue dokumentieren\n- Mit TDD implementieren (London oder Chicago School je nach Kontext)\n- Jeder Test referenziert seine Use-Case-ID für Rückverfolgbarkeit\n- Mit Conventional Commits committen, Issue-Nummer referenzieren\n- Prüfen ob Spec oder Architektur-Docs aktualisiert werden müssen\n- Wenn EPIC fertig, Pull Request erstellen",
     "category": "development"
   },
+  {
+    "id": "refactoring",
+    "title": "Refactoring",
+    "titleDe": "Refactoring",
+    "description": "How we identify and execute refactorings safely",
+    "descriptionDe": "Wie wir Refactorings sicher identifizieren und durchführen",
+    "anchors": ["code-smells", "mikado-method"],
+    "template": "Refactoring targets are named code smells, not a vague urge to \"clean up\".\n\nFor any refactoring that does not complete in one step, use the Mikado Method: attempt the change, note what breaks, revert, and do the prerequisites first — never leave the build broken while you dig.\n\nRefactoring commits change structure only. Behaviour changes go in separate commits, and the test suite stays green at every commit.",
+    "templateDe": "Refactoring-Ziele sind benannte Code Smells, kein vager Drang \"aufzuräumen\".\n\nFür jedes Refactoring, das nicht in einem Schritt fertig wird, die Mikado-Methode nutzen: die Änderung versuchen, notieren was bricht, zurücksetzen und zuerst die Voraussetzungen erledigen — den Build nie kaputt lassen, während man gräbt.\n\nRefactoring-Commits ändern nur Struktur. Verhaltensänderungen kommen in separate Commits, und die Testsuite bleibt bei jedem Commit grün.",
+    "category": "development"
+  },
   {
     "id": "code-quality",
     "title": "Code Quality",

website/public/llms.txt

@@ -5651,9 +5651,14 @@ Clarify requirements using the Socratic Method:
 - Ask at most 3 questions at a time, challenge assumptions
 - Use MECE to ensure questions cover all areas without overlap
 - Keep asking until you fully understand the requirements
-- Document as a PRD (problem, goals, personas, success criteria, scope)
 
-*Referenced anchors: socratic-method, mece, prd*
+Frame the scope before writing it down:
+- Impact Mapping connects deliverables to business goals and actors — so you build what moves a goal, not just what was asked.
+- User Story Mapping lays stories along the user's journey and exposes a coherent first slice.
+
+Document the result as a PRD (problem, goals, personas, success criteria, scope).
+
+*Referenced anchors: socratic-method, mece, prd, impact-mapping, user-story-mapping*
 
 ## Architecture Documentation
 
@@ -5699,6 +5704,16 @@ Create EPICs and User Stories as GitHub issues from the specification.
 
 *Referenced anchors: invest, moscow*
 
+## Vertical Slicing
+
+Build the first increment as a walking skeleton: a deployable end-to-end slice that wires every architectural layer together and does almost nothing else.
+
+Grow the system as thin vertical slices — each slice cuts through all layers and delivers one small piece of user value. Slices are tracer bullets: kept and refined, never thrown away.
+
+When a technical unknown blocks a slice, run a spike solution first — a timeboxed, throwaway experiment that removes the risk. Spike code is discarded; only its lesson carries into the slice.
+
+*Referenced anchors: walking-skeleton, tracer-bullet, thin-vertical-slice, spike-solution*
+
 ## Implement Next
 
 For each issue:
@@ -5713,6 +5728,16 @@ For each issue:
 
 *Referenced anchors: tdd-london-school, tdd-chicago-school, definition-of-done, conventional-commits*
 
+## Refactoring
+
+Refactoring targets are named code smells, not a vague urge to "clean up".
+
+For any refactoring that does not complete in one step, use the Mikado Method: attempt the change, note what breaks, revert, and do the prerequisites first — never leave the build broken while you dig.
+
+Refactoring commits change structure only. Behaviour changes go in separate commits, and the test suite stays green at every commit.
+
+*Referenced anchors: code-smells, mikado-method*
+
 ## Code Quality
 
 Our code follows: