toga-ai 1.0.76 → 1.0.78

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

@@ -4,7 +4,7 @@
 |-----|---------|-------|
 | [TOGa Desk Architecture](architecture.md) | TOGa Desk is the staff-facing support desk **and field-service platform** (analysts work at `/desk/`). | desk/index.php, desk/includes/loader.php, desk/config.php, desk/includes/controllers/actions.php, desk/includes/controllers/data.php, desk/includes/controllers/modals.php, desk/includes/classes/class.app.php, desk/includes/classes/class.ticket.php, desk/api/index.php, desk/api/resources/tickets.php, crons/tickets.php |
 | [Email-to-Ticket Intake (crons/tickets.php)](features/email-to-ticket-intake.md) | TOGa Desk ingests support email into tickets through a cron-driven IMAP poller (`crons/tickets.php`) plus a postfix pipe variant (`crons/pipe.php`). | crons/tickets.php, crons/tickets_prod.php, crons/pipe.php, desk/includes/classes/class.ticket.php |
-| [Field-Service Dispatch (central / repair orders)](features/field-service-dispatch.md) | The **central** subsystem is TOGa Desk's field-service dispatch domain: repair-order lifecycle, technician scheduling, onsite vs depot service, parts, and shipm | desk/includes/controllers/actions/central/, desk/includes/classes/class.repair.php, desk/includes/classes/class.repairhistory.php, desk/_/browser/datatable/central.php, desk/template/pages/central.php, desk/template/pages/central/view.php |
+| [Field-Service Dispatch (central / repair orders)](features/field-service-dispatch.md) | The **central** subsystem is TOGa Desk's field-service dispatch domain: repair-order lifecycle, technician scheduling, onsite vs depot service, parts, and shipm | desk/includes/controllers/actions/central/, desk/includes/classes/class.repair.php, desk/includes/classes/class.repairhistory.php, desk/_/browser/datatable/central.php, desk/template/pages/central.php, desk/template/pages/central/view.php, desk/template/modals/central/addTracking.php, library/app/model/togadesk/repairordertracking.php, library/app/api/carrier/ups.php |
 | [REST API (RPC-over-POST) & API-Key Auth](features/rest-api.md) | TOGa Desk exposes a programmatic API at `desk/api/`. | desk/api/index.php, desk/api/resources/tickets.php, desk/api/resources/assets.php, desk/api/resources/authenticate.php, desk/includes/classes/class.apikey.php, desk/includes/functions.php |
 | [SMB Contract Editing & the clientMspId Corruption Trap](features/smb-contract-editing.md) | The SMB contracts page (`/desk/?route=toga/smbcontracts&togaClientId=<id>`) edits `TOGA_*.SMBContracts` rows via a modal. | desk/template/modals/toga/smbcontracts/smbContract.php, desk/includes/controllers/modals/toga/smbcontracts/smbContract.php, desk/includes/controllers/actions/toga/smbcontracts/smbContract.php, desk/includes/controllers/actions/toga/smbcontracts/edit.php |
 | [Ticket Lifecycle (class.ticket.php)](features/ticket-lifecycle.md) | All TOGa Desk ticket creation and reply handling funnels through `Ticket` in `desk/includes/classes/class.ticket.php`. | desk/includes/classes/class.ticket.php, desk/includes/controllers/actions.php, desk/api/resources/tickets.php, crons/tickets.php, desk/includes/controllers/actions/tickets/merge.php |

package/knowledge/1.0/apps/togadesk/features/field-service-dispatch.md

@@ -7,7 +7,7 @@ client: shared
 type: feature
 status: active
 updated: 2026-06-15
-owners: ["jcardinal"]
+owners: ["jcardinal", "mhammontree"]
 files:
   - desk/includes/controllers/actions/central/
   - desk/includes/classes/class.repair.php
@@ -15,6 +15,9 @@ files:
   - desk/_/browser/datatable/central.php
   - desk/template/pages/central.php
   - desk/template/pages/central/view.php
+  - desk/template/modals/central/addTracking.php
+  - library/app/model/togadesk/repairordertracking.php
+  - library/app/api/carrier/ups.php
 related:
   - 1.0/apps/togadesk/architecture.md
   - 1.0/apps/togadesk/features/ticket-lifecycle.md
@@ -53,6 +56,25 @@ the originating page. Status changes are audited through `RepairHistory` (`repai
 onsite/install started → review → closed; depot repairs add parts/tracking steps. Bulk actions
 exist for closing installs and editing onsite tickets.
 
+## UPS shipment / carrier-account billing (Prepare Shipment flow)
+The "PREPARE SHIPMENT" button opens modal `desk/template/modals/central/addTracking.php`,
+whose carrier/account dropdown is built from the constant
+`App_Model_TogaDesk_RepairOrderTracking::CARRIER_ACCOUNTS`
+(`library/app/model/togadesk/repairordertracking.php`) — a display⇒value list of multiple
+carrier accounts (Agilant `8696XA`, ODP Veyer `H4Y167`, Compass `33951W`, Advance Auto
+`2V1Y10`, Vision Precision `87161X`, plus FedEx accounts). Submit calls
+`Repair::addTracking($_POST)` (~L600 in `class.repair.php`), which builds an
+`App_Api_Carrier_ShipmentRequest` and calls `App_Api_Carrier_UPS::submitShipmentRequest()`.
+
+**The displayed account and the billed account come from different places.** The dropdown is
+just `CARRIER_ACCOUNTS`; the account that actually ships/bills is the hardcoded
+`const SHIPPER_NUMBER` in `library/app/api/carrier/ups.php`, injected into the UPS payload as
+*both* `Shipment.Shipper.ShipperNumber` and `BillShipper.AccountNumber`. `SHIPPER_NUMBER` is
+shared **library core** consumed by every 1.0 app (togadesk, togaview, worker); a separate
+synced copy lives in `_underscore` for 2.0 apps, plus a hardcoded `<ShipAccount>` in
+`library/app/api/essls.php`. Full account-location map:
+`C:\WWW\shipping_carrier_ups_account_location.md`.
+
 ## Data model
 `repair_orders`, `repair_order_customers`, `repair_order_addresses`, `repair_order_technicians`,
 `repair_history` (in `db_togadesk`), joined to TOGA `ServiceRequests` for managed-service-order
@@ -70,7 +92,21 @@ always confirm the client arm before changing shared central logic.
   an order in an inconsistent state.
 - Cross-database context: some central data controllers switch the DB link to a client database
   (`App_Model_Client::changeDbLinkToClientDatabase()`).
+- **UPS carrier-account dropdown is NOT honored by the shipment API call.** In
+  `Repair::addTracking()` the selected `carrierAccount` is only saved onto the tracking record
+  (`$track->carrierAccount = $data['carrierAccount']`, ~L932/949/966); it is never passed into
+  the `ShipmentRequest`. `submitShipmentRequest()` therefore always bills the hardcoded
+  `SHIPPER_NUMBER` (Agilant), so picking ODP Veyer / Compass / etc. has no billing effect. True
+  third-party billing would require passing the chosen account into the request via a UPS
+  `BillThirdParty` / `BillReceiver` payment block instead of `BillShipper`.
+- The Agilant UPS account is **hardcoded in core, not config/DB** — changing it means editing
+  `SHIPPER_NUMBER` in both framework cores (`library` and `_underscore`), the ESSLS
+  `<ShipAccount>` XML, the `CARRIER_ACCOUNTS` Agilant entry, and test fallbacks. See the
+  account-location map noted under *UPS shipment / carrier-account billing*.
 
 ## Change history
+- 2026-06-15 — documented UPS Prepare Shipment flow: CARRIER_ACCOUNTS dropdown vs hardcoded
+  SHIPPER_NUMBER, and the gotcha that the dropdown selection is never forwarded to the UPS API
+  (always bills Agilant). Agilant account migrated 135FV5 → 8696XA. (mhammontree)
 - 2026-06-15 — documented from a source read of `controllers/actions/central/` and
   `class.repair.php` (jcardinal)

package/knowledge/2.0/apps/toga2-hub/INDEX.md

@@ -0,0 +1,6 @@
+# toga2-hub (TOGA Hub) — 2.0 knowledge
+
+| Doc | Summary | Files |
+|-----|---------|-------|
+| [TOGA Hub Architecture](architecture.md) | toga2-hub (TOGA Hub) is a React + TypeScript single-page admin portal for the TOGA platform. | toga2-hub/src/main.tsx, toga2-hub/src/routes.tsx, toga2-hub/src/App.tsx, toga2-hub/src/api/axiosInstance.ts, toga2-hub/src/api/apiFunctions.ts, toga2-hub/src/utils/queryHelpers.ts, toga2-hub/src/contexts/AuthContext.tsx, toga2-hub/src/stores/useUserStore.ts |
+| [ACL Record Permissions — Rendering Semantics (Permissions Page)](features/acl-permissions-rendering.md) | How the TOGA Hub Permissions page must interpret the api2 endpoint `GET /v2/acl-record-permissions/getAclRecordPermissionsByRecordAndRole` and turn its response | toga2-hub/src/pages/Permissions/api/permissionsApi.ts, toga2-hub/src/pages/Permissions/utils/permissionsUtils.ts, toga2-hub/src/pages/Permissions/viewModel/useRolesViewModel.ts, toga2-hub/src/hooks/useAclPermissionsByRoleQuery.ts, toga2-hub/src/pages/Permissions/view/RolesView/RoleDetailView/LogicGroupView.tsx, toga2-hub/src/pages/Permissions/view/RecordsView/RecordDetailView/RecordDetailView.tsx, toga2-hub/src/hooks/useQueryData.ts |

package/knowledge/2.0/apps/toga2-hub/architecture.md

@@ -0,0 +1,156 @@
+---
+title: TOGA Hub Architecture
+framework: "2.0"
+repo: toga2-hub
+project: TOGA Hub
+client: shared
+type: architecture
+status: active
+updated: 2026-06-15
+owners: [tcox]
+files:
+  - toga2-hub/src/main.tsx
+  - toga2-hub/src/routes.tsx
+  - toga2-hub/src/App.tsx
+  - toga2-hub/src/api/axiosInstance.ts
+  - toga2-hub/src/api/apiFunctions.ts
+  - toga2-hub/src/utils/queryHelpers.ts
+  - toga2-hub/src/contexts/AuthContext.tsx
+  - toga2-hub/src/stores/useUserStore.ts
+related:
+  - 2.0/apps/toga2-hub/features/acl-permissions-rendering.md
+---
+
+## Summary
+
+toga2-hub (TOGA Hub) is a React + TypeScript single-page admin portal for the TOGA
+platform. It is a pure frontend client — all business logic and persistence live in the
+`api2` backend (framework 2.0), which Hub talks to exclusively over REST. The portal is
+multi-tenant: it selects both its API endpoint and theme from the hostname it is served
+from (e.g. `toga2-hub`, `compass.togahub`).
+
+Primary surfaces: **Login** (auth), **Permissions** (manage roles, records, and ACL
+field permissions), and **Users** (user management). The Permissions surface is the most
+involved; its rendering rules are documented separately in
+[ACL Record Permissions — Rendering Semantics](features/acl-permissions-rendering.md).
+
+## Stack
+
+- React 18.3 + TypeScript 5.9, built with **Vite 5.4** (no Webpack).
+- `@tanstack/react-query` 5.90 — server state, fetching, mutations.
+- `zustand` 4.5 with `persist` — lightweight client state.
+- `react-router-dom` — routing. `react-hook-form` 7.72 — forms.
+- `axios` — HTTP client.
+- `@agilant/toga-blox` — shared Agilant UI library (provides `EnvironmentBadge`,
+  `performLogout`, shared components).
+- Tailwind CSS 3.4 (large custom palette: `hub-primary-*`, `supply-blue-*`, `navy-*`,
+  `crimson-*` — prefer these over stock Tailwind) + SCSS via `sass-embedded`.
+- Cypress 15.5 for E2E. No unit-test runner is configured (despite `@types/jest`).
+
+## API layer (how it talks to api2)
+
+Entry points: `src/api/axiosInstance.ts` (instance + interceptors), `src/api/apiFunctions.ts`
+(`apiGet / apiPost / apiPut / apiDelete<T>(route, [data], options, params)`).
+
+**Base-URL resolution is hostname-aware.** axiosInstance reads `window.location.hostname`,
+uppercases the first segment, and looks up `VITE_API_<SEGMENT>` (e.g. host
+`compass.togahub` → `VITE_API_COMPASS`), falling back to `VITE_API`. A new tenant hostname
+needs a matching `VITE_API_*` env var.
+
+**Auth tokens** (localStorage keys `accessToken`, `refreshToken`, `user`):
+- No user yet → `POST /auth/public` obtains a public token.
+- Logged in → uses the access token from login.
+- On `401` → `POST /auth/refresh`; retry the original request. If refresh fails,
+  `performLogout()` (from toga-blox) runs.
+
+**Interceptors**: every request receives a UUID `transactionId` query param (tracing) and
+an `Authorization: Bearer <token>` header.
+
+**Query language**: api2 uses a structured query object (`fields`, `join`, `ojoin`,
+`where`, `sort`) serialized to a query string by `src/utils/queryHelpers.ts`
+(`assembleOptions`). This is **not GraphQL**. Every read goes through it, so learn it early.
+The `fields` parameter is an allowlist enforced by api2 (EV-8 validation in api2 `V2.php`):
+a field not in the record's allowlist silently won't return, and a single prohibited field
+can fail the whole fetch (see the ACL feature doc for the `Roles.id` / `EZ-2` example).
+Casing must match exactly what api2 expects.
+
+## State management
+
+- **AuthContext** (`src/contexts/AuthContext.tsx`) — `isAuthenticated`, `user`, `login()`,
+  `logout()`, `setUser()`, `isAuthInitialized`; syncs localStorage and listens for cross-tab
+  `storage` events.
+- **Zustand** `useUserStore` (`src/stores/useUserStore.ts`) — persisted under key `zu-user`;
+  holds the user alongside AuthContext.
+- **React Query** — configured in `main.tsx` with `retry: false`,
+  `refetchOnWindowFocus: false`.
+- No Redux. Logout clears `accessToken`, `refreshToken`, `user`, and the `zu-user` store. If
+  logout cleanup ever grows, centralize the wipe rather than maintaining per-key lists
+  (per-key lists drift — a lesson learned the hard way in sibling repo toga2-commerce).
+
+## Routing & layout
+
+- `src/main.tsx` — bootstraps the render tree: `QueryClientProvider` → `AuthProvider` →
+  `RouterProvider`.
+- `src/routes.tsx` — routes: `/login` (unauthenticated), `/permissions`, `/users`; root `/`
+  redirects to `/permissions?tab=roles`. Permissions carries UI state in query params
+  (`?tab=roles|records&roleUuid=…&recordId=…`).
+- `src/App.tsx` — authenticated layout: `AppHeader`, `EnvironmentBadge` (shows BETA/GAMMA/…),
+  `VerticalNavBar`, and the route `Outlet`.
+
+## Critical flows
+
+- **Login** — `pages/Login/LoginPage.tsx` → `pages/Login/api/LoginApi.tsx`
+  (`validateEmailDomain`, `useSubmitLoginPassword`) → `viewModel/useLoginPageViewModel.ts`.
+  Flow: enter email → local validate → `validateEmailDomain` (`/domains`) →
+  `POST /auth/login` → store tokens + user → navigate to `/`. Login copy is data-driven from
+  `LOGINFIELDS.json` (edit the JSON, not the component).
+- **Permissions** — `pages/Permissions/view/PermissionsPage.tsx` tabs into `RolesView/` and
+  `RecordsView/`. Rendering rules in the ACL feature doc.
+- **Users** — `pages/Users/view/UsersPage.tsx` → `UsersView/`, `UserDetailView/`.
+
+## Build, environments & deploy
+
+Scripts (`package.json`): `npm run dev`; `npm run togahub` / `npm run compass` (dev on a
+specific hostname); `npm run build` = `tsc -b && vite build` (type-checks then bundles to
+`dist/`); `npm run lint`; `npm run cypress`.
+
+Environment config via `.env.<mode>` files; only `VITE_`-prefixed vars reach the client.
+
+| Env | API base URL |
+|---|---|
+| production | `https://api.togahub.com/v2` |
+| beta | `https://api.beta.togahub.com/v2` |
+| alpha/gamma | `https://api.gamma.togahub.com/v2` |
+| development | beta API by default |
+
+> **Dev points at the BETA API by default.** When debugging data, confirm whether you're
+> looking at beta or prod — beta and prod also differ in DB schema naming (the Core DB with
+> RecordFields/ACL lives in a separate `prod-core` cluster; beta tenant schemas are named
+> `Client`, prod tenant schemas `Client_<Tenant>`).
+
+Hosting: Elastic Beanstalk (Agilant standard; use `/create-elastic-beanstalk` for new envs).
+Served as a static SPA build; no custom `.ebextensions` in-repo.
+
+## Where to start (read in order)
+
+1. `src/main.tsx` — render tree, React Query + Auth providers.
+2. `src/routes.tsx` — routes.
+3. `src/App.tsx` — layout.
+4. `src/api/axiosInstance.ts` — hostname-aware base URL + auth tokens.
+5. `src/api/apiFunctions.ts` + `src/utils/queryHelpers.ts` — the api2 query language.
+6. `src/contexts/AuthContext.tsx` — session state.
+7. `src/pages/Permissions/view/PermissionsPage.tsx` — main surface (+ the ACL feature doc).
+8. `tailwind.config.js` — design tokens.
+
+## Open questions (unverified — confirm before relying on)
+
+- axiosInstance has a deliberate ~1ms pre-request delay whose purpose is undocumented —
+  understand before removing.
+- Possible query-param name inconsistency in the Permissions Records detail
+  (`recordUuid` written vs `recordId` read) — verify when next touching that path.
+- `src/dummyData/*.json` mocks exist; some surfaces (e.g. the Records-tab permissions list)
+  may still render mock data — confirm a component hits the live API before debugging data.
+
+## Related docs
+
+- [ACL Record Permissions — Rendering Semantics](features/acl-permissions-rendering.md)

package/knowledge/2.0/apps/toga2-hub/features/acl-permissions-rendering.md

@@ -0,0 +1,111 @@
+---
+title: ACL Record Permissions — Rendering Semantics (Permissions Page)
+framework: "2.0"
+repo: toga2-hub
+project: TOGA Hub
+client: shared
+type: feature
+status: active
+updated: 2026-06-10
+owners: [tcox]
+files:
+  - toga2-hub/src/pages/Permissions/api/permissionsApi.ts
+  - toga2-hub/src/pages/Permissions/utils/permissionsUtils.ts
+  - toga2-hub/src/pages/Permissions/viewModel/useRolesViewModel.ts
+  - toga2-hub/src/hooks/useAclPermissionsByRoleQuery.ts
+  - toga2-hub/src/pages/Permissions/view/RolesView/RoleDetailView/LogicGroupView.tsx
+  - toga2-hub/src/pages/Permissions/view/RecordsView/RecordDetailView/RecordDetailView.tsx
+  - toga2-hub/src/hooks/useQueryData.ts
+related: []
+---
+
+## Summary
+
+How the TOGA Hub Permissions page must interpret the api2 endpoint
+`GET /v2/acl-record-permissions/getAclRecordPermissionsByRecordAndRole` and turn its
+response into the green-check / red-X permissions grid. Semantics confirmed in a design
+review with jcardinal (Naperville, 2026-06-09); an earlier implementation over-thought
+the rules and had to be corrected back to the simple reading below.
+
+## Endpoint usage
+
+- `?recordId=N` (no roleId) → returns logic groups for **every role** on that record.
+  This feeds the **Roles tab record detail** (pick a role, then click a record): every
+  element of the response renders as its own table, labeled by role — the role
+  selection does NOT filter the tables ("that's useful for this rendering of this
+  page" — the unscoped call, per the 2026-06-09 review).
+- The **Records tab** record detail does NOT render these tables — its permissions tab
+  is an app-sectioned permissions list (dummy data as of 2026-06-10, real data TBD).
+- `?recordId=N&roleId=M` → returns only that role's logic groups. Supported by the API
+  for role-scoped use cases, but not currently used by the Hub UI.
+- `recordId`/`roleId` are the numeric backend PKs, not UUIDs.
+- **Gotcha:** `Roles.id` is not field-ACL-readable for hub users — requesting it on
+  `GET /roles` returns `EZ-2` 403 (`fields: ["id"]`, route `roles`, `aclDatabase:
+  CLIENT`), and a single prohibited field fails the whole fetch. Don't request `id` on
+  `/roles`. Suspect the same for `Apps.id` (needed for the appId → column mapping on
+  `/apps`) — if app-specific permissions render all-red, check the `/apps` response
+  first. Backend grant requests pending with jcardinal.
+
+## Response shape
+
+`data.aclRecordPermissions.getAclRecordPermissionsByRecordAndRole` is an array of
+`{ logicGroup, roles[] }`:
+
+- `logicGroup` — the condition tree shown above the grid. `logicGroupExpressions` items
+  are `type: "EXPRESSION"` (leaf, with `recordExpression.description` as display label)
+  or `type: "GROUP"` (nested group with its own `operator` + expressions). A logic group
+  with `uuid: null` and no expressions means "no conditions" (e.g. the Public role).
+- `roles[].permissions[]` — flat list of permission entries:
+  `{ uuid, appId, indirectRecordId, recordId, allowCreate, allowRead, allowUpdate, allowDelete }`.
+
+## Rendering rules (the part that was corrected)
+
+The grid has one column per app (Supply, Hub, View, …) and one row per CRUD action.
+Resolve a role's `permissions[]` array like this:
+
+1. **`appId: null` = ALL apps.** An entry with `appId: null` and all CRUD true means
+   green checks across the board, every column.
+2. **`appId: <id>` = that app's column only.** App id → column via `Apps.slug`
+   (`toga-supply` → supply column; app id 5 = Supply).
+3. **No `appId: null` entry present** → columns without an app-specific entry are all
+   false → **red X's**. E.g. a role whose only entry is `appId: 5` all-true renders
+   Supply fully green and every other column fully red.
+4. **Effective cell value = OR across all matching entries.** Redundant entries are
+   normal and harmless (e.g. `appId: null` all-true *plus* `appId: 5` all-true — the
+   second adds nothing). A role can also carry multiple `appId: null` entries; OR them
+   all in.
+5. Don't over-derive: the backend data is not normalized/human-curated yet (cleanup is
+   planned once Hub can visualize it). Render what the entries say, nothing more.
+6. **Every logic group is its own table under the record — never filter.** On the
+   Roles tab record detail, each element of the unscoped response renders as its own
+   conditions box + CRUD table, labeled with its role name. "Only one table shows" was
+   a recurring bug caused by client-side role filtering of the response — the original
+   build (multiple tables per record) was correct. Do not reintroduce a roleUuid filter
+   on the logic-group array.
+
+## indirectRecordId
+
+Entries with `indirectRecordId` set are indirect grants managed by the backend
+(observed: Compass Base role carries a direct `appId: null` entry and a second
+`appId: null, indirectRecordId: 2` entry). The Hub UI ORs them into the rendered grid
+but must **never POST/PUT/DELETE them** from the permissions save flow — only direct
+entries (`indirectRecordId: null`) are editable. Exact backend semantics still to be
+confirmed.
+
+## Save/cleanup conventions (Hub-side)
+
+- All columns fully checked → collapse to a single `appId: null` entry and delete
+  redundant app-specific entries.
+- Mixed state → delete any existing `appId: null` entry and write per-app entries.
+- All unchecked → delete every direct entry for that role/record.
+
+## Validating against the database
+
+Permissions live in Core DB table `AclRecordPermissions` (per-role CRUD), conditions in
+the logic-group/record-expression tables, field-level in `AclFieldPermissions` (see api2
+architecture doc). The API response is the source of truth for rendering; SQL is the
+fallback for verifying unexpected data.
+
+## Change history
+- 2026-06-15 — Added to the team knowledge base alongside the toga2-hub architecture doc. (tcox)
+- 2026-06-09 — Rendering/save semantics confirmed in design review (appId:null collapse, mixed-state per-app writes, Core DB validation path). (jcardinal)

package/knowledge/INDEX.md

@@ -18,6 +18,7 @@ _Auto-generated by `knowledge.js index`. Do not hand-edit._
 - **toga2-supply** (TOGa Supply) — 2 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) — 0 doc(s) → [2.0/apps/toga2-view/INDEX.md](2.0/apps/toga2-view/INDEX.md)
+- **toga2-hub** (TOGA Hub) — 2 doc(s) → [2.0/apps/toga2-hub/INDEX.md](2.0/apps/toga2-hub/INDEX.md)
 
 ## Clients
 

package/knowledge/registry.json

@@ -9,5 +9,7 @@
   { "repo": "saml",        "project": "SAML SSO Gateway", "framework": "2.0", "role": "app",  "dependsOn": [] },
   { "repo": "toga2-view",  "project": "TOGa View Frontend", "framework": "2.0", "role": "app",  "dependsOn": ["api2"] },
   { "repo": "togadesk",    "project": "TOGa Desk",   "framework": "1.0", "role": "app",  "dependsOn": [] },
-  { "repo": "togaview",    "project": "TOGa View",   "framework": "1.0", "role": "app",  "dependsOn": [] }
+  { "repo": "togaview",    "project": "TOGa View",   "framework": "1.0", "role": "app",  "dependsOn": [] },
+  { "repo": "toga2-hub",   "project": "TOGA Hub",    "framework": "2.0", "role": "app",  "dependsOn": ["api2"] }
+
 ]

package/package.json

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