Managing Tickets

Tickets are the unit of work in Mopheus. Every database health check, performance tuning task, backup recovery operation, or incident investigation is a ticket. Tickets are scoped to a workspace and can be grouped into projects.

Create a Ticket

From the UI, click New ticket in the top-right of the Tickets view. The only required field is a title. Add a description, set the priority, attach the ticket to a project, add labels, then click Create.

Use the Timing picker to stage a scheduled start and due time, then apply both together. Both values include a date, time, and timezone. When both are set, the due time must be later than the start time. You can also edit timing later from the ticket detail panel.

A scheduled start keeps the ticket in Backlog until the selected time, then moves it to Todo and dispatches the assigned Agent or Team leader. The start must be at least one minute in the future. If the selected Agent no longer has an online Runtime at activation time, Mopheus moves the ticket to Todo, records the failure in a system comment, and does not retry automatically. This prevents delayed execution outside the intended operational window.

When a non-terminal ticket reaches its due time, Mopheus sends one Inbox reminder to the member who created it. If an Agent created it, the reminder goes to that Agent's current owner when the owner is still a workspace member. Terminal tickets do not generate a reminder.

Status Lifecycle

Status is not a fixed linear sequence. Teams can move a ticket according to the work at hand; the diagram shows the recommended delivery loop and common return paths.

Agent Execution and Status

Switch status from the status picker in the ticket detail panel. Backlog, Cancelled, and Archived tickets are not automatically dispatched to agents. To trigger automatic work, first move the ticket to an executable state, normally Todo or In Progress.

While an AgentTask is running, use the transcript guidance box to add a pending instruction. Process now marks one pending instruction for best-effort delivery at the next provider-safe boundary; it does not interrupt an active tool call. Pending instructions can still be withdrawn before delivery. The stop control in the transcript header cancels the entire AgentTask and its running work.

Batch Updating Status

When multiple tickets are selected in the list view, a floating batch action bar appears at the bottom of the screen. Click Change Status to transition all selected tickets simultaneously to a target status (such as Done, In Progress, or Todo). If any ticket has unresolved enforced dependencies, the system validates and blocks the update to preserve dependency integrity.

Priorities

Leaving the priority unset is equivalent to Normal.

Additional Fields

Beyond title, status, and priority, tickets support:

Edit these fields from the ticket detail panel.

Subtasks

A ticket can have subtasks. Subtasks are full tickets — they have their own status, priority, assignee, and comments — but the parent ticket's detail view shows them inline. Closing all subtasks does not auto-close the parent; the parent owner decides when the umbrella work is done.

Create a subtask from the Subtasks panel on the parent ticket detail view.

When an AgentTask uses its task token to move a bound subtask into in_review or done, Mopheus records a pending wake for the parent ticket. The parent assignee is considered after that source AgentTask reaches a final state. If the same run already triggers the parent assignee through an effective parent-ticket comment, the pending wake is suppressed. Human status changes do not automatically wake the parent in this phase.

Dependencies

Dependencies model "this ticket cannot start until that ticket is done." Use them sparingly — they tend to surface real coordination cost. Blocked tickets are marked in the list, and the UI warns when you try to start a ticket that still has open blockers.

Add or remove dependencies from the Dependencies section in the ticket detail panel.

Labels

Labels are free-form workspace-scoped tags. Use them for cross-cutting concerns that do not deserve their own project (slow-query, capacity-risk, change-window).

Add, edit, or remove labels directly from the label area in the ticket detail panel or on list rows.

Comments and Timeline

Comment trigger preview

The composer can show a read-only snapshot of the Agents a comment may wake. Sending recalculates routing after the comment is persisted, so a pending snapshot may legitimately become queued, coalesced, deferred, or blocked when assignment, runtime, permissions, or queue state changes. Use the per-comment skip control only for that comment; it does not change Agent, ticket, or team configuration.

Every ticket has a threaded timeline that mixes user comments, status changes, agent run summaries, and subtask events. Comments support Markdown and are the primary place to record progress, discuss approaches, and hand off context.

Write and submit comments from the input box at the bottom of the ticket detail panel. Drag-and-drop file attachments are supported. Every root comment and reply provides a direct shareable link (via Copy link in the action menu or by clicking the comment timestamp anchor #comment-<id>); opening a comment link automatically un-collapses parent threads, expands resolved thread blocks, and scrolls smoothly to highlight the target comment.

Markdown and Previews

Ticket descriptions, comments, and chat messages share the same Markdown rendering. Ticket descriptions and comments can switch between Rich text and Markdown to work directly with the source; agent, team, and scheduled-job instructions provide the same source mode. Task list checkboxes can be completed in Rich text mode. Mermaid diagrams open in a zoomable, draggable viewer and can be downloaded as SVG. Use ==highlighted text== for an inline highlight. Bare ticket references such as #42 and the workspace prefix form (for example, TSK-42) are saved as clickable ticket links when the target exists; references inside code remain literal.

GFM task lists show their checked state but are read-only, matching the reference implementation's behaviour. Source files open with syntax highlighting, and PDF attachments open in a paginated in-app preview. Markdown attachments render as rich text (with code highlighting, Mermaid diagrams, and tables) and can switch to the raw source via the toggle next to the download button; HTML attachments render as a sandboxed page, and CSV attachments render as a table with the same source toggle. Text and source attachment previews support files up to 20 MB; larger files remain downloadable.

Interactive Decision Widgets

[!NOTE] Experimental Capability & Feature Flag: Interactive Ticket Widgets is currently an experimental capability governed by the two-tier feature flag widget.

• Default State: Enabled by default (enabled). Workspace administrators can opt out in Workspace Settings → Features (toggle to "Force Off"). Platform administrators can also control availability platform-wide.
• Graceful Degradation: When disabled, agents will not generate widget prompts or outputs. Any existing widget blocks in ticket discussions degrade gracefully into standard syntax-highlighted JSON code blocks, and the floating submission bar as well as profile theme preferences are automatically hidden.

Agents can embed interactive decision widgets directly within ticket descriptions and comments by using the widget code block fence (```widget ... ```) with a valid JSON schema. Members can make structured choices directly in the web UI without typing out unstructured replies.

Supported Widget Types

• Single Select (single_select): Choose exactly one option from a list of structured alternatives (e.g. choosing between architectural approaches or backup strategies).
• Multi Select (multi_select): Select one or more options, with optional min and max constraints (e.g. selecting target nodes for a rolling restart).
• Confirm Action (confirm_action): Confirm or reject a high-impact operation, with an optional or required text rationale (e.g. database schema migrations or production failovers).

Example Widget Schema

```widget
{
  "v": "1",
  "id": "w_failover_choice",
  "type": "single-select",
  "label": "Select Primary Failover Target",
  "props": {
    "options": [
      { "value": "node-db-02", "label": "Node DB-02 (Zone A)", "description": "Replication lag: 0ms, NVMe storage", "intent": "positive" },
      { "value": "node-db-03", "label": "Node DB-03 (Zone B)", "description": "Replication lag: 12ms, HDD storage" }
    ],
    "default": "node-db-02"
  }
}
```

User Interaction and Submission

• Selection and Batch Submission: When selecting options across one or more widgets, a floating submission bar docks at the bottom of the screen. Members can review pending choices and click Submit choices to record their decision.
• Audit Receipt Comment: Upon submission, Mopheus records the widget state and automatically posts a structured receipt comment in the timeline. The receipt contains a summary table of submitted choices and an expandable raw JSON payload (<details>).
• Immutable State: Once submitted or expired, the widget transitions to a locked state displaying the member who made the decision, the timestamp, and the confirmed choices.
• Visual Themes: Users can customize their widget appearance in Profile Settings under Widget Theme. Five distinct themes are supported:
  • Default: Clean modern border and card layout.
  • Compact: Dense operational layout with minimized spacing.
  • Vibrant: High-contrast borders and rich status badges.
  • Geek Mono: Monospace terminal styling with bracketed check indicators ([x]).
  • Warm Industrial: Warm neutral background with tactile mechanical bezels.
• Safe Fallback: If a widget contains an invalid schema or an unknown type, it degrades safely to an informative fallback box with the raw JSON preserved.

Long Comment Threads

For tickets with more than five top-level discussion threads, the detail panel shows a desktop minimap and a quick-jump rail. Select an entry to scroll to that thread; its full card turns light blue briefly, then fades back to its normal background. Use the expand-all and collapse-all controls above the timeline to change every discussion thread at once.

Use Ctrl+F (or Cmd+F) while the comment panel is focused to search comments in the panel. Matches are highlighted and the previous/next controls move through them.

Any comment, including a reply, can resolve its thread. The resolving comment carries a Resolved badge. Resolving a top-level comment collapses the thread into a summary. Resolving a reply keeps the root comment and that resolving reply visible, while the other replies are folded until you expand the thread. Clearing the resolved state restores the full thread.

Grilling & Critical Review (Grill Me)

Click the Grill Me action to trigger an agent to conduct a structured decision-tree review (up to 10 rounds of self-reflective Q&A using the grill-me skill) to identify risks, evaluate trade-offs, and suggest recommended solutions.

• Select a Griller Agent: When designated Griller agents (with the Griller toggle enabled, such as an Architecture Griller or DBA Griller) exist in the workspace, clicking the dropdown chevron next to the Grill button lets you select a specific specialist; clicking the primary button assigns the default or first available Griller agent.
• Ticket Grilling (Ticket Grill): Located in the header toolbar on the ticket detail page and in the ticket list context menu. Treats the ticket title and description as the source of truth to review overall requirements, architectural design, edge cases, and trade-offs. The review report is posted as a root comment on the ticket timeline.
• Comment Grilling (Comment Grill): Located on individual comment cards. Treats the specific comment thread as the source of truth to review local proposals or replies. The review report is posted as a reply within that comment thread.

Trigger Agents from Comments

Comments can wake agents without changing the ticket assignee. Top-level comments and replies are routed differently.

Top-level comments:

Replies to an existing comment:

When a comment or reply does trigger work, that message becomes the run's trigger context: the agent sees the ticket, the discussion so far, and the specific message that woke it up. Replies stay scoped to their comment thread. If no compatible runtime is online, the triggered task stays queued until one connects.

Before a task starts running, Mopheus coalesces compatible comment triggers for the same agent and ticket to avoid duplicate runs in a short burst:

• Top-level comments with no replies join one pending root pool, so a sequence of independent updates can be handled in one run.
• A member reply in a thread with an active task is still dispatched. When that task is running, the reply creates a queued successor; later replies merge into that successor while it remains pending.
• The first reply under any root in that pool binds and seals the pool to that thread. Later top-level comments start a new pending pool instead of joining an established conversation; later replies in the sealed thread continue to coalesce.
• The merged task keeps the highest priority it has received. A routine update cannot lower the priority of queued work.
• Once a task is running, its prompt snapshot is not rewritten. Later comments create a successor task, and tasks for the same agent and ticket are claimed serially.

Filter and Search

The ticket list supports filtering by status, priority, assignee, label, creation time, and more. Full-text search covers titles and descriptions. Filter selections are saved for each user and workspace across refreshes and ticket-list pages. Creation-time filters also remain in the URL so you can share a dated view with teammates.

Tickets default to creation time descending, so the newest work appears first. Open Sort by to order tickets by priority, start date, due date, creation time, updated time, or title. Select the active option again to reverse its direction; the selected field and direction persist across refreshes.

Command-line Reference

The following commands are available for users who prefer the CLI:

# Create a ticket
mopheus ticket create \
  --title "Fix flaky payment webhook test" \
  --description "Test fails ~10% of the time on CI" \
  --priority high

# Schedule a ticket. Repeat the command with different timestamps for a batch.
mopheus ticket create \
  --title "Upgrade database at midnight" \
  --status backlog \
  --agent-id <agent-id> \
  --activate-at "2026-12-31T16:00:00Z"

# Clear a scheduled start
mopheus ticket update <ticket-id> --activate-at ""

# Change status (use snake_case: in_progress, in_review)
mopheus ticket status <ticket-id> in_progress

# Batch update ticket status (comma-separated list of ticket IDs or UUIDs)
mopheus ticket batch-update --ids <id1,id2,id3> --status done

# Create a sub-ticket
mopheus ticket create --title "Subtask example" --parent-id <parent-ticket-id>

# Update a ticket
mopheus ticket update <ticket-id> --title "New title" --priority urgent

# Assign (member / agent / team / clear)
mopheus ticket assign <ticket-id> --user-id <user-id>
mopheus ticket assign <ticket-id> --agent-id <agent-id>
mopheus ticket assign <ticket-id> --team-id <team-id>
mopheus ticket assign <ticket-id> --unassign

# Manage dependencies
mopheus ticket dependency add <ticket-id> <depends-on-ticket-id>
mopheus ticket dependency list <ticket-id>
mopheus ticket dependency remove <dependency-id>

# Manage labels (a single label by name or UUID; repeat the command to add more)
mopheus ticket label add <ticket-id> bug
mopheus ticket label list <ticket-id>
mopheus ticket label remove <ticket-id> urgent

# Ticket metadata (structured key-value store)
mopheus ticket metadata list <ticket-id>
mopheus ticket metadata get <ticket-id> --key <key>
mopheus ticket metadata set <ticket-id> --key <key> --value <value>
mopheus ticket metadata delete <ticket-id> --key <key>

# Subscribers
mopheus ticket subscriber list <ticket-id>
mopheus ticket subscriber add <ticket-id> --user-id <user-id>
mopheus ticket subscriber remove <ticket-id> --user-id <user-id>

# Comments (--content passes text directly)
mopheus ticket comment add <ticket-id> --content "PR opened: github.com/acme/payments/pull/482"
mopheus ticket comment list <ticket-id>
mopheus ticket comment update <comment-id> --content "Updated content"
mopheus ticket comment delete <comment-id>

# Comment Grill Me review (trigger deep self-Q&A review on a comment, optionally specifying a Griller agent)
mopheus ticket comment grill <comment-id>
mopheus ticket comment grill <comment-id> --agent-id <griller-id>

# Ticket Grill Me review (trigger deep self-Q&A review on the entire ticket, optionally specifying a Griller agent)
mopheus ticket grill <ticket-id>
mopheus ticket grill <ticket-id> --agent-id <griller-id>

# Attach files when creating a ticket or adding a comment
mopheus ticket create --title "Logs" --attachment ./logs.tar.gz
mopheus ticket comment add <ticket-id> --content "See attached" --attachment ./screenshot.png

# Filter and view
mopheus ticket list --status in_progress --priority high
mopheus ticket list --search "payment retry" --status todo
mopheus ticket search "webhook"
mopheus ticket get <ticket-id>

# Cancel a ticket
mopheus ticket cancel <ticket-id>

# Re-run or cancel an agent task (takes an agent-task id, not a ticket id)
mopheus ticket rerun <agent-task-id>
mopheus ticket cancel-agent-task <agent-task-id>
mopheus ticket run-messages <agent-task-id>

mopheus ticket list --search <query> searches ticket titles and descriptions. Combine it with list filters such as --status, --priority, and --project to narrow the result.

Useful ticket create / ticket update flags:

The transcript composer is available for running AgentTasks. Authorization checks the task requester/owner, workspace owner, and then the RBAC rule. Messages are queued in order on the owning daemon; senders may withdraw their own messages before delivery, while an authorized owner or task manager may withdraw another sender's queued message. WebSocket events refresh queue and delivery status in real time. The WebSocket is only a wake-up signal: the daemon scheduler restores pending messages from the server after reconnects or retries, and task completion is deferred while undelivered interactions remain.