toga-ai 1.0.493 → 1.0.494

package/knowledge/1.0/apps/library/features/toga2-api-client-and-bridge.md

@@ -6,13 +6,15 @@ project: Library
 client: shared
 type: feature
 status: active
-updated: 2026-07-28
+updated: 2026-08-03
 owners: [jcardinal, mhammontree]
 files:
   - library/app/api/toga2.php
   - worker/crons/toga2/aig/sync_togasupply_aig.php
   - worker/crons/toga2/wje/sync_togasupply_wje.php
 related:
+  - ../../../2.0/apps/api2/features/nested-relationship-writes.md
+  - ../../../clients/aig/features/entitlement-intake.md
   - netsuite-suiteql-api-reference.md
   - netsuite-suiteql-rest-shim.md
   - ../../worker/features/netsuite-togasupply-per-client-sync.md
@@ -106,6 +108,80 @@ bool $enabled2to1, bool $enabled1to2)`. When `enabled2to1`:
 - The 1→2 direction (`enabled1to2`) is a stub (not yet implemented).
 - DB target is selected with `App_Model_Client::changeDbLinkToClientDatabase(getClientDatabaseNames()[$togaClientId])`.
 
+### TRUE-79401 payload shape — RESOLVED 2026-08-03 (nested; NO api2 work needed)
+
+**The multi-email payload shape is settled, and the 2026-07-28 library change is the COMPLETE
+implementation — zero api2/`_underscore` work is required.** (This supersedes the previous "open
+question, owner Paulina".) Sources: AIG's post-entitlements API field-mapping spreadsheet, the
+2026-05-01 Teams meeting, and the 2026-05-04 AIG email exchange.
+
+AIG's mapping document maps **both** `UserDefined3` (secondary email) **and** `UserDefined4` (third
+email) to the **same** nested collection — `Entitlements.contact.contactEmailAddresses[].emailAddress`.
+In the meeting the team looked up our own record/field names specifically to write them into that
+document ("it is called contact email addresses and the field is called email address").
+
+> **`UserDefined3` / `UserDefined4` are AIG's SOURCE-SIDE column labels only.** They are not, and
+> never were, fields to implement on our side. Verified: `UserDefined3` appears **nowhere** in
+> `api2` or `_underscore` — its only occurrences in the tree are a comment in
+> `library/app/api/toga2.php` and this doc.
+
+Correct inbound shape:
+
+```json
+"contact": {
+  "primaryContactEmailAddress": { "emailAddress": "primary@example.com" },
+  "contactEmailAddresses": [
+    { "emailAddress": "primary@example.com" },
+    { "emailAddress": "second@example.com" }
+  ]
+}
+```
+
+The primary **may** be repeated inside the collection — `syncContactToToga1Customer` de-dupes with
+`array_unique`.
+
+**Three distinct layers — only the last one is delimited.** Conflating them is the easy mistake:
+
+| Layer | Shape |
+|---|---|
+| 1. AIG → us (V2 payload) | nested `contactEmailAddresses[]` **array of objects** |
+| 2. `Client_Aig.ContactEmailAddresses` (2.0) | one **ROW** per address |
+| 3. `TOGA_AIG.Customers.emailAddress` (1.0) | a single `'; '`-joined **STRING** |
+
+The 2026-05-01 meeting's comma-vs-semicolon debate was entirely about **layer 3** (a legacy
+`varchar(255)` can only hold a string) and says nothing about the inbound payload.
+
+**Structural trap:** `contactEmailAddresses` is a **direct child collection**, so it is a **flat**
+array of objects — *not* the double-wrapped bridge-table form used by its siblings in the very same
+AIG payload (`entitlementEntitlementCoverageTypes: [{ entitlementCoverageType: {…} }]`). And a
+wrong shape does **not** error: V2 returns **201** and drops the data — see
+[api2 nested-relationship writes](../../../2.0/apps/api2/features/nested-relationship-writes.md).
+
+**Purpose is verification/lookup ONLY.** Settled 2026-05-01: "it's just for visual, this is for
+verification, it's a string." The use case is a support agent looking up a caller by **any** of
+their addresses after pulling the contract number. Multi-recipient notification (CC/BCC on TogaDesk
+tickets) was **explicitly rejected** — see the gotcha about the single-recipient registration email.
+
+### Open items (TRUE-79401)
+
+1. Confirm the library change is **merged and deployed to the prod worker** (git/deploy state not
+   verified as of 2026-08-03).
+2. **Beta verification of the nested write is outstanding.** Assert real
+   `Client_Aig.ContactEmailAddresses` **row counts** (never the HTTP status), covering **both** a
+   brand-new contact (CREATE) **and** a second entitlement for an **existing** contact (UPDATE).
+   The UPDATE path is the suspect one: the reverse back-reference injection at `V2.php:4985–4996`
+   breaks single-key forced-MATCH and explicitly names `primaryContactEmailAddress` as likely
+   affected (see the api2 doc, 2026-07-20).
+3. Give AIG's dev team a **concrete JSON example** (above), not just the
+   `contactEmailAddresses[].emailAddress` path expression, so they don't emit an array of bare
+   strings.
+4. Confirm with **Paulina** that the mapping document actually reached AIG. Risk: our 2026-05-04
+   email told AIG to send the email fields "only if they are necessary for the process" — ambiguous
+   phrasing, sent in the same breath as dropping Business Unit, which may have read as a de-scope.
+   No AIG reply. Meanwhile AIG won't enable the extra fields until we tell them the feature is live
+   → **both sides are waiting on each other.** The feature has been functionally complete since
+   2026-07-28 and is gated on **communication + verification, not development.**
+
 ### `syncWithTogadesk()` — 2.0 ⇄ 1.0 (TOGaDesk)
 
 A large bi-directional sync gated by **two checkpoint parameters** stored in 2.0 via
@@ -176,18 +252,51 @@ enable flags** and an optional `$monitorTogadeskDepartmentIds[]`:
   enough to hold several `'; '`-joined emails, so TRUE-79401 needed **no** schema/dbchanges migration
   (the earlier fear that it was ~VARCHAR(55) was wrong). `TOGA_AIG` is the 1.0 legacy DB;
   `Client_Aig` is the 2.0 prod tenant.
-- **The multi-email path is not yet exercised (open, TRUE-79401).** As of 2026-07-28 all 20
-  `Client_Aig.ContactEmailAddresses` rows are one-per-contact, and **no** api2/`_underscore` code
-  references `UserDefined3`/`UserDefined4` or creates `ContactEmailAddresses` rows. Whether an api2
-  intake mapping is still needed depends on how Staples / SA.com sends the extra emails: if they POST
-  nested `contactEmailAddresses` records to the V2 API the library change is complete; if they send
-  flat `UserDefined3`/`UserDefined4` fields expecting us to map them into email rows, an api2 intake
-  mapping must be built. Open question owned by **Paulina**.
+- **The multi-email path is not yet exercised in prod data (TRUE-79401)** — as of 2026-07-28 all 20
+  `Client_Aig.ContactEmailAddresses` rows are one-per-contact. The *payload-shape* question that
+  used to sit here is **RESOLVED** — see *TRUE-79401 payload shape* above. Verification (real row
+  counts on beta, CREATE **and** UPDATE paths) is the remaining open item.
+- **Do not "fix" the single-recipient registration email.**
+  `_Model_Aig_Entitlement::postPost` sends the Staples Protection Plan registration email to
+  `addTo($payload->contact->primaryContactEmailAddress->emailAddress)` only. That is **correct by
+  design**: TRUE-79401's scope is *verification/lookup*, and the team explicitly rejected
+  CC/BCC-ing every address onto TogaDesk tickets. Multi-recipient notification is out of scope.
+- **The dedupe `LIKE` is an equality match a stored list can no longer satisfy (latent).**
+  `syncContactToToga1Customer`'s fallback lookup is
+  `WHERE Customers.emailAddress LIKE '$primaryEmailAddress'` — **no wildcards**, so it is an
+  equality match. Now that the column can hold a `'; '`-joined list, a 1.0 row that already holds a
+  list will **not** match a primary-only lookup. Shielded in practice because dedupe is
+  authoritatively keyed on `c_togaCustomerId` first and a successful sync writes that id back to
+  2.0, dropping the contact out of the `c_togaCustomerId IS NULL` query forever. It only bites if
+  the **write-back fails after the insert succeeds** — a retry then inserts a **duplicate**
+  customer instead of matching. Hardening if it ever fires: `LIKE '%$primaryEmailAddress%'`. Note
+  this is a consequence of a deliberate deviation: the 2026-05-01 meeting said to drop the primary
+  email entirely, but the implementation retained a separately-escaped primary for this lookup (the
+  right call — dropping it would have broken legacy record matching outright).
+- **No `emailAddress2`/`emailAddress3` columns — deliberate.** The 2026-05-01 meeting explicitly
+  rejected adding extra email columns across the ~15 Toga Classic client DBs and chose the
+  delimited single field instead. That is **why TRUE-79401 has no `dbchanges` migration** — an
+  intentional decision, not an oversight. (The doc's earlier "fear that `Customers.emailAddress`
+  was ~VARCHAR(55)" traces to a garbled transcript line — "needs to fifty-five… maybe we should
+  change it to a long"; the column is `varchar(255)`. Closed.)
 - **PHP 7.2** target (prod worker/library) — no arrow functions, typed properties, `??=`, `match`.
   Lint with `C:\xampp7\php\php.exe -l`.
 
 ## Change history
 
+- 2026-08-03 — TRUE-79401 **payload shape RESOLVED** (review/no-code session; sources: AIG's
+  field-mapping spreadsheet, the 2026-05-01 Teams meeting, the 2026-05-04 AIG email). Both
+  `UserDefined3` and `UserDefined4` map to the **same** nested
+  `contact.contactEmailAddresses[].emailAddress` collection; `UserDefined3/4` are **AIG's
+  source-side labels only** and exist nowhere in `api2`/`_underscore` — so **no api2 intake mapping
+  is needed** and the 2026-07-28 library change is the complete implementation. Replaced the
+  "open question, owner Paulina" gotcha with the resolved shape + a concrete JSON example. Also
+  recorded: purpose is **verification/lookup only** (multi-recipient notification explicitly
+  rejected, so `postPost`'s single-recipient email is correct by design); the three-layer
+  payload/row/delimited-string distinction; the extra-email-columns rejection that explains the
+  absent `dbchanges` migration; and the latent wildcard-less dedupe `LIKE` vs. a stored list.
+  Remaining: deploy confirmation, beta row-count verification (CREATE **and** UPDATE), sending AIG
+  a concrete JSON example, and confirming the mapping doc reached AIG. (mhammontree)
 - 2026-07-28 — TRUE-79401: `syncContactToToga1Customer` now stores a contact's **full** email list in
   1.0 `TOGA_AIG.Customers.emailAddress` as a `CUSTOMER_EMAIL_DELIMITER` (`'; '`)-joined, deduped,
   escaped string (was primary-only) for AIG/Staples support lookup. Added

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

@@ -9,7 +9,7 @@
 | [Health-check endpoint (/health liveness short-circuit)](features/health-check-endpoint.md) | `_Controller_Index::api()` short-circuits **liveness/health-probe** requests to an HTTP 200 **before** any routing, DB bootstrap, or V2 engine work runs. | api2/Controller/Index.php |
 | [Language Translation Layer (audience.language + sidecar tables)](features/language-translation-layer.md) | Serves the same TOGa data (Item title/description/longDescription, plus item **feature** text — `Features.name`, `ItemCategoryFeatureGroups.name`, `ItemFeatures | api2/Component/Api/V2/V2.php, api2/Component/Api/V2/Response/Response.php, _underscore/Model/Core/Setting.php, _underscore/Model/Core/RecordField.php, _underscore/Model/Core/DefaultGlobalSetting.php, _underscore/Model/Client/ItemTranslation.php, _underscore/Model/Client/FeatureTranslation.php, _underscore/Model/Client/ItemCategoryFeatureGroupTranslation.php, _underscore/Model/Client/ItemFeatureTranslation.php, dbchanges2/Client/2026-06-23a - ItemTranslations.sql, dbchanges2/Client/2026-06-23b - ItemTranslationsAcl.sql, dbchanges2/Client/2026-07-13a - FeatureTranslations.sql, dbchanges2/Client/2026-07-13b - FeatureTranslationsAcl.sql, dbchanges2/Core/2026-06-23a - RecordFieldsTranslationColumn.sql, dbchanges2/Core/2026-06-23b - ItemTranslationsRecord.sql, dbchanges2/Core/2026-07-13 - FeatureTranslationsRecord.sql |
 | [Nested FK object embedding is gated by the CHILD record's own ACL](features/nested-fk-acl-embedding.md) | When the V2 JSON engine serializes a foreign-key field into a **nested object** (in `getFullModelData()`, ~V2.php L6016-6060), it re-checks the **child** record | api2/Component/Api/V2/V2.php, dbchanges2/Client_Compass/2026-07-23b - PurchaseOrdersRecordReadAcl.sql |
-| [Nested-relationship writes & child matching (link vs. create)](features/nested-relationship-writes.md) | When a 2.0 API write payload (`POST`/`PUT`) contains a **nested related object** (e.g. | api2/Component/Api/V2/V2.php |
+| [Nested-relationship writes & child matching (link vs. create)](features/nested-relationship-writes.md) | When a 2.0 API write payload (`POST`/`PUT`) contains a **nested related object** (e.g. | api2/Component/Api/V2/V2.php, _underscore/Model/Client/ContactEmailAddress.php |
 | [Record Scripts (computed/aggregate /v2 endpoints — the authoring contract)](features/record-scripts.md) | In api2 you almost never write a controller. | api2/Component/Api/V2/V2.php, _underscore/Model/Team/Sprint.php, _underscore/Model/Client/ItemFulfillment.php, _underscore/Query.php |
 | [V2 Request Logging & Where Requests Land (client vs core log DB)](features/request-logging.md) | The V2 engine logs **every inbound request** — success *and* failure, with response code and payload — and routes each log entry to the **client** log or the ** | api2/Component/Api/V2/V2.php, _underscore/Model/Client/Logs/Api.php, _underscore/Model/Core/Logs/Api.php |
 | [POST + JSON-body args for scripted APIs](features/scripted-api-post-body-args.md) | The V2 engine can run a Record Script (scripted API) for a **POST** request, and a scripted API can receive its arguments from the **JSON request body** instead | api2/Component/Api/V2/V2.php |

package/knowledge/2.0/apps/api2/features/nested-relationship-writes.md

@@ -6,10 +6,11 @@ project: API
 client: shared
 type: feature
 status: active
-updated: 2026-07-20
+updated: 2026-08-03
 owners: ["bala", "mhammontree", "tcox"]
 files:
   - api2/Component/Api/V2/V2.php
+  - _underscore/Model/Client/ContactEmailAddress.php
 related:
   - ../architecture.md
   - ../../../clients/aig/features/entitlement-intake.md
@@ -124,6 +125,33 @@ build — audit such rows before/with the deploy. First seen in AIG (TRUE-79978)
 beta/QA threw EV-12 on the injected `entitlementFulfillmentType` — see
 [AIG entitlement intake](../../../clients/aig/features/entitlement-intake.md).
 
+## A wrong-shaped nested collection returns 201 and silently drops the data
+
+V2 **ignores payload keys it does not recognize** and does not validate the *element shape* of a
+nested collection. Two distinct failure modes both return **HTTP 201 Created** with no error
+anywhere — no `messages[]`, nothing in the client `Logs` or the core/writer `Logs`:
+
+1. **Unknown / flat key.** A partner sends a source-side column label (e.g. a literal
+   `UserDefined3`) instead of the nested collection. The key is dropped; no child row is created.
+2. **Array of bare strings instead of array of objects.** `"contactEmailAddresses":
+   ["email2@domain.com"]` instead of `[{"emailAddress": "email2@domain.com"}]`. Nothing is
+   created, and any consumer doing `array_column($list, 'emailAddress')` gets an **empty** list —
+   so a downstream sync silently falls back to the primary email and the extra addresses vanish
+   with no trace.
+
+**Operational rules that follow:**
+
+- **When verifying a nested-collection integration, assert actual child ROW COUNTS** (e.g.
+  `SELECT COUNT(*) FROM Client_Aig.ContactEmailAddresses …`). **Never** treat the HTTP status as
+  evidence — a 201 proves only that the parent was written.
+- **Never hand a partner a path expression as the spec.** `contactEmailAddresses[].emailAddress`
+  does not pin element structure and reads as "an array of emails" to many developers. Always give
+  a **concrete JSON example** of the collection, objects included.
+- **Know whether the collection is direct or bridged.** A direct child collection is a **flat
+  array of objects** (`contactEmailAddresses: [{emailAddress}]`); a bridge/join collection is
+  **double-wrapped** (`entitlementEntitlementCoverageTypes: [{entitlementCoverageType: {…}}]`).
+  Both shapes routinely appear in the *same* payload, so the sibling collections actively mislead.
+
 ## Gotcha
 
 - **Nested write with only a non-identifier field silently creates duplicates.** This is a
@@ -135,6 +163,13 @@ beta/QA threw EV-12 on the injected `entitlementFulfillmentType` — see
 
 ## Change history
 
+- 2026-08-03 — Documented that V2 **silently ignores unrecognized payload keys and does not
+  validate nested-collection element shape**: both a flat/unknown key and an array of bare strings
+  (instead of an array of objects) return **HTTP 201** with the data dropped and no error logged
+  anywhere. Added the verification rule (assert child row counts, never the HTTP status), the rule
+  to give partners a concrete JSON example rather than a `collection[].field` path expression, and
+  the direct-vs-bridged collection shape distinction. Surfaced while resolving the AIG TRUE-79401
+  multi-email payload shape (`Client_Aig.ContactEmailAddresses`); no code changed. (mhammontree)
 - 2026-07-20 — Root-caused the **UPDATE-path** failure of the single-key-uuid forced-MATCH: the
   update path injects a reverse back-reference (`contactId = parent id`) into nested child objects
   at `V2.php:4985–4996` (commit `91d803f`) when the child has a back-FK to the parent, turning the

package/knowledge/2.0/apps/worker2/features/teams-transcript-export.md

@@ -6,8 +6,8 @@ project: Worker
 client: shared
 type: feature
 status: active
-updated: 2026-07-09
-owners: ["ajean", "jcardinal"]
+updated: 2026-08-03
+owners: ["ajean", "jcardinal", "mhammontree"]
 files:
   - worker2/Worker/Team/Transcripts.php
   - worker2/Config/production.ini
@@ -140,6 +140,15 @@ process is identical for all.
   those files. Acceptable as a one-off — the ledger `s3Key` is updated to match — but if you
   ever need a minimal re-file, change the move test to compare only the `YYYY-MM-DD` folder
   segment and relocate while preserving the original filename.
+- **There is NO transcript coverage before ~2026-06-12 — pre-June meetings are not in our store.**
+  `Team/Transcripts/Export` first ran successfully in production on **2026-06-12** (PR #78), and it
+  works off an **incremental watermark** with a bounded `lookbackDays`; nothing in its history shows
+  a multi-week backfill ever running. So searching `Team.TranscriptExports` /
+  `Team.TranscriptProcessing` / the `togaiq` KBs for a meeting older than ~2026-06-12 comes back
+  **empty even though the meeting WAS recorded**. Do not conclude "it wasn't recorded."
+  **Recovery path for an older meeting: Microsoft Graph** (which still retains it) or a manually
+  exported `.docx`/`.vtt` — not our own store. Hit in practice on 2026-08-03: a 2026-05-01 meeting
+  had to be supplied as a downloaded `.docx`.
 - **Cron rows cannot be `DELETE`d once they have fired.** `Core.WorkerJobs.cronJobId` has a FK
   (`WorkerJobs_CronJobs_FK`) to `CronJobs.id`, so a schedule change must `UPDATE` an existing
   row (and set `isActive = 0` on the ones being retired), not delete-and-reinsert. The historical
@@ -181,6 +190,12 @@ Policy gap; a `400` only on a UPN means the id was never resolved to a GUID. (A
 
 ## Change history
 
+- 2026-08-03 — Documented the **pre-2026-06-12 coverage gap**: `Team/Transcripts/Export` first ran in prod on
+  2026-06-12 (PR #78) and is watermark-incremental with a bounded `lookbackDays`, with no backfill
+  ever run — so any meeting older than ~2026-06-12 is absent from `Team.TranscriptExports` /
+  `Team.TranscriptProcessing` / `togaiq` despite having been recorded. Recovery is via Microsoft
+  Graph or a manual `.docx`/`.vtt` export. Found while recovering a 2026-05-01 meeting. No code
+  changed. (mhammontree)
 - 2026-07-09 — **`Export` re-architected to GRAPH-DIRECT** (merged into the ingestion pipeline).
   The `toga-private` staging bucket is dropped: `Export` is now a thin poller that records a
   discovery row and enqueues one `Process` job per transcript; `Process` downloads the VTT

package/knowledge/clients/aig/features/entitlement-intake.md

@@ -5,13 +5,14 @@ project: API
 client: aig
 type: client-feature
 status: active
-updated: 2026-07-29
+updated: 2026-08-03
 owners: ["mhammontree"]
 files:
   - _underscore/Model/Aig/Entitlement.php
   - dbchanges2/Client_Aig/2026-06-18a - TRUE-79534 AIG SaleItem codes.sql
 related:
   - clients/aig/features/contract-reconciliation.md
+  - 1.0/apps/library/features/toga2-api-client-and-bridge.md
   - 2.0/apps/api2/features/request-logging.md
   - 2.0/apps/api2/features/nested-relationship-writes.md
   - 2.0/apps/api2/architecture.md
@@ -121,6 +122,23 @@ Loading the catalog fixed intake, and because the feed re-sends outstanding cont
 **backlog of dropped contracts self-healed on the next scheduled run** — no manual back-fill was
 needed (see [contract reconciliation](contract-reconciliation.md)).
 
+## Business Unit (`UserDefined2`) — answered and DROPPED (nothing to build)
+
+AIG (Alissa, 2026-05-04) confirmed the **Business Unit / Value** field needs **nothing returned to
+AIG**: they already store it from the sale, and it is used only for **sales invoicing**, which is a
+**different process from claims invoicing** (the one we participate in). We replied asking them to
+**omit it from the API call entirely**. **No invoice-file template was ever needed.**
+
+Verified there is no dead custom field to clean up: `c_businessUnit` exists **nowhere** in
+`_underscore`, `api2`, or `dbchanges2` (the only `BusinessUnits` hits in the tree are unrelated, in
+the `forecast` repo). Corroborated by AIG's field-mapping spreadsheet, where the `UserDefined2`
+row's target column is **empty** while every other row is mapped.
+
+**This — not the extra emails — was the item actually blocking Paulina from sending the mapping
+document.** The two were conflated previously. See
+[the library bridge doc](../../../1.0/apps/library/features/toga2-api-client-and-bridge.md) for the
+resolved email-payload shape.
+
 ## Key files / entry points
 
 - **`_underscore/Model/Aig/Entitlement.php`** — `prePost(&$api, &$payload)` is the PRE-POST
@@ -223,6 +241,19 @@ this interceptor or use this dual-purpose Items pattern.
 
 ## Gotchas / known issues
 
+- **`postPost`'s SINGLE-recipient registration email is correct by design — do not "fix" it.**
+  It sends the Staples Protection Plan registration email to
+  `addTo($payload->contact->primaryContactEmailAddress->emailAddress)` only. TRUE-79401's multi-email
+  work is for **verification/lookup only** (a support agent finding a caller by any of their
+  addresses); the team **explicitly rejected** CC/BCC-ing every address onto TogaDesk tickets, so
+  multi-recipient notification is out of scope. Settled in the 2026-05-01 meeting: "it's just for
+  visual, this is for verification, it's a string."
+- **A wrong-shaped nested collection on intake returns HTTP 201 and silently drops the data.**
+  Both a flat/unknown key (a literal `UserDefined3`) and an array of bare strings
+  (`"contactEmailAddresses": ["a@b.com"]` instead of `[{"emailAddress": "a@b.com"}]`) are accepted
+  with **no error anywhere**. When verifying AIG's multi-email feed, assert **actual
+  `Client_Aig.ContactEmailAddresses` row counts** — never the HTTP status. See
+  [api2 nested-relationship writes](../../../2.0/apps/api2/features/nested-relationship-writes.md).
 - **A sale-item code missing from `Client_Aig.Items` currently produces an HTTP 500, not a clean
   "Missing AIG item ID."** In prod (TRUE-79534) a valid-but-unknown code made `$itemId` empty and
   the downstream fulfillment query threw MySQL ERROR 1064 — so the request 500'd and the contract
@@ -275,6 +306,15 @@ this interceptor or use this dual-purpose Items pattern.
 
 ## Change history
 
+- 2026-08-03 — Review-only session (no code changed). **Business Unit (`UserDefined2`) is answered
+  and dropped**: AIG (2026-05-04) needs nothing returned — it is theirs, from the sale, for **sales**
+  invoicing (not claims invoicing); we asked them to omit it from the API call and **no invoice-file
+  template was needed**. Verified `c_businessUnit` exists nowhere in `_underscore`/`api2`/`dbchanges2`,
+  so there is no dead field to clean up; the mapping spreadsheet's `UserDefined2` target column is
+  empty. This — not the extra emails — was what blocked Paulina from sending the mapping document.
+  Also recorded that `postPost`'s **single-recipient** registration email is **correct by design**
+  (TRUE-79401 is verification/lookup only; multi-recipient CC/BCC was explicitly rejected), and the
+  201-with-dropped-data trap when verifying the nested `contactEmailAddresses` feed. (mhammontree)
 - 2026-07-29 — TRUE-80179 / TRUE-79534 (**RESOLVED + correction**): the `STS_001` intake gap is
   **closed and it self-healed.** After the catalog load + collation fix shipped, AIG's next
   scheduled batch delivered all **156** outstanding `STS_001` contracts and every one succeeded

package/package.json

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