# SnagBadger

SnagBadger connects bug reporting with test planning, agent-driven UI testing, and regression testing.

## Language

**Bug report**:
A description of a problem, its reproduction steps, expected and actual behavior, and any supporting evidence. A bug report can exist locally without a ticket in an external tracker.

A bug report may be incomplete; missing information does not invalidate the observations it contains.

**Report revision**:
An identifiable version of a bug report that retains the report's stable identity. Local exports and external tickets can refer to particular revisions of the same report.

**Reproduction steps**:
Instructions describing how to encounter a reported problem, distinct from the recorded interactions of a particular attempt. They may be incomplete when the path to the problem is not yet understood.

**Reproduction script**:
Executable browser-automation instructions intended to reproduce a reported problem. It is distinct from a regression test, which checks an established expectation.

**Reproduction readiness**:
The state of a report's executable reproduction: incomplete, runnable but unverified, or verified to reproduce the reported problem. Readiness does not determine whether the bug report itself is valid.

**Recorded interactions**:
An account of actions actually taken during an attempt, which may include detours, retries, and an unfinished sequence. These observations are distinct from intended test steps and authored reproduction instructions.

**Evidence**:
Observations and supporting material associated with a bug report or test result, including structured diagnostics, recorded interactions, and attachments. Evidence may be incomplete, sanitized, or explicitly omitted.

**Attachment**:
A file included as supporting evidence, such as a screenshot, video, or other diagnostic artifact.

**Sanitization**:
Removal or redaction of sensitive content from evidence itself before export or submission. The resulting report can identify alterations or omissions without retaining the removed values.

**Harvester**:
A developer-enabled collector of evidence from the host website or its libraries, including diagnostic information, screenshots, recorded interactions, and recordings. Developer configuration determines which collection choices reporters can select.

**Plugin**:
A self-contained extension that registers evidence collection, report delivery, or reporting-interface contributions. A plugin may serve several responsibilities; built-in and developer-authored plugins use the same extension contract.

**Configuration profile**:
A reusable set of developer-selected reporting settings. Provided dev and public profiles are customizable starting points, not distinct permission modes.

**Capture**:
The collection of visual or interaction evidence while reproducing a problem, including screenshots, recorded steps, or video.

**Provider**:
A configurable destination integration that saves or submits a bug report, such as local export or an issue tracker.

**Test plan**:
A description of behaviors and scenarios to verify, used to guide manual or agent-driven testing.

**Test definition**:
A reusable description of a scenario's prerequisites, actions, and expected outcomes, distinct from observations made during its execution.

**Test definition revision**:
An identifiable version of the resolved instructions, expectations, execution settings, and lifecycle hooks that govern a test. Descriptive and selection metadata do not distinguish execution revisions.

**Test section**:
A hierarchical grouping of tests and nested sections that can share instructions, metadata, and execution settings.

**Regression test**:
An executable check derived from a known bug to detect its recurrence.

**Test run**:
An execution of selected tests, with the outcomes and evidence observed during that execution.

**Test result**:
The outcome and observations of an individual test within a test run, including an unfinished attempt. Problems discovered during that attempt can be reported independently of its outcome.

**Attempt**:
A single execution of a test or effort to reproduce a reported problem, with its own actions, outcome, comments, and evidence. Retrying creates another attempt without replacing earlier attempts.

**Flaky test result**:
A test result whose latest attempt passed after an earlier failed or incomplete attempt. Recovery retains the earlier observations and their need for attention.

**Result comment**:
An agent's contribution to a test result, classified by separate type and importance fields regardless of the test's outcome. A comment can supply context for a linked bug report without itself being a bug report.

**Comment type**:
The category of a result comment, with problem, optimization, suggestion, and context as defaults. Projects can define additional types and may allow agents to introduce their own.

**Comment importance**:
The degree of attention a result comment warrants, independent of its category. Its project-configurable scale defaults to low, medium, high, and critical.

**Observation**:
An action or outcome recorded during capture or testing, kept distinct from explanations inferred from it.

**Hypothesis**:
An explicitly unverified explanation of a reported problem or proposal for how to reproduce it.

**Test-run report**:
A record of a test run, organized by test sections and individual results, with summaries and supporting evidence. A failed result can supply information for a bug report, but the test-run report also includes other outcomes.

**Theme**:
The branding and visual choices applied to supplied reporting experiences, including colors, typography, spacing, and styling layer.

**Appearance preference**:
The choice to use light appearance, dark appearance, or follow the device's current appearance. The resolved appearance is the light or dark result of that choice.