ticket: refine ticket config role prompts

work-items/open/20260605-173322-ticket-config-role-profile-mapping/artifacts/investigation-plan.md

@@ -20,9 +20,8 @@ These are not arbitrary user-defined roles. They are the roles required by the T
 
 Keep the boundary:
 
-- Profile: Pod runtime recipe.
+- Profile: Pod runtime recipe, including durable role behavior/system instruction when using role-specific profiles.
-- Ticket role config: binds a fixed Ticket role to a Profile selector and optional prompt/workflow refs.
+- Ticket role config: binds a fixed Ticket role to a Profile selector and optional launch prompt/workflow refs.
-- System instruction: role's durable behavior/boundary.
 - Launch prompt: first committed task/user message for a concrete Ticket/action.
 - Workflow: procedural flow, later possibly stateful.
 
@@ -64,12 +63,13 @@ Keep the boundary:
   - Parses workflow frontmatter/body records.
   - No stateful workflow runner exists yet.
 
-### Prompt resources / system instruction
+### Prompt resources / launch prompts
 
 - `crates/pod/src/prompt/loader.rs`
   - Resolves instruction-file references like `$yoi/...` and `$user/...` for current startup/instruction use.
 - Prompt catalog/resources are currently separate from workflow state.
 - There is no implemented role-specific launch prompt engine yet.
+- Role-specific durable system behavior should remain in the selected Profile for the MVP; this config should not override Profile system instruction.
 
 ## Important constraint
 
@@ -88,6 +88,7 @@ Possible dependency choices:
 Recommended MVP:
 
 - Add config domain/parser to `crates/ticket`, using lightweight string wrapper types such as `ProfileSelectorRef`, `PromptRef`, and `WorkflowRef` without depending on `manifest` or `pod`.
+- In the MVP, `PromptRef` is for launch prompts only. Do not add role-level `system_instruction` here; the selected Profile owns durable role system behavior.
 - `pod` consumes this config and performs runtime interpretation where needed.
 
 This preserves:
@@ -112,31 +113,26 @@ root = "work-items"
 
 [roles.intake]
 profile = "project:intake"
-system_instruction = "$workspace/ticket/intake/system"
 launch_prompt = "$workspace/ticket/intake/launch"
 workflow = "ticket-intake-workflow"
 
 [roles.orchestrator]
 profile = "project:orchestrator"
-system_instruction = "$workspace/ticket/orchestrator/system"
 launch_prompt = "$workspace/ticket/orchestrator/launch"
 workflow = "ticket-orchestrator-routing"
 
 [roles.coder]
 profile = "inherit"
-system_instruction = "$workspace/ticket/coder/system"
 launch_prompt = "$workspace/ticket/coder/launch"
 workflow = "multi-agent-workflow"
 
 [roles.reviewer]
 profile = "project:reviewer"
-system_instruction = "$workspace/ticket/reviewer/system"
 launch_prompt = "$workspace/ticket/reviewer/launch"
 workflow = "multi-agent-workflow"
 
 [roles.investigator]
 profile = "inherit"
-system_instruction = "$workspace/ticket/investigator/system"
 launch_prompt = "$workspace/ticket/investigator/launch"
 workflow = "ticket-orchestrator-routing"
 ```
@@ -156,7 +152,7 @@ When `.yoi/ticket.config.toml` is missing:
   - coder: `multi-agent-workflow`
   - reviewer: `multi-agent-workflow`
   - investigator: `ticket-orchestrator-routing`
-- system instruction / launch prompt: none
+- launch prompt: none
 
 When a role section exists but omits optional prompt/workflow refs:
 
@@ -197,7 +193,6 @@ pub enum TicketRole {
 
 pub struct TicketRoleProfile {
     pub profile: ProfileSelectorRef,
-    pub system_instruction: Option<PromptRef>,
     pub launch_prompt: Option<PromptRef>,
     pub workflow: WorkflowRef,
 }
@@ -258,8 +253,8 @@ For this repository, adding actual `.yoi/ticket.config.toml` should be considere
 
 - Take TicketRole + Ticket context + role config.
 - Build `SpawnPod` requests.
-- Resolve profile selector using existing Profile registry.
+- Resolve selected Profile using existing Profile registry; role-specific system behavior comes from that Profile.
-- Resolve role system instruction separately from initial launch prompt.
+- Resolve launch prompt separately from the selected Profile's system instruction.
 - Commit launch prompt as the first user/task message, not hidden context.
 - Include workflow ref in launch/task context.
 
@@ -278,7 +273,7 @@ For this repository, adding actual `.yoi/ticket.config.toml` should be considere
 - Persist workflow phase/state.
 - Gate allowed tools by phase.
 - Inject phase prompts only by committing them to history first.
-- Keep SystemInstruction role-stable and task/phase prompts dynamic.
+- Keep Profile/SystemInstruction role-stable and task/phase prompts dynamic.
 
 ## Validation for implementation
 

work-items/open/20260605-173322-ticket-config-role-profile-mapping/item.md

@@ -7,7 +7,7 @@ kind: task
 priority: P1
 labels: [ticket, config, profile, orchestration]
 created_at: 2026-06-05T17:33:22Z
-updated_at: 2026-06-05T17:35:08Z
+updated_at: 2026-06-05T18:15:02Z
 assignee: null
 legacy_ticket: null
 ---
@@ -24,7 +24,7 @@ The project should not introduce an arbitrary Role registry. The roles needed he
 - reviewer
 - investigator
 
-Each fixed role needs to select a Profile and, later, separate role-level system instruction, first launch prompt, and workflow binding. This is Ticket orchestration configuration, not a generic Profile replacement.
+Each fixed role needs to select a Profile and, later, a first launch prompt and workflow binding. Role-specific durable behavior should live in the selected Profile, not in this config file. This is Ticket orchestration configuration, not a generic Profile replacement.
 
 ## Goal
 
@@ -46,7 +46,6 @@ The MVP should establish the configuration file, fixed role schema, backend root
   - root path, defaulting to `work-items` relative to the workspace.
 - Support per-role configuration:
   - `profile` selector string;
-  - optional role system instruction prompt reference;
   - optional launch/initial prompt reference;
   - optional workflow slug/reference.
 - Keep `profile` selector syntax aligned with existing SpawnPod/profile selectors where possible:
@@ -57,8 +56,7 @@ The MVP should establish the configuration file, fixed role schema, backend root
   - `project:<name>`
   - unqualified registry selector when accepted by existing profile resolution.
 - Preserve the conceptual separation:
-  - Profile = Pod runtime recipe.
+  - Profile = Pod runtime recipe, including durable role behavior/system instruction when using role-specific profiles.
-  - role system instruction = role's durable behavior/boundary.
   - launch prompt = first committed task/user message for a specific Ticket/action.
   - workflow = procedural flow, later potentially stateful.
 - Validate known fields and reject/diagnose unknown roles or malformed fields.
@@ -67,7 +65,6 @@ The MVP should establish the configuration file, fixed role schema, backend root
 - Update the existing Ticket built-in feature adapter to use the configured backend root when available, falling back to `work-items`.
 - Expose a reusable resolver API for later Pod launch/TUI code:
   - role -> profile selector;
-  - role -> optional system instruction ref;
   - role -> optional launch prompt ref;
   - role -> optional workflow slug;
   - backend root.
@@ -94,31 +91,26 @@ root = "work-items"
 
 [roles.intake]
 profile = "project:intake"
-system_instruction = "$workspace/ticket/intake/system"
 launch_prompt = "$workspace/ticket/intake/launch"
 workflow = "ticket-intake-workflow"
 
 [roles.orchestrator]
 profile = "project:orchestrator"
-system_instruction = "$workspace/ticket/orchestrator/system"
 launch_prompt = "$workspace/ticket/orchestrator/launch"
 workflow = "ticket-orchestrator-routing"
 
 [roles.coder]
 profile = "inherit"
-system_instruction = "$workspace/ticket/coder/system"
 launch_prompt = "$workspace/ticket/coder/launch"
 workflow = "multi-agent-workflow"
 
 [roles.reviewer]
 profile = "project:reviewer"
-system_instruction = "$workspace/ticket/reviewer/system"
 launch_prompt = "$workspace/ticket/reviewer/launch"
 workflow = "multi-agent-workflow"
 
 [roles.investigator]
 profile = "inherit"
-system_instruction = "$workspace/ticket/investigator/system"
 launch_prompt = "$workspace/ticket/investigator/launch"
 workflow = "ticket-orchestrator-routing"
 ```
@@ -138,7 +130,7 @@ When `.yoi/ticket.config.toml` is absent:
   - coder: `multi-agent-workflow`
   - reviewer: `multi-agent-workflow`
   - investigator: `ticket-orchestrator-routing`
-- system instruction / launch prompt refs: none
+- launch prompt refs: none
 
 ## Acceptance criteria
 
@@ -149,13 +141,13 @@ When `.yoi/ticket.config.toml` is absent:
 - Relative backend root resolves against workspace root.
 - Backend root from config is used by the Ticket built-in feature adapter.
 - Role profile selector strings are retained/parsed in a form later usable by role launching code.
-- Optional `system_instruction`, `launch_prompt`, and `workflow` refs are parsed and exposed without trying to run a workflow engine.
+- Optional `launch_prompt` and `workflow` refs are parsed and exposed without trying to run a workflow engine.
 - Tests cover missing config, full config, partial role config, unknown role, relative backend root, and adapter backend-root usage.
 - `cargo test -p ticket` and focused `cargo test -p pod ticket --lib` pass.
 - `cargo check --workspace --all-targets`, `cargo fmt --check`, `git diff --check`, and `./tickets.sh doctor` pass.
 
 ## Follow-up tickets
 
-- `ticket-role-pod-launcher`: construct role-specific `SpawnPod` requests from Ticket context, role config, separated system instruction, launch prompt, workflow binding, and scope policy.
+- `ticket-role-pod-launcher`: construct role-specific `SpawnPod` requests from Ticket context, role config, selected Profile, launch prompt, workflow binding, and scope policy.
 - `tui-ticket-role-actions`: expose fixed Ticket role actions in TUI using the launcher.
 - Later workflow-state engine: persisted workflow phase/state, phase-specific allowed tools, and phase prompts committed to history before model use.

work-items/open/20260605-173322-ticket-config-role-profile-mapping/thread.md

@@ -43,4 +43,28 @@ Plan:
 6. Defer Pod role launching, TUI actions, and workflow-state/prompt sequencing to follow-up tickets.
 
 
+---
+
+<!-- event: decision author: hare at: 2026-06-05T18:15:02Z -->
+
+## Decision
+
+Decision update: remove `system_instruction` from the MVP `.yoi/ticket.config.toml` role schema.
+
+Rationale:
+
+- The selected Profile already owns durable role behavior and system/instruction configuration.
+- Adding `system_instruction` to Ticket role config would create an unclear override/merge boundary with Profile.
+- Ticket role config should bind fixed Ticket roles to Profile selectors, workflow refs, and launch prompts only.
+- Launch prompts remain useful here because they are per-action first committed task/user messages, unlike role-stable system behavior.
+
+Updated MVP role fields:
+
+- `profile`
+- optional `launch_prompt`
+- optional `workflow`
+
+If system-level role overlays are needed later, design them explicitly as a separate prompt/context ticket, likely with an overlay name and clear history/cache semantics. Do not add an implicit system instruction override in this ticket.
+
+
 ---