[saucam]

CI and the release workflow installed bun-version: latest, so a Bun release could change CI under an unrelated PR.
That happened on #401: Bun 1.4.3's TOML parser broke a test, while developers were running 1.3.13.

This pins Bun in one place, .bun-version (1.3.13, the version in local use), and has every oven-sh/setup-bun step read it with bun-version-file.
A Bun upgrade is now a deliberate one-line PR that CI tests before it lands.

Verification

• pr-check.yml (both jobs) and release.yml read .bun-version; nothing else in the repo pins or names a Bun version.
• This PR's own CI run is the check that bun-version-file resolves on the runner.
• Not run: the release workflow (it runs on tags only).

🤖 Generated with Claude Code

[highflame-oracle]

🔮 Oracle Review

🎯 Start Here

.bun-version (~15 min) — Logic changes in .bun-version

---

📋 PR Summary

What this PR does: Pins Bun version across CI workflows to a .bun-version file (1.3.13) instead of latest, preventing CI breaks from upstream Bun releases under unrelated PRs.

Key changes:

• Adds .bun-version file containing 1.3.13 as single source of truth
• Updates pr-check.yml to read Bun version from .bun-version via bun-version-file
• Updates release.yml to read Bun version from .bun-version via bun-version-file

Areas affected: CI/CD pipelines, toolchain version management

Testing notes: This PR's own CI run validates that bun-version-file resolves correctly on the runner; the release workflow cannot be tested pre-merge as it only runs on tags.

---

🔍 Code Review

This is a well-scoped, incident-driven fix that correctly addresses the root cause of #401 — unpinned CI dependencies allowing upstream changes to break builds unpredictably. The single-source-of-truth approach via .bun-version makes upgrades deliberate and testable, which is exactly the right pattern for toolchain versioning.

What's good:

• ✨ Establishes a single source of truth for Bun versioning, eliminating the drift risk between CI and local dev environments
• ✨ Makes version upgrades a deliberate, testable action rather than an implicit side effect — strong alignment with reproducible builds principles
• ✨ Minimal, focused change that solves the stated problem without over-engineering

Review Stats:

---

Generated by Oracle - Highflame's AI Code Reviewer

[highflame-oracle]

Consider adding a brief upgrade runbook

Now that Bun is pinned, an upgrade requires editing this file. The PR description already describes the process ("a deliberate one-line PR that CI tests before it lands"), but that knowledge is ephemeral. Consider a one-liner in the repo README or a CONTRIBUTING.md noting: "To upgrade Bun, change .bun-version and verify CI passes before merging." This prevents someone from bumping the file without realizing CI is the validation gate.

[saucam]

pr-shepherd: CI is green on e7b7b92 (daemon-check, web-check, Socket x2). No fixes were needed and nothing was pushed. Both setup-bun steps logged Obtained version 1.3.13 from .bun-version. The release.yml change only runs on release, so this PR does not exercise it.