lightcone-cli 0.4.1__tar.gz → 0.4.2__tar.gz

{lightcone_cli-0.4.1 → lightcone_cli-0.4.2}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.5
 Name: lightcone-cli
-Version: 0.4.1
+Version: 0.4.2
 Summary: Lightcone command-line toolchain
 Author: Lightcone Research
 License: BSD-3-Clause
@@ -76,7 +76,9 @@ Then tell the agent what you have to start from — a research question
 
 - **Multiverse analysis** — define methodological decisions with multiple options; `lc` runs your analysis across all defensible paths automatically
 - **Provenance integrity** — every output gets a content-addressed manifest; `lc verify` detects tampering or broken chains
-- **HPC-ready execution** — Snakemake-backed DAG dispatch with SLURM and container support (Docker, Podman, Apptainer) out of the box
+- **HPC-ready execution** — Snakemake-backed DAG dispatch with SLURM and container support (Docker, Podman, podman-hpc) out of the box
+- **Cloud-ready execution** — on a lightcone JupyterHub, `lc` builds images through GCP Cloud Build and runs the pipeline in a run-scoped Dask Gateway cluster, with nothing to configure
+- **Report from the spec** — `lc init` scaffolds a MyST report that references your analysis by path, so figures and numbers stay single-sourced
 - **Reproducible publishing** — `lc export wrroc` emits a [Workflow Run RO-Crate](https://www.researchobject.org/workflow-run-crate/) bundle ready for Zenodo or WorkflowHub
 
 → [Full documentation](https://docs.lightconeresearch.org)

{lightcone_cli-0.4.1 → lightcone_cli-0.4.2}/README.md

@@ -40,7 +40,9 @@ Then tell the agent what you have to start from — a research question
 
 - **Multiverse analysis** — define methodological decisions with multiple options; `lc` runs your analysis across all defensible paths automatically
 - **Provenance integrity** — every output gets a content-addressed manifest; `lc verify` detects tampering or broken chains
-- **HPC-ready execution** — Snakemake-backed DAG dispatch with SLURM and container support (Docker, Podman, Apptainer) out of the box
+- **HPC-ready execution** — Snakemake-backed DAG dispatch with SLURM and container support (Docker, Podman, podman-hpc) out of the box
+- **Cloud-ready execution** — on a lightcone JupyterHub, `lc` builds images through GCP Cloud Build and runs the pipeline in a run-scoped Dask Gateway cluster, with nothing to configure
+- **Report from the spec** — `lc init` scaffolds a MyST report that references your analysis by path, so figures and numbers stay single-sourced
 - **Reproducible publishing** — `lc export wrroc` emits a [Workflow Run RO-Crate](https://www.researchobject.org/workflow-run-crate/) bundle ready for Zenodo or WorkflowHub
 
 → [Full documentation](https://docs.lightconeresearch.org)

{lightcone_cli-0.4.1 → lightcone_cli-0.4.2}/claude/lightcone/scripts/session-start.sh

@@ -52,9 +52,10 @@ Materialization: ok=$ok_count stale=$stale_count missing=$missing_count alias=$a
 Substrate CLIs (use --help on any):
   lc init / lc run / lc status / lc verify / lc build / lc export wrroc
   astra validate / astra paper add / astra universe generate
+  myst start — preview the MyST report scaffolded by lc init (needs mystmd)
 
 Reference skills (invoke when the surface above isn't enough):
-  /astra   — astra.yaml spec: decisions, prior_insights, findings, evidence, sub-analyses, narrative anchors
+  /astra   — astra.yaml spec: decisions, prior_insights, findings, evidence, sub-analyses
   /lc-cli  — lc workflow: spec-code invariant, status interpretation, failure diagnosis"
 
 if [ "$validation_ok" -ne 0 ]; then

{lightcone_cli-0.4.1 → lightcone_cli-0.4.2}/claude/lightcone/skills/README.md

@@ -1,6 +1,6 @@
 # lightcone-cli skills
 
-Each subdirectory is one Claude Code skill: `SKILL.md` plus optional `references/`, `assets/`, and `scripts/`. `lc init` copies these into a project's `.claude/skills/` so they are discoverable to Claude Code sessions.
+Each subdirectory is one Claude Code skill: `SKILL.md` plus optional `references/`, `scripts/`, and `templates/`. `lc init` copies these into a project's `.claude/skills/` so they are discoverable to Claude Code sessions.
 
 ## Project lifecycle skills
 

{lightcone_cli-0.4.1 → lightcone_cli-0.4.2}/claude/lightcone/skills/astra/SKILL.md

@@ -372,15 +372,21 @@ description: |
 astra init [DIRECTORY]                          # Scaffold a new analysis
 astra validate astra.yaml                       # Validate (run after every change)
 astra validate astra.yaml --verify-evidence     # + verify insight quotes against PDFs
+astra validate astra.yaml --skip-evidence       # Skip evidence checks even when insights exist
+astra spec [TERM] [--full]                      # Agent-friendly schema reference (concept summary, one entry, or full dump)
 astra info [--decisions|--inputs|--outputs]     # Analysis summary / element details
 astra universe generate -n NAME [-d "desc"]     # Generate universe from defaults
 astra universe check universes/x.yaml           # Check universe constraints
-astra viz [--fmt ascii|mermaid]                 # Visualize decision space
-astra schema show analysis|universe|insights    # Show JSON schema
+astra viz [--format mermaid|ascii]              # Visualize decision space
+astra schema show analysis|universe|insights    # Print a LinkML schema
+astra schema export [-o DIR]                    # Export LinkML schemas to files
 astra paper add DOI [--version N] [--pdf PATH]  # Cache a paper for evidence checks
 astra paper list                                # List cached papers
 astra paper show DOI                            # Show metadata for a cached paper
 astra paper path DOI [--version N]              # Print the cached PDF's path
+astra paper remove DOI                          # Remove a paper from the cache
+astra paper fetch-metadata [DOI|--all]          # Fetch title/authors for cached papers
+astra paper verify-quote DOI -q "TEXT"          # Verify a single quote
 astra paper verify-quotes DOI                   # Batch-verify quotes; reads {"quotes":[...]} JSON from stdin
 ```
 

{lightcone_cli-0.4.1 → lightcone_cli-0.4.2}/claude/lightcone/skills/check-sentence-by-sentence/SKILL.md

@@ -58,9 +58,10 @@ Pandoc.
    > "Which paper source should I audit? Please give me a `.tex` path or
    > `work/reference/document.md`."
 
-   If only `work/reference/paper.pdf` exists, ask the user to run the PARSE
-   phase first so `work/reference/document.md` exists. Do not audit PDFs
-   directly.
+   If only `work/reference/paper.pdf` exists, ask the user to run
+   `/paper-extraction` first (in lc-from-paper projects this happens during
+   the ORIENT stage) so `work/reference/source/` or
+   `work/reference/document.md` exists. Do not audit PDFs directly.
 
 ## Section enumeration
 

{lightcone_cli-0.4.1 → lightcone_cli-0.4.2}/claude/lightcone/skills/figure-comparison/SKILL.md

@@ -48,20 +48,20 @@ results.
 3. **Locate the paper reference substrate.** The user may have passed a
    path. Resolve it in this order:
 
-   1. If the argument is a directory containing `metadata.json`,
+   1. If the argument is a directory containing `index.json`,
       `document.md`, `figures/`, or `tables/`, use that directory as the
       paper reference root.
    2. If the argument is an arXiv source directory containing `.tex` files,
       use it as `source_root`, and use its parent `work/reference/` as the
       paper reference root when that parent exists.
    3. If no argument was supplied, prefer lc-from-paper's layout:
-      - `work/reference/source/` when arXiv TeX source exists. Use the TeX
-        files there for labels/captions and the parsed artifacts under
-        `work/reference/{figures,tables,metadata.json}` for renderable
-        reference files.
+      - `work/reference/source/` when arXiv TeX source exists. Use
+        `work/reference/index.json` for the figure/table inventory, the TeX
+        files for labels/captions, and the extracted artifacts under
+        `work/reference/{figures,tables}` for renderable reference files.
       - `work/reference/document.md` plus
-        `work/reference/{figures,tables,metadata.json}` when no TeX source
-        exists. This is the PDF + Docling fallback from lc-from-paper.
+        `work/reference/{figures,tables,index.json}` when no TeX source
+        exists. This is the PDF + Docling fallback from paper-extraction.
    4. Only after lc-from-paper paths fail, look for a legacy unzipped arXiv
       dir in cwd: a directory containing both a `*.tex` file and figure
       files (`*.pdf`, `*.png`, `*.eps`). Common names: `paper_source/`,
@@ -70,12 +70,14 @@ results.
    If no usable reference substrate is found, ask:
 
    > "Where is the paper reference directory? In a lc-from-paper project this
-   > should usually be `work/reference/`, containing `document.md`,
-   > `metadata.json`, and extracted `figures/` / `tables/`."
+   > should usually be `work/reference/`, containing `index.json`, extracted
+   > `figures/` / `tables/`, and either `source/` (arXiv TeX) or
+   > `document.md` (Docling fallback)."
 
-   If only `work/reference/paper.pdf` exists, ask the user to run the PARSE
-   phase first so Docling or the TeX parser populates `work/reference/`.
-   Do not compare directly against a whole PDF.
+   If only `work/reference/paper.pdf` exists, ask the user to run
+   `/paper-extraction` first (in lc-from-paper projects this happens during
+   the ORIENT stage) so `work/reference/index.json` and the extracted
+   artifacts are populated. Do not compare directly against a whole PDF.
 
 ## Phase 1 -- Understand the paper's main results
 
@@ -100,15 +102,20 @@ Read, in this order:
    come from the output ID and the result resolver in Phase 2.
 
 3. **The paper reference substrate**, in this order:
-   - Read `work/reference/metadata.json` when present. It is the primary
-     index for paper figures and tables; its paths are relative to
-     `work/reference/` and usually point into `figures/` or `tables/`.
+   - Read `work/reference/index.json` when present. It is the canonical
+     structural index for paper figures and tables, written by
+     paper-extraction on both paths; each figure/table entry carries `id`,
+     `label`, `caption`, and a `file` path relative to `work/reference/`
+     (usually pointing into `figures/` or `tables/`; multi-panel figures
+     also carry `files`). On the Docling path a `metadata.json`
+     intermediate may also exist; ignore it -- its content is already
+     folded into `index.json`.
    - If `work/reference/source/` exists, grep its TeX files for
      `\includegraphics`, `\label{fig:...}`, `\caption{...}`, and
-     `\begin{table}` to recover labels/captions that metadata may have
+     `\begin{table}` to recover labels/captions that the index may have
      missed.
    - If only `work/reference/document.md` exists, use the markdown plus
-     `metadata.json` as the source of captions, table text, and in-text
+     `index.json` as the source of captions, table text, and in-text
      numerical claims. This is the Docling/Pandoc fallback; preserve its
      line numbers and do not pretend it is TeX.
    - Grep the abstract, results, and discussion sections of the TeX or
@@ -155,23 +162,26 @@ For project-side result paths, resolve every output ID with this order:
 - Use an explicit `reproduced_file` from `comparison-report.yaml` or an
   explicit reproduced path/glob from `targets/targets.md`, if present and
   the file exists.
-- Search for flat files at `results/<universe>/<output_id>.<ext>` with the
-  first suitable type-specific extension: images (`.png`, `.jpg`, `.jpeg`,
+- Look inside the output directory `results/<universe>/<output_id>/` --
+  every `lc run` output is a directory containing the artifact file(s)
+  plus `.lightcone-manifest.json`. Glob within it for the first suitable
+  type-specific extension: images (`.png`, `.jpg`, `.jpeg`,
   `.pdf`, `.eps`), tables (`.csv`, `.parquet`, `.md`, `.txt`), values
-  (`.json`, `.yaml`, `.yml`, `.txt`, `.md`).
+  (`.json`, `.yaml`, `.yml`, `.txt`, `.md`) -- always ignoring
+  `.lightcone-manifest.json` and `.snakemake_timestamp`.
 - If still unmatched and no scoped ledger exists, fall back to filename-stem
-  similarity within `results/<universe>/`.
+  similarity across the artifact files inside `results/<universe>/*/`.
 - If no match is found, use `project_path: null` and render a red
   `NOT PRODUCED` panel. Do not include unrelated result files; the report is
   target-driven when target/report files exist, and paper-driven otherwise.
 
-For tables: use `work/reference/metadata.json` and `work/reference/tables/`
+For tables: use `work/reference/index.json` and `work/reference/tables/`
 when present. If TeX source exists, capture the raw LaTeX of the `tabular`
 block and any `\caption{...}`. If only `work/reference/document.md` exists,
 capture the Docling/Pandoc markdown table or the extracted table artifact
 under `work/reference/tables/`. The project side is whatever artifact
-carries the same content -- typically a CSV / parquet / markdown file at
-`results/<universe>/<output_id>.<ext>`. If `astra.yaml` declares no matching
+carries the same content -- typically a CSV / parquet / markdown file
+inside `results/<universe>/<output_id>/`. If `astra.yaml` declares no matching
 output, use `project_path: null`. **If the paper contains no tables at all,
 leave the manifest's `tables` list empty; the helper must omit the entire
 Tables section from the HTML in that case (no header, no "no tables"
@@ -182,8 +192,8 @@ project_value?, project_value_source?, paper_quote}`. Pull
 `paper_value` from the in-text claim or `astra.yaml`'s
 `findings.*.paper_value`. Pull `project_value` from
 `astra.yaml`'s `findings.*.replicated_value` if present, otherwise from
-a scoped `comparison-report.yaml` entry or a flat result summary file at
-`results/<universe>/<output_id>.<ext>` that you can read statically.
+a scoped `comparison-report.yaml` entry or a result summary file inside
+`results/<universe>/<output_id>/` that you can read statically.
 **Never compute or re-derive values yourself.** If no project value can
 be located statically, leave it null and flag in the HTML.
 
@@ -218,9 +228,11 @@ Use a small Python helper rather than embedding base64 inline through
 your tool calls -- multi-MB image base64 strings would balloon your
 context.
 
-Use the existing `.lightcone/` directory in the project root. Do not create
-directories in this skill. All three files this skill writes -- manifest,
-helper, and final HTML -- live there.
+Write into the `.lightcone/` directory in the project root. It exists in
+any `lc init`-ed project; if it is missing, tell the user the project is
+not initialized (`lc init`) instead of silently creating directories. All
+three files this skill writes -- manifest, helper, and final HTML -- live
+there.
 
 1. **Write the manifest** as JSON to
    `.lightcone/comparison_manifest.json`. Schema:
@@ -238,7 +250,7 @@ helper, and final HTML -- live there.
          "paper_caption": "...",
          "paper_path": "targets/main_result.pdf",
          "project_output_id": "primary_metric_plot",
-         "project_path": "results/baseline/primary_metric_plot.png"
+         "project_path": "results/baseline/primary_metric_plot/plot.png"
        }
      ],
      "tables": [
@@ -247,7 +259,7 @@ helper, and final HTML -- live there.
          "paper_caption": "...",
          "paper_latex": "\\begin{tabular}{...}\\end{tabular}",
          "project_output_id": "...",
-         "project_path": "results/baseline/summary_table.csv"
+         "project_path": "results/baseline/summary_table/summary.csv"
        }
      ],
      "values": [
@@ -259,7 +271,7 @@ helper, and final HTML -- live there.
          "paper_quote": "we find $\\mathrm{metric} = 12.5 \\pm 0.4$ <unit>",
          "project_value": "12.47",
          "project_uncertainty": "0.41",
-         "project_value_source": "results/baseline/metric.json"
+         "project_value_source": "results/baseline/primary_metric/metric.json"
        }
      ]
    }
@@ -519,8 +531,9 @@ solid-fill buttons), it is wrong.
   `scripts/` or `results/`. The only files this skill writes are
   `.lightcone/comparison_manifest.json`,
   `.lightcone/build_comparison.py`, and
-  `.lightcone/comparison.html`. Assume `.lightcone/` already exists; never
-  write into `results/`.
+  `.lightcone/comparison.html`. `.lightcone/` exists in any `lc init`-ed
+  project; if it is missing, stop and tell the user to run `lc init`
+  rather than creating it. Never write into `results/`.
 - You MUST NOT fabricate values. If a paper number is not stated in the
   paper source, `targets/targets.md`, `comparison-report.yaml`, or
   `astra.yaml`, leave it null. If a project number is not recorded in a

{lightcone_cli-0.4.1 → lightcone_cli-0.4.2}/claude/lightcone/skills/lc-cli/SKILL.md

@@ -4,8 +4,8 @@ description: >
   Reference for `lc` CLI execution: commands (init/run/status/verify/build/export),
   the Spec-Code Invariant (`astra.yaml` and code never diverge), status
   interpretation (ok/stale/missing/alias), failure diagnosis, multiverse
-  runs, scratch overrides for HPC, sub-analysis scaffolding, publishing
-  via WRROC. Invoke whenever running, debugging, or diagnosing `lc`
+  runs, scratch overrides for HPC, JupyterHub/Dask Gateway deployments,
+  sub-analysis scaffolding, publishing via WRROC. Invoke whenever running, debugging, or diagnosing `lc`
   workflows; whenever interpreting `lc status` / `lc verify` output; or
   whenever the user asks about the development workflow surrounding
   `astra.yaml`.
@@ -19,25 +19,33 @@ Reference for lightcone-cli execution: CLI commands, development workflow, statu
 ## CLI Reference
 
 ```bash
-lc init [DIR] [--permissions yolo|recommended|minimal] [--scratch PATH]  # Scaffold a new ASTRA project
-lc run [OUTPUTS...] [--universe NAME] [--force] [--verbose] [--rerun-triggers TRIGGERS]  # Materialize outputs
-lc build [--force] [--runtime docker]                             # Build container images from specs
+lc init [DIR] [--no-git] [--no-venv] [--permissions yolo|recommended|minimal] [--scratch PATH]  # Scaffold a new ASTRA project
+lc run [OUTPUTS...] [--universe NAME] [--jobs N] [--force] [--verbose] [--rerun-triggers TRIGGERS]  # Materialize outputs
+lc build [--force] [--runtime docker|podman|podman-hpc|kubernetes]  # 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
 lc export wrroc [--output PATH] [--universe NAME] [--zip] [--metadata-only] [--author "NAME <EMAIL>"]  # Export Workflow Run RO-Crate bundle
 ```
 
-`lc run` is quiet by default — pass `--verbose` to see worker output. `--scratch` is only relevant on HPC sites where `$HOME` doesn't honor `flock` (NERSC etc.); it redirects Snakemake state and Dask spill onto the named filesystem.
+`lc run` is quiet by default — pass `--verbose` to see worker output. `--jobs` bounds parallel dispatch (default: local CPU count). `--scratch` is only relevant on HPC sites where `$HOME` doesn't honor `flock` (NERSC etc.); it redirects Snakemake state and Dask spill onto the named filesystem.
+
+`lc init` also scaffolds a template MyST report (`myst.yml` + `index.md`; `_build/` is gitignored) — preview it with `myst start` (requires the MyST CLI: `npm i -g mystmd`).
 
 The first `lc` invocation auto-creates `~/.lightcone/config.yaml`:
 
 ```yaml
 container:
-  runtime: auto    # or: docker | podman | podman-hpc | none
+  runtime: auto    # or: docker | podman | podman-hpc | kubernetes | none
 ```
 
+On the `kubernetes` runtime there is no local OCI runtime: `lc build` submits each Containerfile to the deployment's GCP Cloud Build service (running under the deployment's service account) and pushes `<registry>/lc-<project>:<hash>` — same content-addressed identity. Freshness is a registry check, not a local image-store check.
+
 **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.
 
+## JupyterHub Deployments (Dask Gateway)
+
+A lightcone JupyterHub is detected via `DASK_GATEWAY__ADDRESS` (site `jupyterhub` in the site registry); the container runtime resolves to `kubernetes` — the worker pod *is* the container, and recipes run natively inside it. `lc run` pre-flight-builds images through Cloud Build, then creates a run-scoped Gateway cluster sized by `--jobs`, with workers running the project image; the cluster is torn down when the run finishes. Constraint: every output in one run must resolve to a single container image, or `lc run` fails — consolidate on one Containerfile (or one shared prebuilt image). If a run sits at zero workers (e.g. a slow first-time image pull), the wait for the first worker is bounded by `LIGHTCONE_GATEWAY_WORKER_TIMEOUT` (seconds, default 600).
+
 ## Creating Sub-Analyses
 
 Sub-analyses are scaffolded by hand, since each one is just another `astra.yaml` nested in a directory. To add one:

{lightcone_cli-0.4.1 → lightcone_cli-0.4.2}/claude/lightcone/skills/lc-feedback/SKILL.md

@@ -41,9 +41,9 @@ Default to **lightcone-cli** if ambiguous.
 Collect versions silently:
 
 ```bash
-python3 -c "import astra; print(astra.__version__)" 2>/dev/null || echo "n/a"
-python3 -c "import lightcone.cli; print(lightcone.cli.__version__)" 2>/dev/null || echo "n/a"
-python3 --version 2>&1
+astra --version 2>/dev/null || echo "n/a"
+lc --version 2>/dev/null || echo "n/a"
+python --version 2>&1
 uname -s -r
 ```
 

{lightcone_cli-0.4.1 → lightcone_cli-0.4.2}/claude/lightcone/skills/lc-from-code/SKILL.md

@@ -59,7 +59,7 @@ For reference, here are the decision criteria for classifying candidates:
 
 When the codebase is large enough that one Explore pass risks missing depth (a multi-project monorepo, a workflow folder plus a notebooks tree plus a `src/` package), spawn Explores in parallel against the named subtrees — one Explore per coherent region. Aggregate their inventories into the final scan output.
 
-Write the scan results to `CLAUDE.md` under `## Project Notes` (fresh migration) or to the path the invocation prompt specifies (scan-only — typically `work/reference/code-index.md`) as a script inventory, then in fresh migration mode draft or add to `astra.yaml` from the scan results following the spec structure documented in `/astra`. In scan-only mode, stop after the inventory file lands; do not touch `astra.yaml`. Use the decision criteria from `/astra` (Decisions section) to filter candidate decisions down to only true analytical choices — most hardcoded values are implementation details, not decisions. Use current hardcoded values as defaults.
+Write the scan results to `CLAUDE.md` (fresh migration — append a `## Project Notes` section; the file `lc init` generates has an orientation intro, an `lc` CLI quick reference, and a `## Report` section, but no notes section) or to the path the invocation prompt specifies (scan-only — typically `work/reference/code-index.md`) as a script inventory, then in fresh migration mode draft or add to `astra.yaml` from the scan results following the spec structure documented in `/astra`. In scan-only mode, stop after the inventory file lands; do not touch `astra.yaml`. Use the decision criteria from `/astra` (Decisions section) to filter candidate decisions down to only true analytical choices — most hardcoded values are implementation details, not decisions. Use current hardcoded values as defaults.
 
 In augment mode, preserve the existing paper-derived or user-derived `inputs`, `outputs`, `decisions`, `findings`, and `description` unless the code scan shows a real conflict. Attach code evidence to the nearest existing home first. Create new ASTRA structure only when the code reveals a real analysis object that has no suitable home in the current spec.
 
@@ -103,6 +103,8 @@ Parameterize the code from ASTRA decisions so the baseline run reproduces the ex
 - No container setup but a `requirements.txt`: write a minimal `Containerfile` (`FROM python:3.12-slim`, copy and `pip install -r requirements.txt`, then `COPY . .`) and point `container:` at it.
 - Nothing to go on: set `container: python:3.12-slim` as a starting point — the user can swap to a real `Containerfile` later.
 
+Prefer a single shared image unless recipes genuinely need different stacks: on a JupyterHub/Dask-Gateway deployment, `lc run` rejects specs that resolve to more than one container image per run.
+
 Whatever approach you use:
 
 - **Don't refactor, restructure, or improve the code.** Just add the parameter plumbing.
@@ -120,7 +122,7 @@ If it fails, read the error, fix it, and retry. Iterate until `lc status` shows
 
 If the scan found existing results elsewhere in the project, compare them against the new outputs in `results/baseline/<output_id>/` to verify the migration preserved behavior.
 
-Then validate the spec and the provenance chain: `astra validate astra.yaml` and `lc verify`. Present summary to user.
+Then validate the spec and the provenance chain: `astra validate astra.yaml` and `lc verify`. Present summary to user. If the project was scaffolded by `lc init`, also flag that the MyST report (`index.md`) still references the boilerplate ids (`example_method`, `main_result`) and needs updating to the reshaped spec's element paths.
 
 ## Rules
 

{lightcone_cli-0.4.1 → lightcone_cli-0.4.2}/claude/lightcone/skills/lc-from-paper/SKILL.md

@@ -64,7 +64,7 @@ ORIENT runs as one phase in **seven stages**:
 
 These get drafted into **two files** plus the substrate, all in the reproduction workdir:
 
-- **`constitution.md`** — the ralph loop's driving document. Goal, Fidelity intent, Scope, Quality bar, Evidence (paper DOI, arXiv ID, code repo URL), Open dimensions. Starts with YAML frontmatter `status: active` so the ralph launcher accepts it. Authored using the `/ralph` skill's authoring discipline (the constitution-authoring mode of `/ralph` — see its references on voice and sections).
+- **`constitution.md`** — the ralph loop's driving document. Goal, Fidelity intent, Scope, Quality bar, Evidence (paper DOI, arXiv ID, code repo URL), Open dimensions. Starts with YAML frontmatter `status: active` (the launcher accepts `open` or `active`; `active` is the convention here). Authored using the `/ralph` skill's authoring discipline (the constitution-authoring mode of `/ralph` — see its references on voice and sections).
 - **`CLAUDE.md`** — the auto-loading walk-up. Paper identity at the top, Rules (universal across reproductions; leave the template's defaults), Disagreements log (starts empty), Open opportunities (starts empty), Pointers (to `constitution.md`, `work/reference/`, etc.).
 - **`work/reference/`** — paper substrate from `/paper-extraction` + code substrate from `/lc-from-code` scan-only (when a code repo exists).
 

{lightcone_cli-0.4.1 → lightcone_cli-0.4.2}/claude/lightcone/skills/lc-from-paper/references/architect.md

@@ -30,7 +30,7 @@ Read `constitution.md`, `CLAUDE.md`, `work/reference/index.json`, `work/referenc
 2. **Choose: one analysis or sub-analyses?** If the paper has only one stage end-to-end (no clean intermediate handoffs), write a single analysis. If it has genuinely independent stages (each stage's output flows as the next's input), write sub-analyses. Sub-analysis IDs must be noun phrases: `reconstruction`, `clustering`, `bao_fit`. Avoid reserved names: `inputs`, `outputs`, `decisions`, `findings`, `prior_insights`, `analyses`, `options`, `content`.
 3. **Wire inputs and outputs at the sub-analysis level.** For each sub-analysis:
    - Declare `inputs:` from `code-index.md`'s External-data-dependencies plus any paper-named external datasets. The depth (acquisition path, selection criteria) is SPECIFY's; ARCHITECT names the input and gives it a stable id.
-   - Declare `outputs:` matching the result loci from `index.json` (figures + tables) plus any intermediate artifacts a downstream sub-analysis consumes. Tag each output's `priority:` from the paper's emphasis (primary / secondary). **The reproduction's targeted scope from `constitution.md`'s Scope takes precedence** — if the user only wants Figure 3 and Table 2, only those land as `outputs:`; the rest are out-of-scope and noted as such.
+   - Declare `outputs:` matching the result loci from `index.json` (figures + tables) plus any intermediate artifacts a downstream sub-analysis consumes. Note each output's priority (primary / secondary, from the paper's emphasis) in its `description:` — there is no `priority:` slot in the schema; SPECIFY carries the priority formally into `targets/targets.md`. **The reproduction's targeted scope from `constitution.md`'s Scope takes precedence** — if the user only wants Figure 3 and Table 2, only those land as `outputs:`; the rest are out-of-scope and noted as such.
 4. **Author the root and per-analysis `description`.** Write a short `description:` (one or two paragraphs) on the root analysis and on each sub-analysis — enough to orient a reader on what the analysis is and what it produces. The root `description:` should give a top-down, end-to-end sketch of how the sub-analyses' outputs flow into one another when sub-analyses exist. Keep it high-level; per-decision and per-finding prose lives on those entries' own `rationale:` / `notes:` fields, authored in SPECIFY.
 5. **Validate.** `astra validate astra.yaml` must return clean — even with empty `decisions:` / `prior_insights:` / `findings:` blocks, the structural fields and descriptions must pass schema checks.
 
@@ -38,27 +38,33 @@ Read `constitution.md`, `CLAUDE.md`, `work/reference/index.json`, `work/referenc
 
 ```yaml
 # Stub: structure + descriptions. SPECIFY fills decisions/findings/prior_insights.
-id: <paper-slug>
-title: "<paper title>"
-doi: <doi>
+# Paper: "<paper title>" — DOI <doi> (cached via `astra paper add <doi>`;
+# title/doi are not Analysis slots, so they live here and in constitution.md)
+version: "0.0.12"
+name: <paper-slug>
 
 description: |
   <high-level paragraph for the root analysis; sketch the end-to-end
   data flow across sub-analyses when they exist>
 
+inputs: []           # externals live on the sub-analyses that consume them
+
+outputs:             # root-level re-exports of the replication targets
+  - id: <output-id>
+    from: <sub-analysis-id-1>.<output-id>
+
 analyses:
   <sub-analysis-id-1>:
     description: |
       <short paragraph orienting a reader on this sub-analysis>
     inputs:
-      <input-id>:
-        <stable name; depth lives in SPECIFY>
+      - id: <input-id>
+        type: data
+        description: "<stable name; acquisition depth lives in SPECIFY>"
     outputs:
-      <output-id>:
-        type: figure | table | metric | data-product
-        priority: primary | secondary
-        description: |
-          <one-line on what this output is>
+      - id: <output-id>
+        type: figure   # figure | table | metric | data | report
+        description: "<one-line on what this output is; note primary / secondary emphasis>"
     decisions: {}      # SPECIFY fills
     prior_insights: {} # SPECIFY records placeholders (Evidence with doi:, no quote: yet), LITERATURE fills the quote: selectors
     findings: {}       # SPECIFY fills

{lightcone_cli-0.4.1 → lightcone_cli-0.4.2}/claude/lightcone/skills/lc-from-paper/references/compare.md

@@ -20,11 +20,11 @@ COMPARE is what a ralph iteration does when the workdir signals "RUN done (`resu
 
 ## Result path convention
 
-For an output with `id: X`, the reproduced result lives at `results/<universe_id>/X.<ext>`:
+For an output with `id: X`, the reproduced result lives in the directory `results/<universe_id>/X/` — the artifact(s) the recipe wrote plus the run's `.lightcone-manifest.json`:
 
-- metrics: `.json` containing `{"value": ...}`
-- figures: `.png`
-- tables: `.csv`
+- metrics: a `.json` containing `{"value": ...}`
+- figures: a `.png`
+- tables: a `.csv`
 
 ## Task
 

{lightcone_cli-0.4.1 → lightcone_cli-0.4.2}/claude/lightcone/skills/lc-from-paper/references/implement.md

@@ -53,7 +53,7 @@ The iteration merges scripts and recipes after the per-output sub-agents finish.
 ### Rules for the first pass
 
 1. **One script per output** (or a shared script for tightly-coupled outputs).
-2. **Parameterize by decisions.** Each decision is a CLI argument; scripts also receive `--universe <universe_id>`. See lightcone-cli's `CLAUDE.md` for the full convention.
+2. **Parameterize by decisions.** Each decision the output declares becomes a CLI argument, wired explicitly in the recipe via `{decisions.<id>}`; paths flow via `{output}` and `{inputs}` / `{inputs.<id>}`. Nothing is auto-injected — the recipe's `command:` must pass everything the script needs, and any other placeholder is rejected at run time.
 3. **Add recipes** to each output in `astra.yaml` with `command:` and `inputs:` (dependencies). Recipe inputs use the `<analysis>.<output>` tree-path form that wires outputs to downstream inputs.
 4. **Create `requirements.txt`** with needed packages. Do not install them — the RUN phase manages environments.
 5. **Do not execute scripts** — the RUN phase handles execution via `lc run`.

{lightcone_cli-0.4.1 → lightcone_cli-0.4.2}/claude/lightcone/skills/lc-from-paper/references/review.md

@@ -1,6 +1,6 @@
 # REVIEW — close-out in the user's main session
 
-The reproduction has converged: the constitution's `status:` is `closed` (after COMPARE returned `pass`, or `partial` with the un-acted opportunities logged, and the next cold-survey iteration found nothing left to do). The ralph loop's tmux session has exited. REVIEW runs back in the user's main session — the second of two interactive bookends, the first being ORIENT. It runs in the user's main session (not as an iteration) because both `/figure-comparison` and `/check-sentence-by-sentence` use `AskUserQuestion`, which isn't available inside detached ralph iterations.
+The reproduction has converged: the constitution's `status:` is `closed` (after COMPARE returned `pass`, or `partial` with the un-acted opportunities logged, and the next cold-survey iteration found nothing left to do). The ralph loop's tmux session has exited. REVIEW runs back in the user's main session — the second of two interactive bookends, the first being ORIENT. It runs in the user's main session (not as an iteration) because both `/figure-comparison` and `/check-sentence-by-sentence` are interactive — they prompt the user for anything they can't infer, which doesn't work inside detached ralph iterations.
 
 Its job is to render the validation surfaces, walk the user through the accumulated open questions, land the resolutions, and draft the final report — in one interactive arc. The Open opportunities list in CLAUDE.md already carries un-acted-on opportunities from the latest COMPARE (those iterations logged them directly); REVIEW just reads them.
 
@@ -21,7 +21,7 @@ The phase name **REVIEW** is freed by the old pre-implement REVIEW phase folding
 ## Outputs
 
 - `.lightcone/comparison.html` — `/figure-comparison`'s portable side-by-side report (paper artifacts vs reproduced)
-- (Optional) `.lightcone/check-sentence-by-sentence.md` — `/check-sentence-by-sentence`'s claim audit (file:line or NOT FOUND per sentence)
+- (Optional) `/check-sentence-by-sentence`'s claim audit, rendered in-chat (file:line or NOT FOUND per sentence — the skill writes no files)
 - `open-questions.md` — same file, but with `## Resolutions` section appended capturing what the user said for each entry
 - Edits to `astra.yaml` / `implementation-notes.md` / `universes/baseline.yaml` if any open-question resolution warrants a spec change
 - `REPRODUCTION-SUMMARY.md` — final report; concise (~1–2 pages); the canonical record of what the reproduction landed on
@@ -32,19 +32,19 @@ The phase name **REVIEW** is freed by the old pre-implement REVIEW phase folding
 
 ### `/figure-comparison` (mandatory)
 
-Invoke the `/figure-comparison` skill from the user's main session. It builds a portable HTML side-by-side comparing paper artifacts (from `targets/`) to reproduced artifacts (from `results/<universe>/`). The skill uses `AskUserQuestion` for any inputs it can't infer from the workdir; that works because REVIEW runs back in the user's main session — the prompts land here, not in a detached iteration.
+Invoke the `/figure-comparison` skill from the user's main session. It builds a portable HTML side-by-side comparing paper artifacts (from `targets/`) to reproduced artifacts (from `results/<universe>/`). The skill asks the user about any inputs it can't infer from the workdir; that works because REVIEW runs back in the user's main session — the prompts land here, not in a detached iteration.
 
 Output lands at `.lightcone/comparison.html`. Show the user the path and offer to open it (`open` on macOS, `xdg-open` on Linux, or just print the path so they click in their terminal).
 
-**Do not spawn `/figure-comparison` under the `Task` tool or inside a ralph iteration.** It has `AskUserQuestion` in its `allowed-tools`; sub-agents and detached iterations have no user-reach, so the prompt fires into nothing.
+**Do not spawn `/figure-comparison` under the `Task` tool or inside a ralph iteration.** It prompts the user for inputs it can't infer; sub-agents and detached iterations have no user-reach, so the prompt fires into nothing.
 
 ### `/check-sentence-by-sentence` (opt-in)
 
 Ask the user via `AskUserQuestion` whether they want the claim audit. It's optional because for many reproductions the figure-comparison already settles "did it match?"; the sentence-by-sentence audit earns its keep when the paper makes many specific quantitative claims and the user wants each one anchored to a code location.
 
-If yes, invoke `/check-sentence-by-sentence`. Same discipline as `/figure-comparison` — it can prompt the user; do not spawn under `Task` or inside a ralph iteration.
+If yes, ask the user to run `/check-sentence-by-sentence` themselves — that skill is user-invoked by design and should not be launched from here. Same discipline as `/figure-comparison` once it runs: it can prompt the user, so it belongs in the main session, never under `Task` or inside a ralph iteration.
 
-Output lands at `.lightcone/check-sentence-by-sentence.md` (or wherever the skill writes it). Show the user the path.
+The audit renders directly in chat as a markdown report organized by paper section — the skill writes no files.
 
 ## Step 2: walk `open-questions.md` with the user
 
@@ -99,8 +99,8 @@ This commit is the durable mark that the reproduction has reached close-out. Fut
 
 ## Notes
 
-- **This phase runs in the user's main session.** Do not invoke it from inside a ralph iteration. The whole point of REVIEW is that the user is reachable — every step uses `AskUserQuestion` (directly, or via the sibling skills it invokes), and iterations are detached.
-- **`/figure-comparison` and `/check-sentence-by-sentence` use `AskUserQuestion`.** That's why REVIEW runs in the user's main session and they live here, not in any iteration. Invoking either inside an iteration fires prompts into nothing.
+- **This phase runs in the user's main session.** Do not invoke it from inside a ralph iteration. The whole point of REVIEW is that the user is reachable — every step prompts the user (via `AskUserQuestion` directly, or via the interactive sibling skills it invokes), and iterations are detached.
+- **`/figure-comparison` and `/check-sentence-by-sentence` are interactive.** They prompt the user when they need input — that's why REVIEW runs in the user's main session and they live here, not in any iteration. Invoking either inside an iteration fires prompts into nothing.
 - **The user owns the verdict-acceptance decision.** REVIEW's purpose is to let the user see what the loop's iterations did and decide whether they accept it. The skill renders surfaces and asks; it does not unilaterally close.
 - **Don't confuse with the per-phase reviews inside the loop.** ARCHITECT, SPECIFY, LITERATURE, and IMPLEMENT each have their own fresh-context review discipline that happens by iteration boundary. Those are unrelated to this close-out — same word, different jobs. The phase boundary makes them unambiguous: per-phase reviews live inside their host phase's reference; this one is the post-loop close-out in the user's main session.
 - **Open-question resolutions are durable.** Append to `open-questions.md`'s `## Resolutions` section so the next re-run / future session sees what was decided. Do not delete the original questions.

{lightcone_cli-0.4.1 → lightcone_cli-0.4.2}/claude/lightcone/skills/lc-from-paper/references/run.md

@@ -29,11 +29,11 @@ Check status:
 lc status --universe baseline
 ```
 
-Status states are `ok` (materialized), `pending` (has recipe, not run), `no_recipe` (declared, no recipe — bug). Every output declared in `astra.yaml` must reach `ok`.
+Status states are `ok` (materialized, current), `missing` (not yet materialized), `stale` (materialized, but the spec has drifted since — recipe, container, or decisions changed; needs a re-run), `alias` (a re-export of another output; resolves through its source). Every output declared in `astra.yaml` must reach `ok`.
 
 If outputs fail:
 
-1. **Read the script's error.** `results/<universe>/<output>/.log` (or wherever the runner emits stderr) usually has the message.
+1. **Read the script's error.** `lc run` re-emits each recipe's stdout / stderr on its own terminal output, and on failure prints a summary pointing at the saved snakemake stderr log. There is no per-output log file on disk — the run's terminal output is the record.
 2. **Diagnose.** Common failures: missing data dependency (a referenced URL changed; the data archive moved), missing Python package (`requirements.txt` was incomplete), spec / script mismatch (the recipe's `inputs:` does not match what the script reads).
 3. **Fix.** Edit the script or `requirements.txt` or the spec, whichever applies.
 4. **Re-run.** `lc run --universe baseline` resumes from where things failed; it does not re-execute already-materialized outputs.
@@ -52,6 +52,6 @@ If outputs fail:
 
 ## Notes
 
-- The runner backend (Docker / local / SLURM) comes from the project's target configuration — `~/.lightcone/config.yaml` and `.lightcone/lightcone.yaml`. RUN does not need to choose; the runner picks based on config.
-- For long-running computations, the script's stdout / stderr stream into the result directory's log file. The iteration should use the Monitor tool on the log file to stream events (each stdout line surfaces as a notification), not poll `lc status` repeatedly. For one-shot waits, Bash with `run_in_background` notifies on completion.
+- The runner backend (Docker / local / SLURM) comes from the project's target configuration — `~/.lightcone/config.yaml` and `.lightcone/lightcone.yaml`. RUN does not need to choose; the runner picks based on config. One caveat: on a JupyterHub / Dask-Gateway deployment, `lc run` requires every output in a run to resolve to a single container image — specs declaring several distinct containers are rejected there; consolidate on one Containerfile.
+- For long-running computations, run `lc run` under Bash with `run_in_background` — recipe stdout / stderr surfaces on the `lc run` process's own output as rules finish (there is no per-output log file to monitor), and the background run notifies on completion instead of the iteration polling `lc status` repeatedly.
 - **Commit the materialized results' state when RUN settles.** The actual `results/` artifacts are gitignored heavy data, but the run-level outcome (which outputs reached `ok`, any failures logged) is worth a commit so the next iteration can read `git log` to know RUN landed.

{lightcone_cli-0.4.1 → lightcone_cli-0.4.2}/claude/lightcone/skills/lc-from-paper/references/specify.md

@@ -79,7 +79,7 @@ Read the paper's section(s) covering this sub-analysis. Author:
            # quote: omitted at SPECIFY time — LITERATURE fills the TextQuoteSelector in
    ```
 
-   Evidence with `doi:` and no `quote:` is structurally valid in 0.0.10 (`quote:` is optional on Evidence); the placeholder passes `astra validate` and waits for LITERATURE to fill the quote. `astra validate --verify-evidence` should only be run after LITERATURE has resolved every placeholder.
+   Evidence with `doi:` and no `quote:` is structurally valid (`quote:` is optional on Evidence); the placeholder passes `astra validate` and waits for LITERATURE to fill the quote. `astra validate --verify-evidence` should only be run after LITERATURE has resolved every placeholder.
 
    When the citation's DOI is unresolved (`citations[<key>].doi: null` — flagged in `extraction_warnings`), the placeholder still needs a `doi:` (Evidence requires exactly one of `doi` or `artifact`). In that case, omit the Evidence entry entirely or fall back to an artifact reference if the gap will be resolved internally — and log the unresolved citation to `open-questions.md` so the user can supply the DOI at REVIEW close-out. Don't pre-emptively fetch the cited paper or guess its content; LITERATURE does that with fresh context per paper.
 

{lightcone_cli-0.4.1 → lightcone_cli-0.4.2}/claude/lightcone/skills/lc-new/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: lc-new
 description: Use this skill whenever the user starts a new ASTRA analysis from a research question — scoping the question, structuring inputs and outputs, identifying decisions through literature, and landing astra.yaml + project CLAUDE.md. Triggers on verbs (`new`, `start`, `scope`) combined with nouns (`analysis`, `project`, `question`, `research`) — e.g. "new analysis", "start project", "scope research question" — even if the user doesn't say "project" explicitly. Don't use this for working inside an existing ASTRA project; this is for fresh scoping only.
-allowed-tools: Read, Write(astra.yaml), Write(universes/*), Write(CLAUDE.md), Edit(astra.yaml), Edit(universes/*), Edit(CLAUDE.md), Glob, Grep, Bash(astra:*), Bash(lc:*), WebSearch, WebFetch, AskUserQuestion, Agent
+allowed-tools: Read, Write(astra.yaml), Write(universes/*), Write(CLAUDE.md), Edit(astra.yaml), Edit(universes/*), Edit(CLAUDE.md), Edit(index.md), Glob, Grep, Bash(astra:*), Bash(lc:*), WebSearch, WebFetch, AskUserQuestion, Agent
 ---
 
 # /lc-new
@@ -70,7 +70,7 @@ Spawn all in a single message (parallel). Show progress as results come in:
   ○ Wu & He 2018 (reading...)
 ```
 
-Write extracted prior insights to astra.yaml immediately. Synthesize them by topic for the user.
+Write extracted prior insights to astra.yaml immediately. The extractor's `decision_links:` block is not an ASTRA field — translate it into `insights: [...]` lists on the corresponding decision options when merging (Option.insights in `/astra`); never copy `decision_links` into astra.yaml. Synthesize the insights by topic for the user.
 
 ### Decision Identification
 
@@ -121,7 +121,11 @@ Replace the TODO `description:` in `astra.yaml` with a short one-or-two-paragrap
 
 ### Populate CLAUDE.md
 
-Read the existing `CLAUDE.md` (created by `lc init`). Fill the `## Project Notes` section per the inline guidance there — context from the conversation that's not in `astra.yaml` and would be lost after `/clear`. The spec is the source of truth for structure, decisions, and evidence.
+Read the existing `CLAUDE.md` (created by `lc init` — an orientation intro, an `lc run`/`lc status`/`lc verify` quick reference, and a `## Report` section). Append a `## Project Notes` section capturing the scoping outcome — context from the conversation that's not in `astra.yaml` and would be lost after `/clear` — and update the intro's "has not been scoped yet" framing now that the spec is real. The spec is the source of truth for structure, decisions, and evidence.
+
+### Populate Report
+
+`lc init` scaffolds `index.md` with references to the boilerplate `astra.yaml` elements — `decisions.example_method` (an inline `{astra}` mention and a `:::{astra} decisions.example_method\n:::` block) and `outputs.main_result` (an `{astra:value}` mention). Those IDs no longer exist once the boilerplate is replaced, which breaks the MyST build. Swap them for one representative top-level decision ID and one representative top-level output ID from the finalized spec. Only fix the reference IDs — leave the surrounding TODO narrative (Introduction/Methods/Results prose) for the user to fill in.
 
 ### Review with User
 
@@ -154,7 +158,7 @@ Then tell the user the spec is ready and they can begin implementation. Recommen
 
 You MUST NOT write Python, R, or other implementation code.
 
-You MUST ONLY create/modify: `astra.yaml`, `universes/*.yaml`, `CLAUDE.md` (Finalize only).
+You MUST ONLY create/modify: `astra.yaml`, `universes/*.yaml`, `CLAUDE.md` (Finalize only), `index.md` (Finalize only, reference IDs only).
 
 You MUST NOT fabricate quotes -- all evidence must pass `astra validate --verify-evidence`.
 

{lightcone_cli-0.4.1 → lightcone_cli-0.4.2}/claude/lightcone/skills/ralph/SKILL.md

@@ -49,7 +49,7 @@ For deeper voice / section guidance and the discipline that keeps a constitution
    ---
    ```
 
-   That's what the launcher checks; it refuses to start otherwise.
+   That's what the launcher checks; it refuses to start otherwise. (`status: open` is accepted too; `active` is the convention.)
 
 3. **Refine** — Show the draft, get feedback, revise. Use `AskUserQuestion` for structured choices. Apply the qualitative ambiguity self-check from [`references/crafting.md`](references/crafting.md) — goal, constraints, success — before launching. Reach for the crafting rhythm and stances when the conversation has careful-thinking character; skip when it doesn't.
 

{lightcone_cli-0.4.1 → lightcone_cli-0.4.2}/claude/lightcone/skills/ralph/references/constitution.md

@@ -39,7 +39,7 @@ Read relevant files, understand existing patterns. This informs the **constituti
 
 ### 2. Draft
 
-Create the constitution as a markdown file with `status: active` in YAML frontmatter (that's what the launcher checks). Some workflows expect a specific path so a runner picks it up — e.g. `/lc-from-paper` writes `constitution.md` at the reproduction workdir root. Otherwise put it wherever the work lives. The section block in the SKILL's "What goes in a constitution" is your starting shape; fill what fits, drop what doesn't.
+Create the constitution as a markdown file with `status: active` in YAML frontmatter (that's what the launcher checks; it accepts `open` or `active`, with `active` as the convention). Some workflows expect a specific path so a runner picks it up — e.g. `/lc-from-paper` writes `constitution.md` at the reproduction workdir root. Otherwise put it wherever the work lives. The section block in the SKILL's "What goes in a constitution" is your starting shape; fill what fits, drop what doesn't.
 
 Use the crafting process from [`crafting.md`](crafting.md):
 

{lightcone_cli-0.4.1 → lightcone_cli-0.4.2}/pyproject.toml

@@ -63,9 +63,11 @@ dev = [
 ]
 docs = [
     "zensical>=0.0.33",
+    # squidfunk's mike fork — required by zensical's versioning provider.
+    # Not on PyPI; install from git.
+    "mike @ git+https://github.com/squidfunk/mike.git ; python_version >= '3.10'",
 ]
 
-
 [project.scripts]
 lc = "lightcone.cli:main"