# React Native + Express Expert Engineering Rules

  ## Pacing and Scope Control
  1. **Explicit Checkpoint Requirements**
     - Pause after completing each logical unit of work. Wait for explicit approval before continuing.
     - Never implement more than one feature/task in a single session without confirmation.
  2. **Minimalist Implementation**
     - Implement only the minimum required for each specified task; prefer a narrower interpretation if unclear.
  3. **Staged Development Protocol**
     - Use a 'propose → approve → implement → review' cycle for every change.
     - After each component or API endpoint, summarize changes and next steps before proceeding.
  4. **Scope Boundary Enforcement**
     - If implementation requires changes outside initial scope/files, pause and seek approval.
     - Avoid "while I'm at it" improvements unless approved in advance.

  ## Communication Protocols
  1. **Mandatory Checkpoints**
     - After every change, summarize what’s complete and what’s planned next. Mark done items as [COMPLETE].
  2. **Complexity Warnings**
     - If more than 3 files are affected or any [MAJOR] change is needed (>20 lines), flag as [COMPLEX CHANGE] and request explicit confirmation.
  3. **Change Magnitude Indicators**
     - Mark changes as [MINOR] (1–5 lines), [MODERATE] (6–20 lines), [MAJOR] (20+ lines), and provide implementation plan for major changes.
  4. **Testability Focus**
     - Pause at earliest point where new logic can be tested. Wait for confirmation before proceeding past test checkpoints.

  ## Build & Development Commands
  - Use npm (or yarn) scripts for all build, start, and test processes. Document key commands (`npm run dev`, `npm run build`, etc.) in README.
  - Use .env files for sensitive or environment-specific config. Never commit .env to version control.

  ## Project Structure
  - For React Native: Use modular folders (`components/`, `screens/`, `contexts/`, `utils/`, `services/`).
  - For Express: Organize with `controllers/`, `routes/`, `middlewares/`, `repositories/`, and `models/`.
  - Adapt to existing structure; don’t force changes if the project organization is already established.

  ## Coding Guidelines & Style
  - Always use TypeScript on both frontend and backend.
  - Use functional React components with Hooks; avoid class components.
  - Leverage Context API or Redux/Zustand for global state management.
  - Use Prettier and ESLint (prefer Airbnb config) for formatting/linting. Run on every commit using Husky/lint-staged.
  - Naming: camelCase for functions/variables, PascalCase for components, kebab-case for files.
  - Add JSDoc/TSDoc/type comments for exported functions/classes as needed.
  - Keep components/widgets and API handlers small, focused, and composable.

  ## Testing Guidelines
  - Write unit tests for functions and business logic (Jest for backend and frontend).
  - Use React Native Testing Library for UI components; use Supertest for API endpoints.
  - Ensure at least 80% test coverage for critical code paths; flag gaps during review.
  - Practice proper mocking and stubbing in tests; use CI pipelines to run tests on every PR.

  ## Documentation Guidelines
  - Maintain up-to-date OpenAPI/Swagger docs for backend APIs.
  - Keep README.md current: setup, build/test instructions, architecture notes, troubleshooting.
  - For shared code (hooks, utilities), provide example usages in README or as inline code comments.

  ## Security Guidelines
  - Store sensitive data using secure storage solutions (on-device & server-side).
  - Implement proper API auth with JWT.
  - Sanitize & validate all inputs on both client and server; prevent XSS, CSRF, and injection vulnerabilities.
  - Never expose secrets or sensitive data in source code or logs.

  ## Performance & Accessibility Guidelines
  - Optimize React Native rendering: use memoization and avoid unnecessary re-renders.
  - Paginate and cache API responses when appropriate; optimize indexes for DB queries.
  - Follow accessibility best practices for all interactive UI elements.
  - Minimize bundle and API payload sizes; enable compression where possible.

  ## Flexibility Notice
  These are recommended standards. If a project’s architecture or process clearly conflicts, adapt the above to remain consistent with local/project conventions—while maintaining best practices