Builder & Tangle

The Builder is where you spend most of your time. The graph is the main canvas, the Code panel toggles in from the left via a Code button in the toolbar, and you can work in either view. Any edit you make in the graph updates the text, any edit you make in the text re-parses and updates the graph. Same project, two windows.

Tangle is the AI builder that writes Weft for you in plain language. It is a cloud feature: on WeaveMind Cloud it is injected into the Builder page as a sidebar. On OSS self-hosted installs, Tangle is not included, so you write Weft by hand or copy Tangle-generated code from a cloud session into your local instance. The rest of this page describes the Builder features that are available in both OSS and cloud; the Tangle-specific sections are flagged.

Why two views

Graph-only languages turn into spaghetti at scale. Click-and-drag to wire 50 nodes is slow, and you cannot grep a graph. Code-only tools hide the architecture behind scrollbars, and AI builders waste tokens generating the same plumbing over and over.

Weft does both. The code is the source of truth. It is dense, readable, diffable, version-controllable. The graph is derived from the code and always in sync. You look at the graph to understand the shape of a system. You look at the code to change it.

Any edit in one view applies instantly to the other. Drag a node in the graph, the code updates. Change a port type in the code, the graph redraws. There is no "export to graph" step, because there is nothing to export. The graph IS the code.

How Tangle writes Weft (cloud only)

This section covers Tangle, which is only available on WeaveMind Cloud. The rest of the Builder features below work in both OSS and cloud.

Tangle knows the Weft language, the node catalog, and the design principles. When you ask it to build something, it picks nodes, writes typed connections, and hands the result back as a Weft block the dashboard parses and applies to your project.

A few things make Tangle fast where most AI coding tools are slow:

• The language enforces good patterns. The compiler catches wrong architecture at build time, so the AI cannot silently ship a bug that would only surface in production. Typing errors surface immediately in the editor, and Tangle can read them and fix on the next turn.
• Dense syntax. Weft is designed to be written by AI, so every character counts. Tangle spends its tokens on logic, not plumbing.
• Node shopping. Tangle does not carry the full node catalog in its context. It knows the base nodes and searches for the rest on demand, which keeps each turn focused.
• SEARCH/REPLACE patches. On edits, Tangle sends targeted diffs inside weft-patch blocks instead of rewriting the file, so your formatting and comments are preserved and the turn stays cheap.

Workflow

The typical loop looks like this:

1. Create or open a project. Add nodes from the palette (Ctrl+P) or write them directly in the Code panel.
2. Wire the nodes together, either by dragging from output ports to input ports in the graph, or by writing connection lines in the code.
3. Click around in the graph to see the architecture. Open individual nodes to edit their config.
4. Click Run. The project executes. Node outputs appear inline on each node in the graph and go into the Executions history.
5. If something is wrong, read the error on the failing node, fix the code, run again. Past executions stay around for comparison.
6. When it works, deploy a public page so non-technical users can run it too, or add a cron or API trigger so it runs automatically.

With Tangle (cloud only), steps 1 to 3 collapse into "ask Tangle to build it", and step 5 is "tell Tangle what is wrong" instead of fixing by hand.

Big projects get built top-down: you define the high-level groups and their interfaces first, mock them with test configs, then fill each group in separately. The compiler checks that the pieces still fit together as you go.

The code panel

The toolbar has a Code button that toggles a Weft code editor side panel. It is CodeMirror with Weft syntax highlighting and the usual shortcuts (multi-cursor, find, replace, undo). The editor re-parses after a short debounce (about half a second) and patches the graph accordingly. Parse errors show up inline; the last-good parse stays live while you are mid-edit.

Saving is automatic. After the re-parse, the project is persisted to the backend. There is no save button, no explicit commit step. You can close the tab mid-edit and come back; your latest saved state is still there.

The graph view

The graph view shows every node as a box with its input ports on the left and output ports on the right. Edges carry data from outputs to inputs. The layout is computed automatically (ELK), so you do not manually position nodes.

Things you can do in the graph:

• Click a node to select it. Expand a node (via the expand arrow on the node header, or by resizing it) to see its inline config form with editable fields.
• Hover a port to see its name in a tooltip.
• Drag from an output port to an input port to create an edge.
• Right-click a port to open the port context menu. From there you can toggle required/optional on inputs, set or change a port's type (including resolving MustOverride), and remove user-added custom ports.
• Click the collapse arrow on a group to collapse it to a single node showing its interface. Click again to expand.
• Press Ctrl+P to open the command palette and add any node from the catalog.
• Right-click the canvas to get a context menu with quick add, undo, redo, and other common actions.

Every structural action in the graph has an equivalent in the code panel. They are not two tools, they are two windows on the same thing.