Tickets

A ticket is a unit of trackable work that flows through a pipeline of stages — from a backlog idea to a merged pull request. Tickets can be created manually, generated from a Plan or Insight, or synced from GitHub Issues / Azure DevOps Work Items.

Pipeline stages

Pending → Queued → Implementation → Developer Approval → QA Approval → Pull Request → Completed

Stage	What it means
Pending	Created but not yet queued. Editable; can have blocker dependencies.
Queued	In the priority queue waiting for a slot.
Implementation	An AI session is actively working on the ticket.
Developer Approval	Implementation finished; waiting for developer review.
QA Approval	Developer approved; waiting for QA.
Pull Request	Approved; PR created and tracked for merge status.
Completed	PR merged (or skipped to merge).
Failed / Canceled / Merge Conflicts	Terminal states.

Lifecycle modes

Set per-workspace under Tickets Configuration:

• QA First (default) — Developer Approval → QA Approval → Pull Request
• Merge First — Pull Request is created earlier; QA reviews against the PR

You can also enable Skip QA Approval to route Developer Approval directly to Pull Request, or use Skip to Merge on individual tickets to bypass the approval flow entirely.

Per-ticket approval overrides

When creating or editing a ticket, you can enable two per-ticket overrides under Approval Overrides:

• Force No Developer — skips the Developer Approval stage for this ticket. After Implementation completes, the ticket auto-advances without waiting for developer review.
• Force No QA — skips the QA Approval stage for this ticket.

Both flags override the workspace-level settings. Combining them sends the ticket directly from Implementation to PR creation (or Direct Merge, depending on the workspace Merge Mode) without any human approval gate.

Ticket types and sources

Source	Origin
Manual	Created in the UI
External	Synced from GitHub Issues or Azure DevOps/TFS Work Items
From a Plan	Created from a completed Plan
From an Insight	Created from an extracted Insight

Ticket type tags: Bug, Feature, Task, Other.

Queue management

Queued tickets start automatically as capacity frees up:

• Priority — High-priority tickets are picked up ahead of normal-priority ones
• Max Concurrent Tickets — Configured per session host on the Hosts page; a ticket starts only when a host that can run it has free capacity
• Automatic advancement — Tickets start and advance on their own as slots become available; no manual promotion needed
• Startup Recovery — In-flight tickets resume on server restart

Toggle High Priority on a ticket to bump it ahead of normal-priority tickets.

Approval flow

Developer Approval

When implementation completes, the assigned Developer reviews:

• Approve with optional notes and file attachments
• Pass-back — send the ticket back to Implementation with a message; the agent re-enters the worktree

QA Approval

After developer approval, the assigned QA reviews:

• Approve with optional notes/attachments
• Reject with feedback text and attachments — increments the ticket's iteration count and re-enters Implementation

When a QA rejection is accepted, the original session is revived and resumes with the rejection feedback as a new user message. The session's worktree is preserved between dev-approval and QA review specifically so this revival is fast and the iteration history is unbroken.

If the worktree was released between approval and rejection (e.g., the ticket was canceled and restarted, or the host went offline), the rejection is refused with an error message asking you to use Start Over instead. This guarantees rejection feedback is never lost to a silently-recreated session.

Skip to Merge

A privileged action that bypasses the approval stages and goes straight to the Pull Request stage. Gated by the tickets.skip_to_merge permission.

Iteration tracking

Each QA rejection increments the ticket's rejection count, which is used as the iteration number for grouping rework history. The Rework History panel splits stage entries by iteration so you can see exactly what changed between attempts.

Ticket configuration

Per-ticket settings configurable at creation or while pending:

Setting	Description
Agent Provider	Polygent Code, Claude Code, Gemini CLI, OpenCode, Kilo CLI, Codex, Qwen Code
Agent Model	Specific model the provider should use
Workflow	Optional workflow to run during Implementation
High Priority	Bumps the ticket in the queue
Developer	Assigned developer (approver)
QA	Assigned QA reviewer
Development Mode	Auto (autonomous) or Manual (step-by-step)
Manual Implementation	Use an existing branch instead of creating a new worktree
Session Mode Toggles	Code Architecture, UX Enhancement, Edge Cases, Code Review, Verification, Update Tests, Update Docs

Attachments

Upload files to a ticket while it is Pending or Queued:

• Max size: 10 MB per file
• Allowed types: png, jpg, gif, svg, webp, pdf, txt, md, docx, zip
• Download or delete attachments any time before the ticket leaves Queued

Approval notes and rejection feedback can also carry their own attachments.

Comments

• Add a comment at any stage
• Edit your own comments
• Attach files to comments

Blockers and dependencies

While a ticket is Pending, you can mark another ticket as a blocker. The blocked ticket cannot enter the queue until the blocker reaches a terminal completed state.

PR status tracking

Once a ticket reaches the Pull Request stage, Polygent tracks the PR status:

Status	Meaning
Open	PR exists, not merged
Merged	PR merged → ticket completes
Closed	PR closed without merge
Conflicts	Merge conflicts detected
Failed to Create	PR creation failed

Use Refresh PR Status to force a re-check or Retry PR Creation if creation failed.

Activity feed

Every ticket has a chronological activity timeline with icons and color coding. Entries include:

• Ticket created; stage entered (with a From → To label)
• Stage outcome (Approved / Rejected / Failed / Canceled / Merged / Skipped)
• Attachment uploaded; priority changed; blocker set
• PR status changes (Open / Merged / Closed / Conflicts / Failed to Create)
• Ticket failed (with a failure reason); ticket canceled; ticket completed

The feed is a resizable sidebar panel attributed to the actor (user or system).

Bulk actions

Select multiple tickets to run any of:

• Start, Dequeue, Cancel, Complete, Delete
• Assign Developer, Assign QA, Toggle Priority

Other operations

• Merge as Duplicate — Mark a ticket as a duplicate of another and close it
• Rerun Failed Ticket — Re-enter the queue from a failed state
• Cancel Ticket — Move to Canceled at any active stage
• Override Stage — Admin-only recovery action to manually move a stuck ticket to another valid stage, bypassing the normal pipeline. Only specific transitions are allowed (e.g., QA Approval → Implementation). Any active session is canceled first, and the move is recorded as a Manual Override in the activity feed. Gated by the tickets.manage permission.
• Batch Deploy to Slot — Merge multiple ticket branches into a single deployment slot for QA
• ETA Estimation — Predicted completion time based on historical cycle times
• Total Cost Display — Aggregate USD cost of all sessions for the ticket
• Per-Ticket Lock — Concurrent stage transition prevention; only one transition per ticket can be in flight at a time
• Stage Outcome Tracking — Each completed stage records its outcome (Approved, Rejected, Failed, Canceled, Merged, Skipped, Manual Override) for the activity feed and rework history

Examples

Hands-off bug fix with full review Create a Bug ticket, assign a workflow that reproduces and fixes the issue, set Development Mode to Auto, assign a developer and QA, and Queue it. The agent implements; the developer approves; QA approves; Polygent opens a PR — all surfaced through targeted notifications at each gate.

Fast-track a trivial change A typo fix doesn't need two approval rounds. On the ticket, enable Force No QA (and optionally Force No Developer). After implementation it goes straight to PR creation or direct merge, depending on the workspace's Merge Mode.

Cap the cost of a risky refactor A large refactor could loop for a while. Set a Per-Task AI Budget when creating the ticket (see AI Cost Budgets); the ticket's sessions stop once that cap is reached, regardless of workspace headroom.

Jump the queue for an incident A production incident lands as a ticket. Toggle High Priority — it bumps ahead of normal-priority work and starts as soon as a host slot frees up.

Batch-test several tickets together Three tickets are ready for QA. Select them, Batch Deploy to Slot, and Polygent merges all three branches onto one deployment slot so QA can test the combined build before any of them merge.

Start Ticket Templates

Define Start Ticket Templates at the workspace level — preset configurations (provider, model, workflow, session toggles, etc.) that pre-fill the ticket creation form. Set one as the workspace default to streamline ticket creation.

Example: Create a "Bug — Auto" template that pre-selects your bug-fix workflow, Auto mode, and the CodeReview + Verification toggles. Set it as the default so every new bug ticket starts correctly configured with one click.

Scoping tools and MCP servers

A template (and the Custom option in the Start Ticket dialog) can restrict what the ticket's agent is allowed to use:

• Allowed Tools — limit the agent to a subset of the provider's tools (e.g. Read, Grep only). Shown only for providers that support tool selection. Leave empty for the provider's defaults.
• MCP Servers — inject only the chosen user-defined MCP servers. Leave empty to inject all enabled servers.
• Polygent MCP Tools — restrict which built-in Polygent tools (e.g. create_ticket, write_plan) the agent can call. Leave empty to allow all.

These selections flow through to the ticket's session — so a restricted template produces a restricted agent run, even for auto-queued tickets.

External sync

See the Ticket Sync guide for GitHub Issues and Azure DevOps/TFS Work Items integration, including auto-start rules, label/area-path filters, and status mapping.