One toolkit, discipline by discipline
Everything below shares one project tree, one version history and one delivery pipeline. Pick the discipline you care about — the rest is already in the same project.
Electrical
Schematics and panel layouts, with the netlist behind them
Draw the electrical design on A3 sheets and lay the same parts out in the cabinet. The netlist, wire numbers and cross-references are derived from the drawing, so tracing a circuit and colouring a net never means maintaining a second copy by hand.
A3 sheet editor
Symbol placement, 45°/Manhattan wire routing, device tags, wire numbering and cross-references, with undo/redo on every gesture.
Netlist and trace mode
Follow a net across sheets, terminals and cross-references. Nets that jump between drawings are drawn as interruption points, so the jump reads the same in the editor, the viewer and the export.
Net potentials and wire colours
Semi-automatic label heuristics with manual per-net overrides. The canvas, the read-only viewer and the PDF/ZIP export all use the same colouring.
3D cabinet layout
Arrange components on a real enclosure, check clearances before anything is mounted, and keep the cabinet thermal register alongside the design.
EPLAN import
Bring existing work across: 2D macros become editable symbols, 3D macros become GLB, and .edz part metadata lands in the parts register — then insert from the symbol catalogue.
Review without an editor
The same rendering engine powers a read-only viewer for reviewers and approvers.
PCB
Code-first boards where the source is the document
A PCB is a tscircuit TSX program compiled in the browser to circuit JSON, then rendered as a board, a schematic and a 3D assembly. Every board or schematic gesture compiles back into the source, so the code, the drawing and an agent edit always describe one program.
The source is the design
TSX compiles in a Web Worker to circuit JSON. Board and schematic gestures are written back into the source instead of living only in the session.
Board, schematic, 3D and code views
One document, four faces: layout, editable schematic, interactive 3D board and the code itself.
Parts and live stock
A parts library plus live JLCPCB stock search, so the part you place is the part you can buy.
BOM and diagnostics dock
The BOM and compiler diagnostics read the compile and stay docked beside the design instead of in a separate tool.
CAD & CFD
Parametric parts, assemblies and analysis on the same project tree
A part is a FeatureScript-compatible source document evaluated by an OCCT-in-WASM kernel. Features, gizmos and parameters all compile to source; assemblies compose parts and imported STEP; the CFD study maps that geometry to a solver package and reviews the solved result in the app.
Source is the model
FeatureScript-compatible source is canonical. The feature toolbar, gizmos and Parameters pane all compile into source blocks, so history is a diffable program.
OCCT-in-WASM kernel
The browser evaluates the source with the same kernel the review and export paths use.
Assemblies and imported parts
Compose placed parts and imported STEP instances, with a derived feature history and STEP/STL/PNG export.
Sites and terrain
Seat an assembly on a georeferenced DEM terrain so plant layouts sit on the actual site, not a plane.
CFD studies and solver dispatch
Map flow bodies and named patches, carry a vessel-scale case definition in the study, dispatch it to a containerised OpenFOAM solve, then review the result set in the CFD page.
Calculations & documents
Sizing work, reference documents and the numbers that bind them
Engineering calculations belong next to the design they size, not in a spreadsheet that drifts. Calculation sheets recalculate live, documents can reference each other by value, and PDFs from suppliers are readable as project documents.
Calculation sheets
Typed cell inputs, a formula language with live recalculation and a CSV artifact — pump duty, tank and pipe sizing, design checks.
Value bindings across documents
An @from annotation pulls a value from one project document into another without copy-paste.
PDF reference documents
Render, extract text and attachments, and open decoded U3D 3D models from supplier PDFs that live in the project tree.
Authored deliverables
A deliverable is a page type: choose its pages, order, format, purpose and print options, then run it as often as the design changes.
Engineering data
One part master feeding every drawing and BOM
Projects share one materials register: catalog parts, organisation libraries, project usage, panel BOMs and a generated rollup with documentation coverage. Vendor and EPLAN inventories are harvested into the same model instead of being retyped per project.
Project parts register
One register per project feeds the sheets, the cabinet layout, the PCB BOM and the rollup.
Panel BOM and project rollup
A BOM page per panel and a generated project rollup, with documentation coverage so missing data is visible.
Materials catalogue and libraries
Catalog → organisation library → project usage, with harvested vendor inventories and EPLAN part masters.
Cabinet thermal register
Dissipation data travels with the cabinet so a thermal review is part of the design record.
Delivery
Issue the package, not a folder of loose PDFs
Export is a designed artifact. Build a package with its contents page, manifest, scope and print options inside the project, version it with the design, and render it through the same pipeline every time.
Authored export packages
Scope by project, zone or an authored order; a contents page and manifest travel with the PDF/ZIP.
Print options and net colour
Per-package print options, including sheets coloured by net potential for the site copy.
Deterministic render pipeline
A server-side Puppeteer render pipeline produces the same output for the app, a re-run and an automated job.
Collaboration & agents
One project, many hands — people and agents on the same rules
Documents are collaborative in real time, projects are versioned like code, and work is tracked on a task board. The in-app assistant and isolated agent runs act through the same project and approval rules as a person, on their own branches.
Realtime editing
Yjs-backed editing with presence and cursors, on a project filesystem with folders and a dependency graph.
Version control for projects
Commit, branch, restore and manually merge a whole project on a content-addressed (IPLD) store — for every document, not just text files.
Task board and work inbox
Boards, comments, links and a cross-project My work inbox, so design work and delivery work share one queue.
Isolated agent runs
A run works on its own branch in an isolated workspace and never touches the live project; its result comes back as a reviewable commit.
In-app assistant with approval
Chat reads the project and proposes changes under an explicit approval policy (Suggest by default). Provider keys stay on the server.
The document model under all of it
Eight surfaces, one set of rules. A page kind declares what a document is; the project supplies filesystem, versioning, collaboration and export around it.
Where the product is today
Every subsystem documents its own status. This is the honest summary — what ships, what is in progress, and what is still a proposal.
Shipped, including EPLAN macro import.
Shipped slices with the code-first / source-is-the-model authoring.
Shipped on a single-working-tree model.
Two people cannot yet edit different branches at once; the merge target is the checked-out branch.
A Tauri shell over the same editors; offline parity is in progress.
Not decoded yet; embedded U3D models are.
Specified (power-budget diagnostics, plugin host) but not shipped.
Put a real project through it
The free plan includes every editor and one active project, so you can take a job from schematic to issued package before you decide.