Betrieb — CAS Dokumentation

Repositories zuweisen

Standardweg für ein Projekt, an dem die Agenten arbeiten sollen:

cas repo add <git-url>
cas repo list

Der aktive Workspace-Pfad im Container ist /home/node/workspace/<repo-name> — in openclaw.json unter agents.defaults.repoRoot hinterlegt.

GitLab-Integration (Phase 2)

Runner läuft als Container gitlab-runner, Executor Docker, mit Socket-Mount für Docker-in-Docker-Szenarien
Registrierung nutzt GITLAB_URL (Standard https://gitlab.com) und GITLAB_RUNNER_TOKEN
SSH-Key unter /home/cas/.ssh/ für Git-Operationen zu GitLab
Webhooks verweisen auf das Gateway unter https://gateway.<DOMAIN> (Details im Installer / Konfigurationsvorlagen)

API-Zugriff für private Repos beim Klonen: GITLAB_API_TOKEN in der .env.

Phase 3 — Kurzüberblick

Extra	Wirkung
Authelia	Benutzerdatenbank, Secrets unter `~/cas/authelia/`; Traefik-Middleware `authelia@docker`; OpenClaw ggf. auf `trusted-proxy`
Telegram / WhatsApp	Erweiterte Kanäle für Steuerung und Status (Konfiguration über Installer-Prompts)
Weitere Agenten	architect, qa, po, docs, security — Prompts/Modelle wie im Template definiert
Wartung	Logrotate; optional täglicher `cas backup` per Cron

Updates

cd /home/cas/cas
cas update

Für neue CAS-Version inkl. Template-Änderungen:

cas update --self
cas update

Wenn sich docker-compose.yml im Repo-Template geändert hat, muss die lokale Datei unter ~/cas/ zum neuen Stand gebracht werden (neues Setup der betreffenden Phase oder manueller Abgleich mit dem Git-Stand von cas/templates.py).

Backups

cas backup

Sichert Konfiguration und Secrets — nicht zwingend die kompletten Workspace-Daten aller Repos (fokussiert auf Betriebsrelevanz laut BACKUP_PATHS im Code). Für Voll-Backups Repos/ZFS separat planen.

Dokumentation aktuell halten

Diese Seiten liegen im Git unter docs/site/. Änderungen am Produkt (CLI, Phasen, URLs) sollten hier gespiegelt werden — im Projekt gibt es eine Cursor-Rule, die genau das für KI-gestützte Bearbeitung verankert.