feat: Story 2.1 auf done setzen (Human-Review-Freigabe) + Re-Run-Patches Rev 1.4
Story 2.1 «Concepts aus Source Material erzeugen (OKF-Konform)» ist done: - spec-2-1: status review -> done + Change-Log-Eintrag - sprint-status.yaml: Story 2.1 -> done, last_updated 08-17 07:35 - wiki/log.md: done-Eintrag (Human-Review-Freigabe) - open bleibt: Action-Item code-review-2-1-item-2 (Validator-Rev 9, kein Blocker) Umsetzung der Unabhängig-Re-Run-Patches (4 Layer, 15/17): - schema/compiler.md -> Revision 1.4 (Pruefgrundlage Rev 8, §6.6-Labels §4.5/§4.2, §3.2 Kollision-Hold-Run-Fortsetzung, §5.3/§6.3 Rollback-Sequenz, Sprachkorrekturen) - wiki/index.md Baumdiagramm um Root-Concepts-Ebene - deferred-work Dedupe + n=21, review-input-dryrun Aufloesung, epic-2-context AD-4c tautologisch, validator-revision-8 status done/DoD, spec Verification Co-Authored-By: Claude <noreply@anthropic.com>
This commit is contained in:
Michael Tamse
@@ -115,13 +115,7 @@ Noch nicht adressierte, aber real erkannte Arbeit — gesammelt aus Reviews. Ein
|
||||
|
||||
> **Code-Review-Defer (bmad-code-review, 2026-08-16):** Diese Einträge decken die im externen Adverse-Review von Story 2.1 als Defer klassifizierten Befunde ab, die bewusst nicht in Story 2.1 behoben werden. Sie sind getrennt von den Step-04-Review-Defer-Kontexten oben (die der Implementierung selbst entstammen).
|
||||
|
||||
- source_spec: `_bmad-output/implementation-artifacts/spec-2-1-concepts-aus-source-material-erzeugen-okf-konform.md` (Code Review, Story 2.1)
|
||||
summary: Content-Truth-Verifikation einführen — kein bestehender Check verifiziert, dass der Body eines Concepts seinen deklarierten `raw/`-Quellen (Inhalt) entspricht. Die drei Concepts sind im Review inhaltlich korrekt (Spot-Checks gegen PRD/epics/spine bestätigt), aber Validator (§3 rein strukturell), spec-Verification (grep-Smoke) und compiler.md-Selbsttests (Kriterien 1–3) decken nur Form/Existenz, nicht den Inhalt. Verifikation, dass erfundenes/gegenläufiges Body-Content nicht als kuratierte Wahrheit durchgeht, ist die Kern-Fähigkeit (FR-2/FR-5).
|
||||
evidence: Verification-Gap-Review (Story 2.1): Body-Fälschung bei byte-identischem Frontmatter ändert kein Verdikt und keinen grep-Check. Für Story 2.2 (Claim-granulare Provenienz, AD-4a/A0-3) bzw. eine spätere Inhaltstreue-Prüfung.
|
||||
|
||||
- source_spec: `_bmad-output/implementation-artifacts/spec-2-1-concepts-aus-source-material-erzeugen-okf-konform.md` (Code Review, Story 2.1)
|
||||
summary: Determinismus-Selbsttest-Dokumentation in `schema/compiler.md` schärfen — §6.6-Interpretations-Hinweis behauptet, die ✓-Form sei „genau diese Form … im Demonstrationslauf erfüllt"; da `generated.at` pro Run variiert (Ausführungszeitpunkt, AD-15), ist der Selbsttest (Kriterium 2 „at-Normalform") als Form-Verifikation über die Normalform statt über einen festen `at`-Sekundenwert zu formulieren, damit ein „Regenerate"-Vergleich auf einem OTHER-Diff-Basis nicht an der Run-Zeit scheitert (Punkt-14-sicher). Für Story 2.3 (Determinismus/A0-7-Verifikation) bzw. nächste Validator-Revision.
|
||||
evidence: Edge-Case-Review (Story 2.1): „Determinism self-test compares generated.at which varies per run".
|
||||
> **Dedupe-Verweis (bmad-code-review Re-Run, 2026-08-17):** „Content-Truth-Verifikation einführen" und „Determinismus-Selbsttest-Dokumentation schärfen" wurden am 2026-08-16 bereits im Block „Folge-Aufgaben aus Story-2.1-Review (Defer-Kontexte; 2026-08-16)" oben erfasst (gleicher Tag, nahezu identischer Text, nur anderes `source_spec`-Label). Die Ownership liegt dort; dieser Code-Review-Block trägt beide Punkte **nicht** ein zweites Mal (vermeidet Doppel-Erledigung). Konkret: Content-Truth → Story 2.2; Determinismus-Selbsttest → Story 2.3 / nächste Validator-Revision.
|
||||
|
||||
- source_spec: `schema/validator.md` (Story 1.4) — aufgelöst via Option A
|
||||
summary: Frieren-Verletzung heilen — die Innen-Ebenen-Klarstellung (Punkt-6 / Key-Subset auf `sources`/`generated`-Eintragsebene), die Spot 2.1 als Rev-7-Notiz in `schema/validator.md` eingetragen hat, muss in der **nächsten autorisierten Validator-Revision** formal mitlaufen (gemeinsam mit der F-14-Negativ-Fixture). Dadurch verliert die Abweichung ihren Status als unautorisierte Mutation und Story 2.1 ist `done`-fähig. Der Rev-7-Hinweis bleibt bis dahin erhalten (kein Rückbau).
|
||||
@@ -150,7 +144,7 @@ Noch nicht adressierte, aber real erkannte Arbeit — gesammelt aus Reviews. Ein
|
||||
> **Herkunft:** Nutzer-Probelauf in `D:\mita\wow-2nd-sandbox` (Compiler Rev 1.3 gegen `raw/MetaModel.pdf`, 11 radium-Concepts OKF-konform als positivem R-2-Beleg ausgeführt) — siehe `review-input-dryrun-2-1-pdf-radium.md` im selben Verzeichnis. Der Bericht (vom Nutzer erstellt) enthält Tooling-/Prozess-Optimierungs-Maßnahmen (P1/P2/P3) **auf Ausführungs-/Werkzeug-Ebene**, keine Norm-Änderungen (D-3). Diese Einträge sichern die Folge-Aufgaben; die detaillierte Zuordnung (inkl. Konformitäts-Bewertung) steht im Review-Input-Dokument.
|
||||
|
||||
- source_spec: `_bmad-output/implementation-artifacts/review-input-dryrun-2-1-pdf-radium.md` (Sandbox-Dryrun, P1)
|
||||
summary: Fixture-Selbsttest des Validator-Prüfwerkzeugs vor jedem Bundle-Lauf etablieren (P1) — jede Negativ-Fixture (`validator.md` §7.1, n=17) muss ein deterministisches FAIL mit Ursache erzeugen, jede Positiv-Fixture (§7.2/§7.3, ~20) SUCCESS; optional die „Skript-Fallen" (PyYAML-`datetime`-Parsing statt Textform §4.3, relative Link-Auflösung Punkt 11, `usage_count`-Float) als eigene Negativ-Fixtures ergänzen. Nutzen: Fehler des Prüfwerkzeugs werden vor Berührung des Bundles sichtbar (im Probelauf 2 Diagnose-Zyklen durch Falsch-FAILs des Prüfskripts vermeidbar). D-3-tauglich (rein textueller Check-Block, kein Standalone).
|
||||
summary: Fixture-Selbsttest des Validator-Prüfwerkzeugs vor jedem Bundle-Lauf etablieren (P1) — jede Negativ-Fixture (`validator.md` §7.1, n=21) muss ein deterministisches FAIL mit Ursache erzeugen, jede Positiv-Fixture (§7.2/§7.3, ~20) SUCCESS; optional die „Skript-Fallen" (PyYAML-`datetime`-Parsing statt Textform §4.3, relative Link-Auflösung Punkt 11, `usage_count`-Float) als eigene Negativ-Fixtures ergänzen. Nutzen: Fehler des Prüfwerkzeugs werden vor Berührung des Bundles sichtbar (im Probelauf 2 Diagnose-Zyklen durch Falsch-FAILs des Prüfskripts vermeidbar). D-3-tauglich (rein textueller Check-Block, kein Standalone).
|
||||
evidence: Prozess-Optimierungs-Bericht §3.1/§4.1 (Tooling-Diagnose-Zyklen, Punkt-11-Identity-Match; korrigiert: kein Instruktions-Defekt); Review-Input §2/§4 (Konformität: D-3/AD-17h).
|
||||
|
||||
- source_spec: `_bmad-output/implementation-artifacts/review-input-dryrun-2-1-pdf-radium.md` (Sandbox-Dryrun, P1)
|
||||
@@ -168,3 +162,28 @@ 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: 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.
|
||||
evidence: Prozess-Optimierungs-Bericht §4.5; Review-Input §4 (vertragskonform: Schema-Subset unangetastet); verknüpft mit Defer zum „`sources`-`id`-Eindeutigkeit" (BH-13).
|
||||
|
||||
## Deferred from: code review of story-2.1 (2026-08-17)
|
||||
|
||||
> **Unabhängiger Re-Run (bmad-code-review, 2026-08-17)** auf dem Stand nach Validator-Rev-8 (HEAD `ae5e0aa`). Die tragenden Story-2.1-Artefakte sind validator-clean (alle 8 ACs PASS); die Defer-Einträge unten sind bewusst nicht in Story 2.1 behobene bzw. vorbestehende Punkte.
|
||||
|
||||
- source_spec: `_bmad-output/implementation-artifacts/spec-2-1-concepts-aus-source-material-erzeugen-okf-konform.md` (Code-Review-Re-Run 2026-08-17)
|
||||
summary: Content-Truth-Verifikation — keine Änderung zum bereits deferrierten Punkt (Story 2.2), aber der Re-Run liefert eine konkrete, prüfbare Instanz: das ASCII-Datenfluss-Diagramm-Layout in `wiki/knowledge-kompilation-inkrementell.md` stammt aus `raw/architecture-spine/…`, während das Concept `sources: raw/epics/…` deklariert (Inhalt kuratiert/korrekt, nur die exakte Diagrammform nicht von der deklarierten Source gedeckt).
|
||||
evidence: Acceptance-Auditor (Informational) + Blind Hunter; die anderen beiden Concepts sind vollständig in ihren deklarierten Sources verankert.
|
||||
|
||||
- source_spec: `_bmad-output/implementation-artifacts/spec-2-1-concepts-aus-source-material-erzeugen-okf-konform.md` (Code-Review-Re-Run 2026-08-17)
|
||||
summary: Concept-Bodies präsentieren Epic-3/4-Fähigkeiten als aktuelle Tatsache ohne Forward-Referenz-Marker — `knowledge-kompilation-inkrementell.md`: „Verbindung zu Regelwerken" (NEW/CONFIRMING-CORRECTING-Klassifikation, grep/ripgrep-Relevanzbestimmung → Story 3.2/4.1) und „FR-6 Aktualisierung statt neuer Dateien" (→ Story 3.1, die `compiler.md` §7 explizit nicht baut und deren Kollision-Hold §3.2 auf bestehendem Pfad abbricht). Zu markieren, sobald die Claim-Provenienz-/Kontext-Marker-Logik (Story 2.2) existiert.
|
||||
evidence: Blind Hunter (2 Einzelfindings); Epic-3/4-Zuordnung belegt in `raw/epics/…` (Story 3.1/3.2, 4.1).
|
||||
|
||||
- source_spec: `_bmad-output/implementation-artifacts/spec-2-1-concepts-aus-source-material-erzeugen-okf-konform.md` (Code-Review-Re-Run 2026-08-17)
|
||||
summary: `wiki/log.md` akkumuliert Meta-/Prozess-Einträge (Review-Verdikt, Action-Item-Statusflips, Validator-Revision-Ankündigungen) ohne Marker, der sie von Vertrag-§5-„fachlichen Änderungen" unterscheidet — vorbestehendes Muster (die Retrospective-Follow-up-Einträge tun dasselbe), nicht neu durch diesen Diff verursacht; F17 defert Log-Content-Validierung bewusst.
|
||||
evidence: Blind Hunter; pre-existing.
|
||||
|
||||
### Geholderte validator.md-Patches — Arbeitsauftrag für die nächste autorisierte Validator-Revision (Rev 9)
|
||||
|
||||
> **Herkunft:** Unabhängiger bmad-code-review Re-Run (2026-08-17), Patches 16/17. Beide betreffen die am 2026-08-17 autorisierte, gefrorene `schema/validator.md` (Rev 8) — ihre Anwendung setzt einen **neuen Autorisierungsschlag** auf `schema/` voraus und wurde im Re-Run bewusst **nicht** mitgepatcht (Frieren-Prinzip, Analogie zur Option-A-Heilung F-14). `validator.md` selbst bleibt bis zur autorisierten Revision unverändert.
|
||||
|
||||
- summary: **1. Punkt-4-Fehlerursachen-Grammatik um `resolved=`-Token erweitern** — Fixture 4a (§7.1) erwartet `FAIL … Punkt 4: resource ausserhalb raw/ oder unzulaessiger Pfad (resolved=README.md)`, aber die §3-Punkt-4-Vorlage `(..-Traversal|absolut|URL|Backslash|file://)` trägt kein `resolved=`-Token; §7 verlangt „exakt die aus §3". In der autorisierten Revision die Punkt-4-Vorlage um ein optionales `resolved=<Pfad>`-Token ergänzen (oder die Fixture-Vorlage an die Vorlage angleichen) + Zertifizierung der Fixture 4a (isoliert, genau Punkt 4) neu ausführen.
|
||||
- summary: **2. Innen-Ebenen-Punkt-6-Fixture-Zeile ergänzen** — die in Rev 8 formalisierte Innen-Ebenen-Regel (Punkt 6: unautorisierte Keys in `sources`/`generated`/`verified`-Einträgen, Vertrag §3.3–§3.5) hat keine Fixture-Zeile in §7.1/§7.3; der einzige Punkt-6-Fixture ist Top-Level `foo: bar`, §7.3 zeigt `sources … role: x` nur als Inline-Prosa-Beispiel. In der autorisierten Revision eine Negativ-Fixture-Zeile (z. B. `sources`-Eintrag mit `role: x` bei existierender `raw/`-Datei → `FAIL … Punkt 6`) ergänzen + Zertifizierung (isoliertes Sample) + Nachweis in `wiki/log.md` nachführen.
|
||||
evidence: bmad-code-review Re-Run (2026-08-17) — Blind Hunter + Verification-Gap; beides betrifft die gefrorene Rev 8.
|
||||
status: offen — Home: nächste autorisierte Validator-Revision (Rev 9), Validator-Kanal; **kein Story-2.1-Blocker** (Story bleibt `review`, `done`-fähig; verbleibende Schwelle = Human-Review). Verknüpft mit Action-Item `code-review-2-1-item-2`.
|
||||
|
||||
@@ -36,7 +36,7 @@ Aus dem lokal bereitgestellten Source Material (Epic 1) entstehen eigenständige
|
||||
|
||||
## Cross-Story Dependencies
|
||||
|
||||
- Setzt Workspace-Trennung, Bundle-Root und das OCKF-Feldsubset aus Epic 1 (Story 1.1, 1.3, 1.4) voraus; die Schema-Validierung von Story 1.4 erzwingt auch AD-4c (keine abgeleitete Provenienz).
|
||||
- Setzt Workspace-Trennung, Bundle-Root und das OCKF-Feldsubset aus Epic 1 (Story 1.1, 1.3, 1.4) voraus. AD-4c (keine abgeleitete Provenienz) ist in v1 tautologisch erfüllt — `sources` zeigt ausschließlich auf `raw/`, daher kann kein generiertes Concept ein anderes generiertes Concept als alleinige Provenienz führen (Vertrag §6.1: erzeugt **kein** eigenes Validitätsprädikat; kein eigener Validator-Check).
|
||||
- Die hier erzeugten Concepts, Links und `index.md`-Strukturen sind die Eingabe für die inkrementelle Kompilation und Synthese (Epic 3) sowie für Widerspruchs- und Kuratierungs-Kontexte (Epic 4).
|
||||
- Identität und Verlinkung dieses Epics werden von den Consumers in Epic 5 unverändert gelesen.
|
||||
- Keine UX-/Design-Anteile relevant für diesen Epic: v1 ist datei-/CLI-basiert ohne GUI (A-3, AD-11).
|
||||
|
||||
@@ -29,8 +29,10 @@ scope: review-context
|
||||
Run (`4fe7aaa0…eea5ec`). EC-11 bestätigt: `raw/report/report-2026-08-16.pdf`
|
||||
bleibt unberührt (kein `.md`, kein Verdikt).
|
||||
- **Validator-Run-Ergebnis (Sandbox-Selbstauskunft, Anhang A):** SUCCESS für
|
||||
alle 18 Sandbox-Bundle-Dateien (0 FAIL): 13 Root- + 5 `spring/`-Dateien.
|
||||
Darunter die 5 realen Bundle-Dateien zuzüglich 11 radium- + 2 spring-Dateien.
|
||||
alle 18 Sandbox-Bundle-Dateien (0 FAIL): 16 Root- (5 reale + 11 radium-) + 2
|
||||
`spring/`-Dateien.
|
||||
Darunter die 5 realen Bundle-Dateien zuzüglich 11 radium- + 2 spring-Dateien
|
||||
(= 16 Root- + 2 spring/ = 18).
|
||||
- **`at`-Konsistenz:** Alle 11 `at`-Stempel der neuen Concepts einheitlich
|
||||
(`2026-08-16T09:23:33Z`), `verified` ungesetzt (v1-Default AD-15), Innen-Ebenen-
|
||||
Key-Subset eingehalten (Punkt 6), kanonische Reihenfolge (§6.6).
|
||||
|
||||
+40
-6
@@ -2,8 +2,8 @@
|
||||
title: 'Concepts aus Source Material erzeugen (OKF-Konform) (Story 2.1)'
|
||||
type: 'feature'
|
||||
created: '2026-08-16'
|
||||
status: 'review'
|
||||
review_loop_iteration: 1
|
||||
status: 'done'
|
||||
review_loop_iteration: 2
|
||||
baseline_commit: a67ba659108006a54eb54b84592d1dba046af96e
|
||||
context:
|
||||
- _bmad-output/implementation-artifacts/epic-2-context.md
|
||||
@@ -119,9 +119,40 @@ Konforme Wiedervorlage nach dem Erst-Review — alle 5 Patch-Findings verifizier
|
||||
|
||||
**Verdikt (Re-Re-Review, 2026-08-17):** Die offene Option-A-Voraussetzung ist **erfüllt** — die autorisierte Validator-Revision 8 ist ausgeführt und zertifiziert. Story 2.1 ist damit **`review`-fähig und `done`-fähig**; keinerlei AC-/Vertrags-Blocker in den Story-Artefakten, keine neuen Findings aus den Nachzieh-Patches. Verbleibende Schwelle bis `done` ist ausschließlich die **menschliche Review-Freigabe** (Human-Review, Status `review` → `done`), nicht mehr eine technische Voraussetzung.
|
||||
|
||||
## Spec Change Log
|
||||
### Review Findings (bmad-code-review, 2026-08-17 — unabhängiger Re-Run auf dem Stand nach Validator-Rev-8)
|
||||
|
||||
- (leer bis zum ersten Review-Loopback)
|
||||
**Kernbefund:** Alle 8 Acceptance Criteria **PASS**; die tragenden Story-2.1-Artefakte (compiler.md, 3 Concepts, index/log, validator Rev 8) sind validator-clean (`raw/` unangetastet, keine Area-Verzeichnisse, kein Executable-Code, keine unautorisierten Keys in keiner Ebene, EC-1/Punkt 11 erfüllt). Kein `high`. Die Findings sind Doku-/Referenz-Konsistenz, zwei Instruction-Vollständigkeits-Lücken und ein `medium`-Governance-Item. Unabhängig verifiziert, nicht aus dem Vordingsvermerk übernommen.
|
||||
|
||||
**patch:**
|
||||
|
||||
- [x] [Review][Patch] `schema/compiler.md` §0/§8 nennt die Prüfgrundlage `validator.md` „Revision 7", aber der Validator ist jetzt **Revision 8** — die von OBS-1 geschlossene Referenzkette ist damit nur halbschließend (3 Layer: Blind + Acceptance + Verification-Gap) [schema/compiler.md:5, schema/compiler.md:127]
|
||||
- [x] [Review][Patch] `wiki/log.md` (2026-08-16): die `schema/compiler.md`-Rev-1.3-Zeile hat ihren `-`-Bullet verloren (nur führendes Leerzeichen) und rendert als Fortsetzung des Rev-8-Eintrags — zwei Ereignisse in einem Listeneintrag, bricht die §5-Flach-Bullet-Konvention, die dieser Diff selbst in Patch #5 durchgesetzt hat [wiki/log.md:8]
|
||||
- [x] [Review][Patch] `schema/compiler.md` §6.6: Referenz-Labels in 4 Zeilen falsch („§4.4 canonical Key-Reihenfolge", „§4.4 keine Duplikat-Keys", „§4.4 sources-Eintrag-Key-Subset", „§4.4 kein okf_version") — aber §4.4 dieser Datei ist die `status`/`stale_after`-Regel; canonical-order ist §4.5, sources-Key-Subset ist §4.2. Die Rev-1.2-Logzeile dokumentiert, das Label sei „von §4.5 auf §4.4 korrigiert" — d. h. die vorgegebene Korrektur bewegte es an die falsche Stelle [schema/compiler.md:99-102]
|
||||
- [x] [Review][Patch] `wiki/index.md`: das Baum-Diagramm (code-block) ist veraltet — es zeigt das Bundle weiterhin nur als `<area>/…` ohne Root-Concepts, während `## Concepts` direkt darunter 3 neue Root-Dateien auflistet; die Struktur-Skizze widerspricht nun dem Dateisatz, den sie dokumentiert [wiki/index.md:12-20]
|
||||
- [x] [Review][Patch] `deferred-work.md`: „Content-Truth-Verifikation einführen" und „Determinismus-Selbsttest-Dokumentation schärfen" erscheinen je **zweimal** (Folge-Aufgaben-Block + Code-Review-Block) mit nahezu identischem Text, aber unterschiedlichem `source_spec`-Label und (für Determinismus) unterschiedlichem Home — Ownership mehrdeutig, lädt zu Doppel-Erledigung ein [deferred-work.md]
|
||||
- [x] [Review][Patch] `deferred-work.md` (Sandbox-Dryrun-P1): „jede Negativ-Fixture (`validator.md` §7.1, **n=17**)" — die §7.1-Tabelle hat nach Revision 8 **21** Zeilen (nach Rev 7: 20); Zählung in einem frisch geschriebenen Eintrag falsch [deferred-work.md]
|
||||
- [x] [Review][Patch] `review-input-dryrun-2-1-pdf-radium.md` §1: interne Inkonsistenz der Datei-Auflösung — „13 Root- + 5 spring/" vs. „die 5 realen … zuzüglich 11 radium- + 2 spring-" (impliziert 16 Root- und 5 vs. 2 spring) [review-input-dryrun-2-1-pdf-radium.md]
|
||||
- [x] [Review][Patch] `validator-revision-8-autorisationsrunde-…md`: Frontmatter `status: 'draft'` **und** alle 4 Definition-of-Done-Boxen `- [ ]`, obwohl die Runde ausgeführt, zertifiziert und downstream `done` ist (Action-Item done, log.md-Zertifizierung, deferred-work „umgesetzt") — die Legitimität, Rev 8 als „autorisiert" zu führen, stützt sich auf ein nicht finalisiertes Dokument; Status finalisieren + DoD abhaken (3 Layer: Blind + Acceptance + Verification-Gap) [validator-revision-8-autorisationsrunde-f14-innen-ebenen.md:5,76-79]
|
||||
- [x] [Review][Patch] Spec: doppelte `## Spec Change Log`-Sektion — die obere enthält weiterhin nur „(leer bis zum ersten Review-Loopback)", die untere die tatsächlichen Einträge; das Re-Re-Review-Verdikt (der bedeutendste Zustandswechsel nach Log-Start) fehlt im Change Log [spec-2-1-…md]
|
||||
- [x] [Review][Patch] Rev-8-Runde: Datums-Diskrepanz — `wiki/log.md`, `sprint-status.yaml` (`closed`) und der validator-Rev-8-Logeintrag sagen **2026-08-16**, aber der ausführende Commit `e6c36fc` sowie `deferred-work.md` („umgesetzt 2026-08-17") und das `→ review`-Flip-Verdikt sagen **2026-08-17**; aus den Artefakten ist nicht konsistent ableitbar, an welchem Tag die Runde lief [wiki/log.md:7, sprint-status.yaml:161]
|
||||
- [x] [Review][Patch] `epic-2-context.md`: „die Schema-Validierung von Story 1.4 **erzwingt auch AD-4c** (keine abgeleitete Provenienz)" — übertrieben; Vertrag §6.1 (A0-5/AD-4c) sagt, die Regel sei in v1 „tautologisch erfüllt" und „erzeugt kein eigenes Validitätsprädikat", und der Validator hat keinen AD-4c-Check. Der frisch angelegte Epic-Kontext schreibt Erzwingung einem Mechanismus zu, der per Definition noch nicht existiert [epic-2-context.md]
|
||||
- [x] [Review][Patch] `schema/compiler.md` Sprache: §5.2 „Der Body darf keine **grossen** Quell-Exzerpte enthalten" (→ „großen") und §1.4 „zu verarbeitende Evidenz kann auch andere **Aufträge** als `.md` tragen" (→ „Formate"/„Endungen") — beide in normativem Kontext (FR-2-Bodylimit, Evidenz-Definition) [schema/compiler.md:28,61]
|
||||
- [x] [Review][Patch] Spec `## Verification` + `## Suggested Review Order` veraltet: erwarten „KEINE … `schema/validator.md`-Mutationen" und „Validator (Rev 7) … unverändert autorisiert" — beides wird vom Diff widersprochen (validator.md ist jetzt Rev 8 und mutiert); die Spec wurde nie angepasst, um zu verzeichnen, dass Option A den legitimen Diff-Inhalt geändert hat [spec-2-1-…md]
|
||||
- [x] [Review][Patch] `schema/compiler.md` §3.2 Kollision-Hold: definiert nur das Ergebnis je Einheit („bricht für diese Einheit ab"), aber **nicht**, ob der Run die übrigen Einheiten fortsetzt und was der Gesamt-Run-Status bei teils-gehaltener Einheit ist — Run-Ergebnis nicht deterministisch ableitbar [schema/compiler.md:40]
|
||||
- [x] [Review][Patch] `schema/compiler.md` §5.3/§6.3: „keine weiteren Mutationen auf FAIL" + „Commit-Boundary ist die Mutations-Boundary" fehlt eine **explizite Rollback-Sequenz** für den Teilzustand (Concept-Datei + Index-Zeile + log-Zeile bereits geschrieben), der zwischen „Mutieren" und einem fehlgeschlagenen „Validieren" existiert — teilweise Mutationen könnten inkonsistent im Bundle liegen [schema/compiler.md:63,70]
|
||||
- [ ] [Review][Patch] `schema/validator.md` §7.1 Fixture 4a: das erwartete Verdikt — **GEGEHOLDERT (2026-08-17):** betrifft die gerade autorisierte, gefrorene `validator.md` (Rev 8); Anwendung setzt einen neuen Autorisierungsschlag auf `schema/` voraus und wird separat bestätigt, nicht automatisch mitgepatcht. `Punkt 4: … (resolved=README.md)` ist aus der §3-Punkt-4-Vorlage `(..-Traversal|absolut|URL|Backslash|file://)` **nicht ableitbar** — die Vorlage trägt kein `resolved=`-Token (Punkt 4 deckt zwar „außerhalb raw/ durch Auflösung", die Fehlerursachen-Grammatik listet es aber nicht); §7 verlangt „exakt die aus §3". *Betrifft die (gerade autorisierte) frozen `validator.md`* [schema/validator.md:63,214]
|
||||
- [ ] [Review][Patch] `schema/validator.md` Rev 8: die „formalisierte" **Innen-Ebenen-Punkt-6-Regel** hat keine Fixture-Zeile — **GEGEHOLDERT (2026-08-17):** betrifft die gerade autorisierte, gefrorene `validator.md` (Rev 8); Anwendung setzt einen neuen Autorisierungsschlag auf `schema/` voraus und wird separat bestätigt, nicht automatisch mitgepatcht. in §7.1/§7.3 — der einzige Punkt-6-Fixture ist Top-Level `foo: bar` (Zeile 6), die §7.3-Notiz zeigt `sources … role: x` nur als Inline-Beispiel, nicht als Tabellen-Fixture; die Zertifizierung dieses Falls existiert nur als Prosa in log.md/spec/sprint-status, kein re-runbares Sample ist committed, obwohl §7 behauptet, die Tabellen machten „jede mechanische Bedingung reproduzierbar nachprüfbar". *Betrifft die (gerade autorisierte) frozen `validator.md`* [schema/validator.md:214,260]
|
||||
|
||||
**defer:**
|
||||
|
||||
- [x] [Review][Defer] Content-Truth-Verifikation: kein Check verifiziert den Body eines Concepts gegen seinen deklarierten `raw/`-Quellen-Inhalt. Konkrete Instanz: `knowledge-kompilation-inkrementell.md` — das ASCII-Datenfluss-Diagramm-Layout stammt aus `raw/architecture-spine/…`, deklariert ist `sources: raw/epics/…` (Inhalt an sich ist kuratiert/korrekt, nur die exakte Diagrammform ist nicht von der deklarierten Source gedeckt) — deferred, Story 2.2 (bereits in deferred-work.md) [wiki/knowledge-kompilation-inkrementell.md]
|
||||
- [x] [Review][Defer] Concepts präsentieren Epic-3/4-Fähigkeiten als aktuelle Tatsache ohne Forward-Referenz-Marker: `knowledge-kompilation-inkrementell.md` „Verbindung zu Regelwerken" (NEW/CONFIRMING-CORRECTING-Klassifikation + grep/ripgrep-Relevanz → Story 3.2/4.1) und „FR-6 Aktualisierung statt neuer Dateien" (→ Story 3.1, die `compiler.md` §7/§3.2 explizit nicht baut und deren Kollision-Hold auf bestehendem Pfad sogar abbricht) — deferred, Story 2.2/3 [wiki/knowledge-kompilation-inkrementell.md:62-67]
|
||||
- [x] [Review][Defer] Determinismus-Selbsttest: §6.6-Interpretations-Hinweis behauptet „genau diese Form … im Demonstrationslauf erfüllt", die ✓-Zeile pinnt `at: 2026-08-16T09:23:33Z`, aber `generated.at` variiert pro Run (AD-15) — für einen Regenerate-Vergleich hält nur die Normalform, nicht „genau diese Form" — deferred, Story 2.3 (bereits in deferred-work.md) [schema/compiler.md:97,108]
|
||||
- [x] [Review][Defer] `wiki/log.md`: die neuen 2026-08-16/17-Einträge sind überwiegend Prozess/Meta-Content (Review-Verdikt, Action-Item-Statusflips, Validator-Revision-Ankündigungen) statt Vertrag-§5-„fachliche Änderungen … verknüpft mit dem mutierten Concept-Pfad"; kein Marker unterscheidet Meta- von Fach-Einträgen, kein Validierungs-Hook (F17 defert Log-Content-Validierung bewusst) — vorbestehendes Muster (Retrospective-Follow-up-Einträge), nicht neu durch diesen Diff verursacht — deferred, pre-existing [wiki/log.md]
|
||||
|
||||
**dismiss (2 — nicht persistent):**
|
||||
- Consumer-Namen (BMAD/Claude Code/Codex) in `wissensarchitektur-trennung-states.md` **sind** in der deklarierten `raw/architecture-spine/…` belegt (Zeilen 324/334/700–701) — kein Content-Truth-Verstoß (False Positive des Blind-Hunters).
|
||||
- Sandbox-Dryrun-Artefakte (`review-input-dryrun-…md`, `deferred-work.md`-Dryrun-Block) sind additiv, nicht-normativ, klar als externer Kontext aus `D:\mita\wow-2nd-sandbox` gelabelt — kein Befund gegen `schema/`/`wiki/`/`raw/`.
|
||||
|
||||
## Design Notes
|
||||
|
||||
@@ -136,7 +167,7 @@ Konforme Wiedervorlage nach dem Erst-Review — alle 5 Patch-Findings verifizier
|
||||
## Verification
|
||||
|
||||
**Commands:**
|
||||
- `git status --short && git diff --stat` — expected: neue Datei `schema/compiler.md` + `wiki/<slug>.md`-Concepts + `wiki/index.md`-Änderung + `wiki/log.md`-Eintrag + `sprint-status.yaml`-Update; KEINE `raw/`-, `schema/wiki-compiler.md`-, `schema/validator.md`-Mutationen.
|
||||
- `git status --short && git diff --stat` — expected: neue Datei `schema/compiler.md` + `wiki/<slug>.md`-Concepts + `wiki/index.md`-Änderung + `wiki/log.md`-Eintrag + `sprint-status.yaml`-Update; KEINE `raw/`- oder `schema/wiki-compiler.md`-Mutationen. (Hinweis 2026-08-17: `schema/validator.md` ist zwischenzeitlich im Rahmen der autorisierten Option-A-Revision 8 mutiert — der ursprüngliche Diff-Erwartungswert „KEINE `schema/validator.md`-Mutationen" gilt für den Story-2.1-Erstellungs-Diff, nicht mehr für den Gesamt-Stand nach Validator-Rev-8.)
|
||||
- Validator-Instruktion gegen Bundle ausführen (manuell/deterministisch, siehe `schema/validator.md` §5-Grammatik): `grep -nE 'Punkt 11|concept nicht verlinkt' schema/validator.md` + praktischer SUCCESS-Lauf des Validators gegen `wiki/` — expected: alle neuen Concepts + `index.md` + `log.md` liefern `SUCCESS` (kein FAIL, kein WARN-Blocker).
|
||||
- Frontmatter-Konformitäts-Smoke: `grep -nE '^(type|sources|generated|verified|status|stale_after):' wiki/*.md` — expected: nur §3-Felder je Concept; `type` gesetzt; `generated.at` im Format `YYYY-MM-DDTHH:MM:SS` (mit Offset-Suffix).
|
||||
- `sources`-Auflösung: `grep -nE 'resource:' wiki/*.md` — expected: jeder Wert ist ein existierender `/`-getrennter `raw/`-Pfad (kein `..`, kein `wiki/`, keine URL).
|
||||
@@ -174,6 +205,9 @@ Konforme Wiedervorlage nach dem Erst-Review — alle 5 Patch-Findings verifizier
|
||||
|
||||
## Spec Change Log
|
||||
|
||||
- **2026-08-17 (Human-Review-Freigabe → `done`):** Nutzer-Freigabe erteilt — Story 2.1 ist `done` (Status `review` → `done`); die letzte verbleibende Schwelle (menschliche Review-Freigabe) ist damit überschritten. Alle 8 ACs PASS, kein AC-/Vertrags-Blocker; offene Folge-Arbeit (autorisierte Validator-Revision 9: Punkt-4-Grammatik `resolved=`-Token, Innen-Ebenen-Punkt-6-Fixture-Zeile) ist kein Story-2.1-Blocker und bleibt in `deferred-work.md` / Action-Item `code-review-2-1-item-2` verankert. `sprint-status.yaml`: Story 2.1 → `done`.
|
||||
- **2026-08-17 (Code-Review-Re-Run, Patches 15/17 umgesetzt):** Unabhängiger Re-Run (4 Layer) auf dem Stand nach Validator-Rev-8: 17 Patch / 4 Defer / 2 Dismiss, alle 8 ACs PASS. 15 Patches umgesetzt — `schema/compiler.md` → Revision 1.4 (Prüfgrundlage Rev 8, §6.6-Referenzlabels §4.5/§4.2, §3.2 Kollision-Hold-Run-Fortsetzung, §5.3/§6.3 Rollback-Sequenz, Sprachkorrekturen), `wiki/log.md` (verlorener Bullet, Rev-8-Datum), `wiki/index.md` (Baumdiagramm), `deferred-work.md` (Dedupe, n=21), `review-input-dryrun-…md` (Datei-Auflösung 16+2), `validator-revision-8-…md` (status done, DoD), `epic-2-context.md` (AD-4c tautologisch), spec Verification/Suggested-Review-Order (Rev 8), `sprint-status.yaml` (closed-Datum 08-17). 2 Patches auf der gefrorenen `validator.md` (Rev 8) **geholdert** → nächste autorisierte Validator-Revision (Rev 9): Punkt-4-Grammatik `resolved=`-Token + Innen-Ebenen-Punkt-6-Fixture-Zeile (s. `deferred-work.md` „Arbeitsauftrag Rev 9", Action-Item `code-review-2-1-item-2`). Status bleibt `review` (`done`-fähig; verbleibende Schwelle = Human-Review).
|
||||
- **2026-08-17 (Re-Review):** Re-Re-Review-Verdikt — Option-A-Voraussetzung erfüllt (autorisierte Validator-Revision 8 ausgeführt und zertifiziert: F-14-Fixture 4a, Innen-Ebenen-Key-Subset formalisiert, Header „Revision 6" → „Revision 8"); Story 2.1 `review`-fähig und `done`-fähig; verbleibende Schwelle bis `done` ausschließlich die menschliche Review-Freigabe.
|
||||
- **2026-08-16 (Step-04-Review):** `sources`-Eintrag-Key-Subset als Zusatz-Verification-Check ergänzt (Vertrag §3.3, Punkt 6); `at`-Format-Smoke als Punkt-14-Beleg unter die Verification-Checks aufgenommen; `status: in-review` (Review begonnen). Keine Änderung am `<frozen-after-approval>`-Intent.
|
||||
- **2026-08-16 (Erstellung):** Initiale Approve-Baseline.
|
||||
|
||||
@@ -217,7 +251,7 @@ Nach den drei Review-Layern (Blind Hunter, Edge Case Hunter, Verification Gap) a
|
||||
- Authorized contract: field subset, `sources` key-subset per entry, `generated` by/at — the normative anchor Story 2.1 derives from (unchanged, authorized).
|
||||
[`wiki-compiler.md`](../../schema/wiki-compiler.md#L53)
|
||||
|
||||
- Validator (Rev 7): §7.3-Isolations-Hinweis auf Innen-Ebenen-Key-Subset erweitert — Punkt 6 deckt auch `sources`/`generated`/`verified`-Eintragsebenen ab (Revisionslog nachgeführt, unverändert autorisiert).
|
||||
- Validator (Rev 8): F-14-Negativ-Fixture 4a (§7.1, Punkt 4) + Innen-Ebenen-Key-Subset formalisiert (Punkt 6 → §7.3-Isolations-Notiz, autorisiert) + Header-Revisionszahl auf 8 angehoben (OBS-1 behoben) — autorisierte Option-A-Revision, 2026-08-17 ausgeführt und zertifiziert.
|
||||
[`validator.md`](../../schema/validator.md#L260)
|
||||
|
||||
**Wissenseinheiten — Konzepte aus den Quellen**
|
||||
|
||||
@@ -29,7 +29,7 @@
|
||||
# - 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
|
||||
generated: 08-14-2026 00:00
|
||||
last_updated: 08-17-2026 05:40
|
||||
last_updated: 08-17-2026 07:35
|
||||
project: wow20
|
||||
project_key: NOKEY
|
||||
tracking_system: file-system
|
||||
@@ -43,7 +43,7 @@ development_status:
|
||||
epic-1-retrospective: done
|
||||
|
||||
epic-2: in-progress
|
||||
2-1-concepts-aus-source-material-erzeugen-okf-konform: review
|
||||
2-1-concepts-aus-source-material-erzeugen-okf-konform: done
|
||||
2-2-claim-granulare-provenienz-dokumentieren: backlog
|
||||
2-3-concepts-verlinken-eine-erlaubte-linkform: backlog
|
||||
2-4-deterministische-bereichszuordnung-concept-hierarchie: backlog
|
||||
@@ -159,10 +159,16 @@ action_items:
|
||||
'Revision 7', OBS-1). Danach Story 2.1 zur Review-Freigabe wiedervorlegen."
|
||||
owner: "dev"
|
||||
status: done
|
||||
closed: "2026-08-16"
|
||||
closed: "2026-08-17"
|
||||
resolution: "schema/validator.md auf Revision 8: F-14-Fix-Fixture 4a (§7.1, Punkt 4),
|
||||
Innen-Ebenen-Key-Subset formalisiert (Punkt-6-Zelle verweist auf §7.3, autorisiert),
|
||||
Header-Revisionszahl auf 8 angehoben (OBS-1 behoben). Zertifizierung PASS (Fixture
|
||||
4a FAIL Punkt 4; Innen-Ebenen FAIL Punkt 6; reales Bundle SUCCESS). Story 2.1
|
||||
zur Review-Freigabe wiedervorgelegt (status: review)."
|
||||
ref: "_bmad-output/implementation-artifacts/validator-revision-8-autorisationsrunde-f14-innen-ebenen.md"
|
||||
- id: "code-review-2-1-item-2-validator-rev9-punkt4-grammar-innen-ebenen-fixture"
|
||||
epic: 2
|
||||
action: "Autorisierte Validator-Revision 9 vorbereiten (bmad-code-review Re-Run 2026-08-17, geholderte Patches 16/17): 1) Punkt-4-Fehlerursachen-Grammatik um `resolved=`-Token erweitern (Fixture 4a ableitbar machen); 2) Innen-Ebenen-Punkt-6-Fixture-Zeile in §7.1/§7.3 ergänzen (Rev-8-Formalisierung re-runbar belegen). Danach Zertifizierung (isolierte Fixtures + reales Bundle) und `wiki/log.md`-Nachweis."
|
||||
owner: "dev"
|
||||
status: open
|
||||
ref: "_bmad-output/implementation-artifacts/deferred-work.md"
|
||||
|
||||
+5
-5
@@ -2,7 +2,7 @@
|
||||
title: 'Autorisierte Validator-Revision 8 — F-14-Fixture + Innen-Ebenen-Key-Subset formalisieren (Option-A-Heilung Story 2.1)'
|
||||
type: 'authorization-round'
|
||||
created: '2026-08-16'
|
||||
status: 'draft'
|
||||
status: 'done'
|
||||
based_on_commit: f91ef89078ee8e4c8a979cfb70f20ead1ffe854b
|
||||
related:
|
||||
- _bmad-output/implementation-artifacts/spec-2-1-concepts-aus-source-material-erzeugen-okf-konform.md
|
||||
@@ -73,7 +73,7 @@ Nach erfolgreicher Ausführung + Zertifizierung:
|
||||
|
||||
## Erfolgskriterien (Definition of Done dieser Runde)
|
||||
|
||||
- [ ] `schema/validator.md` trägt Revision 8: Header `8`, Revisionslog-Eintrag Rev 8, Fixture 4a, Innen-Ebenen-Verweis in Punkt-6-Zelle; §7-Katalog weiterhin abschließend (kein neuer Punkt 15).
|
||||
- [ ] Zertifizierung 1–3 dokumentiert (Fixture 4a FAIL, Innen-Ebenen Punkt 6 FAIL, reales Bundle SUCCESS).
|
||||
- [ ] `schema/wiki-compiler.md`, `schema/compiler.md`, `raw/`, `adapters/`, `wiki/`-Concepts unverändert (außer `wiki/log.md`-Einträge).
|
||||
- [ ] Sprint-Tracking aktualisiert (Action-Item done, Story 2.1 `done` nach Human-Review).
|
||||
- [x] `schema/validator.md` trägt Revision 8: Header `8`, Revisionslog-Eintrag Rev 8, Fixture 4a, Innen-Ebenen-Verweis in Punkt-6-Zelle; §7-Katalog weiterhin abschließend (kein neuer Punkt 15).
|
||||
- [x] Zertifizierung 1–3 dokumentiert (Fixture 4a FAIL, Innen-Ebenen Punkt 6 FAIL, reales Bundle SUCCESS).
|
||||
- [x] `schema/wiki-compiler.md`, `schema/compiler.md`, `raw/`, `adapters/`, `wiki/`-Concepts unverändert (außer `wiki/log.md`-Einträge).
|
||||
- [x] Sprint-Tracking aktualisiert (Action-Item done, Story 2.1 `done` nach Human-Review).
|
||||
|
||||
+12
-11
@@ -2,7 +2,7 @@
|
||||
|
||||
> **Status:** abgeleitet (Story 2.1) — deterministische, agent-unabhängige Compiler-Instruktion für die Erzeugung neuer Concepts aus Source Material.
|
||||
> **Normative Grundlage:** `schema/wiki-compiler.md` (autorisiert, Story 1.3) — insbesondere §2 Bundleroot, §3 Feldsubset (§3.1–§3.7), §5 `log.md`-Typdefinition, §6 Index-Regel/Prädikate, §7 abschließende 14-Punkte-Liste, §8 Normreferenzen.
|
||||
> **Prüfgrundlage:** `schema/validator.md` (abgeleitet, Story 1.4; Revision 7) — die Validierung bleibt die mechanische Bestätigung der Konformität (AD-17h).
|
||||
> **Prüfgrundlage:** `schema/validator.md` (abgeleitet, Story 1.4; Revision 8) — die Validierung bleibt die mechanische Bestätigung der Konformität (AD-17h).
|
||||
> **Ableitungsdatum:** 2026-08-16
|
||||
> **Kanonischer Producer-Actor:** `wow-compiler/0.1.0`
|
||||
|
||||
@@ -25,7 +25,7 @@ Bestätigung (Story 1.4): schema/validator.md (mechanische Prüfung, kein L
|
||||
1. **Voraussetzung:** Der Run verarbeitet ausschließlich **veröffentlichte (committete) Inhalte** als Input (AD-17a — „Der Compiler darf nur veröffentlichte (committed) Inhalte als Input verwenden"); Zwischenstände während einer Mutation sind nie Input.
|
||||
2. **Evidenz:** Das Source Material unter `raw/` — jede Datei unter `raw/`, die als evidierenfähige Source verarbeitet wird, ist Evidenz (AD-2/AD-3). Vom Compiler erzeugte Concepts DÜRFEN ausschließlich auf solche `raw/`-Dateien als `sources`-`resource` zeigen.
|
||||
3. **Bestehendes Bundle:** Das aktuelle `wiki/` (Bundleroot `index.md`, `log.md`, bestehende Concepts) ist der zweite Input; der Run beginnt mit dem vorhandenen Bundle und verändert nur, was durch neue Erkenntnisse betroffen ist (AD-5 — niemals „Regenerate Everything").
|
||||
4. **Nicht-Evidenz (Artefakt-/Grenzdateien) sind KEIN Input:** `raw/README.md`, jede `raw/**/source.md` (Provenienz-Sidecar), `schema/`, `adapters/` — sie sind keine zu verarbeitende Evidenz und dürfen **nie** als `sources`-`resource` eines Concepts verwendet werden. (Dokumentarische Konvention der Source-Bereitstellung nach `raw/README.md` — eine nicht-mechanische Ausnahme zur Evidenz-Erwartung; zu verarbeitende Evidenz kann auch andere Aufträge als `.md` tragen, z. B. PDF.)
|
||||
4. **Nicht-Evidenz (Artefakt-/Grenzdateien) sind KEIN Input:** `raw/README.md`, jede `raw/**/source.md` (Provenienz-Sidecar), `schema/`, `adapters/` — sie sind keine zu verarbeitende Evidenz und dürfen **nie** als `sources`-`resource` eines Concepts verwendet werden. (Dokumentarische Konvention der Source-Bereitstellung nach `raw/README.md` — eine nicht-mechanische Ausnahme zur Evidenz-Erwartung; zu verarbeitende Evidenz kann auch andere Formate als `.md` tragen, z. B. PDF.)
|
||||
|
||||
## 2. Interpretieren (Wissenseinheiten erkennen)
|
||||
|
||||
@@ -37,7 +37,7 @@ Bestätigung (Story 1.4): schema/validator.md (mechanische Prüfung, kein L
|
||||
## 3. Reconcile (gegen das bestehende Bundle)
|
||||
|
||||
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. **Kollision-Hold:** Existiert bereits ein Concept mit dem Ziel-Pfad, wird **nicht** stumm überschrieben. Diese Instruktion deckt die Anlage **neuer** Concepts ab; die Erweiterung/Präzisierung/Korrektur bestehender Concepts ist Epic 3 (AD-5, FR-6). Der Run bricht für diese Einheit mit einem textuell identifizierbaren Hinweis ab („Concept existiert bereits — Aktualisierung ist Epic 3").
|
||||
2. **Kollision-Hold:** Existiert bereits ein Concept mit dem Ziel-Pfad, wird **nicht** stumm überschrieben. Diese Instruktion deckt die Anlage **neuer** Concepts ab; die Erweiterung/Präzisierung/Korrektur bestehender Concepts ist Epic 3 (AD-5, FR-6). Der Run bricht für diese Einheit mit einem textuell identifizierbaren Hinweis ab („Concept existiert bereits — Aktualisierung ist Epic 3") und **setzt mit den übrigen erkannten Wissenseinheiten fort**; die gehaltene Einheit erzeugt keine Datei, keinen Index-Link und keinen `log.md`-Eintrag. Mindestens eine erfolgreich erzeugte und mindestens eine gehaltene Einheit → der Run ist **teilweise erfolgreich**: die erzeugten Concepts werden normal validiert und veröffentlicht, die gehaltenen Einheiten werden textuell als solche benannt (NFR-4).
|
||||
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 werden (Run-FAIL, Vertrag §2).
|
||||
|
||||
## 4. Synthetisieren (Provenienz & Trust)
|
||||
@@ -58,16 +58,16 @@ Je neuem Concept werden die Frontmatter-Metadaten nach Vertrag §3 festgelegt:
|
||||
|
||||
1. **Ziel-Pfad:** Das neue Concept ist eine Markdown-Datei unter `wiki/`. In dieser Story (keine deterministische Area-Zuordnung; Story 2.4) werden neue Concepts **auf Root-Ebene** angelegt: `wiki/<concept-kebab-case>.md`. Es wird **kein** `wiki/<area>/`-Verzeichnis angelegt; ein als Area gedachtes Ziel (Unterverzeichnis) wird bis Story 2.4 **abgelehnt** und führt zu einem textuell identifizierbaren Hinweis („Area-Zuordnung ist Story 2.4").
|
||||
- Konvention für den Dateinamen: kebab-case-Slug aus der Concept-Identität (kein Sonderzeichen, keine Endung `.md`-Dopplung). Der Dateiname definiert die Concept-Identität (relativer OKF-Pfad ohne `.md`, AD-7a).
|
||||
2. **Dateiinhalt:** YAML-Frontmatter gemäß §4 (kein weiteres Feld), gefolgt von einem Markdown-Body, der die Wissenseinheit eigenständig und lesbar darstellt (NFR-2, NFR-3). Der Body darf keine grossen Quell-Exzerpte enthalten (FR-2). Claim-granulare Inline-Provenienz (AD-4a) ist Story 2.2 und wird hier **nicht** gefordert.
|
||||
2. **Dateiinhalt:** YAML-Frontmatter gemäß §4 (kein weiteres Feld), gefolgt von einem Markdown-Body, der die Wissenseinheit eigenständig und lesbar darstellt (NFR-2, NFR-3). Der Body darf keine großen Quell-Exzerpte enthalten (FR-2). Claim-granulare Inline-Provenienz (AD-4a) ist Story 2.2 und wird hier **nicht** gefordert.
|
||||
3. **Index-Regel (Punkt 11/§6):** Nach Anlage MUSS das neue (Root-)Concept in der Bundleroot `wiki/index.md` verlinkt werden — seine Identität (relativer OKF-Pfad ohne `.md`) als relativer Bundle-Pfad referenziert, mit oder ohne `.md`-Endung (eine genau-eine-Form-Festlegung ist Story 2.3). Ohne diese Verlinkung ist das Bundle strukturell invalide (§7 Punkt 11).
|
||||
- All dies (Anlage + Verlinkung + `log.md`) erst abschließen, wenn die Validierung (§6) SUCCESS liefert. Zwischenstände werden nicht als fertige Mutation veröffentlicht — Commit-Boundary ist die Mutations-Boundary (AD-17f).
|
||||
- All dies (Anlage + Verlinkung + `log.md`) erst abschließen, wenn die Validierung (§6) SUCCESS liefert. Zwischenstände werden nicht als fertige Mutation veröffentlicht — Commit-Boundary ist die Mutations-Boundary (AD-17f). Bei Validierungs-FAIL wird der Teilzustand **explizit zurückgerollt**: neue Concept-Datei(en) gelöscht, zugehörige Index-Verlinkung(en) aus `wiki/index.md` entfernt, `log.md`-Eintrag(e) wieder entfernt — das Bundle nimmt seinen Zustand vor dem Run wieder ein (keine partielle Mutation bleibt liegen).
|
||||
4. **Dokumentation (`log.md`, Vertrag §5):** Die Anlage neuer Concepts wird als datumsgruppierter Eintrag in `wiki/log.md` dokumentiert (neueste zuerst; Header = ISO-Datum `YYYY-MM-DD`), verknüpft mit dem neuen Concept-Pfad und den genutzten `raw/`-Quellen. `log.md` bleibt ohne Frontmatter (Punkt 10).
|
||||
|
||||
## 6. Validieren (mechanische Bestätigung)
|
||||
|
||||
1. Nach Abschluss aller Mutationen wird das gesamte Bundle gemäß `schema/validator.md` geprüft (§3 14 Punkte je Datei + §6-Fachprüfungen; Verdikt-Grammatik §5).
|
||||
2. **Erfolgsbedingung:** Alle Dateien unter `wiki/` — Bundleroot, `log.md`, sämtliche neuen Concepts — liefern `SUCCESS` (kein FAIL; `stale_after`-WARN wäre nur Berichtskanal). Dabei ist insbesondere Punkt 11 (Index-Regel) zu bestätigen: jeder neue Root-Concept-Pfad ist in `wiki/index.md` verlinkt.
|
||||
3. Bei jedem FAIL gilt der Run als gescheitert; es werden **keine** weiteren Mutationen durchgeführt, `raw/` bleibt unangetastet (AD-3), und die Fehlerursache wird textuell benannt (NFR-4).
|
||||
3. Bei jedem FAIL gilt der Run als gescheitert; es werden **keine** weiteren Mutationen durchgeführt, `raw/` bleibt unangetastet (AD-3), und die Fehlerursache wird textuell benannt (NFR-4). Der bereits geschriebene Teilzustand (neue Concept-Dateien, Index-Verlinkungen, `log.md`-Einträge) wird gemäß §5.3 zurückgerollt, sodass das Bundle seinen Zustand vor dem Run wieder einnimmt.
|
||||
4. Der Producer hält das Verdikt-Ergebnis (je Datei SUCCESS/FAIL) als Ausführungs-Nachweis fest (z. B. in der Story-Spezifikations-Verification oder im Run-Bericht).
|
||||
|
||||
## 6.5 Determinismus- & Selbsttest-Norm (Nachprüf-Sektion)
|
||||
@@ -96,10 +96,10 @@ Die folgende Tabelle macht jede Erzeugungsregel dieser Instruktion reproduzierba
|
||||
| §4.3 `generated.by` Pflicht (§3.4) | `generated: {by: wow-compiler/0.1.0, at: …}` | `generated: {at: …}` (ohne `by`) → Punkt 7 |
|
||||
| §4.3 `generated.at` volles ISO-8601-Datetime (§3.4, Validator §4.3) | `at: 2026-08-16T09:23:33Z` | `at: 2026-08-16` (reines Datum) → Punkt 14 |
|
||||
| §4.3 `verified` ungesetzt (A0-20) | (kein `verified`) | `verified: {by: human:x, at: …}` → Punkt 6 (unautorisiertes Feld, nur maschinelle Erzeugung A0-20), hier nicht erzeugt |
|
||||
| §4.4 canonical Key-Reihenfolge (Validator §4.1) | `type` → `sources` → `generated` | — (kein Validator-FAIL: Reihenfolge ist Output-Normalform, kein §7-Punkt; der Compiler erzeugt sie deterministisch und die Normalform-Abweichung tritt damit nicht auf) |
|
||||
| §4.4 keine Duplikat-Keys (Punkt 13) | jeder Key einmal | zweimal `type:` → Punkt 13 |
|
||||
| §4.4 `sources`-Eintrag-Key-Subset (Vertrag §3.3) | nur `resource`, `id`, `title`, `author`, `usage_count`, `last_modified` | `resource …` + z. B. `role: x` → Punkt 6 (unautorisiertes Feld, Innen-Ebene) |
|
||||
| §4.4 kein `okf_version`/`type: bundle` (Punkt 9) | (nicht vorhanden) | `okf_version: "0.2"` → Punkt 9 |
|
||||
| §4.5 canonical Key-Reihenfolge (Validator §4.1) | `type` → `sources` → `generated` | — (kein Validator-FAIL: Reihenfolge ist Output-Normalform, kein §7-Punkt; der Compiler erzeugt sie deterministisch und die Normalform-Abweichung tritt damit nicht auf) |
|
||||
| §4.5 keine Duplikat-Keys (Punkt 13) | jeder Key einmal | zweimal `type:` → Punkt 13 |
|
||||
| §4.2 `sources`-Eintrag-Key-Subset (Vertrag §3.3) | nur `resource`, `id`, `title`, `author`, `usage_count`, `last_modified` | `resource …` + z. B. `role: x` → Punkt 6 (unautorisiertes Feld, Innen-Ebene) |
|
||||
| §4.5 kein `okf_version`/`type: bundle` (Punkt 9) | (nicht vorhanden) | `okf_version: "0.2"` → Punkt 9 |
|
||||
| §5.1 Root-Pfad & Verlinkung (Punkt 11, §6) | `wiki/<slug>.md` + Link in `wiki/index.md` | Concept ohne Link in `index.md` → Punkt 11; `wiki/<area>/<slug>.md` → Bereichs-Hinweis (Story 2.4) |
|
||||
| §5.4 `log.md`-Dokumentation (§5) | datumsgruppierter Eintrag mit Concept-Pfad + Quellen | fehlender Eintrag → kein Validator-FAIL, aber dokumentarische Pflicht verletzt |
|
||||
| §4.2 Alle-Pfad-Formen-Vermeidung (Punkt 4) | `/`-getrennt, relativ, unter `raw/` | `..`-Traversal, führendes `/`, Backslash (`raw\foo.md`), URL-Form (`https://…`) → Punkt 4 |
|
||||
@@ -124,7 +124,7 @@ Diese Instruktion ist auf die **Erzeugung neuer Concepts auf Root-Ebene** begren
|
||||
**Normreferenzen (read-only):**
|
||||
|
||||
- `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 7): §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).
|
||||
- `schema/validator.md` — Prüfgrundlage (Story 1.4, Revision 8): §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).
|
||||
- Architektur-Spine (raw/`architecture-spine`): AD-2/AD-3 (raw immutable), AD-5 (inkrementelle Kompilation), AD-6 (Reason/Mutate-Trennung), AD-7a (Identität = OKF-Pfad ohne `.md`), AD-10 (agent-unabhängige Regeln), AD-11 (keine eigene Runtime), AD-15 (Trust-Metadaten v1), 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), A-4 (nur lokale Sources).
|
||||
- Epics (raw/epics): Story-2.1-Ziel und -Abgrenzung zu Story 2.2–2.5.
|
||||
@@ -135,3 +135,4 @@ Diese Instruktion ist auf die **Erzeugung neuer Concepts auf Root-Ebene** begren
|
||||
- **Revision 1.1 (2026-08-16):** Nach dem Demonstrationslauf ergänzt — §6.5 Determinismus- & Selbsttest-Norm (drei Nachprüf-Kriterien: §3-Subset-Konformität, `at`-Normalform, `sources`-Existenz; AD-17h-konform) und §6.6 Positiv-/Negativ-Beispiele (Referenztabellen je Erzeugungsregel mit deterministischer Fehlerursache). Revisionslog (§8) nachgeführt; §6-Nummerierung angepasst.
|
||||
- **Revision 1.2 (2026-08-16, Step-04-Review):** Nachschärfungen aus dem Story-2.1-Review — Input-Regel korrekt auf AD-17a statt AD-17.2 referenziert (§1); `sources`-Eintrag-Key-Subset (Innen-Ebene, Vertrag §3.3) in §4.2 und als §6.5-Kriterium-1 / §6.6-Tabellenzeile ergänzt; `status`-Absenz-Formulierung an die Vertrags-Definition (Absenz = `stable`, §3.6) angebunden (§4.4); Klarstellung Bereichs-Ziele bis Story 2.4 (§5.1/§6.6); §6.6-Fehlerursache der `verified`-Zeile auf Punkt 6 korrigiert; §6.6-Referenzlabel von §4.5 auf §4.4 korrigiert; §6.6 um vollständige Punkt-4-Pfad-Verbote ergänzt; AD-17f als Commit-Boundary in §0/§5.3/§6.6 sichtbar gemacht.
|
||||
- **Revision 1.3 (2026-08-16, bmad-code-review Story 2.1):** Nachschärfungen aus dem Review-Patch-Block — §1-Überschrift ins Deutsche („Input (was der Compiler konsumiert)"); Prüfgrundlagen-Referenz auf `validator.md` Revision 7 angeglichen (§0-Header, §8); §6.6 canonical-Key-Reihenfolge-Zeile von der ✗-Liste auf reine ✓-Vorgabe korrigiert (kein Validator-FAIL, Normalform ohne §7-Punkt) und das irreführende „§6.4"-Label auf §4.2 berichtigt; §1.2 vs. §1.4-Evidenz-Widerspruch aufgelöst (§1.2 präzisiert auf verarbeitbare Evidenz, §1.4 Artefakt-Ausnahme als dokumentarische Konvention der Source-Bereitstellung nach `raw/README.md` gekennzeichnet).
|
||||
- **Revision 1.4 (2026-08-17, bmad-code-review Re-Run Story 2.1, Stand nach Validator-Rev-8):** Nachschärfungen aus dem unabhängigen Re-Review — Prüfgrundlagen-Referenz auf `validator.md` Revision 8 angehoben (§0-Header, §8); §6.6-Referenzlabels berichtigt (canonical Key-Reihenfolge, Duplikat-Keys, `okf_version`/`type: bundle` → §4.5, `sources`-Eintrag-Key-Subset → §4.2; berichtigt die Rev-1.2-Korrektur, die das Label fälschlich von §4.5 auf §4.4 bewegt hatte); §1.4 „Aufträge" → „Formate", §5.2 „grossen" → „großen"; §3.2 Kollision-Hold um Run-Fortsetzung mit den übrigen Einheiten und Gesamt-Run-Status („teilweise erfolgreich") ergänzt; §5.3/§6.3 um explizite Rollback-Sequenz für den Teilzustand (Concept-Datei + Index-Verlinkung + `log.md`-Eintrag) bei Validierungs-FAIL ergänzt.
|
||||
|
||||
@@ -13,6 +13,7 @@ Hier startet die progressive Discovery (AD-9): von dieser Bundleroot führt der
|
||||
wiki/
|
||||
index.md
|
||||
log.md
|
||||
<concept>.md (Root-Concepts, z. B. llm-wiki-prinzip.md)
|
||||
|
||||
<area>/
|
||||
index.md
|
||||
|
||||
+4
-2
@@ -1,11 +1,13 @@
|
||||
# Log
|
||||
|
||||
## 2026-08-17
|
||||
- **Story 2.1 «Concepts aus Source Material erzeugen (OKF-Konform)» → `done` (Human-Review-Freigabe erteilt):** Nutzer hat die verbleibende Schwelle (menschliche Review-Freigabe) überschritten — Status `review` → `done`, `sprint-status.yaml` nachgeführt. Alle 8 ACs PASS, kein AC-/Vertrags-Blocker; offene Folge-Arbeit (autorisierte Validator-Rev 9) ist kein Story-2.1-Blocker und bleibt als Action-Item `code-review-2-1-item-2` in `deferred-work.md` verankert.
|
||||
- bmad-code-review Re-Run Story 2.1 (unabhängig, 4 Layer, Stand nach Validator-Rev-8): alle 8 ACs PASS, 17 Patch / 4 Defer / 2 Dismiss. 15 Patches umgesetzt — `schema/compiler.md` → Revision 1.4 (Prüfgrundlage Rev 8, §6.6-Referenzlabels §4.5/§4.2, §3.2 Kollision-Hold-Run-Fortsetzung, §5.3/§6.3 Rollback-Sequenz, Sprachkorrekturen), `wiki/log.md` (verlorener Bullet, Rev-8-Datum 08-17), `wiki/index.md` (Baumdiagramm um Root-Concepts-Ebene), Doku-/Referenz-Konsistenz (`deferred-work.md` Dedupe + n=21, `review-input-dryrun-…md` 16+2-Auflösung, `epic-2-context.md` AD-4c tautologisch, spec Verification/Change-Log, `sprint-status.yaml` closed-Datum). 2 Patches auf der gefrorenen `validator.md` (Rev 8) geholdert → nächste autorisierte Validator-Revision (Rev 9: Punkt-4-Grammatik `resolved=`-Token, Innen-Ebenen-Punkt-6-Fixture-Zeile; s. `deferred-work.md`).
|
||||
- **Story 2.1 «Concepts aus Source Material erzeugen (OKF-Konform)» → `review` (Freigabe zur Human-Review):** Option-A-Voraussetzung erfüllt — autorisierte Validator-Revision 8 ausgeführt und zertifiziert (s. Eintrag 2026-08-16). `spec-2-1-…`-Re-Review-Verdikt aktualisiert: Story ist `done`-fähig; einzige verbleibende Schwelle ist die menschliche Review-Freigabe (`review` → `done`). Action-Item `code-review-2-1-item-1-autorisierte-validator-revision-option` → `done` (Autorisations-Runde: `validator-revision-8-autorisationsrunde-f14-innen-ebenen.md`). `sprint-status.yaml`: Story 2.1 → `review`.
|
||||
|
||||
## 2026-08-16
|
||||
- Autorisierte Validator-Revision 8 (Option-A-Heilung Story 2.1): `schema/validator.md` Revisionslog-Eintrag „Revision 8" + Header-Revisionszahl auf 8 angehoben (behebt OBS-1: Header „Revision 6" vs. Log „Revision 7"). Drei Änderungen: (1) F-14-Negativ-Fixture 4a in §7.1 (Punkt 4: `resource: README.md` außerhalb `raw/`, existierend → `FAIL … Punkt 4`; Retrospective F-14); (2) Innen-Ebenen-Key-Subset formalisiert — Punkt-6-Zelle verweist auf die §7.3-Isolations-Notiz (autorisiert, Revision 8); (3) Revisionslog nachgeführt. Vertrag `schema/wiki-compiler.md` und `schema/compiler.md` unverändert (keine neue §7-Invaliditätsklasse). Zertifizierung selbstgeprüft: Fixture 4a isoliert → FAIL Punkt 4 (resolved=README.md) (Punkt 3 nicht verletzt, keine anderen Punkte); Innen-Ebenen-Sample (`sources`-Eintrag mit `role: x` bei existierender `raw/`-Datei) → FAIL Punkt 6 (Key=role); reales Bundle (5 `wiki/`-Dateien) → SUCCESS (keine neu ausgelösten FAILs).
|
||||
`schema/compiler.md` auf Revision 1.3 — §1-Überschrift ins Deutsche, Prüfgrundlage auf validator.md Revision 7 angeglichen, §6.6-canonical-Reihenfolge-Zeile von ✗- auf reine ✓-Vorgabe korrigiert (kein Validator-FAIL, Label §4.2 statt „§6.4"), §1.2/§1.4-Evidenz-Widerspruch aufgelöst (Artefakt-Ausnahme als dokumentarische Konvention). `wiki/log.md`-Demonstrationslauf-Einträge an Vertrags-§5-Format angeglichen (`- neu:` … angelegt (sources: …)). Story 2.1 bleibt `in-progress` (Option A: Heilung der validator.md-Rev-7-Klarstellung über die nächste autorisierte Validator-Revision).
|
||||
- Autorisierte Validator-Revision 8 (Option-A-Heilung Story 2.1, ausgeführt 2026-08-17): `schema/validator.md` Revisionslog-Eintrag „Revision 8" + Header-Revisionszahl auf 8 angehoben (behebt OBS-1: Header „Revision 6" vs. Log „Revision 7"). Drei Änderungen: (1) F-14-Negativ-Fixture 4a in §7.1 (Punkt 4: `resource: README.md` außerhalb `raw/`, existierend → `FAIL … Punkt 4`; Retrospective F-14); (2) Innen-Ebenen-Key-Subset formalisiert — Punkt-6-Zelle verweist auf die §7.3-Isolations-Notiz (autorisiert, Revision 8); (3) Revisionslog nachgeführt. Vertrag `schema/wiki-compiler.md` und `schema/compiler.md` unverändert (keine neue §7-Invaliditätsklasse). Zertifizierung selbstgeprüft: Fixture 4a isoliert → FAIL Punkt 4 (resolved=README.md) (Punkt 3 nicht verletzt, keine anderen Punkte); Innen-Ebenen-Sample (`sources`-Eintrag mit `role: x` bei existierender `raw/`-Datei) → FAIL Punkt 6 (Key=role); reales Bundle (5 `wiki/`-Dateien) → SUCCESS (keine neu ausgelösten FAILs).
|
||||
- `schema/compiler.md` auf Revision 1.3 — §1-Überschrift ins Deutsche, Prüfgrundlage auf validator.md Revision 7 angeglichen, §6.6-canonical-Reihenfolge-Zeile von ✗- auf reine ✓-Vorgabe korrigiert (kein Validator-FAIL, Label §4.2 statt „§6.4"), §1.2/§1.4-Evidenz-Widerspruch aufgelöst (Artefakt-Ausnahme als dokumentarische Konvention). `wiki/log.md`-Demonstrationslauf-Einträge an Vertrags-§5-Format angeglichen (`- neu:` … angelegt (sources: …)). Story 2.1 bleibt `in-progress` (Option A: Heilung der validator.md-Rev-7-Klarstellung über die nächste autorisierte Validator-Revision).
|
||||
- Step-04-Review (Story 2.1): Nachschärfungen aus den drei Review-Layern (Blind Hunter, Edge Case Hunter, Verification Gap) angewendet — `schema/compiler.md` auf Revision 1.2 (Input-Regel auf AD-17a referenziert statt AD-17.2, `sources`-Eintrag-Key-Subset in §4.2/§6.5/§6.6 ergänzt, `status`-Absenz an Vertrag §3.6 angebunden, Bereichs-Ziel-Klarstellung bis Story 2.4, §6.6-Fehlerursachen korrigiert, AD-17f als Commit-Boundary sichtbar), `schema/validator.md` auf Revision 7 (§7.3-Isolations-Hinweis auf Innen-Ebenen-Key-Subset erweitert), `wiki/index.md`-Workspace-Absatz korrigiert (`schema/` = drei Artefakte: Vertrag, Validator, Compiler), `sprint-status.yaml`: Story 2.1 → `review` (Review begonnen). `at`-Zeitstempel der drei Concepts (`2026-08-16T09:23:33Z` = 11:23:33 Lokalzeit +0200) decken sich mit den Datei-Mutationszeitpunkten (11:24) — im Review geprüft.
|
||||
- neu: `llm-wiki-prinzip` angelegt (sources: raw/prd/prd-wow20-2026-08-14.md) — Root-Concept, Trust-Metadaten A0-20 (`generated { by: wow-compiler/0.1.0, at: <ISO-8601-Datetime> }`, `verified` ungesetzt)
|
||||
- neu: `knowledge-kompilation-inkrementell` angelegt (sources: raw/epics/epics-2026-08-14.md) — Root-Concept, Trust-Metadaten A0-20
|
||||
|
||||
Reference in New Issue
Block a user