← 返回日报索引

2026-10-24 GitHub 趋势研究简报

证据边界： 本日全部元数据取自 2026-10-24 CST 06:00 前后（UTC 2026-10-23T22:13Z 快照）经 gh CLI 认证的 GitHub REST / Search API（search/repositories（created:>2026-10-17、created:>2026-10-21、created:>2026-10-22）、repos/{owner}/{repo}、repos/{owner}/{repo}/readme（Accept: application/vnd.github.raw）、repos/{owner}/{repo}/contents/{LICENSE,NOTICE,AGENTS.md,docs/checks.md,docs/how-it-works.md,docs/benchmark/README.md,analyses/known-issues.md}、repos/{owner}/{repo}/git/trees/HEAD 与 ?recursive=1、repos/{owner}/{repo}/releases、repos/{owner}/{repo}/commits、repos/{owner}/{repo}/contributors、users/{org}），字段包括 stargazers_count / forks_count / subscribers_count / open_issues_count / size / language / license.spdx_id / topics / created_at / pushed_at / owner.type / description。「X 小时 / Y 天 Z⭐」按 created_at（UTC）到 2026-10-24 计算，总星数除以经过时长为下限粗估；单日 star 增量未做统计（需分页遍历 stargazer 列表），因此所有增速表述都不能读作当日新增。已核验为空/为零并直接标注的字段：contributors API 对 theorem-labs/oss-verify-proofs 与 oosexgang/hackios-xnu-userland 返回空数组，对 xevrion/hatchzip、haplollc/Vesalius 返回 1 人；topics 对 HackiOS 两仓库为空数组；subscribers_count 为 4 / 1 / 1 / 0（oss-verify 的 0 为本批最低）；license.spdx_id 对 HackiOS 两仓库为 NOASSERTION、对 Vesalius 为 null。本日新增发现的可核验元数据不一致（第四类，累计四例）：oosexgang/hackios-xnu-kernel 的 license.spdx_id 为 NOASSERTION，而其 LICENSE 首行明写 APPLE PUBLIC SOURCE LICENSE Version 2.0 - August 6, 2003（APSL 2.0，与 GPL 不同的 copyleft，且含专利报复条款），且 README 与 NOTICE 未说明该仓库自有代码的许可——这比 10-23 记录的 UniXNU/Snapintosh 两例严重，因为 APSL 2.0 对「External Deployment」（分发给第三方或作为 Larger Work 提供服务）有明确条件（须满足 Section 2.1 关于 Source Code 的全部条件），依赖 license 扫描器判断「是否可商用/可内嵌」的工具会得到错误的默认答案；另 haplollc/Vesalius 仓库根目录没有 LICENSE 文件（?recursive=1 全树查询确认仅存在 VesaliusKit/Sources/CTreeSitter/LICENSE、CTreeSitterGrammars/LICENSES/*.LICENSE 等第三方许可与 vscode-extension/LICENSE），GitHub license 字段为 null，按默认版权保留处理——这与前几日的 NOASSERTION/NOLICENSE 问题同类但性质不同：不是许可证识别失败，而是根本没有许可证声明。热度的关键限定：本日四个项目 fork-star 分化为 17.2% / 6.5% / 1.9% / 1.6%，这四个数字不可横向比较——高 fork 比例的 HackiOS 对应「fork 去移植自己的机型」（仓库明写 common/new-device.sh <codename> path/to/device.dtb + docs/PORTING.md + 设备 profile 模板 _template.conf），oss-verify 的 6.5% 对应「fork 去读证明语句」（其证明语句是公开的 Markdown/Rocq 文本），hatchzip 的 1.9% 与 Vesalius 的 1.6% 对应「不需要 fork，只需下载 release asset 或 brew 安装」（hatchzip 3 个 release × 22 个 asset；Vesalius 提供 Homebrew tap）。连续第四天观察到同一条分界线：fork 比例在「可改造型项目」与「不可改造型项目」之间不可比。 本日没有 CVE 驱动的注意力洪峰（这是自 10-21 php2shell 事件以来的第二次无事件驱动日），但本日出现了一条生态层面的、可核验的批量异常：2026-10-22 12:24–12:28 之间至少 11 个互不相关的仓库在约 8 分钟内集中发布，owner 名全部为 12 位随机小写字母数字串（tunflwgudkyb/cs2-external-esp 256⭐、wpfigfszroxn/pubg-external-esp 247⭐、piqganehprlv/ff-external-esp 120⭐、ulymxumfqtdi/dbd-external-esp 116⭐、urdtbittefnu/deadlock-external 64⭐、yatrjzgbwurs/yt-view-bot 75⭐、ezosizcojoaj/roblox-account-switcher 71⭐、onvuehvxqnfx/warzone-dlc-unlocker 71⭐、nevenaywgmhe/tiktok-dm-blaster 67⭐、eqyvlbekmlqq/tiktok-view-bot 65⭐、hkcjsyzbcgqq/twitch-viewer-bot-ai 62⭐，以及 bwuxqdmgyb/pdf-annotate 67⭐），其中 10 个是 ESP 外挂、刷量机器人、账号切换器或私信轰炸器——owner 名的随机长度一致性 + 创建时间的分钟级聚集 + topics 模板化（同一批 *-external-esp / *-viewer-bot / *-account-switcher 命名）三项交叉证据共同指向批量账号行为，而非有机增长。已过滤的其余可核验 spam 模式延续前几日：.github 作仓库名 + *-tool(s)/.github 命名 + 统一「🔥 …-bot」描述（dex-tool-best/.github 173⭐、df-tools-bn/.github 173⭐、onchain-trading-bot/.github 173⭐、onchain-whale-tracker-pc-desktop/.github 136⭐、mw-tools-123/.github 91⭐，均创建于 2026-10-23 02:10–13:04）本日不新增延续跟踪条目。

今日重点趋势（按排名）

趋势 1：Apple 内核移植的第三条路径（趋势分 91）

本日最值得记的结构性观察：48 小时内出现了第三条互不相识的 Apple 内核移植路径，而它在关键决策上与前两条恰好相反。

先固定事实基线（全部来自 GitHub 官方接口与仓库原文）：

事实 UniXNU/UniXNU（10-23 记录） Acelogic → Macintosh/Snapintosh（10-23 记录） oosexgang/hackios-xnu-kernel（本日新增）
目标 iOS + macOS 跑在非 Apple ARM64 硬件 macOS 27 跑在 Snapdragon X2 Elite 笔记本 iOS 16.5 跑在 Android 手机硬件与 QEMU
内核来源 官方 XNU，不 patch 官方 kernelcache，默认未修改 Apple 开源 XNU 源码（xnu-8796.121.2），直接打补丁
路径 UEFI + 伪平台契约 EL2 hypervisor（monitor）+ 工具链 自写 EFI loader + Mu-Silicium UEFI 移植 + 替代闭源驱动
设备覆盖 35 份设备文档，多机型 只支持一台（A16） 2 处运行（POCO X5 Pro + QEMU），设备 profile 模板已存在
用户态 — macOS 27 iOS 16.5 未修改用户态（launchd → backboardd → SpringBoard → apps）
许可 BSD-2-Clause-Patent（文件）/ NOASSERTION（API） MIT（文件）/ NOASSERTION（API） APSL 2.0（文件）/ NOASSERTION（API）
规模信号 35 设备 · 16 驱动 submodule · subs 3 · 30 commits 11 commits · subs 4 6 commits · 2 contributors · subs 4

分歧点极清晰：前两条都拒绝碰内核，HackiOS 恰恰选择改内核。 UniXNU 的整条设计哲学是「不 patch 内核而是补齐内核期待的 Apple 平台契约」，Macintosh 是「跑 Apple 官方 kernelcache 默认未修改」——两者都把「内核保持官方二进制」当作原则，代价是继承全部不兼容与全部漏洞，收益是内核升级时零 rebase。HackiOS 反其道而行：既然 Apple 的 XNU 本身是开源的（APSL 2.0），那就直接编译它、打补丁，然后跑官方未修改的用户态。 这是一个从法律与工程两个维度都不同的第三条路——它把「不改内核」的成本（继承不兼容）换成了「每次内核升级都要重新 rebase 补丁」的成本，而对 iOS 16.5 这个固定版本，rebase 成本为零。

第二个值得记的观察是它的分布形态。 HackiOS 把内核侧与用户态侧拆成两个仓库（内核仓库 1,064⭐ ⑂183；用户态仓库 328⭐ ⑂116，fork/star 35.4%），两个仓库都明写「No Apple files are in either repository」，IPSW 由 ios165/fetch.sh 从 Apple CDN 下到本机并本地解包——这是本日第四个把「Apple 私有输入不得入库」写成仓库级制度的项目（前三个是 UniXNU 的 README Private blobs 段、Macintosh 的 AGENTS.md 第 1 条、Macintosh 的 THIRD_PARTY_NOTICES）。四天内四个互不相识的项目，各自独立地把同一条合规要求写在了仓库级别的显眼位置——这条纪律正在成为 Apple 硬件逆向领域的默认规范，而不是某个项目的个人习惯。

第三个观察是本日最值得学的一份文档：docs/checks.md「How our own checks lie」。

它的开头就把整篇文档的论点说完了：「They are written down because eleven of the twelve look the same: missing information reads as a missing problem.」

这条论点的分量在于它反转了通常的怀疑方向。普通做法是怀疑「检查通过」意味着「检查没问题」；这份文档主张更常见的失败是「检查根本没跑」而这看起来和「检查跑了并且通过了」一模一样。它给的十一个例子里最有代表性的三个：

  1. 被跳过的检查没有计数。 continue 不加总 → 十条 AIR 声明在只比较四个 case 之一后被列为匹配（其余三个卡在无限等待）；if idx >= len(flat): continue 静默丢掉短行；read() 进固定缓冲区丢掉文件尾部。总计仍然对得上——68 + 3 + 7 = 78——因为被推迟的那些也被算作匹配。 它给出的对策不是「检查总数」而是「一个每个例外都有自己的列与名字和数字的总计」，并指出最极端的情况是对空集做检查：「a loop of zero iterations prints '0 of 47' and looks exactly like an honest zero」——那次是内核列表所在目录在两次会话之间被清理，唯一救回来的是 shell 单独说了「no such file」。「A denominator lies as quietly as a summand.」
  2. 被静默的命令。 patch -s --dry-run 返回 0 却不说话，沉默被读成「恰好适用」；去掉 -s 才会说 succeeded at 410 (offset 2 lines)。
  3. 从缺席推断。 「日志里没有」与「没发生」是两件事——loader 的日志会丢掉中段（标记是「size at the limit」加上确切的一行 the log between the first 256 KB and the last 1 MB was dropped，而不是「was dropped」这几个字，按钮驱动也打印同样的话）；grep 的视野会漏掉二十行之上的守卫（六个 bin/sh 匹配全是 /var/jb/bin/sh）；一个从不触发的看门狗只有在同时给出运行次数时才证明任何事（他们的看门狗是 26 次运行、零漂移）；一次打印零行的测量其实是 grep 了一个 printf 从不打印的模式。「A measurement that cannot fire looks exactly like an event that did not happen.」 那个零不是靠怀疑仪器抓到的，而是靠与已测到的结论矛盾抓到的：三个模块靠指针绑定翻译，因此那里不可能是零。

架构师速览（HackiOS）：

决策问题 研究判断 证据边界
系统边界 两层：① 内核侧（XNU 补丁 + EFI loader + UEFI 移植 + 替代闭源驱动 + Wi-Fi 层 + QEMU 脚本 + xl 宿主控制工具 + 预构建产物）② 用户态侧（init.c + 注入库 + CoreAudio 设备 + OpenGL ES 到 Mesa 的桥 + APFS 镜像构建器 + Mesa/AIR 工具 + Procursus bootstrap）。边界划在「Apple 文件」处：两个仓库都不含 Apple 文件，IPSW 由本机脚本下载解包 README 的两仓库分工表、Layout 表、userland README 的 Path 表、ios165/fetch.sh 与 fetch-from-ipsw.py；xnu/redwood.patch 的实际改动规模与 xnu/files/ 的新增内容本窗口未取，待核验
主路径 设备上电 → fastboot boot 加载预构建的 hackios-redwood-boot.img（Mu-Silicium UEFI，内嵌自写 loader）→ loader 通过 USB 起 fastboot 协议链路 → 上传系统镜像到 RAM（2.5 GB，约 80 s）→ loader 装载 XNU（redwood.patch 应用后的配置）→ 内核提供替代驱动（IOSurface / IOMobileFramebuffer / AppleKeyStore / 网络栈 / minicrypto 替 corecrypto / AMFI 与 Sandbox 替身）→ iOS 16.5 launchd → backboardd → SpringBoard → 应用；注入库通过 DYLD_INSERT_LIBRARIES（kern.exec_inject）进入 backboardd / SpringBoard / mediaserverd，mediaserverd 获得自写 CoreAudio 输出设备 README 的 How it works ASCII 图、userland README 的 Path 表、xl 命令列表（enter / ramdisk / run / screenshot / reboot / logs / 屏幕与声音录制 / 相机帧 / stop / state）；注入库在具体系统服务上的生命周期与失败回退路径未明说，待核验
关键权衡 改内核 vs 不改内核（本批三个 Apple 项目里唯一改内核的：继承 rebase 成本，换取摆脱平台契约伪造）· 直接编译 Apple 开源 XNU vs 用官方 kernelcache（前者需要 theos + iPhoneOS16.5.sdk + 工具链，后者只需 Apple 文件）· 真机 + QEMU 双运行 vs 只跑其一（QEMU 让无手机的人能复现，真机让 GPU/Wi-Fi/摄像头路径可验证）· fastboot boot 不写闪存 vs 刷入 ROM（明确「research bench, not a ROM」，会话到时内核交还日志）· 注入库 vs 改系统二进制（dyld 注入让「用户态一个字节未改」这句主张成立）· APSL 2.0 vs 宽松许可（用 APSL 分发 Apple 派生物有明确条件，见风险节） README 的两处主张、Layout 表、docs/checks.md、userland README 的 Licenses 段、仓库 LICENSE 首行；「为什么选择改内核」的显式论证 README 未给，只有结果
最小 PoC 1. 先确认主机条件（Linux x86-64、约 12 GB 磁盘、4 GB 内存、7-Zip 23+ 因其读 APFS）→ 2. common/setup.sh 把用户态仓库并入同一棵树（git dir .userland.git）→ 3. ios165/fetch.sh 从 Apple CDN 下载 7.4 GB 并本地解包（5–15 分钟）→ 4. common/build.sh qemu-virt 构建 APFS 镜像（注意：没有交叉工具链时使用 prebuilt/userland 里的预编译产物）→ 5. common/run.sh qemu-virt 启动（20 分钟会话，2–3 分钟后出现锁屏）→ 6. 只验证锁屏与主屏渲染，不要一上来碰 Metal 应用（456 个 shader 中 293 个可跑，剩 163 个不可跑）→ 7. 真机路径需要 POCO X5 Pro 5G + 解锁 bootloader + adb/fastboot，且必须先 adb pull 五个 vendor 固件（fw-gpu/ fw-wifi/ fw-audio/ fw-haptic/）→ 8. 按 docs/checks.md 的口径检查自己的每一条断言（尤其不要把「没报错」当成「检查过了」） 第 3 步是不可绕过的时间成本（7.4 GB 下载 + 5–15 分钟），第 6 步是本 PoC 最重要的判断；真机路径的固件提取必须在 build.sh 之前完成（README 明写 userland/build.sh 会打印哪些固件被装入）；本 PoC 无法验证摄像头、蜂窝与 App Store 路径——README 自己写明这些不支持

趋势 2：把「我证明了什么」与「我没证明什么」做成可执行的形式（趋势分 90）

theorem-labs/oss-verify-proofs 的热度很低（92⭐ ⑂6，subs 0，全仓库仅 2 个 commit，contributors API 返回空数组）。但它是本批信息密度最高的项目之一，而且它的信息全部以机器可检查的形式给出。

它做的事一句话说得清：对 OSS-Fuzz 的 fuzz target 给出机器检验的证明，证明「在陈述的界限内不存在使它失败的输入」——而且 「Each proof is about compiled binaries, not source code.」

它的边界声明写在最前面，不是最后面。 README 第三节标题就是 「LPS is best effort and not complete. It describes part of Linux, and it makes some assumptions that it does not check. A proof is only as good as LPS.」 这句话把「形式化验证」这件事最容易误导人的地方直接摆在了台面上——证明的可信度上限由语义模型的完备性决定，而这个模型自己明说不完备。

然后是 What a proof does not say 这一节，六条边界：

这最后一条值得单独强调。 它意味着 138 条已证证明的主张是「在覆盖范围内 sanitizer 不报错且两构建行为一致」，而不是「程序会终止」。一个能被 fuzzing 之外的形式化方法证明「不会崩溃」却没证明「会终止」的库，在实践中仍然可能挂死。作者把这个缺口写在最显眼处而不是藏起来。

规模也被诚实摊开，没有任何取舍式包装：1,381 个 OSS-Fuzz 项目中 427 个可构建（781 个「语言待定」、97 个「尚未构建」、3 个「需要模型支持」、3 个「无编译器」、32 个「无 harness」、6 个「排除」、32 个「暂缓」）；427 个可用项目有 2,148 个 harness 与 20,164 条 statement——138 条已证、0 条已知为假（0 counterexamples、0 witnessed false）、0 条疑似为假、229 条被模型阻塞、0 条 withheld、19,797 条仍 open。8,578 个二进制随发布附上，0 个被扣留。2,148 个 harness 中 2,141 个有全部四种构建（plain / ASan / UBSan / ASan+UBSan）。analyses/known-issues.md 逐条列出每一个既非 open 也非 proved 的 statement 及原因——例：arrow/arrow-csv-fuzz 的全部四条 statement 都标 blocked by the model，原因是「二进制查询 CPU affinity 并启动线程，模型尚未覆盖」。

可核验性的工程细节值得记。 每个证明在 proofs/<project>/<harness>/provenance/ 有 build record，含上游仓库与 commit、harness 文件、recipe、编译器、构建器镜像、static AddressSanitizer commit、编译与链接 flags、每个二进制的 SHA-256 与许可。oft check 的检查序列是硬的：先对每个二进制校验 SHA-256 → 构建内存映像与 statement → 编译每条证明 → 编译一个把证明的定理赋予 statement 类型的 wrapper → 读取 wrapper 的 Print Assumptions 输出，拒绝任何不在允许列表中的假设。允许的公理被逐条列出：Rocq 原生的整数/数组/字符串类型及其规范，加上 6 条标准库公理（classic、functional_extensionality_dep、constructive_indefinite_description、propositional_extensionality、sig_forall_dec、sig_not_dec）。checker image 固定到 sha256:cc9ae43a9f4b0dd59d7c8d30727d36e039bfe72a2a9f9c4a99c68e413037e902。

许可分层是本日第二值得学的文档处理。 NOTICE 明确：「statements, tools, documentation and the proofs that we wrote are under the MIT licence」，而「Proofs that we made from proofs that Anthropic licensed under the Apache License 2.0 or the MIT licence, at the recipient's option, keep those licences and their file headers」——LICENSES/ 下同时存放 anthropic-proofs-LICENSE（Apache-2.0）、anthropic-proofs-LICENSE-MIT、anthropic-proofs-NOTICE，且每个此类证明的 build record 指名这三个文件。这不是「MIT 主体 + 角落里的例外」，而是把混用许可的来源、条款选择权与归属声明三者都做成了可追溯的引用结构。

架构师速览（oss-verify-proofs）：

决策问题 研究判断 证据边界
系统边界 ① 证明层（proofs/ 每个目录一个证明，含 Statements.v 与 Rocq 证明）② 语义模型层（外部仓库 theorem-labs/rocq-linux-process-semantics，commit f1006fe81783）③ 工具链层（tools/oft/ 是 oft 命令的 Python 实现，负责 fetch/check/generate；toolchain/checker.Dockerfile 固定 checker 镜像）④ 生成层（oft generate 从模板与 facts 生成 README、STATUS 与 known-issues，文件头明写 'generated by oft generate; do not edit'）⑤ 信任层（toolchain/allowed-axioms.txt、docs/trust.md、docs/semantics.md）。数据面是 ELF 字节 → LPS 内存映像 → Rocq 定理；控制面是 oft 的 fetch/check/generate 三条命令与 CI README 的 Repository layout 与 Versions 节、analyses/known-issues.md 首行、.github/workflows/{release-check,pr,weekly}.yml；tools/oft/ 的具体实现本窗口未取，待核验
主路径 维护者在 theorem-labs/oss-verify 登记项目 → CI 拉取该项目的 OSS-Fuzz 二进制（./oft fetch <project>，每个二进制对 SHA-256 校验）→ oft check <project>/<harness> --parts statements,proofs 在固定 checker 镜像内构建 LPS 内存映像、生成 statement、编译证明、编译 wrapper、读取 Print Assumptions 并拒绝越界假设 → 通过的证明随 release 发布（v2026.10.0 含 427 个 asset，v2026.10.0-src 含 851 个）→ 未证明的 statement 进 index/STATUS.md 与 analyses/known-issues.md README 的 Check a proof 节与 Statements for OSS-Fuzz fuzz targets 节；「登记 → 拉取 → 证明」这条流水线的自动化程度与人工介入点未明说，待核验
关键权衡 证明二进制 vs 证明源码（二进制可核验但脱离源码语境；源码可读但需要可信编译器链）· 限定 riscv64 静态链接 vs 覆盖 OSS-Fuzz 实际的 x86-64 动态构建（前者可在形式化模型里完整建模，后者不能——这是一个明确的取舍，不是缺陷）· agreement statement vs halts statement（前者可证（138 条），后者本次一条未证——因为模型不支持终止性，analyses 里 229 条 blocked by the model 多属此类）· LPS 的不完备性 vs 完备性成本（作者明写「LPS is best effort and not complete」并把 docs/semantics.md 指向读者——这是自觉的取舍而非疏漏）· MIT 主体 + 逐证明保留 Anthropic 原始许可 vs 统一重许可（前者保留原始归属，后者省事但可能违反来源许可）· 2.1 GB 仓库体积 vs 逐证明分单元可检查（CI 改为 'one proof unit per check job' 说明体积已构成工程约束） README 的 What a proof does not say 与 Versions 与信任清单、NOTICE、commit 'ci: one proof unit per check job'；未明示：证明工作的实际人力投入、哪些库的证明有商业资助
最小 PoC 1. 确认有 Docker、zstd、Python 3 + PyYAML → 2. git clone + cd oss-verify-proofs → 3. ./oft fetch coturn（拉取该项目的二进制并逐个对 SHA-256 校验）→ 4. python3 -m pip install --require-hashes --target "$HOME/oft-pydeps" -r tools/oft/requirements.txt → 5. docker run（--network none、非 root 用户、挂载 pydeps 与工作目录）跑 ./oft check coturn/FuzzStunClient --parts statements,proofs → 6. 必须预留资源：16 核上一次证明检查最多需 20 GiB 内存，核越多内存需求越大（每核编译一个文件），--cpuset-cpus 可限制核数 → 7. 读 oft check 的输出：它应当在 Print Assumptions 阶段拒绝任何越界公理——如果这一步没有输出拒绝，检查本身就没在起作用 → 8. 再跑一条 analyses/known-issues.md 里标为 blocked by the model 的 statement，确认它被正确归类为阻塞而非静默跳过 第 5 步是唯一能独立证伪「它真的在检查」的步骤（与 HackiOS 的 checks.md 同构——必须验证检查器会拒绝，而不只验证它会通过）；第 6 步的资源需求决定了它不是「随手跑一下」的验证路径；本 PoC 无法验证证明对 x86-64 的适用性（那不是它证明的东西）

趋势 3：破坏性操作的不变量与「提前拒绝」（趋势分 89）

xevrion/hatchzip（2.5 天 888⭐ ⑂17，fork/star 1.9% 为本批最低，subs 1，Rust，Apache-2.0）的 star 数比同批的 oss-verify 高一个量级，但它的内容密度是本日第二高的。

它解决的问题具体到能算。 180 GB 的归档解出 200 GB，WinRAR / 7-Zip / unzip 需要 380 GB 磁盘，因为归档与产物必须同时存在于盘上。HatchZip 只需略多于 200 GB。

技术路线是一条完整的理由链，而不是一个技巧：

  1. 只能从尾部截断。 从前或从中删除需要打洞（Linux fallocate、Windows FSCTL_SET_ZERO_DATA、macOS F_PUNCHHOLE），而 FAT32 与 exFAT 不支持打洞，且各系统行为不同。所以 HatchZip 从尾部工作。
  2. 每个格式把归档描述为 unit 列表（ZIP 一个 entry = 本地头 + 数据；7z 一个 solid block 或非 solid 时的一个文件；tar 一个 entry 含其前的长名/pax 记录；.tar.gz 整个归档从前端解）。unit 按位置倒序解压，每批之后把归档截断到该批最低 unit 的起点。
  3. 7z 的 solid block 只能从头解码，所以它只能在其全部解出后才被释放——最大 unit 就是就地解压的主要成本（需要「输出 + 约等于最大 unit」的空间）。
  4. 目录与空文件在 7z 里没有数据只有头条目，构成一个额外 unit，起点在头所在处，所以先做，且截断它只释放已保存的头。

它给出的唯一硬拒绝场景是可复算的：7-Zip 默认设置会把整个归档放进一个 solid block，此时「一块在被完全解出前一点空间都释放不了」——HatchZip 在碰任何东西之前就拒绝并说明原因。README 对比表的最后一行结果就是 Refused before touching anything。

README 的对比表全部带具体数值（同一份 200 MB 游戏数据、21 个文件、220 MiB tmpfs 模拟整机磁盘、约 50 MB 空闲）：

归档 unzip / 7-Zip HatchZip
ZIP，180 MB unzip 在第 6/21 个文件耗尽空间 完成，每个文件逐字节一致
7z 25.01 -ms=20m（10 个 solid block） 需 380 MB 0.64 s 完成，逐字节一致
7z 分 5 卷各 40 MB 需 380 MB 完成，卷被逐个删除，峰值占用 210 MB
tar（GNU tar），200 MB 需 400 MB 0.12 s 完成，逐字节一致
7z 默认设置（1 个 solid block） 需 380 MB 在改动任何东西之前就拒绝

速度上 ZIP 解压 0.25–0.35 s，对比 unzip 6.00 的 1.48–1.50 s（含一次 unzip 跳过的 fsync）。测量环境写明：Fedora 43、Intel Core i7-14700HX、SK Hynix NVMe SSD、热页缓存；空间测试用 220 MiB tmpfs，速度测试用 ext4。速度来自并行解压，所以只含一个巨型文件的归档按单核速度解出。 README 还说明额外空间需求约等于「能一次释放的最大单元」的大小，并指出在支持打洞的文件系统上，大文件每 256 MiB 就释放一次归档字节（一个 600 MiB 存储文件在 950 MiB tmpfs + 367 MB 空闲下完成，而传统方式需要 629 MB），hatchzip check 能为任意归档算出确切数字。

AGENTS.md 把不变式写成绝对句，这是本批最值得抄的一段工程纪律：

「The tool destroys its input. The invariant is absolute: the journal never claims a file before it is durable, and the archive is never truncated past an entry the journal doesn't claim.」 「Anything that can be refused is refused before the archive is touched.」 「Every number in the README and docs is measured on real hardware, never estimated. Paste the measurement when you change one.」 「A behavior is not finished until it ran for real: a real archive extracted, the output compared byte for byte, the crash tests passing.」 「Never run extract on an archive you can't recreate. It deletes it.」

以及通信规范：「Be succinct. Prefer code over prose.」「State what you did not verify. An honest gap costs less than a confident wrong claim.」

它还把踩过的坑写成具体条目（Traps already fallen into），每一条都是真实事故而非泛泛的最佳实践：zip crate 反向扫描整个归档找 end record，storage::Reader 必须对已截断区域返回零而不是报错，否则每次恢复都失败于 No CDFH found；tar 依赖同样的零来停在截断点；Windows 上必须用字节区间锁，因为锁归档会阻塞自己的读取线程（another process has locked a portion of the file），platform::open_exclusive 在那里改用 share mode；Linux 用一次 syncfs 刷新一批，所以每目录的 bug 只在 macOS 与 Windows 上暴露；链接条目的文件夹直到最后才存在，不要按批处理；不要在测试里硬编码单元数（7z writer 给某些空文件单独一个 block，会让每个计数差一——改为断言不变式）；7-Zip 默认设置可能把整个归档放进一个 solid block，测试要同时用 -ms=<size> 与默认设置；恢复时崩溃批次写过但未提交的文件仍占空间，必须先删除再做空间检查，否则检查会拒绝一个其实装得下的运行。

架构师速览（hatchzip）：

决策问题 研究判断 证据边界
系统边界 四个 crate：core（引擎库：每格式一文件的 archive/ + 唯一缩减归档字节的 storage.rs + engine.rs 规划与执行解压 + journal.rs 崩溃安全状态 + session.rs 前端调用面 + platform/ 每 OS 一文件）、cli（hatchzip 命令与端到端测试）、gui、shell。边界划在「截断」这个动作上——引擎只通过 storage.rs 触碰归档字节，其余代码都不直接缩减文件 AGENTS.md 的 Project coding standards 与 Traps already fallen into、README 的 Layout、crates/core/src 目录树；gui/ 与 shell/ 的职责本窗口未取，待核验
主路径 用户选择归档 → hatchzip check 先算空间（在任何改动之前）→ 若可装下：从尾部定位最后一个 unit → 读取并写入输出 → 每批之后截断归档到该批最低 unit 的起点并 fsync → journal 记录已提交项 → 全部完成后归档归零、只留输出；崩溃后由 journal 恢复（已截断区域读作零，让 zip crate 反扫时零不匹配签名、让 tar 把零读成归档结束） README 的 Highlights 与 docs/how-it-works.md 的 The space problem / Why from the end / The journal / The saved tail 节；「恢复时如何发现崩溃批次写过但未提交的文件」在 AGENTS.md 里提到但流程细节未取，待核验
关键权衡 只从尾部截断 vs 打洞（尾部是所有文件系统都支持的最小公倍数，打洞收益大但 FAT32/exFAT 不支持且各系统行为不同）· 就地释放空间 vs 需要 2 倍磁盘（核心主张）· 最大 unit 作为不可压缩成本 vs 预先拒绝（7z 默认设置直接被拒）· journal 作为崩溃恢复的真相源 vs 不做恢复（恢复能力以额外状态与复杂度为代价）· 每平台一个文件 vs cfg 条件编译（AGENTS.md 明令 platform/ 之外禁止 cfg(target_os)）· Rust 1.95 + MSRV 1.89 vs 更低版本（File::try_lock） README 的 Highlights、AGENTS.md 的 Operating systems 与 Rust 节、AGENTS.md 的 Traps 逐条；未明示：journal 文件与输出目录的原子性策略细节、gui 与 cli 是否共用同一 session 路径
最小 PoC 1. 先准备一个可重建的归档（AGENTS.md：「Never run extract on an archive you can't recreate. It deletes it.」）→ 2. 跑 hatchzip check 看它算出的确切空间需求 → 3. 故意试一个 7-Zip 默认设置的 7z——它应该在动手之前就拒绝并解释原因（这是本 PoC 唯一能证伪「它真的提前拒绝」的步骤）→ 4. 用 -ms=20m 的多 block 7z 跑一次，对比输出与原文件逐字节一致 → 5. 在解压过程中强杀进程，然后恢复，验证输出逐字节一致（README 声称在每种格式运行的多个点、两个不安全时刻都杀过，每次恢复输出都相同）→ 6. 在一个空间只够「输出 + 最大 unit」的分区上跑，验证它不会在空间耗尽时留下半个归档 → 7. 验证已截断区域读作零的行为（这是恢复正确性的基础）→ 8. 检查 platform/ 之外的代码没有 cfg(target_os) 第 3 步与第 5 步是唯二能证伪其核心主张的步骤；第 1 步是硬前提；第 6 步需要真实的分区或 tmpfs 配额，本 PoC 不覆盖多卷删除路径

趋势 4：用一次诚实的失败轮次回答「agent 到底会不会用我的 MCP」（趋势分 88）

haplollc/Vesalius（1.7 天 61⭐ ⑂1，fork/star 1.6%，subs 1，Swift）功能上是一个本地代码图 + MCP server + CLI + Mac app + VS Code 扩展，五个只读工具（usages / feature_map / outline / architecture / dependency_cycles），对 Claude Code 的调用图覆盖 Swift（经类型解析）、TypeScript、JavaScript、Python。

但它最值得记的部分是 benchmark 的诚实，而这是本日报里唯一一个「作者先写下自己的失败」的项目。

第一轮 24 次运行中，Claude 只在 2 次调用了 Vesalius。 作者的判断是：那一轮的 13% token 差距「主要是 run-to-run 噪声」（rather than a real effect）。根因也写清楚了：Claude Code 把 MCP 工具藏在 tool search 后面，而它几乎从不搜索。

于是做了 Vesalius 2：按问题类型各配一个更锋利的工具，并把最常被问的两个预加载（usages 与 feature_map 预加载约加 900 token 上下文，其余三个等 tool search 按需加载）。结果：20/20 次全部调用。

最终数字（同一固定构建 2.1.307、同一模型与 prompt、只读工具，20 个真实问题 × 6 个代码库，一次带一次不带，一个 AI 评审对着代码里核实的 key 盲评）：

它逐类列出没赢的地方，这是本批少见的做法：

问题类型 题数 token 变化 质量变化
谁依赖这个文件 5 −71% +1.6
导入环 1 −74% +2.2
谁调用这个 2 −56% −0.2
变更影响 3 −42% −1.0
功能在哪 5 −38% −2.1
架构 2 −33% −1.2
符号在哪 2 −8% −1.7

并且写明：20 题中有 4 题 token 反而更多（+2% 到 +19%）；11 题质量移动超过 1 分（3 题更好、8 题更差）；「每题只有一次运行一次评审，单题噪声很大，所以区间是对问题做 bootstrap」。

它还有留出集：8 题是在 Vesalius 2 设计之后写的、来自两个从未用于构建它的代码库，其上减 44%（95% CI 12%–65%），另 12 题是它对着建的。方法论边界也写清了：三个代码库是作者私有应用，答案 key 与 run transcript 保持私有（避免泄漏进未来的工具设计与训练数据），因此无法精确复现该 benchmark；judge 指令公开在 docs/benchmark/grading_prompt.md，harness 与分析脚本公开在同目录。

它还用本地计数解决了一个真实痛点：vesalius stats 显示 Claude 到底问过什么（工具、调用数、token、每次答案的中位耗时、完整性检查是否通过），从不记录你的问题、符号或代码；vesalius doctor 按 Claude Code 的方式启动 server 并检查每一环连接、它服务哪个仓库、索引有多新。这直接针对 MCP 生态里最常见的抱怨——「agent 从来不调我的工具」——而 Vesalius 的答案是先承认这曾经是真的（第一轮 2/24），然后把根因写下来，再改设计。

对比表也毫不含糊地写明它不是所有人的正确工具：调用图只覆盖 4 种语言，其余 13 种只有词法；只在 macOS 15+ Apple silicon 上运行；在仓库里不留任何东西（对比 CodeGraph 留 .codegraph/、graphify 留 graphify-out/）；setup 只加一条 MCP 条目与一条权限规则；无网络（CodeGraph 默认开匿名遥测与更新检查）。

架构师速览（Vesalius）：

决策问题 研究判断 证据边界
系统边界 ① 索引与图引擎（VesaliusKit：SwiftSyntax 解析出的调用图 + 类型推导流 + 持久化索引）② MCP server（stdio，暴露 5 个只读工具）③ CLI（vesalius usages/feature-map/outline/architecture/dependency-cycles/ask/impact/health/map/query/watch/doctor/stats）④ Mac app（SwiftUI，含 Settings › Agents 可注册 MCP）⑤ VS Code 扩展。边界划在「索引存放位置」：不写入用户的仓库、CLAUDE.md 或 hooks，索引与使用计数在 ~/Library/Application Support/Vesalius，可整目录删除 README 的 What setup changes and nothing else 节、工具表、FAQ 的 How do I remove it 节；索引的存储格式与查询后端（README 提到 vesalius query "<sql>" 对索引做只读 SQL）本窗口未取具体实现，待核验
主路径 vesalius setup 注册 MCP + 加一条权限规则 + 索引当前仓库 → Claude Code 提问 → tool search 命中（usages/feature_map 预加载，其余按需）→ MCP server 查询本地索引 → 返回带 file:line 的答案 + 完整性检查 → Claude 用 grep/读文件做二次核对（benchmark 中每题 2.65 次搜索/读/shell 调用，对比无 Vesalius 时的 7.2 次）→ vesalius stats 记录本次调用（仓库路径、工具、答案大小与耗时、完整性检查是否通过） README 的 Quick start 输出、The five tools 节、Is Claude using it? 节（含真实 vesalius stats 输出）；索引刷新时机（ensureFresh 的增量判定）与 --no-refresh 的失效条件未完全核验
关键权衡 预加载两个工具（+900 token 上下文）vs 全按需加载（这是把 2/24 提到 20/20 的关键改动，代价是固定上下文成本）· 类型感知的调用图 vs 纯 tree-sitter 词法（Swift 走类型解析准确但只有 4 种语言有调用图）· 本地索引 vs 服务端索引（无网络、无遥测、无 .codegraph/ 残留）· 只读工具 vs 可写工具（所有工具只读，编辑仍交给 agent）· 私有 benchmark 数据 vs 完全可复现（保留数据防泄漏，代价是无法精确复现）· 单平台 vs 跨平台（只在 Apple silicon 上，放弃三大平台市场） README 的 How it compares 表与 Where it helps 节、benchmark 的留出集说明；「为什么放弃 Linux/Windows」README 未解释
最小 PoC 1. 确认硬件门槛：Apple silicon + macOS 15+（这一步不成立则整个 PoC 不成立）→ 2. brew install haplollc/tap/vesalius → 3. vesalius setup（建议先 --dry-run 看它要改什么）→ 4. 用 vesalius doctor 确认连接（它按 Claude Code 的方式启动 server 并检查每一环）→ 5. 在你自己的仓库问一个问题，例如「谁调用 X，改名要改什么」→ 6. 故意问一个代码里不存在的符号，观察它是否返回「0 unresolved」并给出完整性检查（这一步验证它是否真的在解析而非猜测）→ 7. 跑 vesalius stats，确认 Claude 确实调用了它（若调用数为 0，回到 Vesalius 的 FAQ：先按名要求一次「use vesalius to find who calls X」，因为预加载不等于会被调用）→ 8. vesalius setup --undo 验证可完全回退 → 9. 在自己的代码上跑一次它自己的 benchmark harness（docs/benchmark/run_benchmark.py）以获得对自己代码库的数字 第 6 步是唯一能证伪「它真的在解析」的步骤（与 HackiOS 的 checks.md 同构）；第 7 步是本项目的核心价值所在——没有 stats，agent 调没调用根本不可见；第 9 步能给出比 README 更贴合自己代码库的数字

最值得关注的方向

今天四个项目分属四个领域（Apple 内核移植 / 形式化验证 / 归档工具 / 代码图 MCP），没有一个共同的技术主题。但有一条结构在四个项目里同时出现，而且四个项目各自用完全不同的形式把它实现了一遍：

项目 它怎么表达「边界」
HackiOS 「我们的检查会骗我们」——docs/checks.md 十一让检查说谎的方式 + 一条对策
oss-verify 「我证明了什么 / 我没证明什么」——独立的 What a proof does not say 一节 + 逐条 statement 状态
hatchzip 「这个操作会毁掉输入」——AGENTS.md 的绝对不变式 + 「能拒绝的先拒绝」
Vesalius 「我第一轮失败了 / 我在哪些问题上更差」——benchmark 的失败轮次 + 逐类质量表

这是连续第二天出现同一个结构（10-23 记录了「把边界、缺口与失败模式写成可核验的文档」），但今日的形式更进了一步：10-23 的四个项目把边界写在文档里，今日的四个项目里有三个把边界写进了可执行的检查或不可变式。 HatchiOS 的 checks.md 讲的是「怎么验证你的验证」，oss-verify 讲的是「怎么让机器读出你的证明边界」，hatchzip 讲的是「怎么让代码拒绝而不是补救」，Vesalius 讲的是「怎么让失败的实验留下数据」——这四个都在回答同一个问题：如果我的判断是错的，我怎么知道？

跨项目的第二个观察（本日最实用的一条）：fork-star 在本日四个项目之间依然完全不可比，但分界线的位置与昨日完全一致。

项目 ⭐ ⑂ fork-star 归类 机制解释
oosexgang/hackios-xnu-kernel 1,064 183 17.2% 可改造型 fork 去移植自己的机型——common/new-device.sh + docs/PORTING.md + 设备 profile 模板
theorem-labs/oss-verify-proofs 92 6 6.5% 可读型 fork 去读证明语句（statement 是公开的 Rocq/Markdown 文本）
xevrion/hatchzip 888 17 1.9% 不可改造型 不需要 fork，只需下载 release asset（3 个 release × 22 个 asset）
haplollc/Vesalius 61 1 1.6% 不可改造型 不需要 fork，只需 brew 安装

推断（不构成事实）：本日四个数据点继续显示 fork 比例与「项目是否允许/需要用户改造」相关，而与项目质量、热度或价值无关。这是连续第四天观察到同一条分界线（10-21 记录 1.1%–18.6%，10-22 记录 5.5%–35.9%，10-23 记录 0.5%–15.7%，本日 1.6%–17.2%）。但这仍是四个数据点，不足以支撑任何普遍结论。

必须同时说清的第三点：本日没有事件驱动的热度洪峰，取而代之的是一条生态层面的批量异常。 这比事件洪峰更值得记录，因为它改变了「今日热度排序」的读法：

第四点必须说清的：本日四个项目没有两个可以直接投入生产。

项目 现在能不能用 卡在哪
HackiOS 不能（除非你有一台 POCO X5 Pro 5G 或愿意跑 QEMU） 需要从 Apple CDN 下载 7.4 GB；453 个 shader 中 163 个不可用；蜂窝/蓝牙/App Store 不支持；APSL 2.0 的分发条件
oss-verify 不能（作为普通工具） 它不是工具而是证明集；证明只对静态 riscv64 有效；没有任何 halts 证明；一次检查最多 20 GiB 内存
hatchzip 可以，但有条件 未代码签名；APFS 与 NTFS 上的打洞未验证（大文件内部省空间在 macOS/Windows 上不生效）；只能在支持截断的文件系统上工作
Vesalius 可以，但平台受限 只支持 Apple silicon + macOS 15+；调用图只有 4 种语言；无 LICENSE 文件

本日唯一「今天就能用且今天就能验证」的项目是 hatchzip 与 Vesalius（后者限平台）——而它们恰好是本日 fork-star 最低的两个（1.9% / 1.6%）。 这是本日最实用的一条读法：热度与可用性在本日再次完全脱钩，而且脱钩的方向与 star 排序相反。

重点项目深度分析（top 3）

Deep Dive 1：oosexgang/hackios-xnu-kernel（本日信息量最大的单项目）

项目定位。 在 Android 手机硬件与 QEMU 上启动 Apple 开源的 XNU 内核（xnu-8796.121.2 = iOS 16.5 的内核）并在其上运行未修改的 iOS 16.5 用户态，1.7 天 1,064⭐ ⑂183（fork/star 17.2%，本批最高），C，APSL 2.0（LICENSE 文件）/ NOASSERTION（GitHub API），20677 KB，subs 4，oi 7，全仓库仅 6 个 commit，contributors API 返回 2 人。

为什么它值得比它的 star 数更多的注意力。 因为它是48 小时内出现的第三个 Apple 内核移植项目，而它在最关键的那个决策上与前两个相反——前两个都坚持「不改内核」，它直接编译 Apple 开源的 XNU 源码并打补丁。三个项目、三种路线、同一周，这个事实本身就是本日最强的结构性信号：Apple 硬件逆向已经不再是一个人的黑客项目，而是一个有多种已验证技术路线的领域。

它的技术亮点：

  1. 自写 EFI loader（xnuloader/loader.c，clang + lld-link，不用 EDK2），它常驻内存、提供 USB fastboot 协议链路、看门狗、接收内核日志。
  2. UEFI 移植（uefi/ 为 Project Silicium 移植 + mkxnuimg.py 打包），每个 release 附带 hackios-redwood-boot.img——redwood UEFI 内嵌自写 loader，可直接 fastboot boot，且不含任何 Apple 文件。
  3. Apple 闭源驱动的替代实现（IOSurface / IOMobileFramebuffer / AppleKeyStore / 网络栈 / minicrypto 替 corecrypto / AMFI 与 Sandbox 替身）。
  4. Metal 驱动工作（Mesa 25.0.7 + AIR→ir3 前端），456 个系统 shader 中 293 个已在 Adreno 642L 上运行（62.9%）。
  5. Linux Wi-Fi 驱动层（WCN6750 via ath11k + LinuxKPI，wifi/lx/）。
  6. 「用户态一个字节未改」的实现方式：缺失部分由内核替代驱动或 DYLD_INSERT_LIBRARIES 注入库补齐（kern.exec_inject），注入进 backboardd / SpringBoard / mediaserverd，mediaserverd 获得自写 CoreAudio 输出设备。
  7. 双运行目标：真机（fastboot boot，不写闪存，重启即回 Android）与 QEMU（无需真机，20 分钟会话，2–3 分钟出锁屏）——QEMU 路径让任何人都能复现，这是它 fork-star 17.2% 的机制解释。

风险。

是否值得跟踪。 值得，且跟踪方式应是「它会不会扩到第二台设备」而非「star 数」。 它是本日唯一一个把「可复现路径」（QEMU）与「真实硬件路径」（真机）同时提供的项目，也是唯一一个把「Apple 内核可以是补丁目标而不只是黑盒」的路线证明出来的项目。观察重点：(1) docs/checks.md 是否继续更新（这是它最独特的资产）；(2) 163 个不可用 shader 是否继续下降；(3) 是否出现第二台设备 profile（决定它是可移植方案还是封闭作品）；(4) redwood.patch 的规模与是否随 XNU 版本更新；(5) 许可表述是否补齐自有代码条款。

Deep Dive 2：theorem-labs/oss-verify-proofs（把「我证明了什么」做成机器可读的形式）

项目定位。 针对 OSS-Fuzz 的 fuzz target 给出机器检验的 Rocq 证明，1.5 天 92⭐ ⑂6（fork/star 6.5%），Rocq Prover，MIT，2142968 KB ≈ 2.1 GB（本批最大），subs 0，oi 1，topics 6，全仓库仅 2 个 commit，contributors API 返回空数组。

为什么它值得比它的 star 数更多的注意力。 因为它证明了一件本日报其他项目都在做但没做到的事：把边界变成可执行的检查，而不只是可读的声明。 对比本日其他三个项目——HatchiOS 讲「怎么验证你的验证」，Vesalius 讲「我的实验失败了」，hatchzip 讲「先拒绝」——oss-verify 讲的是「让机器读出我的证明边界，并且让检查器真的会拒绝」：oft check 在 Print Assumptions 阶段拒绝任何不在 toolchain/allowed-axioms.txt 里的假设。一个只会通过的检查器和一个会拒绝的检查器，价值差一个数量级——而后者可被独立验证。

三个技术观察点：

  1. 证明的对象是二进制而非源码。 这让证明可核验（build record 含每个二进制的 SHA-256），但也让它与 OSS-Fuzz 实际的 x86-64 动态构建之间存在可核验的落差——README 自己列了这一条。
  2. LPS 是形式化模型，因此它的不完备性被转移成了证明的适用性边界。 作者的处理方式是把边界写成句子而不是脚注：「A proof is only as good as LPS.」并且 docs/semantics.md 专讲设计原则与其极限，analyses/known-issues.md 逐条给出每个未证 statement 的原因（229 条被模型阻塞，多数正是因为模型不覆盖线程与 CPU affinity）。
  3. 许可分层是一份值得抄的文档实践。 NOTICE 区分「我们写的」与「由 Anthropic 授权的证明派生而来的」，LICENSES/ 存两份许可文本 + NOTICE，且每个此类证明的 build record 指名这三个文件。在一个 AI 辅助证明越来越多、而训练数据来源许可越来越敏感的时间点，这种处理方式值得被直接借鉴。

风险。

是否值得跟踪。 值得，但作为「方法与文档规范的样本」而非「可用工具」。 观察重点：(1) 20,164 条 statement 中 open 的 19,797 条下降速度（这决定 LPS 支持面扩张的节奏）；(2) 是否出现 halts statement（那会显著改变主张强度）；(3) 是否开始接受外部项目的证明（contributors 是否从 0 变成非 0）；(4) LPS 的模型覆盖扩展（线程、CPU affinity 是当前 229 条阻塞的主因）。

Deep Dive 3：xevrion/hatchzip（本日唯一「今天就能用」的项目，也是唯一带绝对不变式的）

项目定位。 就地解压超大归档，边解边把归档从尾部截断，2.5 天 888⭐ ⑂17（fork/star 1.9%，本批最低），Rust，Apache-2.0，1990 KB，subs 1，oi 8，contributors API 返回 1 人，3 个 release × 22 个 asset。

为什么它值得比它的 star 数更多的注意力。 因为它是本日唯一一个「我现在就能下载、用它、并且能自己验证它」的项目——而它同时是本日 fork-star 最低的项目。这两件事同时成立，本身就是本日最强的一条读法。

它的技术亮点：

  1. 理由链而非技巧。 只能从尾部截断（打洞在 FAT32/exFAT 上不支持且各系统行为不同）→ 每格式的 unit 划分 → 倒序解压 → 每批截断到最低 unit 起点。每一步都有「为什么不能是别的」。
  2. 可复算的硬拒绝。 7z 默认设置的单个 solid block 无法在解出前释放空间 → 在碰任何东西之前拒绝并解释原因。
  3. journal 作为崩溃安全的真相源，配 <archive>.hatchzip-tail 保存索引尾部（在截断移除它之前复制并记 CRC-32），已截断区域读作零让 zip crate 反扫与 tar 解析都正确停下。
  4. 实测数字而非估计：README 的每一个数字都来自真实硬件（AGENTS.md 明令「Every number in the README and docs is measured on real hardware, never estimated」），并附测量环境。
  5. 平台差异被收进一个模块：AGENTS.md 明令 platform/ 之外禁止 cfg(target_os)/cfg(windows)，CI 三平台跑测试。

风险。

是否值得跟踪。 值得，且优先级在本日「可立即采用」类别中最高。 观察重点：(1) 签名与公证（这是企业落地的必要条件）；(2) APFS/NTFS 打洞验证；(3) 是否支持更多压缩方法与加密 7z；(4) journal 格式的稳定性（跨版本恢复的兼容性）；(5) 贡献者数量——单作者项目的连续性是真实风险。

风险与机遇

机会

  1. ⭐ 「我的检查会骗我」成为一份可复制的文档类型。 HackiOS 的 docs/checks.md 把十一让检查说谎的方式写成了带真实代价的条目，并给出对策「每个例外都有自己的列、名字和数字」与「a denominator lies as quietly as a summand」。这个方法论可以移植到任何写测试、跑 benchmark、做验证的团队——包括本日报的读者自己的项目。
  2. ⭐ 「不会失败的检查器」与「会失败的检查器」应当被区别对待。 oss-verify 的 oft check 在 Print Assumptions 阶段拒绝越界公理，且允许公理被逐条列出。这与上一条是同一件事的两面：如果你的检查只会通过，它就不构成证据。
  3. ⭐ 破坏性操作也可以有绝对不变式。 hatchzip 的「journal 在文件持久化之前不认领它；归档绝不截断到 journal 未认领的条目之后」是可以直接照抄的形式。更重要的是它配了一条组织纪律：「State what you did not verify. An honest gap costs less than a confident wrong claim.」
  4. ⭐ 失败的实验轮次值得写进 README。 Vesalius 的第一轮 24 次里 agent 只调用了 2 次，作者把它写成 benchmark 的第一段而非附录——这让读者知道「20/20」这个数字是怎么来的，也让人能判断该改动是否真的有效。
  5. ⭐ 许可分层的处理方式（oss-verify 的 NOTICE + LICENSES/ + build record 指名）值得被抄进任何混合来源的项目。 本周已记录四类 license 元数据问题（NOASSERTION / null / 无 LICENSE 文件 / APSL 未标注），这说明「许可证表述」已经是开源发布的一个真实故障点。
  6. Apple 内核移植在一周内出现三条独立技术路线（UEFI 伪平台契约 / EL2 hypervisor / 编译开源 XNU 打补丁），且本批四条路线都把「Apple 私有输入不得入库」写成了仓库级制度。 这既是领域成熟度的信号，也是一份现成的合规清单模板。
  7. 本日出现的可复现路径值得利用：HackiOS 的 QEMU 路径（无需真机、20 分钟会话、2–3 分钟出锁屏）与 oss-verify 的 oft check（可在自己环境独立复现检查流程）——这两个是本日报中唯二能由第三方独立执行完整验证的项目。

风险

  1. ⚠️ 本日最刺眼的一条是生态层面的批量行为。 2026-10-22 12:24–12:28 之间至少 11 个仓库在约 8 分钟内集中发布，owner 名全部为 12 位随机字符串，其中 10 个是 ESP 外挂 / 刷量机器人 / 账号切换器 / 私信轰炸器。三项交叉证据（owner 名长度、创建时间聚集、topics 与命名模板）共同指向批量账号行为。 后果是：搜索结果里的 star 有一部分是「被推到首页的注意力」而非「被采用的信号」，今日任何基于 star 排序的选型都需要先过滤这一层。
  2. ⚠️ 许可问题在本日新增两类，且其中一类比以往严重。 HackiOS 的 LICENSE 是 APSL 2.0（copyleft + 专利报复条款），而 GitHub 侧 NOASSERTION 且 README/NOTICE 未说明自有代码条款——APSL 对「External Deployment」有明确条件，误判会直接影响商业可用性。Vesalius 则是根本没有根级 LICENSE 文件（tree 递归查询确认），按默认版权保留处理。这两类都不是「扫描器识别失败」而是「表述本身有实质法律含义」，必须人工阅读。
  3. ⚠️ oss-verify 的 138 条证明中没有任何一条证明 halts。 「不触发 sanitizer 错误且两构建行为一致」不等于「程序会终止」——一个能证明不崩溃却可能挂死的库，在实践中仍然是有问题的。作者把这一点写在 README 的独立一节，但只读标题的读者会高估其主张强度。
  4. ⚠️ 三处「声明的能力」目前没有独立复现记录。 HackiOS 的真机截图与 QEMU 会话、oss-verify 的证明正确性（依赖一个作者声明为「best effort and not complete」的 LPS）、hatchzip 的「每个文件逐字节一致」对比表——全部是作者自述。本日报无法独立验证其中任何一项。
  5. 单作者 / 小团队项目的连续性是真实风险。 hatchzip（contributors 1 人）、Vesalius（contributors 1 人，3 个 commit）、HackiOS（contributors 2 人，6 个 commit）、oss-verify（contributors API 返回空数组，2 个 commit）——本批四个项目全部处于「一两个人撑起整个项目」的状态，且三个可立即采用的（hatchzip、Vesalius、以及部分 QEMU 路径的 HackiOS）都在其中。
  6. ⚠️ 本日四个项目没有两个可以直接投入生产，且热度排序与可用性完全脱钩。 1,064⭐ 的 HackiOS 不能商用部署（许可 + 硬件 + 功能缺口），92⭐ 的 oss-verify 是证明集不是工具，888⭐ 的 hatchzip 与 61⭐ 的 Vesalius 反而是今天就能用的两个——这是连续第二天记录到「热度与可用性脱钩」，且本日脱钩方向与 star 排序相反。
  7. Android TV 去广告赛道继续第 7 天有新项目，但今日仍不重复建档。 Gathin23/cleanyourtv 已达 27,708⭐ ⑂3,118（NOASSERTION，19 topics），simbasjungles/free-my-tv 3,920⭐、pengchujin/aerial-tv 3,796⭐、humblemuzzu/dumbtv 1,385⭐、Ansub/tv-detox 1,374⭐、mihirgupta0900/tv-home 424⭐、lesnolie/Tigris 413⭐、nthnclrk/CleanFrame 509⭐、mrcen3204097569-spec/lean-electron-vue 100⭐。该赛道已在 10-19/10-20/10-21/10-22/10-23 五份日报完整记录，今日仅记为赛道延续性证据，不计入趋势排名——重复计入会让趋势指数失真。唯一值得注意的是 CleanFrame 的自我定位：「A personal home screen for Samsung The Frame. A starting point to fork and adapt.」——这是一条直接印证本日 fork-star 分界线的证据。
  8. 延续跟踪项目本日数据：deepseek-ai/DeepInfer 21,056⭐ ⑂2,322（subs 50，10-23 为 43）、colinhacks/reylo 1,028⭐ ⑂8（subs 2，10-23 为 0）、UniXNU/UniXNU 856⭐ ⑂148（subs 4）、Macintosh/Snapintosh 745⭐ ⑂43（subs 7，10-23 为 4）、oosexgang/hackios-xnu-userland 328⭐ ⑂116。⭐ 重要变化：Acelogic/Snapintosh 已改名为 Macintosh/Snapintosh（组织 Acelogic → 组织 Snapintosh，组织创建于 2026-10-23T05:28:04Z），且主仓库已拆分为 8 个仓库（Macintosh/Snapintosh 745⭐、Macintosh/q1n1 35⭐、Macintosh/air2ir3 / SnapAdreno / SnapI2CHID / SnapMetal / SnapQCC2072 均 0⭐ 新建、Macintosh/.github 组织档案）。今日不重复建档，但这一拆分是本日 Apple 内核移植三路线格局中的重要结构变化。

证据边界总结

项目 关键事实（可核验） 推断（不构成事实） 待观察（待后续数据）
oosexgang/hackios-xnu-kernel C + LICENSE 首行 APPLE PUBLIC SOURCE LICENSE Version 2.0 - August 6, 2003 而 GitHub license.spdx_id 为 NOASSERTION + 20677 KB + 1.7 天 1,064⭐ ⑂183（fork/star 17.2%）+ 全仓库仅 6 commits、contributors API 返回 2 人 + subs 4 oi 7 + topics 为空数组 + releases API 返回 1 个（v0.1.0 published 2026-10-22T06:42:07Z，唯一 asset 为 hackios-redwood-boot.img）+ 定位「boots Apple's open-source XNU kernel (xnu-8796.121.2, the kernel of iOS 16.5) on Android phone hardware and runs the unmodified iOS 16.5 user space on top of it」+ 「The iOS programs, frameworks and dyld shared cache are not changed by a single byte」 + 两处运行（POCO X5 Pro 5G redwood / Snapdragon 778G，fastboot boot 不写闪存；QEMU aarch64，20 分钟会话、2–3 分钟出锁屏）+ What works / Does not work 两列表格（不可用：蜂窝、蓝牙、本内核下充电、App Store 与 Apple ID 登录（无 Secure Enclave，FairPlay daemon 退出）、视频与实况照片）+ Metal 456 个系统 shader 中 293 个已在 Adreno 642L 上运行 + Wi-Fi WCN6750 via ath11k（55–90 Mbit/s）+ 8 核（cpus=8，大核 2.4 GHz，约 20 s 到锁屏）+ iOS 写入数据跨重启存活（var_store=1 ufs_write=1） + Sileo + Procursus + SSH + 「It is a research bench, not a ROM」 + ⭐ docs/checks.md「How our own checks lie」十一让检查说谎的方式（被跳过的检查没有计数 → 68+3+7=78 把未检查项算成匹配；空集检查打印「0 of 47」与诚实的零无法区分；patch -s --dry-run 返回 0 却不说话；日志中段被丢弃；grep 视野漏守卫；看门狗 26/26 零漂移；「a measurement that cannot fire looks exactly like an event that did not happen」；「missing information reads as a missing problem」）+ 两仓库分工 + 两仓库均明写「No Apple files are in either repository」 + 设备移植路径 common/new-device.sh + docs/PORTING.md + 设备 profile（common/devices/{redwood,qemu-virt,_template}.conf） 推断：6 commits + 2 contributors 支撑 1,064⭐ 说明 star 度量的是话题吸引力而非社区规模；推断：fork/star 17.2% 与「fork 去移植自己机型」的路径直接对应（QEMU 路径 + 设备模板是证据）；推断：三条 Apple 内核移植路线在一周内并存说明该领域已从个人黑客项目变成有多种已验证技术路线的领域 待核验：仓库自有代码的许可表述缺失（LICENSE 只有 APSL 2.0 原文，README/NOTICE 未说明自有代码条款）· APSL 2.0 的 External Deployment 条件对本项目分发的实际影响 · xnu/redwood.patch 的改动规模与 xnu/files/ 的内容（本窗口未取）· 163 个不可用 shader 的构成与继续下降的路径 · 文档给出的 docs/checks.md 十一项是否对应实际发生过的事故（作者自述每条都付出过代价，本日报无法核验）· 是否出现第二台设备 profile · QEMU 会话与真机截图无第三方复现记录
theorem-labs/oss-verify-proofs Rocq Prover + MIT + 2142968 KB ≈ 2.1 GB + 1.5 天 92⭐ ⑂6（fork/star 6.5%）+ 全仓库仅 2 commits、contributors API 返回空数组 + subs 0 + oi 1 + topics 6 + releases API 返回 3 个（v2026.10.0 含 427 个 asset；v2026.10.0-src 含 851 个；sources-v1 含 2 个）+ 定位「Theorem statements about OSS-Fuzz fuzz targets as compiled RISC-V binaries, and machine-checked Rocq proofs of them」+ 「Each proof is about compiled binaries, not source code」 + 60 个 entry point 在 25 个库上有证明，用 Rocq 9.2.0 检查，陈述于 LPS + 「LPS is best effort and not complete… A proof is only as good as LPS」 + agreement statement 定义（plain build 未超预算的每个输入上，sanitizer build 不触发错误且两者可观测行为集合相同；'every input' 含参数/环境变量/文件/stdin；'error' 含崩溃/无效内存访问/abort()/失败的 UBSan 检查/LPS 无法解释的步骤；'observable behaviours' 含标准流与连接的字节及顺序/退出状态/文件最终内容；内存预算是前提：ASan 类 2 GiB、UBSan 类 16 GiB）+ ⭐「What a proof does not say」六条（不证明库正确、只覆盖单入口点可达代码、只针对 clang 20.1.8 + musl 的静态 riscv64 而非源码也非 x86-64 构建、在 LPS 中为真、本次发布无任何 halts 证明故不能排除永不终止的运行）+ 规模：1,381 个 OSS-Fuzz 项目中 427 available（781 language pending / 97 not yet built / 3 needs model support / 3 no compiler / 32 no harness / 6 excluded / 32 held），2,148 harnesses，20,164 statements = 138 proved / 0 known false / 0 suspected false / 229 blocked by the model / 0 withheld / 19,797 open，8,578 个二进制随发布附上、0 withheld，2,141/2,148 有全部四种构建 + analyses/known-issues.md 逐条列出未证 statement 及原因（如 arrow/arrow-csv-fuzz 因「查询 CPU affinity 并启动线程，模型尚未覆盖」blocked）+ 可核验性：每个证明在 proofs/<project>/<harness>/provenance/ 有 build record（上游仓库与 commit、harness 文件、recipe、编译器、构建器镜像、static-asan commit、编译与链接 flags、每个二进制的 SHA-256、许可）；oft check 校验 SHA-256 → 构建内存映像与 statement → 编译证明 → 编译 wrapper → 读取 Print Assumptions 并拒绝任何不在允许列表的假设 + 公理边界：toolchain/allowed-axioms.txt 仅含 Rocq 原生整数/数组/字符串类型规范 + 6 条标准库公理（classic / functional_extensionality_dep / constructive_indefinite_description / propositional_extensionality / sig_forall_dec / sig_not_dec）+ checker image 固定 sha256:cc9ae43a9f4b0dd59d7c8d30727d36e039bfe72a2a9f9c4a99c68e413037e902 + 16 核上一次证明检查最多需 20 GiB 内存（每核编译一个文件）+ CI：release-check 每次 push 到 main 与每周各跑一次并检查每个已提交证明，pr workflow 检查 PR 改动，weekly workflow 无缓存全量检查 + 许可分层：NOTICE 明确自有部分 MIT，「由 Anthropic 以 Apache-2.0 或 MIT 授权的证明派生而来的保留那些许可与文件头」，LICENSES/ 存 anthropic-proofs-LICENSE（Apache-2.0）+ anthropic-proofs-LICENSE-MIT + anthropic-proofs-NOTICE，每个此类证明的 build record 指名这三个文件 推断：subs 0 + 2 commits + contributors 空数组 = 机构发布而非社区共建，且外部贡献者痕迹为零；推断：229 条 blocked by the model 集中于线程与 CPU affinity，说明 LPS 的扩展瓶颈清晰；推断：「agreement 已证 138 条而 halts 一条未证」反映模型完备性而非作者取舍 待核验：LPS 作为公开声明为不完备的模型，其与 Linux 的具体差异清单（docs/semantics.md 本窗口未取）· 19,797 条 open statement 的下降速度（决定 LPS 扩张节奏）· 是否接受外部项目提交证明（contributors 是否从 0 变为非 0）· 是否存在 halts statement · 2.1 GB 仓库对 clone 的实际负担与 CI 拆 job 后的总时长 · tools/oft/ 的具体实现与人工介入点 · 证明工作的实际人力投入与商业资助情况
xevrion/hatchzip Rust + Apache-2.0 + 1990 KB + 2.5 天 888⭐ ⑂17（fork/star 1.9%，本批最低）+ subs 1 oi 8 + topics 12 + contributors API 返回 1 人 + 3 个 release（v0.1.0 2026-10-22T11:12:59Z / v0.1.1 13:20:47Z / v0.1.2 2026-10-23T14:18:16Z，每个 22 个 asset：Linux tar.gz、.deb、.rpm、AppImage、macOS aarch64/x86_64 dmg、Windows x64 安装器）+ 定位「Extract huge archives in place: the archive shrinks as your files hatch, so you only need room for the output」+ 问题量化：180 GB 归档解出 200 GB，WinRAR/7-Zip/unzip 需 380 GB，HatchZip 只需略多于 200 GB + ⭐ 技术理由链：只能从尾部截断（从前/从中删除需打洞：Linux fallocate / Windows FSCTL_SET_ZERO_DATA / macOS F_PUNCHHOLE，FAT32 与 exFAT 不支持打洞且各系统行为不同）→ 每格式 unit 划分（ZIP 一 entry、7z 一 solid block 或非 solid 时一文件、tar 一 entry 含长名/pax、.tar.gz 整个归档从前端解）→ 倒序解压 → 每批截断到最低 unit 起点 → 7z solid block 只能从头解码，最大 unit 即主要成本（需「输出 + 约等于最大 unit」空间）→ 7z 目录与空文件无数据只有头条目构成额外 unit，先做 + ⭐ 唯一硬拒绝：7-Zip 默认设置把整个归档放进一个 solid block → 在碰任何东西之前拒绝并说明原因 → ⭐ 对比表（同一份 200 MB 数据 21 文件、220 MiB tmpfs、约 50 MB 空闲）：ZIP 180 MB → unzip 在第 6/21 个文件耗尽空间 vs HatchZip 完成且逐字节一致；7z 25.01 -ms=20m（10 solid block）需 380 MB vs 0.64 s 完成；7z 分 5 卷各 40 MB 需 380 MB vs 完成、卷逐个删除、峰值 210 MB；tar 需 400 MB vs 0.12 s 完成；7z 默认设置 → 拒绝。速度：ZIP 0.25–0.35 s vs unzip 6.00 的 1.48–1.50 s（含一次 unzip 跳过的 fsync）。测量环境：Fedora 43、Intel Core i7-14700HX、SK Hynix NVMe SSD、热页缓存，空间测试 220 MiB tmpfs、速度测试 ext4，速度来自并行解压故单巨型文件按单核速度 + ⭐ AGENTS.md 绝对不变式：「The tool destroys its input. The invariant is absolute: the journal never claims a file before it is durable, and the archive is never truncated past an entry the journal doesn't claim.」「Anything that can be refused is refused before the archive is touched.」「Every number in the README and docs is measured on real hardware, never estimated.」「A behavior is not finished until it ran for real.」「Never run extract on an archive you can't recreate. It deletes it.」「State what you did not verify. An honest gap costs less than a confident wrong claim.」+ ⭐ 踩坑条目：storage::Reader 对已截断区域必须返回零否则每次恢复失败于 'No CDFH found'；tar 依赖同样的零停在截断点；Windows 必须用字节区间锁（锁归档会阻塞自己的读取线程）；Linux 用一次 syncfs 刷新一批所以每目录的 bug 只在 macOS 与 Windows 暴露；链接条目文件夹直到最后才存在；不硬编码单元数（7z writer 给某些空文件单独 block）；测试要同时覆盖 -ms=<size> 与默认设置；恢复时未提交文件仍占空间必须先删除再做空间检查 + 架构分层：crates/core（archive/ 每格式一文件 + storage.rs 唯一缩减归档字节 + engine.rs + journal.rs + session.rs + platform/{linux,macos,windows,unix}.rs）+ crates/cli（hatchzip 命令与端到端测试）+ crates/gui + crates/shell + journal 为 <archive>.hatchzip 的小 JSON，记录 format（zip/7z/tar/tar.gz 使恢复不必猜半 eaten 文件）与每卷原始长度及 CRC-32 + 保存尾部：截断前复制最后 unit 之后的全部内容到 <archive>.hatchzip-tail 并记 CRC-32，之后经 storage::Reader 解析（已截断区域读作零，零永不匹配 zip 签名，tar 把零读成归档结束）+ 平台约束：Rust 1.95（pin 在 rust-toolchain.toml），MSRV 1.89 为 File::try_lock，禁止 platform/ 之外使用 cfg(target_os)/cfg(windows)，CI 在 Linux/macOS/Windows 三平台跑测试 推断：fork/star 1.9% 与「只需下载 release asset、不需 fork」一致；推断：「可复算的硬拒绝」是本项目区别于普通解压工具的关键设计选择——它把失败前移到任何改动之前 待核验：APFS 与 NTFS 上的打洞未验证（README 明说 'NTFS and APFS not yet verified'）→ 「每 256 MiB 释放一次」的优化在这两个平台上不生效 · 未代码签名（Windows 需「更多信息→仍要运行」，macOS 15+ 需手动允许）· journal 实现的逐行正确性（唯一的安全屏障，本窗口未核验）· 7z 的加密与部分压缩方法是否全覆盖 · crates/gui/ 与 crates/shell/ 的职责 · 单作者（contributors 1 人）的项目连续性
haplollc/Vesalius Swift + GitHub license 字段为 null 且仓库根目录无 LICENSE 文件（?recursive=1 全树查询确认仅有 VesaliusKit/Sources/CTreeSitter/LICENSE、CTreeSitter/LICENSE-ICU、CTreeSitterGrammars/LICENSES/tree-sitter-{javascript,python,typescript}.LICENSE 与 vscode-extension/LICENSE，均为第三方许可）+ 7870 KB + 1.7 天 61⭐ ⑂1（fork/star 1.6%）+ subs 1 oi 1 + topics 10 + 全仓库仅 3 个 commit（2026-10-23T05:05:18Z / 21:06:09Z / 21:13:44Z）+ contributors API 返回 1 人 + releases API 返回 1 个（v2.1.0 published 2026-10-23T21:06:24Z，2 个 asset）+ 定位「A map of your codebase for Claude Code: an on-device code graph with an MCP server, a CLI, a Mac app and a VS Code extension」+ 五个只读工具 usages / feature_map / outline / architecture / dependency_cycles + usages 与 feature_map 预加载（约 +900 token 上下文），其余三个等 tool search 按需；所有工具只读 + ⭐ 两轮 benchmark：第一轮 24 次运行中 Claude 只在 2 次调用了 Vesalius → 作者判定那一轮 13% token 差距「主要是 run-to-run 噪声」并把失败写进 README（根因：Claude Code 把 MCP 工具藏在 tool search 后面而几乎从不搜索）→ Vesalius 2 按问题类型各配一个更锋利工具并预加载最常被问的两个 → 20/20 次全部调用；同一固定构建 2.1.307、同一模型与 prompt、只读工具，20 个真实问题 × 6 个代码库，一次带一次不带，一个 AI 评审对着代码里核实的 key 盲评 → token 中位数减 51%（95% CI 36%–62%；几何均值，普通均值 −44%，204k → 113k）、轮数减 43%、耗时减 41%、质量 −0.5 分（95% CI −1.6 到 +0.8，两边 97–98 附近），「某功能在哪」低 2.1 分（95% CI −4.2 到 −0.4）+ ⭐ 逐类质量表：谁依赖这个文件 5 题 −71%/+1.6、导入环 1 题 −74%/+2.2、谁调用这个 2 题 −56%/−0.2、变更影响 3 题 −42%/−1.0、功能在哪 5 题 −38%/−2.1、架构 2 题 −33%/−1.2、符号在哪 2 题 −8%/−1.7；20 题中 4 题 token 反而更多（+2% 到 +19%），11 题质量移动超过 1 分（3 更好 8 更差）；「每题只有一次运行一次评审，单题噪声很大，所以区间对问题做 bootstrap」 + 留出集 8 题（Vesalius 2 设计之后写的、来自两个从未用于构建它的代码库）减 44%（95% CI 12%–65%），另 12 题是对着建的 + 方法论边界：三个代码库是作者私有应用，答案 key 与 run transcript 保持私有（防泄漏进未来工具设计与训练数据）→ 无法精确复现；judge 指令公开于 docs/benchmark/grading_prompt.md，harness 公开于 docs/benchmark/（run_benchmark.py / analyze.py / make_report.py / extract_grades.py / results.json / results_v1.json / tasks.json）+ 对比表：调用图覆盖 Swift（经类型解析）、TypeScript、JavaScript、Python，其余 13 种语言只有词法；只跑 macOS 15+ Apple silicon；在仓库里不留任何东西（对比 CodeGraph 留 .codegraph/、graphify 留 graphify-out/）；setup 只加一条 MCP 条目与一条权限规则；无网络（CodeGraph 默认开匿名遥测与更新检查）+ setup 只做三件事（注册 vesalius mcp（Claude Code --scope user，检测到 codex 时也注册 Codex）、把 mcp__vesalius__* 加入 ~/.claude/settings.json 的 permissions.allow（--no-permissions 可跳过）、索引当前仓库）；从不写你的仓库、CLAUDE.md 或 hooks；--dry-run 先显示计划；vesalius setup --undo 可完全回退 + ⭐ 本地计数：vesalius stats 显示 Claude 问过什么（工具/调用数/token/每次答案中位耗时/完整性检查是否通过，从不记录你的问题、符号或代码，VESALIUS_STATS=off 或 --reset 可关闭/清空）；vesalius doctor 按 Claude Code 的方式启动 server 并检查每一环连接、它服务哪个仓库、索引有多新 + benchmark 中每题 2.65 次搜索/读/shell 调用 vs 无 Vesalius 时的 7.2 次 推断：61⭐ 与 subs 1 说明尚无采用信号；推断：「先承认第一轮失败再重做」比任何单轮数字都更能预测该工具是否会被真的用起来 待核验：无根级 LICENSE——按默认版权保留处理，这是「根本没有许可证声明」而非「识别失败」 · 索引的存储格式与查询后端（README 提到 vesalius query "<sql>" 对索引做只读 SQL，本窗口未取实现） · 索引刷新时机（ensureFresh 的增量判定）与 --no-refresh 的失效条件 · 调色板极窄的调用图在非 Swift 语言上的准确度损失有多少（benchmark 显示「符号在哪」−1.7 分，但样本仅 2 题） · 是否放弃 Linux/Windows 的理由（README 未解释） · 三个私有代码库的答案 key 与 transcript 无法核验

总证据边界： 本日全部元数据取自 2026-10-24 CST 06:00 前后（UTC 2026-10-23T22:13Z 快照）经 gh CLI 认证的 GitHub REST / Search API，README 与 docs/checks.md / docs/how-it-works.md / AGENTS.md / NOTICE / LICENSE / analyses/known-issues.md / docs/benchmark/README.md 原文经 Accept: application/vnd.github.raw 抓取，仓库结构经 git/trees/HEAD 与 ?recursive=1，历史与贡献者规模经 commits 与 contributors。「X 小时 / Y 天 Z⭐」按 created_at（UTC）到 2026-10-24 计算，总星数除以经过时长为下限粗估；本日报未做逐日 star 增量统计（需分页遍历 stargazer），因此任何「增速」表述都不能读作当日新增。 releases API 对 HackiOS 返回 1 个、oss-verify 返回 3 个、hatchzip 返回 3 个、Vesalius 返回 1 个——四个项目全部有可下载产物，这在本日四个项目中是罕见的共同点。subscribers_count 为 4 / 1 / 1 / 0（oss-verify 的 0 为本批最低，HackiOS 的 4 为本批最高）。topics 对 HackiOS 两仓库为空数组，其余三个分别 6 / 12 / 10 个。本日新增发现两类可核验的许可元数据问题：HackiOS 的 license.spdx_id 为 NOASSERTION 而其 LICENSE 首行为 APPLE PUBLIC SOURCE LICENSE Version 2.0 - August 6, 2003（APSL 2.0，copyleft + 专利报复条款，且 README/NOTICE 未说明自有代码的许可条款——依赖 license 扫描器判断「是否可商用/可内嵌」的工具会得到错误的默认答案），以及 Vesalius 仓库根目录没有 LICENSE 文件（全树递归查询确认只有第三方许可），GitHub license 字段为 null，按默认版权保留处理——这两类都不是「许可证识别失败」而是「表述本身有实质法律含义」。加上 10-22 记录的 php2shell-poc（spdx_id=null）与 10-23 记录的 UniXNU 与 Macintosh 两处 NOASSERTION，四天内累计四类共五例。本日没有 CVE 驱动的注意力洪峰（这是自 10-21 php2shell 事件以来的第二次无事件驱动日），取而代之的是一条生态层面的可核验批量异常：2026-10-22 12:24–12:28 之间至少 11 个互不相关的仓库在约 8 分钟内集中发布，owner 名全部为 12 位随机小写字母数字串，其中 10 个是 ESP 外挂 / 刷量机器人 / 账号切换器 / 私信轰炸器，三项交叉证据（owner 名长度一致性 + 创建时间分钟级聚集 + topics 与仓库名的模板化命名）共同指向批量账号行为而非有机增长——这意味着本日搜索结果中的相当一部分 star 是「被推到首页的注意力」而非「被采用的信号」。已过滤其余可核验 spam 模式（.github 作仓库名 + *-tool(s)/.github 命名 + 统一「🔥 …-bot」描述：dex-tool-best/.github 173⭐、df-tools-bn/.github 173⭐、onchain-trading-bot/.github 173⭐、onchain-whale-tracker-pc-desktop/.github 136⭐、mw-tools-123/.github 91⭐，均创建于 2026-10-23 02:10–13:04）。未纳入 key_projects 的候选：openmathmodel/open-math-harness（119⭐ ⑂12，Rust + Apache-2.0，能力型微内核 + 代理权限边界 + Lean 验证证明，README 明写「The full runtime currently relies on the Open Math OS deployment environment… does not yet provide a standalone local setup for interactive agents or proof search」，subs 0、仅 1 个 commit，作为架构样本有价值但部署依赖未解除，本窗口未取 AGENTS.md 原文故不建档）、EthanArbuckle/fairplay-decrypt（1,522⭐ ⑂234，NOLICENSE，DRM 规避，不建档）、7API/uncensored-ai-api（222⭐ ⑂62，规避模型安全护栏，不建档）、rossark0/rossark-motion-skill（381⭐ ⑂28，Swift 动画 skill，未取 README）、Spectrmachina/Ztrust（153⭐ ⑂0，零 fork 且承诺用 Zcash 前跑证明支付漏洞赏金，机制新颖但本窗口未取 README）、rolottr/bambu-bar（104⭐ ⑂6，Swift Bambu Lab 菜单栏应用，未取 README）、haplollc/Vesalius 对比的 CodeGraph / graphify / context-mode（未取 README，且 Vesalius 的对比表已提供其定位）。延续跟踪：Acelogic/Snapintosh 已改名为 Macintosh/Snapintosh（组织 Acelogic → 组织 Snapintosh，该组织创建于 2026-10-23T05:28:04Z），且主仓库已拆分为 8 个仓库（Macintosh/Snapintosh 745⭐、Macintosh/q1n1 35⭐、Macintosh/air2ir3 / SnapAdreno / SnapI2CHID / SnapMetal / SnapQCC2072 均 0⭐ 新建、Macintosh/.github 组织档案），今日不重复建档但记录此结构变化；deepseek-ai/DeepInfer 21,056⭐ ⑂2,322（subs 50）、colinhacks/reylo 1,028⭐ ⑂8（subs 2）、UniXNU/UniXNU 856⭐ ⑂148（subs 4）、oosexgang/hackios-xnu-userland 328⭐ ⑂116（subs 1）。今日最重要的判断不是「哪个项目最热」，而是四个互不相关的项目在同一天用四种完全不同的形式回答了同一个问题：「如果我的判断是错的，我怎么知道？」——HackiOS 讲「怎么验证你的验证」（checks.md 十一项），oss-verify 讲「怎么让机器读出你的证明边界，并且让检查器真的会拒绝」（oft check 拒绝越界公理），hatchzip 讲「怎么让代码在动手之前就拒绝」（7z 默认设置硬拒绝 + AGENTS.md 绝对不变式），Vesalius 讲「怎么让失败的实验留下数据」（第一轮 2/24 的失败被写进 README）。这四者都与 star 数完全无关，却构成本日跨领域最强的共同信号，且比 10-23 记录的「把边界写进文档」更进了一步——10-23 的四个项目把边界写在文档里，今日的四个项目里有三个把边界写进了可执行的检查或不可变式。 同一批数据里另有一条相反方向的信号值得同时记住：本日 star 最高的两项（HackiOS 1,064⭐ 与 hatchzip 888⭐）与本日最可立即采用的两项（hatchzip 与 Vesalius）并不重合，而本日 fork-star 最低的两项（1.9% / 1.6%）恰是这两个可立即采用的项目——热度与可用性在本日不仅脱钩，而且脱钩方向与 star 排序相反。

重点项目档案