toga-ai 1.0.543 → 1.0.545

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

@@ -27,6 +27,7 @@
 | [_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()`. | _underscore/Model/Core/Model.php, _underscore/Model.php, _underscore/Model/Rate/Subscription.php |
 | [_Model::save() vs raw _Query — no atomic conditional update](features/model-save-vs-query-atomic-update.md) | `_Model::save()` is a plain load-then-write ORM primitive and **cannot express an atomic conditional update** (an optimistic-concurrency / row-claim guard such | _underscore/Model.php, _underscore/Query.php, _underscore/Model/Rate/Subscription.php |
 | [NetSuite REST Client (_Component_Api_Netsuite) — record writes & SuiteQL](features/netsuite-rest-client.md) | `_Component_Api_Netsuite` is the **2.0 `_underscore` NetSuite REST client** — the shared primitive every worker2/api2 NetSuite caller uses for record GETs, Suit | _underscore/Component/Api/Netsuite/Netsuite.php |
+| [Legacy page meta (Page::meta) & context-scoped ClientRecordFieldSettings](features/page-meta-context-field-settings.md) | `_Model_Core_Page::meta()` is the **legacy** page-meta resolver behind `GET /pages/meta?slug=<slug>` — still the live path for `toga2-supply` and other pre-Surf | _underscore/Model/Core/Page.php |
 | [Per-Client Database Connections & the Local Logs Trap](features/per-client-database-connections.md) | When `_underscore` serves a request for a client it opens **three distinct per-client database connections**, not one. | _underscore/Database.php, _underscore/Query.php, _underscore/ApiRequest.php, _underscore/Model/Client/Logs/Api.php, api2/Controller/Index.php |
 | [Persona Name Translation (PersonaTranslations sidecar)](features/persona-name-translation.md) | Serves Persona **names** in multiple languages by adding a per-language **sidecar** table `PersonaTranslations`, reusing the platform's existing metadata-driven | _underscore/Model/Client/PersonaTranslation.php, dbchanges2/Client/2026-07-22b - PersonaTranslations.sql, dbchanges2/Core/2026-07-22a - PersonaTranslationsRecord.sql, dbchanges2/Client/2026-07-22c - PersonaTranslationsAcl.sql, dbchanges2/Client_CompassCanada/2026-07-22 - PersonaTranslationsFrench.sql, toga2-commerce/src/pages/Account/view/MySettingsView.tsx |
 | [Recursive Item Fulfillments (upstream mirroring)](features/recursive-item-fulfillments.md) | In a multi-tier supply chain a sales order (SO) spawns a purchase order (PO) that becomes another SO downstream, and so on. | _underscore/Model/Client/ItemFulfillment.php, _underscore/Model/Client/ItemFulfillmentItem.php, _underscore/Model/Client/ItemFulfillmentItemUnit.php, _underscore/Model/Client/ItemFulfillmentPackage.php, _underscore/Model/Compass/AdvanceShippingNotice.php, dbchanges2/Core/2026-02-13 - 75601 - RecursiveItemFulfillmentCreation.sql, dbchanges2/Core/2026-06-04 - RecursiveItemFulfillmentPut.sql, dbchanges2/Client_Compass/2026-07-02a - FixSA133377TrackingSerialAndDuplicateIF.sql |

package/knowledge/2.0/apps/_underscore/features/page-meta-context-field-settings.md

@@ -0,0 +1,75 @@
+---
+title: Legacy page meta (Page::meta) & context-scoped ClientRecordFieldSettings
+framework: "2.0"
+repo: _underscore
+project: _Underscore
+client: shared
+type: feature
+status: active
+updated: 2026-08-10
+owners: [tcox]
+files:
+  - _underscore/Model/Core/Page.php
+related:
+  - surface-resolver.md
+  - error-reporting-issue-event.md
+  - ../../../clients/elite/features/supply2-tableview-config-drift.md
+---
+
+## Summary
+
+`_Model_Core_Page::meta()` is the **legacy** page-meta resolver behind `GET /pages/meta?slug=<slug>`
+— still the live path for `toga2-supply` and other pre-Surface frontends. It is being replaced by
+[`_Model_Core_Surface::resolve`](surface-resolver.md), but must not be deleted while consumers
+remain. One part of it — **context-scoped `ClientRecordFieldSettings`** — carries a live framework
+bug that takes down *unrelated* pages for any client that uses the feature.
+
+## What context-scoped field settings are
+
+`Client_*.ClientRecordFieldSettings` lets a client override a field's presentation (e.g. its label)
+**in the context of another field**: a row carries the target `recordFieldId` plus a
+`contextRecordFieldId`, meaning "when field X is shown *through* field Y, label it differently."
+
+Example (Elite): row id 1 relabels field **58** to **"Total"** in the context of field **190**
+(`ServiceRequests.id`) — authored for the `service-requests` view.
+
+## The bug — "Undefined array key \<contextRecordFieldId\>" 500
+
+> **Status: reported to the backend, unfixed as of 2026-08-10.**
+
+`Page::meta()` fetches a client's field-settings rows by **target field id only**, so Elite's row is
+returned for **any** page whose field set contains field 58 — not just the page that owns field 190.
+It then resolves `contextRecordFieldId` against a lookup array built **only from the current page's
+fields**. When the context field is not on that page, PHP raises *"Undefined array key 190"* at
+`Model/Core/Page.php:824`.
+
+Historically that was a warning and the page still rendered. The **strict Sentry error handler**
+deployed to beta on 2026-08-07 promotes it to a **fatal**, so it now surfaces as a hard 500 — Elite's
+`/pages/meta?slug=inventory` (a page with nothing to do with service requests) began 500ing purely
+because the service-requests row exists.
+
+**Fix:** an `isset()` guard around `Page.php` ~L822–829 — skip any context setting whose context
+field is not present on the requested page.
+
+**Blast radius:** any client that uses context-scoped field settings can hit this on **every page
+that shares the base field**. The failure looks unrelated to the page you are debugging, and it can
+appear long after the settings row was authored — a redeploy that tightens error handling, not a
+data change, is what makes it fatal.
+
+## Gotchas
+
+- **A page-meta 500 is not necessarily about that page.** Trace it to the offending
+  `ClientRecordFieldSettings` row via the array key in the message (it is a `Core.RecordFields` id),
+  not via the slug you requested.
+- **Error-handler strictness is a deploy-time behavior change.** Warnings that were survivable for
+  years become 500s the moment the strict handler ships; expect a cluster of "new" failures in old
+  code after such a deploy.
+- Do not "fix" this by deleting the client's settings row — that removes a real client
+  customization. The guard belongs in the framework.
+
+## Change history
+- 2026-08-10 — First capture: documented context-scoped `ClientRecordFieldSettings` and the
+  `Page.php:824` *"Undefined array key \<contextRecordFieldId\>"* fatal (context field not on the
+  requested page), which the 2026-08-07 strict Sentry handler turned from a warning into a 500 on
+  Elite's `/pages/meta?slug=inventory`. Reported to the backend; recommended `isset()` guard at
+  ~L822–829. (tcox)

package/knowledge/2.0/apps/_underscore/workflows/local-db-refresh-from-beta.md

@@ -111,9 +111,23 @@ Order matters — dump first so a failed dump never wipes a local schema it can'
   `Core` change-sets (e.g. the Surface-layer seeds), so a later replay of *committed* changes is
   largely a no-op. Only ad-hoc changes that were never committed to dbchanges2 need re-applying
   after a reset.
+- **⚠ Beta itself gets rebuilt from PRODUCTION — treat every beta hand-insert as temporary.** A
+  `Client_*` schema on dev-sandbox can be re-imported from prod at any time (e.g. `Client_Elite`,
+  2026-08-07 11:55). Everything hand-inserted on beta and never committed to `dbchanges2` is gone:
+  a hand-built TableView, a seeded `devteam@togatech.com` user (it returns as a row with an **empty
+  password**, which reads as "wrong password", not "missing user"), ad-hoc config rows. **Row ids
+  also shift on re-import**, so notes or scripts that identify a row by id stop matching — key on
+  the natural columns instead (for `TableViewJoins`: `tableViewId` + `joinRecordId` +
+  `joinOnRecordFieldId`). If a beta-only row matters, ship it as a `dbchanges2` migration. Worked
+  example: [Elite TableView config
+  drift](../../../clients/elite/features/supply2-tableview-config-drift.md).
 
 ## Change history
 
+- 2026-08-10 — Added the **beta-is-rebuilt-from-prod** gotcha: a `Client_*` schema can be re-imported
+  from production at any time, discarding every uncommitted hand-insert (hand-built TableViews, the
+  seeded `devteam` user — which returns with an empty password) and **shifting row ids**, so match
+  rows by natural columns and ship beta-only rows as `dbchanges2` migrations. (tcox)
 - 2026-08-06 — Recorded that environment **`beta` resolves to the dev-sandbox cluster** in
   `Core.DatabaseHosts` for `Client_*` schemas, so an app pointed at `api.beta.togahub.com` is
   reading dev-sandbox data and the DB MCP environment to query is `dev-sandbox` (not

package/knowledge/2.0/apps/toga2-supply/INDEX.md

@@ -5,4 +5,4 @@
 | [TOGa Supply (toga2-supply) Architecture](architecture.md) | `toga2-supply` is the **React + Vite frontend** for TOGa Supply — warehouse fulfillment tooling (shipment selection, fulfill & ship against carrier APIs, NetSui | toga2-supply/src/api/toga.ts, toga2-supply/src/pages/ShipmentItems/view/ShipmentItemsPage.tsx, toga2-supply/src/pages/EditShipment/view/EditShipmentPage.tsx, toga2-supply/src/pages/EditShipment/api/UpdateShipmentApi.ts, toga2-supply/src/pages/Shipments/view/components/ShipmentsCardTableForm/ShipmentsCardTableForm.tsx |
 | [Fulfill & Ship](features/fulfill-and-ship.md) | Fulfill & Ship lets a warehouse user select sales-order line items, enter serials, pick a carrier/method, and in one action: create the Item Fulfillment records | _underscore/Model/Client/Measure.php, _underscore/Model/Client/TrackingNumber.php, toga2-supply/src/pages/EditShipment/helpers/ShipmentDetailsForm/getEditShipmentFormOptions.ts, toga2-supply/src/pages/EditShipment/helpers/ShipmentDetailsForm/validateFormOnSubmit.ts, toga2-supply/src/pages/EditShipment/helpers/ShipmentDetailsForm/checkDimensions.ts, toga2-supply/src/components/ui/Tables/BasicTable/BasicTable.tsx, toga2-supply/src/components/ui/Tables/types.ts, toga2-supply/src/components/ui/GoogleMapsLink.tsx, toga2-supply/src/pages/ShipmentItems/view/forms/ShipmentItemsTable.tsx, toga2-supply/src/pages/ShipmentItems/api/ShipmentItemsApi.ts, toga2-supply/src/pages/ShipmentItems/types.ts, toga2-supply/src/pages/EditShipment/viewModel/FIELDS/RETURNLABELFIELDS.json, toga2-supply/src/pages/EditShipment/view/components/forms/EditShipmentForm.tsx, toga2-supply/src/components/ui/BaseInput/UnitSelect.tsx, toga2-supply/src/pages/EditShipment/view/modals/SerialNumbersModal.tsx, toga2-supply/src/pages/ShipmentItems/view/ShipmentItemsPage.tsx, toga2-supply/src/pages/EditShipment/view/EditShipmentPage.tsx, toga2-supply/src/pages/EditShipment/view/components/forms/EditShipmentForm.tsx, toga2-supply/src/pages/EditShipment/view/components/SelectedShipmentItemsTable.tsx, toga2-supply/src/pages/EditShipment/view/helpers/ShipmentDetailsForm/renderEditShipmentFormInput.tsx, toga2-supply/src/pages/EditShipment/viewModel/FIELDS/DUMMYUPDATESHIPMENTFIELDS.json, toga2-supply/src/pages/EditShipment/helpers/ShipmentDetailsForm/renderEditShipmentFormInput.tsx, toga2-supply/tailwind.config.cjs, toga2-supply/src/pages/EditShipment/view/modals/ReturnShippingModal.tsx, toga2-supply/src/styles/index.scss, toga2-supply/src/components/ui/BaseInput/BaseInput.tsx, toga2-supply/src/pages/EditShipment/api/UpdateShipmentApi.ts, toga2-supply/src/pages/EditShipment/viewModel/signatureTypes.ts, toga2-supply/src/pages/EditShipment/view/modals/SelectReturnAddressModal.tsx, toga2-supply/src/pages/EditShipment/helpers/ShipmentDetailsForm/formatShipmentData.ts, toga2-supply/src/pages/EditShipment/types.ts, toga2-supply/src/pages/Shipments/view/ShipmentsPage.tsx, toga2-supply/src/pages/Shipments/view/components/ShipmentsCardTableForm/ShipmentsCardTableForm.tsx, toga2-supply/src/pages/Shipments/api/ShipmentsApi.ts, toga2-supply/src/pages/Shipments/types.ts, toga2-supply/src/pages/FulfilledShipments/view/FulfilledShipmentsPage.tsx, toga2-supply/src/components/ui/CardTable/CardTable.tsx, toga2-supply/src/components/ui/CardTable/types.ts, toga2-supply/src/assets/pen-line.svg, _underscore/Model/Client/ItemFulfillment.php, _underscore/Trait/Netsuite/ItemFulfillment.php, _underscore/Component/Library/Carriers/Ups/Ups.php |
 | [AWS Amplify Build & Deploy (non-prod environments)](workflows/amplify-build-and-deploy.md) | How `toga2-supply` (React + Vite) builds and deploys on **AWS Amplify**. | toga2-supply/amplify.yml, toga2-supply/.gitattributes, toga2-supply/.github/workflows/sync-stage-environments.yml, toga2-supply/.env.qc-security |
-| [Onboarding a client to the supply2 frontend (host-scoping)](workflows/client-host-scoping.md) | How a new tenant becomes a "client" in the `toga2-supply` frontend. | toga2-supply/src/stores/useHostNameStore.ts, toga2-supply/src/utils/resolveClientHostName.ts, toga2-supply/src/hooks/useHostName.tsx, toga2-supply/src/hooks/usePageDetails.tsx, toga2-supply/src/hooks/usePageListDetails.tsx, toga2-supply/src/components/layout/SlideMenu/SlideMenu.tsx, toga2-supply/src/utils/handleClientAuthentication.ts, toga2-supply/src/App.tsx, toga2-supply/src/pages/Inventory/viewModel/FIELDS/DUMMYGROUPOPTIONS.ts, toga2-supply/src/pages/Inventory/viewModel/FIELDS/INVENTORYPAGEFIELDS.ts, toga2-supply/src/pages/Inventory/listing/InventoryPage.tsx, toga2-supply/src/pages/Inventory/listing/InventorySubTablePage.tsx, toga2-supply/src/api/toga.ts, toga2-supply/package.json |
+| [Onboarding a client to the supply2 frontend (host-scoping)](workflows/client-host-scoping.md) | How a new tenant becomes a "client" in the `toga2-supply` frontend. | toga2-supply/src/stores/useHostNameStore.ts, toga2-supply/src/utils/resolveClientHostName.ts, toga2-supply/src/hooks/useHostName.tsx, toga2-supply/src/hooks/usePageDetails.tsx, toga2-supply/src/hooks/usePageListDetails.tsx, toga2-supply/src/components/layout/SlideMenu/SlideMenu.tsx, toga2-supply/src/utils/handleClientAuthentication.ts, toga2-supply/src/App.tsx, toga2-supply/src/pages/Inventory/viewModel/FIELDS/DUMMYGROUPOPTIONS.ts, toga2-supply/src/pages/Inventory/viewModel/FIELDS/INVENTORYPAGEFIELDS.ts, toga2-supply/src/pages/Inventory/listing/InventoryPage.tsx, toga2-supply/src/pages/Inventory/listing/InventoryRouter.tsx, toga2-supply/src/pages/Inventory/listing/InventorySubTablePage.tsx, toga2-supply/src/pages/Orders/OrdersPage.tsx, toga2-supply/src/pages/Orders/viewModel/useOrdersPageViewModel.ts, toga2-supply/src/pages/Orders/api/OrdersApi.ts, toga2-supply/src/pages/Orders/view/OrderView/viewModel/useOrderDetailsViewModel.ts, toga2-supply/src/components/ui/Tables/PrimaryTable/helperFunctions/renderModalContent.tsx, toga2-supply/src/utils/convertConstructorColumnTitles.ts, toga2-supply/src/api/toga.ts, toga2-supply/package.json |

package/knowledge/2.0/apps/toga2-supply/workflows/client-host-scoping.md

@@ -6,7 +6,7 @@ project: TOGa Supply
 client: shared
 type: workflow
 status: active
-updated: 2026-08-06
+updated: 2026-08-10
 owners: [apeterson, tcox]
 files:
   - toga2-supply/src/stores/useHostNameStore.ts
@@ -20,7 +20,14 @@ files:
   - toga2-supply/src/pages/Inventory/viewModel/FIELDS/DUMMYGROUPOPTIONS.ts
   - toga2-supply/src/pages/Inventory/viewModel/FIELDS/INVENTORYPAGEFIELDS.ts
   - toga2-supply/src/pages/Inventory/listing/InventoryPage.tsx
+  - toga2-supply/src/pages/Inventory/listing/InventoryRouter.tsx
   - toga2-supply/src/pages/Inventory/listing/InventorySubTablePage.tsx
+  - toga2-supply/src/pages/Orders/OrdersPage.tsx
+  - toga2-supply/src/pages/Orders/viewModel/useOrdersPageViewModel.ts
+  - toga2-supply/src/pages/Orders/api/OrdersApi.ts
+  - toga2-supply/src/pages/Orders/view/OrderView/viewModel/useOrderDetailsViewModel.ts
+  - toga2-supply/src/components/ui/Tables/PrimaryTable/helperFunctions/renderModalContent.tsx
+  - toga2-supply/src/utils/convertConstructorColumnTitles.ts
   - toga2-supply/src/api/toga.ts
   - toga2-supply/package.json
 related:
@@ -81,6 +88,52 @@ shared static that shows *only* your additions for other hosts; `npx tsc --noEmi
 in on the real subdomain and confirm columns render (pageMeta), the group-by switcher is hidden if
 you locked it, and nested chevrons appear.
 
+**Two follow-ups the review pass added (2026-08-10) — apply both when host-scoping inventory:**
+
+- **Re-seed `localStorage("selectedGrouping")` when the stored uuid isn't in the resolved host's
+  array** (`InventoryPage.tsx`). The key is shared across hosts on one origin, so a same-origin host
+  switch (or corrupt JSON) otherwise leaves a stale uuid that the non-null-asserted `find` throws on.
+  This is a provable no-op for hosts sharing the default array.
+- **Redirect `/inventory_items` → `/inventory` for hosts whose default view has no `subTableParent`**
+  (`InventoryRouter.tsx`). Do it **data-driven off the resolved view**, not off a host literal: a
+  terminal (non-chained) view otherwise passes `undefined` into `PrimaryTable`.
+
+## Reference implementation 2 — Elite Service Requests: retitling a shared page (2026-08-10)
+
+The second Elite page is the **existing Orders page host-configured**, not a new route — the pattern
+to copy when a client wants "their" version of a shared page under a different name. See
+[Elite supply2 scope](../../../../clients/elite/features/supply2-scope.md) for the client detail.
+
+The shape: a per-host `FIELDS/<HOST>/BASE.json` supplies `pageTitle`, `tableSlug`, `listingSlug`,
+and feature flags; `useOrdersPageViewModel.ts` gets an **explicit host entry** (`ELITE: {base: …}`,
+following the PRUDENTIAL `base` precedent); and every hardcoded slug literal in the page becomes
+`fields?.<key>` **with the old literal as the fallback**. Elite's page replaced **8** occurrences of
+`"sales-orders"` this way. Because no other host defines the new keys, every default path stays
+literal-identical — that is the property that makes the change zero-risk for other tenants, and it is
+what you should be able to assert before merging.
+
+Feature removal is expressed by **omission**, not by a flag check scattered through the page:
+omitting `approvalActionOptions` (plus `approvalsButton.isEnabled: false`) is what drops approvals.
+
+**Routing stays centralized.** No route was added for "Service Requests"; the nav label and the page
+title are config. Do not add per-client routes (see above).
+
+## When a client's table view sits on a DIFFERENT record than the detail route
+
+Elite's `service-requests` table view is built on the **ServiceRequests** record (joining SalesOrders
+1:1), while every details-modal route in the page is a `/sales-orders` record route. A retitled page
+is often *also* a re-recorded page — confirm with the backend which record the view is built on
+before wiring the modal. The fix pattern:
+
+- add a **resolver** API call that translates the row uuid into the record uuid the modal route
+  expects (Elite: `getSalesOrderUuidForServiceRequest()` in `Orders/api/OrdersApi.ts` — `GET
+  /sales-orders` with a ServiceRequests join and `where ServiceRequests.uuid = …`);
+- thread the resolved uuid into the details view model as a react-query whose **`enabled` is gated on
+  the host**, so other hosts never issue the extra request;
+- expect **columns the other record does not have** — see the `isQuote` gotcha below;
+- expect the join to be **optional**: an unmatched row resolves to `null` and the modal opens empty.
+  Decide the empty-state treatment with product; do not silently ship a blank modal.
+
 ## Getting a login for a new host (auth + test user)
 
 Onboarding stalls here more often than in the frontend. Two findings from Elite:
@@ -112,6 +165,12 @@ a plaintext credential. Remember [beta = the dev-sandbox
 cluster](../../_underscore/workflows/local-db-refresh-from-beta.md) — seed the environment the app
 actually talks to.
 
+> **The seeded account does not survive a tenant refresh.** When `Client_Elite` was rebuilt from
+> production (2026-08-07), `devteam@togatech.com` came back as a **re-seeded row with an empty
+> password** — the login failure looks like a wrong password, not a missing user. Re-run the same
+> hash copy from `Client_Compass.Users` (id 127046 on dev-sandbox). Anything else you hand-inserted
+> on beta is gone too — see the gotcha below.
+
 ## Onboarding checklist
 
 1. Confirm the client's subdomain resolves the tenant (hostname → client → `Client_<slug>` DB), and
@@ -147,8 +206,36 @@ actually talks to.
 - **View-model host maps must not depend on a fallback.** Orders' `useOrdersPageViewModel.ts`
   uses `fieldMapping[hostName] || fieldMapping.compass`, but the fallback key is a nonexistent
   lowercase `compass`, so an unrecognized host **throws**. Always add an explicit host entry.
+  (Still true as of 2026-08-10 — the broken fallback was deliberately left in place; fix it only as
+  its own change.)
+- **The row-click modal registry is keyed by `pageTitle`.** `renderModalContent.tsx` picks
+  `modalConfig[hostName][pageTitle] || modalConfig.DEFAULT[pageTitle]` — so **retitling a page
+  silently unhooks its modal**: rows become inert with no error. Elite's modal stayed dead until a
+  `"Service Requests"` key was added to `modalConfig.DEFAULT` routing to `OrderDetailsModal`
+  (additive). Any host given a custom page title must get a matching modal-config key in the same
+  change.
+- **A page slug with no backend page meta used to crash the whole table.**
+  `convertConstructorColumnTitles.ts` dereferenced the meta unguarded
+  (`Cannot read properties of null (reading 'settings')`) — hit the moment a `listingSlug` pointed at
+  a page that does not exist in `Core.Pages`. It is now null-guarded and degrades to `""` labels
+  (callers already fall back to the field name). Reusing another page's `listingSlug` is therefore
+  survivable, but remember it only affects **ACL and search labels** — column headers come from the
+  **table-view** meta, not the page meta.
+- **A record swap costs you columns.** Elite's `service-requests` view is built on ServiceRequests,
+  which has **no `isQuote` column**, so Orders' unconditional `isQuote: false` filter 500'd with
+  `1054 Unknown column`. Filters that assume the SalesOrders shape must be made conditional on a
+  FIELDS flag (`hasQuoteFilter`), not assumed. Backend confirmed this is an FE-side fix.
 
 ## Change history
+- 2026-08-10 — Added **reference implementation 2 — retitling a shared page** (per-host
+  `FIELDS/<HOST>/BASE.json` supplying `pageTitle`/`tableSlug`/`listingSlug`, explicit host entry in
+  the view model, slug literals threaded through `fields?.` with literal fallbacks, feature removal
+  by omission) and a section on **table views built on a different record than the detail route**
+  (uuid resolver, host-gated query, optional join). New gotchas: the modal registry is keyed by
+  `pageTitle` so retitling silently unhooks the modal; `convertConstructorColumnTitles` is now
+  null-guarded for a slug with no page meta; a record swap loses columns (`isQuote` → `1054`). Also
+  recorded the `selectedGrouping` re-seed + terminal-view `/inventory_items` redirect, and that a
+  tenant refresh from prod returns the seeded `devteam` user with an empty password. (tcox)
 - 2026-08-06 — Added the **Elite Inventory reference implementation** (separate host array +
   call-time `getGroupOptions()`, the shared `resolveClientHostName.ts` util, host-scoped
   `getInventoryPageFields()`, additive uuid `else if` branches, `npm run <host>` + hosts-file

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

@@ -23,6 +23,7 @@
 | [Etilize Catalog Item Import & Refresh](features/etilize-catalog-item-import.md) | Client-generic catalog onboarding from an S3 CSV plus an Etilize re-pull. | worker2/Worker/Etilize/Items.php |
 | [Etilize Item Translation Import](features/etilize-item-translation-import.md) | The abstract worker class `_Worker_Etilize_ItemTranslations` imports **non-English** item text from Etilize into the client's `ItemTranslations` table. | worker2/Worker/Etilize/ItemTranslations.php |
 | [Monitoring Framework (Orchestrator + Child Monitors)](features/monitoring-framework.md) | A unified, DB-driven monitoring framework for business-critical data flows (Compass POs, Prudential asset imports, AIG closed claims, …). | worker2/Worker/Monitor.php, worker2/Worker/Monitors/, worker2/Worker/Monitors/RateEntitlement.php, worker2/Worker/Notification/Email.php, worker2/Worker/Rate.php, dbchanges2/Core/2026-05-21 - Monitors.sql, dbchanges2/Core/2026-06-29a - Rate Entitlement Contract Monitor.sql |
+| [NetSuite Integrations Monitor (Monitor/Operations/NetsuiteIntegrations)](features/netsuite-integrations-monitor.md) | `_Worker_Monitor_Operations::NetsuiteIntegrations()` is a cross-client health check that detects **stuck NetSuite ↔ 2.0 integrations**. | worker2/Worker/Monitor/Operations.php, dbchanges2/Core/2026-08-10a - Netsuite Integrations Monitor.sql, _underscore/Database.php, _underscore/Query.php |
 | [NetSuite ↔ ClickUp / TOGA Opportunity Sync (API Message Queue + worker2 webhook)](features/netsuite-opportunity-sync.md) | Outbound sync from NetSuite to TOGA for the record types the Forecast2 importer pulls (opportunities first; sales/items/etc. | worker2/Worker/Netsuite.php, worker2/Worker/Netsuite/Opportunity.php, worker2/Worker/Clickup.php, worker2/Worker/Clickup/Opportunity.php, worker2/Controller/Index.php, _underscore/Worker.php, test/@dave/NetSuite/api-message-queue/lib_amq_queue.js, test/@dave/NetSuite/api-message-queue/ue_api_msg_queue_enqueue.js, test/@dave/NetSuite/api-message-queue/ue_amq_drain.js, test/@dave/NetSuite/api-message-queue/ss_amq_drain.js, test/@dave/NetSuite/api-message-queue/DEPLOY_RUNBOOK.md, test/@dave/clickup/backfill_opportunity_numbers.php, test/@dave/clickup/probe_opportunity_fields.php, test/@dave/probe_clickup_desc_match.php, test/@dave/test_model_load_behavior.php, dbchanges2/Forecast/2026-06-25a - Add unique index on Opportunities netsuiteOpportunityInternalId.sql, _underscore/Model/Forecast/Opportunity.php, test/@dave/approach/TRUE-80044.md, worker/crons/toga2/forecast2/common_import_sales_from_netsuite.php |
 | [NetSuite → Forecast Open-Orders Sync (salesOrder webhook → OpenOrderItems)](features/netsuite-salesorder-open-orders-sync.md) | Webhook-driven, single-record port of the legacy open-orders importer (TRUE-79142). | worker2/Worker/Netsuite/SalesOrder.php, worker2/Worker/Netsuite.php, worker2/Component/Forecast/Db/Db.php, worker2/Worker/Netsuite/Location.php, test/@dave/Junk Drawer/NetSuite/api-message-queue/ue_api_msg_queue_enqueue.js, test/@dave/Junk Drawer/NetSuite/api-message-queue/ue_amq_invoice_resync_salesorder.js, test/@dave/probe_salesorder_rest_shape.php, test/@dave/probe_open_order_lines.php, test/@dave/check_so_status.php, test/@dave/check_so_history.php, test/@dave/probe_so_rest_lines.php, test/@dave/probe_missing_oo_timing.php, test/@dave/probe_missing_oo_createdby.php, test/@dave/probe_drift_so_dates.php, test/@dave/probe_open_order_gating.php, worker/crons/toga2/forecast2/import_open_orders.php, worker/crons/toga2/forecast2/common_import_sales_from_netsuite.php |
 | [NetSuite Supporting-Record Webhook Importer (the reusable recipe)](features/netsuite-supporting-record-webhook-importer.md) | A single **repeatable recipe** for porting a legacy daily-pull NetSuite *supporting-record* importer (the lookup/dimension tables behind Forecast2 — Employees, | worker2/Worker/Netsuite/Employee.php, worker2/Worker/Netsuite/Account.php, worker2/Worker/Netsuite/Classification.php, worker2/Worker/Netsuite/Customer.php, worker2/Worker/Netsuite/Item.php, worker2/Worker/Netsuite.php, _underscore/Model/Forecast/Employee.php, _underscore/Model/Forecast/Account.php, _underscore/Model/Forecast/Classification.php, _underscore/Component/Forecast/Db/Db.php, test/@dave/test_employee_lifecycle.php, test/@dave/test_account_lifecycle.php, test/@dave/test_classification_lifecycle.php, test/@dave/NetSuite/api-message-queue/ue_api_msg_queue_enqueue.js, worker/crons/toga2/forecast2/import_supporting_records.php |

package/knowledge/2.0/apps/worker2/features/all-client-email-queue-monitor.md

@@ -15,6 +15,7 @@ files:
   - dbchanges2/Logs_Client/2026-05-21 - Email.sql
 related:
   - ./oneuptime-worker2-monitoring.md
+  - ./netsuite-integrations-monitor.md
   - ./monitoring-framework.md
   - ../../_underscore/features/email-send-pipeline.md
   - ../../_underscore/features/per-client-database-connections.md

package/knowledge/2.0/apps/worker2/features/netsuite-integrations-monitor.md

@@ -0,0 +1,139 @@
+---
+title: NetSuite Integrations Monitor (Monitor/Operations/NetsuiteIntegrations)
+framework: "2.0"
+repo: worker2
+project: Worker
+client: shared
+type: feature
+status: active
+updated: 2026-08-10
+owners: ["jcardinal"]
+files:
+  - worker2/Worker/Monitor/Operations.php
+  - dbchanges2/Core/2026-08-10a - Netsuite Integrations Monitor.sql
+  - _underscore/Database.php
+  - _underscore/Query.php
+related:
+  - ./all-client-email-queue-monitor.md
+  - ./oneuptime-worker2-monitoring.md
+  - ./monitoring-framework.md
+  - ../../_underscore/features/per-client-database-connections.md
+---
+
+## Summary
+
+`_Worker_Monitor_Operations::NetsuiteIntegrations()` is a cross-client health check that
+detects **stuck NetSuite ↔ 2.0 integrations**. It sweeps **every** client's business
+database (`Client_<X>`), looks in the `Parameters` table for rows where
+`` `key` `` LIKE `NETSUITE_EXECUTION_MODE_%` and `` `value` `` LIKE `1-RUNNING`, and pushes
+one aggregate payload to a single OneUptime Incoming Request monitor with the **offending
+integrations named** in the body. A row parked at the `1-RUNNING` sentinel means an
+integration hung mid-run.
+
+This is the second all-client monitor in `_Worker_Monitor_Operations`, modeled exactly on
+its sibling [EmailQueue](./all-client-email-queue-monitor.md) — a "dumb reporter, smart
+monitor": the worker only reports measured values and OneUptime holds the alarm
+thresholds. It is **shared internal operational infrastructure**, not a client feature.
+
+## Key files / entry points
+
+- `worker2/Worker/Monitor/Operations.php` — `abstract class _Worker_Monitor_Operations`.
+  - `public static function NetsuiteIntegrations(): string` — the action, route
+    `Monitor/Operations/NetsuiteIntegrations`.
+  - `private static function resolveClientDatabases(): array` — one `DB_CORE` query
+    returning every client + its **business** database name (`Client_<X>`) + this
+    environment's hosts. Mirrors `resolveClientLogDatabases()` but joins `Core.Clients` on
+    `clientDatabaseId` (not `logDatabaseId`).
+- `dbchanges2/Core/2026-08-10a - Netsuite Integrations Monitor.sql` — the `Core.CronJobs`
+  seed row (see below).
+- Dispatched by action string, not PHP import — the autoloader + `_Worker::runTask()`
+  reach the class via the cron action path.
+
+## How it works
+
+1. **Resolve every client's business database.** `resolveClientDatabases()` joins
+   `Clients` → `Databases` (via `Clients.clientDatabaseId`) → `DatabaseHosts` →
+   `Environments`/`Regions`, all **LEFT OUTER JOINs** so a misconfigured client is
+   reported, not silently dropped (`unresolvedClients`). Closest region first; later rows
+   for the same client are skipped.
+2. **Register each client's business DB under its REAL database name, no alias**, guarded
+   by `if (!isset(_Database::$_registers[$dbName]))`, then query via `_Query`. A per-client
+   loop cannot reuse a shared alias — every iteration would clobber it.
+3. **Sweep `Parameters` per client:**
+   `` SELECT `key`, `value` FROM Parameters WHERE `key` LIKE 'NETSUITE_EXECUTION_MODE_%' AND `value` LIKE '1-RUNNING' ``.
+   The integration **type** is the key with the `NETSUITE_EXECUTION_MODE_` prefix stripped
+   via `substr()` (e.g. `NETSUITE_EXECUTION_MODE_SALES_ORDERS` → `SALES_ORDERS`).
+4. **Bucket each client** into `checked`, `skipped` (no `Parameters` table —
+   `isMissingTableError()`), or `unreachable` (any other query/connection failure). A
+   per-client `try/catch (Throwable)` keeps one bad client from failing the sweep.
+5. **Decide the tokens and push once** to OneUptime.
+
+### Payload contract — `alarm` and `probe` are SEPARATE tokens
+
+Follows the [OneUptime push-metric pattern](./oneuptime-worker2-monitoring.md): OneUptime
+can only string-match a body, so the worker decides and emits tokens.
+
+| Field | Meaning |
+|---|---|
+| `status` | `reporting`, or `error` (reserved for the Core lookup itself failing → `error:client_lookup_failed`) |
+| `alarm` | `DEGRADED` when any stuck integration is found, else `OK` |
+| `probe` | `DEGRADED` when any client DB is unreachable, else `OK` |
+| `stuckCount` | number of stuck integrations found |
+| `offendingIntegrations` | comma-joined `"ClientName: TYPE"` |
+| `clientsChecked`, `clientsSkipped` | coverage counters |
+| `unreachableClients`, `unresolvedClients` | named coverage gaps |
+| `checkedAtUtc` | `gmdate('c')` |
+
+## Cron seed (dbchanges2)
+
+`dbchanges2/Core/2026-08-10a - Netsuite Integrations Monitor.sql` — INSERT into
+`Core.CronJobs`: action `Monitor/Operations/NetsuiteIntegrations`, schedule
+`*/10 * * * *` (every 10 min), `maxExecutionTime` 120, `isActive` 1, `parameters` NULL,
+fixed random uuid. Targets **only** `Core` (no cross-cluster refs), INSERT-only and
+unguarded per dbchanges2 conventions. Modeled on
+`Core/2026-07-29a - AIG Entitlement API Failure Monitor.sql`.
+
+**Shipped `isActive=1` while the OneUptime URL is still a placeholder** (developer's
+choice): the sweep runs but the push fails soft (`error_log`) until the real URL is pasted
+into the worker method.
+
+## Gotchas / known issues
+
+- **`` `key` `` and `` `value` `` are MySQL reserved words** — backtick-quote them in the
+  `Parameters` query.
+- **Single source of truth for the key prefix.** `$KEY_PREFIX` builds both the `LIKE`
+  pattern (via `_Database::escape`) and the `substr()` that derives the integration type;
+  never hardcode the prefix twice.
+- **Never-throw / 200-on-all-paths.** The method always returns a summary string. The
+  OneUptime push is `setLogging(false)` + `setThrowExceptionsOnFailure(false)` **and**
+  wrapped in its own `try/catch`, so a failed ping never fails the worker job.
+- **OneUptime push URL is a credential** — it lives only as an in-file value in the worker
+  method, never committed to dbchanges2 and never recorded in a doc. It is currently a
+  placeholder.
+- **Business DB, not logs DB.** Join `Clients.clientDatabaseId` for `Client_<X>`; the
+  sibling EmailQueue monitor joins `logDatabaseId` for `Logs_<X>`. See
+  [per-client database connections](../../_underscore/features/per-client-database-connections.md).
+- The all-client resolution gotchas from
+  [EmailQueue](./all-client-email-queue-monitor.md) apply verbatim: LEFT OUTER JOIN every
+  level, null host columns unless the environment join matched, detect missing table by
+  MySQL error **number** 1146 (not message text), and remember a passing dev run (single
+  all-in-one endpoint) does not prove cross-cluster correctness.
+
+## Change history
+
+- 2026-08-10 — Built `NetsuiteIntegrations()` + `resolveClientDatabases()` on
+  `_Worker_Monitor_Operations` (all-client `Parameters` sweep for
+  `NETSUITE_EXECUTION_MODE_%` = `1-RUNNING`), plus the `Core.CronJobs` seed
+  (`*/10 * * * *`, `isActive=1`) and an OneUptime Incoming Request monitor import. OneUptime
+  URL still a placeholder; sweep runs and pushes fail-soft until pasted. (jcardinal)
+
+## Related docs
+
+- [All-Client Email Queue Monitor](./all-client-email-queue-monitor.md) — the sibling
+  all-client monitor this one is modeled on.
+- [OneUptime push-metric monitors for 2.0 workers](./oneuptime-worker2-monitoring.md) — the
+  push/token pattern and OneUptime criteria (incl. `{{requestBody.*}}` incident templating).
+- [Per-Client Database Connections](../../_underscore/features/per-client-database-connections.md)
+  — business/log database name resolution.
+</content>
+</invoke>

package/knowledge/2.0/apps/worker2/features/oneuptime-worker2-monitoring.md

@@ -111,6 +111,25 @@ log dive. `status: "error"` stays reserved for the checker being **fully** blind
 resolution query failed). Worked example:
 [All-Client Email Queue Monitor](./all-client-email-queue-monitor.md).
 
+### Incident / alert title & description templating (`{{requestBody.*}}`)
+
+OneUptime incident and alert **titles and descriptions support `{{variable}}` templating**
+(verified against OneUptime docs 2026-08-10). For an **Incoming Request** monitor, the
+POSTed JSON body is addressed via the `requestBody` prefix — e.g.
+`{{requestBody.offendingIntegrations}}`, `{{requestBody.stuckCount}}`,
+`{{requestBody.checkedAtUtc}}`, `{{requestBody.message}}`. Other available vars:
+`{{requestHeaders}}`, `{{requestMethod}}`, `{{incomingRequestReceivedAt}}`.
+
+- **Missing paths resolve to empty string**, so one template covers both a normal degraded
+  payload and an edge case like `error:client_lookup_failed` without a second template.
+- Body-content criteria use `checkOn: "Request Body"` / `filterType: "Contains"`; the
+  heartbeat criterion uses `"Not Recieved In Minutes"` (note OneUptime's misspelling).
+- A degraded criterion can OR several tokens, e.g. Contains `"alarm":"DEGRADED"` **OR**
+  `"error":"client_lookup_failed"`.
+- Reuse the project's existing status/severity ObjectIDs when authoring the import JSON.
+- Docs: https://oneuptime.com/docs/monitor/incident-alert-templating and
+  https://oneuptime.com/docs/en/monitor/incoming-request-monitor
+
 ### Heartbeat / cron cadence timing
 
 The 10-min-Degraded / 15-min-Offline heartbeat thresholds pair with a **5-minute** cron
@@ -192,6 +211,10 @@ check for another client.
   monitors must pass the region (see [Cloud S3 helpers](../../_underscore/features/cloud-s3-helpers.md)).
 
 ## Change history
+- 2026-08-10 — Documented OneUptime incident/alert `{{requestBody.*}}` templating (missing
+  paths → empty string; `Not Recieved In Minutes` heartbeat spelling), discovered while
+  wiring the second all-client `_Worker_Monitor_Operations` monitor —
+  [NetSuite Integrations Monitor](./netsuite-integrations-monitor.md). (jcardinal)
 - 2026-07-30 — Added the multi-client refinement of the payload contract: a **separate `probe`
   token** (`OK`/`DEGRADED`) alongside `alarm`, so a partial logs-cluster outage cannot read as a
   healthy metric, plus naming the offending clients in the body. Recorded that the previously

package/knowledge/INDEX.md

@@ -19,7 +19,7 @@ _Auto-generated by `knowledge.js index`. Do not hand-edit._
 ## 2.0 framework
 
 - **_underscore** (_Underscore) _(framework core)_ — 48 doc(s) → [2.0/apps/_underscore/INDEX.md](2.0/apps/_underscore/INDEX.md)
-- **worker2** (Worker) — 42 doc(s) → [2.0/apps/worker2/INDEX.md](2.0/apps/worker2/INDEX.md)
+- **worker2** (Worker) — 43 doc(s) → [2.0/apps/worker2/INDEX.md](2.0/apps/worker2/INDEX.md)
 - **api2** (API) — 22 doc(s) → [2.0/apps/api2/INDEX.md](2.0/apps/api2/INDEX.md)
 - **dbchanges2** (Database Changes) _(framework core)_ — 8 doc(s) → [2.0/apps/dbchanges2/INDEX.md](2.0/apps/dbchanges2/INDEX.md)
 - **toga2-supply** (TOGa Supply) — 5 doc(s) → [2.0/apps/toga2-supply/INDEX.md](2.0/apps/toga2-supply/INDEX.md)

package/knowledge/clients/elite/INDEX.md

@@ -2,6 +2,6 @@
 
 | Doc | Framework | Summary | Files |
 |-----|-----------|---------|-------|
-| [Elite — supply2 frontend scope (Inventory built, Sales Orders pending)](features/supply2-scope.md) | 2.0 | Scope for onboarding Elite to the `toga2-supply` frontend (host `ELITE`). | toga2-supply/ELITE-CLIENT-TASK-NOTES.md, toga2-supply/src/pages/Inventory/viewModel/FIELDS/DUMMYGROUPOPTIONS.ts, toga2-supply/src/pages/Inventory/viewModel/FIELDS/INVENTORYPAGEFIELDS.ts, toga2-supply/src/pages/Inventory/viewModel/index.ts, toga2-supply/src/pages/Inventory/listing/InventoryPage.tsx, toga2-supply/src/pages/Inventory/listing/InventorySubTablePage.tsx, toga2-supply/src/utils/resolveClientHostName.ts, toga2-supply/src/pages/Orders/OrdersPage.tsx, toga2-supply/src/pages/Orders/viewModel/useOrdersPageViewModel.ts, toga2-supply/src/pages/Orders/view/OrderView/viewModel/useOrderDetailsViewModel.ts, toga2-supply/src/components/ui/Tables/PrimaryTable/helperFunctions/renderModalContent.tsx, toga2-supply/src/components/layout/SlideMenu/SlideMenu.tsx, toga2-supply/package.json |
+| [Elite — supply2 frontend scope (Inventory + Service Requests, both built)](features/supply2-scope.md) | 2.0 | Scope for onboarding Elite to the `toga2-supply` frontend (host `ELITE`). | toga2-supply/ELITE-CLIENT-TASK-NOTES.md, toga2-supply/src/pages/Inventory/viewModel/FIELDS/DUMMYGROUPOPTIONS.ts, toga2-supply/src/pages/Inventory/viewModel/FIELDS/INVENTORYPAGEFIELDS.ts, toga2-supply/src/pages/Inventory/viewModel/index.ts, toga2-supply/src/pages/Inventory/listing/InventoryPage.tsx, toga2-supply/src/pages/Inventory/listing/InventoryRouter.tsx, toga2-supply/src/pages/Inventory/listing/InventorySubTablePage.tsx, toga2-supply/src/utils/resolveClientHostName.ts, toga2-supply/src/utils/convertConstructorColumnTitles.ts, toga2-supply/src/pages/Orders/OrdersPage.tsx, toga2-supply/src/pages/Orders/viewModel/FIELDS/ELITE/BASE.json, toga2-supply/src/pages/Orders/viewModel/useOrdersPageViewModel.ts, toga2-supply/src/pages/Orders/api/OrdersApi.ts, toga2-supply/src/pages/Orders/view/OrderView/viewModel/useOrderDetailsViewModel.ts, toga2-supply/src/components/ui/Tables/PrimaryTable/helperFunctions/renderModalContent.tsx, toga2-supply/src/components/layout/SlideMenu/SlideMenu.tsx, toga2-supply/package.json |
 | [Elite — stale TableView config (11 dead Core.RecordFields across 9 views)](features/supply2-tableview-config-drift.md) | 2.0 | `Client_Elite`'s `TableViewJoins` predate **two** platform bridge-table migrations and still reference **11 deleted `Core.RecordFields` ids (211, 321, 932, 358, | dbchanges2/Client_Elite/, dbchanges2/Client_Nychh/2026-06-19a - FixItemFulfillmentTableViewTrackingAndRoot.sql |
 | [Elite](profile.md) | 2.0 | Elite is a managed-services client that uses **Freshservice** as their helpdesk platform. | worker2/Worker/Elite.php, library/app/api/toga2.php |

package/knowledge/clients/elite/features/supply2-scope.md

@@ -1,12 +1,12 @@
 ---
-title: Elite — supply2 frontend scope (Inventory built, Sales Orders pending)
+title: Elite — supply2 frontend scope (Inventory + Service Requests, both built)
 framework: "2.0"
 repo: toga2-supply
 project: TOGa Supply
 client: elite
 type: client-feature
 status: active
-updated: 2026-08-06
+updated: 2026-08-10
 owners: [apeterson, tcox]
 files:
   - toga2-supply/ELITE-CLIENT-TASK-NOTES.md
@@ -14,10 +14,14 @@ files:
   - toga2-supply/src/pages/Inventory/viewModel/FIELDS/INVENTORYPAGEFIELDS.ts
   - toga2-supply/src/pages/Inventory/viewModel/index.ts
   - toga2-supply/src/pages/Inventory/listing/InventoryPage.tsx
+  - toga2-supply/src/pages/Inventory/listing/InventoryRouter.tsx
   - toga2-supply/src/pages/Inventory/listing/InventorySubTablePage.tsx
   - toga2-supply/src/utils/resolveClientHostName.ts
+  - toga2-supply/src/utils/convertConstructorColumnTitles.ts
   - toga2-supply/src/pages/Orders/OrdersPage.tsx
+  - toga2-supply/src/pages/Orders/viewModel/FIELDS/ELITE/BASE.json
   - toga2-supply/src/pages/Orders/viewModel/useOrdersPageViewModel.ts
+  - toga2-supply/src/pages/Orders/api/OrdersApi.ts
   - toga2-supply/src/pages/Orders/view/OrderView/viewModel/useOrderDetailsViewModel.ts
   - toga2-supply/src/components/ui/Tables/PrimaryTable/helperFunctions/renderModalContent.tsx
   - toga2-supply/src/components/layout/SlideMenu/SlideMenu.tsx
@@ -32,13 +36,14 @@ related:
 
 Scope for onboarding Elite to the `toga2-supply` frontend (host `ELITE`). Elite's supply2 surface
 is two pages: **Inventory** (a single "Units By Items" group-by view, nested expand, no modal) and
-**Sales Orders** (table + details modal, **no approvals**).
+**Service Requests** (the Orders page, host-retitled; table + details modal, **no approvals**).
 
-**Status (2026-08-06):** Part 1 — **Inventory is code-complete** and is the platform's
-first-ever host-scoping of the global inventory statics; it follows the shared
-[host-scoping playbook](../../../2.0/apps/toga2-supply/workflows/client-host-scoping.md), where the
-reusable shape now lives. Part 2 — **Sales Orders is a separate ticket, not started.** The
-source-of-truth plan is `toga2-supply/ELITE-CLIENT-TASK-NOTES.md` at the repo root.
+**Status (2026-08-10): both pages are built and live-verified on beta/dev-sandbox.** Part 1 —
+Inventory is the platform's first-ever host-scoping of the global inventory statics and follows the
+shared [host-scoping playbook](../../../2.0/apps/toga2-supply/workflows/client-host-scoping.md),
+where the reusable shape lives. Part 2 — "Sales Orders" was implemented and then **pivoted into
+Service Requests**, iteratively debugged against beta 2026-08-07 → 08-10, and verified end-to-end.
+The source-of-truth plan is `toga2-supply/ELITE-CLIENT-TASK-NOTES.md` at the repo root.
 
 ## Part 1 — Inventory (built)
 
@@ -57,41 +62,101 @@ One host-scoped group-by view only: **"Units By Items"**, no group-by modal.
   Elite uuid; NYCHH's `94f1e621…` / `904cc7b1…` branches were not touched.
 - `src/utils/resolveClientHostName.ts` (new, shared) resolves the host from
   `useHostNameStore.getState()` with a `window.location.hostname` subdomain fallback.
-- `SlideMenu.tsx` has an **Inventory-only** Elite branch whose deep-link preselects the uuid.
+- `SlideMenu.tsx` has an Elite branch whose Inventory deep-link preselects the uuid.
 - Local run: `npm run elite` (`vite --host elite.togasupply`) plus a
   `127.0.0.1 elite.togasupply` hosts-file entry.
 
-**Verified:** every playbook guardrail holds (one `isDefault` per host; the diff for other hosts is
-only the export rename; `npx tsc --noEmit` clean). Live on dev-sandbox/beta: login works, columns
-render from pageMeta, the group-by switcher is hidden, chevrons render.
-
-**Not yet validated: the nested expand.** Expanding the nested table 500s — that is a **backend
-data-config** problem in `Client_Elite`, not a frontend one; see
-[Elite supply2 TableView config drift](./supply2-tableview-config-drift.md).
-
-## Part 2 — Sales Orders (separate ticket, not started)
-
-- Table columns are backend pageMeta-driven for slug `sales-orders`; ACL fetched under slug
-  `sales-orders-listing`.
-- **Details modal needs no code:** `renderModalContent.tsx` DEFAULT routes unknown hosts to
-  `OrderDetailsModal` only (no `ApprovalsModal`); `useOrderDetailsViewModel.ts` falls back to
-  `DEFAULTFIELDS.json`.
-- **Required FE change:** add an explicit `ELITE` entry to `useOrdersPageViewModel.ts`
-  `fieldMapping`. The fallback `fieldMapping[hostName] || fieldMapping.compass` references a
-  nonexistent lowercase `compass` key, so an unrecognized host **throws**. Elite's FIELDS must
-  set `approvalsButton.isEnabled=false` and omit `approvalActionOptions` to exclude approvals.
-- That ticket will also hit the stale `sales-orders` TableView joins — see the config-drift doc.
-
-## Known limitations (current state)
-
-- **Elite login lands on `/` (Orders) and crashes.** Because Orders has no `ELITE` `fieldMapping`
-  entry, the landing route throws until the Sales Orders ticket lands. Deliberate: the nav
-  deliberately exposes **Inventory only** for now, and adding an Orders entry before that ticket
-  would advertise a broken page.
+**Hardening from the CodeRabbit review (2026-08-10)** — guardrail-preserving variants, not the
+reviewer's literal diffs:
+
+- `InventoryPage.tsx` **re-seeds** the persisted `localStorage("selectedGrouping")` whenever the
+  stored option's uuid is not present in the resolved host's array. This covers same-origin host
+  switches and corrupt JSON, and is a provable no-op for hosts that share the default array (their
+  stored uuids always match).
+- `InventoryRouter.tsx` redirects `/inventory_items` → `/inventory` for any host whose default view
+  has **no `subTableParent`** — data-driven, no host literal. Without it Elite's terminal nested
+  view passes `undefined` into `PrimaryTable`.
+
+## Part 2 — Service Requests (built, verified 2026-08-10)
+
+**"Service Requests" is the Orders page host-configured, not a new route.** The supply2.5 mockup's
+own source says so: `elite-app.jsx` has `VIEW_META.Orders.title = "Service Requests"` and a nav
+entry `{label: "Orders", text: "Service Requests"}`, and its "service request details modal" is a
+details-only order modal. The translation principle held throughout: **the 2.5 mockup is the spec
+for WHAT, supply2.0 components are the HOW** — so this shipped as config + slug threading on the
+existing `OrdersPage`, with zero new routes.
+
+**Implementation**
+
+- `src/pages/Orders/viewModel/FIELDS/ELITE/BASE.json` (new): `pageTitle` `"Service Requests"`,
+  `tableSlug` `"service-requests"`, `listingSlug` `"sales-orders-listing"`, `hasQuoteFilter` false,
+  `approvalsButton.isEnabled` false, `exportButton` true, and **no `approvalActionOptions`** (that
+  omission is what removes approvals).
+- `useOrdersPageViewModel.ts`: an explicit `ELITE: { base: BASE_ELITE }` entry plus the host branch,
+  following the **PRUDENTIAL** `base` precedent. The broken `|| fieldMapping.compass` fallback was
+  deliberately left untouched — fixing it is out of scope and every host now needs an explicit entry
+  anyway (see the playbook).
+- `OrdersPage.tsx`: all **8** hardcoded `"sales-orders"` literals now read `fields?.tableSlug` with a
+  `sales-orders` fallback; the page title comes from `fields`; the ACL check is optional-chained; and
+  the `isQuote` filter is **conditional** — omitted entirely when `fields?.hasQuoteFilter === false`.
+- `SlideMenu.tsx`: the Elite nav is "Service Requests" + Inventory.
+
+**Zero cross-client risk:** no other host defines any of the new FIELDS keys, so every default path
+is literal-identical to before.
+
+### The backend `service-requests` view is built on ServiceRequests, not SalesOrders
+
+The backend table view (slug supplied by the backend dev) is built on the **ServiceRequests RECORD**
+— joining Tickets / Customers / ServiceRequestTypes / SalesOrders, where
+`SalesOrders.serviceRequestId = ServiceRequests.id` (1:1). It is **not** a renamed SalesOrders view.
+Three consequences drove the rest of the work:
+
+1. **Row uuids are ServiceRequests uuids, but every detail-modal route is a `/sales-orders` record
+   route.** Fixed with `getSalesOrderUuidForServiceRequest()` in `src/pages/Orders/api/OrdersApi.ts`
+   (`GET /sales-orders` + a ServiceRequests join, `where ServiceRequests.uuid = …`), whose resolved
+   `detailsUuid` is threaded through `useOrderDetailsViewModel.ts` via react-query. The query is
+   **enabled only for `hostName === "ELITE"`**, so every other host bypasses it entirely.
+2. **ServiceRequests has no `isQuote` column.** `OrdersPage`'s unconditional `isQuote: false` filter
+   500'd with `1054 unknown column`; the backend confirmed the fix belongs on the FE, hence
+   `hasQuoteFilter`.
+3. **There is no `service-requests-listing` page in `Core.Pages`.** Elite reuses
+   `sales-orders-listing`. Column headers come from the **table-view** meta, not the page meta, so
+   the only things affected by the reuse are ACL and search labels.
+
+Verified working end-to-end on the one Elite service request that has a linked sales order
+(ticket INC-13982).
+
+## Open question — orphan ServiceRequests (needs backend/product input)
+
+**5 of 6** Elite service requests on dev-sandbox have **no linked SalesOrder**, so the details modal
+opens empty — the resolver correctly yields `null` and there is nothing to render. Undecided:
+
+- an explicit "no order linked" empty state, or
+- a ServiceRequest-level detail view (not just an order modal), or
+- making order-less rows non-clickable.
+
+The prerequisite answer is a data question: **is an order-less service request a legitimate
+lifecycle state**, or is the dev-sandbox data simply incomplete? Do not pick a UI treatment before
+that is answered.
+
+## Known limitations / notes
+
 - `Client_Elite` contains **three pre-existing test Items** (ids 3–5, created 2025-09-18 during
   Elite onboarding) — not test data from this work.
+- The Elite work still sits on top of the stale `Client_Elite` TableView config — see
+  [supply2-tableview-config-drift](./supply2-tableview-config-drift.md), including the
+  2026-08-07 prod→beta refresh that wiped the hand-built `service-requests` view.
 
 ## Change history
+- 2026-08-10 — **Service Requests shipped and verified** (INC-13982): implemented as the Orders page
+  host-configured, not a new route — new `FIELDS/ELITE/BASE.json` (pageTitle/tableSlug/listingSlug/
+  `hasQuoteFilter`/no `approvalActionOptions`), explicit `ELITE` entry in `useOrdersPageViewModel`,
+  8 hardcoded `sales-orders` literals threaded through `fields?.tableSlug`, conditional `isQuote`
+  filter, and `getSalesOrderUuidForServiceRequest()` resolving ServiceRequests uuids → SalesOrders
+  record routes (ELITE-only). Recorded that the backend view is built on the ServiceRequests record
+  (no `isQuote`, no `service-requests-listing` page) and the open orphan-ServiceRequest question.
+  Also landed the CodeRabbit Inventory hardening (`selectedGrouping` re-seed, `/inventory_items`
+  redirect for terminal views). (tcox)
 - 2026-08-06 — Elite Inventory implemented (first host-scoping of the global inventory statics):
   separate `eliteGroupOptions` array + `getGroupOptions()`, `ELITE_UNITS_BY_ITEMS_UUID`, shared
   `resolveClientHostName.ts`, host-scoped `getInventoryPageFields()`, additive page branches,
@@ -100,4 +165,3 @@ data-config** problem in `Client_Elite`, not a frontend one; see
   keep the nav Inventory-only until the Sales Orders ticket (Orders throws for unmapped hosts).
   (tcox)
 - 2026-08-04 — Captured the planned Elite supply2 scope (Inventory single-view + Sales Orders without approvals) from the ELITE-CLIENT-TASK-NOTES.md scoping session; no code written yet (apeterson)
-</content>

package/knowledge/clients/elite/features/supply2-tableview-config-drift.md

@@ -6,7 +6,7 @@ project: Database Changes
 client: elite
 type: client-feature
 status: active
-updated: 2026-08-06
+updated: 2026-08-10
 owners: [tcox]
 files:
   - dbchanges2/Client_Elite/
@@ -15,6 +15,7 @@ related:
   - ./supply2-scope.md
   - ../../../2.0/apps/_underscore/features/tracking-number-bridges.md
   - ../../../2.0/apps/_underscore/features/units-for-items-for-purchase-orders.md
+  - ../../../2.0/apps/_underscore/features/page-meta-context-field-settings.md
 ---
 
 ## Summary
@@ -87,6 +88,30 @@ Do **not** hand-patch view by view. Diff `Client_Elite.TableViewJoins` wholesale
 **production as well as dev-sandbox** — production reproduces the same 500 at go-live otherwise.
 `sales-order-shipments` (join 10) is the one case a NYCHH diff cannot resolve.
 
+## The 2026-08-07 prod→beta refresh — what a rebuild costs you
+
+`Client_Elite` on dev-sandbox was **rebuilt from production** at 11:55 on 2026-08-07 (with a beta API
+redeploy). Everything hand-inserted on beta was lost, which is the strongest argument yet for the
+recommendation above. Four distinct breakages followed, all diagnosed by reading the DB:
+
+1. **The hand-built `service-requests` table view was wiped** — production never had it, so the
+   rebuild simply did not carry it. The backend dev recreated it by hand *again*. **Every beta
+   hand-insert must become a `dbchanges2` migration or the next refresh eats it.**
+2. **`devteam@togatech.com` came back with an EMPTY password** (re-seeded row). Restored by copying
+   the bcrypt hash from `Client_Compass.Users` id 127046 — see the
+   [host-scoping playbook](../../../2.0/apps/toga2-supply/workflows/client-host-scoping.md).
+3. **The Orders `isQuote` filter started 500ing** (`1054 Unknown column`) — ServiceRequests has no
+   such column; fixed on the frontend (see [supply2-scope](./supply2-scope.md)).
+4. **Elite `/pages/meta?slug=inventory` began 500ing** with *"Undefined array key 190"* — a
+   `_underscore` framework bug in `Page::meta()` on context-scoped field settings, newly fatal
+   because of the strict Sentry error handler that shipped in the same redeploy. See
+   [legacy page meta](../../../2.0/apps/_underscore/features/page-meta-context-field-settings.md).
+
+**Row ids are not stable across a re-import.** `TableViewJoins` ids shifted with the rebuild, so any
+note, script, or diff that identifies a join by **row id** is worthless after a refresh. Match rows
+by **(`tableViewId`, `joinRecordId`, `joinOnRecordFieldId`)** instead — the id columns in the table
+above are a snapshot for orientation, not a key.
+
 ## Gotchas / known issues
 
 - **A `Client_*` DB that predates a platform migration fails silently until a user opens the
@@ -98,10 +123,13 @@ Do **not** hand-patch view by view. Diff `Client_Elite.TableViewJoins` wholesale
   [error-reporting-issue-event](../../../2.0/apps/_underscore/features/error-reporting-issue-event.md).
 
 ## Change history
+- 2026-08-10 — Recorded the **2026-08-07 prod→beta rebuild of `Client_Elite`** and its four
+  breakages (wiped hand-built `service-requests` view, empty-password `devteam` user, the `isQuote`
+  `1054`, and the `/pages/meta` 500), plus the rule that **`TableViewJoins` row ids shift on
+  re-import — match by (`tableViewId`, `joinRecordId`, `joinOnRecordFieldId`), never by id.** (tcox)
 - 2026-08-06 — Documented Elite's stale TableView config: 11 dead `Core.RecordFields` (211, 321,
   932, 358, 1431) across 9 views, left behind by the tracking-number-bridge (319) and
   `SalesOrderItems_PurchaseOrderItems` (289) migrations that NYCHH received and Elite did not.
   Verified the view-17 fix live, then **reverted it** at the developer's request; recommended a
   wholesale `Client_Elite` vs `Client_Nychh` diff shipped as a dbchanges2 migration to prod, and
   flagged `sales-order-shipments` join 10 as broken in NYCHH too. (tcox)
-</content>

package/knowledge/clients/elite/profile.md

@@ -10,7 +10,7 @@ project: Worker
 client: elite
 type: profile
 status: active
-updated: 2026-08-06
+updated: 2026-08-10
 owners: [snaredla, apeterson, tcox]
 files:
   - worker2/Worker/Elite.php
@@ -28,20 +28,29 @@ Elite is a managed-services client that uses **Freshservice** as their helpdesk
 TOGA 2 is the source of truth for tickets, notes, and file attachments. The integration
 keeps Freshservice and TOGA 2 in sync via webhook-driven worker jobs.
 
-**Elite is also being onboarded to TOGa Supply (2026-08).** The frontend scope and its current
-state live in [supply2-scope](features/supply2-scope.md); the backend blocker (stale
+**Elite is also being onboarded to TOGa Supply (2026-08).** Both frontend pages — **Inventory** and
+**Service Requests** (the Orders page host-retitled, not a new route) — are built and live-verified
+on beta as of 2026-08-10; see [supply2-scope](features/supply2-scope.md). The backend blocker (stale
 `Client_Elite` TableView config, a production go-live risk) is in
 [supply2-tableview-config-drift](features/supply2-tableview-config-drift.md). On the backend,
 dbchanges2 **PR #454** (TRUE-80499, snaredla24, 2026-08-05) added the **netsuite** module to
 `Client_Elite/_modules.txt` — the supply-chain schema layer is arriving.
 
+Elite's service-request data model: `ServiceRequests` is the record the `service-requests` table
+view is built on (joining Tickets / Customers / ServiceRequestTypes / SalesOrders, with
+`SalesOrders.serviceRequestId = ServiceRequests.id`, 1:1). **Most Elite service requests on
+dev-sandbox have no linked sales order** — whether that is a legitimate lifecycle state is an open
+question for backend/product (see supply2-scope).
+
 **Tenant/test-account notes.** `Core.Domains` rows for Elite already exist in **every**
 environment (dev `http://elite.togasupply`, beta, production, sandbox-dev) with no dbchanges2 Core
 migration creating them, and Elite has **no `ClientAuthentications` row** — supply2 login is
 ordinary password auth. The shared `devteam@togatech.com` test user was seeded into dev-sandbox
 `Client_Elite.Users` (+ `Users_Roles`; Elite roles are 1=Base, 2=Developer, 3=API, 4=Public) from
 `Client_Compass.Users` — see the
-[host-scoping playbook](../../2.0/apps/toga2-supply/workflows/client-host-scoping.md).
+[host-scoping playbook](../../2.0/apps/toga2-supply/workflows/client-host-scoping.md). **Note:**
+`Client_Elite` on dev-sandbox was rebuilt from production on 2026-08-07, which emptied that user's
+password and wiped hand-built config — re-seeding may be needed again after any refresh.
 
 ## TOGA 2 API credentials
 

package/package.json

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