fix: Story 3.13 Epic-1-Remediation (Rev 3.8) — kanonische byte-deterministische log.md-Eintragsform + CREATE-Kern aus A/B-Fixture (D-3.13-6 Option 2)
Re-Run #5 lief RED an E.4 (A/B-Determinismus: NON_AT=26 AT=4 → HARD-FAIL). Exakter Zeilen-Nachzähl-Befund: 24/26 (92%) der NON_AT-Abweichungen sind CREATE-/Slug-getrieben (beta.md 11 + quanten-observatorium-kanal.md 11 + index.md 2), verbleibende 4 log.md-Zeilen = 2 CREATE-Einträge (Slug-Divergenz) + 2 freie UPDATE-Wortungen (+ Wanduhr-generated.at im Body). Autorisierter Minimal-Änderungssatz (Q1 + "continue"): (1) compiler.md Rev 3.8 (D-3-Instruktions-Patch, additive Präzisierung): - §5.9 Pkt 4 (Update), §5.1 Pkt 4 (Anlage), §5.10 Pkt 7 (Synthese-Anlage): kanonische, byte-deterministische log.md-Eintragsform fixiert (- Story 3.1-Update: <concept> (<neue-Quellen>; Baseline <SHA>) etc.), kein freier Zusatztext, kein Wanduhr-Wert im log.md-Body (Wanduhr lebt ausschließlich im Frontmatter-generated.at, §5.14 Pkt 3). - §8 Revisionslog Rev 3.8-Eintrag. - NUR log.md-Form gepinnt; NUR Concept-Body/Slug/FR-2/§5.14-Pkt-3-Ausnahme UNVERÄNDERT. CREATE-Zielpfad-Signal-Pin = offener Defer (Ask-First). - Form = genau die, die Sub-Runs 3-3/3-4 mechanisch bereits demonstrieren (Ist-Behaviour verankert, kein Widerspruch). (2) run-sandbox.sh E-Sektion: CREATE-/beta-Fall aus der A/B-Fixture entfernt (D-3.13-6 Option 2): E.1-Fixture (keine beta-Quellen), AGENT_PROMPT (keine beta-Fakt), E.5 (CREATE-Witness entfernt, UPDATE-Alpha-Witness bleibt), E.8 (index.md unverändert statt "+1 CREATE-Link"), Header-Kommentare. A/B-Prüfung deckt den Update-/Erhaltungs-Kern; CREATE/Synthese gelten über Sub-Runs 3-3/3-4 + D-Validator als demostriert. Beide Änderungen berühren NICHT die frozen I/O-Matrix-Zeile GENERATED_AT_AUSNAHME und NICHT den §5.14 Pkt 3-Vertrag. bash -n clean. Erwartetes E.4-Ergebnis: NON_AT=0 AT=2 (alpha.md at-only). Co-Authored-By: Claude <noreply@anthropic.com>
This commit is contained in:
Michael Tamse
+100
@@ -0,0 +1,100 @@
|
||||
---
|
||||
title: "Arbeitsauftrag — compiler.md Rev 3.7 → 3.8 (Epic-1-Remediation, Story 3.13): CREATE-Slug + log-Determinismus-Patch"
|
||||
status: DRAFT — Entwürfe (B1/B2) ready-to-apply; C (Body-Byte-Residual) an Nutzer-Entscheidung (a)/(b)/(c)/(d) gebunden; NICHT autorisiert, compiler.md UNVERÄNDERT
|
||||
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). Status **DRAFT** — `schema/compiler.md` ist **UNVERÄNDERT**; erst nach Nutzer-Freigabe werden B1/B2 (und ggf. C je Entscheidung) angewendet, danach 12-Sandbox-Re-Execution + Re-Run #6.
|
||||
|
||||
## 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).
|
||||
@@ -19,10 +19,12 @@
|
||||
# Negativ-Fixtures + 1 Positiv-Kontrolle; frischer
|
||||
# Validator-Agent MUSS 3×FAIL + 1×SUCCESS liefern
|
||||
# (E) Zwei-frische-Agenten zwei /tmp-Worktrees auf denselben $BASE-Commit
|
||||
# (isolierte Mini-Bundle-Fixture: UPDATE alpha + CREATE
|
||||
# beta), beide Läufe führen schema/compiler.md aus;
|
||||
# A/B-anglichen: Frontmatter/Index/Log/Byte-Kern nur
|
||||
# at-Ausnahme, Run-Receipts A==B (außer at/Tree-Cellen)
|
||||
# (isolierte Mini-Bundle-Fixture: UPDATE alpha —
|
||||
# Update-/Erhaltungs-Kern; CREATE-/Synthese-Kern über
|
||||
# Sub-Runs 3-3/3-4, D-3.13-6 Option 2), beide Läufe führen
|
||||
# schema/compiler.md aus; A/B-anglichen: Frontmatter/
|
||||
# Index/Log/Byte-Kern nur at-Ausnahme, Run-Receipts A==B
|
||||
# (außer at/Tree-Cellen)
|
||||
# (F) G-1..G-8 harte Assertions (inkl. G-6 echter perturbed-Drittrun-Tree
|
||||
# C durch denselben E.4-Classifier + Positiv-/Negativ-
|
||||
# Kontrolle, G-7 Epic-5-Smoke auf Ist-Baum, G-8 Porcelain)
|
||||
@@ -43,8 +45,12 @@
|
||||
# Bundle validierte Planungstoken-Menge (P-13).
|
||||
# - D-5: D-NEG = 3 §7-/§6-Negativ-Fixtures + frischer Validator-Agent,
|
||||
# der zwingend 3×FAIL + 1×SUCCESS liefert (AC-3-Hälfte).
|
||||
# - D-6: E.1-Fixture mit CREATE-Fall (beta: neue raw-Quellen → neues
|
||||
# Concept + Index-Link); AC-6 sechs Demonstrationsfälle.
|
||||
# - D-6: E.1-Fixture — Update-/Erhaltungs-Kern (alpha UPDATE + gamma Erhaltung);
|
||||
# CREATE-/Synthese-Kern bewusst NICHT in der A/B-Fixture (D-3.13-6 Option 2,
|
||||
# Re-Run #5-Befund: CREATE-Fall 24/26 der NON_AT-Abweichungen treibend —
|
||||
# Slug-Ableitung + CREATE-Prosa — und hebt den A/B-Byte-Kern aus der
|
||||
# at-Ausnahme; CREATE/Synthese gelten über die Sub-Runs 3-3/3-4 als
|
||||
# demostriert); AC-6 Demonstrationsfälle über Sub-Runs + A/B-Kern abgedeckt.
|
||||
# - P-2..P-14: siehe spec §5.18 (Patches).
|
||||
# ============================================================================
|
||||
set -u
|
||||
@@ -425,14 +431,18 @@ pos1=$(pos_count pos.md)
|
||||
# ==============================================================================
|
||||
runlabel "E. ZWEI FRISCHE AGENT-KONTEXTE A/B (AC-7)"
|
||||
|
||||
# --- E.1 Fixture im Käfig (D-6: UPDATE alpha + CREATE beta; Bundle-Frontmatter P-4) ---
|
||||
# --- E.1 Fixture im Käfig (AC-6-Update-/Erhaltungs-Kern; Bundle-Frontmatter P-4) ---
|
||||
# alpha: bestätigender Zuwachs raw/alpha-v2.md (S-3, gleiche Aussage wie alpha-v1#S-2)
|
||||
# beta: EINDEUTIGER Term quanten-observatorium-kanal — kein bestehendes Concept
|
||||
# deckt ihn ab ⇒ Routing CREATE (neues Concept + Index-Link, Punkt 11/Anlage).
|
||||
# Der Ziel-Pfad (Slug) wird vom Producer aus dem Term abgeleitet (§5.15/§5.7) —
|
||||
# das Gate HARDCODIERT ihn NICHT (D-1: keine erwarteten Plan-Literale); die
|
||||
# Witness detektiert die neue Datei über Git und prüft deren SEMANTIK.
|
||||
# ⇒ Routing UPDATE (CONFIRMING-Konsolidierung §5.16 Pkt. 4, Multi-Beleg §5.5).
|
||||
# gamma: unabhängig, bleibt byte-identisch (AC-6)
|
||||
# CREATE-/Synthese-Kern: NICHT Teil der A/B-Fixture — die CREATE-/Synthese-Mechanik
|
||||
# (neues Concept + Index-Link Punkt 11 + Slug-Ableitung §5.15/§5.7 + log.md)
|
||||
# ist über die Sub-Runs 3-3/3-4 (mechanische, gepinnte Fixture) als demostriert
|
||||
# gelten (Spec-Notiz, D-3.13-6 Option 2; Re-Run #5-Befund: der CREATE-Fall war
|
||||
# 24/26 der NON_AT-Abweichungen treibend — Slug-Ableitung + CREATE-Prosa — und
|
||||
# würde den A/B-Byte-Kern aus der at-Ausnahme herausheben. Die A/B-Prüfung
|
||||
# deckt damit den Update-+Erhaltungs-Kern; CREATE/Synthese bleiben über die
|
||||
# Sub-Runs + D-Validator abgedeckt.)
|
||||
rm -rf "$CAGE/wiki" "$CAGE/raw" # E.1 baut die Fixture sauber neu (keine §B-Reste in $BASE)
|
||||
mkdir -p "$CAGE/wiki" "$CAGE/raw"
|
||||
cat > "$CAGE/wiki/index.md" <<'FIXTURE'
|
||||
@@ -490,21 +500,10 @@ cat > "$CAGE/raw/gamma-v1.md" <<'FIXTURE'
|
||||
### S-1
|
||||
Evidenz v1: Gamma-Thema.
|
||||
FIXTURE
|
||||
cat > "$CAGE/raw/beta-v1.md" <<'FIXTURE'
|
||||
### S-1
|
||||
Beta: quanten-observatorium-kanal etabliert die Baseline.
|
||||
FIXTURE
|
||||
cat > "$CAGE/raw/beta-v2.md" <<'FIXTURE'
|
||||
### S-2
|
||||
Beta: quanten-observatorium-kanal bestätigt die Baseline.
|
||||
FIXTURE
|
||||
# Term-Isolations-Garantie (Fixture-Setup, kein Run-Zustand): der beta-Term darf
|
||||
# in KEINER Baseline-Datei vorkommen — sonst wäre CREATE unscharf (Kandidat alpha).
|
||||
if grep -rq 'quanten-observatorium-kanal' "$CAGE/wiki" "$CAGE/raw/alpha-v1.md" "$CAGE/raw/alpha-v2.md" "$CAGE/raw/gamma-v1.md"; then
|
||||
echo "HARD-FAIL (E.1): beta-Term taucht in Baseline-Dateien auf (CREATE-Isolation verletzt)" >&2
|
||||
exit 1
|
||||
fi
|
||||
pass "E.1 Fixture: Mini-Bundle (index+alpha+gamma+log) + Zuwachs alpha-v2/beta-v1/beta-v2, term-isoliert"
|
||||
# CREATE-/Synthese-Kern (beta-Quellen) bewusst NICHT in der A/B-Fixture — die
|
||||
# CREATE-Mechanik ist über die Sub-Runs 3-3/3-4 als demostriert gelten
|
||||
# (D-3.13-6 Option 2; Re-Run #5-Befund: 24/26 NON_AT-Abweichungen CREATE-treibend).
|
||||
pass "E.1 Fixture: Mini-Bundle (index+alpha+gamma+log) + Zuwachs alpha-v2 (UPDATE-Kern)"
|
||||
( cd "$CAGE" && git add -A && git commit -qm "Käfig-Fixture: Baseline inkl. Zuwachs" ) \
|
||||
|| { echo "HARD-FAIL (E.1): Fixture-Commit fehlgeschlagen" >&2; exit 1; }
|
||||
BASE=$(git -C "$CAGE" rev-parse HEAD)
|
||||
@@ -529,7 +528,6 @@ Fakten zur committeten Fixture in diesem Worktree (ausschließlich Fakten, keine
|
||||
- wiki/index.md (Bundleroot), wiki/log.md, wiki/alpha.md und wiki/gamma.md sind die bisherigen Concepts.
|
||||
- raw/alpha-v1.md und raw/gamma-v1.md sind Baseline-Evidenz.
|
||||
- raw/alpha-v2.md ist ein neu committeter Zuwachs (Stelle S-3); er enthält dieselbe belegte Aussage wie raw/alpha-v1.md#S-2.
|
||||
- raw/beta-v1.md und raw/beta-v2.md sind neu committete Zuwächse (Stellen S-1/S-2) mit einem eindeutigen Term, für den kein bestehendes Concept existiert.
|
||||
|
||||
Mutationen (wiki/-Concepts, index.md, log.md) UND die Receipt-Datei run-receipt.txt (Worktree-Root, AUSSERHALB von wiki/ und raw/) sind EXAKT nach den Konventionen von schema/compiler.md auszuführen — keine vorgegebenen Werte. Die run-receipt.txt trägt diese Felder (Werte aus deinem Lauf):
|
||||
baseline: <volles SHA des Baseline-Commits>
|
||||
@@ -635,7 +633,8 @@ fi
|
||||
[ -z "$AB_DIFF_STAT" ] && echo " BEFUND: A/B-Diff leer — Runs vollständig konvergiert (zulässig)"
|
||||
pass "E.4 A/B-Vergleich: Bundle-State identisch bis auf at-Ausnahme (§5.14 Pkt. 2 / G-1)"
|
||||
|
||||
# --- E.5 Witness: Nicht-Vakuum gegen Baseline (UPDATE alpha + CREATE beta) ---
|
||||
# --- E.5 Witness: Nicht-Vakuum gegen Baseline (UPDATE alpha; CREATE-/Synthese-Kern
|
||||
# über Sub-Runs 3-3/3-4, nicht Teil der A/B-Fixture — D-3.13-6 Option 2) ---
|
||||
# alpha (UPDATE): Multi-Beleg-Anker raw/alpha-v2.md#S-3 + sources-Konsolidierung.
|
||||
ABS_A=$(git -C "$CAGE" show "$BASE:wiki/alpha.md" | sha256sum | cut -d' ' -f1)
|
||||
for wt in a b; do
|
||||
@@ -645,32 +644,7 @@ for wt in a b; do
|
||||
git -C "$ROOT/wt-$wt" show 'HEAD:wiki/alpha.md' | grep -q 'raw/alpha-v2.md#S-3' \
|
||||
|| { echo "HARD-FAIL (E.5): Witness $wt alpha ohne Multi-Beleg-Anker raw/alpha-v2.md#S-3" >&2; exit 1; }
|
||||
done
|
||||
# beta (CREATE): die neue Concept-Datei wird GIBASES-DIFF-gedetectet (nie
|
||||
# Slug-hartcodiert — §5.15 leitet den Pfad aus dem Term ab; D-1: kein Plan-Literal).
|
||||
# Erwartet: exakt EINE neue wiki/-Datei (außer log.md/index.md, die M sind nicht A).
|
||||
NEW_CONCEPT_A=$(git -C "$CAGE" diff --name-only --diff-filter=A "$BASE" "$HEAD_A" -- wiki/ | grep -vE '(^|/)log\.md$' | grep -vE '(^|/)index\.md$' | LC_ALL=C sort)
|
||||
NEW_CONCEPT_B=$(git -C "$CAGE" diff --name-only --diff-filter=A "$BASE" "$HEAD_B" -- wiki/ | grep -vE '(^|/)log\.md$' | grep -vE '(^|/)index\.md$' | LC_ALL=C sort)
|
||||
NEW_A_COUNT=$(printf '%s\n' "$NEW_CONCEPT_A" | grep -c '^' || true)
|
||||
[ "$NEW_A_COUNT" -eq 1 ] \
|
||||
|| { echo "HARD-FAIL (E.5): CREATE A — erwartet exakt 1 neue Concept-Datei, sind: $NEW_A_COUNT" >&2; printf '%s\n' "$NEW_CONCEPT_A" >&2; exit 1; }
|
||||
# A und B müssen dieselbe neue Datei erzeugen (Determinismus der CREATE-Zuordnung)
|
||||
[ "$NEW_CONCEPT_A" = "$NEW_CONCEPT_B" ] \
|
||||
|| { echo "HARD-FAIL (E.5): CREATE-Pfad divergiert A($NEW_CONCEPT_A) vs B($NEW_CONCEPT_B) — Determinismus-Verstoß" >&2; exit 1; }
|
||||
NEW_CONCEPT="$NEW_CONCEPT_A"
|
||||
NEW_LEAF=$(basename "$NEW_CONCEPT")
|
||||
echo " CREATE-Zieldatei (Producer-geleitet, §5.15): $NEW_CONCEPT"
|
||||
for wt in a b; do
|
||||
git -C "$ROOT/wt-$wt" show "HEAD:$NEW_CONCEPT" | grep -q 'resource: raw/beta-v1.md' \
|
||||
|| { echo "HARD-FAIL (E.5): CREATE $wt — $NEW_CONCEPT sources ohne raw/beta-v1.md" >&2; exit 1; }
|
||||
git -C "$ROOT/wt-$wt" show "HEAD:$NEW_CONCEPT" | grep -q 'resource: raw/beta-v2.md' \
|
||||
|| { echo "HARD-FAIL (E.5): CREATE $wt — $NEW_CONCEPT sources ohne raw/beta-v2.md" >&2; exit 1; }
|
||||
git -C "$ROOT/wt-$wt" show "HEAD:$NEW_CONCEPT" | grep -q 'quanten-observatorium-kanal' \
|
||||
|| { echo "HARD-FAIL (E.5): CREATE $wt — $NEW_CONCEPT trägt nicht den beta-Term (falsches Concept)" >&2; exit 1; }
|
||||
# Index-Verlinkung (Punkt 11/Anlage): die Bundleroot verlinkt die neue Datei.
|
||||
git -C "$ROOT/wt-$wt" show 'HEAD:wiki/index.md' | grep -qF "$NEW_LEAF" \
|
||||
|| { echo "HARD-FAIL (E.5): CREATE $wt — index.md verlinkt die neue Concept-Datei $NEW_LEAF nicht (Punkt 11)" >&2; exit 1; }
|
||||
done
|
||||
pass "E.5 Witness: alpha UPDATE (Multi-Beleg) + beta CREATE (neue Datei, sources, Term, Index-Link) in A und B"
|
||||
pass "E.5 Witness: alpha UPDATE (Multi-Beleg raw/alpha-v2.md#S-3 + sources-Konsolidierung) in A und B"
|
||||
|
||||
# --- E.6 Run-Receipt A-vs-B (D-2: Modell sandbox-3-8 DET-2, keine erwarteten Literale) ---
|
||||
RA="$ROOT/wt-a/run-receipt.txt"
|
||||
@@ -710,7 +684,8 @@ for wt in a b; do
|
||||
done
|
||||
pass "E.7 sources-Liste alpha.md (A und B) konsolidiert (raw/alpha-v1.md + raw/alpha-v2.md)"
|
||||
|
||||
# --- E.8 Unabhängiges Wissen erhalten (AC-6): gamma byte-pinned; index = BASE + exakt 1 neue Link-Zeile ---
|
||||
# --- E.8 Unabhängiges Wissen erhalten (AC-6): gamma byte-pinned; index.md UNVERÄNDERT
|
||||
# (kein CREATE in der A/B-Fixture — D-3.13-6 Option 2: kein neuer/entfernter Link) ---
|
||||
HA=$(git -C "$ROOT/wt-a" show 'HEAD:wiki/gamma.md' | sha256sum | cut -d' ' -f1)
|
||||
HB=$(git -C "$ROOT/wt-b" show 'HEAD:wiki/gamma.md' | sha256sum | cut -d' ' -f1)
|
||||
BASEHG=$(git -C "$CAGE" show "$BASE:wiki/gamma.md" | sha256sum | cut -d' ' -f1)
|
||||
@@ -722,13 +697,15 @@ IDX_B=$(git -C "$ROOT/wt-b" show 'HEAD:wiki/index.md')
|
||||
IDX_DIFF=$(git -C "$CAGE" diff "$BASE" "$HEAD_A" -- wiki/index.md)
|
||||
IDX_ADDED=$(printf '%s\n' "$IDX_DIFF" | grep -c '^+[^+]' || true)
|
||||
IDX_DELETED=$(printf '%s\n' "$IDX_DIFF" | grep -c '^-[^-]' || true)
|
||||
[ "$IDX_DELETED" -eq 0 ] || { echo "HARD-FAIL (E.8): index.md trägt Deletions (nur Appending erlaubt):" >&2; printf '%s\n' "$IDX_DIFF" >&2; exit 1; }
|
||||
[ "$IDX_ADDED" -eq 1 ] || { echo "HARD-FAIL (E.8): index.md Diff != exakt 1 Zeile (erwartet: CREATE-Link), ist: $IDX_ADDED" >&2; printf '%s\n' "$IDX_DIFF" >&2; exit 1; }
|
||||
printf '%s\n' "$IDX_DIFF" | grep '^+[^+]' | grep -qF "$NEW_LEAF" \
|
||||
|| { echo "HARD-FAIL (E.8): die einzige neue index-Zeile ist kein Link auf die CREATE-Datei $NEW_LEAF:" >&2; printf '%s\n' "$IDX_DIFF" >&2; exit 1; }
|
||||
pass "E.8 Unabhängiges Wissen erhalten: gamma byte-identisch; index = BASE + exakt 1 CREATE-Link (A==B)"
|
||||
[ "$IDX_ADDED" -eq 0 ] || { echo "HARD-FAIL (E.8): index.md trägt neue Zeilen (erwartet: unverändert — kein CREATE in A/B-Fixture):" >&2; printf '%s\n' "$IDX_DIFF" >&2; exit 1; }
|
||||
[ "$IDX_DELETED" -eq 0 ] || { echo "HARD-FAIL (E.8): index.md trägt Deletions (erwartet: unverändert):" >&2; printf '%s\n' "$IDX_DIFF" >&2; exit 1; }
|
||||
pass "E.8 Unabhängiges Wissen erhalten: gamma byte-identisch; index.md unverändert (kein CREATE in A/B-Fixture, A==B)"
|
||||
|
||||
# --- E.9 log.md: Eintrag mit vollem Baseline-SHA (R-1; P-9; kein vorgeschriebener Wortlaut) ---
|
||||
# --- E.9 log.md: Eintrag mit vollem Baseline-SHA (R-1; P-9) ---
|
||||
# Wort-Form: der A/B-Byte-Kern von log.md wird über die kanonische Log-Eintragsform
|
||||
# (compiler.md Rev 3.8, §5.9 Pkt. 4) garantiert — das Gate selbst HARDCODIERT den
|
||||
# Eintragswortlaut NICHT (D-1: keine erwarteten Literale), es prüft nur Struktur
|
||||
# (Lauf-Eintrag vorhanden + voller Baseline-SHA, R-1).
|
||||
for wt in a b; do
|
||||
LOG_BASE=$(git -C "$CAGE" show "$BASE:wiki/log.md" | sha256sum | cut -d' ' -f1)
|
||||
LOG_HEAD=$(git -C "$ROOT/wt-$wt" show 'HEAD:wiki/log.md' | sha256sum | cut -d' ' -f1)
|
||||
|
||||
+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).
|
||||
3. **Index-Regel (Punkt 11/§6):** Nach Anlage MUSS das neue Concept in der `index.md` **seines Bereichs** verlinkt werden — für Root-Concepts in der Bundleroot `wiki/index.md`, für Area-Concepts in der jeweiligen Area-`index.md` (`wiki/<area>/index.md`, §5.7) — seine Identität (relativer OKF-Pfad ohne `.md`) als relativer Bundle-Pfad referenziert; die genau-eine-Form-Festlegung ist in **§5.6** gepinnt (file-relativ, mit `.md`-Endung; §5.7 Pkt. 4). Ohne diese Verlinkung ist das Bundle strukturell invalide (§7 Punkt 11).
|
||||
- All dies (Anlage + Verlinkung + `log.md`) erst abschließen, wenn die Validierung (§6) SUCCESS liefert. Zwischenstände werden nicht als fertige Mutation veröffentlicht — Commit-Boundary ist die Mutations-Boundary (AD-17f). Bei Validierungs-FAIL wird der Teilzustand **explizit zurückgerollt**: neue Concept-Datei(en) gelöscht, zugehörige Index-Verlinkung(en) aus `wiki/index.md` entfernt, `log.md`-Eintrag(e) wieder entfernt — das Bundle nimmt seinen Zustand vor dem Run wieder ein (keine partielle Mutation bleibt liegen). **Update-Pfad-Ergänzung (Review-Loop-2):** bei einem FAIL im Update-Pfad (§5.9) gilt derselbe Grundsatz für **modifizierte** Pfade — die vor dem Run geänderten Concept-Pfade (und die `log.md`-Einträge des Runs) werden aus dem Baseline-Zustand wiederhergestellt (z. B. `git checkout -- <wiki/pfad>`; der Baseline-Commit ist der in R-1/Pkt. 6 notierte `<Baseline-Commit>`), sodass kein teilweise aktualisierter Concept-State liegen bleibt.
|
||||
4. **Dokumentation (`log.md`, Vertrag §5):** Die Anlage neuer Concepts wird als datumsgruppierter Eintrag in `wiki/log.md` dokumentiert (neueste zuerst; Header = ISO-Datum `YYYY-MM-DD`), verknüpft mit dem neuen Concept-Pfad und den genutzten `raw/`-Quellen. `log.md` bleibt ohne Frontmatter (Punkt 10).
|
||||
4. **Dokumentation (`log.md`, Vertrag §5):** Die Anlage neuer Concepts wird als datumsgruppierter Eintrag in `wiki/log.md` dokumentiert (neueste zuerst; Header = ISO-Datum `YYYY-MM-DD`), verknüpft mit dem neuen Concept-Pfad und den genutzten `raw/`-Quellen. `log.md` bleibt ohne Frontmatter (Punkt 10). **Kanonische Log-Eintragsform (Revision 3.8, Story 3.13 — additive Präzisierung für den Determinismus-Vertrag §5.14/AD-17h):** der Anlage-Eintrag trägt **exakt** die kanonische Form `- Anlage: <concept> (<quellen>; Baseline <Baseline-Commit>)` mit: `<concept>` = die relative OKF-Identität **ohne** `.md` (ohne Backticks, ohne Zusatz-Labels); `<quellen>` = die genutzten `raw/`-Quellen, **lexikografisch (LC_ALL=C) sortiert** und per ` + ` getrennt; `<Baseline-Commit>` = der **volle** SHA. **Kein freier Zusatztext** und **kein Wanduhr-Wert** im `log.md`-Body (der Wanduhr-Wert lebt ausschließlich im Frontmatter-`generated.at`, §5.14 Pkt. 3-Ausnahme) — der Eintrag ist damit **byte-deterministisch** aus dem committeten Git-State + dem kanonischen Eingabeset (§5.14 Pkt. 2) ableitbar. Für die Synthese-Neu-Anlage gilt dieselbe Form mit dem Operations-Label `Synthese-Anlage` (§5.10 Pkt. 7, Revision 3.8).
|
||||
|
||||
## 5.5 Claim-granulare Provenienz (Story 2.2)
|
||||
|
||||
@@ -274,7 +274,7 @@ Diese Sektion ist der **einzige Instruktions-Ort** der Update-Mutationsmechanik
|
||||
- **Erweitern — Abgrenzungskriterium:** greift dann, wenn die neue committete Evidenz eine **neue belegte Aussage** trägt, die im bestehenden Body **nicht** existiert (Term-/Stellen-Abgleich gegen die §5.5-Inline-Verweise; kein bestehender Anker). **Struktur-Erhaltungsregel (Erweitern):** die neue Aussage wird als **eigener Absatz angefügt** (Body-Ende); bestehende belegte Aussagen bleiben **byte-identisch**, keine Umschreibung bestehender Absätze; Frontmatter nur `sources`-**Zuwachs um den echten neuen Beleg** + ein `generated.at`-Bump. **Textgenauigkeits-Rahmen (Erweitern):** die neue Aussage wird eigenständig formuliert, trägt den §5.5-Inline-Beleg mit existierender Stellen-Kennung; kein Satz-Umbau des Bestands. *(Überlappt eine Einheit mehrere Formen — z. B. sie trägt zugleich eine neue belegte Aussage und eine Schärfung einer bestehenden —, ordnet der Producer die Einheit der in der Abgrenzungs-Reihenfolge ersten zutreffenden Form zu (deterministisch, AD-17h); die Textgenauigkeits-Rahmen der übrigen Formen gelten für die jeweiligen Teilbestandteile unverändert.)*
|
||||
- **No-Op — Abgrenzungskriterium (Nicht-Form, engere Auslegung, bestehende Regel oben):** greift nur, wenn **keine** der drei Formen greift (die Evidenz ist bereits vollständig im Body); im Zweifel trifft eine der drei Formen — die Entscheidung ist textuell deterministisch (Term-/Stellen-Abgleich). **Erhaltungsregel (No-Op):** volle Byte-Identität (keine Mutation, kein `at`-Bump, kein `sources`-Zusatz, kein `log.md`-Eintrag).
|
||||
3. **Index-/Link-Form unverändert (§5.6-Pin):** Ein reines Body-Update ändert die Concept-Identität nicht → der bestehende Index-Link (Bundleroot oder Area-`index.md`) bleibt unverändert gültig; **kein neuer Link** bei reinem Body-Update (kein Index-`index.md`-Zusatz). Die **`log.md`-Eintragspflicht** (Pkt. 4) bleibt davon **unberührt**: *jedes* Update — auch ein reines Body-Update — MUSS seinen `log.md`-Eintrag „Story 3.1-Update" führen; nur der **Index-**Link bleibt unverändert. Wird durch das Update eine Concept-Kategorie (Root vs. Area) oder die Identität berührt, ist das **Ask-First** (AD-7d-Renames/Redirects; nicht Teil von Story 3.1). Neue zulässige Concept-Links (Beziehungsschicht, §5.6) werden nur gesetzt, wenn die neue Erkenntnis eine echte, inhaltsbegründete Beziehung rechtfertigt.
|
||||
4. **`log.md`-Eintragspflicht (Vertrag §5):** Jedes Update wird als datumsgruppierter Eintrag in `wiki/log.md` dokumentiert (Header = ISO-Datum `YYYY-MM-DD`, neueste zuerst), verknüpft mit dem mutierten Concept-Pfad und den genutzten `raw/`-Quellen. Für Updates wird der Eintrag als „**Story 3.1-Update**" markiert (disambiguierbar von Anlage-Einträgen). Konflikt-/Erhaltungsfälle (Pkt. 2 „Korrigieren" ohne Ersetzungsevidenz) werden explizit als Disagreement-Eintrag mit dem mutierten Concept-Pfad geführt (AD-16b, Vertrag §5) — der Epic-4-Interface-Fall bleibt dokumentiert, ohne Korrektur-Klassifikation hier.
|
||||
4. **`log.md`-Eintragspflicht (Vertrag §5):** Jedes Update wird als datumsgruppierter Eintrag in `wiki/log.md` dokumentiert (Header = ISO-Datum `YYYY-MM-DD`, neueste zuerst), verknüpft mit dem mutierten Concept-Pfad und den genutzten `raw/`-Quellen. Für Updates wird der Eintrag als „**Story 3.1-Update**" markiert (disambiguierbar von Anlage-Einträgen). Konflikt-/Erhaltungsfälle (Pkt. 2 „Korrigieren" ohne Ersetzungsevidenz) werden explizit als Disagreement-Eintrag mit dem mutierten Concept-Pfad geführt (AD-16b, Vertrag §5) — der Epic-4-Interface-Fall bleibt dokumentiert, ohne Korrektur-Klassifikation hier. **Kanonische Log-Eintragsform (Revision 3.8, Story 3.13 — additive Präzisierung für den Determinismus-Vertrag §5.14/AD-17h, kein Re-Negotiation des obigen Regeltexts):** Der Update-Eintrag trägt **exakt** die kanonische Form `- Story 3.1-Update: <concept> (<neue-Quellen>; Baseline <Baseline-Commit>)` mit: `<concept>` = die relative OKF-Identität **ohne** `.md` (ohne Backticks, ohne Zusatz-Labels wie `neu:`); `<neue-Quellen>` = die in diesem Run **neu** hinzugekommenen `raw/`-Quellen, **lexikografisch (LC_ALL=C) sortiert** und per ` + ` getrennt (eindeutig aus der Zuwachs-Sicht, Pkt. 6 R-1 — bei einer einzelnen Quelle nur der eine Pfad); `<Baseline-Commit>` = der **volle** SHA (Pkt. 6 R-1). Der Eintrag trägt **keinen freien Zusatztext** (keine Update-Typ-Erklärung, keine §-/Pkt.-Referenzen, keine Beleg-Stellen-Kennungen) und **keinen Wanduhr-Wert** (`generated.at`/`verified[].at`) — der Wanduhr-Wert lebt **ausschließlich** im Frontmatter-`generated.at` (§5.14 Pkt. 3-Ausnahme), nie im `log.md`-Body. Die `## YYYY-MM-DD`-Datumsgruppe (neueste zuerst, Pkt. 4) ist Teil der Form und wird über den Eintrag gehoben. Damit ist der Eintrag **byte-deterministisch aus dem committeten Git-State + dem kanonischen Eingabeset** (§5.14 Pkt. 2) ableitbar: zwei unabhängige Runs desselben Git-States + desselben Eingabesets liefern **byte-identische** `log.md`-Einträge (identische Datumsgruppe, identische Werte). Die Anlage- und Synthese-Neu-Anlage-Einträge folgen derselben kanonischen Form mit ihrem jeweiligen Operations-Label (§5.1 Pkt. 4, §5.10 Pkt. 7 — Revision 3.8).
|
||||
5. **Erhaltungs-Invariante (Kern) + deterministischer Diff-Selbsttest (AD-17h, FT-6/FR-12):** Ein Compilation Run darf nur die Concepts **neu anlegen oder verändern**, die durch den erkannten Erkenntnis-Zuwachs tatsächlich betroffen sind. **Nicht betroffene Concept-Pfade bleiben byte-identisch unverändert** — es gibt **nie** „Regenerate Everything" (AD-5, A0-6). Die Inkrementalität ist als **re-executierbarer Diff-Selbsttest** mechanisch kontrollierbar: Nach jedem Run prüft der Producer ab der Workspace-Root
|
||||
```sh
|
||||
git diff --name-only <Baseline-Commit> -- wiki/
|
||||
@@ -298,7 +298,7 @@ Diese Sektion ist der **Instruktions-Ort der Synthese-Dimension** (AD-4, FR-7):
|
||||
4. **Übernahme aus bestehenden Concepts (AD-4c — nie alleinige Provenienz):** Übernimmt das Synthese-Concept Formulierungen aus bestehenden Concepts (Kontext-/Synthese-Umformulierung, nicht eigenständig gegen `raw/` belegt), trägt die übernommene Aussage den **§5.5-Kontext-Marker** (Pkt. 2, Muster „übernommen aus `<Concept>` auf Basis von `<source>`, nicht eigenständig belegt") — **kein bestehendes Concept ist alleinige Provenienz eines anderen**. Die Quelle des übernommenen Concepts bleibt damit textuell rückverfolgbar; die Direktübernahme aus `raw/` (ohne Zwischen-Concept) verwendet das Muster „übernommen aus `<source>` (rohe Quelle), nicht eigenständig belegt". **Sandbox-Szenario N3** demonstriert den Kontext-Marker („übernommen aus `gamma` auf Basis von `raw/gamma-v1.md#S-1`, nicht eigenständig belegt") und prüft, dass die Quelle des übernommenen Concepts **nicht** als eigene `sources`-Quelle eingetragen wird (AD-4c).
|
||||
5. **Reflektierter Wissensstand (FR-7 AC-4, NFR-7):** Der Body trägt **integrierte, je Aussage provenance-tags versehene Aussagen** — **keine per-Source-Zusammenfassungs-Struktur** (keine Blöcke „Quelle A: … / Quelle B: …"). **Reflektiertheits-Selbsttest (textuell deterministisch, grepbasiert):** es existiert **keine** Zeile, die einen Quell-Label abschnittsstrukturiert — das Muster ist ein Zeilenanfangs-Label „`Quelle <Label>:`"/„`Source <Label>:`" (einbuchstabig, mehrbuchstabig oder mit Ziffer/Unterstrich suffigiert), grepbasiert `grep -nE '^(Quelle|Source) [A-Z][A-Za-z0-9_ -]*:' <Synthese-Concept>` liefert leer; jede Aussage trägt ihren Provenienz-Tag (§5.5). Ein Befund (Aneinanderreihung) ist ein **Instruktions-Selbsttest-FAIL** (NFR-7, kein stiller Vorbeilass — NFR-4): der Producer stellt den Body vor Run-Abschluss so um, dass die Integration erfüllt ist.
|
||||
6. **§5.6-Pin unverändert:** Synthese fügt **keine neue Linkform** und **keine** neuen `index.md`-Links ohne echte, inhaltsbegründete Beziehung hinzu — §5.6-Pin (genau-eine-Linkform, file-relativ mit `.md`-Endung) und §5.9 Pkt. 3 (kein neuer Index-Link bei reinem Body-Update) gelten unverändert. **Form-Wahl-Klassifikationsprobe (Defer U2/U7, Story 3.3):** eine Synthese-Einheit, die zugleich neue + schärfende + ersetzende Anteile trägt (Form-Überlapp), wird per §5.9-Abgrenzungs-Reihenfolge `Korrigieren → Präzisieren → Erweitern → No-Op` **strikt pro Evidenz-Einheit** der **ersten zutreffenden Form** zugeordnet (deterministisch, AD-17h); die Textgenauigkeits-Rahmen der übrigen Formen gelten für die jeweiligen Teilbestandteile unverändert.
|
||||
7. **`log.md`-Eintragspflicht (Vertrag §5):** Jede Synthese wird als datumsgruppierter Eintrag in `wiki/log.md` dokumentiert. Ein Synthese-**Update** auf ein bestehendes Concept führt den Eintrag „**Story 3.1-Update**" (Disagreement-Fälle als Disagreement-Eintrag mit dem mutierten Concept-Pfad, AD-16b); eine Synthese-**Neu-Anlage** eines neuen Synthese-Concepts führt einen **Anlage-Eintrag** (disambiguierbar von Update-Einträgen). Der Eintrag verknüpft das erzeugte Concept mit der **vollständigen Multi-Source-`sources`-Liste** und hält den `<Baseline-Commit>` (R-1, §5.9 Pkt. 6) fest.
|
||||
7. **`log.md`-Eintragspflicht (Vertrag §5):** Jede Synthese wird als datumsgruppierter Eintrag in `wiki/log.md` dokumentiert. Ein Synthese-**Update** auf ein bestehendes Concept führt den Eintrag „**Story 3.1-Update**" (Disagreement-Fälle als Disagreement-Eintrag mit dem mutierten Concept-Pfad, AD-16b); eine Synthese-**Neu-Anlage** eines neuen Synthese-Concepts führt einen **Anlage-Eintrag** (disambiguierbar von Update-Einträgen). Der Eintrag verknüpft das erzeugte Concept mit der **vollständigen Multi-Source-`sources`-Liste** und hält den `<Baseline-Commit>` (R-1, §5.9 Pkt. 6) fest. **Kanonische Log-Eintragsform (Revision 3.8, Story 3.13 — additive Präzisierung für den Determinismus-Vertrag §5.14/AD-17h):** die Synthese-**Neu-Anlage** trägt **exakt** die kanonische Form `- Synthese-Anlage: <concept> (<quellen>; Baseline <Baseline-Commit>)` (Operations-Label `Synthese-Anlage`, disambiguierbar von `Anlage`/`Story 3.1-Update`); `<quellen>` = die **vollständige** Multi-Source-`sources`-Liste, **lexikografisch (LC_ALL=C) sortiert** und per ` + ` getrennt; `<Baseline-Commit>` = der **volle** SHA. **Kein freier Zusatztext** und **kein Wanduhr-Wert** im `log.md`-Body (der Wanduhr-Wert lebt ausschließlich im Frontmatter-`generated.at`, §5.14 Pkt. 3-Ausnahme) — der Eintrag ist **byte-deterministisch** aus dem committeten Git-State + dem kanonischen Eingabeset (§5.14 Pkt. 2) ableitbar. Das Synthese-**Update** folgt der kanonischen Update-Form von §5.9 Pkt. 4 (`Story 3.1-Update`, Revision 3.8).
|
||||
8. **Erhaltungs-Invariante & Determinismus-Vertrag (AD-17h/A0-19):** Der **§5.9-Pkt.-5-Diff-Selbsttest gilt für Synthese-Runs unverändert**: die mutierten/neu angelegten Pfade sind eine Teilmenge von (Kandidatenliste ∪ Neu-Anlage-Zielpfade ∪ `log.md` ∪ nachgeführte `index.md`) — **keine neue Datei außer echten Ziel-Pfaden** (Duplikat-Kontrolle via `??`-Sicht, `git status --porcelain -- wiki/`). Gleicher Git-State + gleiche Eingabemenge → identischer Synthese-Vorgang (Ziel-Pfad via §3.2/§5.7, `sources`-Liste lexikografisch nach `resource` LC_ALL=C, Konsolidierung und Form-Zuordnung wie Pkt. 3/6); der `generated.at`-Wanduhr-Gap (gleiches Eingabeset, unabhängige Runs, verschiedene `at`) bleibt offene A0-20-Konvention mit Home **Story 3.8** (§5.9 Pkt. 2, `generated.at`-Konvention) — unverändert bindend. **Duplikat-Fall (Synchronisation zwischen Concepts und Evidenzbasis):** ein `raw/`-Quellpfad erscheint **nur einmal** in einer `sources`-Liste — ein bestehender Eintrag derselben `resource` wird **nicht** doppelt angelegt (die Neuanlage eines Synthese-Concepts setzt voraus, dass kein bestehendes Concept dieselbe Quelle bereits mit derselben Stellen-Kennung als Beleg nutzt; für Update-Fälle gilt das §5.9-Pkt.-2-Prinzip „bestehende Einträge bleiben unverändert" — der Zuwachs einer Quelle, die bereits existiert, wird niemals doppelt eingetragen). **Unzugeordnete/verwaiste Evidenz (Orphan-Kontrolle, pre-existing — dokumentiert den Vertrag, wie er vor dieser Story bestand):** neu committete `raw/`-Evidenz ohne Ziel-Pfad-Treffer bleibt **unzugeordnet** (weder still getilgt noch hintenherum als eigenes Concept angelegt) und wird in `log.md` als verwaist protokolliert — kein Banner/keine stille Vorbearbeitung; eine Präzisierung der Reconcile-Orphan-Politik leistete die Verankerung in §5.13-Phase 5 / **die deterministische Reconcile-Orphan-Regel unten (Story 3.8; §5.14 Pkt. 5)** — eine Staffelung an Epic-4 (Story 4.1) bleibt für die Verwaist-Klassifikation offen. **Deterministische Reconcile-Orphan-Regel (Story 3.8; §5.14-Präzisierung):** der Verwaist-Befund — neu committete `raw/`-Evidenz ohne jeglichen Ziel-Pfad-Treffer (kein Update-Kandidat nach §3.2, keine Synthese-Zuordnung nach Pkt. 1–7, kein §5.7-Neu-Anlage-Ziel-Pfad) — wird deterministisch aus dem committeten Git-State erhoben (Zuwachs gg. `<Baseline-Commit>`, §5.9 Pkt. 6 R-1) und als **datumsgruppierter `log.md`-Eintrag** verwaist protokolliert (Header `YYYY-MM-DD`, neueste zuerst — Vertrag-§5-Datumsgruppe; Quell-Pfad + `<Baseline-Commit>`); **kein Banner**, **keine stille Vorbearbeitung**, **keine** eigenständige Concept-Anlage aus verwaister Evidenz (AD-16-Default: Erhaltung — die Evidenz bleibt in `raw/` unangetastet, AD-3; keine Korrektur-/Erweiterungs-Klassifikation hier vorweggenommen — Epic-4-Interface, Story 4.1). **Präzisierung (Review-Loop-3, D-4):** die obige „Staffelung an Epic-4 (Story 4.1)" betrifft ausschließlich die **Korrektur-/Erweiterungs-Klassifikation** verwaister Evidenz (Epic-4-Interface, Story 4.1); der **Hold selbst** (Erhaltung der unzugeordneten `raw/`-Evidenz im benannten Hold ohne Wissensmutation, NFR-7) hat seinen Home in **Story 3.10 (Epic 3)** und ist in **§5.16** dieser Instruktion verankert (Story 3.10, Hold-Ausbau: post-Reconcile-Orphan über alle Erhebungs-Stufen a/b/c, Mehrziel-Auflösung, benannter Hold mit beiden Evidenzpfaden im Run-Receipt) — die Reconcile-Orphan-Regel dieses Bullets ist die deterministische Verankerung dieses Holds in der Instruktion. Gleicher Git-State + gleiche Eingabemenge ⇒ identischer Verwaist-Befund und identischer `log.md`-Eintrag (AD-17h/A0-19, §5.14).
|
||||
|
||||
## 5.11 Leasing & Dirty-Tree-Schutz für konkurrierende Producer (Story 3.5)
|
||||
@@ -541,3 +541,8 @@ Diese Instruktion ist auf die **Erzeugung neuer Concepts auf Root-Ebene und in A
|
||||
- **Revision 3.5 (2026-08-21, Story 3.10):** Neue Sektion **§5.16 „Inkrementelle Update- & Synthese-Erhaltung + Hold-Ausbau (Story 3.10)"** eingefügt (nach §5.15, vor §6) — die **operationelle Erhaltungs-Klammer** über den textuell unveränderten §5.9/§5.10/§5.15-Mechaniken (D-3, Story 3.10; A0-21-Incrementality-Teil, FR-4/FR-6/FR-12, AD-4/AD-5; §5.15-Zelle-3-/§5.15-Scope-Präzisierung-/§5.10-Pkt.-8-D-4-Hold-Home hierin verankert): (1) **Kontinuitäts-Garantie** (AC-1; in-place Update/Synthese, kein Duplikat, Identität + Index-Link erhalten), (2) **Korrigieren mit Run-Receipt-Trace** (AC-2; ersetzte Wortlautfolge + Source-Basis im Run-Receipt außerhalb des Bundles, §5.14 Pkt. 2; mehrdeutig → benannter Hold Epic 4), (3) **Schutzbestandteile & Byte-Identität** (AC-3; gültige belegte Aussagen, §5.5-Inline-Verweise, `sources` gültiger Belege, §5.6-Links, human-`verified` bleiben erhalten; nicht betroffene Concepts byte-identisch, §5.9 Pkt. 5), (4) **CONFIRMING-Konsolidierung** (AC-4; bestätigende neue Source mit neuem Evidenzanker → Aussage genau einmal, alle Anker via §5.5-Multi-Beleg, `sources`-Zuwachs, `at`-Bump, **kein NO_OP** — Stellen-Abgleich auf den Anker, nicht auf den Inhalt), (5) **gemeinsame Wissensrepräsentation als Synthese-Erhaltung** (AC-5; §5.10-Pkt.-2/3/5, Update auf bestehendes Concept = Erweiterung, keine Neuschreibung), (6) **byte-erhaltender NO_OP** (AC-6; nur bei vollständig identischer Evidenz **samt vollständiger Evidenzanker-Menge** — kein `at`-Bump, kein `sources`-Zusatz, kein `log.md`-Eintrag; fehlender Anker → Pkt. 4), (7) **Provenienz- & Link-Selbsttest aus aktuellem Run** (AC-7; Baseline = `<Baseline-Commit>` des aktuellen Runs, erwartete Delta-Menge = Kandidatenliste ∪ Neu-Anlage ∪ `log.md` ∪ nachgeführte `index.md`; kein historischer Commit/globaler Zählwert normativ), (8) **benannter Hold** (AC-8/NFR-7; post-Reconcile-Orphan über **alle** Erhebungs-Stufen a/b/c — die Story-3.9-Sandbox übte nur Stufe a (§5.15-Pkt.-6-Scope-Präzisierung aufgegriffen) —, Mehrziel-Auflösung via D-8-Mehrfach-Term-Vereinigung auf eine primäre Ziel-Repräsentation, sonst fail-closed Hold; widersprüchliche/klassifikationspflichtige Evidenz ohne Wissensmutation; beide Evidenzpfade im Run-Receipt). **§5.15:** Zelle-3-Zeile und Scope-Präzisierung auf die §5.16-Verankerung nachgeführt („in §5.16 verankert, Story 3.10"). **§5.10 Pkt. 8:** D-4-Bullet um die §5.16-Verankerung des Hold selbst ergänzt (Hold-Ausbau: Stufen a/b/c, Mehrziel, benannter Hold). **§7:** Relevanzbestimmung-Bullet um die **Story-3.10-Verankerung** erweitert (§5.16; bestehende Story-Bullets unverändert). **AD-16-Klassifikation/semantische Auflösung bleibt Epic 4.** **Abschlussklausel (Story 3.10):** Keine Änderung an `schema/wiki-compiler.md`/`schema/validator.md`/`adapters/`/`raw/` (AD-3); **keine neue §7-Invaliditätsklasse**; **keine fünfte Update-/Routing-Form**; die §5.9-Abgrenzungs-Reihenfolge `Korrigieren → Präzisieren → Erweitern → No-Op` bleibt die **einzige** Form-Wahl (textuell unverändert); **kein Standalone** (D-3); keine Vertragsänderung; **kein neuer Prädikat-/Format-/Frontmatter-Key**; `schema/canonical-terms.md` unverändert (kein neuer Normalisierungs-Operand — Umlaut-vs-Transkription bleibt benannter Defer, Ask-First); Commit-Boundary-Regel unverändert; `generated.at`-Verhalten unverändert (A0-20-Konvention). **`sprint-status.yaml`:** Key `3-10-inkrementelle-update-und-synthese-erhaltung-absichern` auf **`review`** geflippt (Implementierungs-Commit; finaler `done`-Flip im Step-05-Status-Sync nach abgeschlossenem Review-Loop — Präzedenz Revision 3.2/3.3/3.4). Sandbox-Nachweis (**E-1..E-9, Exit 0**; CONFIRMING ≠ NO_OP byte-bewiesen, NO_OP byte-erhaltend, Korrigieren-Receipt-Trace, aktueller-Run-Selbsttest, Orphan über Stufe-a/b/c, Mehrziel-Konsolidierung/-Hold, Zwei-Run-Identität nicht-vakuum) und per-Datei-Validator-Verdikt siehe `wiki/log.md`-Eintrag (Story 3.10, Revision 3.5).
|
||||
- **Revision 3.6 (2026-08-21, Story 3.11):** Neue Sektion **§5.17 „Atomare Root-Scope-Lease-Akquise (Story 3.11)"** eingefügt (nach §5.16, vor §6) — die **operationelle Atomaritäts-Präzisierung der Root-Scope-Akquise** über der textuell unveränderten §5.11-/§5.12-Mechanik (D-3, Story 3.11; AD-17b/A0-13; §5.11 Pkt. 1/2 und §5.12-Anker sind Fugen-Identität, Revision 3.6): (1) **Exklusivitätsschlüssel = scope-bezogener Lock im clone-geteilten Zustand** (AC-a; der geteilte Git-Ref-/Objektnamespace ist der einzige von allen Worktrees/Prozessen eines Clones gemeinsam gesehene Zustand; eine deterministisch benannte, committete Ref je Root-Scope `wiki/`, z. B. `refs/leases/wiki`; die **Run-ID ist Lock-Inhalt und nicht Bestandteil des Exklusivitätsschlüssels** — der Ref-Name trägt keine Run-ID; die bisherige `<id>`-Ablage §5.11 Pkt. 1 bleibt per-Lease-Ablage ohne alleinige Exklusivität), (2) **atomare Akquise (create-only) — genau ein Gewinner** (AC-b; `git update-ref <lock-ref> <wert> $ZERO_SHA` schlägt fehl, sobald der Ref existiert, und berührt einen existierenden Lock nicht; gits Ref-Sperre serialisiert zwei Worktrees/Prozesse desselben Clones; **Ask-First-Pflicht**: nicht sicher atomar belegbar auf Windows/Git-Bash → HALT, Alternativ-Primitiv zur Autorisierung), (3) **`LEASE_HOLD`-Semantik** (AC-c; abgewiesener Producer verändert weder `wiki/` noch den Lock, erzeugt keinen Compilation Commit, entfernt keine fremde Lease, beendet sauber, AD-16-Pfad), (4) **Determinismus** (AD-17h/A0-19; clone-geteilter Zustand = eindeutige Gewinner-/Verlierer-Entscheidung; Lock-Inhalt dokumentierender Ablage-Wert, kein Schlüsselbestandteil), (5) **Kollisions-Hold an Epic 4** (AC-e/AD-17c/A0-14; kein textueller Auto-Merge, strukturierter Kollisions-Hold mit beiden Commit-Hashes und Scope an Epic 4 via §5.16-Pkt.-8-/§5.10-Pkt.-8-Hold-Mechanik; AD-16-Klassifikation bleibt Epic 4; Commit-Boundary = Mutations-Boundary und `log.md`-Eintragspflicht unverändert), (6) **Abgrenzung** (keine Wanduhr/Systemzeit A0-20, keine Staleness-/Recovery-Logik — bleibt §5.12/Story 3.6 und Story 3.12 —, keine Verwaist-/Stale-Behandlung/kein Branch-Lifecycle nach Übernahme — Story 3.12). **§7:** Leasing-Bullet um die **Story-3.11-Verankerung** erweitert (§5.17; bestehende Story-Bullets unverändert). **§8:** AD-17b/A0-13 bleiben über die bestehende §5.11-Zuordnung verankert — §5.17 referenziert sie (Fugen-Identität). **Abschlussklausel (Story 3.11):** Keine Änderung an `schema/wiki-compiler.md`/`schema/validator.md`/`adapters/`/`raw/` (AD-3); **keine neue §7-Invaliditätsklasse**; **kein neuer Frontmatter-Key für Lease-Metadaten** (Vertrag §3.1–§3.7 unverändert); **kein neuer Prädikat-/Format-Key**; **kein Standalone** (D-3); keine Vertragsänderung; §5.11-Pkt.-1/2-Wortlaut und §5.12-Anker **textuell unverändert** (additive Präzisierung, Fugen-Identität); keine Wanduhr/Systemzeit (A0-20); keine Staleness-/Recovery-Logik (Story 3.6/3.12); Commit-Boundary-Regel unverändert; AD-16-Klassifikation bleibt Epic 4. **`sprint-status.yaml`:** Key `3-11-root-scope-leasing-atomar-akquirieren` auf **`review`** geflippt (Implementierungs-Commit; finaler `done`-Flip im Step-05-Status-Sync nach abgeschlossenem Review-Loop — Präzedenz Revision 3.2/3.3/3.4/3.5). Sandbox-Nachweis (**A-1..A-8, Exit 0**; Zwei-Worktree-/Zwei-Prozess-Überlappung mit Zwischenzustands-Sampling („niemals zwei aktive Root-Leases" **konstruktiv belegt** — eine scope-bezogene Ref + atomarer create-only-Write, keine zwei Refs/Werte im Überlappungs-Fenster), `LEASE_HOLD`-Nicht-Mutation, Kollisions-Hold mit beiden Commit-Hashes) und per-Datei-Validator-Verdikt siehe `wiki/log.md`-Eintrag (Story 3.11, Revision 3.6).
|
||||
- **Revision 3.7 (2026-08-21, Story 3.12):** Neue Sektion **§5.18 „Lease-Lifecycle & transaktionaler Commit-Abschluss (Story 3.12)"** eingefügt (nach §5.17, vor §6) — die **geschlossene, transaktionale Lifecycle-Klammer** der Koordinations-Dimension über der textuell unveränderten §5.11-/§5.12-/§5.13-/§5.17-Mechanik (D-3, Story 3.12; AC-1..AC-7; A0-20 — keine Wanduhr-/Systemzeit-Steuerung, Lifecycle deterministisch aus dem committeten Git-State, AD-17h/A0-19; §5.17-Pkt.-1-Z. 419-„Lifecycle-Regie Story 3.12" und Pkt.-6-Z. 424-„bleibt Story 3.12" sind die Anschluss-Sutur, Fugen-Identität): (1) **Liveness & Ownership** (AC-1; eine höhere Generation allein macht eine lebende Lease nicht stale — Staleness verlangt bestätigten Abbruch oder abgelaufene Liveness plus atomare Ownership-Prüfung; kein Wanduhr-TTL, A0-20), (2) **stale-Übernahme genau einmal** (AC-2; ownership-gebunden über den §5.17-Scope-Lock, ersetzte Holder-ID im `log.md` benannt, genau eine aktive Root-Lease, nie still gelöscht — AD-17e), (3) **eindeutige Abort-/Protect-Zustandsmaschine** (AC-3; getrackte fremde Änderung → Scratch-Zone `scratch/<run-id>/` oder `git stash push`, ungetrackte fremde Datei → Protect, byte-identischer Restore, `UNCOMMITTED_INPUT`-Abbruch abgestimmt §5.11 Pkt. 3, nie gelöscht), (4) **Baseline-Rollback Index + Worktree** (AC-4; `git reset --hard <Baseline-Commit>`, Post-Rollback-Diff gg. Baseline leer, §5.13 Pkt. 3), (5) **durable Release** (AC-5; Mutation + zulässiger Log-/Koordinationsnachweis committet, Lock per Ref-Delete nur durch Inhaber, Worktree sauber, Clean-Input-Guard — Folge-Run ohne `INPUT_UNCOMMITTED`-Abbruch; Release-Fehler = HARD-FAIL), (6) **kanonisches Log** (AC-6; `wiki/log.md` nur vertragskonforme fachliche + notwendige Koordinationsereignisse, Build-/Review-/Story-/Sandbox-Historie außerhalb), (7) **Kill-Point-Tests** (AC-7; vor Mutation/nach Mutation/vor Commit/nach Commit je konsistenter Endzustand, §5.13-Pkt.-3-Zustands-Restaurations-Invariante). **§7:** Leasing-Bullet um die **Story-3.12-Verankerung** erweitert (§5.18; bestehende Story-Bullets unverändert). **§8:** AD-17b/A0-13/A0-15/A0-16-/AD-17e/f-Anker bleiben über die bestehende §5.11-/§5.12-Zuordnung verankert — §5.18 referenziert sie (Fugen-Identität). **Abschlussklausel (Story 3.12):** Keine Änderung an `schema/wiki-compiler.md`/`schema/validator.md`/`adapters/`/`raw/` (AD-3); **keine neue §7-Invaliditätsklasse**; **kein neuer Frontmatter-/Format-Key** (Vertrag §3.1–§3.7 unverändert); **kein Standalone** (D-3); keine Vertragsänderung; §5.11-Pkt.-1-7-/§5.12-Pkt.-1-7-/§5.13-/§5.17-Wortlaute **textuell unverändert** (additive Präzisierung, Fugen-Identität); keine Wanduhr/Systemzeit (A0-20, keine TTL über Kalenderzeit); keine stille Löschung fremder uncommitteter/geschützter Änderungen (AD-17e); keine Wissensmutation bei Orphan/Hold (AD-16-Default); kein textueller Auto-Merge (AD-17c); `generated.at`-Verhalten unverändert; Commit-Boundary-Regel unverändert; AD-16-Klassifikation bleibt Epic 4. **`sprint-status.yaml`:** Key `3-12-lease-lifecycle-und-commit-abschluss-transaktional-schliessen` auf **`review`** geflippt (Implementierungs-Commit; finaler `done`-Flip im Step-05-Status-Sync nach abgeschlossenem Review-Loop — Präzedenz Revision 3.2/3.3/3.4/3.5/3.6). Sandbox-Nachweis (**L-1..L-9, Exit 0**; Lifecycle-Zustandsmaschine, Abort-/Protect-Zustandsmaschine getrackt/ungetrackt byte-identisch, Baseline-Rollback Index+Worktree mit leerem Post-Rollback-Diff, Kill-Point-Tests an vier Punkten, durable Release + Clean-Input-Guard, stale-Übernahme genau einmal) und per-Datei-Validator-Verdikt siehe `wiki/log.md`-Eintrag (Story 3.12, Revision 3.7).
|
||||
- **Revision 3.8 (2026-08-23, Story 3.13, Epic-1-Remediation — D-3-Instruktions-Patch, autorisiert; additive Präzisierung der `log.md`-Eintragsform, kein Re-Negotiation des Bestehenden):** **Kanonische, byte-deterministische `log.md`-Eintragsform** fixiert, um den Determinismus-Vertrag §5.14/AD-17h (Zwei-Run-Identität) im `log.md`-Body zu erfüllen — der A/B-Vergleich (Story 3.13 E.4) verlangt **byte-identische** Bundle-State-Bestandteile außerhalb der benannten `at`-Ausnahme (§5.14 Pkt. 3), während die bisherige `log.md`-Eintragspflicht („verknüpft mit dem Concept-Pfad und den Quellen", ohne Wort-Pin) zwei unabhängige Läufe mit **freiem Zusatztext** erlaubte (Update-Typ-Erklärung, §-/Pkt.-Referenzen, Beleg-Stellen-Kennungen, Wanduhr-`generated.at` im Body, Eintragsreihenfolge) — jede dieser Freiheiten erzeugt eine NON_AT-Differenz und damit einen AD-16-Klassifikationsdefekt. Die gepinnte Form (in **§5.9 Pkt. 4** Update, **§5.1 Pkt. 4** Anlage, **§5.10 Pkt. 7** Synthese-Neu-Anlage) ist:
|
||||
- **Update:** `- Story 3.1-Update: <concept> (<neue-Quellen>; Baseline <Baseline-Commit>)`
|
||||
- **Anlage:** `- Anlage: <concept> (<quellen>; Baseline <Baseline-Commit>)`
|
||||
- **Synthese-Neu-Anlage:** `- Synthese-Anlage: <concept> (<quellen>; Baseline <Baseline-Commit>)`
|
||||
mit `<concept>` = relative OKF-Identität **ohne** `.md` (ohne Backticks, ohne Zusatz-Labels wie `neu:`); `<quellen>`/`<neue-Quellen>` = die (neu) genutzten `raw/`-Quellen **lexikografisch (LC_ALL=C) sortiert**, per ` + ` getrennt (eindeutig aus der Zuwachs-Sicht, §5.9 Pkt. 6 R-1); `<Baseline-Commit>` = **voller** SHA (R-1); die `## YYYY-MM-DD`-Datumsgruppe (neueste zuerst) ist Teil der Form und wird über den Eintrag gehoben. **Kein freier Zusatztext** und **kein Wanduhr-Wert** im `log.md`-Body — der Wanduhr-Wert lebt **ausschließlich** im Frontmatter-`generated.at` (§5.14 Pkt. 3-Ausnahme), nie im `log.md`-Body. Damit ist jeder Eintrag **byte-deterministisch** aus dem committeten Git-State + dem kanonischen Eingabeset (§5.14 Pkt. 2) ableitbar: zwei unabhängige Runs desselben Git-States + desselben Eingabesets liefern **byte-identische** `log.md`-Einträge (identische Datumsgruppe, identische Werte). Die Form ist diejenige, die die Sandbox-Sub-Runs 3-3/3-4 **mechanisch bereits demonstrieren** (`- Story 3.1-Update: <concept> (<quellen>; Baseline <SHA>)`, `- Synthese-Anlage: <concept> (<quellen>; Baseline <SHA>)`), nun als normative Instruktion fixiert — kein Widerspruch, sondern Verankerung des Ist-Behaviours. **Nicht geändert:** §5.14 Pkt. 3 (die `at`-Ausnahme bleibt **ausdrücklich** die `generated.at`/`verified[].at`-Feldwerte — der `log.md`-Body-Wanduhr-Verbot ist eine Folge davon, keine Änderung der Ausnahme-Menge), §5.10 Pkt. 3 (CREATE/Synthese-Body-Wortung bleibt „Befund-Äquivalenz, nicht Wort-Identität" — der Pin betrifft **nur** den `log.md`-Eintrag, **nicht** den Concept-Body), §5.1 Pkt. 2 (FR-2 „eigenständig formuliert" — der Body bleibt eigenständig formuliert, der `log.md`-Eintrag ist Buchführung, kein Body), die §5.9-/§5.10-Regeltexte oberhalb der Pins (textuell **unverändert**; der Pin ist ein additiver Sub-Regeltext). **Slug-/Term-Ableitung (CREATE-Zielpfad):** **nicht** in dieser Revision geändert — der CREATE-Slug-Ableitungsmechanismus (§5.15 Pkt. 1 Dateiname→Term, §5.7-Ziel-Pfad) bleibt wie ist; die Story-3.13-E.4-A/B-Prüfung deckt den **Update-/Erhaltungs-Kern** (D-3.13-6 Option 2), der CREATE-/Synthese-Kern gilt über die Sub-Runs 3-3/3-4 als demostriert. Ein CREATE-Zielpfad-Signal-Pin (Inhalts-Term maßgeblich vs. Dateiname-Stamm) bleibt **offener Defer** (Ask-First-Kandidat für eine künftige Revision, nicht Teil dieser Remediation). **Abschlussklausel:** Keine Änderung an `schema/wiki-compiler.md`/`schema/validator.md`/`adapters/`/`raw/` (AD-3); **keine neue §7-Invaliditätsklasse**; **kein Standalone** (D-3); keine Vertragsänderung; **kein neuer Prädikat-/Format-/Frontmatter-Key**; das `generated.at`-Verhalten selbst **unverändert** (nur: kein Wanduhr-Wert im `log.md`-Body — eine Folge der §5.14 Pkt. 3-Ausnahme, kein Verhaltenswechsel); keine Workflow-Engine (AD-6, AD-11); Commit-Boundary-Regel unverändert. **`sprint-status.yaml`:** Story 3.13 bleibt **`in-progress`** (Remediation durchgeführt; Abschluss-Flip `done` erfolgt im Step-05-Status-Sync nach grünem Re-Run #6).
|
||||
|
||||
Reference in New Issue
Block a user