管理とアップデート

Herdr によるインストールでは PATH に collie が含まれません。Herdr のアクション ID (Herdr アクション) を使用してください。スタンドアロンインストールの場合は、バイナリが ~/.local/share/collie/current/bin/collie または <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

bin/collie link を実行すると、バイナリへのシンボリックリンクが ~/.local/bin に作成されます (collie を PATH に追加)。

設定と状態はチェックアウトの外部に保存され、アップデート後も保持されます (bridge/solo-baseline.test.ts)。.env と tailscale serve レコードは設定ディレクトリ (バイナリインストールの場合は ~/.config/collie、Herdr インストールの場合は Herdr のプラグイン設定ディレクトリ) にあります。ペアリングされたデバイスと stt.json は状態ディレクトリ (COLLIE_STATE_DIR で変更していない限り ~/.local/state/collie) にあります。

パッケージ管理されたインストール

パッケージマネージャー経由で Collie をインストールした場合、更新もパッケージマネージャーが行うため、本セクション以降の内容は該当しません:

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

Collie はディスク上の状態（.git が存在しない、versions/ のレイアウトでない、リリースペイロードに含まれるマニフェストが存在する、ルートが読み取り専用／ホームディレクトリ外／root所有のいずれかである）からこのインストール形態を認識します。後者の3つの条件は、いずれか1つを満たせば十分です。この場合、Collie は自身でのインプレース更新を拒絶し、フォルダーを管理するパッケージマネージャーを特定できる場合はそのコマンドを案内します:

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

プレフィックスから Collie が認識可能なマネージャーを特定できない場合、実行できないコマンドを推測して表示することはせず、最初の2行を出力して終了します。

collie doctor は同じインストールを正常と報告し、スマートフォンの更新カードには更新ボタンの代わりにパッケージコマンドが表示され、新しいリリースが存在することが引き続き示されます。

注。 これは回避すべき制限ではありません。このフォルダーはパッケージマネージャーが管理しており、その背後でファイルを置き換えると、インストール内容に関するデータベースの整合性が崩れます。sudo collie update も同様に処理を拒否します。

新しいバージョンを適用するには、パッケージマネージャーを実行した後にサービスを再起動してください。

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

miseによるインストールは例外です。ツリーがホームディレクトリ内に配置され、.git も versions/ のレイアウトも存在しないため、Collieはこれをパッケージ化されたものとして認識しません。そのため collie update は cannot tell how this Collie was installed で拒否し、マネージャー名を提示しません。管理は引き続きmise側で行われます。インストール を参照してください。

再起動はCollieが自動で実行できない必須の手順です。パッケージマネージャーは実行中のbridgeの背後でファイルを置き換えるため、プロセスはすでに新バージョンを報告していながら、古いコードを実行し続けます。Collieはこの不一致を検知して通知します。collie doctorはrestart-pendingを発生させ、電話には「Bridge restart needed」バナーが表示され「Collie was replaced on disk. Restart it.」と案内されます。どちらもcollie restartを実行した時点で解消されます。

crewでは、パッケージ管理されたメンバーがスマートフォンからアップデートを受け取ることはありません。crewはそれを「パッケージマネージャー待ち」として一覧表示し、そのメンバーを除外して実行を完了とみなします。そのため、上記2つのコマンドでバージョンを揃えます。

パッケージ化された lead は、自身の移行のみを拒否します。スマートフォンは現在leadが実行しているバージョンへと全memberを引き続き揃え、1回の確認操作でそれらが対象になります。上記の2つのコマンドでleadを移行した後は、自動で揃うことはありません。「Updates」ページをもう一度タップすると、memberがleadの新しいバージョンに追従します。

スマートフォンまたはターミナルからのアップデート

2つのアップデート経路が存在し、どちらも各ホスト上で同じ手順を実行します。稼働中のリリースの隣に新しいリリースをステージングし、シンボリックリンクを切り替え、再起動して、サービスが応答することを確認します。crewリード上では、どちらの経路でもcrew全体が対象になります。スマートフォンは手軽な経路です。ターミナルは、スマートフォンで揃えられないマシンに対するフォールバックです。

スマートフォンから

設定を開き、アップデートを選択します。カードには稼働中のバージョン、最新リリース、およびアップデートに含まれる中間バージョンが表示されます。ホストがすでに最新リリース上にある場合、カードにその旨が表示され、操作は何も提示されません。

その下には事前チェックが1チェックにつき1行で並びます: doctor、disk、bun、tree、upstream、service。リード上では、すべてのcrewメンバーもチェックされます。

• —
  緑は問題ありません。
• —
  黄は把握しておく価値がありますが、処理をブロックすることはありません。crew間のバージョンの不一致、通常とは異なるインストール種別、リリース済みだが適用されていないメジャーバージョンなどが該当します。チェックアウト内の追跡対象外の作業ファイルは緑色のままです。
• —
  赤はアップデートをブロックします。行には、赤状態のcollie doctor、ステージングビルド用空き容量が1GB未満、ホスト上にbunが存在しない、アップストリームに到達できないなどの理由が表示されます。1つのコマンドで解消できる場合、カードにそのコマンドがFix: <command>として表示されます。

<version>にアップデートをタップすると確認が1回求められます。確認テキストの内容どおりに処理されます。ターミナルセッションは維持され、スマートフォンの表示は最大30秒間切断されます。再起動で停止するのはブリッジのみでマルチプレクサは停止しないため、エージェントは実行を継続し、スマートフォンは新しいバージョンで再接続されます。定期アップデートでメジャーバージョンが自動適用されることはありません。メジャー移行時には専用の確認が行われ、バージョンが新しいメジャーとして明記され、最初にリリースノートを読むよう指示されます。

実行中はシートが画面に表示されます。下のアップデート実行中のスマートフォンの表示を参照してください。「Updates」ページのカードにも同じ状態がより詳細に表示されます:

最初の4つは進行状況を示します。カードにその旨が表示され、画面を開いたままにするよう求められます。rolled-back は現在留まっているバージョン名とサービスログの末尾を表示し、再試行 を提示します。stuck はターミナルで実行するコマンドを1つ表示します。interrupted では 再試行 も提示されます。

次のダイジェストで通知 はカードの通知を非表示にします。ミュートではありません。次のプッシュ通知は、より新しいリリースと新しい配信枠の両方を待ってから行われます。

通知の頻度 更新のプッシュ通知はダイジェスト形式で、最大でも1日1回、ホストの現地時間9:00より前には送信されません。パッチリリースのみの差分は週次の枠まで待機するため、パッチトレインは4回ではなく1回のプッシュで届きます。マイナーまたはメジャーリリースは日次の頻度を維持し、待機中のパッチもまとめて適用されます。保留されたリリースは集約され、破棄されることはありません。パッチ側から日次の頻度を要求することもできます。当日中の適用が必要な修正はリリース時に緊急とマークされ、更新カードに緊急ラベルとその理由を説明する1文が表示されます。通知はリリース時、またはリリース後最初の9:00に行われます。緊急リリースが1つあると、待機中のトレイン全体が日次扱いになりますが、バージョン自体は通常のパッチのままです。この機能の導入前からのインストール環境では、一度更新されるまで緊急パッチでも週次の枠が維持されます。通知枠に関わらず、カードには常に現在の状態が表示されます。設定 → 通知（Web Push）にあるupdates通知設定が、唯一の無効化スイッチです。

crewリード上ではボタンにcrewを<version>にアップデートと表示され、1回の確認ですべてのマシンに適用されます。リードが自身のヘルスゲートに従って最初にアップデートされます。その後、各ピアが自身の事前チェック、ヘルスゲート、ロールバックを使用して、1台ずつ同じリリースにバージョンを揃えます。ピアごとのボタンや2回目の確認プロンプトはありません。詳細、2つの復旧経路、およびスマートフォンで修正できない1つのケースについては、残りのcrewのアップデートを参照してください。

各画面の上部にある帯には、実行中の処理ではなく待機中の状態が表示されます。提供中のリリース、アップデートできなかったピア、および手元のアプリがブリッジより古い場合のNew version — tap to updateなどです。実行中のアップデートは帯ではなくシートに表示されます。

アップデート実行中のスマートフォンの表示

確認をタップしたデバイスではシートが画面に表示され、その他のすべてのデバイスにはバッジが表示されます。

シートにはマシンごとに1行ずつ、リードを先頭としてそれぞれのバージョンと現在の状態が表示されます。その下には、マシンではなく手元のアプリに関する、このデバイス自体の行が表示されます。ブリッジが新しいバージョンの配信を開始すると、スマートフォンはバックグラウンドでそのアプリを取得し、この行に受信中のファイル数がカウントされます。またシートには、アップデートはマシン上で実行されており、アプリを閉じても停止しない旨が小さな文字で1度だけ表示されます。

実行を開始したデバイスでは、シートの背後にあるアプリを使用できません。それ以外の操作はブロックされません。2台目のスマートフォンやタブレットにはタップして開くための1行が表示され、開いた後に再び閉じます。

すべてのマシンの処理が完了し、スマートフォンで新しいアプリが動作すると、シートは自動で閉じ、バージョンを示す短いメッセージが表示されます。クルー環境ではCrew updated to <version>と表示され、単一マシンの環境ではそのマシン名が表示されます。

Retry crew update など、メンバーのみを更新する実行も同様に画面を占有します。lead はその実行の対象外であり再起動もしないため、lead の行には already up to date と表示されます。末尾には Members updated to <version> と表示され、更新できなかったメンバーがある場合は、更新を実行したスマートフォンの画面にその理由とともにシートが開いたまま残ります。

3つの状態で処理が停滞する可能性がありますが、それぞれに対処方法があります。いずれの場合もアップデートはキャンセルされず、アプリのリロードも行われません。

注。 「ダウンロード中です。アプリをそのまま使い続けてください」はスマートフォンのアプリに関する通知であり、マシンに関するものではありません。マシン側の処理は完了しており、新しいアプリがまだ届いていないだけです。手元のアプリは動作を継続し、ダウンロードが完了した時点で自動的に切り替わります。

ターミナルからの操作

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 は使用方法を表示し、何も起動しません。すべての collie コマンドは、処理を実行する前に -h と --help に同様に応答します。

Herdr 管理下のインストール環境では、同じ操作が Herdr のアクションになります:

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

collie update --checkは何も変更しません。collie doctorを実行し、空き容量、bunのバージョン、作業ツリー、アップストリームのリリーストリスト、サービスユニットを読み取ります。lead上では、各自のSSH経由ですべてのcrewメンバーに同じ確認を行います。問題がなければ終了コード0で復帰し、--jsonはバージョン情報付きのレポートを出力します。このインスタンスのみをチェックしてcrewメンバーをスキップするには、--localを追加します。スマートフォンは自身のホスト上でローカルチェックを実行し、crew link経由で各ピアのステータス行を読み取るため、事前チェックにSSHは不要です。

collie update は現在のメジャーバージョンの最新リリースを取得し、ステージングします。その後、再起動によってアップデートを要求した bridge が終了するため、コマンドは切り替え処理を別のアップデータに渡して終了します。そのアップデータは current が新バージョンを指すように変更し、新しいバイナリで再起動したうえで、インストールしたばかりのバージョンを返す応答を最大30秒間 GET /api/health にポーリングします。応答がない場合、または旧バージョンから応答があった場合は、current を元に戻してもう一度再起動し、サービスログの末尾とともに rolled-back を記録します。それも起動しない場合は、手動で実行するコマンドとともに stuck を記録し、それ以上自動で再起動することはありません。ロールバックは1回のみ行われ、2回行われることはありません。

お使いのマシンで30秒では足りない場合は COLLIE_UPDATE_HEALTH_TIMEOUT_MS を設定してください。制限時間を超える遅いコールドスタートはアップデート失敗とみなされ、ロールバックされます。

collie update --status はアップデータが保持する記録を出力します。スマートフォンも同じ記録を読み取ります。メインポートの停止中は、deputy のスタンバイポートが /standby/update でその記録を提供します。

新しい beacon フックイベントが利用可能な場合、update は hooks install claude の再実行を促す通知を出力します。

更新、ロールバック、切り替えが成功するたびに、新しいビルドが collie skill sync を実行します。このマシン上の各エージェントハーネスに walky talky スキルをインストールし、古いコピーを更新して、エージェントが現在実行中のビルドを認識できるようにします。変更したファイルごとに1行出力し、更新処理を失敗させることはありません。実行できない場合は update が注記を1行表示し、手動で collie skill sync を実行します。collie skill uninstall を実行したハーネスはスキップされます。指示ファイルをそのまま維持するには COLLIE_SKILL_SYNC=off を設定してください。その場合、スキルが古いときに更新処理が注記を表示するのみとなります（スキルのインストール）。

各バージョンの配置場所

バイナリインストールとリンクされたクローンは、インストールルート（バイナリインストールの場合は ~/.local/share/collie または $COLLIE_DIR、チェックアウトの場合はクローン自体）の下で共通のレイアウトを使用します:

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

チェックアウト環境では、各 versions/vX.Y.Z はリリースタグの git worktree であり、単一の .git を共有するため、バージョンごとに追加で消費されるのはツリーのみで、オブジェクトストアが重複することはありません。ビルドは新しいディレクトリ内で実行され、最後に完了マーカーが書き込まれます。そのマーカーがないと切り替えが拒否されるため、ビルドが途中で終了しても稼働中のバージョンには影響しません。本番への適用は current シンボリックリンクのリネーム1回で行われます。保持ポリシーにより current と最新の過去2バージョンが保持されます。削除処理は実行が成功した場合にのみ行われるため、ロールバック先が必要になる可能性のある実行中にそれが削除されることはありません。

Herdr 管理 のチェックアウトは例外であり、その場で更新が進みます（ADR 0006、2026-09-03改定）。これは detached かつ shallow であり、Herdr が所有するディレクトリ内に存在するため、その隣に versions/ のレイアウトはなく、引き渡す対象も、切り戻す対象もありません。そこでは --rollback は拒否されます。復旧手順は指定されたタグの再インストール（herdr plugin install AltanS/collie --ref vX.Y.Z --yes）です。

1.8.0から1.7.0へのロールバックには、ステートディレクトリでの2箇所の手動編集が必要です。 1.8.0は初回起動時に3つのステートファイルの名前を変更するため、~/.local/state/collie/にはcrew-trust.json、crew-ops.json、crew-runtime.jsonが格納されるようになり、1.7.0ビルドは古い名前のみを読み取ります。1.7.0ビルドを起動する前に、3つとも名前を元に戻してください:

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

次に、pack-trust.json内の2つのキー名を編集します。1.8.0はどちらの表記のcrewブロックも読み取り、1.7.0が"pack"および"packId"として書き込んでいた部分を"crew"（内部は"crewId"）として書き戻します。1.7.0ビルドは自身の表記しか読み取れないため、1.8.0によってストアへの書き込み（参加、ローテーション、warrantの更新、削除のいずれかで発生）が行われた後は、そのブロック名を"pack"に、idフィールド名を"packId"に戻してください。3つのファイル内の他の部分は変更されていないため、crew-ops.jsonとcrew-runtime.jsonは編集不要です。ファイルを直接編集したくない場合は、アップデート前に取得したpack-trust.jsonのコピーを復元するか、1.8.0のまま運用してください。トラストストアを読み取れない1.7.0ビルドは単独モードで起動し、名簿を適用しません。

逆に 1.9.0 へ移行する場合も、手動で同じ2箇所の変更が必要です。 1.8.x は初回の起動時に3つのファイル名を自動で変更しましたが、1.9.0 はファイル名を変更しません。そのため、1.8.x を経由していない state ディレクトリには 1.7.0 の名前が残っており、1.9.0 のビルドは crew の名前しか読み込みません。起動時にその旨が表示され、必要な2箇所の変更が示された上で、ディレクトリを引き継がずに単独で動作します。起動する前に以下の変更を行ってください。

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

次に、crew-trust.json 内の2つのキー名を変更します。ブロック "pack" を "crew" に、その中のすべての "packId" を "crewId" に変更します。3つのファイルのそれ以外の部分は変更しません。古い名前のまま残されたファイルがあってもデータは失われませんが、crew が認識されなくなり、名前を変更するまでその collie は単独で起動します。

検証

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

最新のタグであることを確認します。

スマートフォン自体のバンドル は独立した仕組みです。PWA 自体が新しいビルドを確認して約1分以内にリロードしますが、アップデートの実行中はリロードを保留します。作業中の場合は「タップしてアップデート」というバナーを表示し、タップされるのを待ちます。

Windows環境

ソースチェックアウト環境では、Windowsにおいて、ソースチェックアウト環境が自動更新されることはありません。zipインストール環境では自動更新されます。のcollie updateおよびスマートフォンの「Update」ボタンにその旨が1行で表示され、変更は一切行われません。zipインストールへの移行は1回限りの手動手順です:

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

その後、collie update はターミナルとスマートフォンから動作します。この一連の手順はリリースファイルのローカルコピーを使って Windows 11 VM 上でテストされましたが、移行作業自体はテストされていません。また、v1.15.0 までのリリースでは実行中の collie.exe を差し替えることができませんでした。Windows 上の Collie を参照してください。

バージョンが変わらない場合

collie update は実行ごとに GitHub へ直接問い合わせを行います。チェックアウト時は git ls-remote を、バイナリインストール時は GitHub tags API を使用します。リリース一覧はキャッシュされません。数秒前に公開されたリリースは、GitHub 側の反映に少し時間がかかるため、表示されるまでに1分ほどかかることがあります。次に collie doctor を実行してください。それでも解決しない場合は collie が実行できない場合 を参照してください。

GitHubがリリース確認をレート制限する場合

バイナリインストールでのcollie updateは、GitHubのAPI経由でリリースを一覧取得します。スマートフォンの更新バナーやinstall.shも同様です。GitHubは匿名アクセスの呼び出し元に対して、ネットワークアドレスごとに1時間あたり60回のAPI呼び出しを許可しているため、1台のルーターの背後にあるすべてのマシンがその上限を共有します。上限を使い切ると、チェックは失敗して安全側に倒れ、何も変更しません:

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.

トークンを設定すると、レート制限が独自枠になります。Collieは環境変数からトークンを読み取り、入力を求めることはありません。

最初に設定されたものが優先されます。タグ一覧は公開されているため、トークンに必要な権限は一切の権限なしです。リポジトリアクセスをPublic repositories (read-only)に設定し権限を何も選択しないFine-grained個人用アクセストークンか、スコープを一切選択しないクラシックトークンを使用してください。書き込み権限を持つトークンは使用しないでください。

ターミナルで1回実行するだけなら、gh CLIの認証情報を借用します。この値がコマンドラインやシェルの履歴に残ることはありません。

GH_TOKEN=$(gh auth token) collie update

サービスで使用する場合は、インスタンスの.env（Collieがパーミッション600で保持）または[update]配下のconfig.tomlに記述して再起動してください。bridgeは起動時にトークンを読み込むため、スマートフォンのバナーが新規または変更後のトークンを反映するのはcollie restartの後になります。collie configではsetまたはunsetとして表示され、値が出力されることはありません。トークンはapi.github.comにのみ送信されます。リリースのダウンロードはgithub.comから行われますが、こちらにはそのような制限はなく、トークンが送信されることもありません。トークンに関するメッセージには値ではなく取得元の環境変数名が表示されます。GitHubに拒否されたトークンはHTTP 401とその変数名でチェックに失敗するため、トークンの誤りがレート制限と誤認されることはありません。bridgeはその旨をログに1度出力した後は最後に確認したリリースを維持します。そのため、トークンの期限切れ後にバナーの更新が停止している場合はそのログ行を確認してください。collie update --checkを実行すればいつでもそのログ行を確認できます。

collie update --checkはupstream配下の同じ3つのケースをレポートします。チェックアウト環境では代わりにgit ls-remoteでタグ一覧を取得するため、API制限のカウント対象外になります。crew構成では各マシンが自身のトークンを読み取ります。メンバーは各自の.envから自身のcollie updateを実行してアップデートします。

メジャーバージョンの更新

update がメジャーバージョンを自動で更新することはありません。

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

次のメジャーバージョンの最新安定版リリースへ更新します。プレリリース (ADR 0020) は対象外です。関連項目: 0.x から 1.0 へのアップグレード。

"You are not currently on a branch" で失敗する場合

0.23.1 より前の GitHub からのインストールでは、ブランチの追跡参照がありません (#63)。アップデート機能を復旧するには再インストールしてください:

# 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

Herdr のプラグイン設定ディレクトリ (慣例上は ~/.config/herdr/plugins/config/herdr.collie) にある設定は保持されます。

残りのcrewのアップデート

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

これは、スマートフォンから同期できないピア向けの端末操作手順です。スマートフォンの場合、1回のタップと1回の確認でクルー全体を更新できます。リードで設定 → システム → アップデートを開き、crewを<version>にアップデートを選択してください。ボタン上部の事前チェックは、リードだけでなく全メンバーを対象とします。いずれかのチェックが失敗（赤）するとボタンは無効化され、失敗したマシン名と理由が表示されます。

リードが自身のヘルスゲートに従って最初にアップデートされます。リードが安定して初めて、最初のピアの処理が始まります。1.7.0以降では、文言の観点からもこの順序が重要になります。1.7.0未満のリードはメンバーのステータスを出力の先頭行で読み取りますが、1.6.0がpack …を出力していた箇所で1.7.0のメンバーはcrew …を出力するため、未アップデートのリードでは読み取れません。1.7.0のリードは両方を読み取れます。その後、各ピアは自身でを揃えます。リードが実行しているリリースを読み取り、GitHubからその正確なタグを取得して、自身の事前チェック、ヘルスゲート、ロールバックを実行します。ピアは1台ずつ処理されます。Updatesページにはメンバーごとに1行が表示されます: waiting、checking、staging、restarting、verifying、updated、rolled back、またはunreachable。

メンバーの自動更新は最大で1時間に1回です。手動などにより1時間以内に更新されたメンバーは、その行の下に rate-limited, retries in about N min と表示されて待機し、その時間が経過すると実行が継続されます。リード自身の更新がロールバックされた場合、メンバーには変更が加えられず、行にもその旨が表示されます。新しい更新はクルーの実行が完了するまで待機します（最長2時間）。

1.7.0から1.8.0へ。 再びリードを最初に更新します。これには2つ目の理由があります。1.8.0では通信パス、2つの環境変数キー、3つの状態ファイル、およびjournalのプレフィックスがcrewに変更されます。1.8.0のリードは1リリース期間だけ古い/pack/v1/*パスに応答するため、まだ1.7.0のメンバーも既存の接続経由でロールオーバーに追従できます。1.9.0では両方の古い表記が削除されます。各名称とマシン上での役割については1.7.0または1.8.xから1.9.0へのアップデートを参照してください。リードを1.9.0へ移行する前に、すべてのメンバーを1.8.xに更新してください。1.9.0は古いパスに何も応答しなくなり、1.7.0のままのメンバーはリードのpreflightで赤色表示され、双方のバージョンと該当マシンで実行すべきコマンドが示されます。リリースで公開されるcollie-release.jsonアセットは、帯ウィジェット、Updatesカード、毎日のプッシュ通知に表示される通知文の元データとなりますが、アップデートの動作自体を変更することはありません。また、このアセットはリリースが公開されたことをチェック処理に伝える役割も持ちます。アセットがまだ404を返すタグは提示されず、次回のチェックで再確認されます。

peerが追従できるかどうかは、2つの要件によって決まります。

• —
  peerにはgithub.comへの送信HTTPS接続が必要です。 ここがコードの取得元です。このアクセス権がない場合、ピアは「遅延」として報告され、上記のコマンドを使用して端末から同期されます。
• —
  -dev+ビルドは追従しません。 開発ビルドを実行しているマシンは、leadが何を実行していてもそのビルドのままになります。

ロールバックしたpeerはUpdatesページにその旨を表示し、自動では再試行しません。2つの経路で再試行できます。

• —
  スマートフォンから。 leadが最新でpeerが遅れている場合、ボタンの表示はRetry crew updateになります。peerのみを対象とする新しい実行が開始され、その新しい実行によって各peerにもう1回の試行が許可されます。
• —
  lead上のターミナルから。 スマートフォンでは一切揃えられないpeerに対してこれを使用します。コマンドは共通です。

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

これをlead上で実行すると、手元のSSH経由で一連の処理が実行されます。まず全マシンの事前チェックを行い、各ピア自体のレポートとSSH経由で得られた応答を並べて出力するため、状態の不一致があいまいにならず明確に確認できます。確認を1回求めた後、lead自身が配布対象のビルドをまだ実行していない場合はまずleadをアップデートします。続いて各ピアを順次処理します。各ピアにleadのコミットがgit bundleとしてプッシュされ、再ビルド、再起動が行われ、同じ30秒の制限時間内に新しいビルドで応答するまでポーリングされます。スタンドアロンインストールやパッケージ経由でgitチェックアウトを持たないleadにはプッシュするコミットがないため、同じssh経由で自身が実行しているリリースを各ピアにインストールし、そのタグに固定します。この場合、gitチェックアウトから実行されているピアはスキップされ、その行にcollie update --to-tag v<version>と表示されます。

最初の失敗で処理全体が停止します。それ以降のすべてのメンバーには手が付けられず、「not attempted」として報告されます。サマリーには失敗を解消するための1つのコマンドが表示されます。自身のアップデートに失敗したリードは、ピアには一切手を付けません。crewはバージョンの不一致を許容するため（CREW_PROTOCOL.md §7.1）、ここで停止しても安全です。半分だけアップデートされたcrewはサポート対象の状態ですが、無理に進めることはサポートされません。

スマートフォンでは修正できない1つのケース。 ピアがバージョンを揃えた後で、gitやファイルのコピーによって手動でリードをロールバックすると、ピアがリードより新しいバージョンのまま残されます。Collieはこのロールバックを検知しないため、メンバーはダウングレードしません。スマートフォンのロールバックまたはcollie update --rollbackを使ったロールバック、およびStableへの復帰では、メンバーもダウングレードされます。リリースラインの「The crew follows the lead」を参照してください。メンバーが下位バージョンに移行するのは、これら2つの操作時のみです。リードがピアを意図的に後退させられると、任意のバージョンに変更できてしまうためです。手動ロールバックによるバージョンの不一致は無害であり、リード上でcollie crew update <member>を実行すれば解消します。

コードはSSH経由でピアに届き、crewリンク経由で届くことはありません（ADR 0016、2026-09-04補遺）。ピア自身を更新する場合、コードは匿名のHTTPS経由でGitHubから取得され、ピアが独自に判断します。leadは自身が実行しているバージョンと、どのピアが処理を継続できるかのみを伝えます。

アップデータ自体が停止した場合

アップデータが消失した場合、上記の手順はいずれも機能しません。このセクションでは、ターミナルのみが利用可能であることを前提とした復旧手順を説明します。

アップデータは <state dir>/update.json (デフォルトでは ~/.local/state/collie/update.json、または $COLLIE_STATE_DIR 配下) という 1 つのレコードを書き込みます。まずはこれを確認してください。状態、アップデート元のバージョン、アップデート先のバージョン、アップデータの pid、そして障害時にはサービスログの末尾と復旧コマンドが記録されています。

スマートフォンから開始したアップデートは、ターミナルには一切出力されません。systemd ユーザーマネージャーを使用する Linux では、collie-api-update-<stamp> という名前の一時ユニット配下で実行され、終了すると --collect がそのユニットを直ちに削除するため、実行ログは journal にのみ残ります。

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

macOS を含むそれ以外の環境では、アップデーター自体の出力は状態ディレクトリ内のファイルに書き込まれます。

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

スマートフォンからアップデートを開始するたびにそのファイルは空になり、直前の実行ログが update-runner.log.1 として保持されます。systemd を利用する環境では、このファイルには systemd-run が出力する1行のみが保持され、残りのログは上記の journal に記録されます。

crewのアップデート後も、特定のcrewメンバーが古いバージョンのまま残ることがあります。この場合、チェックアウト自体は新しいタグを示していても、/standby/healthやフッターには古いビルドが表示され続けます。systemctl --user list-units 'collie-api-update-*'でアップデータが実行中でないことを確認してください。実行中でなければ、対象のマシンでcollie updateを実行します。これにより、完了しなかったチェックアウトのビルドを再実行します。

切り替え前に中断した実行（たとえば、このマシンで起動しない新しいバージョンの場合など）では、ディスク上のデータは変更されません。アップデートを開始したスマートフォン側には対象マシンでアップデートが失敗した旨と理由が表示され、同じ理由が update.json の reason フィールドにも記録されます。

スマートフォン側では成功と報告されたにもかかわらず下流の処理が実行されなかった場合は、ここを確認してください。たとえば、実行レコードを書き込めなかったという警告は、lead自身が更新されたもののcrewを更新しない状態を示しています。残りの半分はbridge自体のジャーナルに出力されます。leadがレコードを取得すると、実行ごとに1行の[crew] update <run id>: levelling peers to <version>が出力されます。1.8.0より前では、このプレフィックスは[pack]でした。この行が存在しない場合、ターンは開始されていません。

1.5.4 未満のバージョンで bunx の処理が停止する問題

バージョン 1.5.4 より前では、スマートフォンから開始された更新は PATH が通っていない一時的な systemd ユーザーユニット内で実行されます。チェックアウトによるインストールで Bun が ~/.bun/bin にのみ存在する場合、チェックアウトの更新は進むものの、bunx: command not found でリビルドに失敗します。これを解決するには、Bun に PATH が通っているターミナルから collie update を 1 回実行するか、shim 自体が Bun を検出する Herdr アクションを実行してください。どちらの方法でも、更新されたチェックアウトがリビルドされます。1.5.4 以降では、アップデーターが自動的に Bun を検出します。

その隣には pid とタイムスタンプを保持する <state dir>/update.lock が配置されます。実行は常に 1 つずつです。レコードの状態が preflight、staging、restarting、verifying のいずれかのままで 10 分間変化がなく、その pid がプロセステーブルに存在しない場合、処理は終了しています。これは interrupted として扱われ、新しい実行がロックを取得できます。

手動で以前のバージョンに戻すには、current をそのバージョンに指定して再起動します。

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

または、以前のバージョンに同じ処理を実行させます。これは stuck レコードに含まれているコマンドです。

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

collie ではなくフルパスを使用してください。PATH 上の名前は current 経由で解決されますが、current 自体に問題がある可能性があるためです。

ヘルスチェックゲートで検出できない事象

このゲートが保証するのは、サービスが復帰し、インストールされたバージョンで /api/health に応答したということのみです。これは限定的な保証であり、「絶対に文鎮化しない」ことを意味するものではありません。ゲートが成功を報告している場合でも、以下の 4 点に問題が生じる可能性があります。

• —
  スマートフォン上の古い Web バンドル。 ホストは新しいバージョンに更新されているものの、スマートフォンは service worker から古い JavaScript を実行し続けている状態です。PWA は独自のスケジュールでバンドルを置き換えるため、ヘルスチェックゲート側からその状態を把握することはできません。
• —
  設定またはスキーマのマイグレーション。 Collie はこの更新頻度でマイグレーションを提供しておらず、アップデータもこれを実行しません。ゲートが確認するのはサービスが応答するかどうかであり、データの形式が正しいかどうかではありません。
• —
  操作時にのみ破損する mux ドライバー。 bridge が起動してヘルスチェックに応答する一方で、最初の実際の attach や send の実行時にアダプターが失敗する状態です。ヘルスチェックは生存確認プローブであり、適合性テストの実行ではありません。
• —
  古いバージョンのコードを実行しているアップデータ。 切り離されたアップデータは、置換対象となるバージョンから起動されます。アップデータは小さく安定した状態に保たれ、そのレコードはバージョン管理されているため、古いアップデータと新しい bridge は引き続き相互に認識できますが、これはリスク軽減策であり完全な保証ではありません。

スクリプトから最新リリースを特定する

Gitタグを取得し、SemVer順にソートします。プレリリースが除外されるGET /repos/AltanS/collie/releases/latestは使用しないでください。

# 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

リリースライン

各マシンは2つのリリースラインのいずれかに属します。デフォルトはStableです。

• —
  Stableは、たとえば1.23.0のような正式リリースのみを取得します。
• —
  EdgeはEdgeビルド（たとえば1.23.0-edge.2）も取得します。EdgeビルドはGitHubのプレリリースであり、正式リリースの数日前に同一ツリーから作成されます。一般公開前に有志へ先に届くため、リグレッションを早期に発見できます。

スマートフォンからラインを設定します: Settings → Updates → Release line。ラインの切り替えによって何かがインストールされることはありません。ラインが保存され、処理結果が表示されます。その後、通常のアップデート画面を通じて、Updatesカードに新しいラインの更新が提示されます。

• —
  Edgeでは、同一メジャーバージョン内で、現在実行中のビルドより新しい最新ビルド（Edgeビルドおよび正式リリースの両方）が提示されます。正式リリースは、両方のラインで自身のEdgeビルドを置き換えます。
• —
  このマシンがロールバックしたことのあるビルドは、どちらのラインでも二度と提示されません。
• —
  Edgeでは、新しいビルドに関するプッシュ通知は次回のダイジェストではなく、次回のチェック時に送信されます。ただし現地時間の09:00までは待機します。Stableは従来のダイジェスト時間枠を維持します。

Edgeでの配信間隔の目安 Edgeビルドの配信頻度は最大で1日1回程度であり、各ビルドには視認可能な変更が含まれます。bridgeは6時間ごとに新しいビルドを確認します。プッシュ通知はビルドごとに1回届き、ホストの現地時間09:00より前に送信されることはありません。1回のチェックで複数の新規ビルドが見つかった場合は、1つのプッシュ通知にまとめられます。アップデートストリップはビルドごとに1回確認を表示し、スキップすることも可能です。次回アップデート時には最新のものが適用されます。ストリップを閉じてもそのバージョンのみに適用されるため、次のビルドで再び確認が表示されます。

Stableへの復帰 Edgeビルドを実行しているマシンでStableに切り替えると、ページには次の3つのケースのいずれかが表示されます:

1. 01
   現在のビルド以上の正式リリースが公開されている場合。Updatesカードには通常のアップデートとして提示されます。
2. 02
   現在のEdgeビルドがすべての正式リリースより進んでいる場合。ページには2つの選択肢が提示されます: - 今すぐ戻す: 確認画面を経て、現在のビルドより古い最新の正式リリースをインストールします。マシンに保持されているStableビルドがあればそれを使用し、なければダウンロードします。現在のビルドの状態ファイルがそのリリースで読み込めない場合、ボタンの前に該当ファイル名が表示されます。 - Stableを待つ: 現在のビルドを維持します。Edgeビルドは提示されなくなり、次の正式リリースが公開された当日に提示されます。
3. 03
   すでに正式リリースを実行しています。必要な操作はありません。

保持されるビルド マシンがEdge上にある間は、実行中ビルド、直前のビルド、および最新のStableビルドが保持されます。マシンがStableに戻るまで最新のStableビルドは削除されないため、「今すぐ戻す」はダウンロードではなく切り替えのみで完了します。

ロールバック Edgeビルドからのロールバックを行うと、マシンはStableに移行し、該当ビルドにはロールバック済みフラグが付けられます。これはスマートフォンのロールバックでもcollie update --rollbackでも同様です。自身のヘルスチェックに失敗したEdgeビルドはアップデータによってロールバックされ、同じフラグが付けられるため、再提示されません。ラインはEdgeのまま維持され、次のEdgeビルドは通常どおり提示されます。

crewはリードに追従する リードのラインがcrewのラインになります。リードがEdgeにある場合、メンバーはリードに従ってEdgeビルドに移行し、リードのラインを自身のラインとして引き継ぎます。メンバーがダウングレードするのは、リードがロールバックしたかStableに戻った場合のみです。メンバーが下位バージョンをインストールするのは、この2つのケースに限られます。Crewページにはメンバーが追従しているラインが表示されます。

ターミナルから実行します。 ラインの設定はスマートフォンから行います。1回限りの実行用フラグが2つ用意されています:

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 は --downgrade なしで下位タグを取得することはありません。Edge タグの上位版を取得するのは、Edge 上のマシンのみです。Herdr 管理のインストール環境では、両方の系統と復帰パスが同じインプレースアップデートを経由します。アップデータがタグをチェックアウトし、Edge サフィックスをバージョンファイル自体に書き込みます。

プレリリース

Stable インストール環境はプレリリース版を受け取りません。例外は Edge 系統上の Edge ビルドです（リリースライン を参照）。プレリリースへのオプトインを行うと、最終リリースが提供されるまでそのメジャーのプレリリースを追跡します（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

スクリプトから最新リリースを特定するを使用して<tag>を解決します。

安定版リリースに戻すには:

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

1.24.0 へのアップグレード

バージョン 1.24.0 では、使用状況ドット、Stop ボタン、大画面レイアウトが追加されます。1.23.4 から移行する場合、アップグレード時に必要な作業はありません。以下の変更点があります。

• —
  Collie は statusLine を変更しません。 折り返しは collie hooks install claude --statusline でオプトインします。Edge ビルドの折り返しを解除したい場合は、collie hooks uninstall claude を実行してから collie hooks install claude を実行してください（Collie は Claude 自身の設定にフックを書き込みます）。
• —
  コンテキストドットに新しいフックは不要です。 1.23.4 でインストールされたフックにはすでに SessionStart が含まれており、同じコマンドを実行します。新しい Collie はそれらを使用してセッションファイルを読み取ります。collie hooks install claude を一度も実行したことがない場合は、一度実行してください。ウィンドウサイズはセッション開始時に決定されるため、既に実行中の Claude セッションは、再起動、再開、クリア、または圧縮されるまでドットを表示しません。
• —
  5時間ドットと7日間ドットは自身のログイン情報を読み取ります。 Claude の場合、Collie はこのマシン上のログインファイルを読み取り、api.anthropic.com に問い合わせます。Codex の場合、Codex のセッションファイルを読み取り、どこにも問い合わせません。どちらもデフォルトで有効です。無効にするには、.env で COLLIE_ACCOUNT_WINDOWS=0 を設定するか、[bridge] の下で account_windows = false を設定します。OpenCode Go と Grok は、指定するまで無効のままです（利用状況ウィンドウ）。
• —
  Stop ボタン、Clear ボタン、および Steer。 Stop は2回タップするとエージェント自身の停止キーを押します（ターンの停止）。Clear は入力ボックスを空にし、Restore は2分間テキストを元に戻します（入力ボックスをクリアする）。pi、Codex、OMP で実行中のターンをステアリングするには、Send を長押しします（ステアかキューか）。
• —
  pane-active を設定するテーマはバージョン 3 です。 1.24.0 より古い Collie は、バージョン名を記載したメッセージとともにそのファイルを拒否します。他のテーマはバージョンを維持します（バージョン）。
• —
  ワイド画面ではサイドバーが表示されます。 幅 600px、高さ 480px 以上の場合、ペイン画面には複数のペインが並んで表示されます。1台のデバイスでスマートフォンのレイアウトを維持するには、Settings で 大画面レイアウト を Off に設定してください。

1.19.0へのアップグレード

バージョン1.19.0では、起動処理が1つのページに統合され、スマートフォンごとに独自のKeysやランチャーを構成できるようになりました。アップグレード当日に必要な作業はありません。主な変更点は以下のとおりです。

• —
  Newシートはページになりました。 ダッシュボードの+ 新規をクリックすると/newが開き、マシン、AgentまたはCommandの選択、フォルダー、および新しいworktreeスイッチが表示されます。new-spaceシート、そのスペースラベル、既存のworktree一覧は廃止されました。既存のworktreeを開くには、マシン上でherdr worktree openを使用してください（スマートフォンからエージェントまたはシェルを起動）。
• —
  エージェントを名前指定で起動するにはクルーメンバーの更新が必要です。 ページには古いバージョンのCollieを実行しているメンバーが一覧表示され、その選択肢は無効化されます。最初にリードを更新すると、メンバーもそれに続きます（マシン上で何かを開始する）。
• —
  スマートフォンからランチャーを追加できます。 デフォルトの[phone] adds = trueでは、ペアリングされたスマートフォンからマシンに最大20行まで追加でき、launchers-added.jsonに保持されます。これを無効にするには、launchers.tomlでadds = falseを設定してください（スマートフォンから追加されたランチャー）。
• —
  Keysパッドはボードになりました。 既存のパッドの状態で開始され、ブラウザーごとに独自の配置が保持されます（独自のキーパッド）。keys.toml内のプリセットは変更されません。
• —
  フォルダー名のみの指定はホーム配下のフォルダーを指します。 Folderフィールドのprojectsは~/projectsを意味するようになり、存在しないフォルダーは通知とともに拒絶されます。

1.18.0 へのアップグレード

バージョン1.18.0では、書き込みだけでなく読み取りにもペアリングが必須になりました（ADR 0086）。アップグレード時の変更点は以下のとおりです。

• —
  ペアリング済みのスマートフォンはそのまま動作します。 保存済みのトークンはすでに新しいルールを満たしています。対応は不要です。
• —
  未ペアリングのブラウザにはペアリング画面が表示されます。 これまで読み取りが可能だった未ペアリングのデスクトップブラウザには、403 device not pairedが表示されるようになります。ホスト側でcollie pairを実行し、ブラウザの「Settings」でそのコードを入力してください（デバイスをペアリングする）。
• —
  インストール済みのアプリは、もう一度読み込まれるまで古い画面のままになることがあります。 インストール済みのアプリは、もう一度読み込まれるまで前のバージョンの画面を表示し続けることがあります。1.18 以降へのアップデート後に「Sign in」と表示された場合は、アプリを再読み込みするか、一度閉じてから再度開いてください。その後、上記の手順でペアリングします。
• —
  スクリプトは一度ペアリングする必要があります。 トークンなしでAPIを読み取っていたスクリプトは、403を受け取るようになります。collie pair --expires 30dを実行し、{"code": "...", "label": "script"}と同一オリジンのOriginヘッダーを付与した/api/pairへのPOSTでコードを要求してください。そのレスポンスでトークンが1回のみ返されます。以降のすべての呼び出しで、このトークンをAuthorization: Bearer <token>として送信してください。パスワードと同様に保管してください。
• —
  ホストのCLIは対応不要です。 collie doctor、collie history、およびクルーの更新スイープは、bridgeが状態ディレクトリに書き込むローカル認証情報を使用して、自身のbridgeを読み取ります。
• —
  1.18.0未満へのロールバックではトークンの有効期限が無視されます。 古いbridgeはexpiresAtフィールドを認識しないため、bridgeが更新されるまでは期限切れのデバイスが再び動作します。問題がある場合は、collie devices revoke <label>で失効させてください（デバイスに有効期限を設定する）。
• —
  古い監査ファイルには入力文字が含まれている可能性があります。 1.18.0より前に書き込まれたファイルには、スマートフォンで入力した文字が含まれている可能性があります。アップデート前のaudit.logファイルをローテーションまたは削除してください。
• —
  マスキングが干渉する場合があります。 「Files」内のファイル本文および「Changes」内のdiffは、ペインのテキストと同じシークレットマスクを通過するようになります。必要な情報が隠れてしまう場合は、.envでCOLLIE_REDACT=offを設定し、再起動してください（設定）。
• —
  1.18.0のリードはメンバーのテキストもマスクします。 1.17.xのままのメンバーはマスキングを行わないため、スマートフォンに届く前にリードがそのメンバーのテキストをマスクします。メンバーのテキストをマスクなしで表示するには、メンバーだけでなくリードでもCOLLIE_REDACT=offを設定してください。

0.x から 1.0 へのアップグレード

BUN_INSTALLが.env内でのみ定義されている場合は、代わりにシェルプロファイルまたはサービス環境でエクスポートしてください。その後、次を実行します:

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

# Linked clone
bin/collie update --major

bin/collie versionまたはherdr plugin action invoke version --plugin herdr.collieで確認します。

crewのセットアップの場合: 最初にリードを更新し、次にcollie crew update <member>…（残りのcrewのアップデート）を実行します。注意:

• —
  joinでは、プレーンなhttp://リードに対して--insecureが必要です。
• —
  1.0以前の招待トークンは、crew inviteで再生成する必要があります。
• —
  古いメンバーレコードにはreconnectが必要です。
• —
  アップグレードされていないピアは、crew status（CREW_PROTOCOL §7.1）でwarn:と表示されます。

1.0での変更点

HerdrのアクションIDとscripts/collie-ctl.shのルーティングは変更されていません（ADR 0006）。

CLIコマンドは<checkout>/bin/collie（コマンド）にコンパイルされます。bin/collie linkを使用してcollieをPATHに追加してください（collie を PATH に追加、ADR 0021）。

新機能:

• —
  pair / devices: デバイスごとの書き込み認証情報（デバイスをペアリングする）。
• —
  crew … / join / promote: マルチホストクラスタリング（crewコマンド）。
• —
  doctor: 設定の診断。
• —
  stt setup: 音声入力コンポーザーの設定（音声入力）。
• —
  hooks install claude / beacon emit: エージェントのアクティビティビーコン（エージェントビーコン）。
• —
  COLLIE_MUX: herdr（デフォルト）、tmux、またはzellij（tmuxとzellij）を選択します。

実環境で並行運用する場合

セカンダリインスタンスの設定については単一ホスト上での複数 Collie インスタンスの実行を参照してください。

ロールバック

最後の 0.x タグをチェックアウトして再ビルドします:

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

bash scripts/collie-ctl.sh build で再ビルドし、Herdr の restart アクションを実行します。状態ファイル (crew-trust.json、crew-runtime.json、paired-devices.json、pairing-pending.json) は残して問題ありません。ロールバックするとデバイスのペアリング強制が解除されるため、書き込み保護が必要な場合は COLLIE_DEVICE_HEADER を設定してください。

動作確認

version の出力が 1.0.0 以上であることを確認します。アップグレード後の環境ではデバイスが自動ペアリングされません。pair を実行してスマートフォンに書き込み認証情報を発行し、その端末を紛失した場合は devices revoke を実行してください (デバイスをペアリングする)。

停止またはアンインストール

サービスを一時停止します:

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

サービス定義とポートマッピングを削除します (.env とチェックアウトしたリポジトリは保持されます):

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

プログラムと作成したファイルの両方を削除するには、インストール → アンインストール の3つの手順に従ってください。パッケージを含むインストール種別ごとに記載されています。

collie が実行できない場合

バイナリインストール (~/.local/share/collie または $COLLIE_DIR) の場合は、古いバイナリを直接実行します:

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

特定のバージョンを直接インストールするには:

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

チェックアウトまたは Herdr によるインストールの場合は、git checkout <tag> または herdr plugin install AltanS/collie --ref vX.Y.Z --yes を実行します。

フォーク版を使用している場合

collie update は origin と COLLIE_UPDATE_REPO (デフォルトは AltanS/collie) を照合し、一致しない場合は処理を中断します。フォーク版で独自のタグをリリースしている場合は COLLIE_UPDATE_REPO=you/collie を設定してください。

上流の更新を手動でフォークへマージするには:

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

フォーク版では update --major を使用せず、v1.* タグを手動でマージしてください。collie doctor を実行するとアクティブな COLLIE_UPDATE_REPO を確認できます。

再起動後も維持する

Linux では、ログインしていない状態でもユーザーサービスを実行し続けるよう lingering を有効にします:

loginctl enable-linger $USER

systemctl --user status collie でステータスを確認します。

macOS では、start が ~/Library/LaunchAgents/herdr.collie.plist を自動的に管理します。ユーザーログイン時に起動します。ステータスは launchctl print gui/$(id -u)/herdr.collie で確認してください。