@zq-silk/yui 0.14.0 → 0.14.2

package/i18n/README.zh-CN.md

@@ -17,7 +17,7 @@ Yui 不把 Agent 的判断固化成确定性的工作流引擎。核心只负责
 ## 核心模型
 
 - `WorkItem`：唯一的有界工作单元，保存目标、验收条件、依赖、状态和精简结果。
-- `WorkerProfile`：可复用且与 provider 无关的行为模板，保存指令、Skill、访问要求及可选 model/effort hint。
+- `WorkerProfile`：可复用的 Worker 模板，分别保存可移植行为与继承或显式指定的 Agent runtime。
 - `TaskRole`：Task 内可修改的 Worker 实例，可绑定多个 Agent，并分别保存运行配置。
 - `Turn`：Task Role 的一次受管派发与结果交付。
 - `ChangeSet`：隔离 WorkItem 当前 HEAD 的不可变 Git 结果。
@@ -33,8 +33,19 @@ Agent 对话内创建 native subagent，或交给 Task Role Turn。Yui
 worker  explorer  implementer  reviewer
 ```
 
-Profile 不绑定 Agent，也不持有 Session 或 workspace。把 Yui Agent Profile 应用到 Task Role 时，会把 instructions、Skills、访问意图以及可选 model/effort 复制到该 Role 的 active Agent binding；显式 Role 参数可以继续覆盖这些值。它与 Codex 通过 `--profile` 选择的原生 config profile 不是一回事。Operator、Leader
-与 Task Role 是运行时 Role。
+Profile 的 runtime 要么动态继承当前全局 Worker active binding，要么显式指定
+一个 Agent 及可选 model/effort；adapter 始终由 Agent 配置派生。`profile list`
+和 `profile show` 会展示当前有效 Agent，以及继承时的 Worker launch revision，
+但不会因此改写 Profile 或增加其 revision。Profile 本身不持有 Session 或
+workspace。显式 Profile 指向的 Agent 只要在全局 Worker 中存在 binding（无论
+active 还是 dormant），其余 binding 配置就取自该 binding；未绑定的 Agent
+使用 Provider 默认值。被显式 Profile 这样引用的 Worker binding，必须先更新
+Profile、改为继承或删除 Profile 后才能解绑。model/effort 仍由 Profile 自身
+决定，省略即表示 Provider 默认值，而不是 Worker 中的值。把 Yui Agent Profile
+应用到新 Task Role 时，会冻结完整解析后的
+binding，以及 instructions、Skills 和访问意图；之后 Profile 或全局 Worker
+变更不会反向改写已有 Task Role。它与 Codex 通过 `--profile` 选择的原生 config
+profile 不是一回事。Operator、Leader 与 Task Role 是运行时 Role。
 
 ## 环境要求
 
@@ -100,7 +111,7 @@ Task 的命令（例如 `task work create`、`task integration start`）仍使
 Task 内的本地子记录 ID。Candidate 只在所属 WorkItem 内递增，并同时保存
 Task 与 WorkItem provenance。
 
-Yui 只支持当前 aggregate-v14 / StoredTask-v13 schema。旧 home 不提供转换、
+Yui 只支持当前 aggregate-v31 / Task-v7 schema。旧 home 不提供转换、
 双读或历史记录推断；需要使用新版本时初始化全新的 `YUI_HOME`。当前引用契约见
 [Task 本地 ID](../docs/task-local-identity.md)。
 
@@ -116,11 +127,23 @@ yui task create "修复 CSV 转义" --project app --type bugfix
 yui task create "交付 CSV 导出" --project app --type feature
 yui task update <task-id> --priority high --tags release,csv --due-at 2026-08-01T00:00:00Z
 yui task update <task-id> --clear-priority --clear-tags --clear-due-at
+yui task message update <task-id>/<message-id> --body-file updated-message.md --wake-policy none
+yui task work edit <task-id>/<work-item-id> --objective "修订后的目标" \
+  --accept "新的可观察验收标准"
+yui task work retire <task-id>/<work-item-id> --summary "从当前 Draft 中移除"
 yui task show <task-id>
 yui task context <task-id>
 yui task activate <task-id>
 ```
 
+Draft 只保存规划记录和 Project 绑定，不采用可写 managed Workspace。Message
+与 WorkItem 编辑只替换显式指定的可变字段，记录 ID 和审计历史保持不变；重复
+选项表示整体替换，对应 `--clear-*` 显式表示空集合。retired 记录继续保留在历史
+视图中，但退出当前 Draft。retired WorkItem 不满足依赖，也不会通过可选
+replacement 自动重定向下游；激活前必须修正剩余 Draft。所有 Draft-only 编辑和
+retire 都不创建、停止或清理运行时资源；`task activate` 会在采用任何 Workspace
+之前校验当前依赖图、Role 和 Project scope。
+
 Task type 描述需求意图，不选择执行协议。软件 Project 通常使用 `bugfix` 或
 `feature`：bugfix 由 Leader 在 Task main 独立、快速完成；如果范围扩大到需要
 独立 owner，应先改为 feature 再创建 WorkItem。feature 由 Leader 判断是自己直接
@@ -175,6 +198,23 @@ review。冻结头变化时创建新的语义 Round；同一 Reviewer 的兼容
 所有候选、ReviewRound 和 Leader 决策都集中在原 WorkItem 下；reject
 后的下一轮会复用原执行 Role、Session 与 workspace，并追加新候选。
 
+显式 WorkItem Candidate Review 与 Task-final Review 默认都直接创建一个 main
+Reviewer Turn；只有 Leader 明确提供至少两个不同的 `--lane-role` 时才使用复制执行。
+复制执行最多支持八个 Lane。所有 Producer Lane 在隔离 workspace 中检查同一冻结 Assignment，全部 settle 且至少
+两个成功后，才创建一个权威 main synthesis Turn。自动 policy 触发的 Candidate
+Review 始终保持直接执行。主 Reviewer 通过冻结 Context 按 Lane 顺序读取每个成功
+Producer Turn 的原始结果；Core 不复制其 prompt/workspace/runtime，也不解析结果语义。
+
+```sh
+yui task work review <task-id>/<work-item-id>
+yui task work review <task-id>/<work-item-id> \
+  --lane-role security-reviewer --lane-role correctness-reviewer
+
+yui task review request <task-id> --role reviewer
+yui task review request <task-id> --role reviewer \
+  --lane-role security-reviewer --lane-role correctness-reviewer
+```
+
 查看已有 Task 的详细状态时，优先使用 `task context`。它一次聚合 Task、Brief、Active Decision、最近的 Milestone、Role、当前及最近的 WorkItem 与关联 Turn、最近的 Message、Open/Resolved InputRequest 和 Event。终端输出会精简历史和长文本；`yui --json task context <task-id>` 会在顶层 `data` 中返回完整记录。
 
 Task identity 由一个有界交付目标决定，而不是由涉及几个仓库决定。带仓库的
@@ -281,10 +321,11 @@ Task/WorkItem 模型，不增加额外任务类型。
 `--last` 可直接恢复最近一条；新建会话不会伪装成 resume 选项，必须显式使用
 `operator new`，并把原对话保留在历史中。
 
-从已配置的全局 Worker 创建 Task Role，应用 Profile 并派发 WorkItem：
+从 Profile 当前解析出的 runtime 创建 Task Role 并派发 WorkItem：
 
 ```sh
 yui config role show worker
+yui config profile show implementer
 yui task role add <task-id> implementer --profile implementer
 yui task role show <task-id> implementer
 
@@ -294,47 +335,32 @@ yui task work isolate <task-id>/<work-item-id>
 yui task work dispatch <task-id>/<work-item-id> --input "完成实现并运行聚焦测试"
 ```
 
-派发默认仍为 `single`。Leader 可在全新 WorkItem 上显式开启有界多路探索；每个
-接受的阶段按 `Plan → Generate → Compare → Synthesize → Verify → Resolve`
-推进，只有接受后的 Resolve 阶段会物化既有的单一 Candidate：
+不传 `--lane-role` 时，assignee 直接在 WorkItem 主工作区执行。若要让多个生产者
+基于完全相同的冻结 Assignment 独立执行，必须传入至少两个不同的 Task Role；
+单个 Role、重复 Role 或 assignee 本身都会被拒绝：
 
 ```sh
 yui task work dispatch <task-id>/<work-item-id> \
-  --mode parallel-diverse --max-rounds 2 --stage-max-attempts 2 \
-  --strategy fixed:2 --lane-role critic \
-  --stage-max-tokens 240000 --stage-max-tool-calls 200 \
-  --stage-max-seconds 1800 --stage-quorum 2
-yui task work group resolve <task-id>/<work-item-id> \
-  --decision accept --summary "Plan 证据充分"
-```
-
-每个阶段都是新的不可变 ExecutionGroup；其 ContextSnapshot 与选中的父 Lane
-结果都以持久引用衔接。`retry` 在阶段尝试预算内重做当前阶段，而 Resolve 上的
-`retry` 才进入下一轮，并受最大轮次约束。
-
-每个新阶段还会冻结一份 Resource Broker 契约：token、工具调用和墙钟预算，
-quorum 与 deadline，straggler 窗口，以及继续增加 Lane 所需的最低边际价值。
-省略这些参数时使用独立的执行成本默认值与 runtime-health 时间窗；同一阶段的 retry
-累计原有花费并共享绝对 deadline。执行、Lane retry 和 Reviewer panel 准入统一核算
-Home、Task、WorkItem、Group、Provider、Agent 和模型层级的活动 Lane；容量不足的
-Lane 会耐久保留为 pending，不会把整个 Group 判失败。容量释放或 deadline 到达会沿
-既有 actionability 路径唤醒 Leader，重跑同一 dispatch 即按冻结输入继续。释放的
-容量优先留给最早且当前可准入的等待 Lane；受 Provider 或 Agent 限制的队首
-不会阻塞独立资源域继续推进。Provider 限流仍沿用既有的原地重试窗口，不会扩散成
-兄弟 Lane 失败。
-
-Leader 可在接受 Group 时增加 `--early-stop <0-100>`。只有 quorum 已满足且 T5 的
-Verify/Resolve 证据证明验收充分时，Yui 才允许提前终止；它只跳过从未启动的 Lane，
-运行中的 straggler 会被报告并保留，不会因为省费被自动杀死。证据不足时，预算或
-deadline 耗尽会把阶段留给 Leader 决议，绝不会把薄证据转换成成功。
-
-新建探索历史还会冻结结构化候选收敛契约。Yui 将当前阶段的精确 JSON 形状追加到
-每个 Lane assignment，并在 Leader 推进前校验入选报告：Compare 必须显式划分
-重复簇，并以直接来源、可执行检查或冻结产物支持每条入选路线；Synthesize 对调研
-使用 claim/evidence 表、对架构使用决策矩阵、对代码只选择一个冻结 Git snapshot。
-Verify 必须使用与入选 Synthesize 作者不同的 Role。只有逐条验收证据完整时才能得到
-`passed` 并由 Resolve 接受 Candidate；显式 gap 只能形成 `next-round`，再通过有界的
-Resolve `retry` 继续。票数和衍生分析可以作为报告上下文，但不能替代直接证据。
+  --input "完成实现并运行聚焦测试" \
+  --lane-role producer-a --lane-role producer-b
+```
+
+Lane 是可恢复的逻辑槽。成功 Lane 指向不可变的 Producer Turn 结果；Turn 失败时
+Lane 仍保持 open，并显示为 `needs-attention`。Leader 对精确失败 Turn 执行重试或
+显式结算：
+
+```sh
+yui task turn retry <task-id>/<failed-turn-id>
+yui task turn settle <task-id>/<failed-turn-id>
+```
+
+Yui 会等待所有 Lane 结算。至少两个 Producer 成功结果才会为 WorkItem assignee
+幂等创建一个主 Turn；成功数不足时本次 WorkItem 尝试失败，不会降级使用单个结果。
+主 Turn 重试继续引用同一来源 Group，也不会重跑成功 Lane。只有成功的主 Turn 能
+形成 Review 与 Integration 使用的 Candidate。`task work show`、`task work list`、
+Task context 和 Web 控制室从相同持久事实推导执行形态、恢复目标、综合资格、主 Turn、
+Candidate 溯源、下一步及责任人。缺失事实保持 `unknown` 或 `unobserved`；token、
+耗时和工具调用只读展示，不参与调度、恢复或生命周期决策。
 
 每个 Agent binding 只有一套 adapter-specific 权限枚举配置：`default` 遵循
 provider 默认行为；`bypass` 编译 provider 支持的 bypass flag；`configured`
@@ -342,26 +368,40 @@ provider 默认行为；`bypass` 编译 provider 支持的 bypass flag；`config
 `mode`、`allowedTools` 与 `disallowedTools`。provider 权限与 Profile 行为意图、
 Project 写入授权彼此独立：普通写入只由精确 WorkItem 范围和匹配的 managed
 workspace 授权。任意非 Leader
-Task Role 在创建时不传 `--agent`，都会复制全局 Worker Role 的完整 Agent
-bindings，Leader 无需重新拼接 model、effort 和权限。创建回执与
-`task context` 分别记录 Profile intent、精确可写 Project 与实际 permission strategy。显式
-`--agent` 属于 Task 专用覆盖，必须在派发前补全并回读配置。
+Task Role 在创建时同时不传 `--profile` 和 `--agent`，会复制全局 Worker Role
+的完整 Agent bindings，Leader 无需重新拼接 model、effort 和权限。传
+`--profile` 时会冻结该 Profile 当前解析出的完整 binding。创建时的 model、
+effort、权限和其他 Agent 设置必须与 `--agent` 同时提供，以便在任何持久化前
+完成能力校验并原子写入一套完整 binding。创建时同时传入 `--profile` 与
+`--agent`，Agent 必须与 Profile 当前解析出的 Agent 一致；Profile runtime
+仍作为基础 binding，显式 Agent 设置覆盖对应字段。更新 Task Role 时，不传
+`--agent` 会更新 active binding；传入 `--agent` 则只更新指定 binding 而不
+激活它，只有 `task role bind` 会切换 active Agent。显式 Profile 必须解析到
+该更新目标，其 runtime 作为基础 binding，显式 Agent 设置覆盖对应字段。单独
+使用继承 Worker 的 Profile 时，可以只更新可移植 Role 行为，而不重新定向绑定
+到其他 Agent 的 Role；若同时传入 `--agent` 或 Agent 设置，其当前解析出的
+Worker Agent 必须与更新目标一致。创建回执与 `task context` 分别记录 Profile
+intent、精确可写 Project 与实际 permission strategy。应用 Profile 会替换
+AgentProfile 所拥有的可移植字段（`defaultAccess`、description、instructions、
+skills 及由 access 派生的 constraints）；同一命令中的显式 Role 选项随后覆盖。
 
 ReviewRound 从冻结 Candidate SHA 创建独立的可写 worktree。只有 exact
 ReviewRound owner、reviewRoundId、冻结 base 与 workspace 全部匹配时，才获得
 该 workspace 的写入授权；Skill 仍禁止 push、Integration、Task state、其他
 workspace 与真实 YUI_HOME 变更。Reviewer 以最终 Provider 回复交付当前 Turn，
-Yui 自动保存其完整的自由格式 Markdown 或 JSON 报告。如果 JSON 含已知的 `checks` 或
-`evidenceCommit` 字段，Yui 会把它们记录为结构化证据，并核验 commit 是否等于
-managed Review branch HEAD；未知字段仍保留在完整报告中。
+Yui 原样保存其完整的自由格式 Markdown、JSON 或普通文本结果，不解析标题、字段、
+checks、severity、finding、verdict 或 evidence commit。Skill 和派发消息可以建议
+输出结构，但该结构不是 Core 协议；格式缺失或 JSON 无效由 Leader 阅读原文后判断。
+Core 自己观测的 workspace 与 Git 证据独立保存。
 
 Reviewer 可以修改文件并在不提交的情况下结束 Turn；脏字节不会被推断为 evidence。
 该 Round 仍会精确终结且不产生 Candidate/ChangeSet，workspace 会为 Leader 判断而
 保留，cleanup 会在其重新变干净前拒绝删除。
 
 Provider 原生 Turn 终态会结束 Turn，Yui 保存最终回复，将 WorkItem 提交给 Leader 审查，并追加结果消息和
-唤醒 Leader；它不会验收或完成 WorkItem。Leader 不会自唤醒，pending wake
-会保留到 Leader 空闲。
+唤醒 Leader；它不会验收或完成 WorkItem。有效结果在 512 KiB 限制内逐字保留；
+缺失、空白、含 NUL 或超限结果不会伪造成功文本，而是以 `missing-result` 和
+Core 诊断失败终结该 Turn。Leader 不会自唤醒，pending wake 会保留到 Leader 空闲。
 
 如果无法最终判断结果，交接必须明确标为 `uncertain`、`incomplete`、
 `blocked` 或 `requiring Leader judgment`，并提交最完整且真实的身份、已执行
@@ -383,11 +423,13 @@ yui config profile show reviewer
 subagent 的创建与结果返回完全由 Leader 当前 Agent 的 native child 能力
 完成，没有 `yui ... subagent` 命令。Leader 必须选择并读取一个显式
 Worker Profile；没有合适的专用 Profile 时使用 `worker`。child brief
-需要包含 Profile revision、instructions、Skills、访问边界、验证要求及
-当前 runtime 支持的 model/effort hint。
+需要包含 Profile revision、instructions、Skills、访问边界、验证要求，并把
+Profile 当前解析出的 Agent/model/effort 仅作为上下文。
 
 native subagent 继承 Leader Agent、凭据和对话上下文，忽略 Task Role 的
-Agent bindings。Leader 审查返回结果后，在 WorkItem summary 中登记真实
+Agent bindings；Profile 的 runtime 选择只控制 Task Role 物化。只有当 Profile
+解析到同一个 Agent 且 native child API 支持时，才应用其中的 model/effort，
+否则继承实际 runtime。Leader 审查返回结果后，在 WorkItem summary 中登记真实
 执行信息：
 
 ```sh
@@ -483,6 +525,64 @@ yui task context <task-id>
 
 需要查看单个集合或记录时，再使用 `task work`、`task message`、`task turn` 和 Task Knowledge 下的细分命令。
 
+使用一个幂等命令记录 Task 已确认的 PR/MR 外部交付状态：
+
+```sh
+yui task publication upsert <task-id> --project <project> \
+  --provider github --repository <owner/name> --kind pull-request --id <number> \
+  --url <url> --state open --reported
+```
+
+必需的 provider/repository/external ID 会定位当前 Publication。首次 upsert
+创建记录。后续 upsert 会继承未指定的元数据；只有完整证据上下文不变时才继承未指定的
+合入证据。证据上下文包括 local commit、PR/MR state、remote commit、evidence 文本
+和 mergedAt。任一显式提供的上下文值真正变化时，未显式提供的 verification 会重置为
+`reported`，未重新提供的合入证据字段会清除；仅改变 local commit 且未显式提供 state
+时还会把 Publication 重置为 `open`。重复提供相同值仍保持幂等。只有语义发生变化时才
+追加新的不可变记录，并由 Yui 自动关联上一版本；相同输入不会新增事件。`list`、`show`
+和 `task context` 继续保留完整历史。该命令只记录调用方已经掌握的事实，不会自行查询
+Provider，也不替代 Review、Integration 或 Task completion 门禁。
+
+可针对当前 GitHub Publication 查询真实 PR 状态并记录验证结果：
+
+```sh
+yui task publication verify <task-id>/<publication-id>
+```
+
+验证是一次显式的外部读取。一期调用 PATH 中已固定绝对路径的可信本地 `gh`，复用
+`gh` 自己的认证，Yui 不保存 GitHub token。命令先要求当前未 supersede
+Publication 的 local commit 精确等于 Task 交付 head，再要求 GitHub 返回相同的
+PR head、真实 merged 状态和远端合入 commit。远端调用结束后还会重新核对 Task head
+与 Publication，全部不变才追加新的不可变 `verified` 记录。缺少 `gh`、认证不可用、
+Provider 输出不明确、PR 仍 open/closed、head 已移动或本地权威并发变化时都不会写入
+verified。一期不支持 GitLab 远端验证。
+
+可查询每个已交付 Project head 是否都有当前 merged Publication 覆盖：
+
+```sh
+yui task remote-delivery <task-id>
+yui task remote-delivery <task-id> --json
+```
+
+这是只读派生投影，不是新的 Task 状态，也不存在可单独写入的 `merged` 标志。
+active 或 reopened Task 使用当前干净的 Task main heads，并明确标记为 provisional；
+completed 或 archived Task 使用最近一次 `task.completed` 冻结的 heads。每个 Project
+都会展示预期 local commit、匹配的当前未 supersede Publication、PR/MR state、
+verification 与 remote commit。聚合状态为 `none`、`unavailable`、`pending`、
+`partial` 或 `merged`，并分别暴露 `allMerged` 与 `allVerified`。只有
+`localCommit` 精确匹配
+预期 head 且 state 为 `merged` 的当前 Publication 才贡献 merged 覆盖；缺 commit、
+open/closed、陈旧 head 与已 supersede 记录都不会被推断为已合入。Task head 与
+managed base 相同的 Project 不需要 Publication。`task show`、`task context`、
+`task next-action` 和 Web detail 共用同一个 selector。
+`Archive --integrated coverage` 同时要求 `allMerged=true` 和
+`allVerified=true`。
+
+有效旧版本 completed Task 如果没有冻结的 completion heads，Yui 会报告
+`unavailable`，并继续对 integrated archive fail closed。先 reopen，再重新 complete
+以记录精确 heads，之后重试 archive。Yui 不会从 Publication 或 worktree 猜测缺失的
+head，`--force` 也不能绕过缺失 head 证据。
+
 完成目标后，可将 Task 标记为 completed，从而停止自动唤醒，同时保留 session 和 Task main worktree：
 
 ```sh
@@ -494,9 +594,15 @@ completed Task 在显式 reopen 前会拒绝消息、派发、进入 session、
 Turn 交付。终态 WorkItem、Review、Integration 与 Lane worktree 会作为非阻塞的
 completion advisory 返回，但必须在 archive 前处理。每个隔离 WorkItem worktree
 仍需显式标记 integrated 或 abandoned，清理时也会删除其受管分支；archive 还必须
-通过 `--integrated` 或 `--abandon` 明确 Task main 的处理结果，之后才会停止
-session 并清理干净的 Task main。Task 与 WorkItem 记录都会保留，Task main 分支
-作为恢复信息保留，不会被静默删除。
+通过 `--integrated` 或 `--abandon` 明确 Task main 的处理结果。`--integrated`
+还要求 remote-delivery 的 `allMerged=true` 与 `allVerified=true`；Task
+completion 或只有 reported 的 merge 都不等同于已验证远端交付。如果所有精确
+Task head 都已合入但仍有 Publication 是 `reported`，archive 会列出这些记录并拒绝。
+只有获得明确授权后，`task archive <task-id> --integrated --force` 才能仅覆盖这一
+verification 缺口，并在归档事件中记录 override；它不能绕过缺失、陈旧、open 或
+closed 的合入证据。有意不合入时继续使用显式 `--abandon` 路径。之后 archive 才会
+停止 session 并清理干净的 Task main。Task 与 WorkItem 记录都会保留，Task main
+分支作为恢复信息保留，不会被静默删除。
 Task 生命周期的交互选择只展示有效来源状态：activate 只展示 Draft，complete 只展示 active，reopen 只展示 completed。
 
 ## Session 与 tmux
@@ -519,7 +625,7 @@ yui task role takeover <task-id> <role>
 yui task role release <task-id> <role>
 ```
 
-Codex Role thread 可在 Desktop 中直接查看和操作；Desktop 已有 active Turn 时，Yui 只保留待投递工作并等待，不会失败或重复投递。`view`、`takeover`、`release` 继续作为 Claude 等独立进程 Provider 的人工控制入口。Yui 不写入全局 Hook/config，也不启动、重启或停止共享 daemon；Codex CLI/daemon 故障由 Task 生命周期之外修复。Global Operator 与 global Role 继续使用原生交互式 CLI，不属于受管理 Task Provider 协议。
+Codex Role thread 可在 Desktop 中直接查看和操作；Desktop 已有 active Turn 时，Yui 只保留待投递工作并等待，不会失败或重复投递。`view`、`takeover`、`release` 继续作为 Claude 等独立进程 Provider 的人工控制入口。Yui 不写入全局 Hook/config，也不启动、重启或停止共享 daemon；Codex CLI/daemon 故障由 Task 生命周期之外修复。Global Operator 与 global Role 继续使用原生交互式 CLI，不属于受管理 Task Provider 协议；Yui 在内部将 Codex 的 Global TUI 连接到同一个默认 App Server，用户不能通过 Agent 或 Role 参数覆盖该连接，Session Manifest 自带不依赖启动进程环境的 Global Context 命令，因此同一 thread 可直接切换到 Desktop 继续对话。
 
 当新版本需要离线迁移 Home 时，应等待当前 Turn 完成，然后从普通 shell
 执行 `yui session stop --all`，再重新执行 `yui update`。停止命令会先整体预检：

package/package.json

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