@toolpath/tool-scraper 2.3.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/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/records.d.ts

@@ -42,7 +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 { type UnitSystem } from '@toolpath/tool-support';
+import { type ThreadMethod, type UnitSystem } from '@toolpath/tool-support';
 import { type BrandName } from './identity.js';
 import type { FactSource } from './provenance.js';
 /**
@@ -69,6 +69,16 @@ export interface GeometryField {
      */
     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';
 /**
@@ -447,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
@@ -473,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,7 +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 { GEOMETRY_FIELDS as DICTIONARY, } from '@toolpath/tool-support';
 import { dimensionalColumn } from './conventions.js';
 import { ScraperConfigError } from './errors.js';
 import { recordGuid } from './identity.js';
@@ -315,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.3.0",
+  "version": "2.4.0",
   "description": "Scrape cutting-tool geometry from vendor catalogs into records and CSVs",
   "license": "MIT",
   "engines": {
@@ -83,7 +83,7 @@
   ],
   "dependencies": {
     "htmlparser2": "12.0.0",
-    "@toolpath/tool-support": "^0.1.0"
+    "@toolpath/tool-support": "^0.2.0"
   },
   "devDependencies": {
     "@types/node": "24.10.1",