toga-ai 1.0.652 → 1.0.654

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

@@ -37,8 +37,8 @@
 | [Persona Name Translation (PersonaTranslations sidecar)](features/persona-name-translation.md) | Serves Persona **names** in multiple languages by adding a per-language **sidecar** table `PersonaTranslations`, reusing the platform's existing metadata-driven | _underscore/Model/Client/PersonaTranslation.php, dbchanges2/Client/2026-07-22b - PersonaTranslations.sql, dbchanges2/Core/2026-07-22a - PersonaTranslationsRecord.sql, dbchanges2/Client/2026-07-22c - PersonaTranslationsAcl.sql, dbchanges2/Client_CompassCanada/2026-07-22 - PersonaTranslationsFrench.sql, toga2-commerce/src/pages/Account/view/MySettingsView.tsx |
 | [Record Change Audit Log (Logs_<Client>.Record / RecordField) — reading a field's history](features/record-change-audit-log.md) | Every 2.0 client schema has a sibling **logs** schema `Logs_<Tenant>` (e.g. | _underscore/Model/Client/Logs/Record.php, _underscore/Model/Client/Logs/RecordField.php, _underscore/Model/Client/Logs/CustomRecordField.php |
 | [Recursive Item Fulfillments (upstream mirroring)](features/recursive-item-fulfillments.md) | In a multi-tier supply chain a sales order (SO) spawns a purchase order (PO) that becomes another SO downstream, and so on. | _underscore/Model/Client/ItemFulfillment.php, _underscore/Model/Client/ItemFulfillmentItem.php, _underscore/Model/Client/ItemFulfillmentItemUnit.php, _underscore/Model/Client/ItemFulfillmentPackage.php, _underscore/Model/Compass/AdvanceShippingNotice.php, dbchanges2/Core/2026-02-13 - 75601 - RecursiveItemFulfillmentCreation.sql, dbchanges2/Core/2026-06-04 - RecursiveItemFulfillmentPut.sql, dbchanges2/Client_Compass/2026-07-02a - FixSA133377TrackingSerialAndDuplicateIF.sql, dbchanges2/Client_Compass/2026-08-18 - FixSA135471HeroItemHalfQuantityFulfillment.sql |
-| [Sales-order \"PO Number\" sourcing — one surface element, `_purchaseOrders`, tenant SQL underneath](features/sales-order-po-number-sourcing.md) | The sales-order modal's **PO Number** field is **not** tenant-split at the display layer. | _underscore/Model/Client/SalesOrder.php, _underscore/Model/Compass/SalesOrder.php, toga25-supply/src/pages/SalesOrders/helpers/surfaceBundleToTenantFields.ts, toga25-supply/src/pages/SalesOrders/view/SalesOrderRecordModalLayout/hooks/usePurchaseOrderDetails.ts, dbchanges2/Core/2026-08-25a - PoNumberDetailFieldPurchaseOrdersValueKey.sql, dbchanges2/Core/2026-07-23a - PoNumberDetailFieldValueKey.sql, dbchanges2/Client_Quad/2026-08-19a - PoDetailsButtonMostRecentPoSelection.sql |
-| [SO↔PO bridge tables are TWO tables in OPPOSITE directions (upstream vs downstream)](features/sales-order-purchase-order-bridge-direction.md) | There are **two** bridge tables linking sales orders and purchase orders, and they mean **opposite things**. | _underscore/Model/Client/PurchaseOrders/SalesOrder.php, _underscore/Model/Client/SalesOrders/PurchaseOrder.php, _underscore/Model/Client/ItemFulfillment.php, _underscore/Model/Client/SalesOrder.php |
+| [Sales-order \"PO Number\" sourcing — one surface element, `_purchaseOrders`, tenant SQL underneath](features/sales-order-po-number-sourcing.md) | The sales-order modal's **PO Number** field is **not** tenant-split at the display layer. | _underscore/Model/Client/SalesOrder.php, _underscore/Model/Compass/SalesOrder.php, _underscore/Model/Compass/Canada/SalesOrder.php, dbchanges2/Client/2026-08-25 - SalesOrderPurchaseOrdersFieldAllClients.sql, toga25-supply/src/pages/SalesOrders/helpers/surfaceBundleToTenantFields.ts, toga25-supply/src/pages/SalesOrders/view/SalesOrderRecordModalLayout/hooks/usePurchaseOrderDetails.ts, dbchanges2/Core/2026-08-25a - PoNumberDetailFieldPurchaseOrdersValueKey.sql, dbchanges2/Core/2026-07-23a - PoNumberDetailFieldValueKey.sql, dbchanges2/Client_Quad/2026-08-19a - PoDetailsButtonMostRecentPoSelection.sql |
+| [SO↔PO bridge tables are TWO tables in OPPOSITE directions (upstream vs downstream)](features/sales-order-purchase-order-bridge-direction.md) | There are **two** bridge tables linking sales orders and purchase orders, and they mean **opposite things**. | _underscore/Model/Client/PurchaseOrders/SalesOrder.php, _underscore/Model/Client/SalesOrders/PurchaseOrder.php, _underscore/Model/Client/ItemFulfillment.php, _underscore/Model/Client/SalesOrder.php, _underscore/Trait/Netsuite/SalesOrder.php, library/app/api/toga2.php |
 | [Per-client sales-order status filter (Surface FILTER_SET → table meta `filterOptions`)](features/sales-order-status-filter-surface.md) | The status-filter dropdown on the sales-orders table is **per client**, driven by a Surface `FILTER_SET` rather than by the raw contents of the client's `SalesO | _underscore/Model/Client/TableView.php, _underscore/Model/Core/Surface.php, _underscore/Model/Client/SalesOrder.php, _underscore/Model/Quad/SalesOrder.php, _underscore/Model/Prudential/SalesOrder.php, toga-blox/src/components/Table/hooks/useFetchTablePageMeta.ts, toga-blox/src/api/types.ts, dbchanges2/Core/2026-08-24b - SalesOrderStatusFilterSurfaceSeed.sql, dbchanges2/Client_Compass/2026-08-24b - SalesOrderStatusFilterHides.sql, dbchanges2/Client_CompassCanada/2026-08-24b - SalesOrderStatusFilterHides.sql, dbchanges2/Client_Quad/2026-08-24b - SalesOrderStatusFilterHides.sql, dbchanges2/Client_Nychh/2026-08-24b - SalesOrderStatusFilterHides.sql |
 | [_String helpers — ASCII-safe HTML entity encoding (and the parseBetween trap)](features/string-html-entity-helpers.md) | `_String` is the 2.0 framework's static string utility class. | _underscore/String.php |
 | [Surface Resolver (_Model_Core_Surface::resolve — replaces Page::meta)](features/surface-resolver.md) | The runtime for the platform-wide **Surface** UI presentation layer: 9 `_underscore` models plus a cached resolver, `_Model_Core_Surface::resolve(&$api, string | _underscore/Model/Client/Language.php, dbchanges2/Core/2026-08-21 - SalesOrderDecisionSurfacesReseed.sql, dbchanges2/Core/2026-08-24 - RestoreApproveDenyRowActionsVisibility.sql, dbchanges2/Client_Quad/2026-08-24 - ProdPortApprovePoNumberEnabledRule.sql, dbchanges2/Client_Compass/2026-08-24 - ProdPortApprovalsGateAndApproveStepTwoRule.sql, dbchanges2/Client_CompassCanada/2026-08-24 - ProdPortApprovalsGateAndApproveStepTwoRule.sql, dbchanges2/Client_Nychh/2026-08-24 - FixInventoryGroupingsUnitsTopologyOverrideIds.sql, toga25-supply/src/App.tsx, toga25-supply/src/surface/useFetchSurfaceMeta.ts, toga25-supply/src/contexts/AuthContext.tsx, dbchanges2/Core/2026-07-21a - SalesOrderDecisionSummarySurfaceSeed.sql, dbchanges2/Core/2026-07-21b - SalesOrderDecisionActionSurfaceSeed.sql, dbchanges2/Core/2026-08-21a - SalesOrderDecisionSurfacesReseed.sql, dbchanges2/Client_Compass/2026-07-21c - SalesOrderDecisionSummaryTotalConcat.sql, dbchanges2/Client_Quad/2026-07-21c - SalesOrderDecisionSummaryOverride.sql, dbchanges2/Client_CompassCanada/2026-07-21c - SalesOrderDecisionSummaryTotalConcat.sql, dbchanges2/Client_Compass/2026-08-04a - ApprovalDetailsAssignedManagerPreferredStage.sql, _underscore/Model/Core/Surface.php, _underscore/Model/Client/AclRecordScript.php, _underscore/Model/Core/RecordScript.php, dbchanges2/Core/2026-06-30a - SurfaceMetaGroupAndSalesOrderSections.sql, dbchanges2/Client/2026-06-30a - SurfaceMetaGroupAcl.sql, dbchanges2/Client_Quad/2026-07-01a - GrantSurfacesMetaGroupScriptAcl.sql, dbchanges2/Client_CompassCanada/2026-07-01a - GrantSurfacesMetaGroupScriptAcl.sql, dbchanges2/Core/2026-06-29b - SurfaceMetaPublicReadAcl.sql, dbchanges2/Client/2026-06-29c - SurfaceRecordScriptAcl.sql, dbchanges2/Core/2026-06-29c - SurfaceDebugPhpMethodFix.sql, dbchanges2/Client_Compass/2026-07-15f - SalesOrderRecordActionsRemoveDeadConfigRuleOverrides.sql, dbchanges2/Core/2026-07-17h - Update - ClearApprovalsFilterButtonConfig.sql, dbchanges2/Client_Compass/2026-07-17a - SalesOrderApprovalActionsOverride.sql, dbchanges2/Client_Compass/2026-07-17b - SalesOrderApprovalsFilterButtonOverride.sql, dbchanges2/Client_CompassCanada/2026-07-17a - SalesOrderApprovalActionsOverride.sql, dbchanges2/Client_CompassCanada/2026-07-17b - SalesOrderApprovalsFilterButtonOverride.sql, dbchanges2/Client_Quad/2026-07-17a - SalesOrderApprovalActionsOverride.sql, dbchanges2/Client_Quad/2026-07-17b - SalesOrderApprovalsFilterButtonOverride.sql, _underscore/Model/Core/SurfaceElement.php, _underscore/Model/Core/Action.php, _underscore/Model/Core/Vocabulary.php, _underscore/Model/Core/VocabularyTerm.php, _underscore/Model/Core/Message.php, _underscore/Model/Client/SurfaceOverride.php, _underscore/Model/Client/MessageTranslation.php, _underscore/Model/Client/ThemeToken.php, _underscore/Model/Core/Page.php, api2/Component/Api/V2/V2.php |

package/knowledge/2.0/apps/_underscore/features/calculated-sql-fields.md

@@ -23,7 +23,7 @@ related:
   - ../../api2/features/v2-api-error-codes.md
   - ./model-magic-field-access.md
   - ./model-save-parent-cascade-stored-field-deadlock.md
-  - ./purchase-order-sales-order-bridges.md
+  - ./sales-order-purchase-order-bridge-direction.md
 ---
 
 ## Summary
@@ -186,7 +186,7 @@ generous end; `Developer` and `Public` get no ACL row for any field.
   `Client_Imhouston` (1 of 35 prod) and 7 of 36 client-sandbox schemas, driving the re-runnable
   `Client/2026-08-25 - SalesOrderPurchaseOrdersFieldAllClients.sql`. Recorded the `Base` + `API`
   by-name ACL convention for these rows. Cross-linked
-  [PO-to-SO bridge tables](./purchase-order-sales-order-bridges.md) — the metadata row makes
+  [PO-to-SO bridge tables](./sales-order-purchase-order-bridge-direction.md) — the metadata row makes
   `_purchaseOrders` *requestable*, but the field's SQL was reading the wrong bridge table, so a
   successful rollout still returned blank for most clients. (bala)
 - 2026-08-18 - Documented **how a calculated field becomes requestable**: a client-scoped

package/knowledge/2.0/apps/_underscore/features/netsuite-salesorder-address-phone-sync.md

@@ -16,7 +16,7 @@ related:
   - acl-permission-chain.md
   - address-uniqueness-normalization.md
   - carrier-shipping-labels.md
-  - purchase-order-sales-order-bridges.md
+  - sales-order-purchase-order-bridge-direction.md
   - ../../toga2-supply/features/fulfill-and-ship.md
   - ../../api2/features/record-scripts.md
 ---
@@ -41,15 +41,16 @@ changes behaviour for all 22 clients at once**.
 (and was NULL on the order tested), while the **bridge covers 12,643 of 12,658** orders. Resolve the
 PO through the bridge, not the column.
 
-**⚠ …and it is the REVERSE bridge, which the shared `SalesOrders._purchaseOrders` field did not
-read.** This trait writes the PO link via the api2 child key **`purchaseOrderSalesOrders`**, which
-lands in **`PurchaseOrders_SalesOrders`** — while the base calculated field
-`_Model_Client_SalesOrder::_purchaseOrders()` queried **`SalesOrders_PurchaseOrders`**, a *different*
-table populated by a *different* (1.0 cron) pipeline holding Agilant's **vendor** POs rather than the
-customer's. So every client on this trait stored a correct PO that the field could not see: 41,381 of
-72,134 prod orders rendered blank. Read
-[PO-to-SO bridge tables](./purchase-order-sales-order-bridges.md) **before** touching either side of
-this link — the child key you choose decides which table you write, silently.
+**⚠ …and it is the UPSTREAM bridge, which the shared `SalesOrders._purchaseOrders` field did not
+read.** This trait writes the PO link via the api2 child key **`purchaseOrderSalesOrders`**, landing
+in **`PurchaseOrders_SalesOrders`** (upstream — the *customer's* PO). The base calculated field
+`_Model_Client_SalesOrder::_purchaseOrders()` queried **`SalesOrders_PurchaseOrders`** (downstream),
+a *different* table populated by a *different* pipeline — the 1.0
+`App_Api_Toga2::syncPurchaseOrderFromNetsuite` cron — holding Agilant's **vendor** POs. So every
+client on this trait stored a correct PO the field could not see: **41,381 of 72,134** prod orders
+rendered blank until a downstream-then-upstream `COALESCE` was added. Read
+[SO↔PO bridge direction](./sales-order-purchase-order-bridge-direction.md) **before** touching either
+side of this link — the child key you choose decides which table you write, silently.
 
 ## ⚠ Four traps when writing a field on this shared trait
 
@@ -102,11 +103,11 @@ intended, not a fault.
 ## Change history
 
 - 2026-08-26 — Corrected the PO half of the "where the values come from" table: the
-  `purchaseOrderSalesOrders` child key this trait posts writes the **reverse** bridge
+  `purchaseOrderSalesOrders` child key this trait posts writes the **upstream** bridge
   (`PurchaseOrders_SalesOrders`, customer PO), while the shared `SalesOrders._purchaseOrders`
-  calculated field read the **forward** bridge (`SalesOrders_PurchaseOrders`, Agilant vendor PO) — so
+  calculated field read the **downstream** bridge (`SalesOrders_PurchaseOrders`, Agilant vendor PO) — so
   all 22 trait clients stored a PO the UI could not display (41,381 of 72,134 prod orders blank).
-  Cross-linked the new [PO-to-SO bridge tables](./purchase-order-sales-order-bridges.md) doc. (bala)
+  Cross-linked [SO↔PO bridge direction](./sales-order-purchase-order-bridge-direction.md). (bala)
 - 2026-08-11 — TRUE-80824: created. Prefilled TOGa Supply's Reference 1 / Reference 2 / Phone # from
   NetSuite by sourcing `SalesOrders.number`, the bridge-linked purchase order (`otherRefNum` — **not**
   `customerPurchaseOrder`, ~59% populated vs the bridge's 12,643/12,658), and the shipping address's

package/knowledge/2.0/apps/_underscore/features/sales-order-po-number-sourcing.md

@@ -6,11 +6,13 @@ project: _Underscore
 client: shared
 type: feature
 status: active
-updated: 2026-08-25
-owners: [apeterson]
+updated: 2026-08-26
+owners: [apeterson, bala]
 files:
   - _underscore/Model/Client/SalesOrder.php
   - _underscore/Model/Compass/SalesOrder.php
+  - _underscore/Model/Compass/Canada/SalesOrder.php
+  - dbchanges2/Client/2026-08-25 - SalesOrderPurchaseOrdersFieldAllClients.sql
   - toga25-supply/src/pages/SalesOrders/helpers/surfaceBundleToTenantFields.ts
   - toga25-supply/src/pages/SalesOrders/view/SalesOrderRecordModalLayout/hooks/usePurchaseOrderDetails.ts
   - dbchanges2/Core/2026-08-25a - PoNumberDetailFieldPurchaseOrdersValueKey.sql
@@ -50,12 +52,53 @@ deliberately **not** set: the value is a scalar comma-joined string, not a perso
 via `resolvePathInsensitive(valueKey)`, normalising an empty string to an em-dash.
 
 ### The tenant layer (`_purchaseOrders`)
+
+**Only TWO classes in the whole tree define this method** — verified with
+`grep -rn "function _purchaseOrders" _underscore/`:
+
 | Tenant | Implementation | Direction read |
 |---|---|---|
-| **Compass USA** | overrides in `_underscore/Model/Compass/SalesOrder.php:238` — a `UNION ALL` of its own vendor POs plus Office Depot's POs traversed SO→PO→SO→PO across the multi-tier chain | downstream **+ upstream** (only tenant reading upstream) |
-| **Quad Graphics** | no override → base implementation | downstream only |
-| **Compass Canada** | no `Model/Compasscanada/` directory exists at all → base implementation | downstream only |
-| base (`_Model_Client_SalesOrder:348`) | the shared calculated field | **downstream only** (`SalesOrders_PurchaseOrders`) |
+| **Compass USA and Compass Canada** | both inherit `_Model_Compass_SalesOrder::_purchaseOrders()` (`_underscore/Model/Compass/SalesOrder.php:238`) — a `UNION ALL` of its own vendor POs plus Office Depot's POs traversed SO→PO→SO→PO across the multi-tier chain | downstream **+ upstream** |
+| **Quad Graphics** | no override → base implementation | downstream, then upstream fallback |
+| base (`_Model_Client_SalesOrder:349`) | the shared calculated field | **downstream, falling back to upstream** (see below) |
+
+**⚠ Correction (2026-08-26): Compass Canada is not on the base implementation.** The earlier "no
+`Model/Compasscanada/` directory" reading looked in the wrong place — Compass's tenants nest one
+level deeper, at `_underscore/Model/Compass/Canada/SalesOrder.php`, where
+`_Model_Compass_Canada_SalesOrder extends _Model_Compass_SalesOrder`. Compass USA is
+`Model/Compass/Usa/SalesOrder.php` and does the same. So **any change to the Compass override moves
+both Compass tenants**, and neither is affected by a change to the base. Compass Canada's upstream
+bridge is in fact **empty** (0 rows; 735 of 788 orders resolve downstream) — it is downstream-only,
+not upstream-only.
+
+### The base field now falls back to upstream (`COALESCE`)
+
+Because the trait-based NetSuite sync writes **upstream** while the base field read **downstream**,
+41,381 of 72,134 prod orders across the 19 base-model tenants resolved no PO at all. The base
+`_purchaseOrders()` is now a **`COALESCE` of two scalar subqueries** — downstream first, upstream as
+the fallback — which fixes every upstream tenant at once and needed **no per-tenant override**.
+
+Branch state as verified **2026-08-26** (do not assume this is live):
+
+| Repo | Change | Where it lives |
+|---|---|---|
+| `_underscore` | the `COALESCE` fallback | commit `4579e0e7` on `TRUE-81284`, merged into **`_beta`**, `_sandbox-client`, `_sandbox-dev`. **Not on `_production`.** |
+| `dbchanges2` | `Client/2026-08-25 - SalesOrderPurchaseOrdersFieldAllClients.sql` (the `CustomRecordFields` row for the schemas the 2026-08-11b rollout missed) | commit `0ca4012` on `TRUE-81284`, pushed. **Not on `_main` or `_beta`.** |
+
+Verified while applied: **zero existing values changed for any tenant** — the fallback only fills
+nulls — while coverage went NYCHH 64 → 819 of 819, Elite 57 → 288 of 288, Quad 475 → 1,456 of 1,463.
+The MySQL 8 plan stayed indexed (both subqueries `ref` on `idx_salesOrderId`, then `eq_ref` on the
+`PurchaseOrders` primary key) and `COALESCE` short-circuits, so the upstream subquery only runs when
+the downstream one is null.
+
+#### ⚠ Still open — which direction wins when an order has both
+
+Downstream-first shows the **vendor** PO, while the sales-orders **list** (whose table-view join
+reads upstream) shows the **customer** PO, so one order can display two different PO numbers in the
+list and in the modal. Orders carrying both are real and not rare: NYCHH 64, Elite 55, Quad 469.
+Downstream-first was chosen, then questioned in favour of treating the list as the source of truth;
+a per-tenant override on `_Model_Nychh_SalesOrder` preferring upstream was offered and **not built**.
+**Settle this before quoting either value as correct.**
 
 ### `poSelection` is a different thing
 The `poSelection` config on the `sales-order-record-actions` surface picks **which** linked PO the
@@ -74,14 +117,34 @@ the two — changing one does not move the other.
 - **Surface seed `id`s are deterministic; surface `uuid`s are not.** Seeds insert with `UUID()`, so
   the element uuid differs per environment. A uuid quoted in an older migration will **not** match
   the uuid in a live payload. Key surface updates on the literal `id` (here, `id = 7`).
-- **Downstream-only base implementation is a trap for upstream tenants.** On an upstream-only
-  tenant `_purchaseOrders` resolves cleanly (no `EV-8`) and returns `null` forever. See
+- **Downstream-only base implementation was a trap for upstream tenants.** On an upstream-only
+  tenant `_purchaseOrders` resolved cleanly (no `EV-8`) and returned `null` forever. Closed on
+  `_beta` by the `COALESCE` fallback above. See
   [SO↔PO bridge direction](./sales-order-purchase-order-bridge-direction.md) and
   [NYCHH PO Number](../../../clients/nychh/features/po-number-upstream-direction.md).
+- **A correct value here still may not reach the older TOGa Supply order-details modal.** That UI is
+  config-driven and declares the display row and the API field request **separately**: the
+  `DEFAULTFIELDS` and `QUAD` field sets ask for a `_purchaseOrders` row without listing
+  `_purchaseOrders` in `apiFields.fetchOrderDetails`, so it renders blank regardless of the SQL. See
+  [order-detail field config](../../toga2-supply/features/order-detail-field-config-and-customer-name.md).
+- **Fixing the SQL is not enough on a tenant whose schema lacks the metadata row.** No
+  `CustomRecordFields` row (`recordId` 14, field `_purchaseOrders`) means `EV-8` no matter what the
+  model returns, and the original per-client rollout **missed schemas** — prod 1 of 35, sandbox 7 of
+  36. See [calculated SQL fields](./calculated-sql-fields.md).
 - Dropping `isPersonaValue` is intentional; re-adding it will make the FE try to treat the string
   as a persona array.
 
 ## Change history
+- 2026-08-26 — Base `_purchaseOrders()` became a **`COALESCE`** of downstream-then-upstream, closing
+  the upstream-tenant gap for all base-model tenants with no per-tenant override (verified: no
+  existing value changed; NYCHH 64 → 819/819, Elite 57 → 288/288, Quad 475 → 1,456/1,463; plan stays
+  indexed). Recorded its branch state (`_beta`, **not** `_production`) and left the
+  **downstream-vs-upstream tie-break open** for orders carrying both (NYCHH 64, Elite 55, Quad 469),
+  where the modal and the list can disagree. **Corrected the tenant table**: Compass Canada is not on
+  the base implementation — it lives at `Model/Compass/Canada/` and inherits the Compass override, so
+  both Compass tenants move together and Compass Canada's upstream bridge is empty. Added the two
+  other independent causes of a blank PO (missing `CustomRecordFields` row → `EV-8`; the older supply
+  order-details field set never requesting the field). (bala)
 - 2026-08-25 — Repointed `SurfaceElements` id 7 to `_purchaseOrders` for all clients
   (`Core/2026-08-25a`, reverting `Core/2026-07-23a`) and made the FE adapter honour the surface
   `valueKey` instead of a hardcoded path; recorded the corrected per-tenant map, which supersedes

package/knowledge/2.0/apps/_underscore/features/sales-order-purchase-order-bridge-direction.md

@@ -6,17 +6,20 @@ project: _Underscore
 client: shared
 type: feature
 status: active
-updated: 2026-08-25
-owners: [apeterson]
+updated: 2026-08-26
+owners: [apeterson, bala]
 files:
   - _underscore/Model/Client/PurchaseOrders/SalesOrder.php
   - _underscore/Model/Client/SalesOrders/PurchaseOrder.php
   - _underscore/Model/Client/ItemFulfillment.php
   - _underscore/Model/Client/SalesOrder.php
+  - _underscore/Trait/Netsuite/SalesOrder.php
+  - library/app/api/toga2.php
 related:
   - ./sales-order-po-number-sourcing.md
   - ./recursive-item-fulfillments.md
   - ./fulfillable-item-propagation.md
+  - ./netsuite-salesorder-address-phone-sync.md
   - ../../api2/features/v2-rest-query-contract.md
   - ../../../clients/nychh/features/po-number-upstream-direction.md
 ---
@@ -47,10 +50,45 @@ origin; the second is what was generated from it.
   - A multi-tier tenant (Compass USA) has **both**, chained SO→PO→SO→PO.
 - The only in-code statement of the distinction today is a docblock at
   `_underscore/Model/Client/ItemFulfillment.php:136-140`.
-- The base `_purchaseOrders` calculated field on `_Model_Client_SalesOrder` (line ~348) reads the
-  **downstream** table only. See
+- The base `_purchaseOrders` calculated field on `_Model_Client_SalesOrder` (line ~348) read the
+  **downstream** table only until 2026-08-25, when a **fallback to upstream** was added. See
   [sales-order PO Number sourcing](./sales-order-po-number-sourcing.md).
 
+### Two writers, one per direction — and the child key is what picks the table
+
+The two directions are not two views of one write; they are populated by **two different sync
+pipelines**, in **different frameworks**:
+
+| | UPSTREAM (`PurchaseOrders_SalesOrders`) | DOWNSTREAM (`SalesOrders_PurchaseOrders`) |
+|---|---|---|
+| Written by | **2.0** `_Trait_Netsuite_SalesOrder` (`_underscore/Trait/Netsuite/SalesOrder.php` ~:664-680 and ~:720) | **1.0** cron `App_Api_Toga2::syncPurchaseOrderFromNetsuite` (`library/app/api/toga2.php:2028`, posts the child key at :2504) |
+| api2 child key | `purchaseOrderSalesOrders` | `salesOrderPurchaseOrders` |
+| PO number stored | NetSuite `$nsOrder->otherRefNum` — the **customer's** PO (`EIT0011108`, `LOI-Woodhull`, `GAVELL/08252026`, Quad `4992713`) | the **vendor** PO — numeric NetSuite PO numbers (`168984`), Elite's `P100019` |
+
+**⚠ The child key is the only thing that decides which table you write, and getting it wrong is
+silent.** api2 treats `salesOrderPurchaseOrders` and `purchaseOrderSalesOrders` as two unrelated
+child collections, so a transposed key writes a perfectly valid row into the *other* direction and
+the reading side simply never sees it. No error, no warning. Read the key aloud, like the routes.
+
+Because **22 client `SalesOrder` models compose `_Trait_Netsuite_SalesOrder`**, every NetSuite-synced
+tenant writes **upstream** rows — which is why upstream-only tenants are the norm on that trait
+rather than the exception. (Grep the composition list before assuming a trait change is
+client-scoped; note the same grep also matches the `SalesOrderItem` / `SalesOrderStage` models, so
+count `SalesOrder.php` files only or you will report 66.)
+
+### How much downstream-only cost, measured on prod
+
+Because the base field read downstream only while the trait wrote upstream, **41,381 of 72,134**
+sales orders across the 19 base-model tenants returned no PO at all — only 30,753 resolved. Worst
+affected: NYCHH 64/822, Canon 594/6,290, GroWrk 1,226/12,793, S&P Global 971/9,468, Endeavor Health
+1,919/11,836. **An order can also carry both directions at once** (NYCHH 64, Elite 55, Quad 469),
+which is what makes the tie-break in
+[PO Number sourcing](./sales-order-po-number-sourcing.md) a real decision rather than a formality.
+
+All **35** prod client schemas contain all four tables (`SalesOrders`, `PurchaseOrders`, both
+bridges), verified via `information_schema` — so reading either direction is structurally safe
+everywhere. Present is not populated.
+
 ## Gotchas
 
 - **An empty array is the symptom.** `200` / `totalRecordCount 0` with **no** `EZ-*` or `EV-*`
@@ -62,11 +100,38 @@ origin; the second is what was generated from it.
 - **The routes are near-homographs.** `sales-order-purchase-orders` vs
   `purchase-order-sales-orders`. Read them aloud before wiring a front-end call.
 - **Downstream-only assumptions are baked into shared code.** Any tenant whose POs are purely
-  upstream (verified: NYCHH; suspected: Compass Canada, which has no `Model/Compasscanada/`
-  overrides at all) silently gets `null`/empty from the shared downstream-reading helpers rather
-  than an error. Upstream-only tenants need an explicit upstream counterpart field.
+  upstream (verified: NYCHH) silently gets `null`/empty from the shared downstream-reading helpers
+  rather than an error.
+- **⚠ Compass Canada is NOT upstream-only, and it DOES have model overrides** — corrected
+  2026-08-26. The earlier "no `Model/Compasscanada/` directory" reading looked in the wrong place:
+  the folder is **`_underscore/Model/Compass/Canada/`**, and
+  `_Model_Compass_Canada_SalesOrder extends _Model_Compass_SalesOrder`, so Compass Canada inherits
+  **Compass's** `_purchaseOrders` override, not the base one. Its **upstream bridge is completely
+  empty (0 rows)** while 735 of 788 orders resolve a PO downstream. When checking whether a tenant
+  has overrides, search for the class name (`grep -rn "class _Model_.*_SalesOrder extends"`) rather
+  than guessing a directory — Compass's tenants nest one level deeper than everyone else's.
+- **⚠ Do NOT paper over the direction with an `ojoin` on a shared single-record fetch.** It is
+  tempting because it works in one place: the TOGa Supply NYCHH orders **list** joins the upstream
+  bridge and is correct — but only because NYCHH's upstream bridge happens to be **1:1** (823 rows /
+  823 distinct sales orders, max 1 PO per SO). The same join in the shared
+  `fetchOrdersDetails` (`toga2-supply/src/pages/Orders/api/OrdersApi.ts:397`) breaks three tenants:
+  **Compass** has up to **6,440** downstream POs on one sales order (row multiplication on a
+  single-record fetch), **Compass Canada's upstream bridge is empty** (735 of 788 would drop to
+  **zero**), and **Prudential** has only **1,868 of 26,843** orders upstream (92% populated would
+  become 7%). A scalar `GROUP_CONCAT` calculated field is the right mechanism precisely because it
+  collapses many POs without multiplying rows.
 
 ## Change history
+- 2026-08-26 — Added the **write** side: the two directions are populated by two different
+  pipelines (2.0 `_Trait_Netsuite_SalesOrder` writes **upstream** customer POs from `otherRefNum`;
+  the 1.0 `syncPurchaseOrderFromNetsuite` cron writes **downstream** vendor POs), and the api2 child
+  key (`purchaseOrderSalesOrders` vs `salesOrderPurchaseOrders`) is the only thing selecting the
+  table — a transposed key writes the wrong direction silently. Quantified the downstream-only cost
+  on prod (41,381 of 72,134 orders returned no PO across the 19 base-model tenants) and noted
+  tenants carrying both directions. **Corrected the Compass Canada claim**: it has overrides at
+  `Model/Compass/Canada/` and inherits the Compass `_purchaseOrders` override, and its upstream
+  bridge is empty — it is downstream-only, not upstream-only. Added the "do not fix this with an
+  `ojoin`" gotcha with the Compass / Compass Canada / Prudential regressions it would cause. (bala)
 - 2026-08-25 — Documented the two-direction bridge after an NYCHH "empty array" debug that was
   purely a wrong-direction query; recorded route/model/record-id mapping and the empty-vs-EZ
   diagnostic signature (apeterson)

package/knowledge/2.0/apps/ai-bdr/INDEX.md

@@ -6,9 +6,10 @@
 | [BDR Web Funnel — Full Implementation Plan](features/bdr-web-funnel-plan.md) | > **Execution status (2026-07-16):** PLAN **Phases 0–5 are BUILT and QA'd**, Phase 6 > was **mostly already built** (the `info` contract was implemented at comm | bdr/PLAN.md, bdr/mockup/app.jsx, bdr/mockup/screens.jsx, bdr/mockup/components.jsx |
 | [Call Orchestration — PHP Worker ↔ Vapi (the integration seam)](features/call-orchestration.md) | The **PHP worker** is the orchestrator; **Vapi** is the actor. | ai-bdr/docs/client-onboarding-sop.md, ai-bdr/docs/vapi-firstmessage-timing-fix.md, ai-bdr/docs/vapi-inbound-callback-assistant-request.md, ai-bdr/docs/vapi-voicemail-iphone-screening.md, ai-bdr/scripts/update_structured_output.py |
 | [AI-BDR Campaign Chat — Backend Contract + Frontend Widget Handoff](features/campaign-chat-handoff.md) | The consolidated backend + frontend handoff for the **AI-BDR campaign chat** — a grounded AI-BDR chat widget for landing pages, powered by the Talos backend at | ai-bdr-campaign-handoff.md, bdr/src/lib/talosChat.ts |
+| [Landing "Call me now" Flow (/landing) — screens + the dormant real callback route](features/landing-call-flow.md) | The **"Call me now" path on `/landing`**: a two-screen flow (call form → calling/recap) plus a **real, wired, but deliberately dormant** backend route (`POST /a | bdr/src/flow/screens/SecurityCallNow.tsx, bdr/src/flow/screens/SecurityCalling.tsx, bdr/src/lib/securityCallFlow.ts, bdr/src/lib/leadName.ts, bdr/src/app/api/landing-call/route.ts, bdr/src/flow/landingCallApi.ts, bdr/src/flow/screens/SecurityLanding.tsx, bdr/src/components/ChatPanel.tsx, bdr/src/content/security.ts, bdr/src/app/security.css, bdr/src/proxy.ts, bdr/.env.example, bdr/test/securityCallFlow.test.ts, bdr/test/landingCallRoute.test.ts |
 | [Talos Chat Drawer on /landing (first campaign-chat consumer)](features/landing-chat-drawer.md) | The **right-anchored chat drawer on `/landing`**, wired to the **real** Talos campaign-chat backend at `https://api.togaiq.com`. | bdr/src/components/ChatPanel.tsx, bdr/src/components/ChatMarkdown.tsx, bdr/src/lib/talosChat.ts, bdr/src/content/security.ts, bdr/src/flow/screens/SecurityLanding.tsx, bdr/src/app/security.css, bdr/test/talosChat.test.ts, bdr/test/chatMarkdown.test.ts |
 | [Live Call Status — Vapi call API → funnel Success screen lifecycle](features/live-call-status.md) | The BDR funnel's Success screen shows the **real** state of the call it just requested — dialing / ringing / answered-and-talking / ended / not-answered — inste | bdr/src/server/vapiCall.ts, bdr/src/server/callStatus.ts, bdr/src/server/statusToken.ts, bdr/src/server/callbackService.ts, bdr/src/server/workerDialer.ts, bdr/src/lib/callStatus.ts, bdr/src/app/api/call-status/route.ts, bdr/src/app/api/call-now/route.ts, bdr/src/flow/useCallStatusViewModel.ts, bdr/src/flow/callStatusApi.ts, bdr/src/flow/screens/Success.tsx, bdr/src/content/schema.ts, bdr/src/content/default.ts, bdr/src/proxy.ts |
-| [Cybersecurity Landing Page (/landing — the site's current main page)](features/security-landing-page.md) | A single-page **cybersecurity services marketing landing page** at **`/landing`** in the `bdr` repo — and, as of 2026-08-24, **the site's main page**: `/` **307 | bdr/src/app/landing/page.tsx, bdr/src/app/security.css, bdr/src/flow/screens/SecurityLanding.tsx, bdr/src/content/security.ts, bdr/src/components/LogoSymbol.tsx, bdr/src/components/AssistantMark.tsx, bdr/src/components/Ico.tsx, bdr/src/components/Particles.tsx, bdr/src/components/ChatPanel.tsx, bdr/src/components/ChatMarkdown.tsx, bdr/src/lib/talosChat.ts, bdr/next.config.ts, bdr/eslint.config.mjs |
+| [Cybersecurity Landing Page (/landing — the site's current main page)](features/security-landing-page.md) | A single-page **cybersecurity services marketing landing page** at **`/landing`** in the `bdr` repo — and, as of 2026-08-24, **the site's main page**: `/` **307 | bdr/src/app/landing/page.tsx, bdr/src/app/security.css, bdr/src/flow/screens/SecurityLanding.tsx, bdr/src/flow/screens/SecurityCallNow.tsx, bdr/src/flow/screens/SecurityCalling.tsx, bdr/src/lib/securityCallFlow.ts, bdr/src/content/security.ts, bdr/src/components/LogoSymbol.tsx, bdr/src/components/AssistantMark.tsx, bdr/src/components/Ico.tsx, bdr/src/components/Particles.tsx, bdr/src/components/ChatPanel.tsx, bdr/src/components/ChatMarkdown.tsx, bdr/src/lib/talosChat.ts, bdr/next.config.ts, bdr/eslint.config.mjs |
 | [Vapi Integration — Assistants, Tools, Structured Output](features/vapi-integration.md) | Everything inside Vapi: the three assistants, the three shared tools, the shared structured-output schema, the Liquid-templated system prompt, and the Python sc | ai-bdr/vapi/templates/assistant.template.json, ai-bdr/vapi/templates/system-prompt.template.md, ai-bdr/prompts/archive/prompt-may-15.txt, ai-bdr/prompts/campaigns/healthcare-2026-03-18.md, ai-bdr/prompts/campaigns/healthcare-v2-2026-03-25.md, ai-bdr/prompts/templates/campaign-template.md, ai-bdr/scripts/update_assistant.py, ai-bdr/scripts/update_system_prompt.py, ai-bdr/scripts/update_structured_output.py, ai-bdr/scripts/update_call_summary_context.py, ai-bdr/scripts/fix_booking_guardrails.py, ai-bdr/scripts/get_assistant.py, ai-bdr/docs/vapi-firstmessage-timing-fix.md, ai-bdr/docs/vapi-voicemail-iphone-screening.md |
 | [Web Funnel — Built Next.js App (structure, stack, how to run)](features/web-funnel-app.md) | > **READ FIRST (2026-08-24) — the funnel is currently UNREACHABLE.** `/` now > **307-redirects to `/landing`**, the new cybersecurity landing page > ([security- | bdr/PLAN.md, bdr/next.config.ts, bdr/.gitignore, bdr/src/server/hubspot.ts, bdr/src/server/leadSink.ts, bdr/src/server/callbackService.ts, bdr/src/server/workerDialer.ts, bdr/src/server/mailer.ts, bdr/src/server/statusToken.ts, bdr/src/server/vapiCall.ts, bdr/src/server/callStatus.ts, bdr/src/lib/summaryText.ts, bdr/src/lib/emailFormat.ts, bdr/src/lib/callStatus.ts, bdr/src/app/api/share-summary/route.ts, bdr/src/app/api/call-status/route.ts, bdr/src/flow/shareSummaryApi.ts, bdr/src/flow/callStatusApi.ts, bdr/src/flow/useCallStatusViewModel.ts, bdr/src/flow/screens/Success.tsx, bdr/src/flow/screens/CallNow.tsx, bdr/src/flow/screens/Schedule.tsx, bdr/src/flow/screens/CallSummary.tsx, bdr/src/content/schema.ts, bdr/src/content/default.ts, bdr/test/togaEnrichment.test.ts, bdr/test/fastDial.test.ts, bdr/eslint.config.mjs, bdr/amplify.yml, bdr/src/app, bdr/src/app/layout.tsx, bdr/src/app/page.tsx, bdr/src/app/studio.css, bdr/src/lib/resolveCampaignId.ts, bdr/src/lib/scheduleSlots.ts, bdr/src/lib/formatPhone.ts, bdr/src/lib/analytics.ts, bdr/src/lib/rateLimit.ts, bdr/src/lib/clientIp.ts, bdr/src/proxy.ts, bdr/.env.example, bdr/src/components/GoogleAnalytics.tsx, bdr/src/components/RichText.tsx, bdr/src/content, bdr/src/components, bdr/src/flow, bdr/src/server, bdr/src/server/toga.ts, bdr/src/app/api, bdr/test, bdr/test/togaPrimaryPhone.test.ts, bdr/public, bdr/mockup/styles.css |
 | [Web Funnel — Next.js UI + Config-Driven Campaign Content](features/web-funnel-content-model.md) | > **Status note (RESOLVED 2026-07-16):** the content **contract** below (schema, > provider seam, adapters) is BUILT and QA'd (PLAN Phases 0–5). | bdr/src/content/schema.ts, bdr/src/content/provider.ts, bdr/src/content/useCampaign.ts, bdr/src/content/default.ts, bdr/src/lib/resolveCampaignId.ts, bdr/src/server/leadSink.ts, bdr/src/server/callbackService.ts, bdr/src/app/api/call-now/route.ts, bdr/src/app/api/call-later/route.ts, bdr/src/app/api/contact/route.ts |

package/knowledge/2.0/apps/ai-bdr/features/landing-call-flow.md

@@ -0,0 +1,226 @@
+---
+title: Landing "Call me now" Flow (/landing) — screens + the dormant real callback route
+framework: "2.0"
+repo: ai-bdr
+project: AI-BDR
+client: shared
+type: feature
+status: active
+updated: 2026-08-26
+owners: [tcox]
+files:
+  - bdr/src/flow/screens/SecurityCallNow.tsx
+  - bdr/src/flow/screens/SecurityCalling.tsx
+  - bdr/src/lib/securityCallFlow.ts
+  - bdr/src/lib/leadName.ts
+  - bdr/src/app/api/landing-call/route.ts
+  - bdr/src/flow/landingCallApi.ts
+  - bdr/src/flow/screens/SecurityLanding.tsx
+  - bdr/src/components/ChatPanel.tsx
+  - bdr/src/content/security.ts
+  - bdr/src/app/security.css
+  - bdr/src/proxy.ts
+  - bdr/.env.example
+  - bdr/test/securityCallFlow.test.ts
+  - bdr/test/landingCallRoute.test.ts
+related:
+  - security-landing-page.md
+  - landing-chat-drawer.md
+  - live-call-status.md
+  - call-orchestration.md
+  - web-funnel-app.md
+---
+
+## What this is
+
+The **"Call me now" path on `/landing`**: a two-screen flow (call form → calling/recap)
+plus a **real, wired, but deliberately dormant** backend route
+(`POST /api/landing-call`) that requests an actual Vapi callback for an **anonymous**
+visitor.
+
+It was built 2026-08-26 on the design lead's UI review of the landing page: *"mock is
+right; missing a Call me now button + flow; book a meeting slightly large; check with
+Alex re shared component."*
+
+**Read this first:** the route is **off by default**. It requires
+`TOGA_SECURITY_CAMPAIGN_UUID`, and **no cybersecurity campaign exists in Toga yet**, so
+in every environment today the flow runs its **simulation**. That is the intended end
+state for now — *"wired up and ready for the campaign"* — not an unfinished build.
+
+## The two campaigns are NOT the same thing (read before wiring anything)
+
+AI-BDR has **two independent campaign systems** with unrelated ids. Confusing them is the
+easiest mistake to make on this page, because both serve the same cybersecurity offer.
+
+| | **Talos chat campaign** | **Toga dialer campaign** |
+|---|---|---|
+| Lives in | `api.togaiq.com` → `campaign_registry` | Toga platform → `Client_True.Campaigns` |
+| Used by | the chat drawer ([landing-chat-drawer.md](landing-chat-drawer.md)) | the callback/dialer path (this doc) |
+| Security id | `43fdf2b6-7a5d-4e85-be6b-911f42aa787f` ("External Pen Testing") | **none exists** |
+| Env var | `NEXT_PUBLIC_TALOS_API_BASE` (base URL only) | `TOGA_SECURITY_CAMPAIGN_UUID` |
+
+**`43fdf2b6-7a5d-4e85-be6b-911f42aa787f` cannot be used for
+`TOGA_SECURITY_CAMPAIGN_UUID`.** It is a Talos chat-grounding campaign, not a dialer
+campaign, and Toga has never heard of it.
+
+`Client_True.Campaigns` in **prod** holds exactly two rows (verified 2026-08-26), both
+**healthcare**, both `c_meetingType = discovery-call`:
+
+- `15d0c02f-501e-e081-2ead-61b78c854223` — "26.05 - AI BDR - Ryan Nitti"
+- `d8f7abe6-8f06-0218-03d1-50db575` — "26.04 - AI BDR TEST CAMPAIGN"
+
+So there is **no cybersecurity dialer campaign and no cybersecurity Vapi assistant**.
+That is the single blocker for real calls from `/landing`, and it is owned **outside the
+`bdr` repo** (Toga platform + Vapi config).
+
+## Screen flow
+
+`SecurityLanding.tsx` gained a page-level `screen` state — `landing | call | calling` —
+swapped with `SwapFade` using the **mock's app-shell timings** (`outMs 240`, `inMs 460`,
+`rise 12`, `drop 18`). `backToOverview` resets the recap rotation and scrolls to top.
+
+1. **`SecurityCallNow.tsx`** (new) — the mock's security *CallNow* screen: trust column,
+   **business email** field with a live hint (*"we'll assess the domain **acme.com**"*,
+   derived by `emailDomain`), and a masked phone field. Submit is enabled only when
+   `isValidEmail` **and** `isViablePhone` (`isCallFormComplete`).
+2. **`SecurityCalling.tsx`** (new) — the mock's *Success* screen in calling mode:
+   `dialing` → **Connected** with an `mm:ss` timer → **End call** → **Call ended** with a
+   recap, **Copy**, and three exits: *Call me again* / *Book a meeting* (booking link) /
+   *Back to overview*.
+3. **`lib/securityCallFlow.ts`** (new) — the pure helpers, all unit-tested:
+   `fillTokens`, `emailDomain`, `isCallFormComplete`, `formatCallTimer`, and the
+   recap-summary rotation (short / medium / large by visit count).
+
+Entry points: the drawer's new **"Call me now"** button (see
+[landing-chat-drawer.md](landing-chat-drawer.md)) via `ChatPanel`'s new `onCall` prop.
+All copy lives in `src/content/security.ts` under the new `callNow` and `calling` groups
+plus `talos.callCta`.
+
+### Why new screens instead of reusing the studio ones
+
+`src/flow/screens/CallNow.tsx` and `Success.tsx` (the parked studio funnel) read the
+studio **`CampaignBundle` + lead contexts**, which `/landing` does not provide, and the
+studio `CallNow` has **no email field** at all (the studio funnel primes identity from
+`?hsContactId`). Reuse would have meant threading bundle/lead plumbing into a static
+marketing page.
+
+### Deliberate deviations from the mock
+
+- **No `AmbientQuestions`** — that component is bundle-driven.
+- Recap has **Copy** but **no Share sheet**.
+- The mock's *"Schedule a call"* became **"Book a meeting"** (booking link), because
+  `/landing` has no schedule screen.
+- Footnote **Privacy / Terms are live `togatech.com` links** (funnel precedent), not the
+  mock's inert `#` hashes.
+
+## The real path — `POST /api/landing-call` (wired, dormant)
+
+Built as a **separate route from `/api/call-now`** because the landing visitor is
+**anonymous**: there is no `?hsContactId` priming on `/landing`, so there is no HubSpot
+contact and no lead ref to work from — only the email and phone the visitor just typed.
+
+Request `{ email, phoneNumber }`. Order of operations:
+
+1. **Validate** — `isValidEmail` + `MAX_EMAIL_LENGTH`, `isValidUSPhone`.
+2. **Config gate** — require `TOGA_SECURITY_CAMPAIGN_UUID` (must be a Toga uuid) or
+   return a **503 envelope** *"Live callback is not configured"* **before any upstream
+   call**. This is what keeps the route inert without a feature flag.
+3. **Lead** — `togaLeadSink.upsertLead`, with `firstName`/`lastName` derived from the
+   email local part by the new `src/lib/leadName.ts` (`nameFromEmail`):
+   `jane.doe@…` → `Jane` `Doe`; `jdoe@…` → `Jdoe` + an **empty** lastName. Links the
+   campaign.
+4. **Dial** — `togaCallbackService.requestCall(uuid, { type: "now" }, phone)` — the
+   **same code path as `/api/call-now`** (contact write + worker fast dial; see
+   [live-call-status.md](live-call-status.md)).
+5. **Tokens** — mints the same purpose-scoped status/share tokens as the studio flow.
+
+`src/flow/landingCallApi.ts` (`submitLandingCall`) is the client seam and returns
+`{ live, statusHandle }`. **Any** non-success — 503, 400, 500, network — resolves to
+`live: false` and the screen runs the **simulation**. `SecurityCallNow`'s submit posts
+the request but **never blocks the screen advance**.
+
+### Live vs. simulation in `SecurityCalling`
+
+Mirrors the studio `Success.tsx` split, using the existing
+`useCallStatusViewModel` (see [live-call-status.md](live-call-status.md)):
+
+| | Simulation (today) | Live (once configured) |
+|---|---|---|
+| Phases | scripted dialing → connected → ended | real Vapi states: dialing → on call (real elapsed) → ended / *"We could not reach you"* |
+| Recap | static, rotating short/medium/large | the **real Vapi recap** replaces it |
+| "End call" button | shown | **hidden** — a browser cannot hang up a phone call |
+| Status unavailable | n/a | **holds at dialing** with a note; never fakes progress |
+
+Rate limiting: `/api/landing-call` was added to `src/proxy.ts`'s **call-limiter branch and
+matcher**, sharing the `/api/call-now` bucket.
+
+## Turning it on later (config only — no code change)
+
+1. Create the **cybersecurity campaign + Vapi assistant** in Toga — runbook:
+   `ai-bdr/docs/client-onboarding-sop.md` (see [call-orchestration.md](call-orchestration.md)).
+2. Set `TOGA_SECURITY_CAMPAIGN_UUID` in `.env.local` and in the **Amplify console** (it is
+   already covered by the build-time `env | grep` recipe in `amplify.yml` that materializes
+   `TOGA_*` into `.env.production` — see [web-funnel-app.md](web-funnel-app.md)).
+3. Redeploy (console vars only reach a build that starts **after** they are saved).
+
+**Rejected alternatives (do not redo them):**
+
+- *Remove the route until the campaign exists* — it would simply be rebuilt later; the
+  env gate already makes it inert.
+- *Point it at a healthcare campaign to test with a real phone* — **do not**. The
+  assistant would pitch the wrong offer to a real person.
+
+## Open items before the first live run
+
+- **An empty `lastName` on an email-only lead is UNVERIFIED against Toga.** `jdoe@…`
+  produces `Jdoe` + `""`; nobody has confirmed Toga accepts that on `upsertLead`.
+- **The deployed environment needs `TOGA_VAPI_TOKEN`** for live status to render. Without
+  it the call still happens, but the screen **holds at dialing with the unavailable note**
+  — by design, not a bug.
+- The recap's "Book a meeting" inherits the landing page's booking-link problem (see
+  [security-landing-page.md](security-landing-page.md)).
+
+## Gotchas
+
+- **Two campaign systems, same product.** See the table above. A Talos `campaign_id` in
+  `TOGA_SECURITY_CAMPAIGN_UUID` fails the uuid/Toga check and the route 503s — which
+  looks exactly like "not configured," so check *which* id you pasted before debugging.
+- **The 503 is a designed state, not an error to fix.** A dormant route returning
+  *"Live callback is not configured"* is the expected production behavior today.
+- **Never let the network decide the UX.** `submitLandingCall` is fire-and-continue: the
+  screen advances regardless, and only the *content* (real vs. simulated) depends on the
+  response.
+- **No "End call" on the live path.** If you see one during a live call, the live/sim
+  branch is wrong — the browser has no way to hang up a Vapi phone call.
+- **An anchor styled as `.btn` renders smaller than a real `<button>` sibling** unless
+  `font-size` is pinned — see the drawer doc's gotcha; the same trap produced the
+  oversized "Book a meeting" button this session.
+
+## How to work on it
+
+- 18 new Vitest tests: `test/securityCallFlow.test.ts` (9) and
+  `test/landingCallRoute.test.ts` (9).
+- Verified 2026-08-26: `tsc` clean, `eslint` clean, **vitest 385/385**, `next build`
+  clean — the route builds as `ƒ /api/landing-call` and **`/landing` stays prerendered
+  static** (the call screens are client-side; the POST only happens on submit).
+- **Nothing is committed** — all of it lives in the `bdr` working tree; the developer
+  merges and commits.
+
+## Change history
+- 2026-08-26 — Initial doc. BUILT the `/landing` "Call me now" flow: `ChatPanel` gained an
+  `onCall` prop and a "Call me now" action above "Book a meeting"; new `SecurityCallNow` /
+  `SecurityCalling` screens driven by a page-level `landing|call|calling` state in
+  `SecurityLanding` (SwapFade on the mock's app-shell timings), new pure helpers in
+  `lib/securityCallFlow.ts`, and new `callNow`/`calling` content groups. BUILT the REAL
+  callback path — `POST /api/landing-call` for ANONYMOUS visitors (validate → require
+  `TOGA_SECURITY_CAMPAIGN_UUID` else 503 before any upstream call → `upsertLead` with a
+  name derived from the email local part via new `lib/leadName.ts` → `requestCall` on the
+  same path as `/api/call-now` → purpose-scoped status/share tokens), the
+  `submitLandingCall` client seam, the live/sim split in `SecurityCalling`, and the
+  `/api/call-now` rate-limit bucket. DECIDED to keep it **dormant** until the campaign
+  exists (enabling is config only); rejected deleting the route and rejected testing
+  against a healthcare campaign. DISCOVERED the Talos chat campaign id is NOT a Toga
+  dialer campaign and that prod has only two healthcare dialer campaigns — no
+  cybersecurity campaign or Vapi assistant exists, which is the real blocker. Open:
+  empty-`lastName` acceptance and `TOGA_VAPI_TOKEN` in the deployed env. tsc/eslint clean,
+  385/385 tests, `/landing` still prerendered static. Uncommitted at capture. (tcox)

package/knowledge/2.0/apps/ai-bdr/features/landing-chat-drawer.md

@@ -6,7 +6,7 @@ project: AI-BDR
 client: shared
 type: feature
 status: active
-updated: 2026-08-25
+updated: 2026-08-26
 owners: [tcox]
 files:
   - bdr/src/components/ChatPanel.tsx
@@ -19,6 +19,7 @@ files:
   - bdr/test/chatMarkdown.test.ts
 related:
   - security-landing-page.md
+  - landing-call-flow.md
   - campaign-chat-handoff.md
   - web-funnel-app.md
   - ../../toga-blox/features/talos-assistant.md
@@ -92,11 +93,22 @@ in the adapter).
   into the response type by `toTalosResponse()`. The backend's **silent
   lead/qualification fields are never read** — deliberate, per the handoff.
 
+## Drawer actions (both render as of 2026-08-26)
+
+The drawer's action row under the message list now carries **two** buttons, in the
+mockup's order:
+
+1. **"Call me now"** — new 2026-08-26, driven by `ChatPanel`'s new **`onCall` prop**. It
+   swaps `/landing` to the call screens; the flow, its dormant real backend, and the
+   Talos-chat-vs-Toga-dialer campaign distinction live in
+   [landing-call-flow.md](landing-call-flow.md). **(This corrects the previous "Call me
+   now is NOT rendered" note** — that was true only while the sole destination was the
+   parked studio call screen. Purpose-built landing screens replaced that dead end.)
+2. **"Book a meeting"** — an `<a>` to the same booking href as the page's primary CTA
+   (still the dead Calendly link; see [security-landing-page.md](security-landing-page.md)).
+
 ## Deliberate deviations from the mockup drawer
 
-- **"Call me now" is NOT rendered.** Its destination is the parked studio call screen,
-  unreachable from this page. The standing drawer action is **"Book a meeting"** →
-  the same Calendly href as the page's primary CTA.
 - **`cta` and `cited_slides` are captured and typed but not rendered yet.** Both are
   clean follow-ups; `cited_slides` additionally needs `GET /api/ai/campaign/{id}` plus
   presigned-URL freshness handling (those URLs expire ~7 days — see the handoff).
@@ -128,15 +140,36 @@ So the decision: build the shell now, swap it later.
   documented theming ceiling), so even fully themed it will **not** match the security
   mockup drawer pixel-for-pixel. Accept that at swap time or fund the spacing-token pass.
 
+**Status 2026-08-26 — decision re-affirmed: keep the disposable bridge shell.** A note to
+**apeterson** is **drafted but not yet sent** (the developer will send it). What it has to
+cover, so the alignment conversation starts from facts:
+
+- our adapter **already matches his `TalosAdapter` seam** and is **wired live**;
+- the two blockers are still blox-side and unscheduled — **unpublished to npm**, and
+  **React `^18` peers vs. BDR's React 19**;
+- the **design divergence** the security mock introduces versus blox `TalosPanel`: the
+  **"Call me now" / "Book a meeting" action buttons under the message list**, and the
+  cobalt **`.security-shell` theme**. Those must be reconciled as **blox props/theme vs.
+  app-side composition** before a swap is possible — that decision is the real gate now,
+  not just publishing.
+
 ## Styling
 
 The `.chatveil` / `.chatpanel` block was ported from the security mockup's `styles.css`
 into `security.css` and is **scoped under `.security-shell`** like every other landing
-rule. (The source mockup folder was deleted from the repo on 2026-08-25; `security.css`
-is now the only copy of these styles.) `z-index: 120`, width `min(400px, 92vw)`, reduced-motion respected.
+rule. (**Correction to an earlier note:** the mockup folder was deleted 2026-08-25 but
+**re-added 2026-08-26**, so `security.css` is *not* the only copy — the mockup is back in
+the repo as the design reference. `security.css` remains the only *shipped* copy.)
+`z-index: 120`, width `min(400px, 92vw)`, reduced-motion respected.
 `.chatmd-p` / `.chatmd-list` carry the reply rhythm. Escape and scrim click close the
 drawer; focus moves into the composer on open and is restored to the opener on close.
 
+**Action-row sizing (fixed 2026-08-26).** "Book a meeting" rendered visibly larger than the
+mockup's. Root cause: the mockup's chat actions are `<button>`s, which browsers draw at the
+~13.3px default button font because `.btn` never sets `font: inherit`; ours is an `<a>`
+inheriting the panel's body size. Both are now pinned:
+`.security-shell .chatactions .btn{font-size:13.5px;padding:0 16px;min-height:44px}`.
+
 ## Gotchas
 
 - **`api.togaiq.com` chat endpoints are origin/UA-gated — verified 2026-08-25 with
@@ -157,21 +190,38 @@ drawer; focus moves into the composer on open and is restored to the opener on c
   any merged/trimmed turns would break the strict alternating shape and return a 422.
 - **The chat is fully client-side**, which is why `/landing` still builds as a
   **prerendered static** route. Adding a server call here changes that.
-- **`/landing` is not rate-limited** (`src/proxy.ts` matches only `/` and the five API
-  routes). The drawer talks to a third-party origin, not a BDR API route, so the
-  limiter still does not apply — but the abuse surface now exists on the page.
+- **`/landing` is not rate-limited** (`src/proxy.ts` matches `/` and the API routes, not
+  the page). The drawer talks to a third-party origin, not a BDR API route, so the limiter
+  still does not apply to *chat* — but the abuse surface exists on the page. The drawer's
+  new "Call me now" action does hit a BDR route, and that one **is** limited
+  (`/api/landing-call`, on the `/api/call-now` bucket).
 
 ## How to work on it
 
 - 30 new Vitest tests across `test/talosChat.test.ts` and `test/chatMarkdown.test.ts`
   (message-shape rules including the 30-cap alternation, 401 re-mint-once, fallback on
   network error and on 5xx, alternation preserved across a fallback turn, adapter
-  reset, markdown safety). Suite **367/367 green**; `tsc`, `eslint` (incl. the
-  no-em-dash rule), and `next build` all clean as of 2026-08-24.
-- **Nothing is committed** — the drawer lives in the `bdr` working tree only, awaiting
-  the developer's branch/commit go-ahead.
+  reset, markdown safety). Suite **385/385 green** as of 2026-08-26 (was 367 before the
+  call-flow tests); `tsc`, `eslint` (incl. the no-em-dash rule), and `next build` all clean.
+- **Shipped state:** the drawer landed on `_dev-sandbox` via **TRUE-80965**, merged by the
+  developer 2026-08-25. **TRUE-80966** ("Connect Talos UI to Backend Services") is
+  engineering-complete — chat is live from allowlisted origins — but **acceptance is
+  pending** on three items: the sandbox **origin allowlist**, rendering of **`cta` /
+  `cited_slides`**, and the **absent CRM lead sink**. The 2026-08-26 action-row changes are
+  uncommitted working tree.
 
 ## Change history
+- 2026-08-26 — The drawer now renders **both** mockup actions: a new **"Call me now"**
+  button (via `ChatPanel`'s new `onCall` prop) above "Book a meeting" — **reversing** the
+  2026-08-24 decision not to render it, which only held while the destination was the
+  parked studio call screen (see [landing-call-flow.md](landing-call-flow.md) for the new
+  screens). FIXED "Book a meeting" rendering too large (`<a>` inherits body size, sibling
+  `<button>`s use the ~13.3px browser default; both pinned in `.chatactions .btn`).
+  CORRECTED the styling note — the security mockup was re-added to the repo on 2026-08-26,
+  so `security.css` is only the *shipped* copy, not the *only* copy. Re-affirmed the
+  TRUE-80692 "keep the disposable bridge shell" decision and recorded the drafted (not yet
+  sent) note to apeterson, including the new design divergence — action buttons + cobalt
+  theme — that must be reconciled as blox props/theme vs. app-side. (tcox)
 - 2026-08-25 — Verified the origin gate with browser-shaped probes: `localhost:3000` is
   allowed and returns live replies end-to-end; `bdr.dev.sandbox.togatech.com` gets 403 at
   session mint (not allowlisted → deployed drawer runs on scripted fallback). Recorded the

package/knowledge/2.0/apps/ai-bdr/features/live-call-status.md

@@ -6,7 +6,7 @@ project: AI-BDR
 client: shared
 type: feature
 status: active
-updated: 2026-07-29
+updated: 2026-08-26
 owners: [tcox]
 files:
   - bdr/src/server/vapiCall.ts
@@ -24,6 +24,7 @@ files:
   - bdr/src/content/default.ts
   - bdr/src/proxy.ts
 related:
+  - landing-call-flow.md
   - web-funnel-app.md
   - vapi-integration.md
   - call-orchestration.md
@@ -144,6 +145,13 @@ rules that are specific to this feature:
   looks fake in this environment" is an **env** symptom, not a code bug.
 
 ## Change history
+- 2026-08-26 — **Second consumer:** `/landing`'s new `SecurityCalling` screen reuses this
+  pipeline unchanged (`useCallStatusViewModel` + `/api/call-status` + the same
+  purpose-scoped status token), fed by the new `POST /api/landing-call` for anonymous
+  visitors. Two behavior notes specific to it: it shows **no "End call" button on the live
+  path**, and an **unavailable** status **holds at dialing** rather than faking progress.
+  The route is env-gated and currently dormant — see
+  [landing-call-flow.md](landing-call-flow.md). No change to this feature's own code. (tcox)
 - 2026-07-29 — Created. BUILT the live call-status pipeline: `src/server/vapiCall.ts` reads
   `GET https://api.vapi.ai/call/{id}` with the worker's Vapi bearer credential and drives a real
   dialing / active / ended / not-answered lifecycle on the Success screen (replacing the ~5s

package/knowledge/2.0/apps/ai-bdr/features/security-landing-page.md

@@ -6,12 +6,15 @@ project: AI-BDR
 client: shared
 type: feature
 status: active
-updated: 2026-08-25
+updated: 2026-08-26
 owners: [tcox]
 files:
   - bdr/src/app/landing/page.tsx
   - bdr/src/app/security.css
   - bdr/src/flow/screens/SecurityLanding.tsx
+  - bdr/src/flow/screens/SecurityCallNow.tsx
+  - bdr/src/flow/screens/SecurityCalling.tsx
+  - bdr/src/lib/securityCallFlow.ts
   - bdr/src/content/security.ts
   - bdr/src/components/LogoSymbol.tsx
   - bdr/src/components/AssistantMark.tsx
@@ -24,6 +27,7 @@ files:
   - bdr/eslint.config.mjs
 related:
   - landing-chat-drawer.md
+  - landing-call-flow.md
   - campaign-chat-handoff.md
   - web-funnel-app.md
   - web-funnel-content-model.md
@@ -38,19 +42,21 @@ and the 7-screen Agent Studio funnel is parked (see `web-funnel-app.md`). Its jo
 conversion: *"Book your free risk assessment."*
 
 It is a **pixel-faithful port of a designer mockup**, not new design work. The source
-mockup lived at `BDR/AI BDR - Security/` (a React 18 UMD + in-browser Babel prototype —
-`app.jsx`, `screens.jsx`, `components.jsx`, `styles.css`, plus a
-`ground-truth-tokens-and-stack.md` token spec) but **was deleted from the repo on
-2026-08-25 — the port is complete and the shipped code in `src/` is now the only
-reference.** The landing is that mockup's **`Capabilities` screen**; because
-`src/flow/screens/Capabilities.tsx` already exists as a studio screen, it was ported
-under the name **`SecurityLanding`**.
-
-**Status (updated 2026-08-24): one live backend, nothing else.** The page now carries a
-**Talos chat drawer wired to the real campaign-chat backend** — see
-[landing-chat-drawer.md](landing-chat-drawer.md), which owns that subject. Everything
-else is still UI only: no form, no lead capture, no Toga/HubSpot call, no analytics
-events of its own.
+mockup lives at **`BDR/AI BDR - Security/`** — a React 18 UMD + in-browser Babel prototype
+(`app.jsx`, `screens.jsx`, `components.jsx`, `styles.css`, plus a
+`ground-truth-tokens-and-stack.md` token spec). **History, because an earlier capture got
+it wrong:** the folder was deleted on 2026-08-25 (port believed complete) and then
+**RE-ADDED by the developer on 2026-08-26** — it is **in the repo today** and is the
+standing design reference for further porting. The landing is that mockup's
+**`Capabilities` screen**; because `src/flow/screens/Capabilities.tsx` already exists as a
+studio screen, it was ported under the name **`SecurityLanding`**.
+
+**Status (updated 2026-08-26): two backends wired, one of them dormant.** The page carries
+a **Talos chat drawer wired to the real campaign-chat backend** — see
+[landing-chat-drawer.md](landing-chat-drawer.md) — and, as of 2026-08-26, a **"Call me
+now" flow with a real (but env-gated, currently inert) callback route**, which is its own
+subject in [landing-call-flow.md](landing-call-flow.md). That call flow is the page's
+**first form and first lead capture**. Still absent: landing-specific analytics events.
 
 ## Page structure
 
@@ -61,6 +67,11 @@ events of its own.
 screen — **carries its own page shell**: the noise layer, the mote field, the topbar
 lockup, and the header CTA. There is no shared layout wrapper for it.
 
+Since 2026-08-26 `SecurityLanding` is also a **tiny router**: a page-level `screen` state
+(`landing | call | calling`) swaps the marketing page for the call screens via `SwapFade`.
+The marketing sections below are the `landing` case; see
+[landing-call-flow.md](landing-call-flow.md) for the other two.
+
 Section order inside the shell:
 
 1. **Hero** (`.lp-hero`) — eyebrow, headline whose closing clause is the TOGA gradient
@@ -127,9 +138,12 @@ does not define or defines differently.
   was verified byte-identical**, so the 7 existing studio screens do not shift. Any future
   change here must keep that property.
 - **`LogoSymbol.tsx`** / **`AssistantMark.tsx`** — new inline-SVG marks.
-- **`eslint.config.mjs`** — a `"AI BDR - Security/**"` `globalIgnores` entry existed
-  while the mockup was in the repo; it was removed with the mockup on 2026-08-25 (the
-  studio flow's `mockup/**` entry remains).
+- **`eslint.config.mjs`** — the `"AI BDR - Security/**"` `globalIgnores` entry is
+  **present and required**. It was removed alongside the 2026-08-25 mockup deletion and
+  **restored on 2026-08-26** when the mockup came back; lint is clean with it. (The studio
+  flow's `mockup/**` entry is separate and has always been there.) If the mockup folder is
+  ever removed again, remove this entry with it — and if you see lint errors in
+  Babel-flavored `.jsx`, this entry is what is missing.
 
 ## CTA wiring (read this before assuming the page converts)
 
@@ -153,6 +167,13 @@ does not define or defines differently.
   the mockup's "Ask Me Anything") both **open the Talos chat drawer** as of 2026-08-24.
   Neither is inert any more. The drawer, its backend adapter, and its offline fallback
   are documented in [landing-chat-drawer.md](landing-chat-drawer.md).
+- **"Call me now"** (new 2026-08-26, in the drawer's action row above "Book a meeting")
+  swaps the page to the call screens. The backend behind it is **real but dormant** —
+  `POST /api/landing-call` 503s until `TOGA_SECURITY_CAMPAIGN_UUID` is set, and no
+  cybersecurity Toga campaign exists yet, so the flow currently runs its **simulation**.
+  Full detail, including the *do-not-confuse-these* Talos-chat-vs-Toga-dialer campaign
+  distinction and the enable-later runbook, in
+  [landing-call-flow.md](landing-call-flow.md).
 
 ## Responsive / mobile pass (original work, not ported)
 
@@ -171,11 +192,16 @@ ported. All of it is scoped under `.security-shell`.
 
 ## How to work on it
 
-- `npx tsc --noEmit`, `npm run lint`, `npm run build` — all clean as of 2026-08-24;
-  `/landing` builds as a **prerendered static** route. Local prod smoke test:
-  `GET /` → `307` with `Location: /landing`, `GET /landing` → `200`.
-- **Nothing is committed** — as of capture the whole landing lives in the `bdr` working
-  tree only. It is not shipped or deployed.
+- `npx tsc --noEmit`, `npm run lint`, `npm run build`, `npx vitest run` — all clean as of
+  2026-08-26 (385/385 tests); `/landing` still builds as a **prerendered static** route.
+  Local prod smoke test: `GET /` → `307` with `Location: /landing`, `GET /landing` → `200`.
+- **Shipping state:** the landing + chat drawer landed on `_dev-sandbox` via **TRUE-80965**
+  ("integrate Talos UI into landing"), merged by the developer 2026-08-25 — one conflict in
+  `security.ts`, resolved to the TRUE-80965 side. **TRUE-80966** ("Connect Talos UI to
+  Backend Services") is engineering-complete (chat is live from allowlisted origins) but
+  **acceptance is pending**: the sandbox origin allowlist, rendering of `cta` /
+  `cited_slides`, and the absent CRM lead sink. The 2026-08-26 call-flow work is
+  **uncommitted working tree** — the developer merges and commits.
 
 ## Known gaps / pending work
 
@@ -186,7 +212,12 @@ ported. All of it is scoped under `.security-shell`.
 - **Chat drawer's origin allowlist is not done** — `api.togaiq.com` is origin/UA gated,
   so until localhost / sandbox / prod domains are allowlisted the drawer silently answers
   from its scripted fallback (see [landing-chat-drawer.md](landing-chat-drawer.md)).
-- No form, no lead capture, no landing-specific analytics.
+- **No cybersecurity Toga campaign / Vapi assistant exists**, so the "Call me now" path
+  cannot place real calls. Owned outside the `bdr` repo; see
+  [landing-call-flow.md](landing-call-flow.md).
+- No landing-specific analytics events.
+- ~~No form, no lead capture~~ — **the call flow added both 2026-08-26** (email + phone →
+  `upsertLead`), though the lead write only fires once the campaign env var is set.
 - ~~Mobile pass pending~~ — **done 2026-08-24** (see *Responsive / mobile pass* above).
 - ~~Chat drawer not ported~~ — **done 2026-08-24**, and wired to the real backend rather
   than re-creating the mockup's scripted-only behavior.
@@ -201,36 +232,66 @@ ported. All of it is scoped under `.security-shell`.
   `Capabilities.tsx` is a *studio* screen — hence `SecurityLanding.tsx`. Likewise
   `src/flow/screens/Landing.tsx` is a **studio** screen and has nothing to do with the
   `/landing` route. Check which is meant before editing either.
-- **`.btn` does not reset anchor styling.** Every studio `.btn` is a `<button>`, so
-  studio.css never needed `text-decoration:none`. The landing's primary CTA is an `<a>`,
-  which arrives underlined — a scoped `.security-shell a.btn{text-decoration:none}` rule
-  fixes it. Any future anchor-as-button elsewhere hits the same trap.
+- **`.btn` does not reset anchor styling — in TWO ways.** Every studio `.btn` is a
+  `<button>`, so studio.css never needed to normalize anchors.
+  1. *Underline.* An `<a class="btn">` arrives underlined; scoped
+     `.security-shell a.btn{text-decoration:none}` fixes it (and a matching
+     `.ended-cta a.btn` reset was needed for the call-recap buttons, 2026-08-26).
+  2. *Font size (found 2026-08-26).* A real `<button>` renders at the browser's ~13.3px
+     default button font unless `font: inherit` is set, while an `<a>` inherits its
+     container's body size — so **an anchor-as-`.btn` sitting next to real buttons looks
+     visibly larger**. That was the root cause of the "Book a meeting" drawer button being
+     oversized; the fix pins the size for both:
+     `.security-shell .chatactions .btn{font-size:13.5px;padding:0 16px;min-height:44px}`.
+     Whenever you mix anchor and button actions in one row, pin `font-size`.
 - **`Particles` default behavior must stay byte-identical.** The new `palette`/`bold`/
   `radiate` props are additive on purpose; the 7 studio screens depend on the untouched
   default path.
-- **Nothing further can be ported from the security mockup — it was deleted from the
-  repo (2026-08-25).** The chat drawer (see `landing-chat-drawer.md`) was the last piece
-  ported before deletion. Historical note: that mockup's `styles.css` carried the same
-  literal-`\n` corruption class as `mockup/styles.css` (a JS-string generation artifact,
-  see `web-funnel-app.md`) — the standing gotcha still applies to the studio `mockup/`
-  folder, which remains in the repo.
+- **The security mockup IS in the repo — do not trust the 2026-08-25 "deleted" note.**
+  It was deleted on 2026-08-25 and **re-added on 2026-08-26**; `BDR/AI BDR - Security/` is
+  the live design reference again (the call screens were ported from it). Check the working
+  tree before assuming either way. Its `styles.css` carries the same literal-`\n`
+  corruption class as `mockup/styles.css` (a JS-string generation artifact, see
+  `web-funnel-app.md`) — treat ported CSS accordingly.
 - **No `<head>` resource surprises this time**, but the standing rule from the first port
   still applies: a font named in ported CSS is not a loaded font. The landing rides
   `layout.tsx`'s existing Plus Jakarta Sans.
-- **`/landing` is not rate-limited.** `src/proxy.ts`'s matcher covers only `/` and the
-  five API routes, so the landing bypasses the limiter entirely. That is correct today
-  (the page is static and reads no contact data), but it stops being correct the moment
-  the page gains a form or reads a query param.
+- **`/landing` itself is still not rate-limited** — `src/proxy.ts`'s matcher covers `/`
+  and the API routes, not the page. The page now **has a form** (the call flow), but the
+  abuse surface is the API route, and **`/api/landing-call` WAS added to the matcher and
+  shares the `/api/call-now` limiter bucket** (2026-08-26). The rule stands for anything
+  new: a page-level read of a query param or contact data would still need the matcher
+  widened.
+- **`src/content/security.ts` is CRLF.** A `\n`-only regex will not match its line
+  endings — that silently defeated a scripted merge-conflict resolution during the
+  TRUE-80965 merge (resolved by hand to the TRUE-80965 side). Use `\r?\n` in any script
+  that rewrites this file.
 
 ## Change history
+- 2026-08-26 — **CORRECTION to the 2026-08-25 entry below:** the developer **re-added**
+  `BDR/AI BDR - Security/` on 2026-08-26. The mockup is in the repo and is the standing
+  design reference; the `"AI BDR - Security/**"` `globalIgnores` entry in
+  `eslint.config.mjs` was **restored** with it (lint clean). The porting gotchas are live
+  again, not retired. (tcox)
+- 2026-08-26 — BUILT the **"Call me now" flow** on the page (design-lead review) and the
+  real-but-dormant `POST /api/landing-call` behind it; `SecurityLanding` became a
+  `landing|call|calling` SwapFade router over the new `SecurityCallNow`/`SecurityCalling`
+  screens. This gives the page its **first form and first lead capture**. Own doc:
+  [landing-call-flow.md](landing-call-flow.md). FIXED the oversized drawer "Book a meeting"
+  button — root cause was `<a class="btn">` inheriting the panel body size while sibling
+  `<button>`s render at the ~13.3px browser default; both are now pinned. Recorded that
+  `/api/landing-call` joined the `proxy.ts` call-limiter, and that `security.ts` is CRLF
+  (which defeated a `\n`-only conflict-resolution regex during the TRUE-80965 merge to
+  `_dev-sandbox`). tsc/eslint/build clean, 385/385 tests, `/landing` still prerendered
+  static. (tcox)
 - 2026-08-25 — VERIFIED the primary-CTA booking link is dead: the mockup's Calendly URL and
   the whole `calendly.com/toga-technology` org 404. TOGA books via Cal.com team
   `toga-technology`, which has only the healthcare `discovery-call` event type (both prod
   campaigns use it); no security event type exists. Recorded the fix path (create Cal.com
   event → set `primaryCtaHref` + campaign `cta_url`). (tcox)
-- 2026-08-25 — The source mockup folder `BDR/AI BDR - Security/` was **deleted from the
-  repo** (port complete; shipped code is the reference now). Its `eslint.config.mjs`
-  `globalIgnores` entry was removed with it; the porting-related gotchas are retired.
+- 2026-08-25 — **[SUPERSEDED 2026-08-26 — the folder was restored; see above.]** The
+  source mockup folder `BDR/AI BDR - Security/` was **deleted from the repo** (port
+  believed complete). Its `eslint.config.mjs` `globalIgnores` entry was removed with it.
   (tcox)
 - 2026-08-24 — Closed both of the doc's open gaps. BUILT the **mobile pass** as original
   work (560px and 420px breakpoints under `.security-shell`; the `.lp-value-motes` inset

package/knowledge/2.0/apps/ai-bdr/features/web-funnel-app.md

@@ -6,7 +6,7 @@ project: AI-BDR
 client: shared
 type: feature
 status: active
-updated: 2026-08-24
+updated: 2026-08-26
 owners: [tcox]
 files:
   - bdr/PLAN.md
@@ -67,6 +67,7 @@ related:
   - bdr-web-funnel-plan.md
   - live-call-status.md
   - security-landing-page.md
+  - landing-call-flow.md
   - ../architecture.md
   - ../workflows/safe-call-loop-testing.md
   - ../../worker2/features/vapi-webhook-handler.md
@@ -458,6 +459,15 @@ everything?" question in this doc:
   even in info's own code — do not carry them into BDR.
 - **BDR deploy env vars = 7 total:** the 5 server-side ones + `NEXT_PUBLIC_GA_MEASUREMENT_ID` +
   (new 2026-07-21) **`TOGA_WORKER_URL`** (the fast-dial gate; unset ⇒ cron-only).
+- **Optional 8th, deliberately UNSET (new 2026-08-26): `TOGA_SECURITY_CAMPAIGN_UUID`** —
+  declared in `.env.example`, the on/off gate for `/landing`'s real callback route. Unset ⇒
+  `POST /api/landing-call` returns a 503 *"Live callback is not configured"* before touching
+  Toga, and the landing call flow runs its simulation. **Leave it unset until a cybersecurity
+  Toga campaign + Vapi assistant exist** (none does), and never set it to a Talos chat
+  `campaign_id` — different system. See
+  [landing-call-flow.md](landing-call-flow.md). It needs no `amplify.yml` change: the
+  build-time `env | grep -E '^(HUBSPOT_|TOGA_|NEXT_PUBLIC_|RATE_LIMIT_)'` line already
+  matches `TOGA_*`.
 
 ## Local dev setup (BDR)
 
@@ -751,6 +761,12 @@ would be cached by browsers and crawlers and become painful to undo.
   harness; pull it with `npx toga-ai`.
 
 ## Change history
+- 2026-08-26 — Env-var accounting only: recorded an **optional 8th deploy var**,
+  `TOGA_SECURITY_CAMPAIGN_UUID`, declared in `.env.example` and deliberately **left unset**.
+  It gates `/landing`'s new real callback route (`POST /api/landing-call`), which 503s and
+  falls back to simulation without it; no `amplify.yml` change is needed because the
+  build-time `env | grep` recipe already matches `TOGA_*`. The funnel itself is unchanged.
+  See [landing-call-flow.md](landing-call-flow.md). (tcox)
 - 2026-08-24 — **DECIDED: `/` 307-redirects to `/landing` and the whole Agent Studio flow is
   parked.** `next.config.ts` gained `redirects()` with `permanent: false` (deliberately
   temporary so browsers/crawlers do not cache it while design settles). The new

package/knowledge/2.0/apps/toga2-supply/features/order-detail-field-config-and-customer-name.md

@@ -18,7 +18,7 @@ related:
   - ../../../../clients/elite/features/supply2-scope.md
   - ../workflows/client-host-scoping.md
   - ../architecture.md
-  - ../../_underscore/features/purchase-order-sales-order-bridges.md
+  - ../../_underscore/features/sales-order-purchase-order-bridge-direction.md
 ---
 
 ## Summary
@@ -109,7 +109,7 @@ As of 2026-08-26 that still reports `1` for `DEFAULTFIELDS.json` and the three `
 fix was drafted this session but is not present on any branch or stash.** The backend half (the
 `_purchaseOrders` calculated field reading the wrong bridge table) is a separate, independent cause
 of the same blank row; see
-[PO-to-SO bridge tables](../../_underscore/features/purchase-order-sales-order-bridges.md).
+[PO-to-SO bridge tables](../../_underscore/features/sales-order-purchase-order-bridge-direction.md).
 
 ### Which field set a host gets
 
@@ -164,7 +164,7 @@ requires **both** changes, not either one:
   covers COMPASS / COMPASSCANADA / QUAD (+ an ELITE early return), so **every other host falls
   through to `DEFAULTFIELDS`** — a default-set gap is a platform-wide gap. The four-file fix was
   drafted but is **not on any branch**; the backend half is a separate cause, see
-  [PO-to-SO bridge tables](../../_underscore/features/purchase-order-sales-order-bridges.md). (bala)
+  [PO-to-SO bridge tables](../../_underscore/features/sales-order-purchase-order-bridge-direction.md). (bala)
 - 2026-08-18 — First capture. Documented that the order-details Customer name is **hardcoded in the
   frontend**, not read from the database: every host's config uses
   `valueKey: "orderBoxDetails.customer.name"`, `orderBoxDetails` exists nowhere in the codebase or

package/knowledge/INDEX.md

@@ -28,7 +28,7 @@ _Auto-generated by `knowledge.js index`. Do not hand-edit._
 - **toga2-hub** (TOGa Hub) — 2 doc(s) → [2.0/apps/toga2-hub/INDEX.md](2.0/apps/toga2-hub/INDEX.md)
 - **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) — 12 doc(s) → [2.0/apps/ai-bdr/INDEX.md](2.0/apps/ai-bdr/INDEX.md)
+- **ai-bdr** (AI-BDR) — 13 doc(s) → [2.0/apps/ai-bdr/INDEX.md](2.0/apps/ai-bdr/INDEX.md)
 - **toga2-commerce** (TOGa Commerce) — 19 doc(s) → [2.0/apps/toga2-commerce/INDEX.md](2.0/apps/toga2-commerce/INDEX.md)
 - **toga25-supply** (TOGa 2.5 Supply) — 12 doc(s) → [2.0/apps/toga25-supply/INDEX.md](2.0/apps/toga25-supply/INDEX.md)
 - **toga-blox** (TOGa Blox) — 10 doc(s) → [2.0/apps/toga-blox/INDEX.md](2.0/apps/toga-blox/INDEX.md)

package/knowledge/clients/nychh/INDEX.md

@@ -2,5 +2,5 @@
 
 | Doc | Framework | Summary | Files |
 |-----|-----------|---------|-------|
-| [NYCHH PO links are UPSTREAM — the downstream SO→PO route returns empty](features/po-number-upstream-direction.md) | 2.0 | NYCHH's sales orders are created **from the customer's purchase order**, so their SO↔PO links live in the **upstream** table `PurchaseOrders_SalesOrders` (route | _underscore/Model/Client/SalesOrder.php, toga25-supply/src/pages/SalesOrders/view/SalesOrderRecordModalLayout/hooks/usePurchaseOrderDetails.ts, dbchanges2/Client/2026-08-11b - SalesOrderPurchaseOrdersField.sql |
+| [NYCHH PO links are UPSTREAM — the downstream SO→PO route returns empty](features/po-number-upstream-direction.md) | 2.0 | NYCHH's sales orders are created **from the customer's purchase order**, so their SO↔PO links live in the **upstream** table `PurchaseOrders_SalesOrders` (route | _underscore/Model/Client/SalesOrder.php, _underscore/Trait/Netsuite/SalesOrder.php, toga25-supply/src/pages/SalesOrders/view/SalesOrderRecordModalLayout/hooks/usePurchaseOrderDetails.ts, dbchanges2/Client/2026-08-11b - SalesOrderPurchaseOrdersField.sql, dbchanges2/Client/2026-08-25 - SalesOrderPurchaseOrdersFieldAllClients.sql |
 | [NYC Health & Hospitals](profile.md) | 2.0 | NYC Health & Hospitals (NYCHH) is a TOGA 2.0 client on the `_underscore` platform, prod schema `Client_Nychh`. | dbchanges2/Client_Nychh/2026-08-18 - InventoryUnitsItemColumns.sql, dbchanges2/Client_Nychh/2026-08-24 - FixInventoryGroupingsUnitsTopologyOverrideIds.sql |

package/knowledge/clients/nychh/features/po-number-upstream-direction.md

@@ -6,12 +6,14 @@ project: _Underscore
 client: nychh
 type: client-feature
 status: active
-updated: 2026-08-25
-owners: [apeterson]
+updated: 2026-08-26
+owners: [apeterson, bala]
 files:
   - _underscore/Model/Client/SalesOrder.php
+  - _underscore/Trait/Netsuite/SalesOrder.php
   - toga25-supply/src/pages/SalesOrders/view/SalesOrderRecordModalLayout/hooks/usePurchaseOrderDetails.ts
   - dbchanges2/Client/2026-08-11b - SalesOrderPurchaseOrdersField.sql
+  - dbchanges2/Client/2026-08-25 - SalesOrderPurchaseOrdersFieldAllClients.sql
 related:
   - ../../../2.0/apps/_underscore/features/sales-order-purchase-order-bridge-direction.md
   - ../../../2.0/apps/_underscore/features/sales-order-po-number-sourcing.md
@@ -22,7 +24,13 @@ related:
 
 NYCHH's sales orders are created **from the customer's purchase order**, so their SO↔PO links live
 in the **upstream** table `PurchaseOrders_SalesOrders` (route `purchase-order-sales-orders`,
-record 276). They have **no** downstream `SalesOrders_PurchaseOrders` rows.
+record 276). Their POs are the customer's own numbers — `EIT0011108`, `COR0015555`,
+`LOI-Woodhull` — written from NetSuite `otherRefNum` by `_Trait_Netsuite_SalesOrder`.
+
+**Refinement (prod, 2026-08-26): "no downstream rows" holds for the vast majority but not all.** Of
+822 NYCHH sales orders, **64 carry a PO in BOTH directions**, which is exactly the set where the
+list and the modal can disagree — see the open tie-break below. On prod the downstream-only base
+field resolved a PO on only **64 of 822** orders.
 
 This produced a symptom that looked like a bug and was not: the sales-order modal's PO Number came
 back as an empty array while the sales-orders **list** column showed a PO number for the same
@@ -44,16 +52,35 @@ the **upstream** table.
 
 ## Gotchas
 
-- 🚨 **Open consequence.** The shared `_purchaseOrders` calculated field reads the **downstream**
-  table (`_underscore/Model/Client/SalesOrder.php:348`). Now that the modal's PO Number binds to
-  `_purchaseOrders`, NYCHH resolves it without an `EV-8` but gets **`null` forever**. NYCHH needs an
-  **upstream counterpart** — either an upstream-aware override of `_purchaseOrders` for this tenant
-  or an upstream variant field. **No tenant precedent exists for upstream-only:** Compass USA reads
-  both, Quad and Compass Canada are downstream-only.
+- ✅ **The open consequence is addressed on `_beta` — and NOT with a per-tenant override.** The
+  shared `_purchaseOrders` field read the **downstream** table only
+  (`_underscore/Model/Client/SalesOrder.php:349`), so once the modal bound to `_purchaseOrders`
+  NYCHH resolved it without an `EV-8` and got `null`. Rather than a NYCHH-specific field, the
+  **base** field became a `COALESCE` of downstream-then-upstream, which fixed every upstream tenant
+  at once: NYCHH went from 64 to **819 of 819** orders resolving a PO, with **no existing value
+  changed** for any tenant. It sits on `_beta` / the sandbox branches, **not `_production`** — see
+  [PO Number sourcing](../../../2.0/apps/_underscore/features/sales-order-po-number-sourcing.md) for
+  the exact commits. NYCHH is also not the only upstream tenant: all 22 clients on
+  `_Trait_Netsuite_SalesOrder` write upstream.
+- 🚨 **Still open for NYCHH specifically: the 64 both-direction orders.** Downstream-first makes the
+  modal show the **vendor** PO while the list keeps showing the **customer** PO. A
+  `_Model_Nychh_SalesOrder` override preferring upstream was offered and not built. Decide which one
+  NYCHH should see before treating either surface as authoritative.
+- **The NYCHH orders list is not a template.** Its table-view join through the upstream bridge is
+  safe **only** because NYCHH's upstream bridge is coincidentally 1:1 (823 rows / 823 distinct sales
+  orders). Copying that join into a shared single-record fetch breaks Compass (up to 6,440 POs on one
+  order), Compass Canada (empty upstream bridge) and Prudential (1,868 of 26,843 upstream).
 - Do not "fix" this by adding downstream rows. The direction is correct for NYCHH's business model;
-  the shared field is what is incomplete.
+  the shared field is what was incomplete.
 
 ## Change history
+- 2026-08-26 — Closed the open `_purchaseOrders` gap: fixed in the **base** field as a
+  downstream-then-upstream `COALESCE` (not a NYCHH override), taking NYCHH from 64 to **819 of 819**
+  orders with a PO and changing no existing value; currently on `_beta`, not `_production`. Refined
+  "no downstream rows" — **64 of 822** NYCHH orders have both directions, which is the remaining open
+  question (modal would show the vendor PO, the list shows the customer PO). Recorded that the NYCHH
+  orders-list upstream join is safe only because their upstream bridge is 1:1 and must not be copied
+  into a shared fetch. (bala)
 - 2026-08-25 — Diagnosed the empty-array PO Number as a wrong-direction query (upstream data,
   downstream route); ruled out ACL and migrations; recorded the still-open `_purchaseOrders`
   downstream-only gap for this tenant (apeterson)

package/package.json

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