WCAG specialist focused on criterion-level evidence across perceivable, operable, understandable, and robust behavior, without overstating automated scan results as conformance.
A perspective available to CARBON—not a claim that this tester has reviewed your project. Findings require execution evidence.
Compatibility specialist focused on browser, device, viewport, operating-system, assistive-technology, and support-matrix evidence, with explicit coverage gaps rather than assumed portability.
A perspective available to CARBON—not a claim that this tester has reviewed your project. Findings require execution evidence.
Performance specialist focused on user-visible latency, Core Web Vitals, payload and request cost, caching, API timing, scalability, mobile constraints, memory, and leaks.
A perspective available to CARBON—not a claim that this tester has reviewed your project. Findings require execution evidence.
Content and UX-writing specialist focused on page identity, clear copy, information architecture, credibility, navigation, status communication, readability, and content quality.
A perspective available to CARBON—not a claim that this tester has reviewed your project. Findings require execution evidence.
Forms specialist focused on input contracts, validation, boundaries, state, submission, recovery, data quality, conversion barriers, and accessible interaction.
A perspective available to CARBON—not a claim that this tester has reviewed your project. Findings require execution evidence.
First-impression and conversion specialist focused on value clarity, trust, navigation, calls to action, responsive composition, dead ends, and page credibility.
A perspective available to CARBON—not a claim that this tester has reviewed your project. Findings require execution evidence.
Checkout and payment specialist focused on order accuracy, address and payment input, trust, retry safety, pricing truth, completion, and conversion-blocking failures.
A perspective available to CARBON—not a claim that this tester has reviewed your project. Findings require execution evidence.
AI
Virtual AI tester
Priya
Shopping Cart Tester
Shopping-cart specialist focused on line-item state, quantities, promotions, totals, inventory changes, persistence, accessibility, and safe transition to checkout.
A perspective available to CARBON—not a claim that this tester has reviewed your project. Findings require execution evidence.
AI
Virtual AI tester
Mateo
Pricing Page Tester
Pricing and subscription specialist focused on plan clarity, comparison, currency and locale, hidden conditions, billing cadence, conversion paths, and truthful claims.
A perspective available to CARBON—not a claim that this tester has reviewed your project. Findings require execution evidence.
AI-generated-code specialist focused on logic, boundaries, null and empty states, failure handling, API use, security, privacy, tests, code smells, state, and misleading AI shortcuts.
A perspective available to CARBON—not a claim that this tester has reviewed your project. Findings require execution evidence.
A service going away is a technical event. Losing a customer's work
because the app did not recover is a product failure.
/carbon-reliability focuses on resilience: partial
failures, retries, idempotency, restarts, races, observability, and
rollback behavior.
Test the unfinished
operation
Imagine a background export. The job starts, writes part of a file,
and loses its worker. On restart, does it resume safely, start again, or
tell the user the incomplete file is ready?
That is a sequence with an expectation, not a request to “test
reliability” in the abstract. Source inspection helps identify the
transition. An isolated runtime experiment can establish how the system
behaves under the selected conditions.
The agent should inspect both visible feedback and authoritative
state where available. A recovered process does not prove the data
recovered. A retry loop does not prove the operation is idempotent.
Ask about one important
failure
/carbon-reliability investigate interrupted exports and restart recovery in the local test environment; use synthetic records and propose faults before injecting them
The report should explain the interruption, the observed recovery,
what was retained or lost, and how to verify a repair. An unavailable
dependency is a limit, not evidence that recovery is safe.
Reliability is not a promise that nothing ever fails. It is an
account of how the product contains failure and gets the user somewhere
sensible afterward.
That account deserves testing before the first real incident writes
it for you.
Install CARBON at testers.ai/carbon for a supported
coding agent such as Claude, Codex, or Cursor.
