A sub-analysis's declared `source:` resolves against the project root, not its own analysis root

[EiffL]

Updated: this was written while #199 gave external sub-analyses their own results trees. That was removed before merge — lc now materializes a flat analysis only (#202). The question below stands for whenever nesting lands.

A declared input's source: is resolved against the project root, wherever it is declared:

elif declared.source:
    paths[declared.id] = root / declared.source

So a sub-analysis at analyses/hod/ cannot name a file beside its own astra.yaml — source: ../data/catalog.txt, the spelling someone editing analyses/hod/astra.yaml would reach for, resolves outside the repository and fails:

fatal: ../data/catalog.txt: '../data/catalog.txt' is outside repository

Writing source: data/catalog.txt works, because it is resolved against the project root.

Why this is a question, not just a bug

Two defensible readings, and the choice is ASTRA's before it is lc's:

1. Relative to the declaring analysis — source: means "relative to the astra.yaml that declares it", which is how a reader of analyses/hod/astra.yaml would read it, and what makes such a directory genuinely portable.
2. Relative to the project (today) — source: is a project-level address, so a sub-analysis names shared data the same way its parent does, and one input is one path however deep it is declared.

The schema says only "URI or path to the data source", so it does not settle it. Whichever way it lands, the answer belongs in astra-spec first, since every runner has to agree.

Note the readings are not equivalent for ..: the first makes escaping the project easy to write by accident.

Notes

Pre-existing. Blocked in practice by #202 — there is nothing to resolve a sub-analysis source: for until nested specs are buildable.