Research-to-Code Pipeline Orchestrator

Purpose

Coordinate the complete research workflow, ensuring each stage builds on previous results and maintains consistency.

Pipeline Stages

Stage 1: Problem Definition

Skills: problem_specification Output: Formal spec with types, constraints, invariants Checkpoint: Spec reviewed and approved

Stage 2: Theoretical Analysis

Skills: algorithmic_analysis, comparative_complexity Output: Complexity analysis, design comparison table Checkpoint: Theory sound, alternatives evaluated

Stage 2.5: Optimization Loop (Optional)

Skills: iterative_optimizer Output: Improved algorithm or confirmation of optimality Checkpoint: User satisfied or proven optimal Mode: User-enabled via "aggressive optimization" or "can we do better?" Loop: Repeats Stage 2 with challenges until user stops

Stage 3: Design Selection

Skills: systems_design_patterns, microarchitectural_modeling, language_comparative_runtime Output: Design decision with justification Checkpoint: Design choice documented and justified

Stage 4: Implementation

Skills: multi_language_codegen, safety_invariants Output: Working code in Java, C++, Rust Checkpoint: Code compiles, passes basic tests

Stage 5: Testing

Skills: unit_test_generation Output: Comprehensive test suites Checkpoint: All tests pass, coverage ≥90%

Stage 6: Benchmarking

Skills: test_data_design (FIRST), benchmark_design, performance_interpretation Output: Test data catalog, performance measurements, and analysis Checkpoint: Comprehensive test data covers edge cases; results match theoretical predictions (within ±20%)

Stage 7: Reporting

Skills: reporting_visualization, technical_exposition, pedagogical_reflection, temporal_style_adapter Output: Complete technical report Checkpoint: Document ready for review

Stage 8: Consistency Check

Skills: self_consistency_checker Output: Verification report Checkpoint: No contradictions detected

Orchestration Logic

Sequential Dependencies

problem_specification
    ↓
algorithmic_analysis + comparative_complexity
    ↓
[OPTIONAL LOOP: iterative_optimizer]
    ↓ (if improvements found)
    ↑ (re-run analysis with new approach)
    ↓ (user stops or proven optimal)
systems_design_patterns + microarchitectural_modeling
    ↓
multi_language_codegen + safety_invariants
    ↓
unit_test_generation
    ↓
benchmark_design → performance_interpretation
    ↓
reporting_visualization + technical_exposition
    ↓
pedagogical_reflection
    ↓
self_consistency_checker

Feedback Loops

• Optimization loop (Stage 2.5): iterative_optimizer challenges solution → re-run Stage 2 with improvements
• Benchmarks contradict theory: Revisit analysis or modeling
• Tests fail: Revisit implementation or specification
• Consistency check fails: Revisit affected stages

Execution Strategy

Automatic Mode

1. Execute stages sequentially
2. Use skill_context_cache to pass results forward
3. Halt on checkpoint failures
4. Generate final report automatically
5. Optimization loop disabled by default (enables on "aggressive optimization" keyword)

Interactive Mode

1. Execute stage, present results
2. User approves or requests revision
3. Continue to next stage
4. User can jump back to any stage
5. Optimization loop: After Stage 2, ask "Optimize further or continue?" If optimize → Stage 2.5

Aggressive Optimization Mode

1. After Stage 2, automatically activate iterative_optimizer
2. Challenge current solution with 3-5 improvements
3. User selects challenge or stops
4. If challenge selected: re-run Stage 2 with new approach
5. Loop until user satisfied or proven optimal
6. Trigger: User says "aggressive optimization", "find optimal", "can we do better?"

Parallel Opportunities

• Implement Java, C++, Rust in parallel (after design)
• Run benchmarks in parallel (after all implementations)
• Generate sections of report in parallel (after benchmarks)

Context Handoff

Use skill_context_cache to pass:

• Spec → Analysis: Types, constraints, invariants
• Analysis → Design: Complexity, operations profile
• Design → Implementation: Data structures, algorithms
• Implementation → Testing: Code structure, edge cases
• Testing → Benchmarking: Validated implementations
• Benchmarking → Reporting: Measurements, analysis

Pipeline Invocation

Full Pipeline:

"Research optimal k-way merge, implement in all languages, benchmark, and write CS500 report"

Partial Pipeline:

"Implement heap-based merge from existing spec"
→ Starts at Stage 4

Resume Pipeline:

"Benchmarks showed unexpected results; re-analyze and update report"
→ Loops back to Stage 2, continues to Stage 7

Optimization Loop:

"Research k-way merge with aggressive optimization"
→ Runs Stage 1-2
→ Stage 2.5: "O(nk) found. Can we do better?" → Challenge with heap O(n log k)
→ Loop: User approves → re-run Stage 2 with heap
→ Stage 2.5: "O(n log k) achieved. Can we do better?" → Challenge with constants
→ Loop: User stops → Continue to Stage 3

Quality Gates

Each stage has acceptance criteria:

Error Handling

Checkpoint Failure

• Document issue
• Identify root cause
• Determine which stage to revisit
• Re-execute from that stage

Unexpected Results

• Treat as scientific finding, not error
• Investigate cause (measurement issue vs model issue)
• Update model or document limitation
• Continue pipeline

Cross-Skill Integration

Coordinates: All 19 other skills (including iterative_optimizer) Uses: skill_context_cache for state management Feeds into: Final deliverable (complete research artifact) Optional loop: iterative_optimizer challenges solutions after Stage 2