toga-ai 1.0.732 → 1.0.734

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

@@ -530,6 +530,20 @@ Parameters are stored **per client DB** but accessed **through the TOGa2 API**,
   a new line is actually created. Full root cause, the prod cleanup migration, and the
   deploy-fix-before-cleanup sequencing live in the
   [Compass ODP Duplicate PO-Line Cleanup](../../../clients/compass-usa/workflows/odp-duplicate-po-line-cleanup.md).
+- **Customer-PO created from a sales order was missing `dateOrder` and had `cost` hardcoded 0 (both
+  fixed 2026-09-01, shared, `library` only).** In `syncSalesOrderFromNetsuite`
+  (`library/app/api/toga2.php`), the "create the customer PO" `POST /purchase-orders` branch
+  (~L1961) never set `dateOrder`, so every customer PO built from a sales order had
+  `PurchaseOrders.dateOrder` NULL. Fix: add
+  `'dateOrder' => App_Date::convertToTimezone($nsOrder->tranDate, 'Y-m-d', 'America/New_York')`
+  (the same expression that sets the SO's own `dateOrder` at ~L1394). Separately, all **three**
+  PO-item creation sites (`POST /purchase-order-item-sales-order-items`, ~L1863/1937/2051) sent
+  `'cost' => 0`; because this PO is the customer PO **for** the sales order, the PO line's cost is
+  the SO line's price — changed to `'cost' => $salesOrderItem['price']` (`$itemPrice`, from the
+  NetSuite rate or amount/qty fallback built ~L1223, always present). **Both are INSERT-ONLY:** the
+  create branches run only when the PO / line does not already exist and nothing PUTs `dateOrder` or
+  `cost`, so re-syncs and a second SO sharing the same customer-PO number never overwrite them.
+  **Existing NULL/`cost=0` rows are NOT backfilled** — new records only.
 - **⚠ A single un-deletable renumbered line could freeze the entire SALES_ORDERS section (fixed
   2026-08-17).** When NetSuite renumbers a line, `syncSalesOrderFromNetsuite` renumbers by
   **DELETE `/sales-order-items/{uuid}` then re-create in the per-item loop**. Its "pinned row" guard
@@ -881,9 +895,43 @@ Parameters are stored **per client DB** but accessed **through the TOGa2 API**,
   `'catalog' => ['name' => 'Agilant']` on the inventory-adjustment item-create. Stops all new duplicates.
   The one-time cleanup of the accumulated ~4,300 duplicate part numbers across all 17 clients is the
   [NetSuite duplicate-Items dedup workflow](../workflows/netsuite-duplicate-items-dedup.md).
+- **⚠ Inventory-adjustment `/units` reconciliation missed an existing unit on a serial-CASE mismatch →
+  1062 dup-key freeze (fixed 2026-09-01, shared, `library` only).** In
+  `syncInventoryAdjustmentFromNetsuite` (`library/app/api/toga2.php` ~L5985) the PHP lookup of existing
+  units was keyed by the **returned** unit serial (`$thisLookupUnitsBySerialNumber[$unit->serialNumber]`,
+  stored `'n/a'`) but looked up with the NetSuite serial **uppercased** via `strtoupper` (`'N/A'`). **PHP
+  array keys are case-sensitive; the `Units.itemId_serialNumber` unique key is case-insensitive** — so
+  the existing unit was missed, re-INSERTed, and collided MySQL **1062** ("Duplicate entry '560-N/A'")
+  → `EV-10` → the section aborted (fail-loud, no per-record try/catch) and froze at `1-RUNNING`. **Fix:**
+  key the lookup by `strtoupper($unit->serialNumber)` so it matches the uppercased NetSuite serial;
+  section self-heals on deploy (mode→IDLE, watermark advances). The `Items.uuid=$uuidItem` scoping was
+  left intact deliberately — copying the fulfillment "serial-only" lookup would be wrong for the shared
+  `'N/A'` placeholder serial (it would reuse another item's placeholder unit). **Durable lesson: when a
+  PHP lookup mirrors a case-insensitive DB unique key, normalize the KEY the same way you normalize the
+  probe — case-fold both, not one.**
+- **Diagnosis playbook (durable) — localize a frozen inventory-adjustment section without NetSuite
+  access.** The 2026-09-01 NYCHH freeze above was diagnosed purely from DB logs, and item-matching was
+  *ruled out* (item 560 / partNumber B11B242201 is the only Agilant-catalog item for that part — no
+  duplicate second-catalog item, `$uuidItem` resolved correctly; the inventory-adjustment item-create
+  already stamps catalog `Agilant`). Chain: **`Client_<Id>.Parameters`** (localize the stuck section:
+  `1-RUNNING` + frozen watermark) → **`Logs.Event` filtered by `clientId`** (crash `file:line`, the
+  chain `toga2.php → common_sync_togasupply.php → sync*FromNetsuite`, plus the `transactionId`) →
+  **`Logs_<Client>.Api` on that `transactionId`** (the untruncated `EV-*`/MySQL rejection + payload).
+  A "silent freeze" here is a serial/data collision, not necessarily a catalog/item-matching problem —
+  read the untruncated Api-log rejection before assuming item matching.
 
 ## Change history
 
+- 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'
+  `cost` from the SO line `price` (was hardcoded 0) across all three PO-item create sites — both
+  INSERT-only, no backfill of existing rows. `syncInventoryAdjustmentFromNetsuite` now keys the `/units`
+  reconciliation lookup by `strtoupper($unit->serialNumber)` so a case-mismatched serial (`'n/a'` vs
+  `'N/A'`) matches the case-insensitive `Units.itemId_serialNumber` unique key — was missing the
+  existing unit and 1062-colliding, freezing NYCHH `INVENTORY_ADJUSTMENTS` at `1-RUNNING` (watermark
+  frozen 2022-12-28). Ruled out item-matching as the cause (single Agilant-catalog item, `$uuidItem`
+  correct). All three benefit every togasupply client. (jcardinal)
 - 2026-09-01 — **TRUE-81576: stopped runaway duplicate `ShippingCarriers` creation (worker + library).**
   `common_sync_togasupply.php` now seeds the carrier lookup from its own paged `GET /shipping-carriers`
   loop instead of harvesting carriers out of the `/shipping-methods` loop — a carrier with zero

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

@@ -6,8 +6,8 @@ project: TOGa Blox
 client: shared
 type: workflow
 status: active
-updated: 2026-08-31
-owners: [jcardinal, apeterson]
+updated: 2026-09-02
+owners: [jcardinal, apeterson, tcox]
 files:
   - toga-blox/.github/workflows/publish.yml
   - toga-blox/package.json
@@ -86,12 +86,13 @@ environment needs its own maintained `_<mode>` branch in `toga-blox-npm`.
 ## Gotchas
 
 - **⚠ There is a STALE UNDERSCORED dist-tag on the registry — `_sandbox-client` (with the
-  underscore) is NOT the channel.** Verified 2026-08-31, the registry carries **both**
-  `_sandbox-client` = `1.0.316-sandbox-client.1` (vestigial, predates the current pipeline) **and**
-  `sandbox-client` = `1.1.1-sandbox-client.140` (the live channel head). Branch `_<mode>` maps to
+  underscore) is NOT the channel.** Re-verified 2026-09-02, the registry still carries **both**
+  `_sandbox-client` = `1.0.316-sandbox-client.1` (vestigial, predates the current pipeline; it has
+  **not** moved in over a month) **and** `sandbox-client` = `1.1.2-sandbox-client.142` (the live
+  channel head). Branch `_<mode>` maps to
   channel `<mode>` with the underscore **stripped** (same convention as `amplify.yml`), so the
   **branch** `_sandbox-client` tracks the **tag** `sandbox-client`. Asking npm for "the latest
-  `_sandbox-client` tag" literally installs something **139 publishes behind**. Always resolve the
+  `_sandbox-client` tag" literally installs something **141 publishes behind**. Always resolve the
   head with `npm view @agilant/toga-blox dist-tags` and install the underscore-less name.
 - **Publish before build.** `npm install @agilant/toga-blox@<mode>` fails `ETARGET No matching
   version` in the app build until this repo has published that channel. GitHub Actions runs the
@@ -131,8 +132,19 @@ environment needs its own maintained `_<mode>` branch in `toga-blox-npm`.
   was then made **on `_sandbox-client`**, at the developer's explicit direction. That **deviates
   from the `deploy-sandbox-client` skill's "never commit the bump directly to `_sandbox-client`"
   rule.** It was safe *only* because the feature branch does not carry the version line, so nothing
-  could be clobbered — **record this as a one-off, not a new default.** CI then published base+1 →
-  `1.0.334-sandbox-client.136`.
+  could be clobbered. CI then published base+1 → `1.0.334-sandbox-client.136`.
+- **Bumping the base directly on `_sandbox-client` is the ACTUAL practice — it is safe under three
+  preconditions, and it is no longer a one-off.** Second occurrence 2026-09-02 (`1.1.0` → `1.1.1`,
+  commit `543a7186`, published `1.1.2-sandbox-client.142`), same shape as 2026-08-26. Stop treating
+  the skill's "never bump on `_sandbox-client`" line as absolute; treat it as conditional. The bump
+  on the release branch is fine when **all three** hold:
+  1. The working tree is **clean**.
+  2. The branch is **in sync with `origin`** (nothing unpushed, nothing to pull).
+  3. No feature branch pending merge **touches the `version` line** — which is normally true,
+     because feature branches never edit it (see the gotcha above).
+  If any one fails, bump on the feature branch instead. Note the bump commit lands *only* on
+  `_sandbox-client` and is never merged back, which is precisely what generates the "N behind"
+  release plumbing described two gotchas up.
 - **`gh` is not installed on every dev machine.** The skill's `gh run watch` monitoring step simply
   does not work there. Fall back to polling the registry:
   `npm view @agilant/toga-blox@sandbox-client version` (or `npm dist-tag ls @agilant/toga-blox`)
@@ -200,6 +212,17 @@ environment needs its own maintained `_<mode>` branch in `toga-blox-npm`.
   you push to a release branch.
 
 ## Change history
+- 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
+  workflow was accurate end-to-end — no new gotchas. **Promoted the on-branch version bump from a
+  "one-off deviation" to the actual practice with three stated preconditions** (clean tree, in sync
+  with origin, no pending merge touching the `version` line); this was its second occurrence under
+  identical conditions. Refreshed the live `sandbox-client` head in the stale-dist-tag gotcha
+  (`.140` → `.142`); the vestigial `_sandbox-client` tag is unmoved at `1.0.316-sandbox-client.1`.
+  Confirmed the registry-polling fallback (`npm view @agilant/toga-blox@sandbox-client version`)
+  is the working verification path where `gh` is absent, and that publish lands ~2 min after the
+  push. (tcox)
 - 2026-08-31 — Recorded the **stale underscored dist-tag trap**: the registry carries both
   `_sandbox-client` (`1.0.316-sandbox-client.1`, vestigial) and `sandbox-client`
   (`1.1.1-sandbox-client.140`, live head). Installing the underscored name silently pins 139

package/knowledge/clients/nychh/features/netsuite-inventory-adjustment-fulfillment-link.md

@@ -6,7 +6,7 @@ project: Library
 client: nychh
 type: client-feature
 status: active
-updated: 2026-08-30
+updated: 2026-09-01
 owners: [jcardinal]
 files:
   - library/app/api/toga2.php
@@ -134,11 +134,22 @@ Both are framework-level NetSuite facts — full detail on
   **`mainline='F'` is the WRONG filter** — NetSuite sometimes marks the first real fulfilled line
   `mainline='T'`.
 
-## Two shared-engine fixes in `syncInventoryAdjustmentFromNetsuite` (surfaced here, affect any client)
+## Three shared-engine fixes in `syncInventoryAdjustmentFromNetsuite` (surfaced here, affect any client)
 
-Both are in the shared library method — see also the
+All in the shared library method — see also the
 [per-client sync](../../../1.0/apps/worker/features/netsuite-togasupply-per-client-sync.md):
 
+- **(c) Serial-CASE mismatch missed the existing unit → 1062 freeze (fixed 2026-09-01).** The `/units`
+  reconciliation lookup was keyed by the **returned** unit serial (`$unit->serialNumber`, stored `'n/a'`)
+  but probed with the NetSuite serial **uppercased** via `strtoupper` (`'N/A'`). PHP array keys are
+  case-sensitive but `Units.itemId_serialNumber` is a **case-insensitive** unique key, so the existing
+  unit (id 546, itemId 560, serial `'n/a'`) was missed and re-INSERTed → MySQL **1062**
+  ("Duplicate entry '560-N/A'") → `EV-10` → section aborted (no per-record try/catch). This froze NYCHH
+  `INVENTORY_ADJUSTMENTS` at `1-RUNNING`, watermark stuck 2022-12-28 (integration was recently
+  restarted). **Fix:** key the lookup by `strtoupper($unit->serialNumber)`. The `Items.uuid=$uuidItem`
+  scoping was **kept deliberately** — copying the fulfillment "serial-only" lookup would be wrong for the
+  shared `'N/A'` placeholder serial (would reuse another item's placeholder unit). Section self-heals on
+  deploy. `library` only, working-tree, not yet committed/deployed.
 - **(a) Prune-order FK violation.** The stale-item prune deleted an `InventoryAdjustmentItem` while
   its child `InventoryAdjustmentItemUnits` still referenced it (FK **RESTRICT**, no cascade) → MySQL
   **1451** → `EV-11`. **Fix:** delete the child units (`/inventory-adjustment-item-units/{uuid}`)
@@ -197,9 +208,29 @@ this feature on the scheduled cron.
 - **Empty lookups drop or duplicate items.** The item loop filters to known warehouses and creates
   items on lookup-miss, so any manual/diagnostic invocation must seed the warehouse/item/manufacturer
   lookups (the harness does).
+- **A frozen NYCHH `INVENTORY_ADJUSTMENTS` section is NOT necessarily an item-matching / two-catalog
+  problem (verified 2026-09-01).** When the section stuck at `1-RUNNING`, item matching was suspected
+  (wrong of two intentional catalogs). Verified in prod it was fine: item **560**
+  (uuid `4c7b93d2-…`, partNumber **B11B242201**, HYBRID) is the Agilant-catalog item and the **only**
+  item with that part number — no duplicate second-catalog item, `$uuidItem` resolved correctly, and the
+  inventory-adjustment item-create already stamps catalog `Agilant`. The freeze was purely the serial-CASE
+  bug (fix (c) above). **Diagnosis chain (no NetSuite access):** `Client_Nychh.Parameters` (localize the
+  stuck section) → `Logs.Event` `clientId=3` (crash `toga2.php:6080` via
+  `common_sync_togasupply.php:1180` `syncInventoryAdjustmentFromNetsuite`, + `transactionId`) →
+  `Logs_Nychh.Api` on that `transactionId` (untruncated `EV-10`/1062 rejection + payload).
 
 ## Change history
 
+- 2026-09-01 — **Unfroze NYCHH `INVENTORY_ADJUSTMENTS` — serial-CASE mismatch in the `/units` lookup
+  (shared `library`, working-tree, not yet committed/deployed).** `syncInventoryAdjustmentFromNetsuite`
+  keyed the units lookup by the returned serial (`'n/a'`) but probed with the uppercased NetSuite serial
+  (`'N/A'`); PHP array keys are case-sensitive while `Units.itemId_serialNumber` is case-insensitive, so
+  the existing unit was missed, re-INSERTed, and 1062-collided → `EV-10` → section aborted at
+  `1-RUNNING` (watermark frozen 2022-12-28). Fixed by keying on `strtoupper($unit->serialNumber)`; kept
+  the `Items.uuid=$uuidItem` scoping (the shared `'N/A'` placeholder makes serial-only wrong here). Ruled
+  out item-matching / two-catalog as the cause (item 560 / B11B242201 is the only Agilant-catalog item,
+  `$uuidItem` correct). Diagnosed entirely from `Parameters` → `Logs.Event` (clientId 3) → `Logs_Nychh.Api`
+  by `transactionId`, no NetSuite access. (jcardinal)
 - 2026-08-30 — Verified that NYCHH adjustments with a NULL `itemFulfillmentId`/`itemFulfillmentItemId`
   are **correct, not a bug**: 0 of 27 NYCHH adjustments populate NetSuite `custbody_stock_adjustment`
   (~1 in 40 account-wide), so most carry no link. Confirmed the shim's scalar SuiteQL read of the field

package/knowledge/clients/nychh/profile.md

@@ -187,4 +187,9 @@ table views. Client-specific DB change-sets live in `dbchanges2/Client_Nychh/`.
   path on any branch, and neither is in the working tree — so the transfer-order **custom-field
   write permission** and the **stage status identifier** are, like the ACL layers above, prod/local
   state with no file behind them. Rewrite them before anyone builds a fresh environment.
+- 🚨 **OPEN, not investigated (found 2026-09-01): recurring api2 `1054` errors for NYCHH.**
+  `Logs.Event` **issueId 64**, `clientId 3`: *"Database Error Occurred Error #: 1054 Unknown column
+  'vendor.uuid' in 'where clause'"* on a `PurchaseOrders` GET (`_Query->getFoundRows` via
+  `V2.php processRoutePairs`), several occurrences ~2026-09-01 12:29. Flagged for a future look; no
+  change made. Likely a TableView/query join referencing `vendor.uuid` that isn't in scope.
 - This profile is a starting point; expand as more NYCHH-specific behavior is captured.

package/package.json

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