feat(rlm): add terraphim_rlm crate Phase 1 implementation

Create new terraphim_rlm crate for RLM (Recursive Language Model)
orchestration with Firecracker VM isolation.

Phase 1 includes:
- Core types: SessionId, SessionInfo, BudgetStatus, Command types
- Error types: RlmError with MCP error format support
- Configuration: RlmConfig with pool, budget, security settings
- ExecutionEnvironment trait for pluggable backends
- FirecrackerExecutor stub with snapshot management
- Backend selection logic (Firecracker → E2B → Docker)

Also adds design/specification documentation:
- Research document with sandbox alternatives analysis
- Specification v1.2 with interview findings
- Design document v1.3 with implementation plan
- Quality evaluation reports

All 24 unit tests pass.

🤖 Generated with Terraphim AI

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

Author: AlexMikhalev

.docs/design-rig-rlm-integration.md

@@ -0,0 +1,245 @@
+# Document Quality Evaluation Report
+
+## Metadata
+- **Document**: `/home/alex/projects/terraphim/terraphim-ai-rlm/.docs/design-rig-rlm-integration.md`
+- **Type**: Phase 2 Design
+- **Evaluated**: 2026-01-06
+- **Evaluator**: disciplined-quality-evaluation
+
+## Decision: GO
+
+**Average Score**: 4.33 / 5.0
+**Weighted Average** (Phase 2 weights): 4.43 / 5.0
+**Blocking Dimensions**: None
+
+## Dimension Scores
+
+| Dimension | Score | Weight | Weighted | Status |
+|-----------|-------|--------|----------|--------|
+| Syntactic | 5/5 | 1.5 | 7.5 | Pass (Critical) |
+| Semantic | 4/5 | 1.0 | 4.0 | Pass |
+| Pragmatic | 5/5 | 1.5 | 7.5 | Pass (Critical) |
+| Social | 4/5 | 1.0 | 4.0 | Pass |
+| Physical | 5/5 | 1.0 | 5.0 | Pass |
+| Empirical | 3/5 | 1.0 | 3.0 | Pass |
+
+**Weighted Average Calculation**: (7.5 + 4.0 + 7.5 + 4.0 + 5.0 + 3.0) / 7.0 = 4.43
+
+---
+
+## Detailed Findings
+
+### 1. Syntactic Quality (5/5) - Pass (Critical Dimension)
+
+**Strengths:**
+- **Section 4**: File paths use consistent format `crates/terraphim_rlm/src/*.rs` throughout all tables
+- **Section 5**: Step numbering (1-29) is sequential with no gaps; phase groupings (1-7) are logical
+- **Section 2**: Invariants (INV-1 through INV-5) and Acceptance Criteria (AC-1 through AC-8) use consistent ID scheme
+- **Section 6**: Testing strategy cross-references AC-* and INV-* IDs correctly
+- All component names (`TerraphimRlm`, `FirecrackerExecutor`, `SessionManager`) used consistently
+
+**Weaknesses:**
+- None significant
+
+**Suggested Revisions:**
+- None required
+
+---
+
+### 2. Semantic Quality (4/5) - Pass
+
+**Strengths:**
+- **Section 4**: File paths reference actual existing crates (`terraphim_firecracker`, `terraphim_mcp_server`) verified in workspace
+- **Section 3.1**: Component diagram accurately reflects terraphim architecture patterns
+- **Appendix A**: Dependency graph matches actual crate relationships in Cargo.toml
+- **Section 7.1**: Risk mitigations reference specific design decisions (HTTP bridge, bypassing rig-core)
+
+**Weaknesses:**
+- **Section 4.2**: File `src/executor.rs` listed alongside `src/executor/mod.rs` - unclear if these are alternatives or both needed
+- **Section 5, Step 9**: References `terraphim_rlm/src/llm_bridge.rs` but this file not in Section 4.1 file list
+
+**Suggested Revisions:**
+- [ ] Clarify executor module structure: is it `src/executor.rs` OR `src/executor/mod.rs` + submodules?
+- [ ] Add `llm_bridge.rs` to Section 4.1 file list, or clarify where this functionality lives
+
+---
+
+### 3. Pragmatic Quality (5/5) - Pass (Critical Dimension)
+
+**Strengths:**
+- **Section 5**: 29 implementation steps each marked with "Deployable?" column - enables incremental delivery
+- **Section 5**: Checkpoints after each phase provide clear milestones
+- **Section 4**: Every file has Action (Create/Modify), Responsibility, and Dependencies columns
+- **Section 6**: Every acceptance criterion maps to specific test location and type
+- **Section 8**: Questions categorized as "Decisions Needed Before", "Decisions That Can Wait", and "Clarifications"
+- **Appendix B**: File count summary (25 new, 4 modified, 29 total) provides implementer with scope estimate
+
+**Weaknesses:**
+- None - this is an exemplary implementation plan
+
+**Suggested Revisions:**
+- None required
+
+---
+
+### 4. Social Quality (4/5) - Pass
+
+**Strengths:**
+- **Section 3.2**: "Does NOT Do" column explicitly prevents responsibility creep
+- **Section 3.3**: "Complected Areas to Avoid" table surfaces potential confusion points
+- **Section 2.1**: Invariants stated as testable assertions, not vague principles
+- **Section 7.3**: Complexity ratings (High/Medium/Low) with reasons prevent underestimation
+
+**Weaknesses:**
+- **Section 5, Phase 2**: "Core Execution" is vague - Steps 5-9 span VM allocation, execution, AND LLM bridge
+- **Section 8.1**: "Default budget values" recommendation says "Conservative" without defining what that means numerically
+
+**Suggested Revisions:**
+- [ ] Consider splitting Phase 2 into "VM Execution" (Steps 5-8) and "LLM Bridge" (Step 9) for clarity
+- [ ] In Section 8.1, add specific numbers for "Conservative" (already in spec: 100K tokens, 5 min)
+
+---
+
+### 5. Physical Quality (5/5) - Pass
+
+**Strengths:**
+- All 8 expected Phase 2 sections present with correct headers
+- Consistent table formatting throughout (29 tables total)
+- ASCII component diagram in Section 3.1 clearly shows architecture
+- Appendices A-C separate auxiliary information from core plan
+- Section numbering enables precise references
+- Horizontal rules separate major sections
+
+**Weaknesses:**
+- None - formatting is exemplary
+
+**Suggested Revisions:**
+- None required
+
+---
+
+### 6. Empirical Quality (3/5) - Pass (Borderline)
+
+**Strengths:**
+- Implementation sequence broken into 7 phases with checkpoints
+- Tables reduce cognitive load for file lists and mappings
+- Appendices moved detailed reference material out of main flow
+
+**Weaknesses:**
+- **Section 5**: 29 steps in 7 phases - high volume requires multiple reads to understand full scope
+- **Section 4**: Three large file tables (4.1, 4.2, 4.3) in sequence - dense information block
+- **Overall**: Document is 400+ lines - substantial reading commitment
+
+**Suggested Revisions:**
+- [ ] Consider adding TL;DR summary of phases at start of Section 5
+- [ ] Optional: Add estimated effort per phase (e.g., "Phase 1: ~2 hours, Phase 2: ~1 day")
+
+---
+
+## Revision Checklist
+
+Priority order based on impact on implementation:
+
+### High Priority
+- [ ] Add `llm_bridge.rs` to Section 4.1 file list (semantic gap)
+
+### Medium Priority
+- [ ] Clarify executor module structure (`src/executor.rs` vs `src/executor/mod.rs`)
+- [ ] Add specific budget numbers to Section 8.1 recommendation
+
+### Low Priority (Optional)
+- [ ] Add TL;DR phase summary at start of Section 5
+- [ ] Consider splitting Phase 2 naming for clarity
+
+---
+
+## JSON Output
+
+```json
+{
+  "metadata": {
+    "document_path": "/home/alex/projects/terraphim/terraphim-ai-rlm/.docs/design-rig-rlm-integration.md",
+    "document_type": "phase2-design",
+    "evaluated_at": "2026-01-06T12:45:00Z",
+    "evaluator": "disciplined-quality-evaluation"
+  },
+  "dimensions": {
+    "syntactic": {
+      "score": 5,
+      "strengths": ["Consistent file paths", "Sequential step numbering", "Consistent ID schemes"],
+      "weaknesses": [],
+      "revisions": []
+    },
+    "semantic": {
+      "score": 4,
+      "strengths": ["Valid crate references", "Accurate architecture diagram", "Correct dependency graph"],
+      "weaknesses": ["Executor module structure unclear", "llm_bridge.rs missing from file list"],
+      "revisions": ["Clarify executor structure", "Add llm_bridge.rs to file list"]
+    },
+    "pragmatic": {
+      "score": 5,
+      "strengths": ["29 deployable steps", "Checkpoints per phase", "Complete test mapping"],
+      "weaknesses": [],
+      "revisions": []
+    },
+    "social": {
+      "score": 4,
+      "strengths": ["Does NOT Do column", "Complected Areas table", "Testable invariants"],
+      "weaknesses": ["Phase 2 naming vague", "Conservative budget undefined"],
+      "revisions": ["Clarify Phase 2 scope", "Add budget numbers"]
+    },
+    "physical": {
+      "score": 5,
+      "strengths": ["All 8 sections", "Consistent tables", "Good ASCII diagram"],
+      "weaknesses": [],
+      "revisions": []
+    },
+    "empirical": {
+      "score": 3,
+      "strengths": ["7 phases with checkpoints", "Tables reduce load", "Appendices separate detail"],
+      "weaknesses": ["29 steps high volume", "Dense file tables", "400+ lines"],
+      "revisions": ["Optional: Add TL;DR", "Optional: Add effort estimates"]
+    }
+  },
+  "decision": {
+    "verdict": "GO",
+    "blocking_dimensions": [],
+    "average_score": 4.33,
+    "weighted_average": 4.43,
+    "minimum_threshold": 3.0,
+    "average_threshold": 3.5
+  },
+  "revision_checklist": [
+    {"priority": "high", "action": "Add llm_bridge.rs to Section 4.1 file list", "dimension": "semantic"},
+    {"priority": "medium", "action": "Clarify executor module structure", "dimension": "semantic"},
+    {"priority": "medium", "action": "Add specific budget numbers to Section 8.1", "dimension": "social"},
+    {"priority": "low", "action": "Add TL;DR phase summary", "dimension": "empirical"}
+  ]
+}
+```
+
+---
+
+## Next Steps
+
+**GO**: Document approved for Phase 3 (Implementation).
+
+**Recommended Actions Before Implementation:**
+1. Address HIGH priority revision: Add `llm_bridge.rs` to file list (~1 min)
+2. Optionally address MEDIUM priority revisions for implementer clarity
+
+**Proceed with:** `disciplined-implementation` skill using this design document.
+
+**Implementation can begin immediately** - the document provides sufficient detail for a competent developer to start Phase 1 (Foundation) steps 1-4.
+
+---
+
+## Summary
+
+This is an **excellent Phase 2 design document** that demonstrates:
+- Comprehensive file-level planning (29 files across 3 crates)
+- Clear implementation sequencing with 7 phases and checkpoints
+- Strong traceability between acceptance criteria and tests
+- Thoughtful risk mitigation with explicit residual risk acknowledgment
+
+The document exceeds the quality threshold and is ready for implementation. Minor revisions are recommended but not blocking.