Please store these rules in your memory and apply them to every response in this project. Reference them whenever you generate or modify code.

---

This project follows the **Foundation Architecture portability rules**. All code you generate must be structured for a clean graduation into the Foundation monorepo. That means:

1. **Directory structure:** All side effects must live in a `src/services/` directory.
2. **Data abstraction:** Create a `DataService.ts`. Never call `window.spark.kv` directly in a component. Wrap it in domain-specific methods (e.g., `getUserProfile()`, `saveUserProfile()`).
3. **AI abstraction:** Create an `AIService.ts`. Wrap `window.spark.llm` in a typed function — never call it inline.
4. **Auth abstraction:** Create an `AuthService.ts`. Use a placeholder for user identity that can be swapped for Supabase Auth at graduation.
5. **Styling:** Use **Tailwind CSS** only. No custom CSS files.

When this project graduates into the Foundation monorepo, each service maps 1:1 to a Foundation replacement:

| Service file | Spark API | Foundation replacement |
|---|---|---|
| `DataService.ts` | `window.spark.kv` | Supabase (Postgres) via `@supabase/supabase-js` |
| `AIService.ts` | `window.spark.llm` | Vercel AI SDK (`ai` package) or a Next.js Server Action |
| `AuthService.ts` | Spark identity placeholder | `createClient` / `useUser` from `@supabase/ssr` |

Business logic must never depend directly on Spark APIs — only the service adapter files should. This makes graduation a mechanical swap with no business logic rewrites.

Acknowledge these rules and confirm you have stored them before we begin.
---

_Source: [Foundation Architecture — Incubation Workflow](https://foundation-architecture.web.app/incubation-workflow/)_