4.0 KiB
4.0 KiB
| id | slug | title | status | kind | priority | labels | created_at | updated_at | assignee | legacy_ticket | ||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 20260605-040104-ticket-intake-workflow | ticket-intake-workflow | Ticket intake workflow | open | task | P1 |
|
2026-06-05T04:01:04Z | 2026-06-05T06:10:32Z | null | 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
unspecifiedonly when unavoidable.
- Intake should mark
needs_preflightfor 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_neededorspike_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 doctorpass if code changes are included.
Dependencies
- Requires
ticket-local-files-backend. - Requires
ticket-built-in-feature-toolsfor the intended authority boundary.
Follow-up tickets
ticket-orchestrator-routing