ticket: preflight yoi ticket cli

This commit is contained in:
Keisuke Hirata 2026-06-06 05:34:39 +09:00
parent 0b279ef6d8
commit d725fb81d6
No known key found for this signature in database
3 changed files with 197 additions and 1 deletions

View File

@ -0,0 +1,94 @@
# Delegation intent: yoi ticket CLI parity
## Intent
Add `yoi ticket ...` CLI operations over the Rust Ticket backend so direct Ticket mutation is owned by the `yoi` binary rather than `tickets.sh`.
This is the first step in the Yoi-local Ticket backend migration. `tickets.sh` remains in place for this ticket only as transitional compatibility and validation reference.
## Worktree / branch
- worktree: `/home/hare/Projects/yoi/.worktree/yoi-ticket-cli-parity`
- branch: `work/yoi-ticket-cli-parity`
## Requirements
Implement these subcommands in the top-level `yoi` binary crate:
- `yoi ticket create --title "..." [--slug slug] [--kind task] [--priority P2] [--label a,b]`
- `yoi ticket list [--status open|pending|closed|all]`
- `yoi ticket show <id-or-slug>`
- `yoi ticket comment <id-or-slug> [--role comment|plan|decision|implementation_report] [--file path|--message text]`
- `yoi ticket review <id-or-slug> --approve|--request-changes [--file path|--message text]`
- `yoi ticket status <id-or-slug> open|pending|closed`
- `yoi ticket close <id-or-slug> [--resolution text|--file path]`
- `yoi ticket doctor`
Use `crates/ticket` backend APIs directly. Do not shell out to `tickets.sh`.
## Current code map
- `crates/yoi/src/main.rs`
- Owns top-level CLI parsing and dispatch.
- Existing subcommands include `pod`, `keys`, and `memory lint`.
- Add `ticket` parsing/dispatch here or in a new module such as `crates/yoi/src/ticket_cli.rs`.
- `crates/yoi/Cargo.toml`
- Add dependency on `ticket` if needed.
- `crates/ticket/src/lib.rs`
- Ticket domain/backend APIs: `LocalTicketBackend`, `TicketBackend`, `NewTicket`, `NewTicketEvent`, `TicketReview`, status/review/event types, doctor reports.
- `crates/ticket/src/config.rs`
- Workspace ticket config and backend root defaults. Use if it helps locate backend root; otherwise current active storage is still `work-items/` for this ticket.
- `tickets.sh`
- Compatibility/reference only. Do not invoke it from Rust code.
## Scope notes
- Active storage stays where it is for this ticket (`work-items/` unless config already directs otherwise).
- Keep `tickets.sh` in place.
- CLI output does not need exact `tickets.sh` formatting, but should be understandable and stable enough for tests.
- Prefer concise plain text output for human CLI; JSON is not required unless already easy.
- `yoi ticket doctor` should be usable as the future validation command.
## Non-goals
- Moving storage to `.yoi/tickets/`.
- Removing `tickets.sh`.
- Adding external tracker backends.
- TUI changes.
- Scheduler/lease/queue.
- Broad CLI framework refactor.
## Edge cases / validation expectations
- `comment` / `review` should accept exactly one body source: `--file` or `--message`, or provide a clear error.
- `review` requires exactly one of `--approve` / `--request-changes`.
- `close` requires resolution text/file or a clear error if the backend cannot close without a resolution.
- `status closed` should preserve backend semantics. If direct status-to-closed cannot write a resolution, either reject it with guidance to use `close` or keep parity only if existing backend supports it safely.
- `doctor` should print diagnostics and return non-zero on failures.
- `--help` for `yoi ticket` should document subcommands.
## Validation
Run at least:
- focused `cargo test -p yoi ticket` tests;
- `cargo test -p ticket`;
- `cargo check --workspace --all-targets`;
- `cargo fmt --check`;
- `git diff --check`;
- `./tickets.sh doctor`;
- built binary `yoi ticket doctor` against the repository if possible.
Run `nix build .#yoi --no-link` if feasible.
## Completion report
Report:
- worktree path / branch;
- commit hash;
- implemented command surface;
- backend root resolution behavior;
- tests/validation results;
- known compatibility gaps from `tickets.sh`, if any;
- whether ready for external review.

View File

@ -7,7 +7,7 @@ kind: task
priority: P1
labels: [ticket, cli, backend]
created_at: 2026-06-05T20:30:06Z
updated_at: 2026-06-05T20:30:06Z
updated_at: 2026-06-05T20:34:35Z
assignee: null
legacy_ticket: null
---

View File

@ -4,4 +4,106 @@
Created by tickets.sh create.
---
<!-- event: plan author: hare at: 2026-06-05T20:34:35Z -->
## Plan
# Delegation intent: yoi ticket CLI parity
## Intent
Add `yoi ticket ...` CLI operations over the Rust Ticket backend so direct Ticket mutation is owned by the `yoi` binary rather than `tickets.sh`.
This is the first step in the Yoi-local Ticket backend migration. `tickets.sh` remains in place for this ticket only as transitional compatibility and validation reference.
## Worktree / branch
- worktree: `/home/hare/Projects/yoi/.worktree/yoi-ticket-cli-parity`
- branch: `work/yoi-ticket-cli-parity`
## Requirements
Implement these subcommands in the top-level `yoi` binary crate:
- `yoi ticket create --title "..." [--slug slug] [--kind task] [--priority P2] [--label a,b]`
- `yoi ticket list [--status open|pending|closed|all]`
- `yoi ticket show <id-or-slug>`
- `yoi ticket comment <id-or-slug> [--role comment|plan|decision|implementation_report] [--file path|--message text]`
- `yoi ticket review <id-or-slug> --approve|--request-changes [--file path|--message text]`
- `yoi ticket status <id-or-slug> open|pending|closed`
- `yoi ticket close <id-or-slug> [--resolution text|--file path]`
- `yoi ticket doctor`
Use `crates/ticket` backend APIs directly. Do not shell out to `tickets.sh`.
## Current code map
- `crates/yoi/src/main.rs`
- Owns top-level CLI parsing and dispatch.
- Existing subcommands include `pod`, `keys`, and `memory lint`.
- Add `ticket` parsing/dispatch here or in a new module such as `crates/yoi/src/ticket_cli.rs`.
- `crates/yoi/Cargo.toml`
- Add dependency on `ticket` if needed.
- `crates/ticket/src/lib.rs`
- Ticket domain/backend APIs: `LocalTicketBackend`, `TicketBackend`, `NewTicket`, `NewTicketEvent`, `TicketReview`, status/review/event types, doctor reports.
- `crates/ticket/src/config.rs`
- Workspace ticket config and backend root defaults. Use if it helps locate backend root; otherwise current active storage is still `work-items/` for this ticket.
- `tickets.sh`
- Compatibility/reference only. Do not invoke it from Rust code.
## Scope notes
- Active storage stays where it is for this ticket (`work-items/` unless config already directs otherwise).
- Keep `tickets.sh` in place.
- CLI output does not need exact `tickets.sh` formatting, but should be understandable and stable enough for tests.
- Prefer concise plain text output for human CLI; JSON is not required unless already easy.
- `yoi ticket doctor` should be usable as the future validation command.
## Non-goals
- Moving storage to `.yoi/tickets/`.
- Removing `tickets.sh`.
- Adding external tracker backends.
- TUI changes.
- Scheduler/lease/queue.
- Broad CLI framework refactor.
## Edge cases / validation expectations
- `comment` / `review` should accept exactly one body source: `--file` or `--message`, or provide a clear error.
- `review` requires exactly one of `--approve` / `--request-changes`.
- `close` requires resolution text/file or a clear error if the backend cannot close without a resolution.
- `status closed` should preserve backend semantics. If direct status-to-closed cannot write a resolution, either reject it with guidance to use `close` or keep parity only if existing backend supports it safely.
- `doctor` should print diagnostics and return non-zero on failures.
- `--help` for `yoi ticket` should document subcommands.
## Validation
Run at least:
- focused `cargo test -p yoi ticket` tests;
- `cargo test -p ticket`;
- `cargo check --workspace --all-targets`;
- `cargo fmt --check`;
- `git diff --check`;
- `./tickets.sh doctor`;
- built binary `yoi ticket doctor` against the repository if possible.
Run `nix build .#yoi --no-link` if feasible.
## Completion report
Report:
- worktree path / branch;
- commit hash;
- implemented command surface;
- backend root resolution behavior;
- tests/validation results;
- known compatibility gaps from `tickets.sh`, if any;
- whether ready for external review.
---