toga-ai 1.0.721 → 1.0.722

package/knowledge/1.0/apps/worker/workflows/netsuite-duplicate-items-dedup.md

@@ -15,7 +15,7 @@ related:
   - ../features/netsuite-togasupply-per-client-sync.md
   - ../../library/features/netsuite-suiteql-rest-shim.md
   - ../../../clients/compass-usa/workflows/catalog-fold-reversal.md
-  - ../../../clients/compass-usa/features/two-catalog-item-model.md
+  - ../../../clients/compass-usa/features/item-catalogs-and-duplicate-items.md
 ---
 
 ## Summary
@@ -39,7 +39,7 @@ after the code fix is deployed.
 > running this on any client, confirm the client is **single-catalog**; if not, the dedup must be
 > **catalog-aware** (dedup within a catalog, never across). See the Compass
 > [catalog-fold reversal](../../../clients/compass-usa/workflows/catalog-fold-reversal.md) and
-> [two-catalog item model](../../../clients/compass-usa/features/two-catalog-item-model.md).
+> [Compass item catalogs & duplicate items](../../../clients/compass-usa/features/item-catalogs-and-duplicate-items.md).
 
 ## Root cause — why the duplicates existed at all
 

package/knowledge/clients/compass-usa/INDEX.md

@@ -6,7 +6,7 @@
 | [Compass ASN → ItemFulfillment Auto-Creation](features/asn-to-item-fulfillment.md) | 2.0 | For Compass USA, posting an AdvanceShippingNotice (ASN) auto-creates the ItemFulfillment (IF) on the upstream SalesOrder. | _underscore/Model/Compass/AdvanceShippingNotice.php, _underscore/Model/Compass/PurchaseOrder.php, api2/Component/Api/Cxml/Cxml.php, dbchanges2/Client_Compass/2026-06-11 - AsnItemTrackingNumberAcl.sql, dbchanges2/Client_Compass/2026-06-15b - BackfillSA132781ItemFulfillmentTracking.sql, dbchanges2/Client_Compass/2026-06-16 - CleanupSA132763CrossLineTracking.sql, dbchanges2/Client_Compass/2026-06-16b - CleanupSA132743CrossLineTracking.sql, dbchanges2/Client_Compass/2026-06-16c - BackfillSA132763C40QYUCTracking.sql, dbchanges2/Client_Compass/2026-06-18a - CleanupSA132898DuplicateTracking.sql, dbchanges2/Client_Compass/2026-06-18b - CleanupSA132881DuplicateTracking.sql, dbchanges2/Client_Compass/2026-07-02a - FixSA133377TrackingSerialAndDuplicateIF.sql |
 | [Cost Centers — Unit Locations, numeric-only policy](features/cost-centers.md) | 2.0 | A Compass "cost center" — the value a user picks in commerce and that lands on an order — is **not** a `CostCenters` row. | toga2-commerce/src/pages/Cart/api/CartApi.ts, worker1.5/crons/toga2/compass/import_locations.php, _underscore/Model/Compass/SalesOrder.php, api2/Component/Api/V2/V2.php, dbchanges2/Client_Compass/2026-07-06 - RemoveNonNumericCostCenters.sql |
 | [Compass isFulfillable — Data Quality & the Type-Derived Rule](features/isfulfillable-data-quality-and-type-rule.md) | 2.0 | A **prod-data investigation (2026-08-12, read-only)** into why so many Compass storefront lines still have a dead **Qty Fulfilled** cell. | _underscore/Model/Client/Item.php, library/app/api/toga2.php, worker/crons/toga2/netsuite/backfill_isfulfillable_all_clients.php, dbchanges2/Core/2026-07-17 - RegisterItemIsFulfillableInterceptors.sql, toga2-supply/src/pages/Orders/view/OrderView/components/sections/OrderItemsTableSection.tsx |
-| [Compass Item Catalogs (Compass vs Agilant) & the Duplicate Items the NetSuite Sync Creates](features/item-catalogs-and-duplicate-items.md) | 1.0 | `Client_Compass.Items` is **split across catalogs by which pipeline created the item**, and the two halves are routinely mistaken for one. | library/app/api/toga2.php, _underscore/Model/Compass/PurchaseOrder.php, _underscore/Model/Compass/Usa/PurchaseOrder.php, worker/crons/toga2/netsuite/common_sync_togasupply.php, worker/crons/toga2/compass/workflow/3a_import_office_depot_purchase_orders.php |
+| [Compass Item Catalogs (Compass vs Agilant) & the Duplicate Items the NetSuite Sync Creates](features/item-catalogs-and-duplicate-items.md) | 1.0 | `Client_Compass.Items` is **split across catalogs by which pipeline created the item**, and the two halves are routinely mistaken for one. | library/app/api/toga2.php, _underscore/Model/Compass/PurchaseOrder.php, _underscore/Model/Compass/Usa/PurchaseOrder.php, worker/crons/toga2/netsuite/common_sync_togasupply.php, worker/crons/toga2/compass/workflow/3a_import_office_depot_purchase_orders.php, worker/crons/toga2/compass/workflow/1_transmit_compass_sales_orders_to_mits.php |
 | [Compass: Item-Fulfillment TableViews (for-sales-order-items & for-sales-orders, tracking via bridge)](features/item-fulfillment-tracking-tableview.md) | 2.0 | Two sibling Compass TableViews in `Client_Compass` display fulfilled items in toga2-supply, both driven by `TableViews` / `TableViewJoins` / `TableViewFields` c | dbchanges2/Client_Compass/2026-06-10 - ItemFulfillmentsForSalesOrderItemsTableView.sql, dbchanges2/Client_Compass/2026-06-11 - ItemFulfillmentsForSalesOrdersTableView.sql, dbchanges2/Client_Compass/2026-06-15a - FixItemFulfillmentTrackingNumberJoins.sql, dbchanges2/Client/2026-07-15a - ExcludeFeeItemsFromItemFulfillmentsForSalesOrdersView.sql |
 | [Compass MITS PO → SO Item Linking](features/mits-po-to-so-item-linking.md) | 2.0 | MITS sends Compass inbound Purchase Orders (`POST /v2/purchase-orders`) against a Sales Order (`mitsSalesOrder`). | _underscore/Model/Compass/PurchaseOrder.php, _underscore/Model/Compass/Usa/PurchaseOrder.php, api2/Component/Api/V2/V2.php, worker/crons/toga2/compass/workflow/3a_import_office_depot_purchase_orders.php |
 | [Compass MITS PO Transmission to Vendors](features/mits-po-transmission-to-vendors.md) | 2.0 | The 1.0 worker cron `2_transmit_mits_purchase_orders_to_vendors.php` transmits Compass PurchaseOrders to their vendors (Office Depot, Strategic Systems, Compass | worker/crons/toga2/compass/workflow/2_transmit_mits_purchase_orders_to_vendors.php, worker/crons/toga2/compasscanada/workflow/2_transmit_mits_purchase_orders_to_vendors.php, library/app/client/compass.php |
@@ -21,7 +21,6 @@
 | [Persona Model & Levy-Sector Gating (worker2 PEOPLE cron)](features/persona-model-and-levy-gating.md) | 2.0 | Compass USA catalogue visibility is driven by **personas** in `Client_Compass`. | worker2/Worker/Client/Compass/PeopleFile.php |
 | [Compass Sales-Order Line-Number Renumbering (and why it hangs off the SO hooks)](features/sales-order-line-renumbering.md) | 2.0 | Compass sales-order lines must stay numbered **1..N with no gaps** after any add, edit, or delete — downstream MITS/PO linking reads `lineNumber` as an identity | _underscore/Model/Compass/SalesOrderItem.php, _underscore/Model/Compass/SalesOrder.php |
 | [Stranded Approval Reassignment (repointing approvals off dead duplicate Compass Users rows)](features/stranded-approval-reassignment.md) | 2.0 | A Compass employee who leaves and comes back after more than `CONTACT_UNLINK_GRACE_DAYS` (5) is **inserted as a brand-new `Users` row** by the PEOPLE importer i | _underscore/Model/Compass/ApprovalDecision.php, worker2/Worker/Client/Compass/ApprovalReassignment.php, worker2/Worker/Client/Compass/PeopleFile.php |
-| [Compass USA — intentional two-catalog Item model (store vs Agilant procurement)](features/two-catalog-item-model.md) | 2.0 | Compass USA keeps its items in **two intentional catalogs**, and the **same part number legitimately exists once per catalog**. | library/app/api/toga2.php, worker/crons/toga2/netsuite/common_sync_togasupply.php, worker/crons/toga2/compass/workflow/1_transmit_compass_sales_orders_to_mits.php |
 | [Compass USA](profile.md) | 2.0 | Compass USA is a TOGA client running a multi-tier supply-chain commerce operation. |  |
 | [Compass USA — reversing the 199-item catalog fold (MITS outage recovery)](workflows/catalog-fold-reversal.md) | 2.0 | The **root cause** of the Compass MITS transmission outage (the `assetType`-NULL and duplicate-vendor symptoms) was an ad-hoc cross-client **duplicate-items mer | test/team/2.0 deployment/duplicate_items_merge_ALL_CLIENTS.sql, test/team/2.0 deployment/duplicate_items_merge_analysis.sql, worker/crons/toga2/compass/workflow/1_transmit_compass_sales_orders_to_mits.php, library/app/api/toga2.php, worker/crons/toga2/netsuite/common_sync_togasupply.php |
 | [Compass Cross-Kit Bundle Corruption — Detection & Repair](workflows/cross-kit-bundle-corruption.md) | 2.0 | A frontend regression in `toga2-commerce`'s edit-order bundle submission mis-attributed bundle (kit) line items and **fees/warranties** to the **wrong kit**, pe | src/api/syncSalesOrderItemsFromLocalStorageCartToApi.ts |

package/knowledge/clients/compass-usa/features/item-catalogs-and-duplicate-items.md

@@ -7,19 +7,22 @@ client: compass-usa
 type: client-feature
 status: active
 updated: 2026-09-01
-owners: ["bala"]
+owners: ["bala", "jcardinal"]
 files:
   - library/app/api/toga2.php
   - _underscore/Model/Compass/PurchaseOrder.php
   - _underscore/Model/Compass/Usa/PurchaseOrder.php
   - worker/crons/toga2/netsuite/common_sync_togasupply.php
   - worker/crons/toga2/compass/workflow/3a_import_office_depot_purchase_orders.php
+  - worker/crons/toga2/compass/workflow/1_transmit_compass_sales_orders_to_mits.php
 related:
   - odp-edi-850-item-resolution.md
   - mits-po-to-so-item-linking.md
+  - mits-sales-order-transmission-alerting.md
   - isfulfillable-data-quality-and-type-rule.md
   - ../workflows/odp-duplicate-po-line-cleanup.md
   - ../workflows/odp-order-pipeline-to-netsuite.md
+  - ../workflows/catalog-fold-reversal.md
   - ../profile.md
   - ../../../1.0/apps/library/features/netsuite-item-isfulfillable-sync.md
   - ../../../1.0/apps/worker/features/netsuite-togasupply-per-client-sync.md
@@ -62,6 +65,26 @@ the same list — they are **two different source systems' views** of overlappin
 (`vendorId = 1`) point at **catalog-2** items. Filtering the ODP item lookup to catalog 1 therefore
 breaks a large slice of the Office Depot pipeline outright.
 
+## Customer → catalog rule (which catalog an order resolves to)
+
+Confirmed by the developer and by pre-merge data (2026-08-31):
+
+- **`customerId = 2` (Compass) sales orders → catalog 1 (Compass/store) items.**
+- Everyone else — **Office Depot `customerId = 1`, Agilant `customerId = 3`** → catalog 2
+  (Agilant) items.
+
+Pre-merge snapshot: `customerId = 2` order lines were ~100% on catalog 1 (**182,787 vs 1**).
+The store (catalog-1) item is the one that carries the MITS classification
+(`assetType`/`category`/`type`); a Compass line that resolves to a catalog-2 Agilant item has
+NULL classification and **MITS rejects the whole order** (HTTP 400 "The AssetType field is
+required"). So this mapping is load-bearing.
+
+**⚠ Every catalog re-point MUST be scoped by `customerId`.** An ad-hoc
+`UPDATE ... WHERE itemId = <agilantId>` with no customer filter wrongly moved **687
+Office-Depot lines** onto a Compass item and had to be corrected. This is the durable lesson
+from the 2026-08-31 catalog-fold reversal — see
+[catalog-fold reversal](../workflows/catalog-fold-reversal.md).
+
 ## Where the "Agilant" catalog is hardcoded
 
 The 1.0 side writes and reads catalog 2 **by name**, in four places — none of them configurable:
@@ -93,13 +116,21 @@ Plus `-1` / `-2` suffixed copies: items **2431, 2432, 2443, 2653**.
 **Two distinct duplicate shapes, and only the first exists in prod today:**
 - **Different part numbers** (the table above) — the two rows never match on part number, so each
   pipeline keeps using "its own" item and quantities/fulfillments diverge. This is the live shape.
-- **Same part number, two catalogs — NOT present in prod.** This is the shape behind the
-  [dual-catalog duplicate PO-line bug](../workflows/odp-duplicate-po-line-cleanup.md) (4,886
+- **Same part number, two catalogs — NOT present in prod (2026-09-01).** This is the shape behind
+  the [dual-catalog duplicate PO-line bug](../workflows/odp-duplicate-po-line-cleanup.md) (4,886
   duplicate PO lines across 1,320 Office Depot POs when that was investigated).
   **Verified on prod `Client_Compass` 2026-09-01: zero part numbers are duplicated at all, and zero
   span more than one catalog.** It matters only as a thing to re-check, because a part-number lookup
   with no catalog filter has **no ambiguity check on its exact-match branch**
   ([850 line-item resolution](odp-edi-850-item-resolution.md)).
+  **⚠ Unresolved tension — reconcile before relying on "partNumber is unique."** The
+  [2026-08-31 catalog-fold reversal](../workflows/catalog-fold-reversal.md) is recorded as having
+  folded **199 catalog-1 items into their catalog-2 Agilant canonical by `UPPER(partNumber)`**,
+  which requires those 199 to have shared a part number across the two catalogs pre-merge, and the
+  reversal restored them. That does not square with "zero part numbers span two catalogs" verified
+  the same day. Confirm on prod whether the restored catalog-1 twins carry **distinct** part numbers
+  (e.g. the `#B1H` / `-S` variant forms above) or genuinely-shared ones before treating table-wide
+  `partNumber` uniqueness as settled.
 
 ## "Who changed this part number?" — the audit trail says nobody
 
@@ -143,8 +174,25 @@ children" rule:
 - **⚠ Do not "fix" a mismatch by creating an item** so a string matches. That is how the junk items
   got there in the first place — fix the `VendorItems` mapping instead
   ([850 line-item resolution](odp-edi-850-item-resolution.md)).
+- **The NetSuite sync UPDATE path never touches `assetType`/`category`/`type`.** `getCreateItem`
+  stamps them as NULL on create (so a **new** Agilant item is born unclassified → a Compass line
+  on it fails MITS), but the sync UPDATE only PUTs `inventoryType` / `isFulfillable`. Practical
+  consequence: once classification is set on an item it is **durable across sync runs** (the sync
+  will not revert it) — the exposure is only newly-created items. This is why a store-catalog data
+  repair survives, but the Compass NetSuite sync must still be **stopped before** any catalog
+  re-point (it re-creates Compass order lines on Agilant items). See
+  [catalog-fold reversal](../workflows/catalog-fold-reversal.md).
 
 ## Change history
+- 2026-09-01 — Folded in the **customer → catalog rule** (`customerId = 2` → catalog 1, everyone
+  else → catalog 2; verified 182,787 vs 1 pre-merge) and the mandatory `customerId` scope on any
+  catalog re-point (an unscoped one moved 687 Office-Depot lines). Added that the NetSuite sync
+  UPDATE path never touches `assetType`/`category`/`type` (so classification is durable once set;
+  only new items are born unclassified) and that the Compass sync must be stopped before a re-point.
+  Cross-linked the [catalog-fold reversal](../workflows/catalog-fold-reversal.md) and flagged an
+  **unresolved tension**: that reversal folded/restored 199 catalog-1 items by `UPPER(partNumber)`,
+  which implies shared cross-catalog part numbers pre-merge and does not square with the same-day
+  "partNumber is unique table-wide" verification — needs a prod re-check. (jcardinal)
 - 2026-09-01 — Recorded a **second, independent victim of the same catalog-scoping trap, on the 2.0
   side**: `_Model_Compass_PurchaseOrder::handleMrOrder` references MR sales-order items with a
   hardcoded `COMPASS_CATALOG_UUID` (`961dbcbc…` = catalog **1**), which is the mirror image of the

package/knowledge/clients/compass-usa/features/mits-sales-order-transmission-alerting.md

@@ -17,7 +17,7 @@ files:
   - dbchanges2/Logs/2026-08-04a - MITS rejection business recipients.sql
 related:
   - mits-po-transmission-to-vendors.md
-  - two-catalog-item-model.md
+  - item-catalogs-and-duplicate-items.md
   - ../workflows/catalog-fold-reversal.md
   - ../../compass-canada/profile.md
   - ../../../2.0/apps/worker2/features/error-escalation-cron.md
@@ -134,7 +134,7 @@ order lines resolved to Agilant items that have no store classification. The sam
 their VendorItems, which is what triggered the SQL 1242 abort (see gotchas below). Full root
 cause + the reversal playbook: [catalog-fold reversal](../workflows/catalog-fold-reversal.md).
 Compass keeps two intentional catalogs and the customer→catalog rule is load-bearing — see
-[two-catalog item model](./two-catalog-item-model.md).
+[Compass item catalogs & duplicate items](./item-catalogs-and-duplicate-items.md).
 
 **Fix the data:** assign the correct `assetTypeId` to the affected `Client_Compass.Items`
 (business owns the mapping), and check whether the NetSuite item sync owns `assetType` — if it

package/knowledge/clients/compass-usa/profile.md

@@ -31,7 +31,6 @@ related:
   - workflows/granting-persona-bundle-access.md
   - workflows/granting-navigation-access.md
   - features/mits-sales-order-transmission-alerting.md
-  - features/two-catalog-item-model.md
   - workflows/catalog-fold-reversal.md
   - features/asn-to-item-fulfillment.md
   - features/order-fulfillment-status-per-line.md

package/knowledge/clients/compass-usa/workflows/catalog-fold-reversal.md

@@ -14,7 +14,7 @@ files:
   - library/app/api/toga2.php
   - worker/crons/toga2/netsuite/common_sync_togasupply.php
 related:
-  - ../features/two-catalog-item-model.md
+  - ../features/item-catalogs-and-duplicate-items.md
   - ../features/mits-sales-order-transmission-alerting.md
   - ../../../1.0/apps/worker/workflows/netsuite-duplicate-items-dedup.md
 ---
@@ -25,7 +25,7 @@ The **root cause** of the Compass MITS transmission outage (the `assetType`-NULL
 duplicate-vendor symptoms) was an ad-hoc cross-client **duplicate-items merge** that wrongly
 folded Compass's **two intentional catalogs** together. This workflow records the damage and
 the **durable playbook** used to reverse it. See the
-[two-catalog item model](../features/two-catalog-item-model.md) for why the catalogs are
+[two-catalog item model](../features/item-catalogs-and-duplicate-items.md) for why the catalogs are
 intentional.
 
 ## What broke (root cause)
@@ -91,7 +91,7 @@ damage.**
 - **Stop the Compass NetSuite sync first.** The sync re-creates Compass order lines on Agilant
   items, so the reversal is only durable if the sync is stopped; re-enabling risks re-pointing
   new/re-synced orders back to Agilant (2 lines seen after a test re-enable). See the
-  [two-catalog item model](../features/two-catalog-item-model.md).
+  [two-catalog item model](../features/item-catalogs-and-duplicate-items.md).
 - **Never `UPDATE IGNORE` + delete-leftover for a catalog operation** — it permanently deletes
   collision rows and cannot be reversed. Use FK-checks-ON, fail-loud, single transaction.
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "toga-ai",
-  "version": "1.0.721",
+  "version": "1.0.722",
   "description": "TOGA Technology Team Claude Knowledge System — shared AI coding harness with skills, knowledge base CLI, and project installer for Claude Code.",
   "keywords": [
     "claude",

package/knowledge/clients/compass-usa/features/two-catalog-item-model.md

@@ -1,103 +0,0 @@
----
-title: Compass USA — intentional two-catalog Item model (store vs Agilant procurement)
-framework: "2.0"
-project: _Underscore
-client: compass-usa
-type: client-feature
-status: active
-updated: 2026-09-01
-owners: ["jcardinal"]
-files:
-  - library/app/api/toga2.php
-  - worker/crons/toga2/netsuite/common_sync_togasupply.php
-  - worker/crons/toga2/compass/workflow/1_transmit_compass_sales_orders_to_mits.php
-related:
-  - ../workflows/catalog-fold-reversal.md
-  - ./mits-sales-order-transmission-alerting.md
-  - ../../../1.0/apps/worker/workflows/netsuite-duplicate-items-dedup.md
-  - ../../../1.0/apps/worker/features/netsuite-togasupply-per-client-sync.md
----
-
-## Summary
-
-Compass USA keeps its items in **two intentional catalogs**, and the **same part number
-legitimately exists once per catalog**. These are **not duplicates** — folding them together
-broke MITS transmission platform-wide (see
-[catalog-fold reversal](../workflows/catalog-fold-reversal.md)). `Client_Compass.Catalogs`:
-
-| id | name | Purpose |
-|---|---|---|
-| 1 | **Compass** | Customer / store catalog. Items carry store classification (`assetType`, `category`, `type`). |
-| 2 | **Agilant** | Procurement / NetSuite catalog. Items are synced from NetSuite; **no** classification fields. |
-| 3 | Office Depot | Empty. |
-
-**Rule: a part number that appears in both catalogs is one item per catalog, on purpose.**
-Any dedup/merge that treats cross-catalog same-part-number rows as duplicates is wrong for
-this client.
-
-## Customer → catalog rule (which catalog an order resolves to)
-
-Confirmed by the developer and by pre-merge data:
-
-- **`customerId = 2` (Compass) sales orders → catalog 1 (store) items.**
-- Everyone else — **Office Depot `customerId = 1`, Agilant `customerId = 3`** → catalog 2
-  (Agilant) items.
-
-Verified pre-merge (2026-08-31 snapshot): `customerId = 2` order lines were ~100% on
-catalog 1 (**182,787 vs 1**).
-
-**Every catalog re-point MUST be scoped by `customerId`.** An ad-hoc
-`UPDATE ... WHERE itemId = <agilantId>` with no customer filter wrongly moved **687
-Office-Depot lines** onto a Compass item and had to be corrected. Scope by `customerId = 2`.
-
-## Why the store catalog matters for MITS
-
-The MITS transmit cron needs the **store** classification. When a Compass order line resolves
-to an **Agilant** (catalog-2) item, that item has `assetType`/`category`/`type` NULL, so the
-payload `assetType` is null and **MITS rejects the whole order** (HTTP 400 "The AssetType
-field is required"). So the customer→catalog mapping is load-bearing, not cosmetic. See
-[MITS sales-order transmit alerting](./mits-sales-order-transmission-alerting.md).
-
-## How NetSuite → TOGa Supply sync interacts with the catalogs
-
-The NetSuite → TOGa Supply sync is **Agilant-catalog-only**. This has two durable
-consequences for Compass:
-
-- **Item CREATE always stamps `catalog: Agilant` and sets NO classification.**
-  `App_Api_Toga2::getCreateItem` (`library/app/api/toga2.php` ~L6194-6270) builds the create
-  payload with `catalog => Agilant` and no `assetType`/`category`/`type`; the item lookup in
-  `worker/crons/toga2/netsuite/common_sync_togasupply.php` is built off the Agilant catalog
-  only. So **new items are born on catalog 2, unclassified** — and a Compass order line landing
-  on such an item fails MITS.
-- **Item UPDATE only PUTs `inventoryType` / `isFulfillable`, never `assetType`/`category`/
-  `type`.** So once classification is set on an item it is **durable across sync runs** — the
-  sync will not revert it. The problem is only **new** items, which arrive unclassified.
-
-**Consequence for any data repair:** because the sync re-creates Compass order lines pointing
-at Agilant items, a store-catalog reversal is only durable if the **Compass NetSuite sync is
-stopped first**. Re-enabling it risks re-pointing new/re-synced Compass orders back to Agilant
-(2 such lines were observed right after a test re-enable). A proper long-term fix is a
-sync-lookup change so `customerId = 2` resolves to catalog 1 — outstanding.
-
-## Gotchas / known issues
-
-- **Same part number in both catalogs is NOT a duplicate.** The cross-client
-  [duplicate-items dedup](../../../1.0/apps/worker/workflows/netsuite-duplicate-items-dedup.md)
-  treated Compass's catalog-1 twins as dupes and folded 199 of them into Agilant, causing the
-  MITS outage. Any dedup on this client must be **catalog-aware**.
-- **The MITS crons hold API credentials inline** in the transmit files — treat them as
-  secret-bearing when copying snippets anywhere.
-- Catalog 3 (Office Depot) is empty — do not assume Office Depot orders use it; ODP customer
-  `customerId = 1` resolves to catalog 2.
-
-## Change history
-- 2026-09-01 — Documented Compass USA's intentional two-catalog item model (1 = Compass/store
-  with classification, 2 = Agilant/NetSuite procurement without), the `customerId = 2` →
-  catalog 1 rule (verified 182,787 vs 1 pre-merge), and the mandatory `customerId` scope on any
-  catalog re-point (an unscoped one moved 687 Office-Depot lines). Recorded that the NetSuite →
-  TOGa Supply sync is Agilant-catalog-only: CREATE stamps `catalog: Agilant` with no
-  classification (new items born unclassified → MITS 400), while UPDATE never touches
-  classification (so a set value is durable). Written after the cross-client dedup folded 199
-  catalog-1 twins into Agilant and broke MITS. (jcardinal)
-</content>
-</invoke>