toga-ai 1.0.797 → 1.0.799

package/knowledge/1.0/apps/library/features/toga2-api-client-and-bridge.md

@@ -6,7 +6,7 @@ project: Library
 client: shared
 type: feature
 status: active
-updated: 2026-09-08
+updated: 2026-09-11
 owners: [jcardinal, mhammontree, bala]
 files:
   - library/app/api/toga2.php
@@ -79,6 +79,17 @@ belong to the NetSuite importer — documented in the per-client-sync doc, not h
 - Returns the decoded response object; callers read `->data->{resource}`, `->meta->nextPage`,
   `->isSuccess`, `->status`, `->messages[].code`.
 
+> **The "Invalid API Response" exception now LEADS with the api2 message codes (2026-09-11).**
+> `send()`'s failure exception used to `print_r` the whole response envelope, whose header prints
+> first — so on a real rejection the useful api2 code (e.g. `EV-10: ...`) fell **past** the
+> `Logs.Event.errorMessage` `varchar(255)` limit and was **truncated away**, making the failure look
+> "quiet" (this is exactly what hid the NYCHH duplicate-`Units` EV-10 — see the
+> [per-client sync doc](../../worker/features/netsuite-togasupply-per-client-sync.md)). The exception
+> message now puts the `->messages[].code: text` list **first**, via a new private helper
+> `describeApiMessages()` (~L726), then the `print_r` dump. The helper **caps each message's text at
+> 160 chars** so an echoed customer value cannot land in full in the log table (cso point). Net: the
+> real api2 cause self-reveals in `Logs.Event` on the next run instead of being cut off.
+
 > **`send()` ALWAYS returns something carrying `isSuccess` — so `empty($response->isSuccess)` is a
 > safe failure check on anything it returns, GETs included** (verified 2026-08-12, ~L432–450). It
 > returns early **only** when `isSuccess` is true; when `isSuccess` is false and
@@ -413,6 +424,15 @@ enable flags** and an optional `$monitorTogadeskDepartmentIds[]`:
 
 ## Change history
 
+- 2026-09-11 — **Observability: `send()`'s "Invalid API Response" exception now leads with the api2
+  message codes.** Added a private `describeApiMessages()` helper (~L726) that renders the
+  `->messages[].code: text` list (each text capped at 160 chars, cso point) and prepended it to the
+  exception message ahead of the `print_r` dump (~L636). Reason: `Logs.Event.errorMessage` is
+  `varchar(255)` and the old dump printed the envelope header first, pushing the real api2 code (e.g.
+  `EV-10`) past 255 chars where it was truncated — so failures looked "quiet". This made the NYCHH
+  duplicate-`Units` EV-10 self-reveal; the underlying case-mismatch fix and the three diagnosis traps
+  are on the [per-client sync doc](../../worker/features/netsuite-togasupply-per-client-sync.md). Library
+  only, `php -l` clean; **written, not committed/deployed**. (jcardinal)
 - 2026-09-08 - Added `updateTransferOrderStageToClosed(&$nsOrder, array &$clientConfiguration): bool`
   and the constant `TRANSFER_ORDER_STATUS__CLOSED = 'closed'` (also now used by the `case 'Closed'` in
   the transfer-order status switch). It is a **stage-only** writer: it never touches line items, so it

package/knowledge/1.0/apps/worker/features/netsuite-togasupply-per-client-sync.md

@@ -6,7 +6,7 @@ project: Worker
 client: shared
 type: feature
 status: active
-updated: 2026-09-09
+updated: 2026-09-11
 owners: ["dfranks", "bala", "jcardinal", "mhammontree", "snaredla", "rgirish"]
 files:
   - worker/crons/toga2/netsuite/common_sync_togasupply.php
@@ -296,6 +296,49 @@ hit **every section and every client**, not just the by-reference ones.
   GET's UTC. `strtotime()` and `App_Date::convertToSQLDate()` both use the script tz (Chicago) and are
   the trap. Any manual cursor rewind value you set by hand must also be **Eastern**.
 
+### ⚠ ITEM_RECEIPTS froze at RUNNING on a case-mismatched Units serial → duplicate-unit INSERT (EV-10 / 1062) (found + fixed 2026-09-11, NYCHH prod)
+
+`syncItemReceiptFromNetsuite()` (`library/app/api/toga2.php` ~L4022) builds a PHP array of the
+client's existing `Units` keyed by **serial number** to decide PUT (update) vs POST (create). The
+DB `GET /units` (`Units.serialNumber IN (...)`) is **case-insensitive** and returns the **stored**
+casing (e.g. `'na100'`), but the code keyed the PHP lookup by that **raw stored** value while reading
+it with the **uppercased** serial (`strtoupper` at ~L3905). **PHP array keys are case-sensitive** → the
+lookup missed the existing row → took the **create** path → `POST /units` collided on the
+case-insensitive `Units.itemId_serialNumber` unique key → MySQL **1062** / api2 **EV-10** → the
+ITEM_RECEIPTS section **threw before its cursor PUT**, freezing at RUNNING (and ITEM_FULFILLMENTS,
+which runs behind it, froze with it).
+
+- **Proven on NYCHH:** `Client_Nychh.Units` 23400-23409 store serial `'na100'..'na109'` (lowercase),
+  `c_netsuiteInternalInventoryAssignmentId` NULL; the sync sent `'NA100'`.
+- **Fix (library only, `php -l` clean):** `strtoupper()` on **both** the array key **and** the reads,
+  so the PHP lookup is case-insensitive like the DB. A **second, half-fixed copy** of the same lookup
+  lower in the file (~L6326) already uppercased the **key** but not its two **reads** — made them
+  match too. php-reviewer + cso both cleared it (SAFE TO SHIP). **Written, NOT committed/deployed.**
+- **Lesson:** whenever a PHP lookup mirrors a case-insensitive DB column, normalize case on **every**
+  side — the key write and every read. One un-normalized read reintroduces the duplicate-create path.
+
+#### Diagnosis: three traps that hid this EV-10 (2026-09-11)
+
+The section looked "quiet" (RUNNING, no loud crash-loop under the usual filter) because of three
+things worth knowing for any 1.0-sync freeze:
+
+- **areaPath is NOT only `crons/toga2/netsuite`.** 1.0 sync NetSuite/api2 errors also log under
+  `context.REFERENCE.areaPath` = `library/app/api` and `library/app/api/netsuite` — filtering on the
+  cron path alone **misses** them. (The "Filter on areaPath = `crons/toga2/netsuite`" note near the top
+  of this doc is therefore an *incomplete* filter — widen it to these two areas as well.)
+- **EV-10 is api2's GENERIC "save failed" wrapper — the real DB error is NOT in base `Logs`.** The
+  underlying `1062 Duplicate entry ... for key ...` lives in `Logs_<Client>.Api`: filter
+  `responsePayload LIKE '%EV-10%'` (or join by `transactionId`) for route + `requestPayload` + the full
+  `responsePayload` carrying the real MySQL error. (Same `Logs_<Client>.Api` chain as the other rejection
+  gotchas in this doc.)
+- **Some crashes never record at all.** The worker's error-log write to the logs DB can time out
+  (`mysqli_select_db ... errno=110 Connection timed out`, e.g. `Logs.Issue` 588/589), so a section can
+  freeze with **no** `Logs.Event`/`Issue` row — read `Client_<X>.Parameters` for the stuck RUNNING
+  section as the primary signal, not the log tables.
+- Cross-link: the `send()` "Invalid API Response" exception was also changed 2026-09-11 to **lead with
+  the api2 message codes** so this EV-10 self-reveals in `Logs.Event` next time — see
+  [App_Api_Toga2](../../library/features/toga2-api-client-and-bridge.md).
+
 ### ⚠ Per-record isolation is SECTION-SPECIFIC — and SALES_ORDERS has NONE (corrected 2026-08-17)
 
 Whether a bad record is "stepped over" or freezes the section depends entirely on whether **that
@@ -1439,6 +1482,19 @@ library (or vice versa) crashes GroWrk and Adyen on their next sync run.
 
 ## Change history
 
+- 2026-09-11 — **ITEM_RECEIPTS froze at RUNNING on NYCHH: a case-mismatched `Units` serial lookup
+  (library, fix written not deployed).** `syncItemReceiptFromNetsuite` (`library/app/api/toga2.php`
+  ~L4022) keyed a PHP existing-`Units` array on the DB's stored serial casing (`'na100'`) but read it
+  with the uppercased serial (`'NA100'`, `strtoupper` ~L3905); PHP array keys are case-sensitive, so the
+  lookup missed the row, took the create path, and hit the case-insensitive `Units.itemId_serialNumber`
+  unique key → MySQL **1062** / api2 **EV-10** → the section threw before its cursor PUT and froze,
+  dragging ITEM_FULFILLMENTS behind it. Fixed by `strtoupper()`-ing **both** the array key and the reads
+  (and the half-fixed second copy ~L6326, which had the key but not its two reads). Proven on
+  `Client_Nychh.Units` 23400-23409 (serial `'na100'..'na109'`). php-reviewer + cso cleared it. Also
+  recorded the three diagnosis traps that hid it: sync errors also log under areaPath `library/app/api`
+  and `library/app/api/netsuite` (not only `crons/toga2/netsuite`); EV-10 is a generic wrapper whose real
+  1062 lives in `Logs_<Client>.Api` (`responsePayload LIKE '%EV-10%'`); and the worker's logs-DB write can
+  time out (errno 110, `Logs.Issue` 588/589) so some crashes never record. (jcardinal)
 - 2026-09-09 — **The resume cursor was READ on the wrong clock — a silent +1h window skip dropped
   records across ALL 6 sections and ALL clients (worker, deployed + verified).** `startModeIteration`
   (`common_sync_togasupply.php` ~L622) parsed the Eastern-stored cursor with `strtotime()` (script tz

package/knowledge/1.0/apps/worker/workflows/tracing-a-worker-cron-run-in-production.md

@@ -6,8 +6,8 @@ project: Worker
 client: shared
 type: workflow
 status: active
-updated: 2026-09-04
-owners: ["bala", "kyalamarthi"]
+updated: 2026-09-11
+owners: ["bala", "kyalamarthi", "rgirish"]
 files:
   - worker/ebs/cron.worker.php
   - worker/schedules/cron.worker.sync.json
@@ -23,6 +23,7 @@ related:
   - ../../library/features/cron-execution-monitoring.md
   - ../../library/features/email-test-mode-and-write-free-sends.md
   - ../../../1.0/standards/backend-php.md
+  - ../../../clients/prudential/features/itemclasses-device-tier-data.md
 ---
 
 ## Summary
@@ -47,6 +48,27 @@ frequency makes you read a normal gap as an outage.
 Also check whether the job is registered in the env you are testing in at all: this one is **not**
 in `cron.beta.json`, so beta never runs it on a schedule. Nothing on beta is evidence about it.
 
+### Is the job switched OFF? — read the `active` flag carefully
+
+Each schedule entry is `{active, name, schedule, cron}`, and `ebs/cron.worker.php:39` gates it:
+
+```php
+if (!property_exists($cron, 'active') || $cron->active) {
+```
+
+- **`"active": 0` genuinely stops the job** — it is never written into the crontab, so it leaves
+  no `CronJobExecutions` row and no trace anywhere. Indistinguishable from "never fired" unless
+  you read the JSON.
+- **⚠ A MISSING `active` property means the job RUNS.** The default is on, not off. Do not read
+  the absence of `active` as "disabled".
+
+When a job is off, `git log` the schedule file to find out who turned it off and why — the commit
+message usually carries the reason. Worked example (2026-09-11): "Transmissions to Netsuite"
+(`cron.worker.sync.json:441`) is `"active": 0`, disabled 2026-07-17 in commit `14570def`
+("Add careOf & skip Apple; disable Netsuite cron") on `_production`. That single flag is what made
+Prudential's `ItemClasses` data dead — see
+[Prudential ItemClasses device-tier data](../../../clients/prudential/features/itemclasses-device-tier-data.md).
+
 ### Which of the 7 boxes runs it — and in which timezone
 
 Two facts you need before you go looking for evidence, both easy to get wrong:
@@ -188,6 +210,11 @@ real script **never executes**, on every tick, with no error anywhere. It looks
 contain anything; only the `cron` path is shell-parsed.
 
 ## Change history
+- 2026-09-11 — Added **"is the job switched OFF?"** to Step 1: `ebs/cron.worker.php:39` gates on
+  `!property_exists($cron, 'active') || $cron->active`, so `"active": 0` genuinely stops the job
+  and leaves no trace, but a **missing `active` property means it RUNS** (default is on). Also:
+  `git log` the schedule file to find who disabled it and why. Found while proving Prudential's
+  `ItemClasses` data was dead. (rgirish)
 - 2026-09-04 — Added the **`&`-in-a-cron-filename trap**: `ebs/cron.worker.php:41` concatenates the
   path into the crontab line unquoted, so a shell metacharacter splits the command and the script
   never runs while leaving no trace. Found via the renamed Compass Canada

package/knowledge/2.0/apps/_underscore/INDEX.md

@@ -27,6 +27,7 @@
 | [FIELD_STORAGE fields — per-row lazy hydration and the platform-wide missing-column 500](features/field-storage-row-hydration.md) | `FIELD_STORAGE` is the 2.0 field type for blob-backed columns (S3 or local folder). |
 | [Forecast.Sales NetSuite import engine (real-time webhook)](features/forecast-sale-import.md) | Real-time importer that takes a NetSuite **sale** record and writes its lines into `Forecast.Sales` (the Forecast2 revenue table). |
 | [isFulfillable Propagation Up the SO↔PO Chain](features/fulfillable-item-propagation.md) | `Items.isFulfillable` is a boolean that gates whether a storefront line's **Qty Fulfilled** cell is actionable. |
+| [ItemClasses / _Model_Client_ItemClass — who actually uses it (and why it is not free)](features/item-classification-itemclasses.md) | `ItemClasses` is an empty-looking, almost-unused lookup table that ships in **every** 2.0 client database. |
 | [Item-Fulfillment Stage Lifecycle (picked/packed/shipped) & Order Status](features/item-fulfillment-stage-lifecycle-and-order-status.md) | Every ItemFulfillment (IF) now carries an explicit **stage** — picked → packed → shipped — resolved through `ItemFulfillmentStages → ItemFulfillmentStatuses` (m |
 | [DB-free unit testing for _underscore model interceptors](features/model-interceptor-unit-testing.md) | `_underscore` shipped with **no** PHPUnit setup (no `composer.json`/`phpunit`; only vendored PhpOffice tests existed). |
 | [_Model magic-field access (__get without __isset)](features/model-magic-field-access.md) | `_Model` exposes DB columns as "magic" properties via `__get()`, but it defines **no** `__isset()`. |

package/knowledge/2.0/apps/_underscore/features/cloud-s3-helpers.md

@@ -6,8 +6,8 @@ project: _Underscore
 client: shared
 type: feature
 status: active
-updated: 2026-07-14
-owners: ["jcardinal", "bala"]
+updated: 2026-09-10
+owners: ["jcardinal", "bala", "rgirish"]
 files:
   - _underscore/Cloud.php
 related:
@@ -59,6 +59,13 @@ None — shared core helper.
   do not add your own `ContinuationToken` loop on top.
 - A bucket outside the config-default us-east-1 (e.g. `agilant-as2` in us-west-2) throws
   `AuthorizationHeaderMalformed` unless you pass `$awsRegion`.
+- **⚠ `copyFileToS3` is a single `putObject` — it CANNOT upload a file larger than 5 GB.**
+  Verified 2026-09-10 at `_underscore/Cloud.php:49`: the method issues one `putObject` call, and
+  S3 caps a single PUT at **5 GB**. There is **no `MultipartUploader` anywhere in `_underscore`
+  or `worker2`**. Anything that could produce a large artifact — a database dump above all — will
+  fail on this helper once it crosses the limit. If you need large-object upload, add
+  `MultipartUploader` explicitly; do not assume this helper scales.
+
 - **`getFileFromS3` (the GET method) is single-region.** It builds the `S3Client` with region
   `_Config::cloud('aws_region')` (the worker's own region) and only swallows HTTP 404. Reading
   an object from a bucket in a **different** region raises a `301 PermanentRedirect`, which it
@@ -67,6 +74,10 @@ None — shared core helper.
   has no region-override parameter.)
 
 ## Change history
+- 2026-09-10 — Recorded that **`copyFileToS3` (`Cloud.php:49`) is a single `putObject`**, so it
+  cannot upload an object larger than S3's 5 GB single-PUT cap, and that **no `MultipartUploader`
+  exists anywhere in `_underscore` or `worker2`**. Matters for any large-artifact upload, database
+  dumps first. (rgirish)
 - 2026-07-15 — Documented that `getFileFromS3` is single-region (client built with the worker's
   own `aws_region`, only swallows 404, re-throws `301 PermanentRedirect` for cross-region reads);
   use a direct HTTPS download for cross-region/public objects. (bala)

package/knowledge/2.0/apps/_underscore/features/item-classification-itemclasses.md

@@ -0,0 +1,127 @@
+---
+title: "ItemClasses / _Model_Client_ItemClass — who actually uses it (and why it is not free)"
+framework: "2.0"
+repo: _underscore
+project: _Underscore
+client: shared
+type: feature
+status: active
+updated: 2026-09-11
+owners: ["rgirish"]
+files:
+  - _underscore/Model/Client/ItemClass.php
+  - _underscore/Model/Client/Item.php
+  - worker/crons/toga2/prudential/transmissions_to_netsuite.php
+  - toga2-supply/src/pages/Inventory/api/InventoryApi.tsx
+related:
+  - ./netsuite-rest-client.md
+  - ./record-change-audit-log.md
+  - ../../../../clients/prudential/features/itemclasses-device-tier-data.md
+  - ../../dbchanges2/workflows/client-schema-drift-audit.md
+---
+
+## Summary
+
+`ItemClasses` is an empty-looking, almost-unused lookup table that ships in **every** 2.0 client
+database. It looks like free real estate for a new item-classification feature. It is not:
+**2 of 36 production clients already have rows in it, and they use it for two different things,
+neither of which is NetSuite's `class` field.**
+
+Read this before you plan to reuse, extend, or repurpose `ItemClasses` for any client.
+
+Audit done 2026-09-11 across all TOGA codebases and all 36 production client schemas.
+
+## Key files / entry points
+
+- **`_underscore/Model/Client/ItemClass.php`** — `_Model_Client_ItemClass`,
+  `DATABASE = _underscore::DB_CLIENT`, `TABLE = 'ItemClasses'`. Four fields only:
+  `id`, `uuid`, `code`, `name`.
+- **`_underscore/Model/Client/Item.php:23`** — the only foreign key:
+  `public $itemClassId = [self::FIELD_FOREIGNKEY, ... => '\_Model_Client_ItemClass'];`
+- **`worker/crons/toga2/prudential/transmissions_to_netsuite.php:171-178`** — the **only** code
+  anywhere that reads it (see below).
+
+## How it works
+
+### The table ships blank to everyone
+
+`ItemClasses` is part of the blank client DB, so every 2.0 tenant has the table. Having the
+table says nothing about whether the client uses it. **Check row counts, not schema.**
+
+### Who has data (prod, verified 2026-09-11)
+
+| Client | Rows in `ItemClasses` | Items tagged | What the rows actually mean |
+|---|---|---|---|
+| **Northwell** | 27 | 245 of 247 | ServiceNow **service categories** — "Print", "Computer", "Service Desk" |
+| **Prudential** | 7 | 9 of 765 | Dell/Apple **device tiers** — "LATITUDE 73XX", "MACBOOK PRO" |
+| all other 34 clients | 0 | 0 | unused |
+
+Two clients, two unrelated meanings. Neither is an "item class" in the NetSuite sense.
+
+**Canon is a false positive.** `dbchanges2/Client_Canon/2024-01-01.sql` contains `ItemClasses`
+schema changes, but production `Client_Canon` has **0 rows**. Schema history is not usage.
+
+### There is exactly one reader in the whole platform
+
+`worker/crons/toga2/prudential/transmissions_to_netsuite.php:171-178` pulls
+`ItemClasses.name` as `deviceTier` for the line-1 item of a sales order and sends it to NetSuite:
+
+```sql
+SELECT ItemClasses.name
+FROM SalesOrderItems
+INNER JOIN Items ON Items.id = SalesOrderItems.itemId
+INNER JOIN ItemClasses ON ItemClasses.id = Items.itemClassId
+WHERE SalesOrderItems.salesOrderId = SalesOrders.id AND SalesOrderItems.lineNumber = 1
+LIMIT 1
+```
+
+That cron is **disabled** — see the
+[Prudential ItemClasses data doc](../../../../clients/prudential/features/itemclasses-device-tier-data.md).
+
+**Nothing writes `itemClassId`.** No writer exists in `api2`, `worker2`, or `_underscore`.
+
+### Frontend: one real reference, and a grep trap
+
+`grep itemClass` in the frontend is misleading — most hits in `toga2-supply` are CSS
+variables like `menuItemClassNames`, not this table. The one genuine reference is
+`toga2-supply/src/pages/Inventory/api/InventoryApi.tsx:815`, requesting the column
+`item.itemClass.name`.
+
+## NetSuite `classification` — the shape you would have to map from
+
+Queried live via SuiteQL (2026-09-11): **311 classifications**, columns
+`id`, `name`, `fullname`, `isinactive`, `parent`.
+
+- **It is a tree, not a flat list.** Each row has a `parent` and a colon-separated `fullname`,
+  e.g. name `Laptop` / fullname `Technology Sales : Hardware : End User Devices : Laptop` /
+  parent `405`.
+- **⚠ `name` is NOT globally unique** — only unique within its parent. Repeats seen:
+  "Managed Services" 3x (ids 75, 395, 379), "Software" 2x (ids 3, 419), "AI & Data Sciences" 2x,
+  "Data Services" 2x.
+
+## Gotchas
+
+- **⚠ `ItemClasses.name` has a UNIQUE index (index literally named `name`).** NetSuite
+  classification names repeat, so **any attempt to load NetSuite classes into this table fails
+  until that UNIQUE is dropped.** This is the first blocker on any NetSuite-classification work.
+- **A hierarchy path column must be `TEXT`, not `varchar(512)`.** NetSuite `fullname` values are
+  long, and the 2.0 standard caps varchar at 255.
+- **The table is already `utf8mb4_0900_ai_ci`**, so new columns need no explicit `COLLATE`.
+- **`c_` custom fields are NOT declared as properties on the 2.0 Model class.** The framework
+  reads them from `CustomRecordFields` (`ItemClasses` is `Core.Records` id **105**). Confirmed:
+  no `public $c_netsuite*` property exists on any `Model/Client` class. Copy the pattern in
+  `dbchanges2/_modules/netsuite/2026-08-18 - TransferOrdersNetsuiteStatus.sql`.
+- **Check whether the client has an `ItemClassCustomFields` table before adding `c_` columns.**
+  `Client_Prudential` does not, so its `c_` columns would go directly on `ItemClasses`.
+- **"Every client has the table" ≠ "the table is free."** Repurposing `ItemClasses` org-wide
+  would break Northwell's 245 tagged items, which hold ServiceNow service categories.
+
+## Change history
+- 2026-09-11 — Documented from a full usage audit of `ItemClasses` across every TOGA codebase and
+  all 36 prod client schemas: the table ships blank to all clients but **only Northwell (27 rows,
+  ServiceNow service categories) and Prudential (7 rows, Dell device tiers) have data**, for two
+  different meanings; there is exactly **one reader** (`transmissions_to_netsuite.php:171-178`,
+  currently disabled) and **zero writers**; Canon has schema but no rows. Recorded the live
+  NetSuite `classification` shape (311 rows, a tree with repeating `name`) and the resulting
+  blocker: `ItemClasses.name` is UNIQUE and must be dropped before NetSuite classes can be
+  mapped in. (rgirish)

package/knowledge/2.0/apps/ai-bdr/features/web-funnel-app.md

@@ -6,8 +6,8 @@ project: AI-BDR
 client: shared
 type: feature
 status: active
-updated: 2026-08-26
-owners: [tcox]
+updated: 2026-09-10
+owners: [tcox, rgirish]
 files:
   - bdr/PLAN.md
   - bdr/next.config.ts
@@ -32,6 +32,9 @@ files:
   - bdr/test/fastDial.test.ts
   - bdr/eslint.config.mjs
   - bdr/amplify.yml
+  - bdr/package.json
+  - bdr/.npmrc
+  - bdr/src/components/TalosDrawer.tsx
   - bdr/src/app
   - bdr/src/app/layout.tsx
   - bdr/src/app/page.tsx
@@ -619,6 +622,28 @@ would be cached by browsers and crawlers and become painful to undo.
 
 ## Gotchas
 
+- **⚠ An `import` added without the matching `package.json` dependency only fails in Amplify —
+  never locally.** Root cause of the 2026-09-10 build break: PR #5 (`blox-talos-bdr-update`,
+  TRUE-81447) added
+  `import { TalosPanel } from "@agilant/toga-blox/dist/components/Talos/index.js"` to
+  `src/components/TalosDrawer.tsx` but **never added `@agilant/toga-blox` to `package.json`**.
+  The author's `node_modules` already had it (linked or left over from an earlier install), so
+  local `next build` was green; Amplify installs from the lockfile into a clean tree and failed
+  with `Module not found`. **Before merging any PR that adds a new bare import, grep the new
+  import specifiers against `package.json`** — a green local build proves nothing about a clean
+  install. The `local-link` workflow states the same trap from the blox side: "a link masks
+  missing dependency + peer declarations."
+- **BDR's blox dependency set (as fixed 2026-09-10):** `@agilant/toga-blox@1.1.2-production.144`
+  (pinned exactly, from the `production` dist-tag), plus
+  `@fortawesome/fontawesome-svg-core@^7.3.1` and `@fortawesome/react-fontawesome@^3.5.0`, plus a
+  new `bdr/.npmrc`. Verified: clean install exit 0, `next build` compiled, **385/385 tests pass**.
+  The `.npmrc` needs the **FontAwesome Pro** registry line and `legacy-peer-deps=true` — blox is a
+  **public** package needing no token, and blox peers still cap React at `^18` while BDR runs
+  React 19. Full detail:
+  [dynamic-publish-pipeline.md](../../toga-blox/workflows/dynamic-publish-pipeline.md#consuming-blox-which-registry-actually-needs-a-token).
+  **Never commit the token value** — a live one was pushed in `bdr` commit `88809c3`; treat it as
+  compromised and rotate.
+
 - **"The funnel is gone / a CRM link doesn't prefill" — check the redirect FIRST.** Since
   2026-08-24 `/` 307s to `/landing`, so every symptom that used to mean "missing env" or
   "rate-limit soft-degrade" can now simply mean the request never reached `page.tsx`. Probe
@@ -754,6 +779,14 @@ would be cached by browsers and crawlers and become painful to undo.
   harness; pull it with `npx toga-ai`.
 
 ## Change history
+- 2026-09-10 — **Fixed the Amplify `Module not found` build break** and recorded its durable
+  lesson: PR #5 added a `@agilant/toga-blox` import to `TalosDrawer.tsx` without adding the
+  package to `package.json`, so it built locally (stale `node_modules`) and failed only on
+  Amplify's clean install. Added `@agilant/toga-blox@1.1.2-production.144` +
+  `@fortawesome/fontawesome-svg-core@^7.3.1` + `@fortawesome/react-fontawesome@^3.5.0` and a
+  `bdr/.npmrc` (FontAwesome Pro registry + `legacy-peer-deps=true` for the React 19 host; blox
+  itself is public and needs no token). Verified clean install, compiled build, 385/385 tests.
+  (rgirish)
 - 2026-08-26 — Env-var accounting only: recorded an **optional 8th deploy var**,
   `TOGA_SECURITY_CAMPAIGN_UUID`, declared in `.env.example` and deliberately **left unset**.
   It gates `/landing`'s new real callback route (`POST /api/landing-call`), which 503s and

package/knowledge/2.0/apps/toga-blox/workflows/dynamic-publish-pipeline.md

@@ -6,12 +6,14 @@ project: TOGa Blox
 client: shared
 type: workflow
 status: active
-updated: 2026-09-02
-owners: [jcardinal, apeterson, tcox]
+updated: 2026-09-10
+owners: [jcardinal, apeterson, tcox, rgirish]
 files:
   - toga-blox/.github/workflows/publish.yml
   - toga-blox/package.json
   - toga-blox/src/utils/getFontAwesomeIcon.tsx
+  - bdr/.npmrc
+  - toga25-supply/.npmrc
 related:
   - ../architecture.md
   - ./landing-a-large-feature-branch.md
@@ -83,6 +85,50 @@ blox channel. A channel exists **only** when this repo (`toga-blox-npm`) publish
 This publish-before-build ordering is the ongoing cost of the strict 1:1 model: every
 environment needs its own maintained `_<mode>` branch in `toga-blox-npm`.
 
+## Consuming blox: which registry actually needs a token
+
+**`@agilant/toga-blox` is a PUBLIC npm package. It needs NO auth.** Verified 2026-09-10 by an
+unauthenticated request:
+
+```
+curl -s -o /dev/null -w '%{http_code}' https://registry.npmjs.org/@agilant%2Ftoga-blox
+# 200
+```
+
+The team had been copying an `.npmrc` carrying **two** tokens into each consumer, believing the
+`@agilant` scope was private. It is not. Only **one** credential is real:
+
+| Registry | Auth needed? | Why |
+|---|---|---|
+| `registry.npmjs.org` (`@agilant/toga-blox`) | **No** | Public package, HTTP 200 unauthenticated |
+| `npm.fontawesome.com` (`@fortawesome/pro-*`) | **Yes** | Paid/private packages |
+
+**FontAwesome Pro is the only thing the token is for.** blox's `src/utils/getFontAwesomeIcon.tsx`
+hard-imports `@fortawesome/pro-solid-svg-icons`, `pro-regular-svg-icons` and
+`pro-light-svg-icons`, so any consumer of blox pulls the Pro registry transitively. Proven by
+isolating `HOME` to an empty dir and installing: the failure is **E401 on `npm.fontawesome.com`
+tarballs only** — never on the `@agilant` scope.
+
+Practical consequence: a consumer's `.npmrc` needs the FontAwesome registry line + token and
+`legacy-peer-deps=true`. It does **not** need an `@agilant:registry` line or an npmjs token.
+
+### `legacy-peer-deps=true` is required on a React 19 host
+
+blox `peerDependencies` still declare React `^18`. A React 19 consumer (e.g. the `bdr` Next.js
+app) cannot resolve the install without `legacy-peer-deps=true` in `.npmrc`. The peer range is a
+declaration, not a runtime wall — blox runs fine on React 19 (see
+[local-link-into-a-consumer-app.md](./local-link-into-a-consumer-app.md) §2).
+
+### ⚠ Never commit a token VALUE in `.npmrc`
+
+Live FontAwesome tokens have been found **committed** in `toga25-supply/.npmrc` and
+`info/.npmrc`, and one was pushed in `bdr` commit `88809c3`. Treat every token found this way as
+compromised and rotate it. The correct shape is an env-var placeholder resolved at build time —
+which is exactly what blox's own `publish.yml` already does (see the "Secret hygiene done right"
+gotcha below). This is the same violation already recorded in
+[`../../../standards/frontend.md`](../../../standards/frontend.md); what is **new here is that
+only the FontAwesome token was ever needed** — the npmjs token in those files bought nothing.
+
 ## Gotchas
 
 - **⚠ There is a STALE UNDERSCORED dist-tag on the registry — `_sandbox-client` (with the
@@ -212,6 +258,15 @@ environment needs its own maintained `_<mode>` branch in `toga-blox-npm`.
   you push to a release branch.
 
 ## Change history
+- 2026-09-10 — **Corrected a long-standing team assumption: `@agilant/toga-blox` is a PUBLIC npm
+  package and needs no auth** (verified by unauthenticated `curl` → HTTP 200). The only registry
+  that requires a token is **FontAwesome Pro** (`npm.fontawesome.com`), pulled in transitively
+  because `getFontAwesomeIcon.tsx` hard-imports the `@fortawesome/pro-*` packages — proven by
+  isolating `HOME` and observing E401 on FontAwesome tarballs only. Consumers had been copying an
+  `.npmrc` with both tokens; the npmjs one was never needed. Also recorded that
+  `legacy-peer-deps=true` is required on a React 19 host (blox peers still cap at `^18`), and that
+  live tokens were found committed in `toga25-supply/.npmrc`, `info/.npmrc` and pushed in `bdr`
+  `88809c3` — rotate and replace with a build-time env-var placeholder. (rgirish)
 - 2026-09-02 — Released `1.1.2-sandbox-client.142` (base `1.1.0` → `1.1.1` on `_sandbox-client`,
   commit `543a7186`) and rolled it into `toga25-supply` (pin `1.1.1-sandbox-client.140` →
   `1.1.2-sandbox-client.142`, clean `npm install`, `tsc --noEmit` zero errors). The documented

package/knowledge/2.0/apps/worker2/features/creating-worker-actions.md

@@ -6,13 +6,15 @@ project: Worker
 client: shared
 type: feature
 status: active
-updated: 2026-09-02
-owners: [jcardinal, dfranks, mhammontree, tcox, bala, ajean]
+updated: 2026-09-10
+owners: [jcardinal, dfranks, mhammontree, tcox, bala, ajean, rgirish]
 files:
   - worker2/Worker/
   - worker2/Controller/Index.php
   - worker2/LambdaFunctions/JobScheduler/lambda_function.py
   - _underscore/Worker.php
+  - worker2/Worker/Infrastructure/Database.php
+  - worker2/.platform/hooks/prebuild/020-install-mysql-client.sh
 related:
   - ../architecture.md
   - ./netsuite-opportunity-client-labels.md
@@ -190,6 +192,40 @@ The EB worker dispatcher (`Controller/Index.php::worker()`) wraps your action ca
 > It now captures **both** success results and failure text. See
 > [architecture.md](../architecture.md) for the multi-producer rename gotcha.
 
+### ⚠ A `null` return is logged as SUCCESS — "it ran green" is not evidence it did anything
+
+`Controller/Index.php:378` records `isSuccess = 1` for **any** normal return, including `null`.
+The framework has no notion of "the action did no work": an action that silently does nothing —
+or is an unfinished stub — produces a clean `WorkerJobs` row indistinguishable from a real run.
+
+Live example: **`_Worker_Infrastructure_Database::Backup()`
+(`worker2/Worker/Infrastructure/Database.php:5-15`) is a stub.** It sends a test email to a
+hardcoded address and returns `null`. Every invocation is logged as a **successful database
+backup**. Nothing is backed up.
+
+Two rules follow:
+
+1. **When you write an action, return something that proves the work happened** — a count, an
+   id list, a summary string. `return null;` on a work-performing action throws away the only
+   signal the dispatcher records.
+2. **When you audit an action, never accept a green `WorkerJobs` row as proof.** Read the
+   `output` column, and read the method. This applies to anything safety-critical (backups,
+   reconciliations, syncs) where "it's been green for months" is the expected — and worthless —
+   observation.
+
+Two related defects found in the same audit, both worth knowing before you build on this
+infrastructure:
+
+- **`_underscore/Cloud.php:49` `copyFileToS3` is a single `putObject`**, so it cannot upload
+  anything over S3's **5 GB** single-PUT cap, and there is no `MultipartUploader` anywhere in
+  `_underscore` or `worker2` — see
+  [_Cloud S3 helpers](../../_underscore/features/cloud-s3-helpers.md).
+- **`worker2/.platform/hooks/prebuild/020-install-mysql-client.sh` installs the WRONG client for
+  Aurora MySQL 3.** It installs **`mariadb105`**, whose `mysqldump` has no `--set-gtid-purged`
+  flag and emits MariaDB-versioned `/*!100xxx*/` conditional comments — comments that MySQL
+  silently **ignores on reload**, so parts of the dump vanish without any error. Any dump-based
+  work on this host needs the **MySQL** client (`mysql-community-client`), not the MariaDB one.
+
 Crucially, the worker **always returns HTTP 200, even on a throw**, so SQS deletes the message
 immediately. **There is no DLQ and no automatic retry.** A throw makes the failure *visible* (a
 failed `WorkerJobs` row to alert on) — it does **not** re-run the job.
@@ -464,6 +500,18 @@ Rules: rename **both sides in one PR and one deploy**; grep every repo for the o
   commit-before-SQS transaction pattern that the worker relies on.
 
 ## Change history
+- 2026-09-10 — Recorded that **a `null` return is stamped `isSuccess = 1`**
+  (`Controller/Index.php:378`), so an action that does nothing is logged as a successful run —
+  with the live proof that `_Worker_Infrastructure_Database::Backup()`
+  (`Worker/Infrastructure/Database.php:5-15`) is a stub that emails a hardcoded address, returns
+  `null`, and has therefore been reporting successful database backups while backing up nothing.
+  Added the two rules: return a proof-of-work value from every action, and never treat a green
+  `WorkerJobs` row as evidence for a safety-critical job. Also recorded two neighbouring defects
+  found in the same audit: `_Cloud::copyFileToS3` is a single `putObject` (5 GB ceiling, no
+  `MultipartUploader` in the codebase), and the EB prebuild hook
+  `020-install-mysql-client.sh` installs **`mariadb105`**, whose `mysqldump` lacks
+  `--set-gtid-purged` and writes `/*!100xxx*/` comments that MySQL silently drops on reload —
+  the wrong client for Aurora MySQL 3. (rgirish)
 - 2026-09-02 — Added the corollary that an action must **never sleep-wait for a third-party API
   rate budget** (it burns the 300s cap and the failure is unrecoverable — no retry, no DLQ); bulk
   work yields and re-enqueues, event-driven work proceeds over budget counted and alarmed. (ajean)

package/knowledge/INDEX.md

@@ -18,10 +18,10 @@ _Auto-generated by `knowledge.js index`. Do not hand-edit._
 
 ## 2.0 framework
 
-- **_underscore** (_Underscore) _(framework core)_ — 82 doc(s) → [2.0/apps/_underscore/INDEX.md](2.0/apps/_underscore/INDEX.md)
+- **_underscore** (_Underscore) _(framework core)_ — 83 doc(s) → [2.0/apps/_underscore/INDEX.md](2.0/apps/_underscore/INDEX.md)
 - **worker2** (Worker) — 68 doc(s) → [2.0/apps/worker2/INDEX.md](2.0/apps/worker2/INDEX.md)
 - **api2** (API) — 25 doc(s) → [2.0/apps/api2/INDEX.md](2.0/apps/api2/INDEX.md)
-- **dbchanges2** (Database Changes) _(framework core)_ — 17 doc(s) → [2.0/apps/dbchanges2/INDEX.md](2.0/apps/dbchanges2/INDEX.md)
+- **dbchanges2** (Database Changes) _(framework core)_ — 18 doc(s) → [2.0/apps/dbchanges2/INDEX.md](2.0/apps/dbchanges2/INDEX.md)
 - **toga2-supply** (TOGa Supply) — 9 doc(s) → [2.0/apps/toga2-supply/INDEX.md](2.0/apps/toga2-supply/INDEX.md)
 - **saml** (SAML SSO Gateway) — 6 doc(s) → [2.0/apps/saml/INDEX.md](2.0/apps/saml/INDEX.md)
 - **toga2-view** (TOGa View Frontend) — 12 doc(s) → [2.0/apps/toga2-view/INDEX.md](2.0/apps/toga2-view/INDEX.md)

package/knowledge/clients/nychh/profile.md

@@ -18,7 +18,7 @@ project: _Underscore
 client: nychh
 type: profile
 status: active
-updated: 2026-09-10
+updated: 2026-09-11
 owners: ["jcardinal", "apeterson", "bala", "akhokhani"]
 files:
   - dbchanges2/Client_Nychh/2026-09-02a - TransferOrderNetsuitePushInterceptor.sql
@@ -115,6 +115,16 @@ table views. Client-specific DB change-sets live in `dbchanges2/Client_Nychh/`.
   written. Proven on IF `6138135` (Eastern 2025-09-04 17:26:58). Fixes and the standing "cursor is
   always Eastern" rule live in the
   [per-client sync feature doc](../../1.0/apps/worker/features/netsuite-togasupply-per-client-sync.md).
+- **ITEM_RECEIPTS froze on a case-mismatched serial → duplicate-`Units` EV-10/1062, root-caused + fixed
+  (2026-09-11, fix NOT deployed).** The receipts feed threw before its cursor PUT (freezing it and
+  ITEM_FULFILLMENTS behind it) because `syncItemReceiptFromNetsuite` keyed its existing-`Units` PHP
+  lookup on the DB's stored serial casing (`'na100'`) but read it with the uppercased serial (`'NA100'`);
+  the missed row took the create path and collided on the case-insensitive `Units.itemId_serialNumber`
+  unique key → MySQL 1062 / api2 EV-10. Proven on `Client_Nychh.Units` 23400-23409
+  (serials `'na100'..'na109'`, `c_netsuiteInternalInventoryAssignmentId` NULL). Library-only fix
+  (`strtoupper()` on both the key and the reads). This is a **different** duplicate from the open
+  sales-order `Items` duplicate below (658-BFZH). Mechanism + the EV-10 → `Logs_Nychh.Api` diagnosis
+  traps: [per-client sync doc](../../1.0/apps/worker/features/netsuite-togasupply-per-client-sync.md).
 - **NYCHH sync scope + data-gap scale + backfill approach (2026-09-09).**
   - **Scope = 22 NetSuite customers:** parent **28908** "NYC Health + Hospitals" + 21 hospital child
     customers (`24145, 29273, 29276, 31584, 31910-31916, 31918-31925, 32229, 33674`).

package/knowledge/clients/prudential/INDEX.md

@@ -5,6 +5,7 @@
 | [Prudential: Dell ASN units PRE/POST interceptor (legacy key + flat tracking)](features/dell-asn-units-interceptor.md) | 2.0 | After the tracking-number bridge migration, the ASN unit route was renamed (`advance-shipping-notice-units` → `advance-shipping-notice-item-units`), so the inhe |
 | [Prudential: Dell LCH IOP transmissions (LCHRequestV2)](features/dell-lch-iop-transmissions.md) | 1.0 | Outbound order transmissions from the 1.0 worker tier to Dell's Lifecycle Hub (LCH) ITSM integration. |
 | [Prudential: Device information import + unit→contact linking (import_device_information.php)](features/device-information-import-and-contact-linking.md) | 1.0 | Prudential's **device-sync** cron (`worker/crons/toga2/prudential/import_device_information.php`) pulls device/asset records (from ServiceNow / the Dell CMDB fe |
+| [Prudential: ItemClasses device-tier data is dead (and how that was proved)](features/itemclasses-device-tier-data.md) | 2.0 | `Client_Prudential.ItemClasses` held 7 hand-seeded Dell/Apple **device tiers** ("LATITUDE 73xx", "MACBOOK PRO", …) tagged onto **9 of 765** items. |
 | [Prudential: OneUptime order-pipeline backlog monitors (Monitor/Prudential/*)](features/oneuptime-order-pipeline-monitors.md) | 2.0 | Three worker2 OneUptime push monitors (TRUE-80587) that watch the Prudential/Dell order pipeline for **stalls**, which were previously invisible — a stuck pipel |
 | [Prudential: order email PDF attachments (which guide goes on which email)](features/order-email-pdf-attachments.md) | 1.0 | Every customer-facing Prudential order email carries S3-hosted PDF guides, and **which** guide is attached is decided by the service request type. |
 | [Prudential: Service Request Regional Address Validation](features/service-request-address-validation.md) | 2.0 | The `prePost` interceptor on `_Model_Prudential_ServiceRequest` validates `deliverToAddress` fields differently depending on which Prudential regional customer |

package/knowledge/clients/prudential/features/itemclasses-device-tier-data.md

@@ -0,0 +1,108 @@
+---
+title: "Prudential: ItemClasses device-tier data is dead (and how that was proved)"
+framework: "2.0"
+repo: dbchanges2
+project: Database Changes
+client: prudential
+type: client-feature
+status: active
+updated: 2026-09-11
+owners: ["rgirish"]
+files:
+  - dbchanges2/Client_Prudential/2024-01-01.sql
+  - dbchanges2/Client_Prudential/2026-09-11 - ClearItemClasses.sql
+  - worker/crons/toga2/prudential/transmissions_to_netsuite.php
+  - worker/schedules/cron.worker.sync.json
+related:
+  - ../profile.md
+  - ../../../2.0/apps/_underscore/features/item-classification-itemclasses.md
+  - ../../../2.0/apps/_underscore/features/record-change-audit-log.md
+  - ../../../1.0/apps/worker/workflows/tracing-a-worker-cron-run-in-production.md
+---
+
+## Summary
+
+`Client_Prudential.ItemClasses` held 7 hand-seeded Dell/Apple **device tiers**
+("LATITUDE 73xx", "MACBOOK PRO", …) tagged onto **9 of 765** items. The data was seeded once by
+SQL in 2023, never maintained, is partly wrong, and **nothing reads or writes it today**. It was
+cleared on 2026-09-11 to free the table for real NetSuite item classification later.
+
+The second half of this doc is the **4-source method used to prove "this field is dead"** —
+reusable for any field on any client.
+
+## How it works (what the data was)
+
+Source is a hardcoded seed block in `dbchanges2/Client_Prudential/2024-01-01.sql:435-449`:
+7 `INSERT INTO ItemClasses`, then a per-`partNumber` `UPDATE` stamping `Items.itemClassId`.
+**No API, no external feed, no sync.** That is the entire origin.
+
+The one consumer was `worker/crons/toga2/prudential/transmissions_to_netsuite.php:171-178`,
+which sent `ItemClasses.name` to NetSuite as `deviceTier`.
+
+## Proving a field is dead — the 4-source method
+
+Run all four. Any one alone is weak; together they are conclusive.
+
+**1. Grep for readers and writers in every repo.**
+One reader (`transmissions_to_netsuite.php`), zero writers in `api2`, `worker2`, `_underscore`.
+Watch for frontend grep noise — `itemClass` matches CSS variable names like `menuItemClassNames`.
+
+**2. Check the field-change audit log — absence is evidence.**
+Resolve the field id first (`Logs_*` and `Core` are on different clusters, so this is two
+queries — see [Record Change Audit Log](../../../2.0/apps/_underscore/features/record-change-audit-log.md)):
+
+- `Core.RecordFields` id **605** = `Items.itemClassId`; `Core.Records` id **21** = `Items`,
+  id **105** = `ItemClasses`.
+- `Logs_Prudential.RecordField` has **zero rows** for field 605, ever. Zero log rows on record 105.
+
+**Prove the logging itself works, or "no rows" means nothing.** Item logging is demonstrably
+live: 1,963 log rows across 353 items, current through today, tracking `partNumber`,
+`description`, `isFulfillable`, `catalogId`. So `itemClassId` simply never changes.
+
+**3. Scan the inbound API payloads.**
+Zero of **3,808** `/v2/items` calls in September carried an `itemClass` key. Items arrive from a
+NetSuite sync cron — `POST /v2/items` from `34.214.204.95` (`apiId` 5) — with payload shape
+`{partNumber, description, inventoryType, catalog:{name}, c_netsuiteInternalItemId, isFulfillable}`.
+**No `itemClass` field.** That is why new items never get a class, and why only 9 of 765 are tagged.
+
+**4. Check the consumer cron's `active` flag, then `git log` it.**
+`worker/schedules/cron.worker.sync.json:441` — `"active": 0` on "Transmissions to Netsuite".
+Disabled **2026-07-17** by Jeff Cardinal, commit `14570def` ("Add careOf & skip Apple; disable
+Netsuite cron"), branch `_production`. See
+[tracing a worker cron run](../../../1.0/apps/worker/workflows/tracing-a-worker-cron-run-in-production.md)
+for the `active`-flag semantics.
+
+## Gotchas
+
+- **⚠ The surviving tags were partly wrong.** 2 of the 9: item 3512 (`MRW23XX/A`,
+  "MacBook Pro 16 M3") was tagged **MACBOOK AIR**; item 3513 (`920-008219`, a Logitech keyboard)
+  was tagged **MACBOOK PRO**. Stale hand-seeded lookup data degrades silently — do not trust it
+  because it exists.
+- **Clear the FK before the parent rows.** `Items_itemClassId` is the only FK referencing
+  `ItemClasses` (verified via `information_schema.KEY_COLUMN_USAGE` on `Client_Prudential`), so
+  the null-out of `Items.itemClassId` must run **before** the parent rows are removed.
+- **Northwell was NOT touched.** Its 27 ServiceNow service categories and 245 tagged items are
+  still live. Open question, not yet decided: whether to move Northwell's rows to a separate
+  table if `ItemClasses` gets repurposed org-wide.
+
+## The migration
+
+`dbchanges2/Client_Prudential/2026-09-11 - ClearItemClasses.sql` — data removal only, re-runnable,
+table and columns untouched. Two statements: null out every non-null `Items.itemClassId`, then
+empty `ItemClasses`. Order matters (see the FK gotcha above).
+
+**Deliberately scoped small.** Adding the NetSuite classification columns
+(`c_netsuiteInternalClassificationId`, `c_netsuiteFullName`, `c_netsuiteParentId`), dropping the
+UNIQUE on `name`, and registering the `CustomRecordFields` rows for `recordId` 105 is a
+**separate later task**. The traps already found for it are recorded in
+[ItemClasses / _Model_Client_ItemClass](../../../2.0/apps/_underscore/features/item-classification-itemclasses.md).
+
+## Change history
+- 2026-09-11 — Cleared the 7 stale device-tier rows and the 9 item tags via
+  `2026-09-11 - ClearItemClasses.sql` (null the FK first — `Items_itemClassId` is the only FK).
+  Documented the 4-source proof that the data was dead: one reader / zero writers,
+  zero `Logs_Prudential.RecordField` rows for `Core.RecordFields` id 605 against 1,963 live rows
+  on other Item fields, zero of 3,808 September `/v2/items` payloads carrying `itemClass`, and the
+  sole consumer cron `"active": 0` since 2026-07-17 (commit `14570def`). Also recorded that 2 of
+  the 9 surviving tags were plainly wrong. Column additions deliberately deferred to a later task.
+  (rgirish)

package/knowledge/clients/prudential/features/transmit-ordershipped-email.md

@@ -6,7 +6,7 @@ project: Worker
 client: prudential
 type: client-feature
 status: active
-updated: 2026-08-31
+updated: 2026-09-11
 owners: ["rgirish", "bala"]
 files:
   - worker/crons/toga2/prudential/transmit_ordershipped_updates_prudential.php
@@ -86,20 +86,26 @@ TrackingNumbers WHERE purchaseOrderId = PurchaseOrders.id AND TrackingNumbers.st
 orders that genuinely qualified for a delivery email. Over 2026-07-01..07-09 this dropped 6 false
 positives (25 → 19 flagged) while retaining all 19 genuine discrepancies.
 
-## A second cron sends the same shipped email
+## A second cron sends the same shipped email — but it is DISABLED (corrected 2026-09-11)
 
-`transmissions_to_netsuite.php` (also `active: 1`) builds and sends the **same** shipped email —
-same subjects, same branch shape — and also stamps `c_dtTransmittedOrderShippedUpdateToPrudential`.
-It is easy to miss: it is not named like the other `transmit_*` crons. Any change to the shipped
-email's content or attachments must be applied to **both** files or the two senders drift.
+`transmissions_to_netsuite.php` builds and sends the **same** shipped email — same subjects, same
+branch shape — and also stamps `c_dtTransmittedOrderShippedUpdateToPrudential`. It is easy to
+miss: it is not named like the other `transmit_*` crons. Any change to the shipped email's content
+or attachments must be applied to **both** files or the two senders drift.
+
+> **⚠ It is `"active": 0`, not `active: 1` as this page said until 2026-09-11.**
+> `worker/schedules/cron.worker.sync.json:441` — disabled **2026-07-17** by Jeff Cardinal, commit
+> `14570def` ("Add careOf & skip Apple; disable Netsuite cron") on `_production`. So **it has not
+> been sending anything since then**, and it is not currently a live duplicate sender. Keep the
+> two files in sync anyway — it can be switched back on with one flag.
 
 **And it does not stop at the shipped email — it also sends the two *delivered* emails.**
 `transmissions_to_netsuite.php` carries "Prudential: New hire equipment has been delivered"
 (~L1765) and "Prudential: Your equipment has been delivered" (~L2149), the **same two subjects**
 that `transmit_closecomplete_updates_prudential.php` sends — except the `transmissions_to_netsuite`
-versions make **no `addAttachment()` calls at all**. Whether both crons fire for the same order was
-not established (2026-08-31); if they do, the customer receives a duplicate delivered email, one
-copy of which is missing the guides. Establish this before touching either delivered path.
+versions make **no `addAttachment()` calls at all**. The open question from 2026-08-31 — whether
+both crons fire for the same order and send a duplicate delivered email — is **moot while this
+cron is off** (see the box above). It becomes live again the moment anyone sets `"active": 1`.
 
 It was also the last Prudential cron still calling `file_get_contents()` directly for its PDFs and
 calling `addAttachment()` unconditionally — so a failed S3 pull threw and killed the batch, and a
@@ -201,6 +207,10 @@ stamp (crash hits the next iteration). With multiple New-type POs, a crash on PO
 all subsequent POs in the same run.
 
 ## Change history
+- 2026-09-11 — **Correction: `transmissions_to_netsuite.php` is `"active": 0`, not `active: 1`.**
+  Disabled 2026-07-17 (commit `14570def`) in `cron.worker.sync.json:441`, so the "second shipped
+  sender" and the suspected duplicate *delivered* email are dormant, not live. Found while
+  auditing that cron as the only reader of `ItemClasses`. (rgirish)
 - 2026-08-31 — TRUE-81393 / PR #1707 (merged to `_production`): the shipped email's
   `$attachmentText` paragraph was unconditional while each attach was guarded, so a failed S3 pull
   produced copy promising guides that were not attached — and it said "guides" even for a single

package/knowledge/clients/prudential/profile.md

@@ -15,7 +15,7 @@ project: _Underscore
 client: prudential
 type: profile
 status: active
-updated: 2026-09-10
+updated: 2026-09-11
 owners: ["jcardinal", "rgirish", "bala", "mhammontree"]
 files: []
 related:
@@ -31,6 +31,7 @@ related:
   where each code is logged, and how to tell "we refused it" from "they never sent it".
 - features/supply-orders-csv-export.md
   - features/order-email-pdf-attachments.md
+  - features/itemclasses-device-tier-data.md
 ---
 
 ## Summary

package/package.json

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