toga-ai 1.0.561 → 1.0.563

package/knowledge/1.0/apps/library/INDEX.md

@@ -16,6 +16,5 @@
 | [NetSuite SuiteQL/REST API Reference](features/netsuite-suiteql-api-reference.md) | General working reference for the Agilant NetSuite integration: how to authenticate, how SuiteQL behaves, and the confirmed schema of the tables/columns/codes w | library/app/api/netsuite/rest.php, library/ssl/netsuite_ec_key.pem, test/@dave/Junk Drawer/nsq.php |
 | [NetSuite SuiteQL/REST Shim — Field Semantics](features/netsuite-suiteql-rest-shim.md) | `App_Api_Netsuite_Rest` is the REST/SuiteQL replacement for the deprecated NetSuite SOAP toolkit. | library/app/api/netsuite/rest.php |
 | [NetSuite Sync Alert Monitor (App_SystemMonitor_NetSuiteIntegration)](features/netsuite-sync-alert-monitor.md) | `App_SystemMonitor_NetSuiteIntegration` (`library/app/systemmonitor/netsuiteintegration.php`, title **"NetSuite Sync Alert"**) is a 1.0 system monitor that watc | library/app/systemmonitor/netsuiteintegration.php, worker/crons/infrastructure/system_monitors.php |
-| [App_Api_ServiceRequest — provisioning a TOGa 2.0 Service Request from 1.0](features/service-request-toga2-provisioning.md) | `App_Api_ServiceRequest` (`library/app/api/servicerequest.php`) is the shared 1.0-side class that turns a posted form into a **TOGa 2.0 Service Request** — it v | library/app/api/servicerequest.php, library/app/api/toga2.php, togadesk/desk/includes/classes/class.ticket.php |
 | [Startech PC Matic B2B Sync (library)](features/startech-pcmaticb2b-sync.md) | `library/app/api/toga2.php` handles bidirectional ticket sync for PC Matic B2B between TOGaDesk 1.0 and TOGA 2.0. | library/app/api/toga2.php, library/app/api/startechticket.php, worker/crons/toga2/startech/common_import_supporting_records.php |
 | [App_Api_Toga2 — TOGa2 API Client & 1.0↔2.0 Sync Bridge](features/toga2-api-client-and-bridge.md) | `App_Api_Toga2` (`library/app/api/toga2.php`, ~8400 lines) is the **1.0-side client for the TOGa 2 (`_underscore`/api2) public API** *and* the home of the cross | library/app/api/toga2.php, worker/crons/toga2/aig/sync_togasupply_aig.php, worker/crons/toga2/wje/sync_togasupply_wje.php, test/@Mark/AIG/test_multi_email.php |

package/knowledge/1.0/apps/library/features/app-class-placement-base-contracts.md

@@ -17,7 +17,7 @@ files:
   - library/app/api/carrier/fedex.php
 related:
   - ../architecture.md
-  - ./service-request-toga2-provisioning.md
+  - ../../../clients/elite/features/togadesk-service-request-intake.md
 ---
 
 ## Summary

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

@@ -23,7 +23,7 @@ related:
   - ../../worker/features/netsuite-togasupply-per-client-sync.md
   - ../architecture.md
   - ./error-capture-1-0.md
-  - ./service-request-toga2-provisioning.md
+  - ../../../clients/elite/features/togadesk-service-request-intake.md
 ---
 
 ## Summary
@@ -91,7 +91,8 @@ belong to the NetSuite importer — documented in the per-client-sync doc, not h
 > `->data->{resource}` sees an empty result and concludes **"the record does not exist"** — which,
 > for a duplicate check or a contact lookup, is exactly the wrong conclusion (it creates a second
 > record). Check `empty($response->isSuccess)` *first*, and keep "unknown" distinct from "absent".
-> See [App_Api_ServiceRequest](./service-request-toga2-provisioning.md) for the three bugs this
+> See [Elite Service Request intake](../../../clients/elite/features/togadesk-service-request-intake.md)
+> for the bugs this
 > caused and the `?bool` tri-state fix.
 
 > **`authenticate()` is also 1.0's ambient-client choke point for error reporting** (added
@@ -391,7 +392,8 @@ enable flags** and an optional `$monitorTogadeskDepartmentIds[]`:
   returns — including GETs — and a `$throwOnError = false` failure must never be read as "the record
   does not exist". Also recorded that naming `fields` on `GET /states` **suppresses** the nested
   country a plain request returns. Surfaced building
-  [App_Api_ServiceRequest](./service-request-toga2-provisioning.md) (TRUE-80497). (snaredla)
+  [App_Api_ServiceRequest](../../../clients/elite/features/togadesk-service-request-intake.md)
+  (TRUE-80497). (snaredla)
 - 2026-08-10 — TRUE-79401 re-synced with `_production` (`c64164fe`, pushed); the sole conflict was a
   positional const-block collision, resolved by keeping both sides. Patch intact; deploy still
   unverified. `STARTECH_TOGADESK_CLIENTS` (credential registry, add a row per client onboard) is

package/knowledge/1.0/apps/togadesk/workflows/standalone-test-scripts.md

@@ -52,7 +52,7 @@ web stack. Example harness: `C:\WWW\test\@Mark\TOGaDeskSupport\test_derive_custo
   harness then tests everything *after* the permission gate — it does **not** test the gate itself,
   so a permission regression will pass. Hit while harnessing
   `Ticket::createEliteServiceRequest()` (see the
-  [Elite desk Service Request feature](../../../clients/elite/features/desk-service-request-creation.md)).
+  [Elite desk Service Request feature](../../../clients/elite/features/togadesk-service-request-intake.md)).
 - **Lint/run with the right PHP.** Desk + library code targets **7.2**, and the default CLI on a dev
   box is 8.x — see the
   [7.2 verification procedure](../../test/features/static-no-db-regression-harness.md).

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

@@ -3,7 +3,7 @@
 | Doc | Summary | Files |
 |-----|---------|-------|
 | [API (api2 / TOGa API v2) Architecture](architecture.md) | `api2` is the backend powering the public **TOGa 2.0 API**. | api2/Controller/Index.php, api2/Component/Api/V2/V2.php, api2/Component/Api/Cxml/Cxml.php, api2/Component/Api/V2/Response/Response.php, api2/Config/ |
-| [API Payload Interceptors (metadata-registered prePost/postPut model hooks)](features/api-payload-interceptors.md) | A `_Model`'s `prePost()` / `postPost()` / `prePut()` / `postPut()` hooks are **not** called by the model. | api2/Component/Api/V2/V2.php, api2/Controller/Index.php, _underscore/Model/Client/ItemFulfillment.php, _underscore/Model/Elite/SalesOrder.php, _underscore/Model/Compass/SalesOrder.php, _underscore/Model/Compass/SalesOrderItem.php, dbchanges2/Core/2026-06-30a - ItemFulfillmentStageDefaultInterceptor.sql |
+| [API Payload Interceptors (metadata-registered prePost/postPut model hooks)](features/api-payload-interceptors.md) | A `_Model`'s `prePost()` / `postPost()` / `prePut()` / `postPut()` hooks are **not** called by the model. | api2/Component/Api/V2/V2.php, api2/Controller/Index.php, _underscore/Model/Client/ItemFulfillment.php, _underscore/Model/Elite/SalesOrder.php, _underscore/Model/Elite/ServiceRequest.php, _underscore/Model/Compass/SalesOrder.php, _underscore/Model/Compass/SalesOrderItem.php, dbchanges2/Core/2026-06-30a - ItemFulfillmentStageDefaultInterceptor.sql, dbchanges2/Core/2026-08-06a - Service request and sales order payload interceptors.sql |
 | [Multi-Client (Cross-Client) Data Retrieval](features/cross-client-data-retrieval.md) | A single authenticated V2 GET listing can return records across **many** clients (designed for 1000+) that the caller is entitled to, honoring **each target cli | api2/Component/Api/CrossClient/CrossClient.php, api2/Component/Api/V2/V2.php, api2/Controller/Index.php, _underscore/Model/Cache/Table.php, _underscore/Model/Cache/Tables/Client.php, _underscore/Model/Core/Record.php, worker2/Worker/Platform/Cache.php, worker2/Controller/Index.php, worker2/_.php, dbchanges2/Cache/2026-06-30a - MultiClientCacheTables.sql, dbchanges2/Core/2026-06-30b - CacheClusterRegistrationAndRecordTtl.sql, dbchanges2/Core/2026-07-27a - PlatformCacheCleanCron.sql |
 | [Encrypted-User-UUID Auth Handoff (/auth/encrypted-user-uuid)](features/encrypted-user-uuid-auth-handoff.md) | `POST /auth/encrypted-user-uuid` is the intended **cross-client / SSO-handoff identity mechanism**: given an encrypted `{client, user}` UUID pair, it mints a fr | api2/Component/Api/CrossClient/CrossClient.php |
 | [ENVIRONMENT (not the EB environment name) decides the _underscore branch and Config file](features/environment-variable-drives-underscore-branch.md) | An api2 Elastic Beanstalk instance decides **which `_underscore` branch it clones** and **which `Config/<env>.ini` it loads** from the EB environment property * | api2/.ebextensions/git.php, api2/.ebextensions/php_include_underscore.config, api2/.ebextensions/git.sandbox-dev.json, api2/Config/beta.ini, api2/Config/sandbox-dev.ini, api2/Component/Api/V2/V2.php |

package/knowledge/2.0/apps/api2/features/api-payload-interceptors.md

@@ -6,16 +6,18 @@ project: API
 client: shared
 type: feature
 status: active
-updated: 2026-08-11
-owners: ["mhammontree", "dfranks", "bala"]
+updated: 2026-08-12
+owners: ["mhammontree", "dfranks", "bala", "snaredla"]
 files:
   - api2/Component/Api/V2/V2.php
   - api2/Controller/Index.php
   - _underscore/Model/Client/ItemFulfillment.php
   - _underscore/Model/Elite/SalesOrder.php
+  - _underscore/Model/Elite/ServiceRequest.php
   - _underscore/Model/Compass/SalesOrder.php
   - _underscore/Model/Compass/SalesOrderItem.php
   - dbchanges2/Core/2026-06-30a - ItemFulfillmentStageDefaultInterceptor.sql
+  - dbchanges2/Core/2026-08-06a - Service request and sales order payload interceptors.sql
 related:
   - ./record-scripts.md
   - ../architecture.md
@@ -333,6 +335,12 @@ and the failing environment**. It is a small table, and the drift is usually exa
   change that switches on a *code* path; if the PHP defining the method is not confirmed deployed to
   that environment, the row takes the endpoint down. Insert inactive, verify the deploy, then flip
   `isActive = 1` — and remember every environment activates independently.
+- **⚠ A post interceptor's `$payload` is the record, not a route-keyed envelope** — and it is
+  by-reference, so pull the record into a local instead of reassigning `$payload`.
+- **⚠ Client behaviour never goes on `_Model_Client_X`.** Every tenant with a row for that record
+  inherits it through `parent::` calls. Put it on `_Model_<Client>_X`.
+- **A client's rows may be in `Core` (with `clientId`), not in `Client_<X>`** — check both before
+  concluding a client has no interceptors.
 - **The method name is derived, so a typo'd enum silently misses.** A row with
   `prePostProcessing = 'PRE'`, `httpMethod = 'PUT'` resolves to `prePut`, not `prePost`; the engine
   will simply find no method and move on.

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

@@ -235,7 +235,7 @@ queue failure cannot fail the originating write, so the user's record saves, not
 happens, and no error surfaces. Worked example: `GenerateSalesOrder` →
 `GenerateSalesOrderFromServiceRequest` spans `worker2/Worker/Sync/ServiceRequest.php` and the
 dispatch string in `_underscore/Model/Elite/ServiceRequest.php:44` — see the
-[Elite Service Request pipeline](../../../clients/elite/features/service-request-to-salesorder-pipeline.md).
+[Service Request → Sales Order generation](./service-request-sales-order-generation.md).
 
 Rules: rename **both sides in one PR and one deploy**; grep every repo for the old string (including
 `Core.CronJobs.action` and migrations) before merging; and treat it exactly like the

package/knowledge/2.0/apps/worker2/features/elite-freshservice-sync.md

@@ -139,9 +139,25 @@ To test worker2 Elite code locally against production TOGA 2 and Freshservice:
    require '_underscore.php';
    ```
 
-4. **PHP version** — worker2 vendor targets PHP >= 8.5. Local PHP 8.1 requires a
-   temporary bypass in `vendor/composer/platform_check.php` — revert before committing.
+4. **PHP version** — worker2's Composer install targets **PHP >= 8.5**, so on a local **8.1**
+   machine every script dies in `vendor/composer/platform_check.php` before any of your code runs.
+   **The flag-based escapes do not work here** — three were tried (the `--ignore-platform-req`
+   family and friends) and none of them stopped the runtime check, because the check is a
+   *generated file* that `autoload.php` requires unconditionally; the flags only affect
+   dependency *resolution* at install time.
+   The one thing that works is **temporarily neutralizing `vendor/composer/platform_check.php`**
+   and restoring it immediately afterwards. Two properties make that safe: the file is
+   **gitignored** (so it can never be committed by accident), and it is regenerated by any
+   `composer install`/`dump-autoload`. Still, wrap it so the restore is guaranteed even if the
+   script fails — a half-bypassed vendor tree is a confusing thing to come back to. Never leave it
+   neutralized, and never "fix" this by lowering the platform requirement.
 
 ## Change history
+- 2026-08-12 — Expanded the local-PHP-version note: on a PHP 8.1 machine the **flag-based
+  `--ignore-platform-req` escapes do not help**, because `platform_check.php` is a generated file
+  required unconditionally by `autoload.php` and the flags only affect install-time resolution.
+  The working approach is to temporarily neutralize `vendor/composer/platform_check.php` with a
+  **guaranteed restore** — safe because the file is gitignored and regenerated by any
+  `composer install`. (snaredla)
 - 2026-06-11 — Redacted Elite credential constants from the doc; secret scanner added to `validate`. (snaredla)
 - 2026-06-10 — Documented `_Worker_Elite` Freshservice → TOGA 2 webhook sync (conversation/attachment handling, TOGA 2 API gotchas, local dev setup). (snaredla)

package/knowledge/2.0/apps/worker2/features/service-request-sales-order-generation.md

@@ -139,6 +139,41 @@ have it. See the `c_`-column convention in `2.0/standards/framework-rules.md`.
 - **Placement:** cross-system sync workers live under `worker2/Worker/Sync/`. This worker does
   **not** belong in `Worker/Netsuite/` (which keeps the NetSuite push,
   `Worker/Netsuite/SalesOrder.php`) and not in `Worker/Client/`.
+- **⚠ Renaming this action is a TWO-REPO, single-deploy change.** The method name here and the
+  `runTask(action: 'Sync/ServiceRequest/GenerateSalesOrderFromServiceRequest', …)` **string** in
+  `_underscore/Model/Elite/ServiceRequest.php:44` must land and deploy **together** — the rename
+  from `GenerateSalesOrder` on 2026-08-12 spans both. Ship either alone and the dispatcher targets a
+  name that no longer exists; because `postPost` wraps `runTask` in try/catch + `error_log`, Sales
+  Order generation then stops **silently**. Same exposure for
+  `Sync/SalesOrderStatus/PostSalesOrderStatusToTogadesk1`. See
+  [creating worker actions](./creating-worker-actions.md).
+- **⚠ The copied client-context helper has already DRIFTED.** `getClientContextFromCore()` here,
+  the same private in `Worker/Sync/SalesOrderStatus.php`, and `getClientContext()` in
+  `Worker/Netsuite/SalesOrder.php` are three copies — and only **this** one has `ORDER BY id ASC` on
+  the `Apis` credential lookup, so the other two pick a **non-deterministic** API credential row
+  (`Worker/Netsuite/SalesOrder.php` documents the flaw in a comment). Add the `ORDER BY` to all
+  three if you touch any, and prefer extraction.
+- **The NetSuite actions in this chain are `Netsuite/SalesOrder/CreateNetSuite` and
+  `Netsuite/SalesOrder/UpdateNetSuite`.** There is **no** `Netsuite/SalesOrder/Push` — do not write
+  that string into a migration, a test or a doc.
+
+## Verifying the whole chain — `test_elite_chain_toga2.php`
+
+`test/@srija/Elite Testing/Service Requests/test_elite_chain_toga2.php` (PHP 8.1) exists because the
+interceptor layer is a **single point of silent failure**: the Service Request is created, nothing
+downstream happens, and no error is raised anywhere. It asserts, in order:
+
+1. **every queued action string resolves to a real `class::method`** (the rename hazard above);
+2. the `_underscore` models queue **those same strings**;
+3. `ApiPayloadInterceptors` rows exist for **record 35 (service-requests)** and **record 14
+   (sales-orders)** — and, critically, that each row's **derived** method name
+   (`strtolower(prePostProcessing) . ucfirst(strtolower(httpMethod))`) actually **exists on the
+   model**, because a registered row whose method is missing **500s every request on that route**;
+4. Sales Order / Purchase Order / NetSuite / desk-reply state after a run;
+5. a **repeat** status push, proving the dedupe guard holds.
+
+Those three structural checks (string resolves → producer matches → interceptor row + derived
+method exist) are reusable for any client on this chain.
 
 ## Known limitations — business blockers, not code defects
 
@@ -153,6 +188,15 @@ Recorded so nobody re-debugs them as bugs. All four were confirmed against Elite
 
 ## Change history
 
+- 2026-08-12 (later pass) — Recorded three deployment/verification facts: the action rename
+  `GenerateSalesOrder` → `GenerateSalesOrderFromServiceRequest` is a **two-repo, single-deploy**
+  change (the `runTask` string lives in `_underscore/Model/Elite/ServiceRequest.php:44`, and a
+  half-shipped rename stops Sales Order generation silently); the copied client-context helper has
+  **drifted** (`ORDER BY id ASC` on the `Apis` lookup exists only in this file, so the other two
+  copies pick a non-deterministic credential); and the chain is verified by
+  `test_elite_chain_toga2.php`, which checks that every queued action string resolves, producers
+  match, and each interceptor row's **derived** method name exists. Also noted the real NetSuite
+  action names (no `Netsuite/SalesOrder/Push`). (snaredla)
 - 2026-08-12 — TRUE-80497/80498: built `_Worker_Sync_ServiceRequest` — a tenant-agnostic
   `GenerateSalesOrderFromServiceRequest(clientIdentifier, serviceRequestId)` generalizing the
   Prudential 1.0 cron, with early return when a sales order already exists (idempotent under

package/knowledge/INDEX.md

@@ -4,11 +4,11 @@ _Auto-generated by `knowledge.js index`. Do not hand-edit._
 
 ## 1.0 framework
 
-- **library** (Library) _(framework core)_ — 18 doc(s) → [1.0/apps/library/INDEX.md](1.0/apps/library/INDEX.md)
+- **library** (Library) _(framework core)_ — 17 doc(s) → [1.0/apps/library/INDEX.md](1.0/apps/library/INDEX.md)
 - **worker** (Worker) — 21 doc(s) → [1.0/apps/worker/INDEX.md](1.0/apps/worker/INDEX.md)
 - **dbchanges** (Database Changes) _(framework core)_ — 1 doc(s) → [1.0/apps/dbchanges/INDEX.md](1.0/apps/dbchanges/INDEX.md)
 - **worker1.5** (Worker 1.5) — 0 doc(s) → [1.0/apps/worker1.5/INDEX.md](1.0/apps/worker1.5/INDEX.md)
-- **togadesk** (TOGa Desk) — 13 doc(s) → [1.0/apps/togadesk/INDEX.md](1.0/apps/togadesk/INDEX.md)
+- **togadesk** (TOGa Desk) — 12 doc(s) → [1.0/apps/togadesk/INDEX.md](1.0/apps/togadesk/INDEX.md)
 - **togaview** (TOGa View) — 7 doc(s) → [1.0/apps/togaview/INDEX.md](1.0/apps/togaview/INDEX.md)
 - **webhook** (Webhook) — 1 doc(s) → [1.0/apps/webhook/INDEX.md](1.0/apps/webhook/INDEX.md)
 - **walmarttechservices** (Walmart Tech Services) — 1 doc(s) → [1.0/apps/walmarttechservices/INDEX.md](1.0/apps/walmarttechservices/INDEX.md)
@@ -19,7 +19,7 @@ _Auto-generated by `knowledge.js index`. Do not hand-edit._
 ## 2.0 framework
 
 - **_underscore** (_Underscore) _(framework core)_ — 54 doc(s) → [2.0/apps/_underscore/INDEX.md](2.0/apps/_underscore/INDEX.md)
-- **worker2** (Worker) — 49 doc(s) → [2.0/apps/worker2/INDEX.md](2.0/apps/worker2/INDEX.md)
+- **worker2** (Worker) — 48 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) — 6 doc(s) → [2.0/apps/toga2-supply/INDEX.md](2.0/apps/toga2-supply/INDEX.md)

package/knowledge/clients/elite/INDEX.md

@@ -2,11 +2,9 @@
 
 | Doc | Framework | Summary | Files |
 |-----|-----------|---------|-------|
-| [Elite — \"New Service Request\" button on TOGa Desk 1.0 tickets](features/desk-service-request-creation.md) | 1.0 | TRUE-80497. | togadesk/desk/includes/controllers/modals/tickets/serviceRequest.php, togadesk/desk/includes/controllers/actions/tickets/serviceRequest.php, togadesk/desk/template/modals/tickets/serviceRequest.php, togadesk/desk/includes/classes/class.ticket.php, library/app/model/togadesk/ticket.php, library/app/api/servicerequest.php, dbchanges2/Client_Elite/2026-08-11a - EliteServiceRequestTicketUnique.sql, test/@srija/Elite Testing/Service Requests/test_elite_desk_service_request.php |
-| [Elite SalesOrder → NetSuite Push (postPost/postPut interceptors → worker2)](features/salesorder-netsuite-push.md) | 2.0 | Elite orders created in Toga are pushed into NetSuite **event-driven**, not on a cron. | _underscore/Model/Elite/SalesOrder.php, worker2/Worker/Netsuite/SalesOrder.php, dbchanges2/Client_Elite/2026-08-10 - SalesOrderNetsuiteInterceptors.sql |
+| [Elite SalesOrder → NetSuite Push (postPost/postPut interceptors → worker2)](features/salesorder-netsuite-push.md) | 2.0 | Elite orders created in Toga are pushed into NetSuite **event-driven**, not on a cron. | _underscore/Model/Elite/SalesOrder.php, _underscore/Model/Elite/ServiceRequest.php, worker2/Worker/Netsuite/SalesOrder.php, dbchanges2/Core/2026-08-06a - Service request and sales order payload interceptors.sql |
 | [Elite — Sales Order stage change posts a reply on the TOGa Desk (1.0) ticket](features/salesorder-status-togadesk-reply.md) | 2.0 | When an Elite sales order's **stage** changes, a reply is posted on the originating **TOGa Desk (1.0)** ticket so the requester sees progress where they raised | worker2/Worker/Sync/SalesOrderStatus.php, _underscore/Model/Elite/SalesOrderStatus.php, _underscore/Model/Elite/SalesOrder.php |
-| [Elite — Service Request → Sales Order → status back to TOGa Desk 1.0](features/service-request-to-salesorder-pipeline.md) | 2.0 | Once a Service Request exists in 2.0 (raised from [TOGa Desk](./desk-service-request-creation.md) or in supply2), an interceptor-driven chain turns it into a Sa | worker2/Worker/Sync/ServiceRequest.php, worker2/Worker/Sync/SalesOrderStatus.php, _underscore/Model/Elite/ServiceRequest.php, _underscore/Model/Elite/SalesOrder.php, test/@srija/Elite Testing/Service Requests/test_elite_chain_toga2.php |
 | [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/Orders/view/OrderView/viewModel/FIELDS/ELITE/BASEFIELDS.json, toga2-supply/src/pages/Orders/viewModel/FIELDS/ELITE/BASE.json, toga2-supply/src/pages/Inventory/viewModel/FIELDS/DUMMYGROUPOPTIONS.ts, toga2-supply/src/hooks/useFetchData.tsx, toga2-supply/src/components/ui/Toaster.tsx, 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 — raising a Service Request from a TOGa Desk ticket (App_Api_ServiceRequest)](features/togadesk-service-request-intake.md) | 1.0 | An Elite agent raises a **Service Request** from a TOGa Desk (1.0) ticket via a modal. | library/app/api/servicerequest.php, togadesk/desk/includes/classes/class.ticket.php, togadesk/desk/template/modals/tickets/serviceRequest.php, togadesk/desk/includes/controllers/modals/tickets/serviceRequest.php, togadesk/desk/includes/controllers/actions/tickets/serviceRequest.php, dbchanges2/Client_Elite/2026-08-11a - EliteServiceRequestTicketUnique.sql |
+| [Elite — raising a Service Request from a TOGa Desk ticket (App_Api_ServiceRequest)](features/togadesk-service-request-intake.md) | 1.0 | An Elite agent raises a **Service Request** from a TOGa Desk (1.0) ticket via a modal. | library/app/api/servicerequest.php, library/app/model/togadesk/ticket.php, togadesk/desk/includes/classes/class.ticket.php, togadesk/desk/template/modals/tickets/serviceRequest.php, togadesk/desk/includes/controllers/modals/tickets/serviceRequest.php, togadesk/desk/includes/controllers/actions/tickets/serviceRequest.php, dbchanges2/Client_Elite/2026-08-11a - EliteServiceRequestTicketUnique.sql, test/@srija/Elite Testing/Service Requests/test_elite_desk_service_request.php |
 | [Elite](profile.md) | 2.0 | Elite is a managed-services client that uses **Freshservice** as their helpdesk platform. | worker2/Worker/Elite.php, worker2/Worker/Sync/ServiceRequest.php, library/app/api/toga2.php, library/app/api/servicerequest.php, _underscore/Model/Elite/SalesOrder.php, _underscore/Model/Elite/ServiceRequest.php, togadesk/desk/includes/classes/class.ticket.php |

package/knowledge/clients/elite/features/salesorder-netsuite-push.md

@@ -6,16 +6,20 @@ project: _Underscore
 client: elite
 type: client-feature
 status: active
-updated: 2026-08-10
-owners: ["bala"]
+updated: 2026-08-12
+owners: ["bala", "snaredla"]
 files:
   - _underscore/Model/Elite/SalesOrder.php
+  - _underscore/Model/Elite/ServiceRequest.php
   - worker2/Worker/Netsuite/SalesOrder.php
-  - dbchanges2/Client_Elite/2026-08-10 - SalesOrderNetsuiteInterceptors.sql
+  - dbchanges2/Core/2026-08-06a - Service request and sales order payload interceptors.sql
 related:
   - ../../../2.0/apps/worker2/features/netsuite-salesorder-outbound-push.md
+  - ../../../2.0/apps/worker2/features/service-request-sales-order-generation.md
   - ../../../2.0/apps/api2/features/api-payload-interceptors.md
   - ../../../2.0/apps/_underscore/features/netsuite-rest-client.md
+  - ./salesorder-status-togadesk-reply.md
+  - ./togadesk-service-request-intake.md
   - ../profile.md
 ---
 
@@ -48,15 +52,51 @@ different shape — a CashSale built inline in `postPost`).
 5. `runTask` is wrapped in `try/catch` + `error_log`, so a broken queue can never fail the sales
    order POST itself.
 
+## `postPut` also drives the desk reply (2026-08-12)
+
+`postPut` now branches on **what was actually submitted** (`$api->httpPayload` holds only the fields
+sent):
+
+- **stage changed** (`salesOrderStageId` / `salesOrderStage`) → queues
+  `Sync/SalesOrderStatus/PostSalesOrderStatusToTogadesk1`, **first**, because it does not need the
+  NetSuite read-back. See [Sales Order stage → desk reply](./salesorder-status-togadesk-reply.md).
+- **shipping method changed** → the existing `Netsuite/SalesOrder/UpdateNetSuite` path, which also
+  bails when the order has no `c_netsuiteInternalSalesOrderId` (never sent, so nothing to update).
+
+Neither branch replaces the by-reference `$payload`; the record is read into a local, so a
+multi-record response is not truncated.
+
 ## Interceptor registration is per-environment DATA — and prod has none
 
 `Client_Elite.ApiPayloadInterceptors` is **EMPTY in production**. Without rows, `postPost`/`postPut`
-**never run**: the order saves, nothing else happens, and there is no error anywhere. The
-migration `dbchanges2/Client_Elite/2026-08-10 - SalesOrderNetsuiteInterceptors.sql` registers
-`POST`/`POST` and `POST`/`PUT` for **`recordId 14` (sales-orders)**, guarded with
-`WHERE NOT EXISTS` so a replay cannot create duplicates — **a duplicate row would queue the same
-NetSuite job twice for one order.** (Check the file carries dbchanges2's mandatory
-`YYYY-MM-DD<letter>` suffix before it merges.)
+**never run**: the order saves, nothing else happens, and there is no error anywhere.
+
+> **⚠ CORRECTION (2026-08-12): the registration migration moved.** It is no longer
+> `dbchanges2/Client_Elite/2026-08-10 - SalesOrderNetsuiteInterceptors.sql` (that file no longer
+> exists). The rows now land in **`Core.ApiPayloadInterceptors`** via
+> **`dbchanges2/Core/2026-08-06a - Service request and sales order payload interceptors.sql`**,
+> using the *one-client / all-APIs* form: `clientId 41` (Elite), **`apiId NULL`**, `isActive 1`,
+> `minDepth 1`. Three rows: **record 35 (`service-requests`) POST/POST**, **record 14
+> (`sales-orders`) POST/POST**, and **record 14 POST/PUT**.
+
+Every row is guarded with `WHERE NOT EXISTS` on `(clientId, recordId, prePostProcessing,
+httpMethod)` so a replay cannot create duplicates — **a duplicate row would queue the same NetSuite
+job twice for one order.**
+
+**The record 14 rows fire for EVERY Elite sales order**, not only ones that came from a service
+request — the migration says so explicitly. Any guard that should apply only to service-request
+orders has to live in the PHP.
+
+## Decision — the push lives on Elite models, never on `_Model_Client_SalesOrder`
+
+`_Model_Compass_SalesOrder` and `_Model_Quad_SalesOrder` both call `parent::postPost()`, and
+Compass has an **active `recordId 14` interceptor row**. So a NetSuite push placed on the shared
+`_Model_Client_SalesOrder` would have pushed **Compass and Quad** orders into NetSuite as a side
+effect. It is on `_Model_Elite_SalesOrder` / `_Model_Elite_ServiceRequest` for that reason.
+
+**Decision: no traits for per-client interceptor behaviour.** A small interceptor is added per
+client as each one needs it. A shared trait `use`d by several client models re-creates the same
+blast radius the client-model split exists to prevent, and hides it one level further down.
 
 `recordId 14` and the `Apis` ids (**1 = Agilant, 2 = Elite**) happen to match between dev-sandbox
 and production — **verify them per environment rather than assuming.**
@@ -107,6 +147,20 @@ precedent**. Treat the first prod Elite order as a real first run.
 
 ## Change history
 
+- 2026-08-12 — TRUE-80498/80501: **corrected the registration migration** — the
+  `Client_Elite/2026-08-10 - SalesOrderNetsuiteInterceptors.sql` file no longer exists; the rows now
+  land in **`Core.ApiPayloadInterceptors`** via
+  `Core/2026-08-06a - Service request and sales order payload interceptors.sql` in the
+  one-client/all-APIs form (`clientId 41`, `apiId NULL`, `minDepth 1`), covering **record 35
+  service-requests POST/POST** as well as record 14 POST/POST and POST/PUT, and noting that the
+  record 14 rows fire for **every** Elite sales order. Extended `postPut` to queue
+  `Sync/SalesOrderStatus/PostSalesOrderStatusToTogadesk1` on a **stage** change (ahead of the
+  NetSuite read-back it does not need), leaving the shipping-method branch as-is. Recorded the
+  **decision** that the push lives on `_Model_Elite_*` and never on the shared
+  `_Model_Client_SalesOrder` — Compass and Quad both call `parent::postPost()` and Compass has an
+  active record 14 row, so the shared model would have pushed their orders to NetSuite — and the
+  companion decision to add **a small interceptor per client rather than a shared trait**.
+  (snaredla)
 - 2026-08-10 — **Built the Elite push trigger**: `_Model_Elite_SalesOrder::postPost` queues
   `Netsuite/SalesOrder/CreateNetSuite`, `postPut` queues `UpdateNetSuite` on a shipping-method
   change; both call `parent::postPost()` first, bail when the payload carries

package/knowledge/clients/elite/features/togadesk-service-request-intake.md

@@ -10,17 +10,21 @@ updated: 2026-08-12
 owners: ["snaredla"]
 files:
   - library/app/api/servicerequest.php
+  - library/app/model/togadesk/ticket.php
   - togadesk/desk/includes/classes/class.ticket.php
   - togadesk/desk/template/modals/tickets/serviceRequest.php
   - togadesk/desk/includes/controllers/modals/tickets/serviceRequest.php
   - togadesk/desk/includes/controllers/actions/tickets/serviceRequest.php
   - dbchanges2/Client_Elite/2026-08-11a - EliteServiceRequestTicketUnique.sql
+  - test/@srija/Elite Testing/Service Requests/test_elite_desk_service_request.php
 related:
   - ../profile.md
   - ./salesorder-netsuite-push.md
   - ../../../2.0/apps/worker2/features/service-request-sales-order-generation.md
   - ../../../1.0/apps/library/features/toga2-api-client-and-bridge.md
   - ../../../1.0/apps/togadesk/features/ticket-lifecycle.md
+  - ../../../1.0/apps/togadesk/workflows/standalone-test-scripts.md
+  - ../../../1.0/apps/library/features/app-class-placement-base-contracts.md
 ---
 
 ## Summary
@@ -37,6 +41,26 @@ only the **desk gate** (is this an Elite service-request ticket?) and the **tick
 reporting**. Commit `e2b03fa7` moved ~235 lines out of `class.ticket.php` to get there — record the
 library file as the home; `class.ticket.php` is now the caller, not the implementation.
 
+## The button and its gate — three conditions, one helper
+
+On a qualifying ticket the **"New Service Request"** button **replaces** the existing **"New Part
+Request"** button; it is not an extra button, and every other Elite department keeps the parts flow.
+
+`App_Model_TogaDesk_Ticket::isEliteServiceRequestTicket(int $clientId, int $departmentId, ?string $ticketTypeValue): bool`
+(`library/app/model/togadesk/ticket.php`) is the single source of truth — `true` only when **all
+three** hold:
+
+| Condition | Constant |
+|---|---|
+| `tickets.clientid` = 163 (Elite) | `TOGADESK_CLIENT_ID__ELITE` |
+| `tickets.departmentid` = 299 (Elite Helpdesk - Contact Center) | `TOGADESK_DEPARTMENT_ID__ELITE_CONTACT_CENTER` |
+| custom field 88 "Ticket Type" = `Service Request` | `TOGADESK_CUSTOM_FIELD_ID__ELITE_TICKET_TYPE` + `ELITE_TICKET_TYPE__SERVICE_REQUEST` |
+
+The template, the modal controller **and** `Ticket::createEliteServiceRequest()` all call the helper
+rather than repeating the three ids — re-checked server-side, because a hidden button is not a
+security control. The ticket's 2.0 uuid comes from **`tickets.referenceId`**; without one the modal
+cannot proceed.
+
 ## How it works
 
 1. The modal (`desk/template/modals/tickets/serviceRequest.php`) collects the requested-for person,
@@ -51,7 +75,23 @@ library file as the home; `class.ticket.php` is now the caller, not the implemen
 5. `App_Api_ServiceRequest::createServiceRequestInToga2(...)` posts the **parent and its units in
    one request**. Related records resolve by **natural key** (type name, part number, email) —
    only the customer is referenced by uuid.
-6. The desk writes a `Service Request created <number>` history entry with the unit count.
+6. The desk writes a `Service Request created <number>` history entry with the unit count, and adds
+   a reply authored by `ELITE_DEFAULT_AGENT = 35876` (Agilant Helpdesk / serviceops@togatech.com —
+   the author of the other machine-written replies on Elite tickets). The reply passes the ticket's
+   **current** status as `newStatus`, so raising a Service Request does not silently move the ticket
+   to *In Progress*.
+
+## Statuscodes: 1705 = success, 11 = failure
+
+`Ticket::ELITE_SERVICE_REQUEST_STATUS__SUCCESS = 1705` is Elite's own success message row;
+`ELITE_SERVICE_REQUEST_STATUS__FAILURE = 11` is the generic "cannot add item" failure, with the
+detail written to the ticket history. **Two paths return 1705 without creating anything, and both
+are deliberate:**
+
+- the **duplicate guard** — the desired end state (one Service Request on this ticket) already
+  holds, so a second submit is duplicate-safe SUCCESS, not an error;
+- a **create that succeeded but whose reply write failed** — `addReply()` is wrapped in try/catch
+  and the exception is swallowed, so a reply failure can never report a successful create as failed.
 
 ## The duplicate guard must filter IN the query
 
@@ -114,8 +154,43 @@ wrong-country address.
 select2 state list kept emptying the dropdown — the file's own comment records this. The
 server-side pair check is the guard; the modal stays as-is.
 
+## Test harness
+
+`test/@srija/Elite Testing/Service Requests/test_elite_desk_service_request.php` (PHP **7.2**)
+exercises the desk half from the CLI — a path that had **never been executed** before 2026-08-12:
+the button gate, `referenceId` resolution, the six modal lookups, the duplicate guard, and under
+`--run` a real create with history/reply verification.
+
+**It cannot test the permission gate.** `createEliteServiceRequest()` calls `isOwner()`, which reads
+the `$isAdmin` / `$liu` globals and **redirects + exits** when they are absent; the harness seeds
+them, so it proves everything *after* the permission check, not the check itself. See
+[standalone test-script bootstrap](../../../1.0/apps/togadesk/workflows/standalone-test-scripts.md)
+— and note that verifying 7.2 compatibility needs a real 7.2 binary, since the default CLI is 8.x
+([procedure](../../../1.0/apps/test/features/static-no-db-regression-harness.md)).
+
 ## Gotchas / known issues
 
+- **⚠ The endpoint is hardcoded to PRODUCTION, in TWO constants that must stay in sync.**
+  `Ticket::ELITE_SERVICE_REQUEST_CREATE_ENDPOINT` (`class.ticket.php`) and
+  `ELITE_SERVICE_REQUEST_LOOKUP_ENDPOINT` (the modal controller) are both
+  `https://api.togahub.com/v2`. They **must** match: the modal reads customer / state / item uuids
+  from the lookup endpoint and the create posts those same uuids, and **a uuid from one environment
+  does not exist in another**. Consequence, deliberate but sharp: **every environment
+  (alpha/beta/stage) writes Service Requests into production.** Change one constant and you must
+  change the other in the same commit.
+- **⚠ A failed contact lookup used to create a DUPLICATE contact in 2.0.**
+  `findContactUuidByEmailAddress()` returned `null` on an API failure, which the caller read as "no
+  such contact" and created one — for someone 2.0 already held. Same root cause as the duplicate-SR
+  bug above: with throwing off, a failure arrives as a *response*. `empty($response->isSuccess)` is
+  a safe check on **anything** `App_Api_Toga2::send()` returns, GETs included — see
+  [the transport doc](../../../1.0/apps/library/features/toga2-api-client-and-bridge.md).
+- **`States.countryId` has `isIdentifier = 0`**, so a nested country cannot disambiguate a state
+  either — the state **uuid** is the only country-safe handle when posting.
+- **A 2.0 list route returns an array; a single-record response returns a bare object.** The modal
+  controller normalises this — new lookups must do the same or they break on the one-result case.
+- **`App_Api_ServiceRequest` extends nothing, deliberately.** In `library/app/`, the folder is a
+  behavioural contract and `App_Api` is the fulfilment-vendor base — see
+  [where a new App_ class goes](../../../1.0/apps/library/features/app-class-placement-base-contracts.md).
 - **⚠ Do not re-implement this in `class.ticket.php`.** After `e2b03fa7` that file holds the desk
   gate and history reporting only. New validation or payload work belongs in
   `library/app/api/servicerequest.php`.
@@ -129,6 +204,16 @@ server-side pair check is the guard; the modal stays as-is.
 
 ## Change history
 
+- 2026-08-12 (later pass) — Recorded the **button gate** itself
+  (`isEliteServiceRequestTicket()`: client 163 + department 299 + custom field 88 = `Service
+  Request`; the button **replaces** "New Part Request" on those tickets, and the 2.0 uuid comes from
+  `tickets.referenceId`), the **statuscode semantics** (1705 success / 11 failure, with both the
+  duplicate guard and a swallowed reply failure returning 1705), the reply author
+  `ELITE_DEFAULT_AGENT = 35876` and its status-preserving `newStatus`, the ⚠ **hardcoded production
+  endpoint pair** that makes every environment write to production, the **duplicate-contact** bug
+  from reading past a failed lookup (`empty($response->isSuccess)` is the safe check on anything
+  `send()` returns), `States.countryId isIdentifier = 0`, and the PHP 7.2 desk harness plus its
+  `isOwner()` limitation. (snaredla)
 - 2026-08-12 — TRUE-80497: moved the Elite service-request intake out of
   `togadesk` `class.ticket.php` into `library/app/api/servicerequest.php`
   (`App_Api_ServiceRequest`, commit `e2b03fa7`, ~235 lines); `class.ticket.php` keeps only the desk

package/knowledge/clients/elite/profile.md

@@ -30,8 +30,9 @@ related:
   - features/supply2-scope.md
   - features/supply2-tableview-config-drift.md
   - features/salesorder-netsuite-push.md
-  - features/desk-service-request-creation.md
-  - features/service-request-to-salesorder-pipeline.md
+  - features/togadesk-service-request-intake.md
+  - features/salesorder-status-togadesk-reply.md
+  - 2.0/apps/worker2/features/service-request-sales-order-generation.md
 ---
 
 ## Summary
@@ -60,19 +61,20 @@ renders a designed "no order details" empty state (see supply2-scope).
 Center tickets (client 163 / department 299 / Ticket Type = *Service Request*) show a **New Service
 Request** button that replaces *New Part Request* and creates the Service Request in TOGa 2.0 via
 the shared `App_Api_ServiceRequest` — see
-[desk-service-request-creation](features/desk-service-request-creation.md). The 2.0 side then
+[togadesk-service-request-intake](features/togadesk-service-request-intake.md). The 2.0 side then
 generates a Sales Order and posts the order status back onto the desk ticket —
-[service-request-to-salesorder-pipeline](features/service-request-to-salesorder-pipeline.md). This
+[service-request-sales-order-generation](../../2.0/apps/worker2/features/service-request-sales-order-generation.md). This
 adds **`togadesk`** (and **`test`**, for the two CLI harnesses) to Elite's app scope. **One Service
 Request per ticket** is enforced by a UNIQUE index on `ServiceRequests.ticketId`
 (`dbchanges2/Client_Elite/2026-08-11a`) — applied on dev-sandbox, **not yet in production** —
 and the desk endpoints are currently **hardcoded to production**, so every environment writes there.
 
 **Elite orders are pushed to NetSuite event-driven (2026-08).** `_Model_Elite_SalesOrder`'s
-`postPost`/`postPut` interceptors queue the shared worker2 push. Elite's
-`ApiPayloadInterceptors` table is **empty in production**, so the registration migration is the
-go-live gate — see [salesorder-netsuite-push](features/salesorder-netsuite-push.md). This work adds
-**`_underscore`** and **`api2`** to Elite's app scope.
+`postPost`/`postPut` interceptors queue the shared worker2 push. `Client_Elite.ApiPayloadInterceptors`
+is **empty in production**; the registration rows now live in **`Core.ApiPayloadInterceptors`**
+(`dbchanges2/Core/2026-08-06a`, `clientId 41` / `apiId NULL`, records 35 and 14) and landing them is
+the go-live gate — see [salesorder-netsuite-push](features/salesorder-netsuite-push.md). This work
+adds **`_underscore`** and **`api2`** to Elite's app 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

package/package.json

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

package/knowledge/1.0/apps/library/features/service-request-toga2-provisioning.md

@@ -1,135 +0,0 @@
----
-title: App_Api_ServiceRequest — provisioning a TOGa 2.0 Service Request from 1.0
-framework: "1.0"
-repo: library
-project: Library
-client: shared
-type: feature
-status: active
-updated: 2026-08-12
-owners: [snaredla]
-files:
-  - library/app/api/servicerequest.php
-  - library/app/api/toga2.php
-  - togadesk/desk/includes/classes/class.ticket.php
-related:
-  - ./toga2-api-client-and-bridge.md
-  - ./app-class-placement-base-contracts.md
-  - ../../../clients/elite/features/desk-service-request-creation.md
----
-
-## Summary
-
-`App_Api_ServiceRequest` (`library/app/api/servicerequest.php`) is the shared 1.0-side class that
-turns a posted form into a **TOGa 2.0 Service Request** — it validates and normalises the posted
-values, resolves the related 2.0 records it needs, refuses a duplicate, and POSTs the Service
-Request with its nested units in a single request. All transport goes through
-[`App_Api_Toga2::send()`](./toga2-api-client-and-bridge.md); this class holds no 1.0 table and does
-no SQL.
-
-First consumer is the Elite "New Service Request" button in TOGa Desk (see
-[Elite desk Service Request creation](../../../clients/elite/features/desk-service-request-creation.md)),
-but the class itself is client-agnostic — the caller passes the API endpoint in.
-
-## Key files / entry points
-
-`abstract class App_Api_ServiceRequest` — public:
-
-- `buildFromPostedValues(array $postedValues, string $ticketUuid, ?string $overrideWithApiEndpoint = null): array`
-  — validates + normalises the modal post into the 2.0 payload array (throws on a validation
-  failure; the caller converts that into the UI message).
-- `searchTicketFromToga2(string $ticketUuid, ?string $overrideWithApiEndpoint = null)` — the
-  **duplicate guard**: does a Service Request already exist for this ticket?
-- `createServiceRequestInToga2(array $serviceRequest, ?string $overrideWithApiEndpoint = null)` —
-  the POST (parent + nested units).
-- `describeApiFailureMessage($response): string` — turns a 2.0 failure response into an
-  agent-readable message.
-
-Private: `isStateInCountry()`, `findContactUuidByEmailAddress()`, `cleanPostedValue()`.
-
-## How it works
-
-1. **Build** — `buildFromPostedValues()` trims/length-caps every posted value
-   (`cleanPostedValue()`), resolves the requester contact by email, checks the selected state
-   really belongs to the selected country, and assembles the parent payload plus one nested
-   `serviceRequestUnits` entry per line.
-2. **Duplicate guard** — `searchTicketFromToga2()` looks the ticket uuid up in 2.0 before creating
-   anything.
-3. **Create** — `createServiceRequestInToga2()` POSTs **parent + nested `serviceRequestUnits` in
-   ONE request**. Related records inside that payload resolve by **natural key** — the request type
-   by *name*, the item by *partNumber* — while **customer, state and ticket are matched by uuid**.
-4. The caller (TOGa Desk) maps the outcome to its own status code and writes the ticket
-   history/reply.
-
-## The failure-check contract — `empty($response->isSuccess)` is always safe
-
-This is the load-bearing fact behind three bugs fixed on 2026-08-12, and it is not obvious from the
-call site.
-
-`App_Api_Toga2::send()` (`library/app/api/toga2.php`, ~L432–450) **always returns a response object
-that carries `isSuccess`**:
-
-- it returns early **only** when `isSuccess` is true;
-- when `isSuccess` is false and `$throwExceptionOnApiError = false`, it falls through the retry loop
-  and ends at `return $response` — **a failure arrives as a return value, not an exception**;
-- if the response is not an object, or lacks the `isSuccess` property at all, it **throws**.
-
-Therefore anything `send()` hands back can be checked with `empty($response->isSuccess)` — including
-GETs. There is no "successful response without the property" case to defend against.
-
-**The bug class this prevents:** every helper here calls `send()` with
-`$throwExceptionOnApiError = false`, so a network blip, an auth failure or a 500 comes back as a
-*response*. Code that reads straight past it to `$response->data->{resource}` sees "no records" and
-concludes **"the thing does not exist"** — the most dangerous possible misreading for a lookup.
-
-## Fixed 2026-08-12 — three silent failures, one root cause
-
-| Lookup | Old behavior on API failure | Consequence |
-|---|---|---|
-| duplicate Service Request | returned `null` | read as "no duplicate exists" → **a second Service Request on a ticket that already had one** |
-| contact by email | returned `null` | read as "no contact exists" → **a duplicate contact created in 2.0** for someone 2.0 already held |
-| state-belongs-to-country | returned `false` | a blip told the agent *"the selected state does not belong to the selected country"* — a **false accusation of bad input** |
-
-`isStateInCountry()` now returns **`?bool` as a tri-state**: `true` confirmed, `false` a genuine
-mismatch, **`null` unconfirmed** (exception or empty result). The submission is refused in both the
-`false` and `null` cases — the difference is the **message**: only `false` blames the input, `null`
-says the check could not be completed. Do not collapse this back into a `bool`.
-
-## 2.0 API rules this class had to learn the hard way
-
-- **Naming `fields` on `GET /states` SUPPRESSES the nested country.** A plain request returns the
-  nested `country`; adding a `fields` list drops it. If a nested relation vanishes, suspect the
-  field list before suspecting the data.
-- **Post a state by UUID, never by code.** `WA` and `NT` each belong to **two** countries, and the
-  API matches on code alone. `States.countryId` has `isIdentifier = 0`, so the nested country cannot
-  disambiguate it either — the uuid is the only unambiguous handle.
-- **Natural-key resolution inside a nested write:** type by name, item by partNumber. Only
-  customer / state / ticket go by uuid.
-
-## Gotchas / known issues
-
-- **A uuid is environment-scoped.** Any flow that reads uuids from one 2.0 environment and posts
-  them to another will fail or, worse, resolve to a different record. Read and write against the
-  **same** endpoint — see the hardcoded-endpoint gotcha in the
-  [Elite desk feature](../../../clients/elite/features/desk-service-request-creation.md).
-- **This class extends nothing, deliberately.** Extending `App_Api` silently inherits the 1.0
-  fulfilment-vendor contract. See
-  [where a new App_ class goes](./app-class-placement-base-contracts.md).
-- **Credentials.** Elite's `CLIENT_UUID_ELITE` / `API_UUID_ELITE` / `API_SECRET_ELITE` are class
-  constants on `App_Api_Toga2` (`library/app/api/toga2.php`). Read them from source; never
-  reproduce the values. An API secret living in a git-tracked constant is a standing concern — see
-  the credentials gotcha on [the transport doc](./toga2-api-client-and-bridge.md).
-
-## Change history
-
-- 2026-08-12 — TRUE-80497: created `App_Api_ServiceRequest` as the shared 1.0→2.0 Service Request
-  provisioner. Recorded the `send()` failure contract (**`empty($response->isSuccess)` is always a
-  safe check, including on GETs**) and fixed **three** silent failures that all came from reading
-  past a failure response returned under `$throwExceptionOnApiError = false`: the duplicate-SR
-  lookup and the contact lookup both reported "does not exist" (allowing a second SR and a
-  duplicate contact), and the state/country check reported a genuine mismatch for an exception or
-  empty result. `isStateInCountry()` now returns `?bool` — `null` = unconfirmed, with its own
-  message; both `null` and `false` still refuse. Also recorded the 2.0 rules: `fields` on
-  `GET /states` suppresses the nested country; states must be posted by uuid (`WA`/`NT` are
-  ambiguous across countries and `States.countryId` has `isIdentifier = 0`); parent + nested
-  `serviceRequestUnits` post in one request with type/item resolved by natural key. (snaredla)

package/knowledge/clients/elite/features/desk-service-request-creation.md

@@ -1,136 +0,0 @@
----
-title: "Elite — \"New Service Request\" button on TOGa Desk 1.0 tickets"
-framework: "1.0"
-repo: togadesk
-project: TOGa Desk
-client: elite
-type: client-feature
-status: active
-updated: 2026-08-12
-owners: [snaredla]
-files:
-  - togadesk/desk/includes/controllers/modals/tickets/serviceRequest.php
-  - togadesk/desk/includes/controllers/actions/tickets/serviceRequest.php
-  - togadesk/desk/template/modals/tickets/serviceRequest.php
-  - togadesk/desk/includes/classes/class.ticket.php
-  - library/app/model/togadesk/ticket.php
-  - library/app/api/servicerequest.php
-  - dbchanges2/Client_Elite/2026-08-11a - EliteServiceRequestTicketUnique.sql
-  - test/@srija/Elite Testing/Service Requests/test_elite_desk_service_request.php
-related:
-  - ../../../1.0/apps/library/features/service-request-toga2-provisioning.md
-  - ../../../1.0/apps/togadesk/features/ticket-lifecycle.md
-  - ../../../1.0/apps/togadesk/workflows/standalone-test-scripts.md
-  - ./service-request-to-salesorder-pipeline.md
-  - ../profile.md
----
-
-## Summary
-
-TRUE-80497. Elite agents used to raise Service Requests **by hand, outside the desk**. A ticket that
-qualifies now shows a **"New Service Request"** button that opens a modal and creates the Service
-Request directly in **TOGa 2.0**, writing the resulting number back to the ticket history and as a
-reply.
-
-On a qualifying ticket the button **replaces** the existing **"New Part Request"** button — it is
-not an extra button. Every other Elite department keeps the parts flow untouched.
-
-## The gate — three conditions, one helper
-
-`App_Model_TogaDesk_Ticket::isEliteServiceRequestTicket(int $clientId, int $departmentId, ?string $ticketTypeValue): bool`
-(`library/app/model/togadesk/ticket.php`) is the single source of truth. It is `true` only when
-**all three** hold:
-
-| Condition | Constant |
-|---|---|
-| `tickets.clientid` = 163 (Elite) | `TOGADESK_CLIENT_ID__ELITE` |
-| `tickets.departmentid` = 299 (Elite Helpdesk – Contact Center) | `TOGADESK_DEPARTMENT_ID__ELITE_CONTACT_CENTER` |
-| custom field 88 "Ticket Type" = `Service Request` | `TOGADESK_CUSTOM_FIELD_ID__ELITE_TICKET_TYPE` + `ELITE_TICKET_TYPE__SERVICE_REQUEST` |
-
-The template, the modal controller **and** `Ticket::createEliteServiceRequest()` all call the same
-helper rather than repeating the three ids — re-checked server-side because the button being hidden
-is not a security control.
-
-## How it works
-
-1. **Modal controller** (`controllers/modals/tickets/serviceRequest.php`) re-checks the gate,
-   resolves the ticket's 2.0 uuid from `tickets.referenceId`, then runs its lookups against 2.0
-   (customer/contact, states, countries, request types, items, existing Service Request) and
-   renders `template/modals/tickets/serviceRequest.php`.
-2. **Action controller** (`controllers/actions/tickets/serviceRequest.php`) is a thin shim: it calls
-   `Ticket::createEliteServiceRequest($_POST)` and reroutes on the returned statuscode.
-3. **`Ticket::createEliteServiceRequest()`** (`class.ticket.php`) owns the desk half only — gate,
-   ticket lookup, history and reply. Validation, duplicate detection and the API calls belong to
-   [`App_Api_ServiceRequest`](../../../1.0/apps/library/features/service-request-toga2-provisioning.md).
-4. On success it writes a `TicketHistory` line (`Service Request created <number> (<type>, N units)`)
-   and adds a reply authored by `ELITE_DEFAULT_AGENT = 35876` (Agilant Helpdesk /
-   serviceops@togatech.com — the same author as the other machine-written replies on Elite tickets).
-   The reply passes the ticket's **current** status as `newStatus`, so creating a Service Request
-   does not silently move the ticket to *In Progress*.
-
-## Statuscodes: 1705 = success, 11 = failure
-
-`ELITE_SERVICE_REQUEST_STATUS__SUCCESS = 1705` is Elite's own success message row;
-`ELITE_SERVICE_REQUEST_STATUS__FAILURE = 11` is the generic "cannot add item" failure, with the
-detail written to the ticket history.
-
-**Two paths return 1705 without creating anything, and both are correct:**
-
-- the **duplicate guard** — a Service Request already exists for this ticket, so the desired end
-  state is already true. A second submit is a **duplicate-safe SUCCESS**, not an error.
-- a **create that succeeded but whose reply write failed** — the `addReply()` call is wrapped in
-  try/catch and the exception is deliberately swallowed, so a reply failure can never report a
-  successful create as a failure.
-
-## One Service Request per ticket (Elite only)
-
-Decided 2026-08-11. The application-level duplicate guard is not sufficient on its own — two
-simultaneous submissions can both pass it — so the rule is enforced in the database by a **UNIQUE
-index on `ServiceRequests.ticketId`**:
-`dbchanges2/Client_Elite/2026-08-11a - EliteServiceRequestTicketUnique.sql`.
-
-- Applied to **dev-sandbox**; **NOT yet applied to production**.
-- **Elite-only.** Other clients may legitimately raise more than one Service Request per ticket —
-  do not promote this index to a shared/Core migration.
-
-## Gotchas / known issues
-
-- **⚠ The endpoint is hardcoded to PRODUCTION, in TWO constants that must stay in sync.**
-  `Ticket::ELITE_SERVICE_REQUEST_CREATE_ENDPOINT` (`class.ticket.php`) and
-  `ELITE_SERVICE_REQUEST_LOOKUP_ENDPOINT` (the modal controller) are both
-  `https://api.togahub.com/v2`. They **must** match: the modal reads customer / state / item uuids
-  from the lookup endpoint and the create posts those same uuids, and **a uuid from one environment
-  does not exist in another**. The consequence is deliberate but sharp — **every environment
-  (alpha/beta/stage) writes Service Requests into production.** Change one constant and you must
-  change the other in the same commit.
-- **A 2.0 list route returns an array; a single-record response returns a bare object.** The modal
-  controller normalises this (wraps the object) — new lookups must do the same or they break on the
-  one-result case.
-- **`tickets.referenceId` is the bridge to 2.0.** No `referenceId` ⇒ no 2.0 ticket uuid ⇒ the modal
-  cannot proceed.
-- **The desk half had never been executed before 2026-08-12.** See the harness below.
-
-## Test harness
-
-`test/@srija/Elite Testing/Service Requests/test_elite_desk_service_request.php` (PHP **7.2**)
-exercises the desk half from the CLI: the button gate, `referenceId` resolution, the six modal
-lookups, the duplicate guard, and — under `--run` — a real create with history/reply verification.
-
-**It cannot test the permission gate.** `createEliteServiceRequest()` calls `isOwner()`, which reads
-the `$isAdmin` / `$liu` globals and **redirects + exits** when they are absent; the harness seeds
-them, so everything it proves is *after* the permission check. See
-[standalone test-script bootstrap](../../../1.0/apps/togadesk/workflows/standalone-test-scripts.md).
-
-## Change history
-
-- 2026-08-12 — TRUE-80497: built the Elite "New Service Request" button, modal, action and
-  `Ticket::createEliteServiceRequest()`, gated by
-  `App_Model_TogaDesk_Ticket::isEliteServiceRequestTicket()` (client 163 + department 299 + custom
-  field 88 = `Service Request`) and **replacing** the "New Part Request" button on those tickets.
-  Recorded the statuscode semantics (1705 success / 11 failure, with the duplicate guard and a
-  swallowed reply failure both returning 1705), the **one-Service-Request-per-ticket** rule enforced
-  by a UNIQUE index on `ServiceRequests.ticketId`
-  (`dbchanges2/Client_Elite/2026-08-11a`, dev-sandbox only — **not yet in production**), and the
-  ⚠ hardcoded production endpoint pair that makes every environment write to production. Added the
-  PHP 7.2 desk harness (`test/@srija/…/test_elite_desk_service_request.php`) for a path that had
-  never been executed. (snaredla)

package/knowledge/clients/elite/features/service-request-to-salesorder-pipeline.md

@@ -1,109 +0,0 @@
----
-title: "Elite — Service Request → Sales Order → status back to TOGa Desk 1.0"
-framework: "2.0"
-repo: worker2
-project: Worker
-client: elite
-type: client-feature
-status: active
-updated: 2026-08-12
-owners: [snaredla]
-files:
-  - worker2/Worker/Sync/ServiceRequest.php
-  - worker2/Worker/Sync/SalesOrderStatus.php
-  - _underscore/Model/Elite/ServiceRequest.php
-  - _underscore/Model/Elite/SalesOrder.php
-  - test/@srija/Elite Testing/Service Requests/test_elite_chain_toga2.php
-related:
-  - ./salesorder-netsuite-push.md
-  - ./desk-service-request-creation.md
-  - ../../../2.0/apps/api2/features/api-payload-interceptors.md
-  - ../../../2.0/apps/worker2/features/creating-worker-actions.md
-  - ../../../2.0/apps/worker2/features/netsuite-salesorder-outbound-push.md
-  - ../profile.md
----
-
-## Summary
-
-Once a Service Request exists in 2.0 (raised from
-[TOGa Desk](./desk-service-request-creation.md) or in supply2), an interceptor-driven chain turns it
-into a Sales Order and reports the order's status back to the 1.0 desk ticket:
-
-1. `_Model_Elite_ServiceRequest::postPost` queues
-   **`Sync/ServiceRequest/GenerateSalesOrderFromServiceRequest`** (worker2).
-2. That action generates the Sales Order (and, where vendors are resolvable, purchase orders),
-   moving the Service Request to the **Exception** stage when it cannot.
-3. `_Model_Elite_SalesOrder` queues the NetSuite push — a separate feature, see
-   [SalesOrder → NetSuite push](./salesorder-netsuite-push.md).
-4. **`Sync/SalesOrderStatus/PostSalesOrderStatusToTogadesk1`** writes the order status back as a
-   reply on the originating 1.0 desk ticket, with a dedupe guard so a repeated push does not
-   double-post.
-
-Every hop is registered data (`ApiPayloadInterceptors`) plus a queued action **string** — which is
-where the two durable hazards below come from.
-
-## ⚠ Renaming a worker action is a TWO-REPO, single-deploy change
-
-The 2026-08-12 rename `GenerateSalesOrder` → `GenerateSalesOrderFromServiceRequest` touches:
-
-- the **method** — `worker2/Worker/Sync/ServiceRequest.php`
-- the **dispatch string** — `\_Worker::runTask(action: 'Sync/ServiceRequest/GenerateSalesOrderFromServiceRequest', …)`
-  in `_underscore/Model/Elite/ServiceRequest.php:44`
-
-**They must land and deploy together.** If either ships alone, `runTask` dispatches to a name that
-no longer exists and **Sales Order generation stops silently** — `postPost` wraps `runTask` in
-try/catch + `error_log`, so the Service Request saves and nothing else happens, with no user-visible
-error. The same coupling applies to `Sync/SalesOrderStatus/PostSalesOrderStatusToTogadesk1`.
-
-Treat an action name like a database column rename: see the multi-producer rename rule in
-[creating worker actions](../../../2.0/apps/worker2/features/creating-worker-actions.md).
-
-## The NetSuite actions in this chain
-
-`Netsuite/SalesOrder/CreateNetSuite` (new order) and `Netsuite/SalesOrder/UpdateNetSuite` (changed
-order) are the real queued actions. **There is no `Netsuite/SalesOrder/Push`** — do not write that
-string into a migration, a test or a doc.
-
-## Verifying the chain — `test_elite_chain_toga2.php`
-
-`test/@srija/Elite Testing/Service Requests/test_elite_chain_toga2.php` (PHP 8.1) exists because the
-interceptor layer is a **single point of silent failure**: the Service Request is created, nothing
-downstream happens, and no error is raised anywhere. It asserts, in order:
-
-1. **every queued action string resolves to a real `class::method`** (the rename hazard above);
-2. the `_underscore` models queue **those same strings**;
-3. `ApiPayloadInterceptors` rows exist for **record 35 (service-requests)** and **record 14
-   (sales-orders)**, and — critically — that each row's **derived** method name
-   (`strtolower(prePostProcessing) . ucfirst(strtolower(httpMethod))`) actually **exists on the
-   model**. A registered row whose derived method is missing **500s every request on that route**;
-4. Sales Order / Purchase Order / NetSuite / desk-reply state after a run;
-5. a **repeat** status push, to prove the dedupe guard holds.
-
-Reusable beyond Elite — the same three checks (string resolves, producer matches, interceptor row +
-derived method exist) catch the entire silent-failure class. Background on the mechanism:
-[API payload interceptors](../../../2.0/apps/api2/features/api-payload-interceptors.md).
-
-## Gotchas / known issues
-
-- **Duplicated client-context helper, already drifted.** `getClientContextFromCore()` exists in both
-  `Worker/Sync/ServiceRequest.php` and `Worker/Sync/SalesOrderStatus.php`, and as
-  `getClientContext()` in `Worker/Netsuite/SalesOrder.php`. Only the **ServiceRequest** copy has
-  `ORDER BY id ASC` on the `Apis` credential query — the other two pick a **non-deterministic API
-  credential row** (Netsuite/SalesOrder.php even documents the flaw in a comment). **Not yet
-  extracted**; recorded as a known issue, see the
-  [outbound push doc](../../../2.0/apps/worker2/features/netsuite-salesorder-outbound-push.md).
-- **The interceptor registration is per-environment DATA.** "It didn't fire in <env>" is a `SELECT`
-  on that client's `ApiPayloadInterceptors`, never a code question.
-
-## Change history
-
-- 2026-08-12 — TRUE-80497/80501: documented the Elite Service Request → Sales Order → desk-status
-  chain. Recorded the **two-repo rename constraint** (the worker method in
-  `worker2/Worker/Sync/ServiceRequest.php` and the `runTask` dispatch string in
-  `_underscore/Model/Elite/ServiceRequest.php:44` must deploy together or Sales Order generation
-  stops silently), that the real NetSuite actions are `CreateNetSuite`/`UpdateNetSuite` (**no
-  `Push`**), and the drifted duplicate client-context helper (`ORDER BY id ASC` present in only one
-  of three copies → non-deterministic API credential). Added the PHP 8.1 chain harness
-  `test_elite_chain_toga2.php`, which verifies action strings resolve, producers match, and each
-  interceptor row's **derived** method name exists (a missing one 500s every request on the route).
-  (snaredla)