Weavatrix Refactor JS

Part of the Weavatrix ecosystem. This repository preserves the explicit JavaScript refactoring line.

This is the JavaScript refactoring engine of Weavatrix, continued as weavatrix-refactor-js. The weavatrix-refactor package ships the native Rust MCP host built on weavatrix-rust and the weavatrix-edit / weavatrix-refactor-plan / weavatrix-worktree crates. This package continues that version line: weavatrix-refactor@0.1.5 was the last JavaScript release under the old name, and weavatrix-refactor-js@0.1.6 picks up from it. Install weavatrix-refactor-js, or pin weavatrix-refactor@0.1.5, to stay on the JavaScript implementation.

Evidence-backed, transactional refactoring for coding agents.

weavatrix-refactor-js is the write-capable member of the JavaScript family. It combines the complete read-only weavatrix-js code-intelligence MCP with 11 refactoring tools that can prove a change, preview it against the current working tree, apply it atomically, refresh the graph, and roll it back.

Engine boundary: this package hosts the weavatrix-js engine. It does not use the native weavatrix-rust engine, and installing both packages does not silently upgrade this one's analysis layer. Its state lives in ~/.weavatrix-refactor-js, kept separate from the Rust host's so the two never share a lock, a token store, or a rollback journal.

It is substantially more than a rename wrapper:

• semantic JS/TS rename through the bundled language server;
• SQL table and field rename with schema-aware evidence;
• strict graph-plus-lexical rename for Python, Rust, Go, Java, C#, and Solidity;
• several related JS/TS renames merged into one atomic transaction;
• signature, symbol-body, import, bulk-replace, move, and delete-safety workflows;
• byte-exact file hashes, before text, provenance, uncertainty, and graph revision in every applyable plan;
• stale-tree detection, repository locking, rollback bundles, and automatic rollback after a mid-write failure;
• architecture and cycle projection before structural moves;
• post-change blast-radius and verification tools inherited from the core.

Why this is a separate package

The MIT weavatrix-js core is physically read-only: its published artifact has no repository source-write path. This package is the explicit write boundary. Installing it and selecting its refactor profile makes the edit capability visible; without this package, the server cannot modify source.

The split is a safety property, not packaging cosmetics:

weavatrix-js core       weavatrix-refactor-js                 repository
read-only evidence  ->  plan + preview + confirmation  ->  atomic write
graph / LSP / audit     hashes / provenance / rollback     refreshed graph

Architecture

The implementation is a ports-and-adapters system with one-way boundaries:

edit-plan model  <-  filesystem / lock / token adapters
       ^                         ^
       |                         |
plan engines     ->  preview / apply / rollback workflows  ->  MCP adapter

• Model validates the frozen weavatrix.edit-plan.v1 envelope and applies byte-exact edits as pure string transformations.
• Platform adapters own real-path containment, atomic replacement, repository locks, single-use tokens, and durable rollback bundles.
• Plan engines compute rename, signature, symbol, import, move, delete, and bulk-replace evidence without owning the write workflow.
• Application workflows bind a preview to the current repository, issue and consume confirmation tokens, apply under a lock, and restore on failure.
• MCP adapter composes the 11 refactor tools with the read-only weavatrix-js catalog and exposes one stdio server.

The checked-in strict architecture contract enforces zero runtime cycles, files no longer than 300 lines, and functions no longer than 100 lines. It has no exceptions or ratchet baseline.

What makes the refactor workflow different

An ordinary editor rename answers: "Which text edits should I make now?" Weavatrix Refactor also answers:

The system fails closed when proof is insufficient. It never upgrades an INFERRED edge into an applyable edit and never hides an ambiguous reference.

The complete rename workflow

rename_symbol and rename_related_symbols are complete operations, not PLANNED-only helpers. Each method owns both phases.

1. Preview

Call the rename method normally:

{
  "symbol": "src/users.ts#getUser@12",
  "new_name": "getCustomer"
}

The method computes the rename, validates every plan file against the working tree, and returns PREVIEW_OK with a short-lived confirmToken. Preview never writes source and does not require the environment write gate.

2. Apply through the same method

Repeat the same operation inputs and add the confirmation:

{
  "symbol": "src/users.ts#getUser@12",
  "new_name": "getCustomer",
  "mode": "apply",
  "confirm_token": "<token from preview>"
}

The tool recomputes the deterministic plan, verifies that the token belongs to that plan and repository, takes the repository lock, rechecks hashes and before text, writes a rollback bundle, and applies every edit bottom-up.

The same contract applies to a coordinated set:

{
  "renames": [
    {"symbol": "src/api.ts#getUser@8", "new_name": "getCustomer"},
    {"symbol": "src/api.ts#getOrder@20", "new_name": "getPurchase"}
  ]
}

rename_related_symbols detects overlapping edits, chains, swaps, shadowing risk, and per-sub-rename failure before it issues a token. Apply is one atomic multi-file operation.

Refactoring tools

Complete write workflows

Proven plan producers

These plans are applied with apply_edit_plan, using the same preview, token, atomic-write, and rollback protocol as rename.

Structural review and safety tools