Score and tune layout settings against the benchmark corpus

[matt-edmondson]

Follows #378. The bench harness could measure one configuration but not compare two, so picking a default still came down to reading a table and forming an opinion. This adds the missing half — and, more usefully than the search itself, the statistics that say which of its answers are real.

What's here

LayoutScore — one number per configuration. Eight normalised penalty terms, weighted so overlaps dominate, then hidden links and unreadable starts. It is a judgement call written down rather than a fact, and the remarks say so and say where to argue with it.

LayoutTuner — coordinate descent. Sweeps one setting across explicit candidates with the rest held, keeps the best, repeats until a round finds nothing. Every step is one setting, one sweep and one reason, which is what makes a tuned default arguable instead of merely asserted. Candidates are scored in parallel into their own slots, so a run is several times faster and still deterministic.

GraphCorpus.TwoClasses — a second real document, 34 nodes, and the first graph in the corpus with two roots. Counter is a single class, so all of its edges are short. Two classes with Transfer calling into Account.Withdraw/Deposit produce long edges crossing between the subtrees, which is the case that makes a link disappear behind a body parked in the middle.

The part that changed the method

The corpus score is a random variable, and it is noisier than the gains a descent chases. Scored eight times over independent families of starting arrangements, the unchanged defaults vary by:

starts	sd of corpus score
12	0.317
24	0.096
48	0.032

Two descents run before this was measured — at 8 and 12 starts, accepting every improvement — converged on values that disagreed on six of fifteen settings and scored within 0.01 of each other. Both were fitting the arrangements they happened to be handed.

So two additions exist purely to prevent that:

• BenchOptions.StartOffset selects an independent family of arrangements, which is what makes a holdout check possible at all: a value chosen on one family has to also win on one it was not chosen on.
• LayoutTuner.DefaultMinimumGain requires a change to beat the incumbent by 0.1, roughly three times the deviation at 48 starts, before it is kept.

Not in this PR

No default in LayoutSettings or PhysicsSettings is changed here. The tuning run at 48 starts is what decides that, and it belongs in its own commit with its evidence next to it.

Testing

LayoutTunerTests covers the ways a tuner goes wrong quietly: a candidate list that never offers the value a setting already has (so a pass cannot decline to move), a writer that reads back a different setting than it names, a score that is not reproducible, and a descent that ignores its own gain floor. 11 tests, all passing, plus the existing suite.

🤖 Generated with Claude Code

https://claude.ai/code/session_018b2bn5CKSzpjRV4nxv3c3y

---

Generated by Claude Code

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud