test-completed-plan 是构建流程的测试阶段。它主要在 execute-plan 冻结计划并写好规格的 Post-ship verification 清单后运行，任务是把其中人工把关的 AC 行通过实际操作运行中的应用，得出真实通过/失败结论，并只勾选有证据支持的项。
用途：当 execute-plan 已交付规格，且 ### Post-ship verification 块存在待验证的 - [ ] AC-NNN-XX: 步骤 → 预期结果时使用。它验证行为而非代码：不修 bug（确认的 P0/P1 交给 fix-verify-loop），不重算已在交付门确认的代码级 AC。也支持独立入口：无 execute-plan 交接时，把 plan.md 清单或临时行为检查列表当作输入，就地记录 PASS/FAIL；其余流程不变，仅省略规格勾选与 Testing findings 块。
输入：规格清单 meta/specs/NNN-*/spec.md → ## Completion record → ### Post-ship verification；仓库配置 meta/workflows/automated-testing/automated-testing-instructions.md 提供具体值（如何启动应用、认证、日志、数据库等），技能只携带流程。
协议步骤：Step 0 解析仓库配置，缺失时向用户询问并可选生成配置；Step 1 按 AC 需要的最小模态分类（Tier 1 前端/单元、Tier 2 真实认证应用、Tier 3 日志/数据库）；Step 1.5 仅对需要的层启动应用；Step 2 按认证阶梯选最省的一级；Step 3 逐条验证并记录一手证据；Step 4 安全勾选（判断类 AC 需 verifier 代理确认，离散状态可自行勾选），维护 Testing findings 块；Step 5 路由 bug，先排除环境问题，合同破坏交用户协调；Step 6 强制清理临时插桩、浏览器会话与凭证；Step 7 按固定格式报告；Step 8 将本次学到的仓库特定事实经用户批准后写入配套配置。
限制：不修代码；Tier 2 无法读取跨域 iframe 的请求体，需借助配置声明的临时日志插桩；所有产物写入会话暂存区，绝不提交认证状态或令牌；判定依赖本运行捕获的证据，不得从先前代码级结果推断通过，需逐行精确编辑而非整块正则替换。