diff --git a/AGENTS.md b/AGENTS.md index 8e152fd..252192f 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -5,7 +5,7 @@ - 开始任何实质性修改前，先阅读 `docs/cynos-default-project-layout.md`。 - 理解项目时读取 `docs/PROJECT.md`（存在时）；处理需求时读取对应的 `docs/changes//intent.md`、`spec.md` 和 `plan.md`（存在时）。 - 已发布 MVP 基线工件位于 `docs/changes/luowang-harness-mvp/`。 -- 当前增量变更是 `docs/changes/luowang-v07-production-closure/`，用于补齐 v0.7 Role Skills、固定分支请求、数据清理、实时进度、历史 Run 和真实联合验收；处理这些主题时先读该目录，冲突处以其 Spec 为准。 +- 当前增量变更是 `docs/changes/luowang-v07-production-closure/`，用于补齐 v0.7 Built-in Role Instructions（内置角色指令）、固定分支请求、数据清理、实时进度、历史 Run 和真实联合验收；罗网不使用 Pi Skills，并保持 Main/Runner/Reviewer 三组 Agent 配置、正常 Run 四个隔离 Session。处理这些主题时先读该目录，冲突处以其 Spec 为准。 - 技术栈、产品边界和验收要求以对应需求 `spec.md` 为准，不在本文件重复维护。 ## 仓库与分支 diff --git a/docs/changes/luowang-v07-production-closure/intent.md b/docs/changes/luowang-v07-production-closure/intent.md index 2d4b9e6..9a1d1c6 100644 --- a/docs/changes/luowang-v07-production-closure/intent.md +++ b/docs/changes/luowang-v07-production-closure/intent.md @@ -1,6 +1,6 @@ # 罗网 v0.7 生产闭环补齐 Intent -- 状态：Approved v0.1 +- 状态：Approved v0.2 - 关联规格：[spec.md](./spec.md) - 实现计划：[plan.md](./plan.md) - 上游基线：[罗网 Harness MVP](../luowang-harness-mvp/intent.md) @@ -8,15 +8,15 @@ ## 1. 为什么需要这个变更 -罗网 `v0.1.0` 已经实现主要框架，包括 Git/SQLite/OSS、固定 commit Run、Main → Runner → Reviewer → Main、场景维护、归档与 Issue、FIFO 队列、Playwright MCP、控制台和 Docker 部署。现有自动化测试也能使用本地仓库、样例应用和 test doubles 验证大量确定性规则。 +罗网 `v0.1.0` 已经实现主要框架，包括 Git/SQLite/OSS、固定 commit Run、Main · 规划 → Runner → Reviewer → Main · 最终汇总、场景维护、归档与 Issue、FIFO 队列、Playwright MCP、控制台和 Docker 部署。现有自动化测试也能使用本地仓库、样例应用和 test doubles 验证大量确定性规则。 但当前代码和发布说明把“本地 fixture 回归通过”表述成了“34 个 AC 全量验收完成”，而真实外部 smoke 仍为 blocked；同时，生产路径存在几项会阻止 v0.7 闭环成立的缺口： -1. 角色方法全部硬编码在 Orchestrator 长提示词中，同一内容还同时作为 system prompt 和用户消息发送；Pi 的 ambient Skills 虽被安全禁用，但罗网也没有版本化、按角色隔离的内置工作方法资源； +1. 角色方法全部硬编码在 Orchestrator 长提示词中，同一内容还同时作为 system prompt 和用户消息发送；Pi Skills 已被安全禁用，但罗网也没有版本化、按角色隔离的内置角色指令资源； 2. 用户指定 branch/tag/SHA 时，merge 和测试是两个独立动作，普通 Run API 还允许直接传任意 target，可能绕开固定 `scenario-testing` 分支； 3. 生产默认测试数据管理器只能登记数据，没有“Runner 已通过 UI/API 删除并确认”的路径；只要登记数据且没有注入测试适配器，Run 就会被强制 blocked； 4. 当前场景和执行进度只在 Run 创建时初始化为 `null`、`0/0`，真实 Runner 不会上报变化； -5. Main 只得到 Git 正式报告摘要和 GitHub Issues，无法查询 SQLite 中特殊 blocked、interrupted、场景 PR 和归档失败等详细历史 Run； +5. Main · 规划只得到 Git 正式报告摘要和 GitHub Issues，无法查询 SQLite 中特殊 blocked、interrupted、场景 PR 和归档失败等详细历史 Run； 6. Phase 9 默认验收使用 `FixtureSessionFactory` 和直接 Playwright，未走真实 `createAgentSession()` 模型工具循环，也没有完成真实 Provider + Pi + Playwright MCP + OSS + 非生产应用的联合证明； 7. README 对验收状态和本地原生依赖的说明不准确。 @@ -26,12 +26,12 @@ 完成本变更后，罗网应具备以下可观察结果： -1. Main Planning、Runner、Reviewer、Main Finalization 和初始化方法成为罗网自身版本化的内置 Role Skills，由应用按 Session 确定性加载并完整注入；目标仓库、宿主机和用户目录中的 Skills 仍不会被发现或执行； +1. Main · 规划、Runner、Reviewer、Main · 最终汇总和初始化方法成为罗网自身版本化的 Built-in Role Instructions（内置角色指令），由应用按 Session 确定性加载并完整注入；它们是发布物中的固定 Markdown 资源，不是 Pi Skills；目标仓库、宿主机和用户目录中的 Skills 仍不会被发现或执行； 2. 固定方法、安全边界、动态 Run 上下文和本次请求分层传递，不再重复注入同一长提示词；不同角色只看到自己需要的动态事实； 3. 人工 merge 请求进入现有 SQLite FIFO，在轮到它时完成 `merge --no-ff → non-force push → 固定新的 scenario-testing HEAD → Run`；普通人工测试不能直接绕开场景测试分支； 4. Runner 可以登记测试数据并通过 UI/API 删除，但 Runner 的清理声明不能直接变成完成事实；只有受控 adapter 独立核验，或 Reviewer 读取 Harness 管理的清理证据后确认，数据才视为已清理，任何未确认残留仍可靠地使结果 blocked； 5. 网站在真实执行中显示总场景数、已完成数、当前场景和脱敏活动，而不是只依赖 UI fixture； -6. Main 可以按需查询有限、只读、相关的历史 Run 摘要，包括未写入 Git 正式报告的本地事实； +6. Main · 规划可以按需查询有限、只读、相关的历史 Run 摘要；Main · 最终汇总只获得本次 confirmed Bugs 的 Issue create/link 所需摘要；Runner 和 Reviewer 均不获得历史查询工具； 7. 本地自动化验收与真实外部联合验收明确分层：本地通过不能冒充 live 通过，发布验收在任何必需外部证明 blocked 时必须失败； 8. 使用独立、可信、非生产测试项目完成真实 Provider、Pi Agent、Playwright MCP、OSS、GitHub、数据清理、归档、Issue 和进度闭环； 9. README 准确说明已实现、已本地验证、尚未 live 验证和本地构建前置条件； @@ -48,7 +48,7 @@ ### 系统 -- Agent Session/Prompt/Tool 组装； +- 三组 Agent 配置、四个隔离 Session、Prompt/Tool 组装； - SQLite 测试请求队列和 Repository Service； - Run Orchestrator、测试数据管理、Gateway 当前状态和 Run Store； - Phase 9 acceptance harness、CI 和 README； @@ -60,9 +60,10 @@ - 保留单实例、单租户、单目标仓库、单场景测试分支、单测试环境、单 active Run 和 FIFO； - 不引入多阶段 checkpoint、通用工作流引擎、发布 gate、多 worker、复杂 worktree 或新的长期状态文件； - 继续使用 `passed | failed | blocked`，不照搬其他项目的五状态、三轴结论或复杂聚合模型； -- 内置 Role Skills 只规定工作方法，所有读取、写入、Secret 和副作用权限继续由代码中的 custom tools、adapter 和路径校验强制执行； -- Pi ambient Skill、Prompt、Context 和宿主机/目标仓库资源发现保持关闭；不得为了读取 Role Skill 给 Agent 开放任意文件 `read`； -- Main 不获得测试账号；Reviewer 不获得测试账号、命令和 Git 写入；Runner 不获得 Git Token、模型 Key、OSS Secret、管理员密码或主密钥； +- 罗网始终只有 `agents.main`、`agents.runner`、`agents.reviewer` 三组 Agent 配置；正常 Run 创建 Main · 规划、Runner、Reviewer、Main · 最终汇总四个互相隔离的 Session，不增加 Planner/Finalizer 配置； +- 内置角色指令只规定工作方法，不提供权限；所有读取、写入、Secret 和副作用权限继续由代码中的 custom tools、Secret Store、adapter、writer、路径 allowlist 和 patch 校验强制执行； +- 保持 `noSkills=true`，不创建 `SKILL.md`、不使用 `skillsOverride`、不启用 Pi Skill 自动发现；ambient Prompt、Context 和宿主机/目标仓库资源发现也保持关闭；不得为了读取内置角色指令给 Agent 开放任意文件 `read`，也不得允许网站配置任意角色指令路径； +- Main · 规划和 Main · 最终汇总均不获得测试账号；Reviewer 不获得测试账号、命令和 Git 写入；Runner 不获得 Git Token、模型 Key、OSS Secret、管理员密码或主密钥； - 所有正式测试 target 必须是远端场景测试分支上的不可变 commit；merge 冲突不得由 Agent 修改产品代码解决； - 真实验收只连接操作者确认可信的仓库和非生产环境，使用合成数据和专用账号； - 凭据只通过进程环境、Docker Secret 或网站 Secret Store 提供，不写入 Git、需求文档、PR、Issue、测试报告或普通日志； @@ -104,7 +105,7 @@ 本变更成功不以“新增了多少文件或测试”为标准，而以以下事实同时成立为准： - 已知生产路径缺口均有用户可观察的修复和自动回归； -- 实际 Pi SDK Session 而非 FixtureSessionFactory 完成一次受控工具循环； +- 实际 Pi SDK Session 而非 FixtureSessionFactory 分别证明正常四 Session Run 和陌生项目初始化流程，覆盖模型消息、受控工具循环、Session 隔离与 dispose； - 真实联合 Run 在独立非生产项目上完成并可由 Run、commit、报告、截图、OSS object、PR/Issues 和清理结果复核； - 本地与 live 结果被准确区分，缺少任何 live 前置条件时明确 blocked 且不能发布； - 没有通过补复杂状态机、放宽安全边界或增加未来架构来“解决”问题。 diff --git a/docs/changes/luowang-v07-production-closure/plan.md b/docs/changes/luowang-v07-production-closure/plan.md index 3866f8e..a49e54f 100644 --- a/docs/changes/luowang-v07-production-closure/plan.md +++ b/docs/changes/luowang-v07-production-closure/plan.md @@ -1,6 +1,6 @@ # 罗网 v0.7 生产闭环补齐实施计划 -- 状态：Implementation Plan v0.1 +- 状态：Implementation Plan v0.2 - 关联 Intent：[intent.md](./intent.md) - 关联 Spec：[spec.md](./spec.md) - 上游计划：[罗网 Harness MVP Plan](../luowang-harness-mvp/plan.md) @@ -138,11 +138,11 @@ LUOWANG_LIVE_OSS_ACCESS_KEY_SECRET | 阶段 | 建议分支 | 独立闭环结果 | 主要 AC | |---|---|---|---| | Closure 0 | `fix/closure-truthful-status` | README 准确说明当前证明范围和本地依赖 | DOC-01、ACCEPT-01 部分 | -| Closure 1 | `feat/closure-role-skills` | 版本化 Role Skills 被按 Session 确定性注入且不开放 ambient 发现 | INSTR-01/02/03 | +| Closure 1 | `feat/closure-role-instructions` | 三组 Agent 配置创建四类隔离 Session，内置角色指令被确定性注入且不开放 Pi Skills/ambient 发现 | INSTR-01/02/03 | | Closure 2 | `fix/closure-merge-test-queue` | branch/tag/SHA 经同一 FIFO 合并并测试固定分支 HEAD | MERGE-01/02、TARGET-01 | | Closure 3 | `fix/closure-test-data` | Runner 能确认实际清理，残留可靠 blocked | DATA-01/02 | | Closure 4 | `fix/closure-live-progress` | 真实 Run 上报当前场景、总数和完成数 | ACTIVE-01 | -| Closure 5 | `feat/closure-run-history` | Main 可查询相关 SQLite/Recovery 历史摘要 | HISTORY-01 | +| Closure 5 | `feat/closure-run-history` | Main · 规划可查询相关历史，Main · 最终汇总只获本次 bug 摘要 | HISTORY-01 | | Closure 6 | `feat/closure-production-acceptance` | local 验收真实经过 Pi SDK，local/live/release 分层 | PI-01、ACCEPT-01/02 | | Closure 7 | `feat/closure-live-acceptance-release` | 使用人类提供资源完成 live 联合验收并发布 | LIVE-01/02、SECRET-01、RELEASE-01 | @@ -176,43 +176,50 @@ LUOWANG_LIVE_OSS_ACCESS_KEY_SECRET `AC-CLOSURE-DOC-01` 的状态/安装范围和 `AC-CLOSURE-ACCEPT-01` 的文案部分通过；公开文档不再把 blocked live 写成完成。 -## 7. Closure Phase 1：确定性内置 Role Skills +## 7. Closure Phase 1：确定性 Built-in Role Instructions ### 目标 -保留当前显式 Prompt 的安全和确定性，把工作方法从 Orchestrator 长字符串中抽离为版本化 Role Skills，并消除 system/user 重复注入和跨角色 Context 过宽。 +罗网不使用 Pi Skills。保留当前显式 Prompt 的安全和确定性，把固定工作方法从 Orchestrator 长字符串中抽离为版本化 Built-in Role Instructions（内置角色指令），同时明确“三个 Agent 配置、四个隔离 Session”，消除 system/user 重复注入和跨角色 Context 过宽。 ### 修改范围 -1. 新建 `resources/agent-roles/` 中 Spec §3 固定的六个 Markdown 资源； +1. 新建 `resources/agent-roles/` 中 Spec §3 固定的六个普通 Markdown 资源；不创建 `SKILL.md`，不采用 Pi Skill 格式； 2. 增加现有 Session owner 内的资源装载/构建边界： - 固定 allowlist； - 每个文件固定逻辑 ID 和格式版本；实际装载版本以 `逻辑 ID + 应用版本 + SHA-256` 标识； - 缺失/空文件失败； - 生产 build/Docker 必须携带资源； - 可输出逻辑 ID/hash 用于测试，但不记录内容或本地敏感路径； -3. `agent-session.ts` 继续关闭 ambient Skill/Prompt/Context/内置工具；不启用通用 `read`； -4. 重构 `orchestrator.ts` 的 prompt 组装： - - system prompt = common + 唯一角色 + 可选初始化 + 输出契约； - - user message = 角色裁剪后的 Run 上下文和本次任务； - - 不再把同一字符串传两次； -5. 把 opc-aicom 可吸收原则压缩进对应 Role Skill，不复制 suite/catalog/checkpoint/五状态/三轴/gate； -6. 维持全部 custom tool allowlist 和 writer 权限； -7. 为每个 Session 和初始化变体增加 prompt/resource 快照或结构断言。 +3. `agent-session.ts` 保持 `skills=[]`、`noSkills=true`、ambient Prompt/Context/内置工具关闭；不使用 `skillsOverride`，不启用通用 `read`，不允许网站配置角色指令路径； +4. 保持且只保持 `agents.main`、`agents.runner`、`agents.reviewer` 三组配置： + - Main Planning Session 和 Main Finalization Session 都使用同一 Main 模型/thinking 配置； + - 两者每次分别新建 Session，不共享完整对话； + - 不增加 planner/finalizer 模型字段、Provider 检查或配置 migration； +5. 重构 `orchestrator.ts` 的 Prompt 组装： + - system prompt = 角色身份 + common + 当前阶段内置角色指令 + 可选初始化规则 + 输出契约； + - user message = 当前任务 + 角色裁剪后的动态 Run 上下文； + - 不再把同一完整指令发送两次； +6. 把 Spec §3.6 的证据优先级、独立审核、偏差、清理和反模式写入对应内置角色指令；不引入 suite/catalog/checkpoint/五状态/三轴/gate； +7. 维持并分别断言四类 Session 的 custom tool、Secret、writer、路径和 patch 权限；指令内容不能授予权限； +8. 面向用户统一显示 `Main · 规划`、`Runner`、`Reviewer`、`Main · 最终汇总`，覆盖文档、网站当前执行页、活动记录和报告；内部 `main-a`/`main-b` 可以保留，不做数据迁移； +9. 为四类 Session、初始化附加规则和同角色多 Session 增加 prompt/resource 结构断言。 ### 专项验证 -- 在临时 target 仓库创建恶意 `.pi/skills`、`.agents/skills`、`AGENTS.md`，system prompt 中不存在其标记； -- 在临时 host agentDir 创建全局 Skill，仍不进入 Session； -- 分别创建 Main A、Runner、Reviewer、Main B，断言只包含自己的 Role Skill，不包含其他角色专属标记； -- 断言 user message 不含完整 Role Skill，Runner/Reviewer Context 不含历史 Issues/测试密码； -- 删除一个内置资源后，Session 创建明确失败且不回退； -- 断言工具名集合与修改前一致； -- 生产 build 和 Docker 内资源存在。 +- 在临时 target 仓库创建恶意 `.pi/skills`、`.agents/skills`、`AGENTS.md`、Prompt/Context 文件，Session 中不存在其标记； +- 在临时 host agentDir 和用户目录创建全局 Skill/Prompt/Context，仍不进入 Session； +- 断言未调用 `skillsOverride`，没有 `SKILL.md`，没有通用 `read`，网站没有任意角色指令路径字段； +- 分别创建 Main Planning、Runner、Reviewer、Main Finalization Session，只包含对应内置角色指令，不包含其他角色专属标记； +- 断言两个 Main Session 使用同一 `agents.main` 模型/thinking 配置，但 Session ID、对话和工具集合隔离；配置 schema 仍只有 Main、Runner、Reviewer； +- 初始化静态勘察/候选综合的多个 Main Planning Session 互不共享对话；运行时侦察/候选验证的多个 Runner Session 同样隔离； +- 断言 user message 不含完整角色指令，Runner/Reviewer Context 不含历史 Issues/测试密码； +- 删除一个内置资源后，Session 创建明确失败且不回退 Pi Skills 或 ambient 资源； +- 生产 build 和 Docker 内资源存在；网站、活动和报告只出现四个统一显示名称。 ### 退出条件 -`AC-CLOSURE-INSTR-01`、`AC-CLOSURE-INSTR-02`、`AC-CLOSURE-INSTR-03` 通过；角色行为测试保持，未扩大任一角色权限。 +`AC-CLOSURE-INSTR-01`、`AC-CLOSURE-INSTR-02`、`AC-CLOSURE-INSTR-03` 通过；三组配置、四类 Session 和角色行为测试保持，未扩大任一角色权限。 ## 8. Closure Phase 2：人工 merge 与测试进入同一 FIFO @@ -222,27 +229,50 @@ LUOWANG_LIVE_OSS_ACCESS_KEY_SECRET ### 修改范围 -1. 通过新 migration 为现有测试请求队列增加 request kind 和可选 `source_ref`，保持旧行可读取； +1. 通过新 migration 为现有测试请求队列增加 `request_kind`、`source_ref`、`prepared_merge_commit`、`resolved_target_commit`；后两个字段是请求幂等事实，不建立通用 checkpoint。严格实现 Spec §4.4 的旧行规则： + - terminal 行只读保留，不重新执行；有关联 Run 时从 Run Store 回填 resolved； + - 有 `run_id` 的 running/waiting_archive 只恢复既有 Run/归档；`waiting_archive` 缺少 `run_id` 时统一 failed，不重新排队； + - queued/running-without-run automatic 行迁为 `automatic-head`，调度时取新 HEAD； + - queued/running-without-run manual/api 且旧 target 为空时迁为 `manual-current-head`； + - queued/running-without-run manual/api 且旧 target 非空时明确 failed，不把旧 target 猜成 sourceRef 或 merge 授权； + - 旧 `target_ref` 只作历史兼容读取，新调度不使用； 2. 在 Queue/Automation owner 中实现 Spec §4 三类请求；自动请求仍只合并 queued automatic，人工请求永不合并； -3. 调度 `manual-merge-source` 时依次执行 fetch、ancestor check、`merge --no-ff`、non-force push、固定返回 HEAD、启动 Run； -4. 改造 `/api/repository/merge` 和网站合并入口为异步入队，返回 queue/request ID； -5. 普通 `/api/runs` 和网站 Run 表单移除任意 target 输入；非空旧字段明确 `400`； -6. 重测入口复用原请求说明但在调度时读取当前场景测试分支 HEAD； -7. Orchestrator 只接收调度层已经证明属于场景测试分支的固定 SHA；保留 checkout 后 SHA 一致性检查； -8. 增加 merge 后进程退出恢复、来源已包含、冲突、push 竞争和重复请求测试； -9. 更新 API/UI 文案，明确“已排队”而不是“已经合并”。 +3. 调度 `manual-merge-source` 时严格执行： + - fetch 并解析 source ref； + - 基于当时远端 `scenario-testing` HEAD 生成本地 `merge --no-ff` commit； + - push 前持久化 `prepared_merge_commit`； + - non-force push 同一 prepared commit； + - push 成功后持久化同值的 `resolved_target_commit`； + - 只使用 `resolved_target_commit` 创建或关联唯一 Run； +4. 恢复逻辑按已持久化事实分支： + - 只有 prepared：远端已包含则补写 resolved；未包含则只尝试 push 同一 commit，远端竞争时失败，不重做 merge； + - 已有 resolved：校验它位于远端场景分支历史，忽略后来新增 HEAD，创建或关联唯一 Run； + - 已有关联 Run：不再创建第二个； +5. 来源已是祖先时不生成 merge commit，把当时远端 HEAD 持久化为 prepared/resolved 后创建 Run； +6. 改造 `/api/repository/merge` 和网站合并入口为异步入队，返回 queue/request ID； +7. 普通 `/api/runs` 和网站 Run 表单移除任意 target 输入；非空旧字段明确 `400`； +8. 重测入口复用原请求说明但在调度时读取当前场景测试分支 HEAD； +9. Orchestrator 只接收调度层持久化且已证明发布到场景测试分支的 `resolved_target_commit`；保留 checkout 后 SHA 一致性检查； +10. 更新 API/UI 文案，明确“已排队”而不是“已经合并”。 ### 专项验证 -使用临时 bare remote： +使用临时 bare remote 和真实 Queue/Repository/Recovery 生产代码： +- 空库和 `v0.1.0` schema 都能迁移四个字段；migration 重复启动不重复改写； +- 分别构造 automatic/manual/api × queued/running-without-run/running-with-run/waiting_archive-with-run/waiting_archive-without-run/completed/failed/interrupted 旧行：断言 request kind、requeue/recovery/fail/只读行为与 Spec §4.4 表完全一致；`waiting_archive` 缺少 Run ID 必须 failed； +- 旧 manual/api 非空 target 不会写入 `source_ref`、不会 merge、不会创建 Run，错误提示要求通过 merge-source 重新提交； +- 旧 automatic 的 `target_ref` 不作为新 target，轮到时固定当时场景分支 HEAD；有关联旧 Run 的 resolved 只从已存 Run/Recovery target 回填； - 排队两个普通人工请求和一个 merge-source，按 FIFO 执行且不丢失； -- merge-source 产生 `--no-ff` merge commit、non-force push，Run target 等于远端新 HEAD； -- 来源已是祖先时不重复 merge，但创建新的人工 Run； -- merge 冲突、来源不存在、远端竞争时无 Run、无推进、工作树清理； -- merge 成功后模拟重启，恢复不重复 merge并最终创建一个 Run； -- `/api/runs` 任意 SHA/ref 返回 `400`； -- 普通人工和重测 target 为调度时远端场景分支 HEAD； +- merge-source 产生 `--no-ff` merge commit，且在 push 前数据库已有 `prepared_merge_commit`； +- push 成功后 `resolved_target_commit == prepared_merge_commit`，Run target 严格等于 resolved； +- 在 prepared 持久化后、push 前退出：恢复只 push 同一 prepared commit，不重新生成 merge； +- 在 push 后、resolved 持久化前退出：恢复从远端包含关系补写同一 resolved，不重复 merge； +- resolved 后、Run 创建前让场景分支再前进：恢复仍创建一个以旧 resolved 为 target 的 Run； +- Run 关联后重启：不创建第二个 Run； +- 来源已是祖先时不重复 merge，但持久化当时 HEAD 并创建新的人工 Run； +- merge 冲突、来源不存在、prepared 后远端竞争时无 Run、无推进、工作树清理； +- `/api/runs` 任意 SHA/ref 返回 `400`；普通人工和重测 target 为调度时远端场景分支 HEAD； - 自动合批行为和 last completed target 计算不回归。 ### 退出条件 @@ -261,13 +291,13 @@ LUOWANG_LIVE_OSS_ACCESS_KEY_SECRET 2. 增加 Runner 的 `submit_test_data_cleanup_claim`、`list_pending_test_data` custom tools：claim 必须引用当前 Run Evidence Store 中真实存在的证据 ID，只能进入待核验状态； 3. 为脱敏删除后 API 查询结果增加受控文本 evidence 保存/读取；沿用当前 Run 路径、大小、类型和 Secret 校验； 4. 增加 Reviewer 的 `verify_test_data_cleanup`：只有 Reviewer 已实际读取 claim 对应 evidence 后才能确认或拒绝，不能执行目标环境命令或访问账号； -5. 更新 Runner/Reviewer Role Skills： +5. 更新 Runner/Reviewer 内置角色指令： - 创建前取得 run-id prefix； - 创建后立即登记； - 场景结束通过 UI/API 删除； - 保存“删除后不存在”的脱敏截图/查询证据并提交 claim； - Reviewer 先读证据，再结构化确认或拒绝； -6. 调整 Run 收尾顺序：Runner 后 adapter 可先核验 pending，Reviewer 后做最终检查，再把未确认项作为 blocking reason 交给 Main B； +6. 调整 Run 收尾顺序：Runner 后 adapter 可先核验 pending，Reviewer 后做最终检查，再把未确认项作为 blocking reason 交给 Main · 最终汇总； 7. 无数据或全部 verified-cleaned → 正常；纯声明、未受控/未读取证据、Reviewer 拒绝、pending 或 adapter 失败 → blocking reason + execution/report 残留清单； 8. 不增加网站任意 cleanup command、数据库写权限或“相信 Markdown 自述”的捷径； 9. 测试账号、数据 ID、清理证据和 adapter receipt 全部脱敏。 @@ -279,7 +309,7 @@ LUOWANG_LIVE_OSS_ACCESS_KEY_SECRET - claim 未登记 ID、其他 Run ID、重复确认被拒绝或明确幂等； - 受控 adapter 删除并独立查询不存在，可直接产生 verified receipt；adapter 部分失败仍 blocked； - 多场景数据分别核验，pending 数量正确； -- 零数据 Run 不要求 adapter或 Reviewer cleanup 工具； +- 零数据 Run 不要求 adapter 或 Reviewer cleanup 工具； - execution/review/report 有脱敏清理事实，没有密码、Cookie、Token 或原始敏感响应； - FixtureSessionFactory 不再通过注入“总是成功 cleanup”掩盖生产默认路径。 @@ -315,30 +345,30 @@ LUOWANG_LIVE_OSS_ACCESS_KEY_SECRET `AC-CLOSURE-ACTIVE-01` 和上游 `AC-ACTIVE-VIEW-01` 通过。 -## 11. Closure Phase 5：Main 相关历史 Run +## 11. Closure Phase 5：Main Planning 相关历史 Run ### 目标 -Main 能使用 SQLite/Recovery 中未写入正式 Git 报告的历史事实，同时保持查询有限、脱敏和角色隔离。 +Main · 规划能使用 SQLite/Recovery 中未写入正式 Git 报告的历史事实；Main · 最终汇总只得到本次 confirmed Bugs 的 Issue create/link 所需摘要，同时保持查询有限、脱敏和角色隔离。 ### 修改范围 1. 扩展 RunStore/Recovery owner，提供 Spec §7 的摘要查询；复用已有表，不复制历史； 2. 支持 recent、commit、scenario、bug/Issue 过滤和 20/100 限制； -3. 增加 Main 专用 `query_run_history` custom tool；Main A 可查询，Main B 只查询本次 bug 相关摘要； +3. 增加 Main Planning 专用 `query_run_history` custom tool；Main · 最终汇总不获得该工具，只由 Harness 注入本次 confirmed Bugs 的 Issue create/link 所需有限摘要； 4. Runner、Reviewer 工具集中不存在该工具； 5. 返回正常 completed、特殊 blocked、interrupted、场景 PR、归档失败和多个 Issue 摘要； 6. 查询失败显式 unavailable，成功空结果显式 empty； -7. 更新 Main Role Skills，要求按相关性查询，不把全部历史塞进 prompt。 +7. 更新 Main · 规划和 Main · 最终汇总的内置角色指令，前者按相关性查询，后者只使用 Harness 提供的本次 bug 摘要，不把全部历史塞进 prompt。 ### 专项验证 - 构造正常 passed、failed、多 Issue、特殊 blocked + PR、interrupted、archive failed； -- Main 按场景/commit/Issue 查到正确摘要和稳定顺序； +- Main · 规划按场景/commit/Issue 查到正确摘要和稳定顺序；Main · 最终汇总只能看到本次 confirmed Bugs 的有限摘要，不能主动扩大查询； - limit 边界、无结果和数据库失败区分； - 摘要不含完整工件、测试账号、Secret 和未经脱敏错误； - Runner/Reviewer 调不到历史工具； -- Main 计划真实引用相关历史，不回写旧 Run。 +- Main · 规划产出的计划真实引用相关历史，不回写旧 Run。 ### 退出条件 @@ -348,33 +378,50 @@ Main 能使用 SQLite/Recovery 中未写入正式 Git 报告的历史事实， ### 目标 -本地 acceptance 真实穿过 Pi SDK Session/Role Skill/custom tools，同时把 local、live 和 release 状态彻底分开。 +本地 acceptance 真实穿过 Pi SDK Session、Built-in Role Instructions、Pi 模型消息和 custom tool 循环；同时覆盖普通 Run、完整陌生项目初始化和确定性故障恢复，并把 local、live、release 状态彻底分开。 ### 修改范围 1. 建立本地可控模型协议服务或等价 adapter，使测试不调用公网但真实经过生产 `createPiAgentSessionFactory` 和 `createAgentSession()`； -2. 至少完成 Main A → Runner → Reviewer → Main B 的真实 Pi 消息/工具循环、五文件和 dispose；不能注入 FixtureSessionFactory 作为该 AC 证据； -3. 保留 FixtureSessionFactory 用于细粒度确定性单测，但验收报告准确标记层级； -4. 重构 acceptance AC 映射，每个 AC 运行或引用能证明自身行为的检查，不按七个粗 proof 批量赋值； -5. 增加 `test:acceptance:local`、`test:acceptance:live`、`test:acceptance:release`；兼容 `test:acceptance` 只能别名 local； -6. live 输入预检一次列出所有 missing 字段；blocked/failed 非零；release 只在质量、local、live 全部 passed 时为零； -7. 报告拆分 local/live/release，保存命令和证据，不保存 Secret； -8. 更新 CI 只运行 local，输出明确“CI 未执行 live”；fork PR 不接收 live Secrets； -9. 更新 README 的最终命令和状态说明。 +2. 为普通 Run 建立真实生产路径验收：Main Planning Session → Runner Session → Reviewer Session → Main Finalization Session；四个 Session 各自新建和 dispose，两个 Main Session 共用 `agents.main` 配置但不共享对话，通过五个 Markdown 工件交接； +3. 为陌生项目初始化建立完整真实 Pi 路径： + - Main Planning Session：静态勘察； + - Runner Session：运行时侦察； + - **新的** Main Planning Session：候选综合； + - **新的** Runner Session：候选验证； + - Reviewer Session：独立审核； + - Main Finalization Session：最终汇总； +4. 初始化验收必须形成三个独立用例： + - 直接新增场景：执行完整六 Session 序列，由候选验证 Runner 真实执行后再进入 Reviewer 和 Main Finalization； + - 需要场景 PR：执行 Main Planning 静态勘察 → Runner 运行时侦察 → 新 Main Planning 候选综合 → Reviewer → Main Finalization 五个 Session；跳过候选验证 Runner，不执行未审核场景，仍写齐五个 Markdown 工件和受限 patch，以 blocked 归档并创建场景 PR； + - 最终修订未重跑：在已经完成候选验证的初始化用例中，Main · 最终汇总按 Reviewer 意见修订尚未发布 patch 后，不创建新的 Runner Session，因此结果保持 blocked； +5. 记录并断言每次 Session 的唯一 ID、Agent 配置来源、内置角色指令 ID/hash、工具集合、输入工件、输出工件和 dispose；多个 Main Planning Session、多个 Runner Session 均不得共享完整对话； +6. 把确定性故障证明纳入 local：使用真实生产代码和本地 Git、HTTP、S3-compatible 服务验证 merge 冲突、归档失败重试、Indexer 暂时不可用、进程重启、队列恢复及 prepared/resolved merge 恢复； +7. 保留 FixtureSessionFactory 用于细粒度确定性单测，但普通/初始化 Pi 路径和上述生产恢复不得以 FixtureSessionFactory 作为 AC 证据； +8. 重构 acceptance AC 映射，每个 AC 运行或引用能证明自身行为的检查，不按粗粒度 proof 批量赋值； +9. 增加 `test:acceptance:local`、`test:acceptance:live`、`test:acceptance:release`；兼容 `test:acceptance` 只能别名 local； +10. live 输入预检一次列出所有 missing 字段；blocked/failed 非零；release 只在质量、local、live 全部 passed 时为零； +11. 报告拆分 local/live/release，保存命令和证据，不保存 Secret； +12. 更新 CI 只运行 local，输出明确“CI 未执行 live”；fork PR 不接收 live Secrets； +13. 更新 README 的最终命令和状态说明。 ### 专项验证 -- 生产 Session factory 的四个角色确实创建/销毁，工具调用和 Role Skill 标记可审计； +- 普通 Run 创建四个不同 Session ID，显示 Main · 规划 → Runner → Reviewer → Main · 最终汇总；两个 Main Session 使用同一 Main 模型/thinking 配置但 Prompt、工具和对话隔离； +- 普通 Run 真实经过 Pi 模型消息和 custom tool 循环，写出 `plan.md`、`execution.md`、`draft-report.md`、`review.md`、`report.md` 并 dispose 全部 Session； +- 初始化直接新增场景用例真实经过六个新 Session；两个 Main Planning Session 互不共享对话，两个 Runner Session 互不共享对话，每次只获得本阶段内置角色指令和工具； +- 初始化场景 PR 用例严格创建 Main Planning/Runner/Main Planning/Reviewer/Main Finalization 五个 Session，明确没有候选验证 Runner；`plan.md`、`execution.md`、`draft-report.md`、`review.md`、`report.md` 和受限 patch 齐全，结果 blocked 后才由归档创建场景 PR；不把未审核场景写成已验证； +- 初始化最终汇总修订 patch 用例没有重新 Runner 执行，因此最终仍 blocked； +- 配置和 connectivity checks 仍只有 Main、Runner、Reviewer 三组，不出现 Planner/Finalizer 字段或第四个 Provider 检查； - 模型协议返回非法工具、漏写文件、越权工具时生产校验拒绝； +- 本地真实 Queue/Repository/Archiver/Indexer 生产代码通过 merge conflict、prepared/push/resolved 各退出点、归档失败重试、Indexer 故障恢复、进程重启和队列恢复； - `test:acceptance:local` 在无外部变量环境通过且不称 release passed； -- `test:acceptance:live` 缺任一字段列出完整 missing 集合并非零； -- 构造 live failed/blocked，release 非零；全部 test double 只能使 local passed； -- 每个受影响 AC 报告自己的 evidence； -- 报告与 CI 日志中注入 canary Secret，扫描阴性。 +- `test:acceptance:live` 缺任一字段列出完整 missing 集合并非零；构造 live failed/blocked 时 release 非零；全部 test double 只能使 local passed； +- 每个受影响 AC 报告自己的 evidence；报告与 CI 日志中注入 canary Secret，扫描阴性。 ### 退出条件 -`AC-CLOSURE-PI-01`、`AC-CLOSURE-ACCEPT-01`、`AC-CLOSURE-ACCEPT-02` 通过；Phase 7 可以只关注真实外部系统，而不回头补验收基础设施。 +`AC-CLOSURE-PI-01`、`AC-CLOSURE-ACCEPT-01`、`AC-CLOSURE-ACCEPT-02` 通过；merge、归档、Indexer、重启和队列恢复的确定性故障证据已在 local 完成，Phase 7 只关注真实外部联合证明。 ## 13. Closure Phase 7：真实联合验收和发布 @@ -407,33 +454,32 @@ Main 能使用 SQLite/Recovery 中未写入正式 Git 报告的历史事实， ### 实施与验收范围 1. 构建候选 `quality` 和 `runtime` 镜像，从独立持久卷启动一个非 root 罗网实例； -2. 通过网站/API 配置真实测试仓库、环境、Provider、三个模型、Playwright MCP、私有 OSS 和账号； +2. 通过网站/API 配置真实测试仓库、环境、Provider、Main/Runner/Reviewer 三个模型、Playwright MCP、私有 OSS 和账号；不得出现 Planner/Finalizer 独立配置或第四个模型检查； 3. 运行所有 connectivity checks，保存脱敏结果； -4. 使用 merge-source 请求把可控产品/需求变化纳入 `scenario-testing`，验证 FIFO 和固定新 HEAD； -5. 完成一个真实 passed UI Run：真实 Pi 四 Session、Playwright MCP 操作、截图、OSS 上传、Reviewer 看图、数据创建/删除/mark cleaned、五文件、Git 三报告、Indexer 回读和实时 0/N→N/N； +4. 使用 merge-source 请求把可控产品/需求变化纳入 `scenario-testing`，验证 FIFO、prepared/resolved 持久化事实和固定 `resolved_target_commit`； +5. 完成一个真实 passed UI Run：真实 Pi 创建 Main · 规划、Runner、Reviewer、Main · 最终汇总四个隔离 Session，执行 Playwright MCP 操作、截图、OSS 上传和 Reviewer 看图；创建并删除测试数据，提交清理 claim 后由 adapter 独立核验或 Reviewer 实际读取 Harness 证据确认；写五个工件、Git 正式报告，完成 Indexer 回读和实时 0/N→N/N； 6. 使用人类预先给出的两个独立、可逆失败条件完成一个真实 failed Run，确认至少两个不同 Bugs，幂等创建/关联多个 Issues，报告及 Issues 完成后才推进； 7. 完成一个真实 blocked Run：保留已确认 Bug（如有）但不推进；阻塞来源使用可控非生产依赖，不破坏环境； 8. 验证场景 PR、PR 合并后旧 Run 不变、当前 HEAD 人工重测； -9. 验证 merge 冲突、归档失败重试、Indexer 暂时不可用恢复、进程重启 interrupted 和队列恢复； -10. 验证场景/报告 allowlist、历史报告 blob SHA 不变、罗网仓库无测试资产； -11. 验证所有测试数据和 OSS 临时探测对象按策略清理；被正式 Git 报告引用的证据对象保留到项目负责人明确执行后续保留/删除决定，不得在验收收尾时误删； -12. 运行 `npm run test:acceptance:release`，保存 JSON/Markdown 证据； -13. 发现生产问题时停止发布，在独立 `fix/*` 修复、合入 develop、重建候选并重跑受影响 AC 和完整 release acceptance； -14. 全部通过后由项目负责人选择 `v0.1.1` 或 `v0.2.0`，更新版本/README/变更说明； -15. 发起 `develop → main` PR，合并后创建指向发布 commit 的新 tag；核对 `v0.1.0` 指向未变化； -16. 轮换/撤销临时 GitHub Token、Provider Key、OSS Key 和测试账号，或记录它们作为专用长期凭据继续保留的人工决定。 +9. 验证场景/报告 allowlist、历史报告 blob SHA 不变、罗网仓库无测试资产； +10. 验证所有测试数据和 OSS 临时探测对象按策略清理；被正式 Git 报告引用的证据对象保留到项目负责人明确执行后续保留/删除决定，不得在验收收尾时误删； +11. 运行 `npm run test:acceptance:release`；它必须复用 Phase 6 的 local 确定性故障证据并执行本 Phase live 联合证明，保存分层 JSON/Markdown 结果；不在真实 GitHub/官网环境重复制造 merge 冲突、归档、Indexer、重启或队列故障； +12. 发现生产问题时停止发布，在独立 `fix/*` 修复、合入 develop、重建候选并重跑受影响 AC 和完整 release acceptance； +13. 全部通过后由项目负责人选择 `v0.1.1` 或 `v0.2.0`，更新版本/README/变更说明； +14. 发起 `develop → main` PR，合并后创建指向发布 commit 的新 tag；核对 `v0.1.0` 指向未变化； +15. 轮换/撤销临时 GitHub Token、Provider Key、OSS Key 和测试账号，或记录它们作为专用长期凭据继续保留的人工决定。 ### 必须保存的非 Secret 证据 - 候选镜像 digest、发布 commit； - 测试仓库 URL、场景分支、source/merge/target commits； - passed/failed/blocked Run IDs； -- Role Skill IDs/hash、三个模型 ID； +- 内置角色指令 IDs/hash、Main/Runner/Reviewer 三个模型 ID； - 场景进度 API/页面截图； - OSS object keys/稳定受保护 URL 和 Reviewer 读取事实； - 报告 commit、场景 PR、多个 Issue URLs； - 清理前后脱敏数据 ID/查询结果； -- 重启、归档重试和 Indexer 回读结果； +- Phase 6 local 的重启/归档重试/队列恢复证据引用，以及本次 live Indexer 回读结果； - local/live/release AC 矩阵和命令退出码； - `v0.1.0` 与新 tag 指向。 @@ -456,7 +502,7 @@ Main 能使用 SQLite/Recovery 中未写入正式 Git 报告的历史事实， | `AC-CLOSURE-INSTR-03` | Closure 1 | Closure 6、7 | | `AC-CLOSURE-MERGE-01` | Closure 2 | Closure 6、7 | | `AC-CLOSURE-TARGET-01` | Closure 2 | Closure 6、7 | -| `AC-CLOSURE-MERGE-02` | Closure 2 | Closure 6、7 | +| `AC-CLOSURE-MERGE-02` | Closure 2 | Closure 6 | | `AC-CLOSURE-DATA-01` | Closure 3 | Closure 6、7 | | `AC-CLOSURE-DATA-02` | Closure 3 | Closure 6、7 | | `AC-CLOSURE-ACTIVE-01` | Closure 4 | Closure 6、7 | diff --git a/docs/changes/luowang-v07-production-closure/spec.md b/docs/changes/luowang-v07-production-closure/spec.md index 407b89f..99f35d1 100644 --- a/docs/changes/luowang-v07-production-closure/spec.md +++ b/docs/changes/luowang-v07-production-closure/spec.md @@ -1,6 +1,6 @@ # 罗网 v0.7 生产闭环补齐 Spec -- 状态：Implementation Baseline v0.1 +- 状态：Implementation Baseline v0.2 - 关联 Intent：[intent.md](./intent.md) - 实现计划：[plan.md](./plan.md) - 上游规格：[罗网 Harness MVP Spec](../luowang-harness-mvp/spec.md) @@ -8,7 +8,7 @@ ## 1. 规格范围与优先级 -本 Spec 只覆盖以下增量：角色工作方法装载、人工 merge 与固定 target、测试数据清理确认、实时场景进度、Main 历史 Run、验收分层、外部资源交付和后续发布。 +本 Spec 只覆盖以下增量：角色工作方法装载、人工 merge 与固定 target、测试数据清理确认、实时场景进度、Main Planning 历史 Run、验收分层、外部资源交付和后续发布。 发生冲突时： @@ -21,23 +21,23 @@ 实现以当前 `develop` 为起点，并把下列事实作为回归基线： -- 四个独立 Agent Session 和角色 custom tools 已存在，生产 Session 使用 Pi SDK； +- `agents.main`、`agents.runner`、`agents.reviewer` 三组 Agent 配置已存在；正常 Run 创建 Main · 规划、Runner、Reviewer、Main · 最终汇总四个独立 Session，生产 Session 使用 Pi SDK； - ambient extensions、Skills、Prompt Templates、Themes 和 Context Files 已关闭； - 当前角色方法硬编码在 Orchestrator，完整提示词同时进入 system prompt 和首条用户消息； - `/api/repository/merge` 直接执行 merge，`/api/runs` 接受任意 `targetCommit`； - 默认 TestDataManager 没有清理实现，登记数据后无法确认已清理； - `currentScenario` 和 `scenarioProgress` 只初始化、不随真实 Runner 更新； -- Run Store 已保存详细 Run，但 Main 上下文只包含正式报告摘要和 GitHub Issues； +- Run Store 已保存详细 Run，但 Main · 规划上下文只包含正式报告摘要和 GitHub Issues； - Phase 9 本地 acceptance 使用 FixtureSessionFactory，live smoke 只覆盖 GitHub 的有限路径； - `v0.1.0` 已发布，必须保持不可变。 -## 3. 内置 Role Skills 与 Prompt 组装 +## 3. Built-in Role Instructions 与 Prompt 组装 ### 3.1 设计选择 -罗网不使用 Pi 面向通用 Agent 的 ambient Skill 发现和“模型按需调用通用 read 加载 SKILL.md”机制。固定角色的方法每次都适用，应由应用在创建 Session 前确定性、完整加载。 +罗网不使用 Pi Skills。Main、Runner、Reviewer 的业务职责固定，应用必须在创建 Session 前从自身发布物中确定性、完整加载 Built-in Role Instructions（内置角色指令），而不是让模型发现或读取 Skill。 -罗网维护以下第一方、版本化 Markdown 资源： +固定资源为： ```text resources/agent-roles/ @@ -49,80 +49,118 @@ resources/agent-roles/ └── scenario-initialization.md ``` -这些文件称为 **Role Skills**，但它们不是目标仓库 `.pi/skills`，也不参与 Pi 的全局/项目自动发现。构建产物和 Docker 镜像必须包含它们；任一必需文件缺失、为空或不可读时，对应 Session 创建失败并给出不含本地敏感路径的明确错误。 +这些 Markdown 文件是罗网发布物中的固定角色说明，不是 `SKILL.md`，不遵循 Pi Skill 格式，也不参与 Pi 的全局、用户、宿主机或项目自动发现。构建产物和 Docker 镜像必须包含它们；任一必需文件缺失、为空或不可读时，对应 Session 创建失败并给出不含本地敏感路径的明确错误。 -### 3.2 Session 装载规则 - -| Session | 固定装载 | 条件装载 | -|---|---|---| -| Main A | `common.md` + `main-planning.md` | 初始化 Run 再加 `scenario-initialization.md` | -| 初始化候选 Main | `common.md` + `main-planning.md` + `scenario-initialization.md` | 无 | -| Runner | `common.md` + `runner-execution.md` | 初始化 Run 再加 `scenario-initialization.md` 中 Runner 相关段落或独立受控节 | -| Reviewer | `common.md` + `reviewer-audit.md` | 初始化 Run 再加必要的初始化审核规则 | -| Main B | `common.md` + `main-finalization.md` | 初始化 Run 再加 `scenario-initialization.md` | - -实现可以在构建时把 Markdown 编译为模块，或在启动时从固定安装目录读取；无论采用哪种方式，生产 Session 获得的内容必须只来自当前罗网版本的 allowlist，不能接收 Agent 指定路径。 - -继续保持： +Session 创建继续保持： ```text +skills = [] noSkills = true noPromptTemplates = true noContextFiles = true noTools = builtin ``` -不得为了 Role Skill 开放任意 `read`。以后确有大型可选参考资料时，只能增加按逻辑名称映射到当前角色固定 allowlist 的 `read_role_reference(name)`；本变更不要求先实现该工具。 +不得使用 `skillsOverride`，不得开放通用 `read`，不得加载目标仓库中的 `.pi/skills`、`.agents/skills`、`AGENTS.md` 或其他角色资源，也不得允许网站配置任意角色指令路径。 + +### 3.2 三个 Agent 配置与四个独立 Session + +罗网只有三组可配置 Agent： + +```text +agents.main +agents.runner +agents.reviewer +``` + +正常 Run 创建四个全新的独立 Session： + +```text +Main Planning Session +→ Runner Session +→ Reviewer Session +→ Main Finalization Session +``` + +面向用户统一显示： + +```text +Main · 规划 +Runner +Reviewer +Main · 最终汇总 +``` + +Main Planning Session 和 Main Finalization Session 共同使用 `agents.main` 的 Provider、模型和 thinking 配置，但它们是两个新建、互相隔离的 Session：不共享完整对话，使用不同内置角色指令和不同受控工具，只通过落盘 Markdown 工件交接。不得增加 `agents.planner`、`agents.finalizer`、第四个模型字段、第四个 Provider 检查或第四组 live 模型输入。 + +初始化流程可以创建多个 Main Planning Session 和多个 Runner Session；每次都必须新建并隔离，但分别复用 `agents.main` 和 `agents.runner` 配置。内部类型为兼容现有数据可以继续使用 `main-a`、`main-b`，不要求迁移；网站、当前执行页面、活动记录和报告不得显示这些内部名称。 + +### 3.3 四类 Session 职责与装载 -### 3.3 Prompt 分层 +| Session | 固定装载 | 初始化时附加 | 职责与硬边界 | +|---|---|---|---| +| Main · 规划 | `common.md` + `main-planning.md` | `scenario-initialization.md` | 理解请求、需求和累计 diff；阅读项目理解、场景和相关历史；维护或选择场景；形成 `plan.md`；必要时生成受限场景 patch；不执行测试 | +| Runner | `common.md` + `runner-execution.md` | 无 | 顺序执行计划；使用受控命令、Playwright MCP 和测试账号；创建、登记、清理测试数据；保存证据；写 `execution.md` 和 `draft-report.md` | +| Reviewer | `common.md` + `reviewer-audit.md` | 无 | 独立读取本次工件和受控证据；审核截图和清理证据；判断 Bug、blocked 和零场景结论；写 `review.md`；不执行命令、不获取测试账号 | +| Main · 最终汇总 | `common.md` + `main-finalization.md` | `scenario-initialization.md` | 读取前置工件和 Reviewer 结论；按 `blocked > failed > passed` 聚合；处理 confirmed Bugs 的 Issue create/link；写 `report.md`；初始化 Run 可按 Reviewer 意见修订尚未发布的场景 patch，但修订后未重新执行必须保持 blocked | -每个 Session 只发送一次固定方法： +初始化中的“静态勘察”和“候选综合”都是 Main Planning Session；“运行时侦察”和“候选验证”都是 Runner Session。职责相同的多次 Session 仍不能共享完整对话，只能读取当时允许的落盘工件和角色裁剪上下文。 + +实现可以在构建时把 Markdown 编译为模块，或在启动时从固定安装目录读取；无论采用哪种方式，生产 Session 获得的内容必须只来自当前罗网版本的固定 allowlist，不能接收 Agent 或网站指定路径。 + +### 3.4 Prompt 分层 + +每个 Session 的输入固定分成： ```text System Prompt = 角色身份 -+ common Role Skill -+ 当前角色 Role Skill ++ common Role Instructions ++ 当前阶段 Role Instructions + 可选初始化规则 -+ 当前角色输出契约 ++ 输出契约 -首条 User Message -= 本次任务 +User Message += 当前任务 + 经过角色裁剪的动态 Run 上下文 ``` -禁止把同一完整角色说明同时放入 system prompt 和 user message。动态值不写入 Role Skill：run-id、请求、base/target/included commits、阻塞原因、历史摘要和证据引用都属于本次用户消息或受控工具结果。 +同一完整角色说明不能同时进入 system prompt 和 user message。动态值不写入内置角色指令：run-id、请求、base/target/included commits、阻塞原因、历史摘要和证据引用都属于本次 user message 或受控工具结果。 -### 3.4 角色动态上下文 +内置角色指令不提供权限。权限只由 custom tools、Secret Store、adapter、writer、路径 allowlist 和 patch 校验强制控制；Prompt 声明不能扩大工具、Secret 或写入范围。 -- **Main A**：请求、trigger、base/target/included commits、场景模式、初始化标记、已索引场景摘要、历史报告/Run/Issue 查询能力； +### 3.5 角色动态上下文 + +- **Main · 规划**：请求、trigger、base/target/included commits、场景模式、初始化标记、已索引场景摘要，以及有限的历史报告/Run/Issue 查询能力； - **Runner**：run-id、固定 target、计划、工作场景、非生产环境工具和 Harness 已确认阻塞原因；不直接注入历史 Issues 或 Git Token； - **Reviewer**：run-id、固定 target、本次工件、证据引用和 Harness 阻塞原因；可以对已经读取的当前 Run 清理证据作结构化确认，但不获得目标环境命令、历史 Issue 列表、测试账号或任意仓库写入能力； -- **Main B**：固定 Run 范围、本次四个前置工件、Reviewer 结论、与 confirmed bugs 相关的已有 Issue 查询结果；不获得目标仓库通用读取和命令能力。 +- **Main · 最终汇总**：固定 Run 范围、本次四个前置工件、Reviewer 结论，以及只与本次 confirmed Bugs 的 Issue create/link 相关的历史 Issue/Run 摘要；不获得通用历史查询、目标仓库通用读取或命令能力。 -### 3.5 Role Skill 内容规则 +### 3.6 内置角色指令内容规则 -从 `opc-aicom/.pi/skills` 只吸收适合 v0.7 的方法： +内置角色指令固定以下方法： - 已确认规格和长期场景回答“应该是什么”；代码只回答“怎么调用”和“当前实际怎样”，不能用当前实现反推正确期望； -- Main 明确记录选择理由、证据优先级和覆盖缺口； +- Main · 规划明确记录选择理由、证据优先级和覆盖缺口； - Runner 不修改产品或场景，按顺序执行，记录实际观察、决定性/辅助证据、偏差、Secret 边界和清理； - Reviewer 先看固定 Run/场景期望和原始证据，最后才看 Runner 草稿；Runner 报告是待审核假设，不是事实； - 不影响验证目标的偏差可以记录后继续，影响前置、操作语义或断言的偏差必须 blocked； -- Main B 只根据已落盘事实和审核结论聚合，不发明执行事实，不回写旧结果； -- 每个 Role Skill 使用“目标、硬边界、顺序、输出契约、失败规则、反模式”的稳定结构。 +- Main · 最终汇总只根据已落盘事实和审核结论聚合，不发明执行事实，不回写旧结果； +- 每份内置角色指令使用“目标、硬边界、顺序、输出契约、失败规则、反模式”的稳定结构。 -明确不吸收 suite/catalog、长期能力图、多 checkpoint、审批 hash、workflow gate、大量状态 JSON、五状态、三轴结果、发布 gate、pi-subagents、自测和公共 OSS 规则。 +不引入 suite/catalog、长期能力图、多 checkpoint、审批 hash、workflow gate、大量状态 JSON、五状态、三轴结果、发布 gate、pi-subagents、自测和公共 OSS 规则。 -### 3.6 可验证性 +### 3.7 可验证性 -每个 Role Skill 固定逻辑 ID 和内容格式版本；运行/验收以 `逻辑 ID + 应用版本 + 内容 SHA-256` 标识实际装载版本。验收报告记录这些标识，但不创建新的 Run 状态文件。测试必须证明： +每份内置角色指令固定逻辑 ID 和内容格式版本；运行/验收以 `逻辑 ID + 应用版本 + 内容 SHA-256` 标识实际装载版本。验收报告记录这些标识，但不创建新的 Run 状态文件。测试必须证明： -- 每个 Session 只装载自己的 Role Skill； -- ambient 用户/宿主机/目标仓库 Skill 即使存在也不会进入 system prompt； +- 四类 Session 只装载自己的内置角色指令； +- ambient Skills、Prompt、Context、用户/宿主机/目标仓库资源即使存在也不会进入 Session； - system prompt 不包含其他角色的专属规则； -- user message 不重复完整 Role Skill； -- 工具 allowlist 不因 Role Skill 改变。 +- user message 不重复完整内置角色指令； +- 工具 allowlist 不因指令内容改变； +- 配置仍只有 Main、Runner、Reviewer 三组，Main 的两个 Session 使用同一配置但对话和工具隔离； +- 面向用户只显示 Main · 规划、Runner、Reviewer、Main · 最终汇总。 ## 4. 固定场景测试分支上的人工请求 @@ -136,7 +174,7 @@ System Prompt | `manual-current-head` | 人工/API 请求文本、可选 initialization | fetch 后固定当前远端场景测试分支 HEAD；人工请求不合并、不丢失 | | `manual-merge-source` | 人工请求文本、`sourceRef`、明确确认 | 轮到时 fetch，`merge --no-ff` 到场景测试分支，non-force push，固定发布后的新 HEAD，再创建 Run | -队列可以增加明确的 request kind 和 `sourceRef` 字段；不得把 branch/tag/任意 SHA 继续伪装成可直接 checkout 的 `targetCommit`。 +队列 migration 必须增加并持久化 `request_kind`、`source_ref`、`prepared_merge_commit`、`resolved_target_commit`；字段使用数据库命名，API 可继续使用对应 camelCase。`prepared_merge_commit` 和 `resolved_target_commit` 是请求幂等事实，不是通用 checkpoint 或工作流状态。不得把 branch/tag/任意 SHA 继续伪装成可直接 checkout 的 `targetCommit`。 ### 4.2 API 和网站行为 @@ -146,13 +184,44 @@ System Prompt - 初始化请求同样只能针对当前场景测试分支 HEAD，或先通过 merge-source/首次建分支把来源纳入固定分支； - API 响应和网站显示 queued、merge/running、waiting archive、completed/failed/interrupted 等现有事实，不增加跨 Run checkpoint。 -### 4.3 合并失败与幂等 +### 4.3 固定 merge 结果与恢复幂等 + +`manual-merge-source` 必须按以下顺序执行： +```text +解析 source ref +→ 基于当时远端 scenario-testing HEAD 生成本地 merge commit +→ 持久化 prepared_merge_commit +→ non-force push +→ 持久化 resolved_target_commit +→ 使用 resolved_target_commit 创建且只创建一个 Run +``` + +具体规则： + +- `prepared_merge_commit` 必须在 push 前提交到 SQLite；成功 push 后，`resolved_target_commit` 固定为已经发布到场景测试分支的同一 commit；Orchestrator 只能接收该字段，不能重新读取移动中的 HEAD 替换 target； +- 来源已经是场景测试分支祖先时不创建重复 merge commit；把当时远端 HEAD 作为本请求的 prepared/resolved commit，仍可创建本次人工 Run； +- 进程在 push 后、写入 resolved 前退出时，恢复逻辑 fetch 远端并检查是否已包含 `prepared_merge_commit`；已包含则持久化同一 `resolved_target_commit`，不得重复 merge 或改用更新后的 HEAD； +- 进程在 prepared 后、push 前退出时，只能尝试把同一 prepared commit non-force push；若远端已经竞争性前进且不包含 prepared commit，则请求明确失败，不重新生成指向新 HEAD 的 merge； +- `resolved_target_commit` 已存在时，恢复逻辑只校验该 commit 已发布在远端场景测试分支历史中，然后创建或关联唯一 Run；即使场景分支后来又有新 commit，本请求 target 也不改变； - `sourceRef` 无法解析、merge 冲突、远端竞争或 push 失败时，请求以明确失败结束，不创建 Agent Run、不修改产品代码、不推进 target； -- 来源已是场景测试分支祖先时不重复 merge，但仍可对当前远端 HEAD 创建本次人工 Run； -- merge 成功后记录 merge commit/场景分支 HEAD，并把该不可变 SHA 交给 Orchestrator；后续到达的新 commit 留给下一请求； -- 人工 merge 请求不参与自动请求合批；进程在 merge 后、Run 前退出时，恢复逻辑必须通过远端祖先检查重试，不能重复 merge 或丢失请求； -- 远端写入继续禁止 force-push。 +- 人工 merge 请求不参与自动请求合批；远端写入继续禁止 force-push。 + +### 4.4 `v0.1.0` 旧队列行迁移 + +旧 schema 的 `target_ref` 不能被静默解释成已确认的 `source_ref`。migration 和启动恢复使用以下固定规则： + +| 旧行 | 新 `request_kind` | 处理 | +|---|---|---| +| `trigger=git|schedule`，`status=queued` | `automatic-head` | 保留旧 `target_ref` 只作历史审计；新调度不直接使用它，轮到时按当前 automatic-head 规则固定场景分支可测试 HEAD | +| `trigger=manual|api`，`status=queued`，`target_ref IS NULL` | `manual-current-head` | 正常保留排队，轮到时固定当前场景分支 HEAD | +| `trigger=manual|api`，`status=queued`，`target_ref IS NOT NULL` | `manual-current-head` | migration 直接标记 `failed`，错误说明旧任意 target 不会自动升级成 merge 授权；操作者必须通过新 merge-source 入口重新提交 | +| `status=running` 且 `run_id IS NULL` | 按上述 queued 规则 | automatic 或无 target 的 manual/api 可重新排队；带旧 target 的 manual/api 标记 failed，不执行旧 target | +| `status=waiting_archive` 且 `run_id IS NULL` | 按 trigger 归类 | migration 统一标记 `failed`，错误说明等待归档请求缺少 Run ID；不得重新排队、merge 或创建 Run | +| `status=running|waiting_archive` 且已有 `run_id` | 按 trigger 归类 | 只恢复既有 Run/归档，不重新调度；`resolved_target_commit` 从该 Run/Recovery 的已固定 target 回填（可取得时） | +| `status=completed|failed|interrupted` | 按 trigger 归类 | 作为历史只读记录保留，不重新执行；有已存 Run 时可从 Run Store 回填 resolved，无值则保持 null | + +旧 `target_ref` 列可以为兼容读取保留，但新请求不再写入，调度器也不得把它当作 source 或 resolved target。migration 必须在同一事务中先回填 `request_kind` 再处理旧 pending 行；错误信息不得包含 Secret。旧 automatic 行在新语义下按调度时 HEAD 执行，旧 manual/api 任意 target 宁可显式失败，也不能在没有新的 merge 确认时推进 `scenario-testing`。 ## 5. 测试数据生命周期 @@ -192,7 +261,7 @@ Reviewer 获得 `verify_test_data_cleanup`：只能处理当前 Run 的 cleanup - Runner 在每个创建数据的场景结束前执行删除、保存删除后核验证据并提交 cleanup claim； - Runner 结束后，Harness 可以先让受控 adapter 对 pending 条目兜底删除和独立核验；其余 claim 交给 Reviewer 读取证据并确认； -- Reviewer 完成后、Main B 汇总前，Harness 对全部登记项做最终核对；任何仍为 registered、cleanup-claimed、被 Reviewer 拒绝或 adapter 核验失败的项目都加入 blocking reason； +- Reviewer 完成后、Main · 最终汇总前，Harness 对全部登记项做最终核对；任何仍为 registered、cleanup-claimed、被 Reviewer 拒绝或 adapter 核验失败的项目都加入 blocking reason； - 最终结果必须 blocked，execution/report 列出脱敏残留 ID、声明/核验状态和原因； - 没有登记数据或全部 `verified-cleaned` 时，默认生产配置可以正常完成，不要求虚假的空清理 adapter； - 本变更不开放网站任意清理命令、任意数据库写入或目标项目脚本路径配置。 @@ -220,9 +289,9 @@ finish_scenario(scenario_id) 进度只用于真实可观察状态，不替代最终 `report.md` 的场景结果。Agent 异常时保留最后一次活动并进入现有失败/interrupted 流程。 -## 7. Main 的历史 Run 查询 +## 7. Main Planning 的历史 Run 查询 -在现有 Run Store/Recovery Store owner 上增加 Main 专用只读查询，不建立第二份历史源。 +在现有 Run Store/Recovery Store owner 上增加 Main Planning 专用只读查询，不建立第二份历史源。 查询默认返回有限、脱敏摘要，每条可包含： @@ -235,10 +304,10 @@ finish_scenario(scenario_id) 支持按当前 commit 范围、场景 ID、Issue/bug key 和最近数量筛选；默认上限 20，硬上限 100。默认不返回完整工件、模型对话、Secret、测试账号或未脱敏工具参数。 -- Main A 可按需调用，用于影响判断和场景选择； -- Main B 只获得与本次 confirmed bugs 的 Issue 处理相关摘要； -- Runner 和 Reviewer 不获得该工具； -- SQLite 查询失败与“成功但无历史”必须区分，失败时 Main 记录覆盖缺口，不能当作空历史。 +- Main · 规划可以按需调用 `query_run_history`，用于影响判断和场景选择； +- Main · 最终汇总不获得通用历史查询工具，只由 Harness 提供与本次 confirmed Bugs 的 Issue create/link 相关的有限历史 Issue/Run 摘要； +- Runner 和 Reviewer 不获得历史查询工具； +- SQLite 查询失败与“成功但无历史”必须区分，失败时 Main · 规划记录覆盖缺口，不能当作空历史。 ## 8. 验收分层和命令语义 @@ -250,7 +319,22 @@ finish_scenario(scenario_id) | 本地生产路径集成 | 真实调用 `createAgentSession()`、资源装载和工具循环；外部 Git/HTTP/S3 可使用临时服务 | 否 | 否 | | live 联合验收 | 真实 GitHub、Provider、Pi、Playwright MCP、OSS、非生产应用和账号 | 是，由操作者本地提供 | 是，且必须全部通过 | -本地生产路径集成不能再用 FixtureSessionFactory 代替 Pi Session factory。可以使用本地可控模型协议服务使输出确定，但必须真实经过 Pi SDK 的 Session、模型消息、custom tool 调用、Role Skill system prompt 和 dispose。 +本地生产路径集成不能再用 FixtureSessionFactory 代替 Pi Session factory。可以使用本地可控模型协议服务使输出确定，但必须真实经过 Pi SDK 的 Session、模型消息、custom tool 调用、内置角色指令 system prompt 和 dispose。 + +local 至少证明两类生产流程： + +1. 普通 Run：Main Planning Session → Runner Session → Reviewer Session → Main Finalization Session，四个 Session 独立创建和 dispose，并产出五个 Markdown 工件； +2. 陌生项目初始化：Main Planning Session 静态勘察 → Runner Session 运行时侦察 → **新的** Main Planning Session 候选综合 → **新的** Runner Session 候选验证 → Reviewer Session → Main Finalization Session。 + +初始化还必须分别覆盖： + +- **直接新增并验证**：执行上述完整六 Session 序列，候选综合产生可直接应用的新场景，新的 Runner Session 执行候选验证，之后 Reviewer 和 Main Finalization 均运行； +- **需要场景 PR 时提前 blocked**：固定执行 Main Planning 静态勘察 → Runner 运行时侦察 → 新 Main Planning 候选综合 → Reviewer → Main Finalization，共五个 Session；由于候选 patch 必须人工审核，**不创建候选验证 Runner Session、不执行未审核场景**，但 Reviewer 仍审核已有侦察/patch 并写 `review.md`，Main Finalization 写 blocked `report.md`；与普通 Run 相同的五个 Markdown 工件必须齐全，另保留受限场景 patch 供归档创建 PR； +- **最终修订未重跑**：在已完成候选验证的初始化用例中，Main · 最终汇总按 Reviewer 意见修订尚未发布 patch 后，因修订内容没有新的 Runner Session 重新执行，结果必须保持 blocked。 + +多个 Main Planning Session 和多个 Runner Session 不共享完整对话，每个 Session 只获得自己的内置角色指令和受控工具；上述每条路径创建的全部 Session 都必须 dispose。 + +merge 冲突、归档失败重试、Indexer 暂时不可用、进程重启和队列恢复属于确定性本地验收：使用真实生产代码和本地 Git、HTTP、S3-compatible 服务完成，不要求在 live GitHub 或官网环境制造故障。 ### 8.2 标准命令 @@ -374,7 +458,7 @@ thinking level、环境说明、额外账号和外部 allowlist 可以使用非 | 情况 | 必须行为 | |---|---| -| Role Skill 缺失/错误 | Session 不启动，Run 明确失败或 blocked；不退回 ambient Skill | +| 内置角色指令缺失/错误 | Session 不启动，Run 明确失败或 blocked；不退回 Pi Skills 或 ambient 资源 | | 普通 Run 指定任意 target | `400` 拒绝并提示固定分支入口 | | merge conflict/远端竞争 | 队列请求失败，不创建 Run、不推进、不自动改代码 | | 数据只有 Runner 清理声明、证据未受控/未读取、Reviewer 拒绝或 adapter 未确认 | Run blocked，列脱敏残留和核验状态 | @@ -389,7 +473,7 @@ thinking level、环境说明、额外账号和外部 allowlist 可以使用非 - SQLite schema 变更使用版本化、可重复执行 migration；现有队列、Run 和归档数据必须前向升级； - API 删除或拒绝 `targetCommit` 时更新网站和测试；如保留过渡字段，只能明确报错，不能继续执行旧的不安全语义； - 已有 completed/、报告、Issues、场景 PR、last completed target 和 `v0.1.0` tag 不修改； -- Role Skill 资源属于罗网发布物，不写目标仓库； +- 内置角色指令资源属于罗网发布物，不是 Pi Skills，不写目标仓库； - 本地 acceptance 结果命名变化要提供 README 迁移说明； - 原生 `better-sqlite3` 在没有匹配预编译包时需要 `python3`、`make`、`g++`，README 优先推荐 Docker 并说明本地依赖。 @@ -404,21 +488,21 @@ thinking level、环境说明、额外账号和外部 allowlist 可以使用非 ## 13. 验收条件 -1. **AC-CLOSURE-INSTR-01**：四类 Session 和初始化流程只装载罗网版本化的正确 Role Skill；目标仓库、宿主机和用户 ambient Skills 即使存在也不会进入 Session； -2. **AC-CLOSURE-INSTR-02**：固定方法只进入 system prompt 一次，user message 只包含当前任务和角色裁剪的动态上下文；角色工具权限与上游安全边界不变； -3. **AC-CLOSURE-INSTR-03**：Role Skill 包含证据优先级、代码不得反推期望、独立审核、清理、偏差和反模式，但没有引入 suite/catalog/checkpoint/新结果状态/发布 gate； -4. **AC-CLOSURE-MERGE-01**：人工 branch/tag/SHA 请求进入 FIFO，按顺序 `merge --no-ff`、non-force push，并只测试新 `scenario-testing` HEAD；已包含来源不会重复 merge； -5. **AC-CLOSURE-TARGET-01**：普通人工/API Run 不能直接指定任意 target；自动、人工和初始化 Run 的 target 都是远端场景测试分支上的不可变 commit； -6. **AC-CLOSURE-MERGE-02**：merge 冲突、远端竞争、重启重试不修改产品代码、不重复 merge、不创建错误 Run、不推进； -7. **AC-CLOSURE-DATA-01**：Runner 可以登记并实际删除测试数据，但只有受控 adapter 独立核验，或 Reviewer 读取 Harness 管理的删除后证据并确认，才能成为 `verified-cleaned`；无 adapter 时全部经 Reviewer 确认的生产 Run可以完成； +1. **AC-CLOSURE-INSTR-01**：Main Planning、Runner、Reviewer、Main Finalization 四类 Session 只装载对应的罗网 Built-in Role Instructions；ambient Skills、Prompt、Context 和用户/宿主机/目标仓库资源不会进入 Session；配置仍只有 Main、Runner、Reviewer 三组； +2. **AC-CLOSURE-INSTR-02**：固定角色指令只进入 system prompt 一次，user message 只包含当前任务和角色裁剪的动态上下文；角色工具权限与上游安全边界不变； +3. **AC-CLOSURE-INSTR-03**：Role Instructions 内容包含证据优先级、代码不得反推期望、独立审核、清理、偏差和反模式，但没有引入 suite/catalog/checkpoint/新结果状态/发布 gate； +4. **AC-CLOSURE-MERGE-01**：人工 branch/tag/SHA 请求进入 FIFO，按顺序生成 `merge --no-ff` commit、持久化 `prepared_merge_commit`、non-force push、持久化 `resolved_target_commit`，并只测试该已发布的不可变 commit；已包含来源不会重复 merge； +5. **AC-CLOSURE-TARGET-01**：普通人工/API Run 不能直接指定任意 target；自动、人工和初始化 Run 的 target 都是远端场景测试分支历史上的不可变 commit； +6. **AC-CLOSURE-MERGE-02**：`prepared_merge_commit`、`resolved_target_commit` 和唯一 Run 关联使 merge 冲突、远端竞争、push 前后重启恢复不修改产品代码、不重复 merge、不改变本次 target、不创建错误 Run、不推进； +7. **AC-CLOSURE-DATA-01**：Runner 可以登记并实际删除测试数据，但只有受控 adapter 独立核验，或 Reviewer 读取 Harness 管理的删除后证据并确认，才能成为 `verified-cleaned`；无 adapter 时全部经 Reviewer 确认的生产 Run 可以完成； 8. **AC-CLOSURE-DATA-02**：纯 Runner 声明、未受控/未读取证据、Reviewer 拒绝、pending 或兜底核验失败都使 Run blocked，报告显示脱敏残留和核验状态且 Secret 不泄漏； 9. **AC-CLOSURE-ACTIVE-01**：真实 Runner Run 在网站依次显示总数、当前场景、已完成数和脱敏活动；零场景、Agent 异常和初始化侦察显示正确； -10. **AC-CLOSURE-HISTORY-01**：Main 能按需查询有限的正常、特殊 blocked、interrupted、场景 PR 和归档失败摘要，并区分空历史与查询失败；Runner/Reviewer 无该权限； -11. **AC-CLOSURE-PI-01**：本地生产路径集成真实经过 `createAgentSession()`、Role Skill system prompt、模型消息、custom tool 循环和 dispose，不由 FixtureSessionFactory 代替； +10. **AC-CLOSURE-HISTORY-01**：Main Planning 可以按需查询有限的正常、特殊 blocked、interrupted、场景 PR 和归档失败历史 Run，并区分空历史与查询失败；Main Finalization 只获得本次 confirmed Bugs 所需的有限历史 Issue/Run 摘要；Runner 和 Reviewer 不获得历史查询工具； +11. **AC-CLOSURE-PI-01**：本地生产路径集成用真实 `createAgentSession()` 分别完成普通 Main Planning → Runner → Reviewer → Main Finalization 四 Session Run，以及完整陌生项目初始化流程；覆盖 Pi 模型消息、内置角色指令、custom tool 循环、多个同角色 Session 的对话隔离、每个已创建 Session 的 dispose 和五个 Markdown 工件；初始化同时证明：直接新增并验证走完整六 Session；场景 PR 路径跳过候选验证 Runner、仍走 Reviewer/Main Finalization 并写齐五工件后提前 blocked；最终汇总修订未发布 patch 但未重跑时仍 blocked；FixtureSessionFactory 不能作为本 AC 证据； 12. **AC-CLOSURE-ACCEPT-01**：local、live、release 三种验收状态和命令分离；live blocked 时 release 非零，README 不再称其为全量完成； 13. **AC-CLOSURE-ACCEPT-02**：每个受影响 AC 有独立、可追溯证据，不能依靠一个粗粒度 proof 批量标记通过； 14. **AC-CLOSURE-LIVE-01**：真实 GitHub + Provider + Pi + Playwright MCP + 私有 OSS + 非生产应用完成至少一个含 UI 截图和数据创建/清理的 passed Run； -15. **AC-CLOSURE-LIVE-02**：live 另外验证 failed、多 Issues、blocked 不推进、merge-source、当前 HEAD 人工重测、归档幂等、Indexer 回读和实时进度； +15. **AC-CLOSURE-LIVE-02**：live 另外验证含两个 confirmed Bugs/Issues 的 failed Run、blocked 不推进、merge-source、场景 PR、当前 HEAD 人工重测、正式报告、Indexer 回读和实时进度； 16. **AC-CLOSURE-SECRET-01**：所有 live Secret 只从受控输入进入候选实例/Secret Store，不出现在命令输出、环境回显、API 响应、日志、工件、Git、PR/Issue 或验收报告； 17. **AC-CLOSURE-DOC-01**：README 准确说明 Docker 优先、本地原生编译依赖、local/live 验收边界和实际发布状态； 18. **AC-CLOSURE-RELEASE-01**：全部验收通过后发布新的 SemVer，tag 与 main 发布 commit 一致，`v0.1.0` 保持原指向。