toga-ai 1.0.1087 → 1.0.1089

package/knowledge/1.0/apps/api/features/talos-ticket-endpoint.md

@@ -6,7 +6,7 @@ project: API 1.0
 client: shared
 type: feature
 status: active
-updated: 2026-10-19
+updated: 2026-10-20
 owners: ["jcardinal"]
 files:
   - api/_/app/route/ticket.php
@@ -38,8 +38,9 @@ Server side of the Talos ticket contract (client side: [ticket API integration](
 ## Gotchas
 
 - **`App_Cloud` in api throws `Error`, not `Exception`** (no AWS SDK, see [App_Cloud](../../library/features/app-cloud-aws-credentials.md)). `catch (Exception)` misses it. TRUE-82935: `copyFileToS3` after the mount write threw → row never renamed, request failed, and `error.php` itself crashed so nothing reached `Logs.Errors`.
-- **A failed PUT repeats hourly.** Talos re-sends at ~:00:49 and resets the reply timestamp each time → one more raw-named `session_report_*.txt` row per hour per ticket. By 2026-10-19: 4,219 rows (clientid 3 = 3,772, clientid 188 = 447). Cleanup: `dbchanges/TOGaDeskSupport/JC/2026-10-19.sql` — run only **after** the api fix is deployed, else rows come back.
+- **A failed PUT repeats hourly.** Talos re-sends at ~:00:49 and resets the reply timestamp each time → one more raw-named `session_report_*.txt` row per hour per ticket. Cleanup `dbchanges/TOGaDeskSupport/JC/2026-10-19.sql` ran on prod 2026-10-20 after the fix deployed: deleted 4,481 rows (header said 4,219 — rows kept growing until deploy); 0 bad rows remain. A cleanup like this must run **after** the fix deploys, else rows come back.
 - **Security, open (values not recorded):** `config.*.ini` sits in the web root with SES SMTP credentials and no deny rule; the old api s3fs IAM key is still in git history (key itself deleted 2026-10-12, TRUE-82705).
 
 ## Change history
+- 2026-10-20 — api PR #39 deployed; first correctly named Talos file row id 615850, no raw-named rows or duplicates after it; cleanup run (TRUE-82935) (jcardinal)
 - 2026-10-19 — Created: removed `copyFileToS3` from uploads (mount write is the S3 write), mount check before any row, per-reply duplicate guard, `error.php` Throwable guard, s3fs `iam_role=auto` (TRUE-82935, branch, not deployed) (jcardinal)

package/knowledge/1.0/apps/togadesk/features/s3fs-asifiles-file-storage.md

@@ -6,7 +6,7 @@ project: TOGa Desk
 client: shared
 type: feature
 status: active
-updated: 2026-10-19
+updated: 2026-10-20
 owners: ["mhammontree", "snaredla", "jcardinal"]
 files:
   - togadesk/ebs/mount-s3fs-folders.php
@@ -42,8 +42,9 @@ Every Desk file read from `/var/app/asifiles/...` (Knowledge Base docs `knowledg
 - **Open, not fixed — `template/pages/documents/viewdocument.php`:** `$_GET['id']` goes raw into the file path (path traversal, e.g. `../../../current/config.prod.ini`) and into unescaped SQL on `kb_versioning` and `kb_documents` (views UPDATE). A missing file red-boxes (`App_Error` exits on the warning) instead of a clean message. Fix: cast id to `(int)`; guard the read and show "document not available". Needs its own ticket.
 - The KB path is hardcoded to `knowledgebase-prod` (env-based line commented out), so non-prod reads prod KB files.
 - **Writing into the mount IS the S3 upload.** A file written under `/var/app/asifiles/<prefix>/` lands at `s3://asifiles/<prefix>/`; do not also `App_Cloud::copyFileToS3` it. Used by the email cron (worker `ontrack/desk/uploads` → `/var/app/asifiles/togadesk-prod/uploads`, `worker/ebs/setup_symbolic_links.php` + `links.worker.json`) and the 1.0 `api` Talos uploads ([Talos ticket API](../../api/features/talos-ticket-endpoint.md), same `iam_role=auto` setup since TRUE-82935). A write while the mount is down goes to local disk hidden under the mount point — check the mount first (`is_link`, or compare `stat()` dev with the parent).
-- **Open, not fixed — `odp-togadesk-prod` (Office Depot) deploys fail.** TOGaDesk-Production deploys of PR #624 and #625 (2026-10-16) failed there: `command 04-make_s3fs in .ebextensions/006_mount-s3fs.config failed` (s3fs 1.84 source build: virtual memory exhausted). `agilant-togadesk-prod` and `imhouston-togadesk-prod` succeeded. ODP instances may run mixed versions. Needs its own ticket (bigger instance / swap, or install a prebuilt s3fs).
+- **Open, not fixed — `odp-togadesk-prod` (Office Depot) deploys fail.** TOGaDesk-Production deploys of PR #624 and #625 (2026-10-16) failed there: `command 04-make_s3fs in .ebextensions/006_mount-s3fs.config failed` (s3fs 1.84 source build: virtual memory exhausted). `agilant-togadesk-prod` and `imhouston-togadesk-prod` succeeded. ODP instances may run mixed versions. 2026-10-20: `odp-togadesk-prod` instance type and memory limits raised (developer, ops) — **not yet verified** by a successful TOGaDesk-Production release; check the next release's `04-make_s3fs` step on ODP.
 
 ## Change history
+- 2026-10-20 — ODP instance size + memory raised for the s3fs build OOM; awaiting a successful release (TRUE-82935) (jcardinal)
 - 2026-10-19 — Mount write = S3 upload (email cron, api); ODP s3fs build failure on deploy (TRUE-82935) (jcardinal)
 - 2026-10-13 — Created: s3fs mount moved from the dead IAM key to `-o iam_role=auto`; check_s3fs/register scripts assume `WorkloadsRuntime` (TRUE-82718, togadesk PR #622) (snaredla, mhammontree)

package/knowledge/clients/prudential/features/dell-lch-iop-transmissions.md

@@ -6,7 +6,7 @@ project: Worker
 client: prudential
 type: client-feature
 status: active
-updated: 2026-09-29
+updated: 2026-10-20
 owners: ["rgirish", "bala"]
 files:
   - library/app/api/delllch.php
@@ -101,7 +101,16 @@ Dell's requested transaction record (date/time, payload, response code, response
 Reading it:
 - A row with a `requestPayload` but **NULL `responseCode`** = curl never got an answer.
 - A `/validate/` row with **no** matching `/request/` row = validated but never submitted.
-- **Do not `LIKE`-scan on `requestPayload`** — `Logs_Prudential.Api` is millions of rows and the payload is not indexed, so a `requestPayload LIKE '%REQ%'` query times out. Filter by `dtStamp` (indexed) + `direction` + exact `route` instead.
+- **Never `LIKE`-scan `requestPayload` without a `dtStamp` bound** — millions of rows, payload not indexed, it times out. Bound by `dtStamp` (indexed) + `direction` + exact `route` first (e.g. 30 min after PO `dtCreated`); a `LIKE` inside that window is fine.
+- The payload carries the **REQ** (`requestNumber`, `custom.svcOrderReqNumber`), **not the RITM** — search by REQ.
+
+### Tracing a REQ to Dell (read-only, prod)
+1. `Client_Prudential.ServiceRequests`: `c_reqNumber` (indexed) = REQ, `c_ritmNumber` = RITM, `number` = SR#. One SR per RITM, so one REQ can have several SRs.
+2. SR → SO: `SalesOrders.serviceRequestId`.
+3. SO → PO: bridge **`SalesOrders_PurchaseOrders`** (`salesOrderId`, `purchaseOrderId`). `PurchaseOrders_SalesOrders` is empty for these, and `PurchaseOrders.customerSalesOrder` does not hold the SO number.
+4. Dell PO: `vendorId = 1`; `dtSubmitted` = cron sent it; stage via `purchaseOrderStageId` → `PurchaseOrderStages.name`; ASN via `AdvanceShippingNotices.purchaseOrderId`.
+5. Send proof: `Logs_Prudential.Api` row, `direction='OUT'`, route `/iopv2/api/v2/request/LCHRequestV2`, response `202` (see transaction log above).
+- `ServiceRequests.serviceRequestStageId` is NULL on new SRs — not a status. Use PO stage + ASN + `c_dtTransmitted*UpdateToPrudential` columns.
 
 ### Deployment order (Prudential standard: beta before production)
 Beta scripts (`crons/toga2/prudential_beta/`) are migrated and verified **first**; only then is the production script (`crons/toga2/prudential/transmissions_to_dell.php`, `$inProduction = true`) touched. Beta scripts run against the beta DB (`db_beta_toga2core` / `db_client_prudential`) so failures never reach live customer orders. Established pattern for all Prudential script changes.
@@ -120,10 +129,13 @@ Verification plan:
 - **`dtSubmitted` is stamped without inspecting the response (latent bug, not yet fixed).** Every regional cron sets `PurchaseOrders.dtSubmitted = NOW()` immediately after the send without checking Dell's HTTP status, and `App_ApiTransaction::execute()` (`library/app/apitransaction.php`) only throws on curl transport failure / empty / non-JSON body — **not** on HTTP >= 400. So a Dell 4xx/5xx rejection is recorded as "sent", the PO drops out of the `dtSubmitted IS NULL` queue, and is never retried. `getAccessToken()` also does not check the token-call result (silent 401 path). Second way an order can silently fail to reach Dell; fix later by inspecting the response before stamping.
 - **⚠ A 422 retries forever — a permanent data rejection is treated as transient.** Because validation failure `continue`s without stamping `dtSubmitted`, the same PO is re-selected **every 5 minutes, indefinitely**. One PO Box address cost **748 Dell asset lookups between 2026-09-18 and 2026-09-22** (~280 calls/day), each ending in the same 422. A 422 is a schema/data rejection that will never pass on retry: it should **park** the request (stamp a failure state) rather than re-queue. Until that is built, the hourly alert email is the only stop signal — and it stops nothing.
 - `requestType` is the SR type only (Refresh/Breakfix/Reclaim/Bulk) — do **not** put the event there. Event signalling moved to the separate required `requestEvent` field (Create/Update/Cancel). Conflating them reproduces the old overloaded `svcOrderType` bug under the new schema.
+- **Multi-RITM REQ gets one SO+PO, on the first RITM only.** India REQ4534726 / REQ4534727 each came as 2 RITMs (same user, bundle 001 Knowledge Worker); the second SR (SR131682, SR131684) has no SO, no PO, and was never sent. Dell gets one LCHRequestV2 per REQ. Open (2026-10-20): duplicate RITM or second device expected? Ask Prudential/PM before changing generation.
+- **India SOs/POs from 2026-10-19 have 0 SalesOrderItems / PurchaseOrderItems** (SA100029, SA100020, PU127771, PU127762); USA (SA100048 / PU127790) has 1 each. Dell send is unaffected (payload built from the SR); NetSuite sync may be. Not investigated.
 - Dell deprecated `LCHRequest`; any script still POSTing to the old route will fail. All four transmission scripts must point at `LCHRequestV2`.
 - The removed fields (e.g. `deviceType`, `lob`, `imageType`) will be rejected by V2 validation — do not reintroduce them.
 
 ## Change history
+- 2026-10-20 — TRUE-82951: added REQ trace path; resubmit of the 5 "API 400 Error (SNOW -> TOGa)" RITMs verified (SR131681-SR131685, all 3 REQs sent, 202). Found multi-RITM gap and 0-item India orders. Investigation only. (rgirish)
 - 2026-10-05 — Recorded that the Dell ship-to comes from `ServiceRequests.deliverToAddressId` (not the PO address), Dell's PO Box 422, and the forever-retry loop a 422 creates (748 lookups for one bad address). Investigation only, no code change. (bala)
 - 2026-09-29 — Noted the provision profile is read from the linked bundle; wrong bundle link sent India REQs the USA profile. (rgirish)
 

package/package.json

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