ai-flow-dev 2.2.0 → 2.2.1

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

@@ -1,371 +1,703 @@
-# Phase 5: Code Standards & Best Practices
+## PHASE 5: Code Standards (15-20 min)
 
-**Duration:** 15-20 minutes
-**Questions:** ~10 questions
-**Output:** docs/code-standards.md, parts of ai-instructions.md
----
-## 🎯 Objective
+> **Order for this phase:** 5.1 → 5.2 → 5.3 → 5.4 → 5.5 → 5.6 → 5.7 → 5.8 → 5.9 → 5.10 → 5.11 → 5.12 → 5.13
 
-Define coding conventions and standards for your mobile app:
+> **📌 Scope-based behavior:**
+>
+> - **MVP:** Ask 5.1-5.5 only (formatting, naming, structure, coverage target, Git workflow), skip 5.6-5.13 (advanced practices)
+> - **Production-Ready:** Ask all questions 5.1-5.13
+> - **Enterprise:** Ask all questions 5.1-5.13 with emphasis on governance and documentation
 
-1. File and component naming conventions
-2. Code formatting and linting rules
-3. Import organization
-4. Commit message standards
-5. Mobile-specific best practices
----
-## 📋 Questions
+### Objective
 
-### Question 5.1: File Naming Convention
+Establish code quality rules, naming conventions, and development practices.
 
-**How will you name your files?**
+---
 
-**If React Native:**
+## 🔍 Pre-Flight Check (Smart Skip Logic)
 
-- A) ⭐ **PascalCase for components** (Recommended)
-  - Components: `UserProfile.tsx`, `Button.tsx`
-  - Screens: `HomeScreen.tsx`, `ProfileScreen.tsx`
-  - Hooks: `useAuth.ts`, `useLocalStorage.ts`
-  - Utils: `formatDate.ts`, `apiClient.ts`
+> 📎 **Reference:** See [prompts/shared/smart-skip-preflight.md](../shared/smart-skip-preflight.md) for the complete smart skip logic.
 
-- B) **kebab-case for all files**
-  - Components: `user-profile.tsx`, `button.tsx`
+**Execute Pre-Flight Check for Phase 5:**
 
-**If Flutter:**
+- **Target File**: `docs/code-standards.md`
+- **Phase Name**: "CODE STANDARDS"
+- **Key Items**: Linters, formatters, naming conventions, code review process
+- **Typical Gaps**: Team-specific conventions, code review workflow
 
-- A) ⭐ **snake_case** (Dart convention)
-  - Files: `user_profile.dart`, `home_screen.dart`
-  - Classes: `UserProfile`, `HomeScreen`
+**Proceed with appropriate scenario based on audit data from `.ai-flow/cache/audit-data.json`**
 
-**If Native iOS:**
+---
 
-- A) ⭐ **PascalCase** (Swift convention)
-  - Files: `UserProfile.swift`, `HomeViewController.swift`
+## Phase 5 Questions (Full Mode)
 
-**If Native Android:**
+**5.1 Code Style & Formatting**
 
-- A) ⭐ **PascalCase for classes, camelCase for files** (Kotlin convention)
-  - Files: `UserProfile.kt`, `HomeActivity.kt`
-
-**Your answer:**
----
-### Question 5.2: Component/Screen Naming Convention
+```
+Formatting preferences:
 
-**How will you name components and screens?**
+Indentation:
+A) ⭐ 2 spaces - Recommended for JavaScript/TypeScript
+B) 4 spaces - Common for Python, Java
+C) Tabs
 
-**If React Native:**
+Quotes:
+A) ⭐ Single quotes - 'text' (JavaScript)
+B) Double quotes - "text" (Python, Java)
 
-- A) ⭐ **PascalCase** (Recommended)
-  - Components: `<UserProfile />`, `<Button />`
-  - Screens: `<HomeScreen />`, `<ProfileScreen />`
+Line length:
+A) ⭐ 80 characters - Traditional
+B) 100 characters - Modern balance
+C) 120 characters - Wide screens
 
-**If Flutter:**
+Semicolons (JavaScript/TypeScript):
+A) ⭐ Required - Always use semicolons
+B) Optional - ASI (Automatic Semicolon Insertion)
 
-- A) ⭐ **PascalCase for widgets**
-  - Widgets: `UserProfile`, `HomeScreen`
+Trailing commas:
+A) ⭐ Yes - ES5+ compatible, cleaner diffs
+B) No
 
-**If Native:**
+Formatter & Linter:
+A) ⭐ Prettier + ESLint - Recommended combination
+   - Prettier: Auto-format on save (style/formatting)
+   - ESLint: Code quality and error detection
+   - Use eslint-config-prettier to avoid conflicts
 
-- A) ⭐ **PascalCase for classes**
-  - iOS: `UserProfileViewController`
-  - Android: `UserProfileActivity`
+B) ESLint only - With formatting rules
+   - Handles both linting and formatting
+   - More config overhead
 
-**Your answer:**
+C) Prettier only - Formatting without linting
+   - Fast, opinionated formatting
+   - No code quality checks
 
-**Named exports vs default exports?**
+D) EditorConfig only - Basic cross-editor consistency
 
-**If React Native:**
+E) Manual formatting - Not recommended
 
-- A) ⭐ **Named exports** (Recommended)
+Your choice: __
+```
 
-  ```typescript
-  export const Button = () => { ... }
-  // Usage: import { Button } from './Button'
-  ```
+**5.2 Naming Conventions**
 
-- B) **Default exports**
-  ```typescript
-  export default function Button() { ... }
-  ```
+```
+Naming style by type:
 
-**Your answer:**
----
-### Question 5.3: Linting & Formatting
+Files:
+A) ⭐ kebab-case - user-service.ts, api-controller.ts
+B) camelCase - userService.ts, apiController.ts
+C) PascalCase - UserService.ts, ApiController.ts
 
-**What linting/formatting tools will you use?**
+Classes/Interfaces:
+A) ✅ PascalCase - UserService, IUserRepository
 
-**If React Native:**
+Functions/Methods:
+A) ✅ camelCase - getUserById, createOrder
 
-- A) ⭐ **ESLint + Prettier** (Recommended)
-  - ESLint: Code quality rules
-  - Prettier: Code formatting
+Variables:
+A) ✅ camelCase - userName, totalPrice
 
-- B) **Biome** (All-in-one, faster)
+Constants:
+A) ✅ UPPER_SNAKE_CASE - MAX_RETRIES, API_BASE_URL
 
-**If Flutter:**
+Interfaces (TypeScript):
+A) ⭐ I-prefix - IUserService, IRepository
+B) No prefix - UserService, Repository
+C) -Interface suffix - UserServiceInterface
 
-- A) ⭐ **dart format** (Built-in)
-- B) **dart analyze** (Linting)
+Boolean variables:
+A) ✅ is/has/can prefix - isActive, hasPermission, canEdit
+```
 
-**If Native iOS:**
+**5.3 File Organization**
 
-- A) ⭐ **SwiftLint** (Recommended)
-- B) **SwiftFormat**
+> **Note:** The AI will adapt the following examples to match your selected language/framework from Phase 3 (questions 3.1 and 3.2). File extensions, naming conventions, and folder names will be automatically adjusted.
 
-**If Native Android:**
+```
+Project structure approach:
+
+A) ⭐ Feature-based (Modular) - Recommended for most projects
+
+Group by feature/module with subfolders for organization:
+
+[DYNAMIC EXAMPLE - AI will adapt based on your stack]
+
+TypeScript/NestJS example:
+src/
+  modules/
+    users/
+      dto/
+        create-user.dto.ts
+        update-user.dto.ts
+      entities/
+        user.entity.ts
+      users.controller.ts
+      users.service.ts
+      users.repository.ts
+      users.module.ts
+    orders/
+      dto/
+      entities/
+      orders.controller.ts
+  common/
+    guards/
+    interceptors/
+  config/
+
+Python/FastAPI example:
+src/
+  modules/
+    users/
+      schemas/
+        user_create.py
+        user_update.py
+      models/
+        user.py
+      users_controller.py
+      users_service.py
+      users_repository.py
+    orders/
+      schemas/
+      models/
+  common/
+    dependencies/
+    middleware/
+
+Java/Spring Boot example:
+src/main/java/com/myapp/
+  modules/
+    users/
+      dto/
+        CreateUserDto.java
+        UpdateUserDto.java
+      domain/
+        User.java
+      UsersController.java
+      UsersService.java
+      UsersRepository.java
+    orders/
+  common/
+    config/
+    security/
+
+Go example:
+src/
+  modules/
+    users/
+      models/
+        user.go
+      handlers/
+        user_handler.go
+      services/
+        user_service.go
+      repositories/
+        user_repository.go
+    orders/
+  common/
+    middleware/
+
+C#/.NET Core example:
+src/
+  Modules/
+    Users/
+      DTOs/
+        CreateUserDto.cs
+        UpdateUserDto.cs
+      Entities/
+        User.cs
+      UsersController.cs
+      UsersService.cs
+      UsersRepository.cs
+    Orders/
+      DTOs/
+      Entities/
+  Common/
+    Middleware/
+    Extensions/
+
+Benefits: Scalable, easy to find related code, clear module boundaries
+---
+B) 🏆 Feature-based (Flat) - Simple projects
+
+Flat structure within each feature (AI will adapt naming):
+
+src/
+  users/
+    user_controller
+    user_service
+    user_repository
+    user_dto
+    user_entity
+  orders/
+    order_controller
+    order_service
+    ...
+
+Benefits: Simpler, fewer folders, good for small projects
+---
+C) Layer-based (Traditional) - Legacy style
+
+Group by technical layer/type (AI will adapt naming):
+
+src/
+  controllers/
+    user_controller
+    order_controller
+  services/
+    user_service
+    order_service
+  repositories/
+    user_repository
+    order_repository
+  entities/
+    user_entity
+    order_entity
+  dto/
+    create_user_dto
+    create_order_dto
+
+Benefits: Clear separation by type, familiar for MVC developers
+Drawbacks: Hard to see feature boundaries, files scattered
+---
+D) Hybrid - Domain + Shared layers
+
+Modules for features + shared technical folders (AI will adapt):
+
+src/
+  modules/
+    users/
+      (feature code)
+    orders/
+      (feature code)
+  shared/
+    services/
+    utils/
+  infrastructure/
+    database/
+    cache/
+
+Your choice: __
+Why?
+---
+After you select, the AI will generate the exact folder structure with proper:
+- File extensions (.ts, .py, .java, .go)
+- Naming conventions (camelCase, snake_case, PascalCase)
+- Framework-specific folders (dto vs schemas, entities vs models vs domain)
+- Common patterns for your chosen stack
+```
 
-- A) ⭐ **ktlint** (Recommended)
-- B) **Detekt**
+**5.4 Import Organization**
 
-**Your answer:**
+```
+Import ordering:
 
-**ESLint config (if React Native):**
+A) ⭐ Recommended order:
+1.  External libraries (react, express, etc.)
+2.  Internal modules (@/services, @/utils)
+3.  Relative imports (./user.dto, ../shared)
+4.  Types/Interfaces
+5.  Styles/Assets
 
-- A) ⭐ **@react-native-community/eslint-config**
-- B) **eslint-config-airbnb**
-- C) **Custom config**
----
-### Question 5.4: Import Organization
+B) Alphabetical
+C) No specific order
 
-**How will you organize imports?**
+Path aliases:
+A) ✅ Yes - Use @ for src root
+- import { UserService } from '@/services/user.service';
 
-**If React Native:**
+B) No - Use relative paths only
+```
 
-```typescript
-// 1. External libraries
-import React from 'react';
-import { useQuery } from '@tanstack/react-query';
+**5.5 TypeScript/Type Rules**
 
-// 2. Internal modules
-import { Button } from '@/components/Button';
-import { useAuth } from '@/hooks/useAuth';
+```
+(Skip if not using TypeScript)
+
+A) ✅ Strict mode - Enable all strict checks ⭐
+B) ❌ any allowed - Use any when needed (not recommended)
+C) ⚠️ Gradual typing - Start loose, tighten over time
+
+Rules:
+- ✅ No implicit any
+- ✅ Strict null checks
+- ✅ No unused variables
+- ✅ Explicit function return types
+- ✅ Interface over type (when possible)
+
+Type preference:
+A) Interfaces for object shapes
+B) Types for unions/intersections
+C) Mix both as needed ⭐
+```
 
-// 3. Relative imports
-import { UserCard } from './UserCard';
+**5.6 Error Handling**
 
-// 4. Types
-import type { User } from '@/types';
 ```
+Error handling strategy:
 
-**If Flutter:**
+A) ⭐ Try-catch with custom error classes
+- Centralized error handler
+- HTTP error mapping
+- Detailed error messages
 
-```dart
-// 1. Dart SDK
-import 'dart:async';
+B) Error codes/enums
+- Consistent error codes across app
 
-// 2. External packages
-import 'package:flutter/material.dart';
-import 'package:provider/provider.dart';
+C) Result pattern
+- Never throw, return Result<T, Error>
 
-// 3. Internal modules
-import 'package:myapp/models/user.dart';
-import 'package:myapp/services/auth_service.dart';
+Your approach: __
+
+Error logging:
+A) ⭐ All errors logged with context
+B) Only server errors (5xx)
+C) Errors + warnings
+
+Error responses to client:
+A) ⭐ Detailed in dev, generic in production
+- Dev: Full stack trace
+- Prod: Error code + user-friendly message
+
+B) Always detailed
+C) Always generic
 ```
 
-**Your answer:**
+**5.7 Comments & Documentation**
 
-**Import alias for src/?**
+````
+When to comment:
 
-- `@/` (React Native)
-- `~/` (Alternative)
-- No alias (relative paths only)
----
-### Question 5.5: TypeScript/Dart Strictness
+A) ⭐ Recommended approach:
+- Complex business logic
+- Non-obvious solutions
+- TODOs and FIXMEs
+- Public APIs (JSDoc/Docstrings)
+- Configuration decisions
 
-**How strict should TypeScript/Dart be?**
+B) Minimal comments - Self-documenting code only
+C) Extensive comments - Every function
 
-**If React Native (TypeScript):**
+Doc comments:
+A) ✅ JSDoc for TypeScript/JavaScript
+B) ✅ Docstrings for Python
+C) ✅ JavaDoc for Java
 
-- A) ⭐ **Strict mode** (Recommended)
+Example:
+```typescript
+/**
+ * Calculates user's total order value for the current month
+ * @param userId - The unique user identifier
+ * @param includeDiscounts - Whether to apply promotional discounts
+ * @returns Total value in cents
+ */
+async function calculateMonthlyTotal(
+  userId: string,
+  includeDiscounts: boolean
+): Promise<number>;
+```
 
-  ```json
-  {
-    "strict": true,
-    "noUncheckedIndexedAccess": true
-  }
-  ```
+````
 
-- B) **Moderate**
-- C) **Lenient**
+**5.8 Testing Standards**
 
-**If Flutter (Dart):**
+```
 
-- A) ⭐ **Strict analysis** (Recommended)
-  ```yaml
-  analyzer:
-    errors:
-      invalid_annotation_target: error
-  ```
+Test coverage requirements:
 
-**Your answer:**
+Minimum coverage:
+A) 🏆 80%+ - Enterprise standard
+B) ⭐ 70%+ - Recommended for most projects
+C) 50%+ - Minimum acceptable
+D) No requirement
 
-**`any` type policy (TypeScript):**
+What to test:
 
-- A) ❌ Never allow `any`
-- B) ⚠️ Allow with warning
-- C) ✅ Allow freely (not recommended)
----
-### Question 5.6: Code Comments
+- ✅ Services/Business logic - 80%+ coverage
+- ✅ Controllers/Routes - 60%+ coverage
+- ✅ Utilities/Helpers - 90%+ coverage
+- ✅ Database repositories - 70%+ coverage
+- ❓ DTOs/Entities - Usually no tests needed
 
-**What's your commenting policy?**
+Test file naming:
+A) ⭐ .spec.ts / .test.ts - Next to source file
+B) Separate tests/ folder
 
-A) ⭐ **JSDoc for public APIs, inline for complex logic** (Recommended)
+Mocking strategy:
+A) ⭐ Mock external dependencies (DB, APIs)
+B) Integration tests with real DB
+C) Mix: Unit tests mock, integration tests don't
 
-```typescript
-/**
- * Fetches user data from the API
- * @param userId - The user's unique identifier
- * @returns User object or null if not found
- */
-export async function fetchUser(userId: string): Promise<User | null> {
-  // Check cache first
-  const cached = cache.get(userId);
-  if (cached) return cached;
-  return api.get(`/users/${userId}`);
-}
 ```
 
-B) **JSDoc everywhere**
-C) **Minimal comments**
-D) **No comment policy**
+**5.9 Code Complexity Limits**
 
-**Your answer:**
----
-### Question 5.7: Component/Screen Structure
+```
 
-**How will you structure components and screens?**
+Code quality metrics:
 
-**If React Native:**
+Function length:
+A) ⭐ Max 50 lines per function
+B) Max 100 lines
+C) No limit
 
-```
-screens/
-├── HomeScreen/
-│   ├── HomeScreen.tsx
-│   ├── HomeScreen.test.tsx
-│   ├── HomeScreen.styles.ts
-│   └── index.ts
-```
+Cyclomatic complexity:
+A) ⭐ Max complexity 10
+B) Max complexity 15
+C) No limit
 
-**If Flutter:**
+Parameters:
+A) ⭐ Max 4 parameters (use object for more)
+B) Max 6 parameters
+C) No limit
+
+Nesting depth:
+A) ⭐ Max 3 levels
+B) Max 4 levels
+C) No limit
 
 ```
-lib/
-├── screens/
-│   ├── home_screen.dart
-│   └── home_screen_test.dart
+
+**5.10 Git Commit Standards**
+
+````
+
+Commit message format:
+
+A) ⭐ Conventional Commits
+
 ```
 
-**Your answer:**
----
-### Question 5.8: Error Handling Patterns
+<type>(<scope>): <subject>
+
+<body>
 
-**How will you handle errors?**
+<footer>
+```
 
-**If React Native:**
+Types: feat, fix, docs, style, refactor, test, chore
 
-- A) ⭐ **Error Boundaries + Try-Catch**
-  - Error Boundaries for render errors
-  - Try-Catch for async errors
+Example:
 
-**If Flutter:**
+```
+feat(auth): add JWT refresh token rotation
 
-- A) ⭐ **Try-Catch + Global Error Handler**
-  - FlutterError.onError for global errors
+- Implement token rotation on every refresh
+- Store refresh tokens in Redis
+- Add expiration cleanup job
 
-**If Native:**
+Closes #123
+```
 
-- A) ⭐ **Try-Catch + Crash Reporting**
-  - Sentry, Firebase Crashlytics
+B) Simple descriptive messages
+C) No standard
 
-**Your answer:**
+Branch naming:
+A) ⭐ feature/description, bugfix/description, hotfix/description
+B) Your initials + description (e.g., jd/add-auth)
+C) No standard
 
-**Error logging:**
+````
 
-- Firebase Crashlytics
-- Sentry
-- Console only (development)
----
-### Question 5.9: Mobile-Specific Best Practices
+**5.11 Versioning & Changelog**
 
-**What mobile-specific practices will you enforce?**
+```
 
-Select all that apply:
+Versioning policy:
+
+What versioning scheme will you use?
+A) ⭐ SemVer (Major.Minor.Patch) (recommended)
+B) Date (YYYY.MM.DD)
+C) Other: \_\_
+
+Migration strategy:
+How will you handle breaking changes and migrations?
+A) ⭐ Document in the changelog and provide migration scripts (recommended)
+B) Only document changes
+C) Other: \_\_
+
+Changelog:
+How will you document and communicate changes?
+A) ⭐ CHANGELOG.md in the repository (recommended)
+B) Releases on GitHub/GitLab
+C) Notes in documentation
+D) Other: \_\_
+
+Who will be responsible for updating the changelog?
+A) ⭐ Tech Lead (recommended)
+B) Author of the change (who does the PR)
+C) Documentation team
+D) Other: \_\_
+Example roles: Tech Lead, release manager, PR author, documentation team, etc.
 
-- [ ] **Performance:** Avoid unnecessary re-renders
-- [ ] **Memory:** Dispose resources properly (listeners, timers)
-- [ ] **Battery:** Optimize background tasks
-- [ ] **Network:** Handle offline scenarios gracefully
-- [ ] **Permissions:** Request permissions just-in-time
-- [ ] **Accessibility:** Support screen readers (TalkBack/VoiceOver)
-- [ ] **Platform Differences:** Handle iOS vs Android differences
-- [ ] **App State:** Handle app backgrounding/foregrounding
-- [ ] **Deep Links:** Support universal links/app links
-- [ ] **Push Notifications:** Handle notification taps
+```
 
-**Your answer:**
----
-### Question 5.10: Commit Message Convention
+**5.12 Logging Standards**
 
-**What commit message format will you use?**
+```
+What logging approach will you use?
+
+Log format:
+A) ⭐ Structured JSON - Machine-readable, easy to parse (recommended)
+B) Plain text - Human-readable, traditional
+C) Both - Different formats for different environments
+
+Log levels:
+- DEBUG: Detailed debugging info (development only)
+- INFO: General information (request start, successful operations)
+- WARN: Warnings (deprecated features, recoverable errors)
+- ERROR: Errors (failed operations, exceptions)
+- FATAL: Critical errors (system failures)
+
+Default log level:
+- Development: __
+- Production: __
+
+Log context to include:
+A) Request ID (for tracing)
+B) User ID (if authenticated)
+C) IP address
+D) User agent
+E) Request path
+F) Response status
+G) Duration
+H) Error stack traces
+
+→ Your selection (e.g., A, B, E, F, G): __
+
+Log aggregation tool:
+A) ⭐ CloudWatch (AWS)
+B) Datadog
+C) ELK Stack (Elasticsearch, Logstash, Kibana)
+D) Splunk
+E) Other: __
+
+Log retention: __ days
+```
 
-A) ⭐ **Conventional Commits** (Recommended)
+**5.13 Custom Project Rules**
 
 ```
-<type>(<scope>): <subject>
+Do you have any project-specific rules for AI assistants?
+
+❌ NEVER Rules (things that should NEVER be done):
+
+Examples of NEVER rules:
+- Never use ORM X, always use ORM Y
+- Never modify files in the /legacy folder
+- Never use inline styles in components
+- Never bypass the API gateway
+
+Your custom NEVER rules:
+1. __
+2. __
+3. __
+(Leave blank if none)
+
+✅ ALWAYS Rules (things that should ALWAYS be done):
+
+Examples of ALWAYS rules:
+- Always use the company's error handling wrapper
+- Always include tenant_id in database queries
+- Always use the shared logging utility
+- Always run security scan before commit
+
+Your custom ALWAYS rules:
+1. __
+2. __
+3. __
+(Leave blank if none)
+```
 
-<body>
+### Phase 5 Output
 
-<footer>
 ```
+📋 PHASE 5 SUMMARY:
+
+Formatting: [indentation, quotes, line length, formatter + linter]
+Naming: [files, classes, functions, variables, constants, interfaces style]
+File Organization: [feature-based / layer-based / hybrid + rationale]
+Imports: [ordering strategy, path aliases]
+Type Rules: [strict mode, rules applied, type preferences]
+Error Handling: [strategy, logging approach, client response format]
+Comments: [when to comment, doc style (JSDoc/Docstrings/JavaDoc)]
+Testing: [coverage % target, what to test, file naming, mocking strategy]
+Complexity: [function length, cyclomatic complexity, parameters, nesting depth limits]
+Git: [commit format (conventional/simple), branch naming convention]
+Versioning: [scheme (SemVer/Date), migration strategy, changelog method, responsibility]
+Logging Standards: [format (JSON/text), levels, context, aggregation tool, retention]
+Custom Rules: [NEVER rules count, ALWAYS rules count]
+
+Is this correct? (Yes/No)
+```
+
+---
+
+### 📄 Generate Phase 5 Documents
+
+**Before starting generation:**
 
-- Types: feat, fix, docs, style, refactor, test, chore
-- Example: `feat(auth): add biometric login`
+```
+📖 Loading context from previous phases...
+✅ Re-reading project-brief.md
+✅ Re-reading docs/architecture.md
+✅ Re-reading ai-instructions.md
+✅ Re-reading specs/security.md
+```
 
-B) **Simple descriptive**
-C) **No convention**
+**Generate documents automatically:**
 
-**Your answer:**
+**1. `docs/code-standards.md`**
 
-**Enforce with:**
+- Use template: `.ai-flow/templates/docs/code-standards.template.md`
+- Fill with all code quality rules, naming conventions, formatting
+- Write to: `docs/code-standards.md`
 
-- commitlint (pre-commit hook)
-- Manual review
-- No enforcement
----
-## ✅ Phase 5 Completion
+**2. Update `ai-instructions.md`**
 
-After answering all questions, summarize:
+- Add code style rules to formatting section
+- Add complexity limits and testing requirements
 
 ```
----
-✅ Phase 5 Complete: Code Standards
----
-Selected Standards:
-- File Naming: PascalCase for components
-- Linting: ESLint + Prettier
-- TypeScript: Strict mode
-- Import Organization: Grouped by type
-- Error Handling: Error Boundaries + Try-Catch
-- Commit Messages: Conventional Commits
+✅ Generated: docs/code-standards.md
+✅ Updated: ai-instructions.md (code standards added)
+
+Documents have been created with all Phase 5 information.
+
+📝 Would you like to make any corrections before continuing?
 
-Proceed to Phase 6 (Testing Strategy)? (Y/n)
+→ If yes: Edit the files and type "ready" when done. I'll re-read them.
+→ If no: Type "continue" to proceed to Phase 6.
 ```
----
+
+**If user edits files:**
+Re-read files to refresh context before continuing.
+
+---
+
+**Proceed to Phase 6 only after documents are validated.**
+
+> ⚠️ **CRITICAL:** DO NOT generate README.md in this phase. README.md is ONLY generated in Phase 8 (step 8.5) after framework initialization.
+
+---
+
 ## 📝 Generated Documents
 
 After Phase 5, generate/update:
+- `docs/code-standards.md` - Development practices and quality rules
+
+---
 
-- `docs/code-standards.md` - Code standards and conventions
-- `ai-instructions.md` - Add code standards rules
----
-**Next Phase:** Phase 6 - Testing Strategy
+**Next Phase:** Phase 6 - Testing Strategy (15-20 min)
 
-Read: `.ai-flow/prompts/mobile/flow-build-phase-6-testing.md`
----
-**Last Updated:** 2025-01-XX
+Read: `.ai-flow/prompts/backend/flow-build-phase-6.md`
 
-**Version:** 1.4.0
+---
 
+**Last Updated:** 2025-12-20
+**Version:** 2.1.8
 
+---
 
+## PHASE 6: Testing Strategy (15-20 min)