@defai.digital/automatosx 12.8.7 → 13.1.3

package/examples/abilities/accessibility.md

@@ -1,115 +0,0 @@
-# Accessibility (A11y)
-
-Build inclusive web applications following WCAG guidelines.
-
-## Core Principles (WCAG)
-
-1. **Perceivable** - Users must be able to perceive the information
-2. **Operable** - Users must be able to operate the interface
-3. **Understandable** - Users must understand the information and interface
-4. **Robust** - Content must work with current and future technologies
-
-## Essential Practices
-
-### 1. Semantic HTML
-- Use proper HTML elements (button, nav, header, main, footer, article)
-- Avoid div/span for interactive elements
-- Use headings (h1-h6) in logical order
-- Use lists (ul, ol) for groups of items
-- Use form elements with proper labels
-
-### 2. ARIA Attributes
-- Use aria-label for icons and buttons without text
-- Use aria-describedby for additional context
-- Use aria-live for dynamic content updates
-- Use aria-expanded for collapsible sections
-- Use aria-hidden="true" for decorative elements
-- Don't over-use ARIA (semantic HTML is better)
-
-### 3. Keyboard Navigation
-- All interactive elements must be keyboard accessible (Tab, Enter, Space)
-- Provide visible focus indicators (:focus-visible)
-- Implement skip links for main content
-- Use tabindex="0" to add elements to tab order
-- Use tabindex="-1" to remove from tab order (programmatically focusable)
-- Never use positive tabindex values
-
-### 4. Color and Contrast
-- Minimum contrast ratio 4.5:1 for normal text
-- Minimum contrast ratio 3:1 for large text (18pt+)
-- Don't rely on color alone to convey information
-- Provide text alternatives for color-coded information
-- Test with color blindness simulators
-
-### 5. Forms
-- Use <label> for every form input
-- Provide clear error messages
-- Use aria-invalid and aria-describedby for errors
-- Group related inputs with fieldset/legend
-- Mark required fields clearly (aria-required="true")
-- Provide autocomplete attributes where appropriate
-
-### 6. Images and Media
-- Provide alt text for all images
-- Use empty alt="" for decorative images
-- Provide captions for videos
-- Provide transcripts for audio content
-- Don't use images of text (use real text)
-
-### 7. Focus Management
-- Manage focus for modals (trap focus, restore on close)
-- Focus first interactive element when opening dialogs
-- Provide focus indicators for all interactive elements
-- Use :focus-visible to show focus only for keyboard users
-- Announce route changes for screen readers
-
-### 8. Screen Reader Support
-- Use live regions (aria-live) for dynamic updates
-- Provide meaningful page titles
-- Use aria-label when visual label isn't enough
-- Test with screen readers (NVDA, JAWS, VoiceOver)
-- Announce loading states and errors
-
-## Common Patterns
-
-### Modal Dialogs
-- Trap focus within modal
-- Close on Escape key
-- Return focus to trigger element on close
-- Use role="dialog" and aria-modal="true"
-- Provide accessible close button
-
-### Dropdown Menus
-- Use aria-expanded to indicate state
-- Navigate with arrow keys
-- Close on Escape
-- Close on click outside
-- Focus first item when opened
-
-### Form Validation
-- Associate errors with fields (aria-describedby)
-- Mark invalid fields (aria-invalid="true")
-- Announce errors to screen readers
-- Provide clear, specific error messages
-- Don't rely on color alone
-
-## Testing Tools
-
-- axe DevTools (Chrome extension)
-- Lighthouse accessibility audit
-- WAVE (Web Accessibility Evaluation Tool)
-- Keyboard navigation testing (Tab, Shift+Tab, Enter, Space, Esc, Arrow keys)
-- Screen reader testing (VoiceOver on Mac, NVDA/JAWS on Windows)
-
-## Quick Checklist
-
-- [ ] All interactive elements keyboard accessible
-- [ ] Proper semantic HTML used
-- [ ] All images have appropriate alt text
-- [ ] Color contrast meets WCAG AA (4.5:1)
-- [ ] Forms have proper labels and error handling
-- [ ] Focus management for modals/dialogs
-- [ ] ARIA attributes used correctly (when needed)
-- [ ] Tested with keyboard navigation
-- [ ] Tested with screen reader
-- [ ] No accessibility errors in axe DevTools

package/examples/abilities/api-design.md

@@ -1,168 +0,0 @@
-# API Design
-
-## Overview
-Design RESTful, GraphQL, and other API architectures following industry best practices, focusing on developer experience, performance, and maintainability.
-
-## Core Principles
-
-### 1. RESTful Design
-- Resource-oriented URL structure
-- Proper HTTP method usage (GET, POST, PUT, PATCH, DELETE)
-- Stateless communication
-- HATEOAS when appropriate
-
-### 2. GraphQL Design
-- Schema-first approach
-- Efficient resolver implementation
-- Query complexity analysis
-- Pagination and batching strategies
-
-### 3. API Versioning
-- URL versioning (`/v1/`, `/v2/`)
-- Header versioning (`Accept: application/vnd.api+json; version=1`)
-- Deprecation policies and timelines
-
-### 4. Error Handling
-- Consistent error response structure
-- Meaningful HTTP status codes
-- Detailed error messages for debugging
-- Error code cataloging
-
-### 5. Authentication & Authorization
-- Token-based authentication (JWT, OAuth 2.0)
-- API key management
-- Rate limiting per user/client
-- Scope-based permissions
-
-## Design Patterns
-
-### Request/Response Patterns
-```
-GET /api/v1/resources/{id}
-→ 200 OK with resource
-→ 404 Not Found
-→ 401 Unauthorized
-
-POST /api/v1/resources
-→ 201 Created with Location header
-→ 400 Bad Request with validation errors
-→ 409 Conflict for duplicates
-```
-
-### Pagination
-- Cursor-based for large datasets
-- Offset/limit for smaller datasets
-- Include metadata (total count, has_next, cursors)
-
-### Filtering & Sorting
-- Query parameters: `?filter[status]=active&sort=-created_at`
-- Standardized field names
-- Documentation of supported operators
-
-## Documentation Standards
-
-### OpenAPI/Swagger
-- Complete endpoint descriptions
-- Request/response schemas
-- Example payloads
-- Authentication requirements
-
-### API Documentation Must Include
-- Quick start guide
-- Authentication flow
-- Rate limits
-- Error codes reference
-- Changelog with version history
-
-## Performance Considerations
-
-### 1. Response Optimization
-- Minimal payload size
-- Field selection (`?fields=id,name`)
-- Compression (gzip, brotli)
-- Caching headers (ETag, Cache-Control)
-
-### 2. Request Optimization
-- Batch endpoints for multiple operations
-- Webhook support for async operations
-- WebSocket for real-time updates
-
-### 3. Monitoring
-- Response time percentiles (p50, p95, p99)
-- Error rates by endpoint
-- Rate limit hit metrics
-- Payload size distribution
-
-## Security Guidelines
-
-### Input Validation
-- Schema validation for all requests
-- Sanitize user input
-- Size limits on payloads
-- Content-type verification
-
-### Rate Limiting
-- Per-endpoint limits
-- User/API key throttling
-- Gradual backoff responses
-- 429 Too Many Requests with Retry-After
-
-### CORS Configuration
-- Explicit origin whitelisting
-- Credential handling
-- Preflight request caching
-
-## Contract Testing
-
-### Schema Validation
-- Request validation against OpenAPI spec
-- Response validation
-- Breaking change detection
-
-### Backward Compatibility
-- Additive changes only (new fields)
-- Deprecation warnings before removal
-- Versioning for breaking changes
-
-## Tools & Technologies
-
-### Design
-- OpenAPI 3.x specification
-- Postman/Insomnia for testing
-- GraphQL Playground
-- API Blueprint
-
-### Testing
-- Contract testing (Pact)
-- Load testing (k6, JMeter)
-- Security scanning (OWASP ZAP)
-
-### Documentation
-- Swagger UI
-- ReDoc
-- GraphQL Voyager
-- Stoplight Studio
-
-## Checklist for New API
-
-- [ ] OpenAPI spec created and validated
-- [ ] Authentication/authorization implemented
-- [ ] Rate limiting configured
-- [ ] Error responses standardized
-- [ ] CORS properly configured
-- [ ] Input validation on all endpoints
-- [ ] Response caching strategy defined
-- [ ] API documentation published
-- [ ] Monitoring/alerting set up
-- [ ] Contract tests written
-- [ ] Load testing performed
-- [ ] Security audit completed
-
-## Application Hints
-
-When designing APIs:
-- Prioritize backward compatibility; breaking changes require explicit versioning strategy
-- Validate request/response schemas before implementation (use OpenAPI spec as contract)
-- Consider rate limiting and pagination for all list endpoints from the start
-- Check idempotency requirements for payment, financial, or state-changing operations
-- Document error codes and response formats before writing endpoint logic

package/examples/abilities/best-practices.md

@@ -1,102 +0,0 @@
-# Best Practices Ability
-
-Apply industry-standard best practices across development.
-
-## Code Quality
-
-1. **Readability**
-   - Clear, descriptive names
-   - Consistent formatting
-   - Meaningful comments
-   - Self-documenting code
-
-2. **Simplicity**
-   - KISS (Keep It Simple, Stupid)
-   - Avoid over-engineering
-   - Solve today's problem
-   - Refactor when needed
-
-3. **Maintainability**
-   - DRY (Don't Repeat Yourself)
-   - SOLID principles
-   - Low coupling, high cohesion
-   - Modular design
-
-4. **Reliability**
-   - Error handling
-   - Input validation
-   - Defensive programming
-   - Comprehensive testing
-
-## Development Practices
-
-### Version Control (Git)
-
-- Commit often, push daily
-- Write meaningful commit messages
-- Use feature branches
-- Review before merging
-- Keep main/master deployable
-
-### Code Review
-
-- Review all changes
-- Be constructive and respectful
-- Check for bugs, style, design
-- Suggest alternatives
-- Approve only when ready
-
-### Testing
-
-- Write tests first (TDD)
-- Test behavior, not implementation
-- Aim for 80%+ coverage
-- Fast test execution
-- Fix failing tests immediately
-
-### Security
-
-- Never commit secrets
-- Validate all inputs
-- Use parameterized queries
-- Keep dependencies updated
-- Follow OWASP guidelines
-
-## Architecture Principles
-
-1. **Separation of Concerns**
-   - Each module has one responsibility
-   - Clear boundaries
-   - Minimal dependencies
-
-2. **Dependency Injection**
-   - Don't create dependencies internally
-   - Inject through constructor/parameters
-   - Easier testing and flexibility
-
-3. **Interface-Based Design**
-   - Program to interfaces, not implementations
-   - Enables polymorphism
-   - Facilitates testing (mocking)
-
-4. **Configuration Over Hardcoding**
-   - Use config files/environment variables
-   - Don't hardcode URLs, paths, credentials
-   - Environment-specific configs
-
-## Performance
-
-- Profile before optimizing
-- Optimize bottlenecks only
-- Use caching strategically
-- Minimize database queries
-- Lazy load when possible
-- Consider asynchronous operations
-
-## Documentation
-
-- README for every project
-- API documentation (JSDoc, OpenAPI)
-- Code comments for "why"
-- Architecture diagrams
-- Changelog/release notes

package/examples/abilities/caching-strategy.md

@@ -1,165 +0,0 @@
-# Caching Strategy
-
-## Overview
-Design and implement multi-layer caching strategies to optimize application performance, reduce database load, and improve user experience.
-
-## Caching Layers
-
-### 1. Client-Side Caching
-- Browser cache (Cache-Control, ETag)
-- Service Worker caching
-- Local Storage / IndexedDB
-- CDN edge caching
-
-### 2. Application-Level Caching
-- In-memory cache (Redis, Memcached)
-- Application process cache
-- Query result caching
-- Computed value caching
-
-### 3. Database Caching
-- Query result cache
-- Prepared statement cache
-- Connection pool
-- Buffer pool (InnoDB)
-
-## Cache Patterns
-
-### Cache-Aside (Lazy Loading)
-1. Check cache
-2. If miss → Query database
-3. Store in cache
-4. Return data
-
-**Use when**: Read-heavy, acceptable stale data
-
-### Write-Through
-1. Write to cache
-2. Write to database (synchronous)
-3. Return success
-
-**Use when**: Data consistency critical
-
-### Write-Behind (Write-Back)
-1. Write to cache
-2. Queue database write (async)
-3. Return success
-
-**Use when**: High write throughput needed
-
-### Read-Through
-Cache handles database reads automatically
-
-**Use when**: Simplify application logic
-
-### Refresh-Ahead
-Proactively refresh before expiration
-
-**Use when**: Predictable access patterns
-
-## Cache Invalidation
-
-### Time-Based (TTL)
-**Pros**: Simple, predictable
-**Cons**: May serve stale data
-
-### Event-Based
-**Pros**: Always fresh
-**Cons**: Complex invalidation logic
-
-### Tag-Based
-**Pros**: Flexible, bulk invalidation
-**Cons**: Overhead in management
-
-## Cache Key Design
-
-### Naming Conventions
-`<namespace>:<entity>:<id>:<attribute>`
-
-Examples:
-- `user:123:profile`
-- `product:456:inventory`
-- `session:abc123:cart`
-
-### Hierarchical Keys
-`app:v1:user:123:settings`
-
-### Composite Keys
-- `search:query:<hash>:page:1`
-- `filter:category:electronics:brand:apple`
-
-## Performance Optimization
-
-### Connection Pooling
-- Min/max pool size tuning
-- Connection timeout configuration
-- Health checks for stale connections
-
-### Compression
-- Compress large values (>1KB)
-- Trade CPU for memory savings
-- Use MessagePack or Snappy
-
-### Batch Operations
-- Pipeline multiple commands
-- Reduce network round trips
-
-### Read Replicas
-- Separate read/write connections
-- Route heavy reads to replicas
-- Monitor replication lag
-
-## Monitoring & Metrics
-
-### Key Metrics
-- Hit rate (hits / (hits + misses))
-- Miss rate
-- Eviction rate
-- Memory usage
-- Latency (p50, p95, p99)
-
-### Alerts
-- Hit rate < 80%
-- Memory usage > 85%
-- Eviction rate spike
-- Replication lag > 1s
-
-## Eviction Policies
-- **noeviction**: Return error when full
-- **allkeys-lru**: Evict least recently used
-- **volatile-lru**: Evict LRU with TTL set
-- **allkeys-random**: Random eviction
-- **volatile-ttl**: Evict soonest expiring
-
-## Common Pitfalls
-
-### Cache Stampede
-**Problem**: Many requests hit DB on cache miss
-**Solution**: Probabilistic early expiration, lock-based refresh, always return stale data while refreshing
-
-### Cache Penetration
-**Problem**: Queries for non-existent data bypass cache
-**Solution**: Cache null results with short TTL
-
-### Hot Key Problem
-**Problem**: Single key gets massive traffic
-**Solution**: Key sharding, local cache, load balancing
-
-### Cache Avalanche
-**Problem**: Many keys expire simultaneously
-**Solution**: Add jitter to TTL (TTL ± random)
-
-## Design Checklist
-
-- [ ] Cache layers identified (client, app, DB)
-- [ ] Cache pattern selected (cache-aside, write-through, etc.)
-- [ ] Invalidation strategy defined
-- [ ] Key naming convention established
-- [ ] TTL values justified
-- [ ] Eviction policy configured
-- [ ] Connection pooling set up
-- [ ] Monitoring/alerting configured
-- [ ] Security measures implemented
-- [ ] Cache stampede prevention
-- [ ] Performance testing completed
-- [ ] Documentation updated

package/examples/abilities/ci-cd.md

@@ -1,61 +0,0 @@
-# CI/CD Pipelines
-
-Automate build, test, and deployment processes. Implement continuous integration and continuous delivery for reliable, fast releases.
-
-## Do's ✅
-
-```yaml
-# ✅ Good: Comprehensive pipeline (GitHub Actions)
-name: CI/CD
-on:
-  push:
-    branches: [main]
-  pull_request:
-
-jobs:
-  test:
-    runs-on: ubuntu-latest
-    steps:
-      - uses: actions/checkout@v3
-      - uses: actions/setup-node@v3
-        with:
-          node-version: '18'
-          cache: 'npm'
-      - run: npm ci
-      - run: npm run lint
-      - run: npm test
-      - run: npm run build
-
-  deploy:
-    needs: test
-    if: github.ref == 'refs/heads/main'
-    runs-on: ubuntu-latest
-    steps:
-      - name: Deploy
-        run: ./deploy.sh production
-        env:
-          AWS_KEY: ${{ secrets.AWS_KEY }}
-```
-
-## Don'ts ❌
-
-```yaml
-# ❌ Bad: Deploy without testing
-on: push
-jobs:
-  deploy:
-    steps:
-      - run: ./deploy.sh  # YOLO!
-
-# ❌ Bad: Secrets in code
-env:
-  API_KEY: "sk_live_abc123"  # Never!
-```
-
-## Best Practices
-- Run tests on every commit
-- Use secrets management
-- Implement rollback strategies
-- Use artifact caching
-- Implement deployment gates for production
-- Monitor deployment health