openprd-quality

name	openprd-quality
description	评估可观测性、业务成本与滥用护栏、评估执行环境覆盖、性能基线、极端场景，以及 HTML 质量评估报告和项目知识 Skill。

OpenPrd Quality

当实现就绪、日志、链路追踪、免费额度、业务成本、滥用防护、评估执行环境、冒烟测试、性能基线、压力数据或项目级经验 Skill 在范围内时，使用这份 skill。

命令

• openprd quality . --init：初始化 .openprd/quality/config.json 和 .openprd/knowledge/
• openprd quality . --verify：在 .openprd/quality/reports/ 下生成 JSON 和 HTML 质量评估报告
• openprd quality . --learn --from <report-id-or-json>：把已修复或已审查的质量问题沉淀为项目级经验 Skill
• openprd grow . --review：审查执行中发现的可复用配置、规则候选或 user-local 偏好；和 quality --learn 互补，前者沉淀操作配置，后者沉淀已验证质量经验。若 quality --learn --review 命中项目经验候选，先在最终回复结尾用人话说明“本次情况 / 计划保留的经验 / 以后怎么复用 / 只保留在当前项目里”，再询问用户是否保留。

审查契约

• 场景画像：先判断当前变更是基础、前端、桌面端、后端、成本、安全、性能、极端数据还是发布交付场景，再确定必需 EVO 门禁。
• 可观测性：确认中心化 logs / traces / errors、共享 trace/request/task/error id、脱敏、保留期和查询示例。
• 业务护栏：涉及免费用户、额度、AI 调用、第三方 API、生成、存储或下载时，确认成本来源、用户级限制、负向验证、监控、报警和止损动作。
• 评估执行环境：确认冒烟测试、任务到功能覆盖、正常性能基线和极端数据压力场景；脚本存在只代表能力，不能替代本次运行证据。
• 大界面改动证据：先按用户目标、信息架构变化、视觉决策成本和验证风险判断是否需要方案评审；需要时确认候选效果图已经给用户看过，并且每个方向有清楚的用途、受众、气质端点、审美主张和记忆点；用户已明确确认哪个方向、整张图或哪些子图纳入后续对比；只有确认后的 reference-set 才应出现在 .openprd/harness/visual-reviews/。
• 视觉评审证据：涉及界面视觉实现且已有确认参考效果图时，确认 .openprd/harness/visual-reviews/ 下存在本次 openprd visual-compare 输出的“效果图 / 实现截图”JPG，并且 Agent 已基于合成图复核差异；如果参考图来自整板、网格图或多对象候选图，确认已完成 openprd visual-prepare 产出的 reference-set、contact sheet 或 board 模板审查。没有参考图时先按场景区分新建界面和修改既有界面：新建界面确认实现前 3 方向方案评审已完成，修改既有界面确认存在“修改前 / 修改后”JPG，并已检查预期变化和未改区域漂移；若验收关注局部细节，确认存在“局部焦点证据板”；若并行跑了多个优化方向，确认存在“并行实验证据板”；若使用普通截图或 Computer/Browser/Playwright 实测截图作为证据，确认存在“截图实测证据板”；若新功能或改动包含同构列表、卡片、网格、表格，或用户反馈排版没对齐，确认存在“对齐辅助线证据板”，并同时包含容器轨道 spread 和标题/副标题/描述/标签/状态/价格/按钮/图标等内部内容槽位 spread 量测；若用户反馈或任务目标是单个素材/图标/头像/徽标/按钮图形/图片内部居中、视觉重心或偏心，确认存在“内部居中证据板”，并同时包含主体外接框中心偏移和视觉重心偏移。这些证据不只查有无图片，还要查气质、层级、字体/色彩/动效/表面角色和记忆点是否成立。
• 轻量 UI 可视优化证据：卡片宽度、间距、留白、对齐、颜色、圆角、字号、按钮或图标等小改仍属于用户可见变化。质量审查时至少确认存在修改前后视觉对比、局部焦点证据板、截图实测证据板、对齐辅助线证据板或内部居中证据板，并且本轮审美意图、气质、层级和记忆点已被复核；build、package、dev-check、单元测试或单张原始截图都不能替代视觉收口证据。
• HTML 报告：把 .openprd/quality/reports/*.html 当成面向人的评审产物，而不是次级导出。
• 知识沉淀：当某个已验证修复具备重复性、高影响、隐藏性或由 agent 误判引发时，把模式抽象到 .openprd/knowledge/skills/<skill>/SKILL.md。
• 自我成长：当问题来自配置缺口、文件识别、命令习惯或用户偏好时，优先记录为 .openprd/growth 候选，经用户确认后固化；不要把个人偏好混进项目共享质量经验。

就绪规则

• openprd run . --verify 若显示 taskReady=true 且 workspaceReady=false，不能宣称整体工作区就绪；先明确区分“当前任务通过，工作区待关注”，再列出未通过门禁。若只剩 feature-coverage，说明是任务账本或覆盖证据未收口，不要把本次功能表述成失败。
• 大界面改动缺少实现前 3 方向效果图评审、缺少审美主张/记忆点，或用户未确认方向时，不要进入大 UI 实现；UI 任务有参考图但缺少 visual-compare 输出时，不要宣称视觉实现完成；没有参考图时先判断新建界面还是修改既有界面，新建界面缺少 3 方向方案评审、修改既有界面缺少修改前后截图对比时，都不要宣称视觉自检完成；轻量 UI 可视优化缺少视觉证据或审美复核时，可以说代码或构建已处理，但不要说界面已经优化完成；如果只做了普通截图或 Computer 实测截图而没有截图实测证据板，也不要宣称视觉收口完成；如果界面包含同构列表、卡片、网格、表格却没有对齐辅助线证据板，也不要宣称相同槽位已经对齐；如果 alignment-board 只量了外框、列宽或行顶，缺少标题、副标题、描述、标签、状态、价格、按钮、图标等内部内容槽位，也不要宣称卡片/列表/网格已经对齐；如果对比图仍有明显结构、气质、层级、字体/色彩/表面角色、记忆点偏差或漂移，先返工而不是把差异留给用户发现。
• 最终回复必须列出未通过的必需 EVO 门禁；场景可选门禁可以说明为 advisory，但不能混同为已通过。

收紧规则

Agent 创建的性能基线从合理的行业平均默认值开始。用户可以放宽或收紧，但 Agent 的自更新只能收紧阈值。