v0.1.0 — headless CAD file I/O for OCCTSwift

Initial release. Spin-out of file-I/O concerns from OCCTSwiftTools per OCCTSwiftTools#12 so headless consumers (Scripts, PadCAM CLI, batch pipelines) don't drag in OCCTSwiftViewport transitively just to load a STEP file.

What's in this package

• enum ShapeLoader — load(from:format:progress:), loadRobust(...), loadFromManifest(at:). Returns ShapeLoadResult { shapesWithColors, dimensions, geomTolerances, datums, manifest }.
• enum CADFileFormat — .step, .stl, .obj, .brep, .iges (lifted from OCCTSwiftTools).
• enum ExportManager + enum ExportFormat — OBJ / PLY / STEP / BREP / glTF / GLB writers (lifted from OCCTSwiftTools).
• struct CADBodyMetadata — pure-data per-body picking metadata (face / edge / vertex indices). Produced by OCCTSwiftTools.CADFileLoader.shapeToBodyAndMetadata; lives here so the type itself doesn't carry a Viewport dep.
• struct ScriptManifest — Codable manifest format for the script harness (lifted from OCCTSwiftTools).
• final class ImportProgressClosure — closure-backed OCCTSwift.ImportProgress adapter (lifted from OCCTSwiftTools).

What's NOT here

• ViewportBody production. That's OCCTSwiftTools.CADFileLoader.shapeToBodyAndMetadata — one floor up — and is the entire reason this package exists separately.
• CADLoadResult { bodies: [ViewportBody], ... }. Stays in OCCTSwiftTools where the Viewport dep already lives.

Architecture position

OCCTSwiftAIS          (depends on Tools)
       ↑
OCCTSwiftTools        (bridge: Shape ↔ ViewportBody — depends on IO + Viewport)
   ↑       ↑
   |   OCCTSwiftViewport  (Metal renderer)
   |
OCCTSwiftIO           ← this repo
       ↑
OCCTSwift             (B-Rep kernel)

Installation

.package(url: "https://github.com/gsdali/OCCTSwiftIO.git", from: "0.1.0"),

Dependencies

• OCCTSwift ≥ 0.170.1. No transitive Viewport.

Stats

18 tests / 4 suites — all green on macOS arm64 with OCCT_SERIAL=1 swift test --parallel --num-workers 1.