toga-ai 1.0.238 → 1.0.240

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

@@ -5,7 +5,7 @@
 | [Worker (1.0 Framework) Architecture](architecture.md) | `worker` is the legacy (**1.0** `App_` framework) **background-job tier**. | worker/index.php, worker/_/app/framework.php, worker/crons/, worker/schedules/, worker/ebs/cron.worker.php, worker/.ebextensions/035_cron.worker.config |
 | [Compass MA Sales Order Exception Report](features/compass-ma-sales-order-exception-report.md) | A worker cron that emails operations the "Compass Refresh Exception Report" — Compass `MA%` sales orders whose corresponding Office Depot (ODP) sales order has | worker/crons/toga2/compass/workflow/7_generate_ma_sales_order_exception_report.php |
 | [Compass Partial In-Transit & Delivered Emails (per package)](features/compass-partial-in-transit-delivered-emails.md) | Compass USA and Compass Canada send a **per-package** in-transit email (and a matching delivered email) instead of one email listing the whole order. | worker/crons/toga2/compass/update_salesorder_status_from_odp.php, worker/crons/toga2/compasscanada/workflow/3_update_salesorder_status_from_grand_and_toy.php |
-| [Forecast2 ↔ NetSuite Reconciliation & Trueup Tooling](features/forecast2-netsuite-reconciliation.md) | CLI tools to **audit** and **repair** drift between the production `Forecast` DB (core2) and NetSuite. | test/@dave/checker.php, test/@dave/looper.php, test/@dave/reconcile_netsuite_totals.php, test/@dave/fixer.php, test/@dave/analyze_netsuite_forecast_diff.php, test/@dave/trueup_sales.php, test/@dave/trueup_open_orders.php, test/@dave/loop_trueup_open_orders.php, test/@dave/trueup_opportunities.php, test/@dave/probe_sales_gap_direct.php, test/@dave/probe_missing_oo_timing.php, test/@dave/probe_missing_oo_createdby.php, test/@dave/probe_drift_so_dates.php, test/@dave/probe_profit_invoices.php, test/@dave/probe_profit_gap.php, worker/crons/toga2/forecast2/common_import_sales_from_netsuite.php, worker/crons/toga2/forecast2/periodic_forecast_discrepancy_fix_open_orders.php, worker/crons/toga2/forecast2/import_open_orders.php, worker/schedules/cron.worker.infrastructure.json |
+| [Forecast2 ↔ NetSuite Reconciliation & Trueup Tooling](features/forecast2-netsuite-reconciliation.md) | CLI tools to **audit** and **repair** drift between the production `Forecast` DB (core2) and NetSuite. | test/@dave/checker.php, _underscore/Component/Forecast/SaleImport/SaleImport.php, test/@dave/looper.php, test/@dave/reconcile_netsuite_totals.php, test/@dave/fixer.php, test/@dave/analyze_netsuite_forecast_diff.php, test/@dave/trueup_sales.php, test/@dave/trueup_open_orders.php, test/@dave/loop_trueup_open_orders.php, test/@dave/trueup_opportunities.php, test/@dave/probe_sales_gap_direct.php, test/@dave/probe_missing_oo_timing.php, test/@dave/probe_missing_oo_createdby.php, test/@dave/probe_drift_so_dates.php, test/@dave/probe_profit_invoices.php, test/@dave/probe_profit_gap.php, worker/crons/toga2/forecast2/common_import_sales_from_netsuite.php, worker/crons/toga2/forecast2/periodic_forecast_discrepancy_fix_open_orders.php, worker/crons/toga2/forecast2/import_open_orders.php, worker/schedules/cron.worker.infrastructure.json |
 | [NetSuite → TOGa Supply Per-Client Sync (thin wrappers)](features/netsuite-togasupply-per-client-sync.md) | Syncs NetSuite transactions (sales orders, purchase orders, invoices, item receipts, item fulfillments, inventory adjustments) into each TOGa Supply (2.0) clien | worker/crons/toga2/netsuite/common_sync_togasupply.php, worker/crons/toga2/netsuite/sync_togasupply_canon.php, worker/schedules/cron.worker.sync.json, dbchanges2/_modules/netsuite/2026-04-01 - Parameters.sql |
 | [Prudential: Send Shipments for the Day report (daily cron)](features/send-shipments-for-the-day.md) | Daily cron (9:00 PM) that emails Prudential and Dell stakeholders an Excel report of all devices shipped that day, including tracking number, serial number, emp | worker/crons/notifications/reports/send_shipments_for_the_day.php |
 | [Onboarding a Client to the NetSuite TOGa Supply Sync](workflows/onboarding-client-to-netsuite-togasupply-sync.md) | How to add a new TOGa 2 client to the per-client NetSuite → TOGa Supply importer (`worker/crons/toga2/netsuite/`). | worker/crons/toga2/netsuite/sync_togasupply.php, worker/crons/toga2/netsuite/common_sync_togasupply.php, worker/schedules/cron.worker.sync.json, dbchanges2/_modules/netsuite/2026-04-01 - Parameters.sql |

package/knowledge/1.0/apps/worker/features/forecast2-netsuite-reconciliation.md

@@ -6,10 +6,11 @@ project: Worker
 client: shared
 type: feature
 status: active
-updated: 2026-06-29
+updated: 2026-06-30
 owners: [dfranks]
 files:
   - test/@dave/checker.php
+  - _underscore/Component/Forecast/SaleImport/SaleImport.php
   - test/@dave/looper.php
   - test/@dave/reconcile_netsuite_totals.php
   - test/@dave/fixer.php
@@ -32,6 +33,7 @@ related:
   - ../architecture.md
   - ../../library/features/netsuite-suiteql-rest-shim.md
   - ../../library/features/netsuite-suiteql-api-reference.md
+  - ../../_underscore/features/forecast-sale-import.md
 ---
 
 ## Summary
@@ -202,6 +204,47 @@ by reconciling a chosen tranDate range directly against NetSuite.
   on `tranDate`, not NS `lastmodifieddate`, so a **symmetric** lastmodified fingerprint isn't possible — it
   would require NS-pull-then-id-lookup or the recency-pruned approach.
 
+- **JOURNAL ENTRIES are reconciled WITHIN the SALES category, not as a separate category (TRUE-79862
+  architecture decision, dfranks).** A JE is **not its own reconciliation category** — JE rows live in
+  the **same `Forecast.Sales` table** as the four sale types (`netsuiteTransactionType='journalEntry'`),
+  written by the same `_Component_Forecast_SaleImport` importer (see the sale-import doc's *JournalEntry
+  import* section). So the **sales pass covers the WHOLE `Sales` table**, sale-types + JEs together:
+  - **`fixer.php`** — `findSalesDiscrepancies` merges, on the **NS side**, the sale-type per-line aggregate
+    with `journalEntryNsTotals()` (a GL-account-grouped JE helper); the **FC side reads ALL `Sales` rows**
+    (no type filter); each discrepancy is tagged **`kind` (`'sale'` | `'je'`)**. The FIX dispatch routes
+    sale ids to `fixSales()` and JE ids to `fixJournalEntries()`. The per-corrector DELETE scoping stays
+    **per-type** (`fixSales` delete-candidates scoped to the 4 sale types; `fixJournalEntries` scoped to
+    `'journalEntry'`) so neither corrector deletes the other's rows.
+  - **`checker.php`** — the sales `nsSub` is a **`UNION ALL`** of the sale-type arm and a JE arm; the sales
+    `fcSub` reads **all `Sales` rows**. checker needs **no per-item/JE-specific logic** because its
+    fingerprint compares per-transaction (per-id) totals + the id-set, which are **item-agnostic**.
+- **JE→`Forecast.Sales` reconciliation math + scope (mirrors `_Component_Forecast_SaleImport::buildJournalEntryRows`).**
+  Only JE lines posting to the revenue/cost **account-NUMBER allowlist** are sales-relevant: revenue
+  `41100/41300/41500`, cost `51100/51200` (exact-number, never prefix — see the sale-import doc for the
+  sub-account traps). `revenue = Σ(−foreignamount)` over revenue-acct lines; `profit = Σ(−foreignamount)`
+  over **all** allowlisted lines (cost lines net profit down via debit-positive `foreignamount`). Group by
+  **(local salesRep, item)** → one Sales row per group; synthetic `lineNumber` from
+  `ksort(json_encode([salesRepId,itemId]))` then `1..N` — **fixer MUST key identically** or its upsert
+  dupes against the webhook importer's rows. JE `foreignamount`s are **cent-precision**, so a per-JE
+  sum-then-round equals the importer's per-salesRep round-then-sum **exactly** — this is what keeps
+  checker's "in sync" == fixer's "nothing to fix" for JEs (the compute-identically invariant applied to JEs).
+  Scope facts: of **~1235 JEs** in 2025-01-01..present, only **~295** touch a revenue/cost account; **~34**
+  of those net to **0 rev AND 0 profit** and import no rows. JEs hitting only bank/equity/tax/AP accounts
+  are correctly excluded **by design** (e.g. JE 7213407 = a Bank↔Equity reclass, 0 allowlist lines → never
+  imported — not a miss). An accrual JE and its NetSuite auto-reversal are **separate transactions**, each
+  reconciled independently by its own `internalId`.
+- **JE item dimension is NULL today; here is how to enable it later.** `itemId` is null on JE Sales rows
+  because the JE import path reads item **only** via the configurable `JE_LINE_ITEM_FIELD` (currently null)
+  — it does **not** read native `transactionline.item`, so even a populated native `tl.item` would NOT flow
+  through. To enable: (1) set `JE_LINE_ITEM_FIELD` to the source field (`'item'` for native, or a
+  `custcol_*` if a custom column is added) — `journalLineLookup` then resolves it via
+  `lookupId('Items','netsuiteItemInternalId',…)` and the group key already carries the item slot; AND (2)
+  update **`fixer.php`** to SELECT the item column in its JE SuiteQL, resolve NS item→local id (reuse
+  `createMissingForecastItemFromNetSuite` self-heal), and extend the group key to `(salesRep, item)`.
+  **`checker.php` needs no change.** Consider whether item should self-heal (salesRep does **not** — see
+  the sale-import doc). The salesRep dimension itself is the JE line custom column `custcol_sales_rep_line`
+  (wired under TRUE-79862).
+
 ## Data model
 
 `Forecast.Sales`, `Forecast.OpenOrderItems` on the **core2** cluster
@@ -214,6 +257,16 @@ None — Forecast2 is a single shared dataset.
 
 ## Gotchas / known issues
 
+- **CROSS-TYPE CONTAMINATION: once JEs share `Forecast.Sales`, any FC Sales read missing a type scope
+  treats JE rows as rogue sales.** Discovered live (TRUE-79862): the SALES fix **deleted 74 JE rows
+  (8 JEs) as "stale sales"** because `findSalesDiscrepancies`'s FC query had **no type filter**, so JE
+  rows looked like FC-only sales that the NS-sales aggregate never returns. **Correct resolution is NOT
+  to filter JEs OUT of the sales pass** — it is to reconcile the **whole table together** (NS side =
+  sale-types `UNION` JE; FC side = all rows) and **route the FIX by `kind`** (`'sale'`→`fixSales`,
+  `'je'`→`fixJournalEntries`), keeping each corrector's DELETE scoping per-type so neither deletes the
+  other's rows. (See the JE-within-Sales architecture under *How it works*.) General lesson: when two
+  transaction families share one table, an audit read with no type scope manufactures phantom FC-only
+  deltas for the other family.
 - **An NS-DELETED invoice leaves STALE cost-only `Forecast.Sales` rows the add/update-only import can
   never remove.** The 5-min `import_sales.php` cron is **add/update-only — it has no delete path** (only
   the nightly discrepancy-fix deletes). So when an invoice is **deleted in NetSuite**, its already-imported
@@ -420,6 +473,24 @@ None — Forecast2 is a single shared dataset.
 
 ## Change history
 
+- 2026-06-30 — **Folded JOURNAL ENTRIES into the SALES reconciliation in `fixer.php` + `checker.php`
+  (TRUE-79862).** Architecture decision (dfranks): a JE is **not its own category** — JE rows live in the
+  same `Forecast.Sales` table (`netsuiteTransactionType='journalEntry'`) as the four sale types, so the
+  sales pass reconciles the **whole table**. `fixer.findSalesDiscrepancies` merges the NS sale-type
+  aggregate with `journalEntryNsTotals()`, reads ALL FC Sales rows, tags each diff `kind` (`sale`|`je`),
+  and routes the FIX (`fixSales`/`fixJournalEntries`) with per-type DELETE scoping. `checker`'s sales
+  `nsSub` becomes a `UNION ALL` (sale-types + JE) over all FC Sales rows — no JE-specific logic since its
+  fingerprint is per-id/item-agnostic. **Gotcha recorded: cross-type contamination** — the initial
+  un-typed FC Sales read deleted 74 JE rows (8 JEs) as "stale sales"; fixed by reconciling the families
+  together + routing by kind, not by filtering JEs out. **JE math/scope** (mirrors
+  `buildJournalEntryRows`): allowlist accts 41100/41300/41500 rev + 51100/51200 cost; group by
+  (salesRep,item) with `ksort(json_encode([salesRep,item]))` synthetic lineNumber — fixer keys identically
+  to the importer or it dupes; cent-precision foreignamounts make sum-then-round == importer round-then-sum
+  (compute-identically holds for JEs). Of ~1235 JEs (2025→present) only ~295 hit a rev/cost acct, ~34 net
+  to $0 and import nothing; bank/equity/tax/AP-only JEs excluded by design (not misses). Accrual + NS
+  auto-reversal reconcile independently per internalId. **Item dimension is null today** (`JE_LINE_ITEM_FIELD`
+  null; native `tl.item` not read); enabling it needs the importer field set AND fixer SELECT/resolve/group-
+  by-(salesRep,item) — checker needs no change. (dfranks)
 - 2026-06-29 — **Recorded that `fixer.php`'s OOI path lacks `locationId`/`quantityBackordered`/
   `amountDue`** (planning for TRUE-79162). The Sales path already handles anchor-line `amountDue`
   behind a `forecastColumnExists('Sales','amountDue')` guard; the OpenOrderItems path (lookup SELECT,

package/knowledge/2.0/apps/toga2-commerce/INDEX.md

@@ -6,5 +6,6 @@
 | [Cart Notification Emails — duplicate prevention](features/cart-notification-emails.md) | On the cart "Notifications" section a user can add CC email addresses to an order. | src/pages/Cart/CartPage.tsx, src/pages/Cart/view/cartForm/CartForm.tsx, src/stores/useEmailOptionsStore.ts, src/stores/useCartSalesQuoteZu.ts, src/pages/Cart/viewModel/FIELDS/*/*/*/CARTPAGE.ts |
 | [Cart Page — config-driven form architecture (current state + planned refactor)](features/cart-page-config-architecture.md) | The Cart page (`src/pages/Cart/`) is the most config-heavy page in `toga2-commerce`. | src/pages/Cart/CartPage.tsx, src/pages/Cart/view/cartForm/CartForm.tsx, src/pages/Cart/view/cartForm/CartFormSection.tsx, src/pages/Cart/view/cartForm/CartFormRenderer.tsx, src/pages/Cart/view/EditCart.tsx, src/pages/Cart/view/EditOrder.tsx, src/pages/Cart/viewModel/useEditOrderOrEditCartViewModel.ts, src/pages/Cart/viewModel/FIELDS/*/*/*/CARTPAGE.ts, src/hooks/useAssignClientFields.ts |
 | [Client Fields — per-tenant / language / role content & config](features/client-fields.md) | Almost no user-facing text, field layout, or page config is hard-coded in `toga2-commerce`. | src/fieldsConfig/index.ts, src/fieldsConfig/getClientLoginFields.ts, src/fieldsConfig/clientFields/COMPASS.json, src/fieldsConfig/clientFields/COMPASSCANADA.json, src/fieldsConfig/clientFields/QUAD.json, src/hooks/useAssignClientFields.ts, src/hooks/useDynamicConditionalFieldOptions.ts, src/stores/useFieldsStore.ts, src/components/BaseDetailField/BaseDetailField.tsx |
+| [Config-Driven Expedited Shipping Gating (Cart)](features/expedited-shipping-gating.md) | On the toga2-commerce **Cart** page, expedited shipping options (**"2nd Day EOB"** and **"Next Day Air"**) are only offered in the *Shipping Method* dropdown wh | toga2-commerce/src/pages/Cart/helpers/shippingOptionGates.ts, toga2-commerce/src/pages/Cart/viewModel/FIELDS/shared/shippingOptionGates.ts, toga2-commerce/src/pages/Cart/view/cartForm/CartForm.tsx, toga2-commerce/src/pages/Cart/CartPage.tsx |
 | [Multi-Tenant Resolution & Theming](features/multi-tenant-theming.md) | `toga2-commerce` serves multiple clients from one codebase. | src/themeConfig/themes.json, src/themeConfig/ThemeContext.tsx, src/themeConfig/types.ts, src/components/ThemeSwitcher/ThemeSwitcher.tsx, src/components/AuthLayout/AuthLayout.tsx, src/api/axiosInstance.ts, src/contexts/AuthContext.tsx, tailwind.config.js |
 | [AWS Amplify Build & Deploy (non-prod environments)](workflows/amplify-build-and-deploy.md) | How `toga2-commerce` (React + Vite, "commerce2-react") builds and deploys on **AWS Amplify**. | toga2-commerce/amplify.yml, toga2-commerce/.gitattributes, toga2-commerce/package.json, toga2-commerce/.github/workflows/sync-stage-environments.yml |

package/knowledge/2.0/apps/toga2-commerce/features/expedited-shipping-gating.md

@@ -0,0 +1,108 @@
+---
+title: Config-Driven Expedited Shipping Gating (Cart)
+framework: "2.0"
+repo: toga2-commerce
+project: TOGa Commerce
+client: shared
+type: feature
+status: active
+updated: 2026-06-30
+owners: [tcox]
+files:
+  - toga2-commerce/src/pages/Cart/helpers/shippingOptionGates.ts
+  - toga2-commerce/src/pages/Cart/viewModel/FIELDS/shared/shippingOptionGates.ts
+  - toga2-commerce/src/pages/Cart/view/cartForm/CartForm.tsx
+  - toga2-commerce/src/pages/Cart/CartPage.tsx
+related:
+  - ../../../../clients/compass-usa/profile.md
+  - ../../../../clients/compass-canada/profile.md
+---
+
+## Summary
+On the toga2-commerce **Cart** page, expedited shipping options (**"2nd Day EOB"** and
+**"Next Day Air"**) are only offered in the *Shipping Method* dropdown when the cart contains
+a **computer kit**. Otherwise they are filtered out of the options, and any previously
+selected expedited method auto-resets to **"Standard Ground"**. The behavior is **config
+driven** — a tenant opts in per shipping-method field via an `optionGates` entry; there is no
+`if (clientSlug === ...)` branching. Omitting `optionGates` means expedited is always shown.
+
+Applies today to all three tenants: **COMPASS**, **COMPASSCANADA** (English + French), and
+**QUAD**.
+
+## Key files / entry points
+- `src/pages/Cart/helpers/shippingOptionGates.ts` (NEW) — pure helpers + types:
+  `ShippingOptionGate` / `ShippingOptionRule`, `filterShippingOptionsByGates`,
+  `getHiddenShippingOptionNames`, `evaluateShippingOptionRule`, `findShippingMethodField`
+  (resolves the shipping field by `valueKey`, **not** by index), `getBaseShippingOptionName` +
+  `SHIPPING_OPTION_LABEL_SEPARATOR`, and `STANDARD_GROUND_SHIPPING_NAME`.
+- `src/pages/Cart/viewModel/FIELDS/shared/shippingOptionGates.ts` (NEW) — the
+  `EXPEDITED_SHIPPING_GATE` config constant: `optionNames` `["2nd Day EOB","Next Day Air"]`,
+  `visibleWhen { item: "primaryItem", path: "item.itemCategory.name", operator: "equals",
+  value: "COMPUTERS" }`.
+- 15 `CARTPAGE.ts` files (COMPASS x4 roles, COMPASSCANADA ENGLISH x4 + FRENCH x4, QUAD x3) —
+  each shipping-method field opts in via `optionGates: [EXPEDITED_SHIPPING_GATE]`.
+- `src/pages/Cart/view/cartForm/CartForm.tsx` — filters `shippingMethodOptions` through the
+  gates (reactive on `cartData.cartBundles`) before the select renders; resolves the shipping
+  field via `findShippingMethodField`; uses `SHIPPING_OPTION_LABEL_SEPARATOR` for the
+  cost-suffix label.
+- `src/pages/Cart/CartPage.tsx` — the warning-modal effect derives expedited names from the
+  config gates; a NEW auto-reset effect (guarded on `dirtyFields.shippingMethod` + loaded
+  options) resets a now-hidden expedited selection back to Standard Ground.
+
+## How it works
+1. The config layer (`EXPEDITED_SHIPPING_GATE`) declares which option names are gated and the
+   condition under which they are *visible* (`visibleWhen`). A shipping-method field opts in by
+   listing the gate in `optionGates`.
+2. A **"computer kit"** is identified by the bundle's **PRIMARY item** —
+   `bundleItemGroup.slug === "primary"` — having `item.itemCategory.name === "COMPUTERS"`. This
+   reuses the same `{ item, path, operator, value }` rule vocabulary as the existing bundle-page
+   one-per-order limit (`evaluateCartQuantityRestriction.ts` + `restrictedQuantity` in
+   `BUNDLEDETAILSPAGE.json` / `CartOverlay/Bundle.tsx`). `value` may be a string **or** a
+   `string[]`, so qualifying categories stay editable in config without code changes.
+3. Cart contents are sourced from `useCartStoreZu` (`cartData.cartBundles`), so detection
+   reacts to add/remove. A computer kit plus a non-computer item (printer/accessory) still
+   shows expedited; removing the kit hides it.
+4. `CartForm` runs `filterShippingOptionsByGates` over the fetched options before rendering the
+   select; `CartPage` runs the auto-reset effect so an already-chosen expedited method does not
+   silently survive once it is no longer offered.
+
+This mirrors the toga2.5 / toga25-supply "named rule" / config-driven cart pattern: tenant
+behavior is expressed in config, not in code branches.
+
+## Gotchas
+- **Compass MacBook catalog categorization is INCONSISTENT, and it breaks the computer-kit
+  assumption.** Verified in prod `Client_Compass.Items`: MacBooks are spread across at least
+  **four** categories — `"APPLE LAPTOP"` (e.g. 14" MacBook Pro M5, partNumber `MDE54LL/A-S`),
+  `"COMPUTERS"` (14"/16" MacBook Pro M4, `MW2W3LLA-S` / `MX2X3LLA-S`), `"MAC & ACCESSORIES"`
+  (~18 older M1/M2 MacBook Air/Pro models), and `"PDC NEW HIRE - APPLE"`. The gate matches
+  `itemCategory.name === "COMPUTERS"` **only**, so MacBooks tagged `APPLE LAPTOP` /
+  `MAC & ACCESSORIES` do **not** qualify for expedited shipping (and would not trigger the
+  one-per-order limit either). Confirmed live on beta and prod: the "Compass 14\" Macbook"
+  kit's primary item resolves to `APPLE LAPTOP`. The backend assumption (Alex) was that all
+  MacBooks were already `COMPUTERS`; the data shows otherwise. **Team decision this session:**
+  keep the rule keyed to `COMPUTERS` only (intended). The fix is **catalog data
+  normalization** (or extending the config `value` list to
+  `["COMPUTERS","APPLE LAPTOP"]`) — it is *not* a code gap. Hand the categorization to the
+  catalog/data team.
+- **The gate is UI-only, not server-enforced.** Shipping methods come from `/shipping-methods`
+  (UPS carrier, fetched in `useCartViewModel`) and are filtered client-side. The gate is a
+  selection restriction, not order validation. Follow-up recommended: enforce
+  expedited-requires-kit at order submission in **api2**.
+- **Only the top-level primary item is scanned.** Nested child-bundle items are not inspected
+  for the computer category (consistent with the existing `checkCartContainsComputerKit`
+  detector). Fine today, but a miss if a `COMPUTERS` item ever lives only in a nested child
+  bundle.
+- **No automated test was added.** The repo has no unit-test runner (Cypress only). Verified
+  via `tsc -b` (clean, twice) and an independent maker≠checker code review. ESLint could not
+  run locally (missing `eslint-plugin-react-compiler` — environment issue).
+
+## Change history
+- 2026-06-30 — Built config-driven expedited-shipping gating: expedited methods shown only
+  when the cart holds a COMPUTERS-category computer kit, with auto-reset to Standard Ground
+  otherwise; tenant opt-in via `optionGates` (no client-slug branching). Code review fixed 3
+  findings: fail-open index read → resolve field by `valueKey`; substring `.includes` match →
+  base-name compare via `getBaseShippingOptionName`; edit-order silent-downgrade/load race →
+  reset guarded on dirty + loaded options. Documented the Compass MacBook category
+  inconsistency as a known gotcha (data-normalization item, not a code gap). (tcox)
+</content>
+</invoke>

package/knowledge/INDEX.md

@@ -27,7 +27,7 @@ _Auto-generated by `knowledge.js index`. Do not hand-edit._
 - **talos** (TOGa IQ) — 7 doc(s) → [2.0/apps/talos/INDEX.md](2.0/apps/talos/INDEX.md)
 - **voice-to-voice** (TOGa Voice) — 4 doc(s) → [2.0/apps/voice-to-voice/INDEX.md](2.0/apps/voice-to-voice/INDEX.md)
 - **ai-bdr** (AI-BDR) — 4 doc(s) → [2.0/apps/ai-bdr/INDEX.md](2.0/apps/ai-bdr/INDEX.md)
-- **toga2-commerce** (TOGa Commerce) — 6 doc(s) → [2.0/apps/toga2-commerce/INDEX.md](2.0/apps/toga2-commerce/INDEX.md)
+- **toga2-commerce** (TOGa Commerce) — 7 doc(s) → [2.0/apps/toga2-commerce/INDEX.md](2.0/apps/toga2-commerce/INDEX.md)
 - **toga25-supply** (TOGa 2.5 Supply) — 7 doc(s) → [2.0/apps/toga25-supply/INDEX.md](2.0/apps/toga25-supply/INDEX.md)
 - **toga-blox** (TOGa Blox) — 7 doc(s) → [2.0/apps/toga-blox/INDEX.md](2.0/apps/toga-blox/INDEX.md)
 

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

@@ -13,11 +13,12 @@ project: _Underscore
 client: compass-canada
 type: profile
 status: active
-updated: 2026-06-26
-owners: [jcardinal, bala]
+updated: 2026-06-30
+owners: [jcardinal, bala, tcox]
 files: []
 related:
   - ../compass-usa/profile.md
+  - ../../2.0/apps/toga2-commerce/features/expedited-shipping-gating.md
 ---
 
 ## Summary
@@ -41,6 +42,11 @@ to but distinct from Compass USA. Like Compass USA it spans the **2.0** commerce
   (`1_…` transmit SOs to MITS, `2_…` transmit POs to vendors, `3_…` status from G&T cXML,
   `4_…` import G&T ASNs).
 
+## Storefront notes (toga2-commerce)
+- Runs the same `toga2-commerce` storefront (2.0, consumes api2), with English + French cart
+  configs (COMPASSCANADA ENGLISH / FRENCH). Cart expedited-shipping gating applies here too —
+  see [Config-Driven Expedited Shipping Gating](../../2.0/apps/toga2-commerce/features/expedited-shipping-gating.md).
+
 ## Notes
 - Customer language preference: `UserGlobalSettings.settingId = 2` (`en` / `fr-CA`); customer-
   facing emails are sent in EN or FR accordingly.

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

@@ -12,11 +12,12 @@ project: _Underscore
 client: compass-usa
 type: profile
 status: active
-updated: 2026-06-18
-owners: [jcardinal, bala]
+updated: 2026-06-30
+owners: [jcardinal, bala, tcox]
 files: []
 related:
   - features/asn-to-item-fulfillment.md
+  - ../../2.0/apps/toga2-commerce/features/expedited-shipping-gating.md
 ---
 
 ## Summary
@@ -32,7 +33,16 @@ separate, related client (see its own profile).
   Client-specific model overrides live under `_underscore/Model/Compass/`.
 - **1.0:** worker crons under `worker/crons/toga2/compass/` handle email-based imports and
   notifications.
-- Storefront: compass.togacommerce.com / compass.togahub.com.
+- Storefront: compass.togacommerce.com / compass.togahub.com. The storefront app repo is
+  **`toga2-commerce`** (2.0, consumes api2).
+
+## Storefront notes (toga2-commerce)
+- Cart expedited-shipping gating: expedited methods ("2nd Day EOB", "Next Day Air") are shown
+  only when the cart contains a COMPUTERS-category computer kit — see
+  [Config-Driven Expedited Shipping Gating](../../2.0/apps/toga2-commerce/features/expedited-shipping-gating.md).
+  **Known data issue:** many Compass MacBooks are categorized `APPLE LAPTOP` /
+  `MAC & ACCESSORIES`, not `COMPUTERS`, so those kits do **not** qualify for expedited — a
+  catalog-data normalization matter, not a code gap.
 
 ## Vendors & integrations
 - **Office Depot (ODP)** — vendor id 1. ASNs arrive via **cXML** (direct V2 API) and via the

package/package.json

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