Anwendungsteil 1. Wiederherstellung von Spezifikationen aus Legacy

Status: Empfehlung. Die Sammlung von Beweisen, die Normalisierung der Zeitleiste und die Trennung von Anforderungen und memory bank — etablierte ingenieurtechnische Verfahren. Die dreiseitige Datei-Schiedsgerichtsbarkeit am Ende des Kapitels — Grenzbereich.

Für das schulische Durchlaufen reicht es, ein einziges genealogy.md zu erstellen und die genehmigte Anforderung von der Hypothese abzugrenzen. Datei-Schiedsgerichtsbarkeit, Normalisierer und Replay historischer Daten sind nur für den vollständigen Production-Track erforderlich.

Dieses Kapitel knüpft an Teil 13 des ersten Bandes an: dort haben wir die Konstitution eines bestehenden Projekts wiederhergestellt, hier stellen wir eine einzelne Production-Anforderung aus den Spuren eines Vorfalls wieder her. Halten Sie den Fokus eng: eine Behauptung, zwei Quellen, eine offene Frage. Alles, was Normalisierer, historisches Replay oder Datei-Schiedsgerichtsbarkeit erfordert, gehört zum vollständigen Track.

Vor dem Lesen

• Stütze aus dem ersten Band: Teil 13 lehrt die Wiederherstellung der Konstitution eines bestehenden Projekts; hier stellen Sie eine einzelne Production-Anforderung wieder her.
• Lokaler schulischer Fall: node_not_ready, weil sich daran leicht Provenienz und Unsicherheit zeigen lassen.

• Spur für capstone/: ein Eintrag genealogy.md für das Hauptthema high_memory_usage mit zwei evidence_ref und einer offenen Frage.
• Hauptbegriffe des ersten Durchgangs: evidence_ref und memory bank (Grenze zwischen Anforderung und Hintergrundkontext). Die übrigen Begriffe des Kapitels — Verifier/Implementor/Safety, Koordinator-Protokollant, Normalisierer, Datei-Schiedsgerichtsbarkeit — sind referenzielle Begriffe, die ausführlich in Teil 8 behandelt werden.
• Was zurückzustellen ist: Normalisierer für Logs, historisches Replay und Datei-Schiedsgerichtsbarkeit.

Im ersten Band war AgentClinic ein schulisches Projekt in TypeScript, Hono, serverseitigem JSX, SQLite und Vitest. Im zweiten Band verwenden wir das schulische Modell AgentClinic-production. Dasselbe Projekt gedanklich in Kubernetes deployt. Grafana und PagerDuty senden Webhooks (webhook) in seinen Triage-Kontur, und langlaufende Repliken haben eine operative Historie angesammelt. Python wird im zweiten Band nur für kleine runnable-Skripte in examples/ verwendet, nicht als Stack der Hauptanwendung.

Ein echter Cluster muss nicht hochgefahren werden. Die Legacy-Spuren, mit denen die Kapitel 1–11 arbeiten, sind schulische Post-Mortems, Dashboards und Logs eines Production-Szenarios. Die konkreten Vorfälle weiter unten (node_not_ready, appointment_latency / appointment_latency_spike, autoscale_200pct, cdn_error_budget_burn, high_memory_usage) — Ereignisse aus diesem Modell, keine abstrakten Szenarien.

Die ingenieurtechnische Bezeichnung dieses Verfahrens — Wiederherstellung von Spezifikationen aus beobachtbaren Artefakten: Logs, Metriken, Chats, Post-Mortems und überprüfbaren Entscheidungsspuren. Wenn Sie die bildhafte Formulierung "Spec-Nekromantie" begegnen, betrachten Sie sie nur als kurzes Etikett für diese Rekonstruktion, nicht als separate Technik.

Ziel

Nach dem Abgang des SRE-Teams blieben in einem Projekt zur automatischen Vorfallsverwaltung Fragmente zurück: 47 Seiten unstrukturierter Logs, mehrere Slack-Threads, Screenshots von Dashboards und Post-Mortems ohne formale SDD. Das Ziel des Kapitels ist zu zeigen, wie man aus solchen Spuren eine ingenieurtechnisch brauchbare Spezifikation für einen Triage-Pipeline auf Basis von Qwen Code wiederherstellt. Die Alternative — eine Sammlung plausibler Vermutungen — ist uns nicht geeignet.

Nach dem Abschnitt können Sie:

• Anforderungen vom Hintergrundmodell memory bank abgrenzen (vollständige Definition in den "Schlüsselideen" unten);
• Beweise in eine einheitliche Ereigniskette sammeln;
• implizite Regeln extrahieren und in überprüfbare User Stories umwandeln;
• die Herkunft jedes Punktes so festhalten, dass umstrittene Entscheidungen später auditiert und neu begründet werden können (Rahmen SDD "Spezifikation als ausführbares Artefakt" aus GitHub Spec Kit).

Minimaler schulischer Szenario

Schulischer Fall

Production-Vorfall node_not_ready: anhand des Metrik-Logs, einer Eskalation in PagerDuty und eines Post-Mortems muss eine einzelne Anforderung wiederhergestellt werden — wann das Ereignis NodeNotReady zu P1 wird und wann es nicht automatisch geschlossen werden darf.

Vorbereitung

• book2/examples/templates/genealogy.md — Provenienz-Vorlage.
• Die schulische Auszug unten — minimaler Ersatz für Logs, Post-Mortem und Slack-Thread.
• Ein umstrittener Fakt: geplantes Deploy-Fenster, Canary-Namespace oder manuelle Eskalationsabsage.

Logische Frage: worin unterscheidet sich genealogy.md von git log oder git blame. Kurz: dadurch, dass in git keine Felder vorhanden sind, die hier tragend sind. git log zeigt, welche Datei geändert wurde und wer es getan hat. genealogy.md zeigt, woher die Anforderung selbst stammt, wie sicher wir uns ihrer sind (uncertainty), welche Quellen sie bestätigen (evidence_ref) und welche offenen Fragen unbeantwortet blieben. Ein Commit "added requirement" in der Git-Historie unterscheidet nicht zwischen "wir wissen das fest aus zwei Post-Mortems" und "wir haben das im Chat vermutet". In genealogy.md ist dieser Unterschied zwingend.

Minimaler schulischer Auszug:

grafana:NR-2026-05-17-01  cluster=prod-k8s node=worker-07 event=NodeNotReady count=3 window=10m
pagerduty:NR-2026-05-17-01 escalation=created owner=platform_oncall severity=P1
postmortem:node-not-ready-2026-05  note="auto-resolve was rejected until two stable OK windows"
open_questions:
  - "canary namespace исключает P1 или только снижает уверенность?"

Wenn Sie keine eigenen Logs haben, verwenden Sie diesen Auszug. Wenn Sie reale Materialien haben, ersetzen Sie die Zeilen durch Ihre eigenen, behalten Sie aber denselben Mindeststandard bei: zwei Quellen, eine Behauptung, eine offene Frage.

Schritte

1. Kopieren Sie die Vorlage genealogy.md in das Arbeitsverzeichnis. Erwartung: es erscheint eine Datei mit Abschnitten für Quelle, Status, Sicherheit und offene Fragen.
2. Notieren Sie eine einzelne Behauptungs-Kandidat: zum Beispiel, >=3 NodeNotReady за 10 минут создают P1.
3. Fügen Sie mindestens zwei Beweis-Markierungen (evidence_ref) und einen fehlenden Kontext hinzu. Erwartung: die Behauptung kann nicht als "einfach Meinung des Autors" gelesen werden.
4. Grenzen Sie die Anforderung vom memory bank ab: Cluster-Topologie und Namen der Diensthabenden dürfen nicht zum Vertrag werden.
5. Formulieren Sie die Behauptung in Given/When/Then um und geben Sie daneben an, welches Feld der zukünftigen JSON Schema den Schwellenwert, die Schwere und die Schließbedingung prüft.
6. Setzen Sie den Status auf approved, needs_clarity oder rejected. Erwartung: ein umstrittener Fakt wird nicht als genehmigte Anforderung verschleiert.

Kontrollfakt

In genealogy.md gibt es einen Eintrag, in dem gleichzeitig Behauptung, Quellen, Sicherheitsniveau, fehlender Kontext und Verbindung mit überprüfbarem Verhalten sichtbar sind. Wenn Schwellenwert oder SLA nicht durch einen Verweis auf die Quelle verteidigt werden können, bleibt die Anforderung eine Hypothese.

Wie das in capstone/ gelangt

Übertragen Sie in capstone/genealogy.md nur einen gesicherten Eintrag: Behauptung, zwei evidence_ref, Sicherheitsniveau und offene Frage. Übertragen Sie nicht die gesamte Zeitleiste, Log-Auszüge und Slack-Zitate, wenn sie nicht zum Beweis einer konkreten Anforderung geworden sind.

Minimaler Fragment für high_memory_usage:

- claim: "При memory_percent >= 90% за 10m для appointments-api создаётся P1."
  status: needs_clarity
  evidence_ref: ["grafana:HM-2026-05-17-01", "postmortem:api-memory-2026-05"]
  uncertainty: medium
  open_questions:
    - "Подтверждён ли запрет auto-resolve без двух стабильных окон?"

Reviewbarer Spur

Im schulischen Paket bewahren Sie nur das ausgefüllte genealogy.md oder seinen Fragment auf. Entwürfe von Log-Auszügen und temporäre Tabellen sind nicht im Repository erforderlich, wenn sie nicht zu überprüfbarem Beweis geworden sind.

Schlüsselideen

Die erste Disziplin der Spezifikationswiederherstellung — trennen Sie faktische Anforderungen und das Hintergrundmodell memory bank streng. Unter memory bank verstehen wir eine separate Schicht des infrastrukturellen Kontexts: alles, was bei der Interpretation von Fakten hilft, aber selbst kein Vertrag ist.

Wenn dieser Begriff neu erscheint, betrachten Sie ihn durch den ersten Band. Das, was dort in tech-stack.md (worauf wir schreiben) und in QWEN.md (ständiger Kontext des Agenten) lebte, wird im zweiten Band mit einem gemeinsamen Wort memory bank bezeichnet. Es ist dieselbe Hintergrundschicht, nur jetzt ist sie explizit von den Anforderungen getrennt, weil in Production-Szenarien der Unterschied "Vertrag vs Kontext" kritisch wird.

Eine Anforderung beschreibt im Gegensatz zum memory bank das Verhalten einer Funktion. Was als Auslöser gilt. Wann ein Vorfall erstellt wird. Welcher SLA gilt. Wer die Eskalation erhält. Unter welchen Bedingungen das Ereignis geschlossen wird.

memory bank speichert etwas anderes: Cluster-Topologie, Liste der Teams, historische Vereinbarungen, API-Einschränkungen, gewohnte Kommunikationskanäle und operative Lexik. Warum diese Trennung wichtig ist. Wenn man die Ebenen vermischt, erscheint im SDD leicht eine falsche Regel wie "Canary ist immer nicht-eskalierbar". In Wirklichkeit kann dies nur Kontext des Test-Namespaces sein, nicht universelles Verhalten des Produkts.

Führen Sie die Trennung bereits in der Phase der Artefakt-Inventarisierung ein. Im SDD verzeichnen Sie Behauptungen, die mit einem beobachtbaren Szenario überprüft werden können: >=3 NodeNotReady за 10 минут создают P1, NOC получает уведомление через 15 минут, закрытие требует 2 последовательных OK.

In memory bank senden Sie alles, was bei der Interpretation von Fakten hilft, aber kein Vertrag ist:

• wer in der Vorfallsnacht Dienst hatte;
• warum in Slack ein alter Dienstname verwendet wurde;
• welche Teams Zugriff auf Grafana haben.

Solcher Filter verringert das Risiko, dass Qwen Code die infrastrukturelle Umgebung als Geschäftsregel annimmt und auf Basis eines zufälligen Details Verhalten zu entwerfen beginnt.

Die zweite Idee — Beweise in einer einheitlichen zeitlichen Ereigniskette sammeln und normalisieren. Quellen haben jeweils ihr eigenes Profil:

• Logs liefern beobachtbare Zustände und Ereignisreihenfolge;
• Slack zeigt Absichten der Operatoren und manuelle Umgehungen;
• Post-Mortem fixiert Ursachen und Folgen;
• Metriken ermöglichen die Abschätzung des Degradationsmaßstabes.

Vor der Analyse bringen Sie die Quellen auf eine gemeinsame Zeit (UTC). Entfernen Sie Duplikate, heben Sie Ereigniscodes hervor und verknüpfen Sie die Einträge mit einer einheitlichen Kennung für Vorfall, Cluster, Node oder Deployment. Ohne dies wird die SDD-Wiederherstellung zu einem Streit über Erinnerungen, nicht zu einer Rekonstruktion des Systemverhaltens.

Die normalisierte Kette wird als Sequenz ts → source → event_code → actor → affected_scope → evidence_ref aufgebaut, wobei das letzte Feld die Beweis-Markierung (evidence_ref) ist, ein Verweis auf eine konkrete Stelle im ursprünglichen Artefakt. Im Fall node_not_ready kann das Gerüst zeigen, dass drei Ereignisse NodeNotReady innerhalb von 10 Minuten fast immer der Erstellung von P1 vorausgingen. Dann folgte nach 15 Minuten die Eskalation zum NOC. Die Schließung erfolgte nur nach einem Paar stabiler OK.

Erfassen Sie separat Ausnahmen: geplantes Deploy-Fenster, Canary-Namespace, temporärer Metrikverlust oder manuelle Eskalationsabsage. Entfernen Sie solche Ausnahmen nicht als Rauschen — gerade sie weisen oft auf verborgene Bedingungen der zukünftigen Spezifikation hin.

> [conceptual interface] — diese Befehle zeigen die erwartete Schnittstelle lokaler Normalisierer. Fertige timeline_builder.py und evidence_matrix.py gibt es im Repository des Lehrbuchs nicht; implementieren Sie sie in Ihrem Projekt, wenn Sie vom schulischen Minimum zum vollständigen Track übergehen.

rg -n "NotReady|NodeNotReady|ALERT|deploy" evidence/raw/* > evidence/index.txt
python3 tools/timeline_builder.py --input evidence/raw --out evidence/timeline.ndjson
python3 tools/evidence_matrix.py \
  --timeline evidence/timeline.ndjson \
  --slack evidence/slack_export.json \
  --metrics evidence/metrics.csv \
  --out evidence/matrix.csv

Kontrolle: jede Zeile in evidence/timeline.ndjson enthält ts, source, event_code, cluster, namespace, actor und evidence_ref; leere Felder blockieren den Übergang zur Anforderungsableitung.

Weiter zeigt das Schema, wie aus Legacy ein wiederhergestelltes SDD gewonnen wird. Auf der rechten Seite erscheint der Block "Schiedsgerichtsbarkeit" mit drei Rollen und einem Koordinator: das ist der vollständige Track, der ausführlich in Teil 8 behandelt wird. Im ersten Durchgang betrachten Sie den Block "Schiedsgerichtsbarkeit" als einen einzelnen Schritt "umstrittene Anforderungen prüft eine unabhängige Rolle" — die detaillierte Rollenzusammensetzung braucht hier nicht gelesen zu werden.

flowchart TD
  subgraph Вход["Вход: legacy"]
    L[Логи, пост-мортем, Slack, метрики]
  end
  subgraph Обработка["Обработка"]
    P[Парсинг и временная цепочка]
    R[Гипотезы требований и пользовательские истории]
  end
  subgraph Арбитраж["Арбитраж (полный трек, ч.8)"]
    TBR[Независимая роль проверяет спорные требования]
  end
  subgraph Результат["Результат"]
    S[Восстановленный SDD и genealogy.md]
  end
  L --> P --> R --> TBR --> S

Die dritte Idee — implizite Anforderungen durch Qwen Code extrahieren, aber jede Behauptung nach Quelle und Kontext bewerten. Qwen Code arbeitet hier nicht als Autor der Geschäftslogik, sondern als Vermittler für die Extraktion. Ihm werden Fakten, Umgebungsbeschränkungen und ein strenges Antwortformat übergeben, in dem Behauptungen ohne Beweisverweis verboten sind.

Eine gute Anfrage bittet nicht "SDD erfinden", sondern etwas anderes:

• wiederkehrende Regeln in der Ereigniskette finden;
• bestätigende Quellen angeben;
• Gegenbeispiele nennen;
• ein Sicherheitsniveau zuweisen.

So verstärkt das Modell die Analyse, erhält aber nicht das Recht, Vermutungen in Anforderungen zu verwandeln. Erwarten Sie von Qwen Code eine Liste von Behauptungs-Kandidaten (claims), nicht die finale Spezifikation.

Schlecht:

> REQ-NR-01: при частых NodeNotReady на node создаётся P1.

Problem: weder Schwellenwert noch Zeitfenster noch Beweis-Markierung. Die Regel ist weder überprüfbar noch anfechtbar.

Gut:

> REQ-NR-01: при >=3 NodeNotReady за 10 минут на одном node и коррелированном росте 5xx создаётся P1. evidence: logs/node-2026-05-12.parquet#row_4123, slack/thread_11#msg_7, grafana/node_5xx#segment_11:00. confidence: medium. missing_context: planned deploy window.

Was das in der Praxis bringt. Solcher Eintrag ist nützlicher als glatter Text einer User Story: er zeigt sofort, wo die Anforderung robust ist und wo sie bei der Überprüfung beim Diensteigentümer erfordert. Wenn eine Regel nur durch ein Post-Mortem bestätigt ist und nicht mit den Metriken übereinstimmt, bleibt sie eine Hypothese, auch wenn sie überzeugend klingt.

> [project script] — qwen -p ist an sich runnable, aber der Eingabe-@evidence/matrix.csv muss zuerst in Ihrem Projekt zusammengestellt werden. Das Format des resultierenden JSON stabilisieren Sie durch einen separaten Parser-Normalisierer.

qwen -p "Прочитай @evidence/matrix.csv. Найди повторяющиеся правила
инцидента node_not_ready. Верни claims с evidence, counterexample,
missing_context и confidence. Не утверждай факты без evidence." \

--approval-mode plan \
  --output-format json \
  > sdd/drafts/nr-claims.qwen.json

qwen -p "Прочитай @sdd/drafts/nr-claims.qwen.json и проведи cross-examine:
для каждого claim проверь source, counterexample и missing_context.
Пометь claim как approved, needs_clarity или rejected." \
  --approval-mode plan \
  --output-format json \
  > sdd/drafts/nr-claims-cross.qwen.json

Kontrolle: Qwen arbeitet hier im kopflosen Plan Mode. Der resultierende JSON von Qwen Code —
Bericht mit Sitzungsnachrichten; wenn das Projekt ein strenges claims.json benötigt,
fügen Sie einen separaten Parser-Normalisierer hinzu und prüfen Sie ihn mit Tests.

Die vierte Idee — Anforderungen gleichzeitig in Given/When/Then und maschinenlesbarem Vertrag, zum Beispiel JSON Schema, kodieren. Given/When/Then hält die Anforderung in der Sprache des Verhaltens: Ausgangszustand, Ereignis, erwartetes Ergebnis.

JSON Schema fixiert Pflichtfelder, zulässige Werte, numerische Grenzen und Datenstruktur. Der Vertrag kann in CI oder einer lokalen Validierungs-Pipeline validiert werden. Die doppelte Aufzeichnung beseitigt die Kluft zwischen "menschlich verständlich" und "maschinell überprüfbar".

Für node_not_ready sieht die Verhaltensgeschichte so aus:

• Given der Cluster prod-k8s befindet sich in aktiver Schicht und es werden innerhalb von 10 Minuten >=3 NodeNotReady für einen Node festgestellt;
• When das Ereignis mit einem Deployment korreliert ist oder mit einem Anstieg von 5xx in verwandten Metriken;
• Then wird ein Vorfall severity=P1 erstellt, die Primärreaktion wird in 8 Minuten erwartet, die Auto-Eskalation zum NOC erfolgt nach 15 Minuten, und die Schließung ist nur nach 2 aufeinanderfolgenden OK innerhalb von 10 Minuten erlaubt.

Formulieren Sie die Ausnahme für Canary-Namespace als separate Bedingung, nicht als Anmerkung am Ende. Sonst kann der Validator den Standardpfad nicht vom abgeschwächten Schwellenwert unterscheiden. Solches Format verwandelt das Gespräch über "schnelle Reaktion" in konkrete Zahlen, Ereignisse und Status.

Minimales JSON Schema desselben Vertrags (vollständige Form mit triggers und regulärem Ausdruck für auto_resolve_window — im vollständigen Track):

{
  "$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"]}
      }
    }
  }
}

Die fünfte Idee betrifft nur den vollständigen Track: umstrittene wiederhergestellte Anforderungen können der Datei-Schiedsgerichtsbarkeit übergeben werden. Drei Rollen stimmen ab — Verifizierer, Implementierer, Safety; der Koordinator führt das Protokoll, stimmt nicht ab. Der Verifizierer prüft die Widerspruchsfreiheit von Zahlen und Status, der Implementierer — die Umsetzbarkeit in der aktuellen Triage-Pipeline, Safety — die Grenzen sicheren Handelns und das Vetorecht bei critical_risk. Rollen, Verdikte und Präzedenzfälle werden ausführlich in Teil 8 behandelt; der ausführbare schulische Analogon liegt unter [examples/tribunal/](examples/tribunal/). Für das schulische Minimum ist dieser Schritt nicht erforderlich: genealogy.md mit Quellen, Sicherheitsniveau und offener Frage reicht aus.

Die sechste Idee — führen Sie genealogy.md, ein separates Register der Herkunft jeder Anforderung. Wozu es dient. Ein wiederhergestelltes SDD verliert schnell an Wert, wenn nach einem Monat nicht mehr erklärbar ist:

• warum der Schwellenwert von 3 Ereignissen in 10 Minuten gewählt wurde;
• wer den SLA von 8 Minuten bestätigt hat;
• warum Canary einen separaten Modus erhielt.

genealogy.md verknüpft die Behauptung mit Logs, Slack, Metriken, Post-Mortem, der Entscheidung der Datei-Schiedsgerichtsbarkeit und dem aktuellen Unsicherheitsniveau. So wird die Spezifikation zu einer Beweiskette, nicht zu einem textuellen Schnappschuss des kollektiven Gedächtnisses.

- req_id: NR-01
  statement: "При >=3 NodeNotReady за 10m для одного node и росте 5xx создаётся P1."
  source:
    - logs: evidence/normalized_node_logs.parquet#row_4123
    - slack: export/slack_thread_11.json#msg_7
    - metrics: grafana/node_5xx_timeseries.csv#segment_2026-05-12T11:00
  status: approved
  adjudicated_by: [Verifier, Implementor, Safety]
  uncertainty: low
  open_questions: []

Wenn ein Punkt umstritten bleibt, verschleiern Sie ihn nicht als genehmigten Vertrag. Setzen Sie uncertainty: medium oder uncertainty: high, geben Sie den Grund des Zweifels an und fügen Sie einen Überprüfungsplan hinzu:

• fragen Sie den Diensteigentümer an;

• führen Sie ein Replay mit historischen Daten durch;
• vergleichen Sie mit einem benachbarten Cluster;
• sammeln Sie die fehlende Metrik.

Solches Provenienz-Register ist besonders wichtig für die zukünftige Konstitution des Projekts. In sie sollten nur Regeln mit verständlicher Herkunft, Geltungsbereich und Überprüfungsmechanismus übergehen.

Beispiele und Anwendung

Der schulische Auszug aus 4 Zeilen im "Minimalen schulischen Szenario" ist bereits ein gefiltertes Ergebnis der Normalisierung. Im ursprünglichen Satz finden sich:

• 9 Stunden Beobachtungen;
• 11 relevante Slack-Nachrichten;
• 47 Seiten unbereinigter Logs;
• 1 248 Ereignisse NodeNotReady;
• 63 Alerts;
• 8 zuvor geschlossene Vorfälle.

Nach der Normalisierung ist sichtbar, dass der steile Anstieg von NodeNotReady mit einem Deployment zusammenfiel, ein Teil der Ereignisse in den Canary-Segment mit anderer Auto-Eskalationslogik ging, und es erscheinen zwei Verhaltenszweige: Standard-P1 und Canary-Pfad mit abgeschwächten Schwellenwerten.

> [conceptual interface] — Pseudocode des Normalisierers. Runnable-Beispiele des zweiten Bands bleiben bei Python stdlib und liegen in book2/examples/.

read evidence/normalized_node_logs
sort events by ts
filter event_code == "NodeNotReady"
group by cluster,node in 10m windows
mark windows where count >= 3

link marked windows to alerts and Slack messages in [-15m,+5m]

Das Fenster [-15m,+5m] ist nötig, weil der Operator das Problem vor der formalen Vorfallsaufzeichnung diskutieren konnte oder bereits nach dem automatischen Alert. Wenn ein Ereignis zum Canary-Namespace ohne SLO-Degradation gehört — setzen Sie eine separate Markierung, entfernen Sie es nicht als Rauschen. Wenn ein geplantes Deploy-Fenster einen Teil von NodeNotReady erklärt, geben Sie direkt in der Anforderung an, ob dies die Erstellung von P1 blockiert oder nur die Sicherheit verringert.

Das wiederhergestellte SDD wird erst nach dem Replay zum Arbeitsartefakt: lassen Sie historische Vorfälle durch den neuen JSON-Vertrag laufen und prüfen Sie, ob die erstellten Schweregrade, SLA und Eskalationen mit den bestätigten Ausgängen übereinstimmen. Abweichungen bedeuten nicht immer einen Fehler des Vertrags — manchmal zeigen sie, dass die alte Praxis widersprüchlich war oder vom konkreten Diensthabenden abhing. Was in diesem Fall geändert werden soll — Spezifikation, memory bank oder Status der Hypothese in genealogy.md — entscheidet die Datei-Schiedsgerichtsbarkeit aus Teil 8.

Fazit

Die Wiederherstellung von Spezifikationen aus Legacy stellt das SDD nicht aus Intuition, sondern aus einer überprüfbaren Beweiskette wieder her. Der Weg ist folgender:

• Legacy-Artefakte werden in eine Zeitleiste normalisiert;

• Qwen Code extrahiert Behauptungs-Kandidaten mit Sicherheitsniveau;
• Anforderungen werden vom memory bank getrennt;
• dann werden sie in Given/When/Then und JSON Schema kodiert;
• für den vollständigen Track durchlaufen sie die Datei-Schiedsgerichtsbarkeit Koordinator/Implementierer/Verifizierer;
• sie erhalten Provenienz in genealogy.md.

Solcher Prozess verwandelt das Chaos von Logs, Chats und Post-Mortems in einen Vertrag. Der Vertrag kann validiert, angefochten, auf historischen Daten neu durchgespielt und in ein strengeres Regelsystem überführt werden. Im nächsten Kapitel vergiften wir absichtlich Spezifikationen mit Widersprüchen und untersuchen, wo Qwen Code zu stecken beginnt.

Artefakte und Fertigstellungskriterien

Der vollständige Track fügt hinzu: evidence/timeline.ndjson, evidence/matrix.csv mit Verweisen auf Logs, Slack, Metriken und Post-Mortems, sdd/drafts/nr-claims.qwen.json mit Behauptungs-Kandidaten, contracts/node_not_ready.schema.json und einen Eintrag der Datei-Schiedsgerichtsbarkeit für Anforderungen, die nicht manuell genehmigt werden können. Der vollständige Track gilt als fertig, wenn Given/When/Then und JSON Schema denselben Vertrag beschreiben, der Normalisierer eine reproduzierbare zeitliche Kette liefert, und der Validator oder die Datei-Schiedsgerichtsbarkeit ein überprüfbares verdict fällt.

Praxis

1. Kopieren Sie [examples/templates/genealogy.md](examples/templates/genealogy.md) in capstone/genealogy.md und füllen Sie einen Eintrag für den Hauptfall high_memory_usage aus: Behauptung, mindestens zwei evidence_ref, Sicherheitsniveau und eine offene Frage. Den schulischen Auszug aus dem "Minimalen schulischen Szenario" können Sie als Ersatz für echte Logs verwenden.
2. Formulieren Sie Ihre Behauptung in Given/When/Then um und geben Sie daneben an, welche drei Felder des JSON Schema den Schwellenwert, die Schwere und die Schließbedingung prüfen. Ein Feld, das nicht durch einen Quellenverweis verteidigt werden kann, lassen Sie als uncertainty: medium, nicht als genehmigten Vertrag.

1. Öffnen Sie [appendix-a-bridges-to-book.md](appendix-a-bridges-to-book.md) und markieren Sie, welches Kapitel des ersten Bandes die Stütze für Ihr genealogy.md war. Wenn es keine Stütze gibt — das ist ein Signal, dass die Anforderung noch nicht an das schulische Modell gebunden ist.

Kontrollfragen

1. Warum ist der Beweis wichtiger als eine selbstbewusste Formulierung der Anforderung?
2. Worin unterscheidet sich memory bank vom SDD-Vertrag und warum ist es gefährlich, sie zu vermischen?
3. Wann darf eine Hypothese nicht in eine approved-Anforderung umgewandelt werden?
4. Sie haben eine Regel anhand zweier Post-Mortems wiederhergestellt, aber der Diensteigentümer ist vor einem halben Jahr gekündigt. Was tun Sie mit dieser Regel, bevor Sie sie in requirements.md aufnehmen?