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 pack, un miembro empaquetado nunca recibe una actualización desde el teléfono. El pack lo lista como "waits for the package manager" y contabiliza la ejecución como 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 enlace simbólico, reiniciar y comprobar que el servicio responda. En un lead de pack, ambas rutas cubren todo el pack. El teléfono es la ruta corta. La terminal es el recurso de reserva 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 ubica la comprobación previa, con una línea por cada verificación: doctor, disk, bun, tree, upstream y service. En un líder, también se comprueba cada miembro del pack.

• —
  Verde está despejado.
• —
  Ámbar es información útil y nunca bloquea: desfase de versiones en un pack, un tipo de instalación inusual, una versión principal disponible que no se está aplicando. Los archivos de borrador no rastreados 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.

Mientras se ejecuta, la tarjeta muestra su estado:

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 cambio que solo contiene versiones patch espera a una ventana semanal, de modo que una serie de parches llega en una sola notificación en lugar de cuatro; una versión minor o major mantiene la frecuencia diaria e incluye los parches pendientes. Las versiones retenidas se agrupan, nunca se descartan. La tarjeta siempre muestra el estado actual con independencia de la ventana. La preferencia de notificación updates, en Ajustes → notificaciones (Web Push), es el único interruptor de apagado.

En un lead de pack, el botón muestra Actualizar pack a <version> y una sola confirmación se aplica a todas las máquinas. El lead se actualiza primero, bajo su propia puerta de enlace de salud. Luego, cada peer se nivela a sí mismo a la misma versión, uno a la vez, utilizando su propio preflight, su propia puerta de enlace de salud y su propio rollback. No hay ningún botón por peer ni un segundo aviso de confirmación. Para obtener detalles, conocer las dos rutas de recuperación y el único caso que el teléfono no puede resolver, consulte Actualizar el resto del pack.

Una franja en la parte superior de cada pantalla muestra la ejecución: la versión disponible, luego Starting update…, Updating to <version>, Updated to <version>. Tap to reload. y finalmente Updating <n> peers: <names> a medida que los peers la siguen. Los peers que hayan revertido también se indican allí, con Consulte Actualizaciones. para volver a la página. La franja aparece en esta secuencia:

Desde el terminal

collie update --check            # read-only preflight, --json for a script
collie update --check --local    # the same, this instance only, no pack 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

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 cambia 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 servicio, y en un lead consulta lo mismo a cada miembro del pack mediante su propio SSH. Sale con código 0 a menos que algo esté en rojo, y --json imprime un informe con versión. Añada --local para comprobar únicamente esta instancia y omitir los miembros del pack. El teléfono ejecuta esa comprobación local en su propio host y lee la línea de cada peer a través del enlace de pack, por lo que su preflight 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.

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).

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.

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.

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.

Actualizar el resto del pack

Actualice un pack desde el teléfono con un solo toque y una sola confirmación. Abra Configuración → Actualizaciones en el lead y seleccione Actualizar pack a <version>. El preflight sobre el botón cubre a todos los miembros, no solo al lead. Si una comprobación aparece en rojo en algún punto, el botón se deshabilita e indica la máquina que falla y el motivo.

El lead se actualiza primero, bajo su propia puerta de enlace de salud. Solo cuando se ha estabilizado comienza el primer peer. Luego, cada peer se nivela a sí mismo: lee la versión que ejecuta su lead, obtiene esa etiqueta exacta de GitHub y ejecuta su propio preflight, su propia puerta de enlace de salud y su propio rollback. Los peers avanzan uno a la vez. La página de Actualizaciones mantiene una línea por miembro: waiting, checking, staging, restarting, verifying, updated, rolled back o unreachable.

Dos requisitos determinan si un peer puede seguir el proceso:

• —
  Un peer necesita HTTPS saliente hacia github.com. De allí proviene su código. Sin ese acceso, el peer se reporta como atrasado y se nivela desde la terminal, como se explica más abajo.
• —
  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 de pack. 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 pack update <member>…      # on the lead
collie pack update --all

Se ejecuta como una sola secuencia a través de su propio SSH. Primero realiza el preflight de cada máquina e imprime el informe propio de cada peer junto a la respuesta que obtiene mediante SSH, de modo que cualquier discrepancia sea explícita y no promediada. Solicita un único consentimiento. Luego actualiza el propio lead si este aún no ejecuta la compilación que está distribuyendo. A continuación, procesa cada peer por turno: se envía al peer el commit del lead como un git bundle, se recompila, se reinicia y se sondea hasta que responda con la nueva compilación dentro del mismo margen de 30 segundos.

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 soluciona el fallo. Un lead que no puede aplicar su propia actualización no interviene en ningún peer. Detenerse allí es seguro, porque un pack tolera el desfase de versiones (PACK_PROTOCOL.md §7.1), por lo que un pack actualizado a medias es un estado admitido, mientras que forzar la continuación no lo es.

Un caso que el teléfono no puede solucionar. Si revierte el lead manualmente después de que sus peers se hayan nivelado, los peers quedan por delante de su lead. Nada degrada la versión de un peer: un lead que pudiera retroceder un peer sería un lead que podría moverlo a cualquier versión. El desfase es inocuo y la solución es collie pack update <member> en el lead.

El código llega a un peer a través de su SSH y nunca mediante el enlace de pack (ADR 0016, adenda 2026-09-04). Cuando un peer se nivela a sí mismo, su código proviene de GitHub a través de HTTPS anónimo y el peer decide por sí mismo. El lead solo indica la versión que está ejecutando y qué peer 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 por el teléfono no se imprime en la terminal. Se ejecuta en su propia unidad transitoria de systemd, llamada collie-api-update-<stamp>, y --collect elimina esa unidad tan pronto como finaliza, por lo que su transcripción solo queda en el journal:

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

Allí es donde debe buscarse cuando el teléfono informa que la operación tuvo éxito y algo posterior no ocurrió; por ejemplo, una advertencia de que no se pudo escribir el registro de ejecución, lo que indica un lead que se actualizó a sí mismo y no nivelará su pack. El propio journal del bridge contiene la otra mitad: una línea [pack] update <run id>: levelling peers to <version> por ejecución, cuando el lead recoge el registro. Si no existe tal línea, los turnos nunca se iniciaron.

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

Versiones preliminares

Las instalaciones estables no reciben versiones preliminares. Optar por una versión preliminar sigue las versiones preliminares de esa versión mayor hasta que se publique 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 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 pack: Actualice primero el lead y luego ejecute collie pack update <member>… (Actualizar el resto del pack). Nota:

• —
  join requiere --insecure para leads http:// simples.
• —
  Los tokens de invitación anteriores a 1.0 deben regenerarse con pack invite.
• —
  Los registros de miembros antiguos requieren reconnect.
• —
  Los pares no actualizados se muestran como warn: en pack status (PACK_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).
• —
  pack … / join / promote: Clústeres multihost (Comandos de pack).
• —
  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 (pack-trust.json, pack-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 los archivos restantes: ejecute herdr plugin uninstall herdr.collie (gestionado por Herdr), o ejecute bin/collie unlink y elimine ~/.local/share/collie / $COLLIE_DIR (independiente).

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.