Sync upstream Silo-Server/silo-android (30 commits)

.github/release.yml

@@ -0,0 +1,15 @@
+# Groups the release notes GitHub generates by the labels prairie-triage puts on
+# pull requests. Store notes keep only the Features and Fixes sections
+# (scripts/release-version.py). See docs/releasing.md.
+changelog:
+  categories:
+    - title: 🚀 Features
+      labels: [enhancement]
+    - title: 🐛 Fixes
+      labels: [bug]
+    - title: 📚 Documentation
+      labels: [documentation]
+    - title: 📦 Dependencies
+      labels: [dependencies]
+    - title: Other changes
+      labels: ["*"]

.macroscope/check-run-agents/visible-change-evidence.md

@@ -0,0 +1,111 @@
+---
+title: Visible change evidence
+model: gpt-6-luna
+reasoning: high
+input: full_diff
+tools:
+  - browse_code
+  - git_tools
+  - github_api_read_only
+  - modify_pr
+exclude:
+  - ".agents/**"
+  - "docs/superpowers/**"
+conclusion: neutral
+maxRuns: 3
+maxBudgetPerRun: 0.50
+maxBudgetPerPR: 3.00
+---
+
+Prairie requires evidence in every pull request that changes what a user sees. Reviewers should be
+able to see the change without building the branch. Your job is to decide whether this PR changes
+what a user sees, on which devices, and, if it does, whether its Evidence section shows that change
+on each of them. You report; you do not judge whether the change is good.
+
+The rules are in `CONTRIBUTING.md` under "Show visible changes". Read that section first; it is the
+authority if this prompt and it disagree.
+
+## Decide whether the change is visible
+
+Read the PR title, body, and full diff. Trace changed code to what a user would see; do not match
+on file names alone. A change is visible when it alters any of these:
+
+- app UI in the phone app (`androidApp/`), the TV app (`androidTvApp/`), or the code they share
+  (`android-shared/`, `shared/`), including strings and resources: layout, styling, copy,
+  navigation, focus, empty and error states;
+- which items a screen shows, or in what order: search results, home sections, recommendations,
+  library browsing, collections, sorting, or filtering;
+- what an item shows: titles, artwork, descriptions, ratings, badges, episode grouping, or
+  availability;
+- playback behavior a user notices: default audio or subtitle tracks, markers, controls, or resume
+  position.
+
+These are not visible on their own: unit and instrumented tests, CI, fastlane, Gradle and baseline
+profile changes that do not change what ships, internal refactors with identical output, logging,
+and documentation. When the path to the user is real but uncertain, say so and treat the change as
+visible.
+
+## Work out which devices it reaches
+
+The devices are an Android phone, an Android tablet, an Android foldable folded and open (any
+model, such as a Galaxy Z Fold or Pixel Fold), and Android TV. The phone app runs on the first
+three; the TV app runs on Android TV; shared modules reach both apps unless the changed code is only
+called from one. Then trace the layout checks around the changed code:
+
+- `smallestScreenWidthDp`, `widthDp` and `heightDp` thresholds, `isExpandedWindow`, and
+  `isExpandedDetailLayout` decide whether a screen takes its phone or wide layout. A folded
+  foldable behaves like a phone; an open one takes the wide layouts a tablet does.
+- `FoldingFeature` and `isTabletopPlayerPosture` reach only a foldable, open or half-folded.
+
+List each device the change reaches. When you cannot tell whether a device is reached, count it.
+
+## Check the evidence
+
+Find the `## Evidence` section of the PR body. For a visible change, it passes when it has:
+
+- before-and-after images, a recording, or a line starting with `Evidence:
+  https://evidence.prairieserver.org/`;
+- evidence that matches the change: a UI change needs screenshots or a recording; a change to which
+  items appear or their order needs a before and an after of the same screen with the same data;
+- captures for every device the change reaches, with the foldable both folded and open, or a
+  reason the PR gives for each device it leaves out;
+- a recording when the change is about motion, timing, focus movement, or a multi-step flow;
+- the device and build or commit the captures came from.
+
+Evidence on `evidence.prairieserver.org` is private, and you cannot open it. For a section that links
+a page there, count the link as evidence, do not ask for the devices or build in the body, and list
+the devices the page should show so the reviewer can check it.
+
+An explanation of why evidence could not be captured is acceptable; report it so the reviewer can
+decide, and do not count it as a pass. A reason for leaving out a device is acceptable when the code
+you traced agrees with it; when it does not, say which code reaches that device.
+
+For a change that is not visible, the section should say `Evidence: none, no user-visible change`.
+If it is empty or still holds the template table, suggest that line.
+
+You cannot open images. Judge them from their placement, alt text, captions, and surrounding text.
+Never claim an image shows something you could not read.
+
+## How to report
+
+Always write the check run summary. Start with one line: `visible` or `not visible`, and `evidence
+complete`, `evidence incomplete`, `evidence missing`, or `evidence explained as unavailable`. Then
+list the user-visible effects you found, each with the file that causes it and the devices it
+reaches, and what the evidence covers or lacks.
+
+Post one conversation comment on the PR only when a visible change has missing or incomplete
+evidence, or when a change that is not visible has no Evidence line. Name each visible effect that
+lacks evidence, the devices it is missing on, and the kind of evidence it needs, in one line each.
+If the author has replied that evidence is not needed or has explained why it is unavailable,
+accept that and do not raise it again unless new commits change what users see.
+
+## Rules
+
+- Do not change the PR title, body, labels, assignees, or reviewers. Do not @-mention anyone.
+- Comments are public. Do not include hostnames, IP addresses, local paths, credentials, or personal
+  data.
+- If you see private details in the evidence, such as hostnames, URLs, account names, or personal
+  library contents, say that the evidence needs redacting without repeating the details.
+- Write plainly: lead with the finding, use active voice, and skip praise and filler.
+- End every comment with `<sub>Automated check: Macroscope check run agent (gpt-6-luna). Evidence was
+  not reviewed for correctness.</sub>`

AGENTS.md

@@ -11,7 +11,7 @@ This repository contains only the Prairie Android clients. Shared Kotlin logic l
 - Android TV navigation is Home, available media-type tabs from server libraries, For You (with its Watchlist/Favorites dropdown, mirroring tvOS `.recommendations`), Calendar, and Requests while the server enables it (mirroring tvOS `.requests`), plus search and profile actions. Reading/ebooks are excluded.
 - Live TV (Prairie-only) is live on phone and TV, gated by `LiveTvFeatureStore` (the server has channels), and reached from the profile menu (phone `ProfileMenu` via `LocalLiveTvMenuAction`; TV profile dropdown). It is not a bottom-nav or top-menu tab.
 - Upstream Silo syncs have silently dropped Prairie-only code. `scripts/check-prairie-invariants.sh` (CI job "Prairie invariants") anchors it; see `docs/upstream-sync.md`. When restoring dropped code, add an anchor.
-- Requests is live on phone and TV, server-gated by `requests_enabled` (phone: profile menu + search; TV: a top-bar tab + search, matching Apple). Admins who can moderate requests approve, decline, and retry them in the Requests screens, as on Apple; limits and auto-approval stay in web admin. Other admin surfaces are not exposed in the Android clients — no STATS dashboard, and none of the richer admin screens (users/sessions/logs/scans). Session management (seeing where you are signed in and signing other devices out) is not exposed either; device pairing stays. This is a deliberate divergence from Apple, which does surface the STATS dashboard. Do not add any of it back to menus without an explicit product decision.
+- Requests is live on phone and TV, server-gated by `requests_enabled` (phone: profile menu + search; TV: a top-bar tab + search, matching Apple). Request administration (approve, decline, retry, limits, auto-approve) is web-admin only: the Requests screens offer users request, cancel of their own pending request, and status, and never moderation (a source guard test enforces this). Other admin surfaces are not exposed in the Android clients — no STATS dashboard, and none of the richer admin screens (users/sessions/logs/scans). Session management (seeing where you are signed in and signing other devices out) is not exposed either; device pairing stays. This is a deliberate divergence from Apple, which does surface the STATS dashboard. Do not add any of it back to menus without an explicit product decision.
 - Watch Party (synchronized playback) is experimental on phone and TV. Its entry points (profile menu, the detail page's party action, and phone `prairie://watch-party` invitations) appear only while Settings → Experimental → Watch Party is on, a device-local toggle that defaults on in debug builds and off in release builds, and it works only when the server advertises the room and playback capabilities. Keep it behind the toggle until the qualification matrix in `docs/watch-party-implementation-plan.md` passes.
 
 ## Skills & review agents
@@ -32,7 +32,7 @@ repos are under `.agents/code-review-kit/`.
 
 ## Coding Style & Naming Conventions
 
-Use Kotlin 2.1, Java 21 targets, and Compose idioms. The Prairie package root is `org.prairieserver.prairie`. Both the phone and TV apps share a single `applicationId`, `org.prairieserver.prairie`, so they publish as one Google Play listing (Play routes each build by manifest feature filtering — the phone build requires `android.hardware.touchscreen`; the TV build requires `android.software.leanback`). The Gradle `namespace` stays distinct per module (`org.prairieserver.prairie.android`, `org.prairieserver.prairie.tv`) so generated `R`/`BuildConfig` classes don't collide. The two artifacts use distinct versionCodes (`base*2` for phone, `base*2+1` for TV), so each release bumps both by 2 with no reuse. Releases derive the base from the marketing version plus a build number (`base = 100_000_000 + (major*10000 + minor*100 + patch)*1000 + build`), so the same version can ship repeatedly as build 1, 2, 3 the way TestFlight does — bump the build number rather than inventing a new patch version for a re-release. This repo is on the full Prairie namespace cut, so do not add legacy package IDs, legacy storage names, or old-brand symbols. Kotlin classes and composables use `PascalCase`; functions and properties use `camelCase`.
+Use Kotlin 2.1, Java 21 targets, and Compose idioms. The Prairie package root is `org.prairieserver.prairie`. Both the phone and TV apps share a single `applicationId`, `org.prairieserver.prairie`, so they publish as one Google Play listing (Play routes each build by manifest feature filtering — the phone build requires `android.hardware.touchscreen`; the TV build requires `android.software.leanback`). The Gradle `namespace` stays distinct per module (`org.prairieserver.prairie.android`, `org.prairieserver.prairie.tv`) so generated `R`/`BuildConfig` classes don't collide. The two artifacts use distinct versionCodes (`base*2` for phone, `base*2+1` for TV), so each release bumps both by 2 with no reuse. `scripts/release-version.py` derives the base from the store version and a repository-wide build number (`base = 100_000_000 + (major*10000 + minor*100 + patch)*1000 + build`), so a version ships as many tester builds as it needs before its store release. See `docs/releasing.md`. This repo is on the full Prairie namespace cut, so do not add legacy package IDs, legacy storage names, or old-brand symbols. Kotlin classes and composables use `PascalCase`; functions and properties use `camelCase`.
 
 ## Testing Guidelines
 
@@ -74,7 +74,10 @@ follow-up work.
   covers UI and UX changes and changes to which items appear or what they show,
   such as search results, home sections, recommendations, sorting, filtering,
   metadata, or artwork. Use before-and-after captures of the same screen with the
-  same data, and a short recording when motion, timing, or focus matters. Write
+  same data, and a short recording when motion, timing, or focus matters.
+  Capture each device the change can reach: an Android phone, an Android
+  tablet, an Android foldable (folded and open), and Android TV, or say why a
+  device is unaffected. Write
   `Evidence: none, no user-visible change` only when that is true.
 - Attach evidence on GitHub under the PR body's Evidence heading, or publish it
   with `npx @prairie-server/evidence publish <folder> --pr <number>` and put its

FEATURES.md

@@ -10,7 +10,7 @@ A detailed inventory of what the Android **phone** and **TV** clients do today.
 
 File pointers are repository-relative.
 
-> **Important exposure note:** Requests is live on both Android surfaces, gated by the server's `requests_enabled` flag (`/api/v2/requests/status`), and reached from the profile menu and search on phone and from a top-bar tab and search on TV — matching the Apple clients. Admins who can moderate approve, decline, and retry requests there. The richer admin screens (users/sessions/logs/scans) remain inaccessible. Watch Party is experimental, behind Settings → Experimental → Watch Party.
+> **Important exposure note:** Requests is live on both Android surfaces, gated by the server's `requests_enabled` flag (`/api/v2/requests/status`), and reached from the profile menu and search on phone and from a top-bar tab and search on TV — matching the Apple clients. Request administration (approve, decline, retry, limits, auto-approve) stays in web admin. The admin screens (users/sessions/logs/scans) remain inaccessible. Watch Party is experimental, behind Settings → Experimental → Watch Party.
 
 ---
 
@@ -88,7 +88,7 @@ Shown only while Settings → Experimental → Watch Party is on (default on in
 | Release calendar | ✅ | ✅ | Top-level mobile tab and TV top-menu tab |
 | Live home refresh (events websocket) | ✅ | ✅ | `HomeRealtimeCoordinator`: user_state/catalog channels, 2s debounce; TV also refreshes on resume |
 | System "Watch Next" row integration | ➖ | ✅ | `WatchNextRepository` (tvprovider) |
-| Requests | ✅ | ✅ | Server-gated by `requests_enabled`; phone: profile menu + search; TV: top-bar tab + search; admin approve/decline/retry |
+| Requests | ✅ | ✅ | Server-gated by `requests_enabled`; phone: profile menu + search; TV: top-bar tab + search; "Notify me when available" on titles someone else requested (when the server reports `follow_supported`); request administration stays in web admin |
 
 ## Reading (ebooks)
 
@@ -135,7 +135,7 @@ Shown only while Settings → Experimental → Watch Party is on (default on in
 | Favorites & watchlist | ✅ | ✅ | TV: from Settings |
 | Ratings | ✅ | ✅ | |
 | Watch history | ✅ | ✅ | |
-| Content requests (browse/search TMDB, status tracking) | ✅ | ✅ | Four-step status track, My Requests, admin approvals; see Requests above |
+| Content requests (browse/search TMDB, status tracking) | ✅ | ✅ | Four-step status track, My Requests, notify me when someone else's request becomes available; see Requests above |
 | Release calendar | ✅ | ✅ | |
 | Notifications inbox (paginated, realtime updates, mark-read) | ✅ | ✅ | REST + WebSocket |
 
@@ -160,6 +160,6 @@ Shown only while Settings → Experimental → Watch Party is on (default on in
 
 **TV** is a 10-foot, D-pad client focused on browsing and playback, including audiobooks, calendar, the subtitle suite, person detail, and system Watch Next integration. It intentionally omits ebooks/reading and downloads management.
 
-**Not currently exposed on either Android surface:** the admin stats dashboard and full admin management (users/sessions/logs/scans). **Experimental:** Watch Party, behind Settings → Experimental. Request moderation (approve, decline, retry) is the one admin action the Requests screens offer.
+**Not currently exposed on either Android surface:** the admin stats dashboard, full admin management (users/sessions/logs/scans), and request moderation (approve, decline, retry), which stays in web admin. **Experimental:** Watch Party, behind Settings → Experimental.
 
 Both apps share the same networking, auth, repositories, most ViewModels, and the entire Media3 playback/capability stack.