Take the packaged Fusion exporter, and a preset Fusion will load

[JustinSGray]

What this is

Two things, one of which is a bug fix found by testing the export in Fusion.

The exporter moves into a package. app/shared/fusion-library.ts is deleted and the work is done by @toolpath/tool-support/export/fusion 0.4.0, whose per-type rules come from Autodesk's own published JSON Schema rather than from a table written here. app/shared/fusion-input.ts is the whole seam that remains — this catalog's records turned into what that package takes, and its ExportNotes read back into the dialog. The dialog drops its workpiece-material and spindle-ceiling questions, because nothing here answers them yet.

Exported libraries would not import into Fusion. Every tool went out with start-values: { presets: [] }, and Fusion refuses a tool carrying no cutting-data preset. Every tool now carries one placeholder, Default Preset, with 1 in every numeric field.

Why the empty list looked correct

Autodesk's schema does ask for a preset — every start-values branch declares presets: { type: 'array', minLength: 1 } — but minLength is a string keyword, so on an array it is a no-op. Autodesk meant minItems. No validator enforces it, which is why the reading that Fusion wants the key and not a preset in it went unchallenged, and why the exporter package's own schema test could not catch it.

Two independent confirmations:

• The library validates cleanly against ToolLibrary.schema.json (sha256 matching the digest pinned in ui-packages) under ajv, and Fusion still refused it. Schema-valid is not import-valid.
• Of 727 tools across seventeen libraries Fusion itself wrote, every one carries at least one preset and none carries zero.

Verified by re-importing the same library with one preset added: it loads.

How one preset serves five tool types

Autodesk states a preset's shape per type and the five shapes are not variations on one another. defaultPreset writes the union of what they require and lets fusionPresets narrow it — a field the type does not model is dropped before the record is written:

type	fields written
flat / ball / bull nose / slot mill	20
spot drill	17
drill, reamer	11, no cutting feedrate
tap right hand	6

Writing one shape per type here would have been a fourth copy of a table that already exists in the exporter and in the schema digest it is checked against.

material is deliberately omitted — an absent band is no restriction rather than a narrow one, and the exporter supplies the all-materials band for that reason. The two booleans Autodesk hangs if/then rules off are set, so the fields they demand travel with their own 1.

Why 1 and not a real number

They are placeholders. What a tool's feeds and speeds should be is a machining model, and this application does not answer that yet. app/shared/pretool-presets.ts is that model, still unwired on purpose, and goes back through the same ToolRequest.presets the placeholder already travels on — after its three documented problems are fixed (spot/centre drills short of a spotting preset's five feedrates, a tap given four fields a tapping preset does not model, and millimetre arithmetic against records stated in the vendor's own unit system). A visible 1 loads and nobody mistakes it for a recommendation.

Also in here

• The bump passes through tool-support 0.3.1, whose collet grip tolerance widened from 1e-6 mm to a thousandth of an inch. toolholding.test.ts now pins both sides of that corridor, including 40ERSS0312 — a sealed ER40 collet 0.0635 mm undersize in both unit columns, which stays refused.
• Three published packages (app-support, tool-drawing, tool-scraper) still depend on tool-support 0.3.1, so two copies resolve in the store. Harmless — it is pure logic with no runtime state, and 0.4.0 is additive — but worth knowing.

Tests

• app/shared/fusion-input.test.ts — a new the preset every tool carries block: one preset per request under its own guid, the milling required set measured against FUSION_TYPES rather than a list retyped here, the drill narrowing, and the tap coming out as exactly its six.
• apps/catalog/tests/on-the-part.spec.ts — the end-to-end download assertion is now its opposite: one preset named Default Preset, not an empty list.
• pnpm check green (check-style, lint, build, check-types, test). The export e2e passes.

[dementive]

If you didn't already I think it would be good to integrate my changes from this PR: #11 into this since they will likely conflict it seems.