@rdmind/rdmind 0.0.9-alpha.1 → 0.0.9

package/.knowledge/.ext/.bmad-core/templates/fullstack-architecture-tmpl.yaml

@@ -0,0 +1,947 @@
+# <!-- Powered by BMAD™ Core -->
+template:
+  id: fullstack-architecture-template-v2
+  name: Fullstack Architecture Document
+  version: 2.0
+  output:
+    format: markdown
+    filename: docs/architecture.md
+    title: '{{project_name}} Fullstack Architecture Document'
+
+workflow:
+  mode: interactive
+  elicitation: advanced-elicitation
+
+sections:
+  - id: introduction
+    title: Introduction
+    instruction: |
+      If available, review any provided relevant documents to gather all relevant context before beginning. At minimum, you should have access to docs/prd.md and docs/front-end-spec.md. Ask the user for any documents you need but cannot locate. This template creates a unified architecture that covers both backend and frontend concerns to guide AI-driven fullstack development.
+    elicit: true
+    content: |
+      This document outlines the complete fullstack architecture for {{project_name}}, including backend systems, frontend implementation, and their integration. It serves as the single source of truth for AI-driven development, ensuring consistency across the entire technology stack.
+
+      This unified approach combines what would traditionally be separate backend and frontend architecture documents, streamlining the development process for modern fullstack applications where these concerns are increasingly intertwined.
+    sections:
+      - id: starter-template
+        title: Starter Template or Existing Project
+        instruction: |
+          Before proceeding with architecture design, check if the project is based on any starter templates or existing codebases:
+
+          1. Review the PRD and other documents for mentions of:
+          - Fullstack starter templates (e.g., T3 Stack, MEAN/MERN starters, Django + React templates)
+          - Monorepo templates (e.g., Nx, Turborepo starters)
+          - Platform-specific starters (e.g., Vercel templates, AWS Amplify starters)
+          - Existing projects being extended or cloned
+
+          2. If starter templates or existing projects are mentioned:
+          - Ask the user to provide access (links, repos, or files)
+          - Analyze to understand pre-configured choices and constraints
+          - Note any architectural decisions already made
+          - Identify what can be modified vs what must be retained
+
+          3. If no starter is mentioned but this is greenfield:
+          - Suggest appropriate fullstack starters based on tech preferences
+          - Consider platform-specific options (Vercel, AWS, etc.)
+          - Let user decide whether to use one
+
+          4. Document the decision and any constraints it imposes
+
+          If none, state "N/A - Greenfield project"
+      - id: changelog
+        title: Change Log
+        type: table
+        columns: [Date, Version, Description, Author]
+        instruction: Track document versions and changes
+
+  - id: high-level-architecture
+    title: High Level Architecture
+    instruction: This section contains multiple subsections that establish the foundation. Present all subsections together, then elicit feedback on the complete section.
+    elicit: true
+    sections:
+      - id: technical-summary
+        title: Technical Summary
+        instruction: |
+          Provide a comprehensive overview (4-6 sentences) covering:
+          - Overall architectural style and deployment approach
+          - Frontend framework and backend technology choices
+          - Key integration points between frontend and backend
+          - Infrastructure platform and services
+          - How this architecture achieves PRD goals
+      - id: platform-infrastructure
+        title: Platform and Infrastructure Choice
+        instruction: |
+          Based on PRD requirements and technical assumptions, make a platform recommendation:
+
+          1. Consider common patterns (not an exhaustive list, use your own best judgement and search the web as needed for emerging trends):
+          - **Vercel + Supabase**: For rapid development with Next.js, built-in auth/storage
+          - **AWS Full Stack**: For enterprise scale with Lambda, API Gateway, S3, Cognito
+          - **Azure**: For .NET ecosystems or enterprise Microsoft environments
+          - **Google Cloud**: For ML/AI heavy applications or Google ecosystem integration
+
+          2. Present 2-3 viable options with clear pros/cons
+          3. Make a recommendation with rationale
+          4. Get explicit user confirmation
+
+          Document the choice and key services that will be used.
+        template: |
+          **Platform:** {{selected_platform}}
+          **Key Services:** {{core_services_list}}
+          **Deployment Host and Regions:** {{regions}}
+      - id: repository-structure
+        title: Repository Structure
+        instruction: |
+          Define the repository approach based on PRD requirements and platform choice, explain your rationale or ask questions to the user if unsure:
+
+          1. For modern fullstack apps, monorepo is often preferred
+          2. Consider tooling (Nx, Turborepo, Lerna, npm workspaces)
+          3. Define package/app boundaries
+          4. Plan for shared code between frontend and backend
+        template: |
+          **Structure:** {{repo_structure_choice}}
+          **Monorepo Tool:** {{monorepo_tool_if_applicable}}
+          **Package Organization:** {{package_strategy}}
+      - id: architecture-diagram
+        title: High Level Architecture Diagram
+        type: mermaid
+        mermaid_type: graph
+        instruction: |
+          Create a Mermaid diagram showing the complete system architecture including:
+          - User entry points (web, mobile)
+          - Frontend application deployment
+          - API layer (REST/GraphQL)
+          - Backend services
+          - Databases and storage
+          - External integrations
+          - CDN and caching layers
+
+          Use appropriate diagram type for clarity.
+      - id: architectural-patterns
+        title: Architectural Patterns
+        instruction: |
+          List patterns that will guide both frontend and backend development. Include patterns for:
+          - Overall architecture (e.g., Jamstack, Serverless, Microservices)
+          - Frontend patterns (e.g., Component-based, State management)
+          - Backend patterns (e.g., Repository, CQRS, Event-driven)
+          - Integration patterns (e.g., BFF, API Gateway)
+
+          For each pattern, provide recommendation and rationale.
+        repeatable: true
+        template: '- **{{pattern_name}}:** {{pattern_description}} - _Rationale:_ {{rationale}}'
+        examples:
+          - '**Jamstack Architecture:** Static site generation with serverless APIs - _Rationale:_ Optimal performance and scalability for content-heavy applications'
+          - '**Component-Based UI:** Reusable React components with TypeScript - _Rationale:_ Maintainability and type safety across large codebases'
+          - '**Repository Pattern:** Abstract data access logic - _Rationale:_ Enables testing and future database migration flexibility'
+          - '**API Gateway Pattern:** Single entry point for all API calls - _Rationale:_ Centralized auth, rate limiting, and monitoring'
+
+  - id: tech-stack
+    title: Tech Stack
+    instruction: |
+      This is the DEFINITIVE technology selection for the entire project. Work with user to finalize all choices. This table is the single source of truth - all development must use these exact versions.
+
+      Key areas to cover:
+      - Frontend and backend languages/frameworks
+      - Databases and caching
+      - Authentication and authorization
+      - API approach
+      - Testing tools for both frontend and backend
+      - Build and deployment tools
+      - Monitoring and logging
+
+      Upon render, elicit feedback immediately.
+    elicit: true
+    sections:
+      - id: tech-stack-table
+        title: Technology Stack Table
+        type: table
+        columns: [Category, Technology, Version, Purpose, Rationale]
+        rows:
+          - [
+              'Frontend Language',
+              '{{fe_language}}',
+              '{{version}}',
+              '{{purpose}}',
+              '{{why_chosen}}',
+            ]
+          - [
+              'Frontend Framework',
+              '{{fe_framework}}',
+              '{{version}}',
+              '{{purpose}}',
+              '{{why_chosen}}',
+            ]
+          - [
+              'UI Component Library',
+              '{{ui_library}}',
+              '{{version}}',
+              '{{purpose}}',
+              '{{why_chosen}}',
+            ]
+          - [
+              'State Management',
+              '{{state_mgmt}}',
+              '{{version}}',
+              '{{purpose}}',
+              '{{why_chosen}}',
+            ]
+          - [
+              'Backend Language',
+              '{{be_language}}',
+              '{{version}}',
+              '{{purpose}}',
+              '{{why_chosen}}',
+            ]
+          - [
+              'Backend Framework',
+              '{{be_framework}}',
+              '{{version}}',
+              '{{purpose}}',
+              '{{why_chosen}}',
+            ]
+          - [
+              'API Style',
+              '{{api_style}}',
+              '{{version}}',
+              '{{purpose}}',
+              '{{why_chosen}}',
+            ]
+          - [
+              'Database',
+              '{{database}}',
+              '{{version}}',
+              '{{purpose}}',
+              '{{why_chosen}}',
+            ]
+          - [
+              'Cache',
+              '{{cache}}',
+              '{{version}}',
+              '{{purpose}}',
+              '{{why_chosen}}',
+            ]
+          - [
+              'File Storage',
+              '{{storage}}',
+              '{{version}}',
+              '{{purpose}}',
+              '{{why_chosen}}',
+            ]
+          - [
+              'Authentication',
+              '{{auth}}',
+              '{{version}}',
+              '{{purpose}}',
+              '{{why_chosen}}',
+            ]
+          - [
+              'Frontend Testing',
+              '{{fe_test}}',
+              '{{version}}',
+              '{{purpose}}',
+              '{{why_chosen}}',
+            ]
+          - [
+              'Backend Testing',
+              '{{be_test}}',
+              '{{version}}',
+              '{{purpose}}',
+              '{{why_chosen}}',
+            ]
+          - [
+              'E2E Testing',
+              '{{e2e_test}}',
+              '{{version}}',
+              '{{purpose}}',
+              '{{why_chosen}}',
+            ]
+          - [
+              'Build Tool',
+              '{{build_tool}}',
+              '{{version}}',
+              '{{purpose}}',
+              '{{why_chosen}}',
+            ]
+          - [
+              'Bundler',
+              '{{bundler}}',
+              '{{version}}',
+              '{{purpose}}',
+              '{{why_chosen}}',
+            ]
+          - [
+              'IaC Tool',
+              '{{iac_tool}}',
+              '{{version}}',
+              '{{purpose}}',
+              '{{why_chosen}}',
+            ]
+          - [
+              'CI/CD',
+              '{{cicd}}',
+              '{{version}}',
+              '{{purpose}}',
+              '{{why_chosen}}',
+            ]
+          - [
+              'Monitoring',
+              '{{monitoring}}',
+              '{{version}}',
+              '{{purpose}}',
+              '{{why_chosen}}',
+            ]
+          - [
+              'Logging',
+              '{{logging}}',
+              '{{version}}',
+              '{{purpose}}',
+              '{{why_chosen}}',
+            ]
+          - [
+              'CSS Framework',
+              '{{css_framework}}',
+              '{{version}}',
+              '{{purpose}}',
+              '{{why_chosen}}',
+            ]
+
+  - id: data-models
+    title: Data Models
+    instruction: |
+      Define the core data models/entities that will be shared between frontend and backend:
+
+      1. Review PRD requirements and identify key business entities
+      2. For each model, explain its purpose and relationships
+      3. Include key attributes and data types
+      4. Show relationships between models
+      5. Create TypeScript interfaces that can be shared
+      6. Discuss design decisions with user
+
+      Create a clear conceptual model before moving to database schema.
+    elicit: true
+    repeatable: true
+    sections:
+      - id: model
+        title: '{{model_name}}'
+        template: |
+          **Purpose:** {{model_purpose}}
+
+          **Key Attributes:**
+          - {{attribute_1}}: {{type_1}} - {{description_1}}
+          - {{attribute_2}}: {{type_2}} - {{description_2}}
+        sections:
+          - id: typescript-interface
+            title: TypeScript Interface
+            type: code
+            language: typescript
+            template: '{{model_interface}}'
+          - id: relationships
+            title: Relationships
+            type: bullet-list
+            template: '- {{relationship}}'
+
+  - id: api-spec
+    title: API Specification
+    instruction: |
+      Based on the chosen API style from Tech Stack:
+
+      1. If REST API, create an OpenAPI 3.0 specification
+      2. If GraphQL, provide the GraphQL schema
+      3. If tRPC, show router definitions
+      4. Include all endpoints from epics/stories
+      5. Define request/response schemas based on data models
+      6. Document authentication requirements
+      7. Include example requests/responses
+
+      Use appropriate format for the chosen API style. If no API (e.g., static site), skip this section.
+    elicit: true
+    sections:
+      - id: rest-api
+        title: REST API Specification
+        condition: API style is REST
+        type: code
+        language: yaml
+        template: |
+          openapi: 3.0.0
+          info:
+            title: {{api_title}}
+            version: {{api_version}}
+            description: {{api_description}}
+          servers:
+            - url: {{server_url}}
+              description: {{server_description}}
+      - id: graphql-api
+        title: GraphQL Schema
+        condition: API style is GraphQL
+        type: code
+        language: graphql
+        template: '{{graphql_schema}}'
+      - id: trpc-api
+        title: tRPC Router Definitions
+        condition: API style is tRPC
+        type: code
+        language: typescript
+        template: '{{trpc_routers}}'
+
+  - id: components
+    title: Components
+    instruction: |
+      Based on the architectural patterns, tech stack, and data models from above:
+
+      1. Identify major logical components/services across the fullstack
+      2. Consider both frontend and backend components
+      3. Define clear boundaries and interfaces between components
+      4. For each component, specify:
+      - Primary responsibility
+      - Key interfaces/APIs exposed
+      - Dependencies on other components
+      - Technology specifics based on tech stack choices
+
+      5. Create component diagrams where helpful
+    elicit: true
+    sections:
+      - id: component-list
+        repeatable: true
+        title: '{{component_name}}'
+        template: |
+          **Responsibility:** {{component_description}}
+
+          **Key Interfaces:**
+          - {{interface_1}}
+          - {{interface_2}}
+
+          **Dependencies:** {{dependencies}}
+
+          **Technology Stack:** {{component_tech_details}}
+      - id: component-diagrams
+        title: Component Diagrams
+        type: mermaid
+        instruction: |
+          Create Mermaid diagrams to visualize component relationships. Options:
+          - C4 Container diagram for high-level view
+          - Component diagram for detailed internal structure
+          - Sequence diagrams for complex interactions
+          Choose the most appropriate for clarity
+
+  - id: external-apis
+    title: External APIs
+    condition: Project requires external API integrations
+    instruction: |
+      For each external service integration:
+
+      1. Identify APIs needed based on PRD requirements and component design
+      2. If documentation URLs are unknown, ask user for specifics
+      3. Document authentication methods and security considerations
+      4. List specific endpoints that will be used
+      5. Note any rate limits or usage constraints
+
+      If no external APIs are needed, state this explicitly and skip to next section.
+    elicit: true
+    repeatable: true
+    sections:
+      - id: api
+        title: '{{api_name}} API'
+        template: |
+          - **Purpose:** {{api_purpose}}
+          - **Documentation:** {{api_docs_url}}
+          - **Base URL(s):** {{api_base_url}}
+          - **Authentication:** {{auth_method}}
+          - **Rate Limits:** {{rate_limits}}
+
+          **Key Endpoints Used:**
+          - `{{method}} {{endpoint_path}}` - {{endpoint_purpose}}
+
+          **Integration Notes:** {{integration_considerations}}
+
+  - id: core-workflows
+    title: Core Workflows
+    type: mermaid
+    mermaid_type: sequence
+    instruction: |
+      Illustrate key system workflows using sequence diagrams:
+
+      1. Identify critical user journeys from PRD
+      2. Show component interactions including external APIs
+      3. Include both frontend and backend flows
+      4. Include error handling paths
+      5. Document async operations
+      6. Create both high-level and detailed diagrams as needed
+
+      Focus on workflows that clarify architecture decisions or complex interactions.
+    elicit: true
+
+  - id: database-schema
+    title: Database Schema
+    instruction: |
+      Transform the conceptual data models into concrete database schemas:
+
+      1. Use the database type(s) selected in Tech Stack
+      2. Create schema definitions using appropriate notation
+      3. Include indexes, constraints, and relationships
+      4. Consider performance and scalability
+      5. For NoSQL, show document structures
+
+      Present schema in format appropriate to database type (SQL DDL, JSON schema, etc.)
+    elicit: true
+
+  - id: frontend-architecture
+    title: Frontend Architecture
+    instruction: Define frontend-specific architecture details. After each subsection, note if user wants to refine before continuing.
+    elicit: true
+    sections:
+      - id: component-architecture
+        title: Component Architecture
+        instruction: Define component organization and patterns based on chosen framework.
+        sections:
+          - id: component-organization
+            title: Component Organization
+            type: code
+            language: text
+            template: '{{component_structure}}'
+          - id: component-template
+            title: Component Template
+            type: code
+            language: typescript
+            template: '{{component_template}}'
+      - id: state-management
+        title: State Management Architecture
+        instruction: Detail state management approach based on chosen solution.
+        sections:
+          - id: state-structure
+            title: State Structure
+            type: code
+            language: typescript
+            template: '{{state_structure}}'
+          - id: state-patterns
+            title: State Management Patterns
+            type: bullet-list
+            template: '- {{pattern}}'
+      - id: routing-architecture
+        title: Routing Architecture
+        instruction: Define routing structure based on framework choice.
+        sections:
+          - id: route-organization
+            title: Route Organization
+            type: code
+            language: text
+            template: '{{route_structure}}'
+          - id: protected-routes
+            title: Protected Route Pattern
+            type: code
+            language: typescript
+            template: '{{protected_route_example}}'
+      - id: frontend-services
+        title: Frontend Services Layer
+        instruction: Define how frontend communicates with backend.
+        sections:
+          - id: api-client-setup
+            title: API Client Setup
+            type: code
+            language: typescript
+            template: '{{api_client_setup}}'
+          - id: service-example
+            title: Service Example
+            type: code
+            language: typescript
+            template: '{{service_example}}'
+
+  - id: backend-architecture
+    title: Backend Architecture
+    instruction: Define backend-specific architecture details. Consider serverless vs traditional server approaches.
+    elicit: true
+    sections:
+      - id: service-architecture
+        title: Service Architecture
+        instruction: Based on platform choice, define service organization.
+        sections:
+          - id: serverless-architecture
+            condition: Serverless architecture chosen
+            sections:
+              - id: function-organization
+                title: Function Organization
+                type: code
+                language: text
+                template: '{{function_structure}}'
+              - id: function-template
+                title: Function Template
+                type: code
+                language: typescript
+                template: '{{function_template}}'
+          - id: traditional-server
+            condition: Traditional server architecture chosen
+            sections:
+              - id: controller-organization
+                title: Controller/Route Organization
+                type: code
+                language: text
+                template: '{{controller_structure}}'
+              - id: controller-template
+                title: Controller Template
+                type: code
+                language: typescript
+                template: '{{controller_template}}'
+      - id: database-architecture
+        title: Database Architecture
+        instruction: Define database schema and access patterns.
+        sections:
+          - id: schema-design
+            title: Schema Design
+            type: code
+            language: sql
+            template: '{{database_schema}}'
+          - id: data-access-layer
+            title: Data Access Layer
+            type: code
+            language: typescript
+            template: '{{repository_pattern}}'
+      - id: auth-architecture
+        title: Authentication and Authorization
+        instruction: Define auth implementation details.
+        sections:
+          - id: auth-flow
+            title: Auth Flow
+            type: mermaid
+            mermaid_type: sequence
+            template: '{{auth_flow_diagram}}'
+          - id: auth-middleware
+            title: Middleware/Guards
+            type: code
+            language: typescript
+            template: '{{auth_middleware}}'
+
+  - id: unified-project-structure
+    title: Unified Project Structure
+    instruction: Create a monorepo structure that accommodates both frontend and backend. Adapt based on chosen tools and frameworks.
+    elicit: true
+    type: code
+    language: plaintext
+    examples:
+      - |
+        {{project-name}}/
+        ├── .github/                    # CI/CD workflows
+        │   └── workflows/
+        │       ├── ci.yaml
+        │       └── deploy.yaml
+        ├── apps/                       # Application packages
+        │   ├── web/                    # Frontend application
+        │   │   ├── src/
+        │   │   │   ├── components/     # UI components
+        │   │   │   ├── pages/          # Page components/routes
+        │   │   │   ├── hooks/          # Custom React hooks
+        │   │   │   ├── services/       # API client services
+        │   │   │   ├── stores/         # State management
+        │   │   │   ├── styles/         # Global styles/themes
+        │   │   │   └── utils/          # Frontend utilities
+        │   │   ├── public/             # Static assets
+        │   │   ├── tests/              # Frontend tests
+        │   │   └── package.json
+        │   └── api/                    # Backend application
+        │       ├── src/
+        │       │   ├── routes/         # API routes/controllers
+        │       │   ├── services/       # Business logic
+        │       │   ├── models/         # Data models
+        │       │   ├── middleware/     # Express/API middleware
+        │       │   ├── utils/          # Backend utilities
+        │       │   └── {{serverless_or_server_entry}}
+        │       ├── tests/              # Backend tests
+        │       └── package.json
+        ├── packages/                   # Shared packages
+        │   ├── shared/                 # Shared types/utilities
+        │   │   ├── src/
+        │   │   │   ├── types/          # TypeScript interfaces
+        │   │   │   ├── constants/      # Shared constants
+        │   │   │   └── utils/          # Shared utilities
+        │   │   └── package.json
+        │   ├── ui/                     # Shared UI components
+        │   │   ├── src/
+        │   │   └── package.json
+        │   └── config/                 # Shared configuration
+        │       ├── eslint/
+        │       ├── typescript/
+        │       └── jest/
+        ├── infrastructure/             # IaC definitions
+        │   └── {{iac_structure}}
+        ├── scripts/                    # Build/deploy scripts
+        ├── docs/                       # Documentation
+        │   ├── prd.md
+        │   ├── front-end-spec.md
+        │   └── fullstack-architecture.md
+        ├── .env.example                # Environment template
+        ├── package.json                # Root package.json
+        ├── {{monorepo_config}}         # Monorepo configuration
+        └── README.md
+
+  - id: development-workflow
+    title: Development Workflow
+    instruction: Define the development setup and workflow for the fullstack application.
+    elicit: true
+    sections:
+      - id: local-setup
+        title: Local Development Setup
+        sections:
+          - id: prerequisites
+            title: Prerequisites
+            type: code
+            language: bash
+            template: '{{prerequisites_commands}}'
+          - id: initial-setup
+            title: Initial Setup
+            type: code
+            language: bash
+            template: '{{setup_commands}}'
+          - id: dev-commands
+            title: Development Commands
+            type: code
+            language: bash
+            template: |
+              # Start all services
+              {{start_all_command}}
+
+              # Start frontend only
+              {{start_frontend_command}}
+
+              # Start backend only
+              {{start_backend_command}}
+
+              # Run tests
+              {{test_commands}}
+      - id: environment-config
+        title: Environment Configuration
+        sections:
+          - id: env-vars
+            title: Required Environment Variables
+            type: code
+            language: bash
+            template: |
+              # Frontend (.env.local)
+              {{frontend_env_vars}}
+
+              # Backend (.env)
+              {{backend_env_vars}}
+
+              # Shared
+              {{shared_env_vars}}
+
+  - id: deployment-architecture
+    title: Deployment Architecture
+    instruction: Define deployment strategy based on platform choice.
+    elicit: true
+    sections:
+      - id: deployment-strategy
+        title: Deployment Strategy
+        template: |
+          **Frontend Deployment:**
+          - **Platform:** {{frontend_deploy_platform}}
+          - **Build Command:** {{frontend_build_command}}
+          - **Output Directory:** {{frontend_output_dir}}
+          - **CDN/Edge:** {{cdn_strategy}}
+
+          **Backend Deployment:**
+          - **Platform:** {{backend_deploy_platform}}
+          - **Build Command:** {{backend_build_command}}
+          - **Deployment Method:** {{deployment_method}}
+      - id: cicd-pipeline
+        title: CI/CD Pipeline
+        type: code
+        language: yaml
+        template: '{{cicd_pipeline_config}}'
+      - id: environments
+        title: Environments
+        type: table
+        columns: [Environment, Frontend URL, Backend URL, Purpose]
+        rows:
+          - [
+              'Development',
+              '{{dev_fe_url}}',
+              '{{dev_be_url}}',
+              'Local development',
+            ]
+          - [
+              'Staging',
+              '{{staging_fe_url}}',
+              '{{staging_be_url}}',
+              'Pre-production testing',
+            ]
+          - [
+              'Production',
+              '{{prod_fe_url}}',
+              '{{prod_be_url}}',
+              'Live environment',
+            ]
+
+  - id: security-performance
+    title: Security and Performance
+    instruction: Define security and performance considerations for the fullstack application.
+    elicit: true
+    sections:
+      - id: security-requirements
+        title: Security Requirements
+        template: |
+          **Frontend Security:**
+          - CSP Headers: {{csp_policy}}
+          - XSS Prevention: {{xss_strategy}}
+          - Secure Storage: {{storage_strategy}}
+
+          **Backend Security:**
+          - Input Validation: {{validation_approach}}
+          - Rate Limiting: {{rate_limit_config}}
+          - CORS Policy: {{cors_config}}
+
+          **Authentication Security:**
+          - Token Storage: {{token_strategy}}
+          - Session Management: {{session_approach}}
+          - Password Policy: {{password_requirements}}
+      - id: performance-optimization
+        title: Performance Optimization
+        template: |
+          **Frontend Performance:**
+          - Bundle Size Target: {{bundle_size}}
+          - Loading Strategy: {{loading_approach}}
+          - Caching Strategy: {{fe_cache_strategy}}
+
+          **Backend Performance:**
+          - Response Time Target: {{response_target}}
+          - Database Optimization: {{db_optimization}}
+          - Caching Strategy: {{be_cache_strategy}}
+
+  - id: testing-strategy
+    title: Testing Strategy
+    instruction: Define comprehensive testing approach for fullstack application.
+    elicit: true
+    sections:
+      - id: testing-pyramid
+        title: Testing Pyramid
+        type: code
+        language: text
+        template: |
+          E2E Tests
+          /        \
+          Integration Tests
+          /            \
+          Frontend Unit  Backend Unit
+      - id: test-organization
+        title: Test Organization
+        sections:
+          - id: frontend-tests
+            title: Frontend Tests
+            type: code
+            language: text
+            template: '{{frontend_test_structure}}'
+          - id: backend-tests
+            title: Backend Tests
+            type: code
+            language: text
+            template: '{{backend_test_structure}}'
+          - id: e2e-tests
+            title: E2E Tests
+            type: code
+            language: text
+            template: '{{e2e_test_structure}}'
+      - id: test-examples
+        title: Test Examples
+        sections:
+          - id: frontend-test
+            title: Frontend Component Test
+            type: code
+            language: typescript
+            template: '{{frontend_test_example}}'
+          - id: backend-test
+            title: Backend API Test
+            type: code
+            language: typescript
+            template: '{{backend_test_example}}'
+          - id: e2e-test
+            title: E2E Test
+            type: code
+            language: typescript
+            template: '{{e2e_test_example}}'
+
+  - id: coding-standards
+    title: Coding Standards
+    instruction: Define MINIMAL but CRITICAL standards for AI agents. Focus only on project-specific rules that prevent common mistakes. These will be used by dev agents.
+    elicit: true
+    sections:
+      - id: critical-rules
+        title: Critical Fullstack Rules
+        repeatable: true
+        template: '- **{{rule_name}}:** {{rule_description}}'
+        examples:
+          - '**Type Sharing:** Always define types in packages/shared and import from there'
+          - '**API Calls:** Never make direct HTTP calls - use the service layer'
+          - '**Environment Variables:** Access only through config objects, never process.env directly'
+          - '**Error Handling:** All API routes must use the standard error handler'
+          - '**State Updates:** Never mutate state directly - use proper state management patterns'
+      - id: naming-conventions
+        title: Naming Conventions
+        type: table
+        columns: [Element, Frontend, Backend, Example]
+        rows:
+          - ['Components', 'PascalCase', '-', '`UserProfile.tsx`']
+          - ['Hooks', "camelCase with 'use'", '-', '`useAuth.ts`']
+          - ['API Routes', '-', 'kebab-case', '`/api/user-profile`']
+          - ['Database Tables', '-', 'snake_case', '`user_profiles`']
+
+  - id: error-handling
+    title: Error Handling Strategy
+    instruction: Define unified error handling across frontend and backend.
+    elicit: true
+    sections:
+      - id: error-flow
+        title: Error Flow
+        type: mermaid
+        mermaid_type: sequence
+        template: '{{error_flow_diagram}}'
+      - id: error-format
+        title: Error Response Format
+        type: code
+        language: typescript
+        template: |
+          interface ApiError {
+            error: {
+              code: string;
+              message: string;
+              details?: Record<string, any>;
+              timestamp: string;
+              requestId: string;
+            };
+          }
+      - id: frontend-error-handling
+        title: Frontend Error Handling
+        type: code
+        language: typescript
+        template: '{{frontend_error_handler}}'
+      - id: backend-error-handling
+        title: Backend Error Handling
+        type: code
+        language: typescript
+        template: '{{backend_error_handler}}'
+
+  - id: monitoring
+    title: Monitoring and Observability
+    instruction: Define monitoring strategy for fullstack application.
+    elicit: true
+    sections:
+      - id: monitoring-stack
+        title: Monitoring Stack
+        template: |
+          - **Frontend Monitoring:** {{frontend_monitoring}}
+          - **Backend Monitoring:** {{backend_monitoring}}
+          - **Error Tracking:** {{error_tracking}}
+          - **Performance Monitoring:** {{perf_monitoring}}
+      - id: key-metrics
+        title: Key Metrics
+        template: |
+          **Frontend Metrics:**
+          - Core Web Vitals
+          - JavaScript errors
+          - API response times
+          - User interactions
+
+          **Backend Metrics:**
+          - Request rate
+          - Error rate
+          - Response time
+          - Database query performance
+
+  - id: checklist-results
+    title: Checklist Results Report
+    instruction: Before running the checklist, offer to output the full architecture document. Once user confirms, execute the architect-checklist and populate results here.