yoi/work-items/open/20260605-040104-ticket-intake-workflow/thread.md

Created

Created by tickets.sh create.

---

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.

---

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.

---