103 lines
4.2 KiB
Markdown
103 lines
4.2 KiB
Markdown
# Delegation intent: typed Ticket thread event log
|
|
|
|
## Classification
|
|
|
|
`implementation-ready` foundational backend/API slice before `explicit-ticket-workflow-state`.
|
|
|
|
The explicit workflow-state ticket needs a reliable audit/event path for state transitions. This ticket should first make the existing Ticket thread format more typed and useful without rewriting history or changing panel workflow semantics yet.
|
|
|
|
## Intent
|
|
|
|
Turn `thread.md` into a concise typed append-only event log for durable Ticket events, especially state transitions and Intake summaries. Keep current state in `item.md` frontmatter; keep full conversations in Pod/session logs.
|
|
|
|
## Worktree / branch
|
|
|
|
- worktree: `/home/hare/Projects/yoi/.worktree/typed-ticket-thread-event-log`
|
|
- branch: `work/typed-ticket-thread-event-log`
|
|
|
|
This ticket may read tracked `.yoi/tickets` records/design artifacts. Do not read or edit `.yoi/memory/`.
|
|
|
|
## Requirements
|
|
|
|
- Add/formalize typed event kinds for at least:
|
|
- `state_changed`;
|
|
- `intake_summary`.
|
|
- Preserve existing event kinds and historical compatibility:
|
|
- `create`;
|
|
- `comment`;
|
|
- `plan`;
|
|
- `decision`;
|
|
- `implementation_report`;
|
|
- `review`;
|
|
- `status_changed`;
|
|
- `close`.
|
|
- Add typed Rust data/API for appending a `state_changed` event with fields such as:
|
|
- `from`;
|
|
- `to`;
|
|
- `actor` or `author`;
|
|
- `reason`;
|
|
- optional concise `summary` / refs body.
|
|
- Add typed Rust data/API for appending an `intake_summary` event with a bounded Markdown body and/or structured heading metadata.
|
|
- Keep `thread.md` append-only.
|
|
- Do not use thread events as the current-state authority; this ticket may add event APIs, but `explicit-ticket-workflow-state` owns current workflow frontmatter fields.
|
|
- If a minimal state-transition helper is added, keep it forward-compatible with frontmatter state updates; do not invent a separate scheduler/state machine.
|
|
- Update parser/doctor to understand the new event kinds and required attributes where practical.
|
|
- `state_changed` should require `from`, `to`, `author/actor`, and `at` or equivalent.
|
|
- `intake_summary` should require normal event metadata and a non-empty body where practical.
|
|
- Keep existing Ticket tools/CLI working.
|
|
- Avoid mass rewriting historical `thread.md` records.
|
|
- Update docs/comments that describe thread role/event meanings.
|
|
|
|
## Current code map
|
|
|
|
- `crates/ticket/src/lib.rs`
|
|
- `TicketEventKind` currently supports `StatusChanged` and `Other`.
|
|
- `LocalTicketBackend::append_thread_event(...)` writes HTML comment event metadata.
|
|
- `parse_thread(...)`, `parse_event_comment(...)`, `doctor_thread_events(...)` parse/validate thread events.
|
|
- `LocalTicketBackend::add_event(...)`, `review(...)`, `status(...)`, and `close(...)` are existing mutation paths.
|
|
- `crates/ticket/src/tool.rs`
|
|
- `TicketComment` currently exposes only `comment`, `plan`, `decision`, `implementation_report` roles. Consider whether to expose new event kinds now or keep them backend-only for first slice.
|
|
- `crates/yoi/src/ticket_cli.rs`
|
|
- Direct CLI paths for comment/review/status/close; update only if new event API needs direct maintainer exposure.
|
|
- `docs/development/work-items.md`
|
|
- Update thread semantics if touched.
|
|
|
|
## Non-goals
|
|
|
|
- Implementing explicit `workflow_state` frontmatter fields; next ticket owns that.
|
|
- Replacing Pod/session logs.
|
|
- Capturing full Intake conversations in Ticket thread.
|
|
- Rewriting all historical thread files.
|
|
- Building scheduler/lease/queue behavior.
|
|
- Panel layout changes.
|
|
|
|
## Validation
|
|
|
|
Run at least:
|
|
|
|
- `cargo test -p ticket thread` or targeted new thread event tests;
|
|
- `cargo test -p ticket`;
|
|
- `cargo test -p yoi ticket` if CLI/tool-visible behavior changes;
|
|
- `cargo test -p pod ticket --lib` if Ticket tools change;
|
|
- `cargo check --workspace --all-targets`;
|
|
- `cargo fmt --check`;
|
|
- `git diff --check`;
|
|
- `cargo build -p yoi`;
|
|
- `target/debug/yoi ticket doctor`.
|
|
|
|
Run `nix build .#yoi --no-link` if feasible.
|
|
|
|
## Completion report
|
|
|
|
Report:
|
|
|
|
- worktree path / branch;
|
|
- commit hash;
|
|
- new event kinds and metadata fields;
|
|
- backend APIs added;
|
|
- parser/doctor behavior;
|
|
- tool/CLI/doc updates, if any;
|
|
- historical compatibility behavior;
|
|
- validation results;
|
|
- whether `explicit-ticket-workflow-state` can proceed.
|