Google rejected the first submission ("Violation of Play Console
Requirements" — apps in the "Health apps" category require an
organization account). The likely cause: this draft recommended
declaring pet weight/vet-visit/vaccination data under Data Safety's
"Health and fitness" category "as a precaution." That category is for
data about the person using the app, not their pet, and apparently
triggered Google's automated Health-app classification.
Reversed the recommendation (don't declare it there) and added a
section on checking the Play Store app category is "Social", not a
health/medical category — the rejection email names both as possible
causes.
Confirmed 2026-09-07 while deploying the Child Safety Standards page:
/Dockers/PawFeed on the NAS is its own git checkout tracking the
self-hosted Gitea remote, kept up to date via git pull rather than the
manual FTP upload this file previously described. Documents the actual
deploy steps (ssh daniel@192.168.1.222 on the standard port, git pull,
then rolling-deploy.sh) so this doesn't need rediscovering next time.
New public page at /kinderschutz — required by Google Play's Child
Safety Standards policy for apps with user-generated content/social
features (https://support.google.com/googleplay/android-developer/answer/14747720).
Registered as public + maintenance-exempt in proxy.ts, matching the
existing /impressum, /datenschutz, /nutzungsbedingungen pattern.
Content covers only mechanisms that actually exist in this codebase:
in-app reporting (ReportSheet + admin moderation review), a named
responsible contact (same identity as /impressum), and the German/EU
legal framework (StGB §184b/c, DSA, JuSchG) for law-enforcement
cooperation on confirmed CSAE content — no invented automated-
detection claims.
Cross-linked from the other legal pages' footers, the web /pets
footer, and the mobile app's My Pets legal-links section (new
pets.legalChildSafety i18n key, DE/EN).
feature-graphic-1024x500.png — exact 1024x500, 24-bit PNG (no alpha,
per Play Console's spec), brand-matching gradient with the paw glyph
and wordmark.
beschreibung.md — short + full store listing description drafts based
on actual app features (posts, stories, milestones, health tracking
with consent, messaging, species/breed discovery, spider-hiding
preference), ready to paste into Play Console.
store-assets/play-store-icon-512.png — dedicated 512x512 RGBA copy of
the (now-fixed) app icon for the Play Console listing upload.
store-assets/play-console-data-safety.md — Data Safety form draft
based on an actual read of mobile/package.json's dependencies and the
relevant hooks/routers (push token flow, health-consent module), not
guessed: no payment/location/analytics SDK present in the mobile app,
account deletion exists but only via the web app (documented with the
URL Play Console needs).
Icon fix: android-icon-foreground/monochrome.png (and icon.png/
favicon.png/splash-icon.png) were the wide website wordmark logo
(paw + "PawFeed" text), with the actual paw glyph confined to a tiny
78x79px region on the far left of a 512x512 canvas. Android's adaptive
icon system only renders the center ~66% safe zone, so almost none of
the design was ever visible — explaining the "nearly all black" home
screen icon. Isolated the paw glyph via its orange pixel bounding box
and re-centered it properly on each target canvas (transparent for
foreground/monochrome/splash, solid background for icon.png/favicon).
monochrome.png is now a true white-alpha silhouette (Android's spec)
instead of sharp's tint() output, which produced gray instead of white.
Also removed android-icon-background.png — it was the same oversized
wordmark logo, redundant with (and overriding) the adaptiveIcon
backgroundColor that was already set to the same color.
Splash screen: expo-splash-screen was never installed despite
splash-icon.png existing in assets/ — app had no splash config at all,
which explains the light-gray placeholder/broken-image glyph seen on
launch (a generic fallback, not this app's own asset). Installed and
configured with the corrected splash-icon.png.
Play Store prep: added android.versionCode (required once
appVersionSource is "local" and unset until now) and made the
production build profile explicit about android.buildType: app-bundle
(required for Play Store; "preview" stays APK for direct install).
Messages (conversation list + chat detail) used the static (light-only)
color tokens instead of useTheme() — same bug class as the earlier
auth-screen/comments/RepostCard fixes this session.
Also fixed: the comment and chat input rows sat flush against the
bottom edge with a flat 12px padding, no bottom safe-area inset. On
devices with Android's gesture nav bar this put the send button right
where the system back/home gesture also listens, making it error-prone
to tap ("in einem Schutzbereich sehr schwer anklickbar"). Both input
rows now pad by max(12, insets.bottom) instead of a flat 12px.
Build #4 failed at the expo doctor pre-build check EAS runs, with two
real issues:
- app.json's newArchEnabled key is no longer a valid Expo config field
in SDK 57 (New Architecture is the only architecture now, so the
opt-in toggle was removed) — the schema validator rejected it as an
unknown property.
- expo-router was pinned to 5.1.11, an old-style version number
predating Expo's SDK-aligned versioning — way behind the ~57.0.19
expected for this SDK. expo-linking/expo-secure-store were a patch
version behind too. Fixed via `npx expo install --fix` rather than
guessing version numbers.
The expo-router bump changed tabBarIcon's expected color prop type
from `string` to RN's `ColorValue`; updated NotificationsTabIcon's
signature to match.
`npx expo-doctor` now reports 18/18 checks passed.
FeedScreen's feedItems useMemo (interleaveTrending) sat after the
loading/error early returns instead of before them, violating the
Rules of Hooks: the loading-state render calls fewer hooks than the
loaded-state render, so React throws "Rendered fewer hooks than
expected" the moment the feed finishes loading — crashing the app on
every real device right after login. Moved the useMemo (and the plain
posts/trendingPosts derivations it depends on) above both early
returns so every render calls the same hooks in the same order.
Also add graphify-out to the root .easignore.
Sign-in/sign-up and RepostCard used the static (light-only) color
tokens instead of useTheme() — in dark mode the login screen kept a
light background with light-theme-colored text baked in, and
RepostCard's text color was hardcoded independent of its (already
theme-aware) surrounding background, both landing on illegible
low-contrast text. Same bug class as earlier dark-mode fixes this
session, converted the same way (useTheme() + makeStyles(colors)).
Also add a root-level .easignore (EAS Build's archive root may resolve
above mobile/ for monorepo purposes) excluding backend/tooling
directories the mobile app never needs at build or runtime (.claude,
.impeccable, .planning, docker, prisma — the last is only a type-only
dependency via mobile's tRPC router import, erased before Metro
bundles anything).
An untracked local android/ folder (from an earlier expo run:android)
was inflating the build archive to 365MB and, more importantly, was
making EAS Build treat the project as "bare workflow" — building that
stale native folder as-is instead of regenerating it from app.json via
Continuous Native Generation. Deleted the folder locally and excluded
it (plus ios/, node_modules, IDE state) from future archives so a
stray prebuild output can't silently make app.json changes stop taking
effect.
Was gitignored under the assumption it should be redownloaded per
clone, but a cloud EAS build clones from git and won't see a gitignored
file at all — the build would fail without it (app.json's
android.googleServicesFile references this path). Its contents (API
key, app/project IDs) aren't secret: Google restricts access by
package name and SHA fingerprint, not by hiding the file, same as most
public Firebase Android repos.
userInterfaceStyle was hardcoded to "light" in app.json — since the app
resolves its "Automatic" theme option via RN's useColorScheme(), which
Expo only wires up to the OS when userInterfaceStyle is "automatic",
the auto setting would have silently never followed the system theme
in a real native build (only worked in the dev client, which isn't
gated by this app.json field the same way).
Also pin the preview/production EAS build profiles' EXPO_PUBLIC_* env
vars explicitly in eas.json. .env is gitignored, so a cloud build has
no guarantee of seeing it (or seeing the right values) — this makes
the native build's API/Clerk/Supabase targets explicit and independent
of whatever's in the local .env at build time. Values are non-secret
(EXPO_PUBLIC_* is always inlined into the client bundle).
Multi-photo posts gave no visual hint they were swipeable — a viewer
would only ever see the first image unless they already knew to swipe.
Adds a "1 / N" counter badge (top-right overlay) and a dot-page
indicator below the carousel, porting web's PostCard indicators.
Notification taps for post-related types (REACTION/COMMENT/MENTION/
PAW_BACK) landed on a bare "no comments yet" screen with no sign of the
actual post. The comments screen now fetches the post via the existing
posts.getById and shows it (image/caption/header) via the shared
PostCard above the comment list.
The actor's name in each notification row is now its own tappable text
run that links to their profile, separate from tapping the rest of the
row (which still opens the notification's target) — ported from web's
notifications page, which does the same split between a Link and plain
text.
Also fixed: the comments screen used the static (light-only) color
tokens throughout, so embedding the theme-aware PostCard produced
near-invisible light text on its own light background in dark mode.
Converted the screen to useTheme() like the rest of the dark-mode-
converted screens.
Notifications: add a visible hairline separator between rows and make
each row tappable — it marks read and navigates to the relevant post
(comments screen) or pet profile, porting web's getHref()/getPostId()
routing logic.
Feed: the "..." menu on a post now opens a delete confirmation instead
of the report sheet when the post belongs to the currently active pet;
report sheet stays unchanged for posts from other pets. Reuses the
pre-existing posts.delete mutation, no backend changes needed.
- explore.getTrending posts are now interleaved into the chronological
Feed at semi-random intervals (src/lib/interleave-trending.ts),
marked with a small "Trending" badge on PostCard — a lightweight
stand-in for web's separate Explore "Trending" tab, which mobile
wasn't going to get as its own screen. No backend change: reuses the
existing explore.getTrending procedure as-is.
- update app icon / splash / favicon / Android adaptive-icon assets
(user-provided)
- README: correct the now-stale Dark Mode "not yet converted" list
(Explore/Notifications/pet profile/health were converted in the
found.md batch) and document the report/date-format/pinch-zoom/
legal-links fixes
- new report feature: a "..." button on every post opens a reason-picker
sheet (reports.create), matching web's ReportSheet reasons/copy
- pet profile, edit, followers/following, and the whole health screen
(incl. consent gate) converted to the makeStyles(colors) dark-mode
pattern
- fixed the invisible back button on every pushed (app)/_layout.tsx
screen: headerTintColor was never set, so the native-stack default
back chevron kept its platform tint instead of the theme color —
black-on-black in dark mode looked like a missing button entirely
- health forms (weight/vet visit/vaccine) now take dates as DD-MM-YYYY
instead of the backend's raw YYYY-MM-DD, converting internally
(src/lib/date-format.ts); invalid dates now show an error instead of
the mutation silently failing with no onError handler at all — this,
not persistence, was the actual "Gesundheitsdaten werden nicht
gespeichert" bug
- pinch-to-zoom on the full-screen image viewer via a plain
PanResponder (no new native dependency)
- Pets tab: language switcher now uses flag emoji (🇩🇪/🇬🇧/🌐), and a
new footer section links Impressum/Datenschutz/Nutzungsbedingungen
plus the installed app version
All live-verified against the deployed backend except pinch-zoom
(two-finger gestures aren't simulatable over adb).
- i18next + react-i18next + expo-localization: device-locale detection,
an MMKV-persisted DE/EN/Automatisch override (mirrors web's cookie-only
locale, no backend field needed), and a language switcher on the Pets
tab next to the theme toggle
- every screen and shared component converted from hardcoded German
strings to translation keys; de.json/en.json kept in exact key-parity
(218 keys each, verified programmatically)
- backend: src/trpc/init.ts now accepts an x-locale header as a fallback
locale source (cookie still wins, web unaffected) since mobile has no
cookie jar to set NEXT_LOCALE in; mobile's tRPC client sends the
current language on every request
- fixes a latent bug: species/breed pickers were hardcoded to locale
"de" while every other pet query resolved names via ctx.locale's
default (English, since mobile never sent a locale cookie) — both now
use the same current-language value
- expo-localization is a new native module (config plugin) and needs a
native rebuild to actually link; deviceLocale() falls back to English
instead of crashing when it isn't linked yet, so the app stays usable
before that rebuild happens
Needs a NAS deploy (src/trpc/init.ts is shared backend code) before the
x-locale fallback and the species/breed locale fix take effect for mobile.
- Explore and Notifications tabs now read colors from ThemeContext
instead of the static light-only tokens
- OptionPicker's option list is position:absolute so it overlays
following content instead of pushing it down, with zIndex on the
component root (and FlatList's ListHeaderComponentStyle on Explore)
so it actually paints above sibling content instead of underneath it
- check off found.md's resolved items, record the three newly reported ones
- 5-step onboarding (guidelines, upload consent, spider opt-in, pet
creation, avatar) that gates first launch until a pet exists
- Add/delete pet flows on the Pets tab, with a shared OptionPicker
(ScrollView-based, not FlatList, to avoid nested-VirtualizedList
warnings inside onboarding's outer ScrollView)
- App-wide light/dark/auto theme via ThemeContext, synced with the
existing owner.getThemePreference/setThemePreference backend
procedures; core navigation chrome, Feed, Pets tab, and shared
primitives (Button, TextField, Card, PetAvatar, PostCard, StoryTray)
converted to the makeStyles(colors) pattern
- found.md fixes: safe-area insets on image/story viewers so controls
clear the status bar, auto-mark-all-read on the notifications tab,
and an Explore species/breed filter
sign-in.tsx only ever covered login (per its own comment "sign-up screens
are follow-up work"). Adds the other half: email/password sign-up using
Clerk's Futures API (signUp.password() -> verifications.sendEmailCode()/
verifyEmailCode() -> finalize()), mirroring sign-in.tsx's two-step
credentials/verify shape. No invite-code step, since INVITE_REQUIRED is
globally off on the backend since launch.
Verified live on the Android emulator: real Clerk validation surfaces
correctly (breached-password rejection), and a valid submission correctly
sends a verification email and transitions to the code-entry step.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Push notifications went from "wired but not deliverable" to fully working
end-to-end this session. Records the three separate one-time setup pieces
(EAS project id, FCM credentials baked at prebuild time, and the FCM V1
vs. Legacy service-account-key slot mixup that produced a confusing
"Unable to retrieve the FCM server key" error) so a future session doesn't
have to rediscover them.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Minimal EAS Build config (development/preview/production profiles) —
needed by `eas credentials` to manage the FCM push key, no EAS Build
runs yet. Push notifications are now fully verified end-to-end: real
device token minted, registered with the backend, and a live push
delivered to the Android emulator's notification tray.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Next.js's production build type-checks the whole repo by tsconfig.json's
default include glob, which picked up mobile/'s .tsx files once the
Docker image's git checkout finally included mobile/ (first pull to
include it) — none of mobile's own dependencies (react-native, expo-router,
...) are installed in that container, so the build failed outright.
mobile/ is now excluded from tsconfig.json and .dockerignore; it's a
separate app with its own tsconfig/package.json and was never meant to be
type-checked or shipped as part of the web image.
Also completes the mobile EAS/FCM push setup (app.json's extra.eas.projectId
and googleServicesFile, google-services.json gitignored) and adds a 15s
timeout around getExpoPushTokenAsync so a device that can't reach FCM fails
visibly instead of hanging silently forever.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Health: consent gate (Art. 9 DSGVO) plus weight/vet-visit/vaccine log
sections, gated behind health.getConsentStatus like the web app.
Milestones: view a pet's milestone posts and create the 5 user-initiated
types with an optional photo. Messaging: chat detail/compose screen
(messages/[conversationId].tsx) polling while focused, reachable from the
conversations list and from a pet profile's new "Nachricht" entry point.
Push: usePushNotifications requests permission and registers the Expo
push token with owner.registerPushToken; real delivery still needs an EAS
project id (`eas init`), tracked in the README.
All four verified live on a real Android emulator: health CRUD (add/list/
delete a weight log), Health/Milestones/Nachricht entry points gated
correctly by own-pet vs. other-pet, and full chat history loading via an
existing conversation.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Owner.expoPushToken + owner.registerPushToken/clearPushToken, plus a
best-effort Expo push send wired into notify() alongside the existing
in-app Notification row. Missing/expired token or unreachable Expo push
service silently no-ops — push delivery must never break the underlying
action it's attached to.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Story tray/creation/viewer with PawRing seen/unseen indicator, expo-video
playback for VIDEO posts (replacing the static placeholder), and a
pets/people/hashtags search screen reachable from the Explore tab header.
Extracts FollowButton from the pet-profile screen since search results
need the same follow/unfollow toggle.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
PawBackButton toggles reposts.create/delete with an isReposted-backed
optimistic state, mirroring web's PawBackButton — replaces the static
repost count in PostCard's action row. RepostCard renders a REPOST
post as a read-only "Paw-Back von {name}" attribution wrapper around
the original post's pet header, image, and caption, ported from web's
RepostCard with no action row (matches web: only the original post is
reactable/commentable).
Post creation: gallery/camera picker (expo-image-picker) uploads each
image straight to Supabase Storage via a presigned PUT
(posts.getPresignedUrl + expo-file-system), then posts.create with the
resulting storage keys — reachable via a new "+" header button on the
Feed tab. No client-side blurhash (browser Canvas API, no RN
equivalent) or AI-disclosure/mention support yet, matching the rest of
mobile's plain-text captions.
Comments: a dedicated screen (posts/[postId]/comments) for reading,
posting, and deleting one's own comments, reachable by tapping the
comment icon on a PostCard. Ported from web's PostDetailDialog comment
panel, scoped down to just that panel since mobile's image full-view
already has its own route.
Header now shows the PawFeed paw+text logo on the Feed tab (matching
web's Sidebar wordmark). Tapping a post image opens a full-screen
viewer as a route-based fullScreenModal, with a blurred edge-to-edge
copy of the same photo behind the sharp foreground image instead of a
flat black backdrop, for a more dynamic Photos-app-style lightbox.
Fixes from user testing on a real device:
- Feed: replaced an invisible spacing-only separator with an actual
hairline divider between posts.
- Android launcher icon showed Expo's default placeholder (a blue arrow)
because the app icon and the Android adaptive-icon layers
(foreground/background/monochrome) are two separate asset sets — only
icon.png/favicon.png had been replaced. Added scripts/derive-adaptive-
icon.js to crop the paw glyph out of icon.png (detected by its marigold
color) and generate all three adaptive-icon layers plus the splash icon;
this is an explicit placeholder per user's own call, not final art.
New: full pet profile (app/(app)/pets/[petId]/), matching web's
src/app/(app)/pets/[petId]/page.tsx:
- View: identity, species, bio/adoption story, follower/following counts
(tappable → list screens), the pet's own posts below.
- Follow/unfollow with real initial state (follows.isFollowing) and
optimistic toggle — unlike feed reactions, this endpoint actually
exists, so no need to fake an initial state.
- Edit screen (name/nickname/bio/adoption story via pets.update) for the
owner's own pets.
- Tapping a pet (feed header, Explore card, Pets-tab row) now opens this
profile instead of nowhere; the Pets tab's active-pet switch is now a
separate checkmark control instead of overloading the whole row tap.
PostCard's post-shape prop is now structural rather than tied to
feed.getFeed's output type, since posts.byPetId selects `pet` via the
narrower petIdentitySelect (no isVerified/owner) — both need to satisfy
the same component.
Verified end-to-end on-device: feed separator visible, own-pet profile
shows a working Bearbeiten button whose form is correctly prefilled (a
stray edit was made to Bianca's nickname field by mistake during testing
and was discarded via back-navigation without saving — never sent to the
server), someone else's pet profile shows a working Follow/Unfollow
toggle, followers list navigates correctly, and the home-screen launcher
icon now shows the paw instead of the default Expo icon.
Moves the mobile app from a connectivity scaffold to a real Phase 1 app:
- Migrate off Expo Go onto a local custom dev client (expo-dev-client,
built via expo prebuild + expo run:android against the local Android
SDK — no EAS account needed). Needed because react-native-mmkv requires
native code Expo Go doesn't ship.
- Persisted, MMKV-backed TanStack Query cache (PersistQueryClientProvider)
plus expo-image, so a relaunch renders the last-known feed/pets/
notifications instantly instead of a blank screen while refetching.
- ActivePetContext: every pet-scoped procedure requires an explicit petId
server-side (no server-side "current pet"), ported from web's
ActivePetContext, MMKV-backed instead of localStorage.
- Bottom Tabs (Feed/Explore/Notifications/Pets) mirroring the web app's
actual mobile nav, with Messages as a header button rather than a tab
(matches web). Feed, PostCard, PawButton reactions, pet discovery grid,
notifications list, and a conversations list are all wired to the real
backend and verified against the live database.
- Design tokens/components extended with PostCard/PawButton/PetAvatar/
PetIdentityBadges, all styled from the existing src/theme/tokens.ts.
- Fixed a react/react-dom version mismatch surfaced along the way, and
handle Clerk's needs_client_trust (Device Trust) sign-in status with an
email-code step.
Verified end-to-end in the Android emulator against pawfeed.org: feed
scrolls and paginates with real posts/images, paw reactions toggle
optimistically and persist, pet switching updates every screen, and
notifications/explore show live data.
- Add design tokens (colors, radii, typography) mirroring DESIGN.md's
"Spotlight Porch" system, plus Button/TextField/Card components built
on them. Restyle the sign-in and placeholder home screens to match.
- Load Inter via @expo-google-fonts/inter, gate rendering on fonts +
Clerk being ready instead of a blank screen.
- Pin react-dom to match react's version — Metro/Hermes hard-require
exact equality, and react-dom wasn't pinned anywhere before.
- Handle Clerk's `needs_client_trust` status (Device Trust, tied to the
dashboard's Native Applications API): send/verify an email code
before finalizing sign-in.
Verified end-to-end in the Android emulator against the live backend:
sign-in, device-trust code verification, and the home screen showing
real stats.getPublicStats data.
Connectivity + auth scaffold only: Expo Router, Clerk session auth via
expo-secure-store, and a type-only tRPC AppRouter import from the web
app's router — no backend changes needed. See mobile/README.md.
The admin panel (src/app/p/[secret]/layout.tsx) never wrapped its tree
in ClerkThemeProvider, unlike (app)/layout.tsx — a SpeedUp-Plan P0
optimization that deliberately kept Clerk's client bundle off routes
without a <UserButton/>. Consequence: no client-side session-token
refresh ran on admin pages. The initial page load stayed authenticated
(Clerk's server-side handshake reissues the token on full document
navigations), but subsequent tRPC XHRs — e.g. legal.publish — started
failing with UNAUTHORIZED/401 a few minutes in, since that handshake
only fires for navigations, not fetch calls. Confirmed live: a fresh
page reload always restored a working session, matching this exactly.
Mounting ClerkThemeProvider in the admin layout re-adds background
token refresh. Also gives the legal-publish error handler an
actionable message for UNAUTHORIZED specifically (distinct from other
failures), since a residual case can still occur after a real 7-day
session expiry.
Add a per-pet consent gate (Art. 9 Abs. 2 lit. a DSGVO) in front of the
whole Health-Tracking area (weight, vet visits, vaccines, emergency
vet, feeding, Health Card): an un-pre-checked checkbox must be
confirmed before any of it is used, enforced server-side in
health.ts (not just the UI) via a new assertHealthConsent check on
every data-bearing endpoint.
Revoking consent (health.revokeConsent) deletes every health record
for that pet in one transaction and is available at any time from the
Health page. Pet gains healthConsentGivenAt/healthConsentRevokedAt
(nullable, additive — db push already applied against the shared
Supabase instance).
Extends the Datenschutzerklärung (Abschnitt 3) with the Art. 9 legal
basis and the revoke/auto-delete mechanism, per counsel's follow-up.
Narrow the Art. 4 No. 1 GDPR non-personal-data claim to data that
permits no inference about the owner as a natural person, and call
out the case where it can (e.g. pet photos alongside a profile
picture) as personal data after all.
- clarify pet-only data (breed, weight, health records) is not
personal data under Art. 4 No. 1 GDPR since GDPR protects only
natural persons; still handled confidentially per policy
- switch Clerk/Cloudflare/Mux/Stripe from SCC framing to EU-U.S. DPF
certification (Art. 45 adequacy decision), strengthen the residual
SCC/Schrems-II fallback clause beyond TLS + access restrictions
- document 30-day retention and rationale for technical error reports
Verified live that adding Clerk's frontend API host to script-src does
NOT resolve the CSP violation in modern browsers: with 'strict-dynamic'
present, CSP3 ignores host-based entries in that directive entirely
(Chrome's own violation message confirms this). The console noise is a
Clerk SDK-side loading quirk, not something fixable here without
dropping 'strict-dynamic'. Keeping the host entry only as the same
spec-mandated pre-CSP3 fallback the existing 'unsafe-inline' entry
already relies on, with the comment corrected to say so.
Clerk's clerkMiddleware auto-adds its frontend API host to connect-src
but not script-src, so the initial (unversioned) clerk.browser.js/
ui.browser.js load was blocked by strict-dynamic before the 307 redirect
to the versioned URL — two CSP violations reported to /api/csp-report on
every page that renders Clerk UI, dragging the Best Practices Lighthouse
score down. Derives the host from the publishable key (same approach as
the existing Supabase/GlitchTip hostname helpers) instead of hardcoding it.
- README: note @clerk/localizations' deDE usage in the tech stack table
and shipped-features list.
- ClerkThemeProvider: comment explaining why deDE is needed (Clerk's own
UI defaults to English regardless of the app's next-intl locale).
- mobil.md: mark the Capacitor plan superseded by the React Native/Expo
scaffold decided this session (see mobile/README.md).
The sign-in/sign-up UI rendered in English despite the rest of the app
being German — @clerk/localizations ships an official deDE locale that
plugs directly into ClerkProvider's existing appearance config.
README: document today's shipped work (story reactions/comments, per-pet
insights dashboard, DESIGN.md/PRODUCT.md design system, admin panel visual
pass) in "What's Shipped" and the admin panel section.
docker/rolling-deploy.sh and start.sh were tracked as 100644 (no executable
bit) since this repo is worked from Windows, which never records it — every
fresh git pull onto the Linux NAS made them non-executable again. Fixed via
git update-index --chmod=+x so this doesn't recur.
The post-card action row (comments, hide/unhide, pin/unpin, AI-disclosure
correction, delete) had no explanation of what each icon does — add a help
popover next to the "Posts" heading listing icon + action name.
admin
