Remove ASTRA narrative field from skills; bump astra-tools to 0.2.10 (#156)

ASTRA's `narrative` field has been removed from the spec ([astra-spec
RFC-0002](https://github.com/LightconeResearch/astra-spec/blob/main/rfcs/0002-decouple-reports.md))
— replaced by a single optional `description` on any Analysis, with rich
write-ups now authored as **external reports** that reference analysis
elements by their tree-path. This brings the skill bundle in line.

## Dependency
- `astra-tools>=0.2.5` → **`>=0.2.10`** (the release that requires
`astra-spec>=0.0.11`, the narrative-free schema).

## Skills
- **Deleted the `narrative` skill** (`SKILL.md` + references) and every
pointer to it: docs mirror (`docs/skills/narrative.md`), `zensical.toml`
nav, README/index rows, CLAUDE.md bundle note. The paper-reproduction
bundle is now **five skills (four siblings)**.
- **`astra`** (spec reference): dropped `narrative`/`authors` from the
field list, removed `narrative` from the reserved-ID set, and replaced
the `## Narrative` section with a `## Description` + element-addressing
section.
- **`lc-new`**: "Populate Narrative" → "Populate Description".
- **`lc-from-paper`** (SKILL + `architect`/`specify`/`implement`
references): ARCHITECT authors a short per-analysis `description` (no
five-section narrative, no `astra-anchor:` weaving); SPECIFY drops the
`/narrative` substrate invocation and authors
`rationale:`/`claim:`/`notes:` directly on entries.
- **`paper-extraction`**: the `extract-paper-substrate.py` script now
emits a top-level `description:` (from the abstract) instead of
`narrative.summary`, and no longer emits a `narrative.findings`
cross-link; the SKILL prose and the example YAML are aligned (example
bumped to 0.0.11).
- **`figure-comparison`, `lc-from-code`, `check-sentence-by-sentence`**:
source `description`/`findings:` per-element fields instead of
`narrative.*`.
- **docs/user**: FINALIZE authors a `description:`.

Remaining uses of the word "narrative" are general-English
(constitution/report writing, console output) — not the ASTRA field.

## Verification
- `uv run pytest` → **335 passed**
- The paper-extraction example and the script's generated stub both
**validate against astra-spec 0.0.11**
- No new ruff findings (CI lints `src/ tests/`; the skill script is out
of scope); no dangling links to the removed skill

🤖 Generated with [Claude Code](https://claude.com/claude-code)

---------

Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Author: EiffL

CLAUDE.md

@@ -70,7 +70,7 @@ claude/lightcone/           # Claude plugin source — force-included into the w
 ├── skills/                 # lc-new, lc-from-code, lc-from-paper,
 │                            # lc-feedback, ralph;
 │                            # paper-reproduction bundle: lc-from-paper (entry),
-│                            # ralph (loop substrate), narrative,
+│                            # ralph (loop substrate),
 │                            # paper-extraction, figure-comparison,
 │                            # check-sentence-by-sentence
 │                            # (see skills/README.md for the full bundle map)

claude/lightcone/skills/README.md

@@ -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. |

claude/lightcone/skills/astra/SKILL.md

@@ -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

claude/lightcone/skills/check-sentence-by-sentence/SKILL.md

@@ -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

claude/lightcone/skills/figure-comparison/SKILL.md

@@ -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,

claude/lightcone/skills/lc-from-code/SKILL.md

@@ -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:
 

claude/lightcone/skills/lc-from-paper/SKILL.md

@@ -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>/` |