Watched Variables

Live values of variables being observed by Claude Code.

Claude Code Pairing

Bridges a lopecode notebook to Claude Code via WebSocket.

Claude Code CLI  ←MCP→  Channel Server  ←WS→  This Module (browser)

Cell groups (in dependency order):

1. UI — cc_chat (main interface), cc_watch_table (variable inspector)
2. State — cc_config, cc_notebook_id, cc_activity, cc_status, cc_messages, cc_watches, cc_module, voiceEnabled
3. Module lookup — cc_find_module resolves module names via runtime.mains
4. Serialization — cc_serialize_value (safe value→string for transport)
5. Variable watcher — cc_watchers observes variables, debounces & sends updates
6. Command handlers — cc_handle_* (one per MCP tool)
7. Command dispatch — cc_command_handlers routes action→handler
8. WebSocket — cc_ws manages connect/pair/auto-reconnect and message dispatch
9. Side effects — cc_change_forwarder streams cell edits, cc_voice optional speech I/O
10. Imports — currentModules, exportToHTML, compile, history, runtime-sdk helpers

State cells

Reactive Inputs.input() cells holding connection state. These are the shared mutable atoms that UI and WebSocket cells read/write.

Module lookup & serialization

cc_find_module resolves a module name (e.g. "@tomlarkworthy/exporter-3") to a runtime Module object by polling viewof currentModules.value at call time (not reactively). cc_serialize_value safely converts any runtime value to a truncated string for transport.

Variable watcher

Subscribes to Observable variables via observe(), debounces updates (1s), and forwards changes to Claude Code over the WebSocket. Also maintains the cc_watches table UI.

Command handlers

One handler per MCP tool. Each receives a cmd object and the Observable runtime, returns {ok, result} or {ok:false, error}. Handlers: get-variable, define-variable, define-cell, delete-variable, list-variables, list-cells, run-tests, create-module, delete-module, eval, fork, watch, unwatch.

Command dispatch & WebSocket

cc_command_handlers maps action strings to handler functions. cc_ws manages the WebSocket lifecycle: connect, pair with token, dispatch incoming messages (commands, replies, tool-activity), and auto-reconnect from the URL hash cc= param or sessionStorage.

Side effects

cc_change_forwarder polls the local-change-history and streams new cell edits to Claude Code. cc_voice provides optional speech recognition input and TTS output for hands-free pairing.

Exporter 3

video explainer for exporter 2

Serialize literate computational notebooks with their dependancies into single downloadable files. Double click to open locally. No server required, works in a file:// context for simplicity.

• File-first representation. The Observable Runtime and common builtins like Inputs, htl, highlight, _ (lodash) and markdown are bundled for offline operation.
• Recursive and self-sustaining, the exporter is implemented in userspace and can be forked again after exporting.
• Fast, single file notebooks open fast!
• Moldable, the file format is uncompressed, readable, editable with a text editor, and diffable by Git.
• Runtime-as-the-source-of-truth, format derived from the live Obervable Runtime representation.
• No sandboxing, the notebook is rendered without an iframe
• Custom bootloaders, for control over the standard library
• Userspace, implementation is a normal notebook.

Exporter improves upon exporter 2 by refactoring out Observable Javascript concepts, it works on the low level reprentation directly.

Usage Guide

To put the exporter in one of your notebooks, first import the UI builder.

import {exporter, forkAnchor, exportAnchor } from '@tomlarkworthy/exporter'

Then call the builder to make the UI. You don't need to pass any options, but the options is where you can customise the output format.

exporter({
  handler: (action, state) => {}, // Optional UI click handler
  style: undefined,// customer reference to a style DOM node or a string to insert as a style block
  output: (out) => {}, // hook to get result of exporting
  notebook_url: undefined,// hardcode the default notebook_url
})

If you want to export without a UI, use the function exportToHTML, see the example

import {exportToHTML } from '@tomlarkworthy/exporter'

async function exportToHTML({
  mains = new Map(), // (name -> module) Map of main modules
  runtime = _runtime,
  options = {} // Object, export options, e.g. head, title
} = {})

You can also just use inline anchor tags: forkAnchor() or downloadAnchor()

Lopecode HTML Format Specification

Inline http responses

The HTML file contains <script> blocks that hold content to serve internal network requests locally.

<script id="d/c2dae147641e012a@46" 
        type="text/plain"
        data-encoding="base64+gzip"
        data-mime="application/javascript"
>
...inline text or base64 string
</script>

Requests to the URL matching the id are served locally, this includes import, fetch, XMLHttpRequest and <script> src attribute.

Main script

The main script loads the Observable runtime with no standard library and loads a bootloader module. The bootloader is responsible for setting up the standard library and loading the first real modules, which it discovers by reading the bootconf.json. @tomlarkworthy/bootloader is the default which comes with d3, Plot, md, htl and lodash local.

Persisted Hash URL

To help carry state across an export, the URL hash parameter is remembered in the bootconf.json and set automatically when opening the file if one is not present. URLs are limited in size, ff you need to move large amount of data across an export, use a local FileAttachment instead.

Themes

Themes are sourced from NotebookKit. A theme is fetched once from Github once when switching themes, but integrated into the export, and reused locally on subsequent exports. This keeps the bundle small, and you only need a network connection if switching to obtain the new CSS source files.

exportModuleJS

Serialize a single module from the live runtime to a .js module source string. Unlike module_specs (which serializes all modules as part of the full HTML export pipeline), exportModuleJS works on-demand against the live runtime with no task dependency.

import {exportModuleJS} from "@tomlarkworthy/exporter-3"

const {source, fileAttachments} = await exportModuleJS(moduleId, {runtime, moduleNamesFn})

Parameters

• moduleId — module name string, e.g. "@tomlarkworthy/flow-queue"
• options.runtime — Observable runtime instance (default: _runtime)
• options.moduleNamesFn — function to build module name map (default: buildModuleNames)

Returns {source, fileAttachments}

• source — full .js module source with export default function define(runtime, observer)
• fileAttachments — Map<name, {url, mimeType}> of the module's file attachments

Figures out the import structure of a runtime, just pass a runtime to the function moduleMap to get a summary of the modules. Returns a map indexed by a Module object to a record.

module -> {
  type: "notebook import" | "module variable",
  name: <module name>,
  module: <module object ref>
  dependsOn: [<module name>*],
  dependedBy: [<module name>*],
}