@defai.digital/automatosx 5.0.13 → 5.1.2

package/examples/abilities/performance.md

@@ -0,0 +1,80 @@
+# Frontend Performance Optimization
+
+Optimize React applications for speed and efficiency.
+
+## Core Web Vitals
+
+Target metrics:
+- **LCP** (Largest Contentful Paint): < 2.5s
+- **FID** (First Input Delay): < 100ms
+- **CLS** (Cumulative Layout Shift): < 0.1
+- **FCP** (First Contentful Paint): < 1.8s
+- **TTI** (Time to Interactive): < 3.8s
+
+## Optimization Strategies
+
+### 1. Code Splitting
+- Use React.lazy() for route-based splitting
+- Split heavy components (charts, editors, modals)
+- Use Suspense with meaningful fallbacks
+- Analyze bundle with webpack-bundle-analyzer
+
+### 2. Memoization
+- useMemo() for expensive calculations
+- useCallback() for callbacks passed to child components
+- React.memo() for components that re-render with same props
+- Don't over-memoize (profile first)
+
+### 3. Virtualization
+- Use react-window or react-virtualized for long lists (>100 items)
+- Implement infinite scroll for large datasets
+- Lazy load images in viewport
+
+### 4. Asset Optimization
+- Compress images (WebP format, use srcset)
+- Lazy load images (loading="lazy")
+- Use CDN for static assets
+- Enable gzip/brotli compression
+- Optimize fonts (font-display: swap, preload critical fonts)
+
+### 5. Render Optimization
+- Avoid inline function/object creation in render
+- Use key prop correctly for lists
+- Lift state up sparingly (keep state local when possible)
+- Debounce/throttle expensive operations (search, scroll handlers)
+- Use production build for deployment
+
+### 6. Network Optimization
+- Implement caching strategies (Cache-Control headers)
+- Use service workers for offline support
+- Prefetch critical resources
+- Minimize API calls (batch requests)
+- Use GraphQL field selection to fetch only needed data
+
+### 7. Bundle Optimization
+- Tree-shake unused code
+- Use dynamic imports for conditional features
+- Remove unused dependencies
+- Use lighter alternatives (date-fns instead of moment)
+- Configure webpack to split vendor bundles
+
+## Performance Profiling
+
+Tools and techniques:
+- Chrome DevTools Performance tab
+- React DevTools Profiler
+- Lighthouse CI
+- Web Vitals library
+- Bundle analyzer
+
+## Quick Checklist
+
+Before deploying:
+- [ ] Bundle size analyzed and optimized
+- [ ] Images compressed and lazy loaded
+- [ ] Long lists virtualized
+- [ ] Expensive computations memoized
+- [ ] Route-based code splitting implemented
+- [ ] Core Web Vitals measured and acceptable
+- [ ] Production build tested
+- [ ] Caching strategy configured

package/examples/abilities/problem-solving.md

@@ -0,0 +1,50 @@
+# Problem-Solving Ability
+
+Systematically approach and solve complex problems.
+
+## Problem-Solving Framework
+
+1. **Define** the problem
+   - State the problem clearly
+   - Identify root cause (5 Whys)
+   - Separate symptoms from causes
+   - Define constraints
+
+2. **Analyze** the situation
+   - Gather relevant information
+   - Identify patterns
+   - Consider multiple perspectives
+   - List assumptions
+
+3. **Generate** solutions
+   - Brainstorm alternatives
+   - Don't judge initially (divergent thinking)
+   - Consider unconventional approaches
+   - Document all ideas
+
+4. **Evaluate** options
+   - List pros and cons
+   - Consider trade-offs
+   - Assess feasibility
+   - Estimate impact
+
+5. **Implement** solution
+   - Create action plan
+   - Start with small experiments
+   - Monitor progress
+   - Adjust as needed
+
+6. **Review** and learn
+   - Did it solve the problem?
+   - What worked well?
+   - What could be improved?
+   - Document lessons learned
+
+## Techniques
+
+- **5 Whys**: Dig deeper by asking "why" repeatedly
+- **First Principles**: Break down to fundamental truths
+- **Rubber Duck Debugging**: Explain problem out loud
+- **Divide and Conquer**: Break into smaller sub-problems
+- **Work Backwards**: Start from desired outcome
+- **Analogies**: Apply solutions from similar domains

package/examples/abilities/refactoring.md

@@ -0,0 +1,49 @@
+# Refactoring Ability
+
+Improve code structure without changing behavior.
+
+## When to Refactor
+
+- Before adding new features
+- When code is hard to understand
+- When code has duplications (DRY)
+- When tests are brittle or missing
+- During code review
+
+## Common Refactorings
+
+1. **Extract Function**
+   - Break long functions into smaller ones
+   - Improve readability and reusability
+
+2. **Rename**
+   - Use descriptive names
+   - Reflect current purpose
+
+3. **Extract Variable**
+   - Name complex expressions
+   - Improve readability
+
+4. **Inline**
+   - Remove unnecessary abstractions
+   - Simplify code flow
+
+5. **Move Method/Function**
+   - Improve code organization
+   - Reduce coupling
+
+## Refactoring Process
+
+1. Ensure tests are passing
+2. Make small, incremental changes
+3. Run tests after each change
+4. Commit frequently
+5. Review and validate improvements
+
+## Safety Rules
+
+- Never refactor and add features simultaneously
+- Always have tests before refactoring
+- Make one change at a time
+- Run tests frequently
+- Use version control (commit often)

package/examples/abilities/release-strategy.md

@@ -0,0 +1,58 @@
+# Release Strategy
+
+Plan and execute safe, controlled software releases. Use deployment patterns that minimize risk and enable quick rollback.
+
+## Deployment Patterns
+
+### 1. Blue-Green Deployment
+```bash
+# ✅ Switch traffic instantly
+kubectl apply -f deployment-green.yaml
+curl http://green.example.com/health
+kubectl patch service app -p '{"spec":{"selector":{"version":"green"}}}'
+# Rollback if needed: switch back to blue
+```
+
+### 2. Canary Deployment
+```yaml
+# ✅ Good: Gradual rollout (10% canary, 90% stable)
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  name: app-stable
+spec:
+  replicas: 9
+---
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  name: app-canary
+spec:
+  replicas: 1
+```
+
+### 3. Feature Flags
+```javascript
+// ✅ Good: Gradual feature rollout
+if (featureFlags.isEnabled('new-checkout', user.id)) {
+  return <NewCheckout />;
+}
+```
+
+## Don'ts ❌
+
+```bash
+# ❌ Bad: Big bang release on Friday
+./deploy-all-changes.sh
+# Go home, hope for best
+
+# ❌ Bad: No rollback plan
+```
+
+## Best Practices
+- Release during low-traffic periods
+- Have documented rollback procedure
+- Use feature flags for risky changes
+- Monitor key metrics during/after release
+- Automate deployment process
+- Document release notes

package/examples/abilities/risk-assessment.md

@@ -0,0 +1,19 @@
+Goal
+- Identify and prioritize risks; propose mitigations and owners.
+
+How to do it
+- List risks by category (technical, operational, legal, market).
+- Rate likelihood and impact (Low/Med/High or 1–5).
+- Propose mitigations, triggers, and owners.
+
+Do
+- Use a table: Risk | Likelihood | Impact | Mitigation | Owner | Trigger.
+- Include residual risk after mitigation.
+
+Don’t
+- Don’t list generic risks without project context.
+- Don’t skip ownership/trigger criteria.
+
+Output
+- A prioritized risk register plus a short mitigation plan.
+

package/examples/abilities/secrets-policy.md

@@ -0,0 +1,61 @@
+# Secrets Management Policy
+
+Securely store, rotate, and access secrets (API keys, passwords, certificates). Never commit secrets to version control.
+
+## Do's ✅
+
+```bash
+# ✅ Good: Environment variables
+export DATABASE_URL="postgresql://user:password@localhost/db"
+export API_KEY="sk_live_abc123"
+
+# Access in code
+const dbUrl = process.env.DATABASE_URL;
+```
+
+```javascript
+// ✅ Good: AWS Secrets Manager
+const AWS = require('aws-sdk');
+const client = new AWS.SecretsManager({ region: 'us-east-1' });
+
+async function getSecret(name) {
+  const data = await client.getSecretValue({ SecretId: name }).promise();
+  return JSON.parse(data.SecretString);
+}
+```
+
+```
+# ✅ Good: .gitignore secrets
+.env
+.env.local
+secrets/
+*.pem
+*.key
+```
+
+## Don'ts ❌
+
+```javascript
+// ❌ Bad: Hardcoded secrets
+const API_KEY = "sk_live_abc123xyz";
+const DB_PASSWORD = "SuperSecret123!";
+
+// ❌ Bad: Logging secrets
+logger.info('DB connection', { password: dbPassword });
+
+// ❌ Bad: Secrets in URLs
+fetch(`https://api.com/data?api_key=${apiKey}`);
+// ✅ Good: In headers
+fetch('https://api.com/data', {
+  headers: { 'Authorization': `Bearer ${apiKey}` }
+});
+```
+
+## Best Practices
+- Never commit secrets to git
+- Use secret management tools (Vault, AWS Secrets Manager)
+- Rotate secrets regularly (90 days)
+- Different secrets for dev/staging/prod
+- Audit secret access
+- Encrypt at rest and in transit
+- Use pre-commit hooks (detect-secrets)

package/examples/abilities/secure-coding-review.md

@@ -0,0 +1,51 @@
+# Secure Coding Review
+
+Review code for security vulnerabilities using OWASP Top 10 and secure coding standards. Identify and fix flaws before production.
+
+## OWASP Top 10 Examples
+
+### A01: Broken Access Control
+```javascript
+// ❌ Bad: No authorization
+app.get('/api/users/:id/orders', async (req, res) => {
+  const orders = await db.getOrders(req.params.id);
+  res.json(orders);  // Any user can view any orders!
+});
+
+// ✅ Good: Verify ownership
+app.get('/api/users/:id/orders', auth, async (req, res) => {
+  if (req.user.id !== parseInt(req.params.id)) {
+    return res.status(403).json({ error: 'Forbidden' });
+  }
+  const orders = await db.getOrders(req.params.id);
+  res.json(orders);
+});
+```
+
+### A02: Cryptographic Failures
+```javascript
+// ❌ Bad: Weak hashing
+const hash = crypto.createHash('md5').update(password).digest('hex');
+
+// ✅ Good: Strong hashing
+const hash = await bcrypt.hash(password, 12);
+```
+
+### A03: Injection
+```javascript
+// ❌ Bad: SQL Injection
+const query = `SELECT * FROM users WHERE email = '${email}'`;
+
+// ✅ Good: Parameterized query
+const query = 'SELECT * FROM users WHERE email = ?';
+const results = await db.query(query, [email]);
+```
+
+## Review Checklist
+- ✅ MFA for sensitive actions
+- ✅ Authorization checks on all endpoints
+- ✅ Input validation and sanitization
+- ✅ Parameterized queries
+- ✅ Secrets not hardcoded
+- ✅ TLS 1.2+ required
+- ✅ No sensitive data in logs

package/examples/abilities/security-audit.md

@@ -0,0 +1,65 @@
+# Security Audit Ability
+
+Identify and mitigate security vulnerabilities in code.
+
+## OWASP Top 10 Focus
+
+1. **Injection Attacks**
+   - SQL injection
+   - Command injection
+   - XSS (Cross-Site Scripting)
+   - Prevention: Input validation, parameterized queries
+
+2. **Broken Authentication**
+   - Weak passwords
+   - Session management issues
+   - Missing MFA
+   - Prevention: Strong auth mechanisms, secure sessions
+
+3. **Sensitive Data Exposure**
+   - Unencrypted data
+   - Hardcoded secrets
+   - Logging sensitive info
+   - Prevention: Encryption, secret management
+
+4. **Access Control**
+   - Missing authorization checks
+   - Privilege escalation
+   - IDOR (Insecure Direct Object References)
+   - Prevention: Proper authorization, RBAC
+
+5. **Security Misconfiguration**
+   - Default credentials
+   - Unnecessary services enabled
+   - Debug mode in production
+   - Prevention: Secure defaults, hardening
+
+## Security Checklist
+
+Input Validation:
+
+- [ ] Validate all user inputs
+- [ ] Whitelist > blacklist
+- [ ] Sanitize outputs
+- [ ] Check file upload types and sizes
+
+Authentication & Authorization:
+
+- [ ] Strong password requirements
+- [ ] Secure session management
+- [ ] Proper authorization checks
+- [ ] Rate limiting on auth endpoints
+
+Data Protection:
+
+- [ ] Encrypt sensitive data at rest
+- [ ] Use HTTPS for data in transit
+- [ ] No secrets in code/logs
+- [ ] Secure key management
+
+Code Security:
+
+- [ ] No eval() or dangerous functions
+- [ ] Parameterized queries (no string concat)
+- [ ] Secure random number generation
+- [ ] Dependency vulnerability scanning

package/examples/abilities/sql-optimization.md

@@ -0,0 +1,84 @@
+# SQL Optimization
+
+## Overview
+Optimize SQL queries for performance through proper indexing, query structure, and execution plan analysis. Focus on reducing query time, minimizing resource usage, and scaling efficiently.
+
+## Do's ✅
+
+### Use Indexes Effectively
+```sql
+-- ✅ Good: Index on WHERE clause columns
+CREATE INDEX idx_users_email ON users(email);
+SELECT * FROM users WHERE email = 'user@example.com';
+
+-- ✅ Good: Composite index for multi-column queries
+CREATE INDEX idx_orders_user_date ON orders(user_id, created_at);
+SELECT * FROM orders WHERE user_id = 123 AND created_at > '2024-01-01';
+```
+
+### Use EXPLAIN to Analyze
+```sql
+-- ✅ Always check execution plan
+EXPLAIN ANALYZE
+SELECT * FROM orders o
+JOIN users u ON o.user_id = u.id
+WHERE o.created_at > '2024-01-01';
+```
+
+### Limit Result Sets
+```sql
+-- ✅ Good: Use LIMIT for pagination
+SELECT * FROM products
+ORDER BY created_at DESC
+LIMIT 20 OFFSET 40;
+
+-- ✅ Good: Use EXISTS instead of COUNT
+SELECT EXISTS(SELECT 1 FROM users WHERE email = 'test@example.com');
+```
+
+## Don'ts ❌
+
+### N+1 Query Problem
+```sql
+-- ❌ Bad: N+1 queries
+for each user:
+  SELECT * FROM orders WHERE user_id = user.id;
+
+-- ✅ Good: Single JOIN query
+SELECT u.*, o.*
+FROM users u
+LEFT JOIN orders o ON u.id = o.user_id;
+```
+
+### SELECT *
+```sql
+-- ❌ Bad: Fetching unnecessary columns
+SELECT * FROM users;
+
+-- ✅ Good: Select only needed columns
+SELECT id, email, name FROM users;
+```
+
+### Function on Indexed Column
+```sql
+-- ❌ Bad: Function prevents index usage
+SELECT * FROM users WHERE LOWER(email) = 'test@example.com';
+
+-- ✅ Good: Function index or direct comparison
+CREATE INDEX idx_users_email_lower ON users(LOWER(email));
+-- OR store email in lowercase
+SELECT * FROM users WHERE email = 'test@example.com';
+```
+
+## Best Practices
+
+1. **Index foreign keys** used in JOINs
+2. **Use connection pooling** to reduce overhead
+3. **Batch operations** instead of row-by-row
+4. **Monitor slow queries** with database logs
+5. **Use appropriate data types** (INT vs BIGINT)
+
+## Resources
+- [PostgreSQL Performance Tips](https://wiki.postgresql.org/wiki/Performance_Optimization)
+- [MySQL Optimization](https://dev.mysql.com/doc/refman/8.0/en/optimization.html)
+- [Use The Index, Luke](https://use-the-index-luke.com/)

package/examples/abilities/state-management.md

@@ -0,0 +1,96 @@
+# State Management
+
+Manage application state effectively using appropriate patterns and tools.
+
+## State Classification
+
+### 1. Local State
+- Component-specific state (form inputs, UI toggles)
+- Use: useState, useReducer
+- Keep state close to where it's used
+
+### 2. Shared State
+- State shared between multiple components
+- Use: Context API for theme, auth, locale
+- Avoid Context for frequently changing values (causes re-renders)
+
+### 3. Server State
+- Data fetched from APIs
+- Use: React Query, SWR, or Apollo Client
+- Benefits: caching, background updates, optimistic UI
+- Don't store server data in global state
+
+### 4. Global Application State
+- Complex state shared across the app
+- Use: Redux Toolkit, Zustand, Jotai, or Recoil
+- Examples: shopping cart, user preferences, app config
+
+## Choosing the Right Tool
+
+| State Type | Tool | Use Case |
+|------------|------|----------|
+| Local UI | useState | Form inputs, modals, dropdowns |
+| Computed | useMemo | Derived values, expensive calculations |
+| Shared Simple | Context | Theme, auth status, locale |
+| Server Data | React Query/SWR | API data, caching, refetching |
+| Global Complex | Redux/Zustand | Cart, multi-step forms, app-wide config |
+
+## Best Practices
+
+### State Placement
+- Keep state as local as possible
+- Lift state up only when necessary
+- Avoid prop drilling (use Context or state management library)
+- Co-locate state with components that use it
+
+### State Updates
+- Never mutate state directly (use immutable updates)
+- Use functional updates for state that depends on previous value
+- Batch related state updates
+- Avoid excessive state splitting (group related state)
+
+### Performance
+- Memoize expensive computations (useMemo)
+- Memoize callbacks (useCallback)
+- Use state selectors to prevent unnecessary re-renders
+- Split contexts to avoid re-rendering unrelated components
+
+### Context API Guidelines
+- Create separate contexts for separate concerns
+- Don't put frequently changing values in Context (causes re-renders)
+- Use Context for truly global, infrequently changing data
+- Consider useMemo for context values
+
+### Redux Toolkit Guidelines
+- Use createSlice for reducers
+- Use createAsyncThunk for async actions
+- Use selectors with reselect for derived data
+- Normalize complex nested state
+- Keep business logic in reducers, not components
+
+### React Query/SWR Guidelines
+- Set appropriate staleTime and cacheTime
+- Use queryKey properly (includes dependencies)
+- Implement optimistic updates for better UX
+- Handle loading and error states
+- Use mutations for POST/PUT/DELETE
+
+## Anti-Patterns to Avoid
+
+❌ Storing server data in Redux (use React Query instead)
+❌ Putting everything in global state
+❌ Mutating state directly
+❌ Using Context for high-frequency updates
+❌ Over-fetching data (fetch only what you need)
+❌ Ignoring loading and error states
+❌ Complex state logic in components (move to reducers/hooks)
+
+## Quick Checklist
+
+- [ ] State is placed at appropriate level (local vs shared)
+- [ ] Using correct tool for state type
+- [ ] Server state managed by React Query/SWR
+- [ ] State updates are immutable
+- [ ] Performance optimizations applied (memoization, selectors)
+- [ ] Loading and error states handled
+- [ ] No prop drilling (use Context or state library)

package/examples/abilities/task-planning.md

@@ -0,0 +1,65 @@
+# Task Planning Ability
+
+Break down complex projects into manageable tasks.
+
+## Planning Process
+
+1. **Understand** the goal
+   - Clarify requirements
+   - Identify constraints
+   - Define success criteria
+
+2. **Decompose** into tasks
+   - Break into phases
+   - Identify dependencies
+   - Estimate effort
+   - Prioritize
+
+3. **Create** actionable steps
+   - Each task should be:
+     - Specific and clear
+     - Measurable
+     - Achievable
+     - Time-bound
+
+4. **Review** and adjust
+   - Check for gaps
+   - Validate estimates
+   - Get stakeholder approval
+   - Adjust as needed
+
+## Task Template
+
+```
+Task: [Clear, action-oriented title]
+
+Description:
+- What needs to be done
+- Why it's important
+- Expected outcome
+
+Acceptance Criteria:
+- [ ] Criterion 1
+- [ ] Criterion 2
+- [ ] Criterion 3
+
+Estimate: [time estimate]
+Priority: [High/Medium/Low]
+Dependencies: [other tasks]
+```
+
+## Prioritization Framework
+
+**Eisenhower Matrix:**
+
+1. Urgent + Important: Do first
+2. Important + Not urgent: Schedule
+3. Urgent + Not important: Delegate
+4. Neither: Eliminate
+
+**Value vs Effort:**
+
+- High value, low effort: Quick wins
+- High value, high effort: Major projects
+- Low value, low effort: Fill-ins
+- Low value, high effort: Avoid