partforge 0.133.1 → 0.133.2

package/docs/KERNEL-CONTRACT.md

@@ -296,7 +296,7 @@ above. All ops return a `Solid`.
 | `vector2d(name, {shape?, width\|height\|fit, align?, valign?})` | A declared vector document → `Shape2D`. `name` = a declared name in the part's `vectors` field (`partforge-vector` JSON — authored by hand or ingested from an `.svg`; never raw `.svg`). With no `shape`, the document's own composition: every `"add"` shape unioned minus every `"subtract"` shape; `shape` selects one named shape's geometry whatever its role. Sizing follows the document's required `units`: `"artwork"` requires exactly one of `width`/`height`/`fit` in millimetres, `"mm"` places as authored (scale 1, no translate) and accepts a size option optionally; more than one is refused. Uniform scale in every case (`fit` = larger extent); `align`/`valign` position it, same as `text2d`, defaulting to centre/middle for `"artwork"` and to no translate for `"mm"`. **The composed call derives ONE transform from every region in the document**, `"add"` and `"subtract"` alike, so a size or align option cannot scale the subtracts relative to the adds; a `shape` call is measured against that shape alone. **Primitive contours (`circle`/`rect`/`polygon`) expand to ordinary path contours at the format boundary, in `vector-format.js`, so this op's kernel-facing contract is unchanged by them** — nothing below the loader learns primitives exist. Conformance: **both backends** (it lowers to `shape2d` + `union`, exactly like `text2d`). Parity: **identical across backends by construction** — the regions are curve-native (arcs/cubics), so there is no sampling step for the two backends to diverge over. |
 | `hull(inputs[])` | Convex hull of all inputs (each a `Shape2D`, a curve contour, or an `[[x,y],…]` point list) → a convex `Shape2D`. Backend-agnostic: a pure-JS monotone-chain hull over the inputs' sampled points (curved inputs tessellated at a fixed LOD), lifted via `shape2d` (see the parity note below). Throws on an empty input array or a degenerate (collinear/point-count < 3) hull. |
 | `hullChain(inputs[])` | Swept hull over an ordered sequence of ≥2 inputs (same input forms as `hull`): the union of `hull([inᵢ, inᵢ₊₁])` for each consecutive pair — e.g. a tapered link connecting a row of circles. Throws with fewer than 2 inputs. |
-| `toSTEP(named[])` | `[{name, solid, color?}]` → `Promise<ArrayBuffer>` of a STEP assembly. B-rep class only. `color` (`0xRRGGBB`, optional) is the body's surface colour, written as that exact sRGB value; a body without one (or with an unusable one) is written in the viewer's no-material blue-grey (`0x9fb4cc`), never a kernel default. The framework passes each sub-part's display colour — the one its 3MF object gets. Additive: `CONTRACT_VERSION` stays 4, the `import` precedent. |
+| `toSTEP(named[])` | `[{name, solid, color?}]` → `Promise<ArrayBuffer>` of a STEP assembly. B-rep class only. `color` (`0xRRGGBB`, optional) is the body's surface colour, written as that exact sRGB value; a body without one (or with an unusable one) is written in the viewer's no-material blue-grey (`0x9fb4cc`), never a kernel default. The framework passes each sub-part's display colour — the one its 3MF object gets. Every file is AP242, its header's `FILE_SCHEMA` and its body alike — the first export in a process included. Additive: `CONTRACT_VERSION` stays 4, the `import` precedent. |
 | `import(name)` | Previously-registered imported geometry (STEP/STL/3MF, declared in the part's `imports` field) as an ordinary `Solid`. Required on both in-repo backends (Manifold accepts mesh formats, OCCT accepts STEP); a format the routed backend can't use throws lazily, at this call, not at registration. Fed by an underscore-prefixed side-channel, not part authors — see [Conformance classes](#conformance-classes). Additive: not in `OCCT_ONLY_OPS`; needed no `CONTRACT_VERSION` bump of its own (v3 came from the mesh fillet/chamfer change, not this op). |
 
 `hull`/`hullChain` parity: point-list and curve-contour inputs hull bit-identically

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "partforge",
-  "version": "0.133.1",
+  "version": "0.133.2",
   "description": "Turn a declarative part definition into a parametric-CAD web app (three.js + Manifold/Replicad). Requires a Vite-based consumer.",
   "type": "module",
   "license": "MIT",

package/src/framework/geometry/occt-step.js

@@ -1,5 +1,6 @@
 // STEP writer for the OCCT backend: replicad 0.23.1's `exportSTEP` (and the
-// `createAssembly` it calls), changed only in how each body's colour is made.
+// `createAssembly` it calls), changed in how each body's colour is made and in
+// when the writer's model is made (so every file's header names AP242; below).
 //
 // replicad gets colour wrong twice. A body with no colour is painted its default
 // red, so every exported part opened red in a CAD tool. And a colour it is given
@@ -15,7 +16,8 @@
 //
 // Everything else — the XCAF document, naming, the writer's modes and statics,
 // the FS round trip, and which native objects are handed to GC — is replicad's
-// own, so this writes the same file replicad did apart from the colours. The
+// own, so this writes the same file replicad did apart from the colours and the
+// first file in a process, whose header replicad left saying AP214. The
 // document handle passed to Transfer is deliberately never freed: the document
 // itself is owned by its WrappingObj (as replicad's AssemblyExporter owns it),
 // and freeing the handle too would destroy it twice.
@@ -51,14 +53,22 @@ export function writeStep(replicad, bodies) {
   shapeTool.UpdateAssemblies();
 
   const session = r(new oc.XSControl_WorkSession());
-  const writer = r(new oc.STEPCAFControl_Writer_2(r(new oc.Handle_XSControl_WorkSession_2(session)), false));
-  writer.SetColorMode(true);
-  writer.SetLayerMode(true);
-  writer.SetNameMode(true);
+  const sessionHandle = r(new oc.Handle_XSControl_WorkSession_2(session));
+  const writer = r(new oc.STEPCAFControl_Writer_2(sessionHandle, false));
   oc.Interface_Static.SetIVal("write.surfacecurve.mode", true);
   oc.Interface_Static.SetIVal("write.precision.mode", 0);
   oc.Interface_Static.SetIVal("write.step.assembly", 2);
   oc.Interface_Static.SetIVal("write.step.schema", 5);
+  // The header's FILE_SCHEMA is fixed when the writer's model is made, which
+  // constructing the writer does — before the statics above are set. They cannot
+  // go first: the process's first STEP writer is what defines them, so until then
+  // SetIVal is a silent no-op. So the first file in a process said AP214 (OCCT's
+  // default) over an AP242 body. Re-initialising with a fresh model now stamps
+  // the header with the schema the body is written in, on every export.
+  writer.Init(sessionHandle, true);
+  writer.SetColorMode(true);
+  writer.SetLayerMode(true);
+  writer.SetNameMode(true);
   const progress = r(new oc.Message_ProgressRange_1());
   writer.Transfer_1(new oc.Handle_TDocStd_Document_2(doc.wrapped), oc.STEPControl_StepModelType.STEPControl_AsIs, null, progress);