forgecad 0.10.4 → 0.11.0

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

@@ -1,145 +0,0 @@
-<!-- Generated by scripts/build-forgecad-skill.mjs — do not edit. Edit agent-skill-library/forgecad-design-spec/SKILL.md instead. -->
-
-# forgecad-design-spec
-
-Create a ForgeCAD design brief, HLD, or LLD before coding by walking through use, assembly, interfaces, decisions, and verification.
-
-| Field | Value |
-| --- | --- |
-| Installed by | `forgecad skill install` |
-| Source | `agent-skill-library/forgecad-design-spec/SKILL.md` |
-
----
-
-## Design Spec
-
-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-build-model` + `forgecad` → `.forge.js` |
-
-
-## Bundled Files
-
-- `references/default-profiles.md`
-- `references/master-prompt.md`

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

@@ -1,84 +0,0 @@
-<!-- Generated by scripts/build-forgecad-skill.mjs — do not edit. Edit agent-skill-library/forgecad-grade-model/SKILL.md instead. -->
-
-# forgecad-grade-model
-
-Grade a ForgeCAD or CAD-as-code model against a requirement, brief, prompt, reference, or acceptance criteria with evidence and a 0-10 score.
-
-| Field | Value |
-| --- | --- |
-| Installed by | `forgecad skill install` |
-| Source | `agent-skill-library/forgecad-grade-model/SKILL.md` |
-
----
-
-## Grade Model
-
-Grade the delivered model against the requirement, not against what could be fixed later. Never edit the model unless the user explicitly requests repairs — then record the baseline grade first, change, and re-grade.
-
-### Workflow
-
-1. **Extract the requirement** into a checklist, must-haves separate from nice-to-haves. If the brief is vague, grade the most reasonable literal interpretation and mark unverifiable items `Unknown`.
-2. **Run the model**: `forgecad run <model>.forge.js` (in the ForgeCAD repo use the local build, `node dist-cli/forgecad.js run ...`). If it fails to execute, stop and apply the caps.
-3. **Render** at least `iso`, `front`, `right`, `top` to a scratch dir; add views (back, bottom, close-up, section) when the model is asymmetric, hollow, mechanical, or likely to hide mistakes.
-4. **Open and look at every PNG** — never score from command output alone. Check silhouette, proportions, required features, part boundaries, interfaces, and whether the model reads as the requested artifact from more than one angle.
-5. **Inspect** whenever hidden internals, fit, wall thickness, or assembly behavior are central to the brief — grading without inspecting them caps the score. Delegate evidence choice, commands, and manifest reading to the `forgecad-inspect-model` skill. Findings (unexpected collisions, thin regions, floating bodies, wrong component counts) are evidence, not warnings to wave away.
-6. **Score**: fill the rubric, apply caps, give a final 0-10 in whole or `.5` increments. Unknowns count against the score.
-
-### Rubric
-
-| Dimension | Points | What To Look For |
-| --- | ---: | --- |
-| Requirement fit | 4 | Satisfies the stated must-haves, captures the intended object/function, no drift into a generic substitute. |
-| Geometric completeness | 2 | Correct silhouette, proportions, visible details, part boundaries, internal structure when required, no missing major components. |
-| Mechanical/manufacturing plausibility | 2 | Believable materials/process, real interfaces, clear load paths, fasteners/seats/clearances where needed, no impossible assembly. |
-| Validation health | 1 | Runs cleanly, renders from multiple views, targeted inspections reveal no major unaddressed issues. |
-| Code/model quality | 1 | Parametric clarity, readable organization, meaningful names, no debug junk, appropriate ForgeCAD APIs. |
-
-Anchors: 9-10 = evidence-backed match for the brief; 7-8 = recognizable and mostly complete, fixable gaps; 5-6 = main idea only; below 5 = broken or loosely related.
-
-### Evidence Caps
-
-Maximum scores, applied after the rubric:
-
-- Model does not execute: max `2`.
-- Executes but cannot be rendered: max `4`.
-- No rendered images visually inspected: max `5`.
-- Only one flattering view inspected: max `6`.
-- A must-have requirement is absent: max `6`.
-- Visually recognizable but physically impossible for the requested use: max `6`.
-- Internals, fit, walls, or assembly central to the brief but uninspected: max `7`.
-- Multi-part assembly violates the ForgeCAD component model — sibling imports, assembly-space coordinates inside parts, structural `translate()` placement, missing connector mates, or parent/child data flow confusion: max `7`; max `6` when the violation makes the assembly brittle or mechanically wrong.
-- Inspection finds unexpected collisions, floating bodies, critical thin walls, or wrong connectivity: max `6`; max `5` when the defect invalidates the main function.
-- Delivered as a finished product/prototype but presented with default flat lighting (no `scene()` rig), a generically colorful or material-false palette, or teaching-diagram styling: max `8`. Does not apply when the brief asks for a blockout or bare technical study.
-- Any score relying on an assumption the evidence cannot verify: mark it `Unknown`, never score above `8`.
-
-### Report Format
-
-```markdown
-Score: N / 10
-
-Requirement checklist:
-| Item | Result | Evidence |
-| --- | --- | --- |
-| ... | Pass/Partial/Fail/Unknown | render/inspection/file evidence |
-
-Evidence reviewed: run outcome; views inspected; inspection highlights.
-Why this score: decisive strengths and defects.
-Caps applied: list, or `None`.
-Next fixes: the 2-5 highest-leverage improvements.
-```
-
-### Grading Rules
-
-- A beautiful render with missing functional geometry is not a high score.
-- Grade the default returned model unless the user names a parameter set or variant.
-- No points for comments, labels, or intentions absent from the geometry.
-- Decorative screws, floating labels, and teaching-diagram callouts are not real mechanical interfaces.
-- For multi-part assemblies, require the component model: parts build locally at origin, expose connectors/metadata, the parent positions them, and inter-part data flows through parent props and returned metadata.
-- Cite which render or inspection finding drove the grade.
-- When comparing models, use identical checklist, cameras, inspection evidence, and caps for all.
-
-
-## Bundled Files
-
-- `agents/openai.yaml`

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

@@ -1,80 +0,0 @@
-<!-- Generated by scripts/build-forgecad-skill.mjs — do not edit. Edit agent-skill-library/forgecad-inspect-model/SKILL.md instead. -->
-
-# forgecad-inspect-model
-
-Select, run, and interpret ForgeCAD inspection evidence for collisions, sections, wall thickness, components, masks, depth, normals, surface continuity, and fit.
-
-| Field | Value |
-| --- | --- |
-| Installed by | `forgecad skill install` |
-| Source | `agent-skill-library/forgecad-inspect-model/SKILL.md` |
-
----
-
-## Inspect Model
-
-Use `forgecad inspect ...` when a shaded render is too ambiguous and you need structured evidence: a bundle directory with evidence PNGs plus a root `manifest.json` (or, for `inspect section`, a probe directory with `result.json`, `section.svg`, `section.png`). Inspection is not a substitute artifact: look inside with sections, masks, `--focus`/`--hide`, and transparency — never edit the model into a cutaway or exploded default to make inspecting easier. Output dirs: let `inspect` allocate its timestamped directory by default (repeated probes never collide); use `/tmp/<model>-inspect` for throwaway bundles, a project directory only for persistent artifacts.
-
-Routing: authoring/API questions → `forgecad` skill; creating a new model → `forgecad-build-model`.
-
-### Workflow
-
-1. **Identify the failure question.** What would make the model wrong: overlap, thin walls, hidden cavity failure, disconnected or accidentally fused bodies, floating parts, orientation artifacts, identity confusion?
-2. **Confirm the model executes.** If in doubt, run `forgecad run model.forge.js` first; add `--debug-imports` for suspect imports.
-3. **Pick ONE targeted evidence command** from the table below. `forgecad inspect evidence` lists everything available.
-4. **Summarize the manifest first**, then use `jq` against `manifest.json` for targeted follow-up. The helper ships beside this SKILL.md — invoke it skill-dir-relative; it accepts the bundle directory or a `manifest.json` path:
-
-   ```bash
-   python <this-skill-dir>/summarize_manifest.py /tmp/model-inspect
-   ```
-
-5. **Inspect the PNGs, not only the JSON.** View identity/context images first, then the risk evidence's view, then orthogonal cameras (`front`, `right`, `top`) when iso hides the issue, sections only when internals matter. In automation, resolve file paths through the manifest — custom cameras break canonical filenames.
-6. **Isolate intentional overlaps** with `--focus "A,B"` or `--hide "C"` so the remaining report stays meaningful.
-7. **Treat findings as model bugs**: unexpected collisions, critical thin regions, high unresolved thickness area, wrong component counts, floating bodies, or surprising gaps mean fix the model and reinspect.
-8. **Report honestly.** Include the exact command, bundle path, manifest highlights, and the PNG views actually inspected. Never claim geometry is verified if you only ran `forgecad run`.
-
-### Evidence Selection
-
-| Question | Evidence command |
-|----------|------------------|
-| Quick visual sanity | `inspect visual image` |
-| Kinematic rig, joints, axes, and links | `inspect visual rig` |
-| Object naming and identity | `inspect visual objects` |
-| Exact local section measurement, bore widths, rib thickness through a chosen line | `inspect section --ray ...` |
-| Hidden internals, cavities, pockets, screw paths, captured components | `inspect sections at\|stack\|sample` |
-| Multi-part interference, fit checks, ghost parts, moving clearances | `inspect fit interference` |
-| Printability, shell walls, ribs, bosses, snaps, slots | `inspect manufacture thickness` plus `inspect sections at\|stack\|sample` when internals matter |
-| Parts without a mesh-contact path to the ground | `inspect physical floating` |
-| Accidental fusion, connected solids | `inspect physical components` |
-| Air gaps between physical components | `inspect physical gaps` |
-| Surface orientation, occlusion, faceting, strange protrusions | `inspect visual depth` or `inspect visual normals` |
-| Loft, fillet, skin, and sweep surface continuity | `inspect surface zebra` or `inspect visual normals` |
-| Reference-vs-candidate reconstruction comparison | `inspect compare overlay --with reference.3mf` |
-
-### Section Probe + Replay
-
-The agent-native measure-then-recheck loop:
-
-```bash
-forgecad inspect section model.forge.js --plane yz --ray bore:-20,0:20,0
-forgecad inspect replay outputs/inspect/<probe>/result.json --source candidate.forge.js
-```
-
-The probe's `result.json` field contract (frames, rulers, gaps, replaySpec) is documented in the forgecad skill's `docs/guides/inspection-bundles.md`.
-
-### Misread Traps
-
-- Face-touching is not a collision; collision findings are positive-volume overlaps.
-- Gray/unresolved thickness area means the evidence is incomplete, not that the model is safe.
-- Distance/gap figures are bbox-gap metrics between components, not closest-surface distances.
-- Depth, normals, and zebra are visual aids (heatmap, camera-view normals, stripe shader), not exact measurements or curvature proofs.
-- Resolve mask colors through the manifest's object list, never by object order.
-
-### Reference
-
-Bundle/manifest contract, evidence semantics, and current limits: the forgecad skill's `docs/guides/inspection-bundles.md`. CLI flags and command tree: its `docs/CLI.md`.
-
-
-## Bundled Files
-
-- `summarize_manifest.py`

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

@@ -1,78 +0,0 @@
-<!-- Generated by scripts/build-forgecad-skill.mjs — do not edit. Edit agent-skill-library/forgecad-verify-mujoco/SKILL.md instead. -->
-
-# forgecad-verify-mujoco
-
-Verify a ForgeCAD MJCF export in MuJoCo with dynamics, contacts, controls, joint travel, and rendered evidence before calling it simulation-ready.
-
-| Field | Value |
-| --- | --- |
-| Installed by | `forgecad skill install` |
-| Source | `agent-skill-library/forgecad-verify-mujoco/SKILL.md` |
-
----
-
-## Verify MuJoCo
-
-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-inspect-model`; model authoring/API questions -> `forgecad`; building a new model -> `forgecad-build-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-skill/library/forgecad-design-spec/SKILL.md

@@ -1,132 +0,0 @@
----
-name: forgecad-design-spec
-description: Create a ForgeCAD design brief, HLD, or LLD before coding by walking through use, assembly, interfaces, decisions, and verification.
-forgecad-public: true
----
-
-# Design Spec
-
-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-build-model` + `forgecad` → `.forge.js` |

package/dist-skill/library/forgecad-design-spec/references/default-profiles.md

@@ -1,99 +0,0 @@
-# Family Intake Profiles
-
-Family-scoped starter anchors for closing missing inputs — temporary engineering anchors, not truth, and never reused across families.
-
-## Process Selection By Family
-
-Never default to 3D printing. Choose the process stack from artifact family, load path, scale, safety expectations, material properties, quantity/iteration needs, and operating story. Typical honest stacks:
-
-- rideable vehicles: metal/composite/wood structure, urethane/rubber wheels, bearings, brakes, fasteners, purchased safety-critical hardware
-- furniture: wood, sheet goods, tube, metal brackets, conventional joinery; printed parts only for honest secondary details
-- enclosures: injection molding, sheet metal, CNC, thermoforming, or printing depending on quantity, ruggedness, serviceability
-- fixtures: machined, laser-cut, welded, printed, or hybrid with standard clamps/pins/fasteners
-- small mechanisms: hybrid printed/machined/sheet parts plus purchased pivots, shafts, bearings, springs, fasteners, motors, electronics
-
-## Family: Grippers And Small Mechanisms
-
-Use for: robot grippers, articulated fingers, small pick-and-place tools, manipulators, end-effectors.
-
-Family questions: delicate / mixed-general / rigid-tool-like handling? size closer to desk, household, or workshop objects? cheapest / balanced / performance-first hardware?
-
-Duty bands:
-
-- `light-duty` — object mass `0.05-0.15 kg`, opening/feature band `30-60 mm`; small servo, compact lightweight prototype members (printed, machined, or laser-cut per the selected posture)
-- `general-duty` — object mass `0.20-0.50 kg`, opening `60-120 mm`; standard metal-gear servo or NEMA17-class solution, M3/M4 fasteners, inserts, pins, bearings where honest
-- `sturdy-duty` — object mass `0.50-1.00 kg`, opening `100-180 mm`; stronger shafts, bearings, more metal reinforcement; downgrade final certainty unless the mechanism stays simple
-
-### Subtype: Dexterous Finger / Humanoid Hand Module
-
-Use for robot/dexterous/anthropomorphic/tendon/prosthetic-style fingers or one module of a robot hand.
-
-Story shape: a hand/manipulation program at an invented robotics org, a concrete module revision (`F2 index finger`, `Rev-C palm-mount finger`), a go/no-go or demo gate, a named test rig, real deployment stakes. Seed: "Helix Handworks is preparing the F2 index-finger module for its DEX-07 warehouse-pilot go/no-go review. The finger must bolt into Palm Mule V3, route a Bowden tendon through the MCP base without rubbing the housing wall, survive a 1,000-cycle curl test on Rig-3, and expose pivot/wear surfaces before the customer demo cell is frozen."
-
-Starter assumptions for `general-duty` / `medium` / `balanced`:
-
-- envelope: adult index-finger scale, roughly `95-115 mm` long, `18-24 mm` wide, `16-24 mm` thick
-- joints: MCP/PIP/DIP-like flexion chain with hard stops and clearance checks through curl
-- motion target: MCP `0-75 deg`, PIP `0-90 deg`, DIP `0-65 deg`
-- actuation: tendon or Bowden cable flexion with passive elastic/spring return unless the user asks for independent motors
-- hardware: metal pivot pins or shoulder screws, bushings or bearing surfaces, serviceable tendon anchor, replaceable fingertip/contact pad, palm mounting datum
-- validation: full-range curl sweep, tendon rub check, pivot wear check, fingertip contact load path, base-mount stiffness, assembly access
-
-## Family: Fixtures, Jigs, And Holders
-
-Use for: drill guides, work-holding fixtures, camera/sensor mounts, brackets, repeatable positioning tools.
-
-Family questions: positioning, clamping, or repeated handling? palm-, hand-, or bench-size? speed of build vs stiffness?
-
-Non-obvious anchors: at `general-duty`, put inserts, metal pins, or off-the-shelf fasteners where wear concentrates; at `sturdy-duty` (repeated clamping, workshop abuse), printed geometry must be backed by thicker sections, inserts, metal rails, or replaceable wear faces.
-
-## Family: Enclosures And Electronics Housings
-
-Use for: PCB enclosures, instrument cases, sensor housings, covers and shells.
-
-Family questions: one PCB, hand-sized stack, or bench device? passive venting, fan support, or dust protection? aesthetics, serviceability, or ruggedness?
-
-Non-obvious anchors: at `general-duty`, a removable lid with real fastening (inserts) and clearance for wiring/service loops; at `sturdy-duty`, thicker walls, boss reinforcement, connector strain protection, and a sealing strategy.
-
-## Family: Furniture And Load-Bearing Structures
-
-Use for: tables, shelves, stands, stools, structural frames.
-
-**Caution:** human-bearing or safety-critical structures usually end `BEST-EFFORT BUILD CANDIDATE` unless there is real structural reasoning, conservative geometry, and honest material limits.
-
-Family questions: decorative / light household / real workshop use? side-table, desk, or bench span? will it ever support a person, heavy tools, or repeated impact?
-
-Non-obvious anchors: at `general-duty`, real attention to leg stiffness, racking resistance, and joint reinforcement; at `sturdy-duty`, stronger joinery, thicker members, triangulation/bracing. Wood, sheet goods, tube, and metal hardware are first-class BOM items; printed parts only where honest (brackets, templates, feet, cable features, corner blocks).
-
-## Family: Chassis And Mobile Robot Structures
-
-Use for: wheeled robot chassis, tracked platforms, sensor carts, mobile bases. **Not** for human-ridden scooters, bikes, skateboards, or mobility devices — those route to Human Vehicles below.
-
-Family questions: indoor smooth, mixed home, or rough workshop floor? tiny robot, small rolling base, or larger platform? runtime / price / ruggedness priority?
-
-Non-obvious anchors: at `general-duty`, strengthen wheel mounts, motor mounts, and battery restraint; at `sturdy-duty`, more metal shafts/bearings/real fastening and increased skepticism about fully printed load paths.
-
-## Family: Human Vehicles And Rideable Product Forms
-
-Use for: kick scooters, bicycles, skateboards/longboards, carts, strollers, dollies, mobility-adjacent platforms — anything a person stands on, rides, steers, brakes, or leans on.
-
-**Caution:** rideables usually end `BEST-EFFORT BUILD CANDIDATE` unless there is real structural analysis, conservative geometry, braking/steering reasoning, and explicit test limitations. Never present a rider-rated design as safe without validation.
-
-Family questions: visual CAD study, manufacture-realistic prototype candidate, or explicitly printable toy/model? child-, adult-, display-, or cargo-scale? steering, braking, folding, suspension, or static form only?
-
-Anchors: `light-duty` = display/toy/non-ridden study, printed cosmetic parts acceptable. `general-duty` = aluminum/steel tube or frame, machined or cast fork/dropout features, wood/composite/aluminum deck, urethane/rubber wheels, real bearings, axles, grip tape, purchased brake/steering hardware. `sturdy-duty` = conservative metal/composite structure, triangulation, large bearing interfaces, replaceable wear parts; downgrade certainty unless structural checks and a real test plan are explicit.
-
-Manufacturing: primary load paths in metal tube/plate/extrusion or wood/composite — never printed unless the user explicitly requested a printed demonstration model. Rolling interfaces purchased (wheels, bearings, axles, spacers, bushings); contact/wear interfaces in urethane/rubber, grip tape, replaceable pads. Printed parts only for cosmetic covers, cable guides, templates, fit-check models, or low-load accessory brackets.
-
-## If No Family Fits
-
-Do not force a nearby family. Name the nearest family, state the mismatch, and build a custom intake brief with 2-4 artifact-specific levers.
-
-## When Printing Is Selected
-
-Only when the artifact actually includes printed parts:
-
-- structural printed parts: PETG by default; PLA allowed for prototypes/fit checks
-- nozzle `0.4 mm`, layer height `0.2 mm`
-- threaded service joints: heat-set inserts where repeated opening is expected
-- sliding/rotating or wear-heavy interfaces: pins, bushings, bearings, or sacrificial wear parts — never raw printed rubbing unless intentionally low-duty