From f6a22734d3804b6f92d20a4bb57cc2d6dede0a09 Mon Sep 17 00:00:00 2001 From: wtclaude Date: Thu, 30 Jul 2026 02:51:53 -0500 Subject: [PATCH] docs(android): link the M11 app PRs and name the remaining gate Both parts are built: Android-app#30 (the visibility rules + read-model adds) and #31 (the four screens, stacked on it). The on-device five-rung walk against a website on the cutover branch is what edge->main is now actually waiting on. Co-Authored-By: Claude --- android/PLAN.md | 4 ++++ link/v3.md | 9 ++++++--- 2 files changed, 10 insertions(+), 3 deletions(-) diff --git a/android/PLAN.md b/android/PLAN.md index 47782a1..a682d43 100644 --- a/android/PLAN.md +++ b/android/PLAN.md @@ -913,6 +913,10 @@ push, and Play (M6–M8) follow the designed app. `/public/shard/features` simply `404`s, and each consumer below falls back to exactly today's behavior. The app declares no protocol version and never talks to the sidecar. + **Both parts are built and in review:** Part 1 `RunicGateway/Android-app#30`, Part 2 (stacked on + it) `#31`. 336 unit tests pass and lint is clean on both; the on-device five-rung walk below is + the remaining gate, and it is what the cutover is actually waiting on. + - **Part 1 — the visibility rules + the read-model adds.** The security-shaped half, reviewed on its own: - `GET /public/shard/features` → `{ level, features[] }`: the features **this caller** may reach. diff --git a/link/v3.md b/link/v3.md index 284f886..ba3106f 100644 --- a/link/v3.md +++ b/link/v3.md @@ -961,9 +961,12 @@ request rides the same authenticated OkHttp client as every other call, so an ap the same audience rung as the same account on the web; and every shard DTO in the app is nullable-with-defaults, so field projection strips fields without a deserialization failure. -Scoped as **M11 in [`../android/PLAN.md`](../android/PLAN.md) §9**, two PRs (the visibility rules + -read-model adds, then the four screens). `edge` → `main` is held until both land, so web and app -surface the same shard on the same day. Neither PR is coupled to the merge order — on a pre-v3 website +Scoped as **M11 in [`../android/PLAN.md`](../android/PLAN.md) §9**, two PRs: the visibility rules + +read-model adds ([Android-app #30](https://gitea.whitlocktech.com/RunicGateway/Android-app/pulls/30)) +and the four screens ([#31](https://gitea.whitlocktech.com/RunicGateway/Android-app/pulls/31), stacked +on it). Both are **built and in review**; the on-device five-rung walk (§11) against a website on the +cutover branch is the remaining gate. `edge` → `main` is held until both land, so web and app surface +the same shard on the same day. Neither PR is coupled to the merge order — on a pre-v3 website every new route and `/public/shard/features` `404`s and the app falls back to today's behavior — so holding the cutover is a schedule decision, not a technical dependency.