Ppt Review

执行规则

审查维度

以下维度必须逐项检查，不得跳过：

1. 任务满足度：task-pack.json 中的目标、页数、场景是否被满足。
2. 风格执行度：style-spec.json 是否被忠实执行。
3. 叙事一致性：storyboard.json 与最终页面是否一致。
4. 承载预算兑现：storyboard.json.pages[n].payload_budget 是否被兑现——逐页对照 claim_count、evidence_count、structure_block_count、require_comparison_or_summary。
5. 页级资产满足：是否满足页级 asset_requirements。
6. 风格漂移：页面之间是否存在风格漂移。
7. 溢出与过空：单页是否溢出、过空或信息失衡。
8. 承载不足：payload_budget 明确要求多块承载，但页面只剩松散标题区或单一大卡片。
9. 结构块不足：结构块数量低于预算要求。
10. 对比/摘要缺失：预算要求了对比或摘要但页面没有兑现。
    • 缺少对比或摘要应直接记为问题。
11. unresolved 处理：资产计划中的 unresolved 是否需要继续处理。
12. 背景装饰层：是否缺少 data-layer="bg-motif" 标记；是否只有纯色或渐变背景。
13. 前景装饰层：是否缺少 data-layer="fg-motif" 标记。
    • 缺少背景装饰层应直接记为问题。
    • 缺少前景装饰层应直接记为问题。
14. 装饰层强度：装饰层是否只是很小的角标或极弱纹理，不足以构成真正的背景/前景层。
15. real-photo 兑现：如果要求真实图片却只落了 SVG 或 placeholder；如果某页仍存在必需 real-photo 槽位未兑现。
16. 图片质量：已落地真实图片的清晰度、相关性、水印、槽位语义一致性。
17. 信息来源一致性：页面里是否出现 storyboard 之外的新文本、新数值或新图表数据。

核对方式

• 消费前必须先确认 task-pack.json、style-spec.json、storyboard.json 以及已产出的页面文件真实存在且可读。
• 如果目标文件不存在、目录不一致或交付物缺页，先标记缺失依赖，不要猜测。
• 必须直接读取页面 HTML，必要时结合 DOM/CSS 结构核对装饰层，不要只根据模型自述判定通过。
• 必须交叉核对 storyboard.json.pages[n].asset_requirements、asset-plan.json.slots 与最终 HTML，不要只看其中一层。
• 必须核对 storyboard.json.pages[n].title_atom_ids、display_items 与最终 HTML，不要接受页面阶段现场补编。
• 对图表页，必须逐项核对图表标题、系列名、数值、图例是否都能回指到 display_items 与 atom_ids。
• 如果图表中的可见文本或数值没有 data-display-id 或 data-atom-ids，不得判定通过。
• 必须检查页面里是否存在 data-layer="bg-motif" 与 data-layer="fg-motif" 装饰层证据。
• 如果 style-spec recipe 要求某个 motif，就要在页面里找到对应的 data-motif-key。
• 如果页面里出现 storyboard 之外的新文本、新数值或新图表数据，必须判定为阻塞。
• 必须检查标题元素是否放在 #ct 或 #header。
• 不要把仅存在于源码但被层级盖住的标题判成通过；如果 .header 落在 #ct 外面，应视为标题不可见。

图片质量复核

• 必须复核已落地真实图片的质量，不要因为"已经下载成功"就默认通过。
• 对已选图片至少复核这些硬性项：清晰度、相关性、明显水印、槽位语义一致性。
• 任一硬性项失败，必须判定为阻塞，不得交付。
• 构图 与 风格一致性 属于弱筛查；没有明显大问题时可以通过，但要在 review 中留下告警或备注。

路由逻辑

• 能局部修复的问题，不要整套推倒重来。
• 如果只是某页问题，应转到 ppt-page-plan、ppt-page-polish 或 ppt-page-assets。
• 如果某页仍存在必需 real-photo 槽位未兑现或真实图片质量不合格，应转到 ppt-page-assets。
• 如果是全局设计问题，应转到 ppt-style-refine。
• 如果是叙事节奏问题，应转到 ppt-story-refine。
• 资产类问题应转到 ppt-page-assets 或回到 ppt-asset-plan 继续补齐。

用户回显

• 开始反馈：说明正在审查整套 deck，并指出会检查结构、风格、页面质量和资产状态。
• 完成反馈：给出总体结论、问题数量、推荐下钻 skill 和 下一步。
• 如果 review 发现阻塞性交付问题，要在反馈里明确指出不能直接交付的原因，不要只给笼统评价。

关键原则

• 审查结果必须写回文件，不能只在聊天消息里口头总结。
• 必须逐页对照 payload_budget，不得只看整体印象。
• DOM/CSS 结构核对是必须步骤，不能只凭模型记忆判定通过。
• 交叉核对三层资产（storyboard 要求、asset-plan 槽位、最终 HTML）是必须步骤。
• 页面信息回指核对也是必须步骤；不要接受页面阶段现场补编。
• 如果没有 review.json，后续不要直接进入导出。

禁止事项

• 如果页面只有纯色或渐变背景，且缺少背景装饰层或前景装饰层，不能直接交付。
• 如果页面要求真实图片却只落了 SVG 或 placeholder，不能直接交付。
• 如果某页仍存在必需 real-photo 槽位未兑现，即使页面其他部分完成，也必须判定为阻塞。
• 如果已落地真实图片存在清晰度不足、相关性不足、明显水印或槽位语义不一致，必须判定为阻塞。
• 如果页面里出现 storyboard 之外的新文本、新数值或新图表数据，必须判定为阻塞。
• 如果图表标题、系列名、数值、图例没有显式回指，或只存在于 HTML 而不存在于 storyboard.json.display_items，必须判定为阻塞。
• 如果图表中的可见文本或数值没有 data-display-id 或 data-atom-ids，不得判定通过。
• 不要接受页面阶段现场补编。
• 不要写成 Pass with minor notes，也不要建议立即导出。
• 如果 payload_budget 明确要求多块承载，但页面只剩一个松散标题区或单一大卡片，不能直接交付。