Antigravity Generative UI for QA: Validate Test Evidence Dashboards

Antigravity generative UI for QA can turn a dense test report into an inline HTML dashboard with tables and charts. That is useful when a release has hundreds of results and a reviewer needs to spot failures, retries, duration spikes, or missing coverage quickly. It is also easy to trust the presentation before proving that the numbers came from the correct report.

This tutorial builds a disposable evidence dashboard from synthetic test data. You will freeze the source reports, ask Antigravity to generate one reviewable HTML artifact, challenge it with difficult fixtures, recalculate every metric independently, and keep deterministic CI plus human judgment as the release authority.

What Google officially documents

Google’s current Antigravity changelog says the August 26, 2026 Antigravity 2.11.0 release added Generative UI for rendering HTML artifacts inline in chat. The same entry documents support for KaTeX, Chart.js, and Plotly in Generative UI widgets and artifact previews.

The official Artifacts documentation describes artifacts as structured agent deliverables that support asynchronous review and feedback. Google’s Artifact Review documentation distinguishes Request Review from Always Proceed and recommends pausing to inspect plans or code changes. The current Settings documentation keeps project scope, tool permissions, sandboxing, and outside-folder access as separate controls.

What the lab will prove

The dashboard is not the source of truth. It is a view over immutable evidence. The lab should prove five things:

• the dashboard reads the intended report version;
• every displayed total can be reproduced independently;
• bad or ambiguous data fails visibly instead of becoming a plausible chart;
• the HTML does not introduce unexpected resources, active actions, or fabricated rows; and
• the review becomes stale whenever the input or dashboard changes.

Use a private repository with only synthetic names and results. Do not copy production URLs, customer identifiers, tokens, screenshots, or internal stack traces into the prompt or artifact.

Step 1: create frozen source evidence

Export a small machine-readable result file from a deterministic test run. JSON is convenient, but the method works with normalized JUnit XML or another documented schema. Include a run identifier, commit SHA, environment, start and end timestamps, and one row per final test outcome.

{
  "run_id": "AG-GUI-031",
  "commit": "full-recorded-sha",
  "schema": "qa-result-v1",
  "tests": [
    {"id":"checkout-card","status":"passed","duration_ms":842,"attempts":1},
    {"id":"checkout-tax","status":"failed","duration_ms":1190,"attempts":2},
    {"id":"checkout-coupon","status":"skipped","duration_ms":0,"attempts":0}
  ]
}

Hash the raw report and store the hash outside the generated dashboard. Record the test command, runner version, operating system, timezone, locale, branch, full commit, dependency lock hash, and report schema. If any of these values are unknown, label them unknown rather than letting the agent infer them.

Step 2: define an explicit metric contract

Write the calculation rules before generating the UI. For example:

• Total: unique final test IDs after rejecting duplicates.
• Passed, failed, skipped: count only documented final status values.
• Flaky: passed on the final attempt after at least one earlier failed attempt.
• Retry count: sum of attempts minus one, never below zero.
• Duration: use the final recorded duration in milliseconds; do not convert missing data to zero.
• Pass rate: passed divided by executed tests; exclude skipped tests and show the denominator.

These definitions prevent the chart from silently choosing a different denominator or treating a retry as another test. Save the contract as a reviewed file and hash it with the source report.

Step 3: request one bounded artifact

Use Planning Mode and Request Review. Give Antigravity a narrow prompt:

Create one self-contained HTML artifact for AG-GUI-031.
Read only the supplied synthetic report and metric contract.
Show the run identity, source hash, summary table, status chart,
slow-test table, retry list, and validation warnings.
Use Chart.js or Plotly only if available in this installed build.
Do not fetch remote data, invent missing values, edit the report,
write outside the project, or add buttons that trigger actions.
Keep a plain table that exposes every chart value.
Stop on duplicate IDs, unknown status values, or schema mismatch.
A QA engineer will independently recalculate all metrics.

Record the complete prompt, the generated HTML hash, and the Antigravity build. Review the raw HTML as well as the rendered artifact. A convincing screenshot is not enough.

Step 4: verify the clean control

Calculate the expected counts with a small reviewed script or the test runner’s own report processor. Compare the dashboard’s visible totals, percentages, labels, duration units, ordering, and source identity with that independent result.

Check the chart and its fallback table row by row. Hover values are useful for exploration, but reviewers should not need a pointer to discover a failure count. The run ID, commit SHA, schema, report hash, timezone, and generated timestamp should be visible without exposing sensitive paths.

Step 5: challenge the data model

Create separate immutable fixtures for these cases:

• zero tests and an empty file;
• all passed, all failed, and skipped-only runs;
• duplicate test IDs with conflicting outcomes;
• a test that fails, retries, and passes;
• unknown statuses, missing duration, negative duration, and non-numeric values;
• a very large duration outlier that compresses the rest of the chart;
• thousands of rows and very long test names;
• Unicode, right-to-left text, quotes, angle brackets, and markup-like test names;
• mixed schema versions and a stale report from another commit;
• timestamps around midnight and daylight-saving changes; and
• truncated or malformed input.

The expected behavior should be documented for each fixture. Ambiguous inputs should produce a visible validation warning and no release-ready summary. They should not be repaired silently.

Step 6: test retries and flaky classification

Retries create misleading dashboards when every attempt is counted as a separate test. Build fixtures with a stable pass, stable failure, fail-then-pass, pass-then-fail, and exhausted retry. Confirm the final status and attempt history remain separate dimensions.

Recalculate the flaky count from raw attempt records. If the source report contains only a final status and no attempt history, show flaky data unavailable. Do not let the agent infer a flaky result from duration, logs, or test name.

Step 7: inspect HTML and resource boundaries

Review the generated HTML for unexpected network URLs, script sources, forms, uploads, navigation targets, hidden content, or action buttons. Confirm it reads only the reviewed local input or embedded sanitized data. Use the browser’s network and console tools in a disposable profile if the artifact executes client-side code.

Treat report fields as untrusted text. A test name containing markup-like characters must render as text, not executable content. Add a harmless canary string and verify it appears only in the intended table cell and never as HTML, a URL, or a script value.

Step 8: test rendering without confusing it with correctness

View the artifact in light and dark themes, a wide desktop layout, and a narrow mobile-sized pane. Check long labels, zoom, high contrast, focus order, and keyboard access. Every visual chart should have a readable table or text summary with the same values.

Run an automated accessibility scan and a manual keyboard check, but keep the findings separate from metric correctness. A dashboard can be accessible and numerically wrong, or accurate and unusable. Both dimensions need explicit evidence.

Step 9: prove stale-artifact detection

Change one source fixture after the dashboard is generated. The report hash must change, and the old dashboard must fail the identity check. Repeat with a changed metric contract and with the same report copied under another filename.

Immediately before review approval, recompute the report, contract, and HTML hashes. If any value differs from the recorded bundle, discard the screenshot and regenerate the artifact. Approval belongs to an exact evidence set, not a filename.

Step 10: compare the dashboard with CI

The final dashboard summary should match the authoritative CI run for the same commit and environment. Compare test counts, final statuses, retry history, durations, start and end timestamps, and artifact identity. Investigate differences instead of choosing whichever presentation looks cleaner.

Keep the raw runner report, CI link or run identifier, calculation output, generated HTML, screenshots, source hashes, validation warnings, accessibility report, and reviewer decision together. Redact secrets before sharing the evidence bundle.

QA evidence matrix

Risk	Test	Independent evidence
Wrong report	Stale commit fixture	Run ID, commit, and report hash
Inflated totals	Duplicate IDs and retries	Normalized unique-ID calculation
Hidden missing data	Absent and malformed fields	Schema validator output
Fabricated metric	Final-only report without attempts	Raw attempt availability
Unsafe rendering	Markup-like test names	Raw HTML and network inspection
Inaccessible chart	Keyboard and narrow layout	Fallback table and accessibility scan
Stale approval	Change report after generation	Report, contract, and HTML hashes

Screenshot plan

Capture the official Generative UI announcement, installed-build check, frozen raw report with hashes, metric contract, bounded artifact prompt, clean dashboard with source identity, duplicate and malformed-data warnings, retry fixture, raw HTML and network inspection, accessible narrow layout, and final CI-to-dashboard reconciliation. Redact usernames, machine paths, repository remotes, account details, and internal URLs.

Final checklist

• Confirm Generative UI and the selected chart library in the installed build.
• Use synthetic reports in a disposable private project.
• Freeze run, commit, schema, timezone, locale, prompt, and hashes.
• Define metric denominators and retry rules before generation.
• Keep a table exposing every chart value.
• Reject duplicates, unknown statuses, malformed input, and schema drift visibly.
• Inspect raw HTML, resource use, and hostile-text rendering.
• Test themes, narrow layouts, keyboard access, and fallback content.
• Recalculate every metric independently and compare it with CI.
• Keep defect, merge, release, and dashboard adoption decisions human-owned.

Conclusion

Antigravity’s Generative UI can make test evidence faster to understand, especially when raw reports are too large for a quick review. The safe QA pattern is to bind the dashboard to exact source hashes, define metrics before visualization, attack the input model, inspect the generated HTML, expose chart values in plain tables, and reconcile everything with deterministic CI. That turns a polished artifact into a useful review surface without turning it into an unearned source of truth.