OpenWork 红测诊断实战：以证据为准的失败分类与根因定位工作流

OpenWork 红测诊断实战以证据为准的失败分类与根因定位工作流【免费下载链接】openworkThe open-source alternative to Claude Cowork (powered by opencode)项目地址: https://gitcode.com/GitHub_Trending/ope/openwork在 OpenWork 仓库中每当 CI 变红、typecheck 失败、spec 超时或出现疑似 flaky 用例时.opencode/skills/diagnose-a-red-run/SKILL.md定义了一套先分类、后动码的标准化诊断流程先用干净对照组验证失败是否早已存在再按失败特征签名错误码、超时转储、认证 403 等快速缩小根因最后通过环境取证排除僵尸进程与泄漏状态。读完本文你将掌握一套可复现的红色运行red run处置方法能够在改动任何代码之前对是否 pre-existing、是否环境相关、是否产品歧义、是否会话老化做出有证据支撑的判断并正确发布红色测试证据。为什么需要先诊断后修改OpenWork 的测试体系将所有可执行覆盖放在evals/specs/**/*.test.ts测试通过openwork/testkit驱动 Electron、Den 或其他应用表面.e2e.test.ts。evals/README.md 给出了官方推荐的铺就路径paved pathwrite-a-spec—— 编写 specrun-tests—— 运行测试diagnose-a-red-run—— 运行失败时先诊断publish-evidence—— 发布既有证据并声明 PR 结论也就是说diagnose-a-red-run是整个工作流中失败发生时的第一道闸门。它的核心理念是在修改代码或宣布这是早已存在的问题之前必须先完成证据采集与失败分类。从记忆或一个被改动过的检出modified checkout出发永远不足以判定某个失败是 pre-existing——这是该技能反复强调的纪律。技能本身通过 opencode 的 skills 机制加载其 frontmatter 声明为测试红了、typecheck 失败、CI 任务失败、flaky、超时、以及这个是不是早就坏了都用它来在改动代码之前对任何失败进行检查进行分类。第一步捕获分支失败锁定可操作证据诊断的第一步不是猜测而是把失败现场钉下来。技能要求记录以下信息确切的命令复现该检查所运行的完整 CLI 命令commit SHA运行所基于的提交退出码进程的退出状态通过/失败/跳过计数测试结果的完整统计而不是一句红了首个可操作的失败必须逐字引用quote第一条 actionable failure而不是用你自己的话概括掉do not summarize it away。在 run-tests 技能中同样强调记录确切的命令、退出码与通过/失败/跳过计数将每个 skip 报告为skipped — needs: X绝不能把它当成通过。这正是把失败现场数据化的同一原则。随后对检查类型进行分类它是testkit spec、单元测试套件、typecheck、构建、lint还是CI 任务不同类型的失败对应不同的后续路径——例如单元/类型/CI-only 的失败要求先检查第一个失败任务并在本地运行其确切命令之后才扩大调查范围。第二步运行干净对照组才能判定早已存在技能给出了硬性规定永远不要凭记忆或从被改动过的检出中宣布某个失败是 pre-existing。标准做法是用 git worktree 拉取一个干净的origin/dev控制组git fetch origin dev git worktree add /tmp/openwork-dev-control --detach origin/dev # In that clean worktree, prepare the same prerequisites and run the exact command. git worktree remove /tmp/openwork-dev-control关键约束包括等价性工具版本、环境、服务、flags 与 secrets 都必须与失败现场保持一致否则对照组没有意义引用对照组结果像引用失败本身一样引用控制组的确切命令、origin/dev的 SHA、退出码、计数以及匹配的失败文本分类标准只有当干净对照组复现出同样的失败时才能把失败归类为pre-existing否则归类为introduced本次改动引入、environment-specific环境特有或unresolved未解决关于 flaky 的纪律一个无法复现的控制组不能作为 flaky 的证据。要用 flaky 这个标签必须两侧都重复运行repeat both sides之后才能下结论。这一规则与仓库的提交纪律相呼应publish-evidence 同样强调测试运行绑定到 commit SHA历史重写rebase、cherry-pick后必须重跑并重新发布。证据必须绑定到确切的提交这是 OpenWork 测试证据体系的一贯原则。第三步按特征签名分类失败技能为常见失败模式给出了一组签名 → 动作的映射这是整个技能中实战价值最高的部分单元 / 类型 / CI-only 失败检查第一个失败的 job并在本地运行它的确切命令之后才扩大调查范围。许多 CI-only 失败在本地复现时立即暴露为环境或顺序问题而不是代码问题。视觉模型对相同像素的分歧当同一像素的视觉判断出现分歧vision disagreement on identical pixels时问题往往出在claim 的措辞或产品歧义上——不是测试基础设施坏了。处理方式让产品行为变得无歧义或让 claim 变得事实化make the product unambiguous or make the claim factual。在 OpenWork 的 E2E 体系中视觉判断默认被推迟需要显式添加--with-llm-vision才能内联判断见 evals/README.md因此同一证据、两个判断的场景确实存在。带 On-screen dump 的超时超时并伴随 on-screen dump 时先读 dump。它直接指明当时页面/会话处于什么状态例如 dump 中出现的/session可能暴露一个 steer-back拉回竞态。dump 是现场证据比猜测更可靠。认证403 INVALID_ORIGIN此类失败指向Den 的可信来源trusted origins配置。检查 Den 的 trusted origins 是否与实际运行来源一致而不是急着改测试。Authorize URL 指向真实 provider如果授权 URL 指向了真实的第三方 provider说明Den 在没有 mock 环境的情况下启动了。这与 OpenWork 的 eval 体系密切相关evals是一个独立的 pnpm workspace测试依赖 witness确定性的 provider 替身记录它看到的一切见 evals/README.md 术语表与 mock 环境来保证确定性。Den 一旦绕过 mock 环境启动授权流程就会打到真实 provider。Teardown 阶段403 fresh_auth_required这个签名说明**会话老化session aged**了。技能的提示是一个freshSession重试机制存在。这一点在仓库源码中得到直接印证evals/packages/behaviors/src/den.ts 中定义/** Refresh an eval session using the credentials captured by signIn. */ export async function freshSession(session: DenSession): PromiseDenSession { return signIn(session, { email: session.email, password: session.password }); }freshSession通过signIn重新调用/api/auth/sign-in/email来刷新会话。reauth-popup.e2e.test.ts则提供了该签名的真实测试证据在 evals/specs/reauth-popup.e2e.test.ts 中会话老化后world.ageSession(20)对 access 授予、skill 删除与 MCP 创建的请求都返回{ error: reauth, reason: fresh_auth_required }而内容编辑窗口在 20 分钟时仍然可用——这表明 Den 对安全敏感操作与内容编辑使用了不同的会话新鲜度要求。当你看到 teardown 阶段的fresh_auth_required时优先考虑会话是否已经老化超过阈值该路径是否已接入freshSession重试第四步环境取证Environment Forensics当失败与环境状态相关时技能给出了四条经过实战检验的取证经验按端口杀进程而不是按进程名tsx watch可能会留下孤儿的 Node 子进程这个孤儿占着端口而/health却仍然撒谎返回正常。因此判断存活要基于端口占用而不是进程名。EADDRINUSE health 200 僵尸存活日志中出现EADDRINUSE而 health 检查却返回 200说明有一个僵尸进程幸存了下来。这是表面健康、实际被旧进程劫持的典型信号。Electron 僵尸会从根进程重生Electron 的僵尸进程可以从根进程重新拉起所以要杀死整个进程组而不是单个 PID。泄漏状态会污染组织泄漏的状态leftover connectors 等会污染 organizations在两次运行之间删除遗留的 connectors否则测试结果会被上一次运行残留的状态污染。与之配套的还有 evals/README.md 中的资源所有权规则脚本的AsyncDisposableStack拥有脚本创建的资源并按逆序释放附加attached或共享资源则只释放脚本自己新增的部分如本地端口转发或为该次运行创建的 org不会停止或删除共享 substrate。规则一句话概括stack 拥有脚本创建的东西而不是脚本附加到的东西。理解这条规则才能判断 teardown 阶段到底应该清理什么。第五步testkit 失败先读未验证产物红色证据也要发布技能最后指出对于 testkit 失败在触碰代码之前先读该次测试运行最后一批未验证的产物last unvalidated artifacts——它们往往已经揭示了失败状态。如果需要用publish-evidence发布有价值的红色测试证据注意发布证据是人工审计材料不等于通过的判定it remains human audit, not a passing verdict。publish-evidence 将这一点落实为完整的发布协议结论三元组Passed每个 claim 都有可观察断言、Failed至少一个断言推翻了预期、Incomplete需求、工具或证据缺失skip 永远是Incomplete绝不等于Passed发布命令对当前 PR head 的完整证据集用pnpm evals:e2e --publish --pr n --all或显式选择运行--test-run dir|name发布≠通过publisher 成功退出只表示已发布PR 结论必须从记录的结果与缺口gaps推导Failed 和 Incomplete 的报告同样是有效证据可以发布红色磁带red tapes有效--force只用于刻意发布历史性或红色测试证据输出会被标注红色磁带是合法的人工验证产物在它们能解释Failed或Incomplete结论时应予以发布。也就是说一条红色运行不是坏记录而是诊断链上的一环——只要它被准确记录、干净对照组验证、按签名归类并用 publish-evidence 规范发布它就是有价值的审计证据。配套实操本地复现所需的最小环境诊断流程中运行确切命令依赖可用的本地测试环境。run-tests 给出了最小准备步骤同样适用于红测诊断时的本地复现pnpm evals:e2e slug pnpm evals:pr specs/name.test.ts本地 fallback 需要先构建工作区依赖并准备数据库pnpm --filter openwork/types build pnpm --filter openwork-ee/den-db build pnpm --filter openwork/email build pnpm dev:den:mysql注意事项本地server()需要 MySQL 运行在127.0.0.1:3306不先构建上述工作区依赖den-api 的 import 会失败——这本身就是一类典型的环境前置条件失败如果检出路径包含空格需在 E2E 前设置OPENWORK_EVAL_SURFACES_DIR指向无空格路径node-gyp 与 electron-rebuild 依赖它迭代期间可复用 warm DenOPENWORK_EVAL_DEN_API_URL但在声明Passed之前必须移除复用覆盖并在同一提交上通过server()冷启动secrets 用infisical run --silent --注入绝不打印或回显值。E2E CLI 会打印placement: daytona|local (reason)说明放置原因诊断时请把这一行复制进报告——它本身就是环境取证的一部分。--local与--daytona可覆盖继承的放置而--den url可复用 Den 实例见 evals/README.md。诊断原则小结把diagnose-a-red-run的完整流程压缩成可执行的检查单钉现场记录命令、SHA、退出码、通过/失败/跳过计数逐字引用首个可操作失败分类检查类型testkit spec / 单元 / typecheck / build / lint / CI job跑干净对照组git worktree检出origin/dev保持前置条件等价同侧失败才判pre-existing非复现 ≠ flaky两侧重复后才可用该标签按签名归因像素分歧看 claim 措辞超时读 on-screen dumpINVALID_ORIGIN查 Den trusted origins真实 provider 说明缺 mock 环境fresh_auth_required说明会话老化freshSession可重试环境取证按端口杀进程警惕EADDRINUSE health 200 的僵尸Electron 要杀进程组运行间清理遗留 connectors证据优先testkit 失败先读最后未验证产物红色证据用 publish-evidence 规范发布发布是审计而非通过判定。这套工作流的最终目的是让红测处置从碰运气的猜测变成可审计、可复现、可引用的证据链——每一次红色运行都在为仓库的测试体系积累有效的人类审计材料。【免费下载链接】openworkThe open-source alternative to Claude Cowork (powered by opencode)项目地址: https://gitcode.com/GitHub_Trending/ope/openwork创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考