Initial Commit
This commit is contained in:
@@ -0,0 +1,204 @@
|
||||
// Paperclip Agent-Konfigurationen für BMAD Phase 4 Automation
|
||||
// =============================================================
|
||||
// Drei Agents:
|
||||
// 1. PM-Supervisor — Planung, Routing, Reporting (kein Code)
|
||||
// 2. Dev-Worker — create-story + dev-story (starkes Code-Modell)
|
||||
// 3. QA-Engineer — code-review + retrospective (anderes Modell,
|
||||
// für adversariale Unabhängigkeit)
|
||||
//
|
||||
// Sprint Planning ist NICHT Teil der Automation. Der Operator führt
|
||||
// bmad-sprint-planning vorab manuell aus, sodass sprint-status.yaml
|
||||
// beim Workflow-Start bereits existiert.
|
||||
//
|
||||
// Hinweis: Das exakte Schema des opencode_local-Adapters kann je
|
||||
// Paperclip-Version variieren. Vor dem Einspielen einmal abfragen:
|
||||
// curl -sS "$PAPERCLIP_API_URL/llms/agent-configuration/opencode_local.txt" \
|
||||
// -H "Authorization: Bearer $PAPERCLIP_API_KEY"
|
||||
// ==============================================================================
|
||||
|
||||
// ------------------------------------------------------------------------------
|
||||
// 1. PM-SUPERVISOR
|
||||
// ------------------------------------------------------------------------------
|
||||
{
|
||||
"name": "PM Supervisor",
|
||||
"role": "supervisor",
|
||||
"title": "BMAD Phase 4 Orchestrator",
|
||||
"icon": "📋",
|
||||
"description": "Pflegt die BMAD-Phase-4-Task-Hierarchie, routet Tasks an Dev und QA, entscheidet über Retries bei Review-Fails, erzwingt Single-Epic-Sequenz und Single-Task-per-Agent. Führt keine BMAD-Skills aus.",
|
||||
|
||||
"adapterType": "process",
|
||||
"adapterConfig": {
|
||||
"adapter": "opencode_local",
|
||||
"cwd": "/srv/projects/<dein-projekt>",
|
||||
"sessionBehavior": "resume-or-new",
|
||||
// Supervisor BRAUCHT Session-Kontinuität – er versteht den Graphen
|
||||
// über mehrere Heartbeats hinweg. Resume sorgt dafür, dass er beim
|
||||
// nächsten Wake nicht vergessen hat, an welcher Story/Epic wir sind.
|
||||
|
||||
"env": {
|
||||
// Optional: explizites Modell-Pinning
|
||||
// "OPENCODE_MODEL": "<supervisor-modell-string>"
|
||||
},
|
||||
|
||||
"heartbeat": {
|
||||
// Event-Wakes (task_completed) bleiben aktiv.
|
||||
// ZUSÄTZLICH: Timer-Patrol alle 15 Minuten. Der Supervisor
|
||||
// inspiziert dabei den gesamten Task-Graphen und räumt Blocker
|
||||
// auf – siehe SKILL.md Abschnitt 6 "Patrol".
|
||||
//
|
||||
// 15 Minuten ist bewusst gewählt: häufig genug, um echte Hänger
|
||||
// innerhalb einer halben Stunde zu erkennen und zu beheben;
|
||||
// nicht so oft, dass eigene Race Conditions mit laufenden
|
||||
// Agent-Tasks entstehen oder Budget unnötig verbrannt wird.
|
||||
//
|
||||
// Anpassung: auf 300 (5 Min) wenn du aggressiver willst, auf
|
||||
// 1800 (30 Min) wenn du konservativer willst.
|
||||
"enabled": true,
|
||||
"intervalSec": 900
|
||||
}
|
||||
},
|
||||
|
||||
"runtimeConfig": {
|
||||
"maxTurns": 80,
|
||||
// 80 reichen für Bootstrap (Parsing, Task-Graph-Erstellung) und
|
||||
// normale Scheduling-Entscheidungen (<10 Turns pro Wake). Patrol-
|
||||
// Durchläufe liegen ebenfalls unter 20 Turns bei sauberem Graphen.
|
||||
|
||||
"timeoutMs": 900000
|
||||
// 15 Min. Bootstrap kann bei vielen Epics länger dauern; normale
|
||||
// Scheduling-Calls sind in <1 Min durch.
|
||||
},
|
||||
|
||||
"desiredSkills": [
|
||||
"monitor-bmad-progress"
|
||||
],
|
||||
|
||||
"prompt": "Du bist der PM-Supervisor einer BMAD-V6-Phase-4-Automation mit getrennten Dev- und QA-Rollen. Folge strikt dem Skill 'monitor-bmad-progress'. Du führst keine BMAD-Skills selbst aus – du routest, koordinierst, patrouillierst, meldest. Du hast ZWEI Arten von Wakes: (1) Event-Wakes bei task_completed, dann normales Scheduling/Retry-Handling; (2) Timer-Wakes alle 15 Minuten, dann PATROL: gesamten Task-Graphen inspizieren, Blocker selbstständig auflösen (Stuck Tasks, Orphan Ready, verlorenes Ready-Setting, Duplikate, Leerlauf). Erzwinge die drei Concurrency-Policies aus dem Skill (Single-Epic-Sequenz, Single-Task-per-Agent, Strikte Story-Ordnung) bei jedem Ready-Setzen. Erzwinge die Idempotenz-Invariante bei jeder Task-Anlage: nie Tasks mit identischem Kompositschlüssel (type, epic_id, story_id, retry_count) doppelt anlegen. Respektiere Paperclips Execution-Contract: Starte actionable work im selben Heartbeat, stoppe nicht am Plan, hinterlasse durable progress, nutze Child-Issues statt Polling.",
|
||||
|
||||
"reportsTo": "<ceo-agent-id-oder-leer-falls-top-level>",
|
||||
"budget": {
|
||||
"monthlyUsd": 20
|
||||
}
|
||||
}
|
||||
|
||||
// ------------------------------------------------------------------------------
|
||||
// 2. DEV-WORKER
|
||||
// ------------------------------------------------------------------------------
|
||||
// Erzeugt Story-Dateien und implementiert Stories. Bei Retries nach
|
||||
// QA-Review-Fails landet auch die Retry-Implementierung hier.
|
||||
{
|
||||
"name": "Dev Worker",
|
||||
"role": "developer",
|
||||
"title": "BMAD Phase 4 Implementer",
|
||||
"icon": "💻",
|
||||
"description": "Führt create-story und dev-story aus. Implementiert in frischen OpenCode-Sessions (kein Context-Carryover). Bei Retries nach QA-Review-Fail arbeitet er die Findings ab.",
|
||||
|
||||
"adapterType": "process",
|
||||
"adapterConfig": {
|
||||
"adapter": "opencode_local",
|
||||
"cwd": "/srv/projects/<dein-projekt>",
|
||||
"sessionBehavior": "new",
|
||||
// BEWUSSTE Abweichung vom Default: fresh session pro Task.
|
||||
// Grund: BMAD-Workflow-Doku verlangt fresh chats, sonst leidet
|
||||
// die Qualität. Paperclip akzeptiert das als Setting.
|
||||
|
||||
"env": {
|
||||
"OPENCODE_MODEL": "<starkes-code-modell-wie-sonnet-oder-aehnlich>"
|
||||
// Konkret durch den Operator zu setzen. Ein starkes Code-Modell
|
||||
// ist hier richtig – dies ist der primäre Code-Produzent.
|
||||
},
|
||||
|
||||
"heartbeat": {
|
||||
"enabled": false
|
||||
// wake-on-assignment. Paperclip's Single-Task-Checkout sorgt
|
||||
// zusammen mit der Supervisor-Policy B dafür, dass nie zwei
|
||||
// Tasks gleichzeitig zugewiesen werden.
|
||||
}
|
||||
},
|
||||
|
||||
"runtimeConfig": {
|
||||
"maxTurns": 300,
|
||||
// Default von Paperclip. Passt für dev-story mit Test-Iteration;
|
||||
// für create-story wird das nicht ausgeschöpft.
|
||||
|
||||
"timeoutMs": 2700000
|
||||
// 45 Min. Für große Stories ggf. höher, für reine create-story
|
||||
// reicht es locker.
|
||||
},
|
||||
|
||||
"desiredSkills": [
|
||||
"execute-bmad-dev-tasks"
|
||||
],
|
||||
|
||||
"prompt": "Du bist der Dev-Worker in einer BMAD-V6-Phase-4-Automation. Folge strikt dem Skill 'execute-bmad-dev-tasks'. Du behandelst ausschließlich create-story und dev-story – alles andere weist du ab mit wrong_agent_type. Du arbeitest immer nur an einem Ticket zur selben Zeit. Respektiere Paperclips Execution-Contract: Starte actionable work im selben Heartbeat, stoppe nicht am Plan, leave durable progress mit clear next action, mark blocked work mit owner/action.",
|
||||
|
||||
"reportsTo": "<supervisor-agent-id>",
|
||||
"budget": {
|
||||
"monthlyUsd": 300,
|
||||
"perTaskUsdMax": 10
|
||||
}
|
||||
}
|
||||
|
||||
// ------------------------------------------------------------------------------
|
||||
// 3. QA-ENGINEER
|
||||
// ------------------------------------------------------------------------------
|
||||
// Code-Review nach jeder Story, Retrospective nach jedem Epic.
|
||||
// Bewusst ANDERES Modell als der Dev-Worker für adversariale
|
||||
// Unabhängigkeit. Kein Code-Schreiben, nur Prüfung und Dokumentation.
|
||||
{
|
||||
"name": "QA Engineer",
|
||||
"role": "qa",
|
||||
"title": "BMAD Phase 4 Reviewer & Retrospective Lead",
|
||||
"icon": "🔍",
|
||||
"description": "Führt code-review und retrospective aus. Bewusst anderes Modell als der Dev-Worker, um adversariale Unabhängigkeit zu gewährleisten. Schreibt keinen Code – nur Findings, Verdicts und Retros.",
|
||||
|
||||
"adapterType": "process",
|
||||
"adapterConfig": {
|
||||
"adapter": "opencode_local",
|
||||
"cwd": "/srv/projects/<dein-projekt>",
|
||||
"sessionBehavior": "new",
|
||||
// Fresh session pro Review – verhindert, dass Erinnerungen aus
|
||||
// vorherigen Reviews das aktuelle einfärben. Auch das ist die
|
||||
// BMAD-Empfehlung für adversariale Reviews ("Information
|
||||
// asymmetry – Run reviews with fresh context").
|
||||
|
||||
"env": {
|
||||
"OPENCODE_MODEL": "<anderes-modell-als-dev-z-b-opus-oder-gemini>"
|
||||
// WICHTIG: Dieses Modell muss sich nachweislich vom
|
||||
// Dev-Worker-Modell unterscheiden. Gleiches Modell mit frischem
|
||||
// Context ist besser als nichts, aber unterschiedliche Modelle
|
||||
// fangen verschiedene Fehlerklassen ab. Die Supervisor-Skill
|
||||
// erkennt übrigens, wenn beide gleich sind, und warnt einmalig.
|
||||
},
|
||||
|
||||
"heartbeat": {
|
||||
"enabled": false
|
||||
}
|
||||
},
|
||||
|
||||
"runtimeConfig": {
|
||||
"maxTurns": 200,
|
||||
// Reviews und Retros brauchen weniger als Dev-Arbeit, aber mehr
|
||||
// als Supervisor-Routing. 200 ist eine solide Mitte.
|
||||
|
||||
"timeoutMs": 1800000
|
||||
// 30 Min. Code-Review einer mittleren Story dauert 5-15 Min;
|
||||
// Retros sind in 10-20 Min durch. Timeout deckt auch große
|
||||
// Stories ab.
|
||||
},
|
||||
|
||||
"desiredSkills": [
|
||||
"execute-bmad-qa-tasks"
|
||||
],
|
||||
|
||||
"prompt": "Du bist der QA-Engineer in einer BMAD-V6-Phase-4-Automation. Folge strikt dem Skill 'execute-bmad-qa-tasks'. Du behandelst ausschließlich code-review und retrospective – alles andere weist du ab mit wrong_agent_type. Du änderst keinen Code und machst keine Commits. Dein Review ist adversarial: Finde Probleme, prüfe was FEHLT (Akzeptanzkriterien, Edge-Cases, Tests). Zero Findings ist ein Warnsignal, kein Erfolg. Du arbeitest immer nur an einem Ticket zur selben Zeit.",
|
||||
|
||||
"reportsTo": "<supervisor-agent-id>",
|
||||
"budget": {
|
||||
"monthlyUsd": 150,
|
||||
"perTaskUsdMax": 5
|
||||
// QA ist günstiger als Dev, weil kein Code geschrieben wird.
|
||||
// Anderes Modell kann trotzdem teurer sein pro Token – daher
|
||||
// kein Faktor 10 Unterschied.
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,169 @@
|
||||
# Paperclip Company-Konfiguration für BMAD Phase 4 Automation
|
||||
# ===========================================================
|
||||
# REFERENZ-Dokument, keine direkt einspielbare Config.
|
||||
# Paperclip legt Companies/Agents über UI oder API an.
|
||||
# Konkrete API-Payloads: config/agents.jsonc
|
||||
# Schritt-für-Schritt-Setup: docs/RUNBOOK.md
|
||||
|
||||
company:
|
||||
name: "BMAD Phase 4 Executor"
|
||||
mission: >
|
||||
Automatisierte Ausführung der BMAD-V6-Implementation-Phase mit
|
||||
getrennten Dev- und QA-Rollen. Phasen 1–3 sowie Sprint Planning
|
||||
sind manuell durchgeführt. Diese Company führt ausschließlich den
|
||||
Create → Dev → Review Loop pro Story mit max. 3 Retries bei
|
||||
Review-Fails und Retrospectives pro abgeschlossenem Epic aus.
|
||||
|
||||
# Pfad auf das BMAD-Projekt-Verzeichnis, in dem OpenCode arbeitet.
|
||||
project_root: "/srv/projects/<dein-projektname>"
|
||||
|
||||
# Wohin Eskalationen gehen. Optional – wenn leer, nur Dashboard.
|
||||
operator:
|
||||
name: "<dein Name>"
|
||||
notification_webhook: "<optional>"
|
||||
|
||||
# Agents – Details siehe config/agents.jsonc
|
||||
# -------------------------------------------
|
||||
agents:
|
||||
|
||||
- id: pm-supervisor
|
||||
role: "Supervisor"
|
||||
adapter: opencode_local
|
||||
session_behavior: resume-or-new
|
||||
skills: [monitor-bmad-progress]
|
||||
budget_monthly_usd: 20
|
||||
heartbeat: event-only # wake-on-assignment, kein Timer
|
||||
governance:
|
||||
can_create_child_issues: true
|
||||
can_complete_own_work: false
|
||||
can_escalate: true
|
||||
|
||||
- id: dev-worker
|
||||
role: "Developer"
|
||||
adapter: opencode_local
|
||||
session_behavior: new # fresh chat pro BMAD-Skill (BMAD-Doku-Anforderung)
|
||||
skills: [execute-bmad-dev-tasks]
|
||||
model: "<starkes Code-Modell>"
|
||||
budget_monthly_usd: 300
|
||||
per_task_usd_max: 10
|
||||
heartbeat: event-only
|
||||
reports_to: pm-supervisor
|
||||
assigned_task_types: [create-story, dev-story]
|
||||
governance:
|
||||
can_modify_files: true
|
||||
can_git_commit: true
|
||||
can_git_push: false
|
||||
can_create_child_issues: false
|
||||
|
||||
- id: qa-engineer
|
||||
role: "QA"
|
||||
adapter: opencode_local
|
||||
session_behavior: new # fresh session = unabhängiges Review
|
||||
skills: [execute-bmad-qa-tasks]
|
||||
model: "<anderes Modell als dev-worker>"
|
||||
budget_monthly_usd: 150
|
||||
per_task_usd_max: 5
|
||||
heartbeat: event-only
|
||||
reports_to: pm-supervisor
|
||||
assigned_task_types: [code-review, retrospective]
|
||||
governance:
|
||||
can_modify_files: false # QA schreibt keinen Code
|
||||
can_git_commit: false
|
||||
can_git_push: false
|
||||
can_create_child_issues: false
|
||||
|
||||
# Hinweis: Der Supervisor oben nutzt `heartbeat: event-plus-timer`
|
||||
# mit Intervall 900s (15 Min) – siehe agents.jsonc. Das ist
|
||||
# beabsichtigte Abweichung vom Event-only-Muster der Worker:
|
||||
# Der Supervisor patrouilliert proaktiv und räumt Blocker auf.
|
||||
|
||||
# Concurrency- und Sequenzierungs-Policies
|
||||
# -----------------------------------------
|
||||
# Diese Policies werden vom Supervisor-Skill ERZWUNGEN (nicht nur
|
||||
# empfohlen). Das Skill prüft sie vor jedem Ready-Setzen eines Tasks.
|
||||
policies:
|
||||
|
||||
single_epic_sequence:
|
||||
id: A
|
||||
enabled: true
|
||||
description: >
|
||||
Höchstens ein Epic ist zu einem Zeitpunkt "aktiv". Das nächste
|
||||
Epic startet erst, wenn die Retrospektive des vorigen Epics
|
||||
completed ist. Kein Task aus einem späteren Epic wird ready
|
||||
gesetzt, solange ein früheres Epic nicht abgeschlossen ist.
|
||||
|
||||
single_task_per_agent:
|
||||
id: B
|
||||
enabled: true
|
||||
description: >
|
||||
Jeder Agent bearbeitet zur selben Zeit genau einen Task.
|
||||
Supervisor setzt einen neuen Task für einen Agent erst dann auf
|
||||
ready, wenn dieser Agent keinen anderen Task ready oder
|
||||
in-progress hat. Paperclips atomisches Task-Checkout verstärkt
|
||||
das auf Infrastruktur-Ebene.
|
||||
|
||||
strict_story_order:
|
||||
id: C
|
||||
enabled: true
|
||||
description: >
|
||||
Innerhalb eines Epics werden Stories strikt in Reihenfolge
|
||||
abgearbeitet: Story 1.1 bis zum approved, dann Story 1.2,
|
||||
dann Story 1.3 und so weiter. Story N.(M+1) rührt sich nicht,
|
||||
solange Story N.M nicht approved ist. Keine Vor-Arbeit, keine
|
||||
Parallelität über Story-Grenzen hinweg.
|
||||
|
||||
idempotent_task_creation:
|
||||
id: invariant-zero
|
||||
enabled: true
|
||||
description: >
|
||||
Jede Task-Anlage läuft durch Duplikats-Prüfung. Kompositschlüssel
|
||||
ist (type, epic_id, story_id, retry_count). Kein Task mit
|
||||
identischem Schlüssel wird je zweimal angelegt. Gilt für
|
||||
Bootstrap, Retry-Logik und Patrol-autonome Aktionen gleichermaßen.
|
||||
|
||||
# Patrol-Policy
|
||||
# -------------
|
||||
patrol:
|
||||
enabled: true
|
||||
interval_seconds: 900 # 15 Min (siehe agents.jsonc)
|
||||
meta_stall_threshold_minutes: 60 # ab hier Eskalation statt Weiter-Patrol
|
||||
autonomous_resolutions:
|
||||
- stuck_in_progress_task # Agent-Hang, Task reset-to-ready
|
||||
- orphan_ready_task # kein Agent assigned, re-assign
|
||||
- lost_ready_propagation # Vorgänger completed, Folge blocked
|
||||
- duplicate_task # jüngere Duplikate cancellen
|
||||
- idle_workflow # kein aktiver Task trotz offenem Goal
|
||||
- dirty_worktree # WIP-Commit, kein Code-Verlust
|
||||
mandatory_escalations: # Operator muss ran, keine autonome Aktion
|
||||
- retry_limit_reached # inhaltliche Entscheidung
|
||||
- missing_agent # Agent dereferenziert oder gelöscht
|
||||
- meta_stall # >1h kein Fortschritt trotz Patrol
|
||||
|
||||
# Skill-Config – werden als persistent_facts an Agents übergeben
|
||||
# --------------------------------------------------------------
|
||||
skill_config:
|
||||
monitor-bmad-progress:
|
||||
max_review_retries: 3
|
||||
timeout_retry_limit: 3
|
||||
consecutive_crash_limit: 2
|
||||
stall_detection_minutes: 30
|
||||
patrol_interval_seconds: 900
|
||||
|
||||
# Governance-Eskalationen (harte Stops, kein Approval-Gate)
|
||||
# ---------------------------------------------------------
|
||||
hard_escalations:
|
||||
- retry_limit_reached
|
||||
- sprint_status_missing
|
||||
- sprint_status_inconsistent
|
||||
- no_epic_source_found
|
||||
- planning_incomplete
|
||||
- dirty_worktree
|
||||
- consecutive_crash_limit_reached
|
||||
- concurrent_task # Concurrency-Verletzung – STOPP
|
||||
- duplicate_task_detected # Idempotenz-Verletzung erkannt durch Worker
|
||||
- partial_bootstrap_detected # unvollständige Task-Hierarchie
|
||||
- budget_exhausted
|
||||
|
||||
audit_trail:
|
||||
enabled: true
|
||||
retention_days: 90
|
||||
Reference in New Issue
Block a user