@defai.digital/automatosx 12.8.7 → 13.1.3

package/examples/abilities/testing.md

@@ -1,56 +0,0 @@
-# Testing Ability
-
-Write comprehensive, maintainable tests for software systems.
-
-## Test Types
-
-1. **Unit Tests** (80% of tests)
-   - Test individual functions/methods
-   - Mock external dependencies
-   - Fast execution (<1ms per test)
-   - High coverage (80%+)
-
-2. **Integration Tests** (15% of tests)
-   - Test component interactions
-   - Use real dependencies when possible
-   - Test critical workflows
-   - Moderate execution time
-
-3. **End-to-End Tests** (5% of tests)
-   - Test complete user workflows
-   - Use production-like environment
-   - Test critical paths only
-   - Slower execution acceptable
-
-## Best Practices
-
-- **Arrange-Act-Assert** pattern
-- One assertion per test (when possible)
-- Clear test names (describe what is tested)
-- Independent tests (no shared state)
-- Fast feedback (optimize test speed)
-
-## Test Coverage Goals
-
-- Critical paths: 100%
-- Business logic: 90%+
-- UI components: 70%+
-- Utility functions: 80%+
-- Overall project: 80%+
-
-## Testing Anti-Patterns to Avoid
-
-- Testing implementation details
-- Brittle tests (break with minor changes)
-- Slow tests (block development)
-- Flaky tests (non-deterministic)
-- No tests (technical debt)
-
-## Application Hints
-
-When writing tests:
-- Test behavior, not implementation details; tests should survive refactoring
-- Prioritize critical paths and edge cases over chasing coverage percentages
-- Keep tests independent; shared state between tests causes flaky failures
-- Make test names describe the expected behavior, not the method being tested
-- Fix flaky tests immediately; they erode trust in the entire test suite

package/examples/abilities/threat-modeling.md

@@ -1,58 +0,0 @@
-# Threat Modeling
-
-Identify, assess, and mitigate security threats systematically using frameworks like STRIDE to analyze attack vectors.
-
-## STRIDE Framework
-
-- **S**poofing: Impersonating user/system
-- **T**ampering: Modifying data/code
-- **R**epudiation: Denying actions
-- **I**nformation Disclosure: Exposing sensitive data
-- **D**enial of Service: Making system unavailable
-- **E**levation of Privilege: Gaining unauthorized access
-
-## Do's ✅
-
-```markdown
-# ✅ Good: Document threats per asset
-## Asset: User Password
-- Spoofing: Attacker uses stolen credentials → Mitigation: MFA
-- Tampering: Hash modified in DB → Mitigation: Hash with bcrypt
-- Information Disclosure: Leaked in logs → Mitigation: No passwords in logs
-- Elevation: Admin password compromised → Mitigation: Rate limiting, complexity
-```
-
-```javascript
-// ✅ Good: Validate and sanitize
-const path = require('path');
-const filename = path.basename(req.body.filename);
-const safePath = path.join('./uploads', filename);
-if (!safePath.startsWith('./uploads/')) {
-  return res.status(400).send('Invalid filename');
-}
-```
-
-## Don'ts ❌
-
-```javascript
-// ❌ Bad: Assuming input is safe
-const filename = req.body.filename;
-fs.writeFile(`./uploads/${filename}`, content);
-// What if filename = "../../etc/passwd"?
-```
-
-## Best Practices
-- Perform threat modeling early in design
-- Update when architecture changes
-- Prioritize by risk (likelihood × impact)
-- Document mitigations
-- Review with security team
-
-## Application Hints
-
-When threat modeling:
-- Identify assets and trust boundaries first before analyzing specific threats
-- Apply STRIDE per component or data flow, not globally across the entire system
-- Prioritize threats by (Impact × Likelihood); don't attempt to fix everything
-- Document residual risks explicitly; security is about informed trade-offs
-- Update the threat model when architecture changes, not just at initial design

package/examples/abilities/troubleshooting.md

@@ -1,80 +0,0 @@
-# Troubleshooting Ability
-
-Systematically diagnose and resolve technical issues.
-
-## Troubleshooting Process
-
-1. **Gather Information**
-   - What is the expected behavior?
-   - What actually happens?
-   - Error messages (exact text)
-   - Steps to reproduce
-   - When did it start?
-   - Recent changes
-
-2. **Reproduce** the Issue
-   - Follow exact steps
-   - Use same environment
-   - Note any variations
-   - Document reproduction steps
-
-3. **Isolate** the Problem
-   - Is it consistent or intermittent?
-   - Which components are affected?
-   - What works vs what doesn't?
-   - Minimum reproduction case
-
-4. **Form Hypothesis**
-   - Based on evidence
-   - Consider multiple possibilities
-   - Most likely cause first
-   - Document reasoning
-
-5. **Test Hypothesis**
-   - Change one variable at a time
-   - Verify results
-   - If wrong, revise hypothesis
-   - Keep track of what you've tried
-
-6. **Implement Solution**
-   - Apply fix
-   - Test thoroughly
-   - Document solution
-   - Prevent recurrence
-
-## Diagnostic Techniques
-
-- **Check Logs**: Application, system, error logs
-- **Verify Basics**: Network, permissions, disk space
-- **Binary Search**: Disable half, narrow down
-- **Compare Environments**: Dev vs prod differences
-- **Monitor Resources**: CPU, memory, network
-- **Review Recent Changes**: Git history, deployments
-- **Test in Isolation**: Minimal setup, mock dependencies
-
-## Common Issues Checklist
-
-Configuration:
-
-- [ ] Environment variables set correctly
-- [ ] Config files in right location
-- [ ] Paths absolute vs relative
-
-Network:
-
-- [ ] Firewall/security groups allow traffic
-- [ ] DNS resolving correctly
-- [ ] SSL certificates valid
-- [ ] Timeouts configured appropriately
-
-Permissions:
-
-- [ ] File permissions correct
-- [ ] User has necessary privileges
-- [ ] Database permissions granted
-
-Dependencies:
-
-- [ ] All dependencies installed
-- [ ] Correct versions
-- [ ] No version conflicts