Driver and real language packages (Python, Go, Dart), then OCR and PDF rendering in Rust #313

Tracking issue for the plan in docs/research/driver-and-language-packages.md, revised on 2026-10-17 for the move to MonoSmith and the ten languages it builds.

Today the Python package runs the CLI once per call and needs Node on the PATH. The plan keeps the engine in TypeScript, puts a driver in front of it, ships the driver as a bundled per-platform runtime (the Playwright model), and gives each language a real package over one generated schema and one conformance suite. The measured hot spots move to Rust behind the contracts that already exist. The repository moves from mnci to MonoSmith first, and MonoSmith is improved as gaps are found (issues filed there: monosmith-app/monosmith#248 to #254).

• Phase M: moved to MonoSmith in chore: move the workspace from mnci (Nx) to MonoSmith #316 (smith 1.10.0). Builds, tasks and release tags continue; CI, the devcontainer and lint are smith's. Docker stays off until docker: make the registry and whether to push a setting of the convention monosmith-app/monosmith#285; workarounds for monosmith fix(studio): changing the source leaves stale data; add a way to clean up, and no restart needed #290 and perf(studio): a sample run streams slowly into the UI (86 records take about 80 s, the same run in the CLI 5 s) #291 go when those ship
• Phase 0: timed in section 9 of the plan. The engine is not the bottleneck (27 ms for 160 records over HTTP); a browser crawl spends its time navigating and in per-extract round trips (fixable in TypeScript); a scanned page costs 2.2 s of OCR and 0.85 s of rendering, so phase 6 is justified for both
• Phase 1 (feat(driver): the engine over JSON-RPC on stdio, for clients in other languages #325, feat(driver): protocol 1.1: probe, diff, export, and client-served access #333, feat(driver): protocol 1.2: worker mode, its items served by the client #334, feat(driver-client): a thin TypeScript client, held to the conformance suite #335, feat(mcp): the run tool runs through the driver's session #336): packages/driver (JSON-RPC 2.0 over stdio), driver-protocol.schema.json, conformance fixtures, thin TypeScript client, MCP run streams through it
• Phase 2 (feat(driver): a runtime per platform, so a client needs no Node #339, feat(driver-client): download the driver runtime once, so no Node is needed #340, fix(driver): the runtime's driver reports its release version #341; a hand-written matrix workflow instead of MonoSmith's native job): the driver app tagged native (MonoSmith fix(ci): read npm 12's pack --json object when staging apps #254), per-platform archives on a release, download-and-cache with hash check, OPENCRAW_DRIVER and OPENCRAW_DRIVER_OFFLINE
• Phase 3 (refactor(opencraw-python): lay the Python package out in slices #342, feat(opencraw-python): the engine through its driver, with no Node needed #343, feat(opencraw-python): an asyncio twin of the crawler, with async def hooks #347, feat(opencraw-python): the protocol's models, generated from its schema #348; opencraw 0.2.0 on PyPI): Python client, the reference for the others (Crawler, streamed records and events, hooks / solvers / access plugins as functions, worker mode)
• Phase 4: Go, Dart (desktop and server only), C#, Rust, Ruby, Java (GitHub Packages Maven), PHP (split-repo mirror for Packagist), C++ (tag only)
• MonoSmith features OpenCraw needs (both shipped in smith): a Playwright e2e toolchain plugin; a split-repo release for PHP packages
• Phase 6: @opencraw/ocr-native (napi-rs, native Tesseract) behind OcrEngine, only if phase 0 justifies it
• Phase 6: @opencraw/pdf-native (pdfium-render) behind renderPagePng, only if phase 0 justifies it

Nothing in @opencraw/core, Studio, the extension or the MCP tools changes.

🤖 Generated with Claude Code

https://claude.ai/code/session_01TjR6eM2tUwU3NGnKXsmEap