toga-ai 1.0.751 → 1.0.753

package/knowledge/1.0/apps/library/features/netsuite-sync-alert-monitor.md

@@ -104,18 +104,22 @@ that worker job does the syncing, this library class notices when it stops.
   checkpoints mean anything; and a client that is held / never transacts supply (AIG) must be
   left **off** this list or it produces permanent false-positive tickets.
 
-- **⚠ The pending cursor-rename in the sync will SILENTLY BLIND this monitor (BUILT 2026-09-02, not yet
-  deployed).** The per-record resume cursor work on the sync renames each section's position key from
-  `NETSUITE_LAST_SYNC_DATETIME_<SECTION>` to `NETSUITE_LAST_SYNC_CURSOR_<SECTION>` (value becomes
-  `"<lastmodifieddate>|<netsuite id>"`). This monitor's `NETSUITE_SYNC_PARAMETER_KEYS` still lists the old
-  `DATETIME` keys, so after the rename its `where..in` `/parameters` read matches **zero rows** and it
-  reports OK forever — no stale-checkpoint alerts. The sync developer **intentionally left the monitor
-  un-updated** this session (accepted gap). When the rename deploys, update `NETSUITE_SYNC_PARAMETER_KEYS`
-  to the `CURSOR` names **and** parse the `<date>|<id>` value (`strtotime` the part before `|`) before the
-  48h compare. See the [per-client sync doc](../../worker/features/netsuite-togasupply-per-client-sync.md).
+- **⚠ THIS MONITOR IS NOW BLIND — the cursor-rename shipped 2026-09-02 and this monitor was NOT updated.**
+  The sync's per-record resume cursor deployed to prod 2026-09-02 (worker `06e8f9ef` + library `3a70b59c`),
+  renaming each section's position key from `NETSUITE_LAST_SYNC_DATETIME_<SECTION>` to
+  `NETSUITE_LAST_SYNC_CURSOR_<SECTION>` (value now `"<lastmodifieddate>|<netsuite id>"`). This monitor's
+  `NETSUITE_SYNC_PARAMETER_KEYS` still lists the old `DATETIME` keys, so its `where..in` `/parameters` read
+  now matches **zero rows** and it reports OK forever — **no stale-checkpoint alerts fire**. This was an
+  accepted gap at deploy time, but it is now live. **FIX OWED:** update `NETSUITE_SYNC_PARAMETER_KEYS` to the
+  `CURSOR` names **and** parse the `<date>|<id>` value (`strtotime` the part before `|`) before the 48h
+  compare. See the [per-client sync doc](../../worker/features/netsuite-togasupply-per-client-sync.md).
 
 ## Change history
 
+- 2026-09-02 — **The sync's `NETSUITE_LAST_SYNC_DATETIME_*` → `NETSUITE_LAST_SYNC_CURSOR_*` rename SHIPPED to
+  prod (worker `06e8f9ef` + library `3a70b59c`), so this monitor is now BLIND** — its `where..in` read matches
+  zero rows and it reports OK forever. Monitor was not updated with the rename (accepted gap, now live). Fix
+  owed: update `NETSUITE_SYNC_PARAMETER_KEYS` to the CURSOR names + `strtotime` the part before `|`. (jcardinal)
 - 2026-09-02 — Flagged that the sync's pending `NETSUITE_LAST_SYNC_DATETIME_*` →
   `NETSUITE_LAST_SYNC_CURSOR_*` key rename (BUILT, not yet deployed) will make this monitor match zero rows
   and stop alerting; it was intentionally left un-updated. Update the key list + parse the `<date>|<id>`

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

@@ -418,9 +418,14 @@ enable flags** and an optional `$monitorTogadeskDepartmentIds[]`:
   still had a RESTRICT child (item receipt `ItemReceiptItems.purchaseOrderItemId`, or an SO/TO link).
   Fixed to **unlink first, then delete**: delete the four PO bridge routes, unhook item receipts with
   `PUT /item-receipt-items/{uuid}` `['purchaseOrderItem' => null]`, then DELETE the PO line kept
-  **throwing** as the fail-loud backstop — mirroring the SALES_ORDERS cleanup. Written + reviewed,
-  **not yet committed/deployed**; carries a schema deploy dependency (nullable
-  `ItemReceiptItems.purchaseOrderItemId`). Full detail, the mirror-NetSuite decision, and the api2
+  **throwing** as the fail-loud backstop — mirroring the SALES_ORDERS cleanup. **Now committed to
+  `_production` and confirmed live on Elite** (carried a schema deploy dependency: nullable
+  `ItemReceiptItems.purchaseOrderItemId`). **Follow-up fix same day:** the bridge-clear step's **GET**
+  was also a throwing `send()` — a client without an ACL grant on the transfer-order bridge routes
+  (Elite, Core records 329/330) got **403 EZ-2** and re-froze; the bridge/link GET loop now passes
+  `$throwExceptionOnApiError=false` and **skips** a link table on a no-access response (403 OR EZ-2),
+  while any other failure still throws. (Ops note: merging `library` to `_production` does not deploy
+  the worker boxes — a worker deploy does.) Full detail, the mirror-NetSuite decision, and the api2
   bridge-route-key mechanic (kebab→camel, no pluralization) live on
   [NetSuite → TOGa Supply per-client sync](../../worker/features/netsuite-togasupply-per-client-sync.md)
   (2026-09-02). (jcardinal)

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

@@ -92,12 +92,14 @@ its IDLE write. **There is no timeout, memory cap, or resource limit anywhere in
 never *tune the window size down*. (Corollary: a window that has grown back to the cap is positive
 evidence the section is completing.)
 
-### Per-record resume cursor — checkpoint after EACH record, not window-end (BUILT 2026-09-02, NOT yet deployed)
+### Per-record resume cursor — checkpoint after EACH record, not window-end (LIVE 2026-09-02)
 
 The historical weakness of window-end-only checkpointing: a mid-window crash (poison record, or the
 log-DB doom loop above) re-processes the **whole** window every run — the giant-fulfillment doom loop is a
 direct consequence. This change converts the checkpoint to **per-record keyset (seek) resume** so a
-transient crash resumes at the next record instead of redoing the window.
+transient crash resumes at the next record instead of redoing the window. **Deployed to prod
+2026-09-02** — worker commit `06e8f9ef` + library commit `3a70b59c` (both tips of `_production`), with the
+rename migration run on every client DB first (see the deploy-order gotcha below).
 
 - **Key rename per section:** `NETSUITE_LAST_SYNC_DATETIME_<SECTION>` → `NETSUITE_LAST_SYNC_CURSOR_<SECTION>`,
   value format **`"<lastmodifieddate>|<netsuite internal id>"`**. The id breaks same-second ties.
@@ -109,10 +111,16 @@ transient crash resumes at the next record instead of redoing the window.
   already carried it).
 - **Save after EACH main record** (one PUT of `lastmod|id`); on a clean window with 0 records, PUT
   `"<windowTop>|0"` so empty date ranges still advance. No new `try/catch` — stays fail-loud.
-- **Migration is MANDATORY with the code (see the reset trap in Gotchas):**
+- **Migration is MANDATORY, and runs BEFORE the code (see the deploy-order gotcha in Gotchas):**
   `dbchanges2/Client/2026-09-02b - NetsuiteSyncCursorRename.sql` (Client fan-out) renames the keys **and**
-  appends `|0` to carry the value across; safe to re-run. The new-client seed module
-  (`dbchanges2/_modules/netsuite/2026-08-05 - CLEAN NETSUITE CLINET.SQL`) was updated to CURSOR.
+  appends `|0` to carry the value across; safe to re-run. It was run on all client DBs first, then the
+  code deployed — the required order.
+- **⚠ OPEN follow-up — new-client seed was edited in place (dbchanges2 rule violation).** The seed module
+  `dbchanges2/_modules/netsuite/2026-08-05 - CLEAN NETSUITE CLINET.SQL` had its 6 seed rows **renamed in
+  place** to CURSOR keys with `|0`. That breaks the dbchanges2 "never edit an already-applied file" rule and
+  the client-schema drift audit. **Revert that file and add a NEW dated `_modules/netsuite/` file** carrying
+  the same guarded `UPDATE ... WHERE key LIKE 'NETSUITE_LAST_SYNC_DATETIME_%'` so future new clients land on
+  CURSOR keys. Still uncommitted in the working tree.
 
 ### ⚠ Per-record isolation is SECTION-SPECIFIC — and SALES_ORDERS has NONE (corrected 2026-08-17)
 
@@ -330,9 +338,11 @@ Per-client `Parameters` table (2.0 client DB, e.g. `Client_Canon.Parameters`; co
 
 Parameters are stored **per client DB** but accessed **through the TOGa2 API**, not direct SQL.
 
-**Pending rename (BUILT 2026-09-02, not yet deployed):** the position keys become
-`NETSUITE_LAST_SYNC_CURSOR_<SECTION>` with value `"<lastmodifieddate>|<netsuite internal id>"` — see the
-per-record resume cursor in *How it works*. The `NETSUITE_EXECUTION_MODE_*` keys are unchanged.
+**Key rename (LIVE 2026-09-02):** the position keys are now
+`NETSUITE_LAST_SYNC_CURSOR_<SECTION>` with value `"<lastmodifieddate>|<netsuite internal id>"` for all 6
+sections — see the per-record resume cursor in *How it works*. The `NETSUITE_EXECUTION_MODE_*` keys are
+unchanged. Renamed on every client DB by `Client/2026-09-02b - NetsuiteSyncCursorRename.sql` (run before
+the code deploy).
 
 ## Client variations
 
@@ -488,6 +498,19 @@ per-record resume cursor in *How it works*. The `NETSUITE_EXECUTION_MODE_*` keys
   `$dateField='lastmodifieddate'` and the engine calls it without the 4th arg. So a backdated
   `trandate` is irrelevant to whether an invoice imports, and a just-modified invoice still won't
   import until it is >24h old (the upper-bound cap).
+- **⚠ DEPLOY ORDER: the cursor-rename migration MUST run on EVERY client DB before the worker/library
+  deploy — there is NO old-key fallback in code.** `Client/2026-09-02b - NetsuiteSyncCursorRename.sql`
+  renames `NETSUITE_LAST_SYNC_DATETIME_<SECTION>` → `NETSUITE_LAST_SYNC_CURSOR_<SECTION>`. If the code
+  ships first, `startModeIteration()` reads a CURSOR key that doesn't exist yet and falls back to
+  `MIN_DATETIME_TO_CHECK_FOR_NETSUITE_DATA` (= `'2018-01-01'` for 17 of 18 clients) — re-scanning ~8 years
+  across all sections and all clients at once, a thundering herd against NetSuite + api2. Both the php and
+  sql reviewers flagged this as critical. The 2026-09-02 deploy followed the correct order (migration on all
+  client DBs first, then code). Same rule for any future position-key rename: schema first, code second.
+- **Per-record checkpoint PUT multiplies api2 round-trips on high-count catch-up windows (tuning note, not
+  shipped).** The per-record resume cursor does one `App_Api_Toga2::send` PUT per record. On a big backfill
+  window (e.g. sales orders / POs) that is one extra api2 round-trip per record. Optional future tuning:
+  batch the checkpoint every N records while still writing it **before** the next record's dispatch (so
+  crash-resume stays correct). Not built.
 - **A parse error in the shared `library/app/api/netsuite/rest.php` takes down EVERY client at
   once (tier-wide outage).** All wrappers autoload `App_Api_Netsuite_Rest` in the pre-section
   LOOKUPS/setup phase of `common_sync_togasupply.php` (~line 433). Because PHP parses the whole
@@ -626,8 +649,8 @@ per-record resume cursor in *How it works*. The `NETSUITE_EXECUTION_MODE_*` keys
   — for the throwing order.
 
 - **⚠ The PURCHASE_ORDERS cleanup DELETE froze the whole section when NetSuite drops a PO line that
-  still has an item receipt or SO/TO link (fixed 2026-09-02, `library` only — WRITTEN + REVIEWED,
-  NOT yet committed/deployed).** Same freeze class as the SALES_ORDERS renumber-DELETE above, on a
+  still has an item receipt or SO/TO link (fixed + DEPLOYED 2026-09-02, `library` only — committed to
+  `_production`, confirmed live on Elite).** Same freeze class as the SALES_ORDERS renumber-DELETE above, on a
   different path. `syncPurchaseOrderFromNetsuite`'s cleanup loop ("remove remaining items if
   updating", `library/app/api/toga2.php`) deleted a leftover Toga PO line with a **bare, throwing**
   `send()` DELETE `/purchase-order-items/{uuid}`. When the dropped line still had an item receipt
@@ -658,6 +681,26 @@ per-record resume cursor in *How it works*. The `NETSUITE_EXECUTION_MODE_*` keys
     `dbchanges2/Client/2026-06-19a - TransferOrderSchemaFixes.sql` (section 7, guarded/re-runnable).
     **Confirm that migration has run on every client DB before deploying the code fix**, or the PUT
     `purchaseOrderItem = null` fails.
+  - **⚠ Follow-up (deployed same day): the bridge-CLEAR GET must TOLERATE a 403 for a client that
+    lacks the bridge (transfer-order routes).** After the first fix deployed, Elite hit a NEW freeze.
+    The cleanup **GETs** each of the four bridge routes to find rows to remove, and that GET was a
+    **throwing** `send()`. Elite has **no ACL grant** on the transfer-order bridge Core records (**329**
+    `purchase-order-items-transfer-order-items`, **330** `transfer-order-items-purchase-order-items`)
+    because Elite does not use transfer orders, so `GET /purchase-order-items-transfer-order-items`
+    returned **403 EZ-2** ("no permission to read the specified fields", roleIds [1,3]) → the whole
+    section aborted, watermark still frozen at 2025-10-13. **Fix:** the bridge/link GET loop now calls
+    `App_Api_Toga2::send(..., $throwExceptionOnApiError = false)` and, on a **no-access** response
+    (status **403** OR error code **EZ-2**), **skips that link table** — no access means the client
+    cannot have rows there, so there is nothing to clear. **Any other failure still throws** (fail
+    loud). Covers both transfer-order bridge routes. Confirmed: Elite's PO import unfroze after
+    redeploy.
+  - **Confirming the new cleanup code is actually live (from `Logs_<Client>.Api`).** A run on the
+    **NEW** code shows, before the PO-line delete: `GET /purchase-order-item-sales-order-items`,
+    `GET /sales-order-item-purchase-order-items`, `GET /purchase-order-items-transfer-order-items`
+    (may be **403 and skipped**), `GET /item-receipt-items`, then `PUT /item-receipt-items/{uuid}`
+    (the unhook). The **OLD** code goes straight from the purchase-order PUT to a bare
+    `DELETE /purchase-order-items/{uuid}` with none of those. This call pattern is the ground truth
+    for whether the worker box is running the fix.
   - **api2 route mechanics (verified against `api2/Component/Api/V2/V2.php`).** For these list/bridge
     routes the response collection key is a **plain kebab→camel conversion of the route, no
     pluralization** (`/purchase-order-item-sales-order-items` → `purchaseOrderItemSalesOrderItems`).
@@ -672,6 +715,14 @@ per-record resume cursor in *How it works*. The `NETSUITE_EXECUTION_MODE_*` keys
     "move the receipt to the surviving line" is **unsafe** — double-count / `UNIQUE(itemReceiptId,
     purchaseOrderItemId)` collision. Only clean cases self-heal; tangled ones must throw for a human.
 
+- **⚠ Merging `library` to `_production` on GitHub does NOT update the running worker EC2 boxes — a
+  worker DEPLOY does.** After a `library` merge to `_production`, the worker instances keep running the
+  **OLD** `library` code across cron cycles until an actual worker deploy pushes it onto the boxes. On
+  2026-09-02 the PO-cleanup fix merged at 14:48 but the worker ran old code for multiple 5-min cron
+  cycles (the api2 log still showed the old bare DELETE, none of the new calls) until it was deployed.
+  **Before concluding a `library` fix "didn't work," confirm the worker box is actually running it** —
+  the `Logs_<Client>.Api` call pattern is the ground truth (see the PO-cleanup call-pattern note above).
+
 - **⚠ Inventory-adjustment sync: two shared-engine bugs + it is still SOAP (2026-08-28).** Both fixed
   in `syncInventoryAdjustmentFromNetsuite` (`library/app/api/toga2.php`) and reachable by any client
   running inventory adjustments: (a) the stale-item prune deleted an `InventoryAdjustmentItem` before
@@ -1044,8 +1095,16 @@ per-record resume cursor in *How it works*. The `NETSUITE_EXECUTION_MODE_*` keys
 
 ## Change history
 
-- 2026-09-02 — **Per-record resume cursor BUILT (shared: `worker` + `library` + `dbchanges2`; pending
-  review + deploy, NOT shipped).** Converts the section checkpoint from window-end-only to per-record
+- 2026-09-02 — **Per-record resume cursor DEPLOYED to prod (shared: `worker` + `library` + `dbchanges2`).**
+  Now live: worker commit `06e8f9ef` + library commit `3a70b59c` (tips of `_production`); rename migration
+  `Client/2026-09-02b - NetsuiteSyncCursorRename.sql` run on all client DBs **before** the code. Recorded the
+  deploy-order rule (no old-key fallback — code-first would fall back to `MIN_DATETIME_TO_CHECK_FOR_NETSUITE_DATA`
+  = `'2018-01-01'` and thundering-herd re-scan ~8 years for all clients; php + sql reviewers flagged it
+  critical). Two open items: (1) the new-client seed `_modules/netsuite/2026-08-05 - CLEAN NETSUITE CLINET.SQL`
+  was edited in place (dbchanges2 rule violation) — revert + add a new dated file; (2) optional tuning — batch
+  the per-record checkpoint PUT every N records on high-count windows. Both still uncommitted. (jcardinal)
+- 2026-09-02 — **Per-record resume cursor BUILT (shared: `worker` + `library` + `dbchanges2`; shipped later
+  the same day — see entry above).** Converts the section checkpoint from window-end-only to per-record
   keyset resume so a mid-window crash (poison record or the log-DB doom loop) resumes at the next record
   instead of re-processing the whole window. Position key `NETSUITE_LAST_SYNC_DATETIME_<SECTION>` →
   `NETSUITE_LAST_SYNC_CURSOR_<SECTION>`, value `"<lastmodifieddate>|<netsuite id>"` (id breaks same-second
@@ -1069,21 +1128,30 @@ per-record resume cursor in *How it works*. The `NETSUITE_EXECUTION_MODE_*` keys
   1048 "quantityAdjustBy cannot be null" on NetSuite serialized-detail sub-lines. The null-skip reached prod
   ~2026-09-01 afternoon; Issue 542 stopped 09-01 14:08. Recorded that `3-IDLE`-crawl = the same poison-record
   shrink as `1-RUNNING`, not a slow section. (jcardinal)
-- 2026-09-02 — **PURCHASE_ORDERS cleanup DELETE freeze fixed (shared, `library` only — WRITTEN +
-  REVIEWED, NOT yet committed/deployed).** `syncPurchaseOrderFromNetsuite`'s "remove dropped items"
-  cleanup deleted a NetSuite-dropped PO line with a bare throwing DELETE; a leftover item receipt
-  (`ItemReceiptItems.purchaseOrderItemId`, RESTRICT) or SO/TO link → 1451 → EV-11 → threw → froze the
-  whole PURCHASE_ORDERS section at `1-RUNNING` (Elite watermark stuck 2025-10-13, window ÷3 to 1s,
-  poison PO re-tried every 5 min). Fix mirrors the SALES_ORDERS cleanup: unlink all four PO bridge
-  routes, unhook item receipts via `PUT /item-receipt-items/{uuid}` `purchaseOrderItem = null`, then
-  DELETE the PO line kept **throwing** as the fail-loud backstop. **Decision:** the sync mirrors
-  NetSuite — remove our line + its links but keep the real records on the other side; never
-  log-and-skip (a log-and-skip guard was tried this session and rejected as data damage). **Deploy
-  dependency:** `ItemReceiptItems.purchaseOrderItemId` must be nullable
-  (`dbchanges2/Client/2026-06-19a - TransferOrderSchemaFixes.sql` §7) on every client DB first.
-  Recorded the api2 bridge-route key mechanic (plain kebab→camel, no pluralization; PUT writes SQL
-  NULL) and Elite's 78 duplicate PO line-groups (4 with receipts, all tangled → must fail loud).
-  No prod data was modified (read-only SELECTs + NetSuite reads). (jcardinal)
+- 2026-09-02 — **PURCHASE_ORDERS cleanup DELETE freeze fixed + DEPLOYED, plus a follow-up 403 fix
+  (shared, `library` only — committed to `_production`, confirmed live on Elite).**
+  `syncPurchaseOrderFromNetsuite`'s "remove dropped items" cleanup deleted a NetSuite-dropped PO line
+  with a bare throwing DELETE; a leftover item receipt (`ItemReceiptItems.purchaseOrderItemId`,
+  RESTRICT) or SO/TO link → 1451 → EV-11 → threw → froze the whole PURCHASE_ORDERS section at
+  `1-RUNNING` (Elite watermark stuck 2025-10-13, window ÷3 to 1s, poison PO re-tried every 5 min). Fix
+  mirrors the SALES_ORDERS cleanup: unlink all four PO bridge routes, unhook item receipts via
+  `PUT /item-receipt-items/{uuid}` `purchaseOrderItem = null`, then DELETE the PO line kept **throwing**
+  as the fail-loud backstop. **Decision:** the sync mirrors NetSuite — remove our line + its links but
+  keep the real records on the other side; never log-and-skip (a log-and-skip guard was tried this
+  session and rejected as data damage). **Deploy dependency:** `ItemReceiptItems.purchaseOrderItemId`
+  must be nullable (`dbchanges2/Client/2026-06-19a - TransferOrderSchemaFixes.sql` §7) on every client
+  DB first. Recorded the api2 bridge-route key mechanic (plain kebab→camel, no pluralization; PUT writes
+  SQL NULL) and Elite's 78 duplicate PO line-groups (4 with receipts, all tangled → must fail loud).
+  **Follow-up after deploy:** the cleanup's **bridge-clear GET** was itself a throwing `send()`, and a
+  client without an ACL grant on the transfer-order bridge routes (Elite — no transfer orders — Core
+  records 329/330) got **403 EZ-2** on `GET /purchase-order-items-transfer-order-items` and re-froze;
+  the bridge/link GET loop now passes `$throwExceptionOnApiError=false` and **skips** a link table on a
+  no-access response (403 OR EZ-2), while any other failure still throws. Elite PO import unfroze after
+  redeploy. **Two ops lessons:** (1) merging `library` to `_production` does NOT deploy the worker EC2
+  boxes — only a worker deploy does (old code ran for cron cycles after the 14:48 merge); (2) the
+  `Logs_<Client>.Api` call pattern (bridge GETs + item-receipt unhook PUT vs. a bare PO-line DELETE) is
+  the ground truth for whether the fix is live. No prod data was modified (read-only SELECTs + NetSuite
+  reads). (jcardinal)
 - 2026-09-01 — **Customer-PO `dateOrder`/`cost` fixes + NYCHH inventory-adjustment serial-case unfreeze
   (shared, `library` only, working-tree — not yet committed/deployed).** `syncSalesOrderFromNetsuite`
   now sets the customer PO's `dateOrder` from the SO `tranDate` (was always NULL) and its PO lines'

package/knowledge/clients/elite/features/netsuite-togasupply-sync.md

@@ -126,8 +126,8 @@ the trait declares must exist as a column, a `CustomRecordFields` row **and** an
 ## Change history
 
 - 2026-09-02 — **Elite PURCHASE_ORDERS froze on a dropped PO line that still had a receipt** (shared
-  fix, `library` only — WRITTEN + REVIEWED, NOT yet committed/deployed). Elite was the confirmed prod
-  case: `NETSUITE_EXECUTION_MODE_PURCHASE_ORDERS='1-RUNNING'`, watermark frozen at **2025-10-13**,
+  fix, `library` only — now DEPLOYED to `_production`, PO import confirmed unfrozen on Elite). Elite was
+  the confirmed prod case: `NETSUITE_EXECUTION_MODE_PURCHASE_ORDERS='1-RUNNING'`, watermark frozen at **2025-10-13**,
   window collapsed to 1s, same poison PO re-tried every 5 min. Root cause is shared, not Elite —
   `syncPurchaseOrderFromNetsuite`'s cleanup DELETE threw on a leftover item receipt / SO link. Elite
   data behind it: **78 duplicate `(purchaseOrder, vendorItem)` PO line-groups**, only **4** carry a
@@ -138,7 +138,17 @@ the trait declares must exist as a column, a `CustomRecordFields` row **and** an
   (double-count / `UNIQUE(itemReceiptId, purchaseOrderItemId)` collision) — tangled cases fail loud
   for a human, only clean cases self-heal. **Before deploy:** confirm
   `ItemReceiptItems.purchaseOrderItemId` is nullable on `Client_Elite`
-  (`dbchanges2/Client/2026-06-19a - TransferOrderSchemaFixes.sql` §7). Full mechanics on the
+  (`dbchanges2/Client/2026-06-19a - TransferOrderSchemaFixes.sql` §7). **Follow-up after deploy:** a
+  second freeze appeared — the cleanup's **bridge-clear GET** was a throwing `send()`, and Elite has
+  **no ACL grant** on the transfer-order bridge Core records (**329**
+  `purchase-order-items-transfer-order-items`, **330** `transfer-order-items-purchase-order-items`)
+  because Elite doesn't use transfer orders, so `GET /purchase-order-items-transfer-order-items`
+  returned **403 EZ-2** (roleIds [1,3]) and aborted the section. Fixed by making the bridge GET loop
+  tolerate a no-access response (`$throwExceptionOnApiError=false`, skip that link table on 403/EZ-2,
+  else throw); Elite unfroze after redeploy. Note: merging `library` to `_production` did **not**
+  deploy the worker boxes — an actual worker deploy was required, and the `Logs_Elite.Api` call
+  pattern (bridge GETs + item-receipt unhook PUT vs. a bare PO-line DELETE) is how you confirm the fix
+  is live. Full mechanics on the
   [engine doc](../../../1.0/apps/worker/features/netsuite-togasupply-per-client-sync.md). (jcardinal)
 - 2026-09-01 — **Drop-ship / special-order POs were never importing for Elite** (e.g. PO tranid
   128238). Root cause was in shared code, not Elite: `listPurchaseOrders()` filtered the PO header by

package/package.json

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