feat: kanonischen Workspace-Stamm erstellen (Story 1.1)
- raw/ wiki/, schema/, adapters/ als Architekturgrenzen angelegt (AD-2, AD-3, AD-10) - OKF-Bundleroot wiki/index.md mit type: bundle und okf_version: "0.2" (AD-1) - Reserviertes wiki/log.md (leer) als Protokoll- und Lease-Root-Scope-Bestandteil - Platzhalter schema/wiki-compiler.md (Story 1.3) und adapters/claude (Story 5.3) - Orientierungs-READMEs, .gitignore fuer IDE/OS-Cruft - Sprint-Status Story 1.1 auf review, Epic 1 auf in-progress - Spec-Trace + Epic-1-Kontext generiert Co-Authored-By: Claude <noreply@anthropic.com>
This commit is contained in:
Michael Tamse
@@ -0,0 +1,39 @@
|
||||
# Epic 1 Context: Wissens-Workspace & Quellen-Aufnahme
|
||||
|
||||
<!-- Compiled from planning artifacts. Edit freely. Regenerate with compile-epic-context if planning docs change. -->
|
||||
|
||||
## Goal
|
||||
|
||||
Der Nutzer richtet den kanonischen, Git-versionierten Wissens-Workspace ein und stellt dem Compiler Sources bereit. Der Workspace zerlegt die vier Verantwortungsbereiche physisch und semantisch: `raw/` (immutable Source Material / Evidenz), `wiki/` (kuratiertes OKF-Knowledge Bundle), `schema/` (verbindlicher OKF-Schema-Vertrag) und `adapters/` (dünne agenten-spezifische Instruktionen, außerhalb des Bundles). Eine Datei unter `raw/` ist Evidenz, eine Datei unter `wiki/` ist abgeleitete Wissensrepräsentation — das bloße Kopieren eines Quell-Dokuments zählt nicht als Wissensintegration. Am Ende entsteht eine validierte Basis, in der jeder Compilation Run den kompletten Workspace inkrementell weiterentwickeln kann (AD-2, AD-3, AD-12, AD-1a, AD-1b).
|
||||
|
||||
## Stories
|
||||
|
||||
- Story 1.1: Kanonischen Workspace-Stamm erstellen
|
||||
- Story 1.2: Sources lokal unter `raw/` bereitstellen
|
||||
- Story 1.3: OKF-Schema-Vertrag `schema/wiki-compiler.md` autorisieren
|
||||
- Story 1.4: Schema-Validierung für Bundle implementieren
|
||||
|
||||
## Requirements & Constraints
|
||||
|
||||
- Der Nutzer kann eine oder mehrere Sources (1..n) bereitstellen, ohne vorab die Wiki-Struktur entscheiden zu müssen; v1 akzeptiert nur lokal materialisiertes Source Material — URL-Abrufe werden als nicht unterstützt zurückgewiesen (FR-1, A-4).
|
||||
- Die Phasen "bereitgestelltes Source Material" und "Curated Knowledge" sind eindeutig unterscheidbar; ein Quell-Dokument wird nie automatisch zum Concept und eine Kopie unter `wiki/` ist keine erfolgreiche Kompilation (FR-2).
|
||||
- Ein Compilation Run verändert bestehendes Source Material niemals — `raw/` bleibt immutable; neue Source-Versionen sind neue/versionierte Sources (AD-3). Ein fehlgeschlagener Run lässt `raw/` unangetastet.
|
||||
- Der Workspace ist als normale Git-Working-Copy portabel: nach `git clone` liegt `raw/` + `wiki/` + Compiler-Vertrag bereit, kein Server und keine Datenbank erforderlich (NFR-1, NFR-5). Mutiert wird textuell, damit Git-Diffs fachlich aussagekräftig bleiben (NFR-4, AD-14).
|
||||
- Das Lesen/Bearbeiten des Bundles setzt generell keine Wiki-of-Wikis-Runtime voraus — Standard-Markdown-Werkzeuge und Dateioperationen genügen (FR-15, NFR-2, NFR-3).
|
||||
- Es gibt keine GUI in v1: der gesamte Workflow ist datei-/CLI-basiert (A-3).
|
||||
|
||||
## Technical Decisions
|
||||
|
||||
- **Struktur (Seed):** `raw/` (inkl. optionalem `assets/`), `wiki/`, `schema/wiki-compiler.md`, `adapters/<agent>/`. Nur `wiki/` ist Bundleroot des OKF Bundles; `raw/`, `schema/`, `adapters/` liegen außerhalb des Bundles und sind keine Concept-Dateien (AD-2, AD-10).
|
||||
- **Bundle und Fundament:** Bundleroot `wiki/index.md` mit Frontmatter `type: bundle` und `okf_version: "0.2"`; leere Protokolldatei `wiki/log.md`. Area-Verzeichnisse innerhalb von `wiki/` folgen dem Muster `<area>/index.md` + `<concept>.md` (AD-1, AD-9).
|
||||
- **Schema-Vertrag (AD-1a, A0-1):** `schema/wiki-compiler.md` bindet verbindlich das erlaubte OKF-0.2-Feldsubset — `type` als einziges Pflichtfeld; optional `sources`, `generated`, `verified`, `status`, `stale_after`; festgelegt werden Liste-vs.-Map-Form von `sources`, Zulässigkeit von `generated`/`verified` und `status`-Policing — dazu die Typdefinition von `log.md`, die Index-Regel (jedes Area hat eine `index.md`) und Validitätsprädikate für Concepts und Bundle-Root.
|
||||
- **Provenienz-Grenze (AD-4b, A0-4):** `sources`-Einträge lösen ausschließlich auf `raw/`-Pfade oder extern referenzierte immutable Evidenz auf — nie auf `wiki/`-Concept-Pfade; das Schema bindet dieses Verbot.
|
||||
- **Validierung (F-2/AD-1b, A0-2):** Vor jeder Mutation wird das Bundle gegen `schema/wiki-compiler.md` geprüft; ein strukturell OKF-invalides Bundle (z.B. fehlender `type`) schlägt den gesamten Run fehl, fehlende optionale Felder gelten nicht als invalide. Die Validierung ist eine eigenständige, deterministische, ohne LLM-Urteil aufrufbare Prüfung (AD-13/AD-17h-konform).
|
||||
- **Kein eigener OKF-Dialekt / kein eigenes Schema neben OKF (AD-1);** `adapters/` dürfen keine abweichende Knowledge-Semantik definieren, nur agenten-spezifische Ausführung (AD-10).
|
||||
|
||||
## Cross-Story Dependencies
|
||||
|
||||
- Alle späteren Epics (Concept-Erzeugung, Kompilation, Wissenstreue, Consumer-Zugriff) setzen die hier etablierte Workspace-Trennung, die Bundle-Root und den Schema-Vertrag voraus.
|
||||
- Der Schema-Vertrag aus Story 1.3 ist die Eingabe für die Validierung in Story 1.4 und definiert zugleich die Feld-Subset-Basis, auf der Epic 2 OKF-konforme Concepts produziert.
|
||||
- Die Immutability von `raw/` (Story 1.2) ist die Recovery-Basis für Leasing-/Stale-Szenarien späterer Epics (AD-17d).
|
||||
- Keine UX/Design-Anteile relevant für diesen Epic: v1 ist datei-/CLI-basiert ohne GUI (A-3, AD-11).
|
||||
+43
@@ -0,0 +1,43 @@
|
||||
---
|
||||
title: 'Kanonischen Workspace-Stamm erstellen (Story 1.1)'
|
||||
type: 'feature'
|
||||
created: '2026-08-14'
|
||||
status: 'done'
|
||||
route: 'one-shot'
|
||||
review_loop_iteration: 0
|
||||
context:
|
||||
- _bmad-output/implementation-artifacts/epic-1-context.md
|
||||
---
|
||||
|
||||
## Intent
|
||||
|
||||
**Problem:** Das Projekt besitzt noch keinen kanonischen Wissens-Workspace; Source Material und kuratiertes Knowledge Bundle sind nicht physisch/semantisch getrennt.
|
||||
|
||||
**Approach:** Den Workspace-Stamm `raw/ | wiki/ | schema/ | adapters/` als Git-versionierte Seed anlegen, mit OKF-Bundleroot `wiki/index.md` (`type: bundle`, `okf_version: "0.2"`), leerem `wiki/log.md` und Platzhaltern für Schema-Vertrag und Adapter.
|
||||
|
||||
## Suggested Review Order
|
||||
|
||||
**Workspace-Trennung & Einstieg**
|
||||
|
||||
- Bundleroot mit `okf_version: "0.2"` und Frontmatter-Regel — Einstiegspunkt der Discovery
|
||||
[`index.md`](../../wiki/index.md#L1)
|
||||
|
||||
- OPF-README: Area, Platzhalter mit Verweis auf Story 1.3
|
||||
[`wiki-compiler.md`](../../schema/wiki-compiler.md#L1)
|
||||
|
||||
- Dünne-Adapter-Konvention (AD-10), Multi-Adapter-Layout dokumentiert
|
||||
[`README.md`](../../adapters/README.md#L1)
|
||||
|
||||
- Claude-Adapter-Platzhalter (Story 5.3 hält den Rest)
|
||||
[`README.md`](../../adapters/claude/README.md#L1)
|
||||
|
||||
- Immutability & Evidenz-Grenze von `raw/` inkl. Artefakt-Carve-out
|
||||
[`README.md`](../../raw/README.md#L1)
|
||||
|
||||
**Peripherie**
|
||||
|
||||
- Root-Orientierung über alle vier Verzeichnisse
|
||||
[`README.md`](../../README.md#L1)
|
||||
|
||||
- IDE-/OS-Ignore-Regeln
|
||||
[`.gitignore`](../../.gitignore#L1)
|
||||
@@ -0,0 +1,75 @@
|
||||
# STATUS DEFINITIONS:
|
||||
# ==================
|
||||
# Epic Status:
|
||||
# - backlog: Epic not yet started
|
||||
# - in-progress: Epic actively being worked on
|
||||
# - done: All stories in epic completed
|
||||
|
||||
# Story Status:
|
||||
# - backlog: Story only exists in epic file
|
||||
# - ready-for-dev: Story file created, ready for development
|
||||
# - in-progress: Developer actively working on implementation
|
||||
# - review: Implementation complete, ready for review
|
||||
# - done: Story completed
|
||||
|
||||
# Retrospective Status:
|
||||
# - optional: Can be completed but not required
|
||||
# - done: Retrospective has been completed
|
||||
|
||||
# Action Item Status:
|
||||
# - open: Committed during a retrospective, not yet addressed
|
||||
# - in-progress: Actively being worked on
|
||||
# - done: Completed
|
||||
|
||||
# WORKFLOW NOTES:
|
||||
# ===============
|
||||
# - Epic transitions to 'in-progress' automatically when its first story starts (via build's sprint sync)
|
||||
# - Stories can be worked in parallel if team capacity allows
|
||||
# - Developer typically creates the next story after the previous one is 'done' to incorporate learnings
|
||||
# - 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-14-2026 19:42
|
||||
project: wow20
|
||||
project_key: NOKEY
|
||||
tracking_system: file-system
|
||||
story_location: D:/mita/wow-2nd/_bmad-output/implementation-artifacts
|
||||
development_status:
|
||||
epic-1: in-progress
|
||||
1-1-kanonischen-workspace-stamm-erstellen: review
|
||||
1-2-sources-lokal-unter-raw-bereitstellen: backlog
|
||||
1-3-okf-schema-vertrag-schema-wiki-compiler-md-autorisieren: backlog
|
||||
1-4-schema-validierung-für-bundle-implementieren: backlog
|
||||
epic-1-retrospective: optional
|
||||
|
||||
epic-2: backlog
|
||||
2-1-concepts-aus-source-material-erzeugen-okf-konform: backlog
|
||||
2-2-claim-granulare-provenienz-dokumentieren: backlog
|
||||
2-3-concepts-verlinken-eine-erlaubte-linkform: backlog
|
||||
2-4-deterministische-bereichszuordnung-concept-hierarchie: backlog
|
||||
2-5-progressive-discovery-über-index-md-bereitstellen: backlog
|
||||
epic-2-retrospective: optional
|
||||
|
||||
epic-3: backlog
|
||||
3-1-inkrementellen-datenfluss-implementieren-interpret-reconcile: backlog
|
||||
3-2-relevanzbestimmung-textual-deterministisch-umsetzen-grep-rip: backlog
|
||||
3-3-bestehende-concepts-erweitern-präzisieren-korrigieren: backlog
|
||||
3-4-wissen-aus-mehreren-sources-synthetisieren: backlog
|
||||
3-5-leasing-dirty-tree-schutz-für-konkurrierende-producer-umsetz: backlog
|
||||
3-6-lease-staleness-recovery-basis-absichern: backlog
|
||||
3-7-reason-mutate-trennung-und-konsistenz-endzustand-sicherstell: backlog
|
||||
3-8-determinismus-vertrag-ad-17h-als-agent-instruktions-validato: backlog
|
||||
epic-3-retrospective: optional
|
||||
|
||||
epic-4: backlog
|
||||
4-1-information-vor-jeder-änderung-klassifizieren-new-confirming: backlog
|
||||
4-2-disagreements-in-log-md-explizit-dokumentieren: backlog
|
||||
4-3-menschliche-kuratierung-respektieren-human-curation: backlog
|
||||
4-4-trust-metadaten-maschinell-vs-human-reviewed-unterscheiden: backlog
|
||||
epic-4-retrospective: optional
|
||||
|
||||
epic-5: backlog
|
||||
5-1-git-nachvollziehbare-änderungen-konsistenz-commit-boundary: backlog
|
||||
5-2-tool-unabhängigen-zugriff-und-agent-lesbarkeit-gewährleisten: backlog
|
||||
5-3-agent-unabhängige-compiler-regeln-dünne-adapter: backlog
|
||||
epic-5-retrospective: optional
|
||||
Reference in New Issue
Block a user