OpenWork erweitern und dazu beitragen
1. Beginne mit einer Runtime-Schicht​
OpenWork hat mehrere saubere Erweiterungs-Oberflächen:
| Ziel | Erste Anlaufstelle |
|---|---|
| Desktop-UX | apps/app und apps/desktop |
| Host- und Orchestrierungsverhalten | Orchestrator- und Host-Modus-Oberflächen |
| Plugin-Verwaltung | OpenCode-Plugin-Integration |
| Skills und Templates | Oberflächen zur Paketierung lokaler Workflows |
| Debug- und Berechtigungs-UX | Session- und Kontrollschichten |
2. Warum eng begrenzte Änderungen wichtig sind​
Da OpenWork zwischen einem UI-Produkt und einem Runtime-Orchestrator sitzt, können breite Patches schnell kompliziert werden. Kleinere, oberflächenspezifische Änderungen sind leichter nachzuvollziehen und zu testen.
3. Die besten ersten Beiträge​
- Korrekturen an Doku und Onboarding,
- Verbesserungen der Berechtigungs-UX,
- mehr Klarheit bei Host/Client,
- Feinschliff bei der Plugin- oder Skill-Verwaltung,
- bessere Debug-Exporte oder Diagnosen.
4. Denke in wiederholbaren Team-Workflows​
Ein guter OpenWork-Beitrag sollte verbessern:
- Teilbarkeit,
- Nachvollziehbarkeit (Auditierbarkeit),
- Sicherheit,
- oder Klarheit fĂĽr den Betrieb.
5. Bevor du einen PR öffnest​
Validiere genau den Host-, Client- oder Plugin-Flow, den dein Patch betrifft, und stelle sicher, dass die Berechtigungslogik aus Sicht der Nutzerin klar bleibt.