siesa-agents 2.1.35 → 2.1.37

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

@@ -1,824 +0,0 @@
-# <!-- 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.