Rules so schichten, dass Teams konsistent arbeiten
Regeln sind in QuantenRam keine Dekoration fuer Prompts, sondern die eigentliche Ausfuehrungspolitik eines Projekts. Sie entscheiden, wann ein Agent planen muss, wann er ein guenstiges Alias behalten soll, wann auf Review eskaliert wird und welche Verifikation nach jeder groesseren Aenderung verpflichtend ist.
Am besten funktionieren Rules dann, wenn sie kurz, testbar und nah am echten Arbeitskontext formuliert sind. Ein Projekt mit Django, Hidden Admin unter /ksxok, Hybrid Billing und Aliasrouting braucht andere Leitplanken als ein generischer Playground. Darum sollte deine Regelbasis immer aus einer kleinen globalen Konvention und einer repo-nahen Spezialisierung bestehen. In diesem Projekt ist AGENTS.md genau diese operative Kernschicht.
Globale Defaults fuer den Alltag
Globale Regeln sollten nur Verhalten festhalten, das in fast jedem Projekt sinnvoll bleibt, etwa knappe Antworten, klare Verifikation und vorsichtiger Umgang mit destruktiven Aktionen. Alles, was stark von Stack, Produkt oder Billing abhaengt, gehoert nicht in die globale Ebene, sondern ins jeweilige Repository.
Projektregeln nah am Code
Repo-nahe Regeln sollten konkrete Pfade, Pflichttests, Tier-Strategien und lokale Runbooks nennen. Genau hier legst du fest, dass QuantenRam-Aliase statt roher Modellnamen verwendet werden, welche Checks vor einem Rollout laufen und welche Dateien ein Agent in neuen Sessions zuerst lesen muss.
Sicherheitsregeln vor Komfortregeln
Wenn zwei Regeln kollidieren, gewinnt immer die restriktivere Ebene. Ein Komfortwunsch wie "arbeite schnell" darf nie eine Sicherheitsvorgabe wie "kein destruktives Git ohne explizite Anweisung" aushebeln. Diese Prioritaet sollte nicht implizit sein, sondern schriftlich in der Regelbasis stehen.
Projektregeln in QuantenRam konkret formulieren
Gute QuantenRam-Regeln benennen nicht nur Stil, sondern auch operative Folgen. Eine Regel wie "nutze fuer Routineaufgaben zuerst quantenram-start/*" ist wertvoll, weil sie Kosten, Qualitaet und Eskalation steuert. Eine Regel wie "nach Aenderungen an Modell- oder Routing-Logik immer /v1/models und einen echten Smoke-Request pruefen" ist wertvoll, weil sie den Uebergang von Textanweisung zu realer Betriebssicherheit schliesst. Genau diese Art von Formulierung sollte in AGENTS.md, projektbezogenen Notes und Release-Runbooks landen.
# Beispiel fuer eine repo-nahe Regelbasis
1) Lies in neuen Sessions zuerst AGENTS.md und handoff.md.
2) Nutze fuer Baseline-Arbeit quantenram-start/*; eskaliere nur mit Begruendung.
3) Nach Aenderungen an Routing, Keys oder Modellfreigaben pruefe /v1/models und einen echten Chat-Request.
4) Sicherheits- und Billing-relevante Regeln haben Vorrang vor Komfortregeln.Coding-Standards und Verifikation als Teil der Rules
Coding-Standards sollten nicht als isolierter Stilblock gepflegt werden, sondern als Teil des Ausfuehrungspfads. Wenn ein Projekt Python, Django-Checks und gezielte Testpfade verwendet, dann gehoeren diese Dinge in die Regelbasis hinein: nicht als Wunschliste, sondern als definierte Abschlussbedingung. So weiss ein Agent nicht nur, wie Code aussehen soll, sondern auch, wann eine Aenderung wirklich als abgeschlossen gilt.
Praktisch bedeutet das: Regeln nennen Dateipfade, Testbefehle, typische Verify-Loops und bekannte Stolperstellen wie Billing-Auswirkungen oder Tier-Freigaben. Gerade fuer QuantenRam lohnt sich diese Genauigkeit, weil Modellwahl, API-Vertrag und Dashboard-Sichtbarkeit zusammenhaengen. Wer nur Stil regelt, aber nicht den Betriebsweg, bekommt konsistente Syntax und trotzdem inkonsistente Releases.
Vererbung und Layering ohne Widersprueche
Rule Layering bleibt nur dann stabil, wenn die Praezedenz klar ist. Am besten definierst du eine einfache Reihenfolge: globale Defaults ganz unten, Projektregeln darueber, sicherheitskritische Ueberschreibungen ganz oben. Wenn eine neue Regel eingefuehrt wird, sollte gleichzeitig notiert werden, welche Ebene sie ueberschreibt und wie ihre Einhaltung geprueft wird. Auf diese Weise entsteht kein wachsender Regelwald, sondern eine wartbare Hierarchie.
Ein guter Wartungsrhythmus ist incident-getrieben und klein. Wenn ein Agent versehentlich das falsche Modelltier waehlt oder ein teurer Review-Pfad fuer Routinearbeit genutzt wird, wird daraus keine lange Grundsatzdiskussion, sondern eine neue, kurze Regel mit einer passenden Verifikation. Genau so bleiben Rules lebendig und produktiv.
Starke Rules sind in QuantenRam immer operational: Sie legen fest, welche Aliasfamilie zuerst genutzt wird, welche Sicherheitsgrenzen gelten und welcher Verify-Loop eine Aenderung wirklich abschliesst.