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

```text
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.
