Hitonabi
d18aac0e1b
Ampel / ampel (push) Successful in 25s
Befund beim Nachsehen wegen Zeds "Skills Support"-Ankuendigung: die 46 Zeilen Arbeitsregeln in AppData\Roaming\Zed\AGENTS.md haben OpenCode NIE erreicht. Zeds Doku ist eindeutig — AGENTS.md und Skills gelten nur fuer Zeds NATIVEN Agenten, nicht fuer ACP-Agenten wie OpenCode. Hier wird ueber ACP gearbeitet. Gute Regeln (Plan vor Code, kleine Schritte, beweisen statt behaupten, Faulheits-Leiter, Kontext-Waechter) liefen also ins Leere. Sie liegen jetzt in ~/.config/opencode/AGENTS.md — auf dem PC UND auf der Box, also am Tag in Zed und nachts im Cron. Vorlage im Repo unter deploy/opencode/. Beim Umzug korrigiert: - Zeds eingebaute Commit-Vorlage entfernt. Sie war in dieselbe Datei gerutscht und sagt "Only return the commit message in your response" — in dauerhaft aktiven Regeln ein Fehlerherd. - "Zum Bauen oben auf Coder umschalten" gestrichen: seit der Mannschafts- Umstellung laufen plan und build auf demselben Modell. Das war MEINE Regression aus Stufe 4, hier faellig geworden. - Kontext-Waechter auf den Governor umgeschrieben (der kennt den Fuellstand wirklich, Zeds Anzeige war Heuristik). - Neu: Pruef-Tor (VERIFY, inkl. "Test abschwaechen gilt als Betrug"), die Subagenten-Mannschaft, der Werkzeug-Zaun und ein Abschnitt fuer UNBEAUFSICHTIGTE Laeufe — nachts sagt niemand "los", dort darf der Agent nicht auf Freigabe warten. Bewiesen: in einem leeren Ordner (nur globale Regeln wirksam) antwortet der Agent wortgenau aus der neuen Datei. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
76 lines
4.3 KiB
Markdown
76 lines
4.3 KiB
Markdown
# OpenCode-Seite: ein Regelwerk, zwei Auslöser
|
|
|
|
Tagsüber tippst du in **Zed** (PC), nachts ruft ein **Hermes-Cron** dasselbe (Box).
|
|
Beide Wege benutzen dieselbe OpenCode-Version, dieselbe Mannschaft, dasselbe Plugin
|
|
und denselben Token-Wächter. Der einzige Unterschied ist die Adresse des Governors.
|
|
|
|
## Was wohin gehört
|
|
|
|
| Datei hier | Ziel auf dem PC | Ziel auf der Box |
|
|
|---|---|---|
|
|
| `opencode.pc.json` | `~/.config/opencode/opencode.json` | — |
|
|
| `opencode.box.json` | — | `~/.config/opencode/opencode.json` |
|
|
| `AGENTS.global.md` | `~/.config/opencode/AGENTS.md` | `~/.config/opencode/AGENTS.md` |
|
|
| `plugin/mc2-governor.ts` | `~/.config/opencode/plugin/` | `~/.config/opencode/plugin/` |
|
|
| `VERIFY.template` | — | wird von `gitea-repo-create.sh` in **jedes neue Repo** als `VERIFY` gesät |
|
|
|
|
### Warum die Regeln hier liegen und nicht in Zed
|
|
|
|
Die persönlichen Arbeitsregeln standen bis 25.07.2026 in `AppData\Roaming\Zed\AGENTS.md` — und
|
|
haben dort **nie den Coding-Agenten erreicht**. Zeds eigene Doku ist eindeutig: `AGENTS.md` und
|
|
Skills gelten **nur für Zeds nativen Agenten**, nicht für ACP-Agenten wie OpenCode. Da hier über
|
|
ACP gearbeitet wird, liefen die Regeln jahrelang ins Leere.
|
|
|
|
OpenCode liest stattdessen (in dieser Reihenfolge): `AGENTS.md` im Projekt (aufwärts gesucht) und
|
|
`~/.config/opencode/AGENTS.md` global. Beide gelten zusammen — Projektregeln ergänzen die globalen.
|
|
|
|
Beim Umzug bewusst geändert:
|
|
- **Zeds Commit-Vorlage entfernt.** Sie war in dieselbe Datei gerutscht und enthielt „Only return
|
|
the commit message in your response" — in einer dauerhaft aktiven Regeldatei ein Fehlerherd.
|
|
- **Modellwähler-Absatz gestrichen.** „Zum Bauen oben auf Coder umschalten" stimmt seit der
|
|
Mannschafts-Umstellung nicht mehr: `plan` und `build` laufen auf demselben Modell.
|
|
- **Kontext-Wächter umgeschrieben** auf den Governor, der den Füllstand wirklich kennt.
|
|
- **Neu:** Prüf-Tor (`VERIFY`), die Subagenten-Mannschaft und ein Abschnitt für **unbeaufsichtigte
|
|
Läufe** — nachts sagt niemand „los", also darf der Agent dort nicht auf Freigabe warten.
|
|
|
|
Der Governor selbst liegt in `../governor/` (Proxy + systemd-Unit), der unbeaufsichtigte
|
|
Läufer in `../opencode-lauf.sh`.
|
|
|
|
## Die Mannschaft
|
|
|
|
| Rolle | Modell | Gemessen (25.07.2026) | Warum |
|
|
|---|---|---|---|
|
|
| `plan` + `build` | `coder` — Qwen3-Coder-Next | **51,5 t/s** | Hält den Faden, verteilt Zuarbeit. MoE mit 3B aktiv → schnell auf Strix Halo. |
|
|
| `explore` | `hermes` — Qwen3.6-35B | **69,6 t/s** | Ohnehin dauerwarm → kostet **null** zusätzlichen Speicher. Sucht, liest, meldet kurz zurück. |
|
|
| `review` | `kritiker` — Devstral-Small-2 | **15,0 t/s** | Bewusst eine **fremde Modellfamilie** (Mistral statt Qwen) → andere blinde Flecken. Dicht = langsam beim Schreiben, aber ein Kritiker liest viel und schreibt wenig. |
|
|
|
|
`heavy` (gpt-oss-120b, 63 GB) ist **nicht** mehr in der Tagesrolle: es würde beim Laden
|
|
das ganze warme Set verdrängen. Es bleibt der Nacht-Gutachter (4:30-Cron).
|
|
|
|
## Nach einer Änderung
|
|
|
|
Die Dateien hier sind **Vorlagen**, keine Live-Konfiguration. Nach einer Änderung
|
|
verteilen:
|
|
|
|
```bash
|
|
# Box
|
|
scp deploy/opencode/opencode.box.json hitonabi@192.168.178.151:~/.config/opencode/opencode.json
|
|
scp deploy/opencode/plugin/*.ts hitonabi@192.168.178.151:~/.config/opencode/plugin/
|
|
# PC (aus dem Repo heraus)
|
|
cp deploy/opencode/opencode.pc.json ~/.config/opencode/opencode.json
|
|
cp deploy/opencode/plugin/*.ts ~/.config/opencode/plugin/
|
|
```
|
|
|
|
**Zed muss danach neu gestartet werden** — OpenCode liest seine Konfiguration nur beim Start.
|
|
|
|
## Fallen, die Zeit gekostet haben
|
|
|
|
- **Kein `_comment`-Schlüssel in `opencode.json`.** OpenCode validiert streng und
|
|
verweigert den Start mit „Unrecognized key". Kommentare gehören in dieses README.
|
|
- **Das Plugin läuft auf Windows UND Linux.** Deshalb `node:fs` statt `cat` und Buns
|
|
`${{ raw: cmd }}` statt `bash -lc` — beides fehlt auf Windows bzw. verschluckt den Befehl.
|
|
- **Bei `opencode run` beendet sich der Prozess, bevor `session.idle` fertig ist**
|
|
(gemessen 25.07.). Für unbeaufsichtigte Läufe liegt die Prüf-Schleife deshalb
|
|
zusätzlich in `opencode-lauf.sh`, wo sie den Prozess überlebt. In Zed greift das Plugin.
|
|
- **Plugin-Verzeichnis:** `plugin/` und `plugins/` werden beide erkannt; wir nutzen `plugin/`.
|