firebase-development-validate

# 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`