@zq-silk/yui 0.13.9 → 0.14.0

package/dist/workItem/workItem.js

@@ -13,7 +13,7 @@ const TERMINAL_STATUSES = [
 export function createWorkItem(id, taskId, input, now) {
     const timestamp = now.toISOString();
     return validateWorkItem({
-        schemaVersion: 12,
+        schemaVersion: 13,
         id: requireIdentity(id, "Work Item id"),
         taskId: requireIdentity(taskId, "Task id"),
         title: requireText(input.title, "Work item title"),
@@ -46,7 +46,7 @@ export function submitWorkItemCandidate(workItem, input, now) {
     const revision = workItem.revision + 1;
     const sequence = workItem.candidates.length + 1;
     const candidate = validateWorkItemCandidate({
-        schemaVersion: 2,
+        schemaVersion: 3,
         id: `candidate-${sequence}`,
         taskId: workItem.taskId,
         workItemId: workItem.id,
@@ -248,8 +248,8 @@ export function recordWorkItemWorkspaceDisposition(workItem, disposition, now) {
     });
 }
 export function validateWorkItem(workItem) {
-    if (workItem.schemaVersion !== 12)
-        throw new Error("WorkItem must use schemaVersion 12.");
+    if (workItem.schemaVersion !== 13)
+        throw new Error("WorkItem must use schemaVersion 13.");
     validateTaskRecordReference({ taskId: workItem.taskId, localId: workItem.id }, "workItem");
     requireIdentity(workItem.taskId, "Task id");
     requireText(workItem.title, "Work item title");
@@ -498,7 +498,7 @@ export function workItemExecutionGroupById(workItem, executionGroupId) {
     return workItem.executionGroups.find(({ id }) => id === executionGroupId);
 }
 /**
- * True when a Run failure belongs to the WorkItem's current unresolved Lane.
+ * True when a Turn failure belongs to the WorkItem's current unresolved Lane.
  * Such a failure is Lane-bounded: the WorkItem remains running so the Leader
  * can reuse completed siblings and retry only this failed attempt.
  */
@@ -634,8 +634,8 @@ export function validateWorkItemCandidate(candidate) {
     if (typeof candidate !== "object" || candidate === null) {
         throw new Error("Work Item candidate is required.");
     }
-    if (candidate.schemaVersion !== 2) {
-        throw new Error("Work Item candidate must use schemaVersion 2.");
+    if (candidate.schemaVersion !== 3) {
+        throw new Error("Work Item candidate must use schemaVersion 3.");
     }
     requireIdentity(candidate.taskId, "Work Item candidate Task id");
     validateTaskRecordReference({
@@ -656,14 +656,14 @@ export function validateWorkItemCandidate(candidate) {
     if (typeof candidate.source !== "object" || candidate.source === null) {
         throw new Error("Work Item candidate source is required.");
     }
-    if (candidate.source.type !== "direct" && candidate.source.type !== "run") {
+    if (candidate.source.type !== "direct" && candidate.source.type !== "turn") {
         throw new Error("Work Item candidate source is invalid.");
     }
-    if (candidate.source.type === "run") {
+    if (candidate.source.type === "turn") {
         validateTaskRecordReference({
             taskId: candidate.taskId,
-            localId: candidate.source.runId
-        }, "agentRun");
+            localId: candidate.source.turnId
+        }, "turn");
     }
     if ((candidate.executionGroupId === undefined) !== (candidate.executionLaneId === undefined)) {
         throw new Error("Work Item candidate execution lineage is incomplete.");

package/dist/workspace/workItemChangeSetManager.js

@@ -263,7 +263,7 @@ export class WorkItemChangeSetManager {
      * ReviewRound freezes the candidate it reviewed at `reviewBaseCommit`; when
      * the captured ChangeSet head is that commit, the round's checks are
      * durable evidence for it.  "completed" alone is not a verdict: the
-     * reviewer may have yielded with failed checks (requires-repair), so only a
+     * reviewer may have completed with failed checks (requires-repair), so only a
      * round with an explicit positive verdict — at least one passed check and
      * no failed one — may feed `evidenceRefs`.  The link is by
      * `reviewBaseCommit`, not by `evidenceCommit`: the latter records the exact

package/docs/task-local-identity.md

@@ -5,7 +5,7 @@ Task owns an independent, monotonically increasing sequence for every record
 family:
 
 - WorkItem
-- AgentRun
+- Turn
 - ReviewRound
 - ChangeSet
 - IntegrationAttempt
@@ -22,7 +22,7 @@ advances that aggregate high-water mark under the storage process lock.
 
 Candidate identity is narrower: `candidate-N` is a WorkItem-local sequence.
 Every Candidate stores its `taskId` and `workItemId`, in addition to the source
-Run when one exists.
+Turn when one exists.
 
 ## Reference contract
 
@@ -37,13 +37,13 @@ JSON, mailbox, Controller, Hook, receipt, Web, and error paths retain the Task
 scope. Context-free commands reject a bare local ID instead of searching all
 Tasks, even if that ID currently happens to be unique.
 
-A managed Task session may use `work-item-1` or `agent-run-1` because its
+A managed Task session may use `work-item-1` or `turn-1` because its
 `YUI_TASK_ID` is explicit. A command that already receives the Task as another
 argument may also use a subordinate local ID. Outside those two cases, use the
 qualified form. Delivery receipts use the same provenance, for example:
 
 ```text
-agent-run:task-7/agent-run-1
+turn:task-7/turn-1
 input-request:task-7/input-1
 ```
 
@@ -57,6 +57,6 @@ does not match the current schema, keep it untouched for external archival
 and initialize a fresh home for this runtime.
 
 This hard cut keeps Task-local references, Role desired configuration, and
-immutable AgentRun/RoleSession effective snapshots under one unambiguous
+immutable Turn/RoleSession effective snapshots under one unambiguous
 contract. There is no compatibility lookup, conversion command, or
 intermediate storage format.

package/i18n/README.zh-CN.md

@@ -19,12 +19,12 @@ Yui 不把 Agent 的判断固化成确定性的工作流引擎。核心只负责
 - `WorkItem`：唯一的有界工作单元，保存目标、验收条件、依赖、状态和精简结果。
 - `WorkerProfile`：可复用且与 provider 无关的行为模板，保存指令、Skill、访问要求及可选 model/effort hint。
 - `TaskRole`：Task 内可修改的 Worker 实例，可绑定多个 Agent，并分别保存运行配置。
-- `AgentRun`：Task Role 的一次受管派发与结果交付。
+- `Turn`：Task Role 的一次受管派发与结果交付。
 - `ChangeSet`：隔离 WorkItem 当前 HEAD 的不可变 Git 结果。
 - Integration：候选集成、检查、冲突报告和 Leader 决策。
 
 每个 WorkItem 只选择三条路径之一：Leader 直接执行、Leader 在当前
-Agent 对话内创建 native subagent，或交给 Task Role AgentRun。Yui
+Agent 对话内创建 native subagent，或交给 Task Role Turn。Yui
 不提供 subagent 启动命令，也不创建 child Session 记录。
 
 内置 Profile：
@@ -90,10 +90,10 @@ export YUI_HOME=/absolute/path/to/yui-home
 yui setup
 ```
 
-home 中包含 `schema.json`、权威 `state.json`、Project Catalog、项目知识和 Controller 发现文件。稳定 Project checkout 与受管理 worktree 位于 home 外部的 workspace。运行时存储严格匹配且 fresh-only：不会双读旧 schema，也不会猜测旧 ID。
+home 中包含 `schema.json`、权威 SQLite 数据库 `yui.db`、Project Catalog、项目知识和 Controller 发现文件。稳定 Project checkout 与受管理 worktree 位于 home 外部的 workspace。运行时只接受当前存储契约：不会回退读取 `state.json`、转换旧 schema 或猜测旧 ID。
 
 所有 Task-owned 记录族都在各自 Task 内分配单调递增的本地 ID。因此，不同
-Task 可以同时拥有 `work-item-1`、`agent-run-1` 或 `input-1`。受管 Task
+Task 可以同时拥有 `work-item-1`、`turn-1` 或 `input-1`。受管 Task
 session 可由 `YUI_TASK_ID` 提供作用域并使用本地短 ID；Task session 外必须
 使用 `<task-id>/<local-id>`。Yui 不会拿裸 ID 扫描所有 Task。已经显式接收
 Task 的命令（例如 `task work create`、`task integration start`）仍使用该
@@ -157,11 +157,11 @@ yui config workflow set review --role reviewer --trigger final
 每个进入 Leader 验收阶段的结果，都会成为原 WorkItem 上一个明确的候选。
 当前全局规则对所有新旧 Task 的下一个候选生效，并在候选提交时形成快照；
 后续 `set`/`clear` 不会改变已经在途的判断。
-`always` 会为每个候选启动 ReviewRound，包括 Role yield 的结果和 Leader 直接管理的
+`always` 会为每个候选启动 ReviewRound，包括已结束的 Role Turn 结果和 Leader 直接管理的
 结果；`leader` 则让候选保持等待验收，由 Leader 直接 accept 或执行
 `yui task work review <task-id>/<work-item-id>`。因此只要配置了审查规则，Leader
 管理的候选也不会直接标记为完成。ReviewRound 引用不可变候选，审查
-AgentRun 不创建新 WorkItem，也不会递归触发审查。审查以自然语言结果
+Turn 不创建新 WorkItem，也不会递归触发审查。审查以自然语言结果
 唤醒 Leader；Leader 决定验收、reject 后在原 Role 与原 Session 中修复、
 再次审查，或通过 InputRequest 询问用户。审查失败会保留为可见证据并
 唤醒 Leader，但不会取代 Leader 的最终判断。
@@ -169,13 +169,13 @@ AgentRun 不创建新 WorkItem，也不会递归触发审查。审查以自然
 显式请求 Task 级 Review；不可变 Task contract 也可以强制要求。Task-final Round
 直接冻结 Task main，不需要虚构 WorkItem/Candidate，因此没有 WorkItem 的小任务也能
 review。冻结头变化时创建新的语义 Round；同一 Reviewer 的兼容原生 Session 可以在
-稳定 workspace 中继续，而每个 Run 仍严格绑定自己的 Round 和冻结头。旧报告保留为
+稳定 workspace 中继续，而每个 Turn 仍严格绑定自己的 Round 和冻结头。旧报告保留为
 证据。Reviewer 按 Project Policy/Knowledge 检查整个 Task，并只报告有直接证据的
 可达、重要、可行动问题或有限验证缺口。
 所有候选、ReviewRound 和 Leader 决策都集中在原 WorkItem 下；reject
 后的下一轮会复用原执行 Role、Session 与 workspace，并追加新候选。
 
-查看已有 Task 的详细状态时，优先使用 `task context`。它一次聚合 Task、Brief、Active Decision、最近的 Milestone、Role、当前及最近的 WorkItem 与关联 Run、最近的 Message、Open/Resolved InputRequest 和 Event。终端输出会精简历史和长文本；`yui --json task context <task-id>` 会在顶层 `data` 中返回完整记录。
+查看已有 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 由一个有界交付目标决定，而不是由涉及几个仓库决定。带仓库的
 Task 可以绑定多个 Project，并为每个 Project 记录独立 base ref：
@@ -215,7 +215,7 @@ yui task project add <task-id> shared-sdk --base main
 和匹配的 managed workspace 才能授权修改 Project。Role 也可以显式选择
 `default`，或用 `configured` 保留显式设置的任意 provider 原生权限选项子集。
 
-写入范围只能扩大，不能缩小。Worker yield 并报告还需要另一个仓库后，
+写入范围只能扩大，不能缩小。Worker 报告还需要另一个仓库后，
 Leader 使用完整的“旧范围 + 新范围”更新并重新派发：
 
 ```sh
@@ -262,8 +262,8 @@ yui operator enter
 yui task role reset <task-id> <role> --reason "<该 generation 无法继续的原因>"
 ```
 
-Yui 从自己的记录中推导当前 Run、Agent、launch、receipt 和 native Session。
-它只失败化该精确 active Run（以及对应 execution WorkItem），把当前 Session
+Yui 从自己的记录中推导当前 Turn、Agent、launch、receipt 和 native Session。
+它只失败化该精确 active Turn（以及对应 execution WorkItem），把当前 Session
 保存为 broken history，并要求 Controller 只停止该 Role 拥有的 runtime。该命令
 不会创建 Candidate、验收工作或完成 Task。cleanup pending 期间，`task role status`
 和 `task context` 会阻止 fresh launch；已有 message、review 和交付历史都会保留。
@@ -350,38 +350,23 @@ bindings，Leader 无需重新拼接 model、effort 和权限。创建回执与
 ReviewRound 从冻结 Candidate SHA 创建独立的可写 worktree。只有 exact
 ReviewRound owner、reviewRoundId、冻结 base 与 workspace 全部匹配时，才获得
 该 workspace 的写入授权；Skill 仍禁止 push、Integration、Task state、其他
-workspace 与真实 YUI_HOME 变更。两种 provider 都必须直接执行当前 Run 的 exact
-stdin yield；最终回复本身不是持久交付。review yield 的 stdin 保存 Reviewer
-完整的自由格式 Markdown 或 JSON 报告。如果 JSON 含已知的 `checks` 或
+workspace 与真实 YUI_HOME 变更。Reviewer 以最终 Provider 回复交付当前 Turn，
+Yui 自动保存其完整的自由格式 Markdown 或 JSON 报告。如果 JSON 含已知的 `checks` 或
 `evidenceCommit` 字段，Yui 会把它们记录为结构化证据，并核验 commit 是否等于
-managed Review branch HEAD；未知字段仍保留在完整报告中：
+managed Review branch HEAD；未知字段仍保留在完整报告中。
 
-```sh
-yui task run yield <task-id>/<review-run-id> --summary-file - <<'YUI_SUMMARY'
-{"summary":"复现并验证完成","checks":[{"name":"npm test","outcome":"passed","details":"全部通过"}],"evidenceCommit":"<exact-sha>"}
-YUI_SUMMARY
-```
-
-Reviewer 可以修改文件并在不提交的情况下 yield；脏字节不会被推断为 evidence。
+Reviewer 可以修改文件并在不提交的情况下结束 Turn；脏字节不会被推断为 evidence。
 该 Round 仍会精确终结且不产生 Candidate/ChangeSet，workspace 会为 Leader 判断而
 保留，cleanup 会在其重新变干净前拒绝删除。
 
-Worker 显式交付当前 Run：
-
-```sh
-yui task run yield <task-id>/<run-id> --summary-file - <<'YUI_SUMMARY'
-导出器已完成，聚焦测试通过
-YUI_SUMMARY
-```
-
-yield 会结束 AgentRun，将 WorkItem 提交给 Leader 审查，并追加结果消息和
+Provider 原生 Turn 终态会结束 Turn，Yui 保存最终回复，将 WorkItem 提交给 Leader 审查，并追加结果消息和
 唤醒 Leader；它不会验收或完成 WorkItem。Leader 不会自唤醒，pending wake
 会保留到 Leader 空闲。
 
 如果无法最终判断结果，交接必须明确标为 `uncertain`、`incomplete`、
 `blocked` 或 `requiring Leader judgment`，并提交最完整且真实的身份、已执行
 动作、仓库状态、检查与错误、最后生命周期边界、未完成工作、待决事项、风险、
-置信度及有界下一选项。yield 只记录不可变的 Run/Candidate 或 Review 证据；
+置信度及有界下一选项。Turn 结果只是不可变的执行证据；
 它不表示验收、WorkItem 完成、ChangeSet capture、Integration 或 Task 完成。
 
 对于有界工作，Leader 可以直接执行 roleless WorkItem，也可以在当前
@@ -412,9 +397,9 @@ yui task work update <task-id>/<work-item-id> done \
 
 无法确认实际 model/effort 时使用 `inherited` 或 `unknown`，不能猜测。
 需要独立 provider、凭据、交互 Session 或持久生命周期时，使用 Task Role
-AgentRun。
+Turn。
 
-隔离 Task Role 的结果按“Worker yield → Leader 语义审查 → capture 当前
+隔离 Task Role 的结果按“Provider Turn 终态记录 Turn 结果 → Leader 语义审查 → capture 当前
 HEAD → candidate 集成和检查 → Leader accept”的顺序处理。审查不通过时，
 Leader reject 并在同一 workspace 重新派发。相同 HEAD 重复 capture 复用
 原 ChangeSet；修复后的新 HEAD 形成新候选：
@@ -440,7 +425,7 @@ yui task integration resolve <task-id>/<integration-id> \
 yui task integration continue <task-id>/<integration-id>
 ```
 
-Worker yield 不等于 WorkItem 完成。Leader 审查结果、验证和最新
+Worker Turn 完成不等于 WorkItem 完成。Leader 审查结果、验证和最新
 ChangeSet 集成后再显式验收：
 
 ```sh
@@ -456,21 +441,21 @@ worktree 与检查日志会作为证据保留，直到显式清理。
 
 ```sh
 yui task message retire <task>/<message> --reason "已被新指令替代"
-yui task run retire <task>/<agent-run> --reason "无效的启动记录"
+yui task turn retire <task>/<turn> --reason "无效的启动记录"
 ```
 
 这些命令追加 retirement 事实；列表和审计仍保留并标记原 Message、
-WorkItem 或 AgentRun，而受管 Run 上下文、actionability、恢复、Review 证据和调度会忽略
-它。活动 AgentRun 会先按精确身份终态化；重复废弃是幂等操作。Message 与
-AgentRun 只能由用户或全局 Operator 废弃，WorkItem 也可由所属 Task Leader
+WorkItem 或 Turn，而受管 Turn 上下文、actionability、恢复、Review 证据和调度会忽略
+它。活动 Turn 会先按精确身份终态化；重复废弃是幂等操作。Message 与
+Turn 只能由用户或全局 Operator 废弃，WorkItem 也可由所属 Task Leader
 废弃。
 
-长期 Task 不依赖 native transcript 恢复。Leader 每次 yield 前更新 Brief
+长期 Task 不依赖 native transcript 恢复。Leader 每次结束 Provider Turn 前更新 Brief
 的 focus 和 leader summary；材料性技术选择写入 Decision；可独立汇报的
 阶段成果写入 Milestone；只有跨 Task 稳定有效的信息才进入 Project
 Knowledge。
 
-当活动 Leader Run 必须获得用户决定才能继续时，可以创建持久 InputRequest，并 yield 当前 Run：
+当活动 Leader Turn 必须获得用户决定才能继续时，可以创建持久 InputRequest，然后以真实的 blocked 结果结束当前 Provider Turn：
 
 ```sh
 yui task input request <task-id> --question "默认使用哪种格式？" \
@@ -496,7 +481,7 @@ yui task input request <task-id> --question "默认使用哪种格式？" \
 yui task context <task-id>
 ```
 
-需要查看单个集合或记录时，再使用 `task work`、`task message`、`task run` 和 Task Knowledge 下的细分命令。
+需要查看单个集合或记录时，再使用 `task work`、`task message`、`task turn` 和 Task Knowledge 下的细分命令。
 
 完成目标后，可将 Task 标记为 completed，从而停止自动唤醒，同时保留 session 和 Task main worktree：
 
@@ -506,7 +491,7 @@ yui task reopen <task-id>
 ```
 
 completed Task 在显式 reopen 前会拒绝消息、派发、进入 session、重试和迟到的
-yield。终态 WorkItem、Review、Integration 与 Lane worktree 会作为非阻塞的
+Turn 交付。终态 WorkItem、Review、Integration 与 Lane worktree 会作为非阻塞的
 completion advisory 返回，但必须在 archive 前处理。每个隔离 WorkItem worktree
 仍需显式标记 integrated 或 abandoned，清理时也会删除其受管分支；archive 还必须
 通过 `--integrated` 或 `--abandon` 明确 Task main 的处理结果，之后才会停止
@@ -518,9 +503,11 @@ Task 生命周期的交互选择只展示有效来源状态：activate 只展示
 
 受管理的 Provider 会话仍然是普通用户会话。Yui 只添加对应的 Role Skill 与 Session Manifest 指针，并通过 Provider 原生结构化协议提交 Task 工作；Yui 不接管完整对话历史。受管理输入绝不会作为终端按键、粘贴文本或启动 argv 发送。Codex 在只转发字节的 `app-server proxy` 上完成 App Server WebSocket 握手，接入与 Desktop 相同的共享 daemon；原生 thread 可在 Desktop 中直接查看和操作。Task execution stop 只终止 Yui 的 Agent Host、WebSocket 与 proxy，保留共享 daemon、原生 thread、Task、WorkItem、代码与持久消息；start 创建新的 attachment。Claude 继续使用独立的持久 stream-json 进程，并以精确回放的 user message 作为接收确认。
 
-Run、Conversation、Activation 与 Turn 是四个独立身份。Conversation 可以跨多个 Run 和客户端连接；Activation 只代表 Yui 当前的连接，而不是对 Provider thread 的独占所有权；Turn 在写入前先持久化。写入超时或结果不明确会进入 `delivery-unknown`，不会自动重发。Codex 已存在的原生 active Turn 只会让 Yui 暂时等待，不会导致 Yui Run 失败；Claude 等独立进程 Provider 继续通过 Yui 的 view/takeover 边界进行人工控制。
+Session、Activation 与 Turn 是独立身份。Session 可以跨多个 Turn 和客户端连接；Activation 只代表 Yui 当前的连接，而不是对 Provider thread 的独占所有权。每次 Provider 执行对应一个持久 Turn；写入超时或结果不明确会进入 `delivery-unknown`，不会自动重发。Codex 已存在的 active Turn 只会让 Yui 暂时等待，不会导致待投递 Turn 失败；Claude 等独立进程 Provider 继续通过 Yui 的 view/takeover 边界进行人工控制。
+
+Turn 是 Role 是否有工作正在执行的唯一持久调度状态，记录可见输入、来源/渠道与最终回复，不复制思考过程或工具调用。所有经 Yui 中转或生成的输入统一使用 `source: yui`；Provider UI 中直接输入的消息使用 `source: user`；显式 Goal continuation 使用 `source: provider`。Provider Turn 终态后 Yui 完成该 Turn，再把下一个 Turn 投递到同一 Session。TaskRole 本身只保存身份和期望启动配置，不再保存可写的运行状态；CLI/Web 展示的 Role 状态由活动 Turn 派生，并叠加 Session/Driver 生命周期事实用于诊断。
 
-AgentRun 是 Role 是否有工作正在执行的唯一持久调度状态。Conversation 不再维护另一份 current Run；Provider Turn 中的 Run id 只用于关联接收回执和终态事件。TaskRole 本身只保存身份和期望启动配置，不再保存可写的运行状态；CLI/Web 展示的 Role 状态由活动 AgentRun 派生，并叠加 Session/Driver 生命周期事实用于诊断。Agent 可以在 Provider 终态到达前声明旧 Run 的语义结果，下一批 mailbox 工作也可以先形成新的 AgentRun；Agent Host 仍会串行等待旧 Turn 结束，再投递被保留的新输入，不回滚事件，也不把旧 Conversation 强行换绑到新 Run。
+Goal 是 Session 级显式 Provider 事实，可以跨越多个 Turn。Codex 通过 Goal API/事件提供，Claude 通过 `active_goal` 提供；Yui 不用静默等待来猜测 Goal 是否完成。Turn 结束不等于 Goal、WorkItem 或 Task 完成，只有 Leader 更新 WorkItem 与 Task 的持久语义。
 
 Task Role 使用以下显式入口：
 
@@ -534,7 +521,7 @@ 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 协议。
 
-当新版本需要离线迁移 Home 时，应等待当前 Turn/Run 完成，然后从普通 shell
+当新版本需要离线迁移 Home 时，应等待当前 Turn 完成，然后从普通 shell
 执行 `yui session stop --all`，再重新执行 `yui update`。停止命令会先整体预检：
 只要仍有 Session 正在运行或存在未决生命周期工作，就不会开始停止；全部空闲
 时会先阻止新的 Leader 调度，停止并等待 Controller 完全退出，重新检查运行时
@@ -554,7 +541,7 @@ binding，用于不同账号、模型、profile 或环境来源；这些 binding
 更新时才进入现有配置选择流程。
 
 受管理 Session 的普通工作流命令统一调用 PATH 中的 `yui`。Session Manifest
-与持久 Role/Run fence 负责身份认证，CLI 和 Controller 只需满足协议与存储兼容，
+与持久 Role/Turn fence 负责身份认证，CLI 和 Controller 只需满足协议与存储兼容，
 不会因包版本升级而使现有 Session 失效；Provider 回调等内部路径仍保留精确围栏。
 `update` 会幂等刷新旧版本生成的精确 CLI wrapper，使历史 Session 也转为这一
 兼容入口。
@@ -568,7 +555,7 @@ state、receipt 与 pane fence。Yui 不会解析 prompt glyph、进度文本、
 或其他 Agent 终端输出来推断 ready 或 success。`captureRole()` 只用于显式的人类
 transcript 查看，不具备生命周期权威。
 
-稳定的 Role 上下文不会创建额外的 bootstrap Turn。Task execution Run 按角色使用通用 Leader 或 Worker Skill，review Run 则按持久 Run purpose 使用通用 Reviewer Skill；Provider 可以通过安全的追加式原生上下文通道携带 Skill，也可以在普通 Task 投递中指向它。这些都只是 Yui 自己拥有的可移植编排规则。Project Skills 始终是 Project 中正常版本化的文件，由 Agent 通过自身项目机制发现、选择并按需加载；Yui 不扫描、不解析、不复制，也不注入 Project Skills。Managed Codex 保留用户原有的 developer instructions；普通 Task 消息会携带精简的 Session Manifest 绝对路径，Manifest 再指向对应的 Yui Role Skill，供 Codex 按需读取。model、effort、permission、workspace 与 shell 设置作为共享 daemon 上的线程级 `thread/start` 或 `thread/resume` 配置传入；Codex 原生 config profile 因无法隔离到单条共享 thread 而被拒绝，Yui 不修改底层 Codex 配置文件。App Server 原生通知是 Managed Codex 线程的生命周期权威；Yui 不为它安装 Hook，也不占用 `notify`。交互式 Codex Session 仍可使用 Yui 的结构化 `notify` callback，Doctor 会报告最终生效的配置冲突。`skills.config` 只负责启停已发现 Skill，Yui 不会误用它。Claude 从 Yui 管理的私有 `0600` context 文件读取同一份 Yui Role Skill 内容，不再把大段或敏感文本放进 argv；重试和 resume 会复用按 purpose 区分的稳定路径。非 Operator 的 global Role 保持中性，不会注入 Task 编排 Skill。因此 Operator 会停在空白的原生 composer，用户输入仍是第一条 user message；Leader wake、Worker 和 Reviewer Run assignment 仍是邮箱投递的真实工作消息。
+稳定的 Role 上下文不会创建额外的 bootstrap Turn。Task execution Turn 按角色使用通用 Leader 或 Worker Skill，review Turn 则按持久 Turn purpose 使用通用 Reviewer Skill；Provider 可以通过安全的追加式原生上下文通道携带 Skill，也可以在普通 Task 投递中指向它。这些都只是 Yui 自己拥有的可移植编排规则。Project Skills 始终是 Project 中正常版本化的文件，由 Agent 通过自身项目机制发现、选择并按需加载；Yui 不扫描、不解析、不复制，也不注入 Project Skills。Managed Codex 保留用户原有的 developer instructions；普通 Task 消息会携带精简的 Session Manifest 绝对路径，Manifest 再指向对应的 Yui Role Skill，供 Codex 按需读取。model、effort、permission、workspace 与 shell 设置作为共享 daemon 上的线程级 `thread/start` 或 `thread/resume` 配置传入；Codex 原生 config profile 因无法隔离到单条共享 thread 而被拒绝，Yui 不修改底层 Codex 配置文件。App Server 原生通知是 Managed Codex 线程的生命周期权威；Yui 不为它安装 Hook，也不占用 `notify`。交互式 Codex Session 仍可使用 Yui 的结构化 `notify` callback，Doctor 会报告最终生效的配置冲突。`skills.config` 只负责启停已发现 Skill，Yui 不会误用它。Claude 从 Yui 管理的私有 `0600` context 文件读取同一份 Yui Role Skill 内容，不再把大段或敏感文本放进 argv；重试和 resume 会复用按 purpose 区分的稳定路径。非 Operator 的 global Role 保持中性，不会注入 Task 编排 Skill。因此 Operator 会停在空白的原生 composer，用户输入仍是第一条 user message；Leader wake、Worker 和 Reviewer Turn assignment 仍是邮箱投递的真实工作消息。
 
 ## Controller 与失败处理
 
@@ -587,23 +574,23 @@ Controller；如果之前没有运行，会在完成后启动。只读命令和
 `upgrade --dry-run` 不会启动 Controller。`update` 只有在新二进制健康检查通过后，
 才会替换或启动 Controller。
 
-恢复 reconciliation 默认每 120 秒执行一次。普通持久状态变化只会将 Task、Role 或 Operator key 放入队列并立即返回；固定 100ms 窗口内到达的 key 会合并触发一次不重叠的定向处理。Operator 呈现使用独立 lane，不会被 Task 的 Git/worktree 操作阻塞；周期 Git/worktree 处理只覆盖仍有持久 Task mailbox 工作的 Task，活动 Role 的存活检查合并为一次 tmux inventory。来自 Provider 原生事件或受支持 Hook 的结构化 Agent Driver observation，会经过精确 fence 后进入持久 runtime inbox。终态 Turn observation 会给合法的 yield、输入请求或完成动作保留 2 秒竞争窗口；到期后才关闭被 Agent 遗忘的活动 Role Run。持久 WorkMailbox 会冻结当前 processing 批次，期间的新事件合并到下一 pending 批次；失败会释放当前批次供恢复。推荐输入与 pending Turn 共用最近 deadline 选择器，不依赖恢复扫描间隔；显式 `task reconcile` 仍会立即请求恢复扫描。保留的闭环为：
+恢复 reconciliation 默认每 120 秒执行一次。普通持久状态变化只会将 Task、Role 或 Operator key 放入队列并立即返回；固定 100ms 窗口内到达的 key 会合并触发一次不重叠的定向处理。Operator 呈现使用独立 lane，不会被 Task 的 Git/worktree 操作阻塞；周期 Git/worktree 处理只覆盖仍有持久 Task mailbox 工作的 Task，活动 Role 的存活检查合并为一次 tmux inventory。来自 Provider 原生事件或受支持 Hook 的结构化 Agent Driver observation，会经过精确 fence 后进入持久 runtime inbox。终态 Turn observation 会原子记录精确的 Turn 结果。持久 WorkMailbox 会冻结当前 processing 批次，期间的新事件合并到下一 pending 批次；失败会释放当前批次供恢复。推荐输入与 pending Turn 共用最近 deadline 选择器，不依赖恢复扫描间隔；显式 `task reconcile` 仍会立即请求恢复扫描。保留的闭环为：
 
 1. 准备 active Project Task 的主 worktree；
 2. 停止 archived Task 的 tmux，并只清理干净 worktree；
-3. 投递排队的 Worker Run；
+3. 投递排队的 Worker Turn；
 4. 检测活动 Role 进程退出；
 5. Leader 空闲时投递 pending wake。
 
-自动输入只通过 tmux 投递。每次处理只做一次非阻塞的 process-state readiness 检查；启动阶段忙碌时通过小型有界 mailbox timer 重试，后续忙碌会话通常由 Codex turn-complete 事件再次唤醒。pane 内 receipt 可避免 Controller 重试时重复输入同一 Run。
+自动输入只通过 tmux 投递。每次处理只做一次非阻塞的 process-state readiness 检查；启动阶段忙碌时通过小型有界 mailbox timer 重试，后续忙碌会话通常由 Codex turn-complete 事件再次唤醒。pane 内 receipt 可避免 Controller 重试时重复输入同一 Turn。
 
-Role 在 yield 前退出时，Controller 会失败对应 Run 和 running WorkItem，并唤醒 Leader。恢复状态通过精简的 Jobs 兼容视图呈现：
+Role 进程未产生 Provider 终态结果就退出时，Controller 会失败对应 Turn 和 running WorkItem，并唤醒 Leader。恢复状态通过精简的 Jobs 视图呈现：
 
 ```sh
 yui jobs list
 yui jobs retry leader-recovery:<task-id>
 yui task reconcile <task-id>
-yui task run retry <failed-run-id>
+yui task turn retry <failed-turn-id>
 ```
 
 `jobs` 不是旧版通用队列，只展示持久 Leader wake 和 Leader recovery failure。
@@ -619,7 +606,7 @@ yui web
 # Yui web control room: http://127.0.0.1:4173
 ```
 
-可用 `--port <port>` 或 `--host 127.0.0.1|::1|localhost` 修改监听参数。Yui 会拒绝非 loopback host，因为控制室会展示 Task、Role、WorkItem、Run、Message、Decision、Milestone 和 InputRequest 等信息。服务启动时生成的随机 token 会嵌入页面，并保护写操作和终端连接。
+可用 `--port <port>` 或 `--host 127.0.0.1|::1|localhost` 修改监听参数。Yui 会拒绝非 loopback host，因为控制室会展示 Task、Role、WorkItem、Turn、Message、Decision、Milestone 和 InputRequest 等信息。服务启动时生成的随机 token 会嵌入页面，并保护写操作和终端连接。
 
 Web 端可以通过与 Terminal 相同的持久化 CLI 路径回答 open InputRequest，也可以通过原生 xterm 客户端 attach 到已有 Operator、Leader 或 Worker tmux pane。关闭浏览器终端只会 detach 当前 tmux client，Agent 进程与对话继续保留；Web 不复制 transcript，也不维护第二套会话状态。
 

package/package.json

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