@zq-silk/yui 2.8.1 → 2.9.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/dist/cli/commandCatalog.js +35 -12
- package/dist/cli/interactionPolicy.js +2 -2
- package/dist/commands/durableJobCommands.js +50 -0
- package/dist/commands/projectCommands.js +4 -33
- package/dist/commands/scheduleCommands.js +45 -0
- package/dist/commands/taskActivationCommands.js +19 -5
- package/dist/commands/taskCommands.js +2 -1
- package/dist/commands/taskFactCommands.js +24 -12
- package/dist/commands/taskPublicationCommands.js +6 -3
- package/dist/commands/taskPublicationVerifyCommand.js +74 -28
- package/dist/context/runContextPack.js +24 -4
- package/dist/context/taskContext.js +52 -15
- package/dist/context/taskPhase.js +99 -0
- package/dist/controlPlaneCli.js +6 -0
- package/dist/controller/controller.js +35 -0
- package/dist/controller/fileSchedulerStoreAdapter.js +16 -1
- package/dist/controller/jobControl.js +42 -12
- package/dist/controller/jobDefinitionControl.js +304 -0
- package/dist/controller/jobSupervisor.js +47 -32
- package/dist/controller/runtime.js +11 -2
- package/dist/controller/scheduleControl.js +176 -0
- package/dist/coordination/workMailbox.js +3 -3
- package/dist/external/githubPublicationVerifier.js +14 -5
- package/dist/external/gitlabPublicationVerifier.js +2 -1
- package/dist/interaction/notificationPresentation.js +3 -3
- package/dist/interaction/operatorPresentation.js +5 -0
- package/dist/job/builtinJob.js +58 -0
- package/dist/job/durableJob.js +72 -49
- package/dist/job/jobDefinition.js +68 -0
- package/dist/job/jobRunner.js +2 -1
- package/dist/job/projectRefreshRunner.js +48 -0
- package/dist/repository/projectRefresh.js +58 -0
- package/dist/repository/taskWorkspacePreparer.js +2 -1
- package/dist/schedule/schedule.js +108 -0
- package/dist/scheduler/operatorEvent.js +2 -0
- package/dist/scheduler/operatorInputNotificationProcessor.js +8 -0
- package/dist/storage/contextRecords.js +8 -0
- package/dist/storage/jobSchema.js +15 -0
- package/dist/storage/maintenanceCaller.js +1 -1
- package/dist/storage/recordValidation.js +5 -0
- package/dist/storage/scheduleSchema.js +12 -0
- package/dist/storage/sqliteSchema.js +74 -24
- package/dist/storage/sqliteStore.js +110 -9
- package/dist/storage/storageVersions.js +1 -1
- package/dist/storage/storeRpc.js +5 -0
- package/dist/storage/upgrade/jobDefinitionMigration.js +22 -0
- package/dist/task/publicationToolObservation.js +128 -0
- package/dist/task/taskActivationService.js +35 -0
- package/dist/web/assets/client/app/settings.js +7 -1
- package/dist/web/assets/client/i18n/en.js +61 -0
- package/dist/web/assets/client/i18n/zh-CN.js +61 -0
- package/dist/web/assets/client/index.js +2 -0
- package/dist/web/assets/client/views/jobs.js +222 -0
- package/dist/web/assets/client/views/task/page.js +11 -1
- package/dist/web/assets/shared/manageNav.js +1 -0
- package/dist/web/assets/shared/taskTabs.js +2 -2
- package/dist/web/assets/shell/settingsContent.js +3 -0
- package/dist/web/assets/styles/index.js +2 -0
- package/dist/web/assets/styles/views/jobs.js +19 -0
- package/dist/web/webJobs.js +52 -0
- package/dist/web/webServer.js +31 -0
- package/docs/cli-information-contract.md +43 -2
- package/docs/cli-information-contract.zh-CN.md +32 -1
- package/docs/job-runs.md +224 -0
- package/docs/release-workflow.md +43 -0
- package/docs/release-workflow.zh-CN.md +33 -0
- package/docs/schedules.md +132 -0
- package/docs/storage-baseline.md +18 -1
- package/docs/storage-baseline.zh-CN.md +15 -1
- package/docs/task-delivery.md +68 -2
- package/docs/task-delivery.zh-CN.md +33 -1
- package/docs/testing/verification-levels.md +6 -2
- package/docs/testing/verification-levels.zh-CN.md +6 -3
- package/package.json +4 -3
- package/skills/yui-leader/SKILL.md +18 -1
- package/skills/yui-leader/VERSION +1 -1
- package/skills/yui-leader/references/planning.md +9 -1
- package/skills/yui-reviewer/SKILL.md +4 -0
- package/skills/yui-reviewer/VERSION +1 -1
- package/skills/yui-runtime/SKILL.md +9 -3
- package/skills/yui-runtime/VERSION +1 -1
- package/skills/yui-runtime/references/context-ordering.md +103 -0
- package/skills/yui-runtime/references/publication.md +44 -4
- package/skills/yui-worker/SKILL.md +5 -0
- package/skills/yui-worker/VERSION +1 -1
package/docs/task-delivery.md
CHANGED
|
@@ -208,8 +208,10 @@ Task Integration produced that exact candidate, pass its local ID with
|
|
|
208
208
|
This records one Task event, not a new delivery status, Candidate lifecycle,
|
|
209
209
|
Git operation, or permission to change completed work.
|
|
210
210
|
|
|
211
|
-
`task publication verify`
|
|
212
|
-
|
|
211
|
+
`task publication verify` accepts tool-neutral evidence with `--observation
|
|
212
|
+
<json>`, or performs an explicit authorized provider read with the optional
|
|
213
|
+
gh/glab adapter when that option is absent. Neither tool is mandatory.
|
|
214
|
+
It records the remote source head, PR/MR state and merge commit independently of
|
|
213
215
|
Task acceptance. A mismatched head or non-merged state is saved as **reported**,
|
|
214
216
|
superseding earlier verification; provider errors or mismatched external identity
|
|
215
217
|
write nothing. A merged provider observation verifies only that Publication's
|
|
@@ -218,6 +220,70 @@ Metadata/verification successors preserve adoption only through an uninterrupted
|
|
|
218
220
|
same-candidate Publication lineage. Candidate or referenced Integration changes
|
|
219
221
|
cannot silently reuse the decision.
|
|
220
222
|
|
|
223
|
+
### Record a Leader's tool observation
|
|
224
|
+
|
|
225
|
+
First `publication upsert` the owning Task's exact candidate, PR/MR URL and
|
|
226
|
+
target branch. The Leader can inspect that object with any authorized CLI/API,
|
|
227
|
+
interpret its result, and submit the following JSON using
|
|
228
|
+
`task publication verify task-1/publication-1 --observation '<json>'`:
|
|
229
|
+
|
|
230
|
+
```json
|
|
231
|
+
{
|
|
232
|
+
"taskId": "task-1",
|
|
233
|
+
"publicationId": "publication-1",
|
|
234
|
+
"projectId": "project-1",
|
|
235
|
+
"provider": "gitlab",
|
|
236
|
+
"repository": "team/app",
|
|
237
|
+
"externalKind": "merge-request",
|
|
238
|
+
"externalId": "42",
|
|
239
|
+
"externalUrl": "https://forge.example/team/app/-/merge_requests/42",
|
|
240
|
+
"targetBranch": "main",
|
|
241
|
+
"localCommit": "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa",
|
|
242
|
+
"state": "merged",
|
|
243
|
+
"headCommit": "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa",
|
|
244
|
+
"remoteCommit": "bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb",
|
|
245
|
+
"observedAt": "2026-10-17T04:00:00.000Z",
|
|
246
|
+
"tool": "internal-cli",
|
|
247
|
+
"command": "internal-cli mr inspect team/app!42",
|
|
248
|
+
"output": "{\"iid\":42,\"state\":\"merged\",\"sha\":\"aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa\",\"merge_commit_sha\":\"bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb\"}"
|
|
249
|
+
}
|
|
250
|
+
```
|
|
251
|
+
|
|
252
|
+
Replace every example identity, SHA, timestamp and output with observed facts.
|
|
253
|
+
`provider` describes the forge (GitHub PR or GitLab MR), not the tool brand.
|
|
254
|
+
All fields shown are required for a merged observation; `remoteCommit` is optional
|
|
255
|
+
for open/closed, and `mergedAt` is optional. Output must be a nonempty, sanitized
|
|
256
|
+
relevant response excerpt, not credentials or just a conclusion; the whole JSON
|
|
257
|
+
is limited to 64 KiB. Yui never executes `command` or parses arbitrary output into
|
|
258
|
+
success. It trusts the authorized caller's inspection and checks exact identity,
|
|
259
|
+
URL/service, target, candidate and timestamps.
|
|
260
|
+
|
|
261
|
+
New evidence must refer to the current Publication, be no more than 24 hours
|
|
262
|
+
old and not future-dated. Observation may precede initial bookkeeping or a
|
|
263
|
+
title-only update. Immutable history supplies the lower time bound only when
|
|
264
|
+
the candidate, object, target or remote facts materially changed; changing and
|
|
265
|
+
restoring a candidate does not revive earlier evidence. After a title-only
|
|
266
|
+
update, bind the same actual result to the current record ID without re-querying.
|
|
267
|
+
An exact immediate retry returns the existing receipt without duplicating it;
|
|
268
|
+
later changes cannot replay it. The full canonical JSON is kept in the existing
|
|
269
|
+
opaque `evidence` text, with actor and record time on the immutable Publication.
|
|
270
|
+
There is no new persistent format or migration; historical records remain valid.
|
|
271
|
+
Once recorded, verification is a fixed observation, not live monitoring or a
|
|
272
|
+
24-hour archive lease. Known later changes require a successor; failures and
|
|
273
|
+
unknown results never assert a fresh success. URL/target/candidate changes reset
|
|
274
|
+
verification, while title-only changes can retain it.
|
|
275
|
+
GitHub repository URL comparison respects case-insensitive owner/name identity.
|
|
276
|
+
GitLab relative deployment paths are allowed, but the complete registered
|
|
277
|
+
service prefix must still match. Adapter observations retain the observed target
|
|
278
|
+
branch even when the earlier Publication did not specify one; missing targets
|
|
279
|
+
cannot establish new verification.
|
|
280
|
+
|
|
281
|
+
`upsert --verified` is now rejected: use this observation path or the optional
|
|
282
|
+
adapter. No natural-language summary or bare flag verifies a merge. Existing
|
|
283
|
+
verified records are not rewritten. Remote delivery and ordinary archive reuse
|
|
284
|
+
sufficient exact evidence without another gh/glab read; acceptance, business
|
|
285
|
+
settlement, stopped execution and safe resource cleanup remain independent.
|
|
286
|
+
|
|
221
287
|
CLI, current Leader Context and Web derive coverage from these same facts, with
|
|
222
288
|
no provider reads or evidence writes. They distinguish not delivered, merged
|
|
223
289
|
but uncovered, covering merge not verified, partial delivery and verified merge.
|
|
@@ -161,13 +161,45 @@ Review 时跳过刷新,该新鲜度字段为 null。重复完成不重新观
|
|
|
161
161
|
`--integration <id>`,一并绑定其已提交证据。这只新增一个 Task 事件,不新增交付
|
|
162
162
|
状态表、Candidate 生命周期或 Git 操作,也不授权修改已完成成果。
|
|
163
163
|
|
|
164
|
-
`task publication verify`
|
|
164
|
+
`task publication verify --observation '<json>'` 接受 Leader 通过任意获授权
|
|
165
|
+
CLI/API 得到的精确工具证据;省略此选项时才使用可选 gh/glab 适配器执行 provider
|
|
166
|
+
读取。不强制工具品牌,也不要求已充分核验的结果再用 gh/glab 重查。它独立于 Task
|
|
165
167
|
验收,记录远端 source head、PR/MR 状态和 merge commit。head 不匹配或尚未合并时,
|
|
166
168
|
保存为 **reported** 并取代旧验证;provider 错误或外部身份不匹配则不写任何证据。
|
|
167
169
|
已合并的 provider 观察仅验证该 Publication 的精确本地候选;squash 不需要伪造
|
|
168
170
|
提交祖先关系。元数据/验证更新只有沿连续同候选的 Publication 血缘才能继承采用;
|
|
169
171
|
候选或所引用的 Integration 变化,不能悄悄复用旧决定。
|
|
170
172
|
|
|
173
|
+
先用 `publication upsert` 登记本 Task 的精确候选、PR/MR URL(含服务地址)和
|
|
174
|
+
目标分支,再用工具检查该对象。观察 JSON 的完整示例见
|
|
175
|
+
[工具证据录入](task-delivery.md#record-a-leaders-tool-observation);
|
|
176
|
+
必需字段为 `taskId`、`publicationId`、`projectId`、`provider`、`repository`、
|
|
177
|
+
`externalKind`、`externalId`、`externalUrl`、`targetBranch`、`localCommit`、
|
|
178
|
+
`state`、`headCommit`、`observedAt`、`tool`、`command`、`output`。
|
|
179
|
+
合并状态还必须有 `remoteCommit`,`mergedAt` 可选。SHA 为完整小写值,时间为
|
|
180
|
+
ISO 时间戳。`provider` 表示 GitHub/GitLab 服务,不表示工具品牌。
|
|
181
|
+
`output` 保留经过脱敏的实际响应关键摘录,不是凭据或一句“已合并”结论;
|
|
182
|
+
完整 JSON 最大 64 KiB。Yui 不执行 `command`,不解析任意自然语言来判定成功。
|
|
183
|
+
Leader 负责实际检查和解释输出,Core 负责身份、服务 URL、目标、候选和时间绑定。
|
|
184
|
+
|
|
185
|
+
新证据必须引用当前不可变 Publication,距登记不超过 24 小时且不能在未来。
|
|
186
|
+
观察可以早于首次登记或仅标题更新;只有不可变历史中的候选、对象、目标或远程事实
|
|
187
|
+
发生实质变化,才构成观察时间下界。候选改变后又恢复,也不能复用变化前的证据。
|
|
188
|
+
仅标题更新时,将实际结果绑定到当前记录 ID,无需重新查询。
|
|
189
|
+
相同观察的直接重试复用原回执;之后发生变化
|
|
190
|
+
不能重放旧回执。完整规范化 JSON 保存在既有不透明 `evidence` 文本中,操作者和
|
|
191
|
+
登记时间由 Publication 保留;没有新增持久化格式,也不改写历史证据。
|
|
192
|
+
登记后的验证是固定观察,不是实时监控或 24 小时归档租约;已知后续变化须另记
|
|
193
|
+
后继事实。失败或未知结果不能变成新的验证成功。URL、目标分支、候选变化会失效
|
|
194
|
+
旧验证;仅标题变化可保留验证。
|
|
195
|
+
GitHub URL 按 owner/name 不区分大小写比较;GitLab 支持相对部署路径,但完整的
|
|
196
|
+
已登记服务前缀仍须匹配。适配器会持久化实际读到的目标分支,即使原记录未填写;
|
|
197
|
+
缺失目标分支不能建立新的验证。
|
|
198
|
+
|
|
199
|
+
`upsert --verified` 现在会被拒绝,请使用上述观察入口或可选适配器。
|
|
200
|
+
现存已验证历史保持可读。普通归档复用精确充分的证据,不重跑指定工具;
|
|
201
|
+
候选验收、业务结清、执行停止和安全清理检查不变。
|
|
202
|
+
|
|
171
203
|
CLI、当前 Leader Context 和 Web 从同一组事实推导覆盖,不联网、不写证据。展示
|
|
172
204
|
区分尚未交付、PR/MR 已合并但未覆盖、已覆盖合并但未验证、部分交付、已验证合并。
|
|
173
205
|
每个 Project 保留自己的验收 head、候选、采用引用和原因。缺失的历史 head 仍然
|
|
@@ -50,12 +50,12 @@ is required.
|
|
|
50
50
|
## Permanent core smoke
|
|
51
51
|
|
|
52
52
|
`npm test` and `npm run test:core` build the checkout and run the maintained suite.
|
|
53
|
-
The stable suite owns current storage 1.
|
|
53
|
+
The stable suite owns current storage 1.11 and its declared 1.0 through 1.10 minor
|
|
54
54
|
transition. It contains no undeclared historical format compatibility path.
|
|
55
55
|
|
|
56
56
|
Current coverage includes:
|
|
57
57
|
|
|
58
|
-
1. Fresh storage 1.
|
|
58
|
+
1. Fresh storage 1.11, exact schema/record validation, no initialization over
|
|
59
59
|
unknown data, and rejection of old integer formats without mutation.
|
|
60
60
|
2. Exact-version staging, mismatched-target refusal, same-major contiguous
|
|
61
61
|
minor preflight, explicit maintenance-owner identity across handover, and
|
|
@@ -75,6 +75,10 @@ Current coverage includes:
|
|
|
75
75
|
8. Failure isolation for optional Controller maintenance, individual retry
|
|
76
76
|
Sessions and Task continuation observation, with scoped errors and no
|
|
77
77
|
fabricated delivery, cancellation or quiescence.
|
|
78
|
+
9. Activation-source handoff without replay, Brief guards across same-timestamp
|
|
79
|
+
input, Home/baseline-bound fixed event windows, and complete frozen-ref deltas
|
|
80
|
+
with removals. These deterministic checks establish contracts, not a model's
|
|
81
|
+
semantic conflict judgment.
|
|
78
82
|
|
|
79
83
|
Keep the test phase seconds-scale and measure build separately. Use the
|
|
80
84
|
existing assembled-package smoke for actual CLI/Controller/Host/tmux wiring,
|
|
@@ -36,12 +36,12 @@ Yui 是一个单用户本地产品。永久验证保护关键的 happy path 和
|
|
|
36
36
|
## 永久 core smoke
|
|
37
37
|
|
|
38
38
|
`npm test` 和 `npm run test:core` 构建当前 checkout 并运行维护中的套件。
|
|
39
|
-
|
|
40
|
-
|
|
39
|
+
稳定套件维护当前存储 1.11 和明确声明的 1.0 至 1.10 连续小版本迁移,
|
|
40
|
+
不包含未声明的历史格式兼容路径。
|
|
41
41
|
|
|
42
42
|
当前覆盖包括:
|
|
43
43
|
|
|
44
|
-
1. 新建存储 1.
|
|
44
|
+
1. 新建存储 1.11、精确结构与记录校验、禁止覆盖未知数据库、无修改拒绝旧整数格式。
|
|
45
45
|
2. 精确版本暂存、目标不匹配拒绝、同主版本连续小版本预检、交接锁显式所有者,
|
|
46
46
|
以及恢复时核对捕获的协议和存储身份,不接受缺失字段。
|
|
47
47
|
3. 持久 Task/Message/Decision 上下文、Draft 激活权威、mailbox 认领、
|
|
@@ -54,6 +54,9 @@ Yui 是一个单用户本地产品。永久验证保护关键的 happy path 和
|
|
|
54
54
|
和备份行为。
|
|
55
55
|
8. Controller 可选维护、各个重试 Session、Task continuation 观察的失败隔离,
|
|
56
56
|
诊断包含所属对象,不伪造投递、取消或静默状态。
|
|
57
|
+
9. 无重放的激活来源交接、同时间戳新输入使 Brief 写入校验失效、绑定 Home 与基线的
|
|
58
|
+
固定事件窗口,以及含移除项的完整冻结引用增量。这些确定性测试验证契约,
|
|
59
|
+
不代表已验证真实模型的语义冲突判断效果。
|
|
57
60
|
|
|
58
61
|
测试阶段保持秒级,构建单独计时。真实 CLI/Controller/Host/tmux 接线复用现有
|
|
59
62
|
组装包冒烟,不新增守护进程矩阵;稳定套件不重建任何已退役的存储路径。
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@zq-silk/yui",
|
|
3
|
-
"version": "2.
|
|
3
|
+
"version": "2.9.0",
|
|
4
4
|
"description": "Local control plane for long-running native agent CLI sessions backed by tmux.",
|
|
5
5
|
"license": "MIT",
|
|
6
6
|
"private": false,
|
|
@@ -48,12 +48,13 @@
|
|
|
48
48
|
"dependencies": {
|
|
49
49
|
"@xterm/addon-fit": "^0.11.0",
|
|
50
50
|
"@xterm/xterm": "^6.0.0",
|
|
51
|
+
"cron-parser": "5.10.2",
|
|
51
52
|
"node-pty": "1.2.0-beta.15",
|
|
52
53
|
"smol-toml": "1.8.0",
|
|
53
54
|
"ws": "^8.21.1"
|
|
54
55
|
},
|
|
55
56
|
"optionalDependencies": {
|
|
56
|
-
"sqlite-
|
|
57
|
-
"sqlite-
|
|
57
|
+
"sqlite-compat": "npm:better-sqlite3@10.1.0",
|
|
58
|
+
"sqlite-modern": "npm:better-sqlite3@13.0.3"
|
|
58
59
|
}
|
|
59
60
|
}
|
|
@@ -42,6 +42,11 @@ transcript or process.
|
|
|
42
42
|
|
|
43
43
|
Apply terminal/gate and read-only intent boundaries before selecting delivery
|
|
44
44
|
or planning work; the routes below do not override those restrictions.
|
|
45
|
+
When old discussion text differs from new intent, apply
|
|
46
|
+
[current intent and temporal reads](../yui-runtime/references/context-ordering.md):
|
|
47
|
+
inspect exact sources before treating normal stage progression as a conflict.
|
|
48
|
+
An adopted same-scope development request supersedes the earlier discussion-only
|
|
49
|
+
stage, not independent restrictions. Never use active status or Brief alone.
|
|
45
50
|
|
|
46
51
|
- **Draft or planning-only authority:** read [Planning and activation handoff](references/planning.md).
|
|
47
52
|
Use the recorded submission intent (`record`, `discuss`, `develop`) and
|
|
@@ -100,7 +105,8 @@ then ack the exact entry. Inbox acknowledgement
|
|
|
100
105
|
never accepts a Candidate or completes the Task.
|
|
101
106
|
|
|
102
107
|
The DB Brief is the current summary, not a full plan or a history of messages.
|
|
103
|
-
After meaningful progress,
|
|
108
|
+
After meaningful progress, read `task brief show` and use
|
|
109
|
+
`task brief update --if-current <writeGuard>` with only intended fields;
|
|
104
110
|
read `task event list` before deliberately restoring an older value. Keep
|
|
105
111
|
references to substantial plans, prototypes and reports in that summary.
|
|
106
112
|
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;
|
|
|
111
117
|
do not copy it into Brief merely to create a second completion record. Brief
|
|
112
118
|
maintenance is not a new completion gate, and routine unchanged steps do not
|
|
113
119
|
need an update.
|
|
120
|
+
Also reconcile the summary at requirement changes and phase handoffs; carry the
|
|
121
|
+
exact activation/input references. Core projects current lifecycle and source
|
|
122
|
+
diagnostics without rewriting historical messages. A stale-guard rejection
|
|
123
|
+
requires reading the new input and reconciling, not retrying the old text.
|
|
114
124
|
Decisions contain the actual decision, reason and necessary boundaries, not
|
|
115
125
|
the entire proposal. Label recommendations as recommendations, not user
|
|
116
126
|
decisions.
|
|
@@ -132,6 +142,13 @@ heartbeat or unchanged wait. Ordinary fact edits need no self-wake.
|
|
|
132
142
|
|
|
133
143
|
## Close the current turn
|
|
134
144
|
|
|
145
|
+
For external delivery, choose any available authorized CLI/API and follow
|
|
146
|
+
[Publication evidence](../yui-runtime/references/publication.md). Record exact
|
|
147
|
+
tool observations through `publication verify --observation`; gh/glab are optional
|
|
148
|
+
adapters, not mandatory trusted brands. Do not repeat a sufficient exact
|
|
149
|
+
verification merely to use a different tool. Tool inspection is your judgment;
|
|
150
|
+
candidate acceptance, immutable evidence and ordinary archive safety still apply.
|
|
151
|
+
|
|
135
152
|
- **Planning:** save meaningful revisions, summarize the discussion and await
|
|
136
153
|
feedback. This is a complete turn; it needs no WorkItem, Review, InputRequest
|
|
137
154
|
or Task completion just to stop.
|
|
@@ -1 +1 @@
|
|
|
1
|
-
|
|
1
|
+
5
|
|
@@ -56,7 +56,15 @@ and historical Runs/Sessions count even when no Session is currently busy.
|
|
|
56
56
|
CLI commands: an authorized Operator can perform the mechanical operation.
|
|
57
57
|
|
|
58
58
|
With that authorization, inspect any existing activation request before creating
|
|
59
|
-
one with `task activation request <task-id> --request-id <id> --environment <plan
|
|
59
|
+
one with `task activation request <task-id> --request-id <id> --environment <plan>
|
|
60
|
+
--source-message <message-id>`. If the new authorization arrived directly in
|
|
61
|
+
the native conversation and has no saved Message, use `--source-text` with the
|
|
62
|
+
exact user input instead. Core records this as caller-attributed source text in
|
|
63
|
+
the immutable activation event, not a new Message or another delivery. Never
|
|
64
|
+
substitute a Brief paraphrase, fabricate user authorship, or resend the input.
|
|
65
|
+
Keep the same source and request ID on retries. Read the returned source event
|
|
66
|
+
when diagnosing a mismatch. Update Brief with the new intent and source refs
|
|
67
|
+
before ending the planning turn; do not rewrite old user messages.
|
|
60
68
|
Choose the plan from the authorized resources; retain the request id for retries.
|
|
61
69
|
The Controller adopts an eligible request. `task activate <task-id>` is the
|
|
62
70
|
foreground adoption operation for an existing request, not a request-free shortcut.
|
|
@@ -57,6 +57,10 @@ own-inbox flow for current-ReviewRound clarification. Read complete originals,
|
|
|
57
57
|
claim before handling, and ack after disposition. These messages supplement
|
|
58
58
|
the frozen pack; they cannot replace its Candidate, expand review scope, or
|
|
59
59
|
turn acknowledgement into a review verdict.
|
|
60
|
+
Use Runtime's [temporal read contract](../yui-runtime/references/context-ordering.md)
|
|
61
|
+
for stale summaries or delayed input. Current facts can explain a handoff but
|
|
62
|
+
cannot silently replace the frozen candidate. Read original source relations
|
|
63
|
+
before reporting a historical planning-stage restriction as a current conflict.
|
|
60
64
|
|
|
61
65
|
Verify the exact AgentRun identity, Context Pack, frozen head, and ReviewRound-owned
|
|
62
66
|
workspace before inspecting candidate sources. If context loading or workspace
|
|
@@ -1 +1 @@
|
|
|
1
|
-
|
|
1
|
+
4
|
|
@@ -130,9 +130,10 @@ For every explicitly dispatched managed Task AgentRun:
|
|
|
130
130
|
messages; use the expansion command above or the Leader's current Task Context.
|
|
131
131
|
Reports remain evidence, not authority to enlarge the assignment.
|
|
132
132
|
|
|
133
|
-
5. On a later wake,
|
|
134
|
-
|
|
135
|
-
|
|
133
|
+
5. On a later wake, refresh current Task facts separately from frozen Run refs.
|
|
134
|
+
Use a Run delta only against its exact declared Snapshot lineage; `deltaRefs`
|
|
135
|
+
is a hint, not a complete patch. If no baseline is available, reload the
|
|
136
|
+
exact pack; do not reconstruct state from transcript memory.
|
|
136
137
|
|
|
137
138
|
Loading and verifying Context is the start of the work, not its result. Continue
|
|
138
139
|
with the authorized assignment. In Draft, persist the discussed plan and wait
|
|
@@ -290,6 +291,11 @@ exactly-once execution.
|
|
|
290
291
|
|
|
291
292
|
## Read bounded information completely when required
|
|
292
293
|
|
|
294
|
+
For apparent conflicts, stage handoffs or incremental maintenance, read
|
|
295
|
+
[current intent and temporal reads](references/context-ordering.md).
|
|
296
|
+
It distinguishes stage progression from independent constraints and explains
|
|
297
|
+
source attribution, Brief guards, fixed delta windows and bounded recovery.
|
|
298
|
+
|
|
293
299
|
Structured CLI results live in the top-level `data`, not a JSON-encoded
|
|
294
300
|
`output` string. Task current Context includes bounded current facts and
|
|
295
301
|
message references; it does not include event or terminal Run history.
|
|
@@ -1 +1 @@
|
|
|
1
|
-
|
|
1
|
+
8
|
|
@@ -0,0 +1,103 @@
|
|
|
1
|
+
# Current intent, provenance and temporal reads
|
|
2
|
+
|
|
3
|
+
Use this when a handoff, changed requirement, stale summary or incremental read
|
|
4
|
+
appears to conflict with earlier material. Core supplies facts and source
|
|
5
|
+
relations; the Agent decides meaning within its existing authority.
|
|
6
|
+
|
|
7
|
+
## Resolve the apparent conflict
|
|
8
|
+
|
|
9
|
+
Read the current Task view first, then the relevant exact original sources:
|
|
10
|
+
Task requirements, `phase.activation.source` event and its linked Message,
|
|
11
|
+
current request, Brief, and the Session's actual authority. The `phase` and
|
|
12
|
+
`caller` projections are observations, not permission granted by a summary.
|
|
13
|
+
Do not fetch all history merely because the sources differ.
|
|
14
|
+
|
|
15
|
+
Classify the difference before deciding:
|
|
16
|
+
|
|
17
|
+
- **Stage progression:** an earlier “discuss only” limits that planning stage.
|
|
18
|
+
A later explicit request to start the same work, legally adopted Activation,
|
|
19
|
+
enabled gate and delivery-authorized Session establish the next stage.
|
|
20
|
+
Continue without asking for the same authorization again. The old words stay
|
|
21
|
+
in the audit trail; they are not a fresh stop.
|
|
22
|
+
- **Same-scope replacement:** a later authoritative original can replace the
|
|
23
|
+
particular requirement it changes. Explain the scope of that replacement in
|
|
24
|
+
Brief; preserve unchanged requirements and the original references.
|
|
25
|
+
- **Independent restriction:** “do not publish”, resource limits, material
|
|
26
|
+
exclusions and unrelated prohibitions remain unless explicitly changed by an
|
|
27
|
+
authorized source. Development authorization is not release authorization.
|
|
28
|
+
- **Actual contradiction or missing evidence:** read the exact source and
|
|
29
|
+
current facts first. If the material ambiguity remains, request only the
|
|
30
|
+
missing user decision; do not fabricate provenance or resolve it by timestamp.
|
|
31
|
+
|
|
32
|
+
Active lifecycle alone never authorizes implementation of a new analysis-only
|
|
33
|
+
request. An old planning Session never promotes itself. Stop, archive,
|
|
34
|
+
Assignment, workspace and grant boundaries remain independent checks.
|
|
35
|
+
|
|
36
|
+
An activation event's `sourceText` is exact text supplied by the recorded
|
|
37
|
+
caller; `leader-attested-native-input` explicitly identifies the Leader's
|
|
38
|
+
capture, not a Provider-verified user message. Read it as attributed evidence
|
|
39
|
+
together with the adopted request. `sourceMessageId` names the original shared
|
|
40
|
+
Message; its body digest detects edits, while handling receipts do not change
|
|
41
|
+
the source body. Missing/changed/unavailable provenance is visible and calls for
|
|
42
|
+
an exact-source read, not an automatic prohibition or an automatic grant.
|
|
43
|
+
Do not select whichever summary arrived last as the winning authority.
|
|
44
|
+
|
|
45
|
+
`phaseRelation: recorded-before-activation-request` is recording order only.
|
|
46
|
+
It does not declare every old requirement superseded. A delayed result or an
|
|
47
|
+
acknowledged Message retains its original scope, source and version.
|
|
48
|
+
`revised-after-activation-request` means an existing Message was edited after
|
|
49
|
+
that boundary; its old ID must not hide the new revision.
|
|
50
|
+
|
|
51
|
+
## Keep the shared working summary current
|
|
52
|
+
|
|
53
|
+
Description owns the goal and durable boundaries; Brief owns the current
|
|
54
|
+
semantic interpretation, progress, blockers, next action and original refs.
|
|
55
|
+
Core owns lifecycle, gate, Activation, Session and operation facts. Do not
|
|
56
|
+
manually mirror them into a competing state machine.
|
|
57
|
+
|
|
58
|
+
At a changed requirement, phase handoff, resolved blocker, meaningful result or
|
|
59
|
+
completion, reconcile affected Brief fields. Routine unchanged steps need no
|
|
60
|
+
write. `phase.brief.refresh-needed` is a mechanical hint, not a semantic verdict
|
|
61
|
+
or completion gate. Compare originals before editing.
|
|
62
|
+
|
|
63
|
+
Read `task brief show <task>`; update with its `writeGuard` as
|
|
64
|
+
`task brief update <task> --if-current <writeGuard> ...`. A new semantic event,
|
|
65
|
+
Brief edit or changed Task boundary invalidates the guard even at the same
|
|
66
|
+
timestamp. On rejection, reread current facts and reconcile only the intended
|
|
67
|
+
fields; do not blindly copy an old summary under a newly read guard.
|
|
68
|
+
An old Session still cannot write through this operation.
|
|
69
|
+
|
|
70
|
+
## Maintain a baseline and incremental history
|
|
71
|
+
|
|
72
|
+
For current Task facts, retain `coreCursor` from `task context <task>`.
|
|
73
|
+
`task context delta <task> --after <coreCursor>` returns **event history**, not
|
|
74
|
+
a replacement current view. Retain the same `--after` on every continuation;
|
|
75
|
+
use `--continuation` until `complete: true`, then advance to `throughCursor`.
|
|
76
|
+
The window's upper bound is fixed. Later arrivals belong to the next read.
|
|
77
|
+
|
|
78
|
+
Deduplicate by source Home + Task + event ID, and process numeric event order
|
|
79
|
+
within that stream. `createdAt` is occurrence/recording metadata, not a global
|
|
80
|
+
causal clock; native acceptance, delivery and acknowledgement are separate
|
|
81
|
+
facts. Never apply a late event's old payload over a newer current record.
|
|
82
|
+
Re-read affected current refs with their digest when making a decision.
|
|
83
|
+
An empty delta preserves the baseline; `stateChanged` can still require a
|
|
84
|
+
current read because not every shared fact is a Task event.
|
|
85
|
+
|
|
86
|
+
Cursors from another Home/Task, incompatible or invalid continuations, missing
|
|
87
|
+
baselines and source changes require a fresh bounded current read. Do not join
|
|
88
|
+
pages from different windows or versions. A failed original-detail digest
|
|
89
|
+
requires rediscovery; a content page must be reassembled only with its own
|
|
90
|
+
source digest. None of these reads consumes input or permits replay.
|
|
91
|
+
|
|
92
|
+
Frozen Run context is a different stream. Keep its exact Snapshot and
|
|
93
|
+
Assignment. `deltaRefs` is a launch hint, not a complete patch. The explicit
|
|
94
|
+
Run delta reports complete changed `refs` and `removedRefs` against its named
|
|
95
|
+
parent Snapshot, with large documents paginated. Apply removals only to that
|
|
96
|
+
frozen inventory; an empty delta is a no-op. Mutable Task facts and current
|
|
97
|
+
inbox clarifications must be refreshed separately within read scope; they
|
|
98
|
+
never expand the frozen Assignment or change a Review candidate.
|
|
99
|
+
|
|
100
|
+
Focused wakes use exact input refs, including delayed and same-timestamp
|
|
101
|
+
inputs. Timestamp-window discovery is under `--history` (or a historical wake
|
|
102
|
+
without refs), not new delivery authority. Original event and Message reads
|
|
103
|
+
remain available without rewriting or replaying them.
|
|
@@ -67,9 +67,49 @@ whose result is delivered; do not duplicate the same PR/MR across Tasks to
|
|
|
67
67
|
substitute for missing ownership or acceptance evidence.
|
|
68
68
|
|
|
69
69
|
Track PR/MR identity, state, commits, URL, merge time and evidence, not CI or
|
|
70
|
-
deployment status.
|
|
71
|
-
|
|
72
|
-
|
|
70
|
+
deployment status. Verification is tool-neutral: the Leader may use any available
|
|
71
|
+
CLI or API within the existing external-read authority. No particular brand,
|
|
72
|
+
installation or second gh/glab query is required. A summary saying "merged" is
|
|
73
|
+
reported evidence, not a tool observation; `upsert --verified` is refused.
|
|
74
|
+
|
|
75
|
+
First record the exact local candidate, PR/MR URL (including its service host)
|
|
76
|
+
and target branch. Inspect that object with an authorized tool, checking the
|
|
77
|
+
repository, PR/MR identity, target branch, remote source head and integrated
|
|
78
|
+
commit against the actual output. Then use
|
|
79
|
+
`task publication verify <task>/<publication> --observation '<json>'`.
|
|
80
|
+
The JSON fields are `taskId`, `publicationId`, `projectId`, `provider`,
|
|
81
|
+
`repository`, `externalKind`, `externalId`, `externalUrl`, `targetBranch`,
|
|
82
|
+
`localCommit`, `state`, `headCommit`, `remoteCommit` (required for merged),
|
|
83
|
+
`observedAt`, `tool`, `command`, `output`, and optionally `mergedAt`.
|
|
84
|
+
Use full lowercase SHAs and ISO timestamps; `output` is a sanitized relevant
|
|
85
|
+
tool-response excerpt, not an unsupported conclusion or credentials. `command`
|
|
86
|
+
describes the exact CLI query or API request; Yui does not execute it.
|
|
87
|
+
Read the original output and resolve ambiguous/conflicting results before
|
|
88
|
+
asserting a known state. Do not fabricate evidence or normalize failure into merge.
|
|
89
|
+
|
|
90
|
+
The observation must name the current immutable Publication, match its candidate,
|
|
91
|
+
URL and target, and be recorded within 24 hours without future dating. The tool
|
|
92
|
+
read may precede the first upsert or a title-only update: these are bookkeeping,
|
|
93
|
+
not changes to the observed object. Observations must not predate the latest
|
|
94
|
+
material change in the immutable lineage (candidate, object, target or remote
|
|
95
|
+
facts), including a changed-then-restored candidate. When only bookkeeping has
|
|
96
|
+
changed, read the current record and bind the same actual result to its current
|
|
97
|
+
ID; do not repeat the external query just for that update.
|
|
98
|
+
Identical immediate retries reuse the saved receipt.
|
|
99
|
+
Later candidate/URL/target changes invalidate verification; use fresh evidence,
|
|
100
|
+
not an old JSON edited to look current. Inspect `publication show` after an
|
|
101
|
+
uncertain save before retrying. Original records and their full evidence remain.
|
|
102
|
+
These are caller-attested tool facts: Core checks exact binding and freshness,
|
|
103
|
+
not the semantic truth of arbitrary output. It trusts the authorized Leader's
|
|
104
|
+
inspection, not the executable's brand.
|
|
105
|
+
|
|
106
|
+
Without `--observation`, `verify` uses the optional gh/glab adapter and performs
|
|
107
|
+
an external read, requiring that read's existing authority. Missing adapters
|
|
108
|
+
are not missing user authorization when another authorized tool is available.
|
|
109
|
+
If no usable evidence or authorized read exists, retain reported evidence and
|
|
110
|
+
state that specific gap. A recorded verification is fixed evidence, not live
|
|
111
|
+
monitoring; no clock-based re-query is required just to archive it. Known later
|
|
112
|
+
changes must be recorded as successors before relying on delivery.
|
|
73
113
|
|
|
74
114
|
Preserve each completion head as that acceptance's evidence. After an authorized
|
|
75
115
|
reopen, finish the new work and record its own completion; retain the earlier
|
|
@@ -88,7 +128,7 @@ rewrite completion, or mark a merge verified to bridge an evidence gap.
|
|
|
88
128
|
|
|
89
129
|
Adoption records a fixed decision, not remote verification or publication
|
|
90
130
|
authority. The verify operation observes the exact Publication candidate through
|
|
91
|
-
|
|
131
|
+
an authorized tool or the optional adapter and records contrary head/state facts as reported successors,
|
|
92
132
|
invalidating previous verification. Metadata and verification updates may retain
|
|
93
133
|
adoption while the candidate is unchanged; a changed candidate needs a new
|
|
94
134
|
decision. Archived history is read-only to these adopt/verify operations.
|
|
@@ -29,6 +29,11 @@ final report. Current-Assignment `inbox show` is an authorized way to read new
|
|
|
29
29
|
directed clarification during this turn without redispatch. Claim before
|
|
30
30
|
handling and ack only after disposition; never use it to read another
|
|
31
31
|
Assignment, expand Project permissions, or accept your own result.
|
|
32
|
+
For delayed or conflicting material, follow Runtime's
|
|
33
|
+
[temporal read contract](../yui-runtime/references/context-ordering.md).
|
|
34
|
+
Refresh relevant current originals without replacing the frozen Assignment.
|
|
35
|
+
Report genuine scope conflicts to Leader; older stage-only wording is not a
|
|
36
|
+
new prohibition after a legally authorized handoff.
|
|
32
37
|
|
|
33
38
|
Leader clarification and continuation arrive as Messages in the exact bounded
|
|
34
39
|
Context Pack. Read those authorized refs; do not request pack-external Leader
|
|
@@ -1 +1 @@
|
|
|
1
|
-
|
|
1
|
+
3
|