chore(make): one drift guard per line, and refuse an empty entry (backend#2626)

[LukasWodka]

Part of tracebloc/backend#2626

DRIFT_GUARDS is one |-separated line, so it conflicted every time two branches each added a guard — three times on client#911 in a single day.

The obvious claim is false, and I checked rather than asserting it

One-guard-per-line does not make those appends auto-merge. Appending requires editing the previous last line to add its |\ continuation, so both sides still touch the same line and git still conflicts. Measured both ways on the real 38-entry list:

layout	conflict hunk	longest line in it
one line (develop today)	5 lines	1842 characters
one guard per line	5 lines	30 characters

So what changes is whether the conflict can be resolved by reading it. At 1842 characters, finding which guard each side added means diffing two long strings by eye — and the resolution that looks right in a diff viewer is "take one side", which silently deletes the other branch's gate. A required check stops existing and every run still reports green, which is this file's own subject.

This buys legibility at the moment of highest risk, not automation. The Makefile comment says exactly that rather than the tidier version.

It also closes a fail-open the new layout makes easy to type

A || in the middle of the list yields an empty entry. sh -c "" exits 0 and ran still increments, so the count check passes and the run reports green with one of its guards being the empty string. Measured before the fix:

$ make drift DRIFT_GUARDS=true||true
drift: all 3 guards green          # exit 0

A trailing | was already caught — the for drops a trailing empty field, so ran falls short of exp — which is why only the middle case needed a new guard. Entries are also trimmed, so a whitespace-only entry is refused too, and ==> lines no longer carry the leading space Make's continuations insert.

The recipe's guards were asserted by a comment

That's the part worth having. The three fail-open protections in the drift recipe were documented in prose and had been found by hand twice — #755's quote-collapse, and this doubled-| case. New: scripts/tests/drift-list-integrity.bats, 8 cases.

Every case drives make drift itself with a crafted list rather than re-implementing the splitting logic, so a copy of the rule cannot go on passing while the recipe drifts. It also fails closed if the committed list ever shrinks below 20 entries — otherwise the crafted cases would stay green while make drift gated almost nothing.

Mutation-proved — each of the four refusals is independently load-bearing:

mutation	tests passing
empty-entry guard removed	6 of 8 (the || and whitespace cases)
the trim removed	7 of 8
the count check removed	7 of 8
the empty-list check removed	7 of 8
restored	8 of 8

Not done, and named in the Makefile

Deriving the list from scripts/tests/*.sh would remove the conflict entirely and make an added guard file auto-merge — and it would stop the list being a second source of truth about which files are drift guards.

It is left out because it changes which scripts run: a new .sh in that directory never meant as a drift guard would start gating merges. That needs its own change and its own opt-out list, and I would rather propose it than smuggle it in here.

Test plan

• make drift — 38/38 guards green
• CI=true bats scripts/tests/*.bats — 1603 passing, 0 failures (was 1595; +8)
• bats-hygiene green — every assertion in the new file is || return 1 hardened
• shellcheck -S warning -x -s bash clean on the new file
• scripts/gen-manifest.sh --check clean
• The four pre-existing refusals re-verified by hand: empty list, trailing |, doubled |, and a quote-containing guard that must not collapse the list

Makefile + one new test file only — no chart content, so no version bump.

🤖 Generated with Claude Code

---

Note

Low Risk
Changes only Makefile drift orchestration and new unit tests; no chart, auth, or runtime behavior.

Overview
Reformats DRIFT_GUARDS in the Makefile to one guard per line (with |\ continuations) so merge conflicts show a short differing line instead of a ~1800-character single line—reducing the risk of resolving conflicts by taking one side and silently dropping a guard. The drift recipe now trims each entry (Make continuation spaces) and fails on empty or whitespace-only entries, closing a fail-open where || or | | made sh -c "" count as a passing guard while the run still reported green.

Adds scripts/tests/drift-list-integrity.bats: eight Bats cases that invoke make drift with crafted lists (empty list, trailing |, doubled |, quotes, etc.) plus a floor that the committed list has at least 20 guards—machine-checking protections that were previously only documented in comments.

^{Reviewed by Cursor Bugbot for commit 26a68e4. Bugbot is set up for automated code reviews on this repo. Configure here.}

[LukasWodka]

Demoted with evidence, then hardened anyway.

It does not reproduce

The claim is that GNU Make 4.x renders an exported simply-expanded variable as export DRIFT_GUARDS :=, so a ^DRIFT_GUARDS := matcher misses on Ubuntu CI and the floor never counts entries.

Measured: this suite passed on Ubuntu CI as written — bats (bash unit, mocked) = SUCCESS on the exact platform named. Make records the assignment and the export directive as separate lines in -p output, so the matcher hit. And a miss would have failed closed ([ -n "$line" ] || return 1), not passed silently.

But the dependency was real, so it's gone

The matcher was depending on which of two shapes a given Make emits. Local make here is 3.81, CI's is 4.x, and the test should not care. One alternation removes it: ^(export )?DRIFT_GUARDS[[:space:]]*:?=.

The part that would genuinely have stayed uncovered is the other branch. The committed-list assertion can only ever exercise the shape this Make emits, so the alternative would have been untested until a Make upgrade made it live — which is the gap the finding was pointing at even though its stated failure was wrong. There's now a test driving all four forms directly (export/no-export × :=/=), plus a control that a line merely mentioning the name is not an assignment.

Mutation-proved:

mutation	result
the optional export prefix dropped	8 of 9 — the reported shape
the matcher made over-broad (drops the = requirement)	8 of 9 — the control bites
restored	9 of 9

Also on this PR

The PATH persist — ubuntu:24.04 leg failed once and passed on re-run — 6 of 7 matrix legs were green first time and the same leg passes on client#911 and client#922, so it was a flake, not this change. Recorded rather than quietly re-run.

make drift 38/38 · bats-hygiene green · shellcheck -S warning -x clean · manifest --check clean.

[LukasWodka]

bugbot run

[LukasWodka]

bugbot run

[LukasWodka]

Built on 5bf6002 rather than beside it — a co-driver and I fixed this same finding on this branch simultaneously, and theirs got there first. Its one-matcher-two-callers shape is kept; this is the delta.

The count made the strip untestable

awk -F'|' NF returns the same number whether or not the assignment prefix was removed, because a leftover prefix just rides along inside field 1. Measured on 5bf6002 itself: narrowing the sed to ^DRIFT_GUARDS := left all nine cases green. So the half of the matcher this finding was actually about — handling both shapes Make can print — was still only half covered.

The function returns the value now; callers count; the shape case asserts it byte-exact, which is the only thing a wrong strip changes.

The rename exposed a vacuous control, and that's the part worth reading

The control was:

! printf '%s\n' "#   DRIFT_GUARDS is documented above" | drift_guards_entries

Renaming the function left that line pointing at nothing — ! missing_command is non-zero, ! inverts it, and the control went on passing while exercising nothing at all. My first attempt to fix it made it worse: routing through bash -c to capture the status, where a bats-defined function is invisible, so every run was 127.

It now asserts the function exists (type -t) and then that it refuses, so "it refused" can never be satisfied by "it is gone".

Mutation-proved, all three reaching the live function:

mutation	result
the sed narrowed	red — the weakness this commit closes
the function renamed away	red on two cases — the vacuous control, now caught
the grep narrowed	red — the original finding's shape, still covered
restored	9 of 9

Note on the two of us

Three convergent fixes on this branch today (the develop merge, the rule-9 fix, and this). The per-PR lock only coordinates /ship against /ship, so it doesn't see a co-driver — the non-fast-forward push abort is what actually caught it, and each time I read theirs before writing over it. Worth knowing when reading the commit sequence.

make drift 38/38 · bats-hygiene green · shellcheck -S warning -x clean.

[LukasWodka]

bugbot run

[cursor]

✅ Bugbot reviewed your changes and found no new issues!

Comment @cursor review or bugbot run to trigger another review on this PR

^{Reviewed by Cursor Bugbot for commit 31d7946. Configure here.}

[aptracebloc]

Verified against the code at 26a68e4. The one-per-line reformat preserves all 38 guards, and the new empty-entry refusal is genuinely fail-closed: each entry is trimmed then [ -z ]-checked, so a middle || or whitespace-only entry exits 1 rather than counting sh -c "" as a passing guard, while a trailing | stays caught by the existing ran != exp count check. The bats suite drives make drift itself rather than restating the split logic, floors the real list at 20 entries, and the mutation table shows each of the four refusals is independently load-bearing. CI is green (incl. make drift 38/38 and the +8 bats cases), both Bugbot threads are resolved, and there is no merge conflict. No defects found.

— drafted with Claude Code

[LukasWodka]

/fr-pass

Functional review on staging — passed, with direct evidence.

Journey (tier A), staging · amd64, run 33494337123 — green end to end, every leg:

install via the real installer → client components healthy → CLI installed from its signed release and signed in → dataset ingested for every task type → use case published → model trained and the leaderboard read.

The train leg, which is the one that matters:

experiment echi0zyk (pk 4041) started
experiment echi0zyk: COMPLETED (terminal, 29 poll(s))
inference submit: submitted for inference on cycle no 2
leaderboard: found after 6 poll(s), running_score=0.9, cycle=2
submissions: our run is on the board (accuracy=0.9 loss=0.3515 captured=True); 1 row(s) total

This repo's change is on the path that run exercised, so this is functional evidence rather than an inference from code review.

Two things stated rather than glossed:

• The run is against the deployed code. Backend f991c788 was helm upgraded into staging at 09:50:19Z and this journey started at 09:50:46Z. A separate journey (33493727497) sits red from 09:43:42 — seven minutes before that deploy — so it exercised the previous image and is not evidence about this promotion.
• e2e-test-agent did not ship this hop (blocked by a Bugbot High, e2e-test-agent#368). So this is yesterday's agent, and the run does not exercise e2e's own unshipped changes. It exercises the platform, which is what this card needs.