Critic als CI-Job mit Pflicht-Check #9

Folgt auf #6. Spec: docs/2026-11-13-befund-ledger-critic-verdikt-design.md, Abschnitt „Bekannte Grenzen“, Punkt „Orchestrator-Vertrauen bleibt“.

Ist-Zustand: Seit #6 validiert der Kern die rohe Critic-Ausgabe selbst. status ist kein Eingabefeld, und das Verdikt wird aus dem Ledger abgeleitet. Der Critic läuft aber weiterhin im Orchestrator: Dieser reicht die rohe Ausgabe an critic-verdict weiter und setzt selbst gh pr ready.

Risiko: Der Orchestrator könnte gültiges JSON ohne Befunde fabrizieren oder gh pr ready ohne accepted aufrufen. Kein Check auf GitHub würde das bemerken.

Vorschlag: Den Critic als CI-Job mit Pflicht-Check laufen lassen. Der Job ruft den Critic auf, leitet das Verdikt über den Kern ab und meldet es als Check-Status. Der Auto-Merge hängt dann an diesem Check, statt an einem Draft-Status, den der Orchestrator setzt.

Offene Fragen:

• API-Schlüssel und Kosten in der CI.
• Frischer Kontext und Zugriff auf Spec und Diff im Job.
• Umgang mit not-run (Retry im Job, danach roter Check).
• Verhältnis zur Draft-Bindung REQ-BIND-1 bis 5.

Das ist eine Spec-Änderung: Sie muss vor der Umsetzung abgenommen werden.