统一 agent 平台 · 缺口模块、模块间输入输出与组合方案

版本：v1（评审稿）　公开版

本文是内部设计稿的脱敏公开版：保留模块划分、交接契约与存储规范，

移除内网地址、账号路径、模型与网关名称、仓库路径与规模数字。

本文回答四件事：

1. 在已有算力平台之上，还缺哪些模块；
2. 这些模块之间传什么（输入输出）、怎么连；
3. 文件/存储怎么规范化（布局、命名、权限、生命周期、可执行审计）；
4. 怎么把它们组合成一个系统，以及分几阶段落地、怎么验收。

这是设计评审稿，不是已实现功能的宣称。 已落地为可执行代码的只有两处，其余模块均未编码：

• 第 5.6 节的 scripts/storage_audit.py：存储审计（tests/test_storage_audit.py 23 项通过）；
• §3.9 的 scripts/incident_verify.py：判定故障是否真的修好（tests/test_incident_verify.py 55 项通过）。

它把"定位/修复可以交给模型、验证不能"这条原则变成可测函数：只有当初的检测规则重跑通过才算修好，

agent 自述只记录不生效，观测不到一律判失败。

第 2 节每一条现状都标注了本机可复现的核验方式；第 7.2 节列出明确未核实、不能当作能力的部分。凡本文写"已实现"的，指仓库现有代码或本机服务；凡写"设计"的，均未编码。

1. 一页结论

平台不是缺一个"总控 agent"，而是缺两条账本之间的连接件：

• 已有 工作/资源账本（compute-scheduler）：谁占了几张卡、任务跑到哪、租约与配额、失败与抢占。它有租约、fencing token、审计，但没有"会话"概念。
• 已有 会话账本（各 agent 自己的 home：Codex rollout、Claude project jsonl、Cursor chat 目录、DSH session）：对话内容与历史，能各自 resume。但它们彼此不知道对方的 id，也没有独占写者保护。
• agent-fleet 把五个 agent 的技能/记忆/历史检索对齐了，dsh-superagent 把触发→评估→工单→派工→回报跑通了，但两者都只覆盖了问题的一半：fleet 不理解"任务"，DSH 只调度 DSH 自己的 worker。

所以缺的不是再造一层编排，而是 6 个连接件 + 5 个补强：

关键判断（本机实测支撑，见第 2.3 节）：

1. 会话可移植性是文件系统级的，不是协议级的。 同一 runtime 换 home/换 cwd 只要把会话产物放到它查找的位置就能 resume——codex 家族、Cursor、Claude 三者实测成立（R1/R7/R10/R12）；DSH 只验证了"拒绝跨目录采用"（R14），未验证落位后可 resume。
2. provider/model 是会话的固有属性，不能静默替换。 Codex 会话记录了 model_provider，换 provider 直接拒绝；显式 -c model_provider=... -m ... 才能跨路由继续。交接必须携带路由，不能只带 session id。
3. 双写会真出事。 Codex 第二个写者报 thread-store conflict: ... already has an active writer；Cursor 直接报 Persistent chat ownership is currently changing；而 Cursor 在错误 cwd 下 resume 不报错、只是给了个空上下文——静默失败比报错更危险，必须由平台侧校验上下文回读，不能信退出码。
4. 跨 runtime 只有单向导入。 Codex 已经在自动导入 Claude/Cursor 的会话（80 条记录），但没有任何导出通道；跨 runtime 的"完整 resume"只能是"结构化重建"，不能假装是同一线程。

2. 现状盘点（事实与证据）

2.1 已有资产

2.2 五套 launcher、四类会话格式的真实形态

下面按 launcher 列（本机装了五个），但会话格式只有四类：codex 家族共用一种，Cursor / Claude / DSH 各自一种——这决定了 §3.2 只需要四个 adapter，而不是五个。

DSH 不在这五个 launcher 里：它是本机 dsh-superagent 的宿主，会话在 ~/.dsh/sessions/<slug(cwd)>/<session-id>/（session.v4.jsonl.zstd + session.lock）。它作为第四类会话格式出现在 §3.2 的 adapter 表里；落位后可 resume 未验证（R14 只验证了它会显式拒绝跨目录采用）。

codex agents 只能起 TUI（无 TTY 时报 TERM is set to "dumb" 或 stdout is not a terminal），不可脚本化；脚本化入口是 app-server 的 thread/list / thread/read，以及 codex exec --json。

2.3 resume 行为的实测结论

以下均为本机当日真实执行（均在临时目录中进行，探针会话事后已清理）：

由实测直接推出的三条设计约束：

• C1 交接 = 落位 + 路由 + 独占。三者缺一，resume 要么失败、要么静默丢上下文、要么双跑。
• C2 不能只看退出码。Cursor 在错误 cwd 下"成功"返回。平台必须做上下文回读校验（续接后问一个只有原会话才知道的事实），把通过/不通过写进回执。

但这条校验本身要诚实：它只能证明"这条会话还记得某件事"，不能证明"历史无损"。

而且校验要发一个 turn，本身就会写进会话、可能触发工具调用。所以：

• 校验必须禁用工具、只读（--sandbox read-only 或等价），并且校验那一轮要标记为校验轮，不计入任务历史；
• 回执要分开记四件事，不能合成一个 passed：identity（是同一个会话 id）、recall（记得旧事实）、

route（provider/model 真的是目标）、work（工作目录与产物还在）。四者都可能单独失败；

• 无法证明的部分（附件、工具状态、被压缩掉的历史）要写进回执的 unproven 字段，

而不是让 passed: true 暗示全都验证过了。

• C3 跨 runtime 只能重建、不能伪装。只有 Codex 具备（单向）导入；其余方向必须显式标记为 converted（摘要 + 关键产物 + 新会话），不能报成"同一会话已恢复"。

3. 缺口模块：输入、输出、依赖

约定：所有模块读写三个既有事实源，不自造第二份真相——

csched（工作/资源）、各 runtime home（会话）、orchestrator.sqlite（工单）。

新增的只有关联与索引，它们的每一行都必须可回溯到上面三者之一。

3.1 数据模型（新增两张表，放在 csched 库里）

-- 会话注册表：平台内稳定身份，指向某个 runtime home 里的真实会话
CREATE TABLE IF NOT EXISTS sessions (
  session_uid    TEXT PRIMARY KEY,        -- 平台 id：<runtime>:<native_id>（**不含 home**，见 §3.1.1）
  runtime        TEXT NOT NULL,           -- codex | codex-api | codex-ds | cursor | claude | dsh
  native_id      TEXT NOT NULL,           -- 各 runtime 自己的 id（codex uuid / cursor chatId / claude session uuid / dsh session-id）
  home           TEXT NOT NULL,           -- 最近一次已知的 home；权威位置以 session_copies 为准
  cwd            TEXT NOT NULL,           -- 记录时的工作目录（Cursor/Claude/DSH 的可达性键）
  provider       TEXT,                    -- 会话记录的 model_provider；空表示 runtime 无此概念
  model          TEXT,                    -- 会话记录的模型
  store_path     TEXT NOT NULL,           -- 会话产物在磁盘上的路径（不复制内容进库）
  title          TEXT,
  writer_state   TEXT NOT NULL DEFAULT 'free',  -- free | leased | contended（见 §3.5）
  parent_uid     TEXT,                    -- fork/导入来源
  origin         TEXT NOT NULL,           -- native | imported | relocated | converted
  size_bytes     INTEGER, turn_count INTEGER,
  last_active_at REAL, created_at REAL NOT NULL, updated_at REAL NOT NULL
);
CREATE UNIQUE INDEX IF NOT EXISTS sessions_native ON sessions(runtime, native_id);
CREATE INDEX IF NOT EXISTS sessions_cwd ON sessions(runtime, cwd, last_active_at DESC);

-- 物理副本：一次落位一行。逻辑会话（sessions）与其副本（copies）分表，
-- 否则"同一个对话在 x 处与 y 处"无法表达，锁也就锁不住两个写者。
CREATE TABLE IF NOT EXISTS session_copies (
  copy_id      TEXT PRIMARY KEY,          -- <session_uid>@<home_sha8>@<cwd_sha8>
                                          -- 必须含 cwd：Cursor/Claude 的可达性键是 cwd，
                                          -- 同一 home 下换 cwd 落位是合法操作
  session_uid  TEXT NOT NULL,             -- 指向 sessions；一个会话可有多个副本
  home         TEXT NOT NULL,
  cwd          TEXT NOT NULL,
  store_path   TEXT NOT NULL,
  content_hash TEXT,                      -- 该副本最后一次已知内容哈希（GC 与交接校验都依赖它）
  authority    TEXT NOT NULL CHECK (authority IN ('primary','stale','archived')),
                                          -- primary：runtime 正在写的位置
                                          -- stale：确实过时、可回收
                                          -- archived：人工留档，不自动回收
  last_seen_at REAL, created_at REAL NOT NULL, updated_at REAL NOT NULL
);
CREATE UNIQUE INDEX IF NOT EXISTS one_primary_copy
  ON session_copies(session_uid) WHERE authority='primary';

-- 关联：一个 job / 一个 ticket 可以先后用过多个会话（故障转移、交接、重建）
CREATE TABLE IF NOT EXISTS session_links (
  seq         INTEGER PRIMARY KEY AUTOINCREMENT,
  at          REAL NOT NULL,
  session_uid TEXT NOT NULL,
  job_id      TEXT,                       -- csched jobs.job_id
  ticket_id   TEXT,                       -- orchestrator ticket id（仅作外键语义，不跨库约束）
  role        TEXT NOT NULL,              -- primary | continuation | replacement | imported
  receipt     TEXT,                       -- JSON：交接回执（见 3.4）
  actor       TEXT NOT NULL
);

-- 交接事件：append-only，只追加不改写。描述"发生了什么"。
CREATE TABLE IF NOT EXISTS handoff_events (
  seq         INTEGER PRIMARY KEY AUTOINCREMENT,
  at          REAL NOT NULL,
  handoff_id  TEXT NOT NULL,               -- 关联到 handoff_state，事件本身不更新
  from_uid    TEXT, to_runtime TEXT NOT NULL, to_home TEXT NOT NULL, to_cwd TEXT NOT NULL,
  mode        TEXT NOT NULL CHECK (mode IN ('native','relocated','converted')),
  lease_id    TEXT, fencing_token INTEGER,
  kind        TEXT NOT NULL,                -- planned|materialized|verified|failed|abandoned|authority_switched
  detail      TEXT,                        -- JSON：该步的证据（哈希、校验结果、错误）
  actor       TEXT NOT NULL
);
CREATE INDEX IF NOT EXISTS handoff_events_by_id ON handoff_events(handoff_id, seq);

-- 交接当前状态：由事件推导出的投影，可以被更新（这就是它与事件表分开的原因）。
CREATE TABLE IF NOT EXISTS handoff_state (
  handoff_id  TEXT PRIMARY KEY,
  state       TEXT NOT NULL CHECK (state IN ('planned','materialized','verified','failed','abandoned')),
  baseline_hash TEXT,                      -- 交接那一刻的不可变基线（GC 只认它，不认"最后已知"）
  verify      TEXT,                        -- JSON：C2 的上下文回读结果
  error       TEXT,
  updated_at  REAL NOT NULL
);

3.1.1 为什么逻辑会话与物理副本必须分表

第一版把 home 编进 session_uid，于是同一个对话在两个 home 里就是两个 uid。

落位之后源与目标各持一个 uid，两个写者可以各自合法地拿到"这个会话"的锁，

而这正是 M4 要防的事。评审把这条列为阻塞项是对的。

修正后的模型：

• sessions：逻辑会话，id 只由 runtime + native_id 决定。锁、租约、session_links、

工单关联全部挂在它上面——一个对话永远只有一个锁。

• session_copies：物理副本，一个逻辑会话在几个 home 里存在就有几行；

authority='primary' 的那一行是当前权威位置，由部分唯一索引保证至多一个。

• 落位的语义因此变成"把 primary 从 A 副本切到 B 副本"，而不是"产生一个新会话"。

切换是一次带条件的更新：旧 primary 与新 primary 在同一事务内改，

失败则整体回滚，不会出现两个 primary。

authority 的三种取值是必要的：stale 表示"这份确实过时了但还留着"，

archived 表示"人工决定留档"。只有 stale 且哈希与 primary 一致时才可回收。

设计取舍：

• 不存对话内容。会话正文留在各自 home，库里只存路径、哈希、标题与统计。理由：体积（本机 Codex 会话 数 GB、数千 个文件）、隐私边界、以及"会话格式属于各 runtime"这一事实。
• session_uid 不带 home。第一版把 home 编进 id，于是同一对话在两个 home 里就是两个会话、

两把锁——落位后两个写者各自"合法"。现在 id 只由 runtime + native_id 决定，home 属于副本

（session_copies）。代价是必须显式规定 runtime 归一规则：codex/codex-api 是**同一个

runtime 的不同路由**（共享 home 与会话库），codex-ds 虽有独立 home 但会话格式相同，

归一为 runtime=codex, route=<official|vendor> 加不同 home；否则同一个对话仍会被登记两次。

• cwd 是一等字段。Cursor/Claude/DSH 的可达性由 cwd 决定（R9/R11/R14），提前存下就能在交接前判断"能否 native"。

3.2 M2 Runtime Adapter：统一能力位

一个 adapter 只做五件事，且必须先声明能力再做：

capabilities(): {
  can_list, can_read_transcript, can_resume_native, can_relocate,
  portable_unit: "file" | "dir" | "none",     # 复制什么
  cwd_bound: bool,                             # 是否要求原 cwd
  provider_bound: bool,                        # 是否把 provider 写进会话
  needs_route: bool,                           # resume 命令是否必须带 provider/model
  exclusive: "lockfile" | "ownership" | "none",
  id_from: "stdout_json" | "index" | "fs_scan"
}
list(opts) -> [SessionMeta]
read(uid, tail=N) -> TranscriptPage

# 落位分三步，缺一步就会"复制成功但 runtime 找不到"：
stage(uid, target{home,cwd})     -> StagedCopy      # 1. 复制到平台暂存区 sessions/<uid>/payload/
install(staged, target)          -> PlacementReceipt # 2. 安装到目标 runtime 真正查找的位置
                                  #    必须处理：目标已存在同名会话（冲突）、
                                  #    安装中途失败（回滚到安装前）、目标已在被写（拒绝）
resume_argv(uid, target, prompt, route) -> [argv]    # 纯函数，可单测
verify(uid, target) -> VerifyReceipt                 # C2 的上下文回读

adapter 的三个反模式（本机已踩到，必须写进实现约束）：

1. 不要把 codex 与 codex-api 当两个 runtime。它们共享 home、共享会话库，只差 provider 路由；当成两个 runtime 会重复注册同一会话（sessions_native 唯一索引会挡住，但语义仍错）。正确做法：runtime=codex，route=openai|vendor-gateway。
2. 不要用 codex agents。它要求 TTY，脚本里不可用（实测两种失败）。
3. 不要相信 Claude/Cursor 的 --resume 退出码（R11）。必须 verify。

3.3 M1 Session Registry：同步与索引

输入：list() 的结果（周期扫描 + 事件驱动补扫）。

输出：sessions 表的 upsert；给 M5 提供查询。

关键行为：

• 增量扫描：以 store_path 的 (mtime, size) 为指纹，未变则跳过（fleet history 已用同样策略，可直接复用）。
• 索引缺口要报出来：~/.codex/session_index.jsonl 441 条 < 数千个会话文件（其中 数千 个是 .jsonl.zst），说明"仅靠索引答不出全部会话"。Registry 以文件扫描为准、索引为补充（.jsonl 与 .jsonl.zst 都认），并把差异计数写进健康检查（不静默）。
• 不搬内容：store_path 是唯一定位；跨 home 落位由 M3 复制，Registry 只记录"现在有几份"。

3.4 M3 Handoff Engine：三种模式与回执

handoff(session_uid, target{runtime?, home, cwd}, route?, prompt?, lease_id?) -> HandoffReceipt

判定顺序（先便宜后昂贵，先无损后有损）：

回执（写入 handoff_events.detail，同时作为 job/ ticket 的附件）：

{
  "handoff_id": "hf_...",
  "uid": "codex:01a197b9-...",
  "from": {"copy": "codex:01a197b9-...@3f9a12c8@aa17b0e4", "home": "~/.codex",
           "provider": "openai", "model": "<official-model>", "cwd": "<探针目录>"},
  "to":   {"copy": "codex:01a197b9-...@b47d90c1@aa17b0e4", "home": "~/.codex-ds",
           "provider": "vendor-gateway", "model": "<vendor-model>"},
  "runtime": "codex",
  "mode": "relocated",
  "materialized": {"copied": ["sessions/2026/11/01/rollout-...jsonl"], "sha256_match": true},
  "route": {"provider_override": "vendor-gateway", "model": "<vendor-model>"},
  "verify": {"method": "context_recall", "question": "上一轮输出的 token 是什么",
             "expected_hash": "...", "observed_hash": "...", "passed": true},
  "lossy": [],
  "lease": {"lease_id": "l_...", "fencing_token": 7}
}

回执是这套平台的核心产品物：它把"我交接成功了"从一句话变成可复核的证据（复制了什么、哈希是否一致、回读是否通过、路由是什么、占的是哪个租约）。没有回执的交接一律记为 failed。

3.5 M4 Session Lease：独占写者

输入：handoff_state 的 planned 状态 + csched 的 lease_id/fencing_token。

输出：允许/拒绝 resume；sessions.writer_state 上的"当前写者"视图（free | leased | contended）。

与 csched 现有语义的一处必要偏离：csched 的租约过期即释放，因为远端进程本身就是它的任务； 会话锁不能这样。租约过期只说明心跳没到，不说明写者没了。所以 M4 在 csched 租约之上 多加一层"写者是否确认退出"的判断，两者都满足才放锁。这不是重复实现，是刻意更严格。

规则：

1. 一个 session_uid 同时只允许一个写者（state in ('leased','running') 的 lease）。
2. 写者身份写进 resume 命令的环境变量（如 PLATFORM_SESSION_TOKEN=<uid>:<fencing_token>），并在每次 resume 前校验 token 仍是当前值——旧 worker 晚到不得写回（与 csched 现有的 fencing 语义一致）。
3. runtime 自带的锁只能当第二道：Codex 的 thread-writer-locks、Cursor 的 ownership、DSH 的 session.lock 都是本机进程级，跨机器/跨用户都不可靠，且 Cursor 在错误 cwd 下根本不触发（R11）。平台必须自己持锁。
4. 锁的清理，按原因分两档，不能一律释放：

| 原因 | 是否释放 | 说明 |

|---|---|---|

| 进程已确认退出（进程层面证据） | 释放 | 唯一可以自动释放的情况 |

| handoff_state.state='failed'，且确认无存活写者 | 释放 | 只有"进程从没起来"或"进程已确认退出"才算；failed 本身只表示交接失败，不表示没有写者。resume 已经起了进程再失败（如 verify 不过）就是反例 |

| 租约超时 | 不自动释放 | 超时只说明"我没收到心跳"，不说明进程没了；转 contended |

| 主机失联 / SSH 不可达 | 不自动释放 | 见下表，这是最容易误判的一种 |

卡住的锁要有 TTL 与"强制接管"审计（接管必须是 human，且记录谁、为什么）。

TTL 到期只产生"可以接管"的提示，不自动放锁——自动放锁等于自动制造双写者。

这条规则有一个本文尚未解决的缺口，必须写明而不是留给实现时发现：

fencing token 只能保护经过平台的写入。会话产物是 runtime 自己写磁盘的：

一个被判定失联、租约已回收的旧进程，如果还活着，它的写入不经过平台校验，

-platform 无法拒收。因此「旧 worker 不得写回」在会话场景下不是靠 token 保证的，只能靠先杀进程再放锁。

据此 M4 的实际语义分两种，且不能混称：

一条必须写死的纠错：SSH 不可达 不是"进程已退出"的证据，而是最危险的反例。

网络分区、隧道断开、跳板机故障、目标机负载过高都会让 SSH 失败，而这些场景里旧进程

往往正在正常写会话文件。把"连不上"当成"没在跑"，等于在最需要互斥的时候放开第二个写者。

可达性只能证明"我现在控制不了它"，不能证明"它没在写"。

contended 是一个必须存在的状态：它诚实地表示"我们知道可能有两个写者，且我们没有解决"。

把它和 ready 混在一起，就是本文反复强调的那种"看起来成功"的失败。

3.6 M5 Work Link：两条账本的连接

跨库不做分布式事务。 DSH 与 csched 各自提交，用幂等键 + 补偿扫描收敛：DSH 写 link 失败则在下一次 tick 重试；csched 找不到对应 ticket 时保留孤儿 link 并在看板"异常"里挂着，不静默删除。

3.7 M6 Unified Gateway：一个入口

输入：CLI / HTTP /api/v1/... / MCP tool。

输出：与直接调 csched 完全相同的对象（同一份状态）。

platform submit   --runtime codex-ds --gpus 0 --command "..." --session-policy reuse|new|any
platform sessions [--runtime --cwd --job --ticket] [--stale]
platform resume   <session_uid> --target codex-ds --cwd <dir> [--prompt-file f] [--lease ...]
platform handoff  <session_uid> --to cursor --cwd <dir> [--convert]
platform link     --job <id> --ticket <id>
platform verify   <session_uid>            # 上下文回读校验（C2）
platform health                            # adapters 能力位 + 索引缺口 + 锁占用

MCP 工具（csched 目前没有，属于补强）：

platform.list_sessions(filters)        platform.resume(session_uid, target)
platform.submit_work(spec)             platform.work_status(id)
platform.handoff(session_uid, target)  platform.quota_status()

权限边界（沿用 csched 现有三档 token，不新造）：

• agent token：可读会话、提交自己的工作、恢复自己持有租约的会话；
• human token：可强制接管锁、可交接他人会话、可设置 converted 策略；
• read token：看板只读。

3.8 四个补强（M7–M10）

M7 Agent 注册：csched agents 现在是空的。每个 agent 启动时上报

{agent_id, kind, runtime, home, provider, model, host, cwd, capabilities{tools, sandbox, max_concurrency}}，

心跳 60 秒。用途：交接前判断"目标 runtime 是否在线、能否用这个模型"（否则就是 R4/R5 的失败）。

M8 事件与通知：把三类事件统一成 {at, actor, kind, object_id, payload, seq}：

csched 的 events（已有、append-only）、DSH 的 outbox 回执（已有）、fleet 的扫描事件（无，需补）。

对外只提供可补读的游标（since=seq）与去重键（kind+object_id+seq），不承诺"必达"。

M9 凭据与路由：每个 runtime 的 provider 定义不同（R4 的教训）。

路由描述必须包含 launcher + profile + provider + model + credential_file，

交接时整块搬运，只搬配置位置、不搬密钥内容（沿用 registry.py 的凭据检测与 agent-fleet/maas-key 单文件模式）。

3.9 M11 故障自愈：自动修到好，并由确定性复检确认

用户要求：出现故障后能自动触发 agent 定位问题并解决。这一节先说清已经有什么，再说缺什么， 否则会重复造已经存在的部件。

3.9.1 已有的那一半（本机实测，2026-11-02）

这条链路是能用的：已有若干工单闭环，其中一单真的找出了控制面的缺陷（见 3.9.8）。

3.9.2 缺的那一半（同一时刻的实测数字）

3.9.3 M11 的五个阶段与契约

detect ──► locate ──► repair ──► verify ──┐
  ▲            ▲                          │ 未通过
  │            └────── 换一种诊断 ◄────────┤（同类失败达阈值）
  │                                       │
  └────────── 退避后继续 ◄────────────────┘
                     │ 只有下列情况才停
                     ▼
                告知人（停手原因）+ 保持 open

核心原则：locate 和 repair 可以交给模型，verify 绝不能。

验证必须回到当初检测到故障的那条判据上重跑一次（同一探测、同一阈值、同一对象）。

模型说"已修好"只作为 Diagnosis 的一部分记录，不作为关闭工单的依据——这正是本文反复强调的

"不要用 agent 的自述替代证据"。

3.9.3.1 修到好为止：重试没有次数上限

第一版这里写的是"连续失败 3 次即升级、不再自动重试"。那是错的，它和"故障要被持续修好"直接冲突：

一个还在坏着的故障，因为"试了三次"就退出队列，和修好了在表面上没有任何区别——

队列变干净了，系统还是坏的。

正确的边界不是次数，而是原因。自动重试只在以下三种情况下停：

三条都不是"我们试过但没成功"。失败本身永远不构成放弃的理由。

配套的三条机制：

1. 退避到上限而不是退避到停止。第 N 次失败后等待 min(60s × 2^(N-1), 6h)，

一个断掉的隧道会每几小时重试一次，永远——而不是试三次之后被遗忘。

1. 同类失败要换诊断，不是加大力气重试。同一 signature 的修复连续失败 3 次，

说明诊断错了而不是运气差；此时回到 locate 拿新假设，而不是把同样的动作再做一遍。

这是"持续修"和"死循环"的分界线：修的是方法，不是重试次数。

1. 只有人能把故障判为不修。wontfix 必须由人写入并带理由；系统自己无权把一个

open 的故障标成"就这样了"。

核心原则：locate 和 repair 可以交给模型，verify 绝不能。

验证必须回到当初检测到故障的那条判据上重跑一次（同一探测、同一阈值、同一对象）。

模型说"已修好"只作为 Diagnosis 的一部分记录，不作为关闭工单的依据——这正是本文反复强调的

"不要用 agent 的自述替代证据"。

3.9.4 数据模型增量

-- 故障事件：一次故障一行，与维护工单是 1:N（同一故障可能被处理多次）
CREATE TABLE IF NOT EXISTS incidents (
  incident_id  TEXT PRIMARY KEY,
  kind         TEXT NOT NULL,              -- unreachable | deploy_failure | lease_stuck | quota_exhausted | ...
  subject      TEXT NOT NULL,              -- resource_id 或 job_id
  signature    TEXT NOT NULL,              -- 根因指纹：kind+subject+归一化错误串的哈希，用于合并同类
  detected_at  REAL NOT NULL,
  detect_rule  TEXT NOT NULL,              -- 当初触发的那条判据，verify 必须复用它
  detect_args  TEXT NOT NULL,              -- JSON：阈值、探测目标、期望值
  state        TEXT NOT NULL CHECK (state IN
                 ('open','diagnosing','repairing','verifying','resolved','wontfix')),
                                          -- 没有 escalated：系统无权放弃一个仍 open 的故障
  severity     INTEGER NOT NULL DEFAULT 10,
  verify_attempts INTEGER NOT NULL DEFAULT 0,
  repair_attempts INTEGER NOT NULL DEFAULT 0,
  updated_at   REAL NOT NULL
);
CREATE UNIQUE INDEX IF NOT EXISTS one_open_incident_per_signature
  ON incidents(signature) WHERE state IN ('open','diagnosing','repairing','verifying');

三条设计约束：

1. signature 去重。同一 kind+subject+归一化错误 只允许一个活跃 incident。

重复的 deploy 失败应合并成少数几个 incident，而不是几十张单。

1. detect_rule + detect_args 必须落库。没有它们，verify 就退化成"再跑一次 agent 看看"，

而那正是当前失败模式。

1. 维护工单变成 incident 的执行记录，不再是独立实体：maintenance_jobs 加 incident_id，

一单对应一次 repair 尝试。这样"同一故障试了 3 次"是查得出来的。

3.9.5 修复的授权分级：L1/L2 默认开启

默认只读让"解决问题"永远做不到——agent 只能诊断，故障永远留在原地。

用户已明确要求尽可能自动修复、减少人的参与，因此 L1 与 L2 默认开启，L3 永不开。

判据只有一条：坏了能不能自己长回来。隧道、服务、租约"重连即可"，可以自动；

共享机器上的进程状态不由我们定义，必须人确认。这条线写死，不交给模型判断。

四条实现约束（已落地为 scripts/incident_verify.py）：

1. 故障族 → 级别是显式映射，不是推断。新故障类型默认 L0（只读），

必须有人给它的影响面定级后才会自动修。默认值取安全的那个方向。

1. L3 打开会直接抛异常，不是静默忽略——避免某天有人"顺手"把共享机器加进自动列表。
2. 每个自动动作必须先有回滚方案。restart_unit/reconnect_tunnel/retry_job/rebuild_lease

都有对应的 undo；没有 undo 的动作一律要求人工，而不是"先做了再说"。

1. 冷却防修复风暴。一秒钟重启八次本身就是一次故障；L1 冷 60 秒、L2 冷 300 秒。

每次自动动作写一条审计：{级别, 动作, 回滚方案, 第几次尝试, 检测规则, 复检结果, 执行者}。

审计里必须能回答"这个动作为什么被允许"，而不只是"做了什么"。

3.9.5.1 修完之后怎么测：每类故障的判定规则

"再检查一下"不是规则。规则必须写成 判据 + 期望值 + 数据来源，并且只能用当初触发故障的那条判据。

下表每一行都已落地为 scripts/incident_verify.py 中的同名函数，并有对应测试。

三条硬规则：

1. 故障族与复检规则必须匹配。deploy_failure 配上 unreachable 的规则，会去问一个

与故障无关的问题——可能故障还在却判通过，也可能真修好了却永远判失败。两者都比"拒绝验证"更坏，

所以不匹配时直接拒绝验证并标失败。

1. 指标缺失 = 失败，不是跳过。quota available=None、heartbeat_age 读不到，都判不通过。

"没测到"和"没问题"必须分开。

1. 只读复检。复检本身不得写会话、不得触发工具调用、不得改状态；它发的是一个只读探测。

否则"验证"会制造新的副作用，甚至自己把故障修好了再宣布通过。

还有一个必须承认的边界：复检查的是"故障现象是否消失"，不是"根因是否消除"。

隧道重连后通过，不代表导致断开的那个原因（比如证书快过期、跳板机内存泄漏）解决了；

所以同一 signature 复发会计入 regressed 并立刻汇报，而不是当成新故障。

3.9.6 并发与积压（当前最痛的一条）

现状是每 30 分钟只处理 1 单，而积压远大于此。改为：

• 按 severity 与 age 调度，不是 FIFO：P0（服务本身不可用）立即跑，P3（历史失败任务）批量处理；
• 同类合并：同一 signature 的 N 张单只跑一次诊断，其余引用同一次结果；
• 有界并发：max_concurrent_repairs（默认 2），因为同时改两处更容易把状态搞乱；
• 失败退避：按 §3.9.3.1 的指数退避继续重试，不因次数停止；只有三种“原因”会停手并告知人。

3.9.7 验证：故障注入，不是"跑一遍看看"

3.9.8 已确认的现实缺陷（由现有维护 agent 自己发现）

repair-manaenv-editor-slot0-129-140 的结论指出：控制面 probe_all() 的 _has_endpoint()

只认 kind ∈ {ssh, local}，而该资源是 kind=http，于是每个 tick 都被 skipped，health 永远为空。

已复核为真：endpoint 为 http 的资源共 2 个，_has_endpoint 均返回 False，health 均为空。

这说明自愈链路本身能产出真实缺陷——但也暴露闭环缺失：这个发现写在工单的 summary 文本里，

没有任何机制把它变成一个带负责人的待修项。M11 的 Diagnosis 应当能产出这种"顺带发现的缺陷"，

并允许它转成 incident 而不是埋在一段中文里。

3.9.9 汇报：让人知道有漏洞，而不是刷屏

要求是"有漏洞要汇报给我"。这里有两个失败模式，必须同时避开：

• 不报：故障坏了几天没人知道——这正是当前 summary 里那句缺陷发现的处境；
• 全报：每次重试都发一条，人很快把它静音，之后真故障也看不到。

所以按事件类型决定报不报，而不是按"有没有新消息"：

消息只写三件事：哪里坏了、现在什么状态、下一步是什么。

不写尝试了几次、跑了什么命令——那些属于记录，不属于通知。

一次重试失败不是新闻，一个还在坏的故障才是。

消息形态（真实存在的失败例）：

发现故障：<对象> 出现<故障类型>，已开始自动定位与修复。
<对象> 仍在：复检未通过（<具体判据>），会继续修。
<对象> 的<故障类型>已修复，复检通过。
<对象> 修不动了：<停手原因>。已尝试 N 次，需要你决定下一步。

"已修复"只能由复检结果触发，不能由 agent 的话触发。 否则汇报本身就成了

"把没修好的说成修好了"的通道——那是比不汇报更坏的结果。

3.9.10 顺带发现：自愈过程本身就是缺陷来源

维护 agent 在自己的结论里报告了 _has_endpoint() 不认 kind=http 的缺陷（见 3.9.8）。

这类"修 A 的时候发现 B 坏了"是自愈系统的高价值副产品，但当前它只存在于一段中文

summary 里，没有任何机制把它变成待办。

M11 要求 Diagnosis 带一个 side_findings[] 字段：诊断过程中发现的、与本工单无关但确实存在的缺陷。

它们不改变当前 incident 的状态，但会各自生成新的 incident（走同一套 detect→verify 流程），

并按 §3.9.9 的规则合并进同一条汇报，而不是再发一条消息。

这条的价值在于：系统的缺陷发现能力不再取决于有人恰好读了某条日志。

4. 模块间连接：数据流

4.1 组件与连接（谁调谁）

                      ┌────────────────────────────────────────────────────┐
 人 / agent / CI ────► │ M6 Unified Gateway  (CLI · HTTP /api/v1 · MCP)      │
                      └───┬───────────────┬────────────────┬───────────────┘
                          │               │                │
        ┌─────────────────▼──┐   ┌────────▼─────────┐  ┌───▼──────────────┐
        │ M5 Work Link       │   │ M3 Handoff Engine │  │ M7 Agent Registry│
        │ job↔session↔ticket │   │ native/relocated/ │  │ 谁在线、什么模型  │
        │ ↔artifact          │   │ converted + 回执  │  │ 什么权限         │
        └───┬────────────┬───┘   └───┬──────────┬────┘  └───┬──────────────┘
            │            │           │          │           │
   ┌────────▼──────┐ ┌───▼───────────▼──┐  ┌────▼───────────▼──────────────┐
   │ csched 控制面  │ │ M1 Session        │  │ M4 Session Lease              │
   │ jobs/leases/  │ │ Registry          │  │ 独占写者 + fencing token      │
   │ quota/events  │ │ sessions/links    │  │ (复用 csched 的租约语义)       │
   └────────┬──────┘ │ handoffs          │  └────┬──────────────────────────┘
            │        └───┬───────────────┘       │
            │            │                       │
            │     ┌──────▼───────────────────────▼──────┐
            │     │ M2 Runtime Adapters (每个 runtime 一套)│
            │     │ codex · cursor · claude · dsh         │
            │     └──┬────────┬─────────┬─────────┬──────┘
            │        │        │         │         │
            │   ┌────▼───┐ ┌──▼────┐ ┌──▼─────┐ ┌─▼──────┐
            │   │~/.codex│ │~/.cursor│ │~/.claude│ │~/.dsh  │
            │   │+ -.codex-ds│      │         │  │sessions│
            │   └────────┘ └───────┘ └────────┘ └────────┘
            │
   ┌────────▼─────────────┐        ┌──────────────────────────────┐
   │ dsh-superagent       │◄───────┤ 通知/回报（M8 事件游标+去重）  │
   │ ticket/assignment    │        └──────────────────────────────┘
   └──────────────────────┘

4.2 一次"派工 → 交接 → 恢复"的时序

调用方            Gateway        Work Link      Handoff        Lease        Adapter/Runtime
  │                  │               │             │             │              │
  │ submit(work,     │               │             │             │              │
  │  session_policy= │               │             │             │              │
  │  reuse)          │               │             │             │              │
  ├─────────────────►│               │             │             │              │
  │                  ├── jobs(POST) ──────────────────────────────────────────► csched
  │                  │               │             │             │              │
  │                  ├── 选会话 ─────►│ 查 sessions │             │              │
  │                  │               │  (runtime,  │             │              │
  │                  │               │   cwd, 最近) │             │              │
  │                  │               │             │             │              │
  │                  ├── handoff(uid,target) ─────►│             │              │
  │                  │               │             ├── 申请租约 ─►│              │
  │                  │               │             │◄─ lease+token             │
  │                  │               │             ├── materialize ────────────►│ 复制产物
  │                  │               │             ├── resume_argv ────────────►│ 起进程
  │                  │               │             ├── verify(上下文回读) ─────►│
  │                  │               │             │◄── passed/failed           │
  │                  │               │◄── link(job,session) ────┤              │
  │◄─ 202 job_id ────┤               │             │             │              │
  │                  │               │             │             │              │
  │  ... 进程崩溃 / 机器失联 ...                     │             │              │
  │                  │               │             │             │              │
  │                  ├── 检测 attempt failed ──────►│             │              │
  │                  │               │             │             │              │
  │   ┌──────────────┴───────────┐   │             │             │              │
  │   │ 进程已确认退出？          │   │             │             │              │
  │   └──────┬──────────────┬────┘   │             │             │              │
  │      是  │              │ 否/未知（含机器失联）  │             │              │
  │          ▼              ▼        │             │             │              │
  │   释放旧租约      标 contended    │             │             │              │
  │   新 attempt      不释放、不重启   │             │             │              │
  │   relocated/      等人工接管      │             │             │              │
  │   converted       或旧进程确认退出  │             │             │              │
  │          │              │        │             │             │              │
  │          └──────┬───────┘        │             │             │              │
  │                 ▼                │             │             │              │
  │           新回执（含 lossy 与 contended 原因）  │             │              │

4.3 关键接口契约（跨模块）

5. 存储与文件管理规范（M10）

这一节回答"文件怎么存、存哪、谁能删、留多久、怎么验"。它是所有其他模块的前置契约：M1 记录路径、M3 复制会话、M5 关联产物、M8 事件落盘，都必须遵守本节的布局与权限；否则"能 resume"很快会变成"到处是副本、不知道哪份是真的"。

5.1 为什么要单独成节（本机实测的账）

不治理的代价不是理论问题，本机已经发生：

5.2 目录布局（平台根的唯一形状）

平台根默认 <平台根>/（沿用本机 ~/.local/share/ 惯例；$PLATFORM_HOME 可覆盖）。一个根，固定七个子类，不允许在根下再长出别的目录：

$PLATFORM_HOME/                    0700  平台根
├─ state/                          0700  可写、可并发、必须备份
│   ├─ platform.db                 0600  sessions/copies/links/handoffs（§3.1）
│   ├─ platform.db-wal/-shm        0600  SQLite WAL
│   └─ locks/                      0700  单实例锁
├─ secrets/                        0700  只放位置与权限，绝不复制
│   ├─ <runtime>.token             0600  agent token
│   └─ README.md                   0600  每份凭据的用途与轮换方式（不写值）
├─ sessions/                       0700  relocated 会话副本（源 home 不归这里管）
│   └─ <session_uid>/              0700
│       ├─ payload/                0700  复制来的会话产物（保持原相对路径）
│       ├─ receipt.json            0600  交接回执（§3.4）
│       └─ meta.json               0600  runtime、home、cwd、provider、model、哈希
├─ artifacts/                      0700  任务产物，一个 job 一个目录
│   └─ <job_id>/                   0700
│       ├─ manifest.json           0600  清单：文件名 + 字节数 + sha256 + 来源
│       └─ files/                  0700  实际产物
├─ evidence/                       0700  proof 类材料，append-only
│   └─ <yyyy-mm-dd>/<用途>/         0700  before/after 成对命名（见 5.3）
├─ logs/                           0700  服务与任务日志，按天切
│   └─ <service>/<yyyy-mm-dd>.log  0600
└─ scratch/                        0700  可随时清空；重启后允许为空

规则：

1. 类目即策略。一个目录属于哪个类，决定它的权限、保留期与预算；不允许"临时放一下"到别的类里。
2. 不嵌套别的类。artifacts/<job>/ 里不允许再出现 logs/ 或 sessions/ 语义的子树；跨类引用走 manifest.json 的路径字段。
3. 不跟随软链。审计与回收都不跨软链（避免把 ~/.codex 整个拖进清理范围）。
4. 只在本机。平台根不出现在远端机器；远端的任务根沿用 csched 既有约定 ~/.compute-tasks/<job_id>/（compute_scheduler/bootstrap.py 的 TASK_ROOT_NAME），任务结束由 cleanup() 删除并留回执。
5. secrets/ 只存位置。凭据值仍留在各自既有位置（<凭据文件>（0600）、<令牌文件>（0600）、各 home 的 auth.json），平台侧只记录"它是哪份、谁能读、怎么轮换"。

5.3 命名规范

证据成对：UI 或行为类证据必须成对存放（before-/after-），并在 manifest.json 里写明基线与变更后的 revision；只有 after 的证据视为不完整（与本机既有证据命名一致，如 ops/evidence-20261101/）。

5.4 权限矩阵（谁能读、谁能写、谁能删）

硬规则：

• 不存在 0664/0775。本机实测存在（见 5.1），属待修而非"以后注意"。审计工具会把它们打成 file_permissions/dir_permissions。
• 权限位不是授权模型，只是一道兜底。同一个 UID 下运行的 agent 与人类进程，0700/0600 拦不住任何一个：

它只挡住其他 UID。所以上表的"agent 只读 / 人类读写"是平台接口层的约定，

由 token 档位（agent/human/read）强制，文件权限只保证"别的用户看不见"。

若真需要进程级隔离，只能靠独立 OS 账号或容器——那是另一层，本文不声称已经具备。

同理，"只追加"不是文件系统能力，而是 storage.write 的实现约束（同名即拒）。

• 可执行文件 0700，不允许 0755：run.sh 只需属主可执行。
• 不写 world/group 位。共享靠平台接口，不靠文件权限"图省事"。
• secrets/ 写入由人类或 install.sh 完成，agent 只读；agent 需要新凭据时报告缺口，不自行落盘。

5.5 生命周期：创建 → 使用 → 回收

创建：mkdir 0700 + umask 077（与 bootstrap.py 现有做法一致）
  │
使用：只在自己的类内写；跨类只读；append-only 类同名即拒绝
  │
结束：写 manifest/receipt → 关掉租约与锁 → 进入保留期
  │
回收：gc_plan 列出超期文件 → 人工/定时任务确认 → 删除 → 写回执

保留期（默认值，可按类调整）：

三条附加规则：

1. 先有回执再删。删除必须能回答"删了什么、为什么、谁批的"；gc_plan 只产出计划，删除是独立动作。
2. append-only 永不回收。evidence/ 的旧文件只能被更新的证据取代语义，不能被 gc 删除。
3. 超预算先报警再动手。超过类预算 25% 报 error，其余超出报 warn；不允许静默删用户的证据或产物。
4. 副本何时才真是副本（这一条推翻"30 天到期就删"的直觉）。

relocated 交接之后，目标 runtime 会继续往它自己 home 里的那份会话写：那份成了对话的新家，

而平台 sessions/<uid>/payload/ 里的暂存副本只是复制那一刻的快照，不会再被任何人写。

这两者必须分开看，否则会得出两个都错的结论：

• 把暂存副本当"新家"→ 会以为它一直在变，永远不敢删（第一版的毛病）；
• 把 runtime home 里的那份当"平台的副本"→ 会把它纳入 GC 范围，那是删掉真实历史。

GC 只管平台自己的 sessions/ 暂存区，绝不碰任何 runtime home。

而暂存副本能否删，取决于目标 home 里那份权威副本是否已经独立成立（见下）。

因此 sessions/ 的回收必须满足全部条件才允许：

• 它对应的 session_copies.authority 不是 primary（权威位置已切到目标 home，平台暂存区降为 stale）；
• session_links 里没有指向它的活跃 job（没有租约、没有 running 的 attempt）；
• 它最近 last_active_at 已超过 30 天；
• 存在一个与待删副本内容完全一致的另一个位置，且这个判断有不可变基线可依。

这一条第一版写错了两次，记录在此以免再犯：

• 错法一："源还在、哈希没变就能删副本"。副本被续写之后，源恰恰因为没变而过期。
• 错法二："副本当前哈希 == 最后登记哈希，说明没被续写"。这也不成立：扫描器

每轮都会把续写后的哈希登记回去，于是续写过的副本同样"等于最后已知"。

正确做法是交接基线不可变：handoff_state.baseline_hash 在交接那一刻写入、此后

永不更新。删除副本前要求：另一副本（或源）当前的哈希 == baseline_hash，

并且待删副本自基线以来没有新写入。基线之后两边都动过，就没有任何一方能证明

自己包含全部历史——此时不回收，交给人判断。

还有一条不能省：核验与删除之间不得有写入，而"删除前再算一次哈希"不是这个保证。

重算只能检测"两次计算之间"的写入，检测完到 unlink 之间仍有窗口；那不是消除了竞态，

只是把窗口缩小到看不见。

唯一正确的做法：在整个"核验 → 删除"窗口内持有该会话的写者锁（M4），

没有锁就不删——哪怕因此留下一个过期副本。删一个多余副本的代价是磁盘，

删掉唯一历史的代价是不可逆。GC 没有"拿不到锁就硬删"的选项。

三条任一不满足就不回收，并把原因写进 gc_plan 的输出。只在时间上做判断的 GC，

删掉的会是唯一一份真实历史。

1. 写满时怎么办，必须先决定。三类的行为不同，不能都用"报警"：

| 情况 | 行为 |

|---|---|

| artifacts/ 或 sessions/ 将超预算 | 拒绝新的写入/新的交接（快速失败），并报警；不自动删旧的 |

| logs/ 超预算 | 按天滚动并删最旧的（日志可再生） |

| scratch/ 超预算 | 直接清空 |

| 磁盘整体水位 > 90% | 停止一切新的 relocated 交接（因为它是磁盘增长最快的操作），报警 |

不写清这条，实现时就会有人"顺手删点东西"来腾空间，而那正是唯一一份历史的所在。

1. 预算数字是可调常量，不是测出来的。上表的数字取自本机现状的数量级（单个 agent 会话已 数 GB）加上一个宽松倍数，用来触发讨论，不是容量规划结论；真正落地时应按实测增长调整，并把调整记进审计。

5.6 M10 的接口（给其他模块调用）

storage.path(cls, *parts) -> Path            # 只允许拼七类之内的路径，越界即异常
storage.ensure(cls, *parts) -> Path          # mkdir 0700 + 校验父类存在
storage.write(cls, *parts, data, mode=0o600) # 原子写（tmp + rename），append-only 类同名即拒
storage.manifest(job_id) -> dict             # 生成/校验清单（文件名、字节、sha256）
storage.verify(manifest) -> VerifyReceipt    # 逐文件核哈希；缺失/变动即 failed
storage.audit(root=None) -> AuditReport      # 全部七类的权限/预算/清单审计
storage.audit_uniform(root) -> AuditReport   # 对既有 agent home 只读审计（不改结构）
storage.gc_plan(now=None, live=(), sources=(), baseline_hashes={}, locked=()) -> [plan]
                                             # 只产计划；live/sources/baseline_hashes/locked 决定合规不可删

实现见本工作区的 scripts/storage_audit.py（tests/test_storage_audit.py 23 项）；

它只依赖标准库，拿到这两个文件即可在任何 Python 3.11+ 上复跑：python3 -m pytest tests -q。

可直接跑：

python3 scripts/storage_audit.py "$PLATFORM_HOME"            # 全类审计
python3 scripts/storage_audit.py "$PLATFORM_HOME" --json     # 机器可读
python3 scripts/storage_audit.py "$PLATFORM_HOME" --gc-plan  # 附带回收计划
python3 scripts/storage_audit.py --uniform ~/.codex/sessions # 只读审计既有 home

对外稿以占位示例代替真实输出：

$ python3 scripts/storage_audit.py --uniform "<某个 agent home>/sessions"
uniform    dirs=165 files=<N>  bad_dirs=68 bad_files=<多数文件>

$ python3 scripts/storage_audit.py --uniform "<另一个 agent home>/chats"
uniform    dirs=60 files=<M>  bad_dirs=52 bad_files=<多数文件>

结论不依赖具体数字：同一个 home 里大量会话文件是组可写、目录也是组可写，

而各 runtime 的默认 umask 并不统一。规范必须由平台侧强制，不能指望各 runtime

自己收敛。

（findings=40 是"每类最多报 20 条"的采样上限；bad_dirs/bad_files 才是全量计数。）

读法：Codex 的 数千个会话文件里 约三千 个权限不合规、68 个目录组可写；Cursor 195 个文件里 187 个；Claude 204 个里 186 个；隔离的 codex-ds 93 个里 43 个；只有 DSH 基本干净（80 个文件里 1 个 session.lock 是 0664）。这不是"某个家目录没设好"，而是每个 runtime 的默认 umask 都不同、且都允许组可写——所以规范必须由平台侧强制，不能指望各 runtime 自己统一。这是 M10 的第一个待修项。

5.7 各模块必须遵守的存储约束

5.8 验收

1. storage_audit.py "$PLATFORM_HOME" 返回 0，且 findings 只有 warn。
2. 人为造一个 0664 文件与一个缺 manifest.json 的产物目录，审计必须分别报 file_permissions 与 missing_manifest。
3. gc_plan 对 evidence/ 永不产出条目（append-only），对 scratch/ 超 1 天必产出；对 sessions/ 超期但仍有活租约或无法重新落位的条目，产出的是 action=refuse 并带原因，不是删除项。
4. 一次 relocated 交接后：sessions/<uid>/receipt.json 存在、payload 哈希与回执一致、state/ 里 handoff_state.state='verified'。
5. 对既有 home 的 --uniform 审计不修改任何文件（只读）；修复权限是显式的独立动作。

6. 组合成系统：分阶段落地与验收

原则：每一步都能独立上线并产生可验证价值，不出现"全部做完才有用"的阶段。

验收必须包含的崩溃边界（只验"跑通了"是不够的，要验"在哪一步死掉不会留下坏状态"）：

每条都要求"重启后账本收敛"：重复跑一遍 reconcile，不应产生新的进程、新的 primary 或新的删除。

验收必须包含的四个反例（来自实测，最容易"看起来成功"）：

1. 错误 cwd 的 Cursor resume（R11）：必须判 failed，不能因为退出码 0 就算成功。
2. 双写（R8/R13）：第二个写者必须被平台拒绝，且拒绝发生在起进程之前。
3. provider 不匹配（R2）：必须提前判定并给出"改哪个字段"的可执行错误，而不是把 -32600 原样抛给用户。
4. 索引缺口（session_index.jsonl 441 条 < 数千个会话文件，且 数千 个是 .jsonl.zst 压缩档，索引未覆盖）：必须显示"未知/待补扫"，不能把"索引里没有"当成"会话不存在"。
5. 未压缩与已压缩混存：同一个 sessions/ 下 545 个 .jsonl 与 数千 个 .jsonl.zst。adapter 的 list 必须两种都认，materialize 复制时保持原文件名（否则 runtime 找不到）。

7. 明确不做、未核实与风险

7.1 不做（本期）

• 不做会话内容的中央存储/同步。内容留在各 home；平台只存路径与哈希。理由：体积、隐私、格式归属。
• 不做跨 runtime 的"同一线程"伪装。只有 native/relocated 才能叫"恢复"；其余叫 converted。
• 不替换 csched 的调度、不替换 DSH 的工单模型。本方案只加连接件。
• 不引入 Temporal/K8s/Ray 作为底座。理由见 compute-scheduler-design.md §4；本方案的持久性需求（租约、fencing、append-only 事件）csched 已满足。
• 不自动 merge、不自动接管他人会话；强制接管仅 human token 且留审计。

7.2 未核实（不得当作能力）

7.3 风险

8. 与现有系统的关系（一句话各自定位）

9. 下一步（需要人确认的三件事）

1. P0 先做哪个 runtime：建议 codex 家族优先（本机 数千个会话文件里 ~/.codex 占绝大多数，且已有 app-server 通道与导入能力），Cursor 第二（会话体积第二、静默失败风险最高）。
2. relocated 副本的保留策略：是"交接后删源"（省空间，不可回滚）还是"保留 N 天"（可回滚，占空间）。建议默认保留 7 天并在看板显示占用；§5.5 的类默认值是 30 天，若不改就以类为准。
3. 既有 home 的权限是否要就地修：§5.6 审计出 Codex 约三千 个 0664 文件、Cursor 187 个、Claude 186 个。修复是显式动作（会改动各 runtime 自己的文件），建议先在 ~/.codex、~/.cursor、~/.claude 上各做一次 chmod -R go-rwx 并写回执，还是只对平台新建目录生效。

在这三点确定前，P0（存储基线 + 只读索引）不依赖任何决策，可以立即开始。