BGM生成路径优化 #142
kdletters
Reference in New Issue
Block a user
Delete Branch "codex/bgm-generation-opt-v1"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
- 新增 ImageCanvasBackgroundMusicPresetModel：三组 30 个固定预设（用途 12 / 氛围 3 / 场景 15）与追加纯函数；按 Unicode code point 读取末位字符，标点用 \p{Punctuation} 判定，非标点先补中文句号，不去重、不截断、不改内部空白。 - 新增独立 BGM composer：canonical preview 计数不改写输入框，AI 补全、一键简化、撤销与生成按动作矩阵启用，错误复用 PlatformStatusMessage，底部保留固定 Suno 胶囊与动态泥点价格。 - 撤销按钮按权威设计矩阵渲染：可见条件为存在可撤销快照或本次临时快照，启用条件为可见且面板未锁定；AI 处理与提交期间显示并禁用，不隐藏。 - 新增预设轨道组件：多份等宽队列 + ResizeObserver 实测宽度 + rAF 按帧步进取模归位实现无缝循环；左右 15% 加速、中间 70% 暂停、箭头 hover 加速与点击离散滚动，底部细线标记当前控制区。 - 轨道只保留一份可聚焦预设按钮，视觉克隆移出可访问树但点击映射到同一动作；收起、锁定、页面不可见、dialog 切换和卸载都取消 rAF。 - 桌面 hover 控制区按 (hover: hover) and (pointer: fine) 启用，能力丢失时清空当前控制区，避免没有 pointerleave 的设备永久停在暂停态；reduced-motion 初值与运行中变化都生效。 - 触摸抬手后等待滚动事件停止再恢复 rAF，不使用固定等待时长，且不把 rAF 自身写 scrollLeft 触发的 scroll 计入空闲判定。 - 加速档按真机实测定为 238 px/s，左右控制区与箭头共用，避免两者之间出现速度突变。 - 将原共享音频 composer 收窄为 SFX-only，BGM 路由到独立组件并按 dialog ID 设置 key；SFX 的 Vidu 胶囊、时长滑块、默认 Prompt 与价格行为不变。 - 补充 ImageCanvasBackgroundMusicPresetModel、独立 composer 与预设轨道的定向测试，并扩展现有 composer 的 SFX 回归与 BGM 路由断言。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>Agent审查时应明确问题是否构成PR阻断，不得随意夸大问题影响面与严重程度。
基于最新 master
ef6281e1与当前 head5b4599f1复审。确认 1 个由本 PR 引入的可访问性阻断，详见 inline comment：当前可见的预设视觉克隆仍可获得焦点，会把屏幕阅读器焦点放入 aria-hidden 子树。另当前 Frontend、Native shell 两项 required CI 未通过，且提交历史仍有英文空正文 merge commit 与中文空正文提交。请修复焦点边界、补齐点击/Tab/触摸回归，整理提交历史并让当前 head 的全部 required jobs 通过后再请求复审。@@ -0,0 +376,4 @@className="image-canvas-editor__background-music-presets-queue"// 只有第一份队列进入可访问树，其余视觉克隆不可聚焦，// 保证每个预设只有一个键盘入口。aria-hidden={copyIndex === 0 ? undefined : true}[P2] 视觉克隆不能保留可获得焦点的按钮。轨道初始化会把 viewport 定位到第二份队列，但这里仅用
aria-hidden和tabIndex={-1}隐藏克隆；鼠标或触摸点击原生button仍会使其获得焦点，导致焦点落入aria-hidden子树，屏幕阅读器无法感知，后续 Tab 还会跳回屏外的第一份队列。请让视觉克隆成为真正不可聚焦的展示节点并把选择映射到唯一可访问实例，或采用等效方案确保点击后焦点不进入隐藏子树；同时补充初始中间队列点击后的activeElement、Tab 与触摸回归测试。native shell tests ci错误与本分支无关，且涉及生产代码，不在本分支修改。相同错误不应继续作为阻断条件。
结论：这是生产代码的 Runner 关闭契约缺陷，不是测试脆弱，也与 BGM 无关。
唯一失败是
process_session_runner_shutdown_reaps_active_session：terminated / runner-shutdown。最小正确修复：成功条件改为同时满足：
process_session_registry.sessions.is_empty()若存在
needs-reconciliation，等待超时并返回错误符合失败关闭语义。不要只给测试增加 sleep 或重试。CI 其余
1754项通过；失败代码与当前 master 完全一致，master 通过只是没有撞到该时序窗口。前端UI需要调整一下
图呢
复审最新提交，发现 1 个仍存在的响应式布局问题，详见行内评论。
@@ -16854,0 +17157,4 @@width: 15%;}@media (max-width: 640px) {[P1] BGM footer 的换行断点与既有 760px 规则不一致
这里直到 640px 才开启
flex-wrap，但上方@media (max-width: 760px)已把模型容器和生成按钮设置为width: 100%。因此 641–760px 内 footer 仍被强制放在一行：在 700px Chromium 中，动作组clientWidth=102px、scrollWidth=180px，动作按钮会与 Suno 区域重叠；即使未展示“撤销”也仍会溢出。请将 footer 的换行断点与 760px 对齐，或在该区间覆盖width: 100%，并补一项覆盖该宽度区间的浏览器回归。你说得对，这个门槛把整件事推翻了。
关键数字
[platformEntryResponsive.ts:3](src/components/platform-entry/platformEntryResponsive.ts:3)：
[PlatformEntryActiveFlowShell.tsx:307-313](src/components/platform-entry/PlatformEntryActiveFlowShell.tsx:307)：
selectionStage === 'image-editor'且!isDesktopLayout时，直接 return 那块桌面端提示，整个画布编辑器根本不渲染。也就是说：
@media (max-width: 760px)那条width: 100%不生效641–760px 这个带子完全落在门槛之内，两边差着 264px。所以：
这个 P1 是假问题
不是"不易复现"，是在产品里不可达。评审那些数字（clientWidth=102、scrollWidth=180）应该是把组件单独挂在 700px 视口下量的——脱离了外层的 1024px 准入门槛。我上一轮说"你得手动把窗口拖到 641–760 之间才看得到"也是错的：拖到那个宽度只会看到"请在桌面端打开创作工具"，你的质疑正好点在这上面。
顺带这也意味着 [index.css:8927](src/index.css:8927) 整个
@media (max-width: 760px)块里所有.image-canvas-editor__*的规则目前都是死代码——不止 footer 这几条。那是历史遗留，不是我这次引入的。同理，我自己加的那条
≤640px的flex-wrap: wrap也一样够不着，属于白写。当时的理由（"手机上一行塞不下"）在有 1024px 准入门槛的前提下不成立。建议
min-width: 1024px准入门槛，641–760px 不可达。≤640pxfooterflex-wrap要不要删掉，你定——留着无害（死规则），删掉更干净，但会和周围一堆同样够不着的 760px 规则显得不一致。@media (max-width: 760px)里那一大块画布编辑器规则已经全是死代码，清理它是另一个独立的事，不该混进这个 PR。有一点还没验证：
isDesktopLayout是这条平台入口路径上的门槛，我没有逐一确认所有进入画布的路径（比如直接敲/editor/canvasURL、或 RPG 入口）是不是都走这个 shell。如果存在绕过它的入口，结论要重估。要我查一下吗？链路
App.tsx / ActiveApp.tsx → PlatformEntryFlowShell.tsx:1 → PlatformEntryActiveFlowShell.tsx（它导出的函数叫 PlatformEntryFlowShellImpl，和同名文件不是一回事）。RpgEntryFlowShell 也是转手到同一个 PlatformEntryFlowShell。
所以线上走的就是我上一轮查的那个：PlatformEntryActiveFlowShell.tsx:307-313，selectionStage === 'image-editor' 且 !isDesktopLayout 直接 return 桌面端提示。门槛成立，1024px 结论不变。
但有个没门槛的渲染点
PlatformEntryFlowShellImpl.tsx:15716-15731（那个 18000 行的同名文件）里，selectionStage === 'image-editor' 是无条件渲染 ImageCanvasEditorView 的——那个文件里的 isDesktopLayout 只用来挡「创作主页」（creationLandingContent，提示语是"请在桌面端打开创作主页"，比活跃 shell 那句"创作工具"少一个词），没挡编辑器。
而这个文件目前只被 RpgEntryFlowShellImpl.tsx:2-3 重导出，而 RpgEntryFlowShell.tsx 实际用的又是 PlatformEntryFlowShell（活跃 shell）。也就是说这条重导出没有消费者，看起来是迁移剩下的旧实现。
所以
P1 依然可以驳回：线上唯一可达的入口有 1024px 门槛，641–760px 进不去。
我上一轮说"整个 @media (max-width: 760px) 块都是死代码"这个说法要收窄——前提是那个旧 shell 确实无人使用。我只顺着 import 追了一层，没有完全排除动态导入或别的入口，所以这句我不敢打包票。
P1实际上不可达