Hare/yoi
1
1
Fork 0
Code Actions Packages Releases Activity
3edd68558f
yoi/work-items/open/20260605-173322-ticket-config-role-profile-mapping/thread.md

2.6 KiB
Raw Blame History

Created

Created by tickets.sh create.

Decision

Decision: implement .yoi/ticket.config.toml as Ticket orchestration configuration with fixed Ticket role slots.

Use fixed roles, not an arbitrary Role registry:

  • intake
  • orchestrator
  • coder
  • reviewer
  • investigator

The config maps these fixed Ticket roles to Profile selector strings and optional role system instruction / launch prompt / workflow refs. This keeps Profile as the Pod runtime recipe while Ticket orchestration owns the role-to-profile binding.

The first implementation should parse/validate config and wire the configured backend root into Ticket tools. It should not spawn Pods, add TUI actions, or implement a stateful workflow engine yet.

Detailed investigation and implementation plan: artifacts/investigation-plan.md.

Plan

Plan:

  1. Add Ticket config model/parser, probably in crates/ticket/src/config.rs, using lightweight string wrapper types for Profile/prompt/workflow refs so ticket does not depend on pod.
  2. Parse .yoi/ticket.config.toml from a workspace root, with defaults when missing.
  3. Support [backend] local root and fixed [roles.*] sections.
  4. Wire the configured backend root into crates/pod/src/feature/builtin/ticket.rs so Ticket tools no longer hard-code <workspace>/work-items.
  5. Add focused tests in ticket and pod.
  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.