C-refresh part 2/2 — structure: responsive collapse, SVG icons, all six status glyphs, type-derived attachment labels (refs #439) - #459

The WCAG contrast test's effectiveBackground() walk treated any element's
non-transparent computed background-color as a real painted surface. The
#439 icon refresh (merged to main via #459, which this branch predates)
switched .preview-icon and friends to `mask-image` + `background-color:
currentColor` — the standard single-colour tintable-icon technique. That
background-color is clipped to the icon's silhouette by the mask; it is
never a rectangle behind text. For any such element, currentColor makes
the "background" trivially equal the "foreground" by construction, so the
walk found a spurious 1.00:1 wherever a masked icon happened to pick up
sampleable text.

That happened here because of a real (separate, out of scope for this
fix) HTML-escaping bug: the synthetic fixture's edge-case filename
containing a raw `"` breaks out of `data="[[FILENAME]]"`, leaking markup
as text children of the otherwise-empty .preview-icon span and an
unrecognized <greaterthan> element the broken parse produces. That leak is
real and made both elements eligible for sampling; skipping masked
elements in the background walk makes the walk find the same true
ancestor surface every other passing text element already clears against.

Diagnosed by downloading the exact fixture CI's dump job produced
(GH Actions run 31745292239) and reproducing the 1.00:1 locally against
that fixture with plain diagnostic instrumentation: this branch's own
fixture predates #459's icon refresh entirely, which is why "8/8 green
locally" and "2/8 red in CI" were both true — pull_request's default
checkout tests the PR merged with current main, not the branch alone.

The WCAG contrast test's effectiveBackground() walk treated any element's
non-transparent computed background-color as a real painted surface. The
#439 icon refresh (merged to main via #459, which this branch predates)
switched .preview-icon and friends to `mask-image` + `background-color:
currentColor` — the standard single-colour tintable-icon technique. That
background-color is clipped to the icon's silhouette by the mask; it is
never a rectangle behind text. For any such element, currentColor makes
the "background" trivially equal the "foreground" by construction, so the
walk found a spurious 1.00:1 wherever a masked icon happened to pick up
sampleable text.

That happened here because of a real (separate, out of scope for this
fix) HTML-escaping bug: the synthetic fixture's edge-case filename
containing a raw `"` breaks out of `data="[[FILENAME]]"`, leaking markup
as text children of the otherwise-empty .preview-icon span and an
unrecognized <greaterthan> element the broken parse produces. That leak is
real and made both elements eligible for sampling; skipping masked
elements in the background walk makes the walk find the same true
ancestor surface every other passing text element already clears against.

Diagnosed by downloading the exact fixture CI's dump job produced
(GH Actions run 31745292239) and reproducing the 1.00:1 locally against
that fixture with plain diagnostic instrumentation: this branch's own
fixture predates #459's icon refresh entirely, which is why "8/8 green
locally" and "2/8 red in CI" were both true — pull_request's default
checkout tests the PR merged with current main, not the branch alone.

Rebased onto origin/main (f442e8e), which merged #459 mid-execution of
this branch's plan: an icon refresh adding status-glyph and icon tokens
(SVG masks replacing base64 PNGs), a responsive @media (max-width: 700px)
breakpoint, and type-derived attachment labels. TemplateSnapshotTests
correctly caught the drift (Snapshot index/index-inline changed).

Refreshed with XCHR_UPDATE_SNAPSHOTS=1 swift test --filter
TemplateSnapshotTests (which itself fails on purpose per the FIX-2
change), then re-ran clean and read both goldens in full before
committing: well-formed, properly closed, the hostile-filename markup
this branch's expected-failure regression test depends on is still
present and unescaped.

* Design: test coverage for the rendered report

Nothing here has ever asserted anything about how the report looks. The
three existing comparisons -- DifferentialTests, ReproducibilityTests,
BaselineCaptureTests -- all compare one render to another render, and
none of them knows what any of it means. A token that resolves to
nothing, a dark-mode palette that fails contrast, a filter tab that
stops filtering: all pass silently.

That became load-bearing when #439 started redesigning the UI. #455
tokenized the stylesheet and claimed "zero visual change" with no test
able to confirm it; #456 adds dark mode and asserts WCAG floors. Those
are claims a browser checks mechanically and a reviewer cannot.

Three layers over one synthetic ParsedResult fixture: unit tests on
model logic, per-template HTML goldens, and Playwright for the facts
only a browser knows. Layers 1 and 2 add no toolchain and need neither
simulator nor .xcresult.

The design turns on a constraint BaselineCaptureTests already documents:
fixtures regenerate, so a golden keyed to one cannot be checked in. The
way out is to stop feeding renders from generated fixtures -- hence the
synthetic fixture, and hence the one production change, a Summary
initialiser taking pre-parsed runs.

Also records a defect found while writing this: TestScreenshotFlow
discards its tailCount parameter and hardcodes suffix(3).

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>

* Plan: report visual test coverage, 13 tasks in three phases

Phase 1 builds the Swift foundation -- a StubPayloadProvider, a synthetic
ParsedResult covering every rendered status, and a Summary initialiser
taking pre-parsed runs. Phase 2 adds golden snapshots keyed to that
fixture rather than to a generated .xcresult, which is what makes them
committable at all. Phase 3 adds the browser layer.

Task 1 opens RED on the tailCount defect the spec recorded. Task 12
hands the finished suite to #456 and unskips the dark-mode assertion
there, which is the sequencing argument's payoff: the first claim about
how this report looks that a machine, not a reviewer, checks.

Three assertions in the plan are verified by deliberately breaking
something and confirming the failure -- an undeclared token reference, a
contrast floor, and a changed golden -- because an assertion that has
never failed is one nobody should trust.

Selectors are taken from HTMLTemplates.swift rather than guessed:
`.selected` is the live selection class, group rows sit under
`.run.active`, and the filter tabs are `<li>` elements carrying counts.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>

* TestScreenshotFlow honours tailCount instead of hardcoding 3

* Synthetic ParsedResult fixture covering every rendered state

* Fix PayloadProviding member count in the visual-test-coverage design spec

The spec called PayloadProviding a three-member protocol, but it declares
five: url, exportPayload, exportPayloadData, exportLogs, exportLogsData.
Task 2's SyntheticResultTests fixture is what surfaced the discrepancy.

* Deduplicate SyntheticResultTests' ParsedTestCase extraction, widen filename assertion

Review fix round 1: the three tests repeated the same 11-line
runs→testables→groups→ParsedNode extraction chain verbatim. Extracted a
private allTestCases() helper. Also widened
testCoversHostileAttachmentFilename to require all five hostile
characters the fixture filename actually carries ("'<>&), not just two
of them, so the assertion pins what the fixture provides.

* Summary initialiser taking pre-parsed runs, for fixture-free rendering

Adds an internal Summary.init(parsedRuns:payloads:renderingMode:
downsizeImagesEnabled:downsizeScaleFactor:faultCollector:bundleNames:),
alongside the existing public path-based initialiser, so tests can render
a full report page from SyntheticResult's fixture with no .xcresult and
no simulator. This is the injection point #391 made possible: ParsedRun
is now the boundary between reading and rendering, so tests can construct
one directly instead of reading it out of a bundle.

Internal, not public, because PayloadProviding is internal;
@testable import reaches it from tests while library consumers keep the
resultPaths-based initialiser untouched.

SummarySeamTests exercises the new seam: a full page renders
(<!doctype html>, the fixture's SyntheticSuite group, the :root token
layer), the complete synthetic tree produces zero faults, and two
renders of the same fixture are byte-identical.

* Give the synthetic fixture a real log reference, so Run.init? stops degrading

SyntheticResult.parsedRun passed logReference: nil, which sent Run.init?
down the else branch: a warning to the console, and logContent = .none —
no logs section at all in the rendered page. Every golden HTML file from
Task 4 onward would have pinned a report missing that pane, and
StubPayloadProvider.exportLogs/exportLogsData would have stayed dead code
no test ever reached. Fixing this now, before any goldens exist, is the
cheapest point to do it.

StubPayloadProvider gains a logText constant and real exportLogs/
exportLogsData implementations that mirror exportPayload/exportPayloadData:
resolve from the same exports map, touch no filesystem. SyntheticResult
registers a logReference in payloads and wires it into parsedRun.

SummarySeamTests.testRendersAFullPageWithoutAnXcresult now asserts the
logs iframe doesn't degrade to an empty src. A new test,
testInlineRenderingEmbedsTheActualLogBytes, proves the fixture's log
bytes reach the rendered page for real: under .inline rendering the
iframe src is a data: URI, so the exact base64 encoding of logText is
a verifiable substring of the output. .linking mode (used elsewhere in
this file) only yields a content-free relative file name, so it cannot
by itself prove real bytes made the trip — the .inline mode assertion is
required to confirm the fix's actual purpose, not just that the warning
went away.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>

* Snapshot harness and the index golden, keyed to the synthetic fixture

* Inline-mode golden alongside the linking-mode one

* Correct the no-fixtures verification claim: park only the .xcresult bundles

Parking the entire Resources directory also removes differential-allowlist.json,
the fourth Package.swift-declared resource. With zero resolvable resources
SwiftPM synthesizes no Bundle.module, breaking the whole test target's build —
a packaging artifact, not evidence the synthetic-fixture suites need .xcresult
fixtures. Parking only the three .xcresult bundles isolates the actual claim.

* Dump the synthetic render for the browser suite

* Playwright scaffold and token-resolution assertions

Introduces the browser test layer: a pinned Playwright + axe-core
devDependency set, chromium-only config with retries disabled, and two
assertions over the report's computed CSS custom properties — every
declared :root token resolves to a non-empty value, and no rule
references a token that was never declared.

Verified the second assertion actually bites: temporarily broke a
var(--color-text-primary) reference in HTMLTemplates.swift to
var(--color-text-nonexistent), re-dumped the fixture, and watched
`no rule references an undeclared token` fail naming the bogus token.
The template edit was reverted before committing.

* Recurse into grouping rules so dark-mode :root is not blind spot

Both CSS scanners in tokens.spec.ts filtered on `rule instanceof
CSSStyleRule`, which is false for CSSMediaRule — so the
@media (prefers-color-scheme: dark) :root block PR #456 added was
invisible to both assertions. A stylesheet with a token declared or
referenced only inside that block would pass "no rule references an
undeclared token" vacuously; the name was inaccurate.

Walk CSSGroupingRule.cssRules recursively (covers @media, @supports,
@layer alike) in both evaluate bodies. Verified the walk now visits 2
:root rules instead of 1, and that a var() reference broken *inside*
the dark block is caught post-fix but was silently missed by the
pre-fix scanner against the same fixture.

* WCAG contrast and dark-mode assertions, dark mode unskipped (#456 landed)

* axe-core runs without gating; all findings filed on #440

* Behavioural assertions for filters and keyboard navigation

* Run the browser assertions in CI

Adds a two-job workflow: a macOS job dumps the synthetic render fixtures
via VisualFixtureDumpTests (no simulator, no .xcresult, no
prepareTestResults.sh needed — Package.swift's differential-allowlist.json
resource is enough to synthesize Bundle.module), then an Ubuntu job
downloads those fixtures and runs the Playwright suite against them.

setup-node and download-artifact are pinned to their actual latest
releases (v7.0.0 and v8.0.1) rather than the older SHAs from the initial
draft; download-artifact's SHA matches the one already pinned in
release.yml.

* Fix effectiveBackground() to skip masked icon fills

The WCAG contrast test's effectiveBackground() walk treated any element's
non-transparent computed background-color as a real painted surface. The
#439 icon refresh (merged to main via #459, which this branch predates)
switched .preview-icon and friends to `mask-image` + `background-color:
currentColor` — the standard single-colour tintable-icon technique. That
background-color is clipped to the icon's silhouette by the mask; it is
never a rectangle behind text. For any such element, currentColor makes
the "background" trivially equal the "foreground" by construction, so the
walk found a spurious 1.00:1 wherever a masked icon happened to pick up
sampleable text.

That happened here because of a real (separate, out of scope for this
fix) HTML-escaping bug: the synthetic fixture's edge-case filename
containing a raw `"` breaks out of `data="[[FILENAME]]"`, leaking markup
as text children of the otherwise-empty .preview-icon span and an
unrecognized <greaterthan> element the broken parse produces. That leak is
real and made both elements eligible for sampling; skipping masked
elements in the background walk makes the walk find the same true
ancestor surface every other passing text element already clears against.

Diagnosed by downloading the exact fixture CI's dump job produced
(GH Actions run 31745292239) and reproducing the 1.00:1 locally against
that fixture with plain diagnostic instrumentation: this branch's own
fixture predates #459's icon refresh entirely, which is why "8/8 green
locally" and "2/8 red in CI" were both true — pull_request's default
checkout tests the PR merged with current main, not the branch alone.

* Fix undeclared-token scan to see shorthand var() references

rule.style iterated longhand-by-longhand: Chromium stores a shorthand
containing var() (e.g. border: 1px solid var(--color-border-strong)) as a
pending-substitution value, so every expanded longhand serialises to "".
Scanning rule.style.cssText instead sees the literal var(...) text
regardless of shorthand expansion.

Confirmed by mutation: before the fix the scan found 28 of 34 var()
references; after, all 34. Deleting --color-border-strong from
HTMLTemplates.swift's :root (both light and dark blocks) now makes the
test fail, naming the token; previously it stayed green.

* Fail a snapshot refresh run instead of reporting it green

The XCHR_UPDATE_SNAPSHOTS=1 branch wrote the golden and returned, so a
refresh run was unconditionally green — writing bytes proves nothing about
whether the new content is correct. XCTFail after a successful write so
CI can never pass while the env var is set, and a developer refreshing
locally is prompted to re-run without it for a real verdict.

* Rename a11y test to state what it actually checks

GATING_IMPACTS = [] (correctly, per #440) makes the assertion
expect([]).toEqual([]) — it cannot fail regardless of what axe finds, but
the old name ("report has no critical or serious accessibility
violations") claimed a guarantee the test does not provide. Renamed to
describe the gate's actual state and expanded the comment to record all
six known findings (image-alt critical x6, frame-title serious,
heading-order/landmark-one-main/region moderate, empty-heading minor) so
the debt is legible without re-running the suite.

* Add expected-failure regression test for hostile-filename escaping

SyntheticResultTests.testCoversHostileAttachmentFilename asserts the
fixture contains a filename with " ' < > & — but nothing asserted the
render escapes it, and it does not: HTMLTemplates.swift interpolates the
raw filename into onclick="showText('[[SOURCE]]')" unescaped, so the
embedded double quote breaks out of the attribute. The committed goldens
already contain this broken markup.

Adds a regression test wrapped in XCTExpectFailure recording the defect
(HTMLTemplates.swift / Attachment.swift, out of scope here) without
turning the suite red. The moment the escaping is fixed, XCTExpectFailure
flips this into a hard failure — an unexpectedly-passing expected
failure — which is the loud signal that the test should be promoted out
of the wrapper.

* Amend the design spec to match what actually shipped

Whole-branch review found five claims in the spec the delivered work does
not satisfy. Recorded as a dated Amendments section rather than editing
history: fixture attachment coverage (PNG/text only, not video/HTML),
behavioural assertions (2 of 3 shipped — no attachment-click-populates-
preview test), contrast pairing discovery (sampled from one static DOM
state, not the cascade; --color-text-secondary and --color-accent-soft
are never exercised as text colour in the fixture's default render), axe
moderate/minor reporting (console.log, not $GITHUB_STEP_SUMMARY), and
Sequencing (PR #456 merged first and is this branch's merge-base, so the
suite did not land before #456 as planned — #456's claims were verified
retroactively instead, and confirmed sound).

* Document the visual test layer in CONTRIBUTING.md

"CI runs exactly these two commands, so a green run locally means a green
run on your pull request" stopped being true once the Visual workflow
landed. Corrected the claim and documented the two layers CONTRIBUTING.md
was silent on: template snapshots (XCHR_UPDATE_SNAPSHOTS=1 to refresh,
and why a refresh run always fails) and the Playwright browser layer
(dump via XCHR_VISUAL_DIR swift test --filter VisualFixtureDumpTests,
then npm ci + npx playwright test in visual/).

* Drop the test-fixture default from Summary's seam initialiser

bundleNames: [String] = ["Synthetic"] put a test fixture's name into
production source as a default value. Made it a required parameter and
updated the three callers (SummarySeamTests, TemplateSnapshotTests,
VisualFixtureDumpTests) to pass "Synthetic" explicitly — the goldens'
<title> is unchanged because the value itself didn't change, only where
it's supplied from.

Also mirrored the path-based initialiser's identifier shape —
.appending("bundle\(index)").appending("action0") — instead of the
unrelated run-\(index), so the goldens pin an identifier set a real
report could actually produce. This does change the goldens: every
derived id/toggle/activities hash shifts with the path string. Regenerated
via XCHR_UPDATE_SNAPSHOTS=1 and diffed to confirm every changed line is
only a 32-hex-char identifier, nothing else.

* Exclude committed Snapshots goldens from the test target's resources

swift build --build-tests warned "found 2 file(s) which are unhandled"
for Tests/XCTestHTMLReportTests/Snapshots/*.html once those goldens
existed: SwiftPM saw them under the target's source directory but they
are read directly by path (SnapshotSupport.swift), not vended as
Bundle.module resources. exclude: ["Snapshots"] tells SwiftPM to leave
the directory alone.

* Regenerate goldens against PR #459's icon/structure refresh

Rebased onto origin/main (f442e8e), which merged #459 mid-execution of
this branch's plan: an icon refresh adding status-glyph and icon tokens
(SVG masks replacing base64 PNGs), a responsive @media (max-width: 700px)
breakpoint, and type-derived attachment labels. TemplateSnapshotTests
correctly caught the drift (Snapshot index/index-inline changed).

Refreshed with XCHR_UPDATE_SNAPSHOTS=1 swift test --filter
TemplateSnapshotTests (which itself fails on purpose per the FIX-2
change), then re-ran clean and read both goldens in full before
committing: well-formed, properly closed, the hostile-filename markup
this branch's expected-failure regression test depends on is still
present and unescaped.

---------

Co-authored-by: Claude Opus 5 (1M context) <[email protected]>

* Make the tests tree read like Xcode's outline (refs #439)

Second of three serial PRs implementing Option A. A1 gave the report a
summary header; this one restyles everything below it except the filter
pills, which are A3's.

Every row in the tree — suite, test case, iteration, activity, attachment
— becomes one flex line: disclosure triangle, status badge, name, and the
duration in a right-hand column of its own. What that replaces is a pair
of floats clearing a fixed 52px of left padding on every `<p>` whether or
not the row had a badge to put there, which is why the duration could
only ever be more text after the name.

The status glyph becomes Xcode's rounded badge instead of #459's diamond.
The same six shapes survive — that was the property #459 bought, that
status is never colour alone and no state draws a blank cell — and suite
rows join them, which #459 could not do while the badge was a float and
a heading meant reworking the gutter. The glyph stays a knock-out rather
than the mockup's white tick: a hole's contrast against its fill is by
construction the status token's contrast against the row, which #439
already sized to clear 3:1 in both themes, where white on the mockup's
green is 3.13:1.

Nesting is finally visible. Depth is applied to the child container and
never written into the markup as a number: the legacy backend interposes
two wrapper levels the modern one does not, so a depth attribute would
differ between the two renders in every row of the tree, and the
`wrapperGroups` mask unwraps the element and would leave the numbers
behind. `differential-allowlist.json` is untouched.

An expanded test gets the mockup's timeline treatment minus the one part
4.0 has no data for: the panel is inset and its gutter is ruled, and
there are no per-activity elapsed offsets, because `ParsedActivity` has
carried no timestamps since the port and inventing them would be fiction.

Three things found while shooting this and fixed here:

- Below 700px the test list had no `min-height: 0`, so it grew to hold
  every row instead of scrolling inside its share. `body` sets
  `overflow: hidden`, so on a long run the last test in the report could
  not be brought on screen at all. Pre-existing, and worse since A1 spent
  height above the tree.
- The scrolling list was never keyboard-reachable — axe's
  `scrollable-region-focusable`, serious. The gate stayed green only
  because the synthetic fixture fell seven pixels short of overflowing.
- On a selected row the status badge was a 1.36:1 stain on the accent.
  It now takes the selection's own text colour, at 5.71:1.

The Logs tab reclaims the summary band, which describes a test run and
says nothing about a log.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>

* Make the row bleed actually paint, and the axe gate actually bite (refs #439)

Six review findings on #483. None was a blocker; all six are addressed here.

The full-width row bleed was inert. `box-shadow: -100vw 0 0 <colour>` is the
border box translated whole, so the offset that clears the indentation also
drags the box's right edge that far left: at -100vw the entire shadow landed
at x <= 0, outside the viewport and outside the scroll container clipping it,
and painted nothing. Rows hovered and selected from the indent rightwards,
which is the opposite of what deviation 13 claimed. Shipped rather than
deleted, because the mockup is unambiguous — its failure tint and its
expanded-test band both run to the card's edge, under the disclosure column
rather than starting after it.

Replaced with a strip painted by `::before` and anchored `right: 100%`, so it
begins where the row begins and runs left for as far as it is told, with no
arithmetic that a deep enough tree or a narrow enough pane can outrun.
`background-color: inherit` means hover, selection and a suite heading's own
ground each reach the gutter by the same declaration that paints the row.
Pixel-verified at 1440 and 375, both themes, hover and selection, on the
synthetic fixture and on a real 3-deep render: every gutter pixel now matches
the row's computed background, and reverting to the shadow turns all sixteen
readings back to bare page colour. Nothing widens: leftward overflow is
unreachable in a left-to-right scroll container, and the 375px probe holds.

The axe gate was worse than "live by accident". `scrollable-region-focusable`
analyses a region only if it overflows, and this fixture's layout does not
settle on `load`: four `img.screenshot-tail` in the tree are `loading="lazy"`
and point into a `.xcresult` that is not there, and a deferred image box is
2px until its load is attempted and 20px once the broken-image placeholder
replaces it. So the tree measured 373px or 426px from the same file — 0px of
overflow or 53px — and under a parallel run it was the wrong one about a fifth
of the time, with axe analysing a tree that had no scrollable region at all.
`a11y.spec.ts` now settles the images and then asserts the overflow. Both
halves are needed: waiting alone leaves the seven-pixel blindness, asserting
alone turns a real race into a flaky test. Mutation-checked both ways —
stripping the `tabindex` reddens the gate, and giving the pane room to fit
fails the precondition with the measurement in the message.

The `attachmentDisplayNames` masker is narrowed on both counts. `(?:left )?`
is gone: the masker only ever sees two renders of the same build, so an anchor
matching a pre-A2 report bought a cross-revision property nothing consumes.
The replacement is anchored on the `row-name` wrapper and takes only the text
inside it — the entry declares that display *names* diverge, and the wrapper
markup was not part of that claim. Same nine matches as before on both
goldens, but the wrapper survives into the compared text: 9 dropped before, 0
now. Reverting the anchor still turns `testMaskedRendersAreIdenticalAcrossBackends`
red, so the edit remains necessary rather than a laundering of the differential.

Two comments that shipped inside every generated report were false. The dark
theme's said the activities panel is darker than the page and that this
inverts the light theme; it is lighter here and darker there, which is one
step off the page in whichever direction the theme has. A1's said nothing
below the header was restyled — A2 restyled the tree.

153 tests / 3 skipped / 0 failures on both reader legs, DifferentialTests 7/7
on both, visual 16/16 across twenty consecutive runs, swiftformat clean,
swiftlint 35 violations 0 serious.

---------

Co-authored-by: Claude Opus 5 (1M context) <[email protected]>

…ixes #460) (#486)

* Give every status a filter, and the log something to filter it with (fixes #460)

The last of #439's redesign PRs. A1 gave the report a summary header, A2 gave
the tree Xcode's outline, A3a gave each view its own surface and reserved a
slot in each toolbar. This fills the slots.

## The expected-failure bucket (#460)

The model has named `.expectedFailure` since #443 and A1's tally has counted
it in a bucket of its own since the header landed. The filter row was the last
reading of a run that still had it in no bucket at all: five functions, each
naming the four row classes it shows or hides, and an expected failure carries
none of them. So "Passed" left one on screen — a reader asking for the tests
that passed was shown one that did not — and "All" could not put it back,
because "All" only ever set `display: block` on those same four. The group
pass then read the row as hidden, so a suite of nothing but expected failures
vanished from the tree the moment the reader touched any filter, "All"
included.

**Decision: they leave `unknown` entirely, and nothing in the header moves.**
That is the whole point — A1 already put them where they belong, and the
coordination this needed was to make the toolbar agree rather than to move a
count. `CoreTests` has carried the disagreement as a comment since A1 ("the two
readings disagree until A3 rebuilds the filters"); it now asserts the partition
instead.

**The pills are the legend, made operable.** Both are rendered from the run's
`Tally`: same buckets, same order, same drop-the-empty-ones rule. A leading
"All", then one pill per outcome the run produced. That is what closes the
class of defect rather than the instance — `unknown` had exactly the same gap
and no issue filed against it, and it is filtered now for the same reason
`expectedFailure` is: a status gets a pill *because* the run produced it.

Three consequences worth stating, since each was a filter that did not finish:

- **A suite goes when its last visible row does.** The pass this replaces
  bailed out on any group holding a sub-group, so the legacy backend's two
  wrapper levels — "Selected tests" and "<target>.xctest" — survived every
  filter. Two selected rows sat under three empty headings. Deciding
  deepest-first covers both cases with one rule.
- **A filtered-out test takes its screenshot with it.** `.screenshot-tail` is
  emitted *between* rows rather than inside one (A2), so it was outside
  everything the filters touched.
- **A childless suite is a row.** `Run.allTests` counts one as a leaf — the
  shape a crashed target leaves behind, which `TruncationFaultTests` is built
  from — so the pills count it and now filter it.

## Tests and runs

Xcode's toolbar states 21 tests and 23 runs on `TestResults.xcresult`; ours
knew only tests. The difference is `parameterizedAddition(value:)`, which ran
once per argument set.

Neither `iterations` nor `arguments` could carry that: both readers
deliberately collapse argument executions into one iteration (that is what
makes the two backends agree on the rows), and only the modern format names
the argument values. The *count* is in both bundles — legacy has one sibling
metadata entry per execution, modern one `Arguments` child — and legacy was
throwing it away in `mergingArgumentExecutions`. `ParsedTestCase` gains
`executionCount`, so this converges the readers rather than reading anything
new, and `DifferentialTests.testExecutionCountsAgreeAcrossBackends` holds them
converged, with a non-vacuity check because equality is free if nothing ever
ran twice.

The toolbar reads `23 executions`, not "23 runs": this report already spends
the word "run" on a destination, which the picker labels `Run 1`, `Run 2`.
It is `aria-live`, because a filter changes it. Each row that accounts for a
difference says so — `3 arguments`, the option-A mockup's own tag — and only
the count is stated, never the values, which one backend cannot see.

No per-run rows in the tree: counts and filter semantics only.

## A name filter, in both views

Xcode puts a Filter field at the trailing end of both toolbars. So does this,
in the slot A3a reserved. On Tests it is a name-substring filter over the tree
that *composes* with the pills — "Failed" and "one" together mean the failing
tests whose names contain "one". On Logs it filters the log's lines.

**The log moves into the page to make that possible.** It was an
`<iframe src>` pointing at a `file://` sibling or a `data:` URI — a foreign
origin either way — and two things followed that the report shipped: nothing
in the page could filter, search or scroll it, which is why A3a's toolbar
carried an inert "All Messages" label where a control belongs; and it could
not see the token layer, so in dark mode the Logs view was a white slab with
black text, the same class of defect as the base64 status PNGs #459 replaced.
`logs-1440-dark.png` in the A3a evidence is that slab; the one here is the
same view themed.

A single `<pre>` rather than an element per line: a filter that rebuilds one
text node is a string join, where a six-figure log would otherwise be a
six-figure DOM. The `.log` export is untouched — it is the artifact #480 fixed
and `DifferentialLogTests` compares — and inline mode gets *smaller*, since
escaped text costs less than the same bytes base64'd into a URI.

## Substitution order, closed rather than ordered

`Run` fills its two templates from two ordered lists instead of one
dictionary. `HTML.html` reduces over a dictionary, so it fills placeholders in
hash order and fills the ones an earlier replacement *inserted* as readily as
the ones the template author wrote — the hazard the A3a review found in the
picker. Two per-view templates make it closable: each list holds only what its
own template needs, so a test named `[[LOG_TEXT]]` is not merely filled late
but unfillable, and a log line reading `[[TEST_SUMMARIES]]` likewise. Both
directions pinned in `PlaceholderOrderTests`.

## Verification

- `swift test` — 193 tests, 0 failures, 3 skipped, on both legs (default/auto
  and `XCHR_RESULT_READER=modern`).
- `DifferentialTests` green on both legs; the allow-list is untouched.
- `visual` — 48 Playwright tests, 0 failures: six axe states (two new — the
  filtered tree and the filtered log), contrast over both themes, both
  fixtures and now both *views*, the filter behaviour, and 375px.
- Masked duration shapes untouched.
- `swiftformat --lint` clean; no new SwiftLint warnings.

Refs #439.

* Match suite names in the tree filter too

A filter over a tree that only ever reads its leaves is one a reader finds out
about the hard way: typing the name of a suite they can see emptied the pane.
Matching an ancestor keeps that suite and the tests inside it, which is what
the same query does in Xcode's outline.

The status filter stays a leaf question. A suite's own status is folded from
its children, so filtering on it would put rows of every outcome under a
heading claiming one.

Gated with its own precondition: the test asserts that no row carries the
suite's name itself, or it would be measuring substring matching rather than
ancestry.

Refs #439.

* Put the log's monospace stack in the token layer

The one literal A3b left outside it. The sheet has had zero hardcoded font
stacks since #455 gave it a token layer, and the log body had no business
being the exception.

Refs #439.

* Carry every tail screenshot with its row, not just the nearest

Review finding, verified before fixing. `TestScreenshotFlow` emits a test's
*last three* screenshots (`suffix(tailCount)`), so a test with several is
preceded by several — and the filter walked back exactly one sibling, leaving
the outer ones on screen with no row to belong to.

The synthetic fixture already contains such a row (`testFails()`, whose
standard activities and failure activity each carry a screenshot), so the gate
was passing on a one-tail row while the two-tail one went unchecked. It now
counts every tail rather than the first, and asserts the fixture actually holds
a run of more than one — mutation-tested against the one-sibling version, which
it fails.

Refs #439.

* Keep the executions count level with the rows on screen

Review finding, reproduced before fixing. Filter the real two-bundle report to
`Passed` and the toolbar reads `14 executions`; jump to a failing test from the
digest and a thirteenth row appears — 15 executions on screen — while the
toolbar still says 14. `digestJump` cleared `display` on the row and its
ancestors itself and never recomputed, so it walked around the single writer
the file's own contract names ("One writer, so the rendered value and every
recomputation of it are the same sentence"). The element is `aria-live`, so the
notice a screen-reader reader gets when a row arrives was silence.

The count is now taken off the rows rather than accumulated while the filter
decides them: `countExecutionsOnScreen` sums the visible rows' `data-runs` and
writes through `setCount`, and both the filter and the jump call it. Anything
that changes what the pane holds can restate the figure the same way.

The gate is the reviewer's scenario exactly — `Passed`, then the digest jump —
asserting the toolbar equals the executions actually visible, summed from the
rows, with a precondition that the jump really did reveal one. It fails on the
old code (`4 executions` where 5 are showing) and holds on the new. The goldens
carry only this script change.

Refs #439.

* Say only what the fixtures show about the combined shape

Two documentation nits from the review of #486.

The cross-reference named `testExecutionCountsMatchAcrossBackends`; the test is
`testExecutionCountsAgreeAcrossBackends`. A stale name in a repo that otherwise
keeps them exact is a reader sent looking for a test that does not exist.

And the note on a test that is both parameterized and repeated asserted more
than anyone here can know: "legacy counts the product, modern the larger of the
two". No fixture exercises that shape, which is the whole reason it is written
down — and modern's answer in particular turns on where the `Repetition` nodes
sit, `R` if they nest under `Arguments` rather than `max(R, A)`. The note now
says the shape is unmeasured and names the gate that would catch it, which is
what the reasoning behind the field actually supports.

Refs #439.