[NoQA] Refine reviewer rules based on automated tracker feedback

[kacper-mikolajczak]

Explanation of Change

Refines two coding-standards rules consumed by the Claude reviewer, based on accept/reject feedback gathered via the automated tracker. Each refinement narrows the rule's firing condition so reviewers stop dismissing technically-wrong suggestions, which was eroding trust in unrelated rules.

• CLEAN-REACT-PATTERNS-4 (clean-react-4-no-side-effect-spaghetti.md) - Previously flagged any internal helper that returns JSX, with rationale that React Compiler "cannot independently memoize" closures. That claim is wrong for thin delegation wrappers, and three sampled PR threads all rejected the suggestion on that basis. The rule now fires only when the helper (a) contains hooks/side effects/non-trivial business logic, (b) builds deeply nested JSX inline, or (c) closes over mutable parent state. Explicit carve-outs added for switch/conditional helpers that delegate to already-extracted children, and .map() over already-extracted components. The "Incorrect" example is replaced with one that hits all three triggers.
• CLEAN-REACT-PATTERNS-1 (clean-react-1-composition-over-config.md) - Case 3 (monolithic prop interface) previously counted all props uniformly, which flagged components that legitimately lifted state across siblings. Adds a Case 3 carve-out for coordination props whose role is structurally detectable: the same state setter passed to two or more sibling children, OR the same callback consumed by two or more sibling children. Case 4 (config-array rendering) is intentionally unchanged - evidence is too thin to lock in a threshold change.

The originally proposed PERF-9 refinement was rolled back during review - the cases the new carve-out would have permitted (intermediate state that is render-driving) are exactly the cases PERF-14 already wants migrated to useSyncExternalStore, so adding the carve-out would have created a contradiction between the two rules.

No application code is modified - this PR touches only .claude/skills/coding-standards/rules/*.md.

Fixed Issues

$ #90591
PROPOSAL:

Tests

This PR only modifies markdown files consumed by the Claude reviewer skill - no runtime code changes, so the mobile/web platform test matrix is N/A.

1. Verify that no errors appear in the JS console (no JS shipped).
2. Open each modified rule file under .claude/skills/coding-standards/rules/ and confirm the frontmatter parses and the markdown renders without broken sections.
3. Trigger the Claude reviewer against a PR containing a thin delegation render helper (e.g., const renderRow = () => type === 'foo' ? <Foo /> : <Bar />). Confirm CLEAN-REACT-PATTERNS-4 no longer fires.
4. Trigger the Claude reviewer against a PR whose component prop count is inflated by a single state setter passed to two or more sibling children. Confirm CLEAN-REACT-PATTERNS-1 Case 3 no longer fires on that basis alone.
5. Trigger the Claude reviewer against a PR with a render helper that closes over useState and builds nested JSX with business logic inline. Confirm CLEAN-REACT-PATTERNS-4 still fires (regression check on the narrowed rule).

Offline tests

N/A - the change does not affect runtime behavior or network/offline code paths. Rule files are consumed by the Claude reviewer pipeline, not by the app at runtime.

QA Steps

Same as Tests above. QA validation is performed by running the Claude reviewer against test PRs that exercise the narrowed and preserved firing conditions.

• Verify that no errors appear in the JS console

PR Author Checklist

• I linked the correct issue in the ### Fixed Issues section above
• I wrote clear testing steps that cover the changes made in this PR
  • I added steps for local testing in the Tests section
  • I added steps for the expected offline behavior in the Offline steps section
  • I added steps for Staging and/or Production testing in the QA steps section
  • I added steps to cover failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
  • I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
  • I tested this PR with a High Traffic account against the staging or production API to ensure there are no regressions (e.g. long loading states that impact usability).
• I included screenshots or videos for tests on all platforms
• I ran the tests on all platforms & verified they passed on:
  • Android: Native
  • Android: mWeb Chrome
  • iOS: Native
  • iOS: mWeb Safari
  • MacOS: Chrome / Safari
• I verified there are no console errors
• I followed proper code patterns
  • I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle
  • I verified that comments were added to code that is not self explanatory
  • I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
  • I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method
    • If any non-english text was added/modified, I used JaimeGPT to get English > Spanish translation. I then posted it in #expensify-open-source and it was approved by an internal Expensify engineer. Link to Slack message:
  • I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
  • I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines and is either coming verbatim from figma or has been approved by marketing
  • I verified proper file naming conventions were followed for any new files or renamed files.
  • I verified the JSDocs style guidelines were followed
• If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
• I followed the guidelines as stated in the Review Guidelines
• I tested other components that can be impacted by my changes
• I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
• I verified any variables that can be defined as constants are defined as such
• I verified that if a function's arguments changed that all usages have also been updated correctly
• If any new file was added I verified that:
  • The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory
• If a new CSS style is added I verified that:
  • A similar style doesn't already exist
  • The style can't be created with an existing StyleUtils function
• If new assets were added or existing ones were modified, I verified that:
  • The assets are optimized and compressed
  • The assets load correctly across all supported platforms.
• If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown
• If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App
• If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
• If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
• If the PR modifies the UI or modifies the form input styles:
  • I verified that all the inputs inside a form are aligned with each other.
  • I added Design label and/or tagged @Expensify/design so the design team can review the changes.
• If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
• I added unit tests for any new feature or bug fix in this PR to help automatically prevent regressions in this user flow.
• If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.

Screenshots/Videos

Android: Native

N/A - no UI changes

Android: mWeb Chrome

N/A - no UI changes

iOS: Native

N/A - no UI changes

iOS: mWeb Safari

N/A - no UI changes

MacOS: Chrome / Safari

N/A - no UI changes