OpenWork Architektur und Runtime
1. Die Gestalt des Workspace​
Die README offenbart diese zentralen Runtime-Oberflächen:
| Bereich | Warum es wichtig ist |
|---|---|
| Desktop-App | Lokale UI-HĂĽlle |
| Host-Modus | Lokaler Orchestrierungs-Stack |
| Client-Modus | Verbindung zu einem bestehenden Server |
| OpenCode-Runtime | Treibt Sessions und Tasks an |
| Skill- und Plugin-Verwaltung | Erweitert Workflows |
| Berechtigungs- und Timeline-UI | Macht Entscheidungen und Fortschritt sichtbar |
Das ist eine reichhaltigere Struktur als ein einfaches Chat-Fenster.
2. Das mentale Modell der Runtime​
Zur Laufzeit macht OpenWork im Allgemeinen Folgendes:
- die Nutzerin wählt einen Workspace oder Server,
- die Host- oder Client-Verbindung wird hergestellt,
- OpenCode fĂĽhrt den zugrunde liegenden Workflow aus,
- Sessions streamen Updates per SSE,
- Todos, Berechtigungen und Debug-Informationen erscheinen in der UI.
3. Warum der Host-Modus wichtig ist​
Der Host-Modus ist eines der klarsten Beispiele für das Designziel von OpenWork. Das Produkt möchte lokale Orchestrierung einfach machen, ohne Nutzer zu zwingen, jedes CLI-Teil manuell zu verwalten.
4. Warum Berechtigungen ein erstklassiges Konzept sind​
Die README listet ausdrücklich Berechtigungsanfragen und Auswahlmöglichkeiten wie einmal erlauben, immer oder ablehnen auf. Das bedeutet, dass OpenWork verstanden werden sollte als:
eine OpenCode-Workbench plus eine menschliche Kontrollschicht
und nicht nur als ein hĂĽbscheres Frontend.
5. Was du im Code zuerst lesen solltest​
Beginne mit:
- den Setup- und Architektur-Notizen in der README,
apps/app,apps/desktop,- dem Orchestrator-bezogenen Code,
- den Oberflächen zur Plugin- und Skill-Verwaltung.