# CARBON report contract

Use this shape for both plans and executed tests. Keep it concise for focused requests and expand it for a full sweep.

## Brand shell

Every generated HTML report uses the CARBON marketing identity: a pure black
canvas, white typography, restrained gray structure, and the white geometric
cut-C mark beside `CARBON / ENGINEERING CONFIDENCE`. Status colors communicate
evidence state only. testers.ai remains visible as ownership attribution in the
footer rather than replacing the CARBON masthead.

Each primary section and information block uses a relevant custom inline SVG
from the CARBON report icon family. Remaining risk uses orange (`#ff9f43`),
distinct from confirmed-failure red and warning amber. Layouts use editorial
hierarchy—decision spreads, evidence-led sections, ledgers, timelines, and
grouped context bands—instead of a uniform card grid.

## Header

- **Target:** URL/path/artifact and build/version when known
- **Mode:** Plan, Test, Review, or Focused
- **Evidence basis:** live behavior, browser, screenshot, source, requests, logs
- **Environment and identity:** target tier and role(s)
- **Safety boundary:** what was allowed and intentionally not run

## Detected surface

List detected elements with:

| Element | Evidence | Match | Loaded item files |
|---|---|---:|---|
| Username field | label + input attributes | high | controls-input, auth-people-access |

State important absences and ambiguities. Do not pad the list with decorative nouns.

## Release bar

State the smallest set of Must behaviors that need to pass for this surface to be trusted. Tie each to the user promise or risk.

## Test suite

Give every case a stable ID:

| ID | Pri | Scenario / variation | Oracle | Status | Evidence |
|---|---|---|---|---|---|
| CAR-AUTH-001 | Must | Submit valid active-user credentials | Authenticated once; intended return route | Pass/Fail/Blocked/Planned | E3 + artifact |

Use one row for one decision-relevant variation. Do not collapse a large boundary set into “test validation.” For an extensive plan, group rows under the relevant control or behavior.

For tests designed from a suspected source defect, show both the normative
oracle and the pre-execution prediction. `predictedOutcome: fail` means the
test is intentionally expected to expose a defect. Keep its execution status
`planned` until it runs; if it fails, report “suspected defect confirmed” while
retaining the ordinary product-failure status.

Statuses:

- **Pass:** observed result met the oracle.
- **Fail:** observed result contradicted a grounded oracle.
- **Blocked:** execution was attempted or required but a named dependency prevented it.
- **Planned:** selected but not executed in this mode/safety boundary.
- **Explore:** expected behavior is intentionally unresolved.

## Findings

Order by impact, then confidence. For each defect:

- concise title and severity;
- exact starting state and steps;
- expected result and its oracle;
- actual result;
- evidence tier and artifact;
- scope/blast radius;
- safe copy-paste repair prompt when useful;
- regression checks after repair.

Do not call a convention violation a defect unless it creates measurable user, accessibility, security, integrity, or product-promise harm.

## Every-page evidence observatory

For every browser page or materially different page state that was actually
tested, retain and render the richest safely available bundle:

- screenshot(s), viewport, URL, title, state, and linked test IDs;
- bounded DOM and accessibility snapshots;
- console messages plus uncaught/page errors;
- bounded, redacted request/response metadata, status, failure, and timing;
- performance and Web Vitals when exposed;
- synthetic test inputs/outputs and storage-safe state metadata;
- trace, recording/video, downloaded artifact, and other adapter evidence;
- explicit unavailable or privacy-withheld channels.

Show screenshots in context, not as an appendix of unexplained images. Record a
visual review for each safe screenshot covering general layout, clipping,
overlap, content, state, and responsive issues. For each page, analyze all
collected artifacts for general DOM, accessibility, console,
network, mixed-content/security, performance, privacy/redaction, and test-result
signals. Correlate evidence across channels and repeated pages, but label a
correlation as investigation support rather than a proven root cause. A missing
channel is an evidence gap, not a pass or failure.

## Persona and exploratory evidence

Every executed browser pass must state its coverage shape:

- **breadth:** sample the reachable routes, widgets, roles, states, transitions,
  linked APIs, and representative responsive/accessibility surfaces;
- **depth:** follow the highest-risk journey through negative and boundary data,
  interruption, retry, recovery, persistence, permissions, and neighboring state;
- **balanced:** map broadly first, then drill into the strongest observed risk.

Show the rationale and each exploratory charter. Attach every observation to
the page/state, screenshot, action, linked test IDs, observed result, next
probe, and stop condition. Breadth and depth are coverage strategies, not
claims that the entire product was tested.

Show generated end-user feedback in visual cards beside the relevant page
evidence: role, goal, 1–5 dimension ratings, what worked, friction,
recommendation, confidence, and supporting evidence. Derive perspectives from
actual product roles, goals, flows, and access needs. Keep them separate from
the named CARBON testing specialists. Persona opinion can reveal a product
risk, but it is not a deterministic pass/fail oracle unless corroborated by a
grounded product contract and observed behavior.

## Coverage and uncertainty

Summarize:

- passed/failed/blocked/planned counts by Must/Should/Explore;
- elements and risk areas covered;
- identities, states, browsers/viewports, transports, and data boundaries not covered;
- differences between screenshot/source inference and executed evidence;
- destructive/security/load cases deliberately not run;
- recommended next evidence, in priority order.
- planned personas or exploration charters without captured evidence.

## Completion rule

A green happy path is not completion. Finish when the highest-risk claims have direct evidence, severe failures are absent or explicit, recovery and permission boundaries are checked, and remaining uncertainty is visible enough for a decision.
