toga-ai 1.0.310 → 1.0.312

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

@@ -23,7 +23,7 @@
 | [Startech Webhook Handler (worker2)](features/startech-webhook-handler.md) | Receives inbound webhook events from Startech (Easeedesk) and creates or updates the corresponding ticket in TOGA 2.0. | worker2/Worker/Startech.php |
 | [Talos (TOGa IQ) Meeting-Notes Integration & Token Auto-Refresh (consumer)](features/talos-meeting-notes-integration.md) | How a **dev tool / agent consumes Talos (TOGa IQ)** to query the team meeting-notes corpus programmatically. | .claude/skills/plan-ticket/scripts/talos.js |
 | [Talos Pricing Automation (worker2 Cron — AWS Actuals, Calibration, Monthly Report)](features/talos-pricing-automation.md) | The worker2 half of the **Talos Pricing Platform** (see the talos `pricing-cogs-model` and tools `talos-pricing-ui` docs for the other halves). | worker2/Worker/Talos/Pricing.php, worker2/Database/TalosPricingCrons.sql |
-| [Talos Transcript Ingestion Pipeline (worker2 → AWS Bedrock KBs)](features/talos-transcript-ingestion.md) | `_Worker_Team_Transcripts` runs a fully automated, cron-driven pipeline that ingests raw Teams transcripts into the **Talos / TOGa IQ** AWS Bedrock knowledge ba | worker2/Worker/Team/Transcripts.php, worker2/bin/sync-knowledge-bases.php, worker2/Config/production.ini, dbchanges2/Team/2026-06-30a, dbchanges2/Team/2026-06-30b, dbchanges2/Team/2026-06-30c, dbchanges2/Team/2026-06-30d, dbchanges2/Team/2026-06-30e, dbchanges2/Core/2026-06-30a, dbchanges2/Core/2026-07-02a, dbchanges2/Team/2026-07-02a, dbchanges2/Team/2026-07-08a, dbchanges2/Team/2026-07-09a |
+| [Talos Transcript Ingestion Pipeline (worker2 → AWS Bedrock KBs)](features/talos-transcript-ingestion.md) | `_Worker_Team_Transcripts` runs a fully automated, cron-driven pipeline that ingests raw Teams transcripts into the **Talos / TOGa IQ** AWS Bedrock knowledge ba | worker2/Worker/Team/Transcripts.php, worker2/bin/sync-knowledge-bases.php, worker2/Config/production.ini, worker2/Database/TeamsTranscriptExports.sql, dbchanges2/Team/2026-06-30a, dbchanges2/Team/2026-06-30b, dbchanges2/Team/2026-06-30c, dbchanges2/Team/2026-06-30d, dbchanges2/Team/2026-06-30e, dbchanges2/Core/2026-06-30a, dbchanges2/Core/2026-07-02a, dbchanges2/Team/2026-07-02a, dbchanges2/Team/2026-07-08a, dbchanges2/Team/2026-07-09a, dbchanges2/Team/2026-07-10a |
 | [Team Sprint Management & Reporting](features/team-sprint-management.md) | `_Worker_Team_Sprint` (file `Worker/Team/Sprint.php`) is the engine behind TOGA's internal **development-sprint process and reporting**. | worker2/Worker/Team/Sprint.php |
 | [Teams Meeting Transcript Export](features/teams-transcript-export.md) | > **SUPERSEDED (2026-07-09) — the S3-staging model below is history.** `Export` is now a thin > **GRAPH-DIRECT** cron poller: it no longer archives raw VTT to ` | worker2/Worker/Team/Transcripts.php, worker2/Config/production.ini, worker2/Database/TeamsTranscriptExports.sql, dbchanges2/Core/2026-06-18a - Teams Transcript Export schedule.sql |
 | [VAPI Webhook Handler (worker2 — AI-BDR end-of-call processing)](features/vapi-webhook-handler.md) | `_Worker_Vapi` ([worker2/Worker/Vapi.php](worker2/Worker/Vapi.php)) is the **PHP side of the AI-BDR call loop** — the webhook that receives VAPI's end-of-call r | worker2/Worker/Vapi.php, worker2/Worker/Ai/Bdr/Vapi.php |

package/knowledge/2.0/apps/worker2/features/talos-transcript-ingestion.md

@@ -6,12 +6,13 @@ project: Worker
 client: shared
 type: feature
 status: active
-updated: 2026-07-09
+updated: 2026-07-10
 owners: [jcardinal]
 files:
   - worker2/Worker/Team/Transcripts.php
   - worker2/bin/sync-knowledge-bases.php
   - worker2/Config/production.ini
+  - worker2/Database/TeamsTranscriptExports.sql
   - dbchanges2/Team/2026-06-30a
   - dbchanges2/Team/2026-06-30b
   - dbchanges2/Team/2026-06-30c
@@ -22,6 +23,7 @@ files:
   - dbchanges2/Team/2026-07-02a
   - dbchanges2/Team/2026-07-08a
   - dbchanges2/Team/2026-07-09a
+  - dbchanges2/Team/2026-07-10a
 related:
   - ./teams-transcript-export.md
   - ./notification-email-template.md
@@ -65,20 +67,48 @@ JSON that PHP renders to an inline-styled HTML recap email, enqueued to the orga
 ## How it works
 
 ### `Export(int $lookbackDays, ?int $limit = null, array $cc = [], array $bcc = [])` (cron)
-Thin poller. The old `organizers` parameter was **REMOVED** — organizers are always resolved
-from config now.
-1. For each configured organizer, poll Microsoft Graph for transcripts in the lookback window.
-2. Resolve the organizer email (see *Organizer email resolution*).
-3. Record a discovery-ledger row in `Team.TranscriptExports` — **synchronously, then
-   committed** (see the durability gotcha).
-4. Enqueue one `Process` job per transcript.
+Thin poller with a **quiet-period stability gate** — it does **not** enqueue a transcript on
+first sight (that processed still-in-progress meetings and emailed half-meeting recaps). The old
+`organizers` parameter was **REMOVED** — organizers are always resolved from config now.
+
+**Why a gate is needed:** the Graph `callTranscript` object carries **no "meeting ended"
+signal** — only `id, meetingId, createdDateTime, transcriptContentUrl, meetingOrganizer` (no
+`endDateTime`, no `duration`, no `status`, verified against Graph v1.0 `onlineMeeting:
+getAllTranscripts`). Teams keeps **appending to the VTT while the meeting is live**.
+`onlineMeeting.endDateTime` is only the **scheduled** end and for recurring meetings is the
+series anchor (same unreliability that already rules out `startDateTime` for the meeting date).
+So the only reliable end proxy is **that the transcript content stopped growing**.
+
+**Observe-until-stable**, per organizer, per transcript:
+1. Skip immediately if already handed off (`dtEnqueued` set) — **no re-download**.
+2. Otherwise download the VTT **only to measure `strlen` (byte size)**.
+3. First sighting → `recordObservation()` (INSERT, `dtEnqueued` NULL) and **defer**.
+4. Size grew since last poll → still live → `updateObservationSize()` (resets the
+   `dtLastChanged` anchor) and **defer**.
+5. Size unchanged for `>= TRANSCRIPT_STABLE_QUIET_SECONDS` (const = **1200s / 20 min**) →
+   meeting ended → `markEnqueued()` (stamps `dtEnqueued`, commit) then enqueue one
+   `Team/Transcripts/Process` job. At the hourly Export cron cadence this is effectively
+   "second poll with unchanged size ⇒ process," with the 20-min floor guarding against
+   unusually frequent polls.
 
 - `$limit` caps enqueues per run (mainly for testing; e.g. `1` = a single meeting).
 - `cc` / `bcc` thread through each `Process` job into the recap email; validated in
   `enqueueRecapEmail` (deduped, organizer excluded). **Fallback:** if the organizer email
   can't be resolved but `cc` is present, the recap sends **TO** the cc addresses.
-- A Graph `callTranscript` already recorded (`alreadyExported()`) is skipped. Export treats a
-  Duplicate-entry exception as **"skipped"**, not a hard error.
+
+**Watermark (`resolveWatermark`) — must not skip past an open observation.** The per-organizer
+Graph window start takes `MIN(dtCreated)` over **open** observations (`dtEnqueued IS NULL`),
+falling back to `MAX(dtCreated)` over handed-off rows, minus the 1-min overlap. Without this a
+long meeting whose `createdDateTime` predates a newer already-handed-off meeting falls outside
+the Graph date filter and gets stuck "observing" forever.
+
+**Private helpers (Transcripts.php):** `loadObservation` (`useQueryCache(false)`; returns
+`id,sizeBytes,dtLastChanged,dtEnqueued,meetingSubject,organizerEmail`), `recordObservation`
+(replaces `recordExport`; synchronous + `_Database::transactionCommit(DB_TEAM)`),
+`updateObservationSize`, `markEnqueued`, `meetingFor` (memoized `getMeeting` wrapper),
+`secondsSince` (parses a MySQL UTC datetime with `' UTC'` suffix → elapsed seconds).
+`alreadyExported()` and `recordExport()` were **removed** (superseded by the observation
+helpers).
 
 ### `Process(int $transcriptId, string $graphUserId, string $meetingId, string $organizerEmail, string $subject, string $meetingStartIso, array $cc = [], array $bcc = [])`
 1. Download the VTT **straight from Graph** (no S3 round trip).
@@ -128,12 +158,27 @@ spacing (Bedrock allows only one in-flight ingestion per KB, so parallel syncs r
 - **`Team.TranscriptPromptTemplate`** — `name, bodyText, instruction, model, temperature, …`.
 - **`Team.KnowledgeBases`** — `slug, name, isGeneral, bedrockKbId, isActive`; auto-kept-current
   from Bedrock by the daily `SyncKnowledgeBases`.
-- **`Team.TranscriptProcessing`** — pipeline ledger + idempotency. `status` ENUM
-  (`pending/cleaned/uploaded/archived/synced/failed`). **`transcriptIdentifier` widened to
-  `VARCHAR(768)`** (dbchanges2 `Team/2026-07-09a`).
-- **`Team.TranscriptExports`** — discovery ledger written by `Export`.
-  `transcriptIdentifier` **also widened to `VARCHAR(768)`**. Graph-direct columns +
-  `organizerEmail` added (dbchanges2 `Team/2026-07-08a`).
+**The two tables are BOTH live and NOT redundant** — different owners, different jobs:
+
+- **`Team.TranscriptExports`** — **discovery/observation ledger** owned by `Export()`: drives
+  the per-organizer watermark, transcript dedupe, and the quiet-period observation. Keyed on
+  `transcriptIdentifier` (widened to `VARCHAR(768)`, dbchanges2 `Team/2026-07-09a`).
+  Quiet-period columns (dbchanges2 `Team/2026-07-10a`): `sizeBytes` **repurposed** as the
+  last-observed raw VTT byte count; `dtLastChanged` (the quiet-period anchor); `dtEnqueued`
+  (**NULL = still observing; non-NULL = handed off**, the new done-marker). Dead column
+  `s3Key` **dropped** (leftover from the removed S3-staging scheme, no code refs).
+- **`Team.TranscriptProcessing`** — **pipeline state machine** owned by `Process()`: `status`
+  ENUM (`pending/cleaned/uploaded/archived/synced/failed`), KB result keys
+  (`kbSlug/approvedKey/archiveKey/aiModel/failureReason`), and its own
+  `transcriptIdentifier`-keyed idempotency (also `VARCHAR(768)`). Dead column `sourceKey`
+  (and its unique index) **dropped** (removed S3-staging leftover).
+
+**Dedupe key rule:** recurring meetings **reuse the same `meetingIdentifier`** but get a
+**new `transcriptIdentifier` per occurrence**, so dedupe MUST stay keyed on
+`transcriptIdentifier`, never `meetingIdentifier`.
+
+**Migration ordering (`Team/2026-07-10a`):** ADD columns → backfill
+`dtEnqueued=dtExported` on existing rows → DROP `s3Key` → DROP INDEX + `sourceKey`.
 
 ## Configuration
 
@@ -146,6 +191,20 @@ part of the ingestion loop** (raw reads removed). Credential values live only in
 
 ## Gotchas / known issues
 
+- **DEPLOY ORDER: apply migration `2026-07-10a` BEFORE deploying the new worker2 code.** The
+  code reads/writes `dtEnqueued`/`dtLastChanged`; deploying code first errors on every poll.
+  The migration also backfills every existing row as handed-off (`dtEnqueued=dtExported`) so
+  no historical or legacy-duplicate row is re-observed or re-processed.
+- **Root cause of the earlier "same meeting processed multiple times" duplicate rows.**
+  Diagnosed from prod `Team.TranscriptExports` rows 573/577 (same "Craftex Open Items"
+  meeting): row 573's `transcriptIdentifier` was truncated to exactly 255 chars and is the
+  byte-for-byte prefix of row 577's full 304-char id. These were pre-`2026-07-09a` truncated
+  rows; the removed `alreadyExported()` compared the full 304-char id and never matched the
+  truncated stored value, so the meeting re-enqueued. The `2026-07-09a` widen fixed it going
+  forward but left stale truncated rows that could never match. Across the table 42
+  `meetingIdentifier`s had duplicates (lengths 56/255/304) — a mix of truncation artifacts and
+  **legitimate recurring occurrences** (recurring reuses `meetingIdentifier`, new
+  `transcriptIdentifier` each time). `2026-07-10a`'s backfill marks all historical rows inert.
 - **Idempotency: 304-char Graph ids truncated at `VARCHAR(255)` (root cause of endless
   reprocessing).** Graph `callTranscript` ids are ~304 chars; `transcriptIdentifier` columns
   were `VARCHAR(255)`, so ids were silently truncated. `alreadyExported()` compared the full
@@ -183,6 +242,20 @@ part of the ingestion loop** (raw reads removed). Credential values live only in
 
 ## Change history
 
+- 2026-07-10 — **Added the quiet-period stability gate to `Export`** so in-progress meetings
+  are no longer processed (was emailing half-meeting recaps). `callTranscript` has no
+  end-of-meeting signal, so `Export` now observes each transcript's VTT byte size and only
+  hands off (enqueues `Process`) once size is unchanged for `TRANSCRIPT_STABLE_QUIET_SECONDS`
+  (1200s). New `TranscriptExports` columns `dtLastChanged`/`dtEnqueued` + repurposed
+  `sizeBytes`; new helpers (`recordObservation`, `updateObservationSize`, `markEnqueued`,
+  `loadObservation`, `meetingFor`, `secondsSince`); removed `alreadyExported`/`recordExport`.
+  `resolveWatermark` now floors at `MIN(dtCreated)` of open observations so a long meeting
+  can't fall out of the Graph window. Confirmed both `Team` tables are non-redundant
+  (Exports = discovery/observation, Processing = pipeline state machine); dropped dead columns
+  `TranscriptExports.s3Key` and `TranscriptProcessing.sourceKey`. Diagnosed the prior
+  duplicate-row root cause (pre-`2026-07-09a` truncated ids never matched; dedupe must stay
+  keyed on `transcriptIdentifier`, never `meetingIdentifier`). **Apply `2026-07-10a` before
+  deploying the code.** dbchanges2: `Team/2026-07-10a`. (jcardinal)
 - 2026-07-09 — **Re-architected to GRAPH-DIRECT.** `Export` is now a thin cron poller
   (removed the `organizers` param; added `$limit`, `cc`/`bcc`); `Scan` and
   `bin/reprocess-transcripts.php` deleted; the `toga-private` staging bucket dropped entirely.

package/knowledge/clients/prudential/INDEX.md

@@ -6,6 +6,6 @@
 | [Prudential: Dell LCH IOP transmissions (LCHRequestV2)](features/dell-lch-iop-transmissions.md) | 1.0 | Outbound order transmissions from the 1.0 worker tier to Dell's Lifecycle Hub (LCH) ITSM integration. | library/app/api/delllch.php, worker/crons/toga2/prudential/transmissions_to_dell.php, worker/crons/toga2/prudential_beta/transmissions_to_dell_india.php, worker/crons/toga2/prudential_beta/transmissions_to_dell_ireland.php, worker/crons/toga2/prudential_beta/transmissions_to_dell_usa.php |
 | [Prudential: Device information import + unit→contact linking (import_device_information.php)](features/device-information-import-and-contact-linking.md) | 1.0 | Prudential's **device-sync** cron (`worker/crons/toga2/prudential/import_device_information.php`) pulls device/asset records (from ServiceNow / the Dell CMDB fe | worker/crons/toga2/prudential/import_device_information.php, worker/crons/toga2/prudential/backfill_unit_contacts.php, dbchanges2/Client_Prudential/2026-07-07 - Contact Dedup Merge.sql |
 | [Prudential: Service Request Regional Address Validation](features/service-request-address-validation.md) | 2.0 | The `prePost` interceptor on `_Model_Prudential_ServiceRequest` validates `deliverToAddress` fields differently depending on which Prudential regional customer | _underscore/Model/Prudential/ServiceRequest.php |
-| [Prudential Order Shipped Email — transmit_ordershipped_updates_prudential.php](features/transmit-ordershipped-email.md) | 1.0 | Cron script that transmits "Order Shipped" updates to ServiceNow (RITM) and sends a shipped notification email to the end user. | worker/crons/toga2/prudential/transmit_ordershipped_updates_prudential.php, worker/crons/toga2/prudential/transmit_closecomplete_updates_prudential.php, worker/crons/toga2/prudential/generate_sales_and_purchase_orders_from_service_requests.php, worker/crons/toga2/prudential_beta/generate_sales_and_purchase_orders_from_service_requests.php |
+| [Prudential Order Shipped Email — transmit_ordershipped_updates_prudential.php](features/transmit-ordershipped-email.md) | 1.0 | Cron script that transmits "Order Shipped" updates to ServiceNow (RITM) and sends a shipped notification email to the end user. | worker/crons/toga2/prudential/transmit_ordershipped_updates_prudential.php, worker/crons/toga2/prudential/transmit_closecomplete_updates_prudential.php, worker/crons/toga2/prudential/transmit_rejected_cancelled_updates_prudential.php, worker/crons/toga2/prudential/generate_sales_and_purchase_orders_from_service_requests.php, worker/crons/toga2/prudential_beta/generate_sales_and_purchase_orders_from_service_requests.php, worker/crons/notifications/reports/prudential_exception_report.php |
 | [Prudential Financial](profile.md) | 2.0 | Prudential is a TOGA client whose device-fulfillment flow is driven by **Dell** via the Dell API (`Client_Prudential.Apis.id = 2`). |  |
 | [Prudential: Dell ASN failed POST backfill replay](workflows/dell-asn-backfill-replay.md) | 2.0 | When Dell ASN POSTs fail in bulk (e.g. |  |

package/knowledge/clients/prudential/features/transmit-ordershipped-email.md

@@ -6,13 +6,15 @@ project: Worker
 client: prudential
 type: client-feature
 status: active
-updated: 2026-07-06
+updated: 2026-07-10
 owners: ["rgirish"]
 files:
   - worker/crons/toga2/prudential/transmit_ordershipped_updates_prudential.php
   - worker/crons/toga2/prudential/transmit_closecomplete_updates_prudential.php
+  - worker/crons/toga2/prudential/transmit_rejected_cancelled_updates_prudential.php
   - worker/crons/toga2/prudential/generate_sales_and_purchase_orders_from_service_requests.php
   - worker/crons/toga2/prudential_beta/generate_sales_and_purchase_orders_from_service_requests.php
+  - worker/crons/notifications/reports/prudential_exception_report.php
 related:
   - ../profile.md
 ---
@@ -47,11 +49,37 @@ Iterates the same POs collected in Phase 1. For each:
 - `Client_Prudential.PurchaseOrders.c_dtEmailSentOrderShipped` — stamped after email send
 - Both fields are checked by `prudential_exception_report.php` to detect discrepancies
 
+**⚠ `c_dtTransmittedOrderClosedUpdateToPrudential` is an OVERLOADED column (discovered 2026-07-10).**
+It is written by TWO different crons for THREE distinct terminal outcomes:
+- **Delivered / Closed-Complete** — stamped by `transmit_closecomplete_updates_prudential.php`,
+  gated on an ASN with a `DELIVERED` tracking number, and **pairs with a customer email**
+  (`c_dtEmailSentOrderClosed`). *Only this path owes an email.*
+- **Rejected / Cancelled** — stamped by `transmit_rejected_cancelled_updates_prudential.php`,
+  with **no ASN join**; it only pushes a ServiceNow "rejected"/"cancelled" RITM update and
+  **sends no customer email**.
+
+So a no-ASN Rejected/Cancelled PO shows a "delivered" transmit stamp with `c_dtEmailSentOrderClosed`
+NULL forever — that is correct, not a failure. Any query keyed on this column alone will
+conflate the two. Example: REQ4448998 (PO 26544) was a Rejected order with no ASN/tracking and
+was a false positive in the "Order Delivered Email Not Sent" report.
+
 ## Exception report link
 `worker/crons/notifications/reports/prudential_exception_report.php` flags any PO where
 `c_dtTransmittedOrderShippedUpdateToPrudential IS NOT NULL` AND `c_dtEmailSentOrderShipped IS NULL`
 as "Order Shipped Email Not Sent". This appears daily in the Prudential REQ Processing Report email.
 
+**Order-Delivered discrepancy query — DELIVERED gate required (fixed 2026-07-10, ~line 463-474).**
+The Order-Delivered discrepancy query originally filtered only on
+`c_dtTransmittedOrderClosedUpdateToPrudential IS NOT NULL AND c_dtEmailSentOrderClosed IS NULL`
+with no shipment/stage filter. Because that column is overloaded (see Data model), every
+Rejected/Cancelled Dell PO was flagged as an "Order Delivered Email Not Sent" failure even though
+it never owed a delivery email. Fix: add
+`AND EXISTS (AdvanceShippingNotices → ASNItems → ASNItemUnits → ASNItemUnits_TrackingNumbers →
+TrackingNumbers WHERE purchaseOrderId = PurchaseOrders.id AND TrackingNumbers.status = 'DELIVERED')`
+— this mirrors the closecomplete cron's own Phase-1 email precondition, so the report only flags
+orders that genuinely qualified for a delivery email. Over 2026-07-01..07-09 this dropped 6 false
+positives (25 → 19 flagged) while retaining all 19 genuine discrepancies.
+
 ## Sibling scripts sharing this pattern
 The same two-phase (transmit-then-email) shape and the same PDF-fetch fragility exist in three
 sibling crons, all fixed the same way this session (2026-07-06):
@@ -65,6 +93,21 @@ sibling crons, all fixed the same way this session (2026-07-06):
 
 ## Gotchas / known issues
 
+**ROOT CAUSE (third regression) — `App_Database::escapeString()` does not exist → fatal on the 404 auto-create path (fixed 2026-07-10):**
+`createAssetAndRetryPut()` in **both** `transmit_ordershipped` and `transmit_closecomplete`
+(~line 158) called `App_Database::escapeString($serialNumber)`. **That method does not exist** on
+`App_Database` — only `sqlEscape`, `sqlProtect`, and `mysqlRealEscapeString` do. Under the 1.0
+framework's `error_reporting(E_ALL)`, calling a non-existent static method is a **fatal `Error`
+that kills the cron mid-run**. It fires whenever an asset PUT to ServiceNow returns 404
+(`isAssetNotFoundError`) — routine for Breakfix/Reclaim/Refresh returned/replacement assets not yet
+in the Prudential CMDB. The fatal occurs in Phase 1 **after** the transmit flag is stamped but
+**before** the email phase, so the email is permanently stranded (email flag left NULL). This was
+the specific unaddressed trigger of the month-long email-stranding — distinct from, but riding on
+top of, the two-phase design flaw below. **Fix: `escapeString` → `sqlEscape` in both files**
+(`sqlEscape` is already used correctly elsewhere in the same files, e.g. ordershipped line 1386).
+This was flagged as a "latent error" in the 2026-07-06 pre-existing-issues note; it turned out to
+be the live trigger.
+
 **ROOT CAUSE — `file_get_contents` in a 1.0 cron THROWS, it does not return false (discovered 2026-07-06):**
 The 1.0 framework bootstrap sets `error_reporting(E_ALL)` and `App_Error::handleError`
 (`library/app/error.php` ~line 348) converts **every** PHP warning into an `ErrorException`.
@@ -110,8 +153,8 @@ URL was still live in 3 of the sibling files and was corrected this session.
 **Pre-existing issues surfaced this session (NOT fixed — awareness only):**
 - SQL-injection risk: unescaped `$reqNumber` concatenated into a `LIKE '%...%'` query in the
   Phase-2 body of both `transmit_ordershipped` and `transmit_closecomplete`.
-- `transmit_closecomplete` calls `App_Database::escapeString()` (~line 158) which does not exist
-  on `App_Database` (only `sqlEscape` does) — latent error in the `createAssetAndRetryPut` path.
+- (RESOLVED 2026-07-10) `App_Database::escapeString()` at ~line 158 in **both** crons — see the
+  ROOT CAUSE gotcha above; this "latent" error was the actual fatal trigger, now fixed to `sqlEscape`.
 - Separate inbound issue: Dell SR re-POST hitting `ServiceRequests.number` UNIQUE constraint →
   API 400 "Duplicate entry SR129013" (REQ4444748). Not part of the email fix.
 
@@ -132,5 +175,20 @@ stamp (crash hits the next iteration). With multiple New-type POs, a crash on PO
 all subsequent POs in the same run.
 
 ## Change history
+- 2026-07-10 — Third regression of the "Order Shipped / Order Delivered Email Not Sent" symptom.
+  True trigger: `createAssetAndRetryPut()` called the nonexistent `App_Database::escapeString()`
+  (~line 158 in `transmit_ordershipped` + `transmit_closecomplete`) — a fatal `Error` under E_ALL
+  that fired on the ServiceNow 404 asset auto-create path (routine for Breakfix/Reclaim/Refresh),
+  killing Phase 1 after the transmit stamp but before the email. Fixed `escapeString` -> `sqlEscape`
+  in both files (verified by 3 adversarial subagents; php -l clean). Recovered by nulling the
+  transmit flags for 9 stranded shipped POs + 1 closed PO (re-processing is idempotent) — the 9
+  owed shipped emails were confirmed sent 2026-07-10 09:34-09:35.
+  Also: discovered `c_dtTransmittedOrderClosedUpdateToPrudential` is overloaded across
+  Delivered vs Rejected/Cancelled (only Delivered owes an email), and fixed the
+  `prudential_exception_report.php` Order-Delivered discrepancy query to require an EXISTS on a
+  DELIVERED tracking number (drops Rejected/Cancelled false positives; REQ4448998/PO 26544 was one).
+  The structural two-phase stamp-before-email flaw remains **open** — candidate durable fix: stamp
+  the email flag only after a successful send and/or wrap each PO's email phase in try/catch. Not
+  done this session (scoped to the specific trigger) (rgirish)
 - 2026-07-06 — Found the real root cause: `file_get_contents` throws (E_ALL→ErrorException) so the `!== false` guards (incl. the 2026-06-18 one) were never effective. Added `safeFetchPdf()` (try/catch ErrorException → false) + independent per-PDF guards; email now always sends even if a PDF fails. Extended the same fix to `transmit_closecomplete` and both `generate_sales_and_purchase_orders_from_service_requests` scripts, and finished the stale Mac PDF URL fix in the 3 files the 2026-06-18 change missed. Documented the permanent two-phase stranding flaw and the date-bounded-recovery requirement; scope kept to fix-forward (no auto self-heal) by developer decision (rgirish)
 - 2026-06-18 — Fixed 403 crash: corrected Mac PDF URL (`_15.6_v4` → `PrudentialMacSetupGuide.pdf`) and added a `!== false` guard on all S3 fetches in New branch. NOTE (2026-07-06): this guard was ineffective — the exception is thrown inside `file_get_contents`, not returned (rgirish)

package/package.json

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