ai-flow-dev 2.1.9 → 2.2.1

package/prompts/mobile/flow-build-phase-7.md

@@ -1,415 +1,1001 @@
-# Phase 7: Store Deployment
+## PHASE 7: Operations & Deployment (10-15 min)
 
-**Duration:** 15-20 minutes
-**Questions:** ~12 questions
-**Output:** docs/app-store.md, specs/build-configuration.md, specs/deployment.md, parts of ai-instructions.md
----
-## 🎯 Objective
+> **Order for this phase:** 7.1 → 7.2 → 7.3 → 7.4 → 7.4.1 → 7.5 → 7.6 → 7.7 → 7.7.1 → 7.7.2 → 7.8 → 7.9 → 7.9.1 → 7.9.2 → 7.9.3 → 7.9.4 → 7.10
 
-Define your app store deployment strategy:
+> **📌 Scope-based behavior:**
+>
+> - **MVP:** Ask 7.1-7.4 only (deployment basics), skip 7.5-7.10 (monitoring, scaling, backups), mark as "TBD"
+> - **Production-Ready:** Ask 7.1-7.8, simplify 7.9-7.10 (advanced monitoring and resilience)
+> - **Enterprise:** Ask all questions 7.1-7.10 with emphasis on reliability and disaster recovery
 
-1. Which app stores will you publish to?
-2. What CI/CD pipeline will you use?
-3. How will you handle versioning?
-4. What code signing strategy?
-5. What beta testing approach?
----
-## 📋 Questions
+### Objective
 
-### Question 7.1: Target App Stores
+Define deployment, monitoring, and operational practices.
 
-**Which app stores will you publish to?**
+---
 
-A) ⭐ **Apple App Store (iOS)** (Required for iOS)
+## 🔍 Pre-Flight Check (Smart Skip Logic)
 
-- Requires: Apple Developer Account ($99/year)
-- Review process: 1-3 days typically
-- Best for: iOS apps
+> 📎 **Reference:** See [prompts/shared/smart-skip-preflight.md](../shared/smart-skip-preflight.md) for the complete smart skip logic.
 
-B) ⭐ **Google Play Store (Android)** (Required for Android)
+**Execute Pre-Flight Check for Phase 7:**
 
-- Requires: Google Play Developer Account ($25 one-time)
-- Review process: Usually instant, can take hours
-- Best for: Android apps
+- **Target File**: `docs/deployment.md`
+- **Phase Name**: "OPERATIONS & DEPLOYMENT"
+- **Key Items**: CI/CD pipeline, deployment platform, monitoring, logging
+- **Typical Gaps**: Incident runbooks, disaster recovery, scaling strategy
 
-C) 🔥 **Both App Store + Play Store** (Recommended for cross-platform)
+**Proceed with appropriate scenario based on audit data from `.ai-flow/cache/audit-data.json`**
 
-- Maximum reach
-- Best for: Most apps
+---
 
-D) **Enterprise Distribution Only**
+## Phase 7 Questions (Full Mode)
 
-- Internal distribution
-- No public store
-- Best for: Enterprise apps
+**7.1 Deployment Environment**
 
-**Your answer:**
----
-### Question 7.2: CI/CD Pipeline
+```
+
+Where will you deploy?
+
+A) ⭐ Cloud Platform
+
+- AWS (ECS, Fargate, Lambda, EC2)
+- Google Cloud (Cloud Run, GKE, Compute Engine)
+- Azure (App Service, AKS, VMs)
+
+B) 🔥 Platform-as-a-Service (PaaS)
+
+- Heroku
+- Railway
+- Render
+- Fly.io
+- Vercel (for APIs)
+
+C) 🏢 On-Premises
+
+- Company servers
+- Private cloud
 
-**What CI/CD tool will you use for builds and deployment?**
+D) 🐳 Container Orchestration
 
-A) ⭐ **Fastlane** (Recommended)
+- Kubernetes (GKE, EKS, AKS)
+- Docker Swarm
+- Nomad
 
-- Automates builds, screenshots, deployment
-- Works with iOS and Android
-- Integrates with GitHub Actions, Bitrise, etc.
-- Best for: Most projects
+Your choice: \_\_
+Why?
 
-B) **Codemagic**
+```
+
+**7.2 Containerization**
+
+````
+
+Will you use Docker?
 
-- Cloud-based CI/CD for Flutter/React Native
-- Easy setup, good for small teams
-- Best for: Flutter/React Native apps
+A) ⭐ Yes - Dockerize application
 
-C) **GitHub Actions**
+- Multi-stage build
+- Optimized image size
+- Docker Compose for local dev
 
-- Flexible, free for public repos
-- Custom workflows
-- Best for: GitHub-hosted projects
+B) No - Deploy directly
 
-D) **Bitrise**
+If yes:
+Base image: **
+Estimated image size: ** MB
 
-- Mobile-focused CI/CD
-- Good for complex workflows
-- Best for: Enterprise teams
+Example stack (local development):
 
-E) **Manual Builds**
+```yaml
+services:
+  app:
+    build: .
+    ports: [3000:3000]
+  db:
+    image: postgres:15
+  redis:
+    image: redis:7
+```
 
-- Build locally, upload manually
-- Best for: Learning, small projects
+````
 
-**Your answer:**
----
-### Question 7.3: Versioning Strategy
+**7.3 Environment Strategy**
 
-**How will you version your app?**
+```
 
-A) ⭐ **Semantic Versioning** (Recommended)
+How many environments will you have?
 
-- Format: `MAJOR.MINOR.PATCH` (e.g., `1.2.3`)
-- MAJOR: Breaking changes
-- MINOR: New features, backward compatible
-- PATCH: Bug fixes
-- Best for: Most apps
+A) ⭐ Three environments
 
-B) **Date-based Versioning**
+- Development (local)
+- Staging (pre-production, QA)
+- Production (live)
 
-- Format: `YYYY.MM.DD` (e.g., `2025.01.20`)
-- Best for: Frequent releases
+B) 🏆 Four+ environments
 
-C) **Build Number Only**
+- Development
+- Testing (automated tests)
+- Staging
+- Production
 
-- Incrementing build number
-- Best for: Simple apps
+C) 🚀 Two environments
 
-**Your answer:**
+- Development
+- Production
 
-**Version code strategy (Android):**
+Your choice: \_\_
 
-- A) ⭐ **Incrementing integer** (1, 2, 3, ...)
-- B) **Based on version** (e.g., 1.2.3 → 10203)
+Environment configuration:
+A) ✅ Environment variables (.env files)
+B) ✅ Config service (AWS Secrets Manager, Vault)
+C) ✅ Feature flags (LaunchDarkly, Unleash)
 
-**Build number strategy (iOS):**
+```
 
-- A) ⭐ **Incrementing integer** (1, 2, 3, ...)
-- B) **Based on version** (e.g., 1.2.3 → 10203)
----
-### Question 7.4: Code Signing Strategy
+**7.4 CI/CD Pipeline**
 
-**How will you handle code signing?**
+```
 
-**For iOS:**
+CI/CD platform:
 
-- A) ⭐ **Automatic Signing** (Recommended)
-  - Xcode manages certificates
-  - Easier for most developers
-  - Best for: Most apps
+A) ⭐ GitHub Actions - If using GitHub
+B) 🔥 GitLab CI - If using GitLab
+C) Jenkins - Self-hosted
+D) CircleCI
+E) Travis CI
+F) AWS CodePipeline
+G) Azure DevOps
 
-- B) **Manual Signing**
-  - More control
-  - Required for enterprise apps
-  - Best for: Advanced scenarios
+Your choice: \_\_
 
-**For Android:**
+Pipeline stages:
 
-- A) ⭐ **Automatic Signing** (Recommended)
-  - Gradle manages keystores
-  - Easier for most developers
-  - Best for: Most apps
+1. ✅ Checkout code
+2. ✅ Install dependencies
+3. ✅ Lint
+4. ✅ Test (with coverage)
+5. ✅ Build
+6. ✅ Security scan (optional)
+7. ✅ Deploy to staging
+8. ⏸️ Manual approval (optional)
+9. ✅ Deploy to production
 
-- B) **Manual Signing**
-  - More control
-  - Required for some enterprise scenarios
-  - Best for: Advanced scenarios
+Auto-deploy strategy:
+A) ⭐ Auto-deploy to staging, manual approval for production
+B) 🚀 Auto-deploy to production (main branch)
+C) Manual deploy for all environments
 
-**Your answer:**
+```
 
-**Keystore management:**
+**7.4.1 Deployment Strategy** (Production-Ready and Enterprise only)
 
-- A) ⭐ **Store in CI/CD secrets** (Recommended)
-  - GitHub Secrets, Bitrise Secrets, etc.
-  - Secure, automated
+```
+What deployment strategy will you use for production?
+
+A) ⭐ Rolling Deployment - Gradual replacement
+   - Replace instances one at a time
+   - Zero downtime
+   - Easy rollback
+
+B) 🔥 Blue-Green Deployment - Instant switch
+   - Two identical environments
+   - Switch traffic instantly
+   - Higher infrastructure cost
+
+C) ⚡ Canary Deployment - Progressive rollout
+   - Deploy to small percentage first
+   - Monitor for issues
+   - Gradually increase traffic
+
+D) 🏆 Feature Flags - Code-level control
+   - Deploy code, toggle features
+   - Instant enable/disable
+   - Best with: LaunchDarkly, Unleash
+
+Your choice: __
+
+Rollback plan:
+- How quickly must rollback complete? __ minutes
+- Who can trigger rollback? [DevOps/Tech Lead/Any developer]
+- Rollback trigger criteria? [Error rate > X%, latency > Y ms, manual]
+
+If Blue-Green:
+- Traffic switching: [Load balancer, DNS, etc.]
+- Database migrations: [Strategy for zero-downtime]
+
+If Canary:
+- Initial traffic: __%
+- Gradual increase: __% per __ minutes
+- Success criteria: __
+```
 
-- B) **Store locally**
-  - Manual management
-  - Best for: Small teams
----
-### Question 7.5: Beta Testing Strategy
+**7.5 Monitoring & Logging**
 
-**How will you handle beta testing?**
+````
 
-A) ⭐ **TestFlight (iOS) + Firebase App Distribution (Android)** (Recommended)
+Monitoring tools:
 
-- Free, easy to use
-- TestFlight: Up to 10,000 testers
-- Firebase: Unlimited testers
-- Best for: Most projects
+Application Performance Monitoring (APM):
+A) ⭐ Datadog - Full-featured, expensive
+B) 🔥 New Relic - Popular
+C) Sentry - Error tracking focus
+D) ⚡ OpenTelemetry + Grafana - Open source
+E) AWS CloudWatch
+F) None yet
 
-B) **TestFlight (iOS) + Google Play Internal Testing (Android)**
+Your choice: \_\_
 
-- Official store channels
-- Internal testing: Up to 100 testers
-- Best for: Store-focused testing
+Logging:
+A) ⭐ Centralized logging
 
-C) **TestFlight (iOS) + Google Play Closed Beta (Android)**
+- Winston/Pino (Node.js) → CloudWatch/Datadog
+- Python logging → ELK Stack
 
-- Closed beta: Up to 20,000 testers
-- Best for: Larger beta programs
+B) Basic console logs
 
-D) **HockeyApp / App Center**
+C) Structured JSON logging ⭐
 
-- Microsoft's solution
-- Good for enterprise
+```json
+{
+  "level": "info",
+  "timestamp": "2024-01-15T10:30:00Z",
+  "userId": "123",
+  "action": "user.login",
+  "ip": "192.168.1.1",
+  "message": "User logged in successfully"
+}
+```
 
-E) **No Beta Testing**
+Your logging strategy: \_\_
 
-- Direct to production
-- Best for: MVPs, internal apps
+Metrics to track:
 
-**Your answer:**
----
-### Question 7.6: Release Strategy
+- ✅ Request rate (requests/sec)
+- ✅ Error rate (% of failed requests)
+- ✅ Response time (p50, p95, p99)
+- ✅ Database query time
+- ✅ Cache hit rate
+- ✅ CPU/Memory usage
+- Custom business metrics: \_\_
 
-**What release strategy will you use?**
+````
 
-A) ⭐ **Staged Rollout** (Recommended)
+**7.6 Alerts**
 
-- Release to 10% → 50% → 100% of users
-- Monitor for issues before full release
-- Best for: Most apps
+```
 
-B) **Gradual Rollout**
+When should you be alerted?
 
-- Release to specific countries/regions first
-- Expand gradually
-- Best for: Global apps
+A) ✅ Error rate > **% (e.g., 1%)
+B) ✅ Response time > **ms (e.g., 1000ms)
+C) ✅ 5xx errors (server errors)
+D) ✅ Service down (health check failure)
+E) ✅ Database connection failures
+F) ✅ Disk space > 80%
+G) ✅ Memory usage > 85%
 
-C) **Full Release**
+Alert channels:
+A) ⭐ Email
+B) 🔥 Slack/Discord
+C) ⚡ PagerDuty/Opsgenie (on-call)
+D) SMS (critical only)
 
-- Release to 100% immediately
-- Best for: Small updates, bug fixes
+Your preferences: \_\_
 
-**Your answer:**
----
-### Question 7.7: App Store Metadata
+On-call rotation:
+A) Yes - Using [PagerDuty/Opsgenie]
+B) No - Monitor during business hours
 
-**What metadata will you prepare for stores?**
+```
 
-**Required:**
+**7.7 Backup & Disaster Recovery**
 
-- [ ] App name (30 chars iOS, 50 chars Android)
-- [ ] App description (4000 chars)
-- [ ] Screenshots (various sizes)
-- [ ] App icon (1024x1024 iOS, 512x512 Android)
-- [ ] Privacy policy URL
+```
 
-**Optional:**
+Backup strategy:
 
-- [ ] Promotional text
-- [ ] Keywords (iOS only)
-- [ ] App preview videos
-- [ ] Feature graphic (Android)
+Database backups:
+A) ⭐ Automated daily backups
 
-**Your answer:**
----
-### Question 7.8: Screenshot Automation
+- Retention: 30 days
+- Point-in-time recovery
 
-**Will you automate screenshot generation?**
+B) 🏆 Continuous backups
 
-A) ⭐ **Yes - Fastlane Screenshots** (Recommended)
+- Every hour
+- 90 days retention
 
-- Automate screenshots for all devices
-- Update automatically on each release
-- Best for: Most apps
+C) Manual backups weekly
 
-B) **Yes - Manual Scripts**
+Your strategy: **
+Retention period: ** days
 
-- Custom screenshot scripts
-- Best for: Custom requirements
+Disaster recovery:
 
-C) **No - Manual Screenshots**
+- Recovery Time Objective (RTO): \_\_ (how fast to restore)
+- Recovery Point Objective (RPO): \_\_ (acceptable data loss)
 
-- Take screenshots manually
-- Best for: Small teams, infrequent updates
+Example:
 
-**Your answer:**
----
-### Question 7.9: App Review Preparation
+- RTO: 1 hour (service restored within 1 hour)
+- RPO: 15 minutes (lose max 15 min of data)
 
-**How will you prepare for app review?**
+```
 
-**For iOS App Store:**
+**7.7.1 Database Migrations in Production**
 
-- [ ] Test on latest iOS version
-- [ ] Test on multiple device sizes
-- [ ] Ensure all features work
-- [ ] Prepare demo account credentials
-- [ ] Review App Store guidelines
-- [ ] Test in TestFlight first
+```
+How will you handle database migrations in production?
 
-**For Google Play:**
+Zero-downtime migrations:
+A) ⭐ Yes - Plan for zero-downtime migrations (Production-Ready/Enterprise)
+B) No - Accept maintenance windows (MVP)
 
-- [ ] Test on latest Android version
-- [ ] Test on multiple device sizes
-- [ ] Ensure all features work
-- [ ] Prepare demo account credentials
-- [ ] Review Play Store policies
-- [ ] Test in internal testing first
+If zero-downtime:
+- Strategy: [Expand/Contract, Blue-Green migrations, etc.]
+- Rollback plan: __
+- Testing: [Tested on staging, Dry-run process]
 
-**Your answer:**
----
-### Question 7.10: Update Frequency
+Migration windows (if not zero-downtime):
+- Preferred time: __
+- Duration: __ minutes
+- Notification: __
+```
 
-**How often will you release updates?**
+**7.7.2 Database Connection Pooling**
 
-A) ⭐ **As Needed** (Recommended)
+```
+Database connection pooling configuration:
 
-- Release when features are ready
-- Best for: Most apps
+Pool tool: [ORM built-in, pgBouncer, HikariCP, etc.]
 
-B) **Weekly**
+Settings:
+- Min connections: __
+- Max connections: __
+- Connection timeout: __ ms
+- Idle timeout: __ ms
+- Max lifetime: __ ms
 
-- Regular weekly releases
-- Best for: Rapid iteration
+Monitoring:
+- Track active/idle connections: [Yes/No]
+- Alert on pool exhaustion: [Yes/No]
+```
 
-C) **Bi-weekly**
+**7.8 Scaling Strategy**
 
-- Every two weeks
-- Best for: Balanced approach
+```
 
-D) **Monthly**
+How will you handle growth?
 
-- Once per month
-- Best for: Stable apps
+A) ⭐ Horizontal scaling - Add more instances
 
-**Your answer:**
----
-### Question 7.11: Rollback Strategy
+- Load balancer distributes traffic
+- Stateless application design
 
-**How will you handle rollbacks?**
+B) Vertical scaling - Bigger instances
 
-A) ⭐ **Store Rollback** (Recommended)
+- Increase CPU/RAM
+- Simpler but limited
 
-- Revert to previous version in store
-- Best for: Critical bugs
+C) ⚡ Auto-scaling - Automatic based on load
 
-B) **Hotfix Release**
+- Scale up during high traffic
+- Scale down to save costs
+- Metrics: CPU > 70%, requests > threshold
 
-- Release emergency fix
-- Best for: Quick fixes
+Your strategy: \_\_
 
-C) **No Rollback Plan**
+Expected load:
 
-- Not recommended
-- Best for: Very small apps
+- Initial: \_\_ requests/minute
+- Year 1: \_\_ requests/minute
+- Peak traffic: \_\_x normal load
 
-**Your answer:**
----
-### Question 7.12: Monitoring & Analytics
+Database scaling:
+A) Read replicas - Scale reads
+B) Sharding - Split data across DBs
+C) Vertical scaling - Bigger DB instance
+D) Not needed yet
 
-**What monitoring will you use post-deployment?**
+```
 
-A) ⭐ **Firebase Analytics + Crashlytics** (Recommended)
+**7.9 Health Checks**
 
-- Free, comprehensive
-- Works with iOS and Android
-- Best for: Most apps
+````
 
-B) **Sentry**
+Health check endpoints:
 
-- Excellent error tracking
-- Good for: Production apps
+A) ✅ /health - Basic liveness
 
-C) **App Store Connect Analytics + Play Console Analytics**
+- Returns 200 OK if app is running
 
-- Built-in store analytics
-- Best for: Store metrics
+B) ✅ /health/ready - Readiness check
 
-D) **Custom Analytics**
+- Returns 200 OK if app can handle traffic
+- Checks: DB connected, Redis connected, etc.
 
-- Mixpanel, Amplitude, etc.
-- Best for: Advanced analytics
+C) ✅ /health/live - Liveness check
 
-**Your answer:**
----
-## ✅ Phase 7 Completion
+- Returns 200 OK if app is alive
+- Load balancer uses this
 
-After answering all questions, summarize:
+Example response:
 
+```json
+{
+  "status": "healthy",
+  "timestamp": "2024-01-15T10:30:00Z",
+  "checks": {
+    "database": "ok",
+    "redis": "ok",
+    "disk_space": "ok"
+  },
+  "version": "1.2.3"
+}
 ```
----
-✅ Phase 7 Complete: Store Deployment
----
-Selected Deployment Strategy:
-- Stores: {{TARGET_STORES}}
-- CI/CD: {{CICD_PIPELINE}}
-- Versioning: {{VERSIONING_STRATEGY}}
-- Code Signing: {{CODE_SIGNING}}
-- Beta Testing: {{BETA_TESTING}}
-- Release Strategy: {{RELEASE_STRATEGY}}
-- Monitoring: {{MONITORING_TOOLS}}
 
-Generated Documents:
-✅ docs/app-store.md
-✅ specs/build-configuration.md
-✅ specs/deployment.md
-✅ .env.example
----
-📊 Progress Summary:
+Your health check endpoints: \_\_
+
+````
+
+**7.9.1 Graceful Shutdown**
+
+```
+Will you implement graceful shutdown?
+
+A) ⭐ Yes - Handle shutdown gracefully (Production-Ready/Enterprise)
+B) No - Standard shutdown
+
+If yes:
+Shutdown sequence:
+1. Stop accepting new requests (timeout: __s)
+2. Finish processing current requests (timeout: __s)
+3. Close database connections (timeout: __s)
+4. Close other connections (Redis, message queues, etc.)
+5. Exit process
+
+Total shutdown timeout: __s
+
+Implementation:
+- Signal handling: [SIGTERM, SIGINT]
+- Health check grace period: __s
+- Connection drain timeout: __s
+```
+
+**7.9.2 Circuit Breakers & Resilience**
+
+```
+Will you implement circuit breakers?
+
+A) ⭐ Yes - Protect against cascading failures (Production-Ready/Enterprise)
+B) No - Direct service calls
+
+If yes:
+Circuit breaker tool: [Resilience4j, Hystrix, Polly, etc.]
+
+Configuration:
+- Failure threshold: __% (open circuit after X% failures)
+- Success threshold: __% (close circuit after X% successes)
+- Timeout: __ms
+- Half-open retries: __
+- Reset timeout: __s
+
+Fallback strategy:
+A) ⭐ Return cached data
+B) Return default/empty response
+C) Call alternative service
+D) Return error gracefully
+
+Services to protect:
+{{#EACH SERVICE_TO_PROTECT}}
+- **{{SERVICE_NAME}}**: {{FAILURE_THRESHOLD}}% threshold, fallback: {{FALLBACK_STRATEGY}}
+{{/EACH}}
+```
+
+**7.9.3 Retry & Timeout Policies**
+
+```
+Define retry and timeout policies for external dependencies:
+
+| Service/Dependency | Timeout   | Retries | Backoff Strategy     | Notes                |
+|--------------------|-----------|---------|----------------------|----------------------|
+| Database queries   | 5000ms    | 2       | None (fail fast)     | Connection pooled    |
+| Redis cache        | 1000ms    | 1       | None                 | Cache miss = OK      |
+| Payment API        | 30000ms   | 3       | Exponential (1s,2s,4s)| Must complete        |
+| Email service      | 5000ms    | 3       | Fixed (2s)           | Queue if fails       |
+| External REST APIs | 10000ms   | 2       | Exponential          | Circuit breaker      |
+| File storage (S3)  | 15000ms   | 3       | Exponential          | Large files          |
+
+Your policies:
+
+| Service/Dependency | Timeout   | Retries | Backoff Strategy     | Notes                |
+|--------------------|-----------|---------|----------------------|----------------------|
+|                    |           |         |                      |                      |
+|                    |           |         |                      |                      |
+
+Global defaults:
+- Default HTTP timeout: __ ms (recommended: 10000)
+- Default retries: __ (recommended: 2)
+- Default backoff: [None/Fixed/Exponential]
+
+Non-retryable errors:
+- 400 Bad Request (client error, won't succeed on retry)
+- 401/403 Unauthorized/Forbidden
+- 404 Not Found
+- [Your additions]
+```
+
+**7.9.4 Request/Response Logging & Masking**
+
+```
+What request/response data will you log?
+
+Log levels by environment:
+| Environment | Level    | Body Logging | Performance Logging |
+|-------------|----------|--------------|---------------------|
+| Development | debug    | Full         | Yes                 |
+| Staging     | info     | Truncated    | Yes                 |
+| Production  | info     | Minimal      | Yes                 |
+
+Request logging:
+- ✅ HTTP method and URL
+- ✅ Request ID (correlation)
+- ✅ User ID (if authenticated)
+- ✅ IP address (optional, may hash for privacy)
+- ✅ Request duration (ms)
+- ❓ Request body (careful with size and PII)
+- ❓ Query parameters
+
+Response logging:
+- ✅ Status code
+- ✅ Response duration (ms)
+- ❓ Response body (careful with size)
+
+Sensitive data masking (CRITICAL):
+
+| Field Pattern          | Masking Strategy           |
+|------------------------|----------------------------|
+| password, secret       | Completely redact          |
+| token, api_key         | Show last 4 chars only     |
+| email                  | j***@example.com           |
+| phone                  | ***-***-1234               |
+| credit_card            | ****-****-****-1234        |
+| ssn, national_id       | Completely redact          |
+| [Your patterns]        | __                         |
+
+Log format:
+A) ⭐ Structured JSON (recommended for aggregation)
+B) Plain text with patterns
+C) Framework default
+
+Log aggregation:
+A) ⭐ Centralized (ELK, Datadog, CloudWatch)
+B) File-based with rotation
+C) Console only (development)
+```
+
+**7.10 Documentation & Runbooks**
+
+```
+
+Operational documentation:
+
+A) ✅ Deployment guide - How to deploy
+B) ✅ Runbooks - How to handle incidents
+
+- Database connection failure → steps to diagnose/fix
+- High CPU usage → steps to investigate
+- Service down → recovery procedure
+
+C) ✅ Architecture diagrams (Mermaid format)
+
+- System architecture diagram (mermaid)
+- Data flow diagram (mermaid)
+- Infrastructure diagram (mermaid)
+
+D) ✅ API documentation
+
+- Swagger/OpenAPI
+- Auto-generated from code
+
+Will you create these?
+A) Yes - All of them ⭐
+B) Yes - Critical ones only (deployment, runbooks)
+C) Later - Start without docs
+
+API documentation strategy:
+A) ⭐ Code-First (Recommended)
 
-Phases 1-7 completed:
-✅ project-brief.md (Phase 1)
-✅ docs/app-structure.md (Phase 2)
-✅ docs/architecture.md (Phase 3)
-✅ ai-instructions.md (Phase 3)
-✅ docs/code-standards.md (Phase 5)
-✅ docs/testing.md (Phase 6)
-✅ docs/app-store.md (Phase 7)
-✅ specs/build-configuration.md (Phase 7)
-✅ specs/deployment.md (Phase 7)
-✅ .env.example (Phase 7)
+- Generate docs from code (Swagger/OpenAPI decorators)
+- Always in sync with code
+- Tools: @nestjs/swagger, FastAPI docs
 
-Remaining:
-⏭️  Phase 8: Project setup & final documentation
----
-🎯 Next: Phase 8 - Project Setup & Final Documentation
----
-Phase 8 will:
-- 🔍 Detect project state (new vs existing)
-- 🚀 Initialize framework (optional, for new projects)
-- 📝 Generate final docs (platform-guides, navigation-guide, contributing)
-- 📖 Generate AGENT.md (master documentation index)
-- 📄 Generate README.md (with intelligent merge if needed)
-- 🤖 Create tool-specific configs (based on AI selection)
+B) 📝 Design-First
 
-Continue to Phase 8? (yes/no)
+- Write openapi.yaml manually first
+- Generate code from spec
+- Better for large teams/contracts
+
+C) 📄 Manual
+
+- Write Markdown/Notion docs
+- Hard to keep in sync (Not recommended)
+
+```
+
+---
+
+#### 🎨 MERMAID OPERATIONS DIAGRAM FORMATS - CRITICAL
+
+## **Use these exact formats** for operational and infrastructure diagrams mentioned in question 7.10:
+
+##### 1️⃣ System Architecture Diagram (Deployment View)
+
+Use `graph TD` to show deployed system components with scaling and redundancy:
+
+````markdown
+```mermaid
+graph TD
+    subgraph "Production Environment"
+        subgraph "Load Balancer Layer"
+            LB1[Load Balancer 1]
+            LB2[Load Balancer 2]
+        end
+
+        subgraph "Application Layer"
+            App1[API Server 1<br/>4 vCPU, 8GB RAM]
+            App2[API Server 2<br/>4 vCPU, 8GB RAM]
+            App3[API Server 3<br/>4 vCPU, 8GB RAM]
+        end
+
+        subgraph "Data Layer"
+            Primary[(Primary DB<br/>PostgreSQL 15)]
+            Replica1[(Read Replica 1)]
+            Replica2[(Read Replica 2)]
+            Cache[Redis Cluster<br/>3 Nodes]
+        end
+
+        subgraph "Message Queue"
+            Queue[RabbitMQ Cluster<br/>3 Nodes]
+        end
+    end
+
+    Internet[Internet] -->|HTTPS| LB1
+    Internet -->|HTTPS| LB2
+    LB1 --> App1
+    LB1 --> App2
+    LB2 --> App2
+    LB2 --> App3
+
+    App1 -->|Write| Primary
+    App2 -->|Write| Primary
+    App3 -->|Write| Primary
+
+    App1 -->|Read| Replica1
+    App2 -->|Read| Replica2
+    App3 -->|Read| Replica1
+
+    App1 -->|Cache| Cache
+    App2 -->|Cache| Cache
+    App3 -->|Cache| Cache
+
+    App1 -->|Async Jobs| Queue
+    App2 -->|Async Jobs| Queue
+    App3 -->|Async Jobs| Queue
+
+    Primary -.->|Replication| Replica1
+    Primary -.->|Replication| Replica2
+
+    style Internet fill:#e1f5ff
+    style Primary fill:#e1ffe1
+    style Cache fill:#f0e1ff
+    style Queue fill:#ffe1f5
+```
+````
+
+## **Use for:** Showing deployed infrastructure, scaling configuration, redundancy, high availability
+
+##### 2️⃣ Data Flow Diagram (Request Flow)
+
+Use `flowchart LR` to show how data moves through the system step-by-step:
+
+````markdown
+```mermaid
+flowchart LR
+    User[User Request] -->|1. HTTPS POST| LB[Load Balancer]
+    LB -->|2. Route| API[API Server]
+    API -->|3. Validate JWT| Auth[Auth Service]
+    Auth -->|4. Token Valid| API
+
+    API -->|5. Check Cache| Cache[(Redis Cache)]
+    Cache -->|6. Cache Miss| API
+
+    API -->|7. Query| DB[(PostgreSQL)]
+    DB -->|8. Data| API
+
+    API -->|9. Store in Cache| Cache
+    API -->|10. Enqueue Job| Queue[Message Queue]
+
+    Queue -->|11. Process| Worker[Background Worker]
+    Worker -->|12. Send Email| Email[Email Service]
+
+    API -->|13. JSON Response| User
+
+    style User fill:#e1f5ff
+    style Cache fill:#f0e1ff
+    style DB fill:#e1ffe1
+    style Email fill:#fff4e1
+```
+````
+
+## **Use for:** Documenting request/response cycles, async processing flows, numbered execution steps
+
+##### 3️⃣ Infrastructure Diagram (Cloud Resources)
+
+Use `graph TB` with subgraphs to show cloud infrastructure and network topology:
+
+````markdown
+```mermaid
+graph TB
+    subgraph "AWS Cloud - Production (us-east-1)"
+        subgraph "VPC (10.0.0.0/16)"
+            subgraph "Public Subnet (10.0.1.0/24)"
+                ALB[Application Load Balancer]
+                NAT[NAT Gateway]
+            end
+
+            subgraph "Private Subnet 1 (10.0.10.0/24)"
+                ECS1[ECS Cluster<br/>Auto Scaling Group]
+                App1[Container: API<br/>Fargate Task]
+                App2[Container: API<br/>Fargate Task]
+            end
+
+            subgraph "Private Subnet 2 (10.0.20.0/24)"
+                RDS[(RDS PostgreSQL<br/>Multi-AZ)]
+                ElastiCache[ElastiCache Redis<br/>Cluster Mode]
+            end
+
+            subgraph "Private Subnet 3 (10.0.30.0/24)"
+                SQS[Amazon SQS<br/>Message Queue]
+                Lambda[Lambda Functions<br/>Background Workers]
+            end
+        end
+
+        subgraph "Supporting Services"
+            S3[S3 Bucket<br/>File Storage]
+            CloudWatch[CloudWatch<br/>Monitoring & Logs]
+            SecretsManager[Secrets Manager<br/>API Keys & Credentials]
+        end
+    end
+
+    Internet[Internet Users] -->|HTTPS| ALB
+    ALB --> App1
+    ALB --> App2
+
+    App1 --> RDS
+    App2 --> RDS
+    App1 --> ElastiCache
+    App2 --> ElastiCache
+
+    App1 -->|Upload/Download| S3
+    App2 -->|Upload/Download| S3
+
+    App1 -->|Send Message| SQS
+    SQS -->|Trigger| Lambda
+    Lambda --> RDS
+
+    App1 -->|Logs & Metrics| CloudWatch
+    App2 -->|Logs & Metrics| CloudWatch
+    Lambda -->|Logs| CloudWatch
+
+    App1 -->|Fetch Secrets| SecretsManager
+    App2 -->|Fetch Secrets| SecretsManager
+
+    style Internet fill:#e1f5ff
+    style RDS fill:#e1ffe1
+    style ElastiCache fill:#f0e1ff
+    style S3 fill:#fff4e1
+    style CloudWatch fill:#ffe1e1
+```
+````
+
+## **Use for:** Documenting cloud architecture, network topology, AWS/GCP/Azure resources, VPC design
+
+##### 4️⃣ Monitoring & Observability Diagram (Optional)
+
+Use `graph TD` to show monitoring, logging, and alerting stack:
+
+````markdown
+```mermaid
+graph TD
+    subgraph "Application Layer"
+        App[API Servers]
+        Worker[Background Workers]
+    end
+
+    subgraph "Monitoring Stack"
+        Prometheus[Prometheus<br/>Metrics Collection]
+        Grafana[Grafana<br/>Dashboards]
+        AlertManager[Alert Manager<br/>Notifications]
+    end
+
+    subgraph "Logging Stack"
+        FluentBit[Fluent Bit<br/>Log Collector]
+        Elasticsearch[Elasticsearch<br/>Log Storage]
+        Kibana[Kibana<br/>Log Viewer]
+    end
+
+    subgraph "Tracing"
+        Jaeger[Jaeger<br/>Distributed Tracing]
+    end
+
+    subgraph "Alerts"
+        PagerDuty[PagerDuty]
+        Slack[Slack Notifications]
+    end
+
+    App -->|Metrics| Prometheus
+    Worker -->|Metrics| Prometheus
+    Prometheus --> Grafana
+    Prometheus --> AlertManager
+
+    App -->|Logs| FluentBit
+    Worker -->|Logs| FluentBit
+    FluentBit --> Elasticsearch
+    Elasticsearch --> Kibana
+
+    App -->|Traces| Jaeger
+    Worker -->|Traces| Jaeger
+
+    AlertManager --> PagerDuty
+    AlertManager --> Slack
+
+    style Grafana fill:#e1f5ff
+    style Kibana fill:#f0e1ff
+    style PagerDuty fill:#ffe1e1
+```
+````
+
+## **Use for:** Documenting observability strategy, monitoring infrastructure, alerting workflows
+
+**Best Practices for Operations Diagrams:**
+
+1. **Include Resource Specs:** Add CPU/RAM/disk info to nodes (e.g., `[API Server<br/>4 vCPU, 8GB RAM]`)
+2. **Show Redundancy:** Display load balancers, replicas, multi-AZ deployments, failover paths
+3. **Label Network Boundaries:** Use subgraphs for VPCs, subnets, availability zones, regions
+4. **Document Protocols:** Label connections with HTTPS, gRPC, TCP, WebSocket, etc.
+5. **Add IP Ranges:** Include CIDR blocks for network subnets (e.g., `10.0.1.0/24`)
+6. **Show Auto-Scaling:** Indicate which components scale horizontally/vertically
+7. **Include External Services:** SaaS tools, third-party APIs, CDNs, email providers
+8. **Color Code by Layer:** Infrastructure (blue), data (green), monitoring (purple), alerts (red)
+
+**Common Formatting Rules:**
+
+- Code fence: ` ```mermaid ` (lowercase, no spaces, three backticks)
+- Use `subgraph "Name"` to group related components by layer/zone
+- Use `[(Cylinder)]` for databases, data stores, and persistent storage
+- Use `[Square Brackets]` for services, servers, and compute resources
+- Use dotted arrows `-.->` for replication, backup, and async flows
+- Apply consistent styling: `style NodeName fill:#colorcode`
+
+**Deployment Context Examples:**
+
+- For Docker: Show containers, volumes, networks, registries
+- For Kubernetes: Show pods, services, ingress, namespaces, persistent volumes
+- For Serverless: Show Lambda functions, API Gateway, S3 triggers, event sources
+- For VMs: Show instances, security groups, load balancers, auto-scaling groups
+
+## **Validation:** Test diagrams at https://mermaid.live/ before saving to ensure syntax is correct
+
+### Phase 7 Output
+
+```
+📋 PHASE 7 SUMMARY:
+
+Deployment Environment: [cloud/PaaS/on-premises/container-orchestration + platform choice + rationale] (7.1)
+Containerization: [yes/no + Docker setup (base image, size, compose stack)] (7.2)
+Environments: [number of environments (dev/staging/prod) + config approach (env vars/secrets/feature flags)] (7.3)
+CI/CD Pipeline: [platform (GitHub Actions/GitLab CI/etc.) + pipeline stages + auto-deploy strategy] (7.4)
+Deployment Strategy: [standard/blue-green/canary/rolling + zero-downtime approach + rollback plan] (7.4.1)
+Monitoring & Logging: [APM tool + logging strategy (centralized/structured JSON) + metrics to track] (7.5)
+Alerts: [alert conditions (error rate/response time/5xx/etc.) + channels (email/Slack/PagerDuty) + on-call rotation] (7.6)
+Backup & Disaster Recovery: [backup strategy + retention period + RTO/RPO targets] (7.7)
+Database Migrations in Production: [zero-downtime strategy + rollback plan + migration windows] (7.7.1)
+Database Connection Pooling: [pool tool + settings (min/max/timeouts) + monitoring] (7.7.2)
+Scaling Strategy: [horizontal/vertical/auto-scaling + expected load + database scaling approach] (7.8)
+Health Checks: [endpoints (/health, /health/ready, /health/live) + checks performed] (7.9)
+Graceful Shutdown: [yes/no + shutdown sequence + timeouts] (7.9.1)
+Circuit Breakers & Resilience: [yes/no + tool + configuration + fallback strategies] (7.9.2)
+Documentation & Runbooks: [what will be created (deployment guide/runbooks/architecture diagrams in mermaid format/API docs) + API doc strategy (code-first/design-first)] (7.10)
+
+Is this correct? (Yes/No)
+```
+
+---
+
+### 📄 Generate Phase 7 Documents
+
+**Before starting generation:**
+
+```
+📖 Loading context from previous phases...
+✅ Re-reading docs/testing.md
+✅ Re-reading ai-instructions.md
+```
+
+**Generate documents automatically:**
+
+**1. `docs/operations.md`**
+
+- Use template: `.ai-flow/templates/docs/operations.template.md`
+- Fill with deployment, monitoring, alerting, backup, scaling
+- Write to: `docs/operations.md`
+
+**2. `specs/configuration.md`**
+
+- Use template: `.ai-flow/templates/specs/configuration.template.md`
+- Fill with environment variables, secrets management, feature flags
+- Write to: `specs/configuration.md`
+
+**3. `.env.example`**
+
+- List all environment variables needed
+- Include comments explaining each variable
+- Write to: `.env.example`
+
+```
+✅ Generated: docs/operations.md
+✅ Generated: specs/configuration.md
+✅ Generated: .env.example
+
+Documents have been created with all Phase 7 information.
+
+📝 Would you like to make any corrections before continuing?
+
+→ If yes: Edit the files and type "ready" when done. I'll re-read them.
+→ If no: Type "continue" to proceed to final checkpoint.
+```
+
+**If user edits files:**
+Re-read files to refresh context before continuing.
+
+---
+
+### Phase 7 Completion
+
+```
+✅ Phase 7 Complete!
+
+Generated documents:
+✅ docs/operations.md
+✅ specs/configuration.md
+✅ .env.example
+
+📝 Would you like to review these documents before proceeding to Phase 8?
+
+→ If yes: Edit the files and type "ready" when done.
+→ If no: Type "continue" to proceed to Phase 8.
 ```
----
-**Last Updated:** 2025-12-09
 
-**Version:** 2.0.0 (Unified workflow with Phase 8)
+---
+
+## 📝 Generated Documents
+
+After Phase 7, generate/update:
+
+- `docs/operations.md` - Operations and deployment guide
+- `specs/configuration.md` - Configuration specification  
+- `.env.example` - Environment variables template
+
+---
+
+**Next Phase:** Phase 8 - Project Setup & Final Documentation
 
+Read: `.ai-flow/prompts/backend/flow-build-phase-8.md`
 
+---
 
+**Last Updated:** 2025-12-20
 
+**Version:** 2.1.8