Compare commits
15
Commits
6624e07d3b
...
3f57586a50
| Author | SHA1 | Date | |
|---|---|---|---|
|
|
3f57586a50 | ||
|
|
09c1c83a5a | ||
|
|
cccc0a35e9 | ||
|
|
65dfc26961 | ||
|
|
77fd460ec3 | ||
|
|
2a9fa89f8a | ||
|
|
7c3c19bac4 | ||
|
|
fb4c1c8b05 | ||
|
|
5029124445 | ||
|
|
37d9fdcec5 | ||
|
|
90a01fed37 | ||
|
|
35b5939df6 | ||
|
|
52312c254b | ||
|
|
50f3628df4 | ||
|
|
894ae346ab |
+115
@@ -0,0 +1,115 @@
|
|||||||
|
---
|
||||||
|
title: "Arbeitsauftrag — compiler.md Rev 3.7 → 3.8 (Epic-1-Remediation, Story 3.13): CREATE-Slug + log-Determinismus-Patch"
|
||||||
|
status: AUSGEFÜHRT (Teilumsetzung) — B2 (log-Form-/Wanduhr-Pin) + A/B-Umfang (b) angewendet, Rev 3.8 committet; B2-Reihenfolge-Hälfte + B1 (Slug) = offene Defers; C (Body-Byte) = zurückgewiesen (FR-2). Siehe §0.1 Ausführungsstatus.
|
||||||
|
date: 2026-08-23
|
||||||
|
owner: ProMods
|
||||||
|
related: spec-3-13-epic-3-verifikations-und-abnahmegate.md, spec-3-8-determinismus-vertrag-ad-17h-als-agent-instruktions-validato.md, deferred-work.md
|
||||||
|
---
|
||||||
|
|
||||||
|
# Arbeitsauftrag — compiler.md Rev 3.7 → 3.8 (Epic-1-Remediation, Story 3.13)
|
||||||
|
|
||||||
|
**Stellenwert:** Dies ist der **Autorisierungs-Träger** der separat autorisierten Epic-1-Remediation (AC-4-Pfad; Präzedenz Validator-Rev-8/9, AD-3-Compliance: keine stille Schema-Semantik-Änderung durch das Gate).
|
||||||
|
|
||||||
|
## 0.1 Ausführungsstatus (2026-08-23, Nutzer-Autorisierung „continue" — superset des §0-Empfehlungs-Vorschlags (b))
|
||||||
|
|
||||||
|
Dieser Entwurf legte drei Bausteine fest: **B1** (CREATE-Slug-Signal), **B2** (log-Determinismus), **C** (CREATE-Body-Byte-Residual, an die A/B-Umfangs-Entscheidung (a)/(b)/(c)/(d) gebunden). Nach der exakten Zeilen-Nachzähl des Re-Run-#5-Befunds (NON_AT=26 AT=4; 24/26 = 92 % CREATE-/Slug-getrieben) und der Nutzer-Autorisierung („continue" auf den empfohlenen Minimal-Änderungssatz) wurde **ausgeführt**:
|
||||||
|
|
||||||
|
| Baustein | Status | Umsetzung |
|
||||||
|
|---|---|---|
|
||||||
|
| **B2** — kanonische, byte-deterministische `log.md`-Eintragsform + Reihenfolge-Pin | 🟡 **TEILANGEWENDET** (Rev 3.8; Reihenfolge-Hälfte = offener Defer, D-3.13-L2-1) | **Angewendet (Rev 3.8):** die kanonische Eintragsform + kein Wanduhr-at im Body — §5.9 Pkt. 4 (Update), §5.1 Pkt. 4 (Anlage), §5.10 Pkt. 7 (Synthese-Anlage) + §8 Revisionslog. Form = `- <Operation>: <concept> (<quellen>; Baseline <SHA>)`, lex (LC_ALL=C) sortiert, ` + ` getrennt, voller SHA, **kein** freier Zusatztext, **kein** Wanduhr-at im Body (Wanduhr ausschließlich im Frontmatter-`generated.at`, §5.14 Pkt. 3). **Nicht angewendet (offener Defer, Review-Loop-2 D-3.13-L2-1):** der Entwurf-B2-Hälfte „**Reihenfolge pinnen**" (Reihenfolge der Log-Einträge *innerhalb* einer `## YYYY-MM-DD`-Datumsgruppe) ist **nicht** in compiler.md gelandet (grep 0 Treffer „Innerhalb einer Datumsgruppe"/Tie-Break) — nur die Form-/Wanduhr-Hälfte wurde umgesetzt. Latent (3× A/B-`log.md` byte-identisch, noch nie rot); Defer in deferred-work.md. |
|
||||||
|
| **A/B-Umfang (b)** — CREATE aus der A/B-Fixture nehmen (D-3.13-6 Option 1 → Option 2) | ✅ **ANGEWENDET** (Gate) | `run-sandbox.sh` E-Sektion: E.1 (keine beta-Quellen), AGENT_PROMPT (beta-Fakt entfernt), E.5 (CREATE-Witness entfernt, UPDATE-`alpha` bleibt), E.8 (index.md unverändert, IDX_ADDED=0), Header. A/B prüft den Update-/Erhaltungs-Kern; CREATE/Synthese gelten über Sub-Runs 3-3/3-4. |
|
||||||
|
| **B1** — CREATE-Slug-Signal (Inhalts-Term maßgeblich) | ⏸️ **DEFER** (offen) | **Nicht** in Rev 3.8 — der CREATE-Fall steht nicht mehr in der A/B-Fixture, daher ist der Slug-Pin für den grünen Re-Run #6 **nicht** erforderlich. Als **benannter Defer / Ask-First-Kandidat** dokumentiert (in compiler.md Rev 3.8 + Spec Change Log); §5.15 Pkt. 1 (Dateiname→Term) / §5.7 bleiben wie ist. |
|
||||||
|
| **C** — CREATE-Body byte-deterministisch | ❌ **ZURÜCKGEWIESEN** (FR-2) | Q1-Item (2) = Option (c): ein Byte-Pin des CREATE-Body widerspricht §5.1/FR-2/§5.10 Pkt. 3 („Befund-Äquivalenz, **nicht** Wort-Identität") direkt — Semantik-Change, kein Bugfix. Bewusst **nicht** ausgeführt. |
|
||||||
|
|
||||||
|
**Konsequenz für Re-Run #6:** erwartetes E.4-Ergebnis `NON_AT=0 AT=2` (`alpha.md` at-only; `log.md` byte-identisch via gepinnter Form; `gamma.md`/`index.md` unverändert). **Nicht berührt:** frozen I/O-Matrix-Block (inkl. `GENERATED_AT_AUSNAHME`), §5.14 Pkt. 3 (at-Ausnahme = Feldwerte), §5.10 Pkt. 3 (Body-Wortlaut), §5.1 Pkt. 2 (FR-2). **Commit:** `7c3c19b` (compiler.md Rev 3.8 + Gate + dieser Autorisierungs-Träger). **Ausstehend:** 12-Sandbox-Re-Execution, Re-Run #6 (grüner Voll-Lauf), Review-Loop-2 + finaler `done`-Flip (Step-05-Status-Sync nach grünem Re-Run #6).
|
||||||
|
|
||||||
|
**Unten:** der ursprüngliche Entwurfstext (B1 §1, B2 §2, C §3) bleibt als **historische Entscheidungsgrundlage** erhalten — die ausgeführte Form steht in §0.1; wo B1/B2 im Folgenden als „ready-to-apply" beschrieben sind, gilt: B2 **teil**angewendet (Form-/Wanduhr-Hälfte ja; **Reihenfolge-Hälfte nicht** — offener Defer D-3.13-L2-1, Review-Loop-2), B1 nicht angewendet (Defer).
|
||||||
|
|
||||||
|
## 0. Prämisse-Korrektur (warum dieser Entwurf anders aussieht als die Q1-Prämisse)
|
||||||
|
|
||||||
|
Die Q1-Autorisierung („(1) CREATE-Slug-Signal pinning, (2) CREATE-Body-kanonische Form (byte-deterministisch), (3) log.md-Regel") beruhte auf dem Befund „26 NON_AT-Zeilen = freie CREATE-Synthese". Gegen den **realen A/B-Diff** des Re-Run #5 (`/tmp/gate-313-run5.log`, Z. 1240–1330) aufgerechnet ist das **invertiert**:
|
||||||
|
|
||||||
|
| Quelle | NON_AT-Zeilen | Natur |
|
||||||
|
|---|---|---|
|
||||||
|
| `wiki/beta.md` (gelöscht) | 11 = 10 Frontmatter + 1 Body-Satz | Frontmatter **byte-identisch**; gezählt als delete **nur wegen Pfad `beta`** |
|
||||||
|
| `wiki/quanten-observatorium-kanal.md` (neu) | 11 = 10 Frontmatter + 1 Body-Satz | Frontmatter **byte-identisch**; gezählt als add **nur wegen Pfad `quanten-…`** |
|
||||||
|
| `wiki/index.md` | 2 (Link-Zeile) | **Slug-getrieben** |
|
||||||
|
| `wiki/log.md` | 4 | gemischt: Slug-Name + **Reihenfolge** + **Wanduhr-`at` im Body** + freier Wortlaut |
|
||||||
|
| **Summe** | **26** | — |
|
||||||
|
|
||||||
|
- **22/26 (85 %) sind Slug-getrieben** — die 20 Frontmatter-Zeilen sind inhaltlich identisch; git zählt sie als gelöscht+addiert **nur weil die Dateinamen divergieren** (`beta` vs. `quanten-observatorium-kanal`), plus 2 Index-Links.
|
||||||
|
- **Nur 2 Zeilen** sind die eigentliche freie CREATE-Prosa (ein Body-Satz pro Lauf); **4 Zeilen** log.md, davon **2 strukturell** (Reihenfolge ungepinnt + Wanduhr-`at` im Body) und 2 frei (Wortlaut).
|
||||||
|
|
||||||
|
**Quelltext-Verankerungen (Zeilen, `schema/compiler.md`):**
|
||||||
|
- `§5.14 Pkt. 3` (L375): Zwei-Run-Vergleich lässt **genau eine** benannte Differenz zu (`generated.at`); **alle übrigen** Bestandteile **byte-identisch**.
|
||||||
|
- `§5.10 Pkt. 3` (L297): CREATE-/Synthese-Body-**Reihenfolge** deterministisch gepinnt (lex nach Beleg-Anker, LC_ALL=C); **Wortlaut** nicht — dort explizit „Befund-Äquivalenz, **nicht** Wort-Identität".
|
||||||
|
- `§5.1 Pkt. 2` (L84) + `§5 Pkt. 3` (L34, FR-2): Body **eigenständig formuliert**; „Bloße Kopie … DÜRFEN nicht erzeugt werden"; „Der Body darf keine großen Quell-Exzerpte enthalten".
|
||||||
|
- `§5.14 Pkt. 2` (L374) + spec-3-8 P-5 (L150): 3.8-Basis **nur mechanisch simuliert** (Subshell-Läufe), **nur UPDATE-Pfad**, **nie** echte frische LLMs; „der Nachweis echter frischer Kontexte erfolgt im Story-3.13-Abnahmegate über reale Agent-Läufe".
|
||||||
|
|
||||||
|
**Konsequenz:** Q1-Item (1) **Slug** und (3) **log-Struktur** sind **FR-2-sicher, determinismus-pflichtig (routing/log sind ohnehin deterministisch, §5.7/§5.15/§5.10-AD-17h) und frozen-Block-unabhängig** → **B1/B2 unten, ready-to-apply**. Q1-Item (2) **CREATE-Body byte-deterministisch** ist **nicht FR-2-sicher** (Byte-Pin bricht `§5.1`/FR-2/`§5.10 Pkt. 3`) → **C unten, an die (a)/(b)/(c)/(d)-Entscheidung gebunden**. Der latente Kern: `§5.14 Pkt. 3` (Byte-Identität) vs. `FR-2`/`§5.10 Pkt. 3` (freies, nicht-wortidentisches Wortlaut) — in 3.8 durch Simulation verdeckt, in 3.13/E.4 aufgedeckt.
|
||||||
|
|
||||||
|
## 1. B1 — CREATE-Slug-Signal: Inhalts-Term maßgeblich (FR-2-sicher, ready-to-apply)
|
||||||
|
|
||||||
|
**Problem (AD-16-Instruktionslücke):** Bei einem CREATE, dessen `raw/`-Dateinamen-Stamm vom erkannten Inhalts-Term abweicht (Fixture: `raw/beta-v1.md`/`beta-v2.md`, Stamm `beta`, Inhalts-Term `quanten-observatorium-kanal`), ist das **maßgebliche Slug-Signal nicht deterministisch fixiert**:
|
||||||
|
- `§5.1 Pkt. 1` (L83): „kebab-case-Slug aus der Concept-Identität … **Der Dateiname definiert die Concept-Identität** (relativer OKF-Pfad ohne `.md`, AD-7a)" — für ein **neues** Concept zirkulär (Identität = OKF-Pfad, der noch nicht existiert).
|
||||||
|
- `§5.15 Pkt. 1` (L383): „dieser kollabierte, lowercasene **Dateiname** ist der **primäre Term** je Zuwachs-Datei" — leitet den Term aus dem **Dateinamen** ab (→ `beta`).
|
||||||
|
- Design-Notes (spec L150): intendiert das Ergebnis als **term-geleitet** (→ `quanten-observatorium-kanal`).
|
||||||
|
|
||||||
|
Lauf A (`wiki/beta.md`) folgte §5.15/Dateinamen; Lauf B (`wiki/quanten-…`) folgte der term-geleiteten Intention → Divergenz = **22/26 NON_AT-Zeilen**.
|
||||||
|
|
||||||
|
**Patch (Bestandsregel, kein neues Prädikat/Kein §7-Key/kein Frontmatter-Key, AD-3/D-3-konform):** Der **CREATE-Dateiname** leitet sich vom **erkannten Inhalts-Term** (deterministisch erkannte Wissenseinheit, `§2`-Interpretation/`§3.2`) ab, nicht vom `raw/`-Dateinamen-Stamm; der Dateinamen-Stamm ist nur **Fallback**, wenn er mit dem Inhalts-Term übereinstimmt oder kein abgrenzbarer Inhalts-Term erkannt wird. Abgrenzung: das betrifft **ausschließlich die CREATE-Ziel-Namensgebung** (Zelle 2, `§5.15 Pkt. 3`); der **Reconcile-/Match-Term** (`§5.15 Pkt. 1`) bleibt **textuell unverändert** (er dient dem Match auf *bestehende* Concepts, nicht der Namensgebung neuer).
|
||||||
|
|
||||||
|
**Vorgeschlagener Wortlaut — `§5.1 Pkt. 1` (L83), Bullet 2 ersetzt:**
|
||||||
|
|
||||||
|
> **Vorher (L83):**
|
||||||
|
> - Konvention für den Dateinamen: kebab-case-Slug aus der Concept-Identität (kein Sonderzeichen, keine Endung `.md`-Dopplung). Der Dateiname definiert die Concept-Identität (relativer OKF-Pfad ohne `.md`, AD-7a).
|
||||||
|
|
||||||
|
> **Nachher (Vorschlag):**
|
||||||
|
> - Konvention für den Dateinamen: kebab-case-Slug (kein Sonderzeichen, keine Endung `.md`-Dopplung). Der Dateiname **definiert** die Concept-Identität (relativer OKF-Pfad ohne `.md`, AD-7a); bei **Neu-Anlage** (CREATE, `§5.15 Pkt. 3` Zelle 2) **entsteht** der Dateiname **deterministisch aus dem erkannten Inhalts-Term** der neuen Wissenseinheit (`§2`-Interpretation/`§3.2`; Kollaps-/Lowercase-Normalisierung `§3.2 Pkt. 1b`/`§5.15 Pkt. 1`) — **term-geleitet**. Der `raw/`-Zuwachs-Dateinamen-Stamm ist nur **Fallback**, wenn er mit dem erkannten Inhalts-Term übereinstimmt **oder** kein abgrenzbarer Inhalts-Term erkannt wird. Weichen Dateinamen-Stamm und erkannte Inhalts-Term ab, **gewinnt der Inhalts-Term** (deterministisch; Design-Intention term-geleitet) — die CREATE-Namensgebung ist damit **byte-deterministisch aus dem committeten Zustand** ableitbar (AD-17h/A0-19); eine Abweichung zweier Runs im CREATE-Slug ist ein AD-16-Klassifikationsdefekt (`§5.14 Pkt. 4`), kein Rauschen.
|
||||||
|
|
||||||
|
**Revisionslog (`§8`):** Eintrag Rev 3.8 — `§5.1 Pkt. 1` CREATE-Slug-Signal deterministisch (Inhalts-Term maßgeblich, Dateinamen-Stamm nur Fallback); kein Prädikat-/§7-/Frontmatter-Key-Change (AD-3/D-3); `§5.15 Pkt. 1`-Match-Term unverändert.
|
||||||
|
|
||||||
|
## 2. B2 — log.md-Determinismus: Reihenfolge pinnen + kein Wanduhr-`at` im Body (FR-2-sicher, ready-to-apply)
|
||||||
|
|
||||||
|
**Problem (AD-16-Instruktionslücke, 2 der 4 log-Zeilen):** `log.md`-Einträge innerhalb einer Datumsgruppe haben **keine deterministische Reihenfolge**, und **Wanduhr-`generated.at`-Werte im Body** sind nicht untersagt. Lauf A legte die Einträge in einer Reihenfolge, Lauf B in einer anderen, und Lauf B bettete `generated.at = 2026-08-23T13:48:23Z` in den log-Body ein — beides liegt **außerhalb** der benannten `at`-Ausnahme (die gilt nur für das **Frontmatter-Feld** `generated.at`/`verified[].at`, nicht für Body-Text; `§5.14 Pkt. 3`).
|
||||||
|
|
||||||
|
**Patch (Bestandsregel-Ergänzung, kein neuer Key):**
|
||||||
|
1. **Innerhalb einer Datumsgruppe** (`Header = YYYY-MM-DD`) werden die Einträge in **deterministischer Reihenfolge** geführt: lexikografisch nach **Concept-Pfad** (LC_ALL=C), Tie-Break nach **fixer Operations-Reihenfolge** (Neu-Anlage → Update → Synthese-Update → Verwaist/Hold). Die Datumsgruppen selbst bleiben „neueste zuerst" (unverändert, `§5.1 Pkt. 4`).
|
||||||
|
2. **Wanduhr-Werte im Body sind verboten:** ein `log.md`-Eintrag trägt **nur** die Datumsgruppen-Header-Zeile, das `<Baseline-Commit>` und ggf. den Beleg-/`sources`-Pfad — **kein** Wanduhr-`generated.at`-/`verified[].at`-Wert als Body-Text (der `at`-Wanduhr-Gap lebt ausschließlich im Frontmatter-Feld, `§5.14 Pkt. 3`/A0-20). Ein Eintrag mit Wanduhr-Body-Wert ist ein textuell benannter Instruktions-Verstoß (NFR-4).
|
||||||
|
|
||||||
|
**Vorgeschlagener Wortlaut — `§5.1 Pkt. 4` (L87) am Ende ergänzen:**
|
||||||
|
|
||||||
|
> **Nachher (Vorschlag, an L87 anfügen):**
|
||||||
|
> … `log.md` bleibt ohne Frontmatter (Punkt 10). **Innerhalb einer Datumsgruppe** (Header `YYYY-MM-DD`) werden die Einträge **deterministisch** geführt: lexikografisch nach **Concept-Pfad** (LC_ALL=C), Tie-Break nach **fixer Operations-Reihenfolge** (Neu-Anlage → Update → Synthese-Update → Verwaist/Hold) — gleiche Eingabemenge ⇒ identische Eintrags-Reihenfolge (AD-17h/A0-19, `§5.14`). Ein `log.md`-Body-Eintrag trägt **keinen** Wanduhr-`generated.at`-/`verified[].at`-Wert als Text (der `at`-Wanduhr-Gap lebt ausschließlich im Frontmatter-Feld, `§5.14 Pkt. 3`/A0-20); ein solcher Body-Wert ist ein textuell benannter Instruktions-Verstoß (NFR-4).
|
||||||
|
|
||||||
|
**Konsistenz:** identisch in `§5.10 Pkt. 7` (L301, Synthese-`log.md`-Eintragspflicht) spiegeln — Verweis auf die `§5.1 Pkt. 4`-Reihenfolge-/Wanduhr-Regel (eine Regel, zwei Verankerungen, Fugen-Identitäts-Präzedenz).
|
||||||
|
|
||||||
|
**Revisionslog (`§8`):** Eintrag Rev 3.8 — `§5.1 Pkt. 4`/`§5.10 Pkt. 7` log-Determinismus (intra-Date-Gruppe-Reihenfolge + kein Wanduhr-at im Body); kein Prädikat-/§7-/Frontmatter-Key-Change.
|
||||||
|
|
||||||
|
## 3. C — CREATE-Body-Byte-Residual (AN NUTZER-ENTSCHEIDUNG (a)/(b)/(c)/(d) GEBUNDEN — NICHT VORFREIGEBEN)
|
||||||
|
|
||||||
|
Nach B1+B2 bleibt das **eigentliche** freie-Prosa-Residual: **1 CREATE-Body-Satz pro Lauf + ~1–2 log-Wortlaut-Zeilen**. Zwei frische LLMs schreiben diesen freien, FR-2-mandatierten, „eigenständig formulierten" Satz **nie byte-identisch** — und `§5.14 Pkt. 3` verlangt Byte-Identität. Das ist der latente Vertragskonflikt. **Q1-Item (2) „CREATE-Body kanonische Form (byte-deterministisch)" ist genau dieser Teil und ist NICHT FR-2-sicher** (Byte-Pin bricht `§5.1`/FR-2/`§5.10 Pkt. 3`). **Dieser Abschnitt darf erst nach der Nutzer-Entscheidung umgesetzt werden.** Optionen (frozen-Block/Ask-First-Berührung gekennzeichnet):
|
||||||
|
|
||||||
|
- **(a) A/B auf Wissens-Ebene für freien Body** *(frozen-Matrix-Zeile `GENERATED_AT_AUSNAHME`, spec L49 + AC-7)* — **empfohlen**, weil vertragself-konsistent (`§5.10 Pkt. 3` sagt bereits „Befund-Äquivalenz, nicht Wort-Identität"): der freie CREATE-Body-Wortlaut wird als **zweite benannte Ausnahme-Klasse** neben `at` behandelt; **Struktur** (Slug/Frontmatter/`sources`/Provenanz-Anker/Claim-Abdeckung/Index-Link) bleibt **byte-streng**, freier **Wortlaut** per Claim-/Provenienz-Abdeckung (nicht byte-weise) verglichen. CREATE bleibt in der A/B-Fixture (AC-6 wie geschrieben). Berührt `§5.14 Pkt. 3` (Ausnahme-Menge um zweite Klasse erweitern) + frozen spec L49.
|
||||||
|
- **(b) CREATE aus A/B-Fixture nehmen** *(revidiert D-3.13-6 Option 1 → 2)* — A/B prüft nur den nachweislich byte-deterministischen UPDATE-Pfad; CREATE + Synthese gelten über Sandbox-Sub-Runs 3-3/3-4 als demostriert. AC-6-Auslegung: „Anlage neuer Wissenseinheit" über die Sub-Runs. Vertrag/frozen-Block/FR-2 unangetastet, kleinster Pfad; CREATE nicht mehr im echten frischen-Agenten-A/B-Nachweis.
|
||||||
|
- **(c) Kanonischer CREATE-Body** *(substanzieller compiler.md-Change)* — CREATE-Body auf aus `raw/` mechanisch abgeleitete Form pinnen (exakte Wortfolge der zuerst-belegenden Quelle, anchor-geordnet). Macht CREATE byte-determinisch, A/B bleibt streng. **RISIKO: bricht vmtl. FR-2** („eigenständig formuliert, keine Kopie"); eigener breiterer Autorisationsrunde würdig.
|
||||||
|
- **(d) Teil-Patch liefern, Residual rot lassen** — B1+B2 als Epic-1-Remediation geliefert (beseitigt die 22/26-Slug-Hauptursache — echter, dokumentierter Fortschritt); das kleine Prosa-Residual als **benannter Defer** an spätere Vertrags-Revision/Epic 4 → Gate bleibt rot auf einem kleinen, ehrlich verstandenen Rest; Story 3.13 in-progress.
|
||||||
|
|
||||||
|
## 4. Verifikationsplan (nach Anwendung der jeweils autorisierten Untermenge)
|
||||||
|
|
||||||
|
1. `bash -n` + Voll-Lesedurchgang `schema/compiler.md` (keine Fugen-Identitäts-Brüche; alle `§`-Verweise intakt).
|
||||||
|
2. **12 Sandbox-Suiten re-executieren** (Sub-Runs, fail-fast; `sandbox-3-1..3-12`, je `exit 0`).
|
||||||
|
3. **Re-Run #6: grüner Voll-Lauf des Gates** (`_bmad-output/implementation-artifacts/sandbox-3-13/run-sandbox.sh`, ~2.5–3.5 h, Background-Subagent, `CLAUDE_BIN` = echte winpty-freie `claude.exe` per P-3-Override, P-16-Floor 32000).
|
||||||
|
4. **Erwartetes A/B-Ergebnis je Option:**
|
||||||
|
- **(a):** E.4 `NON_AT=0` (oder `NON_AT` nur in explizit als zweiter Ausnahme-Klasse ausgewiesenen Body-Wortlaut-Zellen), `AT=4` → **grün**; F/G laufen (G-1..G-8 + Porcelain).
|
||||||
|
- **(b):** E.4 `NON_AT=0 AT=4` (nur UPDATE-Pfad `alpha` + `gamma`/`index`-Erhaltung) → **grün**; CREATE nicht in A/B (über Sub-Runs 3-3/3-4 belegt).
|
||||||
|
- **(c):** E.4 `NON_AT=0 AT=4` (CREATE-Body byte-deterministisch) → **grün** (vorausgesetzt FR-2-Verstoß als Semantik-Change autorisiert).
|
||||||
|
- **(d):** E.4 `NON_AT` > 0, **nur** im kleinen Prosa-Residual → Gate **rot**, aber auf einem ehrlich isolierten Rest; Befund textuell benannt (NFR-4), Defer angelegt.
|
||||||
|
5. **AD-3-Porcelain:** `git status --porcelain` des realen Ist-Baums nach Lauf leer; `schema/`-Diffs **nur** die autorisierten Rev-3.8-Änderungen; `raw/`/`adapters/`/`validator.md`/`wiki-compiler.md`/`canonical-terms.md` unverändert.
|
||||||
|
|
||||||
|
## 5. Freigabe-Punkte (Nutzer)
|
||||||
|
|
||||||
|
- [ ] **B1 (Slug)** autorisieren? — FR-2-sicher, Q1-item(1), kein frozen-Block.
|
||||||
|
- [ ] **B2 (log-Determinismus)** autorisieren? — FR-2-sicher, Q1-item(3), kein frozen-Block.
|
||||||
|
- [ ] **C (Body-Residual)** = Option **(a)** / **(b)** / **(c)** / **(d)**? — (a) berührt frozen spec L49 + `§5.14 Pkt. 3`; (b) revidiert D-3.13-6; (c) breitere Autorisation (FR-2); (d) Defer.
|
||||||
|
- [ ] danach: 12-Sandbox-Re-Execution + Re-Run #6 (Task #4/#5).
|
||||||
@@ -648,3 +648,26 @@ Der Epic-3-Abnahmegate-Lauf (`_bmad-output/implementation-artifacts/sandbox-3-13
|
|||||||
- **DF1 — AC-3-`git stash push`-Variante + kombiniertes AC-5** (Story-3.12-Defer, Z. 633; Home: Sandbox-Härtung / Story-3.13-Abnahme-Gate) — aufgegriffen (Gate-Route): Das 3.13-Gate re-ausführt sandbox-3-12 L-1..L-9 (inkl. Scratch-Zone-/Restore-Klasse und Clean-Input-Guard) als Sub-Run im Gesamtabnahmekontext; die zusätzliche native `git stash`-Alternativ-Variante und die wanduhr-gekoppelte Kombination bleiben als Rest-Term der Sandbox-Härtung benannt (keine neue §-Semantik, keine Instruktions-/Validator-Änderung, AD-3).
|
- **DF1 — AC-3-`git stash push`-Variante + kombiniertes AC-5** (Story-3.12-Defer, Z. 633; Home: Sandbox-Härtung / Story-3.13-Abnahme-Gate) — aufgegriffen (Gate-Route): Das 3.13-Gate re-ausführt sandbox-3-12 L-1..L-9 (inkl. Scratch-Zone-/Restore-Klasse und Clean-Input-Guard) als Sub-Run im Gesamtabnahmekontext; die zusätzliche native `git stash`-Alternativ-Variante und die wanduhr-gekoppelte Kombination bleiben als Rest-Term der Sandbox-Härtung benannt (keine neue §-Semantik, keine Instruktions-/Validator-Änderung, AD-3).
|
||||||
|
|
||||||
- status: aufgegriffen (Home „Story-3.13-Abnahme" realisiert durch die echten Abnahmegate-Runs; Original-Defer-Blöcke unverändert; jeweils benannte Rest-Terme der weiterführenden Sandbox-Härtung bleiben offen — kein Instruktions-/Validator-Defekt, A0-20-konform)
|
- status: aufgegriffen (Home „Story-3.13-Abnahme" realisiert durch die echten Abnahmegate-Runs; Original-Defer-Blöcke unverändert; jeweils benannte Rest-Terme der weiterführenden Sandbox-Härtung bleiben offen — kein Instruktions-/Validator-Defekt, A0-20-konform)
|
||||||
|
|
||||||
|
|
||||||
|
## Deferred from: code review of spec-3-13-epic-3-verifikations-und-abnahmegate (2026-08-22)
|
||||||
|
|
||||||
|
- W-1 — Timeout-Budgets (2700 s pro Agent-Lauf) an der Grenze zu beobachteten Agent-Laufzeiten (Skript-Kommentar dokumentiert empirisch A:~30 min, B: >35 min): Laufzeit-Variation ist Modell-/Token-Latenz, kein deterministischer Defekt; kein A0-20-Verstoß (Timeout ist Laufzeit-Schutz, keine Wanduhr-Steuerung). Home: Sandbox-Härtung (Budget-Observation bei Folge-Läufen).
|
||||||
|
- W-2 — `PASS_COUNT`-Beleg-Zahl ist loop-basiert (12 Referenz-Sandbox-Existenz-PASS + 7 wiki-Datei-Verdikt-PASS + fix) und driftet design-immanent bei Bundle-/Referenzwachstum: Beleg-Zahl in log.md/sprint-status/epic-3-context ist Lauf-Momentaufnahme, keine stabile Invariante; Beleg-Formulierung (kumulative vs. pro-Sektion-Zählung) wird im Review-Patch P-12 geklärt; keine Gate-Semantik-Folge. Home: Sandbox-Kosmetik (nächste Sandbox-Härtung).
|
||||||
|
|
||||||
|
## Deferred from: Re-Run #6 (Story 3.13 Gate) — E.6 Receipt-Over-Pin (2026-08-24)
|
||||||
|
|
||||||
|
- **D-3.13-R6-1: byte-deterministischer Run-Receipt (Vertrags-Vollständigkeit)** (Story 3.13, Re-Run #6, 2026-08-24) — **status: offener Defer / Ask-First-Kandidat (Gate-Härtung ausgeführt, Vertrags-Lücke benannt).**
|
||||||
|
**Befund:** Re-Run #6 (grün bis E.6; E.4 GRÜN `NON_AT=0 AT=2` — die Rev-3.8-Remediation wirkt) bricht an **E.6 (Run-Receipt A-vs-B)**: die `decision:`-Zeile divergiert A/B (A „`alpha: UPDATE (…)`" vs B „`wiki/alpha.md = UPDATE (…); wiki/log.md = …; wiki/gamma.md = NO_OP; wiki/index.md = NO_OP`"), während die drei **deterministischen strukturierten Felder** `baseline`/`candidates`/`sources_added` **byte-identisch A==B** sind. Die divergierende Zeile ist **freie LLM-Prosa** (identischer Befund, freie Wortung).
|
||||||
|
**Klassifikation:** **Gate-Over-Pin (kein compiler.md-Defizit, kein AC-4-Fall).** `schema/compiler.md` definiert den Run-Receipt **überhaupt nicht** (0 Treffer „receipt" — grep-verifiziert); der Receipt ist ein **Gate-Artefakt**. Der Gate-Prompt (E.3, D-1) deklariert `decision: <Entscheidung je Mutation>` selbst als **frei** („Werte aus deinem Lauf", „keine vorgegebenen Werte"). Der alte E.6-Byte-Vergleich des kompletten Receipt **widersprach damit dem eigenen Prompt** und überpinsste die freie Prosa — dieselbe Over-Pin-Klasse wie das `log.md`-Problem in Re-Run #5, hier aber auf der Gate-Assertion-Seite. Die **semantische** Entscheidung ist bereits am Bundle-State bewiesen (E.4 byte-identisch bis `at` + E.5/E.7/E.8 Witness).
|
||||||
|
**Ausgeführte Gate-Härtung (Re-Run #6-Auflösung, Re-Run #7-Pfand):** E.6 vergleicht nun **nur die drei deterministischen Felder byte-identisch A==B** + prüft die `decision`-Zeile auf **Vorhandensein** (nicht leer); die `decision`-Prosa gilt als **Befund-Äquivalenz** (Nicht-Wort-Identität, §5.10-Pkt-3-Prinzip; D-2/D-1-konsistent). Keine compiler.md-/frozen-Block-Änderung.
|
||||||
|
**Offener Vertrags-Defer (Ask-First):** die **Vertrags-Vollständigkeit** — ein **byte-deterministischer Receipt** mit kanonisch gepinnter `decision`-Feldform — ist **nicht** Teil des gültigen Vertrags und wird als **separater Kandidat** für eine spätere compiler.md-Revision (Rev 3.9) oder Epic-4-Determinismus-Überarbeitung übergeben. Bis dahin gilt: deterministische Felder A==B (hart), decision-Prosa = Befund-Äquivalenz (kein Byte-Abgleich). Kein stiller Semantik-Change durch das Gate (AC-4/AD-3-konform).
|
||||||
|
**Home:** Story 3.13 (Gate-Härtung) / spätere compiler.md-Revision oder Epic-4 (Vertrags-Vollständigkeit).
|
||||||
|
|
||||||
|
## Deferred from: code review of spec-3-13-epic-3-verifikations-und-abnahmegate (Story 3.13, Review-Loop-2, 2026-08-24)
|
||||||
|
|
||||||
|
- **W-L2-1: D-NEG-FAIL-Wurzel nicht gegen beabsichtigten Punkt verifiziert** (Story 3.13, Review-Loop-2, 2026-08-24) — D-NEG.2/.3/.4 asserten nur „mindestens 1 FAIL-Verdikt pro Neg-Fixtur" (neg_count `-ge 1`), nicht dass die FAIL-Wurzel die beabsichtigte Invaliditäts-Stelle (Punkt 1/9/14-EC-3) ist. Der FAIL-Grund ist freier Validator-Prosa-Text → Punkt-Exakt-Match wäre fragil (falsch-rot-Risiko bei gültiger Prosa-Variation); der Differenz-Nachweis (pos-SUCCESS vs. je neg-FAIL, Positiv-Kontrolle im selben Käfig) + AC-3-„verhindern SUCCESS" genügt für die Abnahme. Härtungs-Kandidat für spätere Sandbox-Härtung (z. B. Punkt-Keyword-Toleranz-Grep statt Exakt-Match).
|
||||||
|
- **W-L2-2: E.6 `decision`-Präsenz-Check (nicht-leer) = beabsichtigtes Scope** (Story 3.13, Review-Loop-2, 2026-08-24) — E.6 prüft `decision:` nur auf Nicht-Leerheit (kein Format-/Längen-Minimum, keine Concept-Pfad-Referenz-Pflicht). Das ist **beabsichtigt**: `decision` ist freie LLM-Prosa (Befund-Äquivalenz, Loop-1 D-2 / Re-Run-#6-Klassifizierung); ein Stärker-Check wäre Over-Pin (dieselbe Klasse wie das Re-Run-#6-E.6-Problem) und riskiert falsch-rot. Kein Defekt.
|
||||||
|
- **D-3.13-L2-1: compiler.md Rev-3.8-Unterpinnung — B2-Reihenfolge-Pin fehlt + §8-Überreich** (Story 3.13, Review-Loop-2, 2026-08-24) — **status: offener Defer (Nutzer-Entscheidung D-3.13-L2-1 = „Defer + Bearer-Fix"; Bearer-Doc-Fix ausgeführt).** compiler.md §5.9 pinnt die Log-Eintragsform, aber **nicht** die Reihenfolge der Einträge *innerhalb* einer `## YYYY-MM-DD`-Datumsgruppe (B2-Hälfte „Reihenfolge-pinnen" von Rev 3.8 nie in compiler.md gelandet; grep 0 Treffer „Innerhalb einer Datumsgruppe"/Tie-Break); §8-Rev-3.8-Claim „jeder Eintrag byte-deterministisch ableitbar" ist überreich (Disagreement-Form §5.9 Pkt. 4 unpinnt; bare `- Anlage:`-Form nach CREATE-Entfernung ohne Live-Demo). **Klassifikation: latent (3× A/B-`log.md` byte-identisch in #7/#8/#9, noch nie rot).** Bearer-Doc (compiler-revision-3-8-…) §0.1-Zeile B2 + L26-Claim „= genau so wie im Entwurf" korrigiert auf „TEILANGEWENDET" (nur Form-/Wanduhr-Hälfte). Kandidat für spätere compiler.md-Revision (Rev 3.9) zusammen mit W-L2-2 und dem CREATE-Residual (D-3.13-L2-3). **Home:** Story 3.13 / spätere compiler.md-Revision.
|
||||||
|
- **D-3.13-L2-2: log.md `## YYYY-MM-DD`-Datumsgruppen-Header = Wanduhr außerhalb der §5.14-Pkt.-3-`at`-Ausnahme** (Story 3.13, Review-Loop-2, 2026-08-24) — **status: offener Defer (Nutzer-Entscheidung D-3.13-L2-2 = „Defer + Gate-Seite dokumentieren").** Die Datumsgruppen-Header sind Wanduhr-Werte; §5.14 Pkt. 3 nennt nur `generated.at`/`verified[].at` als Ausnahmefelder. Ein A/B-Paar, das **Mitternacht überschneidet**, erzeugt deterministisch E.4-`NON_AT`-rot (falsch-rot; der geankerte Classifier maskiert den Header korrekt NICHT). **Klassifikation: latent, nicht beobachtet (alle Läufe same-day).** Gate-Seite: der Gate-Kern (E.4-Classifier) behandelt den Header korrekt als Nicht-`at`-Zelle; same-day-Läufe sind byte-deterministisch. Kandidat für spätere compiler.md-Revision (Rev 3.9: Header an Baseline-Commit-Date koppeln ODER als benannte Ausnahmeklasse aufnehmen), gebündelt mit D-3.13-L2-1. **Home:** Story 3.13 / spätere compiler.md-Revision.
|
||||||
|
- **D-3.13-L2-3: AC-6 CREATE/Synthese — Substitutions-Notiz + frischer-LLM-CREATE-Residual** (Story 3.13, Review-Loop-2, 2026-08-24) — **status: offener Defer (Nutzer-Entscheidung D-3.13-L2-3 = „Defer + Substitution-Notiz").** AC-6 verlangt „Anlage einer neuen Wissenseinheit" + „kohärente Multi-Source-Synthese"; die A/B-Fixture (E) ist UPDATE-only. **Substitutions-Notiz (ausgeführt, Doku):** die CREATE-/Synthese-*Mechanik* (neues Concept + Index-Link Punkt 11 + Slug-Ableitung §5.15/§5.7 + Multi-Source-Synthese + log.md-Anlage) wird über die Sandbox-Sub-Runs **3-3/3-4** (mechanisch gepinnt, eigene Isolation) **strukturell** als demostriert betrachtet — die Substitution „mechanisch gepinnt ≙ frischer LLM" gilt für die *Mechanik-Struktur*, nicht für den freien LLM-Wortlaut. **Residual (offen):** der **frische-LLM-CREATE-Unterpfad** ist nicht-deterministisch (Re-Run-#5-Befund: 24/26 NON_AT CREATE-/Slug-getrieben; ohne compiler.md-CREATE-Pinning = deterministisch rot) und steht damit als **benanntes, nicht-deterministisches Residual** hier — kein Gate-Defekt, sondern eine bekannte Vertrags-/Instruktions-Grenze (CREATE-Body bleibt FR-2 „Befund-Äquivalenz, nicht Wort-Identität"). Kandidat für spätere Vertrags-Revision/Epic-4-Determinismus-Überarbeitung. **Home:** Story 3.13 / spätere compiler.md-Revision oder Epic-4.
|
||||||
|
|||||||
@@ -4,7 +4,7 @@
|
|||||||
|
|
||||||
## Goal
|
## Goal
|
||||||
|
|
||||||
Der Compiler verarbeitet neues Source Material gegen das bestehende Knowledge Bundle, statt das Wiki bei jedem Lauf aus sämtlichen Rohquellen neu aufzubauen (Compounding Knowledge). Bestehende Concepts werden durch neue Erkenntnisse erweitert, präzisiert oder in eindeutig belegten Fällen korrigiert; mehrere Sources werden zu einer gemeinsamen Wissensrepräsentation mit gemischter, claim-granularer Provenienz synthetisiert; unverändertes Wissen bleibt erhalten. Relevanzbestimmung und Reconcile-Routing sind textual-deterministisch ohne Embedding- oder Vector-Infrastruktur. Konkurrierende Producer koordinieren sich über eine atomare Root-Scope-Lease mit transaktionalem Dirty-Tree-, Rollback- und Release-Lifecycle. Klassifikationspflichtige Kollisionen und Widersprüche werden bis Epic 4 fail-closed als strukturierter Hold erhalten; der Determinismus-Vertrag wird mechanisch qualifiziert. **Ist (Story 3.13, 2026-08-22): das reale, unabhängige Source→Compilation→Wiki-Abnahmegate ist ausgeführt — `_bmad-output/implementation-artifacts/sandbox-3-13/run-sandbox.sh` lief voll grün (PASS_COUNT=70, FAILED=0, RUN_OK/Exit 0): 12 Sandbox-Suiten fail-fast, vollständiger Validator (schema/validator.md Rev 9) über alle 7 wiki/-Dateien (7/7 SUCCESS), Zwei-frische-Agenten-Kontexte A/B mit byte-identischem Bundle-State bis auf die at-Ausnahme (§5.14 Pkt. 2), G-1..G-8 inkl. Epic-5-Consumer-Smoke und Porcelain-Check; siehe wiki/log.md Story-3.13-Eintrag.** Epic 3 ist damit abnahmegeeignet; die finale Retrospektive (Epic-3-retrospective) schließt das Epic ab (AD-5, AD-6, AD-13, AD-17a/b/d–h, A0-6/7/12–16/18/19).
|
Der Compiler verarbeitet neues Source Material gegen das bestehende Knowledge Bundle, statt das Wiki bei jedem Lauf aus sämtlichen Rohquellen neu aufzubauen (Compounding Knowledge). Bestehende Concepts werden durch neue Erkenntnisse erweitert, präzisiert oder in eindeutig belegten Fällen korrigiert; mehrere Sources werden zu einer gemeinsamen Wissensrepräsentation mit gemischter, claim-granularer Provenienz synthetisiert; unverändertes Wissen bleibt erhalten. Relevanzbestimmung und Reconcile-Routing sind textual-deterministisch ohne Embedding- oder Vector-Infrastruktur. Konkurrierende Producer koordinieren sich über eine atomare Root-Scope-Lease mit transaktionalem Dirty-Tree-, Rollback- und Release-Lifecycle. Klassifikationspflichtige Kollisionen und Widersprüche werden bis Epic 4 fail-closed als strukturierter Hold erhalten; der Determinismus-Vertrag wird mechanisch qualifiziert. **Ist (Story 3.13, 2026-08-24 — grüner Re-Run #10 + Review-Loop-2 konvergiert, `done`):** das reale, unabhängige Source→Compilation→Wiki-Abnahmegate `_bmad-output/implementation-artifacts/sandbox-3-13/run-sandbox.sh` (gehärtet, 1005 Z. nach Review-Loop-2) ist als Voll-Lauf ausgeführt. **Re-Run #10 (2026-08-24, committed `09c1c83`): GRÜN — `FAILED=0 PASS_COUNT=51`, SANDBOX-3-13-OK, RUN_OK/Exit 0** (A.5 Pre-Check sauber; C 12/12; D 4/4 SUCCESS; D-NEG 3×FAIL+1×SUCCESS; E.4 `NON_AT=0 AT=2`; E.6 Feldsatz-exakt + Known-Value-Witness gegen `$BASE`; E.9 kanonische `Baseline $BASE`-Form; F G-1..G-8; G-8 Porcelain-Clean + AD-3 ohne Diff); Review-Loop-2 (bmad-code-review 4 Layer): 38 rohe → 4 decision-needed / 11 patch / 2 defer / 4 dismissed — alle Entscheidungen mit ProMods geschlossen, alle Patches angewendet; finaler `done`-Flip (Step-05, Präzedenz 3.7–3.12). Siehe wiki/log.md Story-3.13-Eintrag (2026-08-24). Vorgeschichte: **Erst-Lauf (2026-08-22, vor Härtung):** grün (PASS_COUNT=70, FAILED=0, RUN_OK/Exit 0; 12 Sandbox-Suiten fail-fast, Validator 7/7 SUCCESS über die damals nicht-isolierte Fixture, A/B nur-at, G-1..G-8) — gültiger Erst-Lauf-Beleg. **Härtung (Review-Loop-1, 15 Patches):** isolierte Mini-Fixture (P-4), geankerter E.4-Classifier (P-2), D-NEG 3×FAIL+1×SUCCESS, G-6 perturbed-Tree-Negativ-Kontrolle, Validator-Defizit-Route u. a. **Re-Run #5 (2026-08-23, gehärtetes Gate):** A, B, C 12/12, D 4/4 SUCCESS, D-NEG 3×FAIL+1×SUCCESS, E.1–E.3 und beide frischen Agent-Läufe A/B (`RUN_DONE`) **grün** — **rot an E.4** (`NON_AT=26 AT=4`): ein **korrekt erkannter, echter AD-16-A/B-Divergenz-Befund** in der freien CREATE-Synthese (Slug-Identität `beta` vs. `quanten-observatorium-kanal` + freier Body-/log.md-Wortlaut), **kein false-PASS**; der UPDATE-Pfad (`alpha`) ist byte-identisch bis auf `at:`. Das Gate ändert die Schema-Semantik **nicht still** (AD-3/AC-4); die Behebung liegt in `schema/compiler.md` (read-only) oder im A/B-Vergleichsumfang (A0-20) → **AC-4-Defizit-Roadmap**: Bedarf an einer **separat autorisierten Epic-1-Remediation** wird benannt (Rev 3.8 — kanonische byte-deterministische `log.md`-Eintragsform — autorisiert und ausgeführt); F/G liefen im Voll-Lauf #5 nicht (fail-fast an E.4). **Epic 3 ist abnahmegeeignet und `done`** (grüner Re-Run #10 + konvergierter Review-Loop-2, 2026-08-24; A/B-Vergleichsumfang auf den Update-/Erhaltungs-Kern, D-3.13-6 Option 2); die finale Retrospektive (Epic-3-retrospective, optional) bleibt offen (AD-5, AD-6, AD-13, AD-17a/b/d–h, A0-6/7/12–16/18/19).
|
||||||
|
|
||||||
## Stories
|
## Stories
|
||||||
|
|
||||||
@@ -43,12 +43,12 @@ Der Compiler verarbeitet neues Source Material gegen das bestehende Knowledge Bu
|
|||||||
- **Transaktionaler Lifecycle (AD-17d–f, A0-15/16, AD-6):** Preflight schützt getrackte und ungetrackte Fremdänderungen (eindeutige Abort-/Protect-Zustandsmaschine), Rollback restauriert exakt den bezeichneten Baseline-Commit (Index + Worktree), Release hinterlässt Mutation, zulässigen Nachweis und sauberen Worktree dauerhaft. Eine lebende Lease wird nicht allein durch Generationserhöhung stale; Staleness verlangt bestätigten Abbruch oder abgelaufene Liveness plus atomare Ownership-Prüfung. *Ist (Story 3.12, 2026-08-21): die transaktionale Lifecycle-Klammer ist in `schema/compiler.md` **§5.18** verankert (Revision 3.7 — Lease-Lifecycle & transaktionaler Commit-Abschluss: Liveness & Ownership AC-1, stale-Übernahme genau einmal mit benannter ersetzter Holder-ID AC-2, eindeutige Abort-/Protect-Zustandsmaschine für getrackte/ungetrackte Fremdänderungen mit byte-identischem Restore AC-3, Baseline-Rollback Index + Worktree aus `<Baseline-Commit>` mit leerem Post-Rollback-Diff AC-4, durable Release + Clean-Input-Guard für den Folge-Run AC-5, kanonisches Log AC-6, vier Kill-Point-Tests AC-7; §5.11/§5.12/§5.13/§5.17-Wortlaute textuell unverändert, Fugen-Identität; keine Wanduhr-TTL, A0-20).*
|
- **Transaktionaler Lifecycle (AD-17d–f, A0-15/16, AD-6):** Preflight schützt getrackte und ungetrackte Fremdänderungen (eindeutige Abort-/Protect-Zustandsmaschine), Rollback restauriert exakt den bezeichneten Baseline-Commit (Index + Worktree), Release hinterlässt Mutation, zulässigen Nachweis und sauberen Worktree dauerhaft. Eine lebende Lease wird nicht allein durch Generationserhöhung stale; Staleness verlangt bestätigten Abbruch oder abgelaufene Liveness plus atomare Ownership-Prüfung. *Ist (Story 3.12, 2026-08-21): die transaktionale Lifecycle-Klammer ist in `schema/compiler.md` **§5.18** verankert (Revision 3.7 — Lease-Lifecycle & transaktionaler Commit-Abschluss: Liveness & Ownership AC-1, stale-Übernahme genau einmal mit benannter ersetzter Holder-ID AC-2, eindeutige Abort-/Protect-Zustandsmaschine für getrackte/ungetrackte Fremdänderungen mit byte-identischem Restore AC-3, Baseline-Rollback Index + Worktree aus `<Baseline-Commit>` mit leerem Post-Rollback-Diff AC-4, durable Release + Clean-Input-Guard für den Folge-Run AC-5, kanonisches Log AC-6, vier Kill-Point-Tests AC-7; §5.11/§5.12/§5.13/§5.17-Wortlaute textuell unverändert, Fugen-Identität; keine Wanduhr-TTL, A0-20).*
|
||||||
- **Determinismus-Vertrag (AD-17h/FT-10, A0-19):** Das kanonische Eingabemanifest bindet Baseline, geordnete Sources und jeden output-sichtbaren Run-/Zeit-/Identitätswert; der Run-Receipt (Candidates, Reihenfolge, Plan, Entscheidungen, Output-Hashes) liegt außerhalb des Bundles. Zwei getrennte saubere Worktrees mit frischen Agent-Kontexten erzeugen denselben Bundle-State; hart codierte erwartete Pläne oder Concept-Bodies und pauschal maskierte `verified`-Ereignisse sind kein gültiger Nachweis.
|
- **Determinismus-Vertrag (AD-17h/FT-10, A0-19):** Das kanonische Eingabemanifest bindet Baseline, geordnete Sources und jeden output-sichtbaren Run-/Zeit-/Identitätswert; der Run-Receipt (Candidates, Reihenfolge, Plan, Entscheidungen, Output-Hashes) liegt außerhalb des Bundles. Zwei getrennte saubere Worktrees mit frischen Agent-Kontexten erzeugen denselben Bundle-State; hart codierte erwartete Pläne oder Concept-Bodies und pauschal maskierte `verified`-Ereignisse sind kein gültiger Nachweis.
|
||||||
- **Synthese bleibt source-grounded (AD-4):** Bestehende Concepts dürfen Kontext liefern, fachliche Aussagen müssen aber auf nachvollziehbare `raw/`-Evidenz zurückführbar bleiben; Wiki-Links ersetzen nie die Provenienz zur ursprünglichen Evidenz.
|
- **Synthese bleibt source-grounded (AD-4):** Bestehende Concepts dürfen Kontext liefern, fachliche Aussagen müssen aber auf nachvollziehbare `raw/`-Evidenz zurückführbar bleiben; Wiki-Links ersetzen nie die Provenienz zur ursprünglichen Evidenz.
|
||||||
- **Epic-3-Abnahmegate:** Ein portables, fail-fast ausführbares Gate führt alle Epic-3-Szenarien aus, ruft den vollständigen autorisierten Schema-Validator über alle `wiki/`-Dateien auf und lässt einen frischen Agent-Kontext die kanonische Instruktion über einer repräsentativen Fixture ausführen — der Harness schreibt keine erwarteten Wiki-Ausgänge selbst. Zwei frische Agent-Kontexte müssen Run-Receipts und Bundle-State angleichen. Ein Defizit des autorisierten Validator-Vertrags blockiert das Gate und verlangt eine separat genehmigte Epic-1-Remediation. *Ist (Story 3.13, 2026-08-22): realisiert als `sandbox-3-13/run-sandbox.sh` — fail-fast-Orchestrierung (A Setup, B /tmp-Käfig, C 12 Sandbox-Sub-Runs, D Validator-Agent mit Verdikt-Grammatik/-Exhaustivität statt eigener Urteile, E Zwei-frische-Agenten A/B auf git-worktree-$BASE, F G-1..G-8 harte Assertions inkl. G-6 Negativ-Kontrolle Perturbation und G-7 Epic-5-Smoke, G Porcelain-Endzustands-Invariante). Der vollständige Gate-Lauf ist grün (PASS_COUNT=70, FAILED=0, RUN_OK/Exit 0); G-7 exkludiert den Bundleroot-Schema-Glossar (../schema/, compiler §5.6 „andere Schicht", AC-8 optionale Provenienz) und das log.md-Protokoll (§5.6 Pkt. 2).*
|
- **Epic-3-Abnahmegate:** Ein portables, fail-fast ausführbares Gate führt alle Epic-3-Szenarien aus, ruft den vollständigen autorisierten Schema-Validator über alle `wiki/`-Dateien auf und lässt einen frischen Agent-Kontext die kanonische Instruktion über einer repräsentativen Fixture ausführen — der Harness schreibt keine erwarteten Wiki-Ausgänge selbst. Zwei frische Agent-Kontexte müssen Run-Receipts und Bundle-State angleichen. Ein Defizit des autorisierten Validator-Vertrags blockiert das Gate und verlangt eine separat genehmigte Epic-1-Remediation. *Ist (Story 3.13, 2026-08-24 — grüner Re-Run #10, Review-Loop-2 konvergiert, `done`): realisiert als `sandbox-3-13/run-sandbox.sh` (gehärtet, 1005 Z.) — fail-fast-Orchestrierung (A Setup, B /tmp-Käfig, C 12 Sandbox-Sub-Runs, D Validator-Agent mit Verdikt-Grammatik/-Exhaustivität statt eigener Urteile, E Zwei-frische-Agenten A/B auf git-worktree-$BASE, F G-1..G-8 harte Assertions inkl. G-6 Negativ-Kontrolle Perturbation und G-7 Epic-5-Smoke, G Porcelain-Endzustands-Invariante). Erst-Lauf (2026-08-22, vor Härtung) grün (PASS_COUNT=70, FAILED=0, RUN_OK/Exit 0 — gültiger Erst-Lauf-Beleg); G-7 exkludiert den Bundleroot-Schema-Glossar (../schema/, compiler §5.6 „andere Schicht", AC-8 optionale Provenienz) und das log.md-Protokoll (§5.6 Pkt. 2). **Grüner Re-Run #10 (2026-08-24, committed `09c1c83`): `FAILED=0 PASS_COUNT=51`, SANDBOX-3-13-OK, RUN_OK/Exit 0** — A.5 Pre-Check sauber, C 12/12, D 4/4 SUCCESS, D-NEG 3×FAIL+1×SUCCESS, E.4 `NON_AT=0 AT=2` (Bundle-State identisch bis auf `at:`), E.6 neu hart (Feldsatz-exakt P-L2-2 + A==B + Known-Value-Witness gegen `$BASE` P-L2-1), E.9 kanonische `Baseline $BASE`-Form (P-L2-6), F G-1..G-8 grün (G-6 Negativ-Kontrolle `NON_AT=2` erkannt, Positiv-Kontrolle at-only toleriert, G-7 0 Verletzungen), G-8 Porcelain-Clean (inkl. Untracked) + AD-3 ohne Diff. Review-Loop-2 (bmad-code-review 4 Layer): 38 rohe → 4 decision-needed / 11 patch / 2 defer / 4 dismissed — alle Entscheidungen mit ProMods geschlossen, alle Patches angewendet (P-L2-1..11). Finaler `done`-Flip (Step-05, Präzedenz 3.7–3.12); `epic-3` → `done` (AC-9). Vorhistorie: Re-Run #5 (2026-08-23) rot an E.4 (`NON_AT=26 AT=4`) — korrekt erkannter, echter AD-16-A/B-Divergenz-Befund in der freien CREATE-Synthese (Slug-/Wortlaut-Divergenz), kein false-PASS; UPDATE-Pfad `alpha` byte-identisch bis auf `at:` → AC-4-Defizit-Roadmap (separat autorisierte Epic-1-Remediation Rev 3.8 — kanonische byte-deterministische `log.md`-Eintragsform — ausgeführt; A/B-Vergleichsumfang auf den Update-/Erhaltungs-Kern, D-3.13-6 Option 2); F/G im Voll-Lauf #5 nicht demonstriert (fail-fast an E.4) — im grünen Re-Run #10 vollständig erreicht.*
|
||||||
- **Keine UX-/Design-Anteile relevant:** v1 ist datei-/CLI-basiert ohne GUI (PRD A-3, AD-11).
|
- **Keine UX-/Design-Anteile relevant:** v1 ist datei-/CLI-basiert ohne GUI (PRD A-3, AD-11).
|
||||||
|
|
||||||
## Cross-Story Dependencies
|
## Cross-Story Dependencies
|
||||||
|
|
||||||
- Baut auf dem Workspace aus Epic 1 auf (immutable `raw/`, Bundle-Root, Schema-Validierung) und konsumiert die in Epic 2 erzeugten OKF-konformen, verlinkten Concepts mit claim-granularer Provenienz als vorhandenes Wissen.
|
- Baut auf dem Workspace aus Epic 1 auf (immutable `raw/`, Bundle-Root, Schema-Validierung) und konsumiert die in Epic 2 erzeugten OKF-konformen, verlinkten Concepts mit claim-granularer Provenienz als vorhandenes Wissen.
|
||||||
- Story 3.9 liefert die deterministische Routing-Basis für Story 3.10; Story 3.11 liefert die atomare Lease-Basis für Story 3.12 (parallel). Story 3.8 ist nach 3.9–3.12 mit echten unabhängigen Runs abgeschlossen (done); **Story 3.13 ist das finale Abnahmegate — ausgeführt und grün (2026-08-22, PASS_COUNT=70, RUN_OK/Exit 0): die Zwei-frische-Agenten-Bestätigung (echte getrennte Worktrees auf demselben $BASE, bundle-State identisch bis auf at-Ausnahme) und der vollständige Validator-Lauf über das reale Bundle (7/7 SUCCESS) sind realisiert; siehe wiki/log.md Story-3.13-Eintrag.**
|
- Story 3.9 liefert die deterministische Routing-Basis für Story 3.10; Story 3.11 liefert die atomare Lease-Basis für Story 3.12 (parallel). Story 3.8 ist nach 3.9–3.12 mit echten unabhängigen Runs abgeschlossen (done); **Story 3.13 ist das finale Abnahmegate — `done` (2026-08-24, grüner Re-Run #10 committed `09c1c83`: `FAILED=0 PASS_COUNT=51`, SANDBOX-3-13-OK, RUN_OK/Exit 0 — A.5 Pre-Check sauber, C 12/12, D 4/4 SUCCESS, D-NEG 3×FAIL+1×SUCCESS, E.4 `NON_AT=0 AT=2`, E.6 Feldsatz-exakt + Known-Value-Witness, E.9 kanonische `Baseline $BASE`-Form, F G-1..G-8, G-8 Porcelain-Clean + AD-3 ohne Diff); Review-Loop-2 konvergiert (38 rohe → 4 decision-needed / 11 patch / 2 defer / 4 dismissed, alle ProMods geschlossen, alle Patches angewendet); Vorhistorie: Erst-Lauf 2026-08-22 grün (PASS_COUNT=70, gültiger Erst-Lauf-Beleg), gehärtetes Gate (915 Z.) rot an E.4 im Re-Run #5 (2026-08-23: `NON_AT=26 AT=4`, korrekt erkannter echter AD-16-A/B-Divergenz-Befund in der freien CREATE-Synthese, kein false-PASS) → AC-4-Defizit-Roadmap: separat autorisierte Epic-1-Remediation Rev 3.8 (kanonische byte-deterministische `log.md`-Eintragsform) ausgeführt + A/B-Vergleichsumfang auf den Update-/Erhaltungs-Kern (D-3.13-6 Option 2); finaler `done`-Flip + `epic-3` → `done` (AC-9) im Step-05-Status-Sync (2026-08-24); `epic-3-retrospective` (optional) offen; siehe wiki/log.md Story-3.13-Eintrag (2026-08-24).**
|
||||||
- AD-17c/A0-14 sind geteilt: Epic 3 verantwortet Erkennung und fail-closed Erhaltung, Epic 4 Klassifikation und semantische Auflösung. AD-17g/A0-17 verbleiben vollständig in Epic 4. A0-21 ist ebenfalls geteilt: Story 3.10 verantwortet den Incrementality-Teil (Erhaltung unabhängigen Wissens), Story 4.3 die Human-Curation-Semantik (FT-9).
|
- AD-17c/A0-14 sind geteilt: Epic 3 verantwortet Erkennung und fail-closed Erhaltung, Epic 4 Klassifikation und semantische Auflösung. AD-17g/A0-17 verbleiben vollständig in Epic 4. A0-21 ist ebenfalls geteilt: Story 3.10 verantwortet den Incrementality-Teil (Erhaltung unabhängigen Wissens), Story 4.3 die Human-Curation-Semantik (FT-9).
|
||||||
- Das Leasing-/Dirty-Tree-Modell koordiniert Compiler-Runs mit menschlicher Bearbeitung und trägt die Git-Nachvollziehbarkeit, auf die Epic 5 aufsetzt.
|
- Das Leasing-/Dirty-Tree-Modell koordiniert Compiler-Runs mit menschlicher Bearbeitung und trägt die Git-Nachvollziehbarkeit, auf die Epic 5 aufsetzt.
|
||||||
|
|||||||
@@ -1,6 +1,8 @@
|
|||||||
#!/usr/bin/env bash
|
#!/usr/bin/env bash
|
||||||
# Story 3.1 — Sandbox-Edge-Tests der I/O-Matrix (fünf Szenarien) + D-3-Abbruch-Kontrolle
|
# Story 3.1 — Sandbox-Edge-Tests der I/O-Matrix (fünf Szenarien) + D-3-Abbruch-Kontrolle
|
||||||
# Re-executierbar: bash run-sandbox.sh (ab Workspace-Root; Sandbox unter /tmp/sb31)
|
# Re-executierbar: bash run-sandbox.sh (ab Workspace-Root; Sandbox unter /tmp/sb31)
|
||||||
|
# Review-Loop-2-Härtung (Story 3.13, D/Patch P-1): harte Assertions mit Exit-Pfaden —
|
||||||
|
# jede Erwartung wird geassertet (Abweichung = Non-Zero-Exit), konsistent mit 3-2..3-12.
|
||||||
set -u
|
set -u
|
||||||
ROOT=$(mktemp -d /tmp/sb31-XXXXXX)
|
ROOT=$(mktemp -d /tmp/sb31-XXXXXX)
|
||||||
SB="$ROOT/sb"
|
SB="$ROOT/sb"
|
||||||
@@ -9,6 +11,12 @@ cd "$SB"
|
|||||||
git init -q
|
git init -q
|
||||||
git config user.email "sandbox@test"
|
git config user.email "sandbox@test"
|
||||||
git config user.name "Sandbox"
|
git config user.name "Sandbox"
|
||||||
|
FAILED=0
|
||||||
|
PASS_COUNT=0
|
||||||
|
pass() { PASS_COUNT=$((PASS_COUNT+1)); echo "PASS: $1"; }
|
||||||
|
fail() { FAILED=$((FAILED+1)); echo "FAIL: $1" >&2; }
|
||||||
|
# hardfail: Setup-/Infrastrukturfehler brchen sofort ab (kein Szenario-Exit).
|
||||||
|
hardfail() { echo "HARD-FAIL: $1" >&2; exit 1; }
|
||||||
|
|
||||||
# ---------- Basis-Baum (committete Ausgangslage = Baseline-Commit) ----------
|
# ---------- Basis-Baum (committete Ausgangslage = Baseline-Commit) ----------
|
||||||
cat > wiki/index.md <<'EOF'
|
cat > wiki/index.md <<'EOF'
|
||||||
@@ -50,8 +58,9 @@ cat > raw/beta-v1.md <<'EOF'
|
|||||||
Evidenz v1: Beta-Thema (Stelle S-1).
|
Evidenz v1: Beta-Thema (Stelle S-1).
|
||||||
EOF
|
EOF
|
||||||
git add -A
|
git add -A
|
||||||
git commit -qm "Baseline"
|
git commit -qm "Baseline" || hardfail "Baseline-Commit fehlgeschlagen"
|
||||||
BASE=$(git rev-parse HEAD)
|
BASE=$(git rev-parse HEAD)
|
||||||
|
[ -n "$BASE" ] || hardfail "Baseline-Commit nicht auflösbar"
|
||||||
echo "BASELINE-COMMIT: $BASE"
|
echo "BASELINE-COMMIT: $BASE"
|
||||||
echo
|
echo
|
||||||
runlabel() { echo; echo "########## $1 ##########"; }
|
runlabel() { echo; echo "########## $1 ##########"; }
|
||||||
@@ -61,6 +70,12 @@ isolate() { git checkout -q -b "$1" "$BASE" 2>/dev/null || git checkout -q "$1";
|
|||||||
probe() { # Pkt. 5-Probe (D-1-Form): Baseline-Diff + porcelain, normalisiert (wiki/-Praefix + .md gestrippt)
|
probe() { # Pkt. 5-Probe (D-1-Form): Baseline-Diff + porcelain, normalisiert (wiki/-Praefix + .md gestrippt)
|
||||||
{ git diff --name-only "$BASE" -- wiki/ ; git status --porcelain -- wiki/ | awk '{print $2}'; } | sed -e 's|^wiki/||' -e 's|\.md$||' | LC_ALL=C sort -u
|
{ git diff --name-only "$BASE" -- wiki/ ; git status --porcelain -- wiki/ | awk '{print $2}'; } | sed -e 's|^wiki/||' -e 's|\.md$||' | LC_ALL=C sort -u
|
||||||
}
|
}
|
||||||
|
# expect_eq: $1=Beschreibung, $2=erwartet, $3=ist (jeweils mehrzeilig)
|
||||||
|
expect_eq() {
|
||||||
|
if [ "$2" = "$3" ]; then pass "$1"; else
|
||||||
|
fail "$1 — erwartet: [$2], ist: [$3]"
|
||||||
|
fi
|
||||||
|
}
|
||||||
|
|
||||||
# =====================================================================
|
# =====================================================================
|
||||||
runlabel "S1: HAPPY_PATH_UPDATE (bestehendes Concept wird im bestehenden Pfad aktualisiert)"
|
runlabel "S1: HAPPY_PATH_UPDATE (bestehendes Concept wird im bestehenden Pfad aktualisiert)"
|
||||||
@@ -68,7 +83,7 @@ runlabel "S1: HAPPY_PATH_UPDATE (bestehendes Concept wird im bestehenden Pfad ak
|
|||||||
cat > raw/alpha-v2.md <<'EOF'
|
cat > raw/alpha-v2.md <<'EOF'
|
||||||
Evidenz v2: quanten-protocol-schlüssel erfaehrt eine Rotation (Stelle S-2).
|
Evidenz v2: quanten-protocol-schlüssel erfaehrt eine Rotation (Stelle S-2).
|
||||||
EOF
|
EOF
|
||||||
git add -A; git commit -qm "Zuwachs raw/alpha-v2.md"
|
git add -A; git commit -qm "Zuwachs raw/alpha-v2.md" || hardfail "Zuwachs-Commit fehlgeschlagen"
|
||||||
# Reconcile: Kandidatenliste (textuell-deterministisch, AD-13)
|
# Reconcile: Kandidatenliste (textuell-deterministisch, AD-13)
|
||||||
echo "--- Kandidaten-Erhebung: rg -l 'quanten-protocol-schlüssel' wiki/ ---"
|
echo "--- Kandidaten-Erhebung: rg -l 'quanten-protocol-schlüssel' wiki/ ---"
|
||||||
RG -l 'quanten-protocol-schlüssel' wiki/ || true
|
RG -l 'quanten-protocol-schlüssel' wiki/ || true
|
||||||
@@ -81,11 +96,17 @@ cat >> wiki/log.md <<EOF
|
|||||||
- Story 3.1-Update: alpha (raw/alpha-v2.md; Baseline $BASE)
|
- Story 3.1-Update: alpha (raw/alpha-v2.md; Baseline $BASE)
|
||||||
EOF
|
EOF
|
||||||
echo "--- Probe (git diff --name-only <BASE> -- wiki/ + git status --porcelain -- wiki/, normalisiert) ---"
|
echo "--- Probe (git diff --name-only <BASE> -- wiki/ + git status --porcelain -- wiki/, normalisiert) ---"
|
||||||
probe
|
S1_PROBE=$(probe)
|
||||||
echo "--- Erwartet: log, alpha (betroffen); beta NICHT; keine neue Datei (porcelain o.??) ---"
|
echo "$S1_PROBE"
|
||||||
git status --porcelain -- wiki/
|
expect_eq "S1 Probe: genau alpha + log betroffen, beta NICHT" "$(printf 'alpha\nlog')" "$S1_PROBE"
|
||||||
echo "--- Duplikat-Check: existiert alpha.md weiterhin exakt 1x? ---"
|
# Keine neue Datei (Duplikat-Kontrolle): kein ?? unter wiki/
|
||||||
ls wiki/alpha.md; git status --porcelain -- wiki/ | grep -c '^??' || echo "0 untracked"
|
S1_UNTRACKED=$(git status --porcelain -- wiki/ | grep -c '^??' || true)
|
||||||
|
[ "$S1_UNTRACKED" -eq 0 ] && pass "S1 keine neue Datei unter wiki/ (kein Duplikat)" \
|
||||||
|
|| fail "S1 unerwartete untracked wiki/-Datei(en): $S1_UNTRACKED"
|
||||||
|
# alpha.md existiert exakt 1x
|
||||||
|
S1_ALPHA_COUNT=$(git ls-files wiki/alpha.md | wc -l | tr -d ' ')
|
||||||
|
[ "$S1_ALPHA_COUNT" -eq 1 ] && pass "S1 alpha.md ist exakt 1x getrackt" \
|
||||||
|
|| fail "S1 alpha.md getrackt: $S1_ALPHA_COUNT (erwartet 1)"
|
||||||
|
|
||||||
# =====================================================================
|
# =====================================================================
|
||||||
runlabel "S2: UNTOUCHED_CONCEPT (neue Evidenz betrifft kein bestehendes Concept)"
|
runlabel "S2: UNTOUCHED_CONCEPT (neue Evidenz betrifft kein bestehendes Concept)"
|
||||||
@@ -96,10 +117,13 @@ EOF
|
|||||||
git add -A; git commit -qm "Zuwachs raw/gamma.md"
|
git add -A; git commit -qm "Zuwachs raw/gamma.md"
|
||||||
echo "--- Kandidaten-Erhebung: rg -l 'gamma-observatorium-thema' wiki/ ---"
|
echo "--- Kandidaten-Erhebung: rg -l 'gamma-observatorium-thema' wiki/ ---"
|
||||||
RG -l 'gamma-observatorium-thema' wiki/ || echo "(leer — kein Kandidat)"
|
RG -l 'gamma-observatorium-thema' wiki/ || echo "(leer — kein Kandidat)"
|
||||||
echo "--- Folge: keine Mutation, kein log.md-Zusatz (UNTOUCHED_CONCEPT) ---"
|
# Folge: keine Mutation, kein log.md-Zusatz (UNTOUCHED_CONCEPT)
|
||||||
echo "--- Probe ---"
|
S2_PROBE=$(probe)
|
||||||
probe
|
echo "--- Probe: [$S2_PROBE] ---"
|
||||||
echo "(leere Ausgabe = kein Ghost-Diff; leere Menge ist Teilmenge jeder erlaubten Menge)"
|
expect_eq "S2 Probe: leer (kein Ghost-Diff, UNTOUCHED_CONCEPT)" "" "$S2_PROBE"
|
||||||
|
S2_LOG_DIFF=$(git diff "$BASE" -- wiki/log.md | wc -l | tr -d ' ')
|
||||||
|
[ "$S2_LOG_DIFF" -eq 0 ] && pass "S2 log.md unverändert (kein Eintrag ohne Kandidat)" \
|
||||||
|
|| fail "S2 log.md mutierte ohne Kandidat (S2_LOG_DIFF=$S2_LOG_DIFF)"
|
||||||
|
|
||||||
# =====================================================================
|
# =====================================================================
|
||||||
runlabel "S3: CONCEPT_COLLISION_BESTEHEND (Zielpfad belegt -> Update-Routing, kein Duplikat)"
|
runlabel "S3: CONCEPT_COLLISION_BESTEHEND (Zielpfad belegt -> Update-Routing, kein Duplikat)"
|
||||||
@@ -109,16 +133,26 @@ Evidenz v2: quanten-protocol-schlüssel (Stelle S-2, ergaenzend).
|
|||||||
EOF
|
EOF
|
||||||
git add -A; git commit -qm "Zuwachs"
|
git add -A; git commit -qm "Zuwachs"
|
||||||
echo "--- Vor-Mutation-Check: Ziel-Pfad wiki/alpha.md belegt? ---"
|
echo "--- Vor-Mutation-Check: Ziel-Pfad wiki/alpha.md belegt? ---"
|
||||||
test -f wiki/alpha.md && echo "JA — Update-Routing (kein Duplikat, kein stummer Ueberschreiben)"
|
test -f wiki/alpha.md && echo "JA — Update-Routing (kein Duplikat, kein stummer Ueberschreiben)" \
|
||||||
|
|| fail "S3 Zielpfad wiki/alpha.md nicht belegt (Szenario-Setup verletzt)"
|
||||||
echo "--- Vor-Mutation-Zustand (muss leer sein) ---"
|
echo "--- Vor-Mutation-Zustand (muss leer sein) ---"
|
||||||
git status --porcelain -- wiki/; echo "(leer)"
|
S3_PRE=$(git status --porcelain -- wiki/)
|
||||||
echo "--- Mutation im bestehenden Pfad (Update) ---"
|
echo "$S3_PRE"
|
||||||
|
[ -z "$S3_PRE" ] && pass "S3 Vor-Mutation-Zustand leer" || fail "S3 Vor-Mutation-Zustand nicht leer: $S3_PRE"
|
||||||
|
# Mutation im bestehenden Pfad (Update)
|
||||||
echo "Ergaenzung (raw/alpha-v2.md#S-2)." >> wiki/alpha.md
|
echo "Ergaenzung (raw/alpha-v2.md#S-2)." >> wiki/alpha.md
|
||||||
echo "## 2026-08-19" >> wiki/log.md; echo "- Story 3.1-Update: alpha (raw/alpha-v2.md)" >> wiki/log.md
|
echo "## 2026-08-19" >> wiki/log.md; echo "- Story 3.1-Update: alpha (raw/alpha-v2.md)" >> wiki/log.md
|
||||||
echo "--- Nach-Mutation: nur M-Eintraege, KEIN ?? (keine neue Datei = kein Duplikat) ---"
|
echo "--- Nach-Mutation: nur M-Eintraege, KEIN ?? (keine neue Datei = kein Duplikat) ---"
|
||||||
git status --porcelain -- wiki/
|
S3_PORC=$(git status --porcelain -- wiki/)
|
||||||
echo "--- Probe ---"
|
echo "$S3_PORC"
|
||||||
probe
|
S3_UNTRACKED=$(echo "$S3_PORC" | grep -c '^??' || true)
|
||||||
|
[ "$S3_UNTRACKED" -eq 0 ] && pass "S3 keine ??-Einträge (kein Duplikat)" \
|
||||||
|
|| fail "S3 unerwartete ??-Einträge: $S3_PORC"
|
||||||
|
S3_ONLY_M=$(echo "$S3_PORC" | grep -cv '^ M ' || true)
|
||||||
|
[ -n "$S3_PORC" ] && [ "$S3_ONLY_M" -eq 0 ] && pass "S3 nur M-Einträge (Update im bestehenden Pfad)" \
|
||||||
|
|| fail "S3 Porcelain enthält Einträge außerhalb ' M ' (nur-$S3_ONLY_M-Andere)"
|
||||||
|
S3_PROBE=$(probe)
|
||||||
|
expect_eq "S3 Probe: genau alpha + log" "$(printf 'alpha\nlog')" "$S3_PROBE"
|
||||||
|
|
||||||
# =====================================================================
|
# =====================================================================
|
||||||
runlabel "S4: CHANGE_DETECTION (R-1: nur der Zuwachs wird als Evidenz interpretiert)"
|
runlabel "S4: CHANGE_DETECTION (R-1: nur der Zuwachs wird als Evidenz interpretiert)"
|
||||||
@@ -128,22 +162,35 @@ Evidenz v2: nur diese Datei ist neu (Stelle S-2).
|
|||||||
EOF
|
EOF
|
||||||
git add -A; git commit -qm "Zuwachs"
|
git add -A; git commit -qm "Zuwachs"
|
||||||
echo "--- git diff --name-only <BASE> -- raw/ ---"
|
echo "--- git diff --name-only <BASE> -- raw/ ---"
|
||||||
git diff --name-only "$BASE" -- raw/
|
S4_ADD=$(git diff --name-only "$BASE" -- raw/)
|
||||||
echo "--- Erwartet: AUSSCHLIESSLICH raw/alpha-v2.md (alpha-v1.md/beta-v1.md bleiben aussen) ---"
|
echo "$S4_ADD"
|
||||||
|
expect_eq "S4 Zuwachs: ausschließlich raw/alpha-v2.md" "raw/alpha-v2.md" "$S4_ADD"
|
||||||
echo "--- SHA-256-Abgleich (Sekundaer-Fingerprint, D-2): alpha-v1 unveraendert? ---"
|
echo "--- SHA-256-Abgleich (Sekundaer-Fingerprint, D-2): alpha-v1 unveraendert? ---"
|
||||||
sha256sum raw/alpha-v1.md
|
S4_SHA_NOW=$(sha256sum raw/alpha-v1.md | cut -d' ' -f1)
|
||||||
git show "$BASE:raw/alpha-v1.md" | sha256sum
|
S4_SHA_BASE=$(git show "$BASE:raw/alpha-v1.md" | sha256sum | cut -d' ' -f1)
|
||||||
echo "--- (identische Summen = unveraendert; bei Diskrepanz gewinnt git diff, D-2) ---"
|
echo "$S4_SHA_NOW / $S4_SHA_BASE"
|
||||||
|
[ -n "$S4_SHA_NOW" ] && [ "$S4_SHA_NOW" = "$S4_SHA_BASE" ] \
|
||||||
|
&& pass "S4 raw/alpha-v1.md byte-identisch zur Baseline (Immutabilität)" \
|
||||||
|
|| fail "S4 raw/alpha-v1.md weicht von der Baseline ab ($S4_SHA_NOW != $S4_SHA_BASE)"
|
||||||
|
|
||||||
# =====================================================================
|
# =====================================================================
|
||||||
runlabel "S5: PRE_RUN_RECONCILE (Check-Block vor Mutation; fehlende Bundleroot -> Run-FAIL V-1)"
|
runlabel "S5: PRE_RUN_RECONCILE (Check-Block vor Mutation; fehlende Bundleroot -> Run-FAIL V-1)"
|
||||||
isolate s5
|
isolate s5
|
||||||
rm wiki/index.md # Szenario-Setup: Bundleroot fehlt (simuliert, kein Run-Zustand)
|
rm wiki/index.md # Szenario-Setup: Bundleroot fehlt (simuliert, kein Run-Zustand)
|
||||||
echo "--- Check-Block: (4) wiki/index.md-V-1-Vorbedingung ---"
|
echo "--- Check-Block: (4) wiki/index.md-V-1-Vorbedingung ---"
|
||||||
if [ -f wiki/index.md ]; then echo "OK"; else echo "Run-FAIL (V-1, Vertrag §2): wiki/index.md fehlt — keine Mutation darf erfolgen"; fi
|
if [ -f wiki/index.md ]; then
|
||||||
|
echo "OK"
|
||||||
|
fail "S5 V-1-Vorbedingung: wiki/index.md fehlt nicht — Szenario-Setup verletzt"
|
||||||
|
else
|
||||||
|
echo "Run-FAIL (V-1, Vertrag §2): wiki/index.md fehlt — keine Mutation darf erfolgen"
|
||||||
|
pass "S5 V-1-Check löst Run-FAIL (fehlende Bundleroot)"
|
||||||
|
fi
|
||||||
git checkout -q "$BASE" -- wiki/index.md # Setup-Rueckstellung (kein Run-Zustand)
|
git checkout -q "$BASE" -- wiki/index.md # Setup-Rueckstellung (kein Run-Zustand)
|
||||||
echo "--- Zustand nach Abbruch + Rueckstellung (muss leer sein — der Run selbst mutierte nichts) ---"
|
echo "--- Zustand nach Abbruch + Rueckstellung (muss leer sein — der Run selbst mutierte nichts) ---"
|
||||||
git status --porcelain -- wiki/; echo "(leer)"
|
S5_PORC=$(git status --porcelain -- wiki/)
|
||||||
|
echo "$S5_PORC"
|
||||||
|
[ -z "$S5_PORC" ] && pass "S5 Zustand nach Abbruch leer (keine Mutation erfolgt)" \
|
||||||
|
|| fail "S5 Zustand nach Abbruch nicht leer: $S5_PORC"
|
||||||
|
|
||||||
# =====================================================================
|
# =====================================================================
|
||||||
runlabel "S6: INPUT_UNCOMMITTED (D-3: Working-Copy vs. HEAD-Check -> benannter Abbruch)"
|
runlabel "S6: INPUT_UNCOMMITTED (D-3: Working-Copy vs. HEAD-Check -> benannter Abbruch)"
|
||||||
@@ -151,10 +198,22 @@ isolate s6
|
|||||||
echo "uncommittete Zwischenstunde" >> raw/alpha-v1.md # simuliert Dirty-Tree
|
echo "uncommittete Zwischenstunde" >> raw/alpha-v1.md # simuliert Dirty-Tree
|
||||||
echo "--- Check-Block: Working-Copy vs. HEAD fuer raw/ + wiki/ ---"
|
echo "--- Check-Block: Working-Copy vs. HEAD fuer raw/ + wiki/ ---"
|
||||||
DIRTY=$(git status --porcelain -- raw/ wiki/)
|
DIRTY=$(git status --porcelain -- raw/ wiki/)
|
||||||
if [ -z "$DIRTY" ]; then echo "OK — published/committed Input"; else
|
if [ -z "$DIRTY" ]; then
|
||||||
|
echo "OK — published/committed Input"
|
||||||
|
fail "S6 Dirty-Tree nicht erkannt (Abbruch hätte greifen müssen)"
|
||||||
|
else
|
||||||
echo "Abbruch: published/committed Input erforderlich (AD-17a) — ungepublishter Zustand:"
|
echo "Abbruch: published/committed Input erforderlich (AD-17a) — ungepublishter Zustand:"
|
||||||
echo "$DIRTY"
|
echo "$DIRTY"
|
||||||
|
pass "S6 INPUT_UNCOMMITTED-Abbruch greift (benannter Abbruch, keine Mutation)"
|
||||||
fi
|
fi
|
||||||
|
|
||||||
echo
|
echo
|
||||||
echo "Sandbox-Root: $ROOT (loeschbar: rm -rf $ROOT)"
|
echo "########## EMBEDDED-EXIT ##########"
|
||||||
|
echo "FAILED=$FAILED PASS_COUNT=$PASS_COUNT"
|
||||||
|
if [ "$FAILED" -eq 0 ]; then
|
||||||
|
echo "SANDBOX-3-1-OK"
|
||||||
|
exit 0
|
||||||
|
else
|
||||||
|
echo "SANDBOX-3-1-FAILED" >&2
|
||||||
|
exit 1
|
||||||
|
fi
|
||||||
|
|||||||
File diff suppressed because it is too large
Load Diff
+108
-16
File diff suppressed because one or more lines are too long
@@ -29,7 +29,7 @@
|
|||||||
# - Dev moves story to 'review', then runs code-review (fresh context, different LLM recommended)
|
# - Dev moves story to 'review', then runs code-review (fresh context, different LLM recommended)
|
||||||
# - Retrospective appends its action items to action_items; the status view surfaces open ones
|
# - Retrospective appends its action items to action_items; the status view surfaces open ones
|
||||||
generated: 08-14-2026 00:00
|
generated: 08-14-2026 00:00
|
||||||
last_updated: 08-22-2026 19:10
|
last_updated: 08-24-2026 13:22
|
||||||
project: wow20
|
project: wow20
|
||||||
project_key: NOKEY
|
project_key: NOKEY
|
||||||
tracking_system: file-system
|
tracking_system: file-system
|
||||||
@@ -50,7 +50,7 @@ development_status:
|
|||||||
2-5-progressive-discovery-über-index-md-bereitstellen: done
|
2-5-progressive-discovery-über-index-md-bereitstellen: done
|
||||||
epic-2-retrospective: done
|
epic-2-retrospective: done
|
||||||
|
|
||||||
epic-3: in-progress
|
epic-3: done # 2026-08-24: Story 3.13 (Epic-3-Abnahmegate) done — AC-9 erfüllt (alle Stories 3.1–3.13 done; grüner Re-Run #10, Review-Loop-2 konvergiert). Die epic-3-Retrospektive (optional) bleibt offen.
|
||||||
3-1-inkrementellen-datenfluss-implementieren-interpret-reconcile: done
|
3-1-inkrementellen-datenfluss-implementieren-interpret-reconcile: done
|
||||||
3-2-relevanzbestimmung-textual-deterministisch-umsetzen-grep-rip: done
|
3-2-relevanzbestimmung-textual-deterministisch-umsetzen-grep-rip: done
|
||||||
3-3-bestehende-concepts-erweitern-präzisieren-korrigieren: done
|
3-3-bestehende-concepts-erweitern-präzisieren-korrigieren: done
|
||||||
@@ -63,7 +63,7 @@ development_status:
|
|||||||
3-10-inkrementelle-update-und-synthese-erhaltung-absichern: done # Story 3.10 Abschluss 2026-08-21 (bmad-code-review, 3 Layer; Patch-Kaskade, keine intent_gap/bad_spec — Sandbox E-1..E-9 nach Härtung 9/9 harte PASS/Exit 0, §5.16 Rev 3.5). Hinweis: die Epic-3-Abnahme (3.13) bleibt offen (epic-3 remains in-progress).
|
3-10-inkrementelle-update-und-synthese-erhaltung-absichern: done # Story 3.10 Abschluss 2026-08-21 (bmad-code-review, 3 Layer; Patch-Kaskade, keine intent_gap/bad_spec — Sandbox E-1..E-9 nach Härtung 9/9 harte PASS/Exit 0, §5.16 Rev 3.5). Hinweis: die Epic-3-Abnahme (3.13) bleibt offen (epic-3 remains in-progress).
|
||||||
3-11-root-scope-leasing-atomar-akquirieren: done # Story 3.11 Review-Loop-1-Abschluss 2026-08-21 (bmad-code-review, 4 Layer; D-3.11-1 „Konstruktiv + härten", D-3.11-2 „Intentionalen Mutationsversuch bauen"; 20 Patches angewendet — A-2-Sampler wirksam, A-4 Worktree-Beobachtung, A-7 MERGE_OK hart abgewiesen + Post-Merge-State + Baseline im Hold-Eintrag, §5.17 Pkt. 1/4/5-Berichtigungen; Sandbox A-1..A-8 8/8 harte PASS/Exit 0 re-executiert). Hinweis: der finale `done`-Flip ist der Step-05-Status-Sync nach konvergiertem Review-Loop (Präzedenz Story 3.7/3.8/3.9); die Epic-3-Abnahme (3.13) bleibt offen (epic-3 remains in-progress).
|
3-11-root-scope-leasing-atomar-akquirieren: done # Story 3.11 Review-Loop-1-Abschluss 2026-08-21 (bmad-code-review, 4 Layer; D-3.11-1 „Konstruktiv + härten", D-3.11-2 „Intentionalen Mutationsversuch bauen"; 20 Patches angewendet — A-2-Sampler wirksam, A-4 Worktree-Beobachtung, A-7 MERGE_OK hart abgewiesen + Post-Merge-State + Baseline im Hold-Eintrag, §5.17 Pkt. 1/4/5-Berichtigungen; Sandbox A-1..A-8 8/8 harte PASS/Exit 0 re-executiert). Hinweis: der finale `done`-Flip ist der Step-05-Status-Sync nach konvergiertem Review-Loop (Präzedenz Story 3.7/3.8/3.9); die Epic-3-Abnahme (3.13) bleibt offen (epic-3 remains in-progress).
|
||||||
3-12-lease-lifecycle-und-commit-abschluss-transaktional-schliessen: done # Story 3.12 Review-Loop-2-Abschluss 2026-08-22 (bmad-code-review, 4 Layer; D-3.12-1 Option 1 — AC-6-Grenze an log.md-Praxis, L-8-Kategorie-Hyphenate + Negativ-Kontrolle; 7 Patches — P1 scopelock_healthy()/LOCK_READ_ERROR-Propagation, P2 Release-Fehler-negativ + L-6 hart, P3 Setup-Robustheit, P4 Ghost-Diff-Probe + reg_write real, P5 Ownership-Stale + Takeover-Exactly-once, S1/S2 Sync- & Anker-Berichtigung; Sandbox L-1..L-9 9/9 harte PASS/Exit 0 re-executiert; Loop 1: atomarer Ownership-CAS im Takeover, AK-2->AC-2; §5.18 Revision 3.7). Hinweis: der finale `done`-Flip ist der Step-05-Status-Sync nach konvergiertem Review-Loop (Präzedenz Story 3.7/3.8/3.9/3.10/3.11); die Epic-3-Abnahme (3.13) bleibt offen (epic-3 remains in-progress).
|
3-12-lease-lifecycle-und-commit-abschluss-transaktional-schliessen: done # Story 3.12 Review-Loop-2-Abschluss 2026-08-22 (bmad-code-review, 4 Layer; D-3.12-1 Option 1 — AC-6-Grenze an log.md-Praxis, L-8-Kategorie-Hyphenate + Negativ-Kontrolle; 7 Patches — P1 scopelock_healthy()/LOCK_READ_ERROR-Propagation, P2 Release-Fehler-negativ + L-6 hart, P3 Setup-Robustheit, P4 Ghost-Diff-Probe + reg_write real, P5 Ownership-Stale + Takeover-Exactly-once, S1/S2 Sync- & Anker-Berichtigung; Sandbox L-1..L-9 9/9 harte PASS/Exit 0 re-executiert; Loop 1: atomarer Ownership-CAS im Takeover, AK-2->AC-2; §5.18 Revision 3.7). Hinweis: der finale `done`-Flip ist der Step-05-Status-Sync nach konvergiertem Review-Loop (Präzedenz Story 3.7/3.8/3.9/3.10/3.11); die Epic-3-Abnahme (3.13) bleibt offen (epic-3 remains in-progress).
|
||||||
3-13-epic-3-verifikations-und-abnahmegate: done # Story 3.13 Epic-3-Abnahmegate abgeschlossen 2026-08-22: run-sandbox.sh (A Setup, B Käfig-Bau, C 12 Sandbox-Sub-Runs, D Validator-Agent, E Zwei-frische-Agenten A/B, F G-1..G-8, G Porcelain) — voller Lauf PASS_COUNT=70, FAILED=0, RUN_OK/Exit 0; Validator 7/7 SUCCESS über reales Bundle; A/B byte-identisch nur at-Ausnahme (§5.14 Pkt. 2); G-6 Negativ-Kontrolle erkennt Perturbation; G-8 Ist-Baum-Porcelain leer. Aufgedeckte und behobene reale Befunde: (1) wiki/log.md:42 zitat das Literal 'type: bundle' in Prosa → Validator Punkt-9-Verletzung, bedeutungserhaltend de-literalisiert (Bundle-Compliance); (2) G-7-Smoke überstreng gegen Bundleroot-Schema-Glossar (../schema/, compiler §5.6 'andere Schicht') + log.md-Protokoll (§5.6 Pkt. 2 Log-Exclusion) → Exclusion im Gate, Smoke bleibt hart für Concept-Bodies. Epic-3 bleibt in-progress bis zur Epic-3-Retrospektive (AC-9: Epic 3 erst nach done aller Stories 3.8..3.13).
|
3-13-epic-3-verifikations-und-abnahmegate: done # Story 3.13 Review-Loop-2-Abschluss 2026-08-24 (bmad-code-review, 4 Layer, 2026-08-22; 28 eindeutige Befunde: 7 decision-needed / 15 patch / 2 defer / 6 dismissed; ProMods: „Ich folge Deinen Empfehlungen" — D-3.13-1..6 = 1/1/2/1/1/1, D-3.13-7 = 1): Status-Flip `done → in-progress` zurückgenommen (D-3.13-7, Präzedenz 3.7–3.12: finaler `done`-Flip = Step-05 nach konvergiertem Review-Loop); alle 22 Befunde tickt + Change-Log-Eintrag; run-sandbox.sh gehärtet (839 Z.: D-1..D-6 + P-2..P-14 — geankerter E.4-Classifier, Receipt-A-vs-B, G-6 perturbed-Tree wt-c + at-only-Kontrolle wt-c2, G-7 Link-Auflösung + geschlossene Token-Menge am Ist-Baum, D-NEG 3×FAIL+1×SUCCESS, Validator-Defizit-Route, P-11/P-13/P-14); P-1: sandbox-3-1 harte Exit-Pfade (14 PASS/Exit 0); VALIDATOR_DEFIZIT-Matrix-Zeile „G-5 PASS" vs. Boundary/AC-4 = Renegotiation-Kandidat (Boundary/AC-4 gilt implementiert; frozen-Block unangetastet, Ask-First). Erst-Lauf-Beleg (2026-08-22, vor Härtung): PASS_COUNT=70, FAILED=0, RUN_OK/Exit 0, Validator 7/7 SUCCESS — die (20/27/40/51/60/68)-Schnappschüsse im log.md-Eintrag sind kumulative PASS_COUNT-Werte; $BASE=5024d751… ist ein /tmp-Käfig-Commit (Lauf-Beleg, nicht re-ableitbar — P-12, korrigierende Formulierung im 2026-08-23-log-Eintrag). Re-Run #5 (Voll-Lauf gehärtetes Gate 915 Z., 2026-08-23): **ROT an E.4** (`NON_AT=26 AT=4`) — korrekt erkannter echter AD-16-A/B-Divergenz-Befund in der freien CREATE-Synthese (Slug-Identität `beta` vs. `quanten-observatorium-kanal` + freier Body-/log.md-Wortlaut), kein false-PASS; UPDATE-Pfad `alpha` byte-identisch bis auf `at:`; A/B, C 12/12, D 4/4 SUCCESS, D-NEG 3×FAIL+1×SUCCESS, E.1–E.3 + beide frische Agent-Läufe grün, F/G im Voll-Lauf nicht demonstriert (fail-fast an E.4). **AC-4-Defizit-Roadmap:** Behebung liegt in `schema/compiler.md` (read-only) oder A/B-Vergleichsumfang (A0-20) → Story 3.13 bleibt `in-progress`, Bedarf an **separat autorisierter Epic-1-Remediation** (bzw. menschlicher A/B-Umfangs-Entscheidung) benannt; kein stiller Schema-Change (AD-3/AC-4). **Review-Loop-2 (2026-08-24, bmad-code-review 4 Layer, Diff `50f3628..HEAD` + working tree): 38 rohe → 4 decision-needed / 11 patch / 2 defer / 4 dismissed; alle Entscheidungen mit ProMods geschlossen (D-3.13-L2-1 = Defer+Bearer-Fix, D-3.13-L2-2 = Defer+Gate-Doku, D-3.13-L2-3 = Defer+Substitutions-Notiz, D-3.13-L2-4 = dokumentierte Abweichung), alle Patches P-L2-1..11 angewendet (Gate 1005 Z., `bash -n` clean).** **Grüner Re-Run #10 (2026-08-24, committed `09c1c83`): `FAILED=0 PASS_COUNT=51`, SANDBOX-3-13-OK, RUN_OK/Exit 0 — A.5 Pre-Check sauber, C 12/12, D 4/4 SUCCESS, D-NEG 3×FAIL+1×SUCCESS, E.4 `NON_AT=0 AT=2`, E.6 Feldsatz-exakt + Known-Value-Witness (P-L2-1/2), E.9 kanonische `Baseline $BASE`-Form (P-L2-6) hart grün, F G-1..G-8 (G-6 Negativ-Kontrolle NON_AT=2 erkannt, Positiv-Kontrolle at-only toleriert, G-7 Smoke 0 Verletzungen), G-8 Porcelain-Clean (inkl. Untracked) + Negativ-Kontrolle + AD-3 Read-only ohne Diff.** Finaler `done`-Flip (Step-05 nach konvergiertem Review-Loop-2 + grünem Re-Run, Präzedenz 3.7–3.12). **Epic 3 → `done`** (AC-9: alle Stories 3.1–3.13 done); `epic-3-retrospective` (optional) bleibt offen.
|
||||||
epic-3-retrospective: optional
|
epic-3-retrospective: optional
|
||||||
|
|
||||||
epic-4: backlog
|
epic-4: backlog
|
||||||
|
|||||||
+8
-3
@@ -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).
|
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).
|
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.
|
- 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)
|
## 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.)*
|
- **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).
|
- **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.
|
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
|
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
|
```sh
|
||||||
git diff --name-only <Baseline-Commit> -- wiki/
|
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).
|
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.
|
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.
|
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).
|
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)
|
## 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.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.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.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).
|
||||||
|
|||||||
File diff suppressed because one or more lines are too long
Reference in New Issue
Block a user