@zq-silk/yui 0.15.12 → 0.16.0

package/docs/release-workflow.zh-CN.md

@@ -15,10 +15,143 @@ Agent 选择一个预先声明的计划，设施从持久状态驱动该计划
 - **ReleaseWorkflow**（`release-workflow-N`）——计划及其进展：一个确切来源（仓库 +
   钉住的 commit，可选一个 artifact）、一份不可变的有序步骤计划，以及每步一条持久记录。
 
-引擎（`src/release/releaseWorkflowEngine.ts`）是一个纯库；`yui task workflow` 和
+引擎（`src/release/releaseWorkflowEngine.ts`）负责持久状态转换和工作流锁；`yui task workflow` 和
 `yui task grant` 命令驱动它。每个外部系统都位于 `ReleaseWorkflowPorts`
-（`src/release/releaseWorkflowPorts.ts`）之后，因此整个工作流可以用确定性的 fake
-测试，不产生任何真实的 GitHub、npm、git、Controller 或进程副作用。
+（`src/release/releaseWorkflowPorts.ts`）之后。可用临时 SQLite 和确定性的外部端口测试
+恢复逻辑，无需真实 GitHub、npm、git、Controller 或模型效果。
+
+## 1.0 前的契约清理
+
+版本 `0.16.0` 先清退运行时兼容分支，尚未执行最终 1.0 基线切换，也不重置
+存储编号。存储 `27→28` 只规范化可明确识别的单条 Role 调度去重键，旧迁移账本、
+Message、Task 结果和不确定外部效果保持不变。普通打开要求存储 37；已有 Home 只通过
+显式升级入口前进，不增加运行时双读。
+
+这是一次 1.0 前的破坏性变更：
+
+- `message send` 统一使用 `--intent`；CLI 与 capability API 不再接受 `--wake-policy`
+  或 `wakePolicy` 参数，Draft 编辑保留原提交意图。
+- 内部命令集成实现 `notifyMailboxChanged`；Task-only 通知适配器及其调用已统一。
+- ACP peer 必须回报 `configOptions`，不再走 `modes`／`set_mode` 路径。
+- Release 恢复要求精确 Home 与安装 prefix。缺少固定目标的效果保持 unknown，
+  身份不完整的 handover lock 保持围栏。
+- 开发 link/unlink 要求当前登记文件，不搜索或接管旧 NVM 登记，不重建孤立链接。
+- GC 不再发现旧 deployment 布局或重建已删除 worktree；不受支持的 quarantine
+  证据保留，不会被当成当前 move 回执清除。
+- `task activate` 只消费已有请求；没有请求就不采用资源。请求创建、延后准入和
+  原子工作区采用仍分开，并复用同一个现行执行边界。
+- 删除 `task integration queue` 及其状态机。Agent 选择每个 WorkItem 结果的顺序与
+  策略，逐项调用原子 Integration；保留精确检查、目标 CAS 和完成义务。
+
+存储 `28→29` 在删除活动队列表前，将每条旧 payload 原样保存在
+`integration.queue-retired` Task 事件中，并保留原队列 ID。事件编号越过已有计数器
+和历史最大 ID。此操作不验收交付、不生成 Integration、不重放工作；已有 Integration
+与 Job 保持不变。通过 `task event list <task>` 和引用的 WorkItem/Integration
+判断剩余工作；队列退役不代表未完成的 Integration 已结算。
+
+存储 `29→30` 将 Run-linked wake 的完整原文移入 `wake.run-link-retired` Task 事件。
+现有通知保留 ID、投递状态和引用，使用 wake schema 2；Run 终态不再消费通知。
+引用待退役 wake 的活动 Run、受管重试或未决 claim 会同时阻止预检和迁移；
+迁移不停止执行、不编造接受。Global Session 没有受控 binding 时统一显式保存
+`providerBinding: null`。
+
+存储 `30→31` 将 Review scope 统一为显式值：有效旧 WorkItem Review 的缺失／null
+scope 转为 `work-item`，Task-final 候选证据和原迁移账本不变。新建和重试均显式写入 scope。
+
+存储 `31→32` 从当前 WorkItem 移除 `historicalState`，移除前将完整原始 payload
+原样保存在 `work-item.execution-state-retired` Task 事件。当前状态、工作范围、
+Candidate 和执行组不变，不生成 Run 或验收。未知历史形态会报错，记录和迁移账本不前进。
+
+存储 `32→33` 清退 Leader 过渡／预算配置以及 VerificationPlan 的模式。
+活动计划显式补上 schema 版本，实际检查保持不变；已退役 Knowledge 原文保留。
+Integration 显式补入 `rerunChecks: false`，缓存 Artifact 移除试运行复用计数。
+原配置可从显式升级备份恢复。这是已确认的行为变更，不将三种旧模式声称为等价。
+
+已接纳且仍为 `running/validating` 的计划验证会阻止预检和迁移，需先用旧版本完成
+结算；不会把运行中的 Job 改标为新证据契约。该次切换使用 v3 验证摘要，使更早缓存不再被
+自动复用，不重写历史 Job／Integration 结果或删除其日志。旧计划解析冻结在迁移
+目录中，早期迁移保持原有语义。
+
+现行干净候选证明采用 v5 L2-only 执行摘要。Job 和本地验证都在发布可复用成功前，
+检查候选工作区的干净状态、分支和精确 HEAD；旧缓存身份不能绕过这一边界。
+旧记录和日志保持可读，已接纳 Job 不会被改标为新摘要。应先按原契约结算旧尝试，
+或明确放弃后再开始新操作。
+
+L1 执行入口、选择器及当前计划／artifact 类型分支已移除。存储 `34→35` 将
+原始 Project 计划、L1 artifact 与日志保存在 `storage_migration_archive`，
+当前计划改为不含 L1 的 schema 2。存档只是原始审计数据，不是执行 reader 或缓存。
+已结算的旧 ChangeSet-source Integration 转为完整 payload 的 Task 事件；
+仍有工作区、未结算 Job 或 adoption 引用时阻止退休。旧迁移账本不变。
+
+Session 归属统一使用 SQLite。旧 `launch-env` owner 行或 `runtime/session-owners`
+中的文件会阻止切换：先使用旧版本检查并释放精确资源，再明确将旧文件归档到
+活动 Home 之外。迁移不杀进程、不推断归属、不修复损坏数据，也不重写不可变 Manifest。
+
+存储 `35→36` 保留历史 Agent 错误，并将缺失的失败配置明确标为不可用。
+存储 `36→37` 将已记录的失败上下文缩小为原生元数据查询所需输入，原始快照和
+空的可选身份占位值保存在迁移审计中。当前错误读取不依赖执行快照协议，也不
+重建缺失历史。配置拒绝保留原始输入但不自动重试；有权限的 Agent 可查询该次
+失败的模型能力、修正原本要求的配置，再显式重试被拒绝的通知。
+
+不再支持 `task turn` 和 `yui-dev` 补全身份。上线前应替换仍依赖 `task turn`
+Manifest 的 Session；明确卸载／归档旧 `yui-dev` 补全块后，再安装现行 `yui` 补全。
+存储迁移不会修改用户 shell 文件。Host 控制／事件兼容与 updater 交接安全检查保持不变。
+
+存储 `33→34` 从当前记录移除 Message `wakePolicy` 与激活 `origin`，原始表达
+保存在审计事件。旧的仅记录消息转换为 `intent: record`，其他缺少意图的
+user/operator 消息转换为 `discuss`；运行时不再解释缺失的持久化意图。
+编辑仅记录内容不会唤醒 Leader。完成检查读取实际待投递消息引用，也涵盖显式交接
+此前仅保存的内容。
+
+Draft 编辑同时保护请求身份：已经绑定 submission、queue/steer 或交接请求的消息
+不能原地改正文，需新建消息并使用新请求 ID；相同正文更新为无操作。未绑定请求
+身份的讨论编辑仍遵守 pending/failed 激活状态，develop 编辑不启动规划或创建／
+重试激活。这是操作边界修复，不改变存储格式，也不猜测修复过去已被编辑的原文。
+
+Draft 中缺少 origin 且仍 pending 的旧 immediate 激活请求会阻止预检和迁移，即使 Task
+已停止执行。必须先用旧版本显式激活或取消；升级不替用户做这个决定。当前已接纳
+请求不再经过第二次来源门槛，但取消、planning 延后、执行状态与精确 Session 权限
+仍需检查。旧来源及 settled 请求历史保留在 `task.activation-origin-retired` 事件。
+
+新 `job start` 必须带 `--request-id`；RPC 必须提供 `requestId`，capability
+入口使用 invocation 身份。不再从命令内容隐式生成请求，也不再构造匿名 Job。
+已有 Job 的操作证据和按 ID 读取保持不变；相同请求重试防重、不同输入冲突，
+Integration 在 Session 替换后仍找回原 Job。新 request ID 表示明确的新操作，
+不是对旧未知结果的自动重放。
+
+Scheduler 核心读取和持久化操作成为必需接口，缺少 Session／Event 读取不再被当作
+空证据，也不能跳过错误持久化。执行及 Web 投影直接读取当前 Store；
+消息入队必须读取 Task 生命周期。精确投递结算仍独立，不增加会丢失迟到证据的归档门槛。
+Observer、配置、Knowledge 与工作区清理所需 Store 读取也成为必需接口；
+测试替身实现现行合同，不再令生产代码降级。
+
+Task 列表及 `/api/dashboard` 只保留有界目录；调用方去掉 `--view compact`，
+详情使用单 Task 读取。Scheduler 目录索引是必需接口，不再兼容缺失时的全量扫描。
+额外 `schema.json`／`state.json` 不覆盖 SQLite 版本，也不用于开发 Home reset；
+升级保留无关文件。非空 Home 缺少数据库时仍拒绝初始化。
+不认识的 writer lease 明确诊断，不接管、不删除。
+
+`controller status` 固定输出身份信息，存储矛盾仍返回非零健康退出码；
+`YUI_STATUS_IDENTITY` 不再选择另一套契约。升级侧直接复用资源采集器读取生命周期，
+无需让旧 Home 先通过当前 schema 的健康校验。
+
+现行边界进一步收敛：
+
+- Project／Artifact 文件锁及 handover lock 要求精确进程代际证据。owner 缺失、
+  格式不完整或 OS 身份不可读时保持围栏；仅凭年龄不能证明创建者退出，不再用
+  PID-only 存活判断代替身份确认。
+- PR head 查询只调用 `gh pr list --head ... --state open`。仅有效空数组证明不存在；
+  传输失败、身份格式错误和多个匹配都不允许继续创建。
+- 已有 Git 操作缺少原 Integration 进度回执时不再被接管。保留文件并明确诊断；
+  有精确回执的正常冲突／Job 续作仍受支持。
+
+发布前应先收敛旧执行，对不受支持的锁、链接和隔离资源做显式清理。归属与处置尚未
+确定时保留原记录，运行时不替 Agent 选择恢复方案。
+
+后续基线切换必须先验证到目标格式的桥接或导出，再用一个干净基线替换旧初始化和迁移链，
+之后才能删除基线之前的迁移及历史夹具。存储基线只重置一次，不在发布 `1.0.0` 时再次
+重置。未知版本拒绝、精确进程／Host 身份检查与持久审计证据仍应保留。版本 tag、真实
+Home 迁移和发布效果需要各自的发布授权。
 
 ## 授权模型
 
@@ -165,8 +298,9 @@ kind、可选 params，以及一个可选的不可逆级别（`none` | `reversib
 
 该键被传给该步骤的每一次 `executeStep` 调用，包括在一次确认为 absent 的超时之后的
 重试。端口合同要求 `executeStep` 在同一键下是幂等的：一次重试尝试不得产生第二次
-副作用。引擎侧的合同更严格——它绝不为一个已标记 `unknown` 的步骤调用 `executeStep`,
-而是按记录的身份重新查询。fake 记录每一个键，因此测试套件直接证明至多一次执行。
+副作用。引擎不会盲目为 `unknown` 步骤调用 `executeStep`，而是先按记录的身份查询。
+核心测试用真实 SQLite 和确定性端口检查不确定效果查询、已确认步骤复用和 grant 次数耗尽。
+这证明这些引擎边界，不代表真实外部服务或所有发布适配器的幂等性已被验证。
 
 ## Operator 指南
 

package/docs/roles-and-configuration.md

@@ -93,10 +93,20 @@ services. Isolating `YUI_HOME` or replacing a Session does not require a fresh
 native account directory. Managed Task execution uses Claude's non-interactive
 stream-json path with the same native configuration ownership.
 
+Model catalogs are native observations, not a universal Provider whitelist.
+Yui displays the selectable ID/alias and its reported resolved model. An explicit
+custom ID is passed unchanged when the native model field allows custom values;
+this does not prove that the Provider will accept it. Known model-specific effort
+limits are still validated. Configuration rejection reports the observed model
+options and how to inspect the full catalog; an unavailable catalog is not
+replaced by a fabricated list.
+
 ## Commands
 
 ```sh
 yui config agent capabilities <agent-id>
+yui task role capabilities <task> <role> --refresh
+yui task role capabilities <task> <role> --error <error-event-id> --refresh
 yui config role show <global-role>
 yui config profile show <profile>
 yui task role add <task> <role> --profile <profile>
@@ -107,6 +117,25 @@ yui task role session inspect <task> <role>
 yui task role session new <task> <role> --reason "<why a fresh Session is useful>"
 ```
 
+The global query uses the calling process's default native context. Task-scoped
+queries use the Controller's native account environment and the selected Role
+configuration; they never forward the caller's credentials to another Provider.
+Omitting `--error` selects the current desired Role. With `--error`, the recorded
+failed request supplies model, workspace and profile/settings options even after
+the Role changes. A changed configured Agent command/environment binding or an
+unrecorded historical context produces a diagnosis, not a default substitution.
+Task-scoped metadata queries require a running Controller and do not start one.
+
+`--refresh` explicitly re-probes metadata. A failed probe may show a clearly
+marked cached catalog, not claim it is current. Native files and credentials
+are read currently; their secret contents are never snapshotted in error history.
+The lookup reports metadata only, without running a model to test a candidate ID.
+
+Completed in-memory catalogs have a bounded least-recently-used cache. Concurrent
+requests for the same scope share the active probe, including refresh requests;
+once it settles, an explicit refresh probes again. Retained results are labelled
+as cached rather than as a new live response. No cleanup timer or worker is added.
+
 On Role creation, explicit Agent settings require `--agent`. On update, omitted
 `--agent` targets the active binding; a named binding is updated without being
 activated. `task role bind` changes selection. A live Session requires the

package/docs/roles-and-configuration.zh-CN.md

@@ -75,10 +75,17 @@ Claude 自身加载原生设置，并按其生效配置在 API key、既有 help
 服务。隔离 `YUI_HOME` 或替换 Session 都不要求一个全新的原生账号目录。受管的 Task
 执行使用 Claude 的非交互 stream-json 路径，并沿用同样的原生配置归属。
 
+模型目录是原生观测结果，不是整个 Provider 的模型白名单。Yui 显示可选择的 ID/别名
+及原生报告的实际模型映射。原生模型字段允许自定义值时，显式模型 ID 会原样透传；
+这不代表 Provider 已接受该模型。已知模型的 effort 限制仍会校验。配置校验拒绝会显示
+已观测到的模型选项和完整目录查询方式；目录不可用时，不编造“合法模型列表”。
+
 ## 命令
 
 ```sh
 yui config agent capabilities <agent-id>
+yui task role capabilities <task> <role> --refresh
+yui task role capabilities <task> <role> --error <error-event-id> --refresh
 yui config role show <global-role>
 yui config profile show <profile>
 yui task role add <task> <role> --profile <profile>
@@ -89,6 +96,20 @@ yui task role session inspect <task> <role>
 yui task role session new <task> <role> --reason "<why a fresh Session is useful>"
 ```
 
+全局查询使用调用进程的默认原生环境；Task 查询使用 Controller 的原生账户环境及
+所选 Role 配置，不把调用方的凭据转交给其他 Provider。省略 `--error` 查看当前期望
+配置；指定错误记录时，使用失败时保存的模型、工作区、profile/settings 选项，不受
+之后的 Role 修改影响。若配置的 Agent 命令／环境绑定已变化，或历史错误未记录配置，
+返回明确诊断，不替换成默认配置。Task 查询要求 Controller 已运行，不自动启动它。
+
+`--refresh` 显式重新查询元数据；查询失败后返回缓存时会标明缓存来源，不冒充当前
+结果。原生文件及凭据仍按当前值读取，秘密内容不会复制进错误历史。这里只查询
+元数据，不通过真实模型调用来试验候选名称。
+
+已完成目录使用有容量上限的近期使用缓存；相同上下文的并发请求（包括刷新）共享
+正在进行的查询，结束后显式刷新才重新查询。缓存命中标为缓存，不冒充新的实时响应。
+这不增加清理定时器或后台 worker。
+
 创建 Role 时，显式的 Agent 设置需要 `--agent`。更新时，省略 `--agent` 针对活动
 绑定；一个具名绑定会被更新但不被激活。`task role bind` 更改选择。在更改期望设置
 之前，活动 Session 需要该命令的显式确认。

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

@@ -34,6 +34,19 @@ model. A newer, below-minimum, incomplete, or malformed Home fails closed.
 There is no runtime normalization, repair worker, file-Store fallback, dual
 read/write path, or second migration authority.
 
+Typed domain payloads use one current validator registry on writes, ordinary
+reads, bounded Context pages and full-Home diagnostics. Direct and worker-backed
+Stores do not have different validation strength. Invalid records are rejected
+without advancing the revision; an invalid stored record remains available for
+explicit diagnosis, never normalized into a valid-looking replacement.
+
+Storage 35 also has a migration-only `storage_migration_archive` table:
+`migration_version / family / record_key / payload / content`. It retains exact
+retired Project/gate payloads and binary logs without interpreting them in the
+current model. It is not scheduling state, a second cache or a runtime fallback.
+Task-scoped historical Integration retirement uses ordinary Task Events.
+Backups retain both current records and this audit archive.
+
 ## Write and concurrency contract
 
 - Each mutation is one SQLite transaction.
@@ -69,8 +82,8 @@ Every persistent schema or payload change appends one immutable, contiguous
 storage migration. The CLI publishes both `storageVersion` and
 `minimumStorageVersion`; every valid Home in that inclusive range can upgrade
 directly to the current version without installing intermediate releases.
-The current source declares storage version **25**, with minimum supported
-migration version **1**, in `src/storage/storageVersions.ts`. Homes below that
+The current version and migration floor are declared only in
+`src/storage/storageVersions.ts` and exposed by CLI identity. Homes below that
 floor are not migration inputs and remain untouched.
 The target binary's `upgrade --update-preflight` and `--update-apply` result
 shapes and parent-owned handover-lock proof remain backward compatible with
@@ -123,7 +136,7 @@ unifying the root does not weaken control-data or cross-owner isolation.
 **not** a second authority for internal managed paths, and is intentionally not
 an input to `homeLayout.ts`. A Yui-auto-created Global Role that carries no
 user-chosen cwd no longer falls back to it (or to `process.cwd()`): `yui setup`'s
-built-in Operator/Leader and `yui role add` without `--workspace` now default to
+built-in Operator/Leader and `yui config role add` without `--workspace` now default to
 the Home-internal `managedGlobalRoleWorkspace(home)` (`<home>/workspaces/global`),
 and `setup` no longer fabricates an external Home-sibling `workspace/` — a
 `default-workspace` is persisted only if the user configured one. A user who

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

@@ -28,6 +28,17 @@ Yui 只有一个权威产品 Store：WAL 模式下的 `YUI_HOME/yui.db`。`schem
 不完整的或损坏的 Home 一律 fail closed。不存在运行时归一化、修复 worker、
 文件 Store 回退、双读写路径或第二套迁移权威。
 
+类型化领域记录在写入、普通读取、有界 Context 分页和全 Home 检查时，共用一份
+现行校验注册表。直接 Store 与 worker-backed Store 不存在不同强度的校验。
+无效写入不会推进 revision；已存在的无效记录只会报错并保留供明确诊断，
+不会被自动规范化成看似有效的替代记录。
+
+存储 35 新增仅由迁移写入的 `storage_migration_archive`：
+`migration_version / family / record_key / payload / content`。它保留退休的
+Project／gate 原始 payload 和二进制日志，不在当前模型中解释这些历史格式，
+也不是调度状态、第二份缓存或运行时回退。Task 内的历史 Integration 使用普通
+Task 事件保存。数据库备份同时保留当前记录与这份审计存档。
+
 ## 写入与并发合同
 
 - 每次修改是一个 SQLite 事务。
@@ -54,8 +65,8 @@ WorkItem 与 Task 的验收权威仍归 Leader。
 
 每次持久 schema 或负载变更都追加一条不可变、连续的存储迁移。CLI 同时发布
 `storageVersion` 与 `minimumStorageVersion`；处在该闭区间内的每个有效 Home 都能
-直接升级到当前版本，无需安装中间发行版。当前源码在
-`src/storage/storageVersions.ts` 中声明存储版本 **18**、最低支持迁移版本 **1**。
+直接升级到当前版本，无需安装中间发行版。当前版本及最低支持版本统一由
+`src/storage/storageVersions.ts` 声明，并由 CLI 身份读取暴露。
 低于该下限的 Home 不是迁移输入，保持原样不动。目标二进制的
 `upgrade --update-preflight` 与 `--update-apply` 结果形态，以及由父进程持有的
 交接锁证明，对从存储版本 1 起发布的每个 updater 都保持向后兼容，因此一个旧的

package/docs/task-dag-semantics.md

@@ -61,10 +61,10 @@ it does not accept a WorkItem or rewrite dependencies.
 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.
+must also satisfy the applicable Candidate 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
+An isolated code result freezes per-Project Candidate commits and integrates via
+compare-and-swap after its checks; an unsnapshotted, 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.

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

@@ -45,9 +45,9 @@ InputRequest 表示待决问题；回答不自动接受 WorkItem 或改写依赖
 
 Direct 和 replicated 共享一个 Leader 接受边界。Replicated Producer 不形成
 Candidate；只有显式综合的 main Run 结果进入候选路径。Leader 直接管理的
-交付也必须满足适用的 Candidate、ChangeSet 和 Integration 边界。
+交付也必须满足适用的 Candidate 和 Integration 边界。
 
-隔离代码结果按 Project 捕获固定 ChangeSet，检查后 CAS 集成；未捕获、未集成
+隔离代码结果按 Project 冻结 Candidate 提交，检查后 CAS 集成；缺少快照、未集成
 或失效的最新结果不能满足交付。Review 依适用规则和 Task 合同检查。
 Leader 自己交付的 Task main 需要干净、已提交的精确快照。
 

package/docs/task-delivery.md

@@ -8,6 +8,10 @@ Task lifecycle is `draft / active / completed / cancelled / archived`. A Draft
 stores intent, Project bindings, planning discussion and mutable requirements.
 It does not adopt a writable delivery workspace at creation.
 
+Activation requires a durable request with an explicit environment plan:
+use `task activation request <task> --request-id <id> --environment <plan>`.
+The Controller adopts eligible requests; `task activate <task>` may consume an
+existing request in the foreground but never creates implicit activation intent.
 Activation validates current Roles, dependencies, Project scope and resources,
 prepares physical workspaces, and adopts status/ownership atomically. Failed
 preparation leaves the Task Draft with a failed request and a diagnosis delivered
@@ -22,6 +26,11 @@ Leader owns bounded work directly or assigns substantial independent WorkItems.
 Direct execution has no Group. Replication is explicitly requested for independent
 attempts at the same frozen Assignment, followed by Leader-selected synthesis.
 
+Scope overlap is a read-only advisory in `task next-action`, not a text-matching
+creation gate. The Leader inspects original requirements and decides whether
+work is independent. Request identity, permissions, dependencies, workspace
+isolation and acceptance checks remain enforced independently.
+
 ## Managed workspaces
 
 Stable Project checkouts are read-only references. Task main is a logical
@@ -47,20 +56,82 @@ managed workspace remains the Git/control ownership record.
 ## Candidate, Review and Integration
 
 Provider terminal saves the exact original Run result. It does not accept the
-WorkItem. The Leader evaluates the result and captures immutable per-Project
-ChangeSets for isolated code. The governing Candidate supplies provenance for
+WorkItem. The Leader evaluates the result and its immutable per-Project Git
+snapshot. Optional ChangeSets supply diff evidence. The governing Candidate supplies provenance for
 Review and Integration; Producers do not independently enter either path.
 
-Integration applies the fixed ChangeSet in a candidate worktree, runs configured
+The Agent chooses the order and strategy, then starts one Integration from an
+exact WorkItem Candidate. There is no separate ChangeSet integration queue.
+Integration applies the fixed source commits in a candidate worktree, runs configured
 checks, then advances the target only if its head still matches. Conflict,
 failed checks, target movement or rejection retain evidence and never advance
 the target. The Agent chooses retry or manual resolution within the retained
 workspace.
 
+An existing merge/rebase/cherry-pick without the attempt's own progress receipt
+is not adopted from Git markers. Preserve the scene and choose explicit recovery;
+normal continuation uses the original receipt and never replays a completed step.
+
 When checks are a DurableJob, the Integration retains that exact jobId while
 running. Once the Job settles, `task integration continue <task>/<integration>`
-consumes its result and performs the guarded finalization. The direct operation
-does not depend on entries in the separate integration queue.
+consumes its result and performs the guarded finalization. Existing unsettled
+Integrations, including conflicts, remain completion blockers independently of
+how the Agent ordered them.
+
+### Verification reuse and explicit reruns
+
+A configured VerificationPlan reuses only complete, successful, log-verified
+evidence for the exact Project, commit, plan, toolchain and target/base boundary.
+A plan with no reusable evidence executes normally. Plans require
+`schemaVersion: 2` and contain no `l1` or `record/reuse/enforce` mode.
+Storage 34→35 preserves the original Project declarations, L1 artifacts and
+binary logs in migration audit storage, outside current execution and cache
+lookup. Historical `historical-change-sets` Integrations must be settled and
+free of execution/delivery references before their exact payloads become
+`integration.source-retired` Task Events. Their IDs are never reused.
+
+Request fresh checks when creating an operation:
+
+```sh
+yui task integration start <task> --work-item <id> --strategy ff --rerun-checks
+yui task upstream integrate <task> --project <project> --rerun-checks
+```
+
+The flag is immutable intent on that Integration, not a global configuration
+switch. `continue` consumes the same admitted Job; it cannot turn into a rerun.
+Create a new attempt for another execution, and settle any equivalent unfinished
+verification first. Rerun affects only cache reuse, never permissions, Job
+identity, workspace checks or the final target CAS.
+Explicit `--check` commands also request fresh execution. With a plan configured,
+they run after its checks; they are neither ignored nor rejected by text matching.
+Unstructured checks do not search historical Jobs for a substitute result.
+
+Fresh execution withdraws the old success before starting. Failure is recorded
+as failure; interruption, missing logs or a mutated candidate leave no reusable
+success. Both Job and local execution verify the exact clean candidate before
+publishing successful proof. The v5 L2-only execution digest excludes older proof without
+deleting its history. A stale
+cache consumer cannot restore an older result. Release lookup considers the
+newest recorded matching proof rather than searching past a failure for an
+older green result. The cache represents current reusable evidence, not Task
+execution history; original Job and Integration records remain separate.
+
+The public upstream CLI uses the same Controller Job port as other Integration
+commands. `--latest` may return independent pending Jobs for several Projects;
+continue each returned Integration ID rather than issuing another upstream
+request to poll it.
+
+Job admission, management and pre-spawn checks bind a non-Leader to its current
+Assignment, exact WorkItem workspace and writable Project scope. The existing
+Job owner contract does not represent Review/replica workspaces, so those
+requests fail explicitly rather than falling back to Task main. Leader/Operator
+supervision and settlement of already-running Jobs remain separate.
+
+The identity covers declared inputs, not every external service or untracked
+environment condition. Use explicit reruns for changing external inputs,
+flakiness investigation or a user-requested new check. A plan does not authorize
+real-model/paid/shared-resource validation. Reuse never substitutes for Review,
+acceptance or publication authority.
 
 Review follows the applicable Candidate rule or Task-final contract and frozen
 heads. The exact main Reviewer Run holds the report; successful execution is
@@ -190,6 +261,21 @@ operations for safe cleanup; no background retry or broader deletion authority
 is implied. Both archive paths preserve Task history and recovery information.
 Archived Tasks cannot reopen.
 
+Resource GC is a separate, opt-in quarantine path. A runtime subtree moves once:
+the parent receipt owns recovery of its contents, and redundant child registry
+entries are removed in the same registry transaction. Independently owned Git
+worktrees or retained descendants prevent moving their enclosing directory.
+Task records and results are never removed by this consolidation.
+Session process custody comes from SQLite `session_owners`, with live PID and
+start-identity checks. The retired JSON owner directory is not a parallel source.
+
+The plan is not cleanup authority. Apply and purge re-read Task status, managed
+workspaces, active Runs and unsettled Jobs under the existing SQLite writer
+fence, which spans the bounded physical mutation and registry update. A reopened
+Task or new durable owner prevents quarantine/deletion; uncertainty retains the
+resource with a diagnosis. Reopened quarantined resources can be restored.
+This adds neither a retry worker nor another persistent ownership protocol.
+
 `yui task archive-preflight <task> (--integrated|--abandon) [--force] [--json]`
 reads current admission, delivery and exact-owner cleanup checks in one report.
 It is available before and after archive, including to the Task's authorized

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

@@ -7,6 +7,10 @@
 Task 生命周期是 `draft / active / completed / cancelled / archived`。Draft 保存
 意图、Project 绑定、规划讨论和可变需求。它在创建时不采用可写的交付工作区。
 
+激活要求先保存带明确环境计划的请求：
+`task activation request <task> --request-id <id> --environment <plan>`。
+Controller 采用符合条件的请求；`task activate <task>` 可以在前台消费已有请求，
+但不会隐式创建激活意图。
 激活会校验当前 Role、依赖、Project 范围和资源，准备物理工作区，并原子地采用
 状态/所有权。准备失败会让 Task 停在 Draft，附带一个失败请求和投递给 Leader 的
 诊断。延迟激活保留确切意图并等待原生静止，无论它是在规划 Run 中还是在后续讨论中
@@ -18,6 +22,10 @@ Task type 描述被请求的结果，而不是强制的执行者。Leader 直接
 有独立价值的 WorkItem。直接执行没有 Group。复制是为了在同一个冻结 Assignment 上
 进行独立尝试而被显式请求的，随后由 Leader 选择综合。
 
+工作范围重叠只在 `task next-action` 中作为只读建议，不再按文本匹配拦截创建。
+Leader 读取原始需求并判断是否属于独立工作。请求身份、权限、依赖、工作区隔离和
+验收校验仍独立强制执行。
+
 ## 受管工作区
 
 稳定的 Project checkout 是只读参考。Task main 是一个逻辑上的多 Project 根，带有
@@ -37,17 +45,65 @@ Task 仓库所有。对单个 Project，Agent 的正常 cwd 是其受管 Git 根
 
 ## Candidate、Review 与 Integration
 
-Provider 终态保存确切的原始 Run 结果。它不验收 WorkItem。Leader 评估结果，并为
-隔离代码捕获不可变的、按 Project 划分的 ChangeSet。治理 Candidate 为 Review 和
+Provider 终态保存确切的原始 Run 结果。它不验收 WorkItem。Leader 评估结果及其不可变的
+按 Project 划分的 Git 快照。ChangeSet 是可选的差异证据；治理 Candidate 为 Review 和
 Integration 提供来源；Producer 不独立进入这两条路径中的任何一条。
 
-Integration 在候选 worktree 中套用固定 ChangeSet，运行已配置的检查，然后只有在
+Agent 选择结果顺序与策略，再从精确 WorkItem Candidate 发起一次 Integration，
+不再维护单独的 ChangeSet 集成队列。
+Integration 在候选 worktree 中套用固定来源提交，运行已配置的检查，然后只有在
 目标 head 仍匹配时才推进目标。冲突、检查失败、目标移动或拒绝都保留证据，绝不推进
 目标。Agent 在保留的工作区内选择重试或手动解决。
 
+已有 merge/rebase/cherry-pick 若缺少原尝试的进度回执，不根据 Git 标记接管。
+保留现场并选择显式恢复；正常续作使用原回执，不重放已完成步骤。
+
 当检查是一个 DurableJob 时，Integration 在运行期间保留那个确切的 jobId。Job 结算
 后，`task integration continue <task>/<integration>` 消费其结果并执行带守卫的收尾。
-这个直接操作不依赖单独 integration 队列中的条目。
+未结算的 Integration（包括冲突）仍阻止完成，不依赖 Agent 采用了什么执行顺序。
+
+### 验证复用与显式重跑
+
+配置了 VerificationPlan 的项目，默认只复用完整成功、日志可校验，且 Project、
+提交、计划、工具链、目标 ref／基线都精确匹配的证据。存储 `34→35` 将原始 Project
+计划、L1 artifact 和二进制日志保存在迁移审计存档，不再进入当前执行与缓存读取。
+`historical-change-sets` Integration 必须先结算且不存在执行／交付引用，才能将
+完整 payload 转为 `integration.source-retired` Task 事件；旧 ID 不会复用。
+无匹配证据时正常执行。
+计划必须提供 `schemaVersion: 2`，不再包含 `l1` 或 `record/reuse/enforce` 模式。
+
+新建操作时显式要求重跑：
+
+```sh
+yui task integration start <task> --work-item <id> --strategy ff --rerun-checks
+yui task upstream integrate <task> --project <project> --rerun-checks
+```
+
+该选项是本次 Integration 的不可变意图，不是全局配置开关。`continue` 只消费原先
+接纳的 Job，不会变成重跑。再次执行需创建新尝试，并先结算等价的未完成验证。
+重跑只跳过缓存，不绕过权限、Job 身份、工作区检查或最终目标 CAS。
+显式 `--check` 同样要求实际执行。配置了计划时，它们在计划检查后执行，
+不会被忽略，也不会因命令文本相同而被拒绝。
+非结构化检查不再搜索历史 Job 来替代本次执行。
+
+新执行开始前撤下旧成功。失败如实记录；中断、缺失日志或候选被改写时，
+不会保留可复用成功。Job 和本地执行在发布成功证据前，共同检查候选的精确提交、
+分支和干净状态。v5 L2-only 执行摘要隔离旧证据，不删除原有历史。
+过期的缓存使用者不能恢复旧结果。发布查询查看最新匹配证据，不跳过失败去找旧绿灯。
+缓存只表示当前可复用证据，不充当 Task 执行历史；原 Job 和 Integration 记录独立保留。
+
+公开 upstream CLI 与其他 Integration 命令共用 Controller Job 入口。
+`--latest` 可以返回多个 Project 各自待处理的 Job；应继续返回的每个 Integration ID，
+而不是重新发起 upstream 请求来轮询进度。
+
+Job 的准入、管理操作及启动前检查把非 Leader 限定到当前 Assignment、
+精确 WorkItem 工作区和可写 Project。现有 Job owner 不能表达 Review/replica
+工作区时会明确拒绝，不退回 Task 主工作区。Leader/Operator 管理与已运行 Job 的
+结果结算保持独立。
+
+这些身份只覆盖已声明输入，不是所有外部服务和未跟踪环境的完整指纹。
+外部条件变化、排查偶发失败或用户要求再次检查时，应显式重跑。
+计划不赋予真实模型、付费或共享资源测试授权；复用也不替代 Review、验收或发布权限。
 
 Review 遵循适用的 Candidate 规则或 Task-final 合同以及冻结的 head。确切的 main
 Reviewer Run 持有报告；执行成功不等于语义通过。验收归 Leader。即使默认审查策略
@@ -146,6 +202,18 @@ Force 不验证合并、不验收工作、不证明物理静止、不丢弃脏
 检查后通过显式的精确 owner 资源操作进行安全清理；不隐含后台重试或更广泛的删除
 权限。两条归档路径都保留 Task 历史与恢复信息。已归档的 Task 不能重开。
 
+资源 GC 是独立、显式启用的隔离路径。同一 runtime 子树只移动一次，由父目录
+回执负责恢复完整内容；重复的子目录 registry 记录在同一事务内移除。
+独立 Git worktree 或仍需保留的子资源会阻止移动其父目录，不删除 Task 记录或成果。
+Session 进程归属只读取 SQLite `session_owners`，并校验存活 PID 和启动身份；
+旧 JSON owner 目录不再作为并行来源。
+
+清理计划不是执行授权。Apply 与 purge 在现有 SQLite 写锁内重读 Task 状态、
+受管工作区、active Run 和未结算 Job，并保持写锁直到有界文件操作与 registry
+更新完成。Task 重新打开或新增持久所有者会阻止隔离、删除；无法证明安全时
+保留资源并给出原因。已经隔离、随后重新打开的资源可以恢复。
+不增加后台重试 worker 或第二套持久所有权协议。
+
 `yui task archive-preflight <task> (--integrated|--abandon) [--force] [--json]`
 一次读取归档条件、交付覆盖与各精确 owner 的清理检查。归档前后都可用，获授权的
 Task Leader reader 也可读取。这里的 `--force` 仅选择要检查的行为，不会归档、

package/docs/task-discovery.md

@@ -2,25 +2,24 @@
 
 # Bounded Task discovery
 
-Agents discover candidates with `yui task list --view compact --json`, then
+Agents discover candidates with `yui task list --json`, then
 read the selected Task's Context and original Messages. The catalog is a
 current read, not a summary database, a Context snapshot, an acknowledgement,
 or an execution/acceptance decision.
 
-The explicit compact view keeps `task list --json` and `--verbose` detailed
-outputs unchanged for existing consumers. The built-in Operator uses compact;
-internal interactive selectors retain their complete `{id,title,status}` array
-and read only those columns. Web uses the same compact query at
-`GET /api/dashboard?view=compact`; its existing dashboard and Task detail
-endpoints retain execution, observability, usage and remote-delivery fields.
-No storage schema or migration changes are required.
+The catalog is the only list contract; there is no `--view` selector or
+`--verbose` full-history list. Internal interactive selectors retain their
+complete `{id,title,status}` array and read only those columns. Web uses the
+same query at `GET /api/dashboard`. The per-Task detail endpoint retains
+execution, observability, usage and remote-delivery fields. Discovery itself
+does not change persistent records.
 
 ## Query and page contract
 
 ```sh
-yui task list --view compact --project project-1 --status active --limit 20 --json
-yui task list --view compact --attention openInputs --json
-yui task list --view compact --search "candidate title" --json
+yui task list --project project-1 --status active --limit 20 --json
+yui task list --attention openInputs --json
+yui task list --search "candidate title" --json
 yui task context task-1 --json
 yui task context inspect task-1 --store task --ref task-1 --digest <digest> --json
 yui task message show task-1/message-1 --json