ThreadCells のアップグレード
アップグレードとは、検証済みのロールバックを伴う、制御された候補の昇格です。現在実行中のファイルをその場で上書きすることではありません。
アップグレード前
- リリースノートと制限事項を読む。
- 現在のヘルスとアクティブ／ロールバックのビルド ID を確認する。
- 重要なプロバイダー作業／重い作業が安全な境界に到達するのを待つ。
- オープンなワークフローと配信済みの結果を確認する。
- 一貫したバックアップを作成し、データベース整合性チェックを実行する。
- 現在の候補をロールバック用に保持する。
ビルドと検証
意図したソースコミットから実行します。
python3 scripts/build_local_candidate.py --output "$PWD/threadcells-candidate"
candidate="$PWD/threadcells-candidate/threadcells-0.3.4a0-local"
python3 scripts/verify_local_candidate.py --candidate "$candidate"候補 ID がレビュー済みコミットと異なる場合、または docs／Web／ビルドのチェックが失敗した場合は、昇格してはいけません。
ステージと昇格
正規のローカルデプロイメントツールを使用して、アクティブポインターを変えずに候補をステージします。ステージ済みファイルを検証してからアトミックに昇格し、そのリリースを消費する ThreadCells サービスだけを再起動します。
期待結果: Settings → About、Docs フッター、リリースメタデータが同じ候補リビジョンを識別します。
アップグレード後のチェック
curl -fsS http://127.0.0.1:9889/health- Home を開き、容量／ディスク状態を確認する。
- 既存の Agents／Flows を開き、永続的な関係が残っていることを確認する。
- Settings と Spawn でプロバイダーの準備状態を比較する。
- オペレーター認可が設定済みで、保護された変更がロック解除までロックされたままであることを確認する。
- Statistics を開き、更新／再起動で使用量が重複しないことを確認する。
- Docs ルートを開き、パッケージ化されたビルド ID を検証する。
- 端末ストリーミング／再接続を確認する。
- PWA マニフェストとサービスワーカーが動的リクエストをキャッシュしないことを確認する。
- Settings → Telegram を開き、安全な設定状態を確認する。ネイティブ認証情報がすでに設定済みの場合は、明示的な接続とテストメッセージのチェックを実行する。
- 昇格をまたぐオープンエージェントでは、制御接続の再初期化が一度だけ完了し、同じ永続ワークフローがオーナー起床や子／効果の重複なしに継続することを確認する。
履歴の修復
アップグレードには、範囲を限定したデータ修復が含まれる場合があります。ソースの証拠が決定的な場合にのみ実行し、べき等に保ち、前後の件数を記録します。欠落しているプロバイダーテレメトリーは欠落したままとし、過去の使用量を作り出してはいけません。
ロールバック
受け入れが重大に失敗した場合は、次の手順を実行します。
- 失敗した候補と関連する安全なログを保持する。
- 正規のアクティブポインターを検証済みロールバック候補に切り替える。
- 必要なサービスだけを再起動する。
- ロールバックビルドと主要画面を検証する。
- スキーマ／データ互換性が必要とする場合にのみ、アップグレード前のデータベースを復元する。
ロールバックを模倣するために、破壊的な Git reset を使ったり、新しいランタイム証拠を削除したりしてはいけません。
明示的に確認された Full Cleanup は、通常のローカルリリース保持の例外です。デプロイ時に選択されたロールバックを含む、証明済みの非アクティブなリリースをすべて削除し、アクティブな不変リリースだけを残します。アップグレード受け入れ中や、いずれかのエージェントが実行中のときに実行してはいけません。Full Cleanup 成功後にロールバック可用性を戻すには、別の検証済み不変リリースをステージングしてください。未検証ディレクトリーから再構築してはいけません。
ローカルデプロイメントとバックアップと復元を参照してください。