思维实验 ver 0.6.0 alpha — 严格的失败场景审计与修复
触发词： “thought experiment”，且仅此短语——不推断等效表达。在没有明确请求和清晰目标的情况下绝不运行——这是刻意的，不是自主的。
范围： 目标无关。单个文件、整个项目、配置、API合同、基础设施设置——任何可能出错的声明（关于自身行为、结构或依赖的内容）的目标。
与普通审查的不同之处： 两点。第一，它产生具体场景——“给定此输入/此状态，此处确切地出问题并解释原因”——而不是模糊的“这个可以更干净”的建议。第二，它专门追查目标关于外部事物行为的声明，因为这类声明最常因依赖记忆而悄然出错，而不是通过阅读目标自身的逻辑来捕获。
轮次前提交检查（安全护栏）： 在执行轮次前，严肃要求并推荐提交/推送所有现有的未提交更改。事先有一个干净的检查点，意味着如果轮次造成任何损害，始终可以回滚到该检查点。
流程
- 重新读取目标。 拉取其当前、真实的状态——文件、配置，无论它由什么组成——不依赖早期关于它应包含内容的上下文。
- 枚举其依赖项。 任何目标视为自身之外的绝对真理：对于脚本——导入的库、调用的API、CLI工具及其标志、环境/配置假设；对于服务或云设置——它与之交互的其他服务、权限/IAM、DNS、证书、第三方API、网络路径；对于文档——它关于其他事物行为的每一个事实性声明。有意地构建此列表——第4步将验证它，遗漏一个依赖项就意味着错失捕获真实错误的机会。当目标专门用于部署时，还要检查：回滚安全性、开发/生产配置一致性、秘密处理、声明的兼容性基线，以及首次加载/实际条件下的性能与仅开发测试——这些并不总是从纯粹的通用依赖扫描中浮现。对于配对文档（README及其SKILL.md，或文档与它们描述的代码/配置），将每个文件关于对方所说或所做的声明视为要验证的依赖项——并单独检查已建立的格式约定（枚举值的粗体/大小写处理、标题样式）是否在目标内及其兄弟文件间一致应用，仅当存在此类约定可供检查时。
- 构建具体的失败场景思维实验。 导致特定错误输出、崩溃或安全漏洞的具体输入或状态——而不是一般印象。不要预先固定场景数量；继续生成，直到感觉目标的实际风险面已覆盖，而不是达到任意数字。
- 验证每个场景依赖的依赖行为声明，对照现场或权威来源——真实文档、实际API响应、工具的真实输出——而不是信任记忆。这一步通常是最高价值发现的来源。
- 在应用修复前，一次性询问如何授权修复——CRUD选项。 读取始终免费授权，从不设门控；只有创建/更新/删除被授权。批量（每个已确认发现，无需进一步询问）、流程（每轮确认一次，而非每文件内）、文件（在移至下一文件的修复前确认）、或每一步CRUD（确认每个单独编辑）——用户选择的选项在本次运行的剩余部分有效。批量覆盖常规已确认发现，而非无条件覆盖：真正令人惊讶或高于用户授权时预期风险的发现仍会暂停并询问。
- 对已确认发现应用修复，按授权粒度进行。
- 对修复后的状态重新运行此相同流程。 修复可能引入自己的新问题——使其他事物不一致的准确性修复、破坏其他地方不同假设的更正声明。循环直到某次遍历未发现新内容才算完成。
- 报告。 简明陈述每个场景的通过/失败。仅对已确认失败提供完整细节，或当明确要求详细信息时——干净通过不需要为其写一篇论文。将每个失败标记为阻塞性（必须在部署/发布前修复）或非阻塞性（可安全发布，之后修复），使报告不仅作为发现列表，还充当继续/停止输入。每次运行以一个整合的编号摘要结束，而非仅散落在流程中的逐场景提及——按规模缩放：多目标运行（多个文件、多个技能）每个目标一个部分；单个干净目标一句简洁的判定行，无需填充仪式。
新行，每条报告以thought experiment结束。