Symptom
A root astra.yaml that composes sub-analyses via analyses: {part: {path: sub}} — the ASTRA idiom for a parent that synthesizes its parts — cannot run lc status / lc materialize at all, even when the root's own outputs are flat and buildable:
Error: output id 'part.number' contains a dot, so the manifest beside it could not be told from the output's own name.
Minimal repro (lc 0.5.0rc2): root repo; sub/astra.yaml with one metric output number; root spec with one data input bound to sub/results/baseline/number.json, one flat root output overview consuming it, one re-export reexport: {from: part.number}, and analyses: {part: {path: sub}}. astra validate passes; lc status and lc materialize --check at the root refuse with the error above; lc inside sub/ works.
Why it matters
The natural shape for a reproduction + extension + synthesis (this came up building exactly that) is one analysis whose parent owns the overview figure/table computed from its sub-analyses' outputs. Today the parent can declare those outputs (re-exports) and claim them (findings), but cannot execute them — the recipe has to be pushed down into an artificial third sub-analysis, purely because of artifact naming.
Mechanism
Outputs land at results/<universe>/<id>.<format> with .<id>.manifest.json beside them, and the id is recovered by splitting the filename on the first dot; the merged tree qualifies sub outputs as <sub>.<output>, and planning at the root merges the whole tree with no "root-scope only" mode.
Suggested fixes (either would do)
- Plan only root-scope outputs when invoked at the root (sub-analyses stay executed from their own directories, as now), so a parent with flat recipes just works; or
- A per-scope results layout for nested ids (
results/<universe>/<sub>/<id>.<format>), which would also open the door to materializing a whole tree from the root.
Related guidance gap (skill side): LightconeResearch/agent-skills#37.
Symptom
A root
astra.yamlthat composes sub-analyses viaanalyses: {part: {path: sub}}— the ASTRA idiom for a parent that synthesizes its parts — cannot runlc status/lc materializeat all, even when the root's own outputs are flat and buildable:Minimal repro (lc 0.5.0rc2): root repo;
sub/astra.yamlwith one metric outputnumber; root spec with one data input bound tosub/results/baseline/number.json, one flat root outputoverviewconsuming it, one re-exportreexport: {from: part.number}, andanalyses: {part: {path: sub}}.astra validatepasses;lc statusandlc materialize --checkat the root refuse with the error above;lcinsidesub/works.Why it matters
The natural shape for a reproduction + extension + synthesis (this came up building exactly that) is one analysis whose parent owns the overview figure/table computed from its sub-analyses' outputs. Today the parent can declare those outputs (re-exports) and claim them (findings), but cannot execute them — the recipe has to be pushed down into an artificial third sub-analysis, purely because of artifact naming.
Mechanism
Outputs land at
results/<universe>/<id>.<format>with.<id>.manifest.jsonbeside them, and the id is recovered by splitting the filename on the first dot; the merged tree qualifies sub outputs as<sub>.<output>, and planning at the root merges the whole tree with no "root-scope only" mode.Suggested fixes (either would do)
results/<universe>/<sub>/<id>.<format>), which would also open the door to materializing a whole tree from the root.Related guidance gap (skill side): LightconeResearch/agent-skills#37.