开发者门户方案

你有很多上游凭据，散在约 25 个项目文件夹里，没有人知道谁在用、用了多少。方案：每个服务前面放一个 Cloudflare Worker，Worker 持有凭据；每个服务有自己的服务代币；一次调用付一次代币；统计从链上读出。wpCredit 是服务之间的公共单位。

依据 PLAN.md 1.1 版（2026-10-06），六轮对抗式审阅，Woodpecker 会话验收通过。本页只做规划说明，不涉及部署。

方案十句话
  1. 第一个里程碑是现有五个代币的统计。不改任何在线 Worker，不发新代币。
  2. 一个服务一个 Worker，全部来自一个模板。新上游只需要配置，不需要代码。
  3. 一个服务一个服务代币。路线的价格用这个代币计。
  4. 同一个代币有两种付法：单笔通道（每次调用付一次，今天已在用）；预存通道（以后，用于频繁、无人值守和流式调用）。三个 Worker 上的访问密钥是临时通道，M4 结束它。
  5. 任何 HTTP 客户端都能付款。Woodpecker 用自己的钱包付；脚本、服务器和朋友用客户端助手 wpay 付。
  6. 凭据靠轮换离开直接使用：包装、迁移持有者、在提供方轮换、验证旧值已失效。
  7. 部署技能 /devportal。开发者给它一个 token 文件。只有一个助手程序读这个文件。
  8. wpCredit 是服务之间的单位。独立 ERC-20，只有员工发行。用户用它向开发者购买服务代币。封禁只停止购买；回兑是手工的。
  9. 第一阶段就有多个开发者：朋友既是开发者也是彼此的用户。先共用一个门户。三种角色：员工、开发者、用户。
  10. 每个 Worker 发布一个连接器文件。Woodpecker 从文件的 URL 添加这个 API。
前提只有一句：没有资金往来；服务代币和 wpCredit 是计量单位。本方案不做服务条款审查，不做证券法审查。

第一章 全景

方案有五个区域。点一个方块看它的职责。选一个场景，再按“下一步”看数据怎么走。

付款方
Cloudflare（运营者账户）
上游
Base Sepolia 测试链
开发者的机器