Cloudflare Cost Guard

把失控计费的入口查清，优先使用官方能力和已有监控，补齐实际缺口。 正常安静；风险、监控失明与信息性增长分别处理。Skill 是执行工作流，不能代替常驻采集程序。

直接开始

从当前请求与现有配置取得：账号范围、监控所在机器、已有运行目录/调度器、 凭据引用、通知渠道与收件人、当前告警负责人、已获授权的变更。 能只读发现的就自己查；不让用户重述已有决定，也不把背景引文当成新的授权。

根据请求执行审计、监控适配或验收；不要为一次审计强制部署监控。 持续监控请求在授权范围内做到定时采集、状态读回和通知验证，不能只交方案。 如果已有监控在别人的电脑上，收到的报告只是历史输入，不能声称读到了实时进程或文件。

默认频率如下，用户明确选择与现有已验收配置优先：

采集频率与通知频率分开。1h 巡检不能保证及时发现快速失控，更不能封顶费用。 不要为了“实时”启动常驻 LLM、另造控制平面或默认上付费外部服务。

1. 先读现状，再补缺口

• 识别当前账号与 token 的真实读取范围，按账号和产品分别记录权限；缺权限不是零资源。 确认凭据失效才停整把凭据的请求；单个 API 的权限错误仅暂停该能力，保留其他已授权读取。
• 检查已有脚本、状态文件、系统调度、原生告警和通知发送接口。修改前看工作目录、 Git 状态、近期变更与当前工作负责人，保留并发工作。
• 按完整分页盘点公开入口及其计费依赖：自定义域名、默认域名、preview、公开桶、 代理源站，以及没有公开网址的 cron / alarm / Queue / Workflow。 从实际绑定和账单产品发现其他计费服务，包含外部模型供应商；不要只检查首页 URL。
• 保存部署版本、观察时间和证据来源。本地源码不冒充部署源码，过去的账单不冒充当前基线。

2. 官方优先，运行时证明覆盖

读取 official-channels.md，按当前官方文档和账号实际权限核验： 预算告警、可用通知类型/投递渠道、现有规则、Custom Alerts 数据集及产品 analytics。 目录列出字段还不等于查询可用，真实查询与空数据语义也要验证。

对每个重要计费维度标记：已验证覆盖 / 可配置未验证 / 需已有监控补读 / 不适用 / 无法读取。 仅为已证明的缺口适配现有工具。官方查询或日志本身的权限、费用、延迟也要确认； 不能为了监控新增另一条无界采集链。

小时巡检以 requests、CPU、DO 调用/读写及 duration、D1 行读写、KV、R2 操作为适用指标。 R2 存储按桶观察字节、对象数与 24h / 7d 净增长，不每轮全桶列对象、下载文件或制造读写负载。 记录指标单位、时区、观测时间、采样/聚合口径、更新延迟及可用历史跨度。 没有足够历史时标为基线不足，不能把缺失历史当作零来计算增长。

阈值必须带单位、时间窗口与依据。结合真实基线、免费额度、存储类别、当前官方价格、 账期累计量和用户预算；增长趋势本身不等于紧急费用风险。 美元推算标为估算，分开固定订阅、存储、操作、外部 API 与实际计费用量，避免重复扣免费额度。 没有账单权限就报告覆盖缺口；不要为补账单索取或扩权为 super token。

3. 找失控路径的停止条件

沿入口 → 处理器 → 付费操作 → 重试/重新调度追踪放大路径，判断约束发生在昂贵操作之前还是之后。 请求已被拒绝也可能先执行数据库清理；鉴权、单次超时和幂等各自只证明自己的约束。

检查 DO 重新 setAlarm、队列重送/重新入队、定时任务重叠、代理循环、无 LIMIT 查询、 公开模型调用、长期未休眠 DO 和持续写入。自动重试的次数上限不等于应用重新调度的总上限。 CPU 限额不能代替累计读写/调度限制；WAF 不拦内部 alarm。 逐项给出可执行的最小修复或停止办法、影响及恢复路径。审计不自动执行生产保护。

4. 适配常驻监控时的合同

采用现有平台调度器；采集和阈值判断用确定性代码，不调用模型。 每个数据集独立记录成功/失败、最新指标与观测时间；另记最后一次完整采集成功。 不完整采集不能写成“全部正常”。失败阈值以时间表达，并报告实际告警延迟； 不能把 5min 配置的“连续三轮”原样搬成 1h 后静默等三小时。

适配或迁移频率时读取 monitoring.md：查询窗口、成功水位、 阈值窗口、失败时限、watchdog、防重入与补跑必须一起核对。1h 调度保留最近15m查询会漏45m； 补跑多小时累计量不能直接和1h阈值比较。有效空结果、权限失败、截断和数据过旧分别记录。

状态更新与待发事件持久化；发送失败保留事件到真实成功，下一轮指标恢复不能抹掉未投递的紧急事件。 恢复后停止生成新的紧急重复事件；已排队事件携带发生时间与当前状态，避免旧告警伪装成新事故。 正常不通知，信息性趋势默认只进摘要；紧急成本风险、采集故障分别路由与节流。

适配投递时读取 delivery.md。核验 sender 的真实返回契约，CLI exit0 不能独自证明送达。周报邮件仅在用户需要时配置；复用已有渠道，Gmail/gws 均不是必装依赖。

复用已有独立健康检查。单机健康检查不能发现整机离线；先找已有外部探活/跨机心跳， 没有就明确缺口，不自动扩大为双机接管系统。离线时仍有效的投递渠道与用户通知偏好要同时满足。

多机只设一个账号业务告警主负责人。未确认移交前，重叠采集可静默验证，新增告警只覆盖不重叠缺口； 交付覆盖与投递证据后才切主责。不能先停唯一有效监控，不能改另一台机器或跨账号复制秘密。

5. 验证与交付

使用 fixtures 与隔离的通知适配器验证：健康静默、阈值越界、连续采集失败、 发送失败后恢复仍重试待发事件、发送成功后不重送、恢复后停止、 权限不足/过期/空数据/历史不足，以及并发调度不重复发送。 指令行为场景见 scenarios.json；它们不是已通过的程序测试， 缺少源码、runner 或原始收据时不能把另一台机器的测试与投递报告当成本轮复验。 普通测试隔离生产通知和凭据。真实投递测试明确标记“监控投递测试”， 确认当前请求已授权该测试和该收件人后再发送，并核对接收端。

定时器启用、单次命令成功、CF 发送历史、模拟测试都不足以证明端到端上线。 实际调度运行、状态持久化读回、接收端验证分别报告；受阻时交付已完成部分与最小阻塞项。 简短输出：已读 / 已改 / 已验证 / 缺口；附覆盖、当前基线/时间、阈值依据、负责人、 文件位置、服务状态，以及查看日志/停止/恢复方法。不重复泛化调研。

授权与维护

已有明确授权就继续，不重复申请。未授权的真实通知测试、重叠业务告警启用/移交、 删除对象/生命周期、关闭公网入口、认证/限流、停服务、部署或套餐变更， 先完成可审阅的改动与验证，再申请对应批准。Skill 本身不授予这些权限。 凭据只用本机既有最小权限的安全存储引用；公共 skill 不保存账号 ID、token、bot secret、收件人或实测日志。

实践修订只加入能改变执行判断的证据：接口口径/延迟、真实权限、投递失败语义、 调度恢复与实际缺口。修正过时规则，不把每个实例追加成全局例外；运行记录留在项目私有文档。