to-scenes

转换为场景

将 BEATS.md 和 NARRATION.md 转换为 SCENES.md。场景是世界中的一个小事件，而不是信息的容器。画面服务于旁白：在讲述内容需要时，揭示、演示、比较，或恰到好处地停留。

流程

1. 阅读两份输入、适用的设计真相，以及 references/hyperframes-capability-envelope.md。重新计算节拍和旁白产物的摘要；只有当旁白的 source_digest 与当前节拍匹配，且两个已存储的产物摘要都与各自文件匹配时，才继续。能力范围限定可行性，但不规定实现方式。将旁白视为可修订的依据，而非锁定的时间线。
2. 为每个抽象节拍找到一种具象或空间化的表达：赋予概念形体，将其置于一个世界中，并让可见状态发生变化。让这一变化与旁白的解释、强调和停顿相配合，而不是另行设计一套视觉演出。
3. 将属于同一连续事件的节拍组合在一起；如果某个节拍的解释需要不同的视觉事件，就将其拆分。
4. 从整体上设计影片：建立一个贯穿始终的物件或动作，变化场景和镜头尺度，安排视觉高潮，并明确节奏。
5. 标记那些顺序、长度或重复内容会妨碍视觉事件的旁白句子。只有在保留原始节拍的主张和作用之后，才修订 NARRATION.md。任何修订后，都要重新计算其 artifact_digest，并在将其作为来源之前重新验证节拍及文章溯源关系。
6. 按照 references/scene-format.md 编写 SCENES.md。起草或审核场景前，先阅读该文件，并记录当前的节拍和旁白摘要。对于每个演示，都要定义精确的可见序列，选择其真实性模式，并声明每个代码表面的标注方式；不要把这些决定留到制作阶段。
7. 创建或选定唯一的 HyperFrames 审阅项目，并在 SCENES.md 中记录其路径和修订版本。为每个场景构建最小且有用的 16:9 验证图：状态足够时使用 Hero；需要判断变化或连续性时使用 Start/Hero/End；只有针对明确命名的风险，才添加更多状态。凡是会影响结果的地方，都要使用真实字体、接近最终版的文案，以及真实代码或有证据支持的终端组件。将这些验证图嵌入 SCENES.md 中对应场景的章节，或从该章节链接到它们，并附上其状态 ID 和项目修订版本。
8. 根据能力范围评定每个场景的可行性，并在需要时注明依赖项和后备方案。
9. 按照格式参考中的格式运行场景审计。如果场景创建后旁白发生变化，就修订所有受影响的场景，更新 source_narration_digest，重新计算场景的 artifact_digest，将受影响的渲染验证图标记为过期，并在完成前再次运行审计。

在继续之前，使用 SCENES.md 中引用的渲染证据，解决视觉语法和已声明的场景风险。在项目状态和 SCENES.md 中记录项目标识、修订版本、来源摘要、验证图路径、宽高比、已审查的风险和决策。

提交 SCENES.md、修改后的 NARRATION.md 或任何后续修订前，遵循 ../boring-video/references/markdown-review.md。权威的 SCENES.md 会将每个语义场景约定与共享 HyperFrames 项目中可检查的渲染证据配对。不得将未渲染的文字描述当作视觉证据。

当每个节拍都有可行的视觉事件、影片具有刻意设计的变化和连续性、每项已声明的视觉风险都能通过 Markdown 引用的证据进行检查、共享项目和验证图修订版本均已记录，并且 SCENES.md 及本阶段修改的任何 NARRATION.md 均满足 Markdown 审查完成标准时，SCENES.md 即告完成。