Hyperframes Studio 组合Composition编辑可靠性验收解析 composition-reliability 最小测试工程【免费下载链接】hyperframesWrite HTML. Render video. Built for agents.项目地址: https://gitcode.com/GitHub_Trending/hy/hyperframes本篇文章以 Hyperframes Studio 仓库内packages/studio/tests/e2e/fixtures/composition-reliability/目录中的验收夹具说明为主线剖析这份无媒体、纯 HTML的 Studio 工程如何一次性覆盖组合复用、嵌套组合、透明遮罩标题、剪辑碰撞与新轨道放置、跨轨叠层等编辑链路。读完你可以理解 composition-reliability 夹具的验收清单、每个文件的设计意图以及仓库中对应集成测试是如何以不改动检入源的方式守住这些行为的。一、夹具定位一段视频工程验证一整条编辑栈在 Hyperframes 的世界里Studio 的工程本质是 HTML画布上的每一个剪辑、每一条时间线都是带data-*属性的 DOM 节点编辑操作最终写回 HTML 源码。而组合编辑是否可靠正是整条产品栈的地基——组合composition可以被实例化为剪辑、可以被嵌套、可以被移动/剪切/撤销且每一步都必须产生可预期、可复现的源码结果。composition-reliability 夹具正是为此设计的验收基准工程。README 给出了它的设计约束与验收范围Compact, media-free Studio project for validating composition editing as one stack紧凑、无媒体文件的 Studio 工程用于把组合编辑作为一整条技术栈来验证核心设计目标有五条两个**根级宿主root host**在不同时间点复用同一个title-card.htmlnested-shell.html在更深一层托管同一个标题卡构造嵌套组合场景标题卡使用透明 overflow 遮罩包裹可编辑的标题文字同一轨道上的相邻剪辑提供干净的碰撞collision/落至新轨道拖放目标一次跨轨道重叠用于验证常规的视觉分层行为。同时它明确了一种工程纪律进行浏览器验收前须将整个目录复制到 scratch临时工作区验收动作打开工程、组合插入、单选/多选移动、碰撞放置、重叠分层、剪切、标题颜色/字号、单步撤销都在副本上进行仓库内检入的夹具源文件必须保持不变。二、夹具目录解剖一个可发布的迷你 Studio 工程该夹具不是一个零散 HTML 文件而是一个结构完整的工程根目录对应一个可被 Studio 打开的组合packages/studio/tests/e2e/fixtures/composition-reliability/ ├── README.md ├── package.json ├── hyperframes.json ├── index.html # 顶层根组合1280×720 30fps时长 12s └── compositions/ ├── title-card.html # 可复用的标题卡组合480×220 └── nested-shell.html # 嵌套一层托管 title-card 的组合工程声明文件有两个package.json仅含name: composition-reliability-fixture与private: true避免被误发布hyperframes.json 声明了工程格式与资源映射该文件头部还包含$schema与registry键指向项目官方 schema 与上游 registry其paths字段将组合 HTML 目录映射为资源类别格式与仓库 schema/hyperframes.json 描述的工程结构对应{ paths: { blocks: compositions, components: compositions/components, assets: assets } }也就是说compositions/下的每个 HTML 被当作组合块block源来解析——这正是打开工程验收步骤的前提。三、顶层 index.html把验收场景排版成一条可编辑时间线index.html 是整个夹具的舞台。根节点是一个组合容器用data-*属性声明画布元信息main idcomposition-reliability >template idtitle-card-template section idtitle-card-root>template idnested-shell-template section idnested-shell-root>const fixtureDir join( dirname(fileURLToPath(import.meta.url)), ../../../tests/e2e/fixtures/composition-reliability, );随后用两个用例把 README 的核心主张一一转成断言用例一夹具结构自身的静态契约index.html中引用compositions/title-card.html的宿主恰好有两个且data-start依次为[0,4]复用 时间错开nested-shell.html内部的嵌套宿主存在且其data-composition-srctitle-card.html指向的依赖文件确实存在于compositions/目录existsSync校验堵住引用悬空标题模板里.hl-mask文本包含 Reliable compositions其style匹配/\.hl-mask\s*\{[^}]*overflow:\s*hidden;[^}]*background:\s*transparent;/且文字节点是H1透明遮罩拓扑得到机器可读的保证collision-a与collision-b同轨道且 A 的startduration恰好等于 B 的start相邻不重叠layer-overlap与collision-b起点相同但轨道不同跨轨时间重叠成立。用例二编辑会落到正确的源码层这是整个夹具最有价值的守门点。测试通过hyperframes/studio-server/source-mutation导出的patchElementInHtml以及同目录domEditing模块导出的buildDomEditStylePatchOperation模拟两类真实编辑移动时间线上的宿主对index.html中的title-host-a打补丁把start改为 5、duration改为 2。断言结果是修改只出现在根工程源码里data-hf-idtitle-host-a、data-start5、data-duration2均被命中根源码不出现data-hf-idtitle-text标题模板源文件也不含新颜色——时间线宿主编辑不会泄漏进被复用的组合模板。给标题文字换色对模板里的title-text打一个 style 补丁color: #12b886。断言结果是补丁命中颜色只写到title-text元素自身的style上title-mask的style属性保持为空且重着色后的 HTML 不含根工程宿主标记、根源码也不含该颜色——内容级编辑只落在组合模板层绝不外溢。把两个用例合起来看它验证的正是 README 所说的 composition editing as one stack时间线型编辑与内容型编辑虽然走同一条 DOM 补丁管线patchElementInHtml按data-hf-id精确寻址却因为data-hf-id归属的文件不同而天然分层编辑结果永远落在声明它的那份源码里。这与仓库中packages/studio/src/utils/blockInstaller.ts、timelineElement.ts、timelineElementHelpers.ts 等模块持续读写data-composition-src/宿主属性的事实相互印证data-*属性就是 Studio 把 HTML 转成可编辑时间线的那份共享契约。七、验收操作矩阵复制到 scratch 后逐项演练README 给出的浏览器验收操作清单与夹具元素的对应关系如下可直接作为手工验收脚本验收操作在夹具中如何发生打开open打开工程根index.html校验 1280×720 画布与 4 条轨道、6 个剪辑正确物化组合插入composition insert从组合源插入/复用title-card观察新宿主出现在预期时间与轨道单/多移动single/multi move单选拖动title-host-a或框选两个标题宿主一起移动校验源码data-start同步碰撞放置collision placement把一个剪辑拖向collision-a/collision-b邻接处验证碰撞吸附或落至新轨道重叠分层overlap layering观察collision-b轨道 2与layer-overlap轨道 3同时刻重叠时的视觉层序剪切cut对标题宿主执行剪切校验剩余片段与模板不受影响标题颜色/字号修改title-text的颜色与font-size验证只落在模板文件对应元素上单步撤销one-step undo执行一次撤销校验所有文件回到操作前状态每条操作都应遵循同一条前提先复制目录到 scratch 再动手——因为浏览器验收会实际改写工程文件检入的夹具源必须保持原样才能让集成测试与后续验收永远在同一份标准答案上运行。八、小结一份夹具如何撑起一整套可靠性主张回看整个 fixture它的巧妙之处在于用极少的素材完成了极强的覆盖一个可复用的标题卡、一个嵌套壳、两条纯色碰撞条与一块半透明叠层就构造出复用 / 嵌套 / 透明遮罩 / 碰撞落轨 / 跨轨分层五个正交的编辑风险面而 compositionReliabilityFixture.integration.test.ts 则把其中可自动化断言的部分结构契约、编辑归属分层变成了 CI 里每次都跑的守门测试。对于想要为 Studio 贡献组合相关功能或新增验收夹具的开发者这份 fixture 就是现成的模板一个能被搜索、被引用、被复制到 scratch 反复演练的最小工程胜过一段随时可能过期的口头验收清单。【免费下载链接】hyperframesWrite HTML. Render video. Built for agents.项目地址: https://gitcode.com/GitHub_Trending/hy/hyperframes创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/9/10 6:25:04 · 阅读 1.2k Hyperframes Studio 组合（Composition）编辑可靠性验收：解析 composition-reliability 最小测试工程
Hyperframes Studio 组合Composition编辑可靠性验收解析 composition-reliability 最小测试工程【免费下载链接】hyperframesWrite HTML. Render video. Built for agents.项目地址: https://gitcode.com/GitHub_Trending/hy/hyperframes本篇文章以 Hyperframes Studio 仓库内packages/studio/tests/e2e/fixtures/composition-reliability/目录中的验收夹具说明为主线剖析这份无媒体、纯 HTML的 Studio 工程如何一次性覆盖组合复用、嵌套组合、透明遮罩标题、剪辑碰撞与新轨道放置、跨轨叠层等编辑链路。读完你可以理解 composition-reliability 夹具的验收清单、每个文件的设计意图以及仓库中对应集成测试是如何以不改动检入源的方式守住这些行为的。一、夹具定位一段视频工程验证一整条编辑栈在 Hyperframes 的世界里Studio 的工程本质是 HTML画布上的每一个剪辑、每一条时间线都是带data-*属性的 DOM 节点编辑操作最终写回 HTML 源码。而组合编辑是否可靠正是整条产品栈的地基——组合composition可以被实例化为剪辑、可以被嵌套、可以被移动/剪切/撤销且每一步都必须产生可预期、可复现的源码结果。composition-reliability 夹具正是为此设计的验收基准工程。README 给出了它的设计约束与验收范围Compact, media-free Studio project for validating composition editing as one stack紧凑、无媒体文件的 Studio 工程用于把组合编辑作为一整条技术栈来验证核心设计目标有五条两个**根级宿主root host**在不同时间点复用同一个title-card.htmlnested-shell.html在更深一层托管同一个标题卡构造嵌套组合场景标题卡使用透明 overflow 遮罩包裹可编辑的标题文字同一轨道上的相邻剪辑提供干净的碰撞collision/落至新轨道拖放目标一次跨轨道重叠用于验证常规的视觉分层行为。同时它明确了一种工程纪律进行浏览器验收前须将整个目录复制到 scratch临时工作区验收动作打开工程、组合插入、单选/多选移动、碰撞放置、重叠分层、剪切、标题颜色/字号、单步撤销都在副本上进行仓库内检入的夹具源文件必须保持不变。二、夹具目录解剖一个可发布的迷你 Studio 工程该夹具不是一个零散 HTML 文件而是一个结构完整的工程根目录对应一个可被 Studio 打开的组合packages/studio/tests/e2e/fixtures/composition-reliability/ ├── README.md ├── package.json ├── hyperframes.json ├── index.html # 顶层根组合1280×720 30fps时长 12s └── compositions/ ├── title-card.html # 可复用的标题卡组合480×220 └── nested-shell.html # 嵌套一层托管 title-card 的组合工程声明文件有两个package.json仅含name: composition-reliability-fixture与private: true避免被误发布hyperframes.json 声明了工程格式与资源映射该文件头部还包含$schema与registry键指向项目官方 schema 与上游 registry其paths字段将组合 HTML 目录映射为资源类别格式与仓库 schema/hyperframes.json 描述的工程结构对应{ paths: { blocks: compositions, components: compositions/components, assets: assets } }也就是说compositions/下的每个 HTML 被当作组合块block源来解析——这正是打开工程验收步骤的前提。三、顶层 index.html把验收场景排版成一条可编辑时间线index.html 是整个夹具的舞台。根节点是一个组合容器用data-*属性声明画布元信息main idcomposition-reliability >template idtitle-card-template section idtitle-card-root>template idnested-shell-template section idnested-shell-root>const fixtureDir join( dirname(fileURLToPath(import.meta.url)), ../../../tests/e2e/fixtures/composition-reliability, );随后用两个用例把 README 的核心主张一一转成断言用例一夹具结构自身的静态契约index.html中引用compositions/title-card.html的宿主恰好有两个且data-start依次为[0,4]复用 时间错开nested-shell.html内部的嵌套宿主存在且其data-composition-srctitle-card.html指向的依赖文件确实存在于compositions/目录existsSync校验堵住引用悬空标题模板里.hl-mask文本包含 Reliable compositions其style匹配/\.hl-mask\s*\{[^}]*overflow:\s*hidden;[^}]*background:\s*transparent;/且文字节点是H1透明遮罩拓扑得到机器可读的保证collision-a与collision-b同轨道且 A 的startduration恰好等于 B 的start相邻不重叠layer-overlap与collision-b起点相同但轨道不同跨轨时间重叠成立。用例二编辑会落到正确的源码层这是整个夹具最有价值的守门点。测试通过hyperframes/studio-server/source-mutation导出的patchElementInHtml以及同目录domEditing模块导出的buildDomEditStylePatchOperation模拟两类真实编辑移动时间线上的宿主对index.html中的title-host-a打补丁把start改为 5、duration改为 2。断言结果是修改只出现在根工程源码里data-hf-idtitle-host-a、data-start5、data-duration2均被命中根源码不出现data-hf-idtitle-text标题模板源文件也不含新颜色——时间线宿主编辑不会泄漏进被复用的组合模板。给标题文字换色对模板里的title-text打一个 style 补丁color: #12b886。断言结果是补丁命中颜色只写到title-text元素自身的style上title-mask的style属性保持为空且重着色后的 HTML 不含根工程宿主标记、根源码也不含该颜色——内容级编辑只落在组合模板层绝不外溢。把两个用例合起来看它验证的正是 README 所说的 composition editing as one stack时间线型编辑与内容型编辑虽然走同一条 DOM 补丁管线patchElementInHtml按data-hf-id精确寻址却因为data-hf-id归属的文件不同而天然分层编辑结果永远落在声明它的那份源码里。这与仓库中packages/studio/src/utils/blockInstaller.ts、timelineElement.ts、timelineElementHelpers.ts 等模块持续读写data-composition-src/宿主属性的事实相互印证data-*属性就是 Studio 把 HTML 转成可编辑时间线的那份共享契约。七、验收操作矩阵复制到 scratch 后逐项演练README 给出的浏览器验收操作清单与夹具元素的对应关系如下可直接作为手工验收脚本验收操作在夹具中如何发生打开open打开工程根index.html校验 1280×720 画布与 4 条轨道、6 个剪辑正确物化组合插入composition insert从组合源插入/复用title-card观察新宿主出现在预期时间与轨道单/多移动single/multi move单选拖动title-host-a或框选两个标题宿主一起移动校验源码data-start同步碰撞放置collision placement把一个剪辑拖向collision-a/collision-b邻接处验证碰撞吸附或落至新轨道重叠分层overlap layering观察collision-b轨道 2与layer-overlap轨道 3同时刻重叠时的视觉层序剪切cut对标题宿主执行剪切校验剩余片段与模板不受影响标题颜色/字号修改title-text的颜色与font-size验证只落在模板文件对应元素上单步撤销one-step undo执行一次撤销校验所有文件回到操作前状态每条操作都应遵循同一条前提先复制目录到 scratch 再动手——因为浏览器验收会实际改写工程文件检入的夹具源必须保持原样才能让集成测试与后续验收永远在同一份标准答案上运行。八、小结一份夹具如何撑起一整套可靠性主张回看整个 fixture它的巧妙之处在于用极少的素材完成了极强的覆盖一个可复用的标题卡、一个嵌套壳、两条纯色碰撞条与一块半透明叠层就构造出复用 / 嵌套 / 透明遮罩 / 碰撞落轨 / 跨轨分层五个正交的编辑风险面而 compositionReliabilityFixture.integration.test.ts 则把其中可自动化断言的部分结构契约、编辑归属分层变成了 CI 里每次都跑的守门测试。对于想要为 Studio 贡献组合相关功能或新增验收夹具的开发者这份 fixture 就是现成的模板一个能被搜索、被引用、被复制到 scratch 反复演练的最小工程胜过一段随时可能过期的口头验收清单。【免费下载链接】hyperframesWrite HTML. Render video. Built for agents.项目地址: https://gitcode.com/GitHub_Trending/hy/hyperframes创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考