forgecad 0.10.0 → 0.10.2

package/dist/docs-raw/guides/simready-quickstart.md

@@ -0,0 +1,173 @@
+# SimReady Quickstart
+
+ForgeCAD simulation readiness starts in the model file. The `.forge.js` script should return the same assembly you want to inspect, export, and simulate; simulation metadata lives on that assembly instead of in a separate export command.
+
+Use this pattern when you want a robot, fixture, gripper, crate, or imported asset to become a physics package later:
+
+1. Build real parts with connectors.
+2. Add each part to an `assembly(...)` with `sim: Sim.body(...)`.
+3. Connect moving parts with `connect(...)` and put drive intent on the joint.
+4. Finish the root assembly with `withSimulation(...)`.
+5. Run `forgecad check simready` before exporting.
+
+## Robot Pattern
+
+```js
+const aluminum = Sim.material("6061 aluminum", {
+  densityKgM3: 2700,
+  staticFriction: 0.45,
+  dynamicFriction: 0.35,
+  restitution: 0.05,
+});
+
+const rubber = Sim.material("rubber tire", {
+  densityKgM3: 1100,
+  staticFriction: 0.9,
+  dynamicFriction: 0.75,
+  restitution: 0.12,
+});
+
+const chassis = box(220, 120, 28).withConnectors({
+  left_axle: connector({ origin: [0, 82, 0], axis: [0, 1, 0], up: [0, 0, 1], kind: "revolute" }),
+  right_axle: connector({ origin: [0, -82, 0], axis: [0, -1, 0], up: [0, 0, 1], kind: "revolute" }),
+});
+
+const wheel = cylinder(34, 28, undefined, 48)
+  .rotateX(90)
+  .withConnectors({
+    bore: connector({ origin: [0, 0, 0], axis: [0, 1, 0], up: [0, 0, 1], kind: "revolute" }),
+    tread: connector({ origin: [0, 0, -34], axis: [0, 0, -1], up: [1, 0, 0] }),
+  });
+
+return assembly("Rover")
+  .addPart("Chassis", chassis, {
+    sim: Sim.body({
+      massKg: 4.2,
+      material: aluminum,
+      collider: Sim.collider.boundingBox(),
+    }),
+  })
+  .addPart("Left Wheel", wheel, {
+    sim: Sim.body({
+      massKg: 0.32,
+      material: rubber,
+      collider: Sim.collider.convexHull(),
+      contacts: { tread: Sim.contact.wheelSurface("tread") },
+    }),
+  })
+  .addPart("Right Wheel", wheel, {
+    sim: Sim.body({
+      massKg: 0.32,
+      material: rubber,
+      collider: Sim.collider.convexHull(),
+      contacts: { tread: Sim.contact.wheelSurface("tread") },
+    }),
+  })
+  .connect("Chassis.left_axle", "Left Wheel.bore", {
+    as: "leftWheel",
+    type: "revolute",
+    drive: Sim.drive.velocity({ maxTorqueNm: 1.8, maxSpeedRpm: 220, damping: 0.02, friction: 0.01 }),
+  })
+  .connect("Chassis.right_axle", "Right Wheel.bore", {
+    as: "rightWheel",
+    type: "revolute",
+    drive: Sim.drive.velocity({ maxTorqueNm: 1.8, maxSpeedRpm: 220, damping: 0.02, friction: 0.01 }),
+  })
+  .withSimulation({
+    rootPart: "Chassis",
+    profile: Sim.profile.robotBodyRunnable(),
+    controllers: [
+      Sim.controller.diffDrive({
+        leftJoints: ["leftWheel"],
+        rightJoints: ["rightWheel"],
+        wheelRadiusMm: 34,
+        wheelSeparationMm: 164,
+      }),
+    ],
+  });
+```
+
+The important names are authored once:
+
+- `rootPart` names the body that downstream simulators treat as the robot root.
+- `leftWheel` and `rightWheel` are joint names, so controllers and exporters do not need to guess motor wiring.
+- `tread` is an existing connector on the wheel, so contact metadata is checked against geometry-owned names.
+
+## Asset Pattern
+
+Assets use the same assembly contract. In V1, a crate, prop, imported STEP, or static environment object is usually a one-part assembly:
+
+```js
+const pine = Sim.material("pine crate", {
+  densityKgM3: 520,
+  staticFriction: 0.55,
+  dynamicFriction: 0.42,
+  restitution: 0.08,
+});
+
+const crate = box(140, 110, 80).withConnectors({
+  grip: connector({ origin: [0, -56, 8], axis: [0, -1, 0], up: [0, 0, 1] }),
+});
+
+return assembly("Crate Asset")
+  .addPart("Body", crate, {
+    sim: Sim.body({
+      massKg: 2.4,
+      material: pine,
+      collider: Sim.collider.convexHull(),
+      contacts: { grip: Sim.contact.gripperSurface("grip") },
+    }),
+  })
+  .withSimulation({
+    profile: Sim.profile.roboticsAssetPhysx(),
+  });
+```
+
+Asset profiles require physical body metadata and explicit collider intent. They do not require `rootPart`, joints, or controllers.
+
+## Check Then Export
+
+Run the offline gate first:
+
+```bash
+node dist-cli/forgecad.js check simready examples/robotics/simready-diff-drive-rover.forge.js
+```
+
+Then export the package that matches your simulator:
+
+```bash
+node dist-cli/forgecad.js export mjcf examples/robotics/simready-diff-drive-rover.forge.js --output /tmp/rover-mjcf
+node dist-cli/forgecad.js export sdf examples/robotics/simready-diff-drive-rover.forge.js --output /tmp/rover-sdf
+node dist-cli/forgecad.js export urdf examples/robotics/simready-diff-drive-rover.forge.js --output /tmp/rover-urdf
+node dist-cli/forgecad.js export usd examples/robotics/simready-diff-drive-rover.forge.js --output /tmp/rover-usd
+```
+
+Use MJCF/MuJoCo for the fastest local physics loop. Use SDF for Gazebo Sim. Use URDF when the next tool expects a ROS/PyBullet/Isaac import path.
+Use USD for native Isaac Sim/OpenUSD handoff: the package contains a text `.usda` stage with USD Physics bodies, colliders, mass, joints, velocity drives, a `PhysicsScene`, and package-local validation script.
+
+For Isaac workflows, prefer `export usd` when you want to avoid importer heuristics and preserve authored physics metadata directly in USD. Use URDF only when a downstream tool specifically expects URDF or when you need an importer-managed conversion step.
+
+Every package includes `simready-manifest.json`. That manifest is the neutral handoff: model name, units, profile, bodies, joints, drives, controllers, contacts, and validation results.
+
+## What The Check Catches
+
+`forgecad check simready` is source-level validation. It does not need Isaac Sim, OpenUSD, `pxr`, MuJoCo, or NVIDIA validators installed.
+
+It fails when:
+
+- the returned model has no `withSimulation(...)` contract
+- a physical part is missing `Sim.body(...)`
+- mass, density, friction, restitution, torque, speed, damping, or world pose values are non-finite or invalid
+- a collider is missing for profiles that require explicit collision intent
+- `Sim.collider.none(...)` has no reason
+- a contact surface names a missing connector
+- a controller names an unknown or wrong-type joint
+- a robot profile has no `rootPart`, an unknown `rootPart`, or a disconnected joint graph
+
+It intentionally treats joint-connected bodies as connected. A robot with separated wheels, arms, or gripper fingers should pass when the articulated graph is valid.
+
+## Where Control Code Lives
+
+ForgeCAD owns geometry, physical metadata, joints, drives, controllers, manifests, and starter simulator packages. It should not own a single blessed balance controller, reward function, or RL library.
+
+For a runnable training loop, export MJCF and use the generated package scripts. The Scout Cam Rover example includes `gym_env.py`, `train_balance.py`, `train_sb3.py`, `play_balance.py`, and `live_policy_viewer.py`; see [Simulation Workflow](../simulation-workflow.md) for the full MuJoCo and Isaac Lab path.

package/dist/docs-raw/simulation-workflow.md

@@ -0,0 +1,273 @@
+# Simulation Workflow
+
+ForgeCAD should make a robot or simulated asset runnable without making the CAD API own the control algorithm.
+
+The source `.forge.js` model owns geometry, assembly structure, physical metadata, joints, drive intent, contact hints, and the neutral simulation contract. Exported packages then generate an editable simulator lab with all names and wiring connected. Rewards, policies, perturbation tests, curriculum, and RL libraries stay in simulator-side code.
+
+## Current Path: ForgeCAD To MuJoCo
+
+1. Source-author the model as an assembly with `withSimulation(...)`.
+2. Put physical metadata on every part with `Sim.body(...)`.
+3. Put motor intent on joints with `Sim.drive.velocity(...)` or passive dynamics with `Sim.drive.passive(...)`.
+4. Add high-level controller metadata such as `Sim.controller.diffDrive(...)` when the assembly has a standard command interface.
+5. Run the offline gate:
+
+```bash
+node dist-cli/forgecad.js check simready examples/robotics/scout-cam-rover-simready/main.forge.js
+```
+
+6. Export the MuJoCo package:
+
+```bash
+node dist-cli/forgecad.js export mjcf examples/robotics/scout-cam-rover-simready/main.forge.js --output /tmp/scout-cam-rover-mjcf
+```
+
+The generated package contains:
+
+- `scene.xml`: a runnable MuJoCo scene with floor, light, and render settings.
+- `manifest.json`: ForgeCAD-to-MJCF names for links, joints, actuators, generated scripts, and suggested commands.
+- `simready-manifest.json`: neutral simulation contract and validation results.
+- `scripts/gym_env.py`: Gymnasium-compatible MuJoCo env helpers.
+- `scripts/policy_runtime.py`: shared policy loader for ForgeCAD JSON and Stable-Baselines3 zip policies.
+- `scripts/smoke_control.py`: basic actuator smoke test and GIF renderer.
+- `scripts/train_balance.py`: small editable balance trainer.
+- `scripts/play_balance.py`: policy playback with optional external force and torque pulses.
+- `scripts/train_sb3.py`: Stable-Baselines3 PPO/SAC training starter.
+- `scripts/live_policy_viewer.py`: live MuJoCo passive-viewer policy runner.
+
+## What The Generated Gym Env Does
+
+`scripts/gym_env.py` is the bridge between the exported CAD package and control code.
+
+It loads the package manifests, compiles `scene.xml`, discovers actuator IDs, identifies the simulation root body, and calibrates diff-drive signs from MuJoCo joint axes. This matters because mirrored wheel axes can make a naive same-sign left/right command spin or drift instead of moving forward.
+
+The balance environment exposes a compact observation:
+
+- tilt around the wheel axle
+- side tilt
+- angular velocity
+- uprightness
+- root height
+- longitudinal velocity
+- wheel velocities
+- previous forward command
+
+The semantic action is:
+
+- `semanticForward`
+- `semanticTurn`
+
+The env converts those semantic actions into calibrated actuator commands.
+
+## Training The Starter Balance Policy
+
+The generated trainer intentionally avoids heavy RL machinery.
+
+```bash
+cd /tmp/scout-cam-rover-mjcf
+uv run --python 3.11 --with mujoco --with numpy --with gymnasium --with pillow python scripts/train_balance.py --render-gif balance.gif --fps 10
+```
+
+It trains a linear policy:
+
+```text
+observation -> weighted sum -> tanh -> motor command
+```
+
+The optimizer is cross-entropy method:
+
+1. Try many random weight sets.
+2. Simulate each candidate.
+3. Score survival, uprightness, angular rate, and command cost.
+4. Keep the best candidates.
+5. Sample the next generation around those.
+
+This is not deep RL. It is a fast, inspectable starter controller. The right next steps for serious RL are PPO/SAC/PufferLib/MJX/Isaac Lab integrations that reuse the generated env or manifests.
+
+## Serious RL Workflow
+
+For a real reinforcement-learning run, treat the generated MJCF package as the simulator adapter and replace `train_balance.py` with the training stack you actually want. ForgeCAD's job is to produce a valid robot model, named actuators, controller metadata, and a Gymnasium-style environment scaffold; the RL project owns the policy class, reward, curriculum, vectorization, checkpointing, and evaluation harness.
+
+The usual loop is:
+
+1. Load `scene.xml` with MuJoCo.
+2. Load `manifest.json` and `simready-manifest.json` to map ForgeCAD names to MuJoCo bodies, joints, and actuators.
+3. Build observations from `mjData`, such as pose, tilt, angular velocity, wheel velocity, sensors, previous command, and task-specific state.
+4. Let the policy choose an action.
+5. Convert semantic actions, such as `[forward, turn]`, into actuator controls.
+6. Write controls into `mjData.ctrl`, then call `mj_step`.
+7. Compute reward, termination, truncation, and diagnostics.
+8. Let PPO, SAC, PufferLib, MJX, Isaac Lab, or another trainer update the policy.
+9. Save checkpoints and evaluate them with deterministic playback, randomized starts, friction/mass perturbations, and force-push tests.
+
+For the Scout Cam Rover balance example, the first serious action space should usually stay semantic:
+
+```text
+action = [semanticForward, semanticTurn]
+```
+
+That keeps the RL task independent from left/right motor sign conventions. The generated environment already calibrates mirrored wheel axes and maps semantic commands to actuator controls. If a later task needs raw motor commands, add that deliberately after the semantic baseline works.
+
+The reward should encode the actual job, not just survival. For a self-balancing rover, a practical first reward includes uprightness, low tilt rate, target velocity or position tracking, bounded control effort, and clear fall termination. Randomize initial tilt, mass, friction, and push disturbances once the baseline can solve the nominal case.
+
+## Training A Stable-Baselines3 Policy
+
+The MJCF package includes an editable SB3 starter that reuses `BalanceEnv` and the generated semantic diff-drive action mapping:
+
+```bash
+cd /tmp/scout-cam-rover-mjcf
+uv run --python 3.11 --with mujoco --with numpy --with gymnasium --with stable-baselines3 --with pillow python scripts/train_sb3.py \
+  --timesteps 50000 \
+  --output policies/sb3_balance_ppo.zip \
+  --render-gif sb3_balance.gif \
+  --fps 10
+```
+
+That command writes `policies/sb3_balance_ppo.zip` plus `policies/sb3_balance_ppo.json`. The JSON sidecar records the algorithm, observation/action shape, drive calibration, and short deterministic evaluation summary. Use `--algo sac` when you want the SAC template instead of PPO.
+
+## Pushing The Trained Policy
+
+After training, run the policy with a force pulse:
+
+```bash
+cd /tmp/scout-cam-rover-mjcf
+uv run --python 3.11 --with mujoco --with numpy --with gymnasium --with pillow python scripts/play_balance.py \
+  --policy policies/balance_linear.json \
+  --push-y 1 \
+  --push-at 2 \
+  --push-duration 0.15 \
+  --render-gif balance_push.gif \
+  --fps 10
+```
+
+`play_balance.py` applies force or torque through MuJoCo's `xfrc_applied` array on the root body. It reports the frame count, approximate GIF duration, push vector, final tilt, and survival time.
+
+Use these options to push from other directions:
+
+```bash
+--push-x 2
+--push-y -4
+--push-z 1
+--torque-x 0.1
+--torque-y -0.1
+--torque-z 0.1
+```
+
+Increase `--push-y` or `--push-x` when you want a failure/stress test instead of a recovery demo.
+
+Stable-Baselines3 zip policies use the same playback path:
+
+```bash
+cd /tmp/scout-cam-rover-mjcf
+uv run --python 3.11 --with mujoco --with numpy --with gymnasium --with stable-baselines3 --with pillow python scripts/play_balance.py \
+  --policy policies/sb3_balance_ppo.zip \
+  --push-y 1 \
+  --push-at 2 \
+  --push-duration 0.15 \
+  --render-gif sb3_balance_push.gif \
+  --fps 10
+```
+
+## MuJoCo App Vs Policy Control
+
+MuJoCo's standalone viewer and MuJoCo.app load models, not trained policies. Open `scene.xml` when you want to inspect the exported robot, geometry, joints, contacts, actuators, and passive dynamics:
+
+```bash
+uv run --python 3.11 --with mujoco python -m mujoco.viewer --mjcf=scene.xml
+```
+
+A trained policy is control code. The official MuJoCo control path is to set controls before stepping the simulator, or to install a control callback. In Python, the common interactive pattern is the passive viewer: the user script owns the loop, computes policy actions, writes `mjData.ctrl`, calls `mj_step`, and then calls `viewer.sync()`. On macOS, passive-viewer scripts should run with `mjpython`, which is installed with the `mujoco` Python package.
+
+Conceptually:
+
+```python
+model = mujoco.MjModel.from_xml_path("scene.xml")
+data = mujoco.MjData(model)
+
+with mujoco.viewer.launch_passive(model, data) as viewer:
+    while viewer.is_running():
+        action = policy(observation_from(data))
+        data.ctrl[:] = action_to_actuator_controls(action)
+        mujoco.mj_step(model, data)
+        viewer.sync()
+```
+
+`scripts/play_balance.py` is the generated scripted playback path. It loads the policy JSON, applies calibrated actuator commands, optionally applies force or torque pulses through `xfrc_applied`, and can render a diagnostic GIF. It is not the same thing as loading the policy into MuJoCo.app.
+
+To run a policy in an interactive window, use the generated passive-viewer script. On macOS, run it through `mjpython`:
+
+```bash
+cd /tmp/scout-cam-rover-mjcf
+uv run --python 3.11 --with mujoco --with numpy --with gymnasium --with stable-baselines3 mjpython scripts/live_policy_viewer.py \
+  --policy policies/sb3_balance_ppo.zip
+```
+
+## GIF Timing
+
+The generated scripts treat GIF duration as:
+
+```text
+duration ~= frame_count / fps
+```
+
+For a 6-second run at 10 FPS, expect about 60 frames. If the GIF is much shorter, the renderer is undersampling frames or the policy terminated early. The summary JSON prints both `frames` and `gifDurationSecondsApprox` for playback scripts.
+
+Keep FPS modest. A 10 FPS diagnostic GIF is usually easier to review, smaller than a 30 FPS one, and maps to a clean 100 ms GIF frame delay in common viewers.
+
+## What Belongs In ForgeCAD
+
+ForgeCAD should own:
+
+- physical metadata on parts
+- colliders and contact intent
+- joints and drive limits
+- named controller metadata
+- simulator package manifests
+- export to URDF, SDF, and MJCF; native USD/USDZ export is future work
+- generated starter envs, smoke tests, trainers, playback, and perturbation scripts
+- offline source-level readiness checks
+
+ForgeCAD should not own:
+
+- a `selfBalancingDiffDrive(...)` API
+- a single blessed RL algorithm
+- task-specific rewards
+- PufferLib-specific or IsaacLab-specific core CAD primitives
+- deployment-specific training infrastructure
+
+The durable product promise is: model once, export a working simulation lab, then swap the control stack freely.
+
+## Isaac Lab Fit
+
+Isaac Lab integration is plausible, but not turnkey in this slice.
+
+The current NVIDIA Isaac Lab docs describe custom robot training as a multi-step flow: import and tune the robot in Isaac Sim, then define the Isaac Lab interface needed to clone the robot, drive joints, and reset state. Their "Adding a New Robot" tutorial names `AssetBaseCfg` as the interface between the USD articulation and learning algorithms. Their asset configuration guide shows `ArticulationCfg` with `UsdFileCfg`, and notes that `UrdfFileCfg` can replace `UsdFileCfg` for URDF-backed articulations.
+
+Relevant docs:
+
+- https://isaac-sim.github.io/IsaacLab/main/source/tutorials/01_assets/add_new_robot.html
+- https://isaac-sim.github.io/IsaacLab/main/source/how-to/write_articulation_cfg.html
+
+ForgeCAD has the information Isaac Lab needs in pieces:
+
+- URDF export for an articulation import path
+- SimReady manifest with root part, joints, drives, materials, contacts, and controller metadata
+- SDF/MJCF packages for fast local physics iteration
+
+ForgeCAD does not currently have a native USD/USDZ export command. For Isaac workflows today, use URDF as the import artifact and carry the richer ForgeCAD simulation intent through `simready-manifest.json`.
+
+The missing ForgeCAD work for a clean Isaac Lab path is:
+
+- direct USD authoring or a generated Isaac Sim URDF import/conversion script
+- generated `ArticulationCfg` scaffold from `simready-manifest.json`
+- actuator config generation from `Sim.drive.*(...)`
+- reset/observation/action scaffolds equivalent to the MuJoCo Gym env
+- coordinate/frame audit for Isaac's stage conventions and imported URDF axes
+- Isaac Sim/Isaac Lab validation on a machine with those tools installed
+
+Until that exists, the recommended path is:
+
+1. Use MuJoCo export for fast local control-loop iteration.
+2. Export URDF for Isaac Sim and keep `simready-manifest.json` beside it.
+3. Generate or hand-write Isaac Lab `ArticulationCfg` and task code from the ForgeCAD manifests.
+4. Validate imported articulation axes, actuators, masses, colliders, and reset behavior in Isaac Lab.

package/dist/index.html

@@ -83,8 +83,8 @@
       * { margin: 0; padding: 0; box-sizing: border-box; }
       html, body, #root { width: 100%; min-height: 100%; background: var(--fc-bg); color: var(--fc-text); font-family: system-ui, -apple-system, sans-serif; }
     </style>
-    <script type="module" crossorigin src="/assets/app-DSYrDg0V.js"></script>
-    <link rel="stylesheet" crossorigin href="/assets/app-CE3sYcV7.css">
+    <script type="module" crossorigin src="/assets/app-C9ct2hRD.js"></script>
+    <link rel="stylesheet" crossorigin href="/assets/app-CjsbDlb7.css">
   </head>
   <body>
     <div id="root"></div>

package/dist/sitemap.xml

@@ -2,79 +2,91 @@
 <urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
   <url>
     <loc>https://forgecad.io/</loc>
-    <lastmod>2026-06-10</lastmod>
+    <lastmod>2026-06-12</lastmod>
     <changefreq>weekly</changefreq>
     <priority>1.0</priority>
   </url>
   <url>
     <loc>https://forgecad.io/docs</loc>
-    <lastmod>2026-06-10</lastmod>
+    <lastmod>2026-06-12</lastmod>
     <changefreq>weekly</changefreq>
     <priority>0.8</priority>
   </url>
   <url>
     <loc>https://forgecad.io/docs/ai-native-cad</loc>
-    <lastmod>2026-06-10</lastmod>
+    <lastmod>2026-06-12</lastmod>
     <changefreq>weekly</changefreq>
     <priority>0.9</priority>
   </url>
   <url>
     <loc>https://forgecad.io/docs/ai-usage</loc>
-    <lastmod>2026-06-10</lastmod>
+    <lastmod>2026-06-12</lastmod>
     <changefreq>weekly</changefreq>
     <priority>0.8</priority>
   </url>
   <url>
     <loc>https://forgecad.io/docs/cli</loc>
-    <lastmod>2026-06-10</lastmod>
+    <lastmod>2026-06-12</lastmod>
     <changefreq>weekly</changefreq>
     <priority>0.7</priority>
   </url>
+  <url>
+    <loc>https://forgecad.io/docs/simready-quickstart</loc>
+    <lastmod>2026-06-12</lastmod>
+    <changefreq>weekly</changefreq>
+    <priority>0.8</priority>
+  </url>
+  <url>
+    <loc>https://forgecad.io/docs/simulation-workflow</loc>
+    <lastmod>2026-06-12</lastmod>
+    <changefreq>weekly</changefreq>
+    <priority>0.8</priority>
+  </url>
   <url>
     <loc>https://forgecad.io/docs/skills/forgecad-make-a-model</loc>
-    <lastmod>2026-06-10</lastmod>
+    <lastmod>2026-06-12</lastmod>
     <changefreq>weekly</changefreq>
     <priority>0.7</priority>
   </url>
   <url>
     <loc>https://forgecad.io/benchmark</loc>
-    <lastmod>2026-06-10</lastmod>
+    <lastmod>2026-06-12</lastmod>
     <changefreq>weekly</changefreq>
     <priority>0.7</priority>
   </url>
   <url>
     <loc>https://forgecad.io/blog</loc>
-    <lastmod>2026-06-10</lastmod>
+    <lastmod>2026-06-12</lastmod>
     <changefreq>weekly</changefreq>
     <priority>0.6</priority>
   </url>
   <url>
     <loc>https://forgecad.io/pricing</loc>
-    <lastmod>2026-06-10</lastmod>
+    <lastmod>2026-06-12</lastmod>
     <changefreq>monthly</changefreq>
     <priority>0.5</priority>
   </url>
   <url>
     <loc>https://forgecad.io/terms</loc>
-    <lastmod>2026-06-10</lastmod>
+    <lastmod>2026-06-12</lastmod>
     <changefreq>yearly</changefreq>
     <priority>0.3</priority>
   </url>
   <url>
     <loc>https://forgecad.io/privacy</loc>
-    <lastmod>2026-06-10</lastmod>
+    <lastmod>2026-06-12</lastmod>
     <changefreq>yearly</changefreq>
     <priority>0.3</priority>
   </url>
   <url>
     <loc>https://forgecad.io/license</loc>
-    <lastmod>2026-06-10</lastmod>
+    <lastmod>2026-06-12</lastmod>
     <changefreq>yearly</changefreq>
     <priority>0.3</priority>
   </url>
   <url>
     <loc>https://forgecad.io/blog/hello-forgecad-io</loc>
-    <lastmod>2026-06-10</lastmod>
+    <lastmod>2026-06-12</lastmod>
     <changefreq>monthly</changefreq>
     <priority>0.5</priority>
   </url>

package/dist-cli/{check-compiler-JTVBITCR.js → check-compiler-SP7FAL7R.js}

@@ -9,7 +9,7 @@ import {
   resolvePackagePath,
   runDirectCliMain,
   setActiveBackend
-} from "./chunk-OAN5T4XD.js";
+} from "./chunk-RQQ42YCP.js";
 
 // cli/check-compiler.ts
 import assert from "assert/strict";

package/dist-cli/{check-query-propagation-3FFLSMVN.js → check-query-propagation-BRLSHP22.js}

@@ -12,7 +12,7 @@ import {
   resolvePackagePath,
   runDirectCliMain,
   setActiveBackend
-} from "./chunk-OAN5T4XD.js";
+} from "./chunk-RQQ42YCP.js";
 
 // cli/check-query-propagation.ts
 import assert from "assert/strict";