01 — Sprintplan mit Write-Scope
Arbeit, die größer ist als ein Commit, bekommt eine Datei. Diese Datei nennt das Ziel, die ausdrücklichen Nicht-Ziele und welche Datei wer schreiben darf — und sie ist zugleich der Stand. Damit überlebt das Vorhaben jeden Kontext-Reset.
Die Frage
Wie überlebt ein Vorhaben den Kontext-Reset?
Die Sprint-Datei ist der Zustand, nicht seine Beschreibung.
Das Problem
Ein KI-Assistent hat kein Gedächtnis über die Sitzung hinaus. Was nur im Chat-Verlauf steht, ist nach /clear, nach einem Kontext-Kompakt oder am nächsten Morgen weg. Zurück bleibt der Code — und der sagt nicht, was nicht dazugehören sollte.
Prüfliste
docs/plan/sprint-NN-<slug>.mdexistiert, undstatusentspricht der Realität.git diff --name-only main...HEADgegen die Write-Scope-Tabelle gehalten: keine Datei im Diff, die dort nicht steht. Handarbeit, zehn Sekunden — ein Skript dafür ist mehr Wartungslast als Ertrag.- Jedes Akzeptanzkriterium ist abgehakt oder im
## Ergebnisals bewusst offen benannt. - Jeder ausgelassene Schritt hat eine Zeile in der Abweichungstabelle.
## Ergebnisist gefüllt, bevorstatus: abgeschlossengesetzt wird.- Die Sprint-Datei beschreibt die Änderung — nicht noch einmal den Gesamtzustand.
VERSIONwurde außerhalb des Release-Sprints nicht angefasst.
Im Volltext
Diese Seite ist der Einstieg. Begründungen, Beispiele und Grenzen stehen im Volltext — eine Regel steht an genau einer Stelle, und das ist das Repo.
Volltext lesen: methode/01_Sprintplan-und-Write-Scope.md
Stand 2026-08-26 · Apache-2.0 · Fehler oder Gegenbeispiel bitte als Issue im Repo.