ticket: split ticket intake routing
This commit is contained in:
parent
1bf212e225
commit
11daffcd27
|
|
@ -1,7 +0,0 @@
|
|||
<!-- event: migration author: tickets.sh-migration at: 2026-05-27T00:00:17Z -->
|
||||
|
||||
## Migrated
|
||||
|
||||
Migrated from tickets/tui-spawned-pod-panel.md. No legacy review file was present at migration time.
|
||||
|
||||
---
|
||||
|
|
@ -0,0 +1,185 @@
|
|||
# Ticket definition and API shape
|
||||
|
||||
## Definition
|
||||
|
||||
In yoi, a Ticket is the durable orchestration record shared by humans, Intake Pods, Orchestrator Pods, coder Pods, and reviewer Pods.
|
||||
|
||||
Short definition:
|
||||
|
||||
> A Ticket is a durable coordination contract that preserves agreed intent, requirements, readiness, decisions, evidence, review results, and resolution history so Pod groups can route, delegate, implement, verify, and complete work without losing the original intent.
|
||||
|
||||
A local markdown ticket, GitHub Issue, Linear issue, Jira issue, or another tracker record can be a backend representation of a Ticket, but none of those storage representations define the concept.
|
||||
|
||||
The current local backend is the repository's `work-items/` directory managed by `tickets.sh`. That path remains unchanged for now.
|
||||
|
||||
## Roles served by a Ticket
|
||||
|
||||
A Ticket is simultaneously:
|
||||
|
||||
- Intent anchor: preserves what the user and Intake agreed to.
|
||||
- Requirements contract: states observable requirements, acceptance criteria, non-goals, and escalation conditions.
|
||||
- Routing unit: lets Orchestrator decide between requirements sync, preflight, spike, implementation, review, blocked/action-required, pending, or close.
|
||||
- Delegation source: lets Orchestrator derive an `IntentPacket` for a concrete Pod `Assignment`.
|
||||
- Review contract: gives reviewer Pods an explicit basis for approval or request-changes.
|
||||
- Evidence ledger: records plans, decisions, implementation reports, validation, review, artifacts, commits, branches, and resolution.
|
||||
- Backend-neutral record: local files are the first backend, not the product concept.
|
||||
|
||||
## Relationship to other terms
|
||||
|
||||
- `Task`: session-local progress tracking inside a Pod/session. Smaller and more ephemeral than a Ticket.
|
||||
- `Ticket`: durable project/orchestration record.
|
||||
- `Assignment`: concrete delegation from Orchestrator to a coder/reviewer/investigator Pod.
|
||||
- `IntentPacket`: concise implementation/review contract extracted from a Ticket and passed to an Assignment.
|
||||
- `TicketBackend`: backend abstraction for Ticket storage/mutation.
|
||||
- `LocalTicketBackend`: current local file backend over `work-items/`.
|
||||
|
||||
## Conceptual shape
|
||||
|
||||
The Rust model should use a thin typed envelope around Markdown/freeform body content.
|
||||
|
||||
Typed enough for machines:
|
||||
|
||||
- id / slug / title;
|
||||
- kind / priority / labels;
|
||||
- status;
|
||||
- readiness;
|
||||
- needs-preflight;
|
||||
- risk flags;
|
||||
- action-required state;
|
||||
- event kind;
|
||||
- review result;
|
||||
- artifact references;
|
||||
- branch/commit/Pod references where useful.
|
||||
|
||||
Flexible enough for humans/LLMs:
|
||||
|
||||
- background;
|
||||
- requirements;
|
||||
- acceptance criteria;
|
||||
- rationale;
|
||||
- design notes;
|
||||
- plan;
|
||||
- implementation report;
|
||||
- review body;
|
||||
- resolution.
|
||||
|
||||
## Candidate types
|
||||
|
||||
```rust
|
||||
struct Ticket {
|
||||
id: TicketId,
|
||||
slug: TicketSlug,
|
||||
title: String,
|
||||
meta: TicketMeta,
|
||||
body: TicketDocument,
|
||||
events: Vec<TicketEvent>,
|
||||
artifacts: Vec<TicketArtifactRef>,
|
||||
}
|
||||
|
||||
struct TicketSummary {
|
||||
id: TicketId,
|
||||
slug: TicketSlug,
|
||||
title: String,
|
||||
status: TicketStatus,
|
||||
kind: TicketKind,
|
||||
priority: TicketPriority,
|
||||
readiness: TicketReadiness,
|
||||
needs_preflight: bool,
|
||||
action_required: Option<ActionRequired>,
|
||||
}
|
||||
|
||||
enum TicketStatus {
|
||||
Open,
|
||||
Pending,
|
||||
Closed,
|
||||
Other(String),
|
||||
}
|
||||
|
||||
enum TicketReadiness {
|
||||
Unspecified,
|
||||
RequirementsSyncNeeded,
|
||||
SpikeNeeded,
|
||||
ImplementationReady,
|
||||
Blocked,
|
||||
Other(String),
|
||||
}
|
||||
|
||||
enum TicketEventKind {
|
||||
Comment,
|
||||
Plan,
|
||||
Decision,
|
||||
ImplementationReport,
|
||||
Review,
|
||||
StatusChanged,
|
||||
Closed,
|
||||
Other(String),
|
||||
}
|
||||
|
||||
struct TicketEvent {
|
||||
kind: TicketEventKind,
|
||||
body: MarkdownText,
|
||||
refs: Vec<TicketRef>,
|
||||
}
|
||||
```
|
||||
|
||||
## Candidate backend trait
|
||||
|
||||
```rust
|
||||
trait TicketBackend {
|
||||
fn list(&self, filter: TicketFilter) -> Result<Vec<TicketSummary>>;
|
||||
fn show(&self, id: TicketIdOrSlug) -> Result<Ticket>;
|
||||
fn create(&self, input: NewTicket) -> Result<TicketRef>;
|
||||
fn add_event(&self, id: TicketIdOrSlug, event: NewTicketEvent) -> Result<()>;
|
||||
fn review(&self, id: TicketIdOrSlug, review: TicketReview) -> Result<()>;
|
||||
fn set_status(&self, id: TicketIdOrSlug, status: TicketStatus) -> Result<()>;
|
||||
fn close(&self, id: TicketIdOrSlug, resolution: MarkdownText) -> Result<()>;
|
||||
fn doctor(&self) -> Result<TicketDoctorReport>;
|
||||
}
|
||||
```
|
||||
|
||||
The trait should remain backend-shaped and should not bake local file paths into the concept. Local paths belong in `LocalTicketBackend` configuration and implementation.
|
||||
|
||||
## Authority boundary
|
||||
|
||||
Ticket authority is separate from ordinary source/worktree filesystem scope.
|
||||
|
||||
Filesystem scope protects implementation areas and source edits. Ticket management is shared project coordination state and should be mediated through typed Ticket operations, backend locks/conflict handling, and audit/history records rather than delegated arbitrary write access.
|
||||
|
||||
This does not imply unlimited Ticket access. Ticket tools should be granted explicitly and limited to configured Ticket backends and operations.
|
||||
|
||||
## Backend layering
|
||||
|
||||
```text
|
||||
Ticket API / TicketBackend
|
||||
├─ LocalTicketBackend -> current work-items/ directory
|
||||
├─ GitHubTicketBackend -> possible future backend
|
||||
├─ LinearTicketBackend -> possible future backend
|
||||
└─ McpTicketBackend -> possible future bridge
|
||||
```
|
||||
|
||||
Local files are the first backend because they are already the authoritative project record in this repository. External tracker support is not part of the MVP.
|
||||
|
||||
## Validation/linting direction
|
||||
|
||||
Prefer a Ticket linter/policy layer over strict structural enforcement for all body content.
|
||||
|
||||
The code should enforce mechanical consistency and safe mutation:
|
||||
|
||||
- required frontmatter fields;
|
||||
- status directory consistency;
|
||||
- id/slug uniqueness;
|
||||
- thread event parseability;
|
||||
- review/result shape;
|
||||
- resolution existence for closed tickets;
|
||||
- artifact path containment;
|
||||
- lock/conflict behavior;
|
||||
- bounded diagnostics.
|
||||
|
||||
The code should not require every Ticket body to fit a rigid universal schema. Ticket bodies remain Markdown/freeform because design, cleanup, bugs, investigations, and orchestration epics need different prose.
|
||||
|
||||
## Current implementation sequence
|
||||
|
||||
1. `ticket-local-files-backend`
|
||||
2. `ticket-built-in-feature-tools`
|
||||
3. `ticket-intake-workflow`
|
||||
4. `ticket-orchestrator-routing`
|
||||
|
|
@ -1,5 +1,7 @@
|
|||
# WorkItem definition and API shape
|
||||
|
||||
> Superseded on 2026-06-05: the durable orchestration record concept is now named `Ticket`, not `WorkItem`. See `ticket-definition-and-api-shape-20260605.md` and the ticket thread decision for current terminology. This file is retained as historical design context.
|
||||
|
||||
## Definition
|
||||
|
||||
In Insomnia, a WorkItem is not primarily an issue tracker item. A WorkItem is an agreed execution contract that fixes user intent into a bounded unit that Pods can schedule, delegate, implement, review, and close safely.
|
||||
|
|
|
|||
|
|
@ -1,68 +1,86 @@
|
|||
---
|
||||
id: 20260601-031252-builtin-work-item-intake-routing
|
||||
slug: builtin-work-item-intake-routing
|
||||
title: Built-in work item management and intake routing
|
||||
title: Built-in Ticket intake and orchestration routing
|
||||
status: open
|
||||
kind: task
|
||||
priority: P1
|
||||
labels: [work-item, intake, orchestration, tui]
|
||||
labels: [ticket, intake, orchestration]
|
||||
created_at: 2026-06-01T03:12:52Z
|
||||
updated_at: 2026-06-03T12:25:05Z
|
||||
updated_at: 2026-06-05T04:04:42Z
|
||||
assignee: null
|
||||
legacy_ticket: null
|
||||
---
|
||||
|
||||
## Issue
|
||||
## Background
|
||||
|
||||
現在の work item / ticket 運用は、Insomnia システムから切り離しても使えるように `tickets.sh` と markdown files で管理している。一方で、チケットは実質的に WorkItem と統合された構造化データとして運用され始めており、Intake Pod / Orchestrator / coder / reviewer の並行開発フローでは、チケット管理自体を Insomnia の feature として扱う必要が出てきている。
|
||||
Yoi needs a durable project-level coordination record that Intake, Orchestrator, coder Pods, reviewer Pods, and humans can share. The accepted concept name is **Ticket**.
|
||||
|
||||
特に、ユーザーが単一 Orchestrator に依頼してから Orchestrator が調査・チケット化・実装委譲する現在の入口では、ユーザー待ち時間が残る。ユーザーの submit から Intake Pod が直接起動し、ユーザーと意図・要件をすり合わせたうえで正式な WorkItem / ticket を作成し、Orchestrator はそのチケット群の順序付け・割り込み・実装 orchestration に集中する構造へ移行したい。
|
||||
A Ticket is not the same thing as the session-local Task tool. A Task tracks short-lived user-visible progress inside a Pod/session. A Ticket is a durable orchestration contract with requirements, decisions, plans, implementation reports, reviews, artifacts, and resolution history.
|
||||
|
||||
## Direction
|
||||
The current repository already stores this information under `work-items/` and manages it through `tickets.sh`. For now, that storage format remains the local backend. The new code-facing concept should be `Ticket`, not `WorkItem`; `work-items/` is a current local storage path, not the product concept name.
|
||||
|
||||
- `tickets.sh` 相当の work item 管理を、Insomnia の built-in feature / tool surface として設計・実装する。
|
||||
- WorkItem は Pod 専用の独自 context injection や特殊 queue ではなく、`plugin-feature-contribution-registry` で定義する feature contribution として既存 Tool / Hook / Notify 経路に載せる。
|
||||
- Intake Pod はユーザーと直接会話し、必要な調査・重複確認・要件同期を行い、合意済み WorkItem / ticket を作成できるようにする。
|
||||
- Orchestrator はユーザー意図の一次解釈や ticket draft の再承認者ではなく、登録済み WorkItem の scheduling / prioritization / interruption / implementation delegation を担当する。
|
||||
- ユーザー向け Inbox 専用 UI は初期スコープにしない。Intake は既存の `--multi` UI の延長として通常の Pod 会話で制御できるようにする。
|
||||
- Orchestrator が WorkItem を見て不十分と判断し、Intake と Orchestrator 間だけで合意できない場合は、Intake Pod に action-required flag を持たせ、既存の TUI polling / multi-Pod 表示経路でユーザー対応要求として表示する。
|
||||
The original version of this ticket mixed several layers: local ticket backend, built-in Pod tools, Intake behavior, Orchestrator routing, action-required state, and scheduler-like automation. That is too broad for a single implementation ticket, so this ticket now acts as the umbrella tracking ticket for the split.
|
||||
|
||||
## Scope / permission note
|
||||
## Terminology
|
||||
|
||||
Scope は、エージェントが占有して作業する filesystem space を保証するための仕組みである。WorkItem / ticket 管理を built-in tool として提供する場合、その tool は単なる delegated workspace edit と同じ扱いにせず、既存の `tickets.sh` / Bash と同様に work item authority のための専用経路として設計してよい。
|
||||
- `Ticket`: durable orchestration record shared by Intake, Orchestrator, implementation Pods, reviewer Pods, and humans.
|
||||
- `Task`: session-local progress tracking tool; intentionally separate from Ticket.
|
||||
- `Assignment`: a concrete delegation from Orchestrator to a coder/reviewer/investigator Pod.
|
||||
- `IntentPacket`: short implementation/review contract derived from a Ticket and passed to an Assignment.
|
||||
- `TicketBackend`: backend abstraction for reading and mutating Tickets.
|
||||
- `LocalTicketBackend`: backend implementation for the current `work-items/` directory format.
|
||||
|
||||
ただし、これは無制限のファイル編集許可を意味しない。WorkItem tool は対象を work item store に限定し、通常の code/worktree scope とは別の authority boundary と auditability を持つべきである。
|
||||
## Scope of the umbrella
|
||||
|
||||
This umbrella covers the following sequence:
|
||||
|
||||
1. `ticket-local-files-backend`
|
||||
- Add a code-facing Ticket domain model and local backend for current `work-items/` files.
|
||||
- Keep `tickets.sh` and existing file format compatible.
|
||||
|
||||
2. `ticket-built-in-feature-tools`
|
||||
- Expose Ticket operations as a built-in Pod feature/tool surface.
|
||||
- Treat Ticket operations as typed backend authority, not arbitrary filesystem writes.
|
||||
|
||||
3. `ticket-intake-workflow`
|
||||
- Define and install an Intake workflow/profile that clarifies user requests and creates Tickets after user agreement.
|
||||
|
||||
4. `ticket-orchestrator-routing`
|
||||
- Let Orchestrator classify Tickets and route them into preflight, implementation, review, spike, blocked/action-required, or close paths.
|
||||
|
||||
Later scheduler/lease/automatic maintainer behavior is out of scope for this umbrella until the above pieces are usable.
|
||||
|
||||
## Requirements
|
||||
|
||||
- `tickets.sh` で行っている主要操作を、Insomnia の built-in work item management surface として扱えるようにすること。
|
||||
- create
|
||||
- show/list
|
||||
- comment / plan / decision / implementation report
|
||||
- review approve/request-changes
|
||||
- status transition
|
||||
- close / resolution
|
||||
- doctor / consistency check
|
||||
- WorkItem tool surface は `plugin-feature-contribution-registry` の built-in feature contribution として登録できること。
|
||||
- WorkItem / ticket の保存形式は、現在の markdown + frontmatter + thread / artifacts 方式との移行可能性を保つこと。
|
||||
- 既存の `tickets.sh` 運用を即座に破壊しないこと。built-in 化の途中でも git history / work-items directory を authority として読めること。
|
||||
- Intake Pod がユーザーと合意済み WorkItem を作成できる導線を設計すること。
|
||||
- Intake Pod は正式作成前に、必要に応じて既存 ticket / duplicate / related work / relevant files を調査できること。
|
||||
- Intake Pod が作った WorkItem には、ユーザー合意済みであること、背景、要件、acceptance criteria、non-goals、risk flags、needs-preflight などを構造化して残せること。
|
||||
- Orchestrator は作成済み WorkItem queue を見て、実装順序・割り込み・preflight 要否・coder/reviewer 起動を判断できること。
|
||||
- Orchestrator が WorkItem 不十分と判断した場合、必要な質問や修正要求を Intake Pod 経由でユーザーに戻せること。
|
||||
- 専用 Inbox storage / UI を初期要件にしないこと。action-required state は Pod metadata / current state に近い形で持ち、既存 multi-Pod polling / display で見えるようにすること。
|
||||
- action-required Pod は、ユーザーが対応するまで見落とされにくい表示・状態を持つこと。
|
||||
- Intake 結果や WorkItem 操作は audit 可能で、git history / work item thread に経緯が残ること。
|
||||
- secret / private context を WorkItem 本文・thread・artifact・diagnostics に不用意に書かないこと。
|
||||
- work item store への並行書き込みが壊れないよう、atomicity / locking / conflict handling を設計すること。
|
||||
- Use `Ticket` as the product/code concept name.
|
||||
- Keep existing `work-items/` storage as the LocalTicketBackend path for now.
|
||||
- Do not rename the storage directory in this umbrella.
|
||||
- Keep git history + ticket files authoritative.
|
||||
- Preserve compatibility with `tickets.sh` until a replacement is explicitly accepted.
|
||||
- Keep Ticket authority separate from delegated filesystem write scope.
|
||||
- Avoid exposing arbitrary file writes through Ticket tools.
|
||||
- Keep Intake focused on clarification and Ticket creation/update; it must not schedule implementation itself.
|
||||
- Keep Orchestrator responsible for routing/scheduling decisions, not Intake.
|
||||
- Do not introduce an unattended scheduler in the MVP.
|
||||
|
||||
## Acceptance criteria
|
||||
|
||||
- Insomnia 内部から、少なくとも `tickets.sh create/show/list/comment/review/close/doctor` に相当する操作を型付きに実行できる。
|
||||
- Intake Pod がユーザーと合意した内容を正式 WorkItem として作成できる。
|
||||
- Orchestrator は Intake が作成した WorkItem を、再解釈 gate なしに scheduling 対象として扱える。
|
||||
- WorkItem が不十分な場合は、Orchestrator が action-required state を通じて Intake / user に差し戻せる。
|
||||
- `--multi` 系 UI で、通常の Pod 状態に加えて user action required な Intake Pod を認識できる。
|
||||
- 専用 Inbox storage を導入しなくても、未対応のユーザー確認要求が見落とされない。
|
||||
- 既存 `work-items/` と git history に基づく運用・監査が継続できる。
|
||||
- This umbrella records the Ticket terminology decision and split plan.
|
||||
- Child tickets exist for:
|
||||
- local files backend;
|
||||
- built-in feature tools;
|
||||
- intake workflow;
|
||||
- orchestrator routing.
|
||||
- Child tickets state their dependencies, scope, non-goals, and acceptance criteria clearly enough for preflight/implementation sequencing.
|
||||
- Historical `WorkItem` wording in this ticket is either removed or explicitly described as old terminology.
|
||||
- `tickets.sh doctor` passes after the split.
|
||||
|
||||
## Non-goals
|
||||
|
||||
- Renaming `work-items/` to `tickets/`.
|
||||
- Replacing `tickets.sh` immediately.
|
||||
- Building a scheduler/lease system.
|
||||
- Building a TUI spawned-Pod panel.
|
||||
- Changing the session-local Task tool.
|
||||
- Integrating with GitHub Issues, Linear, MCP, or external trackers in this umbrella.
|
||||
|
|
|
|||
|
|
@ -248,4 +248,73 @@ Two implementation-oriented prerequisite tickets are split out:
|
|||
This preserves the desired detachable shape: feature state remains in the feature/extension module, while Pod interaction happens through existing durable host surfaces. WorkItem management should be implemented as a built-in feature contribution once the registry boundary is in place, rather than as a special Pod context-injection path.
|
||||
|
||||
|
||||
---
|
||||
|
||||
<!-- event: decision author: hare at: 2026-06-05T04:03:37Z -->
|
||||
|
||||
## Decision
|
||||
|
||||
Decision: use `Ticket` as the durable orchestration record concept.
|
||||
|
||||
Rationale:
|
||||
|
||||
- `WorkItem` is not a preferred product/code name.
|
||||
- `Work*` naming feels too enterprise/work-order-like for this system.
|
||||
- `Issue` overemphasizes problems/bugs and does not fit design, cleanup, investigation, and orchestration records as well.
|
||||
- `Task` is already used for session-local progress tracking and implies a smaller unit.
|
||||
- `Ticket` is broad enough for requests, bugs, design work, implementation tasks, reviews, spikes, and orchestration epics while remaining natural in the current repository workflow.
|
||||
|
||||
Terminology:
|
||||
|
||||
- `Ticket` is the durable orchestration record.
|
||||
- `Task` remains session-local progress tracking.
|
||||
- `Assignment` is a concrete delegation from Orchestrator to a coder/reviewer/investigator Pod.
|
||||
- `IntentPacket` is a short implementation/review contract derived from a Ticket.
|
||||
- `LocalTicketBackend` is the current `work-items/` markdown/thread/artifact storage backend.
|
||||
|
||||
Scope decision:
|
||||
|
||||
- Keep `work-items/` as the current storage path for now.
|
||||
- Do not rename `work-items/` in this phase.
|
||||
- Treat the old WorkItem wording as historical terminology being replaced by Ticket.
|
||||
|
||||
|
||||
---
|
||||
|
||||
<!-- event: plan author: hare at: 2026-06-05T04:03:37Z -->
|
||||
|
||||
## Plan
|
||||
|
||||
Plan: split the original broad built-in intake/routing ticket into implementation-sized Ticket tickets.
|
||||
|
||||
The parent ticket is now an umbrella for the Ticket-driven intake/orchestration path. The implementation sequence is:
|
||||
|
||||
1. `ticket-local-files-backend`
|
||||
- Add the code-facing Ticket domain/backend layer and LocalTicketBackend over current `work-items/` files.
|
||||
|
||||
2. `ticket-built-in-feature-tools`
|
||||
- Expose typed Ticket operations as a built-in Pod feature/tool surface with Ticket backend authority, not arbitrary filesystem write scope.
|
||||
|
||||
3. `ticket-intake-workflow`
|
||||
- Add the Intake workflow/profile that clarifies user intent and creates/updates Tickets after user agreement.
|
||||
|
||||
4. `ticket-orchestrator-routing`
|
||||
- Add explicit Orchestrator routing classification and intent-packet production for Tickets.
|
||||
|
||||
`tui-spawned-pod-panel` is not part of this path; it may be useful UI work later, but it is not what is currently needed for the multi-agent system.
|
||||
|
||||
|
||||
---
|
||||
|
||||
<!-- event: comment author: hare at: 2026-06-05T04:04:42Z -->
|
||||
|
||||
## Comment
|
||||
|
||||
Added current terminology/design artifact:
|
||||
|
||||
- `artifacts/ticket-definition-and-api-shape-20260605.md`
|
||||
|
||||
The earlier `workitem-definition-and-api-shape-20260601.md` is now explicitly marked superseded and retained only as historical context.
|
||||
|
||||
|
||||
---
|
||||
|
|
|
|||
|
|
@ -0,0 +1,97 @@
|
|||
---
|
||||
id: 20260605-040104-ticket-built-in-feature-tools
|
||||
slug: ticket-built-in-feature-tools
|
||||
title: Ticket built-in feature tools
|
||||
status: open
|
||||
kind: task
|
||||
priority: P1
|
||||
labels: [ticket, feature, tool, orchestration]
|
||||
created_at: 2026-06-05T04:01:04Z
|
||||
updated_at: 2026-06-05T04:01:25Z
|
||||
assignee: null
|
||||
legacy_ticket: null
|
||||
---
|
||||
|
||||
## Background
|
||||
|
||||
After a typed Ticket backend exists, Pods need a controlled way to read and mutate Tickets without receiving arbitrary filesystem write scope over the repository.
|
||||
|
||||
Ticket operations are orchestration authority, not ordinary source-file writes. A coder Pod may have write access only to a child worktree and still need to report implementation progress or attach artifacts to a Ticket through a typed operation. Intake and Orchestrator Pods likewise need Ticket operations that are bounded, auditable, and backend-independent.
|
||||
|
||||
This ticket depends on `ticket-local-files-backend`. It should also be sequenced after or alongside `feature-api-authority-separation` if that ticket is still open, because Ticket tools should use the built-in contribution path without confusing internal built-ins with external plugin grants.
|
||||
|
||||
## Requirements
|
||||
|
||||
- Add a built-in Pod feature for Ticket tools.
|
||||
- Register tools through the existing feature contribution / ToolRegistry path.
|
||||
- Use the typed Ticket backend from `ticket-local-files-backend`.
|
||||
- Treat Ticket operations as configured backend authority, not filesystem scope.
|
||||
- Do not grant arbitrary writes to `work-items/` through generic filesystem tools.
|
||||
- Keep tool outputs bounded and model-readable.
|
||||
- Preserve current `tickets.sh` semantics where equivalent operations exist.
|
||||
- Ensure Ticket operations are recorded durably in the ticket files/thread/resolution/artifacts.
|
||||
- Keep permission/policy behavior explicit and fail-closed.
|
||||
- Avoid external plugin loading or MCP integration in this ticket.
|
||||
|
||||
## Candidate tool surface
|
||||
|
||||
Exact names can be adjusted during preflight, but the surface should be close to:
|
||||
|
||||
- `TicketCreate`
|
||||
- `TicketList`
|
||||
- `TicketShow`
|
||||
- `TicketComment`
|
||||
- `TicketReview`
|
||||
- `TicketStatus`
|
||||
- `TicketClose`
|
||||
- `TicketDoctor`
|
||||
|
||||
Optional follow-up if needed rather than MVP:
|
||||
|
||||
- `TicketArtifactWrite`
|
||||
- `TicketArtifactRead`
|
||||
- `TicketSearch`
|
||||
|
||||
## Authority model
|
||||
|
||||
- The Pod must receive a Ticket backend/tool grant through manifest/profile/feature configuration.
|
||||
- The grant points to a configured backend root, initially the local repository `work-items/` root.
|
||||
- Tool implementations validate paths and identifiers against the backend root.
|
||||
- Artifact writes are constrained to the selected ticket's `artifacts/` directory.
|
||||
- Ticket tools do not imply general `Write` permission to the repository.
|
||||
- Existing PreToolCall policy still applies to the tool call itself.
|
||||
|
||||
## Non-goals
|
||||
|
||||
- Implementing the local files backend itself.
|
||||
- Building Intake workflow behavior.
|
||||
- Building Orchestrator routing/scheduling.
|
||||
- Renaming `work-items/`.
|
||||
- Removing `tickets.sh`.
|
||||
- External tracker integration.
|
||||
- MCP/plugin loading.
|
||||
- Scheduler/lease/queue automation.
|
||||
- TUI changes.
|
||||
|
||||
## Acceptance criteria
|
||||
|
||||
- Ticket tools are registered only when the built-in Ticket feature is enabled/configured.
|
||||
- Ticket tools operate through the typed Ticket backend and not shelling out to `tickets.sh`.
|
||||
- A Pod without filesystem write scope to `work-items/` can perform allowed Ticket operations through the tool grant.
|
||||
- A Pod without the Ticket tool grant cannot mutate Tickets through these tools.
|
||||
- Tool schemas and outputs are bounded, deterministic enough for tests, and suitable for LLM use.
|
||||
- Ticket create/comment/review/status/close operations produce files accepted by `./tickets.sh doctor`.
|
||||
- Tool calls produce no writes outside the backend root and selected ticket artifact directories.
|
||||
- Unit/integration tests cover allowed/denied operation paths and path traversal attempts.
|
||||
- `cargo test` for affected crates passes.
|
||||
- `cargo check --workspace --all-targets`, `cargo fmt --check`, `git diff --check`, and `./tickets.sh doctor` pass.
|
||||
|
||||
## Dependencies
|
||||
|
||||
- Requires `ticket-local-files-backend`.
|
||||
- Prefer after `feature-api-authority-separation` if that ticket remains open.
|
||||
|
||||
## Follow-up tickets
|
||||
|
||||
- `ticket-intake-workflow`
|
||||
- `ticket-orchestrator-routing`
|
||||
|
|
@ -0,0 +1,7 @@
|
|||
<!-- event: create author: tickets.sh at: 2026-06-05T04:01:04Z -->
|
||||
|
||||
## Created
|
||||
|
||||
Created by tickets.sh create.
|
||||
|
||||
---
|
||||
|
|
@ -0,0 +1,94 @@
|
|||
---
|
||||
id: 20260605-040104-ticket-intake-workflow
|
||||
slug: ticket-intake-workflow
|
||||
title: Ticket intake workflow
|
||||
status: open
|
||||
kind: task
|
||||
priority: P1
|
||||
labels: [ticket, intake, workflow, orchestration]
|
||||
created_at: 2026-06-05T04:01:04Z
|
||||
updated_at: 2026-06-05T04:01:25Z
|
||||
assignee: null
|
||||
legacy_ticket: null
|
||||
---
|
||||
|
||||
## Background
|
||||
|
||||
The multi-agent system needs an Intake role that turns a user's vague or broad request into an agreed Ticket before Orchestrator starts scheduling implementation work.
|
||||
|
||||
The Intake role is not a scheduler and does not spawn coder/reviewer Pods. It clarifies intent, checks for duplicates/related tickets, asks the user for missing requirements, and creates or updates Tickets after agreement.
|
||||
|
||||
This ticket depends on typed Ticket tools. Without a built-in Ticket tool surface, Intake would need arbitrary filesystem write scope or ad hoc shell access, which is not the desired authority boundary.
|
||||
|
||||
## Requirements
|
||||
|
||||
- Define an Intake workflow/profile/prompt for Ticket intake.
|
||||
- Intake should be able to:
|
||||
- understand the user's requested change;
|
||||
- inspect existing Tickets for duplicates or related work;
|
||||
- inspect relevant repository files when needed and permitted;
|
||||
- ask clarifying questions;
|
||||
- propose Ticket title/kind/priority/labels;
|
||||
- summarize background, requirements, acceptance criteria, non-goals, escalation conditions, risk flags, and readiness;
|
||||
- create a Ticket after user agreement;
|
||||
- update an existing Ticket when the user asks to refine known work.
|
||||
- Intake-created Tickets should be suitable for Orchestrator routing without a second full reinterpretation pass.
|
||||
- Intake must classify readiness explicitly:
|
||||
- `implementation_ready`;
|
||||
- `requirements_sync_needed`;
|
||||
- `spike_needed`;
|
||||
- `blocked`;
|
||||
- or `unspecified` only when unavoidable.
|
||||
- Intake should mark `needs_preflight` for tickets with design/authority/scope/history/prompt-context risk.
|
||||
- Intake should avoid persisting private/secret-like material in Ticket bodies, thread entries, artifacts, or diagnostics.
|
||||
|
||||
## User agreement rule
|
||||
|
||||
Intake must not silently convert an unresolved draft into an official Ticket.
|
||||
|
||||
MVP behavior:
|
||||
|
||||
- Draft state can live in the conversation while clarifying.
|
||||
- Intake creates a Ticket only after the user accepts the proposed contents or explicitly asks to create it.
|
||||
- If the user wants to record unresolved work, Intake may create a Ticket with readiness such as `requirements_sync_needed` or `spike_needed`, but the unresolved state must be explicit in the Ticket.
|
||||
|
||||
## Non-goals
|
||||
|
||||
- Scheduling implementation.
|
||||
- Spawning coder/reviewer Pods.
|
||||
- Creating worktrees.
|
||||
- Closing Tickets.
|
||||
- Building a dedicated Inbox UI or storage.
|
||||
- Building an unattended maintainer/scheduler.
|
||||
- Replacing `multi-agent-workflow`.
|
||||
- Implementing Ticket backend/tools.
|
||||
|
||||
## Acceptance criteria
|
||||
|
||||
- A user-invocable Intake workflow/profile exists and uses Ticket terminology consistently.
|
||||
- Intake can create a Ticket through Ticket tools after user agreement.
|
||||
- Intake can update/comment on an existing Ticket through Ticket tools when refining known work.
|
||||
- Intake checks for duplicate/related Tickets before creating a new one when practical.
|
||||
- Intake-created Tickets include enough information for Orchestrator to classify next action:
|
||||
- issue/background;
|
||||
- requirements;
|
||||
- acceptance criteria;
|
||||
- non-goals where relevant;
|
||||
- readiness;
|
||||
- needs-preflight;
|
||||
- risk flags;
|
||||
- escalation conditions where relevant.
|
||||
- Intake does not require general repository write scope to create Tickets.
|
||||
- Intake does not start implementation or spawn coder/reviewer Pods.
|
||||
- Secret/private-context handling is documented in the workflow/prompt.
|
||||
- Focused tests or prompt/resource linting cover the installed workflow/profile where applicable.
|
||||
- `cargo check --workspace --all-targets`, `cargo fmt --check`, `git diff --check`, and `./tickets.sh doctor` pass if code changes are included.
|
||||
|
||||
## Dependencies
|
||||
|
||||
- Requires `ticket-local-files-backend`.
|
||||
- Requires `ticket-built-in-feature-tools` for the intended authority boundary.
|
||||
|
||||
## Follow-up tickets
|
||||
|
||||
- `ticket-orchestrator-routing`
|
||||
|
|
@ -0,0 +1,7 @@
|
|||
<!-- event: create author: tickets.sh at: 2026-06-05T04:01:04Z -->
|
||||
|
||||
## Created
|
||||
|
||||
Created by tickets.sh create.
|
||||
|
||||
---
|
||||
|
|
@ -0,0 +1,105 @@
|
|||
---
|
||||
id: 20260605-040104-ticket-local-files-backend
|
||||
slug: ticket-local-files-backend
|
||||
title: Ticket local files backend
|
||||
status: open
|
||||
kind: task
|
||||
priority: P1
|
||||
labels: [ticket, backend, orchestration]
|
||||
created_at: 2026-06-05T04:01:04Z
|
||||
updated_at: 2026-06-05T04:01:25Z
|
||||
assignee: null
|
||||
legacy_ticket: null
|
||||
---
|
||||
|
||||
## Background
|
||||
|
||||
The first step toward Ticket-driven multi-agent orchestration is to make the current `work-items/` + `tickets.sh` file format accessible through a typed Rust API.
|
||||
|
||||
The product/code concept name is **Ticket**. The current directory name `work-items/` remains the LocalTicketBackend storage path for now; do not rename it in this ticket.
|
||||
|
||||
This ticket should produce a backend-shaped domain layer that future Pod tools, Intake workflows, Orchestrator routing, TUI views, and external tracker integrations can use without depending on `tickets.sh` shell execution or ad hoc markdown parsing.
|
||||
|
||||
## Requirements
|
||||
|
||||
- Add a code-facing Ticket domain/backend layer.
|
||||
- Preferred crate: `crates/ticket` or `crates/tickets`; choose the name that reads best in Rust and avoids collision with `tickets.sh` scripts.
|
||||
- The public concept/type names should use `Ticket`, not `WorkItem`.
|
||||
- Implement `LocalTicketBackend` over current `work-items/` storage.
|
||||
- Preserve the current markdown + frontmatter + `thread.md` + `artifacts/` layout.
|
||||
- Preserve compatibility with `tickets.sh`; existing script operations should continue to work on files written by the Rust backend.
|
||||
- Keep git history and repository files authoritative.
|
||||
- Implement typed operations equivalent to at least:
|
||||
- list;
|
||||
- show;
|
||||
- create;
|
||||
- comment / plan / decision / implementation_report events;
|
||||
- review approve/request-changes;
|
||||
- status transition;
|
||||
- close with resolution;
|
||||
- doctor/consistency check.
|
||||
- Use a thin typed envelope with Markdown/freeform bodies.
|
||||
- Include machine-readable fields needed by Orchestrator/TUI/policy:
|
||||
- id / slug / title;
|
||||
- kind / priority / labels;
|
||||
- status;
|
||||
- readiness;
|
||||
- needs-preflight;
|
||||
- risk flags;
|
||||
- action-required state;
|
||||
- event kind;
|
||||
- references to files, branches, commits, Pods, artifacts, URLs where practical.
|
||||
- Keep enums extensible where backend compatibility needs raw values.
|
||||
- Implement safe local-file mutation:
|
||||
- atomic writes where files are replaced;
|
||||
- lock/conflict handling sufficient for multiple Pod/tool users;
|
||||
- no writes outside the configured local ticket root except controlled temp files.
|
||||
- Provide bounded errors/diagnostics suitable for later tool output.
|
||||
|
||||
## Suggested API shape
|
||||
|
||||
The exact API can be adjusted during implementation, but should remain backend-shaped:
|
||||
|
||||
```rust
|
||||
trait TicketBackend {
|
||||
fn list(&self, filter: TicketFilter) -> Result<Vec<TicketSummary>>;
|
||||
fn show(&self, id: TicketIdOrSlug) -> Result<Ticket>;
|
||||
fn create(&self, input: NewTicket) -> Result<TicketRef>;
|
||||
fn add_event(&self, id: TicketIdOrSlug, event: NewTicketEvent) -> Result<()>;
|
||||
fn review(&self, id: TicketIdOrSlug, review: TicketReview) -> Result<()>;
|
||||
fn set_status(&self, id: TicketIdOrSlug, status: TicketStatus) -> Result<()>;
|
||||
fn close(&self, id: TicketIdOrSlug, resolution: MarkdownText) -> Result<()>;
|
||||
fn doctor(&self) -> Result<TicketDoctorReport>;
|
||||
}
|
||||
```
|
||||
|
||||
## Non-goals
|
||||
|
||||
- Exposing Pod tools.
|
||||
- Implementing Intake Pod behavior.
|
||||
- Implementing Orchestrator routing or scheduling.
|
||||
- Renaming `work-items/`.
|
||||
- Removing `tickets.sh`.
|
||||
- Integrating GitHub Issues, Linear, Jira, MCP, or other external backends.
|
||||
- Building a scheduler/lease system.
|
||||
- Changing the session-local Task tool.
|
||||
|
||||
## Acceptance criteria
|
||||
|
||||
- Rust code can read existing open/pending/closed tickets from `work-items/`.
|
||||
- Rust code can create a ticket equivalent to `tickets.sh create`.
|
||||
- Rust code can append typed thread events equivalent to `tickets.sh comment` roles.
|
||||
- Rust code can record approve/request-changes reviews equivalent to `tickets.sh review`.
|
||||
- Rust code can close a ticket with a `resolution.md` equivalent to `tickets.sh close`.
|
||||
- Rust doctor catches the same core consistency failures as `tickets.sh doctor` or clearly documents any remaining gaps.
|
||||
- Files written by the Rust backend pass `./tickets.sh doctor`.
|
||||
- Existing `tickets.sh` can still read/mutate tickets written by the Rust backend.
|
||||
- Unit tests cover parsing, create, event append, review, status transition, close, doctor, lock/conflict handling, and corrupt input diagnostics.
|
||||
- `cargo test` for the new crate passes.
|
||||
- `cargo check --workspace --all-targets`, `cargo fmt --check`, `git diff --check`, and `./tickets.sh doctor` pass.
|
||||
|
||||
## Follow-up tickets
|
||||
|
||||
- `ticket-built-in-feature-tools`
|
||||
- `ticket-intake-workflow`
|
||||
- `ticket-orchestrator-routing`
|
||||
|
|
@ -0,0 +1,7 @@
|
|||
<!-- event: create author: tickets.sh at: 2026-06-05T04:01:04Z -->
|
||||
|
||||
## Created
|
||||
|
||||
Created by tickets.sh create.
|
||||
|
||||
---
|
||||
|
|
@ -0,0 +1,103 @@
|
|||
---
|
||||
id: 20260605-040104-ticket-orchestrator-routing
|
||||
slug: ticket-orchestrator-routing
|
||||
title: Ticket orchestrator routing
|
||||
status: open
|
||||
kind: task
|
||||
priority: P1
|
||||
labels: [ticket, orchestrator, routing, orchestration]
|
||||
created_at: 2026-06-05T04:01:04Z
|
||||
updated_at: 2026-06-05T04:01:25Z
|
||||
assignee: null
|
||||
legacy_ticket: null
|
||||
---
|
||||
|
||||
## Background
|
||||
|
||||
Once Tickets can be created by Intake and read/mutated through built-in Ticket tools, Orchestrator needs a routing layer that decides what should happen next for each Ticket.
|
||||
|
||||
This is not an unattended scheduler MVP. The goal is to make Orchestrator's next-action classification explicit and tool/workflow-backed, so multi-agent operation can move from ad hoc conversation into repeatable routing decisions.
|
||||
|
||||
## Requirements
|
||||
|
||||
- Define Orchestrator routing states for Tickets.
|
||||
- Route Tickets into next actions such as:
|
||||
- requirements sync / return to Intake or human;
|
||||
- preflight;
|
||||
- read-only spike/investigation;
|
||||
- implementation-ready delegation;
|
||||
- review loop;
|
||||
- blocked/action-required;
|
||||
- close/complete;
|
||||
- defer/pending.
|
||||
- Use Ticket fields/events rather than hidden conversation state as routing authority.
|
||||
- Produce an intent packet for implementation-ready Tickets that can be handed to `multi-agent-workflow`.
|
||||
- Preserve current manual merge/close authority unless explicitly authorized otherwise.
|
||||
- Keep final design-boundary decisions, merge, cleanup, and Ticket close under Orchestrator/human control.
|
||||
- Avoid automatic scheduler/lease behavior in MVP.
|
||||
|
||||
## Candidate routing classification
|
||||
|
||||
```text
|
||||
implementation_ready:
|
||||
- Ticket has requirements, acceptance criteria, non-goals/invariants where needed, and validation guidance.
|
||||
- Orchestrator may create worktree + coder/reviewer assignment through existing multi-agent workflow.
|
||||
|
||||
preflight_needed:
|
||||
- Ticket touches design/authority/scope/history/prompt-context or has multiple plausible implementation strategies.
|
||||
- Orchestrator should run ticket-preflight-workflow before implementation.
|
||||
|
||||
requirements_sync_needed:
|
||||
- Ticket purpose is visible but user-facing behavior, terms, scope, or acceptance criteria are unclear.
|
||||
- Return to Intake/human.
|
||||
|
||||
spike_needed:
|
||||
- Technical feasibility, dependency/licensing/performance/diagnostic behavior, or current-code mapping must be investigated first.
|
||||
- Spawn read-only investigation if authorized.
|
||||
|
||||
review_needed:
|
||||
- Implementation report/diff exists and external review has not approved.
|
||||
|
||||
blocked_action_required:
|
||||
- Human decision or external event is required.
|
||||
|
||||
closed_or_noop:
|
||||
- No routing action.
|
||||
```
|
||||
|
||||
## Integration points
|
||||
|
||||
- Existing `.yoi/workflow/multi-agent-workflow.md` remains the implementation/review delegation workflow.
|
||||
- Existing `.yoi/workflow/ticket-preflight-workflow.md` remains the preflight workflow.
|
||||
- Ticket tools provide list/show/comment/update operations.
|
||||
- Future action-required UI/dashboard state can consume the routing result, but UI work is not required in this ticket.
|
||||
|
||||
## Non-goals
|
||||
|
||||
- Building an unattended scheduler.
|
||||
- LeaseStore / queue persistence.
|
||||
- Automatically spawning Pods without human/orchestrator authorization.
|
||||
- Implementing Ticket backend/tools.
|
||||
- Implementing Intake workflow.
|
||||
- Building TUI spawned-Pod panel.
|
||||
- Changing merge/close policy.
|
||||
- Replacing `multi-agent-workflow`.
|
||||
|
||||
## Acceptance criteria
|
||||
|
||||
- Orchestrator has a documented and testable routing classification over Tickets.
|
||||
- Routing decisions are based on Ticket fields/events and current repository/Pod state that is explicitly inspected.
|
||||
- Orchestrator can produce a concise intent packet for implementation-ready Tickets.
|
||||
- Orchestrator can record routing decisions/comments back to the Ticket.
|
||||
- Preflight-needed Tickets are not blindly delegated to coder Pods.
|
||||
- Requirements-sync/spike/blocked classifications produce clear next questions or follow-up actions.
|
||||
- Existing multi-agent workflow remains the execution path for coder/reviewer delegation.
|
||||
- No automatic scheduler/lease system is introduced.
|
||||
- Focused tests/docs/workflow updates cover classification behavior where applicable.
|
||||
- `cargo check --workspace --all-targets`, `cargo fmt --check`, `git diff --check`, and `./tickets.sh doctor` pass if code changes are included.
|
||||
|
||||
## Dependencies
|
||||
|
||||
- Requires `ticket-local-files-backend`.
|
||||
- Requires `ticket-built-in-feature-tools` for tool-backed routing updates.
|
||||
- Benefits from `ticket-intake-workflow`, but can be preflighted in parallel once Ticket fields are stable.
|
||||
|
|
@ -0,0 +1,7 @@
|
|||
<!-- event: create author: tickets.sh at: 2026-06-05T04:01:04Z -->
|
||||
|
||||
## Created
|
||||
|
||||
Created by tickets.sh create.
|
||||
|
||||
---
|
||||
|
|
@ -2,12 +2,12 @@
|
|||
id: 20260527-000017-tui-spawned-pod-panel
|
||||
slug: tui-spawned-pod-panel
|
||||
title: TUI: spawned child Pod の一覧と一時 attach
|
||||
status: open
|
||||
status: pending
|
||||
kind: task
|
||||
priority: P2
|
||||
labels: [migrated]
|
||||
created_at: 2026-05-27T00:00:17Z
|
||||
updated_at: 2026-05-28T14:16:02Z
|
||||
updated_at: 2026-06-05T04:03:38Z
|
||||
assignee: null
|
||||
legacy_ticket: tickets/tui-spawned-pod-panel.md
|
||||
---
|
||||
|
|
@ -0,0 +1,20 @@
|
|||
<!-- event: migration author: tickets.sh-migration at: 2026-05-27T00:00:17Z -->
|
||||
|
||||
## Migrated
|
||||
|
||||
Migrated from tickets/tui-spawned-pod-panel.md. No legacy review file was present at migration time.
|
||||
|
||||
---
|
||||
|
||||
<!-- event: decision author: hare at: 2026-06-05T04:03:38Z -->
|
||||
|
||||
## Decision
|
||||
|
||||
Decision: deprioritize this ticket for the current multi-agent system direction.
|
||||
|
||||
Current need is not a TUI panel for spawned Pods. The priority is Ticket-driven intake/routing: making Tickets a code-facing durable orchestration record, then exposing Ticket operations to Intake/Orchestrator through a typed backend/tool surface.
|
||||
|
||||
This ticket is not closed as technically invalid; it is moved out of the active multi-agent implementation path. Revisit only if direct child Pod visibility/attach UI becomes a concrete UX requirement.
|
||||
|
||||
|
||||
---
|
||||
Loading…
Reference in New Issue
Block a user