feat: 根目录文档、脚本、gitignore

2026-10-08 16:15:33 +08:00
commit e98660ce4e
284 changed files with 26838 additions and 0 deletions
@@ -0,0 +1,12 @@
+# Decision Log
+- 2026-07-22: 初始化项目与基础规则确认。
+- 2026-07-22 [PJM][初始化]: workspace 建立于 workspace/specs/zentao-20260722-1638；规模 medium，风险 medium；可选门禁：架构设计 ✅ / 代码评审 ✅ / 安全 ❌ / 合规 ❌；Git 纪律不启用。— 用户确认，门禁中途变更须走变更单。
+- 2026-07-22 [PM][Round 1]: 项目总目标=IT 工作台落地 SOP 流程+绩效统计（Q1-1）；本期 MVP=全生命周期数据模型落地（Q1-2）；平台自研、数据本系统自有（Q1-3）。— 用户确认。
+- 2026-07-22 [PM][Round 2]: 缺口结论：AI代码审查报告、AI工作日志为净新增表；zt_story_extend 缺 AI 参与率字段；任务侧缺 AI 工作量指数字段；其余数据项复用现有 zt_* 表。证据见 02_acceptance/acceptance.md 映射表。
+- 2026-07-22 [PM][Round 2]: Q2-1 用户授权 PM 依需求判断 → 本期边界=DDL+实体+Mapper+Service，不含 Controller；DDL 放 codes/zentao/sql/。Q2-2 激活时间经用户指出并核实=zt_story_user.activateddate，复用。Q1-4 核实：工作量指数生成公式在文档与代码中均不存在，口径定义转后续阶段，本期仅落字段。
+- 2026-07-22 [PM][Round 2]: 关键架构边界（用户确认）：**工作量指数由 AI 框架计算后上传 zentao，zentao 只存不算**。上传通道 /zt-story-expand 已存在。本期所有 AI 类字段遵循同一边界；zt_ai_code_review / zt_ai_work_log 的上传接口列入后续阶段计划。
+- 2026-07-22 [PM][Round 2 关闭]: 用户确认验收标准 v2（checklist 签字）。需求与验收阶段关闭。
+- 2026-07-22 [PJM][Round 3 工作量评估]: demand-assessor 七步完成：S=4, B=1.6, T=4/F(T)=1.6, P=17/N=3/A=14，安全门触发（单测覆盖率<20%）→ G(A)=1.0，**W=10.2**，风险中，不拆分。demand-assessor 技能实际位于 .claude/skills/（修正此前"不存在"的判断）。
+- 2026-07-22 [PJM][Round 3]: 裁剪决策：W 提交禅道动作暂缓——该通道面向业务需求，本项目自身评估不等需求单，不阻塞主线（裁剪留痕，后续如需补登再执行）。
+- 2026-07-22 [Arch][Round 4 启动]: 用户指出设计须结合 SOP 全流程与现有功能 → 按 SOP 八个提交触点逐环做前后端证据摸底，再出 04_design 设计方案。
+- 2026-07-22 [用户指令]: 方案冻结前**暂停**，提出先出原型（页面可视化）再定。M2 DDL 暂缓，门禁挂起。
@@ -0,0 +1,7 @@
+# Evidence Index
+
+| ID | Title | Type | Source | Date | Path | Notes |
+|---|---|---|---|---|---|---|
+| SRC-001 | AI下的开发SOP流程（新版） | PDF | 用户提供 (docs/) | 2026-07-22 | workspace/specs/zentao-20260722-1638/01_input/references/AI下的开发SOP流程（新版）.pdf | 5页图片型PDF，已逐页阅取；SOP流程图+全生命周期数据模型 |
+| SRC-002 | 信息技术部绩效考核标准-新版 - AI下的考核方案 | XLSX | 用户提供 (docs/) | 2026-07-22 | workspace/specs/zentao-20260722-1638/01_input/references/信息技术部绩效考核标准-新版 - AI下的考核方案.xlsx | 9个岗位sheet，含权重/公式/评分标准 |
+| ASM-001 | 工作量评估（MVP：全生命周期数据模型） | 评估记录 | demand-assessor 七步 | 2026-07-22 | 00_meta/rounds/round_3.md | S=4, B=1.6, F(T)=1.6, A=14(映射0.55被安全门覆盖), **G(A)=1.0（安全门：项目单测覆盖率<20%）**, **W=10.2**；风险等级：中；AI参与建议：AI主导实现+人类把控DDL评审与映射核对+AC-4单测强制补齐对冲测试欠账；提交禅道：待用户提供 story-id |
@@ -0,0 +1,12 @@
+# Architecture Review Checklist
+
+| Item | Description | Status | Evidence | Notes |
+|---|---|---|---|---|
+| Scope | Architecture scope matches requirements |  |  |  |
+| Constraints | Constraints and assumptions documented |  |  |  |
+| Interfaces | Key interfaces defined |  |  |  |
+| Data model | Core data model documented |  |  |  |
+| Tradeoffs | Tradeoffs and alternatives evaluated |  |  |  |
+| Risks | Architecture risks identified and mitigations planned |  |  |  |
+| Non-functional | Performance, availability, security targets defined |  |  |  |
+| Evolution | Migration/compatibility plan documented |  |  |  |
@@ -0,0 +1,12 @@
+# Code Review Checklist
+
+| Item | Description | Status | Evidence | Notes |
+|---|---|---|---|---|
+| Requirements | Implementation matches acceptance criteria |  |  |  |
+| Tests | Unit/functional tests updated and passing |  |  |  |
+| Error handling | Errors handled and user-facing behavior defined |  |  |  |
+| Performance | Performance impact assessed |  |  |  |
+| Security | Security considerations reviewed |  |  |  |
+| Maintainability | Code readability and structure acceptable |  |  |  |
+| Compatibility | Backward compatibility assessed |  |  |  |
+| Logging/Monitoring | Observability changes documented |  |  |  |
@@ -0,0 +1,13 @@
+# Privacy & Compliance Review Checklist
+
+| Item | Description | Status | Evidence | Notes |
+|---|---|---|---|---|
+| Lawfulness/Transparency | Legal basis and user notices are documented |  |  |  |
+| Purpose limitation | Data use limited to defined purposes |  |  |  |
+| Data minimization | Only necessary data collected |  |  |  |
+| Data quality | Data accuracy and update mechanisms defined |  |  |  |
+| Storage limitation | Retention period defined and enforced |  |  |  |
+| Security safeguards | Security controls for personal data |  |  |  |
+| Individual rights | Access/rectify/delete requests supported |  |  |  |
+| Accountability | Audit trail and responsibility defined |  |  |  |
+| DPIA | DPIA completed for high-risk processing |  |  |  |
@@ -0,0 +1,12 @@
+# Security Review Checklist
+
+| Item | Description | Status | Evidence | Notes |
+|---|---|---|---|---|
+| Threat model | Threat model exists for new/changed components |  |  |  |
+| AuthN/AuthZ | Access control and permission checks reviewed |  |  |  |
+| Secrets | Secrets managed securely (no hard-coded secrets) |  |  |  |
+| Input validation | User/externally sourced inputs validated |  |  |  |
+| Dependencies | Third-party dependencies reviewed/approved |  |  |  |
+| Logging | Security-relevant events logged |  |  |  |
+| Incident response | Rollback/mitigation plan documented |  |  |  |
+| Data protection | Sensitive data protected in transit/at rest |  |  |  |
@@ -0,0 +1,12 @@
+# Architecture Review Checklist
+
+| Item | Description | Status | Evidence | Notes |
+|---|---|---|---|---|
+| Scope | Architecture scope matches requirements |  |  |  |
+| Constraints | Constraints and assumptions documented |  |  |  |
+| Interfaces | Key interfaces defined |  |  |  |
+| Data model | Core data model documented |  |  |  |
+| Tradeoffs | Tradeoffs and alternatives evaluated |  |  |  |
+| Risks | Architecture risks identified and mitigations planned |  |  |  |
+| Non-functional | Performance, availability, security targets defined |  |  |  |
+| Evolution | Migration/compatibility plan documented |  |  |  |
@@ -0,0 +1,12 @@
+# Code Review Checklist
+
+| Item | Description | Status | Evidence | Notes |
+|---|---|---|---|---|
+| Requirements | Implementation matches acceptance criteria |  |  |  |
+| Tests | Unit/functional tests updated and passing |  |  |  |
+| Error handling | Errors handled and user-facing behavior defined |  |  |  |
+| Performance | Performance impact assessed |  |  |  |
+| Security | Security considerations reviewed |  |  |  |
+| Maintainability | Code readability and structure acceptable |  |  |  |
+| Compatibility | Backward compatibility assessed |  |  |  |
+| Logging/Monitoring | Observability changes documented |  |  |  |
@@ -0,0 +1,43 @@
+# Gates (DoR / DoD)
+
+> 每阶段进入前检查 DoR，完成后检查 DoD；可选门禁由系统推荐、用户确认。
+
+## 需求输入
+- DoR: 需求来源明确；背景/目标初步描述
+- DoD: 需求文本落盘；证据索引初版
+
+## 验收标准
+- DoR: 需求范围与目标明确
+- DoD: 验收标准可测试；范围边界明确
+
+## 计划制定
+- DoR: 验收标准确认
+- DoD: 里程碑/资源/风险/依赖落盘
+
+## 架构设计（可选）
+- DoR: 复杂度/风险达到门槛
+- DoD: 架构方案/接口/数据模型落盘并评审
+
+## 模块任务拆分
+- DoR: 计划确认
+- DoD: 任务列表与责任人明确
+
+## 功能开发
+- DoR: 任务清单确认
+- DoD: 实现记录与单测/自测结果
+
+## 代码评审（可选）
+- DoR: 评审门禁启用
+- DoD: 评审结论与整改记录
+
+## 测试
+- DoR: 可测试版本与用例准备
+- DoD: 测试报告/缺陷清单/回归记录
+
+## 验收评审
+- DoR: 证据包齐全
+- DoD: 评审决议与整改清单
+
+## 归档
+- DoR: 所有门禁通过
+- DoD: 归档文档与复盘记录
@@ -0,0 +1,16 @@
+# Roles (RACI)
+
+> 按项目规模裁剪并记录原因。
+
+| 阶段/角色 | PM | PJM | Arch | Dev | QA | Council |
+|---|---|---|---|---|---|---|
+| 需求输入 | R | C | I | I | I | I |
+| 验收标准 | A | C | C | I | I | I |
+| 计划制定 | C | A/R | C | I | I | I |
+| 架构设计(可选) | C | C | A/R | I | I | I |
+| 任务拆分 | C | A/R | C | R | I | I |
+| 功能开发 | I | C | C | A/R | I | I |
+| 代码评审(可选) | I | C | C | A/R | I | I |
+| 测试 | I | C | I | C | A/R | I |
+| 验收评审 | C | C | C | C | C | A/R |
+| 归档 | I | A/R | I | I | I | C |
@@ -0,0 +1,22 @@
+# Round 1
+
+## Plan
+- WWH 填充度：Why 明确（AI 时代研发效能度量与绩效考核）[SRC-001][SRC-002]；What 部分明确（SOP 流程 + 9 岗位考核体系）；How 未明确（交付物形态、范围、数据源待确认）
+- 本轮目标：摄入并结构化两份需求输入文档，形成问题清单
+- 需要读取的资产与资料：docs/ 下两份新放入文件；assets/codemap、assets/domainmap（初步判相关性）
+- 需要提出的问题：交付物确认、本期范围、数据源、工作量指数口径
+
+## Do
+- 资产读取：SRC-001（5 页图片型 PDF，逐页渲染阅取）、SRC-002（9 个 sheet 全量提取）；codes/zentao 根目录观察到现行绩效 xlsx；assets/codemap 初查为订单/卡券/调度业务域资产（与本需求平台相关性待确认）
+- 分析与产出：01_input/requirements.md（SOP 流程 14 步、全生命周期数据模型、9 岗位考核指标结构化）；evidence_index.md 建立 SRC-001/002
+- 提问：questions/round_1.yaml（P0×2、P1×2、P2×1）
+
+## Check
+- 目标覆盖：两份文档内容已 100% 覆盖进 requirements.md（SOP 流程、数据模型、考核指标三板块）
+- 证据充分性：关键结论均标注 [SRC-001]/[SRC-002]；交付物推断已标 [ASSUMPTION] 并转化为 Q1-1
+- 逻辑一致性：考核公式与 SOP 数据模型可互相印证（工作量指数、AI代码审查报告、工作日志均为考核取数点）
+
+## Act
+- 更新 summary/status/evidence_index
+- 等待人类确认 Q1-1/Q1-2（P0 未关闭不进入下一轮完整输出）
+- 规划下一轮：P0 关闭后 → 需求拆解（WWH 完整化）→ 02_acceptance 验收标准草案
@@ -0,0 +1,22 @@
+# Round 2
+
+## Plan
+- WWH 填充度：Why/What 已明确；How 部分明确（MVP=数据模型落地，DDL+实体层；是否含 CRUD 接口待 Q2-1）
+- 本轮目标：代码资产深挖 → 数据项缺口分析 → 验收标准草案
+- 需要读取的资产：codes/zentao 实体/枚举/配置（explore 子代理 + 定点核查 ZtMeeting/ZtStoryUser/ZtFile）
+- 需要提出的问题：CRUD 边界、激活时间/附件口径、工作量指数口径（沿用 Q1-4）
+
+## Do
+- 资产读取：codes/zentao 全量结构（Spring Boot 3.3 + MyBatis-Plus + MySQL，zt_* 表体系）；确认 ZtMeeting（会议时间/参与人/纪要）、ZtFile（通用附件）、ZtStoryExpand（AI工作量指标）已存在；确认 AI代码审查报告/AI工作日志 全库无实现（净新增）
+- 分析与产出：02_acceptance/acceptance.md（映射表 + AC-1~5）、checklist.md、questions/round_2.yaml
+- 提问：Q2-1（P1 边界）、Q2-2（P1 口径）、沿用 Q1-4（P1）
+
+## Check
+- 目标覆盖：SRC-001 思维导图数据项 9 类全部完成映射（6 类复用、3 类缺口）
+- 证据充分性：现状判断均有文件路径级证据（ZtStoryUser.java:135、ZtMeeting.java:47/52/73、ZtStoryExpand.java 等）
+- 逻辑一致性：AC 与缺口一一对应；绩效统计/流程流转明确排除在本期外，与 Q1-2 回答一致
+
+## Act
+- 更新 summary/status/decision_log
+- 等待人类确认验收标准草案（P0 级门禁：验收标准确认后才进入工作量评估阶段）
+- 规划下一轮：验收标准确认 → 工作量评估（demand-assessor）→ PJM 制定计划
@@ -0,0 +1,57 @@
+# Round 3 — 工作量评估（demand-assessor 七步，禁止跳步）
+
+输入：01_input/requirements.md + 02_acceptance/acceptance.md v2（MVP：全生命周期数据模型落地）
+
+==============================
+需求工作量评估结果
+==============================
+
+【功能单元】（第一步：仅统计数量，不评复杂度）
+- 新表数据模型单元（DDL+实体+Mapper+Service）：zt_ai_code_review ×1、zt_ai_work_log ×1
+- 老表字段扩展单元：zt_story_extend +AI参与率 ×1、任务侧 +AI工作量指数 ×1
+总数 S = 4
+
+【业务复杂度】（第二步：仅评单个单元，以 zt_ai_work_log 为典型）
+| 项 | 分 | 依据 |
+|---|---|---|
+| 1 业务规则数量 | 2 | 8 类日志枚举 + 字段映射，规则少 |
+| 2 状态流转复杂度 | 1 | 存储型表，无状态机 |
+| 3 异常处理复杂度 | 1 | 无回滚/补偿/降级路径 |
+| 4 边界场景复杂度 | 2 | 枚举校验、时间/关联边界 |
+| 5 需求不确定性 | 2 | 8 类日志已列明，但各类内容结构未细化 |
+B = (2+1+1+2+2)/5 = 1.6
+
+【技术复杂度】（第三步）
+T = 4（涉及 DB 变更：2 新表 + 2 老表加列）→ F(T) = 1 + 0.2×(4-1) = 1.6
+风险说明：无迁移工具、手工 DDL，需可重入与备份；实体无注解驼峰映射须与库表严格一致；有 zt_story_expand 同模式先例可参照。
+
+【AI效率系数】（第四步）
+P = 17（需求清晰度4 / 规则明确度4 / 可验证性5 / 代码结构清晰度4）
+N1 = 0（dynamic-datasource 依赖存在但本变更不涉及多数据源切换）
+N2 = 2（数据库老表变更 +1；低测试覆盖区域 +1）
+N3 = 1（测试覆盖率 <30% +1：src/test 仅 1 个空壳 context-load 测试）
+A = P - N = 14
+
+【安全门】（第五步）
+- 核心结算/分布式事务/权限鉴权/影响范围不清：均否
+- 单测覆盖率 <20%：**是**（全项目仅 ZentaoApplicationTests 1 个空壳测试）→ ⚠️ 高风险变更标记，G(A) 强制 = 1.0
+
+【G(A)】（第六步）
+A=14 映射值 0.55，被安全门覆盖 → G(A) = 1.00
+是否高风险变更：是（触发项：单测覆盖率 <20%）
+
+【最终工作量】（第七步）
+W = B × S × F(T) × G(A) = 1.6 × 4 × 1.6 × 1.00 = **10.2**
+
+【综合风险等级】中（安全门由测试欠账触发，非业务核心性；变更本身机械、同构、可控）
+
+【是否建议拆分】否（4 个单元同构且量小，一次交付；拆分只增管理成本）
+
+【AI建议参与方式】
+规则档位 G(A)=1.0 →「人类主导」。偏离建议并留痕：本变更高度机械（DDL+代码生成），实际风险点是项目无测试网导致回归不可验证 → 建议「AI 主导实现 + 人类把控 DDL 评审与字段映射核对 + AC-4 单测强制补齐作为安全网」（等效 0.75 档执行），由人类在 DDL 落库前逐项确认。
+==============================
+
+## 提交禅道（待办）
+- story-id：输入文档无需求ID → 需用户手动提供
+- status / 人员信息：待用户确认
+- 提交命令：`python .claude/skills/demand-assessor/submit_assessment.py --story-id <ID> --number-units 4 --b 1.6 --ft 1.6 --ga 1.0 --status <状态> --w 10.2 [--product-person ..] [--develop-person ..] [--test-person ..]`
@@ -0,0 +1,21 @@
+# Round 4 — Arch/PJM：SOP×现有功能 设计方案
+
+## Plan
+- 目标：按用户要求，结合 codes/zentao 现有功能与 SRC-001 SOP 全流程，产出具体设计方案（04_design 三件套）与分期计划（03_plan）
+- 前置修正：裁剪 W 提交禅道动作（通道面向业务需求，本项目评估不套业务通道），不再阻塞
+
+## Do
+- 资产深挖：后端 8 触点（explore agent-1）+ 前端 7 项页面（agent-2），关键新发现：
+  - userReview 通过即激活但 activateddate 死字段；meeting 后端附件就绪、前端组件引入未渲染
+  - /zt-story-expand 无 token 直连（itsm_post.py 实证）；绩效 IZtCountService 完全不消费 AI 指标（孤岛）
+  - zt_task 无 AI 字段且为禅道老表；测试报告无承载（zt_testtask.report 死字段）
+- 产出：04_design/architecture.md（14 环节映射表+AD-1~5+分期）、data_model.md（3 新表+1 加列 DDL 设计）、interfaces.md（一期无接口/二期预设）、03_plan 三件套（M1-M4、R1-R6、D1-D4）
+
+## Check
+- 覆盖：SOP 14 步全部映射，每步有现状证据+方案+分期
+- 一致性：一期范围与验收 v2 一致（任务侧字段落地形式细化为扩展表，语义不变）；不新扩范围
+- 证据：关键判断均有文件:行号级证据
+
+## Act
+- 更新 summary/status/decision_log；问题 Q4-1（鉴权）、Q4-2（分期确认）、Q4-3（死字段修复列二期）
+- 等待人类确认方案 → 冻结后进入 M2（DDL 编写）
@@ -0,0 +1,21 @@
+# Round {{round}}
+
+## Plan
+- WWH 填充度：
+- 本轮目标：
+- 需要读取的资产与资料：
+- 需要提出的问题：
+
+## Do
+- 资产读取：
+- 分析与产出：
+- 提问：
+
+## Check
+- 目标覆盖：
+- 证据充分性：
+- 逻辑一致性：
+
+## Act
+- 更新 summary/decision_log/session
+- 规划下一轮
@@ -0,0 +1,10 @@
+# Status
+
+- 当前阶段：架构设计（Arch）— **已暂停（用户指令）**
+- 当前轮次：4
+- 阻塞问题：方案冻结（Q4-2）暂停待议；用户提出先做原型
+- 关键决策：扩展表模式（AD-1）；只存不算（AD-2）；分期方案未冻结
+- 最近更新：2026-07-22
+
+## 下一步
+- 用户决定是否先出原型（storyinfo AI 区块 / 会议附件 / 代码审查 / 工作日志 页面原型）→ 再回方案冻结门禁；M2 DDL 暂停
@@ -0,0 +1,6 @@
+# Summary
+- 2026-07-22: 初始化项目，进入 Round 1。
+- 2026-07-22 [PM][Round 1]: 摄入两份需求输入（SOP流程PDF、绩效考核XLSX）→ 01_input/requirements.md 结构化；P0×2 提出。
+- 2026-07-22 [PM][Round 1 关闭]: 用户确认 Q1-1（总目标=SOP+绩效全落地）、Q1-2（MVP=全生命周期数据模型）、Q1-3（自研平台、数据自有）。P0 关闭。
+- 2026-07-22 [PM][Round 2]: 深挖 codes/zentao → 缺口 2 新表+2 字段 → 验收标准 v2（AC-1~5）；用户逐项裁定 Q2-1（不含 Controller/DDL 入 sql 目录）、Q2-2（激活时间复用 activateddate）、Q1-4（W 由 AI 框架算、zentao 只存不算）→ **用户确认 v2，需求与验收阶段关闭**。
+- 2026-07-22 [PJM][Round 3]: demand-assessor 七步评估完成（技能位于 .claude/skills/）：S=4 B=1.6 F(T)=1.6，安全门触发（全项目仅 1 空壳测试，覆盖率<20%）→ G(A)=1.0，**W=10.2**，风险中，建议 AI 主导+人类把控 DDL 评审+AC-4 单测对冲。待用户提供 story-id 提交禅道。
@@ -0,0 +1,55 @@
+# Requirements
+
+## 背景与目标
+
+信息技术部推行「AI 下的开发 SOP」与配套绩效考核方案：以 AI 辅助完成 PRD 生成、工作量评估、任务拆分、代码审查、测试与文档沉淀，并以「工作量指数」为核心度量，对 9 个岗位进行月度绩效考核。[SRC-001][SRC-002]
+
+本项目（zentao / IT 工作台）被普遍预期为承载该 SOP 流程流转与绩效数据统计的平台，但**具体交付物与范围尚未确认**（见 questions/round_1.yaml Q1-1）。[ASSUMPTION]
+
+## 需求概述
+
+### 一、开发 SOP 流程（SRC-001，流程图）
+
+1. 业务部门提出用户需求 → 评审用户需求、激活
+2. 初次讨论明确用户需求（正式会议需产出会议纪要）
+3. AI 生成初版 PRD 和原型图
+4. 评审讨论初版 PRD，进一步细化需求（向 IT 工作台提交会议纪要、讨论的 PRD 文档）
+5. 文档与真实需求有较大偏差 → 返回 3；无偏差 → 生成最终版 PRD 和原型图
+6. AI 评估 PRD 工作量指标，并生成研发需求、指定完成时间（IT 工作台生成研发需求：工作量指标、完成时间、PRD 文档）
+7. AI 辅助生成架构设计文档、需求成功验收指标、需求测试用例文档
+8. 评审确认各文档（向 IT 服务台提交验收指标、测试用例文档）
+9. AI 拆分任务，按工作量指标评估每个任务的工时并分配（向 IT 服务台提交研发任务）
+10. 开发人员开发实施
+11. 开发任务全部完成后，AI 进行代码审查；审查不通过 → 返回 10
+12. 提交测试人员（向 IT 服务台提交代码审查报告）
+13. 按测试用例实施测试并提交 BUG → 开发修复 → 测试复测 → 提交测试报告（向 IT 服务台提交）
+14. 完成需求研发，更新系统 AI 文档；AI 提交工作日志（向 IT 服务台提交需求的工作日志）→ 结束
+
+### 二、需求全生命周期数据模型（SRC-001，思维导图）
+
+- **用户需求**：需求内容、创建人、创建时间、审批时间、激活时间；需求讨论会（一次/二次）：会议时间、参与人、会议纪要、讨论的 PRD 附件
+- **研发需求**：最终版 PRD 文档；AI 评估工作量指标（功能单元数量、功能单元复杂度、AI 参与率、工作量指数）；需求完成时间、成功验收标准、测试用例文档
+  - **研发任务**：开发人员、AI 评估的任务工作量指数、开始时间、完成时间、实际工时
+  - **测试任务**：测试人员、测试开始/结束时间；BUG（提交人、责任人、修复状态）；测试报告
+- **AI 代码审查报告**：审查事项、审查结果
+- **AI 工作日志**：PRD 各版本生成时间、PRD 工作量指标评估时间与结果、架构设计时间/评审时间/评审结果、任务拆分时间、AI 门禁检查时间与结果、AI 代码审查时间与结果、文档更新时间
+
+### 三、绩效考核方案（SRC-002，9 个岗位 sheet）
+
+跨岗位核心指标：
+
+- **工作量指标完成率** = Σ(月度需求/PRD 工作量指数) ÷ (团队可用工作天数 × 5)（项目经理 0.3、产品经理 0.2、产品助理 0.5 等权重）；=100% 满分，按缺口扣分
+- **版本计划完成率** = Σ(按时发布需求工时) ÷ Σ(所有需求工时) ≥95%
+- **线上 Bug 率** = Σ(当月上线需求线上 Bug 数) ÷ Σ(上线需求开发工时) ≤5‰；普通 Bug / 重大 Bug 分级扣分（重大 Bug 定义：影响上游回传数据、财务数据、大面积影响）
+- **开发岗**：任务及时完成率（0.25）、Bug 密度 ≤15%（0.3，连续 3 个月达标可返还半年扣分）、代码质量（AI 审查：严重问题 1 处扣 3 分；复审严重问题 1 处扣 5 分）、工作量饱和度（月度达标工时 = 团队总工作天数×5 ÷ 开发人员数）
+- **测试岗**：测试计划及时率、测试文档齐备、缺陷检出率 >20%（普通 Bug×1 + 重大 Bug×5 ÷ 测试需求开发工时）、线上 Bug
+- **文档齐备考核**：大型需求（AI 评估工作量指数 >20）必须产出《需求测试用例》《需求测试报告》《AI 项目文档更新记录》《AI 代码审查报告》《AI 工作日志》，缺失扣分
+
+## 证据/参考
+
+| ID | 资料 | 说明 |
+|---|---|---|
+| SRC-001 | `01_input/references/AI下的开发SOP流程（新版）.pdf` | 5 页：开发 SOP 流程图 + 需求全生命周期数据模型 |
+| SRC-002 | `01_input/references/信息技术部绩效考核标准-新版 - AI下的考核方案.xlsx` | 9 个岗位 sheet：项目经理、项目经理(王宇航)、产品经理、产品助理、后端开发、前端开发、测试、UI、运维 |
+
+补充观察：codes/zentao 根目录已存在多份绩效相关 xlsx（2026-04-01绩效.xlsx、各岗位考核表），与 SRC-002 体系一致 [ASSUMPTION: 现行考核已在线下执行]。assets/codemap、assets/domainmap 现有资产描述的是订单/卡券/调度等业务系统（被管理系统），与本需求的 IT 工作台平台相关性待确认 [ASSUMPTION]。
@@ -0,0 +1,41 @@
+# 验收标准（草案 v2，待用户确认）
+
+> v2 变更：激活时间确认复用 `zt_story_user.activateddate`；本期边界明确为「DDL+实体+Mapper+Service，不含 Controller」（PM 依需求解读决定，用户授权）；DDL 路径定为 `codes/zentao/sql/`；Q1-4 核实结论附文末。
+
+本期 MVP 范围：**需求全生命周期数据模型落地**（Q1-2 确认）。项目总目标（SOP 流程流转 + 绩效统计）不在本期验收范围内。
+
+## 范围界定
+
+- 含：缺口表的 DDL、实体/Mapper/Service 生成、字段-需求映射验证、单元测试
+- 不含：Controller 层 CRUD 接口（属后续流程/页面阶段）、SOP 流程状态流转逻辑、绩效统计算分、前端页面、AI 自动评估能力
+
+## 数据项映射与缺口分析（证据：SRC-001 思维导图 vs 现有代码）
+
+| SRC-001 数据项 | 现状（证据） | 缺口 |
+|---|---|---|
+| 用户需求：内容/创建人/创建/审批时间 | `ZtStoryUser.java:111,120` openeddate/approveddate | 复用，无缺口 |
+| 用户需求：激活时间 | `ZtStoryUser.java:153` **activateddate（已存在，用户指出并核实）** | 复用，无缺口 |
+| 需求讨论会：会议时间/参与人/纪要 | `ZtMeeting.java:47,52,73` meetingDate/users/result | 复用，无缺口 |
+| 讨论会 PRD 附件 | `ZtFile.java` 通用附件表 | objectType 取值约定 → Arch 阶段给方案 |
+| 研发需求：AI 工作量指标 | `ZtStoryExpand.java` numberUnits/unitBusinessComplexity/technicalComplexityCoefficient/aiEfficiencyCoefficient/evaluationTime/workloadIndex | **缺「AI 参与率」字段** |
+| 研发任务：AI 评估任务工作量指数 | `ZtTask.java` estimate/consumed/left 为人工工时 | **缺任务级 AI 工作量指数字段** |
+| 测试任务/BUG/测试报告 | `ZtTesttask.java`、`ZtBug.java`、`ZtCase.java` | 复用，无缺口 |
+| AI 代码审查报告（审查事项、审查结果） | 全库 grep 无命中 | **净新增表** |
+| AI 工作日志（8 类：PRD版本/工作量评估/架构设计/架构评审/任务拆分/门禁检查/代码审查/文档更新） | 全库 grep 无命中 | **净新增表** |
+
+## 验收条目
+
+- **AC-1 DDL 交付**：新增 `zt_ai_code_review`（AI代码审查报告：需求关联、审查事项、审查结果、是否通过、审查时间）、`zt_ai_work_log`（AI工作日志：需求关联、日志类型枚举覆盖 SRC-001 全部 8 类、内容/结果、发生时间）两张表；`zt_story_extend` 增加 AI 参与率字段；任务侧增加 AI 工作量指数字段。DDL 脚本含变更说明头，存放于 `codes/zentao/sql/`（新建目录）。
+- **AC-2 实体规范**：新表实体/Mapper/Service 按现有规范生成（`zt_` 前缀、MyBatis-Plus 无注解驼峰映射、`conf/CodeGenerator.java` 生成、Lombok），项目编译通过。
+- **AC-3 映射完整性**：SRC-001 思维导图全部数据项均有字段级映射（上表「复用」项逐一核对落库字段名，缺口项由 AC-1 覆盖），映射表随交付物归档。
+- **AC-4 单测**：新增 Service 方法单测覆盖正常路径 + ≥1 异常/边界路径，全部通过（tgassist Dev 强制规则）。
+- **AC-5 无回归**：现有代码编译与已有测试不因本期改动失败。
+
+## 附：Q1-4 核实结论（用户澄清 + 证据）
+
+**架构边界（用户确认）：工作量指数不在 zentao 计算，由 AI 框架（本框架）计算后上传至 zentao 存储。zentao 只存不算。**
+
+- 上传通道已存在：`ZtStoryExpandController.java:23`（`/zt-story-expand`）→ `zt_story_extend.workloadIndex` 等字段
+- 代码佐证：`ZtStoryExpandServiceImpl.java:114-117` workloadIndex 为外部传入/DB 已有值，无源头计算 —— 与该边界一致
+- 推论：本期新增的 AI 参与率字段同样「只存不算」；`zt_ai_code_review`、`zt_ai_work_log` 后续阶段需参照 `/zt-story-expand` 模式补上传接口（记入后续计划，不在本期范围）
+- 另注：tgassist 提到的 demand-assessor 技能本机不存在（`.kimi-code/skills/` 仅 tgassist），本项目自身的「工作量评估」阶段需另行处理
@@ -0,0 +1,16 @@
+# 验收检查清单（对应 acceptance.md v1）
+
+## DoD 检查项
+
+- [ ] AC-1 `zt_ai_code_review` 表 DDL（含变更说明头，字段覆盖：需求关联、审查事项、审查结果、通过标志、审查时间）
+- [ ] AC-1 `zt_ai_work_log` 表 DDL（日志类型枚举覆盖 SRC-001 全部 8 类）
+- [ ] AC-1 `zt_story_extend` AI 参与率字段 DDL
+- [ ] AC-1 任务级 AI 工作量指数字段 DDL
+- [ ] AC-2 新实体/Mapper/Service 按规范生成，项目编译通过
+- [ ] AC-3 SRC-001 数据项映射表归档（复用项字段名逐一核对）
+- [ ] AC-4 新增 Service 单测通过（正常 + 异常/边界），结果记录至 05_delivery/dev_log.md
+- [ ] AC-5 现有编译/测试无回归
+
+## 签字确认
+
+- [x] 用户确认验收标准（本文件与 acceptance.md）— 2026-07-22 确认 v2
@@ -0,0 +1,8 @@
+# 依赖登记
+
+| ID | 依赖 | 影响 | 状态 |
+|---|---|---|---|
+| D1 | AI 框架侧（本框架/demand-assessor）上传报文格式 | 二期接口字段需与其对齐 | 一期不阻塞；demand-assessor submit_assessment.py 报文可作参照 |
+| D2 | 生产 DB（itsm MySQL）变更窗口与备份 | M2 DDL 落库 | 待用户安排 |
+| D3 | zentao 需求单（本项目自身 W=10.2 补登用） | 仅考核记账，不阻塞开发 | 暂缓（裁剪留痕） |
+| D4 | 前端公共上传组件 src/components/upload | 二期页面改动依赖 | 已存在，34 处引用 |
@@ -0,0 +1,16 @@
+# 里程碑计划（W=10.2 作为输入，风险等级：中）
+
+## 一期（本期 MVP：数据模型落地）
+
+| 里程碑 | 内容 | 出口标准 |
+|---|---|---|
+| M1 方案冻结 | 04_design 三件套用户确认 | 设计冻结，变更走变更单 |
+| M2 DDL 就绪 | codes/zentao/sql/ 下 4 个 DDL 脚本（3 新表+1 加列），含变更说明头，可重入 | 用户评审 DDL 通过 |
+| M3 实体与单测 | 实体/Mapper/Service 生成，编译通过；新 Service 单测（正常+异常路径）全过 | AC-2/AC-4 |
+| M4 验收归档 | 映射表归档（AC-3）、无回归确认（AC-5）、dev_log 完整 | checklist 全勾，进入验收评审 |
+
+排期建议：W=10.2 人日 ≈ 1 人 2 周（含评审往返）；G(A)=1.0 的解读：安全门因测试欠账触发，单测补齐（AC-4）是本期硬要求而非可选项。
+
+## 二期（预排）：上传接口 + 展示打通（立项时重新评估 W）
+
+## 三期（预排）：绩效消费（IZtCountService 接入 AI 指标 → 9 岗位自动算分）
@@ -0,0 +1,10 @@
+# 风险登记
+
+| ID | 风险 | 等级 | 应对 |
+|---|---|---|---|
+| R1 | 无迁移工具，DDL 手工执行；zt_story_extend 生产加列 | 中 | DDL 含变更说明头+可重入；生产执行前备份+用户评审（M2 出口） |
+| R2 | 项目测试覆盖率 <20%（安全门已触发，G(A)=1.0） | 中 | AC-4 新 Service 强制单测；验收以编译+单测+映射核对为准 |
+| R3 | 上传接口无鉴权先例（saveOrUpdate 直连） | 中 | 一期无接口不触发；Q4-1 二期前决策 |
+| R4 | approveddate/activateddate 死字段（用户需求时间链断点） | 低 | 二期小改补写；本期映射表标注 |
+| R5 | /common/upload 未绑定文件 objectType=null，数据卫生 | 低 | 二期附件打通时统一绑定；本期不涉及 |
+| R6 | 一期只落模型无入口，短期"看不见成果" | 低 | 已在方案中明示分期；storyinfo AI 区块二期即有可视产出 |
@@ -0,0 +1,33 @@
+# 架构设计：AI 开发 SOP × IT 工作台现有功能（v1 待确认）
+
+设计原则：最大复用现有 zt_* 功能；AI 侧数据一律「框架算、平台存」（用户确认的边界）；新增一律沿用 `zt_story_extend` 扩展表先例，不改禅道老表结构（zt_task 等）。
+
+## 一、SOP 流程逐环节映射（证据：SRC-001；代码证据见行号）
+
+| # | SOP 环节 | 提交物 | 现有功能（证据） | 差距 | 方案 | 分期 |
+|---|---|---|---|---|---|---|
+| 1 | 需求提出→评审激活 | 用户需求 | 全流程已有：`/zt-story-user` userReview 评审通过→active+revieweddate（ZtStoryUserServiceImpl.java:562-578）；前端 userstoryinfo 评审按钮 | `approveddate/activateddate` 死字段（全库无写入） | 小改：userReview 通过时补写 activateddate | 二期 |
+| 2 | 初次讨论 | 会议纪要+PRD 附件 | `/zt-meeting` 有 result 富文本纪要、storyIds 关联需求、PDF 导出；后端附件绑定已就绪（FileTypes.meeting，ZtMeetingServiceImpl.java:159） | **前端附件 UI 已引入未渲染**（addDialog/editDialog 无 `<uploads>`） | 前端渲染 uploads 组件 + 详情页附件区块 | 二期 |
+| 3-5 | AI 生成 PRD→评审→最终版 | PRD 文档/原型图 | 通用上传 `/common/upload`+zt_file；需求/用户需求附件区块已有（FileTypes.story/userStory） | 无 PRD 版本记录 | 不建版本表：PRD 每版生成时间记入 zt_ai_work_log（log_type=prd_version）——KISS | 一期建表/二期打通 |
+| 6 | AI 评估工作量→生成研发需求 | 工作量指标 | **通道已通**：`/zt-story-expand/saveOrUpdate`（demand-assessor 已对接生产）；指标在统计页 /worktime/count 展示 | ①缺 AI 参与率字段 ②storyinfo 详情页无指标区块（孤岛） | ①zt_story_extend 加列 ai_participation_rate ②详情页加 AI 指标区块 | ①一期 ②二期 |
+| 7-8 | 架构设计/验收指标/测试用例 | 验收指标、用例文档 | 验收标准=zt_storyspec.verify 富文本；用例=zt_case+story-case 评审链；附件通道通用 | 验收指标无结构化（富文本可承载，暂不结构化） | 本期复用 verify+附件；结构化验收指标表→后续按需 | 复用 |
+| 9 | AI 拆分任务/评估工时/分配 | 研发任务 | 任务全流程已有（拆分/指派/zt_effort 工时） | 任务级 AI 工作量指数缺失；zt_task 是禅道老表不宜加列 | **新建 zt_task_extend 扩展表**（沿用 zt_story_extend 先例） | 一期建表 |
+| 10-11 | 开发→AI 代码审查（可回炉） | 代码审查报告 | 完全不存在（全库 grep 零命中） | 净新增 | **新建 zt_ai_code_review** + 上传接口（二期） | 一期建表 |
+| 12-13 | 测试→BUG→复测→报告 | BUG、测试报告 | BUG 全流程已有（/zt-bug）；测试报告无承载（zt_testtask.report 死字段） | 测试报告无上传入口 | FileTypes 加 testReport + 附件入口 | 二期 |
+| 14 | 工作日志/AI 文档更新 | AI 工作日志 | 完全不存在 | 净新增 | **新建 zt_ai_work_log**（8 类 log_type 覆盖 SRC-001 全部日志项） | 一期建表 |
+
+## 二、架构决策
+
+- **AD-1 扩展表模式**：AI 类指标一律进扩展表（zt_story_extend / zt_task_extend / zt_ai_*），不碰 zt_task、zt_story 等禅道老表。依据：zt_story_extend 先例 + 禅道升级兼容。
+- **AD-2 AI 数据统一上传模式**：所有 AI 侧数据（W 值、代码审查、工作日志、AI 参与率）由 AI 框架计算后经 saveOrUpdate 类接口写入，zentao 只存不算（用户确认边界）。上传接口鉴权策略待决（Q4-1：现状 saveOrUpdate 无 token 直连，见 itsm_post.py）。
+- **AD-3 文档类走 zt_file 通用通道**：PRD/原型图/测试报告不建专用表，FileTypes 扩展 testReport；PRD 版本时间进 zt_ai_work_log。
+- **AD-4 展示打通集中二期**：storyinfo 增 AI 区块（指标/审查/日志）、meeting 附件渲染、测试报告入口——均为前端轻改，后端一期仅落模型。
+- **AD-5 绩效消费三期**：IZtCountService 目前完全不消费 zt_story_extend（孤岛），三期按 SRC-002 公式接入工作量指数完成率等指标。
+
+## 三、分期方案
+
+| 期 | 内容 | 验收依据 |
+|---|---|---|
+| **一期（本期 MVP，W=10.2）** | 数据模型：zt_ai_code_review、zt_ai_work_log、zt_task_extend 三张新表 + zt_story_extend 加列；DDL+实体+Mapper+Service+单测 | acceptance v2（AC-1~5），注：任务侧字段落地形式由"加列"细化为"扩展表"，验收条目语义不变 |
+| 二期 | 上传接口（/zt-ai-code-review、/zt-ai-work-log）+ 展示打通（storyinfo AI 区块、meeting 附件、测试报告入口）+ activateddate 补写 | 待二期立项评估 |
+| 三期 | 绩效消费：IZtCountService 接入 AI 指标，9 岗位考核公式自动化（SRC-002） | 待三期立项评估 |
@@ -0,0 +1,53 @@
+# 数据模型设计（一期 DDL）
+
+风格约束：zt_ 前缀；审计字段沿用现有表惯例（create_user/create_time/update_user/update_time）；String 存数值沿用 zt_story_extend.workloadIndex 先例（框架传什么存什么，平台不计算）。DDL 脚本交付于 `codes/zentao/sql/`，含变更说明头。
+
+## 1. zt_ai_code_review（AI 代码审查报告）——SRC-001「审查事项、审查结果」
+
+| 字段 | 类型 | 说明 |
+|---|---|---|
+| id | int PK AI | |
+| story_id | int NOT NULL | 关联研发需求 zt_story.id，建索引 |
+| task_id | int NULL | 可选关联任务（按任务审查时） |
+| round | int DEFAULT 1 | 审查轮次（SOP 允许打回重审） |
+| review_item | text | 审查事项（清单/JSON 文本） |
+| review_result | varchar(20) | 审查结果：pass / reject |
+| review_detail | text | 结果详情（问题列表、严重度） |
+| review_time | datetime | 审查时间 |
+| create_user / create_time / update_user / update_time | 审计字段 | |
+
+## 2. zt_ai_work_log（AI 工作日志）——SRC-001 八类日志
+
+| 字段 | 类型 | 说明 |
+|---|---|---|
+| id | int PK AI | |
+| story_id | int NOT NULL | 关联研发需求，建索引 |
+| log_type | varchar(32) NOT NULL | 枚举：prd_version / workload_eval / arch_design / arch_review / task_split / gate_check / code_review / doc_update（与 SRC-001 思维导图 8 项一一对应），联合索引 (story_id, log_type) |
+| content | text | 日志内容（如 PRD 版本号、评估结果快照） |
+| result | varchar(255) | 结果（如评审通过/不通过） |
+| happen_time | datetime | 事件发生时间（AI 框架侧时间） |
+| create_time | datetime | 入库时间 |
+
+## 3. zt_task_extend（任务扩展表）——SRC-001「AI 评估的任务工作量指数」
+
+| 字段 | 类型 | 说明 |
+|---|---|---|
+| id | int PK AI | |
+| task_id | int NOT NULL UNIQUE | 关联 zt_task.id |
+| ai_workload_index | varchar(16) | AI 评估任务工作量指数（只存不算，风格同 zt_story_extend.workloadIndex） |
+| evaluation_time | varchar(16) | AI 评估工时（对齐需求级字段命名） |
+| create_user / create_time / update_user / update_time | 审计字段 | |
+
+## 4. zt_story_extend 加列
+
+| 字段 | 类型 | 说明 |
+|---|---|---|
+| ai_participation_rate | varchar(16) | AI 参与率（只存不算，口径由 AI 框架定，注释标「口径待定」） |
+
+## 5. 复用不改动的表（映射核对清单，AC-3）
+
+用户需求 zt_story_user（openeddate/revieweddate/activateddate*死字段二期补写）、会议 zt_meeting（result/storyIds + FileTypes.meeting）、附件 zt_file、验收标准 zt_storyspec.verify、任务工时 zt_task+zt_effort、BUG zt_bug、用例 zt_case、需求级 AI 指标 zt_story_extend。
+
+## 6. 二期预备（不进一期 DDL）
+
+FileTypes 枚举加 testReport；枚举实体 LogTypeEnums 随一期实体生成（Java 侧枚举，不落库表）。
@@ -0,0 +1,32 @@
+# 接口设计
+
+## 一期（本期）：无新增接口
+
+边界已确认（Q2-1）：一期只到 实体+Mapper+Service，不含 Controller。新表 Service 接口（Java 层）：
+
+- `IZtAiCodeReviewService`：saveOrUpdate(ZtAiCodeReview)、listByStoryId(storyId)
+- `IZtAiWorkLogService`：saveBatch(storyId, List<ZtAiWorkLog>)、listByStoryId(storyId, logType)
+- `IZtTaskExtendService`：saveOrUpdate(ZtTaskExtend)、getByTaskId(taskId)
+- `IZtStoryExpandService`：既有方法不变，实体加 aiParticipationRate 字段（saveOrUpdate 自动携带）
+
+## 二期（预设计，立项时评审）
+
+### AI 框架上传接口（参照 /zt-story-expand 模式，platform 只存不算）
+
+| 端点 | 方法 | 报文要点 |
+|---|---|---|
+| `/zt-ai-code-review/saveOrUpdate` | POST | storyId, taskId?, round, reviewItem, reviewResult(pass/reject), reviewDetail, reviewTime |
+| `/zt-ai-work-log/saveBatch` | POST | storyId, logs[{logType, content, result, happenTime}] |
+
+### 前端页面改动清单
+
+| 页面 | 改动 | 证据/备注 |
+|---|---|---|
+| meeting add/editDialog + info | 渲染 `<uploads>`（组件已 import 未渲染）+ 附件区块 | FileTypes.meeting 后端已就绪 |
+| storyinfo 详情 | 新增「AI 指标」区块（读 zt_story_extend 含 AI 参与率）、「代码审查」「工作日志」区块 | 参照 projectWork.vue 既有指标列 |
+| bug/testtask 相关页 | 测试报告上传入口 | FileTypes.testReport（二期 DDL） |
+| userstoryinfo | 无改动（activateddate 后端补写即可） | |
+
+## 鉴权决策点（Q4-1，二期前必须回答）
+
+现状：`/zt-story-expand/saveOrUpdate` 无 token 直连（itsm_post.py 实证，仅 Content-Type 头）。新上传接口三选一：沿用内网直连 / 加签名 / 纳入 JWT。倾向：沿用现状保持通道一致，风险记入 risks.md。
@@ -0,0 +1,5 @@
+# Change Log
+
+| Change | Reason | Impact | Decision | Date |
+|---|---|---|---|---|
+|  |  |  |  |  |
@@ -0,0 +1,90 @@
+# 开发日志 (05_delivery/dev_log.md)
+
+> **项目**: {project_name}
+> **更新规则**: 每个任务完成或有重要产出时更新；单元测试执行后**必须**填写"单元测试记录"区块
+
+---
+
+## 任务状态总览
+
+| 任务 | 负责人 | Day | 状态 | 完成时间 | 备注 |
+|------|--------|-----|------|----------|------|
+| T-xxx | — | — | ⬜ 待开始 | — | — |
+
+> 状态说明：✅ 完成 / 🔄 进行中 / ⬜ 待开始 / ❌ 阻塞
+
+---
+
+## 开发日志详情
+
+### {YYYY-MM-DD} | Round N | Dev Assist — {任务编号} {任务名称}
+
+**PDCA 阶段**: Do — 代码产出
+
+**本轮产出**:
+
+| 文件 | 模块 | 说明 |
+|------|------|------|
+| — | — | — |
+
+**关键设计决策**:
+- （记录影响后续维护的设计选择）
+
+**DoD 验证清单**:
+- [ ] ...
+
+**遗留问题**:
+- （无则写"无"）
+
+---
+
+## 单元测试记录
+
+> ⚠️ **强制要求**：每个任务的单测必须在进入 Check 阶段前完成并记录。
+> 单测未通过或未记录 = DoD 未达成 = 禁止推进下一阶段。
+
+### {任务编号} {任务名称} — 单测计划与结果
+
+**执行时间**: {YYYY-MM-DD HH:MM}
+**执行人**: {name}
+**测试框架**: JUnit 5 / Mockito（或实际使用框架）
+
+#### 单测结果明细
+
+| 测试类 | 测试方法 | 场景描述 | 结果 | 备注 |
+|--------|----------|----------|------|------|
+| `XxxServiceTest` | `testSave_success` | 正常创建，返回主键 | ✅ PASS | — |
+| `XxxServiceTest` | `testSave_missingOrderNo` | 订单号为空，抛 BusinessException | ✅ PASS | — |
+| `XxxServiceTest` | `testSave_invalidProvider` | 服务商不存在，抛 BusinessException | ✅ PASS | — |
+| `XxxServiceTest` | `testList_emptyResult` | 无数据时返回空 Page | ✅ PASS | — |
+
+> 结果说明：✅ PASS / ❌ FAIL / ⚠️ SKIP（须注明原因）
+
+#### 覆盖率摘要
+
+| 类 | 方法数 | 已覆盖 | 覆盖率 | 是否达标（≥80%） |
+|----|--------|--------|--------|-----------------|
+| `XxxService` | — | — | —% | — |
+
+> 覆盖率低于 80% 须填写原因，并获得人类确认后方可推进：
+> - 原因：
+> - 确认人：
+> - 确认时间：
+
+#### 失败/跳过明细（若有）
+
+| 测试方法 | 失败原因 | 修复状态 | 修复时间 |
+|----------|----------|----------|----------|
+| — | — | — | — |
+
+---
+
+## 变更记录
+
+> 暂无变更
+
+---
+
+## 阻塞记录
+
+> 暂无阻塞
@@ -0,0 +1,5 @@
+# Defects
+
+| ID | Summary | Severity | Status | Evidence |
+|---|---|---|---|---|
+|  |  |  |  |  |
@@ -0,0 +1,5 @@
+# Regression
+
+| Version | Cases | Pass | Fail | Notes |
+|---|---|---|---|---|
+|  |  |  |  |  |
@@ -0,0 +1,5 @@
+# Test Cases
+
+| Case | Scope | Steps | Expected | Status |
+|---|---|---|---|---|
+|  |  |  |  |  |
@@ -0,0 +1,5 @@
+# Decision
+
+| Item | Decision | Owner | Due | Status |
+|---|---|---|---|---|
+|  |  |  |  |  |
@@ -0,0 +1,7 @@
+# Review
+
+## Summary
+
+## Issues
+
+## Decision
@@ -0,0 +1,7 @@
+# Release Notes
+
+## Highlights
+
+## Changes
+
+## Risks