ci(release): six release workflows, audited by running them rather than reading them

[gHashTag]

Six release-adjacent workflows, audited by running them rather than by reading
them. Two are deleted, three are repaired, one needed nothing.

The headline finding is not a workflow bug. Extension Release had been
building zips with no manifest.json inside them — Chrome refuses to load such
a zip — and the mechanism was an unanchored .gitignore rule. extensions/
matches at any depth, so it matched deploy/trinity-nexus/extensions when the
tree moved there and swallowed both manifests and all six icons. The 53
already-tracked source files beside them kept working, which is exactly why
nothing looked wrong. .gitignore already documents this same defect for
website/, dated 2026-08-10.

Opening this pull request was itself the test for bb3107d0e: nothing built
src/vibeec on a pull request, so it drifted out of step with zig 0.15
unobserved until a release tag. It failed on all four targets, on a second zig
0.15 rename I had not fixed and had wrongly reported as clear — see the work
report below, and 2613794b6. It is green on all four now, which is the first
time src/vibeec has compiled for every target under zig 0.15.2.

{
  "version": 1,
  "head_sha": "2613794b6a7cfcf2c839ca6de652c9ade8e19e30",
  "summary": "Six release-adjacent workflows were audited by running them, not by reading them. Two are deleted, three are repaired, one needed nothing. The extension release had been building zips with no manifest.json inside since the tree moved under deploy/trinity-nexus, and the mechanism was an unanchored .gitignore rule that hid twelve files without breaking the fifty-three already tracked beside them.",
  "changes": [
    "Anchored extensions/ and trinity-nexus/ in .gitignore: unanchored, both matched deploy/trinity-nexus/extensions at depth three and silently swallowed every file added after the move.",
    "Restored the twelve lost extension files from tag ext-v2.0.0, both browser manifests and all six icons across chrome/icons and firefox/icons.",
    "Repointed every path in extension-release.yml from the removed top-level extension/ to deploy/trinity-nexus/extensions.",
    "Deleted build-release.yml, which built a Tauri application removed from this repository on 2026-01-31.",
    "Deleted trinity-binary-release.yml, a duplicate that raced release.yml for the same v* tag and the same release body.",
    "Narrowed build-compiler-release.yml to compiler-v* tags only, so it no longer overwrites Binary Release notes on a v* tag.",
    "Added a pull_request trigger on src/vibeec/** to build-compiler-release.yml, so the compiler is built before a release tag rather than after one.",
    "Migrated forty Writergate call sites across nineteen src/vibeec files to std.fs.File.stdout().deprecatedWriter() and its stderr and stdin counterparts.",
    "Renamed thirty-three managed ArrayList sites across twelve files to std.array_list.Managed, which is the pre-0.15 type under its new name, so no call site changes.",
    "Pinned every macOS job to macos-14: zig 0.15.2 cannot link its own build runner against libc on the macOS 26 SDK that macos-latest now carries.",
    "Replaced the archived goto-bus-stop/setup-zig with mlugg/setup-zig@v2, and softprops/action-gh-release@v1 with v2, everywhere they appeared.",
    "Set make_latest false on both side releases, so a compiler or extension tag cannot displace Trinity at the top of the releases page.",
    "Renamed the compiler release assets from vibee-* to vibeec-*, a naming collision that made two different programs look like one.",
    "Un-swallowed both Test binary steps and gated them to the native target, instead of appending an echo to a binary that cannot execute on the runner.",
    "Rewrote dev-enforcement.yml, which GitHub has never parsed: steps was indented under if, so every run since c523c41b0 reported an empty jobs array.",
    "Removed session-check, which judged every pull request by .trinity/dev_session.json and queried a key that is null in that file.",
    "Added firebird to all five archive steps in release.yml; build.zig installs it unconditionally and no release had ever shipped it."
  ],
  "tests": [
    {
      "command": "gh api repos/gHashTag/trinity/actions/jobs/106089046354/logs (probe job: every error in src/vibeec)",
      "result": "Reported exit 1 and three error lines",
      "status": "failed",
      "evidence": "Its last line was: === exit 1, 3 error lines. The job was green because it was continue-on-error and captured the exit code instead of returning it, and I read the green tick rather than the line under it. The error was compiler.zig:827: struct array_list.Aligned has no member named init."
    },
    {
      "command": "gh run view 35514890254 --json jobs (probe jobs for binaries and the extension)",
      "result": "Both reported what they were asked for",
      "status": "passed",
      "evidence": "firebird installed at 3111768 bytes by the top-level build, and both extension zips assemble with manifest_version 3 and 2 asserted through jq -e after the restore."
    },
    {
      "command": "gh release view v10.1.1",
      "result": "Four archives plus checksums.txt published",
      "status": "passed",
      "evidence": "trinity-linux-amd64, trinity-linux-arm64, trinity-macos-amd64, trinity-macos-arm64 tarballs and checksums.txt, produced by the repaired release.yml on the v10.1.1 tag."
    },
    {
      "command": "python3 -c 'import yaml,sys; print(list(yaml.safe_load(open(sys.argv[1]))[\"jobs\"]))' .github/workflows/dev-enforcement.yml",
      "result": "Parses, reporting title-check and pr-status",
      "status": "passed",
      "evidence": "Before the rewrite the same command raised: mapping values are not allowed here, line 54, column 12 — which is why GitHub reported runs with an empty jobs array."
    },
    {
      "command": "gh run view 35515424344 --json jobs (Dev Workflow Enforcement, on this pull request)",
      "result": "Both jobs ran real steps, first time ever",
      "status": "passed",
      "evidence": "PR Title Format: Validate PR title format=success. Update PR Status: Mark in progress=success, with the two close-event steps correctly skipped. Every earlier run of this workflow had an empty jobs array."
    },
    {
      "command": "git check-ignore -v against every path under deploy/trinity-nexus/extensions",
      "result": "Exactly eleven files became committable",
      "status": "passed",
      "evidence": "The twelfth, chrome/icons/README.md, stays hidden by .gitignore line 315 (*.md), and the packaging step already excludes *.md, so no shipped artifact changes."
    },
    {
      "command": "gh run view 35515424324 (Build Compiler Release, first run, at bb3107d0e)",
      "result": "All four target jobs failed identically",
      "status": "failed",
      "evidence": "compiler.zig:827:41: error: struct array_list.Aligned([]const u8,null) has no member named init — the same line the probe had already printed. This is what the new pull_request trigger exists to catch, and it caught it on its first run."
    },
    {
      "command": "gh run view 35515807566 (Build Compiler Release, at 2613794b6)",
      "result": "All four target jobs green, release skipped",
      "status": "passed",
      "evidence": "x86_64-linux-gnu, aarch64-linux-gnu, x86_64-macos and aarch64-macos all built, and Create Release was correctly skipped on a pull request. The two native Test binary steps ran ./vibeec --version un-swallowed and exited zero. This is the first time src/vibeec has compiled for all four targets under zig 0.15.2."
    }
  ],
  "limitations": [
    "Build Compiler Release is green for all four targets, but only for what compiler.zig reaches. Zig analyses lazily, and the other hundred and fifty files under src/vibeec are outside that import closure and remain unchecked.",
    "The ArrayList change is a rename to std.array_list.Managed, which zig 0.15 marks deprecated. The real unmanaged migration is in progress in this tree file by file, and twelve more files still need it.",
    "Local zig is 0.16.0 and cannot check any of this: it has removed std.heap.GeneralPurposeAllocator and std.process.argsAlloc, and stops on the first before reaching any ArrayList. CI is the only instrument.",
    "Six other unanchored .gitignore directory rules still hide files below top level (bin, demos, mcp, models, runtime — twenty-seven files in all), and were left alone deliberately.",
    "The PR title check warns and exits zero. Fifteen of the last hundred and twenty merged titles fail it, so making it binding would reject this repository's own recent history.",
    "The Windows job in release.yml still runs and still fails: seventeen files use POSIX-only APIs that zig refuses to compile for that target. That is a portability project, not a workflow line.",
    "pr-status cannot label a pull request opened from a fork, because fork events receive a read-only GITHUB_TOKEN no matter what the permissions block asks for.",
    "macos-14 is pinned, not fixed. When ZIG_VERSION moves to a zig that can read the macOS 26 SDK, the pin should come back out."
  ],
  "tags": ["ci", "release", "zig", "gitignore", "workflows"],
  "blog": {
    "title": "The release workflows that had never produced a release",
    "summary": "An audit of six release-adjacent GitHub Actions workflows, carried out by running each one instead of reading it. Two were deleted, three repaired, one was already correct — and the worst defect turned out to be a single unanchored line in .gitignore.",
    "outline": [
      "A workflow that fails on every run is loud, and a workflow that has never run at all is silent. dev-enforcement.yml was the second kind: GitHub could not parse the file, so it reported a failed run with an empty jobs array and the file path where the workflow name should have been. No job started, so there were no logs to read, and the emptiness itself was the diagnosis.",
      "Extension Release was worse, because it succeeded. Every step passed and the zips it uploaded contained no manifest.json, which Chrome will refuse to load. The cause was three directories away from the workflow: an unanchored .gitignore rule matches at any depth, so extensions/ matched deploy/trinity-nexus/extensions when the tree was moved there, and quietly excluded both manifests and all six icons.",
      "Already-tracked files keep working when a gitignore rule starts matching them, which is precisely what makes this class of defect invisible. Fifty-three source files under that directory were committed before the move and carried on being committed afterwards. Only the twelve files added or re-added later vanished, and nothing in the build said so.",
      "The macOS failures were never in build.zig. An earlier diagnosis of this same breakage located a missing link_libc flag at build.zig line 1345; a three-job probe workflow disproved it in one run. zig 0.15.2 cannot link its own build runner against libc on the macOS 26 SDK that macos-latest now carries, and the failing symbols come from build_zcu.o before any repository code is compiled at all.",
      "That same probe then caught me out. Its vibeec job was continue-on-error and its script captured zig's exit code rather than returning it, so the job was green whatever zig said — and I read the green tick instead of the line underneath, which said exit 1 with three error lines. An enumerator job cannot prove a build, and a tick over a printed error list is not evidence of anything.",
      "Zig analyses function bodies lazily, so an error list is only ever the first wave. Fixing the four errors the compiler reported produced exactly one more on the next round, then another rename behind that one, and one error per CI cycle is not a schedule. Each wave since has gone in as a single mechanical rewrite across every site rather than as the one line the compiler happened to name.",
      "src/vibeec had no pull-request build gate of any kind, which is the real reason it drifted out of step with zig 0.15 unobserved. A release tag was the first thing that noticed, which is the most expensive moment available to discover it. The trigger added here builds the four binaries on every pull request that touches the tree, and it failed on all four the first time it ran — which is the trigger working, not the trigger being wrong.",
      "The title check warns rather than fails, and the reason is measured rather than assumed: a hundred and five of the last hundred and twenty merged pull request titles match the conventional pattern, and fifteen do not. Those fifteen are Russian-language prose and README prefixes — a different convention, not malformed input — so a blocking gate would reject twelve percent of this repository's own recent history on a rule nobody agreed to."
    ]
  }
}