人工智能AI 应用交互助手AI Agent【免费下载链接】ironclawIronClaw is an Agent OS focused on privacy, security and extensibility项目地址https://gitcode.com/gh_mirrors/iro/ironclaw点击查看免费下载导读IronClaw 是一个以隐私、安全和可扩展性为核心的 Agent OS其代码库经过数月演进后crates/下堆积了六十多个扁平 crate真实架构被目录结构掩盖。本文基于仓库中docs/internal/reborn/target-architecture/PLAN.md这份执行计划完整拆解 IronClaw Reborn 目标架构重构的何时做、怎么做Wave 0–6 的分波节奏、六条操作原则、四条承重排序约束、决策门decision gate、异常计数棘轮以及配套的机械守门人architecture tests 与 CI 脚本。读完本文你将理解如何把一个已经有机械强制依赖规则、但规则不可见的大型 Rust workspace在不做大爆炸重写的前提下安全地重组成目录即架构、异常可清零的形态并把这套方法论复用到你自己的仓库。1. 文档定位执行计划在 Reborn 重构文档族中的角色PLAN.md 自己给出了精确的自我定位这是推荐的开始并持续推进重构的方式——分波waves、守门人gates、PR 尺寸规则和决策点。它编排了 CHECKLIST.mdWS0–WS12中定义的工作流checklist 是做什么这里是何时与如何做。因此 Reborn 目标架构文档族是一个四件套各有分工文档角色位置README.md执行摘要与家族地图十大家族、稳态 64 包docs/internal/reborn/target-architecture/README.mdPROPOSAL.md完整证据支撑的规格说明书决策记录冻结不改docs/internal/reborn/target-architecture/PROPOSAL.mdCHECKLIST.md完成定义definition of done逐项勾选docs/internal/reborn/target-architecture/CHECKLIST.mdPLAN.md执行计划分波、排序、门禁、PR 尺寸本文主体docs/internal/reborn/target-architecture/PLAN.mdfamilies/每个家族一份深度规格面向未来不含迁移讨论docs/internal/reborn/target-architecture/families/执行计划反复强调这里没有什么是神圣的除了四条标 ⚠ 的承重排序约束。 同时它是一份活文档——从 2026-07-29 立项到 2026-08-06计划经历了多次落地标记✎ landed marker修正每次修正都带着测量数据而不是口头声明。这是理解整份计划的关键每一个数字都要在自己的基线上重新测量绝不继承前任的计数。2. 前置背景七层阶梯、十大家族与异常注册表要理解分波计划必须先理解它操作的对象。PROPOSAL 定义了核心模型详见 README.md 家族地图七层依赖阶梯contracts → substrates → runtimes → kernel → loops → products → app。每个 crate 在Cargo.toml的[package.metadata.ironclaw] layer声明自己的层级只允许依赖不高于自己的 crate。十个家族目录contracts/ substrates/ events/ domains/ kernel/ lanes/ loop/ extensions/ product/ app/。家族是发现性分组不是新的信任边界——目录 ≠ 边界层级矩阵才是 CI 检查的依赖真相。异常注册表LAYER_MATRIX_EXCEPTIONS是仓库自己机器追踪的债务清单初始20 条每条带removes_in目标里程碑。重构的终局是零异常且不新增任何一条。这条阶梯的机械强制在源码中可查reborn_workspace_crates_declare_layers_and_follow_layer_matrix与IRONCLAW_CRATE_LAYERS常量都位于 crates/app/ironclaw_architecture_tests/tests/reborn_dependency_boundaries.rs其中还有一条特殊规则ironclaw_agent_loop只能持有 contracts 层的普通依赖contracts-only规则这是全 workspace 最严格的一条依赖规则。重构完成后这条测试所在的 enforcement 套件自己也完成了重命名与搬家ironclaw_architecture_tests→ 目标树中的app/家族。异常棘轮CHECKLIST §11.2.2是整套计划的安全网LAYER_MATRIX_EXCEPTIONS.len() 基线只允许缩小、禁止增长。值得注意的教训来自 Wave 3 的修正棘轮是上限机制它不强制归零——→ 0 是 WS12 的完成门禁不是任何一波棘轮能保证的性质。这提醒读者不要把有棘轮误读为有进度保证。3. 六条操作原则来自七月列车事故的教训PLAN.md 开篇列出了六条操作原则这是整个分波执行的方法论底座Owner-by-owner拒绝 big-bang。成功的抽取#6529…#6669都是每个 PR 移动一个连贯的 owner四个 god crate 的收窄是许多个 PR不是一个。Move-only PR 无行为变更且如此声明。git mv 路径更新 指引更新diff 里没有其他东西拆分和语义变更绝不与移动共用一个 PR。测试与指引随变更同行。每个 PR 在同一 diff 里更新它失效的 crate 指南、家族 AGENTS.md 与边界规则——审计最清晰的一条教训指引漂移是让 Agent 困惑的根源。删除采用揭开面纱un-masking纪律被触碰的每个 crate 都要跑完整无过滤的测试套件浮出水面的失败是候选的应保留行为而不是要修改的测试。每个 PR 之后main保持可发布。没有一波会留下半翻转的依赖边每个 PR 结束时架构套件全绿异常计数单调不增。决策门便宜到可以随时开昂贵到不能跳过。[decision]项Strategy 确认、triggers/hooks SQL、trust 的签名注册表路径、skills 复活、identity 绑定存储、tools 默认成员必须在对应 wave 开始前拍板——多数只是各一条 Slack 线程。这六条原则直接决定了 Wave 的切分粒度移动是廉价的单位拆分才是昂贵的单位。整个计划约 45 个映射是纯移动/改名只有六个 crate 需要真正的拆分且每个拆分都落在两侧已有测试套件的接缝上。4. Wave 0——现在就开始无设计风险立竿见影Wave 0 的所有内容今天都可以独立落地并且为后续每一波缩小问题域WS0 去通配符化host_api的 prelude⚠ 承重约束——大多数后续行依赖的唯一前置条件。行为无关、机械操作、diff 大但极易审查。落地证据crates/ironclaw_host_api/src/lib.rs的 45 行pub use mod::*;被替换为模块限定导出CHECKLIST 记录rg -c pub use .*::\*→ 0。WS8 安全删除第一轮——零消费者、爆炸半径最小的项dispatcher、embeddings、llm::reasoning、common::trust_boundary、events的 jsonl 辅助函数、outbound/approvals的死 trait、event_projections的三个死子系统这一项单独就把它的依赖集缩小到 eventshost_api、未使用的依赖边、根fuzz/、auth::loopback_oauth、gatingauth::fakes。每项都遵循 un-masking 纪律。WS11 会误导当前 Agent 的漂移热修——对七个不存在 crate 的引用、build_reborn_services、NetworkPolicyDecider、composition 指南里幽灵的src/webui/章节、过时的 feature-gating 声明。这些不等重构它们现在就错。WS0 基线 WS10 §11.2.2 异常棘轮初始武装在 20只许下降 §11.2.7 include-scan 的 warn 模式在 WS2 之前它必然失败——这正是目的让债务可见。决策轮 #1[decision]确认 Strategy B tools 默认成员一条线程改名范围已全部拍板2026-07-29 owner review 2026-07-30 命名审计无条件在各 wave 中执行。退出标准异常计数仍为 20 但已棘轮化死面第一轮已消失prelude 去通配符完成团队签收记录在案。5. Wave 1——ContractsWS1杠杆波创建三个 contracts crate补全 turn 词汇表。此后的一切都更便宜。波内顺序turn 词汇表 →loop_contracts→extension_contracts→product_contracts→ 证据铸造合并⚠ 安全敏感其 refute 测试同 PR 落地→common收窄 → 两条单符号 product 边runner、loop_host。新 crate 落地纪律每个新 crate 在同一 PR 内携带 §11.2.3 允许名单 §11.2.4 端口位置扫描。里程碑异常 20 → 12agent_loop以零异常通过 contracts-onlywebui/openai/channel crates可以开始针对 contracts 编译翻转在 Wave 2。Wave 1 实际关闭情况2026-07-31七个 PR三个 contracts crate 全部存在agent_loop零异常 contracts-only但异常停在 13 而不是 12——因为conversations → turns是 turn 的准入权威而非词汇它落在 WS512这个数字在这波里从未可达。两条值得带走的发现host-auth-mintcargo feature从来不是密封feature unification 会让整个 workspace 都把 mint 门编译为开启每个 slot 都发现 lead-sheet 行部分过时——用你自己的基线重新测量行永远不要继承前任的计数。6. Wave 2——Extensions product 翻转WS2 WS5最讲究排序的一波。⚠端口反转先于层翻转落地extension_host先实现product_contracts端口只有当它的ironclaw_assistant依赖消失后它的层才移动到 loops否则无法编译。operator与webui/openai_compat的翻转同理。序列端口翻转extension_host, operator, webui, openai_compat→extension_manager拆分#6616/#6669 清单整体移动→ strays 出清pairing routes→webui、skill-learning 接缝、bundled skills→include_str!消灭 包同址化 telegram 合并 → memory-provider 包移动memory-nativemem0→extensions/packages/同 PR 携带 enforcement 重指向→ extensions/extension_host 重新分层 → 命名陷阱修复conversations/threads→ attachments 拓宽。里程碑extension_host→product边消失包在extensions/packages/下自包含Discord-proof§10.1字面为真——一个新 channel 只碰一个包目录 一条绑定行。这波产生了执行计划中最密集的修正记录每条都值得单独研读里程碑未达成且其中一条从构造上就不可达extension_host → product存活webui、openai_compat、extension_manager → product同理。结构原因统一调用者必须点名 product 的冻结command/view/capability 常量才能触达 surface而 §6.1.3 有意把这些留在 product。operator是反例——它的残留为零、manifest 边已删除因为它的端口签名从未点名 contracts 允许名单之外的类型。把波级结果压缩进每行里程碑会误导每个 slot 的预期。⚠extension_manager拆分并不像按原样到达那样整块移动清单九项中五项移动四项因结构原因不能动——product_lifecycle是生命周期权威§6.8.3 禁止 manager 拥有且与 #6930 的注册管线跨 16 个调用点互递归可用扩展目录被lifecycle_restore启动时读取没有可分离的 pairing 编排模块SharedCommandSurface在一个开放[decision]拥有的文件内是私有的。重新计价任何假设 #6616/#6669 清单可按名称分离的计划。重新分层的绑定约束是channel_host.rs而非端口它单独持有 26 个存活的 product 符号且是 composition 形态的装配——构造 product 的具体类型这是 contracts crate 永远不能点名的所以无法反转。§12.1c 的排序端口反转先于层翻转已满足未满足的是那个文件的归属——它是开放[decision]解决前products → loops无法编译。Wave 2 移除零条LAYER_MATRIX_EXCEPTIONS是预期结果它杀死的每条边都是products → products矩阵在结构上对它不可见PROSPOSAL §8.1 规则 1。注册表只在 crate改变层时移动——那是 Wave 3 和 Wave 5 的事不是 Wave 2 的。合并已审查的栈有效且有一个值得预防的失败模式#7018 用git merge按依赖顺序合并了四个已审查分支不用 rebase——它已经静默回滚过一个 fail-closed 扫描器不用 squash——那会毁掉 #7003 的重命名检测并逐文件对照各源分支验证并集207 个字节一致、80 个有解释、0 个无法解释。失败模式是跨切片数字一个 PR 里两个切片触碰同一被测量量webui 的 product 符号数第二个切片的移动使第一个切片的行失效而无人编辑。折叠栈时不仅要 diff 文件还要 diff 数字。Wave 2 收尾2026-08-03四条重新分层是两个独立半场、只有一半可达ironclaw_extension_registry→ substrates 落地并带走四条异常 10→6extension_host→ loops 未落地——全树重测发现是十二个生产文件点名ironclaw_assistant而非 D-A 裁决里的一个文件另立 #7092向下重分层是便宜的那种成本全在 crate 自己的依赖列表读 manifest 而不是读消费者过时的波列表浪费 slot 的第一个小时重新测量开放项列表从git log读真值行⚠分支名在并行 worktree 间冲突——推送后必须核对git ls-remote origin branch与本地 tip 一致再信任挂在其上的任何运行。2026-08-04 最终修正十二个文件里有六个从来不是 product 依赖——它们点名的类型只是ironclaw_product重导出的ChannelInboundSurface*实际在ironclaw_product_contracts::surfaceRebornChannelConnectStrategy是product_contracts::package_lifecycle::ChannelConnectStrategy的别名只需导入重指向#7143。强制余量不是文件数而是四个引用类四端口 trait 残留、adapter-registry 常量/函数、run_delivery_ports.rs里的两个 product 自由函数、channel_host.rs/channel_triggered_delivery.rs的 D-A 装配范围。此后整套集合被机械化枚举EXTENSION_HOST_PRODUCTION_FILES_STILL_NAMING_PRODUCT10 个文件、精确匹配、只缩不增、每文件一个理由下一次计价是文件列表 diff而不是估算。7. Wave 3——Kernel loop 收窄WS3 WS4非门控部分序列第一方工具 →extensions/ironclaw_extension_support/registrar 模式每个 PR 一族工具→sandboxlane 合并无生产行为落地时验证→mcpcontracts 翻转 → obligations/builder 内部拆分 → secrets 直接消费者收紧⚠ 端口替换先于边删除→ runner 卸负composition 函数移出、model gateway → loop_host、tool disclosure→ runner/hooks/processes 重新分层 →wit/移动。第一方工具族的两个关键教训只有工具的executor移动——它的 handler、manifest 和 registry 布线留在 host 侧因为extension_support的边界规则禁止ironclaw_host_runtime和ironclaw_extension_registry且host_runtime → ironclaw_extension_support不能按族逐个拆分——它只在最后一个 executor 移走时才倒下所以任何中间族 PR 都不该承诺它。2026-08-04 修正了后半句边确实不可按族拆分——但不是因为需要所有 executor而是它只被两个 executor已经移动的族coding、skills持有所以未来任何族 PR 都不可能移除它。它最终是被ironclaw_extension_support的loops → runtimes向下重分层消灭的而不是任何卸负。给后续族 PR 的常驻建议更简单了只按合并本身计价——已经没有可承诺的异常了。wit/移动2026-08-03越序且安全它排在列表最后但前面什么都不依赖不触碰任何兄弟 lane 的 crate移除零异常它移动文件不移动 crate 的层。两条发现一行可能成为唯一错的文档位置而多数派也不自动正确——CHECKLIST WS4 那行说crates/lanes/wit/另外四处说 crate 内但打破平局的是只有两个目的地之一能在 WS7 之后不被第二次编辑一次移动可以在纸面上履行一条护栏行同时让护栏自己的数字变差——把四处include_str!字面量重指向会让 §11.2.7 从 19 处跨 crate reach-in 变成 21 处修复办法是给被移动资产的文本一个 ownerironclaw_wasm::TOOL_WIT而不是四个读者。测量门禁的前与后永远不要从框推断方向。里程碑与修正里程碑最初写 12 → 0实际这波从 13 开局、main上实时注册表是6WS0_LAYER_MATRIX_EXCEPTION_BASELINE 6。三处错误被就地修正(1) 数字(2)棘轮钉住它是假的——§11.2.2 棘轮只设上限其自身失败消息还允许 owner 批准的基线抬升(3)→ 0 不是这波的可行退出——诚实退出是注册表到 3若 #7067 落在波内则是 1。但收尾记录显示never 0 又被证伪——这波以 0 退出。#7067 落进波内3→1最后一条随后倒下但倒下方式出乎该注的假设边被两个 executor 已移动的族持有且这波自己的 executor/adapter 接缝让 kernel 成为设计上的消费者所以边是结构性的而非过渡性的关闭它的是向下重分层ironclaw_extension_supportloops → runtimes计价方式正是 Wave 2 注里规定的那样。两条半对半错的教训(a) crate 改变层时期待注册表移动比字面更强——一条常驻异常本身就是层声明可能错误的证据先检查它比先规划代码移动更便宜(b) 一行removes_in命名的是意图而非机制给意图计价这里约 8 个 kernelpub拓宽 内建工具注册的语义变更145 处引用跨 31 个文件才能浮出更便宜的那个。标签警告removes_in W7是已退役的七月列车标签不是本计划的 Wave 5 或 WS7本计划的 §8.3 通过 WS2/WS3/WS4 工作解决每条 W7 标记的边W7 Wave 5 的解读已经被向上转述过一次作为事实它是错的。8. Wave 4——Composition、app、domainsWS6与 Wave 2–3 自由重叠——每次驱逐都相互独立。#6691 已落地2026-07-30composition 卸掉约 8.7k 行四项驱逐完成local_dev误名退役——所以这波从约一半已推进的位置开始剩余清单在 PROPOSAL §6.10.1 与 CHECKLIST WS6 中逐项与合并结果对账。两个要规划的结转project service 与 project-create 能力落在product而非identity::projects需要第二次跳跃project-create 移动给product → loop_host增加了一条行为边§6.9.1 的卸负现在要与两条纯数据边一起解决。执行形态composition 驱逐按每 PR 一个 owner§6.10.1 清单local_dev误名退役RebornRuntime瘦身config 厂商段移除及其兼容窗口CLI 厂商解析卸负改名全部已拍板作为纯改名 PR、无 shim且每条都落在该 crate 的 Wave 2–3 内容变更 PR 之后让 crate 内容改一次、名字改一次永不错乱三个 stutter 消灭event_log、extension_registry、assistant、命名审计四件套architecture_tests、extension_support、turn_runner、trace_commons、reborn_批次其余项composition、config、event_store、identity、openai_compat、cli 目录、根integration_tests。里程碑composition 读起来是装配其 mass ratchet 在新下限上重新基线config 无厂商段改名完成。9. Wave 5——物理家族移动WS7拆分 crate 故意晚做稳定 crate 灵活处理。⚠在第一次家族git mv之前WS10 列出的路径键控门禁coverage 合并、panic 扫描器 基线、e2e 路径过滤器、test-scope 分类器、dev-metrics globs必须重写为嵌套树安全形式——在家族目录下它们会静默失败而不是响亮失败。两种允许的模式(a)随里程碑移动——crate 的收窄落地时它移动首选各一次搅动(b)提前批量移动未触碰的 retain-as-is cratesubstrate/events/domains 叶子——Wave 0 之后随时可做纯git mv搅动按口味决定[decision]。最后一次移动与 §11.2.1 family⇄layer 测试和树比较脚本同 PR 落地。2026-08-05 完成树比较脚本是 scripts/ci/check-target-tree.py——它直接解析 PROPOSAL §5 自身而不重述脚本 docstring 明确说明docs/internal/reborn/target-architecture/PROPOSAL.md是唯一副本脚本故意不嵌入第二份会漂移的拷贝接入 Code Style 的Fast deterministic checks自带 17 个自测用例13 个是破坏性注入。它落地时的基线66 个 workspace 成员对 64 个文档化包、1 个文档化排除、2 个拥有的异常。三个检查点放置每个成员在 §5 画的位置§5 不画不存在的 crate、命名目录携带完整包名两个书面例外从树本身读出app/ironclaw_cli持有名为ironclaw的包、extensions/packages/下的目录以扩展身份命名、排除◇项必须存在且不是workspace 成员。异常表只缩不增未覆盖的 delta 失败不再描述真实 delta 的异常行也失败。wit/移动的排序教训六个发布的 WASM guest 经两条树到达工具 ABI——crates/extensions/packages/x/wasm-src/→crates/ironclaw_wasm/wit/——且 scripts/ci/check-wasm-artifact-freshness.py 把每个提交的.wasm键到其整个wasm-src/树的摘要。同 PR 移动ironclaw_wasm和extensions/packages重建只发生一次。实际落地更便宜extensions/packages随 WS7 1/2 批次移动、ironclaw_wasm随 2/2两次 PR 完成一次重建六个重建字节一致预测的六个约 300–600 KB 二进制花费了零提交字节只变了六行摘要。里程碑达成2026-08-05crates/与 PROPOSAL §5 精确一致——精确现在是机器检查的声明而非断言。WS7 1/2 以纯文本 diff 移动 56 个 crate 进入十个家族目录2/2 移动ironclaw_wasm并收尾。两个异常是里程碑诚实的余量不是滑移ironclaw_projects§12.10 决定并入identity但是带相等性基线成本的源码合并不是git mv和ironclaw_first_party_extension_ports删除由它自己的 §9 行拥有。两者都被验证器的只缩不增异常表钉住新 delta 和存活过久的行都会失败。2026-08-05WS8余量降为一个ironclaw_first_party_extension_ports溶解进ironclaw_loop_host::skill_activation——设计工作结果是测量出它桥接的环已不存在、行中三个目的地有两个层不可达——ironclaw_projects是唯一剩余异常。Wave 6 起无门控每个家族目录都有其 AGENTS.md当前仓库crates/下可见十个家族根如 crates/contracts/AGENTS.md、crates/kernel/AGENTS.md 等WS11 的十家族集合在 Wave 5 末完成已满足。10. Wave 6——Process-journal 工作WS9门已移除大部分已落地#6696 于 2026-07-29 合并31,677/−81,499 跨 374 文件带其导入/回滚契约带走了这波的大部分processes拓宽到行原生 journal 与ProcessSupervisorapprovals吸收 approval 与 gate 记录run_state被删除turn store 变成投影runner 的调度器反转到了 supervisor 之上。剩余一项且它是先决策后工作runner 的subagent/await_edge/约 2.9k 行被重做在 process 边上而非删除违背 #6696 自己的设计注。问题process 边能表达那个 resolver 做的事吗还是 await-edge 解析本质上是 loop 层然后要么把它卸进 Wave 3 的 runner 收窄要么修正 PROPOSAL §6.7.3 保留它。**2026-08-05 拍板§12.13 D-Sowner 指示下的授权权威标记给 #6696 作者事后审查修正而非卸负。**测量显示store 已经是纯ProcessDependencyPort投影那一半的卸负发生在 #6696 内部resolver 的 settle-consequence 语义是 loop 层的——无法表达为 journal 边。§6.7.3 携带修正此条目不产生 runner 收窄卸负。11. 持续轨道与每波并行强制WS10每条规则与它保护的变更同落或先落——从不滞后。指引WS11家族 AGENTS.md 在家族目录首次存在时写入crate 指南随 crate 移动/更新十家族集合在 Wave 5 末完成。验证WS12完整 gauntlet 在每个波边界运行扩展用户旅程在 Wave 2 和 3 之后重新验证最终 100% 门禁包括 fresh-agent placement 测试关闭 checklist。执行计划特别强调规则与变更同行的落地节奏并在 Wave 1 中证明了一个可复用习惯每个失败的可枚举门禁都被修复而非放宽——这是这些门禁被建造时具备的属性。12. 建议的前五个 PR具体、有序计划给出了可直接开工的前五个 PR且后续标注了它们的实际落地全部已落地#6934、#6942/#6943/#6964、#6944、#6967、#6975host_apiprelude 去通配符 重指向消费者WS0.1。死面第一轮dispatcherembeddingsllm::reasoning 未使用依赖边WS8。指引漂移热修根文档、crates/AGENTS.md、composition 指南、.claudeskills 中的不存在 crate 引用 幽灵模块WS11.3 子集。host_api::turn中完成 turn 词汇表 删除 turns 重导出 shim 重指向六个纯词汇消费者WS1.1——异常一个 PR 内 20→15六个消费者中五个携带异常conversations 和 hooks 随端口 PR 跟进。contracts/ironclaw_loop_contracts抽取 agent_loop翻转WS1.2——异常 15→12。✎ 实际落地为15→13hooks如预测倒下conversations没有也不能——它是 turn 准入权威而非词汇。13. 协作与流程纪律协调笔记计划记录了影响执行环境的六个关键 PR 与流程事实其中蕴含大量可迁移的工程经验#66912026-07-30大幅推进 Wave 4。重启任何 composition 驱逐前重读 §6.10.1四项已完成其中两项落在仍需第二次跳跃的目的地。#66962026-07-29Wave 6 无门控。对它的规划警告合并没有匹配它自己的设计注runner 的 await-edge 机制任何假设 runner 多缩 4.6k 的估算都错。从活树重新计价不要从 PR 描述计价。#68632026-07-29新增ironclaw_libsql_runtimesubstrates 层、无 workspace 依赖。它随 substrate 批次在 Wave 5 移动但改变了一条强制轨道落地的规则§11.2.6所以 WS10 的 persistence-idiom 项现在是两条断言而非一条。#6930register hosted MCP servers2026-07-3115,002/−1,818153 文件第一个大到足以改变本计划输入的功能PR恰好落在 Wave 2 领地。它不门控任何东西——但 Wave 2 继承了一个新的 sub-ownerhosted-MCP 注册管线4 模块 3.4k 行、Wave 5 继承了一个新的静默路径键控门禁reborn_registration_pipeline_boundary.rs硬编码路径后由 #6996 修复为通过 crate 清单解析的(crate name, in-crate path prefix)对并加measured_scan()断言防扫了个空、Wave 1 有一个实时的 merge-down 项host_api/src/package_lifecycle.rs新增ExtensionRegisterHostedMcp而它正是进行中的extension_contractsslot 要移出host_api的文件。Stacked-PR 证据当前是坏的#6978Wave 1 提出四个pull_request: branches: [main]门控的 workflow 不会挂到面向兄弟分支的 PR 上栈式切片没有自己的 CI 状态且workflow_dispatch运行的reborn-tests.yml在 roll-up 上结构性失败critical-mutation是pull_request/merge_group门控dispatch 下被 skip而 roll-up 不允许该 job skip。三条操作规则直到关闭reviewer 读逐 job 计数而非 roll-up每个切片的 PR 正文声明哪些证据是本地的、哪些是 dispatch 的含运行 URL 与匹配的 head SHA不要把 dispatch 运行上的红色 roll-up 当阻塞除非先确认critical-mutation是唯一失败。✎ 2026-08-04 roll-up 半场已修复mutation_expected (event merge_group)attach 半场是 GitHub 固有行为仍开。Wave 1 以七个 PR 落地WS1.1 #6967、WS1.2 #6975、WS1.3 #6977、WS1.4 #6980、WS1.5 #6981、WS1.6WS1.7 #6982外加中途文档对账 #6979。两个值得保留的习惯每个切片折叠到main后都验证合并后 delta 与合并前 delta 字节一致或对共享文件做行 diff——这抓住了 squash-merge 历史伪影静默丢弃兄弟编辑的情况每个失败的可枚举门禁被修复而非放宽。审查负载全波预计共约 35–50 个 PR七月列车证明这个节奏可持续。任何趋势超过约 400 有效行的语义变更移动除外都应拆分。进度记录落地这些 PR 时勾选 CHECKLIST.md 的框PROPOSAL.md 保持冻结作为决策记录实现中发现的分歧通过 PROPOSAL 修正走回去而非静默分歧。14. 可复用的工程方法清单总结执行计划在六轮修正中沉淀出一套高度可迁移的工程方法论值得单独提炼用你自己的基线重新测量每个数字——lead sheet 是工作表不是清单len()合并列表、cargo metadata、git log真值行而不是继承前任计数。只缩不增shrink-only门禁LAYER_MATRIX_EXCEPTIONS、允许名单、快照、异常表——失败条件同时覆盖新增 delta和存活过久的行且 staleness 检查让过期行变红。字节一致验证移动型 PR 的合并后 delta 与合并前 delta 逐字节核对折叠栈时 diff 数字与文件。un-masking 删除纪律全套件无过滤运行失败是候选行为不是要编辑的测试。测量门禁的前与后永远不从框推断方向——一次移动可以纸面履行一条护栏行同时让护栏自身数字变差。先测再动WS1.5 用探针测试证明 cargo feature 不是密封#7064 用真实路径探针纠正了三个错误结论。任何这个 feature 门控了 X的声明在按同样方式测量前都是未证实的。决策与工作分离[decision]项先拍板多数一条线程授权权威的裁决与 owner 裁决分开标注升级escalation保留完整推理与原始文本。常驻异常是层声明错误的证据——在规划代码移动前先检查它比两者都便宜。这套方法最终指向 PLAN.md 反复出现的主题重构的价值不在移动本身而在让哪里该放什么从考古变成可回答的问题并让债务从被豁免变为被结构性移除。执行计划本身也始终清醒地记录自己的错误——从20→12到never 0到单符号边每一处修正都带着测量数据而不是抹平痕迹这正是它最值得借鉴的地方。赞分享人工智能AI 应用交互助手AI Agent【免费下载链接】ironclawIronClaw is an Agent OS focused on privacy, security and extensibility项目地址https://gitcode.com/gh_mirrors/iro/ironclaw点击查看免费下载相关推荐IronClaw Reborn 架构审查实战指南用机器约束守护六条架构红线IronClaw Reborn 架构审查实战指南用机器约束守护六条架构红线 导读 IronClawAgent OS面向隐私、安全与可扩展性的 Rebo人工智能AI 应用交互助手AI AgentIronClaw lanes/ 执行机制族解析已授权调用的隔离执行架构IronClaw lanes/ 执行机制族解析已授权调用的隔离执行架构 本篇技术指南深入讲解 IronClaw一个面向隐私、安全与可扩展性的 Agent O人工智能AI 应用交互助手AI AgentIronClaw Substrates 层架构解析机制执行而非权威决策的特权基座设计IronClaw Substrates 层架构解析机制执行而非权威决策的特权基座设计 本篇技术指南以 IronClaw 开源仓库的 substrates 目标人工智能AI 应用交互助手AI Agent创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 IronClaw Reborn 架构重构执行计划解析：Wave 分波、守门人机制与 PR 尺寸纪律
人工智能AI 应用交互助手AI Agent【免费下载链接】ironclawIronClaw is an Agent OS focused on privacy, security and extensibility项目地址https://gitcode.com/gh_mirrors/iro/ironclaw点击查看免费下载导读IronClaw 是一个以隐私、安全和可扩展性为核心的 Agent OS其代码库经过数月演进后crates/下堆积了六十多个扁平 crate真实架构被目录结构掩盖。本文基于仓库中docs/internal/reborn/target-architecture/PLAN.md这份执行计划完整拆解 IronClaw Reborn 目标架构重构的何时做、怎么做Wave 0–6 的分波节奏、六条操作原则、四条承重排序约束、决策门decision gate、异常计数棘轮以及配套的机械守门人architecture tests 与 CI 脚本。读完本文你将理解如何把一个已经有机械强制依赖规则、但规则不可见的大型 Rust workspace在不做大爆炸重写的前提下安全地重组成目录即架构、异常可清零的形态并把这套方法论复用到你自己的仓库。1. 文档定位执行计划在 Reborn 重构文档族中的角色PLAN.md 自己给出了精确的自我定位这是推荐的开始并持续推进重构的方式——分波waves、守门人gates、PR 尺寸规则和决策点。它编排了 CHECKLIST.mdWS0–WS12中定义的工作流checklist 是做什么这里是何时与如何做。因此 Reborn 目标架构文档族是一个四件套各有分工文档角色位置README.md执行摘要与家族地图十大家族、稳态 64 包docs/internal/reborn/target-architecture/README.mdPROPOSAL.md完整证据支撑的规格说明书决策记录冻结不改docs/internal/reborn/target-architecture/PROPOSAL.mdCHECKLIST.md完成定义definition of done逐项勾选docs/internal/reborn/target-architecture/CHECKLIST.mdPLAN.md执行计划分波、排序、门禁、PR 尺寸本文主体docs/internal/reborn/target-architecture/PLAN.mdfamilies/每个家族一份深度规格面向未来不含迁移讨论docs/internal/reborn/target-architecture/families/执行计划反复强调这里没有什么是神圣的除了四条标 ⚠ 的承重排序约束。 同时它是一份活文档——从 2026-07-29 立项到 2026-08-06计划经历了多次落地标记✎ landed marker修正每次修正都带着测量数据而不是口头声明。这是理解整份计划的关键每一个数字都要在自己的基线上重新测量绝不继承前任的计数。2. 前置背景七层阶梯、十大家族与异常注册表要理解分波计划必须先理解它操作的对象。PROPOSAL 定义了核心模型详见 README.md 家族地图七层依赖阶梯contracts → substrates → runtimes → kernel → loops → products → app。每个 crate 在Cargo.toml的[package.metadata.ironclaw] layer声明自己的层级只允许依赖不高于自己的 crate。十个家族目录contracts/ substrates/ events/ domains/ kernel/ lanes/ loop/ extensions/ product/ app/。家族是发现性分组不是新的信任边界——目录 ≠ 边界层级矩阵才是 CI 检查的依赖真相。异常注册表LAYER_MATRIX_EXCEPTIONS是仓库自己机器追踪的债务清单初始20 条每条带removes_in目标里程碑。重构的终局是零异常且不新增任何一条。这条阶梯的机械强制在源码中可查reborn_workspace_crates_declare_layers_and_follow_layer_matrix与IRONCLAW_CRATE_LAYERS常量都位于 crates/app/ironclaw_architecture_tests/tests/reborn_dependency_boundaries.rs其中还有一条特殊规则ironclaw_agent_loop只能持有 contracts 层的普通依赖contracts-only规则这是全 workspace 最严格的一条依赖规则。重构完成后这条测试所在的 enforcement 套件自己也完成了重命名与搬家ironclaw_architecture_tests→ 目标树中的app/家族。异常棘轮CHECKLIST §11.2.2是整套计划的安全网LAYER_MATRIX_EXCEPTIONS.len() 基线只允许缩小、禁止增长。值得注意的教训来自 Wave 3 的修正棘轮是上限机制它不强制归零——→ 0 是 WS12 的完成门禁不是任何一波棘轮能保证的性质。这提醒读者不要把有棘轮误读为有进度保证。3. 六条操作原则来自七月列车事故的教训PLAN.md 开篇列出了六条操作原则这是整个分波执行的方法论底座Owner-by-owner拒绝 big-bang。成功的抽取#6529…#6669都是每个 PR 移动一个连贯的 owner四个 god crate 的收窄是许多个 PR不是一个。Move-only PR 无行为变更且如此声明。git mv 路径更新 指引更新diff 里没有其他东西拆分和语义变更绝不与移动共用一个 PR。测试与指引随变更同行。每个 PR 在同一 diff 里更新它失效的 crate 指南、家族 AGENTS.md 与边界规则——审计最清晰的一条教训指引漂移是让 Agent 困惑的根源。删除采用揭开面纱un-masking纪律被触碰的每个 crate 都要跑完整无过滤的测试套件浮出水面的失败是候选的应保留行为而不是要修改的测试。每个 PR 之后main保持可发布。没有一波会留下半翻转的依赖边每个 PR 结束时架构套件全绿异常计数单调不增。决策门便宜到可以随时开昂贵到不能跳过。[decision]项Strategy 确认、triggers/hooks SQL、trust 的签名注册表路径、skills 复活、identity 绑定存储、tools 默认成员必须在对应 wave 开始前拍板——多数只是各一条 Slack 线程。这六条原则直接决定了 Wave 的切分粒度移动是廉价的单位拆分才是昂贵的单位。整个计划约 45 个映射是纯移动/改名只有六个 crate 需要真正的拆分且每个拆分都落在两侧已有测试套件的接缝上。4. Wave 0——现在就开始无设计风险立竿见影Wave 0 的所有内容今天都可以独立落地并且为后续每一波缩小问题域WS0 去通配符化host_api的 prelude⚠ 承重约束——大多数后续行依赖的唯一前置条件。行为无关、机械操作、diff 大但极易审查。落地证据crates/ironclaw_host_api/src/lib.rs的 45 行pub use mod::*;被替换为模块限定导出CHECKLIST 记录rg -c pub use .*::\*→ 0。WS8 安全删除第一轮——零消费者、爆炸半径最小的项dispatcher、embeddings、llm::reasoning、common::trust_boundary、events的 jsonl 辅助函数、outbound/approvals的死 trait、event_projections的三个死子系统这一项单独就把它的依赖集缩小到 eventshost_api、未使用的依赖边、根fuzz/、auth::loopback_oauth、gatingauth::fakes。每项都遵循 un-masking 纪律。WS11 会误导当前 Agent 的漂移热修——对七个不存在 crate 的引用、build_reborn_services、NetworkPolicyDecider、composition 指南里幽灵的src/webui/章节、过时的 feature-gating 声明。这些不等重构它们现在就错。WS0 基线 WS10 §11.2.2 异常棘轮初始武装在 20只许下降 §11.2.7 include-scan 的 warn 模式在 WS2 之前它必然失败——这正是目的让债务可见。决策轮 #1[decision]确认 Strategy B tools 默认成员一条线程改名范围已全部拍板2026-07-29 owner review 2026-07-30 命名审计无条件在各 wave 中执行。退出标准异常计数仍为 20 但已棘轮化死面第一轮已消失prelude 去通配符完成团队签收记录在案。5. Wave 1——ContractsWS1杠杆波创建三个 contracts crate补全 turn 词汇表。此后的一切都更便宜。波内顺序turn 词汇表 →loop_contracts→extension_contracts→product_contracts→ 证据铸造合并⚠ 安全敏感其 refute 测试同 PR 落地→common收窄 → 两条单符号 product 边runner、loop_host。新 crate 落地纪律每个新 crate 在同一 PR 内携带 §11.2.3 允许名单 §11.2.4 端口位置扫描。里程碑异常 20 → 12agent_loop以零异常通过 contracts-onlywebui/openai/channel crates可以开始针对 contracts 编译翻转在 Wave 2。Wave 1 实际关闭情况2026-07-31七个 PR三个 contracts crate 全部存在agent_loop零异常 contracts-only但异常停在 13 而不是 12——因为conversations → turns是 turn 的准入权威而非词汇它落在 WS512这个数字在这波里从未可达。两条值得带走的发现host-auth-mintcargo feature从来不是密封feature unification 会让整个 workspace 都把 mint 门编译为开启每个 slot 都发现 lead-sheet 行部分过时——用你自己的基线重新测量行永远不要继承前任的计数。6. Wave 2——Extensions product 翻转WS2 WS5最讲究排序的一波。⚠端口反转先于层翻转落地extension_host先实现product_contracts端口只有当它的ironclaw_assistant依赖消失后它的层才移动到 loops否则无法编译。operator与webui/openai_compat的翻转同理。序列端口翻转extension_host, operator, webui, openai_compat→extension_manager拆分#6616/#6669 清单整体移动→ strays 出清pairing routes→webui、skill-learning 接缝、bundled skills→include_str!消灭 包同址化 telegram 合并 → memory-provider 包移动memory-nativemem0→extensions/packages/同 PR 携带 enforcement 重指向→ extensions/extension_host 重新分层 → 命名陷阱修复conversations/threads→ attachments 拓宽。里程碑extension_host→product边消失包在extensions/packages/下自包含Discord-proof§10.1字面为真——一个新 channel 只碰一个包目录 一条绑定行。这波产生了执行计划中最密集的修正记录每条都值得单独研读里程碑未达成且其中一条从构造上就不可达extension_host → product存活webui、openai_compat、extension_manager → product同理。结构原因统一调用者必须点名 product 的冻结command/view/capability 常量才能触达 surface而 §6.1.3 有意把这些留在 product。operator是反例——它的残留为零、manifest 边已删除因为它的端口签名从未点名 contracts 允许名单之外的类型。把波级结果压缩进每行里程碑会误导每个 slot 的预期。⚠extension_manager拆分并不像按原样到达那样整块移动清单九项中五项移动四项因结构原因不能动——product_lifecycle是生命周期权威§6.8.3 禁止 manager 拥有且与 #6930 的注册管线跨 16 个调用点互递归可用扩展目录被lifecycle_restore启动时读取没有可分离的 pairing 编排模块SharedCommandSurface在一个开放[decision]拥有的文件内是私有的。重新计价任何假设 #6616/#6669 清单可按名称分离的计划。重新分层的绑定约束是channel_host.rs而非端口它单独持有 26 个存活的 product 符号且是 composition 形态的装配——构造 product 的具体类型这是 contracts crate 永远不能点名的所以无法反转。§12.1c 的排序端口反转先于层翻转已满足未满足的是那个文件的归属——它是开放[decision]解决前products → loops无法编译。Wave 2 移除零条LAYER_MATRIX_EXCEPTIONS是预期结果它杀死的每条边都是products → products矩阵在结构上对它不可见PROSPOSAL §8.1 规则 1。注册表只在 crate改变层时移动——那是 Wave 3 和 Wave 5 的事不是 Wave 2 的。合并已审查的栈有效且有一个值得预防的失败模式#7018 用git merge按依赖顺序合并了四个已审查分支不用 rebase——它已经静默回滚过一个 fail-closed 扫描器不用 squash——那会毁掉 #7003 的重命名检测并逐文件对照各源分支验证并集207 个字节一致、80 个有解释、0 个无法解释。失败模式是跨切片数字一个 PR 里两个切片触碰同一被测量量webui 的 product 符号数第二个切片的移动使第一个切片的行失效而无人编辑。折叠栈时不仅要 diff 文件还要 diff 数字。Wave 2 收尾2026-08-03四条重新分层是两个独立半场、只有一半可达ironclaw_extension_registry→ substrates 落地并带走四条异常 10→6extension_host→ loops 未落地——全树重测发现是十二个生产文件点名ironclaw_assistant而非 D-A 裁决里的一个文件另立 #7092向下重分层是便宜的那种成本全在 crate 自己的依赖列表读 manifest 而不是读消费者过时的波列表浪费 slot 的第一个小时重新测量开放项列表从git log读真值行⚠分支名在并行 worktree 间冲突——推送后必须核对git ls-remote origin branch与本地 tip 一致再信任挂在其上的任何运行。2026-08-04 最终修正十二个文件里有六个从来不是 product 依赖——它们点名的类型只是ironclaw_product重导出的ChannelInboundSurface*实际在ironclaw_product_contracts::surfaceRebornChannelConnectStrategy是product_contracts::package_lifecycle::ChannelConnectStrategy的别名只需导入重指向#7143。强制余量不是文件数而是四个引用类四端口 trait 残留、adapter-registry 常量/函数、run_delivery_ports.rs里的两个 product 自由函数、channel_host.rs/channel_triggered_delivery.rs的 D-A 装配范围。此后整套集合被机械化枚举EXTENSION_HOST_PRODUCTION_FILES_STILL_NAMING_PRODUCT10 个文件、精确匹配、只缩不增、每文件一个理由下一次计价是文件列表 diff而不是估算。7. Wave 3——Kernel loop 收窄WS3 WS4非门控部分序列第一方工具 →extensions/ironclaw_extension_support/registrar 模式每个 PR 一族工具→sandboxlane 合并无生产行为落地时验证→mcpcontracts 翻转 → obligations/builder 内部拆分 → secrets 直接消费者收紧⚠ 端口替换先于边删除→ runner 卸负composition 函数移出、model gateway → loop_host、tool disclosure→ runner/hooks/processes 重新分层 →wit/移动。第一方工具族的两个关键教训只有工具的executor移动——它的 handler、manifest 和 registry 布线留在 host 侧因为extension_support的边界规则禁止ironclaw_host_runtime和ironclaw_extension_registry且host_runtime → ironclaw_extension_support不能按族逐个拆分——它只在最后一个 executor 移走时才倒下所以任何中间族 PR 都不该承诺它。2026-08-04 修正了后半句边确实不可按族拆分——但不是因为需要所有 executor而是它只被两个 executor已经移动的族coding、skills持有所以未来任何族 PR 都不可能移除它。它最终是被ironclaw_extension_support的loops → runtimes向下重分层消灭的而不是任何卸负。给后续族 PR 的常驻建议更简单了只按合并本身计价——已经没有可承诺的异常了。wit/移动2026-08-03越序且安全它排在列表最后但前面什么都不依赖不触碰任何兄弟 lane 的 crate移除零异常它移动文件不移动 crate 的层。两条发现一行可能成为唯一错的文档位置而多数派也不自动正确——CHECKLIST WS4 那行说crates/lanes/wit/另外四处说 crate 内但打破平局的是只有两个目的地之一能在 WS7 之后不被第二次编辑一次移动可以在纸面上履行一条护栏行同时让护栏自己的数字变差——把四处include_str!字面量重指向会让 §11.2.7 从 19 处跨 crate reach-in 变成 21 处修复办法是给被移动资产的文本一个 ownerironclaw_wasm::TOOL_WIT而不是四个读者。测量门禁的前与后永远不要从框推断方向。里程碑与修正里程碑最初写 12 → 0实际这波从 13 开局、main上实时注册表是6WS0_LAYER_MATRIX_EXCEPTION_BASELINE 6。三处错误被就地修正(1) 数字(2)棘轮钉住它是假的——§11.2.2 棘轮只设上限其自身失败消息还允许 owner 批准的基线抬升(3)→ 0 不是这波的可行退出——诚实退出是注册表到 3若 #7067 落在波内则是 1。但收尾记录显示never 0 又被证伪——这波以 0 退出。#7067 落进波内3→1最后一条随后倒下但倒下方式出乎该注的假设边被两个 executor 已移动的族持有且这波自己的 executor/adapter 接缝让 kernel 成为设计上的消费者所以边是结构性的而非过渡性的关闭它的是向下重分层ironclaw_extension_supportloops → runtimes计价方式正是 Wave 2 注里规定的那样。两条半对半错的教训(a) crate 改变层时期待注册表移动比字面更强——一条常驻异常本身就是层声明可能错误的证据先检查它比先规划代码移动更便宜(b) 一行removes_in命名的是意图而非机制给意图计价这里约 8 个 kernelpub拓宽 内建工具注册的语义变更145 处引用跨 31 个文件才能浮出更便宜的那个。标签警告removes_in W7是已退役的七月列车标签不是本计划的 Wave 5 或 WS7本计划的 §8.3 通过 WS2/WS3/WS4 工作解决每条 W7 标记的边W7 Wave 5 的解读已经被向上转述过一次作为事实它是错的。8. Wave 4——Composition、app、domainsWS6与 Wave 2–3 自由重叠——每次驱逐都相互独立。#6691 已落地2026-07-30composition 卸掉约 8.7k 行四项驱逐完成local_dev误名退役——所以这波从约一半已推进的位置开始剩余清单在 PROPOSAL §6.10.1 与 CHECKLIST WS6 中逐项与合并结果对账。两个要规划的结转project service 与 project-create 能力落在product而非identity::projects需要第二次跳跃project-create 移动给product → loop_host增加了一条行为边§6.9.1 的卸负现在要与两条纯数据边一起解决。执行形态composition 驱逐按每 PR 一个 owner§6.10.1 清单local_dev误名退役RebornRuntime瘦身config 厂商段移除及其兼容窗口CLI 厂商解析卸负改名全部已拍板作为纯改名 PR、无 shim且每条都落在该 crate 的 Wave 2–3 内容变更 PR 之后让 crate 内容改一次、名字改一次永不错乱三个 stutter 消灭event_log、extension_registry、assistant、命名审计四件套architecture_tests、extension_support、turn_runner、trace_commons、reborn_批次其余项composition、config、event_store、identity、openai_compat、cli 目录、根integration_tests。里程碑composition 读起来是装配其 mass ratchet 在新下限上重新基线config 无厂商段改名完成。9. Wave 5——物理家族移动WS7拆分 crate 故意晚做稳定 crate 灵活处理。⚠在第一次家族git mv之前WS10 列出的路径键控门禁coverage 合并、panic 扫描器 基线、e2e 路径过滤器、test-scope 分类器、dev-metrics globs必须重写为嵌套树安全形式——在家族目录下它们会静默失败而不是响亮失败。两种允许的模式(a)随里程碑移动——crate 的收窄落地时它移动首选各一次搅动(b)提前批量移动未触碰的 retain-as-is cratesubstrate/events/domains 叶子——Wave 0 之后随时可做纯git mv搅动按口味决定[decision]。最后一次移动与 §11.2.1 family⇄layer 测试和树比较脚本同 PR 落地。2026-08-05 完成树比较脚本是 scripts/ci/check-target-tree.py——它直接解析 PROPOSAL §5 自身而不重述脚本 docstring 明确说明docs/internal/reborn/target-architecture/PROPOSAL.md是唯一副本脚本故意不嵌入第二份会漂移的拷贝接入 Code Style 的Fast deterministic checks自带 17 个自测用例13 个是破坏性注入。它落地时的基线66 个 workspace 成员对 64 个文档化包、1 个文档化排除、2 个拥有的异常。三个检查点放置每个成员在 §5 画的位置§5 不画不存在的 crate、命名目录携带完整包名两个书面例外从树本身读出app/ironclaw_cli持有名为ironclaw的包、extensions/packages/下的目录以扩展身份命名、排除◇项必须存在且不是workspace 成员。异常表只缩不增未覆盖的 delta 失败不再描述真实 delta 的异常行也失败。wit/移动的排序教训六个发布的 WASM guest 经两条树到达工具 ABI——crates/extensions/packages/x/wasm-src/→crates/ironclaw_wasm/wit/——且 scripts/ci/check-wasm-artifact-freshness.py 把每个提交的.wasm键到其整个wasm-src/树的摘要。同 PR 移动ironclaw_wasm和extensions/packages重建只发生一次。实际落地更便宜extensions/packages随 WS7 1/2 批次移动、ironclaw_wasm随 2/2两次 PR 完成一次重建六个重建字节一致预测的六个约 300–600 KB 二进制花费了零提交字节只变了六行摘要。里程碑达成2026-08-05crates/与 PROPOSAL §5 精确一致——精确现在是机器检查的声明而非断言。WS7 1/2 以纯文本 diff 移动 56 个 crate 进入十个家族目录2/2 移动ironclaw_wasm并收尾。两个异常是里程碑诚实的余量不是滑移ironclaw_projects§12.10 决定并入identity但是带相等性基线成本的源码合并不是git mv和ironclaw_first_party_extension_ports删除由它自己的 §9 行拥有。两者都被验证器的只缩不增异常表钉住新 delta 和存活过久的行都会失败。2026-08-05WS8余量降为一个ironclaw_first_party_extension_ports溶解进ironclaw_loop_host::skill_activation——设计工作结果是测量出它桥接的环已不存在、行中三个目的地有两个层不可达——ironclaw_projects是唯一剩余异常。Wave 6 起无门控每个家族目录都有其 AGENTS.md当前仓库crates/下可见十个家族根如 crates/contracts/AGENTS.md、crates/kernel/AGENTS.md 等WS11 的十家族集合在 Wave 5 末完成已满足。10. Wave 6——Process-journal 工作WS9门已移除大部分已落地#6696 于 2026-07-29 合并31,677/−81,499 跨 374 文件带其导入/回滚契约带走了这波的大部分processes拓宽到行原生 journal 与ProcessSupervisorapprovals吸收 approval 与 gate 记录run_state被删除turn store 变成投影runner 的调度器反转到了 supervisor 之上。剩余一项且它是先决策后工作runner 的subagent/await_edge/约 2.9k 行被重做在 process 边上而非删除违背 #6696 自己的设计注。问题process 边能表达那个 resolver 做的事吗还是 await-edge 解析本质上是 loop 层然后要么把它卸进 Wave 3 的 runner 收窄要么修正 PROPOSAL §6.7.3 保留它。**2026-08-05 拍板§12.13 D-Sowner 指示下的授权权威标记给 #6696 作者事后审查修正而非卸负。**测量显示store 已经是纯ProcessDependencyPort投影那一半的卸负发生在 #6696 内部resolver 的 settle-consequence 语义是 loop 层的——无法表达为 journal 边。§6.7.3 携带修正此条目不产生 runner 收窄卸负。11. 持续轨道与每波并行强制WS10每条规则与它保护的变更同落或先落——从不滞后。指引WS11家族 AGENTS.md 在家族目录首次存在时写入crate 指南随 crate 移动/更新十家族集合在 Wave 5 末完成。验证WS12完整 gauntlet 在每个波边界运行扩展用户旅程在 Wave 2 和 3 之后重新验证最终 100% 门禁包括 fresh-agent placement 测试关闭 checklist。执行计划特别强调规则与变更同行的落地节奏并在 Wave 1 中证明了一个可复用习惯每个失败的可枚举门禁都被修复而非放宽——这是这些门禁被建造时具备的属性。12. 建议的前五个 PR具体、有序计划给出了可直接开工的前五个 PR且后续标注了它们的实际落地全部已落地#6934、#6942/#6943/#6964、#6944、#6967、#6975host_apiprelude 去通配符 重指向消费者WS0.1。死面第一轮dispatcherembeddingsllm::reasoning 未使用依赖边WS8。指引漂移热修根文档、crates/AGENTS.md、composition 指南、.claudeskills 中的不存在 crate 引用 幽灵模块WS11.3 子集。host_api::turn中完成 turn 词汇表 删除 turns 重导出 shim 重指向六个纯词汇消费者WS1.1——异常一个 PR 内 20→15六个消费者中五个携带异常conversations 和 hooks 随端口 PR 跟进。contracts/ironclaw_loop_contracts抽取 agent_loop翻转WS1.2——异常 15→12。✎ 实际落地为15→13hooks如预测倒下conversations没有也不能——它是 turn 准入权威而非词汇。13. 协作与流程纪律协调笔记计划记录了影响执行环境的六个关键 PR 与流程事实其中蕴含大量可迁移的工程经验#66912026-07-30大幅推进 Wave 4。重启任何 composition 驱逐前重读 §6.10.1四项已完成其中两项落在仍需第二次跳跃的目的地。#66962026-07-29Wave 6 无门控。对它的规划警告合并没有匹配它自己的设计注runner 的 await-edge 机制任何假设 runner 多缩 4.6k 的估算都错。从活树重新计价不要从 PR 描述计价。#68632026-07-29新增ironclaw_libsql_runtimesubstrates 层、无 workspace 依赖。它随 substrate 批次在 Wave 5 移动但改变了一条强制轨道落地的规则§11.2.6所以 WS10 的 persistence-idiom 项现在是两条断言而非一条。#6930register hosted MCP servers2026-07-3115,002/−1,818153 文件第一个大到足以改变本计划输入的功能PR恰好落在 Wave 2 领地。它不门控任何东西——但 Wave 2 继承了一个新的 sub-ownerhosted-MCP 注册管线4 模块 3.4k 行、Wave 5 继承了一个新的静默路径键控门禁reborn_registration_pipeline_boundary.rs硬编码路径后由 #6996 修复为通过 crate 清单解析的(crate name, in-crate path prefix)对并加measured_scan()断言防扫了个空、Wave 1 有一个实时的 merge-down 项host_api/src/package_lifecycle.rs新增ExtensionRegisterHostedMcp而它正是进行中的extension_contractsslot 要移出host_api的文件。Stacked-PR 证据当前是坏的#6978Wave 1 提出四个pull_request: branches: [main]门控的 workflow 不会挂到面向兄弟分支的 PR 上栈式切片没有自己的 CI 状态且workflow_dispatch运行的reborn-tests.yml在 roll-up 上结构性失败critical-mutation是pull_request/merge_group门控dispatch 下被 skip而 roll-up 不允许该 job skip。三条操作规则直到关闭reviewer 读逐 job 计数而非 roll-up每个切片的 PR 正文声明哪些证据是本地的、哪些是 dispatch 的含运行 URL 与匹配的 head SHA不要把 dispatch 运行上的红色 roll-up 当阻塞除非先确认critical-mutation是唯一失败。✎ 2026-08-04 roll-up 半场已修复mutation_expected (event merge_group)attach 半场是 GitHub 固有行为仍开。Wave 1 以七个 PR 落地WS1.1 #6967、WS1.2 #6975、WS1.3 #6977、WS1.4 #6980、WS1.5 #6981、WS1.6WS1.7 #6982外加中途文档对账 #6979。两个值得保留的习惯每个切片折叠到main后都验证合并后 delta 与合并前 delta 字节一致或对共享文件做行 diff——这抓住了 squash-merge 历史伪影静默丢弃兄弟编辑的情况每个失败的可枚举门禁被修复而非放宽。审查负载全波预计共约 35–50 个 PR七月列车证明这个节奏可持续。任何趋势超过约 400 有效行的语义变更移动除外都应拆分。进度记录落地这些 PR 时勾选 CHECKLIST.md 的框PROPOSAL.md 保持冻结作为决策记录实现中发现的分歧通过 PROPOSAL 修正走回去而非静默分歧。14. 可复用的工程方法清单总结执行计划在六轮修正中沉淀出一套高度可迁移的工程方法论值得单独提炼用你自己的基线重新测量每个数字——lead sheet 是工作表不是清单len()合并列表、cargo metadata、git log真值行而不是继承前任计数。只缩不增shrink-only门禁LAYER_MATRIX_EXCEPTIONS、允许名单、快照、异常表——失败条件同时覆盖新增 delta和存活过久的行且 staleness 检查让过期行变红。字节一致验证移动型 PR 的合并后 delta 与合并前 delta 逐字节核对折叠栈时 diff 数字与文件。un-masking 删除纪律全套件无过滤运行失败是候选行为不是要编辑的测试。测量门禁的前与后永远不从框推断方向——一次移动可以纸面履行一条护栏行同时让护栏自身数字变差。先测再动WS1.5 用探针测试证明 cargo feature 不是密封#7064 用真实路径探针纠正了三个错误结论。任何这个 feature 门控了 X的声明在按同样方式测量前都是未证实的。决策与工作分离[decision]项先拍板多数一条线程授权权威的裁决与 owner 裁决分开标注升级escalation保留完整推理与原始文本。常驻异常是层声明错误的证据——在规划代码移动前先检查它比两者都便宜。这套方法最终指向 PLAN.md 反复出现的主题重构的价值不在移动本身而在让哪里该放什么从考古变成可回答的问题并让债务从被豁免变为被结构性移除。执行计划本身也始终清醒地记录自己的错误——从20→12到never 0到单符号边每一处修正都带着测量数据而不是抹平痕迹这正是它最值得借鉴的地方。赞分享人工智能AI 应用交互助手AI Agent【免费下载链接】ironclawIronClaw is an Agent OS focused on privacy, security and extensibility项目地址https://gitcode.com/gh_mirrors/iro/ironclaw点击查看免费下载相关推荐IronClaw Reborn 架构审查实战指南用机器约束守护六条架构红线IronClaw Reborn 架构审查实战指南用机器约束守护六条架构红线 导读 IronClawAgent OS面向隐私、安全与可扩展性的 Rebo人工智能AI 应用交互助手AI AgentIronClaw lanes/ 执行机制族解析已授权调用的隔离执行架构IronClaw lanes/ 执行机制族解析已授权调用的隔离执行架构 本篇技术指南深入讲解 IronClaw一个面向隐私、安全与可扩展性的 Agent O人工智能AI 应用交互助手AI AgentIronClaw Substrates 层架构解析机制执行而非权威决策的特权基座设计IronClaw Substrates 层架构解析机制执行而非权威决策的特权基座设计 本篇技术指南以 IronClaw 开源仓库的 substrates 目标人工智能AI 应用交互助手AI Agent创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考