@defai.digital/automatosx 12.8.7 → 13.1.2

package/examples/abilities/release-strategy.md

@@ -1,58 +0,0 @@
-# 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/secrets-policy.md

@@ -1,61 +0,0 @@
-# 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

@@ -1,60 +0,0 @@
-# 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
-
-## Application Hints
-
-When reviewing for security:
-- Check authorization on every endpoint; authentication alone is not sufficient
-- Verify parameterized queries for all database operations, including ORMs
-- Ensure secrets are never hardcoded; check for API keys in config files and env vars
-- Validate all user input at trust boundaries, not deep in business logic
-- Review logging to ensure no PII, tokens, or credentials are exposed

package/examples/abilities/software-architecture.md

@@ -1,394 +0,0 @@
-# Software Architecture Ability
-
-Expert knowledge of software architecture patterns, principles, and system design for building scalable, maintainable applications.
-
-## Overview
-
-Software architecture is the fundamental organization of a system, embodied in its components, their relationships, and the principles governing its design and evolution.
-
-## Architectural Principles
-
-### 1. Separation of Concerns
-
-Divide application into distinct sections, each addressing a separate concern.
-
-**Benefits**:
-- Easier to understand and maintain
-- Enables parallel development
-- Facilitates testing and reuse
-
-**Examples**:
-- Presentation vs. Business Logic vs. Data Access
-- Read models vs. Write models (CQRS)
-- Frontend vs. Backend
-
-### 2. Modularity and Encapsulation
-
-Break system into independent, interchangeable modules with well-defined interfaces.
-
-**Principles**:
-- High cohesion: Related functionality together
-- Low coupling: Minimal dependencies between modules
-- Information hiding: Internal implementation details hidden
-
-### 3. Abstraction
-
-Hide complexity behind simpler interfaces.
-
-**Levels**:
-- Hardware → Operating System
-- Operating System → Runtime
-- Runtime → Framework
-- Framework → Application
-
-### 4. Layering
-
-Organize system into horizontal layers with clear responsibilities.
-
-**Rules**:
-- Each layer depends only on layers below
-- Higher layers use services of lower layers
-- No circular dependencies
-
-### 5. Don't Repeat Yourself (DRY)
-
-Every piece of knowledge should have a single authoritative representation.
-
-### 6. YAGNI (You Aren't Gonna Need It)
-
-Don't add functionality until it's necessary.
-
-## Common Architectural Patterns
-
-### Layered Architecture
-
-**Structure**: Organized into horizontal layers
-**Layers** (typical):
-1. Presentation Layer (UI)
-2. Application Layer (Use Cases)
-3. Domain Layer (Business Logic)
-4. Infrastructure Layer (Data Access, External Services)
-
-**When to use**:
-- Traditional monolithic applications
-- Clear separation of concerns needed
-- Team organized by technical layers
-
-**Pros**:
-- Simple and well-understood
-- Clear separation of concerns
-- Easy to test layers independently
-
-**Cons**:
-- Can become tightly coupled
-- Changes may ripple through layers
-- Scalability limitations
-
-```
-┌─────────────────────────────┐
-│   Presentation Layer        │
-├─────────────────────────────┤
-│   Application Layer         │
-├─────────────────────────────┤
-│   Domain Layer              │
-├─────────────────────────────┤
-│   Infrastructure Layer      │
-└─────────────────────────────┘
-```
-
-### Hexagonal Architecture (Ports and Adapters)
-
-**Structure**: Core business logic surrounded by adapters for external systems
-
-**Components**:
-- **Core**: Domain logic (pure, no dependencies)
-- **Ports**: Interfaces defining how core interacts with outside
-- **Adapters**: Implementations of ports (DB, HTTP, etc.)
-
-**When to use**:
-- Domain-driven design
-- Need to swap implementations easily
-- Comprehensive test coverage desired
-
-**Pros**:
-- Core is independent of frameworks
-- Easy to test (mock adapters)
-- Flexibility in implementation choices
-
-**Cons**:
-- More complex than layered
-- Requires discipline to maintain boundaries
-- More abstractions and interfaces
-
-```
-        ┌────────────────────┐
-        │   Adapters (DB,    │
-        │   HTTP, etc.)      │
-        └────────┬───────────┘
-                 │
-        ┌────────▼───────────┐
-        │   Ports            │
-        │   (Interfaces)     │
-        └────────┬───────────┘
-                 │
-        ┌────────▼───────────┐
-        │   Domain           │
-        │   (Business Logic) │
-        └────────────────────┘
-```
-
-### Microservices Architecture
-
-**Structure**: Application as collection of small, independent services
-
-**Characteristics**:
-- Each service is independently deployable
-- Services communicate via APIs (HTTP, messaging)
-- Each service has its own database
-- Organized around business capabilities
-
-**When to use**:
-- Large, complex applications
-- Need for independent scaling
-- Multiple teams working independently
-- Polyglot persistence needs
-
-**Pros**:
-- Independent deployment and scaling
-- Technology diversity
-- Fault isolation
-- Team autonomy
-
-**Cons**:
-- Distributed system complexity
-- Network latency
-- Data consistency challenges
-- Operational overhead
-
-### Event-Driven Architecture
-
-**Structure**: Components communicate through events
-
-**Components**:
-- **Event Producers**: Generate events
-- **Event Channels**: Transport events
-- **Event Consumers**: React to events
-
-**Patterns**:
-- Event Notification
-- Event-Carried State Transfer
-- Event Sourcing
-
-**When to use**:
-- Asynchronous processing needed
-- Loose coupling desired
-- Real-time updates required
-- Complex workflows
-
-**Pros**:
-- Loose coupling
-- Scalability
-- Flexibility
-- Asynchronous processing
-
-**Cons**:
-- Complexity in debugging
-- Eventual consistency
-- Event versioning challenges
-
-### CQRS (Command Query Responsibility Segregation)
-
-**Structure**: Separate models for reading and writing data
-
-**Components**:
-- **Command Model**: Handles writes (create, update, delete)
-- **Query Model**: Handles reads (optimized for specific views)
-
-**When to use**:
-- Read and write patterns differ significantly
-- Need to scale reads and writes independently
-- Complex domain logic
-- Event sourcing
-
-**Pros**:
-- Optimized for different access patterns
-- Independent scaling
-- Clear command/query separation
-
-**Cons**:
-- Increased complexity
-- Eventual consistency
-- Synchronization overhead
-
-## Architectural Decision Making
-
-### Architecture Trade-offs
-
-**Performance vs. Maintainability**:
-- Optimize critical paths
-- Keep non-critical code clean and simple
-
-**Flexibility vs. Simplicity**:
-- Don't over-engineer for future needs
-- Refactor when patterns emerge
-
-**Consistency vs. Availability (CAP Theorem)**:
-- Can't have all three: Consistency, Availability, Partition Tolerance
-- Choose based on business requirements
-
-### Evaluating Architectures
-
-**Quality Attributes**:
-- **Performance**: Response time, throughput
-- **Scalability**: Handle increasing load
-- **Availability**: Uptime, fault tolerance
-- **Security**: Authentication, authorization, data protection
-- **Maintainability**: Easy to modify and extend
-- **Testability**: Easy to verify correctness
-- **Deployability**: Easy to deploy and operate
-
-**Architecture Review Checklist**:
-- [ ] Clear separation of concerns
-- [ ] Appropriate abstraction levels
-- [ ] Well-defined component boundaries
-- [ ] Explicit dependencies
-- [ ] Scalability considerations
-- [ ] Security considerations
-- [ ] Testability built in
-- [ ] Operational concerns addressed
-
-## System Design Patterns
-
-### Database Patterns
-
-**Repository Pattern**:
-- Abstract data access logic
-- Decouple domain from persistence
-
-**Unit of Work**:
-- Maintain list of objects affected by transaction
-- Coordinate writing changes
-
-**Database per Service** (Microservices):
-- Each service owns its database
-- No shared databases
-
-### Communication Patterns
-
-**API Gateway**:
-- Single entry point for clients
-- Request routing and composition
-- Cross-cutting concerns (auth, logging)
-
-**Service Mesh**:
-- Infrastructure layer for service-to-service communication
-- Handles retries, timeouts, circuit breaking
-
-**Message Queue**:
-- Asynchronous communication
-- Decoupling producers and consumers
-- Load leveling
-
-### Resilience Patterns
-
-**Circuit Breaker**:
-- Prevent cascading failures
-- Fail fast when service unavailable
-- Automatic recovery attempts
-
-**Retry with Backoff**:
-- Retry failed operations
-- Exponential backoff to avoid overwhelming
-- Maximum retry limit
-
-**Bulkhead**:
-- Isolate resources to prevent total failure
-- Similar to ship compartments
-- Limit impact of failures
-
-**Timeout**:
-- Set maximum wait time
-- Prevent hanging operations
-- Graceful degradation
-
-## Architecture Documentation
-
-### C4 Model
-
-**Context Diagram**: System and its users
-**Container Diagram**: High-level components
-**Component Diagram**: Internal structure
-**Code Diagram**: Class-level details (optional)
-
-### Architecture Decision Records (ADR)
-
-**Template**:
-```
-# ADR-001: Use PostgreSQL for Primary Database
-
-## Status
-Accepted
-
-## Context
-We need a database that supports complex queries, transactions, and scales to millions of records.
-
-## Decision
-We will use PostgreSQL as our primary relational database.
-
-## Consequences
-**Positive**:
-- ACID compliance
-- Rich query capabilities
-- Proven scalability
-- Strong ecosystem
-
-**Negative**:
-- Requires specialized knowledge
-- Vertical scaling limitations
-- Operational overhead
-
-## Alternatives Considered
-- MySQL: Less feature-rich
-- MongoDB: Consistency concerns
-- DynamoDB: Vendor lock-in
-```
-
-## Anti-patterns to Avoid
-
-### Big Ball of Mud
-- No clear architecture
-- Everything depends on everything
-- **Solution**: Gradual refactoring, introduce boundaries
-
-### Monolithic Database
-- All services share one database
-- Tight coupling
-- **Solution**: Database per service, API composition
-
-### Distributed Monolith
-- Microservices that must be deployed together
-- Worst of both worlds
-- **Solution**: True service independence or consolidate
-
-### God Object
-- Single class/service knows/does everything
-- **Solution**: Single Responsibility Principle
-
-## Best Practices
-
-1. **Start Simple**: Don't over-engineer early
-2. **Evolve Architecture**: Refactor as you learn
-3. **Document Decisions**: Use ADRs
-4. **Define Boundaries**: Clear contracts between components
-5. **Test Architecture**: Fitness functions, architecture tests
-6. **Monitor**: Metrics, logging, tracing
-7. **Security by Design**: Not bolted on later
-8. **Operational Concerns**: Deployment, monitoring, debugging
-
-## Further Reading
-
-- "Software Architecture: The Hard Parts" by Neal Ford et al.
-- "Building Microservices" by Sam Newman
-- "Domain-Driven Design" by Eric Evans
-- "Clean Architecture" by Robert C. Martin
-- "Fundamentals of Software Architecture" by Mark Richards and Neal Ford