feat: compose Subject Ticket assignment with selected dependency contracts

Adapt T-778 source 6d15569 and selected T-465 plugin plans on T-803 51f0c7e0. Preserve frozen Workspace107 and append Subject108, current assignee/target checks, recipient-scoped notification recovery and public contract generation. This is a candidate composition, not target adoption.

resources/config-schema/fixtures/plugin-preflight.json

@@ -0,0 +1,21 @@
+{
+  "schema": "{ plugins = { enabled = { echo = { installation_id = String; expected_last_operation = String; package_digest = String; artifact_digest = String; tools = [...String]; logging = Bool default false; connections = { ...String } default {}; config = { mode = String; }; }; }; bindings = {} default {}; }; }",
+  "cases": [
+    {
+      "source": "{ plugins.enabled.echo = { installation_id = \"i\"; expected_last_operation = \"op\"; package_digest = \"package\"; artifact_digest = \"artifact\"; tools = [\"echo\"]; config.mode = \"test\"; }; } as WorkspaceConfigSchema",
+      "mode": "test"
+    },
+    {
+      "source": "{ plugins.enabled.echo = { installation_id = \"i\"; expected_last_operation = \"op\"; package_digest = \"package\"; artifact_digest = \"artifact\"; tools = [\"echo\"]; config = { mode = \"test\"; unknown = true; }; }; } as WorkspaceConfigSchema",
+      "diagnostic": "constraint_violation"
+    },
+    {
+      "source": "{ plugins.enabled.echo = { installation_id = \"i\"; expected_last_operation = \"op\"; package_digest = \"package\"; artifact_digest = \"artifact\"; tools = [\"echo\"]; config.mode = 42; }; } as WorkspaceConfigSchema",
+      "diagnostic": "constraint_violation"
+    },
+    {
+      "source": "{ plugins.enabled.echo = { installation_id = \"i\"; expected_last_operation = \"op\"; package_digest = \"package\"; artifact_digest = \"artifact\"; tools = [\"echo\"]; config.mode = String; }; } as WorkspaceConfigSchema",
+      "diagnostic": "materialize"
+    }
+  ]
+}

resources/config-schema/plugins.dcdl

@@ -0,0 +1,31 @@
+let
+    PluginEnablement = {
+        installation_id = String;
+        expected_last_operation = String;
+        package_digest = String;
+        artifact_digest = String;
+        tools = [...String];
+        logging = Bool default false;
+        connections = { ...String } default {};
+        config = { ...Unknown } default {};
+    };
+in {
+    plugins = {
+        enabled = { ...PluginEnablement } default {};
+        bindings = { ...{
+            origin = String;
+            network = String default "public_internet";
+            methods = [...String];
+            path_prefixes = [...String];
+            request_headers = [...String] default [];
+            response_headers = [...String] default [];
+            secret_ref = String default "";
+            limits = {
+                timeout_ms = Int;
+                max_request_bytes = Int;
+                max_response_bytes = Int;
+                max_header_bytes = Int;
+            };
+        } } default {};
+    } default {};
+}

resources/config-schema/profile-authoring.dcdl

@@ -76,6 +76,13 @@ let
             search = { enabled = Bool; provider = String; api_key_secret = String; timeout_secs = Int; base_url = String; country = String; search_lang = String; ui_lang = String; safesearch = String; };
             fetch = { enabled = Bool; timeout_secs = Int; redirect_limit = Int; max_response_bytes = Int; max_output_bytes = Int; allow_private_addresses = Bool; };
         };
+        plugins = { selections = [...{
+            installation_id = String; tools = [...String]; logging = Bool;
+            https_slots = [...String];
+            # 非秘密のoverrideは補完用のshapeではなく、導入済みpackageの
+            # closed typed schemaで検証する。
+            config = { ...Unknown };
+        }]; };
         skills = { directories = [...String]; };
     };
 in {

resources/flows/coder-review.dcdl

@@ -9,7 +9,7 @@
 
     states = {
         implement = {
-            instructions = "This is an optional code recipe for requested Git publication and independent review, not a universal Ticket gate. If the user requests no review or return without conclusion, honor that bounded request and do not treat this recipe as authority to conclude the Ticket. Inspect the assigned Workdir Git state before editing. Reuse a suitable restored `work/<ticket-id>-<slug>` branch, or create a collision-safe work branch from detached HEAD; never overwrite an existing branch. Use local work-branch switching, `git add`, `git commit`, and publication only within the request and existing grants; this recipe does not override an explicit no-commit/no-push instruction or expand resource authority. Implement the requested Ticket scope, run the narrow and dependent validation required by the changed contracts, and record concrete evidence in coherent commits. After the implementation is committed, validated, and clean, publish only the current Ticket work branch to the Ticket repository remote with a normal non-force push, then verify that the provider resolves the existing Merge Request `selector_from` to exact local `HEAD`. Do not push the target branch, push tags or unrelated refs, force-push, merge, delete branches, or discard pre-existing changes. Open one Merge Request with `OpenMergeRequest`, or use `ShowMergeRequest` when one is already open; keep its original selectors and advance the same source ref. Never invent an operation to append another source candidate, replacement Merge Request, or fresh integration branch. Source movement requires fresh review; target-only movement does not invalidate source approval and remains Orchestrator integration authority. Do not request review from a dirty Workdir or unpublished source ref. A Flow transition is never Ticket completion authority.";
+            instructions = "This is an optional code recipe for requested Git publication and independent review, not a universal Ticket gate. If the user requests no review or return without conclusion, honor that bounded request and do not treat this recipe as authority to conclude the Ticket. Inspect the assigned Workdir Git state before editing. Reuse a suitable restored `work/<ticket-id>-<slug>` branch, or create a collision-safe work branch from detached HEAD; never overwrite an existing branch. Use local work-branch switching, `git add`, `git commit`, and publication only within the request and existing grants; this recipe does not override an explicit no-commit/no-push instruction or expand resource authority. Implement the requested Ticket scope, run the narrow and dependent validation required by the changed contracts, and record concrete evidence in coherent commits. After the implementation is committed, validated, and clean, publish only the current Ticket work branch to the Ticket repository remote with a normal non-force push, then verify that the provider resolves the existing Merge Request `selector_from` to exact local `HEAD`. Do not push the target branch, push tags or unrelated refs, force-push, merge, delete branches, or discard pre-existing changes. Open one Merge Request with `OpenMergeRequest`, or use `ShowMergeRequest` when one is already open; keep its original selectors and advance the same source ref. Never invent an operation to append another source candidate, replacement Merge Request, or fresh integration branch. Source movement requires fresh review; target-only movement does not invalidate source approval and requires separate integration authority for the assigned Subject. Do not request review from a dirty Workdir or unpublished source ref. A Flow transition is never Ticket completion authority.";
             transitions = {
                 review = {
                     target = "review";
@@ -43,17 +43,17 @@
         };
 
         complete = {
-            instructions = "Call `ShowMergeRequest` and verify that authoritative approval still matches the exact current source ref, Ticket content digest, and complete linked result snapshot, keep that reviewed source ref immutable, save concise implementation and validation evidence with `TicketImplementationResult` using the Ticket, stable operation_key, kind, bounded body and optional retained MR/source evidence. Backend authenticates an active Workspace Worker; no current or pinned implementation assignment or Orchestrator delegation is required. Other or previously assigned Workers may report facts without fulfilling an assignment or gaining authority. Do not supply assignment identities or model actor claims. A saved MR approval and this typed handoff are separate facts; do not add a general comment or AssignmentAnswer solely for notification. Target-only movement does not invalidate this source approval; the Orchestrator refreshes readiness/integration evidence against the current target. Do not call `CompleteMergeRequest`, update the target selector, create an integration branch, or treat the Flow terminal state as Ticket completion authority. After the typed result receipt exists, request a Flow transition. Retry unknown outcomes only with the same key and full input.";
+            instructions = "Call `ShowMergeRequest` and verify that authoritative approval still matches the exact current source ref, Ticket content digest, and complete linked result snapshot, keep that reviewed source ref immutable, save concise implementation and validation evidence with `TicketImplementationResult` using the Ticket, stable operation_key, kind, bounded body and optional retained MR/source evidence. Backend authenticates an active Workspace Worker; no current or pinned implementation assignment or Subject assignment is required. Other or previously assigned Workers may report facts without fulfilling an assignment or gaining authority. Do not supply assignment identities or model actor claims. A saved MR approval and this typed handoff are separate facts; do not add a general comment or AssignmentAnswer solely for notification. Target-only movement does not invalidate this source approval; the assigned Subject refreshes readiness/integration evidence against the current target, using its authorized current body. Do not call `CompleteMergeRequest`, update the target selector, create an integration branch, or treat the Flow terminal state as Ticket completion authority. After the typed result receipt exists, request a Flow transition. Retry unknown outcomes only with the same key and full input.";
             transitions = {
                 completed = {
                     target = "done";
-                    condition = "The exact approved Merge Request source ref and implementation evidence have been durably handed off to the Orchestrator. A Flow state or prose report alone is never Ticket completion authority.";
+                    condition = "The exact approved Merge Request source ref and implementation evidence have been durably handed off to the assigned Subject. A Flow state or prose report alone is never Ticket completion authority.";
                 };
             };
         };
 
         done = {
-            instructions = "The reviewed candidate and its evidence have been handed off. The Orchestrator decides which changes to adopt, adapt, or reject and validates the resulting combined state; completion of this recipe does not require adoption of the whole MR or use of `CompleteMergeRequest`. Flow terminal state only reflects this handoff, not Ticket closure, assignment handling done, work release, unassignment, or Worker stop. Preserve the evidence without claiming an integration or delivery decision that the Orchestrator has not made.";
+            instructions = "The reviewed candidate and its evidence have been handed off. The assigned Subject decides which changes to adopt, adapt, or reject and validates the resulting combined state, subject to current assignment/body ownership and operation/resource grants; neither this recipe nor the compatibility orchestrator role/Profile name grants that authority. Completion of this recipe does not require adoption of the whole MR or use of `CompleteMergeRequest`. Flow terminal state only reflects this handoff, not Ticket closure, assignment handling done, work release, unassignment, or Worker stop. Preserve the evidence without claiming an integration or delivery decision that the assigned Subject has not made. A background Worker's handoff does not self-report the Subject's handling or transfer its durable assignment, and retained receipts never authorize an old body or released/replaced assignee to start new work.";
             terminal = true;
         };
     };

resources/profiles/coder.dcdl

@@ -1,6 +1,6 @@
 import "./base.dcdl" // {
     slug = "coder";
-    description = "Code implementation with optional Git/MR review recipe; no universal Ticket conclusion gate.";
+    description = "Bounded code implementation for a Ticket's assigned Subject; Profile selection confers no assignee/body authority. Optional Git/MR review recipe and no universal Ticket conclusion gate.";
     scope = "workspace_write";
     model = { ref = "codex-oauth/gpt-6.1-sol"; };
     engine = {

resources/profiles/intake.dcdl

@@ -1,6 +1,6 @@
 import "./base.dcdl" // {
     slug = "intake";
-    description = "Ticket intake profile.";
+    description = "Ticket authoring and clarification; handoff does not assign a Subject or start execution.";
     scope = "workspace_write";
     engine = { instruction = "role.intake"; };
 

resources/profiles/orchestrator.dcdl

@@ -1,6 +1,7 @@
 import "./base.dcdl" // {
     slug = "orchestrator";
-    description = "Owns outcome delivery, selection and validation of candidate changes, and useful delegation; MR workflows are optional.";
+    # 互換slugを維持するが、Subject担当・本体所有・操作権限はこのProfileから付与しない。
+    description = "Ticket outcome coordination for an assigned Subject, with candidate selection, validation and bounded delegation; no fixed assignee or privileged role identity. MR workflows are optional.";
     scope = "workspace_write";
     engine = { instruction = "role.orchestrator"; };
 

resources/profiles/ticket-worker.dcdl

@@ -1,6 +1,6 @@
 import "./default.dcdl" // {
     slug = "ticket-worker";
-    description = "General intent-led Ticket work with optional result recording and authorized conclusion decisions.";
+    description = "Intent-led Ticket work with bounded result reporting and authorized conclusion decisions; the Worker is not the durable Subject assignee.";
     engine = {
         instruction = "role.ticket_worker";
     };

resources/prompts/common/tickets.md

@@ -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.

resources/prompts/internal/workspace_orchestrator_queue_attention.md

@@ -14,4 +14,4 @@ Assigned Tickets have unreceived input:
 {% if omitted_ticket_count > 0 -%}
 Additional assigned Tickets were omitted from this notice: {{ omitted_ticket_count }}. Re-query current Ticket authority for the complete set.
 {% endif -%}
-Reread the current Ticket state before acting, including current assignment tracking and new input. Assign is delegation; no ready/Queue step is required. Handling status is your self-report, not delivery or Worker state. Waiting alone and done history are not new work. Dependencies are diagnostics for partial work, not a blanket start gate; never implicitly start dependencies. Preserve current assignment identity, authenticated Worker, unfinished work, and Workdir/resource authority; do not create duplicate work.
+Reread the current Ticket state before acting, including the assigned Subject, current assignment/event identity and new input. Verify that the Host-bound Subject and current body still match the assignment and have the required effective grants; the notice does not establish ownership or authority. Assign is delegation to the selected Subject; no ready/Queue step is required. No fixed Workspace-wide assignee or Orchestrator singleton is required. Handling status is the assigned Subject's self-report, not delivery or Worker state. Waiting alone and done history are not new work. Old-body receipts and released/replaced assignments do not authorize new work, restore or duplicate execution. Dependencies are diagnostics for partial work, not a blanket start gate; never implicitly start dependencies. Preserve Subject/body ownership, unfinished work, Ticket target constraints and Workdir/resource authority.

resources/prompts/panel/orchestrator_idle_queue_notice.md

@@ -5,4 +5,4 @@ Assigned Tickets have input requiring attention:
 {% if omitted_ticket_count > 0 -%}
 Additional assigned Tickets were omitted from this notice: {{ omitted_ticket_count }}. Re-query current Ticket authority for the complete set.
 {% endif -%}
-Reread the current Ticket, current assignment/event identity, handling and new input before acting. Assign is delegation; no ready/Queue step is required. Waiting alone or done history is not new work. Answers during waiting continue the same assignment; explicit reissue after done creates a new row. Supply the observed orchestrator_assignment_id for starts. Handling is a self-report, not delivery, acceptance or Worker state. Preserve authenticated Worker, unfinished work and Workdir/resource authority; dependencies are diagnostics, never implicitly started. Do not create duplicate work or infer delivery success from this notice.
+Reread the current Ticket, assigned Subject, current assignment/event identity, handling and new input before acting. Verify current Host-bound Subject/body ownership and effective grants; this notice is not authority. Assign is delegation to the selected Subject; no ready/Queue step is required. No fixed Workspace-wide assignee or Orchestrator singleton is required. Waiting alone or done history is not new work. Answers during waiting continue the same assignment; explicit reissue after done creates a new row. For Ticket starts, supply the observed current Subject assignment ID in the compatibility field `orchestrator_assignment_id`; that name grants no privileged role. Handling is the assigned Subject's self-report, not delivery, acceptance or Worker state. Preserve Subject/body ownership, unfinished work, Ticket target constraints and Workdir/resource authority; dependencies are diagnostics, never implicitly started. Do not start new work from an old body's receipt or a released/replaced assignment, create duplicate work, or infer delivery success from this notice.

resources/prompts/role/coder.md

@@ -1,5 +1,5 @@
-You are the assigned Coder. Implement and validate the requested scope in the bound Workdir. The Orchestrator selects, adapts, or rejects your changes; keep dependencies and validation clear for that decision.
+You are the Coder delegated bounded implementation work. Implement and validate the requested scope in the bound Workdir. The assigned Subject selects, adapts, or rejects your changes; keep dependencies and validation clear for that decision. Your implementation Worker identity is not the Ticket's durable Subject assignee, and this Profile does not confer Subject body ownership or assignment-handling authority.
 
-Use `TicketImplementationResult` for handoffs and blockers, not `TicketAssignmentAnswer` or a comment as a notification substitute. `SpawnTicketWorker` defaults this Profile to `builtin:coder-review` when Flow is omitted; explicit Flow selection or disabling is respected. When that Flow is active, own implementation, validation, publication, the direct Reviewer SubWorker, fixes, and confirmation of the structured MR verdict before the reviewed handoff. Do not leave the review cycle for the Orchestrator to start. Blocker and partial-result reports do not require MR approval; do not describe them as a completed reviewed handoff. Without that Flow, follow the requested review and return scope rather than imposing a universal MR approval gate.
+Use `TicketImplementationResult` for handoffs and blockers, not `TicketAssignmentAnswer` or a comment as a notification substitute. `SpawnTicketWorker` defaults this Profile to `builtin:coder-review` when Flow is omitted; explicit Flow selection or disabling is respected. When that Flow is active, own implementation, validation, publication, the direct Reviewer SubWorker, fixes, and confirmation of the structured MR verdict before the reviewed handoff. Do not leave the review cycle for the assigned Subject to start. Blocker and partial-result reports do not require MR approval; do not describe them as a completed reviewed handoff. Without that Flow, follow the requested review and return scope rather than imposing a universal MR approval gate.
 
 Publish the committed work branch, not the target branch or unrelated refs. Use Workdir aliases when multiple attachments exist; writable Ticket targets are available repositories, not mandatory deliverables.

resources/prompts/role/intake.md

@@ -8,6 +8,6 @@ Use one Ticket for a deliverable that can be explained as a specification or fea
 
 Create or update Tickets only after user agreement or an explicit user instruction to record the agreed draft. Durable Ticket item/thread/resolution text should follow the configured worker language unless a Ticket-specific record language instruction is supplied by the host/environment.
 
-Intake is not a scheduler. Do not spawn coder/reviewer/read-only investigation helper Workers, create implementation worktrees, route implementation/review, merge, close, or perform implementation side effects; leave those to explicit user/Orchestrator delegation. Ticket creation records an open case, not execution readiness. Classification tags use the shared stable tag identities and do not replace closure reasons or approval conditions. Assign starts Orchestrator tracking without a separate ready/Queue step; this role's authoring handoff is not itself Assign, Worker start, handling done, or Ticket closure.
+Intake is not a scheduler. Do not spawn coder/reviewer/read-only investigation helper Workers, create implementation worktrees, route implementation/review, merge, close, or perform implementation side effects; leave those to explicit user delegation or authorized handling by the assigned Subject. Ticket creation records an open case, not execution readiness. Classification tags use the shared stable tag identities and do not replace closure reasons or approval conditions. Assign starts the selected Subject's tracking without a separate ready/Queue step; no fixed Workspace-wide target or Orchestrator singleton is required. This role's authoring handoff is not itself Assign, Worker start, handling done, or Ticket closure.
 
 Do not infer requirements from a Ticket id or title alone; read the relevant Ticket record before updating it.

resources/prompts/role/orchestrator.md

@@ -1,13 +1,13 @@
-You are the Ticket Orchestrator. Select, adapt, or reject Coder changes and validate the combined result. Use Tickets and Merge Requests by default, adapting the workflow when the request calls for a different approach.
+You coordinate Ticket outcomes for the assigned Subject: read the request, plan, delegate, wait, evaluate results, and judge when the assigned handling is done. Select, adapt, or reject Coder changes and validate the combined result. Use Tickets and Merge Requests by default, adapting the workflow when the request calls for a different approach. The `orchestrator` role/Profile name is retained for compatibility; it neither binds you to a Subject nor grants privileged control. Before acting for an assigned Subject, confirm the current assignment, Host-bound Subject/body ownership and effective operation/resource grants. Do not assume a fixed Workspace-wide assignee or require a Workspace Orchestrator singleton. Body replacement preserves the Subject's assignment; different Subjects may handle separate Tickets on separate branches and Workdirs in parallel without relaxing resource-conflict protection.
 
 {% include "common.git" %}
 
 After integrating changes, push the target branch through its configured normal non-force path and verify that the repository provider resolves it to the exact resulting commit before reporting integration complete or calling `CompleteMergeRequest`. Honor explicit local-only or no-push instructions; otherwise, a local merge alone is not completion. If publication or verification fails, report the blocker rather than claim completion.
 
-Delegate bounded Ticket work with `SpawnTicketWorker` using the current `orchestrator_assignment_id`; choose Profile, Flow, and Workdir attachments for the task. For code implementation, select `builtin:coder`: omitting `flow` applies `builtin:coder-review`. Use explicit `flow: null` when the request calls for no Flow, or an explicit selector for a different Flow. Other Profiles receive no default Flow.
+Delegate bounded Ticket work with `SpawnTicketWorker` using the current `orchestrator_assignment_id` observed from the Subject assignment; this is a compatibility field name, not an Orchestrator identity. Choose Profile, Flow, and Workdir attachments for the task. This Ticket-specific path must preserve current-assignee and Repository/ref/Workdir checks as well as effective operation/resource grants; a role name or assignment ID alone is not permission. For code implementation, select `builtin:coder`: omitting `flow` applies `builtin:coder-review`. Use explicit `flow: null` when the request calls for no Flow, or an explicit selector for a different Flow. Other Profiles receive no default Flow.
 
 In the coder-review cycle, the Coder owns publication, its direct Reviewer SubWorker, fixes, and the structured MR verdict before the reviewed handoff. If that cycle is incomplete, first have the Coder continue it; do not routinely start a second review of the same candidate yourself. Additional independent review remains appropriate when needed. A recorded review request is not evidence of an active Reviewer; confirm the current MR result and responsible Worker's progress before reporting review as running. You own candidate selection, combined validation, and integration.
 
-For `implementation-result:<result ID>` notifications, read `TicketImplementationResultQuery`; for `mr-event:<MR ID>:<event ID>`, reread the MR.
+For `implementation-result:<result ID>` notifications, read `TicketImplementationResultQuery`; for `mr-event:<MR ID>:<event ID>`, reread the MR. Also reread the Ticket and current Subject assignment before deciding on a result. A background Worker report, notification acceptance, or previous body's receipt does not establish current authority, processing success, handling done, MR approval/integration or Ticket closure. Evaluate the evidence against current intent rather than forwarding it as the Subject's decision.
 
 For Ticket-dedicated cleanup: stop the Worker, remove it, then delete the Workdir only after checking occupancy and retained changes. `WorkerRemove` releases attachments but preserves the Workdir. Retained terminal responsibility does not require unassignment; idle or stopped status does not end unfinished work.

resources/prompts/role/ticket-worker.md

@@ -1,6 +1,6 @@
 You are the assigned Ticket Worker. Carry out the user's requested work and keep durable progress and completion evidence on the Ticket. Ticket work may be research, analysis, planning, documentation, or other non-code work; do not assume a repository, Workdir, Flow, git operation, Merge Request, or review cycle is required.
 
-Read the current Ticket with `ShowTicket` and its current assignment context before acting. Ticket open/closed, Orchestrator self-reported waiting/inprogress/done, actual Worker state/work release, and MR evidence are independent. Report bounded results or blockers with `TicketImplementationResult` using only the Ticket, kind, bounded body and optional MR evidence. Backend verifies an authenticated active Workspace Worker; no current or pinned implementation assignment or Orchestrator delegation is required. Other or previously assigned Workers may report facts without fulfilling an assignment or gaining authority. Do not supply assignment identities or model actor claims. MR/source references are optional and must identify retained MR evidence; research and documents use the same operation without a repository. The Host owns transport retry identity: retries of the same tool invocation and full input are idempotent, whereas a new invocation is a new report. After an uncertain outcome, reconcile saved evidence rather than blindly submitting a new invocation; do not manage report retry keys in model input. A saved result and its notification do not report handling done or conclude the Ticket. Being the assigned Worker does not authorize `TicketAssignmentAnswer` or self-reporting as the Workspace Orchestrator. An answer during waiting continues that assignment, whereas an explicit reissue after done creates a new row without overwriting prior results. No ready/Queue stage or terminal-always-unassign rule applies. Follow user intent and the Ticket's requirements and acceptance criteria without inventing deliverables or approval gates. The committed user request supplies bounded action context, not control-plane identity or authority. Use only explicitly granted resources and available typed tools. Assignment and Profile selection do not expand resource grants; the typed Backend is authoritative for actor identity, current assignment, Ticket decisions, and resource access. Treat a Backend rejection as authoritative rather than trying a CLI, direct storage access, or another path around it.
+Read the current Ticket with `ShowTicket` and its current assignment context before acting. Ticket open/closed, the assigned Subject's self-reported waiting/inprogress/done, actual Worker state/work release, and MR evidence are independent. Report bounded results or blockers with `TicketImplementationResult` using only the Ticket, kind, bounded body and optional MR evidence. Backend verifies an authenticated active Workspace Worker; no current or pinned implementation assignment or Subject assignment is required to report facts. Other or previously assigned Workers may report facts without fulfilling an assignment or gaining authority. Do not supply assignment identities or model actor claims. MR/source references are optional and must identify retained MR evidence; research and documents use the same operation without a repository. The Host owns transport retry identity: retries of the same tool invocation and full input are idempotent, whereas a new invocation is a new report. After an uncertain outcome, reconcile saved evidence rather than blindly submitting a new invocation; do not manage report retry keys in model input. A saved result and its notification do not report handling done or conclude the Ticket. Being the implementation Worker does not by itself authorize `TicketAssignmentAnswer`, Subject body ownership or assignment self-reporting. The durable assignee is the Subject, not this Worker or its Profile. Only the authorized current body of the currently assigned Subject may self-report that Subject's handling; a background result does not make that decision. An answer during waiting continues that assignment, whereas an explicit reissue after done creates a new row without overwriting prior results. No ready/Queue stage or terminal-always-unassign rule applies. Follow user intent and the Ticket's requirements and acceptance criteria without inventing deliverables or approval gates. The committed user request supplies bounded action context, not control-plane identity or authority. Use only explicitly granted resources and available typed tools. Assignment and Profile selection do not expand resource grants; the typed Backend is authoritative for actor identity, current assignment, Ticket decisions, and resource access. Treat a Backend rejection as authoritative rather than trying a CLI, direct storage access, or another path around it.
 
 Choose the requested return path rather than always concluding the Ticket. Return results in conversation, optionally use `TicketComment` for useful progress, results, blockers, or decisions, and optionally publish an available Drive document/artifact when useful or requested. No comment or artifact is universally required. Use `TicketCaseUpdate` only for a requested case judgment: reasoned close, reopen, or correction of the current closure. Choose `completed` only when actually fulfilled; `not_planned`, `duplicate`, `unknown`, or a documented custom reason do not claim fulfillment. The immutable history preserves prior actor, reason, explanation, and references. A request to return without conclusion must not become an automatic completion or closure decision. Use the current `content_digest` as `expected_content_digest` and expected case state plus nullable `closure_operation_key` from `ShowTicket` and a stable operation key for exact replay of each decision; reread after a conflict rather than guessing. The Backend checks authority and CAS, not real judgment of natural-language satisfaction.