Alpha 3 已经拥有图片、视频、网页与 Shader 场景，也能让插件、媒体、音频和自动化沿着同一条事件路径工作。到了这个阶段，继续增加入口已经不能证明它更接近长期自用；真正的问题变成了：一条正常规则在真实桌面上持续运行时，系统是否知道哪些工作根本不需要再做。
因此，这一轮留下的不是功能清单，而是一次稳定化判断。
150 毫秒规则暴露的不是“小内存问题”
一次真实音频验收中，规则每 150 毫秒重复请求同一个双屏图片场景。旧的世代门只在最终提交处串行化结果，却没有阻止前面的资产解析与图片解码；同一张大图仍会被反复准备，虚拟内存最终增长到 47.2–54.0 GB，并拖累整个系统资源。
问题的核心不是某个解码器偶然泄漏，而是应用路径没有在昂贵工作开始前识别“这和正在显示、或正在准备的请求完全相同”。
把相同意图收束在资产准备之前
中央场景应用入口现在先读取每台显示器的真实活动状态：已经生效的相同请求直接保持幂等，仍在准备的相同意图合并为一次任务。资产准备本身也采用 single-flight，并在解码前再次确认当前世代仍然有效。
这项修复同时约束 UI、规则、播放列表、SDK 与启动恢复等所有调用者。它没有要求每个入口分别记住节流规则，而是把“不重复做昂贵工作”放回共同边界。
选择隔离，而不是把一次通过写成可用
Windows 进程音频捕获在正常桌面验收中没有达到放行条件，因此默认构建无法启用，Manager 也不会提供这一选项。代码只保留在非默认实验特性中，用于隔离调查。
后续两轮受限探测已经分别通过三秒捕获与默认端点静音场景，进程和作业的内存也保持在设定边界内。但进程重启、长时间运行和正式集成仍未验证，所以这些结果不会解除隔离。
插件成熟度来自边界，而不是数量
插件设置会重新按照当前 manifest 校验：已经移除的键不会继续注入运行时，类型发生变化的旧值会回到新默认值，有范围限制的数字也会重新规范化。旧数据仍被保留，以便可逆降级，但运行中的 Lua VM 只能看到自己声明过的配置。
类型化话题、运行遥测、Widget 锚点与逻辑单位，以及 Spectrum、Pulse、Daycycle 等第一方插件，共同验证的是同一件事：新的能力应当沿着可复用的 api-1 边界生长，而不是为某个演示添加特殊通道。
Alpha 3 仍然没有冻结
复杂图片、视频与网页切换链路以及真实热插拔已经留下通过记录；Explorer 重启恢复、显示设置变化、最新候选的单屏目标保持性与高频规则复验仍需要完成。进程音频捕获不属于默认放行能力，它会继续留在隔离区。
只有剩余 P0 / P0* 门槛关闭、候选身份和记录能够互相对应以后，0.1.0-alpha.3 才会成为适合长期回到的个人基线。
网站只记录当前事实
Projects 页面会把这次事件写成最近决策，而不是把所有底层修复堆成更新日志。Lityura 档案继续区分 Ready、Active 与 Stabilizing，也明确标记哪些实验还没有资格进入默认能力。
这正是 Workspace 作为真实记录空间的用途：它不替项目制造完成感，只把今天已经确定的边界和下一次需要继续的地方留下来。
