Instabox 開発パターン実験

タスクに合う開発構成を仮案として選び、実際の開発・検証と接続や復旧の実験を通じて評価する。3パターンは検証候補であり、確定した推奨構成ではない。「最適」は今回のタスク・環境・観測範囲に限った仮説として扱う。

入口と資料

接続、作業機の準備、認証、永続領域、結果回収、後片付けは Instabox 基本活用 を読む。共通手順をここへ複製しない。

利用の都度 公式 Docs の目次と必要な章を読み、利用中 CLI / SDK / 実行器の版・実環境と照合する。料金、上限、休止条件、APIの詳細をローカルの一覧へ固定しない。選んだパターンの参照ファイルだけを追加で読む。

パターンを仮選定する

まずタスクと現在の環境を読み取る。完了条件、対話の頻度、手元のファイル・GUIへの依存、PCを閉じたい時間、VM停止後まで自動で続ける必要性、利用可能な作業機・実行器・管理基盤を確認する。タスクが提示されていなければ対象を尋ね、任意の開発課題を作らない。

仮案	合う条件	確かめること	詳細
① ローカルが司令役	対話や手元の環境への依存が大きい。重い処理を遠隔へ分けたい	遠隔実行の効果、切断で止まる範囲、結果回収	local-orchestrator.md
② Instaboxで開発を継続	PC不在中も、範囲の決まった開発を進めたい	切断後の後続工程、進捗保存、再接続時の把握	cloud-development.md
③ 外部で仕事・復旧を管理	VM停止を越える起動・照合・次ジョブ管理が必要	外部起動、永続状態、重複防止、停止意思の尊重	external-management.md

• ユーザー指定のパターンを優先し、成立条件が欠けるなら理由と検証できる範囲を示す。無断で別案に切り替えない。
• 指定がなければ要求を満たす最小構成を選ぶ。②を試すだけなら③の独自管理基盤を先に作らない。Instaboxを使う効果が薄ければ、ローカル・一時Docker・既存CIの方が適するという結論も許容する。
• 推奨する仮案、理由、他案を選ばなかった理由、未確認事項、最小の試行を短く伝えて進める。説明だけ・計画だけの依頼では実行しない。スキル自体の作成・編集の依頼を、クラウド実験の許可に広げない。

共通の実験手順

1. 試行を定義する。 記録のひな形を使い、実験ID、検証したい仮説、基点commit・入力、対象範囲、受入条件を残す。ローカル・Instabox・外部管理部分のどこが司令・実行・保存を担当するか明記する。
2. 範囲と上限を決める。 使用する作業機と専用の作業先、実行器、モデル、結果保存先、観測時間、試行回数・利用量の上限、停止条件、保持・後片付けを定める。既存の指定を優先し、不足時は完了条件のある小さな1件・1試行から始める。費用や停止操作など実験の可否を左右する未決事項だけを確認し、許可済みの作業へ形式的な承認待ちを追加しない。
3. 成立条件を調べる。 アカウントの実効休止設定・権限、認証、実行器の切断・再開仕様を確認する。オプションが存在することを、設定が適用される証拠にしない。未確認の能力が中核なら、先に能力確認だけの小さな試行を置く。必要な能力がない場合は、実施不能または条件付きとして残す。
4. 実際に開発・検証する。 タスクの開発ルールに従い、選んだ実行場所で調査・実装・テスト・必要な配布物検証を行う。構成図やプロセス起動だけで完了にしない。同じ作業先を複数の司令役から同時に変更せず、引渡し時は基点と差分を対応付ける。
5. 対象の条件を実験する。 選んだ参照の手順で切断・不在・復旧などを試す。ローカルの観測が止まる間も、実行側に時刻付きの開始・終了・待機記録を残す。許可されていない作業機の停止や他の作業への干渉は行わない。観測できなかった条件は未検証にする。
6. 照合して結果を回収する。 タスクの受入条件と、構成の仮説の両方を判定する。差分、テスト結果、終了コード、ログ・画面、介入時間、停止理由を対応付ける。応答不明なら状態・既存プロセス・成果物を先に照合し、同じ作業を無条件で再送しない。
7. 評価と後片付けを残す。 結論を下記の4分類で示し、今回の条件、根拠、限界、次に変える要因を残す。成果を回収した後、決めた保持方針で後片付けする。比較を続けるなら条件をそろえ、変える要因を絞る。別の試行や一晩の継続性へ結果を一般化しない。

記録と判定

既存の非公開保存先があれば使う。なければユーザーの Codex 領域の experiments/instabox/<実験ID>/ を使う（CODEX_HOME がなければ ~/.codex）。公開リポジトリに依頼文・実行ログ・非公開の差分を自動保存しない。認証情報の値は記録しない。共有用の結果は必要な範囲を確認・除去して作る。

タスクの完了・試行の終了・構成の適否は別々に記録する。承認待ちなどでタスクが未完了でも、停止境界を正しく観測した試行として報告できる。

判定	意味
今回の条件では有効	事前に決めた受入条件と構成の仮説を、対応する証拠で確認できた
条件付き	確認できた部分は有効だが、権限・稼働条件・人間の介入などの成立条件が残る
不適合	必要な条件を満たさないことを観測した。未実装・未測定だけを理由にしない
判定保留	証拠不足、実施不能、結果不明などで適否を判断できない

維持する境界

• 作業機の復帰、Hostの起動、Session / ジョブの再開を区別する。DSH Goalなど実行器の人間による再開条件を、別CLIや予約指示で回避しない。
• 認証待ち、操作承認待ち、利用上限待ち、レビュー待ち、実行結果不明を分ける。既存のモデル・認証・承認・sandbox設定を実験のために弱めない。
• 認証ストアを転送・複製しない。原本スナップショットへ認証情報や実行中・予約済みの仕事を混ぜない。
• 通常の開発は依頼された作業先で行い、Git操作自体の動作試験は一時リポジトリとローカルbare remoteを使う。Linuxの結果で他OSのDesktop互換性を確認済みにしない。

完了報告

選んだ仮案と理由、タスク成果、観測できた切断・復旧条件、4分類の判定、停止理由と人間の介入、未検証、記録先、残した環境を短く報告する。机上確認・実機試行・継続運用で得た根拠を区別する。スキルや構成を確定版へ昇格させる判断は、個別試行の成功から自動で行わない。