89天变91天，他用欧盟委员会给测试打分

一个旅行者在欧洲度过整个夏天后，准备从里斯本离境。她算得很仔细：过去180天里，她在申根区待了89天。只剩一天余量。

自2026年4月10日起，欧盟的入境/出境系统（EES）会在边境记录每一次入境和每一次出境。真正算数的是这份记录。漏扫一次、出境日期记错一天、一段停留被拆成两段，她的89天就可能变成91天。而91天，在档案上就是逾期滞留。

法律留了一条路：欧盟条例（EU）2017/2226第52条允许当事人申请更正自己的EES数据。前提是她得知道记录错了，并且能证明。

这就是Ninety的由来。它计算申根90/180天规则下的停留天数，与EES记录比对，当边境的计数出错时，替用户起草第52条更正信。页面上每条规则都标注了出处（条例2016/399、条例2017/2226）。

差一天，就是全部

一个算错一天的计数器，比没有计数器更糟，因为人们会信它。所以这个产品真正的核心不是界面，而是证明屏幕上的数字对每一位旅行者、在每一次代码提交时都是正确的。

作者的做法是：引擎从不给自己打分。Ninety测试里的期望值，没有一个来自Ninety自己的引擎，全部来自外部：

• 欧盟委员会官方的短期停留计算器：14个公开场景全部吻合，14/14，在线可查。
• 直接运行委员会的计算脚本：400组输入逐字段比对，399/400在每个打印字段上一致，唯一差异逐行记录在案。
• 每次代码提交跑5000条模糊生成的旅行历史，每晚跑20000条。
• 一份独立参考实现，直接照条例2016/399第6(1)条写成：每次提交跑1200个用例，每晚20000个，其中一半落在边界上（第180天和第181天、2月29日、跨年、时钟调整）。
• 408个Vitest测试，变异得分94.47%。

换句话说，是欧盟委员会在给他的测试打分。而TestSprite负责证明：一个真人点击真实应用时，看到的也是同一个正确的数字。

TestSprite怎么接进来的

每个拉取请求都会生成一个Vercel预览环境，TestSprite对它测两遍：

• TestSprite V3（GitHub App）：54个端到端界面测试，每个都断言精确数值，其中一个测试校验全部14个比对计数。
• TestSprite后端（GitHub Actions里的命令行）：30个API与MCP测试，覆盖3个API端点，这3个端点同时也是3个MCP工具。

每个拉取请求跑84个TestSprite测试。两套测试都纳入主分支的7项必需检查，不可绕过，管理员也不例外。第7项是TestSprite的N/N闸门：它从同一提交上的两套测试读取真实计数，不接受任何低于N/N的结果。

这个闸门在最后一个拉取请求上证明了自己。#71的第一次提交读数是52/54，闸门拦住了合并。下一次提交读到54/54加30/30，闸门变绿，才允许合并。

后端测试变红时，会在拉取请求下自动留言：每个失败的测试、可能的原因、运行ID，以及只重跑这些测试的确切命令。每晚还有5个TestSprite测试跑在生产站点上。某个红色的夜晚，工作流自己开了第66号issue，随后第67号拉取请求把它关掉。这个循环在他睡觉时也在跑。

14个拉取请求先红后绿

这段循环故事不是手写的。一个脚本读取GitHub API（每个已合并的拉取请求、每次提交、每个TestSprite状态），生成迭代记录。截至#70，在64个已合并拉取请求和60个拉取请求上的99份TestSprite V3结果中，有14个拉取请求先红后绿：7个真实缺陷、1个界面加载状态问题、7份更严格的测试计划，没有一个是人为植入的。

TestSprite抓到的7个真实缺陷包括：比对表悄悄漏掉一个场景；规划器忽略了一段仍在进行中的停留，而这正是会变成逾期滞留的那类错误；已加载的场景在页面间丢失，导致比对和信件用了错误的历史；带参数刷新时再次清空已保存行程；证据表的差异单元格显示为空白；按Escape键后键盘焦点留在页面主体而不是“添加行程”；以及生产环境无法确认委员会计算器，后来改为运行一份存储且经过哈希校验的委员会脚本副本。

第57号拉取请求是故意先红的。代码审查发现8个缺陷，作者先写了8份TestSprite计划（TS45至TS52）并推送，TestSprite读出34/43。修复后升到42/43，最后那个红点暴露了上面提到的比对页缺陷。修完43/43，合并变绿。测试先行，抓到真缺陷，绿着合并。

对一个站在边境的旅行者来说，她不该需要怀疑自己的计数对不对。当欧盟委员会给数学打分、TestSprite守住每一次代码提交，Ninety才能告诉她：是对的。