studio-loop

Studio 改进循环

负责改进 Studio 体验：让它快速、响应灵敏且可靠。继续制作一支真正的 YouTube 视频，结合 NLE 剪辑和动态图形，并利用这一工作流发现和修复问题。每次实现更改都应用 studio-dev。

恢复项目和浏览器

• 恢复现有工作树、分支/PR 或堆栈、本地视频项目、正在运行的 Studio、浏览器会话和交接备注。继续该项目，而不是每次迭代都另起一个演示项目。保留无关更改和本地 QA 资源；除非用户要求，否则不要提交视频项目或导出文件。
• 根据需要检查 Git 状态和设置说明，但先使用 Studio，再分析其实现。只有在确认工作树和 URL 的情况下才复用服务。否则，从 packages/example 启动 Studio，运行 bunx remotion studio --no-open，并使用它打印的 URL，不要假设端口 3000 属于当前检出项目。必要时构建/安装依赖。
• 不要要求用户解锁 Mac。 使用现有的可用浏览器会话；若无法访问桌面/浏览器 UI，则为本地 Studio 启动一个全新的无头 Playwright 浏览器。此工作流不依赖 Mac 是否已解锁。浏览器工具与产品更改应保持分离。
• 通过点击、键盘输入、拖放、文件上传和截图来操作真实 UI。使用实际注册的 WebMCP 工具读取状态和执行受支持的操作，并在适当时直接编辑项目。不要用源码检查或模拟行为代替 UI 测试。如果浏览器执行失败，请诊断无头环境设置并报告仍未完成的验证；不要将自动化失败视为 Studio 的缺陷。如果 UI 验证仍受阻，将相关工作保留为草稿并报告未完成的验证，不要声称已完成验证检查点。继续不依赖 UI 验证的其他工作。

循环工作

1. 继续处理实际编辑任务。优先处理常见工作流：导入并预览媒体、排列／修剪／拆分片段、编辑文本和变换、添加动态图形和音频、拖动播放头／播放、撤销／重做、保存／重新加载，然后渲染并检查导出的视频。根据已完成的工作调整下一项任务。
2. 出现问题时，先记录可复现的交互和预期结果，再检查相关实现。更改代码前，记录相关的性能基线。留意反馈缓慢、缺少乐观更新路径、闪烁、令人困惑的文案／错误、布局问题、代码迁移失败、竞态和不必要的工作。检查持久化的源文件和可见结果，不要假设请求成功就代表编辑正确。
3. 修复观察到的问题。可以进行内部重构，但要保持有非实验性文档的公共 API 签名稳定。遵循 Studio 现有的设计、乐观更新／历史记录路径、CSS 重置、iframe 悬停处理和模式能力。可编辑代码的操作已经提供 Agent 式访问；不要添加重复的 WebMCP 包装器。按 studio-dev 的要求记录任何新增工具或变更的工具契约。
4. 在重建后的 UI 中重复原始交互。验证即时反馈、持久化／HMR、相关故障／导航竞态以及撤销／重做。覆盖适用的 Studio 模式；对于依赖嵌入的变更，使用真实的 Browser Studio iframe。重新检查受此修复影响的相邻常见操作。
5. 使用可比的项目、视口、交互和播放状态重复性能测量。确认播放确实已开始；测量期间避免并行构建／渲染。遵循 studio-perf，并在渲染／提交工作相关时使用 react-scan。解决性能回退，并如实说明测量限制，不要声称覆盖范围广泛。
6. 运行受影响的现有检查，以及 pr 要求的验证。遵循 writing-tests：除非明确要求，否则不要添加仓库测试用例。临时复现和性能分析脚本可以保存在仓库之外。
7. 将已验证的生产变更提交并推送到当前 PR，并及时更新其标题和说明。持续在该 PR 上迭代，直到用户要求设置检查点或改用其他 PR。返回继续制作视频并重复此流程；修复成功或报告进展都不代表应停止循环。

有需要时，可委派相互独立的复现、审查或范围明确的实现工作。为每位实现负责人分配独立文件，并协调构建和浏览器会话，避免影响他人的测量或编辑。

检查点与审查

除非用户同时要求暂停或停止，否则将“检查点”“让我审查这个 PR”或“开始下一批”视为请求交接一个稳定的审查节点，并继续工作。

1. 完成当前范围明确的修复及其验证。不要扩大本批次的范围。将未完成或无关的工作留给下一层，而不是把部分更改纳入检查点。只暂存预期的生产代码修改片段，检查暂存的差异，并保留同一文件中未纳入的修改片段。本地 QA 的脏文件不是放弃项目或延迟检查点的理由。
2. 提交并推送本批次，更新 PR 描述，说明行为、验证、性能结果和已知限制；如果 PR 处于草稿状态，则使用 gh pr ready 将其标记为可审查。提供 PR 链接和确切的检查点提交。如实报告待处理或失败的 CI；检查尚未完成前，不要称其为通过。
3. 冻结该 PR 的审查范围。必要时按照 gh-stack 采用现有分支，并在进行更多更改前创建下一层。以检查点分支为新层的基础，让其 PR 只显示后续工作。下一层有经过验证的更改后，创建草稿 PR，并让该批次始终留在同一个 PR 中，直到下一个检查点。在未获准强制推送的情况下，使用常规的 git push、gh pr create/edit 和带 PR 编号的 gh stack link 发布；不要调用会强制推送的堆栈命令。
4. 用户审查检查点期间，在新层继续进行同一视频和改进循环。不要继续向正在审查的 PR 中追加无关进展。如果审查反馈要求修改较低层，则在其所属分支上应用修改，并使用堆栈工作流更新依赖层；除非明确获准重写历史，否则应保留已发布的历史记录。
5. 用户合并父级 PR 后，核实其 GitHub 上的实际状态，并在现有的子 PR 中继续。更改子层基准前，先保留工作树中的更改。gh stack sync 会变基并推送，堆栈推送/提交可能会强制推送；未经明确授权，不要用它们重写已发布的子层。保留历史记录的做法是：获取并合并更新后的主干分支到子层，正常推送，调整其 PR 的目标分支，并按需取消堆栈关联/重建其余层的跟踪。检查最终的基准和差异仅包含剩余工作；即使是压缩合并后也要检查。未经明确授权，不要合并 PR 或强制推送。

单独询问状态不代表请求创建检查点。简要回答并继续。暂停/停止请求会结束当前循环；记录恢复工作的起点。除非用户提出要求，否则不要创建定时或后台自动化。

保持上下文连续

在 PR 之外维护一份简短的本地交接记录，记录项目和素材路径、工作树/分支/堆栈及 PR 链接、检查点提交、服务 URL 和启动命令、浏览器连接详情、复现步骤、基线/完成后的证据、测试、导出内容、已知限制以及接下来最有价值的编辑任务。不要在日志和交接记录中保存凭据或完整的渲染请求/环境负载。上下文变化后，从这份记录继续工作，而不是重新发现或重复已完成的工作。