Feedback: evolve the page layout to be independent of supabase/evals

[leggetter]

From Gareth, on the first draft:

Rather than saying 'we copied it', I'd probably reference them saying 'Inspired by
Supabase Evals we…'. Especially if we evolve the layout to be more independent -
which I think we should do.

Three design directions were attached to the thread: a public-record ledger, an
evidence-first transcript view, and a skills A/B delta report. I have not seen the
images, so this issue records the direction rather than assessing them.

Attribution wording is already changed, to "based on" rather than "copied". That
was chosen over "inspired by" deliberately: the tree was imported at a commit and
modified, which NOTICE and CHANGES.md state in full for Apache-2.0 purposes.
"Inspired by" would understate it, and on a page whose argument is that its numbers
are checkable, the first checkable claim should be accurate. "Based on" reads better
than "copied" and stays true.

On layout independence: the current page is a close port of upstream's information
architecture, which was the right way to ship a first draft and is not a reason to
keep it. Two of the three directions Gareth described map onto work already open:

• Listing resulting fixes and improvements, to show the AX work is active, is
  LOOPS.md plus the release changelog (Release process: package a run, its closed issues and its measured delta #13). The content exists; nothing surfaces it
  on the page.
• A skills A/B report is Feedback: show skills and no-skills together, and link where to get the skills #17.

Worth noting the first loop closed as a negative result: the CLI fix bought no
measurable improvement because the failures were variance. A page that lists
improvements needs to handle that honestly, or it becomes a marketing surface that
only reports wins, which is the opposite of the project's stated goal.

Done when there is an agreed design direction, informed by what the data can
actually support.

[leggetter]

Direction agreed: design B, the evidence-first / transcript layout. Iterating later on team feedback.

Why B over the other two, having now seen all three:

• B fits what we have and what we are building. Its Findings then Changelog structure, with FIXED · CLI 1.4.2 against each finding, is the release process in Release process: package a run, its closed issues and its measured delta #13 and LOOPS.md rendered as a page. The content already exists; nothing surfaces it today.
• C (The Delta) is built on a result we do not have. It shows skills adding +27, +20 and +25 points. Measured, our deltas are +1, 0 and -3, and after Loop 1 even those are suspect (Scenarios flake, and single-attempt runs publish the flake as a result #14). The layout's whole structure assumes a large positive skills effect, so building it now would mean shipping a page that argues against itself.
• A (The Public Record) is closest to our real differentiator, that every number links to its run. B keeps that and adds the changelog, so it is A's strength plus the part we need.

What B assumes that we do not yet have, worth naming so the build does not quietly invent it:

In the mockup	Reality
312 runs kept	~5 runs, since 13 August
19 findings filed	roughly 5
14 fixes shipped	0 with a measured improvement. Loop 1 closed as a negative result
Partial credit state	scoring is binary
Six weeks of trend	one week

The three header counters are now answerable:

• findings filed: issues labelled finding, open and closed
• fixes shipped: finding issues closed by a release (Release process: package a run, its closed issues and its measured delta #13). Note this counts fixes shipped, not improvements proven, and the page should not imply otherwise
• runs kept: needed an export change, done in dc2f297. Rows now carry runId, and the snapshot counts distinct runs. It reads 0 today because no run has executed since the field landed, which is true rather than inferred

Partial credit is a scoring change rather than a design one, and should not be added just to fill a legend.

[leggetter]

Pivots stay. Agent, Eval, Journey and Product are all kept, rather than collapsing to design B's single fixed grid. B contributes its evidence-first framing and the Findings/Changelog section; the four-way group-by control stays as it is.

That also changes the calculus on the Product pivot. It is currently 14 Event Gateway scenarios against 1 Outpost (#3), which made it the weakest axis and the easiest to drop. Keeping it means the coverage gap has to be closed rather than designed around, and it now extends to Console, which has no scenarios at all.