Skip to content
Apothem
Vergleich

Apothem vs. rohe CodeBuddy-Regeln

Warum CodeBuddys Projektregeln über Apothem leiten, statt pro Projekt .codebuddy/rules-Dateien von Hand zu schreiben.

CodeBuddy liest Projektregeln aus .codebuddy/rules/*.md. Du kannst diese Dateien von Hand schreiben, pro Projekt, für immer. Apothem verwaltet eine davon für dich und hält sie über jedes Harness und jedes Projekt hinweg konsistent.

Der rohe Ansatz

CodeBuddy-Regeln von Hand zu schreiben bedeutet:

  • Dieselben Engineering-Disziplinen für jedes neue Projekt in .codebuddy/rules/ zu kopieren und einzufügen.
  • Aus dem Takt zu geraten, während sich die Disziplinen weiterentwickeln — es gibt keine einzige Quelle der Wahrheit.
  • Dieselben Konventionen für Cursor, Windsurf, Claude Code und jedes andere von dir genutzte Werkzeug neu abzuleiten, weil jedes seine eigene Regelfläche hat.

Der Apothem-Ansatz

Apothem hält eine kanonische Regel-Kohorte im Quell-Repository und projiziert sie in die native Fläche jedes Harness. Für CodeBuddy schreibt es:

<project>/.codebuddy/rules/apothem-rules.md
AnliegenRohes CodeBuddyApothem
Quelle der WahrheitDie Dateien jedes ProjektsEine kanonische Kohorte
Harness-übergreifende KonsistenzManuell pro WerkzeugAutomatisch projiziert
AktualisierungenJedes Projekt von Hand bearbeitenapothem update --harness codebuddy --project <path>
Eigene Regeln des OperatorsMit den Disziplinen vermischtUnangetastet — Apothem schreibt eine eigene Datei
EntfernungManuelles Löschenapothem uninstall mit zeitgestempeltem Backup

Was dein bleibt

Apothem schreibt nur apothem-rules.md. Deine Memory-Datei CODEBUDDY.md, deine Berechtigungen und MCP-Server in .codebuddy/settings.json und alle anderen von dir verfassten Regeldateien bleiben vollständig im Besitz des Operators. Der Adapter erkennt diese Flächen, bearbeitet sie aber nie.

Die vollständigen Lebenszyklus-Befehle findest du auf der CodeBuddy-Harness-Seite.

On this page