Firebase Development Validate

---
name: firebase-development-validate
description: This skill should be used when reviewing Firebase code against security model and best practices. Triggers on "review firebase", "check firebase", "validate", "audit firebase", "security review", "look at firebase code". Validates configuration, rules, architecture, and security.
---

# Firebase Code Validation

## Overview

This sub-skill validates existing Firebase code against proven patterns and security best practices. It checks configuration, rules, architecture consistency, authentication, testing, and production readiness.

**Key principles:**
- Validate against chosen architecture patterns
- Check security rules thoroughly
- Verify test coverage exists
- Review production readiness

## When This Sub-Skill Applies

- Conducting code review of Firebase project
- Auditing security implementation
- Preparing for production deployment
- User says: "review firebase", "validate", "audit firebase", "check firebase code"

**Do not use for:**
- Initial setup → `firebase-development:project-setup`
- Adding features → `firebase-development:add-feature`
- Debugging active errors → `firebase-development:debug`

## TodoWrite Workflow

Create checklist with these 9 steps:

### Step 1: Check firebase.json Structure

Validate required sections:
- `hosting` - Array or object present
- `functions` - Source directory, runtime, predeploy hooks
- `firestore` - Rules and indexes files
- `emulators` - Local development config

Check hosting pattern matches implementation (site:, target:, or single).

**Reference:** `docs/examples/multi-hosting-setup.md`

### Step 2: Validate Emulator Configuration

Critical settings:
```json
{
  "emulators": {
    "singleProjectMode": true,
    "ui": { "enabled": true }
  }
}
```

Verify all services in use have emulator entries.

**Reference:** `docs/examples/emulator-workflow.md`

### Step 3: Review Firestore Rules

Check for:
- Helper functions at top (`isAuthenticated()`, `isOwner()`)
- Consistent security model (server-write-only OR client-write-validated)
- `diff().affectedKeys().hasOnly([...])` for client writes
- Collection group rules if using `collectionGroup()` queries
- Default deny rule at bottom

**Reference:** `docs/examples/firestore-rules-patterns.md`

### Step 4: Validate Functions Architecture

Identify pattern in use:
- **Express:** Check `middleware/`, `tools/`, CORS, health endpoint
- **Domain-Grouped:** Check exports, domain boundaries, `shared/`
- **Individual:** Check one function per file structure

**Critical:** Don't mix patterns. Verify consistency throughout.

**Reference:** `docs/examples/express-function-architecture.md`

### Step 5: Check Authentication Implementation

**For API Keys:**
- Middleware validates key format with project prefix
- Uses `collectionGroup('apiKeys')` query
- Checks `active: true` flag
- Attaches `userId` to request

**For Firebase Auth:**
- Functions check `request.auth.uid`
- Role lookups use Firestore user document
- Client connects to auth emulator in development

**Reference:** `docs/examples/api-key-authentication.md`

### Step 6: Verify ABOUTME Comments

All `.ts` files should start with:
```typescript
// ABOUTME: Brief description of what this file does
// ABOUTME: Second line with additional context
```

```bash
grep -L "ABOUTME:" functions/src/**/*.ts  # Find missing
```

### Step 7: Review Test Coverage

Check for:
- Unit tests: `functions/src/__tests__/**/*.test.ts`
- Integration tests: `functions/src/__tests__/emulator/**/*.test.ts`
- `vitest.config.ts` and `vitest.emulator.config.ts` exist
- Coverage threshold met (60%+)

```bash
npm test && npm run test:coverage
```

### Step 8: Validate Error Handling

All handlers must:
- Use try-catch blocks
- Return `{ success: boolean, message: string, data?: any }`
- Use proper HTTP status codes (400, 401, 403, 500)
- Log errors with `console.error`
- Validate input before processing

### Step 9: Security and Production Review

**Security checks:**
- No secrets in code (`grep -r "apiKey.*=" functions/src/`)
- `.env` files in `.gitignore`
- No `allow read, write: if true;` in rules
- Sensitive fields protected from client writes

**Production checks:**
- `npm audit` clean
- Build succeeds: `npm run build`
- Tests pass: `npm test`
- Correct project in `.firebaserc`
- Indexes defined for complex queries

## Validation Checklists

### Hosting Pattern
- [ ] Pattern matches firebase.json config
- [ ] Sites/targets exist in Firebase Console
- [ ] Rewrites reference valid functions
- [ ] Emulator ports configured

### Authentication Pattern
- [ ] Auth method matches security model
- [ ] Middleware/checks implemented correctly
- [ ] Environment variables documented
- [ ] Emulator connection configured

### Security Model
- [ ] Server-write-only: All `allow write: if false;`
- [ ] Client-write: `diff().affectedKeys()` validation
- [ ] Default deny rule present
- [ ] Helper functions used consistently

## Common Issues

| Issue | Fix |
|-------|-----|
| Missing `singleProjectMode` | Add to emulators config |
| No default deny rule | Add `match /{document=**} { allow: if false; }` |
| Mixed architecture | Migrate to consistent pattern |
| Missing ABOUTME | Add 2-line header to all .ts files |
| No integration tests | Add emulator tests for workflows |
| Inconsistent response format | Standardize to `{success, message, data?}` |
| No error handling | Add try-catch to all handlers |
| Secrets in code | Move to environment variables |

## Integration with Superpowers

For general code quality review beyond Firebase patterns, invoke `superpowers:requesting-code-review`.

## Output

After validation, provide:
- Summary of findings
- Issues categorized by severity (critical, important, nice-to-have)
- Recommendations for remediation
- Confirmation of best practices compliance

## Pattern References

- **Hosting:** `docs/examples/multi-hosting-setup.md`
- **Auth:** `docs/examples/api-key-authentication.md`
- **Functions:** `docs/examples/express-function-architecture.md`
- **Rules:** `docs/examples/firestore-rules-patterns.md`
- **Emulators:** `docs/examples/emulator-workflow.md`