Migrate Priority 1 documentation from cortex-platform

Architecture (12 files):
- 3 ADRs (MoE, pattern-based learning, worker pool)
- Core principles framework
- Master-worker pattern
- Mixture of Experts architecture
- ML/AI system architecture
- Event-driven architecture
- Hybrid routing architecture
- Medallion architecture
- Automation architecture

Operations (15 runbooks):
- Daily operations checklist
- Emergency recovery procedures
- Worker lifecycle and failure handling
- Daemon management
- Circuit breaker recovery
- MoE router troubleshooting
- Performance debugging
- Task queue management
- Token budget management
- Data quality issues
- Self-healing operations
- Pre-deployment testing
- And more...

Knowledge (11 guides):
- Quick start guide
- Developer guide
- Command cheatsheet
- Self-healing system
- Auto-learning system
- Coordination protocol
- Evaluation framework
- RAG system implementation
- ML/AI quickstart and deployment
- Prompting best practices

Total: 38 documentation files migrated
Source: cortex-platform/docs and cortex-k3s root

Author: ry-ops

vault/architecture/adrs/001-use-moe-architecture.md

@@ -0,0 +1,105 @@
+# ADR 001: Use Mixture of Experts (MoE) Architecture
+
+**Status**: Accepted  
+**Date**: 2025-11-01  
+**Deciders**: System Architects  
+**Technical Story**: Multi-repository management system
+
+## Context
+
+cortex needs to manage multiple repositories efficiently with specialized expertise for different types of tasks (development, security, CI/CD, inventory management). A single monolithic approach would lack the specialization needed for optimal task execution.
+
+## Decision
+
+We will use a Mixture of Experts (MoE) architecture with specialized master agents:
+
+- **Coordinator Master**: Routes tasks to appropriate specialist masters
+- **Development Master**: Handles feature development and bug fixes
+- **Security Master**: Manages security scans and vulnerability remediation
+- **CI/CD Master**: Orchestrates builds, tests, and deployments
+- **Inventory Master**: Catalogs and documents repositories
+- **Dashboard Master**: Provides real-time monitoring
+
+## Rationale
+
+### Advantages
+
+1. **Specialization**: Each master has focused expertise
+2. **Scalability**: Masters can scale independently
+3. **Maintainability**: Clear separation of concerns
+4. **Performance**: Parallel task execution
+5. **Learning**: Pattern-based routing improves over time
+
+### Example Routing Logic
+
+```javascript
+function routeTask(task) {
+  if (task.description.match(/security|cve|vulnerability/i)) {
+    return 'security-master';
+  }
+  if (task.description.match(/deploy|build|test|ci/i)) {
+    return 'cicd-master';
+  }
+  if (task.description.match(/fix|bug|feature|implement/i)) {
+    return 'development-master';
+  }
+  return 'coordinator-master'; // Default fallback
+}
+```
+
+## Consequences
+
+### Positive
+
+- Clear task ownership
+- Better resource utilization
+- Improved success rates through specialization
+- Easier to add new masters
+
+### Negative
+
+- Increased system complexity
+- Routing overhead
+- Potential routing errors
+- Need for coordinator logic
+
+### Mitigation
+
+- Confidence scoring for routing decisions
+- Fallback to coordinator for uncertain tasks
+- Continuous learning from routing outcomes
+- Monitoring and alerting on routing confidence
+
+## Implementation
+
+- **Routing Logic**: `coordination/masters/coordinator/lib/moe-router.sh`
+- **Master Specs**: `coordination/masters/{master-name}/`
+- **Task Queue**: `coordination/tasks/pending/`
+- **Decision Log**: `coordination/masters/coordinator/knowledge-base/routing-decisions.jsonl`
+
+## Alternatives Considered
+
+### 1. Monolithic Agent
+
+**Pros**: Simpler architecture  
+**Cons**: Lacks specialization, harder to scale
+
+### 2. Rule-Based Task Assignment
+
+**Pros**: Predictable routing  
+**Cons**: Inflexible, no learning capability
+
+### 3. Manual Task Assignment
+
+**Pros**: Full control  
+**Cons**: Not scalable, requires human intervention
+
+## Related Decisions
+
+- ADR 002: Pattern-Based Learning for Routing
+- ADR 003: Worker Pool Management
+
+## References
+
+- [Mixture of Experts Paper](https://arxiv.org/abs/1701.06538)
+- [MoE Implementation Guide](https://github.com/ry-ops/cortex/wiki/MoE-Architecture)

vault/architecture/adrs/002-pattern-based-learning.md

@@ -0,0 +1,83 @@
+# ADR 002: Pattern-Based Learning for MoE Routing
+
+**Status**: Accepted  
+**Date**: 2025-11-15  
+**Deciders**: ML Team, System Architects  
+
+## Context
+
+Initial MoE routing used simple keyword matching, resulting in:
+- 65% routing accuracy
+- No improvement over time
+- Inability to handle novel task types
+
+We need routing to improve based on historical outcomes.
+
+## Decision
+
+Implement pattern-based learning that:
+
+1. **Logs all routing decisions** with outcomes
+2. **Learns from successful routes** (task completion)
+3. **Adjusts confidence scores** based on patterns
+4. **Updates routing model** hourly
+
+### Learning Algorithm
+
+```javascript
+function updateRoutingModel(decision, outcome) {
+  const pattern = extractPattern(decision.task);
+  const success = outcome.status === 'completed';
+  
+  // Update pattern weights
+  if (success) {
+    patterns[pattern].weight += 0.1;
+    patterns[pattern].confidence = Math.min(patterns[pattern].confidence + 0.05, 1.0);
+  } else {
+    patterns[pattern].weight -= 0.05;
+    patterns[pattern].confidence = Math.max(patterns[pattern].confidence - 0.1, 0);
+  }
+  
+  // Save updated patterns
+  savePatterns(patterns);
+}
+```
+
+## Rationale
+
+- **Continuous Improvement**: System gets smarter over time
+- **Data-Driven**: Based on actual outcomes, not assumptions
+- **Adaptive**: Handles new task types automatically
+- **Transparent**: All decisions logged for review
+
+## Consequences
+
+### Positive
+
+- Routing accuracy improved from 65% → 85%
+- Handles edge cases better
+- Self-optimizing system
+- Confidence scores guide decision-making
+
+### Negative
+
+- Requires historical data to be effective
+- Cold start problem for new task types
+- Pattern storage overhead
+- Potential overfitting to specific scenarios
+
+## Implementation
+
+- **Pattern Storage**: `coordination/knowledge-base/learned-patterns/patterns-latest.json`
+- **Learning Script**: `llm-mesh/moe-learning/evaluators/pattern-learner.sh`
+- **Metrics**: `coordination/metrics/learning/learner-metrics.jsonl`
+
+## Metrics
+
+Target metrics after 1000 routing decisions:
+
+| Metric | Target | Current |
+|--------|--------|---------|
+| Routing Accuracy | 90% | 85% |
+| Avg Confidence | 0.80 | 0.75 |
+| Pattern Coverage | 95% | 90% |

vault/architecture/adrs/003-worker-pool-management.md

@@ -0,0 +1,57 @@
+# ADR 003: Worker Pool Management Strategy
+
+**Status**: Accepted  
+**Date**: 2025-11-20  
+
+## Context
+
+Workers are spawned on-demand, causing:
+- 2-3 second cold start delay
+- Inefficient resource usage
+- Slow task execution
+
+## Decision
+
+Implement pre-warmed worker pool with:
+
+- **Min Pool Size**: 5 workers
+- **Max Pool Size**: 20 workers
+- **Scale Up**: When queue > 10 tasks
+- **Scale Down**: When idle > 5 minutes
+
+## Implementation
+
+```javascript
+class WorkerPool {
+  constructor() {
+    this.minSize = 5;
+    this.maxSize = 20;
+    this.pool = [];
+    this.initializePool();
+  }
+  
+  initializePool() {
+    for (let i = 0; i < this.minSize; i++) {
+      this.spawnWorker();
+    }
+  }
+  
+  scaleUp() {
+    if (this.pool.length < this.maxSize) {
+      this.spawnWorker();
+    }
+  }
+  
+  scaleDown() {
+    if (this.pool.length > this.minSize) {
+      this.killIdleWorker();
+    }
+  }
+}
+```
+
+## Results
+
+- Cold start: 2000ms → 100ms (20x faster)
+- Resource utilization: 20% → 75%
+- Task throughput: 10/min → 50/min