@aicgen/aicgen 1.0.0-beta.1 → 1.0.0

package/{CLAUDE.md → claude.md}

@@ -1,4 +1,4 @@
-# @aicgen/aicgen - Development Guidelines
+# my-project - Development Guidelines
 
 **Role:** You are an expert software engineer specialized in typescript.
 **User's Goal:** Build high-quality, maintainable software following strict project guidelines.
@@ -8,13 +8,13 @@
 This project follows structured coding guidelines organized by category:
 
 - **Language**: @.claude/guidelines/language.md
-- **Architecture**: @.claude/guidelines/architecture.md
 - **Testing**: @.claude/guidelines/testing.md
 - **Security**: @.claude/guidelines/security.md
 - **Performance**: @.claude/guidelines/performance.md
 - **API Design**: @.claude/guidelines/api-design.md
 - **Code Style**: @.claude/guidelines/code-style.md
 - **Error Handling**: @.claude/guidelines/error-handling.md
+- **Architecture**: @.claude/guidelines/architecture.md
 - **DevOps**: @.claude/guidelines/devops.md
 - **Best Practices**: @.claude/guidelines/best-practices.md
 - **Design Patterns**: @.claude/guidelines/design-patterns.md

package/config.example.yml

@@ -0,0 +1,129 @@
+# Example AICGEN Configuration File
+#
+# LOCATION: This file should be placed at:
+#   - Windows: C:\Users\YourUsername\.aicgen\config.yml
+#   - Linux/Mac: ~/.aicgen/config.yml
+#
+# INSTALLATION:
+#   Windows:
+#     mkdir C:\Users\%USERNAME%\.aicgen
+#     copy config.example.yml C:\Users\%USERNAME%\.aicgen\config.yml
+#
+#   Linux/Mac:
+#     mkdir -p ~/.aicgen
+#     cp config.example.yml ~/.aicgen/config.yml
+#
+# Configuration priority: Environment Variables > User Config > Defaults
+
+# GitHub repository configuration
+github:
+  owner: aicgen
+  repo: aicgen-data
+
+# AI Provider Configuration
+# Customize models, timeouts, and behavior for different AI providers
+ai:
+  # Google Gemini Configuration
+  gemini:
+    # Model: Use latest Gemini 2.0 or 2.5 models
+    # See: https://ai.google.dev/gemini-api/docs/models
+    model: gemini-2.0-flash-exp
+    # Available models:
+    #   - gemini-2.5-flash (latest, recommended)
+    #   - gemini-2.5-pro (most capable, slower)
+    #   - gemini-2.0-flash-exp (experimental, fast)
+
+    # Request timeout in milliseconds
+    timeout: 30000
+
+    # Maximum retry attempts for failed requests
+    maxRetries: 3
+
+    # Maximum output tokens
+    maxTokens: 8192
+
+  # Anthropic Claude Configuration
+  claude:
+    # Model: Use Claude 3.5 Sonnet or Opus
+    # See: https://docs.anthropic.com/en/docs/about-claude/models
+    model: claude-3-5-sonnet-20241022
+    # Available models:
+    #   - claude-3-5-sonnet-20241022 (best balance, recommended)
+    #   - claude-3-opus-20240229 (most capable, expensive)
+    #   - claude-3-haiku-20240307 (fastest, cheapest)
+
+    # Request timeout in milliseconds
+    timeout: 30000
+
+    # Maximum retry attempts
+    maxRetries: 3
+
+    # Maximum output tokens
+    maxTokens: 8096
+
+    # Temperature (0-1): Lower = more focused, Higher = more creative
+    temperature: 0.7
+
+  # OpenAI Configuration
+  openai:
+    # Model: Use GPT-4o or GPT-4 Turbo
+    # See: https://platform.openai.com/docs/models
+    model: gpt-4o
+    # Available models:
+    #   - gpt-4o (latest, recommended)
+    #   - gpt-4-turbo (high capability)
+    #   - gpt-4 (most capable, expensive)
+    #   - gpt-3.5-turbo (fast, cheaper)
+
+    # Request timeout in milliseconds
+    timeout: 30000
+
+    # Maximum retry attempts
+    maxRetries: 3
+
+    # Maximum output tokens
+    maxTokens: 4096
+
+    # Temperature (0-2): Lower = more focused, Higher = more creative
+    temperature: 0.7
+
+  # Sub-Agent Configuration
+  # These are specialized agents for code review tasks
+  subAgents:
+    # Guideline Checker - Verifies code follows project guidelines
+    guidelineChecker:
+      model: claude-opus-4-5
+      # Use lower temperature for strict guideline checking
+      temperature: 0.3
+
+    # Architecture Reviewer - Reviews architectural decisions
+    architectureReviewer:
+      model: claude-sonnet-4-5
+      # Balanced temperature for architecture review
+      temperature: 0.5
+
+    # Security Auditor - Identifies security vulnerabilities
+    securityAuditor:
+      model: claude-opus-4-5
+      # Lower temperature for thorough security analysis
+      temperature: 0.3
+
+# Alternative: Use environment variables instead
+# Export these in your shell profile (.bashrc, .zshrc, etc.):
+#
+# # Gemini
+# export AICGEN_GEMINI_MODEL=gemini-2.5-pro
+# export AICGEN_GEMINI_TIMEOUT=60000
+# export AICGEN_GEMINI_MAX_RETRIES=5
+#
+# # Claude
+# export AICGEN_CLAUDE_MODEL=claude-3-opus-20240229
+# export AICGEN_CLAUDE_TEMPERATURE=0.5
+#
+# # OpenAI
+# export AICGEN_OPENAI_MODEL=gpt-4-turbo
+# export AICGEN_OPENAI_TEMPERATURE=0.8
+#
+# # Sub-Agents
+# export AICGEN_SUBAGENT_GUIDELINE_MODEL=claude-opus-4-5
+# export AICGEN_SUBAGENT_GUIDELINE_TEMP=0.2

package/config.yml

@@ -0,0 +1,38 @@
+github:
+  owner: aicgen
+  repo: aicgen-data
+
+# AI Provider Configuration
+ai:
+  gemini:
+    model: gemini-2.0-flash-exp
+    timeout: 30000
+    maxRetries: 3
+    maxTokens: 8192
+
+  claude:
+    model: claude-3-5-sonnet-20241022
+    timeout: 30000
+    maxRetries: 3
+    maxTokens: 8096
+    temperature: 0.7
+
+  openai:
+    model: gpt-4o
+    timeout: 30000
+    maxRetries: 3
+    maxTokens: 4096
+    temperature: 0.7
+
+  subAgents:
+    guidelineChecker:
+      model: claude-opus-4-5
+      temperature: 0.3
+
+    architectureReviewer:
+      model: claude-sonnet-4-5
+      temperature: 0.5
+
+    securityAuditor:
+      model: claude-opus-4-5
+      temperature: 0.3

package/data/architecture/microservices/api-gateway.md

@@ -1,56 +1,56 @@
-# API Gateway
-
-## Overview
-
-An API Gateway acts as a single entry point for a group of microservices. It handles cross-cutting concerns and routes requests to the appropriate backend services.
-
-## Core Responsibilities
-
-1.  **Routing**: Forwarding requests to the correct service (e.g., `/api/users` -> User Service).
-2.  **Authentication & Authorization**: Verifying identity and permissions at the edge.
-3.  **Rate Limiting**: Protecting services from abuse.
-4.  **Protocol Translation**: Converting public HTTP/REST to internal gRPC or AMQP.
-5.  **Response Aggregation**: Combining data from multiple services into a single response.
-
-## Patterns
-
-### Backend for Frontend (BFF)
-
-Create separate gateways for different client types (Mobile, Web, 3rd Party) to optimize the API for each consumer.
-
-```mermaid
-graph TD
-    Web[Web App] --> WebBFF[Web BFF]
-    Mobile[Mobile App] --> MobileBFF[Mobile BFF]
-    
-    WebBFF --> SvcA[Service A]
-    WebBFF --> SvcB[Service B]
-    
-    MobileBFF --> SvcA
-    MobileBFF --> SvcC[Service C]
-```
-
-## Implementation
-
-### Cross-Cutting Concerns
-
-Handle these at the gateway to keep microservices focused on business logic:
-
-- **SSL Termination**: Decrypt HTTPS at the gateway.
-- **CORS**: Handle Cross-Origin Resource Sharing headers.
-- **Request Validation**: Basic schema validation before hitting services.
-- **Caching**: Cache common responses.
-
-### When to Use
-
-| Use API Gateway When... | Avoid API Gateway When... |
-|-------------------------|---------------------------|
-| You have multiple microservices | You have a monolithic application |
-| You need centralized auth/security | You need ultra-low latency (extra hop) |
-| You have diverse clients (Web, Mobile) | Your architecture is very simple |
-
-## Best Practices
-
-- **Keep it Logic-Free**: Don't put business logic in the gateway. It should be a router, not a processor.
-- **High Availability**: The gateway is a single point of failure; deploy it in a cluster.
-- **Observability**: Ensure the gateway generates trace IDs and logs all traffic.
+# API Gateway
+
+## Overview
+
+An API Gateway acts as a single entry point for a group of microservices. It handles cross-cutting concerns and routes requests to the appropriate backend services.
+
+## Core Responsibilities
+
+1.  **Routing**: Forwarding requests to the correct service (e.g., `/api/users` -> User Service).
+2.  **Authentication & Authorization**: Verifying identity and permissions at the edge.
+3.  **Rate Limiting**: Protecting services from abuse.
+4.  **Protocol Translation**: Converting public HTTP/REST to internal gRPC or AMQP.
+5.  **Response Aggregation**: Combining data from multiple services into a single response.
+
+## Patterns
+
+### Backend for Frontend (BFF)
+
+Create separate gateways for different client types (Mobile, Web, 3rd Party) to optimize the API for each consumer.
+
+```mermaid
+graph TD
+    Web[Web App] --> WebBFF[Web BFF]
+    Mobile[Mobile App] --> MobileBFF[Mobile BFF]
+    
+    WebBFF --> SvcA[Service A]
+    WebBFF --> SvcB[Service B]
+    
+    MobileBFF --> SvcA
+    MobileBFF --> SvcC[Service C]
+```
+
+## Implementation
+
+### Cross-Cutting Concerns
+
+Handle these at the gateway to keep microservices focused on business logic:
+
+- **SSL Termination**: Decrypt HTTPS at the gateway.
+- **CORS**: Handle Cross-Origin Resource Sharing headers.
+- **Request Validation**: Basic schema validation before hitting services.
+- **Caching**: Cache common responses.
+
+### When to Use
+
+| Use API Gateway When... | Avoid API Gateway When... |
+|-------------------------|---------------------------|
+| You have multiple microservices | You have a monolithic application |
+| You need centralized auth/security | You need ultra-low latency (extra hop) |
+| You have diverse clients (Web, Mobile) | Your architecture is very simple |
+
+## Best Practices
+
+- **Keep it Logic-Free**: Don't put business logic in the gateway. It should be a router, not a processor.
+- **High Availability**: The gateway is a single point of failure; deploy it in a cluster.
+- **Observability**: Ensure the gateway generates trace IDs and logs all traffic.

package/data/devops/observability.md

@@ -1,73 +1,73 @@
-# Observability
-
-## Overview
-
-Observability is the ability to understand the internal state of a system by examining its outputs. In modern distributed systems, it goes beyond simple monitoring to include logging, metrics, and tracing.
-
-## Three Pillars
-
-### 1. Structured Logging
-
-Logs should be machine-readable (JSON) and contain context.
-
-```json
-// ✅ Good: Structured JSON logging
-{
-  "level": "info",
-  "message": "Order processed",
-  "orderId": "ord_123",
-  "userId": "user_456",
-  "amount": 99.99,
-  "durationMs": 145,
-  "status": "success"
-}
-```
-```text
-// ❌ Bad: Unstructured text
-"Order processed: ord_123 for user_456"
-```
-
-### 2. Metrics
-
-Aggregatable data points for identifying trends and health.
-
-- **Counters**: Total requests, error counts (`http_requests_total`)
-- **Gauges**: Queue depth, memory usage (`memory_usage_bytes`)
-- **Histograms**: Request latency distribution (`http_request_duration_seconds`)
-
-### 3. Distributed Tracing
-
-Tracking requests as they propagate through services.
-
-- **Trace ID**: Unique ID for the entire request chain
-- **Span ID**: Unique ID for a specific operation
-- **Context Propagation**: Passing IDs between services (e.g., W3C Trace Context)
-
-## Implementation Strategy
-
-### OpenTelemetry (OTel)
-
-Use OpenTelemetry as the vendor-neutral standard for collecting telemetry data.
-
-```text
-# Initialize OpenTelemetry SDK
-SDK.Configure({
-  TraceExporter: Console/OTLP,
-  Instrumentations: [Http, Database, Grpc]
-})
-SDK.Start()
-```
-
-### Health Checks
-
-Expose standard health endpoints:
-
-- `/health/live`: Is the process running? (Liveness)
-- `/health/ready`: Can it accept traffic? (Readiness)
-- `/health/startup`: Has it finished initializing? (Startup)
-
-## Alerting Best Practices
-
-- **Alert on Symptoms, not Causes**: "High Error Rate" (Symptom) vs "CPU High" (Cause).
-- **Golden Signals**: Latency, Traffic, Errors, Saturation.
-- **Actionable**: Every alert should require a specific human action.
+# Observability
+
+## Overview
+
+Observability is the ability to understand the internal state of a system by examining its outputs. In modern distributed systems, it goes beyond simple monitoring to include logging, metrics, and tracing.
+
+## Three Pillars
+
+### 1. Structured Logging
+
+Logs should be machine-readable (JSON) and contain context.
+
+```json
+// ✅ Good: Structured JSON logging
+{
+  "level": "info",
+  "message": "Order processed",
+  "orderId": "ord_123",
+  "userId": "user_456",
+  "amount": 99.99,
+  "durationMs": 145,
+  "status": "success"
+}
+```
+```text
+// ❌ Bad: Unstructured text
+"Order processed: ord_123 for user_456"
+```
+
+### 2. Metrics
+
+Aggregatable data points for identifying trends and health.
+
+- **Counters**: Total requests, error counts (`http_requests_total`)
+- **Gauges**: Queue depth, memory usage (`memory_usage_bytes`)
+- **Histograms**: Request latency distribution (`http_request_duration_seconds`)
+
+### 3. Distributed Tracing
+
+Tracking requests as they propagate through services.
+
+- **Trace ID**: Unique ID for the entire request chain
+- **Span ID**: Unique ID for a specific operation
+- **Context Propagation**: Passing IDs between services (e.g., W3C Trace Context)
+
+## Implementation Strategy
+
+### OpenTelemetry (OTel)
+
+Use OpenTelemetry as the vendor-neutral standard for collecting telemetry data.
+
+```text
+# Initialize OpenTelemetry SDK
+SDK.Configure({
+  TraceExporter: Console/OTLP,
+  Instrumentations: [Http, Database, Grpc]
+})
+SDK.Start()
+```
+
+### Health Checks
+
+Expose standard health endpoints:
+
+- `/health/live`: Is the process running? (Liveness)
+- `/health/ready`: Can it accept traffic? (Readiness)
+- `/health/startup`: Has it finished initializing? (Startup)
+
+## Alerting Best Practices
+
+- **Alert on Symptoms, not Causes**: "High Error Rate" (Symptom) vs "CPU High" (Cause).
+- **Golden Signals**: Latency, Traffic, Errors, Saturation.
+- **Actionable**: Every alert should require a specific human action.

package/data/guideline-mappings.yml

@@ -332,6 +332,134 @@ javascript-testing:
     - testing
     - jest
   category: Language
+dart-basics:
+  path: language/dart/basics.md
+  languages:
+    - dart
+  levels:
+    - basic
+    - standard
+    - expert
+    - full
+  tags:
+    - dart
+    - fundamentals
+    - null-safety
+  category: Language
+dart-async:
+  path: language/dart/async.md
+  languages:
+    - dart
+  levels:
+    - basic
+    - standard
+    - expert
+    - full
+  tags:
+    - dart
+    - async
+    - futures
+    - streams
+  category: Language
+dart-error-handling:
+  path: language/dart/error-handling.md
+  languages:
+    - dart
+  levels:
+    - standard
+    - expert
+    - full
+  tags:
+    - dart
+    - errors
+    - exceptions
+  category: Language
+dart-testing:
+  path: language/dart/testing.md
+  languages:
+    - dart
+  levels:
+    - standard
+    - expert
+    - full
+  tags:
+    - dart
+    - testing
+    - flutter
+  category: Language
+swift-basics:
+  path: language/swift/basics.md
+  languages:
+    - swift
+  levels:
+    - basic
+    - standard
+    - expert
+    - full
+  tags:
+    - swift
+    - fundamentals
+    - optionals
+    - value-types
+  category: Language
+swift-concurrency:
+  path: language/swift/concurrency.md
+  languages:
+    - swift
+  levels:
+    - standard
+    - expert
+    - full
+  tags:
+    - swift
+    - async
+    - actors
+    - structured-concurrency
+    - task
+  category: Language
+swift-swiftui-mvvm:
+  path: language/swift/swiftui-mvvm.md
+  languages:
+    - swift
+  levels:
+    - standard
+    - expert
+    - full
+  tags:
+    - swift
+    - swiftui
+    - mvvm
+    - state-management
+    - combine
+  category: Language
+swift-testing:
+  path: language/swift/testing.md
+  languages:
+    - swift
+  levels:
+    - standard
+    - expert
+    - full
+  tags:
+    - swift
+    - testing
+    - xctest
+    - swift-testing
+  category: Language
+swift-error-handling:
+  path: language/swift/error-handling.md
+  languages:
+    - swift
+  levels:
+    - standard
+    - expert
+    - full
+  tags:
+    - swift
+    - errors
+    - throws
+    - result
+  category: Language
 microservices-boundaries:
   path: architecture/microservices/boundaries.md
   architectures: