antithesis-k8s-onboarding-assistance

Antithesis Kubernetes 入门协助

目的和目标

帮助在 Kubernetes 上运行的客户，将生产清单精简为 antithesis-setup 可用于构建 Antithesis 测试环境的形式。输出是一份结构化分析报告，而不是修改后的 YAML。

成功意味着：

• antithesis/scratchbook/k8s-minimization.md 是一份稳定、可供审阅的报告，说明了 setup 为 k8s 环境中的 SUT 构建测试环境所需的组件、依赖项、存根策略和决策
• 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 时的输入；在此之前，这份报告是交接给 Antithesis 客户团队的结构化材料，而非直接提供给 setup 的输入。无论下游使用者选择哪种路径，此技能都会生成相同的产物。

前置条件和范围界定

在此技能能够开展有效工作之前，需要了解测试范围：SUT 身份、测试边界，以及应用正常运行的成功标准。

有两种方式获取这些信息：

• 从先前的研究产物中读取。 查找 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-documentation 技能为 Antithesis 特定术语提供依据。

此技能没有专门的 Antithesis 文档页面，而是在 antithesis-research 和 antithesis-setup 之间建立衔接。对于任何 Antithesis 领域的概念（SUT、属性、scratchbook 约定、部署拓扑），请以这些技能的文档依据为准。

核心原则

不做考古。 默认方向是最小化。保留某项内容的门槛是“我们有理由相信应用需要它”。移除某项内容的门槛是“这看起来属于平台／集群方面的问题”。优化目标是提高客户取得成功的比例，而不是确保每个决策都正确。两种错误并不对称：

• 移除不该移除的内容： 会在设置或运行时被发现，可在几分钟内恢复。
• 提出太多考古问题： 客户会放弃，且无法挽回。

倾向于第一种。

默认设置较为激进；客户始终可以覆盖；每项决策都清晰可见。 在工作文件中记录决策内容及原因。客户可以查看并对任何决策提出异议，无须说明理由。撤销决策是一等操作——当先前的决策被推翻时，应在历史记录中明确显示撤销，而不是悄悄改写。

技能绝不运行集群命令。 这是不可妥协的原则。客户的机器、客户的 kubeconfig、客户的集群——技能只会说明命令并读取粘贴的输出，绝不执行命令。

绝不对客户说“不”。 工作遇到瓶颈时——运维人员没有响应、遇到棘手的架构问题、客户陷入困境——应为 Antithesis 客户合作团队准备升级材料。将死胡同变成交接机会。

保真度与速度之间的权衡应经过校准，并明确说明。 如果采用常见陷阱默认方案会显著影响保真度（例如，客户在生产环境中使用 Istio 进行测试，而我们却移除 Istio），应说明保真度方面的代价，并让客户选择。客户重视保真度时，不要悄悄优先追求速度。

让客户了解即将离开其环境的内容。 生成升级材料时，即使客户在接收信息时已经说明了对敏感数据的偏好，也应在生成文档前提示其审查敏感数据。受众不同，利害关系也不同。

技能流程

分为八个阶段。每次调用时，先读取工作文件，确定当前进度。工作文件的 frontmatter 记录了 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. 编译最终报告 + 检查交接准备情况。 仅当所有检查清单项都通过后，才汇总工作并编写最终报告——包括不再有状态为 Open 的项目。（参见 阶段指南 → 编译与交接。）

该流程需要多轮迭代。客户会在会话之间联系运维团队。技能会根据工作文件中的记录，从上次进度继续。

阶段转换。 进入每个阶段时，在工作文件的 frontmatter 中将 current_phase 更新为即将进入的阶段编号。第 4 和第 6 阶段的参考文件还会指出具体的阶段推进节点；除此之外，规则很简单——current_phase 始终表示技能当前所处的阶段，或恢复时即将开始的阶段。第 1 和第 2 阶段通常只在首次联系时执行，不会再次进入；工作文件在第 1 阶段创建，初始值为 current_phase: 1，之后逐步推进。

pass_count 和 last_pass 的语义。 一「轮」指客户与运维团队之间的一次往返。发生以下情况时，递增 pass_count，并将 last_pass 更新为当天的日期：

• 客户向运维团队获取答案后返回，生成新的 ops-questions.md
• 客户带来新的清单内容（渲染后的 Helm 输出、附加文件），触发重新分类
• 客户明确要求新一轮

在客户与运维团队的一次往返中多次调用技能，不算作多轮。pass_count 的值会显示在 ops-questions.md 的 Pass <N> 标题中。

阶段指南

确认前置条件

此阶段仅在首次调用时运行；后续调用会根据工作文件中 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。在 应用概述 部分填写 SUT 身份、测试边界、成功标准，以及这些信息的来源（sut-analysis.md 或访谈）。

问候

仅用于首次联系。包括以下要点：

• 这需要多轮处理，这是正常情况，并不意味着失败。
• 我们会在 antithesis/scratchbook/k8s-minimization-work/ 下创建可跨会话保留的产物，并在完成后提供最终报告。
• 每一轮通常都会以你需要向运维团队确认一些问题结束——这就是要做的工作。
• 我会积极精简 Kubernetes 平台机制——服务网格、监控、自动扩缩容、密钥管理 Operator 等。偶尔我会删掉应用实际需要的东西；如果发现这种情况，我们会加回来。优先尽快运行，而不是一开始就做到完美。
• 此技能会在最终报告处结束。下一步是 antithesis-setup，届时才会实际构建测试环境；完成精简并不等于环境已准备好运行测试。
• 如果遇到无法解决的问题，我们会生成一份可交给 Antithesis 项目团队的材料包——你不会陷入困境，而是可以带着背景信息升级处理。

最后询问：“你以前做过这种精简吗，还是第一次？”——这有助于调整需要提供多少指导，同时不会让对话听起来像测验。

当客户确认已理解上述说明并回答校准问题后，进入第 3 阶段（信息收集）。

Intake

采用对话方式，并配合内部检查清单。先扫描工作目录，查找符合 k8s 特征的文件（*.yaml 清单、Chart.yaml、kustomization.yaml、ArgoCD Application 文件）；根据找到的内容确定要问哪些问题。20 个问题的接待表会让人失去耐心；只问那些无法推断的问题。

主要步骤：

1. 敏感数据处理。 在客户粘贴任何内容之前，先询问：“清单中通常包含一些您可能不希望出现在本次对话中的信息——内部主机名、内嵌密钥、账号 ID、客户专属域名。这里是否包含此类信息？如果包含，您希望如何处理：直接在原文中删改、遮盖，还是原样分享？”将答复记录在工作文件的元数据中。在后续整个合作过程中遵循客户的偏好；之后每当可能出现新的敏感内容时，都要再次询问（例如生成升级处理资料包、编写引用清单的运维问题文档时）。

2. 必要时渲染 Helm / Kustomize。 如果客户提供的是模板而非渲染后的输出，请指导他们运行 helm template（使用他们的生产环境 values）或 kustomize build，然后将结果粘贴回来。单靠模板无法进行分析——实际部署内容取决于 values。

3. 内部检查清单——通过对话确认以下各项：

   • 客户名称、角色、运维联系人，以及运维人员回复时的首选渠道
   • 客户有哪些工件（Helm chart？Kustomize？原始清单？部分内容？暂时没有？）
   • 这些内容是否代表生产环境的实际形式，还是简化版本
   • 所用的云或平台层（尽力确认；回答“不知道”也可以）
   • 客户对 k8s 的熟悉程度
   • 应用成功标准——应用正常运行时应是什么样子

最容易被忽略、也最不该忽略的问题，就是成功标准。务必在接待时确认；否则交接准备度检查时就会遇到“完全不知道正常运行是什么样”。

客户审核检查点

完成横向分类后暂停。向客户展示分类结果——SUT、dep-real、dep-stub、范围外——并为每个组件提供一句理由。整理好格式，让客户无需停下来查资料，就能发现明显的误分类。

常见的异议包括：

• “X 属于范围内，因为它会执行你没发现的 Y”
• “Y 应该用模拟项而非真实项，因为 Z”
• “实际上并未使用 Z，把它去掉”

每项更正都要更新工作文件，并添加一条可在历史记录中看到的撤销条目。客户确认分类结果或提出更正后，都要记录一条历史记录；Self-Review 会检查这条记录。

客户确认分类结果或所有更正均已应用后，进入阶段 6（纵向分类）。在工作文件的 frontmatter 中设置 current_phase: 6。

Stub 策略

对于水平分类中归类为 Dependency-stub 的每个依赖项，在工作文件中编写一个 Stub 规格条目，说明 setup 需要构建什么。该技能生成描述；setup 构建实际的 stub。每个条目包含：

• 类型 — 依赖项的类型（HTTP 服务、gRPC 服务、消息队列、数据库、云 API 等）
• SUT 对它发起的调用 — 涉及哪些端点、方法或队列主题；测试流程中会发生哪些调用
• 预期响应形状 — stub 返回哪些预置响应；SUT 会读取哪些特定字段
• 测试要求的行为 — 成功路径、特定失败模式、延迟特征、调用顺序
• 排序／顺序约束 — 测试是否依赖特定调用顺序，或 stub 是否需要在多次调用间记住状态

示例：

### 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.

描述必须足够具体，让 setup 无需重新推导 SUT 的预期行为即可构建 stub。描述不规定 stub 的实现方式（Python、Go、mock 框架等）——由 setup 决定。

当 Stub 规格部分中的每个条目状态均为 Confirmed 或 Defaulted（不能有 Open），且水平分类中的每个 dep-stub 都有对应的 stub 规格时，进入阶段 8（编译并移交）。在工作文件的 frontmatter 中设置 current_phase: 8。

编译并移交

当 current_phase 为 8 时，运行移交就绪检查（参见 工作文件和最终报告结构 → 移交就绪检查清单）。如果检查通过，将工作文件中 当前状态各部分的内容快照写入 antithesis/scratchbook/k8s-minimization.md，作为最终报告。如果检查未通过，向客户列出缺漏并继续迭代——修复可能需要返回较早的阶段（将 current_phase 设回缺漏所属的阶段）。

编译阶段没有单独的客户审核检查点。客户可以在任何一轮检查工作文件，并对任何决策提出异议；提出异议后，应在工作文件中添加一条撤销记录。这是有意为之——在编译阶段增加第二个强制检查点会减慢迭代，而收益并不相称，因为 setup 运行并观察到行为后，仍可恢复 Defaulted 决策。水平审核检查点（阶段 5）是唯一的强制暂停点，因为水平分类错误代价最高（对错误分类的组件进行垂直分析会白费功夫）。

工作文件和最终报告结构

工作文件：antithesis/scratchbook/k8s-minimization-work/working.md

Frontmatter：

---
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（哪些情况算作一次 pass，请参阅 Skill 流程 → pass_count 和 last_pass 语义）。

正文 — 当前状态 部分：

1. 标题 / 元数据 — 客户信息、联系人、应用名称、运维联系人、交接就绪检查清单（见下文）
2. 应用概述 — 应用是什么、功能是什么、成功标准、SUT 身份、测试边界，以及这些信息的来源（研究的 sut-analysis.md 或接收信息时提供的同等研究输入）
3. 横向分类 — SUT、真实依赖、stub 依赖、范围外组件，以及推断出的调用图和任何未解决的调用图问题。以描述性方式记录反向依赖（生产环境中什么会触发 SUT），而非规定性方式。测试驱动程序设计决策应归入 antithesis-workload。
4. 组件清单 — 对每个保留的组件（SUT 或真实依赖）：镜像及拉取信息、副本数、环境变量及其来源、卷挂载、保留的 sidecar、入站 / 出站依赖、已应用的决策
5. Stub 规范 — 对每个 stub 依赖，说明设置需要模拟什么
6. 外部依赖（非 stub） — 测试环境必须考虑的集群外事物
7. 未解决的假设 — 未经确认便采用默认值的事项；如果行为有误，设置需要了解这些情况

每条记录都有一个状态：

• Confirmed — 已通过清单文件、客户和运维人员确认
• Defaulted — 已应用默认值，尚未提出异议
• Open — 正等待运维人员或客户反馈

正文 — 历史记录 部分：逐次 pass 记录日志。简要记录当前状态有哪些变更、收到哪些答复、哪些决策被推翻以及原因。

最终报告：antithesis/scratchbook/k8s-minimization.md

仅当交接就绪检查通过时生成。该报告是工作文件中当前状态各部分的快照（不含历史记录、不含 Open 项，也不含除快照日期外的实时 frontmatter）。待 setup 的 k8s 支持上线后，antithesis-setup 将直接读取此文件；在此之前，它是客户与其 Antithesis 项目团队共享的结构化交接材料。

如果后续问题（setup、项目团队反馈、客户侧发现）促使重新运行此技能并做出更改，则在下一次交接就绪检查通过时重新生成最终报告，覆盖之前的快照。工作文件历史记录会在重新生成期间保留审计轨迹。

交接就绪检查清单

只有在以下条件全部满足时，该技能才会编译最终报告：

• 已识别所有工作负载
• 已编目依赖（并标明 stub / 真实分类）
• 主要决策已确定或记为未解决的假设
• 已记录成功标准
• 所述组件中没有无法解释的平台遗留项
• 不再有状态为 Open 的项目（仅允许 Confirmed 和 Defaulted）

如果任何一项不满足，则不要编写最终报告。明确列出差距并告知客户，然后继续迭代。

运维问题格式

文件：antithesis/scratchbook/k8s-minimization-work/ops-questions.md。每次只处理一个文件，仅针对当前轮次。已解决的问题移入工作文件的历史记录；不要让 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，其中只包含仍未回答的问题，以及根据收到的答案引出的问题。工作文件的历史记录是问题是否已得到回答的权威记录。

敏感数据处理。 在接收时设置的偏好（记录于工作文件的 frontmatter 中的 sensitive_data_preference）决定了 ops-questions.md 内容的呈现方式。生成引用清单内容的问题时，按该偏好处理：就地脱敏（用占位符替换标识符）、屏蔽（使用 <service-name> 之类的通用名称），或原样分享。不要在每次重新生成时都再次询问客户——接收时的偏好适用于当前受众（客户自己的运维团队），反复询问会造成阻碍。只有在受众发生变化时才需要再次询问（升级材料包 → Antithesis 团队）；此时应遵循升级部分中的脱敏检查点。

升级材料包模板

文件：antithesis/scratchbook/k8s-minimization-work/escalation.md。按需生成。

两种触发情形：

• 客户提出请求（“我想请 Antithesis 的代表参与”）
• 工作停滞时，技能主动建议（而非自动生成）：多轮下来没有进展、运维团队对阻塞性问题没有回应，或客户表示不满

两种类型，结构相同：

• 停滞 — 技术工作本可继续，但人为或流程方面陷入停滞
• 难题 — 最小化工作本身遇到需要 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/ 目录，以便项目团队直接查看工作文件。生成材料包时告知客户这一点——不要把这条说明写进材料包正文。

脱敏检查点。 再次提示敏感数据处理（第一次在接收时）。即使客户在接收时选择了“原样分享”，也要再次询问——受众不同（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。
• 每次开始调用时都要读取工作文件。它是恢复工作的唯一事实来源。
• 做出决定时就记录，不要等到阶段结束。工作文件也用作审计轨迹。
• 未获得客户或运维团队明确意见而采用默认决定时，将其状态标记为 Defaulted，而不是 Confirmed。交接就绪检查读取的是状态字段。
• 客户对某项决定提出异议时，要在历史记录部分明确记录撤回决定。不要悄悄改写过去的决定。
• 以描述性方式在工作文件中记录反向依赖（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 项目团队的结构化交接资料）

自我审查

在宣布此技能已完成（撰写最终报告）之前，请根据以下标准检查工作文件。如果你的 Agent 支持生成子 Agent，请创建一个具有全新上下文的 Agent，让它进行审查——提供此技能文件和工作文件的路径。具有全新上下文的审查者能发现上下文内审查容易忽略的问题。如果你的 Agent 不支持子 Agent，请自行审查：重新阅读此文件开头的成功标准，然后根据以下各项检查工作文件。

审查标准：

• 工作文件的 Application overview 部分记录了 SUT 的身份、测试边界、成功标准，以及来源（研究的 sut-analysis.md 或研究等效的接收输入）
• frontmatter 中记录了敏感数据处理偏好（而不是 not-yet-asked）
• 客户清单中可见的每个组件都已分类为 SUT、dep-real、dep-stub 或 out-of-scope，并附有一行理由
• 在开始纵向工作之前，客户已审查并批准横向分类（工作文件的历史记录部分包含记录客户确认或更正内容的条目，并注明日期）
• 每个保留的组件（SUT 或 dep-real）都有一条 Component inventory 记录，涵盖镜像、副本数、环境变量、挂载、保留的 sidecar、出入依赖项
• 每个被模拟的依赖项都有一条 Stub specifications 记录，描述设置需要模拟的内容
• 每条 Defaulted 记录都有一行理由，说明选择该默认值的原因
• 以描述性方式记录反向依赖项，而非规定性描述——不要出现“需要测试驱动器”之类的措辞
• 明确记录尚未解决的假设，状态标记为 Defaulted 或 Open——不得悄然省略
• 工作文件中不得留有状态为 Open 的项目
• 已根据 frontmatter 中记录的偏好，对 ops-questions.md 中引用的任何清单内容应用敏感数据处理偏好
• 最终报告 antithesis/scratchbook/k8s-minimization.md 仅在确认已满足交接就绪条件后才撰写——它是快照，而不是实时工作文件的副本
• 最终报告不包含历史记录部分、不包含快照日期以外的实时 frontmatter，也不包含状态为 Open 的项目（因为生成快照时工作文件中不存在任何 Open 项目）
• 如果生成了升级记录，工作文件的历史记录中应能看到接收时和升级时的脱敏检查点
• 此技能从未运行集群命令；所有命令执行均由客户负责