VPNCHEAP · CEO BRIEF
只读侦察 · 2026-07-31

源码支持的主机制。
状态链断了。

源码证据支持一个跨端主机制：账户快照、订阅定位与节点目录分开缓存，局部触发没有完整传播。登录是所有平台都稳定走完的链，但 Apple App 内支付大多另有完整流程；生产工单占比仍待遥测。

先看 90 秒结论 直接看 CEO 回复稿

范围边界：本轮只做侦察与规划。未修改客户端、未创建 GitHub Project、未改 issue、未触发发布。

12真实 open issues排除 PR，分散在 4 个仓库
1/12有任意标签分类几乎为空
0/12有负责人归属不可见
2可执行原生发布流只证明 workflow；到达率未知
Executive verdict

四个要求，一条主线

Android 找回密码是明确缺功能。节点、续费与账户刷新共享一个跨端状态传播主机制，Windows 另有独立额度校验根因。Issue “统一目录”应解决查看问题，不应破坏代码归属。

源码级根因判定

当前代码不支持把全部工单归为一个长期后端缓存故障。

后端源码会读取当前账户与节点状态，客户端源码则存在“只刷新账户、不更新订阅定位”“只刷新套餐、不拉节点”“支付成功只改 UI 状态”“恢复前台只查隧道”等断点。登录会绕开这些局部缓存，因此常能恢复；真实工单中各根因占比仍需设备版本、请求轨迹与生产指标证明。

状态传播机制 85/100
01

Android 找回密码

后端能力已存在。补原生 UI、验证码与重置 API 接入，不需要新后端。

02

节点手动为主，关键事件自愈

不做固定计时或缓存年龄强刷。登录或新账户、账户 / 权益 / 定位指纹变化、缓存不可用、换号与凭据拒绝恢复可自动刷新一次；纯目录轮换保持手动。

03

缓存与上次成功检查

成功才原子替换本地缓存；暂时失败且账户仍有效时保留旧节点与原检查时间，权威失效则隔离。触屏端下拉，桌面与 TV 保留明确按钮。

04

统一问题中心

Issue 留在代码仓库。一个 GitHub Project 自动汇总，展示仓库、平台、原生类型、状态与负责人。

Fable 5 独立裁决：AGREE，整体 78 / 100

同意主机制跨客户端状态传播断链与重登恢复解释成立，机制置信度约 85。
限制绝对表述登录是所有平台都完整执行的链，不是字面上的唯一完整链；Apple App 内支付大多另有完整流程。
生产归因未证源码能证明缺口，不能证明真实工单中各原因占比。
补齐发布证据iOS 修复在功能分支、独立 macOS 安装版本未知、Windows 修复未合并。
节点策略：MODIFY手动为主加正确性事件自愈 94；严格永不自动 34；15 分钟轮询 55。

P0 独立事件：Android TV 发布凭据安全事件

在受限事件流程内完成影响评估、轮换与现有安装升级连续性验证；闭环前停发该端。公开报告不记录载体、路径、材料或技术细节。

Stop-Ship 100
Android 接入现有找回密码能力98

后端已具备，缺口明确，风险与范围最小。

七表面统一刷新行为契约96

方案评分 96；机制置信度约 85。仍需单独修复 Windows 不限量根因。

触屏下拉 + 桌面按钮 + TV 焦点按钮95

匹配各平台输入方式，入口一致且可发现。

原仓 issue + 统一 Projects V297

一张 CEO 视图，仍保留代码归属和零 LLM 主链。

保持当前 Apple 最低系统版本90

没有付费用户证据前，避免扩大兼容与测试面。

每仓建设受保护原生发布链92

原生签名与商店不同，必须独立但采用同一发布闸门。

Failure anatomy

为什么重登就恢复

登录是唯一在所有平台都稳定执行的完整强刷入口，并非各平台字面上的唯一完整链。Apple App 内支付大多另有完整流程；其余常用刷新路径仍只更新一段。

典型续费失败链

不同客户端断点不同，用户体验却一致。

1

受影响的续费路径

网页或部分客户端续费后，服务端状态改变，但该路径没有可靠完成事件。

2

局部账户刷新

到期与流量可能更新，但订阅定位仍旧。

!

节点仍用旧快照

命中缓存、拒绝后清空，或根本不拉节点。

4

页面继续空

前台恢复与设置页没有完整刷新入口。

5

重新登录

重建账户快照与节点目录，所以常能恢复；具体工单仍待版本与请求轨迹归因。

耐久修复：账户触发统一同步；节点目录日常只手动刷新，只有登录或新账户、本地账户 / 权益 / 定位指纹变化、缓存缺失或不可用、换号与凭据拒绝恢复才自动拉取一次。成功原子替换；暂时失败且账户仍有效时保留旧节点，权威失效则隔离。

三类证据会推翻或显著降低当前归因

完整请求仍旧症状设备已强刷账户与节点，但后端仍返回陈旧或空状态。
会话差异同一账户旧会话持续陈旧，新登录会话立即变新，指向服务端会话缓存。
只影响旧版本工单几乎都来自旧版本，升级后无需重登即可恢复。
○ 已实现并验证△ 已实现，未真机或生产验证 ☐ 未闭环X 阻断或不适用 42 项：○ 1 · △ 6 · ☐ 33 · X 2
客户端表面找回密码双通道协调器续费自愈手动刷新与成功检查前台账户检查受保护发布链闭环
Android 手机Kotlin / Compose☐☐☐☐☐☐
Android TVKotlin / Compose TV☐ 待核实☐☐☐ 按钮☐X 停发
iOSApple native shared△△☐ 含外部☐☐○
macOSApple native shared△△☐ 含外部☐☐☐
Apple TVSwiftUI / tvOSX 网页☐☐☐ 按钮☐☐
独立 macOSSwiftUI / System Extension△☐☐☐☐☐ 安全链
WindowsWPF / .NET 4.8△☐☐☐☐☐

Android 手机

NativeAndroid
断点

账户同步明确不更新订阅定位；提前续费只刷新套餐，不重新拉节点；恢复前台只查连接健康。

最小耐久改动

权威账户写入最新定位；前台只查账户。节点手动刷新，支付后账户 / 权益 / 定位指纹变化时自愈一次，成功才换缓存。

97源码断点

Android TV

NativeTV
断点

节点凭据拒绝直接清空并要求重登；非空旧定位不会刷新账户；无前台刷新。

最小耐久改动

拒绝后刷新账户并重试一次；设置页加焦点按钮与上次成功检查时间；缓存先显示，不做周期节点拉取。

98源码断点

iOS / 共享 macOS

NativeSwift
断点

核心刷新链已较完整，App 内支付大多也能走完；但登录仍是跨 iOS / macOS 一致稳定的全量触发。前台、外部网页支付、账户与设置没有接入。

最小耐久改动

复用现有 generation / epoch 围栏；scene active 只查账户，三指纹变化后才拉节点。页面提供手动刷新、暂时失败留旧与上次成功检查时间。

95源码断点

Apple TV

NativetvOS
断点

已有 last-good 与并发保护，但非空缓存启动不联网，格式有效的旧定位绕过账户刷新。

最小耐久改动

Home active 只查账户；旧定位变化后才拉节点。设置加入焦点按钮，暂时失败且账户仍有效时保留原缓存与成功检查时间。

94源码断点

独立 macOS

NativemacOS
断点

冷启动竞态在当前源码已修，但用户实际安装版本未知。现有 30 分钟任务只刷新订阅且可命中 1 小时缓存，支付后不保证重新拉节点。

最小耐久改动

active 只查账户；支付后账户 / 权益 / 定位指纹变化再拉节点一次。账户 / 设置加按钮，节点成功才原子换缓存。

95源码断点

Windows

NativeWPF
双根因

独立根因是主线冷启动把不限量误判为无额度；传播断点是支付成功只改 UI，Home 单例只初始化一次。

最小耐久改动

先合入额度修复；支付后账户 / 权益 / 定位指纹变化与空缓存自动拉一次，其他时候节点只手动。暂时失败且账户仍有效时不重置现有列表。

98源码断点

Xboard 后端

BackendFresh state
源码已排查

账户与节点请求查询当前用户；节点响应含可用性原因、数量与随状态变化的 ETag。

证据边界

这能排除一个源码层面的全局长期缓存设计，不能替代生产请求轨迹。仍需保留“真无套餐 / 到期 / 额度耗尽 / 禁用”等权威空状态。

93源码断点
Proposed behavior contract

刷新一次，整条链一致

共享行为，不共享代码。账户状态可以自动同步；节点目录手动为主，不做固定周期拉取，只保留正确性事件自愈。

双通道触发策略

前台只检查轻量权威状态；account、entitlement、定位三指纹全部未变化时，节点请求严格为零。没有 5/15 分钟轮询，也没有 24 小时陈旧强刷。

退
登出 / 切换账户立即提升 generation，旧账户节点不可见，晚到结果不得写回
隔离优先
刷
用户手动刷新节点节点页始终可用；触屏下拉，桌面键盘按钮，TV 焦点按钮
永远强制
变
账户、权益或定位变化本地三指纹任一改变才拉节点一次
自动一次
空
登录 / 新账户 / 缓存不可用缓存缺失、损坏或无法解密时自动建立首份有效列表
自动初始化
拒
节点凭据拒绝强刷账户后重试节点一次，禁止循环或首次失败即重登
自动恢复一次
前
普通恢复前台只检查账户；三指纹全不变时绝不请求节点
节点不变
1 · 登出 / 换号提升 generation，旧账户节点立即隔离
2 · 登录 / 新账户 / 缓存不可用缺失、损坏或无法解密时自动建立首份有效缓存
3 · 用户手动刷新始终 force，不依赖新鲜度
4 · 账户、权益或定位变化三指纹任一改变后自动拉节点一次
5 · 凭据拒绝等待受保护账户结果；权威失效则隔离，否则同一 recovery operation 去重入队一次节点重试
6 · 普通前台 / 页面出现不刷新节点，不改变上次成功检查时间
账户检查并发独立 accountRequestEpoch + single-flight；generation / epoch 不匹配的晚到快照丢弃
纯目录批量轮换当前后端无 catalog revision：只由手动刷新或其他正确性事件发现

成功才替换，暂时失败留旧

先显示当前账户的加密缓存。新节点必须完整验证后一次性发布；任何暂时故障都不能把可用列表变空，权威失效则准确隔离。

01

只显示 usable 缓存

加密缓存原子携带 generation、账户 / 权益 / 定位三指纹、设备内 catalog 提交指纹、cacheState、reason、etagEligible、ETag、source、freshness 与 lastSuccessfulCheckAt。quarantined / absent 永不显示。

02

只在允许事件请求节点

三指纹全部不变的普通前台、页面出现、计时器与缓存年龄，都不能触发节点请求。

03

捕获版本并完整校验

请求记录 accountGeneration、单调 requestEpoch，以及预期账户、权益、定位三指纹；响应再通过结构、状态和账户匹配。catalog 指纹只在成功解析后做本地提交去重。

04

只让最新请求原子提交

全部版本值仍匹配才提交；每轮在途触发只合并成一个 trailing request，trailing 期间的新外部允许事件进入下一轮，响应、计时器与递归不能自行续跑。旧响应丢弃。

05

按故障类型处理缓存

暂时失败旧节点与上次成功检查时间完全不变，显示“刷新失败，继续使用上次成功列表”。
权威失效无套餐、过期、撤销、禁用、额度耗尽或会话失效才清除或隔离。
有效非空响应内容变化才原子替换节点、三指纹、catalog 提交指纹、ETag、状态与成功时间；内容未变只更新成功检查
ETag 304仅 usable、eligible、字节已验证且三指纹匹配时算成功检查；节点不变
无有效缓存却收到 304不更新时间；同一事件内只补一次无条件全量请求，仍失败则停止
网络 / 超时 / 解析 / 5xx旧节点与原成功检查时间不变，显示最近失败
账户有效但空响应无类型视为不完整结果，保留旧节点，不发布空列表
权威无套餐 / 到期 / 禁用 / 耗尽 / 撤销 / 会话失效设 quarantined，清节点 / catalog 指纹 / ETag、禁用条件请求，保存 reason / 三指纹 / 检查时间
登出 / 换号旧账户节点立即不可见，晚到结果不得覆盖
同账户请求乱序只有最新 epoch 且三指纹匹配者可提交；其余丢弃
节点页固定显示“上次成功检查：本地日期与时间”。暂时失败不更新时间，并显示“最近刷新失败，继续使用上次结果”；权威失效按成功状态检查记录时间并隔离列表。
统一刷新契约96

正确的治理修复，但不是充分条件；Windows 并行根因、设备验证和发布到达率必须同时闭环。

缓存 + 成功原子替换 + 暂时失败留旧 + 成功检查时间99

账户仍有效时，暂时失败不会把可用列表变空；权威失效仍会准确隔离，用户能看到检查时间。

手动为主 + 正确性事件自愈 + 无计时节点轮询94

尊重用户控制，同时解决续费、空缓存、换号与旧凭据恢复。

严格手动，永不自动刷新34

会把“必须重登”改成“必须知道手动刷新”，续费与首次使用仍可能空白。

15 分钟周期节点轮询55

当前明确拒绝。未来若改变，必须新建 decision record，并先证明 revision 与事件链无法修复。

实施前四项跨边界审计，未通过不得从 △ 升到 ○

生命周期清单逐端枚举 active / resume / pause / destroy 的既有消费者，确认新刷新窗口不会触发竞态。
错误契约新增或改名的 UI、服务、扩展错误码，所有消费者必须显式处理，不能落入静默兜底。
状态发射源同一状态通道只保留权威来源；合成探针在操作进行中必须抑制并记录原因。
终态等待瞬时状态不能直接结束进行中操作；优先使用与本次 operation / revision 对应的权威确认，仅在平台实测需要时采用有依据的停留窗口。
One view, original ownership

统一看问题，不移动问题

Issue 继续留在所属代码仓库，统一 Project 只做跨仓视图、优先级、负责人和进度。CEO 得到一张总看板，工程师仍在原仓处理。

推荐 97 / 100

一个 VPNCheap 产品问题中心

使用 GitHub Projects V2。12 个套件仓库各放一个事件工作流：创建、重开或转移时自动加入；标签、指派与关闭变化同步执行字段。没有定时 LLM，也不复制 issue。

12纳管套件仓库
0当前 Projects V2
12现存 open issues 待一次回填
1Free 内建自动添加仓库上限
已核验的 12 仓纳管清单

vpncheap · vpncheap-android · vpncheap-android-tv · vpncheap-app · vpncheap-apple-native · vpncheap-apple-tv · vpncheap-download · vpncheap-ios · vpncheap-macos · vpncheap-maintained · vpncheap-web · vpncheap-windows

收件箱自动进入
ANDROID · APP续费后节点目录未更新
P0NativeAndroid
APPLE · CLIENT恢复前台未执行完整刷新
P1NativeApple
已分诊按类型
WINDOWS · CLIENT冷启动额度判定不一致
P0NativeWindows
ANDROID TV · RELEASE发布凭据处置与升级连续性
P0SecurityTV
处理中按负责人
SHARED CONTRACT实现全量刷新协调器
P0ReliabilityAll native
待验证真机闸门
DEVICE MATRIX支付、前台、离线与账户切换
P0VerifyMatrix

上方仅为目标结构示意，不代表当前 issue 编号、状态或负责人。现存 12 条先幂等回填到“收件箱”，再人工分诊。

01 · SOURCE

原仓 issue 是唯一事实源

讨论、代码链接、PR、关闭状态都留在对应仓库。统一看板保存引用，不造副本，不改变团队工作习惯。

02 · EVENT

事件驱动自动收集

官方 Action 负责加入 Project；同一工作流再用确定性 Project API 更新自定义字段。两者固定到审核版本并可幂等重跑；一次性脚本回填历史 open issues。

03 · ZERO LLM

分类靠确定性规则

仓库映射平台与运行时；Priority 只在 Project 中分诊，不复制为标签。AI 只允许负责人按需总结，绝不参与同步正确性主链。

权限、负责人和漏同步恢复

opened / reopened / transferred查找或加入 item，再按统一状态优先级求值
labeled / unlabeled校验平台、运行时、表面与类型；冲突时标记 taxonomy-conflict 并进入待补充
assigned / unassigned使用内建 Assignees 作为 Owner，并校验 Project item 可见
closed幂等查找 Project item 并设置 Status = 完成
Status 优先级closed → 完成；否则 taxonomy-conflict → 待补充；否则新建 / 重开 / 转移 → 收件箱
状态测试覆盖 close → 完成、reopen → 收件箱、冲突 reopen → 待补充
任何失败告警 Owner，保留运行日志；按需 GraphQL 对账并幂等补回
Owner平台 / Dev Productivity 负责人拥有 Project、凭据轮换与失败处置，不挂在个人开发者账号。
现在的授权用户级 Project 使用公司控制、只允许 Project 写入与必要 issue 读取的专用 PAT；禁止代码写入，每 90 天复核轮换，人员变动立即轮换。
未来的授权迁到组织 Project 时改用组织安装的 GitHub App，减少单账号依赖。
告警与恢复负责人订阅失败运行；保留日志。按需一键对比全部 open issues 与 Project，幂等补回缺项并可安全重跑。
失效边界同步失败只影响视图，不改变原 issue。凭据恢复后重跑审计，原仓讨论、状态与链接不丢失。
定时策略无 cron、无 LLM。漏事件先修工作流；审计只由负责人按需一键运行，不潜藏周期任务。

统一标签，描述问题本身

仓库已说明代码归属。Platform / Runtime / Surface / Type 固定为可视 badge，不复制成 Project 字段；以下就是完整字典，不允许临时造同义标签。

platform:androidplatform:iosplatform:macosplatform:tvosplatform:windowsplatform:webplatform:backend runtime:nativeruntime:flutterruntime:webruntime:service surface:phonesurface:tabletsurface:desktopsurface:tvsurface:websurface:backend type:authtype:account-billingtype:node-datatype:connectiontype:releasetype:uitype:servertype:support-noisetype:security taxonomy-conflict
默认仓库映射 Platform / Runtime / Surface；无法确定 Type 时加 taxonomy-conflict，不猜
基数Runtime、Type 各一个；共享或跨端 issue 可有多个 Platform / Surface
冲突保留 taxonomy-conflict，并把 Project Status 设为待补充，禁止自动计划
执行字段Status 与 Priority 只在 Project 中维护，不复制为 labels

Project 执行数据，只管进度

自定义字段与标签不重复职责；Repository 和 Assignees 直接使用 GitHub 内建数据。

Status收件箱 / 待补充 / 已分诊 / 已计划 / 处理中 / 待验证 / 完成
PriorityP0 / P1 / P2 / P3，在 Project 收件箱中分诊
Owner / Assignees使用 GitHub 内建 Assignees，避免复制负责人字段
RepositoryGitHub 内建字段，直接显示归属
Customer reports默认空白 / 0，仅在有可核验用户反馈时递增
Last report date最后一次用户反馈日期
Saved viewsCEO 看板 / Native 矩阵 / Hot issues / 待补充 / Release blockers（Type=Release + 高 Priority + 未完成）
统一 Projects V2 + 每仓事件架构97

自动、保留原仓事实源、零定时 token；评分针对控制面架构。

当前用户 Project + 公司专用 PAT78

可立即落地，但存在单账号与多仓 secret 扩散风险，必须明确 Owner、轮换和漏项恢复。

未来迁到组织 Project + GitHub App92

长期权限模型更稳，但当前组织形态与迁移成本需先确认。

单独建“总问题仓库”复制 issue27

双份状态、链接漂移、责任归属更模糊。

定时 AI 汇总器作为主链21

不必要的 token、延迟与失败面，且不能替代原仓事实源。

Native release reality

“一键发布”不是一个链接

每个原生仓库必须有自己的签名、构建、测试与发布工作流。当前只有 iOS TestFlight 与独立 macOS 两条可运行链；链存在不等于修复已到达用户，真实安装版本与 rollout cohort 必须单独证明。

Android 手机

Native Kotlin

☐ 未建设0 个 workflow需要版本、测试、签名、产物与商店发布链打开 Actions

Android TV

Native Kotlin + Compose TV

X 停发11 个旧 workflow流程按 Flutter 脚本编写且不可用；先完成发布凭据事件处置打开 Actions

iOS

Shared Apple native

○ 已实跑TestFlight最近核验成功 2026-07-12；来源是功能分支，不代表用户已安装刷新修复打开工作流

共享 Apple macOS

同仓独立 target

☐ 未建设0 个 macOS workflow不可把 iOS TestFlight 链当作 macOS 发布链打开 Actions

Apple TV

Native tvOS

☐ 未建设0 个 workflow需要 tvOS Archive、签名、测试与 TestFlight 链打开 Actions

独立 macOS

Developer ID distribution

△ 可执行签名 + 公证最近核验成功 2026-07-27；仍缺测试、目标版本与分支保护闸门，用户实际安装版本未知打开工作流

Windows

Native WPF

☐ 未建设0 个 workflow需要构建、测试、签名、安装包与更新清单链打开 Actions

每条原生发布链的最低顺序

01 · 静态检查与单元测试任何失败立即停止，结果绑定提交。
02 · 确定性构建 / Archive版本、构建号、依赖与来源分支可追溯。
03 · 签名受保护环境读取发布凭据，不允许降级为未签名产物。
04 · 安装与冒烟真实目标系统安装，完成启动、登录与基础连接检查。
05 · 平台验证macOS 公证与票据、Apple 商店处理、Android / Windows 包验证。
06 · 受保护分批发布人工批准、版本防重、灰度监控与上一已知良好产物回滚。

当前整体现状：NO-GO，12 / 100

客户端修复尚未完成、真机验证与用户到达证明不足，Android TV 还有发布凭据安全事件。可以并行修其他平台，但 TV 在安全闭环前不得发布。

Release gate
Deployment targets

最低系统版本，先保持

上传所需的最新 Xcode 与 SDK，和用户设备最低版本是两件事。现有 target 由源码确认，是否下调必须由付费用户数据而不是猜测驱动。

源码中的真实基线

iPhone / iPad

共享 Apple 原生项目

iOS 17
macOS

共享 Apple 原生项目

macOS 14
Apple TV

独立 tvOS 项目

tvOS 17.4
macOS

独立系统扩展项目

macOS 14
Decision

保持 iOS 17 / macOS 14

这套基线与当前源码、系统扩展和设计实现一致。Apple 仍向部分旧设备发安全更新，不等于本产品必须马上扩大支持面。

  • 先读取真实安装、付费、退款与客服数据中的系统版本分布。
  • 如旧系统付费用户占比有商业意义，再单独评估 API 降级、设计回退、测试矩阵和支持成本。
  • 最低版本变化必须经过真机启动、登录、支付、连接与升级验证。
90保持当前基线
证据不足时的最稳决定
保持 iOS 17 / macOS 14 / tvOS 17.490

代码与能力基线一致，测试面可控；残余风险是尚未拿到用户版本分布。

现在直接下调到更旧系统43

覆盖面可能增加，但没有收入数据支撑，且会扩大设计、API 与设备测试成本。

Execution roadmap

先止血，再统一，再发布

这是实现顺序，不是假定工期。四条平台线可并行，但共享契约、测试场景与发布闸门必须一致。

○ 已实现且实测△ 已实现待实测☐ 未开始X 停止或不适用实施路线：○ 0 / △ 0 / ☐ 22 / X 0
PHASE 0 · SAFETY

冻结真相与发布风险

在改刷新前锁定状态语义、版本和安全边界。

  • Android TV 发布凭据事件指定负责人并限制处置范围
  • 在受限记录内完成影响评估、轮换与升级连续性验证
  • 记录 7 个客户端线上版本、来源分支、渠道与安装 cohort
  • 冻结统一空状态与会话失效语义
  • 建立按版本分组的去敏刷新链指标
依赖：无　Owner：Security + Release
并行：共同版本 / 状态基线冻结后，其余平台可进 Phase 1；TV 事件只阻断 TV 发布
验收：每条生产现象可关联安装版本与刷新链结果；TV 保持独立 Stop-Ship 直至受限事件闭环
停止：版本来源或升级连续性不明即保持 TV 停发　回滚：不发布 TV，不改变线上凭据状态
PHASE 1 · ROOT FIX

修上游状态断链

每个平台先解决自己的确定性根因，再接统一触发。

  • Android 补齐完整账户快照并去除支付状态短路
  • Android TV 凭据拒绝时先刷新账户并只重试一次
  • Apple 各端去除旧定位对权威账户刷新短路
  • Windows 合入不限量冷启动修复与回归测试
  • 所有端引入 generation、单调 requestEpoch、single-flight 与版本匹配原子发布
依赖：共同版本 / 状态基线，不依赖 TV 事件闭环　Owner：Android / Apple / Windows leads
并行：三平台线独立实现；TV 可改代码但不可发布　验收：竞态、缓存与错误语义测试通过
停止：后端证据推翻根因或出现会话误清　回滚：功能开关或聚焦 revert 返回旧刷新链
PHASE 2 · TRIGGERS

统一用户触发与问题中心

把产品体验与团队观察面接到同一契约。

  • Android 登录页接入找回密码完整流程
  • 触屏端加下拉刷新，桌面端加键盘可用按钮，TV 加焦点按钮
  • 账户自动同步与节点手动刷新拆成双通道，不做周期节点轮询
  • 节点缓存成功才替换；暂时失败且账户有效时留旧并显示原成功检查时间
  • 创建统一 Projects V2、标签、字段与 CEO 视图
  • 12 仓事件工作流和历史 issue 幂等回填
依赖：Phase 1 状态链　Owner：Client UX + Dev Productivity
并行：刷新入口与 Project 可分开　验收：零 LLM 自动收集；普通前台不改节点；成功原子替换、暂时失败留旧、权威失效隔离均可观测
停止：授权、告警、缓存隔离或漏项恢复未闭环　回滚：禁用新触发 / Action，原 issue 与旧入口保留
PHASE 3 · VERIFY

真机矩阵与分批发布

代码审查只能到 △，真实设备与发布链通过后才到 ○。

  • 内购续费、网页续费、到账延迟与支付取消
  • 冷启动、普通前台不改节点、离线、换号与登出后晚到请求
  • 手动刷新成功原子替换；暂时失败且账户有效时保留旧节点和原成功检查时间
  • 权威无套餐、到期、禁用、额度耗尽、撤销与会话失效正确隔离
  • 连接状态完整往返并确认公网出口变化
  • 建设缺失发布链，按版本 cohort 灰度并验证用户实际安装
依赖：对应平台 Phase 1 至 2；TV 发布另需安全事件闭环　Owner：独立 QA + Release
并行：按平台设备矩阵，非 TV 平台不等待 TV　验收：7 表面各自通过，产物可追溯、已到达目标 cohort 且可回滚
停止：任一平台 P0、会话误清、仍需重登或新版本指标不改善　回滚：仅停止该平台灰度并恢复上一已知良好版本

并行分工建议

客户端线Android / Android TV、Apple、Windows 三组并行实现同一契约。
平台线GitHub Project、标签、事件工作流与发布链独立推进。
验证线测试矩阵、去敏指标、设备与回滚验证独立于实现者。
Paste-ready response

给 CEO 的逐项回复

去掉术语争论，直接回答问题归属、原因、处理方式、发布入口与版本边界。

可直接发送

内容只承诺已完成的侦察与下一步实施，不把规划写成已上线。

已把原生客户端、后端、GitHub issue 和发布流程统一排查。逐项回复如下：

  1. 安卓找回密码：后端已有找回密码接口，Android 手机客户端缺少页面和调用链，属于客户端遗漏。计划补齐验证码发送、密码重置、错误提示、本地化和测试。Android TV 的登录与恢复路径在实施基线中单独核实，本报告不预设为不适用。
  2. 续费后没有节点、需要重新登录：源码已确认多个原生客户端把账户状态、订阅定位和节点目录分开缓存，支付完成、恢复前台和返回页面常没有走完整链；登录则是所有平台都稳定执行的全量链，所以常能恢复。Apple App 内支付大多另有完整流程。Windows 主线还有独立的不限量额度判定错误。生产工单中各原因占比仍要用真实版本和请求轨迹确认。
  3. 账户、设置与节点刷新：采用双通道。账户状态可在登录、支付和恢复前台时同步；节点目录日常只由用户手动刷新，不做 5/15 分钟轮询或缓存年龄强刷。登录或新账户、本地账户 / 权益 / 定位指纹变化、缓存缺失 / 损坏 / 无法解密、换号和凭据拒绝恢复属于正确性事件，可自动拉取一次。节点使用本地加密缓存，成功才原子替换；网络、超时、解析或无类型空响应等暂时失败且账户仍有效时保留旧节点与原“上次成功检查”时间；权威无套餐、到期、禁用、额度耗尽、撤销或会话失效则清除或隔离。当前纯目录轮换保持手动发现。
  4. 统一查看 issue：issue 继续归所属代码仓库，不复制、不移动。新建一个“VPNCheap 产品问题中心”跨仓看板，自动汇总全部 12 个仓库，并显示仓库、Native / Flutter、平台、类型、优先级、负责人和状态。采用 GitHub 事件自动加入，不需要定时 AI、定时任务或 token。
  5. 一键发布链接：原生客户端不是共用一个 Flutter 发布入口。当前已核验可运行的是 iOS TestFlight 和独立 macOS 签名公证工作流；两条工作流可运行不代表修复已发布或已到达用户，真实安装版本与 rollout cohort 未知。Android、Android TV、共享 Apple macOS、Apple TV、Windows 的原生发布链需要分别建设。Android TV 发现发布凭据安全风险，闭环前暂停该端发布。
  6. 最低系统版本：当前源码基线是 iOS 17、共享与独立 macOS 14、tvOS 17.4。建议先保持，等真实付费用户、安装和客服数据证明旧系统覆盖有商业价值后，再评估下调和增加测试成本。App Store 上传使用最新 SDK，与客户端最低系统版本不是同一件事。
  7. 执行顺序：先处理 Android TV 发布安全并建立线上版本、来源分支和安装 cohort 基线，再并行修 Android、Apple、Windows 根因；随后接刷新入口和统一问题中心；最后做真机支付、前台、离线、账户切换和分批发布。未经真机与用户到达验证的项目只标为“已实现待验证”，不会当作已解决。
Evidence & method

结论从哪里来

源码、GitHub 实时状态与官方文档交叉核验。未修改客户端、GitHub issue / Project 或发布状态；本简报仅部署为只读静态页面。所有统计是 2026-07-31 的时点快照。

官方与实时来源

GHGitHub：自动添加到 Project每条内建规则只覆盖一个仓库或过滤器，Free 方案只有一条，且不回填旧 issue。 GHGitHub：用 Actions 自动化 ProjectProject 可跨仓；工作流应放在每个仓库，并使用适合 Project 的独立授权。 ACTGitHub 官方 add-to-project Action事件驱动加入统一看板的最小构件；实施时固定到审核过的提交。 Apple：提交要求当前上传工具和 SDK 要求不等于产品 deployment target。 Apple：Xcode 支持范围用于核对当前工具链能构建的最低目标系统。 Apple：App Store 设备采用率只作为方向信号，不能替代 VPNCheap 自己的付费用户数据。 Apple：安全更新记录用于确认部分旧设备仍收到安全维护，不等于产品必须扩大 deployment target。

源码证据摘要

后端与 Android
  • 后端已提供密码重置、当前账户与节点目录接口，并给出权威可用性原因；但轻量账户响应没有目录 revision，现有 server/fetch ETag 也不是实际配置事实源。
  • Android 账户持久化缺少刷新链所需的完整身份与订阅字段，支付路径只在“不可用变可用”时重拉节点。
  • Android TV 在节点凭据被拒绝时直接清会话，而不是先更新账户并重试一次。
Apple 系列
  • 共享项目已具备可复用的强制刷新与版本围栏，但 iOS / macOS 恢复 active 没有调用完整链。
  • Apple TV 与独立 macOS 都有缓存或旧订阅定位短路，导致外部续费后状态继续陈旧。
  • 当前项目配置核验为 iOS 17、macOS 14、tvOS 17.4。
Windows
  • 主线把不限量额度错误判成不可用；修复仅存在未合并分支，尚未验证。
  • 支付成功只更新付款 UI，Home 单例初始化后不重新拉取；退出登录会重建状态。两项可独立或共同形成同样现象，既有生产工单尚未完成归因。
GitHub 时点快照
  • 使用身份已核验的团队账号只读凭据完成查询，未使用个人账号凭据。
  • 12 个套件仓库中，真实 open issues 为 12 条，分布在 4 仓；1 条有标签，0 条有 assignee；Projects V2 为 0。
  • 原生发布链只有 iOS TestFlight 与独立 macOS 两条可运行；源码存在不等于用户已安装。

研究与独立意见

Grok 实时第二意见：推荐“各仓事件驱动 Actions + 跨仓 Project”，不需要 LLM 或定时循环；同时区分最新上传 SDK 与最低用户系统版本。
三条并行源码侦察

Android / Android TV、Apple 全家桶、Windows / 独立 macOS 各由独立子代理读取源码、工作流和版本配置；主代理逐项抽查关键证据并做跨端归因。

Recall 与 Automation Hub

Recall 用于检索历史上下文，涉及发布和兼容性的结论仍以本轮实时核验为准。Automation Hub 只读参考了现有跨项目总览的可视结构，未进行任何修改。

Fable 5 独立裁决

第一次对根因结论为 AGREE：整体置信度 78，跨客户端状态传播机制约 85。第二次冻结“手动为主、正确性事件自愈、无周期节点轮询”。后端复核后，Fable 再裁决为 MODIFY：接受本地三指纹，catalog 改为解析后语义集合的设备内提交指纹；它建议 24 小时前台强刷，但因违反 CEO 明确约束未采用。

质量边界

已确认
  • 客户端状态传播断点的源码路径与后端当前代码行为。
  • 当前后端没有可供轻量前台检查比较的 catalog revision；纯目录轮换保持手动发现。
  • Windows 不限量校验错误是独立并行根因。
  • GitHub 仓库、issue、Project 与 workflow 的实时快照。
  • Apple 项目中声明的最低系统版本和官方当前提交要求。
仍需实施阶段确认
  • 用户当前安装的真实客户端版本、来源分支、发布渠道和 rollout cohort。
  • 各根因在生产工单中的真实占比，以及旧会话和新会话是否存在服务端差异。
  • 付费用户系统版本、外部续费占比、退款与客服影响分布。
  • 手动刷新使用率、暂时失败且账户有效时保留旧节点的持续时间，以及正确性事件自愈是否覆盖全部续费场景。
  • Android TV 发布事件的影响范围、受限处置方案与商店升级连续性。
证伪条件
  • 完整强刷请求仍收到后端陈旧或空状态。
  • 同一账户仅旧会话陈旧，新登录会话立即变新。
  • 问题几乎只来自旧版本，升级后无需重登即可恢复。
交付质量闸门

CodexLoop 对最终事实、刷新合同和 CEO 文案做迭代审查；最终结论以交付时 Completion gate 为准，不在页面预写。真实浏览器覆盖 320、390、768 与 1440 px，并检查溢出、筛选、主题、复制、ARIA、打印、无脚本降级和控制台。