toga-ai 1.0.705 → 1.0.706

package/knowledge/clients/compass-canada/profile.md

@@ -16,7 +16,7 @@ project: _Underscore
 client: compass-canada
 type: profile
 status: active
-updated: 2026-08-28
+updated: 2026-08-31
 owners: [jcardinal, bala, tcox, apeterson]
 files: []
 related:
@@ -28,6 +28,7 @@ related:
   - ../compass-usa/features/stranded-approval-reassignment.md
   - ../compass-usa/features/people-file-user-lifecycle.md
   - ../compass-usa/features/isfulfillable-data-quality-and-type-rule.md
+  - ../compass-usa/features/mits-sales-order-transmission-alerting.md
   - features/french-order-email-localization.md
   - features/order-fulfillment-status-per-line.md
   - features/item-fulfillment-tableviews.md
@@ -72,6 +73,14 @@ to but distinct from Compass USA. Like Compass USA it spans the **2.0** commerce
 - Worker crons for the G&T flow live under `worker/crons/toga2/compasscanada/workflow/`
   (`1_…` transmit SOs to MITS, `2_…` transmit POs to vendors, `3_…` status from G&T cXML,
   `4_…` import G&T ASNs).
+- **⚠ MITS transmit alerting has diverged from Compass USA.** Canada's `1_…transmit…to_mits`
+  cron still raises all **three** of its failure alerts as in-cron `App_Email_Agilant` emails
+  (No Items Found / more than 15 items / Invalid response from MITS API), so changing who is
+  notified here **is** a code edit — whereas USA's rejection path now routes through the Logs
+  Issue/Event pipeline and is configured against the issue instead. Canada's "Invalid response"
+  email also `print_r`s the full payload (ship-to PII) into the body and has no dedupe. Recipients
+  are currently `devteam@togatech.com` + `vburks@togatech.com`. See
+  [MITS Sales-Order Transmit Alerting](../compass-usa/features/mits-sales-order-transmission-alerting.md).
 
 ## Storefront notes (toga2-commerce)
 - Runs the same `toga2-commerce` storefront (2.0, consumes api2), with English + French cart

package/knowledge/clients/compass-usa/INDEX.md

@@ -10,7 +10,7 @@
 | [Compass MITS PO → SO Item Linking](features/mits-po-to-so-item-linking.md) | 2.0 | MITS sends Compass inbound Purchase Orders (`POST /v2/purchase-orders`) against a Sales Order (`mitsSalesOrder`). | _underscore/Model/Compass/PurchaseOrder.php, worker/crons/toga2/compass/workflow/3a_import_office_depot_purchase_orders.php |
 | [Compass MITS PO Transmission to Vendors](features/mits-po-transmission-to-vendors.md) | 2.0 | The 1.0 worker cron `2_transmit_mits_purchase_orders_to_vendors.php` transmits Compass PurchaseOrders to their vendors (Office Depot, Strategic Systems, Compass | worker/crons/toga2/compass/workflow/2_transmit_mits_purchase_orders_to_vendors.php, worker/crons/toga2/compasscanada/workflow/2_transmit_mits_purchase_orders_to_vendors.php, library/app/client/compass.php |
 | [Compass MITS PO rejection — zero line items (400 + Issue + PM alert email)](features/mits-po-zero-line-item-rejection.md) | 2.0 | MITS transmits Compass purchase orders that carry **`"purchaseOrderItems": []`** (real example: PO `50309196-1`, `mitsSalesOrder` `MR244630`). | _underscore/Model/Compass/PurchaseOrder.php, _underscore/Model/Compass/Usa/PurchaseOrder.php, _underscore/Model/Compass/Canada/PurchaseOrder.php, worker2/Worker/Client/Compass/reports/PurchaseOrderRejectionEmail.php |
-| [Compass MITS Sales-Order Transmission — Rejection Alerting (Issue/Event, not email-in-cron)](features/mits-sales-order-transmission-alerting.md) | 2.0 | When MITS **rejects** a Compass sales order transmitted by the 1.0 cron `1_transmit_compass_sales_orders_to_mits.php`, the alert is no longer an email built ins | worker/crons/toga2/compass/workflow/1_transmit_compass_sales_orders_to_mits.php, worker2/Worker/Infrastructure/Errors.php, _underscore/Model/Core/Logs/Issue.php, _underscore/Model/Core/Logs/IssueEmailAddress.php, dbchanges2/Logs/2026-08-04a - MITS rejection business recipients.sql |
+| [Compass MITS Sales-Order Transmit Alerting (US Issue/Event vs Canada in-cron email)](features/mits-sales-order-transmission-alerting.md) | 2.0 | How a failure in the `1_transmit_..._sales_orders_to_mits.php` cron reaches a human — for **both** Compass tenants, because **they no longer work the same way** | worker/crons/toga2/compass/workflow/1_transmit_compass_sales_orders_to_mits.php, worker/crons/toga2/compasscanada/workflow/1_transmit_compassCanada_sales_orders_to_mits.php, worker2/Worker/Infrastructure/Errors.php, tools/mvc/errors/post.php, _underscore/Model/Core/Logs/Issue.php, _underscore/Model/Core/Logs/IssueEmailAddress.php, dbchanges2/Logs/2026-08-04a - MITS rejection business recipients.sql |
 | [Compass MR/MA Order Auto-Approval & Status Gate](features/mr-ma-order-approval-and-status.md) | 2.0 | Compass **MR** and **MA** sales orders are system-generated from the MITS / Office Depot EDI pipeline (they do not originate as user-entered SA orders) and must | _underscore/Model/Compass/SalesOrder.php, _underscore/Model/Compass/PurchaseOrder.php, worker/crons/toga2/compass/workflow/3a_import_office_depot_purchase_orders.php |
 | [Compass ODP EDI 850 Line-Item Resolution (VA part number to IN SKU fallback)](features/odp-edi-850-item-resolution.md) | 1.0 | How each **PO1 line** on an inbound Office Depot (ODP) **EDI 850** is resolved to a real `Client_Compass` catalog item before cron `3a_import_office_depot_purch | worker/crons/toga2/compass/workflow/3a_import_office_depot_purchase_orders.php, library/app/Edi.php |
 | [Compass Office Depot EDI 855 Acknowledgement + Over-Quantity PO Guard](features/odp-edi-855-acknowledgement-and-overquantity-guard.md) | 1.0 | How Compass acknowledges Office Depot (ODP) inbound **EDI 850** purchase orders with an **X12 855**, and the **over-quantity guard** that rejects a duplicate PO | worker/crons/toga2/compass/workflow/3a_import_office_depot_purchase_orders.php, worker/crons/toga2/compass/workflow/4_transmit_office_depot_po_acknowledgements.php, library/app/edi.php |

package/knowledge/clients/compass-usa/features/mits-sales-order-transmission-alerting.md

@@ -1,59 +1,99 @@
 ---
-title: Compass MITS Sales-Order Transmission — Rejection Alerting (Issue/Event, not email-in-cron)
+title: Compass MITS Sales-Order Transmit Alerting (US Issue/Event vs Canada in-cron email)
 framework: "2.0"
 project: _Underscore
 client: compass-usa
 type: client-feature
 status: active
-updated: 2026-08-04
-owners: ["dfranks"]
+updated: 2026-08-31
+owners: ["dfranks", "bala"]
 files:
   - worker/crons/toga2/compass/workflow/1_transmit_compass_sales_orders_to_mits.php
+  - worker/crons/toga2/compasscanada/workflow/1_transmit_compassCanada_sales_orders_to_mits.php
   - worker2/Worker/Infrastructure/Errors.php
+  - tools/mvc/errors/post.php
   - _underscore/Model/Core/Logs/Issue.php
   - _underscore/Model/Core/Logs/IssueEmailAddress.php
   - dbchanges2/Logs/2026-08-04a - MITS rejection business recipients.sql
 related:
   - mits-po-transmission-to-vendors.md
+  - ../../compass-canada/profile.md
   - ../../../2.0/apps/worker2/features/error-escalation-cron.md
   - ../../../2.0/apps/_underscore/features/error-reporting-issue-event.md
   - ../../../1.0/apps/library/features/error-capture-1-0.md
+  - ../../../1.0/apps/tools/features/errors-curation-console.md
 ---
 
 ## Summary
 
-When MITS **rejects** a Compass sales order transmitted by the 1.0 cron
-`1_transmit_compass_sales_orders_to_mits.php`, the alert is no longer an email built inside the
+How a failure in the `1_transmit_..._sales_orders_to_mits.php` cron reaches a human — for
+**both** Compass tenants, because **they no longer work the same way**.
+
+When MITS **rejects** a Compass **USA** sales order, the alert is not an email built inside the
 cron. It is a **business exception** raised into the shared Logs Issue/Event pipeline, and its
-recipients are **rows in `Logs.IssueEmailAddress`**.
+recipients are **rows in `Logs.IssueEmailAddress`**. The Compass **Canada** cron still sends a
+direct `App_Email_Agilant` for the same rejection.
+
+**Consequence for anyone handed a ticket like "add <person> to the MITS error emails": the
+answer depends on the tenant and on which failure.** Check the table below before opening
+either file — half of these alerts have no PHP to change, and the other half have no
+configuration surface at all.
+
+## Which alert goes where (check this first)
+
+| Tenant / failure | Mechanism | To add a recipient |
+|---|---|---|
+| **USA** — MITS rejects the order (`responseCode != 200`) | `App_Exception_Business` → Logs Issue/Event | **Data/UI change.** Add a row to `Logs.IssueEmailAddress` against the issue — no code edit |
+| **USA** — "MITS API Script Error: No Items Found" | in-cron `App_Email_Agilant` | edit `addTo()` in the cron |
+| **Canada** — "No Items Found" | in-cron `App_Email_Agilant` | edit `addTo()` in the cron |
+| **Canada** — "Sales Order Items are more than 15" | in-cron `App_Email_Agilant` | edit `addTo()` in the cron |
+| **Canada** — "Invalid response from MITS API" (the rejection path) | in-cron `App_Email_Agilant` | edit `addTo()` in the cron |
 
-**Consequence for anyone handed a ticket like "add <person> to the MITS error emails": there is
-no PHP to change.** It is a one-row data change delivered as a `dbchanges2/Logs/` migration.
+So the USA cron is a **hybrid**: its rejection path is issue-routed, but it still holds one
+hardcoded email for the no-items case. Only the rejection branch was migrated.
 
-## How it works
+Both crons are live — `worker/schedules/cron.worker.sync.json` schedules
+`toga2/compass/workflow/1_...` and `toga2/compasscanada/workflow/1_...`. (Per the
+[ODP pipeline doc's](../workflows/odp-order-pipeline-to-netsuite.md) rule, a grep hit under
+`crons/toga2/**` is not proof a script runs — these two were verified against the schedule.)
+
+**Current recipients on every in-cron email above:** `devteam@togatech.com` +
+`vburks@togatech.com` (business stakeholder, added 2026-08-31).
+
+## How the USA rejection path works
 
 - The cron raises
   `throw new App_Exception_Business('COMPASS_SALES_ORDER_MITS_TRANSMIT_REJECTED', …, URGENCY_HIGH)`
   on a MITS rejection. (Before 2026-08-03 this block was a hardcoded `new App_Email_Agilant()`
-  with `addTo('devteam@togatech.com')`.)
-- Capture creates/dedupes a `Logs.Issue` keyed on the `issueKey`, and the worker2
-  `Infrastructure/Errors/Escalate` cron does all outbound notification — business email to the
-  configured recipients **and**, independently, the dev-team ClickUp task. See
+  with `addTo('devteam@togatech.com')` — i.e. exactly what Canada still does.)
+- Capture creates/dedupes a `Logs.Issue` keyed on the `issueKey`, so repeated rejections are
+  **one issue with an occurrence count**, not one email per failure. It is visible to internal
+  staff in the Tools `/errors` console.
+- The worker2 `Infrastructure/Errors/Escalate` cron does all outbound notification — business
+  email to the configured recipients **and**, independently, the dev-team ClickUp task. See
   [error-escalation-cron](../../../2.0/apps/worker2/features/error-escalation-cron.md).
 - Recipients live in `Logs.IssueEmailAddress` (FK `issueId` → `Logs.Issue`), scoped by
   `clientId` (`0` = all clients).
 
-### Adding a recipient (the correct pattern)
+### Adding a recipient — two routes
+
+**Route 1 (preferred): the Tools `/errors` console.** `tools/mvc/errors/post.php` exposes
+`add-recipient` / `delete-recipient`, which write `IssueEmailAddress`
+(`uuid, issueId, clientId, emailAddress, toCcBcc`) and set `Issue.isManaged = 1`. `clientId = 0`
+requires an explicit second confirmation checkbox, because one mistyped `0` silently sends one
+client's business users every other client's error content. See
+[errors-curation-console](../../../1.0/apps/tools/features/errors-curation-console.md).
 
-Write a `dbchanges2/Logs/YYYY-MM-DD<letter>` migration that:
+**Route 2: a `dbchanges2/Logs/YYYY-MM-DD<letter>` migration** — use this when the change must
+ride a deploy across environments. It must:
 
-1. **Looks the issue up by `issueKey`**, never by its `id`. The id is assigned on the issue's
+1. **Look the issue up by `issueKey`**, never by its `id`. The id is assigned on the issue's
    **first occurrence** and is therefore not stable across environments.
-2. Uses **`clientId = 0`**. This `issueKey` is raised from a Compass-only code path, and an
+2. Use **`clientId = 0`**. This `issueKey` is raised from a Compass-only code path, and an
    occurrence recorded without client attribution resolves against scope `0` only — a row scoped
    to the Compass `clientId` can deliver nothing. (Never use `0` for an `issueKey` raised from
    shared code — that is a cross-tenant leak.)
-3. Is **idempotent** via `INSERT … WHERE NOT EXISTS`, mirroring the unique key
+3. Be **idempotent** via `INSERT … WHERE NOT EXISTS`, mirroring the unique key
    `uq_issue_client_address_type`.
 
 Configuration is **never retroactive**: `shouldNotify()` fires on the first occurrence, on
@@ -62,28 +102,49 @@ zero events. The first email lands on the **next live rejection**, not on existi
 
 ## Gotchas / known issues
 
-- **Do not "modernize" this alert back into the cron.** Migrating it to
+- **Canada is the pre-2026-08-03 design, and it still carries the two problems that migration
+  fixed.** Its "Invalid response from MITS API" email `print_r`s the **whole transmission
+  payload** into the body — which includes ship-to addressee, attention line, street address and
+  phone number — and there is no issue dedupe, so a bad run emails once per order. Treat
+  bringing Canada onto `App_Exception_Business` as known outstanding work, not a new idea; the
+  USA block is the reference implementation.
+- **Canada's alerts do not send where outbound email is disabled.** The USA no-items email sets
+  `sendEmailEvenIfOutboundEmailIsDisabled = true`; none of Canada's three do. On any environment
+  with outbound email off, Canada fails **silently**.
+- **Do not "modernize" the USA rejection alert back into the cron.** Migrating it to
   `_Model_Client_EmailTemplate::send` (or any in-cron email) reverts the move to the Issue/Event
   pipeline and removes the recipient configuration surface entirely.
-- **Never re-introduce the payload dump into the alert.** The original email included the
-  transmission payload, which carries ship-to addressee, attention line, street address and phone
-  number. The Issue message is stored in a table **shared across every client**, displayed to
-  internal staff in the Tools `/errors` console, pushed to ClickUp, and emailed — so the payload
-  was deliberately removed. Alerts here name the order, not the person.
-- **The MITS cron holds its API credentials inline in the file.** Treat that file as
+- **Never re-introduce the payload dump into the USA alert.** The Issue message is stored in a
+  table **shared across every client**, displayed to internal staff in the Tools `/errors`
+  console, pushed to ClickUp, and emailed — so the payload was deliberately removed. Alerts here
+  name the order, not the person. (This is precisely what Canada still does wrong.)
+- **The MITS crons hold their API credentials inline in the file.** Treat both files as
   secret-bearing when copying snippets anywhere (tickets, PR bodies, knowledge docs).
 - **Adding a recipient does not turn ClickUp ticketing off.** Routing is both-and, not
-  either-or — see the escalation-cron doc for the `elseif` bug this used to be.
+  either-or: `_Worker_Infrastructure_Errors` runs `if ($recipients !== null)` and
+  `if ((bool) $issue->createsClickupTask)` as **two independent** branches.
+  **⚠ The comment above the insert in `tools/mvc/errors/post.php` still claims the opposite**
+  ("it stops creating ClickUp tasks for the dev team and starts emailing these people
+  instead") — that describes the old `elseif` form and is **stale**. Trust `Errors.php`.
 - As of 2026-08-04 prod `Logs.IssueEmailAddress` is empty, so this is the **first business-routed
   issue on the platform**: `processBusinessIssue()` will execute in production for the first time
   when this issue next fires. Watch that run rather than assuming it works.
 
 ## Change history
+- 2026-08-31 — Added `vburks@togatech.com` alongside `devteam@togatech.com` on **every** in-cron
+  `App_Email_Agilant` alert in both MITS transmit crons (USA has one, Canada has three), so the
+  business stakeholder is alerted on transmission failures. Broadened this doc to cover **both**
+  tenants after finding they had diverged: the USA rejection path is Issue/Event-routed
+  (recipients configured against the issue, no `addTo()` to edit) while **Canada still uses the
+  old direct email** for the same branch — including the PII-bearing payload dump and with no
+  dedupe. Also recorded that the USA cron is a hybrid (its no-items alert is still an in-cron
+  email), that recipients can be managed from the Tools `/errors` console as well as a
+  `dbchanges2/Logs` migration, that Canada's alerts are suppressed wherever outbound email is
+  disabled, and that the stale `tools/mvc/errors/post.php` comment misstates ClickUp-vs-email
+  routing. (bala)
 - 2026-08-04 — Documented that MITS rejection alerting moved (worker `5521854b`, 2026-08-03) from a
   hardcoded in-cron `App_Email_Agilant` to `App_Exception_Business` +
   `Logs.IssueEmailAddress` recipients, so adding an alert recipient is a data change, not a code
   change. Recorded the deliberate removal of the PII-bearing payload dump from the alert, the
   look-up-by-`issueKey` / `clientId = 0` / `NOT EXISTS` migration pattern, and that recipient
   configuration only takes effect on the next live occurrence. (dfranks)
-</content>
-</invoke>

package/package.json

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