10 Commits

Author SHA1 Message Date
chahinebrini
44a3348845 feat(community): Domain-Approval-Lyra-Posts multi-locale (de/en/fr/ar)
Bug: User mit FR-locale sahen Lyra-Confirmation-Posts trotzdem auf Deutsch
(Banner/Tabs richtig FR). Root: approve.post.ts generierte den Text via
Groq mit hartcodiertem 'auf Deutsch'-Prompt, speicherte als plain content.

Server (approve.post.ts):
- 4 parallele Groq-Calls (Promise.allSettled) — de + en + fr + ar
- Per-Locale-PROMPT_CFG mit subject/action/statsLine/thanksSegment-Texten
- Locale-aware Number-Format (toLocaleString('de-DE'|'en-US'|'fr-FR'|'ar-EG'))
- Content als JSON {de:'...',en:'...',fr:'...',ar:'...'} gespeichert
- Mindestens DE muss gelingen, sonst kein Post (Sicherheit gegen halbe Posts)
- ~4x Groq-cost pro Post (sehr günstig bei Llama-3.3-70b, parallel-latency
  bleibt ähnlich)

Frontend (PostCard.tsx):
- resolveLocalizedJsonContent() — try-parsed JSON content
- Wenn JSON-Object mit Locale-Keys → pickt i18n.language, fällt auf DE → EN
- Sonst plain content (Legacy-Posts, Comments, User-Posts unverändert)
- Quick-Reject auf '{' first-char vermeidet JSON.parse-Overhead für 99.9%
  der Text-Posts

Legacy-Posts in DB bleiben DE-only (kein retroaktiver Multi-Locale-Rewrite).
Neue Posts ab Deploy haben alle 4 Sprachen.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
2026-05-18 00:29:02 +02:00
chahinebrini
2e409efaf0 feat(onboarding/android + backend/lyra-i18n): platform-dispatch + post-catalog scaffold
Android-Onboarding (Platform.OS dispatch in ProtectionSlide):
- Neue Phasen für Android: preexplain_vpn → preexplain_a11y → a11y_pending
- AppState-Listener: nach Settings-Rückkehr auto-poll isAccessibilityEnabled
  → wenn live, armTamperLock + finish (kein Fokus-Klick nötig)
- onboardingAssets: 8 neue Mappings (android_vpn + android_a11y × 4 Locales)
- Screenshots: vpn-permission + a11y-rebreak-row pro Locale
- Locale-Keys: protection_url_android, protection_lock_android, cta_open_a11y,
  cta_check_a11y, dialog_button_vpn_ok, dialog_button_a11y_toggle, tap_marker_hint_*

Lyra-Post i18n Phase 1 (Scaffold, feature-flag OFF by default):
- schema.prisma: CommunityPost.i18nKey String? (nullable)
- migration 20260517_add_lyra_post_i18n_key: ALTER TABLE ADD COLUMN i18n_key
  (NICHT auto-deployed — `prisma migrate deploy` als separater Step)
- server/lib/lyraPostCatalog.ts: 15 Templates skelettiert + pickRandomTemplate
- cron/lyra-post: USE_TEMPLATE_CATALOG=true Branch → speichert i18nKey;
  default false → LLM-Path unverändert (zero-risk-deployment)
- community.createPost: optionaler i18nKey-Parameter
- posts.get: i18nKey in API-Response
- PostCard: 3-Zeilen-Branch — i18nKey ? t('lyra_posts.'+id) : content
- stores/community: i18nKey?: string|null im Interface
- de.json: lyra_posts-Block mit 15 IDs + DE-Texten

Single-Banner-Verhalten auf Android verifiziert:
lockedIn=urlFilter && appDeletionLock funktioniert weiter — auf Android
alias appDeletionLock ← tamperLock; onboarding arms tamperLock, also
nach onboarding-done direkt ProtectionLockedCard sichtbar.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
2026-05-17 23:48:25 +02:00
chahinebrini
500f673e53 fix(native/community): sync foreign likes_count into PostCard.localCount
Pure additive change — wasLikingRef + a small useEffect right after the
existing useState declarations. handleLike, the heart animation, localLike,
the memo comparator, and the render path are not touched.

Mechanism:
  - useCommunityRealtime already patches the React-Query cache on UPDATE
    events for rebreak.community_posts (the table IS in supabase_realtime
    — verified via pg_publication_tables on staging today).
  - The cache patch propagates to PostCard as a new post.likesCount prop.
  - The useState seed (post.likesCount on mount) was never re-read after
    the first render — the source of the bug.
  - The new useEffect mirrors post.likesCount into localCount with one
    guard: when isLiking transitions from true → false, skip the first
    run. The cache patch from our own action arrives ~100–300ms after
    the API response settles, so on the immediate run the prop is still
    stale; skipping prevents an overwrite of the value handleLike just
    set. The next prop change (cache patch arrival) re-fires the effect
    and syncs correctly.
  - Pure foreign likes (no own action in flight) sync immediately.

Earlier attempts (4c4792c, d28d1f1) tried to refactor wider — both broke
own-likes / comments / animations. This commit deliberately changes only
the new code paths.
2026-05-16 01:08:14 +02:00
chahinebrini
7c6b463acb Revert "fix(native/community): derive heart state from props + store-optimistic delta"
This reverts commit d28d1f145d9bdaa45fb788aaef69c645719f56bb.
2026-05-16 00:48:14 +02:00
chahinebrini
d28d1f145d fix(native/community): derive heart state from props + store-optimistic delta
Replaces the previous mirrored localCount / localLike useState with derived
values computed from `post.likesCount` / `post.userLike` plus the existing
optimisticLikes entry from the community store. The local-state mirror was
the root cause of two separate bugs:

1. Foreign likes never reflected — useState seeded once from props on mount,
   so the React-Query cache patch in useCommunityRealtime updated the prop
   but the displayed count stayed frozen at the mount value.
2. The earlier sync-via-useEffect attempt (4c4792c, reverted in ab9472b)
   broke own-likes because clearing optimistic state could happen before
   the cache patch landed, so useEffect re-read a stale `post.likesCount`
   and snapped the count back down — visible as a 2 → 1 → 2 flicker on tap,
   and as the heart staying red after a toggle-off.

The fix is to NOT mirror at all. The store's `optimisticLikes` map already
stores `{ delta, userLike }` per post (it was set but never read before).
Render path now:
  displayedLike  = optimistic?.userLike  ?? (post.userLike === 'like' ? 'like' : null)
  displayedCount = (post.likesCount ?? 0) + (optimistic?.delta ?? 0)

In handleLike, after the API responds, the React-Query cache is patched
synchronously with the server-truth response before clearOptimisticLike
runs — so the moment the delta drops to 0, the prop already reflects the
new count. No race window, no useEffect, no own/foreign distinction needed.

`isLiking` is still kept as a re-tap guard against double-tap-mid-flight.
2026-05-16 00:40:46 +02:00
chahinebrini
ab9472b976 Revert "fix(native/community): sync realtime-patched likes_count back into PostCard"
This reverts commit 4c4792c153aa6949fc656ed570c0c147ba33ec87.
2026-05-16 00:35:21 +02:00
chahinebrini
4c4792c153 fix(native/community): sync realtime-patched likes_count back into PostCard
`useCommunityRealtime` was already patching the React-Query cache
on community_posts UPDATE events — likesCount, dislikesCount, userLike
all reached the component as props on re-render. But PostCard was
seeding `localLike` / `localCount` once via useState initial values
and never re-reading the props after mount, so a like from another
account showed up as a notification but the heart counter stayed
stale until pull-to-refresh.

Added a useEffect that mirrors `post.likesCount` / `post.userLike`
back into local state, guarded by `isLiking` so an in-flight
optimistic update isn't clobbered by a concurrent realtime patch
of the same row.

Handles unlike (decrement) on the same path, plus off-screen posts
which get the patched cache value on remount and feed-list cards
that refresh in place without scroll.
2026-05-16 00:25:38 +02:00
chahinebrini
14452b2a46 refactor(native): Pressable → TouchableOpacity sweep (style-fn swallows Android styles)
Alle <Pressable style={({pressed}) => ({...})}> ersetzt — style-Funktion
droppt auf Android (New Arch) intermittierend width/height, führt zu 0×0
unsichtbaren Elementen. TouchableOpacity mit activeOpacity ist stabil.

Außerdem übrige Pressables (plain style) aus components/ und app/
migriert sowie zwei überschüssige </View>-Tags in chat.tsx + RoomCard.tsx
entfernt die TS-Fehler verursacht haben.

64 Dateien, typecheck sauber.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
2026-05-11 15:43:10 +02:00
chahinebrini
d7b15e231a feat(theme): Dark Mode Wave 2 — blocker, mail, chat, community, notifications, all remaining screens
Wave 2 = ALLE app-files die in Wave 1 noch hardcoded waren. Komplette App-weit
theme-aware-Migration jetzt durch. Legacy `import { colors }` flat export
vollständig eliminiert.

Migrated this wave:

Top-level Screens:
- app/urge.tsx (makeStyles factory mit ~20 colors)
- app/room.tsx + dm.tsx + games.tsx
- app/(app)/chat.tsx + mail.tsx + coach.tsx + notifications.tsx
- app/profile/[userId].tsx + profile/edit.tsx (INPUT_STYLE in body moved)
- app/debug.tsx + auth/callback.tsx

Blocker (7):
- AddDomainSheet, CooldownBanner, DeactivationExplainerSheet, DomainGrid,
  ProtectionCard, ProtectionDetailsSheet, ProtectionLockedCard

Mail (3):
- ConnectMailSheet, EditMailAccountSheet, MailEmptyState

Chat (1):
- ChatBubble, ChatInput

Community/Posts/Notifications:
- PostCard, PostCardSkeleton, ComposeCard, PostCommentsSheet
- NotificationsDropdown
- StreakBadge (Nativewind classes durch inline dynamic styles ersetzt)

Reusable Sheets:
- WheelPickerModal, OptionsBottomSheet, DeviceLimitReachedSheet

Urge subsystem (5):
- InlineRatingDrawer, ShareSuccessDrawer, UrgeStats, SosFeedbackModal,
  Breathing

Profile components:
- DigaMissionBanner

Pattern: useColors() hook in component body, makeStyles(colors) factory wo
StyleSheet.create vorher hardcoded war. 11 base-tokens (bg/surface/
surfaceElevated/border/text/textMuted/brandOrange/brandBlue/success/error/
warning) nutzen colors.light vs colors.dark scheme.

Bewusst NICHT migriert (semantic colors):
- DigaMissionBanner amber (#fffbeb, #854d0e) — DiGA-brand, nicht neutral
- Lyra-thinking #3b82f6 in urge.tsx — Lyra-brand-color
- scrollDownBtn #374151 — intentional dark floating-button

TS clean. Test: Settings → Theme → Dark — alle screens sollen jetzt dunkel
werden ohne white-flashes.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-09 14:51:02 +02:00
RaynisDev
b58588cf3c initial commit: rebreak-monorepo (RN app + standalone Nitro backend) 2026-05-06 07:13:43 +02:00