feat: 根目录文档、脚本、gitignore
This commit is contained in:
@@ -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
|
||||
- 规划下一轮
|
||||
Reference in New Issue
Block a user