Blueprint

Nicht nur Code und Standard sind offen, sondern auch die Frage, wie man ein Bau-Unternehmen führt.

01 — These

Firma = Git-Organisation

Governance-Dokumente, Rollen, Entscheidungen und ihre Begründungen leben als versionierte Dateien in Git — nicht in einem separaten Wiki, das veraltet, sobald niemand mehr daran denkt, es zu pflegen. Wer wissen will, warum eine Entscheidung so gefallen ist, liest den Decision Record, nicht eine Zusammenfassung davon.

02 — Raster

Das [AI]/[AI→H]/[H]-Raster

Jede wiederkehrende Aufgabe wird einer von drei Kategorien zugeordnet:

AI Die KI erledigt es autonom
AI→H Die KI bereitet vor, ein Mensch entscheidet
H Menschliche Entscheidung, nicht delegierbar

Das Raster ist der Versuch, ehrlich zu benennen, wo Automatisierung Sinn ergibt — und wo sie es explizit nicht tut.

03 — Prinzip

Public-by-Exception

Standardmäßig ist alles privat. Veröffentlichung ist ein bewusster, freigegebener Schritt, kein Default — auch für dieses Blueprint-Repo selbst: Was hier landet, ist bereits durchdacht und freigegeben, kein Rohentwurf.

04 — Umfang

Was im ersten Release enthalten ist

Bewusst klein gehalten

Die Git-Organisation-These, ein Rollen-Datei-Template, das [AI]/[AI→H]/[H]-Raster als generalisierte Vorlage, und der Freigabe-Workflow für Entscheidungen. Release-Kadenz: quartalsweise. Kein Live-Spiegel, kein Sync-Versprechen — ein Release-Artefakt mit Version und Datum.

Wenn dich dieses Modell anspricht — als Gründer:in, die/der es kopieren will, oder als jemand, der Lust hat, es mitzubauen:

GitHub ↗