text-to-cad

Upgrade to cadgen 0.7.15 or newer; the defective tessellation was fixed in that release:

pip install -U cadgen==0.7.15

Then rerun the export:

cadgen stl build teacup.step teacup-export.stl --json

You do not need to clear the cache: meshes created by 0.7.14 are rebuilt automatically because the tessellation version changed. If you use cadgen through the text-to-cad agent/CAD server, update that installation so its CAD server and skills pin cadgen 0.7.15.

Affected versions include 0.7.9 and 0.7.14; tightening --mesh-tolerance or --mesh-angular-tolerance does not reliably fix the issue. As a temporary workaround on older versions, export the same valid STEP directly through build123d/OCCT:

import build123d as bd
part = bd.import_step("teacup.step")
bd.export_stl(part, "teacup-occt.stl", tolerance=0.0004, angular_tolerance=0.15)

Verify the resulting STL has 0 duplicate triangles, 0 boundary edges, and 0 edges shared by more than two faces.

Upgrade to cadgen 0.7.3 or newer, which fixes duplicate and zero-area triangles around holes in curved faces:

pip install --upgrade cadgen==0.7.3

Re-export the affected STL. The new tessellation cache version forces a fresh mesh, while cached CAD geometry can be retained. Verify it with dfam-check or Bambu Studio; the mesh should report watertight: true/manifold = yes and have a valid volume.

On cadgen 0.6.6 or older, a temporary workaround is to export the same shape with OpenCascade's mesher using build123d.export_stl, which produces a defect-free STL.

This happens on Windows 11 because Smart App Control blocks the unsigned native OCP.cp312-win_amd64.pyd shipped in the cadquery-ocp/cadquery-ocp-novtk 7.9.3.1.1 Windows wheels. Confirm it in Event Viewer under Applications and Services Logs > Microsoft > Windows > CodeIntegrity > Operational; look for Event ID 3077. SAC provides no per-file or per-application exception.

Workarounds:
1. Recommended: run the CAD workflow under WSL2, where SAC does not apply. Install WSL with wsl --install, recreate your Linux virtual environment, run pip install -r skills/cad/requirements.txt, and use cadgen/build123d there.
2. If you accept the security trade-off, disable SAC: Windows Security → App & browser control → Smart App Control settings → Off, then restart Windows. Re-enabling it later requires a reset/reinstall.
3. Testing-only alternative: set SAC to Evaluation mode by running, as Administrator, reg add HKLM\SYSTEM\CurrentControlSet\Control\CI\Policy /v VerifiedAndReputablePolicyState /t REG_DWORD /d 2 /f, then restart. This is documented for testing and effectively removes enforcement.

Upgrade to cadgen 0.6.2 or newer; cadgen doctor and the CLI failure report explicitly detect this ImportError and point to SAC/Event ID 3077. A permanent Windows-native fix requires Authenticode signing of the upstream cadquery-ocp wheels.

This is a closure-digest race in cadgen 0.7.11–0.7.15. Each STEP output is temporarily built in a hidden directory beside its final output, such as .<part>-xxxxxxxx. When another model lists that folder with os.listdir(), a glob, or a registry scan, the temporary directory name is hashed into its closure. When the sibling build finishes and deletes its staging directory, the listing changes, so the model is immediately marked STALE (closure changed: ./; changed during the build).

Fix by upgrading to a cadgen release containing PRs #575 and #578, or install from main where both are merged:

python -m pip install -U cadgen

#575 excludes cadgen's own STEP staging folders and temporary files from folder listing digests. #578 excludes a model's own declared outputs, so a model reads current after its first build. After upgrading, run one rebuild to refresh existing records:

cadgen gen

If you cannot upgrade immediately, rerunning cadgen gen is the workaround: the affected models rebuild with the same bytes and usually settle. A source-level workaround is to use a cadgen-owned staging prefix in cadgen/_internal/generation.py, for example .cadgen-stage-<name>-, and skip those cadgen transient entries in cadgen/store/closure.py when computing _listing_digest.

Note: siblings can still become stale once after the very first build into an empty folder. This is intentional because a model may list the folder to discover newly published sibling outputs; another build resolves it.

This timeout can occur in CAD 0.7.15 on Windows when a DXF contains thousands of TEXT or MTEXT entities. Text is rendered as outlines, creating a very large payload that exceeds the viewer’s 10-second limit; the first DXF opened after installation can be especially slow.

Temporary workaround: wait about a minute and click Retry. The second request may reuse the existing render and succeed.

Permanent fix: update to the release containing fix #579. In that release, drawing text is sent as text instead of outlines, and the viewer no longer times out while a drawing is still arriving. A 6,000-text test drawing dropped from 150 MB to 1.5 MB and opened in about 2.5 seconds. If the file still fails after updating, report the issue with the DXF file size.