/governance · Long-Form
Diese Seite erklärt das vollständige System hinter schollmayer.info. Sie ist zugleich die Vorlage für alle anderen aktiven Projekte.
Wer mit Claude Code anfängt, hat schnell zwei Probleme. Erstens: Die Maschine produziert mehr Output als ein Mensch lesen kann. Zweitens: Ohne Prozess wird der Output nach wenigen Wochen unwartbar. Beide Probleme löst Governance — aber nur, wenn man sie nicht als Bürokratie missversteht.
Der Aufbau hier ist einfach. Jedes Vorhaben läuft in drei Akten — Plan, Bau, Abnahme — mit genau zwei Kunden-Entscheidungen. Dazu 5 Regel-Dateien, 17 thematische Personas und eine Review-Pflicht vor jedem Push. Klingt nach Overhead — ist aber genau das Gegenteil. Es ist ein Werkzeug, mit dem ein Einzelner mehr schafft als ein Team von fünf. Und es ist das Ergebnis einer radikalen Verschlankung: ein einziges Release entfernte 71.964 Zeilen.
/04 · Das System dahinter
Claude Code ohne Prozess ist eine Demo. Mit Prozess ist es ein Werkzeug, mit dem ein Einzelner mehr schafft als ein Team von fünf. Jedes Vorhaben läuft in drei Akten — und der Kunde entscheidet genau zweimal.
8 Pflicht-Schritte: Abhängigkeiten, Architektur, Tests, Tech-Debt — geprüft vom IT-Architekt-Review, bevor du es siehst.
Läuft autonom. Tests grün, QA-Review vor jedem Push, Deploy verifiziert am echten Endprodukt — nicht am Health-Check.
Du verifizierst das Ergebnis visuell. Danach: Erkenntnisse in die Experten-Personas, Lane-Stand fortgeschrieben.
Zwei Klick-Anker. Alles dazwischen läuft autonom.
Der Kunde entscheidet genau zweimal: Plan-OK und Abnahme. Keine Architektur-Fragen, keine Zwischen-Klicks — Ergebnisse statt Diskussionen.
Lane-Modell · ein Vorhaben pro FadenVerhalten, Token-Doktrin, 17 Architektur-Filter, Workflow, Kunden-Anforderungen. Davor waren es 121 verstreute Regeln — bis ein Release 71.964 Zeilen gelöscht hat.
Lean-Release · 2026-05DevOps, QA, Frontend, Backend, Content-Stratege, Buchhaltung … Jede ein fokussierter Wissens-Container mit eigenem Fortbildungs-Zyklus. Aktiviert wird, wer gebraucht wird.
Rolling-Slot-FortbildungKein Plan ohne IT-Architekt-Pass. Kein Push ohne QA-Review. Kein Wissens-Eintrag ohne Verifikations-Stempel mit Ablaufdatum. Loop bis ACCEPT.
Pair-Programming · Loop bis ACCEPT„Nichts geht live ohne Abnahme durch den Kunden. Kein Code wird gepusht ohne geprüftes Go. Kein Wissen gilt, bevor es verifiziert ist."
02 · Case-Studies
Nicht aus Theorie — aus dem, was schiefgegangen ist.
2026-05-22
Radikaler Schnitt
Vier Monate Aufbau: über 100 Regeln, acht Prozess-Phasen, Hunderte Gedächtnis-Dateien. Alles funktionierte — und genau das war das Problem. Der erste ernste Stresstest zeigte: Komplexität, die Disziplin verlangt, frisst sich selbst.
In einer Nacht wurde gelöscht, was Pflege verlangte, ohne Wert zu liefern: 162 Wissens-Dateien wurden zu 53 Wiki-Seiten, 100+ Regeln zu fünf Regel-Dateien.
Outcome
Je kleiner die Oberfläche, desto verlässlicher das System. Was weg ist, kann nicht brechen.
2026-05-22
Incident
Eine einzige unverifizierte Behauptung in einer Konfigurationsdatei — dutzendfach gelesen, nie getestet — kostete 11.000 Token an Forensik, als sie brach.
Ursache: kein Zeitstempel. Eine Behauptung ohne Ablaufdatum wird irgendwann als Fakt behandelt.
Outcome
Jeder Wissens-Eintrag trägt seitdem last_verified + Methode. Abgelaufene Stempel flaggt eine tägliche Routine.
2026-05
Regel-Geburt
Sieben Aufgaben wanderten fast 200 Planungsrunden lang unangetastet mit. Nicht blockiert, nicht in Arbeit — nur mitgeschleppt. Die Automatik sah die Markierung, nicht die Absicht.
Mitschleppen ist kein Fortschritt. Es ist eine vertagte Entscheidung, die Zinsen anhäuft.
Outcome
Das Lane-Modell kennt kein Auto-Carry-over: Jedes Vorhaben endet mit Abnahme — oder mit einer dokumentierten Entscheidung dagegen.
03 · Warum so
Erkenntnis 01
Claude wird nicht schneller, wenn man ihm mehr Regeln gibt. Er wird schlauer, wenn er nur die Regeln liest, die im aktuellen Kontext relevant sind. Grundregeln immer, Prozess je Arbeitsstrang, Fachwissen nur bei Bedarf — das hat die Ergebnisse messbar verbessert.
Erkenntnis 02
Plan, Bau, Abnahme klingt nach Overhead. Ist aber das, was Wiederholungs-Schleifen verhindert: Der Plan wird vor der Arbeit verhandelt und reviewt, nicht danach. Der Kunde liest ein Konzept in seiner Sprache — und entscheidet genau zweimal.
Erkenntnis 03
17 Personas sind nicht 17 Rollen. Es sind 17 fokussierte Wissens-Container — jede mit eigenem Research-Zyklus, eigenen Patterns, eigenen Anti-Patterns. Aktiviert wird, wer im Vorhaben gebraucht wird. Der Rest schweigt.
04 · Anti-Patterns
Anti-Pattern 01
Verlockend, aber es rächt sich. Nach 5.000 Zeilen liest Claude nichts mehr sauber — die wichtigen Regeln gehen unter. Schichten und bedarfsweises Nachladen sind die Lösung.
Anti-Pattern 02
Wer den Rahmen nicht vorab festlegt, baut am Ziel vorbei. Der Plan-Akt erzwingt die unbequeme Frage „wann genau ist das Vorhaben fertig?" — bevor Code geschrieben wird.
Anti-Pattern 03
Jedes nicht aufgeschriebene Finding ist verlorenes Wissen. Regel 89 macht das zur Pflicht: jeder Bug, jede Idee, jede Lücke wird sofort Backlog-Item.
Anti-Pattern 04
Was digital lösbar ist, löst der Agent selbst (Regel 99). Scholly wird nur für Scope-Entscheidungen oder Handlungen in der realen Welt gefragt. Das spart pro Vorhaben fünf bis zehn unnötige Rückfragen.
05 · Was du mitnimmst
Schreib zwei kurze Dateien: behavior.md (was IMMER gilt) und workflow.md (wie ein Vorhaben abläuft). Wenige Dateien mit hartem Zeilen-Limit schlagen hundert verstreute Regeln.
Vor jeder Coding-Session: Scope, Deliverables, Abnahme-Kriterien — und ein Review des Plans, bevor gebaut wird. Ein einziges Markdown-File reicht. Kein Vorhaben ohne Vertrag.
Jeder Bug, jede Idee, jeder Lernmoment landet sofort in einem Backlog-File. Nicht „später", sondern jetzt. Drei Vorhaben später wirst du es dir danken.