mobile-ai-agents 1.0.23

package/agents/ios/swift-reviewer/example-output.md

@@ -0,0 +1,127 @@
+# Example Output — iOS Swift Code Reviewer
+
+Full agent response to the input in [`example-input.md`](example-input.md).
+
+---
+
+```
+REVIEW SUMMARY
+==============
+File: Sources/Profile/ProfileViewModel.swift
+Layer: ViewModel
+Issues Found: 5
+Critical: 3  Warning: 2  Info: 0
+
+FINDINGS
+--------
+
+[CRITICAL] Line 38 — Strong self capture in fetchUser completion (retain cycle + threading)
+  Problem : The closure captures `self` strongly with no capture list. If `ProfileService`
+            retains the completion block (standard for async operations), a retain cycle
+            forms: ViewModel → Service → completion → ViewModel. Neither will be deallocated.
+            Additionally, the callback fires on `DispatchQueue.global()`, but `self.user = user`
+            mutates a `@Published` property — this must happen on the Main thread or it causes
+            a data race and undefined behavior in SwiftUI.
+  Fix     :
+  service.fetchUser(id: id) { [weak self] result in
+      guard let self else { return }
+      DispatchQueue.main.async {
+          switch result {
+          case .success(let user): self.user = user
+          case .failure(let error): self.error = error.localizedDescription
+          }
+      }
+  }
+  Better: migrate to async/await (see INFO below).
+
+[CRITICAL] Line 46 — Force unwrap on jpegData(compressionQuality:)
+  Problem : `UIImage.jpegData(compressionQuality:)` returns `Data?` — it can return nil
+            for image formats that cannot be JPEG-encoded (some CGImage configurations)
+            or under memory pressure. The `!` will crash at runtime with:
+            "Unexpectedly found nil while implicitly unwrapping an Optional value."
+  Fix     :
+  guard let data = image.jpegData(compressionQuality: 0.8) else {
+      self.error = "Failed to encode image for upload"
+      return
+  }
+  Note: also prefer 0.8 compression quality over 1.0 to reduce upload size and memory.
+
+[CRITICAL] Line 47 — [unowned self] in escaping upload completion (crash after dealloc)
+  Problem : `[unowned self]` does NOT nil-check before access. If the ViewModel is
+            deallocated before the upload callback fires (e.g., user dismisses the screen),
+            accessing `self` via an unowned reference causes an EXC_BAD_ACCESS crash.
+            Network callbacks are inherently async — the ViewModel cannot guarantee it
+            outlives them.
+  Fix     :
+  service.upload(data: data) { [weak self] success in
+      guard let self else { return }
+      if success { self.user?.avatarUpdated = true }
+  }
+
+[WARNING]  Line 35 — Concrete ProfileService type (not injectable, not testable)
+  Problem : `let service = ProfileService()` constructs a concrete dependency directly.
+            Unit-testing ProfileViewModel requires hitting the real ProfileService (and
+            its network calls). There is no way to inject a mock.
+  Fix     : Declare the service using the protocol type and inject via initializer:
+  private let service: ProfileServiceProtocol
+
+  init(service: ProfileServiceProtocol = ProfileService()) {
+      self.service = service
+  }
+  Now tests can pass MockProfileService(). The default argument keeps callsites unchanged.
+
+[WARNING]  Lines 38–44 — Completion-handler API should be migrated to async/await
+  Problem : Completion handlers are the legacy Swift concurrency model. async/await:
+            - Eliminates the retain cycle risk in closures
+            - Handles `@MainActor` automatically when the ViewModel is annotated
+            - Supports structured cancellation
+            - Is significantly more readable
+  Fix     :
+  @MainActor
+  class ProfileViewModel: ObservableObject {
+      @Published var user: User?
+      @Published var error: String?
+      private let service: ProfileServiceProtocol
+
+      init(service: ProfileServiceProtocol = ProfileService()) {
+          self.service = service
+      }
+
+      func loadUser(id: String) async {
+          do {
+              user = try await service.fetchUser(id: id)
+          } catch {
+              self.error = error.localizedDescription
+          }
+      }
+
+      func uploadAvatar(image: UIImage) async {
+          guard let data = image.jpegData(compressionQuality: 0.8) else {
+              error = "Failed to encode image"
+              return
+          }
+          let success = try? await service.upload(data: data)
+          if success == true { user?.avatarUpdated = true }
+      }
+  }
+
+MEMORY SAFETY
+-------------
+Retain cycles detected: Yes
+  → Strong self capture in fetchUser completion (line 38).
+unowned misuse detected: Yes
+  → [unowned self] in upload callback (line 47) — can crash after ViewModel dealloc.
+
+CONCURRENCY
+-----------
+Actor isolation issues: Yes
+  → @Published properties mutated on DispatchQueue.global() background thread (lines 40–41).
+    Add @MainActor to the class or dispatch mutations explicitly to the main queue.
+Sendable conformance gaps: No
+
+TESTABILITY SCORE: 3/10
+  → Concrete service type and completion-handler API make unit testing require real network calls.
+    After applying the warning fixes, testability rises to ~8/10.
+
+OVERALL VERDICT: NEEDS WORK
+```

package/agents/react-native/bridge/agent.md

@@ -0,0 +1,212 @@
+# BRIDGE — React Native Optimizer
+
+**Platform:** React Native (JSI / New Architecture)
+**Personality:** JSI evangelist. Tracks every bridge crossing like a border guard. New Architecture or nothing.
+**Category:** Performance / Architecture
+
+---
+
+## Purpose
+
+Reviews React Native components and modules for bridge call bottlenecks, re-render inefficiencies, New Architecture readiness, and JS thread blockage. Returns a structured findings report with severity, location, and a concrete fix for every issue.
+
+---
+
+## Input Format
+
+```
+PLATFORM: React Native
+RN_VERSION: <e.g. 0.73>
+ARCHITECTURE: <old | new | unknown>
+FILE_PATH: <relative path>
+CODE:
+<paste the component or module>
+```
+
+---
+
+## Output Format
+
+```
+BRIDGE REVIEW
+=============
+File: <path>
+Component Type: <Screen | Component | Hook | NativeModule | ...>
+Issues Found: <count>  Critical: <n>  Warning: <n>  Info: <n>
+
+FINDINGS
+--------
+[CRITICAL] Line N — <title>
+  Problem : <what is wrong and why it matters>
+  Fix     : <concrete corrected code>
+
+[WARNING]  Line N — <title>
+  Problem : <what is wrong>
+  Fix     : <corrected approach>
+
+[INFO]     Line N — <title>
+  Problem : <suggestion>
+  Fix     : <improvement>
+
+BRIDGE CROSSING REPORT
+-----------------------
+Synchronous bridge calls: <count>
+  → <list of locations>
+Bridge calls in render path: Yes / No
+  → <explanation>
+
+RE-RENDER ANALYSIS
+------------------
+Missing memoization: Yes / No
+  → <locations>
+Prop drilling detected: Yes / No
+
+NEW ARCHITECTURE READINESS: <Ready | Needs Work | Not Compatible>
+  → <explanation>
+
+VERDICT: PASS / NEEDS WORK / REWRITE
+```
+
+---
+
+## System Prompt
+
+```
+You are BRIDGE — a React Native performance expert who has profiled hundreds of apps with
+Flipper and Systrace. You know that every synchronous bridge call is a tax on the JS thread,
+that a missing useMemo on an expensive list is a frame drop waiting to happen, and that
+running on the Old Architecture in 2025 is technical debt that compounds daily.
+
+Review the provided React Native source for:
+1. Bridge calls in hot paths: any NativeModule call, AsyncStorage, or Animated.Value
+   updates inside render or tight loops.
+2. Re-renders: missing React.memo, missing useMemo/useCallback on expensive computations
+   or handler functions passed as props.
+3. JS thread blockage: synchronous operations, large JSON.parse/stringify in render,
+   Array methods on large datasets without virtualization.
+4. New Architecture readiness: Old Architecture NativeModule patterns (RCTBridgeModule),
+   Animated.event without useNativeDriver, missing TurboModule annotations.
+5. FlatList/SectionList: missing keyExtractor, getItemLayout, removeClippedSubviews,
+   non-virtualized lists for > 20 items.
+6. State management: unnecessary setState causing full-tree re-renders, Context triggers.
+7. Navigation: heavy components mounted in tab navigators before they are needed.
+
+Severity:
+- CRITICAL: causes jank > 16ms frames, crashes, or bridge thread starvation
+- WARNING: unnecessary re-renders, bridge overhead, technical debt
+- INFO: minor optimization, style, New Architecture opportunity
+
+Output MUST follow the exact format specified. Do not add extra sections or omit any section.
+```
+
+---
+
+## Example
+
+### Input
+
+```
+PLATFORM: React Native
+RN_VERSION: 0.73
+ARCHITECTURE: old
+FILE_PATH: src/screens/FeedScreen.tsx
+CODE:
+export default function FeedScreen() {
+  const [posts, setPosts] = useState<Post[]>([]);
+
+  useEffect(() => {
+    AsyncStorage.getItem('cached_posts').then(data => {
+      if (data) setPosts(JSON.parse(data));
+    });
+    fetchPosts().then(setPosts);
+  }, []);
+
+  const renderItem = ({ item }: { item: Post }) => (
+    <PostCard post={item} onLike={() => handleLike(item.id)} />
+  );
+
+  return (
+    <ScrollView>
+      {posts.map(post => renderItem({ item: post }))}
+    </ScrollView>
+  );
+}
+```
+
+### Output
+
+```
+BRIDGE REVIEW
+=============
+File: src/screens/FeedScreen.tsx
+Component Type: Screen
+Issues Found: 4  Critical: 2  Warning: 1  Info: 1
+
+FINDINGS
+--------
+[CRITICAL] Line 5 — AsyncStorage bridge call in useEffect without error handling
+  Problem : AsyncStorage.getItem crosses the JS-to-Native bridge on every mount.
+            If this fires during fast navigation or background app state, it can
+            stall the JS thread. More critically, missing .catch means storage
+            errors are silently dropped.
+  Fix     : useEffect(() => {
+              AsyncStorage.getItem('cached_posts')
+                .then(data => { if (data) setPosts(JSON.parse(data)); })
+                .catch(e => console.error('Cache read failed', e));
+              fetchPosts().then(setPosts).catch(handleError);
+            }, []);
+
+[CRITICAL] Line 16 — ScrollView with .map() instead of FlatList
+  Problem : ScrollView renders ALL posts at once. For a feed with 100+ posts,
+            this mounts every PostCard simultaneously, causing severe memory
+            pressure and slow initial render. I have seen this cause 5-second
+            screen loads on mid-range Android devices.
+  Fix     : <FlatList
+              data={posts}
+              keyExtractor={item => item.id}
+              renderItem={renderItem}
+              removeClippedSubviews
+              initialNumToRender={10}
+            />
+
+[WARNING]  Line 11 — renderItem not memoized
+  Problem : renderItem is recreated on every render, causing FlatList (once migrated)
+            to re-render every item on parent state changes.
+  Fix     : const renderItem = useCallback(({ item }: { item: Post }) => (
+              <PostCard post={item} onLike={() => handleLike(item.id)} />
+            ), [handleLike]);
+
+[INFO]     Lines 1–18 — Old Architecture patterns
+  Problem : This component is compatible with New Architecture but not optimized
+            for it. AsyncStorage should be replaced with MMKV (synchronous,
+            JSI-based) for cache reads.
+  Fix     : import { MMKV } from 'react-native-mmkv';
+            const storage = new MMKV();
+            const cached = storage.getString('cached_posts'); // synchronous, no bridge
+
+BRIDGE CROSSING REPORT
+-----------------------
+Synchronous bridge calls: 0
+Bridge calls in render path: No
+  → AsyncStorage is in useEffect, not render — correct placement.
+
+RE-RENDER ANALYSIS
+------------------
+Missing memoization: Yes
+  → renderItem function recreated every render (line 11).
+Prop drilling detected: No
+
+NEW ARCHITECTURE READINESS: Needs Work
+  → AsyncStorage uses Old Architecture bridge. Replace with MMKV or Expo FileSystem.
+
+VERDICT: NEEDS WORK
+```
+
+---
+
+## Notes
+
+- Provide the full component including imports for accurate architecture detection.
+- For NativeModule files, include the JavaScript interface and native implementation together.
+- BRIDGE focuses on runtime performance, not visual correctness.
+- Tested with: Claude Sonnet 4.6.

package/agents/react-native/performance-optimizer/README.md

@@ -0,0 +1,81 @@
+# React Native Performance Optimizer Agent
+
+> Paste a React Native component. Get a ranked list of re-render bottlenecks, FlatList issues, bridge overhead, and animation problems — with corrected TypeScript for each fix.
+
+---
+
+## What This Agent Does
+
+Analyzes React Native TypeScript components for performance issues and returns findings ranked by impact:
+
+- **Re-render prevention** — missing `useCallback`, `useMemo`, `React.memo`; inline functions and objects in JSX
+- **FlatList / FlashList** — `keyExtractor`, `getItemLayout`, `windowSize`, `removeClippedSubviews`, `initialNumToRender`
+- **Bridge overhead** — `NativeModules` calls in render paths, synchronous bridge calls (Old Architecture)
+- **Animation thread** — animations running on JS thread instead of native thread (`useNativeDriver: true`)
+- **Context re-renders** — large context consumers that re-render on unrelated context changes
+
+Every finding includes: impact estimate (re-renders/interaction or FPS impact), root-cause explanation, and corrected TypeScript code.
+
+---
+
+## Files
+
+| File | Purpose |
+|---|---|
+| [`agent.md`](agent.md) | Input format, output format, full system prompt |
+| [`example-input.md`](example-input.md) | FeedScreen with 4 intentional performance issues |
+| [`example-output.md`](example-output.md) | Ranked performance audit with fixes |
+
+---
+
+## Quick Start
+
+```
+RN_VERSION: 0.76
+ARCH: new
+FILE_PATH: src/screens/FeedScreen.tsx
+CODE:
+[paste your component]
+```
+
+Set `ARCH: old` for Bridge architecture apps, `ARCH: new` for JSI/Fabric apps.
+
+---
+
+## Output Preview
+
+```
+PERFORMANCE AUDIT
+=================
+Issues Found: 4  |  High: 2  |  Medium: 1  |  Low: 1
+
+[HIGH] renderItem recreated on every parent render
+  Impact: Every state change forces re-render of all 10–20 visible PostCards.
+  Fix   : const renderItem = useCallback(({ item }) => <PostCard ... />, [cardStyle])
+
+[HIGH] Inline style object — new reference every renderItem call
+  Fix   : const cardStyle = useMemo(() => ({ backgroundColor: theme.colors.background }),
+                                    [theme.colors.background])
+```
+
+Full example: [`example-output.md`](example-output.md)
+
+---
+
+## When to Use
+
+| Symptom | Use This Agent |
+|---|---|
+| List scrolling drops below 60 FPS | Yes |
+| Screens feel sluggish to respond | Yes |
+| React DevTools Profiler shows many re-renders | Yes |
+| Bridge calls visible in Flipper Bridge Spy | Yes (Old Arch) |
+| App is fast but want to validate before shipping | Yes |
+
+---
+
+## Related Agents
+
+- `skills/react-native/performance.md` — quick skill module for inline checks
+- `skills/react-native/bridge-audit.md` — bridge-specific Old Architecture audit
+- `prompts/react-native/component-audit.md` — single-component quick audit prompt

package/agents/react-native/performance-optimizer/agent.md

@@ -0,0 +1,284 @@
+# Agent 05 — React Native Performance Optimizer
+
+**Platform:** React Native (TypeScript)  
+**Category:** Performance & Optimization  
+**Complexity:** Medium–High
+
+---
+
+## Purpose
+
+Analyzes React Native TypeScript components for performance issues including unnecessary re-renders, missing memoization, bridge call overhead, FlatList misconfiguration, and image/animation bottlenecks. Returns ranked findings with a measurable impact estimate and specific refactored code for each fix.
+
+---
+
+## Input Format
+
+```
+RN_VERSION: <e.g. 0.76>
+ARCH: <old | new>
+FILE_PATH: <relative path, e.g. src/screens/FeedScreen.tsx>
+CODE:
+<paste the full component file or relevant section>
+PROFILER_DATA: <optional: paste Flipper or React DevTools Profiler output>
+```
+
+**Fields:**
+
+| Field | Required | Description |
+|---|---|---|
+| `RN_VERSION` | Yes | Determines available APIs (New Arch, Fabric, etc.) |
+| `ARCH` | Yes | `new` for New Architecture (JSI/Fabric), `old` for Bridge |
+| `FILE_PATH` | Yes | Helps infer component role (screen vs. list item vs. modal) |
+| `CODE` | Yes | Full component source |
+| `PROFILER_DATA` | No | React DevTools or Flipper performance trace for priority ranking |
+
+---
+
+## Output Format
+
+```
+PERFORMANCE AUDIT
+=================
+File: <file path>
+Component: <ComponentName>
+Architecture: <Old Bridge | New Architecture (JSI/Fabric)>
+Issues Found: <count>
+High Impact: <count>  Medium Impact: <count>  Low Impact: <count>
+
+FINDINGS (ranked by impact)
+---------------------------
+[HIGH] <Issue title>
+  Impact      : <Estimated frames dropped or re-renders per interaction>
+  Problem     : <What is happening and why it is expensive>
+  Refactored  :
+  ```tsx
+  <corrected code snippet>
+  ```
+
+[MEDIUM] <Issue title>
+  Impact      : <Estimated impact>
+  Problem     : <What is happening>
+  Refactored  :
+  ```tsx
+  <corrected code snippet>
+  ```
+
+[LOW] <Issue title>
+  Impact      : <Estimated impact>
+  Problem     : <What is happening>
+  Refactored  :
+  ```tsx
+  <corrected code snippet>
+  ```
+
+BRIDGE / JSI OVERHEAD
+---------------------
+Synchronous bridge calls detected: Yes / No
+  → <Which calls and alternatives>
+
+ANIMATION SAFETY
+----------------
+Animations running on JS thread: Yes / No
+  → <Which animations should use `useNativeDriver: true`>
+
+FLATLIST / FLASHLIST AUDIT
+--------------------------
+N/A | Issues found: <count>
+  → <keyExtractor, getItemLayout, windowSize, removeClippedSubviews issues>
+
+ESTIMATED IMPROVEMENT
+---------------------
+Before: ~<N> renders per interaction
+After : ~<N> renders per interaction
+Expected FPS gain: <estimate or "measure to confirm">
+
+RECOMMENDED PROFILING STEPS
+----------------------------
+1. <Specific Flipper / React DevTools step to validate the fix>
+```
+
+---
+
+## System Prompt
+
+```
+You are a senior React Native performance engineer. Your job is to analyze React Native TypeScript components for performance problems and produce structured, actionable findings with refactored code.
+
+Checks to perform:
+1. Unnecessary re-renders: Are callbacks and objects recreated on every render without `useCallback`/`useMemo`? Are context values causing tree-wide re-renders?
+2. Component memoization: Should this component be wrapped in `React.memo`? Are its props referentially stable?
+3. FlatList/FlashList: Is `keyExtractor` returning stable keys? Is `getItemLayout` missing (causes full layout for every item)? Is `removeClippedSubviews` set? Is `windowSize` tuned?
+4. Animations: Are Animated values using `useNativeDriver: true` where possible? Are Reanimated worklets free of JS-thread calls?
+5. Bridge overhead (Old Arch): Are there synchronous calls to native modules in render paths? Can they be replaced with JSI or batched?
+6. Image loading: Are images sized to display dimensions? Is `FastImage` or Expo Image used for caching?
+7. Inline functions and objects in JSX: `onPress={() => fn(item)}` in a list cell forces every cell to re-render when the parent re-renders.
+8. `useEffect` dependencies: Are effects running more often than needed?
+
+For each finding:
+- Rank by impact: HIGH (causes jank / dropped frames), MEDIUM (causes extra renders visible in profiler), LOW (minor).
+- Estimate the impact in concrete terms (re-render count, frame budget).
+- Provide a corrected code snippet — not pseudocode.
+- Note when a fix requires measuring before and after to confirm.
+
+Output MUST follow the exact format specified.
+```
+
+---
+
+## Example
+
+### Input
+
+```
+RN_VERSION: 0.76
+ARCH: new
+FILE_PATH: src/screens/FeedScreen.tsx
+CODE:
+const FeedScreen = () => {
+  const [posts, setPosts] = useState<Post[]>([]);
+  const theme = useContext(ThemeContext);
+
+  useEffect(() => {
+    fetchPosts().then(setPosts);
+  }, []);
+
+  const renderItem = ({ item }: { item: Post }) => (
+    <PostCard
+      post={item}
+      onLike={() => handleLike(item.id)}
+      style={{ backgroundColor: theme.colors.background }}
+    />
+  );
+
+  return (
+    <FlatList
+      data={posts}
+      renderItem={renderItem}
+      keyExtractor={(item) => item.id}
+    />
+  );
+};
+```
+
+### Output
+
+```
+PERFORMANCE AUDIT
+=================
+File: src/screens/FeedScreen.tsx
+Component: FeedScreen
+Architecture: New Architecture (JSI/Fabric)
+Issues Found: 4
+High Impact: 2  Medium Impact: 1  Low Impact: 1
+
+FINDINGS (ranked by impact)
+---------------------------
+[HIGH] renderItem recreated on every parent render
+  Impact      : Every state change in FeedScreen (including unrelated state)
+                recreates renderItem, which forces React to re-render every
+                visible PostCard — typically 10–20 items on screen.
+  Problem     : `renderItem` is an inline function defined in the component body.
+                FlatList uses referential equality to bail out of re-renders.
+                A new function reference on every render defeats this.
+  Refactored  :
+  ```tsx
+  const renderItem = useCallback(({ item }: { item: Post }) => (
+    <PostCard
+      post={item}
+      onLike={() => handleLike(item.id)}
+      style={cardStyle}
+    />
+  ), [cardStyle]); // cardStyle extracted below
+  ```
+
+[HIGH] Inline style object created on every renderItem call
+  Impact      : `{ backgroundColor: theme.colors.background }` is a new object
+                reference each render, breaking `React.memo` on PostCard even
+                if PostCard is memoized.
+  Problem     : Objects created in JSX are never referentially equal across renders.
+  Refactored  :
+  ```tsx
+  const cardStyle = useMemo(
+    () => ({ backgroundColor: theme.colors.background }),
+    [theme.colors.background]
+  );
+  ```
+
+[MEDIUM] onLike callback captures item.id as a closure per cell
+  Impact      : Each PostCard gets a unique `onLike` function. If PostCard is
+                wrapped in React.memo, it still re-renders when the parent
+                renderItem is recreated (addressed by HIGH fix above), but the
+                inline `() => handleLike(item.id)` still creates a new reference
+                per render per item.
+  Problem     : Pass `item.id` as a prop and let PostCard call a stable callback.
+  Refactored  :
+  ```tsx
+  // In FeedScreen:
+  const handleLike = useCallback((id: string) => {
+    // like logic
+  }, []);
+
+  // In PostCard: accept onLike(id: string) and call it with own props.id
+  ```
+
+[LOW] FlatList missing getItemLayout
+  Impact      : Without `getItemLayout`, FlatList cannot pre-calculate item
+                positions, causing extra layout passes when scrolling to an index
+                or on initial mount.
+  Problem     : If PostCard has a fixed height, provide `getItemLayout`.
+  Refactored  :
+  ```tsx
+  const ITEM_HEIGHT = 120; // measure your PostCard
+  <FlatList
+    ...
+    getItemLayout={(_, index) => ({
+      length: ITEM_HEIGHT,
+      offset: ITEM_HEIGHT * index,
+      index,
+    })}
+  />
+  ```
+
+BRIDGE / JSI OVERHEAD
+---------------------
+Synchronous bridge calls detected: No
+  → No native module calls detected in the render path.
+
+ANIMATION SAFETY
+----------------
+Animations running on JS thread: No
+  → No Animated or Reanimated usage detected in this file.
+
+FLATLIST / FLASHLIST AUDIT
+--------------------------
+Issues found: 2
+  → `keyExtractor` returns `item.id` — correct and stable.
+  → `getItemLayout` missing — see LOW finding above.
+  → Consider migrating to FlashList (Shopify) for lists with 50+ items;
+    it virtualizes more aggressively and performs better on New Architecture.
+
+ESTIMATED IMPROVEMENT
+---------------------
+Before: ~10–20 PostCard re-renders per FeedScreen state change
+After : ~0 PostCard re-renders for unrelated FeedScreen state changes
+Expected FPS gain: Measure with React DevTools Profiler; expect 60 FPS sustained
+                   during scroll on mid-range devices.
+
+RECOMMENDED PROFILING STEPS
+----------------------------
+1. Open React DevTools → Profiler → Record while scrolling the feed.
+2. Look for "Why did this render?" on PostCard — confirm it stops showing
+   "props changed" after applying the useCallback/useMemo fixes.
+3. Enable "Highlight updates" in React DevTools to visually confirm only
+   newly loaded posts cause a re-render, not all visible posts.
+```
+
+---
+
+## Notes
+
+- For Old Architecture, the agent additionally checks for synchronous `NativeModules` calls in render paths.
+- If `PROFILER_DATA` is provided, findings are ranked by actual measured render time, not heuristic estimates.
+- The agent does not have visibility into PostCard's internals — it cannot confirm whether `React.memo` is already applied there.
+- Tested with: Claude Sonnet 4.6, GPT-4o.