Taproot 1.0: Wenn die Spec nicht mehr optional ist

«Eine gute Spec ist der wirkungsvollste Input, den man einer KI geben kann.» Diesen Satz habe ich in meinem Post über Spec-Driven Development geschrieben. Er stimmt weiterhin. Aber er hat eine Lücke: Eine Spec, die nicht durchgesetzt wird, ist eine Spec, die erodiert.

In demselben Post habe ich Taproot als eines von fünf Frameworks erwähnt — mein eigenes Projekt, das ich aus dieser Lücke heraus gebaut habe. Version 1.0 ist erschienen. Zeit, zu beschreiben, was es anders macht.

Das Problem hinter dem Problem

Fast alle etablierten Ansätze für Spec-Driven Development — PRDs, CLAUDE.md, User Stories im Wiki — haben eine gemeinsame Schwäche: Sie sind Vorschläge. Die Spec liegt im Projekt, der Entwickler soll sie beachten, der KI-Agent soll sie berücksichtigen, der Reviewer soll sie prüfen. Alle sollen. Niemand muss.

Das funktioniert, solange das Team diszipliniert ist und die Codebase klein bleibt. In echten Projekten driftet das System: Specs werden nicht aktualisiert, Code entsteht ohne Spec, ein Feature widerspricht einer Architekturentscheidung, die niemand mehr liest. Der KI-Agent wendet Security-Regeln sporadisch an — bei vier von fünf Formularen ist der CSRF-Schutz da, beim fünften fehlt er. Das ist kein Problem der Methode, sondern der Durchsetzung.

Von der Empfehlung zur Regel

Taproot basiert auf einer einzigen Entscheidung: Die Spec ist kein Dokument neben dem Code. Sie ist eine Commit-Bedingung.

Bei jedem git commit prüft ein pre-commit-Hook drei Dinge, je nachdem was committet wird:

• Neue Implementierung: Die zugehörige Behaviour-Spec muss vollständig sein (Definition of Ready) — Akteure benannt, Akzeptanzkriterien definiert, Edge Cases adressiert.
• Source Code: Tests müssen laufen, alle konfigurierten Bedingungen erfüllt sein (Definition of Done).
• Specs: Sie werden gegen die projektweiten Wahrheiten in taproot/global-truths/ geprüft. Eine Spec, die implizit sagt «Preise werden inklusive MwSt angezeigt», wird abgelehnt, wenn die Global Truth lautet «Preise sind immer exklusive MwSt». Der Widerspruch wird an dem Tag gefangen, an dem er entsteht.

Der Unterschied zu «die Spec sollte konsistent sein» ist nicht graduell, sondern kategorial. Aus Disziplin wird Mechanik.

Anforderungen als First-Class-Files

Specs leben als Markdown-Dateien im Repository, in einer dreistufigen Hierarchie:

taproot/
├── password-reset/        ← Intent: warum existiert das?
│   ├── intent.md
│   └── request-reset/     ← Behaviour: was tut das System?
│       ├── usecase.md
│       └── email-trigger/ ← Implementation: wie ist es gebaut?
│           └── impl.md

Jede Code-Datei lässt sich über diese Hierarchie auf ein Intent zurückverfolgen. Umgekehrt ist jede Anforderung ohne Code sichtbar, und jeder Code ohne Anforderung ebenfalls. Rückverfolgbarkeit ist kein Feature, das man zusätzlich pflegen muss — sie ergibt sich aus der Struktur.

Der Arbeits-Loop reduziert sich auf zwei Befehle: /tr-ineed user authentication beschreibt eine Anforderung, der Agent schreibt die Spec. /tr-implement taproot/auth/ baut Code, Tests und Traceability. Spec zuerst, Code danach, der Hook prüft beides.

Neu in 1.0: Planung über mehrere Anforderungen

Die meisten agentischen Workflows sind auf eine Anforderung zur Zeit ausgelegt. Das skaliert nicht, wenn man einem Agenten zehn Items vor einem Meeting hinterlassen möchte.

/tr-plan baut aus Backlog und unimplementierten Specs einen priorisierten Plan. /tr-plan-execute arbeitet ihn ab — autonom machbare Items laufen durch, Items mit menschlicher Entscheidung pausieren. Wer aus dem Kaffee zurückkommt, findet die autonomen Teile erledigt und die offenen Fragen sauber formuliert vor.

Was Taproot nicht ist

Taproot schreibt Intents, Use Cases und Implementation-Specs, verwaltet einen Backlog und plant die Abarbeitung — Funktionen, die man bisher über ein Ticket-System und einen Business Analysten abgedeckt hat. Für viele Projekte reicht das aus. Für grössere Organisationen mit eigenen Stakeholder-Prozessen ergänzt Taproot das bestehende Ticket-System, statt es zu ersetzen: Das Ticket trägt die Geschäftsentscheidung, die Taproot-Spec trägt die technische Wahrheit, und beide verweisen aufeinander.

Taproot ist auch kein neuer Agent. Es arbeitet mit Claude Code, Cursor oder Gemini. Die Logik liegt in den Files und im Git-Hook, nicht in einer proprietären Runtime — ein Wechsel des Agenten betrifft die Adapter-Konfiguration, nicht die Specs.

Und es ist kein Wasserfall. Specs entwickeln sich weiter; der Unterschied ist nur, dass Änderungen strukturell nachverfolgt werden, statt auf gute Absichten zu vertrauen.

Einstieg

npx @imix/taproot init

Das installiert den Adapter und den pre-commit-Hook. Für bestehende Codebases gibt es /tr-discover, das eine erste Hierarchie extrahiert — ein brauchbarer Startpunkt für Brownfield-Situationen, die man sonst gar nicht angehen würde.

Das Repository: github.com/imix/taproot. MIT-Lizenz. Feedback und Issues willkommen.

Die Position

Der vorherige Post endete mit der These, dass die besten KI-Ingenieure 2026 diejenigen sein werden, die begriffen haben, dass eine gute Spec der wirkungsvollste Input ist. Taproot geht einen Schritt weiter: Eine gute Spec ist notwendig, aber nicht hinreichend. Zusätzlich nötig ist ein Mechanismus, der garantiert, dass sie tatsächlich Wirkung entfaltet — auch wenn das Team müde ist, die Deadline drückt und der Reviewer überlastet.

Ob es gelingt, entscheidet die Praxis. Darum ist 1.0 ein Anfang, kein Abschluss.

Taproot entsteht bei Perito IT in Bern. Hands-on Workshops zu Spec-Driven Development auf Anfrage über perito.ch.