toga-ai 1.0.772 → 1.0.773

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

@@ -6,6 +6,7 @@
 | [/clickup/aliases — ClickUp Label-Alias Admin (Tools → 2.0 Team schema)](features/clickup-label-aliases-admin.md) | The human side of the NetSuite→ClickUp **Stakeholders / End Customer** labels. | tools/mvc/clickup/aliases/get.php, tools/mvc/clickup/aliases/post.php, tools/_/app/clickup/aliases.php, tools/_/app/nav.php |
 | [Developer Dashboard (ClickUp Sprint, tools /developer)](features/clickup-sprint-dashboard.md) | A native **ClickUp sprint dashboard** in the 1.0 `tools` app at route `/developer` (the **"Developer Dashboard"**, renamed from `/clickup/react` / "Clickup" — s | tools/_/app/clickup/sprint.php, tools/v2/sprints/tile/index.php, tools/v2/sprints/current/index.php, tools/v2/sprints/status-breakdown/index.php, tools/v2/sprints/worktype-breakdown/index.php, tools/v2/sprints/points-by-dev/index.php, tools/v2/sprints/burndown/index.php, tools/assets/clickup/sprint-dashboard.html, tools/mvc/developer/get.php, tools/mvc/login/get.php, tools/_/app/nav.php |
 | [CloudFront Client Setup](features/cloudfront-client-setup.md) | An SSO-gated admin tool at **`/devops/cloudfront-clients`** in the Tools 1.0 app that onboards a client onto **CloudFront + Route 53 across multiple AWS account | tools/_/app/devops/cloudfront.php, tools/mvc/devops/cloudfront-clients/get.php, tools/mvc/devops/cloudfront-clients/post.php, tools/assets/js/cloudfront-clients.js, tools/assets/css/cloudfront-clients.css, tools/_/app/nav.php, tools/_/app/frameworkindex.php, tools/config.production.ini |
+| [Compass User & Persona Admin (tools /compass/users, /compass/personas)](features/compass-user-persona-admin.md) | Two pages in the Tools `developers` nav folder that let staff do, in a browser, the two Compass requests that used to mean "email a developer, who writes a `dbc | tools/_/app/compass.php, tools/mvc/compass/users/get.php, tools/mvc/compass/users/post.php, tools/mvc/compass/personas/get.php, tools/mvc/compass/personas/post.php, tools/_/app/nav.php, tools/config.production.ini |
 | [Design Demo Admin](features/design-demo-admin.md) | A self-serve admin UI at **`/design`** in the SSO-protected **Tools** app that lets the design team publish self-contained "Claude Design" HTML exports as **ver | tools/_/app/design/github.php, tools/mvc/design/get.php, tools/mvc/design/post.php, tools/assets/css/design.css, tools/assets/js/design.js, tools/_/app/frameworkindex.php, tools/_/app/nav.php, tools/composer.json |
 | [Tools — Developers Folder (UUID & Password Generators)](features/developer-tools.md) | The first two tools shipped in the Tools app, both under the **Developers** folder and gated to personas **Development Team** / **TOGa Technology**. | tools/mvc/developers/uuid/get.php, tools/mvc/developers/password/get.php, tools/mvc/developers/password/post.php |
 | [/errors Curation Console (Tools → shared Core Logs DB)](features/errors-curation-console.md) | Internal-only triage/curation screen for the 2.0 Issue/Event error-reporting pipeline, built as a 1.0 Tools MVC page reading the **shared Core Logs DB** through | tools/mvc/errors/get.php, tools/mvc/errors/post.php, tools/mvc/errors/issue/get.php, tools/assets/css/style.css, tools/_/app/nav.php, tools/config.production.ini |

package/knowledge/1.0/apps/tools/architecture.md

@@ -6,8 +6,8 @@ project: Tools
 client: shared
 type: architecture
 status: active
-updated: 2026-08-14
-owners: [jcardinal, kyalamarthi]
+updated: 2026-09-04
+owners: [jcardinal, kyalamarthi, ajean]
 files:
   - tools/index.php
   - tools/.ebextensions/020_setup_git_libraries.config
@@ -41,7 +41,11 @@ related:
 **Tools** is a standalone 1.0 (`App_`) application that houses many small internal tools behind
 simple interfaces, gated by Client_True staff persona. It is modeled on `togaview` and depends on
 the `library` core. Auth comes via the SAML gateway `?saml=` handoff; the app owns its own
-session and reads `Client_True` **read-only**. Adding a tool = create `mvc/<route>/get.php`
+session and reads `Client_True` **read-only** — but it is **no longer a read-only app**: as of
+PR tools#13 (unmerged) it also **WRITES** to client tenant databases (`Client_Compass` /
+`Client_CompassCanada`) through new `[database_compass]` / `[database_compasscanada]` ini
+sections that reuse the `[database_true]` account. That is the first non-read-only surface in
+Tools. Adding a tool = create `mvc/<route>/get.php`
 (copy `mvc/_TEMPLATE`) + add one `App_Nav::definition()` entry + `App_Auth::requireAuth([...])`.
 
 **Critical rules:** Do NOT use bare `<header>` elements in this app — they inherit the legacy
@@ -59,6 +63,11 @@ denied at the front controller / out of the web root. New CSS must use `--c-*` t
 `App_FrameworkIndex::setHeaderCode()` is the **only** hook for markup in `<head>`, and it
 **SETS rather than appends** — the theme bootstrap is its sole caller, so a second call
 silently clobbers it.
+**Any page that writes to a client tenant DB must `App_Auth::requireAuth()` an explicit, narrow
+persona list (`['Development Team']`) — never `App_Nav::personasForRoute()`**, which returns the
+UNION of the folder's personas and the action's personas and so widens the grant straight back to
+everyone who can see the nav group. Also: **persona checks read a 4-day session snapshot**, so
+removing someone's persona does **not** revoke their access — their session must be killed.
 
 ## Boot & structure
 

package/knowledge/1.0/apps/tools/features/compass-user-persona-admin.md

@@ -0,0 +1,138 @@
+---
+title: Compass User & Persona Admin (tools /compass/users, /compass/personas)
+framework: "1.0"
+repo: tools
+project: Tools
+client: shared
+type: feature
+status: draft
+updated: 2026-09-04
+owners: [ajean]
+files:
+  - tools/_/app/compass.php
+  - tools/mvc/compass/users/get.php
+  - tools/mvc/compass/users/post.php
+  - tools/mvc/compass/personas/get.php
+  - tools/mvc/compass/personas/post.php
+  - tools/_/app/nav.php
+  - tools/config.production.ini
+related:
+  - ./mvc-data-access-patterns.md
+  - ./persona-gated-navigation.md
+  - ./saml-sso-auth.md
+  - ../architecture.md
+  - ../../../2.0/apps/_underscore/features/effective-persona-resolution.md
+  - ../../../clients/compass-usa/features/people-file-user-lifecycle.md
+  - ../../../clients/compass-usa/features/persona-model-and-levy-gating.md
+  - ../../../clients/compass-usa/workflows/granting-persona-bundle-access.md
+---
+
+## Summary
+
+Two pages in the Tools `developers` nav folder that let staff do, in a browser, the two Compass
+requests that used to mean "email a developer, who writes a `dbchanges2` SQL file": **activate /
+deactivate a Compass user**, and **grant a persona**. Both tenants are covered by one tenant
+switcher — **US** (`Client_Compass`) and **Canada** (`Client_CompassCanada`).
+
+**This is the first thing in `tools` that WRITES to a client tenant database.** Until now the app
+read `Client_True` read-only. That single fact drives most of the design and every open risk below.
+
+Status: built on PR **tools#13**, **not yet merged**. `status: draft` until it ships.
+
+## Key files / entry points
+
+- **`tools/_/app/compass.php`** — `App_Compass`, all data access for both pages (search, persona
+  resolution, activate/deactivate, grant).
+- **`tools/mvc/compass/users/{get,post}.php`** — user search + activate/deactivate + grant persona.
+- **`tools/mvc/compass/personas/{get,post}.php`** — inspect one persona and who reaches it.
+- **`tools/_/app/nav.php`** — the two nav entries, inside the existing `developers` folder.
+- **`tools/config.production.ini`** — new `[database_compass]` / `[database_compasscanada]` sections.
+
+## How it works
+
+### What the pages do
+
+1. **Find a user** by `c_hrEmpUsername`, `email`, or `c_hrEmpPersonnelNbr`.
+2. **Activate / deactivate** them (`Users.isActive`).
+3. **See the personas that user reaches, and WHY** — direct row, own location, or sector.
+4. **Inspect a persona** and list who reaches it, from all three sources.
+5. **Grant a persona** — one `INSERT` into `Users_Personas`.
+
+The "why" column is the point of the tool. Answering "who has persona N" from `Users_Personas`
+alone badly under-reports on Compass, because most users hold their catalogue through their
+**sector**, not through a row of their own. The resolution rule the tool implements is the
+framework's own — see
+[Effective persona resolution](../../../2.0/apps/_underscore/features/effective-persona-resolution.md),
+which also carries the measured prod numbers and the "reverse lookups must be set-based" rule.
+
+### Access gating is deliberately tighter than the folder
+
+Both pages `requireAuth(['Development Team'])` — narrower than the `developers` folder's own
+persona set. That is on purpose: these are tenant **writes**, not read-only developer utilities.
+Passing `App_Nav::personasForRoute()` here would widen the grant back to the folder's set; see the
+nav-narrowing gotcha in [MVC data access patterns](./mvc-data-access-patterns.md).
+
+### Database connections
+
+New `[database_compass]` and `[database_compasscanada]` sections in `config.production.ini` reuse the
+**existing `[database_true]` account** — same client cluster, only `dbname` differs. **No new secret
+value was introduced.** See the accepted risk below.
+
+### Schema footprint: none
+
+The tool creates and alters **nothing**. It reads/writes only `Users`, `Users_Personas`,
+`Locations_Personas`, `Locations`, and reads `Personas` for names.
+
+## Decisions
+
+- **2026-09-04 — No new columns, no new tables (Jeff Cardinal, back-end review).** The tool talks
+  directly to production `Client_Compass` / `Client_CompassCanada` using the existing schema only.
+  This killed an earlier design that added `Users.c_isKeepActive` plus expiry/audit columns, an
+  `AdminAuditLogs` table, and three search indexes. `dbchanges2#478` and `worker2#160` were opened
+  and then **closed unmerged** — do not resurrect them without re-opening that decision.
+- **2026-09-04 — Reuse the `[database_true]` credential** rather than split out a least-privilege
+  Compass account. Raised twice in security review and consciously declined for now (see below).
+
+## Gotchas
+
+- **⚠ Activating a Compass user is TEMPORARY; deactivating is durable.** Because the
+  `c_isKeepActive` flag was dropped from scope, the nightly PEOPLE importer will deactivate anyone
+  absent from that day's file — so an activation only sticks if the person is actually in the file.
+  Deactivation holds, because the cron never reactivates anybody. Full lifecycle:
+  [PEOPLE-file User Lifecycle](../../../clients/compass-usa/features/people-file-user-lifecycle.md).
+- **A cross-region user still needs a code change and a deploy.** The only durable way to hold one
+  active is the hardcoded four-address list in `ensureCrossRegionUsersActive()` in
+  `worker2/Worker/Client/Compass/PeopleFile.php`. This tool does not change that.
+- **Every user search is a full table scan.** `Client_Compass.Users` has no index on `email`,
+  `c_hrEmpUsername`, `c_hrEmpPersonnelNbr` or `isActive` (176k rows; `EXPLAIN` reports `type=ALL`,
+  no possible keys). Same on `Client_CompassCanada`. Keep result sets bounded and do not add
+  per-row lookups against those columns in a loop.
+- **⚠ Accepted risk — the tool widens the blast radius of one shared credential.** It points the
+  `[database_true]` account at two more tenant schemas. `config.production.ini` is committed and was
+  web-readable until the 2026-07-24 `FilesMatch` deny blocks, so **rotation of that account is still
+  owed**. An inline comment in the ini records this and lists the exact grants a split-out Compass
+  account would need. Never paste the value anywhere.
+- **⚠ Persona revocation does not take effect for up to 4 days.** Tools snapshots persona names into
+  `$_SESSION` at login and sessions last 4 days, so removing someone's `Development Team` persona
+  does not lock them out of these pages until their session dies. See
+  [SAML SSO & persona-gated auth](./saml-sso-auth.md).
+- **No staff-actor audit trail exists for these writes.** `Logs_Compass.Record.userId` is a **tenant**
+  `Users.id`, so it cannot record a `Client_True` staff member — it is not usable as the audit log
+  for this tool, and `Logs_Compass.Record` is the client-facing activity log (3.6M rows) besides.
+  See
+  [Record Change Audit Log](../../../2.0/apps/_underscore/features/record-change-audit-log.md).
+  Auditing internal-tool actions remains an open item.
+- **Detecting a no-op UPDATE needs `App_Database::affectedRows()`** — `App_Database::query()` returns
+  the `App_Query` execute result, not a row count. Details in
+  [MVC data access patterns](./mvc-data-access-patterns.md).
+
+## Change history
+
+- 2026-09-04 — Initial: built the two-page Compass user/persona admin (PR tools#13, unmerged) — the
+  first `tools` pages that write to a client tenant DB, gated to `Development Team` only, with a
+  US/Canada switcher and new `[database_compass]` / `[database_compasscanada]` ini sections reusing
+  the existing `[database_true]` account. Recorded Jeff Cardinal's scope reset (no schema changes;
+  `dbchanges2#478` and `worker2#160` closed unmerged) and its consequence — **activation is temporary
+  because the `c_isKeepActive` flag was dropped**, while deactivation is durable. Logged the accepted
+  credential-reuse risk, the 4-day session persona staleness, the missing staff-actor audit trail, and
+  that every user search is a full scan. (ajean)

package/knowledge/1.0/apps/tools/features/mvc-data-access-patterns.md

@@ -6,8 +6,8 @@ project: Tools
 client: shared
 type: feature
 status: active
-updated: 2026-08-04
-owners: [jcardinal, bala]
+updated: 2026-09-04
+owners: [jcardinal, bala, ajean]
 files:
   - tools/_/app/nav.php
   - tools/mvc/get.php
@@ -15,6 +15,7 @@ files:
   - library/app/database.php
 related:
   - ./persona-gated-navigation.md
+  - ./compass-user-persona-admin.md
   - ./saml-sso-auth.md
   - ../architecture.md
   - ../../library/features/mvc-page-pattern-and-app-skeleton.md
@@ -57,6 +58,31 @@ add one expecting the framework to validate it.
   2.0 DB read-only through its own connection (e.g. `db_true → Client_True`); adding
   `db_team → Team` is the same pattern.
 
+### Detecting a no-op UPDATE — `App_Database::affectedRows()`
+`App_Database::query()` returns the `App_Query` execute result, **not** a row count, so it cannot
+tell you whether an `UPDATE` actually changed anything. Use
+`App_Database::affectedRows($linkRegistryString)` — pass the same alias you queried with. This is
+how a page distinguishes "saved" from "the value was already that".
+
+### DB credentials come straight from the ini — there is no secret store
+`App_Database::registerDatabaseConnect()` (`library/app/database.php:125-128`) reads
+**hostname / username / password / dbname directly from the config ini**. Only
+`database_reader_endpoint` goes through `App_Cloud::getParameter()`. So a 1.0 app **cannot** move a
+DB credential into a secret store without changing shared `library` core that every 1.0 app boots
+through. Plan around it: `config.*.ini` is where DB credentials live, and it is committed (see the
+config/secrets note in [the architecture doc](../architecture.md)).
+
+### Input filtering — `App_Page::getVarIfSet()` allows printable ASCII
+`getVarIfSet()` runs `App_String::filterCharactersValidCharactersOnly()`, which permits **ASCII
+32-126**. Emails, usernames and personnel numbers survive intact, so it is safe for those search
+inputs. It is a character filter, not an escaper — still escape/cast before the value reaches SQL.
+
+### Production MySQL runs `US/Central`
+The prod MySQL server timezone is **`US/Central`**, matching the 1.0 framework's `America/Chicago`
+and worker2's Central-time cron scheduling (verified 2026-09-02). So MySQL `CURDATE()` and PHP
+`date('Y-m-d')` agree — there is **no** day-boundary divergence to design around when the same date
+check exists in both SQL and PHP.
+
 ### Gotcha — by-reference row helpers
 `buildArrayOfRows`, `fetchOne`, and `fetchRow` take `$res` **by reference**. Assign the
 `query()` result to a **variable first**, then pass it — passing the call result inline emits
@@ -142,6 +168,14 @@ set_error_handler(fn(): bool => true); // swallow non-fatal notices/deprecations
 `App_Talos_Estimator` → `_/app/talos/estimator.php`.
 
 ## Change history
+- 2026-09-04 — Added four `App_Database` / input facts found building the Compass admin pages:
+  `affectedRows($alias)` is how you detect a no-op `UPDATE` (`query()` returns the `App_Query`
+  execute result, not a row count); `registerDatabaseConnect()` reads DB credentials **directly from
+  the config ini** (only `database_reader_endpoint` uses `App_Cloud::getParameter()`), so there is no
+  secret-store option without changing shared 1.0 core; `App_Page::getVarIfSet()` filters to
+  printable ASCII 32-126, so emails/usernames/personnel numbers pass through intact; and production
+  MySQL runs timezone **`US/Central`**, matching PHP's `America/Chicago`, so `CURDATE()` and
+  `date('Y-m-d')` agree. (ajean)
 - 2026-08-04 — Added two gotchas found rebuilding the Talos Pricing UI: (1) `App_Database::fetchOne()` is **not** an existence test — it `data_seek`s and returns `$row[$col]` with no empty check, so zero rows dereferences null → uncaught `ErrorException` → bare 500; a **library-wide** footgun affecting every 1.0 app (use `COUNT(*)` or `buildArrayOfRows` + `empty()`). (2) Tools runs **PHP 8.5**, where "using null as an array offset" is deprecated even inside `isset()` and the framework escalates deprecations to fatals — cast to `(string)` before indexing; PHP 8.2 local dev does not reproduce it. (jcardinal)
 - 2026-08-03 — Added the error-handler escalation gotcha: `App_Error::handleError` promotes ANY PHP
   notice/deprecation to a thrown `ErrorException` (ignoring `error_reporting`) and, without Sentry,

package/knowledge/1.0/apps/tools/features/saml-sso-auth.md

@@ -6,8 +6,8 @@ project: Tools
 client: shared
 type: feature
 status: active
-updated: 2026-06-30
-owners: [jcardinal]
+updated: 2026-09-04
+owners: [jcardinal, ajean]
 files:
   - tools/_/app/auth.php
   - tools/mvc/sso/initiate/get.php
@@ -20,6 +20,7 @@ files:
   - tools/config.local.ini
 related:
   - ../architecture.md
+  - ./compass-user-persona-admin.md
   - ../../library/features/app-sso-initiation.md
   - ../../../2.0/apps/saml/features/downstream-integration-contract.md
   - ../../../clients/true/features/users-personas-data-model.md
@@ -115,6 +116,17 @@ removed.
 
 ## Gotchas / known issues
 
+- **⚠ Personas are snapshotted at login and sessions last 4 days — revoking a persona does not
+  revoke access.** `App_Auth` caches the user's persona **names** into `$_SESSION` at sign-in and
+  `requireAuth()` / `App_Nav` both read that cache, never the live `Users_Personas` rows. So removing
+  someone's persona leaves them able to use every page it gated for up to **4 days**, until their
+  session expires. This matters most for pages that write to a client tenant — see the [Compass
+  admin pages](./compass-user-persona-admin.md). To cut access off now, kill the session, do not just
+  revoke the persona.
+- **The Tools session cookie has no `Secure` flag.** `App_Framework_Tools` sets `useSessions = false`,
+  so the parent `library` framework's `cookie_secure` setup never runs; Tools sets the cookie itself
+  with HttpOnly + SameSite=Lax only. Open item — do not assume the cookie is HTTPS-only.
+
 - **Consumer route runs mid-render → headers already sent.** The 1.0 framework runs `mvc/sso/get.php`
   **inside** the page render (`frameworkindex → body → loadFile`) after `common/header.php` has
   emitted output, so `session_regenerate_id(true)` fatals ("cannot be regenerated after headers
@@ -180,6 +192,11 @@ remains (already noted in tools knowledge) — **flag for rotation.** Document *
 never the values.
 
 ## Change history
+- 2026-09-04 — Recorded two standing security gaps found while adding tenant-writing pages: personas
+  are **snapshotted into `$_SESSION` at login** and sessions last **4 days**, so revoking a persona
+  does not revoke page access until the session dies (kill the session instead); and the Tools
+  session cookie carries **no `Secure` flag**, because `App_Framework_Tools` sets `useSessions =
+  false` and the parent framework's `cookie_secure` setup therefore never runs. (ajean)
 - 2026-06-30 — Fixed SSO "Sign in failed" (`/login?error=1`) regression and **corrected the earlier wrong "config tokens are removable" note**. The prior fix moved only the consumer/decrypt leg to `Core.Parameters` and advised the `[saml] api_secret_access_token` was removable — but the **initiate** leg (`mvc/sso/initiate/get.php`) still read it from config, so removing it made `App_Sso::initiate()` throw on an empty token (`library/app/sso.php:64-65`) → `/login?error=1`. Fix: **both** legs now source the rotating secret from `Core.Parameters` — added public `App_Auth::currentApiSecret()` (reuses cached `handoffKeys()`), and `sso/initiate/get.php` passes it instead of the config value. Documented the non-empty-token requirement, the `/login?error=1` (initiate) vs "Authentication failed" (consumer) leg distinction, the `true_client_uuid`-stays-in-config rule, and the `db_toga2core`-missing→500 diagnostic. `php -l` clean on both files. (jcardinal)
 - 2026-06-30 — Fixed prod SSO login failure: handoff decrypt keys now sourced from `Core.Parameters` (rotated `API_SECRET_ACCESS_TOKEN`/`_PREVIOUS`) via new `App_Auth::handoffKeys()` over `db_toga2core` (per-request cached, current→previous fallback), instead of the stale committed `config [saml]` tokens — the stale key was the root cause. Added `[database_toga2core]` connection requirement to every config and documented the AES-256-CBC crypto format. Fixed `tools_ssoFail()` 500→intended 401: `http_response_code(401)` fataled on headers-already-sent (preloader flushes before mvc page runs); guarded with `!headers_sent()`. (jcardinal)
 - 2026-06-26 — Wired up real SSO initiation via the new 1.0 `App_Sso` library class (`/sso/initiate`), replacing the `initiation_url` placeholder; registered the fixed-uuid Core.Domains return row (dbchanges2 `2026-06-26a`); fixed the `session_regenerate_id` headers-already-sent fatal (guarded with `!headers_sent()`) and documented the mid-render failure-path limitation; collapsed home → `/login` to one-step sign-in; noted prod secrets live in `config.production.ini [saml]` (jcardinal)

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

@@ -19,6 +19,7 @@
 | [_Config group access — the two-argument "optional" form does NOT rescue a missing GROUP](features/config-group-access.md) | `_Config::<group>('<property>')` reads a value out of the active `Config/<ENVIRONMENT>.ini`, and **it throws when the requested group is absent from the ini.** | _underscore/Config.php, _underscore/Component/Api/Paypal/Paypal.php, _underscore/Worker.php, api2/Config/beta.ini, api2/Config/sandbox-dev.ini |
 | [Core.Domains — the app host registry (and why you cannot derive a host)](features/core-domains-app-host-registry.md) | `Core.Domains` is the **authoritative registry of which host serves which client's app in which environment**. | _underscore/Model/Core/Domain.php, api2/Component/Api/CrossClient/CrossClient.php, api2/Component/Api/V2/V2.php, worker/config.beta.ini |
 | [Re-pointing a DB alias mid-request (_Database::register park/restore)](features/database-alias-repointing.md) | `_Database` keys **all live per-database runtime state by the connection ALIAS** (`Client` / `_underscore::DB_CLIENT`, `ClientLogs`, `Archive`), **not** by the | _underscore/Database.php, _underscore/Query.php, api2/Component/Api/V2/V2.php, api2/Component/Api/CrossClient/CrossClient.php |
+| [Effective persona resolution (_Model_Client_User::_personaIds) — the three sources and the sector hop](features/effective-persona-resolution.md) | A user's **effective** persona set is **not** `Users_Personas`. | _underscore/Model/Client/User.php |
 | [2.0 Email Send Pipeline (queue + Send worker)](features/email-send-pipeline.md) | In 2.0, `_Email::send()` **does not transmit** — it queues the message. | _underscore/Email.php, _underscore/String.php, worker2/Worker/Infrastructure/Email/Send.php, _underscore/Model/Client/Logs/Email.php, _underscore/Model/Client/Logs/EmailAttachment.php |
 | [Client Email Template Sending](features/email-template-sending.md) | `_Model_Client_EmailTemplate` sends a stored, client-defined email template by UUID. | _underscore/Model/Client/EmailTemplate.php, _underscore/Model/Quad/ApprovalDecision.php, _underscore/Model/Quad/SalesOrder.php, _underscore/Model/Client/EmailTemplateOutgoingEmailAddress.php, _underscore/Email.php |
 | [Error Reporting — Issue/Event Capture, Fingerprinting & Aggregation](features/error-reporting-issue-event.md) | Platform-wide error reporting for TOGA 2.0, built on an **Issue / Event** aggregation model in the **shared Core Logs DB**. | _underscore/Error.php, _underscore/Query.php, _underscore/Database.php, _underscore/Exception/Business.php, _underscore/Exception/Database.php, _underscore/Test/DatabaseFingerprint.php, api2/Controller/Index.php, worker2/Controller/Index.php, _underscore/Model/Core/Logs/Issue.php, _underscore/Model/Core/Logs/Event.php, _underscore/Model/Core/Logs/IssueFingerprint.php, _underscore/Model/Core/Logs/IssueClickupTask.php, _underscore/Model/Core/Logs/IssueEmailAddress.php, _underscore/Model/Core/Logs/IssueAreaOwner.php, worker2/Worker/Infrastructure/Errors.php, tools/mvc/errors/issue/get.php, tools/mvc/errors/post.php, dbchanges2/Logs/2026-07-30a - Error reporting Issues and Events.sql, dbchanges2/Logs/2026-08-01a - Rename tables to singular.sql, dbchanges2/Logs_Client/2026-08-01a - Drop Error table.sql, dbchanges2/Core/2026-07-30a - Error escalation cron job.sql |

package/knowledge/2.0/apps/_underscore/features/effective-persona-resolution.md

@@ -0,0 +1,88 @@
+---
+title: Effective persona resolution (_Model_Client_User::_personaIds) — the three sources and the sector hop
+framework: "2.0"
+repo: _underscore
+project: _Underscore
+client: shared
+type: feature
+status: active
+updated: 2026-09-04
+owners: [ajean]
+files:
+  - _underscore/Model/Client/User.php
+related:
+  - ./persona-name-translation.md
+  - ../../../clients/compass-usa/features/persona-model-and-levy-gating.md
+  - ../../../clients/compass-usa/workflows/granting-persona-bundle-access.md
+  - ../../../clients/compass-usa/workflows/persona-population-env-comparison.md
+  - ../../../1.0/apps/tools/features/compass-user-persona-admin.md
+---
+
+## Summary
+
+A user's **effective** persona set is **not** `Users_Personas`. The framework already owns the rule:
+`_Model_Client_User::_personaIds()` (`_underscore/Model/Client/User.php:48`) is the **source of
+truth**. It is a `FIELD_SQL` virtual column — a `GROUP_CONCAT(personaId SEPARATOR ':')` over a
+**UNION of three sources**.
+
+Anything that answers "what can this user see?" or "who can see persona N?" must reproduce all three
+sources. Reading `Users_Personas` alone badly under-reports: on Compass, the overwhelming majority of
+users hold their catalogue through their **sector**, not through a row of their own.
+
+## How it works
+
+### The three sources
+
+1. **`Users_Personas`** on the user's own `userId` — personas granted directly.
+2. **`Locations_Personas`** on the user's **own** `locationId`.
+3. **`Locations_Personas`** on the user's **sector** — reached by **five INNER JOINs** up the
+   `Locations` chain, with semantic aliases:
+
+```
+Locations -> LocationComplex -> LocationDistrict -> LocationRegion -> LocationDivision -> LocationSector
+```
+
+Because those five hops are `INNER JOIN`s, a user whose chain is shorter than five levels simply
+contributes nothing from source 3 — no error, just an empty branch.
+
+### Measured on production, 2026-09-02
+
+| Tenant | Active users | Resolve at hop 5 (sector) | Resolve at hop 0 (own location) | Hops 1-4 and 6 |
+|---|---|---|---|---|
+| `Client_Compass` | 74,268 | **67,157** | 338 | **0** |
+| `Client_CompassCanada` | 4,948 | **4,029** | — | **0** |
+
+So in practice only **two** of the possible depths ever pay out: the user's own location, and the
+five-hop sector. Nothing in between.
+
+**But "persona locations all sit at one level" is FALSE.** The 123 persona-bearing locations in
+`Client_Compass` sit at two different depths — 15 with 3 ancestors, 108 with 6 or more. The depths
+that *users* pick them up at are stable; the depths the *locations* live at are not. Do not write a
+query that assumes a fixed hierarchy depth for `Locations_Personas`.
+
+## Gotchas
+
+- **⚠ A reverse lookup (persona → users) must be SET-BASED.** Build it as the union of the three
+  sources and join once. Never run an `EXISTS`-per-user check: on `Client_Compass` that is 74k
+  executions of a five-join chain against a `Users` table with no useful index (see below).
+- **`Users_Personas` alone is the wrong answer.** On Compass it would return roughly 338 of the
+  67,495 users who actually reach a sector-granted persona. Any "who has persona N" report built on
+  it is wrong, not merely incomplete.
+- **The rule lives in the framework — do not re-derive it.** If you are writing SQL for a report, a
+  migration, or an internal tool, mirror `_personaIds()` rather than inventing a resolution. Where
+  the effective set matters for a *grant*, the same three-source check is the pre-flight step in
+  [Granting a Compass user access to a bundle](../../../clients/compass-usa/workflows/granting-persona-bundle-access.md)
+  — the user may already reach the persona, in which case the right answer is "no change needed".
+- **No index backs the user side of these queries on Compass.** `Client_Compass.Users` has no index
+  on `email`, `c_hrEmpUsername`, `c_hrEmpPersonnelNbr` or `isActive`, so every lookup is a full scan
+  (`EXPLAIN` → `type=ALL`, 176,018 rows, no possible keys). Same on `Client_CompassCanada`.
+
+## Change history
+
+- 2026-09-04 — Initial: documented `_Model_Client_User::_personaIds()` as the source of truth for a
+  user's effective persona set — a `FIELD_SQL` `GROUP_CONCAT` over a UNION of `Users_Personas`, the
+  user's own `Locations_Personas`, and their **sector's**, reached by five aliased INNER JOINs.
+  Measured on prod 2026-09-02: 67,157 of 74,268 active `Client_Compass` users resolve at hop 5 and
+  only 338 at hop 0, with **zero** at any other hop (Canada: 4,029 of 4,948 at hop 5). Recorded that
+  persona-bearing locations sit at two different depths, so "one level" assumptions are wrong, and
+  that reverse persona→user queries must be set-based, never EXISTS-per-user. (ajean)

package/knowledge/2.0/apps/_underscore/features/record-change-audit-log.md

@@ -6,14 +6,15 @@ project: _Underscore
 client: shared
 type: feature
 status: active
-updated: 2026-08-20
-owners: [bala]
+updated: 2026-09-04
+owners: [bala, ajean]
 files:
   - _underscore/Model/Client/Logs/Record.php
   - _underscore/Model/Client/Logs/RecordField.php
   - _underscore/Model/Client/Logs/CustomRecordField.php
 related:
   - ../../api2/features/request-logging.md
+  - ../../../1.0/apps/tools/features/compass-user-persona-admin.md
   - ../../../../clients/compass-usa/features/approval-decision-flow.md
   - ../../../../clients/compass-usa/features/stranded-approval-reassignment.md
   - ../../api2/features/api-payload-interceptors.md
@@ -106,6 +107,15 @@ single record: the milestone notes are the chapter headings, the field changes a
   to read the client id from — resolve it from `Core` (`Clients` JOIN `Databases` on `name`). Known
   ids: `Client_Compass` = **2** (`Logs_Compass`), `Client_CompassCanada` = **43**
   (`Logs_CompassCanada`). This applies to **every** client, not just Compass.
+- **⚠ `Record.userId` is a TENANT `Users.id` — it cannot record an internal staff actor.** There is
+  no way to express "a `Client_True` staff member did this" in this table, so it is **not** an audit
+  log for internal-tool actions taken against a client tenant (e.g. the [Tools Compass admin
+  pages](../../../1.0/apps/tools/features/compass-user-persona-admin.md)). It is also the
+  **client-facing** activity log — `Logs_Compass.Record` is ~3.6M rows — so staff actions do not
+  belong in it even if the id could be made to fit. An internal audit trail needs its own home.
+- **Tables in the `Logs_<Tenant>` schema are SINGULAR — the documented exception to the plural table
+  convention.** `Logs_Compass` holds `Api`, `CustomRecordField`, `Record`, `RecordField`, `Email`,
+  `EmailAttachment`. If you ever add a log table there, name it singular to match.
 - **⚠ `Logs_*` and `Core` are on different database clusters — you cannot join them in one query.**
   `Record.recordId` → `Core.Records` and `RecordField.recordFieldId` → `Core.RecordFields` are
   logical foreign keys across a cluster boundary. Resolve the `Core` ids in a **separate** query and
@@ -119,7 +129,12 @@ single record: the milestone notes are the chapter headings, the field changes a
   mechanism, not the people.
 
 ## Change history
-
+- 2026-09-04 — Recorded two facts found while looking for an audit home for an internal admin tool:
+  `Record.userId` is a **tenant** `Users.id`, so this log **cannot** record a `Client_True` staff
+  actor and is not the audit trail for internal-tool writes (and `Logs_Compass.Record` is the
+  ~3.6M-row client-facing activity log besides); and tables in the `Logs_<Tenant>` schema are
+  **singular** (`Api`, `CustomRecordField`, `Record`, `RecordField`, `Email`, `EmailAttachment`) —
+  the documented exception to the plural table convention. (ajean)
 - 2026-08-20 — Added the **`addNote()` is a silent no-op outside api2** gotcha: `addNote()` only
   stages into the static `$_notes` array and **only api2's `Component/Api/V2/V2.php` ever flushes
   it**, so every `addNote()` call from `_underscore` or `worker2` loses its note with no error. A

package/knowledge/2.0/apps/dbchanges2/features/rerunnable-additive-inserts.md

@@ -6,8 +6,8 @@ project: Database Changes
 client: shared
 type: feature
 status: active
-updated: 2026-09-01
-owners: [bala, kyalamarthi, apeterson]
+updated: 2026-09-04
+owners: [bala, kyalamarthi, apeterson, ajean]
 files:
   - dbchanges2/Client_Compass/2026-08-26a - CompassCreativeStudioPersona.sql
   - dbchanges2/Core/2026-08-27a - Insert - Netsuite Location SyncAll CronJob.sql
@@ -220,9 +220,13 @@ PREPARE stmt FROM @sql; EXECUTE stmt; DEALLOCATE PREPARE stmt;
 
 - **`TABLE_SCHEMA = DATABASE()`** keeps it cluster-safe — the file never names a database, so the
   same statement is correct in every `Client_*` schema.
-- Guard **indexes** the same way against `information_schema.STATISTICS` (and remember a composite
-  unique key is only recorded against its first column — see
-  [tableview-field-metadata](../../api2/features/tableview-field-metadata.md)).
+- Guard **indexes** the same way against `information_schema.STATISTICS`, but **key the guard on
+  `COLUMN_NAME` + `SEQ_IN_INDEX = 1`, never on `INDEX_NAME`.** An index name is arbitrary: guarding
+  on the name misses an equivalent index that someone already created under a different name, and
+  you silently add a duplicate. Guarding on "is this column already the first column of some index"
+  asks the question you actually mean. (A composite unique key is likewise only recorded against its
+  first column — see
+  [tableview-field-metadata](../../api2/features/tableview-field-metadata.md).)
 - The `PREPARE` shape is what makes the guard work at all: **DDL cannot sit inside an `IF`** in a
   plain script, so the condition has to select the *statement text*, not branch around it.
 
@@ -280,6 +284,11 @@ concluding a migration is production-safe.
   [FIELD_SQL calculated fields](../../_underscore/features/calculated-sql-fields.md).
 
 ## Change history
+- 2026-09-04 — Sharpened the index guard: check `information_schema.STATISTICS` on **`COLUMN_NAME` +
+  `SEQ_IN_INDEX = 1`**, not on `INDEX_NAME` — an existing index under a different name goes
+  undetected by a name-based guard and you add a duplicate. Found while sizing (and then dropping)
+  the Compass `Users` search indexes. (ajean)
+
 - 2026-09-01 — Added the **fan-out rollback rule**: a `Client/` grant migration that fans out across
   every tenant must use **hardcoded v4 uuid literals**, not the generator, so its rollback
   (`DELETE … WHERE uuid IN (…)`) can only touch rows that file created. A natural-key rollback on

package/knowledge/INDEX.md

@@ -14,11 +14,11 @@ _Auto-generated by `knowledge.js index`. Do not hand-edit._
 - **walmarttechservices** (Walmart Tech Services) — 1 doc(s) → [1.0/apps/walmarttechservices/INDEX.md](1.0/apps/walmarttechservices/INDEX.md)
 - **test** (Test) — 15 doc(s) → [1.0/apps/test/INDEX.md](1.0/apps/test/INDEX.md)
 - **toga** (TOGa) — 3 doc(s) → [1.0/apps/toga/INDEX.md](1.0/apps/toga/INDEX.md)
-- **tools** (Tools) — 16 doc(s) → [1.0/apps/tools/INDEX.md](1.0/apps/tools/INDEX.md)
+- **tools** (Tools) — 17 doc(s) → [1.0/apps/tools/INDEX.md](1.0/apps/tools/INDEX.md)
 
 ## 2.0 framework
 
-- **_underscore** (_Underscore) _(framework core)_ — 79 doc(s) → [2.0/apps/_underscore/INDEX.md](2.0/apps/_underscore/INDEX.md)
+- **_underscore** (_Underscore) _(framework core)_ — 80 doc(s) → [2.0/apps/_underscore/INDEX.md](2.0/apps/_underscore/INDEX.md)
 - **worker2** (Worker) — 59 doc(s) → [2.0/apps/worker2/INDEX.md](2.0/apps/worker2/INDEX.md)
 - **api2** (API) — 25 doc(s) → [2.0/apps/api2/INDEX.md](2.0/apps/api2/INDEX.md)
 - **dbchanges2** (Database Changes) _(framework core)_ — 15 doc(s) → [2.0/apps/dbchanges2/INDEX.md](2.0/apps/dbchanges2/INDEX.md)

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

@@ -12,12 +12,13 @@ apps:
   - worker2
   - dbchanges2
   - library
+  - tools
 project: _Underscore
 client: compass-canada
 type: profile
 status: active
-updated: 2026-09-01
-owners: [jcardinal, bala, tcox, apeterson]
+updated: 2026-09-04
+owners: [jcardinal, bala, tcox, apeterson, ajean]
 files: []
 related:
   - ../compass-usa/profile.md

package/knowledge/clients/compass-usa/features/people-file-user-lifecycle.md

@@ -6,12 +6,13 @@ project: Worker
 client: compass-usa
 type: client-feature
 status: active
-updated: 2026-08-20
-owners: [bala]
+updated: 2026-09-04
+owners: [bala, ajean]
 files:
   - worker2/Worker/Client/Compass/PeopleFile.php
 related:
   - ./persona-model-and-levy-gating.md
+  - ../../../1.0/apps/tools/features/compass-user-persona-admin.md
   - ./approval-decision-flow.md
   - ./stranded-approval-reassignment.md
   - ../profile.md
@@ -118,9 +119,27 @@ rediscovered, and the deactivation path has no model hooks at all (see below).
 - **`_Model_Client_Logs_Record::addNote()` is a no-op in this cron.** Staged notes are only flushed
   by api2, so a worker must write its `Record` rows itself. See
   [Record Change Audit Log](../../../2.0/apps/_underscore/features/record-change-audit-log.md).
-- **`Client_Compass.Users` is 176,057 rows with no index on `c_hrEmpPersonnelNbr`, `email`, or
-  `isActive`.** Any per-row lookup you add against those columns is a full scan of ~174k rows. An
-  index migration is recommended and **not yet done**.
+- **`Client_Compass.Users` is ~176,000 rows with no index on `c_hrEmpPersonnelNbr`, `email`,
+  `c_hrEmpUsername`, or `isActive`.** Any per-row lookup you add against those columns is a full
+  scan — `EXPLAIN` returns `type=ALL`, 176,018 rows, no possible keys (re-confirmed on prod
+  2026-09-02, and the same on `Client_CompassCanada`). An index migration is recommended and **still
+  not done**. **The blank-client template is not a safe proxy for this schema**: `dbchanges2/Client/
+  2026-06-03- BLANK_CLIENT_DATABASE.sql` declares `UNIQUE KEY email (email)`, and Compass has
+  diverged from it. Check the live tenant, never the template.
+- **⚠ `executeForTenant()`'s inactivation sweep is the ONLY place in the file that writes
+  `isActive = 0`.** Every other `isActive` path in the ~2,200-line class only forces it back to
+  **1**. Two consequences: (a) **an activation made outside this cron is temporary** — the next run
+  deactivates the person again unless they are in that day's PEOPLE file — while (b) **a
+  deactivation is durable**, because nothing here ever reactivates anyone on its own. This is what
+  makes the [Tools Compass admin
+  pages](../../../1.0/apps/tools/features/compass-user-persona-admin.md) a one-way-durable tool.
+- **`ensureCrossRegionUsersActive()` runs `UPDATE Users SET isActive = 1 WHERE email = X` with no
+  `isActive` filter**, so it reactivates **every** row carrying one of its four hardcoded addresses,
+  dead duplicates included. Verified on prod 2026-09-02: each of the four addresses currently
+  resolves to exactly **one** active row in **both** tenants (zero inactive), so nothing is being
+  resurrected today — but the query would happily do it if a duplicate appeared. That hardcoded list
+  is also still the **only** durable way to hold a cross-region user active, and changing it needs a
+  code change and a deploy per request.
 
 ## Remediation — BUILT 2026-08-20
 
@@ -151,6 +170,17 @@ question is now contained rather than blocking.
 
 ## Change history
 
+- 2026-09-04 — Recorded that the inactivation sweep in `executeForTenant()` is the **only**
+  `isActive = 0` writer in the whole class (every other path only forces it back to 1), so an
+  activation made outside the cron is **temporary** while a deactivation is **durable** — the
+  governing constraint on the new [Tools Compass admin
+  pages](../../../1.0/apps/tools/features/compass-user-persona-admin.md). Noted that
+  `ensureCrossRegionUsersActive()` filters on email only, so it would reactivate dead duplicates
+  too (prod check 2026-09-02: one active row per address in both tenants, so nothing is being
+  resurrected today), and that its hardcoded four-address list remains the only durable
+  cross-region hold. Extended the missing-index gotcha with `c_hrEmpUsername`, the `EXPLAIN`
+  evidence, and the fact that the blank-client template's `UNIQUE KEY email` does **not** describe
+  this tenant. (ajean)
 - 2026-08-20 — **Built the remediation** that this doc had recorded as designed-but-unbuilt: the
   importer is now a thin trigger that collects newly created user ids and calls the new worker action
   `Client/Compass/ApprovalReassignment/Reassign` **after the tenant transaction commits**; all the

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

@@ -6,12 +6,13 @@ project: Worker
 client: compass-usa
 type: client-feature
 status: active
-updated: 2026-08-26
-owners: [bala]
+updated: 2026-09-04
+owners: [bala, ajean]
 files:
   - worker2/Worker/Client/Compass/PeopleFile.php
 related:
   - ./people-file-user-lifecycle.md
+  - ../../../2.0/apps/_underscore/features/effective-persona-resolution.md
   - ../profile.md
   - ../workflows/persona-refactor-migration.md
   - ../workflows/persona-population-env-comparison.md
@@ -95,6 +96,13 @@ hierarchy root**:
          └─ … (users sit ~5 levels below 55)
 ```
 
+> **How a user's personas are *read* is a different rule from how this cron *assigns* them.** The
+> effective set is a UNION of `Users_Personas`, the user's own `Locations_Personas`, and their
+> sector's — and on prod **67,157 of 74,268** active Compass users get theirs from the **sector**,
+> not from a row of their own. See
+> [Effective persona resolution](../../../2.0/apps/_underscore/features/effective-persona-resolution.md)
+> before writing any "who has persona N" query.
+
 ## Persona assignment, by tenant
 
 **US** (`$tenantKey === 'US'`):
@@ -138,6 +146,12 @@ VIP (35) and CDL (30) handling is orthogonal and applies to both tenants unchang
   constants from this file into tickets, docs, or chat transcripts.
 
 ## Change history
+- 2026-09-04 — Linked the framework rule for **reading** effective personas
+  ([Effective persona resolution](../../../2.0/apps/_underscore/features/effective-persona-resolution.md)):
+  `_Model_Client_User::_personaIds()` unions `Users_Personas`, the user's own `Locations_Personas`
+  and their sector's, and on prod 2026-09-02 **67,157 of 74,268** active Compass users resolve
+  through the **sector** (Canada: 4,029 of 4,948). Assignment by this cron and resolution at read
+  time are separate rules — do not answer "who has persona N" from `Users_Personas`. (ajean)
 - 2026-08-26 — **Correction from a read-only prod check.** The "Non-Levy = id **38** on dev-sandbox
   *and* prod" claim is wrong: prod has **no Non-Levy persona** and id 38 is **"MyDining- KDS"**, so
   prod's auto-increment is past 38 and persona 1 is still named **"All"**. Reinforces resolve-by-name.

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

@@ -15,12 +15,13 @@ apps:
   - library
   - test
   - talos-backend
+  - tools
 project: _Underscore
 client: compass-usa
 type: profile
 status: active
-updated: 2026-09-02
-owners: [jcardinal, bala, tcox, apeterson, dfranks, akhokhani]
+updated: 2026-09-04
+owners: [jcardinal, bala, tcox, apeterson, dfranks, akhokhani, ajean]
 files: []
 related:
   - ../../2.0/apps/_underscore/features/sales-order-po-number-sourcing.md

package/knowledge/clients/compass-usa/workflows/granting-persona-bundle-access.md

@@ -6,13 +6,15 @@ project: Database Changes
 client: compass-usa
 type: workflow
 status: active
-updated: 2026-09-02
-owners: [bala]
+updated: 2026-09-04
+owners: [bala, ajean]
 files:
   - dbchanges2/Client_Compass/2026-08-26a - CompassCreativeStudioPersona.sql
 related:
   - ./granting-navigation-access.md
   - ./changing-a-kit-line-item.md
+  - ../../../2.0/apps/_underscore/features/effective-persona-resolution.md
+  - ../../../1.0/apps/tools/features/compass-user-persona-admin.md
   - ../features/persona-model-and-levy-gating.md
   - ./persona-refactor-migration.md
   - ./persona-population-env-comparison.md
@@ -139,6 +141,11 @@ A user's **effective** persona set is three UNIONed sources, not just `Users_Per
 3. `Locations_Personas` on the user's **sector** — five `parentLocationId` hops up
    (location → complex → district → region → division → sector).
 
+The framework already implements exactly this in `_Model_Client_User::_personaIds()` — mirror it
+rather than re-deriving it, and note that on prod the **sector** hop is where almost every Compass
+user gets their personas. Full rule and the measured numbers:
+[Effective persona resolution](../../../2.0/apps/_underscore/features/effective-persona-resolution.md).
+
 **Check all three before adding anything** — the user may already reach the bundle through their
 location, in which case the right answer is "no change needed". After the grant, re-run the same
 resolution and confirm the bundle number appears; the verification block at the end of the template
@@ -167,6 +174,12 @@ tooling uses — see
   removed. A "remove access" request is a different, destructive job and needs its own review.
 
 ## Change history
+- 2026-09-04 — Pointed the three-source verification step at the framework's own implementation,
+  `_Model_Client_User::_personaIds()`, now documented with prod measurements in
+  [Effective persona resolution](../../../2.0/apps/_underscore/features/effective-persona-resolution.md).
+  The Tools [Compass admin pages](../../../1.0/apps/tools/features/compass-user-persona-admin.md)
+  now do the "grant a persona to a user" step (`Users_Personas` insert) in a browser; the bundle /
+  item / assortment work in this file still needs SQL. (ajean)
 - 2026-09-02 — Recorded the **reverse case** and cross-linked it: adding a new line to a kit that
   personas *already* own hits the same item-ACL rule, so a fully active `BundleItems` row is omitted
   per-persona until `Personas_Items` is backfilled (item 687 `TabAdminSuppPro` reached only MITS Team

package/package.json

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