---
name: zimaos-environment
description: Vollständiger System-Kontext für ZimaOS/CasaOS — alle technischen Details, Pfade, Hardware und Docker-Ressourcen.
trigger:
  - "ZimaOS"
  - "CasaOS"
  - "System"
  - "Hardware"
  - "Speicher"
  - "Festplatte"
  - "Docker"
priority: high
---

# ZimaOS Environment Reference

## System
- **OS**: ZimaOS (IceWhale) auf Linux-Basis
- **Paketmanager**: Keiner (`apt`, `pacman`, `apk` fehlen)
- **Rootfs**: Read-only

## Hardware
- **3D-Drucker**: Bambu Lab A1 Mini
- **Speicher**: Spare powerbank + 2W solar panels (ZONADAH)

## Laufwerke — Exaktes Layout (Stand Mai 2026)

```
Filesystem      Size  Used Avail Use% Mounted on
/dev/root       1.2G  1.2G     0 100% /            # ROOT — NIE benutzen!
devtmpfs        3.9G     0  3.9G   0% /dev
tmpfs           3.9G  3.4G  500M  88% /tmp          # RAM-Disk — begrenzt!
/dev/sdb8       222G   57G  165G  26% /DATA         # SSD — Haupt-Arbeitslaufwerk
/dev/sda        932G  124G  806G  14% /media/HDD_1TB # HDD — Langzeit-Archive
```

| Mount | Type | Größe | Frei | Nutzung |
|-------|------|-------|------|---------|
| `/` | rootfs | 1.2 GB | **0%** | **NIE für Daten** |
| `/tmp` | tmpfs (RAM) | 3.9 GB | ~500 MB–3.5G | Temp-Files nur <50 MB |
| `/DATA` | SSD (/dev/sdb8) | 222 GB | ~165 GB | **ALLES hierher** |
| `/media/HDD_1TB` | HDD (/dev/sda) | 932 GB | ~806 GB | Archive, Backups |

### ⚠️ Tmpfs-Pitfall — Kritisch!
`/tmp` ist ein **RAM-Disk (tmpfs)** mit nur 3.9 GB. Wird schnell gefüllt durch:
- Video-Downloads (yt-dlp schreibt nach `/tmp`)
- Frame-Extraktion (ffmpeg → `/tmp/frames/`)
- 3D-Modelle (GLB/STL in `/tmp`)
- **`pip install` Abbrüche hinterlassen Leichen** (`/tmp/pip-unpack-*`, `/tmp/pip-build-env-*`)
  - Ein einzelner `pip install torch`-Versuch hinterließ **2.6 GB Leiche** (`/tmp/pip-unpack-npwcublu`)
- **Playwright Chromium Prozesse** laufen headless und belegen persistent RAM

**Symptom**: `OSError: [Errno 28] No space left on device` obwohl `/DATA` 165 GB frei hat.

### Pitfall: "Ich habe genug Speicher" — Verify Before Claim!
**Der User hat 165 GB frei auf `/DATA`. Aber `pip install` lädt nach `/tmp` (RAM-Disk).**
Ein 530 MB Wheel braucht ~1.5 GB beim Entpacken. `/tmp` hat nur 3.9 GB — und die Hälfte kann schon durch Leichen belegt sein.

**Vor jedem großen Download oder `pip install`:**
```bash
df -h /tmp          # Freien RAM-Disk-Platz checken
du -sh /tmp/*       # Leichen aufspüren
rm -rf /tmp/pip-unpack-* /tmp/pip-build-env-*   # Aufräumen
```

### ✅ Neue Work-Directory-Struktur (ab Mai 2026)
Große temporäre Dateien gehören **NIEMALS** nach `/tmp`. Stattdessen:

| Zweck | Pfad | Befehl |
|-------|------|--------|
| Arbeitsdateien (Video, Audio, 3D, Downloads) | `/DATA/AppData/hermes/work/` | `cd /DATA/AppData/hermes/work` |
| Download-/Install-Temp | `/DATA/AppData/hermes/tmp_downloads/` | `TMPDIR=/DATA/AppData/hermes/tmp_downloads pip install ...` |
| Langzeit-Archive | `/media/HDD_1TB/archive/` | — |

**Konvention:**
1. Vor jeder großen Operation: `cd /DATA/AppData/hermes/work`
2. Bei `pip install` großer Pakete (torch, etc.): `TMPDIR=/DATA/AppData/hermes/tmp_downloads python3 -m pip install ...`
3. Nach Session: Aufräumen oder nach `/media/HDD_1TB/archive/` verschieben
4. Kleine echte Temp-Files (Logs, Sockets) dürfen nach `/tmp`

## Pfade
| Ressource | Pfad |
|-----------|------|
| Hermes Home | `/DATA/AppData/hermes` |
| Hermes Gateway | systemd service |
| Hermes Config | provider `custom`, model `kimi-k2.6`, base_url `https://ollama.com/v1` |
| Browser Cache | `/DATA/AppData/hermes/browser/` |
| Codex CLI | `/DATA/AppData/hermes/.bin/codex` |
| Hermes Skills | `/DATA/AppData/hermes/skills/` |
| Hermes .env | `/DATA/AppData/hermes/.env` |
| Work Dir | `/DATA/AppData/hermes/work/` |
| Projects Dir | `/DATA/AppData/hermes/projects/` |

## Integrierte Dienste
| Dienst | Status | Details |
|--------|--------|---------|
| **Browser** | Aktiv | Docker `kiwi-browser:v2`, Port 30000, Playwright + Chromium |
| **Notion API** | Aktiv | Token in `.env`, Skill vorhanden |
| **Google Calendar** | Aktiv | `kiwitime` unter `.bin/`, OAuth in `.secrets/google_oauth.env` |
| **GMX Email** | Aktiv | `amadeus.bot@gmx.at`, IMAP/SMTP |
| **faster-whisper** | ✅ Bereits installiert | Im venv (`/DATA/AppData/hermes/venv/lib/python3.11/site-packages/faster_whisper/`). Model: `base` in `/DATA/AppData/hermes/.cache/whisper/`. Nie `openai-whisper` installieren — braucht PyTorch >500 MB und scheitert auf `/tmp`.|
| **Honcho Memory** | ✅ Lokal aktiv | Eigener FastAPI-Server auf `localhost:8000`, SQLite-Backend. `.env` braucht `HONCHO_API_KEY=local` + `HONCHO_BASE_URL=http://127.0.0.1:8000`. Siehe `references/honcho-local-setup.md` für Server-Code und Einrichtung.|
| **AGENTS.md** | ✅ Im Hermes-Root | Betriebsregeln für Kiwi (`/DATA/AppData/hermes/AGENTS.md`). Hermes lädt sie automatisch pro Session. Siehe `references/kiwi-operating-rules.md` für aktuellen Inhalt.

## Sudo-Berechtigungen (erlaubt)
- `gateway restart`
- `apt-get install`
- `docker`

## Memory-Management auf ZimaOS — Priorität: Skills statt Memory

Hermes Memory hat nur **2.200 Zeichen** — extrem knapp.

**Regel**: Technische Details NIEMALS in Memory pressen. Stattdessen:
1. Alles System-/Docker-/API-relevante in diesen Skill (`zimaos-environment`)
2. User-Präferenzen in `user-persona` Skill
3. Verhaltensregeln in `kiwi-operational-rules` Skill
4. Workflows in dedizierten Skills (`local-transcription-workflow`, etc.)
5. Memory nur für **kurze Verweise**: "siehe Skill X" oder "Projekt-Datei unter `/DATA/AppData/hermes/projects/...`"

### Wichtige User-Präferenz (Mai 2026)
Der User hat explizit gesagt: *"Ich hab immer Angst das du was wichtiges löscht...
Wäre besser daraus ein Skill zu machen statt Memory, da ist der Platz immer knapp."*

**Konsequenz:**
- Wenn Memory knapp wird (>85%) → in Skills auslagern
- Memory-Einträge durch Skill-Referenzen ersetzen
- Memory NIE als primären Wissenspeicher nutzen
- **Kein Verweis auf Memory aus Memory!** (z.B. "siehe oben" funktioniert nicht in neuen Sessions)
- User-Eingekommene Korrekturen/Regeln → im relevanten Skill einbetten, nicht nur Memory
- Session-spezifische Details → in `references/<topic>.md` unter dem passenden Skill