prod-code v0.2.0

Second release: every language, a real cluster, and the agent tools that make prod-code more
than a fast LSP. Since v0.1.0:

• Cluster (Phase 5 complete): gateways gossip every 5 s (--peers, --advertise) and every
  node knows the whole cluster; one seed address in PROD_CODE_REMOTE is enough, the client
  discovers the rest and caches it. Placement is decided by the cluster: the node that holds
  the workspace, else the quietest live node with the right engine; idle workspaces move off
  overloaded nodes. prod-code cluster shows the gossip view. The Rust engine now runs build
  scripts and expands proc macros (rust-analyzer's proc-macro server), so derives resolve.

• Failure dossier (Phase 8.2): prod-code diagnose [FILTER] and MCP code_diagnose_failure
  run the tests and explain each failure with the code at every mentioned location, the
  enclosing function and its callers, and what changed in the working tree.

• In-memory diagnostics and edit validation (Phase 7.7): prod-code diagnostics <file> and
  prod-code validate <file> (MCP code_diagnostics, code_validate_edit) report what the
  analyzer thinks of a file, or of a proposed new content, without a build and without
  writing: rust-analyzer diagnostics from the in-memory database, pull or published
  diagnostics from the managed servers. Type errors, unresolved names and hallucinated APIs
  are caught in well under a second on every language.

• Dead-code scan (Phase 8.6): prod-code dead-code and MCP code_dead_code list unreferenced
  functions, methods and types found through the analyzer, skipping tests and entry points and
  bucketing exported symbols and trait/interface methods separately. Batch features (impact,
  dead-code) run on one persistent gateway session instead of a connection per query.

• Rust document symbols carry their enclosing items (containerName: tests, impl Shape for Circle).

• The Rust engine analyses cfg(test) and debug_assertions code like rust-analyzer's IDE
  defaults, so #[test] functions exist in the call graph; callers are flagged as tests by
  the analyzer. Document symbols point at the item's name and carry its full extent.

• A synced project manifest (tsconfig, package.json, pyproject, CMakeLists, Package.swift,
  go.mod, Cargo.toml, prod-code.toml ...) restarts the workspace's engines on the next session.

• Impact analysis (Phase 8.1): prod-code impact (and MCP code_impact) lists the functions
  the working-tree diff touches, the callers that reach them through the call hierarchy and
  the affected tests, and emits (or with --run executes) the command that runs only those
  tests. Rust document symbols now carry their full extent.

• Definitions outside the checkout are readable (Phase 8.3): prod-code def shows the lines
  around a definition in the standard library, a dependency cache or a system header, and
  prod-code source <path> prints any such file from the gateway host; MCP code_definition
  embeds the snippet and code_source reads the file. Only toolchain, dependency and SDK
  roots are served.

• Code actions for every language (Phase 7.2): prod-code assists | assist and MCP
  code_assists / code_assist on Go, C/C++, TypeScript, Python and Swift through LSP code
  actions, including quick fixes driven by the server's diagnostics and command-backed
  refactorings (clangd extract-to-variable).

• Monorepos (Phase 3.1): a nested project of another language gets its own engine, its own
  placement (Swift package in a Rust repo lands on a macOS node) and its own check / test
  / exec working directory; prod-code exec runs where it was typed.

• Project tooling is detected per checkout for check | lint | test: TypeScript uses the
  package manager of the lock file (bun, pnpm, yarn, npm) and the configured test runner
  (vitest, jest, bun test, mocha, or the test script) with parsed results; Python runs
  through uv run, the checkout's .venv, or the system interpreter, with pytest or unittest
  and basedpyright pointed at the venv; C/C++ builds with CMake, Meson or Make and tests with
  ctest (after a build) or meson test. Rename now reaches every referencing file on pyright
  (files are opened for the duration of the rename), clangd (CMake is configured with
  compile_commands.json before clangd starts) and sourcekit-lsp. exec never pulls back
  virtual environments, node_modules or build directories.

• All six languages verified end to end on fixtures: hover / definition / references /
  symbols / callers / callees / implementations / rename / check / lint / test; Go on gopls
  (cross-file rename included), Rust in-memory.

• Per-repository Rust analysis options in prod-code.toml ([rust] features = "all" | [..],
  no_default_features, all_targets, sysroot), with rust-analyzer-like defaults: all
  targets analysed and the standard library loaded from rust-src. Repositories that compile
  one module tree into several crates behind feature flags (BTCR's src/strategy2) need
  features = "all", otherwise those modules resolve to nothing.

• Sync ships rustc-wrapper scripts and *.sh, and the gateway keeps the executable bit, so
  cargo metadata works on a workspace whose .cargo/config.toml sets build.rustc-wrapper.
  Verified on BTCR: 109 implementations of StrategyInterface, 235 references, callers with
  call sites, where before only syntax-level queries answered.

• Call hierarchy and implementations (Phase 7.5): prod-code callers | callees | impls and MCP
  code_callers / code_callees / code_implementations for every engine (rust-analyzer
  in-memory, gopls, clangd, native TypeScript, basedpyright, sourcekit-lsp), with call sites.

• Rust document symbols report their real kinds and lines (all were Variable (line 1)).

• Second macOS node: the MacBook Pro (192.168.2.40, Xcode 15.4 with iOS simulators, live GUI
  session) runs a gateway for Swift and Xcode UI tests.

• Sync watermarks are kept per gateway node: a checkout placed on a second node (or moved by
  failover) is uploaded to it in full instead of receiving an empty delta computed against the
  first node. An empty delta is still sent, so a node whose workspace copy was pruned answers
  "fresh" and the client resyncs before the query or exec runs. Files rewritten by the client
  for rename / assists / safe-delete are no longer recorded as synced (the gateway only computed
  those edits); the next sync uploads them, so hover after rename sees the new code.

• Third Linux node ram9 (192.168.2.143, Ryzen 9 7950X) joined the cluster with all Linux
  engines; the Mac Studio (192.168.2.242) is the macOS node for Swift.

• Language engines (Phase 3.4–3.6): C/C++ (clangd), TypeScript (native TypeScript 7
  tsc --lsp, fallback typescript-language-server) and Python (basedpyright) workspaces
  get hover, definition, references and document symbols through the gateway; prod-code check | lint | test run cmake --build (configuring the build dir first), tsc --noEmit /
  eslint / npm test, basedpyright / ruff / pytest, with parsed diagnostics. Build and
  tool manifests (CMakeLists.txt, compile_commands.json, .clangd, requirements*.txt,
  pytest.ini, tox.ini, Pipfile, Bazel BUILD, project.pbxproj, ...) are now synced.
  Swift (Phase 3.7) runs on a macOS gateway node (sourcekit-lsp from Xcode): hover,
  definition, references, symbols, swift build diagnostics and swift test results (XCTest
  and swift-testing parsed). cpp test parses ctest output. Diagnostic paths are relative to
  the checkout instead of the server copy.

• Engine-aware placement (Phase 5.1): gateway status lists the engines whose language
  server is actually installed on the host; the client places a checkout only on a node that
  serves its engine, re-places a remembered node that no longer fits, and prod-code cluster
  shows each node's engines.

• MCP tools open files with the languageId of their extension (was always rust); LSP symbol
  kinds are named correctly in outlines.

• Session churn stress (Phase 5.5): divergent-bench --persistent --churn N kills N% of
  sessions mid-run without a goodbye and verifies the gateway retires them all.

• prod-code check | lint | test --json print the full structured report.

• Safe delete (Phase 7.1.1): prod-code safe-delete <file> <line> <col> and MCP
  code_safe_delete remove an item only when rust-analyzer finds no references to it in the
  workspace; otherwise the usages that block the deletion are listed.

• Load-aware placement (Phase 5.3 first step): gateways report host load and CPU count in
  their status; the first placement of a checkout picks the quietest alive node.

• Multi-gateway placement (Phase 5.1, client side): --remote / PROD_CODE_REMOTE take a
  comma-separated node list; a checkout is placed by rendezvous hashing, remembered locally,
  and fails over to the next alive node. prod-code cluster shows node status and placement.

• Code actions (Phase 7.1): prod-code assists <file> <line> <col> [--to LINE:COL] lists the
  rust-analyzer assists at a position or selection, prod-code assist … <id> [--subtype N]
  applies one; MCP tools code_assists / code_assist. Inline, extract function/variable/
  constant, promote to const, add explicit type, generate and rewrite assists and quick fixes
  all go through the same WorkspaceEdit path as rename.

• Typed remote verification (Phase 6.4): prod-code check, prod-code lint,
  prod-code test [FILTER] and MCP tools code_check, code_lint, code_test. The command
  runs on the gateway and the client parses the output into structured diagnostics
  (error: [E0308] ... (src/lib.rs:12:5)), pass/fail counts and per-failure output for Rust
  (cargo JSON, rustc text, libtest) and Go (go build/go vet lines, go test -json).

• Semantic rename (Phase 7.1.1): prod-code rename <file> <line> <col> <new_name>, MCP tool
  code_rename, and LSP textDocument/rename on the gateway. rust-analyzer computes the
  workspace-wide edit (including module file renames); the client applies it to the checkout
  and records the rewritten files in the sync watermark. Refused renames (no symbol, conflicts)
  are reported as errors instead of empty results.

Binaries

• prod-code-*-linux-gnu / prod-code-server-*-linux-gnu — client and gateway for x86_64 and aarch64 Linux
• prod-code-aarch64-apple-darwin / prod-code-server-aarch64-apple-darwin — client and gateway for Apple Silicon macOS (the gateway is the macOS node for Swift)

Install the client on PATH, point PROD_CODE_REMOTE at any gateway of the cluster, and register prod-code mcp as an MCP server for your agent.