Publish the learned-heuristic results: a Research view in the workbench

[guilyx]

jupyddl.learn shipped in 2.3.0 with its results living only in .docs/ and
a video. The published site — the thing anyone actually reads — said nothing
about the largest addition in the release. This adds a Research view to the
workbench carrying the measured run, and fixes a defect that rendering it
exposed.

The Research view

Built from promo/rl-data.json, the cache the RL video renders from, so the
page and the video quote one measured run and cannot drift apart.
tools/build_web.py distils it into web/dist/research.json; when that cache
is absent the builder emits {} and the view says so rather than showing
numbers from nowhere.

What it reports, all measured, blocksworld trained on 3–6 blocks and judged on
9–13 under GBFS at a 30000-expansion budget:

heuristic	coverage	expanded	seconds	cost
learned	1.00	137	0.036	48.2
hff	1.00	518	0.534	51.8
goalcount	1.00	2483	0.154	51.0
blind	0.00	—	—	—

It deliberately does not stop at that table:

• The per-instance spread, because the held-out set has a heavy tail. Nine
  of ten instances sit between 58 and 227; the tenth is worth thousands, and
  imitation alone could not solve it at all. The mean is close to a report of
  that one instance, so the view shows all ten.
• Where it loses. On logistics it is beaten by hff roughly 6× — 204
  expansions against 35 — and the reason is exact, not mysterious: that domain
  has two predicates, so the feature vector is 8 numbers and can say how many
  packages are somewhere but not which package is where. Counting is blind to
  topology.
• What we got wrong. Three corrections, kept on the page rather than in a
  footnote: the objective is flat where search is already good; an improvement
  was credited to a validation split when the perturbation scale changed in the
  same edit and was doing all of it; and the mean was doing the lying.

The defect it exposed

<main> was hidden until the worker reported ready, so every page of prose,
the requirement matrix and this new view sat behind a full-screen spinner
waiting for a 10 MB WebAssembly runtime none of them use.

The shell now renders immediately from the committed bundle — the menus and
the support matrix come from capabilities.json, which carries the same
registries the runtime reports — the boot notice is a status bar rather than a
splash screen, and only the controls that actually run a planner are gated,
now on state.ready. onReady still overwrites everything from the live
interpreter, which stays the authority.

Verified in Chromium: before the runtime lands, 14 planners, 10 heuristics, 21
requirement rows and the full Research view render with no console errors and
the Run button reads "Loading Python…" and is disabled; after it lands the
button enables, the footer reads jupyddl 2.3.0 · CPython 3.14.2 · WebAssembly, and a search returns a 17-step plan.

Tests

• capabilities.json is pinned to the live registries. It is now rendered
  before Python loads, so a stale bundle no longer merely lags — it states
  something untrue to every visitor for the seconds before the runtime
  corrects it.
• research.json is pinned to promo/rl-data.json.
• A regression test that the app shell is not hidden and the gating is on
  state.ready, since that is how this broke once.
• test_builder_is_reproducible now covers capabilities.json and
  research.json too.

418 passed, 1 skipped; flake8 and black clean.

Also carried

19204ce, unrelated and previously unmerged: the GitHub Release job no longer
requires the PyPI upload to have succeeded. A release records that a version
was cut from a verified commit; PyPI is a downstream channel that can fail for
reasons the code has nothing to do with, and losing the tag and the release to
that would mean no record of the version and a full re-run to get one. build
succeeding is the gate that matters — that is where every check lives.

---

Generated by Claude Code

[cursor]

Bugbot is not enabled for your account, so this pull request was not reviewed.

Enable Bugbot in the Cursor dashboard to get automatic reviews on future PRs.

[guilyx]

Two additions since the description was written.

CodeFactor. This PR first came back "1 issue found." The report is 403 without an account, so rather than guess at it again I looked at what my own diff had added that was worth fixing regardless: renderResearch had grown to 107 lines covering four unrelated blocks, and the Run button label used a nested ternary. Splitting the first into researchHeadline / researchTable / researchSpread / researchNarrative (a 17-line dispatcher) and replacing the second with an if/else took the status to "No issues found." — green for the first time on this repository. Re-checked in Chromium: the view renders identically before and after.

renovate.json. Carried here because it is the other half of closing #152. python-version in build.yml, pages.yml and release.yml is not a dependency to keep current — it picks the interpreter that builds the wheel, bundles web/dist and cuts the release, and tests already covers 3.9–3.14 on every push. Renovate marks those PRs immortal, so the rule is what actually stops it recurring; the reasoning is in the rule's description. Also moves the deprecated config:base to config:recommended.

Merged from main after #153, #154, #155, #156 and #159 landed. The artifact-action bump and this branch's release changes touch neighbouring lines in release.yml; they merged cleanly and tag_name / target_commitish survive alongside download-artifact@v8.

---

Generated by Claude Code