On this page ▾
Inspect, fix and verify
This guide walks an agent through one loop with the audit tool: take a baseline of the running page, fix a finding in the code, and compare the page after the change with the baseline. You can run the same loop by hand on the Audit tab.
Before you start
agent.readOnly is off, so the agent can run axe and record change detection.
The loop
list-pages.
audit with session: "before" and axe: true.
audit with session: "after" and axe: true.
Step 1: Pick the page
Call list-pages. If more than one tab reports, pass its id as page to every call below. Without page, each tool uses the most recent page, which can change when you open another tab.
Step 2: Record what you measure
The audit reads what the inspectors already hold. Errors, hydration, router, form and HTTP findings are there as soon as the page reports. Change detection numbers need a recording:
{"tool": "pangular:record-change-detection", "arguments": {"record": "start", "page": "k3x9"}}Then use the app: open the screens and click what the change is about. Subscriptions after destroy need tracking, so call track-subscriptions with action: "start" too if leaks matter to the change.
Step 3: Take the baseline
{"tool": "pangular:audit", "arguments": {"session": "before", "axe": true, "page": "k3x9"}}The answer is the ranked list of findings, the key numbers and what the audit could not check. It saves the audit as the page's baseline for 30 minutes after its last use. A reload keeps the page id, so the baseline survives the rebuild after your change.
Step 4: Read the detail and fix
Each finding names the tool that explains it, with the arguments to pass, such as explain-error { id: "e1" } or diagnose-change-detection. For accessibility findings, call audit with area: "accessibility": it lists the elements that break each axe rule, their component and instance id, and a link to the rule. Pass an instance id to inspect-component, or to highlight to show the user where it is.
Fix one area at a time, so the comparison says what each change did.
Step 5: Repeat the same steps
After the reload, the recording, the leak data and the error list start again. Start a change detection recording and use the app the same way as before the change. The numbers only compare when the page did the same work.
Step 6: Compare
{"tool": "pangular:audit", "arguments": {"session": "after", "axe": true, "page": "k3x9"}}The answer adds a Before and after section:
| Part | What it shows |
|---|---|
| Numbers | Each number before and after, with the difference marked better or worse. Lower is better for every number. |
| Resolved | Findings the baseline had and the after audit doesn't. |
| New | Findings only the after audit has. Look at these before you call the change done. |
| Still there | Findings in both. When a count moved, it lists those findings, otherwise the first five. |
When only one of the two audits ran axe, or both used the same pass, accessibility findings are not compared, and a note says so. A reload drops the page's last axe pass, so pass axe: true again after the change. Call audit with session: "after" again after another fix: it compares with the same baseline. Call it with session: "before" to start over from the current state, or session: "clear" to drop the baseline.
Show the user
Call open-in-panel with tab: "audit" to give the user a link to the same list and comparison in the panel.
Gotchas
agent.readOnly, audit has no axe argument and record-change-detection is not registered. Run axe and the recording from the panel, and the agent's audit reads them.
- Findings are matched by area, rule and subject, not by position. A renamed component or route counts as one finding resolved and one new.
- An area whose inspector or agent tools are off is left out, and Coverage names it.
- Pipe findings come from the source scan, so they change only when the source does.