Add all BMAD skill artifacts: epics, stories, sprint-status, QA tests, project-context, readiness report

Co-authored-by: Kenearos <86194771+Kenearos@users.noreply.github.com>

_bmad-output/planning-artifacts/product-brief.md

@@ -0,0 +1,139 @@
+---
+stepsCompleted:
+  - step-01-init
+  - step-02-vision
+  - step-03-users
+  - step-04-metrics
+  - step-05-scope
+  - step-06-complete
+inputDocuments:
+  - README.md
+  - CLAUDE.md
+date: 2026-03-12
+author: Mary (BMAD Analyst Agent)
+bmadSkill: 'Analyst Agent (Mary) — /bmad-agent-bmm-analyst → [PB] Create Product Brief'
+bmadWorkflow: '_bmad/bmm/workflows/1-analysis/create-product-brief/workflow.md'
+---
+
+<!-- 📊 Generated by BMAD Analyst Skill — Agent: Mary (Business Analyst) -->
+<!-- Skill Command: /bmad-agent-bmm-analyst → Create Product Brief -->
+<!-- Workflow: _bmad/bmm/workflows/1-analysis/create-product-brief/workflow.md -->
+
+# Product Brief: CouncilOS (KI-Rat Baukasten)
+
+**Autor:** Mary (📊 BMAD Analyst Agent)
+**Datum:** 2026-03-12
+
+---
+
+## 1. Problem & Vision
+
+### Das Problem
+
+Wissensarbeiter verschwenden täglich Stunden damit, KI-Tools manuell zu dirigieren. Die aktuelle Interaktionsparadigma — ein Mensch, eine KI, eine lineare Konversation — ist für komplexe, mehrstufige Aufgaben fundamental ungeeignet.
+
+**Kernprobleme:**
+
+- **Qualitätslücke:** Einzelne KI-Antworten sind oft unzureichend; Nutzer müssen manuell iterieren.
+- **Expertise-Lücke:** Kein einzelnes KI-Modell ist in allen Domänen gleich stark.
+- **Transparenzlücke:** Nutzer sehen nicht, wie und warum die KI entscheidet.
+- **Kontroll-Lücke:** Unternehmenskritische Prozesse können nicht blind KI-Loops überlassen werden.
+
+### Die Vision
+
+**CouncilOS** ist eine visuelle No-Code-Plattform, auf der Nutzer spezialisierte KI-Agenten zusammenstellen, verbinden und als iterativen „Rat" ausführen — bis das Ergebnis die definierte Qualitätsschwelle erreicht.
+
+> „Nicht die KI denkt für dich. Du dirigierst ein Orchester aus KI-Experten."
+
+---
+
+## 2. Zielgruppen & Jobs-to-be-Done
+
+### Primäre Zielgruppe A: Content-Ersteller & Marketing
+
+| Job-to-be-Done | Schmerz | CouncilOS-Lösung |
+|----------------|---------|------------------|
+| Hochwertigen Content produzieren | Stundenlange manuelle Prompt-Iteration | Automatische Critic→Master-Schleifen |
+| SEO-konforme Texte erstellen | Vergisst SEO-Regeln in langen Sessions | Dedizierter SEO-Kritiker-Agent |
+| Brand-Voice sicherstellen | KI weicht vom Stil ab | System-Prompt pro Agent |
+
+### Primäre Zielgruppe B: Software-Entwickler
+
+| Job-to-be-Done | Schmerz | CouncilOS-Lösung |
+|----------------|---------|------------------|
+| Code reviewen und verbessern | Review kostet Senior-Zeit | Architekt-KI + Tester-KI-Schleife |
+| Tests und Docs generieren | Vergessen oder aufwendig | Doku-KI als Terminal-Node |
+
+### Sekundäre Zielgruppe: Analysten & Researcher
+
+| Job-to-be-Done | Schmerz | CouncilOS-Lösung |
+|----------------|---------|------------------|
+| Lange PDFs zusammenfassen | Zeitaufwendig und subjektiv | PDF-Reader-Tool + Analyse-Kette |
+
+---
+
+## 3. Markt & Wettbewerb
+
+| Wettbewerber | Stärke | Schwäche vs. CouncilOS |
+|-------------|--------|------------------------|
+| ChatGPT / Claude (direkt) | Bekannt, einfach | Keine Zyklen, kein Multi-Agent |
+| LangChain | Entwickler-Framework | Kein No-Code, keine visuelle UI |
+| AutoGen (Microsoft) | Multi-Agent | Keine visuelle Canvas-UI |
+| Zapier AI | No-Code-Automatisierung | Kein iteratives Schleifen-Paradigma |
+| Make / n8n | Workflow-Automation | Kein KI-nativer Iteration-Loop |
+
+**Differenzierungsmoment:** CouncilOS ist das einzige Tool, das zyklische Multi-Agenten-Pipelines visuell (No-Code) aufbaubar und kontrollierbar macht.
+
+---
+
+## 4. Erfolgsmetriken (SMART)
+
+| Metrik | Zielwert | Messzeitraum | Messmethode |
+|--------|----------|--------------|-------------|
+| Zeit bis erstem Council-Run | < 5 Minuten | First-Run | Timestamp-Telemetrie |
+| Durchschnittlicher Critic-Score | ≥ 8/10 | Pro Run | Aggregierte Critic-Scores |
+| God-Mode-Nutzungsrate | ≥ 20% aller Runs | Monatlich | Run-Statistik |
+| API-Fehlerrate | < 1% | Wöchentlich | Error-Logging |
+| Gleichzeitige Runs (Skalierbarkeit) | ≥ 10 | Load-Test | Performance-Test |
+
+---
+
+## 5. Scope (MVP → Enterprise)
+
+### In-Scope (MVP — Phasen 1–4)
+
+- ✅ Visueller Canvas mit Drag & Drop (React Flow)
+- ✅ Agent-Konfiguration: Name, System-Prompt, LLM-Modell, Tools
+- ✅ Lineare und bedingte Edges
+- ✅ Blueprint-Speicherung (PostgreSQL JSONB)
+- ✅ Council-Ausführung (Auto-Pilot + God Mode)
+- ✅ WebSocket-Live-Updates
+- ✅ Tavily Web-Suche als Agent-Tool
+- ✅ PDF-Upload + ChromaDB-Suche als Agent-Tool
+
+### Out-of-Scope (Post-MVP)
+
+- ❌ Nutzer-Authentifizierung (Auth0 / JWT)
+- ❌ Multi-User / Team-Collaboration
+- ❌ Kostenkontrolle per LLM-Aufruf
+- ❌ Mobile UI
+- ❌ Lokale LLM-Anbindung (Ollama)
+- ❌ Versionsverwaltung für Blueprints (Git-ähnlich)
+
+---
+
+## 6. Technische Kernannahmen
+
+1. **LangGraph** ist das nicht-verhandelbare Herzstück — alle anderen Frameworks werden nach diesen Anforderungen gewählt.
+2. **Zyklen First** — Die Architektur muss echte Loops unterstützen; DAG-Vereinfachungen sind verboten.
+3. **State als einzige Wahrheitsquelle** — `CouncilState` TypedDict wird zwischen allen Agents geteilt.
+4. **API-Keys bleiben server-seitig** — Kein Frontend-LLM-Aufruf; alle LLM-Calls laufen im Backend.
+
+---
+
+## 7. Nächster Schritt
+
+→ **PM Agent John** erstellt auf Basis dieses Briefs das vollständige PRD.
+→ Dann: **Architect Agent Winston** entwirft die Systemarchitektur.
+→ Dann: **UX Designer Agent** erstellt das UI-Design.
+→ Dann: **PM Agent John** zerlegt in Epics & Stories.