@defai.digital/automatosx 12.8.6 → 13.1.2

package/examples/abilities/solid-principles.md

@@ -1,341 +0,0 @@
-# SOLID Principles Ability
-
-Expert understanding and application of SOLID principles for object-oriented design.
-
-## Overview
-
-SOLID is an acronym for five design principles that make software designs more understandable, flexible, and maintainable.
-
-## The Five Principles
-
-### 1. Single Responsibility Principle (SRP)
-
-**Definition**: A class should have one, and only one, reason to change.
-
-**Key Concepts**:
-- Each module/class should have responsibility over a single part of functionality
-- Separate concerns into different classes
-- High cohesion within classes
-- Changes to one responsibility don't affect others
-
-**Code Smells (Violations)**:
-- "God classes" that do everything
-- Classes with multiple unrelated methods
-- Classes that change for multiple reasons
-- Mixed business logic and infrastructure
-
-**Examples**:
-```typescript
-// ❌ BAD: Multiple responsibilities
-class UserManager {
-  saveToDatabase(user: User) { }
-  sendWelcomeEmail(user: User) { }
-  generateReport(user: User) { }
-  validateUser(user: User) { }
-}
-
-// ✅ GOOD: Single responsibilities
-class UserRepository {
-  save(user: User) { }
-}
-class EmailService {
-  sendWelcomeEmail(user: User) { }
-}
-class ReportGenerator {
-  generate(user: User) { }
-}
-class UserValidator {
-  validate(user: User) { }
-}
-```
-
-### 2. Open/Closed Principle (OCP)
-
-**Definition**: Software entities should be open for extension but closed for modification.
-
-**Key Concepts**:
-- Extend behavior without modifying existing code
-- Use abstraction and polymorphism
-- New features via new code, not changed code
-- Reduces regression risk
-
-**Code Smells (Violations)**:
-- Long switch/if-else chains for type checking
-- Modifying existing classes to add new features
-- Tight coupling to concrete implementations
-
-**Examples**:
-```typescript
-// ❌ BAD: Must modify class to add new shapes
-class AreaCalculator {
-  calculateArea(shape: any) {
-    if (shape.type === 'circle') {
-      return Math.PI * shape.radius ** 2;
-    } else if (shape.type === 'rectangle') {
-      return shape.width * shape.height;
-    }
-    // Must add new else-if for each shape type
-  }
-}
-
-// ✅ GOOD: Open for extension via new implementations
-interface Shape {
-  calculateArea(): number;
-}
-
-class Circle implements Shape {
-  constructor(private radius: number) {}
-  calculateArea() {
-    return Math.PI * this.radius ** 2;
-  }
-}
-
-class Rectangle implements Shape {
-  constructor(private width: number, private height: number) {}
-  calculateArea() {
-    return this.width * this.height;
-  }
-}
-
-class AreaCalculator {
-  calculateTotal(shapes: Shape[]) {
-    return shapes.reduce((sum, shape) => sum + shape.calculateArea(), 0);
-  }
-}
-```
-
-### 3. Liskov Substitution Principle (LSP)
-
-**Definition**: Objects of a superclass should be replaceable with objects of its subclasses without breaking the application.
-
-**Key Concepts**:
-- Subtypes must be substitutable for base types
-- Derived classes must honor base class contracts
-- Preconditions cannot be strengthened
-- Postconditions cannot be weakened
-
-**Code Smells (Violations)**:
-- Subclass throws exceptions on base class methods
-- Subclass changes expected behavior
-- Subclass requires type checking before use
-- "Is-a" relationship violated
-
-**Examples**:
-```typescript
-// ❌ BAD: Square violates Rectangle's contract
-class Rectangle {
-  constructor(protected width: number, protected height: number) {}
-
-  setWidth(width: number) { this.width = width; }
-  setHeight(height: number) { this.height = height; }
-  getArea() { return this.width * this.height; }
-}
-
-class Square extends Rectangle {
-  setWidth(width: number) {
-    this.width = width;
-    this.height = width; // Breaks expectation
-  }
-  setHeight(height: number) {
-    this.width = height; // Breaks expectation
-    this.height = height;
-  }
-}
-
-// ✅ GOOD: Separate hierarchies
-interface Shape {
-  getArea(): number;
-}
-
-class Rectangle implements Shape {
-  constructor(private width: number, private height: number) {}
-  getArea() { return this.width * this.height; }
-}
-
-class Square implements Shape {
-  constructor(private size: number) {}
-  getArea() { return this.size * this.size; }
-}
-```
-
-### 4. Interface Segregation Principle (ISP)
-
-**Definition**: Clients should not be forced to depend on interfaces they don't use.
-
-**Key Concepts**:
-- Many small, specific interfaces better than one large interface
-- Avoid "fat interfaces" with unused methods
-- Clients depend only on methods they need
-- High cohesion in interfaces
-
-**Code Smells (Violations)**:
-- Interface with many unrelated methods
-- Classes implementing interfaces with empty/throw methods
-- Clients importing interfaces with unused methods
-
-**Examples**:
-```typescript
-// ❌ BAD: Fat interface forces unnecessary dependencies
-interface Worker {
-  work(): void;
-  eat(): void;
-  sleep(): void;
-}
-
-class Robot implements Worker {
-  work() { /* ... */ }
-  eat() { throw new Error('Robots don\'t eat'); }
-  sleep() { throw new Error('Robots don\'t sleep'); }
-}
-
-// ✅ GOOD: Segregated interfaces
-interface Workable {
-  work(): void;
-}
-
-interface Feedable {
-  eat(): void;
-}
-
-interface Sleepable {
-  sleep(): void;
-}
-
-class Human implements Workable, Feedable, Sleepable {
-  work() { /* ... */ }
-  eat() { /* ... */ }
-  sleep() { /* ... */ }
-}
-
-class Robot implements Workable {
-  work() { /* ... */ }
-}
-```
-
-### 5. Dependency Inversion Principle (DIP)
-
-**Definition**: High-level modules should not depend on low-level modules. Both should depend on abstractions.
-
-**Key Concepts**:
-- Depend on abstractions, not concretions
-- Use dependency injection
-- Decouple high-level policy from low-level details
-- Enables testability and flexibility
-
-**Code Smells (Violations)**:
-- Direct instantiation of dependencies (new keyword everywhere)
-- Tight coupling to concrete classes
-- Hard to test due to embedded dependencies
-- Cannot swap implementations
-
-**Examples**:
-```typescript
-// ❌ BAD: High-level depends on low-level
-class EmailNotifier {
-  send(message: string) {
-    // Send email
-  }
-}
-
-class UserService {
-  private notifier = new EmailNotifier(); // Tight coupling
-
-  registerUser(user: User) {
-    // ...
-    this.notifier.send('Welcome!');
-  }
-}
-
-// ✅ GOOD: Both depend on abstraction
-interface Notifier {
-  send(message: string): void;
-}
-
-class EmailNotifier implements Notifier {
-  send(message: string) {
-    // Send email
-  }
-}
-
-class SMSNotifier implements Notifier {
-  send(message: string) {
-    // Send SMS
-  }
-}
-
-class UserService {
-  constructor(private notifier: Notifier) {} // Dependency injection
-
-  registerUser(user: User) {
-    // ...
-    this.notifier.send('Welcome!');
-  }
-}
-```
-
-## Applying SOLID in Code Reviews
-
-### Review Checklist
-
-**Single Responsibility:**
-- [ ] Does each class have a clear, single purpose?
-- [ ] Can you describe the class's responsibility in one sentence?
-- [ ] Would changes to different features require changing this class?
-
-**Open/Closed:**
-- [ ] Can new behavior be added without modifying existing code?
-- [ ] Are variations handled through polymorphism?
-- [ ] Is the code using abstraction appropriately?
-
-**Liskov Substitution:**
-- [ ] Can subclasses be used anywhere the base class is expected?
-- [ ] Do derived classes honor base class contracts?
-- [ ] Are preconditions and postconditions preserved?
-
-**Interface Segregation:**
-- [ ] Are interfaces focused and cohesive?
-- [ ] Do clients only depend on methods they use?
-- [ ] Are there any "fat interfaces" to split?
-
-**Dependency Inversion:**
-- [ ] Are dependencies injected rather than created?
-- [ ] Do modules depend on abstractions?
-- [ ] Is the code testable with mock dependencies?
-
-## Common Trade-offs
-
-**Simplicity vs. Flexibility:**
-- Don't over-engineer for flexibility you don't need
-- Apply SOLID when complexity justifies it
-- Start simple, refactor when patterns emerge
-
-**Abstraction Overhead:**
-- Every abstraction adds cognitive load
-- Balance between flexibility and understandability
-- Concrete is simpler, abstract is more flexible
-
-**Performance:**
-- Indirection can add minimal overhead
-- Maintainability usually outweighs micro-optimizations
-- Profile before optimizing away good design
-
-## When to Apply SOLID
-
-**Good Candidates:**
-- Business logic and domain models
-- Core abstractions used throughout system
-- Code expected to change frequently
-- Public APIs and interfaces
-
-**Less Important:**
-- Simple data structures
-- One-off scripts or tools
-- Performance-critical tight loops
-- Code unlikely to change
-
-## Further Reading
-
-- "Clean Architecture" by Robert C. Martin
-- "Design Patterns" by Gang of Four
-- "Refactoring" by Martin Fowler
-- "Growing Object-Oriented Software, Guided by Tests" by Freeman and Pryce

package/examples/abilities/sql-optimization.md

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

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

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

package/examples/abilities/technical-writing.md

@@ -1,77 +0,0 @@
-# Technical Writing Ability
-
-Write clear, concise technical documentation.
-
-## Writing Principles
-
-1. **Know Your Audience**
-   - Beginners: Explain concepts, avoid jargon
-   - Experts: Be concise, focus on details
-   - Mixed: Layer information (overview → details)
-
-2. **Structure Logically**
-   - Start with overview/summary
-   - Use clear headings hierarchy
-   - One idea per paragraph
-   - End with conclusion/next steps
-
-3. **Be Clear and Concise**
-   - Use simple words
-   - Active voice > passive voice
-   - Short sentences and paragraphs
-   - Remove unnecessary words
-
-4. **Use Examples**
-   - Code examples for APIs
-   - Screenshots for UI
-   - Diagrams for architecture
-   - Real-world scenarios
-
-5. **Make it Scannable**
-   - Use bullet points and lists
-   - Bold key terms
-   - Add code blocks for commands
-   - Include table of contents
-
-## Document Types
-
-### API Documentation
-
-```
-## Function Name
-
-Brief description of what it does.
-
-### Parameters
-- `param1` (type): Description
-- `param2` (type, optional): Description
-
-### Returns
-- `type`: Description of return value
-
-### Example
-\`\`\`language
-code example
-\`\`\`
-
-### Errors
-- `ErrorType`: When this error occurs
-```
-
-### Tutorial
-
-1. **Introduction**: What you'll build/learn
-2. **Prerequisites**: What's needed before starting
-3. **Step-by-step instructions**: Numbered, detailed
-4. **Code examples**: Complete, working code
-5. **Next steps**: Where to go from here
-
-### README
-
-1. **Project name and description**
-2. **Installation instructions**
-3. **Quick start example**
-4. **Features list**
-5. **Configuration options**
-6. **Contributing guidelines**
-7. **License**

package/examples/abilities/telemetry-diagnostics.md

@@ -1,51 +0,0 @@
-# Telemetry Diagnostics
-
-## Overview
-
-Develop telemetry analysis pipelines for spacecraft health monitoring, anomaly
-detection, and root-cause investigation to maintain mission safety and
-performance.
-
-## Core Concepts & Best Practices
-
-- **Telemetry Architecture**: Define packet structures, sampling cadences, and
-  data routing between on-board computers, ground stations, and archives.
-- **Signal Conditioning**: Calibrate sensor data, apply filtering (e.g., Kalman,
-  Savitzky-Golay), and manage quantization or time skew.
-- **Anomaly Detection**: Use rule-based thresholds, state estimation
-  residuals, and machine learning classifiers (e.g., autoencoders, Bayesian
-  models).
-- **Fault Isolation**: Correlate cross-subsystem data, maintain fault trees,
-  and perform change point analysis to localize issues quickly.
-- **Operational Resilience**: Establish alert prioritization, escalation
-  paths, and simulation back-testing for flight director readiness.
-
-## Tools & Methodologies
-
-- **Data Platforms**: Deploy time-series databases (InfluxDB, TimescaleDB) with
-  visualization tools (Grafana, Jupyter) for rapid insight.
-- **Processing Pipelines**: Implement streaming analytics with Apache
-  Flink/Spark or cloud-native services; ensure deterministic reprocessing.
-- **Model Libraries**: Utilize Python packages (scikit-learn, PyOD), MATLAB
-  toolboxes, or NASA VIPER for anomaly analytics.
-- **Playback & Simulation**: Reconstruct telemetry scenarios with digital twins
-  or hardware-in-the-loop setups to validate hypotheses.
-- **Configuration Management**: Version-control telemetry definitions, limit
-  changes via configuration control boards, and audit ground software.
-
-## Example Scenario
-
-During a LEO mission, battery temperature sensors report sporadic spikes.
-Engineers run residual analysis against thermal models, replay telemetry
-through a digital twin, and identify a degraded radiator valve actuator. A
-coordinated response adjusts heater duty cycle to maintain safe limits while
-planning hardware replacement.
-
-## Reference Resources
-
-- Jet Propulsion Laboratory, *Spacecraft Telemetry Handbook*
-- NASA Fault Management Handbook, NASA-HDBK-1002
-- ESA OPS-GEN, *Mission Operations Ground Data Systems*
-- Lopez et al., “Deep Learning for Spacecraft Telemetry Anomaly Detection,”
-  *Acta Astronautica* (2020)
-- MITRE, *Telemetry Data Management Best Practices*