Thema: Anwendungsteil 1. Spezifikationen aus Legacy wiederherstellen
Schwierigkeitsgrad: Mittelstufe
Geschätzte Studienzeit: 6-8 Stunden (Theorie + Praxis)
Voraussetzungen: Vertrautheit mit dem ersten Band des Kurses, Teil 13 (Wiederherstellung der Verfassung eines bestehenden Projekts)
Grundlegendes Verständnis von Kubernetes, Grafana, PagerDuty
Erfahrung mit Markdown und JSON
Verständnis der Struktur eines Git-Repositorys
Vertrautheit mit dem Given/When/Then-Format für Benutzergeschichten
Lernziele: Anforderungen (SDD-Vertrag) und Hintergrundkontext (Memory Bank) unterscheiden und dabei bei der Inventarisierung von Artefakten eine strenge Trennung anwenden
genealogy.md mit mindestens zwei evidence_ref, einem Vertrauensniveau und einer offenen Frage für eine Production-Anforderung erstellen
Wiederhergestellte Aussagen in das Given/When/Then-Format überführen und die entsprechenden JSON-Schema-Felder definieren
Qwen Code im Extraktionsmodus (nicht Generierung) nutzen, um Claims mit obligatorischen Quellen und Gegenbeispielen zu erhalten
Die Bereitschaft einer Anforderung zur Bestätigung durch Prüfung der Absicherung von Schwellenwerten und SLAs mit Quellenverweisen bewerten
Überblick: Dieses Kapitel widmet sich der Wiederherstellung ingenieurmäßig brauchbarer Spezifikationen aus dem Chaos von Legacy-Artefakten: unstrukturierten Logs, Slack-Threads, Dashboard-Screenshots und Post-Mortems ohne formale SDD. Nach dem Abgang des SRE-Teams in einem Projekt zur automatischen Vorfallsteuerung verbleiben Fragmente, aus denen überprüfbare Anforderungen extrahiert werden müssen, nicht aber eine Sammlung plausibler Vermutungen. Der didaktische Fokus ist eng: ein Claim, zwei Quellen, eine offene Frage. Der vollständige Production-Track (Normalisierer, historischer Replay, Datei-Schiedsgericht) wird bis Teil 8 zurückgestellt. Das Hauptergebnis ist ein ausgefülltes genealogy.md, das bestätigte Anforderungen von Hypothesen und Hintergrundkontext trennt.
Schlüsselkonzepte: Genealogy.md: Register der Herkunft einer Anforderung, das eine Aussage mit Quellen (Logs, Slack, Metriken, Post-Mortems), dem Vertrauensniveau (uncertainty) und offenen Fragen verknüpft. Im Gegensatz zu git log, das zeigt wer und wann eine Datei geändert hat, zeigt genealogy.md woher die Anforderung selbst stammt und wie sicher man sich ihrer ist. Obligatorische Felder: claim, evidence_ref (mindestens zwei), status (approved/needs_clarity/rejected), uncertainty, open_questions.
Memory bank: Separate Ebene des infrastrukturellen Kontexts: alles, das bei der Interpretation von Fakten hilft, aber selbst kein Vertrag ist. Clustertopologie, Teamliste, historische Vereinbarungen, API-Einschränkungen, gewohnte Kommunikationskanäle, operationale Lexik. Die Vermischung von Memory Bank mit Anforderungen ist gefährlich: in der SDD erscheinen falsche Regeln wie „canary immer nicht-eskalierend“, die in Wahrheit nur Kontext des Test-Namespace sind.
Evidence ref: Nachweis-Markierung — Verweis auf eine konkrete Stelle im Ursprungsartefakt. Format: source:path#location. Beispiele: grafana:NR-2026-05-17-01, postmortem:node-not-ready-2026-05, slack/thread_11#msg_7. Ohne evidence_ref bleibt die Aussage eine Meinung des Autors, keine überprüfbare Anforderung.
Claim (Kandidatenaussage): Wiederhergestellte Regel, noch nicht im Vertrag bestätigt. Ein guter Claim enthält: konkreten Schwellenwert (>=3 NodeNotReady), Zeitfenster (innerhalb 10 Minuten), Bedingung (für einen Node), Korrelation (mit Anstieg von 5xx), evidence_ref, Gegenbeispiel (counterexample), fehlenden Kontext (missing_context), Vertrauensniveau (confidence).
Given/When/Then: Format der Verhaltensbeschreibung einer Anforderung. Given — Ausgangszustand des Systems. When — Auslöseereignis. Then — erwartetes Ergebnis mit konkreten Zahlen, Status und SLAs. Beispiel: Given Cluster in aktiver Schicht und >=3 NodeNotReady innerhalb 10m; When Ereignis korreliert mit Deployment; Then wird P1 erstellt, Erstreaktion innerhalb 8 Minuten, Eskalation in NOC innerhalb 15 Minuten, Schließung nach 2 aufeinanderfolgenden OK innerhalb 10 Minuten.
JSON-Schema-Vertrag: Maschinenlesbare Darstellung einer Anforderung mit obligatorischen Feldern, zulässigen Werten (enum), numerischen Grenzen (minimum/maximum). Die doppelte Dokumentation (Given/When/Then + JSON Schema) beseitigt die Lücke zwischen „für Menschen verständlich“ und „maschinell überprüfbar“. Überprüfbare Felder: rule_id, severity (enum P0-P3), sla_minutes, conditions (event_code, count, window_minutes, namespace_rule).
Normalisierung der Zeitachse: Angleichung der Quellen an eine gemeinsame Zeit (UTC), Entfernung von Duplikaten, Extraktion von Ereigniscodes, Verknüpfung von Einträgen durch eine einheitliche Vorfallkennung. Gerüst: ts → source → event_code → actor → affected_scope → evidence_ref. Ohne Normalisierung wird die Wiederherstellung zu einem Streit über Erinnerungen, nicht zu einer Rekonstruktion des Systemverhaltens.
Datei-Schiedsgericht (vollständiger Track): Prozess der Prüfung strittiger Anforderungen durch drei Rollen: Verifikator (Widerspruchsfreiheit von Zahlen und Status), Implementor (Umsetzbarkeit in aktueller Pipeline), Safety (Grenzen sicheren Handelns, Vetorecht bei critical_risk). Der Koordinator führt Protokoll, stimmt nicht ab. Detailliert in Teil 8. Für das didaktische Minimum — referenziell.
Qwen Code als Extraktor: Das Modell arbeitet nicht als Autor der Geschäftslogik, sondern als Vermittler zur Extraktion von Claims aus normalisierten Daten. Ein guter Prompt fordert: wiederkehrende Regeln, bestätigende Quellen, Gegenbeispiele, Vertrauensniveau. Aussagen ohne Nachweisverweis sind verboten. Modus: kopfloser Plan Mode (--approval-mode plan).
Uncertainty (Vertrauensniveau): low — Aussage durch unabhängige Quellen bestätigt, Replay oder Schiedsgericht bestanden. medium — Widersprüche vorhanden, fehlender Kontext, eine Quelle. high — Annahme auf Basis indirekter Daten. Strittige Fakten werden nicht als approved maskiert: es wird needs_clarity mit Prüfplan vergeben.
Praxisübungen: Titel: Erstellung von genealogy.md für node_not_ready
Problem: Erstellen Sie unter Verwendung der didaktischen Auszüge aus dem Kursmaterial eine Datei genealogy.md mit einem Eintrag für den Vorfall node_not_ready. Gegeben: Grafana-Log mit drei NodeNotReady-Ereignissen innerhalb 10 Minuten, PagerDuty-Eintrag über P1-Eskalation, Post-Mortem mit Ablehnung von Auto-Resolve bis zu zwei stabilen Fenstern, und offene Frage zum Canary-Namespace. Aufgabe: Claim formulieren, zwei evidence_ref hinzufügen, uncertainty und open_questions angeben, Memory Bank abtrennen.
Lösung: 1. Kopieren Sie die Vorlage book2/examples/templates/genealogy.md in das Arbeitsverzeichnis. 2. Notieren Sie den Claim: 'Bei >=3 NodeNotReady innerhalb 10m für einen Node wird P1 erstellt, Schließung erfordert 2 aufeinanderfolgende OK innerhalb 10m'. 3. Fügen Sie evidence_ref hinzu: ['grafana:NR-2026-05-17-01', 'postmortem:node-not-ready-2026-05']. 4. Geben Sie uncertainty an: medium (wegen offener Frage zum Canary). 5. Fügen Sie open_questions hinzu: ['Schließt Canary-Namespace P1 aus oder senkt er nur die Zuversicht?']. 6. In die Memory Bank übertragen: cluster=prod-k8s, node=worker-07, owner=platform_oncall (Kontext, kein Vertrag). 7. Setzen Sie status: needs_clarity. 8. Prüfen Sie: die Aussage darf nicht als 'Meinung des Autors' lesbar sein — der Schwellenwert ist durch Grafana-Verweis abgesichert, die Schließungsbedingung durch Post-Mortem.
Schwierigkeit: Anfänger
Titel: Überführung eines Claims in Given/When/Then und JSON Schema
Problem: Nehmen Sie die Aussage aus der vorherigen Übung und dokumentieren Sie sie doppelt: Verhaltensgeschichte (Given/When/Then) und minimales JSON Schema. Bestimmen Sie, welche drei Schema-Felder den Schwellenwert, die Severity und die Schließungsbedingung prüfen. Die Canary-Ausnahme dokumentieren Sie als separates Bedingung namespace_rule.
Lösung: Given/When/Then: Given Cluster in aktiver Schicht und innerhalb 10 Minuten werden >=3 NodeNotReady für einen Node festgestellt; When Ereignis nicht im Canary-Namespace oder im Canary mit korreliertem Anstieg von 5xx; Then wird Vorfall severity=P1 erstellt, Erstreaktion innerhalb 8 Minuten, Eskalation in NOC innerhalb 15 Minuten, Schließung nach 2 aufeinanderfolgenden OK innerhalb 10 Minuten. JSON Schema: { '$id': 'urn:spec:node-not-ready:v1', 'type': 'object', 'required': ['rule_id','severity','sla_minutes','conditions'], 'properties': { 'rule_id': {'type':'string'}, 'severity': {'type':'string','enum':['P0','P1','P2','P3']}, 'sla_minutes': {'type':'integer','minimum':1,'maximum':120}, 'conditions': {'type':'object','required':['event_code','count','window_minutes','namespace_rule'], 'properties': {'count':{'type':'integer','minimum':3}, 'window_minutes':{'type':'integer','minimum':1}, 'namespace_rule':{'type':'string','enum':['standard','canary']}}}}} Drei prüfbare Felder: count (Schwellenwert >=3), severity (enum P1), conditions mit window_minutes und namespace_rule (Schließungsbedingung durch aufeinanderfolgende OK — im vollständigen Track über auto_resolve_window mit regulärem Ausdruck).
Schwierigkeit: Mittelstufe
Titel: Trennung von Anforderungen und Memory Bank in einem realen Fragment
Problem: Gegeben ist ein Fragment aus Slack-Thread und Post-Mortem: 'Der Diensthabende Wassja bemerkte um 3 Uhr nachts, dass worker-07 in prod-k8s erneut NotReady war, schrieb in Kanal #sre-alerts, rief nach 15 Minuten Nastja aus dem NOC, sie beschlossen nicht automatisch zu schließen, weil beim letzten Mal Auto-Resolve zu einem wiederholten Vorfall führte. Es stellte sich heraus, dass um 2:47 ein planmäßiges Deployment in Canary stattfand. Der alte Service hieß node-health-check, jetzt ist es k8s-node-monitor'. Trennen Sie in Anforderungen (SDD) und Memory Bank. Erklären Sie, warum jedes Element seiner Ebene zugeordnet ist.
Lösung: SDD-Anforderungen: '>=3 NodeNotReady innerhalb 10m → P1' (wiederhergestellt aus wiederkehrendem Muster), 'Schließung erfordert 2 aufeinanderfolgende OK innerhalb 10m' (Post-Mortem: Auto-Resolve abgelehnt), 'Eskalation in NOC innerhalb 15 Minuten' (zeitliche Ereigniskette). Memory Bank: 'Diensthabender Wassja' (wer Dienst hatte — Kontext, kein Vertrag), 'Kanal #sre-alerts' (gewohnter Kommunikationskanal), 'worker-07 in prod-k8s' (konkrete Topologie, änderlich), 'alter Name node-health-check' (historische Lexik), 'planmäßiges Deployment in Canary um 2:47' (Kontext zur Interpretation, aber an sich keine Regel — es sei denn als Bedingung namespace_rule formuliert). Begründung: Personen- und Knotennamen ändern sich, Kommunikationskanäle sind operationale Gewohnheit, Schwellenwerte und SLAs sind überprüfbares Systemverhalten.
Schwierigkeit: Mittelstufe
Titel: Bewertung der Bereitschaft eines Claims zur Bestätigung
Problem: Gegeben sind drei Claims für high_memory_usage. A: 'Bei memory_percent >= 90% innerhalb 10m für appointments-api wird P1 erstellt' — zwei evidence_ref (grafana, post-mortem), aber Verbot von Auto-Resolve ohne zwei stabile Fenster nicht bestätigt. B: 'Bei memory_percent >= 85% innerhalb 5m wird P0 erstellt' — ein evidence_ref (Slack), kein Post-Mortem, widerspricht benachbartem Cluster. C: 'Bei memory_percent >= 90% innerhalb 10m wird P1 erstellt, Auto-Resolve verboten ohne zwei stabile Fenster à 5m' — drei evidence_ref, Replay auf historischen Daten bestanden, aber Service-Besitzer hat gekündigt. Bestimmen Sie status und uncertainty für jeden, begründen Sie.
Lösung: A: status needs_clarity, uncertainty medium. Schwellenwert und Severity durch zwei Quellen abgesichert, aber Schließungsbedingung — offene Frage. Teilweise bestätigte Anforderung darf nicht in approved überführt werden. Plan: Service-Besitzer anfragen oder zusätzliches Post-Mortem finden. B: status rejected (oder bleibt Hypothese), uncertainty high. Eine Quelle, Widerspruch mit benachbartem Cluster, Schwellenwert 85% nicht abgesichert — ähnelt einer Vermutung aus Chat. Ohne Überprüfung nicht annehmbar. C: status approved oder needs_clarity je nach Verfahren. Technisch geben drei Quellen und Replay low uncertainty, aber fehlender Service-Besitzer — Risiko für zukünftige Überarbeitung. Entscheidung: approved mit Anmerkung 'letzte Bestätigung durch gekündigten Besitzer, re-validation bei Architekturänderung erforderlich' oder needs_clarity bis Neubesetzung des Besitzers. Lehre: selbst starkes Beweismaterial erfordert einen lebendigen Überarbeitungsmechanismus.
Schwierigkeit: Fortgeschritten
Fallstudien: Titel: Wiederherstellung der SLA-Eskalation nach Abgang des SRE-Teams in AgentClinic-production
Szenario: Das didaktische Modell AgentClinic-production ist in Kubernetes deployed. Nach dem Abgang des SRE-Teams verbleiben Fragmente: 47 Seiten unstrukturierter Logs, 11 relevante Slack-Nachrichten, Grafana-Dashboard-Screenshots, Post-Mortems ohne formale SDD. Der Triage-Kontour empfängt Webhooks von Grafana und PagerDuty. Eine Anforderung muss wiederhergestellt werden: wann wird NodeNotReady zu P1 und wann darf es nicht automatisch geschlossen werden.
Herausforderung: 1. Zersplitterte Quellen ohne einheitliches Format: Metrik-Logs, Eskalationen in PagerDuty, informelle Post-Mortems. 2. Risiko der Vermischung von operationalem Kontext (Diensthabendennamen, Clustertopologie, alte Servicenamen) mit Geschäftsregeln. 3. Implizite Regel zum Canary-Namespace: schließt er P1 aus oder senkt er nur die Zuversicht? 4. Fehlende formale SDD — Alternative 'Sammlung plausibler Vermutungen' ist inakzeptabel. 5. Notwendigkeit der Überprüfbarkeit: wiederhergestellte Spezifikation muss ausführbares Artefakt werden.
Lösung: 1. Strenger Filter 'Anforderung vs Memory Bank' bereits bei Inventarisierung angewendet. Diensthabendennamen, Slack-Kanäle, Topologie worker-07 — in Memory Bank überführt. 2. Normalisierte Zeitkette erstellt: 1248 NodeNotReady-Ereignisse → Gruppierung nach 10-Minuten-Fenstern → 63 Alerts → Extraktion von 8 zuvor geschlossenen Vorfällen. 3. Übereinstimmung von steilem Anstieg NodeNotReady mit Deployment festgestellt, und zwei Verhaltenszweige: Standard-P1 und Canary-Pfad mit abgeschwächten Schwellenwerten. 4. Claim mit zwei evidence_ref formuliert: grafana:NR-2026-05-17-01 und postmortem:node-not-ready-2026-05. 5. Offene Frage zum Canary dokumentiert, nicht als bestätigte Regel maskiert. 6. Doppelte Dokumentation: Given/When/Then + JSON Schema mit Feldern severity, sla_minutes, conditions. 7. Für das didaktische Minimum — genealogy.md ohne vollständiges Schiedsgericht; für Production-Track Übergang zum Datei-Schiedsgericht in Teil 8 vorgesehen.
Ergebnis: Überprüfbare Anforderung wiederhergestellt: '>=3 NodeNotReady innerhalb 10 Minuten für einen Node erstellt P1, Erstreaktion 8 Minuten, Eskalation in NOC innerhalb 15 Minuten, Schließung nach 2 aufeinanderfolgenden OK innerhalb 10 Minuten'. Bedingung für Canary-Namespace als separates Regel namespace_rule herausgestellt, nicht als Fußnote. genealogy.md ermöglicht Audit der Herkunft jedes Punkts. Spezifikation bereit zur Validierung in CI und Replay auf historischen Daten.
Gelernte Lektionen: Nachweis wichtiger als selbstbewusste Formulierung: schöne Regel ohne evidence_ref — immer noch Hypothese
Trennung von Anforderungen und Memory Bank muss bei Inventarisierung erfolgen, nicht am Ende — sonst dringen falsche Regeln in den Vertrag ein
Ausnahmen (Canary, planmäßiges Deployment) — kein Rauschen, sondern Hinweise auf verborgene Bedingungen der Spezifikation; sie dürfen nicht entfernt werden
Offene Fragen müssen explizit markiert sein, nicht als approved maskiert — dies schützt vor Annahme unbegründeter Entscheidungen
Doppelte Dokumentation Given/When/Then + JSON Schema beseitigt die Lücke zwischen menschenlesbarer Beschreibung und maschineller Überprüfbarkeit
Selbst starkes Beweismaterial erfordert einen lebendigen Überarbeitungsmechanismus bei Team- oder Architekturwechsel
Verwandte Konzepte: genealogy.md
memory bank
evidence_ref
Given/When/Then
JSON-Schema-Vertrag
Normalisierung der Zeitachse
uncertainty
Titel: Fehler der Vermischung von Memory Bank und Anforderungen im Monitoring-Migrationsprojekt
Szenario: Das Plattform-Team migrierte von Eigenentwicklung-Monitoring auf Prometheus+Grafana. Bei der Wiederherstellung von Alerting-Spezifikationen nahmen Ingenieure in die SDD den Satz auf: 'Alerts severity=P1 werden in Kanal #critical-alerts gesendet, erwähnen den OnCall aus Team platform'.
Herausforderung: Nach 6 Monaten wurde Team platform in platform-infra umbenannt, der Kanal wechselte den Namen, und die Diensthabendenrotation ging zu PagerDuty über. Die SDD musste umgeschrieben werden, obwohl sich die Geschäftslogik (wann P1 erstellt wird) nicht geändert hatte. Problem: operationeller Kontext wurde als vertragliche Anforderung kodiert.
Lösung: Retrospektive Analyse zeigte, dass die korrekte Trennung ist: Anforderung — 'Bei >=3 NodeNotReady innerhalb 10m wird P1 erstellt, Eskalation erfolgt innerhalb 15 Minuten gemäß SLA'. Memory Bank — 'Kanal #critical-alerts, Team platform, aktueller OnCall Wassja'. Umgeschriebene SDD mit genealogy.md trennt beständiges Verhalten von änderbarem Kontext. JSON Schema enthält severity und sla_minutes, aber nicht channel_name oder team_name.
Ergebnis: Neue Struktur überdauerte drei Kommunikationsreorganisationen ohne Vertragsänderung. Memory-Bank-Aktualisierung — Operation von Minuten, ohne Schiedsgericht. Lehre bestätigt: Filter 'Vertrag vs Kontext' kritisch für langlebige Spezifikationen.
Gelernte Lektionen: Teamnamen, Kanäle, Personennamen — Memory Bank, unabhängig davon wie 'offensichtlich' sie beim Schreiben erscheinen
Wenn beim Lesen der SDD die Frage 'was wenn sich das Team umbenennt?' aufkommt — das ist Signal für Vermischung der Ebenen
JSON Schema als Audit-Instrument: wenn Feld kein enum oder numerische Grenzen hat, gehört es möglicherweise zur Memory Bank
Verwandte Konzepte: memory bank
Filter Vertrag vs Kontext
JSON-Schema-Vertrag
genealogy.md
Studientipps: Beginnen Sie mit dem minimalen didaktischen Szenario: ein Claim, zwei Quellen, eine offene Frage. Versuchen Sie nicht sofort alle 47 Logseiten abzudecken — das ist der vollständige Production-Track
Üben Sie mit dem didaktischen Auszug von 4 Zeilen, bevor Sie auf reale Materialien anwenden. Struktur wichtiger als Umfang
Für visuellen Stil: zeichnen Sie auf Papier zwei Spalten — links 'Anforderung (überprüfbar)', rechts 'Memory Bank (Kontext)'. Gehen Sie jedes Fragment des Ursprungsartefakts durch und entscheiden Sie, in welche Spalte es fällt
Für auditiven Stil: sprechen Sie Claims laut mit der Frage 'was sollte sich im System ändern?' Wenn die Antwort — 'nichts, das ist nur Information' — dann ist es Memory Bank
Für kinästhetischen Stil: verschieben Sie physisch Karten mit Fragmenten zwischen zwei Stapeln 'SDD' und 'Memory Bank' und diskutieren Sie jeden Verschiebungsschritt
Prüfen Sie jeden Claim mit dem Test 'kann ich dafür einen automatischen Test schreiben?' Wenn nein — möglicherweise keine Anforderung, oder die Anforderung ist nicht konkret genug
Nutzen Sie genealogy.md als 'Verdachts-Checkliste': wenn Eintrag nicht zwei evidence_ref hat — automatisch Hypothese, unabhängig davon wie sicher der Autor ist
Üben Sie mit Qwen Code auf didaktischen Daten im Plan Mode, validieren Sie aber immer den Ausgabe-JSON separat mit einem Parser — das Modell generiert Sitzungsbericht, kein strenges claims.json
Erstellen Sie 'Gegenbeispiele' als obligatorisches Feld: gute Übung — finden Sie in den Ursprungsdaten einen Fall, der Ihrem Claim widerspricht, und erklären Sie warum (Ausnahme? Datenfehler? falsche Hypothese?)
Reviewen Sie genealogy.md nach 24 Stunden mit 'fremden Augen': können Sie, ohne Kontext zu erinnern, verstehen warum der Schwellenwert genau 3 und nicht 2 oder 4 ist?
Zusätzliche Ressourcen: Vorlage genealogy.md: book2/examples/templates/genealogy.md — Startvorlage für Provenienz
Didaktisches Projekt des ersten Bands: AgentClinic mit TypeScript, Hono, serverseitigem JSX, SQLite, Vitest — Bezugspunkt für Verständnis der Memory Bank aus tech-stack.md und QWEN.md
Github spec kit: https://github.com/github/spec-kit — Rahmen 'Spezifikation als ausführbares Artefakt'
Teil 13 des ersten Bands: Wiederherstellung der Verfassung eines bestehenden Projekts — Vorabstütze
Teil 8 des zweiten Bands: part-08-multiagent-tribunal.md — Datei-Schiedsgericht, Details der Rollen Verifier/Implementor/Safety
Tribunal-Beispiele: examples/tribunal/ — ausführbares didaktisches Analogon
Anhang a: appendix-a-bridges-to-book.md — Verbindungen zum ersten Band
Repository des Lehrbuchs: book2/examples/ — ausführbare Skripte in Python stdlib
Zusammenfassung: Die Wiederherstellung von Spezifikationen aus Legacy ist ein ingenieurtechnisches Verfahren zur Umwandlung von Artefaktchaos (Logs, Chats, Post-Mortems) in einen überprüfbaren Vertrag. Schlüsselprinzipien: strenge Trennung von Anforderungen und Memory Bank, Normalisierung der Zeitachse, Extraktion (nicht Generierung) von Claims durch Qwen Code mit obligatorischen evidence_ref, doppelte Dokumentation Given/When/Then + JSON Schema, explizite Markierung von uncertainty und open_questions. Didaktisches Minimum — ein ausgefülltes genealogy.md mit abgesicherter Aussage, zwei Quellen und offener Frage. Vollständiger Production-Track ergänzt Normalisierer, historischen Replay und Datei-Schiedsgericht (Teil 8). Hauptergebnis: die Spezifikation wird zu einer Nachweiskette, die validierbar, anfechtbar, auf historischen Daten wiederholbar und monatelang auditierbar ist.