docs: Umbauplan OpenChamber - getrennte Bahnen fuer Coding und Betrieb
Ampel / ampel (push) Successful in 22s
Ampel / ampel (push) Successful in 22s
Entscheidung 21.08.: Coding zieht auf OpenChamber (ueber OpenCode), Lucy bleibt der Hermes-Runtime mit voller SysAdmin-Rolle. Zwei Bahnen statt einer eierlegenden Wollmilchsau - der Weg, der hier schon einmal ging. Ausloeser: Hermes Desktops Gateway-Registry akzeptiert kein Benutzer/ Passwort (nur Session-Token oder OAuth), darum fiel der Sessions-Reiter immer auf das lokale Geraet zurueck. Rueckbau ist erledigt und in dieser Datei protokolliert (PC entkernt, Box aufgeraeumt, ufw 9119 zu, Lucy nachweislich unversehrt). Der Aufbau steht aus und ist hier Schritt fuer Schritt beschrieben - inklusive der Fallen aus dem Juli-Audit und der heute gemessenen Modellwahl. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
Hitonabi
co-authored by
Claude Opus 5
Claude Opus 5
parent
e04ace242c
commit
7c23ebf382
@@ -0,0 +1,131 @@
|
||||
# Umbau: OpenChamber als Coding-Bahn, Lucy bleibt SysAdmin
|
||||
|
||||
_Entschieden 21.08.2026. Rückbau der Hermes-Coding-Bahn ist **erledigt**, der Aufbau von
|
||||
OpenChamber steht aus. Diese Datei ist die Übergabe an die nächste Sitzung._
|
||||
|
||||
## Die Entscheidung
|
||||
|
||||
**Zwei getrennte Bahnen** — der Weg, der bei diesem Stack schon einmal funktioniert hat:
|
||||
|
||||
| Bahn | Werkzeug | Zweck |
|
||||
|---|---|---|
|
||||
| **Betrieb** | Hermes-Runtime (Lucy) | SysAdmin, Telegram, Crons, Gedächtnis, Skills, Stimme, PC-Steuerung |
|
||||
| **Coding** | **OpenChamber** über OpenCode | Nur programmieren. Getrennt von Lucy. |
|
||||
| **Motor** | llama-swap `:8080` / MC2-Gateway `:9010` | beide Bahnen teilen sich die Modelle |
|
||||
| **Steuerpult** | MC2 `:9001` | unverändert |
|
||||
|
||||
**Warum getrennt:** Der Versuch, beides in Hermes Desktop zu vereinen, ist an zwei Dingen
|
||||
gescheitert — die Gateway-Registry akzeptiert kein Benutzer/Passwort (nur Session-Token oder
|
||||
OAuth, beides für eine selbstgehostete Box ungeeignet), und der Sessions-Reiter fiel dadurch
|
||||
immer auf „This device" zurück. Details in der Gedächtnisnotiz vom 20./21.08.
|
||||
|
||||
## Was bereits erledigt ist (21.08.)
|
||||
|
||||
**PC:**
|
||||
- Hermes Desktop + CLI deinstalliert (`hermes uninstall --full`), Reste von Hand entfernt
|
||||
- `AppData\Local\hermes`, `AppData\Roaming\Hermes`, `~\.hermes` — alle weg
|
||||
- Startmenü- und Desktop-Verknüpfungen entfernt
|
||||
- Env-Variablen bereinigt; **`HERMES_PC_TOKEN` bleibt bewusst** (Lucys PC-Executor auf `:7777`)
|
||||
- Node v24.19.0 in `Program Files` ist unabhängig → bleibt, erfüllt OpenChambers Anforderung (≥22)
|
||||
|
||||
**Box:**
|
||||
- Bot-Profile `coder` + `debugger` entfernt (gesichert in `~/archiv-aufraeumen-20260820/`)
|
||||
- `~/.hermes/desktop-ssh/` entfernt, `desktop-auth.env` entfernt
|
||||
- ufw: Port **9119 wieder zu** — nur noch `22 · 9001 · 8080 · 7681`
|
||||
- Dashboard bleibt auf `0.0.0.0:9119` gebunden **mit Anmeldung**, damit MC2s `/hermes-ui`-Proxy
|
||||
nicht mehr passwortlos aus dem LAN erreichbar ist (das war ein offenes Scheunentor).
|
||||
Zugang: `~/.hermes/dashboard-login.txt` (0600), Benutzer `commander`.
|
||||
‼️ Zugangsdaten stehen **nur** in `config.yaml` — die frühere `EnvironmentFile` hat sie still
|
||||
überstimmt und kostete eine Fehlersuche. Eine Quelle, eine Wahrheit.
|
||||
|
||||
**Verifiziert nach dem Rückbau:** 5 Dienste aktiv · 4 MCP-Server · 4 Crons · Telegram `connected`
|
||||
· PC-Executor HTTP 200. Lucy ist vollständig funktionsfähig.
|
||||
|
||||
## Was aufzubauen ist
|
||||
|
||||
### 1. OpenCode auf der Box
|
||||
|
||||
Wurde beim Juli-Rückbau entfernt (`command -v opencode` → leer). Muss neu.
|
||||
|
||||
```bash
|
||||
# Installation (Box)
|
||||
curl -fsSL https://opencode.ai/install | bash
|
||||
|
||||
# Provider auf den lokalen Motor zeigen lassen: ~/.config/opencode/opencode.json
|
||||
# base_url http://127.0.0.1:9010/v1 (MC2-Gateway, kann model:auto)
|
||||
# oder http://127.0.0.1:8080/v1 (llama-swap direkt)
|
||||
# api_key local
|
||||
```
|
||||
|
||||
Als systemd-**User**-Dienst (wie alle anderen — reboot-fest, sudo-frei):
|
||||
|
||||
```
|
||||
opencode serve --hostname 0.0.0.0 --port 4096
|
||||
```
|
||||
|
||||
Danach `ufw allow from 192.168.178.0/24 to any port 4096 proto tcp`.
|
||||
|
||||
### 2. OpenChamber auf dem PC
|
||||
|
||||
Desktop-Version von den GitHub-Releases (`openchamber/openchamber`, MIT, ~9,1k ★).
|
||||
**Wichtig:** Die Desktop-Variante bringt eine eigene OpenCode-CLI mit — für den Remote-Betrieb
|
||||
muss sie ausgeschaltet werden:
|
||||
|
||||
```
|
||||
OPENCODE_HOST = http://192.168.178.151:4096 ← volle Adresse MIT Port, OHNE Pfad
|
||||
OPENCODE_SKIP_START = true
|
||||
```
|
||||
|
||||
> Fehlt der Port oder hängt ein Pfad dran, **ignoriert OpenChamber die Variable und startet
|
||||
> stillschweigend seinen eigenen Server.** Genau diese Klasse Fehler hat uns bei Hermes einen
|
||||
> halben Tag gekostet.
|
||||
|
||||
Modelle, Provider und Schlüssel liegen in **OpenCode**, nicht in OpenChamber.
|
||||
|
||||
### 3. Modellwahl — nicht wieder den dichten Coder
|
||||
|
||||
★★ **`fast` (Qwen3.6-35B-A3B) nehmen, nicht `coder` (Qwen3.8-27B).** Gemessen:
|
||||
|
||||
| | Ausgabe | Eingabe | SWE-bench Verified |
|
||||
|---|---|---|---|
|
||||
| `fast` Qwen3.6-35B-A3B (MoE) | **95,7 t/s** | 221 t/s | **73,4** |
|
||||
| `coder` Qwen3.8-27B (dicht) | 12,6 t/s | 144 t/s | keine agentische Messung |
|
||||
|
||||
Das dichte Modell ist bandbreitenlimitiert (17 GB ÷ 215 GB/s ≈ 12,6 t/s = Hardware-Limit).
|
||||
Der MoE ist **schneller und besser**.
|
||||
|
||||
### 4. Die Arbeitsanweisung mitnehmen — der wichtigste Fund überhaupt
|
||||
|
||||
Der Agent las in Lauf A eine ganze Nacht lang und schrieb **null Dateien**. Mit dieser Zeile
|
||||
im Auftrag schrieb er in 24 Minuten fünf:
|
||||
|
||||
> **„Arbeite Datei für Datei. Lies HÖCHSTENS zwei Dateien, bevor du die erste änderst.
|
||||
> Kein Gesamtplan, keine Vollinventur. Eine halbfertige Änderung ist wertvoller als eine
|
||||
> vollständige Analyse ohne Änderung."**
|
||||
|
||||
Gehört in OpenChambers System-Prompt bzw. `AGENTS.md` der Projekte.
|
||||
|
||||
## Bekannte Fallen (aus dem Juli-Audit + heute)
|
||||
|
||||
- **Bus-Faktor 1** bei OpenChamber: ~70–80 % der Commits von einer Person. Version **pinnen**,
|
||||
nicht blind auto-updaten.
|
||||
- **Windows-Installer unsigniert** → SmartScreen-Warnung ist erwartbar, kein Alarm.
|
||||
- Nie ohne `--ui-password` über localhost hinaus binden.
|
||||
- `opencode web` (nicht OpenChamber!) hat einen kaputten Projekt-Finder für `$HOME` — falls
|
||||
irgendwo ein leerer Projektbaum auftaucht, ist das der Grund.
|
||||
- Git-Push zum Gitea geht vom PC **nur über PowerShell/GCM**, nicht aus der Git-Bash.
|
||||
|
||||
## Erster Test nach dem Aufbau
|
||||
|
||||
Die Referenzaufgabe liegt bereit und ist halb erledigt — ideal zum Vergleich:
|
||||
|
||||
```
|
||||
Worktree: ~/projekte/mc2-referenz (Zweig referenz/mem0-ausbau)
|
||||
Aufgabe: docs/aufgaben/referenzaufgabe-mem0-ausbau.md
|
||||
Prüfung: bash docs/aufgaben/referenz-check.sh
|
||||
Stand: 5 von 17 Dateien erledigt (Hermes-Lauf A2, abgebrochen durch SSH-Fehler)
|
||||
```
|
||||
|
||||
Damit lässt sich direkt vergleichen: **Wie lange braucht OpenChamber + `fast` für dieselben
|
||||
17 Dateien?** Hermes + dichter Coder brauchte hochgerechnet ~80 Minuten; die Rechnung für
|
||||
`fast` sagt ~30.
|
||||
Reference in New Issue
Block a user