Das Protokoll existiert, weil die Abstimmung es erzeugt hat.
Keine Automatisierung und keine Magie: Die Argumentation ist das Artefakt. Wenn Claude dem Kirat-Rat eine Frage vorlegt, beziehen ChatGPT und Gemini unabhängig Position, Claude ergänzt seine eigene, und sie stimmen ab. Aufruf und Ergebnis enthalten die Frage, die Optionen, jede Stimme, die Entscheidung, wie sie zustande kam, und die Gegenstimme. Die Argumentation wird festgehalten, während sie stattfindet, nicht Wochen später rekonstruiert.
Fünf aufgezeichnete Läufe, einer pro Tool.
Echte Aufzeichnungen von Kirats Tools, entstanden am 13. Oktober 2026 mit der Version, die Sie kaufen, mit Fragen und Aufgaben wie Ihren. Wählen Sie ein Tool und sehen Sie dem Rat bei der Arbeit zu. Dies ist eine Aufzeichnung: Nichts, was Sie hier anklicken, ruft ein Modell auf, und nichts verlässt diese Seite. Der Chat ist zur Veranschaulichung formuliert und gibt nur das aufgezeichnete Ergebnis wieder; was Claude an Kirat geschickt hat und was zurückkam, steht unverändert unter „Im Hintergrund“.
Tool auswählen
Lass Kirat darüber abstimmen: Sollen wir unser Abrechnungsmodul jetzt in einen eigenen Service auslagern oder zuerst seine Grenzen innerhalb des Monolithen härten?
kirat_voteRat befragt
Der Rat hat entschieden (einstimmig 3:0): Zuerst die Grenzen im Monolithen härten.
Alle drei Positionen, meine eingeschlossen, zeigen in dieselbe Richtung. Jede kommt mit Begründung.
Im Hintergrund
kirat_voteWas Claude an Kirat schickt
Frage: Sollen wir unser Abrechnungsmodul jetzt in einen eigenen Service auslagern oder zuerst seine Grenzen innerhalb des Monolithen härten?
Gesendeter Kontext: Team aus 8 Engineers. Ein TypeScript-Monolith mit etwa 60.000 Zeilen, eine Postgres-Datenbank, mehrere Deployments pro Tag. Das Abrechnungsmodul ändert sich jede Woche und hat 5 der letzten 8 Produktionsvorfälle verursacht, meist dadurch, dass andere Module direkt lesend und schreibend auf Abrechnungstabellen zugreifen. Niemand im Team hat ein verteiltes System in Produktion betrieben. Die Unternehmensleitung will innerhalb von zwei Quartalen weniger Vorfälle.
Optionen: Abrechnung jetzt in einen Service auslagern · Zuerst die Grenzen im Monolithen härten
Ergebnis des Rats
Aufgezeichnet am 13. Oktober 2026 mit kirat_vote auf der Standard-Aufwandsstufe; jede Sitzung dauerte unter 20 Sekunden und kostete unter zwei Cent. Fragen, Optionen und Kontext wurden auf Englisch gesendet und sind hier übersetzt, die Begründungen vollständig wiedergegeben. ChatGPT und Gemini antworteten teilweise auf Deutsch (Gemini viermal, ChatGPT einmal); diese Antworten stehen hier im Original, die übrigen sind aus dem Englischen übersetzt. Bei der Frage nach dem Free Tier unterlag Claude 2:1, und sein Einwand blieb im Protokoll. Die Konfidenzwerte sind jeweils die Selbsteinschätzung des Modells.
Lass Kirat diese Abrechnungsfunktion auf Korrektheit und Datenintegrität prüfen.
kirat_reviewRat befragt
Kirat hat 16 bestätigte Befunde gefunden (1 × kritisch, 11 × hoch, 3 × mittel, 1 × niedrig). Jeder Befund wurde von der jeweils anderen Modellfamilie gegengeprüft.
Fang mit denen oben in der Liste an; zu jedem gibt es einen Vorschlag zur Behebung.
Im Hintergrund
kirat_reviewWas Claude an Kirat schickt
Schwerpunkt: Korrektheit und Datenintegrität einer Abrechnungsfunktion
Gesendeter Code:
// billing/applyCredit.ts — billing module in the monolith (TypeScript, node-postgres)
import { pool } from '../db';
export async function applyCredit(customerId: string, invoiceId: string, creditCents: number) {
const inv = await pool.query('SELECT total_cents, status FROM invoices WHERE id = $1', [invoiceId]);
const balance = await pool.query('SELECT credit_cents FROM customers WHERE id = $1', [customerId]);
const available = balance.rows[0].credit_cents;
if (creditCents > available) throw new Error('Not enough credit');
const newTotal = inv.rows[0].total_cents - creditCents;
await pool.query('UPDATE invoices SET total_cents = $1 WHERE id = $2', [newTotal, invoiceId]);
await pool.query('UPDATE customers SET credit_cents = credit_cents - $1 WHERE id = $2', [creditCents, customerId]);
if (newTotal <= 0) {
await pool.query("UPDATE invoices SET status = 'paid' WHERE id = $1", [invoiceId]);
}
return newTotal * 1.19 / 100;
}
Ergebnis des Rats
- kritisch
Fehlende Datenbanktransaktion und Zeilensperre. Bei parallelen Anfragen kann es zu Race Conditions (z. B. Double Spending von Guthaben) und unvollständigen Updates im Fehlerfall kommen.
Behebung: Verwende einen Client aus dem Pool mit BEGIN/COMMIT und nutze SELECT FOR UPDATE, um Zeilen atomar zu sperren und zu aktualisieren.
- hoch
Die drei zusammengehörigen Updates werden nicht in einer Datenbanktransaktion ausgeführt. Schlägt die Abbuchung des Kundenguthabens oder die Statusänderung fehl, kann die Rechnung bereits reduziert sein, ohne dass das Guthaben korrekt belastet beziehungsweise der Status gesetzt wurde.
Behebung: Einen dedizierten Client aus dem Pool beziehen und alle Prüfungen sowie Updates zwischen BEGIN und COMMIT ausführen; bei jedem Fehler ROLLBACK verwenden.
- hoch
Die Rechnung wird erst gelesen und später mit einem absolut berechneten Wert überschrieben. Zwei parallele Aufrufe können denselben Ausgangswert lesen und sich anschließend gegenseitig überschreiben; beide Guthabenabbuchungen erfolgen dennoch, während nur eine Gutschrift vollständig in der Rechnung sichtbar bleibt.
Behebung: Die betroffene Rechnung innerhalb derselben Transaktion mit SELECT ... FOR UPDATE sperren oder den Betrag atomar per UPDATE ... SET total_cents = total_cents - $1 mit geeigneten Bedingungen ändern.
- hoch
Prüfung und Abbuchung des Kundenguthabens sind nicht atomar. Parallele Aufrufe können beide dieselbe verfügbare Deckung sehen und das Guthaben anschließend unter null reduzieren.
Behebung: Den Kundendatensatz transaktional sperren oder ein bedingtes UPDATE verwenden, etwa UPDATE customers SET credit_cents = credit_cents - $1 WHERE id = $2 AND credit_cents >= $1 RETURNING credit_cents, und genau eine zurückgegebene Zeile verlangen.
- hoch
Es wird nicht geprüft, ob die Rechnung dem angegebenen Kunden gehört. Dadurch kann Guthaben eines Kunden auf eine beliebige über invoiceId bezeichnete Rechnung angewendet werden.
Behebung: Rechnung und Kunde über die Eigentümerbeziehung abfragen und aktualisieren, beispielsweise mit WHERE invoices.id = $1 AND invoices.customer_id = $2; bei fehlender Übereinstimmung abbrechen.
- hoch
Der anzuwendende Kredit wird nicht auf den offenen Rechnungsbetrag begrenzt. Ist creditCents größer als total_cents, wird ein negativer Rechnungsbetrag gespeichert und überschüssiges Kundenguthaben verbraucht.
Behebung: Nur Beträge bis zum offenen Rechnungswert zulassen oder den tatsächlich verwendeten Betrag als min(creditCents, total_cents) bestimmen und ausschließlich diesen vom Kundenguthaben abbuchen.
- hoch
Negative, nicht ganzzahlige oder nicht sicher darstellbare Werte werden nicht abgewiesen. Insbesondere erhöht ein negativer creditCents-Wert den Rechnungsbetrag und zugleich durch die Subtraktion eines negativen Werts das Kundenguthaben.
Behebung: Vor Datenbankzugriffen Number.isSafeInteger(creditCents) && creditCents > 0 verlangen; Geldbeträge durchgehend als ganzzahlige Centwerte behandeln.
- hoch
Der gelesene Rechnungsstatus wird vollständig ignoriert. Damit kann Guthaben auch auf bereits bezahlte, stornierte oder anderweitig nicht mehr änderbare Rechnungen angewendet werden; ein bereits bezahlter Beleg kann dadurch negativ werden.
Behebung: Zulässige Ausgangsstatus explizit definieren und atomar in der UPDATE-Bedingung prüfen, beispielsweise AND status = 'open'. Bei keinem Treffer den Vorgang abbrechen.
- hoch
Zugriff auf balance.rows[0] und inv.rows[0] ohne Vorabprüfung. Wenn ein Kunde oder eine Rechnung nicht gefunden wird, stürzt die Anwendung mit einem Unhandled TypeError ab.
Behebung: Prüfe inv.rows.length und balance.rows.length vor dem Zugriff und wirf eine explizite Fehlermeldung.
- hoch
Fehlende Validierung für creditCents auf negative Werte. Ein negativer Wert hebelt die Prüfung (creditCents > available) aus und führt zu fehlerhaften Guthaben- oder Rechnungsanpassungen.
Behebung: Stelle sicher, dass creditCents eine positive Ganzzahl größer als 0 ist.
- hoch
Die Lesezugriffe und die drei Updates laufen außerhalb einer Transaktion und ohne Zeilensperren. Zwei gleichzeitige Aufrufe können beide die Guthabenprüfung bestehen und dasselbe Guthaben zweimal verbrauchen, und ein Absturz zwischen den Updates hinterlässt Rechnung und Guthabenstand inkonsistent.
Behebung: Alles in einer Transaktion auf einem einzigen Client ausführen, die Zeilen mit SELECT ... FOR UPDATE sperren und erst committen, wenn alle Updates erfolgreich waren.
- hoch
Die Funktion prüft nie, ob die Rechnung zum Kundenkonto gehört oder ob sie noch offen ist. Guthaben eines Kundenkontos kann auf die Rechnung eines anderen Kundenkontos angerechnet werden oder auf eine Rechnung, die bereits bezahlt ist.
Behebung: Die Rechnung mit WHERE id = $1 AND customer_id = $2 AND status = 'open' abfragen und mit einem Fehler abbrechen, wenn keine Zeile zurückkommt.
- mittel
Die Existenz von Rechnung und Kunde wird nicht geprüft. Bei unbekannten IDs führen Zugriffe auf rows[0] zu Laufzeitfehlern statt zu einem kontrollierten fachlichen Fehler; außerdem werden beide Abfragen unnötig ausgeführt, bevor dies auffällt.
Behebung: rowCount beziehungsweise rows.length für beide Abfragen prüfen und einen definierten Not-found-Fehler auslösen; die Prüfung in die Transaktion und möglichst in eine relationale Abfrage integrieren.
- mittel
Der Rückgabewert entspricht weder dem gespeicherten Centbetrag noch einer einfachen Umrechnung in die Hauptwährung: Er addiert pauschal 19 Prozent und verwendet Fließkommaarithmetik. Dadurch kann der Aufrufer einen steuerlich und rundungstechnisch anderen Wert erhalten als den tatsächlich gespeicherten Rechnungsrest.
Behebung: Den verbleibenden Betrag in Cent unverändert zurückgeben oder einen klar typisierten Rückgabewert definieren. Falls Steuerberechnung fachlich erforderlich ist, Steuersatz und Rundungsregel aus den Rechnungsdaten beziehen und mit Integer- oder Decimal-Arithmetik berechnen.
- mittel
Verwendung von IEEE 754-Gleitkomma-Arithmetik (newTotal * 1.19 / 100) für Finanzberechnungen. Dies führt zu Präzisions- und Rundungsfehlern.
Behebung: Rechne durchgehend in Cents mit Ganzzahlen (BigInt/Math.round) oder verwende eine Library für exakte Dezimalarithmetik.
- niedrig
Separierter UPDATE-Befehl für den Rechnungsstatus erzeugt unnötige Datenbank-Roundtrips.
Behebung: Führe die Aktualisierung von total_cents und status in einer einzigen UPDATE-Abfrage zusammen.
Gezeigt: jeder bestätigte Befund mit seiner Behebung, so wie die Mitglieder ihn geschrieben haben; die Begründung der Prüfer ist auf ihr Urteil gekürzt. Duplikate werden nicht zusammengeführt, ein Problem kann also mehrfach erscheinen, wenn mehrere Mitglieder es melden. Was die Mitglieder auf Deutsch geschrieben haben, steht hier im Original; was auf Englisch gesendet oder geschrieben wurde, ist hier übersetzt, Code-Kommentare ausgenommen.
Sammle mit Kirat Ideen, wie wir die Vorfälle in der Abrechnung in zwei Quartalen senken, ohne sie aus dem Monolithen herauszulösen.
kirat_brainstormRat befragt
Der Rat hat 15 Ideen gesammelt und jede anonym bewertet. Die drei stärksten:
- Datenbank-Firewall um die Abrechnungstabellen (17/20 Punkte)
- Ausführbare finanzielle Invarianten (17/20 Punkte)
- Vorfall-Replay als Bewährungsprobe vor jedem Release (17/20 Punkte)
Im Hintergrund
kirat_brainstormWas Claude an Kirat schickt
Thema: Ideen, um vom Abrechnungsmodul verursachte Produktionsvorfälle innerhalb von zwei Quartalen zu reduzieren, ohne es in einen separaten Service auszulagern
Gesendeter Kontext: Team aus 8 Engineers. Ein TypeScript-Monolith mit etwa 60.000 Zeilen, eine Postgres-Datenbank, mehrmals täglich deployt. Das Abrechnungsmodul ändert sich jede Woche und hat 5 der letzten 8 Produktionsvorfälle verursacht, meist weil andere Module direkt Abrechnungstabellen lesen und schreiben. Niemand im Team hat je ein verteiltes System in Produktion betrieben. Die Leitung will innerhalb von zwei Quartalen weniger Vorfälle. HARTE VORGABE: kein Neuschreiben des Abrechnungsmoduls. HARTE VORGABE: Die Feature-Arbeit an der Abrechnung geht jede Woche weiter.
Ergebnis des Rats
- 1
Datenbank-Firewall um die Abrechnungstabellen
Getrennte Postgres-Rollen für die Abrechnungs- und Nicht-Abrechnungs-Codepfade des Monolithen anlegen und der allgemeinen Anwendungsrolle direkte Schreibrechte auf Abrechnungstabellen entziehen. Alle Änderungen über eine kleine Zahl geprüfter Stored Procedures oder Transaktionsfunktionen leiten und zuerst vorübergehendes Audit-Logging einführen, um Aufrufer zu finden und zu migrieren, ohne die wöchentliche Feature-Arbeit anzuhalten.
- 2
Ausführbare finanzielle Invarianten
Eine kurze Liste von Invarianten — etwa unveränderliche finalisierte Rechnungen, ausgeglichene Ledger-Einträge, idempotente Erstellung von Belastungen und gültige Zustandsübergänge — als Datenbank-Constraints kodieren, wo das sicher ist, und andernfalls als geplante Prüfungen in Produktion. Dieselben Prüfungen in der CI gegen anonymisierte, produktionsähnliche Fixtures laufen lassen und so das Wissen aus Vorfällen in dauerhafte Stolperdrähte verwandeln statt in eine breite Ausweitung der Tests.
- 3
Vorfall-Replay als Bewährungsprobe vor jedem Release
Die fünf Abrechnungsvorfälle mit erfassten Query-Formen und bereinigten Zeilen in deterministische Replay-Szenarien umwandeln und verlangen, dass jede Änderung an der Abrechnung sie besteht. Generative Tests ergänzen, die Wiederholungen, doppelte Events, Transaktionsreihenfolgen und Teilausfälle rund um genau diese Szenarien permutieren, und damit gezielt das Umfeld der Fehler abdecken, statt eine erschöpfende Abdeckung des Monolithen anzustreben.
- 4
Die Abrechnungsgrenze im Schattenmodus durchsetzen
Als risikoärmere Mutation der Datenbank-Firewall die aktuellen Berechtigungen zunächst beibehalten, aber jede Abfrage, die Abrechnungstabellen berührt, mit Modul, Aufrufstelle und Transaktions-ID protokollieren. Nach vier Wochen unerwartete Schreibzugriffe zu CI-Fehlern machen und dann Modul für Modul zu Fehlern in Produktion; das ersetzt eine sofortige Umstellung der Berechtigungen durch eine gestufte Durchsetzung.
- 5
Schaltzentrale für den Schadensradius der Abrechnung
Riskante Abrechnungsfunktionen — nicht das ganze Modul — hinter serverseitige Kill Switches und prozentuale Rollouts legen, mit Dashboards, die auf Anomalien bei Rechnungen, Zahlungen und Abgleich ausgerichtet sind. Jedes wöchentliche Feature wird mit einem getesteten Abschaltpfad ausgeliefert, sodass das Bereitschaftsteam das neue Verhalten deaktivieren kann, ohne unabhängige Monolith-Deployments zurückzurollen oder Schemamigrationen rückgängig zu machen.
- 6
Postgres-Schema-Kapselung und Row Level Security
Isoliere Billing-Tabellen in ein eigenes Postgres-Schema (billing.*) und entziehe anderen DB-Rollen den direkten Schreib- und Lesezugriff. Module greifen nur über definierte SQL-Views oder gespeicherte Schnittstellen darauf zu. Das eliminiert die Hauptursache der Incidents direkt auf Datenbankebene.
- 7
Contract Testing und Shadow-Pipeline für Billing-Releases
Etabliere automatisierte Consumer-Driven Contract Tests für alle Billing-Schnittstellen in der CI-Pipeline. Ergänzend laufen Billing-Änderungen für kritische Berechnungen im Shadow-Modus ohne Seiteneffekte mit automatischer Differenzprüfung in Produktion.
- 8
Eine zweite Datenbank als Sicherheitsinstrument
Die weiche Annahme „eine Postgres-Datenbank“ bewusst brechen, indem eine schreibgeschützte Schattendatenbank hinzukommt, die per logischer Replikation gespeist wird, während die Abrechnung im Monolithen bleibt und die primäre Datenbank weiterhin als einzige beschrieben wird. Neue Lesezugriffe der Abrechnung und Abgleichsprüfungen gegen beide Datenbanken laufen lassen, die Ergebnisse vor der Freigabe vergleichen und die Schattendatenbank für forensische Abfragen nutzen, damit die Diagnose von Vorfällen die Produktion weder überlasten noch versehentlich verändern kann.
- 9
Striktes Module-Boundary Linting und Public API Facade
Führe ein Architektur-Linting via dependency-cruiser ein, das direkte Imports von Billing-Interna in anderen Modulen im Build-Schritt verbietet. Kommunikation darf nur über ein einzelnes, typsicheres BillingFacade-Interface erfolgen, um schleichende Koppelungen sofort zu blockieren.
- 10
Änderungspässe für die Abrechnung
Jeder Pull Request mit Bezug zur Abrechnung muss einen maschinell geprüften Pass mitführen: betroffene Tabellen, Invarianten, Migrationskompatibilität, Rollback-Pfad und eine Abfrage in Produktion, die den Zustand nach dem Deployment belegt. Ein CODEOWNERS-Gate plus ein 15-minütiges Review durch eine wechselnd für die Abrechnung zuständige Person hält den Prozess schlank genug für wöchentliche Änderungen und bündelt die Prüfung auf modulübergreifende Auswirkungen.
- 11
Auto-generierte Read-Only Postgres Views für Fremdmodule
Eine Mutation der Schema-Kapselung: Statt aufwändiger API-Refactorings werden automatisch schreibgeschützte Postgres Views für externe Abfragen bereitgestellt. Fremdmodule lesen nur diese stabilen Views, während direkte Tabellenzugriffe per DB-Permissions blockiert werden.
- 12
Asynchroner in-process Event-Bus für Read-Models
Anstatt dass fremde Module Billing-Tabellen direkt abfragen, sendet das Billing-Modul In-Memory Events bei Zustandsänderungen. Empfängermodule bauen sich eigene, lokale Projektionen auf. Das entkoppelt Lesezugriffe vollständig von den Billing-Tabellen ohne verteilte Systeme einzuführen.
- 13
Zweiwöchiger Feature-Freeze für Billing-Kapselung
Bricht die weiche Vorgabe des kontinuierlichen wöchentlichen Feature-Outputs für genau zwei Wochen. Das gesamte Team konzentriert sich fokussiert darauf, DB-Koppelungen aufzutrennen. Der Einmalaufwand schafft die Basis, um Incident-Zahlen für die verbleibenden 5 Monate nachhaltig zu senken.
- 14
Datenbankrolle pro Modul
Der Abrechnung ein eigenes Postgres-Schema und eine eigene Rolle geben und anderen Modulen die Schreibrechte auf Abrechnungstabellen entziehen, sodass direkte Schreibzugriffe schon im Staging scheitern, bevor sie die Produktion erreichen.
- 15
Physikalische DB-Partitionierung in eine zweite Postgres-Instanz
Bricht die weiche Vorgabe der Ein-Datenbank-Architektur, behält aber den monolithischen Code bei. Billing-Daten ziehen in eine eigene Datenbankinstanz um, wodurch übergreifende SQL-Joins technisch unmöglich werden. Die betriebliche Komplexität bleibt minimal, da der Code monolithisch bleibt.
Kirats Notiz an Claude: Beste Regelbrecher-Idee erst auf Rang 8: „Eine zweite Datenbank als Sicherheitsinstrument“ — sie bricht bewusst eine weiche Vorgabe. Einmal in ihrer stärksten Form durchdenken, bevor sie verworfen wird.
Alle Ideen, vollständig und in der Rangfolge. Claudes eigene Idee nimmt anonym und gleichberechtigt teil. Was die Mitglieder auf Deutsch geschrieben haben, steht hier im Original; was auf Englisch gesendet oder geschrieben wurde, ist hier übersetzt.
Lass Kirat einen Titel für meinen Vorschlag finden, die Grenzen der Abrechnung erst im Monolithen zu härten.
kirat_createRat befragt
Mein eigener Entwurf hat gewonnen (19/20 Punkte): "Fix billing's boundaries first, split it later if needed"
Im Hintergrund
kirat_createWas Claude an Kirat schickt
Briefing: Titel für einen internen Engineering-Vorschlag: die Grenzen des Abrechnungsmoduls innerhalb des Monolithen härten, bevor ein separater Service in Betracht gezogen wird. Zielgruppe: 8 Engineers und die Leitung, die weniger Vorfälle wollen. Ziel: dass der Vorschlag gelesen und genehmigt wird. Format: ein Titel, auf Englisch.
Kriterien: max. 10 Wörter · benennt die Entscheidung, nicht nur das Thema · keine Buzzwords · auch ohne technischen Hintergrund verständlich
Ergebnis des Rats
- 1
"Fix billing's boundaries first, split it later if needed"
Der eigene Entwurf des Orchestrators.
- 2
"Keep Billing Together, but Isolate It to Prevent Incidents"
Der Titel benennt die Entscheidung, die Abrechnung im Monolithen zu belassen und zugleich ihre Grenzen zu stärken, und verknüpft diese Wahl mit dem gemeinsamen Ziel, weniger Vorfälle zu haben.
- 3
"Strengthen Billing Boundaries in Current App Before Splitting Service"
Der Titel trifft eine eindeutige Richtungsentscheidung, vermeidet unnötigen Fachjargon wie 'Monolith' für das Management und spricht das gemeinsame Ziel der Stabilität direkt an.
Headlines und Titel stehen so da, wie sie geschrieben wurden, auf Englisch, wie es die Briefings verlangten. Die Begründung in Claudes Eintrag ist Kirats eigene Kennzeichnung dafür. Was die Mitglieder auf Deutsch geschrieben haben, steht hier im Original; alles andere, was auf Englisch gesendet oder geschrieben wurde, ist hier übersetzt.
Lass Kirat ein Titelbild für unseren Blogartikel übers Entflechten der Abrechnung aus dem Monolithen erstellen. Abstrakt und ruhig.
kirat_imageRat befragt
Die Jury hat das Bild von gpt-image-2 gewählt (16/20 Punkte). Beide Mitglieder haben beide Bilder anonym bewertet.
Im Hintergrund
kirat_imageWas Claude an Kirat schickt
Briefing: Titelbild für einen internen Engineering-Blogpost über das Herauslösen eines Abrechnungsmoduls aus einem Monolithen: eine abstrakte, ruhige Illustration eines klar abgegrenzten Blocks, der von einem dichten Cluster miteinander verbundener Blöcke abgesetzt ist. Flacher Stil, gedeckte Farben, kein Text, keine Logos.
Kriterien: die Idee einer klaren Grenze ist auf einen Blick erkennbar · ruhig, nicht dramatisch · funktioniert auch in kleiner Größe · kein Text und keine Logos
Ergebnis des Rats
gpt-5.6 · 9/10 Die isolierte Einheit mit gestrichelter Umgrenzung ist sofort erkennbar und steht klar dem dichten, vernetzten Blockcluster gegenüber. Ruhige, gedeckte Farbgebung; auch klein gut lesbar. Leichte räumliche Schattierung statt konsequent flachem Stil.
gemini-3.6-flash · 7/10 Gute Darstellung des isolierten Blocks mit gestrichelter Grenze, ruhiger Stil und klare Lesbarkeit auch in kleiner Ansicht.
gpt-5.6 · 6/10 Abgesetztes Element und komplexes Geflecht vermitteln die Entkopplung grundsätzlich, doch die Grenze wirkt eher wie ein Bildschirmrahmen als wie eine klar definierte Modulgrenze. Das Cluster ist sehr kleinteilig und verliert bei kleiner Darstellung an Lesbarkeit; insgesamt dennoch ruhig und ohne Logos oder lesbaren Text.
gemini-3.6-flash · 4/10 Fokus liegt auf einem Tablet-Bildschirm statt einem abgetrennten Baustein, das Wirrwarr wirkt weniger strukturiert.
KI-generierte Bilder, verkleinert und ansonsten unbearbeitet. Mit ≈ markierte Kosten stammen aus parallel gelaufenen Durchläufen: die eigenen Bildkosten jedes Durchlaufs plus ein gleicher Anteil an den Bewertungsaufrufen. Die Rangfolge ist eine Vorauswahl, die endgültige Wahl bleibt bei Ihnen. Was die Mitglieder auf Deutsch geschrieben haben, steht hier im Original; was auf Englisch gesendet oder geschrieben wurde, ist hier übersetzt.
Entscheidungen überdauern ihre Begründung.
ADRs werden im Nachhinein geschrieben, wenn überhaupt – und bis dahin ist die Begründung zu einer Zusammenfassung des Ergebnisses verblasst.
Die Entscheidung fiel eigentlich in einem Thread. Der Thread ist nicht durchsuchbar, und wer ihn geschrieben hat, ist nicht mehr da.
„Warum ist das so gebaut?“ wird mit Archäologie beantwortet, von dem, der am längsten dabei ist.
Die Argumentation, die ein ADR braucht, festgehalten, während sie stattfindet.
Eine Abstimmung des Rats erzeugt den Teil eines ADR, der am schnellsten verfällt: was gefragt wurde, was erwogen wurde, was sich durchsetzte, wie es sich durchsetzte und wer widersprach. Es ist kein fertiges ADR, und Kirat schreibt keine ADRs. Status, Konsequenzen und Verantwortliche tragen Sie weiterhin selbst ein. Was entfällt, ist das Rekonstruieren einer Argumentation, die niemand aufgeschrieben hat.
ABB. 1 — Was das Ergebnis abdeckt und was nicht. Die zweite Zeile zeigen wir Ihnen lieber, als sie zu verstecken. Die Zahlen bei den Stimmen sind die selbst angegebene Konfidenz der Modelle. Ohne Mehrheit lautet das Ergebnis needs_human: Sie entscheiden.
Kirat behält die letzten 20 Ergebnisse im Ordner .kirat in Ihrem Home-Verzeichnis, und Claude kann neuere mit kirat_result abrufen. Das ist ein Arbeitsgedächtnis, kein Archiv. Speichern Sie die wichtigen Ergebnisse dort, wo Ihre ADRs liegen.
Ein Kauf für Claude Desktop und Claude Code.
Kein Abo, keine Nutzerplätze, kein Konto bei uns. Prüfen Sie vor dem Kauf, wo Kirat läuft:
Wo Kirat läuft
Funktioniert in
- Claude-Desktop-Chats unter macOS und Windows
- Claude Code im Terminal, in VS Code oder im Code-Tab von Claude Desktop
- Cloud-Sitzungen von Claude Code, nach einer einmaligen Einrichtung pro Cloud-Umgebung Mit Grenzen: Alle, die die Umgebung nutzen, können Ihre Keys lesen, und das Tagesbudget zählt pro Sitzung.
Funktioniert nicht in
- Chat im Browser (claude.ai) oder in den Claude-Apps für Mobilgeräte
- Cowork-Aufgaben, die in der Cloud laufen
- Manche Firmenumgebungen: Netzwerke, die einen HTTP-Proxy vorschreiben, und Organisationen, die Desktop-Erweiterungen auf eine Freigabeliste beschränken Fragen Sie vorher Ihre IT.
- 01Claude-Desktop-Erweiterung und Claude-Code-Plugin in einem Download
- 02Setup-Skript für Cloud-Sitzungen von Claude Code
- 03Alle neun Tools: Abstimmung, Code-Review, Ideen-Ranking, Textkritik, Bildvergleich und mehr
- 04Kostenkontrolle: ein Tagesbudget (standardmäßig $5), das Aufrufe zurückhält, die es überschreiten könnten. Nach bestem Bemühen, setzen Sie deshalb auch Limits bei den Anbietern
- 05Lizenz für eine Person, auf Ihren eigenen Geräten und in Ihren Cloud-Umgebungen
- 06Kompatibilitätsupdates nach Möglichkeit — kostenlos, aber ohne Garantie
Läuft in Claude Desktop (macOS/Windows) und Claude Code; Cloud-Sitzungen von Claude Code mit einmaliger Einrichtung — nicht der Chat im Browser oder auf Mobilgeräten. Wo es läuft · Cloud-Grenzen
Kirat kaufenEinmalkauf · Zahlung über Lemon Squeezy (Merchant of Record, Verkäufer), Umsatzsteuer wird im Checkout abgewickelt · Erstattungen: siehe AGB
Die API-Nutzung bezahlen Sie direkt an OpenAI und Google, über Ihre Konten — $0.02–$0.15 pro Ratsentscheidung in unseren Messungen.
Kirat ist nichts für Sie, wenn …
- —Sie Claude nur als Chat im Browser oder auf dem Smartphone nutzen. Kirat läuft in Claude Desktop (macOS/Windows) und Claude Code sowie in Cloud-Sitzungen von Claude Code mit einmaliger Einrichtung — nicht in diesen Chats.
- —Sie einen gehosteten Dienst, Telefon-Support oder garantierte Antwortzeiten brauchen.
- —Sie keine API-Konten und keine Abrechnung bei zwei Anbietern wollen.
- —Sie nur eine Handvoll Entscheidungen im Monat treffen und Antworten gern selbst in getrennten Chats vergleichen.
- —Sie eine Antwort wollen, die sicher klingt. Die Aufgabe eines Rats ist es, Ihnen die Uneinigkeit zu zeigen, und manchmal ist die Uneinigkeit die Antwort.
- —Ihre Daten nicht an OpenAI oder Google gehen dürfen. Alles, was Sie Kirat geben, geht an beide, über Ihre Konten und zu deren Bedingungen.
Bevor Sie kaufen.
Ersetzt das Code-Review?
Nein. kirat_review holt Befunde zu einer Änderung von anderen Modellfamilien ein, bevor ein Mensch sie ansieht, und jeder Befund wird von der jeweils anderen Modellfamilie überprüft. Menschen reviewen weiterhin. Es ändert, worauf sie schauen, nicht, ob sie schauen.
Was darf tatsächlich delegiert werden?
Umkehrbare Arbeitsentscheidungen, über kirat_decide, mit Veto und Tageslimit. Jede delegierte Entscheidung wird in das Protokoll delegierter Entscheidungen im Ordner .kirat geschrieben.
Alles, was sich nur teuer rückgängig machen ließe, gehört in eine Abstimmung, nicht in eine Delegation. Eine Abstimmung liefert Ihnen die Positionen und das Ergebnis; ohne Mehrheit gibt sie needs_human zurück und entscheidet nichts.
Wie passt es in einen bestehenden ADR-Prozess?
Es liefert die Argumentation; Sie liefern das ADR. Aufruf und Ergebnis enthalten die Frage, die Optionen und die Entscheidung – den Teil, den man Wochen später schlecht wiedergibt. Status, Konsequenzen und Verantwortliche bleiben Handarbeit; siehe Abb. 1.
Kirat behält nur die letzten 20 Ergebnisse, speichern Sie also die gewünschten neben dem ADR.
Wie funktioniert es im Team?
Eine Lizenz gilt für eine Person, auf beliebig vielen eigenen Geräten und eigenen Cloud-Umgebungen dieser Person. Eine Weitergabe ist nicht erlaubt, daher braucht jede Person im Team, die Kirat nutzt, eine eigene Lizenz, und eine mit anderen geteilte Cloud-Umgebung braucht eine Lizenz pro Person. Es gibt keine Plätze zu verwalten, kein Konto bei uns und keinen Server zu betreiben.
Jede Person nutzt ihre eigenen API-Keys und ihr eigenes Tagesbudget. Wir empfehlen ein separates Projekt beim Anbieter mit Ausgabenlimit. In einer geteilten Cloud-Umgebung können alle, die sie nutzen, ihre Umgebungsvariablen lesen, einschließlich der Keys.
Die Details, zum Nachlesen.
Alles Weitere vollständig: was Kirat nicht kann und weitere Fragen. Öffnen Sie, was Sie brauchen.
Was Kirat nicht leistet
- —Es ist nicht manipulationssicher. Die Ergebnisse und das Protokoll delegierter Entscheidungen sind lokale Dateien im Ordner
.kirat. Jeder mit Zugriff auf den Computer kann sie bearbeiten oder löschen. Es ist ein lokales Laufprotokoll und eine Gedächtnisstütze, kein Compliance-Nachweis. - —Es ersetzt kein Code-Review und verringert Ihren Review-Aufwand nicht von selbst. Ob es jemandem Zeit spart, hängt ganz von Ihrem Arbeitsablauf ab. Wir haben keine Messung, also behaupten wir auch keine.
- —Es lässt sich nicht in Ihre Pipeline einbinden. Kein Bot kommentiert Pull Requests, und nichts läuft in Ihrer Build-Pipeline. Kirat arbeitet in einem Chat in Claude Desktop oder einer Sitzung in Claude Code – lokal oder, nach der einmaligen Einrichtung, in einer Cloud-Sitzung –, wenn Claude es aufruft.
- —Delegation ist eine Schutzvorrichtung, kein Berechtigungssystem. Veto und Tageslimit beschränken
kirat_decide. Sie beschränken nicht, was Claude, Ihre Werkzeuge oder Ihre Systeme tun dürfen. - —Es hält Ihren Code nicht im Haus. Alles, was Sie Kirat geben (Fragen, Kontext, Code), geht direkt an OpenAI und Google, unter Ihren Konten und deren Bedingungen – von Ihrem Computer aus oder, in Cloud-Sitzungen von Claude Code, aus Ihrer eigenen Cloud-Umgebung über den Netzwerk-Proxy von Anthropic für diese Umgebung. Im Vergleich zur alleinigen Nutzung von Claude kommen damit zwei Empfänger hinzu.
- —Es läuft nicht überall, wo Sie Claude nutzen. Nur dort, wo Claude Werkzeuge auf einem Rechner ausführt, auf dem Kirat installiert ist: Chats in Claude Desktop unter macOS und Windows, Claude Code im Terminal oder in VS Code, lokale Sitzungen im Code-Tab von Claude Desktop, SSH-Sitzungen – und Cloud-Sitzungen von Claude Code (Cloud-Sitzungen im Code-Tab, Claude Code im Web oder in der Mobil-App) nach einer einmaligen Einrichtung Ihrer Cloud-Umgebung. Die Cloud hat Grenzen: Alle, die die Umgebung nutzen, können ihre Umgebungsvariablen lesen, einschließlich Ihrer Keys; Kirats Tagesbudget zählt pro Sitzung, legen Sie also Ausgabenlimits bei OpenAI und Google fest; Hintergrundaufträge und die letzten Ergebnisse enden mit der Sitzung; und die Umgebung muss zwei Hosts zulassen,
api.openai.comund den Download-Host von Kirat. Schlägt die Einrichtung fehl, startet die Sitzung trotzdem, nur ohne Kirat, und der fehlgeschlagene Zustand kann für neue Sitzungen zwischengespeichert bleiben, bis Sie das Setup-Skript bearbeiten. Nicht der Chat im Browser oder in den Mobil-Apps und nicht Cowork-Aufgaben, die in der Cloud laufen. WSL-Sitzungen und lokale Cowork-Aufgaben sind nicht getestet. Netzwerke auf Ihrem eigenen Computer, die einen HTTP-Proxy erfordern, werden nicht unterstützt. Organisationen, die Desktop-Erweiterungen auf eine Allowlist beschränken, blockieren manuelle Installationen; fragen Sie Ihre Administration. Wo es läuft, vollständig.
Was es ohne Sie entscheiden darf.
Ein Werkzeug ist für Entscheidungen gebaut, die Sie abgeben: kirat_decide, für umkehrbare Arbeitsentscheidungen. Es hat ein Veto und ein Tageslimit, und jede delegierte Entscheidung wird in ein lokales Protokoll im Ordner .kirat geschrieben. Für alles andere stimmt der Rat ab, und Sie sehen das Stimmenverhältnis. Ohne Mehrheit lautet die Antwort needs_human, statt sich für eine Seite zu entscheiden.
Die Regeln rund um die Aufrufe stehen im Code, nicht in einem Prompt:
ABB. 2 — Stückliste der Leitplanken. Der Budgetwächter arbeitet nach bestem Bemühen: Legen Sie auch bei den Anbietern Ausgabenlimits fest.
Diese Regeln sind auf lehrreiche Weise gescheitert, und die Korrekturen stehen im Code. Ein Beispiel aus den Release Candidates: Eine Budget-Ablehnung zählte als API-Fehler und konnte den Circuit Breaker auslösen, wodurch ein funktionierendes Mitglied ausfiel. Budget-Ablehnungen zählen inzwischen nicht mehr als Fehler. Kirat hat 256 automatisierte Tests, die ohne Netzwerkzugriff laufen. Die vollständige Chronik der Fehler steht im Abschnitt mit Belegen auf der Hauptseite.
Weitere Fragen
Wo liegen die API-Keys?
Sie geben sie im Installations- oder Einstellungsdialog von Claude selbst ein. Claude Desktop speichert sie im sicheren Speicher des Betriebssystems (macOS-Schlüsselbund, Windows-Anmeldeinformationsverwaltung). Claude Code speichert sie im macOS-Schlüsselbund und unter Windows und Linux in ~/.claude/.credentials.json, nur für Ihren Benutzer lesbar. In Cloud-Sitzungen von Claude Code sind sie Umgebungsvariablen Ihrer Cloud-Umgebung und für alle lesbar, die sie nutzen.
Kirat hat keinen Server und keine Telemetrie. Wir sehen weder Ihre Keys noch Ihre Daten.
Was gehört zur Einführung?
Claude Desktop: Entpacken Sie den Download, öffnen Sie Settings → Extensions → Advanced settings → Install Extension…, wählen Sie die .mcpb-Datei und geben Sie beide Keys im Dialog ein. Desktop warnt, dass aus einer Datei installierte Erweiterungen nicht von Anthropic verifiziert sind; das ist zu erwarten.
Claude Code: Entpacken Sie den Download und verschieben Sie den entpackten Ordner kirat in Ihr Home-Verzeichnis, sodass ~/kirat/claude-code existiert. Führen Sie dann in einer Sitzung /plugin marketplace add ~/kirat/claude-code und /plugin install kirat@kirat aus und geben Sie die Keys ein, wenn Sie danach gefragt werden. Das Plugin benötigt Node.js 20 oder neuer.
Cloud-Sitzungen von Claude Code: Fügen Sie einmal pro Cloud-Umgebung den Block aus dem Download (cloud/setup.sh) am Anfang des Setup-Skripts der Umgebung ein und legen Sie beide Keys als Umgebungsvariablen an. Wir empfehlen die Namen KIRAT_OPENAI_API_KEY und KIRAT_GEMINI_API_KEY: Sie kollidieren nicht mit einem projekteigenen OPENAI_API_KEY (Kirat akzeptiert auch OPENAI_API_KEY und GEMINI_API_KEY). Steht der Netzwerkzugriff auf Full, müssen Sie nichts ändern; andernfalls stellen Sie ihn auf Custom (in neueren Apps: Limited) mit der Standardliste der Paketmanager, plus api.openai.com und dem Download-Host von Kirat. Schlägt die Einrichtung fehl, startet die Sitzung ohne Kirat, und der fehlgeschlagene Zustand kann zwischengespeichert bleiben, bis Sie das Setup-Skript bearbeiten. Prüfen Sie zuerst die Grenzen der Cloud: wo es läuft.
Wenn Ihre Organisation Desktop-Erweiterungen auf eine Allowlist beschränkt, sind manuelle Installationen blockiert; fragen Sie Ihre Administration. Der langsame Teil der Einrichtung ist das Anlegen der beiden API-Keys bei den Anbietern.
Was ist mit Updates und Modellwechseln?
Für ein Update in Claude Desktop installieren Sie die neue .mcpb auf dieselbe Weise (in Claude Code entpacken Sie die neue Version über den alten Ordner kirat und starten Claude Code dann neu oder führen /reload-plugins aus); Keys und Einstellungen bleiben erhalten. Kompatibilitäts-Updates sind nach Möglichkeit kostenlos, ohne Garantie. Größere neue Versionen werden möglicherweise separat verkauft.
Modellnamen und Preise sind Einstellungen. Mustert ein Anbieter ein Modell aus, tragen Sie den neuen Namen und seine zwei Preise ein – kein Update nötig.