convex-self-heal

受控的生产环境自愈循环

Sentry/Datadog/Vercel 可以从错误转到调查，再到起草 PR，但它们把后端视为黑盒，并在需要人工合并时停下，只留下未经验证的差异。Convex 可以完成它们做不到的步骤：由于错误记录存在于用户自己的部署中，修复也可以在该部署的预览环境中演练，因此平台会在任何人审查之前，依据真实的不变量验证修复。这项能力是组合式流程的压轴环节——它串联起 sentinel（捕获）→ findings bus（诊断）→ 修复器（修复）→ migrate-rehearse/tsc/probe（验证）→ 人工 PR（决策）→ deploy-guard（发布）。合并按钮仍由人掌控；机器会完成此前的一切，包括证明修复有效。

工作流

1. GUARD：deploy-guard——此循环会读取生产环境并提出生产环境变更；对部署进行分类并公告，预先取得对循环范围的长期授权（哪些类别的修复可以自动准备，哪些必须始终推迟）。绝不自动合并；人工合并是不可逾越的边界。
2. CAPTURE：要求使用 sentinel（在写入时对用户自己部署中的生产错误进行脱敏）。如果没有 sentinel，就提供安装选项并停止——没有捕获就无从修复。
3. TRIAGE 新出现或反复出现的错误：通过官方 MCP 拉取错误（使用 sentinel 表上的 data/run-once-query，或监控器的 prod_error 事件）。分类：瞬时错误（重试/忽略——对于一次性的网络故障，不要创建 PR）、配置错误（环境变量/密钥——交由 env 处理，绝不猜测密钥），或代码/架构缺陷（继续处理）。
4. ROOT-CAUSE：通过 findings bus 对相关函数运行相应的审计流程——convex-insights（失败请求及调用栈）、convex-advisor（原因是读取限制/OCC 时）、convex-reviewer/convex-authz（逻辑/授权缺陷时）。生成包含证据（调用栈 + 重现输入）和 fixCapability 的 bus finding。如果根因不明确，就停止并报告——错误的修复比尚未解决的错误更糟。
5. REPAIR：通过 finding 的 fixCapability（convex-authz、reviewer 修复器、用于性能问题的 convex-expert）在分支上修复——绝不直接在生产环境中操作。
6. 在提出修复之前，依据后端自身的不变量进行 CERTIFY（这是关键差异——适用的检查一项都不能跳过）： (a) tsc --noEmit 无错误； (b) 如果修复涉及架构/数据，则在由生产环境快照填充的预览环境中通过 migrate-rehearse 执行——架构一致性检查必须在真实形态的数据上通过； (c) 重现后确认问题消失：针对修复后的代码，重放触发错误的输入（使用 convex-test 用例或在预览环境中运行 MCP），并断言失败不再发生； (d) 无回归：finding 必须消失，且被修改的函数不得引入新的 bus finding。 任何适用的验证未通过，都不得提出修复——应报告“已尝试，但未能通过验证”，并说明失败之处。
7. PROPOSE，绝不合并：创建 PR（或供审查的差异），其中包含修复、验证证据（tsc 结果、演练结果、重现后确认问题消失的断言）、原始错误 + finding，以及可逆性说明。标注变更类别。由人工审查并合并。
8. 合并后，通过 deploy-guard 的生产环境授权进行 PROMOTE；部署后，重新检查 sentinel 表和 logs（失败记录），确认该错误特征不再反复出现（不要为此使用 insights——它只跟踪 OCC/读取限制性能事件，不跟踪任意错误特征）。只有当错误不再于生产环境中反复出现时，循环才算结束。如果错误再次出现，就根据新证据重新处理。
9. 设定 BOUND：只有用户在第 1 步预先批准的类别才能自动准备（默认安全类别：验证器修复、添加缺失索引、添加所有权检查、非破坏性回填）；任何破坏性操作、超出添加检查范围的安全敏感变更，或任何含糊不清的情况，都必须推迟，等待人工明确指示。将每项操作记录到仅追加的记录中，以便审计整个循环。

规则

• 合并按钮由人类保留——此循环负责准备并验证修复，绝不会自动合并或自动部署到生产环境（这符合行业边界：没有可信的系统会在无人值守的情况下自动合并并发布到生产环境）。
• 先验证，再提议：tsc +（在生产快照预览环境中执行 schema→migrate-rehearse）+ 复现问题并确认故障已消失 + 没有新的 bus 发现。未经验证的修复应报告为“无法验证”，绝不能宣称已完成。
• 先分类处理：暂时性异常应重试或忽略，配置错误应交由 env 处理（绝不猜测密钥），只有真正的代码或 schema 缺陷才进入修复循环。
• 在分支或预览环境中修复，绝不直接在生产环境中修复；只有经过 deploy-guard 的最新生产环境许可后，才能推广。
• 仅自动准备预先批准的修复类别（默认安全：validator/index/ownership/非破坏性回填）；破坏性或含义不明确的更改一律交由人工处理。
• 真正闭环：合并并部署后，通过 sentinel 表和日志确认错误特征不再出现（而非 insights，它只会查看性能事件）；如果问题仍然存在，则重新打开。
• 每项操作都会记录到仅追加、可审计的记录中；数据驻留在用户自己的部署中（sentinel 规范）。
• 如果根本原因不明确，立即停止并报告——不确定的修复比公开且可见的错误更糟糕。