Conversation
Signed-off-by: Lihua <1017343802@qq.com>
Signed-off-by: Lihua <1017343802@qq.com>
Signed-off-by: Lihua <1017343802@qq.com>
Signed-off-by: Lihua <1017343802@qq.com>
Signed-off-by: Lihua <1017343802@qq.com>
Signed-off-by: Lihua <1017343802@qq.com>
Signed-off-by: Lihua <1017343802@qq.com>
Signed-off-by: Lihua <1017343802@qq.com> (cherry picked from commit c6208daea8b4def86cbdf63dc35a31faaf0a5046)
Signed-off-by: Lihua <1017343802@qq.com>
huangruiteng
left a comment
There was a problem hiding this comment.
审查对象:#4915 @ 4e332dd(exact head)。
-
问题与边界:把新安装默认状态统一到 .loopx、旧安装保留原注册路径并只在显式 plan_id 下迁移,是合理的交付边界。迁移前预览、内容绑定、私有备份、冲突拒绝和回滚都对保护原始数据有价值;本次没有对任何真实 Goal 执行迁移。
-
关键路径:migrate-local-state 会在 loopx/local_state_migration.py:291 将整个旧 runtime root 改名到 ~/.loopx,因此 extensions/state.json 也会一同迁走;core CLI 通过 paths.select_default_runtime_root 选择新/旧路由,DSH GoalBar 会按 registry 的 state_file 读取。
-
阻断发现 [P1]:扩展 CLI 的默认读取没有跟随上述路由。loopx/extensions/runtime.py:69-75 的 default_extension_state_file(None) 仍固定返回 ~/.codex/loopx/extensions/state.json;普通 loopx extension list/enable 在 loopx/cli.py:492-495 与 cli_commands/extension.py:64-68 传入的正是 None。迁移成功后,扩展启用状态已在 ~/.loopx/extensions/state.json,但 list 会以 ok=true 静默返回空列表,enable 等操作还可能重新创建旧路径。隔离临时目录复现:迁移后路径有 1 个扩展,隐式默认读到 0 个。请让扩展默认读取/写入复用同一个 selected runtime route,并增加 execute/rollback 后普通 extension list 的回归测试;不应只靠文档要求操作者每次显式传 --runtime-root。同类 governed-capability 默认目录也可一并核对(目前未发现其无参生产调用,非独立阻断)。
-
验证:tests/test_local_state_migration.py 8/8;project-registry + refresh-isolation 74/74;DSH GoalBar focused vitest 17/17、host TypeScript typecheck 通过;git diff --check 通过。pnpm 完整依赖校验受私有 registry 两个可选二进制 404 阻塞,已安装的直接 vitest 可运行;按该 Goal 的 wait_for_ci=false 没有轮询远端 CI。最关键的扩展迁移反例未被现有 8 个迁移测试覆盖。
-
结论与后续:REQUEST_CHANGES。修复后请更新 exact head,再验证旧路由、全新 .loopx 路由、显式迁移与回滚下扩展状态的一致性。面向下一次改动,最小的相关重构是只保留 paths.py 一个默认 runtime 选择器,避免扩展子系统重复持有路径权威;不需要扩大成新的迁移框架。
English verdict: REQUEST_CHANGES — the migration moves extension activation state to the new runtime root, but ordinary extension commands still read the old hard-coded default and silently report no extensions.
huangruiteng
left a comment
There was a problem hiding this comment.
动机
评审精确 head 4e332dd8689ebd7ba891d37b5b6b01af1e743a8a。新安装将全局与项目 Goal 的本地状态默认收敛到 .loopx,现有注册继续沿用声明过的旧路径,显式迁移则需要可预览、可备份、可回滚,避免改默认值时暗中搬动用户数据。
改动思路
路径选择由注册状态与默认路由决定;migrate-local-state 先生成内容绑定的 plan,再在停工条件下执行备份、状态迁移、注册改写并留下 rollback receipt。doctor、生成的 CLI 命令、SSH/LaunchAgent、Codex App scheduler bridge、DSH GoalBar、文档和打包 chat 示例跟随选中的路径。这些方向合理,迁移的读写端却必须共同遵守同一个路径选择权威。
具体改动
PR 修改了全局 registry 与项目 Goal 的默认目录,增加冲突/符号链接/源变更检查、备份与回滚,并更新上述调用者和示例。迁移正向与回滚的 8 个聚焦测试在当前 head 通过,diff whitespace 检查通过。仍有一处遗漏:loopx/extensions/runtime.py 的 default_extension_state_file(None) 仍固定返回旧的 .codex/loopx/extensions/state.json,普通 loopx extension list/enable 未给 --runtime-root 时会使用它。
对主干的风险
这是数据路径迁移,不应在默认命令静默制造第二份状态。执行迁移会把原有 extensions/state.json 随旧 runtime root 搬到 .loopx,但普通 extension 命令随后会读取旧目录:已有启用的 extension 被显示为空;enable 还可能重新写出旧目录状态。合成隔离状态复现了“隐式列表 0 个、显式迁移目录 1 个”的差异,未触碰用户活动状态。请让 extension 的默认状态文件走统一的 select_default_runtime_root,并补 execute/rollback 后不带 --runtime-root 的普通 CLI list/readback 回归。现有备份机制不能替代这个调用链修复;维护者还需独立确认跨平台与迁移门槛。
我的整体评价
REQUEST_CHANGES。 迁移事务本身及多处路径消费者已有扎实覆盖,但 extension 这个实际入口仍破坏迁移后的默认读写一致性,属于合并阻塞项。相关 refactor 应保持在现有路径选择 owner,不需要新增第二套路由规则;修复后重新核对精确 head。
English verdict: REQUEST_CHANGES - exact head 4e332dd still routes implicit extension state to the legacy runtime root after migration. Eight migration tests and diff check passed, but a synthetic implicit list/readback counterexample remains; unify the default route and add execute/rollback CLI regression coverage.
Signed-off-by: Lihua <1017343802@qq.com>
Signed-off-by: Lihua <1017343802@qq.com>
huangruiteng
left a comment
There was a problem hiding this comment.
动机
复审精确 head 5798e39dabe8f70e496e022b6b161c9e66f0a56b。#4800 的目标是让新安装只使用 .loopx 默认状态路径,同时让既有注册继续沿用声明过的旧路径;只有操作者预览并执行迁移时才移动原始数据。上轮指出的扩展启用状态分叉已修复:普通 extension list 在合成迁移及回滚前后均跟随选中的 runtime。
改动思路
paths.py 统一选择 fresh/current/legacy 路由;migrate-local-state 将 registry 声明、源内容摘要和目标路径绑定为 plan_id,执行前备份并校验,再移动 Goal/runtime、改写 registry,留下可验证的回滚收据。项目 CLI、扩展状态、doctor、生成的 host 命令、DSH GoalBar、安装示例与中英文文档跟随该路由。方向与边界合理,但迁移预检也必须证明目标路径的每一层都仍处于所声明的项目目录内。
具体改动
PR 共改动 114 个文件(+1524/-295):核心是 local_state_migration.py 的预览/执行/回滚、paths.py 的选择器和 registry 路径,余下主要是调用者、示例、文档及聚焦测试。extensions/runtime.py 在本 head 改用共享选择器;新的 CLI 回归覆盖 legacy、fresh、execute、rollback 与双 registry 冲突。
关键代码讲解
select_default_runtime_root只根据 registry 路由选择默认 runtime,不暗中搬迁旧数据。plan_local_state_migration对 Goal 源目录和目标叶子做检查、计算计划摘要,却漏检中间的.loopx/goals目录。migrate_local_state在接受计划后调用new.parent.mkdir和old.rename(new);如果中间目录是符号链接,这两个操作会沿链接把 Goal 目录放到项目外。default_extension_state_file现已复用默认路由选择器,上轮扩展状态遗漏不再是阻断项。
对主干的风险
[P1] 迁移预检未拒绝目标路径中间层的符号链接。 在隔离的合成项目里,使 .loopx/goals 指向项目外的空目录,目标 Goal 叶子仍不存在:预览返回 ok=true,执行返回 migrated,而 ACTIVE_GOAL_STATE.md 实际落在链接目标。这与迁移指南所承诺的 symlink-boundary 校验不符,也可能在成功收据下悄悄改变原始数据的物理位置。请在预览中逐层拒绝符号链接或验证 canonical containment,并在真正 rename 前重验;补一条负例,断言外部目录没有写入。现有备份/回滚能帮助事故恢复,不能替代准入保护。
本轮 145 个迁移、扩展和项目 registry 聚焦测试通过;git diff --check 通过。上述真实文件系统负例仍失败。按 Goal 的 wait_for_ci=false 未轮询远端 CI,也未迁移任何活动 Goal。未来相关重构保持一个 paths.py 路由 owner,并在现有迁移模块补窄边界检查即可,不需另建框架。
语义与 CI 对齐
这是共享本地状态路径契约的有意变更;扩展入口现与选择器对齐,但“预览检查符号链接边界”的当前文档承诺被目标祖先链接反例违反。CI 不是该确定性安全缺口的替代证据。
我的整体评价
REQUEST_CHANGES。 统一默认路径、保留旧注册以及显式可回滚迁移是一块有用且成形的交付;上轮扩展路径问题也已闭合。但此 head 仍允许一个预检通过、执行成功、数据移出项目的场景。修复目标祖先检查并在新 exact head 上跑通负例后再复审;批准代码与实际迁移授权仍是两件事。
English verdict: REQUEST_CHANGES - head 5798e39dabe8f70e496e022b6b161c9e66f0a56b fixes the prior extension-route issue, but a symlinked Goal destination ancestor passes preview and moves state outside the project. 145 focused tests pass; the synthetic filesystem counterexample does not.
Signed-off-by: Lihua <1017343802@qq.com>
huangruiteng
left a comment
There was a problem hiding this comment.
动机
复审 #4915 精确 head bda7a5bfb1ae991b58d42cd96d0c0c05926fa226。#4800 要把新安装的全局与项目 Goal 默认状态收敛到 .loopx,同时保留已注册旧路径;搬动原始数据只能经操作者显式预览、备份、执行和回滚。上轮指出的 extension 默认路由及 Goal 目标祖先符号链接问题,在本 head 的代码和测试中已得到针对性修复。
改动思路
paths.py 统一选择 fresh/legacy/conflict 路由,普通 CLI、extension、项目 prompt、doctor、生成的 host 命令、DSH GoalBar 和打包示例跟随所选路由。migrate-local-state 则以源内容和路径生成 plan_id,先复制并校验私有备份,再移动 Goal/runtime、经严格 codec 改写项目 registry,留下迁移及回滚收据。迁移保持离线、显式;没有对任何活动 Goal 做试迁。
具体改动
整份 PR 相对当前 base 涉及 115 个文件(+1686/-304):核心是迁移与路径选择,其余主要是调用者、双语文档、示例和回归测试。最新四文件增量加入了 Goal 目标路径逐级检查、移动前复验,并让迁移和 project prompt 使用严格项目 registry codec。
关键代码讲解
default_runtime_route选择新旧默认根;双 registry 并存时拒绝隐式选择,不自行搬迁。_require_goal_destination逐层拒绝 Goal 目标祖先链接,预览与真正 rename 前均调用,关闭上轮反例。plan_local_state_migration检查声明、摘要和目标冲突,但在第 223–227 行只检查备份目录叶子,没有检查其父目录。migrate_local_state在第 273–280 行以parents=True建立并复制完整备份;若备份父目录是符号链接,会沿链接写入外部物理目录。
对主干的风险
[P1] 默认备份路径仍可被父级符号链接重定向。 在隔离合成项目中,使 source.parent/loopx-local-state-backups 指向项目外的空目录,预览返回 ok=true,按精确 plan_id 执行返回 migrated,外部目录却出现包含 ACTIVE_GOAL_STATE.md 的完整备份。收据只显示词法路径;成功状态不能证明私有状态留在声明的备份位置。请在预览和复制前检查默认及显式备份路径的祖先/规范化边界,补“外部目录无写入”的负例。修复后仍应保留原始备份与回滚校验,而不是用它们代替准入。
94 个迁移、registry codec/IO census 聚焦测试通过;Ruff、control-plane TypeScript typecheck、git diff --check 通过。风险 canary 的 10 个 catalog 检查与 public-boundary 检查通过,8 个 risk checks 中 3 个 DSH 检查因当前环境无法取得可选平台依赖而失败;另有一个 benchmark-sensitive 人工 hold。不能把这次 canary 记为全绿。未迁移真实用户状态,按本 Goal 的 wait_for_ci=false 未轮询远端 CI。
语义与 CI 对齐
这是共享本地状态与私有备份路径契约的有意变化。严格 codec 和 Goal 目标边界现与文档对齐;备份祖先反例仍违背迁移指南的私有备份/符号链接边界。环境导致的 DSH 校验缺口需在可用依赖环境补跑,不能用其余绿灯抵消确定性的迁移边界缺陷。
我的整体评价
REQUEST_CHANGES。 统一路由与显式可回滚迁移是有用且成形的交付,跨入口的较大改动量有其原因;此前两个阻断项也已闭合。但本 head 仍会在成功收据下把原始状态的备份写到预期位置之外。相关的未来向重构应继续让 paths.py 管默认路由、项目 codec 管序列化,在现有迁移模块中复用一处窄的目标祖先校验,不另建路径权威。修复备份边界并补齐 DSH 环境验证后再按新 exact head 复审;代码批准本身也不等于授权迁移或合并。
English verdict: REQUEST_CHANGES - exact head bda7a5b fixes earlier extension and Goal-target issues, but a symlinked default backup parent still redirects the full private snapshot while preview and execute report success. 94 focused tests pass; three DSH risk checks remain environment-blocked.
Signed-off-by: Lihua <1017343802@qq.com>
Signed-off-by: Lihua <1017343802@qq.com>
Signed-off-by: Lihua <1017343802@qq.com>
huangruiteng
left a comment
There was a problem hiding this comment.
动机
将既有本地默认状态迁入 .loopx,并以显式预览、备份和回滚保护原始数据;这个方向有价值,本轮是对新 head f2d3998 的全 PR 复审。
改动思路
最新提交补上了备份目录祖先 symlink/junction 的检查,之前的备份重定向问题得到覆盖。但项目 registry 的规范路径只检查末端文件是否为 symlink,没有检查其 .loopx 祖先。
具体改动
[P1] 在 loopx/local_state_migration.py:205-213,若某 Goal 使用合法的自定义 state_file,且项目 .loopx 目录是指向项目外目录的符号链接,_state_route 不产生 Goal move,因而不会调用 Goal 目的路径的祖先检查。隔离真实文件系统复现:preview 返回 ok=true、goal_directory_count=0;以该 plan_id 执行后返回 migrated,并改写链接目标中的 registry.json。请在预览和实际项目 registry 写入前拒绝 symlink/junction/reparse-point 祖先,并补一个自定义 state_file 的负例,断言预览/执行均无外部写入。仅检查 registry.json 本身不够。
对主干的风险
此路径会在操作者以为只迁移已声明项目状态时改写项目外 registry,违背迁移数据边界。93 个聚焦测试及独立安装 smoke 通过,但未覆盖这一分支。标准 canary 另有本机 DSH 依赖源不可用及手动 hold,不能据此宣称全绿;这里的阻断结论来自独立可复现的真实文件系统反例,未迁移任何现有 Goal。
我的整体评价
请求修改;保留目前备份祖先修复,补齐项目 registry 祖先边界后,再用同一负例和聚焦迁移/回滚测试复核。相邻边界的前瞻性收敛应复用现有路径验证,而不是增加第二套 registry 决策规则。
English verdict: REQUEST_CHANGES
huangruiteng
left a comment
There was a problem hiding this comment.
动机
复审 #4915 精确 head f2d3998f3e686bdf39c5f4521855b06f7b4dec8f,按 #4800 的目标判断整份变更:新安装应统一使用 .loopx,已注册旧状态保持可用,原始数据只能经明确预览、私有备份、执行和回滚迁移。本轮提交修补了上一轮指出的 backup 祖先链接,但迁移准入仍有一个独立的 project registry 路径缺口。
改动思路
paths.py 统一选择 fresh/current/legacy/conflict 路由;migrate-local-state 用源内容与路径绑定 plan_id,停工后备份、迁移 Goal/runtime、严格改写项目 registry,再留下可回滚收据。project CLI/prompt、extension、doctor、生成的 host 命令、macOS 启动脚本、Codex App scheduler、DSH GoalBar、打包 chat 示例和双语文档跟随被选择或声明的路径。这个完整链路是必要的;任何真实写入路径都必须服从同一祖先边界,不能只验证有 Goal 目录移动的分支。
具体改动
相对本 PR base,115 个文件约 +1835/-304:核心是 local_state_migration.py 与 paths.py,其余主要是上述调用者、文档、fixture 和 526 行聚焦迁移测试。最新增量对默认/显式 backup 的父目录做 symlink/junction 检查,并在复制前复验;这关闭了上轮的备份重定向反例。
关键代码讲解
default_runtime_route(loopx/paths.py)识别新旧单一路由或双 registry 冲突,不在普通读取中搬迁数据。_state_route(loopx/local_state_migration.py:123)对自定义state_file返回“不移动 Goal”;此时后续不会调用 Goal 目标祖先校验。plan_local_state_migration(同文件约 177–255 行)检查项目 registry 叶子本身是否为 symlink,却没有检查.loopx父目录。migrate_local_state(同文件约 283–390 行)依计划备份并改写项目 registry;当父目录是链接时,项目外文件实际被改写。computeGoalBarSourceRevision(packages/dsh-loopx-plugin/src/goalbar/read-model.ts)改为读取 registry 声明的 Goal 状态路径,而非固定旧默认目录。
对主干的风险
[P1] 自定义 Goal 路由绕过 registry 祖先边界。 我在隔离的真实文件系统中构造合法自定义 state_file,将项目 .loopx 指向项目外目录,保持 registry.json 叶子是普通文件。当前 head 预览 ok=true、goal_directory_count=0;以精确 plan_id 执行后返回 migrated,但外部 registry 字节发生变化。原始 runtime 被移动,收据成功,物理路径却违背迁移指南“检查每个 source registry/symlink boundary”的承诺。请在预览和真正写项目 registry 前检查其每层祖先(含 junction/reparse point),补自定义 state_file 的负例,断言预览/执行拒绝且外部目录没有写入。上轮修复的 backup 和 Goal 目的路径检查应保留。
[P1] 当前主干仍无法集成。 git merge-tree --write-tree origin/main HEAD 对 eb16c54 报 loopx/web/chat/asset-retention.json、index.html 内容冲突及打包 JS 的 rename/rename 冲突。请重基并由当前源重新构建 chat bundle,保留主干新资产,再在新精确 head 跑打包/保留清单 smoke;不能只选择一侧生成文件。
本轮源码树的迁移测试 18/18、项目 registry/Windows 安装测试 65 通过且 4 项平台跳过;Ruff 与 diff 检查通过。上述真实文件系统负例失败,merge-tree 失败;未迁移任何活动 Goal,按 Goal 契约未轮询远端 CI。手动 benchmark-sensitive hold 与跨平台复核仍属维护者的独立门槛,不能被本地绿灯替代。
语义与 CI 对齐
#4800 的持久路径契约要求“预览不写、执行不越界、只保留一个权威状态”。新默认和旧注册兼容路径已有测试,但链接祖先反例是当前契约的具体违反;打包资产冲突则意味着当前主干上的最终交付尚不存在。两处均需在新 exact head 重新验证。
我的整体评价
REQUEST_CHANGES。 统一默认路径和显式可回滚迁移是一块有用、比例虽大但由多入口迁移驱动的完整交付;上一轮 backup 修复有效。现有阻断项仍可能让“成功”迁移触碰声明范围外的原始数据,且当前主干合并冲突。相邻的前瞻性收敛应复用现有路径校验/registry codec,而不是新增第二套路由权威;修复两项后重新评审,不执行真实用户状态迁移。
English verdict: REQUEST_CHANGES - exact head f2d3998 still rewrites a project-external registry through a symlinked .loopx ancestor for a custom state_file, and current main has packaged-chat merge conflicts. 18 migration tests and 65 project/Windows tests passed, but the synthetic real-filesystem counterexample and merge-tree failed.
Signed-off-by: Lihua <1017343802@qq.com>
Signed-off-by: Lihua <1017343802@qq.com>
Signed-off-by: Lihua <1017343802@qq.com>
Signed-off-by: Lihua <1017343802@qq.com>
Signed-off-by: Lihua <1017343802@qq.com> (cherry picked from commit f0de8eab81c20c0d6a22675c222f05bebfde649d)
Signed-off-by: Lihua <1017343802@qq.com>
Signed-off-by: Lihua <1017343802@qq.com>
Signed-off-by: Lihua <1017343802@qq.com>
Signed-off-by: Lihua <1017343802@qq.com>
Signed-off-by: Lihua <1017343802@qq.com>
Signed-off-by: Lihua <1017343802@qq.com>
Signed-off-by: Lihua <1017343802@qq.com>
Signed-off-by: Lihua <1017343802@qq.com>
Signed-off-by: Lihua <1017343802@qq.com>
Signed-off-by: Lihua <1017343802@qq.com>
Signed-off-by: Lihua <1017343802@qq.com>
Signed-off-by: Lihua <1017343802@qq.com>
Signed-off-by: Lihua <1017343802@qq.com>
Signed-off-by: Lihua <1017343802@qq.com>
Signed-off-by: Lihua <1017343802@qq.com>
Signed-off-by: Lihua <1017343802@qq.com>
huangruiteng
left a comment
There was a problem hiding this comment.
Whole-PR re-review of exact head e78dc08a87be222caca852dfa7927963209e401f against ee9dad81b14c6d15d32b95851b5d38fcc485e732. No validated PR-introduced blocking finding. Review approval is separate from merge readiness: the installer and DSH qualification below are not green. No merge performed.
动机
我以 #4800 已接受的宿主无关状态目录诉求为目标,重新审查完整 diff,没有沿用旧 approval。旧路径把通用 LoopX 状态绑定到 Codex 名称;直接改常量又会让已有注册目标、定制目录和宿主读模型断开。这个版本交付的是新默认目录、旧安装连续性以及显式可回滚迁移这一完整切片,不代表已经迁移任何用户机器,也不代表在线迁移或发布升级验收完成。
改动思路
权威仍是项目注册表及其声明的 goal/runtime 路由,而不是扫描到哪个同名目录就选择哪个。共享路径 owner 负责新旧默认路由判断;离线迁移复用既有注册表 codec 和事务写入,备份、计划指纹和回读服务于一次明确操作。最小常量替换不足以保住旧目录和 custom route;反过来,也没有必要新造 Todo、quota 或宿主权限 owner。停止全部 writer 是这项离线工具的明确前提,不是通过 receipt 自动保证在线排他。
具体改动
全量变化为 138 个文件、+3192/-342,其中生产及配置 44 个、+1293/-133,测试 42 个、+1644/-97,文档 52 个、+255/-112。许多改动是替换默认路径,但我另外追踪了 installer、scheduler、archive、rollout、SSH 生命周期与 DSH 消费者,未把它们当作纯文案。
关键代码讲解
default_runtime_route在 fresh、已有 legacy、双根冲突和无效路径之间明确分支;诊断前不创建另一套状态。注册目标的 declared route 和 custom 路径继续优先,不能靠默认目录猜测权威。migrate_local_state校验 preview 的内容指纹和路径祖先,再备份、移动注册的 legacy 默认目录并回读;未注册和自定义目录不搬。回滚遇到被修改的目标会拒绝覆盖,恢复目标后才可重新完成回滚。HOST_GLOBAL_REGISTRY_SELECTOR明确区分远端宿主全局注册表与 cwd 项目注册表。真实 CLI 合成双注册表实验中,当前 base/head 都只停止指定全局目标;旧缺陷版本丢失 selector 后被 stale guard 拒绝,任务无法推进。当前修复没有解除这个安全 guard。decodeGoalBarProjectRegistry保留 Python strict-v1 wire 的哈希、数值和 Unicode 规范,供 GoalBar 按声明的状态路径回读。这是持久化格式适配,不是第二套业务规则;直接替换成另一种 JSON canonicalizer 会破坏已有字节契约。
对主干的风险
最强反例是“计划过期或路径跳转后仍搬目录,回滚又覆盖后来写入”。独立合成 HOME、双注册表和真实文件系统实验验证了 preview 无写入、过期计划和逃逸无效果、只移动注册默认目录、自定义及未注册状态保留、修改后回滚拒绝、重新恢复条件后原字节回读。启用 usage consent 的迁移测试也验证 observer 不参与 preview/execute/rollback。没有触碰活动用户 Goal。真实 Windows junction/reparse 和完整跨平台安装仍需对应环境验收;本机相关平台测试明确跳过。
验证:迁移/usage/scheduler/SSH/rollout/archive 等定向 pytest 192 passed、3 平台 skip;注册表 codec、quota settlement、refresh、扩展、session lifetime、Windows installer 等补充测试 146 passed、4 平台 skip;architecture 820 passed;control-plane TypeScript 与定向 Ruff 通过。原风险 canary 执行 19 项,15 passed、4 failed,五项直接检查无失败,public/private boundary 检查通过,未运行 benchmark 作业。
语义与 CI 对齐
没有查询或等待远端 CI,也没有提高预算或取消检查。安装 smoke 在相同 120 秒预算下,immutable base/head 都以 timed_out 结束且无输出;不能把它写成成功。DSH 的 quality/package/runtime 阶段被未改动 lockfile 的缺失可选原生依赖阻断。使用同一可用依赖缓存补充复跑,base/head 的八条类型诊断相同,完整 Vitest 的八个失败名称及错误内容也逐一相同:base 179/187 passed,head 183/191 passed;失败集中于未改动 Session API,新增 GoalBar 读模型测试通过。这些属于独立复现的既有/环境问题,支持 APPROVE 而非对本 PR REQUEST_CHANGES,但完整安装及 DSH 合并就绪证据仍有缺口,需由对应检查/依赖 owner 恢复后再资格化。复用 strict registry、默认路由及 rollback 契约;新 .loopx 默认行为已在迁移文档明确披露,不冒充默认关闭的可选功能。
我的整体评价
long_horizon 改善在于旧状态可连续回读、错误路由安全拒绝并能按明确条件恢复;user_experience 改善在于新默认宿主中立且迁移结果可回读。一次停 writer 的成本有明确范围和恢复步骤,不能扩展成长期人工维护要求。未来面对的整理已在本 PR 采用共享路径 owner、runtime bounded context 和单一 wire codec;没有理由为了减少行数破坏格式兼容或扩大 TS 迁移。全量切片与问题相称,旧 finding 修复和当前整体价值分别得到验证。未发现需要修改当前 head 的阻断缺陷;上述红检查、平台残余风险和 maintainer 合并责任保留,不宣布 canary 全绿或自合并。
English verdict: APPROVE - e78dc08. The complete host-neutral routing and offline recovery slice is justified. Independently reproduced baseline/environment failures remain explicit merge-readiness holds, not PR-introduced blockers.
|
Frame alignment for exact head |
huangruiteng
left a comment
There was a problem hiding this comment.
Whole-PR re-review of exact head 639633173a52e128a496ceb48e8ca3c5d5f0f1e5 against ee9dad81b14c6d15d32b95851b5d38fcc485e732. This supersedes my review on e78dc08a87be222caca852dfa7927963209e401f, which was dismissed after the author pushed the migration refactor. No validated PR-introduced blocking finding. APPROVE is not a merge-readiness pass; the failing qualification checks below remain visible. No merge performed.
动机
以 #4800 已接受的宿主无关状态目录诉求为目标,审查完整 diff,而非继承旧 approval。直接替换默认常量会断开已有注册目标、自定义目录和宿主读模型。本 PR 的可独立交付边界是新默认、旧安装连续性及显式可回滚迁移;不代表已经升级任何用户机器或完成在线迁移验收。
改动思路
项目注册表及其声明的 goal/runtime 路由仍是权威。共享路径 owner 判断新旧默认;离线迁移复用既有 registry codec 和事务写入。备份、计划指纹和回读服务于一次明确操作,不新增 Todo、quota 或生命周期权限 owner。停止全部 writer 是离线工具的前提,不是 receipt 自动保证的在线排他。
新 head 把操作内已完成效果收束进 _MigrationWrites,提取备份、验证、恢复三个同边界 helper。我逐分支对照旧 head 的写入顺序、记录时机和回滚条件;这是行为保持的有界整理,没有增加持久化状态、手工同步事实或第二套业务规则。
具体改动
全量 139 文件 +3289/-342:生产及配置 44 个 +1319/-133,测试 43 个 +1715/-97,文档 52 个 +255/-112。默认路径替换虽占多数,installer、scheduler、archive、rollout、SSH 生命周期及 DSH 消费者仍按实际调用链检查。
关键代码讲解
default_runtime_route明确区分 fresh、legacy、双根冲突及无效路径,诊断前不创建另一套状态;declared/custom 路由继续优先。migrate_local_state用精确 preview 指纹、祖先检查和备份后回读,只搬注册的 legacy 默认目录。_MigrationWrites只在完成效果后记录;恢复仍拒绝覆盖后来的 registry 写入。rollback_local_state_migration检查目标及备份完整性再恢复,不能绕过漂移拒绝。HOST_GLOBAL_REGISTRY_SELECTOR区分远端全局注册表与 cwd 项目注册表。此前真实 CLI 双注册表实验中,base/旧已审 head 都只停止指定全局目标;更早缺陷版本省略 selector 后被 stale guard 拒绝,不能推进。本次增量未改该路径,安全 guard 未放松。decodeGoalBarProjectRegistry保持 Python strict-v1 的哈希、数值及 Unicode 字节契约,供实际 declared state reader 回读。它是持久化格式适配,不是第二套业务规则。
对主干的风险
重点反例是过期计划或路径跳转后仍搬目录,或回滚覆盖迁移后的新写入。新 head 重新执行独立真实 CLI/文件系统的八项观察:preview 无写入、过期计划与逃逸无效果、注册默认目录搬迁、自定义及未注册状态保留、修改后回滚拒绝、恢复条件后原字节回读。新增 File/SQLite 测试通过真实 canonical Todo owner 验证迁移前后 revision 连续、继续写入成功,以及旧 rollback 不覆盖新 revision。未用活动用户状态做实验。
新 head:迁移及 native File/SQLite pytest 36 passed、3 Windows skip;architecture 820 passed;定向 Ruff 通过;完整 DSH Vitest head 183/191 passed,base 179/187 passed。此前 e78dc08a 的定向 Python 192 passed/3 skip、补充 146 passed/4 skip、control-plane TypeScript 及真实 SSH 实验保留原执行版本;三文件增量没有修改这些生产调用链、依赖或测试,我没有把旧 receipt 重标成新 head 的执行。
重新运行原风险 canary:19 项中 14 passed、5 failed,五项直接检查及 public/private boundary 通过;benchmark-sensitive 手工 hold 保留。没有运行 benchmark 作业。
语义与 CI 对齐
没有查询/等待远端 CI,没有提高预算或删除失败检查。五项失败分别处理:
install-local-smoke.py在相同 120 秒预算下,immutable base/旧已审 head 都 timeout 且无输出,新 head 原 canary 仍 timeout,不能写成成功。codex-cli-packaged-install-smoke.py新 head canary/native runner 在断言完成后的TemporaryDirectory清理报OSError[Errno 66]: Directory not empty。base 直接运行同一脚本也报相同清理错误;head 直接运行和 base native runner 又能通过。外层执行方式分别记录,未把不同 wrapper 冒充完全同一运行。脚本及清理路径未被 PR 修改,错误类别和失败位置相同,是已有的间歇性清理问题;原红结果不抹除,完整安装资格仍待恢复。- DSH quality/package/runtime 三阶段在执行前被缺失可选平台原生包阻断;manifest/lock 未变,base/head 冻结依赖准备均可独立复现。不是本 PR 的 codec assertion 失败。
- 同一可用依赖缓存下,base/head 八条完整类型诊断相同。八个 Vitest 失败名称及完整错误内容也相同,仅归一化隔离 checkout 根和机械移动的测试栈位置,签名
2bf737ea6a55844df2ccb407599dfc9120e1dcc3c09a2d78c70941f26c93cf6a。失败属于未改动 Session API/派生 fault,新增 reader 测试通过。
这些既有/环境失败支持 APPROVE,不构成本 PR 的 REQUEST_CHANGES 理由;安装及 DSH 完整合并就绪证据缺口仍由对应检查/依赖 owner 恢复。真实 Windows junction/reparse 及跨平台安装未在本机验证。新 .loopx 默认是明确披露的默认行为变更,自动迁移仍关闭;legacy/custom 路径不要求先迁移才可继续。
我的整体评价
long_horizon 改善是持久化 ownership 能连续回读,错误路由安全拒绝后有实际恢复路径;user_experience 改善是宿主中立的新默认和可理解、可回读的迁移结果。一次停止 writer 的成本不能扩展成长期手工维护。未来面对的有界整理本次已应用在 migration 的单一效果记录及备份/验证/恢复职责,真实 File/SQLite 与恢复反例支持其行为保持;没有理由借此新造通用框架或扩大语言迁移。
完整切片与原问题相称;没有验证出需修改当前 head 的阻断缺陷。保留失败、平台缺口和 maintainer 合并责任,不宣布 canary 全绿、在线安全或自合并。
English verdict: APPROVE - 6396331. The complete host-neutral routing and offline recovery slice is justified, including the bounded behavior-preserving migration refactor. Independently reproduced baseline/environment failures remain explicit qualification holds, not PR-introduced blockers.
|
Frame alignment for exact head |
huangruiteng
left a comment
There was a problem hiding this comment.
Robustness audit of #4915 at exact head 639633173a52e128a496ceb48e8ca3c5d5f0f1e5, compared with ee9dad81b14c6d15d32b95851b5d38fcc485e732. Two newly reproduced blockers invalidate the earlier approval for this head. All experiments used disposable synthetic state; no live state was migrated.
动机
按 #4800 的原始验收,宿主中立的新默认必须同时保留旧安装连续性,并提供实际可恢复的显式迁移。这里需要区分两个流程:安装器既有的 authority-archive upgrade --all-known --execute 升级 File/SQLite 物理格式;本 PR 的 migrate-local-state 显式搬迁目录。普通升级没有调用后者。因此,不应该把“不会自动搬旧目录”理解成“普通升级不会改变旧状态的读取结果”,也不能把格式升级已有的崩溃恢复能力算给目录迁移。
改动思路
共享 paths owner 选择新旧 runtime,项目 registry 的 declared state_file 保持权威;CLI、SSH、scheduler、doctor、extension、machine settings、backup/archive 和 DSH GoalBar 跟随该路由。迁移通过内容绑定 plan_id、私有快照和回读保护一次显式离线操作,要求操作者先停 writer。这个边界总体合理:仅改默认常量会破坏旧路径,另建永久双写 authority 又没有必要。但机器状态不依赖全局 Goal registry 才能存在;恢复也不能只验证开始前的状态而忽略操作已经完成了一半的情况。
具体改动
全量 diff 是 139 文件、+3289/-342。生产及配置涉及默认路径 owner、注册/bootstrap 与生成命令、CLI 迁移、SSH host-global selector、扩展和机器设置、scheduler/rollout/backup/archive,以及 DSH strict registry codec 和 declared-state reader。文档、book、公开示例和 fixture 更新新默认并保留显式 legacy 场景;Windows CI 增加三个 junction 检查。本次核对了这些调用关系和说明,没有将机械路径替换视为独立资格证明。
关键代码讲解
default_runtime_route只用两个registry.global.json的存在性分类安装状态。default_extension_state_file、machine_runtime_root、usage state 与 archive discovery 都消费这个选择。migrate_local_state先复制并逐项验证整个 legacy runtime、项目 registry 和登记的 Goal 目录,再依次 rename 和改 registry。普通异常走_restore_migration_routes;完成效果记录只在内存中,成功 receipt 到最后才落盘。rollback_local_state_migration在开始前验证 backup/target digest,随后先搬 runtime、再搬 Goal、最后恢复 registry。它没有与正向迁移对称的异常补偿,也没有已开始 rollback 的恢复分支。- DSH
decodeGoalBarProjectRegistry/registeredActiveStatePath保留 strict wire 验证并改用声明路径;SSH@host-global在远端解析全局路由,避免 cwd registry 抢占。两者是旧安装连续性的必要 companion,不需要新增设置 UI 或并行的业务规则 owner。
对主干的风险
[P1] 没有全局 registry 的旧机器状态被静默遗忘
位置:loopx/paths.py:79-98,尤其是 fresh 分支。合法触发条件是用户先安装/配置扩展,还没有 connect Goal,因此有 legacy extensions/state.json 而没有 registry.global.json。同一份合成 HOME、同一条真实 extension list CLI,base 返回 ok=true 且包含已启用的 example,head 返回 ok=true 和空数组;原文件字节未变,也没有任何 migration 执行。当前测试中的 legacy extension fixture 预先创建了 global registry,所以漏掉这个分支。
这直接违反旧状态在显式迁移前保持可用的验收,也会影响复用同一 selector 的机器配置读取。扩展消失已经独立复现;没有将尚未独立执行的凭据/usage 场景说成已发生数据丢失。
最小修复:让共享 route owner 区分真正全新安装与“已有明确的 legacy 机器状态、但无 Goal registry”;保持单一权威,遇到不明确状态应给出可恢复诊断,不能静默返回新空状态。增加无 global registry 的 base/head extension 与机器设置回归,并验证首次注册不会制造第二套状态。不应要求用户伪造 registry 或每次传 override 才能继续使用旧安装。
[P1] 回滚中途 I/O 失败留下断开的路由,正常重试无法继续
位置:loopx/control_plane/runtime/local_state_migration.py:560-578。在两个项目迁移成功后,经真实 CLI 执行 rollback,只对第一个 Goal 的回迁 rename 注入一次 OSError(5),其余复制、hash、registry 和文件系统操作均真实执行。观察到:runtime 已搬回 legacy,目标 runtime 不存在,global/project registry 仍声明新 runtime,receipt 仍是 migrated。撤掉故障再执行原 rollback 命令,仍 exit 1,报 legacy path has reappeared。这个“重新出现”的目录恰好是前一次 rollback 自己搬回来的。
备份完整保留,没有观察到原始数据丢失;但用户已经从正常迁移状态进入 registry 与目录不一致的状态,公开命令拒绝恢复。最小修复:为回滚提供受 digest/ownership 保护的补偿或可恢复执行状态,识别本操作已经完成的步骤,同时继续拒绝真正的外部新写入。覆盖 runtime rename 之后、各 Goal rename 之后以及 registry 恢复失败的故障点;修复后应能再次执行到一致旧状态,或自动保持一致迁移后状态,不能仅断言报错和 backup 存在。
另一个已执行的恢复边界探针:正向迁移第一次 Goal rename 后直接退出进程(os._exit(137),绕过 Python cleanup)。快照及 plan 存在且 digest 正确,但无成功 receipt;再次 preview 报旧 state missing,rollback 报 receipt missing。这不证明备份丢失,也不是在线并发测试。它说明硬中断只能进入人工恢复,而当前指南没有完整的部分迁移恢复步骤;应补可验证的恢复入口或具体 runbook,不应宣传无人值守升级级别的恢复能力。
语义与 CI 对齐
本次在 exact head 独立执行:迁移和 native File/SQLite 连续性 36 passed / 3 Windows-only skipped;scheduler、SSH evidence/tunnel、rollout、usage、authority archive、project registry/codec 172 passed;既有格式升级与 File journal 12 passed,包括升级发布前后中断恢复、竞争升级进程和损坏 backup 拒绝。git diff --check 通过。上面两个 blocker 和硬退出边界另经隔离 CLI 探针确认。
当前 packet 观察到 37 个成功的远端检查,不能替代这三个反例。本机没有执行原生 Windows junction 测试;DSH focused test 尝试因该 checkout 缺失 Vitest 模块而未运行,不记为通过,也不把它当作 PR regression。首次 Node 测试启动误用了未安装的 tsx loader,改用项目支持的 Node 原生 TypeScript 入口后上述 12 项通过。独立 CLI 探针的启动器修正后重跑,最终结果验证了实际诊断,不以启动失败作为产品故障证据。本轮没有重新执行完整 installer、DSH packaging 或全部 canary,保留这些资格边界。
typed-state / authority 检查:新 schema 描述的是离线目录迁移,没有扩张成在线 fencing 或 actor 生命周期权限;plan_id 和目标冲突是机器强制条件,停 writer 是操作者前提。默认 .loopx 已在指南披露,但无 registry 的旧状态丢失没有披露。分类错误来自 fresh 的不完整事实输入,不是 substring denylist。错误与恢复合同仍应保持领域中立。
我的整体评价
REQUEST_CHANGES。新默认和多数旧 Goal 路由的设计有价值,正常迁移、backup 校验、拒绝覆盖后续写入也有实证,但 long_horizon 会受扩展被遗忘影响,user_experience 会被不可重试的半回滚打断,当前不能宣布旧安装连续性与恢复验收完成。未来维护性应在现有共享路径 owner 和 migration 恢复边界内收敛,不另造一套同步 registry,也不扩展成无关的全量 TS 重写。修复上述两个复现,并补部分执行的恢复证据后再资格化 exact head;保留停止 writer 和后续写入拒绝覆盖的安全条件。本轮不合并、不部署,也不继承之前的 APPROVE。
English verdict: REQUEST_CHANGES - 6396331. A real CLI base/head probe loses legacy extension discovery without a global registry; an injected rollback I/O failure leaves dangling routes and rejects retry. Backups remain intact, but interrupted migration also lacks receipt-based recovery. Focused Python checks: 208 passed, 3 platform skips; existing format-upgrade/journal checks: 12 passed. No live state was migrated.
…rations Signed-off-by: Lihua <1017343802@qq.com>
Signed-off-by: Lihua <1017343802@qq.com>
Signed-off-by: Lihua <1017343802@qq.com>
Signed-off-by: Lihua <1017343802@qq.com>
Signed-off-by: Lihua <1017343802@qq.com>
Signed-off-by: Lihua <1017343802@qq.com>
Signed-off-by: Lihua <1017343802@qq.com>
huangruiteng
left a comment
There was a problem hiding this comment.
精确 head:1bd8bfa8b5690f02aea752129ac4adc5866109e4;不可变比较基线:6643f367064b9921c864db75a042979fddc4b8c3。本轮亲自复核整个差异并运行独立验证,未继承作者或旧 review 的结论,未查询 GitHub CI。
动机
Issue #4800 的目标是 fresh install 使用 ~/.loopx 与项目 .loopx/goals,legacy 路径在显式迁移前继续有效;doctor/生成提示/读回必须统一,不能静默产生第二套 authority。当前 head 修复旧无-global-registry 的 machine route、部分 rollback 重试、UTF-8/LF 指纹及 HOME-project metadata 分类,价值确实存在,但整条恢复/显式接入路径仍有下面的回归。
改动思路
paths.py 集中选择 fresh/legacy/custom route;physical migration 归在 existing runtime owner,用 preview plan、执行前 fingerprint、离线停写、snapshot 与 typed recovery status 搬移实际文件,不新增 Todo/quota 决策源。已有 registry codec/fences 保留,SSH 使用远端 @host-global,DSH GoalBar 依据登记的 state_file 而非同时读取新旧目录。
具体改动
- 路径 helper 及 bootstrap、project prompt/map/alias、CLI 默认、global sync、backup/uninstall、doctor、usage、extension、scheduler/rollout/install 等调用者一并迁移,custom/registered state 应继续优先。
local_state_migration.py提供migrate-local-state的预览、显式执行与 receipt rollback:源/目标/backup/registry 重定向检查、复制前后 digest、实际 rename、hard-interruption receipt 与后续写入保护。只支持声明的离线维护边界,不声称提供在线原子切换。- DSH 新 readonly strict wire decoder 与 source-revision 读取路径处理 Python 的 envelope、浮点/大整数/Unicode、重复 key、digest 和 lifecycle-only profile;新增 service/read-model fixtures、native File/SQLite 及 recovery 测试。CI OS 覆盖、公共文档/示例/已装载提示同步 fresh 默认,并保留显式迁移说明。
对主干的风险
[P1] 显式路径仍被隐式默认目录冲突拦截。 在合成 HOME 中让 ~/.codex/loopx 和 ~/.loopx 都有 machine state,再调用真实 project register,显式传入新的 project registry 和独立 runtime。主干 exit 0,head exit 1、changed=false,错误却要求再次提供 --registry/--runtime-root。四种相同输入布局中 base 全通过,head 仅双默认布局失败;两个默认目录的文件字节保持不变,失败只产生 lock 文件,没有写入新 Goal/registry。
因果链是 register_project_goal → legacy_todo_write_transaction → require_registry_source_write_allowed → resolve_runtime_root({}, None) → select_default_runtime_root。新 registry 尚不存在,后一个 guard 丢掉了已解析的 explicit effective root。阻断位置是新增的 paths.py:230 fallback;这是 PR 引入的独立工作被误阻断,不是 CI 红灯或测试环境差异。最小修复:新/未注册 source 使用明确的 effective root,同时保留已登记 canonical source 身份及跨 Goal writer fence;不能用 broad catch 或一律 override 掩盖 authority 检查。增加真实 CLI 双默认目录显式接入的回归,并保留隐式冲突和 canonical source 的负例。
本地验证:253 项 focused Python tests 通过、3 项 native Windows junction 用例在 macOS 明确跳过;820 项 architecture tests、control-plane typecheck、70 个变更 Python 文件编译、139 文件 public-boundary scan 和 maintainability ratchet 通过。真实 File-v0/SQLite-v0 migration/restart tests 及 hard exit/rollback 用例包含在 focused suite 中,不用 mock 替代 backend。
另一个独立 Node source-entry harness 对 GoalBar 的真实文件系统验证 strict registry、declared state/decoy、digest tampering、duplicate keys 和 lifecycle-only 拒绝,6 项均通过;同一基线 harness 对三个 strict 拒绝项失败,验证有检测力。完整 DSH Vitest/typecheck 的依赖准备仍未完成:外部 native package 取不到,随后的隔离安装又触发本地 ENOSPC;已停止并清理本轮临时缓存。这些是环境证据缺口,不额外虚构代码缺陷,也不把 source-entry 验证称为完整 packaged DSH 资格。没有迁移真实 Goal、读取凭据、运行付费模型或改动生产。
我的整体评价
REQUEST_CHANGES。原始整合方向、单路 authority 与离线恢复机制是合理的;但已明确提供修复路径的用户仍不能接入独立工作,长程推进与错误可操作性均回归。当前整体不应批准,不能用已有 253 项测试通过替代这个真实入口负例。
未来向前的 bounded refine 应放在 runtime/source-route 与既有 writer fence 的交界,复用单一 route 解析并补上述真实入口覆盖;无需为物理文件迁移发起全量 TS 改写,也不应另建通用迁移框架。历史 v1 receipt/CRLF 兼容有真实持久化恢复义务,应保留到声明的迁移窗口结束;新操作的 byte fingerprints 不应放宽。修复后重做整条显式路径及相关负例,Windows/完整 DSH 验证缺口继续单独记录。本轮不合并、不升级。
English verdict: REQUEST_CHANGES - 1bd8bfa; real project registration ignores the explicit route inside its source-authority fallback when both default runtimes exist. Immutable base succeeds; head rejects with the already-supplied-flags remedy. Focused/architecture/native filesystem checks passed, while Windows and full DSH validation remain explicitly limited.
| value = registry.get("common_runtime_root") if isinstance(registry, dict) else None | ||
| if not value: | ||
| return DEFAULT_RUNTIME_ROOT | ||
| return select_default_runtime_root() |
There was a problem hiding this comment.
[P1] Explicit registration still resolves unrelated conflicting default runtimes
When both default machine runtimes have state, register a new project with BOTH an explicit --registry and --runtime-root. The unchanged immutable base succeeds; this head exits 1 with changed=false and asks for the very two flags already supplied. Existing canonical state is preserved, but independent new work cannot proceed.
register_project_goal already computes effective_root correctly, then legacy_todo_write_transaction calls require_registry_source_write_allowed. That unchanged source-authority guard re-reads the not-yet-created registry as {} and calls resolve_runtime_root(registry, None). The new fallback at paths.py:230 enters select_default_runtime_root and rejects the unrelated default conflict. Thus the real CLI path is not covered by helper/extension explicit-override tests.
Please preserve the explicit effective root for a new/unregistered source while retaining registered canonical-source and cross-goal writer fences; do not catch the conflict broadly or let a runtime override change an existing source's identity. Add a real project register subprocess regression with both defaults populated and explicit paths, and retain negative tests for implicit ambiguity, wrong canonical source, and later conflicting writes.
Fixes #4800.
Fresh installs use
.loopx; existing registered/custom routes and registryless machine settings remain readable until explicit offline migration. Migration records a verified private backup and recovery receipt before its first move. Interrupted migration/rollback resumes through the existing--rollback-receiptcommand and refuses later writes, changed backups or competing routes.Current head:
1bd8bfa8b5690f02aea752129ac4adc5866109e4. This adds two fixes to the previous recovery stage: global registry/receipt bytes are explicitly UTF-8/LF on every host, with the expected global digest recorded before effects; HOME project metadata, codec-validated declared Goal directories and canonical registry lock artifacts do not claim a second machine runtime. Earlier v1 Windows CRLF receipts remain explicitly supported; new operations still reject an unrecorded newline rewrite. The generic registry decoder retains source-session runtime denial. Latest main6643f367064b9921c864db75a042979fddc4b8c3is integrated without rewriting prior commits.Validation and current holds:
1ea60ca84CI completed with Linux shard 2 and Windows failures; pytest/merge-gate were downstream summaries. The actual SSH co-location and newline failures were reproduced before these fixes. Those results are retained and not relabeled.a42ae338e, full architecture: 832 passed, 2 failures caused by a derived census entry after main integration. Current1bd8bfa8bupdates that one derived line; all 9 affected census/binding-inventory checks passed. Census: 255 sites, zero unclassified. No budget or test gate was raised or removed. Focused Ruff and whitespace checks passed.a42ae338ecanary executed 19 automatic checks: 15 passed, 4 failed. Installer hit its unchanged 120-second timeout; three DSH phases were blocked by pnpm attempting to purge the shared dependency cache without a TTY. No purge was approved or performed. Five direct checks and public/private boundary passed; the benchmark-sensitive maintainer hold remains. This canary is not green.Migration and recovery guide.
No live user state was migrated, no benchmark jobs were launched, and no deployment or merge was performed. Stop all writers for explicit offline execution/recovery. Existing machine settings consume the shared selector and DSH GoalBar reads declared Goal paths; this patch needs no new settings UI or second authority owner. The bounded future-facing pass reuses the registry codec and one byte producer, and removes machine/project ownership ambiguity rather than adding a migration framework.