企业官网建设流程全解析

• 人工智能
• AI 应用
• 交互助手
• AI Agent

本文以 docs/internal/reborn/target-architecture/families/kernel.md 为骨架，结合 crates/kernel 家族源码、crates/kernel/AGENTS.md 与 docs/internal/reborn/contracts/kernel-boundary.md 契约文档，系统讲解 IronClaw 中"内核（kernel）"作为安全外围（security perimeter）的设计：为什么它不是单一 crate、九个 crate 各自拥有哪一段特权效应管线、每段阶段的 fail-closed 规则如何在源码与架构测试中被机械地固定。读完本文，你将能够回答"一个特权效应在 IronClaw 中要跨过哪些关口""某个能力调用应该落在哪个 crate""新增内核 crate 需要满足什么边界测试"这些实战问题。

内核是什么：安全外围，而不是一个 crate

IronClaw 的 kernel 家族位于 crates/kernel 目录，是七层依赖阶梯（contracts < substrates < runtimes < kernel < loops < products < app）中承上启下的关键一层。它的定位与直觉相反：内核是一个安全外围（security perimeter），不是代码库中的一个 crate。它由"它调解了什么"来定义，而不是由"它执行了多少行为"来定义——凡是能够影响权威（authority）、隔离（isolation）、持久化控制面状态（durable control-plane state）或敏感数据的操作，都必须穿越一个内核调解的端口（kernel-mediated port），无论该端口由哪个 crate 实现。

项目中不存在、也不应该存在一个ironclaw_kernelcrate。把外围坍缩进单一 crate 会掩盖一个事实：这个外围由多个可独立验证的阶段组成，每个阶段都有自己的 fail-closed 规则和密封的公开表面。

crates/kernel/将这个外围物化为9 个 crate，每个 crate 恰好拥有特权效应管线的一个阶段：

crates/kernel/ ├── ironclaw_trust trust ceilings (sealed) ├── ironclaw_authorization default-deny grants & capability leases ├── ironclaw_approvals exact-invocation consent ├── ironclaw_resources reservation & quota accounting ├── ironclaw_runtime_policy pure policy resolution & lane planning ├── ironclaw_capabilities the CapabilityHost membrane ├── ironclaw_processes lifecycle authority: journal & supervisor ├── ironclaw_turns turn admission & exit validation └── ironclaw_host_runtime mediated services & the lane executor

调用方——loop、扩展（extension）、产品面（product surface）——永远不直接触碰这些阶段；它调用的是"膜"（membrane，即ironclaw_capabilities），由膜去调用其余部分。内核不需要调解的一切都留在内核之外：agent-loop 策略、prompt 组装、任务编排、技能选择、渠道呈现都运行在内核之上，在内核发放的 grants、mounts、leases 和 budget 之下运行。

这一边界的合同语义早在 docs/internal/reborn/contracts/kernel-boundary.md 中被冻结：内核调解的操作包括能力调用/恢复/派生、授权与 grant 匹配、信任类策略求值、义务准备/完成/中止、审批请求与精确调用（exact-invocation）lease 协调、run 状态协调、每线程单活跃 run 协调、文件系统挂载/作用域路径权威、网络策略求值与加固 egress、密钥元数据与一次性消费、资源预留/对账/释放与配额、脱敏与泄漏检测义务、进程生命周期/结果/输出权威面等；而 agent-loop 策略、prompt 组装策略、routine 引擎、技能选择、渠道 UX 等则明确属于 userland。

边界：什么让这个家族与众不同

内核家族的边界划分是理解整个 IronClaw 架构的关键。它与相邻家族的区别如下：

• vssubstrates/（基底）——基底（文件系统、密钥、网络、安全）是机制：与后端无关、与策略无关的机器。内核 crate 决定是否以及如何触碰某个基底，然后调用它；基底永远不决定权威。对应源码见 crates/substrates（ironclaw_filesystem、ironclaw_secrets、ironclaw_network、ironclaw_safety）。
• vsdomains/（领域）——领域拥有某个持久化事物的记录文法；内核拥有关于"做某件事"的决策。领域回答"这是什么记录、它是否合法"；内核回答"这件事是否被允许发生、它是否安全地发生了"。参见 crates/domains。
• vslanes/（执行道）——lanes 执行已被授权的工作，接收密封的 witness 和调解后的服务；它们自己从不授权任何东西。内核是唯一能铸造 witness 的地方。
• vsloop/（循环层）——loop 层是可替换的 userland 策略，本身没有内在权威；它只能通过类型化端口触达内核，内核从不依赖 loop 代码。
• vsapp/（组装层）——composition 为一次部署装配具体的 kernel 服务，自身不持有任何权威逻辑；"内核做决策，app/组装决策者"。

为什么是九个 crate 而不是一个。每个阶段都是一个可独立消费的契约，有自己独立的 fail-closed 规则和自己的密封/多实现形态。把它们折叠进一个 crate，等于把一个编译器可证明的依赖边界——策略引擎的私有 mutator 在自己的 crate 之外不可见、预留治理者的平台相关依赖永远不会触达调用膜——换成一种仅靠 review 来维持的纪律。

特权效应管线与阶段归属

每个特权效应都依序通过同样的阶段。两个 crate 作为持久的准入与生命周期权威把管线夹在两端（admission 与 claimed execution），其余 crate 组成膜本身：

ironclaw_turns与ironclaw_processes是两个准入/生命周期权威：turns 决定工作是否被持久准入；processes 决定已准入的工作如何被认领、跟踪并带至终态——无论是前台 turn 还是后台调用。

在源码中，这一管线被 crates/kernel/ironclaw_capabilities/src/host/mod.rs 的模块章程直接落实：invoke、approval_resume、auth_resume、spawn_resume、spawn各自是私有的工作流模块，authorize是它们共同汇入的单一折叠（fold）。文件头部注释明确三条规则：工作流模块只拥有自己的"前奏"（preamble），两个以上工作流共享的步骤归resume_support；authorize做决策，工作流只映射裁决；本文件只持有状态与词汇，不持有行为。

什么属于这里 / 什么永远不属于这里

属于：决策、leases、预留、调解、生命周期权威、调度组装——一个决策值、一个能力 lease、一个资源预留、一个义务处理器、一个进程或 turn 的转移、密封的 witness 本身。

永远不属于：产品 UX、loop 策略、厂商特定行为、lane 执行机制、存储后端实现。这个家族没有任何 crate 会渲染 prompt、选择投递目标、按厂商协议分支、直接派生容器，或在其任何输出中持久化原始密钥、主机路径或后端错误细节。

crates/kernel/AGENTS.md 的"从不属于这里"清单更进一步并给出归宿：内核阶段被 product/loop/extension crate 持有（去crates/loop/、crates/product/、crates/extensions/）；向上依赖（通过内核定义的端口反向实现，如ProcessExecutor由ironclaw_turn_runner/ironclaw_host_runtime注册）；在任何其他地方铸造密封证据；prompt 组装/任务编排/技能选择/渠道呈现（userland）；厂商特定行为（crates/extensions/packages/*、ironclaw_llmproviders）；lane 执行机制（crates/lanes/）；存储后端实现（crates/substrates/ironclaw_filesystem、ironclaw_libsql_runtime、crates/events/ironclaw_event_store）；以及内核 crate 输出中的原始载荷（无密钥、主机路径、后端错误细节或未脱敏的用户内容）。

依赖方向

内核 crate 依赖各层共享的中性权威词汇（标识符、作用域、能力与决策类型）、基底家族（调解后的存储/凭证/egress 机制）、事件家族（持久审计）、lane 家族（封闭执行器需要构造 lane 适配器），以及沿阶段顺序互相依赖。内核 crate 从不依赖loop/、product/或app/，只有一处刻意的反转：一个定义在内核内部、由更高层实现的端口——进程种类（process-kind）执行在这里定义，由拥有该类工作的 crate 注册。调度端口是中性契约词汇（host_api），膜是它的生产实现。

其他每个家族都依赖这个家族——直接依赖或通过类型化端口；这个家族没有任何东西反向依赖回去。

在机械执行层面，crates/kernel/AGENTS.md 记录了几套可运行的 enforcement：

• 层矩阵（layer matrix）：九个 manifest 全部声明[package.metadata.ironclaw] layer = "kernel"，由reborn_dependency_boundaries.rs检查七层阶梯；异常注册表为空（LAYER_MATRIX_EXCEPTIONS = &[]），kernel→loops 或 kernel→products 的边无法落地。
• 每 crate 禁边（BoundaryRule）：七个 crate（trust、authorization、approvals、resources、processes、turns、capabilities）钉死阶段顺序，例如authorization不得命名approvals，capabilities不得命名host_runtime。
• 同层边被清点而非放任：reborn_same_layer_edge_inventory.rs以等式形式钉死全部 21 条 kernel→kernel 边——新边会失败，删除的边必须在同一 PR 中同步从清单移除。
• witness 密封：reborn_authorized_seal_ratchet.rs::capability_authorizer_is_implemented_only_by_the_kernel保证CapabilityAuthorizer全工作区仅由ironclaw_capabilities实现。
• 证据铸造密封：reborn_sealed_evidence_mint_ratchet.rs对铸造授权 trait 做唯一实现者普查，并钉死已退役的host-auth-mintfeature 在所有 manifest/脚本/工作流中缺席。
• 驱动托管：reborn_persistence_driver_boundary.rs按 crate 白名单化 DB 驱动，只减不增。

九大 crate 逐个拆解

ironclaw_trust——信任上限（trust ceiling）

• 目的：把 manifest 请求的信任解析为主机验证的有效上限，供每个授权决策消费。
• 管线阶段：trust ceiling。
• 拥有：在分层主机策略下评估包身份、来源与请求权威的策略引擎；同步失效（synchronous invalidation）——信任降级会在任何后续副作用发生之前使受影响的 grants 失效。
• 绝不包含：能力注册、grant 发放、调度、密钥托管、运行时执行——这个 crate 只回答"这个包被允许被信任什么"，从不回答"它现在可以做什么"。
• 公开表面：一个密封的有效信任类型，其特权变体只能由本 crate 自身的策略求值构造——不能从 wire 类型反序列化，任何调用方（无论多特权）都不能构造。源码上，EffectiveTrustClass的特权变体没有公开构造器、没有Deserialize（见 crates/kernel/ironclaw_trust/src/decision.rs），host_api侧的#[serde(skip_deserializing)]守卫 wire 半边；变更只能通过mutate_with（crates/kernel/ironclaw_trust/src/policy.rs），按来源的 mutator 为pub(crate)（crates/kernel/ironclaw_trust/src/sources.rs）。
• 依赖：仅中性权威词汇；从不依赖任何其他内核 crate、任何基底、任何 lane。
• 安全与权威角色：权威上限之门。用户安装的包无法以任何可用手段伪造特权上限；且上限本身不授予任何东西——运行在抬高上限下的 loop 或扩展仍然需要后续每一阶段的显式授权，与其他调用方完全一样。
• 为什么独立成 crate：密封是 crate 作用域可见性的性质。如果策略求值是某个更大 crate 内的模块，它的私有 mutator 会被该 crate 内所有其他模块触达；独立 crate 让"只有这段代码可以改变信任状态"成为事实，而非期望 agent 遵守的约定。

ironclaw_authorization——默认拒绝的授权决策

• 目的：把调用方的 grants 与活跃 leases 匹配到请求的效果，默认拒绝（default-deny）。
• 管线阶段：authorization decision。
• 拥有：在有效信任上限下的 grant 匹配；能力 lease 生命周期，包括"单赢家认领"（single-winner claim）——让一个恢复的、先前已批准调用可以安全地重新进入，而不会同时授予第二次调度。源码上，CapabilityLease、其状态机、CapabilityLeaseStorePort、具体 store 与过期检查都住在这里（crates/kernel/ironclaw_authorization/src/lib.rs）；指纹 leases 是单赢家"先认领后消费"（claim-then-consume），且永远不会变成环境性 grants。
• 绝不包含：审批解析、运行时调度、义务执行、或超出"grant 对上下文匹配"的任何策略内容——只回答"是否存在覆盖此效果的 grant"，从不回答"是否应该创建一个"。
• 公开表面：密封的能力 lease 携带调用指纹（invocation fingerprint）——为一个精确输入发放的 lease 永远无法授权另一个输入；lease 的状态转移本身是公开表面的一部分，因为调用方通过它们协调恢复尝试。
• 依赖：ironclaw_trust（每个 grant 必须满足的有效上限）；从不依赖 approvals、capabilities、processes、resources 或内核以上任何东西——审批解析依赖这个 crate，而不是反过来。
• 为什么独立成 crate：授权是一个与同意解析（consent resolution）不同的、可独立测试的决策——匹配静态 grant 与解析一次性人类决策是不同的问题、有不同的失败模式，且只有其中一方应该能够铸造 lease。

ironclaw_approvals——精确调用同意（exact-invocation consent）

• 目的：把 require-approval 裁决解析为有作用域、带指纹的 lease 或持久的拒绝——把人类或策略决策变成膜可以行动的东西的 crate。
• 管线阶段：approval resolution。
• 拥有：持久的审批请求与 gate 记录；fail-closed 的解析顺序——在发放 lease 之前先持久记录决策；对 manifest 显式允许复用的能力，提供持久、作用域受限的 "always allow" 策略。
• 绝不包含：UI 渲染、通知投递目标选择、或在匹配指纹的 lease 被验证并认领之前的调度。选择通知谁、如何通知是调用进这个 crate 的产品关注点，而不是反过来。
• 公开表面：approve/deny 决策类型，把带指纹的 lease 交给膜；一个与一次性 lease 不同的可复用审批记录形态，让 manifest 标记为可复用的能力不必每次调用都重新提示。
• 依赖：ironclaw_authorization（它发放 lease 的存储）；从不依赖 capabilities、host_runtime、processes、turns——膜依赖这个 crate，从不反过来。
• 安全与权威角色：人类/策略同意权威——唯一让"待决决策"变成"有作用域 lease"或"终态拒绝"的地方。拒绝对该请求是持久且终态的；调用方必须提出新请求，而非重试被拒的请求。这个 crate 的 resolver 是受认可的 lease 铸造者——该章程由阶段的 forbidden-edge 规则持有（发放端口本身是公开的），每个带指纹 lease 的构造与通过 authorization crate 的 lease-store 端口发放都在这里；lease 的存储、匹配与过期留在ironclaw_authorization。
• 为什么独立成 crate：同意解析是与 grant 匹配不同的权威，有自己的持久性与排序保证；把它并进 authorization 会模糊"这个 grant 是否适用"与"人类是否同意了这个"。

ironclaw_resources——预留与配额核算

• 目的：通过 reserve → execute → reconcile-or-release 协议治理成本、配额与稀缺运行时容量。
• 管线阶段：reservation——调度时一次，完成时再一次。
• 拥有：预留协议及其在部署关心的每个预算维度上的核算——成本、token、墙钟时间、字节、egress、进程数、并发；对跨越操作员配置上限的预留设置暂停阈值审批门（pause-threshold approval gate），与能力审批保持为不同的机器。
• 绝不包含：运行时或进程执行逻辑，或任何契约要求 fail-closed 拒绝处的"尽力核算"——预留失败永远被当作拒绝，而不是"先继续、之后再补"。
• 公开表面：由不止一个backing store 实现的预留治理器——同一协议在内存、磁盘或持久后端上运行而调用方无需知道；一个 receipt 类型闭合估算与实际消费之间的回路。
• 依赖：仅中性权威词汇；从不依赖任何调用它的 crate——resources被膜、进程生命周期和调解执行调用，它从不反向触达。
• 安全与权威角色：没有活跃预留，任何有成本或配额限制的工作都不执行；存储失败与配额拒绝以同样方式拒绝。
• 为什么独立成 crate：它是唯一在一个协议背后有多个生产 backing 实现的阶段，其平台相关问题绝不能泄漏进任何其他内核 crate 的构建。测试侧，crates/kernel/ironclaw_resources/tests/resource_governor_contract.rs 的用例（如filesystem_resource_governor_fails_closed_then_recovers_after_delta_append_error、reserve_denies_when_usd_limit_would_be_exceeded）直接验证"预留失败即拒绝"。

ironclaw_runtime_policy——纯策略解析与 lane 规划

• 目的：把部署模式、运行时 profile 与组织策略解析为每次调度都强制执行的有效运行时策略。
• 管线阶段：policy planning——折进膜自身的决策，而非独立调用。
• 拥有：单调策略解析——部署与组织策略只允许减少请求的权威，绝不增加；按能力的 lane 规划，选择给定调用被允许使用的执行 lane；任何放宽默认安全姿态的 profile 都要求显式 opt-in，让放宽的执行永远是深思熟虑、有记录的抉择，而非静默默认。源码上，无效的(deployment, profile)组合返回ResolveError而非静默降级（crates/kernel/ironclaw_runtime_policy/src/resolver.rs），放宽的*Yolo*profile 需要显式披露确认，对ProcessBackendKind::None的进程效果返回PlannerError（crates/kernel/ironclaw_runtime_policy/src/planner.rs）。
• 绝不包含：进程启动、调度、或超出 profile 解析的任何产品面策略——回答"哪个 lane 与姿态"，从不回答"运行它"。
• 公开表面：一个有效运行时策略类型，恰好一个受认可的 producer；以任何其他方式构造的值按契约不可信，下游阶段无需重新推导或质疑收到的策略。
• 依赖：仅中性权威词汇；从不依赖任何其他 crate——这个阶段是零副作用的纯计算。
• 安全与权威角色：喂给膜的策略数学之门；确定性与可复现性让审计记录能指名门控某次调用的确切策略。
• 为什么独立成 crate：它是唯一无依赖的阶段——纯策略数学运行于中性词汇之上——保持其为叶子意味着策略解析无需膜的完整服务锥也能被消费和测试。

ironclaw_capabilities——膜（the membrane）

• 目的：面向调用方的调用服务——每个特权效应必须跨越的唯一大门。
• 管线阶段：the membrane——把 trust、authorization、approval、reservation 折进一个密封决策，然后路由调度。
• 拥有：六个工作流——invoke、resume、resume-after-auth、decline-auth、resume-spawn、spawn——每个在任何副作用之前运行相同的折叠；义务接缝（obligation seam），把受限挂载视图与准备好的预留交给调解执行；运行时调度器，把密封 witness 路由到其绑定 lane，并拒绝 witness 密封 lane 与解析绑定之间的任何不匹配。README（crates/kernel/ironclaw_capabilities/README.md）明确：CapabilityHost的工作流住在src/host/的私有模块中，authorize拥有它们共同汇入的单一折叠；折叠输出是只有本 crate 能铸造的密封Authorizedwitness。
• 绝不包含：进程生命周期或结果存储、并行调度路径、或任何未按"授权 → 审批 → 义务准备"顺序通过的效果。
• 公开表面：密封的授权 witness——证明某个具体效果被授权的唯一工件，只能由本 crate 自身的折叠铸造，调度恰好消费一次。CapabilityHost实现CapabilityAuthorizer（crates/kernel/ironclaw_capabilities/src/host/mod.rs）——全工作区唯一实现，只有它能构造AuthorizationGrant(())从而密封Authorized（crates/contracts/ironclaw_host_api/src/authorized.rs）。生产调度器是RuntimeDispatcher（crates/kernel/ironclaw_capabilities/src/dispatch.rs），拒绝 witness/binding lane 不匹配。义务接缝（crates/kernel/ironclaw_capabilities/src/obligations.rs）的CapabilityObligationHandler由ironclaw_host_runtime实现。
• 依赖：其前的阶段 crate——trust、authorization、approvals、resources、runtime_policy——从不依赖调解服务 crate 或 turn 协调器；BoundaryRule禁止它命名ironclaw_host_runtime、ironclaw_secrets、ironclaw_network及一切 lane crate——方向严格是host_runtime → capabilities。
• 安全与权威角色：膜本身。没有 loop、扩展或产品面能以任何其他方式触达特权效果。授权拒绝或不受支持/失败的义务会在调度、进程启动或审批 lease 认领之前失败；审批恢复在调度前验证并认领匹配的带指纹 lease。
• 为什么独立成 crate：密封不变量——只有这个 crate 能产生授权 witness——由专门的边界测试强制执行；一个 crate 让测试恰好有一件事可检查，并让六工作流折叠作为单一单元可审查，而不是散落在攻击者首先探测的边界上。

ironclaw_processes——持久生命周期权威

• 目的：每一件主机跟踪工作的持久生命周期权威，前台或后台皆然。
• 管线阶段：claimed execution。
• 拥有：行原生日志（row-native journal），记录进程身份、谱系与状态；ProcessSupervisor——认领、租赁、心跳、恢复已注册工作，容纳 panic 并驱动有序关闭；由拥有该类工作的 crate 注册的进程种类——ironclaw_turn_runner注册 agent-turn 种类、ironclaw_host_runtime注册能力调用种类；子进程关系作为同一条日志中的边记录（而非旁表）；检查点载荷存为日志行；进程输入一旦被接受即不可变。源码上，ProcessSupervisorConfig的默认值（crates/kernel/ironclaw_processes/src/supervisor.rs）——max_concurrent_processes: 4、poll_interval: 5s、lease_recovery_interval: 10s、heartbeat_interval: 30s、max_consecutive_heartbeat_failures: 3——展示了认领/心跳/恢复的具体节奏；终态守卫（crates/kernel/ironclaw_processes/src/journal_store/state.rs）保证终态只写一次、迟到的完成无法覆盖。
• 绝不包含：能力授权或审批策略，也不对"调用方是否允许派生"发表意见——只关心派生之后发生什么。
• 公开表面：一个进程执行器端口，注册 crate 实现它以认领其种类的工作；一个进程依赖端口，用于记录与查询子关系。
• 依赖：ironclaw_resources（为跟踪的工作预留容量）、中性权威词汇；从不依赖 capabilities、host_runtime、turns、authorization、approvals、trust——其上或旁的一切只能通过它定义的端口反向触达。
• 安全与权威角色：认领执行权威；终态只写一次，迟到的完成永远不能覆盖。
• 为什么独立成 crate：一条日志回答"这件工作此刻在做什么"——前台 turn 与后台能力调用同样适用——这正是这个阶段作为单一权威而非多个存在的原因。

ironclaw_turns——turn 准入内核

• 目的：turn 准入内核——一个会话工作单元的持久入口。
• 管线阶段：admission，以及退出认领边界——loop 报告的结果在成为持久真相之前先被验证。
• 拥有：一个协调器，强制每线程单活跃 run与请求幂等——产品面快速路径去重账本之下的持久、内核侧保证；退出验证——把 loop 报告的完成、失败或阻塞当作认领（claim）而非真相，直到使用主机铸造的证据检查过它。Turn 与 run 状态不是第二个持久存储：它们是ironclaw_processes拥有的进程日志上的类型化投影，因此 turn 的生命周期与其底层进程的生命周期永远不会分裂成对"是否仍在运行"的两种不同回答。源码上，TurnCoordinator暴露 accept/resume/cancel 表面，且MAX_PREPARED_RUN_IDS: usize = 4096等常量（crates/kernel/ironclaw_turns/src/coordinator.rs）体现了准入窗口的容量纪律。
• 绝不包含：原始调度或运行时句柄、原始 prompt 或工具输入内容、密钥、主机路径、渠道身份解析。
• 公开表面：协调器的 accept/resume/cancel 表面；退出证据端口——loop 的主机适配器在接受退出认领前必须满足它。
• 依赖：ironclaw_processes（其状态投影的日志）、中性权威词汇；从不依赖任何调度、运行时或 lane crate——准入与退出验证从不直接触碰执行。
• 安全与权威角色：每线程单活跃 run，以及结构性保证——loop 无法把自己说服进一个它未被授予的持久状态转移。
• 为什么独立成 crate：准入与退出验证回答"这个 turn 是否被允许继续运行"——一个与"这次能力调用是否被允许"不同的 fail-closed 权威问题；两者有不同的调用方与不同的爆炸半径，混淆它们会让 turn 级关注点阻塞能力级关注点，反之亦然。

ironclaw_host_runtime——调解执行服务

• 目的：内核的调解执行服务——已授权 witness 与实际运行 lane 之间的边界。
• 管线阶段：mediated execution，外加完成膜准备的义务。
• 拥有：义务引擎——审计前后、网络策略分阶段、一次性密钥分阶段与消费、挂载限制、资源上限执行、输出脱敏与限制；调解的 egress 与密钥分阶段——lane 获得网络访问或凭证材料的唯一路径，永远有作用域、永远恰好消费一次；封闭 lane 执行器——只调用密封 witness 指名的 lane，别无其他；调度组装——为给定部署从内核其他服务组装膜；通过 provider 中立契约解析内存服务——具体 provider 来自组装，这里从不指名。
• 绝不包含：厂商特定工具处理器实现、沙箱进程/容器机制、产品工作流、或超出调解本身所需的任何驱动依赖。
• 公开表面：膜调用的义务处理器契约；每个运行时 lane 的网络访问都流经的调解 egress 端口。
• 依赖：内核其余部分（组装与驱动膜）、基底家族（调解的存储/凭证/网络机制）、lane 家族（构造封闭执行器适配器）、事件家族（持久审计）；从不依赖任何 extension、product 或 app crate，也不依赖任何 lane 超出其调解所经适配器表面的执行机制。
• 安全与权威角色：把一个密封 witness 变成受限挂载、分阶段凭证、有作用域 egress 下的恰好一次 lane 调用，然后把 lane 的原始输出变成追加到持久审计日志的脱敏证据。未配置的 lane 会 fail closed；凭证只在 HTTPS 或字面loopback 主机上附着（测试见 crates/kernel/ironclaw_host_runtime/src/services/tests.rs）；没有已验证的租户沙箱时，进程/能力工具被隐藏并拒绝——绝无宿主 shell。
• 为什么独立成 crate：义务完成、lane 执行、证据脱敏这一序列是每个运行 lane 同样依赖的单一原子操作；拆成更多 crate 会把一个安全关键的折叠散落到边界上而不增加隔离。

家族 AGENTS.md 的要求：内核工作的"入场规则"

crates/kernel/AGENTS.md 对每一位在这个家族工作的 agent 规定：

• 上文所示的管线图与阶段归属表，使"哪个 crate 拥有这个效果"无需从源码重新推导；
• 禁止跳阶段——first-party 是上限，不是旁路：更高的信任上限仍要求显式 grants、受限挂载、leases、预算与义务处理，走与其他调用方相同的膜；项目交付的任何东西、运行在提升信任类下的任何东西，都不得以其他路径触达特权效果；
• 每个 crate 的一行阶段指派，让新贡献首次阅读即可正确归位：trust→ ceiling，authorization→ decision，approvals→ consent，resources→ reservation，runtime_policy→ planning，capabilities→ the membrane，processes→ lifecycle，turns→ admission，host_runtime→ mediated execution；
• 家族的依赖方向重述为一条检查：内核 crate 依赖 contracts、substrate、events、closed executor 需要适配器时的 lane 家族，以及彼此仅沿阶段顺序——从不依赖loop/、product/、app/，它们只通过已定义端口或已注册执行器反向触达；
• 新增 crate 必须通过的边界测试：说出你的阶段、说出你的 fail-closed 规则或你拥有多个实现的原因——否则你就是九者之一的模块，而不是第十个 crate。

这一"关门规则"与四个密封铸造（sealed mints）相互印证：Authorizedwitness 仅由ironclaw_capabilities铸造；有效信任上限仅由ironclaw_trust::TrustPolicy::evaluate铸造；带指纹审批 lease 由ironclaw_approvals::ApprovalResolver发放进 authorization 的 lease store（决策先于 lease 持久化）；已验证入站证据由ironclaw_extension_host中同置的 ingress verifier 铸造。任何新增的Authorized/EffectiveTrustClass构造器、Default、Deserialize或测试专用逃生口，都被视为安全回归而非便利。

内核之外如何与之协作

跨出这个家族只有几种受约束的方式（见 crates/kernel/AGENTS.md 的 "Crossing out of this family"）：

• 向下到crates/contracts/（ironclaw_host_api、ironclaw_loop_contracts、ironclaw_extension_contracts）——共享词汇与内核为更高层定义的端口；turn/scope/id 词汇住在host_api::turn，绝不在这里。
• 向下到crates/substrates/——内核调解的机制：ironclaw_filesystem（挂载）、ironclaw_secrets（加密托管）、ironclaw_network（egress 传输）、ironclaw_safety。基底从不决定权威。
• 向下到crates/events/（ironclaw_event_log）——持久审计追加。
• 向下到crates/lanes/——仅从ironclaw_host_runtime，用于构造封闭执行器适配器；lanes 接收密封工作与调解服务，从不授权。
• 向上到crates/loop//crates/product/——永远不作为依赖。loop 层注册进程执行器并满足退出证据端口；产品调用ProductSurface→ 膜。如果你需要更高层的行为，在这里定义端口，让上层实现它。

对故障排查同样有用的是 docs/internal/reborn/contracts/kernel-boundary.md 第 7 节的 QA 分流框架：行为缺陷先问"内核是否未能强制执行某个权威/安全/协调保证？"——是则内核 bug，修调解契约/实现并补调用方级回归；"loop 是否在 grants 内做出了糟糕的行为选择？"——则是 loop 实现 bug，修或替换 loop 而无需改变内核保证。该契约第 8 节还列出一组内核边界验收测试：loop 无法绕过CapabilityHost、信任类本身不授予权威、用户安装代码无法自升至FirstParty/System、升级扩大请求权威需重新审批、每线程单活跃 run 在模型/工具副作用前阻塞并发、prompt 注入文件写入被扫描或 fail closed、脱敏审计记录区分内核失败与 loop 行为失败、租户/用户/项目/agent 作用域流经内核调解调用。

小结

IronClaw 内核家族的可验证要点可以压缩为一句话：loop 选择，内核许可，lane 运行，domains 记忆（"Loop chooses, kernel permits, lane runs, domains remember"）。而内核本身是一条九阶段、每阶段一 crate、全程 fail-closed 的特权效应管线：turns准入 →processes认领执行 →trust上限 →authorization默认拒绝 →approvals精确调用同意 →resources预留 →runtime_policy策略规划 →capabilities折叠成密封 witness →host_runtime调解执行。密封的 witness、密封的信任上限、带指纹的审批 lease 只能在这个家族内部铸造——loop、extension 或产品面永远无法伪造。想要深入验证，可以阅读 docs/internal/reborn/target-architecture/PROPOSAL.md（每 crate 契约 §6.5.1–§6.5.10、依赖模型 §8、机械执行 §11.2）、docs/internal/reborn/target-architecture/CHECKLIST.md（完成定义）与 docs/internal/reborn/target-architecture/PLAN.md（执行波次）；在代码侧，跑一遍cargo test -p ironclaw_architecture_tests即可让全部依赖边界、witness 密封与证据铸造棘轮可复现地验证这个外围。

• 人工智能
• AI 应用
• 交互助手
• AI Agent