ticket: use base32 project record ids

2026-06-09 22:10:47 +09:00
parent 0803bc3725
commit 4203988d74
798 changed files with 477 additions and 105 deletions
@@ -0,0 +1,66 @@
+---
+title: "Deprecate umbrella Tickets"
+state: "closed"
+created_at: "2026-06-08T13:22:30Z"
+updated_at: "2026-06-09T02:04:40Z"
+queued_by: "workspace-panel"
+queued_at: "2026-06-09T01:14:14Z"
+---
+
+## 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: non-hierarchical 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, only for non-hierarchical dependency/related/blocking/replacement metadata;
+  - do not create parent/child, sub-ticket, umbrella, part-of, or other hierarchy/container relations as a replacement for umbrella Tickets;
+  - 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 or parent/child sub-ticket hierarchies 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 implementation details in `typed-ticket-relation-metadata`, but this Ticket fixes the policy that relation metadata must not reintroduce hierarchy/container semantics.
+- 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.
+- Development/workflow docs also state that parent/child, sub-ticket, part-of, or umbrella-style hierarchy relations should not be used as substitutes.
+- Intake/Planning guidance explains how to split broad requests without creating an umbrella progress container or sub-ticket hierarchy.
+- 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.