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

feat: connect Subject Ticket assignments across public execution paths

Browse Source
This commit is contained in:
Hare
2026-10-30 00:11:02 +09:00
parent 7ad6030498
commit 6733aeef01
91 changed files with 8938 additions and 1731 deletions
Download Patch File Download Diff File Expand all files Collapse all files
resources/prompts/common/tickets.md
+7 -3
View File
@@ -12,12 +12,16 @@ Ticket cases have only `open` (still handled) and `closed` (handling ended for n
Classification tags use stable tag IDs, not display names, for mutations and filters. Use the shared Workspace tag tools for creation/list/rename/delete and Ticket tag-set changes with their observed operation identities; names such as `ready` never grant start permission. Tag-set CAS compares `expected_tag_ids` with the observed full ID set; tag rename/delete CAS compares `expected_last_operation_key` with the observed tag operation identity. Classification is separate from a close reason and never closes/reopens or delegates a Ticket.
Read the current Orchestrator delegation with `TicketAssignmentTrackingQuery`; enumerate retained assignment IDs with bounded `TicketAssignmentsQuery`, then read a selected row and its `TicketAssignmentTrackingHistory`. Use `TicketAssignmentDiagnostics` for independent bounded delivery/input and start evidence; its separate cursors and explicit unknown/history fields are not a handling status. `QueryTicket` can filter the exact current `assigned_principal`, self-reported `handling_status`, and current closed-case `closure_reason`. Closure reason is distinct from tag IDs; retained/reopened reasons are history, and Worker status is never inferred. Each immutable `assignment_id` denotes this particular delegation to the stable Workspace Orchestrator principal, not a concrete Runtime Worker. Assign is delegation and initial judgment input; no ready step or separate Queue is required. `waiting`, `inprogress`, and `done` are the Orchestrator's self-reported handling, never Ticket case states, delivery/acceptance or Worker running/idle/stop. Record waiting reason, progress, next action and result through `TicketAssignmentTrackingUpdate` when authorized, not just conversation memory. Waiting must identify what is needed next; research returned to a human can be `open` + handling `done`. Respect an explicit user approval condition; do not add a universal human/MR gate. Done is not Backend certification of satisfaction, third-party approval, merge, actual work release, or Worker stop.
A Ticket's durable assignee is an explicitly selected Subject, represented by `{kind: "subject", subject_id: "<subject ID>"}`; `subject_id` is a string. Any permitted Subject can be selected: there is no fixed Workspace-wide assignee or required Orchestrator singleton. Keep the assigned Subject distinct from its current body Worker, background implementation Workers/attempts, and Repository/branch/Workdir resources. Body stop, replacement, or restore does not reassign the Ticket. Different Subjects may handle different Tickets on separate branches and Workdirs in parallel; preserve per-Subject body ownership and actual resource-conflict checks rather than imposing Workspace-wide serialization. Assignment, Profile/role names, Feature activation, and branch separation do not grant operation or resource authority. Backend authenticates the acting Worker and checks effective grants, current Subject/body ownership where required, and Ticket-specific assignment/target conditions.
Use `TicketOrchestratorAssign` for explicit initial delegation or reissue, with target principal, observed `expected_assignment_id` (explicit null only when unassigned), and stable `operation_id`. Query first; target principal is not the actor or an authority claim. The usual target is `{kind: "workspace_agent", agent_key: "workspace-orchestrator"}`; Backend validates role/principal and actual authentication. Use `TicketOrchestratorClear` only for explicit release of the observed assignment with its ID and operation_id, not automatically on done/closed. Neither operation starts or stops a Worker. Exact retry retains the same operation_id and full input; conflict or unknown outcome must not silently generate a new key. Reread current tracking before any subsequent mutation.
Read the current Subject assignment with `TicketAssignmentTrackingQuery`; enumerate retained assignment IDs with bounded `TicketAssignmentsQuery`, then read a selected row and its `TicketAssignmentTrackingHistory`. Use `TicketAssignmentDiagnostics` for independent bounded delivery/input and start evidence; its separate cursors and explicit unknown/history fields are not a handling status. `QueryTicket` can filter the exact current Subject `assigned_principal`, self-reported `handling_status`, and current closed-case `closure_reason`. Closure reason is distinct from tag IDs; retained/reopened reasons are history, and Worker status is never inferred. Each immutable `assignment_id` denotes this particular assignment period to the Subject, not a concrete Runtime Worker. Assign is delegation and initial judgment input; no ready step or separate Queue is required. `waiting`, `inprogress`, and `done` are the assigned Subject's self-reported handling, never Ticket case states, delivery/acceptance or Worker running/idle/stop. Record waiting reason, progress, next action and result through `TicketAssignmentTrackingUpdate` only when authorized to act for the current assigned Subject, not just in conversation memory. Waiting must identify what is needed next; research returned to a human can be `open` + handling `done`. Respect an explicit user approval condition; do not add a universal human/MR gate. Done is not Backend certification of satisfaction, third-party approval, merge, actual work release, or Worker stop.
Use `TicketOrchestratorAssign` for explicit initial assignment, reassignment or reissue to the selected Subject principal, with observed `expected_assignment_id` (explicit null only when unassigned) and stable `operation_id`. Query first; target principal is not the actor or an authority claim. Use `{kind: "subject", subject_id: "<subject ID>"}` for new assignments. Legacy User, Worker and WorkspaceAgent principals (`user`, `worker`, `workspace_agent`) remain readable for historical/audit evidence only; do not use them for new assignments, infer a Subject mapping, or silently replace an unmapped legacy assignee. Report unresolved migration/identity diagnostics instead. `TicketOrchestratorAssign`, `TicketOrchestratorClear`, the `orchestrator` role/Profile spelling, and `orchestrator_assignment_id` are retained compatibility names, not a privileged role or fixed target identity. Use `TicketOrchestratorClear` only for explicit release of the observed assignment with its ID and operation_id, not automatically on done/closed. Neither operation starts or stops a Worker. Exact retry retains the same operation_id and full input; conflict or unknown outcome must not silently generate a new key. Reread current tracking before any subsequent mutation.
Answers during waiting or ongoing handling continue the same assignment row; use `TicketAssignmentAnswer` with that `assignment_id`, observed `expected_last_event_id`, stable `operation_key`, and answer `body`, not an unfenced comment as a substitute. Do not reassign merely to deliver an answer or automatically declare inprogress on arrival. After done, an explicit reissue creates a new row/assignment_id even for the same principal and preserves the prior result. Reopen alone is neither reissue nor resurrection of an old Worker. Release/replacement remains separate from the old row's last status/result; done does not require unassignment. Worker replacement alone does not create a new delegation. Dependencies are diagnostics for judging partial work or waiting, not a blanket start gate; never start dependencies implicitly.
For a new self-report, read the exact current assignment and send `assignment_id`, observed `last_event_id` as `expected_last_event_id`, a stable `operation_key`, and the complete tracking payload. Do not compare status alone or use a replay receipt as a fresh observation. Exact retries retain the same key and full input; reusing a key with changed input is rejected. After stale/replaced/cleared assignment or CAS conflict, reread and reconcile rather than silently overwrite, switch to a newer assignment, or retry as a new operation. Unknown outcomes are not success or failure: reconcile durable evidence and retry only the same operation when appropriate. Assign persistence, notification delivery, Runtime acceptance and actual work start are distinct outcomes; a delivery problem after saved Assign must not prompt another Assign. If a required typed operation or diagnostic endpoint is unavailable, report the concrete API insufficiency instead of inventing state, using a CLI/storage fallback, or creating a second ledger.
Ticket requests, continuing input, changes and MR/implementation results follow the current assigned Subject; delivery resolves that Subject's current body rather than relying on a previous Worker. A notice, retained receipt, historical assignment or saved result is evidence to reread, not authority for an old body or released/replaced assignee to start or continue new work. After reassignment, release, body replacement or permission revocation, recheck current assignment and effective authority; do not restore execution rights from history. A background Worker's result is a bounded factual report, not the assigned Subject's outward decision, adoption judgment or handling update.
For a new self-report, read the exact current assignment and verify that the Host-bound Subject and current body are authorized for that assignment; send `assignment_id`, observed `last_event_id` as `expected_last_event_id`, a stable `operation_key`, and the complete tracking payload. Do not compare status alone or use a replay receipt as a fresh observation. Exact retries retain the same key and full input; reusing a key with changed input is rejected. After stale/replaced/cleared assignment or CAS conflict, reread and reconcile rather than silently overwrite, switch to a newer assignment, or retry as a new operation. Unknown outcomes are not success or failure: reconcile durable evidence and retry only the same operation when appropriate. Assign persistence, notification delivery, Runtime acceptance and actual work start are distinct outcomes; a delivery problem after saved Assign must not prompt another Assign. If a required typed operation or diagnostic endpoint is unavailable, report the concrete API insufficiency instead of inventing state, using a CLI/storage fallback, or creating a second ledger.
Treat case state, assignment handling, and relations as typed domain data rather than filesystem layout or naming conventions. Distinguish a result report, Ticket conclusion, MR review/integration, unfinished assignment, and Worker lifecycle. Terminal current responsibility can remain for display after unfinished work ends; stopping a Worker alone does not end unfinished work, and Ticket conclusion alone does not stop, remove, or clean up its Worker or attachments. Perform only lifecycle actions supported by the tools and authority available to the current Worker.