用途：审查并加固 Convex 应用的授权逻辑。它专注四类在生成式 Convex 后端中占比最高的真实缺陷：身份来自参数（形态 a）、缺失按文档归属校验（形态 b）、公开查询按参数泄露 PII（形态 c）、写入时父引用容器未校验归属（形态 d）。
主要能力与用法：首先执行强制前置检查——确认存在带 provider 的 auth.config.ts，以及以 auth subject（tokenIdentifier/identity.subject）为键的 users/identities 表。二者缺一时，不得注入 requireIdentity/requireOwner，而应将公开的特权函数改为 internalQuery/internalMutation，并提示用户先运行认证设置再重跑本技能。
基础具备后，先做确定性扫描：在 convex/**/*.ts（跳过 _generated 与 .d.ts）中按四类正则定位命中，逐条报告文件、行号与匹配形态，作为与模型无关的客观基线。随后按 convex-expert.md 中的规范模式加固：新增 convex/model/auth.ts，导出 requireIdentity(ctx) 与 requireOwner(ctx, doc)；用 requireIdentity 替换客户端传入的身份参数；对以 _id 为键的读写先 requireOwner(ctx, await ctx.db.get(args.xId))；PII 查询须经身份/归属或明确角色校验；形态 d 命中须在插入/更新子行前载入父文档并校验归属或成员关系（如 participantIds.includes(user._id)）。若 schema 以 users 行 id 记录归属，需先经 subject 索引解析用户行再比较 user._id。不得扩大范围，内部/管理函数保持 internalQuery/internalMutation。
验证：运行 npx tsc --noEmit（或项目 typecheck 脚本），再重跑扫描确认 0 命中。报告按四类分组，说明可利用性并展示实际 diff。限制：仅做授权专项，不处理性能、schema、校验器问题；项目无 convex/ 目录时整体跳过。