67 lines
4.3 KiB
Markdown
67 lines
4.3 KiB
Markdown
---
|
|
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.
|