Hare/yoi
1
1
Fork 0
Code Actions Packages Releases Activity

ticket: defer idle rekick for capacity

Browse Source
This commit is contained in:
Keisuke Hirata 2026-06-12 23:56:24 +09:00
parent dcd61410ad
commit a9b1ab302d
No known key found for this signature in database
2 changed files with 23 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

1
.yoi/tickets/00001KTJXS31R/artifacts/orchestration-plan.jsonl Normal file
View File

@ -0,0 +1 @@
{"id":"orch-plan-20260612-145604-1","ticket_id":"00001KTJXS31R","kind":"waiting_capacity_note","note":"Queue review 2026-06-12: leave queued for now because three active in-progress implementation branches are already delegated (`00001KTVJFT6F` Panel focus, `00001KTTW04W2` Companion progress notification, `00001KTVJGC0Y` Ticket language guidance). This Ticket's re-kick / active work-set scope overlaps conceptually and likely in code with Panel lifecycle / Companion progress notification and has duplicate-start / scheduler-boundary risk. Reconsider after at least the Panel/Companion-notify active work is merged or blocked, so implementation can validate active_inprogress suppression against current behavior.","author":"orchestrator","at":"2026-06-12T14:56:04Z"}

22
.yoi/tickets/00001KTJXS31R/thread.md
View File

@ -126,4 +126,26 @@ Intake refinement により、既存の plan store 実装との差分、current
Ticket を `workspace-panel` が queued にしました。 Ticket を `workspace-panel` が queued にしました。
---
<!-- event: decision author: orchestrator at: 2026-06-12T14:56:17Z -->
## Decision
Routing decision: leave queued for now (`waiting_capacity_note`)
Reason:
- This queue review already accepted and delegated three in-progress branches: `00001KTVJFT6F` (Panel focus model), `00001KTTW04W2` (Companion progress notification), and `00001KTVJGC0Y` (Ticket language guidance).
- This Ticket concerns Orchestrator idle queued re-kick / active work-set behavior and overlaps conceptually with the active Companion progress notification and Panel lifecycle work. Starting it now would raise duplicate-start / scheduler-boundary / integration-conflict risk rather than safe independent parallelism.
- Relation check: dependency relation target `00001KTG3MDFG` is closed, so this is not blocked by an unresolved relation; the current stop reason is capacity/conflict with active work.
Evidence checked:
- Ticket body/thread: active in-progress suppression, clean workspace gate, no queue-drain loop, active-work-set snapshot requirements, and escalation conditions.
- TicketRelationQuery: two relation records checked; `depends_on` target `00001KTG3MDFG` is closed.
- TicketOrchestrationPlanQuery: no prior records; added `waiting_capacity_note` `orch-plan-20260612-145604-1`.
- Workspace/Pod state: Orchestrator worktree clean; active sibling coder Pods are running for Panel focus, Companion progress notification, and Ticket language guidance.
Next action:
- Keep `queued` and reconsider after at least Panel focus / Companion progress notification are merged or blocked, so this Ticket can validate against the current Panel/notification behavior without duplicate scheduler semantics.
--- ---