ticket: refine ticket config role prompts
This commit is contained in:
parent
956394b4ac
commit
3edd68558f
|
|
@ -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<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 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
|
||||
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
- 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.
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
||||
|
||||
---
|
||||
|
|
|
|||
Loading…
Reference in New Issue
Block a user