wow20/_bmad-output/specs/spec-wow20/.memlog.md

topic, updated

topic	updated
Wiki of Wikis — Knowledge Compiler (LLM Wiki / OKF 0.2)	2026-08-14T18:10

• (capability) CAP-1 (FR-1) Sources bereitstellen: Nutzer kann dem Compiler ein oder mehrere Source-Materialien zur Verarbeitung bereitstellen, ohne die Wiki-Struktur vorher bestimmen zu müssen (v1: nur lokal bereitgestelltes Material, A-4). Success: Ein Compilation Run akzeptiert 1..n Sources; keine URL-Beschaffung im Compiler-Kern.
• (capability) CAP-2 (FR-2) Sources vs. Curated Knowledge unterscheiden: System hält Source Material und Knowledge Bundle physisch+semantisch getrennt (raw/ vs. wiki/). Success: Kopie eines Quelldokuments zählt nicht als Wissensintegration; Consumers können beide trennen.
• (capability) CAP-3 (FR-3) Provenienz bewahren: abgeleitetes Wissen bleibt auf Sources rückführbar; neue Quellen entfernen bestehende Provenienz nicht. Success: Jedes erzeugte/aktualisierte Concept referenziert seine zugrunde liegenden Sources (AD-4a); mehrere Contributing Sources dokumentierbar.
• (capability) CAP-4 (FR-4) Gegen bestehendes Wissen kompilieren: Ein Run berücksichtigt neues Source Material UND relevantes vorhandenes kuratiertes Wissen. Success: Bestehendes Wiki ist Input; erarbeitete Erkenntnisse müssen nicht aus Rohquellen neu aufgebaut werden.
• (capability) CAP-5 (FR-5) Concepts erzeugen: Compiler kann aus Source Material neue eigenständige Wissenseinheiten erzeugen. Success: Neues Concept; mehrere Abschnitte einer Source können in unterschiedliche Concepts fließen; nicht an Source-Struktur gebunden.
• (capability) CAP-6 (FR-6) Bestehende Concepts aktualisieren: Compiler kann vorhandene Concepts erweitern/präzisieren/korrigieren. Success: Neue Informationen führen nicht automatisch zu neuen Dateien; Beziehungen+Provenienz bleiben soweit gültig erhalten.
• (capability) CAP-7 (FR-7) Wissen synthetisieren: Compiler führt mehrere Sources zu einer gemeinsamen Wissensrepräsentation zusammen (Wissensstand, nicht Aneinanderreihung). Success: Mehrere Sources zum selben Thema enden nicht in getrennten Zusammenfassungen; Redundanz konsolidiert; relevante Provenienz übernommen.
• (capability) CAP-8 (FR-8) Widersprüche sichtbar behandeln: widersprüchliche Informationen werden nie stillschweigend zu einer eindeutigen Aussage verschmolzen. Success: Relevante Widersprüche bleiben in log.md als explizite Disagreements erhalten (AD-16a Bewahrung als Default); Quellen nachvollziehbar; Unsicherheit darf Teil eines Concepts sein.
• (capability) CAP-9 (FR-9) OKF-konforme Concepts: alle erzeugten Concepts entsprechen OKF 0.2 (Markdown+YAML, type Pflichtfeld, optionale sources/generated/verified/status/stale_after). Success: Bundle validiert gegen schema/wiki-compiler.md; kein eigener OKF-Dialekt.
• (capability) CAP-10 (FR-10) Concepts verlinken: Compiler drückt Beziehungen mit normalen Markdown-Links aus (eine gepinnte Form, AD-7b). Success: Verlinkte Concepts navigierbar; Consumer brauchen keine proprietäre Software; Traversal durch Agenten möglich.
• (capability) CAP-11 (FR-11) Progressive Discovery: Consumer können Wissen schrittweise entdecken ohne alles zu lesen, über Hierarchie+index.md. Success: Übersicht zuerst, dann relevante Concepts öffnen; keine proprietäre Datenbank für Navigation nötig.
• (capability) CAP-12 (FR-12) Inkrementelle Weiterentwicklung: Ein Run entwickelt ein bestehendes Bundle weiter, statt ein unabhängiges Wiki neu zu erzeugen. Success: Unverändertes Wissen bleibt erhalten; Änderungen konzentrieren sich auf betroffene Concepts (AD-5).
• (capability) CAP-13 (FR-13) Menschliche Kuratierung berücksichtigen: manuell gepflegte Inhalte bleiben bestehendes Wissen; bei Konflikt erkennbar. Success: Run entfernt menschl. Ergänzungen nicht wegen fehlender Herkunft; Human-reviewed unterscheidbar von ungeprüft maschinellem (AD-15, generated/verified mit human:-Präfix); Mensch kann direkt editieren (FT-9).
• (capability) CAP-14 (FR-14) Änderungen nachvollziehbar: Änderungen erfolgen an textuellen Artefakten, Git-Diff zeigt fachliche Veränderungen. Success: Git-Diff unterscheidbar; keine proprietäre Änderungsverfolgung; Commit-Boundary als Mutationsgrenze (AD-17f).
• (capability) CAP-15 (FR-15) Tool-unabhängiger Zugriff: Bundle ohne Wiki-of-Wikis-Runtime lesbar (Menschen, LLM-Agenten, Standard-Dateioperationen). Success: Kein proprietäres SDK nötig; Markdown lesbar ohne Wiki-of-Wikis-spezifische Software (NFR-1/2/3/5).
• (capability) CAP-16 (FR-16) Consumer entkoppeln: Bundle nicht auf einen bestimmten LLM-Agenten/Workflow zugeschnitten. Success: BMAD/Claude/Codex/zukünftige Agenten können Consumer sein; Wechsel des Consumers erfordert keine Migration des Wissensformats (AD-10).
• (constraint) Constraint: OKF 0.2 ist der normative Format-Standard (Markdown+YAML-Frontmatter, type Pflichtfeld, optionale sources/generated/verified[human:]/status/stale_after); kein eigener OKF-Dialekt; Bundle-Root = wiki/, okf_version nur in Bundleroot-index.md (AD-1, AD-1a).
• (constraint) Constraint: Kanonischer persistenter Zustand = Git-versioniertes OKF-Knowledge-Bundle; abgeleitete Indizes/Caches/Embeddings sind rebuildable, niemals Source of Truth (AD-1/AD-14).
• (constraint) Constraint: Separation-of-Concerns — Sources → Compilation → Knowledge Bundle → Consumers; Consumer nicht Voraussetzung für Compilation; Source nicht automatisch Teil des Curated Knowledge (AD-2, AD-12).
• (constraint) Constraint: Source-Material immutable (AD-3); Copieren nach wiki/ ist keine Compilation; Relevanzbestimmung textuell-deterministisch (grep/link-traversal), keine Embedding/Vector-Infrastruktur (AD-13, AD-17-Anhang).
• (constraint) Constraint: Provenienz claim-granular; sources-Einträge zeigen nie auf wiki/-Pfade (AD-4a/4b/4c); generiertes Concept nie als alleinige Provenienz eines anderen.
• (constraint) Constraint: Compilation inkrementell (AD-5), Reasoning von Mutation getrennt (AD-6); Concept-ID = OKF-Pfad (AD-7/7a); Konflikte explizit bewahrt, nie still aufgelöst (AD-16/16a/16b).
• (constraint) Constraint: Koordination — lease/branch-basierte Workspace-Konvention, kein textueller Auto-Merge über denselben Concept-Pfad, Root-Scope inkl. log.md und index.md, Dirty-Tree-Schutz, Commit-Boundary als Mutationsgrenze, Determinismus-Kontrakt (AD-17a..h).
• (constraint) Constraint: Kein eigener Serverprozess/eigene LLM-Runtime im MVP (AD-11); agent-unabhängiger Compiler-Contract, Adapter als dünne Hüllen (AD-10).
• (constraint) Constraint: Complexity Guardrail — neue Infrastruktur nur wenn für 'Sources + existing knowledge → improved curated knowledge' erforderlich, sonst Source/Consumer-Adapter (FT-8).
• (constraint) Constraint: (PRD-MVP) v1 kein URL-Abruf; lokal bereitgestelltes Source-Material; keine GUI; kein Block-until-Interaktion-Modell.
• (constraint) Non-goal: keine Vector-DB/Vector-Search/Knowledge-Graph-DB/MCP-Server/Web-UI/Wiki-Rendering-Server/automatische Internetrecherche/Webcrawler/Scheduling/Source-Beobachtung/BMAD- oder Claude-Code- oder CodeGraph-Integration/Multi-User-Rechte/Enterprise-Governance/konkurrierende Ontologie
• (constraint) Non-goal: Retrieval ist Consumer-Verhalten, nicht Kern des Wiki-Compilers (AD-13); Wiki of Wikis ist keine RAG-Plattform, kein CMS, keine Suchmaschine, kein Dokumentenarchiv, keine Obsidian/Confluence-Alternative
• (constraint) Success-Signal (Kern): 'Knowledge should compound' — kein erneutes Rekonstruieren erarbeiteter Synthese bei jeder Anfrage; Lauf 2 baut auf Lauf 1 auf (SM-1/FT-6); plus Proof-origin Weg raw/→wiki/ (SM-2).
• (constraint) Assumption: v1 persönlich/teaminternes Developer Tool (A-1); keine GUI (A-3); Source-Beschaffung nicht Kern, nur bereitgestelltes Material (A-4); BMAD/Claude/Codex/CodeGraph sind Sources/Consumers, keine Kernbestandteile (A-5).
• (constraint) Assumption: AD-4g dawikig; maschinell erzeugt+ungeprüft ist v1-Default (generated ohne verified); Human-Review via verified human:-Präfix; Chip in AD-15 ist Implementierung.
• (constraint) Open Question (PRD OQ-1/Spine): Sollen vollständig manuell erstellte Concepts first-class behandelt oder nur toleriert werden? (Trägt auf FR-13/CAP-13; in v1 toleriert gemäß AD-15.)
• (constraint) Open Question (PRD OQ-5/Spine Q-5): Was passiert mit abgeleitetem Wissen, wenn eine Source entfernt/ersetzt/als falsch erkannt wird? (D-5; Revocation-Fall undesignet.)
• (constraint) Open Question (PRD OQ-6/Spine Q-4): Produktname 'Wiki of Wikis' final oder nur Projektname? (Owner PM.)
• (constraint) Open Question (Spine Q-6): Determinismus-Durchsetzung ohne dedizierten Validator im MVP (D-3) — als Agent-Instruktion bis dahin.
• (assumption) Assumption (korrigiert, ersetzt die obige 'AD-4g'-Zeile): maschinell erzeugt+ungeprüft ist v1-Default (generated ohne verified, kein verified gesetzt); Human-Review via 'verified' mit human:-Präfix-Actor; die konkrete Umsetzung folgt AD-15/FR-9, Implementierung geschieht in schema/wiki-compiler.md (AD-1a).
• (decision) Decision: PRD wird als 'sources' vollständig absorbiert (frontmatter sources:); Architecture-Spine als adopted companion referenziert (AD-IDs 1-17 + Subrules bleiben stabil und zitierbar); Glossary als spec-authored companion.
• (event) Self-Validate Pass 1 (Coherence): alle 16 CAPs haben intent+success (Spec Law 1); intents sind WHAT (2); Constraints nützen echte Grenzen (3); Non-goals explizit (4); Success signal testbar (5); CAP-ID-1..16 stabil (6); lean prose (8).
• (event) Self-Validate Pass 2 (Preservation): FR-1..16/NFR-1..7, A-1..5, Non-Goals, Guardrails alle gelandet (SPEC kernel + companions + architecture spine). Wrapper-only: Sektionen 0/§2-Journeys/§12-Diagramm usw. sind narrative Kapseln, nicht load-bearing Einzel-Claims.