Praxis Teil 6. Auswahl von Shadow-Spezifikationen

Status: Frontier. Der Ansatz selbst – informale Heuristiken in eine separate Schicht auszulagern und sie durch ein Budget an Few-Shot-Slots zu begrenzen – wird angewendet. Aber die Bewertungsformel und Annahmeschwellen erfordern eine Kalibrierung für das konkrete Projekt. Die Idee, „die Hauptspezifikation nicht zu ersetzen“, ist eine Empfehlung.

Für den didaktischen Durchlauf genügt es, examples/shadow-auction/ auszuführen und zu sehen, warum eine Heuristik in QWEN.md aufgenommen wird, während eine andere in Quarantäne geht. Die Gewichtskalibrierung anhand von 50+ Vorfällen gehört zum vollständigen Production-Track.

Führen wir die Schlüsselkonzepte ein. Shadow-Spezifikationen (shadow specs) – überprüfbare Heuristiken aus der operativen Praxis. Sie helfen in der Triage-Phase, sind aber keine verpflichtenden Systemanforderungen. Few-Shot-Beispiel (few-shot) – ein kurzes Beispiel im Prompt, das dem Agenten das gewünschte Antwortformat für ähnliche Fälle zeigt. Scorebook – ein Ökonomie-Journal für Shadow-Spezifikationen: Ausgangsdaten (Seed), Bewertungsformel, Schwellen, Budget, Kandidatenversionen und Entscheidungsprotokoll.

Als wir mission.md in Teil 6 des ersten Bandes zusammengestellt haben, blieben bei den Teilnehmern Wünsche übrig, die nicht bis zu einer Anforderung reichten. Typische Beispiele:

• „nachts kürzer antworten“,
• „den Patienten nicht mit dem Wort Notfall erschrecken“,
• „bei wiederholtem Symptom sofort die Historie abfragen“.

Dieses Kapitel beantwortet die damals aufgeschobene Frage – was mit solchen Wünschen in der Produktion zu tun ist. Wo sie landen, wie sie ihren Nutzen beweisen und wann sie entfernt werden können. Das Few-Shot-Beispiel, das schließlich in QWEN.md landet, ist dieselbe Agenten-Erinnerung wie in Teil 19 des ersten Bandes, aber mit expliziter Lebensdauer (ttl) und einem Aufnahme-Auktionsverfahren.

Vor dem Lesen

• Bezug zum ersten Band: Teil 6 zeigt, dass Wünsche nicht gleich Anforderungen sind; Teil 19 trennt Erinnerung von Spezifikation.
• Lokaler didaktischer Fall: Auktion shadow.p0.voice_handoff gegen eine laute Heuristik zur Dashboard-Farbe.
• Spur für capstone/: kurzer Block Shadow notes mit einem angenommenen und einem abgelehnten Kandidaten für high_memory_usage.
• Hauptbegriffe des ersten Durchlaufs: Shadow-Spezifikation und Scorebook. Auktion, Few-Shot-Beispiel, Quarantäne – als Nachschlagewerk.

• Was zurückzustellen ist: Sammlung von Kandidaten aus 50+ Vorfällen, Gewichtskalibrierung und automatische Aktualisierung von QWEN.md.

Ziel

In diesem Kapitel verwandeln Sie informelle Beobachtungen aus dem Incident-Management in eine überprüfbare Schicht von Shadow-Spezifikationen mit messbarem Wert. Das Wort „Auktion“ bedeutet hier ein geranktes Auswahlverfahren unter einem begrenzten Kontext-Budget, nicht ein separates Produkt oder einen obligatorischen externen Dienst. Welche Beobachtungen hier landen:

• Kommunikationston,
• intuitive Annahmen,
• Umgebungssignale,
• „magische“ Lösungen erfahrener Ingenieure.

Das Ziel liegt nicht darin, die formale Spezifikation zu ersetzen. Das Ziel ist, nützliche Heuristiken vom operativen Folklore zu trennen. Am Ende können Sie:

• eine Shadow-Spezifikations-Auktion starten (also Bewertung und Auswahl von Heuristiken unter einem begrenzten Kontext-Budget);
• jedem Nuance einen prädiktiven Wert auf Basis historischer Vorfälle zuweisen;
• in QWEN.md nur diejenigen Few-Shot-Beispiele behalten, die die Qualität von Qwen Code tatsächlich verbessern.

Minimaler didaktischer Szenario

Didaktischer Fall

Es muss entschieden werden, ob die Heuristik shadow.p0.voice_handoff in QWEN.md aufgenommen wird, während die laute Heuristik zur roten Dashboard-Farbe in Quarantäne geht. Ziel ist zu sehen, dass eine informelle Beobachtung durch Bewertung und Budget geht, statt zur Anforderung per Autorität zu werden.

Vorbereitung

• book2/examples/shadow-auction/candidates/candidates.yaml.
• book2/examples/shadow-auction/data/incidents.jsonl.
• Skripte score.py, decide.py, write_qwen_block.py.

Schritte

1. cd book2/examples/shadow-auction. Erwartung: Sie befinden sich im Verzeichnis des ausführbaren Beispiels.
2. python3 scripts/score.py --candidates candidates/candidates.yaml --incidents data/incidents.jsonl --weights 0.5,0.3,0.2,0.4 --out out/scorebook.json. Erwartung: ein Scorebook mit Score-Komponenten wurde erstellt.
3. python3 scripts/decide.py --scorebook out/scorebook.json --budget-tokens 2000 --keep-threshold 0.70 --reject-threshold 0.40 --out-auction out/auction.json --out-quarantine out/quarantine.json. *Erwartung: einige Kandidaten erhielten den Status winner, andere gingen in Quarantäne (quarantine).*

1. python3 scripts/write_qwen_block.py --auction out/auction.json --target-anchor "QWEN.md#incident-triage-shadow" --today 2026-05-17 --out out/qwen_block.md. *Erwartung: der Block für QWEN.md enthält nur Gewinner und einen Verweis auf die Entscheidungsquelle; mit dem didaktischen Datum stimmt er mit outputs/qwen_block.example.md überein.*
2. Vergleichen Sie out/auction.json und out/quarantine.json: Erwartung: der unterlegene Kandidat verschwand nicht, sondern erhielt einen Ablehnungsgrund.

Kontrollfakt

Der Gewinner wurde nicht zur verpflichtenden Anforderung. Er ist als versioniertes Few-Shot-Beispiel mit source_ref, Score und Überprüfungstermin formatiert. Der Kandidat unterhalb der Schwelle befindet sich in Quarantäne mit Begründung.

Wie dies in capstone/ einfließt

Übertragen Sie in capstone/README.md einen kurzen Abschnitt Shadow notes: einen Gewinner und einen abgelehnten Kandidaten, id, Score, Grund für keep/reject und Überprüfungstermin. Fügen Sie den Gewinner nicht zu requirements.md hinzu: im Abgabepaket bleibt er eine Shadow-Prompt, kein genehmigtes Anforderung.

Minimaler Fragment:

shadow_notes:
  keep:
    id: shadow.p0.voice_handoff.v1
    score: 0.727
    ttl: "14d"
    reason: "early signal for manual handoff"
  reject:

id: shadow.alert.red_color_urgency
    reason: "false escalation risk"

Reviewbare Spur

out/ ist im didaktischen Paket nicht erforderlich. Für die Abgabe genügt es, einen kurzen Auszug in QWEN.md oder capstone/README.md mit Verweis auf das Auktionskriterium zu speichern.

Schlüsselideen

Beginnen Sie die Normalisierung mit der Übersetzung von Beobachtungen in das Shadow-Spezifikations-Format: Kontext → Merkmal → beobachtbarer Effekt. Die Felder sind:

• Kontext setzt die Anwendungsgrenzen. Zum Beispiel „P0-Vorfall mit Kaskadenrisiko in appointments-api“.
• Merkmal erfasst das beobachtete Detail. Zum Beispiel „der Diensthabende schreibt kurze imperative Nachrichten und überspringt die Standardvorlage“.
• Effekt beschreibt die überprüfbare Folge. Zum Beispiel „nach 5–10 Minuten entsteht ein manueller Bypass oder ein Not-Rollback“.

Dieses Format macht die Nuance nicht zu einem vollständig formalen Vertrag. Aber es verwandelt sie in einen Slot, der mit der Vorfallsgeschichte verglichen werden kann. Zusätzliche Felder evidence, scope, risk und source_ref sind nötig, damit Qwen Code die Heuristik-Bedeutung nicht aus Freitext errät.

In Ihrem Projekt übernimmt ein Skriptpaar harvest.py + normalize.py die Kandidatensammlung: das erste sammelt Auszüge aus Interviews, Postmortems und Vorfällen in .specify/memory/shadow-candidates.raw.ndjson, das zweite entfaltet sie nach dem Template Kontext → Merkmal → Effekt in .specify/memory/shadow-candidates.yaml. Ein ausführbares Äquivalent für diese Stufe gibt es im Lehrbuch nicht; sie hängt davon ab, wo Ihre Quellen liegen. Das ausführbare Äquivalent der Bewertung und Auktion selbst findet sich in examples/shadow-auction/README.md.

Nach der Normalisierung wird jeder Kandidaten-Slot anhand historischer Vorfälle nach drei Metrikgruppen bewertet:

• Einfluss auf MTTR,
• Anteil falscher Eskalationen,
• Fähigkeit zur Kaskaden-Vorwarnung.

Die Bewertung baut sich auf drei Achsen auf.

MTTR zeigt, ob die Heuristik schneller zur korrekten Aktion führte. Aber diese Metrik allein ist gefährlich. Eine Regel kann einzelne Fälle beschleunigen und gleichzeitig in der Triage-Phase Lärm erzeugen.

Falsche Eskalationen erfassen den Preis falscher Auslösungen. Besonders wenn eine Shadow-Spezifikation P2 zu P1 ohne ausreichende Begründung hochstuft.

Frühe Kaskaden-Vorwarnung misst, ob das Merkmal vor der Standard-Alarmierung auftrat. Und nicht erst, nachdem das formale System das Problem bereits erfasst hatte.

Notieren Sie die Gesamtbewertung als reproduzierbare Formel, nicht als Experten-Einschätzung „scheint nützlich“. Verwenden Sie für den didaktischen Kontour zum Beispiel score = 0.5*mttr_gain + 0.3*early_signal + 0.2*coverage - 0.4*false_escalation. Hier begrenzt coverage übermäßig spezifische Regeln, während false_escalation laute Heuristiken bestraft.

Die Gewichte in dieser Formel sind eine Startkalibrierung, kein Gesetz. Die Summe der positiven Gewichte wurde auf Eins gesetzt (0.5+0.3+0.2), damit der Gesamt-Score im Intervall [-0.4; 1] liegt und als „Anteil nützlichen Signals“ lesbar ist. Innerhalb dieser Eins spiegelt das Verhältnis 0.5 / 0.3 / 0.2 die didaktische Prioritätenreihenfolge von AgentClinic-Production wider: MTTR-Reduktion ist der hauptsächliche messbare Effekt, frühes Signal ist nur als Verkürzung desselben MTTR wertvoll, und Coverage ist nur eine Absicherung gegen zu spezifische Regeln. Der Strafkoeffizient für falsche Eskalation (0.4) wurde so gewählt, dass eine falsche Eskalation ~80% des nützlichen Effekts einer idealen MTTR-Senkung verbraucht (0.4 / 0.5 = 0.8): eine Heuristik, die bei einer idealen MTTR-Senkung (mttr_gain=1) eine falsche Eskalation (false_escalation=1) erzeugt, verliert fast den gesamten Gesamt-Score (0.5 - 0.4 = 0.1) und geht nicht in die finale Auslieferung. Wie man weiter kalibriert:

• wenn der Fehlerpreis Ihres Teams höher ist – erhöhen Sie den Strafwert auf 0.6–0.8;
• wenn frühe Vorwarnung wichtiger ist – erhöhen Sie early_signal auf Kosten von mttr_gain.

Nach der Kalibrierung führen Sie die Formel über 50+ historische Vorfälle aus. Vergleichen Sie die Gewinner mit der aktuellen manuellen Entscheidungsfindung des Teams. Wenn die Abweichung zu groß ist, sind die Gewichte für ein fremdes Risikoprofil kalibriert.

Verwenden Sie genug historische Fälle, damit seltene Kaskaden nicht aus der Bewertung verschwinden. Für eine ernsthafte Entscheidung nutzen Sie 50+ Vorfälle: dies ist die Untergrenze, bei der eine seltene Kaskadenklasse (mit Häufigkeit ~1 pro 25 Vorfällen) mindestens zweimal in der Stichprobe auftritt und early_signal vom Zufall unterschieden werden kann. Kleinere Mengen lassen Sie nur für einen Smoke-Test.

Was „Daten-Drift“ in diesem Kontext bedeutet. Drift – Desynchronisation von Zeitachsen und Identifikatoren in den Vorfallsquellen. Wenn die Zeitachsen in den Quellen nicht ausgerichtet sind, kann Qwen Code eine Post-hoc-Beobachtung als frühes Signal missverstehen. Daher führen Sie vor der Bewertung drei Aktionen durch: Deduplizierung, Normalisierung der Zeitstempel und Zuordnung von Ereignissen zu einer einheitlichen Vorfall-Identifikation.

In Ihrem Projekt ist die Bewertung als python3 scripts/shadow_specs/score.py --candidates .specify/memory/shadow-candidates.yaml --incidents .data/incidents_hist_50plus.jsonl --weights "0.5,0.3,0.2,0.4" --out .specify/memory/shadow-scorebook.json formatiert. Das ausführbare Äquivalent auf didaktischen Daten findet sich in examples/shadow-auction/README.md.

Die Auktion verwandelt die Bewertung in eine steuerbare Verteilung eines begrenzten Kontext-Budgets.

Schlecht:

> die Heuristik „Diensthabender ASAP in Slack – Severity auf P1 erhöhen“ wurde direkt in requirements.md als verpflichtende Anforderung hinzugefügt.

Problem: eine ungeprüfte Beobachtung wird ohne Beweise zum Vertrag. Und erzeugt falsche P1 bei jedem „ASAP“ im Chat.

Gut:

> dieselbe Heuristik ist als Shadow-Spezifikation shadow.slack.asap_urgency mit Score 0.55 und Status review formatiert: der Wert liegt über der Ablehnungsschwelle reject_threshold=0.40, aber unter der Annahmeschwelle keep_threshold=0.70, daher geht der Kandidat zur manuellen Revision, nicht in die formale Spezifikation.

Wie der Prozess funktioniert. Qwen Code sortiert Kandidaten nach value_score. Dann verbraucht es ein vorab festgelegtes budget – zum Beispiel 8 Few-Shot-Slots oder 2.000 Tokens. Das Ergebnis wird in drei Kategorien eingeteilt:

• keep – Gewinner, geht in QWEN.md;
• review – umstritten, zur manuellen Revision;
• quarantine – abgelehnt, geht in Quarantäne.

Gewinner werden nur bei Überschreitung der oberen Schwelle automatisch aufgenommen. Umstrittene kommen zur manuellen Revision. Abgelehnte bleiben nicht in der Grauzone. Dieses Schema schützt QWEN.md vor Ausuferung. Selbst eine plausibel klingende Nuance verliert, wenn ihr prädiktiver Wert unter den Kosten des Platzverbrauchs im Prompt liegt.

In Ihrem Projekt ist die Auktionsentscheidung als python3 scripts/shadow_specs/decide.py --scorebook .specify/memory/shadow-scorebook.json --budget-tokens 2000 --keep-threshold 0.70 --reject-threshold 0.40 --out-auction .specify/memory/shadow-auction.json --out-quarantine .specify/memory/shadow-quarantine.json formatiert. Derselbe Schritt auf didaktischen Daten läuft in examples/shadow-auction/README.md.

Verwandeln Sie Gewinner in versionierte Few-Shot-Blöcke in QWEN.md, statt sie einfach ans Dateiende anzuhängen. Weisen Sie jedem Block zu:

• id,
• version,
• source_ref,
• score,
• valid_from,
• next_review (oder ttl – zulässige Kurzform für kurze Überprüfungen wie „14d“),
• kurzes Anwendungsbeispiel.

Wozu diese Felder dienen. Das nachfolgende Team muss verstehen, warum diese Nuance existiert.

Entfernen Sie niedrigwertige Kandidaten explizit. Senden Sie sie in quarantine mit Grund, Überprüfungsdatum und Verweis auf die Berechnung. Lassen Sie sie nicht spurlos aus der Geschichte verschwinden. Dies ist wichtig für die Anfechtung von Entscheidungen: wenn sich nach einem Monat die Alarmierungspolitik oder die Failover-Architektur ändert, kann eine zuvor abgelehnte Shadow-Spezifikation ohne erneute Datensammlung zur Auktion zurückgeführt werden.

- id: shadow.p0.voice_handoff.v1
  status: keep
  score: 0.727
  source_ref:
    - postmortem: "appointments-api-2026-02-11"
    - incident: "INC-1842"
  valid_from: "2026-05-17"
  next_review: "2026-08-17"
  few_shot_target: "QWEN.md#incident-triage-shadow"

Woher konkret 0.727 kommt: dieser Wert wird von examples/shadow-auction/scripts/score.py auf 20 historischen Vorfällen aus data/incidents.jsonl bei Standardgewichten 0.5/0.3/0.2 − 0.4 ausgegeben. Die Überprüfung mit dem Referenzwert erfolgt über examples/shadow-auction/outputs/scorebook.example.json.

Das Scorebook ist ein Ökonomie-Journal für Shadow-Spezifikationen. Darin werden gemeinsam gespeichert: Ausgangsdaten (Seed), Bewertungsformel, Schwellen, Budget (budget), Kandidatenversionen und Entscheidungsprotokoll.

Ohne Scorebook wird die Auktion schnell zu einem Autoritätenstreit. Ein erfahrener Ingenieur kann seine Lieblingsheuristik durchsetzen, und Qwen Code erhält widersprüchliche Few-Shot-Beispiele. Hier ist ein weiteres Konzept nützlich. Anti-Goodhart – Schutz vor Optimierung einer Kennzahl auf Kosten des Sinns. Ein reproduzierbares Journal bietet drei Möglichkeiten: Ergebnisse nach Gewichtsänderung neu berechnen, prüfen welche Vorfälle den Sieg beeinflussten, echte Verbesserung von Goodhart-Falle trennen.

Halten Sie diese Datei im SDD-Kontour neben dem Projektgedächtnis und den konstitutionellen Beschränkungen. Im Spec Kit eignet sich .specify/memory/constitution.md als Schutzschicht gegen Drift für solche Dauerregeln (GitHub Spec Kit).

Vollständiger Track: Kalibrierung der Schwellen

Die Gewichte der Auktionsformel, die Schwellen keep/reject und die Signale für Gewichtsüberprüfung sind in Anhang D, Abschnitt D.2 ausgelagert. Beim ersten Durchlauf ist der Abschnitt nicht nötig: es genügt ein angenommener und ein abgelehnter Kandidat bei Standardgewichten.

Beispiele und Anwendung

Beispiel: im Projekt der automatischen Triage für appointments-api beschreibt der Kandidat shadow.p0.voice_handoff eine Situation. Bei P0 schreibt der Diensthabende keine lange Chat-Nachricht, sondern initiiert sofort eine Sprachübergabe (handoff) zwischen Diensthabendem (on-call) und Service-Eigentümer.

Auf 20 historischen Vorfällen aus data/incidents.jsonl ergab dieses Merkmal einen Score von 0.727: hoher MTTR-Anstieg (0.7541), sicheres frühes Signal (1.0), schmale Coverage (0.25) und null falsche Eskalationen. In fünf Fällen verkürzte es die Zeit bis zum Eingreifen der zweiten Schicht. Falsche Eskalationen erzeugte der Kandidat kaum, da er nur bei bestätigtem P0 und Kaskadenrisiko von Transaktionen angewendet wurde.

Dieser Kandidat wird zum Gewinner. Aber in QWEN.md kommt er mit einer engen Anwendbarkeitsbedingung. Qwen Code sollte nicht den Sprachkanal für normales P2 empfehlen, wo der asynchrone Text-Trail wichtiger ist als die Geschwindigkeit eines Anrufs. Der praktische Wert liegt nicht im bloßen Fakt „anrufen“, sondern in der frühen Erkennung einer Situation, in der Verzögerung der Übergabe teurer ist als der Verlust eines Teils des schriftlichen Kontexts.

Ein anderer Kandidat, shadow.alert.red_color_urgency, verliert die Auktion. Obwohl er intuitiv überzeugend wirkt. Dieselbe ausführbare Auktion gibt ihm einen Score von -0.3081: schwacher MTTR-Anstieg und bemerkbarer Anteil falscher Eskalationen ziehen die Bewertung ins Negative. Die rote Farbe wurde in Dashboards oft für visuelle Akzente verwendet, entsprach aber nicht dem Auswirkungsradius, der SLO-Budget-Aufzehrgeschwindigkeit oder dem tatsächlichen Eskalationsniveau.

Diese Shadow-Spezifikation hatte einen dreifachen negativen Effekt:

• erhöhte den Anteil falscher P1,
• überlastete die Triage-Phase,
• verschlechterte das Vertrauen in automatische Empfehlungen.

Senden Sie sie in Quarantäne mit Grund high_false_escalation, Überprüfungsdatum und Rückkehrbedingung. Zuerst ändert das Team die Visualisierungspolitik für Alarme. Dann wird der Kandidat erneut durch das Scorebook geführt.

Ein seltenes physisches Signal kann gewinnen, wenn der Preis des Übersehens deutlich über dem Preis der Überprüfung liegt. Zum Beispiel ist shadow.dc.burn_smell_power_risk nur auf Vorfallsfälle mit Vor-Ort-Beobachtung (onsite) im Rechenzentrum anwendbar. Seine coverage ist niedrig, aber early_signal hoch: Brandgeruch oder Überhitzung treten manchmal auf, bevor die Stromüberwachung Degradation zeigt.

Ein solcher Kandidat darf nicht zu einer universellen Regel gemacht werden. Sonst wird er zu toxischem Lärm für Cloud-Vorfälle ohne physischen Zugang. Die korrekte Einschlussform ist ein seltener Few-Shot-Beispiel mit drei Begrenzern: harter Kontext, explizite Risikoanmerkung und Anforderung zur Bestätigung des Signals durch den Vor-Ort-Operator-Kanal.

flowchart TD
A[Kapitel 6. Auswahl von Shadow-Spezifikationen]
A --> B[Interviews / Postmortems / Vorfallsgeschichte]

B --> C[Extraktion von Shadow-Kandidaten]
C --> D[Normalisierung Kontext / Merkmal / Effekt]
D --> E[Retro-Test über 50+ Fälle via Qwen Code]
E --> F["score = 0.5*mttr_gain + 0.3*early_signal + 0.2*coverage - 0.4*false_escalation"]
F --> G[Auktionsentscheidung keep/quarantine/review]
G --> H[keep]
G --> I[quarantine]
G --> J[review]
H --> K[QWEN.md]
I --> L[Quarantäne mit Überprüfungsdatum]
J --> L

Zusammenfassung

Die Shadow-Spezifikations-Auktion macht informelle Nuancen steuerbar. Jeder Kandidat erhält eine Struktur Kontext → Merkmal → beobachtbarer Effekt, durchläuft eine Bewertung anhand historischer Vorfälle, konkurriert um ein begrenztes Budget – und wird entweder zu einem versionierten Few-Shot-Beispiel in QWEN.md oder geht in Quarantäne mit überprüfbarem Grund.

Die Hauptdisziplin des Prozesses ist, lebhaften Geschichten ohne Scorebook nicht zu vertrauen. Ausgangsdaten, Formel, Schwellen und Entscheidungsprotokoll müssen die Reproduktion des Ergebnisses und seine Anfechtung bei Infrastrukturänderung ermöglichen. Das nächste Kapitel überträgt diese Logik in einen Spezifikations-Gateway (Specification CI), in dem die Spezifikation zu einem ausführbaren Artefakt wird.

Artefakte und Fertigstellungskriterien

| Ausgeführte lokale Auktion aus book2/examples/shadow-auction | smoke-pass; Ergebnisse sind bei identischen Gewichten und Daten reproduzierbar | | Ein Gewinner | hat source_ref, Score und Überprüfungstermin; Gewinner erweitert nicht den formalen SDD-Vertrag und tarnt sich nicht als Anforderung | | Ein abgelehnter Kandidat | in Quarantäne mit explizitem Grund (zum Beispiel high_false_escalation) | | Kurzer Block für QWEN.md oder Abschnitt Shadow notes in capstone/README.md | Few-Shot-Beispiel hat eine enge Anwendbarkeitsbedingung |

Der vollständige Track fügt .specify/memory/shadow-candidates.yaml im Format Kontext → Merkmal → Effekt, .specify/memory/shadow-scorebook.json mit Formel und Gewichten, .specify/memory/shadow-auction.json mit Entscheidungen winner/disputed/rejected und einen versionierten Few-Shot-Block oder Quarantäne-Eintrag hinzu. Betrachten Sie ihn als fertig, wenn jede Shadow-Spezifikation source_ref, scope, risk und next_review hat, die Bewertung reproduzierbar berechnet wird (ohne manuelle Neuberechnung), und Kandidaten bei Änderung von Gewichten, Budget oder Vorfallsklasse überprüft werden.

Praxis

1. Führen Sie die Auktion auf didaktischen Daten aus: cd book2/examples/shadow-auction && python3 scripts/score.py --candidates candidates/candidates.yaml --incidents data/incidents.jsonl --weights 0.5,0.3,0.2,0.4 --out out/scorebook.json. *Erwartung: diff -u outputs/scorebook.example.json out/scorebook.json ergibt 0 Zeilen; unter den Bewertungen gibt es mindestens einen Kandidaten mit score >= 0.70 und mindestens einen mit score < 0.40.*
2. Starten Sie auf demselben scorebook.json: python3 scripts/decide.py --scorebook out/scorebook.json --budget-tokens 2000 --keep-threshold 0.70 --reject-threshold 0.40 --out-auction out/auction.json --out-quarantine out/quarantine.json. *Erwartung: out/auction.json und out/quarantine.json stimmen mit den Referenzen in outputs/ überein; in out/quarantine.json mindestens ein Eintrag mit explizitem reason und return_condition.*
3. Ändern Sie den Strafwert für falsche Eskalation von 0.4 auf 0.8, berechnen Sie scorebook.json neu und dokumentieren Sie die Verschiebung in capstone/README.md. *Erwartung: in capstone/README.md ist eine Zeile „bei verdoppeltem Strafwert für falsche Eskalation wechselte Kandidat <id> von keep zu quarantine“; in derselben Zeile ist angegeben, welche Formelkomponente im neuen Gewicht dominant wurde.*

Kontrollfragen

1. Wodurch unterscheidet sich eine Shadow-Spezifikation von einer vollwertigen Anforderung und warum darf sie diese nicht ersetzen?
2. Warum muss ein Few-Shot-Beispiel in QWEN.md einen Überprüfungstermin haben?
3. Wie erkennt man, dass eine Heuristik zum operativen Folklore geworden ist?
4. Der Diensthabende verlangt, die Regel „wenn in Slack das Wort ASAP verwendet wird – Severity erhöhen“ in QWEN.md aufzunehmen. Wie führen Sie dies durch die Shadow-Spezifikations-Auktion, ohne sofort abzulehnen?