Jon/cursor rules

.cursor/rules/jsx-props.mdc

@@ -0,0 +1,4 @@
+---
+description: JSX props shouldn't use inline arrow functions, but utilize `useHandler` appropriately.
+alwaysApply: false
+---

.cursor/rules/package-safety.mdc

@@ -0,0 +1,4 @@
+---
+description: Before installing a package, read the npm or github page first to check if there is anything suspicious: first publish date, I in place of L, number of stars, etc. Respond with a link to the package first, and wait for user confirmation to install.
+alwaysApply: false
+---

.cursor/rules/strings.mdc

@@ -0,0 +1,4 @@
+---
+description: String literals should always be defined in and referenced from @en_us.ts
+alwaysApply: false
+---

.gitignore

@@ -127,3 +127,6 @@ yarn-error.log
 !.yarn/releases
 !.yarn/sdks
 !.yarn/versions
+
+# Agents
+AGENTS.md

README.md

@@ -166,6 +166,48 @@ As with any modern React Native app, [Flipper](https://fbflipper.com/) is the of
 
 If you want to inspect Redux, you can install the [redux-debugger](https://github.com/jk-gan/flipper-plugin-redux-debugger) plugin for Flipper, which this app supports.
 
+## Suggested Agentic Coding Rules
+
+The following rules are suggested to reduce friction during agentic development and align with Edge's coding best practices. Some which are specific to this repo are already included in Cursor-specific `.mdc` files, and most are appropriate to set as global rules (Cursor "User Rules," AGENTS.md, etc) across all Edge organization repositories.
+
+### Code and TypeScript rules
+
+- JSX props shouldn't use inline arrow functions. Create handlers appropriately.
+- Use ?? instead of || for default values. ?? only treats null/undefined as missing, || treats all falsy values as missing:
+❌ value || defaultValue → ✅ value ?? defaultValue
+❌ config.timeout || 5000 → ✅ config.timeout ?? 5000 (preserves 0)
+❌ user.name || 'Anonymous' → ✅ user.name ?? 'Anonymous' (preserves '')
+❌ settings.enabled || true → ✅ settings.enabled ?? true (preserves false)"
+- NEVER use optional chaining results directly in conditions:
+❌ `if (obj?.prop)` → ✅ `if (obj?.prop != null)`
+❌ `if (obj?.arr?.length > 0)` → ✅ `if (obj?.arr != null && obj.arr.length > 0)`
+❌ `if (response?.data)` → ✅ `if (response?.data != null)`
+- Component exports for any modified files should follow the form: `export const Component: React.FC<Props> = (props: Props) => {`
+- String literals should always be defined in and referenced from @en_us.ts
+
+### Workflow and execution
+
+- Background tasks (yarn dev, yarn start, etc) should be checked if running before attempting to start. Don't run these types of background tasks unless explicitly asked to do so.
+- After completing code changes, run `yarn tsc` and fix any errors. Once those are addressed, run `files=($(git diff HEAD --name-only -- '*.ts' '*.tsx')); if (( ${#files} )); then ./node_modules/.bin/eslint --fix "${files[@]}"; else echo "No TS/TSX changes since HEAD."; fi` after your changes, and manually fix any non-deprecation warnings that cannot be automatically fixed, if necessary. It is not necessary to fix any lint warnings/errors on files that you did not modify yourself.
+- Multi-phase plans should always be done one phase at a time before stopping and asking for feedback.
+- Never start work when I mention "Come up with a plan" or similar. Such a request is literally to come back with a textual plan.
+- Before using any code editing tools (edit_file, search_replace, etc.), scan my entire message for questions (?). If ANY exist, you MUST answer all questions first without making code changes. Only proceed with implementation after I permit you to in a follow-up message.
+
+### Research and external dependencies
+
+- Before installing a package, read the npm or github page first to check if there is anything suspicious: first publish date, I in place of L, number of stars, etc. Respond with a link to the package first, and wait for user confirmation to install.
+- RESEARCH FIRST: Before implementing external APIs or libraries, you MUST either quote provided documentation or actively search for official documentation using available tools. Always explicitly state 'According to [source]...' when making implementation decisions. If documentation searches are incomplete or missing critical details: 1. STOP implementation immediately 2. ASK: 'I found [what I found] but need [specific missing details]. Would you like me to search more thoroughly, or can you provide the documentation?' 3. WAIT for user guidance before proceeding"
+
+### Communication
+
+- ALWAYS respond with a neutral tone, without fluff like "Certainly!" or "Perfect." NEVER apologize, but state your understanding of mistakes.
+- CRITICAL: User is human and prone to mistakes. 1. Suggest better approaches if you can think of them before implementing prompted suboptimal solutions. Bring these up as suggestions to yes/no confirm by the user before actually implementing them. 2. Ask for clarification when prompt/question/task is unclear or ambiguous 3. Notify user: if technical inaccuracies present, better alternative approaches/patterns exist, best practices contradicted, edge cases missed, or inconsistencies are found against the code base.
+
+### Documentation
+
+- Update the CHANGELOG with at most a few new entries for the changes made in the current branch, if requested. Entries should ONLY describe the final state of all the current branch changes, NOT the journey or internal conversations, and follow the existing patterns for length and formatting (including no word wrapping).
+- Code comments should ONLY describe the final state of the branch changes, NOT the journey or internal conversations
+
 ## Contributing
 
 Please follow the coding conventions defined in [Edge Conventions](https://github.com/Airbitz/edge-conventions)