ticket: record orchestration plan review dossier

.yoi/tickets/open/20260607-035710-ticket-orchestration-plan-tool/item.md

@@ -8,7 +8,7 @@ priority: P1
 labels: [ticket, orchestrator, planning, workflow, tools]
 workflow_state: 'inprogress'
 created_at: 2026-06-07T03:57:10Z
-updated_at: '2026-06-08T13:18:35Z'
+updated_at: '2026-06-08T13:23:45Z'
 assignee: null
 queued_by: 'workspace-panel'
 queued_at: '2026-06-08T11:21:13Z'

.yoi/tickets/open/20260607-035710-ticket-orchestration-plan-tool/thread.md

@@ -256,3 +256,86 @@ Coder-reported design summary:
 - Supported kinds include ordering, dependency, conflict, waiting/capacity, and accepted-plan records.
 
 ---
+
+<!-- event: review author: reviewer at: 2026-06-08T13:22:06Z status: approve -->
+
+## Review: approve
+
+Review result: approve.
+
+Evidence:
+- Inspected commit `b28b7759f51e7c9c7ccaaa15358b475e3889952c` and changed files `.yoi/workflow/ticket-orchestrator-routing.md`, `crates/pod/src/feature/builtin/ticket.rs`, `crates/ticket/src/lib.rs`, and `crates/ticket/src/tool.rs`.
+- Storage is per-Ticket `artifacts/orchestration-plan.jsonl`; records are JSONL under the Ticket backend root and validated by `ticket doctor`.
+- Backend/tool surface supports recording and querying by Ticket plus relation kind with kinds `before`, `after`, `blocked_by`, `blocks`, `conflicts_with`, `do_not_parallelize`, `waiting_capacity_note`, and `accepted_plan`.
+- Query tool is registered in the read-only Ticket tool set; record tool is kept out of read-only and available only in mutating/lifecycle tool sets.
+- The implementation stores bounded Ticket/project planning fields and does not change workflow_state, reorder queues, start work, implement a scheduler, or introduce broad relation-graph validation.
+- Orchestrator workflow guidance now tells queued routing to consult plan records and to record durable project-relevant plan decisions.
+
+Validation run from the review worktree passed:
+- `cargo fmt --check`
+- `git diff --check b28b7759f51e7c9c7ccaaa15358b475e3889952c^ b28b7759f51e7c9c7ccaaa15358b475e3889952c`
+- `cargo test -p ticket orchestration_plan`
+- `cargo test -p pod feature::builtin::ticket`
+- `cargo run -q -p yoi -- ticket doctor`
+- `cargo check --workspace`
+- `nix build .#yoi`
+
+---
+
+<!-- event: implementation_report author: orchestrator at: 2026-06-08T13:23:45Z -->
+
+## Implementation report
+
+Merge-ready dossier for human/orchestrator approval.
+
+Status:
+- Implementation branch: `ticket-orchestration-plan-tool`
+- Worktree: `.worktree/ticket-orchestration-plan-tool`
+- Commit under review: `b28b7759f51e7c9c7ccaaa15358b475e3889952c ticket: add orchestration plan tools`
+- Reviewer: `reviewer-ticket-orchestration-plan-tool`
+- Review result: approved; no blocking findings.
+
+Intent / invariant check:
+- Adds a lightweight Ticket-domain orchestration plan/note surface.
+- Does not implement a scheduler, background queue runner, dependency graph solver, TaskStore replacement, or typed Ticket relation metadata.
+- Does not change Ticket workflow_state semantics or move Tickets automatically.
+- Keeps local runtime/session/socket/raw model output out of git-tracked plan records.
+
+Implementation summary:
+- Adds typed `OrchestrationPlanKind` / `OrchestrationPlanRecord` support.
+- Stores records as per-Ticket `artifacts/orchestration-plan.jsonl` JSONL.
+- Adds backend append/query APIs, including query by Ticket id/slug and kind filter.
+- Adds LLM tools `TicketOrchestrationPlanRecord` and `TicketOrchestrationPlanQuery`.
+- Exposes query in read-only Ticket tools and record mutation only in mutating/lifecycle Ticket tools.
+- Adds validation and `ticket doctor` diagnostics for orchestration-plan artifacts.
+- Updates Orchestrator routing workflow guidance to query/record plan context before accepting queued Tickets.
+
+Reviewer evidence:
+- Required record classes are covered: before, after, blocked_by, blocks, conflicts_with, do_not_parallelize, waiting_capacity_note, accepted_plan.
+- Accepted-plan fields are bounded project-relevant fields (`summary`, `branch`, `worktree`, `role_plan`).
+- Validation rejects malformed records such as missing related Ticket for relation kinds, invalid accepted-plan combinations, missing waiting notes, oversized/single-line field violations, and artifact owner mismatch.
+- Capability split was checked in `crates/pod/src/feature/builtin/ticket.rs`.
+
+Validation evidence:
+- Coder reported pass:
+  - `cargo fmt --check`
+  - `git diff --check`
+  - `cargo run -q -p yoi -- ticket doctor`
+  - `cargo check --workspace`
+  - `cargo test -p ticket`
+  - `cargo test -p pod feature::builtin::ticket`
+  - `nix build .#yoi`
+- Reviewer independently ran and passed:
+  - `cargo fmt --check`
+  - `git diff --check b28b7759f51e7c9c7ccaaa15358b475e3889952c^ b28b7759f51e7c9c7ccaaa15358b475e3889952c`
+  - `cargo test -p ticket orchestration_plan`
+  - `cargo test -p pod feature::builtin::ticket`
+  - `cargo run -q -p yoi -- ticket doctor`
+  - `cargo check --workspace`
+  - `nix build .#yoi`
+
+Residual risks / notes:
+- This is intentionally execution-plan metadata, not intrinsic project-level Ticket relations. `typed-ticket-relation-metadata` remains separate.
+- Final merge/close/cleanup is intentionally not performed here without explicit merge approval.
+
+---

.yoi/tickets/open/20260608-072732-typed-ticket-relation-metadata/item.md

@@ -8,7 +8,7 @@ priority: 'P1'
 labels: ['ticket', 'relations', 'planning', 'panel', 'orchestrator']
 workflow_state: planning
 created_at: '2026-06-08T07:27:32Z'
-updated_at: '2026-06-08T07:28:29Z'
+updated_at: '2026-06-08T13:22:42Z'
 assignee: null
 ---
 

.yoi/tickets/open/20260608-072732-typed-ticket-relation-metadata/thread.md

@@ -35,3 +35,25 @@ Considerations:
 The implementation should decide whether unresolved dependencies make Queue invalid, require confirmation, or allow Queue with a visible blocked state. The important requirement is that dependency relation metadata is not only an Orchestrator input; it should also inform the human Queue gate.
 
 ---
+
+<!-- event: decision author: hare at: 2026-06-08T13:22:42Z -->
+
+## Decision
+
+## Design consideration: avoid recreating umbrella Tickets through parent/child relations
+
+Umbrella Tickets are being deprecated as long-lived broad progress containers. This affects relation design.
+
+Parent/child relation kinds can easily recreate the umbrella pattern if they imply that one Ticket is a broad container whose close condition depends on manually inspecting child sufficiency. Therefore relation kinds such as `parent` / `child` should be reconsidered before implementation.
+
+Design guidance:
+
+- Keep concrete dependency/blocking relations distinct from broad grouping.
+- Prefer `Objective` records for medium-term goal/strategy grouping.
+- If decomposition needs to be represented, consider whether a relation such as `derived_from`, `split_from`, or `related` is safer than `parent` / `child`.
+- Do not make relation metadata imply that a broad umbrella Ticket should remain open as a progress container.
+- Any relation kind that approximates parent/child must define clear close semantics and avoid ambiguity around whether all child work is sufficient.
+
+This Ticket should explicitly decide whether to include parent/child relations at all in the first version.
+
+---

.yoi/tickets/open/20260608-132230-deprecate-umbrella-tickets/item.md

@@ -0,0 +1,69 @@
+---
+id: '20260608-132230-deprecate-umbrella-tickets'
+slug: 'deprecate-umbrella-tickets'
+title: 'Deprecate umbrella Tickets'
+status: 'open'
+kind: 'task'
+priority: 'P2'
+labels: ['ticket', 'workflow', 'documentation', 'planning']
+workflow_state: 'planning'
+created_at: '2026-06-08T13:22:30Z'
+updated_at: '2026-06-08T13:22:30Z'
+assignee: null
+---
+
+## Background
+
+Umbrella Tickets have been used as broad containers that split into several implementation Tickets. In practice this creates ambiguous lifecycle semantics:
+
+- it is unclear when the umbrella itself should be closed;
+- child Tickets may be complete while the umbrella remains open;
+- AI-created splits require the user to re-open the umbrella and inspect whether all child work is truly sufficient;
+- the umbrella can become a mix of initial request, progress container, split decision log, Objective-like strategy context, and completion proxy.
+
+The `workspace-panel-orchestrator-queue-automation` Ticket exposed this problem: core child slices were completed, but the umbrella remained open and its close condition was not obvious.
+
+The emerging model is:
+
+- Ticket: implementable/completable work item shaped by Intake/Planning.
+- Objective: medium-term goal, motivation, strategy, and success criteria.
+- Typed Ticket relations: dependency/related/supersedes/blocking metadata between concrete Tickets.
+- OrchestrationPlan: current execution planning for queued/in-progress work.
+
+Umbrella Tickets do not fit cleanly into that model.
+
+## Goal
+
+Deprecate the use of umbrella Tickets as broad multi-Ticket containers, and update workflow/docs so future work is represented by concrete Tickets plus Objectives/relations instead.
+
+## Requirements
+
+- Document that new umbrella Tickets should not be created for broad multi-Ticket efforts.
+- State that Tickets should be concrete work items that can be implemented, reviewed, validated, and closed on their own terms.
+- When a broad request must be split:
+  - create concrete implementable Tickets for the slices;
+  - record the split decision in the relevant Ticket/Objective/thread context;
+  - use an Objective for medium-term goal/strategy context when needed;
+  - use typed Ticket relations, once available, for dependency/related/blocking metadata;
+  - do not keep a separate umbrella Ticket open merely as a progress container.
+- Clarify the migration/cleanup path for existing umbrella Tickets.
+  - They may be closed as superseded/decomposed once concrete follow-up Tickets/Objective context exist.
+  - Closing an umbrella in this way does not mean every related future concern is complete; it means the umbrella container role is retired.
+  - The close resolution should list completed child/concrete Tickets and remaining follow-up Tickets/Objectives.
+- Update workflow guidance for Intake/Planning and Orchestrator so they avoid creating umbrella Tickets during split/refinement.
+- Ensure this does not block creating an initial planning Ticket when a user explicitly asks for a concrete design/investigation work item; the deprecated pattern is the long-lived umbrella progress container.
+
+## Non-goals
+
+- Designing typed Ticket relation metadata; keep relation-kind decisions in `typed-ticket-relation-metadata`.
+- Implementing Objective records; covered by `objective-records-for-medium-term-goals`.
+- Rewriting every historical umbrella immediately.
+- Removing thread history from existing umbrella Tickets.
+
+## Acceptance criteria
+
+- Development/workflow docs explain that umbrella Tickets are deprecated and should not be created for new broad efforts.
+- Intake/Planning guidance explains how to split broad requests without creating an umbrella progress container.
+- Orchestrator guidance explains how to close or retire existing umbrella Tickets once concrete Tickets/Objectives carry the remaining work.
+- At least `workspace-panel-orchestrator-queue-automation` has a clear migration/close recommendation recorded or is handled in a follow-up.
+- `target/debug/yoi ticket doctor` and `git diff --check` pass.

.yoi/tickets/open/20260608-132230-deprecate-umbrella-tickets/thread.md

@@ -0,0 +1,7 @@
+<!-- event: create author: LocalTicketBackend at: 2026-06-08T13:22:30Z -->
+
+## 作成
+
+LocalTicketBackend によって作成されました。
+
+---