consensus-summary-html

共识摘要 HTML

请先选择分支，再选择模型。以指定角色组装、验证并检查视觉产物。此技能不会调度工作者。

创建一个 HTML 页面，帮助读者在一分钟内了解委员会结论，并在不打开原始记录的情况下查看证据。

结果主线

• 结果： 一个包含内联 CSS 和 JavaScript 的独立 .html 文件。
• 下一位使用者： 必须采纳建议、质疑建议，或将其交给下一工作流步骤的人。
• 完成标准： 输出文件已生成，内置验证器以 0 退出，每项可见主张都有来源或明确的证据缺口，且页面不含模板标记。
• 意图： 构建一个决策界面。决策界面先呈现结果，再让读者逐步查看主张、证据、分歧、置信度和行动。

描述工作时，请使用 leitwort：“决策界面先呈现结果，并让尚未解决的证据保持可见。”将先呈现结果作为第一条布局规则，而不是事后补充的摘要说明。

输入约定

使用已完成的 models-consensus 结果。不要再次召集委员会，也不要修改委员会决策。

1. 将持久化的 report_path Markdown 文件作为主要叙述来源。
2. 如果存在持久化的 state_path JSON 文件，请使用它。该文件提供状态、模式、轮次、席位忠实度、实际使用的提供商和模型、独立性核算及置信度值。
3. 如果结果以内联形式提供，请使用其中的报告和状态部分。如果缺少字段，请显示 Not reported 并指出证据缺口。
4. 仅在填补缺失的必需类别时，才读取原始轮次输出文件。默认不要加载完整记录。
5. 如果产物模式、报告结构或状态键不明确，请在规范化前阅读此技能目录中的 references/input-contract.md。

证据优先于装饰。缺失的席位、格式错误的输出、超时、共享提供商或尚未解决的分歧必须保持可见。遵循席位忠实度：只有当结果记录了某个席位实际使用的提供商或模型时，才注明该席位。切勿根据请求的名称或自我声明推断模型。

工作流

1. 定位并冻结结果

在结果对象或用户提供的上下文中找到报告和状态路径。记录会话 ID、问题、状态、模式、产物模式和报告日期。如果状态不是 complete，请将页面标记为部分完成、失败、等待人工输入、已取消或达到上限。不要将部分结果呈现为最终决策。

2. 规范证据

在编写 HTML 之前，先构建一份精简的内部映射。将源路径与每项内容放在一起，以免丢失来源信息。

• **问题与状态：**任务、当前状态、模式、轮次以及任何模式切换。
• **结论：**先用通俗语言说明。对于采纳类问题，必须包含 Adopt、Trial、Hold、Reject 或 Not our problem 中的一个等级，且只能包含一个；将等级与通俗表述放在一起。对于其他类型的问题，直接给出建议，不要臆造等级。
• **共识：**议事会支持的三到六个要点，最有力的证据优先。
• 分歧：列出每项实质性分歧、各方最有力的论据，以及分歧的解决情况或未决状态。遵循标记，绝不覆盖：不要因为多数方人数更多，就隐去少数方的立场。
• **盲点与证据缺口：**议事会无法核实的事实、缺失的背景信息、格式错误的席位，以及本次运行的局限。
• **置信度：**分别给出答案置信度和多样性置信度，并说明各自等级的原因。不要将两者混为一谈。
• **席位与轮次：**已选中、已省略、不可用和重复的席位；有记录时，注明实际使用的提供商和模型；轮次结果及收敛情况。
• **下一步：**仅一项具体行动。如果议事会提出了多项行动，选出影响最大的行动，并将其他行动列入后续备注。

采用筛选，而非压缩。删除重复表述，而非证据、注意事项或异议。

3. 组装决策页面

将此技能目录中的 assets/template.html 复制到商定的输出路径。替换所有标记槽位，并移除所有占位符。

如果已持久化 report_path，默认使用 <report directory>/<session_id>-summary.html。没有报告路径时，使用 docs/consensus/<slug>-summary.html。明确要求更新该产物，即授权进行范围受限的编辑。如果现有目标文件未获准替换，请使用新路径，或询问要更新哪个产物；保留无关内容。

按以下顺序排列各部分，并保持 id 不变：

1. overview：问题、状态、模式、会话，以及一段式摘要。
2. verdict：用通俗语言给出建议；只有当问题涉及是否采用时，才提供采用评级。
3. agreements：理事会成员共同认可的要点。
4. divergences：已解决和未解决的分歧，以及可用的解决理由。
5. evidence：轮次时间线、席位表、实际模型记录，以及来源路径。
6. confidence：分别列出答案置信度和多样性置信度。来源未包含相应值时，显示 Not reported。
7. next-step：一个行动；若来源提供了负责人或目标，则一并注明。
8. limits：缺失的证据、未纳入的席位、未解决的问题，以及本次运行的局限。

页面必须支持三个阅读层次：

• 一览： 主视觉区展示问题、状态、结论和下一步。
• 浏览： 卡片和轮次时间线展示共识、分歧、席位和置信度。
• 深入： 可展开的详情展示来源路径、解决说明和精简的轮次证据。

视觉规则。请先阅读 shared/references/html-page-conventions.md：自包含、三个阅读层次、文本与颜色共同表达状态，以及转义规则均由该文件规定。以下规则专用于决策页面。

• 首屏内容应聚焦。采用深色、高对比度布局，并使用一种强调色表示积极共识、一种表示谨慎、一种表示尚未解决的分歧。
• 仅当来源中存在相应数值时，才使用条形图或环形图。视觉呈现不得暗示理事会未报告的精确度。
• 卡片内容应简短。较长的文本放入 <details> 面板。不要粘贴原始记录。
• 所有来源标签都应清晰可读，例如 report.md、state.json 或 round-2-digest.md。仅当相对链接从输出目录中可正常访问时，才使用相对链接。

语言遵循用户的请求。英语使用 ASD-STE100 简明技术英语。葡萄牙语使用简明的巴西葡萄牙语。名称、路径、枚举值和作为证据引用的理事会原文均保持不变。

4. 验证产物

组装完成后运行验证器。在同一次 shell 调用中，将 SKILL_DIR 设为包含此 SKILL.md 的绝对目录：

SKILL_DIR="<absolute path of this skill directory>"; python3 "$SKILL_DIR/scripts/validate_consensus_summary.py" <output-file.html>

修复报告中的所有错误。验证器会检查必需的部分 id、单独列出的置信度字段、席位表、唯一的下一步、本地自包含性，以及是否残留模板标记。

如果有浏览器，请按照共享规范中的验证步骤进行检查（桌面和窄屏宽度、展开控件，以及每个导航链接都能跳转到实际部分），并额外确认首屏仍可看到尚未解决的分歧。如果没有浏览器，请报告机械检查已通过，但无法进行视觉检查。

5. 交付

先返回绝对输出路径。然后报告理事会状态、结论、下一步、验证命令及结果，以及任何无法进行视觉检查的部分。若理事会状态不是 complete，不得声称页面已定稿。

输出契约

输出为一个独立的 HTML 文件。文件必须包含：

• 默认文件名格式为 <session_id>-summary.html，与已持久化的报告放在同一目录；对于内联结果，则为 docs/consensus/ 下的 <slug>-summary.html；

• 一个 title、lang、字符集和 viewport；

• 一个可见的问题标题和一个可见的状态标签；

• 上述列出的全部八个 section id；

• 恰好一个 data-role="next-step" 元素；

• data-role="answer-confidence" 和 data-role="diversity-confidence"，每个属性的值均为具体值或 Not reported；

• 一个至少包含一行的席位表，即使唯一一行说明未报告席位数据也可以；

• 至少一个来源标签；如果来源详情缺失，还必须明确指出证据缺口；

• 不得包含 <!-- SLOT 注释、{{...}} 标记、TODO、Replace with 文本，也不得依赖外部脚本或样式表。

这是验收契约：验证器以 0 退出；页面可作为本地文件直接打开，无需服务器；首屏包含结论；读者可通过页面导航访问共识、分歧、证据、置信度、下一步和局限部分。

注意事项

• 达成共识并不能证明彼此独立。保留有关共用提供方和自配对的说明。
• 只有一个席位的 council 不属于多模型共识。应显示降低后的多样性置信度。
• 高答案置信度无法弥补低多样性置信度。
• 不要因为存在建议，就将尚未解决的分歧改写为已解决的卡片。
• 不要编造百分比、席位名称、来源链接或解决原因。
• 不要将原始模型请求名称用作有效的模型凭据。
• 不要利用 HTML 页面掩盖席位格式错误或不可用的情况。可观察到的故障也是结果的一部分。