diff --git a/.yoi/tickets/open/20260608-072732-typed-ticket-relation-metadata/item.md b/.yoi/tickets/open/20260608-072732-typed-ticket-relation-metadata/item.md index 0c6db3a1..16ed32b7 100644 --- a/.yoi/tickets/open/20260608-072732-typed-ticket-relation-metadata/item.md +++ b/.yoi/tickets/open/20260608-072732-typed-ticket-relation-metadata/item.md @@ -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. diff --git a/.yoi/tickets/open/20260608-072732-typed-ticket-relation-metadata/thread.md b/.yoi/tickets/open/20260608-072732-typed-ticket-relation-metadata/thread.md index ab8b926d..b7d53376 100644 --- a/.yoi/tickets/open/20260608-072732-typed-ticket-relation-metadata/thread.md +++ b/.yoi/tickets/open/20260608-072732-typed-ticket-relation-metadata/thread.md @@ -57,3 +57,89 @@ Design guidance: This Ticket should explicitly decide whether to include parent/child relations at all in the first version. --- + + + +## 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. + +--- + + + +## 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 を混同しないこと。 + +--- + + + +## 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 はない。 + +--- + + + +## State changed + +Intake refinement により、relation kind、inverse relation の扱い、queue gate 境界、binding invariants、implementation latitude、escalation conditions が揃ったため ready に遷移する。 + +--- diff --git a/.yoi/tickets/open/20260608-132230-deprecate-umbrella-tickets/item.md b/.yoi/tickets/open/20260608-132230-deprecate-umbrella-tickets/item.md index 4167ecd7..52082538 100644 --- a/.yoi/tickets/open/20260608-132230-deprecate-umbrella-tickets/item.md +++ b/.yoi/tickets/open/20260608-132230-deprecate-umbrella-tickets/item.md @@ -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. diff --git a/.yoi/tickets/open/20260608-132230-deprecate-umbrella-tickets/thread.md b/.yoi/tickets/open/20260608-132230-deprecate-umbrella-tickets/thread.md index af67e1e8..3ba50484 100644 --- a/.yoi/tickets/open/20260608-132230-deprecate-umbrella-tickets/thread.md +++ b/.yoi/tickets/open/20260608-132230-deprecate-umbrella-tickets/thread.md @@ -58,3 +58,53 @@ Validation は既存 acceptance criteria の通り、`target/debug/yoi ticket do Intake refinement により、意図・受け入れ条件・binding decisions / invariants・implementation latitude・escalation conditions が揃ったため ready に遷移します。 --- + + + +## 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. + +--- + + + +## State changed + +Ticket を `workspace-panel` が queued にしました。 + + +--- + + + +## 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. + +---