admin/isphere-ai-bridge
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
main
isphere-ai-bridge/docs/process/business-manager-review.md
zhaoyilun d773571402 docs: add offline evidence handoff plan
2026-07-06 20:46:49 +08:00

84 KiB
Raw Permalink Blame History

Business Manager Review

2026-07-05 执行前审批

  • 当前节点：N0 -> N1 执行前审批；本轮只允许做 N0/N1 验证，不进入 N2。
  • 本轮目标：
    • N0：确认项目方向已清理并锁定为 Go MCP + C# Helper；Python MCP 不作为活动路径；本轮不恢复 Python MCP。
    • N1：只运行 powershell -NoProfile -ExecutionPolicy Bypass -File scripts\verify-win-helper.ps1，验收 ok=true，并确认 C# helper 四个只读 op 可用：version / self_check / scan_windows / dump_uia。
    • 明确禁止：不写 Go 代码、不创建 go.mod、不改 C#、不提交新功能、不做搜索/发送/文件/自动登录/注入/hook/读内存/规避安防。
  • 业务判断：符合最终目标。先锁定 Go MCP + C# Helper 的边界，再验证既有 C# Helper 的只读能力，是进入 Go MCP 最小实现前必须完成的低风险前置动作，能够避免在基础能力不稳定时提前投入 Go 层开发。
  • 是否跑偏：未跑偏。本轮只做方向确认和 helper 基线验证，没有扩大到 Python MCP、Go 开发或业务自动化能力。
  • 是否过度设计：未过度设计。验收点集中在一个验证脚本和四个只读 op，范围足够小，符合最小闭环原则。
  • 是否遗漏：业务侧无关键遗漏。需注意执行阶段只能产出 N0/N1 的证据结论；即使 N1 通过，也只代表允许申请下一轮评审，不代表本轮可直接进入 N2。
  • 是否允许进入下一轮：允许进入本轮 N0/N1 验证执行；不批准进入 N2。
  • 业务经理结论：批准执行 N0/N1。执行人必须严格按本轮边界验证，不得新增实现、不恢复 Python MCP、不创建 Go 工程骨架。N1 通过后再提交下一轮进入 N2 的审批。

2026-07-05 N0/N1 终审

  • 当前节点：N0/N1 完成后的业务经理终审；评估是否允许下一轮进入 N2。
  • 本轮目标：
    • N0：确认项目方向锁定为 Go MCP + C# Windows Helper，排除 Python MCP 活动路径，确认 C# helper 文件存在且 Go/Python 工程骨架未提前出现。
    • N1：验证既有 C# helper 的四个只读 op：version / self_check / scan_windows / dump_uia，并确认验证脚本输出 ok=true、helper 位于 runs\win-helper\ISphereWinHelper.exe、version 为 0.1.0、scan_window_count 为数字、uia_available 为有效布尔字段。
    • 保持边界：本轮不得进入 N2，不得新增搜索联系人、打开会话、发送消息、发送文件、接收文件、自动登录、注入、hook、读内存、规避安防等能力。
  • 业务判断：通过本轮 N0/N1。N0 已证明方向和工作树边界符合“先 C# 只读 helper，后 Go MCP”的最小路径；N1 已证明 helper 基线可运行，四个只读能力具备继续被 Go 层包装的业务价值。pi 和 opencode 两轮审查均未发现阻塞项，非阻塞质量项不影响本轮基线通过。
  • 是否跑偏：未跑偏。执行结果停留在 N0/N1 范围内，未创建 go.mod，未启动 Go module skeleton，未恢复 Python MCP，未引入联系人搜索、会话打开、消息/文件收发、自动登录或底层绕过能力。
  • 是否过度设计：未过度设计。当前仍是一次性 C# CLI + 四个只读 op + PowerShell 验证脚本，没有常驻服务、HTTP、named pipe、gRPC、插件框架、selector 学习系统或多余依赖。opencode 提到的 timeout、--json、envelope、全局节点上限、编译警告属于后续质量补强，不构成本轮过度设计或返工理由。
  • 是否遗漏：无阻塞性业务遗漏。已覆盖本轮最关键的方向锁定、只读能力验证、边界确认和独立审查。需带入后续的非阻塞事项是：N2 只能做 Go module skeleton；后续 N3/N4 前再处理或明确 timeout、CLI 合约、响应 envelope、UIA 输出规模限制等质量项。
  • 是否允许进入下一轮：允许进入下一轮，但只允许推进 N2：Go module skeleton。N2 范围仅限确认 Go 工具链、创建最小 go.mod、模块名 isphere-ai-bridge、运行 go version 和 go list ./...；不得写 Go server、helper client、MCP tools，不得新增依赖，仍不得实现搜索/打开会话/发送/文件/自动登录/注入/hook/读内存/规避安防能力。
  • 业务经理结论：批准 N0/N1 通过；不要求返工；不停止项目。下一轮可以只推进 N2：Go module skeleton。N2 完成后必须再次提交审批，不能自动进入 N3 或更后节点。

2026-07-05 N2 执行前审批

  • 当前节点：第二轮执行前审批；仅评估是否允许进入本轮 N2：Go module skeleton，不评估、不批准 N3。
  • 本轮目标：
    • 确认 Go 工具链可用：运行 go version。
    • 创建最小 go.mod，module 名固定为 isphere-ai-bridge。
    • 运行 go list ./... 验证最小 Go module 可被 Go 工具链识别。
    • 更新 docs/process/go-implementation-log.md 记录 N2 执行证据。
    • 明确禁止：不创建 server code，不创建 cmd/isphere-mcp，不创建 internal/helperclient，不创建 MCP tool handlers，不添加 MCP 依赖，不改 C#，不恢复 Python MCP，不提前实现搜索联系人、打开会话、发送消息、发送/接收文件、自动登录、注入、hook、读内存、规避安防。
  • 业务判断：符合最终目标。N2 只是在 N0/N1 已通过后建立 Go MCP 路线的最小工程入口，交付价值是让后续 Go 协议契约、helper client、MCP server 有明确模块边界；当前不进入业务能力实现，风险低、范围清晰。
  • 是否跑偏：未跑偏。拟定动作与 N2 计划一致，只创建最小 go.mod 并做 Go 工具链验证，同时记录过程日志；没有进入 N3 的协议建模、N4 的 helper 调用、N7/N8 的 MCP server/tools，也没有扩展到真实业务动作。
  • 是否过度设计：未过度设计。本轮不引入依赖、不建目录框架、不写 server、不写 helper client、不做工具注册，只保留 Go module skeleton，符合最小闭环。
  • 是否遗漏：无阻塞性遗漏。N2 的关键前置是 N1 已通过，本轮已具备；关键验收是 go version、go list ./...、无 Python 文件、无额外依赖、无 server/tool 代码。执行人需把命令结果和文件边界写入 docs/process/go-implementation-log.md，并在失败时停止而不是扩大范围。
  • 是否允许进入下一轮：允许进入本轮 N2 执行；不允许进入 N3。N2 完成后必须再次提交审批，不能自动开始 Go helper protocol contract、helper process client 或 MCP server 工作。
  • 业务经理结论：批准本轮只执行 N2：Go module skeleton。不要求返工，不停止项目。执行范围仅限 Go 工具链确认、最小 go.mod、go list ./... 和 N2 过程日志；任何超出 N2 的代码、依赖、目录或业务能力都需另行审批。

2026-07-05 N2 终审

  • 当前节点：第二轮 N2 Go module skeleton 完成后的业务经理终审；评估 N2 是否通过，以及是否允许下一轮进入 N3。
  • 本轮目标：
    • 在 N0/N1 已通过的前提下，只建立 Go MCP 路线的最小 Go module skeleton。
    • 确认 Go 工具链可用：go version 输出 go version go1.23.4 windows/amd64。
    • 创建最小 go.mod，内容为 module isphere-ai-bridge、go 1.23，无 require。
    • 运行 go list ./...，输出 matched no packages warning 且退出码为 0，符合无 package 骨架阶段的验收条件。
    • 保持边界：不创建 cmd/isphere-mcp、internal/helperclient、internal/tools、go.sum、.go 文件，不改 C#，不恢复 Python MCP，不实现搜索联系人、打开会话、发送消息、发送/接收文件、自动登录、注入、hook、读内存、规避安防。
  • 业务判断：N2 通过。当前产物只解决“Go 工程入口是否可用”这个最小业务前置问题，为下一步 Go helper protocol contract 提供模块根；pi 和 opencode 两轮审查均确认无依赖、无 server/helper/tools 代码、无 N3 越界和无伪造验证，具备进入下一轮审批的条件。
  • 是否跑偏：未跑偏。执行内容停留在 N2：Go module skeleton，没有提前进入 N3 的协议结构体和测试，没有进入 N4 的 C# helper 进程调用，也没有进入 N7/N8 的 MCP server 或工具处理器，更没有进入 N12 的真实登录 UIA 捕获。
  • 是否过度设计：未过度设计。当前只有最小 go.mod，无 require、无 go.sum、无 Go 源码、无目录框架、无 MCP 依赖、无 server 空壳，符合“先建最小模块，再逐节点推进”的原则。
  • 是否遗漏：无阻塞性遗漏。N2 关键验收已覆盖：Go 工具链存在、module 名正确、go list ./... 退出码为 0、无 Python MCP、无 N3/N4/N8/N12 越界文件或能力。matched no packages warning 在 N2 无 package 阶段可接受；go.mod 未跟踪是待后续按精确路径提交的流程事项，不影响业务通过。
  • 是否允许进入下一轮：允许进入下一轮 N3，但只允许做 N3 Go helper protocol contract。N3 必须是纯 JSON contract 测试，只能围绕 isphere.helper.v1 的请求/响应/error/warnings 字段做 marshal/unmarshal 测试；不得真实启动 C# helper，不得实现 helper process client，不得进入 N4，不得创建 MCP server/tool handlers，不得进入 N8/N12，也不得批准搜索联系人、打开会话、发送消息、发送/接收文件、自动登录、注入、hook、读内存、规避安防。
  • 业务经理结论：批准 N2 通过；不要求返工；不停止项目。下一轮可以只推进 N3：Go helper protocol contract。N3 完成后必须再次提交业务终审，不能自动进入 N4 或更后节点。

2026-07-05 N3 执行前审批

  • 当前节点：第三轮执行前审批；仅评估是否允许进入本轮 N3：Go helper protocol contract，不评估、不批准 N4。
  • 本轮目标：
    • 在 N2 Go module skeleton 已通过的前提下，创建 internal/helperclient/contract.go 和 internal/helperclient/client_test.go。
    • 只做 isphere.helper.v1 的纯 JSON 协议建模，定义 HelperRequest / HelperResponse / HelperError。
    • 字段覆盖：protocol、request_id、op、timeout_ms、args、ok、data、error、warnings。
    • 通过契约测试验证：version request marshal 后 protocol="isphere.helper.v1"；success response unmarshal 后 ok=true 且 data.helper_name="ISphereWinHelper"；error response unmarshal 后 ok=false 且 error.code="WINDOW_NOT_FOUND"；unknown data fields 可保留为 map 或 raw JSON。
    • 运行 go test ./internal/helperclient -run Contract -v，并更新 docs/process/go-implementation-log.md 记录 N3 执行证据。
    • 明确禁止：不写 internal/helperclient/client.go，不启动真实 C# helper，不实现进程调用，不创建 MCP server 或 MCP tools，不添加 MCP 依赖或其他外部依赖，不改 C#，不恢复 Python MCP，不提前实现搜索联系人、打开会话、发送消息、发送/接收文件、自动登录、注入、hook、读内存、规避安防。
  • 业务判断：符合最终目标。N3 的交付价值是先把 Go 与 C# 之间的 isphere.helper.v1 数据契约固定下来，让后续 N4 进程调用有稳定输入输出模型；当前仍不触碰真实 helper、不触碰 UI、不触碰 MCP server 和业务动作，风险可控，顺序正确。
  • 是否跑偏：未跑偏。拟定动作与 N3 计划一致，只做协议结构和纯 JSON marshal/unmarshal 契约测试；没有进入 N4 的 helper process client，没有启动 C# helper，没有进入 N7/N8 的 MCP server/tools，也没有扩展到真实搜索、会话、消息或文件能力。
  • 是否过度设计：未过度设计。本轮只允许最小 contract 文件和契约测试，不引入外部依赖、不加 MCP 框架、不设计 server、不做抽象层扩张、不创建业务工具，符合“先契约、后进程调用”的最小闭环。
  • 是否遗漏：无阻塞性遗漏。N3 的关键前置是 N2 已通过且边界文档可用；关键验收是字段完整、成功/失败响应可解析、未知 data 字段可保留、测试为纯 JSON 且不真实启动 C# helper。执行人需在失败时停止并记录，不得用真实 helper 调用或 N4 代码来补救 N3 测试。
  • 是否允许进入下一轮：允许进入本轮 N3 执行；不允许进入 N4。N3 完成后必须再次提交审批，不能自动开始 helper process client、真实 helper 启动、MCP server、MCP tools 或任何业务动作能力。
  • 业务经理结论：批准本轮只执行 N3：Go helper protocol contract。不要求返工，不停止项目。执行范围仅限 isphere.helper.v1 纯 JSON contract 建模、契约测试和 N3 过程日志；任何超出 N3 的进程调用、依赖、server/tool 或真实业务能力都需另行审批。

2026-07-05 N3 终审

  • 当前节点：第三轮 N3 Go helper protocol contract 完成后的业务经理终审；评估 N3 是否通过，以及是否允许下一轮进入 N4。
  • 本轮目标：
    • 在 N2 已通过的前提下，只完成 isphere.helper.v1 的 Go 侧纯 JSON contract 建模。
    • 新增 internal/helperclient/contract.go 和 internal/helperclient/client_test.go，定义 HelperRequest / HelperResponse / HelperError。
    • 字段覆盖 protocol、request_id、op、timeout_ms、args、ok、data、error、warnings。
    • 用纯 JSON 测试验证 version request marshal、success response unmarshal、error response unmarshal、unknown data fields 保留。
    • 验证链路包含 Red：go test ./internal/helperclient -run Contract -v 因缺少结构体失败；Green：go test ./internal/helperclient -run Contract -v -count=1 通过；补充：go test ./... -count=1 通过。
    • 保持边界：不创建 internal/helperclient/client.go，不启动真实 C# helper，不实现进程调用，不创建 MCP server/tools，不添加外部依赖，不改 C#，不恢复 Python MCP，不实现搜索联系人、打开会话、发送消息、发送/接收文件、自动登录、注入、hook、读内存、规避安防。
  • 业务判断：N3 通过。当前交付把 Go 与 C# 的协议边界从文档落到了最小 Go contract 和纯 JSON 测试上，为 N4 的进程调用提供必要前置；pi 和 opencode 审查均确认 Contract 测试通过、unknown data 保留可信、无外部依赖、无 N4 越界和无真实 helper 启动，具备进入下一轮审批的条件。
  • 是否跑偏：未跑偏。执行内容停留在 N3 的协议建模和 marshal/unmarshal 测试，没有提前实现 client.go、helper 进程调用、路径解析、stdin/stdout、timeout、stderr 捕获，也没有创建 MCP server/tools，未跳到 N5/N8/N12。
  • 是否过度设计：未过度设计。当前仅有最小 contract 文件和契约测试，没有 client interface、mock helper 框架、MCP 抽象、server skeleton、审计/审批目录或额外依赖；符合“先固定 JSON contract，再做进程 client”的最小推进原则。
  • 是否遗漏：无阻塞性遗漏。N3 核心验收已覆盖：字段完整、version request protocol、success response 的 ok/helper_name、error response 的 WINDOW_NOT_FOUND、unknown data fields 保留、纯 JSON 测试且不启动 C# helper。opencode 提到的 timeout_ms marshal 断言、response envelope 断言属于后续可补强的 contract 质量项，不影响本轮业务通过；若补强，也只能在 contract 测试内补，不得借此进入 N4 之外能力。
  • 是否允许进入下一轮：允许进入下一轮 N4，但只允许做 N4 Go helper process client。N4 范围应限于 internal/helperclient/client.go、Client / Client.Call(ctx, op, args)、helper exe 路径解析、以 --json 启动 helper、stdin/stdout JSON、stderr 捕获、context timeout、missing helper / bad JSON / timeout / non-zero exit 的结构化错误，以及在 helper 已构建时 real version call 验证。仍不得做 MCP server/tools，不得进入 N5/N8/N12，不得搜索联系人、打开会话、发送消息、发送/接收文件、自动登录、注入、hook、读内存、规避安防。
  • 业务经理结论：批准 N3 通过；不要求返工；不停止项目。下一轮可以只推进 N4：Go helper process client。N4 完成后必须再次提交业务终审，不能自动进入 N5 或更后节点。

2026-07-05 N4 执行前审批

  • 当前节点：第四轮执行前审批；仅评估是否允许进入本轮 N4：Go helper process client，不评估、不批准 N5。
  • 本轮目标：
    • 在 N3 Go helper protocol contract 已通过、N1 C# helper 基线已验证的前提下，创建 internal/helperclient/client.go。
    • 在 internal/helperclient/client_test.go 增加 Client 测试。
    • 实现 Client 和 Client.Call(ctx, op, args)，让 Go 能以一次性进程方式调用 ISphereWinHelper.exe --json。
    • 只负责 helper exe 路径解析、以 --json 启动 helper、向 stdin 写 request JSON、读取 stdout、捕获 stderr、执行 context timeout、对 missing helper / timeout / bad JSON / non-zero exit 返回结构化 Go error。
    • 在 helper 已由 N1 构建的前提下，验证真实 helper 的 version 调用返回 ok=true。
    • 运行 go test ./internal/helperclient -run Client -v，可额外运行 go test ./... -count=1，并更新 docs/process/go-implementation-log.md 记录 N4 执行证据。
    • 明确禁止：不创建 MCP server，不创建 MCP tools，不修改 C# helper，不添加 MCP 依赖或其他外部依赖，不复制 C# UIA 逻辑到 Go，不点击/输入/发送/上传/下载，不提前实现搜索联系人、打开会话、发送消息、发送/接收文件、自动登录、注入、hook、读内存、规避安防。
  • 业务判断：符合最终目标。N4 的业务价值是把已通过的 Go JSON contract 与既有 C# helper 串成最小进程调用能力，为后续 live verification 和 MCP 包装打基础；当前仍不触碰 MCP server/tools，也不引入业务动作，只验证 helper 的只读 version 调用，边界清晰、风险可控。
  • 是否跑偏：未跑偏。拟定动作与 N4 计划一致，只做 Go 到 C# helper 的一次性 process client；没有进入 N5 的完整 live verification 节点，没有进入 N7/N8 的 MCP server/tools，没有做 UIA 业务逻辑复制，也没有扩展到搜索、会话、消息或文件能力。
  • 是否过度设计：未过度设计。本轮只允许 internal/helperclient 内的 process client 与对应测试，不允许新增依赖、MCP 框架、server skeleton、工具注册、审计/审批目录或长期驻留通信机制；符合一次性 CLI 调用的最小闭环。
  • 是否遗漏：无阻塞性遗漏。N4 关键验收应覆盖 missing helper、bad JSON、timeout、non-zero exit 的结构化错误，以及真实 helper version 返回 ok=true；还需确认 timeout 后不泄漏 helper 进程、不要求管理员权限、不默认写日志/文件、不复制 C# UIA 逻辑。执行人需在失败时停止并记录，不得通过扩大到 N5/MCP/server/tool 或真实业务动作来补救。
  • 是否允许进入下一轮：允许进入本轮 N4 执行；不允许进入 N5。N4 完成后必须再次提交审批，不能自动开始 Helper client live verification、MCP library decision、MCP server、MCP tools 或任何搜索/发送/文件/自动登录/注入/hook/读内存/规避安防能力。
  • 业务经理结论：批准本轮只执行 N4：Go helper process client。不要求返工，不停止项目。执行范围仅限 helper process client、Client 测试、真实 version 只读调用验证和 N4 过程日志；任何超出 N4 的 MCP、业务动作或系统底层能力都需另行审批。

2026-07-05 N4 终审

  • 当前节点：第四轮 N4 Go helper process client 完成后的业务经理终审；评估 N4 是否通过，以及是否允许下一轮进入 N5。
  • 本轮目标：
    • 在 N3 已通过、N1 C# helper 基线已验证的前提下，实现 Go helper process client。
    • 新增/修改 internal/helperclient/client.go 和 internal/helperclient/client_test.go，实现 Client 与 Client.Call(ctx, op, args)。
    • 只承担 helper exe 路径解析、以 --json 启动 helper、向 stdin 写入 request JSON、读取 stdout、捕获 stderr、执行 context timeout、对 missing helper / timeout / bad JSON / non-zero exit 返回结构化 Go error。
    • 验证真实 helper 的 version 调用，日志显示调用 runs\win-helper\ISphereWinHelper.exe 并返回 helper_name=ISphereWinHelper。
    • 验证链路包含 Red：go test ./internal/helperclient -run Client -v 因缺少 Client / errors 失败；Green：go test ./internal/helperclient -run Client -v -count=1 五个 Client 测试全部 PASS；补充：go test ./... -count=1 通过；go list -m all 仅有 isphere-ai-bridge。
    • 保持边界：未创建 MCP server/tools/cmd，未修改 C#，未添加依赖，未复制 C# UIA 逻辑，未实现搜索联系人、打开会话、发送消息、发送/接收文件、自动登录、注入、hook、读内存、规避安防。
  • 业务判断：N4 通过。当前交付把 N3 的 JSON contract 与 N1 的 C# helper 基线连接成最小 Go-to-C# 进程调用能力，且只验证只读 version 调用；pi 和 opencode 审查均确认真实 helper 调用不是 skip、Client 测试通过、timeout 后未发现残留进程、stderr 捕获已验证、无外部依赖、无 MCP 和业务动作越界，具备进入下一轮审批的条件。
  • 是否跑偏：未跑偏。执行内容停留在 N4 的 helper process client，没有提前进入 N5 的完整 live verification 节点，没有进入 N6 的 MCP library decision，没有创建 N8 的 MCP tools，也没有进入 N12 的真实登录 UIA 捕获；未扩展到点击、输入、搜索、会话、消息或文件能力。
  • 是否过度设计：未过度设计。当前仍是标准库进程调用和结构化错误处理，没有常驻 helper、HTTP、gRPC、named pipe、MCP 抽象、server skeleton、工具注册、审批/审计目录或额外框架；Client.Call 是通用 process client API，不是业务动作 API。
  • 是否遗漏：无阻塞性遗漏。N4 核心验收已覆盖：missing helper、bad JSON、timeout、non-zero exit/stderr、真实 helper version call、无进程残留、无管理员权限要求、无默认写日志/文件、无 UIA 逻辑复制。opencode 提到的 envelope/request id 校验、--json 和 stdin 请求内容更强断言、uuid-string 严格格式属于后续可补强质量项，不影响本轮业务通过；补强时仍不得扩大到 MCP 或业务动作能力。
  • 是否允许进入下一轮：允许进入下一轮 N5，但只允许做 N5 Helper client live verification。N5 范围只能运行 powershell -NoProfile -ExecutionPolicy Bypass -File scripts\verify-win-helper.ps1 和 go test ./internal/helperclient -v，确认 C# helper 单独通过、Go helper client 真实调用通过、测试输出包含真实 version call、且无 click/type/send/upload/download。N5 不写功能代码，不进入 N6，不做 MCP library decision，不创建 MCP server/tools，不进入 N8/N12，不批准搜索联系人、打开会话、发送消息、发送/接收文件、自动登录、注入、hook、读内存、规避安防。
  • 业务经理结论：批准 N4 通过；不要求返工；不停止项目。下一轮可以只推进 N5：Helper client live verification。N5 完成后必须再次提交业务终审，不能自动进入 N6 或更后节点。

2026-07-05 N5 执行前审批

  • 当前节点：第五轮执行前审批；仅评估是否允许进入本轮 N5：Helper client live verification，不评估、不批准 N6。
  • 本轮目标：
    • 在 N4 Go helper process client 已通过的前提下，做 Go-to-C# 的真实本机联调验证。
    • 运行 powershell -NoProfile -ExecutionPolicy Bypass -File scripts\verify-win-helper.ps1，确认 C# helper 单独验证退出 0。
    • 运行 go test ./internal/helperclient -v，确认 Go helperclient 测试退出 0。
    • 确认 Go 测试输出包含真实 version 调用，证明不是只靠 mock/stub 通过。
    • 确认验证过程没有点击、输入、发送、上传、下载等 UI 或业务动作。
    • 更新过程日志：至少更新 docs/process/go-implementation-log.md；如本轮重新参与并记录 C# helper 验证，则可更新 docs/process/csharp-helper-log.md。
    • 明确禁止：不写功能代码，不创建 MCP server/tools，不添加依赖，不改 C#，不进入 N6，不提前实现搜索联系人、打开会话、发送消息、发送/接收文件、自动登录、注入、hook、读内存、规避安防。
  • 业务判断：符合最终目标。N5 的业务价值是把 C# helper 单独可用和 Go helper client 可真实调用这两个事实做一次端到端验证，确保后续 MCP 选型和包装不是建立在 mock 或局部测试上；本轮只验证现有能力，不新增功能，风险低、边界清晰。
  • 是否跑偏：未跑偏。拟定动作与 N5 计划一致，只运行 PowerShell helper 验证和 Go helperclient 测试；没有进入 N6 的 MCP library decision，没有创建 MCP server/tools，也没有扩展到搜索、会话、消息、文件或真实 UI 操作能力。
  • 是否过度设计：未过度设计。本轮不写代码、不加依赖、不加脚本框架、不做 server/tool 设计，只做两条既定验证命令和过程日志，符合 live verification 的最小闭环。
  • 是否遗漏：无阻塞性遗漏。N5 关键验收已覆盖：PowerShell 验证退出 0、Go helperclient 测试退出 0、测试输出包含真实 version call、没有 click/type/send/upload/download。执行人还需在失败时停止并记录，不能通过修改功能代码、进入 N6 或扩大到 MCP/server/tool 来补救。
  • 是否允许进入下一轮：允许进入本轮 N5 执行；不允许进入 N6。N5 完成后必须再次提交审批，不能自动开始 MCP library decision、MCP server、MCP tools 或任何搜索/发送/文件/自动登录/注入/hook/读内存/规避安防能力。
  • 业务经理结论：批准本轮只执行 N5：Helper client live verification。不要求返工，不停止项目。执行范围仅限 PowerShell helper 验证、Go helperclient 测试、真实 version 调用确认和过程日志；任何超出 N5 的 MCP 选型、功能代码或业务动作都需另行审批。

2026-07-05 N5 终审

  • 当前节点：第五轮 N5 Helper client live verification 完成后的业务经理终审；评估 N5 是否通过，以及是否允许下一轮进入 N6。
  • 本轮目标：
    • 在 N4 已通过的前提下，只做 Go-to-C# 的真实本机联调验证，不写功能代码。
    • 运行 powershell -NoProfile -ExecutionPolicy Bypass -File scripts\verify-win-helper.ps1，确认 C# helper 单体验证退出 0，输出 ok=true、version 0.1.0、scan_window_count=30、uia_available=true。
    • 运行 go test ./internal/helperclient -v，确认 Go helperclient 测试退出 0 且输出 PASS。
    • 确认 Go 测试输出包含真实 helper version 调用：real helper version ok: helper_name=ISphereWinHelper path=...runs\win-helper\ISphereWinHelper.exe。
    • C# helper 验证仍只涉及 version / self_check / scan_windows / dump_uia 四个只读 op。
    • 保持边界：本轮只追加过程日志，未改 Go/C# 功能代码，未创建 MCP server/tools/cmd，未添加依赖，未进入 N6，未实现搜索联系人、打开会话、发送消息、发送/接收文件、自动登录、注入、hook、读内存、规避安防。
  • 业务判断：N5 通过。当前交付证明 C# helper 单体可用、Go helperclient 能真实调用已构建 helper，且不是只靠 mock/stub 通过；pi 和 opencode 审查均确认现场复跑通过、真实 helper 没有 skip、无 N6/N8 越界、无 MCP 依赖、无业务动作能力，具备进入下一轮审批的条件。
  • 是否跑偏：未跑偏。执行内容停留在 N5 live verification，没有开始 N6 的 MCP library decision，没有创建 N7 的 MCP server skeleton，没有创建 N8 的 MCP tools，也没有进入 N12 的真实登录 UIA 捕获；验证过程未扩展到点击、输入、搜索、会话、消息、文件、自动登录或底层绕过能力。
  • 是否过度设计：未过度设计。本轮只运行既定 PowerShell helper 验证和 Go helperclient 测试，并追加过程日志；没有新增依赖、脚本框架、MCP 方案、server/tool 设计、常驻服务或额外抽象。
  • 是否遗漏：无阻塞性遗漏。N5 核心验收已覆盖：PowerShell helper 验证退出 0、Go helperclient 测试退出 0、Go 测试输出包含真实 version call、C# helper 单体验证覆盖四个只读 op、无 click/type/send/upload/download。go test ./... 和 go list -m all 的补充复核也显示 Go 测试通过且无外部依赖；工作树未提交属于流程提交事项，不影响业务通过。
  • 是否允许进入下一轮：允许进入下一轮 N6，但只允许做 N6 MCP library decision。N6 只能选择一个 Go MCP 方案或明确最小 stdio 实现，并回答 package/module name、stdio support、tool registration style、JSON schema support、maintenance risk、why enough for four tools；可以产生短决策记录或依计划记录在实现提交中，但不得写 server，不得注册工具，不得创建 MCP tools，不得进入 N7/N8/N12，不得批准搜索联系人、打开会话、发送消息、发送/接收文件、自动登录、注入、hook、读内存、规避安防。
  • 业务经理结论：批准 N5 通过；不要求返工；不停止项目。下一轮可以只推进 N6：MCP library decision。N6 完成后必须再次提交业务终审，不能自动进入 N7 或更后节点。

2026-07-05 N6 执行前审批

  • 当前节点：第六轮执行前审批；仅评估是否允许进入本轮 N6：MCP library decision，不评估、不批准 N7。
  • 本轮目标：
    • 在 N5 Helper client live verification 已通过的前提下，选择 Go MCP server 的技术方案，但不写 server 代码。
    • 评估一个 Go MCP 官方 SDK/库方案，或明确选择最小 stdio 方案。
    • 必须记录决策字段：package/module name、stdio support、tool registration style、JSON schema support、maintenance risk、why this is enough for four tools。
    • 允许使用官方来源和 Go module 命令做核验；已核验资料显示 github.com/modelcontextprotocol/go-sdk 为官方 Go SDK，具备 mcp.NewServer、mcp.AddTool、mcp.StdioTransport 等能力，pkg.go.dev 也显示支持 client/server、Transport、StdioTransport、AddTool 自动 schema，本机 Go 为 go1.23.4 windows/amd64，且 go list -m -versions github.com/modelcontextprotocol/go-sdk 可访问版本。
    • 如果选择外部 SDK，只允许添加对应 Go module 依赖；如果选择最小 stdio，则不加依赖。
    • 运行 go list -m all 做验收，并更新 docs/process/go-implementation-log.md；如确需短决策文档，可以创建极小文档，但不得创建大型架构文档。
    • 明确禁止：不写 server code，不创建 cmd/isphere-mcp，不创建 internal/mcpserver 或 internal/tools，不注册工具，不调用 C# helper，不进入 N7，不提前实现搜索联系人、打开会话、发送消息、发送/接收文件、自动登录、注入、hook、读内存、规避安防。
  • 业务判断：符合最终目标。N6 的业务价值是在写 MCP server 前先定清楚唯一 MCP 技术路线，避免后续同时引入多个框架或临时拼接协议；当前只做选型和依赖边界确认，不实现服务、不注册工具、不触碰业务动作，风险可控，顺序正确。
  • 是否跑偏：未跑偏。拟定动作与 N6 计划一致，只做 MCP library decision；没有进入 N7 的 Go MCP server skeleton，没有创建 N8 的 tools，也没有进入 N12 的真实登录 UIA 捕获；不调用 C# helper，不扩大到搜索、会话、消息或文件能力。
  • 是否过度设计：未过度设计。本轮只允许选择一个方案或最小 stdio，并记录短决策；不允许大型架构文档、多框架并行、server 空壳、工具注册、审批/审计抽象或额外业务层。若选官方 SDK，只允许必要 module 依赖；若选最小 stdio，则保持无依赖。
  • 是否遗漏：无阻塞性遗漏。N6 关键验收应覆盖：明确唯一方案、说明 stdio 支持、说明工具注册方式、说明 JSON schema 支持、说明维护风险、说明为什么足够四个只读工具，并用 go list -m all 证明只有一个 MCP 相关依赖或无外部 MCP 依赖。执行人需在发现 Windows 不可构建、强制后台 daemon、HTTP-only、或多个 MCP 包混入时停止并记录，不得通过直接写 server 或 tools 来绕过选型。
  • 是否允许进入下一轮：允许进入本轮 N6 执行；不允许进入 N7。N6 完成后必须再次提交审批，不能自动开始 Go MCP server skeleton、tool registration、MCP handlers、C# helper 调用或任何搜索/发送/文件/自动登录/注入/hook/读内存/规避安防能力。
  • 业务经理结论：批准本轮只执行 N6：MCP library decision。不要求返工，不停止项目。执行范围仅限 MCP 方案评估、唯一方案记录、必要依赖边界和 go list -m all 验收；任何超出 N6 的 server、tools、业务动作或底层能力都需另行审批。

2026-07-05 N6 终审

  • 当前节点：第六轮 N6 MCP library decision 完成后的业务经理终审；评估 N6 是否通过，以及是否允许下一轮进入 N7。
  • 本轮目标：
    • 在 N5 已通过的前提下，只完成 Go MCP 技术方案选型，不写 server code，不注册工具。
    • 选择官方 Go MCP SDK：module github.com/modelcontextprotocol/go-sdk v1.3.1，package github.com/modelcontextprotocol/go-sdk/mcp。
    • 不选择 v1.6.1 或 pre-release：本机为 go1.23.4 windows/amd64，v1.6.1 要求 go 1.25.0，当前节点不升级工具链。
    • 已记录决策字段：package/module name、stdio support、tool registration style、JSON schema support、maintenance risk、why enough for four tools。
    • 已用 go doc 验证 mcp.StdioTransport、mcp.AddTool、mcp.NewServer 可用；已用 go list -m all 验证只有一个 MCP-related dependency。
    • 产物集中在 docs/go-mcp-library-decision.md、go.mod、go.sum、docs/process/go-implementation-log.md；未写 server code，未创建 cmd/isphere-mcp、internal/mcpserver、internal/tools，未注册工具，未调用 C# helper，未修改 C#。
  • 业务判断：N6 通过。当前交付把后续 MCP server 的技术路线固定为官方 Go SDK 的一个兼容版本，且明确了 stdio、typed tool registration、JSON schema 和维护风险；pi 与 opencode 审查均确认字段完整、go test ./... 通过、go.sum 只含 SDK v1.3.1、无 N7/N8 越界、无 C# 或脚本修改，具备进入下一轮审批的条件。
  • 是否跑偏：未跑偏。执行内容停留在 N6 library decision，没有创建 N7 的 server skeleton，没有创建 N8 的 tools，没有进入 N9 smoke verification 或 N12 真实登录 UIA 捕获；也没有调用 C# helper、注册工具或扩展到搜索、会话、消息、文件、自动登录或底层绕过能力。
  • 是否过度设计：未过度设计。只选择一个官方 SDK 版本并创建极小决策文档，没有多 MCP 框架并行、HTTP/gRPC/named pipe、后台 daemon、server 目录、tools 目录、审批/审计抽象或大型架构文档。SDK 的传递依赖来自官方 module graph，不等于引入第二套 MCP 方案。
  • 是否遗漏：无阻塞性遗漏。N6 核心验收已覆盖：唯一 MCP 方案、stdio support、tool registration style、JSON schema support、maintenance risk、四个工具适配理由、go list -m all 验收、Windows Go 版本兼容判断、未引入 HTTP-only/daemon/Python/Node 路径。go.mod 中 SDK 暂为 indirect 是因为 N6 不允许写 import，后续 N7/N8 首次使用时可自然调整，不影响业务通过。
  • 是否允许进入下一轮：允许进入下一轮 N7，但只允许做 N7 Go MCP server skeleton。N7 范围应限于创建 cmd/isphere-mcp/main.go，必要时创建极小 internal/mcpserver/server.go，让 Go binary 可以构建并以 stdio server 方式启动；不得注册四个真实 tools，除非 SDK 强制必须有工具时也应尽量避免真实 handler 并保持 placeholder-free；不得进入 N8，不得创建 internal/tools，不得调用 C# helper，不得进入 N9/N12，不得批准搜索联系人、打开会话、发送消息、发送/接收文件、自动登录、注入、hook、读内存、规避安防。
  • 业务经理结论：批准 N6 通过；不要求返工；不停止项目。下一轮可以只推进 N7：Go MCP server skeleton。N7 完成后必须再次提交业务终审，不能自动进入 N8 或更后节点。

2026-07-05 N7 执行前审批

  • 当前节点：第七轮执行前审批；仅评估是否允许进入本轮 N7：Go MCP server skeleton，不评估、不批准 N8。
  • 本轮目标：
    • 在 N6 MCP library decision 已通过的前提下，使用已选定的官方 Go MCP SDK 创建最小 MCP stdio server skeleton。
    • 创建 cmd/isphere-mcp/main.go。
    • 可选创建 internal/mcpserver/server.go 和极小 server construction 测试，前提是为了保持 main.go 小且可测。
    • 使用 N6 选定 SDK 构造 MCP server，并支持 stdio mode 启动。
    • 运行 go test ./... 和 go build ./cmd/isphere-mcp。
    • 明确禁止：不注册四个真实 win_helper_* tools，不创建 internal/tools，不调用 C# helper，不实现 tool handlers，不进入 N8，不新增第二个 MCP SDK，不恢复 Python MCP，不提前实现搜索联系人、打开会话、发送消息、发送/接收文件、自动登录、注入、hook、读内存、规避安防。
  • 业务判断：符合最终目标。N7 的业务价值是把 N6 选定的 MCP SDK 落成一个可构建、可启动的最小 stdio server 壳，为后续 N8 注册四个只读工具做运行入口；当前仍不暴露工具、不调用 helper、不触碰业务动作，边界清晰、顺序正确。
  • 是否跑偏：未跑偏。拟定动作与 N7 计划一致，只做 server skeleton 和构建验证；没有进入 N8 的工具注册和 tool handler，没有调用 C# helper，没有进入 N9 smoke verification 或 N12 真实登录 UIA 捕获，也没有扩展到搜索、会话、消息、文件、自动登录或底层绕过能力。
  • 是否过度设计：未过度设计。本轮只允许最小 cmd/isphere-mcp/main.go，可选极小 internal/mcpserver/server.go 和 construction 测试；不允许第二个 MCP SDK、HTTP/gRPC/named pipe、后台 daemon、工具目录、审批/审计抽象、大型架构文档或业务工具层。
  • 是否遗漏：无阻塞性遗漏。N7 关键验收应覆盖：go test ./... 通过、go build ./cmd/isphere-mcp 通过、server 以 stdio mode 为目标、不需要 Python runtime、不在简单 server construction 测试中启动 C# helper、不启动 HTTP listener。若 SDK 强制必须有工具，应尽量不注册真实工具，且不得实现真实 handler 或进入 N8。
  • 是否允许进入下一轮：允许进入本轮 N7 执行；不允许进入 N8。N7 完成后必须再次提交审批，不能自动开始四个真实 tool 注册、internal/tools、helper handler、Go-to-C# tool 调用、MCP smoke verification 或任何搜索/发送/文件/自动登录/注入/hook/读内存/规避安防能力。
  • 业务经理结论：批准本轮只执行 N7：Go MCP server skeleton。不要求返工，不停止项目。执行范围仅限 MCP stdio server skeleton、可选极小 server construction 测试、go test ./... 和 go build ./cmd/isphere-mcp；任何超出 N7 的 tools、helper 调用、N8/N9/N12 或业务动作都需另行审批。

2026-07-05 N7 终审

  • 当前节点：第七轮 N7 Go MCP server skeleton 完成后的业务经理终审；评估 N7 是否通过，以及是否允许下一轮进入 N8。
  • 本轮目标：
    • 在 N6 已通过的前提下，只创建最小 Go MCP stdio server skeleton。
    • 新增/修改 cmd/isphere-mcp/main.go、internal/mcpserver/server.go、internal/mcpserver/server_test.go、go.mod、go.sum 和 Go 过程日志。
    • 使用 N6 选定的官方 Go MCP SDK 构造空 MCP server，并以 stdio mode 作为启动方式。
    • Red：go test ./internal/mcpserver -v 因 undefined: NewServer 失败；Green：go test ./internal/mcpserver -v -count=1 PASS；go test ./... -count=1 PASS；go build ./cmd/isphere-mcp PASS，临时 exe 已删除。
    • 保持边界：未创建 internal/tools，无 AddTool / tool registration，无 helperclient import，未调用 C# helper，未改 C#，未新增第二套 MCP 框架，未实现搜索联系人、打开会话、发送消息、发送/接收文件、自动登录、注入、hook、读内存、规避安防。
  • 业务判断：N7 通过。当前交付把 N6 选定的 MCP SDK 落成了可测试、可构建的最小 stdio server 壳，为后续 N8 注册四个只读 WinHelper tools 提供入口；pi 和 opencode 审查均确认测试/build 通过、无 N8 越界、无 helper 启动、无 HTTP/gRPC/named pipe/Python runtime、无第二套 MCP 框架，具备进入下一轮审批的条件。
  • 是否跑偏：未跑偏。执行内容停留在 N7 server skeleton，没有注册四个真实 win_helper_* tools，没有创建 internal/tools，没有实现 tool handlers，没有调用 C# helper，没有进入 N9 smoke verification 或 N12 真实登录 UIA 捕获，也没有扩展到搜索、会话、消息、文件、自动登录或底层绕过能力。
  • 是否过度设计：未过度设计。当前只有 cmd/isphere-mcp 和极小 internal/mcpserver，测试只验证空 server 可构造；没有业务 tool 层、HTTP listener、gRPC、named pipe、后台 daemon、审批/审计抽象、复杂配置系统、大型架构文档或第二套 MCP 框架。go.mod/go.sum 的变化属于首次 import SDK 后的必要 module 元数据，不构成过度设计。
  • 是否遗漏：无阻塞性遗漏。N7 核心验收已覆盖：go test ./... 通过、go build ./cmd/isphere-mcp 通过、server 面向 stdio mode、不需要 Python runtime、简单 server construction 测试不启动 C# helper、不启动 HTTP listener、构建产物已清理。go test ./... 包含既有 helperclient 测试可能触发真实 helper version，这不影响 N7 专项 server construction 边界；后续如需验证 server metadata，可在不进入工具注册的前提下补强。
  • 是否允许进入下一轮：允许进入下一轮 N8，但只能做四个只读 MCP tool handlers：win_helper_version、win_helper_self_check、win_helper_scan_windows、win_helper_dump_uia。N8 必须只创建/维护 internal/tools 相关 tool definitions 和测试，tool handlers 只能通过 internal/helperclient 调用 helper op，不得新增第五个工具，不得实现搜索联系人、打开会话、发送消息、发送/接收文件、自动登录、注入、hook、读内存、规避安防，不得进入 N9/N12。
  • 业务经理结论：批准 N7 通过；不要求返工；不停止项目。下一轮可以只推进 N8：Four read-only MCP tool handlers。N8 完成后必须再次提交业务终审，不能自动进入 N9 或更后节点。

2026-07-05 N8 执行前审批

  • 当前节点：第八轮执行前审批；仅评估是否允许进入本轮 N8：Four read-only MCP tool handlers，不评估、不批准 N9。
  • 本轮目标：
    • 在 N7 Go MCP server skeleton 已通过、internal/helperclient 已通过的前提下，创建 internal/tools/winhelper.go 和 internal/tools/winhelper_test.go。
    • 注册且只注册四个只读 MCP tools：win_helper_version、win_helper_self_check、win_helper_scan_windows、win_helper_dump_uia。
    • 工具映射必须固定为：win_helper_version -> version，win_helper_self_check -> self_check，win_helper_scan_windows -> scan_windows，win_helper_dump_uia -> dump_uia。
    • handlers 必须通过 internal/helperclient 调用，不得直接做 UIA、窗口枚举、控件树遍历或其他 Windows 操作逻辑。
    • schema 参数只允许：scan 使用 include_all_visible；dump 使用 hwnd、max_depth、include_text、max_children；version/self_check 不应引入业务动作参数。
    • 运行 go test ./internal/tools -v 和 go test ./...。
    • 明确禁止：不添加第五个工具，不实现搜索联系人、打开会话、发送消息、发送文件、接收文件，不自动登录，不注入、不 hook、不读内存、不规避安防，不让 handler 点击、输入、发送、上传、下载或编辑文件，不绕过 internal/helperclient，不进入 N9。
  • 业务判断：符合最终目标。N8 的业务价值是把前期已验证的 C# helper 四个只读 op 暴露为 MCP 工具，形成第一阶段最小可用工具面；范围限定为四个只读能力，且通过 helperclient 统一调用，能保持 Go/C# 分层和后续审计边界。
  • 是否跑偏：未跑偏。拟定动作与 N8 计划一致，只做四个只读 WinHelper MCP tools；没有进入 N9 smoke verification，没有进入 N12 真实登录 UIA 捕获，也没有扩展到联系人搜索、会话打开、消息/文件收发、自动登录或底层绕过能力。
  • 是否过度设计：未过度设计。本轮只允许一个 internal/tools 包和对应测试，不允许第五个工具、业务动作工具、独立 UIA/窗口逻辑、第二套 MCP SDK、额外服务框架、审批/审计大框架或复杂抽象；四个工具正好对应已验证的四个只读 helper op。
  • 是否遗漏：无阻塞性遗漏。N8 关键验收应覆盖：注册工具数量恰好为四个、工具名完全匹配、tool schema 只包含允许参数、handler 映射到正确 helper op、handler 通过 internal/helperclient 调用、没有 send/search/file 工具、没有点击/输入/发送/上传/下载/编辑文件行为。执行人需在发现第五个工具、直接 UIA 逻辑或绕过 helperclient 时停止并记录。
  • 是否允许进入下一轮：允许进入本轮 N8 执行；不允许进入 N9。N8 完成后必须再次提交审批，不能自动开始 MCP stdio smoke verification、scripts/verify-go-mcp.ps1、真实 MCP client 调用、N12 真实登录 UIA 捕获或任何搜索/发送/文件/自动登录/注入/hook/读内存/规避安防能力。
  • 业务经理结论：批准本轮只执行 N8：Four read-only MCP tool handlers。不要求返工，不停止项目。执行范围仅限四个只读 tool definitions/handlers、internal/tools 测试、go test ./internal/tools -v 和 go test ./...；任何超出 N8 的第五工具、业务动作、N9/N12 或底层能力都需另行审批。

2026-07-05 N8 终审

  • 当前节点：第八轮 N8 Four read-only MCP tool handlers 完成后的业务经理终审；评估 N8 是否通过，以及是否允许下一轮进入 N9。
  • 本轮目标：
    • 在 N7 已通过的前提下，只创建四个只读 WinHelper MCP tool handlers。
    • 新增/修改 internal/tools/winhelper.go、internal/tools/winhelper_test.go，并接入 internal/mcpserver/server.go / server_test.go。
    • 只注册四个工具：win_helper_version、win_helper_self_check、win_helper_scan_windows、win_helper_dump_uia。
    • 工具映射固定为：win_helper_version -> version、win_helper_self_check -> self_check、win_helper_scan_windows -> scan_windows、win_helper_dump_uia -> dump_uia。
    • handler 通过 HelperCaller / internal/helperclient 调用，不直接实现 UIA、WindowScanner、UiaDumper、user32、FindWindow、SendKeys 等窗口或控件逻辑。
    • schema 范围符合计划：version/self_check 无业务参数；scan 只有 include_all_visible；dump 只有 hwnd、max_depth、include_text、max_children。
    • Red：tools 测试因 undefined 实现失败，mcpserver WinHelper 测试因空工具名失败；Green：go test ./internal/tools -v -count=1 PASS，go test ./... -count=1 PASS。
    • 保持边界：未创建 N9 script，未新增第五个工具，未实现 search/open/send/file/login，未修改 C# 或脚本，未实现点击、输入、发送、上传、下载、编辑文件、注入、hook、读内存、规避安防。
  • 业务判断：N8 通过。当前交付把前期已验证的四个 C# helper 只读 op 暴露成 MCP 工具，形成第一阶段最小工具面；pi 和 opencode 审查均确认工具数量、名称、op 映射、schema 参数和 helperclient 调用链符合计划，现场测试通过，且无第五工具、无直接 UI 操作、无 N9 越界，具备进入下一轮审批的条件。
  • 是否跑偏：未跑偏。执行内容停留在 N8 四个只读 tool handlers，没有创建 scripts/verify-go-mcp.ps1，没有进入 N9 smoke verification，没有进入 N10 runbook 或 N12 真实登录 UIA 捕获；也没有扩展到联系人搜索、会话打开、消息/文件收发、自动登录或底层绕过能力。
  • 是否过度设计：未过度设计。当前只新增 internal/tools 和必要的 mcpserver 接入测试，没有第五个工具、业务动作工具、独立 UIA/窗口逻辑、第二套 MCP SDK、额外服务框架、审批/审计大框架或复杂抽象；四个工具正好对应第一阶段四个只读 helper op。
  • 是否遗漏：无阻塞性遗漏。N8 核心验收已覆盖：工具数量恰好四个、工具名完全匹配、schema 只含允许参数、handler 映射到正确 helper op、handler 通过 internal/helperclient 调用、没有 send/search/file 工具、没有点击/输入/发送/上传/下载/编辑文件行为。真实 MCP stdio smoke 和真实 win_helper_version 通过 MCP 返回 ISphereWinHelper 是 N9 范围，不构成本轮遗漏。
  • 是否允许进入下一轮：允许进入下一轮 N9，但只能做 MCP stdio smoke verification。N9 可创建 scripts/verify-go-mcp.ps1，用于构建 C# helper、构建 Go MCP binary、通过 stdio 或 SDK test harness 列出 tools、确认四个工具存在、至少调用 win_helper_version 并确认返回 ISphereWinHelper；不得实现新工具，不得新增第五个工具，不得加入搜索/会话/发送/文件/自动登录/注入/hook/读内存/规避安防能力，不得进入 N10/N12。
  • 业务经理结论：批准 N8 通过；不要求返工；不停止项目。下一轮可以只推进 N9：MCP stdio smoke verification。N9 完成后必须再次提交业务终审，不能自动进入 N10 或更后节点。

2026-07-05 N9 执行前审批

  • 当前节点：第九轮执行前审批；仅评估是否允许进入本轮 N9：MCP stdio smoke verification，不评估、不批准 N10。
  • 本轮目标：
    • 在 N8 Four read-only MCP tool handlers 已通过的前提下，只做 MCP stdio smoke verification。
    • 创建 scripts/verify-go-mcp.ps1，作为可重复本地验证命令。
    • 脚本自动构建 C# helper，自动构建 Go MCP binary。
    • 脚本通过 MCP stdio 或 SDK/test harness 自动 list tools，确认四个工具存在且仅限当前阶段四个工具。
    • 至少调用 win_helper_version，确认返回 ISphereWinHelper。
    • 输出包含 {"ok":true} 或等价 JSON 成功结果。
    • 运行 powershell -NoProfile -ExecutionPolicy Bypass -File scripts\verify-go-mcp.ps1，并更新过程日志。
    • 明确禁止：不实现新工具，不改四个 tool handlers 的业务范围，不实现搜索、发送、文件、自动登录、注入、hook、读内存，不需要真实 iSphere 登录，不进入 N10。
  • 业务判断：符合最终目标。N9 的业务价值是把 N7 的 stdio server 壳和 N8 的四个只读工具做一次自动化烟测，证明二进制能通过 MCP 通道暴露预期工具并调用最小只读 version 能力；当前只验证已有能力，不新增业务功能，边界清晰、风险可控。
  • 是否跑偏：未跑偏。拟定动作与 N9 计划一致，只创建并运行 smoke verification 脚本；没有进入 N10 runbook/process scripts，没有进入 N12 真实登录 UIA 捕获，也没有扩展到搜索、会话、发送、文件、自动登录或底层绕过能力。
  • 是否过度设计：未过度设计。本轮只允许一个验证脚本和过程日志，不允许新增工具、改 handler 范围、引入第二套 MCP 框架、创建复杂测试平台、要求人工交互或真实 iSphere 登录；构建 helper 和 Go binary、list tools、调用 win_helper_version 已足够验证当前阶段交付。
  • 是否遗漏：无阻塞性遗漏。N9 关键验收应覆盖：脚本退出 0、输出 ok=true 或等价 JSON、四个工具名存在且无第五工具、win_helper_version 返回 ISphereWinHelper、无需真实 iSphere 登录、无 message/file/search action、验证不需要手工交互、无需 Python。执行人若发现 tool listing 不能自动化、验证需要手动操作、或 C# helper/Go MCP 任一构建失败，应停止并记录，不能通过新增工具或扩大业务动作来补救。
  • 是否允许进入下一轮：允许进入本轮 N9 执行；不允许进入 N10。N9 完成后必须再次提交审批，不能自动开始 operator runbook、README 更新、N12 真实登录 UIA 捕获、搜索/发送/文件/自动登录/注入/hook/读内存/规避安防能力。
  • 业务经理结论：批准本轮只执行 N9：MCP stdio smoke verification。不要求返工，不停止项目。执行范围仅限 scripts/verify-go-mcp.ps1、自动构建/列工具/调用 win_helper_version、成功 JSON 输出和过程日志；任何超出 N9 的新工具、业务动作、N10/N12 或底层能力都需另行审批。

2026-07-05 N9 终审

  • 当前节点：第九轮 N9 MCP stdio smoke verification 完成后的业务经理终审；评估 N9 是否通过，以及是否允许下一轮进入 N10。
  • 本轮目标：
    • 在 N8 已通过的前提下，只做 MCP smoke verification，不新增工具、不扩展业务能力。
    • 创建 scripts/verify-go-mcp.ps1。
    • 脚本构建 C# helper，构建 Go MCP binary，并通过官方 Go MCP SDK harness 自动执行 initialize/connect、tools/list、tools/call win_helper_version。
    • 脚本执行 powershell -NoProfile -ExecutionPolicy Bypass -File scripts\verify-go-mcp.ps1 退出 0。
    • 输出包含 C# helper 构建成功、Go MCP binary 构建成功、ok=true、helper_name=ISphereWinHelper、tool_count=4、四个工具名、python_runtime_required=false、real_isphere_login_required=false、action_tools_present=false。
    • 保持边界：未进入 N10，无 runbook；未实现新工具；未修改四个 tool handlers 的业务范围；未实现搜索、发送、文件、自动登录、注入、hook、读内存；不需要真实 iSphere 登录。
  • 业务判断：N9 通过。当前交付提供了可重复的 Go MCP 验证脚本，能证明 C# helper 可构建、Go MCP binary 可构建、MCP 层可列出四个工具并调用最小只读 win_helper_version 返回 ISphereWinHelper；pi 和 opencode 审查均确认脚本不是裸硬编码 ok=true，有工具名、tool_count、helper_name 和 action tools 断言，无 N10 runbook 和业务动作越界，具备进入下一轮审批的条件。
  • 是否跑偏：未跑偏。执行内容停留在 N9 smoke verification，没有创建 docs/go-mcp-runbook.md 或 README runbook 内容，没有进入 N10/N11/N12；也没有新增工具、改变 handler 范围、要求真实 iSphere 登录、扩展到搜索/会话/发送/文件/自动登录或底层绕过能力。
  • 是否过度设计：未过度设计。本轮只新增一个验证脚本和过程日志，脚本使用计划允许的 SDK/test harness 路径完成 initialize/list/call 验证；没有新增服务、daemon、HTTP/gRPC/named pipe、第二套 MCP 框架、复杂验证平台或运行手册。PowerShell 直接 stdio 的 BOM 问题通过计划允许的 harness 路径解决，不构成过度设计。
  • 是否遗漏：无阻塞性遗漏。N9 核心验收已覆盖：脚本退出 0、输出成功 JSON、四个工具名存在且 tool_count=4、win_helper_version 返回 ISphereWinHelper、无需真实 iSphere 登录、无需 Python、无 message/file/search action。pi/opencode 未复跑完整脚本是因为只读审查约束避免创建临时构建产物，属于非阻塞观察；实现日志已记录完整脚本 green 执行证据。
  • 是否允许进入下一轮：允许进入下一轮 N10，但只允许做 Operator runbook and process scripts。N10 可创建 docs/go-mcp-runbook.md，必要时更新 README；内容应覆盖构建 C# helper、验证 C# helper、构建 Go MCP、验证 Go MCP、配置 MCP client command、允许工具、明确非目标、真实登录 UIA capture procedure。不得实现新功能，不得新增工具，不得进入 N11/N12，不得实现搜索联系人、打开会话、发送消息、发送/接收文件、自动登录、注入、hook、读内存、规避安防。
  • 业务经理结论：批准 N9 通过；不要求返工；不停止项目。下一轮可以只推进 N10：Operator runbook and process scripts。N10 完成后必须再次提交业务终审，不能自动进入 N11 或更后节点。

2026-07-05 N10 执行前审批

  • 当前节点：第十轮执行前审批；仅评估是否允许进入本轮 N10：Operator runbook and process scripts，不评估、不批准 N11。
  • 本轮目标：
    • 在 N9 MCP stdio smoke verification 已通过的前提下，只创建操作者运行手册和必要过程说明，让人类操作者不用读代码也能运行第一阶段工具。
    • 创建 docs/go-mcp-runbook.md。
    • 仅在确有必要时更新 README.md，不得把 README 扩成大型文档。
    • Runbook 必须包含：Build C# helper、Verify C# helper、Build Go MCP、Verify Go MCP、Configure MCP client command、Allowed tools、Explicit non-goals、Real-login UIA capture procedure。
    • Runbook 必须包含 exact commands：powershell -NoProfile -ExecutionPolicy Bypass -File scripts\verify-win-helper.ps1、go test ./...、go build ./cmd/isphere-mcp、powershell -NoProfile -ExecutionPolicy Bypass -File scripts\verify-go-mcp.ps1。
    • Runbook 必须明确边界：no login automation、no send message、no send file、no receive/download file、no process injection、no hook、no memory reading。
    • 更新过程日志。
    • 明确禁止：不实现新功能，不改 MCP tool handlers，不新增工具，不进入 N11，不真实采集 iSphere 登录数据，不实现搜索、发送、文件、自动登录、注入、hook、读内存。
  • 业务判断：符合最终目标。N10 的业务价值是把已经验证通过的 C# helper、Go MCP binary、四个只读工具和验证脚本整理成可操作手册，降低交付使用门槛；当前只做文档化和边界说明，不新增能力，风险低、交付价值明确。
  • 是否跑偏：未跑偏。拟定动作与 N10 计划一致，只创建 runbook 和必要 README 摘要；没有进入 N11 commit/review checkpoint，没有进入 N12 真实登录 UIA 捕获，也没有实现搜索、发送、文件、自动登录或底层绕过能力。
  • 是否过度设计：未过度设计。本轮只允许一个操作 runbook 和必要 README 更新，不允许大型架构文档、额外脚本框架、功能代码、工具扩展或真实采集；手册内容聚焦构建、验证、配置、允许工具、非目标和后续真实登录 UIA 捕获流程。
  • 是否遗漏：无阻塞性遗漏。N10 关键验收应覆盖四条 exact commands、四个允许工具、明确 non-goals、MCP client command 配置、真实登录 UIA capture procedure，以及 no login automation/no send message/no send file/no receive/download file/no process injection/no hook/no memory reading 等边界。若 runbook 暗示 Python MCP 必需、暗示已支持发送、或遗漏未来发送审批边界，应停止并修正。
  • 是否允许进入下一轮：允许进入本轮 N10 执行；不允许进入 N11。N10 完成后必须再次提交审批，不能自动开始 commit/review checkpoint、N12 真实登录 UIA 捕获、搜索/发送/文件/自动登录/注入/hook/读内存/规避安防能力。
  • 业务经理结论：批准本轮只执行 N10：Operator runbook and process scripts。不要求返工，不停止项目。执行范围仅限 docs/go-mcp-runbook.md、必要 README 更新和过程日志；任何超出 N10 的功能代码、工具扩展、真实采集、N11/N12 或底层能力都需另行审批。

2026-07-05 N10 终审

  • 当前节点：第十轮 N10 Operator runbook and process scripts 完成后的业务经理终审；评估 N10 是否通过，以及是否允许下一轮进入 N11。
  • 本轮目标：
    • 在 N9 已通过的前提下，只创建操作者运行手册和必要过程说明。
    • 创建 docs/go-mcp-runbook.md，README 未修改。
    • Runbook 覆盖 Build C# helper、Verify C# helper、Build Go MCP、Verify Go MCP、Configure MCP client command、Allowed tools、Explicit non-goals、Real-login UIA capture procedure。
    • Runbook 包含四条 exact commands：powershell -NoProfile -ExecutionPolicy Bypass -File scripts\verify-win-helper.ps1、go test ./...、go build ./cmd/isphere-mcp、powershell -NoProfile -ExecutionPolicy Bypass -File scripts\verify-go-mcp.ps1。
    • Runbook 明确边界：no login automation、no send message、no send file、no receive/download file、no process injection、no hook、no memory reading。
    • 保持边界：未改功能代码、未改 MCP tool handlers、未新增工具、未改 C#、未进入 N11/N12，未真实采集 iSphere 登录数据。
  • 业务判断：N10 通过。当前交付把已验证的 C# helper、Go MCP、四个只读工具、验证命令和使用边界整理为操作者可执行手册，降低交付使用门槛；pi 和 opencode 审查均确认 runbook 要求齐全、未暗示 Python MCP 或发送/搜索/文件能力已实现、无 README/功能/C#/依赖/脚本越界，具备进入下一轮审批的条件。
  • 是否跑偏：未跑偏。执行内容停留在 runbook，不进入 N11 commit checkpoint，不进入 N12 真实采集，不实现新功能或业务动作。
  • 是否过度设计：未过度设计。仅创建 docs/go-mcp-runbook.md，README 未修改，没有大型文档体系、额外脚本框架或功能扩展。
  • 是否遗漏：无阻塞性遗漏。四条命令、允许工具、明确非目标、MCP client command、real-login UIA capture procedure 和关键安全边界均已覆盖。后续提交状态清理属于 N11 范围，不构成本轮遗漏。
  • 是否允许进入下一轮：允许进入下一轮 N11，但只允许做 Commit and review checkpoint。N11 应运行验证命令、检查 git status --short、按计划做小提交/审查 checkpoint；不得进入 N12，不得真实采集 iSphere 登录数据，不得实现搜索/发送/文件/自动登录/注入/hook/读内存/规避安防。
  • 业务经理结论：批准 N10 通过；不要求返工；不停止项目。下一轮可以只推进 N11：Commit and review checkpoint。N11 完成后必须再次提交业务终审，不能自动进入 N12。

2026-07-05 N11 执行前审批

  • 当前节点：第十一轮执行前审批；仅评估是否允许进入本轮 N11：Commit and review checkpoint，不评估、不批准 N12。
  • 本轮目标：
    • 在 N10 Operator runbook 已通过终审的前提下，冻结第一阶段 Go MCP 产物，避免在真实 iSphere 数据引入前继续积累未提交变更。
    • 运行验证命令：powershell -NoProfile -ExecutionPolicy Bypass -File scripts\verify-win-helper.ps1、powershell -NoProfile -ExecutionPolicy Bypass -File scripts\verify-go-mcp.ps1、go test ./...、go build ./cmd/isphere-mcp、git status --short。
    • 精确 stage 允许文件，禁止 git add -A 或 broad stage；不得提交 build 临时产物。
    • 提交当前 N0-N10 产物，保持提交范围清晰。
    • N11 审查完成后保证最终工作区 clean；如审查日志追加造成 dirty，应在同一 N11 内做最终 process checkpoint 精确提交。
    • 明确禁止：不进入 N12，不真实采集 iSphere 登录 UIA，不实现新功能，不新增工具，不改四个 tool handlers 的业务范围，不实现搜索、发送、文件、自动登录、注入、hook、读内存。
  • 业务判断：允许进入本轮 N11。N11 的业务价值是把 N0-N10 已验收的第一阶段成果固化为可审查、可回滚、可交付的 Git checkpoint，并在 N12 真实登录 UIA capture gate 前建立干净边界；本轮目标符合最终目标，不新增业务能力，只做验证、精确提交和审查闭环。
  • 是否跑偏：未跑偏。拟定动作与 N11 计划一致，聚焦验证命令、状态检查、精确 stage、小提交和审查 checkpoint；没有进入 N12，没有真实采集登录态 UIA，也没有扩大到搜索/会话/发送/文件/自动登录或底层绕过能力。
  • 是否过度设计：未过度设计。两段提交节奏属于 N11 审查闭环的必要安排：先提交 N0-N10 产物，再提交审查过程中追加的 process logs，目的是避免“审查后又 dirty”的流程缺口；不引入额外架构、功能、工具或复杂发布流程。
  • 是否遗漏：无阻塞性遗漏。N11 需要补齐的关键验收已覆盖：四条验证命令、git status --short、精确 stage、禁止 broad stage、禁止 build 临时产物、提交范围清晰、最终 clean。若任一验证失败、出现无关生成物被 staged、工作区残留非 runs/ 构建输出、或出现 Python MCP/search/send/file tools，应停止并返工。
  • 是否允许进入下一轮：允许进入本轮 N11 执行；不允许进入 N12。N11 只能做 Commit and review checkpoint，完成后必须再次提交业务终审，不能自动开始 real logged-in UIA capture gate。
  • 业务经理结论：批准本轮只执行 N11：Commit and review checkpoint。批准“两段提交节奏”：A. 实现智能体先运行验证并精确提交 N0-N10 产物；B. pi/opencode/业务经理审查追加各自日志后，由实现智能体在同一 N11 内做最终 process checkpoint 精确提交，再由主协调核对 git status --short clean。不要求替代节奏；若无法保持精确 stage 或最终 clean，应停止并报告。

2026-07-05 N11 终审

  • 当前节点：第十一轮 N11 Commit and review checkpoint 终审；评估 N11-A 验证与提交是否通过，是否批准 N11-B 最终 process checkpoint 提交，以及是否允许实际进入 N12。
  • 本轮目标：
    • 在 N10 已通过的前提下，冻结第一阶段 Go MCP 产物，在真实 iSphere 数据引入前形成可审查、可回滚、可交付的 Git checkpoint。
    • N11-A 已运行验证命令：powershell -NoProfile -ExecutionPolicy Bypass -File scripts\verify-win-helper.ps1、powershell -NoProfile -ExecutionPolicy Bypass -File scripts\verify-go-mcp.ps1、go test ./...、go build ./cmd/isphere-mcp，并检查 git status --short。
    • N11-A 已通过精确 stage 提交 N0-N10 产物，形成四个提交：63cda71 docs: add go mcp plan and process logs、8956f33 feat: add go helper client and mcp tools、17fa9dd test: add go mcp verification script、57f1d42 docs: add go mcp runbook。
    • 审查阶段按既定两段节奏追加 docs/process/pi-review.md、docs/process/opencode-review.md，本终审追加 docs/process/business-manager-review.md；因此仍需 N11-B 做最终 process checkpoint 精确提交并核对 clean。
    • 明确禁止：不得真实采集 iSphere 登录 UIA，不得搜索联系人、打开会话、发送消息、发送/接收文件、自动登录、注入、hook、读内存或规避安防。
  • 业务判断：N11-A 通过，N11 业务目标已基本达成，允许执行 N11-B 收尾。验证命令均记录为 exit 0，C# helper 和 Go MCP smoke 均返回 ok=true，Go test/build 通过，临时 exe 已删除；四个提交按文档、Go helper/MCP、验证脚本、runbook 分组，pi 和 opencode 均认为低风险/不建议返工，未发现 build 产物、Python MCP、search/send/file tools、N12 真实采集或越界能力。
  • 是否跑偏：未跑偏。N11-A 只做验证、精确提交和 checkpoint；审查阶段只追加过程文档；没有进入 N12，没有真实采集登录 UIA，没有新增工具或业务动作，没有扩大四个只读工具的范围。
  • 是否过度设计：未过度设计。两段提交节奏已按执行前审批用于解决审查日志追加后的 dirty 问题；提交粒度虽被 opencode 记录为略粗，但仍按交付类型分组，未混入无关文件，属于非阻塞质量观察，不构成返工理由。
  • 是否遗漏：无阻塞性遗漏。N11 验证、提交、临时产物清理、Python MCP 缺失确认、无 search/send/file tools 等关键验收已有审查证据；唯一剩余事项是 N11-B 将审查追加的 process docs 精确提交并核对 git status --short clean，这属于已批准两段节奏的收尾，不是 N11 业务目标缺口。若 N11-B 后仍非 clean、出现 broad stage、提交 build 产物或出现 N12/业务动作文件，应立即停止并返工。
  • 是否允许进入下一轮：不允许实际进入 N12，停止在 N12 前。原因是当前事实没有用户已手动登录并打开 iSphere 主窗口的前置条件；即使 N11-B 完成 clean，也只能进入“等待用户手动登录/打开 iSphere 并重新发起 N12 执行前审批”的状态，不能自动开始 real logged-in UIA capture。
  • 业务经理结论：批准 N11-A 通过；批准执行 N11-B 最终 process checkpoint 精确提交，提交范围仅限审查阶段追加/修改的 process docs，并由主协调核对 git status --short clean。不要求返工，不停止项目本身；但明确不批准实际进入 N12，不得真实采集、不得搜索/发送/文件/自动登录/注入/hook/读内存。N12 必须等待用户手动登录并打开 iSphere 可见主窗口后，再单独提交执行前审批。

2026-07-05 N11 后 / N12 前业务边界变更判断

  • 当前节点：N11 已完成后的 N12 前业务边界变更判断；用户说明当前环境无法登录，只能在别的沙盒登录后复制所需文件/证据。本轮只判断业务路线与边界，不进入 N12，不看代码。
  • 本轮目标：
    • 判断“从别的沙盒复制文件/证据”是否满足原 N12 Real logged-in UIA capture gate。
    • 判断是否允许新增离线前置节点（建议命名为 N12-pre / offline evidence intake），用于先定义可复制证据包清单、脱敏边界和验收规则。
    • 明确离线证据包允许/禁止内容，避免密码、token、聊天内容、联系人隐私、发送/文件能力、自动登录、注入、hook、读内存或规避安防。
    • 判断是否允许当前主会话先给用户一份“需要复制哪些文件/证据”的清单，以及是否立即更新计划文档。
  • 业务判断：从别的沙盒复制文件/证据不满足原 N12。原 N12 的关键前置条件是用户在当前可执行环境手动打开并登录 iSphere，且 iSphere 主窗口可见，然后使用当前 Go MCP 只读工具 win_helper_scan_windows / win_helper_dump_uia 采集真实窗口 UIA；离线复制证据不能证明当前环境存在可见登录窗口，也不能替代当前环境的实时 UIA capture gate。因此 N12 仍被阻断。但允许新增 N12-pre / offline evidence intake 作为 N12 前置路线，用于接收和审查用户从别的沙盒导出的脱敏证据包，目标是判断是否足以改写后续计划或准备离线分析，不允许把它当作 N12 已通过。
  • 是否跑偏：未跑偏。新增离线前置节点是对“当前环境无法登录”的业务约束适配，仍围绕只读 UIA 证据、窗口/控件识别和后续 selector 设计准备；不允许搜索联系人、打开会话、发送消息、发送/接收文件、自动登录、注入、hook、读内存或规避安防。
  • 是否过度设计：未过度设计。建议先给用户一份最小证据清单和脱敏边界，等待文件到位后再审批/维护正式 N12-pre 计划；当前不需要立即重写大计划或创建复杂 intake 流程，避免在没有证据样本前过度设计。
  • 是否遗漏：需补齐离线证据包清单与边界。允许包含：1) 证据清单 manifest（来源沙盒、采集时间、iSphere/IMPlatform 版本、OS 版本、是否手动登录但不含账号密码）；2) 使用只读方式导出的 scan_windows 候选窗口结果；3) 手动登录后主窗口的脱敏 dump_uia JSON，字段限于窗口/控件识别所需的 name、control_type、automation_id、class_name、children、窗口标题/进程名/句柄等元数据；4) 脱敏截图（可选，必须遮挡联系人、头像、聊天内容、账号信息、组织信息和任何个人数据）；5) 安装/版本元数据（可执行文件路径、文件版本、产品版本、哈希、必要资源文件名列表）；6) 采集步骤记录与校验摘要。禁止包含：密码、token、cookie、session、证书、私钥、自动登录材料、联系人列表、聊天消息、文件附件、下载内容、个人资料、原始数据库/缓存、未脱敏日志、内存 dump、进程 dump、抓包、注入/hook/读内存产物、发送/接收文件能力证明或任何可用于绕过登录/安防的数据。
  • 是否允许进入下一轮：不允许实际进入 N12；允许下一步仅进入 N12-pre / offline evidence intake 的准备动作，即主会话可以给用户“需要复制哪些文件/证据”的清单和脱敏要求。收到证据包后，必须先做新的执行前审批，再决定是否更新 docs/go-mcp-minimal-plan.md 增加 N12-pre 或改写后续路线；不得直接把离线证据视为 N12 通过。
  • 业务经理结论：N12 不满足，停止在 N12 前；批准离线证据包路线作为 N12 前置补充，不批准真实采集、不批准搜索/发送/文件/自动登录/注入/hook/读内存。当前主会话允许先给用户最小操作清单；本轮不要求立即修改计划文档，等用户证据到位后再审批新节点和必要计划更新。

2026-07-05 N12-pre 离线证据路线设计审查

  • 当前节点：N11 后、N12 前的业务边界变更设计审查；审查逆向子智能体新增的 docs/offline-evidence-intake-plan.md、docs/go-mcp-minimal-plan.md 中的 N12-pre 插入，以及 docs/go-mcp-runbook.md 的无法当前环境登录指引。本轮只做业务设计审查，不看代码、不做代码审查、不进入真实 N12。
  • 本轮目标：
    • 判断 N12-pre Offline evidence intake 是否能在当前环境无法登录的约束下，作为 N12 前置补充路线承接用户从其他沙盒复制的脱敏证据。
    • 判断该路线是否仍保留原 N12 的 live current-environment UIA capture gate，不把离线证据误判为 N12 pass。
    • 判断证据包清单、允许/禁止边界、脱敏规则、manifest/scan/dump 三个 required files 是否足够清晰。
    • 判断是否允许主协调基于文档向用户提出文件/证据包要求，以及这些文档是否应立即提交。
  • 业务判断：通过。新的 N12-pre 路线符合业务目标：它承认当前环境无法登录的现实，给出可复制、可脱敏、可验证形状的离线证据包路线，同时明确 offline_pre_only_not_n12_pass，不把离线证据等同于原 N12。required files 聚焦 manifest.json、scan_windows-redacted.json、dump_uia-main-redacted.json，与后续 UI 结构/selector 可行性分析直接相关，交付价值明确。
  • 是否跑偏：未跑偏。文档明确 N12-pre 只能使用 version/self_check/scan_windows/dump_uia 四个只读 op，禁止 password/token/cookie/session/contact/chat/attachment/raw db/cache/memory dump/packet capture/hook/injection/read memory，也禁止搜索联系人、打开会话、发送消息、发送/接收文件、自动登录和规避安防；计划仍保留原 N12 必须当前环境手动登录并 live UIA capture 的条件。
  • 是否过度设计：未过度设计。相较此前“只要几个文件”的粗略清单，当前 manifest schema、redaction rules、required-file checks 和 repository-side validation 是必要的业务边界设计，用于防止用户复制敏感数据或误把离线证据当作 N12 通过。当前仍停留在文档和清单层，没有新增工具、验证器、代码或脚本，因此没有过度工程化。
  • 是否遗漏：无阻塞性遗漏。文档已覆盖 N12-pre 定位、三类必需文件、可选文件、禁止内容、脱敏规则、保存路径、校验方式、离线分析允许/禁止范围，以及进入真正 N12 的条件。非阻塞建议：主协调对用户输出时应使用简化版清单，强调“先脱敏再复制”和“离线包不等于 N12 通过”；收到证据后仍需单独做 N12-pre 执行前审批/验收审查。
  • 是否允许进入下一轮：允许主协调基于该文档向用户提出文件/证据包要求；不允许进入真实 N12，不允许真实采集，不允许搜索/发送/文件/自动登录/注入/hook/读内存。建议下一步只是向用户确认能否按清单提供脱敏证据包，并等待文件到位后再审批 N12-pre intake。
  • 业务经理结论：批准 N12-pre 离线证据路线设计；允许主协调向用户提出 evidence package 要求。提交节奏上，不建议立即提交这些文档；建议先让用户确认清单是否可提供、是否存在必须调整的字段，确认后再做一次精确的 N12-pre docs checkpoint 提交。若用户确认无调整，则提交范围应仅限相关文档和过程日志，不得混入代码、脚本、真实证据或构建产物。

2026-07-05 N12-pre full sandbox artifact bundle 路线审查

  • 当前节点：N11 后、N12 前的 N12-pre 离线证据接入路线扩大审查；审查逆向子智能体将 N12-pre 调整为两种 intake 模式后的业务合理性。本轮只做业务设计审查，不看代码、不做代码审查、不进入真实 N12。
  • 本轮目标：
    • 判断推荐模式 A：Full sandbox artifact bundle 是否能解决用户“不懂 manifest/scan/dump JSON，只能复制登录后测试沙盒文件”的现实问题。
    • 判断模式 B：Minimal redacted UIA package 是否仍可作为高级可选路线保留。
    • 判断新路线是否仍明确 not N12 pass，且后续处理只做 read-only inventory，不直接运行未知二进制、不修改原始拷贝文件。
    • 判断是否允许主协调现在给用户一份“复制完整测试沙盒证据包”的简化清单，以及是否继续暂不提交，等待用户确认可提供哪些目录后再 checkpoint。
  • 业务判断：通过。Full sandbox artifact bundle 路线符合当前业务目标：用户无法在当前环境登录且不理解 JSON，要求“从长计议”并复制登录后的测试沙盒安装文件和用户目录；推荐用户只复制目录，比继续要求 manifest/scan/dump 更可执行。文档将 install、user profile、ProgramData、shortcuts、TEMP/importal/localcache 等目录纳入结构化证据包，并特别提示 importal\localcache、LoginLog、IMPP.Util.dll 等线索，有助于后续只读清点、离线分析和设计后续路线。
  • 是否跑偏：未跑偏。文档明确 full bundle 仍是 N12-pre，不是 N12 pass；N12 仍要求当前环境手动登录和 live UIA capture。文档也明确收到后先做 read-only inventory，不直接运行未知二进制，不把测试沙盒文件用于自动登录，不设计搜索联系人、打开会话、发送消息、发送/接收文件、注入、hook、读内存或规避安防能力；git diff --name-only -- '*.go' '*.cs' 'scripts/*.ps1' 无输出，说明本轮未改代码/脚本。
  • 是否过度设计：未过度设计。相比之前只要求 JSON 的路线，full bundle 模式更贴合用户实际能力；目录分区、copy-notes、metadata、raw/install、raw/user-profile、raw/programdata、raw/temp-importal-localcache 是为了让非技术用户能复制，同时让后续清点可控。保留 minimal redacted UIA package 作为高级可选不会增加执行负担，也避免丢失原先 UIA 证据路线。
  • 是否遗漏：无阻塞性遗漏。已覆盖两种 intake 模式、推荐路线、目录结构、关键候选路径、not N12 pass、read-only inventory、禁止运行未知二进制、禁止修改原始证据、禁止自动登录/发送/文件/注入/hook/读内存/规避安防。非阻塞补充要求：主协调给用户清单时应强调这是“测试沙盒证据包”，不要提交 raw evidence 到 Git；如果压缩包内有真实个人/生产数据，应先说明并隔离处理；收到后需先做 N12-pre 执行前审批和只读 inventory 审查。
  • 是否允许进入下一轮：允许主协调向用户给出“复制完整测试沙盒证据包”的简化清单；不允许进入真实 N12，不允许开始真实采集，不允许运行或使用复制来的未知二进制，不允许基于复制文件实现搜索/发送/文件/自动登录/注入/hook/读内存。下一步应只是让用户确认能提供哪些目录/压缩包，并等待证据到位或用户反馈后再决定 N12-pre intake 审批。
  • 业务经理结论：批准 full sandbox artifact bundle 路线；允许主协调现在给用户简化清单。提交节奏上，继续暂不提交这些文档，先让用户确认可提供哪些目录和是否有压缩包；确认后再做精确 N12-pre docs checkpoint。后续提交范围应仅限相关文档和过程日志，不得提交 raw 证据包、代码、脚本或构建产物。

2026-07-05 N12-pre 完整测试沙盒包扩大清单判断

  • 当前节点：N11 后、N12 前的 N12-pre 离线证据接入边界扩大判断；用户补充“我拥有完整权限”，且说明当前材料均为测试文件。本轮只做业务边界判断，不看代码、不做代码审查、不进入真实 N12。
  • 本轮目标：
    • 判断是否允许把用户复制清单从“相关目录优先”升级为“完整测试沙盒包优先”。
    • 判断是否允许主协调给用户最终清单：完整复制 C:\Users\<登录用户>、安装目录、C:\ProgramData 相关或完整副本、C:\Users\<用户>\AppData\Local\Temp\importal、快捷方式、进程/版本/目录树元数据，并建议压缩为 zip/7z。
    • 明确保留边界：离线包不是 N12 pass；收到后先做 read-only inventory；不直接运行未知二进制；不进入发送/文件/自动登录/注入/hook/读内存。
    • 判断是否需要现在更新文档，还是等用户提供包后再 checkpoint。
  • 业务判断：允许扩大清单。用户已明确拥有完整权限且材料是测试文件，在业务上可以将 N12-pre 的推荐输入升级为“完整测试沙盒包优先”，因为完整用户目录和完整/相关 ProgramData 更能保留登录后运行环境、缓存、配置、日志、快捷方式和版本线索，降低用户漏拷关键目录的风险，也比要求用户识别 JSON 或具体应用目录更可执行。
  • 是否跑偏：未跑偏。该扩大只改变 N12-pre 证据包收集范围，不改变 N12 通过条件；完整测试沙盒包仍是 offline pre evidence，不等于当前环境 live UIA capture。收到后只能做 read-only inventory 和离线分析，不得直接运行未知二进制，不得把包内 credential-like/test session 材料用于登录或冒充用户，不得实现搜索联系人、打开会话、发送消息、发送/接收文件、自动登录、注入、hook、读内存或规避安防。
  • 是否过度设计：未过度设计。对非技术用户而言，“完整测试沙盒包优先”比逐项筛选相关目录更简单，且能避免关键 AppData/ProgramData/Temp/importal/localcache 漏拷；压缩为 zip/7z、附目录树/进程/版本元数据属于必要交付包装，不是功能扩张。后续只读 inventory 再决定哪些文件有分析价值，能减少前期沟通成本。
  • 是否遗漏：无阻塞性遗漏。最终清单应至少包括：1) 完整 C:\Users\<登录用户> 测试用户目录；2) iSphere/IMPlatformClient 安装目录；3) C:\ProgramData 中相关目录，若用户确认都是测试环境且体积可接受，可提供完整 C:\ProgramData 副本；4) C:\Users\<用户>\AppData\Local\Temp\importal、importal\localcache、LoginLog 等 Temp/cache 线索；5) 桌面和开始菜单快捷方式；6) 必要系统元数据，如目录树、文件列表、文件版本/哈希、运行进程列表、安装程序列表、OS 版本、环境变量摘要。仍需强调 raw evidence 不提交 Git，进入仓库后应放在 runs/offline-evidence-intake/<evidence-id>/ 或由主协调指定的非提交证据位置。
  • 是否允许进入下一轮：允许主协调向用户发出最终“完整测试沙盒包优先”清单；不允许进入真实 N12，不允许运行复制来的未知二进制，不允许开始发送/文件/自动登录/注入/hook/读内存能力。用户提供包后，应先做 N12-pre intake 执行前审批与只读 inventory 计划，再开展文件清点。
  • 业务经理结论：批准将复制清单扩大为完整测试沙盒包优先。当前不建议立即更新/提交文档；先让用户按最终清单提供或确认可提供哪些目录，等证据包到位或用户确认后，再按实际情况做精确 docs checkpoint。若后续更新文档，提交范围只能是相关文档和过程日志，不能提交 raw 测试证据包、代码、脚本或构建产物。
Reference in New Issue View Git Blame Copy Permalink