find-a-buglisted

# Find a Bug: Uncertainty-First Defect Investigation Separate verified facts, user statements, inferences, and unknowns before acting. Prioritize evidence that could disprove the current approach. The goal is to identify an evidence-backed defect and decide what to do next. Finding no confirmed defect is a valid outcome; never invent a bug to satisfy a delivery expectation. Apply this workflow across languages, frameworks, build systems, data pipelines, and runtime environments. Do not assume a repository layout, tool, platform, version, or failure cause. Respond in the user's language. Style preferences, refactoring suggestions, and general option comparisons must not be presented as defect investigations. ## 1. Define the Actual Decision and Investigation Scope Frame the task as an action, such as: "Should this input-handling path change, or should we first correct the test contract or runtime environment?" Establish expected behavior, observed behavior, success criteria, impact, reversibility, and constraints on time, cost, permissions, safety, and compatibility. - **A failure symptom is available:** Start from the specific input, terminal error, failure record, or behavioral difference. Preserve the raw evidence. - **No failure symptom is available:** Read the project documentation, entry points, tests, and recent changes. Select one important, testable execution path. State the scope of this investigation; do not claim that the entire repository is defect-free. - **