القائمة
质量闸门——跑真实 check、对照质量目标、出可核对报告，由人签字放行
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
全自动 PDLC 新功能开发（串联 PRD→设计→TDD→实现→评审→发布）
全自动 Bug 修复（定位→复现→修复→测试→文档）
按设计文档和已有测试用例实现代码（带前置守卫、自检、handoff）
创建 PRD 文档（自动化生成 + 自检 + handoff）
代码评审 + 文档评审
发布工作流（跑测试 → bump VERSION → 更 CHANGELOG → tag → 触发 CI/CD）
| name | pdlc-quality |
| description | 质量闸门——跑真实 check、对照质量目标、出可核对报告，由人签字放行 |
跑真实 check → 对照质量目标 → 出可核对的报告 → 人签字放行。
一切判定来自客观数据：覆盖率数字来自覆盖率工具、E2E 覆盖来自 flow→test 映射 + 真跑结果、lint 来自退出码。 AI 只负责把这些数据整理成报告，不参与"达标与否"的判定，放行由人。
⛔ 绝不允许出现的行为：用"我看了一下代码，测试挺全的"这类判断替代真实数据； 用上一次的结果冒充本次；命令没跑通却按通过处理；覆盖率没测量却写一个数字。 量不到就如实写"未测量"——这与状态机里「无命令可跑 →
checks: {}」是同一条纪律。
| 文件 | 作用 | 缺失时 |
|---|---|---|
docs/00_standards/test-commands.yml | 怎么量（命令） | 中止，提示先跑 /pdlc-test-setup |
docs/00_standards/quality-targets.yml | 量到多少算达标 | 走 --init 交互创建（见下） |
docs/00_standards/e2e-flow-map.yml | 核心流 → E2E 测试 的映射 | 若 targets 里声明了 core_flows 则必须有，否则 E2E 判定无法机械化 |
--init：首次建立目标声明templates/quality-targets-template.yml 作骨架。core_flows 草稿：扫 docs/01_requirements/prd/，提取标记为 P0 / P1 的功能流程，
生成候选清单（含来源 PRD 路径）供人确认——降低首次声明的摩擦，但最终清单必须人确认，不自动落盘。test-commands.yml 的 coverage 命令参数对齐；两者不一致要提示人对齐
（以命令参数为准——那才是真正的强制点）。e2e-flow-map.yml 骨架（每条 flow 一个空 tests 列表待填）。按 test-commands.yml 逐条真跑 coverage / e2e / lint，记录命令原文 + 退出码 + 关键输出。
退出码的三态语义、以及「命令跑不了 = yml 过期信号」按下面的规则处理：
补充两条本命令特有的：
拿实测数字对 quality-targets.yml 的达标线。真正的强制点是命令参数里的阈值（如 --cov-fail-under=85）——
退出码就是判定；yml 里的数字用于报告展示与趋势。两处不一致 → 报告里提示对齐。
对每条 core_flow，按 e2e-flow-map.yml 找到映射的测试标识，再到本次真跑的 E2E 结果里核对：
| 情况 | 判定 |
|---|---|
| 映射存在 且 对应测试本次通过 | ✅ |
| 映射存在 但 测试本次失败 | ❌ |
| 映射存在 但 该测试在本次结果里找不到 | ❌ 映射腐烂（指向了不存在的测试） |
core_flow 在映射文件里没有条目 | ❌ 缺映射 |
映射里有 core_flows 中不存在的 id | ⚠️ 黄：孤儿映射，建议清理 |
缺一条 = 红。 绝不用"我觉得这条流程被别的测试覆盖了"来补空缺——那正是要消灭的主观判断。
段一已经把每条命令真跑了一遍，过期信号是白捡的。汇总成报告的一节：
| 状态 | 判据 | 报告里怎么写 |
|---|---|---|
| ✅ 健康 | 命令跑起来了（退出码 0 或非 0 皆可） | 正常 |
| ⚠️ 已失效 | 127 / command not found / 脚本不存在 | 「<项> 的命令已跑不通——yml 过期」+ 报错原文 |
| 💡 可收紧 | 该项当前留空，但本次探测到已可用的命令 | 「<项> 现在可以填了：<候选命令>（已验证退出码 <N>）」 |
| — 留空 | 该项留空且确无可用命令 | 「留空，未测量」（不得判为通过） |
本节只报告、不改 yml——改配置等于改"通过"的定义，要走 /pdlc-test-setup --refresh（严向自动、松向人确认）。
清单靠"有人记得改"维护必然腐烂；腐烂的清单产出 false-green——新增的核心流没进清单，矩阵照样全绿， 把"我们不知道"伪装成"我们覆盖了"，比没有闸门更坏。所以每次运行都强制对账：
docs/01_requirements/prd/ 所有 PRD，提取 P0 / P1 流程。quality-targets.yml 的 core_flows 做 diff。core_flows 无 → ❌「PRD 流程 X 未进 core_flows」core_flows 有、映射无 → ❌「core_flow Y 尚无映射的 E2E」core_flows 无 → ⚠️ 孤儿映射⛔ "不可判"绝不能被当成"没问题"（对账自身的 false-green，真项目上实测踩到过）： 若某份 PRD 不含任何 P0/P1 标记，它提取出的就是空集，于是不产生任何漂移条目—— 报告若就此显示"对账通过"，等于宣称"这份 PRD 里的流程都覆盖了"，而事实是它整份都没进闸门视野。 已上线的主链路最容易栽在这里（老 PRD 常只写"已上线/待开发"，不标优先级）。
规则：统计"因无优先级标记而未参与对账"的 PRD，在报告里单列告警，并且 对账项不得判为 ✅——写成
⚠️ 无漂移，但另有 N 份 PRD 不可判。 处理建议：给这些 PRD 补优先级标记，或在quality-targets.yml里显式声明豁免（写明理由）。
这样清单维护就从"靠自觉"变成被产物纪律接管——PRD 本就被 pdlc 逼着落盘并保持最新， 让它当
core_flows的唯一上游真源，与「状态外化到磁盘」是同一个哲学。
按 templates/quality-report-template.md 生成 docs/07_reviews/quality/<YYYY-MM-DD>.md（ledger 型：一次一份，
可 git diff、可看趋势；同日重跑则覆盖当日文件）。必须包含：
core_flow 都有明确判定（含"映射腐烂"这种红）docs/07_reviews/quality/，含生成时间与 commit SHA可自动修复的（如 lint 可自动修的告警）→ 修完重跑该 check 并以重跑结果为准，报告里注明"已自动修复后重测"。 不可自动修复 → 如实留红，写进报告。
/pdlc-quality 出全量报告/pdlc-ship 会读最近一份质量报告，未达标不让发（除非人显式 override 并写明理由）schedule本命令的 handoff 输出：
📊 质量报告：docs/07_reviews/quality/<YYYY-MM-DD>.md
覆盖率 : <实测> / 目标 <目标> ✅|❌
E2E 核心流 : <M>/<N> 条已覆盖 ✅|❌
Lint : 退出码 <N> ✅|❌
PRD 对账 : <无漂移 | N 项漂移 | 另有 N 份不可判> ✅|⚠️|❌
配置健康度 : <全部健康 | N 项已失效 | N 项可收紧>
🧾 总判定：<达标 | 未达标>
✍️ 待人工签字：报告最后一节（go/no-go 由你拍，本命令不代劳）
👉 未达标项处理：<每条给出具体下一步>
core_flows 维护得多勤——这正是 §2.4 强制对账存在的原因，但对账只能发现
"PRD 里有而清单里没有"，PRD 本身漏掉的核心流谁也发现不了。这条限制要让用户知道。参数: $ARGUMENTS