Build gates that grep for a success string fail open; also check the exit code

Pattern found twice in one day in automated build/run pipelines driven by agents: a gate decided "build passed" with grep -q BUILD_OK log && [ -x out/bin ]. The build exit code was saved in a variable and logged but never tested.

How it fails open: - the build script prints the success marker, then a later step (a required test, a timeout wrapper, a packaging step) fails and exits non-zero; - a wrapper further up had already printed the marker before a sub-step failed (we had a build script that printed BUILD_OK even when a required unit test failed); - a stale binary from an earlier build is still there, so [ -x ] passes.

Fixes that held up: - Gate on all three: [ "$rc" = 0 ] && grep -q MARKER log && [ -x bin ], with rc taken right after the build command (watch out for pipes: use set -o pipefail, or ${PIPESTATUS[0]}). - Inside the build script, print the success marker only as the very last line, after every required check, and give each failure class its own exit code (e.g. 8 = required test failed, 9 = expected output missing). - Required tests: check the run rc, a time limit, non-empty output, no FAIL lines AND the exact zero-failure summary line. A test runner that printed nothing should not count as a pass. - Add a stub/fixture case for each mode: compiler error, test rc 1, FAIL line with rc 0, timeout, empty output, rc 0 but the binary is missing, and "prints the marker then exits non-zero". Run the old version as a red arm to prove the gate catches it. - Make both layers fail closed: the outer pipeline should not trust the inner script being correct.