Merge remote-tracking branch 'origin/master' into merge-first3-master

# Conflicts:
#	.github/actions/eas-build/action.yml
#	.github/actions/setup-node-pnpm-install/action.yml
#	.github/workflows/eas-build-qa.yml
#	.github/workflows/new-app-version.yml
#	.vscode/settings.json
#	__tests__/components/ui/button.test.tsx
#	__tests__/components/ui/checkbox.test.tsx
#	__tests__/components/ui/input.test.tsx
#	__tests__/components/ui/select.test.tsx
#	env.js
#	eslint.config.mjs
#	jest-setup.ts
#	lint-staged.config.js
#	package.json
#	pnpm-lock.yaml
#	src/api/common/client.tsx
#	src/api/common/utils.tsx
#	src/api/posts/use-add-post.ts
#	src/api/posts/use-post.ts
#	src/api/posts/use-posts.ts
#	src/app/(app)/_layout.tsx
#	src/app/(app)/index.tsx
#	src/app/(app)/settings.tsx
#	src/app/_layout.tsx
#	src/app/feed/[id].tsx
#	src/app/feed/add-post.tsx
#	src/app/login.tsx
#	src/app/onboarding.tsx
#	src/components/buttons.tsx
#	src/components/card.tsx
#	src/components/colors.tsx
#	src/components/cover.tsx
#	src/components/inputs.tsx
#	src/components/login-form.test.tsx
#	src/components/login-form.tsx
#	src/components/settings/item.tsx
#	src/components/settings/items-container.tsx
#	src/components/settings/language-item.tsx
#	src/components/settings/theme-item.tsx
#	src/components/title.tsx
#	src/components/typography.tsx
#	src/components/ui/button.tsx
#	src/components/ui/checkbox.tsx
#	src/components/ui/focus-aware-status-bar.tsx
#	src/components/ui/icons/arrow-right.tsx
#	src/components/ui/icons/caret-down.tsx
#	src/components/ui/icons/feed.tsx
#	src/components/ui/icons/github.tsx
#	src/components/ui/icons/language.tsx
#	src/components/ui/icons/rate.tsx
#	src/components/ui/icons/settings.tsx
#	src/components/ui/icons/share.tsx
#	src/components/ui/icons/style.tsx
#	src/components/ui/icons/support.tsx
#	src/components/ui/icons/website.tsx
#	src/components/ui/image.tsx
#	src/components/ui/input.tsx
#	src/components/ui/list.tsx
#	src/components/ui/modal-keyboard-aware-scroll-view.tsx
#	src/components/ui/modal.tsx
#	src/components/ui/progress-bar.tsx
#	src/components/ui/select.tsx
#	src/components/ui/text.tsx
#	src/components/ui/utils.tsx
#	src/lib/auth/index.tsx
#	src/lib/hooks/use-selected-theme.tsx
#	src/lib/i18n/index.tsx
#	src/lib/i18n/utils.tsx
#	src/lib/test-utils.tsx
#	src/lib/use-theme-config.tsx
#	src/lib/utils.ts

Author: fernandatoledo

.agents/skills/pr-description/SKILL.md

@@ -0,0 +1,83 @@
+---
+name: pr-description
+description: Generates a structured PR description from the current branch diff, following the repository's pull request template exactly. Use when the user asks to "write a PR description", "generate a PR description", "create a pull request description", "update the PR description", "prepare a PR body", "draft a pull request summary", or "write GitHub pull request text" from the current branch changes.
+---
+
+# PR Description
+
+## Purpose
+
+Create a brief, reviewer-friendly PR description from the current branch diff. The output must follow the repository's pull request template exactly, preserving every heading and keeping placeholders where content is unknown.
+
+## Style Rules
+
+- Use plain language. Avoid filler like "this PR aims to", "in order to", and "leverages".
+- Be concrete. Name the screens, components, flows, commands, or files that changed.
+- Keep it short. Each prose section should usually be 1-3 sentences.
+- Avoid bullet soup. If a section needs more than 6 bullets, group related items.
+- Skip obvious filler such as import cleanup or lint-only noise unless that is the point of the PR.
+- Do not invent Jira tickets, screenshots, devices tested, or implementation details not supported by the diff.
+
+## Workflow
+
+1. Read the repository instructions first:
+   - `AGENTS.md`
+   - `REVIEW.md` when present, because this repo requires it for review-related work.
+2. Find the PR template:
+   - Prefer `.github/PULL_REQUEST_TEMPLATE.md`.
+   - Fall back to `PULL_REQUEST_TEMPLATE.md` at the repo root only if the GitHub template is absent.
+3. Refresh and inspect the branch:
+   - Run `git fetch origin master`.
+   - Run `git log origin/master..HEAD --oneline`.
+   - Run `git diff origin/master...HEAD --stat`.
+   - Run `git diff origin/master...HEAD`.
+4. Draft the PR description using the exact headings and order from the template.
+5. Save it as `PR_DESCRIPTION.md` at the repo root, overwriting any existing file.
+6. Ensure `PR_DESCRIPTION.md` is ignored by git. If it is missing from `.gitignore`, append it under:
+
+```gitignore
+# PR description scratchpad (agents)
+PR_DESCRIPTION.md
+```
+
+7. Report back with the relative path only, unless the user asks to see the content.
+
+## Section Guidance For This Repository
+
+The current template is `.github/PULL_REQUEST_TEMPLATE.md`. Keep the warning comment and separators from the template if they are present.
+
+### Jira board reference:
+
+Leave the example placeholder or replace it only if a real Jira ticket is present in the branch name, commits, or user request. Do not invent ticket IDs.
+
+### What does this do?
+
+Write 2-4 concise sentences describing what changed. Focus on user-facing behavior, developer workflow changes, or the concrete problem fixed.
+
+### Why did you do this?
+
+Write 1-3 concise sentences explaining the reason for the change. Tie it to the bug, product need, maintainability concern, or template behavior visible in the diff.
+
+### Who/what does this impact?
+
+Name affected screens, flows, platforms, users, modules, or developer workflows. Use a short sentence or compact bullets. If impact is unclear, leave a placeholder comment instead of guessing.
+
+### How did you test this?
+
+List commands run and manual checks performed. Keep the existing checklist from the template and check only items that are supported by evidence or explicitly provided by the user.
+
+### Notes:
+
+Include caveats, follow-ups, migration notes, or review hints. If there are none, leave the template placeholder.
+
+### Screenshots / Previews
+
+Keep the screenshot/Figma/device placeholders unless real images or recordings are available. Remove irrelevant bug before/after tables only when the template structure still remains clear.
+
+## Final Response
+
+After writing the file, say where it was saved, for example:
+
+`Done: PR_DESCRIPTION.md`
+
+Do not paste the full PR description unless the user asks.

.agents/skills/review-changes/SKILL.md

@@ -0,0 +1,71 @@
+---
+name: review-changes
+description: Reviews the current branch diff against this project's architecture, conventions, and code review checklist. Use when the user asks to "review my changes", "review the diff", "check my code", "run a code review", or "review this branch".
+allowed-tools: Bash(git:*), Read
+---
+
+# Review Changes
+
+## Purpose
+
+Perform a code review of the current branch diff against the project's architecture rules, coding conventions, and the REVIEW.md checklist. Report findings grouped by category, with file and line references where possible.
+
+## Workflow
+
+1. Read the project rules:
+   - `AGENTS.md` — critical constraints and glossary
+   - `REVIEW.md` — the review checklist; this is the primary source of truth for what to flag
+   - `agent_docs/architecture.md` — layer diagram, routing conventions, dual auth system
+   - `agent_docs/conventions.md` — API hooks, styling, forms, i18n, anti-patterns
+
+2. Inspect the branch diff:
+   - Run `git fetch origin master`.
+   - Run `git log origin/master..HEAD --oneline` to understand the commit scope.
+   - Run `git diff origin/master...HEAD --stat` to see which files changed.
+   - Run `git diff origin/master...HEAD` to read the full diff.
+
+3. If a changed file needs more context to review correctly (e.g. to check imports, types, or hook usage), use Read to open it.
+
+4. Review the diff against every category in REVIEW.md:
+   - API & Query layer
+   - Auth & security
+   - Type safety
+   - i18n
+   - Styling
+   - Testing
+   - Performance
+
+5. Also check for violations of the critical constraints in `AGENTS.md`:
+   - Package manager (`pnpm` only)
+   - Env values via `Env` from `@/lib/env`
+   - No auth logic in screen components
+   - No manual camelCase↔snake_case conversion
+   - No direct MMKV access in components
+   - All strings through `useTranslation()`
+   - `createMutation` / `createQuery` from `react-query-kit`
+   - `createQueryKeys` in `src/api/query-factory.ts`
+   - `@shopify/flash-list` for growable lists
+   - `expo-crypto` for random IDs
+   - `react-hook-form` + `zod` for forms
+   - `moti` or `react-native-reanimated` for animations (no `Animated` from RN directly)
+
+6. Check layer boundaries from `agent_docs/architecture.md`:
+   - Data flows down: `app/ → components/ → api/ → lib/`
+   - Route guards belong only in `src/app/_layout.tsx`, never in screen files
+   - Auth state management belongs only in `src/components/providers/auth.tsx` and `src/lib/auth/index.tsx`
+
+## Output Format
+
+Group findings by REVIEW.md category. For each finding:
+
+```
+**[Category]** `path/to/file.ts` — short description of the issue and what the correct approach is.
+```
+
+If a category has no issues, skip it.
+
+End the report with one of:
+- **No issues found** — if the diff is clean across all categories.
+- **X issue(s) found** — a one-line summary count.
+
+Do not suggest stylistic preferences not grounded in REVIEW.md, AGENTS.md, or agent_docs/. Do not flag things that are already handled automatically by the interceptors or tooling (e.g. case conversion, token injection).

.claude/hooks/sonar-secrets/build-scripts/pretool-secrets.sh

@@ -0,0 +1,5 @@
+#!/bin/bash
+if ! command -v sonar &> /dev/null; then
+  exit 0
+fi
+sonar hook claude-pre-tool-use

.claude/hooks/sonar-secrets/build-scripts/prompt-secrets.sh

@@ -0,0 +1,5 @@
+#!/bin/bash
+if ! command -v sonar &> /dev/null; then
+  exit 0
+fi
+sonar hook claude-prompt-submit

.claude/settings.json

@@ -0,0 +1,39 @@
+{
+  "hooks": {
+    "PostToolUse": [
+      {
+        "matcher": "Edit|Write",
+        "hooks": [
+          {
+            "type": "command",
+            "command": "pnpm type-check 2>&1 | head -30"
+          }
+        ]
+      }
+    ],
+    "PreToolUse": [
+      {
+        "matcher": "Read",
+        "hooks": [
+          {
+            "type": "command",
+            "command": ".claude/hooks/sonar-secrets/build-scripts/pretool-secrets.sh",
+            "timeout": 60
+          }
+        ]
+      }
+    ],
+    "UserPromptSubmit": [
+      {
+        "matcher": "*",
+        "hooks": [
+          {
+            "type": "command",
+            "command": ".claude/hooks/sonar-secrets/build-scripts/prompt-secrets.sh",
+            "timeout": 60
+          }
+        ]
+      }
+    ]
+  }
+}

.claude/skills/pr-description/SKILL.md

@@ -0,0 +1,83 @@
+---
+name: pr-description
+description: Generates a structured PR description from the current branch diff, following the repository's pull request template exactly. Use when the user asks to "write a PR description", "generate a PR description", "create a pull request description", "update the PR description", "prepare a PR body", "draft a pull request summary", or "write GitHub pull request text" from the current branch changes.
+---
+
+# PR Description
+
+## Purpose
+
+Create a brief, reviewer-friendly PR description from the current branch diff. The output must follow the repository's pull request template exactly, preserving every heading and keeping placeholders where content is unknown.
+
+## Style Rules
+
+- Use plain language. Avoid filler like "this PR aims to", "in order to", and "leverages".
+- Be concrete. Name the screens, components, flows, commands, or files that changed.
+- Keep it short. Each prose section should usually be 1-3 sentences.
+- Avoid bullet soup. If a section needs more than 6 bullets, group related items.
+- Skip obvious filler such as import cleanup or lint-only noise unless that is the point of the PR.
+- Do not invent Jira tickets, screenshots, devices tested, or implementation details not supported by the diff.
+
+## Workflow
+
+1. Read the repository instructions first:
+   - `AGENTS.md`
+   - `REVIEW.md` when present, because this repo requires it for review-related work.
+2. Find the PR template:
+   - Prefer `.github/PULL_REQUEST_TEMPLATE.md`.
+   - Fall back to `PULL_REQUEST_TEMPLATE.md` at the repo root only if the GitHub template is absent.
+3. Refresh and inspect the branch:
+   - Run `git fetch origin master`.
+   - Run `git log origin/master..HEAD --oneline`.
+   - Run `git diff origin/master...HEAD --stat`.
+   - Run `git diff origin/master...HEAD`.
+4. Draft the PR description using the exact headings and order from the template.
+5. Save it as `PR_DESCRIPTION.md` at the repo root, overwriting any existing file.
+6. Ensure `PR_DESCRIPTION.md` is ignored by git. If it is missing from `.gitignore`, append it under:
+
+```gitignore
+# PR description scratchpad (agents)
+PR_DESCRIPTION.md
+```
+
+7. Report back with the relative path only, unless the user asks to see the content.
+
+## Section Guidance For This Repository
+
+The current template is `.github/PULL_REQUEST_TEMPLATE.md`. Keep the warning comment and separators from the template if they are present.
+
+### Jira board reference:
+
+Leave the example placeholder or replace it only if a real Jira ticket is present in the branch name, commits, or user request. Do not invent ticket IDs.
+
+### What does this do?
+
+Write 2-4 concise sentences describing what changed. Focus on user-facing behavior, developer workflow changes, or the concrete problem fixed.
+
+### Why did you do this?
+
+Write 1-3 concise sentences explaining the reason for the change. Tie it to the bug, product need, maintainability concern, or template behavior visible in the diff.
+
+### Who/what does this impact?
+
+Name affected screens, flows, platforms, users, modules, or developer workflows. Use a short sentence or compact bullets. If impact is unclear, leave a placeholder comment instead of guessing.
+
+### How did you test this?
+
+List commands run and manual checks performed. Keep the existing checklist from the template and check only items that are supported by evidence or explicitly provided by the user.
+
+### Notes:
+
+Include caveats, follow-ups, migration notes, or review hints. If there are none, leave the template placeholder.
+
+### Screenshots / Previews
+
+Keep the screenshot/Figma/device placeholders unless real images or recordings are available. Remove irrelevant bug before/after tables only when the template structure still remains clear.
+
+## Final Response
+
+After writing the file, say where it was saved, for example:
+
+`Done: PR_DESCRIPTION.md`
+
+Do not paste the full PR description unless the user asks.

.claude/skills/review-changes/SKILL.md

@@ -0,0 +1,71 @@
+---
+name: review-changes
+description: Reviews the current branch diff against this project's architecture, conventions, and code review checklist. Use when the user asks to "review my changes", "review the diff", "check my code", "run a code review", or "review this branch".
+allowed-tools: Bash(git:*), Read
+---
+
+# Review Changes
+
+## Purpose
+
+Perform a code review of the current branch diff against the project's architecture rules, coding conventions, and the REVIEW.md checklist. Report findings grouped by category, with file and line references where possible.
+
+## Workflow
+
+1. Read the project rules:
+   - `AGENTS.md` — critical constraints and glossary
+   - `REVIEW.md` — the review checklist; this is the primary source of truth for what to flag
+   - `agent_docs/architecture.md` — layer diagram, routing conventions, dual auth system
+   - `agent_docs/conventions.md` — API hooks, styling, forms, i18n, anti-patterns
+
+2. Inspect the branch diff:
+   - Run `git fetch origin master`.
+   - Run `git log origin/master..HEAD --oneline` to understand the commit scope.
+   - Run `git diff origin/master...HEAD --stat` to see which files changed.
+   - Run `git diff origin/master...HEAD` to read the full diff.
+
+3. If a changed file needs more context to review correctly (e.g. to check imports, types, or hook usage), use Read to open it.
+
+4. Review the diff against every category in REVIEW.md:
+   - API & Query layer
+   - Auth & security
+   - Type safety
+   - i18n
+   - Styling
+   - Testing
+   - Performance
+
+5. Also check for violations of the critical constraints in `AGENTS.md`:
+   - Package manager (`pnpm` only)
+   - Env values via `Env` from `@/lib/env`
+   - No auth logic in screen components
+   - No manual camelCase↔snake_case conversion
+   - No direct MMKV access in components
+   - All strings through `useTranslation()`
+   - `createMutation` / `createQuery` from `react-query-kit`
+   - `createQueryKeys` in `src/api/query-factory.ts`
+   - `@shopify/flash-list` for growable lists
+   - `expo-crypto` for random IDs
+   - `react-hook-form` + `zod` for forms
+   - `moti` or `react-native-reanimated` for animations (no `Animated` from RN directly)
+
+6. Check layer boundaries from `agent_docs/architecture.md`:
+   - Data flows down: `app/ → components/ → api/ → lib/`
+   - Route guards belong only in `src/app/_layout.tsx`, never in screen files
+   - Auth state management belongs only in `src/components/providers/auth.tsx` and `src/lib/auth/index.tsx`
+
+## Output Format
+
+Group findings by REVIEW.md category. For each finding:
+
+```
+**[Category]** `path/to/file.ts` — short description of the issue and what the correct approach is.
+```
+
+If a category has no issues, skip it.
+
+End the report with one of:
+- **No issues found** — if the diff is clean across all categories.
+- **X issue(s) found** — a one-line summary count.
+
+Do not suggest stylistic preferences not grounded in REVIEW.md, AGENTS.md, or agent_docs/. Do not flag things that are already handled automatically by the interceptors or tooling (e.g. case conversion, token injection).