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.
|
||||
}
|
||||
}
|
||||
Reference in New Issue
Block a user