@zq-silk/yui 2.6.0 → 2.7.1
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/README.md +23 -0
- package/dist/cli/commandCatalog.js +28 -2
- package/dist/commands/globalRoleCommands.js +22 -2
- package/dist/commands/inboxCommands.js +352 -0
- package/dist/commands/roleSkillValidation.js +2 -0
- package/dist/commands/taskCommands.js +32 -4
- package/dist/context/currentSkills.js +48 -0
- package/dist/context/roleSessionContext.js +13 -16
- package/dist/context/runContextPack.js +2 -0
- package/dist/context/runInputContract.js +1 -1
- package/dist/context/sessionBootstrapManifest.js +27 -4
- package/dist/context/skillCatalog.js +2 -3
- package/dist/context/taskContext.js +2 -0
- package/dist/controlPlaneCli.js +18 -1
- package/dist/controller/controller.js +3 -2
- package/dist/controller/fileSchedulerStoreAdapter.js +19 -4
- package/dist/controller/globalInputDelivery.js +73 -15
- package/dist/controller/globalRuntimeAttention.js +1 -1
- package/dist/controller/operatorNotification.js +6 -1
- package/dist/controller/providerRetryDelivery.js +3 -5
- package/dist/controller/runtime.js +2 -2
- package/dist/doctor/doctor.js +25 -2
- package/dist/executor/effectiveLaunch.js +2 -2
- package/dist/executor/fileRoleLaunchPlanner.js +4 -6
- package/dist/interaction/notificationPresentation.js +2 -2
- package/dist/interaction/operatorPresentation.js +1 -1
- package/dist/message/globalInputBacklog.js +69 -0
- package/dist/message/globalMessageQuery.js +1 -0
- package/dist/message/inboxReceipt.js +32 -0
- package/dist/message/message.js +6 -1
- package/dist/message/messageContinuation.js +34 -13
- package/dist/message/taskInboxOwnership.js +21 -0
- package/dist/nativeAgent/session/backends.js +1 -1
- package/dist/observability/runtimeIdentity.js +1 -1
- package/dist/resources/sqliteResourceRegistry.js +1 -1
- package/dist/runtime/agentHost.js +105 -16
- package/dist/scheduler/operatorEvent.js +49 -0
- package/dist/scheduler/operatorInputNotificationProcessor.js +5 -4
- package/dist/scheduler/taskWake.js +5 -0
- package/dist/sqlite/driver.js +108 -0
- package/dist/storage/sqliteSchema.js +11 -1
- package/dist/storage/sqliteStore.js +60 -1
- package/dist/storage/storageSchema.js +1 -1
- package/dist/storage/storageVersions.js +1 -1
- package/dist/storage/storeRpc.js +1 -0
- package/dist/storage/upgrade/upgradeOrchestrator.js +1 -1
- package/dist/task/completionReadiness.js +11 -4
- package/dist/telemetry/sqliteTelemetryStore.js +1 -1
- package/docs/managed-turn-and-session-runtime.md +81 -5
- package/docs/managed-turn-and-session-runtime.zh-CN.md +51 -3
- package/docs/release-workflow.md +47 -2
- package/docs/release-workflow.zh-CN.md +34 -1
- package/docs/storage-baseline.md +17 -7
- package/docs/storage-baseline.zh-CN.md +11 -5
- package/docs/task-delivery.md +17 -8
- package/docs/task-delivery.zh-CN.md +11 -5
- package/docs/testing/verification-levels.md +22 -4
- package/docs/testing/verification-levels.zh-CN.md +8 -1
- package/i18n/README.zh-CN.md +19 -0
- package/package.json +5 -2
- package/skills/yui-leader/SKILL.md +28 -11
- package/skills/yui-leader/VERSION +1 -0
- package/skills/yui-operator/SKILL.md +10 -2
- package/skills/yui-operator/VERSION +1 -0
- package/skills/yui-operator/references/task-delivery.md +2 -0
- package/skills/yui-reviewer/SKILL.md +8 -1
- package/skills/yui-reviewer/VERSION +1 -0
- package/skills/yui-runtime/SKILL.md +94 -11
- package/skills/yui-runtime/VERSION +1 -0
- package/skills/yui-runtime/references/publication.md +16 -5
- package/skills/yui-worker/SKILL.md +8 -1
- package/skills/yui-worker/VERSION +1 -0
|
@@ -16,16 +16,34 @@ workspace layout, native transcript, or an earlier AgentRun.
|
|
|
16
16
|
|
|
17
17
|
## Enter through the current context
|
|
18
18
|
|
|
19
|
-
Stable instructions and dynamic facts have different lifetimes.
|
|
20
|
-
|
|
21
|
-
|
|
22
|
-
|
|
23
|
-
|
|
24
|
-
|
|
25
|
-
|
|
26
|
-
|
|
27
|
-
|
|
28
|
-
|
|
19
|
+
Stable instructions and dynamic facts have different lifetimes. At the start of
|
|
20
|
+
**every turn**, run the Manifest's `contextProtocol.skillCheckCommand`.
|
|
21
|
+
For an older Manifest, use `yui session skills --json` through the Session's
|
|
22
|
+
CLI/Home; a Global Manifest's self-contained `loadCommand` also checks current
|
|
23
|
+
Skills and works without the launching shell's environment (for example Desktop).
|
|
24
|
+
This lightweight read checks the applicable Skills' current stable paths,
|
|
25
|
+
internal `VERSION` files and readability without loading their bodies. Its
|
|
26
|
+
current paths supersede frozen-package paths in an older Session Manifest.
|
|
27
|
+
Skill versions are independent of npm versions, Session revisions and Task
|
|
28
|
+
Snapshots. A version observation is never evidence that instructions were read.
|
|
29
|
+
|
|
30
|
+
On first entry, version change, new/restored Session, Host recovery, or missing,
|
|
31
|
+
compacted or uncertain instructions, read the exact Session Manifest's profile
|
|
32
|
+
and fully load the current `yui-runtime` plus the applicable Role/custom Skills
|
|
33
|
+
from the check result, including necessary references. If their versions are
|
|
34
|
+
unchanged **and** their full instructions are still available in current context,
|
|
35
|
+
reuse them without rereading all bodies. Do not infer availability from the same
|
|
36
|
+
Session, an earlier read, successful delivery or an unchanged version. Native
|
|
37
|
+
children without their own managed identity use their parent's checked paths
|
|
38
|
+
and inherited scope, never impersonate its Session.
|
|
39
|
+
|
|
40
|
+
Historical frozen packages remain audit evidence only. Missing or damaged
|
|
41
|
+
historical Skill evidence alone does not revoke a valid Session or block its
|
|
42
|
+
messages, and current source cannot prove a historical load. A missing/unreadable
|
|
43
|
+
current entry or version is a concrete installation/configuration error: report
|
|
44
|
+
the path and legal recovery action, preserve input and authority, and check again
|
|
45
|
+
after repair. Never clear identity, change Session or replay unknown input as a
|
|
46
|
+
Skill-loading workaround. CLI/Home protocol and storage checks still apply.
|
|
29
47
|
|
|
30
48
|
Refresh dynamic Task/Session facts before the relevant decision regardless of
|
|
31
49
|
instruction reuse. Leader notifications use the Manifest's `currentCommand`;
|
|
@@ -41,7 +59,12 @@ or reuse an old completed AgentRun snapshot merely to obtain authority. Pending
|
|
|
41
59
|
delivery, unknown execution evidence and missing reports do not themselves
|
|
42
60
|
revoke Session authority. Task lifecycle, scope, Assignment, workspace and
|
|
43
61
|
resource boundaries still apply; a planning Session does not gain delivery
|
|
44
|
-
authority merely because the Task becomes active.
|
|
62
|
+
authority merely because the Task becomes active. An explicit, legal same-result
|
|
63
|
+
implementation or delivery follow-up may instead authorize the current Leader
|
|
64
|
+
to reopen its own completed, unarchived Task; follow the
|
|
65
|
+
[post-completion routing boundary](references/publication.md#post-completion-routing-boundary).
|
|
66
|
+
Queries, discussion, ordinary notifications and Session recovery grant no such
|
|
67
|
+
authority, and reopening never lifts an independent execution stop.
|
|
45
68
|
Use the runtime-provided `TMPDIR` for temporary context or diagnostic files,
|
|
46
69
|
not fixed shared `/tmp` names or the logical multi-Project workspace container.
|
|
47
70
|
Save durable reports in Task artifacts/results before releasing their temporary
|
|
@@ -165,6 +188,66 @@ then handoff. An accepted or unconfirmed steer must not be submitted again by
|
|
|
165
188
|
changing its request id or composing then. A conclusive rejection permits an
|
|
166
189
|
explicit new control attempt; uncertainty does not.
|
|
167
190
|
|
|
191
|
+
## Handle your own inbox in the current turn
|
|
192
|
+
|
|
193
|
+
After loading authorized context, at useful work boundaries and before handing
|
|
194
|
+
off, use `yui inbox list --json` to discover pending input addressed to your
|
|
195
|
+
current managed identity. This applies to Operator, custom GlobalRole, Leader,
|
|
196
|
+
Worker and Reviewer. Do not poll an empty inbox or create another model turn.
|
|
197
|
+
No target Role, Task or native Session is supplied: Yui resolves your current
|
|
198
|
+
identity. A native child gains no separate actor or inbox.
|
|
199
|
+
|
|
200
|
+
1. Read the selected `yui inbox show <entry> --json`. Reads never consume input.
|
|
201
|
+
Follow `nextCursor` and all `contentPage` pages using the rules below.
|
|
202
|
+
2. Before processing, reserve exact entries with
|
|
203
|
+
`yui inbox claim <entry> [<entry> ...] --request-id <stable-id> --json`.
|
|
204
|
+
At most 16 entries are allowed, with independent per-entry results. Retain
|
|
205
|
+
each successful returned ID and request ID; do not replay successful items
|
|
206
|
+
when another item fails. A changed pending window requires a fresh list.
|
|
207
|
+
3. Read complete originals and referenced results, then handle the request
|
|
208
|
+
within its existing authority. Leader notification-window claims move one exact pending window
|
|
209
|
+
into a durable wake: use the returned `originals` command, follow every
|
|
210
|
+
relevant original Message/Run reference, and use its returned wake ID for
|
|
211
|
+
acknowledgement. Later arrivals remain in the next pending window.
|
|
212
|
+
Assignment inbox reads (including a managed Leader Assignment) expose only
|
|
213
|
+
messages for the current Assignment;
|
|
214
|
+
they supplement the frozen pack without expanding it or changing candidates.
|
|
215
|
+
4. Only after handling, explicitly acknowledge each successful item:
|
|
216
|
+
`yui inbox ack <returned-entry> --request-id <stable-id> --reason "<disposition>" --json`.
|
|
217
|
+
Record an obsolete notification as requiring no further action only after
|
|
218
|
+
checking its originals and current facts, never based solely on age.
|
|
219
|
+
|
|
220
|
+
Claiming prevents ordinary automatic delivery; it is not processing completion.
|
|
221
|
+
Acknowledgement records Agent handling, not Host acceptance, result acceptance,
|
|
222
|
+
Task completion, publication or archive. Never acknowledge merely to empty the
|
|
223
|
+
list. On failure or interruption, leave the claim unacknowledged; it remains
|
|
224
|
+
discoverable and does not expire or replay automatically. A current rightful
|
|
225
|
+
successor must inspect original input and prior effects before finishing and
|
|
226
|
+
acknowledging a retained claim. Never replay uncertain external actions.
|
|
227
|
+
For an exact-Session input already claimed by its selected Session, a rightful
|
|
228
|
+
successor may explicitly settle that handling after inspecting the original
|
|
229
|
+
and prior effects. This preserves the original target and claim; it grants no
|
|
230
|
+
permission to submit or execute the input in a different Session.
|
|
231
|
+
An Assignment change does not inherit handling authority. If the original Run
|
|
232
|
+
stopped before acknowledgement, ask the Leader to inspect its exact native
|
|
233
|
+
terminal and use the existing `task message handoff` to the current authorized
|
|
234
|
+
Assignment. The original claim remains; handoff never resubmits it automatically.
|
|
235
|
+
If that Assignment is obsolete, the Leader may inspect the original and prior
|
|
236
|
+
effects, then explicitly use `task message retire <task/message> --reason "<disposition>"`.
|
|
237
|
+
Retirement preserves the original claim and records the management decision;
|
|
238
|
+
it neither fabricates an acknowledgement nor proves native execution stopped.
|
|
239
|
+
An unfinished claim fences its Assignment, not unrelated work of the same Role.
|
|
240
|
+
|
|
241
|
+
In-flight, unknown, previously delivered, explicit interrupt-then and
|
|
242
|
+
unsettled steer inputs retain their existing owner/receipt and report a bounded
|
|
243
|
+
reason instead of being taken over. Use existing exact-receipt recovery when
|
|
244
|
+
needed; do not change request IDs, clear identity, or copy input to bypass it.
|
|
245
|
+
A steer with no control receipt was not submitted; it may be explicitly handled
|
|
246
|
+
and acknowledged in its authorized inbox, without converting it into a queue.
|
|
247
|
+
An accepted notification still follows its normal handling path, not another
|
|
248
|
+
inbox delivery. Original Messages, wake windows and handling receipts remain
|
|
249
|
+
readable after acknowledgement.
|
|
250
|
+
|
|
168
251
|
## Read bounded information completely when required
|
|
169
252
|
|
|
170
253
|
Structured CLI results live in the top-level `data`, not a JSON-encoded
|
|
@@ -0,0 +1 @@
|
|
|
1
|
+
3
|
|
@@ -8,9 +8,19 @@ to push, publish, merge, query an external provider or archive.
|
|
|
8
8
|
|
|
9
9
|
An explicit user request to continue implementation or delivery of the same
|
|
10
10
|
completed, unarchived result authorizes its necessary reopening within that
|
|
11
|
-
request's scope. The
|
|
12
|
-
|
|
13
|
-
|
|
11
|
+
request's scope. The current matching Leader may call `task reopen <task>` for
|
|
12
|
+
its own Task and continue that request; an Operator handoff is not mandatory,
|
|
13
|
+
and neither Role needs the user to additionally say “reopen.” Read the original
|
|
14
|
+
completion, fixed heads/reports, Publication, new request and current authority
|
|
15
|
+
first. Inspect the reopen result and current Context before executing; delivery
|
|
16
|
+
still requires the current Session's delivery authority, legal workspace and an
|
|
17
|
+
enabled execution gate.
|
|
18
|
+
|
|
19
|
+
If the Leader already received the request, use its original durable input and
|
|
20
|
+
continue after reopening; do not resend it or create a self-wake. Preserve a
|
|
21
|
+
direct-conversation request and its boundaries in Task records when needed,
|
|
22
|
+
without impersonating user/Operator input. When the Operator or user is routing
|
|
23
|
+
new input, use the existing two operations:
|
|
14
24
|
|
|
15
25
|
```sh
|
|
16
26
|
yui task reopen <task>
|
|
@@ -30,8 +40,9 @@ intact. The Leader must assess the new request and separately accept any new
|
|
|
30
40
|
result, not pretend old validation proves changed work. Reopen does not replay
|
|
31
41
|
historical Messages/Runs, change the Role's Agent/model/permissions, or lift an
|
|
32
42
|
independent execution stop. Queries, ordinary record/discussion input and Session
|
|
33
|
-
recovery do not authorize resumption. Cancelled intent needs
|
|
34
|
-
restoration authority
|
|
43
|
+
recovery do not authorize resumption. Cancelled intent needs explicit
|
|
44
|
+
user/Operator restoration authority and cannot be restored by the Leader;
|
|
45
|
+
archived Tasks cannot reopen. A stopped gate still needs
|
|
35
46
|
the separately authorized start/cleanup path.
|
|
36
47
|
|
|
37
48
|
These are two atomic operations, not one transaction. Read the reopen result and
|
|
@@ -5,7 +5,8 @@ description: Complete a bounded Yui WorkItem AgentRun or native child assignment
|
|
|
5
5
|
|
|
6
6
|
# Yui Worker
|
|
7
7
|
|
|
8
|
-
Follow [yui-runtime](../yui-runtime/SKILL.md) first
|
|
8
|
+
Follow [yui-runtime](../yui-runtime/SKILL.md) first, including its per-turn
|
|
9
|
+
version/availability check and conditional full reload. For a managed AgentRun,
|
|
9
10
|
load its exact Context Pack and
|
|
10
11
|
use only the returned WorkItem, refs, workspace, writable Project IDs, and
|
|
11
12
|
completion actions. The launch Envelope is a pointer, not an execution brief.
|
|
@@ -23,6 +24,12 @@ Resolve Skill links relative to this Skill's directory.
|
|
|
23
24
|
|
|
24
25
|
## Execute within the exact boundary
|
|
25
26
|
|
|
27
|
+
Use **yui-runtime**'s own-inbox flow at useful work boundaries and before the
|
|
28
|
+
final report. Current-Assignment `inbox show` is an authorized way to read new
|
|
29
|
+
directed clarification during this turn without redispatch. Claim before
|
|
30
|
+
handling and ack only after disposition; never use it to read another
|
|
31
|
+
Assignment, expand Project permissions, or accept your own result.
|
|
32
|
+
|
|
26
33
|
Leader clarification and continuation arrive as Messages in the exact bounded
|
|
27
34
|
Context Pack. Read those authorized refs; do not request pack-external Leader
|
|
28
35
|
messages or require redispatch/status changes merely to answer a question.
|
|
@@ -0,0 +1 @@
|
|
|
1
|
+
2
|