Cloudflare Turnstile 接入向导

要解决的问题

表单接了 Turnstile，校验却没真正生效：有人把 siteverify 放在浏览器里直接请求，secret 被暴露；也有人在后端写了自有 Worker，但密钥传播失败或生产域名漏登记，注册接口照样被批量脚本打穿。这个技能的目标不是讲概念，而是把一个最小可用的接入链路完整走通：组件、托管校验 Worker、前端门控，以及一次真实校验。

它如何工作

技能先运行 scripts/auth-probe.sh 探测 API token 的权限和账户作用域，再确认要注册 localhost、127.0.0.1 和生产域名。随后调用脚本创建 managed 组件、部署标准 siteverify Worker，并把 sitekey 的 secret 通过 wrangler secret put 注入，而不是落盘。

代码库扫描会识别框架、表单提交函数和已有 CAPTCHA。接入时遵循“门控不替换”：已有提交处理逻辑保持不变，只在其之前加一个 success === true 判断。若检测到 reCAPTCHA 或 hCaptcha，会切换到迁移流程，替换 script 标签、组件 class、token 字段和 siteverify 目标。

最后，scripts/validate.sh 运行一次真实校验。任一步失败都会暴露错误并停止，而不是继续往前端文件里写代码。

适用边界

• 校验链路固定为：浏览器 → 用户自己的 Worker → siteverify。不要从前端直连 Cloudflare API。
• Worker 使用 templates/worker/ 里的标准模板，不写自定义路由、限流或第三方集成。
• 不处理邮件、短信、数据库、支付和 OAuth；现有提交函数仍由用户自己负责。
• 只有 clearance_level === no_clearance 时才走完整 Spin 流程；其他预放行配置下技能会退出。
• 遇到已有组件时优先走仪表盘 Fix with Spin 路径；编辑器内恢复仅作为回退方案，且不会重新创建组件来轮换密钥。