runtime-probes

运行时探测

它是代码另一侧 spec-probes 技能的对应项。spec-probes 会在任何内容运行前探测需求；本技能则探测正在运行的系统，或在目标尚不可访问时，准备一个范围明确的运行时交接。

两种故障模式决定了这项设计。无上限的探测会耗尽预算并返回一堆噪声。无法由任何调用方触达的已提升发现，则会白白浪费维护者一天时间。第 1 阶段限定搜索范围。第 2 阶段限定哪些内容可以传出。

开始任一阶段之前

依次明确范围、探测面和停止条件。

范围。 可以是 PR 差异、单个功能或整个产品。对于差异，请使用 blast-radius 技能绘制变更图，并探测其中列出的内容，而不是重新推导。

探测面。 探测必须通过项目的 verify-<app> 驱动程序针对真实系统运行；如果项目尚无此驱动程序，则由 create-verification-skill 技能创建。如果缺少该驱动程序，请将所需的验证面报告为阻塞项，不要另行编造途径。未触达运行中系统的探测状态应为 not run，绝不能算作通过。

停止条件。 执行开始前必须设定界限。开放式实时探索需要任务或项目提供的预算和后果门槛。分别报告这两项限制，保留提供的值，并指出缺失的任何一项。如果调用方提供了明确的有限操作列表，且其调用次数和终止条件或超时都明确，则已具备界限。绝不能把你选择的探测或其数量视为任务提供的预算、调用次数上限或有限授权；计划不能为自身设定执行限制。如果可执行的运行没有界限，就停止并询问缺少的限制，不要擅自编造限制或改做其他工作。针对不可用运行时的计划可以继续，但必须说明仍缺少哪些执行限制。预算用于限制搜索；后果门槛则用于确定哪些影响值得继续调查和提升。如果已安装循环治理套件，就将外层循环交给它，并让本技能作为该循环运行的方法。

在树外维护一份由 runtime-probes 管理的记录，每项探测占一行。每行需注明入口点、类别、探测内容、状态，以及观察结果和证据 ID，或未运行的原因。已完成的调用必须有自己的证据 ID；数量不等于证据。如果禁止写入，就在回复中记录相同信息，而不是创建文件。决策日志请另行使用 show-me-your-work 技能。

第 1 轮：探测

在实时执行期间，盘点入口点，根据其形状选择相关类别，并提出范围有限的对抗性假设。根据观察到的结果进行调整，同时遵守声明的范围和停止条件。对于中断的序列，绝不会询问只读查询。分类体系有意保持封闭：清楚八个类别，胜过列出四十个却无人完成。

对于仅规划或无法执行的工作，只纳入任务或来源提供了具体条件且存在可观察结果的位置的探测。保留已声明的分支、边界和结果，不要臆造顺序、时间、证据或额外类别。根据来源实际声明的条件分类：类型或编码错误属于格式错误输入，未完成前放弃属于中断，完成后重试属于重放。相似的措辞或结果不能作为改换类别的依据。使用能区分来源行为分支的最小集合。将这些探测标记为 not run，并说明未执行的原因。如果请求的探测缺少条件或可观察界面，记录缺失的信息，不要自行补全。

在任务指定的有限工作单元完成后，只处理所提供的工作范围。将范围视为允许列表：上下文事实并不授权分析、分类、提出建议或请求跟进相邻场景。捆绑提供或预先计算的相邻结果只是上下文，不是经授权操作发现的影响。如果经授权的操作本身造成了重大的意外影响，只记录一次该影响，并在扩大范围前征求同意。在实时探索期间，边界只是起点，不是上限；在范围和预算内，根据观察到的行为调整数值和类型。

类别	形状	对抗性问题
格式错误输入	input	遇到错误类型、错误编码，或调用方本不应发送的字段时，会发生什么？
极端大小	input、resource	在零、一、文档规定的边界，以及远超最大实际值时，会发生什么？
中断的序列	sequence、state	操作中途因标签页关闭、进程被终止或连接断开而放弃时，有哪些内容会保留下来？
重复与重放	sequence、state	重复提交、返回上一页或重试请求时，会发生什么？
过期状态	state	客户端操作服务端已更改的状态时，会发生什么？
依赖项故障	boundary	依赖项出错、无返回结果或消失时，调用方会看到什么？
依赖项缓慢	boundary、resource	调用耗时从 10 毫秒变成 10 秒时，会发生什么？
并发参与者	concurrency、state	两个参与者同时操作同一条记录、文件或键时，会发生什么？

对于开放式运行，使用 swarm 技能按入口点划分探测任务并分派。该技能会自行确定工作者模型和投入，因此此处不要重复说明选择。工作者会根据其自身约定，附带证据报告 PASS、ISSUES 或 BLOCKED。不要再另行制定一套报告方式。

对于调用方提供的有限工作，只执行所提供的、有实际影响的操作，并保留其顺序和含义。允许只读检查所提供的文件，但这不构成探测证据，不能扩大范围、增加重放或支持对相邻场景的处置。除非明确要求并发，否则每次只执行一个操作，观察其结果后，再判断下一个操作是否仍获授权。字面命令代表完整调用，而非前缀：按原样运行一次。如果无法使用该命令所需的执行环境，应报告阻碍，而不是尝试包装命令、使用替代方案或重试。分别记录每次调用。

在已执行的运行时工作中，没有匹配形状的入口点应有一行“未分类，手动探测”的宽松记录，不得遗漏。仅规划或无法执行的回复中不要添加此行。

第 2 轮：晋级

每个发现都只是一个假设。使用你配置的 judgment and prose 模型及其配置的推理力度对每项发现作出判断。使用 pstack-harness 技能解决这些问题。只有同时满足以下三项条件，发现才会晋级。

1. 能够复现。 对于实时任务，harness 会从干净的初始状态重放该问题，并再次失败。对于仅作处置的任务，任务提供的已完成观察结果就是任务授权使用的执行证据；不要要求进行任务禁止的重放。既没有干净重放，也没有提供已完成证据的发现不得晋级。
2. 真实调用方能够触达。 指明调用方，以及从真实入口到故障的路径。若提供的源代码说明将已执行的驱动程序或操作映射到该调用方路径，这就是可达性证据；不要要求探测再次调用真实入口，也不要要求维护者重新确认源代码已明确说明的映射。严格的可达性要求仍意味着：如果没有调用方能通过某个守卫，守卫之后的缺陷就不得晋级。只有当源代码未明确说明调用方映射或适用的守卫时，才升级处理；如果源代码已直接说明，则不应升级处理。
3. 维护者会接受修复。 后果会被用户感知、影响数据，或跨越安全或隐私边界。内部代码不够整洁不算缺陷。

根据 ../poteto-mode/references/bugbot-triage.md 中的 fix / dismiss / ask 判定标准，对每项发现进行分类；这三种判定已标注在下方各状态中。按照该文件自身的格式记录总结出的驳回模式，而不是在下次运行时重新推导。

每项发现结束本轮时必须且只能处于一种状态。

• 已晋级（fix）：满足全部三项条件。该发现会获得一个回归测试，并在问题列表中占一行。
• 已驳回（dismiss），并附上理由。“无法触达，唯一的调用方会根据有界枚举值校验此字段”是有效理由。不能保持沉默。
• 缺口：能够复现，但不满足条件 2；该行需指出导致其无法触达的守卫。严格的可达性要求可以确保问题列表中的每项都无需再次争论，但代价是要保留这一行。之后若删除该守卫，缺口就会变为有效问题，因此守卫名称就是保留该行的全部价值。此状态由条件 2 决定，而非由判定标准决定，因此不带判定标签。
• 已升级处理（ask）：你无法自行判断条件 2 或 3，且该发现涉及安全、隐私、身份验证、计费、数据保留或权限边界。向用户询问。对于这些类别，切勿因不确定而驳回；这是该判定标准本身的常设规则。对该发现而言，本轮到此结束，而不是发现本身就此终结。收到答复后，它将转为已晋级、已驳回或缺口。

残留事项

执行运行后，探测脚本就是交付物。若任务授权修改仓库，请提交该脚本，以便审查者重新运行。对于仅规划、无法执行或只读的工作，不要创建或提交探测脚本；除非禁止修改文件，否则将范围有限的交接内容留在 findings.tsv 中。

若明确授权添加回归覆盖，请使用 poteto-tdd 技能。每个晋级的发现都要成为一个在修复前暂存的失败测试。若明确授权实施修复，请逐条发现运行 Bug 修复操作手册（../poteto-mode/playbooks/bug-fix.md）。未经授权，不要暂存测试或开始修复，也不要将多个修复合并到一次提交中。

晋级的测试应断言不变量，而不是逐字记录。「拒绝小于零的数量」在重构后仍然成立。「针对这段确切字节序列返回这条确切错误字符串」则不然。每个晋级的测试在提交前都要使用 verify-commands 技能验证，因为一个生成后显示通过、实际上却什么也没测的测试，比没有测试更糟。

报告范围、表面、停止条件、已执行或标记为 not run 的工作、证据 ID 以及最终处置结果。如果既没有已执行的证据，也没有任务提供的已完成证据，请报告阻碍和缺失事实，不要声称通过、发现问题、复现成功或得出了 Pass 2 结果。说明探测记录是已写入，还是保留在行内。