arc42 · Betriebsmodell

Von Request zu Betrieb

Feature-Lifecycle

flowchart LR R[Feature Request] --> S[Betroffene Produktlinien bestimmen] S --> A[C4 · arc42 · ADR aktualisieren] A --> I[Begrenzte Implementierungsagenten] I --> T[Produkt-Builds und Tests] T --> V[Review und Release-Verifikation] V --> D[Deployment] D --> O[Aggregierter Health-Snapshot] O --> Dash[Dashboard]

Delivery-Verträge

ProduktBuild und ReleaseDeployment
DisplaySwift Bridge + PlatformIO → GitHub Release firmware.binBridge LaunchAgent, ESP zieht OTA beim nächsten Check
ObsidianPlugin Build/Test → BRAT-kompatibles ReleaseObsidian Plugin Update
MCPMaven/Worker Tests → ReleaseCloudflare Worker / Durable Object
WebsiteStatische Validierung → Pages DeploymentCloudflare Pages

Observability

Das Dashboard sammelt nur verdichtete Signale: letzte erfolgreiche Aktion, Version, Fehlerzähler, Latenzklasse und beim Display Akku-/OTA-Status. Rohlogs, Kalenderinhalte und Zugangsdaten bleiben in der jeweiligen Produktumgebung.

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