reins — nur die Domain aus der Quest-CLI behalten, das ratchet als Framework

reins — nur die Domain aus der Quest-CLI behalten, das ratchet als Framework Image: AI generated

how-make-quest handelte davon, wie man eine Quest-CLI mit bloßen Händen baut. Was ein ratchet ist, wie man ein Gate setzt, wie man cheese blockiert. Gibt man einem Agenten diesen einen Text, kommt eine cobra-basierte Go-CLI heraus.

Doch was passiert, wenn man eine zweite Quest-CLI baut? Man schreibt dieselbe einseitige Zustandsmaschine erneut. Man schreibt dasselbe scan/next/submit/status/export erneut. Man schreibt dieselbe PASS-Sperre, dieselbe monotone Abnahme von remaining, denselben JSONL-export erneut. Was sich ändert, ist nur das eine Gate, doch jedes Mal schreibt man den ganzen Rest neu. Das ist die Boilerplate-Steuer, die jede weitere Quest verlangt.

Das Muster war wiederverwendbar. Der Code nicht. reins schließt diese Lücke.

Was ist invariant und was ist Domain

Legt man zwei Quest-CLIs übereinander und betrachtet die Differenz, ist die Grenze scharf.

invariant (jede Quest teilt es)          Domain (je Quest verschieden)
─────────────────────────                ─────────────────────
ratchet: TODO→PASS irreversibel          was eine Quest ist
Befehlsgerüst: scan/next/submit…         was eine "Tatsache" ist
Level-Aggregation: Fail/Review→verdict   welcher cheese zu blockieren ist
Fortschritt persistent·resumable
export: 1-malige Emission

Die linke Seite ist genau das, was how-make-quest bewies — ob die Domain ein Firmenname, ein Endpoint oder eine Funktion ist, der Zahn des ratchet greift gleich. Nur die rechte Seite kennt der Mensch. reins liefert die linke Seite als Framework und lässt dir nur die rechte.

Das ist keine neue Behauptung, sondern ein altes Prinzip, das reins per Code erzwingt — die Trennung von Entscheidung und Implementierung. Das Gate ist die Entscheidung (was in dieser Domain wahr ist), das ratchet·die CLI·die Aggregation sind die Implementierung. Die Implementierung jedes Mal neu zu schreiben, ist das Versäumnis, die Entscheidung an die Implementierung zu binden.

Du implementierst nur ein Gate

Mit reins eine Quest zu bauen heißt, die vier Methoden eines einzigen Interface zu füllen.

type Definition interface {
    Seed(args []string) ([]*quest.Item, error)            // Eingabe → initiale TODO-Seeds
    Render(it *quest.Item) (string, error)                // Erstellungs-Prompt + Verifizierungskontext, den next anzeigt
    Prepare(it *quest.Item, raw []byte) (gate.Context, *quest.Verdict, error) // Einreichung decodieren
    Rules() []gate.Rule                                   // Verletzungsregel-Katalog des Gates
}

func main() { cli.NewQuestCmd("myquest", myDef{}, cli.Options{}).Execute() }

Die eine Zeile main liefert das ratchet, sechs Befehle, Aggregation, export und eine resumable Session vollständig. Du hast nur die vier Domain-Stücke geschrieben. Der Agent muss weiterhin nur zwei Befehle kennen — mit next empfangen, mit submit einreichen. Den Rest entscheidet die Maschine.

Das Gate ist ein Katalog von cheese-Abwehrregeln

Der Kern von how-make-quest war “entwirf ein cheese-unmögliches Gate”. reins macht dieses Design zu einer Datenstruktur — Gate = Regelkatalog. Eine Regel ist ein cheese-Detektor. Findet sie eine Verletzung, feuert sie (true) und lädt eine Tatsache (Fact) auf.

// Eine cheese-Abwehrregel einer News-Ereignis-Extraktions-Quest.
// "existiert der who-Anker tatsächlich in der Quelle" — erfindet der Agent eine Person, fliegt es auf.
var whoAnchorPresent = gate.Rule{
    Meta: gate.RuleMeta{ID: "who-anchor-present", Level: gate.LevelFail, Desc: "erforderlicher who-Anker existiert in der Quelle"},
    Check: func(ctx gate.Context) (bool, quest.Fact) {
        sub := ctx.Submission.(*Event)
        if miss := textmatch.MissingTokens(ctx.Source, sub.Who.Anchors); len(miss) > 0 {
            return true, quest.Fact{Where: "who.anchors", Expected: "Quell-substring", Actual: miss[0]}
        }
        return false, quest.Fact{}
    },
}

Die Tugend dieser Struktur ist, dass sie wächst. Jedes Mal, wenn man einen neuen cheese entdeckt, fügt man eine Regel hinzu und das Gate wird genau so viel härter. Und der Katalog dokumentiert sich selbst — gibt der Befehl rules die Regelliste aus, ist das zugleich “die Auditliste des cheese, den ich blockiere”. Es gibt kein Gate, das nicht weiß, was es blockiert.

Die Schwere ist kein Gewicht, sondern ein Level. Ein einziges Fail bedeutet sofort FAIL. Eine entscheidende Verletzung wird nicht verhandelt — neun 99-Punkte-Verletzungen können kein einziges Fail überdecken. Evaluate aggregiert die gefeuerten Regeln nach Level: ist auch nur eines Fail, FAIL; sonst, wenn es ein Review gibt, REVIEW; bestehen alle, PASS.

Die Befugnis-Asymmetrie wird per Typ erzwungen

Die wichtigste Zeile in how-make-quest war “die PASS-Sperre nur die Maschine”. reins verankert das nicht als Konvention, sondern als Typ.

L1 Maschine (Determinismus)  die einzige Befugnis, PASS zu sperren
L2 KI (Skeptikerin)          nur REVIEW — erhebt Zweifel, kann aber keine Fertigstellung verleihen
L3 Mensch                    der Rest, den beide verfehlt haben

Das Maschinen-Gate vergibt PASS. Selbst wenn man einen KI-Verifier ins Gate setzt, ist das Maximum, das er tun kann, das Aussortieren nach REVIEW. Das Falsche wird von vornherein unmöglich gemacht — gibt das Framework der KI keine API, die ihr PASS-Befugnis verleiht, kann man die Entscheidung nicht einmal versehentlich dem betrunkenen Freund überlassen.

Das zweite Backend — der defeat graph

Für viele Gates genügt die Level-Aggregation unabhängiger Regeln. Doch sobald die Regeln miteinander konkurrieren — “diese Verletzung ist nur sinnvoll, wenn jene Verletzung vorliegt”, “die eigentliche Ursache dieses Scheiterns ist in Wahrheit jenes” —, fressen handgeschriebene if-else-Guards das Gate auf. Nicht dort, wo ein schwaches Gate bricht, sondern dort, wo ein komplexes Gate verrottet.

Das zweite Gate-Backend von reins verlagert diese Konkurrenz in einen deklarativen Graphen — toulmin h-Categoriser. Das Toulmin-Argumentationsmodell wird unverändert zur Datenstruktur:

Warrant — tautology PASS. Der Grund “ohne Gegenrede wird durchgelassen”.
Counter — eine Verletzung greift den Warrant an.
Supersedes — Priorität zwischen Regeln. Welche Gegenrede welche Gegenrede schlägt.

Handgeschriebene Guard-Klauseln verdampfen zu Attacks·Supersedes-Kanten. Und ist die Kantenzahl 0, ist dieser Graph exakt äquivalent zur Level-Aggregation — Komplexität ist eine Kosten, die nur bei Bedarf eingeschaltet wird (opt-in; sie schaltet sich ein, wenn Definition einen gate.Evaluator implementiert).

Das wahre Geschenk des Graphen ist nicht das Urteil, sondern das Feedback. Die Graph-Auswertung gibt dem Agenten einen direkten Lösungsweg zurück — Verdict.Feedback: “warum verloren, und was ändern, um zu gewinnen.” Kein bloßes “FAIL”, sondern eine aus der Struktur der Argumentation berechnete eigentliche Ursache.

Hier wirkt das Paradox aus how-make-quest erneut. Das Modell schmeichelt — es befolgt Anweisungen brav. Bei Meinungen ist Schmeichelei Gift, doch bei Tatsachen ist Schmeichelei ein Aktivposten. Der Lösungsweg ist keine Meinung (“das ist irgendwie komisch”), sondern eine Tatsache (“who.anchors steht nicht im Ausgangstext, ändere das”). Je schmeichelhafter das Modell, desto bereitwilliger nimmt es jene Tatsache an und konvergiert. Deterministischer Graph + schmeichelndes LLM = eine Schleife, bei der Konvergenz garantiert ist.

Nebenwirkungen werden isoliert — ground und staged-Auswertung

Damit ein Gate deterministisch ist, darf das Netzwerk nicht im Gate stecken. Eine Regel, die net/http direkt aufruft, ist nicht unit-testbar, und das Urteil schwankt je nach Leitungslage.

reins treibt die Nebenwirkungen in pkg/ground zusammen — Primitive wie HTTPBody·MXResolves besitzen die externen Abfragen über einen injizierten Resolver und einen Snapshot pro Anfrage. Die Regeln bleiben rein, die Außenwelt verantwortet ground.

Und die staged-Auswertung: die billige Prüfung läuft zuerst, und scheitert sie, findet der Netzwerk-fetch gar nicht erst statt. Es gibt keinen Grund, für eine formal falsche Einreichung DNS abzufragen. Man stellt das Teure und Schwankende hinter das Billige und Sichere.

Kein Abstrahieren bei N=1

Eine der Konventionen von reins offenbart den Charakter dieses Frameworks am genauesten — extrahiere keine Abstraktion aus einem einzigen Konsumenten. Eine neue Abstraktion wird erst eingefroren, nachdem ein zweiter Konsument sie verifiziert hat.

Das ist keine Pedanterie, sondern erstes Prinzip. Eine aus einem Fall extrahierte Abstraktion verwechselt das Zufällige jenes Falls mit dem Wesentlichen. Erst wenn eine zweite Domain dieselbe Abstraktion verlangt, ist bewiesen, dass sie invariant ist. Das Framework wendet “nicht Behauptung, sondern Verifikation” sogar auf seine eigene Evolution an. So wie das Gate der Behauptung des Agenten nicht glaubt, glaubt die Abstraktion der Behauptung eines einzigen Falls nicht.

Derselbe Satz, zur Bibliothek geworden

reins steht auf sieben Paketen in pkg/ — textmatch (Halluzinations-Sperr-Primitive), temporal (Zeitnormalisierung), quest (ratchet-Kern), gate (Gate-Vertrag), graph (defeat graph), ground (Netzwerkisolation), cli (cobra-Gerüst). go build·go test bestehen, alle Funktionen abgedeckt. Und toulmin ist nur einseitig an das Graph-Backend gekoppelt, sodass ein Konsument, der den Graphen nicht nutzt, toulmin nicht einmal linkt.

Code: github.com/park-jun-woo/reins

War how-make-quest ein Satz — die Erzeugung darf probabilistisch sein, die Verifikation muss deterministisch sein —, so ist reins dieser Satz, gehärtet in eine kompilierbare Form. Das Gate reverifiziert die Tatsachen der Domain, das ratchet sperrt das Bestandene, der Graph gibt den Grund des Verlierens als Tatsache zurück, und das schmeichelnde Modell fügt sich jener Tatsache.

Brauchst du das nächste Mal eine Quest-CLI, schreibe das ratchet nicht neu. Schreibe nur das Gate deiner Domain, und leihe dir die Zügel.

Weiterführende Lektüre

Das Prinzip, das reins per Code gehärtet hat — Erzeugung probabilistisch, Verifikation deterministisch —, ist keine Entdeckung allein von reins. Menschen, die einander nicht kannten, stießen an dieselbe Wand und gelangten zur selben Schlussfolgerung. Die unabhängig konvergierenden Projekte, die how-make-quest gesammelt hat, sind der Beweis.

episteme — erzwingt eine Reasoning Surface vor unumkehrbaren Aktionen. Dieselbe Intuition wie das ratchet von reins — PASS wird vor dem Sperren verifiziert.
MagLab — “Das LLM nur zum Schlussfolgern, Zahlen vom deterministischen Werkzeug.” Dieselbe Trennung wie die Isolation der Nebenwirkungen in pkg/ground bei reins.
Manifesto — “Agent proposes, World verifies.” Fasst die Befugnis-Asymmetrie von reins (nur L1 sperrt PASS) in einem Satz zusammen.
oh-my-kamisama — “diffs beat claims.” Dasselbe Prinzip wie das Gate, das nicht die Behauptung, sondern die Tatsache des Agenten reverifiziert.

Und die Wurzel des defeat-graph-Backends ist die Argumentationstheorie — die Toulmin·Dung·Amgoud-Linie der folgenden Quellen. reins’ pkg/graph überträgt jene über 60 Jahre alte Formallogik in eine Go-Datenstruktur.

Quellen

Toulmin, S. (1958). The Uses of Argument. Cambridge University Press. — das Argumentationsmodell, aus dem Warrant·Ground·Backing des defeat graph unverändert übernommen sind.
Dung, P.M. (1995). “On the Acceptability of Arguments and its Fundamental Role in Nonmonotonic Reasoning, Logic Programming and n-Person Games.” Artificial Intelligence, 77(2), 321–357. — die Urquelle des abstrakten Argumentationsframeworks und des attack-(defeat-)Graphen.
Amgoud, L. & Ben-Naim, J. (2013). “Ranking-based semantics for argumentation frameworks.” SUM 2013, LNCS 8078, 134–147. — der von pkg/graph übernommene weighted h-Categoriser. Die Compensation-Eigenschaft, bei der die Akzeptanz eines angegriffenen Knotens sich erholt, wenn er erneut verteidigt wird, mit Konvergenzgarantie.
Nute, D. (1994). “Defeasible Logic.” In Handbook of Logic in Artificial Intelligence and Logic Programming, Vol. 3. Oxford University Press. — die Klassifikation strict/defeasible/defeater. Die formale Wurzel der Regel-Level (Fail/Review) und der Supersedes-Priorität von reins.
Modgil, S. & Prakken, H. (2014). “The ASPIC+ Framework for Structured Argumentation: A Tutorial.” Argument & Computation, 5(1), 31–62. — ein Argumentationssystem, das Nutes Klassifikation innerhalb des Dung-Frameworks strukturiert. Die Genealogie des defeat graph.
Gabriel, V.O. et al. (2020). “Reasoning in BDI agents using Toulmin’s argumentation model.” Theoretical Computer Science, 805, 76–91. — ein Vorläuferfall, der das Toulmin-Modell als Software implementiert (BDI-Agenten). reins’ pkg/graph überträgt dies auf das Gate-Urteil.
Von Neumann, J. (1956). “Probabilistic Logics and the Synthesis of Reliable Organisms from Unreliable Components.” Automata Studies, Princeton University Press. — das Prinzip, ein verlässliches Protokoll auf instabile Bauteile zu legen (die Prämisse von reins).
Stechly, K., Valmeekam, K., & Kambhampati, S. (2024). “On the Self-Verification Limitations of Large Language Models.” arXiv:2402.08115 — Selbstverifikation hebt die Leistung kaum → der Grund, die PASS-Befugnis bei der L1-Maschine zu belassen.
McKee-Reid, L. et al. (2024). “Honesty to Subterfuge: In-Context RL Can Make Honest Models Reward Hack.” arXiv:2410.06491 — selbst ein ehrliches Modell manipuliert, wenn es über die eigene Belohnung urteilt → die Grundlage der Befugnis-Asymmetrie.
Bondarenko, A. et al. (2025). “Demonstrating Specification Gaming in Reasoning Models.” arXiv:2502.13295 — je höher die Fähigkeit, desto besser findet es die Lücke des Gates → der Grund, warum Gate=Regelkatalog wachsen muss.
Thaman, K. (2026). “Reward Hacking Benchmark: Measuring Exploits in LLM Agents with Tool Use.” arXiv:2605.02964 — macht man das Gate absichtlich hart, sanken die Exploits um 87,7 %.
Fanous, A. et al. (2025). “SycEval: Evaluating LLM Sycophancy.” AAAI/ACM AIES 2025. arXiv:2502.08177 — Messung der Schmeichel-Nachgieberate. Die beiden Seiten von “bei Tatsachen ist Schmeichelei ein Aktivposten”.
Shapira, I. et al. (2026). “How RLHF Amplifies Sycophancy.” arXiv:2602.01002 — das Theorem, dass RLHF Schmeichelei verstärkt. Die Prämisse der Konvergenzschleife aus Tatsachen-Feedback + Schmeichelei.
Deque Systems (2021). “Automated Testing Study Identifies 57 Percent of Digital Accessibility Issues.” — die Grenze zwischen dem maschinell beurteilbaren Bereich (57 %) und dem menschlichen Rest (20 %).