From e727920bc717de0c3387a1db72f49344de946f43 Mon Sep 17 00:00:00 2001
From: NoctilumeDev <263493638+NoctilumeDev@users.noreply.github.com>
Date: Fri, 21 Aug 2026 06:33:03 +0800
Subject: [PATCH] docs: define C-first kernel charter

---
 README.md                       |  70 +++++++++++-------
 docs/architecture-hypotheses.md |  23 ++++--
 docs/c-first-kernel-contract.md | 124 ++++++++++++++++++++++++++++++++
 docs/conceptual-origin.md       |  34 +++++----
 docs/evidence-policy.md         |   3 +
 docs/experiment-roadmap.md      |  44 +++++++-----
 docs/research-questions.md      |  16 ++++-
 docs/threat-model.md            |  27 ++++---
 docs/vision.md                  |  50 ++++++++-----
 scripts/verify-repository.mjs   |   2 +
 10 files changed, 303 insertions(+), 90 deletions(-)
 create mode 100644 docs/c-first-kernel-contract.md

diff --git a/README.md b/README.md
index ac1f9e4..98ca5b7 100644
--- a/README.md
+++ b/README.md
@@ -1,23 +1,28 @@
 # FlowKernel
 
-> A long-horizon systems research repository exploring lifecycle-aware,
+> A planned C-first experimental kernel researching lifecycle-aware,
 > continuity-preserving, and AI-assisted resource scheduling.
 
 **Evidence state: Planned. Implementation has not started.**
 
-FlowKernel（流核）研究一个长期问题：操作系统能否不仅观察任务消耗了多少资源，还能理解
-任务所处的生命周期、真实进展和连续运行价值，并据此改进长期资源策略。
+FlowKernel（流核）的长期目标是构建一个以 freestanding C 为可信核心的实验性操作系统内核，
+研究操作系统能否不仅观察任务消耗了多少资源，还能理解任务所处的生命周期、真实进展和
+连续运行价值，并据此改进长期资源策略。
 
 本仓库现在只保存研究问题、架构假设、实验路线和证据规则。它不是一个已经可运行的内核，
 也不把路线图描述成已实现能力。
 
-## 核心原则
+## 实现契约
 
-> AI may propose policy; deterministic mechanisms retain enforcement authority.
+> C owns mechanism and enforcement; AI may only propose bounded policy.
 
+- **The trusted core is C-first.** 内核主体使用受限的 freestanding C；只有启动、中断入口和
+  上下文切换等硬件边界允许隔离、可枚举的最小汇编，不引入第二套策略逻辑。
+- **Lifecycle is an explicit state machine.** Spring Boot 只提供生命周期问题的启发；内核使用
+  自己的构造、绑定、启动、运行、降级、停止和回收状态，不移植应用框架。
 - **AI is advisory.** AI 负责识别状态、评估长期策略并提出动作建议。
-- **Enforcement remains deterministic.** Linux scheduler、cgroup、`sched_ext`、eBPF
-  等确定性机制负责约束和执行。
+- **Enforcement remains deterministic.** C 状态机、Guard 和有限动作执行器负责约束和执行；
+  模型缺席、超时或失效时，确定性基线仍能独立运行。
 - **Safety invariants are not learned policies.** 权限、硬资源上限、最低保障、紧急资源和
   迁移前有效检查点等约束不能交给奖励函数自行领悟。
 - **Mechanism and policy stay separated.** 学习系统可以调整策略，但不重写上下文切换、
@@ -27,7 +32,15 @@ FlowKernel（流核）研究一个长期问题：操作系统能否不仅观察
 
 ## 研究对象
 
-第一阶段不从零编写完整操作系统，而是在 Linux 提供的可控边界上研究：
+最终研究对象是自研的 C-first 实验内核，但不会一开始追求驱动、文件系统、网络和多节点
+能力齐全。工程上分成两个可比较边界：
+
+- **FlowKernel target：** 用受限 freestanding C 建立最小可启动内核、显式生命周期状态机、
+  确定性调度基线、C Guard 和可回退动作执行器；
+- **Linux reference lab：** 使用 Linux、cgroup、`sched_ext` 和 eBPF 作为传统对照组、观测
+  实验台与早期假设验证工具，不把实验台结果冒充 FlowKernel 内核能力。
+
+在这两个边界上逐步研究：
 
 - 进程、容器和长周期 Agent workload 的生命周期建模；
 - CPU、内存、I/O、网络和加速器资源预算；
@@ -42,13 +55,17 @@ FlowKernel（流核）研究一个长期问题：操作系统能否不仅观察
 ```mermaid
 flowchart TD
     state["System and workload state"] --> observe["Lifecycle observer"]
-    observe --> attention["State selection / attention"]
-    attention --> policy["Rule, planner, or learned policy"]
-    policy --> proposal["Bounded action proposal"]
-    proposal --> guard["Deterministic safety guard"]
-    guard --> control["cgroup / sched_ext / eBPF / controller"]
-    control --> runtime["Linux and hardware"]
-    runtime --> state
+    observe --> lifecycle["Deterministic C lifecycle machine"]
+    lifecycle --> baseline["Rule baseline"]
+    lifecycle --> attention["Slow-path state selection"]
+    attention --> policy["External or isolated learned advisor"]
+    policy --> proposal["Typed, bounded action proposal"]
+    baseline --> guard["C safety guard"]
+    proposal --> guard
+    guard --> control["Bounded C executor"]
+    control --> runtime["Scheduler / memory / I/O substrate"]
+    runtime --> hardware["Hardware"]
+    hardware --> state
 ```
 
 微秒到毫秒级的 **Fast Path** 继续使用确定性算法。AI 只进入秒级到分钟级的
@@ -58,14 +75,14 @@ flowchart TD
 
 | 阶段 | 研究目标 | 当前状态 |
 | --- | --- | --- |
-| R0 | 建立传统调度器、静态规则和工作负载基线 | Planned |
-| R1 | 单机生命周期观测与手写策略 | Planned |
-| R2 | `sched_ext`、cgroup 与容器控制实验 | Planned |
-| R3 | 状态筛选、Attention 与可解释观测 | Planned |
-| R4 | 模仿学习、强化学习与确定性 Guard | Planned |
-| R5 | 多节点放置、检查点、迁移与恢复 | Planned |
-| R6 | 故障注入、公平性、连续性与奖励投机验证 | Planned |
-| R7 | 面向 Agent、模型训练和推理的专项 workload | Planned |
+| R0 | 固定 C 工具链、启动契约、传统策略和 workload 对照基线 | Planned |
+| R1 | 最小可启动 C 内核与显式生命周期状态机 | Planned |
+| R2 | 确定性调度、资源回收、C Guard 与故障回退 | Planned |
+| R3 | 生命周期观测、状态筛选、Attention 与可解释性 | Planned |
+| R4 | 模仿学习、强化学习与受限动作提案 | Planned |
+| R5 | workload 连续性、检查点、迁移与恢复 | Planned |
+| R6 | 多核/多节点、故障注入、公平性和长期稳定性 | Planned |
+| R7 | Agent、模型训练和推理 workload 的对照验证 | Planned |
 
 阶段编号表示依赖关系，不代表承诺日期。每一阶段只有形成可重复实验和对照证据后，才会
 从 `Planned` 更新为 `Validated`。
@@ -73,6 +90,7 @@ flowchart TD
 ## 文档
 
 - [概念起源](docs/conceptual-origin.md)
+- [C-first 内核契约](docs/c-first-kernel-contract.md)
 - [愿景与边界](docs/vision.md)
 - [研究问题](docs/research-questions.md)
 - [架构假设](docs/architecture-hypotheses.md)
@@ -95,10 +113,12 @@ flowchart TD
 
 ## 当前不做
 
-- 不宣称正在构建可替代 Linux 的通用操作系统；
+- 不宣称当前已有可运行内核，也不宣称正在替代 Linux；
+- 不用“C 代码少”替代内存安全、并发安全、状态机和故障恢复设计；
+- 不在最小闭环前同时铺开驱动、文件系统、网络栈、多核和分布式控制；
 - 不让模型直接控制中断、时间片、内存页或内核权限；
 - 不把所有 `if/else` 机械替换为强化学习；
-- 不预选模型、算法、编程语言或分布式控制平面；
+- 不预选模型、强化学习算法或分布式控制平面；
 - 不在没有基线、随机种子和失败证据时发布性能结论。
 
 ## License
diff --git a/docs/architecture-hypotheses.md b/docs/architecture-hypotheses.md
index 2297612..95e93b6 100644
--- a/docs/architecture-hypotheses.md
+++ b/docs/architecture-hypotheses.md
@@ -2,10 +2,20 @@
 
 以下内容是待实验验证的候选结构，不是最终架构承诺。
 
+## H0：可信核心应当 C-first、最小且可旁路 AI 运行
+
+FlowKernel target 的内核主体使用受限 freestanding C。启动、中断入口和上下文切换允许
+架构必需的最小汇编，但策略逻辑不能越过 C 接口边界。内核必须在模型完全缺席时依靠
+确定性基线完成启动、运行、停止和资源回收。
+
+预期收益是控制流、ABI、内存布局和故障边界可直接审查；需要验证的代价是 C 未定义行为、
+手工所有权、并发与中断安全所带来的验证成本。
+
 ## H1：机制与策略应严格分离
 
-Linux 和确定性控制器提供有限动作：调整 quota/weight、限流、退避、暂停、恢复、检查点、
-迁移和放置。规则或学习系统只在动作集合内提出建议，不能绕过执行层。
+FlowKernel 的 C 执行器提供有限动作：调整预算或权重、限流、退避、暂停、恢复、检查点、
+迁移和放置。Linux reference lab 使用 cgroup、`sched_ext`、eBPF 和确定性控制器表达相同的
+对照动作。规则或学习系统只在动作集合内提出建议，不能绕过 Guard 和执行层。
 
 预期收益是策略可以独立迭代、回放和回滚；需要验证的代价是跨层状态同步与控制延迟。
 
@@ -14,7 +24,7 @@ Linux 和确定性控制器提供有限动作：调整 quota/weight、限流、
 Fast Path 处理即时机制，Slow Path 处理长期策略。Slow Path 超时或失效时，Fast Path 仍需
 独立维持系统运行。
 
-首个原型不会让模型参与每个 CPU 时间片决策。
+首个原型不会让模型参与每个 CPU 时间片决策，也不会把模型服务设为启动依赖。
 
 ## H3：workload 是比裸进程更合适的早期对象
 
@@ -33,7 +43,8 @@ migration_constraints
 minimum_guarantees
 ```
 
-容器、cgroup 和应用侧探针可以提供较完整的实验边界，但必须测量探针开销和错误信号。
+FlowKernel 内核事件和静态任务描述提供目标侧观测；容器、cgroup 和应用侧探针提供 Linux
+对照侧观测。两边都必须测量探针开销、错误信号和语义差异。
 
 ## H4：学习策略之前必须有规则基线
 
@@ -51,7 +62,7 @@ static rules
 
 ## H5：安全 Guard 拥有最终否决权
 
-Guard 至少负责：
+C Guard 至少负责：
 
 - 拒绝超出硬资源上限或权限边界的动作；
 - 保留内核、控制器和关键任务的紧急资源；
@@ -60,7 +71,7 @@ Guard 至少负责：
 - 在有效 checkpoint 不存在时拒绝迁移；
 - 在策略超时、异常或不可用时切回确定性规则。
 
-这些约束通过代码、模型检查或可重复测试验证，不通过 reward 间接表达。
+这些约束通过 C 代码审查、静态分析、模型检查或可重复测试验证，不通过 reward 间接表达。
 
 ## H6：Attention 只负责“看什么”
 
diff --git a/docs/c-first-kernel-contract.md b/docs/c-first-kernel-contract.md
new file mode 100644
index 0000000..a4a5a5b
--- /dev/null
+++ b/docs/c-first-kernel-contract.md
@@ -0,0 +1,124 @@
+# C-first 内核契约
+
+**Evidence state: Designed. No implementation has been validated.**
+
+本文定义 FlowKernel 未来实现必须遵守的语言、生命周期与学习策略边界。它是研究契约，
+不是已经存在可运行内核的证明。
+
+## 1. C-first 的准确含义
+
+FlowKernel 的可信核心以 **freestanding C** 实现。初始实现采用经过工具链固定的 C11 子集，
+不依赖宿主 libc、C++ runtime、语言虚拟机或垃圾回收器。
+
+“C-first”不等于“所有字节都必须由 C 编译器生成”。启动入口、中断门、上下文切换和少量
+原子指令等架构必需部分可以使用最小汇编，但必须满足以下约束：
+
+- 汇编只承担 C 无法可靠表达的硬件接口，不包含调度或学习策略；
+- 每个汇编入口都有 C 侧契约、保存寄存器说明和独立测试；
+- 汇编规模和调用边界可枚举、可审查，不允许演变成第二套内核逻辑；
+- 链接脚本、启动镜像和工具链版本属于可复现实验输入。
+
+C 提供直接且可固定的 ABI 与内存布局控制，但 C 本身不会自动带来可靠性。越界访问、生命周期
+错误、整数溢出、未定义行为、数据竞争和中断重入仍是首要风险。因此初始可信核心还必须：
+
+- 禁止隐式内存分配、无界递归、可变长数组和无法审计的宏技巧；
+- 为资源句柄定义单一所有者、借用范围和显式释放点；
+- 对所有外部长度、索引、状态和枚举做边界校验；
+- 将中断上下文、可睡眠上下文和持锁上下文写入接口契约；
+- 同时使用编译器警告、静态分析、sanitizer 宿主测试、模拟器和故障注入；
+- 把 warning 当作失败，固定工具链和编译参数，保存可重放构建证据。
+
+## 2. 生命周期不是框架移植
+
+Spring Boot 提供的是问题来源：对象和服务需要被发现、构造、装配、启动、运行、停机和
+回收。FlowKernel 借用这套生命周期思维，但不把 Spring 容器、反射或依赖注入机制搬入
+内核。
+
+初始候选状态机是：
+
+```text
+RESET
+  -> BOOTSTRAP
+  -> DISCOVER
+  -> CONSTRUCT
+  -> BIND
+  -> START
+  -> RUNNING
+  -> QUIESCE
+  -> STOP
+  -> RECLAIM
+```
+
+异常只能进入显式的 `DEGRADED`、`RECOVERING` 或 `FAILED` 路径。每个状态转换必须声明：
+
+1. 前置条件；
+2. 唯一执行所有者；
+3. 资源预算和超时；
+4. 成功后的不变量；
+5. 失败后的补偿、回滚或隔离动作；
+6. 可审计的转换原因和结果。
+
+`if`、`for` 和 `while` 足以表达控制流，却不足以自动形成正确系统。可靠性来自状态、所有权、
+预算、退出条件和失败闭环都被显式定义，而不是来自语法数量少。
+
+## 3. 确定性基线永远先于强化学习
+
+FlowKernel 首先实现一条不依赖模型也能完整运行的确定性路径：
+
+```text
+observed snapshot
+  -> deterministic lifecycle machine
+  -> rule baseline
+  -> C safety guard
+  -> bounded executor
+  -> measured result
+```
+
+强化学习只能作为 Slow Path 的策略顾问加入：
+
+```text
+versioned snapshot
+  -> external or isolated policy advisor
+  -> typed action proposal
+  -> C safety guard
+  -> accept / clamp / reject
+```
+
+学习策略不得：
+
+- 直接写内核指针、页表、寄存器、中断状态或任意调度结构；
+- 在中断、上下文切换、锁和基本内存分配路径中同步推理；
+- 绕过动作 allowlist、资源上限、速率限制和权限检查；
+- 删除、替换或关闭确定性基线；
+- 以 reward 代替 no-starvation、最低保障和恢复所有权等硬不变量。
+
+策略超时、崩溃、输出非法、版本不兼容、置信度不足或 Guard 拒绝时，系统必须在有界时间内
+继续执行确定性基线。模型服务不可用不能成为内核不可用的原因。
+
+## 4. Linux 的角色
+
+Linux、cgroup、`sched_ext` 和 eBPF 继续作为：
+
+- 传统策略对照组；
+- workload 与指标采集实验台；
+- 在自研内核机制成熟前验证生命周期假设的参考实现；
+- 用于比较开销、正确性和收益的外部基线。
+
+它们不是 FlowKernel 最终可信核心的实现语言或永久执行底座。任何在 Linux 实验台得到的结论
+都必须标注环境，不能直接声称已在 FlowKernel 内核中成立。
+
+## 5. 首个可实现边界
+
+首个内核里程碑不追求通用操作系统功能齐全，只要求形成可验证的最小闭环：
+
+- 可重复启动、停止和异常退出；
+- 固定平台上的时钟、中断和最小上下文切换；
+- 静态任务与资源描述；
+- 明确的生命周期状态机；
+- 一条确定性调度与资源回收基线；
+- 可拒绝非法建议的 C Guard；
+- 串行审计记录和宿主侧可重放测试；
+- 模型完全缺席时仍能正常运行。
+
+文件系统、网络栈、驱动生态、多核扩展、在线强化学习和分布式控制都不能挤进这个最小闭环。
+每增加一个机制，都必须先说明它回答哪个研究问题，以及失败时如何回到上一个稳定状态。
diff --git a/docs/conceptual-origin.md b/docs/conceptual-origin.md
index 2588574..3bff749 100644
--- a/docs/conceptual-origin.md
+++ b/docs/conceptual-origin.md
@@ -7,7 +7,7 @@
 
 问题最初来自应用工程中反复出现的生命周期管理：Spring Bean 由容器创建、装配、启动和
 销毁，业务服务与容器 workload 也经历启动、健康、退避、恢复和终止。继续向下观察时，
-进程、cgroup 和操作系统资源同样存在状态转换、所有权和回收边界。
+内核子系统、任务和资源同样存在构造、绑定、启动、运行、降级、停止与回收边界。
 
 这些层次都可以抽象出一个控制循环：
 
@@ -15,10 +15,14 @@
 Observe -> Represent -> Decide -> Guard -> Act -> Measure
 ```
 
-应用代码通常使用状态机、阈值和 `if/else` 完成 `Decide`。Kubernetes 等控制器使用期望
-状态与实际状态之间的差异驱动收敛。操作系统则通过确定性机制调度进程并分配资源。
-FlowKernel 的问题由此形成：当 workload 具有较长生命周期、可观测进展、检查点和恢复
-成本时，资源策略是否仍应只依赖瞬时占用与固定阈值？
+应用代码通常使用状态机、阈值、`if`、`for` 和 `while` 完成 `Decide`。Kubernetes 等
+控制器使用期望状态与实际状态之间的差异驱动收敛。操作系统则通过确定性机制调度任务并
+分配资源。FlowKernel 的问题由此形成：当 workload 具有较长生命周期、可观测进展、
+检查点和恢复成本时，资源策略是否仍应只依赖瞬时占用与固定阈值？
+
+控制语句少不等于系统天然简单。Spring Boot 真正提供的启发是把阶段、依赖、启动顺序、
+失败传播和关闭回收写成显式契约。FlowKernel 将这套思维重建为内核自己的状态机，不引入
+Spring runtime、反射或应用层依赖注入。
 
 ## 相似不等于等价
 
@@ -30,25 +34,28 @@ FlowKernel 的问题由此形成：当 workload 具有较长生命周期、可
 - 学习策略包含统计误差、分布漂移和不可解释输出。
 
 因此，FlowKernel 不是把应用框架或 Kubernetes 机械下沉到内核，也不让模型接管底层
-机制。跨层观察只用于提出问题，不能替代分层设计和逐层证据。
+机制。跨层观察只用于提出问题，不能替代 C 可信核心、最小汇编边界、分层设计和逐层证据。
 
 ## 研究假设的形成
 
 手写规则擅长表达明确不变量，但在高维观测、长期依赖和多目标权衡下可能快速膨胀。由此
-产生一个受限假设：学习方法可以尝试承担部分 Slow Path 的 `Decide`，而确定性机制继续
-负责权限、硬资源上限、最低保障、动作幅度和故障回退。
+产生一个受限假设：学习方法可以尝试承担部分 Slow Path 的 `Propose`，而确定性机制继续
+负责裁决、权限、硬资源上限、最低保障、动作幅度和故障回退。
 
 ```text
 human-defined state and actions
   -> rule baseline
   -> bounded policy proposal
-  -> deterministic guard
-  -> Linux enforcement
+  -> deterministic C guard
+  -> bounded C executor
 ```
 
 这里的“可以尝试”不是技术承诺。如果规则在效果、稳定性、可解释性或成本上更优，研究
 结论应当保留规则，而不是为了使用 AI 强行进入下一阶段。
 
+Linux、cgroup、`sched_ext` 和 eBPF 保留为 reference lab，用于观测、对照和快速验证候选
+动作；它们不是最终 FlowKernel target 的永久执行底座。
+
 ## 为什么先做 R0
 
 项目必须先建立传统调度、静态规则和可复现 workload 基线，才能回答三个基本问题：
@@ -57,13 +64,14 @@ human-defined state and actions
 2. 新策略是否真正优于更简单的方法；
 3. 收益是否足以覆盖推理、状态同步和故障处理成本。
 
-只有这些问题获得证据后，FlowKernel 才会从概念来源进入实现研究。应用层项目可以提供
-workload、故障模式和资源边界样本，但它们只是问题来源与候选控制组，不是操作系统研究
-已经成立的证明。
+R0 还必须先固定受限 C 子集、工具链、启动契约和传统对照环境。只有这些问题获得证据后，
+FlowKernel 才会从概念来源进入最小内核实现。应用层项目可以提供 workload、故障模式和
+资源边界样本，但它们只是问题来源与候选控制组，不是操作系统研究已经成立的证明。
 
 ## 与其他文档的关系
 
 - [愿景与边界](vision.md) 定义研究对象、Fast Path 和 Slow Path；
+- [C-first 内核契约](c-first-kernel-contract.md) 定义语言、生命周期、Guard 和回退边界；
 - [架构假设](architecture-hypotheses.md) 列出等待验证的结构；
 - [前人工作与阅读地图](prior-art.md) 约束新颖性判断；
 - [证据规则](evidence-policy.md) 规定状态声明和实验门槛。
diff --git a/docs/evidence-policy.md b/docs/evidence-policy.md
index 85099be..20b4dfa 100644
--- a/docs/evidence-policy.md
+++ b/docs/evidence-policy.md
@@ -20,6 +20,7 @@ README、Issue、PR、Release 和论文草稿必须使用这些词区分计划
 每项性能或正确性结论至少记录：
 
 - Commit、分支和实验脚本版本；
+- 目标架构、C 编译器、链接器、编译参数、启动镜像、模拟器与宿主环境；
 - 操作系统、内核、CPU、内存、存储和加速器；
 - 容器、虚拟化、网络和节点拓扑；
 - workload、数据规模、预热方式和持续时间；
@@ -37,6 +38,8 @@ README、Issue、PR、Release 和论文草稿必须使用这些词区分计划
 - 将请求总数写成同时并发；
 - 隐藏失败样本、随机种子或停止条件；
 - 以路线图、架构图或模型输出证明实现已经完成；
+- 以“使用 C”或“代码只包含简单循环”证明内核安全、正确或稳定；
+- 将 Linux reference lab 的结果描述为 FlowKernel target 已实现能力；
 - 仅优化 reward，却不检查饥饿和硬不变量。
 
 ## 安全与可恢复性
diff --git a/docs/experiment-roadmap.md b/docs/experiment-roadmap.md
index db97c9d..263921f 100644
--- a/docs/experiment-roadmap.md
+++ b/docs/experiment-roadmap.md
@@ -3,58 +3,65 @@
 路线图描述依赖顺序，不承诺开始时间。研究生阶段正式启动前，可以继续补充文献、问题和
 实验设计，但不使用空实现制造进度。
 
-## R0：传统基线
+## R0：契约、工具链与传统基线
 
-目标：建立可重复 workload、指标和传统策略对照组。
+目标：固定目标架构、受限 C 子集、编译/链接/模拟器工具链，并建立可重复 workload、指标和
+Linux 传统策略对照组。
 
 最低证据：
 
-- 固定硬件、内核、运行时和 workload 版本；
+- 固定硬件、宿主内核、编译器、链接器、模拟器、运行时和 workload 版本；
+- 明确 C/汇编边界、warning 策略、内存所有权规则和启动镜像格式；
 - 保存配置、随机种子和原始结果；
 - 覆盖 CPU-bound、I/O-bound、memory pressure、重试和长任务；
 - 报告平均值、分位数、波动和失败，而不是单次最好结果。
 
-## R1：生命周期观测
+## R1：最小 C 内核与生命周期状态机
 
-目标：建立 workload 状态模型和观测器，不引入学习策略。
+目标：在固定平台上建立可重复启动、停止和故障退出的最小 C 内核，完成时钟、中断、最小
+上下文切换、静态任务与显式生命周期状态机，不引入学习策略。
 
-退出条件：生命周期状态可回放，状态转换有明确来源，错误或缺失观测有降级路径。
+退出条件：每个状态转换都有前置条件、所有者、超时、后置不变量和失败路径；模型完全缺席
+时内核仍可运行；构建和启动可重放。
 
-## R2：受控执行机制
+## R2：确定性资源机制与 Guard
 
-目标：验证 cgroup、容器控制器、`sched_ext` 或 eBPF 提供的候选动作。
+目标：实现确定性调度、资源回收、有限动作执行器与 C Guard，并使用 Linux reference lab
+中的 cgroup、容器控制器、`sched_ext` 或 eBPF 建立同语义对照。
 
 退出条件：每个动作都有权限边界、最大幅度、回滚路径和开销数据；控制器失效不影响
-Fast Path 基本运行。
+Fast Path 基本运行；非法建议不能越过 C Guard。
 
-## R3：状态筛选
+## R3：生命周期观测与状态筛选
 
-目标：比较人工特征、统计选择、Attention 和完整状态输入。
+目标：建立可回放 workload 观测，再比较人工特征、统计选择、Attention 和完整状态输入。
 
 退出条件：说明筛选后的信息损失、推理成本和可解释性，不能只报告模型准确率。
 
-## R4：策略学习
+## R4：受约束策略学习
 
-目标：依次比较自适应阈值、模仿学习和受 Guard 约束的强化学习。
+目标：在内核外或隔离边界内，依次比较自适应阈值、模仿学习和受 C Guard 约束的强化学习。
 
 退出条件：在相同 workload 和预算下超过已调优规则基线，并通过非法动作、策略超时、
 奖励投机、饥饿和控制振荡测试。
 
-## R5：检查点与多节点迁移
+## R5：连续性、检查点与迁移
 
-目标：将决策对象从单机资源预算扩展到放置、checkpoint、迁移和恢复。
+目标：将决策对象从单机资源预算扩展到 checkpoint、迁移、恢复和放置。
 
 退出条件：任务身份和恢复幂等，网络分区下不产生双重执行事实，失败后可以对账和收敛。
 
-## R6：故障与长期稳定性
+## R6：多核、多节点与长期稳定性
 
-目标：验证节点失效、状态延迟、策略不可用、磁盘或网络压力以及长时间运行。
+目标：在单核最小闭环稳定后逐步验证多核并发，再验证节点失效、状态延迟、策略不可用、
+磁盘或网络压力以及长时间运行。
 
 退出条件：硬不变量零违约；所有降级、恢复和残留状态都有可审查证据。
 
 ## R7：AI workload 专项验证
 
-目标：研究编译测试 Agent、模型推理、训练或数据流水线等长周期 workload。
+目标：在 FlowKernel target 与 Linux reference lab 使用同预算实验，研究编译测试 Agent、
+模型推理、训练或数据流水线等长周期 workload。
 
 退出条件：证明生命周期信息带来的收益并非 workload 特制规则造成，且策略开销没有抵消
 收益。
@@ -67,3 +74,4 @@ Fast Path 基本运行。
 4. 资源达到宿主机停止线后停止升压，不把系统失稳伪装成算法结论。
 5. 新策略必须与简单基线使用相同资源预算和数据集。
 6. 结果同时记录成功、失败、回滚和未完成实验。
+7. C warning、静态分析告警、sanitizer 宿主测试失败和未定义行为迹象都必须进入失败证据。
diff --git a/docs/research-questions.md b/docs/research-questions.md
index 8c7a890..3787ec1 100644
--- a/docs/research-questions.md
+++ b/docs/research-questions.md
@@ -4,7 +4,8 @@
 
 ## RQ1：生命周期如何表示
 
-- 哪些状态可以由内核、cgroup、容器运行时和应用直接观测？
+- 哪些状态可以由 FlowKernel 内核事件直接观测，哪些只能由 Linux reference lab、容器运行时
+  或应用探针提供？
 - `WARMING`、`RUNNING`、`WAITING_IO`、`NEAR_CHECKPOINT`、`RETRY_LOOP`、
   `STALLED`、`RECOVERING` 等状态能否可靠区分？
 - 生命周期状态应由显式协议、统计推断还是二者组合产生？
@@ -34,18 +35,27 @@
 ## RQ5：安全边界如何保持确定性
 
 - 哪些资源上限、最低保障和权限规则必须是硬约束？
+- 受限 C 子集、资源所有权和最小汇编边界如何被持续检查？
+- 生命周期状态机如何证明不存在非法跳转、重复释放和失败后悬挂资源？
 - 如何在策略不可用、超时、输出非法或置信度不足时降级？
 - 如何证明关键任务不会因奖励函数而饥饿？
 - 如何限制动作速率，避免控制器振荡？
 
-## RQ6：多节点连续性如何验证
+## RQ6：FlowKernel 与 Linux 对照如何成立
+
+- 两边如何表达语义一致的 workload、生命周期状态和有限动作？
+- Linux reference lab 的观测与 FlowKernel target 的内核事件存在哪些不可消除差异？
+- 工具链、模拟器和真实硬件结果如何分别标注，避免跨环境外推？
+- C 内核新增机制的复杂度和故障面是否抵消策略收益？
+
+## RQ7：多节点连续性如何验证
 
 - 全局状态的一致性要求是什么，哪些信息允许延迟？
 - checkpoint、迁移和恢复的成本如何进入决策？
 - 节点分区或控制平面故障时，执行权如何收敛？
 - workload 身份、资源所有权和重复恢复如何保持幂等？
 
-## RQ7：评价体系是否完整
+## RQ8：评价体系是否完整
 
 候选指标至少包括：
 
diff --git a/docs/threat-model.md b/docs/threat-model.md
index 0c9c4e8..79a8e3b 100644
--- a/docs/threat-model.md
+++ b/docs/threat-model.md
@@ -2,7 +2,7 @@
 
 **Evidence state: Designed. No implementation has been validated.**
 
-本文档约束未来原型的安全边界。当前仓库只有文档，不存在可部署控制器或内核组件。
+本文档约束未来 C-first 原型的安全边界。当前仓库只有文档，不存在可部署控制器或内核组件。
 
 ## 保护目标
 
@@ -18,11 +18,14 @@
 | 组件 | 默认信任级别 | 约束 |
 | --- | --- | --- |
 | workload 与应用进度信号 | 不可信 | 可能错误、过期、伪造或被操纵 |
-| 内核与硬件计数器 | 有限可信 | 仍可能延迟、丢失或被错误解释 |
+| FlowKernel C 可信核心 | 可信计算基 | 必须小、可测试、可在无模型时独立运行 |
+| 最小架构汇编 | 高风险可信边界 | 只提供 C 无法表达的启动、中断和切换接口 |
+| 内核与硬件计数器 | 有限可信 | 仍可能延迟、丢失、溢出或被错误解释 |
 | Attention / 表征层 | 不可信建议 | 不获得执行权 |
 | 规则、Planner 或学习策略 | 不可信建议 | 只能输出版本化、受限动作提案 |
-| Deterministic Guard | 可信计算基 | 必须小、可测试、可旁路 AI 独立运行 |
+| Deterministic C Guard | 可信计算基 | 必须小、可测试、可旁路 AI 独立运行 |
 | 特权执行器 | 高风险可信组件 | 只接受 Guard 许可的 allowlist 动作 |
+| Linux reference lab | 外部对照环境 | 结果不能直接视为 FlowKernel 内核证据 |
 | 多节点状态与网络 | 不可信时序 | 允许延迟、重复、分区和重放 |
 
 ## 主要威胁
@@ -31,17 +34,23 @@
 2. **观测投毒**：日志、指标、标签或训练数据诱导错误表征和动作建议。
 3. **奖励投机**：策略通过饿死低权重任务、隐藏失败或频繁迁移改善单一指标。
 4. **控制振荡**：策略快速反复调整 quota、优先级或放置，造成抖动和级联退化。
-5. **权限扩大**：动作参数、BPF 程序或执行接口越过 allowlist 和 cgroup 边界。
-6. **回退失效**：模型、Guard 或控制器故障时无法恢复默认安全策略。
-7. **状态陈旧**：多节点决策基于过期状态，造成重复恢复、双重执行或资源超配。
-8. **检查点破坏**：不完整、被篡改或不兼容的 checkpoint 被用于迁移和恢复。
-9. **资源耗尽**：策略推理、遥测和审计本身耗尽 CPU、内存、I/O 或网络。
+5. **C 内存与并发错误**：越界、悬空指针、整数溢出、未定义行为、数据竞争或中断重入
+   破坏可信核心。
+6. **生命周期错误**：非法状态跳转、重复启动、重复释放或失败传播缺口造成资源泄漏与悬挂。
+7. **权限扩大**：动作参数、执行接口或 reference lab 的 BPF 程序越过 allowlist 和资源边界。
+8. **回退失效**：模型、Guard 或控制器故障时无法恢复默认安全策略。
+9. **状态陈旧**：多节点决策基于过期状态，造成重复恢复、双重执行或资源超配。
+10. **检查点破坏**：不完整、被篡改或不兼容的 checkpoint 被用于迁移和恢复。
+11. **资源耗尽**：策略推理、遥测和审计本身耗尽 CPU、内存、I/O 或网络。
 
 ## 硬不变量
 
 以下约束必须由确定性代码执行，不能只写入 reward：
 
 - 动作必须属于 allowlist，并通过身份、范围、参数和版本校验；
+- 生命周期转换必须来自当前状态允许的边，并满足唯一所有者与资源后置条件；
+- 架构汇编不能包含策略分支，C/汇编调用边界必须保存并恢复约定状态；
+- 任何外部长度、索引、枚举和句柄在使用前完成边界与生命周期校验；
 - 每个动作有最大幅度、速率限制、冷却时间和可逆路径；
 - 内核、Guard、执行器和关键 workload 保留不可被策略回收的紧急资源；
 - 最低服务保障和 no-starvation 上界必须可测量；
@@ -54,6 +63,8 @@
 ## 最低安全验证
 
 - 伪造、延迟、缺失和相互冲突的观测；
+- C 静态分析、未定义行为检查、宿主 sanitizer 测试和模拟器故障注入；
+- 非法生命周期跳转、重复释放、中断重入和上下文切换寄存器破坏；
 - 非法、越界、重放和高频动作建议；
 - 模型超时、崩溃、漂移和不稳定输出；
 - Guard 与执行器重启、磁盘压力和审计写入失败；
diff --git a/docs/vision.md b/docs/vision.md
index ad669fe..07fb747 100644
--- a/docs/vision.md
+++ b/docs/vision.md
@@ -6,8 +6,8 @@
 负载均衡。长周期 Agent、编译、测试、训练和推理 workload 则会暴露另一类问题：两个
 资源占用相似的任务，可能分别处于“接近检查点并持续收敛”和“重复失败且没有进展”的状态。
 
-FlowKernel 研究系统能否在不放弃确定性安全边界的前提下，将生命周期和长期进展加入
-资源策略。
+FlowKernel 的长期目标是构建一个 C-first 实验内核，研究系统能否在不放弃确定性安全边界
+的前提下，将生命周期和长期进展加入资源策略。
 
 核心研究问题是：
 
@@ -18,27 +18,29 @@ FlowKernel 研究系统能否在不放弃确定性安全边界的前提下，将
 
 ## “AI 操作系统”的含义
 
-本项目中的 AI Operating System 不是“由模型接管内核”。它表示在传统机制之上增加一个
-受约束的长期策略层：
+本项目中的 AI Operating System 不是“由模型接管内核”。它表示一个以受限 freestanding C
+为可信核心、以显式生命周期状态机组织资源、在慢路径接受受约束策略建议的实验系统：
 
 ```text
 Observe -> Represent -> Propose -> Guard -> Act -> Measure
 ```
 
-系统工程中的许多控制器最终都在遍历有状态实体，根据观测和规则作出动作。FlowKernel
-研究的是能否让学习策略承担一部分原本由人工阈值和启发式规则完成的 `Decide`，同时保留
-人类定义的状态空间、动作边界、安全不变量和执行主权。
+系统工程中的许多控制器最终都在遍历有状态实体，根据观测和规则作出动作。`if`、`for`
+和 `while` 可以表达控制流，但系统是否可靠取决于状态、所有权、预算、退出条件和失败闭环
+是否明确。FlowKernel 研究的是能否让学习策略承担一部分原本由人工阈值和启发式规则完成的
+`Propose`，同时由 C 状态机和 Guard 保留动作边界、安全不变量和执行主权。
 
 ## 研究边界
 
 ### Fast Path
 
 微秒到毫秒级机制必须保持确定性，包括中断、上下文切换、锁、内存页分配和基本抢占。
-模型推理不进入这些路径。
+这些机制由 C 可信核心和架构必需的最小汇编实现，模型推理不进入这些路径。
 
 ### Slow Path
 
-秒级到分钟级策略可以研究 AI 辅助，包括：
+秒级到分钟级策略可以研究 AI 辅助。策略层默认位于可信核心之外或隔离边界内，只能输出
+有类型、带版本和有效期的动作建议，包括：
 
 - 资源预算和最低保障调整；
 - workload 阶段与异常模式识别；
@@ -48,22 +50,36 @@ Observe -> Represent -> Propose -> Guard -> Act -> Measure
 
 ### 调度对象
 
-研究对象从裸进程逐步扩展为具有生命周期、依赖、健康状态、检查点和资源包络的 workload。
-容器和 cgroup 是早期实验边界，不是最终目标本身。
+研究对象从静态任务逐步扩展为具有生命周期、依赖、健康状态、检查点和资源包络的 workload。
+FlowKernel target 是最终实验对象；Linux、容器、cgroup、`sched_ext` 和 eBPF 是对照组与
+早期实验台，不是最终可信核心。
+
+### 实现边界
+
+- 内核主体使用受限 freestanding C；
+- 启动、中断入口和上下文切换允许可枚举的最小汇编；
+- Spring Boot 只提供生命周期管理的概念来源，不进入实现依赖；
+- Linux reference lab 用于验证假设和建立传统基线，不代表 FlowKernel 已实现能力；
+- 确定性基线必须先于 Attention、模仿学习或强化学习可用。
+
+详细边界见 [C-first 内核契约](c-first-kernel-contract.md)。
 
 ## 成功标准
 
 FlowKernel 的成功不以“写出多少内核代码”衡量，而以是否能够：
 
-1. 定义可观测、可复现的 workload 生命周期；
-2. 证明新策略相对传统基线改善了明确指标；
-3. 在故障、奖励投机和模型异常时守住硬不变量；
-4. 给出策略收益、推理开销和复杂度成本的完整权衡；
-5. 让失败实验同样可以复现并形成结论。
+1. 构建可重复启动、停止、回收和故障退出的最小 C 内核闭环；
+2. 定义可观测、可回放的 workload 生命周期；
+3. 证明新策略相对同预算传统基线改善了明确指标；
+4. 在内存错误、状态错误、奖励投机和模型异常时守住硬不变量；
+5. 给出策略收益、推理开销和复杂度成本的完整权衡；
+6. 让失败实验同样可以复现并形成结论。
 
 ## 非目标
 
-- 预先承诺完整自制内核；
+- 立即承诺一个可替代 Linux 的完整通用操作系统；
+- 把“使用 C”本身当作内存安全或正确性证明；
+- 在最小闭环前同时实现驱动生态、文件系统、网络栈、多核和分布式控制；
 - 用“AI”替代缺失的状态机和安全设计；
 - 只展示吞吐量而忽略饥饿、失败和恢复；
 - 把单机缩比实验描述为生产集群结论；
diff --git a/scripts/verify-repository.mjs b/scripts/verify-repository.mjs
index 904ca4d..2c04af7 100644
--- a/scripts/verify-repository.mjs
+++ b/scripts/verify-repository.mjs
@@ -10,6 +10,7 @@ const requiredFiles = [
   "CONTRIBUTING.md",
   "SECURITY.md",
   "docs/conceptual-origin.md",
+  "docs/c-first-kernel-contract.md",
   "docs/vision.md",
   "docs/research-questions.md",
   "docs/architecture-hypotheses.md",
@@ -79,6 +80,7 @@ if (!readme.includes("**Evidence state: Planned. Implementation has not started.
 }
 for (const link of [
   "docs/conceptual-origin.md",
+  "docs/c-first-kernel-contract.md",
   "docs/prior-art.md",
   "docs/threat-model.md",
 ]) {