convex-self-heal 是一个「带门禁的生产自我修复循环」，部署在用户自己的 Convex 生产环境中。它的定位是：把生产错误从捕获到修复认证的全过程自动化，唯独把「合并」这一步留给人工。
【用途】 当生产环境出现错误时，该工作流负责捕获错误、对其进行分诊、定位根因、在分支上生成修复、对修复进行认证，并最终产出一个可供人工审阅的 PR。它明确不做自动合并或自动部署到生产，这一人工合并边界是固定的。
【主要能力】 整个流程由多个阶段组成，可概括为一条流水线：capture（sentinel 捕获）→ diagnose（findings bus 诊断）→ repair（fixers 修复）→ certify（migrate-rehearse / tsc / probe 认证）→ human PR（人工决定）→ deploy-guard（晋升）。核心差异化能力在于：由于错误行位于用户自己的部署中，且修复可在该部署的预览上排练，因此平台能在人工审阅之前，用真实不变量对修复进行认证。
各阶段要点如下：
- GUARD（deploy-guard）：该循环会读取生产并提议生产变更，因此需要先对部署进行分类与告知，并 upfront 获得循环范围的长期授权——哪些类别的修复可以自动准备，哪些必须始终延后。永不自动合并，人工合并是固定边界。
- CAPTURE（sentinel）：要求启用 sentinel（在用户自己的部署中捕获生产错误，写入时进行脱敏）。如果未启用，则提议安装并停止——没有捕获就没有可修复的内容。
- TRIAGE（分诊）：通过官方 MCP 拉取新的或反复出现的错误（对 sentinel 表执行 data/run-once-query，或使用 monitor 的 prod_error 事件）。将错误分类为：瞬态（重试/忽略——不要为一次性网络抖动开 PR）、配置类（环境变量/密钥——交给 env，绝不猜测密钥）、或代码/schema 缺陷（继续处理）。
- ROOT-CAUSE（根因定位）：在 findings bus 上运行相关审计，涉及函数可运行 convex-insights（失败请求与堆栈）、convex-advisor（若为读限制/OCC 原因）、convex-reviewer/convex-authz（若为逻辑/授权缺陷）。产出带证据（堆栈 + 可复现输入）与 fixCapability 的 bus finding。若根因不清晰，则停止并报告——错误的修复比未解决的错误更糟。
- REPAIR（修复）：依据 finding 的 fixCapability（convex-authz、reviewer fixers、convex-expert 用于性能）在分支上进行，绝不直接改生产。
- CERTIFY（认证）：在提案前，针对后端自身的不变量进行认证（这是差异化关键，适用的项不可跳过）： (a) tsc --noEmit 干净； (b) 若修复涉及 schema/数据，则在用生产快照播种的预览上通过 migrate-rehearse 运行——schema 一致性门禁必须在真实形状的数据上通过； (c) 复现即消失：针对修复后的代码重放错误的触发输入（convex-test 用例或预览上的 MCP 运行），断言故障不再发生； (d) 无回归：finding 必须消失，且被触及函数上不得引入新的 bus finding。 任何适用的认证未通过的修复都不会被提议，而是以「已尝试、无法认证」并附失败项的形式报告。
- PROPOSE（提议，绝不合并）：打开一个 PR（或供审阅的 diff），内容包括修复、认证证据（tsc 结果、排练结果、复现即消失断言）、原始错误 + finding，以及可逆性说明。为变更类别打标签。由人工审阅并合并。
- PROMOTE（晋升）：合并后通过 deploy-guard 的生产授权进行晋升；部署后重新检查 sentinel 表 + 日志（失败），确认该错误签名不再反复出现（不要用 insights 做这件事——它只追踪 OCC/读限制等性能事件，不追踪任意错误签名）——只有当错误在生产中不再反复出现时，循环才算闭合。若复发，则以新证据重新开启。
- BOUND（边界）：只有步骤 1 中用户预先批准的类别才会被自动准备（默认安全集：validator 修复、缺失索引添加、所有权检查添加、非破坏性回填）；任何破坏性、超出「添加检查」范围的安全敏感、或含糊的变更，始终延后由人工明确指示。每个操作都记录到只追加记录中，使循环可审计。
【使用方式】 该工作流以 Convex 部署为运行环境，需要启用 sentinel 作为捕获前提，并通过官方 MCP 拉取错误。它串联了 sentinel、findings bus、各 fixer（convex-authz、reviewer fixers、convex-expert）、migrate-rehearse、deploy-guard 等能力，形成一个组合式（composition capstone）流程。用户需要在流程开始时为循环范围授予长期同意，并预先批准可自动准备的修复类别。
【适用场景】 适用于运行在 Convex 上、已启用 sentinel 捕获生产错误、且希望以可审计、可认证的方式自动准备修复 PR 的生产环境。尤其适合需要在不牺牲人工合并边界的前提下，减少生产错误排查与修复准备工作量的团队。
【限制】
- 永不自动合并或自动部署到生产，人工合并是固定边界。
- 没有 sentinel 捕获时无法进行修复。
- 瞬态错误不会被开 PR；配置类错误交给 env，绝不猜测密钥。
- 破坏性、超出添加检查范围的安全敏感或含糊的变更，始终延后由人工决定。
- 根因不清晰时必须停止并报告。
- 认证适用的项必须全部通过，未通过认证的修复不会被提议。
- 确认错误是否复发必须使用 sentinel 表 + 日志，而非 insights。
- 数据驻留保持在用户自己的部署中。
【暂未提供的信息】 该资料未提供：具体安装命令、具体定价或收费模式、支持的平台版本细节、各阶段的具体配置参数与代码示例。这些内容暂未提供。