@zq-silk/yui 0.15.9 → 0.15.12

package/docs/task-discovery.md

@@ -0,0 +1,102 @@
+<p align="right"><strong>English</strong> | <a href="./task-discovery.zh-CN.md">简体中文</a></p>
+
+# Bounded Task discovery
+
+Agents discover candidates with `yui task list --view compact --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.
+
+## 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 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
+```
+
+`--project` accepts an exact Project ID. Search matches ID, title, tags and
+Project name using SQLite substring comparison (ASCII case-insensitive;
+non-ASCII characters compare literally). Default scope excludes archived
+Tasks; `--all` or `--status archived` includes them. Counts declare that scope,
+not an invisible global total. Status/search/Project/attention filters apply
+to `total` and the returned Tasks, not the scope-wide attention summary.
+
+The default limit is 20, maximum 100. Successful JSON responses, including the
+CLI envelope, fit 32 KiB. UTF-8 summaries are at most 512 bytes; titles are
+at most 256 bytes. Truncation is explicit. IDs, digests and cursors are never
+truncated. Oversized mandatory metadata produces a bounded error, not a
+non-progressing successful page. A missing Brief is reported as missing.
+
+Order is ascending `(createdAt, id)` with SQLite binary ID ordering. Repeat
+all filters and the limit with `--cursor <nextCursor>`. A null cursor ends the
+page sequence; byte limits can end a page before its requested item limit.
+The first page fixes the largest matching creation key. Newer creation keys
+are excluded until refresh. Each later page reads current facts: lifecycle or
+filter membership changes can affect the enumeration. This is not a frozen
+snapshot, and unrelated runtime events do not invalidate a cursor.
+
+Each Task and attention sample has a real Task Context ref
+(`taskId, store, refId, revision, digest`). The digest covers the original
+Task, not the clipped preview or Brief. Read Task Context for the current
+Brief and use Context inspect for a digest-checked original. A changed digest
+is rejected; a ref never grants authority or implies the requirement was read.
+
+## Attention without full history
+
+Every page, including a filtered empty page, reports the same authorized
+catalog's current attention. Each category contains a record/signal count,
+affected-Task count, up to four exact Task refs, omitted-Task-ref count, and a
+filter for enumerating all affected Tasks:
+
+Start that attention query without the previous status/search/Project filters
+and retain its `all` flag. This preserves the declared catalog scope, including
+archived Tasks when explicitly included.
+
+| Category | Current stored facts |
+| --- | --- |
+| `openInputs` | Open InputRequests |
+| `pendingOperations` | Queued/running durable Jobs |
+| `unknownOperations` | Jobs with `unknown-needs-attention` |
+| `executionSignals` | For active/draft Tasks: live Runs, open WorkItems or accepted WorkItems retaining a current replicated group, unresolved/failed Integrations, pending/running/failed Reviews, Leader failure, and pending/processing Leader mailbox |
+
+`executionSignals` is deliberately conservative discovery, **not** the detailed
+execution-status classifier. Healthy live work is included so runtime identity,
+stall, failed-work and recovery attention cannot be hidden behind pagination
+or require scanning every Task's historical events. Counts must not be read as
+failure counts. Open the affected Task for its precise execution state and
+source records; no report text is parsed into status. Web explicitly labels
+these facts and offers category navigation. Selected detail survives paging,
+filtering and refresh; only the detail read can establish absence.
+
+Task Leader Sessions see only their own Task. Assignment-scoped Workers and
+Reviewers use existing authorized Run Context instead of whole-Task discovery;
+the catalog rejects their request before counting. Global non-Operator and
+incomplete managed identities are rejected. Historical Leader diagnostic reads
+retain their original Task scope. A cursor is scope/filter-bound continuation,
+not a credential. Read operations do not consume messages, acknowledge jobs,
+wake Roles or query providers.
+
+## Cost boundary
+
+SQLite queries existing catalog/status indexes and aggregates narrow facts
+before selecting page rows. It does not decode all Task payloads, Runs,
+Messages or Events into JavaScript, build all overviews and delete fields, or
+construct per-Task Context. Only selected Tasks and bounded attention samples
+are decoded and hashed for original refs.
+
+Output and materialized rows are bounded. Database work still scales with
+authorized Tasks and relevant index rows; search can inspect Task/Project JSON
+inside SQLite. Exact refs still cost the selected original Task's payload size.
+These are local cost boundaries, not constant-time or model-effect claims.

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

@@ -0,0 +1,86 @@
+<p align="right"><a href="./task-discovery.md">English</a> | <strong>简体中文</strong></p>
+
+# 有界任务发现
+
+Agent 使用 `yui task list --view compact --json` 发现候选任务，再读取目标
+Task Context 和原始 Message。目录是当前事实的只读视图，不是摘要数据库、
+Context 快照、消息确认、执行判断或验收结论。
+
+显式 compact 视图不改变既有 `task list --json`、`--verbose` 详细输出。
+内建 Operator 采用 compact；交互选择器保持完整的 `{id,title,status}` 数组，
+只读取这些窄字段。Web 通过 `GET /api/dashboard?view=compact` 使用同一查询；
+原 dashboard 和 Task 详情接口保留执行、观测、用量和远端交付字段。
+本功能不改变持久 schema，无需迁移。
+
+## 查询和分页合同
+
+```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 "候选标题" --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
+```
+
+`--project` 接受精确 Project ID。搜索按 SQLite 子串匹配 ID、标题、标签和
+Project 名称：ASCII 不区分大小写，非 ASCII 字符按字面比较。缺省范围排除
+归档 Task；`--all` 或 `--status archived` 纳入归档。计数明确属于该范围，
+不泄漏不可见的全局总数。状态、搜索、Project 和关注分类只筛选 `total`
+及任务行，不缩小范围内的关注汇总。
+
+缺省每页 20 项，最多 100 项。成功 JSON 响应连同 CLI envelope 不超过
+32 KiB；摘要最多 512 UTF-8 字节，标题最多 256 字节，裁剪明确标记。
+ID、digest 和 cursor 不裁剪。必要元数据过长时返回有界错误，不成功返回
+无法前进的空页。Brief 缺失会明确显示。
+
+顺序是 `(createdAt,id)` 升序，ID 按 SQLite binary 排序。后续请求带
+`--cursor <nextCursor>`，并保留全部筛选参数和 limit。null cursor 表示结束；
+字节预算可能使实际条数少于 limit。首页固定最大匹配创建键，较新创建键
+留到刷新后读取。各页仍读取当前状态：生命周期和筛选成员变化可能影响枚举；
+这不是冻结快照，不会因为无关运行时事件而作废游标。
+
+每个任务和关注样本携带真实 Task Context ref：
+`taskId,store,refId,revision,digest`。digest 覆盖原 Task，不是裁剪预览或
+Brief。当前 Brief 通过 Task Context 读取；Context inspect 可校验 digest
+后展开原文。digest 变化会拒绝旧引用；引用不赋予权限，也不表示需求已读。
+
+## 不扫描全历史也不遗漏关注入口
+
+每页（包括筛选后无匹配的空页）都返回同一授权目录范围的当前关注事实。
+每类包括记录/信号数量、涉及 Task 数量、最多四个精确 Task ref、
+省略的 Task ref 数量，以及枚举全部相关 Task 的筛选入口：
+
+启动该关注查询时清除先前的状态、搜索、Project 筛选，并保留其 `all` 标记，
+从而保持声明的目录范围，包括此前明确纳入的归档任务。
+
+| 分类 | 当前存储事实 |
+| --- | --- |
+| `openInputs` | 未解决 InputRequest |
+| `pendingOperations` | queued/running durable Job |
+| `unknownOperations` | unknown-needs-attention Job |
+| `executionSignals` | active/draft Task 中的活跃 Run、open WorkItem 或仍含当前复制执行组的 accepted WorkItem、未解决或失败 Integration、pending/running/failed Review、Leader failure、pending/processing Leader mailbox |
+
+`executionSignals` 是保守的发现入口，**不是**详情的执行状态分类器。
+健康的活跃工作也会被包括，从而不会因为分页而藏住运行身份、停滞、
+工作失败或恢复相关的关注入口，也不必先扫描所有 Task 历史 Event。
+这些计数不是失败计数；请打开任务读取精确执行状态和来源记录。
+不解析报告正文推导状态。Web 明确标示这些事实并提供分类导航。
+已选详情不因分页、筛选或刷新而丢失；只有详情读取可以确认目标不存在。
+
+Task Leader Session 只能发现自己的 Task。Assignment-scoped Worker 和
+Reviewer 使用既有授权 Run Context，目录会在计数前拒绝其全 Task 发现请求。
+非 Operator 的 Global Session 和不完整的受管身份也会被拒绝。
+历史 Leader 的诊断读取保持原 Task 范围。游标绑定范围及参数，不是凭证。
+读取不会消费 Message、确认 Job、唤醒 Role 或查询外部 provider。
+
+## 成本边界
+
+SQLite 在现有目录及状态索引上聚合窄事实，再选取当前页。
+不会在 JavaScript 中解码全部 Task 正文、Run、Message、Event，不会先
+构造所有重型 Overview 再删字段，也不逐 Task 构造 Context。
+仅当前页和有界关注样本会解码原 Task，并计算精确 ref。
+
+输出和物化行有界；数据库工作量仍随授权 Task 和相关索引行增加，
+搜索可能在 SQLite 内检查 Task/Project JSON。精确引用仍需承担选中
+Task 原正文大小的成本。这些是本机成本边界，不是恒定时间或模型效果承诺。

package/docs/testing/verification-levels.md

@@ -53,12 +53,52 @@ 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.
+    Archive preflight preserves durable records and the Git index, distinguishes
+    frozen-result differences, and cleanup rechecks moved heads, owner branches
+    and new dirt. Read-only Git status never executes configured clean filters.
+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.
+18. Project maintenance waiters yield to the holder, use a shared 60-second
+    monotonic budget with independent 200–500ms jitter, and cancel on Controller
+    stop without losing activation intent. Disposable lock/SQLite/Git fixtures
+    cover exclusion, partial release and under-lock revalidation; injected time
+    checks the minute-long deadline without sleeping for a minute. Competing
+    activations each adopt their own workspace without replaying Git work.
+19. Task usage distinguishes zero, partial and unknown across exact requests,
+    cumulative baselines, Session replacement and native child overlap. A small
+    event fixture checks direct Leader/parallel time semantics and the shared
+    CLI/Web/audit lifetime projection without collecting Provider data.
 
 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.
+Archive preflight adds three small disposable Git/SQLite scenarios (about
+one second of test bodies); broader owner/diagnostic combinations remain
+temporary validation evidence, not a second permanent matrix.
 
 ## Skill and instruction changes
 

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

@@ -43,10 +43,33 @@ Yui 是一个单用户本地产品。永久验证保护关键的 happy path 和
 14. Claude 收到其原生环境和 settings 路径，而没有被注入的认证 helper、被改写的批准
     记录，也没有把 secret 转发给无关适配器；原生认证选择仍归 Claude。环境刷新移除
     已撤销的 key，并把值挡在持久 Task/Role 记录之外。
+15. 普通 Integration 冲突可直接继续；准确 Git 与 Job 证据恢复中断交付，
+    不重放已执行的步骤，也不把已发生的 CAS 与新的验证条件混为一谈。
+16. 明确授权的 force archive 先提交归档，再独立记录清理；不确定输入与晚到
+    结果仍可追溯，归档不使保留资源自动变得可删除。归档预检不改变持久记录或
+    Git index，区分冻结结果差异；清理重查 HEAD、owner 分支和新增脏状态。
+    只读 Git 状态检查不执行配置的 clean filter。
+17. 即使 Host 编译版本的存储代码无法读取 Home，事实仍先进入现有 Inbox；
+    Controller 侧归属校验、ACK 丢失重放和 legacy Host 升级拒绝保护原始执行。
+    独立冻结的 v1 协议生产者在真实 19→22 迁移前后保持同一进程，通过新 discovery
+    分别向两个 Controller 发出认证 RPC，并在断线窗口保留事实。生产 launch 路径
+    在不向 Session 环境导出 Run ID 的前提下保留 scoped 启动证据。该 fixture 代表最低
+    支持的新线协议，不声称已发布的修复前 Host 可以原地热更新。
+    归档与 Host 消费交错时保留完整来源 envelope，不重新打开 Task 或结算原不确定输入。
+18. Project 维护锁等待不阻塞持锁者，使用共享的 60 秒单调时钟预算与每次独立的
+    200–500ms 随机间隔；Controller 停止时取消等待，不丢失激活意图。
+    可丢弃锁、SQLite 和 Git fixture 覆盖排他、部分锁释放及取锁后重校验，
+    注入时钟验证一分钟截止逻辑，不实际等待一分钟；竞争激活各自采用工作区，
+    不重放 Git 操作。
+19. Task 用量在精确请求、累计基线、Session 替换和原生子执行重叠下区分真实零、
+    部分与未知。小型事件 fixture 覆盖直接 Leader/并行耗时，以及 CLI/Web/audit
+    共享的全生命周期投影，不采集 Provider 数据。
 
 把测试阶段保持在秒级；单独度量 TypeScript 构建。新增一个关键回归时记录其增量运行
 时长。这七个恢复边界用例在开发主机上最初约增加 0.4 秒的测试体（独立运行约 0.6 秒，
 含模块启动）。避免在永久套件中使用基于 sleep 的检查或强制的模型/daemon 启动。
+归档预检新增三个可丢弃 Git/SQLite 场景，测试体约一秒；更广的 owner/诊断组合
+保留为临时验证证据，不形成第二套永久矩阵。
 
 ## Skill 与指令变更
 

package/i18n/README.zh-CN.md

@@ -27,7 +27,7 @@ Yui 是面向编程 Agent 的本地控制面。你只需用自然语言把目标
 - **自带 Agent** —— Codex CLI、Claude Code CLI 和 ACP 通过统一边界接入，
   可替换而不丢失 Task。
 - **本地优先、私有** —— 一切运行在你自己的机器上，面向单个受信任用户；
-  Web 视图仅本地回环、只读。
+  Web 仅本地回环，包含只读视图和经认证的用户控制。
 - **默认隔离** —— 仓库改动发生在受管 Git worktree 中，稳定 checkout 保持只读。
 
 > **状态：** 尚未发布 1.0（0.15.x）。CLI 与配置在版本之间仍可能变化；每次升级
@@ -122,7 +122,10 @@ Agent 可以重新读取任务上下文，继续兼容的 Session，或在必要
 进程失败不会抹掉任务，结果不确定的投递也不会被静默重复。
 
 想直观看进展，可以在另一个终端运行 `yui web`。本地 Web 展示同一份任务与
-待回答问题，不是另一套需要同步的任务系统。
+待回答问题，也允许发送消息、回答问题，以及显式 queue、steer 或 interrupt Task 输入。
+这些经认证的 Task 控制复用 CLI 的相同操作，不是另一套需要同步的任务系统。
+详见 [Web 权限](../docs/architecture/capabilities-and-resources.zh-CN.md#cli-与-web)
+和[输入时机](../docs/managed-turn-and-session-runtime.zh-CN.md#输入时机queuesteer-与-interrupt)。
 
 ## 架构
 
@@ -225,7 +228,7 @@ Yui 为你组织的东西 —— 是持久对象，而不是进程：
      它负责搬运工作、记录事实——但从不判断回答好坏
 
   Agent 在 Project 中工作：只读 checkout + 隔离 worktree。
-  Web 视图（yui web）：对存储的本地回环、只读投影。
+  Web（yui web）：本地回环视图 + 经认证的用户控制。
 ```
 
 ### 分层设计
@@ -234,7 +237,7 @@ Yui 为你组织的东西 —— 是持久对象，而不是进程：
 
 ```text
   体验层 Experience   —  你如何交互
-    CLI（Operator）· Web（本地回环、只读）· 原生 Agent 会话
+    CLI（Operator）· Web（本地回环、经认证）· 原生 Agent 会话
     采集输入 · 展示事实 · 确认操作 · 调用能力
         ▼
   决策层 Intelligence —  谁来决定
@@ -270,9 +273,12 @@ Yui 为你组织的东西 —— 是持久对象，而不是进程：
   WorkItem  open ─▶ accepted ─▶ retired
 
   Draft 只保存规划；激活后才采用交付工作区。
-  归档需要工作已了结、worktree 干净，且不可重新打开。
+  普通归档需要工作已了结、worktree 干净，且不可重新打开。
 ```
 
+明确授权的 force 归档可以保留未解决证据与不安全资源；它不证明交付，也不授权删除
+这些资源。详见[归档合同](../docs/task-delivery.zh-CN.md#归档)。
+
 ## 设计原则
 
 ### Agent 做判断，Yui 保存工作事实
@@ -321,8 +327,8 @@ Yui 面向一个受信任本地用户，不是 OS 沙箱，也不是远程多用
 
 ## 深入了解
 
-[总体架构](../ARCHITECTURE.md)介绍端到端设计，
-[文档导航](../docs/architecture/README.md)提供配置、执行、交付、存储和插件的
+[总体架构](../ARCHITECTURE.zh-CN.md)介绍端到端设计，
+[文档导航](../docs/architecture/README.zh-CN.md)提供配置、执行、交付、存储和插件的
 当前合同。想直接操作 CLI 时，使用 `yui --help` 查看命令。
 
 Yui 默认将控制面数据保存在 `~/.yui`，通过 `YUI_HOME` 选择另一个实例。

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@zq-silk/yui",
-  "version": "0.15.9",
+  "version": "0.15.12",
   "description": "Local control plane for long-running native agent CLI sessions backed by tmux.",
   "license": "MIT",
   "private": false,

package/skills/yui-leader/references/execution.md

@@ -22,29 +22,56 @@ implementation patterns, scheduling options, review routing, or recoverable
 runtime actions. Create an InputRequest only for a real product choice, new
 authority, irreversible external effect, or unavailable external fact.
 
-## Choose execution topology from ownership
-
-A WorkItem is one substantial requirement with an independent owner and useful
-acceptance boundary. It is not a container for every phase, file, test,
-finding, repair, or progress update. Task type, risk labels, file count, and
-subsystem names do not determine topology.
-
-Choose the smallest useful executor:
-
-1. **Leader directly** when current context, authority, and tools are enough.
-2. **Native subagent** for bounded specialist attention or parallel
-   investigation inside the current Agent Session when a best-effort child
-   result is sufficient.
-3. **Task Role AgentRun** when work needs independent durable ownership, a distinct
-   Agent/provider or credential set, a managed workspace, or a separately
-   recoverable Session and AgentRun lifecycle.
-
-Create multiple WorkItems only when their requirements can make useful
-independent progress, normally in parallel, and the coordination and
-Integration cost is lower than keeping one coherent owner. Keep coupled
-changes together.
-
-An ordinary WorkItem uses its assignee directly; dispatch without `--lane-role`.
+## Separate the work unit, executor, and concurrency
+
+Honor the user's explicit choice of direct work or delegation. Otherwise make
+three independent judgments; Review is a fourth judgment below.
+
+**Does this result need its own management and acceptance boundary?** A WorkItem
+is a substantial result worth managing and accepting separately inside the Task.
+It need not have a different person, an independent release, or parallel execution.
+Use zero WorkItems when the Task already holds one coherent outcome. One WorkItem
+can be Leader-owned or hold a justified whole-result managed Assignment and
+Candidate. Copying the Task unchanged or displaying progress is not a reason
+to create it. Do not split analysis, editing, testing, Review, and ordinary
+repairs into phase-shaped WorkItems.
+
+**Who should execute?** Direct Leader execution is the default viable path for
+one coupled result when current context, delivery authority, and tools suffice.
+A native child can supply bounded specialist attention or parallel investigation
+inside this Session when a best-effort result suffices; it creates no Yui identity,
+authority, or WorkItem by itself.
+
+Choose a managed Worker only for a concrete benefit that repays requirement
+restatement, context reload, startup, waiting, inspection/rework, Integration,
+and lifecycle management. Benefits include safely parallel independent results,
+a needed capability or execution environment, a genuinely necessary separately
+recoverable lifecycle, freeing the Leader for another actual responsibility,
+or explicit user delegation. An available Worker, cheaper/different model,
+many files, high risk, long duration, or generic maintainability alone is not
+enough. Risk can justify independent Review without delegating implementation.
+When delegation involves a material tradeoff, leave one sentence of concrete
+benefit in the existing Brief; no form, approval, or separate decision record
+is needed.
+
+**Should separate units run concurrently?** Multiple WorkItems may run serially
+because of a real dependency, or concurrently when their results can advance
+independently and the net benefit exceeds coordination and Integration cost.
+Neither a single WorkItem nor multiple executors proves parallelism. Keep
+coupled changes together.
+
+For example, fix one coupled behavior directly in Task main, even when it touches
+many files. Delegate an independent import tool while the Leader implements its
+consumer when the two have a stable boundary and useful parallel progress.
+Keep two separately accepted stages serial when the second genuinely needs the
+first result. Do not wrap a whole Task in an `implementer` WorkItem merely because
+that Role exists.
+
+Apply these choices to new work. Do not automatically cancel an existing Worker,
+reassign/retire WorkItems, or move workspaces to conform to a new default; preserve
+their current ownership and evidence until a justified explicit change.
+
+An ordinary managed dispatch uses the WorkItem assignee; omit `--lane-role`.
 Use [replicated execution](replicated-execution.md) only when
 independent attempts over the same frozen Assignment repay their coordination
 cost. Direct managed execution already provides durable ownership.
@@ -79,8 +106,9 @@ messages and Task Brief. Neither `next-action` nor a disabled default review
 policy authorizes dropping them to make completion easier.
 
 An Integration Job's success is not the final target update. For that
-notification, read [Integration](integration.md) and finish the same
-attempt; do not start a duplicate operation.
+notification, read [Integration](integration.md) and continue from its exact
+evidence; do not start a duplicate operation. Read that guidance also for an
+ordinary Git conflict or an attempt that cannot be reliably resumed.
 
 Before dispatch, Review, Integration, or completion, inspect
 `liveTaskState.activeRuns` and `liveTaskState.activeTaskReviews` in the current
@@ -90,7 +118,36 @@ global Task lock.
 
 ## Execute the chosen path
 
-Dispatch establishes the first owner and frozen Assignment. For ordinary
+### Choose input timing without changing intent
+
+Submission intent (`record`, `discuss`, `develop`) and delivery timing are
+different facts. Input controls do not activate a Task, expand an Assignment,
+or elevate a planning Session. Keep the submission contract when using `send`;
+choose queue, steer or interrupt from the user's intent and current facts:
+
+```sh
+yui task message queue <task> "<continuation>" --request-id <id> --to <role> --work-item <work-id>
+yui task message steer <task> "<current-turn correction>" --request-id <id> --to leader --expected-target <turn>
+yui task role interrupt <task> <role> --expected-target <turn> [--then-message <task/message>] [--request-id <id>]
+```
+
+Queue waits for the next legal opportunity. Steer addresses only the exact
+current native Turn; Worker/Reviewer steer also needs its existing WorkItem or
+ReviewRound. Bare interrupt stores a control request, not a new Message.
+`interrupt-requested` is not a terminal or proof that background resources
+stopped. Then names an already-saved input and reserves its next opportunity
+only within the original Session/writer boundary.
+
+Read `task role session inspect` first. Unsupported and proven-unsubmitted
+steer may be composed with interrupt when the user's intent permits stopping;
+accepted, pending or unknown steer must not be resent through another action
+or request id. Never silently cancel, replace a Session or downgrade to queue.
+
+Global inputs use `role message queue|steer <role>` and `role interrupt <role>`
+with their own owner, not a fabricated Task/Run. See
+[Runtime](../../yui-runtime/SKILL.md) for scope and controlled-console boundaries.
+
+Managed dispatch freezes the Assignment for its assignee. For ordinary
 clarification, feedback or a continuation of that same work, send a Message:
 
 ```sh
@@ -112,37 +169,72 @@ For unknown delivery or Session replacement, read
 [runtime recovery](../../yui-runtime/references/recovery.md). Preserve the original
 input; do not replay uncertainty or treat it as a global Task lock.
 
-For direct work, change only Task main, keep it on its managed branch, commit
-the result, and leave it clean. Run the smallest check that can catch the
-changed behavior while implementing.
+### Direct delivery with zero WorkItems
 
-For a substantial delegated requirement:
+The current delivery Leader needs no self-dispatched AgentRun or placeholder
+WorkItem. Read the full Task requirements and relevant Messages, then implement,
+verify, and fix the coherent result in Task main on its managed branch. Commit
+and leave it clean. Run focused checks while changing behavior and the required
+Project delivery checks on the final result.
 
-```sh
-yui task work create <task-id> "<title>" \
-  --project <project-to-modify> \
-  --objective "<bounded outcome>" \
-  --accept "<observable criterion>"
-```
+Keep the Brief as a current summary, not a replacement for Task requirements.
+Preserve changed intent and reasons in Messages/Decisions, substantial documents
+in Task artifacts, and code and verification evidence in the actual delivery.
+Zero WorkItems reduces coordination records, not requirements or evidence.
 
-Add `--after` only for a real dependency. Likely file overlap is not by itself
-a dependency. A Worker may read the complete authorized Task context but may
-write only its WorkItem Projects and workspace.
+Inspect the complete final diff and decide Review separately. If a Task-final
+Review is required or adds useful evidence, request it against the clean Task
+heads using `yui task review request <task> --role <reviewer>`. No WorkItem is
+needed. Consume the original result, fix reachable findings directly in Task
+main, and decide whether the changed result needs another Review. Honor immutable
+Review contracts and explicit user/Project requirements even if a default is
+disabled. Once the outcome and obligations are satisfied, use `task complete`
+with the outcome, checks, and remaining risk; a final chat message is not completion.
+
+### Leader-owned WorkItem
 
-For a Leader-owned WorkItem, mark it running, complete it directly, then record
-its actual result:
+Use this only when the result merits separate management/acceptance. Omit
+`--role` for direct execution: the Leader owns coordination and performs the
+work without a managed executor Assignment. `--role leader` instead selects the
+Leader Role as a **managed AgentRun executor**; it is not how to label direct
+ownership. Do not self-dispatch merely to gain execution authority.
+
+For a writable Project result, create and inspect its WorkItem-owned workspace
+before editing. The Leader can work there directly; isolation does not require a
+Worker. Task main, WorkItem Develop, and Review workspaces remain distinct owners.
 
 ```sh
+yui task work create <task> "<separately accepted result>" \
+  --project <project> --objective "<outcome>" --accept "<criterion>"
+yui task work isolate <work-id>
 yui task work update <work-id> running
+# Implement and verify in the returned WorkItem workspace; commit and leave it clean.
 yui task work update <work-id> done --summary "<result and evidence>"
-yui task work accept <work-id> --summary "<explicit acceptance and evidence>"
 ```
 
+`done` freezes a direct Candidate, not an AgentRun result or acceptance.
+Inspect it, then integrate the exact isolated result before acceptance:
+
+```sh
+yui task integration start <task> --work-item <work-id> \
+  --project <project> --strategy <ff|cherry-pick|merge|manual>
+# Inspect the attempt and finish it through Integration's normal checks/continuation.
+yui task work accept <work-id> --summary "<decision and evidence>"
+```
+
+Read [Integration](integration.md) for checks, continuation, and recovery.
+Keep the same unit through ordinary fixes.
+A read-only or Gitless result with no writable Projects needs no Git isolation;
+submit its actual evidence and accept it explicitly. Existing exact Task-final
+metadata-only Candidates retain their contract; do not establish a special Review
+contract merely to avoid the ordinary writable WorkItem isolation boundary.
+
 For a native child, pass a bounded brief and applicable Profile constraints
 through the provider's child tools. A small investigation needs no synthetic
 WorkItem. If the child implements an existing Leader-owned WorkItem, keep that
-WorkItem roleless and mark it running. Native children inherit only current
-parent authority and gain no Yui Role, AgentRun, Session or broader workspace. Their
+WorkItem roleless, supply its exact workspace and scope, and mark it running.
+Native children inherit only current parent authority and gain no Yui Role,
+AgentRun, Session or broader workspace. Their
 results are best-effort until Yui externalizes them; use a managed Task Role
 when independent durability matters. Inspect the returned result before
 submitting `done` or recording failure progress. `done` creates a Candidate;
@@ -153,20 +245,27 @@ materializing a Task Role, not when launching a native child. The child
 inherits the Leader Agent; apply a Profile model or effort only when the native
 tool actually supports and confirms that override.
 
-For a managed Task Role:
+### Managed Task Role
 
 ```sh
 yui task role add <task-id> <role> --profile <profile>
 yui task role show <task-id> <role>
-yui task work create <task-id> "<outcome>" --role <role>
+yui task work create <task-id> "<outcome>" --role <role> \
+  --project <project> --objective "<bounded outcome>" --accept "<criterion>"
 yui task work dispatch <work-id> --input "<decision-complete brief>"
 ```
 
+Add `--after` only for a real dependency. Likely file overlap is not by itself
+a dependency. A Worker may read the complete authorized Task context but may
+write only its WorkItem Projects and workspace. Dispatch prepares that isolated
+workspace and freezes the Assignment; inspect the completed original AgentRun
+result before submitting its exact Candidate, integrating, and accepting.
+
 Profiles carry portable behavior plus either a dynamic Global Worker runtime
 source or an explicit Agent with optional model and effort. Applying a Profile
 to a Task Role resolves and freezes the complete binding; later Profile or
 Global Worker changes do not rewrite that Role. Before dispatch, use
-`profile show` and `task role show` to read the exact behavior, Agent, model,
+`config profile show` and `task role show` to read the exact behavior, Agent, model,
 effort, Profile, and workspace. Do not reconstruct or guess launch
 configuration. Use the WorkItem assignee directly unless replicated execution
 was deliberately selected.
@@ -228,8 +327,9 @@ reachable issues to the original execution owner. Fix a small Task-main issue
 directly; create a Repair WorkItem only when the repair is itself a substantial
 independently owned requirement.
 
-A failed ReviewRound is an execution failure, not an automatic retry or repair
-wave. Inspect its exact Round, AgentRun, candidate, Core failure, and
+A failed ReviewRound is an execution failure, not a repair wave. First read
+its Provider retry projection: bounded infrastructure recovery may already own
+the successor. Otherwise inspect its exact Round, AgentRun, candidate, Core failure, and
 `task next-action` facts, then choose the smallest recovery that preserves the
 frozen boundary. Do not invent a retry loop or silently replace the Reviewer
 Session. For replicated execution, choose whether to retry a failed Producer,
@@ -254,8 +354,11 @@ External delivery and Task completion remain separate facts.
 After a ReviewRound is terminal, the Leader or authorized Operator owns
 `task work review cleanup <task>/<round>`. Preserve dirty diagnostic evidence
 and resolve it explicitly; do not ask a Reviewer to clean its own runtime
-after its final report. Cleanup can remain advisory at completion, but all
-required resources must be settled before user-authorized archive.
+after its final report. Cleanup can remain advisory at completion. Ordinary
+archive requires settled resources; explicitly authorized force archive preserves
+unresolved resources and diagnostics under the shared
+[archive contract](../../yui-runtime/references/publication.md). The Leader
+does not gain independent archive authorization.
 
 Complete only when the Task outcome is satisfied, required checks and review
 contracts are settled, WorkItems are accepted or deliberately retired, latest