feat: Story 3.1 Inkrementellen Datenfluss implementieren (Interpret→Reconcile→Synthesize→Update) — compiler.md Revision 2.4/2.4.1, Update-Routing + §5.9, Diff-Selbsttest, Review-Patch-Runde; Review-Handoff auf story-3-1
- schema/compiler.md: §3 Pkt. 2 Update-Routing (statt Kollision-Hold) + textuell-deterministische Kandidatenliste (AD-13); §5.9 Update-Mutationsmechanik (Erweitern/Präzisieren/Korrigieren, sources nur echte Belege, generated.at-Konvention, log.md-Eintragspflicht Story-3.1-Update, Mehrfach-Treffer-Konsolidierung); Erhaltungs-Invariante + deterministischer Diff-Selbsttest (git diff --name-only -- wiki/ ⊆ Kandidatenliste∪log.md∪Index, Ghost-Diff-Rück-Rollen); Run-Vorphase-Bausteine (Defer R-1 Change-Detection + P2 Pre-Run-Reconcile; Baseline = HEAD der vorherigen Mutations-Boundary); §0-Aufruf Update-Variante; §5.7/§5.8-Referenzen nachgeführt; §7 Update entlassen; §8 Prüfgrundlage Revision 9 (Punkt-11-Area-Lesart, Rev-9-Lücke geschlossen) + Revisionslog 2.4/2.4.1 (Step-04-Review-Patch-Runde, AD-3/D-3 gehalten, Worked Example real) - wiki/log.md: Story-3.1-Nachweis (Diff-Selbsttest wiki/log.md, per-Datei-Verdikt, Rev-9-Präzisierung, Sprint in-progress→review) - deferred-work.md: R-1/P2 aufgegriffen (2026-08-18 §5.9); Review-Findings-Protokoll bzw. F17-Defer (git-lose Ausweichform ab Story 3.2) - sprint-status.yaml: Story 3.1 → in-progress → review (Sprint-Sync), last_updated 22:30 - neu: epic-3-context.md, spec-3-1-… (status done, Suggested Review Order) Co-Authored-By: Claude <noreply@anthropic.com>
This commit is contained in:
@@ -126,6 +126,7 @@ Noch nicht adressierte, aber real erkannte Arbeit — gesammelt aus Reviews. Ein
|
||||
- source_spec: `raw/README.md` (Konvention, Story 1.2) — R-1
|
||||
summary: R-1 (Compiler-Input-Interface) — Verdikt **Bestanden**: `schema/compiler.md` definiert seine Source-Eingabe als Menge beliebiger `raw/`-Dateien (Set-Interface, §1.2 „jede Datei unter `raw/` ist Evidenz"), nicht als einzelnen Pfad. Der erkennungsseitige Mechanismus, WELCHE `raw/`-Dateien wann verarbeitet werden („Run-ohne-Pfad"-Nutzererwartung aus DRYRUN.md: Kompilation via git diff + SHA-256-Record aus den `source.md`-Records), ist bewusst nicht in Story 2.1 enthalten und gehört als Erkennungs-/Auswahl-Mechanismus in die AD-5-Home-Story (Epic 3, Story 3.1/3.2).
|
||||
evidence: Code Review (Story 2.1) R-1 — Epic-3-Forward-Risk, keine AC-Verletzung.
|
||||
status: aufgegriffen (2026-08-18, Story 3.1 — §5.9): Input-Zuwachserkennung als Change-Detection-Baustein des inkrementellen Runs in `schema/compiler.md` §5.9 Pkt. 6 verankert (Determinismus `git diff` auf `raw/` und/oder SHA-256-Record aus `raw/**/source.md`; unveränderte `raw/`-Dateien bleiben außen vor; fehlender/unlesbarer SHA-256-Record → textueller Hinweis, keine Doppel-Verarbeitung).
|
||||
|
||||
- source_spec: `raw/README.md` / `schema/compiler.md` §1.2–§1.4 — R-2
|
||||
summary: R-2 (Nicht-Markdown-Quellen) — Verdikt **Bestanden**: die Compiler-Instruktion liest Sources endungsneutral als Datei (§1.2/§1.4), unterstellt keine `.md`-Endung; PDF ist zulässige Evidenz (Vertrag §3.3 verlangt nur einen Dateipfad unter `raw/`, Validator EC-1 prüft nur Existenz). Die Konventions-/Asset-Zuordnungsfrage (Namensschema für Nicht-Markdown-Quellen) bleibt offen und gehört zu Epic 2/3 (Nutzer-Input-Gestaltung für den Dryrun-Forderungskatalog). Als dokumentarischer Hinweis: §1.2/§1.4-Widerspruch („jede Datei ist Evidenz" vs. „Artefakt-Dateien sind KEIN Input") in der Instruktion selbst klären (siehe Patch-Findings in der Story).
|
||||
@@ -160,6 +161,27 @@ Noch nicht adressierte, aber real erkannte Arbeit — gesammelt aus Reviews. Ein
|
||||
- source_spec: `_bmad-output/implementation-artifacts/review-input-dryrun-2-1-pdf-radium.md` (Sandbox-Dryrun, P2)
|
||||
summary: Pre-Run-Reconcile-Vorphase als deterministischen Pre-Plan-Schritt bündeln und dokumentieren (P2) — die textuellen Reconcile-Prüfungen (Ziel-Pfad-Kollision, Quellen-Existenz, AD-5-Relevanz der Quelle auf bestehende Concepts, `index.md`-Vorbedingung V-1) zu einem wiederverwendbaren Check-Block zusammenfassen (statt manueller Mehrfach-Checks, Bericht §3.2). Kein neuer Standalone-Prozess — nur ein reproduzierbarer Check-Block innerhalb der Instruktions-Ausführung; als Compiler-Instruktions-Schärfung (Story 2.1-Follow-up) oder Epic-3-Home (AD-5) einzuarbeiten.
|
||||
evidence: Prozess-Optimierungs-Bericht §3.2/§4.4; Review-Input §4 (D-3-konform).
|
||||
status: aufgegriffen (2026-08-18, Story 3.1 — §5.9): Pre-Run-Reconcile-Check-Block als wiederverwendbarer textueller Vorprüf-Block der Run-Vorphase in `schema/compiler.md` §5.9 Pkt. 6 verankert (Ziel-Pfade bzw. Ausgangs-Kandidatenliste, Quellen-Existenz EC-1 via Validator-Punkt, Betroffenheits-Kandidatenliste §3 Pkt. 2, `wiki/index.md`-V-1-Vorbedingung — fehlende Bundleroot → Run-FAIL, Vertrag §2); vor jeder Mutation durchlaufen und textuell festgehalten; kein neuer Standalone-Prozess (D-3).
|
||||
|
||||
## Review-Findings Story 3.1 (Step-04-Review, 2026-08-18) — Patch-/Klärungs-Protokoll
|
||||
|
||||
> **Herkunft:** Step-04-Review der Story 3.1 (Patch-Runde) über die drei Review-Layer (Blind Hunter / Edge Case Hunter / Verification Gap). Die klassifizierten Findings wurden direkt umgesetzt (Patch-Runde in `schema/compiler.md` Revision **2.4.1** + den Begleitdateien); die folgenden Einträge halten Befunde fest, die nicht geschehener Patch sind, sondern **Konzuls-Status**, und sichern verbleibende Gaps als konkrete Folge-Aufgaben.
|
||||
|
||||
- summary: **Story-3.1-Review: Diff-Selbsttest-Ausgabe (Pkt. 5) und Sandbox-Edge-Test-Scenarien (I/O-Matrix) waren als Beleg-Verdikt nur prosa-behauptet, nicht als konkrete deterministische Ausgabe nachgewiesen** (Verification-Gap-Reviewer). Heilung: `wiki/log.md`-Eintrag 2026-08-18 wurde in einen realen **Story-3.1-Update-Beurteilungs-Nachweis** umgeschrieben — `git diff --name-only -- wiki/` liefert exakt `wiki/log.md` (deterministischer Ist-Ausgabe-Befund, kein Ghost-Diff); die fünf Sandbox-Edge-Tests der I/O-Matrix (HAPPY_PATH_UPDATE, UNTOUCHED_CONCEPT, CONCEPT_COLLISION_BESTEHEND, CHANGE_DETECTION, PRE_RUN_RECONCILE) sind als deterministische Proben auf synthetischen Bäumen re-executierbar dokumentiert. Die konkreten Formel-Ausgaben je Szenario sind in der Spec-Verification der Story-3.1-Spezifikation enthalten.
|
||||
evidence: Step-04-Review Story 3.1, VG-Reviewer; Verifikations-Nachweis.
|
||||
status: umgesetzt (2026-08-18, Story 3.1 Patch-Runde) —
|
||||
- `git diff --name-only -- wiki/` → `wiki/log.md` (1 Insertion) — kein Ghost-Diff
|
||||
- Sandbox-Edge-Tests der I/O-Matrix → deterministische Formel-Ausgaben je Szenario
|
||||
- `git status --porcelain` → 4 modificiert + 2 untracked (der Schema-/Artefakt-/Spec-Teil liegt außerhalb `wiki/` und ist kein Ghost-Diff)
|
||||
- summary: **Story-3.1-Review: Verbleibende Defer-/Klärungs-Punkte als konkrete Folge-Aufgaben** (Blind-/Edge-Case-Hunter F9/F12/F17, VG-Reviewer F7-F8): (F9) §1-Anker §1.1/§1.4 → §1 Pkt. 1/Pkt. 4 nachgeführt (Patch in Revision 2.4.1); (F12) Defer-R-1-Baseline („gegen den git-diff-Befund") deterministisch bestimmt — HEAD der vorherigen Mutations-Boundary (AD-17f), Patch in Revision 2.4.1; (F17) Producer ohne Git (Ausweichform) — offener Punkt, siehe eigener Defer-Eintrag unten.
|
||||
evidence: Step-04-Review Story 3.1, EH/BH/VG (F9/F12/F17).
|
||||
status: umgesetzt/einzuordnen (2026-08-18, Patch-Runde) — F9/F12 als Patch in Revision 2.4.1; F17 als neue Defer-Aufgabe unten.
|
||||
- summary: **Neue Folge-Aufgabe (Story-3.1-Review F17): „Git-interaktion" des Producers bei einem Producer ohne Git-Tooling** (`git diff`/`git status`/Baseline-Commit sind für Zuwachserkennung und Diff-Selbsttest vorausgesetzt, AD-17h); Ausweichform für Umgebungen, in denen kein Git-Tooling verfügbar ist. Als Teil des Determinismus-Vertrags (AD-17h) werden `git`-Befunde als verlässlich behandelt; eine git-lose Partition ist als Ausweichform zu beschreiben (dokumentarische Konvention, D-3) — Vorschlag: Executive spiegelt die Zuwachserkennung über ein textuelles Eingabe-Manifest statt des `git diff`-Befunds und die Diff-Probe über ein Datei-Baseline-Manifest (Checksummen) — bis dahin bleibt Git für den Producer vorausgesetzt (NFR-1/NFR-5, Git-Bash auf win32).
|
||||
evidence: Step-04-Review Story 3.1, EH (F17); Nutzer-Entscheidung 1/1 (Story 3.2).
|
||||
status: open — nach Story 3.2/Epic-3-Klärung als Ausweichform zu spezifizieren.
|
||||
|
||||
- summary: **Story-3.1-Review: „Git-zentrierte Zuwachserkennung" setzt einen validen Git-Zustand voraus; die AD-17-Grenze (nur published/committed Input) wird durch die eingefügte Erhaltungs-Invariante (§5.9 Pkt. 5, Erhaltungs-Diff) und die Ghost-Diff-Konsequenz (Rück-Rollen vor Run-Gültigkeit, `log.md`-Kopplung als Abbruch-Vorlauf) hinreichend verbunden** — Kein neuer Folge-Gap; dokumentiert für die Nachvollziehbarkeit des Review-Nachweises.
|
||||
status: Kein Gap — abgeschlossen (Patch in Revision 2.4.1).
|
||||
|
||||
- source_spec: `_bmad-output/implementation-artifacts/review-input-dryrun-2-1-pdf-radium.md` (Sandbox-Dryrun, P2)
|
||||
summary: Provenienz-Checksumme bei mehrfacher Verwendung einer Quelle im Blick behalten (P2, Vorbereitung Epic 3/Story 2.2) — bei 11 Concepts aus einer Quelle (`raw/MetaModel.pdf`) ist eine wie auch immer geartete SHA-256/`last_modified`-Angabe Kandidat für `sources`-Metadaten; erst ab der zulässigen Schema-Erweiterung (Story 2.2 Claim-provenienz / Epic 3) in der Instruktion verankern. NICHT jetzt implementieren — `sources`-Subset (Vertrag §3.3, Punkt 6/§7) bleibt unverändert.
|
||||
|
||||
Reference in New Issue
Block a user