forgecad 0.10.1 → 0.10.3

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

@@ -139,11 +139,13 @@ Then export the package that matches your simulator:
 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.
 
-ForgeCAD does not currently have a native USD/USDZ export command. For Isaac workflows today, export URDF as the import artifact and carry the richer ForgeCAD simulation intent through `simready-manifest.json`. A future USD exporter should consume the same source-level simulation contract instead of re-inferring physics metadata from mesh geometry.
+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.
 

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

@@ -2,6 +2,64 @@
 
 ForgeCAD should make a robot or simulated asset runnable without making the CAD API own the control algorithm.
 
+## Native Analysis: The Closed Feedback Loop
+
+Some analyses need no external simulator at all — they are computed directly from the model geometry and return a machine-readable feedback report an AI agent (or you) can act on. This is the simulation feedback cycle in its simplest, fastest form: **edit the `.forge.js` → run the analysis → read the metrics → change a parameter → re-run.**
+
+Every native analysis emits the same `forgecad.feedback/v1` contract: name-keyed `metrics` each with a `pass`/`warn`/`fail` status, `findings` that carry an actionable `suggest`, and a `trust` block recording the assumptions behind the numbers.
+
+### Mass properties
+
+```bash
+node dist-cli/forgecad.js sim mass model.forge.js --density 2700 --json
+```
+
+Reports volume, mass, surface area, bounding box, center of mass, the full inertia tensor about the center of mass, principal moments and axes, and a per-object breakdown. Volume, center of mass, and principal axes are exact regardless of material; pass `--density <kg/m3>` (e.g. `2700` aluminium, `7850` steel, `1240` ABS) for accurate mass and inertia magnitude — otherwise it defaults to water and says so.
+
+### Static stability (tip-over)
+
+```bash
+node dist-cli/forgecad.js check stability model.forge.js --min-margin-mm 5 --json
+```
+
+Computes the center of mass, derives the support footprint as the convex hull of the lowest geometry, and reports the **signed tip-over margin** (distance from the CoM projection to the footprint edge — negative means it tips), the tilt angle at which it tips, the critical edge, and the **center-of-mass shift needed** to reach the required margin. Exits non-zero when the margin is below `--min-margin-mm`. Use `--up x|y|z` to set the up axis.
+
+A worked closed loop ships in `examples/analysis/tipping-tripod.forge.js`: at the default base the rig tips by about 3 mm, the report points the fix in −X, and `--param BaseSpreadMm=90` recovers a comfortable positive margin.
+
+### Tolerance / GD&T stack-up
+
+```bash
+node dist-cli/forgecad.js sim tolerance model.forge.js --json
+```
+
+Treats the model's continuous parameters as the varying manufacturing inputs and its numeric `verify.*` results as the measured responses — so ordinary `param(...)` and `verify.inRange(...)` calls already declare the stack-up, with no special API. It builds a finite-difference Jacobian, runs a deterministic Monte Carlo over the linearized surrogate, and reports per-response mean/sigma, Cp/Cpk, yield % and DPMO, worst-case and RSS envelopes, a ranked variance-contribution list (**which dimension to tighten**), and a tolerance-allocation recommendation to reach the target Cpk. A nonlinearity guard errors (pointing you to `--method full-rebuild`) rather than silently reporting a wrong yield; exits non-zero when any response's Cpk is below `--target-cpk` (default 1.33).
+
+A worked closed loop ships in `examples/analysis/clearance-fit.forge.js`: the default (loose) bores hold the clearance spec at only ~84% yield, the report names the dominant dimension, and `--tol BoreDia=±0.05 --tol ShaftDia=±0.05` lifts Cpk above 1.33.
+
+### Mechanism budget (DOF + static-hold torque)
+
+```bash
+node dist-cli/forgecad.js sim mechanism model.forge.js --json
+```
+
+The deterministic budget tier of rigid-body dynamics, computed straight from the assembly joint graph — no external solver, no time-stepping. It reports the actuated degrees of freedom (with a spatial Grübler mobility diagnostic for closed loops) and, for each actuated joint, the gravity-hold torque (revolute) or force (prismatic) it must supply at the current pose, derived from the mass of everything distal to it. When a joint carries a `Sim.drive` effort, the report includes the budget margin and flags over-budget joints. Use `--joint Name=Value` to evaluate a specific pose. The dynamic/contact tier (RL, collisions) is the external Pinocchio/MuJoCo export.
+
+A worked closed loop ships in `examples/analysis/lever-arm-actuator.forge.js`: a 1 kg arm at 0.15 m needs 1.47 N·m (= m·g·r) and holds with ~63% margin against its 4 N·m motor; `--param ArmLength=900` pushes it to 4.4 N·m and trips `MECHANISM.HOLD.OVER_BUDGET`.
+
+### Rigid-body dynamics export (Pinocchio)
+
+```bash
+node dist-cli/forgecad.js export pinocchio model.forge.js --output out/robot_pinocchio
+cd out/robot_pinocchio && uv run --python 3.11 --with pin --with numpy python scripts/run_pinocchio.py
+node dist-cli/forgecad.js sim dynamics out/robot_pinocchio
+```
+
+The dynamic tier. `export pinocchio` reuses the URDF package (per-link inertials computed from the solid) and adds a runnable Pinocchio harness. `run_pinocchio.py` builds the model with `pin.buildModelFromUrdf`, sweeps each joint, computes the gravity-hold torque with `pin.computeGeneralizedGravity`, and writes `feedback.json` in the same `forgecad.feedback/v1` contract; `sim dynamics` reads it back. Pinocchio (BSD-2-Clause) and Coal (BSD-3-Clause) are user-installed — `pip install pin coal` on Linux/macOS, conda-forge on Windows — never bundled.
+
+This closes the same loop as `sim mechanism` and cross-checks it: on the lever-arm example, Pinocchio reports the same 1.47 N·m shoulder hold torque the native tier computes analytically.
+
+See [docs/internal/simulation-feedback-cycle.md](./simulation-feedback-cycle.md) for the full strategy across all simulation categories.
+
 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

package/dist/docs-raw/skills/forgecad-blockout-model.md

@@ -18,7 +18,7 @@ A blockout is a spatial planning artifact: 3-7 simple masses that answer where p
 | Need | Skill |
 |------|-------|
 | High-level 3D idea using simple masses | `forgecad-blockout-model` |
-| Written concept or architecture before CAD | `forgecad-high-level-spec` |
+| Written concept or architecture before CAD | `forgecad-spec-by-walking-through-it` |
 | Accurate, detailed, parametric ForgeCAD model | `forgecad-make-a-model` |
 
 ### Method

package/dist/docs-raw/skills/forgecad-image-replicator.md

@@ -18,7 +18,7 @@ The reference image is evidence, not the deliverable. The deliverable is a real
 ### Companion Skills
 
 - `forgecad` — API docs, model authoring, renderer behavior.
-- `forgecad-prepare-prompt` — when the images underdetermine artifact family, process posture, scale, operating story, or validation boundary.
+- `forgecad-spec-by-walking-through-it` — when the images underdetermine artifact family, process posture, scale, operating story, or validation boundary.
 - `forgecad-make-a-model` — file placement, project structure, decomposition, definition of done.
 - `forgecad-render-inspect` — pre-delivery inspection for multi-part, internal, mechanical, thin-wall, or fit-sensitive objects.
 
@@ -30,7 +30,7 @@ Infer the real object before matching any camera — identity, manufacture, scal
 
 1. Stage references in `/tmp/<slug>-replicate/refs`, keeping originals and adding view names where possible (`front`, `side`, `rear-iso`, `top`, `detail`).
 2. Read each image as evidence, recording: visible facts; scale cues; camera cues; unknowns (hidden/occluded geometry); conflicts across images or stylization.
-3. Write a Real Object Brief — a hard gate before modeling: (a) artifact identity + operating story; (b) assumed scale and units; (c) process posture + part/BOM boundary (real geometry vs purchased vs ghost vs omitted); (d) inferred hidden-side geometry + expected canonical front/back/left/right/top/bottom forms; (e) validation views and inspection evidence. Use `forgecad-prepare-prompt` when these are underdetermined.
+3. Write a Real Object Brief — a hard gate before modeling: (a) artifact identity + operating story; (b) assumed scale and units; (c) process posture + part/BOM boundary (real geometry vs purchased vs ghost vs omitted); (d) inferred hidden-side geometry + expected canonical front/back/left/right/top/bottom forms; (e) validation views and inspection evidence. Use `forgecad-spec-by-walking-through-it` when these are underdetermined.
 4. Build a coarse 3D blockout — model the object, not the image: large volumes, axes, symmetry, side depth, rear form, underside, hidden continuations. Render canonical views before any reference-camera comparison. Follow `forgecad-make-a-model` for project structure.
 5. Calibrate one camera per usable reference, only after the blockout makes sense from canonical views. Use the object center as `target`; estimate azimuth/elevation/distance/FOV from visible faces and perspective cues; use orthographic when parallel edges stay parallel with no perspective convergence.
 6. Render comparison boards: render the model from each calibrated reference camera and place it next to the original. Never compare from memory.

package/dist/docs-raw/skills/forgecad-mujoco-verify.md

@@ -0,0 +1,78 @@
+<!-- Generated by scripts/build-forgecad-skill.mjs — do not edit. Edit agent-skill-library/forgecad-mujoco-verify/SKILL.md instead. -->
+
+# forgecad-mujoco-verify
+
+Verify ForgeCAD MJCF exports in MuJoCo with real dynamics, contacts, root behavior, controls, required joint travel, and rendered evidence before calling a model simulation-ready. Use when making a ForgeCAD assembly sim-ready, debugging MJCF contacts, checking why a body falls through the floor, validating actuator motion, or proving a mechanism moved through the intended range.
+
+| Field | Value |
+| --- | --- |
+| Installed by | `forgecad skill install` |
+| Source | `agent-skill-library/forgecad-mujoco-verify/SKILL.md` |
+
+---
+
+## ForgeCAD MuJoCo Verify
+
+Use this when `forgecad export mjcf ...` is part of the deliverable. A model is not sim-ready just because `forgecad check simready` passes or the MJCF file loads: it must be loaded in MuJoCo, stepped under gravity, driven with the intended controls, contact pairs inspected, and rendered from useful views.
+
+Routing: geometry-only visual inspection -> `forgecad-render-inspect`; model authoring/API questions -> `forgecad`; building a new model -> `forgecad-make-a-model`.
+
+### Definition Of Done
+
+1. **Export from the exact source file.**
+   ```bash
+   rm -rf /tmp/forgecad-mjcf && mkdir -p /tmp/forgecad-mjcf
+   forgecad export mjcf path/to/model.forge.js --output /tmp/forgecad-mjcf
+   ```
+2. **Load the generated scene in MuJoCo.** Use `scene.xml`, not only the model XML, so the floor/camera/package context is included.
+3. **Check the root behavior.** If the model has a free root, it needs real support/contact geometry or an explicit fixed-root export path. Do not hide a floor failure by turning the whole shell into a giant bounding box that blocks moving internals.
+4. **Check initial poses numerically.** For mechanisms, compute the expected body/link axes from the design source and compare them to MuJoCo `xmat`/`xpos`. Joint `ref`/default and connector frames can disagree with visual intuition.
+5. **Keep meaningful collisions.** Do not mark moving functional parts `Sim.collider.none(...)` just to make motion pass. If full visual mesh contact is unstable, use a physically defensible simplified collider or proxy and state what physical surface it represents.
+6. **Run the intended control with numeric acceptance criteria.** Define the expected signed post-settle joint travel before running the test: e.g. "this drive should rotate the drum -0.04 to -0.06 cycles, then stop near zero velocity" or "this wheel should move at least +1 cycle and keep spinning". Use cycles for revolute/indexing mechanisms when that is easier to reason about, and radians for direct MuJoCo qpos checks. A controller that only jitters, moves the wrong direction, overshoots through a stop, or eventually jams after skipping the intended state is a failure even when the process exits 0.
+7. **Inspect contact pairs.** Contact names should match the physical story: floor/support, card/card, wheel/ground, stop/follower, etc. Contacts against a filled-in AABB, hidden fixture, or unrelated side plate usually indicate bad collider selection.
+8. **Render evidence.** Save initial, settled, and driven frames from views that actually show the moving parts. If the model orientation is not obvious, generate a labeled camera preview grid first, inspect it, then rerun with the azimuth/elevation that shows the functional face. Do not report GIFs/frames before visually confirming they are not from the back, underside, or an occluded side.
+
+### Helper Script
+
+This skill ships a MuJoCo smoke verifier:
+
+```bash
+uv run --python 3.11 --with mujoco --with pillow \
+  python <this-skill-dir>/scripts/mujoco_verify.py /tmp/forgecad-mjcf \
+  --settle-seconds 2 \
+  --seconds 8 \
+  --actuator drum_velocity=-0.75 \
+  --watch-joint drum_joint \
+  --expect-drive-cycles drum_joint=-0.06:-0.03 \
+  --expect-final-qvel drum_joint=-0.02:0.02 \
+  --render-dir /tmp/forgecad-mjcf/verify \
+  --camera-preview-grid
+```
+
+Use `--actuator name=value` more than once for multi-actuator models. Use `--expect-drive-cycles joint=min:max` to assert signed final-minus-settled revolute travel in cycles/turns. Use `--expect-drive-delta joint=min:max` when you want raw MuJoCo qpos units instead. Use `--expect-final-qvel joint=min:max` to assert terminal velocity when the mechanism should stop or continue at a bounded speed. The script prints JSON with root drift, initial-to-final joint delta, post-settle drive delta, derived cycle counts, final velocities, expectation ranges, and top contact pairs, then writes PNG frames if `--render-dir` is supplied.
+
+Prefer explicit travel envelopes over loose "it moved" checks:
+
+- Stops/latches: assert a signed drive cycle or delta range and a near-zero final velocity range.
+- Continuous drives: assert the signed drive cycle/delta is large enough over the run and final velocity remains in the expected direction/range.
+- Indexing mechanisms: assert the expected cycle step size, not just eventual stall. If the mechanism reaches a stop only after skipping several indices, treat that as failure.
+- Gravity-settling mechanisms: evaluate functional travel with post-settle drive delta, not initial-to-final delta.
+
+When rendered orientation matters, start with `--camera-preview-grid`, open `camera_preview_grid.png`, pick the azimuth that shows the mechanism face or contact interface, then rerun with `--camera-azimuth <deg>` and any needed `--camera-lookat`, `--camera-distance`, or `--camera-elevation` adjustment. For mechanism evidence, prefer front/front-quarter views for user-facing GIFs and add a side/contact view only when it explains a collision better.
+
+### Contact Debugging Rules
+
+- In MuJoCo UI, enable contact visualization with `Rendering` -> `Contact points` and `Contact forces`; use the right-side perturb/visualization panels if available in your build.
+- If rotation is blocked, list contacts during the stall and sort by repeated pairs. The blocker is usually the pair that appears every step while the driven joint velocity trends to zero.
+- If a body falls through the floor, inspect the exported geoms. Visual geoms have `contype="0" conaffinity="0"` and cannot support anything; collision geoms are usually group 3.
+- Bounding boxes are fast but dangerous for hollow frames, windows, handles, and side plates. They collide as the filled AABB, not the visible object.
+- Mesh collision on complex moving parts can be too exact or solver-hostile. Prefer simple physical proxies for contact-critical moving bodies, such as a slab for a flap card or cylinders for rolling contact, but keep them colliding.
+
+### Reporting
+
+Report the exact export command, the MuJoCo command/script, key numeric results, the most important contact pairs, and the rendered image paths. Say what was not verified. Never say "sim-ready" when only `forgecad run`, `forgecad check simready`, or a successful export was executed.
+
+
+## Bundled Files
+
+- `scripts/mujoco_verify.py`

package/dist/docs-raw/skills/forgecad-spec-by-walking-through-it.md

@@ -0,0 +1,145 @@
+<!-- Generated by scripts/build-forgecad-skill.mjs — do not edit. Edit agent-skill-library/forgecad-spec-by-walking-through-it/SKILL.md instead. -->
+
+# forgecad-spec-by-walking-through-it
+
+Design a ForgeCAD model, mechanism, or assembly by fixing WHAT before HOW in a git-reviewed design document, validated by mentally operating the thing step by step. Covers fuzzy-request intake and process choice, high-level design (HLD), and low-level design (LLD). Use on "spec this out", "plan the design", "write the HLD/LLD", a vague build request that needs concrete decisions, or any moment the right move is a reviewable spec before code.
+
+| Field | Value |
+| --- | --- |
+| Installed by | `forgecad skill install` |
+| Source | `agent-skill-library/forgecad-spec-by-walking-through-it/SKILL.md` |
+
+---
+
+## Spec by Walking Through It
+
+The design document — a git-committed, diff-reviewed markdown file — is the source of truth. Not the code, not the chat, not your head. You iterate it by commit-and-review, and the `git diff` is the review artifact.
+
+**Validate the design by mentally operating the thing, step by step.** Walk it as someone assembles, uses, or moves it. The step with no answer — *"how does the servo get inside the housing?"* — is the real design gap. A spec that reads complete on the page can still hide a hole that only surfaces when you try to put it together in your head. State each gap falsifiably: not "tolerances might be tight" but "the 12mm arm cantilevers under gripping load, may flex >0.5mm."
+
+**Every number has a reason; the narrative comes before the numbers.** Describe the object as if over the phone, then derive each value and show its math: `wallThickness = 2.4mm = 6 × 0.4mm nozzle`. The design is **implementation-blind** — shaped by the object, never by what the ForgeCAD API makes easy. **Manufacturing process is one of those reasons** — a design decision you weigh, never a default you inherit (never assume FDM/printing).
+
+**A vague request is a set of decisions you make honestly, not information to extract.** No placeholders ("appropriate motor"); choose a defensible value, show why, continue. The Decisions table fills only after user review, so the loop stays in the document.
+
+### Altitude — three phases, one document trail
+
+| Phase | When | Output |
+|-------|------|--------|
+| Intake | request is fuzzy / process unspecified | engineering brief + master prompt |
+| HLD | design is wrong in *approach*, alternatives exist | `<name>-hld.md` |
+| LLD | decisions locked, or a simple single-body part | `<name>-lld.md` |
+
+The HLD carries only decision-driving dimensions and genuinely-different alternatives; the LLD carries enough that someone builds from it alone. Speccing every tolerance in an HLD, or revisiting locked decisions in an LLD, is an altitude error — back up. Simple parts skip straight from HLD to code, or from a request to an LLD.
+
+---
+
+### Phase 1 — Intake (fuzzy request → concrete brief)
+
+Use when the user wants something physically real but the ask is vague ("make me a robot gripper", "make it production ready", "pick sensible numbers"). This phase owns intake; once the brief is concrete, continue to HLD or hand off to the `forgecad` skill.
+
+**Manufacturing is a design decision, not a default.** Derive the process stack from artifact family, load path, scale, safety expectations, material, production intent, and operating story — never assume printing/plastic. If the user names a process, honor it but warn when it is unsafe or dishonest for the duty. Family→process anchors live in `references/default-profiles.md`.
+
+**Default posture: manufacture-realistic prototype** — real materials, purchased-part boundaries, assembly logic, validation; no claims of production tooling or certification. Other postures only when justified: `production-realistic`, `printable`, `visual-CAD`, or a specific process posture (`sheet-metal`, `CNC-machined`, `laser-cut`, `welded-tube`, `injection-molded`, `cast`, `hybrid purchased-hardware`). Pick the posture honest for the artifact, not the easiest CAD surface.
+
+**Family-scoped numbers.** Every starter assumption is scoped to one artifact family; never reuse numbers across families.
+
+Workflow:
+1. **Normalize the ask** into plain mechanism language ("6 DOF gripper" → standalone gripper, wrist+gripper, or arm+gripper).
+2. **Build a specific operating story** — invented (non-famous) org, named program, prototype revision, review moment, mission pressure (pilot gate, demo date, investor milestone), and the generic failure mode to avoid. Prefer bold high-agency stories over modest lab exercises. Never assert the user works for a named real company; use real products only as public comparison anchors; never clone proprietary designs.
+3. **Classify the artifact family** (`references/default-profiles.md`); use the no-family-fits escape rather than forcing one. Rideables route to human-vehicles, never chassis.
+4. **Choose the process posture** per the taxonomy above.
+5. **Pick qualitative levers** — duty (`light`/`general`/`sturdy`), scale (`compact`/`medium`/`large`), cost (`cheapest`/`balanced`/`performance-first`) — and translate to family-scoped starter assumptions.
+6. **Close only critical gaps** — at most 3 grouped questions, always choice menus, never raw engineering inputs unless the architecture truly depends on them. Good: "light desk demo, useful hobby tool, or sturdier bench mechanism?" Bad: "What payload mass?"
+7. **Write the engineering brief**: artifact + family + normalized interpretation; operating story + production reason + test setting + failure mode to avoid; output posture; intended loads, size envelope, motion/DOF; process stack + material defaults; purchased-part (BOM) boundary; validation standard; variant policy (versions are selectable params, one rendered at a time); file organization (`main.forge.js` entry for multi-file); explicit uncertainty policy.
+8. **Emit one master prompt** — fill `references/master-prompt.md`; return the finished prompt, not notes about it. It must demand exactly `BUILD-READY` or `BEST-EFFORT BUILD CANDIDATE` (human-bearing furniture and rideables usually end the latter).
+
+Defaults if the user stays vague: `general-duty` / `medium` / `balanced`, invent the operating story, use family starter assumptions.
+
+---
+
+### Phase 2 — High-Level Design (HLD)
+
+Aligns user and agent on *what* to build before *how*. Brevity is a readability tool, not a metric — include whatever evidence, diagrams, and dimensions a good decision needs. Write the sections top to bottom; the order is the workflow.
+
+```markdown
+# [Name] — High-Level Design
+
+## Problem
+What must this do? Hard requirements (grip 40-90mm objects, fit a 60mm
+housing, use purchased bearings). State the problem without implying a
+solution. Unspecified process choice is an open design dimension.
+
+## Approach
+How it works conceptually. ASCII diagram of key elements and their
+spatial relationships — diagram labels stay in this markdown, never
+carried into CAD geometry unless the real artifact needs markings.
+
+## Key Interfaces
+Every point where this touches another part or the outside world:
+mating surfaces, shared dimensions, coordination points. These are the
+contracts that constrain the design.
+
+## Dictionary
+| Term | What it is |
+Define every domain term in plain words, with dimensions where relevant.
+Write for a developer without a mechanical-engineering background.
+
+## Alternatives
+| Option | Description | Tradeoff |
+2-3 genuinely different strategies, not minor variations. Mark one
+recommended and say why. If there is honestly one approach, say so.
+
+## Usage Guide
+Work backwards from how someone uses, assembles, or operates the thing,
+step by step. If a step doesn't make sense ("how does the servo get
+inside?"), flag it inline with ⚠️ and promote it to Concerns.
+
+## Concerns
+1. Numbered, falsifiably specific — a reviewer must be able to say "real
+   problem" or "fine, because…".
+
+## Decisions
+| # | Decision | Rationale |
+Filled ONLY after user review — never pre-decide. Each row resolves a
+concern or alternative.
+```
+
+Rules: if you're speccing every part, formula, and tolerance, you're writing an LLD — back up. If you can't draw it, you don't understand it yet.
+
+---
+
+### Phase 3 — Low-Level Design (LLD)
+
+Implements the HLD's locked Decisions table; it never revisits those decisions. Simple single-body parts skip the HLD and start here. Complex assemblies split into a numbered directory: overview, global constraints, per-component files, assembly, verification.
+
+An LLD is **narrative-first** (reads like describing the object over the phone), **authoritative** (the single source code implements), **implementation-blind**, and shows **every number's rationale**.
+
+Required structure:
+1. **Narrative** — what it is, how it behaves and interacts, why it exists. Concrete comparisons ("about the size of a deck of cards"); no ungrounded vague terms.
+2. **Technical** — typed parameter table (length / angle / count / boolean / choice / ratio / clearance — design-document vocabulary, not the runtime `Param.*` API), always with units (mm, degrees default) and a rationale for every default and range; derived dimensions shown as math; geometry and constraints, each constraint with a rationale.
+3. **Verification** — mandatory checklist: dimensional, functional, printability/process checks.
+
+Don'ts: never open with a parameter list (story before numbers), never leave a constraint implicit, never skip verification. Completeness gate before presenting: can someone build from this alone? Does it implement every HLD decision? Is every constraint explicit with a rationale?
+
+---
+
+### Review via git
+
+HLDs and LLDs iterate through git, not conversation:
+- **Commit every version.** No drafts floating in chat. After writing, commit and tell the user it's ready for review.
+- **Feedback arrives as file edits (inline comments, strikethroughs) or chat — check both.** Read `git diff`: the diff is the review artifact.
+- **Update, commit, repeat** until the Decisions table is filled and the user says "go."
+
+### Pipeline
+
+| Stage | This skill's phase | Output | Next |
+|-------|--------------------|--------|------|
+| Explore a fuzzy ask | Intake | engineering brief + master prompt | HLD |
+| Decide *what* to build | HLD | `*-hld.md` (Decisions filled) | LLD |
+| Detail *how* to build | LLD | `*-lld.md` | `forgecad-make-a-model` + `forgecad` → `.forge.js` |
+
+
+## Bundled Files
+
+- `references/default-profiles.md`
+- `references/master-prompt.md`

package/dist/docs-raw/skills/forgecad-visual-spec.md

@@ -15,7 +15,7 @@ Turn a concrete ForgeCAD artifact, build brief, HLD, or existing model into buil
 
 ### Scope
 
-Only for artifacts already concrete enough to visualize (a specific `.forge.js` model, build brief, or HLD); route vague briefs to `forgecad-prepare-prompt` first. Read minimum context — entry `.forge.js`, one key helper if it delegates geometry, brief/HLD — and capture what must survive the image model: artifact type and scale, major subassemblies, actuation style, visible mechanisms, material and color cues.
+Only for artifacts already concrete enough to visualize (a specific `.forge.js` model, build brief, or HLD); route vague briefs to `forgecad-spec-by-walking-through-it` first. Read minimum context — entry `.forge.js`, one key helper if it delegates geometry, brief/HLD — and capture what must survive the image model: artifact type and scale, major subassemblies, actuation style, visible mechanisms, material and color cues.
 
 ### Core Rule
 

package/dist/docs-raw/skills/forgecad.md

@@ -1,4 +1,4 @@
-<!-- Generated by scripts/build-forgecad-skill.mjs — do not edit. Edit docs/permanent/ instead. -->
+<!-- Generated by scripts/build-forgecad-skill.mjs — do not edit. Edit docs/skill/ instead. -->
 
 # forgecad
 
@@ -7,7 +7,7 @@ ForgeCAD model authoring, editing, debugging, and execution guidance for .forge.
 | Field | Value |
 | --- | --- |
 | Installed by | `forgecad skill install` |
-| Source | Generated from `docs/permanent/` by `scripts/build-forgecad-skill.mjs` |
+| Source | Generated from `docs/skill/` by `scripts/build-forgecad-skill.mjs` |
 
 ---
 
@@ -18,9 +18,9 @@ Author or modify ForgeCAD models, sketches, assemblies, and CLI workflows. Prefe
 ### Workflow
 
 1. Identify the artifact: `.forge.js`, SVG asset, or CLI/export task.
-2. **If the model has any moving parts, load the `assembly` group and `docs/permanent/guides/joint-design.md` upfront** — do not defer the kinematic structure to a refactor pass.
+2. **If the model has any moving parts, load the `assembly` group and `docs/skill/guides/joint-design.md` upfront** — do not defer the kinematic structure to a refactor pass.
 3. Load only the docs the task needs (see Source Map below). Start from the top group, add others as needed, and prefer these docs and recipes over ad-hoc repo examples.
-4. If any two parts are intended to touch or mate in the final model, load `docs/permanent/guides/positioning.md` immediately and default to connectors + `matchTo()`.
+4. If any two parts are intended to touch or mate in the final model, load `docs/skill/guides/positioning.md` immediately and default to connectors + `matchTo()`.
 5. Default to a concrete first pass — easy iteration beats speculative design review.
 6. If an existing model is broken, replace the weak structure rather than preserving bad architecture.
 7. Validate with `forgecad run <file>` (add `--debug-imports` for import chain issues; pass `--backend manifold|occt|truck` when the backend matters).
@@ -46,77 +46,77 @@ Load groups top-to-bottom, stopping when you have what the task needs.
 
 Execution model, colors, coordinate system, primitives, booleans, patterns, imports, parameters, topology, edge queries.
 
-- `docs/permanent/API/core/concepts.md`
-- `docs/permanent/generated/runtime-names.md`
-- `docs/permanent/generated/core.md`
+- `docs/skill/API/core/concepts.md`
+- `docs/skill/generated/runtime-names.md`
+- `docs/skill/generated/core.md`
 
 #### 2. Static Assembly and Positioning (for any multi-part model)
 
 Axis conventions, winding rules, and placement strategy. If parts should touch in the final model, read this group before writing placement code. Connectors + `matchTo()` are the default for mating interfaces; raw `translate()` and `rotate()` are for free offsets, not assembly contracts.
 
-- `docs/permanent/guides/coordinate-system.md`
-- `docs/permanent/guides/positioning.md`
+- `docs/skill/guides/coordinate-system.md`
+- `docs/skill/guides/positioning.md`
 
 #### 3. Sketch APIs
 
 2D construction, transforms, booleans, paths, on-face sketching, extrusion, anchors, text, regions.
 
-- `docs/permanent/generated/sketch.md`
+- `docs/skill/generated/sketch.md`
 
 #### 4. Curves and Surfacing (for lofts, sweeps, splines)
 
 Smooth curves, Hermite splines, lofted and swept solids. For straps, inlays, guards, brace members, vents, or physical bands that live on a carrier surface, use `Carrier` + `SurfaceBody` surface-member primitives before reaching for `variableSweep`, SDF sculpting, or manual boolean overlap recipes.
 
-- `docs/permanent/guides/surface-members.md`
-- `docs/permanent/generated/curves.md`
+- `docs/skill/guides/surface-members.md`
+- `docs/skill/generated/curves.md`
 
 #### 5. Assemblies and Mechanisms (for joints or kinematics)
 
-Assembly graph, joint types, couplings, validation, robot export.
+Assembly graph, joint types, couplings, validation, and simulation export.
 
-- `docs/permanent/generated/assembly.md`
+- `docs/skill/generated/assembly.md`
 
 #### 6. Sheet Metal (for bent parts, K-factor, flat patterns)
 
 Bend operations, flat pattern unfolding, K-factor configuration.
 
-- `docs/permanent/generated/sheet-metal.md`
+- `docs/skill/generated/sheet-metal.md`
 
 #### 7. Output and Export (for STL/3MF/STEP, BOM, dimensions)
 
 Mesh export, exact geometry export, bill of materials, dimension annotations.
 
-- `docs/permanent/generated/output.md`
+- `docs/skill/generated/output.md`
 
 #### 8. Toolbox (fasteners and standard parts)
 
 Parametric bolts, nuts, washers, standard hardware, gears, pipes, and structural profiles.
 
-- `docs/permanent/generated/lib.md`
-- `docs/permanent/generated/wood.md`
+- `docs/skill/generated/lib.md`
+- `docs/skill/generated/wood.md`
 
 #### 9. Runtime Viewport APIs (for cut planes, exploded views, hiding, and animation playback)
 
 Viewer-only APIs such as cutPlane, explodeView, render labels, comparison references, and runtime display behavior.
 
-- `docs/permanent/generated/viewport.md`
+- `docs/skill/generated/viewport.md`
 
 #### 10. Recipes and Debugging (for patterns and troubleshooting)
 
 Modeling patterns, debugging tactics, copyable snippets.
 
-- `docs/permanent/guides/scene-presentation.md`
-- `docs/permanent/guides/joint-design.md`
+- `docs/skill/guides/scene-presentation.md`
+- `docs/skill/guides/joint-design.md`
 
 #### 11. CLI (for validation/render/export tasks)
 
 Test-run, export pipelines, debug flags.
 
-- `docs/permanent/CLI.md`
-- `docs/permanent/guides/inspection-bundles.md`
+- `docs/skill/CLI.md`
+- `docs/skill/guides/inspection-bundles.md`
 
 #### SDF Modeling (smooth booleans, TPMS, deformations, fromFunction)
 
 Primitives, smooth booleans, TPMS lattices, twist/bend/displace, morph, custom functions, gotchas. The doc preamble's precision caution applies to every SDF workflow.
 
-- `docs/permanent/generated/sdf.md`
+- `docs/skill/generated/sdf.md`

package/dist/docs-raw/skills/index.md

@@ -14,13 +14,12 @@ forgecad skill install
 | [forgecad-3d-reconstruction](/docs/skills/forgecad-3d-reconstruction) | `forgecad skill install` | Reconstruct a parametric ForgeCAD model from an existing 3D CAD or mesh file such as STL, OBJ, 3MF, STEP, or STP; inspect the source asset directly, author real ForgeCAD geometry, and iteratively compare the candidate with `forgecad compare 3d`. |
 | [forgecad-blockout-model](/docs/skills/forgecad-blockout-model) | `forgecad skill install` | Create rough high-level ForgeCAD concept models from simple primitives to explore layout, proportions, motion, and part relationships without production detail. Use when asked for a quick model sketch, blockout, spatial mockup, or intuitive low-detail 3D concept. |
 | [forgecad-component-model](/docs/skills/forgecad-component-model) | `forgecad skill install` | Enforce the ForgeCAD Component Model when building multi-part assemblies. Parts build at origin, connectors position them, data flows down from parent. Use when building or reviewing any multi-file ForgeCAD project. |
-| [forgecad-high-level-spec](/docs/skills/forgecad-high-level-spec) | `forgecad skill install` | Write a high-level design document (HLD) for a model, mechanism, or assembly before detailed specification or coding. Use when starting a new design, rethinking an existing one, or when the user asks to spec out, plan, or think through a model at a high level. Works backwards from requirements — defines the problem, explores alternatives, records decisions. Produces a right-sized design document for review and iteration. |
 | [forgecad-image-replicator](/docs/skills/forgecad-image-replicator) | `forgecad skill install` | Build real ForgeCAD geometry from one or more reference images by treating images as evidence, inferring the object, then validating against both reference-matched and canonical views. |
-| [forgecad-lld](/docs/skills/forgecad-lld) | `forgecad skill install` | Write a Low-Level Design (LLD) for a CAD model — exact dimensions, constraints, parameters, and verification criteria. Use after a High-Level Design (HLD) exists and decisions are locked, or for simple parts that don't need an HLD. The detailed design document that code implements. |
 | [forgecad-make-a-model](/docs/skills/forgecad-make-a-model) | `forgecad skill install` | Create manufacture-realistic prototype ForgeCAD (.forge.js) models in the active CAD project. Handles file placement, invokes the forgecad skill for API guidance, and validates the result. |
 | [forgecad-model-grader](/docs/skills/forgecad-model-grader) | `forgecad skill install` | Analyze, verify, and grade ForgeCAD or CAD-as-code models against a user requirement, design brief, prompt, reference, or acceptance criteria. Use when asked to evaluate, judge, QA, benchmark, score, rate, or compare a CAD model; render it from multiple angles, run targeted inspections when needed, visually verify the evidence, and produce a 0-10 score with concise justification. |
-| [forgecad-prepare-prompt](/docs/skills/forgecad-prepare-prompt) | `forgecad skill install` | Turn a fuzzy physical product, mechanism, or CAD artifact request into a concrete manufacture-realistic prototype ForgeCAD build brief and a single master prompt for the modeling pass. Use when the engineering brief is incomplete, manufacturing/process choice is underspecified, or the work needs a specific operating story to avoid generic toy solutions. |
+| [forgecad-mujoco-verify](/docs/skills/forgecad-mujoco-verify) | `forgecad skill install` | Verify ForgeCAD MJCF exports in MuJoCo with real dynamics, contacts, root behavior, controls, required joint travel, and rendered evidence before calling a model simulation-ready. Use when making a ForgeCAD assembly sim-ready, debugging MJCF contacts, checking why a body falls through the floor, validating actuator motion, or proving a mechanism moved through the intended range. |
 | [forgecad-project](/docs/skills/forgecad-project) | `forgecad skill install` | ForgeCAD project CLI workflow — creating, managing, syncing projects and files on forgecad.io. Covers init, push, pull, file operations, member management, publishing, and sharing. |
 | [forgecad-reconstruction-benchmark](/docs/skills/forgecad-reconstruction-benchmark) | `forgecad skill install` | Solve ForgeCAD CAD reconstruction benchmark or RL episodes in a prepared workspace by rebuilding a visible reference asset as readable parametric ForgeCAD in the fixed submission path, using visual and geometric self-checks while respecting sandbox limits. |
 | [forgecad-render-inspect](/docs/skills/forgecad-render-inspect) | `forgecad skill install` | Run and interpret ForgeCAD inspection bundles for model verification. Use when asked to inspect a ForgeCAD model, analyze an inspection bundle, validate collisions, wall thickness, connectivity, floating bodies, sections, masks, depth, normals, or Zebra stripes. |
+| [forgecad-spec-by-walking-through-it](/docs/skills/forgecad-spec-by-walking-through-it) | `forgecad skill install` | Design a ForgeCAD model, mechanism, or assembly by fixing WHAT before HOW in a git-reviewed design document, validated by mentally operating the thing step by step. Covers fuzzy-request intake and process choice, high-level design (HLD), and low-level design (LLD). Use on "spec this out", "plan the design", "write the HLD/LLD", a vague build request that needs concrete decisions, or any moment the right move is a reviewable spec before code. |
 | [forgecad-visual-spec](/docs/skills/forgecad-visual-spec) | `forgecad skill install` | Turn a concrete ForgeCAD artifact, build brief, HLD, or existing model into builder-honest image prompts for AI image models. Use when the user wants visual-spec renders that show the final product while keeping mechanisms, seams, hardware, and build cues visible instead of drifting into concept art. |

package/dist/index.html

@@ -83,7 +83,7 @@
       * { 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-DaTMg3nH.js"></script>
+    <script type="module" crossorigin src="/assets/app-D6ccu2Xx.js"></script>
     <link rel="stylesheet" crossorigin href="/assets/app-CjsbDlb7.css">
   </head>
   <body>

package/dist/sitemap.xml

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