reproduce-and-fix-issues

复现并修复问题

等待源线程中出现可信的分诊标记。通过目标应用的真实 UI 复现确切症状。如果已有修复，则验证该修复。只有确认复现后，才尝试范围有限的修复。

加载自动化提供的外部 Benny 配置。如果缺少配置、必需操作、控制适配器或已完成的功能映射，则安全失败。

硬性安全规则

• 开始任何工作前，冻结源频道和根线程坐标。
• 绝不在源频道中发布根消息。
• 每次在源线程发布前，都要预检源父消息。
• 协调者是唯一可以在 Slack 发布消息的角色。
• 委派的分析工作者只能读取，并返回调查结果或媒体说明。
• 修复阶段的代码工作者只有在其环境可证明不包含 Slack 凭据和任何 Slack 写入操作时，才能编辑代码。否则由协调者编辑。
• 每个子任务提示词都必须明确禁止使用 SendSlackMessage、PostToSlack、chat.postMessage 以及任何其他 Slack 写入操作。
• 绝不给子任务提供 Slack 令牌、发布说明、用于发布的源坐标或对外报告权限。
• 如果子任务需要 Slack 写入权限才能运行，则不要启动它。
• 实用机器人是证据来源。除非某人明确将修复工作委派给它们，否则它们无权负责修复。
• 必须通过真实 UI 交互两次观察到确切的区分性症状。
• 状态检查可以确认观察结果，但不得注入或强行触发症状。
• 未确认复现，则不得编写修复。
• 若已有拉取请求或提交，则切换到验证模式。不要在其基础上另行编写修复。
• 使用 github.com 拉取请求链接。
• 不要将捕获文件、录制内容、日志和令牌加入源代码管理。
• 委派分析时使用 pstack 的 principle-guard-the-context-window。
• 在复现、修复和验证过程中应用 pstack 的 principle-sequence-verifiable-units、principle-fix-root-causes 和 principle-prove-it-works。

1. 冻结源坐标

在列出工作项或委派任务之前：

1. 要求触发器频道与配置的源频道一致。
2. 如果 trigger.thread_ts 存在，则将其设为 SOURCE_THREAD_TS；否则使用 trigger.ts。
3. 要求 SOURCE_THREAD_TS 非空。
4. 将 SOURCE_CHANNEL_ID 和 SOURCE_THREAD_TS 存储为不可变值。
5. 读取源线程，并确认其根消息具有这些确切坐标。
6. 获取源消息的永久链接。

绝不要将这些值替换为回复时间戳、运维时间戳或状态消息时间戳。

每次在源频道发布前：

1. 使用不可变坐标读取线程。
2. 确认父消息存在、未被删除且仍属于源频道。
3. 仅使用 channel=SOURCE_CHANNEL_ID 和 thread_ts=SOURCE_THREAD_TS 发送。
4. 再次读取线程，并确认新消息是回复。

如果任何检查失败，则不要发布任何内容。绝不要尝试在根消息中或备用频道发布。

2. 等待分诊约定

在配置的判定时限内监视源线程。等待期间保持沉默。

仅在以下条件都满足时接受判定：

• 作者与 slack.triage_identity_user_id 一致。
• 该消息是 SOURCE_THREAD_TS 下的回复。
• 该消息恰好包含一个配置的标记。

公开标记形式：

[benny:bug]
[benny:bug] tracker=https://tracker.example/issue/123
[benny:performance]
[benny:performance] tracker=https://tracker.example/issue/123
[benny:other]

仅当判定为 bug 或 performance 时继续。记录可选的跟踪器 URL。若判定为 other、缺少判定、作者不可信、标记冲突或超时，则静默停止。

此标记取代私有机器人身份和自由格式判定匹配。

3. 应用所有权与修复产物门槛

开始工作前立即重新读取线程。

有人明确负责修复

如果有人明确表示负责修复、给出具体实现计划，或要求其他 Agent 实现、打补丁、修复或创建拉取请求，请停止。

以下情况不视为有人负责修复：

• 机器人总结证据。
• 工具查询日志或工单。
• 有人要求机器人诊断、解释、检查或复现问题。
• 机器人提出原因假设，但并未同意实现修复。

根据对方要求执行的操作判断，不要只看是否出现了机器人。

已有修复产物

如果存在一个可能修复此报告的开放拉取请求或已合并提交，请切换到 references/verify-existing-fix.md。

修复产物可以来自讨论串、跟踪器问题、仓库历史记录或拉取请求搜索。没有提交或拉取请求的说法不算修复产物。

如果有人负责这项工作，但尚未产出修复产物，请停止。不要抢先处理。

4. 打开可选的运维讨论串

如果已配置 slack.operations_channel_id，协调器可以在那里创建一条根状态消息。这是复现工作流中唯一允许发布的根消息。

将其坐标存储为 OPERATIONS_CHANNEL_ID 和 OPERATIONS_THREAD_TS。切勿与源消息坐标混淆。

使用已配置的纯 Unicode 状态文本。状态文本应简短：

• 正在复现
• 无法复现
• 已阻塞
• 已复现
• 正在验证现有修复
• 正在尝试有限范围的修复
• 已创建草稿拉取请求
• 修复未能合并

优先使用已配置的 Cursor Slack 操作。仅当用户为某项特定的缺失能力（例如编辑这条状态消息）配置了 BENNY_SLACK_BOT_TOKEN 时，才使用该令牌。绝不要向工作线程公开令牌。

如果未配置运维频道，请在自动化运行输出中记录详细状态。不要改为在源频道发布根消息。

5. 加载并检查控制适配器

读取 references/control-adapter.md 和已完成的映射文件 control.feature_map_path，然后调用 control.skill_name 指定的技能。

找到与报告所述用户路径匹配的功能映射部分。在操作应用前先阅读该部分。如果没有任何部分涵盖此功能，请将运行标记为已阻塞，不要自行编造路径或选择器。

必须具备以下全部七项能力：

1. 启动已配置的目标应用和测试环境。
2. 导航至映射的功能并测试其文档所述状态。
3. 通过点击、输入、按键、滚动、拖动、调整大小或导航来操作真实 UI。
4. 在不修改状态的情况下检查状态。
5. 截取屏幕截图。
6. 开始和停止屏幕录制。
7. 清理进程、会话、配置文件和临时数据。

如果适配器不存在，或缺少任何必需能力，请将运维状态标记为已阻塞并停止。不要把屏幕截图、单元测试、状态修改或源码阅读伪装成 UI 复现。

6. 研究报告

阅读完整的源讨论串和跟踪器问题（如果存在）。

收集以下信息：

• 精确的操作路径
• 预期行为
• 实际观察到的行为
• 预期行为与实际行为出现分歧时的关键状态
• 发生频率
• 版本、环境和平台
• 附件和错误特征
• 候选代码区域

检查截图和视频。必要时可并行使用只读工作线程，检查代码历史、测试思路、影响范围映射和媒体内容。每个工作线程都应接到范围明确的问题，并明确禁止其写入 Slack。

使用 pstack 的 how 技能，追踪该操作在仓库中的执行过程。使用 why 技能调查回归历史和防御性代码。提出相互竞争的原因假设，并找出能够区分这些假设的证据。

7. 复现

通过控制适配器启动目标应用。

操作前，确认应用、工作区、账户、数据集和功能状态均正确。使用稳定的应用标记。不要仅凭窗口顺序或熟悉的标题进行判断。

通过真实的 UI 操作，按报告中的路径进行操作。

在确认已复现前：

1. 说明正确的最终状态。
2. 说明异常的最终状态。
3. 到达二者出现差异的节点。
4. 观察异常状态。
5. 重置足够的状态，确保第二次尝试独立进行。
6. 重复相同路径，再次观察到相同的异常状态。
7. 尽可能交叉核对实际状态值。

使用配置的复现预算。如果在预算内未复现症状，请报告明确的 Could not reproduce 结果。如果环境无法提供所需能力，请报告 Blocked 并说明缺少什么。

预期中的对话框、加载状态或设置步骤不属于 Bug。请捕获能够区分正常行为与异常行为的最终状态。

8. 捕获并审查证据

成功复现后：

• 记录触发症状的完整路径。
• 截取异常最终状态的屏幕截图。
• 保存简短说明，写明确切步骤和观察到的状态。
• 将产物保存在配置的临时产物目录中。

请只读媒体审查员回答一个问题：证据是否清楚显示了具有判别力的异常状态？

如果答案为否或不确定，则不能确认复现。请捕获更好的证据，或使用 Could not reproduce。

仅在已配置时，才在运维讨论串中发布详细证据。源讨论串中的更新应保持简洁。

9. 报告复现结果

先更新运维状态。

对于 Could not reproduce 或 Blocked，不要在源讨论串中发布任何内容。结果由运维讨论串或运行输出记录。

对于已确认的复现，先运行源预检，然后最多发布一条未经提示的源讨论串回复：

• 说明问题已复现。
• 如果存在运维证据讨论串，提供其链接。
• 最多列出 3 条简短发现。
• 如果存在跟踪问题，提供其链接。
• 默认不要提醒负责人。

只有在已配置的 Slack 操作能将证据保留在同一个源讨论串内，且组织的保留政策允许时，才附上证据。

等待配置的异议期限。如果有人指出设置或解读有误，请更正一次复现。在异议期限结束且无人提出有效异议之前，不要开始修复阶段。

10. 验证现有修复

存在修复产物时，请按照 references/verify-existing-fix.md 操作。

验证必须证明基线版本会出现该症状，而修补后的构建不会出现该症状。两条路径都必须通过真实 UI 各执行两次。

不要修改现有修复、添加冲突补丁或创建替代拉取请求。

11. 评估范围明确的修复

仅当以下条件全部满足时才尝试修复：

• 结果是明确确认的复现。
• 媒体审查已确认异常最终状态。
• 未发现现有修复产物。
• 异议期限内无人认领该修复。
• 运行时证据已确定根本原因。
• 可能的更改符合配置的修复预算和仓库范围。
• 控制适配器能够运行基线版本和修补后的构建。

如果有任何条件不满足，请保留复现报告并停止，不要创建拉取请求。

通过关卡后，将运维状态更新为 Attempting bounded fix。

12. 定位根因并实施修复

协调者负责所有 Slack 帖子、最终差异审查、提交和拉取请求。

只读工作者可以：

• 跟踪代码和历史记录
• 提出测试建议
• 梳理影响范围
• 审查差异
• 审查媒体

他们不得编辑、执行外部写入、发布状态或负责修复。

只有在工具隔离能移除该工作者的 Slack 凭据和所有 Slack 写入操作时，才可以在此阶段委派范围严格限定的代码编辑。提示词仍必须明确禁止 Slack 写入。协调者负责审查编辑内容，并运行或验证所需测试。如果无法确定工具隔离是否有效，则由协调者自行编辑。

通过运行时证据确认机制。编辑前排除其他竞争性假设。

以有充分依据的最小改动修复根因。

• 如果有成本低廉的本地测试目标，请调用 pstack 的 tdd 技能，并在修复前编写失败测试。
• 如果该路径成本高、情况不明确或高度依赖集成，请说明跳过 TDD 的原因。
• 不要夹带无关清理。
• 如果改动超出配置的工作量或风险预算，请停止。

13. 证明修复有效

保留原始基线证据。

在打过补丁的构建版本上：

1. 执行相同的真实 UI 路径。
2. 重复两次。
3. 证明故障状态已消失。
4. 证明预期状态已取而代之。
5. 捕获修复后的录屏和截图。
6. 交叉核对与基线相同的真实状态值。

编译、单元测试、代码审查或看似合理的差异都不能作为修复后的证据。

先运行有针对性的测试，然后对改动行为的影响范围进行冒烟测试。覆盖改动可能影响的相邻状态、输入、权限、平台和失败路径。如果仍有回归问题，请停止，不要创建拉取请求。

14. 创建草稿拉取请求

只有在完成修复前后的验证后，才能：

• 审查最终差异，排除无关改动和机密信息。
• 运行仓库要求的检查。
• 如果仓库工作流允许，则按顺序创建小型提交。
• 创建草稿拉取请求。切勿通过此工作流合并或部署。
• 使用跟踪器支持的拉取请求语法，关联配置的跟踪器问题。
• 使用配置的公开 URL 格式，通常为 https://github.com/{owner}/{repo}/pull/{number}。
• 附上复现步骤、根因、测试结果、修复前后的证据以及影响范围检查结果。
• 使用 pstack 的 unslop 技能处理拉取请求文本和所有 Slack 更新。

如果创建拉取请求失败，不要声称已成功。将提交或分支状态保留在运行输出中，并将操作状态标记为 Fix did not land。

成功后，将操作状态标记为 Draft pull request opened，并在操作线程中发布一条简短回复，附上拉取请求链接。不要在源频道新建主帖或主动发布回复。

15. 后续跟进与清理

在一个后续跟进时段内，留意配置的操作线程。

• 根据已收集的证据回答直接问题。
• 如果具体问题导致设置失效，则进行一次明确的修正，并重新运行一次复现。
• 不要介入人工协调或题外闲聊。
• 收到停止要求时立即停止。

始终调用控制适配器的清理功能。仅在配置的保留政策允许的时限内保留工件。