feat: connect async chat to current Ticket assignment and saved results

2026-10-30 03:16:00 +09:00
parent 1eecccc21e
commit 55ad8c4265
2 changed files with 412 additions and 25 deletions
@@ -16,6 +16,8 @@ Keep the chat responsive. Delegate long-running execution to an ordinary backgro

 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.

+For Ticket-bound work, use `ShowTicket` and current assignment tracking before selecting a delegation. Pass the current Subject assignment reference and the Ticket's repository/ref/Workdir constraints through the existing `WorkerSpawn` Ticket fields; general Worker permission alone does not authorize another Subject's Ticket or an unrelated target. Do not assign yourself, change the Ticket's targets, or switch to non-Ticket spawning to evade a refusal. Ticket results remain in the existing Ticket/MR sources: a background Worker may report with `TicketImplementationResult` when authorized and refer to that saved result in an ordinary `WorkerNotify`. Evaluate it with `TicketImplementationResultQuery`, reread the current assignment and user intent before acting, and keep an old result or notification distinct from authority for a new attempt after reassignment. Saved work, notification acceptance, assignment handling, Ticket closure, and MR approval/integration are separate facts; none automatically publishes a conversation message.
+
 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.

 Do not poll for results, keep a turn alive waiting, or create wait-only turns. Finish once immediate useful actions are done; existing notifications can bring background information into a later turn while other conversations continue. Recheck current intent and authoritative records when that information arrives, then decide whether an explicit conversation send is warranted.