The unit design gate could not fail, and the release found out

[Boernsman]

The v0.1.1 release build failed in Doxygen, on sources CI had just passed. Two defects.

A bare \dot in prose. 00-mainpage.dox describes where the diagrams come from and wrote the directive literally. Ubuntu's doxygen 1.9 reads that as the start of a dot block and then hits end of file looking for the end of it; 1.18, which I had locally, does not. Escaped as @c \\dot, the convention that file already uses for \implements and \param, and udd.sh now prints the doxygen version — a log that does not name the tool cannot show a version difference.

The CI gate could not fail. The step ran tools/udd.sh | tee udd.log, and GitHub runs these steps with bash -e and not pipefail, so the pipeline reported tee's exit status and swallowed the script's. Every Doxygen failure this job existed to catch was invisible to it, for as long as it has existed. The release workflow runs udd.sh without a pipe, which is the only reason this surfaced.

Measured, not assumed — with a deliberate broken block in the sources:

set -o pipefail; tools/udd.sh | tee   → exit 1
tools/udd.sh | tee                    → exit 0

Same mistake as the || true that hid the QEMU job failing three different ways. A gate that cannot fail is worse than no gate, because it gets counted as evidence — and this one was counted in a release note.

Consequence for v0.1.1

The tag exists and its release build failed, so no release was published. The tag points at a commit whose 00-mainpage.dox still has the bare \dot, so re-running the release workflow against it fails again: the fix has to be in the tagged tree. Once this merges, either v0.1.1 is deleted and re-cut on the fixed commit, or it stays as a tag with no release and v0.1.2 is the first published one.