ticket: use base32 project record ids
This commit is contained in:
@@ -0,0 +1,65 @@
|
||||
# Implementation report: ticket-intake-workflow
|
||||
|
||||
## Summary
|
||||
|
||||
Added the user-invocable Ticket Intake workflow and lightly updated workflow development documentation.
|
||||
|
||||
The workflow defines Intake as the clarification/materialization boundary between a user's request and Orchestrator routing. Intake clarifies the request, checks duplicate/related Tickets, prepares a draft, obtains user agreement, and creates/updates Tickets through typed Ticket tools.
|
||||
|
||||
## Changed files
|
||||
|
||||
- `.yoi/workflow/ticket-intake-workflow.md`
|
||||
- `docs/development/workflows.md`
|
||||
|
||||
## Workflow behavior
|
||||
|
||||
The new workflow covers:
|
||||
|
||||
- user intent clarification;
|
||||
- duplicate/related Ticket checks with `TicketList` / `TicketShow`;
|
||||
- requirements, acceptance criteria, non-goals, escalation conditions, validation, and related-work capture;
|
||||
- explicit readiness classification:
|
||||
- `implementation_ready`;
|
||||
- `requirements_sync_needed`;
|
||||
- `spike_needed`;
|
||||
- `blocked`;
|
||||
- `unspecified` only with reason;
|
||||
- `needs_preflight` and risk flag handling;
|
||||
- user agreement before official Ticket creation;
|
||||
- `TicketCreate` for new Tickets;
|
||||
- `TicketComment` for existing Ticket refinement;
|
||||
- fail-closed behavior when typed Ticket tools are unavailable;
|
||||
- secret/private-context non-persistence rules;
|
||||
- handoff to `ticket-preflight-workflow`, `multi-agent-workflow`, `auto-maintain`, and future `ticket-orchestrator-routing`.
|
||||
|
||||
## Non-goals preserved
|
||||
|
||||
The workflow explicitly avoids:
|
||||
|
||||
- scheduling implementation;
|
||||
- spawning coder/reviewer/investigator Pods;
|
||||
- creating worktrees;
|
||||
- merge/close/branch cleanup;
|
||||
- unattended automation;
|
||||
- user-agreement-free Ticket creation;
|
||||
- arbitrary filesystem writes to `work-items/`.
|
||||
|
||||
## Review status
|
||||
|
||||
External sibling reviewer approved with no blockers.
|
||||
|
||||
Reviewer non-blocker about an old `work items` phrase in `docs/development/workflows.md` was fixed before commit.
|
||||
|
||||
Remaining follow-up:
|
||||
|
||||
- If a future first-class `TicketUpdate` tool is added, the existing-Ticket refinement path should decide when to use it versus `TicketComment`.
|
||||
|
||||
## Validation
|
||||
|
||||
Validation passed:
|
||||
|
||||
- `git diff --check`
|
||||
- `./tickets.sh doctor`
|
||||
- targeted grep found no `WorkItem` / old system-name wording in the new workflow.
|
||||
|
||||
No code/package changes were made, so `cargo check`, `cargo fmt`, and `nix build` were not necessary for this workflow/docs-only change.
|
||||
@@ -0,0 +1,55 @@
|
||||
# Review: ticket-intake-workflow
|
||||
|
||||
## 1. Result: approve
|
||||
|
||||
Approve. I found no blockers for commit/close.
|
||||
|
||||
## 2. Summary
|
||||
|
||||
The new `ticket-intake-workflow` satisfies the ticket requirements and fits the current multi-agent direction. It defines Intake as a clarification/materialization boundary before Orchestrator routing, keeps implementation scheduling out of scope, requires user agreement before official Ticket creation, and uses typed Ticket tools instead of arbitrary `work-items/` file writes.
|
||||
|
||||
The `docs/development/workflows.md` update is small and accurate for the new workflow theme and child-Pod review responsibilities.
|
||||
|
||||
## 3. Requirement assessment
|
||||
|
||||
- Ticket terminology: pass. The new workflow consistently uses `Ticket` terminology and does not introduce WorkItem or insomnia wording. The only `work-items/` mention is the explicit prohibition against arbitrary filesystem edits, which matches the ticket authority-boundary requirement.
|
||||
- Intake responsibilities: pass. The workflow covers intent clarification, duplicate/related Ticket checks, relevant repository reading when needed and permitted, clarifying questions, draft title/kind/priority/labels, and Ticket creation/update reporting.
|
||||
- Intake non-goals: pass. The workflow explicitly forbids coder/reviewer/investigator Pod spawning, worktree creation, merge/close/branch cleanup, unattended scheduling, and implementation routing from Intake.
|
||||
- User agreement: pass. It requires a pre-creation draft and official Ticket creation only after explicit approval or an explicit create/record request.
|
||||
- Typed Ticket tools: pass. It directs agents to use `TicketList`, `TicketShow`, `TicketCreate`, `TicketComment`, and `TicketDoctor`, and says not to fall back to filesystem writes when tools are unavailable.
|
||||
- Routing fields: pass. Readiness classification, `needs_preflight`, risk flags, acceptance criteria, escalation conditions, validation, and related work are represented in both the draft and recommended Ticket body.
|
||||
- Secret/private handling: pass. It explicitly forbids persisting API keys, tokens, credentials, secret file contents, private prompts/responses, unnecessary private context, and raw secret-bearing logs.
|
||||
- Workflow connections: pass. It connects to `ticket-preflight-workflow` for risk/uncertainty, `multi-agent-workflow` after implementation readiness, `auto-maintain` as an intake source, and future `ticket-orchestrator-routing` as the next routing layer.
|
||||
- Docs update: pass. The docs change adds Intake to current workflow themes and updates child-Pod verification language from old ticket/work-item wording to Ticket requirements and acceptance criteria.
|
||||
|
||||
## 4. Blockers
|
||||
|
||||
None.
|
||||
|
||||
## 5. Non-blockers / follow-ups
|
||||
|
||||
- Note: `docs/development/workflows.md` still contains the pre-existing phrase "replacement for work items" in the general workflow-role paragraph. The implementation diff did not introduce it and the changed lines use Ticket terminology, so I do not consider it a blocker. If the documentation pass is intended to eliminate all old wording globally, that line can be normalized in a follow-up.
|
||||
- Future follow-up: if a first-class `TicketUpdate` tool becomes part of the typed Ticket surface, the existing-Ticket refinement path should decide when to use it versus `TicketComment`. The current workflow is acceptable because it avoids arbitrary file writes and records refinements through typed Ticket comments.
|
||||
|
||||
## 6. Validation assessed
|
||||
|
||||
Reviewed:
|
||||
|
||||
- `work-items/open/20260605-040104-ticket-intake-workflow/item.md`
|
||||
- `.yoi/workflow/ticket-intake-workflow.md`
|
||||
- `docs/development/workflows.md`
|
||||
- `.yoi/workflow/ticket-preflight-workflow.md`
|
||||
- `.yoi/workflow/multi-agent-workflow.md`
|
||||
|
||||
Checks run:
|
||||
|
||||
- `git diff -- .yoi/workflow/ticket-intake-workflow.md docs/development/workflows.md work-items/open/20260605-040104-ticket-intake-workflow/item.md`
|
||||
- `git diff --check -- .yoi/workflow/ticket-intake-workflow.md docs/development/workflows.md work-items/open/20260605-040104-ticket-intake-workflow/item.md` — passed
|
||||
- `./tickets.sh doctor` — passed
|
||||
- Targeted terminology grep for `WorkItem`, `insomnia`, `work item`, `work-items`, and `Ticket`
|
||||
|
||||
I did not run `cargo check`, `cargo fmt`, or `nix build` because this review found only workflow/docs changes and no code/package changes to validate.
|
||||
|
||||
## 7. Residual risk
|
||||
|
||||
The main residual risk is dependency timing: the workflow assumes typed Ticket tools are available, while the ticket states those tools/backend are dependencies. The workflow handles unavailable tools by failing closed and returning to a human/parent workflow, so this is an integration dependency rather than a blocker in the workflow text.
|
||||
@@ -0,0 +1,87 @@
|
||||
---
|
||||
title: "Ticket intake workflow"
|
||||
state: "closed"
|
||||
created_at: "2026-06-05T04:01:04Z"
|
||||
updated_at: "2026-06-05T06:10:56Z"
|
||||
---
|
||||
|
||||
## 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,29 @@
|
||||
Ticket Intake Workflow is complete.
|
||||
|
||||
Implementation:
|
||||
|
||||
- commit: `1233833 workflow: add ticket intake`
|
||||
|
||||
Summary:
|
||||
|
||||
- Added `.yoi/workflow/ticket-intake-workflow.md` as a user-invocable/model-invocable workflow.
|
||||
- Updated `docs/development/workflows.md` to include Intake clarification and Ticket terminology.
|
||||
- The workflow defines Intake as the clarification/materialization boundary before Orchestrator routing.
|
||||
- It requires duplicate/related Ticket checks, readiness classification, needs-preflight/risk flags, draft presentation, and explicit user agreement before official Ticket creation.
|
||||
- It uses typed Ticket tools (`TicketList`, `TicketShow`, `TicketCreate`, `TicketComment`, `TicketDoctor`) and forbids arbitrary filesystem edits to `work-items/`.
|
||||
- It explicitly excludes scheduling, Pod spawning, worktree creation, merge/close, unattended automation, and user-agreement-free Ticket creation.
|
||||
- It documents secret/private-context non-persistence rules.
|
||||
|
||||
Review:
|
||||
|
||||
- External sibling reviewer approved with no blockers.
|
||||
- Reviewer non-blocker about old `work items` wording in `docs/development/workflows.md` was fixed before commit.
|
||||
- Follow-up: if a future `TicketUpdate` tool is added, refine the existing-Ticket update path to choose between `TicketUpdate` and `TicketComment`.
|
||||
|
||||
Validation passed:
|
||||
|
||||
- `git diff --check`
|
||||
- `./tickets.sh doctor`
|
||||
- targeted grep found no `WorkItem` / old system-name wording in the new workflow.
|
||||
|
||||
No code/package changes were made, so cargo/nix validation was not required.
|
||||
@@ -0,0 +1,180 @@
|
||||
<!-- event: create author: tickets.sh at: 2026-06-05T04:01:04Z -->
|
||||
|
||||
## Created
|
||||
|
||||
Created by tickets.sh create.
|
||||
|
||||
---
|
||||
|
||||
<!-- event: review author: hare at: 2026-06-05T06:10:31Z status: approve -->
|
||||
|
||||
## Review: approve
|
||||
|
||||
# Review: ticket-intake-workflow
|
||||
|
||||
## 1. Result: approve
|
||||
|
||||
Approve. I found no blockers for commit/close.
|
||||
|
||||
## 2. Summary
|
||||
|
||||
The new `ticket-intake-workflow` satisfies the ticket requirements and fits the current multi-agent direction. It defines Intake as a clarification/materialization boundary before Orchestrator routing, keeps implementation scheduling out of scope, requires user agreement before official Ticket creation, and uses typed Ticket tools instead of arbitrary `work-items/` file writes.
|
||||
|
||||
The `docs/development/workflows.md` update is small and accurate for the new workflow theme and child-Pod review responsibilities.
|
||||
|
||||
## 3. Requirement assessment
|
||||
|
||||
- Ticket terminology: pass. The new workflow consistently uses `Ticket` terminology and does not introduce WorkItem or insomnia wording. The only `work-items/` mention is the explicit prohibition against arbitrary filesystem edits, which matches the ticket authority-boundary requirement.
|
||||
- Intake responsibilities: pass. The workflow covers intent clarification, duplicate/related Ticket checks, relevant repository reading when needed and permitted, clarifying questions, draft title/kind/priority/labels, and Ticket creation/update reporting.
|
||||
- Intake non-goals: pass. The workflow explicitly forbids coder/reviewer/investigator Pod spawning, worktree creation, merge/close/branch cleanup, unattended scheduling, and implementation routing from Intake.
|
||||
- User agreement: pass. It requires a pre-creation draft and official Ticket creation only after explicit approval or an explicit create/record request.
|
||||
- Typed Ticket tools: pass. It directs agents to use `TicketList`, `TicketShow`, `TicketCreate`, `TicketComment`, and `TicketDoctor`, and says not to fall back to filesystem writes when tools are unavailable.
|
||||
- Routing fields: pass. Readiness classification, `needs_preflight`, risk flags, acceptance criteria, escalation conditions, validation, and related work are represented in both the draft and recommended Ticket body.
|
||||
- Secret/private handling: pass. It explicitly forbids persisting API keys, tokens, credentials, secret file contents, private prompts/responses, unnecessary private context, and raw secret-bearing logs.
|
||||
- Workflow connections: pass. It connects to `ticket-preflight-workflow` for risk/uncertainty, `multi-agent-workflow` after implementation readiness, `auto-maintain` as an intake source, and future `ticket-orchestrator-routing` as the next routing layer.
|
||||
- Docs update: pass. The docs change adds Intake to current workflow themes and updates child-Pod verification language from old ticket/work-item wording to Ticket requirements and acceptance criteria.
|
||||
|
||||
## 4. Blockers
|
||||
|
||||
None.
|
||||
|
||||
## 5. Non-blockers / follow-ups
|
||||
|
||||
- Note: `docs/development/workflows.md` still contains the pre-existing phrase "replacement for work items" in the general workflow-role paragraph. The implementation diff did not introduce it and the changed lines use Ticket terminology, so I do not consider it a blocker. If the documentation pass is intended to eliminate all old wording globally, that line can be normalized in a follow-up.
|
||||
- Future follow-up: if a first-class `TicketUpdate` tool becomes part of the typed Ticket surface, the existing-Ticket refinement path should decide when to use it versus `TicketComment`. The current workflow is acceptable because it avoids arbitrary file writes and records refinements through typed Ticket comments.
|
||||
|
||||
## 6. Validation assessed
|
||||
|
||||
Reviewed:
|
||||
|
||||
- `work-items/open/20260605-040104-ticket-intake-workflow/item.md`
|
||||
- `.yoi/workflow/ticket-intake-workflow.md`
|
||||
- `docs/development/workflows.md`
|
||||
- `.yoi/workflow/ticket-preflight-workflow.md`
|
||||
- `.yoi/workflow/multi-agent-workflow.md`
|
||||
|
||||
Checks run:
|
||||
|
||||
- `git diff -- .yoi/workflow/ticket-intake-workflow.md docs/development/workflows.md work-items/open/20260605-040104-ticket-intake-workflow/item.md`
|
||||
- `git diff --check -- .yoi/workflow/ticket-intake-workflow.md docs/development/workflows.md work-items/open/20260605-040104-ticket-intake-workflow/item.md` — passed
|
||||
- `./tickets.sh doctor` — passed
|
||||
- Targeted terminology grep for `WorkItem`, `insomnia`, `work item`, `work-items`, and `Ticket`
|
||||
|
||||
I did not run `cargo check`, `cargo fmt`, or `nix build` because this review found only workflow/docs changes and no code/package changes to validate.
|
||||
|
||||
## 7. Residual risk
|
||||
|
||||
The main residual risk is dependency timing: the workflow assumes typed Ticket tools are available, while the ticket states those tools/backend are dependencies. The workflow handles unavailable tools by failing closed and returning to a human/parent workflow, so this is an integration dependency rather than a blocker in the workflow text.
|
||||
|
||||
|
||||
---
|
||||
|
||||
<!-- event: implementation_report author: hare at: 2026-06-05T06:10:32Z -->
|
||||
|
||||
## Implementation report
|
||||
|
||||
# Implementation report: ticket-intake-workflow
|
||||
|
||||
## Summary
|
||||
|
||||
Added the user-invocable Ticket Intake workflow and lightly updated workflow development documentation.
|
||||
|
||||
The workflow defines Intake as the clarification/materialization boundary between a user's request and Orchestrator routing. Intake clarifies the request, checks duplicate/related Tickets, prepares a draft, obtains user agreement, and creates/updates Tickets through typed Ticket tools.
|
||||
|
||||
## Changed files
|
||||
|
||||
- `.yoi/workflow/ticket-intake-workflow.md`
|
||||
- `docs/development/workflows.md`
|
||||
|
||||
## Workflow behavior
|
||||
|
||||
The new workflow covers:
|
||||
|
||||
- user intent clarification;
|
||||
- duplicate/related Ticket checks with `TicketList` / `TicketShow`;
|
||||
- requirements, acceptance criteria, non-goals, escalation conditions, validation, and related-work capture;
|
||||
- explicit readiness classification:
|
||||
- `implementation_ready`;
|
||||
- `requirements_sync_needed`;
|
||||
- `spike_needed`;
|
||||
- `blocked`;
|
||||
- `unspecified` only with reason;
|
||||
- `needs_preflight` and risk flag handling;
|
||||
- user agreement before official Ticket creation;
|
||||
- `TicketCreate` for new Tickets;
|
||||
- `TicketComment` for existing Ticket refinement;
|
||||
- fail-closed behavior when typed Ticket tools are unavailable;
|
||||
- secret/private-context non-persistence rules;
|
||||
- handoff to `ticket-preflight-workflow`, `multi-agent-workflow`, `auto-maintain`, and future `ticket-orchestrator-routing`.
|
||||
|
||||
## Non-goals preserved
|
||||
|
||||
The workflow explicitly avoids:
|
||||
|
||||
- scheduling implementation;
|
||||
- spawning coder/reviewer/investigator Pods;
|
||||
- creating worktrees;
|
||||
- merge/close/branch cleanup;
|
||||
- unattended automation;
|
||||
- user-agreement-free Ticket creation;
|
||||
- arbitrary filesystem writes to `work-items/`.
|
||||
|
||||
## Review status
|
||||
|
||||
External sibling reviewer approved with no blockers.
|
||||
|
||||
Reviewer non-blocker about an old `work items` phrase in `docs/development/workflows.md` was fixed before commit.
|
||||
|
||||
Remaining follow-up:
|
||||
|
||||
- If a future first-class `TicketUpdate` tool is added, the existing-Ticket refinement path should decide when to use it versus `TicketComment`.
|
||||
|
||||
## Validation
|
||||
|
||||
Validation passed:
|
||||
|
||||
- `git diff --check`
|
||||
- `./tickets.sh doctor`
|
||||
- targeted grep found no `WorkItem` / old system-name wording in the new workflow.
|
||||
|
||||
No code/package changes were made, so `cargo check`, `cargo fmt`, and `nix build` were not necessary for this workflow/docs-only change.
|
||||
|
||||
|
||||
---
|
||||
|
||||
<!-- event: close author: hare at: 2026-06-05T06:10:56Z status: closed -->
|
||||
|
||||
## Closed
|
||||
|
||||
Ticket Intake Workflow is complete.
|
||||
|
||||
Implementation:
|
||||
|
||||
- commit: `1233833 workflow: add ticket intake`
|
||||
|
||||
Summary:
|
||||
|
||||
- Added `.yoi/workflow/ticket-intake-workflow.md` as a user-invocable/model-invocable workflow.
|
||||
- Updated `docs/development/workflows.md` to include Intake clarification and Ticket terminology.
|
||||
- The workflow defines Intake as the clarification/materialization boundary before Orchestrator routing.
|
||||
- It requires duplicate/related Ticket checks, readiness classification, needs-preflight/risk flags, draft presentation, and explicit user agreement before official Ticket creation.
|
||||
- It uses typed Ticket tools (`TicketList`, `TicketShow`, `TicketCreate`, `TicketComment`, `TicketDoctor`) and forbids arbitrary filesystem edits to `work-items/`.
|
||||
- It explicitly excludes scheduling, Pod spawning, worktree creation, merge/close, unattended automation, and user-agreement-free Ticket creation.
|
||||
- It documents secret/private-context non-persistence rules.
|
||||
|
||||
Review:
|
||||
|
||||
- External sibling reviewer approved with no blockers.
|
||||
- Reviewer non-blocker about old `work items` wording in `docs/development/workflows.md` was fixed before commit.
|
||||
- Follow-up: if a future `TicketUpdate` tool is added, refine the existing-Ticket update path to choose between `TicketUpdate` and `TicketComment`.
|
||||
|
||||
Validation passed:
|
||||
|
||||
- `git diff --check`
|
||||
- `./tickets.sh doctor`
|
||||
- targeted grep found no `WorkItem` / old system-name wording in the new workflow.
|
||||
|
||||
No code/package changes were made, so cargo/nix validation was not required.
|
||||
|
||||
|
||||
---
|
||||
Reference in New Issue
Block a user