# VPNCheap Android Customer Feedback Improvement Plan

Date: 2026-07-31  
Mode: planning only  
Plan confidence: **89/100**. Convert four shipped-but-unverified fixes into device evidence, then close password recovery and shared freshness gaps. This is an executive judgment score, separate from fingerprint priority.

Governing contract: [Feedback-to-Roadmap Decision Contract v1.0, 2026-07-31](https://vpncheap-feedback-brief-20260731.pages.dev/feedback-to-roadmap-decision-contract.md)

## Evidence and state

- **OBSERVED:** process kill lost the selected node; the Quick Settings tile could not cold-start; some services felt slower; forgot password is absent.
- **MEASURED:** matching v2.0.27 code exists for selection persistence, tile cold-start, and QUIC/DoT fallback behavior. Current source still has no reset-password flow.
- **OBSERVED:** later no-node and stale-account reports span multiple native clients, so local unit tests do not prove closure.

`△△△△ ☐☐☐ | 0/4/3/0`

| State | IDs | Local obligation |
|---|---|---|
| `△` | VPN-07, VPN-08, VPN-09, VPN-12 | Matching implementation exists; real-device/released-build proof is missing. |
| `☐` | VPN-16, VPN-17, VPN-13 adoption | Password recovery, freshness contract, and future signed client capability are not end-to-end. |

```text
BEFORE  restart/re-login -> maybe fresh -> user guesses
AFTER   authoritative generation -> visible freshness -> one-tap recovery -> receipt
```

## Execution sequence

Order follows dependency and owner sequence, not numeric rank. Canonical fingerprint scores and program-value judgments are different decision ledgers and are not directly comparable.

Scores below are canonical registry references, not local rescores: item 1 -> VPN-12; item 2 -> VPN-17; item 3 -> VPN-07/08/09, each 68; item 4 -> VPN-16; item 5 -> VPN-13.

### 1. Native node-state release matrix: 81/100, P1

Breakdown: `24 + 15 + 12 + 15 + 5 + 10`.

**PROPOSED:** test current released build for fresh login, existing login, stale subscription path, process kill, account switch, pull refresh, mirror failure, cached recovery, and empty-list reason. One canonical cross-client fingerprint remains open until every supported Android cohort passes.

### 2. Account and subscription freshness: 81/100, P1

Breakdown: `24 + 15 + 12 + 15 + 5 + 10`.

**PROPOSED:** adopt Xboard's versioned freshness envelope, add Settings/Account pull-to-refresh, show last successful refresh and safe stale reason, and never require re-login after a valid top-up or renewal.

### 3. Device verification of v2.0.27 fixes: 68/100, P2

Breakdown: `24 + 7 + 12 + 5 + 10 + 10`.

**PROPOSED:** verify node persistence after OS kill, tile cold-start with app absent, and controlled app/site latency before and after QUIC fallback. Separate client, route, DNS, and service-node evidence.

### 4. Forgot-password recovery: 51/100, P3

Breakdown: `24 + 3 + 12 + 0 + 5 + 7`.

**PROPOSED:** add reset request, neutral anti-enumeration response, expiring link/deep-link handling, success/expired recovery, localization, and backend contract tests.

### 5. Signed client capability adoption: 54/100, P3 evidence gate

Canonical breakdown: `24 + 3 + 5 + 15 + 0 + 7 = 54`.

**PROPOSED:** inventory Android client identity and token/session behavior, then adopt Xboard's signed capability. Do not authorize by user agent alone.

## Phases

### 0-30 days

- Produce a privacy-safe verification matrix for all four `△` items.
- Freeze the P1/P2 freshness envelope with Xboard.
- Inventory signed-capability dependencies and collect its evidence envelope only; this is ordinary evidence collection, not P3 acceleration, and no exception is claimed.
- Document only the observed password-reset gap, current-route inventory, and missing acceptance evidence; no UX or backend solution design occurs in this phase, no P3 acceleration is claimed.

### 31-60 days

- Implement only failed P1/P2 verification regressions and freshness UI in an isolated clean worktree.
- Add P1/P2 lifecycle, cache, failover, and account-switch tests.

### 61-90 days

- Canary the current Android release; monitor no-node, refresh, cold-tile, disconnect, and reset completion fingerprints.
- After scheduled P0-P2 gates close, design and implement password-recovery UX and backend semantics, then complete its anti-enumeration, expiry, deep-link, localization, and backend acceptance matrix.
- After scheduled P0-P2 gates close, define and adopt the signed-capability contract with Xboard.
- Promote to `○` only after real device tunnel transition plus changed public egress, with no sensitive network data recorded.

### Phase gates

- **0-30:** evidence coverage reaches 100%.
- **31-60:** every scheduled P1/P2 acceptance is complete or explicitly approved `X`.
- **61-90:** two canary windows close without regression.
- Stop immediately on any listed guardrail.
- No P3 acceleration is claimed; password-recovery and signed-capability work start in 61-90 only after P0-P2 gates close.

## Guardrails

- Core/Android VPN service owns connection truth; supervisory probes never tear down a surfaced connected session.
- Diagnostics never expose ingress address, node protocol, raw subscription URL, or config.
- Nodes remain a list; no protocol labels; preserve encrypted storage and API failover/cache behavior.
- Stop on auth enumeration, stale-account overwrite, cache poisoning, or network-detail leakage.