Rules so schichten, dass Teams konsistent arbeiten
Regeln sind in QuantenRam keine Dekoration für Prompts, sondern die eigentliche Ausführungspolitik eines Projekts. Sie entscheiden, wann ein Agent planen muss, wann er ein günstiges Alias behalten soll, wann auf Review eskaliert wird und welche Verifikation nach jeder grösseren Änderung 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 für 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 abhängt, gehört 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 Priorität 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 für Routineaufgaben zuerst quantenram-start/*" ist wertvoll, weil sie Kosten, Qualität und Eskalation steuert. Eine Regel wie "nach Änderungen an Modell- oder Routing-Logik immer /v1/models und einen echten Smoke-Request prüfen" 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 Ausführungspfads. Wenn ein Projekt Python, Django-Checks und gezielte Testpfade verwendet, dann gehören 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 Änderung wirklich als abgeschlossen gilt.
Praktisch bedeutet das: Regeln nennen Dateipfade, Testbefehle, typische Verify-Loops und bekannte Stolperstellen wie Billing-Auswirkungen oder Tier-Freigaben. Gerade für QuantenRam lohnt sich diese Genauigkeit, weil Modellwahl, API-Vertrag und Dashboard-Sichtbarkeit zusammenhängen. Wer nur Stil regelt, aber nicht den Betriebsweg, bekommt konsistente Syntax und trotzdem inkonsistente Releases.
Vererbung und Layering ohne Widersprüche
Rule Layering bleibt nur dann stabil, wenn die Präzedenz klar ist. Am besten definierst du eine einfache Reihenfolge: globale Defaults ganz unten, Projektregeln darüber, sicherheitskritische Ueberschreibungen ganz oben. Wenn eine neue Regel eingeführt wird, sollte gleichzeitig notiert werden, welche Ebene sie ueberschreibt und wie ihre Einhaltung geprüft 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 wählt oder ein teurer Review-Pfad für 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 Änderung wirklich abschliesst.