yoi/.yoi/tickets/open/20260607-035710-ticket-orchestration-plan-tool/thread.md

Created

Created by LocalTicketBackend create.

---

Decision

Intake refinement: readiness and boundaries

Readiness classification: implementation_ready, with design preflight recommended before implementation because this introduces a new Ticket/orchestration-domain tool/API surface and durable record format.

Binding decisions / invariants:

• This is a Ticket/orchestration-domain capability, not a generic TaskStore replacement and not a scheduler.
• Durable project-relevant ordering/dependency/conflict/capacity decisions must survive compaction and be queryable later by Ticket id/slug and relation kind.
• Local runtime claims, Pod/session assignment details, sockets, and other ephemeral execution state must remain in the local role-session/runtime registry rather than git-tracked Ticket metadata.
• The first version must remain a lightweight note/plan surface; it must not silently introduce automatic topological scheduling or unattended queue reordering.
• Orchestrator prompts/workflows should consult these records before accepting queued Tickets, but human Queue and queued -> inprogress acceptance semantics remain unchanged.

Implementation latitude:

• The implementer may choose the concrete storage shape within the Ticket backend, such as typed thread events, artifacts, or a small typed record file, if it satisfies queryability, validation, and durability requirements.
• The tool naming and exact relation schema can be adjusted during preflight/implementation, provided the supported relation classes remain ordering, dependency/blocker, conflict, capacity/waiting, and accepted-plan summary.
• The first implementation can favor explicit CRUD/query operations over graph solving or automatic route selection.

Escalation conditions:

• Escalate before implementing if the design would change Ticket workflow-state semantics, mutate local role-session claims, require a migration of existing Ticket records, grant mutating capabilities to Companion, or make Orchestrator start work without the explicit Queue gate.
• Escalate if relation records need to include secret/private workspace details or raw session/model output; Ticket records should store bounded project-relevant decisions only.

Validation expectations:

• Add focused tests for creating/querying relation records by Ticket and relation kind.
• Add tests or prompt/workflow coverage showing Orchestrator can consult the records before queued-ticket acceptance.
• Run the normal package validation for code/runtime-resource changes, including nix build .#yoi before completion.

---

Intake summary

Existing Ticket ticket-orchestration-plan-tool was refined for readiness. It is implementation-ready as a bounded Ticket/orchestration-domain tool surface for recording/querying ordering, dependency/blocker, conflict, capacity/waiting, and accepted-plan decisions. Needs preflight: true, because it introduces a new durable Ticket-domain API/storage surface and touches Orchestrator routing workflow semantics. Risk flags: ticket-domain-tool, persistence, workflow-routing, feature-boundary, compaction. Key invariants: do not replace TaskStore, do not implement a scheduler/graph solver, keep local Pod/session claims out of git-tracked Ticket metadata, preserve the human Queue gate and queued->inprogress acceptance contract.

---

State changed

Intake has clarified readiness, boundaries, implementation latitude, escalation conditions, and validation expectations. The Ticket is ready for human queueing and Orchestrator routing/preflight; implementation should not start until the ready Ticket is queued and accepted through the Orchestrator workflow.

---

Decision

Dependency ordering: planning lane before OrchestrationPlan tool

replace-intake-state-with-planning owns the workflow cleanup for cases where implementation cannot be planned yet: such Tickets should return to the planning lane with a visible reason instead of remaining in a separate preflight_needed state/bucket.

This Ticket should assume that planning-lane behavior exists before the OrchestrationPlan tool is implemented. The dependency/order should be: settle replace-intake-state-with-planning first, then implement the OrchestrationPlan tool on top of the clarified planning/queued/inprogress workflow.

Do not add a Plan-tool-specific preflight_needed state or requirement here. At most, the tool may observe the resulting planning/queued/inprogress Ticket states produced by the workflow model.

---

State changed

Ticket を workspace-panel が queued にしました。

---

Decision

Routing decision: blocked_action_required

Reason:

• The dependency recorded in this Ticket is now satisfied: replace-intake-state-with-planning has been merged and closed, so the planning/queued/inprogress workflow model is available.
• However, this live Orchestrator cannot currently delegate implementation work because it was started before/without an explicit delegation_scope grant after the direct/delegation authority split.
• A previous attempted coder spawn for remove-fixed-investigator-ticket-role failed with: SpawnPod requires delegation authority, but this Pod has no delegation scope grant; direct filesystem scope only authorizes this Pod's own tools.
• This Ticket introduces a new durable Ticket-domain tool/API/storage surface and should use the sibling coder/reviewer workflow, not direct ad-hoc implementation from this restricted Orchestrator.

Evidence checked:

• Ticket body and thread, including the dependency ordering note requiring replace-intake-state-with-planning first.
• Current workspace state and worktrees.
• Visible Pods / delegation state from the prior SpawnPod failure in this same live Orchestrator.

Next action:

• Relaunch/restore an Orchestrator with explicit delegation authority for this workspace, then route this queued Ticket again.
• Once delegation authority is available, this Ticket can be classified as implementation-ready or planning-sync-ready against the now-merged planning workflow model.

State decision:

• Leave this Ticket queued for now.
• Do not transition queued -> inprogress, create a worktree, or spawn coder/reviewer Pods from this restricted Orchestrator.

Escalate if:

• The intended implementation should be done directly by the current Orchestrator despite missing delegation authority; that would bypass the sibling coder/reviewer workflow and needs explicit instruction.

---

Decision

Routing decision: waiting_for_schema_cleanup

ticket-orchestration-plan-tool remains queued, but implementation is intentionally ordered after remove-legacy-ticket-schema-fields.

Reason:

• The plan tool introduces a new durable Ticket-domain API/storage/query surface.
• remove-legacy-ticket-schema-fields is a lower-level cleanup of current Ticket schema/tool/API output and local Ticket record migration.
• Running both in parallel would create unnecessary conflict risk across the Ticket backend/tool surfaces and local .yoi/tickets records.

Next action:

• Complete and merge remove-legacy-ticket-schema-fields first.
• Re-read this Ticket against the stricter schema after that lands, then accept or re-plan it from queued state.

State decision:

• Leave this Ticket queued.
• Do not create a worktree or spawn coder/reviewer for it yet.

---

State changed

Accepted queued implementation after re-reading the Ticket, its dependency notes, current queued set, and workspace state. The previously blocking lower-level schema cleanup (remove-legacy-ticket-schema-fields) has landed and closed, so this Ticket can proceed on the stricter Ticket schema.

---

Decision

Routing decision: implementation_ready

Reason:

• The recorded dependency/order on replace-intake-state-with-planning is satisfied.
• The explicit waiting decision on remove-legacy-ticket-schema-fields is now satisfied; that Ticket has been merged and closed, including stricter current Ticket schema/API surfaces.
• This Ticket has clear requirements and bounded non-goals: implement a lightweight Ticket/orchestration-domain plan surface, not a scheduler, TaskStore replacement, or generic role/session registry.

IntentPacket:

Intent:

• Add a typed, durable Ticket orchestration plan/note surface for Orchestrator routing decisions about Ticket ordering, blockers, conflicts, capacity waiting, and accepted implementation plans.

Design direction / binding decisions:

• Treat this as a Ticket-domain capability, implemented in the existing Ticket backend/tool surface rather than as generic TaskStore or local runtime registry state.
• Prefer a small append/query API with two LLM-facing tools, e.g. one mutating record tool and one read/query tool. Exact names/schema are implementation latitude, but the tool names and JSON schema should be clear and typed.
• Durable storage should live under the Ticket backend root and be git-trackable. A simple per-Ticket artifact such as artifacts/orchestration-plan.jsonl is acceptable if records are validated, append-only enough for audit, and queryable by Ticket id/slug and relation kind.
• Query must work by Ticket id/slug and by relation kind; relation records should be bounded and typed, not arbitrary conversation dumps.
• Supported relation/note classes must cover at least: before/after ordering, blocked_by/blocks dependency, conflicts_with/do_not_parallelize conflict, waiting/capacity notes, and accepted_plan summaries.
• Accepted plan summaries may include bounded project-relevant plan fields such as branch/worktree/role plan, but must not store sockets, raw session ids, model output, local runtime claims, or secret/private environment details in git-tracked Ticket records.
• Keep Ticket workflow_state semantics unchanged: planning/ready/queued/inprogress/done remain authority, and plan records do not move Tickets by themselves.
• The tool must not automatically reorder/schedule queued Tickets; Orchestrator reads it as context and still makes explicit queued -> inprogress acceptance decisions.
• Read-only Ticket capability should be able to query plan records if normal Ticket read-only tools can inspect Ticket records; mutating plan recording should require the same lifecycle/mutating Ticket capability level as other Ticket writes.
• Integrate Orchestrator prompt/workflow guidance so queued routing consults these records before acceptance. Do not make Companion a mutating orchestration actor.

Implementation latitude:

• Coder may choose exact record IDs/timestamps/author fields and whether to expose relation kind names as before, after, blocked_by, blocks, conflicts_with, do_not_parallelize, waiting, accepted_plan or a similarly clear enum.
• Coder may implement storage as typed artifacts or typed thread events, but should justify the choice in tests/implementation report and ensure validation/queryability.
• Coder may add doctor validation for the new durable record format if artifacts are used.
• Coder may update local workflows/prompts/docs narrowly to teach Orchestrator to query these records before routing queued Tickets.

Escalate if:

• Implementation requires a new scheduling engine, automatic dependency graph solver, or background queue runner.
• Implementation needs to store local runtime/session/socket details in git-tracked Ticket records.
• The design would alter Ticket workflow_state transitions or bypass the human Queue gate.
• The tool surface cannot be added without broad plugin/feature-capability redesign.

Validation:

• Focused backend tests for record creation, validation, persistence, and query by Ticket and relation kind.
• Tool schema/tests for record/query tools and capability tool lists if changed.
• CLI/panel tests only if those surfaces are intentionally exposed in this first version; otherwise no CLI/panel UI is required.
• Prompt/workflow resource checks or tests where available.
• cargo fmt --check.
• git diff --check.
• cargo run -q -p yoi -- ticket doctor.
• cargo check --workspace.
• nix build .#yoi before final completion.

---