ticket: route typed relation metadata

This commit is contained in:
Keisuke Hirata 2026-06-09 14:42:56 +09:00
parent 7cfc108030
commit 41a61d79d9
No known key found for this signature in database
6 changed files with 101 additions and 3 deletions

View File

@ -0,0 +1 @@
{"id":"orch-plan-20260609-054243-1","ticket_id":"20260608-072732-001","kind":"before","related_ticket":"20260608-125430-001","note":"Route typed Ticket relation metadata before Objective records so Objective linking/design can target the stable canonical Ticket relation/reference surface after identity simplification.","author":"orchestrator","at":"2026-06-09T05:42:43Z"}

View File

@ -1,8 +1,8 @@
--- ---
title: "Add non-hierarchical typed Ticket relations" title: "Add non-hierarchical typed Ticket relations"
state: "queued" state: 'inprogress'
created_at: "2026-06-08T07:27:32Z" created_at: "2026-06-08T07:27:32Z"
updated_at: "2026-06-09T02:28:14Z" updated_at: '2026-06-09T05:42:43Z'
queued_by: "workspace-panel" queued_by: "workspace-panel"
queued_at: "2026-06-09T02:27:31Z" queued_at: "2026-06-09T02:27:31Z"
--- ---

View File

@ -174,3 +174,76 @@ Next action:
- After `simplify-ticket-identity-fields` is merged/closed/cleaned up or explicitly held back, re-read this Ticket against the new identity model and accept it from queued if still unblocked. - After `simplify-ticket-identity-fields` is merged/closed/cleaned up or explicitly held back, re-read this Ticket against the new identity model and accept it from queued if still unblocked.
--- ---
<!-- event: state_changed author: orchestrator at: 2026-06-09T05:42:43Z from: queued to: inprogress reason: orchestrator_acceptance field: state -->
## State changed
Accepted queued implementation after identity simplification landed, was closed, and the workspace was verified clean on the flat Ticket layout. This Ticket is the lower-level project-level Ticket relation/reference surface, so it should run before Objective records, which may reference Tickets and relation concepts.
---
<!-- event: decision author: orchestrator at: 2026-06-09T05:42:43Z -->
## Decision
Routing decision: implementation_ready
Evidence checked:
- Ticket body/thread, including Intake refinement and explicit first-version relation decisions.
- Current flat Ticket identity state after `simplify-ticket-identity-fields` landed and closed.
- Current queued set: `typed-ticket-relation-metadata` and `objective-records-for-medium-term-goals`.
- Orchestration plan records: none existed before this routing; I recorded that typed relations should run before Objective records.
- Workspace/worktree state: main workspace clean enough to route, no active implementation worktree.
Reason:
- The Ticket has concrete binding decisions: non-hierarchical relation kinds only, forward stored relations with derived inverse views, queue-gate diagnostics for unresolved dependencies/blockers, and clear separation from OrchestrationPlan/runtime claims.
- It is lower-level than Objective records because Objective links should target stable canonical Ticket IDs and relation/reference semantics.
- No concrete missing decision remains that requires returning to planning.
IntentPacket:
Intent:
- Add typed, durable, non-hierarchical project-level Ticket-to-Ticket relation metadata on top of the flat canonical Ticket ID/state model.
Binding decisions / invariants:
- Supported stored relation kinds for first version: `depends_on`, `blocks`, `related`, `supersedes`, `duplicate_of`.
- Do not support hierarchy/container kinds: no `parent`, `child`, `sub-ticket`, `umbrella`, `part_of`, or `contains`.
- Store forward relations only; derive inverse views such as blocked-by / superseded-by / duplicate inverse from forward records.
- Relations are project-level Ticket metadata and must not store Pod/session claims, worktree paths, branch ownership, coder/reviewer assignments, capacity, current planned order, or `do_not_parallelize` execution-plan state.
- Store relations durably under the Ticket backend in a typed, git-trackable, backend-validated form.
- Use canonical opaque Ticket IDs only. Do not use title/slug words as relation authority.
- `TicketShow` must display relation metadata including useful inverse view.
- `ticket doctor` must validate dangling references, invalid kinds, self relations, and obvious dependency/blocking cycles with bounded diagnostics.
- Panel/CLI queue gate should not ignore unresolved blocking relations: unresolved `depends_on` and incoming unresolved `blocks` must be visible as block/diagnostic before `ready -> queued` and rechecked by Orchestrator at acceptance.
- `related` does not block queue; `supersedes` / `duplicate_of` produce visible replacement/duplicate diagnostics but are not automatically all blocking.
- Orchestrator routing treats relations as input constraints distinct from OrchestrationPlan runtime decisions.
- Do not implement Objective records here.
- Do not implement a full scheduler/dependency graph solver.
- Do not change Pod protocol/history/session semantics.
Implementation latitude:
- Coder may choose typed artifact vs current Ticket metadata field if it is validated, git-trackable, queryable, and works with flat IDs.
- CLI/tool names and exact Panel hint wording are implementation latitude if acceptance criteria are met.
- Cycle detection may be bounded and documented/test-covered.
- If the queue gate cannot be fully enforced in Panel/CLI without broad UI redesign, implement visible diagnostics and escalate the exact remaining gap rather than silently skipping it.
Reviewer focus:
- Verify relation storage is typed/validated and does not rely only on Markdown thread prose.
- Verify canonical ID references and local record migration/test fixtures use flat IDs.
- Verify no hierarchy/container relation kind slips in as current behavior.
- Verify OrchestrationPlan and Ticket relations remain distinct.
- Verify doctor and queue/panel/list/show surfaces expose unresolved dependency/blocker information before Orchestrator starts work.
Validation:
- Focused Ticket backend/parser/writer/doctor tests for relations, dangling references, invalid kinds, self relation, cycles, derived inverse views.
- Focused CLI/tool/schema tests for relation create/show/list/query or equivalent surfaces.
- Focused panel/queue-gate tests for unresolved dependency/blocker visibility if touched.
- Workflow/prompt/doc checks for Intake/Planning/Orchestrator relation guidance.
- `cargo fmt --check`.
- `git diff --check`.
- `cargo run -q -p yoi -- ticket doctor`.
- `cargo check --workspace`.
- `nix build .#yoi`.
---

View File

@ -0,0 +1 @@
{"id":"orch-plan-20260609-054243-1","ticket_id":"20260608-125430-001","kind":"after","related_ticket":"20260608-072732-001","note":"Defer Objective record implementation until typed Ticket relation metadata lands; Objective links should be designed against the stable non-hierarchical relation/reference model, not in parallel with it.","author":"orchestrator","at":"2026-06-09T05:42:43Z"}

View File

@ -2,7 +2,7 @@
title: "Define Objective records for medium-term goals" title: "Define Objective records for medium-term goals"
state: "queued" state: "queued"
created_at: "2026-06-08T12:54:30Z" created_at: "2026-06-08T12:54:30Z"
updated_at: "2026-06-09T02:28:14Z" updated_at: '2026-06-09T05:42:43Z'
queued_by: "workspace-panel" queued_by: "workspace-panel"
queued_at: "2026-06-09T02:27:33Z" queued_at: "2026-06-09T02:27:33Z"
--- ---

View File

@ -93,3 +93,26 @@ Next action:
- After `simplify-ticket-identity-fields` is merged/closed/cleaned up or explicitly held back, re-read this Ticket against the new identity model and accept it from queued if still unblocked. - After `simplify-ticket-identity-fields` is merged/closed/cleaned up or explicitly held back, re-read this Ticket against the new identity model and accept it from queued if still unblocked.
--- ---
<!-- event: decision author: orchestrator at: 2026-06-09T05:42:43Z -->
## Decision
Routing decision: waiting_for_relation_metadata
`objective-records-for-medium-term-goals` remains queued, but implementation is intentionally ordered after `typed-ticket-relation-metadata`.
Reason:
- Objective records need stable Ticket link/reference semantics.
- `typed-ticket-relation-metadata` is the lower-level non-hierarchical Ticket relation/reference surface that should land first.
- Running both in parallel would create avoidable conflict in project-record guidance, Ticket link semantics, panel/CLI display, and Orchestrator/Intake wording.
State decision:
- Leave this Ticket `queued`.
- Do not create a worktree or spawn a coder yet.
Next action:
- Complete and merge `typed-ticket-relation-metadata` first.
- Re-read Objective records against the resulting relation/reference model, then accept from queued if still unblocked.
---