feat: Story 3.12 — Lease-Lifecycle und Commit-Abschluss transaktional schließen (Revision 3.7, §5.18; Sandbox L-1..L-9 9/9 harte PASS/Exit 0)

Co-Authored-By: Claude <noreply@anthropic.com>

schema/compiler.md

@@ -423,6 +423,21 @@ Die §5.11-Lease-Akquise (Pkt. 1 — Lockfile `lease/<area>/<id>.lock`, Merge-Ba
 5. **Kollisions-Hold an Epic 4 (AC-e, AD-17c/A0-14):** Zwei Branches mit **ungleichen Änderungen am selben Concept-Pfad** werden **nie textuell automatisch gemerged** (§5.11 Pkt. 4 bleibt textuell unverändert — kein textueller Auto-Merge, AD-17c). Erkennt der Run die Kollision, wird ein **strukturierter Kollisions-Hold mit beiden Commit-Hashes und dem Scope** an Epic 4 übergeben — in die benannte Hold-Mechanik (§5.16 Pkt. 8/§5.10 Pkt. 8): **Ablage-Stelle ist der datumsgruppierte `log.md`-Eintrag** (Header `YYYY-MM-DD`, neueste zuerst — Vertrag §5; Form: Quell-Pfad + `<Baseline-Commit>` + beide Commit-Hashes + Scope, §5.10-Pkt.-8-Form) — **keine Wissensmutation** statt eines automatischen Merges; **AD-16-Klassifikation und semantische Auflösung bleiben Epic 4 / Story 4.x**. Commit-Boundary = Mutations-Boundary (AD-17f, §0/§5.3/§5.11 Pkt. 5 unverändert); `log.md`-Eintragspflicht (Vertrag §5, §5.11 Pkt. 6 unverändert).
 6. **Abgrenzung (keine neue Dimension):** Keine Wanduhr-/Systemzeit in der Akquise (A0-20); keine Staleness-/TTL-/Recovery-Logik (bleibt §5.12/Story 3.6 und Story 3.12); keine Verwaist-/Stale-Behandlung und kein Lease-Branch-Lifecycle nach Übernahme (bleibt Story 3.12) — diese Sektion präzisiert ausschließlich die **Akquise-Atomarität** des Root-Scope im clone-geteilten Zustand; die §5.11-Pkt.-1-Formen (Branch, Lockfile, Merge-Base, Freigabe) und die §5.12-Dimension bleiben unverändert maßgeblich.
 
+## 5.18 Lease-Lifecycle & transaktionaler Commit-Abschluss (Story 3.12)
+
+Die Koordinations-Dimension ist über §5.11 (Leasing/Dirty-Tree, Story 3.5), §5.12 (Staleness/Recovery, Story 3.6), §5.13 (Phasen-Trennung, Story 3.7) und §5.17 (atomare Root-Scope-Lease-Akquise, Story 3.11) verankert — diese Sektion ist die **geschlossene, transaktionale Lifecycle-Klammer** darüber (D-3, Story 3.12; AC-1..AC-7; A0-20 — keine Wanduhr-/Systemzeit-Steuerung, Lifecycle deterministisch aus dem committeten Git-State, AD-17h/A0-19): sie ordnet Akquise (§5.11/§5.17), Preflight/Protect (§5.11 Pkt. 3), Mutation (§5.9/§5.10/§5.16), Rollback (§5.13) und durable Release (§5.11 Pkt. 1/§5.17 Pkt. 1) in eine **eindeutige Zustandsmaschine**, so dass SUCCESS und FAIL je einen sauberen, wiederanlaufbaren Zustand hinterlassen. **Fugen-Identität:** §5.11 (Pkt. 1–7), §5.12 (Pkt. 1–7), §5.13 und §5.17 bleiben **textuell unverändert** — die Lifecycle-Regie ist die von §5.17 Pkt. 1/6 benannte Fortsetzung („Lifecycle-Regie Story 3.12"). Sie fügt **kein** Prädikat, **keine** neue §7-Invaliditätsklasse, **keinen** `schema/wiki-compiler.md`-/`schema/validator.md`-/`adapters/`-/`raw/`-Change (AD-3), **keinen** neuen Frontmatter-/Format-Key (Vertrag §3.1–§3.7 unverändert), **keinen** Standalone (D-3) und **keine** Wanduhr-/Systemzeit hinzu (A0-20).
+
+1. **Liveness & Ownership — Staleness verlangt bestätigten Abbruch/abgelaufene Liveness plus atomare Ownership-Prüfung (AC-1):** Eine lebende Lease wird durch eine **höhere sichtbare Generation allein nicht stale** — Staleness folgt nie aus Kalenderzeit (A0-20: keine Time-To-Live über Wanduhr) und nie allein aus der Gen-Registry (§5.12), sondern aus **committeten Zuständen plus bestätigtem Abbruch oder abgelaufener Liveness**: die Lease gilt als stale (i) wenn der Halter seine Liveness **bestätigt abgebrochen** hat (deterministisch belegt aus dem committeten Git-State, z. B. Halter-Branch-Verlust, abgebrochener Run ohne durable Release, Registry-Status) oder (ii) wenn die **Liveness abgelaufen** ist — ein beobachtbarer Zustand, der aus den committeten Registrierungs-/Markierungs-Zuständen ableitbar ist (§5.12 Gen-/Stale-Marker), nicht aus einem Zeitstempel. **Keine Fremd-Staleness ohne Ownership-Prüfung:** die Stale-Bewertung selbst ist eine **atomare Ownership-Prüfung** — sie verifiziert gegen den geltenden Halter-Zustand (Lock-Inhalt/Inhaber-Run-ID, §5.17 Pkt. 1) und den Registry-Status, bevor irgendeine Übernahme-/Freigabe-Entscheidung greift. Eine höhere Generation führt nur dann zu einer Stale-Klassifikation, wenn zugleich der bestätigte Abbruch/die abgelaufene Liveness vorliegt (Verwaist-Klassifikation, §5.12 Pkt. 3 — Determinismus aus dem committeten Zustand, AD-17h/A0-19).
+2. **Stale-Übernahme genau einmal — benannte ersetzte Holder-ID, genau eine aktive Root-Lease (AC-2):** Ist eine Lease nachweislich stale (Pkt. 1), übernimmt ein neuer Producer den Root-Scope **genau einmal** — nie zwei Übernehmer, nie zwei aktive Root-Leases (AK-2: die Übernahme ist ownership-gebunden: nur wer den Root-Scope-Lock (§5.17 Pkt. 1) nach der atomaren Ownership-Prüfung erwirbt, wird neuer Inhaber; die Ersetzung erfolgt als **Ref-Schreibvorgang auf den scope-bezogenen Lock** mit neuem Lock-Inhalt — die **ersetzte Holder-ID wird im datumsgruppierten `log.md`-Eintrag benannt** (Vertrag §5; Form: Quell-/Scope-Pfad + `<Baseline-Commit>` + alte Holder-ID + neue Holder-ID), so dass die Übernahme vollständig nachvollziehbar ist und **genau eine** aktive Root-Lease bestehen bleibt (Kardinalität 1, §5.17 Pkt. 2). Die verwaiste Lease wird **nie still gelöscht** (AD-17e): die Registry-Zeile und der per-Lease-Lockfile-/Branch-Ablage-Zustand (§5.11 Pkt. 1) bleiben als Verwaist-/Stale-Nachweis erhalten (§5.12 Pkt. 3/6).
+3. **Eindeutige Abort-/Protect-Zustandsmaschine für fremde getrackte/ungetrackte Änderungen (AC-3):** Vor jeder Mutation läuft der Preflight (§5.11 Pkt. 3 — Pre-Mutation-Prüfung `git status --porcelain -- <Mutationsbereich>`; `UNCOMMITTED_INPUT`-Abbruch „published/committed Input erforderlich" bleibt §5.11 Pkt. 3-/§5.9-P2-Element-(1)-gebunden, kein zweiter Abbruch-Pfad) und versetzt den Run in eine **eindeutige Abort-/Protect-Zustandsmaschine** für **fremde** (nicht dem Run gehörende, producer-fremde) uncommittete Änderungen im Mutationsbereich:
+   - **getrackte fremde Änderung** (modifizierte committete Datei): **Schützen** — Sicherung in die **Scratch-Zone `scratch/<run-id>/`** (außerhalb `wiki/`, deterministisch benannt) oder via **`git stash push -- <Pfad>`** (§5.12 Pkt. 5 zulässige native Variante); der Arbeitssatz wird für den Run bereinigt; **Restore nach Run-Ende byte-identisch** aus der Sicherung (SHA-256-/Byte-Identitäts-Prüfung in beide Richtungen) — nie gelöscht (AD-17e). Abort-Pfad: greift die Schutz-Sicherung nicht (z. B. Sicherung nicht byte-identisch restaurierbar), **HALT des Runs** mit textuell benannter Ursache (NFR-4) und Zustands-Restaurations-Invariante (§5.13 Pkt. 3).
+   - **ungetrackte fremde Datei** im Mutationsbereich: **Protect** — die Datei wird in die Scratch-Zone gesichert (bzw. via `git stash push -u` eingeschlossen) und nach dem Run **byte-identisch restauriert**; **keine stille Löschung** (AD-17e); der Schutz wird im `log.md`-Eintrag dokumentiert (Vertrag §5, §5.11 Pkt. 3 „Dirty-Tree-Schutz-Dokumentation").
+   - **Nicht betroffene Bereiche/Dateien unverändert:** nur die benannten fremden Dateien werden geschützt/restauriert — kein Eingriff darüber hinaus (Erhaltungs-Invariante §5.9 Pkt. 5). Diese Zustandsmaschine ersetzt den Inline-Ablauf der Story-3.5-Sandbox (L4) durch eine eindeutige, je Zustand definierte Überführung (UNCOMMITTED_INPUT → SCHUETZEN → MUTIEREN → RESTORIEREN).
+4. **Baseline-Rollback — Index + Worktree aus `<Baseline-Commit>`, Post-Rollback-Diff leer (AC-4):** Tritt ein Fehler **nach Mutation oder Staging** auf (I/O-Matrix `ROLLBACK_NACH_MUTATION`, Kill-Punkt nach Mutation), rollt der Run aus dem **bezeichneten Baseline-Commit `<Baseline-Commit>`** zurück — **Index und Worktree** werden explizit restauriert: `git reset --hard <Baseline-Commit>` stellt beide wieder her (deterministisch, ohne Wanduhr — zulässige Realisierung; die §5.3-/§6-Pkt.-3-Mechanik nennt nur Bundle-/`git checkout`-Wiederherstellung, hier wird der Index **explizit** mitgeführt). **Post-Rollback-Diff gg. Baseline leer:** nach dem Rollback ist der Diff gegen `<Baseline-Commit>` leer (Zustands-Restaurations-Invariante, §5.13 Pkt. 3). **Kill-Punkt nach Mutation/Staging** (Pkt. 7): auch an diesem Kill-Punkt endet der Run in einem konsistenten Zustand — entweder Zustand == Baseline (Rollback) oder valide committet, nie ein Teilzustand (Commit-Boundary = Mutations-Boundary, AD-17f unverändert).
+5. **Durable Release (AC-5):** Erst nach dem durativen Abschluss ist die Lease frei: (1) die **Mutation** ist committet (Bundle == valide committeter Zustand, Commit-Boundary = Mutations-Boundary, AD-17f unverändert), (2) der **zulässige Log-/Koordinationsnachweis** (Vertrag-§5-/§5.11-Pkt.-6-Einträge: Lease-Akquise, Dirty-Tree-Schutz, Merge-Klassifikation, Eskalation, Freigabe; `<Baseline-Commit>` notiert) ist committet — `wiki/log.md` ist die einzige Aufzeichnungs-Stelle im Bundle (kumulativer Registry-Aufbau liegt außerhalb, §5.12 Pkt. 6), (3) der **aktive scope-bezogene Lock wird per Ref-Delete entfernt** (`git update-ref -d <lock-ref>`) — **nur durch den Inhaber** (Ownership: der Lock-Inhalt muss die Run-ID des freigebenden Producers tragen, §5.17 Pkt. 1/3 — „entfernt keine fremde Lease"), (4) der **Worktree ist sauber** (geschützte Fremd-Bytes restauriert, keine uncommitteten Reste, kein hängender Lock). **Clean-Input-Guard (Nachfolger-Bedingung):** der **unmittelbar folgende Run** muss ohne `INPUT_UNCOMMITTED`-Abbruch starten können — d. h. sauberer Worktree, kein hängender Lock, geschützte Fremd-Bytes sind restauriert (Kill-Punkt „nach Commit" antizipiert genau diesen Zustand, Pkt. 7). **Release-Fehler (Ref-Delete scheitert, Lock bleibt hängen, Worktree verschmutzt) = HARD-FAIL:** der Run endet nicht durativ; der Zustand wird textuell benannt (NFR-4) und bis zur Zustands-Restaurations-Invariante (§5.13 Pkt. 3) korrigiert — der Lock hängt nie.
+6. **Kanonisches Log (AC-6):** Das kanonische Knowledge Log `wiki/log.md` enthält **nur vertragskonforme fachliche Änderungen und die notwendigen Koordinationsereignisse** (Vertrag §5; §5.11 Pkt. 6; §5.12 Pkt. 7): Lease-Akquise, Dirty-Tree-Schutz-/Preflight-Dokumentation, Stale-/Liveness-/Übernahme-/Freigabe-Ereignisse, Merge-/Eskalations-/Hold-Klassifikationen, fachliche Update-/Synthese-/Neu-Anlage-Einträge. **Build-, Review-, Story- und Sandbox-Historie liegen außerhalb des Knowledge Bundle** (Run-Receipts außerhalb des Bundles, §5.14 Pkt. 2; Sandbox-Nachweise in `_bmad-output/...`; Sprint-/Status-Akten außerhalb `wiki/`). Ein Verstoß gegen die kanonische Grenze wird **textuell benannt** (NFR-4) und vor dem Commit korrigiert.
+7. **Kill-Point-Tests (AC-7):** Der Lifecycle wird an **vier Kill-Punkten** auf konsistente Endzustände geprüft (je Kill-Punkt deterministisch, AD-17h/A0-19, Zustands-Restaurations-Invariante §5.13 Pkt. 3): (a) **vor Mutation** — Zustand == Baseline, keine Zwischenstände, kein Ghost-Diff (Probe §5.9 Pkt. 5), (b) **nach Mutation** — Zustand == valider Zwischenstand (geplanter Plan-Freeze, §5.13 Pkt. 2), kein Ghost-Diff außerhalb der erlaubten Pfad-Menge (Kandidatenliste ∪ Neu-Anlage ∪ `log.md` ∪ nachgeführte `index.md`), (c) **vor Commit** — nur die erlaubte Pfad-Menge ist staged, kein Teilzustand veröffentlicht (Commit-Boundary = Mutations-Boundary, AD-17f unverändert), (d) **nach Commit** — Bundle == valide committeter Zustand, anschließbar an den Clean-Input-Guard (Pkt. 5: kein hängender Lock, sauberer Worktree, geschützte Fremd-Bytes restauriert). Jeder Kill-Punkt beweist damit den **jeweils konsistenten Endzustand** — nie einen Teilzustand als fertige Mutation (§5.13 Pkt. 4, AD-17f unverändert).
+
 ## 6. Validieren (mechanische Bestätigung)
 
 1. Nach Abschluss aller Mutationen wird das gesamte Bundle gemäß `schema/validator.md` geprüft (§3 14 Punkte je Datei + §6-Fachprüfungen; Verdikt-Grammatik §5).
@@ -477,7 +492,7 @@ Diese Instruktion ist auf die **Erzeugung neuer Concepts auf Root-Ebene und in A
 - **Progressive Discovery über `index.md`** (Navigation, Area-Indizes) — in **§5.8** dieser Instruktion verankert (Story 2.5; AD-9, FR-11, AD-13, NFR-3). **Suche** bleibt konsumenten-/extern-seitig (Consumer-grep über `wiki/`, §5.8 Pkt. 4 — kein Bundle-/Instruktions-Thema mehr). Keine neue §7-Klasse, kein Schema-/Validator-Change.
 - **Eine genau-eine-Linkform** (file-relativ mit `.md`-Endung, in Areas `../`-fähig) — in **§5.6** dieser Instruktion gepinnt (Story 2.3; AD-7b, A0-9, FR-10; Auflösungsmodell §5.7 Pkt. 4) — der Punkt-11-Check des Validators akzeptiert bis auf Weiteres beide Schreibweisen (strukturell unverändert, Story-2.2-Präzedenz).
 - **Synthese über mehrere Sources** (mehrere `raw/`-Quellen → eine gemeinsame Wissensrepräsentation mit gemischter, claim-granularer Provenienz) — **in §5.10** dieser Instruktion verankert (Story 3.4; AD-4, FR-7). Die Verankerung des inkrementellen Datenflusses (Erweitern/Präzisieren/Korrigieren einzelner bestehender Concepts) bleibt **§3 + §5.9** überlassen und ist dort bereits verankert (Story 3.1). Beide sind damit aus diesem Vorbehalt entlassen.
-- **Leasing / Dirty-Tree-Schutz** für konkurrierende Producer — **in §5.11 dieser Instruktion verankert** (Story 3.5; AD-17a..f, A0-12..A0-16; die Enum enthält AD-17d/A0-15 nur als **Norm-Rückverweis** — die §5.11-Auflösung selbst schließt Staleness aus und delegiert an Story 3.6, Pkt. 7-Seam-Kriterium): Lease-Akquise auf `lease/<area>/<id>`-Branches mit Lockfile und Merge-Base-Disziplin, Root-Scope-Lease inkl. `log.md`/`index.md`, Dirty-Tree-Schutz mit Stash/Scratch-Zone und `log.md`-Dokumentation, compiler-vermittelter Merge als AD-16-Pfad, kein textueller Auto-Merge, Commit-Boundary = Mutations-Boundary, Lease-Freigabe (Release, deterministisch); die bestehende Commit-Boundary = Mutations-Boundary-Regel (§0/§5.3, AD-17f) bleibt unverändert bestehender Schutz. **Lease-Staleness/Recovery** (TTL, Lease-Registrierung, verwaiste Leases, `raw/`-Recovery; AD-17d, A0-15) — **in §5.12 dieser Instruktion verankert (Story 3.6)**. **Story-3.11-Verankerung:** die atomare Root-Scope-Lease-Akquise ist in **§5.17 dieser Instruktion** verankert (Story 3.11, Atomare Root-Scope-Lease-Akquise): der Exklusivitätsschlüssel ist ein einziger, scope-bezogener Lock im clone-geteilten Zustand (geteilter Git-Ref-/Objektnamespace aller Worktrees und Prozesse eines Clones — `git update-ref <lock-ref> <wert> $ZERO_SHA`, create-only), die Run-ID ist Lock-Inhalt statt Schlüsselbestandteil (AC-a), die Akquise ist atomar mit genau einem Gewinner und `LEASE_HOLD` für den Abgewiesenen (AC-b/c, §5.11-Pkt.-1-Lease-Hold unverändert), Kollisions-Hold mit beiden Commit-Hashes an Epic 4 statt textuellem Auto-Merge (AC-e, AD-17c/A0-14). Keine neue §7-Klasse, kein Schema-/Validator-Change, keine Vertragsänderung; keine Wanduhr/Systemzeit (A0-20), keine Staleness-/Recovery-Logik (bleibt §5.12/Story 3.12); §5.11-Pkt.-1/2-Wortlaut und §5.12-Anker bleiben unverändert (Fugen-Identität).
+- **Leasing / Dirty-Tree-Schutz** für konkurrierende Producer — **in §5.11 dieser Instruktion verankert** (Story 3.5; AD-17a..f, A0-12..A0-16; die Enum enthält AD-17d/A0-15 nur als **Norm-Rückverweis** — die §5.11-Auflösung selbst schließt Staleness aus und delegiert an Story 3.6, Pkt. 7-Seam-Kriterium): Lease-Akquise auf `lease/<area>/<id>`-Branches mit Lockfile und Merge-Base-Disziplin, Root-Scope-Lease inkl. `log.md`/`index.md`, Dirty-Tree-Schutz mit Stash/Scratch-Zone und `log.md`-Dokumentation, compiler-vermittelter Merge als AD-16-Pfad, kein textueller Auto-Merge, Commit-Boundary = Mutations-Boundary, Lease-Freigabe (Release, deterministisch); die bestehende Commit-Boundary = Mutations-Boundary-Regel (§0/§5.3, AD-17f) bleibt unverändert bestehender Schutz. **Lease-Staleness/Recovery** (TTL, Lease-Registrierung, verwaiste Leases, `raw/`-Recovery; AD-17d, A0-15) — **in §5.12 dieser Instruktion verankert (Story 3.6)**. **Story-3.11-Verankerung:** die atomare Root-Scope-Lease-Akquise ist in **§5.17 dieser Instruktion** verankert (Story 3.11, Atomare Root-Scope-Lease-Akquise): der Exklusivitätsschlüssel ist ein einziger, scope-bezogener Lock im clone-geteilten Zustand (geteilter Git-Ref-/Objektnamespace aller Worktrees und Prozesse eines Clones — `git update-ref <lock-ref> <wert> $ZERO_SHA`, create-only), die Run-ID ist Lock-Inhalt statt Schlüsselbestandteil (AC-a), die Akquise ist atomar mit genau einem Gewinner und `LEASE_HOLD` für den Abgewiesenen (AC-b/c, §5.11-Pkt.-1-Lease-Hold unverändert), Kollisions-Hold mit beiden Commit-Hashes an Epic 4 statt textuellem Auto-Merge (AC-e, AD-17c/A0-14). Keine neue §7-Klasse, kein Schema-/Validator-Change, keine Vertragsänderung; keine Wanduhr/Systemzeit (A0-20), keine Staleness-/Recovery-Logik (bleibt §5.12/Story 3.12); §5.11-Pkt.-1/2-Wortlaut und §5.12-Anker bleiben unverändert (Fugen-Identität). **Story-3.12-Verankerung:** der geschlossene Lifecycle (Akquise → Preflight/Protect → Mutation → Rollback → durable Release → Clean-Input-Guard) ist in **§5.18 dieser Instruktion** verankert (Story 3.12, Lease-Lifecycle & transaktionaler Commit-Abschluss): Liveness & Ownership — eine höhere Generation allein macht eine lebende Lease nicht stale, Staleness verlangt bestätigten Abbruch/abgelaufene Liveness plus atomare Ownership-Prüfung (AC-1); stale-Übernahme genau einmal mit benannter ersetzter Holder-ID und genau einer aktiven Root-Lease (AC-2); eindeutige Abort-/Protect-Zustandsmaschine für getrackte/ungetrackte fremde Änderungen mit byte-identischem Restore (AC-3); Baseline-Rollback **Index + Worktree** aus `<Baseline-Commit>` mit leerem Post-Rollback-Diff (AC-4); durable Release (Mutation + zulässiger Log-/Koordinationsnachweis committet, Lock per Ref-Delete, Worktree sauber, Folge-Run besteht den Clean-Input-Guard, AC-5); kanonisches Log — `wiki/log.md` nur vertragskonforme fachliche Änderungen + notwendige Koordinationsereignisse (AC-6); Kill-Point-Tests vor Mutation/nach Mutation/vor Commit/nach Commit je konsistenter Endzustand (AC-7). Keine neue §7-Klasse, kein Schema-/Validator-Change, keine Vertragsänderung; keine Wanduhr/Systemzeit (A0-20); §5.11-Pkt.-1/2-Wortlaut und §5.12-Anker bleiben unverändert (Fugen-Identität).
 - **Relevanzbestimmung** (feinkörniger Relevanz-Findungsmechanismus der Kandidatenerhebung) — in **§3.2** dieser Instruktion verankert (Story 3.2; Term-Ziehverfahren + Kanonisierungs-Resolver `schema/canonical-terms.md`, drei Erhebungs-Stufen grep/ripgrep + `index.md`-Traversal + Link-Following mit besuchter Menge, `log.md`-Exklusion, Candidate-Liste als relative OKF-Pfade ohne `.md`, Determinismus-Vertrag AD-17h/A0-19). Keine neue §7-Klasse, kein Schema-/Validator-Change; die Em-Dash-`—`-Varianten-Lücke ist als Determinismus-Frage an Story 3.8 übergeben. **Story-3.8-Auflösung:** die Determinismus-Frage ist in **§5.14** dieser Instruktion verankert (Story 3.8, Determinismus-Vertrag & Agent-Instruktions-Validator): die Em-Dash-Kollaps-Klasse, die Kollaps-Reichweite und der Match-Scope der Stufe a sind in **§3.2-Pkt.-1b** als geschlossene, deterministische Regel-Ergänzungen verankert; die Orphan-Politik ist in **§5.10 Pkt. 8** als deterministische Reconcile-Orphan-Regel präzisiert; die `generated.at`-Wanduhr-Gap-Ausnahme ist in §5.14-Pkt.-3 in die **Ausnahme-Menge** des Bundle-State-Vergleichs gefasst (A0-20-Konvention, Ask-First-geschützt). Keine offene Determinismus-Frage verbleibt (bestehende Story-Bullets unverändert). **Scope-Präzisierung (Review-Loop-3, P-8):** dies gilt für die **mit Story 3.8 geschlossenen** Determinismus-Fragen (Em-Dash-Kollaps-Klasse, Kollaps-Reichweite, Match-Scope Stufe a, Reconcile-Orphan-Regel, `generated.at`-Wanduhr-Gap-Ausnahme); bewusst nicht damit geschlossen bleibt die Umlaut-vs-Transkription-Divergenz im Match-Pfad (benannter Defer, `_bmad-output/implementation-artifacts/deferred-work.md` Defer-Block Review-Loop-3 — kein Instruktions-Defekt); die vormals „noch nicht verankerten" Story-3.9-ACs (Term-Gewinnung/Routing) sind dagegen seit der **Story-3.9-Verankerung** in **§5.15 dieser Instruktion** geschlossen (Deterministische Relevanz- & Reconcile-Routing: eine exklusive Routing-Tabelle UPDATE/CREATE/ORPHAN-HOLD/NO_OP — NO_OP als Update-Unter-Entscheidung, leere Candidate-Liste → Zellen 2/3; Termgewinnung geschlossen inkl. Status-Codes A/M/D/R/C, symmetrische Normalisierung mit **einer** Kollaps-Definition (§3.2-Pkt.-1b), Raw-Immutability-Guard, reservierte Zielpfade, Zwei-Run-Identität mit praktisch ausgeübter `at`-Exzeption) — keine stillen offenen Fragen. **Story-3.10-Verankerung:** die Erhaltungs-Absicherung des laufenden, gemischten Runs und der Hold-Ausbau sind in **§5.16 dieser Instruktion** verankert (Story 3.10, Inkrementelle Update- & Synthese-Erhaltung + Hold-Ausbau): Kontinuitäts-Garantie (AC-1), Korrigieren mit Run-Receipt-Trace (AC-2), Schutzbestandteile & Byte-Identität (AC-3), CONFIRMING-Konsolidierung (AC-4 — bestätigende neue Source mit neuem Evidenzanker ist Konsolidierungs-Update, kein NO_OP), gemeinsame Wissensrepräsentation als Synthese-Erhaltung (AC-5), byte-erhaltender NO_OP (AC-6 — nur bei vollständiger Evidenzanker-Menge), Provenienz-/Link-Selbsttest aus aktuellem Run (AC-7 — Baseline = `<Baseline-Commit>`, keine historischen Zählwerte normativ), benannter Hold (AC-8 — post-Reconcile-Orphan über alle Erhebungs-Stufen a/b/c, Mehrziel-Auflösung, beide Evidenzpfade im Run-Receipt; NFR-7). Keine neue §7-Klasse, kein Schema-/Validator-Change, keine Vertragsänderung; AD-16-Klassifikation bleibt Epic 4; die §5.9-Abgrenzungs-Reihenfolge bleibt die einzige Form-Wahl.
 - **Reason/Mutate-Phasen-Trennung & Konsistenz-Endzustand** (logische Phasen-Disziplin: Analyse → Änderungsplanung → Mutation → Validierung, AD-6/A0-7, AC-1/AC-2/AC-3/AC-4) — **in §5.13 dieser Instruktion verankert (Story 3.7; D-3):** Änderungsplanung als institutionalisierter §5.9-Pkt.-6-P2-Block (textuell festgehalten, Plan-Defizit = textuell benannte Abbruch-Kette vor der Mutation), Plan-Freeze = Veränderungs-Sperre an die §5.9-Pkt.-5-Ghost-Diff-Kopplung (erlaubte Pfad-Menge: Kandidatenliste ∪ Neu-Anlage ∪ `log.md` ∪ `index.md`), Zustands-Restaurations-Invariante (Post-Rollback-Diff gg. Baseline leer / Bundle == valide committet, §5.3-Pkt.-3-/§6-Pkt.-3-Rollback unverändert), kein Teilerfolg als fertige Mutation (AD-17f), keine eigene Workflow-Engine (logische Trennung in einer Session, kein Prozess/Server/MCP, D-3/AD-11). Keine neue §7-Klasse, kein Schema-/Validator-Change, keine Vertragsänderung.
 - **Standalone-Compiler / eigene LLM-Runtime / MCP** → verboten in v1 (D-3, D-4, AD-11).
@@ -525,3 +540,4 @@ Diese Instruktion ist auf die **Erzeugung neuer Concepts auf Root-Ebene und in A
 - **Revision 3.4 (2026-08-20, Story 3.9):** Neue Sektion **§5.15 „Deterministische Relevanz- & Reconcile-Routing (Story 3.9)"** eingefügt (nach §5.14, vor §6) — die **geschlossene Routing-Ebene des Reconcile** (AD-17h/A0-19, Story 3.9; §5.14-Pkt.-5-/§7-„Story-3.9-ACs noch nicht verankert"-Vorbehalt aufgelöst): (1) **Termgewinnung** — geschlossener, geordneter Algorithmus aus der Zuwachs-Sicht (Dateiname→Term-Mapping, `source.md`-Sidecar-Exklusion, Status-Codes `A`/`M`/`D`/`R`/`C` via `--diff-filter=ACMR` mit der Akzeptanz-Regel A/C (akzeptiert) vs. M/D/R (Run-FAIL) aus Pkt. 4, §5.9-Pkt.-6-Diskrepanz-/Fallback-Kopplung, Diff↔Manifest-Äquivalenz, Mehrfach-Term-Vereinigung D-8 aufgegriffen; **eine** Kollaps-Definition §3.2-Pkt.-1b), (2) **symmetrische Normalisierung + literal-sichere Suche** (AC-2; `index.md`-Treffer → Traversal-Stufe, kein Konzept-Kandidat), (3) **eine exklusive Routing-Tabelle** (AC-3; UPDATE → CREATE → ORPHAN/HOLD → NO_OP; **NO_OP als Update-Unter-Entscheidung** — leere Candidate-Liste bei neuer Evidenz → Zellen 2/3, nie NO_OP; CREATE-vs-ORPHAN-Prädikat; Stufe-b-Zelle konsistent), (4) **Raw-Immutability-Guard** (AC-4; M/D/**R** → Run-FAIL vor jeder Mutation, A/C akzeptiert), (5) **reservierte Zielpfade** (AC-5; erschöpfende Liste `index`/`log`/`source`/`README`, Ist-Dateimenge via `git ls-tree`-Schnittmenge, deterministischer Hold), (6) **Zwei-Run-Identität** (AC-6; positive UND negative Fixtures, Zwei-Worktree-Vergleich, praktisch ausgeübte `at`-Exzeption — die einzige benannte Differenz). **§3.2:** der NO_MATCH-Anker (Pkt. 3d) als §5.15-Verweis-Anker nachgeführt (leere Candidate-Liste bei neuer Evidenz → Zellen 2/3, nicht NO_OP; `UNTOUCHED_CONCEPT` gilt für den Ghost-Diff-negativen Fall ohne Zuwachs). **§5.14 Pkt. 5:** Scope-Präzisierung nachgeführt (Story-3.9-ACs sind verankert). **§7:** Relevanzbestimmung-Bullet um die §5.15-Verankerung erweitert (Story-3.9-Vorbehalt aufgelöst; bestehende Story-Bullets unverändert). **§8:** AD-17h-/A0-19-/A0-18-Reihe bereits in §5.14 verankert — §5.15 referenziert sie (Fugen-Identität). **Abschlussklausel (Story 3.9):** Keine Änderung an `schema/wiki-compiler.md`/`schema/validator.md`/`adapters/`/`raw/` (AD-3); **keine neue §7-Invaliditätsklasse**; **keine fünfte Routing-/Update-Klasse**; **kein Standalone** (D-3); keine Vertragsänderung; **kein neuer Prädikat-/Format-/Frontmatter-Key**; `schema/canonical-terms.md` unverändert (kein neuer Normalisierungs-Operand — Umlaut-vs-Transkription bleibt benannter Defer); Commit-Boundary-Regel unverändert; Hold-Ausbau (post-Reconcile-Orphan, Mehrziel) bleibt Story 3.10; AD-16-Klassifikation/semantische Auflösung bleibt Epic 4. **`sprint-status.yaml`:** Key `3-9-deterministische-relevanz-und-reconcile-routing-schliessen` auf **`review`** geflippt (Implementierungs-Commit; finaler `done`-Flip im Step-05-Status-Sync nach abgeschlossenem Review-Loop — Präzedenz Revision 3.2/3.3). **Review-Loop-2-Auflösung (Re-Ableitung):** Kern-Defekt BS-L2-1 (NO_MATCH/leere Candidate-Liste nicht NO_OP, sondern Zellen 2/3) und BS-L2-2 (Status-Codes inkl. R/C) behoben; Sandbox um R-1-Negativ-Manifest, R-3-Fall-2-Evidenzvergleich, R-5-CREATE-Bewertungsraum, R-6/R-7-Slug-Ableitung + `git ls-tree`-Schnittmenge, R-8-Zwei-Worktree-Hold, R-9-`at`-Exzeption, harmonisierte `norm()` (eine Kollaps-Definition) ertüchtigt (Details siehe Spec Change Log Loop-2 und `wiki/log.md`-Eintrag).
 - **Revision 3.5 (2026-08-21, Story 3.10):** Neue Sektion **§5.16 „Inkrementelle Update- & Synthese-Erhaltung + Hold-Ausbau (Story 3.10)"** eingefügt (nach §5.15, vor §6) — die **operationelle Erhaltungs-Klammer** über den textuell unveränderten §5.9/§5.10/§5.15-Mechaniken (D-3, Story 3.10; A0-21-Incrementality-Teil, FR-4/FR-6/FR-12, AD-4/AD-5; §5.15-Zelle-3-/§5.15-Scope-Präzisierung-/§5.10-Pkt.-8-D-4-Hold-Home hierin verankert): (1) **Kontinuitäts-Garantie** (AC-1; in-place Update/Synthese, kein Duplikat, Identität + Index-Link erhalten), (2) **Korrigieren mit Run-Receipt-Trace** (AC-2; ersetzte Wortlautfolge + Source-Basis im Run-Receipt außerhalb des Bundles, §5.14 Pkt. 2; mehrdeutig → benannter Hold Epic 4), (3) **Schutzbestandteile & Byte-Identität** (AC-3; gültige belegte Aussagen, §5.5-Inline-Verweise, `sources` gültiger Belege, §5.6-Links, human-`verified` bleiben erhalten; nicht betroffene Concepts byte-identisch, §5.9 Pkt. 5), (4) **CONFIRMING-Konsolidierung** (AC-4; bestätigende neue Source mit neuem Evidenzanker → Aussage genau einmal, alle Anker via §5.5-Multi-Beleg, `sources`-Zuwachs, `at`-Bump, **kein NO_OP** — Stellen-Abgleich auf den Anker, nicht auf den Inhalt), (5) **gemeinsame Wissensrepräsentation als Synthese-Erhaltung** (AC-5; §5.10-Pkt.-2/3/5, Update auf bestehendes Concept = Erweiterung, keine Neuschreibung), (6) **byte-erhaltender NO_OP** (AC-6; nur bei vollständig identischer Evidenz **samt vollständiger Evidenzanker-Menge** — kein `at`-Bump, kein `sources`-Zusatz, kein `log.md`-Eintrag; fehlender Anker → Pkt. 4), (7) **Provenienz- & Link-Selbsttest aus aktuellem Run** (AC-7; Baseline = `<Baseline-Commit>` des aktuellen Runs, erwartete Delta-Menge = Kandidatenliste ∪ Neu-Anlage ∪ `log.md` ∪ nachgeführte `index.md`; kein historischer Commit/globaler Zählwert normativ), (8) **benannter Hold** (AC-8/NFR-7; post-Reconcile-Orphan über **alle** Erhebungs-Stufen a/b/c — die Story-3.9-Sandbox übte nur Stufe a (§5.15-Pkt.-6-Scope-Präzisierung aufgegriffen) —, Mehrziel-Auflösung via D-8-Mehrfach-Term-Vereinigung auf eine primäre Ziel-Repräsentation, sonst fail-closed Hold; widersprüchliche/klassifikationspflichtige Evidenz ohne Wissensmutation; beide Evidenzpfade im Run-Receipt). **§5.15:** Zelle-3-Zeile und Scope-Präzisierung auf die §5.16-Verankerung nachgeführt („in §5.16 verankert, Story 3.10"). **§5.10 Pkt. 8:** D-4-Bullet um die §5.16-Verankerung des Hold selbst ergänzt (Hold-Ausbau: Stufen a/b/c, Mehrziel, benannter Hold). **§7:** Relevanzbestimmung-Bullet um die **Story-3.10-Verankerung** erweitert (§5.16; bestehende Story-Bullets unverändert). **AD-16-Klassifikation/semantische Auflösung bleibt Epic 4.** **Abschlussklausel (Story 3.10):** Keine Änderung an `schema/wiki-compiler.md`/`schema/validator.md`/`adapters/`/`raw/` (AD-3); **keine neue §7-Invaliditätsklasse**; **keine fünfte Update-/Routing-Form**; die §5.9-Abgrenzungs-Reihenfolge `Korrigieren → Präzisieren → Erweitern → No-Op` bleibt die **einzige** Form-Wahl (textuell unverändert); **kein Standalone** (D-3); keine Vertragsänderung; **kein neuer Prädikat-/Format-/Frontmatter-Key**; `schema/canonical-terms.md` unverändert (kein neuer Normalisierungs-Operand — Umlaut-vs-Transkription bleibt benannter Defer, Ask-First); Commit-Boundary-Regel unverändert; `generated.at`-Verhalten unverändert (A0-20-Konvention). **`sprint-status.yaml`:** Key `3-10-inkrementelle-update-und-synthese-erhaltung-absichern` auf **`review`** geflippt (Implementierungs-Commit; finaler `done`-Flip im Step-05-Status-Sync nach abgeschlossenem Review-Loop — Präzedenz Revision 3.2/3.3/3.4). Sandbox-Nachweis (**E-1..E-9, Exit 0**; CONFIRMING ≠ NO_OP byte-bewiesen, NO_OP byte-erhaltend, Korrigieren-Receipt-Trace, aktueller-Run-Selbsttest, Orphan über Stufe-a/b/c, Mehrziel-Konsolidierung/-Hold, Zwei-Run-Identität nicht-vakuum) und per-Datei-Validator-Verdikt siehe `wiki/log.md`-Eintrag (Story 3.10, Revision 3.5).
 - **Revision 3.6 (2026-08-21, Story 3.11):** Neue Sektion **§5.17 „Atomare Root-Scope-Lease-Akquise (Story 3.11)"** eingefügt (nach §5.16, vor §6) — die **operationelle Atomaritäts-Präzisierung der Root-Scope-Akquise** über der textuell unveränderten §5.11-/§5.12-Mechanik (D-3, Story 3.11; AD-17b/A0-13; §5.11 Pkt. 1/2 und §5.12-Anker sind Fugen-Identität, Revision 3.6): (1) **Exklusivitätsschlüssel = scope-bezogener Lock im clone-geteilten Zustand** (AC-a; der geteilte Git-Ref-/Objektnamespace ist der einzige von allen Worktrees/Prozessen eines Clones gemeinsam gesehene Zustand; eine deterministisch benannte, committete Ref je Root-Scope `wiki/`, z. B. `refs/leases/wiki`; die **Run-ID ist Lock-Inhalt und nicht Bestandteil des Exklusivitätsschlüssels** — der Ref-Name trägt keine Run-ID; die bisherige `<id>`-Ablage §5.11 Pkt. 1 bleibt per-Lease-Ablage ohne alleinige Exklusivität), (2) **atomare Akquise (create-only) — genau ein Gewinner** (AC-b; `git update-ref <lock-ref> <wert> $ZERO_SHA` schlägt fehl, sobald der Ref existiert, und berührt einen existierenden Lock nicht; gits Ref-Sperre serialisiert zwei Worktrees/Prozesse desselben Clones; **Ask-First-Pflicht**: nicht sicher atomar belegbar auf Windows/Git-Bash → HALT, Alternativ-Primitiv zur Autorisierung), (3) **`LEASE_HOLD`-Semantik** (AC-c; abgewiesener Producer verändert weder `wiki/` noch den Lock, erzeugt keinen Compilation Commit, entfernt keine fremde Lease, beendet sauber, AD-16-Pfad), (4) **Determinismus** (AD-17h/A0-19; clone-geteilter Zustand = eindeutige Gewinner-/Verlierer-Entscheidung; Lock-Inhalt dokumentierender Ablage-Wert, kein Schlüsselbestandteil), (5) **Kollisions-Hold an Epic 4** (AC-e/AD-17c/A0-14; kein textueller Auto-Merge, strukturierter Kollisions-Hold mit beiden Commit-Hashes und Scope an Epic 4 via §5.16-Pkt.-8-/§5.10-Pkt.-8-Hold-Mechanik; AD-16-Klassifikation bleibt Epic 4; Commit-Boundary = Mutations-Boundary und `log.md`-Eintragspflicht unverändert), (6) **Abgrenzung** (keine Wanduhr/Systemzeit A0-20, keine Staleness-/Recovery-Logik — bleibt §5.12/Story 3.6 und Story 3.12 —, keine Verwaist-/Stale-Behandlung/kein Branch-Lifecycle nach Übernahme — Story 3.12). **§7:** Leasing-Bullet um die **Story-3.11-Verankerung** erweitert (§5.17; bestehende Story-Bullets unverändert). **§8:** AD-17b/A0-13 bleiben über die bestehende §5.11-Zuordnung verankert — §5.17 referenziert sie (Fugen-Identität). **Abschlussklausel (Story 3.11):** Keine Änderung an `schema/wiki-compiler.md`/`schema/validator.md`/`adapters/`/`raw/` (AD-3); **keine neue §7-Invaliditätsklasse**; **kein neuer Frontmatter-Key für Lease-Metadaten** (Vertrag §3.1–§3.7 unverändert); **kein neuer Prädikat-/Format-Key**; **kein Standalone** (D-3); keine Vertragsänderung; §5.11-Pkt.-1/2-Wortlaut und §5.12-Anker **textuell unverändert** (additive Präzisierung, Fugen-Identität); keine Wanduhr/Systemzeit (A0-20); keine Staleness-/Recovery-Logik (Story 3.6/3.12); Commit-Boundary-Regel unverändert; AD-16-Klassifikation bleibt Epic 4. **`sprint-status.yaml`:** Key `3-11-root-scope-leasing-atomar-akquirieren` auf **`review`** geflippt (Implementierungs-Commit; finaler `done`-Flip im Step-05-Status-Sync nach abgeschlossenem Review-Loop — Präzedenz Revision 3.2/3.3/3.4/3.5). Sandbox-Nachweis (**A-1..A-8, Exit 0**; Zwei-Worktree-/Zwei-Prozess-Überlappung mit Zwischenzustands-Sampling („niemals zwei aktive Root-Leases" **konstruktiv belegt** — eine scope-bezogene Ref + atomarer create-only-Write, keine zwei Refs/Werte im Überlappungs-Fenster), `LEASE_HOLD`-Nicht-Mutation, Kollisions-Hold mit beiden Commit-Hashes) und per-Datei-Validator-Verdikt siehe `wiki/log.md`-Eintrag (Story 3.11, Revision 3.6).
+- **Revision 3.7 (2026-08-21, Story 3.12):** Neue Sektion **§5.18 „Lease-Lifecycle & transaktionaler Commit-Abschluss (Story 3.12)"** eingefügt (nach §5.17, vor §6) — die **geschlossene, transaktionale Lifecycle-Klammer** der Koordinations-Dimension über der textuell unveränderten §5.11-/§5.12-/§5.13-/§5.17-Mechanik (D-3, Story 3.12; AC-1..AC-7; A0-20 — keine Wanduhr-/Systemzeit-Steuerung, Lifecycle deterministisch aus dem committeten Git-State, AD-17h/A0-19; §5.17-Pkt.-1-Z. 419-„Lifecycle-Regie Story 3.12" und Pkt.-6-Z. 424-„bleibt Story 3.12" sind die Anschluss-Sutur, Fugen-Identität): (1) **Liveness & Ownership** (AC-1; eine höhere Generation allein macht eine lebende Lease nicht stale — Staleness verlangt bestätigten Abbruch oder abgelaufene Liveness plus atomare Ownership-Prüfung; kein Wanduhr-TTL, A0-20), (2) **stale-Übernahme genau einmal** (AC-2; ownership-gebunden über den §5.17-Scope-Lock, ersetzte Holder-ID im `log.md` benannt, genau eine aktive Root-Lease, nie still gelöscht — AD-17e), (3) **eindeutige Abort-/Protect-Zustandsmaschine** (AC-3; getrackte fremde Änderung → Scratch-Zone `scratch/<run-id>/` oder `git stash push`, ungetrackte fremde Datei → Protect, byte-identischer Restore, `UNCOMMITTED_INPUT`-Abbruch abgestimmt §5.11 Pkt. 3, nie gelöscht), (4) **Baseline-Rollback Index + Worktree** (AC-4; `git reset --hard <Baseline-Commit>`, Post-Rollback-Diff gg. Baseline leer, §5.13 Pkt. 3), (5) **durable Release** (AC-5; Mutation + zulässiger Log-/Koordinationsnachweis committet, Lock per Ref-Delete nur durch Inhaber, Worktree sauber, Clean-Input-Guard — Folge-Run ohne `INPUT_UNCOMMITTED`-Abbruch; Release-Fehler = HARD-FAIL), (6) **kanonisches Log** (AC-6; `wiki/log.md` nur vertragskonforme fachliche + notwendige Koordinationsereignisse, Build-/Review-/Story-/Sandbox-Historie außerhalb), (7) **Kill-Point-Tests** (AC-7; vor Mutation/nach Mutation/vor Commit/nach Commit je konsistenter Endzustand, §5.13-Pkt.-3-Zustands-Restaurations-Invariante). **§7:** Leasing-Bullet um die **Story-3.12-Verankerung** erweitert (§5.18; bestehende Story-Bullets unverändert). **§8:** AD-17b/A0-13/A0-15/A0-16-/AD-17e/f-Anker bleiben über die bestehende §5.11-/§5.12-Zuordnung verankert — §5.18 referenziert sie (Fugen-Identität). **Abschlussklausel (Story 3.12):** Keine Änderung an `schema/wiki-compiler.md`/`schema/validator.md`/`adapters/`/`raw/` (AD-3); **keine neue §7-Invaliditätsklasse**; **kein neuer Frontmatter-/Format-Key** (Vertrag §3.1–§3.7 unverändert); **kein Standalone** (D-3); keine Vertragsänderung; §5.11-Pkt.-1-7-/§5.12-Pkt.-1-7-/§5.13-/§5.17-Wortlaute **textuell unverändert** (additive Präzisierung, Fugen-Identität); keine Wanduhr/Systemzeit (A0-20, keine TTL über Kalenderzeit); keine stille Löschung fremder uncommitteter/geschützter Änderungen (AD-17e); keine Wissensmutation bei Orphan/Hold (AD-16-Default); kein textueller Auto-Merge (AD-17c); `generated.at`-Verhalten unverändert; Commit-Boundary-Regel unverändert; AD-16-Klassifikation bleibt Epic 4. **`sprint-status.yaml`:** Key `3-12-lease-lifecycle-und-commit-abschluss-transaktional-schliessen` auf **`review`** geflippt (Implementierungs-Commit; finaler `done`-Flip im Step-05-Status-Sync nach abgeschlossenem Review-Loop — Präzedenz Revision 3.2/3.3/3.4/3.5/3.6). Sandbox-Nachweis (**L-1..L-9, Exit 0**; Lifecycle-Zustandsmaschine, Abort-/Protect-Zustandsmaschine getrackt/ungetrackt byte-identisch, Baseline-Rollback Index+Worktree mit leerem Post-Rollback-Diff, Kill-Point-Tests an vier Punkten, durable Release + Clean-Input-Guard, stale-Übernahme genau einmal) und per-Datei-Validator-Verdikt siehe `wiki/log.md`-Eintrag (Story 3.12, Revision 3.7).