[calvin-archastro]

Review on ArchCode

Problem and author intent

firstlanding's PR CI runs aster affected test-ci --related --matrix in a detect job, then every test job runs aster affected test-ci --related --lane=X again. Each of about 29 test jobs spends 25 to 33 s in the same --related analysis before its first target. That's about 248 vCPU × 25 s per PR run.

The goal: test jobs reuse the detect job's plan when nothing that affects the plan changed, and fall back to fresh analysis otherwise. A second goal is to show where affected's planning time goes.

What changed

1. Plan replay.
   • --matrix and --dry-run take --plan-out FILE. It writes every lane's plan, the selected projects and command overrides.
   • affected --lane X --plan-in FILE uses the stored plan when the key matches and the lane is present.
   • Otherwise it prints one [aster] --plan-in FILE: <reason>; analysing instead line and analyses as before.
   • The key covers:
     • base and head SHAs, mode, the requested target and flags, and the Aster version;
     • a content digest of the changed files;
     • a digest of the dirty tree, with .aster/ excluded;
     • a projects digest: each target's command and depends_on, each project's config content, and the root aster.toml.
   • Code: src/cli/plan_replay.rs.
2. Phase timings (src/cli/phases.rs). affected prints one stderr line, for example: [aster] affected phases: discover 1.1s, changes 0.6s, plan-in 0.0s, graph 0.0s, related 22.3s, select 0.2s, narrow 0.1s, quarantine 0.3s, total 24.6s.
   • --quiet suppresses it.
   • A replayed run is marked (replayed plan).
3. Docs: the README, docs/ci/github-actions.md (detect job and test job wiring) and skills.md.

Unchanged: without --plan-in, affected behaves exactly as before.

Scope and risk

CLI only. Medium risk, because a stale replay would run the wrong tests. Three things limit that:

• The key is broad: changed-file content, the dirty tree, and project and lane config.
• Any mismatch falls back to fresh analysis.
• Review found that editing aster.toml replayed an old lane. That's fixed and pinned by an_edited_lane_config_is_not_replayed_even_with_a_pinned_head.

User impact

Two new opt-in flags and one timing line on stderr.

Testing

• Canonical end-to-end proof: a_lane_runs_from_the_plan_exactly_as_the_analysis_runs_it in tests/plan_replay.rs. It runs the real aster binary against a git fixture:
  • It writes the plan with --matrix --plan-out, then runs a lane with --plan-in.
  • It asserts the replay runs the same targets as fresh analysis.
• Fallback tests in the same file, one per key field: base, head, mode, changed files, Aster version, a missing lane, a missing or unreadable file, and an_edited_lane_config_is_not_replayed_even_with_a_pinned_head.
• every_run_of_affected_reports_where_its_time_went covers the timing line.
• Additions in tests/related.rs.
• On firstlanding, with a release build, 3 historical bases × 5 lanes:
  • all 15 replayed plans equal fresh analysis after sorting;
  • fresh analysis took 5.6 to 15.7 s and replay 0.8 to 1.6 s.
• The CONTRIBUTING checks pass: cargo fmt --check, clippy -D warnings, cargo doc -D warnings, and cargo test --all-targets --all-features.
• Not proven here: a real CI run. That needs this release plus the firstlanding workflow change.

Follow-ups

• After release, firstlanding bumps ASTER_VERSION and passes --plan-out in the detect job and --plan-in in the test jobs.
• Merge order: independent of the scheduling PR. Both touch src/git/affected.rs and tests/related.rs, so whichever merges second may need a rebase.

🤖 Generated with Claude Code

[calvin-archastro]

ArchDev is watching this pull request. State: settled (cycle 1 of 1 for head 9b06d12).

when	trigger	decision	result
2026-11-11T00:52:02.959Z	verify head	enqueue job_bcfe467e59e95b34bab0c104	no change

Paused by the no-autofix label or a draft; never resolves reviewer threads. Jobs: job_bcfe467e59e95b34bab0c104.