Implementation Plan

Directory Structure

reaktor-workbench/
  src/commonMain/kotlin/dev/shibasis/reaktor/workbench/
    shell/
      WorkbenchShell.kt          // Main shell: top bar, mode toolbar, panels, drawer, status
      WorkbenchMode.kt           // enum: Graph, Run, DevTools, Deploy, Insights
      WorkbenchState.kt          // ViewModel: selected entity, mode, drawer state, panel sizes
      TopBar.kt                  // Project name, branch, env indicator, search trigger
      ModeToolbar.kt             // 5-mode tab bar with keyboard shortcuts
      StatusStrip.kt             // Bottom status bar: mode label, entity count, build status
    sidebar/
      LeftSidebar.kt             // Extend existing TreePanel: mode-aware content, search
      SidebarSearch.kt           // Filter entities by name/type/module/tag
    inspector/
      InspectorPanel.kt          // Extend existing InspectorPanel with type dispatch
      InspectorState.kt          // Scroll-linked section tabs, section visibility tracking
      bodies/
        RouteInspector.kt        // Route: status, screens, trace sparkline
        ScreenInspector.kt       // Screen: render preview, crash rate, session count
        ContainerInspector.kt    // Container: child graph list, nav targets
        UiInspector.kt           // UI element: props, click chain, design overlay
        ActionInspector.kt       // Action/Interactor: signature, downstream chain
        ServiceInspector.kt      // Service: endpoints, p95, error rate
        EdgeInspector.kt         // Edge: latency histogram, deploy target, cert status
        DbInspector.kt           // DB: schema, row count, query performance
        ReleaseInspector.kt      // Release: CI pipeline, artifacts, promote CTA
    drawer/
      DrawerPanel.kt             // Bottom drawer with resize handle and tab bar
      DrawerTab.kt               // enum: Traces, Logs, Agent, Diagnostics, Commands, Queue, CodeDiff
      TraceViewer.kt             // Recent traces with timing, status, provider
      LogViewer.kt               // Filterable log stream
      AgentChat.kt               // LLM agent chat interface (Claude Code model)
      DiagnosticsPanel.kt        // Graph health, port wiring status
      CommandQueue.kt            // Pending GraphCommand list with preview
      CodeDiffViewer.kt          // Side-by-side diff preview for generated code
    screens/
      graph/
        GraphScreen.kt           // Wraps ReaktorGraphEditor + edge filter controls
        GraphModeControls.kt     // Overlay toggles, edge type filters
      run/
        RunScreen.kt             // WYSIWYG preview with device frame
        DeviceFrame.kt           // Phone/tablet/desktop frame with notch, status bar
        ComponentTree.kt         // Compose semantics tree (bidirectional selection)
        RunModeControls.kt       // Device type, theme, network mode pills
      devtools/
        DevToolsScreen.kt        // Causal trace drilldown
        TraceRail.kt             // Vertical waterfall with duration bars
        BlastRadiusPanel.kt      // Computed blast radius from graph edges
        TestImpactPanel.kt       // Test coverage for selected entity
      deploy/
        DeployScreen.kt          // Topology view + CI pipeline
        DeployTopology.kt        // Visual partition map (edge, db, kv, queue, bucket)
        CIPipeline.kt            // CI steps with status indicators
        DeployModeControls.kt    // Local/Staging/Production env switcher
      insights/
        InsightsScreen.kt        // Analytics dashboard
        InsightsTimeline.kt      // Time series chart with deploy markers
        InsightsHeatmap.kt       // Route x Metric heatmap grid
        InsightsModeControls.kt  // Time range (1h/24h/7d/30d), route filter
    search/
      CommandPalette.kt          // Cmd+K modal: entity search, command search
      SearchResult.kt            // Result item: type badge, title, source, module
    commands/
      GraphCommand.kt            // Sealed hierarchy: AddNode, ConnectPorts, SetProperty, etc.
      CommandExecutor.kt         // Apply command to graph, record in history
      CommandHistory.kt          // Undo/redo stack, persistence to SQLite
    agent/
      AgentInterface.kt          // Agent chat protocol, tool invocations
      GraphTool.kt               // Tools: read_graph, select_entity, navigate_to, etc.
      CodeGenBridge.kt           // Bridge: command batch → LLM → CodeDiff
    theme/
      WorkbenchTheme.kt          // Dark/light theme tokens matching prototype palette
      WorkbenchTypography.kt     // Font scales, mono font for code sections
  src/jvmMain/
    PlatformBridge.kt            // Desktop: file system, process launch (IntelliJ/VSCode)
  src/jsMain/
    PlatformBridge.kt            // Web: clipboard, URL routing, service worker

DeviceFrame composable

Wraps the live preview in a phone/tablet/desktop chrome frame. Purely visual — uses Compose Canvas for the notch, status bar, rounded corners. Dimensions from WorkbenchState.deviceMode:

• Phone: 312 x 624 dp, radius 36, notch
• Tablet: 500 x 700 dp, radius 24
• Desktop: 680 x 440 dp, radius 10

RunModeControls

Pill bar at top of center area: device type toggle, theme toggle (light/dark invert), network mode (online/slow/offline overlay badge).

Bidirectional Component Tree ↔ Entity Selection

When a composable is clicked in the preview, the semantics inspector identifies it → map to a graph entity via source location → update selectedEntityId. Conversely, selecting a UI entity in the graph highlights the corresponding composable in the preview.

Desktop: Full semantics inspector with CompositionData access.

Web: Compose/JS doesn't expose LocalInspectionTables. Use a Modifier.semantics-based approach: tag each composable with its graph entity ID, then use PointerInputScope hit testing.

Floating Graph Link Card

When a UI element is selected in the preview, show a floating card (like the prototype's FloatingGraphLink) with: type pill, entity name, source file, action chain strip, latest trace, and "Open in Graph" / "Follow action chain" / "Open in IDE" buttons.

TraceRail

Vertical waterfall with one card per span. Each card shows:

• Colored left border by entity type
• Type pill + entity name + source file
• Duration bar (proportional to total trace time)
• Timing text (offset from trace start)
• Click → select entity → update inspector
• Hover action buttons: "Open in Graph", "Open in IDE"

BlastRadiusPanel

Starting from selected entity, walk N hops through edges, count unique entities and modules. Show a summary card ("14 entities across 6 modules") with expandable list. Computed from the real graph via Traverser.

TestImpactPanel

Find all commands/entities that depend on the selected entity. Cross-reference with test fixtures. Show "12 tests (Maestro 4, Unit 8)" with clickable test names.

DeployTopology

Visual partition map showing all deployment targets extracted from the graph. The prototype's DEPLOY_PARTITIONS (edge, db, kv, queue, bucket) are derived from node types and deploys edge relationships.

Data source: Walk graph edges with type deploys. Group by target platform (Cloudflare Workers, D1, R2, KV, Queue). Each partition shows resource name, status indicator, endpoint URL.

Click interaction: Clicking a partition item sets selectedEntityId to the corresponding edge/db entity → inspector shows deployment-specific details.

CIPipeline

CI step visualization with status indicators (passed/running/queued/failed). Steps derived from a BuildManifest or fetched from CI API (GitHub Actions, Cloudflare Pages).

Environment switching: Local (all green) / Staging (mixed) / Production (gated promote). WorkbenchState.deployEnv controls which pipeline view is shown.

DeployModeControls

Three pill buttons: Local, Staging, Production. Plus a "Deploy" primary action button that changes label per environment.

InsightsTimeline

Time-series chart with deploy markers (vertical dashed lines). Shows request volume, error rate, or custom metric. Time range controlled by WorkbenchState.insightsRange (1h/24h/7d/30d). Rendered using Compose Canvas with polyline + filled area.

InsightsHeatmap

Route × Metric grid. Rows = routes from graph, columns = metrics (p50, p95, p99, error rate, volume). Cell color = green→yellow→red gradient. Click cell → select route entity + open inspector with performance section.

Data source: Routes from graph navigation edges. Metrics from telemetry API or mock data.

Metric Cards

Top-level summary cards: Active Users, Avg Response Time, Error Rate, Deployment Frequency. Each with sparkline and trend indicator.

Modal overlay with:

• Text input with autofocus, fuzzy matching
• Entity search — filter by title, type, module, source, tag. Results grouped by type with color badges.
• Command search — search graph commands by operation/target
• Navigation — Arrow keys to move selection, Enter to navigate, Escape to close
• Action shortcuts — ">" prefix for commands ("> deploy staging", "> add node", "> run tests")

Data source: All entities from Graph, all commands from CommandHistory. Fuzzy match using Levenshtein or prefix matching.

The drawer's "Agent" tab hosts a Claude Code-style chat interface. The agent has access to the full graph via ReaktorGraphDocument and can:

• Read the graph: read_graph() returns the JSON document of all entities, edges, ports
• Select entities: select_entity(id) navigates to an entity
• Navigate modes: navigate_to(mode, entityId) switches screen + selection
• Create commands: push_command(cmd) adds to the command queue
• Generate code: generate_code(commands[]) sends batch to LLM for CodeDiff
• Open in IDE: open_in_ide(filePath, line) launches IntelliJ/VS Code
• Query telemetry: query_metrics(entityId, timeRange) fetches performance data

This mirrors the web prototype's "Ask Code Agent" button but with real tool invocations against the graph runtime.

Context Assembly

When the user triggers "Apply" on a command batch:

1. Serialize the command batch as JSON
2. Include ReaktorGraphDocument (full graph context)
3. Include relevant source files (from entity source metadata)
4. Send to Claude API with system prompt describing Reaktor's conventions
5. Receive CodeDiff (unified diff format per file)
6. Show in CodeDiff viewer tab for user review
7. On approval, write diffs to project via file system (Desktop) or send to IDE plugin (Web)

IDE Bridge

Desktop: Use ProcessBuilder to invoke idea / code CLI for "Open in IDE". Write files directly to project directory.

Web: Communicate with IDE via:

• VS Code: vscode:// URI scheme for file open
• IntelliJ: jetbrains:// URI scheme for file open
• Plugin: HTTP localhost server in IDE plugin for bidirectional communication

reaktorWeb-compose target

• Entry point: fun main() = CanvasBasedWindow { WorkbenchShell(state) }
• Hosting: Cloudflare Workers (same as current prototype) or CDN static
• Service Worker: Offline support, caching of graph manifest and static assets
• URL routing: window.location.hash maps to WorkbenchMode + selected entity
• IDE bridge: vscode:// and jetbrains:// URI schemes for "Open in IDE"

Risk: Compose Multiplatform for Web (Kotlin/JS + canvas) is less mature than Desktop. Some composables may need platform-specific adjustments.

Mitigation: Build everything in commonMain. Keep expect/actual declarations minimal (file I/O, process launch, clipboard). Test on Web early in P1 to surface issues before heavy development.

Fallback: If Compose/JS canvas performance is insufficient for the full workbench, the current React prototype can serve as the web target while the Desktop app uses Compose. The agent/command/graph model remains shared via reaktor-graph → JSON → web frontend.

The biggest upgrade from the web prototype is that every data point is live. The prototype uses 38 hardcoded entities and 39 hardcoded edges. The Compose workbench reads the real Graph runtime:

• Entities & edges from live Graph instance (not mock data)
• Port invocation events from running app (not hardcoded traces)
• Lifecycle state from real node lifecycle (not fake status badges)
• Navigation from actual backstack (not display-only arrows)
• autoWire results from real DI resolution (not hardcoded connections)

The web prototype was a specification. The Compose workbench is the real thing.