Anwendungsteil 6. Auswahl von Schattenspezifikationen

Status: Frontier. Das Verfahren selbst – informelle Heuristiken in eine eigene Schicht auszulagern und sie über ein Few-Shot-Slot-Budget zu begrenzen – wird angewendet. Die Bewertungsformel und die Annahmeschwellen müssen jedoch für das jeweilige Projekt kalibriert werden. Die Idee, „die Hauptspezifikation nicht zu ersetzen“, ist eine Empfehlung.

Für die Lernbearbeitung genügt es, examples/shadow-auction/ durchzuspielen und zu sehen, warum eine Heuristik in QWEN.md aufgenommen wird und eine andere in Quarantäne wandert. Die Kalibrierung der Gewichte an 50+ Vorfällen gehört zum vollständigen Produktions-Track.

Wir führen die Schlüsselbegriffe ein. Schattenspezifikationen (shadow specs) – prüfbare Heuristiken aus der Betriebspraxis. Sie helfen in der Triage-Phase, sind aber keine verbindlichen Anforderungen des Systems. Few-Shot-Beispiel – ein kurzes Beispiel im Prompt, das dem Agenten das gewünschte Antwortformat an ähnlichen Fällen zeigt. Bewertungsjournal (scorebook) – das Wirtschaftsjournal der Schattenspezifikationen: Seed-Daten, Bewertungsformel, Schwellen, Budget, Kandidatenversionen und Entscheidungsprotokoll.

Als wir mission.md in Teil 6 des ersten Bands zusammengestellt haben, blieben bei den Teilnehmenden Wünsche übrig, die es nicht bis zur Anforderung schafften. Typische Beispiele:

• „nachts kürzer antworten“,
• „den Patienten nicht mit dem Wort emergency erschrecken“,
• „bei wiederkehrenden Symptomen sofort die Historie anfordern“.

Dieses Kapitel beantwortet die damals aufgeschobene Frage – was mit solchen Wünschen in der Produktion geschieht. Wohin sie wandern, wie sie ihren Nutzen belegen und wann man sie entfernen kann. Das Few-Shot-Beispiel, das letztlich in QWEN.md landet, ist derselbe Agentenspeicher wie in Teil 19 des ersten Bands, jedoch mit expliziter Lebensdauer (ttl) und Annahmeauktion.

Vor dem Lesen

• Anker im ersten Band: Teil 6 zeigt, dass Wünsche nicht gleich Anforderungen sind; Teil 19 trennt Speicher von Spezifikation.
• Lokaler Lernfall: Auktion shadow.p0.voice_handoff gegen eine verrauschte 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 Durchgangs: Schattenspezifikation und Bewertungsjournal (Scorebuch). Auktion, Few-Shot-Beispiel, Quarantäne – nachschlagbar.

• Was zurückzustellen ist: Sammeln von Kandidaten aus 50+ Vorfällen, Kalibrierung der Gewichte und automatisches Aktualisieren von QWEN.md.

Ziel

In diesem Kapitel verwandeln Sie informelle Beobachtungen aus dem Incident-Management in eine prüfbare Schicht von Schattenspezifikationen mit messbarem Wert. Das Wort „Auktion" bedeutet hier eine rangbasierte Auswahl unter begrenztem Kontextbudget, nicht ein eigenständiges Produkt oder einen zwingenden externen Dienst. Welche Beobachtungen hier landen:

• Tonalität der Kommunikation,
• intuitive Vorannahmen,
• Umgebungssignale,
• „magische" Entscheidungen erfahrener Ingenieure.

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

• eine Auktion von Schattenspezifikationen durchführen (also Bewertung und Auswahl von Heuristiken unter begrenztem Kontextbudget);
• jeder Nuance einen Vorhersagewert auf Basis historischer Vorfälle zuweisen;
• in QWEN.md nur die Few-Shot-Beispiele behalten, die die Qualität von Qwen Code tatsächlich verbessern.

Minimales Lernszenario

Lernfall

Es ist zu entscheiden, ob die Heuristik shadow.p0.voice_handoff in QWEN.md aufgenommen wird und die verrauschte Heuristik zur roten Dashboard-Farbe in Quarantäne wandert. Das Ziel ist zu sehen, dass eine informelle Beobachtung die Bewertung und das Budget durchläuft, statt durch Autorität zur Anforderung 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 Bewertungsjournal 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: Ein Teil der Kandidaten erhielt den Status winner, ein Teil wanderte in die 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 Lerndatum stimmt er mit outputs/qwen_block.example.md überein.*
2. Vergleichen Sie out/auction.json und out/quarantine.json: Erwartung: Der Verlierer-Kandidat ist nicht verschwunden, sondern hat einen Ablehnungsgrund erhalten.

Kontrollfakt

Der Gewinner ist keine verbindliche Anforderung geworden. Er ist als versioniertes Few-Shot-Beispiel mit source_ref, Score und Überprüfungsfrist ausgefertigt. Der Kandidat unterhalb der Schwelle befindet sich mit Begründung in Quarantäne.

Wie dies in capstone/ landet

Übernehmen Sie in capstone/README.md einen kurzen Abschnitt Shadow notes: einen Gewinner und einen abgelehnten Kandidaten, id, Score, Begründung keep/reject und Überprüfungsfrist. Fügen Sie den Gewinner nicht in requirements.md ein: im benoteten Paket bleibt er eine Schattenhinweis, keine freigegebene Anforderung.

Minimales 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"

Überprüfbare Spur

out/ wird im Lernpaket nicht benötigt. Für die Benotung 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 Umwandlung von Beobachtungen in das Schattenspezifikationsformat: Kontext → Merkmal → beobachtete Wirkung. Die Felder sind:

• Kontext legt die Anwendungsgrenzen fest. Beispiel: „P0-Vorfall mit Kaskadenrisiko in appointments-api".
• Merkmal hält das beobachtete Detail fest. Beispiel: „Der Bereitschaftsdienst schreibt kurze imperativische Nachrichten und überspringt die Standardvorlage".
• Wirkung beschreibt die prüfbare Konsequenz. Beispiel: „Nach 5–10 Minuten entsteht ein manueller Bypass oder ein Notfall-Rollback".

Dieses Format macht die Nuance nicht zum vollständig formalen Vertrag. Es verwandelt sie jedoch in einen Slot, der mit der Incident-Historie vergleichbar ist. Die zusätzlichen Felder evidence, scope, risk und source_ref sind nötig, damit Qwen Code den Sinn der Heuristik nicht aus freiem Text errät.

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

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

• Einfluss auf die MTTR,
• Anteil falscher Eskalationen,
• Fähigkeit, frühzeitig vor einer Kaskade zu warnen.

Die Bewertung wird auf drei Achsen aufgebaut.

MTTR zeigt, ob die Heuristik half, schneller zur korrekten Handlung zu gelangen. Allein ist diese Metrik jedoch gefährlich. Eine Regel kann Einzelfälle beschleunigen und gleichzeitig in der Triage-Phase Lärm erzeugen.

Falsche Eskalationen erfassen die Kosten einer Fehlauslösung. Besonders wenn die Schattenspezifikation P2 ohne ausreichende Grundlage auf P1 anhebt.

Frühwarnung vor einer Kaskade misst, ob das Merkmal vor der Standardwarnung auftrat. Nicht erst, nachdem das formale System das Problem bereits erfasst hat.

Halten Sie das Ergebnis als reproduzierbare Formel fest, nicht als Expertenurteil „wirkt nützlich". Für den Lernkontur verwenden Sie zum Beispiel score = 0.5*mttr_gain + 0.3*early_signal + 0.2*coverage - 0.4*false_escalation. Hier begrenzt coverage übermäßig enge Regeln, und false_escalation bestraft verrauschte Heuristiken.

Die Gewichte in dieser Formel sind eine Startkalibrierung, kein Gesetz. Die Summe der positiven Gewichte ist auf Eins normiert (0.5+0.3+0.2), damit der resultierende Score im Intervall [-0.4; 1] liegt und als „Anteil nützlichen Signals" gelesen wird. Innerhalb dieser Eins spiegelt das Verhältnis 0.5 / 0.3 / 0.2 die Lernprioritäten der AgentClinic-Produktion wider: die Reduktion der MTTR ist der wichtigste messbare Effekt, das frühe Signal ist nur wertvoll als Verkürzung derselben MTTR, und die Abdeckung ist lediglich eine Absicherung gegen zu enge Regeln. Der Strafkoeffizient für falsche Eskalationen (0.4) ist so gewählt, dass eine falsche Eskalation ~80 % des Nutzeffekts einer idealen MTTR-Reduktion aufzehrt (0.4 / 0.5 = 0.8): Eine Heuristik, die auf eine ideale MTTR-Reduktion (mttr_gain=1) eine falsche Eskalation (false_escalation=1) erzeugt, verliert fast den gesamten Score (0.5 - 0.4 = 0.1) und geht nicht in die Auslieferung. Wie weiter kalibriert wird:

• wenn die Fehlerkosten in Ihrem Team höher sind – erhöhen Sie die Strafe auf 0.6–0.8;
• wenn die Frühwarnung wichtiger ist – erhöhen Sie early_signal zulasten von mttr_gain.

Nach der Kalibrierung spielen Sie die Formel mit 50+ historischen Vorfällen durch. Vergleichen Sie die Gewinner mit der aktuellen manuellen Entscheidungspraxis des Teams. Ist die Abweichung zu groß, sind die Gewichte auf ein fremdes Risikoprofil kalibriert.

Nehmen Sie genügend historische Fälle, damit seltene Kaskaden nicht aus der Bewertung verschwinden. Für eine ernsthafte Entscheidung verwenden Sie 50+ Vorfälle: Dies ist die Untergrenze, bei der eine seltene Kaskadenklasse (mit Häufigkeit ~1 von 25 Vorfällen) in der Stichprobe mindestens zweimal vorkommt und early_signal von einem Zufallstreffer unterschieden werden kann. Eine kleinere Menge verwenden Sie nur für Smoke-Tests.

Was bedeutet „Daten-Drift" in diesem Kontext. Drift – die Desynchronisation von Zeitskalen und Identifikatoren in den Vorfallquellen. Sind die Zeitachsen in den Quellen nicht ausgerichtet, kann Qwen Code eine post-hoc-Beobachtung als Frühsignal deuten. Daher führen Sie vor der Bewertung drei Schritte aus: Deduplizierung, Normalisierung der Zeitstempel und Zuordnung der Ereignisse zu einer einheitlichen Vorfall-ID.

In Ihrem Projekt wird die Bewertung ausgefertigt 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. Das ausführbare Gegenstück auf Lerndaten befindet sich in examples/shadow-auction/README.md.

Die Auktion verwandelt die Bewertung in eine gesteuerte Verteilung des begrenzten Kontextbudgets.

Schlecht:

> Die Heuristik „Bereitschaftsdienst ASAP im Slack – Severity auf P1 anheben" wurde direkt in requirements.md als verbindliche Anforderung aufgenommen.

Problem: Eine ungeprüfte Beobachtung wird ohne Belege zum Vertrag. Und erzeugt falsche P1 bei jedem „ASAP" im Chat.

Gut:

> Dieselbe Heuristik ist als Schattenspezifikation shadow.slack.asap_urgency mit Score 0.55 und Status review ausgefertigt: Der Wert liegt über der Ablehnungsschwelle reject_threshold=0.40, aber unter der Annahmeschwelle keep_threshold=0.70, daher geht der Kandidat in die manuelle Revision, nicht in die formale Spezifikation.

Wie der Ablauf funktioniert. Qwen Code sortiert die 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 klassifiziert:

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

Gewinner werden nur dann automatisch aufgenommen, wenn sie die obere Schwelle überschreiten. Strittige gehen in die manuelle Revision. Aussortierte bleiben nicht in einer Grauzone. Dieses Schema schützt QWEN.md vor Aufblähung. Selbst eine plausibel wirkende Nuance verliert, wenn ihr Vorhersagewert unter den Kosten des Prompt-Platzes liegt.

In Ihrem Projekt wird die Auktionsentscheidung ausgefertigt 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. Auf den Lerndaten erledigt diesen Schritt examples/shadow-auction/README.md.

Verwandeln Sie Gewinner in versionierte Blöcke von Few-Shot-Beispielen in QWEN.md, anstatt sie einfach am Ende der Datei anzuhängen. Jeder Block erhält:

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

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

Entfernen Sie minderwertige Kandidaten explizit. Schicken Sie sie in quarantine mit Begründung, Überprüfungsdatum und Verweis auf die Berechnung. Lassen Sie sie nicht spurlos aus der Historie verschwinden. Dies ist wichtig, um Entscheidungen anzufechten: Ändert sich nach einem Monat die Alarmierungsrichtlinie oder die Failover-Architektur, kann eine zuvor abgelehnte Schattenspezifikation ohne erneutes Sammeln der Rohdaten wieder in die Auktion gegeben 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: Dies ist der Wert, den examples/shadow-auction/scripts/score.py auf 20 historischen Vorfällen aus data/incidents.jsonl mit den Default-Gewichten 0.5/0.3/0.2 − 0.4 ausgibt. Abgleich mit der Referenz – examples/shadow-auction/outputs/scorebook.example.json.

Das Bewertungsjournal ist das Wirtschaftsjournal der Schattenspezifikationen. Darin werden gemeinsam Seed-Daten, Bewertungsformel, Schwellen, Budget, Kandidatenversionen und Entscheidungsprotokoll gespeichert.

Ohne Bewertungsjournal wird die Auktion schnell zur Autoritätsdebatte. Ein erfahrener Ingenieur kann seine Lieblingsheuristik durchdrücken, und Qwen Code erhält widersprüchliche Few-Shot-Beispiele. Hier ist es sinnvoll, einen weiteren Begriff einzuführen. Anti-Goodhart – Schutz vor der Optimierung einer Kennzahl zulasten des Sinns. Ein reproduzierbares Journal bietet drei Möglichkeiten: die Ergebnisse nach einer Gewichtsänderung neu zu berechnen, zu prüfen, welche Vorfälle den Sieg beeinflusst haben, und eine echte Verbesserung von einer Goodhart-Falle zu unterscheiden.

Im SDD-Kontur halten Sie diese Datei neben dem Speicher und den konstitutionellen Beschränkungen des Projekts. In Spec Kit eignet sich für solche dauerhaften Regeln .specify/memory/constitution.md als Schutzschicht gegen Drift (GitHub Spec Kit).

Vollständiger Track: Schwellenkalibrierung

Die Gewichte der Auktionsformel, die Schwellen keep/reject und die Signale zur Überarbeitung der Gewichte sind in Anhang D, Abschnitt D.2 ausgelagert. Beim ersten Durchgang wird der Abschnitt nicht benötigt: ein angenommener und ein abgelehnter Kandidat mit Default-Gewichten genügen.

Beispiele und Anwendung

Beispiel: Im Projekt zur automatischen Triage für appointments-api beschreibt der Kandidat shadow.p0.voice_handoff eine Situation. Bei P0 schreibt der Bereitschaftsdienst keine lange Chat-Nachricht, sondern initiiert sofort eine Sprachübergabe (Handoff) zwischen Bereitschaftsdienst (on-call) und Service-Owner.

Auf 20 historischen Vorfällen aus data/incidents.jsonl ergab dieses Merkmal einen Score von 0.727: hoher MTTR-Gewinn (0,7541), sicheres Frühsignal (1,0), enge Abdeckung (0,25) und null falsche Eskalationen. In fünf Fällen verkürzte es die Zeit bis zum Hinzuziehen der zweiten Schicht. Falsche Eskalationen erzeugte der Kandidat kaum, weil er nur bei bestätigtem P0 und Risiko einer Transaktionskaskade angewendet wurde.

Dieser Kandidat wird zum Gewinner. In QWEN.md landet er jedoch mit einer engen Anwendungsbedingung. Qwen Code soll den Sprachkanal nicht für ein gewöhnliches P2 empfehlen, wo eine asynchrone Textspur wichtiger ist als die Geschwindigkeit des Anrufs. Der praktische Wert liegt hier nicht im bloßen Fakt „anrufen", sondern in der frühen Erkennung der Situation, in der die 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-Gewinn und ein merklicher Anteil falscher Eskalationen ziehen die Bewertung ins Minus. Rot wurde in Dashboards häufig als visueller Akzent verwendet, entsprach jedoch weder dem Konsequenzradius, der SLO-Budget-Brenngeschwindigkeit noch dem tatsächlichen Eskalationsniveau.

Diese Schattenspezifikation erzeugte eine dreifache negative Wirkung:

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

Schicken Sie sie mit Begründung high_false_escalation, Überprüfungsdatum und Rückkehrbedingung in Quarantäne. Zuerst ändert das Team die Visualisierungsrichtlinie der Alarme. Dann spielt es den Kandidaten erneut durch das Bewertungsjournal.

Ein seltenes physisches Signal kann gewinnen, wenn die Kosten des Übersehens deutlich über den Kosten der Prüfung liegen. Beispielsweise ist shadow.dc.burn_smell_power_risk nur auf Vorfälle mit Vor-Ort-Beobachtung (onsite) im Rechenzentrum anwendbar. Seine coverage ist niedrig, aber early_signal ist hoch: Brandgeruch oder Überhitzung treten manchmal auf, bevor das Strommonitoring eine Degradation zeigt.

Ein solcher Kandidat darf nicht zur Universalregel werden. Sonst wird er zum giftigen Lärm für Cloud-Vorfälle ohne physischen Zugang. Die korrekte Aufnahmeform ist ein seltenes Few-Shot-Beispiel mit drei Begrenzern: harter Kontext, expliziter Risikohinweis und Anforderung, das Signal über einen Vor-Ort-Operator zu bestätigen.

flowchart TD
A[Kapitel 6. Auswahl von Schattenspezifikationen]
A --> B[Interviews / Post-Mortems / Incident-Historie]
B --> C[Extraktion von Schattenkandidaten]
C --> D[Normalisierung Kontext / Merkmal / Wirkung]
D --> E[Retro-Test mit 50+ Fällen über 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 Revisionsdatum]
J --> L

Zusammenfassung

Die Auktion der Schattenspezifikationen macht informelle Nuancen steuerbar. Jeder Kandidat erhält die Struktur Kontext → Merkmal → beobachtete Wirkung, wird auf historischen Vorfällen bewertet, konkurriert um das begrenzte Budget – und wird entweder ein versioniertes Few-Shot-Beispiel in QWEN.md oder wandert mit prüfbarer Begründung in Quarantäne.

Die zentrale Disziplin des Prozesses ist, glänzenden Geschichten ohne Bewertungsjournal nicht zu vertrauen. Seed-Daten, Formel, Schwellen und Entscheidungsprotokoll müssen es erlauben, das Ergebnis zu reproduzieren und bei veränderter Infrastruktur anzufechten. Das nächste Kapitel überführt diese Logik in das Specification Gateway (Specification CI), in dem die Spezifikation zum ausführbaren Artefakt wird.

Artefakte und Fertigkeitskriterien

Der vollständige Track ergänzt .specify/memory/shadow-candidates.yaml im Format Kontext → Merkmal → Wirkung, .specify/memory/shadow-scorebook.json mit Formel und Gewichten, .specify/memory/shadow-auction.json mit Entscheidungen winner/disputed/rejected und einen versionierten Block des Few-Shot-Beispiels oder einen Quarantäne-Eintrag. Betrachten Sie ihn als fertig, wenn jede Schattenspezifikation source_ref, scope, risk und next_review besitzt, die Bewertung reproduzierbar berechnet wird (ohne manuelle Nachberechnung) und Kandidaten bei Änderung der Gewichte, des Budgets oder der Vorfallslasse überprüft werden.

Übung

1. Spielen Sie die Auktion auf den Lerndaten durch: 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 liefert 0 Zeilen; unter den Bewertungen gibt es mindestens einen Kandidaten mit score >= 0.70 und mindestens einen mit score < 0.40.*
2. Führen 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 aus. *Erwartung: out/auction.json und out/quarantine.json stimmen mit den Referenzen in outputs/ überein; in out/quarantine.json gibt es mindestens einen Eintrag mit explizitem reason und return_condition.*
3. Ändern Sie das Gewicht der Strafe für falsche Eskalationen von 0.4 auf 0.8, berechnen Sie scorebook.json neu und halten Sie die Verschiebung in capstone/README.md fest. *Erwartung: In capstone/README.md ist eine Zeile „bei verdoppelter Strafe für falsche Eskalationen wechselte Kandidat <id> von keep zu quarantine" vermerkt; in derselben Zeile steht, welche Formelkomponente im neuen Gewicht dominant wurde.*

Kontrollfragen

1. Worin unterscheidet sich eine Schattenspezifikation von einer vollwertigen Anforderung und warum darf sie diese nicht ersetzen?
2. Warum sollte ein Few-Shot-Beispiel in QWEN.md eine Überprüfungsfrist haben?
3. Woran erkennt man, dass eine Heuristik zur operativen Folklore geworden ist?
4. Der Bereitschaftsdienst verlangt, in QWEN.md die Regel „wenn im Slack das Wort ASAP fällt – Severity anheben" aufzunehmen. Wie führen Sie diese durch die Auktion der Schattenspezifikationen, ohne sofort abzulehnen?