Bump the image's pinned uv to 0.12.23

[EiffL]

The container smoke tests have failed on every branch since 2026-10-02 (#245, fix/sandbox-elf-interpreter, smoke-findings) with:

error: No download found for request: cpython-3.13.16-linux-x86_64-gnu
Error: building at STEP "RUN UV_PYTHON_INSTALL_DIR=/opt/python uv python install 3.13.16 …"

Why

lc init pins .python-version to the exact interpreter running lc. The image build then installs that pin with the uv copied from UV_IMAGE. setup-uv gives CI the newest patch of each Python line, which since 2026-10-02 means 3.11.17 and 3.13.16. The pinned uv 0.12.5 predates both. The 3.12 job only passed because 3.12.14 is still known; 3.12.15 is out and would have broken it next.

Change

UV_IMAGE → ghcr.io/astral-sh/uv:0.12.23@sha256:61d393e44e249f2e4b526b6c7ddcecce245946826e608e11c93ad4f5bba55b21.

• Digest: this is the manifest-list digest, covering linux/amd64 and linux/arm64. I read it from ghcr's registry API and confirmed it by hashing the index body. The same method reproduces the old 0.12.5 pin (e85be844…) exactly.
• Version: 0.12.22 is the first release that knows the new patches; 0.12.23 is the current one.

Effect on projects

This is an engine constant whose bump is meant to be visible (see the layer-6 invariants in CLAUDE.md):

• Containerized projects get a new image tag, so lc build rebuilds, and a new env_version. Existing outputs read behind; nothing is remade.
• Direct-mode projects are unaffected.

Verification

• Pinned images, run by digest: 0.12.5 lists none of cpython 3.11.17, 3.12.15 or 3.13.16; 0.12.23 lists all three.
• tests/test_container_smoke.py under Python 3.13.16 (podman): the old pin fails with CI's exact error and image tag (lc-env-712be96723c9091c). The new pin passes all 6, including materialize in the image and datalad rerun on a clone that starts with no file contents.
• Under Python 3.11.17: 6 passed.
• test_image.py, test_container.py, test_identity.py: 96 passed.

Note

This will happen again whenever a Python patch release is newer than the pinned uv: CI moves to the newest patch, and the image's uv does not. This PR only restores CI; a structural fix is a separate decision.

🤖 Generated with Claude Code

[EiffL]

lgtm

[github-actions]

✅ Eval

Metric	Value
Outputs check	success
Agent run	success
Turns	8
Tool calls	6
Cost	$0.14
Agent wall time	0m52s
Model	claude-sonnet-5-5

lc status

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

  · current  baseline/best_fit        a28ab00
  · current  baseline/hubble_diagram  a28ab00
  · current  baseline/residuals       a28ab00

3 current

Confusion & pain points (Claude analysis)

Confusion & pain points

• The run was essentially clean. There were no errored tool calls, and the agent built, validated, materialized and re-checked the project in 8 turns. The friction below is minor.

• The agent had to edit a skeleton spec with a Python string-replace. The agent wrote python - <<E and used s.replace(...) to patch format:, inputs:, decisions: and the recipe into astra.yaml. That only works if the skeleton's text matches exactly. It left no check that the replacements applied. Only the later astra validate pass shows they did.

  • Cause: the eval seed spec is incomplete, and there is no structured way to fill it in.
  • Fix: ship a fuller seed spec, or give astra a spec-edit helper.

• The agent ran astra through uvx astra-tools@0.2.18 instead of a bare astra. It pinned a version by hand, which suggests the astra binary was not on PATH in the eval project. It did not say why.

  • Cause: the harness does not provide astra, or the skill does not say how to invoke it.
  • Fix: put astra on PATH in the eval environment, or have the skill document the exact invocation and version.

• The agent guessed what the fifth data column meant, and the guess probably biases the results. The Union2.1 file has no header for the fifth column. The agent treated it as a systematic error, which probably explains the reduced χ² of 0.37. It flagged this honestly in its summary but could not check it.

  • Cause: the data input has no documentation or column schema. The agent had no way to look up the format and had to infer it from the values.
  • Fix: include a README or column description with the dataset. Alternatively, let astra.yaml carry a column schema for inputs.

• The agent picked a license on its own to turn on crate maintenance. It set license = "CC-BY-4.0" in pyproject.toml without being asked. The agent said so, but it was asserting terms over someone else's data.

  • Cause: publication intent is derived from the presence of [project].license. The task never said whether to publish, so the agent chose by default.
  • Fix: make the task prompt say whether a crate is wanted, or have the eval accept a run with no license.

Full trace: agent-trace artifact on this run.