Document captcha task and challenge telemetry

[archandatta]

Summary

• list captcha_solve_started, captcha_solve_result, and captcha_challenge_result in the telemetry category guide
• document task correlation, challenge grouping, best-effort delivery, authoritative durations, and every challenge outcome
• expand the data-sensitivity guidance for task and challenge identifiers and page locations

Why

A visible captcha challenge can produce multiple solver tasks. The guide currently exposes only captcha_solve_result, which can lead consumers to pair events by arrival order or treat a successful task as proof that the visible challenge cleared. #3418 adds task-start and challenge-result models so consumers can correlate tasks with task_id, group them with challenge_id, and wait for the challenge-level event when they need the overall outcome.

Existing capture and bot-detection behavior are unchanged. docs.json continues to use the deployed OpenAPI spec, so the API reference will pick up the new models after #3418 ships.

Testing

• npx --yes mintlify@latest dev --port 3000 — preview ready; /browsers/telemetry/categories rendered with the new section and all three event types
• npx --yes prettier@3.6.2 browsers/telemetry/categories.mdx >/dev/null — MDX parsed successfully
• git diff --check origin/main...HEAD — clean

---

Note

Low Risk
Documentation-only changes to the telemetry category guide; no runtime or API behavior is modified in this PR.

Overview
Updates the Telemetry Categories guide so the captcha category reflects task- and challenge-level events, not only terminal solve results.

The operational table now lists captcha_solve_started, captcha_solve_result, and captcha_challenge_result, with a new section on correlating work via task_id and challenge_id, best-effort/unordered delivery, using duration_ms on result events, and meanings for challenge statuses (solved, failure, timeout, abandoned). The data-sensitivity row for captcha is expanded to cover task/challenge outcomes and opaque identifiers alongside page host/path.

^{Reviewed by Cursor Bugbot for commit 6827b7e. Bugbot is set up for automated code reviews on this repo. Configure here.}

[mintlify]

Preview deployment for your docs. Learn more about Mintlify Previews.

Project	Status	Preview	Updated (UTC)
Kernel	🟢 Ready	View Preview	Aug 27, 2026, 5:58 PM

💡 Tip: Enable Workflows to automatically generate PRs for you.

[masnwilliams]

One correctness issue: the challenge-result guidance currently implies guaranteed availability. Please document that consumers need a bounded wait and fallback. Structurally, the diff is clean.

[cursor]

Risk assessment: Very Low

Re-evaluated after the latest push. Assessed from the actual diff, not from PR description or commit-message claims.

What changed

• One file: browsers/telemetry/categories.mdx (+25 / −2 vs main)
• Updates the captcha row in the session-telemetry table to list captcha_solve_started, captcha_solve_result, and captcha_challenge_result
• Adds a documentation section on correlating task vs challenge events (task_id / challenge_id, delivery caveats, outcome table)
• Expands the data-sensitivity row for the same category
• Incremental commit since the prior approval: wording only — challenge results are not guaranteed for every captcha type, delivery is best-effort, and consumers must use a bounded wait with a fallback

Why this remains Very Low

• Documentation-only MDX on a Mintlify docs site; no application code, APIs, config, or infrastructure
• docs.json and other site config are unchanged, so navigation and rendering are unaffected
• No production logic, auth, permissions, or shared-system changes
• Small, isolated surface; easy to reason about
• Product docs for telemetry consumers, not an LLM prompt or model-instruction file
• No CODEOWNERS file in this repo, so codeowner review is not required

Re-approval
This automation already approved an earlier commit as Very Low. The new commit does not increase risk, so that approval is left in place and is not repeated.

  

_{Sent by Cursor Automation: Assign PR reviewers}

[masnwilliams]

The latest update addresses the bounded-wait concern by documenting supported challenge types, best-effort delivery, and a fallback. No remaining findings.