在Slack中复现并修复已分诊Bug：从真实UI复现到有前后…

当Slack线程中出现可信分诊标记（bug/performance）时，通过配置好的应用控制适配器在真实UI中复现问题、验证已有修复，并在拿到前后对比证据后开一个范围受限的草稿PR。

适用场景

解决思路

1. 等待源线程中出现可信的分诊标记，再通过目标应用的真实UI复现确切症状；若已有修复则先验证；只有在确认复现后才尝试受限修复。
2. 加载自动化提供的外部Benny配置；若配置、所需动作、控制适配器或已完成的feature map缺失，则fail closed。
3. 冻结源频道与根线程坐标：要求触发频道等于配置的源频道；将`SOURCE_THREAD_TS`设为`trigger.thread_ts`（若存在），否则用`trigger.ts`；要求其非空；把`SOURCE_CHANNEL_ID`和`SOURCE_THREAD_TS`存为不可变值；读取源线程并验证其根消息坐标一致；获取源permalink。绝不用回复、操作或状态消息的时间戳替换这些值。
4. 每次在源频道发帖前做preflight：按不可变坐标读取线程，确认父消息存在、未删除且仍属于源频道；只用`channel=SOURCE_CHANNEL_ID`和`thread_ts=SOURCE_THREAD_TS`发送；再次读取线程并确认新消息是回复。任一检查失败就不发帖，绝不在根消息或备用频道重试。
5. 遵守硬性安全规则：绝不在源频道发根消息；协调者是唯一的Slack发帖者；委派的分析worker只读并只返回发现或媒体说明；修复阶段的代码worker仅在其环境可证明不含Slack凭证和所有Slack写操作时才可编辑，否则由协调者编辑；每个子prompt必须显式禁止`SendSlackMessage`、`PostToSlack`、`chat.postMessage`及所有其他Slack写操作；绝不把Slack token、发帖指令、发帖用源坐标或对外汇报权限交给子worker；若子worker需要Slack写权限才能运行，就不要启动它；工具机器人只是证据来源，除非有人明确把修复委派给它，否则不拥有修复。
6. 等待分诊契约：在源线程中按配置的verdict预算观察，等待期间保持沉默。仅当verdict作者匹配`slack.triage_identity_user_id`、是`SOURCE_THREAD_TS`下的回复、且恰好包含一个配置标记时才接受。公开标记形式如`[benny:bug]`、`[benny:bug] tracker=https://tracker.example/issue/123`、`[benny:performance]`、`[benny:performance] tracker=...`、`[benny:other]`。仅对`bug`或`performance`继续，并捕获可选tracker URL；对`other`、缺失verdict、不可信作者、冲突标记或超时则静默停止。
7. 应用归属与修复产物门禁：开始工作前立即重读线程。当有人明确认领修复、给出具体实现计划，或要求另一个agent实现、打补丁、修复或开PR时停止。不要把机器人总结证据、工具查日志或工单、有人让机器人诊断/解释/检查/复现、或机器人只发原因假设当作修复归属；判断的是被请求的动作，而不是是否有机器人。若存在开放PR或已合并commit可能修复此报告，切换到`references/verify-existing-fix.md`；产物可来自线程、tracker issue、仓库历史或PR搜索；没有commit或PR的声明不算修复产物。若有人拥有工作但尚未产出产物，停止，不要与其竞争。
8. 可选地开一个operations线程：若配置了`slack.operations_channel_id`，协调者可在那里创建一条根状态消息，这是复现工作流中唯一允许的根帖。把其坐标存为`OPERATIONS_CHANNEL_ID`和`OPERATIONS_THREAD_TS`，绝不与源坐标混淆。使用配置的纯Unicode状态字符串，保持简短：Reproducing、Could not reproduce、Blocked、Reproduced、Verifying existing fix、Attempting bounded fix、Draft pull request opened、Fix did not land。优先使用配置的Cursor Slack动作；仅当用户为某个狭窄缺失能力（如编辑这一条状态消息）配置了`BENNY_SLACK_BOT_TOKEN`时才使用它，绝不把token暴露给worker。若未配置operations频道，把详细状态留在自动化运行输出中，不要用源频道根消息替代。
9. 加载并检查控制适配器：读取`references/control-adapter.md`和`control.feature_map_path`处的已完成map，然后调用`control.skill_name`指定的skill。找到与报告的用户路径匹配的feature-map章节，驱动应用前先阅读；若无章节覆盖该功能，标记运行blocked，而不是发明路径或选择器。要求全部七项能力：启动配置的目标应用和测试环境；导航映射功能并演练其文档化状态；用点击、输入、按键、滚动、拖拽、调整大小或导航驱动真实UI；在不改变状态的前提下检查状态；截屏；开始和停止屏幕录制；清理进程、会话、profile和临时数据。若适配器缺失或任一必需能力缺失，把operations状态标为blocked并停止；不要把截图、单元测试、状态变更或读源码假装成UI复现。
10. 研究报告：读取完整源线程和tracker issue（若有）。收集确切动作路径、期望行为、观察到的行为、二者分歧的判别状态、频率、版本/环境/平台、附件与错误签名、候选代码区域。查看截图和视频。必要时用只读并行worker做代码历史、测试想法、影响范围映射和媒体审查；每个worker只拿一个狭窄问题，并附带Slack写禁令。用pstack的`how` skill沿仓库追踪动作，用`why`查回归历史和防御性代码。形成相互竞争的原因假设，并找出能区分它们的证据。
11. 复现：通过控制适配器启动目标应用。行动前确认正确的应用、工作区、账号、数据集和功能状态；使用稳定的应用标记，不要只依赖窗口顺序或熟悉的标题。用真实UI动作走报告路径。在称为已复现前：命名正确的最终状态；命名损坏的最终状态；到达二者分歧点；观察到损坏状态；重置足够状态使第二次尝试独立；重复同一路径并再次观察到相同损坏状态；尽可能交叉核对真实状态值。期望的对话框、加载状态或设置步骤不是bug；捕获能区分正确与损坏行为的最终状态。使用配置的复现预算；若预算内症状未复现，报告干净的`Could not reproduce`结果；若环境无法提供所需能力，报告`Blocked`并说明缺失内容。
12. 捕获并审查证据：对成功复现，记录穿过症状的完整路径；截取损坏最终状态的截图；保存含确切步骤和观察状态的简短说明；把产物放在配置的临时产物目录。让只读媒体审查者回答一个问题：证据是否可见地展示了判别性的损坏状态？若答案是否定或不确定，则复现未确认；捕获更好证据或改用`Could not reproduce`。仅在配置了operations线程时在那里发详细证据；源更新保持简洁。
13. 报告复现结果：先更新operations状态。对`Could not reproduce`或`Blocked`，在源线程不发任何内容，由operations线程或运行输出承载结果。对已确认复现，运行源preflight并最多发一条非提示性源回复：说明问题已复现；链接operations证据线程（若有）；最多包含三条简短发现；链接tracker issue（若有）；默认不@负责人。仅当配置的Slack动作能把证据保留在同一源线程内且组织保留策略允许时才附证据。等待配置的驳回窗口；若有人表明设置或解释有误，纠正复现一次；在窗口关闭且无有效驳回前不要开始修复阶段。
14. 验证已有修复：当存在修复产物时，遵循`references/verify-existing-fix.md`。验证必须展示基线构建上有症状、补丁构建上无症状，两条路径都通过真实UI跑两次。不要编辑已有修复、添加竞争补丁或开替代PR。
15. 限定受限修复的资格：仅当以下全部成立时才尝试修复：结果是干净的已确认复现；媒体审查确认了损坏最终状态；未出现已有修复产物；驳回窗口内无人认领修复；运行时证据识别出根因；可能的改动符合配置的修复预算和仓库范围；控制适配器能同时运行基线和补丁构建。任一条件失败就保留复现报告并停止，不开PR。门禁通过时，把operations状态更新为`Attempting bounded fix`。
16. 根因分析与实现：协调者拥有所有Slack发帖、最终diff审查、commit和PR。只读worker可追踪代码和历史、提出测试、映射影响范围、审查diff、审查媒体；它们不编辑、不执行外部写、不发状态、不拥有修复。仅当工具隔离从该worker移除Slack凭证和所有Slack写操作时，才可在此阶段委派范围极小的代码编辑；其prompt仍须携带显式Slack写禁令。协调者审查编辑并运行或验证所需测试；若工具隔离不确定，就把编辑留在协调者。用运行时证据确认机制，编辑前排除竞争假设。用最小合理改动修复根因：当有便宜的本地测试目标时调用pstack的`tdd` skill，先写失败测试再修复；当路径昂贵、不清晰或集成重时说明为何跳过TDD；不做无关清理；若改动超出配置的努力或风险预算就停止。
17. 证明修复：保留原始基线证据。在补丁构建上：运行同一真实UI路径；重复两次；展示损坏状态已消失；展示期望状态取而代之；捕获after录制和截图；交叉核对与基线相同的真实状态值。编译、单元测试、代码审查或看似合理的diff都不是after证据。先跑聚焦测试，再对改动行为周边的影响范围做smoke测试，覆盖可能受影响的邻近状态、输入、权限、平台和失败路径；若仍有回归就停止，不开PR。
18. 开草稿PR：仅在拿到前后证明后：审查最终diff是否有无关改动和密钥；运行仓库要求的检查；仓库工作流允许时创建小的有序commit；开草稿PR，绝不从此工作流合并或部署；用tracker支持的PR语法链接配置的tracker issue；使用配置的公开URL形式，通常为`https://github.com/{owner}/{repo}/pull/{number}`；包含复现步骤、根因、测试结果、前后证据和影响范围检查；把PR文本和所有Slack更新过一遍pstack的`unslop` skill。若PR创建失败，不要声称成功；把commit或分支状态留在运行输出中，并把operations状态标为`Fix did not land`。成功时把operations状态标为`Draft pull request opened`，并在operations线程发一条含PR链接的简洁回复；不要创建第二个源频道根消息或非提示性源回复。
19. 后续与清理：在配置的operations线程中观察一个后续窗口。用已收集的证据回答直接问题；当某个具体纠正使设置失效时，应用该纠正并重跑复现一次；不参与人类协调和闲聊；被要求停止时停止。始终调用控制适配器的清理能力；产物只按配置的保留策略保留。

适用边界 · 注意事项

• 仅适用于配置好的Benny复现自动化环境；缺少配置、所需动作、控制适配器或已完成的feature map时应fail closed。
• 当有人已明确认领修复、给出具体实现计划，或已有开放PR/已合并commit可能修复该报告时，不要自行编写修复。
• 当控制适配器缺失或七项能力中任一缺失时，不要继续，也不要把截图、单元测试、状态变更或读源码当作UI复现。