diff --git a/work-items/open/20260605-173322-ticket-config-role-profile-mapping/artifacts/investigation-plan.md b/work-items/open/20260605-173322-ticket-config-role-profile-mapping/artifacts/investigation-plan.md index 7d4763e7..a5fc9167 100644 --- a/work-items/open/20260605-173322-ticket-config-role-profile-mapping/artifacts/investigation-plan.md +++ b/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. -- Ticket role config: binds a fixed Ticket role to a Profile selector and optional prompt/workflow refs. -- System instruction: role's durable behavior/boundary. +- 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 launch prompt/workflow refs. - 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, pub launch_prompt: Option, 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 role system instruction separately from initial launch prompt. +- Resolve selected Profile using existing Profile registry; role-specific system behavior comes from that Profile. +- 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 diff --git a/work-items/open/20260605-173322-ticket-config-role-profile-mapping/item.md b/work-items/open/20260605-173322-ticket-config-role-profile-mapping/item.md index da855595..6e58227c 100644 --- a/work-items/open/20260605-173322-ticket-config-role-profile-mapping/item.md +++ b/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:` - unqualified registry selector when accepted by existing profile resolution. - Preserve the conceptual separation: - - Profile = Pod runtime recipe. - - role system instruction = role's durable behavior/boundary. + - Profile = Pod runtime recipe, including durable role behavior/system instruction when using role-specific profiles. - 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. diff --git a/work-items/open/20260605-173322-ticket-config-role-profile-mapping/thread.md b/work-items/open/20260605-173322-ticket-config-role-profile-mapping/thread.md index de77bf42..d28a697d 100644 --- a/work-items/open/20260605-173322-ticket-config-role-profile-mapping/thread.md +++ b/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. +--- + + + +## 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. + + ---