verify-ticketlisted

# Verify a Ticket ## Overview End-to-end workflow this repo repeats for every tracker ticket: understand the ticket, verify it live in the app on the right environment, capture annotated evidence, back it with an automated pytest test, and post a verdict on the tracker with the evidence attached. The deliverable is always **a reproducible verdict backed by proof** — screenshots + a passing test + a comment, not just an opinion. Read `CLAUDE.md` in the repo root first — it defines the architecture, the authentication flow, and the gotchas this skill builds on. ## The Workflow Track these as todos; do them in order. ### 1. Understand the ticket — read AND watch everything - Fetch the ticket (tracker MCP/API, or the browser). - **Pull and watch/open every attachment — video and screenshots — before forming a verdict.** Text repro alone misses key facts; attachments show the exact error, the exact screen, and the real precondition. - Extract: the bug, the *expected* behavior, the acceptance criteria, the environment it was reported on, and the **fix scope** (which exact case the dev fixed — not a broader claim you can't back). ### 2. Pick the environment — ask if unclear Apps often have multiple environments (dev/QA/staging) with different URLs and sometimes different login flows. If the ticket doesn't pin one, **ask the user which environment** before you start. Set `UI_BASE_URL` (and credentials) accordingly in `.env`. ### 3. Verify live in the app Reproduce