本版把 Studio 的外壳从 Wails 换成 Electron：窗口、打包、发布线、三平台自更新与全部 OS 能力都重新落到内核与传输层上，两个外壳跑同一份前端。另有三条主线：Plan 生命周期成为带授权世代的宿主态，ask 成为回合屏障；沙盒把外网与宿主授权拆成两轴，凭据文件对 bash 也拒绝；上下文维护改由经济边界触发，长回合内可反复折叠，recall 可检索已折叠区。自 2.10.0 起 131 个提交。
升级路径：Windows 安装器改为按用户安装，并在安装时接管旧的 Wails 全机安装（会弹一次卸载确认，拒绝也不影响本次安装）；Linux 的 .deb 与旧包同名，dpkg 按升级处理；macOS 替换自身 bundle。
新增
Studio 改由 Electron 承载
- 控制面首次落到真实 socket 上。此前 Wails 的资源服务器把
hub.Handler()挂成进程内中间件——没有端口、没有 CORS、没有第二条传输，独立进程的渲染器够不到。现在 hub 跑在 loopback HTTP 上，NewLoopbackGate是随之必须存在的边界：策略来自打开监听的宿主而非配置，请求必须发往本监听、必须以本监听为 origin 才能改动、必须携带本次启动铸出的凭据。无 origin 的读放行（顶层导航不发 origin），无 origin 的写拒绝。四类拒绝各有独立错误码。凭据只走 cookie（query token 会落进请求行、历史与 referrer），由宿主设置，页面 JS 读不到。 - Electron 外壳：内核由外壳派生，stdout 传一行版本化 JSON 握手（版本不认识就拒绝启动，日志一律走 stderr），stdin 是租约（父进程一端关闭即内核排空，覆盖崩溃与退出，三平台无信号参与）。页面落在
/_studio/，一条前缀规则即完成路由——反过来「枚举内核所有路由、其余落到页面」是资源服务器逼出来的形状，内核每加一个端点就要改一次。渲染器沙盒化、context isolation、无 node，preload 只递出动词。 - 页面不再自己推断身处哪个外壳。四个窗口控件此前直接够
window.go.main.App，绕过端口层；入口点靠探测 Wails runtime 决定 chrome 长什么样。两者都改问HostPort，它同时回答窗口是否自绘标题栏。CSS 按该属性而非外壳名分支，并同时发--wails-draggable与-webkit-app-region两种拼写——它们是互不理睬的两套机制。 - 窗口的四项 OS 能力接回，内核侧零改动（不加端点、不加事件种类）：拖入文件重新以路径到达（渲染器只拿得到
File，而要对文件本身动手的回合不能在字节副本上做，preload 经webUtils解析）；保存文本与导出插件包走外壳自己的对话框（压缩包仍来自浏览器构建已在用的端点）；通知复用internal/notify与共享的[notifications]设置。 - 状态栏图标成为协议而非绑定。此前托盘设置经 Wails 绑定读写配置文件，折叠数来自同进程喂养的 Tracker，第二个外壳只能自带一份副本。现在三条路由分别是「人设的偏好」「图标画的折叠」「写入两者的唯一入口」：偏好是持久意图，写入后直接回答它变成了什么；折叠是投影，每次读都重算，丢一帧下次读就补回来，所以是拉取而非事件。文案在有数字和词条表的地方按桌面语言组装，画图标的外壳不再各存一份格式化逻辑。
- 目录选择器成为
HostPort动词，三种回答互不折叠：路径、""（面板被取消）、null（该外壳没有选择器）——把后两者当成一件事的调用方会把面板开两次。面板从哪个目录打开由内核经/workspaces回答，外壳不自存副本；可新建目录，否则「只能打开已存在目录」读起来就是「这个应用没法开新项目」。 - 一个数据主目录只允许一个 Studio，无论哪个外壳持有窗口。同一主目录两个窗口就是每个会话文件的两个写者，而两个写者正是把 transcript 分叉成一长串恢复副本的原因；此前这条规则写在 Wails 外壳里，另一个外壳没有。身份移到
internal/instanceid——它一直就是「规范化后的数据主目录」而不是「一个应用」，安装版、便携版与 canary 因此能互相找到，经软链到达的主目录归位到它指向的那个。Electron 的锁键在 profile 目录上，于是 profile 放到该身份下，由平台回答「已在运行」。 - 远程主机能力从 Wails 外壳搬到
internal/remotehost，两个宿主由同一个 broker 构建同一份实现。拨号、在远端装内核、持有链路、给失败命名都不是窗口的事，而持有它们的正是要退役的那个外壳——Electron 此前根本打不开远程工作区。remotehost被归类为宿主适配器而非豁免分层：它实现前端驱动的端口、只由宿主装配，内核/控制器/工具层一律不得触达，三个用例钉住这一点。 - 被阻断的远程拨号，其提问成为规范状态。首见主机密钥或加了口令的私钥会让拨号停下等人回答，此前这个提问活在 Wails 总线上、经绑定返回。现在按三重身份定址（epoch 是内核生命期、operation 是哪次拨号、ask id 是哪个问题），重复回答同一件事幂等成功，回答别的不行；取消是独立状态而非「不存在」。不建 hub 级事件流：唯一订阅者是一个人几秒内就答完的模态框。
- 版本面板经
GET /studio/versions与POST /studio/pin回答，内核里的update.Hub读目录，外壳只陈述自己的 install。这是内核确实算不出来的部分——Electron bundle 里os.Executable()指的是宿主二进制而非应用，版本烙在派生它的进程上。目录地址是常量而非 install 携带，否则一个外壳就能把它指向另一条产品线，那里的条目会把 Studio 更新成别的产品。 - 安装某个版本成为两个外壳都能说的动词：
POST /update/install起编排（在internal/appupdate），GET /update/install是它的进度投影。进度是拉取而非流：一次成功的安装最后做的事就是结束那个本该在推流的进程。路由 202 返回而不等待——接管发生后已没有可用来发送后续回答的东西。 - macOS 自更新补上第三个所有者。它本是三方而非两方：旧应用授权交接、helper 执行替换、新应用证明自己健康并了结事务；替换方可以执行替换，但不能宣布替换是健康的。这个所有者随老外壳一起丢了，于是第一次成功的自更新会把
pending-update.json与回滚 bundle 留在原地，而ensureNoPendingUpdate把这堆残留读成一笔合法事务——之后每一次更新都被「已存在待处理更新」拒绝。UpdateHealthWitness在启动时读一次待处理事务，自身不带路径与版本，所以调用方只可能确认它实际启动自的那一笔。
打包与发布线
make studio走 Electron。它取代的路径按构造就只能在 macOS 上跑——裸 Go 二进制对 LaunchServices 不是 GUI 应用，脚本得先打成 bundle 再启动；Electron 的开发构建本身就是.app，一个脚本服务所有平台。- electron-builder 产出安装器、便携压缩包、磁盘映像与
.deb，沿用 Wails 线的标识与产物命名——更新清单与发布工作流读的就是这些名字，在这里改名等于发布一个没人会被推送的版本。架构词汇在打包边界翻译：electron-builder 说x64，发布说amd64（更新器跑在 Go 二进制里，问的是runtime.GOARCH）；映射不到的架构直接构建失败，因为静默的结果是一个描述着「没有任何运行中的二进制会去问」的平台的产物。 - 三平台都在各自的 GitHub 宿主机上打包，并按发布线实际读取的契约校验真实产物：没有产物叫
x64、有一个叫发布架构；清单频道旁没有 electron-updater 元数据；内核与 SPA 是 resources 而非归档成员；studio-manifest把产物挂到 runner 所在平台的键下。此前只有 Windows 的包真实存在过，macOS 与 Linux 靠的是一个配置文件加一次交叉编译。 - 发布线出 Electron 包。Windows 与 macOS 都分两步打包，理由说一次：两步之间必须对 bundle 做点什么——那里是 Authenticode 签名，这里是公证与钉封；Linux 不需要，所以一步。Windows 签名契约点名两个可执行文件而非一个：本外壳既发窗口也发它派生的内核，只签外层容器会让它们在安装后仍以未签名状态躺在磁盘上，而外面那层安装器已经被信任了。
.deb的包名、更新 helper 的路径/权限/属主与 polkit 策略由 CI 读真实包校验。helper 的路径不是选择：polkit action 的exec.path标注的就是它，授权只授给那一个；它同时也是 Wails 包占用的路径，所以一个目标同时满足策略与升级。--deb-user root显式声明——fpm 对-s dir记录的是构建机的属性，而 polkit 不会执行一个调用者本可写入的 helper，CI runner 的 uid 落在那个文件上等于装得上、更新时拒绝。- 桌面模块的 Go 测试首次进 CI，三平台。此前 Studio 工作流只构建外壳，主工作流的套件全是主模块的——也就是说更新引擎、它的提权 helper、发布侧工具与两个外壳，只在维护者恰好本地跑过的地方是绿的，而那正是会替换别人磁盘上运行中应用的代码。
Plan 生命周期成为宿主态
- Plan 此前是一个原子 bool，同时承载两个问题：用户是否在这个工作流里，以及现在什么可以跑。bool 说不出
AwaitingApproval，也说不出「批准授予的是之后的工作、而非已经在途的工作」——翻转它会把模型在规划期间流式产出的每一次调用追溯性地放行。planmode.Runtime持有唯一的State{Phase, Epoch}，Active是派生而非存储；每次被接受的转换都抬高 epoch（Submit与Revise也在内，因为它们都改变了当前是哪份授权）。每个供应商回合在采样前盖上它所处的状态，来源 epoch 已非当前的调用被当作过期拒绝并被告知原因。 - 规划期间的副作用改在效果轴上判定。Plan 向模型承诺宿主会拒绝写入、有副作用的 shell、能力安装、记忆修改与可写委派，而委派没有被拒绝：边界测的是
mutates，而task、run_skill、use_capability自身不记录任何变更——写发生在子代理里。在 auto 或 yolo 审批档下它们照跑，子代理还握着完整工具集。planmode是叶子包，零值读作「有副作用」，所以一个 fail-open 的屏障发不出去。委派按是否具备写能力拆分，read_only_task、parallel_tasks与只读子代理继续跑——那正是一个计划做调研的方式。 - 「规划期间这个能不能跑」此前有两个回答者（阶段门，以及一条测变更记账的回合策略），各自都不算错，洞在两者之间，而委派的修复只落到了其中一个。判定收敛到唯一所有者：
taskpolicy不再执行，planPhaseEffect成为唯一分类器。阶段判定移到第一个效果之前而非仅在权限之前——代理只有在解析之后才说得出真实目标，而ResolvedCall.Commit按其自身契约位于宿主检查之后，此前它跑在检查前，于是一次被拒的规划调用仍可能留下一条已提交的账本条目。 - 宿主拥有的决定成为投影。想要一份「等你处理」清单的前端，此前只能从事件里自己拼并记住看过什么——而那正是把前几步刚分开的所有权重新揉回去的做法：一个面板、一对 Allow/Deny，计划批准开始长得像权限提示。
Decisions每次被问时从各自的所有者派生，自身无状态，Kind指明所有者、所有者就是回答者（plan_approval回到ResolvePlanDecision，ask回到AnswerQuestion），刻意没有Decision.Approve。身份是所有者本就发出的 id 原样送回，过期卡片因此天然无害。 - Studio 渲染宿主拥有的计划生命周期。此前它把计划卡的三种结果折成一个 approval 布尔，再自行设置 plan 模式——本就有损（修订与退出是不同的转换），生命周期成为宿主态之后还会跟内核自己的动作抢：前端的
SetPlanMode(false)可能退出一个批准刚刚带进执行的工作流。现在两端都把结果整个经ResolvePlanDecision送出。为此 serve 增加POST /plan-decision，宿主不再持有该决定时回 409 与带码的拒绝——这是并发而非客户端错误。窗口持有的、宿主已不再列出的卡片被封存而非删除：它不再可回答，但作为「发生过什么」的记录留在屏幕上。 - 待办的写入被区分成「改计划」与「推进执行」。宿主此前只持有一个事实——任务清单变了——于是每轮重写同样两步的回合，与真正完成它们的回合产生同一个信号；这项工作背后的会话花了十二小时、1065 次任务清单写入，完成步数固定在 22。
ClassifyTodoTransition从清单本身读出一次写入做了什么，身份取稳定的step_id（没有时取规范化文本），绝不取位置。重新规划刻意不算推进：把它算作推进就等于允许一个停滞的回合靠重写自己的清单来自我续命。 complete_step的结论来自任务清单本身。它此前每次签收都以「宿主已推进任务列表，请继续下一步」结尾，而这句话是在不知道是否还有下一步的情况下断言的；宿主早已推进完并知道答案，只是模型唯一会读的那部分——工具结果——没带上它（#8816 就是那个回合：最后一项待办完成，结果仍索要下一步，模型于是发明了一个，回合结束不了）。- 宿主持有的步骤 id 投影到模型读得到的地方。
complete_step把step_id标为 PREFERRED，而宿主自计划投影起就为每一项持有一个——模型却从没被展示过：todoState不进提示词，todo_write只回计数，三个清单渲染器全打裸序号。于是模型能引用的只有它被展示的序号，而那恰恰是重新规划在上方插入一步之后会失效的引用。
ask 成为回合屏障
ask取得的是只有用户能提供的东西。它不是请求权限的方式、不是计划卡、也不能替代代理自己能做的调研——而此前那条准入判据（「无法从请求、代码或合理默认值中解决」）让模型把任何它有看法的事都自行解决了。有推荐意见不等于这个选择归你：当两个合理选项会改变架构、公开 API、数据模型、依赖、UX、兼容性、范围或任何不可逆的东西时，就问，并把推荐放在第一位。- 更要命的是时序。写在问题旁边的一切都是在答案存在之前写的：
ask("删除还是归档?")与write_file(...已删除...)在同一批里，无论用户怎么答都会执行那个猜测。工具自行声明屏障（而非按名字匹配），扫描在调度之前跑；只读的同批调用同样停下——共享同一个并行段才是问题，写不写并不是。被推迟的调用会被告知它们没有被带过来，以及为什么。 - 没人可问的运行不再自己回答自己。旧的回退让模型「用你的最佳判断」，这与唯一会把调用放到这里的规则直接矛盾——决定保持未解决，模型被指向
conclude_blocked而不是一个它还得为之辩护的猜测。任何审批档都不代用户作答。
沙盒：外网与宿主授权分成两轴
network此前扛着两种互不相关的能力。在 Seatbelt 上实测：(deny network*)连 Unix socket 一起挡，于是关掉外网的用户同时失去 ssh-agent——ssh-add -l与 SSH 签名提交都停，而这两件事都不需要互联网。反方向上，默认的network = true把宿主的 agent socket 交给了每一条命令，探针证实了它值多少：在磁盘上的私钥已被删除的前提下，受限 shell 仍然让宿主 agent 产出了一个有效签名。拒绝读取（ForbidReadRoots）对此毫无作用——持有密钥与有权使用它是两回事。Spec现在在Network之外携带HostAuthorities，策略点名服务而非路径，每个后端按各自客户端的方式解析ssh_agent/docker/podman。默认只授予ssh_agent：签名是编码工作流的日常，而容器守护进程的 socket 是全机执行权。零值Spec什么都不授，新的调用点在明说之前都是受限的——MCP 服务器因此不再获得任何宿主授权。受治理的是三个点名端点，DBus、Wayland、X11、gpg-agent、keyring 与任意 socket 仍可达，所以主张始终是「这些端点受治理」，绝不是「宿主 IPC 被隔离」。- 凭据文件对 bash 也拒绝读取。
read_file拒绝~/.ssh/id_ed25519，而cat照样返回：凭据拒绝表只接到了进程内的读取工具，从未接到sandbox.Spec.ForbidReadRoots，于是 OS 边界放行了每一条 shell 命令——包括cp、tar与任意解释器，这也是它无法在命令分类器里打补丁的原因。出网默认开启、auto 档两半都放行，所以那次读取和随后的 POST 都不需要任何提示。internal/secrets现在持有两个消费者共读的那一份表：只装秘密字节的文件默认拒绝（SSH 私钥、~/.aws/credentials、~/.netrc、~/.git-credentials、~/.pypirc、gcloud ADC）。把配置混进秘密的文件刻意不在其中，而且是实测而非推定：拒绝~/.config/gh/hosts.yml会让每一次gh调用在启动时失败，拒绝~/.npmrc会静默改掉 npm 的全局 prefix。[secrets] protect_credential_files = false可关闭。
上下文维护
- 压缩此前只认一条边界：声明窗口的
compact_ratio。一个声明 1,000,000 token 窗口的供应商预设因此把触发点放在 850,000，而一次真实会话跑了 2,150 轮、提示词峰值 321,265——预算的 37.8%，维护一次都没被尝试过。容量与经济性是两条不同的边界：模型支持 1M 上下文，不等于把 300K 的提示词为几百个代理回合反复重放是划算的。自动触发改为两者先到者：窗口的compact_ratio，或可见输入的context_soft_limit_tokens（默认 160000，负值关闭）。 - 一个回合内可反复折叠其已闭合的前缀。此前回合只能被检查点一次，之后折叠区止于该回合的第一条消息，长到能两次触及边界的回合就得扛上它跑过的每一轮——推动这项工作的那次会话在一个回合内持有 321K token、2150 轮，而第一次折叠只够到它之前的 30K。现在检查点能够到的是该回合已闭合的事务：止于
closedPrefixEnd（该回合发出的每一次调用都已有结果的最后一点），所以在途事务永不被劈开，开启该回合的那条请求由keepIndexes逐字保留。 recall可以检索，而不只是定址。此前它只能读别的东西已经命名过的位置，而命名者都会衰减：折叠索引被限制在窗口的 1%、会裁掉最旧的行；canonicalOriginFor对任何位于先前投影内部的东西返回 -1，二次折叠的消息根本没有可推导的规范位置。底下什么都没丢——压缩重写的是模型看见的东西，从不触碰规范 transcript。所以recall增加了查询，在canonical[:CoveredCount]（后备存储，绝非投影）上走与 history 相同的 BM25 原语。检索与读取共用一份预算，空结果不计费也不算错误。检索成本线性且足够小以致不需要索引：1k 条已折叠消息 2.3ms，5k 条 11ms，20k 条 44ms。- 摘要漏掉的改动由宿主写回。折叠索引与摘要分工：
buildFoldIndex基于摘要会携带它们的承诺而跳过「有路径且命令失败」的改动。两条路径打破了这个承诺——mustFree下repairFoldCoverage量完覆盖率就返回（正确，硬上限不是再叫一次摘要器的地方），以及摘要器彻底失败时degradeFoldSummary装上一份什么都不带的机械摘要。两种情况下改动都同时缺席于摘要和索引，却仍在规范 transcript 里：数据留着，地址丢了。现在宿主用同一批回执自己写回路径与命令签名，只写摘要漏掉的部分。
子代理
- 只读子代理按写者的方式汇报。写者子代理以
complete_subtask结束，宿主会拿它的每一条引用与自己观察到的行为对账；只读子代理此前以散文结束，回执仍进入父账本，但语义那一半以一句无法验证的话到达，两者之间没有任何连接。工具附加的顺序是要点：readOnlySubRegistry先构建工具、证明子代理确实能调查点什么，然后才附上汇报方式——先附上的话，一个没有任何调研工具的子代理会因为握着提交发现的工具而通过能力检查，然后就它做不到的工作汇报。 - 完成报告得到的是裁决，而不是一个词兼两义。
complete_subtask此前对两种结果都回「accepted」：宿主能背书的报告，与宿主刚刚下调过其主张的报告，拿到同一个词，差别留在一句尾随的话里。回放显示子代理会怎么处理：首份报告被下调则继续干活，10/10；首份报告完好则停下，4/4，两边都无例外。契约中「exactly once，作为你的最后一次工具调用」被移除——它在写下之前就已被证伪：一个用「再去做」来回应被下调主张的宿主，不可能同时被一个只调用一次的子代理遵守。 - 子代理的审计通路端到端接通。统计「子代理是否按被要求的方式收尾」的通道此前接到了空处：全树没有任何类型实现
SubagentHandoffSink，它也从未在capabilityContracts里注册，于是RecordSubagentHandoff内部的类型断言在第一个包装器上就匹配不到，审计被丢弃——生产者有结构体、有接口、有绿色单测，这恰恰是没人发觉的原因：一致性说明方法存在，只有调用栈能说明值到达了。另一处：每个子代理都发往subagentProgressTracker.wrap()，而它返回event.FuncSink，函数类型不实现任何可选能力，于是那个 sink 丢掉了全部十二条通道。在benchmarks/fanout-width上实测前后：subagent_handoff0→4，contract_shadow1→5，completion_report1→5，protocol_recovery0→6，outcome_progress4→39。
其他
grep会在别处都没匹配时，去 ignore 规则指向别处的地方找一次。此前它遵守.gitignore且无从绕过、也无从得知这条规则生效过：dist/、node_modules/或任何生成目录里的匹配不可达，而返回的是一句光秃秃的「没有匹配」——由此唯一能得出的读法是「不在这里」，而那是比这次搜索实际能作出的主张更强的一句话。现在有三种回答：匹配、来自被忽略路径的匹配，以及「这里也没有，所以是真的不存在而非被过滤掉了」。放宽只放宽 ignore 规则：限制在 switch 之上检查，VCS 存储目录仍被剪掉，隐藏文件仍隐藏。- 响应边界在回合提交之前被分类。被输出上限截断的响应，此前以「bash 的参数无效；它需要 "command"」到达模型——宿主知道原因（
finish_reason是 length），但只把它发给 sink。一次真实会话从中学到的教训是不要再批量发独立调用，而这与整棵树的要求正相反，代价是每次调用一个往返。截断只可能切掉最后一次调用，所以只有它、且只在其参数解析失败时被丢弃。参数报错现在把解析器停下的字节引出来并在下面加脱字符标注。 - 后台任务完成会唤醒拥有它的会话。执行层本就是异步的，代理的控制流不是：后台任务跑完、排入一句话，然后要等用户开口模型才学得到它已经完成（#7948）。这里没有为此另建运行时——会话收件箱本身就是一个。
jobs发布CompletionEvent（一个身份而非一句话），控制器把它翻译成宿主续写。哪条投递路径生效绝不靠读「是否有回合在跑」来决定：回合可能恰好在读与入队之间结束，steer 尝试本身会报告身处哪个世界。 task_token_budget补齐三条轴中缺的那条。TaskBudget自轮次计数下线后就带着三条轴，token 那条是唯一一条 boot 从未映射的，没有任何键能设置它：轴存在、被执行、却打不开。它计的是模型做的工作量——usage.PromptTokens含CacheHitTokens，一轮里 160,000 提示词有 159,900 来自缓存，仍然累计 160,000；推动这项工作的那次会话以 99.9% 命中率把 393.7M 输入 token 中的 393M 走了缓存，若按缓存未命中计分，任何上限都会让它永远跑下去。默认关闭。- Reasonix 主目录像工作区根一样可被陈述。此前每一层都从环境变量里回读它，于是绑定一个主目录的唯一办法是改进程状态——这也是为什么第二个主目录意味着第二个进程，以及为什么
internal/boot里没有东西能并行跑。config.Roots是这个绑定，boot.Options.Home是入口。
修复
- 桌面窗格的提问没人接（#9509、#9527）。三个入口把 runtime 放进 Hub，只有两个到达时是接好的：
Open接自己的，RunGracefulListener在去服务的路上扫掉被收养的，而桌面窗口两条路都不走——它收养自己的第一个窗格并经Handler服务它。desktop/下从没有任何东西调用过EnableInteractiveApproval。于是那个窗格承载的对话没有 Asker，每一次提问都在有人正坐在屏幕前的情况下用「模型自行假定」的回退自答。之后打开的窗格走Open因而正常，这正是它读起来像「只有新会话能提问」的原因，也是回退到旧构建没用的原因——缺口是结构性的，不是回归。不变量移到发布边界：Hub 发布的本地 runtime 按定义就是由交互式前端驱动的。 - 桌面版本锁定从未落盘。
SetDesktopPinnedVersion把值放到配置对象上而SaveTo从不写出：[desktop]渲染器逐个手写相邻的键——close_behavior、tray、check_updates——而这一个不在其中。于是被按在旧构建上的机器下次启动就自由了，更新回它刚刚回滚掉的那个版本，而这正是锁定存在的唯一目的。 - 被阻塞的卡片能在 250ms 内自我封存：按钮消失、内核仍在等、下面那行还声称用户允许了他们从没看见的东西，运行随后等一个没人给得出的回答。两处缺陷同一个成因——
Decisions()只投影计划批准与提问，普通工具权限被跳过（注释说它有自己的所有者和自己的卡片），而前端把那份清单读成「还开着的全集」并封存其中缺席的一切。补全投影是必要但不充分的：在提示存在之前拍的快照，与在它已解决之后拍的，漏掉它的方式一模一样，所以按轮询封存是构造性地有竞态。封存现在骑在内核记录每一次决定所用的那条有序流上，该回执同时带着结果——卡片说出被决定了什么，而不是对它叫不出名字的一切都猜「已允许一次」。 /plan-decision在桌面里没有路由。内核注册了它、sse.ts也调用了，但外壳的 API 表与 dev 代理都不知道，于是端点回的是index.html而非 JSON：桌面应用里的计划决定不起作用，pnpm dev对着活内核也一样。- 未完成的计划仍被要求继续（#8816）。见上「
complete_step的结论来自任务清单本身」。 - 收窄性的转换会丢掉在途工作。epoch 过期此前被写成「一次转换使先前授权下产出的一切失效」，强于它要防的东西——它防的是早先的工作继承它当时不具备的能力。打开 Plan 做的恰恰相反：它收窄可运行的范围，在途的东西什么也没多拿到，而拒绝它会在每次有人碰开关时丢掉该回合的其余部分（只读调用也一样），该给出文件的地方给出「计划授权已过期」。现在只在放宽方向的转换上拒绝。
- 批处理扫描看不见的决定不会结束回合。屏障扫描的是模型写下的调用，在调度之前；而扩展会在
executeOne内部替换调用，即在那次扫描之后——于是一个被变成提问的读取工具，让扫描看着一个已不存在的调用，模型写在它之后的一切照跑。该调用现在自己报告：结果的工具是决定屏障时，回合就在它执行的地方结束。 go test -race在本分支上长期是红的。acknowledgeUpdateHealth在它启动的 goroutine 内部读updateProbation与commitUpdateHealth，而没有任何东西等待该 goroutine，于是在 cleanup 里恢复它们的测试写的正是仍在运行的等待所读的。三个 CI job（desktop、desktop-macos、race）一直挂在这上面。在武装等待的地方读它们也正是它们的语义。此前一直可复现，只是 pre-push 清单跑桌面模块时不带-race，而那是唯一看得见它的开关。internal/control整包 panic，把覆盖率闸门堵死。三个测试把 executor 装配成&agent.Agent{}，而New才是 sink 不再为 nil 的地方（回退到event.Discard），于是被种下的计划观察到的第一件事就解引用了那个 nil。covergate会跑每条敏感路径的测试，internal/control/approval.go是其中之一，退出 1 的包会把整个闸门带下去——一个永远是红的闸门不是闸门，它的下限停在它停止运行那天读到的值上。panic 消除后：sandbox 69.4→73.5，shellparse 63.6→64.5，shellsafe 59.3→61.1，approval.go 93.9→94.3。- serve 的唤醒测试是先 flake 后 race。
Ask在锁下注册问题、释放后才通知（正确——宿主回调若持在那把互斥锁下会阻塞其他每一个问题），但这意味着raise()等待的轮询可能在回调运行之前就返回。 - Windows 上的 TempDir 拆解约四分之一的运行失败，每次是不同的测试，永远表现为「刚清空的目录删不掉」。不是迟到的写者：在观察到失败的同一条命令里抓取，幸存目录里什么都没有，几分钟后仍然没有，然后干净地删掉了。仍开着的句柄会以另一种方式失败——Windows 根本不允许删除打开的文件，回答的是共享冲突而非目录非空。剩下的解释是尚未安定的拆解。契约改为时间性的：测试拥有的目录必须在短界限内变得可删，泄漏是活过截止时间的内容。
.deb闸门对一个正确的包报红。helper 在那儿、在 polkit action 点名的路径上、权限 0755、属主 uid 0——正是--deb-user root所要求并得到的。失败的是断言：dpkg-deb打印0/0而模式要root/root。打印哪一种是读包的机器的属性而非包的属性。这是标准规则警告的那种词表判断的微缩版：一个匹配事物拼写而非事物本身的判断。- Linux 包构建不起来、macOS 的 blockmap 关不掉，两个都来自 CI，也都是 Windows 宿主够不到的平台。fpm 要一个项目主页，electron-builder 没有它就报错，于是 Linux 那条腿在打包之前就失败——这也意味着上一步加的、用
dpkg-deb回读包的闸门此前一次都没跑过。macOS 的 zip 会带一个 blockmap 而没有选项能关掉它：differentialPackage: false是 nsis 选项，Windows 吃下了它，这就是 Windows 那条腿绿的原因。而.blockmap带着发布前缀，那个用来拒绝残缺发布的产物计数会把它算作一个，从而掩盖一个缺失的产物。 - 界面说发生了什么，而不是它怎么评价自己（#9524）。字体设置解释说找不到的名字「不会弄花」界面——那是没人有过的担忧——却从没说下面那行是干什么的；空会话开在一句口号上，副标题用的是实现自己的词汇，而那是新用户看到的第一屏。两处都按同样三件事重写：你能做什么、你会观察到什么、有限制时限制是什么。以同样三条规则扫过
src/ui，取提示、描述、空状态与引导文案，按钮与短标签不动，共 51 处，英文同步更新。
性能
- 不再为答不出东西的效果走查付费。实测而非猜测：17 次录制会话、393 次真实 bash 调用，总体 p50 472ms，但 46% 的调用是宿主无法分类的，这些跑 957ms，其余 387ms。差距来自两次全工作区走查（命令前一次、命令后一次），而走查本仓库的 2 万个条目热态约 300ms：570ms 的差距，600ms 的走查。三处都是白付：后置走查在不可能有结果时也照走（
changed()拒绝被截断或缺席的前置扫描，而后台调用的前置扫描是刻意跳过的）；超过 5 万条目的上限之后整件事纯亏损（两次 5 万条目走查换不到任何东西，每次不可分类调用都来一遍——现在任务级记住第一次）；而且它停不下来（scanWorkspace不接 context，于是按停止会迅速杀掉命令，然后卡在一次不可中断的走查上——这就是「停止没用」在足够大的树上的样子；现在每 512 个条目检查一次）。 - 环境探针按决定它的东西做 key。
prompt.go写明了这一段的用途：「这段前缀对机器上的每个项目和会话都相同，它们共用一个缓存条目。」而指纹里含DenyRoots——也就是工作区根——于是机器上每个项目各拿一个条目、把十一个探针全重跑一遍，与同一个文件里写明的意图相悖。测量先于假设：internal/boot的测试要 160s，我最先怀疑的临时目录清理在 359 次删除里只占 0.9s，CPU profile 里 98.96% 是runtime.cgocall。PATH 决定探针解析到什么，deny roots 只在之后决定要不要跑已解析的东西——昂贵的那一半是机器的属性，便宜的那一半是工作区的属性。internal/boot160s→105s。真正的重点是生产环境：打开一个没打开过的项目，启动时要付十一个子进程。
安全
golang.org/x/crypto升到 v0.55.0（GO-2026-6303）：v0.54.0 的 ssh 包对非公钥认证回调不强制 source-address 关键选项，govulncheck 经sshtest.Server.handleConn追到调用，扫描在每个分支上都失败。- 重定向守卫合三为一，信任决定保持三份。同一个判断存在三处：
validateCLIUpgradeRedirect、validateOfficialRedirect与 update 包的TrustedRedirect。第一和第三除错误前缀与主机判定函数名外逐行相同，第二是同样的规则折进一个条件。而第三个从未接到任何客户端——这正是此类重复失败的形状：没人在看的副本，在有人注意到它不再被调用之前，就先停止被维护了。internal/redirectguard持有机制（仅 HTTPS、无凭据、无端口、跳数上限、调用方点名的主机表），ErrRefused给拒绝一个身份。主机表刻意保持分离：一次下载信任哪些主机是那条路径自己的安全决定。 - 更新器移入内核并接上它找到的那个守卫。Electron 外壳的宿主二进制由根模块构建，而 Go 的 internal 规则管的是导入路径而非模块：
reasonix/desktop/之外的任何东西永远无法导入reasonix/desktop/internal/update。搬迁过程中TrustedRedirect暴露为孤儿，而它不是死代码——它是更新客户端必须使用的CheckRedirect，自带注释说明重定向可能把一次已认证的下载带到另一台主机上，却从未被引用。外壳从netclient组装客户端而后者不设重定向策略，所以每一次目录读取与产物下载都在跟着重定向随便去哪。minisign 校验是挡在这与「已安装的产物」之间的东西，所以这是缺了一层而非一扇敞开的门。
内部
frontend-parity：REASONIX.md 说行为放到控制器上、三个前端因而都继承，而没有任何东西回读这一点。serve 拿到的SessionAPI声明了SwitchBranch却从不调用——会话分支最后变成只有 chat TUI 有，是意外而非决定，另有 149 条边处于同一状态。矩阵从go/types的编译导出数据读出，绝不从选择器名字读：Close与Status既是能力也是标准库方法，按名字匹配会把os.File.Close记成 serve 在驱动Lifecycle.Close——一个掩盖债务的假「已接线」，而这是棘轮唯一不能失败的方向。- 工具 schema 预算成为棘轮。它守的数字是真的：某次实测运行的 5,577 个提示词 token 里有 3,995 是内建工具 schema，每个会话在做任何事之前就先付掉。机制不是：测试里一个手改的常量没有更新路径、也不留下它为何移动的痕迹，于是一次九个 token 的文档改进唯一能做的就是把它绊倒。改为
schema_budget.json+-update-schema-budget+-allow-schema-widen，记录在 5590（低于常量里的 5600——树本来就已经让出了一些，而没人看得见）。 - 依赖全量升级，并支付 go 1.26 的账单。
mvdan.cc/shv3.14.0 要求 go 1.26.0，指令随之移动，而指令正是把 modernize 的newexpr规则在全树打开的东西；那 75 处发现是这次升级的价格而非它继承的债务（同一棵树在低一个版本上 lint 报 0）。fixer 写出的//go:fix inline指令被丢弃而非保留，因为 govet 会把它读成「内联每一个调用点」的要求——那会删掉承载语义的名字。 - 上下文检索基准：一整套实验设施（语料只持有问题从不持有答案、模板占位符按运行生成、污染闸门只认带本次运行熵的代号、fixture 在代理读过之后离开磁盘、按模型回合而非工具事件顺序判定路由）、检索漏斗分级（
NoRetrieval/SearchMiss/HitNotRead/ReadButAnswerWrong/CueRead/Recovered）、查询审计（序号、轮次、排名、与前一条的差异、遗漏了宿主探针的哪些词）、超时分类（PostTargetRunaway与SearchSpiral要的是完全不同的修法）、以及按充分性而非命中来衡量停止。前两次试点都被同一种方式污染：模型 grep 出本仓库的corpus.go并读到了答案。 - 桌面 Go 门禁、真实产物打包契约、
todo_progress语义进度语料提取器与重规划分段器进树，readiness 的两个零生产者审计信号删除，Goal 接受时冻结的项目声明契约（仅影子，不改判定），以及沙盒三个保护维度（完整性/机密性/权威）与 macOS 宿主代理面未测量的记录进文档。
macOS 已用 Developer ID 签名并公证，打开时不需要清除隔离属性。Windows 的窗口、内核与安装器都经 SignPath 做了 Authenticode 签名。Linux 从 .deb 安装。
三个平台都能自更新：Linux 走自己的包，Windows 运行下一个安装器，macOS 替换自身 bundle。