Confirm the bug and date its birth
Checks the report against real telemetry in Axiom, Sentry and Datadog, and pins the release that introduced it.
I want to do this: Can you confirm the bug in ticket #513 from the logs, and which release introduced it? ## Setup (skip if Polylane is already set up) Read and follow https://polylane.com/auth.md for non-interactive signup and setup. Start by checking whether I am already signed in; reuse my account and workspace. If the CLI is missing, bootstrap it without starting the interactive wizard: curl -fsSL 'https://polylane.com/setup?ref=prompts' | bash -s -- --install-only Then follow the guide through email verification, workspace selection, source connections, and MCP authentication. Ask me for an email code or OAuth consent only when needed. Verify each step; report pending setup instead of claiming success from installation alone. ## How to work Over MCP: searchTools lists what this workspace exposes, with each tool's schema; call it first. runTool runs one tool, runCode chains several in one call and returns just the answer. search and execute cover the full Polylane REST API: threads, issues, investigations, autofixes, memories. From the terminal: the polylane CLI wraps the same API, with structured output and non-interactive flags everywhere. Reads always work. Write tools appear only if I have opted in, and every write is screened. ## Task: Confirm the bug and date its birth Steps: 1. Search the logs and error telemetry for the reported symptom 2. Confirm it's real: frequency, affected users, first occurrence 3. Walk the release history back to the deploy where it starts 4. Read that release's diff for the plausible mechanism 5. Deliver the confirmation: evidence, start date, suspect release and commit Ground every claim in data you actually pulled: the query, the log line, the change record. If the data is inconclusive, say so. Ask me before anything that writes.
Half of triage is deciding whether to believe the ticket.
The report is secondhand, the screenshot is cropped, and the reporter's timezone is a mystery. Confirming it's real, and since when, takes longer than the conversation about priority.
- Sprints committed to bugs that were config on the user's side
- "Since when?" answered with a guess
- The regression window nobody narrowed
One prompt, this much work. Every step on your real data.
- 1 Search the logs and error telemetry for the reported symptom
- 2 Confirm it's real: frequency, affected users, first occurrence
- 3 Walk the release history back to the deploy where it starts
- 4 Read that release's diff for the plausible mechanism
- 5 Deliver the confirmation: evidence, start date, suspect release and commit
Triage on facts, not vibes
Real or not, since when, and which release did it, all with the queries attached. Priority arguments end because the data already had them.
