Docs deploy skips pre-releases

[EiffL]

Ahead of tagging v0.5.0rc1: release: published fires for pre-releases too (released is the type that skips them), so publishing an rc from the GitHub UI would have run

mike deploy --push --update-aliases 0.5.0rc1 latest
mike set-default --push latest

— moving the latest alias onto the rc and making docs.lightconeresearch.org serve rc docs as the site default. That contradicts the workflow's own stated rule that the site tracks the released CLI: PyPI hands an rc only to someone who asks for it by name (--pre, or an exact ==0.5.0rc1), so the site must keep serving the last full release.

The fix is one if on the deploy job. github.event.release is null on a workflow_dispatch run, so the manual redeploy path stays unconditional.

pypi-publish.yaml is deliberately untouched. PyPI has no per-upload pre-release flag — it derives one from the PEP 440 version alone. Verified against this branch's build config: a v0.5.0rc1 tag gives hatch-vcs 0.5.0rc1, which pip install lightcone-cli skips without --pre. The GitHub checkbox never enters into it.

Prose updated in the two places that describe the release flow (docs/contributing/setup.md, CLAUDE.md).

🤖 Generated with Claude Code

https://claude.ai/code/session_01AujePdgpiCcNnEJ99ruLFu

[EiffL]

LGTM

[github-actions]

✅ Eval

Metric	Value
Outputs check	success
Agent run	success
Turns	33
Tool calls	31
Cost	$0.99
Agent wall time	3m35s
Model	claude-sonnet-5

lc status

  mode:    direct
  sandbox: landlock (fs: declared, network: allowed)
  crate:   up to date with the outputs

  · current  baseline/best_fit        1d9af1a
  · current  baseline/hubble_diagram  1d9af1a
  · current  baseline/residuals       1d9af1a

3 current

Confusion & pain points (Claude analysis)

Confusion & pain points

• The run was essentially clean — the agent used the astra skill, read the scaffold, wrote scripts, wired the recipe, and materialized successfully with no errored tool calls and no backtracking.
• The agent invoked uvx astra-tools@0.2.13 validate astra.yaml directly rather than using an astra validate CLI entrypoint already on PATH (it had confirmed astra was installed at /home/runner/.local/bin/astra earlier) — a minor inconsistency suggesting the agent wasn't sure whether the installed astra shim and the pinned uvx astra-tools@x.y.z invocation were equivalent, and defaulted to the more verbose/explicit form out of caution rather than any observed failure.
• Before trusting lc materialize, the agent manually ran each script standalone against /tmp scratch directories (three separate fit-parameter combinations, then both plot scripts) to sanity-check outputs and view the PNGs — a reasonable validation step, but one that duplicates what lc run (the probe verb) exists to do in-sandbox; the agent never tried lc run at all, going straight from ad-hoc uv run python scripts/... calls to a full lc materialize, suggesting the probe verb's purpose wasn't obviously discoverable from lc --help or memory.
• No RO-Crate/license guidance was surfaced until lc materialize printed the advisory (! no [project].license ... declare one to enable it) — the agent then had to read pyproject.toml, hand-edit in a license, recommit, and re-materialize as a distinct follow-up step. This works but is a two-round-trip discovery; a one-line mention in scaffold docs or lc init output about the license key enabling publication could save the extra materialize cycle.

Full trace: agent-trace artifact on this run.

[EiffL]

LGTM