用途：证明刚构建或修改的 Convex 功能确实按预期工作，而不是只靠类型检查通过。类型检查只能说明代码能解析，无法证明非所有者真的被拒绝、查询返回正确行、mutation 产生声称的效果。该能力用 seed → drive → assert 的循环在进程内运行，无需部署。
主要能力与流程：
- 识别要证明的功能：某个具体的导出 query/mutation/action 及其预期行为（谁被允许、应返回什么数据、mutation 应改变什么）。意图不明时先问一个聚焦问题。
- 配置 convex-test：确保 convex-test 与 vitest 为 dev 依赖，且 vitest.config.ts 设置 test.environment 为 edge-runtime、server.deps.inline 包含 convex-test，并安装 @edge-runtime/vm。缺少该配置时 convexTest(schema) 会在运行时因 import.meta.glob is not a function 而失败。
- seed 数据：尽量通过应用自身函数插入，使 seed 经过同样的校验器与 mutation；无法由公开 API 创建的夹具可回退到 t.run(async (ctx) => ctx.db.insert(...))。至少 seed 调用者自己的行和第二个用户的行，以便测试跨用户访问。
- 以不同身份 drive：用 t.withIdentity({ subject, tokenIdentifier, ... }) 分别以合法所有者、其他已认证用户、未认证三种身份调用。
- assert：正向断言所有者得到预期行、mutation 产生预期变更；负向断言其他用户被拒绝、需认证处未认证调用被拒绝；数据范围断言 list/query 只返回调用者自己的行。
- 运行 npx vitest run 并报告：已证明的正负断言、以及失败的断言，因为失败的负向断言就是上线前发现的真实授权漏洞。失败项以 bus finding 输出。
限制：不得为了通过而弱化测试，所有者专属查询返回他人行时应在函数中修复；负向测试失败是真实缺陷，应交给 convex-authz/convex-expert，而非改测试至绿色。此能力针对某个已构建的具体功能；通用测试框架搭建属于 test 能力。