/governance · Long-form
This page explains the full system behind schollmayer.info. It also serves as the template for every other active project.
When you start with Claude Code, you hit two problems fast. First: the machine produces more output than a human can read. Second: without a process in place, that output becomes unmaintainable within weeks. Both problems are solved by governance — but only if it's not understood as bureaucracy.
The setup here is simple. Every initiative runs in three acts — plan, build, sign-off — with exactly two customer decisions. Plus 5 rule files, 17 thematic personas, and a mandatory review before every push. Sounds like overhead — but it's the opposite. It's a tool that lets one person ship faster than a team of five. And it's the result of radical pruning: a single release deleted 71,964 lines.
/04 · The system behind it
Claude Code without process is a demo. With process, it's a tool that lets one person ship more than a team of five. Every initiative runs in three acts — and the customer decides exactly twice.
8 mandatory steps: dependencies, architecture, tests, tech debt — checked by an IT-architect review before you see it.
Runs autonomously. Tests green, QA review before every push, deploy verified on the real product — not on a health check.
You verify the result visually. Then: learnings flow into the expert personas, the lane state is updated.
Two click anchors. Everything in between runs autonomously.
The customer decides exactly twice: plan OK and sign-off. No architecture questions, no in-between clicks — results instead of discussions.
Lane model · one initiative per threadBehavior, token doctrine, 17 architecture filters, workflow, customer requirements. Before: 121 scattered rules — until one release deleted 71,964 lines.
Lean release · 2026-05DevOps, QA, frontend, backend, content strategist, accounting … Each a focused knowledge container with its own research cycle. Only those needed get activated.
Rolling-slot researchNo plan without an IT-architect pass. No push without QA review. No knowledge entry without a verification stamp and expiry. Loop until ACCEPT.
Pair programming · loop until ACCEPT"Nothing goes live without customer sign-off. No push without a review ACCEPT. No knowledge without a verification stamp."
02 · Case studies
Not from theory — from what went wrong.
2026-05-22
Radical cut
Four months of building: 100+ rules, eight process phases, hundreds of memory files. Everything worked — and that was exactly the problem. The first serious stress test showed: complexity that demands discipline eventually consumes itself.
In one night, everything that demanded maintenance instead of delivering value was deleted: 162 knowledge files became 53 wiki pages, 100+ rules became five rule files.
Outcome
The smaller the surface, the greater the trust. What's gone can't break.
2026-05-22
Incident
A single unverified claim in a config file — read dozens of times, never tested — cost 11,000 tokens of forensics when it broke.
Root cause: no timestamp. A claim without an expiry date eventually gets treated as fact.
Outcome
Every knowledge entry now carries last_verified + method. A daily routine flags expired stamps.
2026-05
Rule born
Seven tasks moved forward through nearly 200 planning rounds — untouched. Not blocked, not in progress — just carried along. The automation saw the tag, not the intent.
Carry-over is not progress. It's a deferred decision collecting interest.
Outcome
The lane model has no auto-carry-over: every initiative ends with sign-off — or a documented decision against it.
03 · Why like this
Insight 01
Claude doesn't get faster when you give him more rules. He gets smarter when he only reads the rules relevant to the current context. Behavior always, process per lane, domain on demand — the output measurably improved.
Insight 02
Plan, build, sign-off sounds like overhead. It's what prevents redo loops: the plan is negotiated and reviewed before the work, not after. The customer reads a concept in their language — and decides exactly twice.
Insight 03
17 personas aren't 17 roles. They are 17 focused knowledge containers — each with its own research cycle, patterns, anti-patterns. Activated when an initiative needs them. The rest stays silent.
04 · Anti-patterns
Anti-pattern 01
Tempting, but it backfires. Past 5,000 lines, Claude can no longer read anything properly — the important rules get buried. Layers + on-demand loading is the answer.
Anti-pattern 02
Without a scope contract, you build toward a moving target. The plan act forces the uncomfortable question "when exactly is this done?" — before the code is written.
Anti-pattern 03
Every finding not written down is lost knowledge. Rule 89 makes it mandatory: every bug, every idea, every gap becomes a backlog item right away.
Anti-pattern 04
Anything digitally solvable, the agent solves itself (Rule 99). Scholly is asked only for scope decisions or physical actions. That saves 5-10 needless follow-ups per initiative.
05 · What you take away
Write two short files: behavior.md (always-on) and workflow.md (how an initiative runs). A few hard-capped files beat a hundred scattered rules.
Before every coding session: scope, deliverables, sign-off criteria — and a review of the plan before building. A single Markdown file is enough. No initiative without a contract.
Every bug, every idea, every learning lands in a backlog file right away. Not "later", but now. Three initiatives later, you'll thank yourself.