Crabbox（クラウドテストボックススキル）

Crabbox（クラウドテストボックススキル） は何をしますか？

• 意図的なリモート証明: 証明ポリシーに従う。適格で利用可能なホスト上での、制限されたローカル証明を優先する。高コストまたはプラットフォーム固有の作業にはリモート容量を使用できる。キューイングが発生した場合は、自身の割り当てを停止し、PR CIまたは安全なローカルスコープを使用し、未対応の要件を報告する。公開前に必要なビルドが利用できない場合は、テスティングスキルのドラフト/CI証明ポリシーを使用する。
• キューを待ったり、プロバイダのフォールバックを連鎖させたりしてはならない。

バックエンド:

• blacksmith-testbox: 信頼できるメンテナソース。準備済みCI。tbx_...。
• aws: 直接仲介されるCrabbox。新しいPR。カスタム同期/env/キャプチャ。cbx_...。
• local-container: Dockerフォールバック。リモート証明ではない。
• ssh: 既存のオペレーターホスト。macOS/Windows/WSL2。

常にプロバイダ、ID、実行URL、コマンド、結果を報告すること。Testboxを「AWS Crabbox」と呼んではならない。

リポジトリ契約

• 信頼できるコンシューマの指示に基づいて、サンプルコマンド、ブートストラップ、コンテナイメージ、PRを解決すること。コマンドを創作したり、別のコンシューマのセットアップをコピーしたりしてはならない。
• コンシューマ固有のセットアップは、ポータブルスキルの外に保持すること。プレースホルダー定義を参照。

認可と分離

• タスクに必要な作成、再利用、クリーンアップ、一時的な状態、クリーンチェックアウト: 事前承認済み。既存のブランチ、チェックアウト、無関係な編集を保持すること。
• ソースの信頼性、認証情報、本番環境アクセス、予算、公開は権限の境界として残る。分離された状態。タスクごとの承認なしに、オペレーターGatewayに触れてはならない。

ルート優先

• 解決済みのプロバイダを保持する: Testbox（信頼できるソース）、AWS（そのセマンティクスが必要な場合）、secretless CI/AWS（信頼できないコードの場合）。信頼できないラッパー/設定をローカルで実行したり、信頼できないリースをハイドレートしたりしてはならない。
• コマンドの準備ができたら取得し、所有するIDを再利用し、その後停止する。
• 最小限の証明済みプロファイル。より大きなものは、記録されたメモリの証拠または測定された総コストメリットが必要であり、一般的な障害/遅延/タイムアウトでは不十分。ワーカー数を増やして補ってはならない。
• Testboxのサイジング: --blacksmith-workflowを使用し、直接--class/--typeを使用しないこと。プロファイルの変更には新しいリースが必要。
• Blacksmithランナーラベルはティアを要求するものであり、CPUやRAMを保証するものではない。Blacksmithはサービスの可用性に応じてより小さなマシンを割り当てることができる。リソースに敏感なテストやベンチマークでは、割り当てられたマシン上の利用可能なCPU、アフィニティ/クォータ、使用可能なRAMを測定すること。それらの測定値に基づいてワーカーとワークロードのサイズを決めること。要求したティアと観測されたリソースは別々に記録すること。ラベルだけでハードウェアやパフォーマンスを評価してはならない。
• サイズ、期間、ハイドレーション障害、容量は、決してプロバイダのオーバーライドを許可しない。明示的なユーザー選択または必要なバックエンドセマンティクスがそれを行う。

プレフライト

信頼できるリポジトリルート: .crabbox.yamlを読み込み、インストール済みバイナリを解決し、プロバイダ/コマンドを検査する:

export CRABBOX="$(command -v crabbox)"
test -n "$CRABBOX"
"$CRABBOX" --version
"$CRABBOX" config show --json | jq '{provider, profile, target}'
"$CRABBOX" run --help

• コンシューマの信頼できるラッパー/インストール手順を使用すること。
• ネイティブのLinux/WSLコマンドライフサイクルおよびキャンセル証明には、完全に一致するCrabboxディストリビューション、またはCRABBOX_RUNTIME_ARTIFACTSで選択された検証済みランタイムマニフェストが必要。コンパニオンを凍結ソースに一致させ、マニフェストが正確な選択されたコントローラーにバインドされていることを確認すること。ランタイムパックのない開発CLIはレガシーSSH監視を使用する。--versionだけではネイティブ監視を確立できない。割り当て前に選択されたパックを検証すること。CLIのみの証明をネイティブライフサイクル証明としてカウントしてはならない。上流のランタイムアーティファクト手順に従うこと。
• 修復: 上流を検証し、タスク所有のクリーンチェックアウトを使用し、インストール済みバイナリと無関係なソースを保持すること。兄弟チェックアウトを名前だけで信頼してはならない。

リースライフタイム

• TTLは作成時からカウントされ、ハイドレーションを含む。アイドルタイムアウトは非アクティブをカウントする。早い期限が優先される。デフォルト: 各30分、最大4時間。所有者/組織のオーバーライドにより最大24時間まで許可される場合がある。効果的なポリシーとサニタイズされたクランプ通知を使用し、要求された期間は使用しない。ポリシーの厳格化はアクティブなリースにも適用される。
• --keepと stop: neverは有効期限を防がない。保持された直接リースには、明示的な境界TTLとアイドルを要求すること。単なるハートビート、セットアップ、同期、SSH、デスクトップの使用は合計TTLを延長しない。runは、コマンドの実行中にのみ、ポリシー、予算、プロバイダ機能の範囲内で、境界のある自動延長を要求する。
• 長いソース依存作業の前に、残りの総ライフタイムを検査すること。許可されている場合、1回の境界のあるextend <id> --ttl <desired-total> --jsonを要求すること。延長はアイドルをリセットしない。拒否/予算超過/非サポート/非進行/非アクティブの結果は、プロバイダの切り替えや無限リースチェーンではなく、目に見えるスキップまたは失敗を必要とする。Daytonaなどの作成固定プロバイダは、割り当て時に十分なTTLを必要とする。
• 直接のゲストリフレッシュ障害により、古いオンボックス期限を持つより長いプロバイダ期限が残る可能性がある。同じローカル状態を維持し、調整のためだけに同じ固定合計TTLを再試行すること。失敗した延長を保護として扱ってはならない。
• 信頼できるdirectLeases: denyとdirectLeaseAllowを尊重すること。拒否されたプロバイダは、設定されたコーディネータールートを必要とする。直接認証情報でバイパスしてはならない。Testboxはネイティブのジョブおよびアイドル制限を保持する。--ttlは委任されたワークフローを延長しない。
• listはアクティブなコーディネーターリースを表示する。list --retainedは、クリーンアップが未確認の保持された終了リソースを追加する。回復には正確なIDの検査/停止を使用すること。ブロッキング停止が完了を確認するまで、クレームと回復状態を保持すること。

信頼できるTestbox

解決済みプロバイダ = Testbox（または明示的に要求された場合）: コマンドはそれを保持する。明示的なオーバーライドの場合のみ--provider blacksmith-testboxを追加する:

"$CRABBOX" run --timing-json -- CI=1 <check-command>

複数のコマンド: 一度ウォームアップし、IDを保存し、再利用し、停止する。

"$CRABBOX" warmup --keep --timing-json
"$CRABBOX" run --id <tbx_id> --timing-json -- <check-command>
"$CRABBOX" stop <tbx_id>

ルール:

• 1リース、1アクティブコマンド。実行中の同期/リクレームは不可。
• bash -cを優先すること。ログインプロファイルはディレクトリを変更する可能性がある。実行シェル内で、物理的なチェックアウトと期待されるソース/パッチをアサートすること。HEADだけではダーティ同期の証明にはならない。コンシューマの文書化されたハイドレーションシェル契約に従うこと。
• ネイティブのTestboxは、再利用された--id実行を含む、独自の同期を実行する。リモートベースラインに--no-syncを決して依存してはならない。Blacksmithにはネイティブのバイパスがない。リリースされたCrabboxバージョンはフラグを静かに無視する可能性がある。変更されていない意図的な再実行は例外ではない。
• --reclaimは、意図的なチェックアウトパスの所有権移転にのみ使用する。
• 再利用のためにコンシューマの割り当て受領書に従うこと。互換性のあるソースコミットは、タスク、物理チェックアウト、ベース、依存関係、準備、ワークフロー/ジョブ/refが変更されていない場合、リースを再利用できる場合がある。元の割り当ての出典を保持すること。互換性のない受領書: 停止し、再度ウォームアップする。古いリースのオーバーライドは不可。
• 生のSHAはwarmup --refには信頼できない。ブランチ/タグを使用すること。
• blacksmith testbox listは状態を隠す。list --allまたはstatus --id <tbx_id>を使用すること。
• Testboxのステータス/停止: --id。ステータス --jsonは不可。
• 委任されたプロバイダは--fresh-pr、--full-resync、--script*、--env-helper、キャプチャ/ダウンロードフラグを拒否する。

Blacksmithディレクトリダウンロード

再帰的ダウンロード + 必要なリモート末尾スラッシュ: ディレクトリダウンロード。

信頼できないAWS

• クリーンな信頼できるデフォルトブランチのチェックアウト。インストール済みの信頼できるCrabboxバイナリ。
• レビュー済みの完全なヘッドSHAごとに新しいリース。インスタンスロール、Tailscale、ハイドレーションは不可。
• CIのみを転送する。--fresh-prの隣に信頼できるブートストラップをアップロードする。

cd <clean-trusted-default-branch-checkout>
env -u CRABBOX_AWS_INSTANCE_PROFILE \
  "$CRABBOX" config show --json | \
  jq -e '.aws.instanceProfile == ""' >/dev/null

env -u CRABBOX_AWS_INSTANCE_PROFILE \
  -u CRABBOX_TAILSCALE \
  -u CRABBOX_TAILSCALE_AUTH_KEY \
  -u CRABBOX_TAILSCALE_AUTH_KEY_ENV \
  -u CRABBOX_TAILSCALE_EXIT_NODE \
  -u CRABBOX_TAILSCALE_EXIT_NODE_ALLOW_LAN_ACCESS \
  -u CRABBOX_TAILSCALE_HOSTNAME_TEMPLATE \
  -u CRABBOX_TAILSCALE_TAGS \
  "$CRABBOX" warmup \
  --provider aws --network public --tailscale=false \
  --tailscale-exit-node= \
  --tailscale-exit-node-allow-lan-access=false \
  --ttl 4h --idle-timeout 90m --keep --timing-json

"$CRABBOX" inspect --provider aws --id <cbx_id> --json | \
  jq -e '.network == "public" and .tailscale == null' >/dev/null

env -u CRABBOX_AWS_INSTANCE_PROFILE \
  CRABBOX_ENV_ALLOW=CI \
  "$CRABBOX" run \
  --provider aws --id <cbx_id> \
  --fresh-pr <owner/repo#number> \
  --no-hydrate --timing-json \
  --script <trusted-bootstrap-script> -- \
  <expected_full_head_sha> <check-command>

env -u CRABBOX_AWS_INSTANCE_PROFILE \
  "$CRABBOX" stop --provider aws <cbx_id>

• 信頼できるブートストラップは、IMDSv2 IAM認証情報が404を返すことを証明し、SHAを検証し、ランタイムインジェクション変数を削除し、ツールチェーンを固定し、インストール/テストの前にHOMEを分離する必要がある。
• 変更されたヘッド: 新しいリース。欠落しているリモートPRまたはロールがないことの証明: secretlessフォークCI。

直接AWS

• 信頼できるAWSコマンド、認証診断、再同期、クリーンなPR/コンテナ実行: 直接プロバイダを参照。
• コンテナ実行では--no-hydrateを保持すること。ローカルコンテナの証明はローカルとして報告すること。

可観測性

• アーティファクトの収集/認証情報の注入: キャプチャと環境フラグを参照。
• 正確なキー、1つのコマンド。シークレットを決して印刷したり、リポジトリに書き込んだり、シェル履歴に残したりしてはならない。
• 安全な注入パスがない場合: ライブ認証はブロックされる。フェイクキーの証明は不十分。

実際のE2E

• リモートの単体テストだけでなく、分離されたコンシューマ状態で要求されたユーザーエントリポイントを実行すること。
• インストール/プロバイダ/インタラクティブな証明と安全なリビジョン比較: E2E手順を参照。

デスクトップ / クロスOS

SSHターゲット、有料macOSプレフライト、WebVNC、アプリハンドオフ検証: デスクトップおよびクロスOSコマンドを参照。

障害トリアージ

ラッパー、プロバイダ、ハイドレーション、同期、SSH、またはコマンドの障害を特定する:

"$CRABBOX" doctor
"$CRABBOX" status --id <id>
"$CRABBOX" inspect --id <id> --json
"$CRABBOX" logs <run_id>
"$CRABBOX" results <run_id>
blacksmith testbox list --all
blacksmith testbox status --id <tbx_id>

• キューイングされた容量: 所有する割り当てを停止し、証明ポリシーに従う。再試行ストームやプロバイダの切り替えは不可。
• 古い同期: --debug --timing-json、その後、直接プロバイダで--full-resyncを1回実行する。
• 失敗したフェーズ/JUnitを、焦点を絞った再実行の前に読む。壊れたラッパー: 同じプロバイダでインストール済みCLIを使用して診断し、コンシューマの信頼できるパスを通じて更新する。
• 所有するIDのみを停止すること。stopは--timing-jsonを取らない。