goromal/agent-skills

Esta máquina ejecuta NixOS; toda la configuración del sistema reside en el repositorio anixpkgs, clonado en ~/sources/anixpkgs (canónico) y posiblemente en otra ruta (por ejemplo, /data/andrew/dev/claude/sources/anixpkgs). Los árboles actuales se despliegan a través de su configuración de flake; anix-upgrade conserva la ruta basada en canales para árboles más antiguos.

Flujo de trabajo

1. Edita el módulo de Nix o el script de Python/shell relevante en pkgs/.
2. Prepara nuevos archivos — git-cc (usado por anix-upgrade) solo copia archivos rastreados (git ls-files). Agrega nuevos archivos con git add primero, o estarán ausentes silenciosamente en la compilación.
3. Despliega a través de la API local de anix-upgrade-ui (recomendado), transmitiendo hasta que finalice:

   upgrade_host="$(hostname).local"
   curl -si "http://${upgrade_host}/anix-upgrade/api/v1/run" -X POST \
     -H 'Content-Type: application/json' \
     -d '{"source": "/ruta/a/anixpkgs", "local": true}'
   # 202 → {"run_id": "<uuid>", "started": true};  409 → ya en ejecución
   curl -N "http://${upgrade_host}/anix-upgrade/api/v1/stream/<run_id>"
   # termina con [UPGRADE EXITOSA] o [UPGRADE FALLIDA (código N)], luego [TERMINADO]
   

   Usa el nombre de host .local de la máquina, no localhost: Nginx expone esta ruta solo en el host virtual específico de la máquina. Método alternativo de línea de comandos (solo si la API no está disponible): anix-upgrade --local -s /ruta/a/anixpkgs.
4. Prueba el resultado en esta máquina antes de confirmar.

"local": true es obligatorio siempre que el cambio afecte a un paquete de servicio o módulo de NixOS; sin él, anix-upgrade deja dependencies.nix con local-build = false, por lo que los valores predeterminados de cfg.package del módulo resuelven al binario de la etiqueta publicada y el cambio no surte efecto silenciosamente.

Errores importantes

• Los módulos de NixOS deben importarse en el lugar correcto (por ejemplo, la lista de importaciones de pc-base.nix) — agregar un archivo no es suficiente.
• Las nuevas opciones deben declararse en pkgs/nixos/components/opts.nix y asignarse en pc-base.nix antes de usarse en componentes como base-dev-pkgs.nix.
• Los servidores MCP se registran por usuario mediante claude mcp add -s user ...; el script claude-setup (en base-dev-pkgs.nix) maneja esto y debe volverse a ejecutar después de agregar un servidor.

Despliegue en otras máquinas / referencia de la API

La misma API se ejecuta en todas las máquinas que alojan anix-upgrade-ui: http://<hostname>.local/anix-upgrade/api/v1/ (sin autenticación). Campos del cuerpo de run (todos opcionales): version, commit, branch, source (ruta local), local, boot — mismas semánticas que las banderas de anix-upgrade. Usa -si para que se muestren los encabezados de respuesta (algunos proxies eliminan los cuerpos JSON de -s).

Para una máquina remota, primero haz push y pasa commit (un hash completo), no branch — los tarballs de las ramas se almacenan en caché de CDN y pueden estar obsoletos durante minutos incluso con --tarball-ttl 0; un hash de commit usa fetchGit con direccionamiento de contenido y omite la 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}"

Supervisa una ejecución (run_id da 404 una vez que comienza una ejecución más nueva, así que obtén los registros antes de volver a activar):

curl -s  .../api/v1/status/<run_id> | jq .   # estado: running|success|failed
curl -N  .../api/v1/stream/<run_id>          # SSE: reproduce los últimos 512 KB, luego en vivo
curl -o upgrade.log .../api/v1/log/<run_id>  # registro completo

Las ejecuciones aparecen en la interfaz de usuario del navegador en http://<hostname>.local/anix-upgrade/ con una insignia via API; solo una ejecución por máquina a la vez (la API y la interfaz de usuario manual se bloquean mutuamente).