Gestión y actualización

Las instalaciones de Herdr no tienen collie en PATH; use identificadores de acción de Herdr (Acciones de Herdr). Las instalaciones independientes ubican el binario en ~/.local/share/collie/current/bin/collie o <checkout>/bin/collie:

# the install script's layout
cd ~/.local/share/collie/current && bin/collie version
# a source build or a linked clone
cd ~/my/collie-checkout && bin/collie version

Ejecute bin/collie link para crear un enlace simbólico del binario en ~/.local/bin (Añadir collie al PATH).

La configuración y el estado se encuentran fuera de la copia de trabajo y persisten tras las actualizaciones (bridge/solo-baseline.test.ts). .env y el registro tailscale serve están en el directorio de configuración, ~/.config/collie en una instalación binaria o el directorio de configuración de plugins de Herdr en una instalación de Herdr; los dispositivos emparejados y stt.json están en el directorio de estado, ~/.local/state/collie a menos que COLLIE_STATE_DIR lo mueva.

Una instalación por paquete

Si el gestor de paquetes instaló Collie, este se encarga de actualizar Collie, y todo lo que sigue a esta sección no aplica:

sudo pacman -Syu collie-bin    # or `nix profile upgrade collie`, or `brew upgrade collie`

Collie reconoce esta instalación a partir de las estructuras en disco: sin .git, sin disposición versions/, el manifiesto que incluye la versión distribuida y una raíz que es de solo lectura, externa a su directorio personal o propiedad de root. Cualquiera de las tres últimas condiciones es suficiente. En tal caso, rechaza la actualización in situ e indica el comando correspondiente si puede determinar qué gestor es propietario de la carpeta:

error: /opt/collie is a packaged install — updates come from your package manager.
       `collie update` will not replace its files.
       Take the new version with: sudo pacman -Syu collie-bin

Si el prefijo no indica ningún gestor que Collie reconozca, imprime las dos primeras líneas y se detiene en lugar de suponer un comando que no se pueda ejecutar.

collie doctor informa que la misma instalación está en buen estado, y la tarjeta de actualización del teléfono sigue mostrando que existe una versión más reciente, con el comando del paquete en lugar del botón de actualización.

Nota. Esta no es una limitación que deba eludirse. La carpeta pertenece a su gestor de paquetes, y reemplazar sus archivos a sus espaldas dejaría su base de datos con información incorrecta sobre lo que está instalado. sudo collie update lo rechaza de la misma manera.

Para adoptar una nueva versión, ejecute su gestor de paquetes y luego reinicie el servicio:

paru -Syu collie-bin                              # Arch, or your AUR helper of choice
nix profile upgrade collie                        # Nix
mise upgrade --bump github:AltanS/collie          # mise
collie restart

Una instalación de mise es el caso atípico: Collie no la detecta como empaquetada porque el árbol reside en el directorio personal sin .git ni estructura versions/, por lo que collie update la rechaza con cannot tell how this Collie was installed y no nombra ningún gestor. mise sigue siendo su propietario. Consulte Instalación.

El reinicio es la parte que Collie no puede hacer de forma automática, y no es opcional. Su gestor de paquetes reemplaza los archivos mientras el puente está en ejecución, por lo que ese proceso continúa ejecutando el código antiguo a pesar de reportar ya la nueva versión. Collie detecta esa discrepancia y lo notifica: collie doctor genera restart-pending, y el teléfono muestra un aviso de "Bridge restart needed" con el texto "Collie was replaced on disk. Restart it." Ambos se despejan en cuanto se ejecuta collie restart.

En un crew, un miembro instalado por paquete nunca recibe una actualización desde el teléfono. El crew lo lista como "waits for the package manager" y considera la ejecución completa sin él, por lo que los dos comandos anteriores son los que lo nivelan.

Un lead empaquetado rechaza únicamente su propio traslado. El teléfono sigue nivelando a cada miembro a la versión que ejecuta el lead, y una sola confirmación los cubre. Después de que los dos comandos anteriores hayan trasladado el lead, nada se nivela por sí solo: toque la página Actualizaciones una vez más y los miembros pasarán a la nueva versión del lead.

Actualizar, desde el teléfono o la terminal

Existen dos rutas de actualización y ambas ejecutan los mismos pasos en cada host: preparar la nueva versión junto a la activa, cambiar el symlink, reiniciar y comprobar que el servicio responda. En un lead del crew, ambas rutas cubren todo el crew. El teléfono es la ruta corta. La terminal es la alternativa para una máquina que el teléfono no puede nivelar.

Desde el teléfono

Abra Settings y seleccione Actualizaciones. La tarjeta muestra la versión en ejecución, la versión más reciente y las versiones intermedias incluidas en la actualización. Si el host está en la versión más reciente, la tarjeta lo indica y no ofrece nada.

Debajo se encuentra el preflight, con una línea por comprobación: doctor, disk, bun, tree, upstream y service. En un lead, también se comprueba cada miembro del crew.

• —
  Verde está despejado.
• —
  Vale la pena conocer Ámbar y nunca bloquea: discrepancia de versiones en un crew, un tipo de instalación inusual, una versión mayor disponible que no se está aplicando. Los archivos temporales sin seguimiento en un checkout permanecen en verde.
• —
  Rojo bloquea la actualización. La línea indica el motivo, como un collie doctor en rojo, menos de 1 GB libre para la compilación preparada, la ausencia de bun en el host o un servidor ascendente inaccesible. Cuando un solo comando lo resuelve, la tarjeta imprime ese comando como Fix: <command>.

Pulsar Actualizar a <version> solicita confirmación una vez, y el texto de confirmación es literal: la sesión de terminal permanece activa y la vista del teléfono se interrumpe hasta 30 segundos. El reinicio detiene el puente, no el multiplexor, por lo que los agentes continúan ejecutándose y el teléfono se reconecta en la nueva versión. Una versión principal nunca se aplica en una actualización rutinaria: pasar a una requiere su propia confirmación, identifica la versión como una nueva versión principal e indica leer primero las notas de la versión.

Durante la ejecución, una hoja ocupa la pantalla. Consulte Qué muestra el teléfono mientras se ejecuta una actualización más adelante. La tarjeta en la página Updates muestra los mismos estados con mayor detalle:

Los cuatro primeros indican progreso; la tarjeta lo indica y solicita mantener la pantalla abierta. rolled-back indica la versión en la que aún se encuentra, muestra el final del registro del servicio y ofrece Reintentar. stuck imprime el comando único que debe ejecutarse en un terminal. interrupted ofrece Reintentar también.

Recordármelo en el próximo resumen descarta el aviso de la tarjeta. No es un silencio permanente: la siguiente notificación esperará a una versión más reciente y a una nueva ventana de tiempo.

Frecuencia de las notificaciones. Las notificaciones de actualización son un resumen, como máximo una al día, y nunca antes de las 09:00 hora local del host. Un delta que solo contenga versiones de parche espera a una ventana semanal, de modo que el tren de parches llegue en una sola notificación en lugar de cuatro; una versión menor o mayor mantiene la cadencia diaria e incluye los parches en espera. Las versiones retenidas se integran, nunca se descartan. Un parche también puede solicitar la cadencia diaria: una corrección necesaria para el mismo día se marca como urgente al generarse, y la tarjeta de actualización muestra una etiqueta Urgente con una única frase que explica el motivo. Se notifica en el momento de la publicación o a las 09:00 siguientes. Una versión urgente hace que todo el tren en espera pase a ser diario, sin dejar de ser un parche ordinario. Una instalación anterior a esta función mantiene la ventana semanal para un parche urgente hasta que se actualice por primera vez. La tarjeta muestra siempre el estado actual con independencia de la ventana. La preferencia de notificación updates, en Settings → notifications (Web Push), es el único interruptor de desactivación.

En un lead del crew, el botón muestra Actualizar crew a <version>, y una sola confirmación se aplica a todas las máquinas. El lead se actualiza primero, bajo su propio control de salud. Luego, cada peer se nivela a la misma versión, uno a la vez, usando su propio preflight, su propio control de salud y su propio rollback. No hay un botón por peer ni una segunda solicitud de confirmación. Para más detalles, las dos rutas de recuperación y el único caso que el teléfono no puede resolver, consulte Actualización del resto del crew.

Una franja en la parte superior de cada pantalla muestra el estado pasivo en lugar de lo que está en ejecución: la versión disponible, un par que no se pudo actualizar y New version — tap to update cuando la aplicación instalada en el dispositivo va por detrás del bridge. Una actualización en curso pertenece a la hoja, no a la franja.

Qué muestra el teléfono mientras se ejecuta una actualización

Una hoja ocupa la pantalla en el dispositivo donde se confirmó la acción, y los demás dispositivos reciben un distintivo.

La hoja incluye una fila por máquina, empezando por la principal, cada una con su versión y su estado actual. Debajo figura la fila de este dispositivo, correspondiente a la aplicación instalada y no a una máquina: una vez que el bridge sirve la nueva versión, el teléfono descarga la aplicación en segundo plano y la fila contabiliza los archivos a medida que llegan. La hoja también indica una vez, en letra pequeña, que la actualización se ejecuta en las máquinas y que cerrar la aplicación no la detiene.

El dispositivo que inició la ejecución no puede usar la aplicación que queda detrás de la hoja. Nada más queda bloqueado: un segundo teléfono o una tableta muestra una sola línea que se puede pulsar para abrirla, y vuelve a cerrarse.

Cuando todas las máquinas han terminado y el teléfono ejecuta la nueva aplicación, la hoja se cierra automáticamente y un mensaje breve indica la versión. En un crew se muestra Crew updated to <version>; en una sola máquina se muestra el nombre de dicha máquina.

Una ejecución que solo actualiza a los miembros, como Reintentar actualización del crew, toma la pantalla de la misma forma. La fila del lead muestra already up to date, porque el lead no forma parte de esa ejecución y no se reinicia. El final muestra Members updated to <version>, y un miembro que no pudo actualizarse deja la hoja abierta con su motivo en el teléfono que inició la ejecución.

Tres estados pueden quedar bloqueados, y cada uno tiene una salida. Ninguno de ellos cancela la actualización ni recarga la aplicación.

Nota. «Descarga en curso, siga usando la aplicación» se refiere a la aplicación en el teléfono y nunca a la máquina. Las máquinas han terminado; solo falta que llegue la nueva aplicación. La aplicación que tiene abierta sigue funcionando y cambiará por sí sola en cuanto finalice la descarga.

Desde el terminal

collie update --check            # read-only preflight, --json for a script
collie update --check --local    # the same, this instance only, no crew members
collie update                    # stage, flip, restart, verify
collie update --status           # what the updater did, or is doing, --json for a script
collie update --rollback         # put the previous version back
collie update --major            # cross one major, see below

collie update --help muestra el modo de uso y no inicia nada. Cada comando collie responde a -h y --help de la misma forma, antes de realizar cualquier tarea.

En una instalación gestionada por Herdr, los mismos verbos corresponden a acciones de Herdr:

herdr plugin action invoke update --plugin herdr.collie      # Herdr-managed
bin/collie update                                            # Standalone

collie update --check no modifica nada. Ejecuta collie doctor, lee el espacio libre, la versión de bun, el árbol de trabajo, la lista de versiones ascendentes y la unidad de systemd, y en un lead formula la misma pregunta a cada miembro de la crew a través de su propio SSH. Sale con código 0 a menos que haya algún error, y --json imprime un informe con versiones. Añada --local para comprobar solo esta instancia y omitir los miembros de la crew. El teléfono ejecuta esa comprobación local en su propio host y lee la línea de cada par mediante el enlace de crew, por lo que su comprobación previa no necesita SSH.

collie update descarga la versión más reciente de su versión major actual y la prepara. A continuación, el comando transfiere el cambio a un actualizador independiente y finaliza, ya que el reinicio cierra el puente que solicitó la actualización. Dicho actualizador apunta current a la nueva versión, reinicia utilizando el nuevo binario y sondea GET /api/health durante un máximo de 30 segundos para obtener una respuesta que contenga la versión recién instalada. Si la respuesta no llega, o proviene de la versión antigua, restablece current a la versión anterior, reinicia una vez más y registra rolled-back con el final del registro del servicio. Si tampoco se inicia, registra stuck con el comando que debe ejecutarse manualmente, y nada volverá a reiniciarse. Realiza la reversión una sola vez.

Defina COLLIE_UPDATE_HEALTH_TIMEOUT_MS si 30 segundos no son suficientes en su máquina. Un inicio en frío lento que supere el límite establecido se considerará una actualización fallida y se revertirá.

collie update --status imprime el registro que mantiene el actualizador, y el teléfono lee el mismo registro. El acceso de reserva de un deputy lo sirve en /standby/update mientras el puerto principal permanezca inactivo.

Si hay un nuevo evento de hook de beacon disponible, update imprime un aviso para volver a ejecutar hooks install claude.

Tras cada actualización, reversión o cambio correcto, la nueva compilación ejecuta collie skill sync. Instala la skill walky talky en cada entorno de agentes de esta máquina y actualiza las copias desactualizadas para que sus agentes reconozcan la compilación en uso. Muestra una línea por cada archivo modificado y nunca interrumpe la actualización: si no puede ejecutarse, update muestra una nota y collie skill sync se ejecuta manualmente. Omite los entornos donde se ejecutó collie skill uninstall. Defina COLLIE_SKILL_SYNC=off para conservar los archivos de instrucciones sin cambios; la actualización solo mostrará una nota si la skill está desactualizada (Instalar la habilidad).

Dónde residen las versiones

Una instalación binaria y un clon vinculado comparten la misma estructura bajo la raíz de instalación (~/.local/share/collie o $COLLIE_DIR en el caso de una instalación binaria, o el propio clon si se trata de un checkout):

current -> versions/v1.3.0
versions/v1.3.0/
versions/v1.2.0/

En un checkout, cada versions/vX.Y.Z es un worktree de git correspondiente a la etiqueta de la versión, compartiendo el único .git, por lo que una versión solo requiere un árbol y no un almacén de objetos adicional. La compilación se ejecuta dentro del nuevo directorio y escribe un marcador de finalización al concluir; el cambio de versión no se realizará sin ese marcador, por lo que una compilación interrumpida no afecta a la versión activa. La puesta en producción consiste en un único cambio de nombre del enlace simbólico current. La retención conserva current junto con las dos versiones anteriores más recientes, y la purga solo se realiza tras una ejecución correcta, garantizando que una ejecución que pueda requerir su objetivo de reversión nunca lo elimine.

Un checkout de Gestionado por Herdr es la excepción y sigue actualizándose in situ (ADR 0006, modificado el 2026-09-03). Es detached y shallow, y reside en un directorio propiedad de Herdr, por lo que no existe una estructura versions/ a su lado, nada que transferir ni nada a lo que revertir. --rollback se rechaza en este caso; el proceso de recuperación consiste en reinstalar una etiqueta específica (herdr plugin install AltanS/collie --ref vX.Y.Z --yes).

Revertir de 1.8.0 a 1.7.0 requiere dos modificaciones manuales en el directorio de estado. 1.8.0 renombra los tres archivos de estado en su primer inicio, por lo que ~/.local/state/collie/ ahora contiene crew-trust.json, crew-ops.json y crew-runtime.json, y una compilación de 1.7.0 solo lee los nombres antiguos. Renombre los tres a sus nombres anteriores antes de iniciar la compilación de 1.7.0:

cd ~/.local/state/collie
mv crew-trust.json pack-trust.json
mv crew-ops.json pack-ops.json
mv crew-runtime.json pack-runtime.json

Luego edite los nombres de dos claves dentro de pack-trust.json. 1.8.0 lee el bloque de crew con cualquiera de las dos nomenclaturas y lo reescribe como "crew", con "crewId" en su interior, donde 1.7.0 escribía "pack" y "packId". Una compilación de 1.7.0 solo lee su propia nomenclatura, de modo que una vez que 1.8.0 haya escrito el almacén (lo cual hace en cualquier unión, rotación, actualización de warrant o eliminación), vuelva a renombrar ese bloque a "pack" y su campo id a "packId". Nada más dentro de los tres archivos ha cambiado, y crew-ops.json y crew-runtime.json no requieren ninguna edición. Si prefiere no modificar el archivo, restaure una copia de pack-trust.json realizada antes de la actualización, o permanezca en 1.8.0: una compilación de 1.7.0 que no pueda leer el almacén de confianza se inicia en solitario y no aplica ningún registro de miembros.

El proceso inverso hacia 1.9.0 requiere las mismas dos modificaciones manuales. 1.8.x renombró los tres archivos automáticamente en su primer inicio; 1.9.0 no renombra nada. Por lo tanto, un directorio de estado que nunca pasó por 1.8.x aún conserva los nombres de 1.7.0, y una compilación de 1.9.0 solo lee los nombres de crew. Lo advierte al iniciar, indica ambas modificaciones y se mantiene en modo solo en lugar de adoptar el directorio. Realice los cambios antes de iniciarlo:

cd ~/.local/state/collie
mv pack-trust.json crew-trust.json
mv pack-ops.json crew-ops.json
mv pack-runtime.json crew-runtime.json

A continuación, renombre dos claves dentro de crew-trust.json: el bloque "pack" pasa a ser "crew", y cada "packId" dentro de él pasa a ser "crewId". No cambia nada más en los tres archivos. Dejar un archivo con el nombre antiguo no genera pérdida de datos, solo afecta a crew: ese collie se iniciará en modo solo hasta que se renombre.

Verificar

bin/collie update --status
herdr plugin action invoke version --plugin herdr.collie
bin/collie version

Compruebe que aparezca la etiqueta más reciente.

El paquete propio del teléfono es independiente. La PWA busca compilaciones nuevas por sí misma y se recarga en aproximadamente un minuto, pausando dicha recarga mientras dure una actualización. Si se está realizando una tarea, muestra un aviso de "pulsar para actualizar" y espera la confirmación.

En Windows

Una copia de código fuente nunca se actualiza sola en Windows; una instalación por zip sí lo hace. collie update y el botón de actualización del teléfono lo indican en una sola frase en una copia de código fuente y no cambian nada. Pasar a la instalación por zip es un paso manual que se hace una sola vez:

collie uninstall
powershell -ExecutionPolicy Bypass -File .\install.ps1

Después de eso, collie update funciona desde la terminal y desde el teléfono. Esa cadena se ensayó en una máquina virtual de Windows 11 con una copia local de los archivos de la versión, pero el traslado en sí no. Las versiones hasta la v1.15.0 inclusive tampoco podían reemplazar un collie.exe en ejecución. Consulte Collie en Windows.

Si la versión no cambió

collie update consulta a GitHub directamente en cada ejecución, git ls-remote en el caso de una descarga desde el repositorio, o la API de etiquetas de GitHub en el caso de una instalación binaria. No almacena en caché la lista de versiones. Una versión publicada hace unos segundos puede tardar un minuto en aparecer, ya que el propio GitHub necesita un momento para actualizarse. Ejecute collie doctor a continuación. Si eso no lo explica, consulte Cuando collie no se ejecute.

Si GitHub aplica un límite de peticiones a la comprobación de versiones

collie update en una instalación binaria lista los releases mediante la API de GitHub, al igual que el banner de actualización del teléfono y install.sh. GitHub limita a 60 las peticiones API por hora para usuarios anónimos, calculadas por dirección de red; todas las máquinas tras un mismo router comparten dicho límite. Al agotarse, la comprobación falla de forma segura sin aplicar cambios:

error: GitHub rate-limited the release check (HTTP 403). Wait an hour, or set GH_TOKEN
       to a GitHub token with no scopes, so the limit is yours (docs/upgrading.md).
       Nothing was changed.

Un token hace que el límite sea propio. Collie lee uno del entorno y nunca solicita ninguno:

Prevalece el primero que esté configurado. La lista de etiquetas es pública, por lo que el token necesita ningún permiso en absoluto: un personal access token de granularidad fina con acceso al repositorio establecido en Repositorios públicos (solo lectura) y sin permisos seleccionados, o un token clásico sin ningún ámbito marcado. No use un token que pueda escribir nada.

Para una única ejecución en un terminal, tome prestada la credencial de la CLI de gh. El valor nunca llega a la línea de comandos ni al historial del intérprete de comandos:

GH_TOKEN=$(gh auth token) collie update

Para el servicio, colóquelo en el .env de la instancia, que Collie mantiene en modo 600, o en config.toml bajo [update], y reinicie: el bridge lee el token al iniciarse, por lo que el banner del teléfono usa un token nuevo o modificado solo después de collie restart. collie config lo muestra como set o unset y nunca imprime el valor. El token solo se envía a api.github.com: la descarga de la versión proviene de github.com, que no tiene dicho límite, y nunca lo transporta. Un mensaje que menciona el token indica el nombre de la variable de la que provino, nunca el valor. Un token que GitHub rechaza falla la verificación con HTTP 401 y ese nombre, de modo que un token erróneo no se confunda con un límite de tasa. El bridge indica lo mismo una vez en su registro y luego conserva la última versión que detectó; por lo tanto, un banner que deja de actualizarse tras caducar un token corresponde a esa línea de registro; collie update --check lo indica cada vez que se consulte.

collie update --check informa de los mismos tres casos bajo upstream. En su lugar, un checkout enumera las etiquetas con git ls-remote, lo cual no se computa dentro del límite de la API. En una crew, cada máquina lee su propio token: un miembro se actualiza ejecutando su propio collie update, desde su propio .env.

Cambiar de versión mayor

update nunca cambia de versión mayor automáticamente.

herdr plugin action invoke update-major --plugin herdr.collie     # Herdr-managed
bin/collie update --major                                         # Standalone

Esto avanza una versión mayor hasta su versión estricta más reciente. No apunta a versiones preliminares (ADR 0020). Consulte también: Actualización de 0.x a 1.0.

Si eso falla con "You are not currently on a branch"

Las instalaciones desde GitHub anteriores a 0.23.1 carecen de una referencia de seguimiento de rama (#63). Reinstale para restaurar la funcionalidad de actualización:

# replaces the checkout, rebuilds the UI
herdr plugin install AltanS/collie --yes
# reinstall doesn't restart the service
herdr plugin action invoke restart --plugin herdr.collie
# expect 0.23.1 or newer
herdr plugin action invoke version --plugin herdr.collie

Se conserva su configuración en el directorio de configuración de plugins de Herdr, ~/.config/herdr/plugins/config/herdr.collie por convención.

Actualización del resto del crew

collie crew update <member>…      # on the lead
collie crew update --all

Esa es la ruta de terminal, para un par que el teléfono no puede nivelar. Desde el teléfono, actualice todo el equipo con un toque y una confirmación: abra Configuración → Sistema → Actualizaciones en el líder y seleccione Actualizar crew a <version>. La comprobación previa sobre el botón cubre a todos los miembros, no solo al líder. Si alguna comprobación falla, el botón se deshabilita e indica la máquina afectada y el motivo.

El lead se actualiza primero, bajo su propio control de salud. Solo cuando se ha estabilizado comienza el primer peer. A partir de la versión 1.7.0, ese orden también importa por los términos: un lead anterior a 1.7.0 lee el estado de un miembro a partir de su primera línea impresa, y un miembro 1.7.0 imprime crew … donde uno 1.6.0 imprimía pack …, por lo que un lead sin actualizar no puede leerlo. Un lead 1.7.0 lee ambos. Luego, cada peer se nivela a sí mismo: lee la versión que ejecuta su lead, obtiene esa etiqueta exacta desde GitHub y ejecuta su propio preflight, su propio control de salud y su propio rollback. Los peers avanzan uno a uno. La página Updates mantiene una línea por miembro: waiting, checking, staging, restarting, verifying, updated, rolled back o unreachable.

Un miembro se actualiza a sí mismo como máximo una vez por hora. Un miembro que se haya actualizado en la última hora, por ejemplo de forma manual, espera con rate-limited, retries in about N min debajo de su línea, y la ejecución continúa una vez transcurrido ese tiempo. Si la actualización del líder se revierte, los miembros no se tocan y sus líneas así lo indican. Una nueva actualización espera hasta que finalice la ejecución de la crew, como máximo 2 horas.

1.7.0 a 1.8.0. Actualice primero el lead de nuevo, por una segunda razón: 1.8.0 renombra las rutas de conexión, las dos claves de entorno, los tres archivos de estado y el prefijo del diario a crew. Un lead en 1.8.0 responde a las rutas antiguas de /pack/v1/* durante una versión, de modo que un miembro que siga en 1.7.0 continúa la transición a través del enlace existente. Ambas variantes antiguas desaparecen en 1.9.0. Los nombres y la función de cada uno en su máquina se describen en Actualización a 1.9.0 desde 1.7.0 o 1.8.x. Actualice cada miembro a 1.8.x antes de pasar el lead a 1.9.0: 1.9.0 no devuelve nada para las rutas antiguas, y un miembro que continúe en 1.7.0 aparecerá en rojo en la comprobación previa del lead, indicando ambas versiones y el comando que debe ejecutarse en esa máquina. El recurso collie-release.json que publica la versión define el texto de ese aviso en la barra, en la tarjeta Updates y en la notificación push diaria, sin modificar nunca el comportamiento de una actualización. También notifica a la comprobación de que hay una versión disponible: una etiqueta cuyo recurso aún responda con 404 no se ofrece, y la siguiente comprobación volverá a consultar.

Dos requisitos determinan si un peer puede seguir el proceso:

• —
  Un peer necesita HTTPS saliente hacia github.com. De ahí proviene su código. Sin ese acceso, el par se reporta como desactualizado y se nivela desde la terminal, usando el comando anterior.
• —
  Una compilación -dev+ nunca sigue el proceso. Una máquina con una compilación de desarrollo permanece en ella, sin importar lo que ejecute su lead.

Un peer que revierte la actualización lo indica en la página de Actualizaciones y no lo reintenta por sí solo. Dos rutas le otorgan otro intento:

• —
  Desde el teléfono. Una vez que el lead está al día y un peer está atrasado, el botón muestra Reintentar actualización del crew. Inicia una nueva ejecución cuyas únicas etapas son los peers, y esa nueva ejecución es lo que otorga a cada uno de ellos un intento más.
• —
  Desde la terminal, en el lead. Utilice esto para un peer que el teléfono no puede nivelar en absoluto. El comando no cambia:

collie crew update <member>…      # on the lead
collie crew update --all

Ejecutarlo en el lead constituye una única secuencia sobre su propio SSH. Primero realiza una comprobación previa en cada máquina e imprime el informe propio de cada peer junto a la respuesta obtenida por SSH, de modo que las discrepancias sean explícitas en lugar de promediarse. Solicita un único consentimiento. Luego actualiza el propio lead, si este aún no está ejecutando la compilación que distribuye. A continuación procesa cada peer por turno: al peer se le envía el commit del lead como un git bundle, se recompila, se reinicia y se sondea hasta que responde a la nueva compilación dentro del mismo plazo de 30 segundos. Un lead sin checkout de git, procedente de la instalación independiente o de un paquete, no tiene ningún commit para enviar, por lo que instala en cada peer la versión que él mismo ejecuta, sobre el mismo ssh y fijada a esa etiqueta; si un peer se ejecuta desde un checkout de git, se omite y se muestra collie update --to-tag v<version> en su fila.

El primer fallo detiene la ejecución. Todos los miembros posteriores quedan intactos y se reportan como "not attempted", y el resumen indica el comando único que subsana el fallo. Un lead que no puede aplicar su propia actualización no toca a ningún peer. Detenerse allí es seguro, ya que un crew tolera la discrepancia de versiones (CREW_PROTOCOL.md §7.1), por lo que un crew actualizado a medias es un estado admitido y continuar no lo es.

Un caso que el teléfono no puede solucionar. Si revierte el lead manualmente, con git o copiando archivos, después de que los pares se hayan nivelado, los pares quedarán en una versión superior a la de su lead. Collie no detectó la reversión, por lo que ningún miembro retrocede de versión. Una reversión realizada con Revertir versión en el teléfono o con collie update --rollback, así como un cambio de vuelta a Stable, sí hacen que los miembros retrocedan. Consulte "The crew follows the lead" en Líneas de publicación. Esas dos ejecuciones son las únicas que llevan a un miembro a una versión inferior, ya que un lead capaz de hacer retroceder a un par a voluntad podría cambiarlo a cualquier versión. El desfase derivado de una reversión manual es inocuo, y la solución es ejecutar collie crew update <member> en el lead.

El código llega a un par a través de su SSH y nunca a través del enlace de la crew (ADR 0016, adenda 2026-09-04). Cuando un par se nivela a sí mismo, su código proviene de GitHub mediante HTTPS anónimo y el par decide por sí mismo. El lead solo indica la versión que está ejecutando y qué par puede continuar.

Si el propio actualizador falla

Nada de lo anterior ayuda cuando el actualizador ya no está. Esta es la vía que asume únicamente una terminal.

El actualizador escribe un registro, <state dir>/update.json (por defecto ~/.local/state/collie/update.json, o en $COLLIE_STATE_DIR). Léalo primero: indica el estado, la versión de origen de la ejecución, la versión de destino, el pid del actualizador y, en caso de fallo, el final del registro del servicio y el comando de recuperación.

Una actualización iniciada desde el teléfono no imprime nada en la terminal. En Linux con un gestor de usuarios de systemd se ejecuta bajo una unidad transitoria propia, llamada collie-api-update-<stamp>, y --collect elimina esa unidad en cuanto finaliza, por lo que su registro solo queda en el journal:

journalctl --user -u 'collie-api-update-*' --since '30 min ago'

En cualquier otro entorno, incluido macOS, la salida del actualizador va a un archivo en el directorio de estado:

cat ~/.local/state/collie/update-runner.log

Cada actualización iniciada desde el teléfono vacía ese archivo y conserva la ejecución anterior como update-runner.log.1. En el nivel de systemd, el archivo contiene solo la línea que imprime systemd-run, y el journal mencionado contiene el resto.

Un miembro de la crew puede permanecer en la versión antigua tras una actualización de crew. Su checkout muestra entonces la nueva etiqueta, pero /standby/health o el pie de página siguen mostrando la compilación antigua. Compruebe que no se esté ejecutando ningún actualizador con systemctl --user list-units 'collie-api-update-*'. Si no se ejecuta ninguno, ejecute collie update en esa máquina. Esto recompila un checkout cuya compilación no haya finalizado.

Una ejecución que se interrumpe antes del cambio, por ejemplo si una nueva versión no inicia en esta máquina, no modifica nada en el disco. El teléfono que la inició indica que la actualización falló en esa máquina y muestra el motivo, que coincide con el campo reason de update.json.

Ahí es donde se debe mirar cuando el teléfono reportó éxito y algo posterior no ocurrió: una advertencia de que el registro de ejecución no se pudo escribir, por ejemplo, lo que corresponde a un lead que se actualizó y no nivelará a su crew. El propio registro del puente contiene la otra mitad: una línea [crew] update <run id>: levelling peers to <version> por ejecución, cuando el lead toma el registro. Antes de 1.8.0 ese prefijo era [pack]. Si no existe tal línea, los turnos nunca comenzaron.

Una actualización previa a la versión 1.5.4 bloqueada en bunx

Antes de la versión 1.5.4, las actualizaciones iniciadas desde un teléfono se ejecutaban en una unidad de usuario transitoria de systemd que no incluye su PATH. Cuando Bun solo se encuentra en ~/.bun/bin en una instalación por checkout, el checkout avanza, pero la recompilación falla con bunx: command not found. Corrija esto ejecutando collie update una vez desde una terminal donde Bun esté en el PATH, o ejecute la acción de Herdr, cuyo shim localiza Bun por sí mismo. Cualquiera de los dos métodos recompila el checkout avanzado. A partir de la versión 1.5.4, el actualizador encuentra Bun de forma automática.

Junto a él se encuentra <state dir>/update.lock, que contiene un pid y una marca de tiempo. Una sola ejecución a la vez. Un registro que todavía muestre preflight, staging, restarting o verifying, no haya cambiado en 10 minutos y cuyo pid ya no esté en la tabla de procesos, ha terminado: se interpreta como interrupted, y una nueva ejecución puede adquirir el bloqueo.

Para restaurar la versión anterior manualmente, apunte current hacia ella y reinicie:

cd ~/.local/share/collie        # or $COLLIE_DIR, or the checkout root
ls versions/
ln -sfn versions/<previous> current
collie restart

O permita que la versión anterior haga lo mismo, que es el comando que incluye un registro stuck:

~/.local/share/collie/versions/<previous>/bin/collie update --rollback

Utilice la ruta completa, no collie: el nombre en su PATH se resuelve mediante current, y current es lo que puede ser incorrecto.

Lo que la comprobación de estado no detecta

La comprobación demuestra una sola cosa: el servicio volvió a iniciarse y respondió a /api/health con la versión instalada. Esa es una garantía limitada, no una promesa de "nunca fallar". Cuatro elementos pueden estar dañados mientras la comprobación informa un resultado correcto:

• —
  Un paquete web obsoleto en el teléfono. El host tiene la versión nueva y el teléfono sigue ejecutando JavaScript antiguo desde su service worker. La PWA reemplaza su propio paquete según su propia programación; la comprobación de estado no tiene visibilidad sobre ello.
• —
  Migraciones de configuración o de esquema. Collie no distribuye ninguna con esta frecuencia y el actualizador no ejecuta ninguna. La comprobación verifica que el servicio responda, no que sus datos tengan la estructura correcta.
• —
  Un controlador de mux que falla solo al interactuar. El bridge se inicia y responde al estado de salud mientras el adaptador falla en la primera conexión o envío real. La comprobación de estado es un sondeo de actividad, no una ejecución de conformidad.
• —
  El actualizador ejecutando el código de la versión anterior. El actualizador desacoplado se inicia desde la versión que se está reemplazando. Se mantiene pequeño y estable, y su registro está versionado, por lo que un actualizador antiguo y un bridge nuevo aún se entienden, pero esto es una mitigación y no una garantía.

Resolución de la versión más reciente desde un script

Consultar las etiquetas de git y ordenar por semver. Evitar GET /repos/AltanS/collie/releases/latest, que excluye las versiones preliminares.

# newest stable release
git ls-remote --tags --refs https://github.com/AltanS/collie | \
  sed 's#.*refs/tags/##' | grep -E '^v[0-9]+\.[0-9]+\.[0-9]+$' | sort -V | tail -1

Líneas de publicación

Cada máquina pertenece a una de dos líneas de publicación. La opción predeterminada es Stable.

• —
  Stable solo admite versiones definitivas, por ejemplo 1.23.0.
• —
  Edge también admite compilaciones Edge, por ejemplo 1.23.0-edge.2. Una compilación Edge es una versión preliminar de GitHub, generada a partir del mismo árbol pocos días antes de la versión definitiva. Llega primero a los voluntarios, de modo que se detecta cualquier regresión antes de distribuirse de forma general.

Defina la línea en el teléfono: Settings → Updates → Release line. El cambio no instala nada. Guarda la línea y muestra una confirmación. La tarjeta Updates ofrece a continuación lo que disponga la nueva línea, a través de la pantalla habitual de actualización.

• —
  En Edge, la oferta consiste en la compilación más reciente superior a la que se está ejecutando, combinando compilaciones Edge y versiones definitivas dentro de la misma versión mayor. Una versión definitiva sustituye a sus propias compilaciones Edge en ambas líneas.
• —
  Una compilación desde la cual se haya revertido esta máquina nunca se vuelve a ofrecer, en ninguna de las líneas.
• —
  En Edge, la notificación push sobre una nueva compilación se envía en la siguiente comprobación, no en el siguiente resumen periódico. Se respeta la espera hasta las 09:00, hora local. Stable conserva los intervalos de resumen.

Frecuencia esperada en Edge. Cabe esperar como máximo una compilación Edge al día, y cada una incluye un cambio visible. El puente busca nuevas compilaciones cada seis horas. Se recibe una notificación push por compilación, nunca antes de las 09:00 hora local del host. Cuando una comprobación detecta varias compilaciones nuevas, se agrupan en una sola notificación. La barra de actualización pregunta una vez por compilación, y es posible omitir una versión: la siguiente actualización adoptará la más reciente. Descartar la barra aplica solo a esa versión, por lo que la siguiente compilación volverá a preguntar.

Volver a Stable. Al cambiar a Stable en una máquina que ejecuta una compilación Edge, la página presenta uno de tres casos:

1. 01
   Existe una versión definitiva igual o superior a su compilación. La tarjeta Updates la ofrece como una actualización normal.
2. 02
   Su compilación Edge es superior a cualquier versión definitiva. La página ofrece dos opciones: - Volver ahora instala la versión definitiva más reciente inferior a su compilación, tras una confirmación. Utiliza la compilación Stable conservada en la máquina, si existe, o la descarga si no es así. Si esa versión no puede leer un archivo de estado de su compilación, la página indica el nombre del archivo antes del botón. - Esperar a Stable conserva su compilación. No se ofrecerán más compilaciones Edge, y la siguiente versión definitiva se ofrecerá el día de su publicación.
3. 03
   Ya se ejecuta una versión definitiva. No hay ninguna acción pendiente.

Compilaciones conservadas. Mientras una máquina permanece en Edge, conserva la compilación activa, la compilación anterior y la última compilación de Stable. La última compilación de Stable no se purga hasta que la máquina vuelve a Stable, de modo que "Volver ahora" consiste en un cambio y no en una descarga.

Revertir versión. Revertir desde una compilación Edge sitúa la máquina en Stable y marca dicha compilación como revertida. Esto aplica tanto a Revertir versión en el teléfono como a collie update --rollback. Una compilación Edge que falla su propia comprobación de estado es revertida por el actualizador y se marca del mismo modo, evitando que vuelva a ofrecerse. La línea permanece en Edge, y la siguiente compilación Edge se ofrece con normalidad.

El crew sigue al lead. La línea del lead determina la línea del crew. Un miembro sigue a su lead a una compilación Edge cuando este se encuentra en Edge, y adopta la línea del lead como propia. Un miembro solo retrocede de versión si el lead revirtió o volvió a Stable. Esos son los dos únicos casos en los que un miembro instala una versión inferior. La página Crew muestra la línea que siguen los miembros.

Desde el terminal. La línea se define en el teléfono. Existen dos opciones para ejecuciones individuales:

collie update --line edge                     # resolve this one run on Edge; the saved line stays
collie update --to-tag v1.22.6 --downgrade    # go down to a lower final release

--to-tag nunca toma una etiqueta inferior sin --downgrade. Solo toma una etiqueta Edge superior en una máquina que esté en Edge. En una instalación administrada por Herdr, ambas líneas y el camino de regreso pasan por la misma actualización en el lugar: el actualizador comprueba la etiqueta y escribe el sufijo Edge en los archivos de versión.

Versiones preliminares

Las instalaciones estables no reciben versiones preliminares. Las compilaciones Edge son la excepción, en la línea Edge (consulte Líneas de publicación). Al optar por una versión preliminar, se realiza el seguimiento de las versiones preliminares de esa versión mayor hasta que llegue la versión final (ADR 0020):

# Standalone — the install script's opt-in flag takes the newest prerelease
curl -fsSL https://colliepwa.dev/install.sh | sh -s -- --beta

# Herdr-managed — install the tag; that is the whole opt-in
herdr plugin install AltanS/collie --ref <tag> --yes
# a reinstall does not restart the service
herdr plugin action invoke restart --plugin herdr.collie

Resolver <tag> usando Resolución de la versión más reciente desde un script.

Para volver a las versiones estables:

herdr plugin install AltanS/collie --yes
herdr plugin action invoke restart --plugin herdr.collie

Actualización a 1.24.0

La versión 1.24.0 añade puntos de uso, un botón Detener y un diseño para pantallas grandes. Si proviene de 1.23.4, no es necesario hacer nada el día de la actualización. Lo que se notará:

• —
  Collie no modifica su statusLine. Envolverlo es opcional mediante collie hooks install claude --statusline. Si se adoptó la envoltura desde una compilación Edge y se desea eliminar, ejecute collie hooks uninstall claude, luego collie hooks install claude (Collie escribe hooks en la propia configuración de Claude).
• —
  El punto de contexto no necesita un gancho nuevo. Los ganchos instalados por 1.23.4 ya incluyen SessionStart y ejecutan el mismo comando. El nuevo Collie lee el archivo de sesión con ellos. Si nunca se ejecutó collie hooks install claude, ejecútelo una vez. Una sesión de Claude que ya esté en ejecución no muestra ningún punto hasta que se inicie de nuevo, se reanude, se limpie o se compacte, ya que el tamaño de la ventana proviene del inicio de la sesión.
• —
  Los puntos de 5 horas y 7 días leen sus propios inicios de sesión. Para Claude, Collie lee el archivo de inicio de sesión en esta máquina y consulta api.anthropic.com. Para Codex, lee los archivos de sesión de Codex y no consulta a nadie. Ambos están activados de forma predeterminada. Establezca COLLIE_ACCOUNT_WINDOWS=0 en su .env, o account_windows = false bajo [bridge], para desactivarlos. OpenCode Go y Grok permanecen desactivados hasta que se indiquen (Ventanas de uso).
• —
  Un botón Detener, un botón Limpiar y Dirigir. Detener requiere dos toques y pulsa la propia tecla de parada del agente (Detener un turno). Limpiar vacía el cuadro de entrada y Restaurar vuelve a escribir el texto durante dos minutos (Vaciar el cuadro). Mantenga presionado Enviar para dirigir un turno en ejecución en pi, Codex y OMP (Redirigir o encolar).
• —
  Un tema que define pane-active es de versión 3. Un Collie anterior a 1.24.0 rechaza ese archivo con un mensaje que indica la versión. Los demás temas conservan su versión (Versiones).
• —
  Una pantalla ancha muestra una barra lateral. A partir de 600px de ancho y 480px de alto, la pantalla de paneles muestra varios paneles uno al lado del otro. Para mantener el diseño móvil en un dispositivo, configure Diseño para pantallas grandes en Off en Settings.

Actualización a 1.19.0

La versión 1.19.0 traslada el inicio de elementos a una sola página y permite que cada teléfono configure sus propias Keys y lanzadores. No es necesario realizar ninguna acción el día de la actualización. Cambios visibles:

• —
  La hoja New es ahora una página. + Nuevo en el panel abre /new, con la máquina, un selector de Agent o Command, la carpeta y un interruptor Nuevo worktree. La hoja new-space, su etiqueta space y su lista de worktrees existentes han desaparecido. Abra un worktree existente con herdr worktree open en la máquina (Iniciar un agente o una shell desde el teléfono).
• —
  Un crew member debe actualizarse para iniciar agentes por nombre. La página muestra un member que ejecuta una versión anterior de Collie con sus opciones deshabilitadas. Actualice primero el lead y luego los members (Iniciar algo en una máquina).
• —
  Los teléfonos pueden añadir lanzadores. Con el valor predeterminado [phone] adds = true, un teléfono emparejado puede añadir hasta 20 filas a una máquina, almacenadas en launchers-added.json. Defina adds = false en launchers.toml para desactivarlo (Lanzadores añadidos desde un teléfono).
• —
  El pad de Keys es un tablero. Se inicia con el pad anterior y cada navegador conserva su propia disposición (Teclado propio). Los ajustes predefinidos en keys.toml no cambian.
• —
  Un nombre de carpeta simple es una carpeta dentro del directorio de inicio. projects en el campo Folder equivale ahora a ~/projects, y una carpeta que no exista se rechaza con un aviso.

Actualización a 1.18.0

La versión 1.18.0 hace obligatorio el emparejamiento tanto para lecturas como para escrituras (ADR 0086). Cambios el día de la actualización:

• —
  Los teléfonos emparejados siguen funcionando. Su token almacenado ya cumple la nueva regla. No se requiere ninguna acción.
• —
  Los navegadores no emparejados muestran la pantalla de emparejamiento. Un navegador de escritorio que nunca se emparejó y antes podía leer, ahora recibe 403 device not paired. Ejecute collie pair en el host e introduzca el código en Configuración en ese navegador (Emparejar un dispositivo).
• —
  Una app instalada puede mantener las pantallas anteriores durante una carga más. Una app instalada puede seguir mostrando las pantallas de la versión anterior hasta que se vuelva a cargar una vez más. Si muestra "Sign in" tras actualizar a la versión 1.18 o posterior, recargue la app, o ciérrela y vuelva a abrirla. Luego, emparéjela como se indicó anteriormente.
• —
  Los scripts deben emparejarse una vez. Un script que leía la API sin un token ahora recibe 403. Ejecute collie pair --expires 30d y reclame el código con un POST a /api/pair que incluya {"code": "...", "label": "script"} y un encabezado Origin del mismo origen. El token se devuelve una sola vez, en esa respuesta. Envíelo como Authorization: Bearer <token> en cada llamada posterior. Guárdelo como una contraseña.
• —
  Las CLI del host no requieren nada. collie doctor, collie history y el barrido de actualización del equipo leen su propio bridge con una credencial local que el bridge escribe en el directorio de estado.
• —
  Volver a una versión anterior a 1.18.0 ignora la caducidad de los tokens. Un bridge más antiguo no reconoce el campo expiresAt, por lo que un dispositivo caducado vuelve a funcionar hasta que se actualice el bridge. Revóquelo con collie devices revoke <label> si es necesario (Asignar una caducidad a un dispositivo).
• —
  Los archivos de auditoría antiguos pueden contener caracteres tecleados. Los archivos escritos antes de 1.18.0 pueden listar caracteres tecleados en el teléfono. Rote o elimine los archivos audit.log anteriores a la actualización.
• —
  El enmascaramiento puede interferir. El contenido de los archivos en Files y las diferencias en Changes ahora pasan por la misma máscara de secretos que el texto del panel. Si oculta algo necesario, defina COLLIE_REDACT=off en su .env y reinicie (configurar).
• —
  Un lead en 1.18.0 también enmascara el texto de sus miembros. Un miembro que aún esté en 1.17.x no aplica la máscara, por lo que el lead enmascara el texto de ese miembro antes de que llegue a su teléfono. Para ver el texto de un miembro sin enmascarar, defina COLLIE_REDACT=off tanto en el lead como en el miembro.

Actualización de 0.x a 1.0

Si BUN_INSTALL está definido solo en .env, expórtelo en su perfil de shell o en el entorno del servicio. Luego ejecute:

# Herdr-managed
herdr plugin action invoke update-major --plugin herdr.collie

# Linked clone
bin/collie update --major

Verificar con bin/collie version o herdr plugin action invoke version --plugin herdr.collie.

Para configuraciones de crew: Actualice primero el lead y luego ejecute collie crew update <member>… (Actualización del resto del crew). Nota:

• —
  join requiere --insecure para leads http:// simples.
• —
  Los tokens de invitación anteriores a 1.0 deben regenerarse con crew invite.
• —
  Los registros de miembros antiguos requieren reconnect.
• —
  Los pares no actualizados se muestran como warn: en crew status (CREW_PROTOCOL §7.1).

Qué cambia 1.0 para usted

Los ID de acción de Herdr y las rutas de scripts/collie-ctl.sh no han cambiado (ADR 0006).

Los verbos de la CLI se compilan en <checkout>/bin/collie (Comandos). Utilice bin/collie link para añadir collie al PATH (Añadir collie al PATH, ADR 0021).

Nuevas funciones:

• —
  pair / devices: Credenciales de escritura por dispositivo (Emparejar un dispositivo).
• —
  crew … / join / promote: Clústeres multihost (Comandos de crew).
• —
  doctor: Diagnóstico de configuración.
• —
  stt setup: Configuración del compositor de voz (Entrada de voz).
• —
  hooks install claude / beacon emit: Balizas de actividad de agentes (Beacons de agentes).
• —
  COLLIE_MUX: Seleccione herdr (predeterminado), tmux o zellij (tmux y zellij).

Lado a lado, si el herd es real

La configuración de la instancia secundaria está documentada en Múltiples instancias de Collie en un mismo host.

Reversión de cambios

Haga checkout de la última etiqueta 0.x y vuelva a compilar:

last0x=$(git ls-remote --tags --refs origin | sed 's#.*refs/tags/##' | \
  grep -E '^v0\.[0-9]+\.[0-9]+$' | sort -V | tail -1)
git fetch --depth 1 origin tag "$last0x"
git checkout --detach --force "$last0x"
rm -f bin/collie    # 1.0's binary otherwise survives the rollback

Vuelva a compilar con bash scripts/collie-ctl.sh build e invoque la acción restart de Herdr. Los archivos de estado (crew-trust.json, crew-runtime.json, paired-devices.json, pairing-pending.json) pueden conservarse. La reversión elimina la obligación de emparejamiento de dispositivos; configure COLLIE_DEVICE_HEADER si se requiere protección contra escritura.

Comprobar que funcionó

Compruebe que version reporte 1.0.0 o superior. Una instalación actualizada no empareja ningún dispositivo automáticamente: ejecute pair para emitir la credencial de escritura a un teléfono, y devices revoke si dicho teléfono se pierde (Emparejar un dispositivo).

Detener o desinstalar

Pausar el servicio:

herdr plugin action invoke stop --plugin herdr.collie     # Herdr-managed
bin/collie stop                                           # standalone

Eliminar la definición del servicio y las asignaciones de puertos (se conservan .env y los checkouts):

herdr plugin action invoke uninstall --plugin herdr.collie   # Herdr-managed
bin/collie uninstall                                         # standalone

Para eliminar el programa y también sus propios archivos, siga los tres pasos descritos en Instalación → Desinstalación, detallados según el tipo de instalación, incluidos los paquetes.

Cuando collie no se ejecute

Para instalaciones binarias (~/.local/share/collie o $COLLIE_DIR), ejecute directamente un binario anterior:

ls ~/.local/share/collie/versions/
~/.local/share/collie/versions/<previous>/bin/collie update --rollback

Para instalar una versión específica directamente:

curl -fsSL https://colliepwa.dev/install.sh | COLLIE_TAG=v1.0.0 sh

Para checkouts o instalaciones con Herdr, ejecute git checkout <tag> o herdr plugin install AltanS/collie --ref vX.Y.Z --yes.

Uso de un fork

collie update compara origin con COLLIE_UPDATE_REPO (por defecto AltanS/collie) y se interrumpe si difieren. Establezca COLLIE_UPDATE_REPO=you/collie si su fork publica sus propias etiquetas.

Para fusionar manualmente las actualizaciones de upstream en su fork:

git remote add upstream https://github.com/AltanS/collie.git
git fetch upstream --tags
git merge v1.0.0                                            # the tag you decided to take
# resolve the conflicts, commit the merge, then rebuild and restart:
bash scripts/collie-ctl.sh build
# Herdr-managed: invoke the `restart` action instead
bin/collie restart

No use update --major en un fork; fusione la etiqueta v1.* manualmente. Ejecute collie doctor para comprobar el COLLIE_UPDATE_REPO activo.

Persistencia tras reinicios

En Linux, habilite lingering para servicios de usuario desatendidos:

loginctl enable-linger $USER

Compruebe el estado con systemctl --user status collie.

En macOS, start gestiona ~/Library/LaunchAgents/herdr.collie.plist automáticamente. Se ejecuta al iniciar sesión el usuario. Compruebe el estado con launchctl print gui/$(id -u)/herdr.collie.