FIBEMATE 系列。本系列另一篇《密码学时间账本》解决「证据在何时存在」；这一篇回答一个更日常的问题：ml_kem768这个符号是哪天进仓的？X3DH的实现被改过几次？某次审计说「我们 6 月就支持了 SM3」，怎么一句话证实或证伪？答案是 git 历史本身——只是要能查。工具已开源：crypto-time-machine（github.com/Lennonhaha/fibemate-tools，纯 Python 标准库）。
git 本身能回答一半问题：git log -S / -G（pickaxe）可以找「一个字符串何时进入或离开代码库」。问题在工程侧：
crypto-time-machine 做的事：把 git log -S/-G 包成 CLI，结果写进 SQLite 的时间轴表（sha、日期、作者、主题、涉及文件），可查、可导出、可复现。
python ctime/core.py --repo /path/to/fibemate --pattern ml_kem768 --mode=-S参数五个关键位：
--pattern：追踪的符号或字符串（ml_kem768、X3DH、3329、sm3_compress……）。--mode=-S / --mode=-G：直通 git 的两种 pickaxe 语义——-S 统计出现次数变化，-G 按正则比对新旧 diff。两种模式回答的问题不同，都保留。--db：SQLite 输出路径。--since / --until / --query-after：时间窗。扫 fibemate 主仓（2026-09-27 实测）：
ml_kem768，-S 模式：6 个事件——从 initial commit（db81c7f，2026-07-06，v3.1-preview 开源）到 2026-09-19 换用 @noble/post-quantum 参考实现（cba1915，#115），每个事件带完整 sha、时间戳、作者、主题。X3DH，-S 模式：69 个事件。sm3_compress，-G 模式：0 个事件——当前主仓没有这个符号的变更记录，查询本身就证伪了一句「我们改过 SM3 底层」。注意这些数字会随仓库增长而漂移——X3DH 一周前还是 67，现在是 69。时间轴是活数据，引用时给查询日期。
直通 git pickaxe，不自建索引。 -S 和 -G 的语义差异（出现次数 vs diff 内容）是 git 十几年打磨出来的，自己重写一遍只会引入分歧。工具的价值在结构化输出和时间窗，不在重新发明搜索。
SQLite 单表。 timeline(id, sha, date, author, subject, files)——六个字段，够画时间轴、够做审计附件、够被别的脚本 join。多一层抽象都不加。
test/local_test.py：10 项（文件历史非空、不存在符号返回空等），对主仓实测 ALL PASS。test/ci_test.py：9 项（query 返回列表、条目含 files 等），ALL PASS。time-machine-ci workflow，截至 2026-09-27 累计 51 次成功运行。json / os / re / sqlite3 / subprocess / datetime，全标准库。ctime/core.py 当前 168 行。只回答「何时出现、何时消失、改了哪些文件」，不解释动机。 提交主题是作者写的，时间机器不猜测「为什么改」。
git 历史可重写。 rebase、重新签名都能改写过去——这正是《密码学时间账本》一篇讨论过的问题，两个工具是互补关系：时间机器管「查」，时间账本管「锚」。查询结果的可信度以 git 对象图的完整性为界。
模式匹配抓不到语义等价。 符号改名（kyber → ml_kem768）会表现为一消一长两个事件，不会自动合并。
系列至此四条线：可观测性管运行时，TLA+ 管协议逻辑，时间账本管存证锚定，时间机器管历史查询。四条线共同的出发点：审计的人不该信任何一句口头断言——每句话都应该能变成一条可执行的查询。
工具页：fibemate.net/tools/time-machine。
crypto-time-machine/（19 项测试 = 10 local + 9 ci，全 PASS，零外部依赖）ml_kem768 6 事件 / X3DH 69 事件 / sm3_compress 0 事件（2026-09-27 实测）.github/workflows/time-machine-ci.yml（51 次 success）