Hitonabi
d18aac0e1b
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>
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:
planundbuildlaufen 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:
# 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 inopencode.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:fsstattcatund Buns${{ raw: cmd }}stattbash -lc— beides fehlt auf Windows bzw. verschluckt den Befehl. - Bei
opencode runbeendet sich der Prozess, bevorsession.idlefertig ist (gemessen 25.07.). Für unbeaufsichtigte Läufe liegt die Prüf-Schleife deshalb zusätzlich inopencode-lauf.sh, wo sie den Prozess überlebt. In Zed greift das Plugin. - Plugin-Verzeichnis:
plugin/undplugins/werden beide erkannt; wir nutzenplugin/.