@toolpath/tool-scraper 2.2.0 → 2.4.0

package/README.md

@@ -17,14 +17,14 @@ pnpm add @toolpath/tool-scraper
 
 ## Vendors
 
-| Vendor             | Transport                                               | What it publishes                    |
-| ------------------ | ------------------------------------------------------- | ------------------------------------ |
-| Kennametal / WIDIA | AEM variant-table GET, parsed with `htmlparser2`        | tools and toolholding                |
-| REGO-FIX           | Elasticsearch proxy POST + per-part DIN 4000 XML        | toolholding                          |
-| Destiny Tool       | Firestore REST, paginated                               | solid end mills                      |
-| Harvey Tool        | inline JS literal on a product page, plus its `<thead>` | miniature end mills, keyseat cutters |
-| MariTool           | osCommerce category listings, then one page per part    | toolholding                          |
-| EMUGE-FRANKEN      | SAP Commerce JSON API: grouped, variant, batched detail | end mills, twist drills, taps        |
+| Vendor             | Transport                                               | What it publishes                                 |
+| ------------------ | ------------------------------------------------------- | ------------------------------------------------- |
+| Kennametal / WIDIA | AEM variant-table GET, parsed with `htmlparser2`        | tools and toolholding                             |
+| REGO-FIX           | Elasticsearch proxy POST + per-part DIN 4000 XML        | toolholding                                       |
+| Destiny Tool       | Firestore REST, paginated                               | solid end mills                                   |
+| Harvey Tool        | inline JS literal on a product page, plus its `<thead>` | miniature end mills, keyseat cutters              |
+| MariTool           | osCommerce category listings, then one page per part    | toolholding                                       |
+| EMUGE-FRANKEN      | SAP Commerce JSON API: grouped, variant, batched detail | end mills, twist drills, taps cutting and forming |
 
 ## Two entry points
 
@@ -77,6 +77,7 @@ toolpath-scrape harvey --catalog                  # what the four category trees
 toolpath-scrape maritool maritool_cat40_holders.csv  # its leaf categories come from its config
 toolpath-scrape maritool --catalog                # what the five taper trees hold today
 toolpath-scrape emuge emuge_drills.csv            # its category and unit come from its config
+toolpath-scrape emuge emuge_form_taps.csv         # FG02, the cold-forming taps
 ```
 
 `toolpath-scrape --help` lists the rest.
@@ -99,6 +100,15 @@ here. Every Harvey record is `unspecified`: Harvey's material index is published
 than in a variant table, and a scrape cannot reach it — see
 [`docs/HARVEY_PRODUCT_TABLE.md`](docs/HARVEY_PRODUCT_TABLE.md) §1.5.1.
 
+`threadMethod` is `cutting` or `forming` on a tap and `null` on everything else,
+because the question does not apply to a drill. It is the one field that
+separates a thread former from a cut tap: the two are the same `DC`, `TP`,
+`SFDM`, `OAL` and `LCF`, often the same substrate and coating, and a shop drills
+a larger hole before one than before the other. Neither vendor publishes it in a
+variant table — Kennametal states it in a `newTapType` facet and EMUGE in the
+split between its `FG01` and `FG02` categories — so it is a per-family fact, and
+each family cites the index it was read off.
+
 Every per-family constant no vendor table states carries its provenance — whether it was
 vendor-stated, derived or assumed, and by whom on what date. The types enforce it: an assumed fact
 without a note, a date and initials does not compile.

package/dist/conventions.d.ts

@@ -40,9 +40,19 @@
  * confidently wrong rather than obviously broken. See `records.GEOMETRY_FIELDS`
  * for the canonical side of that line.
  */
+import type { UnitSystem } from '@toolpath/tool-support';
 import type { BrandName } from './identity.js';
-/** Which unit system a family's dimensional columns are published in. */
-export type UnitSystem = 'millimeters' | 'inches';
+/**
+ * Which unit system a family's dimensional columns are published in.
+ *
+ * `@toolpath/tool-support`'s, re-exported under the name this package has
+ * always published. The same two strings were declared here and spelled two
+ * other ways downstream — `'metric' | 'inch'`, and a display unit `'mm' | 'in'`
+ * — with a lookup table between them on ingest, which is where a metric family
+ * quietly becomes an inch one. This spelling won because a scrape originates
+ * the fact.
+ */
+export type { UnitSystem } from '@toolpath/tool-support';
 /**
  * The suffix a dimensional column carries, per unit system.
  *

package/dist/families/emuge.d.ts

@@ -1,7 +1,7 @@
 /**
  * EMUGE-FRANKEN's families.
  *
- * Four, one per catalog category crossed with the unit system the category is
+ * Five, one per catalog category crossed with the unit system the category is
  * published in. That is coarser than the vendor's own marketing, which splits
  * end mills fifteen ways by product line — TOP-Cut, Hard-Cut, Alu-Cut — and it
  * is deliberate: EMUGE states the product line, the cutting material, the
@@ -12,8 +12,22 @@
  * `PRODUCT_LINE_COLUMNS` reads one per part onto `ToolRecord.productLine`, from
  * a column every scrape already writes.
  *
- * So the only fact three of these four state is `unit`, and the fourth adds the
- * two a drill record cannot be built without.
+ * So the only fact the two milling families state is `unit`; the drill family
+ * adds the two a drill record cannot be built without, and each tap family adds
+ * how its taps make a thread — see `MACHINE_TAP` and `COLD_FORMING_TAP`.
+ *
+ * ## The tapping split, which is not a unit split
+ *
+ * Tapping is the one category EMUGE publishes as **two**: `FG01`, which it
+ * titles `Machine taps`, and `FG02`, `Cold forming tap`. They are the same
+ * three calls against the same column labels and differ only in what the tools
+ * do — one cuts the thread away, the other displaces material into it — so
+ * they are two families and not two adapters, and the category is what each
+ * one's `threadMethod` fact cites.
+ *
+ * `FG02` went unscraped until 2026-09-07, which meant `emuge_taps.csv` was the
+ * whole of this package's tapping corpus and every row in it was a cutting tap
+ * with nothing recording that it was.
  *
  * ## `rows`
  *
@@ -78,6 +92,9 @@ export declare const SCRAPE_TARGETS: {
     readonly 'emuge_taps.csv': {
         readonly category: "FG01";
     };
+    readonly 'emuge_form_taps.csv': {
+        readonly category: "FG02";
+    };
 };
 export declare const FAMILIES: {
     readonly 'emuge_end_mills_inch.csv': {
@@ -180,6 +197,37 @@ export declare const FAMILIES: {
                 readonly source: "vendor-stated";
                 readonly cite: "every tap dimension is published in millimetres whatever the thread standard — a `#4-40 UNC` tap states `nominal diameter d₁ [mm]` as `2.845 mm`, `pitch [mm]` as `0.635 mm`, and its shank and lengths in `mm` — with `thread symbol`, `nominal size` and `threads per inch` carrying the inch designation beside them";
             };
+            readonly threadMethod: {
+                readonly value: "cutting";
+                readonly source: "vendor-stated";
+                readonly cite: "the vendor's own category `FG01`, which it titles `Machine taps`; and independently every one of its 414 grouped products states a `chamfer form` and none states a `lead taper form` (JG 2026-09-07)";
+            };
+        };
+    };
+    readonly 'emuge_form_taps.csv': {
+        readonly id: "form-taps";
+        readonly brand: "emuge";
+        readonly kind: "tap";
+        readonly familyCode: "FG02";
+        readonly columns: {
+            readonly DC: "nominal diameter d₁";
+            readonly SFDM: "Shank diameter d₂";
+            readonly OAL: "Overall length l₁";
+            readonly LCF: "length of cutting edge l₂";
+            readonly TP: "pitch";
+        };
+        readonly rows: 1432;
+        readonly facts: {
+            readonly unit: {
+                readonly value: "millimeters";
+                readonly source: "vendor-stated";
+                readonly cite: "every tap dimension is published in millimetres whatever the thread standard — a `#4-40 UNC` tap states `nominal diameter d₁ [mm]` as `2.845 mm`, `pitch [mm]` as `0.635 mm`, and its shank and lengths in `mm` — with `thread symbol`, `nominal size` and `threads per inch` carrying the inch designation beside them";
+            };
+            readonly threadMethod: {
+                readonly value: "forming";
+                readonly source: "vendor-stated";
+                readonly cite: "the vendor's own category `FG02`, which it titles `Cold forming tap`; and independently every one of its 137 grouped products states a `lead taper form` and none states a `chamfer form` (JG 2026-09-07)";
+            };
         };
     };
 };

package/dist/families/emuge.js

@@ -1,7 +1,7 @@
 /**
  * EMUGE-FRANKEN's families.
  *
- * Four, one per catalog category crossed with the unit system the category is
+ * Five, one per catalog category crossed with the unit system the category is
  * published in. That is coarser than the vendor's own marketing, which splits
  * end mills fifteen ways by product line — TOP-Cut, Hard-Cut, Alu-Cut — and it
  * is deliberate: EMUGE states the product line, the cutting material, the
@@ -12,8 +12,22 @@
  * `PRODUCT_LINE_COLUMNS` reads one per part onto `ToolRecord.productLine`, from
  * a column every scrape already writes.
  *
- * So the only fact three of these four state is `unit`, and the fourth adds the
- * two a drill record cannot be built without.
+ * So the only fact the two milling families state is `unit`; the drill family
+ * adds the two a drill record cannot be built without, and each tap family adds
+ * how its taps make a thread — see `MACHINE_TAP` and `COLD_FORMING_TAP`.
+ *
+ * ## The tapping split, which is not a unit split
+ *
+ * Tapping is the one category EMUGE publishes as **two**: `FG01`, which it
+ * titles `Machine taps`, and `FG02`, `Cold forming tap`. They are the same
+ * three calls against the same column labels and differ only in what the tools
+ * do — one cuts the thread away, the other displaces material into it — so
+ * they are two families and not two adapters, and the category is what each
+ * one's `threadMethod` fact cites.
+ *
+ * `FG02` went unscraped until 2026-09-07, which meant `emuge_taps.csv` was the
+ * whole of this package's tapping corpus and every row in it was a cutting tap
+ * with nothing recording that it was.
  *
  * ## `rows`
  *
@@ -53,6 +67,74 @@ export const SCRAPE_TARGETS = {
     },
     'emuge_drills.csv': { category: 'FB01' },
     'emuge_taps.csv': { category: 'FG01' },
+    'emuge_form_taps.csv': { category: 'FG02' },
+};
+/**
+ * Tapping geometry, identical either side of the cutting/forming split.
+ *
+ * **EMUGE labels a cold-forming tap's lead `length of cutting edge l₂` too**,
+ * and it reaches the CSV under that label, because a scraped column keeps the
+ * vendor's own name — `conventions.ts` opens on the reason. A former has no
+ * cutting edge and the label is wrong about it; renaming it here would swap one
+ * vendor's inaccuracy for this package's invention, and the record's `LCF` is
+ * the canonical name either way.
+ */
+const TAP_COLUMNS = {
+    DC: 'nominal diameter d₁',
+    SFDM: 'Shank diameter d₂',
+    OAL: 'Overall length l₁',
+    LCF: 'length of cutting edge l₂',
+    TP: 'pitch',
+};
+/**
+ * Which of EMUGE's two tap categories a family scrapes, and how it is known.
+ *
+ * The vendor splits its taps into two categories and scraping either one is
+ * already the answer — but the *parts* say so as well, independently, which is
+ * what makes these `vendor-stated` rather than a claim about a URL. Every
+ * grouped product carries a flat `technicalDetails` list, and:
+ *
+ * - all 414 `FG01` groups state `chamfer form` and none states `lead taper
+ *   form`;
+ * - all 137 `FG02` groups state `lead taper form` and none states `chamfer
+ *   form`.
+ *
+ * Mutually exclusive, both directions, at full coverage (JG 2026-09-07). A
+ * chamfer is ground onto a tap that cuts and a lead taper is rolled onto one
+ * that forms, so the vendor is naming the same distinction twice.
+ * `tests/emuge-corpus.test.ts` re-checks that agreement against a real scrape,
+ * which is what keeps these two constants honest without either family reading
+ * a column.
+ *
+ * **Two things that look like this discriminator and are not**, recorded so
+ * nobody reaches for them: `Geometry` — the column `vendors/emuge/records.ts`
+ * reads as the product line — takes `AL`, `GAL`, `H`, `MULTI`, `SPEED`,
+ * `STEEL`, `VA` and `Z` in *both* categories; and the 189 `FG01` variants whose
+ * `flute characteristic` is `without` are six EMUGE *Robust* groups, reinforced
+ * cutting taps that still state a `chamfer form`.
+ */
+/**
+ * The unit both tap families are published in.
+ *
+ * Shared because the vendor's rule is about tapping and not about either
+ * category: a `#4-40 UNC` tap states millimetres whichever of the two it sits
+ * in, which is the same thing the module note says about there being no unit
+ * facet on tapping at all.
+ */
+const TAP_MILLIMETERS = {
+    value: 'millimeters',
+    source: 'vendor-stated',
+    cite: 'every tap dimension is published in millimetres whatever the thread standard — a `#4-40 UNC` tap states `nominal diameter d₁ [mm]` as `2.845 mm`, `pitch [mm]` as `0.635 mm`, and its shank and lengths in `mm` — with `thread symbol`, `nominal size` and `threads per inch` carrying the inch designation beside them',
+};
+const MACHINE_TAP = {
+    value: 'cutting',
+    source: 'vendor-stated',
+    cite: "the vendor's own category `FG01`, which it titles `Machine taps`; and independently every one of its 414 grouped products states a `chamfer form` and none states a `lead taper form` (JG 2026-09-07)",
+};
+const COLD_FORMING_TAP = {
+    value: 'forming',
+    source: 'vendor-stated',
+    cite: "the vendor's own category `FG02`, which it titles `Cold forming tap`; and independently every one of its 137 grouped products states a `lead taper form` and none states a `chamfer form` (JG 2026-09-07)",
 };
 /** Milling geometry, identical either side of the unit split. */
 const MILLING_COLUMNS = {
@@ -144,20 +226,28 @@ export const FAMILIES = {
         // `records.DIMENSIONAL_COLUMNS` excluding it means: the vendor publishes
         // `pitch [mm]` and this family is millimetres, so the column is already in
         // the record's native unit.
-        columns: {
-            DC: 'nominal diameter d₁',
-            SFDM: 'Shank diameter d₂',
-            OAL: 'Overall length l₁',
-            LCF: 'length of cutting edge l₂',
-            TP: 'pitch',
-        },
+        columns: TAP_COLUMNS,
         rows: 11566,
         facts: {
-            unit: {
-                value: 'millimeters',
-                source: 'vendor-stated',
-                cite: 'every tap dimension is published in millimetres whatever the thread standard — a `#4-40 UNC` tap states `nominal diameter d₁ [mm]` as `2.845 mm`, `pitch [mm]` as `0.635 mm`, and its shank and lengths in `mm` — with `thread symbol`, `nominal size` and `threads per inch` carrying the inch designation beside them',
-            },
+            unit: TAP_MILLIMETERS,
+            threadMethod: MACHINE_TAP,
+        },
+    },
+    // The second half of the vendor's own tapping catalog, and the only forming
+    // taps this package reaches. It scrapes the same three calls as `FG01`
+    // against the same column labels — see `TAP_COLUMNS` — so it is a family
+    // rather than an adapter: what differs is the category, and what the
+    // category settles.
+    'emuge_form_taps.csv': {
+        id: 'form-taps',
+        brand: 'emuge',
+        kind: 'tap',
+        familyCode: 'FG02',
+        columns: TAP_COLUMNS,
+        rows: 1432,
+        facts: {
+            unit: TAP_MILLIMETERS,
+            threadMethod: COLD_FORMING_TAP,
         },
     },
 };

package/dist/families/kennametal.d.ts

@@ -237,6 +237,11 @@ export declare const FAMILIES: {
                 readonly checked: "2026-08-29";
                 readonly by: "JG";
             };
+            readonly threadMethod: {
+                readonly value: "cutting";
+                readonly source: "vendor-stated";
+                readonly cite: "the vendor's own `newTapType` facet on the variants endpoint: every row of this family answers `:relevance:obsoleteFacet:false:newTapType:11-Spiral Point Tap`, and `3-Forming Tap` — the one forming value of the six — returns the no-results notice (JG 2026-09-07)";
+            };
         };
     };
     readonly 'khsst_hand_metric_plug.csv': {
@@ -265,6 +270,11 @@ export declare const FAMILIES: {
                 readonly checked: "2026-08-29";
                 readonly by: "JG";
             };
+            readonly threadMethod: {
+                readonly value: "cutting";
+                readonly source: "vendor-stated";
+                readonly cite: "the same `newTapType` facet: every row of this family answers `2-Hand Tap`, and `3-Forming Tap`, `8-Spiral Flute Tap`, `10-Pipe Tap` and `11-Spiral Point Tap` each return the no-results notice (JG 2026-09-07)";
+            };
         };
     };
     readonly 'spiral_point_metric_plug.csv': {
@@ -293,6 +303,11 @@ export declare const FAMILIES: {
                 readonly checked: "2026-08-29";
                 readonly by: "JG";
             };
+            readonly threadMethod: {
+                readonly value: "cutting";
+                readonly source: "vendor-stated";
+                readonly cite: "the vendor's own `newTapType` facet on the variants endpoint: every row of this family answers `:relevance:obsoleteFacet:false:newTapType:11-Spiral Point Tap`, and `3-Forming Tap` — the one forming value of the six — returns the no-results notice (JG 2026-09-07)";
+            };
         };
     };
     readonly 'gomill_pro_radiused_4fl_necked_metric.csv': {

package/dist/families/kennametal.js

@@ -73,6 +73,40 @@ const NO_COOLANT_THROUGH_TAP = {
     checked: '2026-08-29',
     by: 'JG',
 };
+/**
+ * The tap-type facet, and what it settles.
+ *
+ * **The variant table does not carry it.** All three tap families publish
+ * `D1-TDZ`, `Thread Tolerance Class ANSI`, `Tap Pitch Diameter Limit` and
+ * `Type of Thread` — the thread's *class*, never how it is produced. What does
+ * carry it is the vendor's own `newTapType` Solr facet, and it narrows the same
+ * `.variants.<code>.html` endpoint `vendors/kennametal/scrape.ts` already
+ * calls: `scrape.ACTIVE_ONLY` is one facet on that query and this is a second,
+ * exactly as `vendors/kennametal/materials.ts` appends one.
+ *
+ * Its vocabulary, read off the threading category listing on 2026-09-07, is
+ * `2-Hand Tap`, `3-Forming Tap`, `8-Spiral Flute Tap`, `10-Pipe Tap`,
+ * `11-Spiral Point Tap` and `13-Straight Flute Tap`. Exactly one of the six is
+ * a forming tap; the other five cut. So a family that answers any value but
+ * `3-Forming Tap` is a cutting family, and each of the three below was probed
+ * for its own value **and** for `3-Forming Tap`, which returned the vendor's
+ * no-results notice every time.
+ *
+ * That is why these are `vendor-stated` and not `assumed`: the cite is a query
+ * anybody can re-run, and the *negative* half of it is the part that matters.
+ * A `cite` naming only the CSV's own filename would be this table reading its
+ * own name back to itself.
+ */
+const SPIRAL_POINT_TAP = {
+    value: 'cutting',
+    source: 'vendor-stated',
+    cite: "the vendor's own `newTapType` facet on the variants endpoint: every row of this family answers `:relevance:obsoleteFacet:false:newTapType:11-Spiral Point Tap`, and `3-Forming Tap` — the one forming value of the six — returns the no-results notice (JG 2026-09-07)",
+};
+const HAND_TAP = {
+    value: 'cutting',
+    source: 'vendor-stated',
+    cite: 'the same `newTapType` facet: every row of this family answers `2-Hand Tap`, and `3-Forming Tap`, `8-Spiral Flute Tap`, `10-Pipe Tap` and `11-Spiral Point Tap` each return the no-results notice (JG 2026-09-07)',
+};
 const HSS_ASSUMED = {
     value: 'hss',
     source: 'assumed',
@@ -307,6 +341,7 @@ export const FAMILIES = {
         facts: {
             bmc: HSS_ASSUMED,
             coolantThrough: NO_COOLANT_THROUGH_TAP,
+            threadMethod: SPIRAL_POINT_TAP,
         },
     },
     'khsst_hand_metric_plug.csv': {
@@ -318,6 +353,7 @@ export const FAMILIES = {
         facts: {
             bmc: HSS_ASSUMED,
             coolantThrough: NO_COOLANT_THROUGH_TAP,
+            threadMethod: HAND_TAP,
         },
     },
     'spiral_point_metric_plug.csv': {
@@ -329,6 +365,7 @@ export const FAMILIES = {
         facts: {
             bmc: HSS_ASSUMED,
             coolantThrough: NO_COOLANT_THROUGH_TAP,
+            threadMethod: SPIRAL_POINT_TAP,
         },
     },
     'gomill_pro_radiused_4fl_necked_metric.csv': {

package/dist/families/maritool.d.ts

@@ -46,6 +46,37 @@
  *
  * ## What is not scraped
  *
+ * **The taps are not scraped, and the evidence for when they are is here.**
+ * MariTool sells taps under `c78_148`, and its tree already answers the one
+ * question a tap record needs that no vendor of ours states in a column —
+ * whether the tap cuts its thread or forms it. Only the forming branch carries
+ * the word, so the leaf name settles it (JG 2026-09-07):
+ *
+ * | Leaf                    | cPath              | Method    |
+ * | ----------------------- | ------------------ | --------- |
+ * | Thread Forming Taps     | `78_148_274`       | `forming` |
+ * | — Plug Form Tap         | `78_148_274_275`   | `forming` |
+ * | — Bottoming Form Tap    | `78_148_274_276`   | `forming` |
+ * | Spiral Flute Taps       | `78_148_149`       | `cutting` |
+ * | Spiral Point Taps       | `78_148_224`       | `cutting` |
+ * | Taps for Aluminum       | `78_148_271`       | `cutting` |
+ * | Taper Pipe Taps         | `78_148_283`       | `cutting` |
+ * | DIN Length HPT Taps     | `78_148_284`       | `cutting` |
+ *
+ * **Checked into a table when it is built, not run as a filter**, for the
+ * reason the ER leaves above already give: a rule matching a name drops
+ * silently when the vendor renames a category, and three leaves here are
+ * already named something other than what they hold. `maritool --catalog` walks
+ * the tree, which is how the rule gets re-checked rather than trusted.
+ *
+ * **What still has to be decided before a tap family lands.** A MariTool tap
+ * page publishes `Shank Size`, `Total Length`, `Thread Length` and `Size` —
+ * enough for `SFDM`, `OAL`, `LCF` and a designation `thread.ts` can already
+ * parse — but a metric tap states `Size: M3` and `Pitch Diameter: 0.5` against
+ * a body in inches (`Shank Size: 0.141`, `Total Length: 1 15/16`). No family in
+ * this package is mixed that way and `ToolRecord.unit` is one value, so that is
+ * a decision on its own merits and not a widening of this table.
+ *
  * **BT50 and ISO30 produce no CSV.** MariTool's only BT50 category is end mill
  * holders, which is out of scope; ISO30 has three ER parts and none of them
  * publishes a spec table, so the family would be a receipt of nothing.

package/dist/families/maritool.js

@@ -46,6 +46,37 @@
  *
  * ## What is not scraped
  *
+ * **The taps are not scraped, and the evidence for when they are is here.**
+ * MariTool sells taps under `c78_148`, and its tree already answers the one
+ * question a tap record needs that no vendor of ours states in a column —
+ * whether the tap cuts its thread or forms it. Only the forming branch carries
+ * the word, so the leaf name settles it (JG 2026-09-07):
+ *
+ * | Leaf                    | cPath              | Method    |
+ * | ----------------------- | ------------------ | --------- |
+ * | Thread Forming Taps     | `78_148_274`       | `forming` |
+ * | — Plug Form Tap         | `78_148_274_275`   | `forming` |
+ * | — Bottoming Form Tap    | `78_148_274_276`   | `forming` |
+ * | Spiral Flute Taps       | `78_148_149`       | `cutting` |
+ * | Spiral Point Taps       | `78_148_224`       | `cutting` |
+ * | Taps for Aluminum       | `78_148_271`       | `cutting` |
+ * | Taper Pipe Taps         | `78_148_283`       | `cutting` |
+ * | DIN Length HPT Taps     | `78_148_284`       | `cutting` |
+ *
+ * **Checked into a table when it is built, not run as a filter**, for the
+ * reason the ER leaves above already give: a rule matching a name drops
+ * silently when the vendor renames a category, and three leaves here are
+ * already named something other than what they hold. `maritool --catalog` walks
+ * the tree, which is how the rule gets re-checked rather than trusted.
+ *
+ * **What still has to be decided before a tap family lands.** A MariTool tap
+ * page publishes `Shank Size`, `Total Length`, `Thread Length` and `Size` —
+ * enough for `SFDM`, `OAL`, `LCF` and a designation `thread.ts` can already
+ * parse — but a metric tap states `Size: M3` and `Pitch Diameter: 0.5` against
+ * a body in inches (`Shank Size: 0.141`, `Total Length: 1 15/16`). No family in
+ * this package is mixed that way and `ToolRecord.unit` is one value, so that is
+ * a decision on its own merits and not a widening of this table.
+ *
  * **BT50 and ISO30 produce no CSV.** MariTool's only BT50 category is end mill
  * holders, which is out of scope; ISO30 has three ER parts and none of them
  * publishes a spec table, so the family would be a receipt of nothing.

package/dist/family.d.ts

@@ -20,12 +20,12 @@ import type { UnitSystem } from './conventions.js';
 import type { BrandName } from './identity.js';
 import type { HoldingMapper, ToolholdingKind } from './holding.js';
 import type { Fact } from './provenance.js';
-import type { ColumnMap, ToolKind, ToolRecord } from './records.js';
+import type { ColumnMap, ThreadMethod, ToolKind, ToolRecord } from './records.js';
 import type { MapperOptions, ScrapedRow } from './scrape.js';
 /**
  * The per-family constants a fact can carry, and their types.
  *
- * Eleven keys, which is the whole vocabulary the catalog uses. Naming them rather
+ * Twelve keys, which is the whole vocabulary the catalog uses. Naming them rather
  * than accepting any string is what lets a mapper read `family.coolantThrough`
  * as a `boolean` instead of casting an `unknown` out of a bag — and what makes
  * a fact whose value is the wrong type a compile error where the family is
@@ -49,6 +49,20 @@ export interface FamilyFacts {
      */
     profile?: string;
     coolantThrough?: boolean;
+    /**
+     * How a tap makes its thread — `cutting` or `forming`.
+     *
+     * A fact and not a column because neither vendor publishes it per part: it is
+     * Kennametal's `newTapType` facet, which the variant table does not carry,
+     * and EMUGE's category, which partitions its taps into two. Every declaration
+     * in `families/` cites the index it was read off, and each is one value for a
+     * whole family — checked against the vendor rather than assumed, which is why
+     * they are `vendor-stated`.
+     *
+     * Every `kind: 'tap'` family must state it: `tapRecord` reads it through
+     * {@link fact}, and `records.toolRecord` refuses a tap record without one.
+     */
+    threadMethod?: ThreadMethod;
     flutes?: number;
     /** Degrees included. */
     pointAngle?: number;

package/dist/identity.d.ts

@@ -75,7 +75,7 @@ export declare const BRANDS: {
         readonly host: "destinytool.com";
         readonly home: "https://destinytool.com";
         readonly vendor: "Destiny Tool";
-        readonly productLink: "https://destinytool.com/products?search={material}";
+        readonly productLink: "https://destinytool.com/products/{material}";
     };
     readonly harvey: {
         readonly host: "harveytool.com";

package/dist/identity.js

@@ -54,16 +54,13 @@ export const BRANDS = {
         productLink: 'https://us.rego-fix.com/en/productfinder?q={material}',
     },
     // Destiny Tool is a Next.js SPA with no product data in the HTML at all — it
-    // reads live from a Firestore database. Like REGO-FIX there is no per-part
-    // page to link to, only a client-rendered products list; unlike REGO-FIX's
-    // ProductFinder, nothing here has confirmed a search query parameter the SPA
-    // actually reads, so this is a best-effort link to the listing page rather
-    // than a verified deep link (JG 2026-08-19).
+    // reads live from a Firestore database. Its client-rendered product page is
+    // addressable by the vendor's item number in the path.
     destinytool: {
         host: 'destinytool.com',
         home: 'https://destinytool.com',
         vendor: 'Destiny Tool',
-        productLink: 'https://destinytool.com/products?search={material}',
+        productLink: 'https://destinytool.com/products/{material}',
     },
     // Harvey Tool is the first brand here whose per-part link is a real page the
     // vendor already publishes: every tool number in a product table is rendered

package/dist/measure.d.ts

@@ -41,16 +41,22 @@
  * writes `1 1/2` and admits no hyphen at all. What it hands here is
  * {@link Measured}, which is the part they have in common.
  *
- * **`MM_PER_INCH` lives here and not in a vendor.** It was declared and
- * exported twice — `vendors/harvey/value.ts` and `vendors/regofix/scrape.ts`
- * — so `@toolpath/tool-scraper/vendors/harvey` and `.../vendors/regofix` each
- * published their own copy of 25.4. That is exactly what `conventions.CAD_COLUMN`
- * was moved up for, and what `tests/vendor-boundary.test.ts` now refuses by name.
+ * **`MM_PER_INCH` and `convertLength` are `@toolpath/tool-support`'s**, and are
+ * re-exported here under the names this package has always published.
+ *
+ * They were declared and exported twice inside this package alone —
+ * `vendors/harvey/value.ts` and `vendors/regofix/scrape.ts` — so
+ * `@toolpath/tool-scraper/vendors/harvey` and `.../vendors/regofix` each
+ * published their own copy of 25.4. `tests/vendor-boundary.test.ts` refuses that
+ * by name and moving the constant up here fixed it *within* this package, while
+ * a third copy went on standing in the application downstream. The domain
+ * package is where a constant every consumer shares can only be declared once,
+ * and `@toolpath/tool-support`'s own boundary test now holds the whole tree to
+ * one `25.4`.
  */
-import type { UnitSystem } from './conventions.js';
+import { convertLength, MM_PER_INCH, type UnitSystem } from '@toolpath/tool-support';
 import { type Warn } from './scrape.js';
-/** Exact by definition: the inch has been 25.4 mm since 1959. */
-export declare const MM_PER_INCH = 25.4;
+export { convertLength, MM_PER_INCH };
 /**
  * `.250` -> 0.25, `3/4` -> 0.75, `1-1/2` -> 1.5, `2` -> 2.
  *
@@ -63,8 +69,6 @@ export declare const MM_PER_INCH = 25.4;
  * that guessed would be the mistake `conventions.UNIT_SUFFIX` exists to prevent.
  */
 export declare function fractionValue(token: string): number | null;
-/** `value`, converted from `from` to `to`. A no-op when they agree. */
-export declare function convertLength(value: number, from: UnitSystem, to: UnitSystem): number;
 /**
  * What a value states about itself: a length system, or degrees.
  *

package/dist/measure.js

@@ -41,15 +41,22 @@
  * writes `1 1/2` and admits no hyphen at all. What it hands here is
  * {@link Measured}, which is the part they have in common.
  *
- * **`MM_PER_INCH` lives here and not in a vendor.** It was declared and
- * exported twice — `vendors/harvey/value.ts` and `vendors/regofix/scrape.ts`
- * — so `@toolpath/tool-scraper/vendors/harvey` and `.../vendors/regofix` each
- * published their own copy of 25.4. That is exactly what `conventions.CAD_COLUMN`
- * was moved up for, and what `tests/vendor-boundary.test.ts` now refuses by name.
+ * **`MM_PER_INCH` and `convertLength` are `@toolpath/tool-support`'s**, and are
+ * re-exported here under the names this package has always published.
+ *
+ * They were declared and exported twice inside this package alone —
+ * `vendors/harvey/value.ts` and `vendors/regofix/scrape.ts` — so
+ * `@toolpath/tool-scraper/vendors/harvey` and `.../vendors/regofix` each
+ * published their own copy of 25.4. `tests/vendor-boundary.test.ts` refuses that
+ * by name and moving the constant up here fixed it *within* this package, while
+ * a third copy went on standing in the application downstream. The domain
+ * package is where a constant every consumer shares can only be declared once,
+ * and `@toolpath/tool-support`'s own boundary test now holds the whole tree to
+ * one `25.4`.
  */
+import { convertLength, MM_PER_INCH } from '@toolpath/tool-support';
 import { consoleWarn } from './scrape.js';
-/** Exact by definition: the inch has been 25.4 mm since 1959. */
-export const MM_PER_INCH = 25.4;
+export { convertLength, MM_PER_INCH };
 /**
  * A decimal, a simple fraction or a mixed number — and nothing else.
  *
@@ -80,12 +87,6 @@ export function fractionValue(token) {
     const value = (whole === undefined ? 0 : Number(whole)) + part;
     return Number.isFinite(value) ? value : null;
 }
-/** `value`, converted from `from` to `to`. A no-op when they agree. */
-export function convertLength(value, from, to) {
-    if (from === to)
-        return value;
-    return to === 'inches' ? value / MM_PER_INCH : value * MM_PER_INCH;
-}
 /**
  * A read cell as a length in `unit`, or null where it publishes none.
  *

package/dist/profiles.d.ts

@@ -34,6 +34,7 @@
  * **Collets get no profile.** They publish no CAD model and are not drawn: a
  * collet sits inside the nut, which the holder's own envelope already includes.
  */
+import type { ProfileDatum, ProfilePoint } from '@toolpath/tool-support';
 import type { HolderRecord } from './holding.js';
 import type { BrandName } from './identity.js';
 /** Bumped when {@link ProfilesDocument}'s shape changes in a way a consumer must handle. */
@@ -117,8 +118,12 @@ export interface MeasuredHolder {
     readonly kernelVersion: string;
     readonly options: ImportOptions;
 }
-/** One vertex of a silhouette: `[z, r]`, both in millimetres. */
-export type ProfilePoint = readonly [z: number, r: number];
+/**
+ * One vertex of a silhouette: `[z, r]`, both in millimetres.
+ *
+ * `@toolpath/tool-support`'s, re-exported under this package's own name.
+ */
+export type { ProfilePoint } from '@toolpath/tool-support';
 /**
  * What `z = 0` means on a profile.
  *
@@ -132,8 +137,13 @@ export type ProfilePoint = readonly [z: number, r: number];
  * implementation put it. One `datum` over a batch is only true while every
  * holder in it has a taper, and the first Capto or straight-shank holder makes
  * the document's own header wrong about some of its entries.
+ *
+ * `@toolpath/tool-support`'s, re-exported under this package's own name. It was
+ * declared here, in the drawing package, and in the application between them —
+ * three copies of two strings, one of which decides whether a consumer may
+ * print a gauge length at all.
  */
-export type ProfileDatum = 'gage-line' | 'nose';
+export type { ProfileDatum } from '@toolpath/tool-support';
 /** One holder's measured silhouette, and how far it agrees with the vendor. */
 export interface HolderProfile {
     readonly catalogNumber: string;

package/dist/provenance.d.ts

@@ -44,6 +44,7 @@
  * is shaped `YYYY-MM-DD` — and `cite: ''` would otherwise satisfy the
  * compiler while citing nothing.
  */
+import { type Provenance } from '@toolpath/tool-support';
 /** What a per-family constant can be. */
 export type FactValue = string | number | boolean;
 /**
@@ -53,9 +54,16 @@ export type FactValue = string | number | boolean;
  * before the guesses and finishes on the ones only a person stands behind —
  * `derived` first, then `assumed`. (`vendor-stated` leads the order but is
  * filtered out of that document entirely; see {@link assumptions}.)
+ *
+ * **`@toolpath/tool-support`'s `PROVENANCE`**, re-exported under this package's
+ * own name. The order is load-bearing here and is the shared list's, so the
+ * ordering that document is read in cannot drift from the vocabulary a drawing
+ * marks a derived dimension by. Three identical declarations of these three
+ * strings stood before it — this one, the drawing's `Provenance`, and the
+ * application's.
  */
 export declare const SOURCES: readonly ["vendor-stated", "derived", "assumed"];
-export type FactSource = (typeof SOURCES)[number];
+export type FactSource = Provenance;
 /**
  * One per-family constant, with its provenance.
  *

package/dist/provenance.js

@@ -44,6 +44,7 @@
  * is shaped `YYYY-MM-DD` — and `cite: ''` would otherwise satisfy the
  * compiler while citing nothing.
  */
+import { PROVENANCE } from '@toolpath/tool-support';
 import { ScraperConfigError } from './errors.js';
 import { compare } from './order.js';
 /**
@@ -53,8 +54,15 @@ import { compare } from './order.js';
  * before the guesses and finishes on the ones only a person stands behind —
  * `derived` first, then `assumed`. (`vendor-stated` leads the order but is
  * filtered out of that document entirely; see {@link assumptions}.)
+ *
+ * **`@toolpath/tool-support`'s `PROVENANCE`**, re-exported under this package's
+ * own name. The order is load-bearing here and is the shared list's, so the
+ * ordering that document is read in cannot drift from the vocabulary a drawing
+ * marks a derived dimension by. Three identical declarations of these three
+ * strings stood before it — this one, the drawing's `Provenance`, and the
+ * application's.
  */
-export const SOURCES = ['vendor-stated', 'derived', 'assumed'];
+export const SOURCES = PROVENANCE;
 const DATE = /^\d{4}-\d{2}-\d{2}$/;
 /** What a note has to say, per source kind. */
 const WANTED = {

package/dist/records.d.ts

@@ -42,9 +42,43 @@
  * always a copy is not a second measurement. An adapter that could supply them
  * separately could supply a tool that claims a holder it does not have.
  */
-import { type UnitSystem } from './conventions.js';
+import { type ThreadMethod, type UnitSystem } from '@toolpath/tool-support';
 import { type BrandName } from './identity.js';
 import type { FactSource } from './provenance.js';
+/**
+ * One canonical geometry name: what it measures, and whose name it is.
+ *
+ * **Declared here rather than re-exported from `@toolpath/tool-support`**, even
+ * though the dictionary's entries are the shared ones. The shared
+ * `GeometryField` carries a required `unit` and is `readonly` throughout, and
+ * this type has been published since 1.0: adopting it outright would stop a
+ * consumer that builds one of these — `{ definition, iso }` — from compiling,
+ * for no gain the values below do not already give. The entries *satisfy* the
+ * shared shape, so a field renamed upstream is still a compile error here.
+ */
+export interface GeometryField {
+    /**
+     * What the field measures, phrased so it can be quoted back at whoever
+     * mapped a column to the wrong one.
+     */
+    definition: string;
+    /**
+     * The ISO 13399 code for this measurement, or `null` where the standard's
+     * counterpart has not been pinned against the dictionary. Equal to the
+     * canonical name itself on every field that *is* the standard's code.
+     */
+    iso: string | null;
+}
+/**
+ * How a tap makes its thread.
+ *
+ * `@toolpath/tool-support`'s, re-exported under the name this package reads it
+ * by — the move `conventions.ts` makes for `UnitSystem` and `provenance.ts` for
+ * `PROVENANCE`. A scrape originates the fact and the domain owns the
+ * vocabulary, and two declarations of the same two strings is the drift that
+ * rule exists to prevent.
+ */
+export type { ThreadMethod } from '@toolpath/tool-support';
 /** The kinds of cutting tool this package maps. */
 export type ToolKind = 'drill' | 'tap' | 'endmill';
 /**
@@ -87,20 +121,6 @@ export declare const UNSPECIFIED = "unspecified";
  * type so that the vocabularies cannot drift apart.
  */
 export type MaterialGroupsSource = FactSource | typeof UNSPECIFIED;
-/** One canonical geometry name: what it measures, and whose name it is. */
-export interface GeometryField {
-    /**
-     * What the field measures, phrased so it can be quoted back at whoever
-     * mapped a column to the wrong one.
-     */
-    definition: string;
-    /**
-     * The ISO 13399 code for this measurement, or `null` where the standard's
-     * counterpart has not been pinned against the dictionary. Equal to the
-     * canonical name itself on every field that *is* the standard's code.
-     */
-    iso: string | null;
-}
 /**
  * Canonical geometry fields an adapter may supply, and what each means.
  *
@@ -109,6 +129,26 @@ export interface GeometryField {
  * so the vocabulary's source is readable from the code rather than from a plan
  * document.
  *
+ * ## What each entry says, and what this table says
+ *
+ * The definitions and ISO codes are `@toolpath/tool-support`'s — that is the
+ * dictionary, and it is shared because a code has to mean one thing in every
+ * package that reads one. **This is not that dictionary.** It is the narrower
+ * question only a scraper asks: which of those names an *adapter may map a
+ * vendor column to*.
+ *
+ * The two are not the same list and must not become one. The dictionary knows
+ * `LBH` and `LD`, which are derived from a tool and a holder downstream and
+ * which no vendor publishes; an adapter permitted to map a column to `LBH`
+ * could supply a tool that claims a stickout nobody set. It also knows `LSCN`,
+ * ISO's clamping-length minimum, which is a real vendor column the day a vendor
+ * prints one — and which is deliberately absent below until that day, because
+ * the load-time check's job is to refuse a name no scrape can fill.
+ *
+ * So each entry is an explicit pick out of the shared table rather than a
+ * spread of it: a name dropped from the dictionary is a compile error here, and
+ * a name added to the dictionary does not silently become mappable.
+ *
  * **Seven of the ten are the standard's codes with the standard's meanings.**
  * The three that are not are Autodesk's, and each has an ISO counterpart
  * Autodesk did not use:
@@ -127,43 +167,53 @@ export interface GeometryField {
  */
 export declare const GEOMETRY_FIELDS: {
     readonly DC: {
+        readonly unit: "mm";
         readonly definition: "cutting diameter";
         readonly iso: "DC";
     };
     readonly SFDM: {
-        readonly definition: "shank diameter";
+        readonly unit: "mm";
+        readonly definition: "shank diameter \u2014 what the holder grips";
         readonly iso: "DMM";
     };
     readonly OAL: {
-        readonly definition: "overall length";
+        readonly unit: "mm";
+        readonly definition: "overall length, tip to the end of the shank";
         readonly iso: "OAL";
     };
     readonly LCF: {
-        readonly definition: "flute length — the length of the cutting edge";
+        readonly unit: "mm";
+        readonly definition: "flute length \u2014 the length of the cutting edge";
         readonly iso: "LCF";
     };
     readonly RE: {
+        readonly unit: "mm";
         readonly definition: "corner radius; 0 on a square-end tool";
         readonly iso: "RE";
     };
     readonly TP: {
-        readonly definition: "thread pitch, in the tool’s own unit system";
+        readonly unit: "mm";
+        readonly definition: "thread pitch, in the tool\u2019s own unit system";
         readonly iso: "TP";
     };
     readonly NOF: {
+        readonly unit: "count";
         readonly definition: "number of flutes";
         readonly iso: "NOF";
     };
     readonly SIG: {
+        readonly unit: "deg";
         readonly definition: "point angle, degrees included";
         readonly iso: "SIG";
     };
     readonly 'shoulder-length': {
+        readonly unit: "mm";
         readonly definition: "usable length below the full shank";
         readonly iso: null;
     };
     readonly 'shoulder-diameter': {
-        readonly definition: "diameter at the shoulder — the neck, where necked";
+        readonly unit: "mm";
+        readonly definition: "diameter at the shoulder \u2014 the neck, where necked";
         readonly iso: null;
     };
 };
@@ -407,6 +457,23 @@ export interface ToolRecord {
      * a PCD tool.
      */
     readonly nonFerrous: boolean | null;
+    /**
+     * Taps only, and `null` on every other kind because the question does not
+     * apply — the shape {@link ToolRecord.nonFerrous} already keeps for drills.
+     *
+     * **Not a default, and not derivable from anything else on the record.** A
+     * former and a cut tap of the same size share their `DC`, `TP`, `SFDM`,
+     * `OAL` and `LCF`; what separates them is that one displaces material and the
+     * other removes it, which changes the hole a shop drills first and the feed
+     * it runs. Guessing `cutting` because most of a catalog is would ship a
+     * former with a cut tap's drill size.
+     *
+     * It is a per-family fact rather than a column, and each of the five
+     * declarations cites the vendor's own index — see `families/kennametal.ts`
+     * and `families/emuge.ts`. The invariant below is what stops a sixth tap
+     * family arriving without one.
+     */
+    readonly threadMethod: ThreadMethod | null;
 }
 /**
  * Build a {@link ToolRecord}: mint its guid, default the fields that have a
@@ -433,7 +500,7 @@ export interface ToolRecord {
  * interchange value, and a mapper that mutated one would be reaching back
  * across the seam this type exists to draw.
  */
-export declare function toolRecord(fields: Omit<ToolRecord, 'guid' | 'materialGroups' | 'materialGroupsSource' | 'nonFerrous' | 'productLine'> & Partial<Pick<ToolRecord, 'materialGroups' | 'materialGroupsSource' | 'nonFerrous' | 'productLine'>>): ToolRecord;
+export declare function toolRecord(fields: Omit<ToolRecord, 'guid' | 'materialGroups' | 'materialGroupsSource' | 'nonFerrous' | 'productLine' | 'threadMethod'> & Partial<Pick<ToolRecord, 'materialGroups' | 'materialGroupsSource' | 'nonFerrous' | 'productLine' | 'threadMethod'>>): ToolRecord;
 /**
  * A family's canonical-field → CSV-column-label mapping, validated.
  *

package/dist/records.js

@@ -42,6 +42,7 @@
  * always a copy is not a second measurement. An adapter that could supply them
  * separately could supply a tool that claims a holder it does not have.
  */
+import { GEOMETRY_FIELDS as DICTIONARY, } from '@toolpath/tool-support';
 import { dimensionalColumn } from './conventions.js';
 import { ScraperConfigError } from './errors.js';
 import { recordGuid } from './identity.js';
@@ -81,6 +82,26 @@ export const UNSPECIFIED = 'unspecified';
  * so the vocabulary's source is readable from the code rather than from a plan
  * document.
  *
+ * ## What each entry says, and what this table says
+ *
+ * The definitions and ISO codes are `@toolpath/tool-support`'s — that is the
+ * dictionary, and it is shared because a code has to mean one thing in every
+ * package that reads one. **This is not that dictionary.** It is the narrower
+ * question only a scraper asks: which of those names an *adapter may map a
+ * vendor column to*.
+ *
+ * The two are not the same list and must not become one. The dictionary knows
+ * `LBH` and `LD`, which are derived from a tool and a holder downstream and
+ * which no vendor publishes; an adapter permitted to map a column to `LBH`
+ * could supply a tool that claims a stickout nobody set. It also knows `LSCN`,
+ * ISO's clamping-length minimum, which is a real vendor column the day a vendor
+ * prints one — and which is deliberately absent below until that day, because
+ * the load-time check's job is to refuse a name no scrape can fill.
+ *
+ * So each entry is an explicit pick out of the shared table rather than a
+ * spread of it: a name dropped from the dictionary is a compile error here, and
+ * a name added to the dictionary does not silently become mappable.
+ *
  * **Seven of the ten are the standard's codes with the standard's meanings.**
  * The three that are not are Autodesk's, and each has an ISO counterpart
  * Autodesk did not use:
@@ -98,25 +119,16 @@ export const UNSPECIFIED = 'unspecified';
  * recognises it.
  */
 export const GEOMETRY_FIELDS = {
-    DC: { definition: 'cutting diameter', iso: 'DC' },
-    SFDM: { definition: 'shank diameter', iso: 'DMM' },
-    OAL: { definition: 'overall length', iso: 'OAL' },
-    LCF: {
-        definition: 'flute length — the length of the cutting edge',
-        iso: 'LCF',
-    },
-    RE: { definition: 'corner radius; 0 on a square-end tool', iso: 'RE' },
-    TP: { definition: 'thread pitch, in the tool’s own unit system', iso: 'TP' },
-    NOF: { definition: 'number of flutes', iso: 'NOF' },
-    SIG: { definition: 'point angle, degrees included', iso: 'SIG' },
-    'shoulder-length': {
-        definition: 'usable length below the full shank',
-        iso: null,
-    },
-    'shoulder-diameter': {
-        definition: 'diameter at the shoulder — the neck, where necked',
-        iso: null,
-    },
+    DC: DICTIONARY.DC,
+    SFDM: DICTIONARY.SFDM,
+    OAL: DICTIONARY.OAL,
+    LCF: DICTIONARY.LCF,
+    RE: DICTIONARY.RE,
+    TP: DICTIONARY.TP,
+    NOF: DICTIONARY.NOF,
+    SIG: DICTIONARY.SIG,
+    'shoulder-length': DICTIONARY['shoulder-length'],
+    'shoulder-diameter': DICTIONARY['shoulder-diameter'],
 };
 /**
  * The canonical names that are **not** ISO 13399's own codes, derived rather
@@ -303,9 +315,21 @@ export function toolRecord(fields) {
             `and materialGroupsSource is ${JSON.stringify(source)} — ` +
             `groups are ${JSON.stringify(UNSPECIFIED)} exactly when there are none`);
     }
+    // A tap says how it makes its thread and nothing else does. Both halves are
+    // load-bearing: a tap record with no method is a family that never declared
+    // the fact, and a method on a drill is a mapper that copied a line from the
+    // tap one. Neither can be recovered downstream from what is left on the
+    // record, because the geometry of a former and a cut tap is the same
+    // geometry.
+    const method = fields.threadMethod ?? null;
+    if ((fields.kind === 'tap') !== (method !== null)) {
+        throw new ScraperConfigError(fields.materialNumber, `a ${fields.kind} record states threadMethod ${JSON.stringify(method)} — ` +
+            `a tap says how it makes its thread and no other kind does`);
+    }
     checkGeometry(fields.kind, fields.materialNumber, fields.geometry);
     return Object.freeze({
         ...fields,
+        threadMethod: method,
         guid: recordGuid(fields.brand, fields.materialNumber),
         geometry: Object.freeze({ ...fields.geometry }),
         materialGroups: groups === null ? null : Object.freeze([...groups]),

package/dist/vendors/emuge/records.d.ts

@@ -155,6 +155,16 @@ export declare const PRODUCT_LINE_COLUMNS: Readonly<Record<string, string>>;
  * vendor's marketing rather than a hole here: `SPEED`, `FK`, `GAL`, `GG` and
  * `TILEG` are real lines with no `/a/` page on the US storefront, so the
  * honest answer is the vendor's own code until one appears.
+ *
+ * **`FG02` has no entry at all, on purpose.** Cold-forming taps index by the
+ * same eight geometry codes `FG01` uses — `AL`, `GAL`, `H`, `MULTI`, `SPEED`,
+ * `STEEL`, `VA`, `Z` — and mean different products by them: a `Z`-geometry
+ * former is InnoForm, not the `Rekord B-Z Taps` the `FG01` table would name it.
+ * Borrowing that table would put a cutting tap's product line on a forming tap,
+ * which is the one error this category split exists to make impossible. So the
+ * codes pass through verbatim, which is what the paragraph above already says a
+ * code with no article page does, and naming them from the vendor's own
+ * cold-forming pages is the follow-up.
  */
 export declare const PRODUCT_LINES: Readonly<Record<string, Readonly<Record<string, string>>>>;
 /**

package/dist/vendors/emuge/records.js

@@ -172,6 +172,7 @@ export const PRODUCT_LINE_COLUMNS = {
     FF01: 'product line',
     FB01: 'Geometry',
     FG01: 'Geometry',
+    FG02: 'Geometry',
 };
 /**
  * A category's product-line codes onto the vendor's own name for each.
@@ -194,6 +195,16 @@ export const PRODUCT_LINE_COLUMNS = {
  * vendor's marketing rather than a hole here: `SPEED`, `FK`, `GAL`, `GG` and
  * `TILEG` are real lines with no `/a/` page on the US storefront, so the
  * honest answer is the vendor's own code until one appears.
+ *
+ * **`FG02` has no entry at all, on purpose.** Cold-forming taps index by the
+ * same eight geometry codes `FG01` uses — `AL`, `GAL`, `H`, `MULTI`, `SPEED`,
+ * `STEEL`, `VA`, `Z` — and mean different products by them: a `Z`-geometry
+ * former is InnoForm, not the `Rekord B-Z Taps` the `FG01` table would name it.
+ * Borrowing that table would put a cutting tap's product line on a forming tap,
+ * which is the one error this category split exists to make impossible. So the
+ * codes pass through verbatim, which is what the paragraph above already says a
+ * code with no article page does, and naming them from the vendor's own
+ * cold-forming pages is the follow-up.
  */
 export const PRODUCT_LINES = {
     // `/us/en/multi-drill/a/MultiDRILL`, `/us/en/steeldrill/a/SteelDrill`,
@@ -527,6 +538,7 @@ export function tapRecord(row, family, columns, options = {}) {
         ...common(row, family, what, warn),
         kind: 'tap',
         unit,
+        threadMethod: fact(family, 'threadMethod', family.threadMethod),
         geometry: {
             DC: required(row, columns, 'DC', unit, what, opts),
             TP: required(row, columns, 'TP', unit, what, opts),

package/dist/vendors/kennametal/records.js

@@ -247,6 +247,7 @@ export function tapRecord(row, family, columns) {
         coating: row[COATING] ?? '',
         ...materialGroups(row),
         coolantThrough: fact(family, 'coolantThrough', family.coolantThrough),
+        threadMethod: fact(family, 'threadMethod', family.threadMethod),
         geometry: {
             DC: threadMajorDiameter(tdz, system),
             TP: require_(row, columns, 'TP', unit, what),

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@toolpath/tool-scraper",
-  "version": "2.2.0",
+  "version": "2.4.0",
   "description": "Scrape cutting-tool geometry from vendor catalogs into records and CSVs",
   "license": "MIT",
   "engines": {
@@ -82,7 +82,8 @@
     "README.md"
   ],
   "dependencies": {
-    "htmlparser2": "12.0.0"
+    "htmlparser2": "12.0.0",
+    "@toolpath/tool-support": "^0.2.0"
   },
   "devDependencies": {
     "@types/node": "24.10.1",