Record Confirmed Bug

Record a confirmed bug you have identified during testing.

Call this only after you have observed something that meets the bug bar: reproducible, user-affecting, persistent. Do not record speculation or polish nits. The session report is built from these records — be specific.

Args: title: One-line headline, specific. Bad: "Form has issues." Good: "Login form accepts any password — no authentication." severity: "critical" | "high" | "medium" | "low" | "info". HIGH = data loss / security / payment / blocked flow. MEDIUM = workflow friction / confusing UX / cross-page bug. LOW = polish / suggestion-grade. verify: Optional reproduction clause. When the bug has a machine-checkable symptom (something present/absent on a fresh page load), pass it and Argus will INDEPENDENTLY re-load the page and confirm the symptom before recording — turning the bug into a verified, reproducible finding instead of your unverified say-so. This is Argus's anti-false-positive guard; use it whenever the symptom is text-checkable. Shape: {"expect": "present"|"absent", "target_text": "the text that proves the bug", "at_url": "/path"} # optional, defaults to current page Examples: - Fake delete (item survives): {"expect":"present", "target_text":"Buy groceries","at_url":"/tasks"} - Save didn't persist (new value missing): {"expect":"absent", "target_text":"EDITED-XYZ","at_url":"/tasks/1/edit"} IMPORTANT — the target must PROVE the symptom, not a nearby fact. target_text has to be the exact string whose presence/absence ALONE is the bug. For a COUNT or LOGIC inconsistency ("7 pending + 2 done != 8 total") no single text check establishes it — verifying that "8 total" merely EXISTS does not confirm the inconsistency and would stamp a misleading VERIFIED on tangential evidence. Record those as observation-based (omit verify), or verify the specific wrong value that should not be there. For a broken URL or API response whose HTTP status is the proof, use {"expect_status": 404, "at_url": "/missing"} instead of matching error-page copy. Status verification and text verification are alternatives and cannot be combined in one clause. For a MULTI-STEP bug (the symptom only appears after a journey), add "replay": true — Argus re-drives the recorded action trace (click_what/type_into/select_into/navigate) in a fresh cold context and checks the symptom there, giving a stronger "reproduced by replaying N steps from a cold start" receipt (or INCONCLUSIVE if a step no longer resolves). Shape: {"replay": true, "expect": "present"|"absent", "target_text": "the text that proves the bug"} CAUTION: replay re-EXECUTES the journey's steps against the live backend, so any Save/Delete/Add/checkout in the trace runs a second time (real side effect; the receipt reports writes_replayed). Use the plain clean-load verify (no replay) for destructive flows, or accept the re-run. Add "minimize": true to also narrow a confirmed reproduction to the minimal sufficient steps ("you don't need all 7 — 2 and 5 suffice"). Minimization runs ONLY for a write-free journey (it re-runs subsets, which would repeat any writes); it is skipped with a note otherwise. Omit verify entirely for visual/layout/UX-judgment bugs that no single text check captures — those record as observation-based. evidence: Optional dict with extra context. Recommended keys: description (str): Longer explanation including user impact. Default = same as title. steps (list[str]): Reproduction steps. Default = current session step log (everything you did so far). url (str): Page or screen URL. Default = current page URL. screenshot (str): One of "auto" (default — take one now and attach), "skip" (no screenshot), or a label to use as the screenshot filename. Pre-existing screenshot paths are also accepted. bug_type (str): A category for the report. Default "ux_issue". One of: console_error, network_error, visual_anomaly, ux_issue, crash, broken_link, form_error, state_verification, misleading_success, count_mismatch, text_anomaly, broken_image, seo_issue, accessibility, performance, mixed_content. Pick the SPECIFIC type, not the generic ux_issue: a "Saved!" / success toast that lied -> misleading_success; a delete or edit that did not persist -> state_verification; a wrong/inconsistent count or total -> count_mismatch; a JS exception or dead page -> crash; a form losing data / rejecting valid input -> form_error. Reserve ux_issue for genuine usability friction with no better fit — a data-loss or persistence bug labeled "ux_issue" reads as cosmetic next to its HIGH severity.