fix: Story 3.13 Epic-1-Remediation (Rev 3.8) — kanonische byte-deterministische log.md-Eintragsform + CREATE-Kern aus A/B-Fixture (D-3.13-6 Option 2)

Re-Run #5 lief RED an E.4 (A/B-Determinismus: NON_AT=26 AT=4 → HARD-FAIL).
Exakter Zeilen-Nachzähl-Befund: 24/26 (92%) der NON_AT-Abweichungen sind
CREATE-/Slug-getrieben (beta.md 11 + quanten-observatorium-kanal.md 11 +
index.md 2), verbleibende 4 log.md-Zeilen = 2 CREATE-Einträge (Slug-Divergenz)
+ 2 freie UPDATE-Wortungen (+ Wanduhr-generated.at im Body).

Autorisierter Minimal-Änderungssatz (Q1 + "continue"):
(1) compiler.md Rev 3.8 (D-3-Instruktions-Patch, additive Präzisierung):
    - §5.9 Pkt 4 (Update), §5.1 Pkt 4 (Anlage), §5.10 Pkt 7 (Synthese-Anlage):
      kanonische, byte-deterministische log.md-Eintragsform fixiert
      (- Story 3.1-Update: <concept> (<neue-Quellen>; Baseline <SHA>) etc.),
      kein freier Zusatztext, kein Wanduhr-Wert im log.md-Body (Wanduhr lebt
      ausschließlich im Frontmatter-generated.at, §5.14 Pkt 3).
    - §8 Revisionslog Rev 3.8-Eintrag.
    - NUR log.md-Form gepinnt; NUR Concept-Body/Slug/FR-2/§5.14-Pkt-3-Ausnahme
      UNVERÄNDERT. CREATE-Zielpfad-Signal-Pin = offener Defer (Ask-First).
    - Form = genau die, die Sub-Runs 3-3/3-4 mechanisch bereits demonstrieren
      (Ist-Behaviour verankert, kein Widerspruch).
(2) run-sandbox.sh E-Sektion: CREATE-/beta-Fall aus der A/B-Fixture entfernt
    (D-3.13-6 Option 2): E.1-Fixture (keine beta-Quellen), AGENT_PROMPT (keine
    beta-Fakt), E.5 (CREATE-Witness entfernt, UPDATE-Alpha-Witness bleibt),
    E.8 (index.md unverändert statt "+1 CREATE-Link"), Header-Kommentare.
    A/B-Prüfung deckt den Update-/Erhaltungs-Kern; CREATE/Synthese gelten über
    Sub-Runs 3-3/3-4 + D-Validator als demostriert.

Beide Änderungen berühren NICHT die frozen I/O-Matrix-Zeile GENERATED_AT_AUSNAHME
und NICHT den §5.14 Pkt 3-Vertrag. bash -n clean. Erwartetes E.4-Ergebnis:
NON_AT=0 AT=2 (alpha.md at-only).

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

schema/compiler.md

@@ -84,7 +84,7 @@ Je neuem Concept werden die Frontmatter-Metadaten nach Vertrag §3 festgelegt:
 2. **Dateiinhalt:** YAML-Frontmatter gemäß §4 (kein weiteres Feld), gefolgt von einem Markdown-Body, der die Wissenseinheit eigenständig und lesbar darstellt (NFR-2, NFR-3). Der Body darf keine großen Quell-Exzerpte enthalten (FR-2). Claim-granulare Inline-Provenienz (AD-4a) folgt §5.5 — für neu erzeugte Concepts unmittelbar bei der Erzeugung, für bestehende Bodies per Nachrüstung (Story 2.2).
 3. **Index-Regel (Punkt 11/§6):** Nach Anlage MUSS das neue Concept in der `index.md` **seines Bereichs** verlinkt werden — für Root-Concepts in der Bundleroot `wiki/index.md`, für Area-Concepts in der jeweiligen Area-`index.md` (`wiki/<area>/index.md`, §5.7) — seine Identität (relativer OKF-Pfad ohne `.md`) als relativer Bundle-Pfad referenziert; die genau-eine-Form-Festlegung ist in **§5.6** gepinnt (file-relativ, mit `.md`-Endung; §5.7 Pkt. 4). Ohne diese Verlinkung ist das Bundle strukturell invalide (§7 Punkt 11).
    - All dies (Anlage + Verlinkung + `log.md`) erst abschließen, wenn die Validierung (§6) SUCCESS liefert. Zwischenstände werden nicht als fertige Mutation veröffentlicht — Commit-Boundary ist die Mutations-Boundary (AD-17f). Bei Validierungs-FAIL wird der Teilzustand **explizit zurückgerollt**: neue Concept-Datei(en) gelöscht, zugehörige Index-Verlinkung(en) aus `wiki/index.md` entfernt, `log.md`-Eintrag(e) wieder entfernt — das Bundle nimmt seinen Zustand vor dem Run wieder ein (keine partielle Mutation bleibt liegen). **Update-Pfad-Ergänzung (Review-Loop-2):** bei einem FAIL im Update-Pfad (§5.9) gilt derselbe Grundsatz für **modifizierte** Pfade — die vor dem Run geänderten Concept-Pfade (und die `log.md`-Einträge des Runs) werden aus dem Baseline-Zustand wiederhergestellt (z. B. `git checkout -- <wiki/pfad>`; der Baseline-Commit ist der in R-1/Pkt. 6 notierte `<Baseline-Commit>`), sodass kein teilweise aktualisierter Concept-State liegen bleibt.
-4. **Dokumentation (`log.md`, Vertrag §5):** Die Anlage neuer Concepts wird als datumsgruppierter Eintrag in `wiki/log.md` dokumentiert (neueste zuerst; Header = ISO-Datum `YYYY-MM-DD`), verknüpft mit dem neuen Concept-Pfad und den genutzten `raw/`-Quellen. `log.md` bleibt ohne Frontmatter (Punkt 10).
+4. **Dokumentation (`log.md`, Vertrag §5):** Die Anlage neuer Concepts wird als datumsgruppierter Eintrag in `wiki/log.md` dokumentiert (neueste zuerst; Header = ISO-Datum `YYYY-MM-DD`), verknüpft mit dem neuen Concept-Pfad und den genutzten `raw/`-Quellen. `log.md` bleibt ohne Frontmatter (Punkt 10). **Kanonische Log-Eintragsform (Revision 3.8, Story 3.13 — additive Präzisierung für den Determinismus-Vertrag §5.14/AD-17h):** der Anlage-Eintrag trägt **exakt** die kanonische Form `- Anlage: <concept> (<quellen>; Baseline <Baseline-Commit>)` mit: `<concept>` = die relative OKF-Identität **ohne** `.md` (ohne Backticks, ohne Zusatz-Labels); `<quellen>` = die genutzten `raw/`-Quellen, **lexikografisch (LC_ALL=C) sortiert** und per ` + ` getrennt; `<Baseline-Commit>` = der **volle** SHA. **Kein freier Zusatztext** und **kein Wanduhr-Wert** im `log.md`-Body (der Wanduhr-Wert lebt ausschließlich im Frontmatter-`generated.at`, §5.14 Pkt. 3-Ausnahme) — der Eintrag ist damit **byte-deterministisch** aus dem committeten Git-State + dem kanonischen Eingabeset (§5.14 Pkt. 2) ableitbar. Für die Synthese-Neu-Anlage gilt dieselbe Form mit dem Operations-Label `Synthese-Anlage` (§5.10 Pkt. 7, Revision 3.8).
 
 ## 5.5 Claim-granulare Provenienz (Story 2.2)
 
@@ -274,7 +274,7 @@ Diese Sektion ist der **einzige Instruktions-Ort** der Update-Mutationsmechanik
      - **Erweitern — Abgrenzungskriterium:** greift dann, wenn die neue committete Evidenz eine **neue belegte Aussage** trägt, die im bestehenden Body **nicht** existiert (Term-/Stellen-Abgleich gegen die §5.5-Inline-Verweise; kein bestehender Anker). **Struktur-Erhaltungsregel (Erweitern):** die neue Aussage wird als **eigener Absatz angefügt** (Body-Ende); bestehende belegte Aussagen bleiben **byte-identisch**, keine Umschreibung bestehender Absätze; Frontmatter nur `sources`-**Zuwachs um den echten neuen Beleg** + ein `generated.at`-Bump. **Textgenauigkeits-Rahmen (Erweitern):** die neue Aussage wird eigenständig formuliert, trägt den §5.5-Inline-Beleg mit existierender Stellen-Kennung; kein Satz-Umbau des Bestands. *(Überlappt eine Einheit mehrere Formen — z. B. sie trägt zugleich eine neue belegte Aussage und eine Schärfung einer bestehenden —, ordnet der Producer die Einheit der in der Abgrenzungs-Reihenfolge ersten zutreffenden Form zu (deterministisch, AD-17h); die Textgenauigkeits-Rahmen der übrigen Formen gelten für die jeweiligen Teilbestandteile unverändert.)*
      - **No-Op — Abgrenzungskriterium (Nicht-Form, engere Auslegung, bestehende Regel oben):** greift nur, wenn **keine** der drei Formen greift (die Evidenz ist bereits vollständig im Body); im Zweifel trifft eine der drei Formen — die Entscheidung ist textuell deterministisch (Term-/Stellen-Abgleich). **Erhaltungsregel (No-Op):** volle Byte-Identität (keine Mutation, kein `at`-Bump, kein `sources`-Zusatz, kein `log.md`-Eintrag).
 3. **Index-/Link-Form unverändert (§5.6-Pin):** Ein reines Body-Update ändert die Concept-Identität nicht → der bestehende Index-Link (Bundleroot oder Area-`index.md`) bleibt unverändert gültig; **kein neuer Link** bei reinem Body-Update (kein Index-`index.md`-Zusatz). Die **`log.md`-Eintragspflicht** (Pkt. 4) bleibt davon **unberührt**: *jedes* Update — auch ein reines Body-Update — MUSS seinen `log.md`-Eintrag „Story 3.1-Update" führen; nur der **Index-**Link bleibt unverändert. Wird durch das Update eine Concept-Kategorie (Root vs. Area) oder die Identität berührt, ist das **Ask-First** (AD-7d-Renames/Redirects; nicht Teil von Story 3.1). Neue zulässige Concept-Links (Beziehungsschicht, §5.6) werden nur gesetzt, wenn die neue Erkenntnis eine echte, inhaltsbegründete Beziehung rechtfertigt.
-4. **`log.md`-Eintragspflicht (Vertrag §5):** Jedes Update wird als datumsgruppierter Eintrag in `wiki/log.md` dokumentiert (Header = ISO-Datum `YYYY-MM-DD`, neueste zuerst), verknüpft mit dem mutierten Concept-Pfad und den genutzten `raw/`-Quellen. Für Updates wird der Eintrag als „**Story 3.1-Update**" markiert (disambiguierbar von Anlage-Einträgen). Konflikt-/Erhaltungsfälle (Pkt. 2 „Korrigieren" ohne Ersetzungsevidenz) werden explizit als Disagreement-Eintrag mit dem mutierten Concept-Pfad geführt (AD-16b, Vertrag §5) — der Epic-4-Interface-Fall bleibt dokumentiert, ohne Korrektur-Klassifikation hier.
+4. **`log.md`-Eintragspflicht (Vertrag §5):** Jedes Update wird als datumsgruppierter Eintrag in `wiki/log.md` dokumentiert (Header = ISO-Datum `YYYY-MM-DD`, neueste zuerst), verknüpft mit dem mutierten Concept-Pfad und den genutzten `raw/`-Quellen. Für Updates wird der Eintrag als „**Story 3.1-Update**" markiert (disambiguierbar von Anlage-Einträgen). Konflikt-/Erhaltungsfälle (Pkt. 2 „Korrigieren" ohne Ersetzungsevidenz) werden explizit als Disagreement-Eintrag mit dem mutierten Concept-Pfad geführt (AD-16b, Vertrag §5) — der Epic-4-Interface-Fall bleibt dokumentiert, ohne Korrektur-Klassifikation hier. **Kanonische Log-Eintragsform (Revision 3.8, Story 3.13 — additive Präzisierung für den Determinismus-Vertrag §5.14/AD-17h, kein Re-Negotiation des obigen Regeltexts):** Der Update-Eintrag trägt **exakt** die kanonische Form `- Story 3.1-Update: <concept> (<neue-Quellen>; Baseline <Baseline-Commit>)` mit: `<concept>` = die relative OKF-Identität **ohne** `.md` (ohne Backticks, ohne Zusatz-Labels wie `neu:`); `<neue-Quellen>` = die in diesem Run **neu** hinzugekommenen `raw/`-Quellen, **lexikografisch (LC_ALL=C) sortiert** und per ` + ` getrennt (eindeutig aus der Zuwachs-Sicht, Pkt. 6 R-1 — bei einer einzelnen Quelle nur der eine Pfad); `<Baseline-Commit>` = der **volle** SHA (Pkt. 6 R-1). Der Eintrag trägt **keinen freien Zusatztext** (keine Update-Typ-Erklärung, keine §-/Pkt.-Referenzen, keine Beleg-Stellen-Kennungen) und **keinen Wanduhr-Wert** (`generated.at`/`verified[].at`) — der Wanduhr-Wert lebt **ausschließlich** im Frontmatter-`generated.at` (§5.14 Pkt. 3-Ausnahme), nie im `log.md`-Body. Die `## YYYY-MM-DD`-Datumsgruppe (neueste zuerst, Pkt. 4) ist Teil der Form und wird über den Eintrag gehoben. Damit ist der Eintrag **byte-deterministisch aus dem committeten Git-State + dem kanonischen Eingabeset** (§5.14 Pkt. 2) ableitbar: zwei unabhängige Runs desselben Git-States + desselben Eingabesets liefern **byte-identische** `log.md`-Einträge (identische Datumsgruppe, identische Werte). Die Anlage- und Synthese-Neu-Anlage-Einträge folgen derselben kanonischen Form mit ihrem jeweiligen Operations-Label (§5.1 Pkt. 4, §5.10 Pkt. 7 — Revision 3.8).
 5. **Erhaltungs-Invariante (Kern) + deterministischer Diff-Selbsttest (AD-17h, FT-6/FR-12):** Ein Compilation Run darf nur die Concepts **neu anlegen oder verändern**, die durch den erkannten Erkenntnis-Zuwachs tatsächlich betroffen sind. **Nicht betroffene Concept-Pfade bleiben byte-identisch unverändert** — es gibt **nie** „Regenerate Everything" (AD-5, A0-6). Die Inkrementalität ist als **re-executierbarer Diff-Selbsttest** mechanisch kontrollierbar: Nach jedem Run prüft der Producer ab der Workspace-Root
    ```sh
    git diff --name-only <Baseline-Commit> -- wiki/
@@ -298,7 +298,7 @@ Diese Sektion ist der **Instruktions-Ort der Synthese-Dimension** (AD-4, FR-7):
 4. **Übernahme aus bestehenden Concepts (AD-4c — nie alleinige Provenienz):** Übernimmt das Synthese-Concept Formulierungen aus bestehenden Concepts (Kontext-/Synthese-Umformulierung, nicht eigenständig gegen `raw/` belegt), trägt die übernommene Aussage den **§5.5-Kontext-Marker** (Pkt. 2, Muster „übernommen aus `<Concept>` auf Basis von `<source>`, nicht eigenständig belegt") — **kein bestehendes Concept ist alleinige Provenienz eines anderen**. Die Quelle des übernommenen Concepts bleibt damit textuell rückverfolgbar; die Direktübernahme aus `raw/` (ohne Zwischen-Concept) verwendet das Muster „übernommen aus `<source>` (rohe Quelle), nicht eigenständig belegt". **Sandbox-Szenario N3** demonstriert den Kontext-Marker („übernommen aus `gamma` auf Basis von `raw/gamma-v1.md#S-1`, nicht eigenständig belegt") und prüft, dass die Quelle des übernommenen Concepts **nicht** als eigene `sources`-Quelle eingetragen wird (AD-4c).
 5. **Reflektierter Wissensstand (FR-7 AC-4, NFR-7):** Der Body trägt **integrierte, je Aussage provenance-tags versehene Aussagen** — **keine per-Source-Zusammenfassungs-Struktur** (keine Blöcke „Quelle A: … / Quelle B: …"). **Reflektiertheits-Selbsttest (textuell deterministisch, grepbasiert):** es existiert **keine** Zeile, die einen Quell-Label abschnittsstrukturiert — das Muster ist ein Zeilenanfangs-Label „`Quelle <Label>:`"/„`Source <Label>:`" (einbuchstabig, mehrbuchstabig oder mit Ziffer/Unterstrich suffigiert), grepbasiert `grep -nE '^(Quelle|Source) [A-Z][A-Za-z0-9_ -]*:' <Synthese-Concept>` liefert leer; jede Aussage trägt ihren Provenienz-Tag (§5.5). Ein Befund (Aneinanderreihung) ist ein **Instruktions-Selbsttest-FAIL** (NFR-7, kein stiller Vorbeilass — NFR-4): der Producer stellt den Body vor Run-Abschluss so um, dass die Integration erfüllt ist.
 6. **§5.6-Pin unverändert:** Synthese fügt **keine neue Linkform** und **keine** neuen `index.md`-Links ohne echte, inhaltsbegründete Beziehung hinzu — §5.6-Pin (genau-eine-Linkform, file-relativ mit `.md`-Endung) und §5.9 Pkt. 3 (kein neuer Index-Link bei reinem Body-Update) gelten unverändert. **Form-Wahl-Klassifikationsprobe (Defer U2/U7, Story 3.3):** eine Synthese-Einheit, die zugleich neue + schärfende + ersetzende Anteile trägt (Form-Überlapp), wird per §5.9-Abgrenzungs-Reihenfolge `Korrigieren → Präzisieren → Erweitern → No-Op` **strikt pro Evidenz-Einheit** der **ersten zutreffenden Form** zugeordnet (deterministisch, AD-17h); die Textgenauigkeits-Rahmen der übrigen Formen gelten für die jeweiligen Teilbestandteile unverändert.
-7. **`log.md`-Eintragspflicht (Vertrag §5):** Jede Synthese wird als datumsgruppierter Eintrag in `wiki/log.md` dokumentiert. Ein Synthese-**Update** auf ein bestehendes Concept führt den Eintrag „**Story 3.1-Update**" (Disagreement-Fälle als Disagreement-Eintrag mit dem mutierten Concept-Pfad, AD-16b); eine Synthese-**Neu-Anlage** eines neuen Synthese-Concepts führt einen **Anlage-Eintrag** (disambiguierbar von Update-Einträgen). Der Eintrag verknüpft das erzeugte Concept mit der **vollständigen Multi-Source-`sources`-Liste** und hält den `<Baseline-Commit>` (R-1, §5.9 Pkt. 6) fest.
+7. **`log.md`-Eintragspflicht (Vertrag §5):** Jede Synthese wird als datumsgruppierter Eintrag in `wiki/log.md` dokumentiert. Ein Synthese-**Update** auf ein bestehendes Concept führt den Eintrag „**Story 3.1-Update**" (Disagreement-Fälle als Disagreement-Eintrag mit dem mutierten Concept-Pfad, AD-16b); eine Synthese-**Neu-Anlage** eines neuen Synthese-Concepts führt einen **Anlage-Eintrag** (disambiguierbar von Update-Einträgen). Der Eintrag verknüpft das erzeugte Concept mit der **vollständigen Multi-Source-`sources`-Liste** und hält den `<Baseline-Commit>` (R-1, §5.9 Pkt. 6) fest. **Kanonische Log-Eintragsform (Revision 3.8, Story 3.13 — additive Präzisierung für den Determinismus-Vertrag §5.14/AD-17h):** die Synthese-**Neu-Anlage** trägt **exakt** die kanonische Form `- Synthese-Anlage: <concept> (<quellen>; Baseline <Baseline-Commit>)` (Operations-Label `Synthese-Anlage`, disambiguierbar von `Anlage`/`Story 3.1-Update`); `<quellen>` = die **vollständige** Multi-Source-`sources`-Liste, **lexikografisch (LC_ALL=C) sortiert** und per ` + ` getrennt; `<Baseline-Commit>` = der **volle** SHA. **Kein freier Zusatztext** und **kein Wanduhr-Wert** im `log.md`-Body (der Wanduhr-Wert lebt ausschließlich im Frontmatter-`generated.at`, §5.14 Pkt. 3-Ausnahme) — der Eintrag ist **byte-deterministisch** aus dem committeten Git-State + dem kanonischen Eingabeset (§5.14 Pkt. 2) ableitbar. Das Synthese-**Update** folgt der kanonischen Update-Form von §5.9 Pkt. 4 (`Story 3.1-Update`, Revision 3.8).
 8. **Erhaltungs-Invariante & Determinismus-Vertrag (AD-17h/A0-19):** Der **§5.9-Pkt.-5-Diff-Selbsttest gilt für Synthese-Runs unverändert**: die mutierten/neu angelegten Pfade sind eine Teilmenge von (Kandidatenliste ∪ Neu-Anlage-Zielpfade ∪ `log.md` ∪ nachgeführte `index.md`) — **keine neue Datei außer echten Ziel-Pfaden** (Duplikat-Kontrolle via `??`-Sicht, `git status --porcelain -- wiki/`). Gleicher Git-State + gleiche Eingabemenge → identischer Synthese-Vorgang (Ziel-Pfad via §3.2/§5.7, `sources`-Liste lexikografisch nach `resource` LC_ALL=C, Konsolidierung und Form-Zuordnung wie Pkt. 3/6); der `generated.at`-Wanduhr-Gap (gleiches Eingabeset, unabhängige Runs, verschiedene `at`) bleibt offene A0-20-Konvention mit Home **Story 3.8** (§5.9 Pkt. 2, `generated.at`-Konvention) — unverändert bindend. **Duplikat-Fall (Synchronisation zwischen Concepts und Evidenzbasis):** ein `raw/`-Quellpfad erscheint **nur einmal** in einer `sources`-Liste — ein bestehender Eintrag derselben `resource` wird **nicht** doppelt angelegt (die Neuanlage eines Synthese-Concepts setzt voraus, dass kein bestehendes Concept dieselbe Quelle bereits mit derselben Stellen-Kennung als Beleg nutzt; für Update-Fälle gilt das §5.9-Pkt.-2-Prinzip „bestehende Einträge bleiben unverändert" — der Zuwachs einer Quelle, die bereits existiert, wird niemals doppelt eingetragen). **Unzugeordnete/verwaiste Evidenz (Orphan-Kontrolle, pre-existing — dokumentiert den Vertrag, wie er vor dieser Story bestand):** neu committete `raw/`-Evidenz ohne Ziel-Pfad-Treffer bleibt **unzugeordnet** (weder still getilgt noch hintenherum als eigenes Concept angelegt) und wird in `log.md` als verwaist protokolliert — kein Banner/keine stille Vorbearbeitung; eine Präzisierung der Reconcile-Orphan-Politik leistete die Verankerung in §5.13-Phase 5 / **die deterministische Reconcile-Orphan-Regel unten (Story 3.8; §5.14 Pkt. 5)** — eine Staffelung an Epic-4 (Story 4.1) bleibt für die Verwaist-Klassifikation offen. **Deterministische Reconcile-Orphan-Regel (Story 3.8; §5.14-Präzisierung):** der Verwaist-Befund — neu committete `raw/`-Evidenz ohne jeglichen Ziel-Pfad-Treffer (kein Update-Kandidat nach §3.2, keine Synthese-Zuordnung nach Pkt. 1–7, kein §5.7-Neu-Anlage-Ziel-Pfad) — wird deterministisch aus dem committeten Git-State erhoben (Zuwachs gg. `<Baseline-Commit>`, §5.9 Pkt. 6 R-1) und als **datumsgruppierter `log.md`-Eintrag** verwaist protokolliert (Header `YYYY-MM-DD`, neueste zuerst — Vertrag-§5-Datumsgruppe; Quell-Pfad + `<Baseline-Commit>`); **kein Banner**, **keine stille Vorbearbeitung**, **keine** eigenständige Concept-Anlage aus verwaister Evidenz (AD-16-Default: Erhaltung — die Evidenz bleibt in `raw/` unangetastet, AD-3; keine Korrektur-/Erweiterungs-Klassifikation hier vorweggenommen — Epic-4-Interface, Story 4.1). **Präzisierung (Review-Loop-3, D-4):** die obige „Staffelung an Epic-4 (Story 4.1)" betrifft ausschließlich die **Korrektur-/Erweiterungs-Klassifikation** verwaister Evidenz (Epic-4-Interface, Story 4.1); der **Hold selbst** (Erhaltung der unzugeordneten `raw/`-Evidenz im benannten Hold ohne Wissensmutation, NFR-7) hat seinen Home in **Story 3.10 (Epic 3)** und ist in **§5.16** dieser Instruktion verankert (Story 3.10, Hold-Ausbau: post-Reconcile-Orphan über alle Erhebungs-Stufen a/b/c, Mehrziel-Auflösung, benannter Hold mit beiden Evidenzpfaden im Run-Receipt) — die Reconcile-Orphan-Regel dieses Bullets ist die deterministische Verankerung dieses Holds in der Instruktion. Gleicher Git-State + gleiche Eingabemenge ⇒ identischer Verwaist-Befund und identischer `log.md`-Eintrag (AD-17h/A0-19, §5.14).
 
 ## 5.11 Leasing & Dirty-Tree-Schutz für konkurrierende Producer (Story 3.5)
@@ -541,3 +541,8 @@ Diese Instruktion ist auf die **Erzeugung neuer Concepts auf Root-Ebene und in A
 - **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).
+- **Revision 3.8 (2026-08-23, Story 3.13, Epic-1-Remediation — D-3-Instruktions-Patch, autorisiert; additive Präzisierung der `log.md`-Eintragsform, kein Re-Negotiation des Bestehenden):** **Kanonische, byte-deterministische `log.md`-Eintragsform** fixiert, um den Determinismus-Vertrag §5.14/AD-17h (Zwei-Run-Identität) im `log.md`-Body zu erfüllen — der A/B-Vergleich (Story 3.13 E.4) verlangt **byte-identische** Bundle-State-Bestandteile außerhalb der benannten `at`-Ausnahme (§5.14 Pkt. 3), während die bisherige `log.md`-Eintragspflicht („verknüpft mit dem Concept-Pfad und den Quellen", ohne Wort-Pin) zwei unabhängige Läufe mit **freiem Zusatztext** erlaubte (Update-Typ-Erklärung, §-/Pkt.-Referenzen, Beleg-Stellen-Kennungen, Wanduhr-`generated.at` im Body, Eintragsreihenfolge) — jede dieser Freiheiten erzeugt eine NON_AT-Differenz und damit einen AD-16-Klassifikationsdefekt. Die gepinnte Form (in **§5.9 Pkt. 4** Update, **§5.1 Pkt. 4** Anlage, **§5.10 Pkt. 7** Synthese-Neu-Anlage) ist:
+  - **Update:** `- Story 3.1-Update: <concept> (<neue-Quellen>; Baseline <Baseline-Commit>)`
+  - **Anlage:** `- Anlage: <concept> (<quellen>; Baseline <Baseline-Commit>)`
+  - **Synthese-Neu-Anlage:** `- Synthese-Anlage: <concept> (<quellen>; Baseline <Baseline-Commit>)`
+  mit `<concept>` = relative OKF-Identität **ohne** `.md` (ohne Backticks, ohne Zusatz-Labels wie `neu:`); `<quellen>`/`<neue-Quellen>` = die (neu) genutzten `raw/`-Quellen **lexikografisch (LC_ALL=C) sortiert**, per ` + ` getrennt (eindeutig aus der Zuwachs-Sicht, §5.9 Pkt. 6 R-1); `<Baseline-Commit>` = **voller** SHA (R-1); die `## YYYY-MM-DD`-Datumsgruppe (neueste zuerst) ist Teil der Form und wird über den Eintrag gehoben. **Kein freier Zusatztext** und **kein Wanduhr-Wert** im `log.md`-Body — der Wanduhr-Wert lebt **ausschließlich** im Frontmatter-`generated.at` (§5.14 Pkt. 3-Ausnahme), nie im `log.md`-Body. Damit ist jeder Eintrag **byte-deterministisch** aus dem committeten Git-State + dem kanonischen Eingabeset (§5.14 Pkt. 2) ableitbar: zwei unabhängige Runs desselben Git-States + desselben Eingabesets liefern **byte-identische** `log.md`-Einträge (identische Datumsgruppe, identische Werte). Die Form ist diejenige, die die Sandbox-Sub-Runs 3-3/3-4 **mechanisch bereits demonstrieren** (`- Story 3.1-Update: <concept> (<quellen>; Baseline <SHA>)`, `- Synthese-Anlage: <concept> (<quellen>; Baseline <SHA>)`), nun als normative Instruktion fixiert — kein Widerspruch, sondern Verankerung des Ist-Behaviours. **Nicht geändert:** §5.14 Pkt. 3 (die `at`-Ausnahme bleibt **ausdrücklich** die `generated.at`/`verified[].at`-Feldwerte — der `log.md`-Body-Wanduhr-Verbot ist eine Folge davon, keine Änderung der Ausnahme-Menge), §5.10 Pkt. 3 (CREATE/Synthese-Body-Wortung bleibt „Befund-Äquivalenz, nicht Wort-Identität" — der Pin betrifft **nur** den `log.md`-Eintrag, **nicht** den Concept-Body), §5.1 Pkt. 2 (FR-2 „eigenständig formuliert" — der Body bleibt eigenständig formuliert, der `log.md`-Eintrag ist Buchführung, kein Body), die §5.9-/§5.10-Regeltexte oberhalb der Pins (textuell **unverändert**; der Pin ist ein additiver Sub-Regeltext). **Slug-/Term-Ableitung (CREATE-Zielpfad):** **nicht** in dieser Revision geändert — der CREATE-Slug-Ableitungsmechanismus (§5.15 Pkt. 1 Dateiname→Term, §5.7-Ziel-Pfad) bleibt wie ist; die Story-3.13-E.4-A/B-Prüfung deckt den **Update-/Erhaltungs-Kern** (D-3.13-6 Option 2), der CREATE-/Synthese-Kern gilt über die Sub-Runs 3-3/3-4 als demostriert. Ein CREATE-Zielpfad-Signal-Pin (Inhalts-Term maßgeblich vs. Dateiname-Stamm) bleibt **offener Defer** (Ask-First-Kandidat für eine künftige Revision, nicht Teil dieser Remediation). **Abschlussklausel:** Keine Änderung an `schema/wiki-compiler.md`/`schema/validator.md`/`adapters/`/`raw/` (AD-3); **keine neue §7-Invaliditätsklasse**; **kein Standalone** (D-3); keine Vertragsänderung; **kein neuer Prädikat-/Format-/Frontmatter-Key**; das `generated.at`-Verhalten selbst **unverändert** (nur: kein Wanduhr-Wert im `log.md`-Body — eine Folge der §5.14 Pkt. 3-Ausnahme, kein Verhaltenswechsel); keine Workflow-Engine (AD-6, AD-11); Commit-Boundary-Regel unverändert. **`sprint-status.yaml`:** Story 3.13 bleibt **`in-progress`** (Remediation durchgeführt; Abschluss-Flip `done` erfolgt im Step-05-Status-Sync nach grünem Re-Run #6).