toga-ai 1.0.176 → 1.0.178

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

@@ -2,3 +2,4 @@
 
 | Doc | Summary | Files |
 |-----|---------|-------|
+| [Bundle Confirmation — Cart Preservation When Adding Add-On Services](features/bundleconfirmation-cart-preservation.md) | Fix: adding any add-on service (Data Transfer, Promotional Bundle, New PC Services, etc.) was silently removing the 1-year tech support SKU from the cart. | toga/app/togarefresh2026/servicerequests/bundleconfirmation.php |

package/knowledge/1.0/apps/toga/features/bundleconfirmation-cart-preservation.md

@@ -0,0 +1,68 @@
+---
+title: Bundle Confirmation — Cart Preservation When Adding Add-On Services
+framework: "1.0"
+repo: toga
+project: TOGa
+client: office-depot
+type: client-feature
+status: active
+updated: 2026-06-23
+owners: [snaredla]
+files:
+  - toga/app/togarefresh2026/servicerequests/bundleconfirmation.php
+related:
+  - ../../../clients/office-depot/features/togarefresh2026-linkbuilder-routing.md
+---
+
+## Summary
+Fix: adding any add-on service (Data Transfer, Promotional Bundle, New PC Services, etc.)
+was silently removing the 1-year tech support SKU from the cart. The `?services=` block in
+`bundleconfirmation.php` now only strips tech support when the service being added IS itself
+a tech support plan.
+
+## Key files / entry points
+- `toga/app/togarefresh2026/servicerequests/bundleconfirmation.php` — the `$_GET['services']`
+  block (lines ~118–150) is the only place this logic lives.
+
+## How it works
+Two callers pass `?services=` to `bundleconfirmation.php`:
+
+| Caller | Service IDs passed | Expected behavior |
+|---|---|---|
+| `techsupport.php` (lines 88, 120, 152) | 194, 195, 101900 (tech support plans) | Remove old tech support, add new, set session vars |
+| `additionalservices.php` (lines 277, 288) | Add-on IDs (categories 174, 175, 178, 179) | Append to cart only — never touch existing items |
+
+The fixed block:
+```php
+if (in_array($serviceID, $techSupportServiceIds)) {
+    // Replacing tech support — remove the old plan before adding the new selection
+    $_SESSION['cartProducts'] = array_values(array_filter(...));
+    $_SESSION['techSupportServiceId'] = $serviceID;
+    $_SESSION['selectedJobJacket'] = 2;
+}
+if (!in_array($serviceID, $_SESSION['cartProducts'])) {
+    $_SESSION['cartProducts'][] = $serviceID;
+}
+```
+
+## Data model
+Session vars touched:
+- `$_SESSION['cartProducts']` — array of service IDs in the quote
+- `$_SESSION['techSupportServiceId']` — ID of the selected tech support plan
+- `$_SESSION['selectedJobJacket']` — job jacket type (2 = tech support flow)
+
+## Gotchas / known issues
+- The old code also called `unset($_SESSION['techSupportServiceId'])` for every add-on.
+  This was also a bug — it would flip `$isTechSupportFlow` (line ~296) to false mid-session
+  even when tech support was still in the cart. The fix leaves the var alone for add-ons.
+- Four total `cartProducts` removal points exist in the 2026 service request flow. The other
+  three are all safe: McAfee replacement (`bundleconfirmation.php:103`, removes only the
+  prior McAfee ID), and two empty-value cleanups (lines ~641 and `mcafeeupdates.php:453`).
+- `$techSupportServiceIds = [194, 195, 101900]` — if a new tech support SKU is introduced,
+  this array must be updated or the new plan will be treated as an add-on (won't replace old).
+
+## Related docs
+- `clients/office-depot/features/togarefresh2026-linkbuilder-routing.md`
+
+## Change history
+- 2026-06-23 — Bug fix: add-on services no longer strip tech support from cart. (snaredla)

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

@@ -3,6 +3,7 @@
 | Doc | Summary | Files |
 |-----|---------|-------|
 | [API (api2 / TOGa API v2) Architecture](architecture.md) | `api2` is the backend powering the public **TOGa 2.0 API**. | api2/Controller/Index.php, api2/Component/Api/V2/V2.php, api2/Component/Api/Cxml/Cxml.php, api2/Component/Api/V2/Response/Response.php, api2/Config/ |
+| [Language Translation Layer (audience.language + sidecar tables)](features/language-translation-layer.md) | Serves the same TOGa data (Item title/description/longDescription, expanding later) in multiple languages without forking the schema or breaking English consume | api2/Component/Api/V2/V2.php, _underscore/Model/Core/Setting.php, _underscore/Model/Core/RecordField.php, _underscore/Model/Core/DefaultGlobalSetting.php, _underscore/Model/Client/ItemTranslation.php, dbchanges2/Client/2026-06-23a - ItemTranslations.sql, dbchanges2/Client/2026-06-23b - ItemTranslationsAcl.sql, dbchanges2/Core/2026-06-23a - RecordFieldsTranslationColumn.sql, dbchanges2/Core/2026-06-23b - ItemTranslationsRecord.sql |
 | [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 |
 | [Tickets API (/v2/tickets)](features/tickets-api.md) | The generic ticket endpoint of the 2.0 REST API. | Component/Api/V2/V2.php |
 | [AWS CodePipeline Deployment via CodeConnections (GitHub → Elastic Beanstalk)](workflows/codepipeline-codeconnections-deploy.md) | 2.0 apps (`api2`, `_underscore`) are deployed through **AWS CodePipeline**. |  |

package/knowledge/2.0/apps/api2/features/language-translation-layer.md

@@ -0,0 +1,110 @@
+---
+title: Language Translation Layer (audience.language + sidecar tables)
+framework: "2.0"
+repo: api2
+project: API
+client: shared
+type: feature
+status: active
+updated: 2026-06-23
+owners: ["jcardinal"]
+files:
+  - api2/Component/Api/V2/V2.php
+  - _underscore/Model/Core/Setting.php
+  - _underscore/Model/Core/RecordField.php
+  - _underscore/Model/Core/DefaultGlobalSetting.php
+  - _underscore/Model/Client/ItemTranslation.php
+  - dbchanges2/Client/2026-06-23a - ItemTranslations.sql
+  - dbchanges2/Client/2026-06-23b - ItemTranslationsAcl.sql
+  - dbchanges2/Core/2026-06-23a - RecordFieldsTranslationColumn.sql
+  - dbchanges2/Core/2026-06-23b - ItemTranslationsRecord.sql
+related:
+  - ./acl-permission-chain.md
+---
+
+## Summary
+
+Serves the same TOGa data (Item title/description/longDescription, expanding later) in multiple
+languages without forking the schema or breaking English consumers. English stays in the source
+table; per-language overlays live in per-table **sidecar** tables (`ItemTranslations` first).
+The caller's language is resolved once at authentication, surfaced on every response's
+`audience.language`, and embedded in the JWT; reads/writes are redirected to the sidecar in the
+**API layer** (`V2.php`) — the `_Model` ORM is untouched, so workers/crons/cXML keep returning
+base English. Missing translations fall back to English with a warning in `messages[]` (still 200).
+
+## Key files / entry points
+
+- `_underscore/Model/Core/Setting.php` — `SLUG_LANGUAGE` const + `valueIsSet()` helper (the cascade
+  resolver itself lives in V2.php, since it is a language/API concern).
+- `api2/Component/Api/V2/V2.php`:
+  - `resolveSettingValue($slug, $context)` — the 8-layer Settings-cascade resolver (private).
+  - `resolveValidLanguageCode()` — validates the resolved code against `Languages.code`, default `en`.
+  - `getTranslatedFieldValue()` / `loadTranslationSidecar()` / `shouldTranslate()` / `addTranslationFallbackWarning()` — read path.
+  - `extractTranslationWrites()` / `saveTranslationWrites()` — write path.
+  - `lookupTranslatableFieldByRecordFieldId` built in the RecordFields load (~line 200).
+- `_underscore/Model/Client/ItemTranslation.php` — the first sidecar model.
+
+## How it works
+
+**Language resolution (auth time, user auth only).** `resolveSettingValue('language', …)` walks the
+Settings Matrix in order — DefaultGlobal, DefaultApp, ClientGlobal, ClientApp, PersonaGlobal,
+PersonaApp, UserGlobal, UserApp — each overriding the previous when set. A Client/Persona layer with
+`isOverridable = 0` **locks** the value against all later layers. For the persona layers, the **first
+persona** (in the user's persona order) that sets it wins. The resolved code is validated against
+`Languages.code` (fallback `en`), embedded in the JWT `id.language` claim, and echoed on every
+response as `audience.language`. API-credential auth gets no language. Token refresh copies the claim,
+so a language change requires re-authentication.
+
+**Which fields are translatable (metadata-driven).** `Core.RecordFields.translationRecordFieldId`
+(new column, positioned after `recordId`) points a source field's RecordField at the sidecar field's
+RecordField. `buildLookups`/RecordFields-load resolves this into
+`lookupTranslatableFieldByRecordFieldId[sourceRecordFieldId] => {sidecarRecordId, sidecarField}`.
+
+**Read path (PHP `_Model::load()`, NOT a SQL JOIN — deliberate choice).** At every response
+serialization site (top-level full-model, custom-fields, FK child, both inherent-child paths)
+`getTranslatedFieldValue($record, $field, $sourceModel, $defaultValue)` is called. When a non-base
+language is active and the field is translatable, it loads the sidecar row for that source row +
+`languageId` (cached per row so multiple fields = one load) and returns the sidecar value if non-null;
+otherwise it returns the English default and queues a deduped `W*` warning.
+
+**Write path.** On create and update, `extractTranslationWrites()` pulls translatable fields out of
+the write set for a non-base language (so the English source is never overwritten), and after the
+source row saves, `saveTranslationWrites()` upserts them into the sidecar for the current language.
+Nested-child translatable writes are NOT auto-redirected — use the dedicated `/v2/item-translations`
+endpoint for those.
+
+## Data model
+
+- `Client.ItemTranslations` — `id, uuid, dtCreated, dtUpdated, itemId (FK Items, RESTRICT),
+  languageId (FK Languages, RESTRICT), title, description, longDescription`; `UNIQUE(itemId, languageId)`.
+  English stays in `Items`; sidecar holds only non-English overlays (null → English fallback).
+- `Core.RecordFields.translationRecordFieldId` — new nullable self-FK (after `recordId`).
+- `Core.Records` 331 = `item-translations` (`aclDatabase='CLIENT'`); `Core.RecordFields` 2233–2239
+  (its fields), 2240 (the self-describing `translationRecordFieldId` field).
+- `item-translations` ACL chain lives in each client DB targeting the Base role — see
+  [acl-permission-chain.md](./acl-permission-chain.md).
+
+## Client variations
+
+None — uniform across all clients. The sidecar table + ACL ship via `dbchanges2/Client/` (all client DBs).
+
+## Gotchas / known issues
+
+- The resolver/read/write deliberately use `_Model::load()` per row, not a SQL JOIN/COALESCE — less
+  SQL-efficient but the team's chosen approach; the sidecar is cached per row to avoid N-per-field loads.
+- `audience.language` reflects the *requested* language even if a given field lacks a translation; the
+  per-field fallback warning signals the English fallback.
+- The base language is `en`; when the resolved language is `en` (or API auth) all translation logic is
+  skipped and responses are byte-identical to pre-feature.
+- Migrations not yet executed at time of writing; needs live verification.
+
+## Change history
+
+- 2026-06-23 — Initial build: audience.language + JWT embedding, ItemTranslations sidecar + metadata +
+  full ACL chain, and translation-aware read/write at the API layer. Also fixed a latent autoload bug
+  by renaming `DefaultFlobalSetting.php` → `DefaultGlobalSetting.php`. (jcardinal)
+
+## Related docs
+
+- [ACL Permission Chain](./acl-permission-chain.md)
+- [api2 Architecture](../architecture.md)

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

@@ -13,3 +13,4 @@
 | [NetSuite → Forecast Open-Orders Sync (salesOrder webhook → OpenOrderItems)](features/netsuite-salesorder-open-orders-sync.md) | Webhook-driven, single-record port of the legacy open-orders importer (TRUE-79142). | worker2/Worker/Netsuite/SalesOrder.php, worker2/Worker/Netsuite.php, test/@dave/probe_salesorder_rest_shape.php, test/@dave/probe_open_order_lines.php, test/@dave/check_so_status.php, test/@dave/check_so_history.php, test/@dave/probe_so_rest_lines.php, test/@dave/probe_missing_oo_timing.php, test/@dave/probe_missing_oo_createdby.php, worker/crons/toga2/forecast2/import_open_orders.php, worker/crons/toga2/forecast2/common_import_sales_from_netsuite.php |
 | [Startech Webhook Handler (worker2)](features/startech-webhook-handler.md) | Receives inbound webhook events from Startech (Easeedesk) and creates or updates the corresponding ticket in TOGA 2.0. | worker2/Worker/Startech.php |
 | [Teams Meeting Transcript Export](features/teams-transcript-export.md) | `_Worker_Team_Transcripts` (action `Team/Transcripts/Export`) polls Microsoft Graph for Teams meeting transcripts produced by a set of organizers, classifies ea | worker2/Worker/Team/Transcripts.php, worker2/Config/production.ini, worker2/Database/TeamsTranscriptExports.sql, dbchanges2/Core/2026-06-18a - Teams Transcript Export schedule.sql |
+| [WJE Freshservice Sync (worker2)](features/wje-freshservice-sync.md) | WJE ("WJE IT", helpdesk `wje.freshservice.com`) is a **Freshservice**-based help-desk client whose tickets, contacts, assets, groups, categories, and canned res | worker2/Worker/Wje.php, _underscore/Component/Api/Wje/Wje.php, _underscore/Model/Wje/Ticket.php, _underscore/Model/Wje/TicketNote.php, _underscore/Model/Wje/Contact.php, _underscore/Model/Wje/Unit.php, _underscore/Model/Wje/TicketTeam.php, _underscore/Model/Wje/TicketCategory.php, _underscore/Model/Wje/AssetType.php, _underscore/Model/Wje/PredefinedReply.php, library/app/api/wje.php, worker/crons/toga2/wje/import_supporting_records.php, worker/crons/toga2/wje/sync_togasupply_wje.php, worker/crons/notifications/reports/wje/wje_common.php, library/app/systemmonitor/wje.php, dbchanges2/Client_Wje/2024-10-04 - WjeOnboarding.sql |

package/knowledge/2.0/apps/worker2/features/wje-freshservice-sync.md

@@ -0,0 +1,143 @@
+---
+title: WJE Freshservice Sync (worker2)
+framework: "2.0"
+repo: worker2
+project: Worker
+client: wje
+type: client-feature
+status: active
+updated: 2026-06-23
+owners: ["snaredla"]
+files:
+  - worker2/Worker/Wje.php
+  - _underscore/Component/Api/Wje/Wje.php
+  - _underscore/Model/Wje/Ticket.php
+  - _underscore/Model/Wje/TicketNote.php
+  - _underscore/Model/Wje/Contact.php
+  - _underscore/Model/Wje/Unit.php
+  - _underscore/Model/Wje/TicketTeam.php
+  - _underscore/Model/Wje/TicketCategory.php
+  - _underscore/Model/Wje/AssetType.php
+  - _underscore/Model/Wje/PredefinedReply.php
+  - library/app/api/wje.php
+  - worker/crons/toga2/wje/import_supporting_records.php
+  - worker/crons/toga2/wje/sync_togasupply_wje.php
+  - worker/crons/notifications/reports/wje/wje_common.php
+  - library/app/systemmonitor/wje.php
+  - dbchanges2/Client_Wje/2024-10-04 - WjeOnboarding.sql
+related:
+  - clients/wje/profile.md
+  - 2.0/apps/worker2/features/elite-freshservice-sync.md
+  - 1.0/apps/library/features/toga2-api-client-and-bridge.md
+  - 2.0/apps/worker2/features/startech-webhook-handler.md
+---
+
+## Summary
+
+WJE ("WJE IT", helpdesk `wje.freshservice.com`) is a **Freshservice**-based help-desk client whose
+tickets, contacts, assets, groups, categories, and canned responses are synced into TOGA. Unlike
+Startech (multi-client, resolved dynamically by `company_id`), **WJE is a single hardcoded client** —
+its IDs and credentials are baked into the integration files.
+
+Data reaches TOGA two ways: a **real-time Freshservice webhook** handled by `_Worker_Wje::Webhook`, and
+a **daily batch import** of supporting records. A separate 2-minute cron bridges Toga2 ↔ TOGaDesk (see
+`clients/wje/profile.md`).
+
+## Key files / entry points
+
+- **Webhook handler:** `worker2/Worker/Wje.php` — `abstract _Worker_Wje`, entry `Webhook($payload, $headers)`.
+  Reached via `webhook.togahub.com/wje` → WebhookIngestion Lambda → `Core.WorkerJobs` action `Wje/Webhook`
+  → SQS → EB worker.
+- **API clients (two parallel, same creds):** `_Component_Api_Wje` (`_underscore/Component/Api/Wje/Wje.php`,
+  used by worker2/2.0) and `App_Api_Wje extends App_Api` (`library/app/api/wje.php`, used by 1.0 crons).
+  Both hit `https://wje.freshservice.com` with basic auth; `send($method, $route, $payload)`, 90s timeout,
+  1s sleep between calls. **Production only — no test/stage Freshservice instance.**
+- **Crons (worker 1.0):** `crons/toga2/wje/import_supporting_records.php` (daily import),
+  `crons/toga2/wje/sync_togasupply_wje.php` (2-min Togadesk bridge),
+  `crons/notifications/reports/wje/{wje_monthly_report,wje_quarterly_report,wje_common}.php`.
+- **Models:** `_underscore/Model/Wje/*` (8 classes, see Data model).
+- **Monitoring:** `library/app/systemmonitor/wje.php` (`App_SystemMonitor_WJE`).
+
+## How it works
+
+### Real-time webhook (`_Worker_Wje::Webhook`)
+1. Payload arrives JSON-wrapped under `freshdesk_webhook` (it is Freshservice despite the name):
+   `$wjeRecord = (object)((object)json_decode($payload, true))->freshdesk_webhook;`
+2. Branches on shape: **ticket** webhook if `property_exists($wjeRecord, 'ticket_id')`; **asset** webhook
+   if `property_exists($wjeRecord, 'asset_display_id')`.
+3. **Ticket path:** upserts associated assets (`associated_asset_ids`), the requester contact
+   (`requester_id`), and the agent contact (`agent_id`). Sleeps a few seconds to dodge duplicate-ticket
+   races, then **re-fetches the full ticket** from WJE `/tickets/{id_numeric}` (the webhook body omits
+   `group_id` and category detail). Resolves the category/subcategory/item hierarchy by **name** against
+   TOGA `TicketCategories`. Upserts the ticket (by `c_wjeTicketId`) and syncs conversation notes from
+   `/tickets/{id}/conversations` (by `c_wjeConversationId`).
+4. **Asset path:** upserts the unit by asset tag `ASSET-{display_id}`, matches the contact by email when
+   `c_wjeUserId` is unavailable, and updates serial/tag/type/contact custom fields.
+
+### Daily import (`import_supporting_records.php`)
+Canned responses → `PredefinedReplies` (`c_wjeCannedResponseId`); requesters → `Contacts` (`c_wjeUserId`);
+assets → `Units` (`c_wjeAssetId`, tag `ASSET-{id}`); groups → `TicketTeams` (`c_wjeGroupId`);
+`ticket_form_fields` (field `13000126389`) → `TicketCategories` (`c_wjeCategoryId`, 3-level hierarchy).
+
+### Reports & monitoring
+`wje_common.php::generateWJEReport(...)` builds Excel metrics (SLA, first-response, resolution, reopens)
+via PhpSpreadsheet for client 153 / dept 269; monthly cron emails `serviceops@togatech.com` +
+`mhicks@togatech.com`. `App_SystemMonitor_WJE` checks every 5 min (300s window, 30-min reminders) and
+alerts `devteam@togatech.com` on Freshservice/webhook responses > 300, reading both Logs 1.0 (`API`) and
+Logs 2.0 (`Api` in `db_prod_logs_wje`).
+
+## Data model
+
+Models in `_underscore/Model/Wje/` extend the base `_Model_Client_*` and add WJE linkage fields
+(all `self::FIELD_CHAR`):
+
+| Model | Custom field(s) |
+|-------|-----------------|
+| `_Model_Wje_Ticket` | `c_wjeTicketId`, `c_wjeAgentId` |
+| `_Model_Wje_TicketNote` | `c_wjeConversationId` (unique in DB) |
+| `_Model_Wje_Contact` | `c_wjeUserId` |
+| `_Model_Wje_Unit` | `c_wjeAssetId` |
+| `_Model_Wje_TicketTeam` | `c_wjeGroupId` |
+| `_Model_Wje_TicketCategory` | `c_wjeCategoryId` |
+| `_Model_Wje_AssetType` | `c_wjeAssetTypeId` |
+| `_Model_Wje_PredefinedReply` | `c_wjeCannedResponseId` |
+
+Schema in `dbchanges2/Client_Wje/2024-10-04 - WjeOnboarding.sql` (+ `2024-10-23.sql`, `2024-10-25.sql`):
+API record, the `c_wje*` CustomRecordFields, TicketStages (Open=2, Pending=3, Resolved=4, Closed=5),
+asset type "Laptop", urgencies (Low/Normal/High/Critical), system params
+`TOGADESK_LAST_TICKET_INTEGRATION_DATETIME` / `TOGA_LAST_TICKET_INTEGRATION_DATETIME`.
+
+Hardcoded IDs: `CLIENT_UUID_WJE=c2f5180f-…`, `API_UUID_WJE=4750650f-…` (and `API_SECRET_WJE`) in
+`worker2/Worker/Wje.php`; TOGaDesk client `153`, dept `269` (internal `290`); default group
+`13000155420` / agent `13000771757`; category form field `13000126389`.
+
+## Client variations
+
+WJE-specific: single hardcoded tenant (no `company_id` resolution); requires a group on every ticket and
+falls back to the default group/agent when none is assigned. Sister Freshservice client **Elite** uses a
+parallel but separate `_Worker_Elite` handler — see related doc.
+
+## Gotchas / known issues
+
+- **W1** Payload is wrapped under `freshdesk_webhook`, not top-level. Decode with `json_decode($p, true)` then cast.
+- **W2** Webhook body is thin — `ticket_category`/`group_id` often null; the handler re-fetches `/tickets/{id_numeric}`. Don't trust the webhook body for category/group.
+- **W3** Two id forms: `ticket_id` (string "INC-46687", stored in `c_wjeTicketId`) vs `id_numeric` (46687, used in API calls). Mixing them → 404s / missed matches.
+- **W4** Webhook resolves category by **name** against TOGA `TicketCategories`; the **daily import** is what populates `c_wjeCategoryId`. A WJE rename before the import runs breaks name matching — check the import cron first.
+- **W5** Units keyed by asset tag `ASSET-{display_id}`, linked via `c_wjeAssetId`; asset webhook falls back to email matching when `c_wjeUserId` is absent.
+- **W6** Asset import catches per-asset errors and continues; if WJE revokes `/assets` API access it silently skips assets — check logs.
+- **W7** `c_wjeUserId` is the source of truth for contact identity; email is only opportunistically added.
+- **W8** `_Component_Api_Wje` is production-only — local testing hits production WJE; be careful with writes.
+- **W9** Credentials are duplicated in `_Component_Api_Wje` and `App_Api_Wje` — rotate **both**.
+- **W10** Lazy-transaction rule: write back `c_wje*` identifiers via direct model `->save()`, not an internal API round trip inside an open transaction (cf. Startech G4).
+- **W11** `json_decode($s, true)` + top-level `(object)` cast leaves nested fields as arrays — cast each level you traverse.
+- **W12** TicketStages use Freshservice status codes (Open=2 … Closed=5); status sync depends on those matching live Freshservice statuses.
+
+> Secrets (`API_SECRET_WJE`, the Freshservice password) are hardcoded in source — read them from the file
+> when needed; never copy the values into docs or commits.
+
+## Related docs
+
+- `clients/wje/profile.md` — WJE client profile + the 2-min Togadesk bridge sync.
+- `2.0/apps/worker2/features/elite-freshservice-sync.md` — sister Freshservice client.
+- `2.0/apps/worker2/features/startech-webhook-handler.md` — the multi-client webhook pattern WJE predates.
+- `1.0/apps/library/features/toga2-api-client-and-bridge.md` — `App_Api_Toga2::syncWithTogadesk`.

package/knowledge/INDEX.md

@@ -11,13 +11,13 @@ _Auto-generated by `knowledge.js index`. Do not hand-edit._
 - **webhook** (Webhook) — 1 doc(s) → [1.0/apps/webhook/INDEX.md](1.0/apps/webhook/INDEX.md)
 - **walmarttechservices** (Walmart Tech Services) — 1 doc(s) → [1.0/apps/walmarttechservices/INDEX.md](1.0/apps/walmarttechservices/INDEX.md)
 - **test** (Test) — 11 doc(s) → [1.0/apps/test/INDEX.md](1.0/apps/test/INDEX.md)
-- **toga** (TOGa) — 1 doc(s) → [1.0/apps/toga/INDEX.md](1.0/apps/toga/INDEX.md)
+- **toga** (TOGa) — 2 doc(s) → [1.0/apps/toga/INDEX.md](1.0/apps/toga/INDEX.md)
 
 ## 2.0 framework
 
 - **_underscore** (_Underscore) _(framework core)_ — 11 doc(s) → [2.0/apps/_underscore/INDEX.md](2.0/apps/_underscore/INDEX.md)
-- **worker2** (Worker) — 11 doc(s) → [2.0/apps/worker2/INDEX.md](2.0/apps/worker2/INDEX.md)
-- **api2** (API) — 5 doc(s) → [2.0/apps/api2/INDEX.md](2.0/apps/api2/INDEX.md)
+- **worker2** (Worker) — 12 doc(s) → [2.0/apps/worker2/INDEX.md](2.0/apps/worker2/INDEX.md)
+- **api2** (API) — 6 doc(s) → [2.0/apps/api2/INDEX.md](2.0/apps/api2/INDEX.md)
 - **dbchanges2** (Database Changes) _(framework core)_ — 2 doc(s) → [2.0/apps/dbchanges2/INDEX.md](2.0/apps/dbchanges2/INDEX.md)
 - **toga2-supply** (TOGa Supply) — 3 doc(s) → [2.0/apps/toga2-supply/INDEX.md](2.0/apps/toga2-supply/INDEX.md)
 - **saml** (SAML SSO Gateway) — 2 doc(s) → [2.0/apps/saml/INDEX.md](2.0/apps/saml/INDEX.md)

package/knowledge/clients/wje/INDEX.md

@@ -2,4 +2,4 @@
 
 | Doc | Framework | Summary | Files |
 |-----|-----------|---------|-------|
-| [Wiss, Janney, Elstner Associates, Inc.](profile.md) | 2.0 | Wiss, Janney, Elstner Associates, Inc. | worker/crons/toga2/wje/sync_togasupply_wje.php |
+| [Wiss, Janney, Elstner Associates, Inc.](profile.md) | 2.0 | Wiss, Janney, Elstner Associates, Inc. | worker/crons/toga2/wje/sync_togasupply_wje.php, worker2/Worker/Wje.php, worker/crons/toga2/wje/import_supporting_records.php |

package/knowledge/clients/wje/profile.md

@@ -12,19 +12,33 @@ updated: 2026-06-23
 owners: [jcardinal]
 files:
   - worker/crons/toga2/wje/sync_togasupply_wje.php
+  - worker2/Worker/Wje.php
+  - worker/crons/toga2/wje/import_supporting_records.php
 related:
   - ../../1.0/apps/library/features/toga2-api-client-and-bridge.md
+  - ../../2.0/apps/worker2/features/wje-freshservice-sync.md
 ---
 
 ## Summary
 
-Wiss, Janney, Elstner Associates, Inc. (WJE) is a TOGa Desk client integrated through the
-**1.0↔2.0 TOGaDesk bridge** (`App_Api_Toga2::syncWithTogadesk`). The cron
-`worker/crons/toga2/wje/sync_togasupply_wje.php` runs every 2 minutes and enables the **full**
-set of bridge sub-syncs (tickets both directions, ticket-notes, contacts→people, items/units→
-assets, predefined-replies, ticket-teams→groups, ticket-categories) for TOGaDesk client id 153,
-department 269 (plus internal-tickets department 290). WJE requires a group on every ticket and
-falls back to a default group/agent when none is assigned.
+Wiss, Janney, Elstner Associates, Inc. (WJE — "WJE IT") is a **Freshservice**-based help-desk
+client (`wje.freshservice.com`). It is a **single hardcoded tenant** (no dynamic `company_id`
+resolution). Data moves between WJE and TOGA on three paths:
 
-See the bridge feature doc for the mechanism. No NetSuite TOGa Supply importer runs for WJE
-(it is a help-desk integration, not a supply/procurement client).
+1. **Real-time Freshservice webhook** → `_Worker_Wje::Webhook` (worker2) — creates/updates tickets,
+   contacts, assets, groups, categories, and conversation notes, keyed by `c_wje*` custom fields.
+2. **Daily batch import** (`worker/crons/toga2/wje/import_supporting_records.php`) — imports canned
+   responses, requesters, assets, groups, and the 3-level category hierarchy.
+3. **2-minute TOGaDesk bridge** (`App_Api_Toga2::syncWithTogadesk`) — the cron
+   `worker/crons/toga2/wje/sync_togasupply_wje.php` enables the **full** set of bridge sub-syncs
+   (tickets both directions, ticket-notes, contacts→people, items/units→assets, predefined-replies,
+   ticket-teams→groups, ticket-categories) for TOGaDesk client id 153, department 269 (plus
+   internal-tickets department 290).
+
+WJE requires a group on every ticket and falls back to a default group/agent (`13000155420` /
+`13000771757`) when none is assigned. No NetSuite TOGa Supply importer runs for WJE (it is a
+help-desk integration, not a supply/procurement client).
+
+See **`2.0/apps/worker2/features/wje-freshservice-sync.md`** for the full integration (webhook
+handler, import cron, `c_wje*` models, API clients, schema, reports, monitoring, and gotchas), and
+the bridge feature doc for the `syncWithTogadesk` mechanism.

package/package.json

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