raichominev/concilium — plattformübergreifende adversarial Über…

Concilium — plattformübergreifende adversarial Überprüfung

Ein zweites, anderes Modell prüft Behauptungen (des Benutzers oder des Systems) adversarial. Unterschiedliche Modellabstammung bedeutet unterschiedliche blinde Flecken – darin liegt der Wert. Der Prüfer SCHLÄGT vor; die aufrufende Sitzung RATIFIZIERT. Nie zulassen, dass die Sicherheit einer Seite als Ersatz für Belege dient.

Entwickelt für die Orchestrierung durch Claude Code – Opus 5 und Fable 5 sind beide erstklassige Ratifikationssitze (bei einem blinden Vorhersagebenchmark zu Ergebnissen messbar gleichwertig; jedes Claude-Modell kann die Schleife steuern, aber der Ratifikator sollte eines der beiden sein). Die GPT-Seite (sol/terra/5.5 über codex) übernimmt die unabhängige Untersuchung und mechanische Ausführung – und dieser familienübergreifende Sitz ist tragend: Er erwischt messbar das, was gleichfamilige Sitze gemeinsam übersehen.

Voraussetzungen (einmal pro Umgebung prüfen)

1. codex login status → muss "Logged in using ChatGPT" anzeigen (Abonnement-OAuth – ein API-Schlüssel wird NICHT benötigt und ein Abonnement kann NICHT als solcher verwendet werden; Proxy-/Router-Brücken nicht versuchen).

2. Verfügbare Modelle entdecken: codex debug models oder ~/.codex/models_cache.json. Falls ein Modell mit "requires a newer version of Codex" fehlschlägt, codex update ausführen und wiederholen.

3. Bei erster Nutzung in einer neuen Umgebung den Kalibrierungs-Bootstrap ausführen (references/setup.md), bevor Befunden vertraut wird: einen bekannten Wahrheitstest, dann eine einfache echte Aufgabe, dann (optional) einen direkten Vergleich, um die Stufen-Modelle auszuwählen.

4. Kimi-Sitz – EXPERIMENTELL und nur auf Wunsch; niemals Teil einer Standardrunde. Nur hinzufügen, wenn der Benutzer explizit nach einer dritten Familie fragt. Zwei Transporte, jeder mit eigenem Wrapper hier:

   • Kimi Desktop (Windows). scripts/concilium-review-kimi.ps1 steuert den gebündelten Daimon-Runner der App unter eigenem Electron. Erfordert installierte Desktop-App und Anmeldung.
   • Kimi Code CLI (Linux/macOS/Windows). scripts/concilium-review-kimi.sh steuert das plattformübergreifende, MIT-lizenzierte CLI – headless kimi -p plus Device-Code-OAuth, also geeignet für Container oder Wegwerf-VM (funktionierendes Beispiel: references/isolated-guest-vmware.md). ⚠ Der Druckmodus genehmigt standardmäßig jeden Tool-Aufruf, daher ist Isolation dort Vorbedingung, nicht Vorsichtsmaßnahme. ⚠ Immer --model übergeben: Der CLI-interne Standard ist eine ältere Generation als das Flaggschiff und nichts in der Ausgabe benennt es.

   Kalibriert, aber unzuverlässiger als codex und schwächer in der Isolation: Pfade, Modelle, Sandboxing und die Einschränkungen stehen in references/setup.md und Stolpersteinen #18–21.

Stufenmatrix (Standards sind aktuelle Modelle – pro Installation überschreibbar)

Stufe	Standard	Aufwand	Verwendung für
Research	Flaggschiff (z. B. gpt-5.6-sol)	max	Offene Überprüfungsrunden, adversarial Verifikation
Mechanical	Vorheriges Flaggschiff (z. B. gpt-5.5)	medium	Bekannte Behauptung mit einer Untersuchung prüfen
Runner	Günstige Stufe (z. B. gpt-5.6-terra)	low	Ausführen und berichten: Skript laufen lassen, Import überwachen

Research-Stufen-Wrapper verwenden standardmäßig max für jeden Sitz. Aufwandsvokabulare unterscheiden sich und es lohnt sich, sie genau zu kennen: codex akzeptiert none · minimal · low · medium · high · xhigh · max (gemessen – die API lehnt alles andere ab und benennt das Enum), der Kimi-Sitz akzeptiert low · high · max.

Aufwand ist kein Ersatz für eine zweite Familie – gemessen, mit Kontrolle. Sechs Läufe eines Sitzes (gpt-5.6-sol) über das gleiche 14-Elemente-Vorhersagepaket, bei low/medium/high/xhigh/max plus einer Wiederholung mit gleichem Aufwand: Zwei Läufe mit GLEICHEM Aufwand deckten 10/14 ab, während Paare mit unterschiedlichem Aufwand durchschnittlich 8,9 erreichten und dies nie übertrafen; das gesamte Sechs-Lauf-Ensemble erreichte ebenfalls nur 10/14, gleich dem Rauschpegel von zwei Läufen und gleich einem codex+kimi-Paar. Die Genauigkeit war nicht monoton im Aufwand (high 9, max 9, xhigh 7, medium 7, low 7), während die Wandzeit um das 8-Fache wuchs (21s → 166s). Vier Elemente wurden von jedem Lauf bei jedem Aufwand verfehlt – und der familienübergreifende Sitz erwischt zwei davon. Unterschiedlicher Aufwand resampelt die gleichen blinden Flecken; eine andere Abstammung verschiebt sie. Wenn Sie Abdeckung wünschen, fügen Sie eine Familie hinzu, nicht Rechenleistung. -Mechanical ist die bewusste Herabstufung und bleibt bei medium.

Runner-Aufgaben sind KEINE Überprüfungen – den Wrapper überspringen und codex direkt aufrufen: codex exec -m <billig-modell> -c model_reasoning_effort=low [-s read-only unless it writes] "<aufgabe>" < /dev/null Bei direkten nicht-interaktiven Aufrufen immer stdin schließen (bash < /dev/null; PowerShell $null | codex …) – ein offenes, nicht-TTY-stdin blockiert codex für immer mit "Reading additional input from stdin...", und der verwaiste Prozess überlebt das Timeout der Eltern-Shell (Stolperstein #10; die Wrapper sind immun – sie pipen über stdin).

Eine Überprüfung ausführen

Die gebündelten Wrapper verwenden. Sie laden den gemeinsamen Überprüfungsvertrag aus references/contract.md (single source of truth – Falsifikationsuntersuchung, alternative Erklärung, Einschränkung, Befundvorschlag, Schema/Kodierungsregeln; den Vertrag dort bearbeiten, niemals in den Skripten) und fügen Herkunftsstempel hinzu. Beide Wrapper sind funktional identisch; je nach Plattform wählen:

Linux / macOS (bash):

• Claim: scripts/concilium-review.sh claim "<claim>"
• Diff: scripts/concilium-review.sh diff [base-branch]
• Konfiguration über Umgebungsvariablen: MODEL, EFFORT, MECHANICAL=1 (mechanische Stufe), REPO_DIR, PROJECT_RULES (Pfad zur Regeln-Datei).
• Erste Verwendung nach Klon: chmod +x scripts/concilium-review.sh.

Windows (PowerShell 5.1+):

• Claim: powershell -ExecutionPolicy Bypass -File scripts/concilium-review.ps1 -Claim "<claim>" [-Mechanical] [-RepoDir <path>] [-ProjectRules <file>]
• Diff: ... -Diff [-Base <branch>] – prüft den Arbeitsverzeichnis-Diff von -RepoDir.

Kimi als dritte Familie – EXPERIMENTELL, nur auf Wunsch. Nicht Teil einer Standardrunde; nur hinzufügen, wenn der Benutzer nach einer dritten Familie fragt. Zwei Wrapper, gleicher Vertrag und gleiche fünf Blöcke: concilium-review-kimi.sh (plattformübergreifendes CLI, konfiguriert über Umgebungsvariablen – MODEL ist dort obligatorisch) und concilium-review-kimi.ps1 (Windows Desktop-Runner).

Der Desktop-Wrapper akzeptiert dieselben Parameter -Claim/-Diff/-RepoDir/-ProjectRules/-PriorRounds, plus -Model (Standard k3-agent), -Effort (low|high|max) und -RawPrompt (ohne Vertrag, für Kalibrierungssonden). Zwei sitzspezifische Unterschiede, beide gemessen: CLAUDE.md-Auto-Brückenschaltung ist hier STANDARDMÄSSIG AUS – die Injektion tötet zuverlässig den Lauf mit einer bloßen Connection error., daher ist sie über -AutoRules aktivierbar; stattdessen -ProjectRules <file> verwenden, um dem Prüfer Kontext zu geben. Und niemals seinem Exit-Code vertrauen – er beendet mit 0 bei diesem Fehler, also die fünf Blöcke prüfen. Mehrzeilige Prompts müssen durch diesen Wrapper gehen; ein direkter kimi-daimon --prompt von bash bekommt sein argv verstümmelt (Stolpersteine #18–19).

Dieser Sitz hat keine Sandbox – ihm eine Wegwerf-Kopie geben. -SandboxFrom <dir> kopiert den Baum in ein Wegwerfverzeichnis (ohne .git, Virtualenvs und geheimnisartige Dateien), führt den Agent dort aus, gibt genau aus, was er erstellt/geändert/gelöscht hat, und löscht die Kopie, außer bei -KeepSandbox. Standardmäßig verwenden. Klarmachen, was es bringt: workDir ist keine Grenze – ein Kanarienvogel außerhalb wurde über absoluten Pfad gelesen und wörtlich zurückgegeben (Stolpersteine #20) – also ist dies Schadensradius-Kontrolle und Prüfpfad, keine Eindämmung. Wenn Material auf der Maschine den Anbieter nicht erreichen darf, auf Betriebssystemebene isolieren (separates Konto mit ACLs oder eine VM).

Für eine blinde Runde ist das Risiko dieser Porosität eher Kontamination als Schaden: Ein Agent, der in den echten Baum wandert, kann die Antwort finden, und die Runde hört still auf, blind zu sein. -WatchPaths <a,b,c> hinzufügen – es macht Snapshots der NTFS-Zugriffszeiten für das, was ungelesen bleiben muss (das echte Repository, das Ergebnisprotokoll, der Antwortschlüssel) und meldet alles, was während des Laufs gelesen wird. Validated against a known escape in both directions; read pitfalls #21 before trusting it, including why an enumeration-based version of the same check reported "clean" on a run that had demonstrably escaped.

Operational rules (each one is a measured failure — the why is in references/pitfalls.md):

• Run in background with a full ~10 min timeout from the FIRST call. Real reviews take 5–15+ min at high effort; a foreground timeout kills them mid-probe.
• Prefer a fresh session over resuming a timed-out one. Long resumed chains hit context compaction — the reviewer's early careful reading gets lossy-summarized before the final, consequential step.
• Never bare-resume. codex exec resume silently resets model AND sandbox to the user's config.toml defaults. If you must resume (or want to switch models mid-session), re-pin everything: codex exec resume -m <model> -c sandbox_mode="read-only" -c model_reasoning_effort=<tier> <session-id> - Flags go BEFORE the positional session id. The key is sandbox_mode — -c sandbox=... is silently ignored, and there is no -s flag on resume. Cross-model resume retains context.
• The reviewer is a full agent, not a chatbot — read-only sandbox blocks file writes, not read commands or DB SELECTs. Everything it reviews goes to the second model's provider.
• Watch progress live, don't wait blind — and monitor the right stream. The contract (rule 9) makes the reviewer emit STATUS: one-liners as it works, and codex writes progressively — but the streams split (verified live): with 1> out 2> err, the final five blocks land on stdout while the streaming transcript (banner, STATUS lines, tool calls) goes to stderr. Point a tail/monitor at stderr for progress + failure signatures; read stdout for the verdict. Caveat: PowerShell 1>/2> redirects write UTF-16 — decode accordingly (or redirect through a UTF-8-forcing step) before grepping.
• A blind round needs structural isolation, not an instruction. When the round must be unprimed (a blind eval, a framing-critical blind-first pass per request-template), run the reviewer in a clean directory with auto-rules bridging OFF (-NoAutoRules / NO_AUTO_RULES=1): a model carrying project context and told to "answer from the packet alone" measurably still uses that context (pitfalls #16–17).

Ratifikationsprotokoll (Aufgabe der aufrufenden Sitzung)

Der Prüfer gibt fünf Blöcke zurück: PROBE / ALT / CAVEAT / VERDICT-PROPOSAL / PHASE-LOG. Vor der Weiterleitung oder Handlung:

1. Die eigentliche Untersuchung lesen (die Abfragen/Befehle), nicht nur die Zusammenfassung in Prosa.
2. Extremale Ergebnisse sind eine Stolperfalle: 0% oder 100% bei einem ersten Versuch bedeuten meist einen falschen Join-Schlüssel, falschen Geltungsbereich oder falsche Tabelle – keine Entdeckung. Den tragenden Schritt der Untersuchung selbst verifizieren, bevor man sie akzeptiert.
3. Meinungsverschiedenheiten auf den Geltungsbereich prüfen: Zwei Untersuchungen können beide faktisch richtig sein, aber in unterschiedlichem Geltungsbereich (eine Tabelle vs. DB-weit, eine Quelle vs. alle Quellen). Den Geltungsbereich benennen, bevor Zahlen verglichen werden.
4. Widerlegt/veraltet/unvollständig unterscheiden. "Die Zahlen weichen heute ab" bedeutet nicht, dass die Behauptung zum Zeitpunkt ihrer Erstellung falsch war – Verlauf/Zeitstempel prüfen, bevor "widerlegt" gesagt wird.
5. Das endgültige Befund-Tag selbst zuweisen: [V-code] (gegen Quelle verifiziert, file:line zitieren) / [V-db] (schreibgeschützte Abfrage, zitieren) / [V-probe] (wiederausführbares Skript) / [C] (ungeprüft) / [X] (widerlegt – nennen, was es ersetzt). Der Vorschlag ist Eingabe, nicht die Antwort.
6. Zustimmung nach Abstammung gewichten. Bestätigung derselben Familie (ein Claude-Sitz, der einem Claude-Orchestrator zustimmt) ist schwache Evidenz – Sitze derselben Abstammung teilen messbar falsche Antworten, bis hin zur unabhängigen Produktion identischer falscher Schlussfolgerungen. Eine bestätigende oder widerlegende Aussage einer anderen Familie wiegt schwerer als jede Anzahl von Stimmen derselben Abstammung; einen Streit niemals durch Mehrheit über Sitze entscheiden, die eine Abstammung teilen. Eine dritte Familie (Moonshot) ist als experimenteller, nur auf Wunsch verfügbarer Sitz verfügbar; ein dritter Sitz bringt nichts, es sei denn, er ist unabhängig, also nach Familie gewichten, nicht nach Kopfzahl – und beachten, dass ein einstimmiges Gremium einfach bedeuten kann, dass das Element einfach war (setup.md).

Die Concilium-Schleife (iterative Runden)

Ein einzelner Überprüfungsdurchgang ist oft ausreichend. Aber wenn die Untersuchung des Prüfers eine Lücke hat oder Sie (der Orchestrator) dem Vorschlag aus vertretbaren Gründen widersprechen, ist ein Austausch kein concilium – ein Rat berät. Die Schleife führt Überprüfungsrunden durch, bis der Befund konvergiert oder der Streit als echt erwiesen ist. Diese Schleife wird von Ihnen, der aufrufenden Claude-Sitzung, orchestriert – sie ist ein Protokoll, kein Skript (der Ratifikationsschritt ist Ihr Urteil; nichts kann ihn automatisieren).

Jede Runde:

1. Eine Überprüfung ausführen (der Wrapper) → die fünf Blöcke erhalten → gemäß obigem Protokoll ratifizieren.
2. Das Ergebnis der Runde entscheiden und handeln:

Ergebnis	Bedingung	Aktion
Konvergiert	Sie haben den tragenden Schritt der Untersuchung verifiziert und er hält	STOP – das endgültige Tag ausgeben.
Streit	Die Untersuchung hat eine Lücke, falschen Geltungsbereich oder Sie haben einen spezifischen, beleggestützten Einwand	Die PROBE dieser Runde + Ihren Einwand in eine Runden-Datei schreiben; die nächste Runde mit -PriorRounds/PRIOR_ROUNDS ausführen, die darauf zeigt.
Trocken	Eine Runde fügt keine neuen prüfbaren Belege hinzu – der Prüfer bekräftigt erneut oder sagt (in CAVEAT), dass es keinen neuen Weg gibt	STOP – als [C]/[POLICY] mit der offenen Frage an den Eigentümer eskalieren. Dies ist der Anti-Oszillationsschutz.
Obergrenze	Rundenlimit erreicht (Standard 3) ohne Konvergenz	STOP – den Stand präsentieren und eskalieren; ein echter Streit ist ein Befund, kein Fehler.

Entwurfsregeln (sie folgen direkt aus den Stolpersteinen):

• Neue Sitzung pro Runde – niemals eine Wiederaufnahmekette. Die Schleife ist genau die "lange Kette", vor der Stolperstein #3 warnt; Kontext über die -PriorRounds-Datei nach vorne tragen, nicht über codex exec resume. Jede Runde startet sauber und sieht nur eine kompakte Zusammenfassung dessen, was bereits versucht wurde.
• Jede Runde MUSS einen NEUEN Belegpfad hinzufügen. Der Vertrag (Regel 8) erzwingt dies auf der Prüferseite; Sie erzwingen es auf Ihrer Seite – ein Einwand ist nur eine Runde wert, wenn er durch Belege gestützt wird oder auf eine konkrete, prüfbare Lücke hinweist. "Ich bin nicht überzeugt" ist keine Runde.
• Ratifikator bleibt fest (Sie / Fable); der Prüfer kann die Stufen senken, wenn der Streit enger wird. Runde 1 auf der Research-Stufe; sobald es auf eine mechanische Frage heruntergebrochen ist, die Mechanical-Stufe verwenden. Aber die Stufenänderung muss dokumentiert werden (in der Runden-Datei), und der Geltungsbereich darf sich nicht ungewollt ändern.

Runden-Datei-Schema

Die -PriorRounds-Datei ist eine einfache Textdatei (kein Markdown, kein YAML – das Merkmal ist, dass sie für einen Menschen lesbar und maschinell prüfbar ist, ohne dass der Prüfer sie parsen muss):

== ROUND 1 (research, gpt-5.6-sol, max) ==
PROBE:
<die wörtliche Untersuchung aus dem PROBE-Block>

EINWAND:
<eine präzise, beleggestützte Aussage, warum dies nicht ausreicht> (vom Ratifikator geschrieben, nicht vom Prüfer)

ERGEBNIS: DISPUTE

== ROUND 2 (mechanical, gpt-5.5, medium) ==
PROBE:
<Einschränkung der Untersuchung aus Runde 1 durch breitere Stichprobe>

EINWAND:
(leer – wenn der Ratifikator zustimmt, dass der Streit beigelegt ist; stattdessen ERGEBNIS: CONVERGED)

ERGEBNIS: CONVERGED

Das Format ist bewusst einfach: Es ist ein menschliches Protokoll, das die Prüferschleife informiert, ohne von ihr geparst werden zu müssen. Der Wrapper hängt die Runden-Datei (unverändert, als wörtlichen Text) an den Prompt des Prüfers an, sodass der Prüfer sieht, was bereits versucht wurde. Die Runden-Datei ist nicht der Vertrag; der Vertrag ist die unveränderte Datei in references/contract.md.

Referenzen

• Vertrag (Überprüfungsvertrag — single source of truth)
• Einrichtung & Kalibrierung
• Stolpersteine (jeder operative Fehler, der gemessen wurde)
• Isolierte Gast-VM – funktionierendes Beispiel
• Benchmark-Ergebnisse & Methodik

Jede Referenz ist ein separates Dokument, das mit demselben Maß an Strenge gepflegt wird. Wenn Sie den Skill bearbeiten, die Referenzen entsprechend aktualisieren. Wenn ein Stolperstein durch ein Update behoben wird, in den Stolpersteinen dokumentieren, wann und wie.

Lizenz

MIT — siehe LICENSE