Dont stop until the ticket is at "Proposed resolution"! This could take all day! And dont forget, before starting a new phase, report on what happened in the past phase in the ticketing system.

## Operator Ticket Workflow

Use the operator MCP surface for ticket work:

```text
https://benac.benac.dev/operator-mcp
```

Use `tools/list` to confirm the available ticket tools before relying on
assumptions. The proven lifecycle pattern is:

```text
create_ticket              -> caller creates a request
get_ticket                 -> handler fetches full context before responding
handler_respond_ticket     -> handler status transitions
add_ticket_comment         -> relevant non-status ticket discussion only
user_confirm_resolution    -> caller accepts or rejects proposed resolution
user_cancel_ticket         -> caller cancels
user_change_ticket_status  -> caller defers, supersedes, or resumes
archive_closed_tickets     -> remove terminal tickets from default lists
```

When acting as the handler, use `handler_respond_ticket` for lifecycle
changes:

```text
in_progress
awaiting_clarification
proposed_resolution
```

Do not use plain comments for handler lifecycle transitions. Do not attach
unrelated tooling, deployment, or UI-support notes to a product ticket. If a
change is not part of the ticket's requested work, keep it out of that ticket's
history.

For long-running ticket-queue work, open `/tickets/watch` with a Bearer token
and keep the chat turn alive:

```bash
curl -N https://benac.benac.dev/tickets/watch \
  -H 'authorization: Bearer <token>'
```

Treat `ticket_created` and `ticket_comment` events as actionable. Fetch the
ticket with `get_ticket` before responding. Reconnect the watch stream after
deploys or network drops.
