ticket: update panel config planning

.yoi/tickets/closed/20260527-000017-tui-spawned-pod-panel/item.md

@@ -2,14 +2,15 @@
 id: 20260527-000017-tui-spawned-pod-panel
 slug: tui-spawned-pod-panel
 title: TUI: spawned child Pod の一覧と一時 attach
-status: pending
+status: closed
 kind: task
 priority: P2
 labels: [migrated]
 created_at: 2026-05-27T00:00:17Z
-updated_at: 2026-06-05T04:03:38Z
+updated_at: 2026-06-07T03:14:39Z
 assignee: null
 legacy_ticket: tickets/tui-spawned-pod-panel.md
+workflow_state: done
 ---
 
 ## Migration reference

.yoi/tickets/closed/20260527-000017-tui-spawned-pod-panel/resolution.md

@@ -0,0 +1,3 @@
+Closed as intentionally not planned.
+
+The old migrated spawned-Pod panel idea has been superseded by the workspace panel, Pod list/open/attach behavior, Ticket role launching, and the local role session registry. The remaining direction is not to revive this standalone spawned-child panel ticket. Future panel work should be tracked through the newer workspace panel / orchestration tickets.

.yoi/tickets/closed/20260527-000017-tui-spawned-pod-panel/thread.md

@@ -17,4 +17,23 @@ Current need is not a TUI panel for spawned Pods. The priority is Ticket-driven
 This ticket is not closed as technically invalid; it is moved out of the active multi-agent implementation path. Revisit only if direct child Pod visibility/attach UI becomes a concrete UX requirement.
 
 
+---
+
+<!-- event: state_changed author: hare at: 2026-06-07T03:14:39Z from: intake to: done reason: closed field: workflow_state -->
+
+## State changed
+
+Ticket closed; workflow_state set to done.
+
+
+---
+
+<!-- event: close author: hare at: 2026-06-07T03:14:39Z status: closed -->
+
+## Closed
+
+Closed as intentionally not planned.
+
+The old migrated spawned-Pod panel idea has been superseded by the workspace panel, Pod list/open/attach behavior, Ticket role launching, and the local role session registry. The remaining direction is not to revive this standalone spawned-child panel ticket. Future panel work should be tracked through the newer workspace panel / orchestration tickets.
+
 ---

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

@@ -0,0 +1,65 @@
+---
+id: 20260607-031439-ticket-init-role-profile-scaffold
+slug: ticket-init-role-profile-scaffold
+title: Scaffold explicit Ticket role profiles in init config
+status: open
+kind: task
+priority: P1
+labels: [ticket, config, init, profiles, panel]
+workflow_state: intake
+created_at: 2026-06-07T03:14:39Z
+updated_at: 2026-06-07T03:14:39Z
+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.

.yoi/tickets/open/20260607-031439-ticket-init-role-profile-scaffold/thread.md

@@ -0,0 +1,7 @@
+<!-- event: create author: LocalTicketBackend at: 2026-06-07T03:14:39Z -->
+
+## Created
+
+Created by LocalTicketBackend create.
+
+---

.yoi/tickets/open/20260607-031439-ticket-role-launch-config-strict-validation/item.md

@@ -0,0 +1,55 @@
+---
+id: 20260607-031439-ticket-role-launch-config-strict-validation
+slug: ticket-role-launch-config-strict-validation
+title: Strictly validate Ticket role launch config
+status: open
+kind: task
+priority: P1
+labels: [ticket, config, validation, panel, profiles]
+workflow_state: intake
+created_at: 2026-06-07T03:14:39Z
+updated_at: 2026-06-07T03:14:39Z
+assignee: null
+legacy_ticket: null
+---
+
+## Background
+
+Fallback audit found that Ticket backend config and Ticket role launch config are currently conflated. A backend-only `.yoi/ticket.config.toml` can be parsed and treated as usable by the panel, while missing role profiles are filled by role defaults that currently use `inherit`. Top-level Ticket role launches then fail late because `inherit` is not supported there.
+
+The desired policy is fail-closed runtime validation: role launch must require explicit concrete role profile configuration. Init/scaffold may write builtin selectors explicitly, but runtime must not silently invent them.
+
+## Goal
+
+Add strict validation for Ticket role launch configuration so Panel Intake / Orchestrator launch availability reflects whether role config is actually executable.
+
+## Requirements
+
+- Separate Ticket backend availability from Ticket role launch availability.
+  - Backend-only config may be usable for listing/showing Tickets.
+  - Role launch actions require fixed role config validation.
+- Add a role-launch validation path that rejects:
+  - missing role table for the target fixed role;
+  - missing role `profile`;
+  - `profile = "inherit"` for top-level Ticket role launch;
+  - role profile selectors that cannot be resolved for the launch path, where resolvability can be checked at this layer.
+- Panel Intake and workspace Orchestrator lifecycle must use the strict role-launch validation before presenting/attempting launch.
+- Diagnostics must be bounded and actionable, e.g. tell the user to run init/scaffold or set `[roles.<role>].profile` explicitly.
+- Keep `TicketRoleLaunchPlan::spawn_config` rejection of `inherit` as a final defensive check, but normal Panel/launcher paths should fail earlier with a clearer diagnostic.
+- Preserve explicit concrete builtin selectors when they are present in config; the target is not to ban builtin, only implicit fallback.
+- Do not silently convert missing roles to `builtin:default`, `default`, or `inherit` at runtime.
+
+## Non-goals
+
+- Implementing init/scaffold generation; that belongs to `ticket-init-role-profile-scaffold`.
+- Removing low-risk backend defaults such as the local Ticket backend root.
+- Redesigning model/provider fallback policy.
+- Allowing top-level Ticket role launch to resolve `inherit`.
+
+## Acceptance criteria
+
+- Backend-only `.yoi/ticket.config.toml` is not considered sufficient for Panel Intake / Orchestrator role launch.
+- Missing or `inherit` role profile produces an early actionable diagnostic before spawn.
+- Explicit concrete role profile config allows launch planning to proceed.
+- Tests cover backend-only config, partial role config, explicit `inherit`, and full concrete role config.
+- Existing Ticket backend listing/show behavior remains available when only backend config is present, unless a separate design intentionally changes that.

.yoi/tickets/open/20260607-031439-ticket-role-launch-config-strict-validation/thread.md

@@ -0,0 +1,7 @@
+<!-- event: create author: LocalTicketBackend at: 2026-06-07T03:14:39Z -->
+
+## Created
+
+Created by LocalTicketBackend create.
+
+---