---
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.
