QC评分协议技能：review-requirement/design/develop重写(契合度>9.5+硬门禁)、agent.qc统一评分、agent.pm复盘章节、sdlc-repo-standard复盘报告规范

skills_library/all/sdlc-repo-standard/SKILL.md

@@ -92,3 +92,12 @@ projects/{项目名}/docs/01-design/modules/{模块名}/
   - 每个阶段检查交付件已受控提交
   - develop: 必须检查机构 `apps/{应用名}/`、`modules/{模块名}/` 对应仓库有 git commit
   - 每个阶段检查 `{应用名}_spec.json` 是否随进度更新
+
+### 项目复盘（PM，项目完结后的回顾任务）
+- **落点**: `projects/{项目名}/docs/02-retrospective/retrospective.md`
+- **内容结构**（五段，缺一不合格）:
+  1. 统计：问题总数 / 可复用数 / 提议数；重做次数、冒泡次数、Bug 数、工期
+  2. 问题清单：逐条列出（类型：冒泡/退回/缺口/Bug，问题，解决方法）
+  3. 提议清单：每条提议的名称 + 目标技能（修改哪个/新建）
+  4. 未提提议的问题及理由（一次性问题写明为何不可复用）
+  5. 结论：本项目沉淀的可复用经验一句话总结

skills_library/pipelines/sdlc_general/roles/agent.pm/role/SKILL.md

@@ -23,3 +23,26 @@ capability: task_capability
 ## 应遵守的规范（审核/派发前先 load_skill 加载对应全文，不要凭记忆瞎写）
 - `project-directory-spec`：各阶段交付件落点路径（检查交付件是否在正确位置）
 - `sdlc-repo-standard`：各阶段交付件的内容格式与产出行为准则
+
+## 项目复盘（项目完结后的回顾任务，task_kind='retrospective'）
+
+项目执行完（最后一个任务 review_complete）后，你会收到一个「项目复盘」任务。目标：把本项目遇到的问题和处理方法沉淀为技能提议，让同类问题在下个项目被预防。
+
+### 流程
+
+1. 调 `project_retrospective_data` 工具拿结构化素材（四类问题源已合并：冒泡问题+解决方法、退回重做+意见、编排缺口、Bug+修复说明），不要自己拼 SQL 查。
+2. 逐条判定**可复用性**：
+   - **可复用**（跨项目可能再发生，如「Flask 框架误用」「字段类型映射错误」「部署声称 200 未实测」）→ 生成技能提议
+   - **一次性**（本项目特有的业务理解偏差、需求歧义等）→ 只写进复盘报告，不提提议
+   - 复盘报告必须写明「未提提议的问题及理由」，判定质量可被人工复核
+3. 每条可复用问题生成一个提议，调 `propose_skill(name, description, content)`：
+   - **定位目标技能**：对照问题发生角色（develop 的问题 → agent.develop 或 QC 的 review-develop）+ 现有技能，判断是修改现有技能还是新建
+   - content 是 SKILL.md 草稿，**头部标目标**：`<!-- target: roles/agent.develop/review-develop（修改） -->` 或 `<!-- target: 新建 -->`
+   - content 强制四段：**触发条件 / 问题现象 / 根因 / 检查或处理方法**（从素材的 solution 提炼）。缺段的草稿 = 低质量提议，会被审核直接拒
+4. **去重**：提交前说明目标+要点；同目标同要点的问题只提一条提议（多个实例合并成一条，实例写进现象段）。
+5. 产出复盘报告：落盘 `projects/{项目}/docs/02-retrospective/retrospective.md`，内容 = 问题总数/可复用数/提议清单（含提议名）/未提议问题及理由/统计（重做次数/冒泡次数/Bug数/工期）。作为复盘任务的交付件提交。
+
+### 纪律
+
+- 提议只是草稿（进技能管理的建议列表，待人工审核），**不直接改技能库**——技能库是源头，改写必须走审核。
+- 复盘就事论事：问题归因到「规范/流程缺了什么」，不归咎到某个 agent 个体；提议内容写「下次怎么防」，不写「谁犯了错」。

skills_library/pipelines/sdlc_general/roles/agent.qc/review-design/SKILL.md

@@ -1,39 +1,68 @@
 ---
 name: review-design
-description: QC 审查系统设计师（agent.design）产出的检查清单——架构/ui-design 落盘、模块划分与依赖、数据库设计（字段类型映射/无外键/编码字典）。触发：审查 design 阶段交付件。
+description: QC 审查系统设计师（agent.design）产出的检查协议——A组需求覆盖矩阵（硬门禁：每个原始需求点至少一个功能覆盖）+B组设计专家维度（划分/数据库/架构合理性）+C组合规，契合度=10×通过项/总项，>9.5 放行。触发：审查 design 阶段交付件。
 capability: task_capability
 ---
 
 # 审查系统设计师（agent.design）产出
 
-被查对象：agent.design。审查其产出时逐项核对，任一项不合格即 review_reject 并列出问题。
+被查对象：agent.design。
 
-## 一、应用级设计落盘（对照 project-directory-spec + web-application-spec + module-development-spec）
+## 审查流程（先构建核对项，再逐项判定，最后算分）
 
-- 对照 `project-directory-spec`：
-  - `projects/{项目}/docs/01-design/architecture.md`（架构 + 模块划分 + 模块间依赖 + 开发顺序）
-  - `projects/{项目}/docs/01-design/ui-design.md`（视觉风格/布局/交互模式）
-- **应用与模块关系（关键，对照 web-application-spec + module-development-spec）**：
-  - 应用是唯一部署单元：一个应用 = 一个入口（`app/{应用名}.py`）= 一个端口。architecture.md 必须写明 app 清单——一个项目有几个 app 由 designer 按「部署单元/功能聚合/用户边界」划分，明确这是【单体应用】还是【多个应用】，并写出每个 app 的划分理由，**不能把功能模块设计成独立服务/微服务**
-  - 模块不是独立部署单元：每个模块是应用内的 Python 包，通过 `load_{module}()` 挂载到应用，**无独立 app.py / 端口 / Dockerfile / 服务**
-  - 目录结构：机构 `apps/{应用名}/`（应用仓库）+ `modules/{模块名}/`（模块仓库）。若只有模块仓库没有应用仓库，或模块仓库里带了 app.py / Dockerfile → 退回（违反 module-development-spec）
-  - 若 architecture.md 出现"四模块服务""每模块一个端口/容器"等设计 → 退回：这是把功能模块错误设计成微服务
+1. **收集**：读原始需求、设计交付件；用 `list_features` 查功能清单（覆盖矩阵的数据基础）。
+2. **构建核对项清单**：A 组（需求覆盖，硬门禁）+ B 组（设计专家维度）+ C 组（合规）。
+3. **逐项判定**：每项只输出 过/不过 + 证据。
+4. **算分**：契合度 = 10 × 通过项数 / 总项数（保留两位小数）。
+5. **决策**：契合度 > 9.5 且 A 组无未过项 → review_approve；否则 review_reject。
+   **A 组任一核对项不过 = 必退**（需求覆盖是硬门禁），即使总分 > 9.5 也不放行。
 
-## 二、模块级设计落盘
+## 必读文件
 
-- 每个模块：`projects/{项目}/docs/01-design/modules/{模块名}.md`（模块清单）+ `{模块名}/design.md`（数据设计/CRUD/处理逻辑）+ `{模块名}/skill/SKILL.md`（模块技能文档）
-- 模块划分 + 模块间依赖 + 开发顺序明确，PM 据此派发 develop 任务
-- 基础模块（apppublic/sqlor/ahserver/accounting/appbase/rbac）不列为待开发模块
+- 原始需求：`projects/{项目}/docs/00-requirement/requirement-spec.md`
+- 设计交付件：`projects/{项目}/docs/01-design/architecture.md`、`ui-design.md`、`modules/{模块名}.md` 及 `{模块名}/design.md`
+- 路径权威来源：先 load_skill 加载 `project-directory-spec`
 
-## 三、数据库设计（对照 database-design 规范）
+## A 组：需求覆盖矩阵（硬门禁）
 
-- **字段类型映射**：字段语义→类型是否正确（名称 str 255、金额 double 18/2、状态 str 16、业务日期 date 等）
-- **抽象类型**：禁原生类型 varchar/bigint/boolean/int(11)，一律 str/int/double/timestamp/date/text
-- **无外键**：表间不建 FOREIGN KEY，关联靠字段存 id + codes 段声明
-- **编码字典**：枚举字段（状态/类型）进 appcodes/appcodes_kv，init/data.json 定义，cond 用 parentid=
-- **表定义四段式**：models 表定义 summary/fields/indexes/codes 格式（design 阶段产出 DDL 设计）
+1. 从原始需求抽取**原始需求点清单**（#1、#2……，与需求分析阶段同源，若需求分析交付件里有编号清单则沿用）。
+2. 用 `list_features` 取全部功能点（含 description）。
+3. 构建覆盖矩阵：**每个原始需求点必须至少被一个功能点覆盖**（功能点的名称/描述能对应到该需求点的语义）。
+   - 任一需求点零覆盖 → 该项不过，且必退。退回意见指明「需求点 #N 无任何功能覆盖」。
+4. 反向核对：每个功能点必须能追溯回至少一个需求点。无追溯的功能点列为「镀金待说明」项——不直接判不过，但要求设计师说明理由（说明缺失才算不过）。
+5. 覆盖矩阵整体输出进核对记录（需求点 × 覆盖功能点），供人工复核。
 
-## 四、真实性核查方法
+## B 组：设计专家维度
 
-- 用 read_file / list_files 验证 architecture.md/ui-design.md/modules 真实落盘
-- 核对模块划分是否覆盖需求全部业务域，依赖顺序是否合理
+6. **应用/模块划分**（对照技能映射表加载）：
+   - 应用是唯一部署单元：一个应用 = 一个入口（app/{应用名}.py）= 一个端口；architecture.md 写明 app 清单 + 单体/多应用划分理由。把功能模块设计成独立服务/微服务/独立端口 → 不过。
+   - 模块是应用内 Python 包，无独立 app.py / 端口 / Dockerfile。
+7. **数据库设计**（对照技能映射表加载）：
+   - 字段语义→抽象类型映射正确（名称 str 255、金额 double 18/2、状态 str 16、业务日期 date）
+   - 禁原生类型 varchar/bigint/boolean/int(11)
+   - 表间无外键，关联靠字段存 id + codes 段声明
+   - 枚举字段进编码字典（appcodes/appcodes_kv，init/data.json 定义）
+   - 表定义四段式（summary/fields/indexes/codes）
+8. **架构合理性逐项**（把主观判断转成「有无论证」的机械核对）：
+   - 模块间依赖方向无环、开发顺序可行（依赖在前、被依赖在后）
+   - 设计说明写明**预期数据量/并发量及对应选型理由**——写不出规模假设 = 不过（无论证的架构选型不采信）
+   - 无微服务化倾向（「每模块一个端口/容器」类设计 = 不过）
+
+## C 组：合规项
+
+9. **文档落点**：architecture.md / ui-design.md / modules/{模块}.md + {模块}/design.md 齐全（对照 project-directory-spec）。
+10. **模块清单明确**：模块划分 + 模块间依赖 + 开发顺序明确（PM 据此派发 develop 任务）；基础模块（apppublic/sqlor/ahserver/accounting/appbase/rbac）不列为待开发模块。
+
+## 技能映射表（按核对内容必载，不凭记忆）
+
+| 核对内容 | 必载技能 |
+|----------|----------|
+| 文档落点/路径 | project-directory-spec |
+| 应用/模块划分 | web-application-spec、module-development-spec |
+| 数据库设计 | database-design |
+| 需求覆盖矩阵 | 无需技能，用 list_features + 原始需求原文 |
+
+## 输出要求
+
+- review_approve 的 comment：`契合度 X.XX（通过 n/总 m），需求覆盖 100%` + 核对摘要。
+- review_reject 的 questions：逐条 `[#编号] 位置：…… 问题：…… 改法：……`；A 组未过项必须置顶并标注「硬门禁」。

skills_library/pipelines/sdlc_general/roles/agent.qc/review-develop/SKILL.md

@@ -1,18 +1,42 @@
 ---
 name: review-develop
-description: QC 审查开发工程师（agent.develop）产出的检查清单——模块目录结构、表定义四段式、CRUD 格式、代码语法/禁项/注册接线/sqlor API、RBAC/i18n。触发：审查 develop 阶段交付件。
+description: QC 审查开发工程师（agent.develop）产出的检查协议——交付件类型驱动的技能映射表（表定义/CRUD/dspy/UI/注册各载对应规范技能）+逐项机械核对，契合度=10×通过项/总项，>9.5 放行。触发：审查 develop 阶段交付件。
 capability: task_capability
 ---
 
 # 审查开发工程师（agent.develop）产出
 
-被查对象：agent.develop。审查其产出时逐项机械检查，任一项不合格即 review_reject 并列出问题。
+被查对象：agent.develop。
+
+## 审查流程（先构建核对项，再逐项判定，最后算分）
+
+1. **判交付类型**（见下），用 list_files / read_file 实际看文件，不凭交付说明。
+2. **按技能映射表 load_skill 加载对应规范技能**，然后按技能规范逐项构建核对项清单。
+3. **逐项机械判定**：每项只输出 过/不过 + 证据（文件路径/行号/grep 结果）。第六章应用脚手架硬门禁项任一不过 = 必退（即使总分 > 9.5）。
+4. **算分**：契合度 = 10 × 通过项数 / 总项数（保留两位小数）。
+5. **决策**：契合度 > 9.5 且无硬门禁未过项 → review_approve（comment 附分数与核对摘要）；否则 review_reject（questions 逐条 `[#编号] 位置：…… 问题：…… 改法：……`）。
 
 **先判交付类型，再选检查章节**：
 - 交付**业务模块**（Python 包，机构 `modules/{模块名}/`）→ 查第一~五章
 - 交付**应用脚手架**（机构 `apps/{应用名}/`，有 `app/{应用名}.py` 入口）→ 查**第六章**（硬门禁）+ 第四、五章
 - 两者都交 → 两套都查
 
+## 技能映射表（按交付件内容必载，不凭记忆选技能）
+
+| 交付件内容 | 必载技能 |
+|------------|----------|
+| 目录结构/注册接线 | module-development-spec |
+| models/*.json 表定义 | database-table-definition-spec |
+| json/*.json CRUD | crud-definition-spec |
+| *.dspy 文件 | dspy-file-implementation-spec |
+| *.ui 页面 | web-application-spec |
+| RBAC 路径注册 | rbac-permission-initialization-pattern |
+| 应用脚手架（第六章） | web-application-spec |
+| 跨宿主复用模块（交付声明跨宿主时） | cross-app-module-reuse |
+| 文档落点 | project-directory-spec |
+
+映射表是活文档：新规范技能入库时须同步更新本表。
+
 ## 一、模块目录结构（对照 module-development-spec）
 
 - 包目录 = 模块名（`{模块名}/{模块名}/`），不是 src/

skills_library/pipelines/sdlc_general/roles/agent.qc/review-requirement/SKILL.md

@@ -1,35 +1,49 @@
 ---
 name: review-requirement
-description: QC 审查需求分析师（agent.requirement）产出的检查清单——功能清单是否落库 sd_features、需求文档路径、应用部署单元、部署环境需求。触发：审查 requirement 阶段交付件。
+description: QC 审查需求分析师（agent.requirement）产出的检查协议——先构建核对项清单（原始需求逐条契合+合规项），逐项机械判定，契合度=10×通过项/总项，>9.5 放行。触发：审查 requirement 阶段交付件。
 capability: task_capability
 ---
 
 # 审查需求分析师（agent.requirement）产出
 
-被查对象：agent.requirement。审查其产出时逐项核对，任一项不合格即 review_reject 并列出问题。
+被查对象：agent.requirement。
 
-## 一、功能清单是否真实落库（关键，别只信文档）
+## 审查流程（先构建核对项，再逐项判定，最后算分）
 
-- 用 `list_features` 查 sd_features：需求是否已拆解成功能点（propose_feature 落库）
-- **sd_features 应有 ≥1 条记录**（需求拆解出来的功能点），状态 proposed/approved
-- 若功能清单只在文档里写了、sd_features 却是 0 条 → 退回：功能未用 propose_feature 真实落库
-- 功能点应覆盖需求全部业务域（如组织人事/薪酬/招聘三大域都要有对应 feature）
+1. **收集**：用 read_file 读原始需求与交付件（见下方「必读文件」）；用 `list_features` 查功能清单落库情况。
+2. **构建核对项清单**：按 A 组 + B 组列出全部核对项（每项编号，机械可判定 过/不过）。
+3. **逐项判定**：每项只输出 过/不过 + 证据（文件路径/章节位置/缺失说明），不做主观评价。
+4. **算分**：契合度 = 10 × 通过项数 / 总项数（保留两位小数）。
+5. **决策**：契合度 > 9.5 → review_approve（comment 附分数与核对摘要）；否则 review_reject（questions 逐条列出未过项：编号、位置、问题、改法）。
 
-## 二、需求文档落点
+## 必读文件
 
-- 对照 `project-directory-spec`：需求规格说明书 `projects/{项目}/docs/00-requirement/requirement-spec.md`
-- 需求评审记录 `projects/{项目}/docs/00-requirement/requirement-review.md`
+- 原始需求：`projects/{项目}/docs/00-requirement/requirement-spec.md`（需求规格说明书）+ 需求采集任务的原始输入（任务描述/用户上传材料）
+- 需求分析交付件：`projects/{项目}/docs/00-requirement/` 下分析产出（需求细化/功能化描述）
+- 路径权威来源：先 load_skill 加载 `project-directory-spec`，不要凭记忆找路径
 
-## 三、应用划分（design 职责，requirement 不产出）
+## A 组：原始需求逐条契合（主体核对项）
 
-- requirement 阶段**不划分 app、不产出 apps/{应用名}.md 或 {应用名}_spec.json**（app 划分是 design 阶段的架构决策，见 design 角色技能）
-- 若 requirement 越权划分了 app 或产出了 app 说明文件 → 退回
+1. 从原始需求中抽取**原始需求点清单**（编号列明：#1、#2……）。需求点 = 用户明确要的功能/业务/约束，不是文档里的修饰语。抽取结果写进核对记录（供人工复核抽取是否漏项）。
+2. 逐条核对需求分析交付件是否**响应**了每个需求点。判定锚点（满足才算响应）：
+   - 有该需求点的功能化描述（做什么、给谁用）
+   - 有输入/输出或交互边界说明
+   - 有验收口径（怎么算做完/做对）
+   - **只复述需求原文、没有功能化展开 = 不过**（空泛响应）
+3. 每个需求点一个核对项。若某需求点在交付件中被拆成多个功能分别响应，算过；若被遗漏或合并后丢失语义，算不过。
 
-## 四、部署环境需求明确
+## B 组：合规项
 
-- 测试/生产环境的资源规格、依赖服务、端口、环境变量、高可用、备份、域名证书、监控告警是否写清
+4. **功能清单真实落库**：用 `list_features` 查 sd_features——应 ≥1 条记录（状态 proposed 或之后），且功能点覆盖全部业务域（如三大业务域都要有对应 feature）。只在文档里写了、库里 0 条 → 不过。
+5. **文档落点**：需求文档在 `project-directory-spec` 规定的路径（对照技能，不凭记忆）。
+6. **部署环境需求明确**：测试/生产环境的资源规格、依赖服务、端口、环境变量、高可用、备份、监控告警是否写清。空泛写「按标准配置」= 不过。
+7. **无越权划分**：requirement 阶段不划分 app、不产出 apps/{应用名}.md（app 划分是 design 职责）。越权 → 不过。
 
-## 五、真实性核查方法
+## 真实性核查（所有核对项通用）
 
-- 用 list_features / 查 sd_features 表验证功能清单真实落库
-- 用 read_file / list_files 验证文档真实落盘，不只看交付说明的文字声明
+- 用 list_features / read_file / list_files 验证「真实落库/落盘」，不只信交付说明的文字声明。
+
+## 输出要求
+
+- review_approve 的 comment：`契合度 X.XX（通过 n/总 m）` + 核对摘要。
+- review_reject 的 questions：逐条 `[#编号] 位置：…… 问题：…… 改法：……`，精确到原始需求点编号，让需求分析师拿到就能改。

skills_library/pipelines/sdlc_general/roles/agent.qc/role/SKILL.md

@@ -9,18 +9,25 @@ capability: task_capability
 ## 职责
 对每个交付件做合规 + 质量检查，不合规 `review_reject` 退回重做，并逐条列出问题清单（指出具体哪一项、哪个文件、错在哪、该怎么改）。
 
-## 审查方法：一个被查对象一个技能
+## 审查方法：一个被查对象一个技能 + 统一评分协议
 
-审查某角色的产出时，先 load_skill 加载对应的审查清单技能，按清单逐项检查，不要凭记忆：
+审查某角色的产出时，先 load_skill 加载对应的审查清单技能，按其中的核对项清单逐项检查，不要凭记忆：
 
 | 被查角色 | 审查技能 | 查什么 |
 |---|---|---|
-| agent.requirement | `review-requirement` | 功能清单落库、需求文档、应用部署单元 |
-| agent.design | `review-design` | 架构、模块划分、数据库设计 |
-| agent.develop | `review-develop` | 模块目录、表定义、CRUD、代码质量 |
+| agent.requirement | `review-requirement` | 原始需求逐条契合、功能清单落库、应用部署单元 |
+| agent.design | `review-design` | 需求覆盖矩阵（硬门禁）、架构、模块划分、数据库设计 |
+| agent.develop | `review-develop` | 技能映射表驱动：表定义/CRUD/dspy/UI/注册、代码质量 |
 | agent.test | `review-test` | 测试计划/用例落库、真实执行、Bug |
 | agent.deploy_test / deploy_prod | `review-deploy` | 部署配置、文档、真实部署 |
 
+**统一评分协议（所有审查技能共用）**：
+1. 先构建核对项清单（每项机械可判定 过/不过），再逐项判定，最后算分
+2. 契合度 = 10 × 通过项数 / 总项数（保留两位小数）；**> 9.5 放行**
+3. 不放行时退回意见 = 未过项清单（编号、位置、问题、改法），直接构成重做指令
+4. 审查技能的 comment/questions 必须带分数与逐项结果，供人工抽查复核
+5. 硬门禁项（需求覆盖、应用脚手架禁项等）任一不过 = 必退，不受总分影响
+
 ## 通用检查（所有交付件）
 - **路径/命名/格式**：对照 `project-directory-spec`（load_skill 拿权威路径），交付文件必须在正确位置
 - **内容质量**：完整、可量化、可验收、无空泛套话、无重大缺陷