運用

ThreadCells の日常運用では主に、実行中ビルドの識別情報、ワークフロー所有権、利用可能な容量、復旧可能な状態という四種類の事実を保つことが重要です。

日次チェック

Home、Agents、Settings → General、Settings → Housekeeping を使って、次を確認します。

• サーバーは健全で、想定したビルドが実行中か。
• ディスクと容量は GREEN、YELLOW、RED のどれか。
• 実際にアクティブなスーパーバイザーとワーカーはどれか。
• 配信済みだが未取り込みの結果はないか。
• オーナー判断を待っているワークフローはあるか。
• Telegram が有効なら、Settings → Telegram は想定どおり安全な接続／テスト状態を示すか。

コマンドラインの容量表示は次のとおりです。

threadcells-resource-status

サービス監視にはローカルのヘルスエンドポイントを使います。

curl -fsS http://127.0.0.1:9889/health

起動と停止

threadcells-server をループバックで実行するか、正規のインストール済みサービスを使います。ブラウザーの切断で tmux を基盤とするエージェントが停止することはありません。サポート対象のサーバー再起動では、正当にアクティブな端末ランタイムを保持した後、永続的なオープンワークフローと Inbox 配信状態を復元します。終了済みランタイムは、正確な端末／プロセス ID によって退役します。履歴のセッションおよび結果レコードは、tmux ペインが生き続けることに依存しません。

計画的な再起動の前に、次を行います。

1. アクティブなプロバイダー作業と重い作業を確認する。
2. 可能なら変更操作の中断を避ける。
3. 現在のアクティブビルドとロールバックビルドの識別情報を記録する。
4. アップグレードではデータベースをバックアップして整合性を確認する。
5. 必要な ThreadCells サービスだけを再起動する。
6. 再接続し、何かを再試行する前にワークフロー／結果を検証する。

プロバイダーのライフサイクルには Graceful Exit を使います。tmux を強制終了したりデータベース行を手動削除したりすると、端末状態と永続的なワークフローの事実が乖離する可能性があります。

セッションとワークフローの衛生管理

終了した子をすぐに破棄してはいけません。その永続的な結果が配信され、読まれ、取り込まれ、確認応答されたことを確認します。その後、履歴を保持したままランタイムリソースを退役します。

Add Agent は安定した選択済みセッションの存続期間を対象にします。履歴セッションの削除と終了済み端末の削除は正確な永続 ID を対象とし、アクティブなランタイム、オープン／復旧中ワークフロー、書き込みリース、保留中の結果、またはその他の実際のライフサイクル依存関係が残っている間は拒否されます。保持ログ、保護されたクリーンアップ worktree、終了後のクリーンアップ要求だけで論理削除が妨げられることはありません。ThreadCells はリソース権限を保持し、正確なセッションをトゥームストーン化し、再試行をべき等にします。削除がブロックされた場合、一般的なリソース不在／サーバーエラーではなく、具体的なライフサイクル競合を返します。

一つのセッション内では、Home と Agents が List および Grid ビューでバックエンドの永続的なエージェント作成順序を維持します。ステータス、プロバイダー、プロファイル、アクティビティ、ポーリング、再接続、再起動でエージェントが並べ替えられることはなく、新しいエージェントは以前のエージェントの後ろに追加されます。

プロバイダーの最終応答はオープンなミッションを閉じません。オーナーが承認した作業がすべて完了してから、トップレベルのワークフローを明示的に完了します。オーナーゲートは本当の判断境界にのみ使います。

容量の変更

Settings → Orchestration Capacity では、サーバーを再起動せずに変更を適用できます。縮小時はドレインされ、アクティブなセッションを停止しません。一度に一つの制約だけを変更し、意図したキューが改善するかを監視してください。

容量の変更にはロック解除済みのオペレーターセッションが必要で、監査されます。容量とリソースモデルを参照してください。

ログと証拠

失敗した実行を診断できる十分なログと結果履歴を保ちますが、ログだけを唯一の永続的事実として扱ってはいけません。データベース、ワークフロー結果、Git コミット／差分、候補マニフェスト、テスト証拠は、それぞれ異なる問いに答えます。

認証情報を含むプロンプトや値をログに残さないでください。ThreadCells の公開／API エラーは安全に表示できる必要があります。

Housekeeping

Housekeeping は常に計画優先です。ドライランの候補リストと計画 ID を確認してから、完全に一致する計画を明示的に実行します。実行器は、変更前に現在の保護状態を再構築し、各候補を再検証します。永続履歴を消去せずに、証明済みの終了端末ランタイムと確認応答済みでクリーンアップ保留中の worktree を退役できる場合があります。

バックアップはインベントリー専用で、自動削除されることはありません。未知またはアクティブなリソースは保護されたままです。Full Cleanup は個別に確認するオペレーター操作で、全エージェントがアイドルの間だけ実行され、Ready エージェントの継続権限を保護し、証明済みの非アクティブなローカルリリースをすべて意図的に削除するため、ローカルロールバックは利用できなくなります。Housekeepingを参照してください。

本番変更の規律

アップグレードでは、次の手順を実行します。

1. 正確なコミットから不変の候補をビルドして検証する。
2. 現在のインストールをロールバック用に保持する。
3. データベースをバックアップして整合性を確認する。
4. 正規のデプロイメント機構を通じてステージする。
5. ステージ済みの完全に一致する候補を昇格する。
6. 必要なサービスだけを再起動する。
7. ヘルス、UI、プロバイダー事前検査、オペレーター認可、ワークフロー、端末、設定済みのグローバル Telegram 通知をスモークテストする。

ローカルデプロイメントのついでに公開、プッシュ、タグ付け、公開露出の変更をしてはいけません。アップグレードとデプロイメントを参照してください。

問題が起きたように見えるとき

クリーンアップや再試行の前に証拠を保全します。ビルド ID、セッション／端末／ワークフロー ID、安全なエラーメッセージ、関連ログの時間帯、Git ステータス、現在の容量を記録します。その後、症状別のトラブルシューティングガイドを使ってください。