* fix(app): hold the loading screen until first-run setup is decided A new user saw the empty home, the sidebar and a logo jump before setup popped in. Startup now keeps the splash while setup may still open over the empty home, for at most 3 s and only while the setup host is reachable. Remembered-workspace restore does not wait. Web dialogs now fade in as they already fade out. (cherry picked from commita0a7620b62) (cherry picked from commit72d7c0bf26) * fix(app): fade the dialog card in and land the dim at once (cherry picked from commit6ef05705a0) (cherry picked from commit71c28b431c) * fix(app): keep the loading screen up while startup redirects (cherry picked from commit0b28d4cbff) (cherry picked from commit13cc485e6f) * test(app): cover a setup host that drops while startup waits (cherry picked from commit2a906ef83e) (cherry picked from commit7b6e21207a) * fix(app): type the web-only dialog enter animation style The CSS animation props are not part of ViewStyle. CI typechecks without the generated expo-env.d.ts, which declares them, so the cast is required there. (cherry picked from commitb887d979d2) * fix(app): keep the setup window mounted when the theme changes The shell's appearance boundary remounts its dialog hosts whenever a theme color changes, so picking a theme in setup, or a system light/dark switch, replaced the open setup window and replayed its fade. Setup draws colors through CSS variables and themed props, which update in place, and changes no font size, so it now sits outside that remount. The dialog enter fade is skipped with reduced motion, and its style is typed for CI, which typechecks without the generated expo-env.d.ts. (cherry picked from commitb24c6eacf8) (cherry picked from commitcb0e9907f5) * docs(changelog): prepare 0.15.2 (cherry picked from commit5af1a8ff66) * chore(release): cut 0.15.2 (cherry picked from commite896c05b09)
Paseo website
Plugin install counts
Clients report an install by resolving a plugin with X-Paseo-Install: 1 or
?intent=install, using /api/plugins/resolve/<owner>/<slug> or
/plugins/<owner>/<slug>.json. Ordinary resolves do not count. These numbers
measure install intent, not successful artifact installation or npm downloads.
The worker requires Cloudflare's CF-Connecting-IP header to count a report.
It stores the plugin ID plus a SHA-256 hash of the IP in a WEBSITE_CACHE KV key
with a one hour TTL, never the raw IP. An existing key skips the count; repeats
do not extend the hour. Missing or empty IP headers do not count.
Accepted reports increment the existing all-time total and UTC daily buckets in
WEBSITE_CACHE. Daily buckets retain 60 days and supply the website's seven-day
and thirty-day rankings. /api/plugins/installs still returns plugin IDs mapped
to all-time totals. The registry build
reads that endpoint into the published plugin details and index; the website
reads windowed counts from KV through its five-minute cache. Existing counts
remain intact. The KV guard is advisory: concurrent requests and KV propagation
are not serialized.