Flutter + Firebase rules for AI coding agents

# AGENTS.md - this project

Instructions for AI coding agents working in this repository.

## Project

A Flutter (Dart) + Firebase project.

Stack: Flutter (Dart), Firebase.

## Commands

- Run: `flutter run`
- Analyze: `flutter analyze`
- Tests: `flutter test`
- Format: `dart format .`
- Local emulators: `firebase emulators:start`
- Deploy rules only: `firebase deploy --only firestore:rules`

## Project structure

- Feature folders under `lib/features/<name>/` with widgets, state and data layers.

## How to work in this repo

- Read the relevant files before editing. Follow the patterns already in the codebase over these generic rules.
- Make the smallest change that solves the task. Do not refactor or reformat unrelated code.
- Before saying a task is done, run the type-check, lint and tests listed under Commands and fix what you broke.
- If requirements are ambiguous, ask one clear question instead of guessing.
- Never commit secrets, API keys or `.env` files. Use env vars and keep `.env.example` up to date.
- Do not add a new dependency when the standard library or an existing dependency already covers it.
- Ask before adding, removing or upgrading any dependency.
- Ask before changing database schemas, auth, payments or CI configuration.
- Never delete files, drop data or run destructive commands (`rm -rf`, `git push --force`, `DROP TABLE`) without explicit approval.
- Keep each change under ~200 changed lines where possible; split larger work into steps.

## Flutter (Dart)

- Code must pass `flutter analyze` with no warnings.
- Use `const` constructors wherever possible.
- Split large `build` methods into small widgets, not helper methods returning widgets.
- Use the state management already in the project (Riverpod, Bloc, Provider). Do not introduce a second one.
- Check `mounted` before using `BuildContext` after an `await`.
- Add packages with `flutter pub add`; prefer well-maintained packages from pub.dev.
- Never hardcode API secrets in the app bundle.

## Firebase

- Firebase web config is public by design; security comes from Firestore/Storage Security Rules. Never ship `allow read, write: if true`.
- Every collection needs rules that check `request.auth` and validate the written fields.
- Admin SDK credentials are server-only (Cloud Functions or your backend).
- Model Firestore data for your queries: avoid deeply nested data and unbounded arrays; denormalize deliberately.
- Test rules and functions against the Emulator Suite, not production.

## Reference docs

- [Flutter docs](https://docs.flutter.dev)
- [Firebase docs](https://firebase.google.com/docs)

# CLAUDE.md - this project

Project instructions for Claude Code.

## Project

A Flutter (Dart) + Firebase project.

Stack: Flutter (Dart), Firebase.

## Commands

- Run: `flutter run`
- Analyze: `flutter analyze`
- Tests: `flutter test`
- Format: `dart format .`
- Local emulators: `firebase emulators:start`
- Deploy rules only: `firebase deploy --only firestore:rules`

## Project structure

- Feature folders under `lib/features/<name>/` with widgets, state and data layers.

## How to work in this repo

- Read the relevant files before editing. Follow the patterns already in the codebase over these generic rules.
- Make the smallest change that solves the task. Do not refactor or reformat unrelated code.
- Before saying a task is done, run the type-check, lint and tests listed under Commands and fix what you broke.
- If requirements are ambiguous, ask one clear question instead of guessing.
- Never commit secrets, API keys or `.env` files. Use env vars and keep `.env.example` up to date.
- Do not add a new dependency when the standard library or an existing dependency already covers it.
- Ask before adding, removing or upgrading any dependency.
- Ask before changing database schemas, auth, payments or CI configuration.
- Never delete files, drop data or run destructive commands (`rm -rf`, `git push --force`, `DROP TABLE`) without explicit approval.
- Keep each change under ~200 changed lines where possible; split larger work into steps.

## Flutter (Dart)

- Code must pass `flutter analyze` with no warnings.
- Use `const` constructors wherever possible.
- Split large `build` methods into small widgets, not helper methods returning widgets.
- Use the state management already in the project (Riverpod, Bloc, Provider). Do not introduce a second one.
- Check `mounted` before using `BuildContext` after an `await`.
- Add packages with `flutter pub add`; prefer well-maintained packages from pub.dev.
- Never hardcode API secrets in the app bundle.

## Firebase

- Firebase web config is public by design; security comes from Firestore/Storage Security Rules. Never ship `allow read, write: if true`.
- Every collection needs rules that check `request.auth` and validate the written fields.
- Admin SDK credentials are server-only (Cloud Functions or your backend).
- Model Firestore data for your queries: avoid deeply nested data and unbounded arrays; denormalize deliberately.
- Test rules and functions against the Emulator Suite, not production.

## Reference docs

- [Flutter docs](https://docs.flutter.dev)
- [Firebase docs](https://firebase.google.com/docs)

---
description: "Core rules for this project"
alwaysApply: true
---

# this project

A Flutter (Dart) + Firebase project.

Stack: Flutter (Dart), Firebase.

## Commands

- Run: `flutter run`
- Analyze: `flutter analyze`
- Tests: `flutter test`
- Format: `dart format .`
- Local emulators: `firebase emulators:start`
- Deploy rules only: `firebase deploy --only firestore:rules`

## How to work in this repo

- Read the relevant files before editing. Follow the patterns already in the codebase over these generic rules.
- Make the smallest change that solves the task. Do not refactor or reformat unrelated code.
- Before saying a task is done, run the type-check, lint and tests listed under Commands and fix what you broke.
- If requirements are ambiguous, ask one clear question instead of guessing.
- Never commit secrets, API keys or `.env` files. Use env vars and keep `.env.example` up to date.
- Do not add a new dependency when the standard library or an existing dependency already covers it.
- Ask before adding, removing or upgrading any dependency.
- Ask before changing database schemas, auth, payments or CI configuration.
- Never delete files, drop data or run destructive commands (`rm -rf`, `git push --force`, `DROP TABLE`) without explicit approval.
- Keep each change under ~200 changed lines where possible; split larger work into steps.

---
description: "Flutter (Dart) conventions: Cross-platform Flutter app in Dart 3."
globs: lib/**/*.dart, test/**/*.dart
alwaysApply: false
---

# Flutter (Dart)

- Code must pass `flutter analyze` with no warnings.
- Use `const` constructors wherever possible.
- Split large `build` methods into small widgets, not helper methods returning widgets.
- Use the state management already in the project (Riverpod, Bloc, Provider). Do not introduce a second one.
- Check `mounted` before using `BuildContext` after an `await`.
- Add packages with `flutter pub add`; prefer well-maintained packages from pub.dev.
- Never hardcode API secrets in the app bundle.

Docs: https://docs.flutter.dev

---
description: "Firebase conventions: Firebase Auth, Firestore and Cloud Functions."
globs: firestore.rules, functions/**, **/firebase/**
alwaysApply: false
---

# Firebase

- Firebase web config is public by design; security comes from Firestore/Storage Security Rules. Never ship `allow read, write: if true`.
- Every collection needs rules that check `request.auth` and validate the written fields.
- Admin SDK credentials are server-only (Cloud Functions or your backend).
- Model Firestore data for your queries: avoid deeply nested data and unbounded arrays; denormalize deliberately.
- Test rules and functions against the Emulator Suite, not production.

Docs: https://firebase.google.com/docs

# Cursor rules - this project

You are an expert Flutter (Dart), Firebase engineer working on this codebase. Follow these rules.

## Project

A Flutter (Dart) + Firebase project.

Stack: Flutter (Dart), Firebase.

## Commands

- Run: `flutter run`
- Analyze: `flutter analyze`
- Tests: `flutter test`
- Format: `dart format .`
- Local emulators: `firebase emulators:start`
- Deploy rules only: `firebase deploy --only firestore:rules`

## Project structure

- Feature folders under `lib/features/<name>/` with widgets, state and data layers.

## How to work in this repo

- Read the relevant files before editing. Follow the patterns already in the codebase over these generic rules.
- Make the smallest change that solves the task. Do not refactor or reformat unrelated code.
- Before saying a task is done, run the type-check, lint and tests listed under Commands and fix what you broke.
- If requirements are ambiguous, ask one clear question instead of guessing.
- Never commit secrets, API keys or `.env` files. Use env vars and keep `.env.example` up to date.
- Do not add a new dependency when the standard library or an existing dependency already covers it.
- Ask before adding, removing or upgrading any dependency.
- Ask before changing database schemas, auth, payments or CI configuration.
- Never delete files, drop data or run destructive commands (`rm -rf`, `git push --force`, `DROP TABLE`) without explicit approval.
- Keep each change under ~200 changed lines where possible; split larger work into steps.

## Flutter (Dart)

- Code must pass `flutter analyze` with no warnings.
- Use `const` constructors wherever possible.
- Split large `build` methods into small widgets, not helper methods returning widgets.
- Use the state management already in the project (Riverpod, Bloc, Provider). Do not introduce a second one.
- Check `mounted` before using `BuildContext` after an `await`.
- Add packages with `flutter pub add`; prefer well-maintained packages from pub.dev.
- Never hardcode API secrets in the app bundle.

## Firebase

- Firebase web config is public by design; security comes from Firestore/Storage Security Rules. Never ship `allow read, write: if true`.
- Every collection needs rules that check `request.auth` and validate the written fields.
- Admin SDK credentials are server-only (Cloud Functions or your backend).
- Model Firestore data for your queries: avoid deeply nested data and unbounded arrays; denormalize deliberately.
- Test rules and functions against the Emulator Suite, not production.

## Reference docs

- [Flutter docs](https://docs.flutter.dev)
- [Firebase docs](https://firebase.google.com/docs)

# Copilot instructions - this project

A Flutter (Dart) + Firebase project.

Stack: Flutter (Dart), Firebase.

## Commands

- Run: `flutter run`
- Analyze: `flutter analyze`
- Tests: `flutter test`
- Format: `dart format .`
- Local emulators: `firebase emulators:start`
- Deploy rules only: `firebase deploy --only firestore:rules`

## How to work in this repo

- Read the relevant files before editing. Follow the patterns already in the codebase over these generic rules.
- Make the smallest change that solves the task. Do not refactor or reformat unrelated code.
- Before saying a task is done, run the type-check, lint and tests listed under Commands and fix what you broke.
- If requirements are ambiguous, ask one clear question instead of guessing.
- Never commit secrets, API keys or `.env` files. Use env vars and keep `.env.example` up to date.
- Do not add a new dependency when the standard library or an existing dependency already covers it.
- Ask before adding, removing or upgrading any dependency.
- Ask before changing database schemas, auth, payments or CI configuration.
- Never delete files, drop data or run destructive commands (`rm -rf`, `git push --force`, `DROP TABLE`) without explicit approval.
- Keep each change under ~200 changed lines where possible; split larger work into steps.

---
applyTo: "lib/**/*.dart,test/**/*.dart"
---

# Flutter (Dart)

- Code must pass `flutter analyze` with no warnings.
- Use `const` constructors wherever possible.
- Split large `build` methods into small widgets, not helper methods returning widgets.
- Use the state management already in the project (Riverpod, Bloc, Provider). Do not introduce a second one.
- Check `mounted` before using `BuildContext` after an `await`.
- Add packages with `flutter pub add`; prefer well-maintained packages from pub.dev.
- Never hardcode API secrets in the app bundle.

---
applyTo: "firestore.rules,functions/**,**/firebase/**"
---

# Firebase

- Firebase web config is public by design; security comes from Firestore/Storage Security Rules. Never ship `allow read, write: if true`.
- Every collection needs rules that check `request.auth` and validate the written fields.
- Admin SDK credentials are server-only (Cloud Functions or your backend).
- Model Firestore data for your queries: avoid deeply nested data and unbounded arrays; denormalize deliberately.
- Test rules and functions against the Emulator Suite, not production.

---
trigger: always_on
---

# this project

A Flutter (Dart) + Firebase project.

Stack: Flutter (Dart), Firebase.

## Commands

- Run: `flutter run`
- Analyze: `flutter analyze`
- Tests: `flutter test`
- Format: `dart format .`
- Local emulators: `firebase emulators:start`
- Deploy rules only: `firebase deploy --only firestore:rules`

## How to work in this repo

- Read the relevant files before editing. Follow the patterns already in the codebase over these generic rules.
- Make the smallest change that solves the task. Do not refactor or reformat unrelated code.
- Before saying a task is done, run the type-check, lint and tests listed under Commands and fix what you broke.
- If requirements are ambiguous, ask one clear question instead of guessing.
- Never commit secrets, API keys or `.env` files. Use env vars and keep `.env.example` up to date.
- Do not add a new dependency when the standard library or an existing dependency already covers it.
- Ask before adding, removing or upgrading any dependency.
- Ask before changing database schemas, auth, payments or CI configuration.
- Never delete files, drop data or run destructive commands (`rm -rf`, `git push --force`, `DROP TABLE`) without explicit approval.
- Keep each change under ~200 changed lines where possible; split larger work into steps.

---
trigger: glob
globs: lib/**/*.dart, test/**/*.dart
---

# Flutter (Dart)

- Code must pass `flutter analyze` with no warnings.
- Use `const` constructors wherever possible.
- Split large `build` methods into small widgets, not helper methods returning widgets.
- Use the state management already in the project (Riverpod, Bloc, Provider). Do not introduce a second one.
- Check `mounted` before using `BuildContext` after an `await`.
- Add packages with `flutter pub add`; prefer well-maintained packages from pub.dev.
- Never hardcode API secrets in the app bundle.

---
trigger: glob
globs: firestore.rules, functions/**, **/firebase/**
---

# Firebase

- Firebase web config is public by design; security comes from Firestore/Storage Security Rules. Never ship `allow read, write: if true`.
- Every collection needs rules that check `request.auth` and validate the written fields.
- Admin SDK credentials are server-only (Cloud Functions or your backend).
- Model Firestore data for your queries: avoid deeply nested data and unbounded arrays; denormalize deliberately.
- Test rules and functions against the Emulator Suite, not production.

# GEMINI.md - this project

Project context for Gemini CLI.

## Project

A Flutter (Dart) + Firebase project.

Stack: Flutter (Dart), Firebase.

## Commands

- Run: `flutter run`
- Analyze: `flutter analyze`
- Tests: `flutter test`
- Format: `dart format .`
- Local emulators: `firebase emulators:start`
- Deploy rules only: `firebase deploy --only firestore:rules`

## Project structure

- Feature folders under `lib/features/<name>/` with widgets, state and data layers.

## How to work in this repo

- Read the relevant files before editing. Follow the patterns already in the codebase over these generic rules.
- Make the smallest change that solves the task. Do not refactor or reformat unrelated code.
- Before saying a task is done, run the type-check, lint and tests listed under Commands and fix what you broke.
- If requirements are ambiguous, ask one clear question instead of guessing.
- Never commit secrets, API keys or `.env` files. Use env vars and keep `.env.example` up to date.
- Do not add a new dependency when the standard library or an existing dependency already covers it.
- Ask before adding, removing or upgrading any dependency.
- Ask before changing database schemas, auth, payments or CI configuration.
- Never delete files, drop data or run destructive commands (`rm -rf`, `git push --force`, `DROP TABLE`) without explicit approval.
- Keep each change under ~200 changed lines where possible; split larger work into steps.

## Flutter (Dart)

- Code must pass `flutter analyze` with no warnings.
- Use `const` constructors wherever possible.
- Split large `build` methods into small widgets, not helper methods returning widgets.
- Use the state management already in the project (Riverpod, Bloc, Provider). Do not introduce a second one.
- Check `mounted` before using `BuildContext` after an `await`.
- Add packages with `flutter pub add`; prefer well-maintained packages from pub.dev.
- Never hardcode API secrets in the app bundle.

## Firebase

- Firebase web config is public by design; security comes from Firestore/Storage Security Rules. Never ship `allow read, write: if true`.
- Every collection needs rules that check `request.auth` and validate the written fields.
- Admin SDK credentials are server-only (Cloud Functions or your backend).
- Model Firestore data for your queries: avoid deeply nested data and unbounded arrays; denormalize deliberately.
- Test rules and functions against the Emulator Suite, not production.

## Reference docs

- [Flutter docs](https://docs.flutter.dev)
- [Firebase docs](https://firebase.google.com/docs)