// 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.
  }
}