Let compute offers name their provider instead of a connection

[EiffL]

This simplifies compute.yaml: no connections section, no namespace UUID, no context, no version, and no local settings block. Each offer names its provider directly, and the only local key left is allow_local.

Before:

version: 1
local: {resources: {cpus: 4, memory: 8}}
connections:
  perlmutter:
    namespace: 9d0c0fc5-9be8-407a-a3ec-f17c4110b162
    provider: slurm
    context: perlmutter
offers:
  - name: batch
    connection: perlmutter
    resources: {cpus: 256, memory: 480}
    max_nodes: 16
    time: {default: 1h, max: 12h}
    config: {account: myproject, qos: regular, constraint: cpu}

After:

offers:
  - name: batch
    provider: slurm
    resources: {cpus: 256, memory: 480}
    max_nodes: 16
    time: {default: 1h, max: 12h}
    config: {account: myproject, qos: regular, constraint: cpu}
  - name: local            # optional: replaces the built-in local offer
    provider: local
    resources: {cpus: 4, memory: 8}
    max_nodes: 1
    time: {idle: 30m}

What changed

Catalog shape

• One native authority per provider. lc runs inside one Slurm environment, so context (which became --clusters) is gone. local is this machine; slurm is the cluster the Slurm client reaches by default. That left connections as pure indirection.
• Worker launch settings (python, scratch_root, cwd, interface, task_slots_per_node) live in each offer's config. connection_root is the one top-level key, because discovery and connecting read it outside planning.
• allow_local replaces local: {enabled, resources, time}. An explicit local offer already replaced the built-in one, so local.resources/local.time were a second way to say the same thing, plus a rule forbidding both together. To change the local budget or time limits, write a local offer. allow_local: false (and the NERSC login-node guard, which is unchanged) blocks local launch and execution; local clusters stay inspectable and stoppable.

Checked when the catalog loads

• connection_root is expanded and resolved once. A relative, .. or unexpandable root (such as ~nosuchuser/…) is now a catalog error naming the field. Before, it crashed with a traceback or showed up as a discovery failure on every command. Providers take the resolved root.
• An offer's provider must be one lc supports (local, slurm). Before, a typo such as slurmm loaded fine and then made every discovery incomplete, which blocked every launch, local ones included.

Local GPUs by default

• On Linux, the built-in local offer takes its GPUs from CUDA_VISIBLE_DEVICES, counted the way CUDA reads the mask (it stops at the first invalid entry, so -1 means none). Nothing probes hardware; without a mask, the offer is CPU-only.
• lc compute launch without --gpus takes a local offer whole, GPUs included. --gpus 0 takes it without them. A remote request (--cpus/--memory) is still CPU-only unless --gpus is given.
• An explicit local GPU offer is only used when the mask lists at least as many devices as it declares. This replaces the old check that the mask was merely nonempty.

Slurm and status

• Each submission's log and per-attempt TLS files live under <connection_root>/slurm/<token>/, created before submitting. Connecting from a catalog with a different connection_root now says the job was launched under another root, instead of "scheduler has not started yet". Native inspection and down work from any catalog; connecting needs the launching catalog's root, as for local.
• A timed-out lc compute status --wait includes the last connection error.
• Each command builds one provider per name, so Slurm runs id -u once. Local and Slurm share one check for offer setting strings, and a non-numeric sbatch reply is quoted in the error.

Unversioned compute formats

• Allocations are ephemeral, so compute formats carry no version: no catalog version, no version element in cluster IDs, no schema_version in compute JSON output, and Slurm labels are JobName=lc-<name> and Comment=lightcone:kind=dask:token=<hex>. A format change only strands allocations that end on their own. Manifests keep their schema_version, since they are committed.
• One cost: a Slurm job of your own named lc-… without lc's comment makes discovery incomplete, naming the job, until it is renamed or ends. Full cluster IDs keep working.

Also

• Cluster IDs carry the provider instead of the namespace, so a full ID routes without a catalog lookup.
• launch --dry-run --json reports provider, and status --json keys its errors by provider.
• Fixes a latent bug: Slurm discovery never filtered on the namespace, so two catalogs with different UUIDs gave one job two IDs.

Breaking (pre-release, no migration)

• Catalogs with version, connections or local keys fail validation, and the error names the key.
• Old cluster IDs no longer decode, Slurm job names and comments changed, and private files moved. Stop running clusters before upgrading.

Docs

Not up to date with the follow-up commits. docs/user/cluster.md, docs/cli/compute.md, docs/api/compute.md and docs/user/troubleshooting.md still show version: 1, local.enabled/local.resources, explicit-only local GPUs, schema_version, the lc-v1- labels and submissions/<token>/ paths. Their catalog examples no longer validate. The eval prompt and CLAUDE.md (layer-7 invariants and Recorded decisions) are updated.

Tests

uv run pytest: 1158 passed before the merge from main; test_image.py and test_compute.py were re-run after it (220 passed). ruff and mypy --strict are clean. Nothing was submitted at NERSC.

• New tests cover catalog errors for bad roots and a misspelled provider, a resolved root handed to one provider per command, mask-derived local GPUs (including -1, UUIDs and invalid entries), the local shortcut with and without --gpus 0, connecting from another root, the last connection error on a status --wait timeout, and allow_local validation.
• Tests for things that no longer exist are removed: the reserved connection name, namespace uniqueness, --clusters scoping, the catalog version, and the local settings block.

🤖 Generated with Claude Code

[github-actions]

✅ Eval

Metric	Value
Outputs check	success
Agent run	success
Turns	8
Tool calls	6
Cost	$0.12
Agent wall time	0m42s
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        8961049
  · current  baseline/hubble_diagram  8961049
  · current  baseline/residuals       8961049

3 current

Confusion & pain points (Claude analysis)

Confusion & pain points

• Wasted launch probe. The agent ran lc compute launch --wait 2>&1 | tail -3 while inspecting the data. The digest does not show the output, so I can't say whether it succeeded. Later it ran lc materialize local, so it relied on an allocation named local that came from that launch. Piping through tail -3 hid the output that said the name was local. A cluster name the agent has to guess is a gap: lc materialize could print the available cluster name in its refusal. A bare lc compute launch could also say, in its last line, "use lc materialize local".

• No scaffold for the spec edits. The agent patched astra.yaml with a Python script of string replace calls. It added format, inputs, decisions and the recipe commands, and it matched the existing text exactly. This worked only because the spec stubs had a predictable shape. A mismatch would have left the spec unchanged with no error. Validation passed, but the script has no way to confirm each replacement actually applied. Better tooling would be an astra command that edits or fills output fields, or a skill example that shows the required format: and inputs: fields.

• Several steps in one command, with the output truncated. The agent chained uv add, validate, git commit, materialize and --check into a single Bash call and truncated the output with tail. A failure in any middle step would have been hard to attribute. It worked this time. The --check result was visible only in a truncated snippet ("up to date b…").

• Pinned the validator version by hand. The agent ran uvx astra-tools@0.2.18 validate instead of calling an astra CLI directly. That suggests astra was not on PATH or the agent didn't know it was. The environment should provide astra, or the skill should say which invocation to use. The pinned 0.2.18 also looks guessed, with nothing in the trace showing where it came from.

• License and crate setup done by sed. The agent edited pyproject.toml with sed to add license = "CC-BY-4.0". Its first expression, s/^license.*//, blanks any existing license line instead of replacing it. lc init could scaffold a license field, or the docs could say that setting [project].license turns crate maintenance on. The agent evidently knew this, since it mentions ro-crate-metadata.json.

Full trace: agent-trace artifact on this run.