Compact singleton arrays in the crate

[EiffL]

Summary

• CI has been red on every branch since 2026-09-16: roc-validator 0.11.4 adds RO-Crate 1.1's recommendation that a property with one value be a plain value, not a one-element array. The crate had four such singletons (the root's author, the workflow's input, each action's result), and the crate smoke test refuses any failure beyond its recorded floor. CI resolves the validator fresh on every run since the lock is not committed, which is how the release reached it.
• The serialization in engine/crate.py now compacts every one-element array to its value. One place rather than each builder: the arrays come from three builders, and which of them hold one element depends on the project (one output, one author). It is the rule rocrate already applies to @context.
• The new requirement was inserted as number 24, so the two affiliation checks the floor pins moved from 29.2/29.3 to 30.2/30.3. Those ids belong to a validator version, so the dev dependency now requires 0.11.4 and the floor names the new ids. The floor is still five entries.
• A new test pins that no entity in the rendered document carries a one-element array. docs/api/crate.md records the rule.

Test plan

• LC_CRATE_TESTS_REQUIRED=1 uv run pytest tests/test_crate.py tests/test_crate_smoke.py against roc-validator 0.11.4 (23 passed; REQUIRED clean, RECOMMENDED within the floor)
• Full suite excluding the container smoke tests (617 passed)
• uv run ruff check src/ tests/, uv run mypy src/

🤖 Generated with Claude Code

[EiffL]

LGTM

[github-actions]

✅ Eval

Metric	Value
Outputs check	success
Agent run	success
Turns	36
Tool calls	33
Cost	$0.67
Agent wall time	3m06s
Model	claude-sonnet-5

lc status

  mode:    direct
  sandbox: landlock (fs: declared, network: allowed)
  crate:   up to date with the outputs

  · current  baseline/best_fit        cb0298a
  · current  baseline/hubble_diagram  cb0298a
  · current  baseline/residuals       cb0298a

3 current

Confusion & pain points (Claude analysis)

Confusion & pain points

• No spec examples surfaced up front: the agent had to reverse-engineer the dataset's column semantics (redshift cuts, error-model column) by piping the raw data file through several rounds of awk/sort probes rather than finding this documented anywhere in astra.yaml's comments or a data dictionary — a data/README.md describing column layout (not just the annex/pointer mechanics) would have saved several exploratory bash calls.
• Recipe/output contract had to be learned by trial via astra-tools spec: the agent ran uvx astra-tools@0.2.17 spec output and spec recipe mid-task to learn the format:/placeholder grammar ({output}, {inputs.*}, {decisions.*}) instead of this being front-loaded by the astra:astra skill invocation — suggests the skill's initial load didn't include enough of the recipe/output grammar to avoid a second lookup.
• Manual sanity-checking outside the materialize pipeline: the agent ran lc run python scripts/fit.py ... and the two plotting scripts by hand against /tmp paths to validate correctness before trusting lc materialize, then had to remember to rm -f the scratch outputs before committing — a byproduct of there being no lighter-weight "dry run a recipe" verb, forcing ad hoc use of the probe verb (lc run) with manually-chosen /tmp output paths.
• Otherwise the run was clean: spec validation, lc materialize, lc materialize --check, and astra validate all passed on the first real attempt with no failed commands or dead ends.

Full trace: agent-trace artifact on this run.