toga-ai 1.0.1187 → 1.0.1189

package/knowledge/2.0/apps/toga2-commerce/features/order-submit-sync-sequencing.md

@@ -6,7 +6,7 @@ project: TOGa Commerce
 client: shared
 type: feature
 status: active
-updated: 2026-10-23
+updated: 2026-10-29
 owners: ["bala", "apeterson", "tcox"]
 files:
   - toga2-commerce/src/pages/OrderDetails/hooks/useSubmitOrder.ts
@@ -41,9 +41,9 @@ Submitting an order from the cart fires **two independent sync routines** — on
 
 `updateSalesOrderEmails()` runs **first** inside `syncSalesOrderData()`, so it is the earliest header request on the wire and the one that collides with the delete burst.
 
-### ⚠ Lines are NEVER sent nested on the order write — they go one request at a time
+### ⚠ On an edit, lines are NEVER sent nested on the order write — they go one request at a time
 
-This is the single most misread thing about this path. **Commerce does not post an order with its `salesOrderItems` inside it.**
+This is the single most misread thing about this path. **On `editOrder`, Commerce does not send the order with its `salesOrderItems` inside it.** New placement (`viewType=cart`) is the opposite: `createNewSalesOrderSubmit.ts` sends ONE `POST /v2/sales-orders` with `salesOrderItems` nested (`depth: -1`), no item sync.
 
 - `syncSalesOrdersDataFromLocalStorageCartToApi.ts` **line 20 `delete`s `salesOrderItems`** from the edit `PUT` payload outright.
 - `syncSalesOrderItemsFromLocalStorageCartToApi.ts` then writes lines **individually**:
@@ -100,6 +100,7 @@ Three changes, in `toga2-commerce`:
 - **There is NO success toaster on order placement — by design, not a bug.** `useSubmitOrder` calls `addToaster` **only in its `catch` block** (`status: 'error'`). Both success paths navigate away before anything could render: cart → `createNewSalesOrderSubmit()` → `navigate("/order-details?uuid=…&type=orderPlaced")` (no `addToaster` anywhere in it); edit-order → `window.location.href = getSupplyRedirectLink(orderUuid)`. **Consequence for debugging: placing an order is not a valid way to test toaster styling.** Use a path that stays mounted — add/edit shipping address (Cart or Account), Account → My Settings, or Cart → add new user; for the error variant, force a submit failure to hit the catch block. See [blox Toaster](../../toga-blox/features/toaster.md).
 
 ## Change history
+- 2026-10-29 — Scoped "never nested" to the edit path; new placement nests lines in one `POST /v2/sales-orders` (TRUE-83381). (bala)
 - 2026-10-23 — Price check before both submit paths (TRUE-82729, pending merge); see [cart price refresh](./cart-price-refresh.md). (tcox)
 - 2026-08-11 — Item sync before header sync, `depth: 1`, self-overwrite `PUT` dropped (TRUE-80551). (bala, apeterson)
 

package/knowledge/INDEX.md

@@ -23,7 +23,7 @@ _Auto-generated by `knowledge.js index`. Do not hand-edit._
 ## 2.0 framework
 
 - **_underscore** (_Underscore) _(framework core)_ — 117 doc(s) → [2.0/apps/_underscore/INDEX.md](2.0/apps/_underscore/INDEX.md)
-- **worker2** (Worker) — 101 doc(s) → [2.0/apps/worker2/INDEX.md](2.0/apps/worker2/INDEX.md)
+- **worker2** (Worker) — 102 doc(s) → [2.0/apps/worker2/INDEX.md](2.0/apps/worker2/INDEX.md)
 - **api2** (API) — 29 doc(s) → [2.0/apps/api2/INDEX.md](2.0/apps/api2/INDEX.md)
 - **dbchanges2** (Database Changes) _(framework core)_ — 24 doc(s) → [2.0/apps/dbchanges2/INDEX.md](2.0/apps/dbchanges2/INDEX.md)
 - **toga2-supply** (TOGa Supply) — 9 doc(s) → [2.0/apps/toga2-supply/INDEX.md](2.0/apps/toga2-supply/INDEX.md)

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

@@ -26,6 +26,7 @@
 | [Compass: NetSuite duplicate sales-order monitor (Monitor/Compass/NetsuiteDuplicateSalesOrders)](features/oneuptime-netsuite-duplicate-sales-orders-monitor.md) | 2.0 | worker2 OneUptime push monitor that queries NetSuite (SuiteQL) for Office Depot POs with more than one open NetSuite sales order; open when working on Compass d |
 | [Compass: Office Depot inbound AS2 files monitor (Monitor/Compass/OfficeDepotInboundFiles)](features/oneuptime-office-depot-inbound-files-monitor.md) | 2.0 | worker2 OneUptime push monitor that checks Office Depot 850/997 files are arriving over AS2 and are moved out of `agilant-as2/processed/` to the import folder; |
 | [Compass: Office Depot lost orders monitor (Monitor/Compass/OfficeDepotLostOrders)](features/oneuptime-office-depot-lost-orders-monitor.md) | 2.0 | worker2 OneUptime push monitor that alarms when cron 3a logged an Office Depot 850 in legacy `Logs.FileLog` but no ODP PurchaseOrder exists in `Client_Compass` |
+| [Compass USA: order placement errors monitor (Monitor/Compass/OrderPlacementErrors)](features/oneuptime-order-placement-errors-monitor.md) | 2.0 | worker2 OneUptime push monitor that alarms when a real Compass USA user gets an API error placing an order in TOGa Commerce (`POST /v2/sales-orders` >= 400 in ` |
 | [Compass USA + Canada — order fulfillment status (standard base per-line rule)](features/order-fulfillment-status-per-line.md) | 2.0 | How Compass USA and Canada compute Pending / Picked / Packed / Partially Fulfilled / Fulfilled (the standard base per-line rule since TRUE-79669) and why the ol |
 | [People File Import admin page (tools /compass/people-file-import → worker2)](features/people-file-import-admin-page.md) | 1.0 | Browser page that lists the Compass PEOPLE files on SFTP and runs the importer on demand; open before changing the page or the importer's listing/guard code. |
 | [Compass PEOPLE-File User Lifecycle (duplicate accounts, reactivation grace window, raw-SQL deactivation)](features/people-file-user-lifecycle.md) | 2.0 | The nightly Compass PEOPLE-file cron's Users-row lifecycle (insert/reactivate/deactivate), why it creates duplicate accounts, and its raw-SQL/index traps; open |

package/knowledge/clients/compass-usa/features/oneuptime-order-placement-errors-monitor.md

@@ -0,0 +1,52 @@
+---
+title: "Compass USA: order placement errors monitor (Monitor/Compass/OrderPlacementErrors)"
+framework: "2.0"
+repo: worker2
+project: Worker
+client: compass-usa
+type: client-feature
+status: active
+updated: 2026-10-29
+owners: ["bala"]
+files:
+  - worker2/Worker/Monitor/Compass.php
+  - toga2-commerce/src/pages/OrderDetails/helpers/createNewSalesOrderSubmit.ts
+related:
+  - ../../../2.0/apps/worker2/features/oneuptime-worker2-monitoring.md
+  - ../../../2.0/apps/api2/features/request-logging.md
+  - ../../../2.0/apps/toga2-commerce/features/order-submit-sync-sequencing.md
+  - ./oneuptime-office-depot-lost-orders-monitor.md
+  - ../profile.md
+---
+worker2 OneUptime push monitor that alarms when a real Compass USA user gets an API error placing an order in TOGa Commerce (`POST /v2/sales-orders` >= 400 in `Logs_Compass.Api`); open when it alarms, when tuning it, or when a Compass user says checkout failed.
+
+## Summary
+`Monitor/Compass/OrderPlacementErrors` (worker2 `_Worker_Monitor_Compass`, TRUE-83381). `Core.CronJobs` schedule `*/10 * * * *`, `maxExecutionTime` 120. OneUptime heartbeat monitor **"Compass USA Order Placement Errors"**: degraded after 25 min, down after 35 min with no push. Follows the shared [OneUptime push-metric pattern](../../../2.0/apps/worker2/features/oneuptime-worker2-monitoring.md); the push URL is an in-method local and a credential (not recorded here).
+
+Why: Commerce shows the user the error and tells nobody else, so the team heard only when Compass reported it. Baseline 30 days to 2026-10-28: 1,748 good user order POSTs, 9 failed (7 by one user in 3 minutes on 2026-10-20, `EV` "error while trying to locate the references for the specified field"; 1 on 10-13; 1 on 10-05 "error while attempting to save the data model").
+
+## How it works
+1. Registers `Logs_Compass` (the Logs cluster, `_Config::databaseLogs()`) in-method and calls `_Database::resetQueryCache()` (same SQL every run).
+2. Reads `Logs_Compass.Api`, `dtStamp` window **11 to 1 minutes ago** (10-minute lookback = the cron interval, so no gaps; shifted 1 minute back so a still-running call is not counted as a crash). `dtStamp` is indexed and leads the filter.
+3. Filters: `method = 'POST'`, `route = '/v2/sales-orders'`, `userId IS NOT NULL` (a person, not an API key), `requestPayload LIKE` the Compass customer uuid `4e480554-0c85-11ef-8e3b-0aae2980db55` (`Client_Compass.Customers.id 2` "Compass", the storefront customer), `responseCode >= 400 OR NULL` (NULL = the call crashed).
+4. Any row → `alarm: HIGH`, else `OK`. Clears itself on the next clean window.
+
+Payload: `status`, `alarm`, `reason`, `failedCount`, `affectedUserCount`, `failures` (max 20 lines: `dtStamp`, user name from `responsePayload.audience.user`, route, code, `messages[0].message` cut to 200 chars), `lookbackMinutes`, `checkedAtUtc`.
+
+**No try/catch** (team choice): a DB failure throws, no push goes out, and the heartbeat goes degraded/down. A failed push only logs the HTTP code (never the URL).
+
+Decisions (2026-10-29, with bala): every 10 minutes, 10-minute lookback; customer 2 storefront orders only; integration-key failures left out (API keys `apiId` 1/2 post standalone `/v2/sales-order-items` and have their own owners).
+
+## Gotchas
+- **Filter by the customer uuid inside `requestPayload`, not by `SalesOrders.customerId`.** A failed order writes no `SalesOrders` row, and `Logs_*` is a different cluster from `Client_Compass` (no join). The `LIKE` is cheap only because the `dtStamp` window is 10 minutes; an unbounded route/payload scan over 30 days timed out ([request-logging query rules](../../../2.0/apps/api2/features/request-logging.md)).
+- **New placement nests the lines in `POST /v2/sales-orders`** (`createNewSalesOrderSubmit.ts`, `salesOrderItems` in the body), so one route covers checkout. **Order edits are not covered:** the edit path writes lines one at a time (`POST /v2/sales-orders/{uuid}/sales-order-items`, `PUT`/`DELETE /v2/sales-order-items/{uuid}`), see [order-submit sync](../../../2.0/apps/toga2-commerce/features/order-submit-sync-sequencing.md).
+- **Blind spot: a throw from a PRE interceptor leaves no `Api` row**, so that rejection never reaches this monitor ([request-logging](../../../2.0/apps/api2/features/request-logging.md)). A normal 400 is logged with the full response envelope; `audience.app` = "TOGa Commerce", `audience.user` = the user's display name.
+- `userId` is the token's user: a staff "view as" session logs under the Compass user's id, so a hit may be our own staff.
+
+## Change history
+- 2026-10-29 — Created: user `POST /v2/sales-orders` errors for customer 2, every 10 minutes (TRUE-83381). (bala)
+
+## Related
+- [OneUptime push-metric monitors for 2.0 workers](../../../2.0/apps/worker2/features/oneuptime-worker2-monitoring.md)
+- [V2 request logging](../../../2.0/apps/api2/features/request-logging.md)
+- [Office Depot lost orders monitor](./oneuptime-office-depot-lost-orders-monitor.md)

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

@@ -22,7 +22,7 @@ project: _Underscore
 client: compass-usa
 type: profile
 status: active
-updated: 2026-10-28
+updated: 2026-10-29
 owners: [jcardinal, bala, tcox, apeterson, dfranks, akhokhani, ajean, rgirish, amadda]
 files: []
 related:
@@ -60,6 +60,7 @@ related:
   - features/odp-edi-855-acknowledgement-and-overquantity-guard.md
   - features/odp-edi-file-retention-and-retry.md
   - features/oneuptime-office-depot-lost-orders-monitor.md
+  - features/oneuptime-order-placement-errors-monitor.md
   - ../../2.0/apps/worker2/features/compass-vip-support-importer.md
   - ../../2.0/apps/toga2-commerce/features/expedited-shipping-gating.md
   - ../../2.0/apps/toga2-commerce/features/category-tile-sort-order.md
@@ -137,6 +138,11 @@ separate, related client (see its own profile).
   rows across 110 bundles still on the Agilant twins produced a fresh bad order on every kit
   checkout. Fixed by restoring `BundleItems` in the complete catalog-fold reversal (fix is data, not
   frontend): [catalog-fold reversal](workflows/catalog-fold-reversal.md).
+- **Checkout API errors alarm in OneUptime (2026-10-29, TRUE-83381).** worker2
+  `Monitor/Compass/OrderPlacementErrors` checks `Logs_Compass.Api` every 10 minutes for a user
+  `POST /v2/sales-orders` >= 400 for customer 2 "Compass" (baseline: 9 failed vs 1,748 good in 30
+  days). Order edits and PRE-interceptor rejections are not covered:
+  [order placement errors monitor](features/oneuptime-order-placement-errors-monitor.md).
 
 ## Vendors & integrations
 - **Office Depot (ODP)** — vendor id 1. ASNs arrive via **cXML** (direct V2 API) and via the

package/knowledge/clients/nychh/features/transfer-order-notification-emails.md

@@ -6,10 +6,11 @@ project: Worker
 client: nychh
 type: client-feature
 status: active
-updated: 2026-10-16
+updated: 2026-10-29
 owners: ["bala", "rgirish", "jcardinal", "mhammontree"]
 files:
   - worker2/Worker/Client/Nychh/TransferOrderEmails.php
+  - worker2/Worker/Infrastructure/Email/Send.php
   - _underscore/Model/Nychh/TransferOrder.php
   - _underscore/Model/Nychh/ItemFulfillment.php
   - dbchanges2/Client_Nychh/2026-09-15a - TransferOrderEmails.sql
@@ -58,6 +59,8 @@ Rules that carry most of the risk:
 5. **Shipped fires on the first TRACKING NUMBER, never on the NetSuite shipped stage** (since
    2026-10-05). The warehouse often marks a fulfillment shipped only after delivery, so the stage is
    unreliable. No tracking → no Shipped email, even at stage shipped. See below.
+6. **Shipped is RE-SENT when a new tracking number lands after it** (since 2026-10-21, TRUE-82673).
+   Same template and subject, so the customer reads it as a duplicate. See *Shipped resend*.
 
 Recipient is `DevTeam@togatech.com` while testing. `2026-09-15b` swaps it to
 `EndUserDeviceLifecycle@nychhc.org` — run that file only after sign-off.
@@ -68,10 +71,14 @@ Recipient is `DevTeam@togatech.com` while testing. `2026-09-15b` swaps it to
   - `SendSubmitted(string $transferOrderUuid)` — queued from the TransferOrder `postPut`.
   - `SendFulfillment(string $itemFulfillmentUuid)` — queued from the ItemFulfillment hooks.
   - `SendPending(bool $dryRun = true)` — the `*/5` backstop cron.
-  - `resolveStagesStillToAnnounce(stageName, stageAlreadyEmailed, hasTrackingNumber)` — which
-    stages are still owed (see *Shipped = tracking number*).
+  - `resolveStagesStillToAnnounce(stageName, stageAlreadyEmailed, hasTrackingNumber,
+    hasTrackingAddedSinceEmail)` — which stages are still owed (see *Shipped = tracking number*).
   - `buildHasTrackingNumberSql()` — the one "has tracking" test, shared by
     `readItemFulfillmentForEmail()` (`hasTrackingNumber` column) and the `SendPending` sweep.
+  - `buildHasTrackingAddedSinceEmailSql()` — the one "tracking arrived after the last Shipped email"
+    test, shared the same way (`hasTrackingAddedSinceEmail` column + sweep). See *Shipped resend*.
+  - `readTrackingForEmail(itemFulfillmentId, isAddedSinceLastEmailOnly, addedUpToDateTime)` — all
+    numbers on the first Shipped, only the new ones on a resend.
   - `readLinesMissingAssetTags()` / `sendPackedExceptionEmail()` — the asset-tag hold.
   - `initialize()` registers the client DB before any query runs.
   - Builders: `buildItemRowsHtml()`, `buildTrackingSectionHtml()`, `buildAssetTagTableHtml()`,
@@ -131,7 +138,8 @@ they must stay in step: the Submitted guard, the order read, and both `SendPendi
    `c_dtTransferOrderSubmittedEmailSent` marker, sends, then stamps the marker.
 2. **Packed / Shipped** — the ItemFulfillment `postPost` / `postPut` queue `SendFulfillment` with
    the fulfillment uuid. The stage reached is recorded on `c_transferOrderEmailStageSent`, with
-   `c_dtTransferOrderEmailSent` as the timestamp, so a fulfillment cannot re-announce a stage.
+   `c_dtTransferOrderEmailSent` as the timestamp, so a fulfillment cannot re-announce a stage
+   (one exception: the Shipped resend).
    `resolveStagesStillToAnnounce()` decides what is owed (table in *Shipped = tracking number*).
    When packed was never announced and shipped is now owed it returns **`[packed, shipped]`**, both
    sent in that order in one run — the **asset-tag check lives on packed**, so packed must never be
@@ -139,7 +147,8 @@ they must stay in step: the Submitted guard, the order read, and both `SendPendi
    sync is a **daily** cron, so a fulfillment landing fully shipped/tracked is normal — see
    [the per-client sync](../../../1.0/apps/worker/features/netsuite-togasupply-per-client-sync.md).
 3. The **backstop cron** sweeps anything the hooks missed (below).
-4. All three paths share the same markers, so nothing sends twice.
+4. All three paths share the same markers, so nothing sends twice by accident (the Shipped resend
+   is on purpose).
 5. The worker renders the stored `EmailTemplates` body, fills `{orderItems}` and
    `{trackingSection}` itself, and sends through `_Model_Client_EmailTemplate`.
 
@@ -173,7 +182,8 @@ PUT follows.** Fulfillment **2704** in production: header row at 20:33:09, lines
 
 | Marker (`c_transferOrderEmailStageSent`) | Tracking | Stage | Owed |
 |---|---|---|---|
-| `shipped` | any | any | nothing |
+| `shipped` | added since last email | any | `[shipped]` again (resend) |
+| `shipped` | otherwise | any | nothing |
 | `packed` | yes | any | `[shipped]` |
 | empty | yes | any (incl. picked — tracking means boxed) | `[packed, shipped]` |
 | empty | no | packed / shipped | `[packed]` |
@@ -181,16 +191,58 @@ PUT follows.** Fulfillment **2704** in production: header row at 20:33:09, lines
 
 The asset-tag hold runs whenever packed is owed and blocks both.
 
-- **⚠ `SendPending` WHERE must match that table:** marker NULL or `<> 'shipped'` AND (has tracking OR
-  (stage IN packed/shipped AND `COALESCE(marker,'') = ''`)). Drift → rows picked then skipped, eating
-  `LIMIT 25`.
+- **⚠ `SendPending` WHERE must match that table:** (marker NULL or `<> 'shipped'` AND (has tracking OR
+  (stage IN packed/shipped AND `COALESCE(marker,'') = ''`))) OR (marker = `shipped` AND
+  `buildHasTrackingAddedSinceEmailSql()`). Drift → rows picked then skipped, eating `LIMIT 25`.
 - **Why the cron, not the hook, sends Shipped:** library `syncItemFulfillmentFromNetsuite`
   (`library/app/api/toga2.php`) PUTs the stage first (~L7270), then units/asset tags, and writes
   package tracking **last** (~L8046). The ItemFulfillment `postPut` job runs before tracking exists.
   (Also removes the old race where Shipped read stale tracking/tags.) Tracking imports at picked,
   packed or shipped alike.
-- **Once per fulfillment.** Business rule = 1 tracking number per fulfillment; prod has violations
-  (IF 329047 has 2; IFs 329944/330013 share 1). Still sends once — the marker gates it.
+- **Once per fulfillment, plus one resend per NEW tracking number.** Business rule = 1 tracking number
+  per fulfillment; prod has violations (IF 329047 has 2; IFs 329944/330013 share 1). Numbers present at
+  the first Shipped all go in that one email. A number that arrives later re-sends Shipped — see
+  *Shipped resend*.
+
+### Shipped resend when tracking changes (TRUE-82673, live 2026-10-21)
+
+worker2 `c4d5008` + `1a1e3a0`, PR #193. Built for a warehouse re-keying a mistyped number.
+
+- **Trigger** = `buildHasTrackingAddedSinceEmailSql()`: a linked `TrackingNumbers` row with
+  `dtCreated > ItemFulfillments.c_dtTransferOrderEmailSent`. The sync POSTs a new `TrackingNumbers`
+  row for a number the client has never used, so `dtCreated` = arrival. A number the client already
+  holds is reused with its OLD `dtCreated`, so re-attaching an existing number is NOT announced.
+- **Cutoff, not NOW().** `SendFulfillment()` reads DB time first (`$trackingCutoff`), uses it as the
+  upper bound for the tracking read, and stores it as `c_dtTransferOrderEmailSent`. A number landing
+  mid-send is still newer than the marker, so the next run announces it.
+- **Body lists only the new number(s)** (`isAddedSinceLastEmailOnly`). The old number stays linked in
+  `ItemFulfillments_TrackingNumbers` (the sync needs it) but is left out of the email.
+- **⚠ Same template, same subject ("Order Shipped: N items"), same wording.** Nothing says it is a
+  correction, so the customer reports it as a duplicate. Expected behavior, not a bug.
+
+### Triage: customer reports a duplicate Shipped email
+
+Read-only prod, in order:
+
+1. `Client_Nychh.TransferOrders` by `number` LEFT JOIN `ItemFulfillments` ON `transferOrderId` →
+   `c_transferOrderEmailStageSent`, `c_dtTransferOrderEmailSent` per fulfillment.
+2. `Logs_Nychh.Email WHERE INSTR(body, '<TO number>') > 0` → every email for the order, with `to`,
+   `cc`, `bcc`, `dtSent` (columns are `to`/`cc`/`bcc`, not `toAddresses`).
+3. `ItemFulfillments_TrackingNumbers` JOIN `TrackingNumbers` for the IF → compare each
+   `TrackingNumbers.dtCreated` with `c_dtTransferOrderEmailSent`. A later number = the resend.
+4. Two copies of the SAME email (same number, same minute): `Core.WorkerJobs WHERE
+   action = 'Infrastructure/Email/Send/Run'` around `dtSent` (cron `Core.CronJobs` id 37). One run =
+   we sent it once; the second copy came from the client side.
+
+- **toga-db MCP rejects `REPLACE()`** as a forbidden keyword. Use `INSTR(body,'x') > 0`.
+- **Real case, TRUE-83389 (2026-10-29):** TO 294663 (`TransferOrders.id` 2071), one IF 333376
+  (`ItemFulfillments.id` 3104). Shipped #1 = Email 198, 2026-10-26 17:26, tracking `30494276`
+  (TrackingNumbers 4059). NetSuite re-keyed it to `34094276` (TrackingNumbers 4063, created
+  2026-10-29 08:36, carrier 101 New York Minute) → Shipped #2 = Email 204, 08:41, only the new
+  number. Both bridges (4211, 4215) stay linked. The "04"→"40" swap looks like a typo fix (inferred).
+  The client's two screenshots were both Email 204, sent in one Email Send run at 08:41:45, so the
+  doubled copy came from their side (To `EndUserDeviceLifecycle@nychhc.org` + CC
+  `HealthcareteamNYCHHC@togatech.com` reaching one person is a guess, not proven).
 - **Lag:** adding tracking in NetSuite bumps the IF `lastmodifieddate`, so the sync re-reads it, but
   only on the NYCHH sync interval (daily). E.g. IF 330377 (NS 7566823) still Packed (status B) in
   NetSuite, tracking imported 2026-10-05 11:56.
@@ -417,6 +469,9 @@ loaded out of the dbchanges2 file so an unresolved `{placeholder}` fails a test.
 unescaped values and both detail-box defects were all found there, not in production.
 
 ## Change history
+- 2026-10-29 — Recorded the Shipped resend on a new tracking number (TRUE-82673, live 2026-10-21) and
+  the duplicate-email triage steps, from TRUE-83389 (TO 294663). Investigation only, no code change.
+  (bala)
 - 2026-10-16 — Linked the emails-owed monitor (TRUE-82758). (mhammontree)
 - 2026-10-09 — **New York Minute shows its logo, and NON_SERIALIZED lines are ignored by the asset-tag
   reads** (TRUE-82527). `CARRIER_LOGO_URL_BY_CARRIER_NAME` gained `NEW YORK MINUTE` (no tracking site,

package/package.json

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