arc42 · Betriebsmodell

Vom Request zum Betrieb

Der öffentliche Leitstand zeigt eine kontrollierte Delivery-Spur, keine erfundenen Agentenläufe.

Feature-Lifecycle

flowchart LR R[Freie Anforderung] --> P[Central Planner] P --> PP[Betroffene product planners] PP --> Ref[Refiner: scope, architecture, HITL] Ref --> B[Bounded Builder work orders] B --> V[Verifier: test and release evidence] V --> D[Documentation gate] D --> Rel[Explicit product deployment] Rel --> O[Aggregated observability] O --> Dash[Public dashboard] Ref -->|unclear or risky| H[Human decision] V -->|missing evidence| Ref H --> Ref

Ein Feature-Vertrag

Dashboard und Factory MCP nehmen dieselben Felder entgegen: Titel, freie Anforderung, betroffene Produkte, optionale Akzeptanzkriterien und aufrufenden Harness. Der private Factory-Record enthält die Details. Das öffentliche Dashboard zeigt nur Status, nicht-sensitive Architekturwirkung, Work-order-Station und gegebenenfalls aggregierten Tokenverbrauch.

Feature-Intake-Vertrag lesen

Delivery-Verträge

Produkt	Build und Release	Deployment
Display	Swift Bridge + PlatformIO → GitHub Release `firmware.bin`	Bridge LaunchAgent, ESP prüft OTA beim nächsten vorgesehenen Check
Obsidian	Plugin Build/Test → BRAT-kompatibles Release	Obsidian Plugin Update
MCP	Maven/Worker Tests → Release	Cloudflare Worker / Durable Object
Website	Statische Validierung → Pages Deployment	Cloudflare Pages

Observability

Die Bridge überträgt für Messpunkte nur Zeit, Akku-Spannung und technische Ereignisart. Die Factory behält diese Daten 30 Tage; Kalenderinhalte, BLE-Adressen, Rohlogs und Zugangsdaten bleiben lokal. Die Control Plane prüft ihre GitHub-Abhängigkeit alle 15 Minuten und veröffentlicht bei Problemen einen datensparsamen Gesundheitsstatus.

Source of truth: docs/arc42/01-factory-operating-model.md und ADR 0001