管理とアップデート

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を実行した時点で解消されます。

pack内では、パッケージ管理されているメンバーが電話から更新を受け取ることはありません。packはそのメンバーを「waits for the package manager」として扱い、対象から除外して処理を完了するため、上記の2つのコマンドを実行して最新状態に揃える必要があります。

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

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

アップデートの経路は2つあり、どちらも各ホストで同じ手順を実行します。稼働中のリリースの隣に新しいリリースを配置し、シンボリックリンクを切り替え、再起動して、サービスが応答することを確認します。pack lead上では、どちらの経路でもpack全体が対象になります。スマートフォンを使うのが簡単な経路です。スマートフォンで整合性を保てないマシンに対しては、ターミナルがフォールバックになります。

スマートフォンから

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

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

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

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

実行中、カードには現在の状態が表示されます:

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

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

通知の頻度 アップデート通知はダイジェスト形式で、最大でも1日1回、ホストの現地時間で09:00より前には送信されません。パッチリリースのみの差分は週次の配信枠を待つため、パッチ群は4回ではなく1回のプッシュ通知として届きます。マイナーまたはメジャーのアップデートは日次の頻度を維持し、待機中のパッチも併せて配信されます。保留されたリリースはまとめられ、破棄されることはありません。カードには配信枠にかかわらず常に現在の状態が表示されます。Settings → notifications（Web Push）にある updates 通知設定が、唯一の無効化スイッチです。

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

各画面の上部に表示される帯で実行状況を示します。利用可能なリリースが表示された後、Starting update…、Updating to <version>、Updated to <version>. Tap to reload.、そしてピアの追従に合わせて最後にUpdating <n> peers: <names>が表示されます。ロールバックしたピアもそこに名前が表示され、ページに戻る手段としてUpdatesを参照してください。が表示されます。この帯は以下の順序で表示されます:

ターミナルからの操作

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

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

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

collie update --checkは何も変更しません。collie doctorを実行し、空き容量、bunのバージョン、ワーキングツリー、アップストリームのリリース一覧、サービスユニットを読み取ります。lead上では、ユーザー自身のSSH経由で各packメンバーにも同じ問い合わせを行います。異常（red）がなければ終了コード0で終了し、--jsonはバージョン情報付きのレポートを出力します。--localを追加すると、このインスタンスのみをチェックし、packメンバーをスキップします。スマートフォンは自身のホスト上でそのローカルチェックを実行し、packリンク経由で各peerの行を読み取るため、そのプリフライトに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 の再実行を促す通知を出力します。

各バージョンの配置場所

バイナリインストールとリンクされたクローンは、インストールルート（バイナリインストールの場合は ~/.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）です。

検証

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

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

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

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

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

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

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) にある設定は保持されます。

pack の他のノードのアップデート

スマートフォンから1回のタップと1回の確認でpackをアップデートします。lead上でSettings → Updatesを開き、packを<version>にアップデートを選択します。ボタン上部のプリフライトはleadだけでなく、すべてのメンバーを対象とします。いずれかのチェックで異常（red）が出た場合、ボタンは無効化され、失敗したマシン名とその理由が表示されます。

まずleadが自身のヘルスゲートに従ってアップデートされます。leadが安定した後にのみ、最初のpeerが開始されます。その後、各peerは自身で自身を揃えます。leadが実行しているリリースを読み取り、GitHubからその正確なタグを取得して、独自のプリフライト、ヘルスゲート、ロールバックを実行します。peerは1台ずつ処理されます。Updatesページにはメンバーごとに1行表示されます: waiting、checking、staging、restarting、verifying、updated、rolled back、またはunreachable。

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

• —
  peerにはgithub.comへの送信HTTPS接続が必要です。 そこからコードを取得します。そのアクセス権がない場合、peerは遅れていると報告され、代わりに後述のターミナルから揃えられます。
• —
  -dev+ビルドは追従しません。 開発ビルドを実行しているマシンは、leadが何を実行していてもそのビルドのままになります。

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

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

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

ユーザー自身のSSH経由で一連の処理として実行されます。まずすべてのマシンでプリフライトを実行し、SSH経由で取得した回答の隣に各peer独自のレポートを出力するため、不一致が平均化されず明確になります。1回の同意を求めます。次に、leadが配布対象のビルドをまだ実行していない場合は、lead自体をアップデートします。続いて各peerを順番に処理します。leadのコミットがgit bundleとしてpeerにプッシュされ、再ビルド、再起動され、同じ30秒の猶予時間内に新しいビルドに応答するまでポーリングされます。

最初の失敗で実行は停止します。それ以降のすべてのメンバーは変更されずに「未試行」と報告され、サマリーには失敗を解消する単一のコマンドが表示されます。自身のアップデートを適用できないleadは、いかなるpeerにも手を付けません。packはバージョンの不一致を許容するため（PACK_PROTOCOL.md §7.1）、そこで停止しても安全です。したがって、一部のみアップデートされたpackはサポート対象の状態ですが、そのまま処理を強行することはサポートされません。

スマートフォンでは修正できない1つのケース。 peerがバージョンを揃えた後にleadを手動でロールバックすると、peerはleadよりも新しいバージョンのままになります。peerをダウングレードする処理はありません。peerを古いバージョンに戻せるleadは、peerを任意のバージョンに変更できてしまうためです。この不一致に害はなく、解決策はlead上でcollie pack update <member>を実行することです。

コードはSSH経由でpeerに到達し、packリンク経由で到達することはありません（ADR 0016、2026-09-04補足）。peerが自身を揃える際、そのコードは匿名のHTTPS経由でGitHubから取得され、peer自身が判断します。leadは自身が実行しているバージョンと、どのpeerが続行してよいかのみを提示します。

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

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

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

スマートフォンから開始された更新のログは、ターミナルには一切出力されません。collie-api-update-<stamp> という名前の一時的な systemd ユニットとして実行され、終了すると --collect によって即座にユニットが削除されるため、その出力内容は journal にのみ残ります:

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

スマートフォン側で成功と表示されたにもかかわらず後続の処理が実行されなかった場合（たとえば、リード自体は更新されたものの pack の同期を行わない原因となる実行レコードの書き込み失敗警告など）は、ここを確認してください。bridge 本体の journal には、もう一方のログが含まれます。リードがレコードを取得した際に、実行ごとに 1 行の [pack] update <run id>: levelling peers to <version> が出力されます。この行がない場合、ターンは開始されていません。

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

プレリリース

安定版の環境にはプレリリースは配信されません。プレリリース版を選択すると、正式リリース（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

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で確認します。

packのセットアップについて: 最初にリードを更新し、次にcollie pack update <member>…（pack の他のノードのアップデート）を実行します。注意:

• —
  joinでは、プレーンなhttp://リードに対して--insecureが必要です。
• —
  1.0以前の招待トークンは、pack inviteで再生成する必要があります。
• —
  古いメンバーレコードにはreconnectが必要です。
• —
  アップグレードされていないピアは、pack status（PACK_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: デバイスごとの書き込み認証情報（デバイスをペアリングする）。
• —
  pack … / join / promote: マルチホストクラスタリング（packコマンド）。
• —
  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 アクションを実行します。状態ファイル (pack-trust.json、pack-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

残りのファイルを削除するには、Herdr 管理の場合は herdr plugin uninstall herdr.collie を実行し、スタンドアロンの場合は bin/collie unlink を実行して ~/.local/share/collie / $COLLIE_DIR を削除します。

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 で確認してください。