# Classic Browser Capability Map

Use this reference to translate the classic CARBON browser extensions into
coding-agent browser actions. The goal is capability continuity, not a literal
port of extension UI, subscription, unlock-code, or provider-specific code.

All browser execution uses the machine-readable `carbon-browser/v1` contract in
[`browser/carbon-browser-v1.md`](browser/carbon-browser-v1.md). CARBON owns the
operation names, semantic element references, negotiation rules, safety
classification, and evidence envelope. Host-agent browser control,
Vibium/WebDriver BiDi, Playwright/CDP, Selenium/WebDriver, and testers.ai
managed devices are adapters beneath that boundary. Never silently downgrade a
requested operation or evidence channel when an adapter cannot supply it.

## 1. Page and element inspection

Collect the current URL, title, viewport, visible text, interactive controls,
roles, labels, ARIA state, stable selector hints, and safe screenshot evidence
for every page or materially different page state actually tested.
Support:

- element inspection with role, label, text, attributes, and selector quality;
- full-screen inspection and visual annotation through screenshots;
- global, domain, and exact-URL context supplied by the user;
- session notes and coverage notes that survive a multi-step investigation.

Never capture passwords, tokens, cookies, or unrelated private page content in
the report.

## 2. Adaptive exploration

Select and record a coverage shape before acting:

- **breadth:** sample routes, widgets, roles, states, transitions, responsive
  views, and linked APIs to map the reachable experience;
- **depth:** follow one high-risk journey through negative/boundary data,
  interruption, retry, recovery, permissions, persistence, and adjacent state;
- **balanced:** breadth first, then depth on the strongest observed risk.

Critical exploration follows:

1. Observe the current state.
2. Model likely behavior and risk.
3. Select the highest-value next target.
4. Experiment.
5. Evaluate user and business impact.
6. Adapt the model and charter.

Use feature, journey, error, data, consistency, interruption, recovery,
permission, and cross-feature tours.

Creative exploration adds wrong-order actions, repeated actions, mixed locales,
special and invisible characters, multiple tabs, extreme zoom, empty and large
data, rapid input, offline transitions when controllable, and unexpected
feature combinations. Avoid uncontrolled load, denial-of-service behavior, or
consequential production effects.

## 3. Generation, recording, and playback

Generate test cases from observed DOM, visible behavior, requirements, and
screenshots. Include:

- positive paths;
- invalid and malformed input;
- zero, one, many, and maximum boundaries;
- state transitions, interruption, retry, undo, and recovery;
- roles and permissions;
- accessibility and keyboard behavior;
- privacy and security misuse cases;
- nearby regression risks.

Represent a recorded action with its intent, natural-language step, URL/state,
role or label, stable selector hints, input category rather than sensitive
value, and optional evidence reference. Record explicit assertions as separate
steps.

During playback:

- prefer roles, labels, visible text, test IDs, and resilient selector hints;
- re-inspect after navigation or re-render;
- wait on observable state, not arbitrary time, when possible;
- capture each step result;
- use visual review as supporting evidence, not a reason to automatically pass;
- preserve failed action evidence before retrying.

Export Playwright, Cypress, Selenium, or other automation only when the project
uses it or the user requests it. Exported tests remain candidates until they run
successfully and their oracles are reviewed.

## 4. Accessibility

Cover both deterministic structure and human-visible behavior:

- language, title, headings, hierarchy, landmarks, and skip navigation;
- names, roles, values, ARIA references, and hidden/focusable conflicts;
- labels, required state, autocomplete, errors, and instructions;
- keyboard reachability, order, visible focus, modals, and traps;
- images, SVGs, media alternatives, links, tables, and live regions;
- measured contrast where the browser exposes computed styles;
- touch target size, zoom, reflow, orientation, reduced motion, and timing;
- visual hierarchy, clipping, overlap, reading order, and color-only meaning.

For multi-page requests, crawl only same-origin links within the agreed page
limit. Give each page a result and summarize repeated defects once. Label
screen-reader, cognition, and subjective visual checks as manual review unless
they were actually exercised.

## 5. Bugfinder and persona feedback

Bugfinder coverage includes functionality, JavaScript and API failures,
security indicators, privacy and consent, accessibility, performance,
usability, content, SEO, and error handling. A finding needs observed evidence;
a predicted risk is a hypothesis or candidate test.

Generated end-user personas may evaluate:

- visual design;
- usability and navigation;
- content clarity;
- feature fit;
- competitiveness;
- emotional appeal;
- perceived value;
- accessibility and inclusive use.

Ratings must include the behavior or evidence behind them. Keep generated users
separate from the stable named CARBON specialists. Attach each perspective's
role, goal, ratings, positives, friction, recommendation, and confidence to the
exact page screenshot and linked test IDs. Treat qualitative feedback as a
product signal, not an automatic test verdict.

## 6. AI-builder feedback loop

For embedded or hosted previews from AI coding tools:

1. Resolve the actual preview surface rather than testing the editor shell.
2. Capture the issue in the preview.
3. Draft a concise prompt containing the reproduction, expected behavior,
   evidence, and acceptance check.
4. Show the prompt and planned destination.
5. Send or apply it only after scoped user approval.
6. Re-test the same reproduction after the change.

Do not enable unattended auto-fix behavior by default.

## 7. Manual-testing copilot and handoffs

Support:

- form scanning and varied non-sensitive test-data suggestions;
- local test-case lists with pass, fail, blocked, and note states;
- tracker-ready bug drafts for JIRA, GitHub Issues, Linear, Azure DevOps, or the
  user's chosen system;
- TestRail- or spreadsheet-ready test-case payloads;
- screenshots and page URLs as evidence;
- copy-ready text summaries, structured JSON, and fix prompts.

Creating the payload is local. Filing it, uploading evidence, or writing to a
third-party system is a separate external action and requires the user's
authorization plus an available integration.

## 8. Evidence contract

Each finding should contain:

- title and severity;
- user or business impact;
- starting state and exact reproduction;
- expected and actual behavior;
- screenshot or browser telemetry reference;
- reproducibility status;
- affected URL and environment;
- copy-ready fix prompt;
- uncertainty and next verification step.

For every tested page/state, capture every safely available channel: screenshot,
DOM/accessibility snapshot, console/page errors, failed requests, bounded and
redacted request/response metadata, response status, timing, layout shift and
performance, synthetic data, storage-safe metadata, trace, and recording/video.
Run the general issue review across the combined artifacts and show screenshots
in the report beside the signals they support. Record unsupported or
privacy-withheld channels explicitly. Never invent telemetry or persist raw
credentials, cookies, tokens, or unrelated private response bodies.

## 9. Deliberate exclusions

Do not carry forward:

- hard-coded unlock secrets, admin codes, or subscription bypasses;
- direct third-party model API-key handling in page scripts;
- silent cloud fallback or silent paid usage;
- automatic passing based only on a plausible screenshot;
- automatic issue filing, chatbot submission, or code mutation;
- broad all-URL data capture unrelated to a user-initiated test.
