PyPI - lightcone-cli - Versions diffs - 0.3.5__tar.gz → 0.3.7__tar.gz - Mend

lightcone-cli 0.3.5tar.gz → 0.3.7tar.gz

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.

Files changed (69) hide show

{lightcone_cli-0.3.5 → lightcone_cli-0.3.7}/PKG-INFO RENAMED Viewed

@@ -1,12 +1,26 @@
 Metadata-Version: 2.4
 Name: lightcone-cli
-Version: 0.3.5
+Version: 0.3.7
 Summary: Lightcone command-line toolchain
 Author: Lightcone Research
 License: BSD-3-Clause
 License-File: LICENSE
+Classifier: Development Status :: 4 - Beta
+Classifier: Environment :: Console
+Classifier: Intended Audience :: Science/Research
+Classifier: License :: OSI Approved :: BSD License
+Classifier: Operating System :: OS Independent
+Classifier: Programming Language :: Python
+Classifier: Programming Language :: Python :: 3 :: Only
+Classifier: Programming Language :: Python :: 3.11
+Classifier: Programming Language :: Python :: 3.12
+Classifier: Programming Language :: Python :: 3.13
+Classifier: Programming Language :: Python :: 3.14
+Classifier: Topic :: Scientific/Engineering
+Classifier: Topic :: Scientific/Engineering :: Artificial Intelligence
+Classifier: Topic :: Scientific/Engineering :: Human Machine Interfaces
 Requires-Python: >=3.11
-Requires-Dist: astra-tools>=0.2.5
+Requires-Dist: astra-tools>=0.2.10
 Requires-Dist: click>=8.0
 Requires-Dist: dask>=2024.1
 Requires-Dist: distributed>=2024.1
@@ -21,10 +35,10 @@ Description-Content-Type: text/markdown
 # lightcone-cli
-[![License](https://img.shields.io/badge/License-BSD_3--Clause-blue.svg)](https://opensource.org/licenses/BSD-3-Clause)
-[![Python](https://img.shields.io/pypi/pyversions/lightcone-cli)](https://pypi.org/project/lightcone-cli/)
-[![Tests](https://github.com/LightconeResearch/lightcone-cli/actions/workflows/tests.yml/badge.svg)](https://github.com/LightconeResearch/lightcone-cli/actions/workflows/tests.yml)
-[![PyPI](https://img.shields.io/pypi/v/lightcone-cli)](https://pypi.org/project/lightcone-cli/)
+[![License](https://img.shields.io/badge/License-BSD_3--Clause-426b78.svg?style=flat)](https://opensource.org/licenses/BSD-3-Clause)
+[![Python](https://img.shields.io/badge/python-3.11%20%7C%203.12%20%7C%203.13-4e5a70?style=flat)](https://pypi.org/project/lightcone-cli/)
+[![PyPI](https://img.shields.io/pypi/v/lightcone-cli?style=flat&color=f8f7f3)](https://pypi.org/project/lightcone-cli/)
+[![Tests](https://img.shields.io/github/actions/workflow/status/LightconeResearch/lightcone-cli/tests.yml?style=flat&color=darkgreen)](https://github.com/LightconeResearch/lightcone-cli/actions/workflows/tests.yml)
 <!-- [![Ruff](https://img.shields.io/endpoint?url=https://raw.githubusercontent.com/astral-sh/ruff/main/assets/badge/v2.json)](https://github.com/astral-sh/ruff) -->

{lightcone_cli-0.3.5 → lightcone_cli-0.3.7}/README.md RENAMED Viewed

@@ -1,9 +1,9 @@
 # lightcone-cli
-[![License](https://img.shields.io/badge/License-BSD_3--Clause-blue.svg)](https://opensource.org/licenses/BSD-3-Clause)
-[![Python](https://img.shields.io/pypi/pyversions/lightcone-cli)](https://pypi.org/project/lightcone-cli/)
-[![Tests](https://github.com/LightconeResearch/lightcone-cli/actions/workflows/tests.yml/badge.svg)](https://github.com/LightconeResearch/lightcone-cli/actions/workflows/tests.yml)
-[![PyPI](https://img.shields.io/pypi/v/lightcone-cli)](https://pypi.org/project/lightcone-cli/)
+[![License](https://img.shields.io/badge/License-BSD_3--Clause-426b78.svg?style=flat)](https://opensource.org/licenses/BSD-3-Clause)
+[![Python](https://img.shields.io/badge/python-3.11%20%7C%203.12%20%7C%203.13-4e5a70?style=flat)](https://pypi.org/project/lightcone-cli/)
+[![PyPI](https://img.shields.io/pypi/v/lightcone-cli?style=flat&color=f8f7f3)](https://pypi.org/project/lightcone-cli/)
+[![Tests](https://img.shields.io/github/actions/workflow/status/LightconeResearch/lightcone-cli/tests.yml?style=flat&color=darkgreen)](https://github.com/LightconeResearch/lightcone-cli/actions/workflows/tests.yml)
 <!-- [![Ruff](https://img.shields.io/endpoint?url=https://raw.githubusercontent.com/astral-sh/ruff/main/assets/badge/v2.json)](https://github.com/astral-sh/ruff) -->

{lightcone_cli-0.3.5 → lightcone_cli-0.3.7}/claude/lightcone/skills/README.md RENAMED Viewed

@@ -18,7 +18,7 @@ Not direct entry points — Claude invokes these (or other skills invoke them) t
 | Skill | Role |
 |---|---|
-| `astra` | Reference for the `astra.yaml` spec: structure, decisions, options, prior insights, findings, evidence, sub-analyses, narrative anchors, composition mechanics. |
+| `astra` | Reference for the `astra.yaml` spec: structure, decisions, options, prior insights, findings, evidence, sub-analyses, composition mechanics. |
 | `lc-cli` | Reference for `lc` workflow: commands, the Spec-Code Invariant, status interpretation, failure diagnosis, multiverse runs, WRROC export. |
 ## Paper-reproduction bundle
@@ -29,7 +29,6 @@ A self-contained toolkit for reproducing published papers in ASTRA. The bundle i
 |---|---|
 | [`lc-from-paper`](lc-from-paper/SKILL.md) | **Reproduction driver.** ORIENT-first; one pre-loop phase in the user's main session that asks for the paper, runs `/paper-extraction` inline, interviews the user (grounded in the paper), clones the reference code and runs `/lc-from-code` scan-only (when a repo exists), and drafts the per-paper `constitution.md` + `CLAUDE.md`. Then hands off to a ralph loop whose iterations carry the long middle: ARCHITECT → SPECIFY → LITERATURE → IMPLEMENT → RUN → COMPARE. When the loop closes (constitution `status: closed` after COMPARE returns `pass`), REVIEW runs back in the user's main session. Fidelity intent — captured as prose at ORIENT — is what every iteration reads when sizing its next move, and what COMPARE grades opportunities against. |
 | [`ralph`](ralph/SKILL.md) | The loop substrate. `lc-from-paper`'s ORIENT invokes `/ralph`'s Authoring mode to draft the per-paper constitution; the loop launcher hands off after ORIENT lands. Each iteration runs `/ralph`'s Loop protocol against the constitution. |
-| [`narrative`](narrative/SKILL.md) | Author the `narrative:` prose and decision `rationale:` in `astra.yaml`. Invoked by `lc-from-paper`'s ARCHITECT (for the structural narrative) and SPECIFY (for anchored content narrative). |
 | [`paper-extraction`](paper-extraction/SKILL.md) | Turn an arXiv ID or DOI into a standardized `work/reference/` directory: structural index (figures, tables, outline, citations with resolved DOIs) plus a stub `astra.yaml` for the paper. Primary acquisition path for `lc-from-paper`'s ORIENT (Stage 2); also invoked per cited paper by LITERATURE. |
 | [`check-sentence-by-sentence`](check-sentence-by-sentence/SKILL.md) | Audit paper claims against code locations (`file:line` or `NOT FOUND`). Invoked from `lc-from-paper`'s REVIEW close-out (opt-in); also user-invokable directly. |
 | [`figure-comparison`](figure-comparison/SKILL.md) | Build a self-contained HTML side-by-side: original figures/tables/numerics vs replicated. Invoked from `lc-from-paper`'s REVIEW close-out (mandatory); also user-invokable directly. |

{lightcone_cli-0.3.5 → lightcone_cli-0.3.7}/claude/lightcone/skills/astra/SKILL.md RENAMED Viewed

@@ -3,8 +3,8 @@ name: astra
 description: >
   Comprehensive reference for the `astra.yaml` specification — top-level
   structure, sub-analyses, inputs/outputs, decisions and options, prior
-  insights and findings, evidence and quote verification, narrative
-  anchors, and composition mechanics. Invoke whenever reading, writing,
+  insights and findings, evidence and quote verification, and
+  composition mechanics. Invoke whenever reading, writing,
   validating, or debugging an `astra.yaml` spec; whenever working with
   decisions, options, prior_insights, findings, or evidence; or whenever
   the user asks about ASTRA schema, spec syntax, or sub-analysis
@@ -22,13 +22,13 @@ An `astra.yaml` spec captures this for a single unit of work. The structure is *
 ## astra.yaml Structure
-Fields: `id`, `version`, `name`, `narrative`, `authors`, `tags`, `inputs`, `outputs`, `decisions`, `prior_insights`, `findings`, `analyses`, `container`. `narrative` is the analysis-level prose field -- see [Narrative](#narrative) (typically filled in later, once the structural pieces have settled).
+Fields: `id`, `version`, `name`, `description`, `tags`, `inputs`, `outputs`, `decisions`, `prior_insights`, `findings`, `analyses`, `container`. `description` is the analysis-level free-prose field -- see [Description](#description) (the same optional field every element carries).
-**Reserved IDs.** No analysis entity (input, output, decision, option, finding, prior insight, evidence, sub-analysis) may use any of these names as its `id` -- they collide with the narrative anchor grammar:
+**Reserved IDs.** No analysis entity (input, output, decision, option, finding, prior insight, evidence, sub-analysis) may use any of these names as its `id` -- they collide with the tree-path reference grammar (used by `from:`, `when`, `requires`, and `incompatible_with`):
 ```
 inputs   outputs   decisions   findings   prior_insights
-analyses options   content     narrative
+analyses options   content
 ```
 **`label` field.** Inputs, Outputs, Decisions, Options, and Insights all accept an optional `label:` -- a short human-readable name for compact rendering (margin glyphs, breadcrumbs, card titles). Tooling falls back to `id` when absent. `label` is required only on Options.
@@ -37,7 +37,7 @@ analyses options   content     narrative
 # Simple analysis -- everything at top level
 version: "1.0"
 name: "My Analysis"
-# narrative: { ... }  # see Narrative section; typically added later
+# description: "One-paragraph orientation (optional)"  # see Description section
 inputs:
   - id: training_data
     type: data
@@ -351,46 +351,21 @@ decisions:
 The **`universe:` field** in universe files selects which sub-analysis universe to load: `build_mocks: { universe: baseline }` loads `./analyses/build_mocks/universes/baseline.yaml`.
-## Narrative
+## Description
-`narrative` is the analysis-level prose field on any Analysis (root or sub). It's structured as five Markdown sections: `summary`, `findings`, `methods`, `inputs`, `outputs`. The schema is closed (`additionalProperties: false`) -- no other keys are allowed.
+`description` is a single optional free-prose field on any Analysis (root or sub) -- the same field every other element carries (`Input`, `Output`, `Option`, `Universe`). It holds a short human orientation to the analysis (a paragraph or two), nothing more.
-**Recommendation:** fill `narrative` in *later*, once the structural pieces of the analysis (decisions, outputs, sub-analyses) have settled. Prose written too early goes stale fast and tends to describe what no longer exists. Per-element prose (what each Input, Output, Decision, Option, or Insight is and why) belongs on the elements themselves via `description`/`rationale`/`notes` -- those can be written from day one.
-**Conditional coverage.** All five sections are schema-optional, but `astra validate` enforces:
-| Section | Required when |
-|---|---|
-| `findings` | the analysis has entries under `findings:` |
-| `methods` | the analysis has entries under `decisions:` or `analyses:` |
-| `inputs` | the analysis has entries under `inputs:` |
-| `outputs` | the analysis has entries under `outputs:` |
-| `summary` | always optional |
-Authors narrate what they declare; stub analyses with only a summary stay clean.
-**Anchor references.** Inside any section, link to other elements with Markdown anchor links (`[text](#path.to.element)`) using the same tree-path grammar as `from:` -- `#decisions.scaling`, `#decisions.scaling.options.standard`, `#findings.best_model`, `#analyses.preprocessing` (whole sub-analysis), `#analyses.preprocessing.outputs.features` (element inside a sub-analysis), `#../decisions.method` to escape to a parent scope.
-**Inline images.** Standard Markdown image syntax inside any section -- `![alt](path/to/img.png)` for repo-relative paths or `![alt](https://...)` for URLs. Renderers like lightcone-ui pick them up the same way they pick up text.
+Per-element prose (what each Input, Output, Decision, Option, or Insight is and why) belongs on the elements themselves via `description`/`rationale`/`notes` -- those can be written from day one. The analysis-level `description` can be filled in at any time and is safe to leave short.
 ```yaml
-narrative:
-  summary: |
-    A two-stage pipeline for Iris classification that demonstrates
-    sub-analyses.
-  methods: |
-    The [feature_extraction sub-analysis](#analyses.feature_extraction)
-    produces encoded features, which feed
-    [classification](#analyses.classification). A
-    [test_split](#decisions.test_split) decision controls the holdout.
-  inputs: |
-    [iris_data](#inputs.iris_data) is Fisher's 150-sample, 4-feature,
-    3-class dataset.
-  outputs: |
-    The top level exposes [accuracy](#outputs.accuracy) and a
-    [pipeline_summary](#outputs.pipeline_summary) report.
+description: |
+  A two-stage pipeline for Iris classification that demonstrates
+  sub-analyses: a feature-extraction stage feeds a classification
+  stage. The top level exposes the classifier accuracy and a
+  pipeline-summary report.
 ```
 ## CLI Reference (astra)
 ```bash

{lightcone_cli-0.3.5 → lightcone_cli-0.3.7}/claude/lightcone/skills/check-sentence-by-sentence/SKILL.md RENAMED Viewed

@@ -149,9 +149,10 @@ PROCEDURE
    or generic framing -- skip it.
 3. Before searching, **read `astra.yaml` once** -- it is a pre-built
    paper↔code map maintained by the project. Harvest specifically:
-     - `narrative.methods` — links paper methodology concepts to decision
-       IDs (e.g. paper prose "the chosen <method>" → `#decisions.<id>`)
-     - `narrative.findings` — links paper claims/values to result anchors
+     - `decisions` — each decision's `label` / `rationale` links paper
+       methodology concepts to a decision ID (e.g. paper prose "the chosen
+       <method>" → `decisions.<id>`)
+     - `findings` — links paper claims/values to result entries
      - `prior_insights` (if present) — extracted paper quotes already tied
        to decisions
      - per-decision `evidence` quotes and `description` fields

{lightcone_cli-0.3.5 → lightcone_cli-0.3.7}/claude/lightcone/skills/figure-comparison/SKILL.md RENAMED Viewed

@@ -93,8 +93,8 @@ Read, in this order:
    - If neither file exists, use the default paper-driven flow below and
      build a best-effort report from `astra.yaml` plus `work/reference/`.
-2. **`astra.yaml`** -- specifically `narrative.summary`, `narrative.outputs`,
-   `narrative.findings`, `outputs:`, and `findings:` if present. Use it to
+2. **`astra.yaml`** -- specifically the top-level `description`, `outputs:`,
+   and `findings:` if present. Use it to
    map scoped targets to output IDs and to harvest declared findings. Do not
    assume ASTRA outputs have a dedicated filename-hint field; result paths
    come from the output ID and the result resolver in Phase 2.
@@ -200,7 +200,7 @@ paper asserts and the project tracks. Concretely, harvest from:
   reported sample size after a specific cut, every bin width or step
   used as a result-defining choice, every reported accuracy / score /
   metric.
-- Any explicit reproduction targets in `astra.yaml`'s `narrative.findings`.
+- Any explicit reproduction targets in `astra.yaml`'s `findings:`.
 It is fine to repeat one quantity in multiple manifest entries when the
 paper reports it under different conditions (preliminary vs. final,

{lightcone_cli-0.3.5 → lightcone_cli-0.3.7}/claude/lightcone/skills/lc-from-code/SKILL.md RENAMED Viewed

@@ -61,7 +61,7 @@ When the codebase is large enough that one Explore pass risks missing depth (a m
 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.
-In augment mode, preserve the existing paper-derived or user-derived `inputs`, `outputs`, `decisions`, `findings`, and `narrative` 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.
+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.
 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:

{lightcone_cli-0.3.5 → lightcone_cli-0.3.7}/claude/lightcone/skills/lc-from-paper/SKILL.md RENAMED Viewed

@@ -36,8 +36,8 @@ Eight phases (zero-indexed). ORIENT runs before the loop, in the user's main ses
 | # | Phase | Where it runs | Reference | Primary outputs |
 |---|---|---|---|---|
 | 0 | ORIENT | user's main session | [`references/orient.md`](references/orient.md) | per-paper `constitution.md` + `CLAUDE.md` + paper substrate at `work/reference/{paper.pdf, source/ or document.md, figures/, tables/, index.json, astra.yaml}` (from inline `/paper-extraction`) + code substrate at `work/reference/{code/, code-status.yaml, code-index.md}` (from inline `/lc-from-code` scan-only, when a repo exists) |
-| 1 | ARCHITECT | ralph iteration | [`references/architect.md`](references/architect.md) | stub `astra.yaml` at project root (sub-analyses, inputs, outputs, narrative) |
-| 2 | SPECIFY | ralph iteration | [`references/specify.md`](references/specify.md) | filled `astra.yaml` (`decisions:`, `findings:`, `prior_insights:` placeholders, anchored narrative); `targets/targets.md`; `implementation-notes.md`; `universes/baseline.yaml` |
+| 1 | ARCHITECT | ralph iteration | [`references/architect.md`](references/architect.md) | stub `astra.yaml` at project root (sub-analyses, inputs, outputs, per-analysis `description`) |
+| 2 | SPECIFY | ralph iteration | [`references/specify.md`](references/specify.md) | filled `astra.yaml` (`decisions:`, `findings:`, `prior_insights:` placeholders); `targets/targets.md`; `implementation-notes.md`; `universes/baseline.yaml` |
 | 3 | LITERATURE | ralph iteration | [`references/literature.md`](references/literature.md) | `astra.yaml`'s `prior_insights:` Evidence entries each carry resolved `quote:` + `location:` selectors; per-paper PDFs cached via `astra paper add` |
 | 4 | IMPLEMENT | ralph iteration | [`references/implement.md`](references/implement.md) | `scripts/`, `requirements.txt`, recipes in `astra.yaml` |
 | 5 | RUN | ralph iteration | [`references/run.md`](references/run.md) | `results/<universe>/<output>/` |

{lightcone_cli-0.3.5 → lightcone_cli-0.3.7}/claude/lightcone/skills/lc-from-paper/references/architect.md RENAMED Viewed

@@ -1,6 +1,6 @@
 # ARCHITECT — write the stub `astra.yaml`
-ARCHITECT is the structural seam: decide the sub-analysis decomposition, wire the inputs and outputs at the sub-analysis level, and author high-level narrative prose for each analysis — all in one stub `astra.yaml`. SPECIFY then fills the stub with `decisions:`, `prior_insights:`, `findings:`, and `astra-anchor:` references. Splitting **structure** from **content** keeps each iteration's cognitive load manageable: ARCHITECT decides *what the analyses are*; SPECIFY decides *what's inside each one*.
+ARCHITECT is the structural seam: decide the sub-analysis decomposition, wire the inputs and outputs at the sub-analysis level, and author a short `description:` for each analysis — all in one stub `astra.yaml`. SPECIFY then fills the stub with `decisions:`, `prior_insights:`, and `findings:`. Splitting **structure** from **content** keeps each iteration's cognitive load manageable: ARCHITECT decides *what the analyses are*; SPECIFY decides *what's inside each one*.
 ARCHITECT is what a ralph iteration does when the workdir signals "ORIENT substrate present + project-root `astra.yaml` absent (or empty stub)." The heavy work of *understanding* the paper and code happened in `/paper-extraction` and `/lc-from-code`'s scan-only branch — both invoked inline during ORIENT in the user's main session. Their on-disk substrate (the structural `index.json`, the paper-extraction `astra.yaml`, the `code-index.md`) is what you read on entry. No persistent expert sub-agents; targeted reads against the substrate carry the orientation.
@@ -9,7 +9,7 @@ ARCHITECT is what a ralph iteration does when the workdir signals "ORIENT substr
 - `constitution.md` — Goal, Fidelity intent, Scope, Quality bar. Read first; the Goal's intended replication targets fence what `outputs:` belong in the stub.
 - `CLAUDE.md` — auto-loaded; Rules + accumulators (still empty at this point).
 - `work/reference/index.json` — paper-side structural index from `/paper-extraction` (figures, tables, section outline with line numbers, citations with resolved DOIs).
-- `work/reference/astra.yaml` — paper-extraction's ASTRA-shape stub of the paper itself: id, name, `narrative.summary` (from abstract), optionally `findings:` (paper's claimed numerical results).
+- `work/reference/astra.yaml` — paper-extraction's ASTRA-shape stub of the paper itself: id, name, `description` (from abstract), optionally `findings:` (paper's claimed numerical results).
 - `work/reference/code-index.md` — code-side inventory from `/lc-from-code`'s scan: script inventory, candidate decisions with `file:line` refs, module map, entry-points, external data dependencies, container hints.
 - `work/reference/source/` (Path A) or `work/reference/document.md` (Path B) — paper text. Grep into for specific facts; do not re-read whole.
 - `work/reference/code/` (when present) — the cloned reference code. Read targeted modules when `code-index.md` doesn't answer a structural question.
@@ -17,7 +17,7 @@ ARCHITECT is what a ralph iteration does when the workdir signals "ORIENT substr
 ## Outputs
-- `astra.yaml` at the project root — **stub form**: sub-analyses named, architecture wired (inputs / outputs declared at the sub-analysis level), high-level `narrative:` prose blocks per analysis. **No `decisions:`, `prior_insights:`, `findings:`, or `astra-anchor:` references yet** — those entries don't exist for the narrative to reference.
+- `astra.yaml` at the project root — **stub form**: sub-analyses named, architecture wired (inputs / outputs declared at the sub-analysis level), a short `description:` per analysis. **No `decisions:`, `prior_insights:`, or `findings:` yet** — those entries are SPECIFY's.
 - `constitution.md` updates: Open dimensions, when something material surfaces that warrants user ratification at REVIEW.
 ## Step 1 — Read the substrate, then write the stub
@@ -27,32 +27,29 @@ Read `constitution.md`, `CLAUDE.md`, `work/reference/index.json`, `work/referenc
 ### What to do
 1. **Reconcile sub-analysis decompositions.** Read `code-index.md`'s natural-decomposition section and `index.json`'s section outline. Where paper and code agree on a stage, use that name (noun-phrase, e.g. `reconstruction`). Where they disagree, **code's structure is canonical for stage boundaries** — the paper compresses; the code reveals the actual decomposition. Where code is absent or thin, follow the paper alone. Where module boundaries are genuinely ambiguous, read the relevant modules under `work/reference/code/` to settle it.
-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`, `narrative`.
+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.
-4. **Author the root and per-analysis narrative.** Invoke `/narrative` for prose authoring (it carries the discipline on reserved names, voice, the data-flow paragraph requirement). High-level prose only — **no `astra-anchor:` references yet**, because the entries those would point at don't exist. SPECIFY will weave in anchors as it authors `decisions:` / `prior_insights:` / `findings:` per sub-analysis. The root `narrative:` MUST include a top-down end-to-end data-flow paragraph (per the narrative skill's data-flow rules) when sub-analyses exist.
-5. **Validate.** `astra validate astra.yaml` must return clean — even with empty `decisions:` / `prior_insights:` / `findings:` blocks, the structural fields and narrative prose must pass schema checks.
+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.
 ### Stub shape — what `astra.yaml` looks like after ARCHITECT
 ```yaml
-# Stub: structure + narrative. SPECIFY fills decisions/findings/prior_insights and weaves astra-anchor references into the narrative.
+# Stub: structure + descriptions. SPECIFY fills decisions/findings/prior_insights.
 id: <paper-slug>
 title: "<paper title>"
 doi: <doi>
-narrative:
-  summary: |
-    <high-level paragraph for the root analysis>
-  methods: |
-    <data-flow paragraph; required when sub-analyses exist>
+description: |
+  <high-level paragraph for the root analysis; sketch the end-to-end
+  data flow across sub-analyses when they exist>
 analyses:
   <sub-analysis-id-1>:
-    narrative:
-      summary: |
-        <prose for this sub-analysis>
+    description: |
+      <short paragraph orienting a reader on this sub-analysis>
     inputs:
       <input-id>:
         <stable name; depth lives in SPECIFY>
@@ -74,9 +71,9 @@ analyses:
 - **Stub, not snapshot.** Don't try to author content for `decisions:`, `prior_insights:`, `findings:`. Those go in SPECIFY. Your job is the structural skeleton.
 - **Reserved names.** Sub-analysis IDs are noun phrases; avoid the reserved set. Each ID must be unique across the spec.
-- **Code-as-canonical for structure.** Where paper and code disagree on the decomposition, the code's structure is canonical (the paper compresses for narrative; the code reveals real seams).
+- **Code-as-canonical for structure.** Where paper and code disagree on the decomposition, the code's structure is canonical (the paper compresses; the code reveals real seams).
 - **Targeted scope wins.** `constitution.md`'s Scope fences the reproduction. If the user only wants Figures 3–4 plus Table 2, only those land as `outputs:`.
-- **Narrative prose, no anchors.** Author `narrative:` prose at root and per-sub-analysis levels. Do NOT add `astra-anchor:` references — the entries those would point at don't exist yet.
+- **Short descriptions, high-level only.** Author a `description:` at root and per-sub-analysis levels. Keep it orienting; per-decision / per-finding prose lives on those entries in SPECIFY.
 - **Validate before exit.** `astra validate astra.yaml` must return clean.
 - **Targeted reads, not whole-paper absorption.** The indices give you most of what you need; reach into the source / document / code for specific items, not as a default.
@@ -84,15 +81,15 @@ After the stub is written and validates, commit it (`architect: stub astra.yaml`
 ## Reviewing prior ARCHITECT work as part of survey
-There is no separate review phase. Every iteration that enters and finds an ARCHITECT stub on disk reads it critically before doing anything else. If you see real issues — wrong sub-analysis decomposition, reserved-name collision, missing in-scope output, narrative gap — fix them inline, commit (`architect: fix <what>`), and exit. Only when a fresh-context read finds nothing to fix does the iteration move on to SPECIFY work. The fresh-context property at iteration boundaries makes the next iteration the review; nothing else is needed.
+There is no separate review phase. Every iteration that enters and finds an ARCHITECT stub on disk reads it critically before doing anything else. If you see real issues — wrong sub-analysis decomposition, reserved-name collision, missing in-scope output, a `description` gap — fix them inline, commit (`architect: fix <what>`), and exit. Only when a fresh-context read finds nothing to fix does the iteration move on to SPECIFY work. The fresh-context property at iteration boundaries makes the next iteration the review; nothing else is needed.
 What to look at:
 1. **Sub-analysis decomposition.** Right cuts? Consistent with `code-index.md`? Defensible against the paper where the paper compresses?
-2. **Sub-analysis IDs.** Noun phrases. No reserved-name collisions (`inputs`, `outputs`, `decisions`, `findings`, `prior_insights`, `analyses`, `options`, `content`, `narrative`).
+2. **Sub-analysis IDs.** Noun phrases. No reserved-name collisions (`inputs`, `outputs`, `decisions`, `findings`, `prior_insights`, `analyses`, `options`, `content`).
 3. **Inputs at sub-analysis level.** Each input has a stable id; the data dependency is real (cross-check against `code-index.md`'s External-data-dependencies and the paper's data section).
 4. **Outputs at sub-analysis level.** Each output corresponds to a result locus from `index.json` OR an intermediate artifact a downstream sub-analysis consumes. Targeted scope from `constitution.md`'s Scope is honored — no out-of-scope outputs sneaking in, no in-scope targets missed.
-5. **Narrative coverage.** Root narrative includes a data-flow paragraph (when sub-analyses exist). Each sub-analysis's narrative accurately describes its role. No `astra-anchor:` references at this stage.
+5. **Description coverage.** Root `description` sketches the end-to-end data flow (when sub-analyses exist). Each sub-analysis's `description` accurately describes its role.
 6. **Validates.** `astra validate astra.yaml` returns clean.
 Don't flag empty `decisions:` / `prior_insights:` / `findings:` — that's SPECIFY's territory. Don't re-read the entire paper or code; use the indices and targeted reads. If you see the same artifact getting churned across many recent commits without convergence, log the situation to `open-questions.md` and advance the phase anyway.
@@ -101,12 +98,12 @@ Don't flag empty `decisions:` / `prior_insights:` / `findings:` — that's SPECI
 - `work/reference/index.json` + `work/reference/astra.yaml` + `work/reference/code-index.md` (when code present) exist ⇒ ORIENT substrate is ready
 - `astra.yaml` at project root absent (or present-but-empty) ⇒ this iteration writes the stub
-- `astra.yaml` exists with stub form (sub-analyses + inputs + outputs + narrative populated; `decisions:` / `prior_insights:` / `findings:` blocks present-and-empty) ⇒ ARCHITECT's output is on disk; read it critically. Fix anything wrong; otherwise the iteration moves on to SPECIFY.
+- `astra.yaml` exists with stub form (sub-analyses + inputs + outputs + per-analysis `description` populated; `decisions:` / `prior_insights:` / `findings:` blocks present-and-empty) ⇒ ARCHITECT's output is on disk; read it critically. Fix anything wrong; otherwise the iteration moves on to SPECIFY.
 ## Notes
 - **No persistent expert sub-agents.** The on-disk substrate (`index.json`, `code-index.md`, the paper-extraction `astra.yaml`) carries the orientation iterations need; re-read what you need on entry.
 - **The stub's empty blocks are intentional.** `decisions: {}`, `prior_insights: {}`, `findings: {}` make it clear at a glance that ARCHITECT's job is structural and SPECIFY fills them. Don't try to half-author content — empty is honest.
-- **Code-as-canonical for structure, paper-as-canonical for narrative voice.** The code reveals where the real stage boundaries are; the paper provides the words to describe them. The stub uses both.
-- **The narrative skill is the prose author, not the structure author.** Invoke `/narrative` for the prose blocks; ARCHITECT's job is the structural skeleton plus invoking `/narrative` to fill the `narrative:` keys cleanly.
+- **Code-as-canonical for structure, paper-as-canonical for wording.** The code reveals where the real stage boundaries are; the paper provides the words to describe them. The stub uses both.
+- **Descriptions are orienting, not exhaustive.** ARCHITECT's `description:` blocks give a reader the shape of each analysis; the detailed prose (decision `rationale:`, finding `notes:`) lands on those entries in SPECIFY.
 - **Commit each artifact as it lands.** The stub commits when it lands; each subsequent fix pass commits separately. Small, descriptive commits keep `git log` legible to the next iteration.

{lightcone_cli-0.3.5 → lightcone_cli-0.3.7}/claude/lightcone/skills/lc-from-paper/references/implement.md RENAMED Viewed

@@ -6,7 +6,7 @@ IMPLEMENT is what a ralph iteration does when the workdir signals "SPECIFY done
 ## Inputs
-- `astra.yaml` — the filled spec (sub-analyses, decisions, prior_insights, findings, narrative — all populated by SPECIFY)
+- `astra.yaml` — the filled spec (sub-analyses, decisions, prior_insights, findings — all populated by SPECIFY; per-analysis `description` from ARCHITECT)
 - `implementation-notes.md` — tricky algorithms, numerical gotchas, data-format quirks
 - `work/reference/index.json` — paper-side structural index (figures, tables, outline, citations); useful when the spec compresses or you need to find where in the paper a behavior is described.
 - `work/reference/code-index.md` (when code present) — code inventory: module map, candidate decisions with file:line, entry-points, data dependencies, gotchas (the canonical map of where each sub-analysis's logic lives in `work/reference/code/`).
@@ -54,7 +54,7 @@ The iteration merges scripts and recipes after the per-output sub-agents finish.
 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.
-3. **Add recipes** to each output in `astra.yaml` with `command:` and `inputs:` (dependencies). Recipe inputs use the same `<analysis>.<output>` form the narrative skill's data-flow rules require.
+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`.
 6. **Validate** with `astra validate astra.yaml` after adding recipes.

{lightcone_cli-0.3.5 → lightcone_cli-0.3.7}/claude/lightcone/skills/lc-from-paper/references/specify.md RENAMED Viewed

@@ -1,6 +1,6 @@
 # SPECIFY — fill the stub `astra.yaml`, two passes per sub-analysis
-Read the stub `astra.yaml` from ARCHITECT and fill in `decisions:`, `prior_insights:`, `findings:` per sub-analysis, weaving the existing narrative with `astra-anchor:` references as entries land. SPECIFY is the **first material-disagreement seam** — paper-vs-code conflicts surface here, and they're often the highest-value moments for the user to weigh in on at REVIEW.
+Read the stub `astra.yaml` from ARCHITECT and fill in `decisions:`, `prior_insights:`, `findings:` per sub-analysis. SPECIFY is the **first material-disagreement seam** — paper-vs-code conflicts surface here, and they're often the highest-value moments for the user to weigh in on at REVIEW.
 SPECIFY is what a ralph iteration does when the workdir signals "stub `astra.yaml` present + sub-analyses' `decisions:` / `prior_insights:` / `findings:` blocks still empty." Iterations run detached in tmux; the user isn't reachable interactively, so the canonical-resolution default (code wins where paper and code disagree on a material choice) applies and disagreements are logged to CLAUDE.md's **Paper-vs-code disagreements** section plus `open-questions.md` for REVIEW close-out.
@@ -10,7 +10,7 @@ Per-sub-analysis work is parallelizable when sub-analyses are independent. Each
 ## Inputs
-- `astra.yaml` — the stub from ARCHITECT (sub-analyses, inputs, outputs, narrative; empty `decisions:` / `prior_insights:` / `findings:` blocks)
+- `astra.yaml` — the stub from ARCHITECT (sub-analyses, inputs, outputs, per-analysis `description`; empty `decisions:` / `prior_insights:` / `findings:` blocks)
 - `constitution.md` — Goal (scope), Fidelity intent, Quality bar
 - `CLAUDE.md` — Rules; **Paper-vs-code disagreements** for prior-iteration entries
 - `work/reference/index.json` — paper-extraction's structural index: figures, tables, section outline, citations. The `citations:` block maps each cited paper's BibTeX key (Path A) or synthetic `<lastname>_<year>` key (Path B) to `{locations, citation, doi}`. SPECIFY uses this to write each `prior_insights:` placeholder's `doi:` so LITERATURE knows which paper to fetch.
@@ -22,18 +22,18 @@ Per-sub-analysis work is parallelizable when sub-analyses are independent. Each
 ## Outputs
-- `astra.yaml` — **filled form**: each sub-analysis's `decisions:` populated with decision-level `rationale:` prose plus options (the paper's choice is identified by `default:`); `findings:` populated as full `Insight` blocks with paper-anchored `evidence:` (the target paper's DOI + `quote: {exact, prefix, suffix}` + `location: {page: N}`); `prior_insights:` populated as citation **placeholders** — each a syntactically-complete `Insight` (`id`, `claim`, `created_at`, `evidence: [{id, doi}]`) whose placeholder Evidence carries the cited paper's DOI looked up from `work/reference/index.json#citations[<cite-key>].doi` **but no `quote:` selector yet** — LITERATURE fills those in. Each option that draws on a placeholder cites it via `Option.insights: [<insight_id>, ...]` (the back-reference that links options to prior_insights in the ASTRA grammar). `narrative:` keys updated to weave `astra-anchor:` references into prose as entries land. `astra validate astra.yaml` returns clean (Evidence with `doi:` and no `quote:` is structurally valid at this stage); `astra validate astra.yaml --verify-evidence` runs after LITERATURE has authored the quotes.
+- `astra.yaml` — **filled form**: each sub-analysis's `decisions:` populated with decision-level `rationale:` prose plus options (the paper's choice is identified by `default:`); `findings:` populated as full `Insight` blocks with paper-anchored `evidence:` (the target paper's DOI + `quote: {exact, prefix, suffix}` + `location: {page: N}`); `prior_insights:` populated as citation **placeholders** — each a syntactically-complete `Insight` (`id`, `claim`, `created_at`, `evidence: [{id, doi}]`) whose placeholder Evidence carries the cited paper's DOI looked up from `work/reference/index.json#citations[<cite-key>].doi` **but no `quote:` selector yet** — LITERATURE fills those in. Each option that draws on a placeholder cites it via `Option.insights: [<insight_id>, ...]` (the back-reference that links options to prior_insights in the ASTRA grammar). `astra validate astra.yaml` returns clean (Evidence with `doi:` and no `quote:` is structurally valid at this stage); `astra validate astra.yaml --verify-evidence` runs after LITERATURE has authored the quotes.
 - `universes/baseline.yaml` — selects the paper's choices (where paper and code disagree per the canonical-resolution rule, see "Material conflicts" below)
 - `implementation-notes.md` — concise practical guidance for the IMPLEMENT phase: tricky algorithms, numerical gotchas, data-format quirks, things the spec can't capture. Bullets, not essays.
 - `targets/targets.md` — small target ledger COMPARE consumes: per output (already declared by ARCHITECT), a brief entry with type, priority, paper value, expected match criteria, and the path to the reference figure / table / metric (when applicable, copy the reference file into `targets/` so the directory is self-contained)
 - `CLAUDE.md` updates — append entries to **Paper-vs-code disagreements** for each material conflict surfaced
 - `constitution.md` updates — Open dimensions when something material warrants user ratification at REVIEW
-## Substrate skills to invoke
+## Prose discipline
-- **`/narrative`** — narrative authoring (any of the five `narrative.{summary,inputs,methods,findings,outputs}` keys, plus decision `rationale:` fields) is owned by the narrative skill. Invoke it during the **paper pass** when authoring or extending narrative prose. The narrative skill teaches reserved entity names, the tree-path anchor grammar, the conditional-narrative requirement (which keys are required when), the five-key authoring order, paper-reproduction fidelity discipline, and the new downstream-consumer discipline (lightcone-cli#108). Do not duplicate that content.
+Per-element prose lives directly on the entries SPECIFY authors: each decision's `rationale:` carries the paper's stated reasoning (or the code's, where canonical-resolution applies); findings and prior_insights carry their `claim:` and optional `notes:`. Keep the paper's hedges and qualifiers intact and don't add editorial commentary beyond what the paper supports.
-Your responsibility in this phase is the **content**: build out the `decisions:` / `prior_insights:` / `findings:` for each sub-analysis (each with its own evidence shape — detailed below), and weave `astra-anchor:` references back into the narrative as entries land. ARCHITECT already settled the structure.
+Your responsibility in this phase is the **content**: build out the `decisions:` / `prior_insights:` / `findings:` for each sub-analysis (each with its own evidence shape — detailed below). ARCHITECT already settled the structure and the orienting `description:` blocks.
 ## The two-pass-per-sub-analysis structure
@@ -46,7 +46,7 @@ Read the paper's section(s) covering this sub-analysis. Author:
 1. **`decisions:`** — every choice in this sub-analysis where a different defensible option could plausibly shift a numerical result: algorithmic methods, thresholds, statistical approaches, data selection criteria, calibration choices. Use `when`, `incompatible_with`, and `requires` constraints for non-independent decisions.
    For each decision, the paper-pass authors:
-   - **Decision-level fields:** `label:` (short human-readable name), `rationale:` (the paper's stated reasoning — use `/narrative` for the prose), `default:` (the option the paper actually selects), and `options:` (the map of option entries below).
+   - **Decision-level fields:** `label:` (short human-readable name), `rationale:` (the paper's stated reasoning, authored as prose), `default:` (the option the paper actually selects), and `options:` (the map of option entries below).
    - **Options:** the chosen option plus any sibling alternatives the paper discusses. Each option carries `label:` (required) and an optional `description:`. Per the 0.0.10 grammar, options do **not** carry their own `rationale:` or `evidence:` block — the decision's `rationale:` covers the reasoning; paper-text evidence flows through `findings:` (for the paper's own quantitative claims) or via `Option.insights` back-references into `prior_insights:` (for citation-backed support).
    - **Option ↔ prior_insights linkage:** when the option's support derives from cited literature, list the relevant `prior_insights:` ids in `Option.insights: [<insight_id>, ...]`. The placeholder block under `prior_insights:` (authored in step 2 below) is the back-end of this link — LITERATURE fills in the verbatim cited-paper quote later. **Scope rules** (astra-tools ≥ 0.2.9): bare ids resolve **node-locally only** — the prior_insight must be declared in the same sub-analysis as the option. For a citation declared at an ancestor scope, use explicit upward refs: `[../id]` for the parent, `[../../id]` for the grandparent, etc. (same `../` grammar as `Input.from` and `Decision.from`). The natural shape — declare each cited paper at the sub-analysis that uses it, reference with a bare id from same-scope options — keeps everything node-local and needs no `../`.
@@ -56,7 +56,7 @@ Read the paper's section(s) covering this sub-analysis. Author:
    decisions:
      <decision_id>:
        label: "<short human-readable name>"
-       rationale: "<the paper's stated reasoning, weaving astra-anchors into prose>"
+       rationale: "<the paper's stated reasoning, as prose>"
        default: <chosen_option_id>
        options:
          <option_id>:
@@ -101,9 +101,7 @@ Read the paper's section(s) covering this sub-analysis. Author:
            location: { page: <N> }
    ```
-4. **Weave `astra-anchor:` references into the existing narrative.** ARCHITECT wrote `narrative:` prose without anchors because the entries didn't exist. Now they do — extend the narrative to point at the new `decisions:` / `prior_insights:` / `findings:` entries via the tree-path anchor grammar. Use `/narrative` for this pass; it carries the discipline.
-5. **Verify finding quotes against the paper source by Grep.** For each `findings:` Evidence entry with a `quote:`, Grep the paper source to confirm the `exact:` text is verbatim and the `prefix:` / `suffix:` are real surrounding text. `astra validate --verify-evidence` will run the deterministic check across every quote later (after LITERATURE resolves the `prior_insights:` placeholders); a manual Grep now catches typos and paraphrases before the code pass.
+4. **Verify finding quotes against the paper source by Grep.** For each `findings:` Evidence entry with a `quote:`, Grep the paper source to confirm the `exact:` text is verbatim and the `prefix:` / `suffix:` are real surrounding text. `astra validate --verify-evidence` will run the deterministic check across every quote later (after LITERATURE resolves the `prior_insights:` placeholders); a manual Grep now catches typos and paraphrases before the code pass.
 ### Pass B — code pass (when `work/reference/code/` exists)
@@ -132,9 +130,8 @@ The cross-check questions on entry: are the decisions covering everything materi
 3. **Evidence verification.** Every `findings:` Evidence entry uses `TextQuoteSelector` with a verbatim `exact:` quote, real surrounding-text `prefix:` / `suffix:`, and a `location: {page: N}` (1-indexed). Quotes that are paraphrased or whose `prefix:` / `suffix:` are editorial parentheticals will fail `--verify-evidence`. `prior_insights:` placeholders intentionally have `evidence: [{id, doi}]` without a `quote:` at this stage — LITERATURE authors the quotes — so do not flag a missing quote on placeholder entries. After LITERATURE resolves the placeholders, run `astra validate astra.yaml --verify-evidence`.
 4. **Findings traceability.** Each `findings:` Insight's `evidence:` resolves either to a real paper claim (target-paper DOI + verbatim `quote:` + page) or to a real declared output via `artifact: <output_id>` (with optional `source_commit:` and `snapshot:`).
 5. **Material-disagreement surfacing.** Where paper and code disagree on a material choice, the spec records both options under the relevant `decisions:` entry, `universes/baseline.yaml` selects the code's option (canonical-resolution default), and the conflict is appended to CLAUDE.md's *Paper-vs-code disagreements* section plus `open-questions.md` for the user to resolve at REVIEW close-out. Flag any material disagreement that got silently dropped, that didn't make it into the disagreements log, or where the baseline picked the paper without the canonical-resolution rule applying.
-6. **Narrative anchors.** The sub-analysis's `narrative:` weaves `astra-anchor:` references to the new `decisions:` / `prior_insights:` / `findings:` entries — the tree-path grammar must be valid, and entries actually exist at the referenced paths.
-7. **`narrative:` voice fidelity.** Hedges and qualifiers from the paper survive (per the narrative skill's discipline). Editorial commentary added beyond what the paper supports gets flagged.
-8. **No synthetic data.** Unless the paper itself uses synthetic data, every input has a real acquisition source — no mock / synthetic substitutes anywhere in the sub-analysis's inputs, decisions, or implementation-notes.
+6. **Prose voice fidelity.** Hedges and qualifiers from the paper survive in the decisions' `rationale:` and the findings' `claim:` / `notes:`. Editorial commentary added beyond what the paper supports gets flagged.
+7. **No synthetic data.** Unless the paper itself uses synthetic data, every input has a real acquisition source — no mock / synthetic substitutes anywhere in the sub-analysis's inputs, decisions, or implementation-notes.
 Apply fixes inline as you find them — `astra.yaml`, `universes/baseline.yaml`, `implementation-notes.md`, the disagreements log in CLAUDE.md as needed. The diff against the prior commit is the record of what changed. After any change to `astra.yaml`:
@@ -175,11 +172,11 @@ Out-of-scope targets stay in `targets/targets.md` with an explicit reason and sh
 - **Equation and section numbers must match the rendered paper / PDF**, not a naïve count of TeX blocks or markdown headings. When citing "eq. N" or "§N", find the equation or heading by content in the rendered paper and use the printed number.
 - **Validate** with `astra validate astra.yaml` after each pass.
 - **Targeted reads, not whole-paper absorption.** Use `work/reference/index.json` and `work/reference/code-index.md` for structural lookups; Grep into `work/reference/source/` (Path A) or `work/reference/document.md` (Path B) for specific verbatim quotes; read targeted code modules under `work/reference/code/` for canonical method details. Don't re-read the whole paper or whole code base.
-- **The narrative skill is the prose author, not the structure author.** SPECIFY weaves anchors into the prose ARCHITECT wrote — the structural surface is fixed, the anchored references are SPECIFY's contribution.
+- **Content correctness, not structure.** ARCHITECT settled the structure and the orienting `description:` blocks; SPECIFY's contribution is the `decisions:` / `prior_insights:` / `findings:` content and the prose on those entries.
 ## Survey signals (entry into SPECIFY)
-- `astra.yaml` exists with stub form (sub-analyses + inputs + outputs + narrative; empty decisions / prior_insights / findings) ⇒ ready to specify
+- `astra.yaml` exists with stub form (sub-analyses + inputs + outputs + per-analysis `description`; empty decisions / prior_insights / findings) ⇒ ready to specify
 - For each sub-analysis: `decisions:` populated with decision-level `rationale:` + options (paper's choice at `default:`); `findings:` populated as full Insight blocks with paper-anchored Evidence (DOI + `quote: {exact, prefix, suffix}` + `location: {page}`); `prior_insights:` populated as citation placeholders (`id`, `claim`, `created_at`, `evidence: [{id, doi}]` with `quote:` omitted — LITERATURE fills the quotes next); `Option.insights` back-references wired up where options draw on placeholders ⇒ paper pass done
 - For each sub-analysis: when `work/reference/code/` exists, code-pass material-disagreement entries land in `decisions:` (with both options) and `universes/baseline.yaml` selects the canonical-resolution choice; `implementation-notes.md` carries non-material gotchas ⇒ code pass done
 - For each sub-analysis: a fresh-context iteration reads the slice and finds nothing to fix ⇒ that sub-analysis is done; the next iteration moves on
@@ -191,7 +188,7 @@ Out-of-scope targets stay in `targets/targets.md` with an explicit reason and sh
 ## Notes
 - **Material disagreements** are appended to CLAUDE.md's **Paper-vs-code disagreements** section AND `open-questions.md`. CLAUDE.md is the at-a-glance summary every iteration sees; `open-questions.md` is the user-resolution accumulator. Both lead to the same place: the user resolves at REVIEW close-out.
-- **The narrative skill is the prose author, not the structure author.** SPECIFY's job is content correctness; `/narrative` invocation comes during the paper pass when authoring or extending the narrative prose to weave in anchor references.
+- **SPECIFY owns content, not structure.** Its job is content correctness — the `decisions:` / `prior_insights:` / `findings:` and the `rationale:` / `claim:` / `notes:` prose on them. The orienting `description:` blocks were ARCHITECT's; the structural surface is fixed.
 - **The target ledger is a derivation, not a separate phase's output.** Treat `targets/targets.md` as a small index produced alongside the filled `astra.yaml`, not a heavyweight artifact. The depth lives in `astra.yaml`'s `outputs:` / `findings:` / `decisions:`.
 - **Two-pass discipline is the cross-check.** Skipping the code pass (when code exists) loses the canonical-resolution surface and lets paper-vs-code material disagreements slip through. The fresh-context review can recover *some* of these but not all — the disciplined sequence (paper → code → review) catches more.
 - **Per-sub-analysis parallelism is opt-in.** When sub-analyses are independent (no shared decision blocks, no cross-sub-analysis findings), the iteration can fan out one-level-deep sub-agents (one per sub-analysis from inside its main session) to run their passes in parallel. When they share material decisions or findings (rare), serialize across iterations.

{lightcone_cli-0.3.5 → lightcone_cli-0.3.7}/claude/lightcone/skills/lc-new/SKILL.md RENAMED Viewed

@@ -25,7 +25,7 @@ Then sharpen:
 - "What would a clear answer look like?" (sharpens the description)
 - "Why does this matter?" (context for decisions)
-**Update astra.yaml** — set `name`. (`astra init` scaffolded a placeholder example decision/input/output plus a TODO `narrative` skeleton; the placeholder structure is replaced in Phases 2–3, and narrative prose is filled in Finalize once structure has settled — written too early it goes stale.)
+**Update astra.yaml** — set `name`. (`astra init` scaffolded a placeholder example decision/input/output plus a TODO `description`; the placeholder structure is replaced in Phases 2–3, and the `description` is filled in Finalize once structure has settled — written too early it goes stale.)
 ---
@@ -115,9 +115,9 @@ astra universe generate -n baseline
 Generate only `baseline` unless the user explicitly asks for additional universes.
-### Populate Narrative
+### Populate Description
-Replace the TODO entries in `astra.yaml`'s `narrative:` block now that structure is stable: `summary` (one-paragraph framing), `methods` (decisions and sub-analyses), `inputs`, `outputs`. Use `#path.to.element` anchors for cross-references. Leave `findings` as TODO until results exist.
+Replace the TODO `description:` in `astra.yaml` with a short one-or-two-paragraph orientation now that structure is stable — what the analysis is and how its pieces fit together. Keep it brief; per-element prose lives on each Input/Output/Decision/Option via `description`/`rationale`.
 ### Populate CLAUDE.md

lightcone-cli 0.3.5__tar.gz → 0.3.7__tar.gz

lightcone-cli 0.3.5tar.gz → 0.3.7tar.gz