toga-ai 1.0.379 → 1.0.381

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

@@ -11,6 +11,7 @@
 | [@goagilant.com → @togatech.com Email-Domain Migration (1.0 + 2.0)](features/goagilant-to-togatech-email-migration.md) | Reference + technique for migrating the company email domain `@goagilant.com` → `@togatech.com` across **both** platforms. | migrate_goagilant_to_togatech_2026-06-26.sql, migrate_goagilant_to_togatech_LEGACY_2026-06-26.sql |
 | [TableView Builder (2.0 TableViews SQL generator)](features/tableview-builder.md) | `team/tableViewBuilder/` generates SQL `INSERT` statements for the **2.0 `TableViews`**, `TableViewFields`, and `TableViewJoins` tables from a plain SQL `SELECT | test/team/tableViewBuilder/TableViewGenerator.php, test/team/tableViewBuilder/index.php, test/team/tableViewBuilder/Instructions.md |
 | [Talos Knowledge Base Pipeline (Uploader + Processor)](features/talos-kb-pipeline.md) | `team/talos/` holds the two-script web tooling that feeds the **TOGa Talos** (TOGa IQ) AI knowledge bases. | test/team/talos/kb_uploader.php, test/team/talos/kb_processor.php, test/team/talos/kb_processor.ini |
-| [TOGa 2.0 Client Onboarding SQL Generator](features/toga2-client-onboarding-sql.md) | `team/generate_toga2_onboarding_sql.php` generates the SQL needed to **onboard a new client** onto the 2.0 platform. | test/team/generate_toga2_onboarding_sql.php |
+| [TOGa 2.0 Client Onboarding SQL Generator](features/toga2-client-onboarding-sql.md) | > **Superseded by the browser wizard.** The generation logic here was extracted into the reusable > `OnboardingSqlGenerator` class and wrapped in a local browse | test/team/generate_toga2_onboarding_sql.php |
+| [TOGa 2.0 Client Onboarding Wizard (local tool)](features/toga2-onboarding-wizard.md) | A **local browser wizard** (`test/team/onboarding/`) that automates 2.0 client onboarding end to end: it (1) gathers developer input and **generates all onboard | test/team/onboarding/index.php, test/team/onboarding/classes/OnboardingSqlGenerator.php, test/team/onboarding/classes/DbchangesConsolidator.php, test/team/onboarding/README.md |
 | [TOGa 2.0 User Cross-Client Access SQL Generator](features/toga2-user-cross-client-access-sql.md) | `team/generate_toga2_user_access_sql.php` generates SQL to grant an existing 2.0 user from a **home client** access to a **cross client**. | test/team/generate_toga2_user_access_sql.php |
 | [URL & Domain Markdown Document Builder](features/url-domain-markdown-document.md) | `team/build_url_domain_markdown_document.php` generates a **markdown document of our URLs and domains** by pulling environments and domains from the 2.0 platfor | test/team/build_url_domain_markdown_document.php |

package/knowledge/1.0/apps/test/features/toga2-client-onboarding-sql.md

@@ -6,16 +6,23 @@ project: Test
 client: shared
 type: feature
 status: active
-updated: 2026-06-23
+updated: 2026-07-20
 owners: [jcardinal, mhammontree]
 files:
   - test/team/generate_toga2_onboarding_sql.php
 related:
   - ../architecture.md
+  - ./toga2-onboarding-wizard.md
   - ./toga2-user-cross-client-access-sql.md
   - ../../../2.0/apps/dbchanges2/workflows/client-onboarding.md
 ---
 
+> **Superseded by the browser wizard.** The generation logic here was extracted into the reusable
+> `OnboardingSqlGenerator` class and wrapped in a local browser tool that also implements the
+> consolidation the `SHOULD_CONSOLIDATE` / `RELATIVE_PATH_TO_DBCHANGES2` consts only stubbed — see
+> [TOGa 2.0 Client Onboarding Wizard](./toga2-onboarding-wizard.md). The refactor also added the
+> input validation + escaping this original script lacked.
+
 ## Summary
 
 `team/generate_toga2_onboarding_sql.php` generates the SQL needed to **onboard a new client**
@@ -68,6 +75,10 @@ already have the `Base`/`API` roles from the blank seed so the `Apis_Roles` look
 
 ## Change history
 
+- 2026-07-20 — Generation logic extracted into the reusable `OnboardingSqlGenerator` class (input
+  validation + escaping added — the escaper now matches `_underscore` `Mysql::escape`) and wrapped
+  in a local browser wizard that implements the stubbed consolidation consts. See
+  [toga2-onboarding-wizard](./toga2-onboarding-wizard.md). (mhammontree)
 - 2026-06-23 — Fixed `Apis_Roles` duplicate-uuid bug (use `UUID()` per row); fixed PHP 8 fatal from
   an unquoted `CREATE_CLIENT_API_NAME` constant; implemented the previously-unused client-API block
   (`CREATE_CLIENT_API_NAME`) so it emits both the Agilant and client keys; documented core/client

package/knowledge/1.0/apps/test/features/toga2-onboarding-wizard.md

@@ -0,0 +1,112 @@
+---
+title: TOGa 2.0 Client Onboarding Wizard (local tool)
+framework: "1.0"
+repo: test
+project: Test
+client: shared
+type: feature
+status: active
+updated: 2026-07-20
+owners: [mhammontree]
+files:
+  - test/team/onboarding/index.php
+  - test/team/onboarding/classes/OnboardingSqlGenerator.php
+  - test/team/onboarding/classes/DbchangesConsolidator.php
+  - test/team/onboarding/README.md
+related:
+  - ./toga2-client-onboarding-sql.md
+  - ../../../2.0/apps/dbchanges2/workflows/client-onboarding.md
+  - ../../../2.0/apps/dbchanges2/architecture.md
+---
+
+## Summary
+
+A **local browser wizard** (`test/team/onboarding/`) that automates 2.0 client onboarding end
+to end: it (1) gathers developer input and **generates all onboarding SQL** for a new client, and
+(2) **consolidates the dbchanges2 loose SQL** into a rebuilt blank plus a HISTORIC archive. It is
+the implementation of the previously-stubbed `SHOULD_CONSOLIDATE` / `RELATIVE_PATH_TO_DBCHANGES2`
+constants from the older CLI script
+([toga2-client-onboarding-sql](./toga2-client-onboarding-sql.md)).
+
+**Cross-framework by nature.** The tool is *hosted* in the 1.0 `test` repo, but it is
+**self-contained — it does NOT boot any framework** (no `App_` sandbox), so it can run from any
+folder depth. Its output targets the **2.0** platform (Core + `Client_<Id>` databases) and it
+operates directly on the **2.0 `dbchanges2`** repo working tree.
+
+**Local-only — never deploy publicly.** It runs shell commands (`mysql`/`mysqldump`/`git`) and
+renders live API **secrets**. It must only ever run on a developer's machine.
+
+## How it works
+
+### Part 1 — SQL generation (`OnboardingSqlGenerator`)
+
+A reusable refactor of `generate_toga2_onboarding_sql.php`. Full **10-step** onboarding coverage
+(the original CLI script emitted only steps 5–7). Emits SQL in **labeled, cluster-scoped**
+sections so each block runs against the correct cluster:
+
+- **(A) `CREATE DATABASE`** `Client_<Id>` / `Logs_<Id>` / `Archive_<Id>` with
+  `utf8mb4` / `utf8mb4_0900_ai_ci`.
+- **(B)** blank-apply instructions.
+- **(C) `Core.*` inserts** (`Databases`, `Clients`, `Domains`, `ClientEmailDomains`,
+  `DatabaseHosts`) — secret-free, **committable**, run on the **CORE** cluster.
+- **(D) `Apis` + `Apis_Roles`** — **SECRET**, run on the **`Client_<Id>`** cluster, **never
+  commit** (distribute the secret out-of-band).
+- Plus a one-tap append of `Client_<Id>` to `test/team/2.0 deployment/Clients_Db.txt`.
+
+Applying the Client blank (step B) also covers onboarding **step 9** because the blank carries the
+baseline roles/ACL and **ticket reference data** (Urgencies / TicketTypes / TicketStages /
+TicketTopics) — skip it and the first ticket-create fails with **`EV-12`**.
+
+### Part 2 — dbchanges2 consolidation (`DbchangesConsolidator`)
+
+Folds the loose `Client/*.sql` changes back into a fresh blank + archives the old files. Algorithm:
+
+1. Execute the current blank `Client/<date>-BLANK_CLIENT_DATABASE.sql` into a **scratch DB**
+   (drop + recreate; `utf8mb4`).
+2. Apply all loose `Client/*.sql` in **filename (date) order**.
+3. `mysqldump` the result into the new blank, **two-pass**: pass 1 `--no-data` for all tables
+   (incl. `Apis` **structure**); pass 2 `--no-create-info --ignore-table=<db>.Apis` for **data
+   minus the `Apis` secrets**. New blank = `"<date> - BLANK_CLIENT_DATABASE.sql"`.
+4. `git mv` the old blank + all loose files into `Client/HISTORIC/Files Before <date>/`. The new
+   blank stays active. **Nothing is committed or pushed — changes are staged only.**
+
+**Scope of consolidation:**
+- `Client/` consolidation is **automatic** every run.
+- `_modules/<module>/` consolidation is **opt-in per run**, discovered from the folder tree and
+  keyed by **module name** (e.g. `netsuite`, `startech`, `Ai`, `Bdr`) — **not** per-client.
+  Genuinely-new modules scaffold `_modules/<Module>/` + its `HISTORIC/`. A module's base file is
+  matched by `/(BLANK|CLEAN)/i` (e.g. `CLEAN NETSUITE CLIENT.SQL`).
+
+## Safety model
+
+- **Preview-first.** `buildPlan()` shows the base file, the loose files, the new blank name, and
+  the archive dir **before** anything runs.
+- **Execution double-gated.** Requires an explicit acknowledgment that *"loose files are already
+  applied to ALL existing clients"* (else the new blank diverges from live clients — see the
+  dbchanges2 architecture consolidation lifecycle) **plus** a confirm dialog.
+- **Credentials** are passed via a temp `--defaults-extra-file` (deleted in a `finally`), **never**
+  on the command line and never written into the repo.
+- **Shell is allowlisted** to `mysql` / `mysqldump` / `git`; `mysqlBin` / `mysqldumpBin` are
+  validated; every path is `escapeshellarg`-escaped; a path-traversal guard ensures the target
+  stays inside the dbchanges2 root.
+
+## Gotchas
+
+- **Own UUIDv4, not the framework's.** Because the tool boots no framework, it generates
+  crypto-safe UUIDv4s via `random_bytes` (not `App_Misc::generateUUID`), so it runs from any depth.
+- **`sqlString()` escaper matches the 2.0 canonical escaper EXACTLY** —
+  `_underscore\Database\Driver\Mysql::escape`'s set (`\` `\x00` `\n` `\r` `'` `"` `\x1a`). The
+  original CLI script did **zero** input escaping; this refactor adds validation + escaping, a net
+  security improvement — keep the two escapers in sync if the framework escaper changes.
+- **`Apis_Roles` uses MySQL `UUID()` per row** (documented framework exception): the
+  `INSERT … SELECT` for `Base`+`API` returns 2 rows, each needing a distinct uuid, so a literal
+  would collide.
+- **Never commit the section (D) `Apis` output** — it contains real secret values.
+
+## Change history
+
+- 2026-07-20 — Built the browser wizard (TRUE-79864): `OnboardingSqlGenerator` (reusable refactor
+  of the CLI script, now with input validation + escaping and full 10-step coverage) and
+  `DbchangesConsolidator` (scratch-DB rebuild → two-pass `mysqldump` → `git mv` to HISTORIC,
+  staged-only). Implements the previously-stubbed `SHOULD_CONSOLIDATE` /
+  `RELATIVE_PATH_TO_DBCHANGES2` consts. Local-only tool. (mhammontree)

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

@@ -344,6 +344,22 @@ multi-file UI components (`.php`/`.html`/`.css`/`.js`) invoked as `<_ComponentNa
 - **`_Database::register()` auto-starts a lazy transaction (since Apr 2 2026, commit `fa7835ed`).** Any code that calls `register()` and then writes to that DB must call `_Database::transactionCommit()` before the request ends — otherwise MySQL silently rolls back all writes when the connection closes. Lazy transactions only materialise on the first write, so read-only callers are unaffected. See `_underscore/Database.php:48`. First discovered when Rate SAML user provisioning silently discarded all new user INSERTs (Jun 2026).
 - **PHP "Unclosed '{'" parse errors report a MISLEADING line number.** When a `.php` file loaded by the autoloader (`Loader.php`) has a dropped/unbalanced brace, PHP reports `Unclosed '{' on line N` where N is the **outermost `class X {` line** and fails at EOF — NOT at the true location of the missing `}`. Worse, because the file loads lazily via the SPL autoloader, the runtime trace points at the **caller** that triggered the autoload (e.g. a `new _Email()` call site), not the broken file. **Triage rule:** for an "Unclosed '{'" error, the real culprit is a missing `}` somewhere between the reported line and EOF of the file that failed to load — run `php -l <file>` (it reports the EOF line) and scan the whole file. **Merge-conflict resolutions are a common source of a single dropped brace** — review the entire merge, not just the one file the error appears to name. (First hit: production 500 EO-1, Jul 2026 — a `}` dropped from `_Email::send()` during merge `685e4a14` surfaced as a trace pointing at the `new _Email()` caller.)
 
+- **A controller exception is silently swallowed by `Route.php`, then masked as a view error.** In
+  dispatch, `_underscore/Route.php` (~lines 462–468) wraps the controller call in
+  `catch (Exception $e) { _Database::transactionRollback(); }` — **no log, no rethrow, no debug
+  bypass.** The controller response is left null, so Route.php falls through to its generic throw at
+  line 525: `Failed to determine how to render view for route '<route>' ... './View/Index/<method>.html'`.
+  **Therefore this "Failed to determine how to render view" fatal is very often a MASK for a real
+  exception thrown inside the controller method** (commonly `_Controller_Index::api()`), not a genuine
+  routing/view misconfiguration. A frequent culprit is a DB connect / "Unknown database" failure in
+  `api()`'s **unguarded pre-execute block** (it registers `DB_LOGS` and queries `Logs.Api` for the
+  transactionId-uniqueness check *before/outside* the only try/catch, which wraps just
+  `$api->execute()` at ~line 205). When diagnosing the line-525 error, look for a thrown exception in
+  the controller — not the view layer. (Note: an *unmatched host* does NOT trigger this; `api()`
+  returns a response object that gets JSON-encoded — only a thrown exception hits the line-525 path.)
+  See `2.0/apps/api2/workflows/environment-configuration-and-provisioning.md`. Fix candidate: have
+  Route.php log/rethrow the swallowed exception (or expose it under debug) instead of discarding it.
+
 ## Change history
 - 2026-06-11 — Documented lazy transaction gotcha in `_Database::register()` (rgirish)
 - 2026-06-25 — Added the Surface platform UI presentation/configuration layer (DB-driven UI config replacing `Page::meta()`, CTO-reviewed AGREE-WITH-ADJUSTMENTS) (jcardinal)

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

@@ -13,4 +13,4 @@
 | [Tickets API (/v2/tickets)](features/tickets-api.md) | The generic ticket endpoint of the 2.0 REST API. | Component/Api/V2/V2.php |
 | [V2 API error/message codes (EV/EZ troubleshooting map)](features/v2-api-error-codes.md) | The V2 JSON engine (`Component/Api/V2/V2.php`) returns short **message codes** in the response `error` field, grouped by family: `EN-*` authentication, `EZ-*` a | api2/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**. |  |
-| [New Environment Configuration & Provisioning (api2)](workflows/environment-configuration-and-provisioning.md) | What it takes for a 2.0 API environment (e.g. | api2/Config/<environment>.ini, api2/Controller/Index.php, dbchanges2/Core/2026-06-16a - DatabaseHosts for new QA QC stage demo environments.sql, _underscore/Route.php |
+| [New Environment Configuration & Provisioning (api2)](workflows/environment-configuration-and-provisioning.md) | What it takes for a 2.0 API environment (e.g. | api2/Config/<environment>.ini, api2/Controller/Index.php, dbchanges2/Core/2026-06-16a - DatabaseHosts for new QA QC stage demo environments.sql, dbchanges2/Logs/, _underscore/Route.php |

package/knowledge/2.0/apps/api2/workflows/environment-configuration-and-provisioning.md

@@ -6,12 +6,13 @@ project: API
 client: shared
 type: workflow
 status: active
-updated: 2026-06-16
+updated: 2026-07-20
 owners: ["jcardinal"]
 files:
   - api2/Config/<environment>.ini
   - api2/Controller/Index.php
   - dbchanges2/Core/2026-06-16a - DatabaseHosts for new QA QC stage demo environments.sql
+  - dbchanges2/Logs/
   - _underscore/Route.php
 related: []
 ---
@@ -52,6 +53,16 @@ the real cause.
    DBs must be provisioned and the `dbchanges2` migrations applied before the app can connect.
    Until then, every request throws on the first Core query.
 
+5. **Seed the base `Logs` schema — separate from the per-tenant `Logs_<Client>` DBs.** The
+   Core-level logs database `Logs` (`Core.Databases` id `11`, framework alias `_underscore::DB_LOGS`;
+   tables `Api`, `Error`, `Webhook`) is a **distinct** database from each client's `Logs_<Client>`
+   schema and is easy to miss on an all-in-one cluster where every `Logs_<Client>` exists but base
+   `Logs` does not. `_Controller_Index::api()` registers `DB_LOGS` and queries `Logs.Api` on **every**
+   request (transactionId-uniqueness check) — so if base `Logs` is absent, **every** API request 500s
+   with an "Unknown database 'Logs'" thrown before execute, which then surfaces as the misleading
+   Route.php:525 view fatal (see Edge cases). `dbchanges2` has a dedicated `Logs/` migration folder
+   for this database; apply it alongside `Core` and the tenant schemas.
+
 ## Systems involved
 - **api2** — `Config/<env>.ini` (DB + API hosts); `Controller/Index.php::api()` registers `Core`
   from `[database]` then dispatches by hostname.
@@ -79,8 +90,27 @@ Diagnostic order:
 2. Connect to the resolved host and `SHOW DATABASES` — confirm `Core` actually exists (a fresh
    cluster has only `information_schema/mysql/performance_schema/sys` → not seeded yet).
 3. Confirm `Core.DatabaseHosts` has rows for this `environmentId` (Core Logs DB id is `11`).
+4. **`SHOW DATABASES` and confirm the base `Logs` schema exists**, not just `Logs_<Client>`.
+   `SELECT SCHEMA_NAME FROM information_schema.SCHEMATA WHERE SCHEMA_NAME='Logs'` should return one
+   row (compare against prod, where it lives on `prod-logs`). Zero rows = base `Logs` missing → every
+   request 500s with the Route.php:525 view fatal. The failure **cannot self-report**: `api()`'s
+   error handler writes into `Logs.Api` (the same missing schema) when the env's `[api]` block has no
+   `log_filepath`, so the diagnosis must come from `SHOW DATABASES`, not the logs. Fix by applying the
+   `dbchanges2/Logs/` migration (tables `Api`, `Error`, `Webhook`).
+
+**What is NOT the cause here:** on `sandbox-client` (Environments id 24) the Core DB, the env's
+`DatabaseHosts` rows, JWT-secret `Parameters`, and `Domains` were all present and correct — the base
+`Logs` schema was the *only* thing missing. Don't chase seed/config/connectivity when only base `Logs`
+is absent.
 
 ## Change history
+- 2026-07-20 — `sandbox-client` API 500'd on every request (Route.php:525 view fatal). Root cause: the
+  base `Logs` schema (`DB_LOGS`, `Core.Databases` id 11; tables Api/Error/Webhook) was missing on the
+  all-in-one cluster although every `Logs_<Client>` existed. `_Controller_Index::api()` queries
+  `Logs.Api` before its try/catch, so "Unknown database 'Logs'" was swallowed by Route.php and masked
+  as a view error; it also couldn't self-log (no `log_filepath`, so errors write to the missing Logs).
+  Fixed by applying the `dbchanges2/Logs/` migration. Added base-`Logs` provisioning step 5 + the
+  `SHOW DATABASES` diagnostic. (jcardinal)
 - 2026-06-16 — Documented after fixing `qc-security`: `[database] hostname` was reversed
   (`qc.security...`), which threw on Core connect and surfaced as the Route.php:525 view fatal.
   Added the `2026-06-16a` Core migration registering `DatabaseHosts` for the stage/demo/qa-*/qc-*

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

@@ -4,4 +4,4 @@
 |-----|---------|-------|
 | [Database Changes (dbchanges2) Repository Architecture](architecture.md) | `dbchanges2` is the **schema-migration / SQL change-set repository** for the entire 2.0 platform. | Core/, Client/, Client_<Tenant>/, Logs/, Logs_Client/, _modules/ |
 | [Surface Layer Schema (UI presentation/config tables)](features/surface-layer-schema.md) | The persistent schema for the platform-wide **Surface** UI presentation/configuration layer (see the `_underscore` [surface-resolver](../../_underscore/features | dbchanges2/Client/2026-06-25a - SurfaceClientTables.sql, dbchanges2/Client_Compass/2026-06-25d - SalesOrderSurfaceClientSeed.sql, _underscore/Model/Client/ThemeToken.php, toga25-supply/src/themeConfig.json, dbchanges2/Core/2026-06-25a - SurfaceCoreTables.sql, dbchanges2/Core/2026-06-25b - SurfaceRecordsAndFields.sql, dbchanges2/Core/2026-06-25c - SalesOrderLoginSurfaceSeed.sql, dbchanges2/Core/2026-06-29a - ItemsSurfaceSeed.sql, dbchanges2/Core/2026-06-29b - SurfaceMetaPublicReadAcl.sql, dbchanges2/Client/2026-06-29c - SurfaceRecordScriptAcl.sql, dbchanges2/Core/2026-06-29c - SurfaceDebugPhpMethodFix.sql, dbchanges2/Core/2026-06-29d - VendorItemsSurfaceSeed.sql, dbchanges2/Core/2026-06-29e - InventorySurfaceSeed.sql, dbchanges2/Core/2026-06-30a - SurfaceMetaGroupAndSalesOrderSections.sql, dbchanges2/Client/2026-06-30a - SurfaceMetaGroupAcl.sql, dbchanges2/Client_Compass/2026-06-30a - SalesOrderDisplaySectionManagerOverrides.sql, dbchanges2/Client_CompassCanada/2026-06-30a - SalesOrderSurfaceManagerOverrides.sql, dbchanges2/Client_Quad/2026-06-30a - SalesOrderSurfaceClientOverrides.sql, dbchanges2/Client/2026-06-25a - SurfaceClientTables.sql, dbchanges2/Client/2026-06-25b - SurfaceClientSeed.sql, dbchanges2/Client/2026-06-25c - SurfaceClientAcl.sql, dbchanges2/Client/2026-06-03- BLANK_CLIENT_DATABASE.sql, dbchanges2/Core/2026-07-17h - Update - ClearApprovalsFilterButtonConfig.sql, dbchanges2/Client_Compass/2026-07-17a - SalesOrderApprovalActionsOverride.sql, dbchanges2/Client_Compass/2026-07-17b - SalesOrderApprovalsFilterButtonOverride.sql, dbchanges2/Client_CompassCanada/2026-07-17a - SalesOrderApprovalActionsOverride.sql, dbchanges2/Client_CompassCanada/2026-07-17b - SalesOrderApprovalsFilterButtonOverride.sql, dbchanges2/Client_Quad/2026-07-17a - SalesOrderApprovalActionsOverride.sql, dbchanges2/Client_Quad/2026-07-17b - SalesOrderApprovalsFilterButtonOverride.sql, dbchanges2/Core/2026-07-20a - Update - HideAdminNotesSectionByDefault.sql, dbchanges2/Core/2026-07-20b - Update - NotesSectionFieldElements.sql, dbchanges2/Client_Compass/2026-07-20a - AdminNotesSectionVisibilityOverride.sql, dbchanges2/Client_Compass/2026-07-20b - NotesSectionFieldsOverride.sql, dbchanges2/Client_CompassCanada/2026-07-20a - AdminNotesSectionVisibilityOverride.sql, dbchanges2/Client_CompassCanada/2026-07-20b - NotesSectionFieldsOverride.sql, dbchanges2/Client_Quad/2026-07-20a - NotesSectionFieldsOverride.sql, dbchanges2/Core/2026-07-20c - Update - VendorItemsToggleSurfaceSeed.sql, dbchanges2/Client_Compass/2026-07-20c - ItemRecordEditButtonEnable.sql, dbchanges2/Client_Compass/2026-07-20d - ItemRecordVendorItemsEnable.sql, dbchanges2/Client_CompassCanada/2026-07-20c - ItemRecordEditButtonEnable.sql, dbchanges2/Client_CompassCanada/2026-07-20d - ItemRecordVendorItemsEnable.sql, dbchanges2/Core/2026-07-17 - README - RUN ORDER.md |
-| [2.0 New-Client Onboarding (manual process)](workflows/client-onboarding.md) | How to manually stand up a new 2.0 client (tenant). | Client/, Client_<Tenant>/, Core/, Logs_Client/ |
+| [2.0 New-Client Onboarding (manual process)](workflows/client-onboarding.md) | > **A local browser wizard now automates this.** Steps 2–9 below (create DBs, generate Core/API > inserts, append to `Clients_Db.txt`) — plus the dbchanges2 bla | Client/, Client_<Tenant>/, Core/, Logs_Client/ |

package/knowledge/2.0/apps/dbchanges2/architecture.md

@@ -6,7 +6,7 @@ project: Database Changes
 client: shared
 type: architecture
 status: active
-updated: 2026-07-09
+updated: 2026-07-20
 owners: [jcardinal, mhammontree, bala]
 files:
   - Core/
@@ -147,6 +147,12 @@ client appeared to onboard but failed at the API.
 3. `git mv` the old blank + the consolidated loose files into `Client/HISTORIC/FILES BEFORE <DATE>/`,
    leaving `Client/` with only the new dated blank.
 
+This lifecycle is automated by a local browser tool — see the
+[TOGa 2.0 Client Onboarding Wizard](../../1.0/apps/test/features/toga2-onboarding-wizard.md)
+(`DbchangesConsolidator`): scratch-DB rebuild → two-pass `mysqldump` (keeping `Apis` structure but
+not its secret data) → `git mv` old blank + loose files into `Client/HISTORIC/`, staged only. Run
+it only after the loose files are applied to every live client (step 1 above still holds).
+
 **Applying loose files** requires `SET FOREIGN_KEY_CHECKS=0` — several `ALTER … MODIFY/DROP` a column
 that participates in a foreign key and otherwise fail with error 1832. (The blank dump sets this in
 its own header.)

package/knowledge/2.0/apps/dbchanges2/workflows/client-onboarding.md

@@ -16,9 +16,15 @@ files:
 related:
   - ../architecture.md
   - ../../../1.0/apps/test/features/toga2-client-onboarding-sql.md
+  - ../../../1.0/apps/test/features/toga2-onboarding-wizard.md
   - ../../api2/features/tickets-api.md
 ---
 
+> **A local browser wizard now automates this.** Steps 2–9 below (create DBs, generate Core/API
+> inserts, append to `Clients_Db.txt`) — plus the dbchanges2 blank **consolidation** — are automated
+> by the [TOGa 2.0 Client Onboarding Wizard](../../../1.0/apps/test/features/toga2-onboarding-wizard.md).
+> This doc remains the source of truth for what each step *means* and for running it manually.
+
 ## Summary
 
 How to manually stand up a new 2.0 client (tenant). A tenant spans three databases on three
@@ -94,4 +100,6 @@ Order matters — each step assumes the prior one ran.
 
 ## Change history
 
+- 2026-07-20 — Noted that a local browser wizard now automates steps 2–9 and the dbchanges2 blank
+  consolidation (TRUE-79864). (mhammontree)
 - 2026-06-23 — Initial capture from the Fordham onboarding (TRUE-79702). (mhammontree)

package/knowledge/INDEX.md

@@ -11,7 +11,7 @@ _Auto-generated by `knowledge.js index`. Do not hand-edit._
 - **togaview** (TOGa View) — 6 doc(s) → [1.0/apps/togaview/INDEX.md](1.0/apps/togaview/INDEX.md)
 - **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) — 12 doc(s) → [1.0/apps/test/INDEX.md](1.0/apps/test/INDEX.md)
+- **test** (Test) — 13 doc(s) → [1.0/apps/test/INDEX.md](1.0/apps/test/INDEX.md)
 - **toga** (TOGa) — 2 doc(s) → [1.0/apps/toga/INDEX.md](1.0/apps/toga/INDEX.md)
 - **tools** (Tools) — 8 doc(s) → [1.0/apps/tools/INDEX.md](1.0/apps/tools/INDEX.md)
 

package/package.json

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