ticket: clarify panel and spawn authority tasks

.yoi/tickets/open/20260606-233520-workspace-panel-nonblocking-transitions/item.md

@@ -7,7 +7,7 @@ kind: task
 priority: P2
 labels: [tui, panel, ux, performance]
 created_at: 2026-06-06T23:35:20Z
-updated_at: '2026-06-08T00:02:48Z'
+updated_at: '2026-06-08T01:36:56Z'
 assignee: null
 legacy_ticket: null
 workflow_state: 'queued'

.yoi/tickets/open/20260606-233520-workspace-panel-nonblocking-transitions/thread.md

@@ -144,3 +144,42 @@ Escalate if:
 - Background reload ordering requires a durable scheduler/lease rather than a local UI guard.
 
 ---
+
+<!-- event: decision author: hare at: 2026-06-08T01:36:56Z -->
+
+## Decision
+
+## Binding decision: non-blocking transition scope
+
+This Ticket should implement non-blocking UX for three panel-local wait points:
+
+1. Process/Pod transition waits
+   - Panel-originated Pod spawn / restore / attach / open should show a visible progress state before awaiting runtime socket connect, restore, or spawn completion.
+   - Example states: `launching`, `restoring`, `attaching`.
+
+2. Composer submit/send confirmation waits
+   - Companion send, existing Ticket clarify/intake launch, and Ticket action dispatch should give immediate visible feedback that submit/dispatch started.
+   - On busy/rejected/failed send, preserve the draft where appropriate and surface a bounded diagnostic.
+   - On success, clear/update only according to the existing submit semantics.
+
+3. Initial panel first draw
+   - `yoi panel` should show an initial/loading/minimal panel before non-essential full snapshot, Orchestrator ensure/observe, or slow local runtime checks complete where practical.
+   - Background completion should update the panel state/diagnostics once ready.
+
+Implementation boundaries:
+
+- Reuse or extend existing local pending-task guards such as `PendingReload` where practical.
+- Prevent duplicate overlapping reload/transition tasks.
+- Preserve selected row and composer draft across background refreshes unless the submitted operation succeeds and intentionally clears the draft.
+- Keep enough synchronous checks to avoid presenting actions that would immediately violate known local state invariants.
+
+Non-goals are limited to adjacent changes that could naturally be mixed into this work:
+
+- Do not change Pod spawn/restore/attach authority, identity, or metadata semantics.
+- Do not change Ticket workflow-state/action semantics.
+- Do not introduce a durable scheduler/lease/background-job system.
+- Do not rewrite the entire TUI runtime loop.
+
+Everything else should not be listed as a non-goal unless the implementation discovers it is an actual adjacent risk. Unrelated exclusions add noise and should be avoided.
+
+---

.yoi/tickets/open/20260608-010442-split-direct-and-delegation-authority/item.md

@@ -0,0 +1,73 @@
+---
+id: '20260608-010442-split-direct-and-delegation-authority'
+slug: 'split-direct-and-delegation-authority'
+title: 'Split direct and delegation authority for Pods'
+status: 'open'
+kind: 'task'
+priority: 'P1'
+labels: ['pod', 'scope', 'delegation', 'orchestrator', 'security', 'profile']
+workflow_state: 'intake'
+created_at: '2026-06-08T01:04:42Z'
+updated_at: '2026-06-08T01:04:42Z'
+assignee: null
+legacy_ticket: null
+---
+
+## Background
+
+Orchestrator currently needs enough authority to delegate write scope to Coder Pods, because `SpawnPod` requires child scope to be a subset of the parent Pod's effective write scope. After project profiles were adjusted to make non-coder roles read-only by default, `project:orchestrator` became read-only and could no longer spawn Coder Pods with write scope.
+
+Observed active metadata for `yoi-orchestrator` showed only read scope:
+
+```json
+"scope": {
+  "allow": [
+    { "permission": "read", "target": "/home/hare/Projects/yoi", "recursive": true }
+  ]
+}
+```
+
+The immediate workaround was to edit the Pod metadata under the user data `pods/` directory to grant the Orchestrator write authority. That is not a good long-term boundary.
+
+The design issue is that Orchestrator may need *delegation authority* to give a child Coder a bounded write scope, while not necessarily needing broad direct write authority for its own tool calls. Today those two concepts are conflated in the same effective write scope.
+
+## Goal
+
+Separate a Pod's direct tool/write authority from its authority to delegate scoped write permissions to child Pods.
+
+## Requirements
+
+- Model direct filesystem/tool authority separately from delegation authority.
+  - Direct authority: what the Pod itself may do with tools such as Bash/Edit/Write/Ticket tools.
+  - Delegation authority: what scope the Pod may grant to child Pods through `SpawnPod`.
+- Allow Orchestrator-like roles to delegate bounded child write scopes without necessarily granting themselves arbitrary direct workspace write tools.
+- Preserve safety invariant that delegated child scope must be authorized by an explicit parent grant; do not allow arbitrary escalation.
+- Ensure explicit denies still apply correctly to both direct and delegated permissions.
+- Make the relationship between Profile scope, resolved Manifest scope, and delegation scope explicit and inspectable.
+- Update `SpawnPod` preflight/policy to validate against delegation grants rather than only direct effective write scope if the split is implemented.
+- Update profile authoring guidance so role profiles can express patterns such as:
+  - Companion: direct read, no write delegation.
+  - Intake/Reviewer: direct read, no write delegation by default.
+  - Orchestrator: limited direct writes for Ticket/project records if needed, plus delegation authority for child worktrees.
+  - Coder: direct write only within delegated worktree, no further delegation unless explicitly granted.
+- Avoid requiring users to hand-edit `~/.yoi/pods/<name>/metadata.json` to repair Orchestrator delegation authority.
+- Provide diagnostics when a Pod cannot spawn a child due to missing delegation authority, distinguishing it from missing direct write authority.
+
+## Design questions
+
+- Should delegation authority be represented as a separate `scope.delegate` / `scope.grant` section in Manifest/Profile resolution?
+- Should delegation grants be path-scoped independently from direct grants?
+- Should Ticket role launcher supply Orchestrator delegation grants based on workspace/worktree policy rather than broad workspace write?
+- How should restored older Pod metadata without delegation grants behave?
+- Should direct Ticket tool authority be separated from filesystem write authority in the same change, or remain a separate host-authority concern?
+
+## Acceptance criteria
+
+- Orchestrator can spawn a Coder with write scope to a child worktree without necessarily having broad direct write access to the whole workspace.
+- A Pod without delegation authority cannot grant write scope even if it has read access.
+- A Pod with direct write but no delegation grant cannot spawn write-capable children unless explicitly allowed.
+- Diagnostics distinguish direct permission denial from delegation-authority denial.
+- Profiles/manifests can express at least the Companion/Intake/Orchestrator/Coder/Reviewer patterns above.
+- Tests cover delegation validation, deny handling, restoration/metadata behavior, and SpawnPod error messages.
+- Relevant docs/profile examples are updated.
+- Focused tests, `cargo fmt --check`, `git diff --check`, and `target/debug/yoi ticket doctor` pass.

.yoi/tickets/open/20260608-010442-split-direct-and-delegation-authority/thread.md

@@ -0,0 +1,7 @@
+<!-- event: create author: LocalTicketBackend at: 2026-06-08T01:04:42Z -->
+
+## Created
+
+Created by LocalTicketBackend create.
+
+---

.yoi/tickets/open/20260608-011036-allow-spawnpod-child-workspace-cwd/item.md

@@ -0,0 +1,80 @@
+---
+id: '20260608-011036-allow-spawnpod-child-workspace-cwd'
+slug: 'allow-spawnpod-child-workspace-cwd'
+title: 'Allow SpawnPod to specify child workspace cwd'
+status: 'open'
+kind: 'task'
+priority: 'P2'
+labels: ['pod', 'spawn', 'workspace', 'worktree', 'orchestration']
+workflow_state: 'intake'
+created_at: '2026-06-08T01:10:36Z'
+updated_at: '2026-06-08T01:10:36Z'
+assignee: null
+legacy_ticket: null
+---
+
+## Background
+
+Current multi-agent/worktree workflows assume Coder/Reviewer Pods are spawned with the parent Orchestrator's cwd, usually the main workspace. Worktree isolation is enforced by delegated write scope and by task text instructing the Coder to run every Bash command with `cd <repo>/.worktree/<task-name> && ...`.
+
+Current workflow text explicitly says:
+
+```text
+Pod の cwd は main workspace のままになる。必ず作業対象が child worktree であることを明示し、Bash 実行時は毎回 cd <repo>/.worktree/<task-name> && ... させる。
+```
+
+This works but is fragile and awkward:
+
+- Coder can forget to `cd` before commands.
+- Tool cwd, profile/project discovery, AGENTS.md, and runtime workspace identity remain main-workspace biased.
+- Command snippets are noisy and error-prone.
+- Child worktree behavior is controlled by prompt discipline rather than runtime configuration.
+
+`SpawnPod` currently has no LLM-facing cwd/workspace field; internally child processes are launched with `Command::current_dir(self.spawner_pwd)`.
+
+## Goal
+
+Allow `SpawnPod` callers to specify the child Pod's runtime workspace/cwd, so implementation Pods can be started directly inside their child worktree while keeping explicit scope delegation and orchestration authority boundaries.
+
+## Requirements
+
+- Add a `SpawnPod` input field for child runtime workspace/cwd.
+  - Candidate names: `workspace`, `workspace_root`, or `cwd`.
+  - Prefer terminology aligned with `introduce-runtime-workspace-root-context` if that lands first.
+- When omitted, preserve current behavior: child cwd/workspace defaults to the spawner Pod's pwd.
+- When provided:
+  - Validate the path is absolute.
+  - Validate the path exists and is a directory.
+  - Validate the parent has at least read authority for the path.
+  - Set the child process `current_dir` to that path.
+  - Pass the runtime workspace context to the child Pod/profile resolver consistently if such context exists.
+- Ensure delegated scope remains explicit and independent from cwd.
+  - cwd does not grant permission by itself.
+  - Child write scope must still be supplied through `scope` and validated against parent/delegation authority.
+- Support the standard worktree case:
+  - child cwd/workspace = `<repo>/.worktree/<task-name>`;
+  - child read scope may include main repo if needed;
+  - child write scope is the child worktree or narrower.
+- Update `worktree-workflow` and `multi-agent-workflow` to prefer spawning Coder Pods with cwd/workspace set to the child worktree instead of telling them to `cd` every time.
+- Keep main workspace authority responsibilities explicit:
+  - ticket orchestration progress, final review/approval/close, and merge authority remain with Orchestrator/main workspace unless intentionally delegated.
+- Ensure child worktree `.yoi` sparse rules and `.yoi/memory` behavior remain intact.
+- Add diagnostics if requested cwd/workspace is not permitted or invalid.
+
+## Design questions
+
+- Should the field be named `cwd` for OS process current directory, or `workspace_root` to align with runtime identity/profile discovery?
+- Should `workspace_root` affect default Pod name if `name` is explicitly required by `SpawnPod`?
+- How should profile discovery behave when child cwd is a worktree containing tracked `.yoi` project records but not `.yoi/memory`?
+- Should reviewer Pods also use child worktree cwd by default, or keep main workspace cwd for comparing main vs branch? The workflow should state the preferred pattern.
+
+## Acceptance criteria
+
+- `SpawnPod` can launch a child Pod with process cwd set to an explicit child worktree path.
+- The child Pod's Bash tool starts fresh shells rooted at that child worktree without requiring `cd` in every command.
+- Omitting the field preserves current behavior.
+- Invalid/non-directory/out-of-scope cwd requests fail with clear errors.
+- cwd/workspace selection does not grant implicit read/write permission.
+- Worktree/multi-agent workflows are updated to use the new field for coder Pods.
+- Tests cover omitted/default cwd, explicit valid cwd, invalid cwd, and permission denial.
+- Focused tests, `cargo fmt --check`, `git diff --check`, and `target/debug/yoi ticket doctor` pass.

.yoi/tickets/open/20260608-011036-allow-spawnpod-child-workspace-cwd/thread.md

@@ -0,0 +1,7 @@
+<!-- event: create author: LocalTicketBackend at: 2026-06-08T01:10:36Z -->
+
+## Created
+
+Created by LocalTicketBackend create.
+
+---