@zq-silk/yui 0.15.8 → 0.15.11

package/docs/sqlite-control-plane-design.zh-CN.md

@@ -0,0 +1,62 @@
+<p align="right"><a href="./sqlite-control-plane-design.md">English</a> | <strong>简体中文</strong></p>
+
+# SQLite 控制面存储
+
+Yui 只有一个权威产品 Store：WAL 模式下的 `YUI_HOME/yui.db`。`schema_migrations`
+中连续且带校验和的最高一行，就是当前发行版接受的那一个 Home 存储版本。
+
+## 权威
+
+- `yui.db` 拥有 Task、WorkItem、AgentRun、Message、Decision、结果、Project
+  Knowledge 引用、受管工作区记录、运行时绑定、mailbox、持久事件和配置。
+- Provider Session、transcript、进程、缓存、telemetry 和运行时观察服务于执行
+  与诊断，不替代持久的 Task 事实。
+- 数据库之外的配置和诊断不定义另一个存储版本，也不允许启发式地重建 Task 真相。
+
+## 准入
+
+普通命令只有在同时满足以下条件时才打开 Home：
+
+1. `yui.db` 存在，且其迁移账本是一个有效的不可变前缀。
+2. 账本头恰好等于运行中 CLI 的当前存储版本。
+3. 当前记录校验与引用完整性均通过。
+
+落在 CLI 支持区间内的更旧 Home 无法通过普通准入，但被归类为可升级。
+`yui doctor` 和 `yui upgrade --dry-run` 会报告有序的升级路径而不改动 Home。
+显式的 `yui upgrade` 是唯一的独立变更边界：它让 Controller 静止、备份
+`yui.db`、以事务方式套用所有缺失迁移，并校验当前模型。更新的、低于最低版本的、
+不完整的或损坏的 Home 一律 fail closed。不存在运行时归一化、修复 worker、
+文件 Store 回退、双读写路径或第二套迁移权威。
+
+## 写入与并发合同
+
+- 每次修改是一个 SQLite 事务。
+- WAL 加 `synchronous=FULL` 提供持久提交边界。
+- `home_meta.revision` 是全 Home 范围的 CAS/revision，供需要冻结
+  read/modify/write 边界的调用者使用。
+- 类型化列支持按身份和状态建索引查询；完整且经校验的记录负载仍是持久的领域表示。
+- mailbox 认领、精确的 AgentRun 终结、活动指针移除、结果持久化以及下游唤醒创建，
+  在它们构成同一条产品事实时以事务方式耦合。
+- 幂等键与唯一约束保护可重复的外部效果确认，不构成第二套工作流状态机。
+
+## AgentRun 与 Session 边界
+
+AgentRun 是一次明确请求的执行。它记录相关的可见输入和原始结果，而不是隐藏的
+推理过程或完整工具轨迹。一个 Provider Session 可以包含多个 Run、普通原生对话
+和通知。原生对话和通知不会自动创建 Run。只有精确关联的原生终态才结算该 Run；
+WorkItem 与 Task 的验收权威仍归 Leader。
+
+## 更新行为
+
+`yui update` 暂存一个确切的包，并要求那个暂存二进制把 Home 判定为当前、可迁移
+或受阻。随后它停止那个确切的 Controller、激活同一个包、在需要时运行暂存发行版
+的完整迁移链、校验已安装二进制与当前 Home，再启动替换后的 Controller。
+
+每次持久 schema 或负载变更都追加一条不可变、连续的存储迁移。CLI 同时发布
+`storageVersion` 与 `minimumStorageVersion`；处在该闭区间内的每个有效 Home 都能
+直接升级到当前版本，无需安装中间发行版。当前源码在
+`src/storage/storageVersions.ts` 中声明存储版本 **18**、最低支持迁移版本 **1**。
+低于该下限的 Home 不是迁移输入，保持原样不动。目标二进制的
+`upgrade --update-preflight` 与 `--update-apply` 结果形态，以及由父进程持有的
+交接锁证明，对从存储版本 1 起发布的每个 updater 都保持向后兼容，因此一个旧的
+源码 CLI 仍能驱动一个新得多的目标的完整迁移链。

package/docs/task-dag-semantics.md

@@ -1,57 +1,80 @@
-# Task 依赖与 WorkItem 语义
-
-## 需求与执行分离
-
-Task 是一个有界结果，WorkItem 是其中可独立验收的需求。Task type 不决定
-执行拓扑；Leader 可以直接工作，也可以创建独立负责人交付的 WorkItem。
-实现步骤、一次测试、审查发现或小修补不因此成为新 WorkItem。
-
-WorkItem 持久状态仅为 `open / accepted / retired`：
-
-- `open`：需求仍在处理；可能尚未执行、正在执行、等待验收或需要重试。
-- `accepted`：Leader 已显式接受当前交付。
-- `retired`：需求已显式退役，保留记录和原因。
-
-执行状态归 AgentRun，Candidate 记录当前待接受的结果。提交、拒绝或执行失败
-不把 WorkItem 变成另一套运行状态。接受撤回是显式动作。
-
-## 唯一依赖权威
-
-`WorkItem.dependsOn` 是同一 Task 内的直接依赖列表。前置项 A → 下游 B
-表示 B 的 `dependsOn` 包含 A。保存时检查同 Task 引用、存在性和无环约束。
-它不表达 Provider 并发、Session 占用或文件锁。
-
-派发时，每个直接依赖必须存在且为 `accepted`。Open、retired 或 missing
-均不能满足依赖，错误返回具体 ID 和当前状态。Run 成功、Candidate 存在、
-Review 完成或 Git 已集成都不能代替 WorkItem 接受。
-
-退役的 replacement 字段只解释替代关系，不重定向或重写依赖。
-Leader 必须显式修订需求或依赖；Controller 不沿替换链自动释放下游，
-不级联取消、不自动跳过，也不把依赖列表变成调度计划。
-
-## 修改与恢复
-
-Open WorkItem 的合法定义编辑保存前后值，保留身份和执行证据。已经启动的
-Run 仍使用冻结 Assignment；修改当前需求不追溯改写其 Context 或权限。
-已接受和退役的定义不能借普通编辑覆盖。负责人与资源范围变更受各自边界检查。
-
-执行失败时，Leader 检查原始结果、Session、依赖与工作区，决定续作、重试、
-退役或修改计划。退役后迟到消息保留来源和未投递原因，不自动重开。
-InputRequest 表示待决问题；回答不自动接受 WorkItem 或改写依赖。
-
-## 接受、集成与 Task 完成
-
-Direct 和 replicated 共享一个 Leader 接受边界。Replicated Producer 不形成
-Candidate；只有显式综合的 main Run 结果进入候选路径。Leader 直接管理的
-交付也必须满足适用的 Candidate、ChangeSet 和 Integration 边界。
-
-隔离代码结果按 Project 捕获固定 ChangeSet，检查后 CAS 集成；未捕获、未集成
-或失效的最新结果不能满足交付。Review 依适用规则和 Task 合同检查。
-Leader 自己交付的 Task main 需要干净、已提交的精确快照。
-
-Task lifecycle 是 `draft / active / completed / cancelled / archived`。
-Draft 先规划再显式采用工作区；completed/cancelled 不接收隐式新执行，
-reopen 不重放旧请求；archived 不可重开。Archive 还要求资源静止、干净可移除，
-不因依赖图或完成状态自动删除工作区。
-
-CLI/Web 从这些事实派生展示和建议，不维护第二套可写 DAG、验收状态或计划。
+<p align="right"><strong>English</strong> | <a href="./task-dag-semantics.zh-CN.md">简体中文</a></p>
+
+# Task dependencies and WorkItem semantics
+
+## Requirement and execution are separate
+
+A Task is one bounded outcome; a WorkItem is an independently acceptable
+requirement within it. Task type does not dictate execution topology: the Leader
+can work directly or create WorkItems delivered by separate owners. An
+implementation step, a single test, a review finding or a small fix does not
+become a new WorkItem on its own.
+
+The persistent WorkItem status is only `open / accepted / retired`:
+
+- `open`: the requirement is still in progress — not yet executed, executing,
+  awaiting acceptance or needing another attempt.
+- `accepted`: the Leader has explicitly accepted the current delivery.
+- `retired`: the requirement is explicitly retired, with its record and reason
+  preserved.
+
+Execution status belongs to AgentRun, and a Candidate records the result
+currently awaiting acceptance. Submission, rejection or execution failure does
+not turn a WorkItem into a second runtime state machine. Withdrawing acceptance
+is an explicit action.
+
+## One dependency authority
+
+`WorkItem.dependsOn` is the list of direct dependencies within the same Task. A
+prerequisite A → downstream B means B's `dependsOn` contains A. Saving checks
+same-Task references, existence and the acyclic constraint. It does not express
+Provider concurrency, Session occupancy or file locks.
+
+At dispatch, every direct dependency must exist and be `accepted`. An open,
+retired or missing dependency cannot satisfy it, and the error returns the exact
+ID and current status. A successful Run, an existing Candidate, a completed
+Review or an integrated Git change does not substitute for WorkItem acceptance.
+
+A retired WorkItem's replacement field only explains the substitution; it does
+not redirect or rewrite dependencies. The Leader must explicitly revise the
+requirement or its dependencies. The Controller does not release downstream work
+along a replacement chain, cascade cancellation, auto-skip, or turn the
+dependency list into a scheduling plan.
+
+## Editing and recovery
+
+A legal edit to an open WorkItem definition preserves the before/after values and
+keeps its identity and execution evidence. An already-started Run keeps its
+frozen Assignment; editing the current requirement does not retroactively rewrite
+that Run's Context or permissions. Accepted and retired definitions cannot be
+overwritten by an ordinary edit. Owner and resource-scope changes are checked at
+their own boundaries.
+
+On execution failure, the Leader inspects the original result, Session,
+dependencies and workspace, then decides to continue, retry, retire or revise the
+plan. After retirement, a late message keeps its source and non-delivery reason
+and does not auto-reopen. An InputRequest represents an open question; answering
+it does not accept a WorkItem or rewrite dependencies.
+
+## Acceptance, integration and Task completion
+
+Direct and replicated execution share one Leader acceptance boundary. A
+replicated Producer does not form a Candidate; only the explicitly synthesized
+main Run result enters the candidate path. Delivery the Leader manages directly
+must also satisfy the applicable Candidate, ChangeSet and Integration boundaries.
+
+An isolated code result captures a fixed per-Project ChangeSet and integrates via
+compare-and-swap after its checks; an uncaptured, unintegrated or stale latest
+result cannot satisfy delivery. Review is checked against the applicable rule and
+the Task contract. A Task main the Leader delivers itself needs a clean,
+committed, exact snapshot.
+
+The Task lifecycle is `draft / active / completed / cancelled / archived`. A
+Draft plans first and then explicitly adopts a workspace; completed and cancelled
+Tasks do not accept implicit new execution, and a reopen never replays old
+requests; an archived Task cannot reopen. Archive also requires resources to be
+quiescent, clean and removable, and never deletes a workspace merely because of
+the dependency graph or a completion status.
+
+CLI and Web derive their views and suggestions from these facts; they do not
+maintain a second writable DAG, acceptance state or plan.

package/docs/task-dag-semantics.zh-CN.md

@@ -0,0 +1,59 @@
+<p align="right"><a href="./task-dag-semantics.md">English</a> | <strong>简体中文</strong></p>
+
+# Task 依赖与 WorkItem 语义
+
+## 需求与执行分离
+
+Task 是一个有界结果，WorkItem 是其中可独立验收的需求。Task type 不决定
+执行拓扑；Leader 可以直接工作，也可以创建独立负责人交付的 WorkItem。
+实现步骤、一次测试、审查发现或小修补不因此成为新 WorkItem。
+
+WorkItem 持久状态仅为 `open / accepted / retired`：
+
+- `open`：需求仍在处理；可能尚未执行、正在执行、等待验收或需要重试。
+- `accepted`：Leader 已显式接受当前交付。
+- `retired`：需求已显式退役，保留记录和原因。
+
+执行状态归 AgentRun，Candidate 记录当前待接受的结果。提交、拒绝或执行失败
+不把 WorkItem 变成另一套运行状态。接受撤回是显式动作。
+
+## 唯一依赖权威
+
+`WorkItem.dependsOn` 是同一 Task 内的直接依赖列表。前置项 A → 下游 B
+表示 B 的 `dependsOn` 包含 A。保存时检查同 Task 引用、存在性和无环约束。
+它不表达 Provider 并发、Session 占用或文件锁。
+
+派发时，每个直接依赖必须存在且为 `accepted`。Open、retired 或 missing
+均不能满足依赖，错误返回具体 ID 和当前状态。Run 成功、Candidate 存在、
+Review 完成或 Git 已集成都不能代替 WorkItem 接受。
+
+退役的 replacement 字段只解释替代关系，不重定向或重写依赖。
+Leader 必须显式修订需求或依赖；Controller 不沿替换链自动释放下游，
+不级联取消、不自动跳过，也不把依赖列表变成调度计划。
+
+## 修改与恢复
+
+Open WorkItem 的合法定义编辑保存前后值，保留身份和执行证据。已经启动的
+Run 仍使用冻结 Assignment；修改当前需求不追溯改写其 Context 或权限。
+已接受和退役的定义不能借普通编辑覆盖。负责人与资源范围变更受各自边界检查。
+
+执行失败时，Leader 检查原始结果、Session、依赖与工作区，决定续作、重试、
+退役或修改计划。退役后迟到消息保留来源和未投递原因，不自动重开。
+InputRequest 表示待决问题；回答不自动接受 WorkItem 或改写依赖。
+
+## 接受、集成与 Task 完成
+
+Direct 和 replicated 共享一个 Leader 接受边界。Replicated Producer 不形成
+Candidate；只有显式综合的 main Run 结果进入候选路径。Leader 直接管理的
+交付也必须满足适用的 Candidate、ChangeSet 和 Integration 边界。
+
+隔离代码结果按 Project 捕获固定 ChangeSet，检查后 CAS 集成；未捕获、未集成
+或失效的最新结果不能满足交付。Review 依适用规则和 Task 合同检查。
+Leader 自己交付的 Task main 需要干净、已提交的精确快照。
+
+Task lifecycle 是 `draft / active / completed / cancelled / archived`。
+Draft 先规划再显式采用工作区；completed/cancelled 不接收隐式新执行，
+reopen 不重放旧请求；archived 不可重开。Archive 还要求资源静止、干净可移除，
+不因依赖图或完成状态自动删除工作区。
+
+CLI/Web 从这些事实派生展示和建议，不维护第二套可写 DAG、验收状态或计划。

package/docs/task-delivery.md

@@ -1,3 +1,5 @@
+<p align="right"><strong>English</strong> | <a href="./task-delivery.zh-CN.md">简体中文</a></p>
+
 # Task delivery and resource lifecycle
 
 ## Lifecycle and planning

package/docs/task-delivery.zh-CN.md

@@ -0,0 +1,82 @@
+<p align="right"><a href="./task-delivery.md">English</a> | <strong>简体中文</strong></p>
+
+# Task 交付与资源生命周期
+
+## 生命周期与规划
+
+Task 生命周期是 `draft / active / completed / cancelled / archived`。Draft 保存
+意图、Project 绑定、规划讨论和可变需求。它在创建时不采用可写的交付工作区。
+
+激活会校验当前 Role、依赖、Project 范围和资源，准备物理工作区，并原子地采用
+状态/所有权。准备失败会让 Task 停在 Draft，附带一个失败请求和投递给 Leader 的
+诊断。延迟激活保留确切意图并等待原生静止，无论它是在规划 Run 中还是在后续讨论中
+被请求的。
+
+Task type 描述被请求的结果，而不是强制的执行者。Leader 直接负责有界工作，或分派
+有独立价值的 WorkItem。直接执行没有 Group。复制是为了在同一个冻结 Assignment 上
+进行独立尝试而被显式请求的，随后由 Leader 选择综合。
+
+## 受管工作区
+
+稳定的 Project checkout 是只读参考。Task main 是一个逻辑上的多 Project 根，带有
+按 Project 划分的 Git worktree。对单个 Project，Agent 的正常 cwd 是其受管 Git 根；
+对多个 Project，根加上原生的附加目录机制暴露明确的 Project 集合。
+
+一个隔离的 WorkItem 为可写 Project 拥有独立 worktree，为其余 Project 提供 Task-main
+上下文。写范围是显式的，且只能由获授权的 owner 扩大。Review 拥有一个单独的冻结
+工作区，不能变成 Develop 或 Integration 来源。验收或退役不释放 WorkItem 的持久
+工作区。Task-main 准备会保留一个 Role 保留的 WorkItem/Review cwd，直到显式清理或
+重新分派。决策支持类读取观察当前 Git head，而不准备工作区或迁移 Session。
+
+启动前，实际 Git 血缘必须由已记录的基线派生而来。落在该血缘之外的 reset 是物理
+漂移，而不是猜测或修复所有权的理由。一个显式采用的环境可以选择不同的原生 cwd，
+而受管工作区仍是 Git/控制所有权记录。
+
+## Candidate、Review 与 Integration
+
+Provider 终态保存确切的原始 Run 结果。它不验收 WorkItem。Leader 评估结果，并为
+隔离代码捕获不可变的、按 Project 划分的 ChangeSet。治理 Candidate 为 Review 和
+Integration 提供来源；Producer 不独立进入这两条路径中的任何一条。
+
+Integration 在候选 worktree 中套用固定 ChangeSet，运行已配置的检查，然后只有在
+目标 head 仍匹配时才推进目标。冲突、检查失败、目标移动或拒绝都保留证据，绝不推进
+目标。Agent 在保留的工作区内选择重试或手动解决。
+
+当检查是一个 DurableJob 时，Integration 在运行期间保留那个确切的 jobId。Job 结算
+后，`task integration continue <task>/<integration>` 消费其结果并执行带守卫的收尾。
+这个直接操作不依赖单独 integration 队列中的条目。
+
+Review 遵循适用的 Candidate 规则或 Task-final 合同以及冻结的 head。确切的 main
+Reviewer Run 持有报告；执行成功不等于语义通过。验收归 Leader。即使默认审查策略
+被关闭，用户明确要求委派或获取独立 Review 仍是验收的一部分。`next-action` 报告已
+存储的事实和备选项；它不能削弱 Task Contract，也不能推断“没有记录 WorkItem”就
+意味着请求了直接执行。
+
+## 完成与远程交付
+
+完成会检查当前的 WorkItem、最新捕获/集成的结果、适用的 Review 合同以及确切的、
+干净且已提交的 Task-main 快照。当有一条新的 user/Operator 消息仍在等待 Leader
+投递时，它也会拒绝完成。当前原生轮次必须结束，待处理的通知才能到达；随后 Leader
+读取原始消息并重新评估完成。这派生自既有的 Message 和 mailbox 投递，而不是第二套
+确认或工作流状态。终态工作区清理在完成时可以只是建议，但在归档时不行。被选作
+结果的 Artifact 必须是固定的、存在的且 Task 局部的。
+
+发布记录一个远程 PR/MR 引用。被报告的合并、独立验证的合并以及确切的 Task-head
+覆盖是彼此独立的事实。Task 完成不证明其中任何一项。远程交付从确切的发布/head
+证据读取，而不从标题或分支名推断。
+
+取消意图不证明运行时已停止。user/Operator 可以重开已取消的 Task；Leader 可以重开
+已完成的 Task。重开需要全新的显式输入/工作选择，绝不重放先前的交付请求。
+
+## 归档
+
+归档是一次单独的授权动作，发生在活动工作已了结、资源干净可移除之后。显式选择
+集成交付或有意放弃。集成归档要求确切的已合并 head 和已验证的发布证据。一次显式
+授权的验证覆盖不能绕过缺失或陈旧的 head，也不能绕过一个未合并的结果。
+
+受管的 WorkItem 资源必须在清理前被集成或有意放弃。Review、Lane 和 Integration
+资源必须已结算。脏 worktree 留给 Agent 解决；不发生隐式 reset 或强制删除。Task
+main 分支和持久 Task 记录保留恢复信息。已归档的 Task 不能重开。
+
+清理前用每个命令的 `--help` 查看它确切的权限和选项；阅读一份生命周期文档不授权
+一次外部写入。

package/docs/task-local-identity.md

@@ -1,3 +1,5 @@
+<p align="right"><strong>English</strong> | <a href="./task-local-identity.zh-CN.md">简体中文</a></p>
+
 # Task-local identity
 
 Yui treats a Task as the aggregate boundary for durable workflow records. Each

package/docs/task-local-identity.zh-CN.md

@@ -0,0 +1,58 @@
+<p align="right"><a href="./task-local-identity.md">English</a> | <strong>简体中文</strong></p>
+
+# Task 局部身份
+
+Yui 把 Task 作为持久工作流记录的聚合边界。每个 Task 为下面每一类记录族维护
+一条独立、单调递增的序列：
+
+- WorkItem
+- AgentRun
+- ReviewRound
+- ChangeSet
+- IntegrationAttempt
+- Message
+- InputRequest
+- Decision
+- Milestone
+- Event
+
+序列从 1 开始，因此每个 Task 内某个族的第一条记录本地编号都以 `-1` 结尾
+（例如 `work-item-1`）。删除、取消、完成、重开和归档都不会降低已持久化的
+高水位，所以本地 ID 在同一个 Task 内永不复用。每次分配都在 Store 事务内推进
+该聚合高水位。
+
+Candidate 身份的范围更窄：`candidate-N` 是 WorkItem 内的局部序列。每个
+Candidate 都保存自己的 `taskId` 和 `workItemId`，在有来源 AgentRun 时再附带
+其引用。
+
+## 引用合同
+
+Task 所属引用的可移植形式为：
+
+```text
+<task-id>/<local-id>
+```
+
+例如 `task-7/work-item-1` 和 `task-9/work-item-1` 是不同的。CLI、JSON、mailbox、
+Controller、Hook、回执、Web 以及错误路径都保留 Task 范围。无上下文的命令会
+拒绝裸的本地 ID，而不是在所有 Task 中搜索，即使该 ID 当前恰好唯一。
+
+受管的 Task 会话可以直接用 `work-item-1` 或 `run-1`，因为它的 `YUI_TASK_ID`
+是明确的。已经通过其他参数收到 Task 的命令也可以使用从属的本地 ID。除这两种
+情形外，一律使用限定形式。投递回执沿用同样的来源标注，例如：
+
+```text
+run:task-7/run-1
+input-request:task-7/input-1
+```
+
+不存在兼容查找、跨 Task 猜测或裸 ID 回退。
+
+## 当前 schema 边界
+
+运行时只打开当前 Home 存储版本和当前记录形态，普通工作中既不双读也不推断
+历史记录。历史解码与改写只发生在显式的 `yui upgrade` 边界和 `yui update` 的
+迁移阶段；凡是不低于 CLI 最低支持存储版本的有效 Home 都能直接推进到当前版本。
+
+这条边界让 Task 局部引用、Role 期望配置以及不可变的 AgentRun/RoleSession
+生效快照都处在同一份无歧义的运行时合同下，而只追加的迁移链保留受支持的历史。

package/docs/testing/verification-levels.md

@@ -1,3 +1,5 @@
+<p align="right"><strong>English</strong> | <a href="./verification-levels.zh-CN.md">简体中文</a></p>
+
 # Verification policy
 
 Yui is a single-user local product. Permanent verification protects essential
@@ -51,12 +53,36 @@ regressions, and fast regressions do not establish real-model behavior.
     authentication helpers, rewritten approval records, or secrets forwarded
     to unrelated adapters; native authentication selection stays with Claude. Environment refresh
     removes revoked keys and keeps values out of durable Task/Role records.
+15. ordinary Integration conflicts continue without a decision gate; exact Git
+    receipts and an admitted Job resume interrupted delivery without replay.
+    Validation settlement distinguishes current check conditions from an
+    already-applied CAS. Migration preserves provable old bound FF Jobs and
+    classifies old conflicts without inventing successful checks.
+16. explicit force archive commits before cleanup and preserves uncertain
+    delivery/runtime evidence; partial cleanup and late results remain traceable,
+    while archived runtime resources never become automatically safe to delete.
+17. Host facts reach the existing Inbox even when its compiled store cannot
+    read the Home; Controller-side fencing, ACK-loss replay, and legacy-Host
+    upgrade refusal preserve the original execution. A frozen independent v1
+    protocol producer remains the same process across a real 19→22 migration,
+    authenticates RPCs to both Controllers through refreshed discovery, and
+    retains facts during the disconnected window. Production launch planning
+    also preserves scoped startup evidence before native Session adoption
+    without exporting a Run ID into the Session environment.
+    This fixture is the minimum supported new wire contract, not a claim that
+    pre-fix released Hosts can be hot-patched.
+    Archive racing Host ingress retains the complete source envelope without
+    reopening the Task or settling original uncertain input.
 
 Keep the test phase seconds-scale; measure TypeScript build separately. Record
 incremental runtime when adding a critical regression. The seven recovery boundary
 cases initially add about 0.4 seconds of test bodies (about 0.6 seconds standalone,
 including module startup) on the development host. Avoid sleep-based checks or
 mandatory model/daemon launches in the permanent suite.
+The Integration continuation regressions use disposable Git repositories,
+SQLite and fake Jobs, without a provider or shared Home. Their test bodies
+take about 3 seconds on the development host; validation settlement adds
+about 1.4 seconds to the initial 1.5-second coverage.
 
 ## Skill and instruction changes
 

package/docs/testing/verification-levels.zh-CN.md

@@ -0,0 +1,80 @@
+<p align="right"><a href="./verification-levels.md">English</a> | <strong>简体中文</strong></p>
+
+# 验证策略
+
+Yui 是一个单用户本地产品。永久验证保护关键的 happy path 和少数几个高影响、易被改动
+的正确性边界。它不是一份把每个缺陷或边界情况都收录在案的历史目录。
+
+## 本地开发
+
+使用当前变更所需的最小证据。仅当以下全部成立时才保留一个聚焦的回归测试：
+
+- 失败会丢失持久意图、越过权限/隔离边界，或阻止 Agent/Operator 取得正当进展。
+- 该边界被频繁改动的代码共享，或已经在一次真实执行中失败过。
+- 该检查是确定性的、使用一次性本地夹具、在毫秒级运行，并断言可观察行为而非附带布局。
+- 尚不存在等价覆盖；优先用一个连贯的场景，而不是为每个历史症状分开建用例。
+
+把宽泛的故障矩阵、真实模型演练、畸形数据组合和针对具体事故的脚本保持为临时的。变更
+完成后移除它们的 harness，并保留有用的报告。真实资源结果不替代快速回归，快速回归也
+不确立真实模型行为。
+
+## 永久 core smoke
+
+`npm test` 和 `npm run test:core` 构建 checkout 并运行一个永久套件：
+
+1. 打包后的 CLI 能启动，并暴露 setup/update/upgrade/Task 命令；
+2. 一个普通的 SQLite Task 和 Message 能在重开后存活；
+3. 一个受支持的历史 Home 沿线性存储链迁移到当前版本；
+4. 内置的 Codex 与 Claude Driver 已注册；
+5. 一个独立的声明式插件通过认证入口被创建、验证、调用和停用，其选择和验证被保留。
+6. 一个 Task 从持久的 Operator 输入启动，暴露规划 Context，并在原始意图和捕获的
+   planning 权限被保留的情况下进入交付。
+7. Session 替换保留待处理的原始 Message 和独立工作；旧 Session 保留范围受限的读取，
+   但不能重获写权限；
+8. InputRequest 在没有合成 AgentRun 的情况下经受 Session 替换；
+9. 迟到的原生终态不能结算后继输入或编造接受；
+10. 远程 Operator 启动携带其保留工作区、Role 指令和范围受限的 CLI 身份，同时离线
+    诊断/恢复仍可达。
+11. 持久排队的原生结果经受 Controller 中断并重放，而不毒化 Host；已知的终态输入不会
+    仅因时间变老就变为活动；
+12. Task-final 审查能在没有全局模板的情况下使用其 Task 局部 Reviewer。
+13. 一个原生错误标签只有在具备最新 Turn 终态证据且后台执行已排空时才允许替换；一个
+    错误的原生账号不能授权清理。
+14. Claude 收到其原生环境和 settings 路径，而没有被注入的认证 helper、被改写的批准
+    记录，也没有把 secret 转发给无关适配器；原生认证选择仍归 Claude。环境刷新移除
+    已撤销的 key，并把值挡在持久 Task/Role 记录之外。
+15. 普通 Integration 冲突可直接继续；准确 Git 与 Job 证据恢复中断交付，
+    不重放已执行的步骤，也不把已发生的 CAS 与新的验证条件混为一谈。
+16. 明确授权的 force archive 先提交归档，再独立记录清理；不确定输入与晚到
+    结果仍可追溯，归档不使保留资源自动变得可删除。
+17. 即使 Host 编译版本的存储代码无法读取 Home，事实仍先进入现有 Inbox；
+    Controller 侧归属校验、ACK 丢失重放和 legacy Host 升级拒绝保护原始执行。
+    独立冻结的 v1 协议生产者在真实 19→22 迁移前后保持同一进程，通过新 discovery
+    分别向两个 Controller 发出认证 RPC，并在断线窗口保留事实。生产 launch 路径
+    在不向 Session 环境导出 Run ID 的前提下保留 scoped 启动证据。该 fixture 代表最低
+    支持的新线协议，不声称已发布的修复前 Host 可以原地热更新。
+    归档与 Host 消费交错时保留完整来源 envelope，不重新打开 Task 或结算原不确定输入。
+
+把测试阶段保持在秒级；单独度量 TypeScript 构建。新增一个关键回归时记录其增量运行
+时长。这七个恢复边界用例在开发主机上最初约增加 0.4 秒的测试体（独立运行约 0.6 秒，
+含模块启动）。避免在永久套件中使用基于 sleep 的检查或强制的模型/daemon 启动。
+
+## Skill 与指令变更
+
+一并审阅共享的 Runtime 合同和受影响的 Role/Project Skill。用几个相关场景检查指令
+边界：分析保持只读、复用既有机制、Session 丢失保留 Task 意图，以及执行失败不阻止获
+授权的监督。这是一次有界审阅，而不是一套新的永久矩阵，也不是使用真实模型的许可。
+
+package-start 检查跟随已安装树中的本地 Skill 引用，包括跨 Role 链接。入口点及其引用
+的 Markdown 必须一起发布。文件/格式检查确立可用性，而不是 Agent 行为；不要添加基于
+散文匹配的测试，也不要从静态检查中宣称模型验证。
+
+## CI 与发布
+
+`ci.yml` 运行 core smoke 加一个包装配/启动检查。它不运行第二遍 lint，也不运行单独的
+宽泛回归套件。`publish.yml` 复用那个确切的、已过门的提交，只增加发布独有的 tag、
+产物、安装和 provenance 检查。
+
+作为开发者或审查者的已配置 Agent 是普通执行资源。把一个真实 provider 或模型作为验证
+对象则不同：付费 API、共享 Home、生产系统、真实账号额度以及其他不可丢弃的外部效果，
+绝不由一个测试或验证请求隐含。它们需要用户就确切的资源和效果边界提出显式请求。