[calvin-archastro]

Review on ArchCode

Problem and author intent

A test fixture that runs aster on a temp workspace from inside a target (nested aster) failed //calc:lint and //calc:test in 0 ms in firstlanding CI on 0.29.0. Intent: nested runs work whatever HOME or job count the nested process has.

Failure story:

1. Outer aster admits target //:nested and exports ASTER_EXECUTION_CONTEXT (family dir under <host dir>/family-*).
2. The target runs aster run ... with a different HOME (the e2e contract sandbox sets one). No ASTER_EXECUTION_DIR is set in CI, so the default $HOME/.cache/aster/execution-v1 is recomputed.
3. Host::configured() finds the inherited family's parent differs from that directory and bails with nested execution cannot change ASTER_EXECUTION_DIR.
4. runner.rs turns that into a failure for every target, duration_ms: 0, Execution admission: .... Reproduced with --json on the nested run.

Same class: a nested ASTER_JOBS/--jobs differing from the active capacity hit the "host execution capacity is N while another invocation is active" error, although a nested run never takes a slot.

What changed

• src/executor/admission.rs: parse the inherited context first. When present, the host directory is family.directory.parent() (authoritative), ignoring the nested process's HOME and ASTER_EXECUTION_DIR. A requested job count only conflicts for non-nested invocations.
• README ("Concurrency across local workspaces"): states the rule replacing "nested callers must retain the same execution directory".
• Test: tests/execution_capacity.rs::nested_workspace_with_its_own_home_and_jobs_runs_its_targets.

Unchanged: nesting still borrows the ancestor's slot, resource ordering rules, cancellation.

Scope

Backend only (executor admission).

Risk

Low. Only the nested path changes (when ASTER_EXECUTION_CONTEXT is set). Fresh invocations are unchanged. A forged/stale context still fails on the owner-lock check in acquire.

User impact

Nested aster in sandboxed HOME works instead of failing in 0 ms. Other ASTER_* vars (report dir, remote cache, run id) were checked as the original hypothesis but were not the cause; no change to them.

Testing

• Canonical e2e: tests/execution_capacity.rs::nested_workspace_with_its_own_home_and_jobs_runs_its_targets. Real CLI binary, outer aster runs a target that execs the same binary on a second workspace with another HOME and ASTER_JOBS; asserts both nested targets pass. Fails on main with the 0 ms error, passes now.
• Integration matrix covered: nested with different HOME + different jobs. Same HOME is covered by existing nested tests. Not covered: remote cache/report vars (not involved).
• cargo fmt, cargo clippy --all-targets -- -D warnings, cargo test all pass locally. CI: .github/workflows/ci.yml on PRs.

Follow-ups

• firstlanding's fixture workaround (drop ASTER_*, trivial lint target) can be reverted after this is released.
• Nested runs still serialize on the single borrow lock (existing design).

🤖 Generated with Claude Code