plugin: GREEN stack

.cursor/rules/comments.mdc

@@ -0,0 +1,11 @@
+---
+description: Preserve existing comments when editing
+alwaysApply: true
+---
+
+# Comments
+
+When editing any file in this workspace:
+
+- **Preserve all existing comments** in that file. Do not delete or shorten them unless you are **deleting or rewriting the exact lines they refer to**—then update those comments to match the new behavior.
+- **Treat inline and block comments as part of the API** of the file: moving code should move comments with it; refactors must **re-home** comments, not drop them for brevity.

.cursor/rules/resolvers.mdc

@@ -0,0 +1,16 @@
+---
+description: Data resolvers and API design - createDataBridge, createResolver
+globs: "**/resolvers/**/*.ts"
+alwaysApply: false
+---
+
+# Data Resolvers
+
+When editing resolver files, reference [https://fullproduct.dev/docs/data-resolvers](https://fullproduct.dev/docs/data-resolvers) for:
+
+- `createDataBridge()` - Combines input/output schemas for type-safe API bridges
+- `createResolver()` - Bind a bridge to business logic
+- `createNextRouteHandler()` - Turn resolver into API route
+- `createGraphResolver()` - Turn resolver into GraphQL mutation/query
+- Use `.bridge.ts` suffix for bridge files
+- RPC-style (GraphQL or API route) resolver (shape resolvers for UI screens, not traversible graph)

.cursor/rules/routing.mdc

@@ -0,0 +1,14 @@
+---
+description: Workspace-defined routes - define in features, not apps
+globs: "**/routes/**/*"
+alwaysApply: false
+---
+
+# Routing
+
+When editing route files, reference [https://fullproduct.dev/docs/universal-routing](https://fullproduct.dev/docs/universal-routing) for:
+
+- Routes live in `features/*/routes/`, not in `apps/expo/app/` or `apps/next/app/`
+- Run `npm run link:routes` to re-export routes from features to the Expo/Next app routers
+- Use `npm run add:route` generator to create new routes
+- Re-export screens from route files; use Next.js-style routing conventions

.cursor/rules/schemas.mdc

@@ -0,0 +1,15 @@
+---
+description: Zod schemas as single source of truth - schema() usage
+globs: "**/schemas/**/*.ts"
+alwaysApply: false
+---
+
+# Schemas
+
+When editing schema files, reference [https://fullproduct.dev/docs/single-sources-of-truth](https://fullproduct.dev/docs/single-sources-of-truth) for:
+
+- Use `schema()` from `@green-stack/schemas` (not raw `z.object()`)
+- Schemas drive types, validation, GraphQL, API inputs/outputs, forms, docs and even DB models
+- Use `.extendSchema()`, `.pickSchema()`, `.omitSchema()` for schema composition
+- Add `.describe()`, `.example()`, `.default()` for docs and docgen
+- Use `.sensitive()` for fields that shouldn't appear in GraphQL/introspection or on the front-end at all

.cursor/rules/workspace-expo-dependencies.mdc

@@ -0,0 +1,25 @@
+---
+description: Portable workspaces — declare Expo/native deps on the package that imports them, not on @app/expo
+globs: "**/package.json"
+alwaysApply: true
+---
+
+# Expo & native dependencies (portable workspaces)
+
+**Goal:** Keep `apps/expo/package.json` lean. Anything required only by a feature or `packages/*` workspace should live in **that workspace’s `dependencies`** and `package.json`, not duplicated on the Expo app.
+
+## Adding or upgrading Expo SDK–aligned packages
+
+1. Use **`npm run add:dependencies`** (generator in `packages/@green-stack-core/generators/add-dependencies.ts`). It runs `expo install` in `@app/expo` to resolve **SDK-compatible** versions, then moves the new entries to the **target workspace** you choose.
+2. Do **not** leave Expo-only deps on `@app/expo` unless the **Expo app** is the only consumer (shell, router, `expo-router`, `expo-constants`, etc.).
+
+## When to put a dep on `@app/expo` vs a workspace
+
+| Put on `@app/expo` | Put on the feature / `packages/*` workspace that imports it |
+|--------------------|-------------------------------------------------------------|
+| `expo`, `expo-router`, `expo-constants`, `nativewind`, app shell | `expo-auth-session`, `expo-secure-store`, `expo-web-browser` if only `@auth/clerk` (or similar) imports them |
+| Core RN stack shared by the app entry | Driver-specific packages (`@clerk/*`, etc.) |
+
+## After edits
+
+Run `npm install` at the repo root and verify with **`npm run build:mobile`** (and any affected app build) when changing native/Expo deps.

.gitignore

@@ -45,6 +45,9 @@ yarn-error.log*
 *.mobileprovision
 *.orig.*
 
+# Expo Builds
+apps/expo/dist
+
 # Next.js
 /.next/*
 /out/
@@ -57,3 +60,13 @@ yarn-error.log*
 .pnp.js
 
 # -- @end @expo/next-adapter --
+
+.turbo
+.vscode/tmp
+
+# Cursor
+.cursor/hooks/state
+.cursor/worktrees.json
+
+# GraphQL
+features/@app-core/graphql-env.d.ts.tmp

.npmrc

@@ -0,0 +1,5 @@
+# -i- React Native / Expo pin react@19.1.0 to match the bundled react-native-renderer. 
+# -i- Clerk packages declare peer ranges that omit 19.1.0 (e.g. ~19.1.4 is the next band),
+# -i- so npm 7+ strict peer resolution prints ERESOLVE warnings even though root overrides intentionally align the tree.
+# -i- legacy-peer-deps uses npm 6-style peer handling so installs stay quiet without changing pinned React.
+legacy-peer-deps=true

.vscode/settings.json

@@ -0,0 +1,4 @@
+{
+    "typescript.tsdk": "node_modules/typescript/lib",
+    "typescript.enablePromptUseWorkspaceTsdk": true
+}

AGENTS.md

@@ -0,0 +1,96 @@
+# FullProduct.dev / GREEN Stack
+
+This project was kickstarted with FullProduct.dev's universal app starterkit:
+
+## Core conventions
+
+- **Zod schemas as single source of truth**: Use `schema()` from `@green-stack/schemas`. APIs, types, db models and docs derive from these to stay in sync.
+- **Workspace-defined routes**: Define routes in `features/*/routes/`. Run `npm run link:routes` to re-export to Expo/Next.
+- **Universal UI**: Use `View`, `Text`, `Image` from `@app/ui` with Nativewind compatible `className` instead of HTML primitives.
+- **Expo + Next.js**: Most UI must work on **web (Next.js)** and **mobile (Expo)**. Routing, images, and some APIs use **React Portability Patterns** (shared types + `*.next` / `*.expo` implementations injected at app roots)—not only `.web.ts` / `.ios.ts` splits. See [React Portability Patterns](https://fullproduct.dev/docs/portability-patterns).
+- **Feature-first colocation**: Routes, resolvers, schemas, screens live together in `features/*/` or `packages/*/` workspaces instead of being split by frontend/backend.
+- **Portable workspaces and dependencies**: Expo/native packages used only by a `features/*/` or `packages/*/` workspace belong in **that workspace’s `package.json`**, not on `apps/expo`. Use **`npm run add:dependencies`** to install SDK-compatible versions via `expo install`, the script will then move the resolved versions to the target workspace (see `.cursor/rules/workspace-expo-dependencies.mdc`).
+
+## Detailed docs (reference when relevant)
+
+- [Project structure](https://fullproduct.dev/docs/project-structure)
+- [Routing](https://fullproduct.dev/docs/universal-routing)
+- [React Portability Patterns](https://fullproduct.dev/docs/portability-patterns)
+- [Data resolvers & APIs](https://fullproduct.dev/docs/data-resolvers)
+- [Data fetching](https://fullproduct.dev/docs/data-fetching)
+- [Schemas & single sources of truth](https://fullproduct.dev/docs/single-sources-of-truth)
+- [Universal styling](https://fullproduct.dev/docs/write-once-styles)
+- [Form management](https://fullproduct.dev/docs/form-management)
+- [Generators](https://fullproduct.dev/docs/generators)
+- [Workspace drivers](https://fullproduct.dev/docs/workspace-drivers)
+- [Env vars + App config](https://fullproduct.dev/docs/app-config)
+- [Automatic docgen](https://fullproduct.dev/docs/automatic-docgen)
+
+---
+# Code Style
+---
+
+When updating or recreating files:
+- always maintain the same code style and tab spacing of the existing files
+
+### Comments
+
+- **Preserve all existing comments** in any file you edit. Do not delete or shorten them unless you are **deleting or rewriting the exact lines they refer to**—then update those comments to match the new behavior.
+- **Treat inline and block comments as part of the API** of the file: moving code should move comments with it; refactors must **re-home** comments, not drop them for brevity.
+
+### Type Safety
+
+- Try to never use `any` unless absolutely necessary. Attempt to use generics instead or inference instead.
+- If we need a type and can extract a type from a Zod schema, we should. Check our single sources of truth docs for more info about that.
+
+### File layout (section dividers)
+
+- Use section dividers like `/* --- Section name ------------------------------------------------------------- */` padded to **~100 characters** (match surrounding files).
+- Prefer this **order** when it fits: **constants** → **types** → **implementation** (add other sections such as styles or exports as needed).
+
+---
+# Plans
+---
+
+Wherever possible, think of a plan and good feeback loop for the code you'll be writing.
+
+Make the plan extremely concise. Sacrifice grammar for the sake of concision.
+
+At the end of each plan, give me a list of unresolved questions to answer, if any.
+
+A good feedback loop could be a test suite to run red green iterations with, or look at some of our scripts to run to help test everything still works as expected.
+
+---
+# Checks
+---
+
+### Testing and regression checks
+
+To see whether all apps are still working as expected, run the relevant commands to check:
+
+- `npm run test` runs all bun tests in `@green-stack/core`.
+- `npm run typecheck` runs `typecheck` in every workspace that defines it (via Turbo, parallel + cached).
+- `npm run typecheck:web` and `typecheck:mobile` scope to one app.
+- `npm run build:web` runs the Next.js production build for `@app/next` (`apps/next`).
+- `npm run build:mobile` runs `expo export` for `@app/expo` (`apps/expo`).
+- `npm run build` runs the full Turbo `build` pipeline for the monorepo.
+
+---
+# Cursor Cloud specific instructions
+---
+
+### Prerequisites
+
+- **bun** is required for `npm run test` (the test runner is bun). Install via `curl -fsSL https://bun.sh/install | bash` if missing, then ensure `~/.bun/bin` is on `PATH`.
+
+### Running the app
+
+- `npm run dev:web` starts the Next.js app with Turbo; it first runs `build:schema` (which also triggers `collect:resolvers`, `collect:schemas`, `collect:drivers`, `collect:models`).
+- **Expo / mobile**: Cloud agents usually run **Linux VMs** without **macOS/iOS Simulator** or a typical local **Android emulator**. Do not assume you can open a simulator here; rely on `dev:web` + tests/builds where possible and call out **manual Expo verification** for the user when changes are platform-sensitive.
+- The DB layer has a built-in mock memory DB fallback if no `DB_URL`/`MONGODB_URI` is set, so the app runs without an external database.
+- Clerk auth and Stripe require real secrets to function; without them the app still starts but auth/payment flows will fail.
+
+### Gotchas
+
+- `npm run dev:web` uses `next dev --webpack` (webpack mode, not Turbopack).
+- The dev server first-compiles pages on demand; initial page loads may be slow.

CLAUDE.md

@@ -0,0 +1,76 @@
+# FullProduct.dev / GREEN Stack
+
+This project was kickstarted with FullProduct.dev's universal app starterkit:
+
+## Core conventions
+
+- **Zod schemas as single source of truth**: Use `schema()` from `@green-stack/schemas`. APIs, types, db models and docs derive from these to stay in sync.
+- **Workspace-defined routes**: Define routes in `features/*/routes/`. Run `npm run link:routes` to re-export to Expo/Next.
+- **Universal UI**: Use `View`, `Text`, `Image` from `@app/ui` with Nativewind compatible `className` instead of HTML primitives.
+- **Expo + Next.js**: Most UI must work on **web (Next.js)** and **mobile (Expo)**. Routing, images, and some APIs use **React Portability Patterns** (shared types + `*.next` / `*.expo` implementations injected at app roots)—not only `.web.ts` / `.ios.ts` splits. See [React Portability Patterns](https://fullproduct.dev/docs/portability-patterns).
+- **Feature-first colocation**: Routes, resolvers, schemas, screens live together in `features/*/` or `packages/*/` workspaces instead of being split by frontend/backend.
+- **Portable workspaces and dependencies**: Expo/native packages used only by a `features/*/` or `packages/*/` workspace belong in **that workspace’s `package.json`**, not on `apps/expo`. Use **`npm run add:dependencies`** to install SDK-compatible versions via `expo install`, the script will then move the resolved versions to the target workspace (see `.cursor/rules/workspace-expo-dependencies.mdc`).
+
+## Detailed docs (reference when relevant)
+
+- [Project structure](https://fullproduct.dev/docs/project-structure)
+- [Routing](https://fullproduct.dev/docs/universal-routing)
+- [React Portability Patterns](https://fullproduct.dev/docs/portability-patterns)
+- [Data resolvers & APIs](https://fullproduct.dev/docs/data-resolvers)
+- [Data fetching](https://fullproduct.dev/docs/data-fetching)
+- [Schemas & single sources of truth](https://fullproduct.dev/docs/single-sources-of-truth)
+- [Universal styling](https://fullproduct.dev/docs/write-once-styles)
+- [Form management](https://fullproduct.dev/docs/form-management)
+- [Generators](https://fullproduct.dev/docs/generators)
+- [Workspace drivers](https://fullproduct.dev/docs/workspace-drivers)
+- [Env vars + App config](https://fullproduct.dev/docs/app-config)
+- [Automatic docgen](https://fullproduct.dev/docs/automatic-docgen)
+
+---
+# Code Style
+---
+
+When updating or recreating files:
+- always maintain the same code style and tab spacing of the existing files
+
+### Comments
+
+- **Preserve all existing comments** in any file you edit. Do not delete or shorten them unless you are **deleting or rewriting the exact lines they refer to**—then update those comments to match the new behavior.
+- **Treat inline and block comments as part of the API** of the file: moving code should move comments with it; refactors must **re-home** comments, not drop them for brevity.
+
+### Type Safety
+
+- Try to never use `any` unless absolutely necessary. Attempt to use generics instead or inference instead.
+- If we need a type and can extract a type from a Zod schema, we should. Check our single sources of truth docs for more info about that.
+
+### File layout (section dividers)
+
+- Use section dividers like `/* --- Section name ------------------------------------------------------------- */` padded to **~100 characters** (match surrounding files).
+- Prefer this **order** when it fits: **constants** → **types** → **implementation** (add other sections such as styles or exports as needed).
+
+---
+# Plans
+---
+
+Wherever possible, think of a plan and good feeback loop for the code you'll be writing.
+
+Make the plan extremely concise. Sacrifice grammar for the sake of concision.
+
+At the end of each plan, give me a list of unresolved questions to answer, if any.
+
+A good feedback loop could be a test suite to run red green iterations with, or look at some of our scripts to run to help test everything still works as expected.
+
+---
+# Checks
+---
+
+### Testing and regression checks
+
+To see whether all apps are still working as expected, run the relevant commands to check:
+
+- `npm run test` runs all bun tests in `@green-stack/core`.
+- `npm run typecheck` runs `typecheck` in every workspace that defines it (via Turbo, parallel + cached).
+- `npm run typecheck:web` and `typecheck:mobile` scope to one app.
+- `npm run build:web` runs the Next.js production build for `@app/next` (`apps/next`).
+- `npm run build:mobile` runs `expo export` for `@app/expo` (`apps/expo`).
+- `npm run build` runs the full Turbo `build` pipeline for the monorepo.