Agent-System/.doc/test-reports/2026-09-21-test-env-bizdev-lazy-doc-verification-test-report.md

test 环境商务对接受控文档懒创建验证 — 测试报告

报告日期: 2026-09-21
执行分支: docs/lazy-doc-verification-2026-09-21（纯验证，无代码变更）
证据目录: .doc/test-reports/assets/2026-09-21-test-env-bizdev-lazy-doc-verification/
关联任务: short-term/2026-09-21-test-env-lazy-doc-verification · beta6 报告 §5.3

---

一、 测试背景 (Background)

用户在 test 环境观察到「项目已激活商务对接工作流，但流程受控文档数量为 0」。

静态诊断结论：这是懒创建设计的预期表现，非缺陷——

• 工作流激活事务（internal/projectinstance/store.go activateInstanceTx）只写 projects / project_workflow_instances / project_stage_instances / project_doc_task_instances，不写 document_records；
• 受控文档账本唯一生产创建点是任务运行时 internal/bizdev/service.go:629 调用 docGov.CreateOrGetDocument（internal/docgov/engine.go:183 INSERT）；
• 前端「共 N 份受控文档」计数来自 GET /api/v1/projects/:id/documents?category=workflow → ListWorkflowDocumentsByProject（internal/docgov/project_docs.go:55，查 task_key <> ''）。

诊断时 test 库实测：document_records 全表 0 行；仅有的 2 条 task_runs（项目 2 intake、项目 5 user_requirements）均为激活前发起的 blocked_pending_governance，从未有任务跑完。本报告通过端到端实测闭环验证该结论。

二、 测试目标 (Test Objectives)

#	目标	成功标准
T1	激活后基线	新建项目激活 main 工作流后，documents API 返回 []、document_records 为 0 行、project_doc_task_instances 全 pending
T2	真实 Agent 产出	POST /api/v1/tasks/runs task_key=bd_intake backend=pi-agent（真实 MiniMax-M2.7-highspeed，非 stub）跑至 completed
T3	懒创建落库	任务完成后 document_records 对该项目新增 1 行（task_key='bd_intake'）
T4	API 计数翻转	documents API 返回 1 份、is_template_only=false、职责（author/reviewer/approver）与 SoD 分配一致
T5	正文完整性	受控正文 ≥1500 字符；文件 SHA-256 与账本 content_sha256 一致

三、 测试方案与环境 (Test Plan & Environment)

项	值
OS	Linux 7.0.0-31-generic
目标环境	test :8081 / pi-agent :18866 / pg :5434（agent_system_test）
Agent	pi-agent + MiniMax-M2.7-highspeed（真实 token，容器日志确认 provider=minimax）
数据隔离	新建验证专用项目 id=7 lazy-doc-verify-20260921，不触碰既有项目 2/3/5 与只读项目 143
SoD 职责	author=26 mtx_owner / reviewer=27 mtx_reviewer / approver=28 mtx_approver（beta6 同款）
层级	激活两步确认（plan save → preview → activate）→ 真实小队任务 → SQL/API/正文三重验证

测试用例矩阵：

用例	输入	判定分支
C1 激活基线	preview + activate main v2	lifecycle=active、实例 7 个 pending、文档 0 行
C2 真实任务	bd_intake + backend=pi-agent	status=completed、无 stub 痕迹
C3 账本落库	任务完成后 SQL	document_records 1 行、state=drafting、version=1
C4 API 计数	documents API	1 份、职责齐备、duty_policy=separated
C5 正文完整性	docgov content API	SHA-256 对齐、字数达标

四、 预期结果 (Expected Results)

• C1：激活成功（instance id、plan_hash 返回），API []、SQL 0 行——证明「激活不建文档」；
• C2：HTTP 202 → running → 小队四步（01_organize → 02_draft → 03_review → leader 整合）→ completed，参考 beta6 约 5.5min；
• C3/C4：document_records 与 API 同时出现 1 行/1 份，author_name=矩阵负责人 等 SoD 职责注入；
• C5：output.md（leader 终稿）≥1500 字符，SHA-256 与账本一致（无完整性漂移）。

五、 实际测试结果与判定 (Actual Results & Evaluation)

C1 激活后基线 — PASS

• 测试输入 (Input)：admin(4) 创建项目 7 → 加成员 26/27/28 → PUT /workflow-plan（plan_revision=1）→ POST /activation-preview → POST /workflow-instances/activate
• 实际输出 (Actual Output)：
  • 激活返回：{"project_id":7,"lifecycle_status":"active","active_workflow_key":"main","instance":{"id":5,"workflow_version_id":13,...}}（08-activate.json）
  • 基线 API：[]（09-documents-baseline.json）
  • 基线 SQL：proj7_doc_records = 0；project_doc_task_instances 7 个全部 pending
• 评价判定 (Evaluation / Verdict)：PASS——激活只建实例不建账本，与诊断一致。
• 性能与耗时 (Duration & Latency)：全流程约 4s。

C2 真实 PI Agent 任务 — PASS

• 测试输入 (Input)：mtx_owner(26) POST /api/v1/tasks/runs：task_key=bd_intake、backend=pi-agent、session_id=sess-p7-u26（10-taskrun-create.json）
• 实际输出 (Actual Output)：
  • HTTP 202：{"run_id":"run_1789956764008461988","status":"running"}
  • pi-agent 容器日志：依次 Starting pi run in workspace: .../bd_intake_1789956764023617458/tasks/01_organize → 02_draft → 03_review → repair_1（model: MiniMax-M2.7-highspeed, Provider: minimax）
  • 终态（12-run-final.json）："Status":"completed"，ErrorMessage=""，WorkspaceID=/app/data/workspaces/bizdev/bd_intake_1789956764023617458
• 评价判定 (Evaluation / Verdict)：PASS——真实 Agent 全链路（含一次 quality repair），无 stub。
• 性能与耗时 (Duration & Latency)：02:12:44 → 02:16:29，约 3 分 45 秒。

C3 账本懒创建落库 — PASS

• 测试输入 (Input)：任务完成后 SQL 查询 document_records WHERE project_id=7

• 实际输出 (Actual Output)（13-sql-document-records.txt）：

       doc_id        | project_id | task_key  | current_state | is_template_only | version
  -------------------+------------+-----------+---------------+------------------+---------
   doc_proj7_bd_intake |          7 | bd_intake | drafting      | f                |       1
  

• 评价判定 (Evaluation / Verdict)：PASS——任务运行时 CreateOrGetDocument 落库，0 → 1。

• 性能与耗时 (Duration & Latency)：随任务 finalize 同步落库。

C4 API 计数翻转与职责注入 — PASS

• 测试输入 (Input)：GET /api/v1/projects/7/documents?category=workflow
• 实际输出 (Actual Output)（14-documents-after.json）：1 份；title=用户初始需求收集表；lifecycle_state=drafting；author=矩阵负责人(26) / reviewer=矩阵审核(27) / approver=矩阵批准(28)；duty_policy=separated；is_template_only=false
• 评价判定 (Evaluation / Verdict)：PASS——前端大盘将由「共 0 份」变「共 1 份」。
• 性能与耗时 (Duration & Latency)：接口响应即时。

C5 正文完整性 — PASS

• 测试输入 (Input)：GET /api/v1/docgov/documents/doc_proj7_bd_intake/content
• 实际输出 (Actual Output)（15-controlled-content.json / 16-output-summary.txt）：markdown_chars=7729（≥1500）；本地重算 SHA-256 与账本 content_sha256=da4423df… 完全一致；首行 # 用户初始需求收集表
• 评价判定 (Evaluation / Verdict)：PASS——账本与产物无完整性漂移。
• 性能与耗时 (Duration & Latency)：接口响应即时。

六、 自动化测试套件汇总 (Test Suite Execution)

本次为只读性质的端到端验证（无代码变更），未重跑 go test。最近全量回归基线见 rdev-seed-hotfix 报告 §6（go vet PASS；go test -short 中 2 处既知环境依赖用例失败与本验证无关）。

七、 测试结论与后续优化建议 (Conclusion & Next Steps)

结论：用户观察到的「激活后流程受控文档数量为 0」是懒创建设计的预期表现，非缺陷、无数据丢失。完整证据链闭环：激活成功（0 份基线）→ 真实 PI 任务 3m45s 完成 → 账本落 1 行 → API 计数翻转 → 正文哈希对齐。系统行为符合 internal/bizdev/service.go:629 懒创建契约，beta6 报告 §5.3 结论在本轮得到独立复现。

后续建议：

1. 产品口径：前端可在受控文档大盘为 0 且工作流已激活时，增加「暂无受控文档，发起首个文档任务后生成」的引导文案，降低同类困惑（现 Demo 模板槽与真实账本并存易混淆）。
2. 运维口径：遇到「0 文档」先查 task_runs 是否存在终态任务，再看 document_records；激活前发起的任务会以 blocked_pending_governance 停住，不计入文档生成。
3. 测试债务（引用既有结论）：go test -short 中默认连库的 notification/docgov 用例应改为无库即跳过。