88 lines
5.6 KiB
Markdown
88 lines
5.6 KiB
Markdown
# Bifröst (AI Workspace) vs. OpenCode – Gaps und Arbeitsplan
|
||
|
||
Stand: 22.10.2026
|
||
|
||
Die größte Lücke unseres Chats gegenüber OpenCode ist die fehlende Rückmeldung zur Codequalität (Tests, Build, Diagnosen). Die übrigen Lücken schließen wir in Phasen, ohne neue Infrastruktur; Ausführung von Code (Sandbox) wird später als eigenes Thema geklärt.
|
||
|
||
## Grundunterschied
|
||
|
||
OpenCode ist ein Coding-Agent für eine Person: lokal im Terminal, direkt im Arbeitsverzeichnis, mit den Rechten dieser Person. Unser Chat ist eine Team-Plattform: Er arbeitet auf dem Server mit einem eigenen Klon des Repositorys, führt keinen Code aus und protokolliert alles. Nach außen wirkt nur der Klick eines Menschen.
|
||
|
||
Die Angaben zu OpenCode beruhen auf dem Wissensstand von Claude, nicht auf einer aktuellen Recherche.
|
||
|
||
## Vergleich
|
||
|
||
| Thema | OpenCode | Unser Chat |
|
||
| --- | --- | --- |
|
||
| Code ausführen (Tests, Build, Linter) | Ja, per Shell-Tool | Nein |
|
||
| Dateien bearbeiten | edit, write, patch direkt im Arbeitsverzeichnis | `commit_change` (ersetzen, neu schreiben, löschen) als Commit auf den Chat-Branch |
|
||
| Prüfung nach dem Bearbeiten | LSP-Diagnosen gehen an das Modell zurück | Keine; Fehler zeigen sich erst in CI oder Review |
|
||
| Suchen und Lesen | grep, glob, read, list, Web-Abruf | Lesende Git-Tools; kein Web-Abruf |
|
||
| Planung | Plan-Modus, Todo-Liste, Subagenten | Keine eigene Planungsstufe |
|
||
| Projektregeln | `AGENTS.md` mit Konventionen und Befehlen | Fehlt |
|
||
| Langer Kontext | Automatische Verdichtung | Token-Budget, Arbeitsnotiz, Weiterarbeiten |
|
||
| Rückgängig machen | Undo und Redo über Snapshots | Letzten nicht übertragenen Commit zurücknehmen |
|
||
| Berechtigungen | ask, allow, deny je Tool und Shell-Befehl, für eine Person | Risikoklassen, Policies, Freigaben, Rollen, Audit-Log, für viele Nutzer |
|
||
| Git und Pull Request | Macht die Person selbst oder der Agent per Shell | Branch je Chat; Push und PR per Klick; PR-Status und Review-Kommentare kommen zurück |
|
||
| Daten außer Code | Über MCP | Datenbanken, Uploads mit DuckDB, MCP, Gedächtnis |
|
||
| Betrieb und Kosten | Lokal, eigener API-Schlüssel | Zentral: Kontingente, Kosten, Monitoring, Backup |
|
||
|
||
## Lücken
|
||
|
||
Aufwand: S bis 1 Tag, M einige Tage, L mehr als eine Woche oder abhängig von Infrastruktur.
|
||
|
||
| Lücke | Wirkung | Aufwand | Phase |
|
||
| --- | --- | --- | --- |
|
||
| Keine Rückmeldung zur Qualität (Tests, Build, Diagnosen) | Hoch: Die KI kann nicht prüfen, ob ihr Code funktioniert | L | später |
|
||
| Keine Projektregeln aus dem Repo | Hoch: Stil und Konventionen werden nicht eingehalten | S | 1 |
|
||
| Kein Plan-Modus, keine Todo-Liste | Mittel: Große Aufgaben laufen ohne abgestimmten Plan | M | 2 |
|
||
| Keine statische Prüfung beim Commit (Syntax, JSON, YAML) | Mittel: Offensichtliche Fehler gehen durch | S | 3 |
|
||
| Werkzeuge für große Änderungen (Patch, Pfadsuche) | Mittel: Viele Schritte und Tokens bei Änderungen über mehrere Dateien | M | 3 |
|
||
| Keine Subagenten | Niedrig: Der Hauptkontext füllt sich bei Recherchen | M | 4 |
|
||
|
||
## Entscheidungen (22.10.2026)
|
||
|
||
- **Projektregeln:** nur `AGENTS.md`.
|
||
- **Plan-Modus:** per Schalter, nicht automatisch.
|
||
- **Statische Prüfung:** bei Fehlern zunächst nur warnen, der Commit wird angelegt.
|
||
- **CI:** bleibt vorerst außen vor (kein Build-Status aus Bitbucket).
|
||
- **Sandbox:** ob und wie, wird später festgelegt. Container sind eine Möglichkeit; das wird als eigenes, späteres Thema vertieft. Konzept (OpenShift, ohne privilegierte Container): [sandbox-konzept.md](sandbox-konzept.md).
|
||
|
||
## Arbeitsplan
|
||
|
||
### Phase 1: Projektregeln aus dem Repo (S) – erledigt
|
||
|
||
- [x] `AGENTS.md` vom Stand des Chat-Branches bzw. des Ziel-Branches lesen
|
||
- [x] Größe begrenzen (z. B. 8 KB) und als Projektkonventionen in den Prompt geben, nachrangig zu den Plattform-Regeln
|
||
- [x] Im Chat anzeigen, welche Regeldatei aktiv ist
|
||
- [x] Tests, README, Konzept
|
||
|
||
### Phase 2: Plan-Modus und Todo-Liste (M) – erledigt
|
||
|
||
- [x] Tool `update_plan` (`write_internal`): Die KI pflegt eine Todo-Liste je Chat (offen, in Arbeit, erledigt)
|
||
- [x] Liste sichtbar im Chat; Weiterarbeiten setzt beim nächsten offenen Punkt an
|
||
- [x] Schalter „Erst planen“: In diesem Modus bekommt die KI nur lesende Tools und das Plan-Tool, mit dem Knopf „Plan umsetzen“ gibt es die schreibenden dazu
|
||
- [x] Todo-Liste geht in die Arbeitsnotiz und die PR-Beschreibung ein
|
||
- [x] Tests, Doku
|
||
|
||
### Phase 3: Werkzeuge und statische Prüfung (M) – erledigt
|
||
|
||
- [x] Statische Prüfung beim Commit, ohne Code auszuführen: Python-Syntax, JSON, TOML, XML, YAML; Warnungen gehen an die KI zurück und stehen am Commit
|
||
- [x] `commit_change` nimmt auch einen Unified Diff (Patch) über mehrere Dateien an, inkl. Löschen und Umbenennen
|
||
- [x] Pfadsuche (Glob) als lesendes Tool: gab es schon als `git_find_files`
|
||
- [x] Tests, Doku
|
||
|
||
### Phase 4: Subagenten (optional, M)
|
||
|
||
- [ ] Lesende Teilaufgaben (z. B. „alle Aufrufer finden“) mit eigenem Kontext ausführen; zurück kommt nur das Ergebnis
|
||
|
||
### Später, eigenes Thema: Rückmeldung zur Qualität
|
||
|
||
- **Sandbox:** ein abgeschotteter Container je Lauf, ohne Netz, ohne Secrets, mit Zeit- und Speicherlimit; führt vom Workspace-Admin je Repo festgelegte Befehle aus (Tests, Linter), als Tool `run_checks`. Keine freien Shell-Befehle.
|
||
- **Build-Status aus Bitbucket:** nur, falls die CI auf `ai/*`-Branches läuft und den Status meldet.
|
||
|
||
## Bewusst nicht übernehmen
|
||
|
||
- **Freie Shell auf dem Server:** widerspricht dem Sicherheitsmodell. Ausgeführt wird höchstens in einer Sandbox, mit festgelegten Befehlen.
|
||
- **Schreiben ohne Commit:** Jede Änderung bleibt ein nachvollziehbarer Commit auf dem Chat-Branch.
|
||
- **Push oder PR durch die KI:** bleibt ein Klick eines Menschen.
|