v1.0.0 —— 首个公开预发布（测试版本）

v1.0.0 —— 首个公开预发布

CI 告诉你「测试通过了没有」。
这个工具告诉你「该做的测试有没有被做过」。

⚠️ 这是一个预发布（pre-release）。 功能完整、CI 全绿，但还没有人在真实项目上长期用过它 ——
只有作者自己的两个项目跑过。装上之前请知道这一点。

这一版验证到了什么

项	证据
6 个环境组合	✅ ubuntu / windows × Python 3.11 / 3.12 / 3.13 —— 全绿，每格 544 passed, 5 skipped
类型与风格	mypy 44 个文件无错误 · ruff check + format 干净
打包	sdist 与 wheel 能构建 · twine check 通过（CI 实测，不只是本地声称）
语料	29 条规则（每条都有正例 + 反例夹具）· 10 机制 × 6 不变量 · 4 个场景档案
离线可用	preflight-check demo 零 LLM、零联网就能跑出对比

本地是 546 passed + 3 skipped：多的那 2 条是验收测试，需要作者另一个项目在场（CI 上正确地跳过，而不是假装通过）。

推上 GitHub 之后，第一次 CI 就抓出来的问题

这一版之前的代码本地 545 条全绿，但它从没在真实的 CI 环境里跑过。第一次跑红了 4 条，
每一条都属于「装完之后才出现」那一类：

1. 子进程输出编码只钉了一头 —— 父进程按 UTF-8 解码，却没告诉子进程按什么编码写。
   英文 Windows 上代码页是 cp1252，子进程写不出非 ASCII 就直接崩在写第一行之前，
   stdout 为空；而这个项目里「空输出」的含义是「工具说它没发现问题」。
   一次真实的崩溃被读成了一次干净的结果 —— 正是这个工具最想防的那种错。
   本地是 cp936（编得出中文），所以一直没露出来。
2. find_tool 的测试断言假设「工具和 python.exe 在同一层目录」—— 那只在虚拟环境里成立，
   CI 上是非虚拟环境安装，控制台脚本在 Scripts/。错的是断言里的假设，不是实现。
3. ci.yml 缺 workflow_call —— 发布工作流用 uses: 复用它，而 GitHub 要求被复用的工作流
   必须声明这个触发器。少了它，推 tag 时整个发布运行会在校验阶段失败，
   而本地测试依然全绿。
4. 上面这条现在有测试守着了：新增的测试会扫描所有 uses: ./.github/workflows/*.yml 引用，
   要求被引用的工作流可被复用（把那一行删掉，它会立刻红）。

还没做的（说清楚比含糊好）

• 未发布 PyPI —— 发布工作流已经写好（可信发布，不需要 token），缺的是 PyPI 侧的项目配置。
  今天的 tag 已经把它跑到最后一步，上传会被 PyPI 拒绝（没有可信发布者），这是预期的。
• 矩阵覆盖 3/60 —— 60 个「机制 × 不变量」格子里只有 3 格有规则真的去查。这是最大的功能缺口。
• 问卷答案目前只进报告，还没有接到严重度 / 门禁上。
• 只在 2 个真实项目上验证过，换一种文档风格表现未知。

试它

git clone https://github.com/lddd1026/preflight.git
cd preflight
pip install -e ".[dev]"

preflight-check demo                 # ⭐ 离线：不配 Key、不联网就能看到对比
preflight-check run <你的项目>        # 确定性检查（零 LLM）
preflight-check mechanisms <你的项目> # 机制推导：这个项目该查哪些不变量

MIT 许可。踩过的 18 个坑写在 docs/PITFALLS.md ——
那可能是这个仓库里最值钱的一份文档。