@zq-silk/yui 0.15.12 → 0.16.0

package/dist/workItem/workItem.js

@@ -319,8 +319,7 @@ export function validateWorkItem(workItem) {
         "updatedAt",
         "endedAt",
         "acceptedCandidateId",
-        "currentCandidateId",
-        "historicalState"
+        "currentCandidateId"
     ], "WorkItem");
     if (workItem.schemaVersion !== 15)
         throw new Error("WorkItem must use schemaVersion 15.");
@@ -397,16 +396,6 @@ export function validateWorkItem(workItem) {
     if (workItem.currentCandidateId !== undefined
         && !candidateIds.has(workItem.currentCandidateId))
         throw new Error("Current Candidate is missing.");
-    if (workItem.historicalState !== undefined) {
-        const historical = workItem.historicalState;
-        if (!["pending", "running", "awaiting_acceptance", "completed", "failed", "retired"].includes(historical.status)) {
-            throw new Error("Historical Work Item status is invalid.");
-        }
-        if (historical.outcome !== undefined)
-            requireText(historical.outcome, "Historical outcome");
-        if (historical.endedAt !== undefined)
-            requireTimestamp(historical.endedAt, "Historical endedAt");
-    }
     if (workItem.outcome !== undefined)
         requireText(workItem.outcome, "Work item outcome");
     requireTimestamp(workItem.createdAt, "Work Item createdAt");

package/docs/architecture/capabilities-and-resources.md

@@ -105,6 +105,18 @@ failure contract.
 
 ## CLI and Web
 
+Ordinary Global CLI operations require the Role's current native Session;
+an old Manifest is a context pointer, not continuing write authority. Historical
+self-context reads and the explicit offline diagnostic/recovery routes remain
+available. Home configuration and resource-GC mutations belong to the user or
+current Operator, never a Task Worker. Configuration reads remain available.
+
+Managed Task commands cannot name a different Task. Independent Brief,
+Decision, Milestone, Event and Job reads share Context's readable references;
+an Assignment does not gain a wider view by selecting another query command.
+Job read RPCs carry an explicit caller, and the Controller enforces the scope.
+Current WorkItem Jobs remain visible to their assigned Worker.
+
 A Surface contribution is derived from the Registry's currently authorized
 catalog; there is no second catalog or Host. A CLI contribution uses the
 capability's original name. A Web panel accepts only controlled text, an HTTP(S)
@@ -125,8 +137,8 @@ a way for an Agent or plugin to bypass those boundaries.
 Read-only dashboard, Context and query-panel projections remain separate from
 these mutations. A query panel cannot borrow the browser's user authority to
 mutate state or manage plugins. Task controls share the public CLI's domain
-commands; Global Role controls share the Global handler but currently lack a
-registered top-level CLI path. Message submission intent
+commands; Global Role controls share the Global handler with
+`yui role message queue/steer` and `yui role interrupt`. Message submission intent
 (`record / discuss / develop`, default `discuss`) is
 separate from [input timing](../managed-turn-and-session-runtime.md#input-timing-queue-steer-and-interrupt).
 Transport acceptance does not establish implementation or Task acceptance.

package/docs/architecture/capabilities-and-resources.zh-CN.md

@@ -74,6 +74,16 @@ actual 可以为空，必须显式激活。原 Task 可以发现并调用新能
 
 ## CLI 与 Web
 
+普通 Global CLI 操作要求 Role 当前的原生 Session；旧 Manifest 只是 Context
+指针，不是持续写权限。历史 Session 的自身 Context 读取，以及明确的离线诊断、
+恢复入口仍可使用。Home 配置与资源 GC 修改属于用户或当前 Operator，不能由
+Task Worker 执行；配置读取保持可用。
+
+受管 Task 命令不能指定其他 Task。独立的 Brief、Decision、Milestone、Event
+和 Job 查询复用 Context 的可读引用，不能通过换查询入口扩大 Assignment
+视图。Job 读取 RPC 必须携带调用者，由 Controller 执行范围检查；
+Worker 仍可读取其当前 WorkItem 的 Job。
+
 Surface contribution 由 Registry 当前获授权目录派生，没有第二份目录或 Host。
 CLI contribution 使用能力原名称。Web panel 只接受受控 text、HTTP(S) link 或
 JSON query 描述，不接受作者脚本或任意 HTML。
@@ -90,7 +100,7 @@ Role 显式 `queue / steer / interrupt`。受管 Agent 的能力 RPC 仍使用
 
 只读 dashboard、Context 和查询面板投影与这些修改分开。查询面板不能借浏览器的
 用户权限修改状态或管理插件。Task 控制复用公开 CLI 领域命令；Global Role 控制复用
-Global 处理器，但目前缺少已注册的顶层 CLI 路径。消息提交意图
+Global 处理器，与 `yui role message queue/steer` 和 `yui role interrupt` 共用入口。消息提交意图
 （`record / discuss / develop`，默认 `discuss`）与
 [输入时机](../managed-turn-and-session-runtime.zh-CN.md#输入时机queuesteer-与-interrupt)
 分开。传输接受不证明需求已实施或 Task 已验收。

package/docs/managed-turn-and-session-runtime.md

@@ -98,6 +98,42 @@ candidates retain visible nondelivery reasons. Explicit handoff only targets an
 already-dispatched successor for the same work. Replicated Producer/synthesis
 lineage is not silently rewritten by a message.
 
+Rejected Leader notifications retain their original input and failure diagnosis.
+Deterministic startup failures do not automatically retry; only typed runtime
+contention remains deferred. New messages and a Controller restart do not replay
+the rejected claim. After correcting the cause, explicitly retry its exact wake:
+
+```sh
+yui task wake show <task> <wake>
+yui task wake retry <task> <wake> --reason "<what was corrected>"
+```
+
+Retry returns the rejected batch and later queued input to the existing mailbox;
+it does not rewrite the old wake as accepted or replace a Session. Current runtime
+authority and readiness checks still apply. Model/effort validation rejections show the
+native model options and a command to inspect the full current catalog.
+
+Pre-Run launch failures and native Provider rejections both retain a
+`runtime.agent-error` fact. Notification delivery references that original error
+instead of creating a second copy of the cause. `task event show` supplies the
+scoped capability-query pointer in both human and JSON output; `wake show`
+links the same fact. An unavailable Leader notifies the existing Operator
+channel once; Worker/Reviewer failures use the existing Leader channel. No new
+recovery Agent is started, and there need not be a Run or Session to record the
+failure.
+
+Storage 35→36 archives original historical error payloads and marks their
+unrecorded launch configuration as unavailable. It never reconstructs old model,
+account or settings choices from current Roles.
+
+Storage 36→37 narrows that context to native metadata selectors and the requested
+model/effort. Full old snapshots remain in migration audit, not in the active
+reader. Reading a failure's model options does not validate Task permissions,
+Review state, workspace entries or the current Session bootstrap protocol.
+The three failure ingresses retain their native fencing/classification, while
+record creation and deduplication share one writer and supervisor notices use
+the existing event-routing boundary.
+
 Unknown Leader notifications preserve their wake and input window:
 
 ```sh
@@ -109,11 +145,41 @@ Resolve releases the claim after native-effect fences are clear. It neither
 replays the notification nor invents acceptance or completion. Independent
 Role work and legal local facts are not a Task-wide recovery lock.
 
+Wake status records notification delivery, not Message implementation. For
+ordinary Leader notifications, `consumed` means native acceptance. Native Turn
+completion and Task delivery need their own runtime evidence and durable results.
+A rejected wake stays `dispatched` with its claim until explicit retry or Session
+replacement; an explicitly released historical wake can remain `dispatched`
+without a claim. Unknown acceptance cannot use `wake retry`.
+Session replacement preserves queued input for a new wake and current Context;
+it does not retroactively mark an old wake accepted. Late receipts cannot settle
+the successor's batch. While Session cleanup is pending, new input remains queued.
+Inspect the wake, `notification.delivery` events, current mailbox and Session
+together; do not require one final response per historical wake.
+
+Current wakes are notification-only. Run completion cannot consume a wake, and
+the first notification window starts at Task creation. Retired Run-linked wake
+records remain in Task events with their original ID and payload, not as a
+second active wake format.
+
 ## Input timing: queue, steer and interrupt
 
 Submission intent (`record / discuss / develop`) decides how a requirement is
 routed. Input timing decides when an already-authorized input reaches a Role;
 it does not activate a Task, expand an Assignment or upgrade planning authority.
+Save-only input uses `message send --intent record`; `--wake-policy` is removed.
+Unkeyed Draft Message edits preserve submission intent. `record` and `develop`
+edits never start planning or create/retry activation; `discuss` edits use the
+same activation/planning routing as a discussion submission. A pending or failed
+activation therefore keeps the edited discussion waiting.
+
+A Message with a submission key, queue/steer request, or interrupt-then handoff
+has immutable content: submit a new Message with a new request ID to change it.
+This preserves the original retry comparison and receipt without adding a
+second stored representation of input. Updating to the identical body is a
+no-op, with no event, queue change or Controller notification. Current stored
+user/operator Messages always have an intent; changing that intent also requires
+a new explicit submission.
 The [authenticated Web controls](architecture/capabilities-and-resources.md#cli-and-web)
 use the same three operations as the CLI.
 
@@ -127,13 +193,16 @@ Inspect the Session before selecting a live target:
 
 ```sh
 yui task role session inspect <task> <role>
-yui task message queue <task> "<continuation>" --request-id <id> --to leader
+yui task message queue <task> "<continuation>" --request-id <id>
 yui task message steer <task> "<correction>" --request-id <id> --to leader --expected-target <turn>
 yui task role interrupt <task> <role> --expected-target <turn> --request-id <id> [--then-message <task/message>]
 ```
 
-Worker/Reviewer messages retain their existing `--work-item` or `--review-round`
-association. Reusing a request ID with different content or a different target
+Ordinary Leader `queue` input omits `--to`. An explicit `--to <role>` (including
+`leader`) addresses an existing Assignment and requires `--work-item` or
+`--review-round`; a Message cannot establish that Assignment. `steer` still
+requires an explicit Role and exact live target.
+Reusing a request ID with different content or a different target
 is a conflict. `steer` and `interrupt` never silently retarget, replace a Session,
 kill a process or fall back to another action. No live managed Turn yields
 `NO_ACTIVE_TURN`; stale targets and unsupported control remain explicit outcomes.
@@ -147,12 +216,12 @@ uncertainty cannot.
 
 Global Roles use the same three actions with their own owner and Session,
 without inventing a Task or Run. The local-user Web surface exposes them through
-the shared Global Role handler. There is a current CLI availability gap:
-`src/cli.ts` implements `yui role message queue|steer` and `yui role interrupt`,
-but `src/cli/commandCatalog.ts` does not register the top-level `role` command,
-so public CLI routing rejects these paths as unknown. They are not usable CLI
-examples; report this gap rather than fabricating a Task/Run or borrowing the
-browser's user authority. New controlled Global Sessions use the Host console.
+the shared Global Role handler. The public CLI exposes
+`yui role message queue|steer <role> <text>` and `yui role interrupt <role>`.
+Queue/steer require `--request-id`; steer/interrupt require `--expected-target`.
+These commands retain the caller's existing Session authority; do not fabricate
+a Task/Run or borrow the browser's user authority. Configuration remains under
+`config role`, lifecycle under `session`. New controlled Global Sessions use the Host console.
 A live unmanaged Session is not silently adopted; an explicit Session lifecycle
 action is needed first.
 
@@ -188,7 +257,7 @@ preserve execution history; external edits notify the Leader, while its own
 planning edits do not create a self-wake.
 
 New Draft Roles use a Task-specific planning directory under
-`<YUI_HOME>.task-runtimes/planning`, outside the control Home and delivery trees.
+`<YUI_HOME>/runtime/task-runtimes/planning`, separate from durable control data and delivery trees.
 A planning Run can use `task activation request` to persist intent and return an
 `afterPlanningRun` reference immediately. Its terminal releases the request for
 Controller admission; cancelled intent is not resurrected.
@@ -201,6 +270,10 @@ the Projects still receive managed worktrees. `scratch` selects a Task-owned
 directory. `local` requires a registered local Resource and its grant; a Project
 ID is not a local Resource ID.
 
+`task activate` is foreground adoption of an existing request, not an alternative
+way to create activation intent. A request-free Draft is rejected before resource
+preparation; the command does not invent an environment plan or request ID.
+
 Resource preparation precedes the atomic adoption of Task status and workspace
 ownership. A failed adoption records a failed request and notifies the Leader
 with durable facts; it does not repeatedly prepare resources on unchanged

package/docs/managed-turn-and-session-runtime.zh-CN.md

@@ -84,6 +84,33 @@ owner Run。当 Role 忙碌时，保存会返回而不打断它。一旦它可
 显式 handoff 只针对同一工作已派发的后继。复制的 Producer/综合血缘不会被一条消息
 静默改写。
 
+被拒绝的 Leader 通知保留原始输入和失败原因。确定性的启动错误不再自动重试，
+只有明确的运行时资源争用可以延后再试。新消息和 Controller 重启不会重放被拒绝
+的认领。修正原因后，显式重试对应的 wake：
+
+```sh
+yui task wake show <task> <wake>
+yui task wake retry <task> <wake> --reason "<已修正的原因>"
+```
+
+retry 把被拒绝批次及后续排队输入交回现有 mailbox，不把旧 wake 改成已接受，
+也不替换 Session；当前运行权限和就绪检查仍然生效。模型／effort 校验拒绝会显示原生
+报告的模型选项，并提供查询完整当前目录的命令。
+
+没有 Run 的启动失败与原生 Provider 拒绝都保留规范的 `runtime.agent-error` 事实。
+通知投递引用该原始错误，而不复制第二份原因。`task event show` 的人类和 JSON 输出
+都提供有作用域的能力查询入口，`wake show` 也链接同一事实。无法接收的 Leader 将
+错误通过既有 Operator 通道通知一次；Worker／Reviewer 仍通知 Leader。不启动新的
+恢复 Agent，也不为了记录错误制造 Run 或 Session。
+
+存储 `35→36` 迁移保留历史错误原始 payload，并将当时未记录的启动配置标为不可用，
+不会从当前 Role 猜测过去的模型、账户或 settings 选择。
+
+存储 `36→37` 将该上下文收窄为原生元数据查询选项和请求的模型／effort。旧完整快照
+留在迁移审计中，不由运行时双读。查看模型选项不再校验 Task 权限、Review 状态、
+工作区条目或当前 Session 引导协议。三类错误入口保留各自的原生身份检查与分类，
+错误创建、去重统一一个写入入口，上级通知统一使用事件路由边界。
+
 未知的 Leader 通知保留其唤醒和输入窗口：
 
 ```sh
@@ -94,11 +121,33 @@ yui task wake resolve <task> <wake> --reason <quiescence-evidence>
 resolve 在原生效果围栏清除后释放该认领。它既不重放通知，也不编造接受或完成。独立的
 Role 工作和合法的本地事实不是一把 Task 范围的恢复锁。
 
+wake 状态记录通知投递，不记录 Message 的实施结果。普通 Leader 通知的 `consumed`
+表示原生接受；原生 Turn 完成与 Task 交付应分别依据运行证据和持久结果判断。
+被拒绝的 wake 保持 `dispatched` 并保留 claim，直到显式重试或 Session 替换；
+已显式释放的历史 wake 可以保持 `dispatched` 而不占用 claim。
+接受状态未知的通知不能用 `wake retry` 重放。Session 替换把待投递输入
+保留给新 wake 与当前 Context，不会追溯把旧 wake 标成已接受；旧回执也不能结算
+新批次。Session 清理期间，新输入保持排队。检查时应结合 wake、
+`notification.delivery` 事件、当前 mailbox 与 Session，不应要求每个历史 wake
+都对应一条最终回复。
+
+现行 wake 只表示通知，Run 完成不能消费 wake；首次通知窗口从 Task 创建时间开始。
+退役的 Run-linked wake 通过 Task 事件保留原 ID 和完整原文，不作为第二种活动 wake 格式。
+
 ## 输入时机：queue、steer 与 interrupt
 
 提交意图（`record / discuss / develop`）决定需求如何路由。输入时机决定一条已经
 获授权的输入何时到达 Role；它不激活 Task、不扩大 Assignment，也不提升 planning
-权限。[经认证的 Web 控制](architecture/capabilities-and-resources.zh-CN.md#cli-与-web)
+权限。仅保存输入使用 `message send --intent record`，`--wake-policy` 已移除。
+未绑定请求身份的 Draft Message 仍可编辑，保留原提交意图。编辑 `record` 或
+`develop` 不会启动规划、创建或重试激活；编辑 `discuss` 复用讨论提交的激活／规划
+路由，因此已有 pending 或 failed 激活时，编辑后的讨论仍等待激活处理。
+
+带 submission key、queue/steer 请求或 interrupt-then 交接的 Message 正文不可变；
+需要改内容时，应使用新的 request ID 提交新消息。这保留原请求的判重依据和回执，
+不新增第二套输入存储。更新为相同正文是无操作：不写事件、不改队列、不通知
+Controller。现行 user/operator 消息必须存有意图；改变意图同样需要显式提交新输入。
+[经认证的 Web 控制](architecture/capabilities-and-resources.zh-CN.md#cli-与-web)
 与 CLI 使用同样的三种操作。
 
 | 动作 | 效果 | 不证明什么 |
@@ -111,13 +160,15 @@ Role 工作和合法的本地事实不是一把 Task 范围的恢复锁。
 
 ```sh
 yui task role session inspect <task> <role>
-yui task message queue <task> "<continuation>" --request-id <id> --to leader
+yui task message queue <task> "<continuation>" --request-id <id>
 yui task message steer <task> "<correction>" --request-id <id> --to leader --expected-target <turn>
 yui task role interrupt <task> <role> --expected-target <turn> --request-id <id> [--then-message <task/message>]
 ```
 
-Worker/Reviewer 消息保留既有的 `--work-item` 或 `--review-round` 关联。同一个
-request ID 若换正文或目标会产生冲突。`steer` 与 `interrupt` 不会静默改目标、
+普通 Leader `queue` 输入省略 `--to`。显式 `--to <role>`（包括 `leader`）指向既有
+Assignment，必须带 `--work-item` 或 `--review-round`；Message 不能创建 Assignment。
+`steer` 仍需要显式 Role 与精确实时目标。同一个 request ID 若换正文或目标会产生冲突。
+`steer` 与 `interrupt` 不会静默改目标、
 替换 Session、杀进程或回退到另一动作。没有活动受管 Turn 时返回 `NO_ACTIVE_TURN`；
 陈旧目标与不受支持的控制也保持为显式结果。
 
@@ -127,11 +178,11 @@ request ID 若换正文或目标会产生冲突。`steer` 与 `interrupt` 不会
 可以显式选择新的控制；不确定性不允许重放。
 
 Global Role 使用同样的三种动作和自己的 owner、Session，不虚构 Task 或 Run。
-本地用户 Web Surface 通过共享 Global Role 处理器暴露这些动作。目前 CLI 存在可用性
-缺口：`src/cli.ts` 实现了 `yui role message queue|steer` 和 `yui role interrupt`，
-但 `src/cli/commandCatalog.ts` 没有注册顶层 `role`，因此公开 CLI 路由会拒绝这些路径，
-报告 unknown command。它们不是可用的 CLI 示例；应报告该缺口，不虚构 Task/Run 或
-借用浏览器用户权限。新的受控 Global Session 使用 Host console。活动的非受管 Session
+本地用户 Web Surface 通过共享 Global Role 处理器暴露这些动作。公开 CLI 提供
+`yui role message queue|steer <role> <text>` 和 `yui role interrupt <role>`。
+queue/steer 要求 `--request-id`，steer/interrupt 要求 `--expected-target`。
+这些命令保留调用者现有 Session 权限，不虚构 Task/Run 或借用浏览器用户权限。
+配置仍使用 `config role`，生命周期使用 `session`。新的受控 Global Session 使用 Host console。活动的非受管 Session
 不会被静默采用，需要先执行显式的 Session 生命周期操作。
 
 ## 精确结果
@@ -158,8 +209,8 @@ Candidate 和 ReviewRound 保留来源；Core 不从散文中推导语义接受
 仍是通知。Operator 提交和直接的 Task 消息都能到达那个 Session。Draft 计划/WorkItem
 编辑保留执行历史；外部编辑通知 Leader，而它自己的规划编辑不创建自唤醒。
 
-新的 Draft Role 使用位于 `<YUI_HOME>.task-runtimes/planning` 下、专属于该 Task 的规划
-目录，在控制 Home 和交付树之外。一个 planning Run 可以用 `task activation request`
+新的 Draft Role 使用位于 `<YUI_HOME>/runtime/task-runtimes/planning` 下、专属于该 Task 的规划
+目录，与持久控制数据和交付树分开。一个 planning Run 可以用 `task activation request`
 持久化意图并立即返回一个 `afterPlanningRun` 引用。它的终态把该请求释放给 Controller
 准入；被取消的意图不会复活。Leader 也可以在普通讨论中请求激活而无需 AgentRun：一旦
 原生输入结算，Controller 就采用其持久意图。不需要合成 Run 或额外的用户“continue”。
@@ -168,6 +219,9 @@ Candidate 和 ReviewRound 保留来源；Core 不从散文中推导语义接受
 获得受管 worktree。`scratch` 选择一个 Task 拥有的目录。`local` 需要一个已登记的 local
 Resource 及其 grant；Project ID 不是 local Resource ID。
 
+`task activate` 是对已有请求的前台采用，不是创建激活意图的另一条路径。
+没有请求的 Draft 会在资源准备前被拒绝；命令不代填环境计划或 request ID。
+
 资源准备先于对 Task 状态和工作区所有权的原子采用。一次失败的采用记录一个失败请求，
 并用持久事实通知 Leader；在失败未变时它不反复准备资源。Leader 选择显式重试或修正后的
 请求。成功激活同样为 Leader 留下一条交付通知。激活绝不把活动 Session 变更为交付权限。

package/docs/plugin-sdk.md

@@ -374,8 +374,10 @@ Publication rechecks the complete contribution, dependencies and permissions
 again. A failure does not change the existing directory; a competing
 activate/disable makes a late candidate refuse to publish. After a successful
 publication, the old generation only serves existing references and is disposed
-once drained; a cleanup failure keeps a diagnostic Artifact and neither rolls
-back the new Provider nor pretends the current instance is still unpublished.
+once drained. A cleanup failure is retained on that plugin's diagnostic channel
+with the old generation identity, even if another replacement has already
+published. It is not a Task Artifact, does not roll back the new Provider, and
+does not pretend the current instance is still unpublished.
 
 ## Storage and other ingress
 

package/docs/provider-runtime.md

@@ -91,7 +91,9 @@ The codec must not implement another Task/Run Store or invent native Turn IDs.
 Model, effort and permission requests are compiled against the peer's offered
 configuration axes and checked after application. Setters can change other axes;
 final observed values must still satisfy the requested launch before prompt.
-An acknowledgement without a reported value is weaker than an observed match.
+New and loaded Sessions must report `configOptions` (an empty array is valid).
+Configuration uses `session/set_config_option`; mode-only peers are unsupported.
+An acknowledgement without current reported values cannot satisfy a requested change.
 Unknown ACP products do not inherit a guessed bypass mode from another product.
 
 Yui distinguishes three configuration layers:

package/docs/provider-runtime.zh-CN.md

@@ -73,8 +73,10 @@ ACP 协商初始化和 Session 能力，打开或加载一个确切的 Session
 Task/Run Store，也不得编造原生 Turn ID。
 
 model、effort 和权限请求依据 peer 提供的配置轴编译，并在套用后检查。setter 可以
-改变其他轴；最终观察到的值在 prompt 之前仍必须满足请求的启动。一个没有回报值的
-确认弱于一次已观察的匹配。未知的 ACP 产品不从另一个产品继承猜测的旁路模式。
+改变其他轴；最终观察到的值在 prompt 之前仍必须满足请求的启动。
+新建和加载 Session 都必须回报 `configOptions`（可以为空数组），配置只使用
+`session/set_config_option`，不再支持 mode-only peer。仅确认调用、没有当前回报值
+不能证明请求的配置已生效。未知的 ACP 产品不从另一个产品继承猜测的旁路模式。
 
 Yui 区分三个配置层：
 

package/docs/release-workflow.md

@@ -20,12 +20,193 @@ Two task-level record families back it:
   exact source (repository + pinned commit, optionally an artifact), an
   immutable ordered step plan, and one persisted record per step.
 
-The engine (`src/release/releaseWorkflowEngine.ts`) is a pure library; the
+The engine (`src/release/releaseWorkflowEngine.ts`) owns persisted transitions and the workflow lock; the
 `yui task workflow` and `yui task grant` commands drive it. Every external
 system sits behind `ReleaseWorkflowPorts`
-(`src/release/releaseWorkflowPorts.ts`), so the whole workflow is testable
-with deterministic fakes and no real GitHub, npm, git, Controller, or process
-side effect.
+(`src/release/releaseWorkflowPorts.ts`). Disposable SQLite and deterministic
+external ports exercise recovery without real GitHub, npm, git, Controller,
+or model effects.
+
+## Pre-1.0 contract cleanup
+
+Version 0.16.0 retires runtime compatibility before the final
+1.0 baseline cutover. It does not reset storage numbering.
+Storage 27→28 normalizes only provable singleton Role dispatch dedupe keys;
+the old migration ledger, Messages, Task results and unconfirmed effects remain
+unchanged. Ordinary opens require storage 37. Existing Homes advance only through
+the explicit upgrade boundary; no runtime dual-reader is added.
+
+This is a breaking pre-1.0 change:
+
+- `message send` uses `--intent`; `--wake-policy` is no longer accepted by the
+  CLI or capability API. Draft edits preserve intent.
+- Internal command integrations implement `notifyMailboxChanged`; the Task-only
+  notification adapter has been removed with its callers updated.
+- ACP peers must report `configOptions`; there is no `modes`/`set_mode` path.
+- Release recovery requires a pinned Home and installation prefix. Unpinned
+  identities remain unknown, and incomplete handover locks remain fenced.
+- Development link/unlink requires the current registry. It does not discover
+  or adopt older NVM registrations or reconstruct orphan links.
+- GC no longer discovers retired deployment layouts or reconstructs removed
+  worktrees. Unsupported quarantine evidence is retained, never purged as if
+  it were a current move receipt.
+- `task activate` consumes an existing request; no request means no resource
+  adoption. Request creation, deferred admission and atomic workspace adoption
+  remain separate, using the same current boundary.
+- `task integration queue` and its state machine are removed. The Agent chooses
+  each WorkItem result's order and strategy and calls the atomic Integration
+  operations; exact checks, target CAS and completion obligations remain.
+
+Storage 28→29 preserves every former queue payload verbatim in a Task event
+`integration.queue-retired`, with its original queue ID, before dropping the
+active table. Event IDs advance past both the stored counter and existing
+history. This does not accept delivery, generate an Integration or replay work.
+Existing Integrations and Jobs stay intact. Inspect `task event list <task>`
+and the referenced WorkItem/Integration before deciding what remains to do;
+retiring the queue does not settle an unfinished Integration.
+
+Storage 29→30 retires Run-linked wakes into `wake.run-link-retired` Task events
+with the complete original payload. Current notification IDs, delivery status
+and references remain intact, using wake schema 2; Run termination no longer
+consumes notifications. Live Runs, owned retries and unresolved claims referring
+to a retiring wake block both preflight and migration. The migration does not
+stop execution or fabricate acceptance. Global Session sets use an explicit
+`providerBinding: null` when no controlled binding exists.
+
+Storage 30→31 makes every Review's scope explicit. Missing/null scope in a valid
+older WorkItem Review becomes `work-item`; Task-final candidate evidence and
+the old ledger are unchanged. New and retried Reviews always write their scope.
+
+Storage 31→32 removes WorkItem `historicalState` from the current record.
+Before removal, the entire original payload is preserved verbatim in a
+`work-item.execution-state-retired` Task event. Current status, scope, Candidates
+and execution groups are unchanged; no Run or acceptance is created. Unrecognized
+historical shapes fail without changing the record or advancing the ledger.
+
+Storage 32→33 retires the Leader rollout/budget settings and VerificationPlan
+rollout modes. Active plan bodies gain an explicit schema version; their checks
+remain unchanged, while retired Knowledge bodies are preserved. Integration
+records gain explicit `rerunChecks: false`, and shadow reuse counters are removed
+from cached artifacts. Original settings remain recoverable from the explicit
+upgrade backup. This is an approved behavior change, not an assertion that
+`record`, `reuse` and `enforce` meant the same thing.
+
+Admitted `running`/`validating` plan gates block preflight and migration; settle
+them with the old release first. No in-flight Job is relabelled under the new
+proof contract. That cutover's v3 verification-plan digest excluded older cache entries from
+automatic reuse without rewriting historical Job/Integration results or deleting
+their logs. Historical plan interpretation is frozen inside the migration
+directory so earlier migrations keep their original semantics.
+
+The current clean-candidate proof uses a v5 L2-only execution digest. Both local and
+Job-backed verification check candidate cleanliness, branch and exact HEAD
+before publishing reusable success; older cache identities cannot silently pass
+this boundary. Existing records/logs remain readable and admitted Jobs are not
+relabeled under a new digest. Settle old attempts with their matching contract,
+or explicitly abandon them before starting another operation.
+
+The L1 runner, selector and current plan/artifact type branches are removed.
+Storage 34→35 archives the original Project plan payloads and L1 artifacts/logs
+in `storage_migration_archive`, then adopts VerificationPlan schema 2 without L1.
+The archive is raw audit data, not an alternate execution reader or cache.
+Settled historical ChangeSet-source Integrations become full-payload Task Events;
+live workspaces, unsettled Jobs and adoption references block their retirement.
+The complete earlier migration ledger remains unchanged.
+
+Session custody now has one source, SQLite. Legacy `launch-env` owner rows or
+files in `runtime/session-owners` block this cutover: use the old release to
+inspect and settle their exact resources, then explicitly archive obsolete
+files outside the active Home. The migration does not kill, infer ownership,
+repair malformed records or rewrite immutable Session Manifests.
+
+Storage 35→36 preserves historical Agent errors and explicitly marks missing
+failure configuration as unavailable. Storage 36→37 narrows recorded failure
+context to native metadata-query inputs, preserving the original snapshot and
+empty optional identity placeholders in migration audit. Current error readers
+do not depend on the execution snapshot protocol or reconstruct missing history.
+Configuration rejection preserves input without automatic retry; an authorized
+Agent can inspect failure-scoped model capabilities, correct the intended
+configuration, and explicitly retry the rejected notification.
+
+`task turn` and the `yui-dev` completion identity are no longer supported.
+Before rollout, replace Sessions whose old Manifest still names `task turn`,
+and explicitly remove/archive old `yui-dev` completion blocks before installing
+current `yui` completion. User shell files are never rewritten by storage migration.
+Host control/event compatibility and updater handover safety remain unchanged.
+
+Storage 33→34 removes Message `wakePolicy` and activation `origin` from current
+records, preserving their original representations in audit Events. Historical
+save-only Messages become `intent: record`; other user/operator Messages without
+intent become `discuss`. Runtime readers never infer a missing stored intent.
+Editing record-only context does not wake the Leader. Completion reads actual
+pending message references, including an explicit handoff of previously saved context.
+
+Draft editing also preserves request identity: messages bound to submission,
+queue/steer or handoff requests cannot change body in place. Use a new Message
+and request ID; identical-body updates are no-ops. Unkeyed discussion edits
+honor pending/failed activation, while develop edits never start planning or
+create/retry activation. These are operation-boundary fixes, not a new storage
+format or a repair of previously edited historical content.
+
+An origin-less pending immediate Draft activation blocks preflight and migration,
+including on a stopped Task. Activate or cancel it explicitly with the old release
+first. An admitted current request needs no second origin gate: cancellation,
+planning deferral, execution state and exact Session authority remain enforced.
+Old origin metadata, including settled-request history, remains in
+`task.activation-origin-retired` Events; this never fabricates authorization.
+
+New `job start` calls require `--request-id`; RPC callers supply `requestId`, and
+the capability boundary supplies its invocation identity. There is no implicit
+content-addressed request or anonymous Job constructor. Existing Jobs retain
+their operation evidence and remain addressable by ID. Retrying the same explicit
+request is idempotent, changed input conflicts, and Integration recovery still
+finds its original Job across Session replacement. Choosing a new request ID is
+an explicit new operation, not recovery of an uncertain earlier result.
+
+Core Scheduler readers and persistence operations are required ports. A missing
+Session/event reader cannot be interpreted as empty evidence or skipped error
+persistence. Task execution and Web projections read the current store directly;
+queue admission requires its Task lifecycle read. Exact dispatch settlement
+remains separate and does not gain an archive gate that could lose late evidence.
+Observer, config, Knowledge and workspace-cleanup Store readers are also required;
+test doubles implement those contracts rather than selecting production fallbacks.
+
+Task listing and `/api/dashboard` now expose only the bounded catalog; remove
+`--view compact` from callers and use per-Task reads for detail. Scheduler
+catalog projections are required internal ports, not optional full-scan adapters.
+Extra `schema.json`/`state.json` files cannot override SQLite's version or be
+used to reset a development Home; upgrades leave unrelated files untouched.
+A missing database in a non-empty Home remains a refusal to initialize.
+Unrecognized writer leases are diagnosed without adoption or deletion.
+
+`controller status` always reports identity and retains the nonzero health exit
+for contradictory storage. `YUI_STATUS_IDENTITY` no longer selects another
+contract. Update-owned lifecycle capture uses the same resource collector
+directly, without requiring the old Home to pass current-schema health.
+
+Additional current boundaries:
+
+- Project/artifact file locks and handover locks require exact process-generation
+  evidence. Missing/invalid owners or unreadable OS identity remain fenced;
+  age alone never proves a creator exited. No PID-only positive fallback remains.
+- PR head lookup uses one `gh pr list --head ... --state open` query. Only an
+  empty, valid array proves absence. Transport errors, malformed identities and
+  multiple matches fail without attempting creation.
+- Existing Git operations cannot be adopted without the Integration's original
+  progress receipt. Preserve their files and diagnose explicitly; current
+  receipt-backed conflict/Job continuation remains supported.
+
+Before rollout, settle old executions and use explicit cleanup for unsupported
+locks, links or quarantines. Preserve those records until their owner and
+disposition are established; the runtime does not choose recovery for them.
+
+The later baseline cutover must first establish a verified bridge/export to the
+chosen current format, then replace the old initialization/migration chain with
+one clean baseline. Only then remove pre-baseline migrations and their historical
+fixtures. Reset the storage baseline once; do not reset it again when tagging
+1.0.0. Keep unknown-version rejection, exact process/Host identity checks and
+durable audit evidence. Version tags and real migration/publication effects
+require their separate release authorization.
 
 ## Authorization model
 
@@ -214,9 +395,11 @@ The key is passed to every `executeStep` call for that step, including
 retries after a confirmed-absent timeout. The port contract requires
 `executeStep` to be idempotent under the same key: a retried attempt must not
 produce a second side effect. The engine side of the contract is stricter
-still — it never calls `executeStep` for a step it has marked `unknown`; it
-re-queries by the recorded identity instead. The fakes record every key, so
-the test suite proves at-most-once execution directly.
+still — it never blindly calls `executeStep` for an `unknown` step; it first
+re-queries by the recorded identity. A deterministic core scenario checks
+uncertain-effect queries, confirmed-step reuse and grant exhaustion against
+real SQLite. This proves those engine boundaries, not the idempotency of real
+external services or every release adapter.
 
 ## Operator guide