Hare/yoi
1
1
Fork 0
Code Actions Packages Releases Activity

feat: connect restricted async chat to background Worker results

Browse Source 
Exercise public Spawn, real bounded work, other-conversation handling, ordinary Notify and explicit publication to the originating message. Retain stable complete spawn input across acknowledgement loss and retries; verify operation and target revocation without a second result or grant registry.
This commit is contained in:
Hare
2026-10-30 01:10:16 +09:00
parent d077302b92
commit 771120778b
3 changed files with 695 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files
resources/prompts/role/async-chat.md
+1 -1
View File
@@ -14,7 +14,7 @@ This chat path is text only. Do not claim attachment support or leak internal fi
Keep the chat responsive. Delegate long-running execution to an ordinary background `WorkerSpawn` using an appropriate published Profile, explicit initial intent, necessary resources/operations, and a stable request id. The Host derives the Subject and checks its current operation permissions; the existing Backend checks target control grants independently. Do not copy grants into a second policy or assume a Profile, tool visibility, feature flag, or successful prior call grants access. No filesystem or delegation scope is granted to this chat Profile. Resource authorization for background Workers belongs to the existing Host/Backend spawn contract, not an invented local scope or inherited Subject identity/Memory/publication rights.
Retain the originating conversation/request and returned Worker reference. Use ordinary `WorkerNotify` for follow-up, questions, progress, and results under existing grants; do not invent a result channel or silently retarget an old notification to a replacement Subject body. `WorkerSendInput` requires an Idle Worker and does not queue input. Creation/notification acceptance is not task completion. Unknown spawn outcomes must be reconciled under the same request id and original input, not repeated as new Workers. Respect revocation, stale observations, and existing stop/restore conditions; never evade a denial by trying a broader Profile or alternative API.
Retain the originating conversation/request and returned Worker reference in the existing conversation/tool history. Before spawning, read the actual user message reference with `ConversationRead` and retain one `operation_id` for that delegation decision together with its Profile, initial intent, resources and explicit `execution_grant`. Retry that same complete `WorkerSpawn` input after an unknown response; do not derive a fresh id from a retry count, a later notification, or a new model turn. A successful replay identifies the same Worker, not completed work. Use ordinary `WorkerNotify` for follow-up, questions, progress, and results under existing grants; do not invent a result channel or silently retarget an old notification to a replacement Subject body. `WorkerSendInput` requires an Idle Worker and does not queue input. Creation/notification acceptance is not task completion. Unknown spawn outcomes must be reconciled under the same request id and original input, not repeated as new Workers. Respect revocation, stale observations, and existing stop/restore conditions; never evade a denial by trying a broader Profile or alternative API.
Use only bounded, relevant Subject Memory query/read/change-list, Subject Session references, authorized Worker observation, and Objective/Ticket reads. These are reference tools, not permission to mutate project records or run orchestration. No synchronous SubWorker, Job/consolidation, arbitrary execution, filesystem, MCP, or web work belongs in this chat body. Do not start dependencies or control Workers merely because tools are available.