Merge pull request #4864 from RSSNext/release/desktop/1.3.1

release(desktop): Release v1.3.1

Author: DIYgod

.claude/skills/installing-mobile-preview-builds/SKILL.md

@@ -0,0 +1,79 @@
+---
+name: installing-mobile-preview-builds
+description: Builds and installs the iOS preview build for apps/mobile using EAS local build and devicectl. Use when the user asks to install a preview/internal iOS build on a connected iPhone for production-like testing.
+disable-model-invocation: true
+allowed-tools: Bash, Read, Glob, Grep
+argument-hint: "[device-udid-or-name(optional)]"
+---
+
+# Install Mobile Preview Build (iOS)
+
+Use this skill to create a fresh local `preview` iOS build and install it on a connected iPhone.
+
+## Inputs
+
+- Optional `$ARGUMENTS`: device identifier (UDID or exact device name).
+- If no argument is provided, auto-select the first paired iPhone from `xcrun devicectl list devices`.
+
+## Workflow
+
+1. Validate repo and tooling.
+   - Run from repo root and ensure `apps/mobile` exists.
+   - Verify `pnpm`, `xcrun`, `xcodebuild`, and `eas-cli` are available.
+   - Verify EAS login:
+     ```bash
+     cd apps/mobile
+     pnpm dlx eas-cli whoami
+     ```
+2. Resolve target device.
+   - List paired devices:
+     ```bash
+     xcrun devicectl list devices
+     ```
+   - Choose device in this order:
+     - `$ARGUMENTS` if provided and matches exactly one device.
+     - Otherwise, first paired iPhone.
+3. Trigger local `preview` iOS build.
+
+   ```bash
+   mkdir -p .context/preview-install
+   cd apps/mobile
+   pnpm dlx eas-cli build -p ios --profile preview --non-interactive --local --output=./build-preview.ipa
+   cd ../..
+   cp apps/mobile/build-preview.ipa .context/preview-install/folo-preview.ipa
+   ```
+
+4. Install to device locally.
+   ```bash
+   unzip -q -o .context/preview-install/folo-preview.ipa -d .context/preview-install/unpacked
+   APP_PATH=$(find .context/preview-install/unpacked/Payload -maxdepth 1 -name '*.app' -type d | head -n 1)
+   xcrun devicectl device install app --device "<device-id>" "$APP_PATH"
+   ```
+5. Try launching app.
+
+   ```bash
+   xcrun devicectl device process launch --device "<device-id>" is.follow --activate
+   ```
+
+   - If launch fails due to locked device, instruct the user to unlock iPhone and open `Folo` manually.
+
+## Failure Handling
+
+- If local build fails, report:
+  - build mode (`local`)
+  - failing command
+  - key error message from command output
+- If app config fails with `Assets source directory not found ... /out/rn-web`, prebuild assets then retry once:
+  ```bash
+  pnpm --filter @follow/rn-micro-web-app build --outDir out/rn-web/html-renderer
+  ```
+
+## Output Format
+
+Always return:
+
+1. Build mode (`local`) and final status.
+2. Local IPA path.
+3. Target device identifier.
+4. Install result (`installed` or `failed`) and launch result.
+5. Next action for the user if manual action is required.

.claude/skills/mobile-release/SKILL.md

@@ -0,0 +1,114 @@
+---
+name: mobile-release
+description: Perform a regular mobile release from the dev branch. Gathers commits since last release, updates changelog, bumps version, updates iOS Info.plist, and creates release PR to mobile-main.
+disable-model-invocation: true
+allowed-tools: Bash, Read, Write, Edit, Glob, Grep
+---
+
+# Mobile Regular Release
+
+Perform a regular mobile release. This skill handles the full release workflow from the `dev` branch.
+
+## Pre-flight checks
+
+1. Confirm the current branch is `dev`. If not, abort with a warning.
+2. Run `git pull --rebase` in the repo root to ensure the local branch is up to date.
+3. Read `apps/mobile/package.json` to get the current `version`.
+
+## Step 1: Gather changes since last release
+
+1. Find the last release tag (both old `mobile@` and new `mobile/v` prefixes exist):
+   ```bash
+   git tag --sort=-creatordate | grep -E '^mobile[@/]' | head -1
+   ```
+2. If no tag found, find the last release commit by matching only the subject line:
+   ```bash
+   git log --format="%H %s" | grep "^[a-f0-9]* release(mobile): release v" | head -1 | awk '{print $1}'
+   ```
+3. Get all commits since the last release on the current branch:
+   ```bash
+   git log <last-tag-or-commit>..HEAD --oneline --no-merges
+   ```
+4. Categorize commits into:
+   - **Shiny new things** (feat: commits, new features)
+   - **Improvements** (refactor:, perf:, chore: improvements, dependency updates)
+   - **No longer broken** (fix: commits, bug fixes)
+   - **Thanks** (identify external contributor GitHub usernames from commits)
+
+## Step 2: Update changelog
+
+1. Read `apps/mobile/changelog/next.md`.
+2. Present the categorized changes to the user and draft the changelog content.
+3. Wait for user confirmation or edits before writing.
+4. Write the final content to `apps/mobile/changelog/next.md`, following the template format:
+
+   ```markdown
+   # What's New in vNEXT_VERSION
+
+   ## Shiny new things
+
+   - description of new feature
+
+   ## Improvements
+
+   - description of improvement
+
+   ## No longer broken
+
+   - description of fix
+
+   ## Thanks
+
+   Special thanks to volunteer contributors @username for their valuable contributions
+   ```
+
+5. Keep `NEXT_VERSION` as the placeholder - it will be replaced by `apply-changelog.ts` during bump.
+
+## Step 3: Execute bump
+
+1. Change directory to `apps/mobile/` and run the bump:
+   ```bash
+   cd apps/mobile && pnpm bump
+   ```
+2. This is an interactive `nbump` command that prompts for version selection. It will:
+   - Pull latest changes
+   - Apply changelog (rename next.md to {version}.md, create new next.md from template)
+   - Format package.json with eslint + prettier
+   - Bump version in `package.json`
+   - Update `ios/Folo/Info.plist`:
+     - Set `CFBundleShortVersionString` to the new version
+     - Increment `CFBundleVersion` (build number) by 1
+   - Commit with message `release(mobile): release v{NEW_VERSION}`
+   - Create branch `release/mobile/{NEW_VERSION}`
+   - Push branch and create PR to `mobile-main`
+
+## Step 4: Verify
+
+1. Confirm the PR was created successfully by checking the output.
+2. Report the new version number and PR URL to the user.
+3. Summarize:
+   - New version: v{NEW_VERSION}
+   - Changelog highlights
+   - PR URL
+
+## Post-release (manual steps, inform user)
+
+After the release PR is merged to `mobile-main`:
+
+1. **Trigger production builds** via GitHub Actions `workflow_dispatch`:
+   - Go to "Build iOS" workflow, select `mobile-main` branch, profile = `production`
+   - Go to "Build Android" workflow, select `mobile-main` branch, profile = `production`
+2. Production builds auto-submit to App Store (via `eas submit`) and Google Play (as draft).
+3. After submission, go to App Store Connect and Google Play Console to complete the review/release process.
+
+## Reference
+
+- Bump config: `apps/mobile/bump.config.ts`
+- Changelog dir: `apps/mobile/changelog/`
+- Changelog template: `apps/mobile/changelog/next.template.md`
+- Apply changelog script: `apps/mobile/scripts/apply-changelog.ts`
+- EAS config: `apps/mobile/eas.json`
+- App config: `apps/mobile/app.config.ts`
+- iOS Info.plist: `apps/mobile/ios/Folo/Info.plist`
+- CI build iOS: `.github/workflows/build-ios.yml`
+- CI build Android: `.github/workflows/build-android.yml`

.claude/skills/update-deps/SKILL.md

@@ -0,0 +1,178 @@
+---
+name: update-deps
+description: Update all dependencies across frontend and backend projects. Reads changelogs for breaking changes, checks affected code, runs tests, and provides a summary. Use when updating npm dependencies across the monorepo.
+disable-model-invocation: true
+allowed-tools: Bash, Read, Write, Edit, Glob, Grep, WebFetch, WebSearch, Task
+---
+
+# Update All Dependencies
+
+Update all npm dependencies across the frontend (current repo) and backend projects. This skill handles the full update workflow including changelog review, code impact analysis, testing, and summarization.
+
+## Step 0: Ask for backend directory
+
+Ask the user for the backend project directory path. Do NOT hardcode any path. Example prompt:
+
+> Please provide the backend project directory path (e.g., `/path/to/backend`).
+
+Wait for the user's response before proceeding. Save the path as `BACKEND_DIR` for later use.
+
+## Step 1: Analyze current dependencies
+
+### Frontend (current repo)
+
+1. Run `pnpm outdated --recursive` in the current repo root to identify all outdated dependencies.
+2. Save the full output for later analysis.
+
+### Backend
+
+1. Run `pnpm outdated --recursive` in `BACKEND_DIR` to identify all outdated dependencies.
+2. Save the full output for later analysis.
+
+Present the user with a summary of how many dependencies are outdated in each project.
+
+## Step 2: Update dependencies
+
+### Strategy
+
+Update in two phases to isolate issues:
+
+**Phase 1 — Patch and minor updates (safer):**
+
+From the `pnpm outdated` output, identify all dependencies where the update is a patch or minor version bump. Update them in batch:
+
+1. Frontend: For each patch/minor outdated package, run `pnpm update <package>@latest --recursive` in the repo root.
+2. Backend: For each patch/minor outdated package, run `pnpm update <package>@latest --recursive` in `BACKEND_DIR`.
+
+> **Why `@latest`?** Both projects use `save-exact=true`, so versions are pinned without `^` or `~`. Without `--latest`, `pnpm update` only resolves within the existing range, which for exact versions is a no-op.
+
+**Phase 2 — Major updates (requires careful review):**
+
+For each dependency with a major version update available:
+
+1. Identify the dependency name, current version, and latest version.
+2. **Read the changelog** (Step 3) before updating.
+3. Only update after confirming no blocking breaking changes.
+4. Use `pnpm update <package>@latest --recursive` to update specific packages.
+
+**Important pnpm workspace notes:**
+
+- The frontend project uses `pnpm catalog` in `pnpm-workspace.yaml` for some shared versions. If a dependency is managed via catalog, update the version in `pnpm-workspace.yaml` instead of individual `package.json` files.
+- Both projects use `save-exact=true`, so versions are pinned without `^` or `~`.
+- Check `patchedDependencies` in `pnpm-workspace.yaml` or `package.json` — if a patched dependency is being updated, verify the patch still applies or remove it if no longer needed.
+
+## Step 3: Review changelogs for major updates
+
+For each dependency with a **major version update**, you MUST read the changelog before updating.
+
+### How to find changelogs
+
+Use these methods in order of preference:
+
+1. **npm registry**: Run `npm view <package> repository.url` to find the repo, then check for `CHANGELOG.md` or GitHub releases.
+2. **GitHub releases**: Search `https://github.com/<owner>/<repo>/releases` using WebFetch.
+3. **Web search**: Use WebSearch to find `<package> changelog <old-version> to <new-version>`.
+
+### What to look for
+
+- **Breaking changes**: API removals, renamed exports, changed defaults, dropped Node.js version support.
+- **Deprecated features**: Features being removed in future versions.
+- **Migration guides**: Official upgrade instructions.
+- **Peer dependency changes**: New or changed peer dependency requirements.
+
+### Document findings
+
+For each major update, record:
+
+- Package name and version change (e.g., `foo: 2.x → 3.x`)
+- Breaking changes summary
+- Whether our code is affected (and how)
+
+## Step 4: Check affected code
+
+For each dependency with breaking changes identified in Step 3:
+
+1. Use `Grep` to find all imports and usages of the affected package across the relevant project (frontend or backend).
+2. Read the files containing usages.
+3. Compare the usage against the breaking change description.
+4. If our code uses an affected API:
+   - Attempt to fix the code following the migration guide.
+   - If the fix is complex or risky, **skip updating this dependency** and note it in the summary.
+5. If our code does NOT use any affected API, proceed with the update.
+
+## Step 5: Run tests and checks
+
+After all updates are applied:
+
+### Frontend
+
+Run these commands sequentially in the repo root and capture results:
+
+```bash
+pnpm install
+pnpm typecheck
+pnpm test
+pnpm lint
+```
+
+### Backend
+
+Run these commands sequentially in `BACKEND_DIR` and capture results:
+
+```bash
+pnpm install
+pnpm typecheck
+pnpm test
+pnpm lint
+```
+
+### Handle failures
+
+- **TypeScript errors**: Read the error output, identify which updated dependency caused the issue, and fix the type errors. If unfixable, revert that specific dependency update.
+- **Test failures**: Analyze the failure, check if it's related to a dependency update, and fix or revert.
+- **Lint errors**: Run `pnpm lint:fix` first. If issues persist, fix manually or revert the causing update.
+
+Repeat the test cycle until all checks pass.
+
+## Step 6: Summary
+
+Present the user with a comprehensive summary:
+
+### Update report
+
+```
+## Dependencies Updated
+
+### Frontend
+- <package>: <old-version> → <new-version> (patch/minor/major)
+- ...
+
+### Backend
+- <package>: <old-version> → <new-version> (patch/minor/major)
+- ...
+
+## Skipped Updates (with reasons)
+- <package>: <reason why not updated>
+- ...
+
+## Key Changelog Highlights
+
+### Breaking Changes Applied
+- <package> <version>: <what changed and how we adapted>
+
+### Notable New Features
+- <package> <version>: <brief description>
+
+### Deprecation Warnings
+- <package> <version>: <what's deprecated and timeline>
+
+## Test Results
+- Frontend typecheck: ✅/❌
+- Frontend tests: ✅/❌
+- Frontend lint: ✅/❌
+- Backend typecheck: ✅/❌
+- Backend tests: ✅/❌
+- Backend lint: ✅/❌
+```
+
+Ask the user if they want to commit the changes.