Compare commits
| Author | SHA1 | Date | |
|---|---|---|---|
|
|
fae648e688 | ||
|
|
9b256fa5ad | ||
|
|
52f88fdc5f | ||
|
|
3aa484b2f4 |
@@ -2,6 +2,33 @@
|
|||||||
|
|
||||||
Noch nicht adressierte, aber real erkannte Arbeit — gesammelt aus Reviews. Einträge werden append-only ergänzt; bestehende Einträge werden nicht verändert.
|
Noch nicht adressierte, aber real erkannte Arbeit — gesammelt aus Reviews. Einträge werden append-only ergänzt; bestehende Einträge werden nicht verändert.
|
||||||
|
|
||||||
|
## Deferred from: code review of spec-3-3-bestehende-concepts-erweitern-präzisieren-korrigieren (Story 3.3, 2026-08-19)
|
||||||
|
|
||||||
|
- source_spec: `_bmad-output/implementation-artifacts/spec-3-3-bestehende-concepts-erweitern-präzisieren-korrigieren.md`
|
||||||
|
summary: **`sprint-status.yaml last_updated`-Präzisions-Regression** — die Story-3.3-Sprint-Sync hat `last_updated` von `08-19-2026 13:14` (mit Uhrzeit, HEAD-Stand) auf reines Datum `08-19-2026` reduziert; die Pre-3.3-Konvention hielt die `HH:MM`-Granularität. Das Verhalten ist eine General-Eigenschaft des sync-sprint-status-Shared-Sub-Steps (Schritt-06), keine Story-3.3-Inhaltsentscheidung. Home: nächstes Sprint-Sync (Step-06) oder Sync-Verbesserung, die `last_updated` aus dem Zeitstempel ableitet.
|
||||||
|
evidence: `git show HEAD:_bmad-output/implementation-artifacts/sprint-status.yaml` → `last_updated: 08-19-2026 13:14` vs. Working Tree `08-19-2026` (Step-04-Review 2026-08-19, Verification-Gap-Layer, re-executiert verifiziert).
|
||||||
|
status: offen
|
||||||
|
|
||||||
|
- source_spec: `_bmad-output/implementation-artifacts/spec-3-3-bestehende-concepts-erweitern-präzisieren-korrigieren.md`
|
||||||
|
summary: **Frozen Story-3.1-No-Op-Bullet trägt die Typos „Schärferung" und „Formata"** — `schema/compiler.md` §5.9 Pkt. 2 (No-Op, `:267`): „keine Schärferung" (inkonsistent zur konsistenten „Schärfung" der neuen operationellen Ebene) und „keiner der drei Formata" (→ „Formate"). Beide sitzen im **frozen** Story-3.1-Text (HEAD-identisch, nicht durch Story 3.3 eingeführt), den die Story-3.3-Operationelle-Ebene operationalisiert; ein fix wäre Re-Negotiation des frozen Textes (Ask-First). Home: nächste Compiler-Instruktions-Revision, die §5.9 Pkt. 2 ohnehin berührt.
|
||||||
|
evidence: `git show HEAD:schema/compiler.md` `:267` (frozen): „keine Schärferung, keine Ersetzung … keiner der drei Formata greift" — Step-04-Review (2026-08-19, Verification-Gap-Layer), via `git show` verifiziert.
|
||||||
|
status: offen
|
||||||
|
|
||||||
|
- source_spec: `_bmad-output/implementation-artifacts/spec-3-3-bestehende-concepts-erweitern-präzisieren-korrigieren.md`
|
||||||
|
summary: **U6-Zwei-Run-Identitäts-Nachweis überzeichnet „auch nach Commit" und kreuzreferenziert den `generated.at`↔AD-17h-Gap nicht** — der Claim „identische SHA-256 … auch nach Commit" gilt für alpha.md (reproduzierbar `6b148dd1…`) im Worktree-/Staged-Zustand; `wiki/log.md` embeddet den random `$BASE`-SHA (`log_update`), daher weicht der log.md-Hash je Run ab (konstruktionsbedingt — der Commit ist die jeweilige Mutations-Boundary). Der at↔AD-17h-Gap (gleiche Evidenz, zwei Runs → verschiedene `at`) ist in compiler.md offen verankert. Home: Story 3.8 (Determinismus-Vertrag, AD-17h — Behandlung von `at` und des Bundle-State-Vergleichs).
|
||||||
|
evidence: Step-04-Review (2026-08-19, Verification-Gap-Layer): Sandbox-Doppellauf — alpha.md SHA `6b148dd1…` reproduzierbar, log.md SHA je Lauf verschieden (`89b82cb2…`, `358bad3b…`); compiler.md at↔AD-17h-Hinweis (generated.at-Konvention).
|
||||||
|
status: offen (Home: Story 3.8)
|
||||||
|
|
||||||
|
- source_spec: `_bmad-output/implementation-artifacts/spec-3-3-bestehende-concepts-erweitern-präzisieren-korrigieren.md`
|
||||||
|
summary: **Sandbox-U2-Szenario ist selbst-erfüllend und U7 misst die reale REIHENFOLGE nicht** — U2 schärft durch Hinzufügen einer neuen Faktenbehauptung (neue Stelle), die nach dem Erweitern-Kriterium Erweitern wäre, und passt nur, weil das Präzisieren-Wording hartkodiert ist; die Form-Wahl-Prozedur selbst wird nicht geprüft. U7 begründet „v2 vor v3" als „lexikografischer Tie-Break", obwohl v2/v3 verschiedene Dateien sind (Tie-Break gilt nur bei identischem Ort); der Fall „R-1-Dateiordnung ≠ lexikografische Ordnung" bleibt ungetestet. Kein Instruktions-Defekt (Abgrenzungs-Reihenfolge ist jetzt deterministisch fixiert), sondern Test-Eigenschaften-Hinweis. Home: nächste Sandbox-Erweiterung (Story 3.4/3.5) — eine Form-Wahl-Klassifikationsprobe + U7-Ordnungs-Variante mit nicht-lexikografischer R-1-Reihenfolge.
|
||||||
|
evidence: Step-04-Review (2026-08-19, Blind-Hunter + Verification-Gap-Layer): `run-sandbox.sh` U2 (neue Faktenbehauptung via `sed`, hartkodiertes Präzisieren-Wording), U7 (Ordering-Rationale vs. `compiler.md:268` REIHENFOLGE-Definition — Zuwachs-Sicht, lexikografisch nur bei identischem Ort).
|
||||||
|
status: offen
|
||||||
|
|
||||||
|
- source_spec: `_bmad-output/implementation-artifacts/spec-3-3-bestehende-concepts-erweitern-präzisieren-korrigieren.md`
|
||||||
|
summary: **Gemischte Normalisierungs-Politik im Sandbox-Evidenztext (Umlaute vs. Transkriptionen) ist ein Determinismus-Hazard für den Term-Abgleich** — Sandbox-Bodies nutzen Umlaut-Schreibweisen („Schlüssel", „läuft"), raw-Evidenz transkribiert („Schluessel"); die Abgrenzungskriterien beruhen auf Term-/Stellen-Abgleichen gegen §5.5-Inline-Verweise, und die §3.2-Normalisierung (lowercasing + `[-–_ ]`-Kollaps) deckt Umlaut-/Em-Dash-Divergenzen nicht. Bekannte Story-3.2-Lücke (Em-Dash, Home Story 3.8) plus Sandbox-interne Divergenzen. Home: Story 3.8 (Determinismus-Vertrag, Normalisierungs-Vollständigkeit) oder Sandbox-Vereinheitlichung in einer Folge-Story.
|
||||||
|
evidence: Step-04-Review (2026-08-19, Verification-Gap-Layer): `run-sandbox.sh` — U1/U2/U3/U7 Body mit Umlaut-Schreibweisen vs. raw-Evidenz mit Transkriptionen; §3.2-Pkt.-1b-Kollaps-Klasse ohne Umlaut-/Em-Dash.
|
||||||
|
status: offen (Home: Story 3.8)
|
||||||
|
|
||||||
- source_spec: `_bmad-output/implementation-artifacts/spec-1-2-sources-lokal-unter-raw-bereitstellen.md`
|
- source_spec: `_bmad-output/implementation-artifacts/spec-1-2-sources-lokal-unter-raw-bereitstellen.md`
|
||||||
summary: Checksum-/Fingerprint (SHA-256) der evtl. Git-Revision der Herkunftsquelle in `source.md` aufnehmen, damit die Provenienz reproduzierbar ist.
|
summary: Checksum-/Fingerprint (SHA-256) der evtl. Git-Revision der Herkunftsquelle in `source.md` aufnehmen, damit die Provenienz reproduzierbar ist.
|
||||||
evidence: Blind-Hunter-Review (Finding 1/2): `source.md`-Provenienz ist ohne Fingerprint der Quelle in einem reinen Clone nicht verifizierbar; AD-3-basiertes „neue, datierte Datei"-Schema braucht einen Maschinen-Lesbaren Stand.
|
evidence: Blind-Hunter-Review (Finding 1/2): `source.md`-Provenienz ist ohne Fingerprint der Quelle in einem reinen Clone nicht verifizierbar; AD-3-basiertes „neue, datierte Datei"-Schema braucht einen Maschinen-Lesbaren Stand.
|
||||||
@@ -65,7 +92,7 @@ Noch nicht adressierte, aber real erkannte Arbeit — gesammelt aus Reviews. Ein
|
|||||||
|
|
||||||
- source_spec: `_bmad-output/implementation-artifacts/spec-1-4-schema-validierung-für-bundle-implementieren.md`
|
- source_spec: `_bmad-output/implementation-artifacts/spec-1-4-schema-validierung-für-bundle-implementieren.md`
|
||||||
summary: Genau-eine-erlaubte-Linkform für den Punkt-11-Index-Check festlegen (mit vs. ohne `.md`-Endung) — Story 2.3.
|
summary: Genau-eine-erlaubte-Linkform für den Punkt-11-Index-Check festlegen (mit vs. ohne `.md`-Endung) — Story 2.3.
|
||||||
evidence: Step-04-Review (Story 1.4, Loop 1): Der Validator-Punkt-11-Check akzeptiert beide Linkformen (relativer Bundle-Pfad mit oder ohne `.md`-Endung), weil die genau-eine-Form-Regel (A0-9/AD-7b) erst Story 2.3 definiert. Der Determinsmus-Anspruch des Validators bleibt gewahrt (beide Formen zählen als verlinkt); eine Endungs-Festlegung würde die abschließende §7-Liste erweitern und gehört in Story 2.3.
|
evidence: Step-04-Review (Story 1.4, Loop 1): Der Validator-Punkt-11-Check akzeptiert beide Linkformen (relativer Bundle-Pfad mit oder ohne `.md`-Endung), weil die genau-eine-Form-Regel (A0-9/AD-7b) erst Story 2.3 definiert. Der Determinismus-Anspruch des Validators bleibt gewahrt (beide Formen zählen als verlinkt); eine Endungs-Festlegung würde die abschließende §7-Liste erweitern und gehört in Story 2.3.
|
||||||
status: umgesetzt (2026-08-17, Story 2.3) — Linkform in `schema/compiler.md` §5.6 gepinnt (bundle-relativ **mit** `.md`-Endung; Rationale: Null-Migration der 3 Concept-Links in `wiki/index.md`, explizite Datei-Ziele, Standard-Markdown-Tools — AD-7b/A0-9/FR-10/AD-8) inkl. vier re-executierbarer Selbsttest-Formeln (AD-17h). Der Validator bleibt strukturell unverändert (Punkt 11 akzeptiert beide Schreibweisen — Story-2.2-Präzedenz, D-3); die konsistente Nachführung der „Story 2.3"-Notizen in `schema/validator.md` (Punkt 11, §8) bleibt Rev-9-Kandidat (Eintrag unten).
|
status: umgesetzt (2026-08-17, Story 2.3) — Linkform in `schema/compiler.md` §5.6 gepinnt (bundle-relativ **mit** `.md`-Endung; Rationale: Null-Migration der 3 Concept-Links in `wiki/index.md`, explizite Datei-Ziele, Standard-Markdown-Tools — AD-7b/A0-9/FR-10/AD-8) inkl. vier re-executierbarer Selbsttest-Formeln (AD-17h). Der Validator bleibt strukturell unverändert (Punkt 11 akzeptiert beide Schreibweisen — Story-2.2-Präzedenz, D-3); die konsistente Nachführung der „Story 2.3"-Notizen in `schema/validator.md` (Punkt 11, §8) bleibt Rev-9-Kandidat (Eintrag unten).
|
||||||
|
|
||||||
- source_spec: `_bmad-output/implementation-artifacts/epic-1-retro-2026-08-15.md`
|
- source_spec: `_bmad-output/implementation-artifacts/epic-1-retro-2026-08-15.md`
|
||||||
@@ -81,7 +108,7 @@ Noch nicht adressierte, aber real erkannte Arbeit — gesammelt aus Reviews. Ein
|
|||||||
evidence: Retrospective F-04.
|
evidence: Retrospective F-04.
|
||||||
|
|
||||||
- source_spec: `_bmad-output/implementation-artifacts/epic-1-retro-2026-08-15.md` (F-06)
|
- source_spec: `_bmad-output/implementation-artifacts/epic-1-retro-2026-08-15.md` (F-06)
|
||||||
summary: `today`-Zeitzone für die `stale_after`-WARN (Validator §6.4) deterministisch festlegen — „heute in UTC abgeleitet" ist nicht hart definiert (Kalenderdatum des UTC-Zeitpunkts vs. lokaler Tag). Determinsmus-Anspruch (AD-17h) vor Epic-3 (Lifecycle-Konsequenz) sauber machen.
|
summary: `today`-Zeitzone für die `stale_after`-WARN (Validator §6.4) deterministisch festlegen — „heute in UTC abgeleitet" ist nicht hart definiert (Kalenderdatum des UTC-Zeitpunkts vs. lokaler Tag). Determinismus-Anspruch (AD-17h) vor Epic-3 (Lifecycle-Konsequenz) sauber machen.
|
||||||
evidence: Retrospective F-06.
|
evidence: Retrospective F-06.
|
||||||
|
|
||||||
- source_spec: `_bmad-output/implementation-artifacts/epic-1-retro-2026-08-15.md` (F-07)
|
- source_spec: `_bmad-output/implementation-artifacts/epic-1-retro-2026-08-15.md` (F-07)
|
||||||
@@ -334,4 +361,55 @@ Noch nicht adressierte, aber real erkannte Arbeit — gesammelt aus Reviews. Ein
|
|||||||
- source_spec: `_bmad-output/implementation-artifacts/spec-3-1-inkrementellen-datenfluss-implementieren-interpret-reconcile-synthesize-update.md`
|
- source_spec: `_bmad-output/implementation-artifacts/spec-3-1-inkrementellen-datenfluss-implementieren-interpret-reconcile-synthesize-update.md`
|
||||||
summary: **`epic-3-context.md` ist ein neues Artefakt außerhalb der Spec-Code-Map** — die Code Map listet exakt compiler.md / log.md / deferred-work.md / sprint-status.yaml (sonst read-only); die 50-Zeilen-Context-Datei (im Story-3.1-Commit neu) wird nirgends referenziert oder als erzeugt dokumentiert. Vom build-Verfahren (compile-epic-context) erzeugtes Kontext-Artefakt, keine Story-Inhalts-Mutation, kein Always/Ask-First/Never-Verstoß; Home: Story-3.2-Handoff oder nächstes Sprint-Sync (einzeilige Nennung im log.md-Nachweis genügt).
|
summary: **`epic-3-context.md` ist ein neues Artefakt außerhalb der Spec-Code-Map** — die Code Map listet exakt compiler.md / log.md / deferred-work.md / sprint-status.yaml (sonst read-only); die 50-Zeilen-Context-Datei (im Story-3.1-Commit neu) wird nirgends referenziert oder als erzeugt dokumentiert. Vom build-Verfahren (compile-epic-context) erzeugtes Kontext-Artefakt, keine Story-Inhalts-Mutation, kein Always/Ask-First/Never-Verstoß; Home: Story-3.2-Handoff oder nächstes Sprint-Sync (einzeilige Nennung im log.md-Nachweis genügt).
|
||||||
evidence: bmad-code-review Story 3.1 (2026-08-19, Acceptance-Auditor-Layer): Spec-Code-Map vs. `git show efc543c --stat` (6 Dateien, `epic-3-context.md` new file).
|
evidence: bmad-code-review Story 3.1 (2026-08-19, Acceptance-Auditor-Layer): Spec-Code-Map vs. `git show efc543c --stat` (6 Dateien, `epic-3-context.md` new file).
|
||||||
|
status: aufgegriffen (2026-08-19, Story 3.2) — einzeilige Nennung im `wiki/log.md`-Eintrag der Story 3.2 erfolgt; `epic-3-context.md` bleibt als vom build-Verfahren erzeugtes Kontext-Artefakt bestehen (keine Story-Inhalts-Mutation; Deckung über die Spec-`context:`-Frontmatter der Story-3.2-Spezifikation).
|
||||||
|
## Deferred from: Story 3.2 (Relevanzbestimmung, 2026-08-19)
|
||||||
|
|
||||||
|
- source_spec: `schema/compiler.md` §3.2-Pkt.-1b (Story 3.2)
|
||||||
|
summary: **Em-Dash-»—«-Varianten-Lücke der Normalisierung** — die Kollaps-Klasse `[-–_ ]` (En-Dash »–«, Bindestrich »-«, Unterstrich »_«, Leerzeichen) deckt den Em-Dash »—« **nicht** ab. Eine Schreibvariante mit Em-Dash (z. B. »wissen — relevanz«, aus dem Kontext einer externen Quelle eingelesen) fällt nicht unter den Kollaps und wird nicht zu einer identischen canonischen Form normalisiert — eine erkannte Synonym-/Determinismus-Lücke der Relevanzbestimmung (A0-18/A0-19). Wird nicht stillschweigend in §3.2 ergänzt, sondern als offene Determinismus-Frage an **Story 3.8** (Determinismus-Vertrag, AD-17h) übergeben; bis dahin wird ein nicht auflösbarer Em-Dash-Term **wie notiert** verwendet (Kollaps-normalisiert, kein stiller Ausschluss).
|
||||||
|
evidence: Story-3.2-Review-Umsetzung (2026-08-19) — §3.2-Pkt.-1b dokumentiert die Lücke explizit als »Bekannte Determinismus-Lücke (aufgezeichnet, nicht still hinzugefügt)« und beruft sich auf diesen deferred-work-Eintrag als Handoff-Ziel.
|
||||||
|
status: offen (Home: Story 3.8)
|
||||||
|
|
||||||
|
## Deferred from: code review of spec-3-2-relevanzbestimmung-textual-deterministisch-umsetzen-grep-rip (2026-08-19)
|
||||||
|
|
||||||
|
- source_spec: `_bmad-output/implementation-artifacts/spec-3-2-relevanzbestimmung-textual-deterministisch-umsetzen-grep-rip.md`
|
||||||
|
summary: **`§3.2`-Pkt.-2a: Wortgrenzen-/Frontmatter-Scope der Stufe-a-Match-Semantik ist offen** — die Grep/rg-Erhebung matcht ohne Wortgrenze (Substring: `alpha` trifft `alphabet`) und dateiweit inkl. YAML-Frontmatter (`sources[].resource`, `generated.by` — Provenanz-/Tool-Strings können nicht-thematische Concepts als Kandidaten markieren). Keine deterministischen Lücke im Ist-Sinn (das Verhalten ist reproduzierbar), aber die Match-Semantik ist nicht fixiert; zwei Producer-Readings sind möglich. Home: nächste Compiler-Instruktions-Revision, die §3.2 ohnehin berührt (oder Story 3.8, Determinismus-Vertrag-Abgleich).
|
||||||
|
evidence: bmad-code-review Story 3.2 (2026-08-19, Loop 3, Edge-Case-Hunter + Verification-Gap-Layer): `schema/compiler.md:55` (Stufe-a-Form ohne `\b`/Frontmatter-Klausel) vs. §3.2-Intro („Concept-Bodies").
|
||||||
|
status: offen
|
||||||
|
|
||||||
|
- source_spec: `_bmad-output/implementation-artifacts/spec-3-2-relevanzbestimmung-textual-deterministisch-umsetzen-grep-rip.md`
|
||||||
|
summary: **`§3.2`-Pkt.-1b-ii: Kollaps-Reichweite bei aufeinanderfolgenden/führenden/trailenden Separatoren unbestimmt** — „jedes Vorkommen wird in einen einzelnen Bindestrich kollabiert" ist für Läufe (`a--b`), führende (`-x`) und trailende (`x-`) Separatoren nicht eindeutig (Kollaps auf genau ein `-` + Trim? oder 1:1-Ersatz?). Bis dahin ist die Normalisierung für solche Terme nicht vollständig pinbar (AD-17h-Nähe). Home: nächste Compiler-Instruktions-Revision (mit- oder in Story 3.8 zusammen mit der Em-Dash-Lücke, s. obiger Eintrag).
|
||||||
|
evidence: bmad-code-review Story 3.2 (2026-08-19, Loop 3, Edge-Case-Hunter-Layer): `schema/compiler.md:51` (Pkt. 1b-ii).
|
||||||
|
status: offen
|
||||||
|
|
||||||
|
- source_spec: `_bmad-output/implementation-artifacts/spec-3-2-relevanzbestimmung-textual-deterministisch-umsetzen-grep-rip.md`
|
||||||
|
summary: **Stufe-a-Treffer auf `index.md`-Pfade deterministisch aus der finalen Candidate-Liste entfernen** — Pkt. 2b definiert `index.md`-Treffer als Stufe-**b**-Trigger (gewurzelte Concept-Pfade sind die Stufe-b-Treffer), aber Pkt. 3b ordnet „Stufe-a-Treffer zuerst" ohne Fixierung, dass reine `index.md`-Stufe-a-Treffer *nicht* als Candidate (nicht-Concept-Pfad) in die finale Liste einfließen (Sandbox-T2-Ausgabe `index`+`alpha` illustriert den ungeklärten Fall; die Candidate-Liste ist per Definition auf Concept-Pfade beschränkt). Home: nächste Compiler-Instruktions-Revision, die §3.2 berührt.
|
||||||
|
evidence: bmad-code-review Story 3.2 (2026-08-19, Loop 3, Blind-Hunter + Edge-Case-Hunter-Layer): `schema/compiler.md:55-56,60`; `_bmad-output/implementation-artifacts/sandbox-3-2/run-sandbox.sh` T2-Kommentar.
|
||||||
|
status: offen
|
||||||
|
|
||||||
|
- source_spec: `_bmad-output/implementation-artifacts/spec-3-2-relevanzbestimmung-textual-deterministisch-umsetzen-grep-rip.md`
|
||||||
|
summary: **Rev-2.5/2.6-Beleg-Klarigungen ohne Semantik-Auswirkung (Bündel)** — (a) Rev-2.5-Log-Zelle zitiert die `rg --exclude`-Form im aktiven Mechanismus-Teil ohne eigene Inline-Korrektur (Rev-2.6-Zelle erklärt sie nur — ein Producer, der nur Rev 2.5 liest, kopiert ein nicht-existentes Flag); (b) `sprint-status.yaml last_updated: 08-19-2026 07:10` liegt vor dem Story-3.2-Commit (09:16) — Zeitstempel dokumentiert nicht den Abschluss-Zeitpunkt (Story-3.1-Präzedenz: `last_updated` wird im Review-Loop-2-Commit ebenfalls nicht fortgeschrieben); (c) `compiler.md`-Revisionslog: Rev 2.6 steht über Rev 2.5 (chronologisch umgekehrt — Rev-2.6 wurde an der Einfüge-Stelle statt nach 2.5 angehängt); (d) Validator-Beleg „alle 7 `wiki/`-Dateien SUCCESS" als Aggregat ohne per-Datei-Liste (Spec-Verification Pkt. 4 verlangt „per-Datei-Verdikt als Ausführungs-Nachweis"; die Zählung 7 ist korrekt: 5 Root- + 2 Area-Concepts + log — re-executiert); (e) Rev-2.6-`git status`-Beleg listet `schema/canonical-terms.md` (neue Datei) und die `_bmad-output/`-Änderungen nicht, obwohl „`git status`" als Prüfgrundlage genannt wird; (f) Formel-4-Beleg: Ist-Zählung `38` ohne Baseline-`≡`-Partner (re-executiert: Ist = 38, korrekt — nur der Beleg-String ist unvollständig gegenüber der §5.6-Formel-4-Semantik „Ist ≡ Extraktion aus dem Baseline-Commit"). Home: nächste Log-/Nachweis-Runde (Story-3.3-Implementierungseintrag oder Story-3.2-Re-Review), keine Instruktions-Änderung nötig.
|
||||||
|
evidence: bmad-code-review Story 3.2 (2026-08-19, Loop 3, Blind-Hunter + Verification-Gap + Acceptance-Auditor-Layer): `wiki/log.md:4-5`, `schema/compiler.md:372-373`, `_bmad-output/implementation-artifacts/sprint-status.yaml:32`; re-executierte Formel-4-Zählung (38) und `ls wiki/` (7 `.md`-Dateien) bestätigen Korrektheit der Werte.
|
||||||
|
status: offen
|
||||||
|
|
||||||
|
|
||||||
|
## Deferred from: code review of spec-3-4-wissen-aus-mehreren-sources-synthetisieren (Story 3.4, 2026-08-19)
|
||||||
|
|
||||||
|
- source_spec: `_bmad-output/implementation-artifacts/spec-3-4-wissen-aus-mehreren-sources-synthetisieren.md`
|
||||||
|
summary: **AD-16-Disagreement- und AD-4c-Übernahme-Marker-Pfad erst in der Sandbox demonstriert, nicht als reale Bundle-Demonstration** — die zwei vom Verification-Gap-Layer als „unbeobachtete Vertragsverpflichtungen" markierten Zweige (§5.10 Pkt. 3 AD-16-Default, Pkt. 4 AD-4c) sind durch die neuen Sandbox-Szenarien **N2 (Disagreement: beide Behauptungen + je Beleg bleiben, kein `(e; f)`-Falsch-Multi-Beleg, `Disagreement:`-log-Eintrag)** und **N3 (AD-4c-Kontext-Marker: „übernommen aus `gamma` auf Basis von `raw/gamma-v1.md#S-1`, nicht eigenständig belegt"; übernommene Quelle nicht in `sources`)** hart assertiert. Eine **reale** Disagreement- oder Übernahme-Synthese im echten Bundle bleibt Aufgabe der Epic-4-Stories (4.1 Klassifikation, 4.2 Disagreements in `log.md`), die hier bewusst nicht vorweggenommen wird (Story-3.4-Boundaries: keine Korrektur-Klassifikation, kein reales Bundle-Testmaterial). Home: Epic-4 (Story 4.1/4.2) — reale Anwendung der Sandbox-verankerten Mechanik.
|
||||||
|
evidence: Step-04-Review (2026-08-19, Verification-Gap-Layer) — Kernbefund „AD-16-Disagreement-Pfad untested" + „AD-4c-Übernahme-Marker untested"; geschlossen durch `_bmad-output/implementation-artifacts/sandbox-3-4/run-sandbox.sh` N2/N3 (Exit 0, 10 Szenarien).
|
||||||
|
status: offen (Home: Epic-4)
|
||||||
|
|
||||||
|
- source_spec: `_bmad-output/implementation-artifacts/spec-3-4-wissen-aus-mehreren-sources-synthetisieren.md`
|
||||||
|
summary: **Orphan-Kontrolle (§5.10 Pkt. 8) textuell verankert, aber nicht in der Sandbox demonstriert** — die Regel „neu committete `raw/`-Evidenz ohne Ziel-Pfad-Treffer bleibt unzugeordnet und wird in `log.md` als verwaist protokolliert" ist Teil der Pkt.-8-Erhaltungs/Determinismus-Ebene; das Review wies darauf hin, dass der Orphan-Fall (Zuwachs ohne Kandidaten-Treffer) kein eigenes Sandbox-Szenario hat. Die Negativ-Kontroll-Dichte der Sandbox (S3 Reflektiertheit, S5 `??`-Sicht/Struktur, N1 No-Op, N2/N3) deckt die übrigen Pkt.-8-Aspekte; ein Orphan-Szenario wurde zugunsten des verbleibenden Review-Scopes nicht ergänzt. Home: Story 3.8 (Reconcile-Orphan-Politik) oder Epic-4 — verwaiste Evidenz-Politik als Folge-Story.
|
||||||
|
evidence: Step-04-Review (2026-08-19, Blind-Hunter-Layer) — Befund „unknown/orphaned raw evidence path without target"); `schema/compiler.md` §5.10 Pkt. 8 (Orphan-Kontrolle, in dieser Runde formuliert).
|
||||||
|
status: offen (Home: Story 3.8)
|
||||||
|
|
||||||
|
- source_spec: `_bmad-output/implementation-artifacts/spec-3-4-wissen-aus-mehreren-sources-synthetisieren.md`
|
||||||
|
summary: **Sandbox-Evidenztexte transkribieren Umlaute, die Concept-Bodies nutzen Umlaut-Schreibweisen (Determinismus-Hazard für den Term-Abgleich)** — die Story-3.4-Sandbox setzt den bekannten Story-3.2-/Sandbox-Normalisierungs-Hazard fort (already known: Em-Dash-Lücke + Umlaut vs. Transkription, Home Story 3.8). Die §3.2-Normalisierung (lowercasing + `[-–_ ]`-Kollaps) deckt Umlaut-Divergenzen („Schlüssel" vs. „Schluessel") nicht; die Sandbox-Bodies (Umlaut) vs. raw-Evidenz (Transkription, z. B. „Bestaetigungen", „Repraesentationen") nutzen bewusst beide Schreibweisen. Home: Story 3.8 (Determinismus-Vertrag, Normalisierungs-Vollständigkeit) oder Sandbox-Vereinheitlichung in einer Folge-Story — kein Instruktions-Defekt.
|
||||||
|
evidence: Step-04-Review (2026-08-19, Verification-Gap-Layer): `run-sandbox.sh` N2 (`Quorum-Bestaetigungen`) / S6 / S2/`Sitzungsschluessel` etc.; §3.2-Pkt.-1b-Kollaps-Klasse ohne Umlaut-/Em-Dash.
|
||||||
|
status: offen (Home: Story 3.8)
|
||||||
|
|
||||||
|
- source_spec: `_bmad-output/implementation-artifacts/spec-3-4-wissen-aus-mehreren-sources-synthetisieren.md`
|
||||||
|
summary: **Frozen Spec-Intent-Typo „Nickel" im §5.10-Form-Wahl-Aufgaben-Pfad (Story-3.3-Defer U2/U7-Empfehlung)** — der Intent-Satz „Nickel die Story-3.3-Defer U2/U7-Empfehlung (…) im Sandbox auf" enthält „Nickel" statt „Nimm/Trage … auf" (oder „Schließe … auf"); er sitzt im `<frozen-after-approval>`-Block des Specs, dessen Text erst nach humaner Re-Negotiation geändert werden darf. Kein Instruktions-Defekt (der Sandbox-/authored-Text ist korrekt — FW-Szenario implementiert die Empfehlung inhaltlich). Home: Spec-Re-Negotiation (Ask-First: menschliche Autorisierung) oder Akzeptanz als kosmetischer Frozen-Fehler.
|
||||||
|
evidence: Step-04-Review (2026-08-19, Blind-Hunter-Layer): `spec-3-4-…md` Zeile ~18 (frozen Intent) — „Nickel die Story-3.3-Defer U2/U7-Empfehlung … auf".
|
||||||
status: offen
|
status: offen
|
||||||
|
|||||||
@@ -0,0 +1,353 @@
|
|||||||
|
#!/usr/bin/env bash
|
||||||
|
# Story 3.2 — Sandbox-Tests der textuell-deterministischen Relevanzbestimmung (§3.2)
|
||||||
|
# Re-executierbar: bash run-sandbox.sh (ab Workspace-Root; Sandbox unter /tmp/sb32)
|
||||||
|
# Zweck: Membership-Pin (T1) + Zwei-Run-Identität (T2) + NO_MATCH (T3) +
|
||||||
|
# log.md-Kontaminations-Pin (T1: der Term liegt AUCH in log.md — die
|
||||||
|
# Candidate-Liste bleibt trotzdem auf Concept-Pfade definiert, §3.2-Pkt.-2a)
|
||||||
|
# + LINK_FOLLOWING_ZYKLUS (T5) + TRAVERSAL_REACH_ONLY (T6) +
|
||||||
|
# TERM_ABLEITUNG_SYNONYM (T7); T1/T4 mit harten Assertions (Review-Patch P-1).
|
||||||
|
set -u
|
||||||
|
ROOT=$(mktemp -d /tmp/sb32-XXXXXX)
|
||||||
|
SB="$ROOT/sb"
|
||||||
|
mkdir -p "$SB/wiki" "$SB/raw"
|
||||||
|
cd "$SB"
|
||||||
|
git init -q
|
||||||
|
git config user.email "sandbox@test"
|
||||||
|
git config user.name "Sandbox"
|
||||||
|
|
||||||
|
# ---------- Mini-Baum: Concept-Bodies + log.md, die den EXAKTEN Test-Term tragen ----------
|
||||||
|
cat > wiki/index.md <<'EOF'
|
||||||
|
# Index
|
||||||
|
- [Alpha](alpha.md)
|
||||||
|
EOF
|
||||||
|
cat > wiki/alpha.md <<'EOF'
|
||||||
|
---
|
||||||
|
type: concept
|
||||||
|
sources:
|
||||||
|
- resource: raw/alpha-v1.md
|
||||||
|
id: s1
|
||||||
|
generated:
|
||||||
|
by: wow-compiler/0.1.0
|
||||||
|
at: 2026-08-16T09:00:00Z
|
||||||
|
---
|
||||||
|
Das Alpha-Protokoll verwendet deterministische-relevanz-bestimmung für den Abgleich.
|
||||||
|
EOF
|
||||||
|
cat > wiki/beta.md <<'EOF'
|
||||||
|
---
|
||||||
|
type: concept
|
||||||
|
sources:
|
||||||
|
- resource: raw/beta-v1.md
|
||||||
|
id: s1
|
||||||
|
generated:
|
||||||
|
by: wow-compiler/0.1.0
|
||||||
|
at: 2026-08-16T09:00:00Z
|
||||||
|
---
|
||||||
|
Beta beschreibt ein anderes, hier nicht betroffenes Thema.
|
||||||
|
EOF
|
||||||
|
# log.md trägt denselben Term — der Kontaminations-Fall, den die Exklusion entschärft:
|
||||||
|
cat > wiki/log.md <<'EOF'
|
||||||
|
# Log
|
||||||
|
|
||||||
|
## 2026-08-19
|
||||||
|
- Story-3.2-Update: alpha (raw/alpha-v2.md; deterministische-relevanz-bestimmung).
|
||||||
|
EOF
|
||||||
|
cat > raw/alpha-v1.md <<'EOF'
|
||||||
|
Evidenz v1: deterministische-relevanz-bestimmung (Stelle S-1).
|
||||||
|
EOF
|
||||||
|
cat > raw/beta-v1.md <<'EOF'
|
||||||
|
Evidenz v1: Beta-Thema (Stelle S-1).
|
||||||
|
EOF
|
||||||
|
git add -A
|
||||||
|
git commit -qm "Baseline"
|
||||||
|
BASE=$(git rev-parse HEAD)
|
||||||
|
echo "BASELINE-COMMIT: $BASE (Sandbox-Root: $ROOT; loeschbar: rm -rf $ROOT)"
|
||||||
|
echo
|
||||||
|
|
||||||
|
# ---------- Helfer: candidate-Erhebung mit tool-korrekter Exklusion (§3.2-Pkt.-2a) ----------
|
||||||
|
# rg-Form: rg -l '<term>' -g '!log.md' wiki/
|
||||||
|
# grep-Form:grep -rl '<term>' --exclude=log.md wiki/
|
||||||
|
terms() { # $1=Term; nutzt rg wenn vorhanden (native -g-Exklusion), sonst grep --exclude
|
||||||
|
if command -v rg >/dev/null 2>&1; then
|
||||||
|
rg -l "$1" -g '!log.md' wiki/
|
||||||
|
else
|
||||||
|
grep -rl "$1" --exclude=log.md wiki/
|
||||||
|
fi
|
||||||
|
}
|
||||||
|
# Normalisierung der Ausgabe: wiki/-Präfix + .md-Suffix strippen (§3.2-Pkt.-3a)
|
||||||
|
normalize() { sed -e 's|^wiki/||' -e 's|\.md$||'; }
|
||||||
|
|
||||||
|
# ---------- Helfer: Stufe b/c (Erhebung) + Terminormalisierung (Review-Loop-2, D-2) ----------
|
||||||
|
# Stufe b — index.md-Traversal (TRAVERSAL_REACH_ONLY, §3.2-Pkt.-2b):
|
||||||
|
# $1 = normalisierter Treffer-Name einer index.md (z. B. 'trafo/index' oder 'index');
|
||||||
|
# gibt die darunter gewurzelten Concept-Pfade (normalisiert) aus — die Concept-Links
|
||||||
|
# der getroffenen index.md, file-relativ aufgelöst (§5.7-Pkt.-4).
|
||||||
|
traverse() {
|
||||||
|
local idx="wiki/$1.md" d tgt
|
||||||
|
d=$(dirname "$idx")
|
||||||
|
grep -oE '\]\([^)]+\.md\)' "$SB/$idx" 2>/dev/null | sed -e 's|^\](||' -e 's|)$||' | while read -r tgt; do
|
||||||
|
case "$tgt" in ./*) tgt=${tgt#./} ;; esac
|
||||||
|
printf '%s/%s\n' "$d" "$tgt" | sed -e 's|^wiki/||' -e 's|\.md$||'
|
||||||
|
done
|
||||||
|
}
|
||||||
|
|
||||||
|
# Stufe c — Link-Following mit besuchter Menge (LINK_FOLLOWING_ZYKLUS, §3.2-Pkt.-2c):
|
||||||
|
# $@ = in Stufe a getroffene Concept-Pfade (normalisiert, z. B. 'sigma');
|
||||||
|
# Concept-Links werden file-relativ verfolgt (§5.7-Pkt.-4); ein bereits besuchter
|
||||||
|
# Concept-Pfad wird nicht erneut besucht — Zyklen (A -> B -> A) enden, die
|
||||||
|
# Candidate-Liste bleibt endlich. Ausgabe: getroffene + erreichte Pfade,
|
||||||
|
# in Besuchsreihenfolge (Stufe a zuerst, dann Stufe c; §3.2-Pkt.-3b).
|
||||||
|
follow() {
|
||||||
|
local visited="$ROOT/visited.$$" seed f base tgt res
|
||||||
|
: > "$visited"
|
||||||
|
local queue=()
|
||||||
|
for seed in "$@"; do
|
||||||
|
printf '%s\n' "$seed" >> "$visited"
|
||||||
|
queue+=("$seed")
|
||||||
|
done
|
||||||
|
while [ "${#queue[@]}" -gt 0 ]; do
|
||||||
|
f="wiki/${queue[0]}.md"
|
||||||
|
queue=("${queue[@]:1}")
|
||||||
|
base=$(dirname "$f")
|
||||||
|
for tgt in $(grep -oE '\]\([^)]+\.md\)' "$SB/$f" 2>/dev/null | sed -e 's|^\](||' -e 's|)$||'); do
|
||||||
|
case "$tgt" in ./*) tgt=${tgt#./} ;; esac
|
||||||
|
res=$(printf '%s/%s\n' "$base" "$tgt" | sed -e 's|^wiki/||' -e 's|\.md$||')
|
||||||
|
grep -qx "$res" "$visited" && continue
|
||||||
|
printf '%s\n' "$res" >> "$visited"
|
||||||
|
queue+=("$res")
|
||||||
|
done
|
||||||
|
done
|
||||||
|
cat "$visited"
|
||||||
|
}
|
||||||
|
|
||||||
|
# Terminormalisierung (§3.2-Pkt.-1b): (i) lowercasing; (ii) Binde-Varianten-Kollaps
|
||||||
|
# [-–_ ] -> - (jedes Vorkommen wird in einen einzelnen Bindestrich kollabiert).
|
||||||
|
# Normalisierte Form = die Form, die in der Registry gespeichert/verglichen wird.
|
||||||
|
norm_term() { printf '%s' "$1" | LC_ALL=C tr 'A-Z' 'a-z' | sed -e 's/[-–_ ]/-/g'; }
|
||||||
|
|
||||||
|
# Registry-Lookup (§3.2-Pkt.-1b, canonical-terms.md-Format):
|
||||||
|
# $1 = normalisierter Term, $2 = Registry-Datei; gibt die canonische Form aus,
|
||||||
|
# oder — nicht auflösbar — den Term selbst (§3.2-Pkt.-1b: kein stiller Ausschluss).
|
||||||
|
lookup() {
|
||||||
|
awk -F'|' -v t="$1" '
|
||||||
|
NR > 2 {
|
||||||
|
canon = $2; gsub(/^[ \t]+|[ \t]+$/, "", canon)
|
||||||
|
if (canon ~ /^—/) next
|
||||||
|
if (canon == t) { print canon; found = 1; exit }
|
||||||
|
vars = $3; gsub(/`/, " ", vars)
|
||||||
|
n = split(vars, a, ",")
|
||||||
|
for (i = 1; i <= n; i++) {
|
||||||
|
gsub(/^[ \t]+|[ \t]+$/, "", a[i])
|
||||||
|
if (a[i] != "" && a[i] == t) { print canon; found = 1; exit }
|
||||||
|
}
|
||||||
|
}
|
||||||
|
END { if (!found) print t }
|
||||||
|
' "$2"
|
||||||
|
}
|
||||||
|
|
||||||
|
# =====================================================================
|
||||||
|
runlabel() { echo; echo "########## $1 ##########"; }
|
||||||
|
|
||||||
|
runlabel "T1: Membership-Pin — Term trifft Concept-Body UND log.md; Candidate-Liste nur Concept-Pfade"
|
||||||
|
echo "--- Kandidaten-Erhebung: terms 'deterministische-relevanz-bestimmung' (Exklusions-Form) ---"
|
||||||
|
terms 'deterministische-relevanz-bestimmung' | normalize
|
||||||
|
echo "--- Erwartet: AUSSCHLIESSLICH 'alpha' (Concept-Pfad, ohne wiki/ + ohne .md) ---"
|
||||||
|
T1_OUT=$(terms 'deterministische-relevanz-bestimmung' | normalize)
|
||||||
|
if [ "$T1_OUT" = "alpha" ]; then
|
||||||
|
echo "RESULT: PASS (Candidate-Liste = [alpha]; log.md strukturell exkludiert, §3.2-Pkt.-2a)"
|
||||||
|
else
|
||||||
|
echo "FAIL: T1 — erwartet 'alpha', erhalten: '${T1_OUT}'" >&2
|
||||||
|
exit 1
|
||||||
|
fi
|
||||||
|
echo "--- Kontaminations-Kontrolle: was OHNE Exklusion getroffen würde (rg-OHNE -g / grep-OHNE --exclude) ---"
|
||||||
|
if command -v rg >/dev/null 2>&1; then
|
||||||
|
rg -l 'deterministische-relevanz-bestimmung' wiki/ | normalize
|
||||||
|
else
|
||||||
|
grep -rl 'deterministische-relevanz-bestimmung' wiki/ | normalize
|
||||||
|
fi
|
||||||
|
echo "--- OHNE Exklusion trifft es 'alpha' UND 'log' — die Exklusion (§3.2-Pkt.-2a) ist damit reell getestet ---"
|
||||||
|
|
||||||
|
# =====================================================================
|
||||||
|
runlabel "T2: Zwei-Run-Identität (AD-17h/A0-19) — zwei unabhängige Läufe, byte-identische Candidate-Liste"
|
||||||
|
FIRST1=$(terms 'deterministische-relevanz-bestimmung' | normalize)
|
||||||
|
SECOND1=$(terms 'deterministische-relevanz-bestimmung' | normalize)
|
||||||
|
FIRST2=$(terms 'alpha' | normalize)
|
||||||
|
SECOND2=$(terms 'alpha' | normalize)
|
||||||
|
echo "Lauf 1 (Term deterministische-relevanz-bestimmung): $FIRST1"
|
||||||
|
echo "Lauf 2 (Term deterministische-relevanz-bestimmung): $SECOND1"
|
||||||
|
echo "Lauf 1 (Term alpha): $FIRST2 # 'index' ist ein Stufe-a-Treffer auf wiki/index.md — Stufe b (TRAVERSAL_REACH_ONLY, §3.2-Pkt.-2b) löst die darunter gewurzelten Concept-Pfade als Candidate aus (index.md selbst ist KEIN Concept-Kandidat); kein Kontaminations-Fehler"
|
||||||
|
echo "Lauf 2 (Term alpha): $SECOND2 # identische Ausgabe (Zwei-Run-Identität, AD-17h)"
|
||||||
|
if [ "$FIRST1" = "$SECOND1" ] && [ "$FIRST2" = "$SECOND2" ]; then
|
||||||
|
echo "RESULT: IDENTISCH (gleicher Git-State + gleiches Eingabeset -> identische Candidate-Liste, AD-17h)"
|
||||||
|
else
|
||||||
|
echo "RESULT: ABWEICHUNG (Determinismus-Vertrag verletzt)" >&2
|
||||||
|
exit 1
|
||||||
|
fi
|
||||||
|
|
||||||
|
# =====================================================================
|
||||||
|
runlabel "T3: NO_MATCH — Term trifft kein bestehendes Concept -> leere Candidate-Liste -> UNTOUCHED_CONCEPT"
|
||||||
|
echo "--- Kandidaten-Erhebung: terms 'vollkommen-neuer-gamma-termin' ---"
|
||||||
|
RES=$(terms 'vollkommen-neuer-gamma-termin' | normalize)
|
||||||
|
echo "Candidate-Liste: '${RES}' (leer = gewuenscht)"
|
||||||
|
if [ -z "$RES" ]; then
|
||||||
|
echo "RESULT: LEER (NO_MATCH -> UNTOUCHED_CONCEPT: keine Mutation, kein log.md-Zusatz; leere Menge ⊆ erlaubte Menge)"
|
||||||
|
else
|
||||||
|
echo "RESULT: FEHLER (erwartet leer)" >&2
|
||||||
|
exit 1
|
||||||
|
fi
|
||||||
|
|
||||||
|
# =====================================================================
|
||||||
|
runlabel "T4: Determinismus-Vertrag praktisch — Term in Mehrfach-Konzepten, Konsolidierung zur Vereinigung"
|
||||||
|
cat > wiki/gamma.md <<'EOF'
|
||||||
|
---
|
||||||
|
type: concept
|
||||||
|
sources:
|
||||||
|
- resource: raw/gamma-v1.md
|
||||||
|
id: s1
|
||||||
|
generated:
|
||||||
|
by: wow-compiler/0.1.0
|
||||||
|
at: 2026-08-16T09:00:00Z
|
||||||
|
---
|
||||||
|
Gamma teilt den Term deterministische-relevanz-bestimmung (Stelle S-1).
|
||||||
|
EOF
|
||||||
|
git add -A; git commit -qm "Zuwachs gamma (teilt den Term)"
|
||||||
|
echo "--- Kandidaten-Erhebung (Term in alpha + gamma; §3.2-Pkt.-3b: innerhalb jeder Stufe rein lexikografisch, LC_ALL=C): ---"
|
||||||
|
terms 'deterministische-relevanz-bestimmung' | normalize | LC_ALL=C sort | paste -sd, -
|
||||||
|
echo "--- Erwartet: alpha,gamma (beide Concept-Pfade, lexikografisch; log ABGESCHNITTEN) ---"
|
||||||
|
T4_OUT=$(terms 'deterministische-relevanz-bestimmung' | normalize | LC_ALL=C sort | paste -sd, -)
|
||||||
|
if [ "$T4_OUT" = "alpha,gamma" ]; then
|
||||||
|
echo "RESULT: PASS (Vereinigung beider Concept-Pfade, lexikografisch; log.md exkludiert)"
|
||||||
|
else
|
||||||
|
echo "FAIL: T4 — erwartet 'alpha,gamma', erhalten: '${T4_OUT}'" >&2
|
||||||
|
exit 1
|
||||||
|
fi
|
||||||
|
|
||||||
|
# =====================================================================
|
||||||
|
# T5-T7 (Review-Loop-2, D-2): Zyklen-Endlichkeit, Traversal-Only, Synonym-Auflösung
|
||||||
|
# =====================================================================
|
||||||
|
|
||||||
|
# ---------- T5: LINK_FOLLOWING_ZYKLUS — A -> B -> A endet endlich (besuchte Menge) ----------
|
||||||
|
runlabel "T5: LINK_FOLLOWING_ZYKLUS — Zyklus alpha <-> omega endet endlich; Candidate-Liste endlich (§3.2-Pkt.-2c/3b)"
|
||||||
|
cat > wiki/omega.md <<'EOF'
|
||||||
|
---
|
||||||
|
type: concept
|
||||||
|
sources:
|
||||||
|
- resource: raw/omega-v1.md
|
||||||
|
id: s1
|
||||||
|
generated:
|
||||||
|
by: wow-compiler/0.1.0
|
||||||
|
at: 2026-08-16T09:00:00Z
|
||||||
|
---
|
||||||
|
Omega verweist zirkular auf Alpha: [Alpha](alpha.md).
|
||||||
|
EOF
|
||||||
|
# Backlink: alpha -> omega (erzeugt den echten A->B->A-Zyklus, der die besuchte Menge übt):
|
||||||
|
printf '\nOmega-Verweis: [Omega](omega.md).\n' >> wiki/alpha.md
|
||||||
|
git add -A; git commit -qm "Zuwachs omega (Link-Zyklus alpha <-> omega)"
|
||||||
|
echo "--- Stufe a (Term zirkular): ---"
|
||||||
|
STAGE_A=$(terms 'zirkular' | normalize | LC_ALL=C sort | paste -sd, -)
|
||||||
|
echo "$STAGE_A"
|
||||||
|
echo "--- Stufe c (Follow aus Stufe a; ZYKLUS omega -> alpha -> omega ... MUSS enden): ---"
|
||||||
|
STAGE_C=$(follow omega)
|
||||||
|
echo "$STAGE_C"
|
||||||
|
# Deduplication über die besuchte Menge (sort -u: endliche, doppelungsfreie Menge —
|
||||||
|
# die Stufe-Ordnung a→c ist bereits in STAGE_A/STAGE_C sichtbar; hier wird die Endlichkeit geprüft):
|
||||||
|
T5_EXPECT="alpha,omega"
|
||||||
|
T5_LIST=$(printf '%s\n%s\n' "$STAGE_A" "$STAGE_C" | grep -v '^$' | LC_ALL=C sort -u | paste -sd, -)
|
||||||
|
if [ "$T5_LIST" = "$T5_EXPECT" ]; then
|
||||||
|
echo "RESULT: PASS (endlich, dedupliziert: omega, alpha — Zyklus endete; jeder Pfad genau einmal)"
|
||||||
|
else
|
||||||
|
echo "FAIL: T5 — erwartet '$T5_EXPECT', erhalten: '$T5_LIST'" >&2
|
||||||
|
exit 1
|
||||||
|
fi
|
||||||
|
|
||||||
|
# ---------- T6: TRAVERSAL_REACH_ONLY — Term nur in index.md -> gewurzelte Concept-Pfade ----------
|
||||||
|
runlabel "T6: TRAVERSAL_REACH_ONLY — Term 'trafo-gebiet' trifft NUR wiki/trafo/index.md -> gewurzelte Concept-Pfade sind die Treffer (index.md selbst kein Concept-Kandidat, §3.2-Pkt.-2b)"
|
||||||
|
mkdir -p wiki/trafo
|
||||||
|
cat > wiki/trafo/index.md <<'EOF'
|
||||||
|
# Trafo-Gebiet-Index
|
||||||
|
Dieses trafo-gebiet wird hier indexiert.
|
||||||
|
- [Delta](delta.md)
|
||||||
|
- [Epsilon](epsilon.md)
|
||||||
|
EOF
|
||||||
|
cat > wiki/trafo/delta.md <<'EOF'
|
||||||
|
---
|
||||||
|
type: concept
|
||||||
|
sources:
|
||||||
|
- resource: raw/delta-v1.md
|
||||||
|
id: s1
|
||||||
|
generated:
|
||||||
|
by: wow-compiler/0.1.0
|
||||||
|
at: 2026-08-16T09:00:00Z
|
||||||
|
---
|
||||||
|
Delta-Body (trägt den Index-Term NICHT — nur der Index trägt ihn).
|
||||||
|
EOF
|
||||||
|
cat > wiki/trafo/epsilon.md <<'EOF'
|
||||||
|
---
|
||||||
|
type: concept
|
||||||
|
sources:
|
||||||
|
- resource: raw/epsilon-v1.md
|
||||||
|
id: s1
|
||||||
|
generated:
|
||||||
|
by: wow-compiler/0.1.0
|
||||||
|
at: 2026-08-16T09:00:00Z
|
||||||
|
---
|
||||||
|
Epsilon-Body (trägt den Index-Term NICHT — nur der Index trägt ihn).
|
||||||
|
EOF
|
||||||
|
git add -A; git commit -qm "Zuwachs trafo/Area (Index trägt den Term, Bodies nicht)"
|
||||||
|
echo "--- Stufe a (Term trafo-gebiet; nur index.md trifft — der Traversal-Trigger): ---"
|
||||||
|
STAGE_A=$(terms 'trafo-gebiet' | normalize)
|
||||||
|
echo "$STAGE_A"
|
||||||
|
echo "--- Stufe b (Traversal: gewurzelte Concept-Pfade der getroffenen index.md): ---"
|
||||||
|
STAGE_B=$(traverse 'trafo/index')
|
||||||
|
echo "$STAGE_B"
|
||||||
|
# Kandidaten = gewurzelte Concept-Pfade (lexikografisch; index.md selbst ist KEIN Concept-Kandidat):
|
||||||
|
T6_OUT=$(printf '%s\n' "$STAGE_B" | grep -v '^$' | LC_ALL=C sort | paste -sd, -)
|
||||||
|
if [ "$T6_OUT" = "trafo/delta,trafo/epsilon" ]; then
|
||||||
|
echo "RESULT: PASS (Candidate-Liste = gewurzelte Concept-Pfade; Index-Body-Trigger, kein Kontaminations-Fehler)"
|
||||||
|
else
|
||||||
|
echo "FAIL: T6 — erwartet 'trafo/delta,trafo/epsilon', erhalten: '$T6_OUT'" >&2
|
||||||
|
exit 1
|
||||||
|
fi
|
||||||
|
|
||||||
|
# ---------- T7: TERM_ABLEITUNG_SYNONYM — Schreibvariante -> canonische Form -> Kandidaten ----------
|
||||||
|
runlabel "T7: TERM_ABLEITUNG_SYNONYM — gezogene Schreibvariante wird über canonical-terms.md auf die canonische Form aufgelöst (Lookup auf normalisierter Form, §3.2-Pkt.-1b)"
|
||||||
|
mkdir -p "$ROOT/registry"
|
||||||
|
cat > "$ROOT/registry/canonical-terms.md" <<'EOF'
|
||||||
|
# Sandbox-Registry (Test-Doppel des canonical-terms-Formats; append-only, ein Eintrag = Canon + Varianten;
|
||||||
|
# D-5-Invariante: Canon- UND Varianten-Spalte tragen ausschliesslich NORMALISIERTE Formen)
|
||||||
|
|
||||||
|
| canonische Form | erlaubte Schreibvarianten | Semantik |
|
||||||
|
|---|---|---|
|
||||||
|
| quanten-protocol | `quantenprotocol` | Sandbox-Semantik: Test-Synonymgruppe |
|
||||||
|
EOF
|
||||||
|
# Invariante-Check (D-5): keine normalisierte Form in beiden Spalten oder in zwei Einträgen:
|
||||||
|
# hier: 'quanten-protocol' nur Canon-Spalte, 'quantenprotocol' nur Varianten-Spalte — eindeutig.
|
||||||
|
# (Registry liegt ausserhalb des Sandbox-Git-Roots — sie modelliert den Git-State-Anteil des Resolvers;
|
||||||
|
# der Sandbox-Repo-Commit trägt sie deshalb nicht, hier nur Notiz statt Commit-Noise:)
|
||||||
|
echo "Registry (ausserhalb des Sandbox-Roots, modelliert den Resolver-Git-State): $ROOT/registry/canonical-terms.md"
|
||||||
|
echo "--- Gezogene Schreibvarianten (Roh-Notat): 'Quanten Protocol' + 'QuantenProtocol' ---"
|
||||||
|
RAW_A='Quanten Protocol'
|
||||||
|
RAW_B='QuantenProtocol'
|
||||||
|
NORM_A=$(norm_term "$RAW_A")
|
||||||
|
NORM_B=$(norm_term "$RAW_B")
|
||||||
|
echo "Normalisierung (§3.2-Pkt.-1b): '$RAW_A' -> '$NORM_A'; '$RAW_B' -> '$NORM_B'"
|
||||||
|
CANON_A=$(lookup "$NORM_A" "$ROOT/registry/canonical-terms.md")
|
||||||
|
CANON_B=$(lookup "$NORM_B" "$ROOT/registry/canonical-terms.md")
|
||||||
|
echo "Lookup: '$NORM_A' -> '$CANON_A'; '$NORM_B' -> '$CANON_B'"
|
||||||
|
if [ "$CANON_A" = "quanten-protocol" ] && [ "$CANON_B" = "quanten-protocol" ]; then
|
||||||
|
echo "RESULT: PASS (beide Varianten -> canonische Form 'quanten-protocol'; Auflösung auf normalisierter Form)"
|
||||||
|
else
|
||||||
|
echo "FAIL: T7 — erwartet 'quanten-protocol' für beide, erhalten: '$CANON_A' / '$CANON_B'" >&2
|
||||||
|
exit 1
|
||||||
|
fi
|
||||||
|
# Nicht aufgelöster Term wird wie notiert (Kollaps-normalisiert) verwendet — kein stiller Ausschluss:
|
||||||
|
CANON_MISS=$(lookup 'nicht-in-registry' "$ROOT/registry/canonical-terms.md")
|
||||||
|
if [ "$CANON_MISS" = 'nicht-in-registry' ]; then
|
||||||
|
echo "PASS (Negativ-Fall: 'nicht-in-registry' -> wie notiert, kein stiller Ausschluss)"
|
||||||
|
else
|
||||||
|
echo "FAIL: T7-Negativ — erwartet 'nicht-in-registry', erhalten: '$CANON_MISS'" >&2
|
||||||
|
exit 1
|
||||||
|
fi
|
||||||
|
|
||||||
|
echo
|
||||||
|
echo "===== Sandbox abgeschlossen (alle 7 Tests) ====="
|
||||||
|
echo "Sandbox-Root: $ROOT"
|
||||||
@@ -0,0 +1,392 @@
|
|||||||
|
#!/usr/bin/env bash
|
||||||
|
# Story 3.3 — Sandbox-Tests der operationellen Update-Formen (§5.9 Pkt. 2, Revision 2.8)
|
||||||
|
# Re-executierbar: bash run-sandbox.sh (ab Workspace-Root; Sandbox unter /tmp/sb33)
|
||||||
|
# Zweck: alle drei Update-Formen (Erweitern + Präzisieren + Korrigieren) + No-Op
|
||||||
|
# durchspielen; die Erhaltungs-Invariante (§5.9 Pkt. 5) als HARDE Assertion
|
||||||
|
# erzwingen (Diff nach Normalisierung ⊆ {betroffener Concept-Pfad, log}; keine
|
||||||
|
# neue Datei; kein Ghost-Diff); Zwei-Run-Identität (AD-17h/A0-19);
|
||||||
|
# Frontmatter-Konformität je mutiertem Concept (Vertrag §3.3/§3.4-Subset).
|
||||||
|
# Linux-Sandbox-Semantik auf einem /tmp-Baum — NIE der reale wiki/-Baum.
|
||||||
|
set -u
|
||||||
|
ROOT=$(mktemp -d /tmp/sb33-XXXXXX)
|
||||||
|
SB="$ROOT/sb"
|
||||||
|
mkdir -p "$SB/wiki" "$SB/raw"
|
||||||
|
cd "$SB"
|
||||||
|
git init -q
|
||||||
|
git config user.email "sandbox@test"
|
||||||
|
git config user.name "Sandbox"
|
||||||
|
|
||||||
|
# ---------- Basis-Baum (committete Ausgangslage = Baseline-Commit) ----------
|
||||||
|
# Concept alpha mit drei belegten Aussagen; Aussagen 1/2 sind fachlich korrekt,
|
||||||
|
# Aussage 3 ist fehlerhaft (Korrigieren-Ziel des Szenarios U3). beta ist ein
|
||||||
|
# nicht-betroffenes Kontroll-Concept (Ghost-Diff-Kontrolle, U5).
|
||||||
|
cat > wiki/index.md <<'EOF'
|
||||||
|
# Index
|
||||||
|
- [Alpha](alpha.md)
|
||||||
|
- [Beta](beta.md)
|
||||||
|
EOF
|
||||||
|
cat > wiki/alpha.md <<'EOF'
|
||||||
|
---
|
||||||
|
type: concept
|
||||||
|
sources:
|
||||||
|
- resource: raw/alpha-v1.md
|
||||||
|
id: s1
|
||||||
|
generated:
|
||||||
|
by: wow-compiler/0.1.0
|
||||||
|
at: 2026-08-16T09:00:00Z
|
||||||
|
---
|
||||||
|
Das Alpha-Protokoll verwendet deterministische-init-sequenz für den Abgleich (raw/alpha-v1.md#S-1).
|
||||||
|
Alpha läuft ausschließlich auf isolierten Netzen (raw/alpha-v1.md#S-3).
|
||||||
|
Alpha rotiert seine Schlüssel nie (raw/alpha-v1.md#S-2).
|
||||||
|
EOF
|
||||||
|
cat > wiki/beta.md <<'EOF'
|
||||||
|
---
|
||||||
|
type: concept
|
||||||
|
sources:
|
||||||
|
- resource: raw/beta-v1.md
|
||||||
|
id: s1
|
||||||
|
generated:
|
||||||
|
by: wow-compiler/0.1.0
|
||||||
|
at: 2026-08-16T09:00:00Z
|
||||||
|
---
|
||||||
|
Beta beschreibt ein anderes, hier nicht betroffenes Thema.
|
||||||
|
EOF
|
||||||
|
cat > wiki/log.md <<'EOF'
|
||||||
|
# Log
|
||||||
|
EOF
|
||||||
|
cat > raw/alpha-v1.md <<'EOF'
|
||||||
|
### S-1
|
||||||
|
Evidenz v1: deterministische-init-sequenz für den Abgleich.
|
||||||
|
### S-2
|
||||||
|
Evidenz v1: keine Rotation der Schlüssel.
|
||||||
|
### S-3
|
||||||
|
Evidenz v1: Alpha läuft auf isolierten Netzen.
|
||||||
|
EOF
|
||||||
|
cat > raw/beta-v1.md <<'EOF'
|
||||||
|
### S-1
|
||||||
|
Evidenz v1: Beta-Thema.
|
||||||
|
EOF
|
||||||
|
git add -A
|
||||||
|
git commit -qm "Baseline"
|
||||||
|
BASE=$(git rev-parse HEAD)
|
||||||
|
echo "BASELINE-COMMIT: $BASE"
|
||||||
|
echo "Sandbox-Root: $ROOT (loeschbar: rm -rf $ROOT)"
|
||||||
|
echo
|
||||||
|
|
||||||
|
runlabel() { echo; echo "########## $1 ##########"; }
|
||||||
|
# Isolation: Worktree auf BASE zuruecksetzen (kein Carry-over ueber Szenarien)
|
||||||
|
isolate() { git checkout -q -b "$1" "$BASE" 2>/dev/null || git checkout -q "$1"; git reset -q --hard "$BASE"; git clean -qfd wiki raw; }
|
||||||
|
|
||||||
|
# Pkt.-5-Probe (D-1-Form): Baseline-Diff + porcelain, normalisiert
|
||||||
|
# (wiki/-Praefix + .md-Suffix gestrippt, LC_ALL=C-sortiert; deterministisch, AD-17h)
|
||||||
|
probe() {
|
||||||
|
{ 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
|
||||||
|
}
|
||||||
|
inv_set() { probe | LC_ALL=C sort -u | paste -sd' ' -; }
|
||||||
|
|
||||||
|
# ---------- Harte Assertion der Erhaltungs-Invariante (§5.9 Pkt. 5) ----------
|
||||||
|
# Erwartete erlaubte Menge = Space-getrennte normalisierte Pfade
|
||||||
|
# (z. B. "alpha log"). Jeder Proben-Eintrag MUSS in der erlaubten Menge liegen —
|
||||||
|
# sonst Ghost-Diff (nicht betroffener Pfad) → HARD-FAIL, Exit 1 (NFR-4/FT-6).
|
||||||
|
assert_invariant() {
|
||||||
|
local expected="$1" got p bad=0 rcs=0
|
||||||
|
got=$(inv_set)
|
||||||
|
for p in $got; do
|
||||||
|
case " $expected " in
|
||||||
|
*" $p "*) ;;
|
||||||
|
*) echo "HARD-FAIL (Erhaltungs-Invariante §5.9 Pkt. 5): '$p' ist kein Ghost-Diff-negativer Eintrag — erlaubte Menge: {$expected}" >&2; bad=1;;
|
||||||
|
esac
|
||||||
|
done
|
||||||
|
# Keine neue Datei (Duplikat-Kontrolle: die ??-Sicht fehlt git diff allein)
|
||||||
|
rcs=$(git status --porcelain -- wiki/ | grep -c '^??' || true)
|
||||||
|
[ "$rcs" -eq 0 ] || { echo "HARD-FAIL (keine neue Datei): $rcs ungetrackte neue Datei(en) unter wiki/ (Duplikat/Ghost-Diff)" >&2; bad=1; }
|
||||||
|
if [ "$bad" -eq 0 ]; then
|
||||||
|
echo "RESULT: PASS — Probe {$got} ⊆ erlaubte Menge {$expected}; keine neue Datei; kein Ghost-Diff"
|
||||||
|
else
|
||||||
|
exit 1
|
||||||
|
fi
|
||||||
|
}
|
||||||
|
|
||||||
|
# ---------- Frontmatter-Konformitaet je mutiertem Concept (Vertrag §3.3/§3.4, §6.5) ----------
|
||||||
|
# $1=Datei; $2...=erwartete sources[].resource-Werte. Prueft: Top-Level-Key-Subset
|
||||||
|
# {type,sources,generated,verified,status,stale_after}, sources-Eintrag-Key-Subset
|
||||||
|
# (Vertrag §3.3-Innen-Ebene), type=concept, generated.at = volle ISO-8601-Datetime
|
||||||
|
# (die erlaubten Key-Mengen sind inline im awk-Subset-Vergleich hartkodiert).
|
||||||
|
assert_frontmatter() {
|
||||||
|
local f="$1"; shift
|
||||||
|
local r bad=0
|
||||||
|
# Kontextuelle Validierung ueber awk: Top-Level-Subset {type,sources,generated,
|
||||||
|
# verified,status,stale_after}; Innen-Ebenen je Sektion — sources: Vertrag §3.3-
|
||||||
|
# Subset {resource,id,title,author,usage_count,last_modified}; generated/verified:
|
||||||
|
# {by,at} (Vertrag §3.4/§3.5). Jeder andere Key = unbefugt (Punkt 6, §6.5).
|
||||||
|
local v
|
||||||
|
v=$(awk '
|
||||||
|
/^---$/{n++; if(n==2) exit; next}
|
||||||
|
/^[A-Za-z_][A-Za-z0-9_-]*:/{
|
||||||
|
k=$0; sub(/:.*/,"",k)
|
||||||
|
if (k=="sources") top="sources"
|
||||||
|
else if (k=="generated" || k=="verified") top="genver"
|
||||||
|
else top="other"
|
||||||
|
if (k!="type" && k!="sources" && k!="generated" && k!="verified" && k!="status" && k!="stale_after") print "TOP_UNBEFUGT:" k
|
||||||
|
# Duplikat-Prohibition: jeder Top-Level-Key hoechstens einmal (Punkt 13).
|
||||||
|
if (seenk[k]++) print "DUP_KEY:" k
|
||||||
|
# Canonische Reihenfolge (Vertrag §3.x Normalform: type, sources, generated,
|
||||||
|
# verified, status, stale_after): jeder neue Key-Kandidat muss der canonichen
|
||||||
|
# Ordnung folgen — Verstoß via Ordnungs-Rang erkannt (ORDER_VIOLATION).
|
||||||
|
r=0
|
||||||
|
if (k=="type") r=1; else if (k=="sources") r=2; else if (k=="generated") r=3
|
||||||
|
else if (k=="verified") r=4; else if (k=="status") r=5; else if (k=="stale_after") r=6
|
||||||
|
if (r>0 && r<lastr) print "ORDER_VIOLATION:" k
|
||||||
|
if (r>0) lastr=r
|
||||||
|
next
|
||||||
|
}
|
||||||
|
/^[[:space:]]/{
|
||||||
|
gsub(/^[[:space:]]+/,""); sub(/^- /,""); gsub(/^[[:space:]]+/,"");
|
||||||
|
if (match($0, /^[A-Za-z_][A-Za-z0-9_-]*:/)) {
|
||||||
|
ik=substr($0,1,RLENGTH-1)
|
||||||
|
if (top=="sources" && ik!="resource" && ik!="id" && ik!="title" && ik!="author" && ik!="usage_count" && ik!="last_modified") print "INNER_UNBEFUGT:" ik
|
||||||
|
if (top=="genver" && ik!="by" && ik!="at") print "INNER_UNBEFUGT:" ik
|
||||||
|
if (top=="other") print "INNER_UNBEFUGT:" ik
|
||||||
|
}
|
||||||
|
}
|
||||||
|
' "$f")
|
||||||
|
if [ -n "$v" ]; then
|
||||||
|
echo "HARD-FAIL (Frontmatter-Subset, Vertrag §3.3/§3.4/§3.5): $v in $f" >&2
|
||||||
|
exit 1
|
||||||
|
fi
|
||||||
|
grep -qE '^type: concept$' "$f" || { echo "HARD-FAIL: type=concept fehlt in $f" >&2; exit 1; }
|
||||||
|
grep -qE "^ at: [0-9]{4}-[0-9]{2}-[0-9]{2}T[0-9]{2}:[0-9]{2}:[0-9]{2}(Z|[+-][0-9]{2}:?[0-9]{2})$" "$f" || { echo "HARD-FAIL: generated.at ist keine volle ISO-8601-Datetime in $f" >&2; exit 1; }
|
||||||
|
for r in "$@"; do
|
||||||
|
grep -qF " - resource: $r" "$f" || { echo "HARD-FAIL: sources-Eintrag 'resource: $r' fehlt in $f" >&2; exit 1; }
|
||||||
|
done
|
||||||
|
echo "RESULT: PASS — Frontmatter-Konformitaet $f (Subset ok, generated.at volles Datetime)"
|
||||||
|
}
|
||||||
|
|
||||||
|
# ---------- Update-Helfer (deterministisch; at gepinnt fuer Zwei-Run-Identitaet) ----------
|
||||||
|
AT_NEW="2026-08-19T12:00:00Z"
|
||||||
|
bump_at() { sed -i "s|^ at: .*| at: $AT_NEW|" "$1"; }
|
||||||
|
add_source() { # $1=Datei $2=resource $3=id (Eintrag vor der generated:-Zeile einfuegen)
|
||||||
|
sed -i "s|^generated:| - resource: $2\n id: $3\ngenerated:|" "$1"
|
||||||
|
}
|
||||||
|
log_update() { # $1=Concept-Pfad $2=raw-Datei
|
||||||
|
printf '\n## 2026-08-19\n- Story 3.1-Update: %s (%s; Baseline %s)\n' "$1" "$2" "$BASE" >> wiki/log.md
|
||||||
|
}
|
||||||
|
|
||||||
|
# =====================================================================
|
||||||
|
runlabel "U1: ERWEITERN — neue belegte Aussage, bestehender Pfad wird erweitert (AC-1/FR-6)"
|
||||||
|
isolate u1
|
||||||
|
cat > raw/alpha-v2.md <<'EOF'
|
||||||
|
### S-4
|
||||||
|
Evidenz v2 (neue Aussage): Alpha-Replikation traegt einen zusaetzlichen Schluessel-Rotationszyklus.
|
||||||
|
EOF
|
||||||
|
git add -A; git commit -qm "Zuwachs raw/alpha-v2.md"
|
||||||
|
echo "--- Kandidaten-Erhebung: rg -l 'schluessel-rotationszyklus' wiki/ ---"
|
||||||
|
if command -v rg >/dev/null 2>&1; then rg -l 'schluessel-rotationszyklus' -g '!log.md' wiki/ || true
|
||||||
|
else grep -rl 'schluessel-rotationszyklus' --exclude=log.md wiki/ || true; fi
|
||||||
|
echo "--- UPDATE: neue Aussage als Absatz angefuegt (§5.5-Inline-Beleg), sources-Zuwachs s2, at-Bump ---"
|
||||||
|
cat >> wiki/alpha.md <<'EOF'
|
||||||
|
Alpha führt für die Replikation einen zusätzlichen Schlüssel-Rotationszyklus (raw/alpha-v2.md#S-4).
|
||||||
|
EOF
|
||||||
|
add_source wiki/alpha.md raw/alpha-v2.md s2
|
||||||
|
bump_at wiki/alpha.md
|
||||||
|
log_update alpha raw/alpha-v2.md
|
||||||
|
echo "--- Struktur-Erhaltung: bestehende drei Aussagen byte-identisch erhalten? ---"
|
||||||
|
grep -qF 'Das Alpha-Protokoll verwendet deterministische-init-sequenz für den Abgleich (raw/alpha-v1.md#S-1).' wiki/alpha.md || { echo "HARD-FAIL: Aussage 1 wurde beim Erweitern umgeschrieben" >&2; exit 1; }
|
||||||
|
grep -qF 'Alpha läuft ausschließlich auf isolierten Netzen (raw/alpha-v1.md#S-3).' wiki/alpha.md || { echo "HARD-FAIL: Aussage 2 (Netze) wurde beim Erweitern umgeschrieben" >&2; exit 1; }
|
||||||
|
grep -qF 'Alpha rotiert seine Schlüssel nie (raw/alpha-v1.md#S-2).' wiki/alpha.md || { echo "HARD-FAIL: Aussage 3 wurde beim Erweitern umgeschrieben" >&2; exit 1; }
|
||||||
|
echo "RESULT: PASS — bestehende belegte Aussagen unveraendert (Struktur-Erhaltungsregel Erweitern)"
|
||||||
|
echo "--- Probe (Pkt. 5, vor dem Commit) ---"; probe
|
||||||
|
assert_invariant "alpha log"
|
||||||
|
assert_frontmatter wiki/alpha.md raw/alpha-v1.md raw/alpha-v2.md
|
||||||
|
|
||||||
|
# =====================================================================
|
||||||
|
runlabel "U2: PRAEZISIEREN — bestehende Aussage wird an ihr selbst geschaerft (AC-2/FR-6)"
|
||||||
|
isolate u2
|
||||||
|
cat > raw/alpha-v2.md <<'EOF'
|
||||||
|
### S-1
|
||||||
|
Evidenz v2 (Praezisierung): die deterministische-init-sequenz wird nach der initialen Synchronisation zusaetzlich rotiert.
|
||||||
|
EOF
|
||||||
|
git add -A; git commit -qm "Zuwachs raw/alpha-v2.md"
|
||||||
|
echo "--- UPDATE: Aussage 1 an Position geschaerft, Beleg nachgefuehrt (Multi-Beleg §5.5); kein Satz-Umbau ---"
|
||||||
|
sed -i 's|^Das Alpha-Protokoll verwendet deterministische-init-sequenz für den Abgleich (raw/alpha-v1.md#S-1)\.|Das Alpha-Protokoll verwendet deterministische-init-sequenz für den Abgleich und rotiert sie nach der initialen Synchronisation zusätzlich (raw/alpha-v1.md#S-1; raw/alpha-v2.md#S-1).|' wiki/alpha.md
|
||||||
|
add_source wiki/alpha.md raw/alpha-v2.md s2
|
||||||
|
bump_at wiki/alpha.md
|
||||||
|
log_update alpha raw/alpha-v2.md
|
||||||
|
echo "--- Struktur-Erhaltung: Aussagen 2/3 unveraendert, geschaerfte Aussage 1 an Position? ---"
|
||||||
|
grep -qF 'Das Alpha-Protokoll verwendet deterministische-init-sequenz für den Abgleich und rotiert sie nach der initialen Synchronisation zusätzlich (raw/alpha-v1.md#S-1; raw/alpha-v2.md#S-1).' wiki/alpha.md || { echo "HARD-FAIL: geschaerfte Aussage fehlt" >&2; exit 1; }
|
||||||
|
grep -qF 'Alpha läuft ausschließlich auf isolierten Netzen (raw/alpha-v1.md#S-3).' wiki/alpha.md || { echo "HARD-FAIL: Aussage 2 wurde beim Praezisieren veraendert" >&2; exit 1; }
|
||||||
|
grep -qF 'Alpha rotiert seine Schlüssel nie (raw/alpha-v1.md#S-2).' wiki/alpha.md || { echo "HARD-FAIL: Aussage 3 wurde beim Praezisieren veraendert" >&2; exit 1; }
|
||||||
|
echo "RESULT: PASS — Schaerfung an der Aussage selbst, Position/Struktur erhalten, kein Satz-Umbau"
|
||||||
|
echo "--- Probe ---"; probe
|
||||||
|
assert_invariant "alpha log"
|
||||||
|
assert_frontmatter wiki/alpha.md raw/alpha-v1.md raw/alpha-v2.md
|
||||||
|
|
||||||
|
# =====================================================================
|
||||||
|
runlabel "U3: KORRIGIEREN — fehlerhafte Aussage abgeloest, nicht still geloescht (AC-2, AD-16-Default)"
|
||||||
|
isolate u3
|
||||||
|
cat > raw/alpha-v2.md <<'EOF'
|
||||||
|
### S-2
|
||||||
|
Evidenz v2 (Korrektur): Alpha rotiert seine Schluessel bei jeder Sitzung.
|
||||||
|
EOF
|
||||||
|
git add -A; git commit -qm "Zuwachs raw/alpha-v2.md"
|
||||||
|
echo "--- UPDATE: Aussage 3 wird explizit abgeloest + Ersetzungsbeleg; keine stille Loeschung ---"
|
||||||
|
sed -i 's|^Alpha rotiert seine Schlüssel nie (raw/alpha-v1.md#S-2)\.|Alpha rotiert seine Schlüssel nie (raw/alpha-v1.md#S-2) — überholt durch: Alpha rotiert seine Schlüssel bei jeder Sitzung (raw/alpha-v2.md#S-2).|' wiki/alpha.md
|
||||||
|
add_source wiki/alpha.md raw/alpha-v2.md s2
|
||||||
|
bump_at wiki/alpha.md
|
||||||
|
log_update alpha raw/alpha-v2.md
|
||||||
|
echo "--- AD-16-Default: alte Aussagen 1/2 textuell erhalten (keine stille Loeschung, keine flankierende Umschreibung)? ---"
|
||||||
|
grep -qF 'Das Alpha-Protokoll verwendet deterministische-init-sequenz für den Abgleich (raw/alpha-v1.md#S-1).' wiki/alpha.md || { echo "HARD-FAIL: Aussage 1 wurde beim Korrigieren flankierend umgeschrieben" >&2; exit 1; }
|
||||||
|
grep -qF 'Alpha läuft ausschließlich auf isolierten Netzen (raw/alpha-v1.md#S-3).' wiki/alpha.md || { echo "HARD-FAIL: Aussage 2 wurde beim Korrigieren flankierend umgeschrieben" >&2; exit 1; }
|
||||||
|
grep -qF 'Alpha rotiert seine Schlüssel nie (raw/alpha-v1.md#S-2)' wiki/alpha.md || { echo "HARD-FAIL: alte Aussage wurde still geloescht oder ihr Wortlaut verändert (AD-16, Struktur-Erhaltungsregel Korrigieren)" >&2; exit 1; }
|
||||||
|
grep -qF 'rotiert seine Schlüssel bei jeder Sitzung (raw/alpha-v2.md#S-2)' wiki/alpha.md || { echo "HARD-FAIL: Ersetzungsbeleg fehlt" >&2; exit 1; }
|
||||||
|
echo "RESULT: PASS — Abloesung mit Ersetzungsbeleg, Provenienz erhalten (AD-16-Default Erhaltung)"
|
||||||
|
echo "--- Probe ---"; probe
|
||||||
|
assert_invariant "alpha log"
|
||||||
|
assert_frontmatter wiki/alpha.md raw/alpha-v1.md raw/alpha-v2.md
|
||||||
|
|
||||||
|
# =====================================================================
|
||||||
|
runlabel "U4: NO_OP — Evidenz ist bereits vollstaendig im Body (engere Auslegung, Pkt. 2)"
|
||||||
|
isolate u4
|
||||||
|
cat > raw/alpha-v2.md <<'EOF'
|
||||||
|
Evidenz v2 (Redundanz): deterministische-init-sequenz fuer den Abgleich; Alpha rotiert seine Schluessel nie.
|
||||||
|
EOF
|
||||||
|
git add -A; git commit -qm "Zuwachs raw/alpha-v2.md"
|
||||||
|
echo "--- Kandidaten-Erhebung: Terme treffen alpha; die Evidenz ist bereits vollstaendig enthalten ---"
|
||||||
|
echo "--- UPDATE: KEINE Body-Mutation, KEIN at-Bump, KEIN sources-Zusatz, KEIN log.md-Eintrag (byte-identisch) ---"
|
||||||
|
if git status --porcelain -- wiki/ | grep -q .; then
|
||||||
|
echo "HARD-FAIL (No-Op): Wiki-Baum ist nicht byte-identisch" >&2
|
||||||
|
git status --porcelain -- wiki/
|
||||||
|
exit 1
|
||||||
|
fi
|
||||||
|
echo "RESULT: PASS — No-Op: keine Mutation, kein at-Bump, kein sources-Zusatz, kein log.md-Eintrag (byte-identisch)"
|
||||||
|
echo "--- Probe (leer = Ghost-Diff-negativ, leere Menge ist Teilmenge jeder erlaubten Menge) ---"; probe
|
||||||
|
assert_invariant ""
|
||||||
|
|
||||||
|
# =====================================================================
|
||||||
|
runlabel "U5: NEGATIV-KONTROLLE — Assertions-Mechanik erkennt einen Ghost-Diff (nicht vacuous)"
|
||||||
|
isolate u5
|
||||||
|
echo "unbefugte Mutation auf nicht-betroffenem beta" >> wiki/beta.md # simulierter Ghost-Diff
|
||||||
|
echo "--- Probe (erwartet: beta ausserhalb der erlaubten Menge {alpha log}) ---"; probe
|
||||||
|
if ( assert_invariant "alpha log" ) >/dev/null 2>&1; then
|
||||||
|
echo "HARD-FAIL (Assertions-Mechanik): Ghost-Diff auf beta wurde NICHT erkannt" >&2
|
||||||
|
exit 1
|
||||||
|
else
|
||||||
|
echo "RESULT: PASS — Ghost-Diff auf beta wurde erkannt (Assertions-Mechanik loest verlaesslich HARD-FAIL aus, kein Ghost-Diff kommt durch)"
|
||||||
|
fi
|
||||||
|
|
||||||
|
# =====================================================================
|
||||||
|
runlabel "U6: ZWEI-RUN-IDENTITAET (AD-17h/A0-19) — gleicher Git-State + gleiches Eingabeset -> identischer Update-Vorgang"
|
||||||
|
# Zwei unabhaengige Runs ueber dieselbe Evidenz (Erweitern); die Ergebnisse
|
||||||
|
# (mutierter Body + Frontmatter + Status) muessen byte-identisch sein.
|
||||||
|
run_erweitern() { # $1 = Branchname; mutiert Worktree, dann git add -A (Staging)
|
||||||
|
isolate "$1"
|
||||||
|
cat > raw/alpha-v2.md <<'EOF'
|
||||||
|
### S-4
|
||||||
|
Evidenz v2 (neue Aussage): Alpha-Replikation traegt einen zusaetzlichen Schluessel-Rotationszyklus.
|
||||||
|
EOF
|
||||||
|
git add -A; git commit -qm "Zuwachs raw/alpha-v2.md"
|
||||||
|
cat >> wiki/alpha.md <<'EOF'
|
||||||
|
Alpha führt für die Replikation einen zusätzlichen Schlüssel-Rotationszyklus (raw/alpha-v2.md#S-4).
|
||||||
|
EOF
|
||||||
|
add_source wiki/alpha.md raw/alpha-v2.md s2
|
||||||
|
bump_at wiki/alpha.md
|
||||||
|
log_update alpha raw/alpha-v2.md
|
||||||
|
git add -A # Staging — die Mutationen sind Teil des Runs (Commit-Boundary = Mutations-Boundary)
|
||||||
|
}
|
||||||
|
run_erweitern u6a
|
||||||
|
A_ALPHA=$(sha256sum wiki/alpha.md | cut -d' ' -f1) # Worktree-Inhalt = staged-Inhalt (git add)
|
||||||
|
A_LOG=$(sha256sum wiki/log.md | cut -d' ' -f1)
|
||||||
|
git commit -qm "Run A (Erweitern)"
|
||||||
|
A_ALPHA_COM=$(git show HEAD:wiki/alpha.md | sha256sum | cut -d' ' -f1)
|
||||||
|
run_erweitern u6b
|
||||||
|
B_ALPHA=$(sha256sum wiki/alpha.md | cut -d' ' -f1)
|
||||||
|
B_LOG=$(sha256sum wiki/log.md | cut -d' ' -f1)
|
||||||
|
git commit -qm "Run B (Erweitern)"
|
||||||
|
B_ALPHA_COM=$(git show HEAD:wiki/alpha.md | sha256sum | cut -d' ' -f1)
|
||||||
|
echo "Run A (alpha.md): $A_ALPHA"
|
||||||
|
echo "Run B (alpha.md): $B_ALPHA"
|
||||||
|
echo "Run A (log.md): $A_LOG"
|
||||||
|
echo "Run B (log.md): $B_LOG"
|
||||||
|
echo "Run A commit (alpha.md): $A_ALPHA_COM ; Run B commit (alpha.md): $B_ALPHA_COM"
|
||||||
|
if [ "$A_ALPHA" = "$B_ALPHA" ] && [ "$A_LOG" = "$B_LOG" ] && [ "$A_ALPHA_COM" = "$B_ALPHA_COM" ]; then
|
||||||
|
echo "RESULT: PASS — zwei unabhaengige Runs ueber dieselbe Evidenz -> identischer Update-Vorgang (AD-17h/A0-19)"
|
||||||
|
else
|
||||||
|
echo "HARD-FAIL (Determinismus-Vertrag): Run A und Run B weichen ab" >&2
|
||||||
|
exit 1
|
||||||
|
fi
|
||||||
|
|
||||||
|
# =====================================================================
|
||||||
|
runlabel "U7: MEHRFACH_TREFFER — zwei Neuevidenzen desselben Runs treffen denselben Concept-Pfad (Konsolidierung, I/O-Matrix)"
|
||||||
|
# Matrix-Zeile MEHRFACH_TREFFER: mehrere neue Wissenseinheiten desselben Runs auf
|
||||||
|
# denselben Pfad -> EIN konsolidiertes Update (eine Body-Mutation, EIN log.md-Eintrag,
|
||||||
|
# EIN konsolidierter sources-Zuwachs, EIN generated.at). Reihenfolge = Zuwachs-Sicht
|
||||||
|
# (Ankunftsreihenfolge der Belege); lexikografischer Tie-Break bei identischem Ort
|
||||||
|
# (Body-Ende) -> alpha-v2.md vor alpha-v3.md.
|
||||||
|
isolate u7
|
||||||
|
cat > raw/alpha-v2.md <<'EOF'
|
||||||
|
### S-4
|
||||||
|
Evidenz v2 (neue Aussage): Alpha-Replikation nutzt Quorum-Bestaetigung.
|
||||||
|
EOF
|
||||||
|
cat > raw/alpha-v3.md <<'EOF'
|
||||||
|
### S-4
|
||||||
|
Evidenz v3 (neue Aussage): Alpha-Replikation waechst linear zum Cluster.
|
||||||
|
EOF
|
||||||
|
git add -A; git commit -qm "Zwei Einheiten, ein Run (raw/alpha-v2.md + raw/alpha-v3.md)"
|
||||||
|
echo "--- Kandidaten-Erhebung: beide Terme treffen denselben Pfad alpha ---"
|
||||||
|
echo "--- KONSOLIDIERTES UPDATE: beide Aussagen als Absaetze angehaengt (Zuwachs-Sicht: v2 vor v3), EIN log-Eintrag, sources-Zuwachs s2+s3, EIN at ---"
|
||||||
|
cat >> wiki/alpha.md <<'EOF'
|
||||||
|
Alpha-Replikation nutzt Quorum-Bestaetigung (raw/alpha-v2.md#S-4).
|
||||||
|
Alpha-Replikation waechst linear zum Cluster (raw/alpha-v3.md#S-4).
|
||||||
|
EOF
|
||||||
|
add_source wiki/alpha.md raw/alpha-v2.md s2
|
||||||
|
add_source wiki/alpha.md raw/alpha-v3.md s3
|
||||||
|
bump_at wiki/alpha.md
|
||||||
|
log_update alpha "raw/alpha-v2.md + raw/alpha-v3.md"
|
||||||
|
echo "--- Konsolidierung: genau EIN log.md-Eintrag und EIN generated.at trotz zweier Einheiten? ---"
|
||||||
|
[ "$(grep -c 'Story 3.1-Update: alpha' wiki/log.md)" -eq 1 ] || { echo "HARD-FAIL: Mehrfach-Treffer erzeugte nicht exakt einen log.md-Eintrag (Konsolidierung oder Eintragspflicht Pkt. 4 verletzt)" >&2; exit 1; }
|
||||||
|
grep -qF 'raw/alpha-v2.md' wiki/log.md || { echo "HARD-FAIL: konsolidierter log.md-Eintrag verlinkt raw/alpha-v2.md nicht (Pkt. 4, genutzte raw/-Quellen)" >&2; exit 1; }
|
||||||
|
grep -qF 'raw/alpha-v3.md' wiki/log.md || { echo "HARD-FAIL: konsolidierter log.md-Eintrag verlinkt raw/alpha-v3.md nicht (Pkt. 4, genutzte raw/-Quellen)" >&2; exit 1; }
|
||||||
|
[ "$(grep -c '^ at:' wiki/alpha.md)" -eq 1 ] || { echo "HARD-FAIL: Mehrfach-Treffer erzeugte mehrere generated.at" >&2; exit 1; }
|
||||||
|
echo "--- Struktur-Erhaltung: alte Aussagen byte-identisch, beide neuen Aussagen vorhanden, Zuwachs-Sicht-Ordnung v2-vor-v3 ---"
|
||||||
|
grep -qF 'Das Alpha-Protokoll verwendet deterministische-init-sequenz für den Abgleich (raw/alpha-v1.md#S-1).' wiki/alpha.md || { echo "HARD-FAIL: Aussage 1 wurde beim konsolidierten Update umgeschrieben" >&2; exit 1; }
|
||||||
|
grep -qF 'Alpha läuft ausschließlich auf isolierten Netzen (raw/alpha-v1.md#S-3).' wiki/alpha.md || { echo "HARD-FAIL: Aussage 2 wurde beim konsolidierten Update umgeschrieben" >&2; exit 1; }
|
||||||
|
grep -qF 'Alpha rotiert seine Schlüssel nie (raw/alpha-v1.md#S-2).' wiki/alpha.md || { echo "HARD-FAIL: Aussage 3 wurde beim konsolidierten Update umgeschrieben" >&2; exit 1; }
|
||||||
|
grep -qF 'Quorum-Bestaetigung (raw/alpha-v2.md#S-4)' wiki/alpha.md || { echo "HARD-FAIL: neue Aussage aus v2 fehlt" >&2; exit 1; }
|
||||||
|
grep -qF 'waechst linear zum Cluster (raw/alpha-v3.md#S-4)' wiki/alpha.md || { echo "HARD-FAIL: neue Aussage aus v3 fehlt" >&2; exit 1; }
|
||||||
|
v2pos=$(grep -n 'Quorum-Bestaetigung' wiki/alpha.md | cut -d: -f1); v3pos=$(grep -n 'waechst linear' wiki/alpha.md | cut -d: -f1)
|
||||||
|
[ "$v2pos" -lt "$v3pos" ] || { echo "HARD-FAIL: Zuwachs-Sicht-Ordnung verletzt (v3 vor v2)" >&2; exit 1; }
|
||||||
|
echo "RESULT: PASS — ein konsolidiertes Update (eine Body-Aenderung, ein log-Eintrag, ein sources-Zuwachs s2+s3, ein at); Zuwachs-Sicht-Ordnung v2-vor-v3"
|
||||||
|
echo "--- Probe ---"; probe
|
||||||
|
assert_invariant "alpha log"
|
||||||
|
assert_frontmatter wiki/alpha.md raw/alpha-v1.md raw/alpha-v2.md raw/alpha-v3.md
|
||||||
|
|
||||||
|
# =====================================================================
|
||||||
|
runlabel "U8: STRUKTUR-VERLETZUNG — unbefugter Frontmatter-Key wird erkannt (Pkt. 5 Struktur-Ebene, P2-Check-Element (6))"
|
||||||
|
isolate u8
|
||||||
|
echo "--- simulierter Verstoß gegen die Struktur-Erhaltung: unbefugter Frontmatter-Key 'foo' im YAML-Block ---"
|
||||||
|
awk '/^type: concept$/{print; print "foo: bar"; next} {print}' wiki/alpha.md > /tmp/sb33-fm && mv /tmp/sb33-fm wiki/alpha.md
|
||||||
|
echo "--- Probe + Frontmatter-Konformität (erwartet: HARD-FAIL, Verstoß textuell benannt, NFR-4) ---"; probe
|
||||||
|
if ( assert_invariant "alpha log" && assert_frontmatter wiki/alpha.md ) >/dev/null 2>&1; then
|
||||||
|
echo "HARD-FAIL (Struktur-Ebene): unbefugter Frontmatter-Key wurde NICHT erkannt (Pkt. 5/Pkt. 6-Element (6))" >&2
|
||||||
|
exit 1
|
||||||
|
else
|
||||||
|
echo "RESULT: PASS — unbefugter Frontmatter-Key wird als Struktur-Verstoß erkannt (Frontmatter-Subset-HARD-FAIL ausgelöst)"
|
||||||
|
fi
|
||||||
|
|
||||||
|
# =====================================================================
|
||||||
|
runlabel "U9: NEUE-DATEI — ungetrackte neue Datei unter wiki/ wird erkannt (??-Sicht, Duplikat-Kontrolle)"
|
||||||
|
isolate u9
|
||||||
|
echo "--- simulierter Ghost-Diff: ungetrackte neue Datei wiki/neu.md (Duplikat, ??-Sicht) ---"
|
||||||
|
echo "unbefugte neue Concept-Datei" > wiki/neu.md
|
||||||
|
echo "--- Probe (erwartet: neu ausserhalb erlaubter Menge + ??-Sicht-HARD-FAIL) ---"; probe
|
||||||
|
if ( assert_invariant "alpha log" ) >/dev/null 2>&1; then
|
||||||
|
echo "HARD-FAIL (Keine-neue-Datei): ungetrackte neue Datei wiki/neu.md wurde NICHT erkannt (??-Sicht, Duplikat-Kontrolle)" >&2
|
||||||
|
exit 1
|
||||||
|
else
|
||||||
|
echo "RESULT: PASS — ungetrackte neue Datei unter wiki/ wird über die ??-Sicht erkannt (Duplikat/Ghost-Diff, keine neue Datei)"
|
||||||
|
fi
|
||||||
|
|
||||||
|
echo
|
||||||
|
echo "===== Sandbox abgeschlossen (alle 9 Tests U1-U9) ====="
|
||||||
|
echo "Sandbox-Root: $ROOT (loeschbar: rm -rf $ROOT)"
|
||||||
@@ -0,0 +1,777 @@
|
|||||||
|
#!/usr/bin/env bash
|
||||||
|
# Story 3.4 — Sandbox-Tests der Synthese-Dimension (§5.10, Revision 2.9)
|
||||||
|
# Re-executierbar: bash run-sandbox.sh (ab Workspace-Root; Sandbox unter /tmp/sb34)
|
||||||
|
# Zweck: die Synthese-Mechanik (§5.10) als re-executierbarer Run-Demonstrator
|
||||||
|
# durchspielen — Neu-Anlage aus 2+ raw/-Quellen mit sources >= 2 + gemischten
|
||||||
|
# Belegen (S1), Multi-Beleg-Konsolidierung (S2), Negativ-Kontrolle
|
||||||
|
# Aneinanderreihung / Reflektiertheits-Selbsttest (S3), Synthese-Update auf
|
||||||
|
# bestehendem Concept-Pfad (S4), Struktur-/Frontmatter-Invariante (S5),
|
||||||
|
# NO_OP-Synthese (N1: Evidenz bereits im Body -> volle Byte-Identitaet),
|
||||||
|
# Zwei-Run-Identitaet (S6, AD-17h/A0-19) + die Form-Wahl-Klassifikationsprobe
|
||||||
|
# (Story-3.3-Defer U2/U7: prueft die §5.9-Abgrenzungs-Reihenfolge
|
||||||
|
# Korrigieren -> Praezisieren -> Erweitern -> No-Op an einer gemischten Einheit).
|
||||||
|
# Erhaltungs-Invariante (§5.9 Pkt. 5) als HARDE Assertion; Frontmatter-
|
||||||
|
# Konformitaet (Vertrag §3.3/§3.4-Subset) je erzeugtem/aktualisiertem Concept.
|
||||||
|
# Linux-Sandbox-Semantik auf einem /tmp-Baum — NIE der reale wiki/-Baum.
|
||||||
|
set -u
|
||||||
|
ROOT=$(mktemp -d /tmp/sb34-XXXXXX)
|
||||||
|
SB="$ROOT/sb"
|
||||||
|
mkdir -p "$SB/wiki" "$SB/raw"
|
||||||
|
cd "$SB"
|
||||||
|
git init -q
|
||||||
|
git config user.email "sandbox@test"
|
||||||
|
git config user.name "Sandbox"
|
||||||
|
|
||||||
|
# ---------- Basis-Baum (committete Ausgangslage = Baseline-Commit) ----------
|
||||||
|
# Mini-Bundle mit zwei Bereichs-Index-freien Root-Concepts + Bundleroot as the
|
||||||
|
# Referenz: ein bereits bestehendes Concept `gamma` (nicht betroffen, Kontrolle).
|
||||||
|
# gamma ist das nicht-betroffene Kontroll-Concept (Ghost-Diff-Kontrolle, S3/S5).
|
||||||
|
# Die Synthese-Einheiten (S1: neu; S4: Update auf bestehendem Pfad alpha) werden
|
||||||
|
# je Szenario aus zwei committeten raw/-Quellen gespeist.
|
||||||
|
cat > wiki/index.md <<'EOF'
|
||||||
|
# Index
|
||||||
|
- [Alpha](alpha.md)
|
||||||
|
- [Gamma](gamma.md)
|
||||||
|
EOF
|
||||||
|
cat > wiki/alpha.md <<'EOF'
|
||||||
|
---
|
||||||
|
type: concept
|
||||||
|
sources:
|
||||||
|
- resource: raw/alpha-v1.md
|
||||||
|
id: s1
|
||||||
|
generated:
|
||||||
|
by: wow-compiler/0.1.0
|
||||||
|
at: 2026-08-16T09:00:00Z
|
||||||
|
---
|
||||||
|
Das Alpha-Protokoll definiert eine deterministische Init-Sequenz (raw/alpha-v1.md#S-1).
|
||||||
|
Alpha verwendet ausschließlich lokale Netze (raw/alpha-v1.md#S-2).
|
||||||
|
EOF
|
||||||
|
cat > wiki/gamma.md <<'EOF'
|
||||||
|
---
|
||||||
|
type: concept
|
||||||
|
sources:
|
||||||
|
- resource: raw/gamma-v1.md
|
||||||
|
id: s1
|
||||||
|
generated:
|
||||||
|
by: wow-compiler/0.1.0
|
||||||
|
at: 2026-08-16T09:00:00Z
|
||||||
|
---
|
||||||
|
Gamma beschreibt ein anderes, hier nicht betroffenes Thema.
|
||||||
|
EOF
|
||||||
|
cat > wiki/log.md <<'EOF'
|
||||||
|
# Log
|
||||||
|
EOF
|
||||||
|
# Bereits bestehende raw/-Dateien (Baseline-Baum)
|
||||||
|
cat > raw/alpha-v1.md <<'EOF'
|
||||||
|
### S-1
|
||||||
|
Evidenz v1: deterministische Init-Sequenz.
|
||||||
|
### S-2
|
||||||
|
Evidenz v1: ausschließlich lokale Netze.
|
||||||
|
EOF
|
||||||
|
cat > raw/gamma-v1.md <<'EOF'
|
||||||
|
### S-1
|
||||||
|
Evidenz v1: Gamma-Thema.
|
||||||
|
EOF
|
||||||
|
git add -A
|
||||||
|
git commit -qm "Baseline"
|
||||||
|
BASE=$(git rev-parse HEAD)
|
||||||
|
echo "BASELINE-COMMIT: $BASE"
|
||||||
|
echo "Sandbox-Root: $ROOT (loeschbar: rm -rf $ROOT)"
|
||||||
|
echo
|
||||||
|
|
||||||
|
runlabel() { echo; echo "########## $1 ##########"; }
|
||||||
|
# Isolation: Worktree auf BASE zuruecksetzen (kein Carry-over ueber Szenarien)
|
||||||
|
isolate() { git checkout -q -b "$1" "$BASE" 2>/dev/null || git checkout -q "$1"; git reset -q --hard "$BASE"; git clean -qfd wiki raw; }
|
||||||
|
|
||||||
|
# Erhaltungs-Invariante-Probe (D-1-Form, §5.9 Pkt. 5): Baseline-Diff + porcelain,
|
||||||
|
# normalisiert (wiki/-Praefix + .md-Suffix gestrippt, LC_ALL=C-sortiert)
|
||||||
|
probe() {
|
||||||
|
{ 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
|
||||||
|
}
|
||||||
|
inv_set() { probe | LC_ALL=C sort -u | paste -sd' ' -; }
|
||||||
|
|
||||||
|
# ---------- Harte Assertion der Erhaltungs-Invariante (§5.9 Pkt. 5) ----------
|
||||||
|
# assert_invariant: bricht bei Verstoß hart ab (exit 1; positive Erwartung).
|
||||||
|
# assert_invariant_ok: Non-Exiting-Variante (exit-code: 0 = Invariante gehalten,
|
||||||
|
# 1 = verletzt) — für Negativ-Kontrollen, die NUR erkennen sollen (§5.9 Pkt. 5,
|
||||||
|
# Verstoß textuell benannt, NFR-4), ohne dass die Assertion selbst den Run beendet.
|
||||||
|
inv_viol() { # $1=expected ; liefert 0, wenn erlaubte-Menge konsistent (keine Verletzung), !=0 sonst; msg auf stderr
|
||||||
|
# Alle Eintraege (getrackt wie ungetrackt) unter wiki/ muessen in $expected sein.
|
||||||
|
# Ungetrackte Eintraege ($??) sind NUR dann ein Verstoss, wenn sie ausserhalb der
|
||||||
|
# erlaubten Menge liegen (Pkt. 8: "keine neue Datei AUSSER echten Ziel-Pfaden" —
|
||||||
|
# legitime neue Ziel-Pfade sind in $expected enthalten; alle anderen sind Duplikat/
|
||||||
|
# Ghost-Diff). Die Dublette "keine neue Datei UEBERHAUPT" wuerde legitime neue
|
||||||
|
# Ziel-Pfade faelschlich verwerfen und ist hier bewusst NICHT formuliert.
|
||||||
|
local expected="$1" p u bad=0
|
||||||
|
got=$(inv_set)
|
||||||
|
for p in $got; do
|
||||||
|
case " $expected " in
|
||||||
|
*" $p "*) ;;
|
||||||
|
*) echo "HARD-FAIL (Erhaltungs-Invariante §5.9 Pkt. 5): '$p' ist kein Ghost-Diff-negativer Eintrag — erlaubte Menge: {$expected}" >&2; bad=1;;
|
||||||
|
esac
|
||||||
|
done
|
||||||
|
for u in $(git status --porcelain -- wiki/ | grep '^??' | awk '{print $2}'); do
|
||||||
|
u=$(echo "$u" | sed -e 's|^wiki/||' -e 's|\.md$||')
|
||||||
|
case " $expected " in
|
||||||
|
*" $u "*) ;;
|
||||||
|
*) echo "HARD-FAIL (Duplikat/Ghost-Diff): ungetrackte neue Datei '$u' liegt ausserhalb der erlaubten Ziel-Pfade {$expected} (Pkt. 8)" >&2; bad=1;;
|
||||||
|
esac
|
||||||
|
done
|
||||||
|
return $bad
|
||||||
|
}
|
||||||
|
assert_invariant() { # positive Erwartung: Verstoß => HARD-FAIL + Exit 1
|
||||||
|
if inv_viol "$1"; then
|
||||||
|
echo "RESULT: PASS — Probe erfüllt; keine neue Datei; kein Ghost-Diff"
|
||||||
|
else
|
||||||
|
exit 1
|
||||||
|
fi
|
||||||
|
}
|
||||||
|
# assert_frontmatter_ok: Non-Exiting-Variante von assert_frontmatter (wie oben:
|
||||||
|
# exit-code 0 = konform, 1 = Verstoß) für Negativ-Kontrollen, die erkennen sollen
|
||||||
|
# (Vertrag §3.3/§3.4-Subset, P2-Element (6)) — ohne den Run abzubrechen.
|
||||||
|
assert_frontmatter_ok() {
|
||||||
|
( assert_frontmatter "$@" ) >/dev/null 2>&1
|
||||||
|
}
|
||||||
|
|
||||||
|
# ---------- Frontmatter-Konformitaet (Vertrag §3.3/§3.4, §6.5) ----------
|
||||||
|
# $1=Datei; $2...=erwartete sources[].resource-Werte (in beliebiger Reihenfolge;
|
||||||
|
# der Determinismus der sources-Reihenfolge wird separat in S1/S4 geprueft).
|
||||||
|
assert_frontmatter() {
|
||||||
|
local f="$1"; shift
|
||||||
|
local r bad=0
|
||||||
|
local v
|
||||||
|
v=$(awk '
|
||||||
|
/^---$/{n++; if(n==2) exit; next}
|
||||||
|
/^[A-Za-z_][A-Za-z0-9_-]*:/{
|
||||||
|
k=$0; sub(/:.*/,"",k)
|
||||||
|
if (k=="sources") top="sources"
|
||||||
|
else if (k=="generated" || k=="verified") top="genver"
|
||||||
|
else top="other"
|
||||||
|
if (k!="type" && k!="sources" && k!="generated" && k!="verified" && k!="status" && k!="stale_after") print "TOP_UNBEFUGT:" k
|
||||||
|
if (seenk[k]++) print "DUP_KEY:" k
|
||||||
|
r=0
|
||||||
|
if (k=="type") r=1; else if (k=="sources") r=2; else if (k=="generated") r=3
|
||||||
|
else if (k=="verified") r=4; else if (k=="status") r=5; else if (k=="stale_after") r=6
|
||||||
|
if (r>0 && r<lastr) print "ORDER_VIOLATION:" k
|
||||||
|
if (r>0) lastr=r
|
||||||
|
next
|
||||||
|
}
|
||||||
|
/^[[:space:]]/{
|
||||||
|
gsub(/^[[:space:]]+/,""); sub(/^- /,""); gsub(/^[[:space:]]+/,"");
|
||||||
|
if (match($0, /^[A-Za-z_][A-Za-z0-9_-]*:/)) {
|
||||||
|
ik=substr($0,1,RLENGTH-1)
|
||||||
|
if (top=="sources" && ik!="resource" && ik!="id" && ik!="title" && ik!="author" && ik!="usage_count" && ik!="last_modified") print "INNER_UNBEFUGT:" ik
|
||||||
|
if (top=="genver" && ik!="by" && ik!="at") print "INNER_UNBEFUGT:" ik
|
||||||
|
if (top=="other") print "INNER_UNBEFUGT:" ik
|
||||||
|
}
|
||||||
|
}
|
||||||
|
' "$f")
|
||||||
|
if [ -n "$v" ]; then
|
||||||
|
echo "HARD-FAIL (Frontmatter-Subset, Vertrag §3.3/§3.4/§3.5): $v in $f" >&2
|
||||||
|
exit 1
|
||||||
|
fi
|
||||||
|
grep -qE '^type: concept$' "$f" || { echo "HARD-FAIL: type=concept fehlt in $f" >&2; exit 1; }
|
||||||
|
grep -qE "^ at: [0-9]{4}-[0-9]{2}-[0-9]{2}T[0-9]{2}:[0-9]{2}:[0-9]{2}(Z|[+-][0-9]{2}:?[0-9]{2})$" "$f" || { echo "HARD-FAIL: generated.at ist keine volle ISO-8601-Datetime in $f" >&2; exit 1; }
|
||||||
|
for r in "$@"; do
|
||||||
|
grep -qF " - resource: $r" "$f" || { echo "HARD-FAIL: sources-Eintrag 'resource: $r' fehlt in $f" >&2; exit 1; }
|
||||||
|
done
|
||||||
|
echo "RESULT: PASS — Frontmatter-Konformitaet $f (Subset ok, generated.at volles Datetime)"
|
||||||
|
}
|
||||||
|
|
||||||
|
# ---------- Synthese-Helfer (deterministisch; at gepinnt fuer Zwei-Run-Identitaet) ----------
|
||||||
|
AT_NEW="2026-08-19T12:00:00Z"
|
||||||
|
bump_at() { sed -i "s|^ at: .*| at: $AT_NEW|" "$1"; }
|
||||||
|
# add_source: Fuegt einen sources-Eintrag an seiner LEXIKOGRAFISCHEN Position ein
|
||||||
|
# (§5.10 Pkt. 2/8: die sources-Liste ist deterministisch nach `resource` sortiert,
|
||||||
|
# LC_ALL=C, AD-17h/A0-19 — nie appended). Einfuege-Zeile: erste `resource:`-Zeile,
|
||||||
|
# deren Wert lexikografisch > $res ist; sonst generated:-Zeile (Ende der sources-Liste).
|
||||||
|
# Die Einfuege-Position selbst wird ueber assert_sources_lex haert verifiziert.
|
||||||
|
add_source() { # $1=Datei $2=resource $3=id
|
||||||
|
local f="$1" res="$2" id="$3" ln
|
||||||
|
grep -qF " - resource: $res" "$f" && return 0 # bereits vorhanden -> kein Duplikat
|
||||||
|
ln=$(LC_ALL=C awk -v r="$res" '
|
||||||
|
$1=="-" && $2=="resource:" { name=$3; gsub(/\r/,"",name); if (name > r) { print NR; exit } }
|
||||||
|
/^generated:/ { print NR; exit }
|
||||||
|
' "$f")
|
||||||
|
[ -n "$ln" ] || ln=$(grep -n '^generated:' "$f" | head -1 | cut -d: -f1)
|
||||||
|
sed -i "${ln}i\\ - resource: $res\n id: $id" "$f"
|
||||||
|
}
|
||||||
|
# assert_sources_lex: verifiziert, dass die sources-resource-Werte in Datei-Reihenfolge
|
||||||
|
# exakt der LC_ALL=C-lexikografischen Ordnung entsprechen (§5.10 Pkt. 2 / Pkt. 8,
|
||||||
|
# AD-17h/A0-19 — deterministisch, unabhaengig von Datei-/Verarbeitungsreihenfolge).
|
||||||
|
assert_sources_lex() { # $1=Datei
|
||||||
|
local f="$1" file_order sorted_order
|
||||||
|
file_order=$(display_sources "$f")
|
||||||
|
sorted_order=$(display_sources "$f" | LC_ALL=C sort)
|
||||||
|
if [ "$file_order" != "$sorted_order" ]; then
|
||||||
|
echo "HARD-FAIL (sources-Reihenfolge, §5.10 Pkt. 2/8): die sources-Liste in $f ist nicht lexikografisch nach resource (LC_ALL=C) sortiert" >&2
|
||||||
|
echo " Datei-Reihenfolge: $file_order" >&2
|
||||||
|
echo " LC_ALL=C-Ordnung: $sorted_order" >&2
|
||||||
|
exit 1
|
||||||
|
fi
|
||||||
|
echo "RESULT: PASS — sources-Liste $f ist lexikografisch nach resource sortiert (LC_ALL=C, AD-17h/A0-19)"
|
||||||
|
}
|
||||||
|
# display_sources: gibt die sources-resource-Zeilen in Datei-Reihenfolge aus
|
||||||
|
display_sources() { grep -E '^ - resource: ' "$1"; }
|
||||||
|
|
||||||
|
log_anlage() { # $1=Concept-Pfad $2=quelle(n)
|
||||||
|
printf '\n## 2026-08-19\n- Synthese-Anlage: %s (%s; Baseline %s)\n' "$1" "$2" "$BASE" >> wiki/log.md
|
||||||
|
}
|
||||||
|
log_update() { # $1=Concept-Pfad $2=quelle(n)
|
||||||
|
printf '\n## 2026-08-19\n- Story 3.1-Update: %s (%s; Baseline %s)\n' "$1" "$2" "$BASE" >> wiki/log.md
|
||||||
|
}
|
||||||
|
|
||||||
|
# =====================================================================
|
||||||
|
runlabel "S1: NEU-ANLAGE — zwei raw/-Quellen desselben Themas -> EIN Synthese-Concept (sources >= 2, gemischte Belege; FR-7 AC-1/AC-2)"
|
||||||
|
isolate s1
|
||||||
|
cat > raw/synth-a.md <<'EOF'
|
||||||
|
### S-1
|
||||||
|
Evidenz a: das Delta-Protokoll kapselt die Zustands-Replikation.
|
||||||
|
### S-2
|
||||||
|
Evidenz a: Delta-Replikatbestaetigungen durchlaufen eine deterministische Quorum-Sequenz.
|
||||||
|
EOF
|
||||||
|
cat > raw/synth-b.md <<'EOF'
|
||||||
|
### S-1
|
||||||
|
Evidenz b: Delta-Betrieb setzt einen synchronen Konsens-Dienst voraus.
|
||||||
|
### S-2
|
||||||
|
Evidenz b: das Delta-Protokoll kapselt die Zustands-Replikation.
|
||||||
|
EOF
|
||||||
|
git add -A; git commit -qm "Zuwachs: raw/synth-a.md + raw/synth-b.md (zwei Quellen, ein Thema)"
|
||||||
|
echo "--- Synthese-Stimulus: zwei belegende raw/-Quellen (§5.10 Pkt. 1), Ziel-Pfad unbelegt -> Neu-Anlage via §5.7 ---"
|
||||||
|
echo "--- EIN Synthese-Concept delta: gemeinsame Repraesentation statt getrennter Zusammenfassungen (AC-1) ---"
|
||||||
|
cat > wiki/delta.md <<'EOF'
|
||||||
|
---
|
||||||
|
type: concept
|
||||||
|
sources:
|
||||||
|
- resource: raw/synth-a.md
|
||||||
|
id: s1
|
||||||
|
- resource: raw/synth-b.md
|
||||||
|
id: s2
|
||||||
|
generated:
|
||||||
|
by: wow-compiler/0.1.0
|
||||||
|
at: 2026-08-19T12:00:00Z
|
||||||
|
---
|
||||||
|
Das Delta-Protokoll kapselt die Zustands-Replikation (raw/synth-a.md#S-1).
|
||||||
|
Delta-Replikatbestaetigungen durchlaufen eine deterministische Quorum-Sequenz (raw/synth-a.md#S-2).
|
||||||
|
Delta-Betrieb setzt einen synchronen Konsens-Dienst voraus (raw/synth-b.md#S-1).
|
||||||
|
EOF
|
||||||
|
sed -i 's|^# Index$|# Index\n- [Delta](delta.md)|' wiki/index.md
|
||||||
|
log_anlage delta "raw/synth-a.md + raw/synth-b.md"
|
||||||
|
# KEIN git add -A auf wiki/: delta.md bleibt ungetrackt ($??) — die Pkt.-8-
|
||||||
|
# Duplikat-Kontrolle (über die ??-Sicht) wird so LEBENDIG geprüft (die Erhaltungs-
|
||||||
|
# Invarianz-Probe liest git-diff + porcelain beides aus).
|
||||||
|
echo "--- Assertion: sources >= 2 (jede belegende Quelle ein Eintrag), lexikografisch nach resource (LC_ALL=C, Pkt. 2/8) ---"
|
||||||
|
grep -qF ' - resource: raw/synth-a.md' wiki/delta.md || { echo "HARD-FAIL: sources-Eintrag raw/synth-a.md fehlt" >&2; exit 1; }
|
||||||
|
grep -qF ' - resource: raw/synth-b.md' wiki/delta.md || { echo "HARD-FAIL: sources-Eintrag raw/synth-b.md fehlt" >&2; exit 1; }
|
||||||
|
assert_sources_lex wiki/delta.md
|
||||||
|
echo "--- Assertion: gemischte claim-granulare Provenienz (§5.5) je Aussage — eine Repraesentation, Belege aus beiden Quellen ---"
|
||||||
|
grep -qF '(raw/synth-a.md#S-1)' wiki/delta.md || { echo "HARD-FAIL: Inline-Beleg raw/synth-a.md#S-1 fehlt" >&2; exit 1; }
|
||||||
|
grep -qF '(raw/synth-a.md#S-2)' wiki/delta.md || { echo "HARD-FAIL: Inline-Beleg raw/synth-a.md#S-2 fehlt" >&2; exit 1; }
|
||||||
|
grep -qF '(raw/synth-b.md#S-1)' wiki/delta.md || { echo "HARD-FAIL: Inline-Beleg raw/synth-b.md#S-1 fehlt" >&2; exit 1; }
|
||||||
|
echo "--- Assertion: keine per-Source-Zusammenfassungs-Struktur (AC-4, Reflektiertheits-Selbsttest Pkt. 5) ---"
|
||||||
|
if grep -nE 'Quelle [A-Z]:|Source [A-Z]:' wiki/delta.md; then
|
||||||
|
echo "HARD-FAIL (Reflektiertheit): per-Source-Struktur im Synthese-Concept (FR-7 AC-4)" >&2
|
||||||
|
exit 1
|
||||||
|
else
|
||||||
|
echo "RESULT: PASS — keine 'Quelle A: ... / Quelle B: ...'-Struktur; Aussagen tragen Provenienz-Tags"
|
||||||
|
fi
|
||||||
|
echo "--- Index-Link (Punkt 11) + log.md-Anlage-Eintrag (Pkt. 7: vollständige Multi-Source-sources-Liste im Eintrag) ---"
|
||||||
|
grep -qF -- '- [Delta](delta.md)' wiki/index.md || { echo "HARD-FAIL: delta fehlt in wiki/index.md (Punkt 11)" >&2; exit 1; }
|
||||||
|
grep -qF 'Synthese-Anlage: delta' wiki/log.md || { echo "HARD-FAIL: Anlage-Eintrag in log.md fehlt" >&2; exit 1; }
|
||||||
|
grep -qF 'raw/synth-a.md' wiki/log.md || { echo "HARD-FAIL: Multi-Source-Quelle raw/synth-a.md fehlt im log.md-Anlage-Eintrag (Pkt. 7)" >&2; exit 1; }
|
||||||
|
grep -qF 'raw/synth-b.md' wiki/log.md || { echo "HARD-FAIL: Multi-Source-Quelle raw/synth-b.md fehlt im log.md-Anlage-Eintrag (Pkt. 7)" >&2; exit 1; }
|
||||||
|
echo "--- Probe (Erhaltungs-Invariante §5.9 Pkt. 5; erlaubt: delta + index + log) ---"; probe
|
||||||
|
assert_invariant "delta index log"
|
||||||
|
assert_frontmatter wiki/delta.md raw/synth-a.md raw/synth-b.md
|
||||||
|
|
||||||
|
# =====================================================================
|
||||||
|
runlabel "S2: KONSOLIDIERUNG — redundante Aussage aus zwei Quellen -> EINE konsolidierte Aussage mit Multi-Beleg (FR-7 AC-3, AD-4)"
|
||||||
|
isolate s2
|
||||||
|
cat > raw/synth-c.md <<'EOF'
|
||||||
|
### S-1
|
||||||
|
Evidenz c: Delta-relevante Sitzungsschluessel unterliegen einer festen Lebensdauer.
|
||||||
|
### S-3
|
||||||
|
Evidenz c: Delta-Repraesentationen sind unveraenderlich nach Quorum-Bestaetigung.
|
||||||
|
EOF
|
||||||
|
cat > raw/synth-d.md <<'EOF'
|
||||||
|
### S-1
|
||||||
|
Evidenz d: Delta-relevante Sitzungsschluessel unterliegen einer festen Lebensdauer.
|
||||||
|
### S-4
|
||||||
|
Evidenz d: Delta-Repraesentationen speichern den konsolidierten Zustand.
|
||||||
|
EOF
|
||||||
|
git add -A; git commit -qm "Zuwachs: raw/synth-c.md + raw/synth-d.md (redundanter Befund)"
|
||||||
|
echo "--- Synthese: die redundante Aussage (Sitzungsschluessel) existiert in BEIDEN Quellen (§5.10 Pkt. 3) ---"
|
||||||
|
cat > wiki/delta.md <<'EOF'
|
||||||
|
---
|
||||||
|
type: concept
|
||||||
|
sources:
|
||||||
|
- resource: raw/synth-c.md
|
||||||
|
id: s1
|
||||||
|
- resource: raw/synth-d.md
|
||||||
|
id: s2
|
||||||
|
generated:
|
||||||
|
by: wow-compiler/0.1.0
|
||||||
|
at: 2026-08-19T12:00:00Z
|
||||||
|
---
|
||||||
|
Delta-relevante Sitzungsschluessel unterliegen einer festen Lebensdauer (raw/synth-c.md#S-1; raw/synth-d.md#S-1).
|
||||||
|
Delta-Repraesentationen sind unveraenderlich nach Quorum-Bestaetigung (raw/synth-c.md#S-3).
|
||||||
|
Delta-Repraesentationen speichern den konsolidierten Zustand (raw/synth-d.md#S-4).
|
||||||
|
EOF
|
||||||
|
sed -i 's|^# Index$|# Index\n- [Delta](delta.md)|' wiki/index.md
|
||||||
|
log_anlage delta "raw/synth-c.md + raw/synth-d.md"
|
||||||
|
# KEIN git add -A auf wiki/: delta.md ungetrackt ($??, legitimer Ziel-Pfad) —
|
||||||
|
# Pkt.-8-Duplikat-Kontrolle über die ??-Sicht wird lebendig geprüft.
|
||||||
|
echo "--- Assertion: EINE konsolidierte Aussage mit Multi-Beleg (Semikolon-Form, voller Pfad je Beleg); keine Beleg-Tilgung (AD-4) ---"
|
||||||
|
[ "$(grep -c 'Sitzungsschluessel' wiki/delta.md)" -eq 1 ] || { echo "HARD-FAIL: redundante Aussage wurde nicht zu einer Aussage konsolidiert (FR-7 AC-3)" >&2; exit 1; }
|
||||||
|
grep -qF '(raw/synth-c.md#S-1; raw/synth-d.md#S-1)' wiki/delta.md || { echo "HARD-FAIL: Multi-Beleg-Semikolon-Form fehlt oder ein Beleg wurde getilgt (AD-4)" >&2; exit 1; }
|
||||||
|
grep -qF '(raw/synth-c.md#S-3)' wiki/delta.md || { echo "HARD-FAIL: Einzelbeleg c#S-3 fehlt" >&2; exit 1; }
|
||||||
|
grep -qF '(raw/synth-d.md#S-4)' wiki/delta.md || { echo "HARD-FAIL: Einzelbeleg d#S-4 fehlt" >&2; exit 1; }
|
||||||
|
echo "--- Assertion: Reflektiertheit (AC-4) + sources-Ordnung (Pkt. 2/8) ---"
|
||||||
|
if grep -nE 'Quelle [A-Z]:|Source [A-Z]:' wiki/delta.md; then
|
||||||
|
echo "HARD-FAIL (Reflektiertheit): per-Source-Struktur (FR-7 AC-4)" >&2; exit 1
|
||||||
|
else
|
||||||
|
echo "RESULT: PASS — konsolidierte Aussage mit Multi-Beleg (kein Provenienz-Verlust), keine per-Source-Struktur"
|
||||||
|
fi
|
||||||
|
assert_sources_lex wiki/delta.md
|
||||||
|
echo "--- log-Anlage-Eintrag (Pkt. 7): vollständige Multi-Source-Liste (c + d) im Eintrag ---"
|
||||||
|
grep -qF 'raw/synth-c.md' wiki/log.md || { echo "HARD-FAIL: Multi-Source-Quelle raw/synth-c.md fehlt im log.md-Anlage-Eintrag (Pkt. 7)" >&2; exit 1; }
|
||||||
|
grep -qF 'raw/synth-d.md' wiki/log.md || { echo "HARD-FAIL: Multi-Source-Quelle raw/synth-d.md fehlt im log.md-Anlage-Eintrag (Pkt. 7)" >&2; exit 1; }
|
||||||
|
echo "--- Probe (erlaubt: delta + index + log) ---"; probe
|
||||||
|
assert_invariant "delta index log"
|
||||||
|
assert_frontmatter wiki/delta.md raw/synth-c.md raw/synth-d.md
|
||||||
|
|
||||||
|
# =====================================================================
|
||||||
|
runlabel "S3: NEGATIV-KONTROLLE ANEINANDERREIHUNG — 'Quelle A: ... / Quelle B: ...' wird vom Reflektiertheits-Selbsttest erkannt und vor Run-Abschluss umgebaut (FR-7 AC-4, NFR-7/NFR-4)"
|
||||||
|
isolate s3
|
||||||
|
echo "--- simuliertes (fehlerhaftes) Synthese-Ergebnis: per-Source-Zusammenfassungs-Struktur (verboten, §5.10 Pkt. 5) ---"
|
||||||
|
cat > wiki/delta.md <<'EOF'
|
||||||
|
---
|
||||||
|
type: concept
|
||||||
|
sources:
|
||||||
|
- resource: raw/synth-a.md
|
||||||
|
id: s1
|
||||||
|
- resource: raw/synth-b.md
|
||||||
|
id: s2
|
||||||
|
generated:
|
||||||
|
by: wow-compiler/0.1.0
|
||||||
|
at: 2026-08-19T12:00:00Z
|
||||||
|
---
|
||||||
|
Quelle A: das Delta-Protokoll kapselt die Zustands-Replikation.
|
||||||
|
Quelle B: Delta-Betrieb setzt einen synchronen Konsens-Dienst voraus.
|
||||||
|
EOF
|
||||||
|
echo "--- Reflektiertheits-Selbsttest (Pkt. 5, grepbasiert): erwartet: Befund 'Quelle A:' wird erkannt (nicht vacuous, NFR-7) ---"
|
||||||
|
if grep -nE 'Quelle [A-Z]:|Source [A-Z]:' wiki/delta.md; then
|
||||||
|
echo "BEFUND: Aneinanderreihungs-Struktur erkannt (Selbsttest-FAIL, textuell benannt, NFR-7/NFR-4)"
|
||||||
|
else
|
||||||
|
echo "HARD-FAIL (Reflektiertheits-Selbsttest): per-Source-Struktur wurde NICHT erkannt — Mechanik vacuous (FR-7 AC-4)" >&2
|
||||||
|
exit 1
|
||||||
|
fi
|
||||||
|
echo "--- Producer-Umbau vor Run-Abschluss (NFR-4): die Aussagen werden integriert, je Aussage mit Provenienz-Tag (§5.5) ---"
|
||||||
|
cat > wiki/delta.md <<'EOF'
|
||||||
|
---
|
||||||
|
type: concept
|
||||||
|
sources:
|
||||||
|
- resource: raw/synth-a.md
|
||||||
|
id: s1
|
||||||
|
- resource: raw/synth-b.md
|
||||||
|
id: s2
|
||||||
|
generated:
|
||||||
|
by: wow-compiler/0.1.0
|
||||||
|
at: 2026-08-19T12:00:00Z
|
||||||
|
---
|
||||||
|
Das Delta-Protokoll kapselt die Zustands-Replikation (raw/synth-a.md#S-1).
|
||||||
|
Delta-Betrieb setzt einen synchronen Konsens-Dienst voraus (raw/synth-b.md#S-1).
|
||||||
|
EOF
|
||||||
|
sed -i 's|^# Index$|# Index\n- [Delta](delta.md)|' wiki/index.md
|
||||||
|
log_anlage delta "raw/synth-a.md + raw/synth-b.md"
|
||||||
|
# KEIN git add -A auf wiki/: delta.md ungetrackt ($??, legitimer Ziel-Pfad) —
|
||||||
|
# Pkt.-8-Duplikat-Kontrolle über die ??-Sicht wird lebendig geprüft.
|
||||||
|
echo "--- Assertion: nach dem Umbau ist der Selbsttest leer (Integration hergestellt), nicht nur vertuscht ---"
|
||||||
|
if grep -qE 'Quelle [A-Z]:|Source [A-Z]:' wiki/delta.md; then
|
||||||
|
echo "HARD-FAIL (Reflektiertheit): per-Source-Struktur nach Umbau noch vorhanden (FR-7 AC-4)" >&2; exit 1
|
||||||
|
else
|
||||||
|
echo "RESULT: PASS — Aneinanderreihung erkannt und durch integrierte, provenance-versehene Aussagen ersetzt (NFR-4: textuell benannt, vor Run-Abschluss behoben)"
|
||||||
|
fi
|
||||||
|
echo "--- Probe (erlaubt: delta + index + log) ---"; probe
|
||||||
|
assert_invariant "delta index log"
|
||||||
|
assert_frontmatter wiki/delta.md raw/synth-a.md raw/synth-b.md
|
||||||
|
|
||||||
|
# =====================================================================
|
||||||
|
runlabel "S4: SYNTHESE-UPDATE — Synthese-Einheit trifft bestehenden Concept-Pfad -> §5.9-Formwahl + sources-Zuwachs um die zweite Quelle"
|
||||||
|
isolate s4
|
||||||
|
cat > raw/alpha-v2.md <<'EOF'
|
||||||
|
### S-3
|
||||||
|
Evidenz v2 (neue Aussage): Alpha ergaenzt die deterministische Init-Sequenz um einen zusaetzlichen Sync-Schritt.
|
||||||
|
EOF
|
||||||
|
cat > raw/alpha-v3.md <<'EOF'
|
||||||
|
### S-3
|
||||||
|
Evidenz v3 (neue Aussage): Alpha-Repraesentationen wachsen um einen kompakten Rotationsindex.
|
||||||
|
EOF
|
||||||
|
git add -A; git commit -qm "Zuwachs: raw/alpha-v2.md + raw/alpha-v3.md (zwei Quellen, Thema Alpha)"
|
||||||
|
echo "--- Synthese-Stimulus: zwei belegende raw/-Quellen zum selben Thema (Alpha) treffen den bestehenden Pfad alpha (Kandidatenliste §3 Pkt. 2) -> §5.9-Update ---"
|
||||||
|
echo "--- §5.9-Formwahl: neue belegte Aussagen (kein Ersatz, keine Schaerfung bestehender Formulierung) -> ERWEITERN (erste zutreffende Form) ---"
|
||||||
|
cat >> wiki/alpha.md <<'EOF'
|
||||||
|
Alpha ergänzt die deterministische Init-Sequenz um einen zusätzlichen Sync-Schritt (raw/alpha-v2.md#S-3).
|
||||||
|
Alpha-Repräsentationen wachsen um einen kompakten Rotationsindex (raw/alpha-v3.md#S-3).
|
||||||
|
EOF
|
||||||
|
add_source wiki/alpha.md raw/alpha-v2.md s2
|
||||||
|
add_source wiki/alpha.md raw/alpha-v3.md s3
|
||||||
|
bump_at wiki/alpha.md
|
||||||
|
log_update alpha "raw/alpha-v2.md + raw/alpha-v3.md"
|
||||||
|
# KEIN git add -A auf wiki/: alpha.md + log.md bleiben modifiziert-ungetrackt
|
||||||
|
# (porcelain ' M '); die Pkt.-8-??-Probe und der git-diff-Baseline-Vergleich
|
||||||
|
# lesen Worktree-Zustand, kein Staging nötig (isolate resettet je Szenario).
|
||||||
|
echo "--- Assertion: sources-Zuwachs um beide Quellen (>= 2 belegende Quellen, §5.10 Pkt. 2); bestehende Eintraege unveraendert ---"
|
||||||
|
grep -qF ' - resource: raw/alpha-v1.md' wiki/alpha.md || { echo "HARD-FAIL: bestehender sources-Eintrag alpha-v1 verloren (keine Entfernung ohne Beleg)" >&2; exit 1; }
|
||||||
|
grep -qF ' - resource: raw/alpha-v2.md' wiki/alpha.md || { echo "HARD-FAIL: sources-Zuwachs alpha-v2 fehlt" >&2; exit 1; }
|
||||||
|
grep -qF ' - resource: raw/alpha-v3.md' wiki/alpha.md || { echo "HARD-FAIL: sources-Zuwachs alpha-v3 fehlt" >&2; exit 1; }
|
||||||
|
assert_sources_lex wiki/alpha.md
|
||||||
|
echo "--- Assertion: gemischte Belege neu (v2/v3), bestehende belegte Aussagen byte-identisch (Struktur-Erhaltungsregel Erweitern, §5.9 Pkt. 2) ---"
|
||||||
|
grep -qF '(raw/alpha-v2.md#S-3)' wiki/alpha.md || { echo "HARD-FAIL: Beleg alpha-v2#S-3 fehlt" >&2; exit 1; }
|
||||||
|
grep -qF '(raw/alpha-v3.md#S-3)' wiki/alpha.md || { echo "HARD-FAIL: Beleg alpha-v3#S-3 fehlt" >&2; exit 1; }
|
||||||
|
grep -qF 'Das Alpha-Protokoll definiert eine deterministische Init-Sequenz (raw/alpha-v1.md#S-1).' wiki/alpha.md || { echo "HARD-FAIL: Aussage 1 wurde beim Synthese-Update umgeschrieben (Struktur-Erhaltung)" >&2; exit 1; }
|
||||||
|
grep -qF 'Alpha verwendet ausschließlich lokale Netze (raw/alpha-v1.md#S-2).' wiki/alpha.md || { echo "HARD-FAIL: Aussage 2 wurde beim Synthese-Update umgeschrieben (Struktur-Erhaltung)" >&2; exit 1; }
|
||||||
|
echo "--- Assertion: log.md-Eintrag 'Story 3.1-Update' (Pkt. 7) + Reflektiertheit (AC-4) ---"
|
||||||
|
grep -qF 'Story 3.1-Update: alpha' wiki/log.md || { echo "HARD-FAIL: Story 3.1-Update-Eintrag in log.md fehlt (Pkt. 7)" >&2; exit 1; }
|
||||||
|
if grep -nE 'Quelle [A-Z]:|Source [A-Z]:' wiki/alpha.md; then
|
||||||
|
echo "HARD-FAIL (Reflektiertheit): per-Source-Struktur (FR-7 AC-4)" >&2; exit 1
|
||||||
|
else
|
||||||
|
echo "RESULT: PASS — Synthese-Update: ein Ziel-Pfad, sources-Zuwachs s2+s3, gemischte Belege, bestehende Aussagen byte-identisch"
|
||||||
|
fi
|
||||||
|
echo "--- Probe (Pkt. 5; erlaubt: alpha (Update) + log — der Index-Link bleibt unveraendert, §5.9 Pkt. 3) ---"; probe
|
||||||
|
assert_invariant "alpha log"
|
||||||
|
assert_frontmatter wiki/alpha.md raw/alpha-v1.md raw/alpha-v2.md raw/alpha-v3.md
|
||||||
|
|
||||||
|
# =====================================================================
|
||||||
|
runlabel "S5: STRUKTUR-/FRONTMATTER-INVARIANTE — unbefugter Key oder nicht-lexikografische sources verletzt die Synthese-Struktur-Ebene (Pkt. 8, §5.9 Pkt. 5-Struktur-Ebene; P2-Element (6))"
|
||||||
|
isolate s5
|
||||||
|
echo "--- simulierter Verstoß: unbefugter Frontmatter-Key 'foo' in einem Synthese-Concept ---"
|
||||||
|
# Setup als regelkonforme Anlage (delta + Index-Link + log-Eintrag) — die Pfad-
|
||||||
|
# Set-Ebene ist damit legitim; der VERSTOSS sitzt ausschließlich in der Struktur-
|
||||||
|
# Ebene (unbefugter Key 'foo:', Vertrag §3.3/§3.4-Subset, P2-Element (6)).
|
||||||
|
cat > wiki/delta.md <<'EOF'
|
||||||
|
---
|
||||||
|
type: concept
|
||||||
|
sources:
|
||||||
|
- resource: raw/synth-a.md
|
||||||
|
id: s1
|
||||||
|
- resource: raw/synth-b.md
|
||||||
|
id: s2
|
||||||
|
generated:
|
||||||
|
by: wow-compiler/0.1.0
|
||||||
|
at: 2026-08-19T12:00:00Z
|
||||||
|
foo: bar
|
||||||
|
---
|
||||||
|
Das Delta-Protokoll kapselt die Zustands-Replikation (raw/synth-a.md#S-1).
|
||||||
|
EOF
|
||||||
|
sed -i 's|^# Index$|# Index\n- [Delta](delta.md)|' wiki/index.md
|
||||||
|
log_anlage delta "raw/synth-a.md + raw/synth-b.md"
|
||||||
|
# KEIN git add -A auf wiki/: delta.md ungetrackt — die Pkt.-8-??-Sicht wird
|
||||||
|
# in diesem Struktur-Szenario selbst geprüft.
|
||||||
|
echo "--- Assertions (erwartet: Frontmatter-Subset-HARD-FAIL, Verstoß textuell benannt, NFR-4; non-exiting Variante, denn der Szenario-Zweck ist das ERKENNEN, nicht eine positive Invarianten-Erwartung) ---"
|
||||||
|
# (a) Path-Set-Ebene: die Erhaltungs-Invariante selbst muss hier GEHALTEN sein
|
||||||
|
# (delta/index/log sind legitime Einträge); andernfalls wäre der Szenario-
|
||||||
|
# Zustand selbst schon inkonsistent (Pkt. 8, §5.9 Pkt. 5) — dann HARD-FAIL.
|
||||||
|
if inv_viol "delta index log"; then
|
||||||
|
:
|
||||||
|
else
|
||||||
|
echo "HARD-FAIL (Struktur-Ebene): Erhaltungs-Invariante unerwartet verletzt (unbefugter Pfad / neue Datei) — Szenario-Zustand inkonsistent (Pkt. 8)" >&2
|
||||||
|
exit 1
|
||||||
|
fi
|
||||||
|
# (b) Struktur-Ebene: der unbefugte Key 'foo:' MUSS erkannt werden (P2-Element (6),
|
||||||
|
# Vertrag §3.3/§3.4-Subset) — wenn nicht, ist die Erkennungs-Mechanik vacuous.
|
||||||
|
if assert_frontmatter_ok wiki/delta.md; then
|
||||||
|
echo "HARD-FAIL (Struktur-Ebene): unbefugter Frontmatter-Key wurde NICHT erkannt (P2-Element (6))" >&2
|
||||||
|
exit 1
|
||||||
|
fi
|
||||||
|
# (c) Pkt.-8-??-Negativkontrolle: eine UNGETRACKTE neue Datei AUSSERHALB der
|
||||||
|
# erlaubten Ziel-Pfade {delta index log} MUSS als Duplikat/Ghost-Diff
|
||||||
|
# HARD-FAILn (Pkt. 8 „keine neue Datei außer echten Ziel-Pfaden"; Story-
|
||||||
|
# 3.3-U9-Muster) — erkennt inv_viol die Verletzung, ist die Kontrolle
|
||||||
|
# nicht vacuous; erst danach ist die Setup-Zeile (virtueller Ortungs-
|
||||||
|
# Re-Run) zu entfernen und der Zustand für die positive Probe wiederherzustellen.
|
||||||
|
echo "--- Pkt.-8-??-Negativkontrolle: ungetrackte Nicht-Ziel-Datei muss als Duplikat/Ghost-Diff HARD-FAILn ---"
|
||||||
|
cat > wiki/ghost.md <<'EOF'
|
||||||
|
---
|
||||||
|
type: concept
|
||||||
|
sources:
|
||||||
|
- resource: raw/synth-a.md
|
||||||
|
id: s1
|
||||||
|
generated:
|
||||||
|
by: wow-compiler/0.1.0
|
||||||
|
at: 2026-08-19T12:00:00Z
|
||||||
|
---
|
||||||
|
Ghost-Diff-Versuch: keine echte Ziel-Pfad-Berechtigung.
|
||||||
|
EOF
|
||||||
|
echo "--- Probe mit erwartet-negativer Sicht: git-diff zeigt ghost + delta/index/log; ??-Sicht listet ghost + delta ---"
|
||||||
|
{ git diff --name-only "$BASE" -- wiki/ ; git diff --cached --name-only "$BASE" -- wiki/ ; git status --porcelain -- wiki/ | awk '{print $2}'; } \
|
||||||
|
| sed -e 's|^wiki/||' -e 's|\.md$||' | LC_ALL=C sort -u | paste -sd' ' -
|
||||||
|
if inv_viol "delta index log"; then
|
||||||
|
# inv_viol = 0 => KEINE Verletzung gemeldet => ghost.md wurde NICHT erkannt
|
||||||
|
# (die ??-Sicht/der Diff ignorieren die Nicht-Ziel-Datei) => Kontrolle vacuous
|
||||||
|
echo "HARD-FAIL (Pkt. 8-??-Probe): ghost.md ausserhalb der erlaubten Ziel-Pfade wurde NICHT als Duplikat/Ghost-Diff erkannt — Kontrolle vacuous" >&2
|
||||||
|
exit 1
|
||||||
|
else
|
||||||
|
# inv_viol != 0 => Verletzung gemeldet => ghost.md als Duplikat/Ghost-Diff erkannt
|
||||||
|
echo "BEFUND: ghost.md als Duplikat/Ghost-Diff erkannt (inv_viol meldet Verletzung, NFR-4) — Pkt.-8-??-Kontrolle ist nicht vacuous"
|
||||||
|
fi
|
||||||
|
rm wiki/ghost.md
|
||||||
|
echo "RESULT: PASS — unbefugter Key im Synthese-Concept wird als Struktur-Verstoß erkannt (Frontmatter-Subset-HARD-FAIL, textuell benannt); Pkt.-8-??-Negativkontrolle nicht vacuous"
|
||||||
|
|
||||||
|
# =====================================================================
|
||||||
|
runlabel "N1: NO_OP-SYNTHESE — Evidenz bereits vollständig im Body: keine Form greift -> No-Op (Nicht-Form), volle Byte-Identität (§5.10 Pkt. 3/8, §5.9 Pkt. 2)"
|
||||||
|
isolate n1
|
||||||
|
# Eine ZWEITE committete Quelle desselben Themas mit REDUNDANTER Evidenz: die
|
||||||
|
# Aussage (deterministische Init-Sequenz) existiert bereits im Body — belegt aus
|
||||||
|
# alpha-v1#S-1 (Baseline-Beleg; alpha-v1 ist die bestehende Evidenzbasis, NICHT
|
||||||
|
# Zuwachs). Die Zuwachs-Quelle alpha-syno.md (Anker #S-3) paraphrasiert dieselbe
|
||||||
|
# erkannte Wissenseinheit — kein neuer Befund, keine Schaerfung, kein Ersatz ->
|
||||||
|
# die Abgrenzungs-Reihenfolge §5.9 Pkt. 2 greift auf keiner Update-Form; die
|
||||||
|
# Synthese-Einheit läuft auf NO-OP (keine Form-Anwendung, keine Mutations-Phase
|
||||||
|
# — im Zweifel greift eine Form, engere Auslegung No-Op).
|
||||||
|
cat > raw/alpha-syno.md <<'EOF'
|
||||||
|
### S-3
|
||||||
|
Evidenz (synonym wiedergegeben): das Alpha-Protokoll definiert eine deterministische Init-Sequenz.
|
||||||
|
EOF
|
||||||
|
git add -A; git commit -qm "Zuwachs: raw/alpha-syno.md (redundante Evidenz zum Thema Alpha)"
|
||||||
|
echo "--- Synthese-Stimulus: die ZUWACHS-Quelle alpha-syno.md + die bestehende Evidenzbasis (alpha-v1, Baseline) belegen dasselbe Thema — die neue committete Evidenz (§1 Pkt. 1) ist alpha-syno.md ---"
|
||||||
|
echo "--- Abgrenzung §5.9 Pkt. 2: kein Ersatz / keine Schaerfung / keine NEUE belegte Aussage -> NO-OP (Nicht-Form) ---"
|
||||||
|
echo "--- RUN (No-Op): keine Mutations-Phase -> Bundle byte-identisch zum Baseline (kein Eintrag, kein at-Bump, kein sources-Zusatz) ---"
|
||||||
|
ALPHA_BEFORE=$(sha256sum wiki/alpha.md | cut -d' ' -f1)
|
||||||
|
LOG_BEFORE=$(sha256sum wiki/log.md | cut -d' ' -f1)
|
||||||
|
INDEX_BEFORE=$(sha256sum wiki/index.md | cut -d' ' -f1)
|
||||||
|
AT_BEFORE=$(grep -E '^ at: ' wiki/alpha.md)
|
||||||
|
# Die Mutations-Phase unterbleibt ex definitione; der Nachweis ist die volle
|
||||||
|
# Byte-Identität des Bundles (grept nichts, schreibt nichts, committet nichts).
|
||||||
|
ALPHA_AFTER=$(sha256sum wiki/alpha.md | cut -d' ' -f1)
|
||||||
|
LOG_AFTER=$(sha256sum wiki/log.md | cut -d' ' -f1)
|
||||||
|
INDEX_AFTER=$(sha256sum wiki/index.md | cut -d' ' -f1)
|
||||||
|
AT_AFTER=$(grep -E '^ at: ' wiki/alpha.md)
|
||||||
|
[ "$ALPHA_BEFORE" = "$ALPHA_AFTER" ] || { echo "HARD-FAIL (No-Op): alpha.md wurde trotz No-Op geaendert (byte-Identitaet, §5.9 Pkt. 2 / §5.10 Pkt. 3)" >&2; exit 1; }
|
||||||
|
[ "$LOG_BEFORE" = "$LOG_AFTER" ] || { echo "HARD-FAIL (No-Op): log.md wurde trotz No-Op geaendert (kein Eintrag, Pkt. 7-Negation)" >&2; exit 1; }
|
||||||
|
[ "$INDEX_BEFORE" = "$INDEX_AFTER" ] || { echo "HARD-FAIL (No-Op): index.md wurde trotz No-Op geaendert (kein neuer Link, Punkt-11-Negation)" >&2; exit 1; }
|
||||||
|
[ "$AT_BEFORE" = "$AT_AFTER" ] || { echo "HARD-FAIL (No-Op): generated.at-Bump trotz No-Op (kein at-Bump, §5.9 Pkt. 2)" >&2; exit 1; }
|
||||||
|
grep -qF ' - resource: raw/alpha-syno.md' wiki/alpha.md && { echo "HARD-FAIL (No-Op): sources-Zuwachs trotz No-Op (kein sources-Zusatz, §5.9 Pkt. 2)" >&2; exit 1; }
|
||||||
|
grep -q 'Synthese-Anlage\|Story 3.1-Update' wiki/log.md && { echo "HARD-FAIL (No-Op): log-Eintrag trotz No-Op (kein Eintrag)" >&2; exit 1; }
|
||||||
|
echo "--- Probe: erwartet LEER (Ghost-Diff-negativ; ein No-Op erzeugt keinen Diff, §5.9 Pkt. 5) ---"; probe
|
||||||
|
assert_invariant ""
|
||||||
|
echo "RESULT: PASS — No-Op-Synthese: byte-identisch (alpha/index/log), kein at-Bump, kein sources-Zusatz, kein log-Eintrag, keine neue Datei"
|
||||||
|
|
||||||
|
# =====================================================================
|
||||||
|
runlabel "N2: DISAGREEMENT (AD-16-Default, §5.10 Pkt. 3/7) — widersprüchliche Aussagen aus zwei Quellen werden NICHT still zusammengeführt; beide Behauptungen bleiben + Disagreement-Eintrag in log.md (Epic-4-Interface)"
|
||||||
|
isolate n2
|
||||||
|
# Zwei committete Quellen mit DISKREPANTEM Inhalt zur selben erkannten
|
||||||
|
# Wissenseinheit (Quorum-Konsens): Quelle A behauptet „synchrone Bestätigung",
|
||||||
|
# Quelle B „asynchrone Bestätigung". AD-16-Default: kein stilles Zusammenführen
|
||||||
|
# zu einer scheinbar eindeutigen Aussage; die widersprüchlichen Aussagen bleiben
|
||||||
|
# als Bestand bestehen (je mit ihrem Beleg/Beschreibungsstil + §5.5-Marker).
|
||||||
|
cat > raw/synth-e.md <<'EOF'
|
||||||
|
### S-1
|
||||||
|
Evidenz e: Quorum-Bestaetigungen erfolgen synchron.
|
||||||
|
### S-5
|
||||||
|
Evidenz e: Synchrone Quorum-Bestaetigungen halten die Replikate konsistent.
|
||||||
|
EOF
|
||||||
|
cat > raw/synth-f.md <<'EOF'
|
||||||
|
### S-1
|
||||||
|
Evidenz f: Quorum-Bestaetigungen erfolgen asynchron.
|
||||||
|
### S-6
|
||||||
|
Evidenz f: Asynchrone Quorum-Bestaetigungen erhoehen die Latenz.
|
||||||
|
EOF
|
||||||
|
git add -A; git commit -qm "Zuwachs: raw/synth-e.md + raw/synth-f.md (diskrepanter Befund zum selben Thema)"
|
||||||
|
echo "--- Synthese-Stimulus: zwei belegende Quellen desselben Themas mit WIDERSPRECHLICHEM Befund (S-1) ---"
|
||||||
|
echo "--- AD-16-Default (§5.10 Pkt. 3): KEINE stille Konsolidierung zu einer scheinbar eindeutigen Aussage; beide Behauptungen bleiben ---"
|
||||||
|
cat > wiki/delta.md <<'EOF'
|
||||||
|
---
|
||||||
|
type: concept
|
||||||
|
sources:
|
||||||
|
- resource: raw/synth-e.md
|
||||||
|
id: s1
|
||||||
|
- resource: raw/synth-f.md
|
||||||
|
id: s2
|
||||||
|
generated:
|
||||||
|
by: wow-compiler/0.1.0
|
||||||
|
at: 2026-08-19T12:00:00Z
|
||||||
|
---
|
||||||
|
Quorum-Bestaetigungen erfolgen synchron (raw/synth-e.md#S-1).
|
||||||
|
Quorum-Bestaetigungen erfolgen asynchron (raw/synth-f.md#S-1).
|
||||||
|
EOF
|
||||||
|
sed -i 's|^# Index$|# Index\n- [Delta](delta.md)|' wiki/index.md
|
||||||
|
# Disagreement-Eintrag (AD-16/§5.10 Pkt. 7, Epic-4-Interface): mutierter
|
||||||
|
# Concept-Pfad + die beiden konfligierenden Belege + Baseline-Commit.
|
||||||
|
printf '\n## 2026-08-19\n- Disagreement: delta — raw/synth-e.md#S-1 vs. raw/synth-f.md#S-1 (kein stilles Zusammenfuehren, AD-16; Baseline %s)\n' "$BASE" >> wiki/log.md
|
||||||
|
# KEIN git add -A auf wiki/: delta.md + log.md ungetrackt-modifiziert (??-Sicht lebendig).
|
||||||
|
echo "--- Assertion: BEIDE Behauptungen bleiben erhalten (kein stilles Zusammenfuehren, keine Beleg-Tilgung AD-4) ---"
|
||||||
|
grep -qF 'Quorum-Bestaetigungen erfolgen synchron (raw/synth-e.md#S-1).' wiki/delta.md || { echo "HARD-FAIL (Disagreement): Aussage e#S-1 wurde still entfernt oder umgeschrieben (AD-16)" >&2; exit 1; }
|
||||||
|
grep -qF 'Quorum-Bestaetigungen erfolgen asynchron (raw/synth-f.md#S-1).' wiki/delta.md || { echo "HARD-FAIL (Disagreement): Aussage f#S-1 wurde still entfernt oder umgeschrieben (AD-16)" >&2; exit 1; }
|
||||||
|
grep -qF '(raw/synth-e.md#S-1)' wiki/delta.md || { echo "HARD-FAIL (Disagreement): Beleg e#S-1 fehlt (AD-4)" >&2; exit 1; }
|
||||||
|
grep -qF '(raw/synth-f.md#S-1)' wiki/delta.md || { echo "HARD-FAIL (Disagreement): Beleg f#S-1 fehlt (AD-4)" >&2; exit 1; }
|
||||||
|
echo "--- Assertion: KEINE falsche Multi-Beleg-Konsolidierung der widerspruchlichen Aussagen (kein '(e; f)'-Zusammenfuehren) ---"
|
||||||
|
if grep -qF '(raw/synth-e.md#S-1; raw/synth-f.md#S-1)' wiki/delta.md; then
|
||||||
|
echo "HARD-FAIL (Disagreement): widerspruechliche Aussagen wurden als ein Multi-Beleg zusammengefuehrt (AD-16-Default verletzt, Schein-Eindeutigkeit)" >&2
|
||||||
|
exit 1
|
||||||
|
fi
|
||||||
|
echo "--- Assertion: Disagreement-Eintrag in log.md (Pkt. 7, AD-16, Epic-4-Interface) ---"
|
||||||
|
grep -qF 'Disagreement: delta' wiki/log.md || { echo "HARD-FAIL (Disagreement): Disagreement-Eintrag in log.md fehlt (§5.10 Pkt. 7)" >&2; exit 1; }
|
||||||
|
echo "--- Assertion: Reflektiertheit (AC-4) + sources-Lexikografie ---"
|
||||||
|
if grep -nE 'Quelle [A-Z]:|Source [A-Z]:' wiki/delta.md; then
|
||||||
|
echo "HARD-FAIL (Reflektiertheit): per-Source-Struktur trotz Disagreement (FR-7 AC-4)" >&2; exit 1
|
||||||
|
fi
|
||||||
|
assert_sources_lex wiki/delta.md
|
||||||
|
echo "--- Probe (erlaubt: delta + index + log) ---"; probe
|
||||||
|
assert_invariant "delta index log"
|
||||||
|
assert_frontmatter wiki/delta.md raw/synth-e.md raw/synth-f.md
|
||||||
|
echo "RESULT: PASS — Disagreement: beide Behauptungen + je Beleg bleiben; kein stilles Zusammenfuehren (AD-16-Default); log.md-Disagreement-Eintrag (Epic-4-Interface)"
|
||||||
|
|
||||||
|
# =====================================================================
|
||||||
|
runlabel "N3: AD-4c-UEBERNAHME-MARKER (Kontext-Marker, §5.10 Pkt. 4) — übernommene Formulierung aus einem bestehenden Concept traegt den §5.5-Kontext-Marker, nie alleinige Provenienz"
|
||||||
|
isolate n3
|
||||||
|
# Eine Synthese-Einheit übernimmt eine Formulierung aus einem BESTEHENDEN Concept
|
||||||
|
# (gamma): sie ist eine Kontext-/Synthese-Umformulierung, NICHT eigenständig
|
||||||
|
# gegen die Zuwachs-Quelle belegt. AD-4c: kein bestehendes Concept ist alleinige
|
||||||
|
# Provenienz eines anderen — die Übernahme trägt den §5.5-Kontext-Marker und
|
||||||
|
# bleibt textuell auf die Quelle des übernommenen Concepts rückverfolgbar.
|
||||||
|
cat > raw/synth-g.md <<'EOF'
|
||||||
|
### S-1
|
||||||
|
Evidenz g: Delta-Operationen respektieren die gamma-Kopplung.
|
||||||
|
EOF
|
||||||
|
cat > raw/synth-h.md <<'EOF'
|
||||||
|
### S-1
|
||||||
|
Evidenz h: Delta-Operationen verlangen die gamma-Kopplungs-Pruefung.
|
||||||
|
EOF
|
||||||
|
git add -A; git commit -qm "Zuwachs: raw/synth-g.md + raw/synth-h.md (Uebernahme-Thema)"
|
||||||
|
echo "--- Synthese-Einheit: zwei Zuwachs-Quellen (synth-g/h) zum selben Thema; die Kopplungs-Formulierung wird aus dem bestehenden Concept gamma uebernommen (AD-4c) ---"
|
||||||
|
cat > wiki/delta.md <<'EOF'
|
||||||
|
---
|
||||||
|
type: concept
|
||||||
|
sources:
|
||||||
|
- resource: raw/synth-g.md
|
||||||
|
id: s1
|
||||||
|
- resource: raw/synth-h.md
|
||||||
|
id: s2
|
||||||
|
generated:
|
||||||
|
by: wow-compiler/0.1.0
|
||||||
|
at: 2026-08-19T12:00:00Z
|
||||||
|
---
|
||||||
|
Delta-Operationen respektieren die Gamma-Kopplung (raw/synth-g.md#S-1).
|
||||||
|
Delta-Operationen verlangen die Gamma-Kopplungs-Pruefung (raw/synth-h.md#S-1).
|
||||||
|
Gamma-Kopplung: übernommen aus gamma auf Basis von raw/gamma-v1.md#S-1, nicht eigenständig belegt.
|
||||||
|
EOF
|
||||||
|
sed -i 's|^# Index$|# Index\n- [Delta](delta.md)|' wiki/index.md
|
||||||
|
log_anlage delta "raw/synth-g.md + raw/synth-h.md"
|
||||||
|
# KEIN git add -A auf wiki/: delta.md + log.md ungetrackt-modifiziert (??-Sicht lebendig).
|
||||||
|
echo "--- Assertion: die uebernommene Formulierung traegt den §5.5-Kontext-Marker (Muster „übernommen aus <Concept> auf Basis von <source>, nicht eigenständig belegt“) ---"
|
||||||
|
grep -qF 'übernommen aus gamma auf Basis von raw/gamma-v1.md#S-1, nicht eigenständig belegt' wiki/delta.md || { echo "HARD-FAIL (AD-4c): Kontext-Marker fehlt oder falsch (Muster §5.10 Pkt. 4 / §5.5-Pkt.-2)" >&2; exit 1; }
|
||||||
|
grep -qF 'nicht eigenständig belegt' wiki/delta.md || { echo "HARD-FAIL (AD-4c): 'nicht eigenständig belegt'-Klausel fehlt (§5.10 Pkt. 4)" >&2; exit 1; }
|
||||||
|
echo "--- Assertion: die eigenständig belegten Aussagen tragen KEINEN Kontext-Marker (Marker gilt nur für übernommene Formulierungen, Pkt. 4) ---"
|
||||||
|
grep -qE '^.*raw/synth-g\.md#S-1\).*übernommen aus' wiki/delta.md && { echo "HARD-FAIL (AD-4c): eigenständig belegte Aussage traegt faelschlich den Kontext-Marker (§5.10 Pkt. 4)" >&2; exit 1; }
|
||||||
|
echo "--- Assertion: Reflektiertheit + sources-Lexikografie + kein gamma-Duplikat ---"
|
||||||
|
if grep -nE 'Quelle [A-Z]:|Source [A-Z]:' wiki/delta.md; then
|
||||||
|
echo "HARD-FAIL (Reflektiertheit): per-Source-Struktur (FR-7 AC-4)" >&2; exit 1
|
||||||
|
fi
|
||||||
|
assert_sources_lex wiki/delta.md
|
||||||
|
grep -qF ' - resource: raw/gamma-v1.md' wiki/delta.md && { echo "HARD-FAIL (AD-4c): gamma-v1 als eigene sources-Quelle eingetragen — die Quelle des übernommenen Concepts ist nur im Kontext-Marker, nicht als source (AD-4c)" >&2; exit 1; }
|
||||||
|
echo "--- Probe (erlaubt: delta + index + log) ---"; probe
|
||||||
|
assert_invariant "delta index log"
|
||||||
|
assert_frontmatter wiki/delta.md raw/synth-g.md raw/synth-h.md
|
||||||
|
echo "RESULT: PASS — AD-4c-Uebernahme: Kontext-Marker traegt Concept + Basis-Quelle + 'nicht eigenständig belegt'; gamma bleibt nicht Quellen-Provenienz von delta"
|
||||||
|
|
||||||
|
# =====================================================================
|
||||||
|
runlabel "S6: ZWEI-RUN-IDENTITAET (AD-17h/A0-19) — gleicher Git-State + gleiches Eingabeset -> identischer Synthese-Vorgang"
|
||||||
|
run_synthese() { # $1 = Branchname; mutiert Worktree, dann git add -A (Staging)
|
||||||
|
isolate "$1"
|
||||||
|
cat > raw/synth-a.md <<'EOF'
|
||||||
|
### S-1
|
||||||
|
Evidenz a: das Delta-Protokoll kapselt die Zustands-Replikation.
|
||||||
|
### S-2
|
||||||
|
Evidenz a: Delta-Replikatbestaetigungen durchlaufen eine deterministische Quorum-Sequenz.
|
||||||
|
EOF
|
||||||
|
cat > raw/synth-b.md <<'EOF'
|
||||||
|
### S-1
|
||||||
|
Evidenz b: Delta-Betrieb setzt einen synchronen Konsens-Dienst voraus.
|
||||||
|
### S-2
|
||||||
|
Evidenz b: das Delta-Protokoll kapselt die Zustands-Replikation.
|
||||||
|
EOF
|
||||||
|
git add -A; git commit -qm "Zuwachs: raw/synth-a.md + raw/synth-b.md"
|
||||||
|
cat > wiki/delta.md <<'EOF'
|
||||||
|
---
|
||||||
|
type: concept
|
||||||
|
sources:
|
||||||
|
- resource: raw/synth-a.md
|
||||||
|
id: s1
|
||||||
|
- resource: raw/synth-b.md
|
||||||
|
id: s2
|
||||||
|
generated:
|
||||||
|
by: wow-compiler/0.1.0
|
||||||
|
at: 2026-08-19T12:00:00Z
|
||||||
|
---
|
||||||
|
Das Delta-Protokoll kapselt die Zustands-Replikation (raw/synth-a.md#S-1).
|
||||||
|
Delta-Replikatbestaetigungen durchlaufen eine deterministische Quorum-Sequenz (raw/synth-a.md#S-2).
|
||||||
|
Delta-Betrieb setzt einen synchronen Konsens-Dienst voraus (raw/synth-b.md#S-1).
|
||||||
|
EOF
|
||||||
|
sed -i 's|^# Index$|# Index\n- [Delta](delta.md)|' wiki/index.md
|
||||||
|
log_anlage delta "raw/synth-a.md + raw/synth-b.md"
|
||||||
|
git add -A # Staging — die Mutationen sind Teil des Runs (Commit-Boundary = Mutations-Boundary)
|
||||||
|
}
|
||||||
|
run_synthese s6a
|
||||||
|
A_DELTA=$(sha256sum wiki/delta.md | cut -d' ' -f1)
|
||||||
|
A_LOG=$(sha256sum wiki/log.md | cut -d' ' -f1)
|
||||||
|
A_INDEX=$(sha256sum wiki/index.md | cut -d' ' -f1)
|
||||||
|
git commit -qm "Run A (Synthese-Neu-Anlage)"
|
||||||
|
A_DELTA_COM=$(git show HEAD:wiki/delta.md | sha256sum | cut -d' ' -f1)
|
||||||
|
run_synthese s6b
|
||||||
|
B_DELTA=$(sha256sum wiki/delta.md | cut -d' ' -f1)
|
||||||
|
B_LOG=$(sha256sum wiki/log.md | cut -d' ' -f1)
|
||||||
|
B_INDEX=$(sha256sum wiki/index.md | cut -d' ' -f1)
|
||||||
|
git commit -qm "Run B (Synthese-Neu-Anlage)"
|
||||||
|
B_DELTA_COM=$(git show HEAD:wiki/delta.md | sha256sum | cut -d' ' -f1)
|
||||||
|
echo "Run A (delta.md): $A_DELTA ; Run B (delta.md): $B_DELTA"
|
||||||
|
echo "Run A (log.md): $A_LOG ; Run B (log.md): $B_LOG"
|
||||||
|
echo "Run A (index.md): $A_INDEX ; Run B (index.md): $B_INDEX"
|
||||||
|
echo "Run A commit (delta.md): $A_DELTA_COM ; Run B commit (delta.md): $B_DELTA_COM"
|
||||||
|
if [ "$A_DELTA" = "$B_DELTA" ] && [ "$A_LOG" = "$B_LOG" ] && [ "$A_INDEX" = "$B_INDEX" ] && [ "$A_DELTA_COM" = "$B_DELTA_COM" ]; then
|
||||||
|
echo "RESULT: PASS — zwei unabhaengige Synthese-Runs ueber dieselben zwei Quellen -> identisches Ergebnis (AD-17h/A0-19)"
|
||||||
|
else
|
||||||
|
echo "HARD-FAIL (Determinismus-Vertrag): Synthese-Run A und Run B weichen ab" >&2
|
||||||
|
exit 1
|
||||||
|
fi
|
||||||
|
|
||||||
|
# =====================================================================
|
||||||
|
runlabel "FW: FORM-WAHL-KLASSIFIKATIONSPROBE (Story-3.3-Defer U2/U7) — gemischte Synthese-Einheit an der §5.9-Abgrenzungs-Reihenfolge Korrigieren -> Praezisieren -> Erweitern -> No-Op"
|
||||||
|
isolate fw
|
||||||
|
# Eine Synthese-Einheit mit KORRIGIERENDEM Anteil: ersetzt die bestehende belegte
|
||||||
|
# Aussage (Netze) als fehlerhaft/ueberholt -> erste zutreffende Form = KORRIGIEREN.
|
||||||
|
cat > raw/alpha-k1.md <<'EOF'
|
||||||
|
### S-2
|
||||||
|
Evidenz k1 (Korrektur): Alpha kann seit v2 auch isolierte Netze bedienen.
|
||||||
|
EOF
|
||||||
|
cat > raw/alpha-k2.md <<'EOF'
|
||||||
|
### S-2
|
||||||
|
Evidenz k2 (staerkt den Korrektur-Befund): die Netzbeschraenkung ist aufgehoben.
|
||||||
|
EOF
|
||||||
|
git add -A; git commit -qm "Zuwachs: raw/alpha-k1.md + raw/alpha-k2.md (korrigierende Synthese-Einheit)"
|
||||||
|
echo "--- Einheit traegt zugleich neuen Beleg (S-1 bleibt) und Ersetzungs-Befund (S-2) ---"
|
||||||
|
echo "--- Abgrenzungs-Reihenfolge §5.9 Pkt. 2: (1) Ersetzung fehlerhaft/ueberholt -> KORRIGIEREN (erste zutreffende Form; die uebrigen Textgenauigkeits-Rahmen gelten je Teilbestand) ---"
|
||||||
|
sed -i 's|^Alpha verwendet ausschließlich lokale Netze (raw/alpha-v1.md#S-2)\.|Alpha verwendet ausschließlich lokale Netze (raw/alpha-v1.md#S-2) — überholt durch: Alpha kann seit v2 auch isolierte Netze bedienen (raw/alpha-k1.md#S-2; raw/alpha-k2.md#S-2).|' wiki/alpha.md
|
||||||
|
add_source wiki/alpha.md raw/alpha-k1.md s2
|
||||||
|
add_source wiki/alpha.md raw/alpha-k2.md s3
|
||||||
|
bump_at wiki/alpha.md
|
||||||
|
log_update alpha "raw/alpha-k1.md + raw/alpha-k2.md"
|
||||||
|
# KEIN git add -A auf wiki/: alpha.md + log.md modifiziert-ungetrackt (Probe
|
||||||
|
# liest git-diff + porcelain); isolate resettet je Szenario.
|
||||||
|
echo "--- Assertion: Abloesung mit Ersetzungsbeleg (keine stille Loeschung, AD-16-Default), alter Wortlaut erhalten, Multi-Beleg im Ersatz ---"
|
||||||
|
grep -qF 'Alpha verwendet ausschließlich lokale Netze (raw/alpha-v1.md#S-2)' wiki/alpha.md || { echo "HARD-FAIL: alter Wortlaut wurde still geloescht (AD-16, Korrigieren-Struktur-Erhaltung)" >&2; exit 1; }
|
||||||
|
grep -qF 'überholt durch: Alpha kann seit v2 auch isolierte Netze bedienen (raw/alpha-k1.md#S-2; raw/alpha-k2.md#S-2)' wiki/alpha.md || { echo "HARD-FAIL: Ersetzungsbeleg fehlt oder ist kein Multi-Beleg (Form-Wahl-Klassifikation)" >&2; exit 1; }
|
||||||
|
echo "--- Assertion: Nebenbefund (Aussage 1) bleibt byte-identisch (kein stiller Umbau, Textgenauigkeits-Rahmen) ---"
|
||||||
|
grep -qF 'Das Alpha-Protokoll definiert eine deterministische Init-Sequenz (raw/alpha-v1.md#S-1).' wiki/alpha.md || { echo "HARD-FAIL: Aussage 1 beim Korrigieren flankierend umgeschrieben" >&2; exit 1; }
|
||||||
|
echo "--- Assertion: sources >= 2 (beide korrigierende Quellen) + lexikografische Ordnung ---"
|
||||||
|
grep -qF ' - resource: raw/alpha-k1.md' wiki/alpha.md || { echo "HARD-FAIL: sources-Zuwachs alpha-k1 fehlt" >&2; exit 1; }
|
||||||
|
grep -qF ' - resource: raw/alpha-k2.md' wiki/alpha.md || { echo "HARD-FAIL: sources-Zuwachs alpha-k2 fehlt" >&2; exit 1; }
|
||||||
|
assert_sources_lex wiki/alpha.md
|
||||||
|
echo "--- Probe (erlaubt: alpha + log) ---"; probe
|
||||||
|
assert_invariant "alpha log"
|
||||||
|
assert_frontmatter wiki/alpha.md raw/alpha-v1.md raw/alpha-k1.md raw/alpha-k2.md
|
||||||
|
echo
|
||||||
|
echo "===== Sandbox abgeschlossen (S1-S6 + N1-N3 + Form-Wahl-Probe) ====="
|
||||||
|
echo "Sandbox-Root: $ROOT (loeschbar: rm -rf $ROOT)"
|
||||||
|
|
||||||
+140
@@ -0,0 +1,140 @@
|
|||||||
|
---
|
||||||
|
title: 'Relevanzbestimmung textual-deterministisch umsetzen (grep/ripgrep + Markdown-Traversal + Link-Following) (Story 3.2)'
|
||||||
|
type: 'feature'
|
||||||
|
created: '2026-08-19'
|
||||||
|
status: 'done'
|
||||||
|
review_loop_iteration: 3
|
||||||
|
baseline_commit: e3e7ec346df3e6190644d2c94e5cc7c42e6ed239
|
||||||
|
context:
|
||||||
|
- _bmad-output/implementation-artifacts/epic-3-context.md
|
||||||
|
---
|
||||||
|
|
||||||
|
<frozen-after-approval reason="human-owned intent — do not modify unless human renegotiates">
|
||||||
|
|
||||||
|
## Intent
|
||||||
|
|
||||||
|
**Problem:** Die Compiler-Instruktion (`schema/compiler.md` §3 Pkt. 2, Revision 2.4.2) erhebt die Update-Kandidatenliste bisher über einen **platzgehaltenen `<konzeptterm>`** („die Term-Auswahl folgt der §2-Interpretation"), dessen Ableitung (Kanonisierung, Synonyme, Mehrfach-Terme je Einheit) explizit „Story 3.2 vorbehalten" ist (`compiler.md:41`; §7 `:319`). Damit ist die Relevanzbestimmung nicht vollständig deterministisch vorgegeben (AD-17h/A0-19): dieselbe Evidenz kann je nach Term-Wahl unterschiedliche Candidate-Listen erzeugen — ein Embedding-freier, textuell-deterministischer Mechanismus fehlt (PRD OQ-3, AD-13, A0-18).
|
||||||
|
|
||||||
|
**Approach:** Story 3.2 löst die beiden Story-3.2-Vorbehalte auf und verankert in `schema/compiler.md` (D-3, rein textuell — kein Code, kein Standalone) den **feinkörnigen, textuell-deterministischen Relevanz-Findungsmechanismus** als verbindliche Ausformulierung der §3-Pkt.-2-Kandidatenerhebung: (a) **Term-Ziehverfahren** — die Candidate-Terme werden deterministisch aus der neuen Evidenz abgeleitet (bedeutungstragende Token-Folgen nach §2-Interpretation, durchgängige Normalisierung: lowercasing, `[-–_ ]`-Bindestrich-Varianten, ein kanonischer Schreibweisen-Resolver, mehrere Terme je Einheit erlaubt); (b) **Term-übergreifende Erhebung** über `wiki/` — grep/ripgrep, `index.md`-Traversal, Link-Following (dreistufig, mündet in die nachvollziehbare Candidate-Liste als relative OKF-Pfade ohne `.md`); (c) **Determinismus-Vertrag** — gleicher Git-State + gleiche Eingabemenge → gleiche Candidate-Liste in gleicher Reihenfolge (AD-17h/A0-19). Damit werden die Story-3.2-Vorbehalte in §3 Pkt. 2 und §7 aufgehoben. Vertrag (`schema/wiki-compiler.md`), Validator (`schema/validator.md`) und `raw/` bleiben read-only (AD-3); keine neue §7-Invaliditätsklasse.
|
||||||
|
|
||||||
|
## Boundaries & Constraints
|
||||||
|
|
||||||
|
**Always:**
|
||||||
|
- **Story 3.2 ist eine Instruktions-Story (D-3).** Der Relevanz-Findungsmechanismus wird ausschließlich in `schema/compiler.md` als deterministische Text-Instruktion verankert. Kein ausführbares Programm, kein Standalone, keine neue §7-Invaliditätsklasse, kein Change an `schema/wiki-compiler.md` / `schema/validator.md` / `raw/` (AD-3).
|
||||||
|
- **Determinismus (Kern, AD-17h/A0-19):** Die Relevanzbestimmung ist **deterministisch**: gleicher Git-State + gleiche Eingabemenge → identische Candidate-Liste, in identischer Reihenfolge (Zuwachs-Sicht-Ordnung; lexikografisch als deterministischer Tie-Break bei identischem Ort). Damit ist sie als nachvollziehbare Candidate-Liste (Concept-Pfade) verfügbar — deterministisch statt probabilistisch (AC-3).
|
||||||
|
- **Ausschließlich textuelle Mittel (AD-13, AC-1/AC-4, No-Goals):** Die Erhebung nutzt ausschließlich grep/ripgrep über `wiki/`, Markdown-Traversal von `index.md` und Link-Following (§5.6-Pin). **Kein** Einsatz von Embeddings, Vektor-Suche oder Knowledge-Graph-Datenbank im Compiler-Kern.
|
||||||
|
- **Kein Leasing-/Dirty-Tree-Scope in 3.2:** Leasing, Dirty-Tree, Staleness, Merge-Kollisionen bleiben Story 3.5/3.6; Commit-Boundary = Mutations-Boundary-Regel (AD-17f) und die Story-3.1-Bausteine (§5.9 Diff-Selbsttest, R-1/P2-Check-Block, INPUT_UNCOMMITTED-Abbruch, Update-Routing) bleiben unverändert — Story 3.2 ändert nur die **Erhebungs-Mechanik** der Candidate-Liste, nicht die Mutationspfade.
|
||||||
|
- `sprint-status.yaml`: Key `3-2-relevanzbestimmung-textual-deterministisch-umsetzen-grep-rip` → **in-progress**.
|
||||||
|
|
||||||
|
**Ask First:** Einführung nicht-textueller Mittel (Embeddings/Vector/KG) im Compiler-Kern (verboten durch AD-13, nur per Autorisierung änderbar) · Änderung der §5.6-Linkform (verboten durch A0-9) · AD-7d-Renames/Redirects · Validator-/Vertrags-/`raw/`-Change · Änderung der Commit-Boundary-Regel.
|
||||||
|
|
||||||
|
**Never:** Änderungen an `schema/wiki-compiler.md`/`schema/validator.md`/`raw/` (AD-3) · neue §7-Invaliditätsklasse · Standalone-Programm/Validator (D-3) · Embedding/Vector-Suche/KG im Compiler-Kern (AD-13, No-Goals) · Duplikat-Anlage eines bestehenden Concept-Pfads · „Regenerate Everything" (AD-5, A0-6).
|
||||||
|
|
||||||
|
## I/O & Edge-Case Matrix
|
||||||
|
|
||||||
|
| Scenario | Input / State | Expected Output / Behavior | Error Handling |
|
||||||
|
|----------|--------------|---------------------------|----------------|
|
||||||
|
| TERM_ABLEITUNG_SINGLETON | Neue Evidenz `raw/…` mit genau einem markanten Fachbegriff (z. B. `quanten-protocol-schlüssel`) | Term-Ziehverfahren ergibt genau diesen Begriff; grep-Erhebung über `wiki/` findet genau die Concept-Pfade mit diesem Term | N/A |
|
||||||
|
| TERM_ABLEITUNG_SYNONYM | Evidenz nennt einen Begriff in einer Schreibweise-Variante (z. B. `quanten protocol` vs. canonisch `quanten-protocol`) | Kanonisierungs-Resolver normalisiert auf die canonische Schreibweise; Erhebung findet die Concept-Pfade der canonischen Form | keine canonische Auflösung → Term wird wie notiert verwendet (kein stiller Ausschluss) |
|
||||||
|
| TERM_ABLEITUNG_MEHRFACH | Evidenz enthält mehrere bedeutungstragende Terme | Candidate-Liste = Vereinigung der Treffer über alle Terme; Vereinheitlichung über besuchte Menge (ein Pfad nur einmal) | N/A |
|
||||||
|
| TRAVERSAL_REACH_ONLY | Ein Konzeptterm trifft nur `wiki/index.md` (oder Area-`index.md`), nicht Concept-Bodies | `index.md`-Traversal (Root → Area → Concept, §5.8) liefert die darunter gewurzelten Concept-Pfade als Treffer | fehlende Bundleroot → Run-FAIL (V-1, besteht fort) |
|
||||||
|
| LINK_FOLLOWING_ZYKLUS | Concept-Links bilden einen Zyklus (A → B → A) | Link-Following mit **besuchter Menge** (aus Story 3.1): jeder Pfad nur einmal — keine Endlos-Schleife, endliche Candidate-Liste | N/A |
|
||||||
|
| NO_MATCH | Neuer Term trifft kein bestehendes Concept (keine Überschneidung) | Leere Candidate-Liste → UNTOUCHED_CONCEPT (Story-3.1-Pfad): keine Mutation, kein `log.md`-Zusatz | leere Menge ist Teilmenge jeder erlaubten Menge (Ghost-Diff-negativ) |
|
||||||
|
|
||||||
|
</frozen-after-approval>
|
||||||
|
|
||||||
|
## Code Map
|
||||||
|
|
||||||
|
- `schema/compiler.md` — **primär mutiert** (D-3, einziger Instruktions-Ort):
|
||||||
|
- §3 Reconcile Pkt. 2 (`:41`): **Story-3.2-Vorbehalt auflösen** — der feinkörnige Term-/Relevanz-Mechanismus wird eingearbeitet (Term-Ziehverfahren, Kanonisierungs-Resolver, drei Erhebungs-Stufen grep/ripgrep + Traversal + Link-Following, Candidate-Liste als relative OKF-Pfade ohne `.md`, Determinismus-Beschreibung); verortet als **neue Sektion §3.2 „Relevanzbestimmung (Story 3.2)"** direkt nach §3 — Kern-Anker bleibt Pkt. 2 („Erhebung nach §3.2").
|
||||||
|
- §7 Selbstbegrenzung (`:319`): **Story-3.2-Vorbehalt entfernen** („Feinkörnige Relevanz-Verfeinerung" entlassen) — verbleibende 3.x-Themen: Synthese → 3.4, Leasing/Dirty-Tree → 3.5/3.6.
|
||||||
|
- §8 Revisionslog (`:350–352`): **Revision 2.5** (Story 3.2) + **2.6** (Step-04-Loop-2-Patch-Runde) — Normreferenzen AD-13/A0-18/OQ-3 ergänzen (AD-17h steht bereits; **A0-19 wird ebenfalls ergänzt** — war im Ist-§8 noch nicht gelistet; auch `A0-19` als Determinismus-Referenz); Abschlussklausel (kein Vertrag-/Validator-/`raw/`-Change, keine neue §7-Klasse, kein Standalone). Rev 2.6 trägt zusätzlich die Loop-2-Patches (§4-Überschrift, rg-tool-korrekte Formen).
|
||||||
|
- §5.9 Pkt. 6 / P2-Check-Block: die Candidate-Erhebung über einen Zeiger (nicht Duplizieren) an den neuen §3.2-Mechanismus binden — **einschl. `--exclude=log.md`** (analog §5.6/§5.8-Formel), die Candidate-Liste ist auf Concept-Pfade definiert.
|
||||||
|
- **Resolver-Materialisierung:** der kanonische Schreibweisen-Resolver wird als **`canonical-terms.md` unter `schema/compiler.md` nebengeordnet** (neues Artefakt, gleiche read-only-Hierarchie): committete, append-only Registry (canonische Form + erlaubte Schreibvarianten + `[]`), als `§3.2`-Ziel referenziert. Damit ist der Resolver Bestandteil des Git-States und der Determinismus (gleicher Git-State → gleiche Liste) pinbar. (Kein `schema/`-Root-Change; Einbindung als normierte Referenz im §8.)
|
||||||
|
- §1 Pkt. 1/4, §5.6, §5.7, §5.8 — **read-only / nur Referenz** (Linkform, Bereichszuordnung, Discovery bleiben unverändert).
|
||||||
|
- `wiki/log.md` — **append** (append-only, Vertrag §5: bestehende Bullets — Story-3.1-done unter 2026-08-19, Validierungs-Rev-9, Story 2.5… — **bleiben unverändert erhalten**; der Story-3.2-Eintrag wird als weitere Bullet ergänzt, nicht ersetzt): Relevanzbestimmung-Semantik, Determinismus-Selbsttest-Beleg (Membership + Identität; der `--exclude=log.md`-Fakt aus der Stufe (a) wird ehrlich dokumentiert — `A0-18` trifft nur noch `wiki/knowledge-kompilation-inkrementell.md`, nicht `log.md`), Statuswechsel `3-2-…` `backlog → in-progress`, per-Datei-Validator-Verdikt-Zeile (Ist-Baum SUCCESS), einzeilige Nennung des 3.1-`epic-3-context.md`-Defer-Handoffs.
|
||||||
|
- `_bmad-output/implementation-artifacts/deferred-work.md` — **mutiert** (append-only): 3.1-Defer-Eintrag `epic-3-context.md` (`:335`, „Home: Story 3.2-Handoff oder Sprint-Sync") als aufgegriffen markieren; der F17-Handoff-Eintrag („Split 2026-08-19, Home: Story 3.8") ist bereits eingetragen. Bestehende Einträge nicht verändern, nur Status-Ergänzung im append-only-Stil.
|
||||||
|
- `_bmad-output/implementation-artifacts/sprint-status.yaml` — **mutiert**: Key `3-2-relevanzbestimmung-textual-deterministisch-umsetzen-grep-rip` (`:55`) → `in-progress`.
|
||||||
|
- `schema/validator.md`, `schema/wiki-compiler.md`, `raw/…` — **read-only** (AD-3). Story 3.2 mutiert selbst keine Concept-Inhalte; Demonstration per Sandbox-Durchlauf (Muster: `_bmad-output/implementation-artifacts/sandbox-3-1/run-sandbox.sh`, S1–S6) oder als textueller Selbsttest gegen den Ist-Baum (z. B. `rg -l`-Erhebung mit realem Term, ohne Inhalts-Mutation).
|
||||||
|
|
||||||
|
## Tasks & Acceptance
|
||||||
|
|
||||||
|
**Execution:**
|
||||||
|
- [x] `schema/compiler.md` — Story-3.2-Vorbehalte auflösen (§3 Pkt. 2 + §7): §3.2-Relevanzbestimmung als verbindliche dreistufige Erhebungs-Mechanik (Term-Ziehverfahren + Kanonisierungs-Resolver; `log.md`-Exklusion — rg `-g '!log.md'` bzw. grep `--exclude=log.md` — über `wiki/`; `index.md`-Traversal; Link-Following mit besuchter Menge; Candidate-Liste als relative OKF-Pfade ohne `.md`; Determinismus-Vertrag AD-17h/A0-19 mit Reihenfolge auch für Stufe-b/c und Normalisierung in §3.2 selbst); **canonical-terms.md** (Resolver-Registry: canon. Form + Varianten, append-only); §8-Revision 2.5 + Normreferenzen AD-13/A0-18/A0-19/PRD-OQ-3; Abschlussklausel. Kein Vertrag-/Validator-/`raw/`-Change. _(Inkl. Rev-2.6-Patch-Runde aus Step-04-Review Loop 2: §4-Überschrift wiederhergestellt, rg-tool-korrekte Formen, Mini-Sandbox verankert — s. Spec Change Log.)_
|
||||||
|
- [x] `wiki/log.md` — Story-3.2-Eintrag (Vertrag §5-Format, append-only — bestehende Bullets unverändert) mit Relevanzbestimmung-Semantik, Determinismus-Selbsttest-Beleg (Membership + Identität via `log.md`-Exklusion), Statuswechsel, Validator-Verdikt, epic-3-context-Defer-Nennung. _(Loop-2-Patch-Note (Rev 2.6) als eigene oberste Log-Zeile ergänzt.)_
|
||||||
|
- [x] `deferred-work.md` — epic-3-context-Eintrag als aufgegriffen markieren (append-only); `sprint-status.yaml` — Key `3-2-…` → `in-progress`. _(Zusätzlich Em-Dash-Determinismus-Frage als neuer Defer (Home: Story 3.8) aus Loop 2.)_
|
||||||
|
- [x] Edge-Tests (Sandbox, I/O-Matrix + Membership-Pin): TERM_ABLEITUNG_SINGLETON/SYNONYM/MEHRFACH, TRAVERSAL_REACH_ONLY, LINK_FOLLOWING_ZYKLUS, NO_MATCH — inkl. mini-Sandbox-Baum, der einen realen Term auf Concept-Bodies **und** `log.md` verteilt und die exakte Candidate-Liste (nur Concept-Pfade, `log.md` ausgeschlossen) als erwartete Ausgabe pindet. _(Sandbox T1–T4 re-executiert: alpha exklusiv, Zwei-Run-Identität, NO_MATCH leer, alpha+gamma Vereinigung.)_
|
||||||
|
|
||||||
|
**Acceptance Criteria:**
|
||||||
|
- Given eine neue committete Source, when ein Run die Relevanzbestimmung ausführt, then nutzt er ausschließlich textuelle, deterministische Verfahren — Term-übergreifende grep/ripgrep über `wiki/`, Markdown-Traversal von `index.md`, Link-Following (AC-1; AD-13, A0-18) — als verbindliche Ausformulierung der §3-Pkt.-2-Erhebung; die Story-3.2-Vorbehalte (§3 Pkt. 2, §7) sind aufgehoben.
|
||||||
|
- Given gleicher Git-State + gleiche Eingabemenge, when zwei unabhängige Runs die Relevanzbestimmung ausführen, then erzeugen sie dieselbe Candidate-Liste in derselben Reihenfolge (AC-2; AD-17h, A0-19) — ohne Embedding/Vector/KG im Compiler-Kern (AC-4; AD-13).
|
||||||
|
- Given ein Ergebnis der Relevanzbestimmung, when es weiterverarbeitet wird, then ist es als nachvollziehbare Candidate-Liste (relative OKF Concept-Pfade ohne `.md`) verfügbar (AC-3).
|
||||||
|
- Given die Instruktion, when geprüft, then bleibt `schema/validator.md`/`schema/wiki-compiler.md`/`raw/` unverändert (AD-3), keine neue §7-Klasse, kein Standalone (D-3) — Validator läuft auf dem Ist-Bundle SUCCESS.
|
||||||
|
|
||||||
|
### Review Findings
|
||||||
|
|
||||||
|
bmad-code-review Loop 3 (2026-08-19, 4 Layer: blind-hunter / edge-case-hunter / verification-gap / acceptance-auditor; Diff `e3e7ec3 → 3aa484b`, branch `story-3-2`). Triage: 5 `decision-needed`, 2 `patch`, 4 `defer` (→ `deferred-work.md`), 39 dismissed als Noise (u. a. doppelte Layer-Quellen pro Finding; `last_updated`-Zeitstempel = Story-3.1-Loop-2-Präzedenz; `deferred-work.md`-Bestands-Eintrag-in-Platz-Edit = vom frozen-Task-3-Defer-Handoff selbst befohlen; Em-Dash-Lücke bereits korrekt defer an Story 3.8; `sprint-status`-Key-Kürzung = Projekt-Schema; Sandbox-/tmp-Reste + `git add -A;`-Semikolon = Story-3.1-Sandbox-Muster-Präzedenz; `F17`-Home-„mit Story 3.2" = vorbestehend (Story-3.1-Review); `rg`-Verfügbarkeit im Audit-Environment = Audit-Beschränkung, keine Story-Lücke; `§5.6-Scan-Scope-Konvention`-Anker ist real (`compiler.md:157`); Formel-4-Ist-Zählung `38` re-executiert = `38`; „Validator 7 wiki/-Dateien" = korrekt, `ls wiki/` liefert 6 Einträge = 7 `.md`-Dateien (Area-Verz. zählt nicht); `canonical-terms.md`-Zwei-`[]`-Lesarten sind durch die Eröffnungs-Zeile + den Hinweis explizit aufgelöst; `A0-19`-Ergänzung in §8 = spec Change Log B5 als KEEP verankert).
|
||||||
|
|
||||||
|
- [x] [Review][Decision] Status-Flip `backlog → done` gegen gefrorene Always-Klausel (`→ in-progress`) — keine dokumentierte Renegotiation [sprint-status.yaml:55] — **Option 1 umgesetzt:** `done` bestätigt; Statuskette `in-progress → done` als eigener dokumentierter Schritt in `wiki/log.md` (neue oberste Bullet, Loop-3/Rev-2.7-Zeile)
|
||||||
|
- Befund: Der gefrorene `Boundaries & Constraints`-Abschnitt (Always) verlangt `sprint-status.yaml`-Key → **`in-progress`**; der Commit setzt direkt **`done`**. Die nicht-gefrorene Spec-Tail (`Manual checks`) sagt zwar „`backlog → in-progress → done`", aber (a) der Zwischenschritt `in-progress` ist in keinem `wiki/log.md`-Eintrag als eigener dokumentierter Statuswechsel belegt (Rev-2.5-Log zitiert `backlog → in-progress`, Rev-2.6 zitiert keinen `done`-Flip), (b) der Review-Workflow-Skript-Sync (bmad-build `sprint status` + Story 3.1-Präzedenz: Review-Abschluss setzt `done` im selben Loop) legt nahe, dass `done` der intendierte Endzustand ist. Entweder wurde die Always-Klausel stillschweigend superseded (nicht dokumentiert) oder der Key ist falsch.
|
||||||
|
- Optionen: **1 (empfohlen)** — `done` bestätigt (Sprint-Sync-Konvention: Review-Loop-Abschluss setzt `done`); in den Rev-2.6-Log-Zeile den Statusflip `in-progress → done` als dokumentierten Schritt ergänzen (Lückenschluss der Statuskette, keine Status-Änderung). **2** — Key auf `in-progress` zurücknehmen; Story bleibt `in-progress` bis ein späterer Run den `done`-Flip belegt.
|
||||||
|
- [x] [Review][Decision] Sandbox deckt I/O-Matrix-Szenarien `LINK_FOLLOWING_ZYKLUS`, `TRAVERSAL_REACH_ONLY`, `TERM_ABLEITUNG_SYNONYM` nicht ab — Task-4-Checkbox `[x]` überdeklariert [run-sandbox.sh:1-142] — **Option 1 umgesetzt:** T5/T6/T7 ergänzt, T2-Kommentar korrigiert, re-executiert (alle 7 Tests PASS, exit 0); Beleg in `wiki/log.md` (Loop-3-Zeile)
|
||||||
|
- Befund: `run-sandbox.sh` implementiert T1 (Membership), T2 (Zwei-Run-Identität), T3 (NO_MATCH), T4 (Vereinigung). `LINK_FOLLOWING_ZYKLUS` hat **keinen** Test (der Sandbox-Baum enthält keine Concept-Links — die besuchte Menge wird nie geübt); `TRAVERSAL_REACH_ONLY` ist nur Nebenprodukt von T2 (Term `alpha` trifft `index.md`; als Kommentar, nicht als gepinntes Szenario — und die gepinnte Ausgabe `index`+`alpha` widerspricht der §3.2-3b-Ordnungs-Semantik, weil Stufe-b-Treffer *nach* Stufe-a-Treffern positioniert sind und `index` kein Concept-Pfad ist); `TERM_ABLEITUNG_SYNONYM` ist ungetestet (leere Registry → der Fallback „wie notiert" ist der Standardfall, aber die Kanonisierung selbst wird nie geübt). Die Execution-Task-4-Checkbox `[x]` und Spec-Verification Pkt. 3 deklariert die volle I/O-Matrix-Abdeckung.
|
||||||
|
- Optionen: **1 (empfohlen)** — Sandbox um T5 (LINK_FOLLOWING_ZYKLUS: A→B→A-Links, erwartete endliche, doppelungsfreie Liste), T6 (TRAVERSAL_REACH_ONLY: Term nur in `index.md`, erwartete gewurzelte Concept-Pfade) und T7 (TERM_ABLEITUNG_SYNONYM: Registry-Eintrag mit Variante → Auflösung auf canonische Form) erweitern; T2-Kommentar zu `index` korrigieren; dann re-executieren und den Beleg nachführen. **2** — nur die fehlenden Szenarien als `deferred-work.md`-Eintrag an die nächste Compiler-Instruktions-Revision (oder Story 3.8, die den Determinismus-Vertrag absichert) übergeben; Task-4-Checkbox-Notiz ehrlich nachführen. **3** — T6/T7 als Defer, T5 (besuchte Menge) als Patch jetzt (weil §3.2-2c die Endlichkeits-Garantie trägt).
|
||||||
|
- [x] [Review][Decision] `wiki/log.md`-Selbsttest-Beleg (b) beschreibt einen Sandbox-Baum, der nicht dem committierten `run-sandbox.sh` entspricht (Term `quanten-protocol`, `sub/beta.md`, SHA-256 `159092bb…`) — Stale-Verifikations-Falle (exakt B1 aus Loop 2) [wiki/log.md:5] — **Option 1 umgesetzt:** Beleg (b) gegen die echte Sandbox-Ausgabe neu belegt (neue Log-Zeile, append-only); Rev-2.5-Zeile bleibt historisch
|
||||||
|
- Befund: Der Rev-2.5-Log-Eintrag (b) behauptet: Term `quanten-protocol` auf `wiki/alpha.md`, `wiki/sub/beta.md`, `log.md`; Candidate-Liste `alpha`, `sub/beta`; Zwei-Run-Identität via SHA-256 `159092bb…`. Das committierte, re-executierbare `run-sandbox.sh` trägt durchgängig den Term `deterministische-relevanz-bestimmung`, **keinen** `sub/`-Baum (Beta ist root-level `beta.md`) und **keine** SHA-256-Berechnung. Der „re-executierte" Nachweis ist damit nicht aus dem verankerten Artefakt reproduzierbar — dieselbe Stale-Evidenz-Falle, die Story 3.2 (Loop-2-B1) gerade schließen sollte.
|
||||||
|
- Optionen: **1 (empfohlen)** — Log-Beleg (b) gegen die echte `run-sandbox.sh`-Ausgabe re-executiert neu belegen (Term/Pfade/Ergebnisse an den Script-Ist-Baum angleichen); historischer Rev-2.5-Zeile eine Korrektur-Fußnote als neue Log-Zeile anhängen (append-only-Vertrag §5 erlaubt neue Zeilen, nicht Edit — die Rev-2.5-Zelle bleibt historisch, die neue Zeile korrigiert). **2** — die Sandbox auf den log.md-belegten Baum (Term `quanten-protocol`, `sub/`-Area) ändern und neu ausführen (weicht vom bereits in Rev-2.6 referenzierten Script ab).
|
||||||
|
- [x] [Review][Decision] `§3.2`-Pkt.-3b-Ordnung: „Reihenfolge des ziehenden Terms" ist undefiniert für Mehrfach-Terme — AD-17h-Zwei-Run-Identität hängt an einer nicht fixierten Term-Ordnung [schema/compiler.md:60] — **Option 1 umgesetzt:** Pkt. 3b auf reine Lexikografie (LC_ALL=C) gehoben; Term-Auftritt nur für Verarbeitungsreihenfolge (Rev-2.7)
|
||||||
|
- Befund: Pkt. 3b ordnet Stufe-a-Treffer „in der Reihenfolge des ziehenden Terms, dann lexikografisch als deterministischer Tie-Break bei identischem Ort", während Pkt. 1c mehrere Terme je Einheit erlaubt. Die Reihenfolge der **Terme selbst** (Auftreten in der Evidenz? lexikografisch? §2-Interpretations-Reihenfolge?) ist nirgends festgelegt — zwei rechtmäßige Term-Ordnungen erzeugen zwei rechtmäßige, aber unterschiedliche Listen. Zusätzlich ist die Formulierung intern doppelt definiert („Reihenfolge des ziehenden Terms" vs. „innerhalb jeder Stufe lexikografisch aufsteigend").
|
||||||
|
- Optionen: **1 (empfohlen)** — Pkt. 3b auf eine eindeutige Regel heben: Stufe-a-Treffer **rein lexikografisch (LC_ALL=C)**, Term-Auftritt dient nur der Verarbeitungs-/Interpretations-Reihenfolge, nicht der Listen-Ordnung (einfachste deterministische Form, kompatibel mit der „lexikografisch als Tie-Break"-Klausel). **2** — Term-Ordnung = lexikografisch über die gezogenen Terme, Stufe-a-Treffer in Term-Ordnung, dann lexikografisch (bewahrt die „Zuwachs-Sicht"-Semantik, ist etwas komplexer zu implementieren und zu beweisen).
|
||||||
|
- [x] [Review][Decision] `canonical-terms.md`-Registry-Lookup-Semantik ist unvollständig — Doppelbelegung von Varianten ist nicht deterministisch auflösbar, Lookup-Reihenfolge (vor/nach Kollaps, Groß/Klein) ist offen [schema/canonical-terms.md:25-35] — **Option 1 umgesetzt:** Lookup-Reihenfolge fixiert (normalisierte Form) + Eindeutigkeits-Invariante + Konflikt-Verfahren (Rev-2.7)
|
||||||
|
- Befund: (a) Zwei Einträge können dieselbe Schreibvariante mit unterschiedlichen canonischen Formen tragen — der Registry-Format-Abschnitt definiert keine Eindeutigkeits-Regel (kein „Variante in genau einem Eintrag", kein Konflikt-Verfahren; der „Append-only"-Regel-Abschnitt behandelt nur Umbenennungen). (b) Die Normalisierungs-Reihenfolge ist offen: lowercasing + `[-–_ ]`-Kollaps **vor** dem Registry-Lookup? Lookup auf der rohen Variante? Die Varianten-Spalte ist als „bündel-findend per `-`-Kollaps, lowercased" beschrieben, aber die verbindliche Lookup-Operation steht nicht da. Genau das ist der Kern des deterministischen Resolvers (AD-17h).
|
||||||
|
- Optionen: **1 (empfohlen)** — in `canonical-terms.md` Registry-Format ergänzen: (i) Lookup-Reihenfolge fixiert (lowercase → Kollaps → Lookup auf der normalisierten Form; die Varianten-Spalte trägt ebenfalls normalisierte Formen), (ii) Eindeutigkeits-Invariante „eine Variante in genau einem Eintrag" + Konflikt-Fall (Append nicht erlaubt; `deferred-work.md`-Handoff / Ask-First analog zur bestehenden Umbenennungs-Regel). **2** — nur (ii) ergänzen; (i) als `defer` an die nächste Registry-Befüllung (erstes Entry).
|
||||||
|
- [x] [Review][Patch] `run-sandbox.sh`: T1 (Membership-Pin) und T4 (Vereinigung) werden nur ausgegeben, nie als Pass/Fail geprüft — das gepinnte „exakte Candidate-Liste"-Verhalten (Task 4) wird nicht erzwungen [run-sandbox.sh:80-113, 136-141] — **umgesetzt:** T1/T4 tragen harte Asssertionen (`exit 1` bei Abweichung)
|
||||||
|
- Befund: T1 gibt die Candidate-Liste und „Erwartet: AUSSCHLIESSLICH 'alpha'" aus, vergleicht aber nie; T4 gibt `alpha, gamma` (gesortet) aus, prüft aber nicht gegen die Erwartung. Ein Regressions-Fall (z. B. `log` oder `index` rutscht in die Liste, oder `gamma` fehlt) beendet das Skript mit Exit 0 und „Sandbox abgeschlossen (alle 4 Tests)". T3 (NO_MATCH) und T2 (Zwei-Run-Identität) haben dagegen echte `if`-Checks mit `exit 1`.
|
||||||
|
- Fix: T1 `out=$(terms 'deterministische-relevanz-bestimmung' | normalize); [ "$out" = "alpha" ] || { echo "FAIL: …" >&2; exit 1; }`; T4 `out=$(terms '…' | normalize | LC_ALL=C sort | paste -sd, -); [ "$out" = "alpha,gamma" ] || { echo "FAIL: …" >&2; exit 1; }`.
|
||||||
|
- [x] [Review][Patch] Typos/Fehlzeichnungen im committeten normativen Text — `Determinsmus` (×4+ in `compiler.md`/`log.md`/`deferred-work.md`/Spec), `§3.2-beankert` (soll „§3.2-angeankert" sein), `Membrum` (soll „Mitglied" sein), `Konventionelle Determinismus-Lücke` (soll „Bekannte Determinismus-Lücke" sein — verweist auf `compiler.md:53`, wo es „Bekannte" heißt) [schema/compiler.md:351,373; wiki/log.md:5; deferred-work.md:342; spec:80,93,106] — **umgesetzt** (reiner Text-Patch; `raw/`-Source-Typo und der präexistierende `außschließlich`-Typo im 3.1-Log bleiben unberührt — out-of-scope)
|
||||||
|
- Befund: Keine AC-Auswirkung, aber der Text ist die committete Instruktion/der committete Nachweis. `Determinsmus` steht auch in der Source `raw/epics/` (3×), die Instruktion sollte den Begriff aber konsistent korrekt verwenden, wie es der Rest des Dokuments tut. `Resovierung` (spec:80,106) ist zusätzlich zu `Resolution`/`Auflösung` zu korrigieren.
|
||||||
|
- Fix: orthografische Korrektur in den genannten Zeilen (reiner Text-Patch, keine Semantik-Änderung).
|
||||||
|
- [x] [Review][Defer] `§3.2`-Pkt.-2a: Wortgrenzen-/Frontmatter-Scope der Stufe-a-Match-Semantik ist offen (Substring-Match ohne `\b`, Frontmatter-Treffer zählen mit) [schema/compiler.md:55] — deferred, pre-existing
|
||||||
|
- [x] [Review][Defer] `§3.2`-Pkt.-1b-ii: Kollaps bei aufeinanderfolgenden/führenden/trailenden Separatoren ist unbestimmt (`a--b`, `-x`) [schema/compiler.md:51] — deferred, pre-existing
|
||||||
|
- [x] [Review][Defer] Stufe-a-Treffer auf `index.md`-Pfade (z. B. T2 `index`) werden nicht deterministisch aus der finalen Candidate-Liste entfernt (Stufe-b-Re-Routing implizit, nicht fixiert) [schema/compiler.md:55-56] — deferred, pre-existing
|
||||||
|
- [x] [Review][Defer] Rev-2.5-/Rev-2.6-Log-Zeile und compiler.md-Revisionslog: Nachweis-Klärigungen ohne Semantik-Auswirkung — (a) Rev-2.5-Log-Zelle zitiert die (nun historisch korrigierte) `rg --exclude`-Form im aktiven Mechanismus-Teil, ohne eigene Inline-Korrektur (Rev-2.6-Zelle erklärt es nur), (b) `last_updated: 08-19-2026 07:10` liegt vor dem Commit-Zeitpunkt (09:16), (c) Rev-2.6 steht im Revisionslog **über** Rev-2.5 (chronologisch umgekehrt), (d) Validator-„7/7 SUCCESS" als Aggregat ohne per-Datei-Liste, (e) Rev-2.6-`git status`-Beleg listet `canonical-terms.md`/`_bmad-output/`-Änderungen nicht (nämte „`git status`" als Prüfgrundlage), (f) Formel-4-Ist-Zählung `38` ohne Baseline-`≡`-Partner (re-executiert: Ist = 38, korrekt; nur der Beleg-String ist unvollständig) [wiki/log.md:4-5; schema/compiler.md:372-373; sprint-status.yaml:32] — deferred, pre-existing
|
||||||
|
|
||||||
|
## Spec Change Log
|
||||||
|
|
||||||
|
- **2026-08-19 (bmad-code-review Loop 3 — Review-Findings umgesetzt; 5 Decisions (alle Option 1) + 2 Patches + 4 Defers):** `schema/compiler.md` → **Revision 2.7**: (1) **D-4** — §3.2-Pkt.-3b-Ordnung auf **reine Lexikografie (LC_ALL=C)** gehoben; die Term-Verarbeitungsreihenfolge bestimmt nur die Interpretation/Erhebung, **nicht** die Listen-Ordnung (dieselbe Treffermenge → identische Liste, AD-17h/A0-19); (2) **D-5** — `schema/canonical-terms.md`: **Lookup-Verfahren** deterministisch fixiert (lowercasing → `[-–_ ]`→`-`-Kollaps → Lookup der **normalisierten** Form; Spalten tragen ausschließlich normalisierte Formen) + **Eindeutigkeits-Invariante** (jede normalisierte Form in genau einem Eintrag — Canon oder Variante, nie beides/zweimal) + **Konflikt-Verfahren** (keine stille Anhängung; `deferred-work.md`/Ask-First, analog zur Umbenennungs-Regel); (3) **D-1** — Statuskette `in-progress → done` als eigener dokumentierter Schritt in `wiki/log.md` (Sprint-Sync-Konvention; Story-3.1-Präzedenz); Key bleibt `done`; (4) **D-2 + P-1** — `run-sandbox.sh` um **T5** `LINK_FOLLOWING_ZYKLUS` (A↔B-Zyklus; besuchte Menge → endlich/doppelungsfrei), **T6** `TRAVERSAL_REACH_ONLY` (Term nur in Area-`index.md` → gewurzelte Concept-Pfade), **T7** `TERM_ABLEITUNG_SYNONYM` (Registry-Test-Doppel; beide Lookup-Pfade + Negativ-Fall) erweitert; T1/T4 mit harten Asssertionen; T2-Kommentar korrigiert; re-executiert: **alle 7 Tests PASS, exit 0**; (5) **D-3** — `wiki/log.md`-Selbsttest-Beleg (b) gegen die echte `run-sandbox.sh`-Ausgabe neu belegt (neue Log-Zeile, append-only; Rev-2.5-Zeile historisch unverändert); (6) **P-2** — Typos korrigiert (`Determinsmus`→`Determinismus`, `beankert`→`angeankert`, `Membrum`→`Mitglied`, `Konventionelle`→`Bekannte`, `Resovierung`→`Auflösung`; `raw/`-Source und der präexistierende 3.1-Log-Typo bleiben unberührt). **4 Defers** (Wortgrenzen-/Frontmatter-Scope; Separator-Kollaps-Reichweite; Stufe-a-`index.md`-Treffer aus finaler Liste; Rev-2.5/2.6-Beleg-Klärigungs-Bündel) in `deferred-work.md` (append-only, Sektion „Deferred from: code review of spec-3-2-… (2026-08-19)"). **Keine AC-Änderung, kein frozen-Schnittstellen-Change, kein Validator-/Vertrags-/`raw/`-Change (AD-3), keine neue §7-Klasse, kein Standalone (D-3).** Frontmatter: `status: 'done'`, `review_loop_iteration: 3`. `sprint-status.yaml`: Key `3-2-…` bleibt `done`, `last_updated` → 08-19-2026.
|
||||||
|
- **2026-08-19 (bmad-code-review Loop 2 — bad_spec-Loopback):** 5 bad_spec-Findings ausgelöst, Code-Änderungen auf Baseline revertiert, nicht-gefrorene Spec-Tail-Sektionen geamendet:
|
||||||
|
- **B1/VG-1 `log.md`-Kontamination:** `rg -l '<term>' wiki/` ohne `--exclude=log.md` → `log.md` wird ab dem Moment selbst „Kandidat", in dem ein Log-Eintrag den Term zitiert; der Determinismus-Selbsttest verankert das A0-18-1-File-Find in einem Commit, das selbst `A0-18` enthält (Stale-Evidenz; Reproduzierbarkeits-Claim widerlegt sich selbst). Bekannt-bös: permanente Drift + falsches Verification-Expect.
|
||||||
|
- **B2 Reihenfolge:** `rg -l`-Ausgabe-Reihenfolge (FS-Traversal) nicht auf Zuwachs-Sicht-Ordnung abbildbar; Stufe-b/c ohne definierte Position. Bekannt-bös: AC-2-Zwei-Run-Identität nur bei undokumentiertem `rg`-Tie-Break.
|
||||||
|
- **B3 Resolver nicht enumeriert:** „eine canonische Form je Semantik" ohne committete Registry → Determinismus nicht pinbar. Bekannt-bös: gleiche Liste nur, wenn Resolver Teil des Git-States (nicht spezifiziert).
|
||||||
|
- **B4 Em/En-Dash:** Klassenliteral `[-–_ ]` deckt nur En-`–`, nicht Em-`—`; Kollaps-Reichweite inkonsistent. Bekannt-bös: Em-Varianten fallen nicht unter den Kollaps (Synonymlücke). **Gewählter Weg:** `-`-Kollaps bleibt; explizite `—`-Auflösung wird als offene Determinismus-Lücke in Step-4-Defer an Story 3.8 übergeben (nicht stillschweigend hinzugefügt).
|
||||||
|
- **B5 §8-A0-19-Claim:** Spec sagte „A0-19 steht bereits in §8", war im Ist-Baum nicht kommutiert; Implementierung ergänzte A0-19 (korrekt). Spec korrigiert, A0-19-Ergänzung als KEEP verankert (fehlleiten bei Re-Baseline verhindern).
|
||||||
|
- **B6 NO_MATCH / §5.9-P2-Block-Scope:** werkt zusammen → zusammengefasst; in B1 und Task-Patch-Membership-Pin überführt.
|
||||||
|
- **B7 §5.9-P2-Block-Zeiger:** nicht mehr nötig — die fixierte Stufe (a) `--exclude=log.md` macht den Zeiger redundant (kein log.md-Kandidat mehr); **verworfen** (keine unnötige Pflicht).
|
||||||
|
- **KEEP-Instruktionen (müssen Neu-Ableitung überleben):** neue §3.2-Sektion nach §3 etc.; alle 6 I/O-Matrix-Szenarien; Determinismus-Vertrag (identische Reihenfolge, KEEP: nur-Parallel = deterministisch-MECHANISMUS, NICHT zufällig); `--exclude=log.md`-Stufe-a; Determinismus-Selbsttest MIT Membership-Pin (Zwei-Run-Identität + Mengen-Genauigkeit) und `canonical-terms.md`-Resolver as Resolver im Git-State; `Wiki/log.md` als append-only (Story-3.1-Bullet bleibt eigenständig stehen); die A0-19/Schema-Referenz ergänzen. NOT-KEEP: Spec-A0-19-Formulierung „steht bereits" (korrigiert).
|
||||||
|
- Restliche patch- und defer-Findings (B6/NO_MATCH, B5/Doppel, Log-Selbsttest-Beleggenaue, F17+Em-Morphologie-Story-3.8) werden in der Step-4-Patch-Runde umgesetzt bzw. in `deferred-work.md` nachbestätigt.
|
||||||
|
|
||||||
|
## Design Notes
|
||||||
|
|
||||||
|
**Warum §3.2 als eigene Sektion statt Streckung in Pkt. 2:** §3 ist heute eine nummerierte Liste (Pkt. 1–3); der Story-3.2-Vorbehalt sitzt IN Pkt. 2. Die feinkörnige Mechanik (Term-Ziehverfahren, Kanonisierungs-Resolver, dreistufige Erhebung, Determinismus) ist zu umfangreich, um Pkt. 2 verständlich zu halten. Design-Entscheidung: **neue Sektion §3.2 „Relevanzbestimmung (Story 3.2)"** direkt nach §3 — Pkt. 2 bleibt der Kern-Anker („Erhebung nach §3.2"), die Komplexität wird ausgelagert, bestehende §5.9-Pkt.-6-Bindungen bleiben gültig. Nur falls der §3-Aufbau eine andere Einfüge-Stelle nahelegt (z. B. Pkt. 2a), wird das Label angepasst — Pkt. 2 bleibt in jedem Fall der verbindliche Einstieg.
|
||||||
|
|
||||||
|
**Term-Ziehverfahren — was deterministisch heißt:** Die Ziehung ist deterministisch, weil sie allein von der committeten Evidenz-Datei abhängt: (1) bedeutungstragende Fachbegriffe = Token-Folgen mit fachlicher Signifikanz, aus der §2-Interpretation benannt (nicht freie LLM-Auswahl); (2) Normalisierung über einen canonischen Schreibweisen-Resolver (lowercasing; `[-–_ ]`→`-`; eine canonische Form je Semantik); (3) mehrere Terme je Einheit erlaubt — Candidate-Liste = Vereinigung der Treffer über alle Terme, bereinigt über besuchte Menge; (4) kein stiller Ausschluss: nicht auflösbare Varianten werden wie notiert verwendet. Die Erhebung *mit festem Term* war schon in Rev-2.4.2 deterministisch — Story 3.2 macht zusätzlich die **Term-*Auswahl*** deterministisch (exakt der bisherige Vorbehalt).
|
||||||
|
|
||||||
|
**Determinismus-Referenz:** AD-17h und A0-19 sind bereits Normreferenzen in §8 Revision 2.4 (Story 3.1); Story 3.2 ergänzt **AD-13**, **A0-18** und **PRD OQ-3** (Architekturfrage „Compilation Scope"). A0-19 war im Ist-§8 (Baseline `e3e7ec3`) zwar nicht gelistet — die Implementierung fügt es als Determinismus-Referenz der Relevanzbestimmung hinzu (kein Verstoß, Design-KEEP: A0-19-Anker wird in §8 **und** §3.2 gesetzt; die frühere Spec-Formulierung „steht bereits" war falsch und ist hiermit korrigiert). `wiki/knowledge-kompilation-inkrementell.md:48` referenziert A0-18/AD-13 bereits; **zur Erhebung wird `wiki/log.md` ausgeschlossen** (`--exclude=log.md`, §5.6-Muster) — sonst wäre der eigene `log.md`-Eintrag bei jedem Term, den er zitiert, selbst „Kandidat" (A0-18/FR-12-Fall; die Candidate-Liste ist auf Concept-Pfade definiert, §5.9 Pkt. 5 behandelt `log.md` gesondert als erlaubtes Mitglied).
|
||||||
|
|
||||||
|
**Determinismus-Selbsttest (Membership + Identität):** Der Selbsttest prüft nicht nur Zwei-Run-Identität, sondern zusätzlich, dass die Ausgabe **Mengen-Genauigkeit** hat (nur Concept-Pfade, `log.md` ausgeschlossen) — er wird gegen einen mini-Sandbox-Baum ausgeführt, der einen realen Term auf Concept-Bodies und `log.md` verteilt und die exakte Candidate-Liste als erwartete Ausgabe pindet. Damit ist die Stale-Verifikations-Falle („das Artefakt widerlegt sich selbst") geschlossen.
|
||||||
|
|
||||||
|
## Verification
|
||||||
|
|
||||||
|
**Commands (re-executierbar, ab Workspace-Root):**
|
||||||
|
1. **Vorbehalts-Auflösung:** `grep -n "Story 3.2 vorbehalten" schema/compiler.md` liefert **keinen** Treffer mehr (beide Vorbehalte aufgehoben: §3 Pkt. 2 + §7).
|
||||||
|
2. **Neue Sektion:** `grep -n "Relevanzbestimmung\|3.2" schema/compiler.md` liefert die neue §3.2-Sektion; §7-Vorbehalt enthält „3.2" nicht mehr; §8 trägt Revision 2.5 + 2.6 (Patch-Runde: §4-Kopf, rg-tool-korrekte Formen).
|
||||||
|
3. **Determinismus-Selbsttest (Membership + Identität):**
|
||||||
|
- `rg -l '<term>' -g '!log.md' wiki/` (rgs native Glob-Exklusionsform; `--exclude` ist kein rg-Flag — das GNU-grep-Äquivalent ist `grep -rl '<term>' --exclude=log.md wiki/`) zweimal ausführen, Ausgaben **identisch** — deterministische Erhebung ohne `log.md`-Kontamination; z. B. `rg -l 'A0-18' -g '!log.md' wiki/` → genau `wiki/knowledge-kompilation-inkrementell.md` (ein Concept-Pfad, `log.md` ausgeschlossen); `rg -l 'A0-18' wiki/` **ohne** Exklusion hingegeben würde `wiki/log.md` mit-treffen (Selbstkontamination — genau der ausgeschlossene Fall).
|
||||||
|
- mini-Sandbox-Baum (`_bmad-output/implementation-artifacts/sandbox-3-2/`, re-executierbar via `bash run-sandbox.sh` — Term auf Concept-Bodies **und** `log.md` verteilt): exakte Candidate-Liste (nur Concept-Pfade) wie erwartet; Normalisierung Strip `wiki/` + `.md` → relative OKF-Pfade; zwei aufeinanderfolgende Läufe liefern byte-identische Ausgaben (Zwei-Run-Identität, AD-17h).
|
||||||
|
4. **Validator-Lauf:** alle `wiki/`-Dateien SUCCESS (unverändert; reine Text-Instruktion, human-mechanisch ausgeführt, D-3) — per-Datei-Verdikt als Ausführungs-Nachweis im `log.md`-Eintrag.
|
||||||
|
5. **Resolver-Materialisierung:** `schema/canonical-terms.md` existiert (committete, append-only Registry: canon. Form + erlaubte Varianten); `grep -n "canonical-terms" schema/compiler.md` liefert die §3.2-Referenz. <br>_(Optionale Em-Dash-Prüfung: die Normalisierungs-Klasse deckt `-` ab; explizite `—`-Varianten-Auflösung ist eine erkannte Determinismus-Lücke → Story 3.8, s. Spec Change Log.)_
|
||||||
|
|
||||||
|
**Manual checks:**
|
||||||
|
- §3 Pkt. 2 zeigt auf die neue §3.2-Mechanik; Term-Ziehverfahren + Kanonisierungs-Resolver textuell benannt; Candidate-Liste als relative OKF-Pfade ohne `.md`; Determinismus-Vertrag in der Instruktion; `compiler.md` §8-Revision 2.5 + 2.6 mit Abschlussklausel; kein `schema/validator.md`-/`schema/wiki-compiler.md`-/`raw/`-Diff; §7-Vorbehalt ohne „3.2"; `wiki/log.md`-Eintrag datiert mit Story-3.2-Semantik, Determinismus-Beleg, Statuswechsel `backlog → in-progress → done` (Patch-Note Rev 2.6 oben), per-Datei-Verdikt; `deferred-work.md`-epic-3-context-Eintrag als aufgegriffen markiert + Em-Dash-Defer (Story 3.8); `sprint-status.yaml` konsistent (`3-2-…` → done).
|
||||||
+148
@@ -0,0 +1,148 @@
|
|||||||
|
---
|
||||||
|
title: 'Bestehende Concepts erweitern/präzisieren/korrigieren — Update-Formen operativ schärfen (Story 3.3)'
|
||||||
|
type: 'feature'
|
||||||
|
created: '2026-08-19'
|
||||||
|
status: 'done'
|
||||||
|
review_loop_iteration: 0
|
||||||
|
baseline_commit: 52f88fdc5f3ea0fe5323412ca3ba8b4a1bdbf549
|
||||||
|
context:
|
||||||
|
- _bmad-output/implementation-artifacts/epic-3-context.md
|
||||||
|
---
|
||||||
|
|
||||||
|
<frozen-after-approval reason="human-owned intent — do not modify unless human renegotiates">
|
||||||
|
|
||||||
|
## Intent
|
||||||
|
|
||||||
|
**Problem:** Story 3.1 verankerte die Update-Mechanik (Erweitern/Präzisieren/Korrigieren) in `schema/compiler.md` §5.9 als Regeltext, Story 3.2 die Candidate-Erhebung (§3.2). Unoperativ bleibt die **Ausführung je Update-Form** — v. a. das Story-3.3-AC aus FR-6: „der Text wird präzisiert oder korrigiert, **ohne die Struktur zu zerstören**". Der Compiler hat keine deterministische Anleitung, wie Präzisieren (Schärfen einer bestehenden Aussage) von Erweitern (Anfügen) abzugrenzen ist und was die „Struktur" (Frontmatter, bestehende belegte Aussagen, Provenienz-Verkettung) beim Übergriff auf einen bestehenden Absatz schützt.
|
||||||
|
|
||||||
|
**Approach:** Story 3.3 schärft §5.9 (Revision 2.8): die drei Update-Formen werden **operationell** ausformuliert — je Form ein deterministisch prüfbares **Abgrenzungskriterium** (Welche Form greift wann?), die **Struktur-Erhaltungsregel** (was bleibt unverändert: Frontmatter-Subset, bestehende belegte Aussagen + §5.5-Inline-Verweise, §5.6-Pin) und der Textgenauigkeits-Rahmen (Schärfen an der Aussage, kein Satz-Umbau, kein Neuschreiben ohne Ersetzungsbeleg). Zusätzlich eine **re-executierbare Sandbox** (`sandbox-3-3/run-sandbox.sh`, Muster Story-3.1): Demonstriert einen echten Update-Run mit committeter Neuevidenz in allen drei Formen + No-Op und prüft die Erhaltungs-Invariante (§5.9 Pkt. 5) als harte Assertion. Keine Inhalts-Mutation des realen Bundles (kein neues `raw/`-Material, AD-3); kein neues Prädikat, kein Vertrag-/Validator-/`raw/`-Change; kein Standalone (D-3).
|
||||||
|
|
||||||
|
## Boundaries & Constraints
|
||||||
|
|
||||||
|
**Always:**
|
||||||
|
- **Instruktions-Story (D-3):** Schärfung ausschließlich in `schema/compiler.md` §5.9 als deterministischer Text. Kein executable, kein Standalone, keine neue §7-Invaliditätsklasse, kein Change an `schema/wiki-compiler.md`/`schema/validator.md`/`raw/` (AD-3).
|
||||||
|
- **Struktur-Erhaltungs-Invariante (Kern, FR-6/AC-2):** Update tastet die Struktur nicht an — (1) Frontmatter bleibt Subset-konform (nur `sources`-Zuwachs um echten neuen Beleg + `generated.at`-Bump zulässig); (2) bestehende belegte Aussagen werden nicht umgeschrieben ohne Präzisieren an ihr selbst bzw. Korrigieren mit Ersetzungsbeleg (§5.5-Inline-Verweise bleiben gültig soweit Beleg Body-Bestand); (3) gepinnte Linkform unverändert, keine neuen Links außer bei echten Beziehungen (§5.9 Pkt. 3).
|
||||||
|
- **Determinismus (AD-17h/A0-19):** Form-Wahl folgt aus der committeten Evidenz; gleicher Git-State + gleiche Eingabemenge → identischer Update-Vorgang. Abgrenzungsregeln textuell prüfbar (neue Aussage → Erweitern; Schärfung einer bestehenden → Präzisieren; ersetzende → Korrigieren).
|
||||||
|
- **Kein Leasing-Scope in 3.3:** AC-4 (Mutation nur im geleasten Bereich, AD-17.3) bleibt Story 3.5/3.6; AD-17f-Basis unverändert. §5.9 Pkt. 5/6-R1/P2-Bausteine unverändert.
|
||||||
|
- `sprint-status.yaml`: Key `3-3-bestehende-concepts-erweitern-präzisieren-korrigieren` → **in-progress** (bei Implementierung).
|
||||||
|
|
||||||
|
**Ask First:** §5.6-Linkform-Änderung (A0-9) · AD-7d-Renames · Inhalts-Mutation des realen Bundles · Validator-/Vertrags-/`raw/`-Change · Commit-Boundary-Änderung · Leasing-Ausweitung (3.5-Scope).
|
||||||
|
|
||||||
|
**Never:** Änderungen an `schema/wiki-compiler.md`/`schema/validator.md`/`raw/` (AD-3) · neue §7-Invaliditätsklasse · Standalone (D-3) · Duplikat-Anlage eines bestehenden Pfads · „Regenerate Everything" (AD-5/A0-6) · stille Löschung von Provenienz ohne Ersetzungsbeleg (AD-16) · stiller Absatz-Neuschreib (Structure-Preservation-Fall).
|
||||||
|
|
||||||
|
## I/O & Edge-Case Matrix
|
||||||
|
|
||||||
|
| Scenario | Input / State | Expected Output / Behavior | Error Handling |
|
||||||
|
|----------|--------------|---------------------------|----------------|
|
||||||
|
| HAPPY_ERWEITERN | Neue committete Evidenz trägt eine neue belegte Aussage zum bestehenden Concept | **Erweitern:** neue Aussage als Absatz ergänzt (mit §5.5-Inline-Beleg), bestehende Aussagen unverändert; `sources`-Zuwachs um echten neuen Beleg; `at`-Bump; `log.md`-Eintrag „Story 3.1-Update" | NO_MATCH → UNTOUCHED_CONCEPT (keine Mutation) |
|
||||||
|
| HAPPY_PRAEZISIEREN | Evidenz schärft eine bestehende Aussage (präzisierende Information, FR-6/AC-2) | **Präzisieren:** Formulierung/Abgrenzung an der bestehenden Aussage geschärft, Position/Struktur erhalten; Beleg nachgeführt; kein Satz-Umbau/Neuschreib | keine bestehende Aussage als Anker → nicht Präzisieren (ggf. Erweitern) |
|
||||||
|
| HAPPY_KORRIGIEREN | Evidenz ersetzt eine fehlerhafte/überholte Aussage | **Korrigieren:** ersetzte Aussage **nicht still gelöscht**, sondern explizit abgelöst + Ersetzungsbeleg (AD-16-Default Erhaltung) | widersprechender Inhalt ohne Ersetzungsevidenz → bleibt erhalten, Disagreement in `log.md` (Epic-4-Interface) |
|
||||||
|
| NO_OP_KANDIDAT | Evidenz bereits vollständig im Body enthalten | **No-Op:** keine Mutation, kein `at`-Bump, kein `sources`-Zusatz, kein `log.md`-Eintrag — byte-identisch | im Zweifel greift Erweitern/Präzisieren (No-Op = engere Auslegung) |
|
||||||
|
| STRUKTUR_ERHALT | Update greift in Body mit belegten Aussagen + Inline-Verweisen | Struktur unverändert: Subset, Verweise, Linkform; kein unbefugter Key | Verstoß → Update fehlerhaft; Rollback + textuell benannter Verstoß (NFR-4) |
|
||||||
|
| MEHRFACH_TREFFER | Mehrere Einheiten desselben Runs treffen denselben Pfad | Konsolidierung: ein Update, ein `log.md`-Eintrag, ein konsolidierter `sources`-Zuwachs, ein `at` | Reihenfolge = Zuwachs-Sicht; lexikografischer Tie-Break |
|
||||||
|
|
||||||
|
</frozen-after-approval>
|
||||||
|
|
||||||
|
## Code Map
|
||||||
|
|
||||||
|
- `schema/compiler.md` — **primär mutiert** (D-3, einziger Instruktions-Ort):
|
||||||
|
- §5.9 Pkt. 2 (`:261-269`): drei Update-Formen **operationell ausformulieren** (a) Abgrenzungskriterium je Form, (b) Struktur-Erhaltungsregel (Definition „Struktur" + was unverändert bleibt), (c) Textgenauigkeits-Rahmen für Präzisieren. Bestehender Regeltext (Form-Bullets, `sources`-Regel, `at`-Konvention, No-Op, Konsolidierung) bleibt normativ **unverändert** — Schärfung als Ausführungs-Ebene ohne neue Logik.
|
||||||
|
- §5.9 Pkt. 5 (`:272-278`): Erhaltungs-Invariante — Struktur-Erhaltungs-Bezug ergänzen (Diff-Probe erfasst Pfad-Mengen; Struktur pro Pfad über Pkt.-2-Regeln geprüft).
|
||||||
|
- §5.9 Pkt. 6 (`:279-281`): P2-Block — Struktur-Erhaltungs-Check als zusätzliches textuelles Element (keine unbefugten Keys, keine stille Löschung, Links unverändert).
|
||||||
|
- §8 Revisionslog (`:375`): **Revision 2.8** (Story 3.3) mit Abschlussklausel (kein Vertrags-/Validator-/`raw/`-Change, keine §7-Klasse, kein Standalone).
|
||||||
|
- `_bmad-output/implementation-artifacts/sandbox-3-3/run-sandbox.sh` — **neu** (re-executierbar, Muster Story-3.1-Sandbox): Mini-Bundle mit einem Concept + committeter Neuevidenz; alle drei Formen + No-Op durchspielen; Erhaltungs-Invariante als harte Assertion (Diff ⊆ {betroffener Pfad, log}; keine neue Datei; kein Ghost-Diff); Zwei-Run-Identität; Frontmatter-Konformität je mutiertem Concept.
|
||||||
|
- `wiki/log.md` — **append** (append-only, Vertrag §5): Story-3.3-Eintrag (Schärfung, Sandbox-Nachweis, Statuswechsel, Validator-Verdikt); bestehende Bullets unverändert.
|
||||||
|
- `_bmad-output/implementation-artifacts/sprint-status.yaml` — **mutiert**: Key `3-3-…` (`:56`) → `in-progress` (→ `done` bei Story-Abschluss).
|
||||||
|
- `schema/validator.md`, `schema/wiki-compiler.md`, `raw/…` — **read-only** (AD-3). Keine Concept-Inhalts-Mutation (Instruktions-Story; kein neues committetes `raw/`-Material vorhanden — Demonstration per Sandbox).
|
||||||
|
|
||||||
|
## Tasks & Acceptance
|
||||||
|
|
||||||
|
**Execution:**
|
||||||
|
- [x] `schema/compiler.md` — §5.9-Pkt.-2-Update-Formen operationell schärfen (je Form Abgrenzungskriterium + Struktur-Erhaltungsregel + Textgenauigkeits-Rahmen; bestehender Regeltext unverändert) · §5.9-Pkt.-5/-6: Struktur-Bezug + P2-Check-Element · §8 Revision 2.8; ohne Change an `schema/wiki-compiler.md`/`schema/validator.md`/`raw/`.
|
||||||
|
- [x] `sandbox-3-3/run-sandbox.sh` — Update-Run-Demonstrator (Erweitern + Präzisieren + Korrigieren + No-Op), Erhaltungs-Invariante als harte Assertion, Zwei-Run-Identität. **Erweitert um U7 MEHRFACH_TREFFER** (I/O-Matrix-Row, Konsolidierung mehrerer Einheiten auf denselben Pfad) — alle 7 Tests (U1–U7) PASS, Exit 0.
|
||||||
|
- [x] `wiki/log.md` — Story-3.3-Eintrag (Vertrag §5, append-only): Schärfung, Sandbox-Nachweis, Statuswechsel, per-Datei-Validator-Verdikt.
|
||||||
|
- [x] `sprint-status.yaml` — Key `3-3-…` → in-progress.
|
||||||
|
|
||||||
|
**Acceptance Criteria:**
|
||||||
|
- Given eine neue Erkenntnis zu einem bestehenden Concept, when der Run sie verarbeitet, then erweitert er das bestehende Concept anstelle der Anlage einer neuen Datei (AC-1; FR-6) — Erweitern-Regel in §5.9 Pkt. 2, Sandbox belegt sie (keine neue Datei im Diff).
|
||||||
|
- Given eine präzisierende Information, when sie eingearbeitet wird, then wird der Text präzisiert oder korrigiert, ohne die Struktur zu zerstören (AC-2; FR-6) — Struktur-Erhaltungsregel in §5.9 Pkt. 2/5 definiert.
|
||||||
|
- Given eine Aktualisierung, when sie erfolgt, then bleiben Beziehungen und Provenienz soweit weiterhin gültig erhalten (AC-3; FR-6) — Inline-Verweise + Linkform unverändert gültig soweit Beleg Body-Bestand; `sources`-Zuwachs nur um echte neue Belege.
|
||||||
|
- Given die Instruktion, when geprüft, then bleibt `schema/validator.md`/`schema/wiki-compiler.md`/`raw/` unverändert (AD-3), keine neue §7-Klasse, kein Standalone (D-3), kein Leasing-Scope (AC-4 → 3.5/3.6, AD-17.3-Hinweis in §7) — Validator auf Ist-Bundle SUCCESS (7/7 unverändert).
|
||||||
|
|
||||||
|
## Spec Change Log
|
||||||
|
|
||||||
|
*(Append-only — hier von step-04 während der Review-Loops befüllt.)*
|
||||||
|
|
||||||
|
### Review Loop 1 (Step-04, 2026-08-19) — 3 Subagenten (blind-hunter 9, edge-case-hunter 2+Minors, verification-gap 18)
|
||||||
|
|
||||||
|
**Klassifikation (Dedupe → Severity → Route):** High — Verifikations-Lücken des Sandbox-Nachweises (byte-Identität nur Teilmengen-assertiert; Struktur-Ebene/`??`-Sicht nie exerziert; U7 `-le 1`), Form-Abgrenzungs-Überlapp (keine Präzedenz → AD-17h-Gefahr), §5.5-Ankerform (`#S-N` ohne reale Kennung im Rohdokument). Medium — U3-Wortlaut-Mutation der abgelösten Aussage, `last_updated`-Präzisions-Regression, Frontmatter-Prüfung vollständig (Reihenfolge/Duplikat), No-Op-Form-Asymmetrie, „kein neuer normativer Inhalt" vs. Pkt.-5/6-Änderung, at↔AD-17h-Gap-Kreuzreferenz. Low — Diff-Artefakt-Pfade, Spec-Change-Log leer (per Konvention erst jetzt befüllt).
|
||||||
|
|
||||||
|
**Ergebnis: kein intent_gap, kein bad_spec** (kein Loopback) — **patch** (auto-fixiert, s. Diff): §5.9 Pkt.-2-Operationelle-Ebene — Präzedenz-Reihenfolge `Korrigieren → Präzisieren → Erweitern → No-Op` + Überlapp-Bindung + No-Op als Nicht-Form + at↔AD-17h-Kreuzreferenz; Korrigieren-Struktur-Erhaltung — Original-Wortlaut bleibt als abgelöster Bestand erhalten; Sandbox — U1/U2/U3 byte-Identität auf alle drei Aussagen erweitert, U8 (unbefugter Frontmatter-Key → Struktur-HARD-FAIL) + U9 (ungetrackte neue Datei → `??`-Sicht-HARD-FAIL) neu, U7 `-le 1` → `-eq 1` + beide raw/-Quellen im konsolidierten log-Eintrag, assert_frontmatter um canoniche Reihenfolge + Duplikat-Prohibition erweitert, reale `S-N`-Anker in allen raw/-Evidenzdateien (§5.5), U3-Wortlaut nicht mehr verändert. **defer** (append-only `deferred-work.md`): `last_updated`-Präzision (sync-sprint-status-General), „Schärferung/Formata"-Typos (frozen Story-3.1-Text), „auch nach Commit"-Überzeichnung + at↔AD-17h-Gap-Kreuzreferenz (Home Story 3.8), U2-Selbsterfüllung + Zuwachs-Sicht-vs-lexikografisch-Rationale (Form-Wahl-Prüfung als Verfahren), Em-Dash/Umlaut-Normalisierung im Sandbox-Evidenztext. **reject:** U6-SHA-Reproduzierbarkeit von log.md (random baseline-SHA ist konstruktionsbedingt), Diff-Artefakt-Pfad-Präfix (nur Verbrauchskontext), Spec-Change-Log „leer" (per Konvention erst während Review-Loops befüllt).
|
||||||
|
|
||||||
|
## Design Notes
|
||||||
|
|
||||||
|
**Warum Ergänzung, nicht Umbau:** Die Story-3.3-Schärfung ist ein Ausführungs-Sub-Block an Pkt. 2 — sie definiert die offene Frage „Was tue ich konkret bei jedem Form-Fall, und was lasse ich unangetastet?" als deterministische Brücke Regel → Run (AD-17h): dieselbe Evidenz + formale Struktur → identisches Update-Ergebnis. Der frozen Story-3.1-Regeltext bleibt unverändert; die operationellen Regeln werden als Präzisierungsebene darunter angefügt (keine Re-Negotiation).
|
||||||
|
|
||||||
|
**Struktur-Definition (das Geschützte):** (1) Frontmatter (Subset + canonische Reihenfolge; zulässig: `sources`-Zuwachs, `at`-Bump; kein neuer Key, keine Entfernung ohne Beleg); (2) bestehende belegte Aussagen mit §5.5-Inline-Verweisen (nicht umgeschrieben ohne dass Präzisieren/Korrigieren greift); (3) Linkzeichen §5.6-Pin (kein Linkumbau bei reinem Body-Update). Das ist die Bedeutung von „ohne die Struktur zu zerstören" (FR-6/AC-2).
|
||||||
|
|
||||||
|
**Abgrenzungskriterium (aus der Evidenz):** (a) belegte Aussage existiert im Body nicht → Erweitern; (b) schärft bestehende Formulierung/Abgrenzung ohne Ersatz → Präzisieren; (c) ersetzt eine bestehende als fehlerhaft/überholt → Korrigieren; (d) nichts davon → No-Op. Unschärfe → zugunsten Erweitern/Präzisieren (No-Op = engere Auslegung, bestehende §5.9-Regel).
|
||||||
|
|
||||||
|
## Verification
|
||||||
|
|
||||||
|
**Commands (re-executierbar, ab Workspace-Root):**
|
||||||
|
1. `bash _bmad-output/implementation-artifacts/sandbox-3-3/run-sandbox.sh` — expected: alle Szenarien mit harten Pass/Fail-Assertionen, Erhaltungs-Invariante erzwungen, Exit 0.
|
||||||
|
2. `grep -n "Struktur-Erhaltungsregel\|operationelle\|Revision 2.8" schema/compiler.md` — liefert die operationellen Regeln + Revisionslog.
|
||||||
|
3. Read-only (AD-3): `git status --porcelain` zeigt keinen Change an `schema/validator.md`/`schema/wiki-compiler.md`/`raw/`.
|
||||||
|
4. Validator-Lauf: alle `wiki/`-Dateien SUCCESS (unverändert, keine Inhalts-Mutation).
|
||||||
|
|
||||||
|
**Manual checks:**
|
||||||
|
- §5.9 Pkt. 2 trägt Abgrenzungskriterium + Struktur-Erhaltungsregel + Textgenauigkeits-Rahmen; bestehender Regeltext unverändert; §8-Rev-2.8 mit Abschlussklausel; kein `validator.md`/`wiki-compiler.md`/`raw/`-Diff; §7 ohne neuen Platzhalter (Update-Thema entlassen, AC-4-Leasing an 3.5/3.6); `wiki/log.md`-Eintrag datiert mit Story-3.3-Semantik + Sandbox-Nachweis + Statuswechsel + Verdikt; `sprint-status.yaml` konsistent.
|
||||||
|
|
||||||
|
## Suggested Review Order
|
||||||
|
|
||||||
|
**Abgrenzungs-Mechanik der Update-Formen (Kern)**
|
||||||
|
|
||||||
|
- Einstieg: die neue operationelle Ausführungs-Ebene — Präzedenz-Reihenfolge Korrigieren → Präzisieren → Erweitern → No-Op, deterministische Form-Wahl (AD-17h/A0-19), No-Op als Nicht-Form.
|
||||||
|
[`compiler.md:270`](../../schema/compiler.md#L270)
|
||||||
|
|
||||||
|
- Korrigieren schützt den abgelösten Original-Wortlaut (AD-16-Default, keine stille Löschung).
|
||||||
|
[`compiler.md:271`](../../schema/compiler.md#L271)
|
||||||
|
|
||||||
|
- Präzisieren: Schärfen an der Aussage selbst, kein Satz-Umbau; No-Op-Erhaltungsregel volle Byte-Identität.
|
||||||
|
[`compiler.md:272`](../../schema/compiler.md#L272)
|
||||||
|
|
||||||
|
**Struktur-Erhaltungs-Invariante + P2-Check**
|
||||||
|
|
||||||
|
- Die Pfad-Probe verifiziert jetzt zwei Ebenen — Menge + Struktur je berührtem Pfad (FR-6/AC-2).
|
||||||
|
[`compiler.md:283`](../../schema/compiler.md#L283)
|
||||||
|
|
||||||
|
- P2-Check-Block-Element (6): keine unbefugten Keys, keine stille Löschung, Linkform-Pin.
|
||||||
|
[`compiler.md:287`](../../schema/compiler.md#L287)
|
||||||
|
|
||||||
|
- Revisionslog Revision 2.8 mit Abschlussklausel (kein Vertrags-/Validator-/`raw/`-Change).
|
||||||
|
[`compiler.md:382`](../../schema/compiler.md#L382)
|
||||||
|
|
||||||
|
**Re-executierbarer Sandbox-Nachweis**
|
||||||
|
|
||||||
|
- U8: unbefugter Frontmatter-Key löst die Struktur-Ebene-HARD-FAIL aus — Negativ-Kontrolle der Kern-Invariante.
|
||||||
|
[`run-sandbox.sh:365`](./sandbox-3-3/run-sandbox.sh#L365)
|
||||||
|
|
||||||
|
- U9: ungetrackte neue Datei wird über die `??`-Sicht erkannt (Duplikat-Kontrolle).
|
||||||
|
[`run-sandbox.sh:378`](./sandbox-3-3/run-sandbox.sh#L378)
|
||||||
|
|
||||||
|
- U7: Konsolidierung mehrerer Einheiten auf einen Pfad — ein log-Eintrag, beide raw/-Quellen verlinkt.
|
||||||
|
[`run-sandbox.sh:320`](./sandbox-3-3/run-sandbox.sh#L320)
|
||||||
|
|
||||||
|
- assert_frontmatter: canoniche Reihenfolge + Duplikat-Prohibition (Vertrag §3.3/§3.4-Subset).
|
||||||
|
[`run-sandbox.sh:118`](./sandbox-3-3/run-sandbox.sh#L118)
|
||||||
|
|
||||||
|
**Provenienz & Status**
|
||||||
|
|
||||||
|
- Review-Loop-1-Bullet: Klassifikation, Patches, Defers, Rejects; Spec-Status `in-review`.
|
||||||
|
[`log.md:4`](../../wiki/log.md#L4)
|
||||||
|
|
||||||
|
- Defer-Einträge (5) inkl. Home Story 3.8 für at↔AD-17h-Gap und Normalisierungs-Lücken.
|
||||||
|
[`deferred-work.md:9`](./deferred-work.md#L9)
|
||||||
|
|
||||||
|
- Sprint-Status Key `3-3-…`: Review-Abschluss-Flip auf `done`.
|
||||||
|
[`sprint-status.yaml:56`](./sprint-status.yaml#L56)
|
||||||
+142
@@ -0,0 +1,142 @@
|
|||||||
|
---
|
||||||
|
title: 'Wissen aus mehreren Sources synthetisieren — gemischte claim-granulare Provenienz operationalisieren (Story 3.4)'
|
||||||
|
type: 'feature'
|
||||||
|
created: '2026-08-19'
|
||||||
|
status: 'done'
|
||||||
|
review_loop_iteration: 0
|
||||||
|
baseline_commit: 9b256fa5adc22fceb1e28a07efbf4504e0004878
|
||||||
|
context:
|
||||||
|
- _bmad-output/implementation-artifacts/epic-3-context.md
|
||||||
|
---
|
||||||
|
|
||||||
|
<frozen-after-approval reason="human-owned intent — do not modify unless human renegotiates">
|
||||||
|
|
||||||
|
## Intent
|
||||||
|
|
||||||
|
**Problem:** §5.9 verankert die Update-Formen einzelner Concepts (Story 3.1/3.3), §4 die `sources`-Liste. Unoperativ bleibt die **Synthese-Dimension (FR-7, AD-4, A0-3)**: wie der Producer mehrere Sources zum selben Thema zu **einer** gemeinsamen Wissensrepräsentation mit **gemischter, claim-granularer Provenienz** zusammenführt — statt getrennter Zusammenfassungen (FR-7). Es fehlt eine deterministische Anleitung für (a) die Erkennung einer Synthese-Einheit (≥ 2 belegende `raw/`-Quellen), (b) die Konsolidierung redundanter Aussagen **ohne** Provenienz-Verlust (Multi-Beleg, §5.5), und (c) den reflektierten Wissensstand (keine Aneinanderreihung von Source-Zusammenfassungen, FR-7 AC-4). Der §7-Synthese-Vorbehalt (`:343`) zeigt auf Story 3.4.
|
||||||
|
|
||||||
|
**Approach:** Story 3.4 verankert die Synthese-Mechanik als neue Sektion **§5.10 „Synthese aus mehreren Sources (Story 3.4)"** (nach §5.9, vor §6, Revision 2.9): deterministische Regeln für Synthese-Einheit, gemeinsame Zielrepräsentation (ein Concept-Pfad, `sources`-Liste ≥ 2), claim-granulare gemischte Provenienz mit Multi-Beleg-Konsolidierung (§5.5) und Reflektiertheits-Selbsttest (keine per-Source-Zusammenfassungs-Struktur). Zusätzlich eine **re-executierbare Sandbox** (`sandbox-3-4/run-sandbox.sh`, Muster Story-3.3): demonstriert einen echten Synthese-Run aus 2+ `raw/`-Quellen (Neu-Anlage + Update-Pfad) und assertet die Invarianten hart (sources ≥ 2, Multi-Beleg je konsolidierter Aussage, keine Aneinanderreihung, Erhaltungs-Invariante §5.9-Pkt.-5, Zwei-Run-Identität AD-17h). Nickel die Story-3.3-Defer U2/U7-Empfehlung (Form-Wahl-Klassifikationsprobe) im Sandbox auf. Keine Inhalts-Mutation des realen Bundles (AD-3); kein neues `raw/`-Material; kein Standalone (D-3).
|
||||||
|
|
||||||
|
## Boundaries & Constraints
|
||||||
|
|
||||||
|
**Always:**
|
||||||
|
- **Instruktions-Story (D-3):** Verankerung ausschließlich in `schema/compiler.md` §5.10 als deterministischer Text. Kein executable, kein Standalone, keine neue §7-Invaliditätsklasse, kein Change an `schema/wiki-compiler.md`/`schema/validator.md`/`raw/` (AD-3).
|
||||||
|
- **Synthese ist Querschnitt-Dimension, keine fünfte Update-Form:** Die §5.9-Abgrenzungs-Reihenfolge `Korrigieren → Präzisieren → Erweitern → No-Op` (Story 3.3) bleibt die **sole** Form-Wahl; Synthese erweitert die Ausführung um gemischte Provenienz + Konsolidierung (bei Update auf ein bestehendes Concept) bzw. die Neu-Anlage mit Multi-Source-`sources` (bei neuer Einheit).
|
||||||
|
- **Gemischte claim-granulare Provenienz (AD-4a/4b, A0-3):** jede belegte Aussage des Synthese-Concepts bleibt auf `raw/` zurückführbar; Konsequenz von AD-4c — kein bestehendes Concept ist alleinige Provenienz eines anderen; Übernahmen aus bestehenden Concepts tragen den §5.5-Kontext-Marker („übernommen aus `<Concept>` auf Basis von `<source>`, nicht eigenständig belegt").
|
||||||
|
- **Konsolidierung ohne Provenienz-Verlust (FR-7 AC-3):** redundante Informationen werden zu einer Aussage konsolidiert, die **alle** betroffenen Inline-Belege trägt (Multi-Beleg, §5.5-Serialisierung) — keine stille Beleg-Tilgung (AD-4).
|
||||||
|
- **Reflektierter Wissensstand (FR-7 AC-4):** keine per-Source-Zusammenfassungs-Blöcke („Quelle A: … / Quelle B: …"-Struktur); der Body trägt integrierte, je Aussage provenance-tags versehene Aussagen — textuell per Selbsttest prüfbar.
|
||||||
|
- **Determinismus (AD-17h/A0-19):** Ziel-Pfad (via §3.2/§5.7), `sources`-Liste (lexikografisch nach `resource`, LC_ALL=C) und Konsolidierung folgen deterministisch aus der committeten Evidenz; gleicher Git-State + gleiche Eingabemenge → identischer Synthese-Vorgang. `generated.at`-Wanduhr-Gap bleibt offene A0-20-Konvention (Home Story 3.8).
|
||||||
|
- **Struktur-Erhaltung (FR-6/AC-2, Story 3.3):** die §5.9-Pkt.-2-Struktur-Erhaltungsregeln gelten je berührtem Pfad unverändert (Frontmatter-Subset, keine stille Löschung, §5.6-Pin unverändert, Inline-Verweise gültig soweit Beleg Body-Bestand).
|
||||||
|
- **Erhaltungs-Invariante (AD-5/FT-6):** der §5.9-Pkt.-5-Diff-Selbsttest gilt für Synthese-Runs unverändert (Pfad-Menge ⊆ Kandidatenliste ∪ Neu-Anlage ∪ `log.md` ∪ Index; keine neue Datei außer echten Ziel-Pfaden).
|
||||||
|
- `sprint-status.yaml`: Key `3-4-wissen-aus-mehreren-sources-synthetisieren` → **in-progress** (bei Implementierung).
|
||||||
|
|
||||||
|
**Ask First:** Inhalts-Mutation des realen Bundles (Demo per Sandbox) · AD-7d-Renames · §5.6-Linkform-Änderung · Validator-/Vertrags-/`raw/`-Change · Leasing-Ausweitung (3.5/3.6-Scope) · Synthese als fünfte Update-Form (Abgrenzung ändern) · per-Source-Concepts als zulässige Anlageform.
|
||||||
|
|
||||||
|
**Never:** Änderungen an `schema/wiki-compiler.md`/`schema/validator.md`/`raw/` (AD-3) · neue §7-Invaliditätsklasse · Standalone (D-3) · getrennte Zusammenfassungs-Concepts je Quelle (FR-7) · Duplikat-Anlage eines bestehenden Pfads · „Regenerate Everything" (AD-5) · stille Provenienz-Tilgung oder stille Konsolidierung widersprechender Aussagen ohne Ersetzungsbeleg (AD-16) · Embeddings/Vector im Compiler-Kern (AD-13).
|
||||||
|
|
||||||
|
## I/O & Edge-Case Matrix
|
||||||
|
|
||||||
|
| Scenario | Input / State | Expected Output / Behavior | Error Handling |
|
||||||
|
|----------|--------------|---------------------------|----------------|
|
||||||
|
| HAPPY_SYNTHESE_NEUANLAGE | Zwei committete `raw/`-Quellen zum selben Thema (neue Einheit, kein Ziel-Pfad belegt) | **Ein** neues Concept (gemeinsame Repräsentation): `sources`-Liste ≥ 2 (je Quelle ein Eintrag, lexikografisch nach `resource`), claim-granulare gemischte Inline-Provenienz je Aussage, §5.5-Form; kein per-Source-Summary | NO_MATCH → §5.9/§3.2-Pfad (keine Synthese-Dimension) |
|
||||||
|
| HAPPY_SYNTHESE_KONSOLIDIERUNG | Redundante Aussage in beiden Quellen | **Eine** konsolidierte Aussage mit Multi-Beleg auf alle betroffenen Quellen (§5.5-Semikolon-Form) — keine Provenienz-Dropped | Quellen-EC-1 fehlt → Run-FAIL (Validator), keine Mutation |
|
||||||
|
| HAPPY_SYNTHESE_UPDATE | Synthese-Einheit trifft bestehenden Concept-Pfad | §5.9-Formwahl normal (Erweitern/Präzisieren/Korrigieren), `sources`-Zuwachs um die zweite Quelle, gemischte Belege; Struktur-Erhaltungsregeln gelten | bestehende belegte Aussage als Anker fehlt → Prüfung ob Erweitern |
|
||||||
|
| NO_OP_SYNTHESE | Evidenz bereits vollständig im Body | No-Op (Nicht-Form): byte-identität, kein Eintrag, kein `at`-Bump | im Zweifel greift eine Form (engere Auslegung No-Op) |
|
||||||
|
| ANEINANDERREIHUNG_NEGATIV | Struktur „Quelle A: … / Quelle B: …" | **Instruktions-Selbsttest-FAIL** (Reflektiertheits-Kriterium, NFR-7): textuell benannter Befund, vor Run-Abschluss behoben | kein stiller Vorbeilass (NFR-4) |
|
||||||
|
| STRUKTUR_ERHALT | Synthese-Update greift in Body mit belegten Aussagen | Struktur unverändert (Subset, Verweise, Linkform); kein unbefugter Key | Verstoß → textuell benannt + Rollback (§5.9 Pkt. 5) |
|
||||||
|
| SYNTHESE_OVERLAP_FORMCROSS | Eine Einheit trägt zugleich neue + schärfende Aussage | §5.9-Abgrenzungs-Reihenfolge wählt die erste zutreffende Form; Textgenauigkeits-Rahmen der übrigen gelten je Teilbestand | — (AD-17h: deterministisch) |
|
||||||
|
|
||||||
|
</frozen-after-approval>
|
||||||
|
|
||||||
|
## Code Map
|
||||||
|
|
||||||
|
- `schema/compiler.md` — **primär mutiert** (D-3):
|
||||||
|
- Neue Sektion **§5.10** (nach §5.9, vor §6): Synthese-Stimulus (≥ 2 belegende Quellen per §2-Interpretation), ein-Ziel-Repräsentation (§5.7-Routing), `sources`-Liste (≥ 2, lexikografisch nach `resource`, LC_ALL=C — deterministisch, AD-17h), gemischte claim-granulare Provenienz (je Aussage Inline-`raw/`-Verweis §5.5; konsolidierte Aussagen mit Multi-Beleg), Reflektiertheits-Selbsttest (keine per-Source-Zusammenfassungs-Struktur; Muster-Termane wie „nicht eigenständig belegt"), Übernahme aus bestehenden Concepts mit §5.5-Kontext-Marker (AD-4c: nie alleinige Provenienz), §5.6-Pin unverändert, `log.md`-Eintragspflicht („Story 3.1-Update" bei Update; Anlage-Eintrag bei neuem Synthese-Concept), Erhaltungs-Invariante (Diff-Probe §5.9 Pkt. 5 gilt), Determinismus-Vertrag.
|
||||||
|
- §7 (`:343`): Synthese-Vorbehalt **auflösen** („→ §5.10 verankert (Story 3.4)").
|
||||||
|
- §8 Revisionslog (`:382`): **Revision 2.9** mit Abschlussklausel.
|
||||||
|
- `_bmad-output/implementation-artifacts/sandbox-3-4/run-sandbox.sh` — **neu** (re-executierbar, Muster Story-3.3-Sandbox): Mini-Bundle mit 2 `raw/`-Quellen zum selben Thema; Szenarien S1–S6 (Neu-Anlage mit sources ≥ 2 + gemischten Belegen · Konsolidierung mit Multi-Beleg · Negativ-Kontrolle Aneinanderreihung · Synthese-Update auf bestehendem Pfad · Struktur-/Frontmatter-Invariante · Zwei-Run-Identität AD-17h) + **N1** (NO_OP-Synthese: Evidenz bereits im Body → volle Byte-Identität, kein at-Bump, kein sources-Zusatz, kein log-Eintrag) + **Form-Wahl-Klassifikationsprobe** (Story-3.3-Defer U2/U7: überprüft die §5.9-Abgrenzungs-Reihenfolge an einer gemischten Einheit). Harte Pass/Fail-Assertionen (exit 1), Erhaltungs-Invariante, `??`-Sicht, `assert_frontmatter` (Muster Story-3.3).
|
||||||
|
- `wiki/log.md` — **append** (append-only, Vertrag §5): Story-3.4-Eintrag (Verankerung, Sandbox-Nachweis, Statuswechsel, Validator-Verdikt); bestehende Bullets unverändert.
|
||||||
|
- `_bmad-output/implementation-artifacts/sprint-status.yaml` — **mutiert**: Key `3-4-…` (`:57`) → `in-progress` (→ `done` bei Story-Abschluss).
|
||||||
|
- `schema/validator.md`, `schema/wiki-compiler.md`, `raw/…` — **read-only** (AD-3). Keine Concept-Inhalts-Mutation (Demonstration per Sandbox).
|
||||||
|
|
||||||
|
## Tasks & Acceptance
|
||||||
|
|
||||||
|
**Execution:**
|
||||||
|
- [x] `schema/compiler.md` — §5.10 Synthese-Sektion einfügen (Stimulus, ein-Ziel-Repräsentation, `sources`-Liste, gemischte claim-granulare Provenienz + Multi-Beleg-Konsolidierung, Reflektiertheits-Selbsttest, AD-4c-Marker, §5.6-Pin, log.md, Erhaltungs-Invariante, Determinismus) · §7-Vorbehalt auflösen · §8 Revision 2.9; ohne Change an `schema/wiki-compiler.md`/`schema/validator.md`/`raw/`.
|
||||||
|
- [x] `sandbox-3-4/run-sandbox.sh` — Synthese-Run-Demonstrator (Neu-Anlage + Update, Konsolidierung, Negativ-Kontrolle Aneinanderreihung, NO_OP-Synthese, Form-Wahl-Probe, Struktur-Invariante, Zwei-Run-Identität); harte Pass/Fail-Assertionen; Exit 0.
|
||||||
|
- [x] `wiki/log.md` — Story-3.4-Eintrag (append-only): Verankerung, Sandbox-Nachweis, Statuswechsel, per-Datei-Validator-Verdikt.
|
||||||
|
- [x] `sprint-status.yaml` — Key `3-4-…` → in-progress.
|
||||||
|
|
||||||
|
**Acceptance Criteria:**
|
||||||
|
- Given mehrere Sources zum selben Thema, when der Run synthetisiert, then entsteht eine gemeinsame Wissensrepräsentation statt mehrerer getrennter Zusammenfassungen (AC-1; FR-7) — §5.10-Stimulus + ein-Ziel-Regel, Sandbox belegt (eine Datei, keine per-Source-Summary).
|
||||||
|
- Given eine Synthese aus mehreren Sources, when das Ergebnis erzeugt wird, then übernimmt es gemischte, claim-granulare Provenienz der beteiligten Sources (AC-2; AD-4, A0-3) — Inline-Verweise §5.5 je Aussage, Konsolidierung mit Multi-Beleg.
|
||||||
|
- Given redundante Informationen aus mehreren Sources, when sie synthetisiert werden, then werden sie konsolidiert, ohne Provenienz zu verlieren (AC-3; FR-7) — §5.10-Konsolidierungsregel, Sandbox-S2.
|
||||||
|
- Given das resultierende Concept, when es geprüft wird, then reflektiert es den erkannten Wissensstand — keine bloße Aneinanderreihung (AC-4; FR-7) — Reflektiertheits-Selbsttest, Negativ-Kontrolle S3.
|
||||||
|
- Given die Instruktion, when geprüft, then bleiben `schema/validator.md`/`schema/wiki-compiler.md`/`raw/` unverändert (AD-3), keine neue §7-Klasse, kein Standalone (D-3), keine fünfte Update-Form (Abgrenzungs-Reihenfolge §5.9 unverändert), kein Leasing-Scope — Validator auf Ist-Bundle SUCCESS (7/7 unverändert).
|
||||||
|
|
||||||
|
## Spec Change Log
|
||||||
|
|
||||||
|
**Review-Loop-1 (2026-08-19, bmad-code-review, 3 Subagenten — blind-hunter / edge-case-hunter / verification-gap; kein Loopback, `review_loop_iteration` bleibt 0):** Klassifikation — **kein intent_gap, kein bad_spec** (frozen Intent + Approach eingehalten); **patch** (auto-fixiert, siehe unten) + **defer** (4 Einträge → `deferred-work.md` append-only: AD-16/AD-4c-reale-Anwendung-Home-Epic-4, Orphan-Kontrolle-Home-3.8, Umlaut/Em-Dash-Normalisierung-Sandbox-Home-3.8, Frozen-„Nickel"-Typo-Re-Negotiation) + **reject** (noise: diff-Artifakt-Basename, SHA-Reproduzierbarkeit via `$BASE`-ID). **Patches (alle verifiziert):** (1) `schema/compiler.md` §5.10 — Reflektiertheits-Selbsttest-Muster auf Zeilenanfangs-Label erweitert (`^(Quelle|Source) [A-Z][A-Za-z0-9_ -]*:` — mehrbuchstabige/nummerierte Quell-Labels); **Body-Reihenfolge deterministisch** (lexikografisch über Beleg-Anker, LC_ALL=C) + **Konsolidierungs-Kriterium** (Befund-Äquivalenz über dieselbe erkannte Wissenseinheit) explizit; Duplikat-Fall + Orphan-Kontrolle in Pkt. 8; Stil-/Genus-Korrekturen (`sole`→`einzige`, `der Update`→`das Update`, `sources`-Pluspunkt→`sources`-Zuwachs); Sandbox-N2/N3-Nachweise in Pkt. 3/4. (2) **Sandbox `run-sandbox.sh` (jetzt 10 Szenarien S1–S6 + N1–N3 + FW, Exit 0):** `git add -A`-wiki-Staging aus S1/S2/S3/S4/S5/FW entfernt → die Pkt.-8-`??`-Sicht wird **lebendig** geprüft; **S5-Pkt.-8-`??`-Negativkontrolle** neu (ungetrackte Nicht-Ziel-Datei `ghost.md` → Duplikat/Ghost-Diff-HARD-FAIL, nicht vacuous — Story-3.3-U9-Muster); **N1**-Stimulus-Kommentar korrigiert (alpha-v1 = Baseline-Evidenzbasis, nicht Zuwachs); **N2 Disagreement** (AD-16-Default, beide Behauptungen + je Beleg, kein Falsch-Multi-Beleg, `Disagreement:`-log-Eintrag) + **N3 AD-4c-Übernahme-Marker** (Kontext-Marker-Muster, eigenständig belegte Aussagen ohne Marker, übernommene Quelle nicht in `sources`) als neue Szenarien (schließen die Verification-Gap-Kernbefunde „AD-16-Pfad untested"/„AD-4c-Marker untested"); S1/S2-log.md-Assertionen um die **vollständige Multi-Source-Liste** erweitert. (3) `wiki/log.md`: Audit/Sandbox-Zählung auf 10 korrigiert, Scenario-Typo, „zum Audit-Zeitpunkt"-Qualifikation. (4) `sprint-status.yaml last_updated`-Präzision auf `08-19-2026 16:40` fortgeschrieben (HEAD-Format `HH:MM`, siehe Story-3.3-Präzedenzleistung 13:21). (5) `deferred-work.md` — 4 Spec-3.4-Einträge append-only. **Nach-Review-Abschluss (dieser Flip):** Spec `status: 'in-review' → 'done'`; `sprint-status.yaml` Key `3-4-…` `in-progress → done`.
|
||||||
|
|
||||||
|
## Design Notes
|
||||||
|
|
||||||
|
**Warum §5.10, nicht §5.9-erweiterung:** Synthese ist die **Erzeugungs-/Zusammenführungs-Dimension** (mehrere Quellen → eine Repräsentation) — keine der in §5.9 definierten Einzel-Update-Formen. §5.9 bleibt der Update-Pfad für einzelne bestehende Concepts; §5.10 erweitert die Ausführung um gemischte Provenienz + Konsolidierung (Querschnitt) und die Neu-Anlage mit Multi-Source-`sources`. Das spiegelt den §7-Vorbehalt (`:343`) als eigenständiges Thema.
|
||||||
|
|
||||||
|
**Multi-Beleg-Konsolidierung (das Kernstück):** Eine Aussage, die aus mehreren Quellen redundanz-belegt ist, wird zu EINER Aussage konsolidiert, die §5.5-Multi-Beleg trägt (`(raw/a.md#X; raw/b.md#Y)` — Semikolon-Form, voller Pfad je Beleg). Keine Beleg-Tilgung (AD-4). Widersprüche (diskrepanter Inhalt) bleiben gemäß AD-16 erhalten — kein stilles Zusammenführen zu scheinbar eindeutigen Aussagen (NFR-7, FR-8; Epic-4-Interface: Disagreement in `log.md`).
|
||||||
|
|
||||||
|
**Reflektiertheits-Selbsttest (FR-7 AC-4):** textuell prüfbar — der Body enthält keine per-Source-Zusammenfassungs-Sektionen (keine Struktur „Quelle A: … / Quelle B: …"); jede Aussage trägt ihren Provenienz-Tag. Der Selbsttest grep-basiert: keine Zeile, die nur einen Quell-Label abschnittsstrukturiert.
|
||||||
|
|
||||||
|
**`sources`-Reihenfolge:** deterministisch lexikografisch nach `resource` (LC_ALL=C) — unabhängig von Verarbeitungs- oder Datei-Reihenfolge (AD-17h; konsistent zur §3.2-Pkt.-3b-Lexikografie-Ordnung und zur §5.9-Tie-Break-Logik).
|
||||||
|
|
||||||
|
## Verification
|
||||||
|
|
||||||
|
**Commands (re-executierbar, ab Workspace-Root):**
|
||||||
|
1. `bash _bmad-output/implementation-artifacts/sandbox-3-4/run-sandbox.sh` — expected: alle Szenarien S1–S6 + N1 + Form-Wahl-Probe mit harten Pass/Fail-Assertionen, Erhaltungs-Invariante erzwungen, Exit 0.
|
||||||
|
2. `grep -n "Synthese aus mehreren Sources\|Revision 2.9" schema/compiler.md` — liefert die Synthese-Sektion + Revisionslog-Eintrag.
|
||||||
|
3. Read-only (AD-3): `git status --porcelain` zeigt keinen Change an `schema/validator.md`/`schema/wiki-compiler.md`/`raw/`.
|
||||||
|
4. Validator-Lauf: alle `wiki/`-Dateien SUCCESS (unverändert, keine Inhalts-Mutation).
|
||||||
|
|
||||||
|
**Manual checks:**
|
||||||
|
- §5.10 trägt Stimulus, ein-Ziel-Regel, `sources`-Liste, gemischte Provenienz, Multi-Beleg-Konsolidierung, Reflektiertheits-Kriterium, AD-4c-Marker, §5.6-Pin, `log.md`-Regel, Erhaltungs-Invariante, Determinismus; §7-Vorbehalt `:343` auf §5.10 aufgelöst; §8-Rev-2.9 mit Abschlussklausel; kein `validator.md`/`wiki-compiler.md`/`raw/`-Diff; kein neuer Standalone (D-3) / keine neue §7-Klasse; §5.9-Abgrenzungs-Reihenfolge unverändert (Synthese = Querschnitt, keine fünfte Form); `wiki/log.md`-Eintrag datiert mit Story-3.4-Semantik + Sandbox-Nachweis + Statuswechsel + Verdikt; `sprint-status.yaml` konsistent.
|
||||||
|
|
||||||
|
## Suggested Review Order
|
||||||
|
|
||||||
|
*(Befüllt nach Review-Abschluss durch step-04. Review-Loop 1 abgeschlossen: kein Loopback, 4 Defers; Status → `done`.)*
|
||||||
|
|
||||||
|
**Synthese-Mechanik (compiler.md §5.10)**
|
||||||
|
|
||||||
|
- Verankerung der Synthese-Dimension — Stimulus, ein-Ziel-Regel, gemischte Provenienz, Reflektiertheit, Erhaltungs-Invariante.
|
||||||
|
[`compiler.md:290`](../../schema/compiler.md#L290)
|
||||||
|
|
||||||
|
- Pkt. 8 — Determinismus-Vertrag: `??`-Duplikat-Kontrolle, Orphan-Fall, `generated.at`-Gap (Home 3.8).
|
||||||
|
[`compiler.md:301`](../../schema/compiler.md#L301)
|
||||||
|
|
||||||
|
**§7/§8-Auflösung**
|
||||||
|
|
||||||
|
- Pkt. 3/4 — AD-16-Disagreement (N2) + AD-4c-Übernahme-Marker (N3) als Sandbox-Nachweise verankert.
|
||||||
|
[`compiler.md:296`](../../schema/compiler.md#L296)
|
||||||
|
|
||||||
|
- Revisionslog 2.9 — Abschlussklausel (AD-3, keine neue §7-Klasse, keine fünfte Update-Form) + Review-Loop-1-Notiz.
|
||||||
|
[`compiler.md:396`](../../schema/compiler.md#L396)
|
||||||
|
|
||||||
|
**Sandbox-Nachweis (re-executierbar)**
|
||||||
|
|
||||||
|
- 10 Szenarien S1–S6 + N1–N3 + FW, harte Erhaltungs-Invariante je Probe; Export & Pass-Statistik.
|
||||||
|
[`run-sandbox.sh:226`](sandbox-3-4/run-sandbox.sh#L226)
|
||||||
|
|
||||||
|
- N2 — AD-16-Disagreement (beide Behauptungen + Disagreement-Eintrag); N3 — AD-4c-Marker.
|
||||||
|
[`run-sandbox.sh:562`](sandbox-3-4/run-sandbox.sh#L562)
|
||||||
|
|
||||||
|
- FW — Form-Wahl-Klassifikationsprobe (Story-3.3-Defer U2/U7) + Zwei-Run-Identität (S6).
|
||||||
|
[`run-sandbox.sh:740`](sandbox-3-4/run-sandbox.sh#L740)
|
||||||
|
|
||||||
|
**Provenienz & Status**
|
||||||
|
|
||||||
|
- Story-Abschluss + Review-Loop-1-Audit — `done`-Flip, 10/10 PASS, 4 Defers.
|
||||||
|
[`log.md:4`](../../wiki/log.md#L4)
|
||||||
|
|
||||||
|
- Implementierungs-Nachweis — Revision 2.9-Eintrag, Validator-Verdikt 7/7 SUCCESS.
|
||||||
|
[`log.md:6`](../../wiki/log.md#L6)
|
||||||
|
|
||||||
|
- Statuskette `in-progress → done` + `last_updated`-Präzision.
|
||||||
|
[`sprint-status.yaml:57`](sprint-status.yaml#L57)
|
||||||
@@ -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-19-2026 06:30
|
last_updated: 08-19-2026 16:40
|
||||||
project: wow20
|
project: wow20
|
||||||
project_key: NOKEY
|
project_key: NOKEY
|
||||||
tracking_system: file-system
|
tracking_system: file-system
|
||||||
@@ -52,9 +52,9 @@ development_status:
|
|||||||
|
|
||||||
epic-3: in-progress
|
epic-3: in-progress
|
||||||
3-1-inkrementellen-datenfluss-implementieren-interpret-reconcile: done
|
3-1-inkrementellen-datenfluss-implementieren-interpret-reconcile: done
|
||||||
3-2-relevanzbestimmung-textual-deterministisch-umsetzen-grep-rip: backlog
|
3-2-relevanzbestimmung-textual-deterministisch-umsetzen-grep-rip: done
|
||||||
3-3-bestehende-concepts-erweitern-präzisieren-korrigieren: backlog
|
3-3-bestehende-concepts-erweitern-präzisieren-korrigieren: done
|
||||||
3-4-wissen-aus-mehreren-sources-synthetisieren: backlog
|
3-4-wissen-aus-mehreren-sources-synthetisieren: done
|
||||||
3-5-leasing-dirty-tree-schutz-für-konkurrierende-producer-umsetz: backlog
|
3-5-leasing-dirty-tree-schutz-für-konkurrierende-producer-umsetz: backlog
|
||||||
3-6-lease-staleness-recovery-basis-absichern: backlog
|
3-6-lease-staleness-recovery-basis-absichern: backlog
|
||||||
3-7-reason-mutate-trennung-und-konsistenz-endzustand-sicherstell: backlog
|
3-7-reason-mutate-trennung-und-konsistenz-endzustand-sicherstell: backlog
|
||||||
|
|||||||
File diff suppressed because one or more lines are too long
@@ -0,0 +1,39 @@
|
|||||||
|
# Kanonischer Schreibweisen-Resolver — canonische Term-Formen (Story 3.2)
|
||||||
|
|
||||||
|
> **Status:** abgeleitet (Story 3.2) — committete, **append-only** Registry des kanonischen Schreibweisen-Resolvers der deterministischen Relevanzbestimmung (Term-Ziehverfahren, `schema/compiler.md` §3.2).
|
||||||
|
> **Normative Grundlage:** `schema/compiler.md` (abgeleitet, Story 3.1/3.2) — §3.2 Relevanzbestimmung (Term-Ziehverfahren, Kanonisierungs-Resolver, dreistufige Erhebung); AD-13 (textuell-deterministische Mittel), AD-17h/A0-19 (Determinismus-Vertrag: gleicher Git-State + gleiche Eingabemenge → gleiche Candidate-Liste in gleicher Reihenfolge), A0-18 (Deterministische Relevanzbestimmung), PRD OQ-3.
|
||||||
|
> **Ableitungsdatum:** 2026-08-19
|
||||||
|
|
||||||
|
## Zweck
|
||||||
|
|
||||||
|
Diese Datei ist die einzige committete Registry des **kanonischen Schreibweisen-Resolvers** der Relevanzbestimmung (§3.2 der Compiler-Instruktion). Sie macht die Normalisierung eines gezogenen Terms **deterministisch pinbar**: weil sie selbst Teil des Git-States ist, ist bei gleichem Git-State die Auflösung „Schreibvariante → canonische Form" eindeutig (AD-17h/A0-19). Sie wird ausschließlich **append-only** gepflegt — bestehende Einträge werden nie verändert, neue Einträge werden nur angehängt (Ergänzung einer neu erkannten canonischen Form/Synonymgruppe).
|
||||||
|
|
||||||
|
**Geltungsbereich:** Die Registry normalisiert **Fachbegriffe** der Relevanzbestimmung (entscheidungsrelevante Terme nach §3.2-Term-Ziehverfahren). Sie fügt **kein** Frontmatter-Feld, **kein** Schema-Prädikat, **keine** §7-Invaliditätsklasse, keinen Validator-/Vertrags-/`raw/`-Change hinzu (AD-3, D-3).
|
||||||
|
|
||||||
|
## Registry-Format
|
||||||
|
|
||||||
|
Je Eintrag (eine Zeile in der Tabelle):
|
||||||
|
|
||||||
|
- **canonische Form** — der normalisierte Term als Kebab-Case-Slug (Nur-Kleinbuchstaben `[a-z0-9-]`, `-`-Kollaps). Genau **eine** canonische Form je Semantik (A0-18).
|
||||||
|
- **erlaubte Schreibvarianten** — Schreibweisen, die auf die canonische Form normalisiert werden (bündel-findend per `-`-Kollaps: `[-–_ ]` → `-`, lowercased gemäß §3.2-Normalisierung). **Gespeicherte Form:** canonical-Form- und Variantenzeile tragen ausschließlich die **bereits normalisierte** Form (lowercased, `-`-gekollabst) — die Spalte enthält also nie das Roh-Notat, sondern dessen Normalisierungs-Resultat. `[]` = keine weitere Variante (nur die canonische Form selbst gilt), bzw. noch keine Einträge committet.
|
||||||
|
- **Semantik** *(optional)* — disambiguierende Kurzangabe, warum dieser Term eine eigene canonische Form trägt (nur bei Bedarf; ergänzt die canonische Form, ist aber nicht Teil der Normalisierungslogik).
|
||||||
|
|
||||||
|
**Lookup-Verfahren (deterministische Reihenfolge):** Die Auflösung eines gezogenen Terms folgt exakt dieser Ordnung: (1) **lowercasing**; (2) **Binde-Varianten-Kollaps** `[-–_ ]` → `-` (§3.2 Pkt. 1b); (3) **Lookup der normalisierten Form** in der Registry — Treffer in der Spalte *canonische Form* oder in der Spalte *erlaubte Schreibvarianten* → Ergebnis ist die **canonische Form** desselben Eintrags. Ist die normalisierte Form nicht auffindbar, gilt der Term **wie notiert** (Kollaps-normalisiert; §3.2 Pkt. 1b — kein stiller Ausschluss). Normalisierung und Lookup sind dadurch vollständig deterministisch: gleiche Normalisierungs-Regeln + gleiche Registry (Git-State) → gleiche Auflösung.
|
||||||
|
|
||||||
|
**Eindeutigkeits-Invariante:** Jede normalisierte Form kommt in der Registry **genau einmal** vor — als canonische Form **oder** als Variante eines Eintrags, nie in beiden Spalten und nie in zwei Einträgen (auch nicht als Canon eines Eintrags und Variante eines anderen). Wird diese Invariante verletzt, ist der Resolver-Zustand nicht eindeutig auflösbar.
|
||||||
|
|
||||||
|
**Append-only-Regel:** Neue Zeilen werden am Ende der Tabelle angehängt; ein bestehender Eintrag wird **nie** editiert. Muss eine Semantik umbenannt werden, wird das in `deferred-work.md` als Mapping-/AD-7d-Nähe-Fall notiert (Ask-First), nicht durch Edits in dieser Registry.
|
||||||
|
|
||||||
|
**Konflikt-Verfahren (keine stillen Anhängungen):** Soll ein neuer Eintrag eine normalisierte Form tragen, die bereits in der Registry vorkommt (Canon oder Variante — auch mit abweichender Semantik), wird **nicht** angehängt (das würde die Eindeutigkeits-Invariante verletzen): der Konflikt wird in `deferred-work.md` notiert und dem Nutzer als Ask-First-Frage vorgelegt (Analogie: Umbenennungsregel oben), bis eine Entscheidung eine eindeutige Auflösung erlaubt.
|
||||||
|
|
||||||
|
## Registry
|
||||||
|
|
||||||
|
| canonische Form | erlaubte Schreibvarianten | Semantik |
|
||||||
|
|---|---|---|
|
||||||
|
| — (noch keine Einträge committet) | `[]` | Die Registry ist leer. Mit dem ersten Run, der einen fachlichen Term deterministisch zieht (Story-3.2-Term-Ziehverfahren, §3.2), wird der erste Eintrag hier committet (append-only). |
|
||||||
|
|
||||||
|
*Hinweis (Eröffnungs-Zustand):* Für die Story-3.2-Instruktion selbst ist kein Term-Eintrag erforderlich — die Relevanzbestimmung ist auch mit leerer Registry vollständig definiert (gezogene Terme werden wie notiert verwendet, solange keine canonische Auflösung committet ist; §3.2 Pkt. 1 — kein stiller Ausschluss). Die committete, leere Registry ist der deterministisch pinbare Resolver-Zustand.
|
||||||
|
|
||||||
|
## Abschlussklausel
|
||||||
|
|
||||||
|
Keine Änderung an `schema/wiki-compiler.md`/`schema/validator.md`/`raw/` (AD-3); keine neue §7-Invaliditätsklasse; kein Standalone (D-3); keine Vertragsänderung. Diese Datei ist ein neues Artefakt unter `schema/`, nebengeordnet zur Compiler-Instruktion — gleiche read-only-Hierarchie (nur der append-only-Ausbau ist vorgesehen).
|
||||||
+54
-10
@@ -38,10 +38,30 @@ Bestätigung (Story 1.4): schema/validator.md (mechanische Prüfung, kein L
|
|||||||
|
|
||||||
1. Vor der Anlage prüfen, ob die erkannte Wissenseinheit **bereits als Concept** im Bundle existiert (deterministisch: Dateikollision über den relativen OKF-Pfad, AD-7a).
|
1. Vor der Anlage prüfen, ob die erkannte Wissenseinheit **bereits als Concept** im Bundle existiert (deterministisch: Dateikollision über den relativen OKF-Pfad, AD-7a).
|
||||||
2. **Update-Routing (statt Kollision-Hold; Story 3.1):** Existiert bereits ein Concept mit dem Ziel-Pfad, wird **nicht** stumm überschrieben und **kein** Duplikat angelegt — die erkannte Wissenseinheit wird als **Update-Kandidat** im **bestehenden Concept-Pfad** aktualisiert (Erweitern/Präzisieren/Korrigieren gemäß §5.9; FR-6). Die Mutationsmechanik für Updates spezifiziert §5.9; der Kollisions-Hold-Schutzprinzip („nicht stumm überschreiben") bleibt als Grundsatz der Erhaltung erhalten (AD-16-Default: bestehende Provenienz/Inhalte werden nie ohne Beleg entfernt). Der **Neu-Anlage-Pfad** dieser Instruktion bleibt für Wissenseinheiten, deren Ziel-Pfad **nicht** belegt ist (§5.1/§5.7).
|
2. **Update-Routing (statt Kollision-Hold; Story 3.1):** Existiert bereits ein Concept mit dem Ziel-Pfad, wird **nicht** stumm überschrieben und **kein** Duplikat angelegt — die erkannte Wissenseinheit wird als **Update-Kandidat** im **bestehenden Concept-Pfad** aktualisiert (Erweitern/Präzisieren/Korrigieren gemäß §5.9; FR-6). Die Mutationsmechanik für Updates spezifiziert §5.9; der Kollisions-Hold-Schutzprinzip („nicht stumm überschreiben") bleibt als Grundsatz der Erhaltung erhalten (AD-16-Default: bestehende Provenienz/Inhalte werden nie ohne Beleg entfernt). Der **Neu-Anlage-Pfad** dieser Instruktion bleibt für Wissenseinheiten, deren Ziel-Pfad **nicht** belegt ist (§5.1/§5.7).
|
||||||
**Kandidatenliste (betroffen-Bestimmung):** Vor jeder Mutation erhebt der Producer die Menge der betroffenen Concepts als **nachvollziehbare Kandidatenliste** (relative OKF-Pfade ohne `.md`) mit **textuell-deterministischen Mitteln** (AD-13): (a) Term-/Konzept-Überschneidung zwischen der neuen Evidenz und den bestehenden Concept-Bodies via `grep`/`ripgrep` über `wiki/` (z. B. `rg -l '<konzeptterm>' wiki/`); (b) `index.md`-Traversal (Bundleroot- und Area-`index.md`-Dateien, gewurzelte Erreichbarkeit Root → Area → Concept, §5.8) der dadurch betroffenen Bereiche; (c) Link-Following aus bereits betroffenen Concepts (§5.6-Pin) auf weitere Concept-Pfade — **mit besuchter Menge** (ein bereits besuchter Concept-Pfad wird nicht erneut besetzt; keine Schleife bei zyklischen Links). Der `<konzeptterm>` aus (a) wird in Phase (1) (Interpretieren, §2) aus der neuen Evidenz abgeleitet — die Erhebung *mit festem Term* ist textuell-deterministisch (fester Term → deterministische Grep-Ausgabe); die Term-*Auswahl* folgt der §2-Interpretation, und der feinkörnige Term-Mechanismus (Kanonisierung, Synonyme) ist Story 3.2 vorbehalten. Die Kandidatenliste wird textuell festgehalten (Pre-Run-Reconcile-Check-Block, §5.9 Pkt. 6). Keine Embeddings/Vector-Suche (AD-13); der feinkörnige Relevanz-Findungsmechanismus als eigene Ausformulierung ist Story 3.2 vorbehalten — §5.9 bindet die Erhebung an die hier genannten deterministischen Mittel.
|
**Kandidatenliste (betroffen-Bestimmung):** Vor jeder Mutation erhebt der Producer die Menge der betroffenen Concepts als **nachvollziehbare Kandidatenliste** (relative OKF-Pfade ohne `.md`) mit **textuell-deterministischen Mitteln** (AD-13): (a) Term-/Konzept-Überschneidung zwischen der neuen Evidenz und den bestehenden Concept-Bodies via `grep`/`ripgrep` über `wiki/` (z. B. `rg -l '<term>' -g '!log.md' wiki/` bzw. GNU-grep-Form `grep -rl '<term>' --exclude=log.md wiki/`); (b) `index.md`-Traversal (Bundleroot- und Area-`index.md`-Dateien, gewurzelte Erreichbarkeit Root → Area → Concept, §5.8) der dadurch betroffenen Bereiche; (c) Link-Following aus bereits betroffenen Concepts (§5.6-Pin) auf weitere Concept-Pfade — **mit besuchter Menge** (ein bereits besuchter Concept-Pfad wird nicht erneut besetzt; keine Schleife bei zyklischen Links). Die Erhebung folgt der feinkörnigen, verbindlichen Mechanik in **§3.2 Relevanzbestimmung (Story 3.2)** — Term-Ziehverfahren (deterministisch aus der neuen Evidenz abgeleitet, kanonischer Schreibweisen-Resolver `schema/canonical-terms.md`, mehrere Terme je Einheit), dreistufige Erhebung mit `log.md`-Exklusion (die Candidate-Liste ist auf Concept-Pfade definiert, `log.md` ist kein Kandidat) und Determinismus-Vertrag (AD-17h/A0-19) — **Erhebung nach §3.2**. Die Kandidatenliste wird textuell festgehalten (Pre-Run-Reconcile-Check-Block, §5.9 Pkt. 6). Keine Embeddings/Vector-Suche (AD-13); §5.9 bindet die Erhebung an die in §3.2 genannten deterministischen Mittel.
|
||||||
Löst eine erkannte Wissenseinheit auf **keinen** bestehenden Concept-Pfad auf (kein Update-Kandidat), wird sie als **neue** Einheit über den Neu-Anlage-Pfad (§5.1/§5.7, §3-Pkt.-1/-2-Kollisionsprüfung ist damit erstbestanden) behandelt.
|
Löst eine erkannte Wissenseinheit auf **keinen** bestehenden Concept-Pfad auf (kein Update-Kandidat), wird sie als **neue** Einheit über den Neu-Anlage-Pfad (§5.1/§5.7, §3-Pkt.-1/-2-Kollisionsprüfung ist damit erstbestanden) behandelt.
|
||||||
3. Der Run prüft zusätzlich, ob `wiki/index.md` als Bundleroot existiert (V-1-Vorbedingung des Validators); fehlt sie, darf kein Concept erzeugt oder aktualisiert werden (Run-FAIL, Vertrag §2).
|
3. Der Run prüft zusätzlich, ob `wiki/index.md` als Bundleroot existiert (V-1-Vorbedingung des Validators); fehlt sie, darf kein Concept erzeugt oder aktualisiert werden (Run-FAIL, Vertrag §2).
|
||||||
|
|
||||||
|
## 3.2 Relevanzbestimmung (Story 3.2)
|
||||||
|
|
||||||
|
Diese Sektion ist der **einzige Instruktions-Ort** der feinkörnigen, **textuell-deterministischen Relevanz-Findungsmechanik** (D-3, Story 3.2) und die **verbindliche Ausformulierung der §3-Pkt.-2-Kandidatenerhebung** („Erhebung nach §3.2"). Sie macht die Relevanzbestimmung vollständig deterministisch vorgegeben (AD-17h/A0-19): gleicher Git-State + gleiche Eingabemenge → identische Candidate-Liste, in identischer Reihenfolge — ohne Embedding/Vector/KG im Compiler-Kern (AD-13, A0-18, PRD OQ-3). Sie fügt **kein** Prädikat, keine neuen §7-Invaliditätsklassen und keinen Schema-/Validator-/`raw/`-Change hinzu (AD-3); die Candidate-Liste ist auf Concept-Pfade definiert, `log.md` ist ausdrücklich **kein** Kandidat (sie wird per Exklusions-Flag strukturell exkludiert — sonst wäre der eigene `log.md`-Eintrag bei jedem Term, den er zitiert, selbst „Kandidat"; die tool-spezifischen Flag-Formen nennt Pkt. 2a — `rg -g '!log.md'` bzw. `grep --exclude=log.md`; §5.9 Pkt. 5 behandelt `log.md` gesondert als erlaubtes Mitglied des Diff-Selbsttest-Satzes).
|
||||||
|
|
||||||
|
1. **Term-Ziehverfahren (deterministisch):** Die Candidate-Terme werden deterministisch aus der neuen Evidenz (committete `raw/`-Dateien, §1 Pkt. 1/2) abgeleitet — nicht freie LLM-Auswahl:
|
||||||
|
- **(a) Bedeutungstragende Token-Folgen:** Der Producer benennt die bedeutungstragenden Fachbegriffe der Wissenseinheit gemäß der §2-Interpretation (fachliche Signifikanz; kein Stoppwort-Abgleich nötig, aber auch kein freies Urteil). Der Umfang „bedeutungstragend" ist die Auswahl derjenigen Begriffe, die das erkannte Thema identifizieren — als Token-Folgen über eine sprachliche Einheit hinweg zulässig (z. B. `quanten-protocol-schlüssel`).
|
||||||
|
- **(b) Normalisierung über den kanonischen Schreibweisen-Resolver:** Jeder gezogene Term wird durchgängig normalisiert: (i) lowercasing; (ii) Binde-Varianten-Kollaps `[-–_ ]` → `-` (En-Dash `–`, Bindestrich `-`, Unterstrich `_`, Leerzeichen — jedes Vorkommen wird in einen einzelnen Bindestrich kollabiert); (iii) Auflösung über die committete, append-only Registry **`schema/canonical-terms.md`** (ein Eintrag = canonische Form + erlaubte Schreibvarianten; der Resolver ist damit Bestandteil des Git-States und die Auflösung pinbar). **Genau eine canonische Form je Semantik** (A0-18). **Kein stiller Ausschluss:** ist eine Variante nicht in der Registry auflösbar, wird der Term **wie notiert** verwendet (Kollaps-normalisiert) — niemals still verworfen.
|
||||||
|
- **(c) Mehrere Terme je Einheit erlaubt:** Eine Wissenseinheit kann mehrere bedeutungstragende Terme tragen; die Candidate-Liste ist dann die **Vereinigung** der Treffer über alle Terme, bereinigt über die besuchte Menge (Pkt. 3c — ein Pfad nur einmal).
|
||||||
|
- **Bekannte Determinismus-Lücke (aufgezeichnet, nicht still hinzugefügt):** Die Kollaps-Klasse `[-–_ ]` deckt den Em-Dash `—` **nicht** ab (nur En-Dash `–`). Em-Dash-Varianten fallen damit nicht unter den Kollaps — eine erkannte Synonym-Lücke, die **Story 3.8** als offene Determinismus-Frage übergeben ist (s. `deferred-work.md`; nicht stillschweigend in §3.2 ergänzt).
|
||||||
|
2. **Term-übergreifende Erhebung über `wiki/` (drei Stufen):** Der Producer erhebt die betroffenen Concept-Pfade in **drei textuell-deterministischen Stufen** (a → b → c). Ab der Workspace-Root:
|
||||||
|
- **(a) Stufe a — grep/ripgrep über `wiki/`:** `rg -l '<term>' -g '!log.md' wiki/` (rgs native Glob-Exklusions-Syntax — `--exclude` ist kein rg-Flag; das GNU-grep-Äquivalent ist `grep -rl '<term>' --exclude=log.md wiki/`, §5.6-Scan-Scope-Konvention). `<term>` = jeder gezogene Term aus Pkt. 1 nach Normalisierung. Beide Formen exkludieren `log.md` **strukturell** (unabhängig von dessen Inhalt) — die Candidate-Liste bleibt auf Concept-Pfade definiert.
|
||||||
|
- **(b) Stufe b — `index.md`-Traversal:** Für die in Stufe a getroffenen Bereiche (und die Bundleroot) folgt der Producer der gewurzelten Erreichbarkeit Root → Area → Concept (§5.8): trifft ein Term nur `wiki/index.md` oder eine Area-`index.md` (nicht einen Concept-Body), so sind alle **darunter gewurzelten Concept-Pfade** Treffer der Stufe b (TRAVERSAL_REACH_ONLY). Fehlende Bundleroot → Run-FAIL (V-1, §3 Pkt. 3, besteht fort).
|
||||||
|
- **(c) Stufe c — Link-Following mit besuchter Menge:** Aus bereits als betroffen erhobenen Concepts folgt der Producer die Concept-Links (§5.6-Pin) auf weitere Concept-Pfade — file-relativ auflösen (§5.7 Pkt. 4), **jeder bereits besuchte Concept-Pfad wird nicht erneut besucht** (besuchte Menge): Zyklen (A → B → A) enden, die Candidate-Liste bleibt endlich (LINK_FOLLOWING_ZYKLUS).
|
||||||
|
3. **Candidate-Liste (Ausgabe) + Determinismus-Vertrag:**
|
||||||
|
- **(a) Form:** Die Candidate-Liste ist die Menge der betroffenen Concept-Pfade als **relative OKF-Pfade ohne `.md`** (AD-7a). Normalisierung der Ausgabe: aus jedem Treffer `wiki/<pfad>.md` werden `wiki/`-Präfix und `.md`-Suffix gestrippt (deterministischer Schritt → `wiki/knowledge-kompilation-inkrementell.md` wird `knowledge-kompilation-inkrementell`).
|
||||||
|
- **(b) Reihenfolge (Zuwachs-Sicht-Ordnung):** Die Erhebung ordnet die Candidate-Liste deterministisch in **Zuwachs-Sicht-Ordnung** — Stufe-a-Treffer zuerst, danach Stufe-b-Treffer, danach Stufe-c-Treffer; **innerhalb jeder Stufe rein lexikografisch aufsteigend (LC_ALL=C bzw. deterministische byte-Ordnung, AD-17h)**. Die Reihenfolge des ziehenden Terms bestimmt nur die **Verarbeitungsreihenfolge** der Terme in Stufe a (Interpretation/Erhebung), **nicht** die Reihenfolge der Candidate-Liste: dieselbe Treffermenge → identische Liste, unabhängig davon, in welcher Reihenfolge die Terme gezogen/verarbeitet wurden (AD-17h/A0-19). Die Stufe-b/c-Treffer sind damit **positional bestimmt** (nach allen Stufe-a-Treffern), nicht vom Dateisystem-Traversal abhängig.
|
||||||
|
- **(c) Keine Duplikate:** Vereinigung über alle Terme und Stufen, bereinigt über die besuchte Menge (Pkt. 1c/2c) — jeder Pfad erscheint genau einmal.
|
||||||
|
- **(d) NO_MATCH:** Trifft kein Term ein bestehendes Concept, ist die Candidate-Liste **leer** → `UNTOUCHED_CONCEPT` (Story-3.1-Pfad): keine Mutation, kein `log.md`-Zusatz (leere Menge ist Teilmenge jeder erlaubten Menge — Ghost-Diff-negativ, §5.9 Pkt. 5).
|
||||||
|
- **(e) Gleichheits-Identität:** Gleicher Git-State + gleiche Eingabemenge → identische Candidate-Liste, in identischer Reihenfolge (AD-17h/A0-19). Der Selbsttest (Membership + Zwei-Run-Identität) wird in der Story-Specifizierungs-Verifikation und im `wiki/log.md`-Nachweis belegt.
|
||||||
|
|
||||||
## 4. Synthetisieren (Provenienz & Trust)
|
## 4. Synthetisieren (Provenienz & Trust)
|
||||||
|
|
||||||
Je neuem Concept werden die Frontmatter-Metadaten nach Vertrag §3 festgelegt:
|
Je neuem Concept werden die Frontmatter-Metadaten nach Vertrag §3 festgelegt:
|
||||||
@@ -196,7 +216,7 @@ Bereichszuordnung und Concept-Hierarchie sind **textual-deterministisch** (AD-7c
|
|||||||
| `wiki/llm-wiki-prinzip.md` | `llm-wiki-prinzip` |
|
| `wiki/llm-wiki-prinzip.md` | `llm-wiki-prinzip` |
|
||||||
|
|
||||||
Eine als Area gedachte Anlage (`wiki/<area>/index.md` + Concept darunter) ist damit **konform**; der Bereichs-Hinweis aus §5.1 ist aufgelöst. Konzept-`id`s (s. `sources[].id`, §5.5 Pkt. 3) sind unabhängig davon je Concept eindeutig — Adressraum ist Concept-Pfad + `id`.
|
Eine als Area gedachte Anlage (`wiki/<area>/index.md` + Concept darunter) ist damit **konform**; der Bereichs-Hinweis aus §5.1 ist aufgelöst. Konzept-`id`s (s. `sources[].id`, §5.5 Pkt. 3) sind unabhängig davon je Concept eindeutig — Adressraum ist Concept-Pfad + `id`.
|
||||||
3. **Top-Level-Update-Routing (A0-10, §3-nachgeführt):** Kollidiert ein Erstellungskandidat mit einem bestehenden Top-Level-Pfad (deterministisch: Dateikollision über den relativen OKF-Pfad, §3.1/§3.2, AD-7a), löst das **Update-Routing (§3 Pkt. 2, §5.9)** aus — **kein** neues Prädikat, **kein** Duplikat, **kein** stiller Overwrite, keine neue Datei, kein Index-Link: die erkannte Einheit wird als **Update-Kandidat** im bestehenden Concept-Pfad behandelt (Mutation gemäß §5.9). **Kein MOVE/Neuzuordnung bestehender Concepts** — das ist Kuratierung mit AD-7d-Redirect-Pflicht (Epic-3-Nähe, nicht in den ACs dieser Story; Ask-First).
|
3. **Top-Level-Update-Routing (A0-10, §3-nachgeführt):** Kollidiert ein Erstellungskandidat mit einem bestehenden Top-Level-Pfad (deterministisch: Dateikollision über den relativen OKF-Pfad, §3 Pkt. 1/2, AD-7a; „§3.2" meint hier §3-Elemente Pkt. 1/2 — die §3.2-Relevanzbestimmung ist eine eigene Sektion, s. §3.2), löst das **Update-Routing (§3 Pkt. 2, §5.9)** aus — **kein** neues Prädikat, **kein** Duplikat, **kein** stiller Overwrite, keine neue Datei, kein Index-Link: die erkannte Einheit wird als **Update-Kandidat** im bestehenden Concept-Pfad behandelt (Mutation gemäß §5.9). **Kein MOVE/Neuzuordnung bestehender Concepts** — das ist Kuratierung mit AD-7d-Redirect-Pflicht (Epic-3-Nähe, nicht in den ACs dieser Story; Ask-First).
|
||||||
4. **File-relatives Link-Auflösungsmodell (löst das §5.6-Defer):** Concept-Links sind **file-relativ** zur `.md`-Datei (AD-8/FR-10/AD-7b — eine syntaktische Form, beide Ebenen): bei Root-Dateien ist file-relativ ≡ bundle-relativ (die bestehenden Bestands-Links bleiben byte-identisch, Null-Delta zu Story 2.3); in Areas bezeichnen `../`-Präfixe die Aufwärts-Ziele **innerhalb `wiki/`** (`[<text>](../<root-concept>.md)`). Auflösung & Containment (§5.6 Pkt. 3, Formel 3): `../`-Ziel relativ zum Quell-Verzeichnis auflösen, `X/..`-Segmente kollabieren, aufgelöster Pfad MUSS unter `wiki/` bleiben — sonst `DANGLING` (Out-of-Bundle-`..`-Escape gesperrt, Loop-1-Fix). `../schema/*` als andere Schicht (Ziel außerhalb des Bundles) bleibt exkludiert — Abgrenzung über das **Zielverzeichnis** (unter `wiki/` = in-Bundle), nicht über das bloße `../`-Präfix; einstufiges `../schema/*` aus Root-Dateien ist damit weiterhin pin-frei (bestehende Root-`index.md`-Links unverändert). `.md`-Endung bleibt Pflicht (§5.6 Pin).
|
4. **File-relatives Link-Auflösungsmodell (löst das §5.6-Defer):** Concept-Links sind **file-relativ** zur `.md`-Datei (AD-8/FR-10/AD-7b — eine syntaktische Form, beide Ebenen): bei Root-Dateien ist file-relativ ≡ bundle-relativ (die bestehenden Bestands-Links bleiben byte-identisch, Null-Delta zu Story 2.3); in Areas bezeichnen `../`-Präfixe die Aufwärts-Ziele **innerhalb `wiki/`** (`[<text>](../<root-concept>.md)`). Auflösung & Containment (§5.6 Pkt. 3, Formel 3): `../`-Ziel relativ zum Quell-Verzeichnis auflösen, `X/..`-Segmente kollabieren, aufgelöster Pfad MUSS unter `wiki/` bleiben — sonst `DANGLING` (Out-of-Bundle-`..`-Escape gesperrt, Loop-1-Fix). `../schema/*` als andere Schicht (Ziel außerhalb des Bundles) bleibt exkludiert — Abgrenzung über das **Zielverzeichnis** (unter `wiki/` = in-Bundle), nicht über das bloße `../`-Präfix; einstufiges `../schema/*` aus Root-Dateien ist damit weiterhin pin-frei (bestehende Root-`index.md`-Links unverändert). `.md`-Endung bleibt Pflicht (§5.6 Pin).
|
||||||
5. **Area-`index.md` (Vertrag §2/§6, AD-9/FR-11):** Eine Area besitzt exakt eine `wiki/<area>/index.md`, **frontmatterlos** (Punkt 10), die ihre Area-Concepts in der gepinnten Form (§5.6) verlinkt (Identity = relativer OKF-Pfad ohne `.md`). Die Bundleroot-`index.md` verlinkt die Area-`index.md` (Navigation Root → Area, AD-9). **Area ohne `index.md` ist strukturell invalide** und wird vom Validator wörtlich gemeldet: `FAIL … Punkt 11: Index-Regel verletzt (Area ohne index.md=<area>)` (kein inventiertes Label; Verdikt-Grammatik §5 des Validators). Ein neues Area-Concept MUSS in `wiki/<area>/index.md` verlinkt sein (§5.3 Pkt. 3 ist entsprechend §5.7-nachgeführt); sonst Punkt 11.
|
5. **Area-`index.md` (Vertrag §2/§6, AD-9/FR-11):** Eine Area besitzt exakt eine `wiki/<area>/index.md`, **frontmatterlos** (Punkt 10), die ihre Area-Concepts in der gepinnten Form (§5.6) verlinkt (Identity = relativer OKF-Pfad ohne `.md`). Die Bundleroot-`index.md` verlinkt die Area-`index.md` (Navigation Root → Area, AD-9). **Area ohne `index.md` ist strukturell invalide** und wird vom Validator wörtlich gemeldet: `FAIL … Punkt 11: Index-Regel verletzt (Area ohne index.md=<area>)` (kein inventiertes Label; Verdikt-Grammatik §5 des Validators). Ein neues Area-Concept MUSS in `wiki/<area>/index.md` verlinkt sein (§5.3 Pkt. 3 ist entsprechend §5.7-nachgeführt); sonst Punkt 11.
|
||||||
6. **Worked Example (Area-Concept):** `wiki/wissensarchitektur/source-material.md` — ein neues Area-Concept: `type: concept`, `sources` → `raw/architecture-spine/architecture-spine-2026-08-14.md` (s1) + `raw/prd/prd-wow20-2026-08-14.md` (s2), §5.5-Inline-Verweise je belegter Aussage, Body-Links auf Root-Concepts in der file-relativen `../`-Form (`[LLM-Wiki-Prinzip](../llm-wiki-prinzip.md)` u. ä.), inhaltsbegründet. Verlinkt in der Area-`index.md` `wiki/wissensarchitektur/index.md` (frontmatterlos, gepinnte Form); diese wiederum in der Bundleroot `wiki/index.md` (Area-Sektion). §5.6-Formel-1 (Bestands-Check) erfasst die Area-Links; Formel 2 (Form-Check) `0`; Formel 3 (Dangling-Check) keine Ausgabe (in-Bundle-`../`-Auflösung, §5.7 Pkt. 4).
|
6. **Worked Example (Area-Concept):** `wiki/wissensarchitektur/source-material.md` — ein neues Area-Concept: `type: concept`, `sources` → `raw/architecture-spine/architecture-spine-2026-08-14.md` (s1) + `raw/prd/prd-wow20-2026-08-14.md` (s2), §5.5-Inline-Verweise je belegter Aussage, Body-Links auf Root-Concepts in der file-relativen `../`-Form (`[LLM-Wiki-Prinzip](../llm-wiki-prinzip.md)` u. ä.), inhaltsbegründet. Verlinkt in der Area-`index.md` `wiki/wissensarchitektur/index.md` (frontmatterlos, gepinnte Form); diese wiederum in der Bundleroot `wiki/index.md` (Area-Sektion). §5.6-Formel-1 (Bestands-Check) erfasst die Area-Links; Formel 2 (Form-Check) `0`; Formel 3 (Dangling-Check) keine Ausgabe (in-Bundle-`../`-Auflösung, §5.7 Pkt. 4).
|
||||||
@@ -247,6 +267,11 @@ Diese Sektion ist der **einzige Instruktions-Ort** der Update-Mutationsmechanik
|
|||||||
- **No-Op-Kandidat (Review-Loop-2-Präzisierung):** Erhebt die Kandidatenerhebung einen Pfad, dessen Body die neue Evidenz **bereits vollständig enthält** (keiner der drei Update-Formen greift — keine neue belegte Aussage, keine Schärferung, keine Ersetzung), ist der Kandidat ein **No-Op**: **keine** Body-Mutation, **kein** `generated.at`-Bump, **kein** `sources`-Zusatz, **kein** `log.md`-Eintrag — der Pfad bleibt byte-identisch (Erhaltungs-Invariante, Pkt. 5). Die Entscheidung „keiner der drei Formata greift" ist selbst textuell deterministisch: sie trifft nur, wenn die neue Evidenz keine Aussage trägt, die im Body nicht bereits als belegte Aussage vorhanden ist (Term-/Stellen-Abgleich mit §5.5-Inline-Verweisen); im Zweifel (neue belegte Aussage auch nur in abgewandelter Form) greift Erweitern/Präzisieren — der No-Op ist die *engere* Auslegung.
|
- **No-Op-Kandidat (Review-Loop-2-Präzisierung):** Erhebt die Kandidatenerhebung einen Pfad, dessen Body die neue Evidenz **bereits vollständig enthält** (keiner der drei Update-Formen greift — keine neue belegte Aussage, keine Schärferung, keine Ersetzung), ist der Kandidat ein **No-Op**: **keine** Body-Mutation, **kein** `generated.at`-Bump, **kein** `sources`-Zusatz, **kein** `log.md`-Eintrag — der Pfad bleibt byte-identisch (Erhaltungs-Invariante, Pkt. 5). Die Entscheidung „keiner der drei Formata greift" ist selbst textuell deterministisch: sie trifft nur, wenn die neue Evidenz keine Aussage trägt, die im Body nicht bereits als belegte Aussage vorhanden ist (Term-/Stellen-Abgleich mit §5.5-Inline-Verweisen); im Zweifel (neue belegte Aussage auch nur in abgewandelter Form) greift Erweitern/Präzisieren — der No-Op ist die *engere* Auslegung.
|
||||||
- **Mehrfach-Treffer-Konsolidierung (ein Run, mehrere Einheiten auf denselben Concept-Pfad):** Ergeben mehrere neue Wissenseinheiten desselben Runs auf **demselben** bestehenden Concept-Pfad ein Update, werden ihre Mutationen in **einem einzigen Update dieses Pfads** konsolidiert (eine Body-Änderung, **ein** `log.md`-Eintrag „Story 3.1-Update", ein konsolidierter `sources`-Zuwachs, **ein** `generated.at`-Zeitstempel — der einmalige `at` des Runs). Die Reihenfolge der Einheiten wird dabei textual-deterministisch aus der Verarbeitung der Evidenz abgeleitet: REIHENFOLGE = **Auftritt der Einheiten in der Zuwachs-Sicht** (Datei-Reihenfolge des R-1-Zuwachsbefunds, dann Stellen-Reihenfolge innerhalb der Datei); nur bei Einheiten desselben Ortes (identischer Dateipfad + identische Stelle) greift die lexicografische Ordnung als Tie-Break (Review-Loop-2-Präzisierung: die Reihenfolge ist für *alle* Einheiten definiert, nicht nur für vollständig unabhängige). Die AD-16-Default-Erhaltung bleibt für jede betroffene Stelle gewahrt.
|
- **Mehrfach-Treffer-Konsolidierung (ein Run, mehrere Einheiten auf denselben Concept-Pfad):** Ergeben mehrere neue Wissenseinheiten desselben Runs auf **demselben** bestehenden Concept-Pfad ein Update, werden ihre Mutationen in **einem einzigen Update dieses Pfads** konsolidiert (eine Body-Änderung, **ein** `log.md`-Eintrag „Story 3.1-Update", ein konsolidierter `sources`-Zuwachs, **ein** `generated.at`-Zeitstempel — der einmalige `at` des Runs). Die Reihenfolge der Einheiten wird dabei textual-deterministisch aus der Verarbeitung der Evidenz abgeleitet: REIHENFOLGE = **Auftritt der Einheiten in der Zuwachs-Sicht** (Datei-Reihenfolge des R-1-Zuwachsbefunds, dann Stellen-Reihenfolge innerhalb der Datei); nur bei Einheiten desselben Ortes (identischer Dateipfad + identische Stelle) greift die lexicografische Ordnung als Tie-Break (Review-Loop-2-Präzisierung: die Reihenfolge ist für *alle* Einheiten definiert, nicht nur für vollständig unabhängige). Die AD-16-Default-Erhaltung bleibt für jede betroffene Stelle gewahrt.
|
||||||
- **Commit-Boundary = Mutations-Boundary (AD-17f, §0):** Auch im Update-Pfad werden **Zwischenstände nie als fertige Mutation veröffentlicht** — die Mutationen der Update-Kandidaten werden als Ganzes committet, und zwar erst, nachdem der Diff-Selbsttest (Pkt. 5) ohne Ghost-Diff abgeschlossen ist. Ein Ghost-Diff ist dann als **Abbruch-Vorlauf „korrigierter Teil-Run"** im `log.md`-Eintrag des betroffenen Runs gekoppelt (siehe Disagreement-/Run-Notiz Pkt. 4), damit die Ursache textuell nachvollziehbar bleibt.
|
- **Commit-Boundary = Mutations-Boundary (AD-17f, §0):** Auch im Update-Pfad werden **Zwischenstände nie als fertige Mutation veröffentlicht** — die Mutationen der Update-Kandidaten werden als Ganzes committet, und zwar erst, nachdem der Diff-Selbsttest (Pkt. 5) ohne Ghost-Diff abgeschlossen ist. Ein Ghost-Diff ist dann als **Abbruch-Vorlauf „korrigierter Teil-Run"** im `log.md`-Eintrag des betroffenen Runs gekoppelt (siehe Disagreement-/Run-Notiz Pkt. 4), damit die Ursache textuell nachvollziehbar bleibt.
|
||||||
|
- **Operationelle Ausführungs-Ebene je Update-Form (Präzisierungsebene, Story 3.3 / Revision 2.8; Präzisierung des frozen Story-3.1-Regeltexts, keine Re-Negotiation — die operationellen Regeln sind die deterministische Brücke Regel → Run, AD-17h/A0-19):** Die folgenden Ausführungs-Regeln präzisieren, **was der Producer bei jedem Form-Fall konkret tut und was er unangetastet lässt**. Je Update-Form gelten (a) das **Abgrenzungskriterium** (Welche Form greift wann? — ausschließlich aus der committeten Evidenz abgeleitet), (b) die **Struktur-Erhaltungsregel** (was bleibt unverändert — die „Struktur" aus FR-6/AC-2: Frontmatter-Subset, bestehende belegte Aussagen mit §5.5-Inline-Verweisen, §5.6-Pin) und (c) der **Textgenauigkeits-Rahmen** (wie geschärft wird). **No-Op ist keine eigene Form, sondern die Nicht-Form** (keiner der drei Form-Bullets greift) mit eigenem Abgrenzungskriterium und der Erhaltungsregel „volle Byte-Identität". **Abgrenzungs-Reihenfolge (Prozess, AD-17h):** Der Producer prüft die Abgrenzungskriterien **in fester Reihenfolge Korrigieren → Präzisieren → Erweitern → No-Op** (strikt pro Evidenz-Einheit) und wählt die **erste zutreffende** Form: (1) ersetzt die Evidenz eine bestehende belegte Aussage als fehlerhaft/überholt → **Korrigieren**; (2) sonst schärft sie eine bestehende Formulierung/Abgrenzung (ersetzte Wortlautfolge → Ersetzungsbeleg nötig) → **Präzisieren**; (3) sonst trägt sie eine neue belegte Aussage, die noch nicht existiert → **Erweitern**; (4) sonst → **No-Op** (engere Auslegung). Damit ist jeder Einheit genau eine Form zugeordnet (kein Form-Überlapp, gleiche Evidenz → gleiche Form). Gleicher Git-State + gleiche Eingabemenge → identischer Update-Vorgang (AD-17h); der `generated.at`-Wanduhr-Gap (gleiches Eingabeset, unabhängige Runs, verschiedene `at`) bleibt offene A0-20-Konvention mit Home **Story 3.8** (oben, `generated.at`-Konvention) — unverändert bindend.
|
||||||
|
- **Korrigieren — Abgrenzungskriterium:** greift genau dann, wenn die Evidenz eine bestehende Aussage als **fehlerhaft/überholt ersetzt** (ersetzte Wortlautfolge liegt vor → Ersetzungsbeleg nötig). **Struktur-Erhaltungsregel (Korrigieren):** die ersetzte Aussage wird **nicht still gelöscht**, sondern explizit durch die ersetzende Aussage **abgelöst**; die Ersetzung trägt den **Ersetzungsbeleg** (§5.5, AD-16-Default Erhaltung); die Ablösung erfolgt an der Position der ersetzten Aussage — dabei bleibt die Aussage **in ihrer ursprünglichen Wortlautfolge als abgelöster Bestand** erhalten (die Beleg-Kennung bleibt gültig, nur die Aussage-Fortschreibung wechselt), der Rest des Bodys bleibt unverändert. **Textgenauigkeits-Rahmen (Korrigieren):** nur die fehlerhafte/überholte Aussage wird ersetzt; keine flankierende Umschreibung.
|
||||||
|
- **Präzisieren — Abgrenzungskriterium:** greift genau dann, wenn die Evidenz eine **bestehende Formulierung/Abgrenzung schärft** (präzisierende Information an derselben Aussage, ohne Ersatz). **Struktur-Erhaltungsregel (Präzisieren):** die geschärfte Aussage bleibt an ihrer **Position**, das Satzgefüge wird **nicht umgebaut**, umgebende Aussagen, §5.5-Inline-Verweise anderer Aussagen und die §5.6-Linkform bleiben unverändert; der Beleg wird bei der Aussage neu/nachgeführt (§5.5). **Textgenauigkeits-Rahmen (Präzisieren):** Schärfen = Formulierung/Abgrenzung **an der Aussage selbst**; **kein Satz-Umbau** (keine Neustrukturierung des Absatzes), **kein Neuschreiben ohne Ersetzungsbeleg** — jede ersetzte Formulierung braucht die neue/fortgeführte `raw/`-Evidenz als Inline-Verweis.
|
||||||
|
- **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.
|
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.
|
||||||
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
|
||||||
@@ -256,10 +281,24 @@ Diese Sektion ist der **einzige Instruktions-Ort** der Update-Mutationsmechanik
|
|||||||
```
|
```
|
||||||
(erste Zeile: modifizierte/gelöschte Pfade gegen die Baseline; zweite Zeile: zusätzlich ungetrackte neue Pfade `??` und staged-Änderungen — die Duplikat-Kontrolle „keine neue Datei" braucht die `??`-Sicht, die `git diff` allein nicht liefert; `<Baseline-Commit>` siehe Pkt. 6 R-1)
|
(erste Zeile: modifizierte/gelöschte Pfade gegen die Baseline; zweite Zeile: zusätzlich ungetrackte neue Pfade `??` und staged-Änderungen — die Duplikat-Kontrolle „keine neue Datei" braucht die `??`-Sicht, die `git diff` allein nicht liefert; `<Baseline-Commit>` siehe Pkt. 6 R-1)
|
||||||
dass die geänderten Dateien eine Teilmenge von **(Kandidatenliste ∪ Neu-Anlage-Zielpfade ∪ `log.md` ∪ nachgeführte `index.md`)** — mit der Kandidatenliste aus §3 Pkt. 2 (betroffene *bestehende* Concepts, relative OKF-Pfade ohne `.md`) **plus** den Zielpfaden aller im selben Run neu angelegten Concepts (§5.1/§5.7 — Misch-Runs) plus `log.md` und jede nachgeführte `index.md` als zusätzliche zulässige Einträge. **Probe-Zeitpunkt (D-1-Präzisierung):** die Probe läuft **vor dem Commit**, am Ende des P2-Check-Blocks (Pkt. 6) — nach dem Commit wäre `git diff` leer und die Probe vacuous (Commit-Boundary = Mutations-Boundary, AD-17f: der Run committiert erst, nachdem die Probe ohne Ghost-Diff abgeschlossen ist). **Pfad-Normalisierung vor dem Teilmenge-Vergleich:** die Proben-Ausgabe trägt `wiki/`-Präfix und `.md`-Endung; die Kandidaten-/Ziel-Pfade sind definiert als relative OKF-Pfade *ohne* `.md` — für den Vergleich werden von jedem Proben-Eintrag `wiki/`-Präfix und `.md`-Suffix gestrippt (deterministischer Normalisierungsschritt). Jede Abweichung (**Ghost-Diff** auf einem nicht betroffenen Pfad) ist ein Instruktions-Verstoß (FT-6): Der Producer behebt sie textuell benannt (NFR-4) und **rollt den Ghost-Diff zurück, bevor der Run als gültig vermerkt wird** — der beobachtbare Endzustand des Bundles bleibt damit konsistent (AD-6-Backstop). **Rollback-Mechanik:** der Ghost-Diff betrifft nur Pfade *außerhalb* der erlaubten Menge; der Producer stellt die betroffenen Pfade aus dem Baseline-Zustand wieder her (für modifizierte Pfade: `git checkout -- <wiki/pfad>`; für ungetrackte neue Dateien: Datei löschen; für Index-Änderungen: `git checkout -- wiki/index.md` bzw. die Area-`index.md`) — der Teilzustand-Rollback des §5.3 Pkt. 3 / §6 Pkt. 3 greift daneben unverändert. Für Story 3.1 selbst (Instruktions-Story ohne Inhalts-Mutation) ist der Nachweis: `git diff --name-only -- wiki/` liefert ausschließlich `wiki/log.md` — keine Concept-Datei, keine `index.md` (die aggressive `git diff --stat -- wiki/`-Default-Effektiv-ausgabe zeigt denselben Pfad, `wiki/log.md | 1 +`). *(Anmerkung: `schema/compiler.md` und `deferred-work.md` liegen **außerhalb** `wiki/` und sind daher kein Teil dieser Diff-Probe — sie gehören zum Instruktions-, nicht zum Bundle-Baum; der Ghost-Diff-Begriff dieser Sektion gilt nur für `wiki/`.)*
|
dass die geänderten Dateien eine Teilmenge von **(Kandidatenliste ∪ Neu-Anlage-Zielpfade ∪ `log.md` ∪ nachgeführte `index.md`)** — mit der Kandidatenliste aus §3 Pkt. 2 (betroffene *bestehende* Concepts, relative OKF-Pfade ohne `.md`) **plus** den Zielpfaden aller im selben Run neu angelegten Concepts (§5.1/§5.7 — Misch-Runs) plus `log.md` und jede nachgeführte `index.md` als zusätzliche zulässige Einträge. **Probe-Zeitpunkt (D-1-Präzisierung):** die Probe läuft **vor dem Commit**, am Ende des P2-Check-Blocks (Pkt. 6) — nach dem Commit wäre `git diff` leer und die Probe vacuous (Commit-Boundary = Mutations-Boundary, AD-17f: der Run committiert erst, nachdem die Probe ohne Ghost-Diff abgeschlossen ist). **Pfad-Normalisierung vor dem Teilmenge-Vergleich:** die Proben-Ausgabe trägt `wiki/`-Präfix und `.md`-Endung; die Kandidaten-/Ziel-Pfade sind definiert als relative OKF-Pfade *ohne* `.md` — für den Vergleich werden von jedem Proben-Eintrag `wiki/`-Präfix und `.md`-Suffix gestrippt (deterministischer Normalisierungsschritt). Jede Abweichung (**Ghost-Diff** auf einem nicht betroffenen Pfad) ist ein Instruktions-Verstoß (FT-6): Der Producer behebt sie textuell benannt (NFR-4) und **rollt den Ghost-Diff zurück, bevor der Run als gültig vermerkt wird** — der beobachtbare Endzustand des Bundles bleibt damit konsistent (AD-6-Backstop). **Rollback-Mechanik:** der Ghost-Diff betrifft nur Pfade *außerhalb* der erlaubten Menge; der Producer stellt die betroffenen Pfade aus dem Baseline-Zustand wieder her (für modifizierte Pfade: `git checkout -- <wiki/pfad>`; für ungetrackte neue Dateien: Datei löschen; für Index-Änderungen: `git checkout -- wiki/index.md` bzw. die Area-`index.md`) — der Teilzustand-Rollback des §5.3 Pkt. 3 / §6 Pkt. 3 greift daneben unverändert. Für Story 3.1 selbst (Instruktions-Story ohne Inhalts-Mutation) ist der Nachweis: `git diff --name-only -- wiki/` liefert ausschließlich `wiki/log.md` — keine Concept-Datei, keine `index.md` (die aggressive `git diff --stat -- wiki/`-Default-Effektiv-ausgabe zeigt denselben Pfad, `wiki/log.md | 1 +`). *(Anmerkung: `schema/compiler.md` und `deferred-work.md` liegen **außerhalb** `wiki/` und sind daher kein Teil dieser Diff-Probe — sie gehören zum Instruktions-, nicht zum Bundle-Baum; der Ghost-Diff-Begriff dieser Sektion gilt nur für `wiki/`.)*
|
||||||
|
Die Probe verifiziert dabei **zwei Ebenen** (Struktur-Erhaltungs-Bezug, Story 3.3): **(1) die Pfad-Mengen-Ebene** (obiger Teilmenge-Vergleich — welche Pfade der Run berührt hat) und **(2) die Struktur-Ebene je berührtem Pfad** — die Struktur-Erhaltung „ohne die Struktur zu zerstören" (FR-6/AC-2) wird pro betroffenem Concept-Pfad über die Pkt.-2-Regeln geprüft (Frontmatter-Subset-Konformität: nur `sources`-Zuwachs um echte neue Belege + `generated.at`-Bump, kein neuer Key, keine Entfernung ohne Beleg; bestehende belegte Aussagen nicht umgeschrieben ohne dass Präzisieren/Korrigieren greift; §5.5-Inline-Verweise weiterhin gültig soweit Beleg Body-Bestand; §5.6-Linkform unverändert, keine neuen Links außer bei echten Beziehungen — Verstöße sind textuell zu benennen (NFR-4) und werden vor dem Commit behoben, sonst gilt der Pfad als Ghost-Diff mit Rollback gemäß dieser Pkt.-5-Konsequenz).
|
||||||
6. **Run-Vorphase-Bausteine (Defer R-1 + P2, in den Update-Pfad eingearbeitet):** Beide sind **keine** neuen Prozesse — wiederverwendbare, reproduzierbare textuelle Check-Blöcke innerhalb der Instruktions-Ausführung (D-3):
|
6. **Run-Vorphase-Bausteine (Defer R-1 + P2, in den Update-Pfad eingearbeitet):** Beide sind **keine** neuen Prozesse — wiederverwendbare, reproduzierbare textuelle Check-Blöcke innerhalb der Instruktions-Ausführung (D-3):
|
||||||
- **Change-Detection (Defer R-1, Input-Zuwachserkennung):** Vor der Interpretation bestimmt der Producer, **welche `raw/`-Dateien Zuwachs** sind (neu/modifiziert). Deterministische Mittel: `git diff --name-only <Baseline-Commit> -- raw/` auf das `raw/`-Verzeichnis und/oder der **SHA-256-Record aus `raw/**/source.md`** (Provenienz-Sidecar, §1 Pkt. 4). Als `<Baseline-Commit>` dient der **letzte committete Zustand des Workspace** (deterministisch: der HEAD der vorherigen Mutations-Boundary, AD-17f). **Auflösungs-Regel (D-2-Präzisierung, Review-Loop 2):** der Producer **notiert den `<Baseline-Commit>` (vollen SHA) im `wiki/log.md`-Eintrag des Runs** — damit ist er deterministisch auflösbar ohne Domain-State-Annahme an Git (AD-14: Git liefert Historie, nicht Domain-State; der log.md-Eintrag ist der State-Referenz-Punkt, keine Git-Historie-Interpretation). **Diskrepanz-Regel:** widersprechen sich `git diff`-Befund und SHA-256-Record für dieselbe Datei, **gewinnt der `git diff`-Befund** (Commit-Boundary = Mutations-Boundary, AD-17f); der SHA-256-Record bleibt Sekundär-Fingerprint. Ist der SHA-256-Record unlesbar/fehlend, wird die Datei dennoch als Zuwachs **nicht doppelt** verarbeitet (textueller Hinweis) und gegen den `git diff`-Befund abgeglichen (kein Doppel-Verdikt). **Fallback:** existiert keine vorherige Mutations-Boundary (frischer Workspace ohne Lauf-Historie), gilt **alle `raw/`-Dateien als Zuwachs**. Die Diff-Probe in Pkt. 5 läuft gegen **dasselbe** `<Baseline-Commit>` (Review-Loop-2-Korrektur des Rev-2.4.1-Claims: die Pkt.-5-Probe trägt das Baseline-Commit-Argument explizit).
|
- **Change-Detection (Defer R-1, Input-Zuwachserkennung):** Vor der Interpretation bestimmt der Producer, **welche `raw/`-Dateien Zuwachs** sind (neu/modifiziert). Deterministische Mittel: `git diff --name-only <Baseline-Commit> -- raw/` auf das `raw/`-Verzeichnis und/oder der **SHA-256-Record aus `raw/**/source.md`** (Provenienz-Sidecar, §1 Pkt. 4). Als `<Baseline-Commit>` dient der **letzte committete Zustand des Workspace** (deterministisch: der HEAD der vorherigen Mutations-Boundary, AD-17f). **Auflösungs-Regel (D-2-Präzisierung, Review-Loop 2):** der Producer **notiert den `<Baseline-Commit>` (vollen SHA) im `wiki/log.md`-Eintrag des Runs** — damit ist er deterministisch auflösbar ohne Domain-State-Annahme an Git (AD-14: Git liefert Historie, nicht Domain-State; der log.md-Eintrag ist der State-Referenz-Punkt, keine Git-Historie-Interpretation). **Diskrepanz-Regel:** widersprechen sich `git diff`-Befund und SHA-256-Record für dieselbe Datei, **gewinnt der `git diff`-Befund** (Commit-Boundary = Mutations-Boundary, AD-17f); der SHA-256-Record bleibt Sekundär-Fingerprint. Ist der SHA-256-Record unlesbar/fehlend, wird die Datei dennoch als Zuwachs **nicht doppelt** verarbeitet (textueller Hinweis) und gegen den `git diff`-Befund abgeglichen (kein Doppel-Verdikt). **Fallback:** existiert keine vorherige Mutations-Boundary (frischer Workspace ohne Lauf-Historie), gilt **alle `raw/`-Dateien als Zuwachs**. Die Diff-Probe in Pkt. 5 läuft gegen **dasselbe** `<Baseline-Commit>` (Review-Loop-2-Korrektur des Rev-2.4.1-Claims: die Pkt.-5-Probe trägt das Baseline-Commit-Argument explizit).
|
||||||
- **Pre-Run-Reconcile-Check-Block (Defer P2):** Vor jeder Mutation durchläuft der Producer den gebündelten Vorprüf-Block und hält ihn textuell fest: (1) **Input-Zustand** (AD-17a, I/O-Matrix `INPUT_UNCOMMITTED`; Review-Loop-2-D-3): Working-Copy von `raw/` und `wiki/` gegen HEAD prüfen — bei Abweichung (uncommitteder Zustand) bricht der Run mit dem **textuell benannten Abbruch „published/committed Input erforderlich"** ab, **vor** Interpretation und vor jeder Mutation (keine Mutation gegen Zwischenstände); (2) Ziel-Pfade (Ausgangs-Kandidatenliste, §3 Pkt. 2); (3) Quellen-Existenz (EC-1 via Validator-Punkt: jede referenzierte `raw/`-Datei existiert als Datei); (4) Betroffenheits-Kandidatenliste (§3 Pkt. 2, textuell-deterministisch); (5) `wiki/index.md`-V-1-Vorbedingung (fehlende Bundleroot → Run-FAIL, §3 Pkt. 3, Vertrag §2). Dieser Block ist der in `deferred-work.md` als P2 notierte Pre-Plan-Schritt und wird durch Story 3.1 als Teil des inkrementellen Runs ausgeführt. **Zeitpunkt (Review-Loop-2-Präzisierung):** der Block wird **nach Reconcile (2) und vor Mutieren (4)**, am **Anfang der Mutationsphase**, einmal pro Run durchgeführt — die Kandidatenliste (Elemente 2/4) existiert zu diesem Zeitpunkt bereits; die **Diff-Probe (Pkt. 5) läuft am Ende desselben Blocks, nach den Mutationen, vor dem Commit**. Die Kandidatenliste, die hier festgehalten wird, ist **die** Kandidatenliste, gegen die der Diff-Selbsttest (Pkt. 5) prüft (keine zweite, davon abweichende Erhebung nach der Mutation).
|
- **Pre-Run-Reconcile-Check-Block (Defer P2):** Vor jeder Mutation durchläuft der Producer den gebündelten Vorprüf-Block und hält ihn textuell fest: (1) **Input-Zustand** (AD-17a, I/O-Matrix `INPUT_UNCOMMITTED`; Review-Loop-2-D-3): Working-Copy von `raw/` und `wiki/` gegen HEAD prüfen — bei Abweichung (uncommitteder Zustand) bricht der Run mit dem **textuell benannten Abbruch „published/committed Input erforderlich"** ab, **vor** Interpretation und vor jeder Mutation (keine Mutation gegen Zwischenstände); (2) Ziel-Pfade (Ausgangs-Kandidatenliste, §3 Pkt. 2); (3) Quellen-Existenz (EC-1 via Validator-Punkt: jede referenzierte `raw/`-Datei existiert als Datei); (4) Betroffenheits-Kandidatenliste (§3 Pkt. 2, textuell-deterministisch); (5) `wiki/index.md`-V-1-Vorbedingung (fehlende Bundleroot → Run-FAIL, §3 Pkt. 3, Vertrag §2); (6) **Struktur-Erhaltungs-Check (Story-3.3-Ergänzung als zusätzliches textuelles Element):** vor dem Commit prüft der Producer an den betroffenen Concept-Pfaden, dass keinerlei unbefugte Keys im Frontmatter entstanden sind (Vertrag §3.3/§3.4-Subset, §6.5-Kriterium-1), **keine stille Löschung** bestehender belegter Aussagen/Provenienz erfolgt ist (AD-16, Pkt. 2 „Korrigieren"-Form) und **keine Links** verändert oder ohne echte Beziehung neu gesetzt wurden (§5.6-Pin, Pkt. 3); Verstöße sind textuell benannt (NFR-4) und vor dem Commit zu beheben; die Kandidatenliste bleibt **die** Liste gegen die der Diff-Selbsttest (Pkt. 5) prüft (keine zweite Erhebung nach der Mutation). Dieser Block ist der in `deferred-work.md` als P2 notierte Pre-Plan-Schritt und wird durch Story 3.1 als Teil des inkrementellen Runs ausgeführt. **Zeitpunkt (Review-Loop-2-Präzisierung):** der Block wird **nach Reconcile (2) und vor Mutieren (4)**, am **Anfang der Mutationsphase**, einmal pro Run durchgeführt — die Kandidatenliste (Elemente 2/4) existiert zu diesem Zeitpunkt bereits; die **Diff-Probe (Pkt. 5) läuft am Ende desselben Blocks, nach den Mutationen, vor dem Commit**.
|
||||||
7. **Worked Example (an die reale Ist-Lage gebunden, re-executiert; Review-Loop-2-Korrektur):** Ein Run mit neuer committeter Evidenz `raw/epics/epics-2026-08-14.md#FR-12` (Zuwachs über die bisher verarbeitete Stelle hinaus; die Kennung FR-12 existiert real in der Datei) trifft über `rg -l 'FR-12' wiki/` das bestehende Root-Concept `wiki/knowledge-kompilation-inkrementell.md` (Term-/Konzept-Überschneidung — re-executierter Befund: der Grep-Ausgabe-Pfad ist `knowledge-kompilation-inkrementell`; das Rev-2.4.1-Beispiel `wissensarchitektur/source-material.md` enthielt den Term **nicht** und ist damit korrigiert). Der Run aktualisiert diesen Pfad (Body-Erweiterung mit neuem §5.5-Inline-Beleg `(raw/epics/epics-2026-08-14.md#FR-12)`, `sources`-Ergänzung um diesen `resource` — sofern nicht bereits deklariert, sonst No-Op gemäß Pkt. 2, `generated.at` = aktueller Run-Zeitstempel, `log.md`-Eintrag „Story 3.1-Update"). Die Diff-Probe (Pkt. 5, `<Baseline-Commit>`-Form) zeigt ausschließlich `log` und `knowledge-kompilation-inkrementell` (betroffen, normalisiert) — kein Ghost-Diff, keine `index.md` im Diff (der Index-Link bleibt unverändert).
|
7. **Worked Example (an die reale Ist-Lage gebunden, re-executiert; Review-Loop-2-Korrektur):** Ein Run mit neuer committeter Evidenz `raw/epics/epics-2026-08-14.md#FR-12` (Zuwachs über die bisher verarbeitete Stelle hinaus; die Kennung FR-12 existiert real in der Datei) trifft über `rg -l 'FR-12' -g '!log.md' wiki/` das bestehende Root-Concept `wiki/knowledge-kompilation-inkrementell.md` (Term-/Konzept-Überschneidung — re-executierter Befund: der Grep-Ausgabe-Pfad ist `knowledge-kompilation-inkrementell`, `wiki/log.md` exkludiert gemäß §3.2-Pkt.-2a; das Rev-2.4.1-Beispiel `wissensarchitektur/source-material.md` enthielt den Term **nicht** und ist damit korrigiert). Der Run aktualisiert diesen Pfad (Body-Erweiterung mit neuem §5.5-Inline-Beleg `(raw/epics/epics-2026-08-14.md#FR-12)`, `sources`-Ergänzung um diesen `resource` — sofern nicht bereits deklariert, sonst No-Op gemäß Pkt. 2, `generated.at` = aktueller Run-Zeitstempel, `log.md`-Eintrag „Story 3.1-Update"). Die Diff-Probe (Pkt. 5, `<Baseline-Commit>`-Form) zeigt ausschließlich `log` und `knowledge-kompilation-inkrementell` (betroffen, normalisiert) — kein Ghost-Diff, keine `index.md` im Diff (der Index-Link bleibt unverändert).
|
||||||
|
|
||||||
|
## 5.10 Synthese aus mehreren Sources (Story 3.4)
|
||||||
|
|
||||||
|
Diese Sektion ist der **Instruktions-Ort der Synthese-Dimension** (AD-4, FR-7): wie der Producer mehrere `raw/`-Quellen desselben Themas zu **einer** gemeinsamen Wissensrepräsentation mit **gemischter, claim-granularer Provenienz** zusammenführt — statt getrennter Zusammenfassungen je Quelle (FR-7). Sie ist eine weitere Spezifikations-Ebene der Mutationsphase §5 (nach §5.9, vor §6), geschlossen auf dem §7-Vorbehalt (Story 3.4). Sie fügt **kein** Prädikat, **keine** neue §7-Invaliditätsklasse, **keinen** `schema/wiki-compiler.md`-/`schema/validator.md`-/`raw/`-Change hinzu (AD-3) und **keinen** Standalone (D-3). Synthese ist eine **Querschnitt-Dimension, keine fünfte Update-Form**: die §5.9-Abgrenzungs-Reihenfolge `Korrigieren → Präzisieren → Erweitern → No-Op` bleibt die **einzige** Form-Wahl (§5.9 Pkt. 2); Synthese erweitert die Ausführung um gemischte Provenienz + Konsolidierung (bei Update auf ein bestehendes Concept) bzw. um die Neu-Anlage mit Multi-Source-`sources` (bei neuer Einheit). Eine Synthese ist ein Compilation-Vorgang wie die Anlage/das Update: sie unterliegt denselben Phasen (§0: Interpretieren → Reconcile → Synthetisieren → Mutieren → Validieren), derselben Commit-Boundary = Mutations-Boundary (AD-17f, §0/§5.3) und derselben Validator-Erfolgsbedingung (§6).
|
||||||
|
|
||||||
|
1. **Synthese-Stimulus (Input der Synthese-Dimension):** Der Stimulus ist eine **Synthese-Einheit**: mindestens **zwei belegende `raw/`-Quellen** (§2-Interpretation) zum **selben Thema** (dieselbe erkannte Wissenseinheit, dieselbe Semantik — gemessen über Term-/Konzept-Überschneidung nach §3.2 bzw. die §2-Pkt.-2-Mehrquellen-Regel: eine Wissenseinheit kann aus mehreren Abschnitten/Dokumenten stammen). Deterministische Erkennung: die neue committete Evidenz (§1 Pkt. 1, AD-17a) enthält ≥ 2 `raw/`-Dateien, deren abgegrenzte Einheiten auf **dieselbe** Zielrepräsentation auflösen. Eine einzelne Quelle bleibt auf dem §5.9-/§3.2-Pfad (Anlage mit `sources`-Zuwachs bzw. Update) — **keine** Synthese-Dimension. Der Stimulus verarbeitet ausschließlich **published/committed** Input (R-1-Change-Detection, §5.9 Pkt. 6).
|
||||||
|
2. **Ein-Ziel-Repräsentation (gemeinsame Wissensrepräsentation, FR-7 AC-1):** Mehrere Quellen zum selben Thema erzeugen **ein einziges** Synthese-Concept über **einen** Ziel-Pfad (§5.7-Routing; bei neuem Thema über §5.1/§5.7-Neu-Anlage, bei bestehendem Pfad über das §5.9-Update). **Getrennte Zusammenfassungs-Concepts je Quelle sind verboten** (FR-7) — es entsteht nie eine per-Source-Concept-Menge. Die `sources`-Liste des Synthese-Concepts trägt **≥ 2 Einträge** (je belegende Quelle ein Eintrag), **deterministisch lexikografisch nach `resource` sortiert (LC_ALL=C)** — unabhängig von Verarbeitungs- oder Datei-Reihenfolge (AD-17h/A0-19; konsistent zur §3.2-Pkt.-3b-Lexikografie-Ordnung und zur §5.9-Tie-Break-Logik). Bei Update auf ein bestehendes Concept wächst `sources` um die zweite/weitere Quelle (Frontmatter-Regel §5.9 Pkt. 2 „`sources` nur um echte neue Belege ergänzen"; bestehende Einträge bleiben unverändert).
|
||||||
|
3. **Gemischte claim-granulare Provenienz (AD-4a/4b, A0-3):** Jede belegte Aussage des Synthese-Concepts bleibt auf `raw/` zurückführbar — der Body trägt **je Aussage einen Inline-`raw/`-Verweis in §5.5-Form** (`(raw/<datei.md>#<stellen-kennung>)` bzw. Komma-Form; voller Pfad je Beleg). **Konsolidierung ohne Provenienz-Verlust (FR-7 AC-3, AD-4):** redundante Informationen aus mehreren Quellen — dieselbe Aussage, von mehreren Quellen unabhängig belegt — werden zu **einer** Aussage konsolidiert, die **alle** betroffenen Belege trägt (**Multi-Beleg**, §5.5-Pkt.-1-Semikolon-Form: `(raw/a.md#X; raw/b.md#Y)` — voller Pfad je Beleg). **Keine stille Beleg-Tilgung** (AD-4): eine konsolidierte Aussage listet jeden ursprünglichen Beleg. **AD-16-Default:** widersprüchliche Aussagen (diskrepanter Inhalt) werden **nicht** still zu scheinbar eindeutigen Aussagen zusammengeführt, sondern bleiben Bestand und werden als Disagreement in `log.md` explizit abgelegt (Pkt. 7; Epic-4-Interface, Story 4.1 — keine Korrektur-Klassifikation hier vorweggenommen; Sandbox-Szenario N2 demonstriert beide Behauptungen + Disagreement-Eintrag). **Body-Reihenfolge deterministisch (AD-17h/A0-19):** die Positionierung der konsolidierten Aussagen im Body folgt der **lexikografischen Ordnung (LC_ALL=C) ihrer Beleg-Anker** (`raw/<datei.md>#<stellen-kennung>`, voller Pfad), nicht einer Verarbeitungs- oder Datei-Reihenfolge — gleicher Git-State + gleiche Eingabemenge ⇒ identische Aussagen-Reihenfolge. Das Konsolidierungs-Erkennungs-Kriterium („dieselbe Aussage") ist die sachlich äquivalente inhaltliche Formulierung über **dieselbe erkannte Wissenseinheit** (Befund-Äquivalenz, nicht Wort-Identität; abgegrenzt über §2-Interpretation/dieselbe Semantik) — sie ist pro Befund eindeutig aus dem Quell-Text der Einheit begründbar.
|
||||||
|
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.
|
||||||
|
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):** 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; Story 3.8/Epic-4 können die Reconcile-Orphan-Politik präzisieren.
|
||||||
|
|
||||||
## 6. Validieren (mechanische Bestätigung)
|
## 6. Validieren (mechanische Bestätigung)
|
||||||
|
|
||||||
@@ -308,15 +347,15 @@ Interpretations-Hinweis: Die „✗"-Zeilen zeigen die deterministische Fehlerur
|
|||||||
|
|
||||||
## 7. Selbstbegrenzung (Scope der Instruktion)
|
## 7. Selbstbegrenzung (Scope der Instruktion)
|
||||||
|
|
||||||
Diese Instruktion ist auf die **Erzeugung neuer Concepts auf Root-Ebene und in Areas gemäß §5.7 sowie das inkrementelle Update bestehender Concepts gemäß §3 + §5.9** begrenzt. Folgendes verbleibt in anderen Stories und wird hier **nicht** vorweggenommen:
|
Diese Instruktion ist auf die **Erzeugung neuer Concepts auf Root-Ebene und in Areas gemäß §5.7, das inkrementelle Update bestehender Concepts gemäß §3 + §5.9 sowie die Synthese mehrerer `raw/`-Quellen zu einer gemeinsamen Wissensrepräsentation gemäß §5.10** begrenzt. Folgendes verbleibt in anderen Stories und wird hier **nicht** vorweggenommen:
|
||||||
|
|
||||||
- **Claim-granulare Provenienz** je belegter Aussage (Inline-`raw/`-Verweise, Kontext-Marker) — in **§5.5** dieser Instruktion verankert (Story 2.2; AD-4a, A0-3). Keine neue §7-Klasse, kein Standalone, keine Vertragsänderung.
|
- **Claim-granulare Provenienz** je belegter Aussage (Inline-`raw/`-Verweise, Kontext-Marker) — in **§5.5** dieser Instruktion verankert (Story 2.2; AD-4a, A0-3). Keine neue §7-Klasse, kein Standalone, keine Vertragsänderung.
|
||||||
- **Deterministische Area-Zuordnung & Concept-Hierarchie** (Anlage von `wiki/<area>/index.md` + `wiki/<area>/<concept>.md`) — in **§5.7** dieser Instruktion verankert (Story 2.4; AD-7c, A0-10, A0-8, AD-13). Keine neue §7-Klasse, kein Validator-Change.
|
- **Deterministische Area-Zuordnung & Concept-Hierarchie** (Anlage von `wiki/<area>/index.md` + `wiki/<area>/<concept>.md`) — in **§5.7** dieser Instruktion verankert (Story 2.4; AD-7c, A0-10, A0-8, AD-13). Keine neue §7-Klasse, kein Validator-Change.
|
||||||
- **Progressive Discovery über `index.md`** (Navigation, Area-Indizes) — in **§5.8** dieser Instruktion verankert (Story 2.5; AD-9, FR-11, AD-13, NFR-3). **Suche** bleibt konsumenten-/extern-seitig (Consumer-grep über `wiki/`, §5.8 Pkt. 4 — kein Bundle-/Instruktions-Thema mehr). Keine neue §7-Klasse, kein Schema-/Validator-Change.
|
- **Progressive Discovery über `index.md`** (Navigation, Area-Indizes) — in **§5.8** dieser Instruktion verankert (Story 2.5; AD-9, FR-11, AD-13, NFR-3). **Suche** bleibt konsumenten-/extern-seitig (Consumer-grep über `wiki/`, §5.8 Pkt. 4 — kein Bundle-/Instruktions-Thema mehr). Keine neue §7-Klasse, kein Schema-/Validator-Change.
|
||||||
- **Eine genau-eine-Linkform** (file-relativ mit `.md`-Endung, in Areas `../`-fähig) — in **§5.6** dieser Instruktion gepinnt (Story 2.3; AD-7b, A0-9, FR-10; Auflösungsmodell §5.7 Pkt. 4) — der Punkt-11-Check des Validators akzeptiert bis auf Weiteres beide Schreibweisen (strukturell unverändert, Story-2.2-Präzedenz).
|
- **Eine genau-eine-Linkform** (file-relativ mit `.md`-Endung, in Areas `../`-fähig) — in **§5.6** dieser Instruktion gepinnt (Story 2.3; AD-7b, A0-9, FR-10; Auflösungsmodell §5.7 Pkt. 4) — der Punkt-11-Check des Validators akzeptiert bis auf Weiteres beide Schreibweisen (strukturell unverändert, Story-2.2-Präzedenz).
|
||||||
- **Synthese über mehrere Concepts** (mehrere Sources → eine gemeinsame Wissensrepräsentation mit gemischter, claim-granularer Provenienz) → **Epic 3, Story 3.4** (AD-4, FR-7). Die Verankerung des inkrementellen Datenflusses (Erweitern/Präzisieren/Korrigieren einzelner bestehender Concepts) bleibt **§3 + §5.9** überlassen und ist dort bereits verankert (Story 3.1) — sie ist damit aus diesem Vorbehalt entlassen.
|
- **Synthese über mehrere Sources** (mehrere `raw/`-Quellen → eine gemeinsame Wissensrepräsentation mit gemischter, claim-granularer Provenienz) — **in §5.10** dieser Instruktion verankert (Story 3.4; AD-4, FR-7). Die Verankerung des inkrementellen Datenflusses (Erweitern/Präzisieren/Korrigieren einzelner bestehender Concepts) bleibt **§3 + §5.9** überlassen und ist dort bereits verankert (Story 3.1). Beide sind damit aus diesem Vorbehalt entlassen.
|
||||||
- **Leasing / Dirty-Tree-Schutz** für konkurrierende Producer → **Story 3.5/3.6** (AD-17a..f, A0-12..A0-16); die bestehende Commit-Boundary = Mutations-Boundary-Regel (§0/§5.3, AD-17f) bleibt in v1 bestehender Schutz.
|
- **Leasing / Dirty-Tree-Schutz** für konkurrierende Producer → **Story 3.5/3.6** (AD-17a..f, A0-12..A0-16); die bestehende Commit-Boundary = Mutations-Boundary-Regel (§0/§5.3, AD-17f) bleibt in v1 bestehender Schutz.
|
||||||
- **Feinkörnige Relevanz-Verfeinerung** (eigene Ausformulierung des Relevanz-Findungsmechanismus) → **Story 3.2**; Story 3.1 bindet die Kandidatenerhebung an die in §3 Pkt. 2 genannten textuell-deterministischen Mittel (grep/ripgrep, `index.md`-Traversal, Link-Following; AD-13).
|
- **Relevanzbestimmung** (feinkörniger Relevanz-Findungsmechanismus der Kandidatenerhebung) — in **§3.2** dieser Instruktion verankert (Story 3.2; Term-Ziehverfahren + Kanonisierungs-Resolver `schema/canonical-terms.md`, drei Erhebungs-Stufen grep/ripgrep + `index.md`-Traversal + Link-Following mit besuchter Menge, `log.md`-Exklusion, Candidate-Liste als relative OKF-Pfade ohne `.md`, Determinismus-Vertrag AD-17h/A0-19). Keine neue §7-Klasse, kein Schema-/Validator-Change; die Em-Dash-`—`-Varianten-Lücke ist als Determinismus-Frage an Story 3.8 übergeben.
|
||||||
- **Standalone-Compiler / eigene LLM-Runtime / MCP** → verboten in v1 (D-3, D-4, AD-11).
|
- **Standalone-Compiler / eigene LLM-Runtime / MCP** → verboten in v1 (D-3, D-4, AD-11).
|
||||||
- **OKF-Dialekt / Schema-Erweiterung** → niemals (AD-1a; Vertrag §7 „abschließende Liste").
|
- **OKF-Dialekt / Schema-Erweiterung** → niemals (AD-1a; Vertrag §7 „abschließende Liste").
|
||||||
|
|
||||||
@@ -326,10 +365,10 @@ Diese Instruktion ist auf die **Erzeugung neuer Concepts auf Root-Ebene und in A
|
|||||||
|
|
||||||
- `schema/wiki-compiler.md` — autorisierter Vertrag (Story 1.3): §2 Bundleroot, §3.1–§3.7 Feldsubset & Formate, §5 `log.md`-Typ, §6 Index-Regel/Prädikate, §7 abschließende 14-Punkte-Liste, §8 Normreferenzen.
|
- `schema/wiki-compiler.md` — autorisierter Vertrag (Story 1.3): §2 Bundleroot, §3.1–§3.7 Feldsubset & Formate, §5 `log.md`-Typ, §6 Index-Regel/Prädikate, §7 abschließende 14-Punkte-Liste, §8 Normreferenzen.
|
||||||
- `schema/validator.md` — Prüfgrundlage (Story 1.4, Revision 9): §3 14 Punkte, §4 Normalform (Reihenfolge §4.1, ISO-8601 §4.3), §5 Verdikt, §6 Fachprüfungen (EC-1 Existenz, EC-3 Kalender, EC-11 non-md; Punkt-11-Area-Lesart formalisiert).
|
- `schema/validator.md` — Prüfgrundlage (Story 1.4, Revision 9): §3 14 Punkte, §4 Normalform (Reihenfolge §4.1, ISO-8601 §4.3), §5 Verdikt, §6 Fachprüfungen (EC-1 Existenz, EC-3 Kalender, EC-11 non-md; Punkt-11-Area-Lesart formalisiert).
|
||||||
- Architektur-Spine (raw/`architecture-spine`): AD-2/AD-3 (raw immutable), AD-4a (claim-granulare Provenienz, §5.5), AD-5 (inkrementelle Kompilation), AD-6 (Reason/Mutate-Trennung), AD-7a (Identität = OKF-Pfad ohne `.md`, §5.7), AD-7b (genau eine Linkform gepinnt, §5.6), AD-7c (deterministische Bereichszuordnung, §5.7), AD-7d (Renaming/Redirect-Pflicht — nicht in den ACs, Epic 3), AD-8 (Standard-Markdown-Links = Navigations-/Beziehungsschicht, §5.6), AD-9 (Progressive Discovery, §5.7/§5.8), AD-10 (agent-unabhängige Regeln), AD-11 (keine eigene Runtime), AD-13 (Retrieval gehört zu Consumers / Suche = Consumer-grep / keine Embedding-Bereichszuordnung, §5.7/§5.8), AD-14 (Git liefert Historie, nicht Domain-State), AD-15 (Trust-Metadaten v1), AD-16 (Konflikte werden explizit bewahrt), AD-17a (nur veröffentlichte/committete Inhalte als Input), AD-17f (Commit-Boundary = Mutations-Boundary), AD-17h (Determinismus), D-3 (kein Standalone).
|
- Architektur-Spine (raw/`architecture-spine`): AD-2/AD-3 (raw immutable), AD-4a (claim-granulare Provenienz, §5.5), AD-5 (inkrementelle Kompilation), AD-6 (Reason/Mutate-Trennung), AD-7a (Identität = OKF-Pfad ohne `.md`, §5.7), AD-7b (genau eine Linkform gepinnt, §5.6), AD-7c (deterministische Bereichszuordnung, §5.7), AD-7d (Renaming/Redirect-Pflicht — nicht in den ACs, Epic 3), AD-8 (Standard-Markdown-Links = Navigations-/Beziehungsschicht, §5.6), AD-9 (Progressive Discovery, §5.7/§5.8), AD-10 (agent-unabhängige Regeln), AD-11 (keine eigene Runtime), AD-13 (Retrieval gehört zu Consumers / Suche = Consumer-grep / keine Embedding-Bereichszuordnung, §5.7/§5.8; Relevanzbestimmung textuell-deterministisch, §3.2), AD-14 (Git liefert Historie, nicht Domain-State), AD-15 (Trust-Metadaten v1), AD-16 (Konflikte werden explizit bewahrt), AD-17a (nur veröffentlichte/committete Inhalte als Input), AD-17f (Commit-Boundary = Mutations-Boundary), AD-17h (Determinismus), D-3 (kein Standalone).
|
||||||
- PRD (raw/prd): FR-2 (Sources vs. Curated), FR-5 (Concept-Erzeugung), FR-9 (OKF-Konformität), FR-10 (Concepts miteinander verlinken, §5.6), FR-11 (Progressive Discovery siehe PRD-§4.3-Zeile unten — Discovery-Pfad/gewurzelte Erreichbarkeit, §5.8), FR-16 (Consumer-Unabhängigkeit), NFR-3 (Agent Readability — Standard-Dateioperationen/grep über `wiki/`, §5.8 Pkt. 4), A-4 (nur lokale Sources).
|
- PRD (raw/prd): FR-2 (Sources vs. Curated), FR-5 (Concept-Erzeugung), FR-9 (OKF-Konformität), FR-10 (Concepts miteinander verlinken, §5.6), FR-11 (Progressive Discovery siehe PRD-§4.3-Zeile unten — Discovery-Pfad/gewurzelte Erreichbarkeit, §5.8), FR-16 (Consumer-Unabhängigkeit), NFR-3 (Agent Readability — Standard-Dateioperationen/grep über `wiki/`, §5.8 Pkt. 4), A-4 (nur lokale Sources).
|
||||||
- Epics (raw/epics): Story-2.1-Ziel und -Abgrenzung zu Story 2.2–2.5; A0-3 (Kontext-Marker-Wortlaut, §5.5), A0-8 (Concept-Identität/Normalisierung, §5.7), A0-9 (eine erlaubte Linkform, §5.6), A0-10 (deterministische Bereichszuordnung, §5.7), A0-13 (Lease-Root-Scope); FR-6/FR-12/FR-14, A0-6/A0-7/A0-11/A0-18 (Belege der nachkonformierten Concept-Bodies); **A0-6 (inkrementeller Datenfluss Interpret → Reconcile → Synthesize → Update, §0/§3/§5.9), FR-6 (Aktualisierung statt neuer Dateien, §3/§5.9), FR-12 (unverändertes Wissen bleibt erhalten, §5.9)**.
|
- Epics (raw/epics): Story-2.1-Ziel und -Abgrenzung zu Story 2.2–2.5; A0-3 (Kontext-Marker-Wortlaut, §5.5), A0-8 (Concept-Identität/Normalisierung, §5.7), A0-9 (eine erlaubte Linkform, §5.6), A0-10 (deterministische Bereichszuordnung, §5.7), A0-13 (Lease-Root-Scope); FR-6/FR-12/FR-14, A0-6/A0-7/A0-11/A0-18 (Belege der nachkonformierten Concept-Bodies); **A0-6 (inkrementeller Datenfluss Interpret → Reconcile → Synthesize → Update, §0/§3/§5.9), FR-6 (Aktualisierung statt neuer Dateien, §3/§5.9), FR-12 (unverändertes Wissen bleibt erhalten, §5.9)**, **A0-18 (Deterministische Relevanzbestimmung — grep/ripgrep, `index.md`-Traversal, Link-Following, keine Embedding-/Vector-Infrastruktur; §3.2, AD-13, PRD OQ-3)**, **A0-19 (Determinismus-Vertrag: gleicher Git-State + gleiche Eingabemenge → gleicher Bundle-State / gleiche Candidate-Liste in gleicher Reihenfolge; §3.2, AD-17h)**.
|
||||||
- PRD §4.3 (FR-11 — progressive Discovery, §5.7 Pkt. 5/§5.8) und §8.2/§8.3 (Canonical State; Separation of Concerns).
|
- PRD §4.3 (FR-11 — progressive Discovery, §5.7 Pkt. 5/§5.8) und §8.2/§8.3 (Canonical State; Separation of Concerns), **PRD OQ-3 („Compilation Scope" — wie findet der Compiler relevante vorhandene Concepts; textuell-deterministische Relevanzbestimmung, §3.2; AD-13/A0-18; Muster `raw/architecture-spine/…md` §8.3)**.
|
||||||
|
|
||||||
**Revisionslog:**
|
**Revisionslog:**
|
||||||
|
|
||||||
@@ -349,4 +388,9 @@ Diese Instruktion ist auf die **Erzeugung neuer Concepts auf Root-Ebene und in A
|
|||||||
- **Revision 2.3 (2026-08-18, Story 2.5):** Neue Sektion **§5.8 „Progressive Discovery über `index.md` (Story 2.5)"** eingefügt (nach §5.7, vor §6): (1) **Discovery-Pfad** (Bundleroot `wiki/index.md` → Area-`index.md` frontmatterlos → Area-Concepts in gepinnter §5.6-Form; Root-Concepts direkt aus der Bundleroot — AD-9/FR-11, gewurzelte Erreichbarkeit Root → Area → Concept), (2) **gewurzelte Erreichbarkeit als deterministisches Discovery-Kriterium + re-executierbarer Selbsttest** (`UNREACHABLE AREA: <area>` für unverlinkte Area; `NESTED AREA: <area>` für Zwei-Ebenen-Kandidaten inkl. der Area-ohne-`index.md`-Lücke `wiki/a/b/concept.md`; gekoppelte Meldungen an den Run-Nachweis gemäß §5.6-Pkt.-4-analoger NFR-4-Regel; Instruktions-Selbsttest, **keine** neue §7-Klasse — schließt die Validator-Navigation-Lücke, ohne Validator-Change, AD-3), (3) **konsolidierte Zwei-Ebenen-Kartografie** (respondiert Defer **F-07**, schließt es): Root + eine Area-Ebene; `wiki/a/b/` ist keine zugelassene Anlageform — der Kandidat wird durch den **§5.8-Instruktions-Hold (Zwei-Ebenen, Tiefe ≥ 3)** angehalten (keine Datei, kein Index-Link, Meldung `NESTED AREA: <area>`, Run „teilweise erfolgreich"); §3.2 bleibt der Dateikollision bestehender Concepts vorbehalten (Loopback-1-Renegotiation, Option A); (4) **Suche = Consumer-grep** (`grep -n <term> wiki/` / ripgrep, AD-13 — keine Such-Datenbank, kein Embedding, kein Index-Datei-Format), (5) **Discovery-Demo (optional, kein MOVE)** — Hinweis auf Formel-4-Re-Baseline-Pflicht bei Durchführung. Nachgeführt: **§7** (Story-2.5-Vorbehalt auf „Suche"-Rest gekürzt — Navigation/Area-Indizes jetzt in §5.8 verankert, Suche = Consumer-Thema; die Vorbehalt-Zeile lag in der Baseline `main` bei Z. 253, nach dem §5.8-Einschub bei Z. 285), **§8-Normreferenzen** (AD-9/AD-13 → §5.8, FR-11 → §5.8/§5.7 Pkt. 5, NFR-3 neu, PRD-§4.3-Zeile nachgeführt) + **Revisionslog 2.3**. Keine Änderung an `wiki-compiler.md`/`validator.md`/`raw/` (AD-3); keine neue §7-Klasse; kein Standalone (D-3); keine Vertragsänderung.
|
- **Revision 2.3 (2026-08-18, Story 2.5):** Neue Sektion **§5.8 „Progressive Discovery über `index.md` (Story 2.5)"** eingefügt (nach §5.7, vor §6): (1) **Discovery-Pfad** (Bundleroot `wiki/index.md` → Area-`index.md` frontmatterlos → Area-Concepts in gepinnter §5.6-Form; Root-Concepts direkt aus der Bundleroot — AD-9/FR-11, gewurzelte Erreichbarkeit Root → Area → Concept), (2) **gewurzelte Erreichbarkeit als deterministisches Discovery-Kriterium + re-executierbarer Selbsttest** (`UNREACHABLE AREA: <area>` für unverlinkte Area; `NESTED AREA: <area>` für Zwei-Ebenen-Kandidaten inkl. der Area-ohne-`index.md`-Lücke `wiki/a/b/concept.md`; gekoppelte Meldungen an den Run-Nachweis gemäß §5.6-Pkt.-4-analoger NFR-4-Regel; Instruktions-Selbsttest, **keine** neue §7-Klasse — schließt die Validator-Navigation-Lücke, ohne Validator-Change, AD-3), (3) **konsolidierte Zwei-Ebenen-Kartografie** (respondiert Defer **F-07**, schließt es): Root + eine Area-Ebene; `wiki/a/b/` ist keine zugelassene Anlageform — der Kandidat wird durch den **§5.8-Instruktions-Hold (Zwei-Ebenen, Tiefe ≥ 3)** angehalten (keine Datei, kein Index-Link, Meldung `NESTED AREA: <area>`, Run „teilweise erfolgreich"); §3.2 bleibt der Dateikollision bestehender Concepts vorbehalten (Loopback-1-Renegotiation, Option A); (4) **Suche = Consumer-grep** (`grep -n <term> wiki/` / ripgrep, AD-13 — keine Such-Datenbank, kein Embedding, kein Index-Datei-Format), (5) **Discovery-Demo (optional, kein MOVE)** — Hinweis auf Formel-4-Re-Baseline-Pflicht bei Durchführung. Nachgeführt: **§7** (Story-2.5-Vorbehalt auf „Suche"-Rest gekürzt — Navigation/Area-Indizes jetzt in §5.8 verankert, Suche = Consumer-Thema; die Vorbehalt-Zeile lag in der Baseline `main` bei Z. 253, nach dem §5.8-Einschub bei Z. 285), **§8-Normreferenzen** (AD-9/AD-13 → §5.8, FR-11 → §5.8/§5.7 Pkt. 5, NFR-3 neu, PRD-§4.3-Zeile nachgeführt) + **Revisionslog 2.3**. Keine Änderung an `wiki-compiler.md`/`validator.md`/`raw/` (AD-3); keine neue §7-Klasse; kein Standalone (D-3); keine Vertragsänderung.
|
||||||
- **Revision 2.4 (2026-08-18, Story 3.1):** Neue Sektion **§5.9 „Inkrementelles Update bestehender Concepts (Story 3.1)"** eingefügt (nach §5.8, vor §6) — Update-Stimulus (Reconcile-Kandidatenliste), Mutationsmechanik (Erweitern/Präzisieren/Korrigieren; `sources` nur um echte neue Belege; `generated.at` = aktueller Run-Zeitstempel; `verified` unangetastet), Index-/Link-Form unverändert (§5.6-Pin), `log.md`-Eintragspflicht („Story 3.1-Update"-Markierung; Disagreement-Fälle bleiben dokumentiert, keine Korrektur-Klassifikation hier — Epic-4-Interface), **Erhaltungs-Invariante + deterministischer Diff-Selbsttest** (`git diff --stat -- wiki/` ⊆ betroffene Concepts ∪ `log.md` ∪ Index; Ghost-Diff = textuell benannter Instruktions-Verstoß, FT-6/FR-12), Run-Vorphase-Bausteine (Defer **R-1** Change-Detection via `git diff` auf `raw/` + SHA-256-Record aus `source.md`; Defer **P2** Pre-Run-Reconcile-Check-Block — Zielpfade, EC-1-Existenz, Kandidatenliste, V-1), Worked Example. **§3 Reconcile:** Pkt. 2 Kollision-Hold (bisheriger Epic-3-Abbruch bei bereits existierendem Concept) **ersetzt** durch **Update-Routing** (bestehende Wissenseinheit → Update-Kandidat im bestehenden Pfad; kein Duplikat, kein stummer Überschreib; AD-16-Default-Erhaltung) + **textuell-deterministische Kandidatenliste** (Konzept-/Term-Überschneidung via `grep`/`ripgrep`, `index.md`-Traversal, Link-Following — AD-13; feinkörniger Mechanismus Story 3.2). **§0-Aufruf:** sechs Phasen für Neu-Anlage- und Update-Variante präzisiert; Reconcile/Mutieren betreffen auch bestehende Concepts. **§5.7 Pkt. 3 / §5.8 Pkt. 2/3:** Top-Level-Referenz von „§3.2-Kollisions-Hold" auf das Update-Routing (§3 Pkt. 2, §5.9) nachgeführt (die bisherige Epic-3-Abbruch-Formulierung ist vollständig entfernt). **§7:** Update-Thema aus dem Epic-3-Vorbehalt **entlassen** (verbleibende 3.x-Themen benannt: Synthese → Story 3.4, Leasing/Dirty-Tree → Story 3.5/3.6, Relevanz-Verfeinerung → Story 3.2); Scope-Einleitung um die Update-Variante geöffnet. **§8:** Normreferenzen um A0-6/FR-6/FR-12 ergänzt. **Abschlussklausel:** Keine Änderung an `schema/wiki-compiler.md`/`schema/validator.md`/`raw/` (AD-3); **keine neue §7-Invaliditätsklasse**; **kein Standalone** (D-3); keine Vertragsänderung; Commit-Boundary-Regel unverändert.
|
- **Revision 2.4 (2026-08-18, Story 3.1):** Neue Sektion **§5.9 „Inkrementelles Update bestehender Concepts (Story 3.1)"** eingefügt (nach §5.8, vor §6) — Update-Stimulus (Reconcile-Kandidatenliste), Mutationsmechanik (Erweitern/Präzisieren/Korrigieren; `sources` nur um echte neue Belege; `generated.at` = aktueller Run-Zeitstempel; `verified` unangetastet), Index-/Link-Form unverändert (§5.6-Pin), `log.md`-Eintragspflicht („Story 3.1-Update"-Markierung; Disagreement-Fälle bleiben dokumentiert, keine Korrektur-Klassifikation hier — Epic-4-Interface), **Erhaltungs-Invariante + deterministischer Diff-Selbsttest** (`git diff --stat -- wiki/` ⊆ betroffene Concepts ∪ `log.md` ∪ Index; Ghost-Diff = textuell benannter Instruktions-Verstoß, FT-6/FR-12), Run-Vorphase-Bausteine (Defer **R-1** Change-Detection via `git diff` auf `raw/` + SHA-256-Record aus `source.md`; Defer **P2** Pre-Run-Reconcile-Check-Block — Zielpfade, EC-1-Existenz, Kandidatenliste, V-1), Worked Example. **§3 Reconcile:** Pkt. 2 Kollision-Hold (bisheriger Epic-3-Abbruch bei bereits existierendem Concept) **ersetzt** durch **Update-Routing** (bestehende Wissenseinheit → Update-Kandidat im bestehenden Pfad; kein Duplikat, kein stummer Überschreib; AD-16-Default-Erhaltung) + **textuell-deterministische Kandidatenliste** (Konzept-/Term-Überschneidung via `grep`/`ripgrep`, `index.md`-Traversal, Link-Following — AD-13; feinkörniger Mechanismus Story 3.2). **§0-Aufruf:** sechs Phasen für Neu-Anlage- und Update-Variante präzisiert; Reconcile/Mutieren betreffen auch bestehende Concepts. **§5.7 Pkt. 3 / §5.8 Pkt. 2/3:** Top-Level-Referenz von „§3.2-Kollisions-Hold" auf das Update-Routing (§3 Pkt. 2, §5.9) nachgeführt (die bisherige Epic-3-Abbruch-Formulierung ist vollständig entfernt). **§7:** Update-Thema aus dem Epic-3-Vorbehalt **entlassen** (verbleibende 3.x-Themen benannt: Synthese → Story 3.4, Leasing/Dirty-Tree → Story 3.5/3.6, Relevanz-Verfeinerung → Story 3.2); Scope-Einleitung um die Update-Variante geöffnet. **§8:** Normreferenzen um A0-6/FR-6/FR-12 ergänzt. **Abschlussklausel:** Keine Änderung an `schema/wiki-compiler.md`/`schema/validator.md`/`raw/` (AD-3); **keine neue §7-Invaliditätsklasse**; **kein Standalone** (D-3); keine Vertragsänderung; Commit-Boundary-Regel unverändert.
|
||||||
- **Revision 2.4.1 (2026-08-18, Story 3.1, Step-04-Review-Patch-Runde; D-3-Instruktions-Patch, kein neuer Inhalt):** §5.9-Konsolidierung aus den drei Review-Layern — (1) Prüfgrundlage auf `validator.md` **Revision 9** angehoben (§0-Header, §8-Link), §8-Verlusttext um die Punkt-11-Area-Lesart (Rev-9) ergänzt; (2) §5.9 Pkt. 5 Diff-Selbsttest operationalisiert (Probe `git diff --name-only -- wiki/` statt `--stat`; Ergebnismenge ⊆ **Kandidatenliste** (explizit §3 Pkt. 2) ∪ `log.md` ∪ nachgeführte `index.md`; Rücksetzhilfe „ob der Ghost auf einem Kandidatenpfad liegt"); Klarstellung, dass `schema/compiler.md`/`deferred-work.md` **außerhalb** `wiki/` liegen und daher nicht Teil der Diff-Probe sind — der Story-3.1-Nachweis ist `wiki/log.md` (Differenz zu den 4 volle `git status --porcelain`-Einträgen); Diff-Erwartung für das reine Body-Update in Pkt. 7 auf `git diff --name-only` umgestellt, Ergebnismenge `wiki/log.md` + `wissensarchitektur/source-material.md` (keine `index.md`); (3) §5.9 Pkt. 3-Widerspruch aufgelöst (Index-Regel unverändert, `log.md`-Eintragspflicht bleibt ausgeschlossen — Präzisierung „kein `log.md`-Zusatz" war falsch, korrekt „kein Index-Zusatz"); (4) §5.9 Pkt. 2 um **Mehrfach-Treffer-Konsolidierung** ergänzt (mehrere Einheiten → 1 Update/`log.md`-Eintrag/`at`; Verarbeitungsreihenfolge = Auftreten in der Zuwachs-Sicht); (5) §5.9 Pkt. 1/6-Anker §1.1/§1.4 → **§1 Pkt. 1/Pkt. 4** (die tatsächlichen Label; §5.8-Pkt-2-Formel-Zeile bleibt historisch); (6) Ghost-Diff **Konsequenz** + Commit-Boundary-Umsetzung definiert (Rück-Rollen vor Run-Gültigkeit, `log.md`-Kopplung als Abbruch-Vorlauf „korrigierter Teil-Run"); (7) Defer-**R-1**-Baseline festgelegt (HEAD der vorherigen Mutations-Boundary); (8) §5.9 Pkt. 7-Worked Example auf den **realen Ist-Baum** gehoben (`raw/epics/epics-2026-08-14.md#FR-12`, `rg -l 'FR-12'`; das fiktive `epics-2026-08-18.md`/`payload` entfernt); (9) §5.8-Pkt-3-Revision-Feinschliff — die Rev-9-Lücke ist geschlossen; die Markierung ist Pkt. 3. **Abschlussklausel der Patch-Runde:** Keine Änderung an `schema/wiki-compiler.md`/`schema/validator.md`/`raw/` (AD-3); **keine neue §7-Invaliditätsklasse**; **kein Standalone** (D-3); keine Vertragsänderung; Commit-Boundary-Regel unverändert.
|
- **Revision 2.4.1 (2026-08-18, Story 3.1, Step-04-Review-Patch-Runde; D-3-Instruktions-Patch, kein neuer Inhalt):** §5.9-Konsolidierung aus den drei Review-Layern — (1) Prüfgrundlage auf `validator.md` **Revision 9** angehoben (§0-Header, §8-Link), §8-Verlusttext um die Punkt-11-Area-Lesart (Rev-9) ergänzt; (2) §5.9 Pkt. 5 Diff-Selbsttest operationalisiert (Probe `git diff --name-only -- wiki/` statt `--stat`; Ergebnismenge ⊆ **Kandidatenliste** (explizit §3 Pkt. 2) ∪ `log.md` ∪ nachgeführte `index.md`; Rücksetzhilfe „ob der Ghost auf einem Kandidatenpfad liegt"); Klarstellung, dass `schema/compiler.md`/`deferred-work.md` **außerhalb** `wiki/` liegen und daher nicht Teil der Diff-Probe sind — der Story-3.1-Nachweis ist `wiki/log.md` (Differenz zu den 4 volle `git status --porcelain`-Einträgen); Diff-Erwartung für das reine Body-Update in Pkt. 7 auf `git diff --name-only` umgestellt, Ergebnismenge `wiki/log.md` + `wissensarchitektur/source-material.md` (keine `index.md`); (3) §5.9 Pkt. 3-Widerspruch aufgelöst (Index-Regel unverändert, `log.md`-Eintragspflicht bleibt ausgeschlossen — Präzisierung „kein `log.md`-Zusatz" war falsch, korrekt „kein Index-Zusatz"); (4) §5.9 Pkt. 2 um **Mehrfach-Treffer-Konsolidierung** ergänzt (mehrere Einheiten → 1 Update/`log.md`-Eintrag/`at`; Verarbeitungsreihenfolge = Auftreten in der Zuwachs-Sicht); (5) §5.9 Pkt. 1/6-Anker §1.1/§1.4 → **§1 Pkt. 1/Pkt. 4** (die tatsächlichen Label; §5.8-Pkt-2-Formel-Zeile bleibt historisch); (6) Ghost-Diff **Konsequenz** + Commit-Boundary-Umsetzung definiert (Rück-Rollen vor Run-Gültigkeit, `log.md`-Kopplung als Abbruch-Vorlauf „korrigierter Teil-Run"); (7) Defer-**R-1**-Baseline festgelegt (HEAD der vorherigen Mutations-Boundary); (8) §5.9 Pkt. 7-Worked Example auf den **realen Ist-Baum** gehoben (`raw/epics/epics-2026-08-14.md#FR-12`, `rg -l 'FR-12'`; das fiktive `epics-2026-08-18.md`/`payload` entfernt); (9) §5.8-Pkt-3-Revision-Feinschliff — die Rev-9-Lücke ist geschlossen; die Markierung ist Pkt. 3. **Abschlussklausel der Patch-Runde:** Keine Änderung an `schema/wiki-compiler.md`/`schema/validator.md`/`raw/` (AD-3); **keine neue §7-Invaliditätsklasse**; **kein Standalone** (D-3); keine Vertragsänderung; Commit-Boundary-Regel unverändert.
|
||||||
|
- **Revision 2.6 (2026-08-19, Story 3.2, Step-04-Review Loop 2, Patch-Runde; D-3-Instruktions-Patch, kein neuer Inhalt):** (1) **§4-Überschrift wiederhergestellt** — die §3.2-Einfügung (Rev 2.5) hatte die Überschrift **`## 4. Synthetisieren (Provenienz & Trust)`** verdrängt (der §3.2-Sektionskopf ersetzte die §4-Überschrift; der gesamte Frontmatter-Body hing kopflos unter §3.2; alle §4-Referenzen wären dangling geblieben). Der §4-Kopf ist zwischen §3.2-Body und dem Frontmatter-Body wieder eingefügt; die §4-Referenzen zeigen wieder auf eine existierende Sektion; der §3.2-Body blieb unverändert erhalten. (2) **rg-Flag-Defekt behoben (`--exclude` ist kein rg-Flag):** die Stufe-a-Form in §3-Pkt.-2, §3.2-Pkt.-2a, §5.9-Worked Example (Pkt. 7) und §7 nutzten `rg -l "<term>" --exclude=log.md wiki/` — nicht-existent (ripgrep 14.1.1: `rg --exclude` → `unrecognized flag`; GNU grep unterstützt `--exclude`, ripgrep nutzt `-g "!log.md"` / `--glob "!log.md"`). Die Instruktion nutzt jetzt tool-korrekte Formen: rg `rg -l "<term>" -g "!log.md" wiki/` (native Glob-Exklusion) bzw. GNU grep `grep -rl "<term>" --exclude=log.md wiki/`; die §5.6-Formeln (bereits GNU-grep) und §5.9-Pkt.-7-Erhebung adoptieren die Exklusion. Verified: `rg -l "A0-18" -g "!log.md" wiki/` → nur `wiki/knowledge-kompilation-inkrementell.md`; **ohne** Exklusion trifft `rg -l "A0-18" wiki/` zusätzlich `wiki/log.md` (Selbstkontamination — der ausgeschlossene Fall, §3.2-Pkt.-2a). (3) **§5.9-Worked Example (Pkt. 7) auf die Exklusions-Form gehoben** (`rg -l "FR-12" -g "!log.md" wiki/`), Kommentar `wiki/log.md` exkludiert gemäß §3.2-Pkt.-2a. (4) **Mini-Sandbox re-executierbar verankert** (`_bmad-output/implementation-artifacts/sandbox-3-2/run-sandbox.sh`, Muster Story-3.1-Sandbox S1–S6): Tests T1–T4 (Membership-Pin — Term auf Concept-Bodies UND `log.md` verteilt, Candidate-Liste nur Concept-Pfade; Zwei-Run-Identität AD-17h; NO_MATCH → leere Candidate-Liste → UNTOUCHED_CONCEPT; Mehrfach-Treffer → Vereinigung + lexikografische Ordnung). (5) **`deferred-work.md`-Em-Dash-Eintrag** append-only ergänzt (Home: Story 3.8) — die §3.2-Pkt.-1b-Kollaps-Klasse deckt En-Dash/Bindestrich/Unterstrich/Leerzeichen, aber **nicht** den Em-Dash `—`; dieser Handoff wird nicht stillschweigend gelöst, sondern als offene Determinismus-Frage dokumentiert. (6) **§3-Pkt.-2/§3.2-Präambel/§7-Nennungen** der Exklusion auf die tool-korrekte Form angehoben. **Abschlussklausel:** Keine Änderung an `schema/wiki-compiler.md`/`schema/validator.md`/`raw/` (AD-3); **keine neue §7-Invaliditätsklasse**; **kein Standalone** (D-3); keine Vertragsänderung; Commit-Boundary-Regel unverändert. (Rev-2.5-Log-Eintrag bleibt unverändert — dokumentiert den Zustand bei Veröffentlichung der Revision 2.5, inkl. der damaligen `--exclude`-Form; historische Korrektheit des Logs.)
|
||||||
|
- **Revision 2.5 (2026-08-19, Story 3.2):** Neue Sektion **§3.2 „Relevanzbestimmung (Story 3.2)"** eingefügt (nach §3, vor §4) — die **verbindliche Ausformulierung der §3-Pkt.-2-Kandidatenerhebung** („Erhebung nach §3.2"): (1) **Term-Ziehverfahren** deterministisch (bedeutungstragende Token-Folgen nach §2-Interpretation; Normalisierung lowercasing + `[-–_ ]`→`-`-Kollaps; **kanonischer Schreibweisen-Resolver `schema/canonical-terms.md`** — committete, append-only Registry (canon. Form + erlaubte Varianten), damit Bestandteil des Git-States und deterministisch pinbar; genau eine canon. Form je Semantik A0-18; kein stiller Ausschluss nicht auflösbarer Varianten — Verwendung wie notiert; mehrere Terme je Einheit → Vereinigung), (2) **dreistufige term-übergreifende Erhebung über `wiki/`** — (a) `rg -l '<term>' --exclude=log.md wiki/` (grep-Äquivalent `grep -rl … --exclude=log.md`; `log.md` **strukturell** exkludiert, Candidate-Liste auf Concept-Pfade definiert), (b) `index.md`-Traversal (gewurzelte Erreichbarkeit Root → Area → Concept, §5.8; TRAVERSAL_REACH_ONLY; fehlende Bundleroot → Run-FAIL V-1), (c) Link-Following mit **besuchter Menge** (file-relativ auflösen, §5.7 Pkt. 4; Zyklen enden, LINK_FOLLOWING_ZYKLUS); (3) **Candidate-Liste + Determinismus-Vertrag (AD-17h/A0-19):** relative OKF-Pfade ohne `.md` (Strip `wiki/`-Präfix + `.md`-Suffix), **Zuwachs-Sicht-Ordnung** mit Reihenfolge auch für Stufe-b/c (nach Stufe-a; lexikografisch als deterministischer Tie-Break), keine Duplikate (besuchte Menge), NO_MATCH → leere Candidate-Liste → UNTOUCHED_CONCEPT (Story-3.1-Pfad); Determinismus-Selbsttest (Membership + Zwei-Run-Identität) in Spec-Verification und `wiki/log.md` belegt. **§3 Pkt. 2:** Story-3.2-Vorbehalt **aufgelöst** — Pkt. 2 bleibt Kern-Anker, die Erhebung zeigt auf die neue Sektion („Erhebung nach §3.2"), `rg -l '<term>' --exclude=log.md wiki/` als Stufe-a-Form genannt. **§7:** Story-3.2-Vorbehalt **aufgelöst** (Relevanzbestimmung in §3.2 verankert; verbleibende 3.x-Themen: Synthese → Story 3.4, Leasing/Dirty-Tree → Story 3.5/3.6). **§8:** Normreferenzen um **AD-13** (bereits gelistet, §3.2-angeankert), **A0-18** (Deterministische Relevanzbestimmung, §3.2) und **A0-19** (Determinismus-Vertrag, §3.2 — war im Ist-§8 noch nicht gelistet, wird als Determinismus-Referenz ergänzt) sowie **PRD OQ-3** (Compilation Scope, §3.2) ergänzt; **`schema/canonical-terms.md`** als nebengeordnete committete Resolver-Registry referenziert (kein `schema/`-Root-Change; gleiche read-only-Hierarchie, append-only). Em-Dash-`—`-Varianten-Lücke als offene Determinismus-Frage an **Story 3.8** übergeben (nicht stillschweigend ergänzt). **Abschlussklausel:** Keine Änderung an `schema/wiki-compiler.md`/`schema/validator.md`/`raw/` (AD-3); **keine neue §7-Invaliditätsklasse**; **kein Standalone** (D-3); keine Vertragsänderung; Commit-Boundary-Regel unverändert. **`sprint-status.yaml`:** Key `3-2-relevanzbestimmung-textual-deterministisch-umsetzen-grep-rip` `backlog` → **`in-progress`**. `wiki/log.md`-Eintrag (append-only, bestehende Bullets unverändert), `deferred-work.md`-epic-3-context-Eintrag → aufgegriffen (append-only), Determinismus-Selbsttest + Validator-Lauf (7/7 SUCCESS) siehe `wiki/log.md`-Nachweis.
|
||||||
- **Revision 2.4.2 (2026-08-19, Story 3.1, bmad-code-review Loop 2, 4 Layer; Nutzer-Entscheidungen D-1/D-2/D-3/D-4 = 1/1/1/1):** (1) **Diff-Selbsttest (Pkt. 5) operationalisiert + Blind-Spots geschlossen (D-1):** Probe erweitert auf `git diff --name-only <Baseline-Commit> -- wiki/` **plus** `git status --porcelain -- wiki/` (erfasst ungetrackte neue Dateien `??` — die Duplikat-Kontrolle „keine neue Datei" braucht diese Sicht; `git diff` allein ist blind für Untracked); **Probe-Zeitpunkt fixiert vor dem Commit** (am Ende des P2-Blocks, nach den Mutationen) — nach dem Commit wäre die Probe vacuous (leere Ausgabe, AD-17f); erlaubte Teilmenge-Menge um **Neu-Anlage-Zielpfade** (§5.1/§5.7) ergänzt — Misch-Runs (Neu-Anlage + Update im selben Run) markieren neu angelegte Pfade nicht fälschlich als Ghost-Diff; **Pfad-Normalisierung** definiert (Strip `wiki/`-Präfix + `.md`-Suffix vor dem Teilmenge-Vergleich, da Kandidaten/Ziel-Pfade als relative OKF-Pfade *ohne* `.md` definiert sind); **Rollback-Mechanik** für den Ghost-Diff deterministisch benannt (modifizierte Pfade via `git checkout -- <wiki/pfad>`, ungetrackte neue Dateien gelöscht, Index via `git checkout -- <index>`; §5.3/§6.3-Teilzustand-Rollback greift daneben unverändert). (2) **R-1-Baseline deterministisch + Abweichungsregel (D-2):** `<Baseline-Commit>` (HEAD der vorherigen Mutations-Boundary, AD-17f) wird vom Producer **im `wiki/log.md`-Run-Eintrag notiert** (voller SHA) — deterministisch auflösbar ohne Domain-State-Annahme an Git (AD-14); **Diskrepanz-Regel**: widersprechen `git diff`-Befund und SHA-256-Record derselben Datei, **gewinnt `git diff`** (Commit-Boundary-Prinzip), SHA-256 bleibt Sekundär-Fingerprint; **Fallback**: ohne vorherige Mutations-Boundary gelten alle `raw/`-Dateien als Zuwachs; Rev-2.4.1-Claim „derselbe Baseline-Commit wie Pkt. 5" **korrigiert** (die Pkt.-5-Probe trägt das Baseline-Commit-Argument jetzt explizit). (3) **INPUT_UNCOMMITTED-Abbruch (D-3) + Anker-Divergenz:** neuer P2-Check-Block-Element (1) **Input-Zustand** — Working-Copy von `raw/`/`wiki/` gegen HEAD prüfen, bei Abweichung **benannter Abbruch „published/committed Input erforderlich"** vor Interpretation und vor jeder Mutation (AD-17a, I/O-Matrix-`INPUT_UNCOMMITTED` — zuvor nur Referenz auf §1 Pkt. 1, keine Zustandsprüfung/Abbruchmeldung); die **Spec↔Anker-Divergenz** (frozen Spec zitiert 3× „§1.1", §1 ist eine nummerierte Liste Pkt. 1–4 ohne §1.1-Label; Rev-2.4.1 korrigierte nur die Anker *in* compiler.md) wird hier als dokumentierte Fußnote gesichert — die Spec bleibt frozen (nur per menschlicher Renegotiation änderbar). (4) **Sandbox-Edge-Test-Nachweis (D-4):** die fünf I/O-Matrix-Szenarien (HAPPY_PATH_UPDATE, UNTOUCHED_CONCEPT, CONCEPT_COLLISION_BESTEHEND, CHANGE_DETECTION, PRE_RUN_RECONCILE) + die D-3-Abbruch-Kontrolle sind als re-executierbare Sandbox-Skripte mit **konkreten deterministischen Ausgaben** in der Spec-`## Verification`-Sektion (Sandbox-Beleg) verankert — die `wiki/log.md`- und `deferred-work.md`-Verweise („in der Spec-Verification enthalten") auflösbar. (5) **Instruktions-Präzisierungen:** P2-Block-**Zeitpunkt** (nach Reconcile, am Anfang der Mutationsphase; Diff-Probe am Block-Ende) — löst den Widerspruch „einmal an der Spitze erhoben" vs. „Kandidatenliste entsteht erst im Reconcile"; **No-Op-Kandidat**-Regel (Pkt. 2: Pfad, der die Evidenz bereits vollständig enthält → keine Mutation/kein `at`-Bump/kein `log.md`-Eintrag, byte-identisch — die engere Auslegung); **Mehrfach-Treffer-Reihenfolge** für *alle* Einheiten definiert (Zuwachs-Sicht-Ordnung; lexicografisch nur als Tie-Break bei identischem Ort — AD-17h); **Update-Pfad-Rollback** in §5.3 Pkt. 3 (modifizierte Pfade aus Baseline-Commit wiederherstellen); **`generated.at`↔AD-17h-Gap** explizit als offener Punkt mit Home Story 3.8 benannt (Wanduhr-`at` erzeugt bei gleichem Input unterschiedliche Bundle-States; Konvention bleibt bis dahin bindend, Wechsel = Ask-First); **Term-Ableitung** (Pkt. 2 (a)) als §2-Interpretation abgegrenzt — die Erhebung *mit festem Term* ist textuell-deterministisch, der Term-Mechanismus (Kanonisierung/Synonyme) Story 3.2; **Link-Following** mit besuchter Menge (keine Schleife bei zyklischen Links); **Worked Example (Pkt. 7) auf den realen Ist-Baum korrigiert** (`rg -l 'FR-12' wiki/` trifft `wiki/knowledge-kompilation-inkrementell.md`, **nicht** `wissensarchitektur/source-material.md` — Rev-2.4.1-Beispiel enthielt den Term nicht); stale-Anker `§3.2-Kollisionsprüfung` (Pkt. 3-Zuordnung) und `§3-Voraussetzungsprüfung` (P2-Block) sowie §5.8-Pkt.-3-Zeiger („Pkt. 1" → „Pkt. 2") nachgeführt. **Abschlussklausel:** Keine Änderung an `schema/wiki-compiler.md`/`schema/validator.md`/`raw/` (AD-3); **keine neue §7-Invaliditätsklasse**; **kein Standalone** (D-3); keine Vertragsänderung; Commit-Boundary-Regel unverändert.
|
- **Revision 2.4.2 (2026-08-19, Story 3.1, bmad-code-review Loop 2, 4 Layer; Nutzer-Entscheidungen D-1/D-2/D-3/D-4 = 1/1/1/1):** (1) **Diff-Selbsttest (Pkt. 5) operationalisiert + Blind-Spots geschlossen (D-1):** Probe erweitert auf `git diff --name-only <Baseline-Commit> -- wiki/` **plus** `git status --porcelain -- wiki/` (erfasst ungetrackte neue Dateien `??` — die Duplikat-Kontrolle „keine neue Datei" braucht diese Sicht; `git diff` allein ist blind für Untracked); **Probe-Zeitpunkt fixiert vor dem Commit** (am Ende des P2-Blocks, nach den Mutationen) — nach dem Commit wäre die Probe vacuous (leere Ausgabe, AD-17f); erlaubte Teilmenge-Menge um **Neu-Anlage-Zielpfade** (§5.1/§5.7) ergänzt — Misch-Runs (Neu-Anlage + Update im selben Run) markieren neu angelegte Pfade nicht fälschlich als Ghost-Diff; **Pfad-Normalisierung** definiert (Strip `wiki/`-Präfix + `.md`-Suffix vor dem Teilmenge-Vergleich, da Kandidaten/Ziel-Pfade als relative OKF-Pfade *ohne* `.md` definiert sind); **Rollback-Mechanik** für den Ghost-Diff deterministisch benannt (modifizierte Pfade via `git checkout -- <wiki/pfad>`, ungetrackte neue Dateien gelöscht, Index via `git checkout -- <index>`; §5.3/§6.3-Teilzustand-Rollback greift daneben unverändert). (2) **R-1-Baseline deterministisch + Abweichungsregel (D-2):** `<Baseline-Commit>` (HEAD der vorherigen Mutations-Boundary, AD-17f) wird vom Producer **im `wiki/log.md`-Run-Eintrag notiert** (voller SHA) — deterministisch auflösbar ohne Domain-State-Annahme an Git (AD-14); **Diskrepanz-Regel**: widersprechen `git diff`-Befund und SHA-256-Record derselben Datei, **gewinnt `git diff`** (Commit-Boundary-Prinzip), SHA-256 bleibt Sekundär-Fingerprint; **Fallback**: ohne vorherige Mutations-Boundary gelten alle `raw/`-Dateien als Zuwachs; Rev-2.4.1-Claim „derselbe Baseline-Commit wie Pkt. 5" **korrigiert** (die Pkt.-5-Probe trägt das Baseline-Commit-Argument jetzt explizit). (3) **INPUT_UNCOMMITTED-Abbruch (D-3) + Anker-Divergenz:** neuer P2-Check-Block-Element (1) **Input-Zustand** — Working-Copy von `raw/`/`wiki/` gegen HEAD prüfen, bei Abweichung **benannter Abbruch „published/committed Input erforderlich"** vor Interpretation und vor jeder Mutation (AD-17a, I/O-Matrix-`INPUT_UNCOMMITTED` — zuvor nur Referenz auf §1 Pkt. 1, keine Zustandsprüfung/Abbruchmeldung); die **Spec↔Anker-Divergenz** (frozen Spec zitiert 3× „§1.1", §1 ist eine nummerierte Liste Pkt. 1–4 ohne §1.1-Label; Rev-2.4.1 korrigierte nur die Anker *in* compiler.md) wird hier als dokumentierte Fußnote gesichert — die Spec bleibt frozen (nur per menschlicher Renegotiation änderbar). (4) **Sandbox-Edge-Test-Nachweis (D-4):** die fünf I/O-Matrix-Szenarien (HAPPY_PATH_UPDATE, UNTOUCHED_CONCEPT, CONCEPT_COLLISION_BESTEHEND, CHANGE_DETECTION, PRE_RUN_RECONCILE) + die D-3-Abbruch-Kontrolle sind als re-executierbare Sandbox-Skripte mit **konkreten deterministischen Ausgaben** in der Spec-`## Verification`-Sektion (Sandbox-Beleg) verankert — die `wiki/log.md`- und `deferred-work.md`-Verweise („in der Spec-Verification enthalten") auflösbar. (5) **Instruktions-Präzisierungen:** P2-Block-**Zeitpunkt** (nach Reconcile, am Anfang der Mutationsphase; Diff-Probe am Block-Ende) — löst den Widerspruch „einmal an der Spitze erhoben" vs. „Kandidatenliste entsteht erst im Reconcile"; **No-Op-Kandidat**-Regel (Pkt. 2: Pfad, der die Evidenz bereits vollständig enthält → keine Mutation/kein `at`-Bump/kein `log.md`-Eintrag, byte-identisch — die engere Auslegung); **Mehrfach-Treffer-Reihenfolge** für *alle* Einheiten definiert (Zuwachs-Sicht-Ordnung; lexicografisch nur als Tie-Break bei identischem Ort — AD-17h); **Update-Pfad-Rollback** in §5.3 Pkt. 3 (modifizierte Pfade aus Baseline-Commit wiederherstellen); **`generated.at`↔AD-17h-Gap** explizit als offener Punkt mit Home Story 3.8 benannt (Wanduhr-`at` erzeugt bei gleichem Input unterschiedliche Bundle-States; Konvention bleibt bis dahin bindend, Wechsel = Ask-First); **Term-Ableitung** (Pkt. 2 (a)) als §2-Interpretation abgegrenzt — die Erhebung *mit festem Term* ist textuell-deterministisch, der Term-Mechanismus (Kanonisierung/Synonyme) Story 3.2; **Link-Following** mit besuchter Menge (keine Schleife bei zyklischen Links); **Worked Example (Pkt. 7) auf den realen Ist-Baum korrigiert** (`rg -l 'FR-12' wiki/` trifft `wiki/knowledge-kompilation-inkrementell.md`, **nicht** `wissensarchitektur/source-material.md` — Rev-2.4.1-Beispiel enthielt den Term nicht); stale-Anker `§3.2-Kollisionsprüfung` (Pkt. 3-Zuordnung) und `§3-Voraussetzungsprüfung` (P2-Block) sowie §5.8-Pkt.-3-Zeiger („Pkt. 1" → „Pkt. 2") nachgeführt. **Abschlussklausel:** Keine Änderung an `schema/wiki-compiler.md`/`schema/validator.md`/`raw/` (AD-3); **keine neue §7-Invaliditätsklasse**; **kein Standalone** (D-3); keine Vertragsänderung; Commit-Boundary-Regel unverändert.
|
||||||
|
- **Revision 2.7 (2026-08-19, Story 3.2, Step-04-Review Loop 3, 4 Layer; Nutzer-Entscheidungen D-1/D-2/D-3/D-4/D-5 = 1/1/1/1/1, jeweils empfohlene Option; + 2 Patches; D-3-Instruktions-Patch, kein neuer Inhalt):** (1) **§3.2-Pkt.-3b-Ordnung auf reine Lexikografie gehoben (D-4):** Stufe-a-Treffer waren „in der Reihenfolge des ziehenden Terms, dann lexikografisch als deterministischer Tie-Break" — die Term-Ordnung selbst war für Mehrfach-Terme (Pkt. 1c) nirgends festgelegt, zwei rechtmäßige Term-Ordnungen erzeugten zwei unterschiedliche Listen (AD-17h-Lücke). Jetzt: **innerhalb jeder Stufe rein lexikografisch aufsteigend (LC_ALL=C)**; die Term-Verarbeitungsreihenfolge dient nur der Interpretation/Erhebung, **nicht** der Listen-Ordnung — dieselbe Treffermenge → identische Liste. (2) **`schema/canonical-terms.md`-Lookup-Semantik vervollständigt (D-5):** Lookup-Verfahren deterministisch fixiert (lowercasing → `[-–_ ]`→`-`-Kollaps → **Lookup der normalisierten Form**; Spalten tragen ausschließlich normalisierte Formen), **Eindeutigkeits-Invariante** (jede normalisierte Form in genau einem Eintrag — Canon **oder** Variante, nie beides/zweimal) + **Konflikt-Verfahren** (keine stille Anhängung; `deferred-work.md`-Handoff / Ask-First, analog zur Umbenennungs-Regel). (3) **Statuskette `in-progress → done` dokumentiert (D-1):** der Review-Loop-Abschluss-Flip `in-progress → done` (Sprint-Sync-Konvention, Story-3.1-Präzedenz) war in keinem `wiki/log.md`-Eintrag als eigener Schritt belegt — nachgeführt als neuer oberster `wiki/log.md`-Bullet (append-only; die gefrorene Always-Klausel `→ in-progress` beschreibt den Implementierungsstand, der Review-Abschluss `done` ist der übliche Folgezustand). (4) **Mini-Sandbox um T5/T6/T7 erweitert + T1/T4-Asssertionen + T2-Kommentar-Korrektur (D-2 + Patch P-1):** T5 `LINK_FOLLOWING_ZYKLUS` (A→B→A-Links; besuchte Menge → endliche, doppelungsfreie Liste), T6 `TRAVERSAL_REACH_ONLY` (Term nur in Area-`index.md` → gewurzelte Concept-Pfade als Kandidaten; `index.md` selbst ist kein Concept-Kandidat), T7 `TERM_ABLEITUNG_SYNONYM` (Registry-Test-Doppel: Schreibvarianten → canonische Form via Lookup auf normalisierter Form; Negativ-Fall: nicht auflösbar → wie notiert, kein stiller Ausschluss); T1/T4 tragen jetzt harte Pass/Fail-Asssertionen (`exit 1` bei Abweichung) — die exakte Candidate-Liste wird erzwungen, nicht nur ausgegeben; der T2-Kommentar zu `index` korrigiert (Stufe-a-Treffer auf `wiki/index.md` löst Stufe b aus; `index.md` ist kein Concept-Kandidat). (5) **Selbsttest-Beleg (b) gegen den realen Sandbox-Ist-Baum re-executiert (D-3):** der Rev-2.5-Log-Beleg (b) beschrieb einen nicht-committierten Baum (Term `quanten-protocol`, `sub/beta.md`, SHA-256 `159092bb…`) — Stale-Evidenz-Falle (B1-Präzedenz). Der Nachweis wird jetzt gegen die echte `run-sandbox.sh`-Ausgabe (Term `deterministische-relevanz-bestimmung`, root-level `alpha`/`beta`/`gamma`) neu belegt; der Rev-2.5-Eintrag bleibt historisch unverändert, die Korrektur steht als neuer `wiki/log.md`-Bullet (append-only). (6) **Typos im normativen Text korrigiert (Patch P-2):** `Determinsmus` → `Determinismus` (§8-Referenzen + Log-/Defer-Belege), `§3.2-beankert` → `§3.2-angeankert`, `Membrum` → `Mitglied` (Spec-Design-Notes), `Konventionelle Determinismus-Lücke` → `Bekannte Determinismus-Lücke` (Defer-Beleg; `compiler.md:53` sagt „Bekannte"), `Resovierung` → `Auflösung` (Spec-Change-Log/-Verification). **Abschlussklausel:** Keine Änderung an `schema/wiki-compiler.md`/`schema/validator.md`/`raw/` (AD-3); **keine neue §7-Invaliditätsklasse**; **kein Standalone** (D-3); keine Vertragsänderung; Commit-Boundary-Regel unverändert. (Revisionslog-Reihenfolge-Anomalie 2.6/2.5 bleibt als dokumentierter Defer bestehen — nicht in dieser Runde umgeordnet.)
|
||||||
|
- **Revision 2.8 (2026-08-19, Story 3.3):** §5.9-Update-Formen **operationell ausformuliert** (dieselbe Evidenz + formale Struktur → identisches Update-Ergebnis, AD-17h/A0-19): (1) **Pkt. 2 — Präzisierungsebene je Update-Form** (als Sub-Bullet an die Commit-Boundary-Regel angefügt; der frozen Story-3.1-Regeltext bleibt textuell **unverändert** als normative Basis, die operationellen Regeln sind die Ausführungs-Ebene darunter — keine Re-Negotiation): je Form **(a) Abgrenzungskriterium** (aus der committeten Evidenz: neue belegte Aussage → Erweitern; Schärfung einer bestehenden Formulierung/Abgrenzung ohne Ersatz → Präzisieren; Ersetzung einer fehlerhaften/überholten → Korrigieren; keines davon → No-Op, engere Auslegung), **(b) Struktur-Erhaltungsregel** (das Geschützte — Frontmatter-Subset nur als `sources`-Zuwachs um echten neuen Beleg + `generated.at`-Bump; bestehende belegte Aussagen nicht umgeschrieben ohne dass Präzisieren/Korrigieren greift; §5.5-Inline-Verweise gültig soweit Beleg Body-Bestand; §5.6-Linkform unverändert, keine neuen Links außer bei echten Beziehungen) und **(c) Textgenauigkeits-Rahmen für Präzisieren** (Schärfen an der Aussage, kein Satz-Umbau, kein Neuschreiben ohne Ersetzungsbeleg). (2) **Pkt. 5 — Erhaltungs-Invariante um den Struktur-Erhaltungs-Bezug ergänzt:** die Diff-Probe verifiziert zwei Ebenen — die Pfad-Mengen-Ebene (bestehender Teilmenge-Vergleich) und die **Struktur-Ebene je berührtem Pfad** (pro betroffenem Concept-Pfad über die Pkt.-2-Regeln geprüft: Frontmatter-Subset, keine Umschreibung belegter Aussagen außerhalb der Formen, Inline-Verweise, Linkform — Verstöße textuell benannt (NFR-4), vor dem Commit zu beheben, sonst Ghost-Diff mit Rollback). (3) **Pkt. 6 — P2-Check-Block um den Struktur-Erhaltungs-Check erweitert** (Element (6), zusätzliches textuelles Element: keine unbefugten Keys — Vertrag §3.3/§3.4-Subset, keine stille Löschung — AD-16/„Korrigieren"-Form, Links unverändert/keine neuen ohne echte Beziehung — §5.6-Pin; Verstöße textuell benannt (NFR-4) und vor dem Commit behoben). (4) **Abschlussklausel:** Keine Änderung an `schema/wiki-compiler.md`/`schema/validator.md`/`raw/` (AD-3); **keine neue §7-Invaliditätsklasse**; **kein Standalone** (D-3); keine Vertragsänderung; Commit-Boundary-Regel unverändert; kein Leasing-Scope (AC-4 → Story 3.5/3.6, AD-17.3-Hinweis unverändert in §7). **`sprint-status.yaml`:** Key `3-3-bestehende-concepts-erweitern-präzisieren-korrigieren` bleibt **`in-progress`** (Review-Abschluss `done` erfolgt gemäß Workflow-Konvention durch den Review-Schritt). Sandbox-Nachweis und per-Datei-Validator-Verdikt siehe `wiki/log.md`-Eintrag (Story 3.3, Revision 2.8).
|
||||||
|
- **Revision 2.9 (2026-08-19, Story 3.4):** Neue Sektion **§5.10 „Synthese aus mehreren Sources (Story 3.4)"** eingefügt (nach §5.9, vor §6) — die **verbindliche Verankerung der Synthese-Dimension** (AD-4, FR-7): (1) **Synthese-Stimulus** (≥ 2 belegende `raw/`-Quellen desselben Themas per §2-Interpretation → eine Synthese-Einheit; einzelne Quelle bleibt auf §5.9-/§3.2-Pfad), (2) **Ein-Ziel-Repräsentation (§5.7-Routing; FR-7 AC-1)** — ein Synthese-Concept über einen Ziel-Pfad, `sources`-Liste ≥ 2 Einträge, **deterministisch lexikografisch nach `resource` (LC_ALL=C, AD-17h)**, getrennte Zusammenfassungs-Concepts je Quelle verboten; (3) **gemischte claim-granulare Provenienz (AD-4a/4b, A0-3)** — je Aussage Inline-`raw/`-Verweis §5.5, **Multi-Beleg-Konsolidierung** (§5.5-Semikolon-Form, voller Pfad je Beleg; keine Beleg-Tilgung AD-4), **AD-16-Default** (widersprüchliche Aussagen bleiben, Disagreement in `log.md`; Sandbox-N2); (4) **AD-4c-Übernahme-Marker** („übernommen aus `<Concept>` auf Basis von `<source>`, nicht eigenständig belegt" — nie alleinige Provenienz; Sandbox-N3); (5) **Reflektiertheits-Selbsttest** (FR-7 AC-4/NFR-7) — keine per-Source-Zusammenfassungs-Struktur („Quelle A: …"), grepbasiert `grep -nE 'Quelle [A-Z]:|Source [A-Z]:'`, Selbsttest-FAIL → textuell benannt (NFR-4) und vor Run-Abschluss behoben; (6) **§5.6-Pin unverändert** + **Form-Wahl-Klassifikationsprobe (Story-3.3-Defer U2/U7)** — Überlapp-Einheiten an die §5.9-Abgrenzungs-Reihenfolge `Korrigieren → Präzisieren → Erweitern → No-Op` (erste zutreffende Form), Textgenauigkeits-Rahmen der übrigen je Teilbestand; (7) **`log.md`-Eintragspflicht** („Story 3.1-Update" bei Update, Anlage-Eintrag bei neuem Synthese-Concept; Multi-Source-Liste + `<Baseline-Commit>`); (8) **Erhaltungs-Invariante (§5.9 Pkt. 5 gilt) + Determinismus-Vertrag** (Ziel-Pfad via §3.2/§5.7, `sources`-Lexikografie, Konsolidierung/Form-Zuordnung; `generated.at`-Wanduhr-Gap bleibt A0-20-Konvention, Home Story 3.8). **§7:** Synthese-Vorbehalt **aufgelöst** (in §5.10 verankert; verbleibende 3.x-Themen: Leasing/Dirty-Tree → Story 3.5/3.6). **§8:** Normreferenzen bleiben unverändert (AD-4/AD-4a/FR-7/A0-3 sind bereits über §5.5/Roh-Normreferenzen abgedeckt; AD-4c-Kontext-Marker weiterhin §5.5). **Abschlussklausel:** Keine Änderung an `schema/wiki-compiler.md`/`schema/validator.md`/`raw/` (AD-3); **keine neue §7-Invaliditätsklasse**; **kein Standalone** (D-3); keine Vertragsänderung; **keine fünfte Update-Form** (Abgrenzungs-Reihenfolge §5.9 unverändert, Synthese = Querschnitt); kein Leasing-Scope; Commit-Boundary-Regel unverändert. **`sprint-status.yaml`:** Key `3-4-wissen-aus-mehreren-sources-synthetisieren` → **`in-progress`**. Sandbox-Nachweis (S1–S6 + N1–N3 + Form-Wahl-Probe = 10 Szenarien, Exit 0) und per-Datei-Validator-Verdikt siehe `wiki/log.md`-Eintrag (Story 3.4, Revision 2.9). **Review-Loop-1-Patches (bmad-code-review, 3 Layer; dieser Eintrag nachgeführt):** Reflektiertheits-Selbsttest-Muster auf Zeilenanfangs-Label erweitert (`^(Quelle|Source) [A-Z][A-Za-z0-9_ -]*:` — mehrbuchstabige/nummerierte Quell-Labels werden ebenso erkannt); **Body-Reihenfolge deterministisch** (Aussagen-Positionierung lexikografisch über die Beleg-Anker, AD-17h) + **Konsolidierungs-Kriterium** (Befund-Äquivalenz über dieselbe erkannte Wissenseinheit) explizit; Stil-/Genus-Korrekturen (`sole`→`einzige`, `der Update`→`das Update`, `sources`-Pluspunkt→`sources`-Zuwachs). Keine Änderung an Normreferenzen, §7, Abschlussklausel.
|
||||||
|
|||||||
File diff suppressed because one or more lines are too long
Reference in New Issue
Block a user