goromal/agent-skills

Diese Maschine läuft mit NixOS; die gesamte Systemkonfiguration befindet sich im anixpkgs-Repository, geklont unter ~/sources/anixpkgs (kanonisch) und möglicherweise einem anderen Pfad (z. B. /data/andrew/dev/claude/sources/anixpkgs). Aktuelle Bäume werden über ihre Flake-Konfiguration bereitgestellt; anix-upgrade behält den kanalbasierten Pfad für ältere Bäume bei.

Workflow

1. Bearbeiten des entsprechenden Nix-Moduls oder Python/Shell-Skripts unter pkgs/.
2. Neue Dateien stagen — git-cc (von anix-upgrade verwendet) kopiert nur getrackte Dateien (git ls-files). Neue Dateien zuerst mit git add hinzufügen, sonst fehlen sie still im Build.
3. Bereitstellen über die lokale anix-upgrade-ui-API (bevorzugt), Streaming bis zum Ende:

   upgrade_host="$(hostname).local"
   curl -si "http://${upgrade_host}/anix-upgrade/api/v1/run" -X POST \
     -H 'Content-Type: application/json' \
     -d '{"source": "/path/to/anixpkgs", "local": true}'
   # 202 → {"run_id": "<uuid>", "started": true};  409 → already running
   curl -N "http://${upgrade_host}/anix-upgrade/api/v1/stream/<run_id>"
   # endet mit [UPGRADE SUCCESSFUL] oder [UPGRADE FAILED (exit N)], dann [DONE]
   

   Verwenden Sie den .local-Hostnamen der Maschine, nicht localhost: nginx gibt diese Route nur auf dem maschinenspezifischen virtuellen Host frei. CLI-Fallback (nur wenn die API nicht erreichbar ist): anix-upgrade --local -s /path/to/anixpkgs.
4. Testen des Ergebnisses auf dieser Maschine vor dem Commit.

"local": true ist erforderlich, wenn die Änderung ein Dienstpaket oder NixOS-Modul betrifft — ohne setzt anix-upgrade dependencies.nix auf local-build = false, sodass Modul-cfg.package-Standards auf das veröffentlichte Tag-Binary auflösen und die Änderung still keine Wirkung zeigt.

Wichtige Fallstricke

• NixOS-Module müssen an der richtigen Stelle importiert werden (z. B. pc-base.nix-Importliste) — das Hinzufügen einer Datei reicht nicht.
• Neue Optionen müssen in pkgs/nixos/components/opts.nix deklariert und in pc-base.nix zugewiesen werden, bevor sie in Komponenten wie base-dev-pkgs.nix verwendet werden.
• MCP-Server werden pro Benutzer über claude mcp add -s user ... registriert; das claude-setup-Skript (in base-dev-pkgs.nix) kümmert sich darum und muss nach dem Hinzufügen eines Servers erneut ausgeführt werden.

Bereitstellen auf anderen Maschinen / API-Referenz

Die gleiche API läuft auf jeder Maschine mit anix-upgrade-ui: http://<hostname>.local/anix-upgrade/api/v1/ (keine Authentifizierung). run-Body-Felder (alle optional): version, commit, branch, source (lokaler Pfad), local, boot — gleiche Semantik wie anix-upgrade-Flags. Verwenden Sie -si, damit Antwort-Header angezeigt werden (manche Proxies entfernen -s JSON-Bodies).

Für eine entfernte Maschine zuerst pushen und commit (vollständiger Hash), nicht branch übergeben — Branch-Tarballs sind CDN-gecached und können Minuten lang veraltet sein, selbst mit --tarball-ttl 0; ein Commit-Hash verwendet content-addressed fetchGit und umgeht das CDN:

curl -si -X POST http://<hostname>.local/anix-upgrade/api/v1/run \
  -H 'Content-Type: application/json' \
  -d "{\"commit\": \"$(git rev-parse HEAD)\", \"local\": true}"

Einen Lauf überwachen (run_id 404t, sobald ein neuerer Lauf startet, daher Logs vor dem erneuten Auslösen sichern):

curl -s  .../api/v1/status/<run_id> | jq .   # status: running|success|failed
curl -N  .../api/v1/stream/<run_id>          # SSE: spielt die letzten 512 KB ab, dann live
curl -o upgrade.log .../api/v1/log/<run_id>  # vollständiges Log

Läufe erscheinen in der Browser-Oberfläche unter http://<hostname>.local/anix-upgrade/ mit einem via API-Badge; nur ein Lauf pro Maschine gleichzeitig (API und manuelle UI blockieren sich gegenseitig).