toga-ai 1.0.173 → 1.0.174

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

@@ -6,48 +6,70 @@ project: Test
 client: shared
 type: feature
 status: active
-updated: 2026-06-16
-owners: [jcardinal]
+updated: 2026-06-23
+owners: [jcardinal, mhammontree]
 files:
   - test/team/generate_toga2_onboarding_sql.php
 related:
   - ../architecture.md
   - ./toga2-user-cross-client-access-sql.md
+  - ../../../2.0/apps/dbchanges2/workflows/client-onboarding.md
 ---
 
 ## Summary
 
 `team/generate_toga2_onboarding_sql.php` generates the SQL needed to **onboard a new client**
 onto the 2.0 platform. Runs on the **1.0 `App_` framework**
-(`App_Framework_Sandbox::initialize()`), but the SQL it produces targets the **2.0** client
-databases.
+(`App_Framework_Sandbox::initialize()`), but the SQL it produces targets the **2.0** Core and
+client databases. It is the *insert-generation* half of onboarding; the schema/blank half lives
+in dbchanges2 (see the [2.0 client onboarding workflow](../../../2.0/apps/dbchanges2/workflows/client-onboarding.md)).
 
 ## How it works
 
-Configure the `const` block, then run; the script emits the onboarding SQL to stdout for review.
+Configure the `const` block, then run; the script emits the onboarding SQL to stdout (`<pre>`).
 
 Key configuration:
-- `CLIENT_NAME` — formal client name, proper case (e.g. `'The Coca-Cola Company'`).
-- `CLIENT_IDENTIFIER` — PascalCase, no spaces (e.g. `'Cocacola'`).
+- `CLIENT_NAME` — formal client name, proper case (e.g. `'Fordham University'`).
+- `CLIENT_IDENTIFIER` — PascalCase, no spaces (e.g. `'Fordham'`) → drives `Client_<Id>` etc.
 - `CLIENT_SUBDOMAIN_IDENTIFIER` — lowercase, no spaces; the email domain without TLD.
 - `CLIENT_EMAIL_DOMAINS` — array of permitted email domains **with** TLD.
-- `SHOULD_CREATE_AGILANT_API` — when true, also creates the Agilant API user and api-roles.
+- `SHOULD_CREATE_AGILANT_API` — when true, creates the internal **Agilant** API key + api-roles.
+- `CREATE_CLIENT_API_NAME` — string (e.g. `'Fordham'`) to also create the **client** API key, or `null` to skip.
+- `RELATIVE_PATH_TO_DBCHANGES2`, `SHOULD_CONSOLIDATE` — declared but **not yet implemented** (no
+  consolidation logic in this script; the blank/consolidation lives in dbchanges2).
 
-Platform topology baked into the script:
-- `DATABASE_PREFIXES = ['Client', 'Logs', 'Archive']` — the three DB families a client gets.
-- `ENVIRONMENTS__DATABASE_PREFIXES__CLUSTERS` — per-environment (`dev` / `beta` / `production`)
-  host endpoints for each DB prefix. Production uses a global Aurora cluster with separate
-  writer/reader endpoints (`writer.client.database.togahub.com` / `reader1.client.database.togahub.com`);
-  dev/beta fall back to a single cluster (reader = writer).
+What it emits (UUIDs via `App_Misc::generateUUID()`; it does not touch the DB):
+- **Core inserts** → run on the **core cluster**: `Core.Databases` (Client_/Logs_/Archive_),
+  `Core.Clients`, `Core.Domains` (every app × env), `Core.ClientEmailDomains`, `Core.DatabaseHosts`
+  (prod null-region + 3 regions).
+- **Client inserts** → run on the **client cluster** (`Client_<Id>`): `Apis` + `Apis_Roles`.
+  Note: the `Apis` rows live in the **client** DB, not Core.
+
+## Output split (core vs client clusters)
+
+The script emits one combined blob; for deployment, split it: Core-table inserts to the core
+cluster, the `Apis`/`Apis_Roles` inserts to the client cluster (against `Client_<Id>`, which must
+already have the `Base`/`API` roles from the blank seed so the `Apis_Roles` lookup resolves).
 
 ## Gotchas
 
+- **`Apis_Roles` needs a unique uuid per row.** The role-link insert is
+  `INSERT … SELECT <uuid>, …, r.id FROM Roles WHERE r.name IN ('Base','API')` — that SELECT returns
+  **2 rows**, so a hardcoded literal uuid makes both rows share it → `Duplicate entry … for key
+  'Apis_Roles.uuid'`. Use MySQL **`UUID()`** in the SELECT so each row gets its own. (Fixed
+  2026-06-23; previously bit every client where both roles exist.)
+- **Secrets in output.** The generated `Apis` rows contain real `secret` values. **Never commit**
+  the client-insert file (or any artifact containing it) to a repo — run it in prod and distribute
+  the secret out-of-band. Core inserts are secret-free and safe to commit.
 - The cluster/endpoint map is environment infrastructure encoded as constants — if RDS endpoints
-  change, this script must be updated.
-- Identifiers have strict casing rules (formal vs PascalCase vs lowercase-subdomain); getting
-  them wrong produces inconsistent DB/identity records.
+  change, update the script.
+- Identifiers have strict casing rules (formal vs PascalCase vs lowercase-subdomain).
 - Output is SQL to run manually — review before executing against production.
 
 ## Change history
 
+- 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
+  cluster split and the secret-handling rule. (mhammontree)
 - 2026-06-16 — Initial capture.

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

@@ -4,5 +4,6 @@
 |-----|---------|-------|
 | [API (api2 / TOGa API v2) Architecture](architecture.md) | `api2` is the backend powering the public **TOGa 2.0 API**. | api2/Controller/Index.php, api2/Component/Api/V2/V2.php, api2/Component/Api/Cxml/Cxml.php, api2/Component/Api/V2/Response/Response.php, api2/Config/ |
 | [POST + JSON-body args for scripted APIs](features/scripted-api-post-body-args.md) | The V2 engine can run a Record Script (scripted API) for a **POST** request, and a scripted API can receive its arguments from the **JSON request body** instead | api2/Component/Api/V2/V2.php |
+| [Tickets API (/v2/tickets)](features/tickets-api.md) | The generic ticket endpoint of the 2.0 REST API. | Component/Api/V2/V2.php |
 | [AWS CodePipeline Deployment via CodeConnections (GitHub → Elastic Beanstalk)](workflows/codepipeline-codeconnections-deploy.md) | 2.0 apps (`api2`, `_underscore`) are deployed through **AWS CodePipeline**. |  |
 | [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 |

package/knowledge/2.0/apps/api2/features/tickets-api.md

@@ -0,0 +1,72 @@
+---
+title: Tickets API (/v2/tickets)
+framework: "2.0"
+repo: api2
+project: API
+client: shared
+type: feature
+status: active
+updated: 2026-06-23
+owners: ["mhammontree"]
+files:
+  - Component/Api/V2/V2.php
+related:
+  - ../architecture.md
+  - ../../dbchanges2/workflows/client-onboarding.md
+---
+
+## Summary
+
+The generic ticket endpoint of the 2.0 REST API. Tickets are a metadata-driven **Record**
+(`tickets` → `_Model_Client_Ticket`, `aclDatabase = CLIENT`), so they're created/updated/read like
+any record: `POST/PUT/GET /v2/tickets` (and `/v2/tickets/{uuid}`). PC Matic instead uses
+`/v2/entitlement-tickets` (entitlement-wrapped); plain clients (e.g. Fordham) use `/v2/tickets`
+with ticket fields at the top level.
+
+## Auth & request conventions
+
+- **Base URL** `https://api.togahub.com/v2` (sandbox `https://api.client.sandbox.togahub.com/v2`).
+- **Auth**: `POST /v2/auth/api {client, api, secret}` → `data.tokens.access` (Bearer, ~1h) +
+  `data.tokens.refresh` (~30d). `client` = `Core.Clients.uuid`, `api`/`secret` = the client's
+  `Client_<Id>.Apis` row. Refresh via `POST /v2/auth/refresh` with the refresh token as Bearer.
+- Every request needs a **unique `transactionId`** query param (reuse → `EV-5`).
+- Response envelope: `{transactionId, isSuccess, status, error, messages[], meta{}, data{}}`. A
+  created/read ticket comes back under **`data.tickets`** (not bare `data`).
+
+## How it works (write model)
+
+- **Related objects are nested and resolved by a natural identifier**, not numeric IDs — and **each
+  field has its own identifier set**:
+  - `urgency` → `name` / `weight` / `uuid` (**NOT `code`**)
+  - `ticketStage` → `code`
+  - `ticketType`, `ticketTopic` → `name`
+  Sending an identifier a field doesn't recognize returns **`EV-12`** (the error lists the valid
+  identifier fields). These are **MATCH** (must-exist) references — the value must already exist in
+  the client's reference data.
+- **Inline-created** objects (safe to send without pre-existing data): `address` (CREATE),
+  `contact`/`contactPhoneNumber`/`location`/`reportedByContact` (MATCH_UPSERT).
+- **Child arrays** created inline: `ticketNotes[]`, `ticketFiles[]`, `ticketUnits[]`, `ticketItems[]`,
+  `ticketUsers[]`, `ticketServiceQuestionAnswers[]`.
+- Add a note to an existing ticket via the nested route `POST /v2/tickets/{uuid}/ticket-notes`.
+- `number` is auto-generated (`TK`-prefixed, starts `TK100000`).
+
+A minimal create needs only `shortDescription`/`longDescription` (+ optional `impact`, `ticketNotes`);
+the FK references are all nullable.
+
+## GET / filtering
+
+`GET /v2/tickets` supports `fields`, `where`, `join`/`ojoin`, `sort`, `group`, pagination
+(`page`/`recordsPerPage`), `depth`. To fetch tickets for a contact on the generic flow, join the
+ticket's own contact: `join=Contacts@Contacts:Contacts.id=Tickets.contactId&where=(Contacts.uuid:eq:<uuid>)`.
+(PC Matic instead joins through Entitlements — only valid for its entitlement flow.)
+
+## Gotchas
+
+- **`urgency` matches by `name`, not `code`** — the most common `EV-12` cause.
+- **Reference data must exist** — a newly onboarded client has no Urgencies/TicketTypes/TicketStages/
+  TicketTopics until seeded, so those fields can't be referenced yet (see the onboarding workflow).
+- **Response is under `data.tickets`** — not bare `data`.
+
+## Change history
+
+- 2026-06-23 — Initial capture from the Fordham ticket integration + customer docs (TRUE-79699). (mhammontree)

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

@@ -3,3 +3,4 @@
 | Doc | Summary | Files |
 |-----|---------|-------|
 | [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/ |
+| [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/ |

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

@@ -6,7 +6,7 @@ project: Database Changes
 client: shared
 type: architecture
 status: active
-updated: 2026-06-19
+updated: 2026-06-23
 owners: [jcardinal, mhammontree]
 files:
   - Core/
@@ -36,7 +36,9 @@ is the intended execution order.
 **Critical rules:** every new `.sql` file **must** be named `YYYY-MM-DD<letter> - <Description>.sql`
 with a **mandatory lower-case letter** right after the date (`a` for the first file of that day
 in a folder, then `b`, `c`, …). One folder per database; place client changes under the matching
-`Client_<Name>` folder. Never edit an already-run migration — add a new dated file instead.
+`Client_<Name>` folder. Never edit an already-run migration — add a new dated file instead. The
+`Client/` **blank must carry the baseline DATA seed** (roles, full ACL, reference/lookup tables,
+UI config) — **not just schema**; a schema-only blank produces non-functional clients.
 
 ## File naming convention (the execution contract)
 
@@ -124,6 +126,31 @@ already-applied change files moved aside to keep the live list short. Present un
 typically bucketed as `FILES BEFORE <date>` (or by year under `Core/`). **Never** rely on a
 file inside `HISTORIC` running; **never** add new changes there.
 
+## The Client blank: baseline data + consolidation
+
+`Client/<DATE>-BLANK_CLIENT_DATABASE.sql` (the **latest-dated** one is the current blank) is the
+starting point for every new tenant. It is **not schema-only** — it must also carry the **baseline
+data seed**: the standard roles (`Base`, `Developer`, `API`, `Public`), the full ACL
+(`AclRecordPermissions`/`AclFieldPermissions`/`AclRecordExpressions`/`AclLogicGroups`/…), the
+reference/lookup tables (countries, states, statuses, types, …), and UI config (`TableViews` + fields,
+`SectionRecordFields`). A client built from a **schema-only** blank has no roles/ACL and **cannot
+authorize** — this regressed once (the blank was reduced to `EmailTemplates`-only), which is why a new
+client appeared to onboard but failed at the API.
+
+**Consolidation lifecycle** (folding loose `Client/` changes back into a fresh blank):
+1. The loose `Client/` files must **already be applied to every existing client DB** before they're
+   archived (otherwise the new blank diverges from live clients). This is done manually as the files
+   are created.
+2. Rebuild the blank from the **current clean schema + the baseline data** and `mysqldump` **WITH
+   data** (never `--no-data` — that is exactly how the seed was lost). Keep secret-bearing tables
+   (`Apis`) **out** of the blank.
+3. `git mv` the old blank + the consolidated loose files into `Client/HISTORIC/FILES BEFORE <DATE>/`,
+   leaving `Client/` with only the new dated blank.
+
+**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.)
+
 ## Adding a new change (the rules)
 
 1. Pick the right folder for the target DB: `Core/`, `Logs/`, the shared `Client/` (every

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

@@ -0,0 +1,97 @@
+---
+title: 2.0 New-Client Onboarding (manual process)
+framework: "2.0"
+repo: dbchanges2
+project: Database Changes
+client: shared
+type: workflow
+status: active
+updated: 2026-06-23
+owners: ["mhammontree"]
+files:
+  - Client/
+  - Client_<Tenant>/
+  - Core/
+  - Logs_Client/
+related:
+  - ../architecture.md
+  - ../../../1.0/apps/test/features/toga2-client-onboarding-sql.md
+  - ../../api2/features/tickets-api.md
+---
+
+## Summary
+
+How to manually stand up a new 2.0 client (tenant). A tenant spans three databases on three
+clusters — `Client_<Name>` (client cluster), `Logs_<Name>` (logs cluster), `Archive_<Name>`
+(archive cluster) — plus registration rows in **Core** and two API keys. The schema + baseline
+data come from the dbchanges2 **blank**; the Core/client registration + API keys are generated by
+the [onboarding SQL generator](../../../1.0/apps/test/features/toga2-client-onboarding-sql.md).
+Goal: every `Client_<Name>` DB is architecturally identical.
+
+## Steps
+
+Order matters — each step assumes the prior one ran.
+
+1. **Decide identifiers** — formal name, identifier (PascalCase → `Client_<Id>`), subdomain
+   (lowercase), email domain(s) with TLD, and any modules.
+2. **Create the three databases** — `CREATE DATABASE Client_<Id>` (client cluster),
+   `Logs_<Id>` (logs cluster), `Archive_<Id>` (archive cluster). `Archive_<Id>` can be empty.
+3. **Build `Client_<Id>` schema + baseline** — apply the current blank
+   (`Client/<DATE>-BLANK_CLIENT_DATABASE.sql` — latest-dated), which creates all tables **and** the
+   baseline seed (roles, full ACL, reference/lookup tables, UI config). Run with
+   `SET FOREIGN_KEY_CHECKS=0` (the loose schema files assume it; see Gotchas).
+4. **Build `Logs_<Id>`** — apply `Logs_Client/<DATE>_BLANK_CLIENT_LOGS_DATABASE.SQL`. The API logs
+   here and checks the auth-rate limit against it, so it **must** exist for the API to work.
+5. **Generate the inserts** — run `test/team/generate_toga2_onboarding_sql.php` (set the client
+   consts). It emits Core inserts + the two API-key inserts.
+6. **Run Core inserts on the core cluster** — `Core.Databases`, `Core.Clients`, `Core.Domains`
+   (every app × env), `Core.ClientEmailDomains`, `Core.DatabaseHosts`. This is what makes the API
+   route to the tenant.
+7. **Run the API-key inserts on the client cluster** (against `Client_<Id>`) — two `Apis` rows
+   (internal "Agilant" + the client key) and their `Apis_Roles` links to `Base`+`API`. Distribute
+   the secrets out-of-band (internal → our systems; client → the client). **Never commit secrets.**
+8. **Register for shared changes** — append `Client_<Id>` to `test/team/2.0 deployment/Clients_Db.txt`
+   so future shared `Client/` changes fan out to it.
+9. **Configure client reference/ACL data** — seed the client's ticket reference data
+   (Urgencies, TicketTypes, TicketStages, TicketTopics) and any record/field ACL beyond baseline.
+10. **Verify** — authenticate via the API with `{client = Core.Clients.uuid, api = Apis.uuid,
+    secret = Apis.secret}`, then a smoke request (e.g. create a ticket).
+
+## Systems involved
+
+- **dbchanges2** — the blank (schema + baseline seed), loose `Client/` changes, `Logs_Client/`
+  blank, and the generated `Core/` + `Client_<Name>/` onboarding SQL.
+- **test** (1.0) — `generate_toga2_onboarding_sql.php` produces the Core + API-key inserts.
+- **Core DB** — `Clients`, `Databases`, `DatabaseHosts`, `Domains`, `ClientEmailDomains`
+  (route/identity metadata; supplies the `client` uuid used at auth).
+- **api2 / _underscore** — the API the client calls; verify here.
+- **Bastion** — production deploy path (upload SQL, source per cluster).
+
+## Edge cases & escalation
+
+- **Logs/Archive scope** — building the `Logs_`/`Archive_` *schemas* is sometimes treated as a
+  later phase, but `Logs_<Id>` is required for the API to authenticate/log. Their **Core
+  registration** rows (Databases/DatabaseHosts) are always generated regardless.
+- **Reference data** — a fresh client has roles/ACL/lookups from the blank, but **not** ticket
+  reference data (Urgencies/TicketTypes/TicketStages/TicketTopics). Until seeded, ticket creates
+  that reference them return `EV-12`.
+- **Drift before consolidation** — loose `Client/` files must already be applied to all existing
+  clients before they're consolidated/archived (otherwise the new blank diverges from live
+  clients). See the dbchanges2 architecture doc.
+
+## Gotchas
+
+- **`FOREIGN_KEY_CHECKS=0`** is required when applying the loose schema files — several
+  `ALTER … MODIFY/DROP` a column that's in an FK and fail with error 1832 otherwise.
+- **`Apis` rows are in the CLIENT database**, not Core. Core only holds `Clients`/`ClientEmailDomains`
+  /`ClientApiIdentities`. Auth needs three values: `client` = `Core.Clients.uuid`, `api` =
+  `Client_<Id>.Apis.uuid`, `secret` = `Client_<Id>.Apis.secret`.
+- **`Apis_Roles` needs `Base`+`API` to pre-exist** in `Client_<Id>` — they come from the blank
+  seed. If the blank lacks roles, the role links insert zero rows and the key can't authorize.
+- **Never commit secrets** — the generated `Apis` secrets go in a non-committed artifact; the Core
+  inserts are secret-free and committable.
+- **Domain URLs** — dev uses `http://<sub>.togaX` (no TLD); beta/prod use `https://…<env>.togaX.com`.
+
+## Change history
+
+- 2026-06-23 — Initial capture from the Fordham onboarding (TRUE-79702). (mhammontree)

package/knowledge/INDEX.md

@@ -17,8 +17,8 @@ _Auto-generated by `knowledge.js index`. Do not hand-edit._
 
 - **_underscore** (_Underscore) _(framework core)_ — 11 doc(s) → [2.0/apps/_underscore/INDEX.md](2.0/apps/_underscore/INDEX.md)
 - **worker2** (Worker) — 11 doc(s) → [2.0/apps/worker2/INDEX.md](2.0/apps/worker2/INDEX.md)
-- **api2** (API) — 4 doc(s) → [2.0/apps/api2/INDEX.md](2.0/apps/api2/INDEX.md)
-- **dbchanges2** (Database Changes) _(framework core)_ — 1 doc(s) → [2.0/apps/dbchanges2/INDEX.md](2.0/apps/dbchanges2/INDEX.md)
+- **api2** (API) — 5 doc(s) → [2.0/apps/api2/INDEX.md](2.0/apps/api2/INDEX.md)
+- **dbchanges2** (Database Changes) _(framework core)_ — 2 doc(s) → [2.0/apps/dbchanges2/INDEX.md](2.0/apps/dbchanges2/INDEX.md)
 - **toga2-supply** (TOGa Supply) — 3 doc(s) → [2.0/apps/toga2-supply/INDEX.md](2.0/apps/toga2-supply/INDEX.md)
 - **saml** (SAML SSO Gateway) — 2 doc(s) → [2.0/apps/saml/INDEX.md](2.0/apps/saml/INDEX.md)
 - **toga2-view** (TOGa View Frontend) — 1 doc(s) → [2.0/apps/toga2-view/INDEX.md](2.0/apps/toga2-view/INDEX.md)
@@ -41,6 +41,7 @@ _Auto-generated by `knowledge.js index`. Do not hand-edit._
 - **Compass Canada** (`compass-canada`) → [clients/compass-canada/INDEX.md](clients/compass-canada/INDEX.md)
 - **Compass USA** (`compass-usa`) → [clients/compass-usa/INDEX.md](clients/compass-usa/INDEX.md)
 - **Elite** (`elite`) → [clients/elite/INDEX.md](clients/elite/INDEX.md)
+- **Fordham University** (`fordham`) → [clients/fordham/INDEX.md](clients/fordham/INDEX.md)
 - **GroWrk** (`growrk`) → [clients/growrk/INDEX.md](clients/growrk/INDEX.md)
 - **New York City Department of Education** (`nycdoe`) → [clients/nycdoe/INDEX.md](clients/nycdoe/INDEX.md)
 - **NYC Health & Hospitals** (`nychh`) → [clients/nychh/INDEX.md](clients/nychh/INDEX.md)

package/knowledge/clients/fordham/INDEX.md

@@ -0,0 +1,5 @@
+# Client: Fordham University `fordham`
+
+| Doc | Framework | Summary | Files |
+|-----|-----------|---------|-------|
+| [Fordham University](profile.md) | 2.0 | Fordham University (`fordham.edu`), `clientIdentifier` **Fordham**, onboarded onto the 2.0 platform in June 2026 (TRUE-79702). |  |

package/knowledge/clients/fordham/profile.md

@@ -0,0 +1,49 @@
+---
+title: "Fordham University"
+framework: "2.0"
+apps:
+  - _underscore
+  - api2
+  - dbchanges2
+project: API
+client: fordham
+type: profile
+status: active
+updated: 2026-06-23
+owners: ["mhammontree"]
+files: []
+related:
+  - ../../2.0/apps/api2/features/tickets-api.md
+  - ../../2.0/apps/dbchanges2/workflows/client-onboarding.md
+---
+
+## Summary
+
+Fordham University (`fordham.edu`), `clientIdentifier` **Fordham**, onboarded onto the 2.0 platform
+in June 2026 (TRUE-79702). Their integration uses the **TOGa 2.0 ticket API** (`/v2/tickets`) — they
+create/update/read support tickets in our system via REST. Tickets are the **generic** flow (not
+entitlement-based like PC Matic): the request body is ticket fields at the top level.
+
+## Onboarding
+
+Provisioned via the standard [2.0 client onboarding process](../../2.0/apps/dbchanges2/workflows/client-onboarding.md):
+`Client_Fordham` / `Logs_Fordham` / `Archive_Fordham`, Core registration, and two API keys
+(internal "Agilant" + the "Fordham" client key). The committed dbchanges2 artifacts are
+`Client/<DATE>-BLANK_CLIENT_DATABASE.sql` (seeded blank) and `Core/<DATE>-onboard_Fordham.sql`
+(Core inserts); the API-key inserts (with secrets) are kept out of the repo.
+
+## Integration / API
+
+- Uses **generic `/v2/tickets`** (POST/PUT/GET) — see [tickets-api](../../2.0/apps/api2/features/tickets-api.md).
+- Customer-facing docs delivered (TRUE-79699): a Markdown guide + a Postman collection in PC-Matic
+  style (globals for `{{url}}`/`{{accessToken}}`, hardcoded creds in the auth body).
+
+## Known gaps
+
+- **Ticket reference data not yet seeded** — `Urgencies`, `TicketTypes`, `TicketStages`,
+  `TicketTopics` are empty for Fordham, so ticket creates can only set descriptions/notes until those
+  are configured; referencing them returns `EV-12`.
+
+## Change history
+
+- 2026-06-23 — Initial onboarding + ticket API integration. (mhammontree)

package/package.json

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