Discussion only. No implementation in this issue. Leave it open.
Why this is here
We want a way for a computational engineering model (a CEM) to sit next to VibeCAD without VibeCAD becoming that model, and without baking any one product into the app. Several CEMs are already in use. Other people will build ones we have not seen. The connection should be the same shape for all of them.
This captures a working conversation. It is not a decision.
What the current app actually does
Ribbons are the tabs across the top. The compiled list in src/Gui/VibeCADRibbon.cpp is, in order: Model, Assemble, Mesh, Analyze, Manufacture, Sheet Metal, Drawing, Parameters, Aero, 3D Print. Each tab is a FreeCAD workbench underneath. Sketch is appended while a sketch is being edited. The McMaster module inserts its own tab in Python (src/Mod/McMasterInsert/InstallUI.py); it is not one of those ten.
Clicking McMaster opens the catalog site. Import is a separate action for a STEP file already on disk. That is a catalog window, not a solver. A tab done the same way has no Native authoring surface, so the assistant reports that the ribbon has no tools.
There is no third-party ribbon hook. A tab the assistant can use has to be added in-tree: a domain row, a surface id, and every live command on the allowlist (KNOWN_ACTIONS_BY_SURFACE). New live actions fail classification until they are added there.
The assistant does not pick the ribbon. In Native mode it sees the tool families of the ribbon a person selected. An external tool does not replace those tools. It is added beside them.
Two different MCP roles
Do not mix these.
- External MCP tool servers (Preferences, VibeCAD, MCP). VibeCAD calls
mcp_<name>.<tool>. Those calls never edit the open document. This is the extension point that already exists, and it does not require a new ribbon.
- VibeCAD as the MCP server. An outside client drives VibeCAD. Turning that on stops the built-in assistant. That is not how we would attach a CEM.
Connect Grok Bot is a third wire, and it is not either of those. It starts a loopback control channel in the running process (docs/vibecad-agent-control.md). The click can say connected even when the Grok Bot app was not found. The only value saved is the app path (GrokBotCommand). The status line is drawn as not connected every time the preferences page is built. The button does not ask for a restart. After a restart the channel is gone, so the page looks like the click never happened. That is local UI automation, not a CEM connection. Tracked separately in #4. Do not design the CEM path on top of it.
What a CEM result is
A CEM and VibeCAD do not share a kernel. The result is not one kind of file, and a mesh is not the default.
A study can return any of these. None of them is the contract by itself:
- A mesh, a file of triangles. Opening it is looking at the mesh. It is not an editable feature history.
- A table, or a written brief of numbers. There is nothing to place in the model.
- A report.
- Geometry that is still a solid or a feature history a person can edit. That is a different import than a mesh, and a given study may not have it.
Mesh import today opens a file dialog and does not take a path from a tool. An STL carries no unit of its own. That unit problem belongs to the mesh case only. Assembly constraints are not a computational model. Sending geometry out to a slicer is not a CEM protocol. None of those is the connection.
Open questions
- Is the external MCP tool server the connection we want? A person can still bring a file in when the result is a file. A table or a report has no file to place.
- If placement matters, it matters only for a result VibeCAD can open. That import command would have to accept a path. That is a code change. Not in scope until this discussion says so.
- What is the smallest CEM-agnostic contract? A sketch, not a decision: what the study needs, run one study, where the result landed, plus one honesty line the study itself writes. That line says what the result is (mesh, table, report, or editable geometry), what unit it used if it has one, and what it must not be called. VibeCAD should not learn domain words. The contract does not say "mesh."
- Because an external server stacks on the current ribbon, the assistant can still be on Model while a study runs. How do we keep a result from being described as a feature the ribbon knows how to make, including when the result is not geometry at all?
- One study ribbon (list installed studies, fill a spec, run one, then open the result if it is a file) is a product idea. It is not a hook that exists. A McMaster-style tab would show buttons and give the assistant an empty tool list. Do we want that later, or not at all?
Nothing here authorizes a branch.
Discussion only. No implementation in this issue. Leave it open.
Why this is here
We want a way for a computational engineering model (a CEM) to sit next to VibeCAD without VibeCAD becoming that model, and without baking any one product into the app. Several CEMs are already in use. Other people will build ones we have not seen. The connection should be the same shape for all of them.
This captures a working conversation. It is not a decision.
What the current app actually does
Ribbons are the tabs across the top. The compiled list in
src/Gui/VibeCADRibbon.cppis, in order: Model, Assemble, Mesh, Analyze, Manufacture, Sheet Metal, Drawing, Parameters, Aero, 3D Print. Each tab is a FreeCAD workbench underneath. Sketch is appended while a sketch is being edited. The McMaster module inserts its own tab in Python (src/Mod/McMasterInsert/InstallUI.py); it is not one of those ten.Clicking McMaster opens the catalog site. Import is a separate action for a STEP file already on disk. That is a catalog window, not a solver. A tab done the same way has no Native authoring surface, so the assistant reports that the ribbon has no tools.
There is no third-party ribbon hook. A tab the assistant can use has to be added in-tree: a domain row, a surface id, and every live command on the allowlist (
KNOWN_ACTIONS_BY_SURFACE). New live actions fail classification until they are added there.The assistant does not pick the ribbon. In Native mode it sees the tool families of the ribbon a person selected. An external tool does not replace those tools. It is added beside them.
Two different MCP roles
Do not mix these.
mcp_<name>.<tool>. Those calls never edit the open document. This is the extension point that already exists, and it does not require a new ribbon.Connect Grok Bot is a third wire, and it is not either of those. It starts a loopback control channel in the running process (
docs/vibecad-agent-control.md). The click can say connected even when the Grok Bot app was not found. The only value saved is the app path (GrokBotCommand). The status line is drawn as not connected every time the preferences page is built. The button does not ask for a restart. After a restart the channel is gone, so the page looks like the click never happened. That is local UI automation, not a CEM connection. Tracked separately in #4. Do not design the CEM path on top of it.What a CEM result is
A CEM and VibeCAD do not share a kernel. The result is not one kind of file, and a mesh is not the default.
A study can return any of these. None of them is the contract by itself:
Mesh import today opens a file dialog and does not take a path from a tool. An STL carries no unit of its own. That unit problem belongs to the mesh case only. Assembly constraints are not a computational model. Sending geometry out to a slicer is not a CEM protocol. None of those is the connection.
Open questions
Nothing here authorizes a branch.