C-001-001
支持supports
两个作者侧来源都把项目起点放在游戏开发和被拉长的反馈循环中；45 秒数字由官方回顾直接给出。它们不能证明所有开发环境都经历相同时长。
C-001-002
支持supports
官方发布文和作者访谈共同支撑 Bun 将 runtime、bundler、package manager、test runner 等组合为 all-in-one toolkit 的自我定义。
C-001-003
支持supports
Jarred 的早期访谈直接说明了短暂尝试 Rust 后选择 Zig 的生产力与编译期权衡；它不代表后来 Rust 重写阶段的判断。
C-001-004
背景context
HN 快照和官方回顾用于还原发布初期的注意力规模。points、comments 和 stars 是关注信号，不等同于生产采用。
C-001-005
支持supports
分页快照支撑第一周 issue、PR 流入量和截至核对日的后续状态；这些数字是带日期的仓库快照，不是永久状态。
C-001-006
背景该段保留访谈中“为什么不让 Node 更快”的原始提问与 Jarred 的回答语境，用作节目结构回声，不单独证明重写是唯一方案。
C-001-007
支持supports
收购双方的官方公告共同支撑交易与 Claude Code 基础设施语境；Bun executable 的具体表述来自 Bun 公告。
C-001-008
支持supports
官方 setup 文档支撑 native installer 和 npm 安装最终落到 native binary；该文档本身不直接证明 binary 由 Bun compile 生成。
C-001-009
支持PR 元数据和作者说明支撑重写标题、提交/文件/增删规模、测试边界与使用编译器工具减少内存问题的动机；大 diff 本身不证明代码质量。
C-001-010
支持迁移指南直接支撑两阶段流程和 SAFETY、PERF port 等书面规则；它描述迁移纪律，不代表所有改动都已完成同等程度的人工复核。
C-001-011
支持PR 明确写有 canary 与 non-canary 前的后续工作；发布页快照支撑节目核对日尚未出现对应 stable release。上线前必须刷新此时效性结论。
没有符合条件的证据关系。
全部来源
Bun 官方回顾项目起源、45 秒开发反馈循环、项目历史以及加入 Anthropic 后的定位。
Jarred Sumner 讲述 Bun 的游戏起源、构建反馈循环、早期 Rust 尝试与转向 Zig 的权衡。
Bun 1.0 发布文章，给出 fast, all-in-one toolkit 的官方定义及当时的稳定版承诺。
Bun public beta 后的作者访谈，解释 runtime、bundler、transpiler、package manager 和 script runner 的 all-in-one 组合。
Bun public beta 发布当天的 Hacker News 讨论，用于说明注意力规模和当时的社区问题，不用于单独证明工程事实。
对 2022-07-05 至 2022-07-11 新建 issue 和 PR 的 GitHub API 分页快照与后续状态核对。
Syntax 第 544 期访谈，包含“为什么不直接让 Node 更快”以及 Bun 技术选择的原始语境。
Anthropic 对收购 Bun、Claude Code 增长语境、native installer 合作和后续开源承诺的官方说明。
Claude Code 的安装与系统要求文档，用于核对 native installer 与 npm 安装路径的边界。
Bun 从 Zig 向 Rust 迁移的主 PR，保存创建与合并时间、作者说明、测试边界、规模与 canary 状态。
Bun Zig 到 Rust 迁移所使用的规则文档，包含 Phase A/Phase B、unsafe 注释和 TODO/PERF 标记约束。
Bun 的公开 GitHub Releases 列表，用于核对 Rust 重写合并后是否已有对应 stable release。