yoi/.yoi/tickets/20260608-072732-001/thread.md

Created

Created by LocalTicketBackend create.

---

Decision

Design consideration: Queue gate should account for unresolved dependencies

This relation metadata should be available before Orchestrator planning. That implies a stronger queue-time question:

If a Ticket has a project-level dependency such as depends_on: X, and X is still in planning / not ready / not resolved, should the user be prevented or warned before Queueing the dependent Ticket?

This needs explicit design before implementation.

Considerations:

• A dependency that is still planning likely means the dependent Ticket is not truly runnable yet.
• Queue should probably reject or strongly warn when unresolved depends_on / blocking relations remain.
• The behavior may differ by relation kind:
  • depends_on unresolved: likely hard block or confirmation-required;
  • blocks: informational for the blocked Ticket;
  • related: never blocks;
  • parent / child: depends on workflow semantics;
  • supersedes / duplicate_of: may redirect or discourage Queue.
• The Panel should be able to show why Queue is unavailable or risky before involving the Orchestrator.
• CLI Queue/state transitions should enforce the same rule or at least expose the same diagnostics.
• Orchestrator should still re-check relations at acceptance time, because relations may change between Queue and routing.

The implementation should decide whether unresolved dependencies make Queue invalid, require confirmation, or allow Queue with a visible blocked state. The important requirement is that dependency relation metadata is not only an Orchestrator input; it should also inform the human Queue gate.

---

Decision

Design consideration: avoid recreating umbrella Tickets through parent/child relations

Umbrella Tickets are being deprecated as long-lived broad progress containers. This affects relation design.

Parent/child relation kinds can easily recreate the umbrella pattern if they imply that one Ticket is a broad container whose close condition depends on manually inspecting child sufficiency. Therefore relation kinds such as parent / child should be reconsidered before implementation.

Design guidance:

• Keep concrete dependency/blocking relations distinct from broad grouping.
• Prefer Objective records for medium-term goal/strategy grouping.
• If decomposition needs to be represented, consider whether a relation such as derived_from, split_from, or related is safer than parent / child.
• Do not make relation metadata imply that a broad umbrella Ticket should remain open as a progress container.
• Any relation kind that approximates parent/child must define clear close semantics and avoid ambiguity around whether all child work is sufficient.

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 に遷移する。

---