---
title: "Implementation Phases"
description: "This document maps interfaces to implementation phases to help developers focus on what's needed when."
type: skill
canonical_url: https://claudary.paisolsolutions.com/skills/implementation-phases
source: "Claudary"
difficulty: intermediate
author: "Claude Code Knowledge Pack"
date: 2026-07-10T11:25:20.399Z
license: CC-BY-4.0
attribution: "Implementation Phases — Claudary (https://claudary.paisolsolutions.com/skills/implementation-phases)"
---

# Implementation Phases
This document maps interfaces to implementation phases to help developers focus on what's needed when.

## Overview

# Implementation Phases

This document maps interfaces to implementation phases to help developers focus on what's needed when.

## Phase 1.1: Core Runtime Package (MVP)

**Goal**: Basic expression evaluation working in CLI/backend

**Interfaces Needed**:
- `RuntimeBridge` - Main bridge interface
- `BridgeConfig` (without `debug` field)
- `RuntimeHostInterface` - Runtime-to-host communication
- `RuntimeGlobals` - Globals injected into runtime
- `WorkflowDataProxy` - Data access helper
- `IExpressionEvaluator` - Public API
- `EvaluatorConfig` (without observability)
- `WorkflowData` - Input data format
- `EvaluateOptions` (basic)

**Implementations Required**:
- `IsolatedVmBridge` - For CLI/backend
- `ExpressionEvaluator` - Main evaluator class
- Runtime code (runs inside isolate, bundled via esbuild)
- Lazy loading proxies
- Expression code cache (per-evaluator, caches tournament-transformed code)

**Can Skip**:
- Observability (use `NoOpProvider` stub)
- Debug mode
- Specific error types (use generic `Error`)
- Web Workers
- Task runners

## Phase 0.2: Observability Infrastructure (PARALLEL)

**Goal**: Add metrics, traces, and logs

**Interfaces Needed**:
- `ObservabilityProvider`
- `MetricsAPI`
- `TracesAPI`
- `LogsAPI`
- `Span`

**Implementations Required**:
- `NoOpProvider` (zero overhead when disabled)
- `OpenTelemetryProvider`
- `PostHogProvider` (optional)
- `CompositeProvider` (use multiple providers)

**Integration**:
- Add to `EvaluatorConfig.observability`
- Emit metrics/traces from evaluator and bridge
- Smart sampling implementation

## Phase 1.2: Isolate Pooling

**Goal**: Handle concurrent evaluations

**New Interfaces**: None (uses existing `RuntimeBridge`)

**Implementations Required**:
- `IsolatePool` class
- Pool configuration
- Acquire/release mechanism
- Disposal detection and replacement

## Phase 1.3: Extension Framework

**Goal**: 100% test compatibility

**New Interfaces**: None

**Implementation**: Extension functions in runtime

## Phase 1.4: Error Handling

**Goal**: Graceful error handling with clear messages

**Interfaces Needed**:
- `ExpressionError`
- `MemoryLimitError`
- `TimeoutError`
- `SecurityViolationError`
- `SyntaxError`

**Implementation**: Error handling in all code paths

## Phase 2+: Future Enhancements

### Web Worker Support
**Interfaces**: Already defined (same `RuntimeBridge`)

**Implementations**:
- `WebWorkerBridge`
- Runtime bundled as ESM
- Note: No lazy loading initially (pre-fetch data)

### Chrome DevTools Debugging
**Config**: `BridgeConfig.debug` field

**Implementation**:
- Inspector protocol integration
- Debug mode in IsolatedVmBridge

### Task Runner Integration (Architecture TBD)

Task runners already have process-level isolation. Expression evaluation happens **inside the task runner** (no IPC to worker needed).

**Option A**: Use `IsolatedVmBridge` locally within task runner
- Adds another sandbox layer for extra security
- Task runner creates local evaluator instance
- No lazy loading needed (task runner has all data)

**Option B**: Evaluate directly without extra sandbox
- Reuse task runner's existing process isolation
- Simpler, potentially faster
- May be sufficient given process-level isolation

**Decision pending** - will be made during Phase 2+ implementation.

---

## Quick Start Guides

### For Frontend Developers (Web Worker Integration)

**Phase 1**: Skip - Web Workers are Phase 2+

**Phase 2**: Focus on:
1. `RuntimeBridge` interface - Your bridge must implement this
2. `BridgeConfig` - Configuration options
3. `WorkflowDataProxy` - How to structure data
4. Ignore: Observability interfaces (optional)

**Key Difference**: Web Workers can't do lazy loading initially, so you'll need to pre-fetch all data before calling `execute()`.

### For CLI/Backend Developers

**Phase 1.1**: Focus on:
1. `IsolatedVmBridge` implementation
2. `ExpressionEvaluator` class
3. Runtime code (runs inside isolate)
4. Code cache implementation

**Use**: `NoOpProvider` for observability initially

**Phase 0.2**: Add real observability providers

### For Testing

Integration tests use `IsolatedVmBridge` directly (see `src/__tests__/integration.test.ts`).

All interfaces in `src/types/` are stable enough to write against before the
bridge implementation lands.

---

Source: [Claudary](https://claudary.paisolsolutions.com/skills/implementation-phases) · https://claudary.paisolsolutions.com