Tickets

A ticket is a tracked unit of work that moves from backlog through implementation, human approval, pull request, and completion.

Pipeline stages

The stage identifies the current operator action or automated work.

Stage	Meaning
Pending	Editable and not yet queued.
Queued	Waiting for eligible host capacity.
Plan	A Plan is being generated or reviewed before work starts.
Implementation	A linked session is working on the ticket.
Developer Approval	Waiting for developer review.
QA Approval	Waiting for QA review.
Pull Request	Required pull requests are being created or tracked.
Completed	Delivery requirements are complete.
Failed	Work ended with an unrecovered failure.
Canceled	Work was stopped.
Merge Conflicts	Merge conflicts require resolution.

Ticket Detail combines Implementation and Developer Approval into one Implementation progress step. Its phase text and available actions distinguish active implementation from developer review. Activity history, approval notes, attachments, and lifecycle events remain separate records, so the audit trail still identifies each phase.

Updates appear automatically. Terminal tickets do not restart unless an explicit supported recovery action is used.

Queue pause controls

Queue pause controls stop automatic starts without changing waiting tickets.

• Pause Ticket Queue in Workspace Tickets settings pauses only that workspace. Resume restarts admission under the existing priority and capacity rules.
• Pause All Ticket Queues in Global Settings or the Tickets page header pauses every workspace. A workspace Resume cannot bypass it.
• Global Resume leaves individually paused workspaces paused.
• Queued tickets and approved plans retain their stage, priority, and queue order. Newly queued tickets wait behind the same controls.
• Running sessions and ordinary conversations continue.

The Tickets page identifies whether a global or workspace pause is preventing automatic starts. Terminal tickets do not restart unless an explicit supported recovery action is used. Scheduled ticket automations always create a separate pending ticket, retain the originating schedule and occurrence, and never reopen or reset an earlier ticket.

Lifecycle modes

The workspace ticket lifecycle determines approval and pull-request order for every ticket in that workspace.

• QA First: implementation, developer approval, QA approval, then pull request.
• Merge First: creates the pull request earlier so QA can review it.

Configure lifecycle in Workspace Tickets settings. Individual ticket starts and Start Ticket Templates cannot override it. Changing the setting applies the selected lifecycle to subsequent pipeline transitions and lifecycle-dependent status reporting for all workspace tickets.

Workspace settings can skip QA. Per-ticket Force No Developer and Force No QA overrides skip those gates. Use overrides only when an equivalent review control exists. Skip to Merge is a privileged recovery or expedited-delivery action and bypasses normal approvals.

Plan stage

The optional Plan stage produces an implementation plan before the ticket agent starts coding.

1. Set Plan Stage by Default in Workspace Tickets settings. Enable Skip Plan Approval there to advance a successfully generated Plan straight to Implementation.
2. Configure Plan capabilities in Settings → Plan, then add workspace-specific Plan guidelines under Workspace Guidelines.
3. Start the ticket. Under Plan Stage, choose Workspace Default, Enabled, or Disabled. When Plan is enabled, choose a Plan Model or leave Application Default selected. The Plan model is separate from Implementation Model and remains in use for generation, review revisions, retries, and AI-assisted edits.
4. To reuse the configuration, save the Plan-stage setting and Plan model in a Start Ticket Template. Custom, bulk, preset-driven, synchronized, and MCP-driven starts preserve the applied Plan model. Planning waits for the same capacity used by Chat Sessions and runs in the background.
5. Open Ticket Details and review the Plan section. Editing, AI-assisted changes, version comparison, undo, and redo are available only while the Plan is awaiting approval. They remain locked during generation, rejection revisions, retries, failures, and after approval.
6. Select Approve Plan to lock it and advance to Implementation, or Request Changes to send feedback to the same Plan session.

The Plan section shows generating, awaiting approval, revising, failed, retrying, and approved states. A failed Plan blocks Implementation until Retry succeeds.

In the sidebar pipeline tracker, the Plan stage appears as two segments so you can tell work from waiting at a glance. The Plan (working) segment shimmers like Implementation and counts tickets whose Plan agent is currently generating, revising, or retrying. The plain Plan segment is static and counts Plan tickets that need someone to act — awaiting approval, rejected, failed, or not yet started. Selecting either segment filters the Tickets list to the Plan stage. When Skip Plan Approval is enabled, a successfully generated Plan advances automatically. The approved Plan becomes the Implementation request; ticket attachments and dependency context remain attached.

Ticket sources and types

Source records where work originated; type classifies the request.

Tickets can be manual, externally synchronized, created from a plan, or created from an insight. Types are Bug, Feature, Task, and Other.

Search and filters

The Tickets header shows why the current list is filtered and provides the same criteria on desktop and mobile.

• Search is always available. On narrow screens, select Filters for stage, source, type, assignee, and tags.
• Active search, stage, source, type, assignee, tag, completion, and reopen criteria appear as labeled chips. Remove one chip to keep the other criteria and current sort.
• Changing or removing a criterion returns the list to its first page. Clear all filters also clears the selected saved preset.
• The built-in quick filters remain available above the complete criteria controls.

Saved query presets

Saved query presets let you reuse a Tickets view across browser sessions and devices.

1. Select the workspace whose query you want to save.
2. Set the search, stage, source, type, assignee, tag, completion, reopen, and sort criteria. Multiple tags match tickets carrying any selected tag, including exact tag values that contain commas.
3. Select Save preset, enter a name, and confirm.
4. Review a preset's readable criteria and sort summary in the selector, then select it to apply all saved criteria and refresh the list.
5. Change criteria while the preset remains selected, then select Update preset to replace its saved criteria.

Presets are private to your user account and workspace. Pagination is not saved.

Queue operation

The queue starts eligible planning and implementation work as host capacity becomes available. Ticket planning uses the Chat Session capacity pool and keeps the same host and working copy for Implementation.

High-priority ticket work is considered before normal-priority work throughout the ticket lifecycle, including session creation, developer and QA rejection resumes, hook recovery, generated reports, and follow-up messages. Low-priority ticket work runs only during the configured Low Priority Execution Hour and after High and Normal work. Running agent turns are never interrupted when priority changes. Admission still depends on host capacity, workspace access, branches, blockers, and valid ticket configuration. After service recovery, review in-flight and queued tickets for visible failures before changing stages manually.

Do not use high priority as a substitute for capacity planning. Cancel or reprioritize obsolete work to release queue pressure.

Ticket configuration

Configuration controls how implementation starts and who approves it.

Setting	Purpose
Model	Model used by the implementation session.
Workflow	Optional implementation workflow.
Repository Branches	Starting branch per repository; unchanged fields use repository defaults.
Priority	High, Normal, or Low queue priority; Low uses the configured execution hour.
Developer and QA	Assigned reviewers.
Development Mode	Manual or Auto agent progression.
Manual Implementation	Use operator-managed implementation where supported.
Session Options	Review, verification, tests, docs, and edge-case behavior.
Approval Overrides	Skip selected approval gates for this ticket.

Most implementation settings must be correct while the ticket is Pending. Validate repository branches, workflow parameters, assignments, and capability restrictions before queueing.

Ticket descriptions provide Translate and Explain below the source. The same actions work on the current unsaved description in Create Ticket, including when opened from a session. A read-only popup opens immediately and adds complete lines while the model responds; the completed result then replaces the preview. If live updates are unavailable, the final result still appears normally. Closing the popup cancels the request. The description and other form values never change, and a changed draft is marked as belonging to the earlier source snapshot. Set an optional language override under Profile → General or use the application default.

Approval flow

Approvals are explicit human checkpoints over the linked session and its changes.

Developer Approval

In Ticket Detail, this review appears within the combined Implementation step as Awaiting developer approval. The developer reviews the diff, commits, checks, and requirements. Approve with notes or attachments, or send actionable feedback in the linked session. Rejection feedback is queued ahead of QA rejection resumes and fresh ticket starts on the same host. If either session or ticket capacity is unavailable, the ticket remains in Developer Approval and the message stays pending until capacity becomes available.

The linked session's chat roll uses the same Approve action as standalone sessions, but ticket-linked approval still opens the ticket dialog and follows the configured QA and pull-request sequence. While approval work is applying, both the chat roll and session row show Processing approval and disable another submission.

A linked-session indicator separates run health from session availability:

Indication	Meaning	Operator action
Healthy	The latest run completed and the session is available.	Review and continue normally.
Active	A run or retry is processing.	Wait for completion before assessing the result.
Error	The latest agent run or startup hook failed, but the session remains available.	Open the session, inspect the failure, retry, or continue approval intentionally.
Warning	The session host disconnected before completion.	Confirm host availability, then retry from the session.
Terminal error	The session cannot continue without recovery.	Open the session and use its available recovery action.

An Error or Warning indication does not disable Developer Approval while the linked session remains available. Approval is an intentional decision to accept the current work despite the interrupted run. Queueing newer linked-session feedback removes an older recoverable Error indication immediately, but the ticket retains its recorded implementation issue and failure reason until the normal ticket lifecycle clears them.

QA Approval

QA validates acceptance criteria and relevant regressions. Approve or reject with specific feedback and attachments. Rejection returns the preserved session to Implementation and records another iteration.

If the original working copy is unavailable, rejection is blocked rather than silently recreating context. Use the supported Start Over recovery after preserving required evidence.

Iterations and activity

Iteration and activity history provide the audit trail for rework and stage changes.

QA rejection increments the displayed rework iteration. Review stage transitions, comments, approvals, failures, and linked session activity before deciding whether to retry, start over, cancel, or override a stage.

Cost breakdown

Ticket Details reports AI spend split by where it was incurred, so you can see which part of the pipeline consumed the budget.

Row	Covers
Plan Cost	The Plan stage, when the ticket ran one.
Implementation Cost	The ticket's sessions — the agent work that produced the change.
Merge Cost	AI merge-conflict resolution, when conflicts were resolved automatically.
Total Cost	The sum of the rows above; this is what counts against the per-task budget.

Only rows with recorded spend are shown, and Total Cost is omitted when a single row already carries the whole amount. If a per-task budget is configured, the budget card above the breakdown tracks Total Cost against that limit. For limits and warnings, see AI Cost Budgets.

Attachments and comments

Attachments and comments carry operator context and review evidence.

Pending or queued tickets accept supported attachments up to 10 MB: PNG, JPG, GIF, SVG, WebP, PDF, TXT, Markdown, DOCX, and ZIP. Treat all imported and uploaded content as untrusted. Remove secrets and inspect archives before agent use.

Comments can add or amend discussion context and include attachments. Editing a comment changes the visible record; use a new comment when audit clarity matters.

Blockers and groups

Blockers prevent dependent work from starting; groups collect related tickets.

Use blockers for real delivery dependencies and remove them when no longer applicable. Review dependency effects before canceling a ticket. For grouped work, Ticket Details shows the group title and links to the other tickets you can access, including tickets in other workspaces. Inaccessible tickets are hidden, and group membership does not grant workspace access or merge lifecycle state.

Pull-request status

Pull-request status tracks delivery separately for each changed repository and as an overall ticket result. Polygent may publish unchanged session branches so remote providers can resolve them, but it does not create pull requests for those repositories.

Possible user-facing states include Open, Waiting for Merge, Merged, Closed, Conflicts, and Failed to Create. For multi-repository work, open ticket details to inspect every repository. Completion waits until all required pull requests are merged.

On failure, verify credentials, source and target branches, repository policy, and existing pull requests before retrying. Use merge-conflict recovery rather than forcing a stage when conflicts are reported.

Git push rejections

A Failed ticket shows a safe provider rejection when the repository provider returns an actionable reason during a ticket-related push. The same text appears as a system message in the linked implementation session.

The message identifies the provider and can include the rejected branch or file plus remediation for missing permission, token scope, protected-branch rules, policy restrictions, or repository access. Credentials, authenticated URLs, authorization values, command arguments, local paths, and unrelated command output are removed. When the provider response cannot be displayed safely, the ticket uses the generic push failure message instead.

Resolve the named provider restriction, then use Retry Approval when that action is available. Polygent does not change repository permissions, credentials, or branch policies automatically.

Start Ticket Templates

Templates store approved defaults for repeated ticket starts and automatic start rules.

Templates can include a branch for every workspace repository, model, workflow, reviewers, priority, session options, and allowed tools, skills, MCP servers, and platform tools. Repository defaults are valid selections and are preserved when a template starts a ticket from the ticket dialog, bulk action, completed plan, external sync, or MCP integration. An explicit empty capability selection grants none. Review templates after repository, workflow, model, or access-policy changes.

Bulk and recovery actions

Bulk actions apply one operation to multiple selected tickets.

Confirm the count and stage eligibility before queueing, canceling, deleting, or changing priority. Destructive actions require confirmation. Start Over closes associated active pull requests and safely skips pull requests already completed or abandoned, cancels active conflict resolution, clears ticket history, and deletes Polygent-created branches from their matching repositories. Branches selected through Manual Implementation with Use Existing Branch are preserved. Manual stage override is an administrative recovery tool with constrained transitions; record the incident reason and verify linked sessions and pull requests first.

External sync

Externally sourced tickets use the same pipeline but retain links and configured status exchange with GitHub or Azure DevOps/TFS.

Imported text is untrusted and can block automatic start pending review. See Ticket Sync.

Troubleshooting

These checks cover common ticket incidents.

Symptom	Check
Ticket remains Queued	Check blockers, host capacity, workspace and branch access, and ticket configuration errors.
Implementation did not start	Verify model, workflow parameters, repository branches, template capability selections, and host availability.
Approval action is unavailable	Confirm current stage, assignment, permission, and whether another transition is processing.
QA rejection is refused	The original working copy may be unavailable; preserve feedback and use Start Over.
Git push was rejected	Open ticket details for the provider reason, resolve the named permission, token scope, branch rule, policy, or access restriction, then retry approval.
Pull request was not created	Check changed repositories, credentials, branch policy, existing requests, and the visible creation failure.
Ticket does not complete after merge	Open per-repository status and confirm every required pull request is merged.
Synced status is stale	Check integration credentials, mapping, and the latest sync failure. See Ticket Sync troubleshooting.