ci(brain): the step named "Build TRI Binary" did not build one

[gHashTag]

brain-ci.yml has failed 10 of its last 10 runs on main. A comment already in the file records that before that it reported Brain health 0 below 80 on all 47 of its runs. It has never once produced a measurement.

The health threshold was never the problem. There was never a health number to compare against it.

The cause

Five steps named "Build TRI Binary" ran zig build tri -Dci=true. That target does not build anything installable — build.zig says so:

const tri_step = b.step("tri", "Run TRI - Unified Trinity CLI");
tri_step.dependOn(&run_tri.step);

The step runs the CLI. b.installArtifact(tri) hangs off the install step, which this target never reaches, so the executable is compiled into the cache and never copied to zig-out/bin. Every later step then found nothing:

./zig-out/bin/tri: No such file or directory
tri: command not found
::error::No health score was produced

A step named for building that instead runs is the same shape as the defects this repo has been clearing all fortnight: the name asserts one thing, the command does another, and the red that follows gets attributed to the subject rather than to the step.

The knowledge was already in the repo

tri-build.yml, one file over, carries:

# 'zig build tri' is a RUN step, so using it as the build gate conflated
# "does it compile" with "does it work"

Written for that gate, never propagated to this one. That is worth more attention than the fix: the fortnight's lesson keeps being learned per-file.

The change

zig build install -Dci=true in all five steps, plus an explicit check:

test -x ./zig-out/bin/tri || {
  echo "::error::zig build install produced no ./zig-out/bin/tri"
  exit 1
}

so the failure lands on the step that was supposed to produce the binary, not three steps later as a missing score. A gate that cannot obtain its instrument should name the step that failed to hand it over.

Unverified here

Whether tri stress --health then produces a score above the threshold. It has never run against a real binary, so its output is genuinely unknown — this PR is what makes that question askable, not what answers it. If the score comes back below 80, that is a real finding about the brain and the first one this gate will have ever delivered.

[gHashTag]

This may now be mergeable, and it may fix two of the four permanently-red checks. It needs a rebase to find out.

Found while auditing CI gates from a different angle (#750, #751, #752). Not acting on this PR — it is yours and I have not touched it — but the state has changed underneath it since 2026-08-26.

The diagnosis here is right

zig build tri really does run the CLI rather than install it:

const tri_step = b.step("tri", "Run TRI - Unified Trinity CLI");
tri_step.dependOn(&run_tri.step);

b.installArtifact(tri) hangs off the install step, which tri never reaches. So the executable is compiled into the cache and never copied to zig-out/bin. A step named "Build TRI Binary" that does not build one.

But the fix was insufficient at the time, and the log shows why

The run on this branch is from 2026-08-26. Its failure chain is three deep:

::error::zig build install produced no ./zig-out/bin/tri   ← your own guard fired
tri: command not found                                      ← fallback to PATH
error: NotImplemented

So zig build install -Dci=true did not produce the binary either. Your guard is what makes that visible instead of a mystery health score three steps later — that part worked exactly as designed.

What changed since

Validate VIBEE Codegen runs zig build -Dci=true, which includes the install step, and it is green on current main (f32467d4f onward). Several things landed between 08-26 and now that touch exactly this: the Zig 0.16 migration guards in build.zig (#745, #746, #747, #749) removed targets that could not compile under CI's 0.15.2 toolchain.

That makes it plausible — not certain — that zig build install -Dci=true now produces zig-out/bin/tri, and therefore that this PR would go green.

Why this matters beyond the PR

⚡ Brain Health Check and 📋 Brain Health Report are two of the four checks I have been treating as "red on main regardless" all night, and skipping past on every PR. If the missing binary is their cause, this PR does not merely unblock itself — it removes two of the four, and a whole class of "that check is always red" reasoning goes with them.

The cheap way to find out

Rebase onto current main and let CI answer:

git fetch origin main && git rebase origin/main && git push --force-with-lease

I did not do this myself: rebasing and force-pushing someone else's branch is a real action on your work, and a re-run alone would not help — it would replay the same 11-day-old tree, since a re-run uses the commit's own build.zig, not main's.

If it goes green, withdrawn-live already passes on this branch, which would leave orphan-artefacts as the only permanently-red check on the repo.