forgecad 0.9.5 → 0.9.7

package/dist-skill/library/forgecad-make-a-model/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: forgecad-make-a-model
-description: Create new ForgeCAD (.forge.js) models in the active CAD project. Handles file placement, invokes the forgecad skill for API guidance, and validates the result.
+description: 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-public: true
 ---
 
@@ -8,6 +8,17 @@ forgecad-public: true
 
 Create new ForgeCAD models in the user's active ForgeCAD project.
 
+## Default Output Standard
+
+Unless the user explicitly asks for a rough blockout, toy, pure visual study, mass-production release package, or specific manufacturing process, the output is a **manufacture-realistic prototype**.
+
+That means the model should look and behave like a serious prototype someone could fabricate, buy parts for, assemble, inspect, and iterate in a real shop or product lab. It is not a casual concept sketch, not a universal 3D-printing exercise, and not a claim of certified production readiness.
+
+- Choose processes that fit the artifact: machined, sheet-metal, tube, wood/composite, laser-cut, molded-look prototype, printed, or hybrid purchased-hardware construction as appropriate.
+- Include prototype-real features: wall thickness, fastener stacks, bosses, ribs, flanges, bends, seats, bushings, gaskets, cable exits, service access, toleranced clearances, and believable purchased parts.
+- Use production cues only when they help prototype realism. Do not invent expensive production tooling details, certification claims, or safety ratings unless the user asked for that level.
+- If the user asks for `production-realistic`, push toward manufacturing DFM and production-intent materials. If they ask for `printable`, make the selected printed parts honest. If they ask for `visual-CAD`, keep it clearly visual rather than pretending it is build-ready.
+
 ## File Placement
 
 All new `.forge.js` files go under the date-based directory structure:
@@ -35,6 +46,7 @@ Use today's date for the directory. Use the user's current ForgeCAD project when
 1. Load the ForgeCAD skill — always invoke the `forgecad` skill first to get API docs and authoring guidance. Read at minimum the Core API reference. If any two parts are intended to touch or mate in the final model, read the positioning guide immediately and default to connectors + `matchTo()`.
 2. Create the directory — `mkdir -p YYYY/MM/DD/[folder]` as needed.
 3. Write the model — create the `.forge.js` file(s) following ForgeCAD conventions:
+   - Treat the default build profile as `manufacture-realistic prototype`; choose and encode the artifact's manufacturing/process cues before adding styling detail
    - Declare `param()` / `boolParam()` for all tunable dimensions
    - If the model is split across files, use `main.forge.js` as the primary entry point, import renderable parts from neighboring `.forge.js` files, and keep only pure helpers/constants in plain `.js` modules
    - When there are multiple versions of the same object, expose the version as a choice parameter and render one selected version at a time
@@ -47,12 +59,12 @@ Use today's date for the directory. Use the user's current ForgeCAD project when
    - Return the final geometry (single shape, array, or named objects array)
    - Treat `fillet(shape, r)` and `chamfer(shape, r)` as experimental edge treatments: Manifold can produce incorrect results and OCCT can be very slow. Prefer simpler primitive profiles, lower segment counts, targeted edge selectors, and inspection before relying on the result.
 4. Validate — run `forgecad run <file>` to check for errors. For multi-file projects, always validate `main.forge.js`.
-5. Verify geometry — render the result, run `forgecad run --connectivity` when the model has multiple returned objects or visible attachments, and run `forgecad render inspect` with the relevant channels for the task (see Final Acceptance Gate and Render-Verify Loop below). For multi-file projects, render and inspect `main.forge.js`.
+5. Verify geometry — render the result, run `forgecad run --connectivity` when the model has multiple returned objects or visible attachments, run `forgecad debug assembly --fail-on warning` when the script uses `assembly()`, run `forgecad inspect mechanical-integrity <project-or-file> --collisions` before sharing generated mechanical work, and run `forgecad render inspect` with the relevant channels for the task (see Final Acceptance Gate and Render-Verify Loop below). For multi-file projects, render and inspect `main.forge.js`.
 
 ## Manufacturing Process Is Not Assumed
 
 Do not interpret every ForgeCAD model as a printable object.
-Choose the manufacturing/process cues that fit the artifact unless the user explicitly asked for a specific process.
+Choose the manufacturing/process cues that fit the artifact unless the user explicitly asked for a specific process. A manufacture-realistic prototype can be CNC-machined, bent sheet, tube-and-plate, wood/composite, molded-look low-volume, printed, or hybrid; the right answer depends on the load path and operating story.
 
 - For rideable products such as scooters, bikes, skateboards, carts, or mobility-adjacent devices, use realistic metal/composite/wood structural members, purchased wheels/bearings/axles/brakes/grips, and standard hardware unless the user asked for a printable toy/model.
 - For furniture and load-bearing structures, consider wood, sheet goods, tube, metal brackets, conventional joinery, and printed parts only where they are honest secondary components.
@@ -104,6 +116,52 @@ Do not reveal hidden structure by permanently cutting away the production geomet
 
 When internals are hidden by the final exterior, verify them with exploration tools instead of changing the artifact: render underside or alternate camera views, use `render inspect` section channels, use viewer-only cut planes or explode controls, temporarily make a shell transparent, or add named ghost objects for fit checks. Those views are diagnostic/presentation modes; they must not replace the real model unless the user explicitly asked for a cutaway teaching model.
 
+## Mechanical Assembly Contract
+
+For mechanical models, a ForgeCAD script is not done when it merely looks assembled. Every visible piece must have a believable physical reason to be where it is: fused material, contact faces, a screw stack, a pin in a bore, a tab in a slot, a gasket on a land, a bearing in a seat, a cable in a channel, or a named intentional ghost.
+
+- For bespoke fixed assemblies that do not match an existing `lib.*` helper, start from `examples/api/static-assembly-connectors.forge.js`: build each part in local coordinates, pick one root part, place every other touching part with `matchTo()`, and verify the mate with `verify.connectorDistance(...)`. Do not use final `translate()` calls as assembly contracts.
+- If you use `assembly().addPart()`, do not treat `addFixed()`, `addRevolute()`, or `addPrismatic()` with a manual `frame: Transform.identity().translate(...)` as a physical contract. Manual joint frames are acceptable only as a temporary scaffold. Before delivery, convert mating interfaces to connectors with `connect()` / `match()` where the interfaces physically meet, or prove the manual joint with `forgecad debug assembly --fail-on warning` and documented geometry.
+- A named assembly part should not contain unintentional disconnected bodies. If a "cover plate" contains floating pull tabs, loose screw heads, or a separate gasket, either boolean-join the manufactured features, model the fasteners/seals as separate named parts, or provide the receiving holes/lands that explain the separation.
+- Screws are not decoration. A screw needs a clearance/counterbore in the cover, a receiving threaded hole/boss or through stack in the parent, enough material around both, and aligned axes from one shared bolt pattern.
+- Handles and levers need a load path. Model the hub-to-arm connection, pivot pin/bore, thrust washers or shoulders, stops/detents where relevant, and the connected follower/contact surface. A handle tangent to a hub is a failed mechanism.
+- Covers, doors, cartridges, and service panels need seats. Model ledges, gasket grooves, bosses, snap hooks, tabs, or hinge barrels, then show how the removable part is retained.
+- Cables, wires, and tubes need receiving geometry. Model a gland, grommet, clamp, socket, ferrule, routed channel, or hose barb; do not let a cylinder end in open space.
+- Purchased loose parts may remain separate bodies, but they should be named as purchased hardware or consumables and should sit in believable sockets, bores, races, guides, or fastener stacks.
+- Encode interface intent with `verify.*`, not only comments. Use `verify.clearanceBetween("cover is seated on gasket", cover, gasket, -0.01, 0.05)` for contact/seated fits and clearance bands, `verify.minClearance(...)` or `verify.notColliding(...)` for keep-out/running gaps, and `verify.connectorDistance(...)` for connector-authored mates. Part counts and generic dimensions are useful supporting checks, but they do not prove an interface by themselves.
+
+For ordinary removable covers, prefer `lib.boltedServiceCover(...)` before hand-placing plates, tabs, screw heads, gaskets, and holes. It creates the parent ledge, gasket, cover plate with fused pull tabs, shared bolt pattern, and installed screws as one mechanically accountable interface.
+
+For electronics boxes, backplates, service-stack housings, and camera/monitor enclosures, prefer `lib.datumEnclosureAssembly(...)` before independently placing panels, ribs, bosses, ports, covers, and screws. It creates the tray, ledges, standoffs, ribs, service port, gasket, cover, and screws from one shared datum system.
+
+For PCB-mounted terminal blocks, thermostat backplates, control boards, and wire-entry electronics panels, prefer `lib.pcbTerminalBlockAssembly(...)` before placing a loose green block near a board or cover. It creates the backplate, fused standoffs, PCB mounting screws, PCB pin holes, terminal pins, and seated purchased terminal block from one shared datum system.
+
+For snap-retained covers, cartridges, small clasps, and housings, prefer `lib.snapLatchCoverAssembly(...)` before drawing decorative snap tabs. It creates latch windows, underside catch lands, fused snap hooks, barbs, and clearance checks so the cover is retained by real geometry.
+
+For ordinary pinned handles, cam levers, release levers, and latch arms, prefer `lib.pinnedLeverAssembly(...)` before hand-placing a hub, arm, washers, and pin. It creates a fused lever body, aligned pivot bore, retained pin, thrust washers, support land, and low stop land as one mechanically accountable pivot stack.
+
+For trunnions, side knobs, adjustable pivots, and clamp shafts, prefer `lib.retainedShaftAssembly(...)` before hand-placing rods, washers, and knobs. It creates bored support cheeks, a through shaft, thrust washers, knobs, retaining heads, and shared bore dimensions as one mechanically accountable stack.
+
+For thumb screws, desk clamps, vise screws, capo pressure screws, and small fixture hold-downs, prefer `lib.thumbScrewClampAssembly(...)` before hand-placing a knob, screw cylinder, pressure pad, and bracket jaw. It creates the C-frame, threaded boss/bore, captive pressure pad, hand knob, and seated workpiece contact from one shared datum system.
+
+For drawer slides, quick-release plates, and guided linear carriages, prefer `lib.capturedLinearSlide(...)` before hand-placing rails and a block. It creates a U-channel rail with return lips, end stops, a captured carriage, and explicit travel/clearance dimensions.
+
+For pump cartridges, filter cassettes, battery cartridges, skeg cassettes, and removable slide-in modules, prefer `lib.capturedCartridgeGuideAssembly(...)` before placing a loose tray and block. It creates return lips, a rear stop, a captured cartridge flange, pull tab, insertion travel, and explicit clearance dimensions.
+
+For molded flexible battery doors, sample covers, blister latches, and polypropylene-style service flaps, prefer `lib.livingHingeCoverAssembly(...)` before drawing two plates with a decorative hinge strip. It creates one fused molded strip with fixed leaf, thin flexible web, moving cover leaf, pull lip, snap barb, catch land, and web-thickness checks.
+
+For doors, barn-door leaves, lids, locket leaves, and small hinged access panels, prefer `lib.knuckledHingeAssembly(...)` before hand-placing barrels and a pin. It creates alternating fused knuckles, two leaves, a shared bore, and a retained pin as one mechanically accountable hinge.
+
+For crank links, damper rod ends, crossheads, and clevis-yoke pivots, prefer `lib.clevisPinJointAssembly(...)` before hand-placing an eyelet and pin. It creates bored clevis ears, a captured center link eye, a rear bridge, and a retained pin as one mechanically accountable load path.
+
+For bearings, rollers, burr cartridges, spindle supports, and purchased radial bearings, prefer `lib.seatedBearingAssembly(...)` before hand-placing a ring and shaft near a block. It creates a bored housing, counterbore pocket, bearing shoulder, seated bearing, shaft, collars, and shared clearance dimensions as one mechanically accountable support.
+
+For cables, wires, hoses, pump tubes, and panel pass-throughs, prefer `lib.cableGlandAnchorAssembly(...)` before hand-placing a loose cylinder near a wall. It creates the panel clearance hole, hollow gland body, compression nut, and routed cable/tube as one mechanically accountable pass-through.
+
+For routed cables, wires, hoses, pump tubes, and sensor leads that run along a surface, prefer `lib.routedTubeClipAssembly(...)` before drawing a tube that floats between endpoints. It creates a base panel, saddle clip bores, clip screw holes, installed screws, and the retained tube route from one shared datum system.
+
+For fluid hoses, pump inlets/outlets, filter ports, and lab tubing, prefer `lib.hoseBarbPortAssembly(...)` before drawing a tube that stops at a block. It creates the bored receiver, raised boss, hollow barbed fitting, installed hose, and clamp band as one accountable hose-port interface.
+
 ## Final Geometry Should Be Physically Plausible
 
 Treat each returned part as real matter occupying space. In the final build, separate parts should not intersect unless the intersection is the actual manufacturing intent, such as a welded/fused region, an overmolded insert, or a boolean-unioned solid that is no longer a separate part.
@@ -112,7 +170,9 @@ Do not use final interpenetration as a placement shortcut. For joints and interf
 
 Temporary collisions during construction are fine when they are part of how the model is made or verified: oversized cutter solids before `difference()`, overlapping primitives before `union()`, transparent ghost parts for fit checks, or exploratory joint layouts. Those temporary bodies should be consumed, hidden, named as ghosts, or isolated with inspection filters so final collision findings stay meaningful.
 
-Before delivery on any multi-part, internal, or mechanical model, run the collision inspection, read the collision channel PNGs, and check `manifest.json`. Fix unexpected overlaps. If a collision is intentional, document it in the model naming/comments or isolate that inspection with `--focus` / `--hide` so the remaining collision report proves the final assembly is real.
+If a final overlap is real manufacturing intent, document the exact visible object pair with `verify.intentionalOverlap("rubber grip is overmolded on handle core", rubberGrip, handleCore, "overmolded bonded grip")`. Use this only for welded, fused, overmolded, cast-in, potted, or bonded matter. The mechanical-integrity gate honors it only when the same visible object pair has a confirmed exact collision; unused or non-visible declarations still fail.
+
+Before delivery on any multi-part, internal, or mechanical model, run the collision inspection, read the collision channel PNGs, and check `manifest.json`. Fix unexpected overlaps. If a collision is intentional, declare the exact visible pair with `verify.intentionalOverlap(...)` or isolate that inspection with `--focus` / `--hide` so the remaining collision report proves the final assembly is real.
 
 ## Final Acceptance Gate
 
@@ -126,6 +186,24 @@ Before telling the user the model is done, prove both technical validity and vis
 
    The reported component count must match the design intent. Treat unexpected islands, accidental fusion, or bbox-only "touching" that does not make physical sense as model bugs.
 
+   If the script uses `assembly()`, also run:
+
+   ```bash
+   forgecad debug assembly model.forge.js --fail-on warning
+   ```
+
+   Fix warnings about multiple roots, manual joint contracts, disconnected bodies inside parts, unused connectors, solve warnings, and collisions before delivery. If a warning is truly intentional, rename the part or add a short code comment so a reviewer can see the physical reason.
+
+   For generated mechanical projects or batches, also run:
+
+   ```bash
+   forgecad inspect mechanical-integrity . --collisions
+   ```
+
+   This is the shareability gate. It fails on missing `verify.*` checks, missing mechanical-interface verification, fragmented named groups, uncontracted manual assemblies, positive-volume object collisions, timeouts, and runtime failures. Do not share a generated mechanical model while this gate is red unless the user explicitly asked for a rough concept/blockout.
+
+   The model should include at least one verification that proves a mechanical interface, not just object count. Prefer checks such as `verify.clearanceBetween("bearing is seated in pocket", bearing, housing, -0.01, 0.1)`, `verify.minClearance("carriage clears rail", carriage, rail, 0.15)`, `verify.notColliding("cover screw clears parent hole", screw, parent)`, or `verify.connectorDistance("leg connector is seated", bench, "Rail.leg_0", "Leg0.head", 0, 0.01)`.
+
 2. Run a collision bundle and read both the manifest and images:
 
    ```bash
@@ -240,13 +318,14 @@ return [
 
 This immediately reveals: does it fit? Does it collide with walls? Does the shaft clear the opening?
 
-### Use console.log for dimension checks
+### Use verify for acceptance, console.log for traces
 
-Print derived dimensions and clearances to verify arithmetic before rendering:
+Use `verify.*` for dimensions and clearances that decide whether the model is acceptable. Use `console.log()` only for explanatory traces that help you read the run output.
 
 ```js
-console.log("wall remaining:", ((outerW - slotW) / 2).toFixed(1));  // must be > 0
-console.log("hole clearance from edge:", (flangeW/2 - holeX - holeDia/2).toFixed(1));
+verify.greaterThan("wall remains around slot", (outerW - slotW) / 2, 1.6);
+verify.greaterThan("hole clears flange edge", flangeW / 2 - holeX - holeDia / 2, 2.0);
+console.log("wall remaining:", ((outerW - slotW) / 2).toFixed(1));
 ```
 
 Output appears under "Script output:" in `forgecad run`.

package/dist-skill/library/forgecad-prepare-prompt/SKILL.md

@@ -1,12 +1,12 @@
 ---
 name: forgecad-prepare-prompt
-description: Turn a fuzzy physical product, mechanism, or CAD artifact request into a concrete 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.
+description: 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-public: true
 ---
 
 # Prepare ForgeCAD Prompt
 
-Use this skill before modeling when the user wants something physically real, manufacturing-aware, and buildable, but their request sounds like:
+Use this skill before modeling when the user wants something physically real, manufacturing-aware, and buildable as a manufacture-realistic prototype, but their request sounds like:
 
 - "make me a robot gripper"
 - "design a real mechanism"
@@ -25,6 +25,10 @@ Choose the manufacturing/process stack from the artifact family, load path, scal
 For example: scooters, bikes, skateboards, and rideable vehicles usually point toward metal/composite frames, wood/composite decks, urethane/rubber wheels, bearings, brakes, and standard hardware; furniture often points toward wood, sheet goods, tube, metal brackets, or conventional joinery; enclosures may point toward injection molding, sheet metal, CNC, or printing depending on quantity and ruggedness; fixtures may be machined, laser-cut, welded, printed, or hybrid.
 If the user asks for "printable", "3D printed", "laser cut", "CNC", or another process, honor that process while still warning when it is unsafe or dishonest for the duty.
 
+The default output posture is **manufacture-realistic prototype** unless the user asks for a different posture.
+This means a serious prototype build candidate with real manufacturing cues, purchased-part boundaries, assembly logic, and validation loops. It is stronger than a visual concept or hobby sketch, but it does not claim final production tooling, certification, rider safety, medical compliance, or release-ready DFM.
+Use `production-realistic` only when the user wants production intent, `printable` only when printing is actually the selected process, and `visual-CAD` only for visual/form studies.
+
 Do not let the modeling prompt sound like a casual hobby sketch when the requested artifact belongs to a serious product domain.
 Give the model a specific operating story: a named company or lab, named program, named prototype/revision, review moment, test setting, and concrete reason the part matters.
 If the user did not provide this story, invent plausible non-famous names and details.
@@ -61,6 +65,7 @@ By the end of this skill, there should be:
 - an artifact family classification
 - an assumption bundle with units
 - a clear build profile and manufacturing/process stack
+- a stated output posture, defaulting to manufacture-realistic prototype unless the user chose otherwise
 - a specific operating story
 - a motion / load / size target
 - a BOM boundary
@@ -124,8 +129,9 @@ By the end of this skill, there should be:
 
 4. Choose manufacturing/process posture.
    Treat process selection as part of the brief.
-   Use `production-realistic`, `prototype-realistic`, `printable`, `visual-CAD`, or a more specific process such as `sheet-metal`, `CNC-machined`, `laser-cut`, `welded tube`, `injection-molded`, `cast`, or `hybrid purchased-hardware`.
-   Default to the posture that is honest for the artifact rather than the easiest CAD surface to make.
+   Default to `manufacture-realistic prototype`.
+   Use `production-realistic`, `prototype-realistic`, `printable`, `visual-CAD`, or a more specific process such as `sheet-metal`, `CNC-machined`, `laser-cut`, `welded tube`, `injection-molded`, `cast`, or `hybrid purchased-hardware` only when the brief justifies that more specific posture.
+   Choose the posture that is honest for the artifact rather than the easiest CAD surface to make.
 
 5. Pick qualitative levers, not raw numbers.
    Start from:
@@ -141,7 +147,7 @@ By the end of this skill, there should be:
    - for a gripper: object style, opening band, cost/performance posture
    - for a table: use style, span band, load style
    - for an enclosure: electronics size, ruggedness, cooling posture
-   - for an underspecified product: production-realistic, prototype-realistic, printable, or visual-CAD posture
+   - for an underspecified product: manufacture-realistic prototype, production-realistic, printable, or visual-CAD posture
 
 7. Convert choices into an engineering brief.
    The brief must include:
@@ -151,6 +157,7 @@ By the end of this skill, there should be:
    - production reason
    - test setting
    - what generic output would miss
+   - output posture, defaulting to manufacture-realistic prototype unless changed by the user
    - intended objects / loads
    - rough size envelope
    - motion style and degrees of freedom
@@ -184,7 +191,7 @@ Good:
 - "Which target feels closest: a light desk demo, a useful hobby tool, or a sturdier bench mechanism?"
 - "Will it mostly handle soft/light things, mixed household parts, or rigid/tool-like objects?"
 - "Should we bias for cheapest parts, balanced practicality, or stronger hardware?"
-- "Should this be production-realistic, prototype-realistic, printable, or just a visual CAD study?"
+- "Should this be a manufacture-realistic prototype, production-realistic, printable, or just a visual CAD study?"
 - "Is this more like a gripper, a fixture, an enclosure, a chassis, or furniture?"
 - "Will the table mostly hold decor, laptop-and-books, or workshop abuse?"
 
@@ -201,6 +208,7 @@ If the user says "I don't know" or gives only a broad goal:
 - infer the nearest artifact family from the request
 - invent a specific operating story for the artifact
 - infer the manufacturing/process stack from the artifact family and operating story
+- default the output posture to `manufacture-realistic prototype`
 - choose `general-duty`
 - choose `medium`
 - choose `balanced`

package/dist-skill/library/forgecad-prepare-prompt/references/default-profiles.md

@@ -16,7 +16,7 @@ They are temporary engineering anchors used only when the user has not provided
 
 Use these across families before translating into numbers:
 
-- manufacturing posture: infer unless specified; common values are `production-realistic`, `prototype-realistic`, `printable`, and `visual-CAD`
+- manufacturing posture: default to `manufacture-realistic prototype` unless specified; common override values are `production-realistic`, `prototype-realistic`, `printable`, and `visual-CAD`
 - duty level: `light-duty`, `general-duty`, `sturdy-duty`
 - scale level: `compact`, `medium`, `large`
 - cost posture: `cheapest`, `balanced`, `performance-first`
@@ -29,6 +29,8 @@ Do not use 3D printing as the universal default.
 Choose the process stack from the artifact family, load path, scale, safety expectations, material properties, quantity/iteration needs, and operating story.
 Only use print defaults when the user explicitly requested printing or the selected process stack includes printed parts.
 
+The default posture is `manufacture-realistic prototype`: a credible prototype build candidate with real materials, real purchased parts, plausible fabrication routes, serviceable interfaces, and validation checks. It should be manufacturable enough for a prototype review, but it should not claim final production tooling, certification, or release readiness unless the user asks for that stronger bar.
+
 Examples:
 
 - rideable vehicles: metal/composite/wood structure, urethane/rubber wheels, bearings, brakes, fasteners, and purchased safety-critical hardware
@@ -274,7 +276,7 @@ Do not make rideable load paths printed by default.
 
 ### Family Questions
 
-- Is this a visual/product CAD study, a prototype-realistic build candidate, or a specifically printable toy/model?
+- Is this a visual/product CAD study, a manufacture-realistic prototype build candidate, or a specifically printable toy/model?
 - Is it for child-scale, adult-scale, display-scale, or cargo/utility scale?
 - Does it need steering, braking, folding, suspension, or only static product form?
 
@@ -288,7 +290,7 @@ Do not make rideable load paths printed by default.
 
 `general-duty`
 
-- adult product form or prototype-realistic scooter/bike/cart architecture
+- adult product form or manufacture-realistic prototype scooter/bike/cart architecture
 - aluminum or steel tube/frame members, machined or cast fork/dropout-like features, wood/composite/aluminum deck where appropriate
 - urethane/rubber wheels, real bearings, axles, fasteners, spacers, grip tape, grips, and purchased brake/steering hardware where appropriate
 

package/dist-skill/library/forgecad-prepare-prompt/references/master-prompt.md

@@ -1,12 +1,12 @@
-# ForgeCAD Manufacturing-Aware Master Prompt
+# ForgeCAD Manufacture-Realistic Prototype Master Prompt
 
 Fill the placeholders and return the finished prompt as one block.
 
 ```text
-You are producing a ForgeCAD build-ready physical artifact package, not a concept sketch.
+You are producing a ForgeCAD manufacture-realistic prototype package, not a concept sketch.
 
 Treat this as a serious product-team prototype assignment.
-The goal is to produce a credible internal engineering package for a real build candidate, not a generic maker example.
+The goal is to produce a credible internal engineering package for a real prototype build candidate, not a generic maker example.
 Use the specific operating story below to drive engineering choices; do not flatten it into a vague domain label.
 
 Target artifact:
@@ -25,6 +25,7 @@ Specific operating story:
 - benchmark class / public comparison anchor, if useful: {benchmark_class}
 
 Chosen intake classification:
+- output posture: manufacture-realistic prototype unless the user explicitly selected another posture
 - artifact family: {artifact_family}
 - duty level: {duty_level}
 - scale level: {scale_level}
@@ -46,6 +47,7 @@ Hard constraints:
 - if the mechanism has moving parts, use a real `assembly()` from iteration 1
 - define real joints, limits, axes, and intended operating ranges
 - choose manufacturing/processes that fit the artifact, load path, scale, safety expectations, and operating story
+- default to manufacture-realistic prototype: real prototype materials, fabrication cues, purchased parts, assembly logic, serviceability, and validation without pretending to be production-certified or release-ready
 - do not assume FDM, 3D printing, or "printable" unless the user explicitly asked for it or the chosen process stack includes printed parts
 - include realistic process-appropriate clearances and mechanically honest interfaces
 - include manufactured, printed, and purchased parts only where each is an honest choice
@@ -64,7 +66,7 @@ Acceptable final states:
 1. `BUILD-READY`
 2. `BEST-EFFORT BUILD CANDIDATE`
 
-`BUILD-READY` means the output is specific enough that a competent builder could start fabricating, machining, printing, buying parts, assembling, and testing immediately without inventing missing details.
+`BUILD-READY` means the output is specific enough that a competent builder could start fabricating, machining, printing selected printed parts, buying parts, assembling, and testing the prototype immediately without inventing missing details.
 
 `BEST-EFFORT BUILD CANDIDATE` means you still provide the strongest concrete design possible, but you explicitly name the smallest unavoidable validation loop that remains.
 
@@ -105,7 +107,7 @@ Required outputs:
 - Specify the actuator class, approximate required torque/force, transmission approach, and why they fit the chosen profile.
 
 6. Manufacturing package
-- For each critical part: material, manufacturing process, setup/orientation/tooling/finish assumptions, serviceability notes, and features sensitive to process accuracy.
+- For each critical part: material, manufacturing process, prototype setup/orientation/tooling/finish assumptions, serviceability notes, and features sensitive to process accuracy.
 - If the selected process includes printed parts, include print orientation, likely support strategy, and print-sensitive features for those parts.
 
 7. Bill of materials

package/dist-skill/library/forgecad-render-inspect/SKILL.md

@@ -158,7 +158,7 @@ PNG review order:
 ## Interpretation Rules
 
 - Collision findings are positive-volume boolean overlaps. Face-touching is not a collision.
-- Connectivity is a fast bbox-neighborhood component graph. Concave shapes can over-connect through bounding boxes; use the collisions channel for exact overlap evidence.
+- Connectivity uses bbox as a broadphase, then exact overlap evidence for component grouping. Bbox-only contact does not merge separate scene objects by default; use the collisions channel for positive-volume overlap evidence.
 - Distance is a bbox-gap metric between physical components, not exact closest surface distance.
 - Thickness is a mesh/raycast approximation. Gray or high unresolved area means the visual heatmap is incomplete, not that the model is safe.
 - Depth is a visual heatmap, not raw floating-point depth data.

package/examples/api/bolted-service-cover.forge.js

@@ -0,0 +1,17 @@
+// Bolted service cover: parent ledge, gasket, fused pull tabs, aligned holes, and installed screws.
+
+const cover = lib.boltedServiceCover({
+  width: 90,
+  depth: 56,
+  coverThickness: 3,
+  parentThickness: 8,
+  ledgeWidth: 10,
+  screwSize: 'M4',
+  boltInset: [6, 6],
+});
+
+verify.equal('four retained cover screws', cover.screws.length, 4);
+verify.greaterThan('cover has edge margin around service opening', cover.dims.ledgeWidth, 6);
+verify.notColliding('cover does not collide with gasket', cover.cover, cover.gasket);
+
+return cover.parts;

package/examples/api/cable-gland-anchor.forge.js

@@ -0,0 +1,14 @@
+const anchor = lib.cableGlandAnchorAssembly({
+  cableDiameter: 6,
+  panelThickness: 3,
+  panelWidth: 62,
+  panelHeight: 44,
+});
+
+verify.equal('cable gland anchor has four retained parts', anchor.parts.length, 4);
+verify.greaterThan('panel leaves material around gland flange', anchor.dims.panelHeight - anchor.dims.flangeDiameter, 8);
+verify.notColliding('cable clears gland bore', anchor.cable, anchor.gland);
+verify.notColliding('gland clears panel hole', anchor.gland, anchor.panel);
+verify.clearanceBetween('gland flange is seated at panel pocket', anchor.gland, anchor.panel, 0.01, 0.2);
+
+return anchor.parts;

package/examples/api/captured-cartridge-guide.forge.js

@@ -0,0 +1,14 @@
+const cassette = lib.capturedCartridgeGuideAssembly({
+  length: 150,
+  cartridgeLength: 72,
+  insertion: 28,
+});
+
+verify.equal('cartridge guide has guide and removable cassette', cassette.parts.length, 2);
+verify.notColliding('cartridge clears guide rails and rear stop', cassette.cartridge, cassette.guide);
+verify.greaterThan('cartridge flange is captured by guide lips', cassette.dims.cartridgeWidth, cassette.dims.throatWidth);
+verify.lessThan('cartridge still clears inner guide width', cassette.dims.cartridgeWidth, cassette.dims.innerWidth);
+verify.greaterThan('cartridge body passes through the guide throat', cassette.dims.throatWidth, cassette.dims.cartridgeBodyWidth);
+verify.inRange('cartridge insertion stays inside travel', cassette.dims.insertion, 0, cassette.dims.maxInsertion);
+
+return cassette.parts;

package/examples/api/captured-linear-slide.forge.js

@@ -0,0 +1,13 @@
+const slide = lib.capturedLinearSlide({
+  length: 160,
+  railWidth: 38,
+  carriageLength: 52,
+  travel: 42,
+});
+
+verify.equal('captured slide has rail and carriage parts', slide.parts.length, 2);
+verify.greaterThan('carriage is wider than the throat opening', slide.dims.carriageWidth, slide.dims.throatWidth);
+verify.greaterThan('slide retains usable travel', slide.dims.maxTravel, 80);
+verify.minClearance('carriage clears captured rail', slide.carriage, slide.rail, 0.05);
+
+return slide.parts;

package/examples/api/clevis-pin-joint.forge.js

@@ -0,0 +1,13 @@
+const clevis = lib.clevisPinJointAssembly({
+  pinDiameter: 4,
+  linkThickness: 6,
+  linkArmLength: 38,
+  earThickness: 4,
+});
+
+verify.equal('clevis joint has three retained parts', clevis.parts.length, 3);
+verify.greaterThan('link eye has material around pin bore', clevis.dims.eyeOuterRadius - clevis.dims.boreDiameter / 2, 4);
+verify.greaterThan('clevis gap clears the link eye', clevis.dims.clevisGap, clevis.dims.linkThickness);
+verify.minClearance('link eye clears clevis yoke', clevis.link, clevis.clevis, 0.05);
+
+return clevis.parts;

package/examples/api/datum-enclosure.forge.js

@@ -0,0 +1,16 @@
+const enclosure = lib.datumEnclosureAssembly({
+  width: 96,
+  depth: 64,
+  height: 18,
+  screwSize: 'M3',
+});
+
+verify.equal('datum enclosure has base gasket cover and four screws', enclosure.parts.length, 7);
+verify.greaterThan('internal cavity keeps usable width', enclosure.dims.innerWidth, 80);
+verify.greaterThan('standoff wall remains around screw envelope', enclosure.dims.standoffDiameter - enclosure.dims.threadEnvelopeDia, 4);
+verify.greaterThan('service port leaves top wall material', enclosure.dims.height - enclosure.dims.baseThickness - enclosure.dims.portHeight, 6);
+verify.notColliding('cover clears seated gasket', enclosure.cover, enclosure.gasket);
+verify.notColliding('first screw clears standoff thread envelope', enclosure.screws[0], enclosure.base);
+verify.inRange('cover stack has small seating clearance', enclosure.dims.faceClearance, 0.01, 0.08);
+
+return enclosure.parts;

package/examples/api/guided-loft-olive-oil-bottle.forge.js

@@ -0,0 +1,135 @@
+/**
+ * Guided loft vs ProductSkin: olive oil bottle.
+ *
+ * Left: the new namespaced Loft.withGuideRails(...) primitive. Right: the
+ * equivalent Product.skin(...) authoring style for comparison.
+ */
+
+Product.scenePreset('product');
+
+viewConfig({
+  camera: { position: [190, -250, 150], target: [8, 0, 88], fov: 34 },
+});
+
+const darkOlive = {
+  color: '#34462f',
+  material: {
+    opacity: 0.58,
+    roughness: 0.14,
+    metalness: 0,
+    clearcoat: 1,
+    clearcoatRoughness: 0.04,
+    transmission: 0.28,
+    thickness: 4,
+  },
+};
+const labelStock = Product.materials.mattePlastic('#eee8d8');
+const blackCap = Product.materials.softRubber({ color: '#171a15' });
+
+const guidedStations = [
+  Loft.station(roundedRect(52, 34, 8), 0),
+  Loft.station(roundedRect(60, 38, 11), 78),
+  Loft.station(roundedRect(42, 27, 10), 128),
+  Loft.station(circle2d(12, 64), 166),
+  Loft.station(circle2d(14, 64), 184),
+];
+
+const leftSilhouette = path()
+  .moveTo(-26, 0)
+  .bezierTo(-31, 30, -33, 55, -31, 72)
+  .bezierTo(-30, 90, -27, 107, -25, 118)
+  .bezierTo(-20, 142, -12, 152, -12, 166)
+  .lineTo(-14, 184);
+
+const rightSilhouette = path()
+  .moveTo(26, 0)
+  .bezierTo(31, 30, 33, 55, 31, 72)
+  .bezierTo(30, 90, 27, 107, 25, 118)
+  .bezierTo(20, 142, 12, 152, 12, 166)
+  .lineTo(14, 184);
+
+const backCrown = path()
+  .moveTo(-17, 0)
+  .bezierTo(-21, 30, -22, 56, -20, 72)
+  .bezierTo(-19, 92, -17, 108, -16, 118)
+  .bezierTo(-13, 142, -10, 154, -10, 166)
+  .lineTo(-12, 184);
+
+const frontCrown = path()
+  .moveTo(17, 0)
+  .bezierTo(22, 30, 24, 56, 22, 72)
+  .bezierTo(21, 92, 19, 108, 18, 118)
+  .bezierTo(14, 142, 10, 154, 10, 166)
+  .lineTo(12, 184);
+
+const leftRail = Loft.pathOnXz(leftSilhouette);
+const rightRail = Loft.pathOnXz(rightSilhouette);
+const backRail = Loft.pathOnYz(backCrown);
+const frontRail = Loft.pathOnYz(frontCrown);
+
+const guidedBottle = Loft.withGuideRails(
+  guidedStations,
+  [
+    Loft.leftRail(leftRail),
+    Loft.rightRail(rightRail),
+    Loft.backRail(backRail),
+    Loft.frontRail(frontRail),
+  ],
+  { samples: 19, edgeLength: 1.3 },
+)
+  .as('guided-loft-olive-glass')
+  .material(darkOlive.material)
+  .color(darkOlive.color);
+
+const guidedLabel = Product.applyMaterial(
+  roundedRect(34, 58, 4)
+    .extrude(0.8)
+    .rotateX(90)
+    .translate(0, 22.5, 76)
+    .as('guided-loft-cream-label'),
+  labelStock,
+);
+
+const guidedCap = Product.applyMaterial(cylinder(18, 12, 12, 64).translate(0, 0, 184).as('guided-loft-black-cap'), blackCap);
+
+const guided = group(
+  { name: 'body', shape: guidedBottle },
+  { name: 'label', shape: guidedLabel },
+  { name: 'cap', shape: guidedCap },
+).translate(-52, 0, 0);
+
+const productBottle = Product.skin('product-skin-olive-glass')
+  .axis('Z')
+  .stations([
+    Product.station('base').z(0).roundedRect(52, 34, 8),
+    Product.station('body').z(78).roundedRect(60, 38, 11),
+    Product.station('shoulder').z(128).roundedRect(42, 27, 10),
+    Product.station('neck').z(166).circle(24),
+    Product.station('lip').z(184).circle(28),
+  ])
+  .rails({
+    leftSilhouette: Product.rail.polyline(leftRail),
+    frontCrown: Product.rail.polyline(frontRail),
+  })
+  .material(darkOlive)
+  .edgeLength(1.3)
+  .build();
+
+const productLabel = Product.applyMaterial(
+  roundedRect(34, 58, 4)
+    .extrude(0.8)
+    .rotateX(90)
+    .translate(0, 22.5, 76)
+    .as('product-skin-cream-label'),
+  labelStock,
+);
+
+const productCap = Product.applyMaterial(cylinder(18, 12, 12, 64).translate(0, 0, 184).as('product-skin-black-cap'), blackCap);
+
+const productSkinComparison = group(
+  { name: 'body', shape: productBottle.toShape() },
+  { name: 'label', shape: productLabel },
+  { name: 'cap', shape: productCap },
+).translate(52, 0, 0);
+
+return [guided, productSkinComparison];

package/examples/api/hose-barb-port.forge.js

@@ -0,0 +1,14 @@
+const hosePort = lib.hoseBarbPortAssembly({
+  hoseInnerDiameter: 6,
+  hoseOuterDiameter: 10,
+  barbCount: 3,
+});
+
+verify.equal('hose barb port has receiver fitting hose and clamp', hosePort.parts.length, 4);
+verify.greaterThan('barb peaks retain nominal hose ID', hosePort.dims.barbPeakDiameter, hosePort.dims.hoseInnerDiameter);
+verify.greaterThan('hose has wall around installed barb envelope', hosePort.dims.hoseOuterDiameter - hosePort.dims.installedHoseBoreDiameter, 1.2);
+verify.notColliding('hose clears barb peaks', hosePort.hose, hosePort.fitting);
+verify.notColliding('clamp clears hose outside', hosePort.clamp, hosePort.hose);
+verify.inRange('fitting shoulder seats near boss face', hosePort.dims.faceClearance, 0.01, 0.08);
+
+return hosePort.parts;

package/examples/api/intentional-overlap-overmold.forge.js

@@ -0,0 +1,16 @@
+// Intentional overlap: an overmolded grip shares volume with its rigid handle core.
+const handleCore = box(64, 12, 8).color('#64748b');
+const rubberGrip = box(42, 18, 10).translate(6, 0, 0).color('#111827');
+
+verify.intentionalOverlap(
+  'rubber grip is overmolded on handle core',
+  rubberGrip,
+  handleCore,
+  'overmolded bonded grip around rigid insert',
+);
+verify.greaterThan('rubber grip wraps beyond core width', rubberGrip.boundingBox().max[1], handleCore.boundingBox().max[1]);
+
+return [
+  { name: 'Rigid handle core', shape: handleCore },
+  { name: 'Overmolded rubber grip', shape: rubberGrip },
+];

package/examples/api/knuckled-hinge-assembly.forge.js

@@ -0,0 +1,15 @@
+const hinge = lib.knuckledHingeAssembly({
+  length: 70,
+  leafLength: 28,
+  leafThickness: 1.8,
+  barrelOuterRadius: 3.2,
+  pinDiameter: 2,
+  openAngleDeg: 42,
+});
+
+verify.equal('hinge has two leaves and one retained pin', hinge.parts.length, 3);
+verify.greaterThan('barrel wall remains around pin bore', hinge.dims.barrelOuterRadius - hinge.dims.boreDiameter / 2, 1.5);
+verify.greaterThan('hinge has meaningful knuckle length', hinge.dims.knuckleLength, hinge.dims.pinDiameter * 2);
+verify.minClearance('moving leaf clears fixed leaf', hinge.movingLeaf, hinge.fixedLeaf, 0.05);
+
+return hinge.parts;