@zq-silk/yui 2.10.0 → 2.12.0

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

@@ -36,6 +36,64 @@ Agent 选择一个预先声明的计划，设施从持久状态驱动该计划
 不能将不兼容冒称为兼容，也不为回避版本选择新增历史兼容机制。包版本与协议、
 持久存储契约仍然独立：兼容性检查和必要迁移要求不变，下文存储规则不授予发版权限。
 
+### 2.12.0 兼容性及迁移说明
+
+本 minor 完成作用域明确的 Job 平台：显式业务结果及固定产物、Schedule 目标与服务
+授权、受控 Project 刷新、Task 委派、可选 Agent 执行，以及共用的 Task／全局 Web
+管理。Task 的 Jobs 页签和 Settings → Jobs & schedules 展示准确的历史 Run、
+不可变配置、执行证据及获授权的产物预览。
+
+调用方须区分定义归属、执行目标、进程／原生终态证据和显式 `businessResult`；
+投递或进程退出本身不代表业务成功。按执行器种类处理 Run，不再假设每个 Run 都是
+shell 进程。固定产物引用保留准确来源身份和作用域；可以预览不等于允许执行。
+Task 委派保留不可变来源，不隐式激活 Draft Task。Agent Session 替换保留 Run
+要求及结果，不重放输入；投递未知或旧写入者尚未证明停止时仍拒绝替换。
+详见 [Jobs 与 Runs](job-runs.md)。
+
+Schedule 继续复用已有准入路径，不引入第二套执行状态。服务授权必须明确授予，
+不继承旧 Session 权限，也不授权 Agent 执行。受控 `project.refresh` 绑定当前
+受管 Project 目标，复用工作区干净、准确核验后的 fast-forward 路径；发布不会为
+任何已注册 Project 启用同步。详见 [Schedules](schedules.md)。
+
+存储通过集中连续迁移链从 **1.14 升至 1.20**：**1.15** 业务结果；
+**1.16** Schedule 目标／服务授权；**1.17** 固定 Run 产物；
+**1.18** 受控 Project 刷新；**1.19** Task 委派／来源；**1.20** Agent Run／Session
+证据。支持的 **1.0–1.19** Home 使用已声明的同 major 迁移，保留历史证据，
+不编造结果或授权。另获更新授权后可使用 `yui update --version 2.12.0`；
+updater 负责预检、备份、迁移和 Controller 交接。不要用旧二进制打开升级后的 Home，
+也不要手改存储。minor 编号不是 SemVer 向后兼容承诺。
+
+发布门禁要求准确提交的 Core CI，以及同一运行包在 Linux x64、macOS x64/arm64
+和 Node 20/22/24/26 上的全新安装验证。这些是确定性的隔离检查，不是真实模型验证。
+发布不会更新全局 CLI、迁移生产 Home、替换其 Controller 或运行真实 Project 同步。
+
+### 2.11.0 兼容性及迁移说明
+
+本 minor 允许普通非受管原生 Agent 会话使用与本地终端相同的公共操作，包括一般
+信息查询和创建 Draft Task。原生线程 ID 本身只是查询线索，不代表受管 Role。
+Draft 创建保留已有 Agent、模型、权限和 Profile 配置继承，不启动讨论或开发。
+
+当前仅有原生 ID 的受管 Desktop 会话继续校验 Role、Task、Assignment 和 Grant。
+已知历史、停止、冲突或不完整的受管身份保持拒绝，不降级为公共权限。解绑 Session
+或删除 Role 后保留停止的身份历史。帮助与补全共用调用方发现；离线 Role 模板只是
+指引，不是授权。精确能力评估与执行继续采用当前资源和 Grant 边界。
+详见[授权职责和权限矩阵](authorization.md)。
+
+身份查询仅限所选 Home。仅在其他 Home 登记、或已被旧版本删除历史且没有 Yui
+提示的裸 ID，无法与普通线程区分。受管会话必须保留正确 Home/Manifest；
+本版本不扫描其他 Home，也不重建已删除历史。
+
+存储通过显式集中迁移从 **1.13 升至 1.14**，允许全局 Session 历史在 Role 删除后
+保留，同时保留已有 payload。受支持的 **1.0–1.13** Home 使用连续同 major 升级
+路径。另行获得更新授权后，可使用 `yui update --version 2.11.0`，由 updater 负责
+预检、备份、迁移与 Controller 交接。不要用旧二进制打开升级后的 Home，也不要
+手工修改存储。包 minor 编号不构成兼容性承诺。
+
+发布复用精确提交的 Core CI，并在 Linux x64、macOS x64/arm64 和
+Node 20/22/24/26 上验证同一运行包后发布 npm。这些是确定性隔离验证，
+不是实际模型验证。包发布不更新全局 CLI、不迁移生产 Home、不替换生产 Session，
+也不启动 Web 监听。
+
 ### 2.10.0 兼容性及迁移说明
 
 本稳定 minor 包含精确 Turn 收件箱处理与继任恢复（Task131 / PR #463、

package/docs/schedules.md

@@ -1,6 +1,11 @@
 # Persistent time plans
 
-A Schedule answers **when** to admit a Run of an existing scoped Job. It owns
+For the installed Project maintenance plan and its user overrides, see
+[Built-in Project sync](project-sync.md) ([简体中文](project-sync.zh-CN.md)).
+
+A Schedule answers **when** to dispatch a scoped Job. It either admits a Run
+of an existing Job (default), or asks the Job layer to instantiate an exact
+definition revision as a new Job and admit its first Run. It owns
 the time rule and trigger progress, not the command, execution status or result.
 Immediate execution remains `job run`; manual Runs do not move a Schedule.
 All processing uses the existing Controller and the Job supervisor.
@@ -9,6 +14,7 @@ All processing uses the existing Controller and the Job supervisor.
 
 ```sh
 yui schedule create --global --schedule daily-probe --job probe \
+  --authorization service \
   --rule '{"kind":"cron","expression":"30 9 * * 1-5","timezone":"Asia/Shanghai"}'
 yui schedule list --global
 yui schedule show --global --schedule daily-probe
@@ -16,17 +22,26 @@ yui schedule disable --global --schedule daily-probe --revision 1
 yui schedule enable --global --schedule daily-probe --revision 2
 yui schedule update --global --schedule daily-probe --revision 3 \
   --rule '{"kind":"interval","anchor":"2026-10-17T00:00:00Z","everyMs":3600000}'
+# New Job per occurrence, pinned to the currently available source revision:
+yui schedule create --global --schedule isolated-probe --job probe \
+  --authorization service --target '{"kind":"new-job","definitionRevision":1}' \
+  --rule '{"kind":"interval","anchor":"2026-10-17T00:00:00Z","everyMs":3600000}'
+# Unlike disable, revoke also denies not-yet-started service Runs:
+yui schedule revoke --global --schedule isolated-probe --revision 1
 ```
 
 Create the referenced Job first using [the Job CLI](job-runs.md). Replace
-`--global` with `--task task-N` for a Task-owned Schedule. Global management
-requires a current authenticated Operator Session; Task callers cannot access
+`--global` with `--task task-N` for a Task-owned Schedule. Public local users can
+manage global plans without an Operator Session. Creating or rebinding a public
+plan requires the explicit `--authorization service` choice. Current Operator
+callers can also choose service authorization; omitting it on creation preserves
+the Session-bound behavior. Task callers cannot access
 global or other Tasks' plans. Assignment limits are checked against the Job
 on the server. A Project is a Job target, never an ownership scope.
 
 The Controller RPC is `schedule.control`. Its input is
-`{op,scope,caller,id?,jobId?,rule?,expectedRevision?}`. Supported `op` values
-are `create`, `list`, `show`, `update`, `enable`, `disable`. `scope` uses the
+`{op,scope,caller,id?,jobId?,target?,authorization?,rule?,expectedRevision?}`. Supported `op` values
+are `create`, `list`, `show`, `update`, `enable`, `disable`, `revoke`. `scope` uses the
 Job `JobScope` contract. Trusted ingress must resolve/authenticate `caller`;
 client-supplied scope/identity is not authorization. `create` requires `id`,
 `jobId`, `rule`; all edits require the observed `expectedRevision`. `update`
@@ -35,9 +50,17 @@ revalidating both old visibility and new execution authority. Scope is immutable
 Rule updates retain enabled status only for an already enabled plan; all other
 states become disabled with the new future rule and require explicit enable.
 
+`target` defaults to `{"kind":"existing-job"}`. `{"kind":"new-job",
+"definitionRevision":N}` requires the exact currently available source version.
+A source edit never silently changes that pinned selection; explicitly update
+the target and, for service plans, reauthorize. Job owns deterministic instance
+identity and `instantiation` provenance (`sourceId`, `sourceRevision`, occurrence
+`key`). It does not create a Task. Each new instance has its own overlap scope;
+existing-job mode retains one Job's overlap behavior.
+
 Create/edits return the Schedule; list returns visible Schedule records.
-Show returns `{schedule,lastSuccess}`. `lastSuccess` is the latest readable
-**succeeded JobRun** triggered by this Schedule under its current Job, or null.
+Show returns `{schedule,lastSuccess,runs}`. `lastSuccess` is the latest readable
+**succeeded JobRun** triggered by this Schedule across its historical Jobs, or null.
 It is derived from Run history, never a separately writable Schedule field.
 Retargeting does not move or erase the old Job's Run history.
 
@@ -71,7 +94,7 @@ prevents clock rollback or rule edits from replaying old progress.
 Rule updates increase `generation`; enable retains it. The internal trigger
 key is `<schedule-id>:<generation>:<UTC-due>`, scoped to the Job.
 
-Admission and advancement commit in the same Store transaction. Repeated scans
+Instance creation, first Run admission and advancement commit in the same Store transaction. Repeated scans
 and Controller replacement retain the same Run and occurrence identity.
 The transaction never spawns. The supervisor starts committed Runs and
 preserves its existing unknown-effect and exact-process safeguards.
@@ -86,13 +109,15 @@ Task terminal shutdown. Disabling does not cancel an already admitted Run,
 and cancelling a Run does not disable its Schedule.
 
 `lastAttempt` records `at`, `dueAt`, `outcome` (`admitted`, `overlap`, `blocked`),
-optional exact `runId`, and reason. An overlap Run is the occupying execution,
+optional exact `jobId`/`runId`, `generation`, and reason. Old receipts retain
+only what was originally known; migration does not invent those references.
+An overlap Run is the occupying execution,
 not a successful execution of this occurrence. Recurring overlap skips that
 coalesced tick and advances; once overlap retains its original due instant and
 retries admission on a later pass without adding a queued Run.
 Failed Runs stay in Job history; the next recurring tick follows the same plan.
 
-Creation, update and enable capture the authenticated Session binding and Job
+Session-authorized creation, update and enable capture the authenticated Session binding and Job
 revision. They do not grant execution to a replacement Session or a changed
 Job definition. Before each admission both are checked again, along with current
 Job/Task/workspace prerequisites. Revocation or a changed definition stops the
@@ -100,8 +125,31 @@ plan as `needs-attention`; an authorized current manager must inspect and
 explicitly enable it. Controller restart alone does not revoke the binding.
 Worker-owned plans also retain the current Assignment boundary.
 
+Service authority is a separate explicit grant stored on the Schedule. The
+compiled internal `schedule` registration permits only global `system.noop`
+and `project.refresh`; it does not permit Task shell execution, arbitrary code,
+or additional scopes. `origin=builtin`, `caller.scope=service` and client-supplied
+grant fields cannot create a service identity. Management first authenticates
+the ordinary public/managed caller and checks the actual Job target.
+The grant binds Home, Schedule, dispatch mode, exact definition, action, Project
+and input. Admission and runner start recheck current validity; Project refresh
+also rechecks after waiting for its maintenance lock. Replacing Operator Sessions
+does not revoke a service grant. Source/configuration changes block the plan
+with retained reasons; no silent rebind occurs.
+Service Run results remain in Job history and do not enqueue an Operator wake.
+Dispatch errors still use the existing attention notification when a recipient exists.
+
+`disable` only stops future dispatch; it does not invalidate the grant of an
+already admitted Run. `revoke` disables the plan and invalidates the grant,
+preventing queued service Runs from starting (not cancelling effects already
+in flight). An explicit `enable --authorization service` grants a fresh identity;
+it never resurrects old revoked Runs. Ordinary enable/rule edits retain an
+unchanged active grant. Reauthorization and source/target changes are deliberate
+management operations, not automatic repairs.
+
 Unclassified admission failures roll back, stop that plan, persist the reason
-and notify its Task Leader or global Operator via existing durable inboxes.
+and notify its Task Leader or configured global Operator via existing durable inboxes.
+If no Operator role exists, the plan/reason remains inspectable without creating one.
 No new recovery queue, lease or automatic retry protocol is introduced.
 
 Task stop marks enabled plans as needing attention; restarting execution alone
@@ -114,14 +162,20 @@ settlement guards. A reopened Task does not implicitly resume retired plans.
 
 ## Storage and downstream integration
 
-Storage **1.9 → 1.10** appends `schedules`, keyed by `(scope_key,schedule_id)`,
-and its due index. Old Job/Run bytes and published baseline checksums remain
-unchanged. New Homes initialize 1.10; existing Homes require the centralized
+Storage **1.15 → 1.16** adds explicit target and authorization kinds to existing
+plans, preserving Session bindings, identities, rules, progress and old receipts.
+Original Schedule bytes are archived under migration 16. It never turns historical
+Session authority into a service grant. New optional Job instance provenance and
+Run service-grant references use the existing tables. The published **1.9 → 1.10**
+DDL and all older transitions remain unchanged. New Homes initialize 1.16;
+existing Homes require the centralized
 explicit upgrade path. No real Home migration or package release is implied.
 
 `src/schedule/schedule.ts` exports `Schedule`, `ScheduleRule`, time calculation
 and validation. `src/controller/scheduleControl.ts` owns management and bounded
-reconciliation; `admitJobRun` remains the only execution admission seam.
+reconciliation; Job's `instantiateJobRun` composes instance creation with
+`admitJobRun`, the execution admission seam. No ScheduleRun state or second
+writable execution result is introduced.
 Consumers should use RPC/service responses rather than write storage directly.
 
 Project refresh is a separate controlled Job action supplied by Task128.

package/docs/storage-baseline.md

@@ -2,7 +2,51 @@
 
 # Storage baseline 1.0
 
-Current storage is 1.13. The 1.12 → 1.13 transition permits exact native attempt
+Current storage is 1.20. The 1.19 → 1.20 transition adds Agent Job configurations,
+optional Job ownership on Global Roles, and the `agent_job_runs` table for
+exact original-message/native-attempt evidence and explicit business results.
+Existing Role, Session, process Run and artifact identities are unchanged;
+no Agent or native Session is invented during migration.
+
+The 1.18 → 1.19 transition adds optional immutable Task
+creation source, exact Run delegation and Task/WorkItem result-reference kinds.
+Existing valid payload bytes, ordinary source-less Tasks, unknown effects and
+fixed references are unchanged; no historical source or authority is inferred.
+SQL layout is unchanged.
+
+The additive 1.17 → 1.18 transition admits builtin
+Project-sync provenance, a compiled service issuer and a separate user-enabled
+preference on new Schedules. SQL layout and every existing payload remain unchanged;
+it neither adopts custom Jobs nor fabricates historical grants or Runs.
+Installation is a Controller operation, separate from storage migration.
+
+The 1.16 → 1.17 transition adds optional append-only
+JobRun artifact references and scope/Run-isolated local Git repositories.
+Existing payload bytes and Task Git repositories/frozen references remain
+unchanged; no historical artifact, provenance or authorization is inferred.
+No SQL layout change or automatic cleanup is introduced.
+
+The 1.15 → 1.16 transition adds explicit Schedule
+dispatch targets and authorization kinds. Existing plans keep their exact Session
+authority, rules, identity and progress; original bytes are archived under migration
+16. No service permission is inferred. New service grants and Job instance
+provenance use the same tables; no ScheduleRun lifecycle is introduced.
+
+The 1.14 → 1.15 transition adds separate Job business
+results derived from saved process results, archiving original Run payload bytes
+under migration 15. It does not infer structured business data from logs, change
+execution identities, replay effects or rewrite frozen Context/Integration evidence.
+SQL layout is unchanged. Public immediate builtin admissions use an explicit
+Home/Run-bound user authority, not an invented Session or Schedule authorization.
+
+The 1.13 → 1.14 transition removes the Role foreign key
+from `global_role_session_sets`, preserving every payload byte and rebuilding
+its retry index. Stopped Session identity/history can then outlive Role removal
+without granting authority. No new authorization table or inferred history is
+introduced. Ordinary reads require current storage; only an explicit supported
+upgrade changes an existing Home. See [authorization](authorization.md).
+
+The 1.12 → 1.13 transition permits exact native attempt
 identity on new inbox claims, exact target identity on new steer controls,
 explicit Global inbox retirement and terminal handling-check evidence.
 It does not rewrite historical messages, infer old turn ownership or synthesize

package/docs/storage-baseline.zh-CN.md

@@ -2,7 +2,39 @@
 
 # 存储基线 1.0
 
-当前存储为 1.13。1.12 → 1.13 允许新 inbox claim 记录精确 native attempt、
+当前存储为 1.20。1.19 → 1.20 增加 Agent Job 配置、Global Role 的可选 Job
+归属和 `agent_job_runs` 表，保存原始消息、准确原生尝试与显式业务结果。
+保留现有 Role、Session、进程 Run 和固定产物身份；迁移不创建 Agent 或原生会话。
+
+1.18 → 1.19 增加 Task 可选且不可改写的创建来源、准确 Run
+委托及 Task/WorkItem 结果引用，不改变 SQL 布局或旧 payload 字节。
+普通历史 Task 仍无来源，不补造权限、来源或结果；未知效果与固定产物引用保持。
+
+1.17 → 1.18 允许新记录携带内置 Project 同步来源、
+编译期注册服务签发者及独立的用户启停偏好；SQL 布局和已有 payload 原字节不变。
+迁移不接管手建 Job、不补造历史授权或 Run；安装由 Controller 单独核对。
+
+1.16 → 1.17 增加 JobRun 可选的只追加产物引用，
+以及按 scope 和 Run 隔离的本地 Git 正式产物库。原 payload 字节、
+Task 产物库及冻结引用保持不变，不补造历史产物、来源或授权，
+不改变 SQL 布局，也不增加自动清理。
+
+1.15 → 1.16 增加明确的 Schedule 派发目标及授权类型；
+原计划保留准确 Session 授权、规则、身份与进度，原始字节归档于 migration 16。
+不推导或升级为服务权限。新增服务授权和 Job 实例来源沿用原表，不新增 ScheduleRun 生命周期。
+
+1.14 → 1.15 根据已保存的进程结果增加独立的 Job 业务结果，
+原始 Run payload 字节归档于 migration 15；不从日志猜测结构化业务数据，
+不改执行身份，不重放动作，也不改冻结 Context 或 Integration 证据。SQL 布局不变。
+公共即时 builtin 使用绑定 Home/Run 的 user 授权，不伪造 Session，也不授予 Schedule 持久权限。
+
+1.13 → 1.14 只移除 `global_role_session_sets` 对 Role 的外键，
+原样保留 payload 并重建 retry 索引，使已停止会话的身份／历史在角色移除后继续保留，
+但不赋予权限。不新增授权表，不补造已经丢失的历史。普通读取要求当前存储版本，
+已有 Home 只能通过显式受支持升级迁移，不能在读取时自动迁移。
+详见 [权限职责与矩阵](authorization.md)。
+
+1.12 → 1.13 允许新 inbox claim 记录精确 native attempt、
 新 steer control 记录精确目标，以及 Global 输入显式退役和终态缺回执检查证据。
 不改写历史消息、不推断旧轮次归属、不补造 ACK；SQL 布局不变。
 当前输入和历史处理缺证据通过有界视图分别发现，不新增第二队列。

package/docs/testing/verification-levels.md

@@ -50,12 +50,12 @@ is required.
 ## Permanent core smoke
 
 `npm test` and `npm run test:core` build the checkout and run the maintained suite.
-The stable suite owns current storage 1.13 and its declared 1.0 through 1.12 minor
+The stable suite owns current storage 1.20 and its declared 1.0 through 1.19 minor
 transition. It contains no undeclared historical format compatibility path.
 
 Current coverage includes:
 
-1. Fresh storage 1.13, exact schema/record validation, no initialization over
+1. Fresh storage 1.20, exact schema/record validation, no initialization over
    unknown data, and rejection of old integer formats without mutation.
 2. Exact-version staging, mismatched-target refusal, same-major contiguous
    minor preflight, explicit maintenance-owner identity across handover, and

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

@@ -36,12 +36,12 @@ Yui 是一个单用户本地产品。永久验证保护关键的 happy path 和
 ## 永久 core smoke
 
 `npm test` 和 `npm run test:core` 构建当前 checkout 并运行维护中的套件。
-稳定套件维护当前存储 1.13 和明确声明的 1.0 至 1.12 连续小版本迁移，
+稳定套件维护当前存储 1.20 和明确声明的 1.0 至 1.19 连续小版本迁移，
 不包含未声明的历史格式兼容路径。
 
 当前覆盖包括：
 
-1. 新建存储 1.13、精确结构与记录校验、禁止覆盖未知数据库、无修改拒绝旧整数格式。
+1. 新建存储 1.20、精确结构与记录校验、禁止覆盖未知数据库、无修改拒绝旧整数格式。
 2. 精确版本暂存、目标不匹配拒绝、同主版本连续小版本预检、交接锁显式所有者，
    以及恢复时核对捕获的协议和存储身份，不接受缺失字段。
 3. 持久 Task／Message／Decision 上下文、Draft 激活权威、mailbox 认领、

package/package.json

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

package/skills/yui-runtime/SKILL.md

@@ -80,11 +80,18 @@ is wrong or unavailable, report that fact and use the explicitly authorized
 entry/environment; do not guess another installation or clear Session identity.
 
 Desktop commands may carry only `CODEX_THREAD_ID`. The CLI resolves that native
-identity in the selected Home's current Session registry before routing Task or
-Global operations. Environment and Manifest values are location hints, not
-continuing grants. Conflicting, unregistered, replaced or revoked identities
-do not become public-user callers; a plain user terminal has no managed/native
-identity. `inbox list` reports the resolved current identity. Do not add or clear
+identity against the selected Home's current and historical Session records before
+routing operations. An unknown provider thread with no Yui-specific identity hints
+is an ordinary public caller, like a user terminal; it needs no managed Manifest
+to read public information or create a Draft Task. This does not start discussion
+or development or grant internal managed capabilities. Public command availability
+is not user authorization for a new effect.
+Environment and Manifest values are location hints, not continuing grants.
+Conflicting, partially specified, unregistered Yui identities and known historical
+or revoked Sessions do not become public callers. An ID known only in another
+Home cannot be recognized from the selected Home alone: keep the intended
+Home/Manifest context rather than switching Homes or dropping hints.
+`inbox list` reports the resolved managed identity. Do not add or clear
 environment fields to repair a mismatch. Without a Manifest environment pointer,
 `session skills` returns current Skill paths and the Session's captured profile.
 

package/skills/yui-runtime/VERSION

@@ -1 +1 @@
-10
+11