feat(MSDK-3095): Added cursor AI rules#187
Conversation
|
CodeAnt AI is reviewing your PR. Thanks for using CodeAnt! 🎉We're free for open-source projects. if you're enjoying it, help us grow by sharing. Share on X · |
Review Summary by QodoAdd Cursor AI rules and configuration for project guidance
WalkthroughsDescription• Added comprehensive Cursor AI rules for project guidance • Created platform-specific rules for Android, iOS, and React Native • Established CI/CD, testing, and security best practices documentation • Added Cursor ignore configuration files for optimal indexing Diagramflowchart LR
A["Cursor Rules"] --> B["Project Overview"]
A --> C["Platform Rules"]
C --> D["Android Native"]
C --> E["iOS Native"]
C --> F["React Native"]
A --> G["Development Guides"]
G --> H["TypeScript Conventions"]
G --> I["Testing"]
G --> J["CI/CD & Security"]
A --> K["Cursor Config"]
K --> L[".cursorignore"]
K --> M[".cursorindexingignore"]
File Changes1. .cursor/rules/project-overview.mdc
|
Code Review by Qodo
1.
|
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (6)
✅ Files skipped from review due to trivial changes (1)
🚧 Files skipped from review as they are similar to previous changes (5)
📝 WalkthroughWalkthroughAdds a set of new Cursor rule and repo configuration files documenting native (Android/iOS), React Native, TypeScript, testing, CI, and security conventions, plus ignore/indexing patterns and a Ruby version pin for the sample app. Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
PR Summary: Adds sample/.ruby-version specifying Ruby 3.2.0; no cursor AI rules or other code changes included.
|
codeant-ai
bot
added
the
size:L
![pantoaibot[bot]](https://avatars.githubusercontent.com/in/934356?s=60&v=4){kind=small}
| @@ -0,0 +1 @@ | |||
| 3.2.0 | |||
There was a problem hiding this comment.
[NITPICK] Remove the leading whitespace so the file contains the Ruby version token exactly (e.g. "3.2.0"). Many Ruby version managers (rbenv, chruby, asdf) expect the file to contain the version string without surrounding spaces.
3.2.0
|
Reviewed up to commit:01567a06cef9181c86bc191a938b7190794992f7 Additional SuggestionOthers- Confirm this Ruby version is compatible with the sample project's native tooling (CocoaPods, fastlane, bundler) and with CI images. If you rely on a Gemfile/Gemfile.lock, ensure the Ruby version here matches any Ruby version specified there or document how contributors should select the Ruby version (rbenv/chruby/asdf). Consider adding the same .ruby-version at the repository root if CI and other parts of the repo need the same Ruby runtime. |
![codeant-ai[bot]](https://avatars.githubusercontent.com/in/646884?s=60&v=4){kind=small}
.cursor/rules/ios-native.mdc
Outdated
|
|
||
| ## Build | ||
|
|
||
| - Minimum iOS deployment target: 16.0. |
There was a problem hiding this comment.
Suggestion: The documented minimum iOS deployment target (16.0) conflicts with the actual podspec configuration, which declares iOS 11.0; this mismatch can mislead tools and developers (including Cursor itself) into using APIs that only exist on iOS 16+, causing runtime crashes or build failures for consumers targeting iOS 11–15. [logic error]
Severity Level: Major ⚠️
- ⚠️ Cursor rules misstate supported iOS version for native modules.
- ⚠️ Developers may introduce iOS16-only APIs into iOS11 projects.| - Minimum iOS deployment target: 16.0. | |
| - Minimum iOS deployment target: 11.0. |
Steps of Reproduction ✅
1. Open the podspec at `react-native-usercentrics.podspec:13` (in
`/workspace/react-native-sdk/react-native-usercentrics.podspec`) and observe `s.platform =
:ios, "11.0"`, which declares the library's minimum iOS version as 11.0.
2. Open the Cursor rules file at `.cursor/rules/ios-native.mdc:26` and observe the
documentation line `- Minimum iOS deployment target: 16.0.` indicating a minimum iOS
version of 16.0 for the same native module.
3. Compare these two configuration sources and note the direct contradiction: tooling and
developers reading `.cursor/rules/ios-native.mdc` will believe the minimum supported iOS
version is 16.0, while the actual build configuration via CocoaPods allows iOS 11.0.
4. In a real development workflow, a developer or AI assistant (Cursor) relying on
`.cursor/rules/ios-native.mdc` to guide native code changes for `ios/**/*.swift` and
`ios/**/*.mm` files can reasonably assume iOS 16.0 APIs are safe to use, even though
consumers building against the podspec's iOS 11.0 target would encounter compile-time or
runtime issues when those newer APIs are used on older devices.Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** .cursor/rules/ios-native.mdc
**Line:** 26:26
**Comment:**
*Logic Error: The documented minimum iOS deployment target (16.0) conflicts with the actual podspec configuration, which declares iOS 11.0; this mismatch can mislead tools and developers (including Cursor itself) into using APIs that only exist on iOS 16+, causing runtime crashes or build failures for consumers targeting iOS 11–15.
Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
Nitpicks 🔍
|
|
CodeAnt AI finished reviewing your PR. |
![qodo-code-review[bot]](https://avatars.githubusercontent.com/in/484649?s=60&v=4){kind=small}
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 4
🧹 Nitpick comments (1)
.cursorindexingignore (1)
35-37: Narrow indexing exclusions for core build/tooling files.
scripts/and Android Gradle config files are core project inputs, not generated artifacts. Ignoring them can reduce rule quality and produce weaker AI suggestions around build/test workflows.Suggested diff
# === Script files (utility, not core logic) === -scripts/ -sample/scripts/ +# Keep scripts indexable (used by CI/conventions) +# scripts/ +# sample/scripts/ # === Android generated === -android/build.gradle.kts -android/settings.gradle.kts -android/gradle.properties +# Keep root Android Gradle config indexable +# android/build.gradle.kts +# android/settings.gradle.kts +# android/gradle.propertiesAlso applies to: 46-48
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.cursorindexingignore around lines 35 - 37, The .cursorindexingignore currently excludes broad directories "scripts/" and "sample/scripts/" which hides core build/tooling files; update the ignore rules to narrow the scope (for example replace "scripts/" and "sample/scripts/" with more specific generated-artifact patterns such as "scripts/generated/" or "sample/scripts/generated/" or explicit filenames that are truly generated) or remove those lines entirely so Android Gradle config and other build scripts remain indexed; search for the exact strings "scripts/" and "sample/scripts/" in the .cursorindexingignore and apply the narrower patterns or deletion.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In @.cursor/rules/ci-github-actions.mdc:
- Line 31: The guidance text currently conflates major-version tags with
immutable pins; update the wording around the `@v1`, `@v2`, `@v4` examples to
state that these are mutable tags (they can be moved by maintainers) and
therefore are not equivalent to commit SHA pins, and explicitly recommend using
full commit SHAs for security-critical actions while noting that major-version
tags are acceptable for convenience/non-critical uses; reference the
`@v1/@v2/@v4` tokens and recommend “use full commit SHA (immutable) for
security-sensitive actions” as the replacement phrasing.
In @.cursor/rules/security-snyk.mdc:
- Line 13: Update the guidance text that currently states "Prefer `^` ranges in
`package.json` to allow patch updates" to correctly describe semver: explain
that `^` allows minor and patch updates within the same major version (e.g.,
`^1.2.3` => >=1.2.3 <2.0.0) and that `~` allows patch-only updates within the
same minor version (e.g., `~1.2.3` => >=1.2.3 <1.3.0`), replacing the incorrect
sentence referencing the `^` operator; ensure the revised line mentions both `^`
and `~` operators and their respective update scopes.
In @.cursor/rules/testing.mdc:
- Around line 24-27: The documentation lists unit and instrumented tests but
only provides the unit test command; add an explicit instrumented-test command
for clarity by appending the connected Android instrumentation command (e.g.,
./gradlew :react-native-usercentrics:connectedAndroidTest) alongside the
existing unit test command (./gradlew :react-native-usercentrics:test), and
optionally mention assembleAndroidTest or installDebug and connectedAndroidTest
for CI/use cases so readers can run instrumented tests reliably.
In @.cursor/rules/typescript-conventions.mdc:
- Around line 28-30: The documentation incorrectly states that the TurboModule
spec uses codegenNativeComponent; update the sentence that currently lists both
TurboModuleRegistry and codegenNativeComponent to remove codegenNativeComponent
so it only references TurboModuleRegistry (keep reference to the TurboModule
spec file NativeUsercentricsModule.ts for context).
---
Nitpick comments:
In @.cursorindexingignore:
- Around line 35-37: The .cursorindexingignore currently excludes broad
directories "scripts/" and "sample/scripts/" which hides core build/tooling
files; update the ignore rules to narrow the scope (for example replace
"scripts/" and "sample/scripts/" with more specific generated-artifact patterns
such as "scripts/generated/" or "sample/scripts/generated/" or explicit
filenames that are truly generated) or remove those lines entirely so Android
Gradle config and other build scripts remain indexed; search for the exact
strings "scripts/" and "sample/scripts/" in the .cursorindexingignore and apply
the narrower patterns or deletion.
ℹ️ Review info
Configuration used: defaults
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
sample/Gemfile.lockis excluded by!**/*.lock
📒 Files selected for processing (11)
.cursor/rules/android-native.mdc.cursor/rules/ci-github-actions.mdc.cursor/rules/ios-native.mdc.cursor/rules/project-overview.mdc.cursor/rules/react-native.mdc.cursor/rules/security-snyk.mdc.cursor/rules/testing.mdc.cursor/rules/typescript-conventions.mdc.cursorignore.cursorindexingignoresample/.ruby-version
| - The TurboModule spec lives in `src/fabric/NativeUsercentricsModule.ts`. | ||
| - It uses `TurboModuleRegistry` and `codegenNativeComponent`. | ||
| - Codegen config is in `package.json` under `codegenConfig`. |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
cat -n .cursor/rules/typescript-conventions.mdc | head -40Repository: Usercentrics/react-native-sdk
Length of output: 1530
🏁 Script executed:
rg -n 'TurboModuleRegistry|codegenNativeComponent|codegenNativeCommands' --type-list | head -5Repository: Usercentrics/react-native-sdk
Length of output: 462
🏁 Script executed:
fd -e ts -e tsx | xargs rg -l 'TurboModuleRegistry|codegenNativeComponent' | head -10Repository: Usercentrics/react-native-sdk
Length of output: 137
🌐 Web query:
React Native TurboModule codegenNativeComponent API difference official documentation
💡 Result:
-
What they are for
- TurboModules are for exposing imperative native APIs to JS (functions/constants) as a native module (e.g., storage, sensors). (reactnative.dev)
codegenNativeComponentis for exposing native UI views to JS as a Fabric native component (props + events mapped to a nativeViewManager/component view). (reactnative.dev)
-
JS “spec” shape / API surface
- TurboModule spec: you define an interface that extends
TurboModuleand you typically export it viaTurboModuleRegistry.getEnforcing<Spec>(...). (reactnative.dev) - Native component spec: you define a props interface (usually extending
ViewProps), and exportcodegenNativeComponent<Props>('NativeName')(often cast toHostComponent<Props>). (reactnative.dev)
- TurboModule spec: you define an interface that extends
-
Codegen detection conventions (important “difference” people hit)
- TurboModule spec files must be prefixed with
Native(example:NativeLocalStorage.ts). (reactnative.dev) - Fabric native component spec files must be suffixed with
NativeComponent(example:WebViewNativeComponent.ts). (reactnative.dev)
- TurboModule spec files must be prefixed with
-
Codegen configuration difference
- In
codegenConfig, you generally settype: "modules"for TurboModules andtype: "components"for Fabric components (or"all"for both). (reactnative.dev)
- In
Citations:
- 1: https://reactnative.dev/docs/turbo-native-modules-introduction?utm_source=openai
- 2: https://reactnative.dev/docs/0.76/fabric-native-components-introduction?utm_source=openai
- 3: https://reactnative.dev/docs/turbo-native-modules-introduction?utm_source=openai
- 4: https://reactnative.dev/docs/0.76/fabric-native-components-introduction?utm_source=openai
- 5: https://reactnative.dev/docs/0.76/the-new-architecture/using-codegen?utm_source=openai
- 6: https://reactnative.dev/docs/0.76/the-new-architecture/using-codegen?utm_source=openai
- 7: https://reactnative.dev/docs/0.82/the-new-architecture/using-codegen?utm_source=openai
🏁 Script executed:
cat -n src/fabric/NativeUsercentricsModule.tsRepository: Usercentrics/react-native-sdk
Length of output: 2195
🏁 Script executed:
cat -n package.json | grep -A 20 'codegenConfig'Repository: Usercentrics/react-native-sdk
Length of output: 329
Line 29 incorrectly lists codegenNativeComponent as part of TurboModule setup.
codegenNativeComponent is a Fabric Native Component API for UI views. The actual implementation uses only TurboModuleRegistry. Remove codegenNativeComponent from this line to prevent misleading developers on correct TurboModule patterns.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.cursor/rules/typescript-conventions.mdc around lines 28 - 30, The
documentation incorrectly states that the TurboModule spec uses
codegenNativeComponent; update the sentence that currently lists both
TurboModuleRegistry and codegenNativeComponent to remove codegenNativeComponent
so it only references TurboModuleRegistry (keep reference to the TurboModule
spec file NativeUsercentricsModule.ts for context).
.cursor/rules/android-native.mdc
Outdated
|
|
||
| ## Build | ||
|
|
||
| - Min SDK: 26 (Android 8.0). |
There was a problem hiding this comment.
our min sdk is 24 or 21 in legace, I guess we need to modify this
.cursor/rules/ios-native.mdc
Outdated
|
|
||
| ## Build | ||
|
|
||
| - Minimum iOS deployment target: 16.0. |
There was a problem hiding this comment.
same here, our deployment target is on iOS 11
|
CodeAnt AI is running Incremental review Thanks for using CodeAnt! 🎉We're free for open-source projects. if you're enjoying it, help us grow by sharing. Share on X · |
codeant-ai
bot
added
size:L
Sequence DiagramThis PR introduces repository level Cursor rule files and indexing ignore lists so contributor assistance follows project conventions while avoiding noisy or sensitive files. It also pins the sample Ruby version to keep CocoaPods setup consistent across local development and CI. sequenceDiagram
participant Contributor
participant CursorIDE
participant RuleFiles
participant Indexer
participant CI
Contributor->>CursorIDE: Open repository
CursorIDE->>RuleFiles: Load project and platform conventions
RuleFiles-->>CursorIDE: Return coding guidance
CursorIDE->>Indexer: Apply indexing ignore configuration
Indexer-->>CursorIDE: Exclude generated and sensitive files
Contributor->>CI: Create pull request
CI->>CI: Use pinned Ruby version for iOS setup
Generated by CodeAnt AI |
| @@ -0,0 +1,27 @@ | |||
| --- | |||
| description: Android native module conventions (Kotlin, Gradle) | |||
| globs: "android/**/*.kt,android/**/*.kts,android/**/*.java" | |||
There was a problem hiding this comment.
Suggestion: The rule describes JNI/C++ conventions, but its globs only match Kotlin/Java/Gradle files, so edits in android/src/main/jni/** will not receive this rule. Expand the glob to include C/C++ JNI files so the documented constraints are actually enforced where they matter. [logic error]
Severity Level: Major ⚠️
- ⚠️ JNI edits miss documented "do not hand-edit" guidance.
- ⚠️ Android-native conventions apply inconsistently across native source types.
- ⚠️ Cursor assistance may suggest changes violating JNI workflow.| globs: "android/**/*.kt,android/**/*.kts,android/**/*.java" | |
| globs: "android/**/*.kt,android/**/*.kts,android/**/*.java,android/src/main/jni/**/*.cpp,android/src/main/jni/**/*.c,android/src/main/jni/**/*.cc,android/src/main/jni/**/*.cxx,android/src/main/jni/**/*.h,android/src/main/jni/**/*.hpp" |
Steps of Reproduction ✅
1. Open `.cursor/rules/android-native.mdc` and confirm the rule scope at line 3 only
includes `android/**/*.kt,android/**/*.kts,android/**/*.java`.
2. In the same rule file, confirm JNI-specific constraints are documented at lines 12 and
20 (`src/main/jni/` structure and "do not hand-edit" guidance).
3. Open an actual JNI file that exists in this repo,
`android/src/main/jni/RNUsercentricsModule.cpp` (lines 1–18), which is outside the
configured glob extensions.
4. Observe that this Android-native rule does not match/apply to that `.cpp` file, so
JNI-specific guidance from `.cursor/rules/android-native.mdc` is not surfaced when editing
JNI sources.Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** .cursor/rules/android-native.mdc
**Line:** 3:3
**Comment:**
*Logic Error: The rule describes JNI/C++ conventions, but its `globs` only match Kotlin/Java/Gradle files, so edits in `android/src/main/jni/**` will not receive this rule. Expand the glob to include C/C++ JNI files so the documented constraints are actually enforced where they matter.
Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.|
|
||
| ### test-android (macOS 14) | ||
|
|
||
| - Java 17, Gradle 8.13, `./gradlew :react-native-usercentrics:test`. |
There was a problem hiding this comment.
Suggestion: The documented Android CI command does not match the real workflow, so contributors following this rule will run the wrong task and miss the actual coverage/reporting pipeline behavior used in CI. [logic error]
Severity Level: Major ⚠️
- ⚠️ Android contributor guidance mismatches real CI execution.
- ⚠️ Local validation misses Kover coverage-report generation.
- ⚠️ Debugging CI failures becomes slower and confusing.| - Java 17, Gradle 8.13, `./gradlew :react-native-usercentrics:test`. | |
| - Java 17, Gradle 8.13, `./gradlew :react-native-usercentrics:koverXmlReport :react-native-usercentrics:koverHtmlReport`. |
Steps of Reproduction ✅
1. Open contributor rule `.cursor/rules/ci-github-actions.mdc:24-27`; it instructs Android
CI command `./gradlew :react-native-usercentrics:test`.
2. Trace real CI path in `.github/workflows/ci.yml:131-163`; `test-android` executes
`./gradlew :react-native-usercentrics:koverXmlReport
:react-native-usercentrics:koverHtmlReport`.
3. Note downstream dependency at `.github/workflows/ci.yml:165-170`; artifact upload
expects Kover output directory `android/build/reports/kover/`.
4. A contributor following the rule command locally will run a different Gradle target
than CI, so local validation diverges from actual CI behavior.Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** .cursor/rules/ci-github-actions.mdc
**Line:** 26:26
**Comment:**
*Logic Error: The documented Android CI command does not match the real workflow, so contributors following this rule will run the wrong task and miss the actual coverage/reporting pipeline behavior used in CI.
Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.| - Always use `--frozen-lockfile` (yarn) or `npm ci` (npm) for deterministic installs. | ||
| - Major-version tags (`@v1`, `@v2`, `@v4`) are mutable — maintainers can move them. They are acceptable for convenience on non-critical actions, but use full commit SHA pins (immutable) for security-sensitive actions (e.g., `actions/checkout@<full-sha>`). | ||
| - Do not store secrets in workflow files. Use GitHub Secrets and reference via `${{ secrets.NAME }}`. | ||
| - Snyk scanning runs in the pipeline — ensure no new critical/high vulnerabilities are introduced. |
There was a problem hiding this comment.
Suggestion: This line states that Snyk scanning runs in CI, but there is no Snyk step in the current workflows, which creates a false security assumption and can allow vulnerabilities to slip through unnoticed. [security]
Severity Level: Critical 🚨
- ❌ Security guidance asserts non-existent CI vulnerability gate.
- ⚠️ Contributors may skip adding actual Snyk workflow step.
- ⚠️ Vulnerable dependencies can pass CI unchecked.| - Snyk scanning runs in the pipeline — ensure no new critical/high vulnerabilities are introduced. | |
| - Snyk scanning is not currently configured in the existing GitHub workflows; add and enforce a Snyk CI step before relying on this check. |
Steps of Reproduction ✅
1. Read `.cursor/rules/ci-github-actions.mdc:33`; it states Snyk scanning already runs in
pipeline.
2. Verify actual workflows list from `.github/workflows/` contains only `ci.yml` and
`release.yml`.
3. Inspect `.github/workflows/ci.yml:1-170` and `.github/workflows/release.yml:1-23`;
there is no `snyk` command/action/step.
4. Security assumption in the rule is therefore false for current CI, so contributors may
believe vulnerability gating exists when it does not.Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** .cursor/rules/ci-github-actions.mdc
**Line:** 33:33
**Comment:**
*Security: This line states that Snyk scanning runs in CI, but there is no Snyk step in the current workflows, which creates a false security assumption and can allow vulnerabilities to slip through unnoticed.
Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.| ## Build | ||
|
|
||
| - Minimum iOS deployment target: 11.0. | ||
| - CocoaPods managed via Bundler (`bundle exec pod install`). |
There was a problem hiding this comment.
Suggestion: The Bundler command is documented without the required working directory, but this repository's Gemfile is under sample/, not the repo root. Running bundle exec pod install from the wrong location will fail, so the rule should explicitly scope the command to sample/ios. [possible bug]
Severity Level: Major ⚠️
- ⚠️ iOS setup docs can fail for contributors.
- ⚠️ CocoaPods install flow becomes inconsistent with CI.
- ⚠️ Native development onboarding slows due to command errors.| - CocoaPods managed via Bundler (`bundle exec pod install`). | |
| - CocoaPods managed via Bundler from `sample/ios/` (`cd sample/ios && bundle exec pod install`). |
Steps of Reproduction ✅
1. Open `.cursor/rules/ios-native.mdc:27`; it documents `bundle exec pod install` without
a working directory.
2. Verify repository Ruby setup: only `sample/Gemfile` exists
(`/workspace/react-native-sdk/sample/Gemfile:1`), no root Gemfile.
3. From repo root (`/workspace/react-native-sdk`), run the documented command exactly;
Bundler resolves Gemfile from current/parent path and cannot use project gems.
4. Confirm intended path from CI: `.github/workflows/ci.yml:84-94` runs `bundle install`
in `./sample` and `bundle exec pod install` in `./sample/ios`, showing the command is
directory-scoped in real usage.Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** .cursor/rules/ios-native.mdc
**Line:** 27:27
**Comment:**
*Possible Bug: The Bundler command is documented without the required working directory, but this repository's `Gemfile` is under `sample/`, not the repo root. Running `bundle exec pod install` from the wrong location will fail, so the rule should explicitly scope the command to `sample/ios`.
Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.|
|
||
| - Tests live in `sample/ios/sampleTests/`. | ||
| - Written in Swift, targeting the sample app scheme. | ||
| - Run via `xcodebuild test` against `sample.xcworkspace`. |
There was a problem hiding this comment.
Suggestion: The iOS test command is incomplete and will fail if copied as-is because xcodebuild test requires at least a scheme and destination. Align this line with the actual CI invocation by including -workspace, -scheme, and simulator destination arguments so contributors can run tests successfully. [logic error]
Severity Level: Major ⚠️
- ⚠️ Cursor rule conflicts with CI iOS test invocation.
- ⚠️ Contributors may hit failing local iOS test runs.
- ❌ iOS test setup requires manual command troubleshooting.| - Run via `xcodebuild test` against `sample.xcworkspace`. | |
| - Run via `xcodebuild -workspace sample.xcworkspace -scheme sample -destination 'platform=iOS Simulator,OS=latest,name=iPhone 16 Pro' test`. |
Steps of Reproduction ✅
1. Open `.cursor/rules/testing.mdc:20`; copy the documented iOS command `xcodebuild test`.
2. From `sample/ios` (CI uses this working directory at `.github/workflows/ci.yml:101`),
execute that copied command.
3. Compare with the real CI invocation at `.github/workflows/ci.yml:104-111`, which
explicitly passes `-workspace sample.xcworkspace`, `-scheme "sample"`, and simulator
`-destination`.
4. Because the rule omits those targeting flags, contributors/Cursor-generated
instructions can run with missing context and commonly fail or run unintended targets,
unlike CI's deterministic command.Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** .cursor/rules/testing.mdc
**Line:** 20:20
**Comment:**
*Logic Error: The iOS test command is incomplete and will fail if copied as-is because `xcodebuild test` requires at least a scheme and destination. Align this line with the actual CI invocation by including `-workspace`, `-scheme`, and simulator destination arguments so contributors can run tests successfully.
Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
|
CodeAnt AI Incremental review completed. |
3 participants
User description
Created multiple cursor rules for them to be used as a first basis
Summary by CodeRabbit
CodeAnt-AI Description
Add cursor AI rules, repository ignores, and CI/native contribution guidance
What Changed
Impact
✅ Clearer native contribution guidelines✅ Fewer accidental commits of build artifacts and secrets✅ Fewer CI surprises from mismatched local setups💡 Usage Guide
Checking Your Pull Request
Every time you make a pull request, our system automatically looks through it. We check for security issues, mistakes in how you're setting up your infrastructure, and common code problems. We do this to make sure your changes are solid and won't cause any trouble later.
Talking to CodeAnt AI
Got a question or need a hand with something in your pull request? You can easily get in touch with CodeAnt AI right here. Just type the following in a comment on your pull request, and replace "Your question here" with whatever you want to ask:
This lets you have a chat with CodeAnt AI about your pull request, making it easier to understand and improve your code.
Example
Preserve Org Learnings with CodeAnt
You can record team preferences so CodeAnt AI applies them in future reviews. Reply directly to the specific CodeAnt AI suggestion (in the same thread) and replace "Your feedback here" with your input:
This helps CodeAnt AI learn and adapt to your team's coding style and standards.
Example
Retrigger review
Ask CodeAnt AI to review the PR again, by typing:
Check Your Repository Health
To analyze the health of your code repository, visit our dashboard at https://app.codeant.ai. This tool helps you identify potential issues and areas for improvement in your codebase, ensuring your repository maintains high standards of code health.