antithesis-k8s-onboarding-assistance

Antithesis Kubernetes オンボーディング支援

目的と目標

Kubernetes 上で実行するお客様が、本番環境のマニフェストを antithesis-setup で Antithesis のテスト環境を構築できる形式に最小化できるよう支援します。出力は構造化された分析レポートであり、変更済みの YAML ではありません。

成功とは、次の状態を指します。

• antithesis/scratchbook/k8s-minimization.md が、k8s ベースの SUT のテスト環境を構築するために setup が必要とするコンポーネント、依存関係、スタブ戦略、判断を記述した、安定したレビュー可能なレポートである
• antithesis/scratchbook/k8s-minimization-work/working.md に、各パスでの判断の経緯が記録されている。これには、撤回された判断、デフォルトで決定された事項、未解決の前提が含まれる
• お客様が、（a）最終レポートを setup に渡せる状態にしてこのスキルの作業を完了するか、（b）Antithesis のエンゲージメントチームと共有できるエスカレーションパケットを用意している

このスキルは Kubernetes 上で実行するお客様にのみ適用されます。Docker Compose を直接使用するお客様はこのスキルをスキップし、antithesis-research から antithesis-setup に進みます。

注：現在、antithesis-setup は Docker Compose ハーネスを構築します。setup 側での k8s サポートは別途進められています。この取り組みが完了すると、このスキルの最終レポートは k8s を使用するお客様向けの setup の入力になります。それまでは、setup に直接渡す入力ではなく、Antithesis のエンゲージメントチームへの構造化された引き継ぎ資料となります。後続の利用経路にかかわらず、このスキルが生成する成果物は同じです。

前提条件とスコープ設定

このスキルが有用な作業を行うには、テスト対象に関するスコープ情報が必要です。具体的には、SUT の識別情報、テスト境界、アプリが正常に動作していることを示す成功基準です。

この情報を取得する方法は 2 つあります。

• 以前の調査成果物から読み取ります。 antithesis/scratchbook/sut-analysis.md を探します。存在する場合は、そこから SUT の識別情報を読み取ります。
• お客様にヒアリングします。 何をテストするのか尋ねます。会話から SUT の識別情報、テスト境界、成功基準を把握します。

どちらの情報源でも構いません。後でスコープ情報の出所がわかるよう、作業ファイルにその情報源を記録します。

どちらの方法でも作業を進めるのに十分なスコープ情報が得られない場合（sut-analysis.md が存在せず、お客様がスコープを明確に説明できない場合）、これはワークフローの切り替えではなく、作業を妨げる問題です。このスキルで有用な作業を行うにはテスト対象を把握する必要があることを説明し、お客様が Antithesis のエンゲージメントチームに相談できるよう、エスカレーションパケットを作成する方法を案内します。

スコープ情報の出所にかかわらず、このスキルでは、お客様の k8s 成果物、運用担当者の連絡先、機密データの取り扱いに関する希望、成功基準の詳細など、追加のコンテキストを十分に収集します。スコープは開始の条件であり、インテークでは残りの情報を収集します。

このスキルでは、kubectl、helm、kustomize、docker、kind、k3d、その他クラスターに作用するコマンドは一切実行しません。お客様自身がコマンドを実行し、その出力を貼り付けることはできます。このスキルは貼り付けられた出力を読み取りますが、コマンドを実行することはありません。

定義と概念

• SUT： テスト対象システム（antithesis-research から引き継いだ用語）
• 水平最小化： 顧客のマニフェスト内のどのコンポーネントをテスト範囲に含めるか（SUT、依存関係、または範囲外）を判断すること
• 垂直最小化： 範囲内のコンポーネントから、単一ノードのテスト環境で実行できるよう、プラットフォーム／クラウド／可観測性に関する不要な要素を取り除くこと
• 単一ノードのテスト環境： Antithesis は、小規模で固定されたデプロイに対して、タイムラインを決定論的に探索します。複数ノードの分散システム機能（ノード間の合意形成、クラスターの自動スケーリング、実際のロードバランサー、CNI によって適用されるネットワークポリシー）は、この環境では価値をもたらしません。状態空間と非決定性が増えるだけです。「単一ノード」とは、Antithesis が分散システムの正しさをテストできないという意味ではありません。テストデプロイが Antithesis によって管理される単一の環境として実行され、複数のレプリカやサービスが実際のノード間に分散されず、同じ環境に配置されるという意味です。
• 作業ファイル： 各パスを通じて更新される、作業中の成果物（antithesis/scratchbook/k8s-minimization-work/working.md）
• 最終レポート： 引き継ぎ準備が整った時点で生成される、作業ファイルの現在の状態を固定したスナップショット（antithesis/scratchbook/k8s-minimization.md）
• 落とし穴： 一般に最小化によって取り除かれる、既知の手順があるプラットフォーム層の構成要素（Istio、cert-manager、external-secrets など）
• ステータスフィールド： 作業ファイルの各項目には、Confirmed、Defaulted、Open のいずれかのステータスが設定されます。Open の項目が残っていると、引き継ぎ準備が整ったと判断されません。

ドキュメントに基づく情報

Antithesis 固有の用語を確認するには、antithesis-documentation スキルを使用してください。

このスキル専用の Antithesis ドキュメントページはありません。antithesis-research と antithesis-setup の間をつなぐ役割を担います。SUT、プロパティ、スクラッチブックの規約、デプロイトポロジーなど、Antithesis の領域に属する概念については、これらのスキルのドキュメントを参照してください。

基本原則

過去の経緯を掘り起こさない。 基本方針は最小化です。何かを残すための基準は、「アプリがこれを必要としていると考える理由があること」です。取り除く基準は、「プラットフォーム／クラスターに関する事柄に見えること」です。個々の判断の正しさではなく、成功に至る顧客の割合を最大化してください。2 つの誤りは対称ではありません。

• 残すべきでないものを取り除く場合： セットアップ時または実行時に発見され、数分で復旧できます。
• 過去の経緯について質問しすぎる場合： 顧客が諦めてしまいます。取り返しがつきません。

前者に傾けてください。

デフォルトは大胆に設定し、顧客はいつでも上書きでき、すべての判断を明示します。 何を判断したか、その理由とともに作業ファイルに記録してください。顧客は内容を確認し、理由を説明しなくても、どの判断にも異議を唱えられます。判断の撤回も重要な記録です。以前の判断が覆された場合は、黙って書き換えるのではなく、履歴に明示してください。

このスキルはクラスターコマンドを実行しません。 これは絶対に守る必要があります。顧客のマシン、顧客の kubeconfig、顧客のクラスターに対して、このスキルはコマンドを説明し、貼り付けられた出力を読み取るだけで、コマンドを実行することはありません。

顧客に「できません」と伝えてはいけません。 作業が行き詰まった場合（運用チームから返事がない、解決が難しいアーキテクチャ上の問題がある、顧客が行き詰まっているなど）は、Antithesis のエンゲージメントチーム向けのエスカレーションパケットを作成してください。行き止まりを、円滑な引き継ぎにつなげます。

忠実度と速度のバランスは調整が必要なトレードオフであり、明示してください。 忠実度に大きく影響する落とし穴のデフォルト設定を適用する場合（たとえば、本番環境で Istio を使っている顧客のテストから Istio を取り除く場合）は、忠実度への影響を説明し、顧客に選択してもらってください。顧客が忠実度を重視しているのに、速度を優先する判断を黙って行ってはいけません。

顧客の環境から外部に送る内容について、顧客が把握できるようにしてください。 エスカレーションパケットを作成するときは、受付時に顧客が機密データに関する希望を伝えていた場合でも、文書を作成する前に機密データの確認を促してください。対象者が異なれば、リスクも異なります。

スキルのフロー

8 つのフェーズがあります。実行のたびに、まず作業ファイルを読み、現在の状況を確認します。作業ファイルのフロントマターに current_phase が記録されているため、セッションをまたいでスムーズに再開できます。

1. 前提条件を確認します。 sut-analysis.md を探すか、同等の調査範囲を得るために顧客に聞き取りを行います。どちらの方法でも進めるために十分な範囲を確認できない場合は、ブロッカーとして扱い、エスカレーション用パケットの利用を提案します。（フェーズガイダンス → 前提条件の確認 を参照してください。）

2. 挨拶／期待値の設定。 初回連絡時のみ行います。複数回に分けて進めること、大胆に削減すること、忠実度と速度のトレードオフ、顧客が変更を求められること、運用上の質問が作業の中心であること、エスカレーションの手段があることを伝えます。（フェーズガイダンス → 挨拶 を参照してください。）

3. 情報の聞き取り。 内部チェックリストを使いながら、対話形式で進めます。次の内容を確認します。まず機密データの取り扱い、必要に応じて helm／kustomize によるレンダリング、次に運用担当者の連絡先、成果物の形式、顧客の希望する関与度、アプリケーションの成功基準。（フェーズガイダンス → 情報の聞き取り を参照してください。）

4. 水平分類。 各コンポーネントを SUT／実依存／スタブ依存／対象外に分類します。調査範囲と、マニフェストから得られる呼び出しグラフに基づいて分類します。（references/horizontal-classification.md を参照してください。）

5. 顧客レビューのチェックポイント。 明確に作業を一時停止します。水平カットを提示し、顧客に異議や修正を求めてもらいます。誤分類したコンポーネントに対して垂直作業を行うことは、このスキルで最もコストの高い失敗です。この一時停止を省略しないでください。（フェーズガイダンス → 顧客レビューのチェックポイント を参照してください。）

6. 垂直分類。 残す各コンポーネントから、プラットフォーム／クラウド／オブザーバビリティ関連の不要要素を取り除きます。（references/vertical-classification.md と references/landmines.md を参照してください。）

7. スタブ戦略。 スタブ化する依存関係ごとに、セットアップで何を模倣する必要があるかを説明します。種別、実行される呼び出し、レスポンスの形状、必要な振る舞い、順序の制約を含めます。（フェーズガイダンス → スタブ戦略 を参照してください。）

8. 最終レポートの作成と引き継ぎ準備の確認。 「未完了」のステータス項目が残っていないことを含め、すべてのチェックリスト項目に合格した場合に限り、作業内容を最終レポートにまとめます。（フェーズガイダンス → 作成と引き継ぎ を参照してください。）

このフローは複数回に分けて進めます。顧客はセッションの合間に運用担当者のもとへ行きます。スキルは作業ファイルに記された段階から再開します。

フェーズの移行。 各フェーズに入る際は、作業ファイルのフロントマターにある current_phase を、これから開始するフェーズ番号に更新します。フェーズ 4 と 6 の参照ファイルには、具体的なフェーズ進行のタイミングも記載されています。それ以外は単純で、current_phase は常に、スキルが現在進行中のフェーズ、または再開時にこれから開始するフェーズを示します。通常、フェーズ 1 と 2 は初回連絡時のみ実行し、再度実行することはありません。作業ファイルはフェーズ 1 で current_phase: 1 として作成し、そこから先へ進めます。

pass_count と last_pass の意味。 「パス」とは、顧客と運用担当者との往復を指します。次の場合に pass_count を増やし、last_pass を今日の日付に更新します。

• 顧客が運用担当者から回答を得て戻ってきた後、新しい ops-questions.md を作成するとき
• 顧客が新しいマニフェストの内容（レンダリング済みの Helm 出力、追加ファイルなど）を持ち込み、再分類が必要になったとき
• 顧客が明示的に新たなパスを求めたとき

1 回の顧客と運用担当者との往復の中で、スキルを複数回実行しても、別々のパスとしては数えません。pass_count は、ops-questions.md の Pass <N> ヘッダーに反映される値です。

フェーズガイダンス

前提条件の確認

このフェーズが実行されるのは初回のみです。2回目以降は、作業ファイルの current_phase が示すフェーズから再開し、このセクションはスキップします。

スクラッチブックを確認します。 antithesis/scratchbook/ は、お客様のプロジェクトリポジトリのルート（スキルを実行するディレクトリ）にあります。これは Antithesis スキル群で共有されている規約です（antithesis-research/references/scratchbook-setup.md を参照）。antithesis/scratchbook/ が存在しない場合は作成します。次に、このスキルの作業用成果物を保存する antithesis/scratchbook/k8s-minimization-work/ を作成します。

スコープ情報を取得します。 antithesis/scratchbook/sut-analysis.md が存在する場合は読み込みます。これが標準の情報源です。存在しない場合は、お客様に「具体的に何をテストしていますか？単一のサービスですか、複数サービスにまたがるフローですか、データベースですか、それともエンドツーエンドの顧客ジャーニーですか？」と尋ねます。いずれかの情報源から、SUT の識別情報、テスト範囲、成功基準を記録します。

スコープをまったく特定できない場合（sut-analysis.md がなく、お客様もスコープを説明できない場合）は、ワークフローの振り分けではなくブロッカーとして扱います。このスキルが有用な作業を行うにはスコープ情報が必要であることを説明し、お客様が Antithesis のエンゲージメントチームに相談できるよう、エスカレーションパケットを用意する方法を案内します。

作業ファイルを作成します。 antithesis/scratchbook/k8s-minimization-work/working.md を初期化します。Application overview セクションに、SUT の識別情報、テスト範囲、成功基準、およびそれらの情報源（sut-analysis.md またはインタビュー）を記入します。

あいさつ

初回のやり取りでのみ行います。次の内容を伝えます。

• 複数回の作業が必要です。それが通常であり、失敗を意味するものではありません。
• antithesis/scratchbook/k8s-minimization-work/ に、セッション間で保持される成果物を作成し、完了時には最終レポートも作成します。
• 各回の作業は通常、お客様が運用チームに確認する質問を持ち帰るところで終わります。それがこの作業の一部です。
• Kubernetes のプラットフォーム機能（サービスメッシュ、監視、自動スケーリング、シークレットオペレーターなど）は積極的に削減します。アプリケーションに実際に必要なものを削ることもありますが、必要だと分かった時点で追加し直します。最初から完璧を目指すより、まず動かすことを優先します。
• このスキルは最終レポートの作成までを行います。次のステップは antithesis-setup で、そこで実際にテスト環境を構築します。最小化の完了は、すぐに実行できる状態になったことを意味するわけではありません。
• 解決できない問題が発生した場合は、Antithesis のエンゲージメントチームに渡せるパケットを作成します。行き詰まるのではなく、状況を伝えたうえでエスカレーションできます。

最後に「このような最小化を行ったことがありますか？それとも今回が初めてですか？」と尋ねます。これは、クイズのような印象を与えずに、どの程度サポートするかを調整するためです。

お客様がこの進め方を了承し、経験についての質問に答えたら、フェーズ 3（インテーク）に進みます。

インテーク

内部チェックリストに基づき、対話形式で進めます。まず作業ディレクトリをスキャンし、k8s 形式の成果物（*.yaml マニフェスト、Chart.yaml、kustomization.yaml、ArgoCD の Application ファイル）を確認して、見つかったものをもとに質問の範囲を決めます。20 問のインテークフォームでは相手が離れてしまいます。推測できないことだけを尋ねてください。

主な手順：

1. 機密データの取り扱い。 顧客が何かを貼り付ける前に、次のように尋ねます。「マニフェストには、この会話で共有したくない情報（内部ホスト名、埋め込みシークレット、アカウント ID、顧客専用のドメイン名など）が含まれていることがよくあります。該当するものはありますか？ある場合、どのように扱いますか？その場で伏せる、マスキングする、そのまま共有する、のいずれかをお選びください。」回答を作業ファイルのメタデータに記録します。その後のやり取りではこの希望に従い、新たな内容に機密情報が含まれる可能性がある場面（エスカレーション用パケットの作成、マニフェストから引用する運用上の質問ドキュメントなど）では、改めて確認してください。

2. 必要に応じて Helm／Kustomize をレンダリングする。 顧客がレンダリング済みの出力ではなくテンプレートを持ってきた場合は、helm template（本番用の値を指定）または kustomize build を実行し、その結果を貼り付けてもらうよう案内します。テンプレートだけでは分析できません。実際にデプロイされる内容は値によって決まります。

3. 内部チェックリスト — 次の項目を対話形式で確認します。

   • 顧客名、役割、運用担当者、運用担当者からの返答に使う希望チャネル
   • 用意している成果物（Helm チャート、Kustomize、未加工のマニフェスト、一部のみ、まだ何もない、など）
   • それが本番環境の構成を表しているか、それとも簡略化された構成か
   • 利用しているクラウド／プラットフォーム層（可能な範囲で確認します。「わかりません」でも構いません）
   • 顧客の k8s に関する習熟度
   • アプリの成功基準 — 正常に動作している状態とはどのようなものか

成功基準の確認は、最も省かれやすく、かつ省いた場合の代償が最も大きい質問です。インテーク中に確認してください。そうしないと、引き継ぎ準備の段階で「正常に動作している状態がわからない」という事態になります。

顧客レビューのチェックポイント

水平分類の後でいったん止めます。分類結果（SUT、dep-real、dep-stub、対象外）を、コンポーネントごとに1行の理由とともに提示します。顧客が調べものをせずとも、明らかな誤分類を見つけられる形式にしてください。

よくある異議のパターン：

• 「X は Y を行うので対象範囲に含まれますが、それが見えていません」
• 「Y は実物ではなくスタブにするべきです。理由は Z です」
• 「Z は実際には使われていないので、外してください」

修正があるたびに、作業ファイルを更新し、履歴に修正前後がわかる項目を追加します。顧客が分類結果を確認した場合、または修正を適用した場合は、履歴項目を記録してください。この履歴項目が Self-Review のチェック対象です。

顧客が分類結果を確認するか、すべての修正が適用されたら、フェーズ 6（垂直分類）に進みます。作業ファイルの frontmatter で current_phase: 6 を設定してください。

スタブ戦略

水平分類で Dependency-stub と分類された依存関係ごとに、作業ファイルに スタブ仕様 の項目を記述し、セットアップで構築するものを説明します。このスキルは説明を作成し、セットアップが実際のスタブを構築します。各項目では、以下を扱います。

• 種類 — 依存関係の種類（HTTP サービス、gRPC サービス、メッセージキュー、データベース、クラウド API など）
• SUT が依存先に対して行う呼び出し — 対象となるエンドポイント、メソッド、キュートピック、およびテストフロー中に行われる呼び出し
• 想定されるレスポンスの形式 — スタブが返す固定レスポンス、および SUT が読み取る特定のフィールド
• テストに必要な動作 — 成功パス、特定の失敗モード、レイテンシの特性、順序
• 順序／シーケンスの制約 — テストが特定の呼び出し順序に依存する場合、またはスタブが呼び出し間で状態を記憶する必要がある場合

例：

### auth-service (HTTP stub)

**Kind**: External HTTP service
**Status**: Confirmed

**Calls SUT makes**:
- `POST /token` (during login flow)
- `GET /verify?token=<...>` (during request authentication)

**Response shapes**:
- `POST /token` → `200 OK` with `{"access_token": "<test-jwt>", "expires_in": 3600}`
- `GET /verify` → `200 OK` with `{"valid": true, "user_id": "<id-from-request>"}` for tokens issued by this stub; `401` for unknown tokens

**Behaviors required**:
- Stable token issuance — same input produces same token within a test run
- Failure path: stub should return `401` for verification of an unrecognized token (the test exercises invalid-token handling)

**Ordering / sequencing constraints**: None — each request is independent.

説明は、SUT が何を想定しているかを再度導き出さなくても、セットアップでスタブを構築できるほど具体的にします。スタブの実装方法（Python、Go、モックフレームワークなど）は指定しません。それはセットアップ側で決定します。

スタブ仕様 セクションのすべての項目のステータスが Confirmed または Defaulted（Open がない状態）になり、水平分類で Dependency-stub に分類されたすべての依存関係に対応するスタブ仕様が作成されたら、フェーズ 8（コンパイルと引き継ぎ）に進みます。作業ファイルのフロントマターで current_phase: 8 に設定します。

コンパイルと引き継ぎ

current_phase が 8 の場合、引き継ぎ準備状況の確認を実行します（作業ファイルと最終レポートの構成 → 引き継ぎ準備状況チェックリスト を参照）。確認に合格した場合は、作業ファイルの 現在の状態 セクションのスナップショットとして、antithesis/scratchbook/k8s-minimization.md に最終レポートを作成します。合格しなかった場合は、不足項目をお客様に伝えて反復を続けます。修正のために前のフェーズに戻る必要がある場合もあります（不足項目が属するフェーズに current_phase を戻します）。

コンパイル時に、別途お客様にレビューを依頼するチェックポイントはありません。お客様はどの段階でも作業ファイルを確認し、あらゆる決定に異議を唱えることができます。異議があった場合は、作業ファイルに取り消しの記録を追加します。これは意図的な設計です。コンパイル時に必須のチェックポイントを追加すると、相応の利点がないまま反復のサイクルが遅くなるためです。セットアップの実行時に動作を確認すれば、Defaulted の決定は後から修正できます。水平レビューのチェックポイント（フェーズ 5）のみが必須の中断点です。水平分類を誤ると、誤って分類されたコンポーネントに対する垂直方向の作業が無駄になり、最も大きなコストが発生するためです。

作業ファイルと最終レポートの構成

作業ファイル：antithesis/scratchbook/k8s-minimization-work/working.md

フロントマター：

---
current_phase: <integer 1-8 matching the phase the skill should resume in>
sensitive_data_preference: <"redact-in-place" | "mask" | "share-as-is" | "not-yet-asked">
started: <YYYY-MM-DD>
last_pass: <YYYY-MM-DD>
pass_count: <integer>
---

フェーズ 1 で作業ファイルを作成したときの初期値：current_phase: 1、sensitive_data_preference: not-yet-asked、started と last_pass はどちらも今日の日付、pass_count: 0。インテーク後に ops-questions.md を初めて再生成すると、pass_count は 1 になります（何を 1 回のパスと数えるかについては、スキルのフロー → pass_count と last_pass の意味を参照してください）。

本文 — 現在の状態のセクション：

1. ヘッダー／メタデータ — 顧客情報、連絡先、アプリ名、運用担当者、引き継ぎ準備チェックリスト（以下を参照）
2. アプリケーションの概要 — アプリとは何か、何をするか、成功基準、SUT の識別情報、テスト境界、およびこれらの根拠（調査の sut-analysis.md またはインテーク時に提供された調査相当の入力）
3. 水平分類 — SUT、実依存関係、スタブ化する依存関係、対象外と、推定された呼び出しグラフおよび未解決の呼び出しグラフに関する質問。逆依存関係は規範的ではなく、記述的に記録します（本番環境で何が SUT をトリガーするか）。テストドライバーの設計に関する決定は antithesis-workload の担当です。
4. コンポーネントのインベントリ — 対象として残す各コンポーネント（SUT または実依存関係）について、イメージとプル情報、レプリカ、環境変数とそのソース、ボリュームマウント、残すサイドカー、依存関係の入出力、適用した決定
5. スタブ仕様 — スタブ化する依存関係ごとに、セットアップで再現する必要がある内容
6. 外部依存関係（スタブ化しないもの） — テスト環境で考慮する必要がある、クラスター外のすべてのもの
7. 未解決の前提 — 確認なしでデフォルトを適用した項目。動作が正しくない場合に、セットアップが把握できるようにします

各項目にはステータスがあります。

• Confirmed — マニフェスト、顧客、運用担当者から確認済み
• Defaulted — デフォルトを適用済みで、まだ見直されていない
• Open — 運用担当者または顧客からの回答待ち

本文 — 履歴セクション：パスごとのログ。簡潔に、現在の状態で変更した内容、得られた回答、覆した決定とその理由を記録します。

最終レポート：antithesis/scratchbook/k8s-minimization.md

引き継ぎ準備が整った場合にのみ生成されます。作業ファイルの現在の状態のセクションをスナップショットしたもので（履歴、Open 項目、スナップショット日以外の動的なフロントマターは含みません）。セットアップの k8s サポートが導入された後は、antithesis-setup がこのファイルを直接読み込みます。それまでは、顧客が Antithesis のエンゲージメントチームに共有する、構造化された引き継ぎ資料となります。

下流で発生した問題（セットアップ、エンゲージメントチームからのフィードバック、顧客側での発見）によってこのスキルに再度取り組み、変更を加えた場合は、次回の引き継ぎ準備確認時に最終レポートを再生成し、前回のスナップショットを上書きします。作業ファイルの履歴により、再生成をまたいで監査証跡が保持されます。

引き継ぎ準備チェックリスト

スキルは、以下のすべてを満たした場合にのみ最終レポートを作成します。

• すべてのワークロードを特定済み
• 依存関係を分類して記録済み（スタブ化するか実際のものかを分類）
• 主要な決定を確定済み、または未解決の前提として記録済み
• 成功基準を記録済み
• 記述したコンポーネントに、説明のないプラットフォーム関連の残存項目がない
• Open ステータスの項目が残っていない（Confirmed と Defaulted のみ許可）

いずれかの項目を満たしていない場合、最終レポートを作成しないでください。不足項目を顧客に明示し、反復を続けてください。

Ops-Questions Format

ファイル：antithesis/scratchbook/k8s-minimization-work/ops-questions.md。一度に1ファイルのみを対象とし、現在のパスに限ります。解決した質問は作業ファイルの履歴に移し、ops-questions.md に複数のパスにまたがって蓄積しないようにしてください。

最適化の目標：運用エンジニアがドキュメントを開き、5分で回答でき、会議を必要としないこと。

構成：

# Ops Questions — <project name> — Pass <N>

[Brief intro context — use this template, filling in <customer-side-engineer> and
 <project name>:

  > <customer-side-engineer> here. We're working with Antithesis, a deterministic
  > testing service that runs our application against a wide range of fault scenarios
  > and timing conditions to find bugs we'd otherwise miss. To run our system in
  > Antithesis, we need to minimize our production Kubernetes setup down to a
  > self-contained test environment, and that needs answers to the questions below.
  >
  > Reply by editing this doc inline or pasting into Slack. The worst case is we
  > make a wrong call and the test setup fails to start — we can fix iteratively.
  > Your answer doesn't have to be perfect.

If the customer wants to phrase it differently, that's fine — the requirements are:
two sentences explaining Antithesis, the reply mechanism, and the "answer doesn't
have to be perfect" framing.]

## Quick context

- What ingress controller do we use? (nginx / traefik / aws-alb / other / none)
- What's the storage class for PVCs in <namespace>? (default / specific / none)
- Are there mutating admission webhooks active? (yes / no / don't know)
[etc. — one-line factual questions ops can answer fast]

## Blocking — we can't proceed without these (or an explicit "don't know")

### Q1: <Specific, scannable title>

**Where**: <file path or kubectl reference>

**Why we're asking**: <one sentence — what decision this affects>

**Pick one**:
- [ ] <Answer A> → we [action] and proceed
- [ ] <Answer B> → we [different action]
- [ ] Don't know → we [default action] and customer team can flag if it breaks verification

[etc.]

## Confirming assumptions

### A1: <Title>

**Assumption**: <what we're assuming and why>

**Push back if**: <what would invalidate the assumption>

[etc.]

## Nice-to-know

- <one-liner>
- <one-liner>

ブロッキングとなる質問では、すべて「わからない → デフォルトの対応」という選択肢を必須にしてください。これがなければ、未回答の質問がいつまでも作業を止めてしまいます。これがあれば、最悪の場合でも修正可能な誤った判断にとどまります。

質問する内容の選別。 回答によって判断が変わる場合に限り質問してください。スキルがどのみちデフォルトで破棄する場合は、質問しないでください。質問はどれも、顧客と運用チームの関係に負担をかけます。

一部回答への対応。 運用チームからの返信で、一部の質問だけに回答があった場合は、回答済みの質問の内容を作業ファイルの履歴に移して（回答を記録して）、未回答の質問と、受け取った回答によって新たに生じた質問のみを含む ops-questions.md を再生成してください。どの質問が回答済みかを記録する正規の場所は、作業ファイルの履歴です。

機密データの取り扱い。 受付時に設定した希望（作業ファイルのフロントマターに sensitive_data_preference として記録）が、ops-questions.md の内容の形式を決めます。マニフェストの内容を引用する質問を生成する際は、希望に従ってください。具体的には、その場で編集して識別子をプレースホルダーに置き換える、一般的な名前（<service-name> など）でマスキングする、またはそのまま共有する、のいずれかです。再生成のたびに顧客へ再確認しないでください。この希望はこの読者（顧客自身の運用チーム）に対するものであり、再確認は手間になります。再確認が必要なのは読者が変わる場合（エスカレーション用パケット → Antithesis のエンゲージメントチーム）に限られ、その際はエスカレーションのセクションにある サニタイズの確認 が適用されます。

エスカレーション用パケットのテンプレート

ファイル：antithesis/scratchbook/k8s-minimization-work/escalation.md。必要に応じて生成します。

きっかけは2つです。

• 顧客からの依頼（「Antithesis の担当者にも共有したいです」）
• 停滞時にスキルが自発的に提案する（自動生成はしません）。複数回のパスを経ても進展がない、ブロッキングとなる質問に運用チームから回答がない、顧客が不満を示している場合などです。

形式は2種類で、構成は共通です。

• 停滞 — 技術作業は続けられるものの、人やプロセスの側で行き詰まっている
• 難題 — 最小化の作業自体が、Antithesis 側の専門知識を必要とする問題に直面している

構成：

# Antithesis Escalation Packet — <customer> — <YYYY-MM-DD>

## Context
- Customer: <name, contact>
- App under test: <brief>
- Cluster environment: <cloud/platform>
- Customer-side engineer: <name, role>
- Antithesis engagement contact (if known): <name>

## Status
- Currently on pass <N>
- Started: <YYYY-MM-DD>
- Most recent activity: <YYYY-MM-DD, what>

## Why we're escalating
<One paragraph. Specific. Not "we're stuck."
Example: "Three passes in; ops unresponsive on four blocking Istio AuthZ
questions; customer engineer unable to get internal traction.">

## Decisions so far
<Compact summary of the working file's consequential calls.>

## What's open
<Compact view of ops-questions.md, with how long each has been outstanding.>

## What we've tried
<For hard-problem escalations specifically. Otherwise omit.>

## Suggested next steps
<Skill's best guess at what would unstick this. Be honest about confidence — if
 the skill genuinely doesn't know, say so. "We've exhausted what we can do
 without ops input" is a valid suggestion.>

## Artifacts
- working.md
- ops-questions.md
- (final report not yet generated; or path if it exists)

成果物の添付。 パケット自体は単一の Markdown ドキュメントです。エンゲージメントチームが作業ファイルを直接確認できるよう、送付時には antithesis/scratchbook/k8s-minimization-work/ ディレクトリ全体を添付するよう顧客に伝えてください。パケットの生成時にこのことを顧客に伝え、パケット本文には指示を埋め込まないでください。

サニタイズの確認。 機密データに関する2回目の確認です（1回目は受付時です）。受付時に顧客が「そのまま共有する」を選択していても、読者もリスクも異なるため、もう一度確認してください（Antithesis のエンゲージメントチーム向けです）。また、パケット内に明らかなパターン（内部ホスト名、IP 範囲、クラウドアカウント ID、ARN、埋め込み認証情報、顧客専用ドメイン）がないか確認し、添付一式全体をレビューするよう顧客に促してください。希望があれば、サニタイズ済みのコピーを作成すると伝えてください。何を送信するかの最終判断は顧客が行います。

トーン。 スキル自身の語り口で作成し、顧客が送信前に確認・編集します。苦情ではなく、中立的かつ事実に基づく内容にしてください。「現状、阻害要因、担当者にできる支援」を伝えます。書き直さずにそのまま転送できる内容にしてください。

その時点のスナップショットであり、更新し続ける文書ではありません。 各エスカレーションは、その時点の状況を記録します。後日、再びエスカレーションが必要になった場合は新しいものを生成し、単一の継続的なエスカレーション文書を維持しようとしないでください。

参照ファイル

参照先	読むタイミング
references/horizontal-classification.md	フェーズ 4 — コンポーネントを SUT／dep-real／dep-stub／out-of-scope に分類する前
references/vertical-classification.md	フェーズ 6 — 残すコンポーネントからプラットフォーム／クラウド関連の不要な要素を取り除く前
references/landmines.md	フェーズ 6、vertical-classification と併せて — よくあるプラットフォーム構成要素の厳選リストとその対処方法を確認するため。また、オペレーターとその生成物の例外ケースについては horizontal-classification からも参照します
references/operator-recipes.md	フェーズ 6、オペレーターの置き換えを判断する場合（postgres-operator → プリミティブなど）

一般的なガイダンス

• 顧客のマニフェストはそのままの場所に置いてください。YAML を変更または書き換えないでください。
• すべての呼び出しの開始時に作業ファイルを読んでください。再開時に参照する唯一の情報源です。
• 判断は各フェーズの終了時ではなく、決まり次第記録してください。作業ファイルは監査記録でもあります。
• 明示的な顧客または運用チームの入力がなく、判断を既定値にする場合は、ステータスを Confirmed ではなく Defaulted にしてください。引き継ぎ準備状況のチェックではステータス欄が参照されます。
• 顧客が判断に異議を唱えた場合は、履歴セクションに取り消しを明記してください。過去の判断を黙って書き換えないでください。
• 逆依存関係（cron ジョブ、外部呼び出し元）は、作業ファイルに説明的な形式で記録します（「本番環境では、X が Y を使って SUT をトリガーする」）。テストドライバーを用意するかどうかの判断は antithesis-workload が担います。「テストドライバーが必要」とは書かないでください。
• オペレーターの置き換えは、水平／垂直の境界に関するケースです。オペレーターは除外します（垂直）が、オペレーターが生成するものには独自のコンポーネント項目を作成します（水平）。references/operator-recipes.md を参照してください。

出力

• antithesis/scratchbook/k8s-minimization-work/working.md（各パスで引き継いで使用）
• antithesis/scratchbook/k8s-minimization-work/ops-questions.md（現在のパスのみ。各パスで再生成）
• antithesis/scratchbook/k8s-minimization-work/escalation.md（必要な場合のみ）
• antithesis/scratchbook/k8s-minimization.md（引き継ぎ準備状況の条件を満たしたときに生成。setup の k8s サポートが追加された後は antithesis-setup が使用し、それまでは Antithesis のエンゲージメントチーム向けの構造化された引き継ぎ資料）

セルフレビュー

このスキルが完了したと宣言する前に（最終レポートを作成する前に）、以下の基準に照らして作業ファイルをレビューしてください。エージェントがサブエージェントの起動に対応している場合は、新しいコンテキストでレビューを行うエージェントを作成し、このスキルファイルと作業ファイルのパスを渡してください。新しいコンテキストでレビューすることで、同じコンテキスト内のレビューでは見逃しやすい盲点を発見できます。サブエージェントに対応していない場合は、自分でレビューしてください。まず、このファイルの冒頭にある成功基準を読み直し、次に以下の各基準を作業ファイルと照合してください。

レビュー基準：

• 作業ファイルの Application overview セクションに、SUT の識別情報、テスト境界、成功基準、および情報の出所（リサーチの sut-analysis.md またはリサーチと同等のインテーク入力）が記載されている
• 機微データの取り扱いに関する希望が、フロントマターに記録されている（not-yet-asked ではない）
• 顧客のマニフェストに含まれるすべてのコンポーネントが、SUT、dep-real、dep-stub、または out-of-scope に分類され、それぞれに1行の理由が記載されている
• 垂直方向の作業を始める前に、顧客が水平方向の分類をレビューして承認している（作業ファイルの履歴セクションに、顧客の確認または修正を記録した日付付きの項目がある）
• 残すコンポーネント（SUT または dep-real）ごとに、イメージ、レプリカ数、環境変数、マウント、残すサイドカー、依存関係の入出力を網羅する Component inventory の項目がある
• スタブ化する依存関係ごとに、セットアップで何を偽装する必要があるかを記述した Stub specifications の項目がある
• Defaulted の項目ごとに、選択したデフォルトの理由が1行で説明されている
• 逆依存関係は指示的ではなく、説明的に記録されている。「テストドライバーが必要」といった表現は使われていない
• 未解決の前提は、Defaulted または Open のステータスを付けて明示的に記録されている。暗黙のまま省かれていない
• 作業ファイルに Open ステータスの項目が残っていない
• フロントマターに記録された希望に従って、ops-questions.md に引用されたマニフェストの内容にも、機微データの取り扱いに関する希望が適用されている
• 最終レポート antithesis/scratchbook/k8s-minimization.md は、引き継ぎの準備が整っていることを確認した後にのみ作成されている。これはスナップショットであり、稼働中の作業ファイルのコピーではない
• 最終レポートには、履歴セクション、スナップショット日以外の稼働中のフロントマター、Open ステータスの項目が含まれていない（スナップショット時点で作業ファイルに Open の項目がなかったため）
• エスカレーションを作成した場合、サニタイズのチェックポイント（インテーク時およびエスカレーション時）が作業ファイルの履歴に記録されている
• このスキルはクラスタコマンドを実行していない。すべてのコマンド実行は顧客の責任で行われている