@zq-silk/yui 2.8.0 → 2.9.0

package/docs/schedules.md

@@ -0,0 +1,132 @@
+# Persistent time plans
+
+A Schedule answers **when** to admit a Run of an existing scoped Job. 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.
+
+## Public CLI and API
+
+```sh
+yui schedule create --global --schedule daily-probe --job probe \
+  --rule '{"kind":"cron","expression":"30 9 * * 1-5","timezone":"Asia/Shanghai"}'
+yui schedule list --global
+yui schedule show --global --schedule daily-probe
+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}'
+```
+
+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 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
+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`
+requires a complete rule and optionally changes `jobId` within the same scope,
+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.
+
+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.
+It is derived from Run history, never a separately writable Schedule field.
+Retargeting does not move or erase the old Job's Run history.
+
+## Time and trigger rules
+
+- Once: `{"kind":"once","at":"2026-10-17T08:00:00+08:00"}`. Creation and rule
+  replacement require a future instant with an explicit UTC offset.
+- Interval: `{"kind":"interval","anchor":"2026-10-17T00:00:00Z","everyMs":60000}`.
+  Minimum interval is 1000 ms. Occurrences are anchor + N × everyMs, N ≥ 0.
+  The next occurrence is strictly after creation/edit/enable time. Manual
+  execution and maintenance delays never shift the anchor.
+- Cron: five fields, explicit IANA timezone, `cron-parser` 5.10.2 semantics.
+  Random `H` is rejected. DST spring gaps move the nonexistent time forward
+  by the offset change; repeated fall local times select the earlier instance
+  once. For example New York 02:30 on March 8, 2026 becomes 03:30 (07:30Z);
+  01:30 on November 1 selects 05:30Z, with the next daily occurrence November 2
+  at 06:30Z. This deliberately uses the parser's policy, not a custom
+  “skip gap / both folds” enumerator.
+
+`nextDue` is persisted as UTC. Each Controller reconciliation admits at most
+one occurrence per selected Schedule, with at most 100 due Schedules per pass.
+Plans are ordered by oldest attempt to prevent blocked once plans starving
+others. This is maintenance-resolution scheduling, not a real-time timer:
+actual admission can lag the due instant by Controller load/reconciliation
+interval. No independent daemon or per-plan timer is created.
+
+After downtime, the earliest pending occurrence represents the coalesced
+work; the next occurrence is strictly after the current clock/high-water fence.
+There is no historical catch-up queue. A persisted UTC `processedThrough`
+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
+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.
+This is not an exactly-once guarantee for external side effects.
+
+## State and authority
+
+`enabled` allows future admission; `disabled` is explicit user/Agent disposal
+of future intent; `completed` means a once occurrence was **admitted**, not that
+its Run succeeded; `needs-attention` preserves blocked intent; `retired` records
+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,
+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
+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
+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.
+
+Unclassified admission failures roll back, stop that plan, persist the reason
+and notify its Task Leader or global Operator via existing durable inboxes.
+No new recovery queue, lease or automatic retry protocol is introduced.
+
+Task stop marks enabled plans as needing attention; restarting execution alone
+does not silently reactivate them. Normal Task completion refuses unfulfilled
+enabled/blocked once plans: explicitly disable or fulfil them first. Repeating
+plans do not block completion and are atomically retired with the Task.
+Cancellation/archive retires enabled/blocked plans with their reason and
+history preserved. Existing active/unknown Runs retain all earlier lifecycle
+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
+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.
+Consumers should use RPC/service responses rather than write storage directly.
+
+Project refresh is a separate controlled Job action supplied by Task128.
+Schedule does not implement refresh or Knowledge maintenance. A refresh Job
+can use the same reference-only plan once that action is integrated and tested;
+this document alone is not evidence of that joint integration.
+InputRequest recommended-option deadlines, heartbeat, redelivery and other
+internal domain timers remain with their existing owners.

package/docs/storage-baseline.md

@@ -2,7 +2,24 @@
 
 # Storage baseline 1.0
 
-Current storage is 1.8. The declared 1.7 → 1.8 transition permits an optional
+Current storage is 1.11. The declared 1.10 → 1.11 transition adds source provenance
+to new activation-request event payloads: an existing Message/body digest or
+exact caller-attributed native input, plus the recorded Message boundary.
+Historical events are preserved without guessed sources or replay. Missing
+provenance is an explicit read diagnostic. SQL layout and frozen digests are
+unchanged; the centralized transition has no data rewrite.
+New Task Job status/result/cancellation/acknowledgement writes also append
+`job.state-changed` events atomically. Existing Job history is not backfilled.
+
+The 1.9 → 1.10 transition appends independent
+[Schedules](schedules.md) and their due index without rewriting Jobs or Runs.
+
+The declared 1.8 → 1.9 transition adds stable Job
+definitions and global Runs, and links each historical Task execution to its
+own definition while preserving exact IDs, artifacts and Integration references.
+Original Job payload bytes are archived. See [Job/Run contracts](job-runs.md).
+
+The declared 1.7 → 1.8 transition permits an optional
 Model management connection in Yui configuration. Only service addresses and
 file references are stored; no credentials are imported. Existing Homes remain
 unconfigured, and the SQL layout is unchanged.

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

@@ -2,7 +2,21 @@
 
 # 存储基线 1.0
 
-当前存储为 1.8。1.7 → 1.8 允许在 Yui 配置中保存可选的 Model 管理连接，
+当前存储为 1.11。1.10 → 1.11 为新 activation-request 事件增加来源证据：
+已有 Message 及正文 digest，或带调用者归属的原生输入原文，以及当时的 Message 序号边界。
+历史事件保持原样，不推测缺失来源、不重放输入；缺失来源通过读取诊断明确展示。
+SQL 布局及冻结 digest 不变，集中迁移不改写历史正文。
+新的 Task Job 状态、结果、取消请求及确认处置原子追加 `job.state-changed` 事件；
+不回填历史 Job 事件。
+
+1.9 → 1.10 追加独立 [Schedule](schedules.md) 表和到期索引，
+不改写历史 Job/Run，也不自动启用任何计划。
+
+1.8 → 1.9 新增稳定 Job 定义和 global Run；每条历史 Task 执行
+独立映射为定义，保留原执行 ID、产物与 Integration 精确引用，并归档原始 payload。
+详见 [Job/Run 契约](job-runs.md)。
+
+1.7 → 1.8 允许在 Yui 配置中保存可选的 Model 管理连接，
 仅保存服务地址及文件引用，不导入凭据；已有 Home 保持未配置，SQL 布局不变。
 
 1.6 → 1.7 为规范 Message 和 Leader wake 增加可选的 Agent

package/docs/task-delivery.md

@@ -208,8 +208,10 @@ Task Integration produced that exact candidate, pass its local ID with
 This records one Task event, not a new delivery status, Candidate lifecycle,
 Git operation, or permission to change completed work.
 
-`task publication verify` remains the explicit, authorized provider read. It
-records the remote source head, PR/MR state and merge commit independently of
+`task publication verify` accepts tool-neutral evidence with `--observation
+<json>`, or performs an explicit authorized provider read with the optional
+gh/glab adapter when that option is absent. Neither tool is mandatory.
+It records the remote source head, PR/MR state and merge commit independently of
 Task acceptance. A mismatched head or non-merged state is saved as **reported**,
 superseding earlier verification; provider errors or mismatched external identity
 write nothing. A merged provider observation verifies only that Publication's
@@ -218,6 +220,70 @@ Metadata/verification successors preserve adoption only through an uninterrupted
 same-candidate Publication lineage. Candidate or referenced Integration changes
 cannot silently reuse the decision.
 
+### Record a Leader's tool observation
+
+First `publication upsert` the owning Task's exact candidate, PR/MR URL and
+target branch. The Leader can inspect that object with any authorized CLI/API,
+interpret its result, and submit the following JSON using
+`task publication verify task-1/publication-1 --observation '<json>'`:
+
+```json
+{
+  "taskId": "task-1",
+  "publicationId": "publication-1",
+  "projectId": "project-1",
+  "provider": "gitlab",
+  "repository": "team/app",
+  "externalKind": "merge-request",
+  "externalId": "42",
+  "externalUrl": "https://forge.example/team/app/-/merge_requests/42",
+  "targetBranch": "main",
+  "localCommit": "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa",
+  "state": "merged",
+  "headCommit": "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa",
+  "remoteCommit": "bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb",
+  "observedAt": "2026-10-17T04:00:00.000Z",
+  "tool": "internal-cli",
+  "command": "internal-cli mr inspect team/app!42",
+  "output": "{\"iid\":42,\"state\":\"merged\",\"sha\":\"aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa\",\"merge_commit_sha\":\"bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb\"}"
+}
+```
+
+Replace every example identity, SHA, timestamp and output with observed facts.
+`provider` describes the forge (GitHub PR or GitLab MR), not the tool brand.
+All fields shown are required for a merged observation; `remoteCommit` is optional
+for open/closed, and `mergedAt` is optional. Output must be a nonempty, sanitized
+relevant response excerpt, not credentials or just a conclusion; the whole JSON
+is limited to 64 KiB. Yui never executes `command` or parses arbitrary output into
+success. It trusts the authorized caller's inspection and checks exact identity,
+URL/service, target, candidate and timestamps.
+
+New evidence must refer to the current Publication, be no more than 24 hours
+old and not future-dated. Observation may precede initial bookkeeping or a
+title-only update. Immutable history supplies the lower time bound only when
+the candidate, object, target or remote facts materially changed; changing and
+restoring a candidate does not revive earlier evidence. After a title-only
+update, bind the same actual result to the current record ID without re-querying.
+An exact immediate retry returns the existing receipt without duplicating it;
+later changes cannot replay it. The full canonical JSON is kept in the existing
+opaque `evidence` text, with actor and record time on the immutable Publication.
+There is no new persistent format or migration; historical records remain valid.
+Once recorded, verification is a fixed observation, not live monitoring or a
+24-hour archive lease. Known later changes require a successor; failures and
+unknown results never assert a fresh success. URL/target/candidate changes reset
+verification, while title-only changes can retain it.
+GitHub repository URL comparison respects case-insensitive owner/name identity.
+GitLab relative deployment paths are allowed, but the complete registered
+service prefix must still match. Adapter observations retain the observed target
+branch even when the earlier Publication did not specify one; missing targets
+cannot establish new verification.
+
+`upsert --verified` is now rejected: use this observation path or the optional
+adapter. No natural-language summary or bare flag verifies a merge. Existing
+verified records are not rewritten. Remote delivery and ordinary archive reuse
+sufficient exact evidence without another gh/glab read; acceptance, business
+settlement, stopped execution and safe resource cleanup remain independent.
+
 CLI, current Leader Context and Web derive coverage from these same facts, with
 no provider reads or evidence writes. They distinguish not delivered, merged
 but uncovered, covering merge not verified, partial delivery and verified merge.

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

@@ -161,13 +161,45 @@ Review 时跳过刷新，该新鲜度字段为 null。重复完成不重新观
 `--integration <id>`，一并绑定其已提交证据。这只新增一个 Task 事件，不新增交付
 状态表、Candidate 生命周期或 Git 操作，也不授权修改已完成成果。
 
-`task publication verify` 仍是显式且须获授权的 provider 读取。它独立于 Task
+`task publication verify --observation '<json>'` 接受 Leader 通过任意获授权
+CLI/API 得到的精确工具证据；省略此选项时才使用可选 gh/glab 适配器执行 provider
+读取。不强制工具品牌，也不要求已充分核验的结果再用 gh/glab 重查。它独立于 Task
 验收，记录远端 source head、PR/MR 状态和 merge commit。head 不匹配或尚未合并时，
 保存为 **reported** 并取代旧验证；provider 错误或外部身份不匹配则不写任何证据。
 已合并的 provider 观察仅验证该 Publication 的精确本地候选；squash 不需要伪造
 提交祖先关系。元数据/验证更新只有沿连续同候选的 Publication 血缘才能继承采用；
 候选或所引用的 Integration 变化，不能悄悄复用旧决定。
 
+先用 `publication upsert` 登记本 Task 的精确候选、PR/MR URL（含服务地址）和
+目标分支，再用工具检查该对象。观察 JSON 的完整示例见
+[工具证据录入](task-delivery.md#record-a-leaders-tool-observation)；
+必需字段为 `taskId`、`publicationId`、`projectId`、`provider`、`repository`、
+`externalKind`、`externalId`、`externalUrl`、`targetBranch`、`localCommit`、
+`state`、`headCommit`、`observedAt`、`tool`、`command`、`output`。
+合并状态还必须有 `remoteCommit`，`mergedAt` 可选。SHA 为完整小写值，时间为
+ISO 时间戳。`provider` 表示 GitHub/GitLab 服务，不表示工具品牌。
+`output` 保留经过脱敏的实际响应关键摘录，不是凭据或一句“已合并”结论；
+完整 JSON 最大 64 KiB。Yui 不执行 `command`，不解析任意自然语言来判定成功。
+Leader 负责实际检查和解释输出，Core 负责身份、服务 URL、目标、候选和时间绑定。
+
+新证据必须引用当前不可变 Publication，距登记不超过 24 小时且不能在未来。
+观察可以早于首次登记或仅标题更新；只有不可变历史中的候选、对象、目标或远程事实
+发生实质变化，才构成观察时间下界。候选改变后又恢复，也不能复用变化前的证据。
+仅标题更新时，将实际结果绑定到当前记录 ID，无需重新查询。
+相同观察的直接重试复用原回执；之后发生变化
+不能重放旧回执。完整规范化 JSON 保存在既有不透明 `evidence` 文本中，操作者和
+登记时间由 Publication 保留；没有新增持久化格式，也不改写历史证据。
+登记后的验证是固定观察，不是实时监控或 24 小时归档租约；已知后续变化须另记
+后继事实。失败或未知结果不能变成新的验证成功。URL、目标分支、候选变化会失效
+旧验证；仅标题变化可保留验证。
+GitHub URL 按 owner/name 不区分大小写比较；GitLab 支持相对部署路径，但完整的
+已登记服务前缀仍须匹配。适配器会持久化实际读到的目标分支，即使原记录未填写；
+缺失目标分支不能建立新的验证。
+
+`upsert --verified` 现在会被拒绝，请使用上述观察入口或可选适配器。
+现存已验证历史保持可读。普通归档复用精确充分的证据，不重跑指定工具；
+候选验收、业务结清、执行停止和安全清理检查不变。
+
 CLI、当前 Leader Context 和 Web 从同一组事实推导覆盖，不联网、不写证据。展示
 区分尚未交付、PR/MR 已合并但未覆盖、已覆盖合并但未验证、部分交付、已验证合并。
 每个 Project 保留自己的验收 head、候选、采用引用和原因。缺失的历史 head 仍然

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.8 and its declared 1.0/1.1/1.2/1.3/1.4/1.5/1.6/1.7 minor
+The stable suite owns current storage 1.11 and its declared 1.0 through 1.10 minor
 transition. It contains no undeclared historical format compatibility path.
 
 Current coverage includes:
 
-1. Fresh storage 1.8, exact schema/record validation, no initialization over
+1. Fresh storage 1.11, 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
@@ -75,6 +75,10 @@ Current coverage includes:
 8. Failure isolation for optional Controller maintenance, individual retry
    Sessions and Task continuation observation, with scoped errors and no
    fabricated delivery, cancellation or quiescence.
+9. Activation-source handoff without replay, Brief guards across same-timestamp
+   input, Home/baseline-bound fixed event windows, and complete frozen-ref deltas
+   with removals. These deterministic checks establish contracts, not a model's
+   semantic conflict judgment.
 
 Keep the test phase seconds-scale and measure build separately. Use the
 existing assembled-package smoke for actual CLI/Controller/Host/tmux wiring,

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.0 和未来明确声明的小版本迁移，不包含任何历史
-转换实现、样本或兼容测试。
+稳定套件维护当前存储 1.11 和明确声明的 1.0 至 1.10 连续小版本迁移，
+不包含未声明的历史格式兼容路径。
 
 当前覆盖包括：
 
-1. 新建存储 1.0、精确结构与记录校验、禁止覆盖未知数据库、无修改拒绝旧整数格式。
+1. 新建存储 1.11、精确结构与记录校验、禁止覆盖未知数据库、无修改拒绝旧整数格式。
 2. 精确版本暂存、目标不匹配拒绝、同主版本连续小版本预检、交接锁显式所有者，
    以及恢复时核对捕获的协议和存储身份，不接受缺失字段。
 3. 持久 Task／Message／Decision 上下文、Draft 激活权威、mailbox 认领、
@@ -54,6 +54,9 @@ Yui 是一个单用户本地产品。永久验证保护关键的 happy path 和
    和备份行为。
 8. Controller 可选维护、各个重试 Session、Task continuation 观察的失败隔离，
    诊断包含所属对象，不伪造投递、取消或静默状态。
+9. 无重放的激活来源交接、同时间戳新输入使 Brief 写入校验失效、绑定 Home 与基线的
+   固定事件窗口，以及含移除项的完整冻结引用增量。这些确定性测试验证契约，
+   不代表已验证真实模型的语义冲突判断效果。
 
 测试阶段保持秒级，构建单独计时。真实 CLI／Controller／Host／tmux 接线复用现有
 组装包冒烟，不新增守护进程矩阵；稳定套件不重建任何已退役的存储路径。

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@zq-silk/yui",
-  "version": "2.8.0",
+  "version": "2.9.0",
   "description": "Local control plane for long-running native agent CLI sessions backed by tmux.",
   "license": "MIT",
   "private": false,
@@ -48,12 +48,13 @@
   "dependencies": {
     "@xterm/addon-fit": "^0.11.0",
     "@xterm/xterm": "^6.0.0",
+    "cron-parser": "5.10.2",
     "node-pty": "1.2.0-beta.15",
     "smol-toml": "1.8.0",
     "ws": "^8.21.1"
   },
   "optionalDependencies": {
-    "sqlite-modern": "npm:better-sqlite3@13.0.3",
-    "sqlite-compat": "npm:better-sqlite3@10.1.0"
+    "sqlite-compat": "npm:better-sqlite3@10.1.0",
+    "sqlite-modern": "npm:better-sqlite3@13.0.3"
   }
 }

package/skills/yui-leader/SKILL.md

@@ -42,6 +42,11 @@ transcript or process.
 
 Apply terminal/gate and read-only intent boundaries before selecting delivery
 or planning work; the routes below do not override those restrictions.
+When old discussion text differs from new intent, apply
+[current intent and temporal reads](../yui-runtime/references/context-ordering.md):
+inspect exact sources before treating normal stage progression as a conflict.
+An adopted same-scope development request supersedes the earlier discussion-only
+stage, not independent restrictions. Never use active status or Brief alone.
 
 - **Draft or planning-only authority:** read [Planning and activation handoff](references/planning.md).
   Use the recorded submission intent (`record`, `discuss`, `develop`) and
@@ -100,7 +105,8 @@ then ack the exact entry. Inbox acknowledgement
 never accepts a Candidate or completes the Task.
 
 The DB Brief is the current summary, not a full plan or a history of messages.
-After meaningful progress, use `task brief update` with only intended fields;
+After meaningful progress, read `task brief show` and use
+`task brief update --if-current <writeGuard>` with only intended fields;
 read `task event list` before deliberately restoring an older value. Keep
 references to substantial plans, prototypes and reports in that summary.
 When a delivered correction resolves a recorded blocker or changes the next
@@ -111,6 +117,10 @@ before `task complete`. The completion summary is the terminal conclusion;
 do not copy it into Brief merely to create a second completion record. Brief
 maintenance is not a new completion gate, and routine unchanged steps do not
 need an update.
+Also reconcile the summary at requirement changes and phase handoffs; carry the
+exact activation/input references. Core projects current lifecycle and source
+diagnostics without rewriting historical messages. A stale-guard rejection
+requires reading the new input and reconciling, not retrying the old text.
 Decisions contain the actual decision, reason and necessary boundaries, not
 the entire proposal. Label recommendations as recommendations, not user
 decisions.
@@ -132,6 +142,13 @@ heartbeat or unchanged wait. Ordinary fact edits need no self-wake.
 
 ## Close the current turn
 
+For external delivery, choose any available authorized CLI/API and follow
+[Publication evidence](../yui-runtime/references/publication.md). Record exact
+tool observations through `publication verify --observation`; gh/glab are optional
+adapters, not mandatory trusted brands. Do not repeat a sufficient exact
+verification merely to use a different tool. Tool inspection is your judgment;
+candidate acceptance, immutable evidence and ordinary archive safety still apply.
+
 - **Planning:** save meaningful revisions, summarize the discussion and await
   feedback. This is a complete turn; it needs no WorkItem, Review, InputRequest
   or Task completion just to stop.

package/skills/yui-leader/VERSION

@@ -1 +1 @@
-3
+5

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

@@ -56,7 +56,15 @@ and historical Runs/Sessions count even when no Session is currently busy.
 CLI commands: an authorized Operator can perform the mechanical operation.
 
 With that authorization, inspect any existing activation request before creating
-one with `task activation request <task-id> --request-id <id> --environment <plan>`.
+one with `task activation request <task-id> --request-id <id> --environment <plan>
+--source-message <message-id>`. If the new authorization arrived directly in
+the native conversation and has no saved Message, use `--source-text` with the
+exact user input instead. Core records this as caller-attributed source text in
+the immutable activation event, not a new Message or another delivery. Never
+substitute a Brief paraphrase, fabricate user authorship, or resend the input.
+Keep the same source and request ID on retries. Read the returned source event
+when diagnosing a mismatch. Update Brief with the new intent and source refs
+before ending the planning turn; do not rewrite old user messages.
 Choose the plan from the authorized resources; retain the request id for retries.
 The Controller adopts an eligible request. `task activate <task-id>` is the
 foreground adoption operation for an existing request, not a request-free shortcut.

package/skills/yui-reviewer/SKILL.md

@@ -57,6 +57,10 @@ own-inbox flow for current-ReviewRound clarification. Read complete originals,
 claim before handling, and ack after disposition. These messages supplement
 the frozen pack; they cannot replace its Candidate, expand review scope, or
 turn acknowledgement into a review verdict.
+Use Runtime's [temporal read contract](../yui-runtime/references/context-ordering.md)
+for stale summaries or delayed input. Current facts can explain a handoff but
+cannot silently replace the frozen candidate. Read original source relations
+before reporting a historical planning-stage restriction as a current conflict.
 
 Verify the exact AgentRun identity, Context Pack, frozen head, and ReviewRound-owned
 workspace before inspecting candidate sources. If context loading or workspace

package/skills/yui-reviewer/VERSION

@@ -1 +1 @@
-3
+4

package/skills/yui-runtime/SKILL.md

@@ -130,9 +130,10 @@ For every explicitly dispatched managed Task AgentRun:
    messages; use the expansion command above or the Leader's current Task Context.
    Reports remain evidence, not authority to enlarge the assignment.
 
-5. On a later wake, request only the declared delta after the last pack cursor.
-   If no cursor is available, reload the exact pack; do not reconstruct state
-   from transcript memory.
+5. On a later wake, refresh current Task facts separately from frozen Run refs.
+   Use a Run delta only against its exact declared Snapshot lineage; `deltaRefs`
+   is a hint, not a complete patch. If no baseline is available, reload the
+   exact pack; do not reconstruct state from transcript memory.
 
 Loading and verifying Context is the start of the work, not its result. Continue
 with the authorized assignment. In Draft, persist the discussed plan and wait
@@ -290,6 +291,11 @@ exactly-once execution.
 
 ## Read bounded information completely when required
 
+For apparent conflicts, stage handoffs or incremental maintenance, read
+[current intent and temporal reads](references/context-ordering.md).
+It distinguishes stage progression from independent constraints and explains
+source attribution, Brief guards, fixed delta windows and bounded recovery.
+
 Structured CLI results live in the top-level `data`, not a JSON-encoded
 `output` string. Task current Context includes bounded current facts and
 message references; it does not include event or terminal Run history.

package/skills/yui-runtime/VERSION

@@ -1 +1 @@
-6
+8

package/skills/yui-runtime/references/context-ordering.md

@@ -0,0 +1,103 @@
+# Current intent, provenance and temporal reads
+
+Use this when a handoff, changed requirement, stale summary or incremental read
+appears to conflict with earlier material. Core supplies facts and source
+relations; the Agent decides meaning within its existing authority.
+
+## Resolve the apparent conflict
+
+Read the current Task view first, then the relevant exact original sources:
+Task requirements, `phase.activation.source` event and its linked Message,
+current request, Brief, and the Session's actual authority. The `phase` and
+`caller` projections are observations, not permission granted by a summary.
+Do not fetch all history merely because the sources differ.
+
+Classify the difference before deciding:
+
+- **Stage progression:** an earlier “discuss only” limits that planning stage.
+  A later explicit request to start the same work, legally adopted Activation,
+  enabled gate and delivery-authorized Session establish the next stage.
+  Continue without asking for the same authorization again. The old words stay
+  in the audit trail; they are not a fresh stop.
+- **Same-scope replacement:** a later authoritative original can replace the
+  particular requirement it changes. Explain the scope of that replacement in
+  Brief; preserve unchanged requirements and the original references.
+- **Independent restriction:** “do not publish”, resource limits, material
+  exclusions and unrelated prohibitions remain unless explicitly changed by an
+  authorized source. Development authorization is not release authorization.
+- **Actual contradiction or missing evidence:** read the exact source and
+  current facts first. If the material ambiguity remains, request only the
+  missing user decision; do not fabricate provenance or resolve it by timestamp.
+
+Active lifecycle alone never authorizes implementation of a new analysis-only
+request. An old planning Session never promotes itself. Stop, archive,
+Assignment, workspace and grant boundaries remain independent checks.
+
+An activation event's `sourceText` is exact text supplied by the recorded
+caller; `leader-attested-native-input` explicitly identifies the Leader's
+capture, not a Provider-verified user message. Read it as attributed evidence
+together with the adopted request. `sourceMessageId` names the original shared
+Message; its body digest detects edits, while handling receipts do not change
+the source body. Missing/changed/unavailable provenance is visible and calls for
+an exact-source read, not an automatic prohibition or an automatic grant.
+Do not select whichever summary arrived last as the winning authority.
+
+`phaseRelation: recorded-before-activation-request` is recording order only.
+It does not declare every old requirement superseded. A delayed result or an
+acknowledged Message retains its original scope, source and version.
+`revised-after-activation-request` means an existing Message was edited after
+that boundary; its old ID must not hide the new revision.
+
+## Keep the shared working summary current
+
+Description owns the goal and durable boundaries; Brief owns the current
+semantic interpretation, progress, blockers, next action and original refs.
+Core owns lifecycle, gate, Activation, Session and operation facts. Do not
+manually mirror them into a competing state machine.
+
+At a changed requirement, phase handoff, resolved blocker, meaningful result or
+completion, reconcile affected Brief fields. Routine unchanged steps need no
+write. `phase.brief.refresh-needed` is a mechanical hint, not a semantic verdict
+or completion gate. Compare originals before editing.
+
+Read `task brief show <task>`; update with its `writeGuard` as
+`task brief update <task> --if-current <writeGuard> ...`. A new semantic event,
+Brief edit or changed Task boundary invalidates the guard even at the same
+timestamp. On rejection, reread current facts and reconcile only the intended
+fields; do not blindly copy an old summary under a newly read guard.
+An old Session still cannot write through this operation.
+
+## Maintain a baseline and incremental history
+
+For current Task facts, retain `coreCursor` from `task context <task>`.
+`task context delta <task> --after <coreCursor>` returns **event history**, not
+a replacement current view. Retain the same `--after` on every continuation;
+use `--continuation` until `complete: true`, then advance to `throughCursor`.
+The window's upper bound is fixed. Later arrivals belong to the next read.
+
+Deduplicate by source Home + Task + event ID, and process numeric event order
+within that stream. `createdAt` is occurrence/recording metadata, not a global
+causal clock; native acceptance, delivery and acknowledgement are separate
+facts. Never apply a late event's old payload over a newer current record.
+Re-read affected current refs with their digest when making a decision.
+An empty delta preserves the baseline; `stateChanged` can still require a
+current read because not every shared fact is a Task event.
+
+Cursors from another Home/Task, incompatible or invalid continuations, missing
+baselines and source changes require a fresh bounded current read. Do not join
+pages from different windows or versions. A failed original-detail digest
+requires rediscovery; a content page must be reassembled only with its own
+source digest. None of these reads consumes input or permits replay.
+
+Frozen Run context is a different stream. Keep its exact Snapshot and
+Assignment. `deltaRefs` is a launch hint, not a complete patch. The explicit
+Run delta reports complete changed `refs` and `removedRefs` against its named
+parent Snapshot, with large documents paginated. Apply removals only to that
+frozen inventory; an empty delta is a no-op. Mutable Task facts and current
+inbox clarifications must be refreshed separately within read scope; they
+never expand the frozen Assignment or change a Review candidate.
+
+Focused wakes use exact input refs, including delayed and same-timestamp
+inputs. Timestamp-window discovery is under `--history` (or a historical wake
+without refs), not new delivery authority. Original event and Message reads
+remain available without rewriting or replaying them.