toga-ai 1.0.1090 → 1.0.1091

package/knowledge/INDEX.md

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

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

@@ -8,6 +8,7 @@
 | [Compass Canada — Item-Fulfillment TableViews (dead-Core-id 500, rebuilt onto the USA shape)](features/item-fulfillment-tableviews.md) | 2.0 | Why Compass Canada's item-fulfillment TableViews 500'd on dead Core ids and how they were rebuilt onto the USA shape; open when a Canada TableView 500s on /meta |
 | [Compass Canada: PO-to-vendor transmission monitor (Monitor/Compass/CompassCanadaPurchaseOrderTransmissionsToVendors)](features/oneuptime-po-transmissions-to-vendors-monitor.md) | 2.0 | worker2 OneUptime push monitor for Compass Canada POs the 1.0 cron has not yet sent to the vendor (Grand & Toy), plus how the Canada PO transmit cron differs fr |
 | [Compass Canada — order fulfillment status (standard base rule, no Canada override)](features/order-fulfillment-status-per-line.md) | 2.0 | Canada-specific facts for the shared Compass order fulfillment status (standard base rule since TRUE-79669); open before touching Canada order status or Canada |
+| [Compass Canada Persona Model (sector-granted vs hand-assigned)](features/persona-model.md) | 2.0 | Where each `Client_CompassCanada` persona comes from: PEOPLE cron (only "All"), sector `Locations_Personas`, or hand-assigned with nothing keeping it in step. |
 | [Compass Canada](profile.md) | 2.0 | Compass Canada is the Canadian arm of the Compass account — a separate TOGA tenant, related to but distinct from Compass USA. |
 | [Copying a Compass USA user into the Canada tenant (cross-tenant hand-add)](workflows/copying-a-us-user-into-the-canada-tenant.md) | 2.0 | Giving a Compass **USA** person a login on the Canada TechHub portal: the guarded insert chain, the uuid role/persona mapping, and the worker2 guard that stops |
 | [Grand & Toy ASN Backfill (cXML replay + CSV-to-JSON)](workflows/grand-and-toy-asn-backfill.md) | 2.0 | How to recover Compass Canada shipments whose ASN never landed (cXML replay, CSV-to-JSON, or SQL line backfill); open when replaying a G&T outage or repairing a |

package/knowledge/clients/compass-canada/features/persona-model.md

@@ -0,0 +1,58 @@
+---
+title: Compass Canada Persona Model (sector-granted vs hand-assigned)
+framework: "2.0"
+project: _Underscore
+client: compass-canada
+type: client-feature
+status: active
+updated: 2026-10-20
+owners: [bala]
+files:
+  - worker2/Worker/Client/Compass/PeopleFile.php
+  - "dbchanges2/Client_CompassCanada/2025-12-19 - Personas.sql"
+  - "dbchanges2/Client_CompassCanada/2026-01-16 - insert_locations_personas.sql"
+  - worker/crons/toga2/compasscanada/Imports2.0/create_persona.php
+related:
+  - ../profile.md
+  - ../../compass-usa/features/persona-model-and-levy-gating.md
+  - ../../../2.0/apps/_underscore/features/effective-persona-resolution.md
+  - ../workflows/copying-a-us-user-into-the-canada-tenant.md
+---
+Where each `Client_CompassCanada` persona comes from: PEOPLE cron (only "All"), sector `Locations_Personas`, or hand-assigned with nothing keeping it in step. Open before answering "who sees what" in Canada or adding a Canada persona.
+
+## Summary
+
+Prod `Client_CompassCanada` (verified 2026-10-20): **34 personas**, **5,484** active users. Canada has
+**no** Levy, Non-Levy or Corporate/Field logic; those are Compass USA only
+([US persona model](../../compass-usa/features/persona-model-and-levy-gating.md)). Persona ids mean
+different things per tenant (CA 24 = "ESFM - CGC", not Levy). Personas were created by
+`dbchanges2/Client_CompassCanada/2025-12-19 - Personas.sql` and the 1.0
+`worker/crons/toga2/compasscanada/Imports2.0/create_persona.php`.
+
+## How it works (three sources)
+
+| Source | Personas | Kept in step by |
+|---|---|---|
+| PEOPLE cron (`PeopleFile.php`, CA branch) | **All (1)** | Nightly cron |
+| `Locations_Personas` on sector nodes | Sector personas **2-26** and **30** | Location data. Sector nodes use two-digit `c_erpEntityId` codes (e.g. `05` Canteen, `11` Quebec, `17` / `24` Compass One) |
+| Hand-assigned in `Users_Personas` | Managers/VIPs (33), MacBooks (32), Admin Canada (31), Provisioning (29), CDL & Compass Network (28), WasteNot (27), Executive Assistance (34) | **Nothing.** No job adds or removes them |
+
+The effective set is the usual UNION (direct + own location + 5-hop sector), see
+[Effective persona resolution](../../../2.0/apps/_underscore/features/effective-persona-resolution.md).
+
+## Gotchas
+
+- **11 sector personas grant no kits at all:** 3, 4, 5, 6, 9, 10, 11, 12, 13, 23, 26. Users under those
+  sectors see only what "All" and any hand-assigned persona give them.
+- **Managers/VIPs (33) drifts from reality.** 984 users hold it (19 kits), but only **858 of 1,146**
+  users who manage someone have it. It is hand-assigned, so new managers never get it.
+- **Admin Canada (31)** carries the full catalogue (33 kits); its category gap is in the
+  [profile](../profile.md).
+- **The CA branch of `PeopleFile` only adds/removes "All"** (Levy rule kept verbatim, never fires in
+  Canada). The US-only VIP (35) and persona-30 branches are not tenant-gated; see the latent gaps in
+  the [US persona model](../../compass-usa/features/persona-model-and-levy-gating.md#persona-assignment-by-tenant).
+- `PeopleFile.php` has a literal SFTP credential in its class constants. Never paste its constants.
+
+## Change history
+- 2026-10-20 — Created from a read-only prod check (TRUE-82956): 34 personas / 5,484 users, the three
+  persona sources, 11 sector personas with no kits, Managers/VIPs (33) coverage gap. (bala)

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

@@ -19,7 +19,7 @@ project: _Underscore
 client: compass-canada
 type: profile
 status: active
-updated: 2026-10-18
+updated: 2026-10-20
 owners: [jcardinal, bala, tcox, apeterson, ajean, mhammontree, rgirish]
 files: []
 related:
@@ -28,6 +28,7 @@ related:
   - features/grand-and-toy-asn-import.md
   - workflows/grand-and-toy-asn-backfill.md
   - workflows/copying-a-us-user-into-the-canada-tenant.md
+  - features/persona-model.md
   - ../../2.0/apps/api2/features/cxml-shipnotice-gateway.md
   - ../compass-usa/features/approval-decision-flow.md
   - ../compass-usa/features/stranded-approval-reassignment.md
@@ -222,13 +223,9 @@ to but distinct from Compass USA. Like Compass USA it spans the **2.0** commerce
 - **Storefront French localization** (labels, submenus, orders-for-others, Get Support illustration) is
   driven by the COMPASSCANADA FIELDS JSON; the registry language key is **`fr-CA`** (not `fr`). See
   [Client Fields](../../2.0/apps/toga2-commerce/features/client-fields.md).
-- **Canada has no Levy sector — and its PEOPLE-cron persona logic is deliberately unchanged.** The
-  2026-08-06 Compass USA persona refactor split the US logic in
-  `worker2/Worker/Client/Compass/PeopleFile.php` by tenant; the **CA branch is preserved verbatim**
-  (Levy users lose persona 1, non-Levy users gain it; there is no Non-Levy persona). Verified
-  unreachable by the Levy path: `Client_CompassCanada` has **zero** locations with
-  `c_erpEntityId = 'K00000'` and **zero** users with either hardcoded Levy personnel number. See
-  [Persona Model & Levy-Sector Gating](../compass-usa/features/persona-model-and-levy-gating.md).
+- **Personas: 34, from three sources** (PEOPLE cron only manages "All"; sector personas via
+  `Locations_Personas`; the rest hand-assigned with nothing keeping them in step). No Levy, Non-Levy
+  or Corporate/Field logic in Canada. See [Canada Persona Model](features/persona-model.md).
 - **Known production defect — My Account renders a blank Persona field.** Canada is the only tenant
   with `languageSwitcher.isEnabled = true`, and its "no saved language" login branch (taken by ~98%
   of logins — only **69 of 4,655** active users have a stored language) was the one `setUser` call in

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

@@ -5,7 +5,7 @@
 | [Compass Approval-Decision Flow (Notifications & Manager Reassignment)](features/approval-decision-flow.md) | 2.0 | Compass sales-order approval-decision / notification flow — approval+CC email lists, manager reassignment, settings-driven manager (VIP) auto-approve, EN/FR loc |
 | [Compass ASN → ItemFulfillment Auto-Creation](features/asn-to-item-fulfillment.md) | 2.0 | Compass USA ASN posting auto-creates the ItemFulfillment on the upstream SalesOrder and propagates tracking at every granularity; open when working ASN→IF creat |
 | [Compass Contact Email Resolution & Crossed `primaryContactEmailAddressId` Pointers](features/contact-email-resolution.md) | 2.0 | Any Compass code reading a contact's email must assert the email row belongs to that contact (~14% of pointers are crossed); open before reading Compass contact |
-| [Corporate vs Field laptop personas — the sector-52 split (designed, NOT built)](features/corporate-vs-field-laptop-personas.md) | 2.0 | Agreed design for splitting the Compass catalogue into a Corporate laptop and a field "laptop kit": attach Corporate at sector `J00000` via `Locations_Personas` |
+| [Corporate vs Field laptop personas (Levy/Compass x Corporate/Field, PEOPLE cron)](features/corporate-vs-field-laptop-personas.md) | 2.0 | LIVE since 2026-10-13 (TRUE-82667): `PeopleFile` gives every US user a Corporate or Field laptop persona (Levy and Compass halves) by cost center / sector `J000 |
 | [Cost Centers — Unit Locations, numeric-only policy](features/cost-centers.md) | 2.0 | A Compass "cost center" is a Unit-level Location keyed by `c_erpSystemEntityId` (NOT a `CostCenters` row), numeric-only since 2026-07-06; open for cost-center d |
 | [Compass isFulfillable — Data Quality & the Type-Derived Rule](features/isfulfillable-data-quality-and-type-rule.md) | 2.0 | Why Compass storefront Qty-Fulfilled cells stay dead — `Items.isFulfillable` NULLs are structurally unreachable, some set values are wrong, and the type-derived |
 | [Compass Item Catalogs (Compass vs Agilant) & the Duplicate Items the NetSuite Sync Creates](features/item-catalogs-and-duplicate-items.md) | 1.0 | `Client_Compass.Items` is split across catalogs (Compass vs Agilant) and the NetSuite sync creates duplicate rows for one product; open first whenever a Compass |

package/knowledge/clients/compass-usa/features/corporate-vs-field-laptop-personas.md

@@ -1,90 +1,94 @@
 ---
-title: Corporate vs Field laptop personas — the sector-52 split (designed, NOT built)
+title: Corporate vs Field laptop personas (Levy/Compass x Corporate/Field, PEOPLE cron)
 framework: "2.0"
-project: _Underscore
+repo: worker2
+project: Worker
 client: compass-usa
 type: client-feature
-status: deferred
-updated: 2026-10-05
+status: active
+updated: 2026-10-20
 owners: [bala]
 files:
   - worker2/Worker/Client/Compass/PeopleFile.php
+  - "dbchanges2/Client_Compass/2026-10-12a - PersonaCorporateField.sql"
 related:
   - ./persona-model-and-levy-gating.md
   - ./location-hierarchy-and-sectors.md
+  - ./cost-centers.md
   - ../workflows/persona-refactor-migration.md
+  - ../workflows/granting-persona-bundle-access.md
   - ../../../2.0/apps/_underscore/features/effective-persona-resolution.md
   - ../profile.md
 ---
-Agreed design for splitting the Compass catalogue into a Corporate laptop and a field "laptop kit": attach Corporate at sector `J00000` via `Locations_Personas`, assign Field in `PeopleFile`. Designed 2026-10-05, no code written. Open before building the field kit.
+LIVE since 2026-10-13 (TRUE-82667): `PeopleFile` gives every US user a Corporate or Field laptop persona (Levy and Compass halves) by cost center / sector `J00000`. Open before touching laptop kits, the corporate cost-center lists, or the four segment personas.
 
 ## Summary
 
-Compass confirmed the new **field laptop kit REPLACES the standard laptop** for non-corporate users;
-only admins see both. So the split is by **corporate vs not**, and corporate is a hierarchy question,
-not a flag — see [Location Hierarchy & Sectors](./location-hierarchy-and-sectors.md).
+Compass split the standard laptop into a **Corporate** kit and a cheaper **Field** kit. Field is the
+default; Corporate is decided by cost center (and, for Compass, by sector `J00000`). Four personas
+carry the kits, all assigned **directly in `Users_Personas`** by the nightly PEOPLE cron
+(`worker2/Worker/Client/Compass/PeopleFile.php`, commit `759a05c`, in `_production`). The one-time
+backfill was `dbchanges2/Client_Compass/2026-10-12a - PersonaCorporateField.sql`.
 
-Nothing is built. This doc records the agreed shape so the next session does not re-derive it.
+The earlier design (one `Locations_Personas` row on sector location 52) was **not** built.
 
-## How it works (the agreed design)
+## The four personas (prod `Client_Compass`, verified 2026-10-20)
 
-1. **Corporate persona.** Move the standard laptop bundle(s) out of **Non-Levy (persona 40)** into a
-   new **Corporate** persona, and attach it with a **single `Locations_Personas` row on sector
-   `J00000` (`Locations.id = 52`)**. Effective-persona resolution unions `Users_Personas`, the user's own
-   `Locations_Personas`, and their **sector's** (the 5-level walk), so every cost center under
-   `J00000` inherits it — including ones Compass adds on a later daily import.
-2. **Field persona.** It **cannot** use `Locations_Personas`: "everyone except sector 52" is not a
-   single location. Assign it in `worker2/Worker/Client/Compass/PeopleFile.php` as the default in
-   `Users_Personas`, skipped for anyone under `J00000` — mirroring the existing Levy branch.
-3. **Rejected alternative:** one `Locations_Personas` row per *other* sector (79 of them). It
-   silently misses any new sector Compass adds, which is the exact failure the feed is designed to
-   avoid.
-4. **No `isActive` filter is needed.** No inactive cost center under `J00000` has a single active
-   user, so attaching at the sector only ever reaches real people.
+| Persona | id | number | Kit | Active users |
+|---|---|---|---|---|
+| Levy Corporate | 41 | 43 | 189 LEVY - HP ZBOOK 8 | 244 |
+| Levy Field | 42 | 44 | 248 LEVY - Field Standard Laptop | 5,159 |
+| Compass Corporate | 43 | 45 | 187 Compass Standard HP ZBOOK 8 | 5,028 |
+| Compass Field | 44 | 46 | 247 Compass Field Standard Laptop | 65,447 |
 
-## Where the laptop bundles live (prod `Client_Compass`, verified 2026-10-05)
+- Kit **189 moved off Levy Purchaser (24)** and **187 off Non-Levy (40)**. Only those two moved.
+- Kit **249 NON COMPASS - Field Standard Laptop** sits on persona 5 (HTT and MITS team) and 12 (MITS
+  Team). MITS Team holds every kit, so it also has 247 and 248.
+- Ids and numbers differ (the migration header lists numbers 43-46). `PeopleFile` resolves all four
+  **by name** (`PERSONA_NAME_US_LEVY_CORPORATE` etc.). See the id/number table in
+  [Persona Model](./persona-model-and-levy-gating.md#the-persona-set-us).
 
-The standard laptop bundles sit in **persona 40 "Non-Levy"** (number 42) — not in persona 1, which is
-**Base** and carries only the 9 kits Levy also holds. See
-[Persona Refactor](../workflows/persona-refactor-migration.md) for the three-way split.
+## How it works
 
-| Bundle | Name | Note |
-|---|---|---|
-| 187 | Compass Standard HP ZBOOK 8 Laptop (Preferred) | |
-| 188 | Compass Hybrid HP Ebook 8 Flip (Travel) | `isActive = 0` |
-| 192 | HP PRO MINI 400 G9 | |
-| 195 | Compass Developer HP ZBOOK POWER | |
+`findSegmentPersonaIdsForUser()` runs for every US user on each PEOPLE run (existing and new users):
 
-**All four are attached to persona 12 "MITS Team" as well**, so the split must move/handle **both**
-personas — doing it on Non-Levy alone leaves MITS Team seeing the old laptop.
+1. **Levy half** when the user's effective persona set holds Levy Purchaser (24):
+   cost center in `LEVY_CORPORATE_COST_CENTERS` (33 values from Compass) -> Levy Corporate, else Levy Field.
+2. **Compass half** when the user should hold Non-Levy: location under sector `J00000` (Corporate
+   Indirect OH, `isLocationUnderSector()` walk, US only) **or** cost center in
+   `COMPASS_CORPORATE_COST_CENTERS` (10 values: 4018, 22772, 26963, 28184, 31335, 45781, 47258,
+   54188, 62230, 62937) -> Compass Corporate, else Compass Field.
+3. Cost center = `Users.c_erpEntityId` from the file. A user who moves cost center **swaps halves on
+   the next run** (insert the wanted one, delete the other three).
+4. A Levy user who also holds Non-Levy (Levy VIPs) gets **one of each** half.
+5. **Null-name guard:** until all four personas exist in that environment, nothing is added or
+   removed. That is what made "deploy worker2 first" safe.
 
-There is still **no `Locations_Personas` row for location 52**, so nothing inherits at that sector
-today. The table is already used this way for other sectors (e.g. Levy sector 55 → persona 24).
-
-**Open question — unanswered by the client:** which of **187 / 192 / 195** count as "the standard
-laptops" that stay corporate-only. Settle that before writing the migration.
+The effective set comes from `buildEffectivePersonaIds()`: direct `Users_Personas` + own-location +
+5-hop sector `Locations_Personas` (`findSectorLocationId()`) + Base, using **this run's** VIP/CDL
+flags (a user who just lost VIP drops it). Derived personas (Non-Levy and the four halves) are
+**removed** from that set, so a wrong grant cannot justify itself.
 
 ## Gotchas
 
-- **Never hardcode a persona id.** Resolve by name, exactly as `PeopleFile` does for `Non-Levy` —
-  ids differ per environment. See [Persona Model & Levy-Sector Gating](./persona-model-and-levy-gating.md).
-- **A persona grant is three tables** (`Personas_Bundles`, `Personas_Items`, `Personas_Assortments`),
-  not just bundles — see [granting a bundle](../workflows/granting-persona-bundle-access.md).
-- **The DB does not restrict what a persona sees** — the storefront front end is the only gate. A new
-  persona alone changes nothing until `toga2-commerce` filters on it.
-
-## Related
-- [Persona Model & Levy-Sector Gating](./persona-model-and-levy-gating.md)
-- [Location Hierarchy & Sectors](./location-hierarchy-and-sectors.md)
-- [Persona Refactor migration](../workflows/persona-refactor-migration.md)
-- [Effective persona resolution](../../../2.0/apps/_underscore/features/effective-persona-resolution.md)
+- **The rule lives in two places. Change one, change both:** `PeopleFile.php` and the
+  `2026-10-12a - PersonaCorporateField.sql` migration header/phases. The cron re-applies its copy
+  nightly, so drift silently undoes a manual fix.
+- **The cost-center lists are hardcoded and temporary.** Compass says a PEOPLE-file flag will replace
+  them. Until then a new corporate cost center needs a code change, not a DB row.
+- **Levy Corporate is by cost center only.** Levy's home office is the **district** `K9902`, not a
+  sector, so there is no sector walk for Levy. See [Location Hierarchy](./location-hierarchy-and-sectors.md).
+- **Never hand-add a half in `Users_Personas` or `Locations_Personas`.** The next run deletes a direct
+  row that does not match the rule. A location row still grants the half at read time, but the cron
+  never removes it, so those users end up holding both halves.
+- **The DB does not restrict what a persona sees**; the `toga2-commerce` storefront is the gate. A
+  grant is three tables. See [granting a bundle](../workflows/granting-persona-bundle-access.md).
+- `PeopleFile.php` has a literal SFTP credential in its class constants. Never paste its constants.
 
 ## Change history
-- 2026-10-05 — Created. Recorded the agreed corporate/field split (Corporate attached at sector
-  `J00000` via one `Locations_Personas` row; Field assigned in `PeopleFile` and skipped under
-  `J00000`; the 79-row per-sector alternative rejected) and the prod bundle locations verified the
-  same day: laptops 187 / 188 / 192 / 195 live in **Non-Levy (40)** and are also on **MITS Team
-  (12)**, and location 52 still has no `Locations_Personas` row. An earlier draft of this doc quoted
-  a **2026-09-15** persona read (persona 1 = "All", 23 bundles) as if it were current and called it a
-  conflict with the refactor doc — it was simply taken two days before the refactor went live on
-  2026-09-17. Removed; the refactor docs are correct. Nothing built. (bala)
+- 2026-10-20 — Rewritten from "designed, not built" to the shipped rule (TRUE-82667, worker2
+  `759a05c`, dbchanges2 `2026-10-12a`): four by-name personas assigned in `Users_Personas`, cost-center
+  lists + `J00000` walk, Field default, null-name guard, derived personas excluded from the effective
+  set. Prod counts verified 2026-10-20. The `Locations_Personas`-on-location-52 design was dropped. (bala)
+- 2026-10-05 — Created as a deferred design (Corporate at sector `J00000` via `Locations_Personas`,
+  Field in `PeopleFile`); laptop kits verified on Non-Levy (40) and MITS Team (12). (bala)

package/knowledge/clients/compass-usa/features/location-hierarchy-and-sectors.md

@@ -118,7 +118,7 @@ All of them are flagged Active and all have **zero users**. Drop them before any
 ## Related
 - [Cost Centers — Unit Locations, numeric-only policy](./cost-centers.md)
 - [Persona Model & Levy-Sector Gating](./persona-model-and-levy-gating.md)
-- [Corporate vs field laptop personas (deferred)](./corporate-vs-field-laptop-personas.md)
+- [Corporate vs field laptop personas (live, uses the `J00000` walk)](./corporate-vs-field-laptop-personas.md)
 - [Effective persona resolution](../../../2.0/apps/_underscore/features/effective-persona-resolution.md)
 
 ## Change history

package/knowledge/clients/compass-usa/features/persona-model-and-levy-gating.md

@@ -6,7 +6,7 @@ project: Worker
 client: compass-usa
 type: client-feature
 status: active
-updated: 2026-10-09
+updated: 2026-10-20
 owners: [bala, ajean, mhammontree]
 files:
   - worker2/Worker/Client/Compass/PeopleFile.php
@@ -43,22 +43,29 @@ below.
 
 ## The persona set (US)
 
-**The refactor is LIVE in prod since 2026-09-11** (three-way split, verified 2026-09-17 — see
-[Persona Refactor](../workflows/persona-refactor-migration.md)). Persona 1 is now named **Base**.
-
-| Persona | id | Meaning |
-|---|---|---|
-| Base (was "All") | **1** | The **9** kits Levy and non-Levy both hold (81, 82, 84, 85, 105, 115, 120, 165, 166), plus the 71 items / 11 categories Levy also holds. **Every US user holds it.** |
-| Levy Purchaser | **24** | Levy's own **5** kits: 189, 193, 213, 231, 242. |
-| Non-Levy | **resolved by name** — **id 40, number 42 in prod** | The other 14 persona-1 kits / 123 items / 3 categories. Granted to non-Levy users only. |
-| VIP | 35 | VIP add-on. Carries the manager auto-approve limit (`PersonaGlobalSettings` setting 18 = `'5000'`) — see [Approval-Decision Flow](approval-decision-flow.md). |
-| CDL (MacBook / Surface) | 30 | `@compassdigital.io` + VIP users. |
-
-**Never hardcode the Non-Levy id, and never assume it matches the number.** In prod it is **id 40**
-with **number 42** — the number is derived (`MAX(number)+1` under 100) because number 40 already
-belongs to "MyDining- KDS" (id 38). Earlier drafts variously claimed id 38 and id/number 40; both are
-wrong for prod. Every environment gets a different id, which is exactly what name-resolution protects
-against.
+Three-way refactor live since 2026-09-11 ([Persona Refactor](../workflows/persona-refactor-migration.md));
+Corporate/Field split live since 2026-10-13. Prod `Client_Compass` 2026-10-20: **43 personas** (id 33
+does not exist), **75,724** active users.
+
+| Persona | id | number | Meaning |
+|---|---|---|---|
+| Base (was "All") | **1** | | The **9** kits Levy and non-Levy both hold (81, 82, 84, 85, 105, 115, 120, 165, 166), plus the 71 items / 11 categories Levy also holds. **Every US user holds it.** |
+| Levy Purchaser | **24** | 27 | Levy's own **4** kits: 193, 213, 231, 242 (189 moved to Levy Corporate). |
+| Non-Levy | **by name** — 40 | 42 | The other persona-1 kits / 123 items / 3 categories, minus 187 (moved to Compass Corporate). |
+| Levy / Compass Corporate / Field | **by name** — 41-44 | 43-46 | One laptop kit each. See [Corporate vs Field](./corporate-vs-field-laptop-personas.md). |
+| VIP Role | 35 | 38 | VIP add-on. Carries the manager auto-approve limit (`PersonaGlobalSettings` setting 18 = `'5000'`) — see [Approval-Decision Flow](approval-decision-flow.md). |
+| Macbook and Surface (CDL) | 30 | 33 | `@compassdigital.io` + VIP users. |
+| CDL Eats Technology | 32 | 35 | |
+
+**Never hardcode a derived persona id, and never assume id = number.** Number is assigned as
+`MAX(number)+1` under 100, so ids and numbers drift apart (number 40 is "MyDining- KDS", id 38).
+Every environment gets different ids, which is what name-resolution protects against. `PeopleFile`
+still uses literal id constants for 1 / 24 / 30 / 35.
+
+**Location-granted personas can be wider than the name suggests.** Crothall Purchasing Team (**21**)
+is attached by `Locations_Personas` to the whole Crothall sector `B00000` (location **57**), same as
+Crothall Sector persona 6, so all **7,250** Crothall users see Virtual Manager kits **118 / 148**.
+Open question for Compass (2026-10-20) whether that is intended.
 
 `PeopleFile` resolves it at runtime:
 
@@ -116,10 +123,14 @@ users get it from their *own* location.
 **US** (`$tenantKey === 'US'`):
 - Always ensure **Base (1)** — never delete it. Base is printers, which every US user should see,
   Levy included.
-- **Non-Levy**, only when `$nonLevyPersonaId !== null`:
-  - `isLevy && hasNonLevy` → stage delete
-  - `!isLevy && !hasNonLevy` → stage insert
-- New users: always insert Base; insert Non-Levy only when `!isLevy` and the persona exists.
+- Build the **effective** set (`buildEffectivePersonaIds()`): direct + own-location + 5-hop sector
+  `Locations_Personas` + Base, using this run's VIP/CDL flags, with derived personas (Non-Levy and
+  the four Corporate/Field halves) removed so a wrong grant cannot justify itself.
+- **Non-Levy**, only when `$nonLevyPersonaId !== null`: `shouldUserHaveNonLevy()` is true unless the
+  effective set is exactly Base + Levy. Insert or delete to match.
+- **Corporate/Field half** (`findSegmentPersonaIdsForUser()`), only when all four exist — see
+  [Corporate vs Field](./corporate-vs-field-laptop-personas.md).
+- New users get the same three steps (Base, Non-Levy, half) with an empty direct set.
 
 > **⚠ This rule is DUPLICATED in the migration — change one, change both.** `PeopleFile.php` and
 > Phase 6 of `dbchanges2/Client_Compass/2026-09-11 - PersonaRefactor.sql` both skip users whose whole
@@ -184,6 +195,7 @@ Both are **latent, not live, and not yet fixed** — each needs its own ticket.
   constants from this file into tickets, docs, or chat transcripts.
 
 ## Change history
+- 2026-10-20 — Persona table refreshed from prod (TRUE-82956): ids vs numbers (24/27, 30/33, 32/35, 35/38, 40/42), Levy Purchaser down to 4 kits and Non-Levy minus 187 after the Corporate/Field split (TRUE-82667, live), assignment steps now include the effective set and the Corporate/Field half, Crothall Purchasing Team (21) sector-wide grant flagged as an open question. (bala)
 - 2026-10-09 — Persona 35 now carries the manager auto-approve limit (setting 18); PeopleFile keeps it in exact sync with `c_isVip` (prod 2269/2269), so do not decouple the two (TRUE-82608). (bala)
 - 2026-10-05 — Linked the deferred
   [corporate vs field laptop split](./corporate-vs-field-laptop-personas.md) (Corporate attached at

package/package.json

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