ci.yml:570 is a 4000-char single line every test-adding PR must edit — 3 of 3 conflicts today were that one line #3313

Measurement

Three PRs could not be updated onto main today. All three conflicted on the same single line: .github/workflows/ci.yml:570.

Line 570 is a single ~4000-character string holding all 38 explicit --test targets as one chain:

bash -c 'cargo test -p aprender-core --features setfit --lib setfit && cargo test -p ... && ... && cargo test -p aprender-compute --test registry_case_table'

Every PR that adds a test target must edit that one line. Two such PRs always collide — the serial fraction on the merge path is 1 for anything touching the CI test list, exactly the property #3297 removed from docs/roadmaps/roadmap.yaml. Nobody removed it here.

It compounds: a new tests/*.rs file is dark until it is added to that line (CLAUDE.md says so explicitly), so the file every new test target must touch is also the file most likely to conflict. #3311 found 355 tests dark for exactly this reason, and adding them meant editing line 570 again.

Why the resolution is mechanical, and why that is the point

Every one of these conflicts was append-vs-append. The resolution is the union with main's order authoritative — no judgement, no intent to weigh. A conflict whose resolution is always the same is a merge driver nobody wrote (the phrasing #3256 used for the .jsonl ledgers).

Fix

Make the list a sequence, not a string, so git can merge it line-by-line:

- name: explicit test targets
  run: |
    cargo test -p aprender-core --features setfit --lib setfit
    cargo test -p aprender-core --test monorepo_invariants
    ...

One target per line. Two PRs appending different targets then merge with no conflict at all — the same shape as the fragments fix, applied to the CI list instead of the roadmap.

Two details the change must preserve:

• && chaining is fail-fast; a run: block under shell: bash is -e, which is also fail-fast. Equivalent, but it must be an explicit shell: bash or a set -e — the GitHub default shell has no pipefail and the semantics must not silently loosen (this repo has been bitten by that).
• Line 531 already carries a comment saying an investigation ranked collapsing these into one bash -c. That decision was about job startup cost, not about the merge path, and the cost is unchanged by splitting one string across lines inside the same step.

Resolved under this diagnosis

#3134, #3245, #3248 pushed out of CONFLICTING by taking the union. Each merge commit records that nothing was removed on either side.

Refs #3297, #3308, #3311