light-html-plan

Light HTML Plan

light-html-plan 会将计划记录转换为一个可离线阅读和核对的页面。记录仍是权威依据；页面是带日期的快照。在 Light 项目中，页面位于 .scratch/<feature>/plan.html，更早的版本放在 .scratch/<feature>/plan-history/。在其他地方，请与调用者商定路径。

页面按以下顺序分为五个部分

1. 这个项目是什么：计划会改变什么，并配有框架图。每个区块显示组件名称（在技能集合中显示 Skill 的名称）以及其中的改动，并通过颜色和文字标记为重点改动、小改、新能力或不改。
2. 做到哪一步：每个工作项显示在做什么、已完成、没完成和证据。写完、验收和发布是三个独立状态。
3. 等你决定的事：因等待用户决定而停下的工单、proposed 变更提案、待解答的问题、报告中尚无提案回答的 Plan gap:，以及由计划本身导致的 FAIL；每项都说明其阻碍的事项。
4. 跟当初相比哪里变了：每个变更提案及其改动内容、状态和批准者。
5. 系统替你做了哪些判断：每条已记录的判断都先用通俗的话说明问题，再列出答案、把握程度和判断者。已记录的 reason 不为 none 的条目排在前面。ID 仅作为来源显示。

没有内容的部分写“目前没有”。部分名称使用读者的语言。在第 1 部分上方，用一行状态说明记录日期、工作进度和下一步。

每个部分中的标题和主要句子都是一项主张：读者可以指着它说“这是错的”。用图表、进度条、表格或图示展示关系、进度和数字；正文说明每项展示内容证明了什么。

步骤

1. 判断是创建还是刷新。阅读材料、输出路径，以及刷新时的现有 HTML。对无法读取的输入先作处理，再声称结果完整。
2. 阅读 source-protocol.md，将每项承诺和记录对应到来源及所属部分。若有进度记录或需要刷新，请阅读 progress-and-refresh.md。
3. 阅读 writing.md。先用纯文本撰写状态行和每个部分的主张。大声读出来并反复修改，直到它们完整说明当前状态。
4. 按照 design-and-verification.md，使用 skeleton.html 构建页面，并内联 plan.css。只有在文本定稿后才能开始设计。刷新时保留页面现有设计。
5. 通读渲染后的整个页面，包括已折叠的部分。修改文本措辞，而不是 CSS。对照承诺映射进行核验。检查 1440px 和 390px 宽度、浅色和深色主题、溢出情况，以及文件不会发出外部请求。

返回并停止

返回 HTML 路径、带 SHA-256 的来源定位信息、改动内容，以及已做和未做的检查。若当前正在执行任务，请附上进度参考中的刷新交接信息。

页面按路径、日期和 SHA-256 列出来源；不会嵌入来源的完整文本。用户会通过阅读页面来判断内容是否清晰、外观是否良好；请报告你执行了哪些检查，并将最终判断留给用户。

此能力不会批准计划、拆分工单、更改任务或提案状态、发布或安装任何内容。关于来源的问题应交由其负责人处理；此能力不会调用其他由用户调用的 Skill。 ATTRIBUTION.md 记录了上游参考资料和 Light 的改动。

与调用方的约定

• 可选。 缺少或拒绝此功能时，调用方保留原有行为，页面保留最近一次版本。不会有人因此报告 BLOCKED 或要求安装。
• 调用方先记录。 调用方先写入事件（实现报告、判定、提案），再请求刷新。页面读取记录；绝不会补填记录。
• 返回，不接管。 投递后即返回。
• 不授予任何权限。 页面只显示状态；绝不批准、接受或发布任何内容。