ticket: defer umbrella deprecation routing
This commit is contained in:
parent
d50e6236f8
commit
bcf9e2e58c
|
|
@ -1,14 +1,14 @@
|
|||
---
|
||||
id: '20260608-072732-typed-ticket-relation-metadata'
|
||||
slug: 'typed-ticket-relation-metadata'
|
||||
title: 'Add typed Ticket relation metadata'
|
||||
title: 'Add non-hierarchical typed Ticket relations'
|
||||
status: 'open'
|
||||
kind: 'task'
|
||||
priority: 'P1'
|
||||
labels: ['ticket', 'relations', 'planning', 'panel', 'orchestrator']
|
||||
workflow_state: planning
|
||||
workflow_state: 'ready'
|
||||
created_at: '2026-06-08T07:27:32Z'
|
||||
updated_at: '2026-06-08T13:22:42Z'
|
||||
updated_at: '2026-06-09T01:02:17Z'
|
||||
assignee: null
|
||||
---
|
||||
|
||||
|
|
@ -20,7 +20,7 @@ Ticket orchestration needs two distinct kinds of cross-Ticket coordination:
|
|||
- this feature depends on that Ticket;
|
||||
- this problem must be resolved before that Ticket is meaningful;
|
||||
- this Ticket blocks another Ticket;
|
||||
- this is an umbrella/child or related/superseding Ticket relationship.
|
||||
- this Ticket is related to, supersedes, or duplicates another Ticket.
|
||||
|
||||
2. Orchestrator execution-plan decisions:
|
||||
- these two Tickets are conceptually independent but touch conflicting code paths, so do not run them in parallel;
|
||||
|
|
@ -34,18 +34,22 @@ This Ticket covers the first category: typed, durable Ticket-to-Ticket relations
|
|||
|
||||
## Goal
|
||||
|
||||
Add typed Ticket relation metadata for project-level dependencies, blockers, hierarchy, and related/superseding links, stored with the Ticket system and visible through CLI/Panel/Ticket APIs independently of Orchestrator runtime plans.
|
||||
Add typed Ticket relation metadata for project-level dependencies, blockers, related links, superseding links, and duplication links, stored with the Ticket system and visible through CLI/Panel/Ticket APIs independently of Orchestrator runtime plans. Do not model hierarchy, umbrella, parent/child, sub-ticket, or part-of relations.
|
||||
|
||||
## Requirements
|
||||
|
||||
- Provide a typed way to record Ticket-to-Ticket relations as project records.
|
||||
- Support at least these relation kinds, with final naming to be decided during implementation:
|
||||
- Support at least these non-hierarchical relation kinds, with final naming to be decided during implementation:
|
||||
- `depends_on`: this Ticket requires another Ticket to be completed/resolved first;
|
||||
- `blocks`: this Ticket blocks another Ticket;
|
||||
- `parent` / `child`: umbrella or decomposition relationship;
|
||||
- `related`: non-blocking relation worth showing;
|
||||
- `supersedes` / `superseded_by` or `duplicate_of`: replacement/duplication relationship.
|
||||
- Decide whether inverse relations such as `blocked_by`, `children`, and `superseded_by` are stored explicitly or derived from forward relations.
|
||||
- Do not support hierarchy/container relation kinds in the first version:
|
||||
- no `parent` / `child`;
|
||||
- no `sub-ticket`;
|
||||
- no `umbrella`;
|
||||
- no `part_of` / `contains` decomposition semantics.
|
||||
- Decide whether inverse non-hierarchical relations such as `blocked_by` and `superseded_by` are stored explicitly or derived from forward relations.
|
||||
- Store relations in the Ticket backend in a durable, git-trackable form.
|
||||
- Prefer a typed field/artifact/event model that can be validated by the Ticket backend.
|
||||
- Avoid relying only on freeform Markdown thread text for mechanical relationships.
|
||||
|
|
@ -60,7 +64,8 @@ Add typed Ticket relation metadata for project-level dependencies, blockers, hie
|
|||
- closed/resolved dependencies should be distinguishable from open blockers.
|
||||
- Integrate with Intake/Planning:
|
||||
- Intake/Planning should be able to record known project-level relations when materializing/refining a Ticket;
|
||||
- duplicate/supersedes/parent-child relations should be available for Ticket shaping and review.
|
||||
- dependency/blocking/related/supersedes/duplicate relations should be available for Ticket shaping and review;
|
||||
- Intake/Planning must not create parent/child or umbrella-style relations as a replacement for umbrella Tickets.
|
||||
- Integrate with Orchestrator routing as input, not as runtime plan state:
|
||||
- Orchestrator should consult Ticket relations before accepting queued work;
|
||||
- unresolved `depends_on` / blocking relations should prevent acceptance or return the Ticket to planning/blocked with a visible reason;
|
||||
|
|
@ -75,6 +80,7 @@ Add typed Ticket relation metadata for project-level dependencies, blockers, hie
|
|||
- Implementing a full dependency graph scheduler.
|
||||
- Making every related Ticket relation block queuing automatically.
|
||||
- Encoding transient local Pod/worktree claims in git-tracked Ticket metadata.
|
||||
- Representing Ticket hierarchy, umbrella containers, parent/child decomposition, sub-tickets, or part-of grouping.
|
||||
|
||||
## Acceptance criteria
|
||||
|
||||
|
|
@ -85,7 +91,9 @@ Add typed Ticket relation metadata for project-level dependencies, blockers, hie
|
|||
- Intake/Planning workflow guidance explains when to create project-level relations.
|
||||
- Orchestrator routing guidance treats these relations as input constraints distinct from OrchestrationPlan runtime decisions.
|
||||
- Documentation clearly distinguishes:
|
||||
- `depends_on` / `blocks` as Ticket relation metadata;
|
||||
- `depends_on` / `blocks` as non-hierarchical Ticket relation metadata;
|
||||
- `related` / `supersedes` / `duplicate_of` as non-blocking or replacement metadata;
|
||||
- unsupported hierarchy/container semantics such as parent/child, umbrella, sub-ticket, and part-of;
|
||||
- `do_not_parallelize` / capacity / current planned order as OrchestrationPlan execution decisions;
|
||||
- Pod/session/worktree ownership as local runtime claims.
|
||||
- Focused tests, `target/debug/yoi ticket doctor`, `cargo fmt --check`, and `git diff --check` pass.
|
||||
|
|
|
|||
|
|
@ -57,3 +57,89 @@ Design guidance:
|
|||
This Ticket should explicitly decide whether to include parent/child relations at all in the first version.
|
||||
|
||||
---
|
||||
|
||||
<!-- event: decision author: hare at: 2026-06-09T01:00:53Z -->
|
||||
|
||||
## Decision
|
||||
|
||||
## Decision: relation first version excludes hierarchy
|
||||
|
||||
The first version of typed Ticket relations must not include hierarchy/container relation kinds. Exclude:
|
||||
|
||||
- `parent` / `child`;
|
||||
- `sub-ticket`;
|
||||
- `umbrella`;
|
||||
- `part_of` / `contains`.
|
||||
|
||||
This avoids recreating umbrella Tickets under another schema. The relation feature should focus on non-hierarchical direct relationships: dependency, blocking, related, supersedes, duplicate/replacement. Medium-term grouping belongs to Objective records, not Ticket hierarchy.
|
||||
|
||||
---
|
||||
|
||||
<!-- event: decision author: intake at: 2026-06-09T01:02:08Z -->
|
||||
|
||||
## Decision
|
||||
|
||||
## Intake refinement: ready にするための設計決定
|
||||
|
||||
この Ticket は新規 Ticket ではなく、既存 Ticket の refinement として扱う。Orchestrator が routing できるよう、未決定だった relation kind / inverse / queue gate の境界を次の通り固定する。
|
||||
|
||||
### Readiness
|
||||
|
||||
- readiness: implementation_ready
|
||||
- risk_flags: [ticket-schema, workflow-state, panel, orchestrator-routing]
|
||||
|
||||
### Binding decisions / invariants
|
||||
|
||||
- first version の保存対象 relation kind は非階層 relation のみに限定する。
|
||||
- `depends_on`: この Ticket が対象 Ticket の完了/解決を必要とする。
|
||||
- `blocks`: この Ticket が対象 Ticket の実行/完了を妨げる。
|
||||
- `related`: 非 blocking の関連。
|
||||
- `supersedes`: この Ticket が対象 Ticket を置き換える。
|
||||
- `duplicate_of`: この Ticket が対象 Ticket の duplicate である。
|
||||
- `blocked_by` / `superseded_by` / duplicate 逆一覧などの inverse view は保存済み forward relation から導出する。first version では inverse relation kind を別途保存して整合性を二重管理しない。
|
||||
- `parent` / `child` / `sub-ticket` / `umbrella` / `part_of` / `contains` は first version で扱わない。Ticket relation metadata で umbrella Ticket を再作成しない。
|
||||
- relation metadata は project-level Ticket record であり、Pod/session claim、worktree、branch ownership、coder/reviewer assignment、capacity、current planned order、`do_not_parallelize` を保存しない。これらは local role session registry / OrchestrationPlan / Pod metadata の責務に残す。
|
||||
- Queue gate は unresolved blocking relation を無視してはならない。
|
||||
- 対象 Ticket の unresolved `depends_on` と incoming unresolved `blocks` は、Panel/CLI の `ready -> queued` 操作で visible reason 付きの block/diagnostic にする。
|
||||
- `related` は queue を block しない。
|
||||
- `supersedes` / `duplicate_of` は replacement/duplicate として visible diagnostic にする。自動的に全 relation を blocking 扱いしない。
|
||||
- Orchestrator は `queued -> inprogress` acceptance 時に relation を再確認する。Queue gate の判定は Orchestrator の再確認を省略する根拠ではない。
|
||||
|
||||
### Implementation latitude
|
||||
|
||||
- durable storage の具体形は、typed backend が検証でき、git-trackable で、`TicketShow` / `ticket doctor` / Panel summary から読める限り実装側で選んでよい。例: `item.md` frontmatter の typed field、または Ticket artifacts 配下の typed record。
|
||||
- CLI の具体的な relation 操作名・オプション名、Panel 上の短い表示文言、cycle 検出の bounded な実装方式は実装側で選んでよい。
|
||||
- `depends_on` と `blocks` は利用者が自然な方向で記録できる relation kind として両方残すが、表示・validation では inverse view を導出して重複/矛盾を診断してよい。
|
||||
|
||||
### Escalation conditions
|
||||
|
||||
- hierarchy/container semantics を追加したくなった場合。
|
||||
- inverse relation を保存しないと実装できない設計にしたくなった場合。
|
||||
- queue gate を unresolved dependency でも通常 queue 可能にしたくなった場合。
|
||||
- relation metadata に Pod/session/worktree/assignment/capacity/current-batch order を保存したくなった場合。
|
||||
- public Ticket schema または role workflow guidance で relation kind 名を上記から変更したくなった場合。
|
||||
|
||||
### Validation focus
|
||||
|
||||
- `ticket doctor` が dangling reference、invalid kind、self relation、obvious dependency/blocking cycle を bounded diagnostic として検出すること。
|
||||
- `TicketShow` が forward relation と derived inverse view を理解できる形で表示すること。
|
||||
- Panel/CLI が unresolved dependency/blocker を queue 前に visible にすること。
|
||||
- Intake/Planning と Orchestrator guidance が project-level relation metadata と OrchestrationPlan runtime decision を混同しないこと。
|
||||
|
||||
---
|
||||
|
||||
<!-- event: intake_summary author: intake at: 2026-06-09T01:02:17Z -->
|
||||
|
||||
## Intake summary
|
||||
|
||||
既存 Ticket を refinement し、typed Ticket relation metadata の first version を非階層 relation に限定して implementation_ready にした。保存 relation kind は `depends_on` / `blocks` / `related` / `supersedes` / `duplicate_of`、inverse view は forward relation から導出し、`parent` / `child` / `sub-ticket` / `umbrella` / `part_of` / `contains` は扱わない。unresolved `depends_on` と incoming unresolved `blocks` は Panel/CLI queue gate で visible block/diagnostic にし、Orchestrator は acceptance 時に再確認する。runtime claims や OrchestrationPlan execution decisions は relation metadata に保存しない。blocking open questions はない。
|
||||
|
||||
---
|
||||
|
||||
<!-- event: state_changed author: intake at: 2026-06-09T01:02:17Z from: planning to: ready reason: intake_ready field: workflow_state -->
|
||||
|
||||
## State changed
|
||||
|
||||
Intake refinement により、relation kind、inverse relation の扱い、queue gate 境界、binding invariants、implementation latitude、escalation conditions が揃ったため ready に遷移する。
|
||||
|
||||
---
|
||||
|
|
|
|||
|
|
@ -6,10 +6,12 @@ status: 'open'
|
|||
kind: 'task'
|
||||
priority: 'P2'
|
||||
labels: ['ticket', 'workflow', 'documentation', 'planning']
|
||||
workflow_state: 'ready'
|
||||
workflow_state: 'queued'
|
||||
created_at: '2026-06-08T13:22:30Z'
|
||||
updated_at: '2026-06-09T00:16:38Z'
|
||||
updated_at: '2026-06-09T01:14:47Z'
|
||||
assignee: null
|
||||
queued_by: 'workspace-panel'
|
||||
queued_at: '2026-06-09T01:14:14Z'
|
||||
---
|
||||
|
||||
## Background
|
||||
|
|
@ -27,7 +29,7 @@ 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.
|
||||
- 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.
|
||||
|
|
@ -44,18 +46,19 @@ Deprecate the use of umbrella Tickets as broad multi-Ticket containers, and upda
|
|||
- 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;
|
||||
- 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 during split/refinement.
|
||||
- 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-kind decisions in `typed-ticket-relation-metadata`.
|
||||
- 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.
|
||||
|
|
@ -63,7 +66,8 @@ Deprecate the use of umbrella Tickets as broad multi-Ticket containers, and upda
|
|||
## 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.
|
||||
- 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.
|
||||
|
|
|
|||
|
|
@ -58,3 +58,53 @@ Validation は既存 acceptance criteria の通り、`target/debug/yoi ticket do
|
|||
Intake refinement により、意図・受け入れ条件・binding decisions / invariants・implementation latitude・escalation conditions が揃ったため ready に遷移します。
|
||||
|
||||
---
|
||||
|
||||
<!-- event: decision author: hare at: 2026-06-09T01:00:46Z -->
|
||||
|
||||
## Decision
|
||||
|
||||
## Decision: no hierarchy relations
|
||||
|
||||
Umbrella Ticket deprecation also means not replacing umbrellas with Ticket hierarchy relations.
|
||||
|
||||
Do not introduce or use these relation concepts for current Ticket work:
|
||||
|
||||
- `parent` / `child`;
|
||||
- `sub-ticket`;
|
||||
- `umbrella`;
|
||||
- `part_of` / `contains` decomposition semantics.
|
||||
|
||||
Concrete split work should become separate implementable Tickets. Medium-term context belongs in Objectives. Ticket relations should stay non-hierarchical: dependency, blocking, related, supersedes, duplicate/replacement, and similar direct relations.
|
||||
|
||||
---
|
||||
|
||||
<!-- event: state_changed author: workspace-panel at: 2026-06-09T01:14:14Z from: ready to: queued reason: queued field: workflow_state -->
|
||||
|
||||
## State changed
|
||||
|
||||
Ticket を `workspace-panel` が queued にしました。
|
||||
|
||||
|
||||
---
|
||||
|
||||
<!-- event: decision author: orchestrator at: 2026-06-09T01:14:47Z -->
|
||||
|
||||
## Decision
|
||||
|
||||
Routing decision: defer_pending_policy_merge
|
||||
|
||||
This Ticket is queued and appears implementation-ready, but I am intentionally not accepting it to `inprogress` yet.
|
||||
|
||||
Reason:
|
||||
- There is an approved merge-ready workflow/docs branch pending: `orchestrator-return-to-planning-context-policy` at commit `8576615`.
|
||||
- `deprecate-umbrella-tickets` is also a workflow/docs/planning policy cleanup and is likely to touch adjacent files such as Orchestrator/Intake/Planning guidance and work-item docs.
|
||||
- Running it before the pending policy branch is merged or otherwise resolved would create unnecessary conflict/review risk across the same maintained policy surfaces.
|
||||
|
||||
State decision:
|
||||
- Leave this Ticket `queued`.
|
||||
- Do not create a worktree or spawn a coder yet.
|
||||
|
||||
Next action:
|
||||
- After `orchestrator-return-to-planning-context-policy` is merged/closed/cleaned up or explicitly held back, re-read this Ticket and accept it from queued if still unblocked.
|
||||
|
||||
---
|
||||
|
|
|
|||
Loading…
Reference in New Issue
Block a user