yoi/.yoi/tickets/closed/20260607-031439-ticket-init-role-profile-scaffold/item.md

id	slug	title	status	kind	priority	labels	workflow_state	created_at	updated_at	assignee	legacy_ticket
20260607-031439-ticket-init-role-profile-scaffold	ticket-init-role-profile-scaffold	Scaffold explicit Ticket role profiles in init config	closed	task	P1	ticket config init profiles panel	done	2026-06-07T03:14:39Z	2026-06-07T04:05:15Z	null	null

Background

Fallback audit found that .yoi/ticket.config.toml can currently contain only backend settings. In that case Ticket config parsing succeeds, but fixed Ticket role profiles fall back to inherit, which top-level Panel/CLI Ticket role launch rejects. This causes Panel Intake / Orchestrator launch failures such as:

Ticket role profile 'inherit' cannot be used for top-level launch execution; configure a concrete role profile selector

The desired policy is to distinguish explicit builtin preset selection from implicit runtime fallback. It is acceptable for init/scaffold to generate a working config that explicitly names builtin presets. It is not acceptable for runtime to silently fill missing role config with builtin/default/inherit.

Goal

Make project init/scaffold generate a complete, explicit Ticket role configuration suitable for Panel Intake and Orchestrator launch.

Requirements

• Locate or introduce the init/scaffold path that creates .yoi/ticket.config.toml for a workspace.
• Generate explicit backend config:
  • [backend] provider = "builtin:yoi_local"
  • root = ".yoi/tickets"
• Generate explicit fixed role tables for at least:
  • [roles.intake]
  • [roles.orchestrator]
  • [roles.coder]
  • [roles.reviewer]
  • [roles.investigator]
• Each role table must include a concrete profile, not inherit.
  • Minimal initial implementation may explicitly use builtin:default if role-specific builtin profiles are not ready yet.
  • If role-specific builtin profiles are introduced, use explicit selectors such as builtin:ticket-intake, builtin:ticket-orchestrator, etc.
• Each role table should include explicit workflow for readability and reproducibility:
  • intake: ticket-intake-workflow
  • orchestrator: ticket-orchestrator-routing
  • coder/reviewer: multi-agent-workflow or the agreed workflow for those roles
  • investigator: the agreed read/investigation workflow
• Generated config must pass Ticket role launch validation for Panel Intake and workspace Orchestrator.
• Do not implement runtime fallback from missing role profiles to builtin presets in this ticket.

Non-goals

• Making builtin role profiles an implicit runtime fallback.
• Allowing inherit for top-level Ticket role launch.
• Redesigning provider/model fallback policy.
• Implementing full Companion lifecycle.

Acceptance criteria

• A newly initialized workspace has explicit concrete Ticket role profiles in .yoi/ticket.config.toml.
• Panel Intake launch planning does not fail because generated role profile is inherit or missing.
• Workspace Orchestrator launch planning does not fail because generated role profile is inherit or missing.
• Tests cover generated config shape and successful role-launch validation against the scaffolded config.