@toolpath/tool-scraper 0.1.0 → 2.1.0

package/dist/families/index.js

@@ -31,6 +31,9 @@
  */
 import { ScraperConfigError } from '../errors.js';
 import { FAMILIES as DESTINYTOOL } from './destinytool.js';
+import { FAMILIES as EMUGE } from './emuge.js';
+import { FAMILIES as HARVEY } from './harvey.js';
+import { HOLDER_FAMILIES as MARITOOL_HOLDERS } from './maritool.js';
 import { COLLET_FAMILIES as KM_COLLETS, FAMILIES as KENNAMETAL, HOLDER_FAMILIES as KM_HOLDERS, } from './kennametal.js';
 import { COLLET_FAMILIES as RF_COLLETS, HOLDER_FAMILIES as RF_HOLDERS } from './regofix.js';
 /**
@@ -57,7 +60,7 @@ function merge(...tables) {
     return merged;
 }
 /** Every cutting-tool family, keyed by the CSV it is scraped into. */
-export const FAMILIES = merge(KENNAMETAL, DESTINYTOOL);
+export const FAMILIES = merge(KENNAMETAL, DESTINYTOOL, HARVEY, EMUGE);
 /**
  * Every toolholding family — holders, and the collets that go in them.
  *
@@ -66,7 +69,7 @@ export const FAMILIES = merge(KENNAMETAL, DESTINYTOOL);
  * states a taper and a clamping mode; a collet states a series and a capacity
  * band) and a scrape of one is not a scrape of the other.
  */
-export const HOLDER_FAMILIES = merge(KM_HOLDERS, RF_HOLDERS);
+export const HOLDER_FAMILIES = merge(KM_HOLDERS, RF_HOLDERS, MARITOOL_HOLDERS);
 export const COLLET_FAMILIES = merge(KM_COLLETS, RF_COLLETS);
 /**
  * Every family this package knows, by CSV name — tools and toolholding alike.

package/dist/families/kennametal.d.ts

@@ -230,6 +230,13 @@ export declare const FAMILIES: {
                 readonly checked: "2026-08-08";
                 readonly by: "JG";
             };
+            readonly coolantThrough: {
+                readonly value: false;
+                readonly source: "assumed";
+                readonly note: "HSS taps; no coolant-through variant appears in the family's variant table, and the table publishes no coolant column";
+                readonly checked: "2026-08-29";
+                readonly by: "JG";
+            };
         };
     };
     readonly 'khsst_hand_metric_plug.csv': {
@@ -251,6 +258,13 @@ export declare const FAMILIES: {
                 readonly checked: "2026-08-08";
                 readonly by: "JG";
             };
+            readonly coolantThrough: {
+                readonly value: false;
+                readonly source: "assumed";
+                readonly note: "HSS taps; no coolant-through variant appears in the family's variant table, and the table publishes no coolant column";
+                readonly checked: "2026-08-29";
+                readonly by: "JG";
+            };
         };
     };
     readonly 'spiral_point_metric_plug.csv': {
@@ -272,6 +286,13 @@ export declare const FAMILIES: {
                 readonly checked: "2026-08-08";
                 readonly by: "JG";
             };
+            readonly coolantThrough: {
+                readonly value: false;
+                readonly source: "assumed";
+                readonly note: "HSS taps; no coolant-through variant appears in the family's variant table, and the table publishes no coolant column";
+                readonly checked: "2026-08-29";
+                readonly by: "JG";
+            };
         };
     };
     readonly 'gomill_pro_radiused_4fl_necked_metric.csv': {

package/dist/families/kennametal.js

@@ -66,6 +66,13 @@ const PCD_SUBSTRATE = {
     source: 'vendor-stated',
     cite: 'grade KD1415 is PCD — the cutting material, not the carbide body it is brazed to',
 };
+const NO_COOLANT_THROUGH_TAP = {
+    value: false,
+    source: 'assumed',
+    note: "HSS taps; no coolant-through variant appears in the family's variant table, and the table publishes no coolant column",
+    checked: '2026-08-29',
+    by: 'JG',
+};
 const HSS_ASSUMED = {
     value: 'hss',
     source: 'assumed',
@@ -299,6 +306,7 @@ export const FAMILIES = {
         columns: { SFDM: 'D', OAL: 'L', LCF: 'L3', TP: 'Thread Pitch' },
         facts: {
             bmc: HSS_ASSUMED,
+            coolantThrough: NO_COOLANT_THROUGH_TAP,
         },
     },
     'khsst_hand_metric_plug.csv': {
@@ -309,6 +317,7 @@ export const FAMILIES = {
         columns: { SFDM: 'D', OAL: 'L', LCF: 'L3', TP: 'Thread Pitch' },
         facts: {
             bmc: HSS_ASSUMED,
+            coolantThrough: NO_COOLANT_THROUGH_TAP,
         },
     },
     'spiral_point_metric_plug.csv': {
@@ -319,6 +328,7 @@ export const FAMILIES = {
         columns: { SFDM: 'D', OAL: 'L', LCF: 'L3', TP: 'Thread Pitch' },
         facts: {
             bmc: HSS_ASSUMED,
+            coolantThrough: NO_COOLANT_THROUGH_TAP,
         },
     },
     'gomill_pro_radiused_4fl_necked_metric.csv': {

package/dist/families/maritool.d.ts

@@ -0,0 +1,120 @@
+/**
+ * MariTool's families — toolholding only, and one CSV per spindle taper.
+ *
+ * There is no `FAMILIES` table here: MariTool publishes no cutting tools, so
+ * this vendor never goes through a column map and binds no record mapper —
+ * the REGO-FIX case. What it publishes is ER collet chucks, shrink-fit holders
+ * and hydraulic chucks in five tapers.
+ *
+ * ## The scrape target is a list of leaf categories
+ *
+ * MariTool's tree is two to four levels deep and **no root carries products
+ * itself**, so there is no single page to name. Each family below states the
+ * leaf cPaths it is scraped from, in {@link LEAVES}, and that list is config
+ * rather than something a scrape re-derives: a walk of the five roots is 199
+ * requests to rediscover 41 paths that are already written down. The walk is
+ * kept — `vendors/maritool/catalog.ts`, reachable as `maritool --catalog` —
+ * because it is how this list was built and how it gets rechecked.
+ *
+ * **A leaf carries the clamping mode and the style with it.** Each CSV is one
+ * taper and mixes all three holder styles, so neither can be a family fact;
+ * and MariTool's own name for the leaf is what classifies the part, so the
+ * column is vendor-stated rather than a coinage here. `ER Collet Chucks` is
+ * `collet` / `er-collet-chuck`, `Shrink Fit Holders` is `shrink` /
+ * `shrink-fit`, `Hydraulic Chucks` is `hydraulic` / `hydraulic-chuck`.
+ *
+ * **Three of the leaves are named `Collet Chucks` rather than `ER Collet
+ * Chucks`, and all three are ER** — `c23_24_45` (CAT50 ER32), `c23_24_429_430`
+ * (dual-contact CAT50 ER32) and `c23_46_1811_1812` (HSK63F ER20), verified
+ * from the part numbers on each page. That is the reason this is a list and
+ * not a name filter: a rule matching `ER Collet Chucks` drops all three
+ * silently.
+ *
+ * ## Not a fact between them
+ *
+ * No family below declares one, and every candidate is a column instead:
+ *
+ * - **`taper` and `contact`** — MariTool states the interface per part in its
+ *   `Taper` cell, in both plain and dual-contact forms, and the HSK family
+ *   holds nine sizes in one CSV. A family constant would mask a scrape that
+ *   lost the column.
+ * - **`clamping` and `style`** — three styles per CSV, from the leaf.
+ * - **`unit`** — `Gage Length` is metric on some parts and imperial on others
+ *   inside one file *and* inside one category page, so there is no
+ *   family-level answer to declare. The scraper promotes an `L1_in`/`L1_mm`
+ *   pair with one cell filled instead.
+ *
+ * ## What is not scraped
+ *
+ * **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.
+ *
+ * Mega Grip, SK, TG, end mill and shell mill holders, slitting-saw and hob
+ * arbors, threaded-body and DSF/MCS modulars, drill chucks, floating tap
+ * holders, boring-head adapters, calibration tooling and coolant tubes are all
+ * out of scope as well — 730 further parts under `c23`. Adding one is a
+ * decision, not a widening of this table.
+ */
+/**
+ * One leaf to scrape, and how MariTool classifies what is in it.
+ *
+ * Declared here rather than imported from `vendors/maritool/scrape.ts`,
+ * which declares a structurally identical `LeafTarget`: `families/` is config
+ * and must not import an adapter — `tests/vendor-boundary.test.ts` refuses it,
+ * and the table is read by every test, none of which should drag a vendor's
+ * scraper in behind it.
+ */
+export interface Leaf {
+    /** MariTool's own category path, e.g. `23_25_42`. */
+    readonly cPath: string;
+    /** How a holder in this leaf grips: `collet`, `shrink`, `hydraulic`. */
+    readonly clamping: string;
+    /** The product style, as MariTool names the leaf. */
+    readonly style: string;
+}
+/**
+ * Which leaf categories each family is scraped from, by CSV name.
+ *
+ * Keyed the same as {@link HOLDER_FAMILIES}, which
+ * `tests/maritool.test.ts` holds the two tables to — a family with no leaves
+ * would scrape nothing and report it as an empty catalog.
+ *
+ * The plain and dual-contact leaves of one style sit next to each other on
+ * purpose: they share no `products_id` at all, so a dual-contact holder is a
+ * distinct part rather than a re-listing, and both belong in the taper's CSV.
+ */
+export declare const LEAVES: {
+    readonly 'maritool_cat40_holders.csv': readonly [Leaf, Leaf, Leaf, Leaf, Leaf, Leaf];
+    readonly 'maritool_cat50_holders.csv': readonly [Leaf, Leaf, Leaf, Leaf, Leaf, Leaf];
+    readonly 'maritool_bt30_holders.csv': readonly [Leaf, Leaf, Leaf, Leaf, Leaf, Leaf, Leaf, Leaf];
+    readonly 'maritool_bt40_holders.csv': readonly [Leaf, Leaf, Leaf, Leaf, Leaf, Leaf];
+    readonly 'maritool_hsk_holders.csv': readonly [Leaf, Leaf, Leaf, Leaf, Leaf, Leaf, Leaf, Leaf, Leaf, Leaf, Leaf, Leaf, Leaf, Leaf, Leaf];
+};
+export declare const HOLDER_FAMILIES: {
+    readonly 'maritool_cat40_holders.csv': {
+        readonly catalogName: "MariTool CAT40 Toolholders";
+        readonly rows: 217;
+        readonly brand: "maritool";
+    };
+    readonly 'maritool_cat50_holders.csv': {
+        readonly catalogName: "MariTool CAT50 Toolholders";
+        readonly rows: 9;
+        readonly brand: "maritool";
+    };
+    readonly 'maritool_bt30_holders.csv': {
+        readonly catalogName: "MariTool BT30 Toolholders";
+        readonly rows: 164;
+        readonly brand: "maritool";
+    };
+    readonly 'maritool_bt40_holders.csv': {
+        readonly catalogName: "MariTool BT40 Toolholders";
+        readonly rows: 67;
+        readonly brand: "maritool";
+    };
+    readonly 'maritool_hsk_holders.csv': {
+        readonly catalogName: "MariTool HSK Toolholders";
+        readonly rows: 70;
+        readonly brand: "maritool";
+    };
+};

package/dist/families/maritool.js

@@ -0,0 +1,175 @@
+/**
+ * MariTool's families — toolholding only, and one CSV per spindle taper.
+ *
+ * There is no `FAMILIES` table here: MariTool publishes no cutting tools, so
+ * this vendor never goes through a column map and binds no record mapper —
+ * the REGO-FIX case. What it publishes is ER collet chucks, shrink-fit holders
+ * and hydraulic chucks in five tapers.
+ *
+ * ## The scrape target is a list of leaf categories
+ *
+ * MariTool's tree is two to four levels deep and **no root carries products
+ * itself**, so there is no single page to name. Each family below states the
+ * leaf cPaths it is scraped from, in {@link LEAVES}, and that list is config
+ * rather than something a scrape re-derives: a walk of the five roots is 199
+ * requests to rediscover 41 paths that are already written down. The walk is
+ * kept — `vendors/maritool/catalog.ts`, reachable as `maritool --catalog` —
+ * because it is how this list was built and how it gets rechecked.
+ *
+ * **A leaf carries the clamping mode and the style with it.** Each CSV is one
+ * taper and mixes all three holder styles, so neither can be a family fact;
+ * and MariTool's own name for the leaf is what classifies the part, so the
+ * column is vendor-stated rather than a coinage here. `ER Collet Chucks` is
+ * `collet` / `er-collet-chuck`, `Shrink Fit Holders` is `shrink` /
+ * `shrink-fit`, `Hydraulic Chucks` is `hydraulic` / `hydraulic-chuck`.
+ *
+ * **Three of the leaves are named `Collet Chucks` rather than `ER Collet
+ * Chucks`, and all three are ER** — `c23_24_45` (CAT50 ER32), `c23_24_429_430`
+ * (dual-contact CAT50 ER32) and `c23_46_1811_1812` (HSK63F ER20), verified
+ * from the part numbers on each page. That is the reason this is a list and
+ * not a name filter: a rule matching `ER Collet Chucks` drops all three
+ * silently.
+ *
+ * ## Not a fact between them
+ *
+ * No family below declares one, and every candidate is a column instead:
+ *
+ * - **`taper` and `contact`** — MariTool states the interface per part in its
+ *   `Taper` cell, in both plain and dual-contact forms, and the HSK family
+ *   holds nine sizes in one CSV. A family constant would mask a scrape that
+ *   lost the column.
+ * - **`clamping` and `style`** — three styles per CSV, from the leaf.
+ * - **`unit`** — `Gage Length` is metric on some parts and imperial on others
+ *   inside one file *and* inside one category page, so there is no
+ *   family-level answer to declare. The scraper promotes an `L1_in`/`L1_mm`
+ *   pair with one cell filled instead.
+ *
+ * ## What is not scraped
+ *
+ * **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.
+ *
+ * Mega Grip, SK, TG, end mill and shell mill holders, slitting-saw and hob
+ * arbors, threaded-body and DSF/MCS modulars, drill chucks, floating tap
+ * holders, boring-head adapters, calibration tooling and coolant tubes are all
+ * out of scope as well — 730 further parts under `c23`. Adding one is a
+ * decision, not a widening of this table.
+ */
+const collet = (cPath) => ({ cPath, clamping: 'collet', style: 'er-collet-chuck' });
+const shrink = (cPath) => ({ cPath, clamping: 'shrink', style: 'shrink-fit' });
+const hydraulic = (cPath) => ({
+    cPath,
+    clamping: 'hydraulic',
+    style: 'hydraulic-chuck',
+});
+/**
+ * Which leaf categories each family is scraped from, by CSV name.
+ *
+ * Keyed the same as {@link HOLDER_FAMILIES}, which
+ * `tests/maritool.test.ts` holds the two tables to — a family with no leaves
+ * would scrape nothing and report it as an empty catalog.
+ *
+ * The plain and dual-contact leaves of one style sit next to each other on
+ * purpose: they share no `products_id` at all, so a dual-contact holder is a
+ * distinct part rather than a re-listing, and both belong in the taper's CSV.
+ */
+export const LEAVES = {
+    'maritool_cat40_holders.csv': [
+        collet('23_25_42'),
+        collet('23_25_432_433'),
+        shrink('23_25_503'),
+        shrink('23_25_432_524'),
+        hydraulic('23_25_929'),
+        hydraulic('23_25_432_930'),
+    ],
+    'maritool_cat50_holders.csv': [
+        collet('23_24_45'),
+        collet('23_24_429_430'),
+        shrink('23_24_1978'),
+        shrink('23_24_429_1979'),
+        hydraulic('23_24_957'),
+        hydraulic('23_24_429_1512'),
+    ],
+    'maritool_bt30_holders.csv': [
+        collet('23_33_35'),
+        collet('23_33_444_445'),
+        collet('23_33_269_270'),
+        shrink('23_33_515'),
+        shrink('23_33_444_559'),
+        shrink('23_33_269_1575'),
+        hydraulic('23_33_911'),
+        hydraulic('23_33_444_912'),
+    ],
+    'maritool_bt40_holders.csv': [
+        collet('23_26_36'),
+        collet('23_26_480_481'),
+        shrink('23_26_1640'),
+        shrink('23_26_480_1641'),
+        hydraulic('23_26_1199'),
+        hydraulic('23_26_480_1409'),
+    ],
+    // Fifteen leaves for seventy parts, because HSK is nine sizes rather than
+    // one taper and MariTool files each size's styles under it separately. The
+    // sizes in scope are HSK25E, HSK40E, HSK50A, HSK50E, HSK63A, HSK63F, HSK80F
+    // and HSK100A; the `Taper` column is what tells them apart in the file.
+    'maritool_hsk_holders.csv': [
+        collet('23_46_943_1494'), // HSK63A
+        collet('23_46_1523_1543'), // HSK50A
+        collet('23_46_1552_1558'), // HSK40E
+        collet('23_46_1591_1592'), // HSK25E
+        collet('23_46_972_1605'), // HSK50E
+        collet('23_46_1811_1812'), // HSK63F — the leaf named "Collet Chuck Holders"
+        shrink('23_46_943_947'), // HSK63A
+        shrink('23_46_972_1495'), // HSK50E
+        shrink('23_46_1523_1542'), // HSK50A
+        shrink('23_46_1552_1553'), // HSK40E
+        shrink('23_46_1513_1903'), // HSK100A
+        shrink('23_46_1841_1844'), // HSK80F
+        hydraulic('23_46_943_946'), // HSK63A
+        hydraulic('23_46_1513_1534'), // HSK100A
+        hydraulic('23_46_972_973'), // HSK50E
+    ],
+};
+export const HOLDER_FAMILIES = {
+    // ── MariTool toolholding (JG 2026-08-29) ───────────────────────────────
+    // Five families, 529 parts across 41 leaves, and **no facts on any of
+    // them**. Every per-family constant the other toolholding vendors declare is
+    // a column here, for the reasons in this module's docstring; a fact stating
+    // one would be a constant the vendor's own table contradicts row by row.
+    //
+    // `rows` is the sum of what each leaf's own `(of N products)` line says,
+    // which is the independent restatement `receipts.checkRows` needs: every
+    // other count is computed from the same file it is checking, so a scrape
+    // that silently lost rows agrees with itself.
+    'maritool_cat40_holders.csv': {
+        catalogName: 'MariTool CAT40 Toolholders',
+        rows: 217,
+        brand: 'maritool',
+    },
+    // 11 parts in the vendor's six leaves and 9 rows here: `CAT50-ER32-3.0` and
+    // `CAT50-ER32-4.0` publish no `Product Specifications` table at all — they
+    // state their geometry as prose in a `Product Info` bullet list — so they
+    // have no gage length and are skipped by the scraper with a message. They
+    // are the only two such parts in scope.
+    'maritool_cat50_holders.csv': {
+        catalogName: 'MariTool CAT50 Toolholders',
+        rows: 9,
+        brand: 'maritool',
+    },
+    'maritool_bt30_holders.csv': {
+        catalogName: 'MariTool BT30 Toolholders',
+        rows: 164,
+        brand: 'maritool',
+    },
+    'maritool_bt40_holders.csv': {
+        catalogName: 'MariTool BT40 Toolholders',
+        rows: 67,
+        brand: 'maritool',
+    },
+    'maritool_hsk_holders.csv': {
+        catalogName: 'MariTool HSK Toolholders',
+        rows: 70,
+        brand: 'maritool',
+    },
+};

package/dist/family.d.ts

@@ -24,7 +24,7 @@ import type { MapperOptions, ScrapedRow } from './scrape.js';
 /**
  * The per-family constants a fact can carry, and their types.
  *
- * Ten keys, which is the whole vocabulary the catalog uses. Naming them rather
+ * Eleven 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
@@ -35,6 +35,18 @@ export interface FamilyFacts {
     unit?: UnitSystem;
     /** Cutting-material code — `carbide`, `hss`, `diamond`. */
     bmc?: string;
+    /**
+     * The end profile, as the vendor names it — `Ball`, `Square`,
+     * `Corner Radius`.
+     *
+     * A per-family constant here rather than a per-row derivation because some
+     * vendors state it once for a whole product line and never in the variant
+     * table: Harvey Tool's 52 product pages each publish one profile in the page
+     * title and no profile column, where Destiny Tool publishes an `endStyle`
+     * per row and needs none of this. It is what tells a mapper that a family
+     * with no corner-radius column has `RE = DC / 2` rather than `RE = 0`.
+     */
+    profile?: string;
     coolantThrough?: boolean;
     flutes?: number;
     /** Degrees included. */
@@ -125,6 +137,28 @@ export type BoundToolholding = ToolholdingDefinition & FamilyFacts;
  * stays one route parameter.
  */
 export declare function familyId(cfg: FamilyDefinition | BoundFamily): string;
+/**
+ * A per-family constant a mapper cannot proceed without.
+ *
+ * The projection is what makes this readable — a mapper says `family.unit` and
+ * never learns about provenance — but a projected key is still optional on the
+ * type, because {@link FamilyFacts} is one vocabulary shared by four vendors
+ * and a tap states no `unit`. So the check is per read, and it belongs here
+ * rather than in one adapter: it lived in `vendors/kennametal/records.ts` until
+ * 2026-08-29, which is why the other two adapters each invented their own
+ * weaker answer instead — `family.unit!`, `family.bmc ?? ''`,
+ * `family.coolantThrough ?? false`, a hardcoded `'inches'`.
+ *
+ * **Every one of those defaults is a claim the family never made.** A missing
+ * `coolantThrough` becoming `false` ships a through-coolant drill with its
+ * coolant presets dropped; a missing `bmc` becoming `''` ships a tool with no
+ * cutting material at all. Refusing names the family and the key, at the one
+ * place that can fix it — the config table.
+ *
+ * Same move `scrape.pause` and `conventions.CAD_COLUMN` already made, and for
+ * the same reason: a core concern does not live in one manufacturer's folder.
+ */
+export declare function fact<T>(family: BoundFamily, key: string, value: T | undefined): T;
 /** The brand that published a family, defaulting as the catalog does. */
 export declare function familyBrand(cfg: CommonDefinition | BoundFamily | BoundToolholding): BrandName;
 export {};

package/dist/family.js

@@ -16,6 +16,7 @@
  * says `family.pointAngle` and never learns about provenance — but there is
  * only ever one authored copy to drift from.
  */
+import { ScraperConfigError } from './errors.js';
 /**
  * A family's id: `<brand>:<vendor-local id>`.
  *
@@ -32,6 +33,33 @@
 export function familyId(cfg) {
     return `${cfg.brand ?? 'kennametal'}:${cfg.id}`;
 }
+/**
+ * A per-family constant a mapper cannot proceed without.
+ *
+ * The projection is what makes this readable — a mapper says `family.unit` and
+ * never learns about provenance — but a projected key is still optional on the
+ * type, because {@link FamilyFacts} is one vocabulary shared by four vendors
+ * and a tap states no `unit`. So the check is per read, and it belongs here
+ * rather than in one adapter: it lived in `vendors/kennametal/records.ts` until
+ * 2026-08-29, which is why the other two adapters each invented their own
+ * weaker answer instead — `family.unit!`, `family.bmc ?? ''`,
+ * `family.coolantThrough ?? false`, a hardcoded `'inches'`.
+ *
+ * **Every one of those defaults is a claim the family never made.** A missing
+ * `coolantThrough` becoming `false` ships a through-coolant drill with its
+ * coolant presets dropped; a missing `bmc` becoming `''` ships a tool with no
+ * cutting material at all. Refusing names the family and the key, at the one
+ * place that can fix it — the config table.
+ *
+ * Same move `scrape.pause` and `conventions.CAD_COLUMN` already made, and for
+ * the same reason: a core concern does not live in one manufacturer's folder.
+ */
+export function fact(family, key, value) {
+    if (value === undefined) {
+        throw new ScraperConfigError(family.id, `a ${family.kind} family must state ${key} as a fact`);
+    }
+    return value;
+}
 /** The brand that published a family, defaulting as the catalog does. */
 export function familyBrand(cfg) {
     return cfg.brand ?? 'kennametal';

package/dist/identity.d.ts

@@ -77,6 +77,24 @@ export declare const BRANDS: {
         readonly vendor: "Destiny Tool";
         readonly productLink: "https://destinytool.com/products?search={material}";
     };
+    readonly harvey: {
+        readonly host: "harveytool.com";
+        readonly home: "https://www.harveytool.com";
+        readonly vendor: "Harvey Tool";
+        readonly productLink: "https://www.harveytool.com/products/tool-details-{material}";
+    };
+    readonly maritool: {
+        readonly host: "maritool.com";
+        readonly home: "https://www.maritool.com";
+        readonly vendor: "MariTool";
+        readonly productLink: "https://www.maritool.com/advanced_search_result.php?keywords={material}";
+    };
+    readonly emuge: {
+        readonly host: "www.emuge-franken-group.com";
+        readonly home: "https://www.emuge-franken-group.com";
+        readonly vendor: "EMUGE-FRANKEN";
+        readonly productLink: "https://www.emuge-franken-group.com/us/en/p/{material}";
+    };
 };
 /**
  * The brands this package knows, as a type.

package/dist/identity.js

@@ -65,6 +65,52 @@ export const BRANDS = {
         vendor: 'Destiny Tool',
         productLink: 'https://destinytool.com/products?search={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
+    // as `<a href="/products/tool-details-14916">`, so the template below is the
+    // vendor's own URL rather than a search standing in for one. The 26 parts
+    // whose table cell carries no link are the exception, and the link is still
+    // the right thing to offer for them — see `docs/HARVEY_PRODUCT_TABLE.md` §3.
+    harvey: {
+        host: 'harveytool.com',
+        home: 'https://www.harveytool.com',
+        vendor: 'Harvey Tool',
+        productLink: 'https://www.harveytool.com/products/tool-details-{material}',
+    },
+    // MariTool is an osCommerce-family storefront, and its per-part page is
+    // addressable three ways: `product_info.php?products_id=100`, the
+    // SEO-rewritten `/p100/<slug>/product_info.html`, and a keyword search. The
+    // first two are keyed on an internal store id rather than on the part
+    // number, and that id is the one thing about a MariTool part that is not
+    // stable — a re-created product changes it. So the link is a search for the
+    // part number, the same call REGO-FIX and Destiny Tool got, and here it is a
+    // search the vendor really answers: `advanced_search_result.php?keywords=`
+    // is the storefront's own search endpoint and a part number matches exactly
+    // one product (JG 2026-08-29).
+    //
+    // No `node`: that key is Kennametal's AEM platform and nothing else.
+    maritool: {
+        host: 'maritool.com',
+        home: 'https://www.maritool.com',
+        vendor: 'MariTool',
+        productLink: 'https://www.maritool.com/advanced_search_result.php?keywords={material}',
+    },
+    // EMUGE-FRANKEN is a SAP Commerce storefront whose pages carry no product
+    // data at all — the Vue front end reads a JSON API, and that API is what the
+    // adapter talks to. See `docs/EMUGE_FRANKEN_COMMERCE_API.md`.
+    //
+    // The per-part link is the vendor's own: every variant record answers with
+    // `url: "/us/en/p/<18-digit material number>"`, so this is that page rather
+    // than a search standing in for one. `www.emuge-franken-group.com` is the
+    // group site serving every region; `/us/en/` is the US storefront the
+    // `emugefrankenUSA` base site the scrape reads corresponds to, so the link
+    // and the data are the same catalog (JG 2026-09-01).
+    emuge: {
+        host: 'www.emuge-franken-group.com',
+        home: 'https://www.emuge-franken-group.com',
+        vendor: 'EMUGE-FRANKEN',
+        productLink: 'https://www.emuge-franken-group.com/us/en/p/{material}',
+    },
 };
 /**
  * The two brands on Kennametal's AEM platform.

package/dist/index.d.ts

@@ -19,12 +19,28 @@
  * that goes beside one, is `@toolpath/tool-scraper/node` — a separate entry
  * point, because a backend embedding this wants the data and a maintainer
  * running the CLI wants the file, and only one of those two needs `fs`.
+ *
+ * ## Cutting tools become records; toolholding is rows
+ *
+ * **`ToolRecord` is the uniform output for cutting tools, and only for those.**
+ * `registry.toRecords` maps one cutting-tool family's scrape onto it, through
+ * the adapter its brand binds. Holders and collets have no record type and no
+ * mapper: REGO-FIX and MariTool ship toolholding and nothing else, so a scrape
+ * of either ends at rows and a receipt, and a consumer that wants a holder
+ * reads the CSV's own columns — the shared ones are named in `conventions`.
+ *
+ * That is a real gap rather than a design: `identity.recordGuid` already exists
+ * so that a holder and a tool can be minted into one guid space, and nothing
+ * mints a holder yet. Until something does, `toRecords` is the tool half and
+ * the receipt is the whole of the toolholding half.
  */
+export * from './columns.js';
 export * from './conventions.js';
 export * from './errors.js';
 export * from './family.js';
 export * from './fetch.js';
 export * from './identity.js';
+export * from './measure.js';
 export * from './provenance.js';
 export * from './records.js';
 export * from './scrape.js';

package/dist/index.js

@@ -19,12 +19,28 @@
  * that goes beside one, is `@toolpath/tool-scraper/node` — a separate entry
  * point, because a backend embedding this wants the data and a maintainer
  * running the CLI wants the file, and only one of those two needs `fs`.
+ *
+ * ## Cutting tools become records; toolholding is rows
+ *
+ * **`ToolRecord` is the uniform output for cutting tools, and only for those.**
+ * `registry.toRecords` maps one cutting-tool family's scrape onto it, through
+ * the adapter its brand binds. Holders and collets have no record type and no
+ * mapper: REGO-FIX and MariTool ship toolholding and nothing else, so a scrape
+ * of either ends at rows and a receipt, and a consumer that wants a holder
+ * reads the CSV's own columns — the shared ones are named in `conventions`.
+ *
+ * That is a real gap rather than a design: `identity.recordGuid` already exists
+ * so that a holder and a tool can be minted into one guid space, and nothing
+ * mints a holder yet. Until something does, `toRecords` is the tool half and
+ * the receipt is the whole of the toolholding half.
  */
+export * from './columns.js';
 export * from './conventions.js';
 export * from './errors.js';
 export * from './family.js';
 export * from './fetch.js';
 export * from './identity.js';
+export * from './measure.js';
 export * from './provenance.js';
 export * from './records.js';
 export * from './scrape.js';