bmad_agent/config/company.yaml

# 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