wow20/_bmad-output/implementation-artifacts/spec-3-11-root-scope-leasing-atomar-akquirieren.md

title, type, created, status, baseline_commit, review_loop_iteration, context

title	type	created	status	baseline_commit	review_loop_iteration	context
Story 3.11 — Root-Scope-Leasing atomar und worktree-übergreifend akquirieren	feature	2026-08-21	done	a8b486d0f0	1	_bmad-output/implementation-artifacts/epic-3-context.md

Intent

Problem: Die in schema/compiler.md §5.11/§5.12 verankerte Lease-Akquise ist eine nicht-atomare check-then-act-Operation auf einem Arbeitsbaum-Lockfile (lease/<area>/<id>.lock oben geprüft, unten per >-Write überschrieben) und wird bisher nur in sequenzieller Isolation erprobt. Ein TOCTOU-Race ist möglich: zwei Producer mit verschiedenen Run-IDs können denselben Root-Scope gleichzeitig „erwerben", weil die Run-ID Teil des Exklusivitätsschlüssels (Lockfile-Pfad + Branch-Name) ist. Der von AD-17b/A0-13 geforderte „genau ein scope-bezogener Lock im clone-geteilten Zustand" ist weder in §5.11 verankert noch durch einen realen Zwei-Worktree-/Zwei-Prozess-Test belegt (epic-3-context Z. 41, Zielzustand P-11).

Approach: §5.11 in Revision 3.6 um einen präzisierenden Abschnitt ergänzen: der Exklusivitätsschlüssel wird ein einziger, scope-bezogener Lock im clone-geteilten Zustand des Repos (geteilter Git-Ref-/Objektnamespace aller Worktrees und Prozesse eines Clones); die Run-ID ist Lock-Inhalt statt Schlüsselbestandteil; die Akquise erfolgt atomar (create-only: zweite Akquise schlägt fehl, ohne den Lock zu berühren). Eine neue Sandbox führt einen realen, zeitlich überlappenden Zwei-Worktree-/Zwei-Prozess-Test mit Zwischenzustands-Assertions aus und weist nach, dass niemals zwei aktive Root-Leases gleichzeitig existieren und der unterlegene Producer LEASE_HOLD erhält.

Boundaries & Constraints

Always:

• Fugen-Identität: Branch-Form lease/<area>/<id> (§5.11 Pkt. 1), Lockfile-Pfad lease/<area>/<id>.lock und dessen Feld-Satz bleiben bestehen; Root-Scope-Umfang §5.11 Pkt. 2 (wiki/ inkl. log.md, index.md, aller Root-Dateien; kein Bereich jenseits wiki/) bleibt unverändert.
• Fugen-Identität: AD-17a/17b-Spine-Wortlaut, A0-12/A0-13-Kurzbeschreibungen, §5.12-Anker (Registry im Clone-Root-State bzw. lease-granite-root-Marker, Gen-Invariante, kein Wanduhr/Zeitstempel A0-20) und die bestehende §5.11-Pkt.-1-Lease-Hold-Semantik bleiben unverändert maßgeblich.
• Der Exklusivitätsschlüssel ist der scope-bezogene Lock im clone-geteilten Zustand; die Run-ID ist Lock-Inhalt und nicht Teil des Schlüssels (AC-a).
• Die Akquise ist atomar (create-only): genau ein Gewinner; der Abgewiesene erhält LEASE_HOLD, überschreibt nichts, erzeugt keinen Compilation Commit, entfernt keine fremde Lease (AC-b/c).
• Kein textueller Auto-Merge (AD-17c); ungleiche Änderungen am selben Concept-Pfad werden als strukturierter Kollisions-Hold mit beiden Commit-Hashes an Epic 4 übergeben (AC-e). Commit-Boundary = Mutations-Boundary (AD-17f), log.md-Eintragspflicht (Vertrag §5).
• Schema read-only (AD-3): schema/validator.md, schema/wiki-compiler.md, adapters/, raw/ bleiben unverändert; kein neuer Frontmatter-Key, keine neue §7-Invaliditätsklasse, kein Standalone (D-3).

Ask First:

• Falls das gewählte atomare create-only-Primitiv im geteilten Git-Refnamespace (z. B. git update-ref <ref> <wert> $ZERO_SHA, create-only) auf der Ziel-Plattform (Windows/Git-Bash) nicht zuverlässig atomar belegbar ist, HALT und alternative Primitiv-Auswahl zur Autorisierung vorlegen.

Never:

• Kein Umschreiben des bestehenden §5.11-Pkt.-1/2-Wortlauts — nur additive Präzisierung (Revision 3.6); keine Änderung der Root-Scope-Umfangssemantik.
• Keine Wanduhr-/Systemzeit in der Akquise (A0-20); keine Staleness-/Recovery-Logik (bleibt Story 3.6/3.12).
• Keine Verwaist-/Stale-Behandlung, kein Lease-Branch-Lifecycle nach Übernahme (bleibt Story 3.12).
• Keine Mutation des realen Bundles oder raw/ durch die Sandbox; keine Schein-Parallelität (zwei disjunkte Repos oder Zeitversatz ohne Überlappung beweisen keine Atomarität).

I/O & Edge-Case Matrix

Scenario	Input / State	Expected Output / Behavior	Error Handling
AKQUISE_GEWINNER	scope-frei; Worktree 1 akquiriert Root-Scope	genau ein scope-bezogener Lock mit Inhalt = Run-ID von Worktree 1	N/A
AKQUISE_ABGEWIESEN	scope-Lock bereits von anderer Run-ID (anderer Worktree) gehalten	LEASE_HOLD; wiki/ und Lock unverändert; kein Compilation Commit; fremde Lease bleibt erhalten	abgewiesener Producer beendet sauber mit LEASE_HOLD
AKQUISE_GLEICHZEITIG	zwei Prozesse in getrennten Worktrees, zeitlich überlappende Akquise	Zwischenzustands-Assertions: niemals zwei aktive Root-Leases gleichzeitig; genau ein Gewinner	Verlierer erhält LEASE_HOLD
KOLLISIONS_HOLD	zwei Branches mit ungleichen Änderungen am selben Concept-Pfad	kein textueller Auto-Merge; strukturierter Kollisions-Hold mit beiden Commit-Hashes an Epic 4	Hold-Struktur statt Merge

Code Map

• schema/compiler.md §5.11 (Z. 304–321) / §5.12 (Z. 323–342) / §7 / §8 (Rev. bis 3.5) -- der normativ zu ergänzende Instruktions-Ort: neue Präzisierung als Abschnitt nach §5.12 (Revision 3.6); Pkt.-1/2-Wortlaut und Rückverweise (Z. 321 Seam, §7, §8) bleiben Fugen-Identität.
• _bmad-output/implementation-artifacts/epic-3-context.md Z. 41 -- „Zielzustand (Review-Loop-3, P-11)": zu schließender Ist/Soll-Abstand; nach Verankerung auf Ist-Zustand aktualisieren.
• _bmad-output/implementation-artifacts/sandbox-3-5/run-sandbox.sh -- nicht-atomare akquire() (check-then-act) und L1/L2/L5-Szenarien: Ableitungspflicht des neuen atomaren Lock-Modells.
• _bmad-output/implementation-artifacts/sandbox-3-6/run-sandbox.sh -- Registry-/Gen-Mechanik im Clone-Root-State, isolate() (Z. 97–104); Zwei-Worktree-Erweiterung muss Gen-Invariante und Registry erhalten.
• _bmad-output/implementation-artifacts/sandbox-3-8/run-sandbox.sh Z. 249–251 -- git worktree add-Präzedenz über einem Baseline-Commit (bisher strikt sequenziell; Konkurrenz ist die 3.11-Neuheit).
• _bmad-output/implementation-artifacts/sprint-status.yaml Z. 64 -- Story-Key 3-11-root-scope-leasing-atomar-akquirieren: backlog → review.
• wiki/log.md -- Revisions-/Lauf-Nachweis der Verankerung.

Tasks & Acceptance

Execution:

• schema/compiler.md -- neuen Präzisierungs-Abschnitt (Revision 3.6) nach §5.12 ergänzen: atomarer scope-bezogener Lock im clone-geteilten Zustand (create-only, Run-ID als Lock-Inhalt statt Exklusivitätsschlüssel), LEASE_HOLD-Semantik, Kollisions-Hold mit beiden Commit-Hashes an Epic 4; bestehende Pkt.-1/2 und §5.12 unverändert lassen; §7-Rückverweis und §8-Revisionslog ergänzen -- §5.11-Präzisierung (Story-3.11-Rationale).
• _bmad-output/implementation-artifacts/sandbox-3-11/run-sandbox.sh -- neue re-executierbare Sandbox: echte Zwei-Worktree-/Zwei-Prozess-Überlappung (git worktree add über einer Baseline), atomare Akquise mit Zwischenzustands-Assertions (niemals zwei aktive Root-Leases), LEASE_HOLD-Fälle inkl. Nicht-Mutation des Arbeitsbaums, Kollisions-Hold mit beiden Commit-Hashes; Exit 0, harte PASS/FAIL; berührt reales Bundle/raw/ nicht -- Tests der I/O-Matrix und der 5 ACs.
• _bmad-output/implementation-artifacts/sprint-status.yaml -- Key 3-11-root-scope-leasing-atomar-akquirieren auf review -- Status-Sync des fertigen Drafts.
• wiki/log.md -- Revisions-Nachweis (Verankerung + Sandbox-Lauf) -- Vertrag §5-Eintragspflicht.
• _bmad-output/implementation-artifacts/epic-3-context.md -- Z. 41-Zielzustand auf Ist-Zustand aktualisieren -- Planungsartefakt nachführen.

Acceptance Criteria:

• Given der Root-Scope wiki/ im clone-geteilten Zustand, when ein Producer eine Lease akquiriert, then existiert genau ein scope-bezogener Lock und die Run-ID ist Lock-Inhalt und nicht Teil des Exklusivitätsschlüssels.
• Given zwei Producer mit verschiedenen IDs und getrennten Worktrees, when beide denselben Root-Scope akquirieren, then ist die Akquise atomar und genau ein Producer erhält die Lease; der andere erhält LEASE_HOLD.
• Given ein abgewiesener Producer, when die Akquise fehlschlägt, then verändert er weder wiki/ noch den bestehenden Lock, erzeugt keinen Compilation Commit und entfernt keine fremde Lease.
• Given ein realer Zwei-Worktree-/Zwei-Prozess-Test mit zeitlich überlappender Akquise, when die Läufe ausgeführt werden, then beweisen Zwischenzustands-Assertions, dass niemals zwei aktive Root-Leases gleichzeitig existieren.
• Given zwei Branches mit ungleichen Änderungen am selben Concept-Pfad, when eine Kollision erkannt wird, then wird nicht automatisch textuell gemerged, sondern ein strukturierter Kollisions-Hold mit beiden Commit-Hashes an Epic 4 übergeben.

Spec Change Log

Design Notes

Der Lock muss im clone-geteilten Zustand liegen, weil nur dieser Zustand von allen Worktrees und Prozessen eines Clones gemeinsam gesehen wird: Arbeitsbaum-Lockfiles (lease/<area>/<id>.lock) sind clone-lokal und laden zur nicht-atomaren check-then-act-Akquise ein. Der geteilte Git-Ref-/Objektnamespace bietet dagegen ein natürlich atomares create-only-Primitiv (gits eigene Ref-Sperre, z. B. git update-ref <ref> <wert> 0000…0000, schlägt fehl, sobald der Ref existiert); zwei Worktrees desselben Repos streiten damit serialisiert um denselben Lock. Der Schlüssel ist der Scope (ein Ref pro wiki/), der Inhalt die Run-ID — genau die AC-a-Aussage. Die bisherige <id>-Schlüssigkeit (§5.11 Pkt. 1) bleibt als per-Lease-Ablage bestehen, trägt aber keine Exklusivität mehr allein.

Verification

Commands:

• bash _bmad-output/implementation-artifacts/sandbox-3-11/run-sandbox.sh -- expected: alle Szenarien harte PASS (u.a. „niemals zwei aktive Root-Leases"-Assertion, LEASE_HOLD-Reihenfolge), Exit 0, kein Zugriff auf reales Bundle/raw/.
• grep -n "Revision 3.6" schema/compiler.md und grep -n "## 5.17" schema/compiler.md -- expected: §5.17-Überschrift und §8-Revisionslogeintrag vorhanden; bestehende Pkt.-1/2-Texte unverändert (diff checkt nur additive/berichtigte Zeilen).
• git diff --stat (Repo-Root) -- expected: nur die Review-Loop-1-Touched-Files (Sandbox, schema/compiler.md §5.17-Berichtigungen, Spec, log.md, deferred-work.md, sprint-status.yaml); schema/validator.md/schema/wiki-compiler.md/adapters//raw/ ohne Diff (AD-3).

Manual checks (if no CLI):

• Keine Beschreibung nötig — sämtliche Nachweise laufen über die Sandbox (Exit-Code) und additive Diffs.

Suggested Review Order

Design-Intent (normative Instruktion)

• Einstieg: die §5.17-Atomaritäts-Präzisierung — Exklusivitätsschlüssel im clone-geteilten Zustand, Run-ID als Lock-Inhalt, create-only-Akquise, LEASE_HOLD, Kollisions-Hold an Epic 4 (AC-a..e). compiler.md:415
• Abgrenzungsklausel der Story-3.11-Verankerung — Fugen-Identität von §5.11-Pkt.-1/2 und §5.12 bleibt erhalten, keine neue §7-Klasse, kein Standalone. compiler.md:424

Atomarer Lock im clone-geteilten Zustand

• Atomare create-only-Akquise (git update-ref <lock-ref> <wert> $ZERO_SHA) — gits Ref-Sperre serialisiert Worktrees/Prozesse; deterministischer Blob-Inhalt. run-sandbox.sh:124
• Zwei-Prozess-Überlappung im Zwei-Worktree — Schlüssel-Beweis AC-b/AC-d (genau ein Gewinner, ein LEASE_HOLD, gehärteter Zwischenzustands-Sampler: Ref-Kardinalität + Wert-Evidenz). run-sandbox.sh:217

Kollisions-Hold & Abweisung

• LEASE_HOLD-Nicht-Mutation: abgewiesener Producer lässt wiki//Lock/log.md unverändert, keine Commits, fremde Lease erhalten (AC-c) — Worktree-Beobachtung des Arbeitsbaums (D-3.11-2). run-sandbox.sh:339
• Kollisions-Hold mit beiden Commit-Hashes + Scope + Baseline in log.md an Epic 4 (AC-e, AD-17c, kein textueller Auto-Merge) — MERGE_OK wird hart abgewiesen; Datei-Level-Attest auf den Post-Merge-State. run-sandbox.sh:460

Status- & Nachweissynchronisation (peripher)

• Revisionsnachweis Story 3.11 → review in der Laufzeitakte — Verankerung, Sandbox, Abschlussklausel, Erhaltungs-Invariante. log.md:4
• Planungsartefakt auf Ist-Zustand nachgeführt (epic-3-context Z. 41). epic-3-context.md:41

Härtung & Konsistenz-Funde (defer)

• Konsistenz-, Drift- und Härtungs-Funde aus der Review in der Defer-Liste festgehalten (AC-d-Token, Zeilenanker, dynamische Negativ-Kontrolle, Platzhalter-Banner) inkl. KORREKTUR-Teileintrag (Zeilen-Drift-Defer widerlegt). deferred-work.md:578

Review Findings

Bmad-code-review Loop 1 (2026-08-21), 4 Layer (blind-hunter/edge-case-hunter/verification-gap/acceptance-auditor). Triage: 2 decision-needed, 20 patch, 5 defer, 5 dismissed. Sandbox re-executiert (Windows/Git-Bash): A-1..A-8 8/8 harte PASS, Exit 0, kein Zugriff auf reales Bundle/raw/.

Decision-Needed

• [Review][Decision] D-3.11-1 AC-d-Beweisart (Zwischenzustands-Assertion) — Gelöst (Nutzer-Entscheidung 2026-08-21): Konstruktiv + härten — AC-4 als konstruktiv erfüllt akzeptiert (eine scope-bezogene Ref + atomarer create-only-Write → zu keinem Zeitpunkt zwei aktive Root-Leases); A-2-Sampler zur lebendigen Wert-Evidenz gehärtet, §5.17-/log.md-Nachweis um „konstruktiv“ qualifiziert. Kein frozen-Block-Neuverhandeln. Hintergrund: der A-2-Sampler zählt die Ref-Kardinalität (grep -cF "$SCOPELOCK", Z. 237, nie >1 bei einem Ref-Namen) und der TWO_LOCKS_AT_ONCE-Marker geht per >&2 verloren, weil out_a nur stdout fängt (Z. 238 vs. Z. 255) — die Assertion war als beobachtete Evidenz strukturell tot. [run-sandbox.sh:237-257]
• [Review][Decision] D-3.11-2 A-4-Mutations-Regime (Nicht-Mutation des abgewiesenen Producers) — Gelöst (Nutzer-Entscheidung 2026-08-21): Intentionalen Mutationsversuch bauen — in A-4 einen bewussten Mutations-/Commit-Versuch des abgewiesenen Producers in die Sandbox einbauen, dessen Ausbleiben/Ablehnung dann hart geprüft wird (deckt AC-c als Verhalten ab, nicht nur als Selbstvergleich). Hintergrund: der LEASE_HOLD-Pfad unternimmt heute keinen Mutationsversuch (nur echo "LEASE_HOLD", Z. 309-311) und die AC-c-Assertions vergleichen git show "$BASE:…" mit sich selbst (invarianter Baseline-Blob, nie der Worktree; Z. 297/314/323) — uncommittete Arbeitsbaum-Mutationen des Abgewiesenen schifften unentdeckt durch. [run-sandbox.sh:297-324]

Patch

• [Review][Patch] A-7 MERGE_OK-Zweig akzeptiert den verbotenen textuellen Auto-Merge — case "$ma" in MERGE_CONFLICT|MERGE_OK) lässt beide Outcomes durch; wäre git merge --no-edit clean gegangen, läge exakt der von AD-17c/AC-e verbotene stille Merge vor, der Test meldet dennoch PASS. MERGE_OK hart failen (oder begründen, warum nur CONFLICT zulässig ist); dazu die Body-Assertions auf den Post-Merge-HEAD von branch-y (git show branch-y:wiki/alpha.md) statt auf die invarianten $HASH_X/$HASH_Y-Objekte ausrichten. [run-sandbox.sh:406-443]
• [Review][Patch] A-7 stale-Aussage-Kommentar widerspricht dem Code — Kommentar „(a) … git merge … der Befehl wird gar nicht erst ausgeführt, … kein Merge“ (Z. 401-405) steht über merge_attempt(), das den Merge real ausführt; zudem unverstandener Rest „ablösen von alpha.txt-loesungen“. Kommentar an den tatsächlichen Ablauf korrigieren. [run-sandbox.sh:401-414]
• [Review][Patch] A-7 hold_msg-Variablen-Case ist tautologisch — die zwei case "$hold_msg"-Checks (Z. 430-437) prüfen eine gerade konstruierte Zeichenkette gegen sich selbst (der erste *"$HASH_X"*|*"$HASH_Y"* bestünde sogar bei nur einem Hash); nur die Datei-Checks (Z. 450-453) sind real. Variablen-Case entfernen oder auf den geschriebenen log.md-Inhalt reduzieren. [run-sandbox.sh:430-437]
• [Review][Patch] A-7 log.md-Hold-Eintrag trägt keinen <Baseline-Commit> — die zitierte Hold-Mechanik (§5.16 Pkt. 8/§5.10 Pkt. 8) verlangt „Quell-Pfad + <Baseline-Commit>“; der geschriebene Eintrag (Z. 447) hat Scope + beide Hashes, aber kein Baseline-Commit. Baseline-Komponente ergänzen oder begründen, warum sie beim Kollisions-Hold entfällt. [run-sandbox.sh:446-448]
• [Review][Patch] assert_frontmatter() ist tot — behauptete „at-Normalform je Szenario“ wird nicht ausgeführt — die Funktion (Z. 155-164) prüft §3.3/§3.4-Frontmatter + at-ISO-Normalform, wird aber nirgendwo aufgerufen; wiki/log.md/Revision-3.6 attestiieren dennoch „Erhaltungs-Invariante + at-Normalform je Szenario“. Aufruf ergänzen (z. B. assert_frontmatter wiki/alpha.md nach A-7, wo alpha.md neu geschrieben wird) oder die Nachweis-Formulierung in log.md/Revision korrigieren. [run-sandbox.sh:155-164]
• [Review][Patch] A-3-Kommentar behauptet „zweiter Worktree, eigener Prozess“, ist aber sequentiell im Hauptprozess — die zweite Akquise (Z. 285-286) ist ein direkter scopelock_acquire-Aufruf ohne git worktree add/Subshell; „zeitlich ÜBERLAPPEND“ ist hier falsch (echte Überlappung liegt in A-2). Kommentar entlarven/entschärfen. [run-sandbox.sh:282-286]
• [Review][Patch] A-3 Identitäts-Fall nicht geübt — der Kommentar behauptet „auch eine identisch benannte Run-ID kann den Halter nicht ersetzen“, der zweite Versuch nutzt aber RUN-A3-identisch (andere ID); der exakte Identitäts-Fall RUN-A3 wird nicht geübt. Entweder mit RUN-A3 akquirieren oder den Kommentar korrigieren. [run-sandbox.sh:284-288]
• [Review][Patch] A-1 toter run_a1-Blob — run_a1=$(printf 'producer-a1-run-id' | git hash-object -w --stdin) (Z. 179) wird nie verwendet (echter Lock-Inhalt ist RUN-A1); Dead Code, schreibt ein ungenutztes Objekt. Entfernen. [run-sandbox.sh:179]
• [Review][Patch] A-8 Commit-Zähler-Check am falschen Punkt — der git rev-list --count-Check vor dem ersten scopelock_release (Z. 468-469) kann nur Akquise-Commits, keine Release-Commits nachweisen; der Check nach dem Release (Z. 479-480) ist der wirksame. Erster Check entfernen oder Kommentar korrigieren („hart, vor dem ersten Release“ trifft die eigene Aussage nicht). [run-sandbox.sh:466-480]
• [Review][Patch] Sandbox-Schlusskontrolle ist ein No-op — git status --short --porcelain >/dev/null 2>&1 || true (Z. 494) verwirft Ausgabe und Exit-Code und attestiert nichts (weder Bundlesauberkeit noch „kein Zugriff auf reale Pfade“); dazu bleiben die in A-2/A-4 angelegten Worktrees ($ROOT/wt-a/wt-b/wt-a4) registriert und werden nicht abgeräumt. Ende-Assertion auf eine echte Prüfung umstellen (z. B. git worktree list-Prüfung gg. $ROOT) oder Worktrees aufräumen + No-op entfernen. [run-sandbox.sh:494]
• [Review][Patch] scopelock_release() ohne Ownership-/Exit-Code-Kopplung — git update-ref -d "$SCOPELOCK" (Z. 132-134) läuft ohne || fail und ohne Inhaber-Bindung (kein Abgleich des Ref-Inhalts mit der eigenen Run-ID); ein fehlgeschlagenes Release würde A-1/A-3/A-5/A-6 nicht bemerken. Release-Stellen hart koppeln; Ownership-Prüfung ergänzen oder explizit als Story-3.12-Home benennen. [run-sandbox.sh:132-134]
• [Review][Patch] isolate() räumt den geteilten Ref-Namespace nicht — reset --hard/git clean betreffen nur Arbeitsbaum und HEAD; refs/leases/wiki überdauert Szenario-Grenzen und hängt an der impliziten Release-Disziplin. Expliziten Ref-Reset in isolate() ergänzen, damit ein fehlgeschlagenes Release die Folgeszenarien nicht still kontaminiert. [run-sandbox.sh:99-105]
• [Review][Patch] Asymmetrische Release-Ende-Leereprüfung — A-8 prüft nach dem Release [ -z "$(scopelock_content)" ], A-1/A-3/A-5/A-6 tun es nicht; ein hängender Lock wäre erst in einem späteren, nicht-attributierbaren Szenario auffindbar. Ende-Check je Szenario vereinheitlichen. [run-sandbox.sh:189-189, 288-288, 342-342, 359-359]
• [Review][Patch] §5.17 Pkt. 5 Grammatikbruch + fehlendes Ablage-Ziel — „an Epic 4 übergeben — der benannten Hold-Mechanik“ (Anstelle von „an“); zudem benennt §5.17 Pkt. 5 nirgends, wo der Kollisions-Hold liegt (Run-Receipt? log.md?), während A-7 ihn in wiki/log.md schreibt. Wortlaut berichtigen + Ablage-Stelle normativ benennen. [compiler.md:423]
• [Review][Patch] §5.17 Pkt. 1: „committete Ref“ ist technisch inkorrekt — eine Ref ist kein Commit-Objekt und nicht Teil eines Commits; die Sandbox realisiert es als Blob (git hash-object -w) plus Ref-Write. Für eine normative Sektion, aus der Story 3.12 den Lifecycle ableitet, unpräzise (Lebensdauer des Locks unklar). Auf „geschriebene/verwiesene Ref mit Blob-Inhalt“ berichtigen. [compiler.md:416]
• [Review][Patch] §5.17 Pkt. 4: Determinismus-Aussage gilt nicht im concurrenten Fall — „gleicher Geteilter-Zustand + gleiche Eingabemenge → identische Gewinner-/Verlierer-Entscheidung“ trifft nur für sequentielle Versuche (A-3/A-6); bei überlappenden Producers hängt die Gewinnerwahl vom Scheduling ab, nicht allein vom geteilten Zustand. Pkt.-4-Aussage auf den deterministischen Kern (create-only-Existenzprüfung) eingrenzen oder den concurrenten Fall ausnehmen. [compiler.md:419]
• [Review][Patch] Suggested-Review-Order-Anker bei Commit-Zeit falsch — compiler.md:415 zeigt auf die Leerzeile vor dem §5.17-Intro; compiler.md:527 auf die §8-Revision-3.6-Logzeile (die Abgrenzungsklausel Pkt. 6 liegt ≈ Z. 424); log.md:47 auf eine Zeile unterhalb des 3.11-Eintrags (der liegt auf Z. 4); deferred-work.md:577 auf die Leerzeile vor dem neuen „Deferred from“-Header (Z. 578). Anker neu setzen. [spec:642, 644, 663, 670]
• [Review][Patch] Defer-Evidence benennt die falsche Stelle — der Zeilen-Drift-Defer in deferred-work.md verweist auf „die Spec (Code Map) und die Task-1-Rationale“, die konkreten Fehlancker sitzen aber in der Suggested-Review-Order; zudem ist die Aussage „§5.11 (Z. 304-321)/§5.12 (Z. 323-342) nicht mehr aktuell“ falsch — §5.11 liegt weiterhin auf Z. 304, §5.12 auf Z. 323 (verifiziert bei e02cf84). Evidence präzisieren; den Zeilen-Drift-Teileintrag berichtigen (es gibt keinen Defekt an diesen Anker). [deferred-work.md:580-585]
• [Review][Patch] Spec-Frontmatter context: [] trägt die Code-Map-Abhängigkeit nicht — die Code Map und Task 5 nennen epic-3-context.md (Z. 41) als nachgeführtes Planungsartefakt; die Präzedenz-Spec-3.10 listet dieselbe Datei im context:-Feld. epic-3-context.md in context: aufnehmen. [spec:8]
• [Review][Patch] Spec-Verification-Kommando ungültig — git -C schema/compiler.md diff ist ungültig (git -C erwartet ein Verzeichnis, schema/compiler.md ist eine Datei); grep -n "3.11\|3.6" trifft zudem etliche „Story 3.6“-Erwähnungen in §5.11/§5.12 und taugt nicht als gezielte Revision-3.6-Prüfung. Kommandos berichtigen. [spec:631-632]

Defer

• [Review][Defer] AC-d-Token ohne normative Vorlagen-Definition — der AC-d-Token (Sandbox A-2/A-3, §5.17, log.md) ist in der Vorlage epics.md A0-13/AD-17b nicht separat gelistet (AC-a..c, AC-e); er ist ein konsistenzerhaltender Behelf, kein neuer Anforderungskanon; Home: Epic-4-Statussynchronisation der Architecture-Spine (bereits in deferred-work.md, hier bestätigt). — deferred, pre-existing
• [Review][Defer] Sandbox-3.5/-3.6 üben weiterhin check-then-act-Lockfile-Akquise ohne §5.17-Scope-Lock — die Code Map benennt die akquire() von 3.5/3.6 als „Ableitungspflicht des neuen atomaren Lock-Modells“; die Schwestern-Sandboxes demonstrieren weiterhin die clone-lokale check-then-act-Lockfile-Akquise (Exklusivität nur für identische <id>). Ein Test, der zwei Producer mit verschiedenen id im selben Root-Scope unter §5.17 auf genau einen Gewinner prüft, fehlt. Home: Story-3.12-Lifecycle / Story-3.13-Abnahme. — deferred, pre-existing
• [Review][Defer] A-2 beweist keine garantierte zeitliche Überlappung — die zwei Prozesse starten ohne Synchronisations-Barriere; ein Scheduler kann sie vollständig sequenzieren (genau die „Zeitversatz ohne Überlappung“-Situation, die die Spec als nicht beweiskräftig ausschließt). Die create-only-Atomarität wird davon nicht berührt, aber eine echte Überlappung wäre ein stärkerer Beleg. Home: Sandbox-Härtung / Story-3.13. — deferred, pre-existing
• [Review][Defer] Status-Kontraktion Spec-Frontmatter status: done vs. sprint-status review — wiederholt das Story-3.9-Muster (D-3.9-2: maßgeblich review, Spec-done als Kontraktion); für 3.11 fehlt der explizite Präzedenz-Verweis. Entspricht aber der 3.9-/3.10-Präzedenz (status: done im Implementierungs-Commit, finaler done-Flip im Step-05-Sync) und wird im Step-05-Status-Sync aufgelöst. — deferred, pre-existing
• [Review][Defer] scopelock_header_banner() leerer Platzhalter + fehlende I/O-Matrix-Zeilen für A-5/A-6/A-8 — die ungenutzte Banner-Funktion (Z. 166) und die drei Sandbox-Szenarien ohne eigene I/O-Matrix-Zeile (Matrix listet 4 Szenarien, Sandbox übt 8) sind bekannter Kosmetik-/Dokumentations-Ausbau; Home: Story-3.12 / Matrix-Nachführung. — deferred, pre-existing