diff --git a/docs/crypto-tx-engine-plan.html b/docs/crypto-tx-engine-plan.html
new file mode 100644
index 0000000..152da4b
--- /dev/null
+++ b/docs/crypto-tx-engine-plan.html
@@ -0,0 +1,104 @@
+
+
+
+
+
+pangolin-pay 加密货币交易引擎 实现计划
+
+
+
+
+
← 文档索引
+
pangolin-pay 加密货币交易引擎
+
2026-07-09 · 阅读版 · 执行真相源 docs/superpowers/plans/2026-07-09-crypto-tx-engine.md · #34 的第一块(可独立执行 + 真实小额验证)
+
+
+#34 的第一块、可独立执行、能用真实小额 USDT 端到端验证的基础件。只做加密货币"交易"核心——派生地址、侦测到账、归集(sweep)——不含独角数卡对接、不含发码。成果=独立 Go 服务 pangolin-pay,提供"建单→收款地址→侦测到账→标记已付"+ 离线归集工具。跑通后任何门面都能挂上来。
+
+
+
+安全铁律:热服务只持 xpub(watch-only 派生)+ TronGrid key + 金库收款地址,绝不持私钥;私钥/助记词冷存,归集在离线端签名。关键常量(核对无误再写死):USDT-TRC20 合约 TR7NHqjeKQxGTCi8q8ZY4pL8otSzgjLj6t(6 位小数)· 派生 m/44'/195'/0'/0/i · TronGrid api.trongrid.io。
+
+
+
Phase A — 钱包与密钥(全程离线)
+
+- A.1 离线生成两套助记词(断网,Ian Coleman/bip_utils,TRX/24词/English):钱包 A 运营收款、钱包 B 冷备金库。
+- A.2 导出钱包 A account xpub(
m/44'/195'/0');取钱包 B 地址0 当归集目标。
+- A.3 冷存助记词 A/B(分开)+ Bitwarden;只把 xpub_A + sweep_addr_B 放进配置。
+- A.4 交叉核对:Go 派生出的地址 0..4 必须与 Ian Coleman 逐个一致(防收款地址对不上)。
+
+
+
Phase B — 服务骨架 + HD 派生
+
+- B.1 建 Go 服务
pangolin-pay(独立)。配置:xpub_A / sweep_addr_B / TronGrid key / 确认数 / 超时。自带 SQLite。
+- B.2 HD 派生:go-bip39 + hdkeychain 从 xpub_A watch-only 派生
.../0/i 公钥 → TRON 地址(Keccak 后20字节 + 0x41 + Base58Check)。单测对齐 Ian Coleman。
+- B.3 数据模型:
pay_orders(order_no, sku, expect_amount, addr_index, address, status, tx_id, confirmations, created_at, expires_at) + addr_cursor(next_index)(地址不复用)。
+
+
+
Phase C — 收款(建单 + 侦测到账)
+
+- C.1
POST /order → cursor++ 派生新地址 → 写单(expect_amount 唯一尾数、expires +15min)→ 返回 {order_no, address, expect_amount, expires_at}。
+- C.2
GET /order/{order_no} → status(pending/paid/expired)。
+- C.3 TronGrid watcher 轮询:
/v1/accounts/{addr}/transactions/trc20?only_confirmed=true&contract_address=<USDT>,匹配 to+金额(6位小数)+确认 → paid、记 tx_id。
+- C.4 幂等(同 tx 只认一次)+ 超时 expired(地址不复用)+ 崩溃恢复。
+- C.5 限流退避 + 重试;mock TronGrid 测试:匹配/确认/超时/幂等/恢复。
+
+
+
Phase D — 归集(sweep,离线签名)
+
+- D.1 watcher(xpub)列出有余额地址清单。
+- D.2 gas:gas 钱包给待归集地址打少量 TRX(或能量租赁)。
+- D.3 离线机导入钱包 A 助记词 → 派生 address_i 私钥 → 构造 TRC20
transfer(sweep_addr_B, balance) → 离线签名。
+- D.4 广播:签好的交易经 TronGrid
/wallet/broadcasttransaction 上链(私钥不出门)。
+- D.5 半自动脚本 + 归集 runbook;阈值/定时触发;热地址不囤大额。
+
+
+
Phase E — 端到端验证(真实小额)
+
+- E.1 真单:
POST /order → 转 1 USDT(TRC20)→ watcher 确认 → status=paid。
+- E.2 归集:D 流程 → USDT 到钱包 B 冷地址。
+- E.3 安全核对:热服务无私钥、密钥不入 git、地址不复用。
+
+
+
不在本轮
+
+- 独角数卡门面对接 + epay 支付口(下一块:接门面)。
+/internal/codes/mint JIT 发码 + 兑换闭环(发货侧,#34 后续)。- HD 自动 sweep(先人工)、多币种、watcher 高可用。
+
+
+
相关:#34 收款闭环全景 · 渠道选型 · 知识:brain notes/dev/crypto-hd-wallet-basics.html
+
+
+
← 文档索引
+
方案 A · 自建发卡网（独角数卡）落地细化
+
2026-07-08 · 实现计划 · 门面自建 + USDT 收款 + 激活码自动发货 · 基于已就绪的 server/internal/codes
+
+
+关键前提（好消息）：激活码后端基本已就绪——发卡店回调 POST /webhook/store/codes（HMAC + 时间戳 + nonce 防重放）、用户兑换 POST /v1/redeem（JWT）、批次生成/导出/作废都在 server/internal/codes。所以方案 A 的工作量集中在门面（独角数卡）+ 一小段发货胶水 + 运维，不是重写后端。
+
+
+
已就绪的后端契约（照这个对接，别新造）
+
+
+
已实现 · 发卡店回调 POST /webhook/store/codes
+
发卡店卖出一个码后调它，把该码登记为 pangolin 的有效激活码。挂在 /v1 之外、无需 JWT，靠三重校验。
+
POST /webhook/store/codes # 无 JWT
+Headers:
+ X-Pangolin-Signature: sha256=<hex> # HMAC-SHA256(raw body, secret)
+ X-Pangolin-Timestamp: <unix> # ±5 分钟窗口
+ X-Pangolin-Nonce: <唯一串> # Redis 去重，防重放
+Body:
+ { "code": "<明文激活码>", # 必须是 pangolin 格式合法码（见下）
+ "plan": "pro", # free | pro | team
+ "duration_days": 365,
+ "note": "dujiaoka #订单号" } # 可选备注
+→ 201 {"status":"created"}
+→ 200 {"status":"already_exists"} # code_hash 已存在，幂等
+→ 200 {"status":"duplicate_ignored"} # nonce 重复，幂等
+→ 400 / 401 # 校验失败
+
仅存 hash（明文不落库）。secret 走 Bitwarden，配到 server.env。
+
+
+
+
已实现 · 用户兑换 POST /v1/redeem
+
POST /v1/redeem (JWT)
+Body: { "code": "PGL-XXXX-..." }
+→ 200 { "idempotent":false, "plan":"pro", "duration_days":365,
+ "expires_at":"2027-07-08T00:00:00Z" }
+错误码: CODE_NOT_FOUND / CODE_REDEEMED / CODE_VOID / INVALID_CODE / RATE_LIMITED / ACCOUNT_LOCKED
+
已含幂等（同用户同码重放返回 idempotent=true）+ 限频 + 账户锁。用户中心/客户端只要有"输码兑换"入口即可。
+
+
+
+
已实现 · 批次生成 / 导出 / 作废
+
server/cmd/codegen 生成一批合法码（Crockford Base32、75-bit、带校验位、可 Canonicalize 纠错），export.go 导出明文，VoidBatch 批量作废未使用码。码格式带校验位——第三方要产出合法码不能乱编（见下模型 B 的待补点）。
+
+
+
整体拓扑
+
+
+
+ 钱流
+ 码流
+ 自托管资产
+
+
+
+
部署选址 · 风险隔离
+
+独角数卡必须独立部署，别放 pangolin1。 两个理由：① pangolin1 只有 ~1GB 内存，跑控制面+agent+sing-box 已经紧，再塞 PHP+MySQL+Redis 会 OOM；② 风险隔离——发卡/收款站点和 VPN 控制面绑一起，一处被盯上会牵连另一处。放独立小 VPS（海外，2C/2G 起），与控制面只经 HTTPS webhook 通信。
+
+
+
两种发货模型（映射到已有能力）
+
+ | 模型 A · 预充卡密库存 最快 MVP | 模型 B · webhook JIT 登记 更安全 |
|---|
+
+| 怎么做 | codegen 生成一批 → 导出明文 → 充进独角数卡卡密库 → 发货直接给码 | 独角数卡发货后调 /webhook/store/codes 才把码登记为有效 |
+| 码何时有效 | 生成即有效（在 codes 表 status=unused） | 付款+发货后才有效 |
+| 泄漏风险 | 独角数卡库被脱 → 码可被无票兑换 | 未售出的码无效，脱库也没用 优 |
+| 要写的胶水 | 几乎零（导入卡密即可） | 发货 hook 签 HMAC 调 webhook + 解决"码由谁生成" |
+| webhook | 不用 | 用 /webhook/store/codes |
+
+
+
+
+建议：MVP 先用模型 A（零胶水、当天能卖），跑通量后升级模型 B 拿安全性。
+模型 B 的待补点：webhook 要求发卡店发送pangolin 格式合法码（带校验位）。独角数卡自己产不出合法码，两条路二选一：(1) 在独角数卡侧复刻 GenerateCode 生成算法；(2) 给 pangolin 加一个受保护的 POST /internal/codes/mint（HMAC 同款）让发卡网"先领一个合法码再发货登记"。推荐 (2)，格式单源、不重复实现。
+
+
+
商品 / SKU 映射
+
独角数卡里每个商品 = 一个套餐档，映射到 webhook 的 plan + duration_days：
+
+| 独角数卡商品 | plan | duration_days |
|---|
+
+| Pro · 月 | pro | 30 |
+| Pro · 年 | pro | 365 |
+| Team · 月 / 年 | team | 30 / 365 |
+
+
+
档位/定价对齐 design/CLAUDE.md §7 与官网 Pricing；SKU 表落进配置，别散在代码里。
+
+
USDT 收款接入
+
+- 路子 1 · 独角数卡 USDT 插件 / 加密网关（NOWPayments/Cryptomus 等）：最快，插件配好即"支付完成"回调独角数卡触发发货。查 AUP/抽成/是否非托管。
+- 路子 2 · 自建 TronGrid watcher 作为独角数卡的自定义支付网关：单地址+唯一金额匹配（MVP）或 HD 每单地址（规模化），到账 N 确认后回调独角数卡。最干净，代码量小。详见 发卡+发货架构 的 USDT 一节。
+
+
+
要建的胶水（很小）
+
+- 发货 hook → pangolin webhook（仅模型 B）：独角数卡发货成功后，组 body + 签
X-Pangolin-Signature(HMAC)+时间戳+nonce，POST /webhook/store/codes。独角数卡支持"自动发货 API 商品/webhook"，写个小中间脚本或插件即可。
+- HMAC secret：生成一把，存 Bitwarden；配 pangolin
server.env 与独角数卡侧。
+- （模型 B 推荐）
POST /internal/codes/mint：受 HMAC 保护，返回一个合法码给发卡网。需新增
+- 兑换入口自检：确认客户端/用户中心已有"输码兑换 → /v1/redeem"的 UI（后端已就绪）。
+
+
+
落地步骤
+
第 1 步 · 门面起来（半天）
+
+- 独立小 VPS 部署独角数卡（Docker 最省事），配域名+HTTPS。建 Pro/Team 商品与 SKU。
+
+
第 2 步 · 收款接上（USDT）
+
+- 选路子 1（网关插件）或路子 2（自建 watcher），配到独角数卡，小额实测"付款→自动发货"。
+
+
第 3 步 · 发货接 pangolin
+
+- MVP（模型 A）：
codegen 生成一批 → 导出 → 充进独角数卡卡密库。此步即可开卖。
+- 升级（模型 B）：加
/internal/codes/mint + 发货 hook 调 webhook，切到"售出才有效"。
+
+
第 4 步 · 闭环验证
+
+- 真机走一遍：下单→USDT付款→拿码→客户端/用户中心
/v1/redeem→订阅生效、全端同步。
+- 对账：独角数卡订单 ↔ codes 登记/核销记录，日结核对。
+
+
+
密钥 · 备份 · 风险边界
+
+- HMAC secret、USDT 种子/私钥、独角数卡 DB → 全走 Bitwarden，不入 git、不落明文。
+- 独角数卡 DB 定期备份（订单/卡密）。
+- 红线：这条链全程不碰跑分/中国支付；USDT 进你自托管钱包，法币结算走 US LLC。支付宝/微信便利若要，另起第三方通道（E 层），当可替换插件，不进本链核心。
+
+
+
待你拍板 / 下一步
+
+- 门面选 独角数卡 还是同类？独立 VPS 放哪（海外区域/配置）？
+- USDT 走路子 1（网关）还是路子 2（自建 watcher）？
+- 起步用模型 A（预充）先开卖，确认？后续再上模型 B +
/internal/codes/mint。
+- 确认后我把上面拆成 todo（门面部署 / USDT 接入 / mint 端点 / 发货 hook / 闭环验证）进入落地。
+
+
+
相关：支付渠道选型总览 · 发卡/Reseller 收款 + 激活码自动发货架构
+
+
+
← 文档索引
+
支付渠道选型总览
+
2026-07-08 · 调研 / 选型 · 各支付渠道候选与甄别标准（研究起点，非背书；合规/AUP/风评自行核实）
+
+
+先破一个概念：「发卡平台」不是一个东西，而是两个可分开的决策——① 门面（storefront / 发卡网：展示、下单、自动发卡密）；② 收款通道（channel：实际把钱收进来的管子）。灰 / 干净的分水岭在通道，不在门面。把两者绑在一个第三方身上，是被套牢和被跑路的根源。
+
+
+
决策框架：门面 × 通道
+
+| 层 | 选择 | 建议 |
|---|
+
+| 门面 | 自建发卡网 / 上第三方发卡市场 | 自建（你拥有门面+数据+发货节奏，只外包"收款"一环） |
+| 通道 | USDT 自收 / 加密网关 / 官方鹅 / 支付宝微信第三方 | 干净优先；支付宝/微信第三方=灰产层，最后再叠加、且当可替换插件 |
+
+
+
+
候选清单（A–E）
+
+
+
A · 自建发卡网（门面 · 开源自托管）推荐起步
+
你完全拥有门面 + 自动发卡逻辑（卡密库存 / API 发货），对接 pangolin codes 模块。
+
+- 独角数卡 dujiaoka（GitHub
assimon/dujiaoka）— PHP，最主流，卡密库存 + 多支付插件。
+- acg-faka（异次元 / 彩虹发卡）— PHP，插件多。
+- KamiFaka — Vue + PHP，轻量。
+
+
看点：卡密/API 发货是否好接 codes、支付插件生态、维护活跃度。→ 已细化为落地方案（方案 A）
+
+
+
+
B · 加密支付网关（让 USDT 收款像普通支付，API+webhook）懒人版 USDT
+
+- NOWPayments — 非托管、币种多、API/webhook 齐。
+- Cryptomus — TRC20 友好、商户后台。
+- CoinGate — 欧洲、合规相对正。
+- Plisio / 0xProcessing — 同类可比。
+
+
看点：①是否非托管（直接进你钱包）②抽成 ③AUP 是否禁 VPN（逐家查）④是否强制 KYC/公司资料 ⑤TRC20 支持。
+
+
+
+
C · 自建 USDT 监听（DIY，最干净）干净
+
+- TronGrid（TRON 官方 API，免费额度）— 轮询到账。
+- 节点服务：GetBlock / QuickNode，或自建 TRON 节点。
+- GitHub 搜
tron usdt payment / trc20 watcher 有大量参考实现。
+
+
看点：确认数、TRX gas 归集、种子/私钥托管。见 发卡+发货架构 的“USDT 自动收款”一节。
+
+
+
+
D · 官方鹅（合规补充）干净
+
+- Telegram Stars — TG 官方，bot 内收款（走 Apple/Google IAP，抽成）。
+- Apple / Google IAP — 海外区。
+
+
+
+
+
E · 支付宝/微信 第三方通道（灰产层）不列名单
+
跑分 / 四方聚合。不给候选名单——合法性与跑路风险无法背书。自研路子：
+
+- 站长圈打听历史：
hostloc、LowEndTalk 中文区、相关 TG 发卡/站长群，看实际跑路/冻卡口碑。
+- 一律小额实测提现跑通再放量。
+- 做成可热插拔多通道，账上不留余额。
+
+
+
+
决策矩阵
+
+| 渠道 | 干净度 | 接入难度 | 抽成 | 主要风险 | 适合阶段 |
|---|
+
+| A 自建发卡网 | 门面干净 | 低（部署即用） | —（只付通道费） | 看你插什么通道 | 起步基座 |
+| B 加密网关 | 干净 | 低（API） | ~0.5%–1.5% | AUP 可能禁 VPN、KYC | 快速上 USDT |
+| C 自建 USDT 监听 | 最干净 | 中（写 watcher） | ~0（仅链上手续费） | 种子安全、gas 归集 | 长期主力 |
+| D 官方鹅 | 干净 | 低 | 15%–30% | 抽成高、中国区不可用 | 海外补充 |
+| E 支付宝/微信第三方 | 灰（跑分） | 低 | 8%–20% | 冻卡、跑路、周期性死 | 可选便利、可替换 |
+
+
+
+
尽调清单（仅当接 E · 支付宝/微信第三方通道）
+
+- 结算周期：优先 T+0 / T+1，压你钱三五天的直接 pass。
+- 保证金方向：它押给你？还是你押给它？你押钱=高危。
+- 口碑与跑路史：先在站长圈/TG 群打听历史，有跑路记录排除。
+- 小额实测：先小金额跑通提现，确认到账再放量。
+- 通道稳定性 + 热切换：注定周期性死；同时接 2–3 家，一家挂立刻切。
+- 费率：别只看费率——压钱/爱跑路的更坑。
+
+
+
+红线：Pangolin 主体（尤其中国岩美）永不直接对接跑分/四方聚合、永不用中国支付账户收 VPN 款。E 层的冻卡/跑路风险只允许存在于第三方通道那一层；到你手里的必须是它们的结算款（法币/USDT，走 US LLC）。
+
+
+
推荐研究顺序 + 起步组合
+
+- 先啃 A（独角数卡）+ C（TronGrid 自建监听）——这条让你干净地跑起来，"付完自动发码"体验和灰产 bot 一致。
+- B（加密网关）作为"懒人版 USDT"备选（省掉写 watcher，但查 AUP/抽成/是否非托管）。
+- D 作海外补充；E 最后再碰、只当可替换插件。
+
+
建议起步组合：独角数卡（门面）+ USDT（C 自建监听 或 B 网关）。 已细化 → 方案 A · 自建发卡网落地细化。
+
+
相关文档
+
+
+
+
← 文档索引
+
收款闭环 · 独角数卡 + 自托管 USDT(TRC20) + webhook JIT 发码
+
2026-07-09 · 阅读版 · 执行真相源 docs/superpowers/plans/2026-07-09-payment-clean-usdt-loop.md（带 checkbox）· #34（tier-1）
+
+
+目标：把「下单 → USDT 付款 → 自动发激活码 → 客户端/用户中心兑换 → 订阅生效」端到端打通，全程自托管、售出才发码、无跑分、无第三方支付主体。
+关键前提（已摸底）：激活码后端大半已就绪——POST /v1/redeem（兑换，幂等+限频）、批次生成/导出、发卡店回调 /webhook/store/codes（HMAC+时间戳+nonce）都在。本方案新增核心只有一个后端端点（JIT 发码 /internal/codes/mint）+ 一个独立收款服务 pangolin-pay（TronGrid watcher + epay 支付口）。
+
+
+
三大组件 / 数据流
+
+
买家 ──下单──▶ 独角数卡(门面, 独立 VPS)
+ │ 建单 + epay 跳转
+ ▼
+ pangolin-pay(自建收款服务, 同 VPS)
+ ├ 派生每单唯一 TRC20 收款地址 (watch-only, 只持 xpub)
+ ├ TronGrid watcher 轮询到账 + 确认
+ └ 到账 ──epay notify──▶ 独角数卡「已支付」
+ │
+ ▼ 独角数卡 API-提货
+ pangolin-pay /issue ──HMAC──▶ pangolin 控制面 POST /internal/codes/mint
+ └ 生成合法码 + 存 unused + 返回明文
+ │
+ ▼ 独角数卡把码交付买家
+买家 ──输码──▶ 客户端/用户中心 POST /v1/redeem ──▶ 订阅生效
+
+
+
+安全红线（贯穿全程）：① 热服务 pangolin-pay 只持 xpub 派生收款地址、绝不持私钥（能收不能转，脱库也转不走钱）；② 私钥/助记词冷备 + Bitwarden，不入 git、不上热机；③ 收款终点=自托管钱包，变现经交易所出金 US LLC，记账走 accounting；④ 全程不碰跑分/中国支付。部署在独立海外小 VPS，不放 pangolin1（内存紧 + 风险隔离），只经 HTTPS+HMAC 与控制面 api.yanmeiai.com 通信。
+
+
+
已就绪 vs 本轮新增
+
+| 能力 | 状态 |
|---|
+
+POST /v1/redeem 兑换（幂等+限频+账户锁） | 已实现 |
+| 批次生成/导出（Crockford Base32 75-bit 带校验位，只存 hash） | 已实现 |
+发卡店回调 /webhook/store/codes（HMAC+时间戳+nonce） | 已实现（留给未来第三方发卡店） |
+POST /internal/codes/mint JIT 发码 | 本轮新增 |
+pangolin-pay：TronGrid watcher + epay 支付口 | 本轮新增 |
+| 自托管 TRC20 HD 钱包 + 归集/变现 runbook | 本轮新增 |
+
+
+
+
Phase 0.5 — 钱包选型（用哪个钱包）
+
先厘清：这套架构的「钱包」是两件事，别当成装一个 app。
+
+- 主种子（钱在哪）：一套 BIP39 助记词，冷存。资产本体。
+- watcher 收款：热服务用库从 account xpub（公钥）派生每单地址——watch-only，不是钱包 app，拿不到私钥。
+- 归集签名：动钱时在冷端用私钥离线签 sweep 交易。
+
+
所以「用哪个钱包」= 选 ① 主种子怎么冷存 + ② watcher 用哪个派生库。
+
+
① 主种子 / 冷存 候选
+
+| 方案 | 冷存安全 | xpub 导出 | 归集签名 | 结论 |
|---|
+
+| 离线生成助记词 + 库派生 推荐 | 高（纸/钢板离线，永不联网） | 从种子导 account xpub | 离线机用库签 | 最贴合 watch-only 架构、最灵活 |
+| Ledger 硬件钱包（可叠加） | 最高（私钥不出设备） | 可导 account 公钥（需工具） | 插 Ledger 签 | 想再加一层硬件冷存就用它兜底 |
+| TronLink / imToken / Trust（手机热钱包） | 低（热钱包） | 不便批量派生 | app 内签 | 不推荐当收款主钱包 |
+
+
+
+
② watcher 派生库 候选（给热服务 watch-only 派生，非钱包）
+
+| 语言 | 库 |
|---|
+
+| Go（与 server 同栈，推荐） | tyler-smith/go-bip39 + btcd/btcutil/hdkeychain（BIP32）→ 公钥转 TRON base58 地址；或成熟 TRON Go SDK |
+| Python | tronpy + bip_utils（一步派生 TRON 地址） |
+
+
+
+
+推荐：主种子用离线生成 BIP39 助记词（想再稳叠一层 Ledger 冷存）；watcher 用 Go 库从 account xpub watch-only 派生（与 server 同栈、好集成、热机无私钥）。收款钱包 = 你自己的 HD 种子，不是某个 app。
+
+
+- 0.5.1 定主种子方案：离线助记词（推荐）/ 是否叠加 Ledger 冷存；记录选型。
+- 0.5.2 定 watcher 派生库（Go bip39+hdkeychain→TRON / Python tronpy+bip_utils），跑通派生并与钱包 app 交叉核对同一地址（防派生不一致收不到钱）。
+- 0.5.3 定归集冷签工具（离线机脚本 / Ledger），确认能对 sweep 交易离线签名。
+
+
+
Phase 1 — 自托管钱包（TRC20 HD，watch-only 收款）
+
一套助记词派生无限个收款地址；热服务只拿 xpub 派生地址收款、拿不到私钥；私钥冷备用于归集。
+
+- 1.1 离线生成 BIP39 助记词（24 词），TRON 派生路径
m/44'/195'/0'/0/i（195=TRON）。工具：离线机 tronpy/tronweb 或硬件钱包（Ledger 导出 xpub），生成不联网。
+- 1.2 密钥分级：助记词/私钥→冷备+Bitwarden（永不上热机）；account xpub→给 pangolin-pay watch-only 派生；HMAC secret→Bitwarden。
+- 1.3 定冷钱包归集地址 + 记 USDT-TRC20 合约地址（主网
TR7NHqjeKQxGTCi8q8ZY4pL8otSzgjLj6t，核对无误再写死）。
+- 1.4 备少量 TRX 作归集 gas（TRON 转账吃 energy/bandwidth）。
+- 1.5 验证：xpub 离线派生前 5 地址；往 index 0 打 1 USDT 测试，确认 watch-only 查得到。
+
+
+
Phase 2 — pangolin-pay：TronGrid watcher（自建收款侦测）
+
+- 2.1 建 Go 服务
pangolin-pay（自带轻量 SQLite）。
+- 2.2 数据模型：
pay_orders(order_no, sku, plan, duration_days, addr_index, address, expect_amount, status, tx_id, confirmations, created_at, expires_at) + addr_cursor(next_index)。
+- 2.3 每单唯一地址：建单时从 xpub 派生
m/.../0/next_index（最准，免金额撞车）。次选单地址+唯一金额。
+- 2.4 TronGrid 轮询：
GET /v1/accounts/{addr}/transactions/trc20?only_confirmed=true&contract_address=<USDT>，比对 to/token/金额（含容差）。
+- 2.5 确认：只认已固化交易或等 ≥N 区块（约 1 分钟）→
status=paid + 记 tx_id。
+- 2.6 到账触发发货；幂等：同 tx_id 只认一次、一单只发一次。
+- 2.7 超时（默认 15min）→
expired、释放地址（不复用，避免串单）。
+- 2.8 TronGrid key + 限流退避 + 重试；崩溃可从 DB 未决单恢复。
+- 2.9 测试：mock TronGrid → 金额匹配/确认门槛/超时/幂等/恢复。
+
+
+
Phase 3 — 控制面：JIT 发码端点 POST /internal/codes/mint
+
付款确认时即时生成一个合法码——这才是 webhook JIT 的落点：售出才产码、才有效。自建场景由 pangolin 产码（保证格式+校验位单源），比让外部产码更干净。
+
POST /internal/codes/mint # /internal 组, 无 JWT, HMAC 同 webhook
+Headers: X-Pangolin-Signature: sha256=<hmac> · X-Pangolin-Timestamp(±5min) · X-Pangolin-Nonce
+Body: { "plan":"pro", "duration_days":365, "order_ref":"<独角数卡订单号>" }
+→ 200 { "code":"PGL-XXXX-...", "expires_at":"..." } # 以 order_ref 幂等, 同单返同码
+
+- 3.1 新增端点，HMAC+时间戳+nonce（复用 webhook 那套验签，抽公共中间件）。
+- 3.2 复用
codes.GenerateCode() 产码 + Store.CreateCode 存 unused（channel=ChannelStore）→ 返回明文。
+- 3.3 幂等：
order_ref 为幂等键（存 order_ref→code_hash），同单重放返回同一码。
+- 3.4 secret → Bitwarden →
server.env（CODES_MINT_HMAC_SECRET）；main.go 挂路由。
+- 3.5 保留现有
/webhook/store/codes 供未来第三方发卡店。
+- 3.6 测试：验签/时间戳/nonce/order_ref 幂等/产码格式。
+
+
+
Phase 4 — 独角数卡对接（门面 + 自动发货）
+
+- 4.1（研究·先做）摸清所用独角数卡版本的 epay 支付接口 + API-提货/自动发货商品机制（版本相关，实测出对接点清单再实现）。
+- 4.2 pangolin-pay 实现 epay 兼容支付接口：独角数卡建单 → 跳我方支付页（USDT 地址+应付金额+倒计时+TRC20 强提示）。
+- 4.3 到账 → 按 epay 规范 notify 独角数卡（签名）→ 标「已支付」。
+- 4.4 商品设 API-提货：发货时调 pangolin-pay
/issue → 内部 HMAC 调 /internal/codes/mint 取码 → 交付买家。
+- 4.5 SKU 映射表（配置化）：独角数卡商品 → plan+duration_days（Pro 月/年、Team 月/年；对齐官网 Pricing）。
+- 4.6 幂等贯通：独角数卡 order_no 作为 order_ref 一路透传到 mint，一单一码。
+
+
+
Phase 5 — 部署 · 运维 · 安全
+
+- 5.1 独立海外小 VPS（2C/2G）部署：独角数卡（Docker）+ pangolin-pay + 域名 + HTTPS（不放 pangolin1）。
+- 5.2 密钥落位核对：pangolin-pay 只有 xpub + TronGrid key + epay 签名密钥 + mint HMAC secret，无私钥/助记词（冷备）。全 Bitwarden。
+- 5.3 归集 runbook：定期把各收款地址 USDT sweep 到冷钱包（离线签名），备 TRX gas。
+- 5.4 变现 runbook：冷钱包 → 交易所（能出金 US LLC 的）→ 卖 USDT→USD → 银行；记账交 accounting agent。
+- 5.5 监控告警（接现有 Telegram）：watcher 存活、TronGrid 配额、到账延迟、mint 失败、订单堆积。
+- 5.6 对账：独角数卡订单 ↔ pay_orders ↔ codes（mint/redeem）三方日结，差异告警。
+
+
+
Phase 6 — 端到端验证
+
+- 6.1 真单闭环：下单→USDT付款→watcher确认→mint码→独角数卡交付→
/v1/redeem→订阅生效、全端同步。
+- 6.2 异常路径：超时未付/金额不足/重复付/确认期抖动/mint 重放。
+- 6.3 安全核对：热服务无私钥、密钥不入 git、每单唯一地址不复用、redeem 幂等+限频。
+
+
+
+验收判据：后端 go test ./internal/codes/... 含 mint 验签/幂等/格式全绿；pangolin-pay go test 含匹配/确认/超时/幂等/恢复；真机一笔真 USDT 小额单全通 + 异常逐条演练；安全逐项核对。
+
+
+
不在本轮
+
+- 支付宝/微信第三方通道（E 层，灰产，另议且当可替换插件）。
+- HD 自动 sweep 归集（先人工离线归集）。
+- 多币种、watcher 高可用、加密网关备选路子（B 方案）。
+- Telegram Stars / Apple IAP 独立收款口（海外补充，另排）。
+
+
+
相关：支付渠道选型总览 · 方案A 自建发卡网细化 · 发卡+发货架构
+
+
+
← 文档索引
+
Pangolin 支付落地方案
+
2026-07-08 · 设计方案 · 发卡 / Reseller 收款 + 激活码自动发货（“付完秒发货”体验，收款风险不落在你的主体上）
+
+
+一句话：把「收钱」和「你的品牌 VPN」彻底解耦——收款外包给发卡平台 / Reseller（他们承担支付宝/微信跑分、冻卡、跑路风险），你只做一件事：把一段「激活码」交付出去。所有渠道（发卡法币、USDT、Telegram Stars）进来的钱最后都汇成同一种“货币”——激活码；客户端与用户中心只认码。你们的 codes 激活码模块已实现，支付层只是「入账 → 发码 → 核销」的适配器。
+
+
+
为什么是这个形状（约束）
+
上一轮已经确认的硬约束，直接决定方案形状：
+
+- 中国主体 / 中国支付不能碰：支付宝 / 微信 / 银联 + 岩美（北京）主体卖 VPN → 冻结商户号 + 法律风险。红线
+- 灰产 bot 的做法 = 跑分：那些“资源入群助手”用的是四方聚合支付 + 个人账户跑分（帮信罪 / 冻卡 / 平台跑路）。你自己的主体绝不直接接跑分。
+- 能保留“支付宝/微信便利”的唯一干净姿势：把这一环外包——发卡平台/Reseller 用他们的通道收人民币，风险在他们；你拿结算 + 发激活码。或主力走 USDT（你自己钱包，链上干净） + Telegram Stars（TG 官方）。
+
+
+
整体流程图
+
一笔订单从下单到订阅生效的完整流转。橙色 = 钱流，青色 = 码流，绿色虚线 = 结算/对账。收款与跑分风险全部圈在「发卡平台 / Reseller」内，不进入 Pangolin 主体。
+
+
+
+
+ 钱流
+ 码流（激活码）
+ 结算 / 对账
+ 风险边界（发卡层内）
+
+
+
+
逐环节详解
+
+
+
1用户下单
+
入口有三种形态（见后文“落地节奏”）：① 你的 Telegram bot 菜单；② 用户中心内“获取激活码”下单页；③ 第三方发卡平台的商品页。用户选套餐档位（Pro 月/年、Team），点支付。
+
+
+
+
2发卡平台收款 风险都在这层
+
发卡平台/Reseller 用他们自己的通道收人民币（支付宝/微信走跑分）、USDT、国际代付。关键：收款主体、收款码、跑分账户、冻卡与跑路风险，全部是发卡平台的，不是你的。你和 Pangolin 主体永远不出现在这条法币收款链上。你付出的代价是佣金 / 折扣（业界常见 8%–20%，视通道与结算周期）。
+
+
+
+
3取激活码（两种对接模型）
+
这是唯一需要你出工程的地方，二选一（下一节详述）：
+
+- A · 预充卡密库存：你批量生成激活码 → 充值进发卡平台的“卡密库存” → 平台卖一张发一张。你系统零对接，只需生成码 + 补货。
+- B · API 实时签发：用户支付成功 → 发卡平台
webhook 通知你后端 → 你实时签发一张激活码返回 → 平台转发。库存不积压、可控性强，需对接一个回调接口。
+
+
+
+
+
4秒发货
+
发卡平台把激活码即时发给用户（页面展示 / bot 消息 / 邮件）。用户体验和那些灰产 bot 的“付完自动发”完全一致——差别只在风险归属。
+
+
+
+
5兑换 + 核销
+
用户在 Pangolin 客户端或用户中心输入激活码 → 后端 codes 模块核销：校验有效性、一次性消费（幂等 + 防重放 + 并发锁）、把对应套餐时长写进账户 → 订阅生效、全端同步。这一步你们已经实现，是整套方案的“落地点”。
+
+
+
两种对接模型对比
+
+| 维度 | A · 预充卡密库存 MVP 首选 | B · API 实时签发 |
|---|
+
+| 你要出的工程 | 几乎为零：批量生成激活码导出即可 | 一个签发回调接口 + 验签 + 幂等 |
+| 库存管理 | 要盯库存、及时补货（卖光即断供） | 无库存概念，按需签发 |
+| 可控性 / 风控 | 码一旦充进平台就“出手”了，作废要靠平台配合 | 你实时决定发不发、发什么档、可即时止血 |
+| 对账 | 按“充进多少 / 平台报售出多少”对 | 按你签发条数对，最准 |
+| 换平台成本 | 低（码是通用的，换平台重充即可） | 中（每个平台对接一次回调） |
+
+
+
建议：起步用 A（预充库存）——零工程、当天能卖。跑通量之后，对主力发卡平台升级到 B（API 实时签发）拿回控制权与精准对账；两者可并存（不同渠道用不同模型）。
+
+
落地节奏（先能卖，再自动化）
+
+
阶段 0 · MVP（当天可开卖，零/极少开发）
+
+- 你们
codes 模块已可批量生成激活码 → 手动生成一批 → 挂到 1 个发卡平台（预充库存模型 A）或直接 Telegram 人工收 USDT/发卡平台链接。
+- 用户付款 → 平台秒发码 → 用户在客户端兑换。验证需求、跑通话术与定价。
+
+
+
阶段 1 · 半自动（API 实时签发 + 自动对账）
+
+- 后端加 发卡回调接口
POST /v1/codes/issue（B 模型）：验签 → 幂等键（平台订单号）→ 签发激活码返回。
+- 加对账任务：平台售出流水 ↔ 你签发/核销记录，日结核对，异常告警（防超发/漏发/重放）。
+
+
+
阶段 2 · 自助下单页（可选，长期）
+
+- 用户中心 / 官网内做“获取激活码”自助页：接 USDT 自动收款（链上 watcher 到账→签发，你自己钱包，最干净）+ 可选 Telegram Stars。这条不依赖第三方发卡，抽成低、主体干净，但要自己做收款系统。
+- 发卡/Reseller 继续作为“支付宝/微信便利”的并行兜底渠道。
+
+
+
激活码系统要补的接口（阶段 1）
+
+
B 模型 · 发卡平台签发回调
+
POST /v1/codes/issue # 发卡平台在“支付成功”后调用（服务端对服务端）
+ headers: X-Reseller-Sign # HMAC 验签（每个 reseller 一个密钥，Bitwarden 存）
+ body: {
+ reseller_id, reseller_order_no, # 幂等键 = (reseller_id, reseller_order_no)
+ sku, # 套餐档位 → 映射时长/等级
+ amount, currency
+ }
+→ 200 { code: "PGL-XXXX-XXXX-XXXX", expires_at } # 幂等：同一订单号重复调用返回同一张码
+
要点：① 幂等——同一 reseller_order_no 只签发一张（防平台重试超发）；② 验签——HMAC + 时间戳防伪造/重放；③ SKU 映射表——reseller 的商品 ↔ 你的套餐；④ 记录 issued_by=reseller 便于对账与止血作废。
+
+
+
对账 · 防滥用 · 风险边界
+
+- 对账：每个渠道的“进货/售出”对上“签发/核销”。A 模型对充值批次，B 模型对签发流水。日结 + 异常告警。
+- 防滥用：激活码一次性、绑定套餐、可设过期；核销侧限频；发现某 reseller 泄漏/超卖可整批作废未核销的码。
+- 风险边界（务必守住）：见下。
+
+
+红线：Pangolin 主体（尤其中国岩美）永不直接对接跑分/四方聚合、永不用中国支付账户收 VPN 款。法币收款的通道与冻卡/跑路风险，只允许存在于发卡平台/Reseller 那一层。你和用户之间流动的只有激活码，钱到你手里时已经是发卡平台的结算款（法币/USDT，走 US LLC）。挑选 reseller 时优先预付结算 / 短结算周期，降低平台跑路敞口。
+
+
+
主体与渠道归属
+
+| 渠道 | 收款主体 | 干净度 | 定位 |
|---|
+
+| 发卡/Reseller（支付宝/微信） | 发卡平台（非你） | 风险外包，你侧干净 | 大陆“便利”主力 |
+| USDT 自动收款 | 你 · US LLC 钱包 | 干净 | 大陆技术型用户 / 长期主力 |
+| Telegram Stars | TG 官方 → 你 | 干净 | 补充（抽成，走 Apple/Google IAP） |
+| App Store IAP（海外区） | Apple → 你 | 干净 | 海外华人补充 |
+
+
+
加密/结算入账的会计处理归 code/accounting 专门 agent，不在本项目做费用台账。
+
+
待定 / 下一步
+
+- 选定 1 个起步发卡平台（先 A 预充库存跑 MVP）——需要你定候选。
+- 确认 SKU ↔ 套餐 映射与各档定价（对齐
design/CLAUDE.md §7 / 官网 Pricing）。
+- 阶段 1 排期：
POST /v1/codes/issue 回调 + 对账任务（落 todo，走 codes 模块）。
+- 是否并行启动 阶段 2 的 USDT 自动收款（自建下单页），还是先只靠发卡 + 人工。
+
+
+
相关：灰产 bot 收款机制分析（跑分/四方聚合）见对话记录；本方案是其“合规化替身”——同样的“付完秒发货”，风险不落在你的主体上。
+
+
+
pangolin-pay · 收款测试
+
USDT-TRC20 · 单地址 + 唯一金额 · 手动测试页（非生产收银台）
+
+
+
+
+
+ 订单号
+
+
+
+ 状态
+
+
+
+
请支付精确金额（多付少付都不匹配）
+
+
+
+
+ 收款地址
+
+
+
+
+
+
+ TxID
+ —
+
+
+ 过期倒计时
+
+
+
+ 发往此地址、且金额正好等于上面数字的 USDT-TRC20 转账，会在 watcher 下一轮轮询后自动标记
+ paid。金额不符 → 进 orphan 需人工对账。
+ ⚠️ 需 TRONGRID_API_KEY 已配置，否则 watcher 被限流可能侦测很慢。
+
+
+
+
+
+
+ 地址模型：所有订单收到同一地址，靠唯一金额（基准价 + 微尾数 ≤0.01U）区分。
+ 本页仅调 POST /order 与 GET /order/{id}，无私钥、无密钥。
+
+
feature+windows — 项目 TODO
-
18全部
-
8待开始
+
33全部
+
12待开始
0开发中
-
2待验收
-
8已验收
-
+
6待验收
+
15已验收
+
1待确认
平台 / 标签
-
+
@@ -376,7 +376,7 @@ header .header-meta{color:var(--fg-soft)}
- 📋 待开始 8
+ 📋 待开始 12
▴ 收起
@@ -401,7 +401,12 @@ header .header-meta{color:var(--fg-soft)}
现状 L0(stub)：VpnChannel.swift:69 setKillSwitch 直接 result(nil)、includeAllNetworks()→false。天花板 L3。改 NetworkExtension：includeAllNetworks=true + NEOnDemandRule 常开 + enforceRoutes，由 neagent 系统级强制、扛 app 崩溃。性价比最高的跨端缺口。依据见 docs/killswitch-design.md §4-6。
-
+
+
✓ 已确认
+ 二级改动说明
+ 2026-06-30
+
macOS L0→L3,改 2 个原生文件(不动 Dart/服务端)。【VpnChannel.swift】①加缓存 killSwitchEnabled(默认true);②setKillSwitch 落地:存标志+manager已存在则重新applyKillSwitchConfig+saveToPreferences即时生效;③loadOrCreateManager 按标志设 proto.includeAllNetworks/enforceRoutes=true/excludeLocalNetworks=true(放行LAN)+mgr.onDemandRules=[NEOnDemandRuleConnect()]+isOnDemandEnabled;④stop() gotcha:先关 isOnDemandEnabled+save 再 stopVPNTunnel,否则on-demand把断开拉回;⑤start() options 带 killSwitch 传扩展。【PacketTunnelProvider.swift】startTunnel 读 killSwitch option 缓存,includeAllNetworks() 回调返回该值与NE层对齐。无需新增entitlement。验证靠真机:连上后杀扩展/拔网验证流量被阻断(过L1→L2质变线)+on-demand开机/掉线自动拉起+手动断开不反弹。
📄 详见 docs/killswitch-design.html
+
+
+
+
+
+
+
+ 长锁屏重开 app 连接页整页 blank 成全屏转圈再回来。根因:MeNotifier.build 里 watch(authProvider),token 过期后 resume 首个请求 401 刷 token,authProvider 变,meProvider 重建进 AsyncLoading,meLoadingProvider(=me.isLoading)true,connect_page:38 整页转圈。功能无碍(VPN 没断),仅体验跳。改:meLoadingProvider 只在真首次(还没成功拿过账户数据)整页转圈;已有数据后的刷新保持连接页不动、后台静默更新,同时保留原意(别先闪免费再跳会员)。
+
+
+
+
+
+
+
+
+ 点渠道进二级页,按 kind 分组(频道/群组/Bot)列多条链接,内容 DB 配置。新表 contact_link + GET /v1/contact + 各端 UI。设计:docs/contact-telegram-channels-design.html。待用户统一交互后开发。
+
+
+
@@ -645,75 +774,253 @@ header .header-meta{color:var(--fg-soft)}
- 🔍 待验收 2
+ 🔍 待验收 6
▴ 收起
-
+ data-tier="2"
+ data-tags="后端,前端,CI/CD">
-
app/Mac 后台或睡眠一段时间再打开,连通看门狗路径A(urltest stale)用墙上时钟算陈旧度,_lastUrltestOk 在挂起期冻住→唤醒时误判>45s→_onNodeUnhealthy 触发 disconnect+connect 假重连(智能模式还自动切节点),但隧道没掉。修:_onStats 记 _lastStatsAt,路径A 仅在 stats 仍在流但 urltest 停更时才判死;stats 整体停(挂起)则跳过。connection_provider.dart 一处。
-
+ 审查 F1(P0 安全):当前客户端默认 http://103.119.13.48:8080 明文,密码/JWT 裸奔公网。需先有域名/HTTP 服务:域名解析到 pangolin1 → Caddy/nginx 自动 Let's Encrypt 反代 :8080 → 客户端 api_config.dart 默认改 https → Android 移除 usesCleartextTraffic → 8080 收回 loopback。见 docs/code-review-2026-07.html
+
+
✓ 已确认
+ 二级改动说明
+ 2026-07-06
+
控制面上 TLS 走 CF Tunnel:cloudflared 出站隧道前置 api.yanmeiai.com→127.0.0.1:8080(不占 :443,sing-box REALITY 不动)。6 个 Task:①建隧道+装 cloudflared(加法上线,与旧口并存)②客户端默认切 https+去 Android 明文③CI 守护禁明文④PANGOLIN_PUBLIC_URL 切 https(规则集下载基址)⑤待客户端迁移后收 8080 loopback+关防火墙+修健康检查⑥文档。fallback 拆到 #32。
📄 详见 docs/superpowers/plans/2026-07-06-control-plane-tls-tunnel.md
+
-
+
+
+
审查 F2(P0 运维):pangolin1 生产 SQLite 无任何备份,单盘单机。最简:cron 每日 sqlite3 .backup + rclone 推 R2/S3 异地保留 30 天;更优 Litestream 持续复制。恢复流程写 runbook 并演练。见 docs/code-review-2026-07.html
+
+
改动说明三级 · 可直接执行
+
定时 Gitea Actions 备份工作流(镜像 jiu backup.yml):scripts/ci/backup-db.sh(ssh pangolin1 → sqlite3 online .backup 取 WAL 一致快照 + 远端 integrity_check → gzip 流回 → 存 NAS /volume1/docker/backups/pangolin,保留30天)+ .gitea/workflows/backup.yml(每日02:00北京 cron + 手动,ubuntu-latest,复用 DEPLOY_SSH_KEY,Telegram 通知)。异地=家里NAS≠VPS机房。不动 pangolin1。
+
+
+ -
+
+
+
背景与目标：
+pangolin1 出口是机房脏 IP，访问 Reddit 会触发 403 / 验证码。用 Cloudflare WARP 作为 pangolin1 的一条出站（egress），按目的地分流——把信誉敏感流量（Reddit 等）从 WARP 出，出口 IP 变成 Cloudflare 干净 IP，验证码/403 基本消失；其余流量仍直出保满速。WARP 免费（住宅代理按 GB 收费）。参考本地知识库 /Users/wangjia/code/reddit-karma/docs/sni-throttle-warp.html。
+
+实现步骤（pangolin1，sing-box 数据面）：
+1) 在 pangolin1 用 wgcf（或 warp-go）注册并生成 WARP 的 WireGuard 配置 profile。
+2) sing-box 增加一个 wireguard 类型 outbound，tag=warp。
+3) 增加路由规则：下方「走 WARP 的域名」匹配到 outbound=warp；其余走 direct。
+4) 重启 sing-box 并验证。
+
+走 WARP 的域名（用 domain_suffix，自动覆盖子域）：
+- reddit.com（含 www / old / new / sh / oauth.reddit.com API）
+- redd.it（短链）
+- i.redd.it、v.redd.it（图片/视频媒体）
+- redditstatic.com（静态资源）
+- redditmedia.com（媒体）
+先只放 Reddit 全家桶；后续若遇其它易弹验证码的社交站，再按同样方式往这条规则里追加，规则集可扩展。
+
+保持直出（不走 WARP）：
+- 其余所有流量，尤其大流量/大下载——避免 WARP 免费版吞吐瓶颈，保满速。
+
+约束：
+- 改机器前遵循 notify-before-system-changes：先只读勘察 pangolin1 现有 sing-box 配置与是否已装 wgcf → 给出改动清单请用户确认 → 再改 + 重启验证。
+- WARP 配置/密钥不入 git；wgcf 生成的 profile 落 pangolin1 本地（/etc 下），敏感值走 Bitwarden 记录，不提交明文。
+- WARP 本质仍是数据中心 IP，对最严反欺诈可能仍被标记，但对 Reddit 足够；WARP 不作翻墙用途。
+
+验收标准：
+- 经 pangolin 访问 reddit.com 不再出现 403 / 验证码；
+- curl 确认 reddit 路由的出口 IP 属 Cloudflare 段，而其它流量出口仍为 pangolin1；
+- 直出流量速度不受影响。
+
+
+
+
+
+ -
+
+
+
参考 jiu 的 .gitea/workflows(checks/deploy-server/deploy-site/deploy-client/build-windows/backup),套路:tag 触发(server-v*/site-v*/client-v*)→ checkout → provision(幂等)→ compile(scripts/ci/*.sh)→ go test/flutter test → 建 Gitea/Forgejo release 传产物 → ssh 部署目标机;国内镜像 goproxy.cn/flutter-io.cn。pangolin 差异:①部署机=pangolin1(103.119.13.48,非 jiu 的 ali/EC2),走 ssh 别名;②runner label=nas;③server 端要跑 migrate(SQLite,先备份再迁);④client 产出 apk(split-per-abi arm64)+ macOS 公证 dmg + Windows exe + 未来 iOS,这些产物正是官网下载链接的来源(接 web/website Download.astro 的 href)。现有仅 .gitea/workflows/ci.yml(校验,无部署)。含:官网 Astro 构建+部署、server/agent/migrate 编译部署、客户端多端出包与 release 挂载。
+
+
✓ 已确认
+ 一级方案规划
+ 2026-07-05
+
三期 11 任务(基座+官网+服务端 / Android / macOS+Windows);镜像 jiu scripts/ci+workflows,runner nas/mac/windows,tag 触发;服务端部署固化 F3/F4 备份/迁移/回滚;下载链接接 release;密钥已建对齐 jiu。设计 docs/cicd-design.html,计划 docs/cicd-plan.html。
📄 详见 docs/superpowers/plans/2026-07-05-cicd.md
+
+
+
-
+ ✓
+ 30A
+ 官网入口接真实 URL:部署后恢复 Header 登录(→usercenter)+ 下载按钮 href(→客户端产物)
+
二级待验收
+
+-
+ ✓
+ 30B
+ 官网部署:静态站发布到 pangolin.yanmeiai.com + CF DNS 记录指向服务器
+
二级待验收
+
+
+
+ -
+ data-tags="前端,Web,mac,Windows,Android,iOS">
-
用 ds-flow 把 Flutter 五端+官网+用户中心收口到设计单源。补原型三件套(atoms.css/icons.js/index.html)+Web共享原子层去重(各自实现+同源闸)+硬编码色/fidelity闸+启用pre-commit。6阶段。计划见 docs/superpowers/plans/2026-07-07-frontend-ds-refactor.md
-
-
✓ 已确认
- 一级方案规划
- 2026-07-07
-
6 阶段 ds-flow 治理重构:Phase0 CLAUDE.md+计划落库 / Phase1 原型三件套(atoms.css/icons.js/index.html,收敛ui_kits) / Phase2 Web token同源闸 / Phase3 Web共享原子层去重(各自实现+同源闸,★工作量最大) / Phase4 Flutter收尾+golden补齐 / Phase5 静态闸挂满+启用pre-commit+fidelity体检。已定决策:Web各自实现+同源闸、ui_kits收敛纯HTML、先定稿再逐刀。主题保持light/dark。
📄 详见 docs/superpowers/plans/2026-07-07-frontend-ds-refactor.md
-
客户端/官网/用户中心新增 日/韩/俄/西(共6语 zh/en/ja/ko/ru/es),默认语种改英文。官网根路由/=英文、中文挪/zh/、新增/ja//ko//ru//es/;用户中心补入 site-v* CI 部署。B1:硬编码UI文案6语化+修auth错误消息永远显中文bug;B2:语言选择持久化(shared_preferences)。红线扫描0违规。已发 client-v1.0.60 + site-v0.0.6;B1/B2 待 client-v1.0.61。
+
+
+
+ -
+
+
+
长挂机后数据面睡死→看门狗 path A 正确判上游死,但智能模式仅1节点/找不到备用时只会 _disconnect+报节点异常,逼用户手动重连(实测挂机2h回来即遇)。改 _onNodeUnhealthy:无备用节点时自动重连当前节点重建通路,加有限次数保护避免节点真挂时死循环。connection_provider.dart 一处。
+
+
+
@@ -722,12 +1029,244 @@ header .header-meta{color:var(--fg-soft)}
- ✅ 已验收 8
+ ✅ 已验收 15
▾ 展开
+ -
+
+
+
审查 F4:ConnectNode 发每设备 devDp,DisconnectNode 却吊销账户级 ent.DpUUID 且无 device_id 入参——断开从未真正吊销,凭证活到 TTL。修:disconnect 收 device_id,吊销该设备 dp_uuid(账户级作遗留兜底);客户端带上 device_id。
+
+
+
+
+
+ -
+
+
+
审查 F3:device_id 跨账号复用 + devices.uuid 全局 UNIQUE → 第二账号注册永远 403 → 连接被 DEVICE_NOT_REGISTERED 卡死。落地 migration16 注释里推迟的 UNIQUE(user_id,uuid) 表重建,注册查找改按 (user,uuid)。见 docs/code-review-2026-07.html
+
+
+
+
+
+ -
+
+
+
agent 每 dp_uuid 每窗口计 SessionMinutes=1,控制面 ReportUsage 逐条累加进 usage_daily.minutes_used → N 台并发=N×墙上时钟(chenxin 2903/天)。免费卡控下会错误判耗尽。改:账户维度按 user 分组去重(minutes=max,bytes=sum),每设备维度不变。
+
+
+
+
+
+ -
+
+
+
连接期倒计时+到点切断；耗尽按钮灰化；点击弹广告(占位流程)看完+10分钟(累加,每日封顶120);桌面硬10分钟不可延+升级提示。额度全账户共享。服务端ConnectNode按remaining卡控+TTL硬切;ad_bonus_minutes累加模型;DevVerifier占位。
+
+
✓ 已确认
+ 一级方案规划
+ 2026-07-01
+
已进 plan 模式出方案并经用户 ExitPlanMode 批准
📄 详见 /Users/wangjia/.claude/plans/crystalline-exploring-lerdorf.md
+
+
+ -
+
+
+
windowManager.hide() 走 orderOut: 后窗口不可见,点 Dock 图标只发 applicationShouldHandleReopen(hasVisibleWindows=false),AppDelegate 未接管 → 点了没反应。修:AppDelegate 实现 applicationShouldHandleReopen 唤回 mainFlutterWindow。
+
+
+
+
+
+ -
+
+
+
后台/挂起期 urltest 被限流停更但 speed 在流→path A 误判上游死断连。修:statsLive 闸 + 切后台(paused/hidden)停看门狗、resumed 重启并重置基准。另修连接时长墙上时钟(切后台不漏计)。已合 main 07861ea/37c1724/58211d2,含回归测试。
+
+
+
+
+
+ -
+
+
+
现状:plans.max_devices(free1/pro5/team10)+ devices/service.go:216 强制逻辑 + DEVICE_LIMIT_EXCEEDED 错误码 + 账户API DevicesMax 都在,但 main.go:534 登录注册传 MaxDevices:0(不启用)。原因:free 用户重装会换 device UUID,登录硬卡会把人锁外面。需:① 登录/注册从套餐读 max_devices 传入 RegisterIfAbsent;② 超限不直接拒登,改为'踢最旧设备/让用户选哪台下线'的 UX(客户端弹窗 + 设备管理页操作);③ 处理 free 重装 churn(同机复用而非每次新增)。tier-1:涉及登录接口 + 跨后端/前端 + 策略设计。
+
+
⏸ 待确认
+ 一级方案规划 · 确认后方可继续开发
+
登录卡超限(非硬拒登:token照发+返回device_limit信号,客户端挡在移除设备页)+连接backstop兜底;选择移除+一键踢最旧;服务端按last_seen自动清理久不活跃(staleWindow=30d,活跃count排除+登录best-effort删僵尸)。复用现成 DeleteDevice/ResolvePlan/CheckDeviceQuota/ConnectNode。后端:auth service/handler(recordLogin回传+LoginOutcome.DeviceLimit)、devices(DeviceLimitStatus+活跃count+prune)、main wiring、nodes ConnectNode backstop。前端:auth_api解析、auth_provider路由、DeviceLimitScreen、l10n。无DB schema变更。
📄 详见 ~/.claude/plans/crystalline-exploring-lerdorf.md
+
+
+
在终端运行：
+
/todo approve 16
+
+
+
+
- 45s→_onNodeUnhealthy 触发 disconnect+connect 假重连(智能模式还自动切节点),但隧道没掉。修:_onStats 记 _lastStatsAt,路径A 仅在 stats 仍在流但 urltest 停更时才判死;stats 整体停(挂起)则跳过。connection_provider.dart 一处。",
- "level": "mid",
+ "title": "节点判死无备用时自动重连当前节点(而非断开报错)",
+ "desc": "长挂机后数据面睡死→看门狗 path A 正确判上游死,但智能模式仅1节点/找不到备用时只会 _disconnect+报节点异常,逼用户手动重连(实测挂机2h回来即遇)。改 _onNodeUnhealthy:无备用节点时自动重连当前节点重建通路,加有限次数保护避免节点真挂时死循环。connection_provider.dart 一处。",
+ "level": "low",
"tier": 3,
"tags": [
- "mac",
- "前端"
+ "前端",
+ "Android",
+ "iOS"
],
"status": "done",
- "created_at": "2026-06-30T23:00:25.193Z",
+ "created_at": "2026-07-01T04:11:47.293Z",
"done": false,
"completed_at": null,
"version": null,
@@ -290,33 +307,352 @@
},
{
"id": 19,
- "title": "前端设计系统治理重构（ds-flow 全端）",
- "desc": "用 ds-flow 把 Flutter 五端+官网+用户中心收口到设计单源。补原型三件套(atoms.css/icons.js/index.html)+Web共享原子层去重(各自实现+同源闸)+硬编码色/fidelity闸+启用pre-commit。6阶段。计划见 docs/superpowers/plans/2026-07-07-frontend-ds-refactor.md",
+ "title": "连接页 resume 时整页闪 spinner(锁屏久重开)",
+ "desc": "长锁屏重开 app 连接页整页 blank 成全屏转圈再回来。根因:MeNotifier.build 里 watch(authProvider),token 过期后 resume 首个请求 401 刷 token,authProvider 变,meProvider 重建进 AsyncLoading,meLoadingProvider(=me.isLoading)true,connect_page:38 整页转圈。功能无碍(VPN 没断),仅体验跳。改:meLoadingProvider 只在真首次(还没成功拿过账户数据)整页转圈;已有数据后的刷新保持连接页不动、后台静默更新,同时保留原意(别先闪免费再跳会员)。",
+ "level": "low",
+ "tier": 3,
+ "tags": [
+ "前端",
+ "Android",
+ "iOS"
+ ],
+ "status": "open",
+ "created_at": "2026-07-01T04:13:36.446Z",
+ "done": false,
+ "completed_at": null,
+ "version": null,
+ "owner": "agent"
+ },
+ {
+ "id": 20,
+ "title": "看门狗后台唤醒/切后台误判节点死→假断连(已修)",
+ "desc": "后台/挂起期 urltest 被限流停更但 speed 在流→path A 误判上游死断连。修:statsLive 闸 + 切后台(paused/hidden)停看门狗、resumed 重启并重置基准。另修连接时长墙上时钟(切后台不漏计)。已合 main 07861ea/37c1724/58211d2,含回归测试。",
+ "level": "mid",
+ "tier": 3,
+ "tags": [
+ "Android",
+ "iOS",
+ "前端"
+ ],
+ "status": "accepted",
+ "created_at": "2026-07-01T04:14:03.051Z",
+ "done": true,
+ "completed_at": "2026-07-01T14:59:21.052Z",
+ "version": null,
+ "owner": "agent"
+ },
+ {
+ "id": 21,
+ "title": "免费版10分钟卡控+累加式看广告加时",
+ "desc": "连接期倒计时+到点切断；耗尽按钮灰化；点击弹广告(占位流程)看完+10分钟(累加,每日封顶120);桌面硬10分钟不可延+升级提示。额度全账户共享。服务端ConnectNode按remaining卡控+TTL硬切;ad_bonus_minutes累加模型;DevVerifier占位。",
+ "level": "high",
+ "tier": 1,
+ "tags": [
+ "后端",
+ "前端",
+ "数据库",
+ "mac",
+ "Windows",
+ "Android",
+ "iOS"
+ ],
+ "status": "accepted",
+ "created_at": "2026-07-01T15:30:27.692Z",
+ "done": true,
+ "completed_at": "2026-07-02T03:21:30.577Z",
+ "version": "v1.0.44",
+ "gate": {
+ "kind": "plan",
+ "note": "已进 plan 模式出方案并经用户 ExitPlanMode 批准",
+ "ref": "/Users/wangjia/.claude/plans/crystalline-exploring-lerdorf.md",
+ "approval": "granted",
+ "proposed_at": "2026-07-01T15:30:53.245Z",
+ "approved_at": "2026-07-01T15:31:08.948Z"
+ },
+ "owner": "agent"
+ },
+ {
+ "id": 22,
+ "title": "用量分钟数超计(多设备并发按 dp_uuid 累加)",
+ "desc": "agent 每 dp_uuid 每窗口计 SessionMinutes=1,控制面 ReportUsage 逐条累加进 usage_daily.minutes_used → N 台并发=N×墙上时钟(chenxin 2903/天)。免费卡控下会错误判耗尽。改:账户维度按 user 分组去重(minutes=max,bytes=sum),每设备维度不变。",
+ "level": "high",
+ "tier": 2,
+ "tags": [
+ "后端"
+ ],
+ "status": "accepted",
+ "created_at": "2026-07-02T01:34:10.026Z",
+ "done": true,
+ "completed_at": "2026-07-02T03:21:42.079Z",
+ "version": "v1.0.47",
+ "owner": "agent"
+ },
+ {
+ "id": 23,
+ "title": "macOS 最小化托盘后点 Dock 图标无法唤回窗口",
+ "desc": "windowManager.hide() 走 orderOut: 后窗口不可见,点 Dock 图标只发 applicationShouldHandleReopen(hasVisibleWindows=false),AppDelegate 未接管 → 点了没反应。修:AppDelegate 实现 applicationShouldHandleReopen 唤回 mainFlutterWindow。",
+ "level": "mid",
+ "tier": 3,
+ "tags": [
+ "mac",
+ "前端"
+ ],
+ "status": "accepted",
+ "created_at": "2026-07-02T02:50:26.908Z",
+ "done": true,
+ "completed_at": "2026-07-02T03:21:30.418Z",
+ "version": "v1.0.48",
+ "owner": "agent"
+ },
+ {
+ "id": 24,
+ "title": "联系我们渠道二级页：Telegram/LINE 多频道/群组，DB 配置",
+ "desc": "点渠道进二级页,按 kind 分组(频道/群组/Bot)列多条链接,内容 DB 配置。新表 contact_link + GET /v1/contact + 各端 UI。设计:docs/contact-telegram-channels-design.html。待用户统一交互后开发。",
+ "level": "low",
+ "tier": 1,
+ "tags": [
+ "前端",
+ "后端",
+ "数据库",
+ "mac",
+ "Windows",
+ "Android",
+ "iOS"
+ ],
+ "status": "open",
+ "created_at": "2026-07-02T04:22:44.667Z",
+ "done": false,
+ "completed_at": null,
+ "version": null,
+ "owner": "agent"
+ },
+ {
+ "id": 25,
+ "title": "控制面上 TLS：域名 + 反代证书，客户端默认 https（F1）",
+ "desc": "审查 F1(P0 安全):当前客户端默认 http://103.119.13.48:8080 明文,密码/JWT 裸奔公网。需先有域名/HTTP 服务:域名解析到 pangolin1 → Caddy/nginx 自动 Let's Encrypt 反代 :8080 → 客户端 api_config.dart 默认改 https → Android 移除 usesCleartextTraffic → 8080 收回 loopback。见 docs/code-review-2026-07.html",
+ "level": "high",
+ "tier": 2,
+ "tags": [
+ "后端",
+ "前端",
+ "CI/CD"
+ ],
+ "status": "done",
+ "created_at": "2026-07-02T05:07:08.281Z",
+ "done": false,
+ "completed_at": null,
+ "version": null,
+ "gate": {
+ "kind": "change",
+ "note": "控制面上 TLS 走 CF Tunnel:cloudflared 出站隧道前置 api.yanmeiai.com→127.0.0.1:8080(不占 :443,sing-box REALITY 不动)。6 个 Task:①建隧道+装 cloudflared(加法上线,与旧口并存)②客户端默认切 https+去 Android 明文③CI 守护禁明文④PANGOLIN_PUBLIC_URL 切 https(规则集下载基址)⑤待客户端迁移后收 8080 loopback+关防火墙+修健康检查⑥文档。fallback 拆到 #32。",
+ "ref": "docs/superpowers/plans/2026-07-06-control-plane-tls-tunnel.md",
+ "approval": "granted",
+ "proposed_at": "2026-07-06T08:24:55.562Z",
+ "approved_at": "2026-07-06T08:27:20.492Z"
+ },
+ "owner": "agent"
+ },
+ {
+ "id": 26,
+ "title": "SQLite 每日备份 + 异地容灾（F2）",
+ "desc": "审查 F2(P0 运维):pangolin1 生产 SQLite 无任何备份,单盘单机。最简:cron 每日 sqlite3 .backup + rclone 推 R2/S3 异地保留 30 天;更优 Litestream 持续复制。恢复流程写 runbook 并演练。见 docs/code-review-2026-07.html",
+ "level": "high",
+ "tier": 3,
+ "tags": [
+ "后端",
+ "CI/CD",
+ "数据库"
+ ],
+ "status": "done",
+ "created_at": "2026-07-02T05:07:08.354Z",
+ "done": false,
+ "completed_at": null,
+ "version": null,
+ "gate": {
+ "kind": "change",
+ "note": "定时 Gitea Actions 备份工作流(镜像 jiu backup.yml):scripts/ci/backup-db.sh(ssh pangolin1 → sqlite3 online .backup 取 WAL 一致快照 + 远端 integrity_check → gzip 流回 → 存 NAS /volume1/docker/backups/pangolin,保留30天)+ .gitea/workflows/backup.yml(每日02:00北京 cron + 手动,ubuntu-latest,复用 DEPLOY_SSH_KEY,Telegram 通知)。异地=家里NAS≠VPS机房。不动 pangolin1。",
+ "ref": null,
+ "approval": "none",
+ "proposed_at": "2026-07-06T06:53:10.439Z",
+ "approved_at": null
+ },
+ "owner": "agent"
+ },
+ {
+ "id": 27,
+ "title": "同机换账号设备注册 403 死结：devices 唯一键改 (user_id,uuid)（F3）",
+ "desc": "审查 F3:device_id 跨账号复用 + devices.uuid 全局 UNIQUE → 第二账号注册永远 403 → 连接被 DEVICE_NOT_REGISTERED 卡死。落地 migration16 注释里推迟的 UNIQUE(user_id,uuid) 表重建,注册查找改按 (user,uuid)。见 docs/code-review-2026-07.html",
+ "level": "high",
+ "tier": 1,
+ "tags": [
+ "后端",
+ "数据库"
+ ],
+ "status": "accepted",
+ "created_at": "2026-07-02T05:07:56.717Z",
+ "done": true,
+ "completed_at": "2026-07-05T08:54:08.901Z",
+ "version": null,
+ "owner": "agent"
+ },
+ {
+ "id": 28,
+ "title": "disconnect 撤销每设备凭证而非账户级(F4)",
+ "desc": "审查 F4:ConnectNode 发每设备 devDp,DisconnectNode 却吊销账户级 ent.DpUUID 且无 device_id 入参——断开从未真正吊销,凭证活到 TTL。修:disconnect 收 device_id,吊销该设备 dp_uuid(账户级作遗留兜底);客户端带上 device_id。",
+ "level": "mid",
+ "tier": 3,
+ "tags": [
+ "后端",
+ "前端"
+ ],
+ "status": "accepted",
+ "created_at": "2026-07-02T05:20:47.843Z",
+ "done": true,
+ "completed_at": "2026-07-05T08:54:08.986Z",
+ "version": null,
+ "owner": "agent"
+ },
+ {
+ "id": 29,
+ "title": "给 pangolin1 挂 Cloudflare WARP 出站分流：信誉敏感站走 WARP 干净 IP",
+ "desc": "背景与目标：\npangolin1 出口是机房脏 IP，访问 Reddit 会触发 403 / 验证码。用 Cloudflare WARP 作为 pangolin1 的一条出站（egress），按目的地分流——把信誉敏感流量（Reddit 等）从 WARP 出，出口 IP 变成 Cloudflare 干净 IP，验证码/403 基本消失；其余流量仍直出保满速。WARP 免费（住宅代理按 GB 收费）。参考本地知识库 /Users/wangjia/code/reddit-karma/docs/sni-throttle-warp.html。\n\n实现步骤（pangolin1，sing-box 数据面）：\n1) 在 pangolin1 用 wgcf（或 warp-go）注册并生成 WARP 的 WireGuard 配置 profile。\n2) sing-box 增加一个 wireguard 类型 outbound，tag=warp。\n3) 增加路由规则：下方「走 WARP 的域名」匹配到 outbound=warp；其余走 direct。\n4) 重启 sing-box 并验证。\n\n走 WARP 的域名（用 domain_suffix，自动覆盖子域）：\n- reddit.com（含 www / old / new / sh / oauth.reddit.com API）\n- redd.it（短链）\n- i.redd.it、v.redd.it（图片/视频媒体）\n- redditstatic.com（静态资源）\n- redditmedia.com（媒体）\n先只放 Reddit 全家桶；后续若遇其它易弹验证码的社交站，再按同样方式往这条规则里追加，规则集可扩展。\n\n保持直出（不走 WARP）：\n- 其余所有流量，尤其大流量/大下载——避免 WARP 免费版吞吐瓶颈，保满速。\n\n约束：\n- 改机器前遵循 notify-before-system-changes：先只读勘察 pangolin1 现有 sing-box 配置与是否已装 wgcf → 给出改动清单请用户确认 → 再改 + 重启验证。\n- WARP 配置/密钥不入 git；wgcf 生成的 profile 落 pangolin1 本地（/etc 下），敏感值走 Bitwarden 记录，不提交明文。\n- WARP 本质仍是数据中心 IP，对最严反欺诈可能仍被标记，但对 Reddit 足够；WARP 不作翻墙用途。\n\n验收标准：\n- 经 pangolin 访问 reddit.com 不再出现 403 / 验证码；\n- curl 确认 reddit 路由的出口 IP 属 Cloudflare 段，而其它流量出口仍为 pangolin1；\n- 直出流量速度不受影响。",
+ "level": "high",
+ "tier": 1,
+ "tags": [
+ "warp",
+ "network",
+ "reddit",
+ "pangolin1"
+ ],
+ "status": "done",
+ "created_at": "2026-07-02T05:25:38.314Z",
+ "done": false,
+ "completed_at": null,
+ "version": null,
+ "owner": "agent"
+ },
+ {
+ "id": 30,
+ "title": "CI/CD 全流程:tag 触发编译/发版/部署到 pangolin1(server+agent+client 产物+官网)",
+ "desc": "参考 jiu 的 .gitea/workflows(checks/deploy-server/deploy-site/deploy-client/build-windows/backup),套路:tag 触发(server-v*/site-v*/client-v*)→ checkout → provision(幂等)→ compile(scripts/ci/*.sh)→ go test/flutter test → 建 Gitea/Forgejo release 传产物 → ssh 部署目标机;国内镜像 goproxy.cn/flutter-io.cn。pangolin 差异:①部署机=pangolin1(103.119.13.48,非 jiu 的 ali/EC2),走 ssh 别名;②runner label=nas;③server 端要跑 migrate(SQLite,先备份再迁);④client 产出 apk(split-per-abi arm64)+ macOS 公证 dmg + Windows exe + 未来 iOS,这些产物正是官网下载链接的来源(接 web/website Download.astro 的 href)。现有仅 .gitea/workflows/ci.yml(校验,无部署)。含:官网 Astro 构建+部署、server/agent/migrate 编译部署、客户端多端出包与 release 挂载。",
+ "level": "high",
+ "tier": 1,
+ "tags": [
+ "CI/CD",
+ "后端",
+ "前端",
+ "mac",
+ "Windows",
+ "Android",
+ "iOS"
+ ],
+ "status": "done",
+ "created_at": "2026-07-05T09:27:34.399Z",
+ "done": false,
+ "completed_at": null,
+ "version": null,
+ "subtasks": [
+ {
+ "sid": "30A",
+ "title": "官网入口接真实 URL:部署后恢复 Header 登录(→usercenter)+ 下载按钮 href(→客户端产物)",
+ "tier": 2,
+ "deps": [],
+ "status": "done",
+ "created_at": "2026-07-05T09:56:30.954Z"
+ },
+ {
+ "sid": "30B",
+ "title": "官网部署:静态站发布到 pangolin.yanmeiai.com + CF DNS 记录指向服务器",
+ "tier": 2,
+ "deps": [],
+ "status": "done",
+ "created_at": "2026-07-05T11:19:59.363Z"
+ }
+ ],
+ "gate": {
+ "kind": "plan",
+ "note": "三期 11 任务(基座+官网+服务端 / Android / macOS+Windows);镜像 jiu scripts/ci+workflows,runner nas/mac/windows,tag 触发;服务端部署固化 F3/F4 备份/迁移/回滚;下载链接接 release;密钥已建对齐 jiu。设计 docs/cicd-design.html,计划 docs/cicd-plan.html。",
+ "ref": "docs/superpowers/plans/2026-07-05-cicd.md",
+ "approval": "granted",
+ "proposed_at": "2026-07-05T15:41:17.465Z",
+ "approved_at": "2026-07-05T15:45:12.499Z"
+ },
+ "owner": "agent"
+ },
+ {
+ "id": 31,
+ "title": "官网文档页:撰写 快速开始/FAQ/协议与安全/隐私政策 4 页,接回 Docs 卡片链接",
+ "desc": "web/website Docs 区当前 4 张卡为占位信息卡(不可点)。需撰写真实文档页(可用 Astro content/MDX 或 docs 站),写好后把 Docs.astro 卡片改回 并恢复「阅读」CTA、页脚 文档/FAQ/隐私政策 指向对应页。注意:隐私政策属法律文本,由创始人审定,Claude 仅出初稿;对「无日志」VPN,隐私政策是软性上线门槛。",
+ "level": "mid",
+ "tier": 2,
+ "tags": [
+ "Web",
+ "文档"
+ ],
+ "status": "open",
+ "created_at": "2026-07-05T10:08:52.391Z",
+ "done": false,
+ "completed_at": null,
+ "version": null,
+ "owner": "agent"
+ },
+ {
+ "id": 32,
+ "title": "控制面 fallback:CF 域名被 SNI 封时客户端退回直连节点 IP 的 https 控制口",
+ "desc": "#25 采用 CF Tunnel 前置控制面(api.yanmeiai.com)。已知弱点:该域名可被 GFW 单独 SNI 封锁,届时登录/拉配置不可用(已连隧道不受影响,数据面 REALITY:443 直连也不受影响)。加固:客户端 api 层保留一个直连某健康节点 IP 的 https 控制面 fallback——域名连不上/握手被 RST 时自动退回直连,保证仍能登录/刷新配置/换节点。服务端需在节点上也暴露一个可直连的 https 控制口(或复用现有端口+证书)。属 #25 的后续加固,不在 #25 本轮范围。",
+ "level": "mid",
+ "tier": 2,
+ "tags": [
+ "前端",
+ "后端",
+ "Android",
+ "iOS"
+ ],
+ "status": "open",
+ "created_at": "2026-07-06T08:15:57.519Z",
+ "done": false,
+ "completed_at": null,
+ "version": null,
+ "owner": "agent"
+ },
+ {
+ "id": 33,
+ "title": "三端多语言(6语)+ 默认英文",
+ "desc": "客户端/官网/用户中心新增 日/韩/俄/西(共6语 zh/en/ja/ko/ru/es),默认语种改英文。官网根路由/=英文、中文挪/zh/、新增/ja//ko//ru//es/;用户中心补入 site-v* CI 部署。B1:硬编码UI文案6语化+修auth错误消息永远显中文bug;B2:语言选择持久化(shared_preferences)。红线扫描0违规。已发 client-v1.0.60 + site-v0.0.6;B1/B2 待 client-v1.0.61。",
"level": "mid",
"tier": 1,
"tags": [
"前端",
"Web",
"mac",
- "iOS",
- "Android",
"Windows",
- "CI/CD"
+ "Android",
+ "iOS"
],
"owner": "agent",
"status": "done",
- "created_at": "2026-07-07T15:41:25.760Z",
+ "created_at": "2026-07-07T08:36:36.295Z",
"done": false,
"completed_at": null,
- "version": null,
- "gate": {
- "kind": "plan",
- "note": "6 阶段 ds-flow 治理重构:Phase0 CLAUDE.md+计划落库 / Phase1 原型三件套(atoms.css/icons.js/index.html,收敛ui_kits) / Phase2 Web token同源闸 / Phase3 Web共享原子层去重(各自实现+同源闸,★工作量最大) / Phase4 Flutter收尾+golden补齐 / Phase5 静态闸挂满+启用pre-commit+fidelity体检。已定决策:Web各自实现+同源闸、ui_kits收敛纯HTML、先定稿再逐刀。主题保持light/dark。",
- "ref": "docs/superpowers/plans/2026-07-07-frontend-ds-refactor.md",
- "approval": "granted",
- "proposed_at": "2026-07-07T15:41:36.536Z",
- "approved_at": "2026-07-07T15:54:54.386Z"
- }
+ "version": null
+ },
+ {
+ "id": 34,
+ "title": "独角数卡 + USDT 收款闭环",
+ "desc": "自建发卡网(独角数卡,独立小 VPS 隔离部署,不放 pangolin1)+ USDT(TRC20)收款,打通『下单→付款→自动发激活码→客户端/用户中心兑换→订阅生效』闭环。复用已就绪后端:POST /webhook/store/codes(HMAC+时间戳+nonce)、POST /v1/redeem(JWT)、批次生成/导出(server/internal/codes)。收款终点=单一自托管 USDT 钱包,变现经交易所出金到 US LLC(记账走 accounting)。真相源三文档:docs/payment-a-selfhosted-store-plan.html · payment-channels-overview.html · payment-reseller-fulfillment-design.html。tier-1:含新增 /internal/codes/mint(模型B 单源产码)+ 跨 server/发卡网/客户端/运维。待定:钱包(自托管热钱包 vs 交易所地址)、USDT 路子(自建 TronGrid watcher vs 加密网关)、起步用模型A(预充卡密,零胶水当天可卖)。开工前按 tier-1 走 plan→propose→approve。",
+ "level": "mid",
+ "tier": 1,
+ "tags": [
+ "后端",
+ "支付",
+ "运维"
+ ],
+ "owner": "agent",
+ "status": "open",
+ "created_at": "2026-07-08T14:10:36.343Z",
+ "done": false,
+ "completed_at": null,
+ "version": null
}
]
}