docs-watch

celopedia-skills 文档上游监控

目标：检测镜像到 skills/celopedia-skill/references/ 的事实是否已与实时来源不符，并呈现所有发现——包括机械性修复和有歧义／高风险的标记——每次运行都汇总到一个可供审核的拉取请求中，并将其提交到 celo-org/celopedia-skills:main（规范上游仓库，而非分叉），以便人工批准、编辑或关闭。此流程基于本仓库 README.md 的“Contributing”部分中已有的说明（检查 docs.celo.org → 更新文件 → 提升版本号 → 提交 PR），但将零散的临时报告／问题替换为一个 PR，作为集中审核的唯一入口。

检查的来源

#	来源	获取命令（更多信息见 live-data-sources.md）	参考文件
1	文档站点地图	curl -s https://docs.celo.org/llms.txt	docs-map.md
2	合约地址	https://docs.celo.org/tooling/contracts/core-contracts + token-contracts + l1-contracts + uniswap-contracts（WebFetch）	contracts.md
3	网络信息	https://docs.celo.org/build-on-celo/network-overview（WebFetch）	network-info.md
4	生态系统／TVL	curl -s https://api.llama.fi/protocols | jq '[.[] | select(.chains[]? == "Celo")]'	ecosystem.md
5	资助计划	curl -s https://www.celopg.eco/programs（WebFetch）	grants-funding.md
6	MiniPay 文档	https://docs.minipay.xyz/ 页面树 + getting-started/submit-your-miniapp.html + getting-started/best-practices.html + technical-references/deeplinks.html（WebFetch）	minipay-docs-map.md、minipay-requirements.md、minipay-common-mistakes.md
7	wFIAT 访问权限（Celo 上的 Ripio 代币）	wfiat-access.md 中的命令 → 重新验证（x402 /supported + /api/config、Ripio Ramp /api/countries、Textile RFQ 价位、GeckoTerminal 池、LI.FI 报价、Aave getReservesList、CapyFi eth_getCode）	wfiat-access.md，以及 ai-agents.md 和 SKILL.md 中的 x402 代币条目

来源 6 — MiniPay：谨慎分类

MiniPay 文档包含结构（有哪些页面和深层链接）和政策（上架需要满足什么条件）。两者的处理方式不同：

• reference update — 新增／删除／重命名文档页面，或新增／变更深层链接。这些属于结构性事实；直接编辑 minipay-docs-map.md。
• needs review — 任何上架要求变更：支持或必需的代币、SLA、依赖项安全政策、提交表单 URL 或字段、白名单规则、最小视口或性能标准。这些属于政策，而非数据，会影响技能向构建者提供的构建指导。绝不要根据文档差异自动编辑 minipay-requirements.md 或 minipay-common-mistakes.md——应说明变更内容与缓存内容的差异，并由人工决定。
• 还要检查 minipay-requirements.md 和 minipay-docs-map.md 中引用的 URL 是否仍可访问（curl -o /dev/null -w "%{http_code}"）。只有在替代链接明确无歧义时，失效 URL 才属于 reference update；否则应标记出来。

Source 7 — wFIAT 访问：跟踪结构，而非价格

wfiat-access.md 混合了结构性事实（哪些代币有可用路径）和流动性快照（池 TVL、Textile 最大规模），后者每小时都会变化。只有结构性事实会触发编辑：

• reference update — 某代币的路径新增或消失：Textile 交易对的买入深度从零变为非零（或反过来），LI.FI 开始或停止返回通往某代币的同链路径，某代币出现新的 Celo DEX 池，Ripio Ramp 增删国家或 Celo 代币，x402 /supported 列表增删资产。编辑逐代币表格和对应的路径章节。x402 列表发生变化时，在同一次运行中更新 ai-agents.md（Enabled tokens 表格和 Token-support 行）以及 SKILL.md 中的 x402 行，确保三处始终一致。
• 流动性数字：只有数值变化超过 2 倍或跨越零时，才更新数值并重置 Last verified 时间。较小变化属于 no action — 否则每次运行都会产生一个 PR。
• needs review — 任何会改变集成方资金路径行为的变化：x402 资产的 assetTransferMethod 或 eip2612GasSponsoring 标志发生变化，wFIAT 代币地址发生变化，Ripio BridgeDeposit 地址（0x465e642387d3d73a57CDc1368fFA53A800bA5D47）不再返回代码，或 wFIAT 在 Celo 上出现收益场所（Aave 储备列表新增 wFIAT，或 CapyFi 的 Comptroller 地址在 Celo 上新增代码）。绝不要自动编辑这些内容。
• 某个来源返回错误时（Textile、ramp.ripio.com、li.quest 是第三方 API），该来源视为受阻，与来源 5–6 相同。

流程

1. 加载快照 .claude/skills/docs-watch/snapshot.md — 当前依赖的事实，以及各事实最近一次验证的日期。

2. 获取上述每个来源，并提取相应参考文件中记载的相同事实（页面列表、地址表、链参数、协议列表、项目状态表）。

3. 将每个来源与快照及其参考文件当前内容进行差异比较。

4. 对每项差异进行分类：

   • no action — 外观或无关变化（例如文档页面的文字变了，但页面是否存在或 URL 未变）。PR 中不提及。
   • reference update — 机械且明确的事实变化：网站地图新增/删除/重命名页面、Celo 链列表新增/删除 DeFi 协议、资助项目的 Live/Past 状态变化、新增费用货币代币。直接在运行所在分支上编辑参考文件，写入更正后的事实（见第 5 步）— 不要逐项提交或创建 PR。
   • needs review — 任何模糊或风险较高的变化（不匹配的合约地址、链 ID / 费用货币地址变化、任何涉及 contracts.md 核心协议地址或 network-info.md 链 ID 的情况）。不要编辑文件 — 绝不要猜测如何修复。相反，应在 PR 正文的 “Needs review” 部分（第 5 步）写明清晰标注的条目，准确描述观测到的内容与缓存内容之间的差异。

5. 每次运行最终都会以三种方式之一结束 — 由于此技能不会写入报告文件，因此应根据是否出现 PR 以及出现方式，始终能区分这三种结果：

   • 发现偏差（存在任何 reference update 和／或 needs review 差异）： 为本次运行创建一个拉取请求。

     1. 从 main 创建分支（例如 docs-watch/<YYYY-MM-DD>）。
     2. 在该分支上应用所有 reference update 修改；如果任何参考文件发生变化，还要更新 skills/celopedia-skill/SKILL.md 中的 version（纯数据刷新时递增修订版本号）。
     3. 在同一分支上更新快照（步骤 6）。
     4. 将分支直接推送到 celo-org/celopedia-skills（此检出目录有推送权限，无需 fork），并创建 PR： gh pr create --repo celo-org/celopedia-skills --base main --head <branch> --title "docs-watch: weekly refresh — <date>" --body "..."
     5. PR 正文就是报告，不要另建报告文件。结构如下：开头用一句话概述“变更内容”，每个来源各设一个章节，列出其差异及分类；对于任何需要人工判断的事项，另设清晰区分的 需要审核 章节（审核者可批准、推送修改或关闭 PR）；并列出已在差异中应用的机械性修改。
     6. 一个 PR 覆盖整次运行——不要将 reference update 和 needs review 发现拆分到不同 PR 中。

   • 受阻（一个或多个来源无法访问，例如网络错误、403、超时等，因此无法评估这些来源的差异）：也要创建一个小型拉取请求，确保受阻的运行不会被误认为运行正常而悄无声息。

     1. 从 main 创建分支（例如 docs-watch/blocked-<YYYY-MM-DD>），并且只修改 snapshot.md 中的“Last attempt”行（步骤 6）——不要修改参考文件，也不要递增版本号，因为实际上并未完成验证。
     2. 推送分支并创建 PR，标题为 docs-watch: blocked — <date>；正文准确列出哪些来源失败及失败原因（状态码／错误），并说明本次运行中哪些来源（如果有）成功访问。
     3. 此 PR 仅供参考，不涉及需要合并的内容——审核者真正要解决的是底层阻碍（例如网络出口允许列表）。合并只会记录本次尝试；不合并而关闭也完全可以。

   • 正常（所有来源均可访问，所有差异均为 no action）：不要创建 PR 或提交任何内容——保持完全静默。最后在最终消息中简短总结即可。

6. 更新快照，在步骤 5 使用的分支上进行：

   • 对于来源可访问的发现偏差或正常运行： 使用新验证的值更新各来源的事实，并为每个已检查的来源设置 Last verified: <date>。
   • 对于受阻运行：保留各来源的事实不变（它们实际上并未重新验证），只更新文件顶部的 Last attempt: <date> — BLOCKED (<hosts>) 行。
   • 保持文件精简——只记录上面核查的事实，不要完整复制参考文件。

备注

• live-data-sources.md 已说明优先级顺序（实时 API > 官方文档 > 硬编码参考资料 > 生态目录）。此技能旨在确保“硬编码参考资料”这一层准确可靠，而不是取代其他地方的实时查询。
• 切勿猜测合约地址或链参数来“修复” needs review 项目——设置这一类别正是为了确保涉及安全敏感数据的事实更正始终经过人工审查。