证据

谁都可以声称某个 bug 已修复。本页展示修复本身、守护它的测试，以及当 bug 重新出现时该测试会失败的证据。

由 tools/prove_regressions.py 于 2026-10-03 生成 · 4 项中的 4 项回归测试已证明并非空洞测试。

每项证明是如何产生的

对修复后的代码运行回归测试：它必须通过。
编辑源码，重新引入原来的 bug。
再次运行同一个测试：它必须失败，并且是真实的断言失败。收集错误不算数：那意味着测试根本没有运行。
恢复文件，核验其 SHA-256 与原文件一致，然后重新运行：它必须再次通过。

助手告诉访客 webhook 会携带他们的对话内容。实际上它一点也不携带。

提交 e027e6b · 由 apps/gateway/tests/test_webhook_content_claim.py 守护

Webhook 负载有意只携带一轮对话的“形态”（事件名、时间戳、步数、额度），从不携带其内容。当被问到 webhook 是否包含对话时，助手回答：“是的，每个 webhook 负载都包含该轮的完整对话历史。”这与白名单测试所验证的保证恰恰相反。修复前实测为 6 次运行中出现 2 次编造。

修复的代码，测试运行	通过	`21 passed in 1.15s`
bug 恢复，同一个测试	已拦截	`8 failed, 13 passed in 1.20s`
文件已恢复，测试运行	通过	`sha256 a8d4cb0b10787eff…`

这个测试不是空洞的：bug 一旦复现，它就会失败。

我们曾让店主点击一个并不存在的仪表板卡片。

提交 b4a203a · 由 apps/gateway/tests/test_card_names.py 守护

知识库、文档和一个入门卡片都告诉所有者去找一张名为“Send turns to a webhook”的卡片。真实仪表盘上的卡片写的是“Send events to your own system”。这个名称是在编写知识部分时编造的，未经核实就扩散到了三个地方。实测：2 个设置类回答中有 2 个提到了一个从未存在过的控件。

修复的代码，测试运行	通过	`5 passed in 1.12s`
bug 恢复，同一个测试	已拦截	`3 failed, 2 passed in 1.23s`
文件已恢复，测试运行	通过	`sha256 f6348e1a5bbae209…`

这个测试不是空洞的：bug 一旦复现，它就会失败。

深色模式下的问候语以 1.73:1 的对比度渲染，几乎看不见，而当时的防护检查不可能发现这个问题。

提交 ca47f41 · 由 apps/studio/test/themeContrast.test.mjs 守护

通过在真实 iPhone 上截取的屏幕截图发现，而非来自任何测试。欢迎语颜色被硬编码为 #3a3a3c，在深色模式面板上对比度为 1.73:1，远低于 4.5:1 的最低要求，几乎无法阅读。每一位在深色模式下首次访问的用户都看到了它。修复方案让颜色改为通过主题变量 --pw-mist 取值，使其跟随面板变化；防护检查现在会为每组主题配色计算实际对比度，而不是仅仅相信设置了某个颜色。

修复的代码，测试运行	通过	`pass 5, fail 0`
bug 恢复，同一个测试	已拦截	`pass 3, fail 2`
文件已恢复，测试运行	通过	`sha256 54f8802b444b6194…`

这个测试不是空洞的：bug 一旦复现，它就会失败。

一次失败的轮次让访客在一个已断开的流上无限等待。

提交 4bcc691 · 由 apps/studio/test/streamError.test.mjs 守护

模型调用失败时，服务器正确发送了错误帧，但组件把消息写进了一个已被治理追踪分支隐藏的元素，而且从未折叠追踪。访客看到“正在读取你的消息”在一个早已失败的回合上无限闪烁：没有报错，没有恢复，也无从得知。错误文本赋值正确，却没有渲染到任何地方。这是在 API 账户余额耗尽导致的一次真实故障中发现的。

修复的代码，测试运行	通过	`pass 4, fail 0`
bug 恢复，同一个测试	已拦截	`pass 2, fail 2`
文件已恢复，测试运行	通过	`sha256 54f8802b444b6194…`

这个测试不是空洞的：bug 一旦复现，它就会失败。

运维记录

平台背后有什么，哪些尚未测试。只列出脚本或日志能证明的内容。

备份：每晚 03:17 UTC，pg_dump --clean --if-exists，gzip；每次运行后推送到私有 git 远程仓库；最新一次为 20261003T031701Z；保留 29 份转储。
恢复演练 2026-10-03：转储 20261003T031701Z 在 2 s 内恢复到同一主机上的一个一次性 pgvector/pgvector:pg16 容器中：34 个租户、270 行知识数据、47 张表。该转储生成于 03:17 UTC；13:26 UTC 时，计划执行的演示清理任务删除了一个超过 30 天的废弃演示租户（见网关日志），因此恢复结果比演练时的线上环境多一个租户。
回滚：站点：tools/deploy-site.sh --rollback（再一次切换符号链接，指回上一个版本）；Studio：tools/deploy-studio.sh --rollback（上一个镜像，经过健康检查）。
恢复目标：不作承诺。每晚的转储将数据丢失限制在一天以内；未声明恢复所需时间。
未测试：超出单实例的负载；多区域故障切换；恢复到另一台主机。

来自 docs/ops-record.json，由恢复演练写入（docs/runbooks/db-backup.md）。

这不能证明什么

这些是我对自己代码进行的自查。它们表明特定的测试能捕获特定的 bug，但并不表明系统不存在其他 bug，不表明审计是全面的，也不表明有任何独立方审查过它。测试工具就在代码仓库里；运行它即可核验这一说法。

PANTHEON · 来验证：攻击线上系统 · 审计记录 · 演练记录 · 作品 · 简历