lightcone-cli 0.2.0__tar.gz → 0.3.0__tar.gz

{lightcone_cli-0.2.0 → lightcone_cli-0.3.0}/.gitignore

@@ -207,7 +207,7 @@ marimo/_lsp/
 __marimo__/
 
 
-dev
+dev/
 eval-results
 
 # UV

{lightcone_cli-0.2.0 → lightcone_cli-0.3.0}/PKG-INFO

@@ -1,16 +1,19 @@
 Metadata-Version: 2.4
 Name: lightcone-cli
-Version: 0.2.0
+Version: 0.3.0
 Summary: Lightcone command-line toolchain
 Author: Lightcone Research
 License: BSD-3-Clause
 License-File: LICENSE
 Requires-Python: >=3.11
-Requires-Dist: astra-tools>=0.2.2
+Requires-Dist: astra-tools>=0.2.5
 Requires-Dist: click>=8.0
-Requires-Dist: dagster-docker>=0.25
-Requires-Dist: dagster-webserver>=1.9
-Requires-Dist: dagster>=1.9
+Requires-Dist: dask>=2024.1
+Requires-Dist: distributed>=2024.1
+Requires-Dist: jinja2>=3.0
 Requires-Dist: langfuse>=2.0
 Requires-Dist: pyyaml>=6.0
 Requires-Dist: rich>=13.0
+Requires-Dist: snakemake-interface-common>=1.14
+Requires-Dist: snakemake-interface-executor-plugins>=9.0
+Requires-Dist: snakemake>=9.0

{lightcone_cli-0.2.0 → lightcone_cli-0.3.0}/claude/lightcone/guides/astra-reference.md

@@ -14,7 +14,8 @@ Fields: `name`, `description`, `version`, `authors`, `tags`, `inputs`, `outputs`
 # Simple analysis -- everything at top level
 version: "1.0"
 name: "My Analysis"
-description: "What this analysis investigates."
+narrative:
+  summary: "What this analysis investigates."
 inputs:
   - id: training_data
     type: data
@@ -43,8 +44,16 @@ decisions:
 outputs:
   - id: accuracy
     type: metric
+    inputs: [training_data]                        # upstream artifacts (Input or sibling Output)
+    decisions: [scaling, use_pca, n_components]    # decisions that parameterize this output
     recipe:
-      command: python scripts/evaluate.py
+      command: >
+        python scripts/evaluate.py
+        --data {inputs.training_data}
+        --scaling {decisions.scaling}
+        --use_pca {decisions.use_pca}
+        --n_components {decisions.n_components}
+        --output {output}
 container: Containerfile
 ```
 
@@ -68,9 +77,9 @@ A decision is a methodological choice where a different defensible option could
 
 ### Parameterization
 
-**Every decision must be parameterized in code** -- never hardcode a decision value. Accept all decisions as CLI args.
+**Every decision must be parameterized in code** -- never hardcode a decision value. Decisions reach the script via the recipe template's `{decisions.<id>}` placeholders (see [Recipe Format](#recipe-format)). The recipe author chooses how to pass them — typically as CLI args (`--scaling {decisions.scaling}` paired with `parser.add_argument("--scaling")` in the script), but env vars or sidecar files work too. There is no magic auto-injection: if a decision isn't referenced in the recipe template, the script never sees it.
 
-**Underscore convention:** IDs use underscores in `astra.yaml` (`prior_range`). lightcone-cli passes `--prior_range wide`. Scripts must match: `parser.add_argument('--prior_range')`, **not** `--prior-range`.
+**Decision provenance contract:** list every decision a script consumes under `Output.decisions: [...]`. Re-running the output with a different option for any listed decision must be expected to change the result. The validator enforces that every `{decisions.<id>}` placeholder appears in `Output.decisions`, and `code_version` (the cache key) hashes only those decisions — so changes to unrelated decisions don't invalidate cached results.
 
 ### Constraints
 
@@ -91,21 +100,44 @@ Convention path: `results/<universe_id>/<output_id>.<ext>` -- no `path` field ne
 
 ## Recipe Format
 
-Inline on outputs. Fields: `command` (required), `inputs`, `container`, `resources`.
+In v0.0.7, **`inputs` and `decisions` live on the Output, not on the Recipe.** The recipe is pure *how*: a `command` template plus its execution context (`container`, `resources`).
 
 ```yaml
 outputs:
   - id: accuracy
     type: metric
+    inputs: [trained_model]                  # upstream artifacts
+    decisions: [scaling, n_components]       # decisions that parameterize this output
     recipe:
-      command: python scripts/evaluate.py
-      inputs: [trained_model]               # Dependency on other output
-      container: ghcr.io/proj/ml:latest     # Overrides analysis-level default
+      command: >
+        python scripts/evaluate.py
+        --model {inputs.trained_model}
+        --scaling {decisions.scaling}
+        --n_components {decisions.n_components}
+        --output {output}
+      container: ghcr.io/proj/ml:latest      # Overrides analysis-level default
       resources: { cpus: 4, memory: "32GB", gpus: 1, time_limit: "2h" }
+      # `gpus` is per-node. Multi-node recipes get nodes × gpus total GPUs.
 ```
 
+`Output.inputs` references resolve to either a sibling Output's directory or an analysis-level Input's source string (e.g. a path or `sklearn.datasets.load_iris`). The runner walks any `from:` aliases in the surrounding scope to find the source.
+
 Set `container:` at analysis level (all recipes inherit); per-recipe `container:` overrides. Pass either a container image name (e.g., `python:3.12-slim`, `ghcr.io/org/img:latest`) or a path to a Containerfile (e.g., `Containerfile`, `containers/Dockerfile`). The runtime figures out whether to pull or build.
 
+### Recipe Command Template
+
+The `command` is a template with these placeholders:
+
+| Placeholder | Substitutes to |
+|---|---|
+| `{output}` | The directory the artifact is written to (e.g. `results/baseline/accuracy/`) |
+| `{inputs.<id>}` | The named upstream input's resolved path or source string. `<id>` must be in `Output.inputs`. |
+| `{inputs}` | Space-joined values of every entry in `Output.inputs` (declaration order). |
+| `{decisions.<id>}` | The active option ID for the named decision in this universe. `<id>` must be in `Output.decisions`. |
+| `{{` / `}}` | Literal `{` / `}` (e.g. `awk '{{print $1}}'`). |
+
+Static constants belong inline in the command (`--max-iter 1000`); only varying values are decisions, only path/source values are inputs. Any other placeholder is rejected by `astra validate` and by the runner.
+
 ### Conditional Outputs
 
 Outputs can have `when` conditions -- the output only exists when the condition is met for a given universe. Uses the same syntax as decision `when` (negation with `~`, lists AND'd).
@@ -242,21 +274,29 @@ analyses:
     path: ./analyses/train_network
 ```
 
-Inside each sub-analysis's own `astra.yaml`, `from:` wires inputs and decisions to the parent or siblings:
+Inside each sub-analysis's own `astra.yaml`, `from:` wires inputs and decisions to the parent or siblings using the **unified `../` path grammar**:
 
 ```yaml
 # analyses/train_network/astra.yaml
 inputs:
   - id: training_data
-    type: data
-    from: build_mocks.mock_catalog       # Sibling output
+    from: ../build_mocks.mock_catalog     # Sibling sub-analysis's output (escape one scope, descend)
 outputs:
   - id: trained_model
     type: data
-    recipe: { command: python src/train.py, resources: { gpus: 1, memory: "32GB" } }
+    inputs: [training_data]
+    decisions: [cosmology_model, noise_model]
+    recipe:
+      command: >
+        python src/train.py
+        --data {inputs.training_data}
+        --cosmology {decisions.cosmology_model}
+        --noise {decisions.noise_model}
+        --output {output}
+      resources: { gpus: 1, memory: "32GB" }
 decisions:
   cosmology_model:
-    from: ../cosmology_model             # Inherit parent decision
+    from: ../cosmology_model              # Inherit parent decision (one scope up)
   noise_model:
     label: "Noise Model"
     default: heteroscedastic
@@ -265,11 +305,19 @@ decisions:
       heteroscedastic: { label: "Heteroscedastic" }
 ```
 
-**Wiring patterns:**
-- **Input `from:`** -- `from: parent_input_id` (parent input) or `from: sibling_id.output_id` (sibling output).
-- **Decision `from: ../parent_id`** -- inherits a parent decision. The sub-analysis uses the parent's value; do not set it in the sub-analysis universe.
-- **Output `from: sub.output`** at root level creates an alias to a sub-analysis output.
-- **`universe:` field** in universe files selects which sub-analysis universe to load: `build_mocks: { universe: baseline }` loads `./analyses/build_mocks/universes/baseline.yaml`.
+**Wiring patterns (v0.0.7 unified `from:` grammar):**
+
+| Where | Form | Meaning |
+|---|---|---|
+| Input | `from: ../id` | An ancestor input |
+| Input | `from: ../../id` | A grandparent input |
+| Input | `from: ../sibling.out_id` | A sibling sub-analysis's output |
+| Output | `from: child.out_id` | Re-export of an own child sub's output (no `../` — outputs only flow *up* via re-export, never reach laterally) |
+| Decision | `from: ../id`, `../../id` | An ancestor decision (downward and lateral references aren't allowed; lift shared decisions to a common ancestor) |
+
+An aliased node carries only `id`, `from`, and (where applicable) `when` — type, description, recipe, etc. are inherited from the source.
+
+The `universe:` field in universe files selects which sub-analysis universe to load: `build_mocks: { universe: baseline }` loads `./analyses/build_mocks/universes/baseline.yaml`. Decisions inherited via `from: ../...` use the ancestor's value automatically; do not set them in the sub-analysis universe file.
 
 ## CLI Reference (astra)
 

lightcone_cli-0.3.0/claude/lightcone/guides/lightcone-cli-reference.md

@@ -0,0 +1,61 @@
+# lightcone-cli Reference
+
+Reference for lightcone-cli execution: CLI commands, development workflow, status interpretation, and failure diagnosis. For `astra.yaml` spec syntax, see `astra-reference.md`.
+
+## CLI Reference
+
+```bash
+lc init [DIR]                            # Scaffold a new ASTRA project
+lc run [OUTPUT] [--universe NAME]        # Materialize outputs
+lc build [--force] [--runtime docker]    # Build container images from specs
+lc status [--universe NAME] [--json]     # Materialization status (text or JSON)
+lc verify [--universe NAME]              # Recompute hashes and walk the provenance chain
+```
+
+The first `lc` invocation auto-creates `~/.lightcone/config.yaml` with defaults; edit it directly to pin a container runtime or set the extraction model.
+
+**Always run via `lc`.** Recipes must execute through `lc run` so that container builds, option resolution, resource limits, and result paths are applied. Treat the underlying execution engine as a black box — never invoke schedulers or container runtimes directly, that will bypass reproducibility guarantees.
+
+## Creating Sub-Analyses
+
+Sub-analyses are scaffolded by hand, since each one is just another `astra.yaml` nested in a directory. To add one:
+
+1. Create `analyses/<name>/` with its own `astra.yaml` (and optionally `scripts/`, `universes/baseline.yaml`, `results/`).
+2. Add a `path:` entry to the parent `astra.yaml` under `analyses:` (e.g. `analyses: { my_sub: { path: ./analyses/my_sub } }`).
+3. Add a `<name>: { universe: baseline }` entry to each existing parent universe file.
+
+Populate the sub-analysis's `astra.yaml` with inputs, outputs, and decisions. Use `from:` references to wire inputs and decisions to the parent or siblings — see `astra-reference.md` under "Composition Mechanics."
+
+## Development Workflow
+
+Three overlapping phases:
+
+1. **Write & Debug** — Run scripts directly (`python scripts/compute.py`) to iterate. Write them recipe-ready from the start: parameterize decisions, write to convention paths, one script per output.
+2. **Integrate** — Add `recipe:` blocks to outputs in `astra.yaml`. Track with `lc status` (`alias` / `missing` / `stale` / `ok`). Set `container:` at analysis level or per-recipe — pass an image name (e.g., `python:3.12-slim`) or a path to a Containerfile (e.g., `Containerfile`).
+3. **Materialize** — `lc run` executes recipes inside their declared containers and writes a content-addressed manifest next to each output. Done when `lc status` shows all `ok`.
+
+**An output is not done until `lc run` produces it.** Running scripts directly is for debugging only — final results must always come from `lc run` so they are reproducible.
+
+### Spec-Code Invariant
+
+**`astra.yaml` must always reflect the code and vice versa.** When you change one, update the other immediately:
+- Add a decision to code? Add it to `astra.yaml` and all universe files.
+- Add an output or change a script? Update the `recipe:` block in `astra.yaml`.
+- Remove or rename something? Update both sides and run `astra validate astra.yaml`.
+
+## Status Interpretation
+
+`lc status` shows each declared output's materialization state per universe. Pass `--json` for machine-readable output.
+
+- `ok` — Recipe exists, results on disk, manifest matches the current spec. Done.
+- `stale` — Recipe or decisions changed since the last run. Re-run `lc run`.
+- `missing` — Recipe exists but no manifest (never run, or output deleted). Run `lc run`.
+- `alias` — Output has no recipe of its own; produced as a side effect of an upstream output (or a `from:` reference into a sub-analysis). Not independently materializable.
+
+## Failure Diagnosis
+
+- **Script arg not recognized** — The recipe's `command` template controls how decisions reach the script. Make sure each `{decisions.<id>}` is paired with a flag the script's argparse defines (e.g. `--<id> {decisions.<id>}` ↔ `parser.add_argument('--<id>')`).
+- **Recipe input not found** — Materialize upstream outputs first.
+- **Undeclared placeholder error** — A `{decisions.<id>}` or `{inputs.<id>}` in the recipe references something not listed in `Output.decisions` / `Output.inputs`. Add it to the Output's declaration, or remove the placeholder.
+
+After failure: fix, then `lc run <output_id> --universe <name>`.

{lightcone_cli-0.2.0 → lightcone_cli-0.3.0}/claude/lightcone/skills/lc-build/assets/loop-prompt.md

@@ -4,7 +4,7 @@ You are inside a lc-build loop (universe: {{UNIVERSE}}). Each iteration: survey,
 
 Run these commands and read their output:
 
-1. `lc status --universe {{UNIVERSE}}` -- what's materialized, what's pending, what has no recipe
+1. `lc status --universe {{UNIVERSE}}` -- what's materialized (`ok`), missing, stale, or an alias of an upstream output
 2. `git log --oneline -10` -- what happened recently
 3. `astra validate astra.yaml` -- is the spec valid
 4. Read `.lightcone/plans/build-plan-{{UNIVERSE}}.md` -- your implementation plan (cross off completed items as you go)
@@ -24,9 +24,9 @@ Always fix validation errors before doing anything else. Commit. Exit.
 All outputs are materialized. Time to verify.
 
 1. **Inline checks:**
-   - `astra validate astra.yaml` passes
+   - `astra validate astra.yaml` passes (this also catches undeclared `{decisions.X}` / `{inputs.X}` placeholders in recipes)
    - `lc status --universe {{UNIVERSE}}` shows all `ok`
-   - Decision-code alignment: `grep -r "add_argument" scripts/` and compare against `astra info --decisions` — every decision must be a parameter, no hardcoded values
+   - Decision-code alignment: every decision listed in any `Output.decisions` must be (a) referenced by a `{decisions.<id>}` placeholder in the same Output's recipe command, AND (b) accepted as a parameter by the script the recipe invokes. `astra info --decisions` lists the decisions; `grep -r "add_argument" scripts/` (or whatever the script's parsing convention is) confirms the script side. No hardcoded values.
 2. **If any issues found:** fix them, re-materialize if needed, commit. Exit (loop continues).
 3. **If all clean:** Spawn a verification sub-agent with explicit steps (do not rely on skill dispatch — the sub-agent cannot invoke `/lc-verify` directly):
    ```
@@ -34,7 +34,7 @@ All outputs are materialized. Time to verify.
    Prompt: "Verify the spec, code, and results all agree for universe {{UNIVERSE}}. Run these checks in order:
    1. Spec validation: run `astra validate astra.yaml` — must pass with no errors.
    2. Materialization status: run `lc status --universe {{UNIVERSE}}` — every output must show `ok`.
-   3. Decision-code alignment (most important): run `astra info --decisions` and `grep -r 'add_argument' scripts/`. Every decision in the spec must be accepted as a CLI parameter in the code, with no hardcoded values.
+   3. Decision-code alignment (most important): run `astra info --decisions`. For every output that declares decisions in `Output.decisions`, confirm (a) the recipe's `command` references each one via a `{decisions.<id>}` placeholder, and (b) the invoked script accepts each as a parameter (typically via `add_argument`). No hardcoded option values. `astra validate` flags placeholder/declaration mismatches; this check covers the script side.
    4. Results match spec: for every output in astra.yaml, confirm `results/{{UNIVERSE}}/<output_id>.<ext>` exists and looks well-formed. For `type: metric` outputs, check for valid `{'value': ...}` JSON.
    Report all findings with file paths and line numbers. If all checks pass, end your report with exactly: VERIFIED"
    ```
@@ -47,27 +47,26 @@ These are the kinds of work you'll do, guided by the plan. Not a rigid sequence
 
 ### Writing scripts
 
-1. **Write the script.** Parameterize all decisions from `astra.yaml` as command-line arguments (underscore convention: `stellar_mass_cut` → `--stellar_mass_cut`).
+1. **Write the script.** Make every decision the recipe will pass into it a real CLI parameter (typically `argparse`). The recipe's `command` template is what wires decisions to the script — e.g. `python scripts/fit.py --stellar_mass_cut {decisions.stellar_mass_cut} --output {output}` paired with `parser.add_argument('--stellar_mass_cut')`. Pick the script-side flag names so they match the recipe template; the spec doesn't dictate them.
    The script must contain real, functional logic that produces genuine results from actual input data. No `# TODO` stubs, no hardcoded dummy values standing in for computation, no `pass` in place of real logic, no synthetic/mock data generation when real data is specified. If you cannot implement the full logic (e.g., missing a library or unclear algorithm), document the blocker in the build plan and move on — do not ship a fake version.
-2. **Test locally:** `python scripts/<name>.py --decision1 value1 --decision2 value2` using values from `universes/{{UNIVERSE}}.yaml`.
+2. **Test locally:** invoke the script with concrete values, e.g. `python scripts/<name>.py --decision1 value1 --decision2 value2 --output /tmp/check`, using values from `universes/{{UNIVERSE}}.yaml`.
    Note: manual script runs may write to `results/` but do NOT register as materialized.
-   Only `lc run` creates the Dagster events that `lc status` recognizes.
-3. **Debug until it works.** Read tracebacks, check imports (`python -c "import module"`), verify decision parameter names match `astra.yaml`.
+   Only `lc run` produces the per-output manifests that `lc status` reads.
+3. **Debug until it works.** Read tracebacks, check imports (`python -c "import module"`), verify the recipe template's `{decisions.<id>}` / `{inputs.<id>}` references match `Output.decisions` / `Output.inputs` (decision/input id, not script flag name).
 4. **Commit** with a message describing what the script does.
 
 ### Adding recipes & materializing
 
-1. **Add the recipe block** to `astra.yaml` under the output's `recipe:` key.
+1. **Wire the output.** On the `Output` itself, list its dependencies in `inputs: [...]` and the decisions it consumes in `decisions: [...]`. Then add the `recipe:` block with a `command` template referencing each via `{inputs.<id>}` and `{decisions.<id>}` (and `{output}` for the artifact directory). `astra validate` rejects placeholders that don't match what the Output declares.
 2. **Validate:** `astra validate astra.yaml`
-3. **Check execution environment:** If the target is SLURM, check `echo $SLURM_JOB_ID`. If empty, you are on a login node — warn the user to start an interactive allocation (`salloc`) before running. Do not submit batch jobs during the build loop; interactive execution is required for fast iteration.
-4. **Run it:** `lc run <OUTPUT> --universe {{UNIVERSE}}`
-5. **If it fails:** Read the error output carefully and diagnose the root cause before retrying. Never re-run the same command without changing something first. Common causes:
+3. **Run it:** `lc run <OUTPUT> --universe {{UNIVERSE}}`. `lc run` is the only supported way to execute recipes — it handles container resolution, scheduling, and provenance. Run the loop on a machine that can actually execute recipes (the user's laptop with a container runtime, or a compute session they've already opened).
+4. **If it fails:** Read the error output carefully and diagnose the root cause before retrying. Never re-run the same command without changing something first. Common causes:
    - Container not built → `lc build`
    - Upstream not materialized → materialize dependency first
    - Script error inside container → fix the script, then re-run
    If a second attempt also fails, note the failure in your commit message and in the build plan, then move on to other work. Come back to it in a later iteration with fresh context.
-6. **If it succeeds:** Verify the result file exists at `results/{{UNIVERSE}}/<output_id>.<ext>` and looks well-formed.
-7. **Commit** with a message noting what was materialized.
+5. **If it succeeds:** Verify the result file exists at `results/{{UNIVERSE}}/<output_id>/` and looks well-formed.
+6. **Commit** with a message noting what was materialized.
 
 ## Rules
 

{lightcone_cli-0.2.0 → lightcone_cli-0.3.0}/claude/lightcone/skills/lc-feedback/SKILL.md

@@ -35,7 +35,7 @@ The user should have provided a description inline (e.g., `/lc-feedback pipeline
 
 Triage the repo from context:
 - **ASTRA** — `astra` CLI, schema validation, YAML parsing, helpers
-- **lightcone-cli** — `lc` CLI, Dagster execution, recipes, container builds, scaffolding, skills, telemetry hooks
+- **lightcone-cli** — `lc` CLI, recipe execution, container builds, scaffolding, skills, telemetry hooks
 
 Default to **lightcone-cli** if ambiguous.
 

{lightcone_cli-0.2.0 → lightcone_cli-0.3.0}/claude/lightcone/skills/lc-migrate/SKILL.md

@@ -53,7 +53,24 @@ For reference, here are the decision criteria for classifying candidates:
 
 Write the scan results to `CLAUDE.md` under Analysis Context as a script inventory, then draft `astra.yaml` from the scan results following the spec structure documented in `.claude/guides/astra-reference.md`. Use the decision criteria from [ASTRA Reference](../../guides/astra-reference.md) to filter the subagent's candidate decisions down to only true analytical choices — most hardcoded values are implementation details, not decisions. Use current hardcoded values as defaults.
 
-Include `recipe:` blocks on each output pointing to the script that produces it. Also generate `universes/baseline.yaml` with all defaults matching the current hardcoded values (so the first run reproduces existing behavior).
+For each output, list the upstream artifacts it depends on under `Output.inputs: [...]` and the decisions it consumes under `Output.decisions: [...]`. Then add a `recipe.command` template that references each via `{inputs.<id>}` / `{decisions.<id>}` and writes to `{output}`. Example:
+
+```yaml
+outputs:
+  - id: galaxy_catalog
+    type: data
+    inputs: [survey_data]
+    decisions: [magnitude_cut, redshift_min]
+    recipe:
+      command: >
+        python scripts/build_catalog.py
+        --survey {inputs.survey_data}
+        --magnitude_cut {decisions.magnitude_cut}
+        --redshift_min {decisions.redshift_min}
+        --output {output}
+```
+
+Also generate `universes/baseline.yaml` with all defaults matching the current hardcoded values (so the first run reproduces existing behavior).
 
 Write to `astra.yaml` and `universes/baseline.yaml`, then validate: `astra validate astra.yaml`. Fix any errors.
 
@@ -74,8 +91,8 @@ Parameterize the code so decisions can be varied across universes. The goal is m
 Whatever approach you use:
 
 - **Don't refactor, restructure, or improve the code.** Just add the parameter plumbing.
-- **Underscore convention:** Decision IDs use underscores in `astra.yaml` (`outlier_sigma`). lightcone-cli passes `--outlier_sigma`. Argument parsing must match.
-- **Update output paths** to write to `results/{universe}/{output_id}.ext` following the convention in `CLAUDE.md`.
+- **The recipe template is what wires decisions to scripts.** Each `{decisions.<id>}` placeholder in `recipe.command` substitutes the active option ID at runtime, and the recipe author chooses the script-side flag name. Underscore IDs in the spec → match-them-yourself flags in the script (e.g. `--outlier_sigma {decisions.outlier_sigma}` paired with `parser.add_argument('--outlier_sigma')`). There is no auto-injection.
+- **Output paths.** The recipe receives the output directory as `{output}` — pass that through to the script (`--output {output}`) and have the script write its artifact inside that directory (e.g. `{output}/data.parquet`).
 - **Update recipes** in `astra.yaml` if the entry point or command changed.
 
 ## Phase 3: Run & Debug

{lightcone_cli-0.2.0 → lightcone_cli-0.3.0}/claude/lightcone/skills/lc-new/SKILL.md

@@ -68,7 +68,7 @@ For each approved paper: `astra paper add <doi>`, `astra paper path <doi>`, then
 - **Target decisions**: each decision ID, label, and options with descriptions
 - **Timestamp**: current time in ISO 8601
 
-The agent type is pre-configured with the user's preferred extraction model (set via `lc setup`). Spawn all in a single message (parallel). Show progress as results come in:
+The agent type is pre-configured with the user's preferred extraction model (the `extraction_model` field in `~/.lightcone/config.yaml`). Spawn all in a single message (parallel). Show progress as results come in:
 
 ```
   ✓ Ba et al. 2016 -- 3 prior insights

{lightcone_cli-0.2.0 → lightcone_cli-0.3.0}/claude/lightcone/skills/lc-verify/SKILL.md

@@ -22,11 +22,16 @@ astra validate astra.yaml
 lc status --universe <universe_id>
 ```
 
-Every output should show `ok`. Flag anything pending, missing, or without a recipe.
+Every output should show `ok`. Flag anything `missing`, `stale`, or only present as an `alias`.
 
 ### 3. Decision-code alignment
 
-**The most important check.** For every decision in `astra.yaml`, confirm the code accepts it as a parameter and does not hardcode its value. Compare `astra info --decisions` against `grep -r "add_argument" scripts/`.
+**The most important check.** For every output, every decision listed in `Output.decisions` must:
+
+1. Appear as a `{decisions.<id>}` placeholder in the same Output's recipe `command`. (`astra validate` enforces this; rerun if the spec changed.)
+2. Be accepted as a parameter by the script the recipe invokes, with no hardcoded value.
+
+Compare `astra info --decisions` against `grep -r "add_argument" scripts/` (or whatever the script's parsing convention is). Cross-check the recipe text to see how each decision is passed.
 
 ### 4. Results match spec
 

{lightcone_cli-0.2.0 → lightcone_cli-0.3.0}/claude/lightcone/templates/CLAUDE.md

@@ -18,9 +18,7 @@ astra.yaml              # Specification: decisions, inputs, outputs
 CLAUDE.md             # This file
 Containerfile         # Container image for execution
 requirements.txt      # Python deps (keep in sync with scripts)
-.lightcone/               # lightcone-cli internals
-  lightcone.yaml          # lightcone-cli config (default target, etc.)
-  dagster.yaml        # Dagster instance config
+.lightcone/             # lightcone-cli internals (managed by `lc`; do not edit)
 universes/
   baseline.yaml       # Default decision selections
 scripts/              # Implementation scripts

{lightcone_cli-0.2.0 → lightcone_cli-0.3.0}/pyproject.toml

@@ -10,13 +10,16 @@ authors = [
 ]
 
 dependencies = [
-    "astra-tools>=0.2.2",
+    "astra-tools>=0.2.5",
     "click>=8.0",
     "pyyaml>=6.0",
     "rich>=13.0",
-    "dagster>=1.9",
-    "dagster-webserver>=1.9",
-    "dagster-docker>=0.25",
+    "jinja2>=3.0",
+    "snakemake>=9.0",
+    "snakemake-interface-executor-plugins>=9.0",
+    "snakemake-interface-common>=1.14",
+    "dask>=2024.1",
+    "distributed>=2024.1",
     "langfuse>=2.0",
 ]
 
@@ -51,13 +54,20 @@ build-backend = "hatchling.build"
 source = "vcs"
 
 [tool.hatch.build.targets.wheel]
-packages = ["src/lightcone"]
+packages = [
+    "src/lightcone",
+    "src/snakemake_executor_plugin_dask",
+]
 
 [tool.hatch.build.targets.wheel.force-include]
 "claude/lightcone" = "lightcone/cli/claude/lightcone"
 
 [tool.hatch.build.targets.sdist]
-include = ["src/lightcone", "claude/lightcone"]
+include = [
+    "src/lightcone",
+    "src/snakemake_executor_plugin_dask",
+    "claude/lightcone",
+]
 
 [tool.ruff]
 target-version = "py311"
@@ -73,5 +83,13 @@ namespace_packages = true
 explicit_package_bases = true
 mypy_path = "src"
 
+[[tool.mypy.overrides]]
+module = ["dask.*", "distributed.*"]
+ignore_missing_imports = true
+follow_untyped_imports = true
+
 [tool.pytest.ini_options]
 testpaths = ["tests"]
+markers = [
+    "slow: tests that spin up real subsystems (dask cluster, etc.) — opt-in via -m slow",
+]