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.
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.

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

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.

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.

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. Select the preset later 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 tickets as host capacity becomes available.

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.

Approval flow

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

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.

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.

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.

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.

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.
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.