[roodboi]

Follow-ups to #442 (CI sharding, merged as 6e4bcf2b). Parts (1) and (2) are fixed here. Part (3), the release workflow, is a proposed diff only: it is not part of this PR. The reason is in that section below.

Root cause

Since #442, the hosted suite runs in four test shard i/4 jobs. The test job is now only the required fan-in. It needs test-shard and runs no Bun.

1. Two docs still said a test "runs in the CI test job".
2. bun run ci:bun-crash-census defaulted to --job test, so it read the fan-in. A failed fan-in log has no Bun output, so the census reported zero crashes for it and gave no warning. workflowJobBunVersion(ci.yml, "test") found the fan-in's block, which has no bun-version, and "test shard 1/4" matched no workflow key at all. The workaround in .ai/skills/hack-repo-verify/SKILL.md (--job "test shard i/4") did not work either. The --job check refused /, so the census exited with Invalid argument (reproduced on origin/next).
3. .github/workflows/release-prepare.yml still runs the serial bun run turbo:test. It has no timeout-minutes, so GitHub's 360 min default applies, and Turbo buffers the output.

Fix

(1) Docs. docs/security/env-secrets-threat-model.md:99 and docs/reference/shared-host-lifecycle.md:230 now say the test runs in one of the hosted test shard i/4 jobs, and that the required test check passes only when every shard passes.

(2) Crash census (scripts/ci-bun-crash-census.ts):

• Default jobs: with no --job, the census reads every test shard i/n job of a run. A run with no shard job is from before the split, so its test job ran the suite and is read instead. The same window can span both kinds of run.
• --job values: --job now accepts / and a * pattern. --job "test shard 1/4" and --job "test shard *" both work. Other characters are still refused.
• Workflow Bun version: workflowJobBunVersion now matches a job by its name: template, read only under jobs:. A ${{ ... }} expression in the template matches any text. So test shard 2/4 finds the test-shard matrix job's pin, and test still returns null.
• Warnings: the report adds a closed warning: line when no job matched the selector, or when a selected job shows no Bun setup in its log or workflow block. The same line goes to stderr, and --json gets a warnings array. The warning contains no log content.
• Docs: .ai/skills/hack-repo-verify/SKILL.md now describes the new default.

Tests and evidence

Focused tests: tests/ci-bun-crash-census.test.ts (16 pass). New cases:

• Default selection on a mixed window: shard jobs are read, the fan-in and docker-e2e shard jobs are skipped, and a run from before the split is still read.
• Explicit --job test on a sharded run warns, and the fan-in log content is not printed.
• A selector that matches no job warns.
• The name-template lookup, including quoted templates and on: keys.
• A contract check against the real .github/workflows/ci.yml: all four shard names resolve to the package.json packageManager Bun pin, and test resolves to none.
• --job with / and * is accepted; ; and values over 100 characters are refused.

Mutation proof: each of these 8 mutations makes the suite fail:

• the default selector reads test;
• the name template is ignored;
• no warnings are returned;
• the no_bun_setup warning is dropped;
• the old --job check is restored;
• the workflow version is looked up under the selector name instead of the job's name;
• the default job is test again;
• warnings are not rendered.

Live read-only census (GitHub API GET requests only; window 2026-10-24 05:00Z to 12:00Z, 17 CI runs):

Version	Selector	Jobs	Result
origin/next	default (test)	2	One is the fan-in with bun=unknown; no warning.
This branch	default	5	Every job has a Bun version (log:1,workflow:4,unknown:0); no warning.
This branch	--job test	2	The fan-in prints a warning: 1 of 2 selected jobs show no Bun setup ... line.
This branch	--job "test shard 1/4"	1	Runs; this value was refused before.

Other checks:

• Root bun run check passes, including privacy:check.
• bun run --cwd packages/cli typecheck passes with 0 errors.
• bunx ultracite check on the changed files passes.
• Neighbouring tests pass: shared-host-lifecycle, aes-gcm-v1-context-binding, bun-crash-loop and agent-instruction-source, which reads the verify skill.
• gitleaks 8.30.1 over origin/next..HEAD found no leaks.

Full suite: the hosted CI test check (all four shards) at this PR's head.

(3) release-prepare: proposed diff, not applied

Why it is not applied. The change cannot be validated without a release dispatch or a push to main, and both are outside this unit. release-prepare.yml runs only on push: main and workflow_dispatch. A pull request never runs it, so no hosted check in this PR would exercise the change. Two findings make a run-free change unsafe to claim:

• next's release-prepare cannot pass as written. On next, turbo:test is bun run test:preflight && turbo run test. The preflight needs the matching native config compiler (dist/hack-config-compiler). release-prepare.yml installs no Rust toolchain and never runs bun run build:config-compiler, so the preflight fails before any test starts. On main, turbo:test has no preflight. The last main release-prepare (40050242500) ran 165 files in 30 s. next has 579 files, planned at about 42 min on the macOS shard runner.
• No hosted job runs next's full suite on Linux. The test shard jobs run on blacksmith-6vcpu-macos-15, and linux-process-lifetime runs only 6 files. release-prepare runs on blacksmith-4vcpu-ubuntu-2404. So the Linux duration and the Linux pass/fail result of the whole suite are both unmeasured.

The change only matters when next is merged into main. The workflow that runs is the copy on main, and scripts/test-shard.ts exists only on next, so this diff must not be applied to main by itself. It applies cleanly to next at 6e4bcf2b:

--- a/.github/workflows/release-prepare.yml
+++ b/.github/workflows/release-prepare.yml
@@ -16,6 +16,9 @@
 jobs:
   semantic-release:
     runs-on: blacksmith-4vcpu-ubuntu-2404
+    # GitHub's default limit is 360 min. The suite's own 90 min deadline stops
+    # first and names the running file (HACK-1424).
+    timeout-minutes: 120
     env:
       FORCE_JAVASCRIPT_ACTIONS_TO_NODE24: "true"
     steps:
@@ -47,8 +50,17 @@
       - name: Quality checks (Turbo)
         run: bun run turbo:check
 
-      - name: Tests (Turbo)
-        run: bun run turbo:test
+      # test:preflight needs the matching native config compiler (HACK-1424).
+      - uses: dtolnay/rust-toolchain@1.97.1
+
+      - name: Prepare matching config compiler
+        run: bun run build:config-compiler
+
+      # The `bun run test` file set, Bun pin check and compiler preflight, one
+      # `bun test` process per file with start/PASS/FAIL lines, a 12 min file
+      # limit and a 90 min deadline that names the running file (HACK-1381).
+      - name: Tests (per file)
+        run: bun scripts/test-shard.ts run --shard=1/1 --deadline-seconds=5400
 
       - name: Run semantic-release
         env:

What stays the same:

• Gates: typecheck, privacy check, quality checks, then the tests. semantic-release runs only if every earlier step passes.
• The test run still fails when it should. The runner exits non-zero when any file fails, times out, reports a file count other than 1, or reaches the deadline.
• Exact-head semantics: one job, one checkout of the pushed SHA, the same concurrency group, cancel-in-progress: false.
• Outputs: the same semantic-release step with the same token. No new outputs, artifacts or permissions.

What is new:

• check:bun-version now runs before the tests. It already runs before every bun run test and every CI shard.
• The git ls-files coverage check: verify --count=1 on this head reports "579 files in 1 shards cover the full test set exactly once", planned at 42m22s.
• Per-file progress lines, a heartbeat every 2 min, a 12 min limit per file, a 90 min limit for the run, and a 120 min limit for the job.

Validated statically:

• actionlint 1.7.12 with the repository config passes on both the current and the proposed file.
• bun scripts/test-shard.ts verify --count=1 and plan --shard=1/1 succeed on this head.

Not validated: the run itself on the Linux release runner (compiler build, Linux suite result and duration). That needs one workflow_dispatch of release-prepare.yml against next, or the next-to-main merge. On next, a dispatched run would also reach bunx semantic-release if the tests pass, so a dry run would need --dry-run or a temporary branch filter. I did not dispatch it.

Gaps

• (3) is proposed, not applied. HACK-1424 acceptance allows "explicitly scheduled with a reason", and the reason is above.
• The census's live evidence covers a 7-hour window around the fix(ci): shard the hosted test suite so a slow runner cannot hit the 60 min limit #442 merge, not a long history.
• A job whose workflow fetch fails is also counted as "no Bun setup" in the warning. This is intended: in both cases the zero is not evidence.

Refs HACK-1424

🤖 Generated with Claude Code

---

^{Need help on this PR? Tag @codesmith-bot with what you need.}

[linear-code]

HACK-1424