Files

T

Ampel / ampel (push) Successful in 25s

Details

Persoenliche Arbeitsregeln erreichen endlich den Coding-Agenten

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>

2026-07-25 23:38:08 +02:00

4.3 KiB

Raw Blame History

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:

# 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/.

4.3 KiB Raw Blame History