toga-ai 1.0.77 → 1.0.79

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

@@ -4,5 +4,6 @@
 |-----|---------|-------|
 | [_underscore Framework Architecture](architecture.md) | `_underscore` is the shared PHP backend framework for **all 2.0 applications**. | _underscore/_underscore.php, _underscore/Loader.php, _underscore/Framework.php, _underscore/Model.php, _underscore/Database.php, _underscore/Query.php, _underscore/Route.php, _underscore/Component.php |
 | [Carrier Shipping Labels (UPS/FedEx) & NetSuite Item Fulfillment](features/carrier-shipping-labels.md) | Backend mechanics behind TOGa Supply's Fulfill & Ship: buying a carrier label (UPS/FedEx), persisting it, and creating the NetSuite Item Fulfillment with tracki | _underscore/Model/Client/ItemFulfillment.php, _underscore/Component/Library/Carriers/Ups/Ups.php, _underscore/Trait/Netsuite/ItemFulfillment.php, _underscore/Trait/Netsuite/SalesOrder.php, _underscore/Component/Library/NetSuite/NetSuite.php, _underscore/Model/Client/TrackingNumber.php, _underscore/Model/Client/ShippingMethod.php, _underscore/Model.php, _underscore/Cloud.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/Client/EmailTemplateOutgoingEmailAddress.php, _underscore/Email.php |
 | [Recursive Item Fulfillments (upstream mirroring)](features/recursive-item-fulfillments.md) | In a multi-tier supply chain a sales order (SO) spawns a purchase order (PO) that becomes another SO downstream, and so on. | _underscore/Model/Client/ItemFulfillment.php, _underscore/Model/Client/ItemFulfillmentItem.php, _underscore/Model/Client/ItemFulfillmentItemUnit.php, _underscore/Model/Client/ItemFulfillmentPackage.php, _underscore/Model/Compass/AdvanceShippingNotice.php, dbchanges2/Core/2026-02-13 - 75601 - RecursiveItemFulfillmentCreation.sql, dbchanges2/Core/2026-06-04 - RecursiveItemFulfillmentPut.sql |
 | [Tracking-Number Bridge Migration (ASN / Item Fulfillment / Item Receipt)](features/tracking-number-bridges.md) | Shipment tracking numbers used to live as **scalar FK columns** (`trackingNumberId`, `returnTrackingNumberId`) directly on the lowest-level "unit"/"item" tables | _underscore/Model/Client/AdvanceShippingNoticeItemUnit.php, _underscore/Model/Client/AdvanceShippingNoticeItemUnits/TrackingNumber.php, _underscore/Model/Client/ItemFulfillmentItemUnits/TrackingNumber.php, _underscore/Model/Client/ItemFulfillment.php, _underscore/Model/Prudential/AdvanceShippingNotice.php, _underscore/Model/Compass/AdvanceShippingNotice.php, _underscore/Trait/Netsuite/ItemFulfillment.php, api2/Component/Api/Cxml/Cxml.php, dbchanges2/Client/2026-06-10 - TrackingNumberBridges.sql, dbchanges2/Core/2026-06-10 - TrackingNumberBridges.sql |

package/knowledge/2.0/apps/_underscore/features/email-template-sending.md

@@ -0,0 +1,88 @@
+---
+title: Client Email Template Sending
+framework: "2.0"
+repo: _underscore
+project: _Underscore
+client: shared
+type: feature
+status: active
+updated: 2026-06-15
+owners: ["jcardinal"]
+files:
+  - _underscore/Model/Client/EmailTemplate.php
+  - _underscore/Model/Client/EmailTemplateOutgoingEmailAddress.php
+  - _underscore/Email.php
+related: []
+---
+
+## Summary
+
+`_Model_Client_EmailTemplate` sends a stored, client-defined email template by UUID. It
+loads the template from the client DB (`EmailTemplates` table), merges any template-stored
+recipient addresses, substitutes `{variable}` placeholders in the subject and body, and
+sends via `_Email`. The only client-specific input the send actually needs is the
+**client identifier** (used to scope the outgoing mail via `_Email::setClientIdentifier()`).
+
+## Key files / entry points
+
+- `_underscore/Model/Client/EmailTemplate.php` — the model. Three relevant methods:
+  - **`sendEmail(&$api, $uuid, $to, $cc, $bcc, ...$args): bool`** — the scripted-API entry
+    point. First param is `&$api` per the Record Script contract (see backend-php standard,
+    *Record Scripts*). The only thing it uses from `$api` is `$api->client->clientIdentifier`.
+  - **`send(string $clientIdentifier, $uuid, $to, $cc, $bcc, ...$args): bool`** — the
+    non-API entry point. Caller passes the client identifier directly; no `$api` object.
+  - **`dispatch(string $clientIdentifier, ...): bool`** (private) — the shared body both
+    entry points call. Holds all the real logic.
+- `_Model_Client_EmailTemplateOutgoingEmailAddress` — per-template stored TO/CC/BCC
+  addresses (`toCcBcc` enum), merged into the caller-supplied recipients.
+- `_underscore/Email.php` — `_Email` requires a non-empty `clientIdentifier` (throws
+  `clientIdentifier is required` otherwise) and uses it as the CloudWatch log stream name.
+
+## How it works
+
+1. Load the template by `uuid`; return `false` immediately if `!isActive`.
+2. Search `EmailTemplateOutgoingEmailAddress` for the template and append each stored
+   address to `$to` / `$cc` / `$bcc` by its `toCcBcc` value.
+3. Build `_Email`, set the client identifier, add recipients, set From from the template's
+   `sendFromEmailAddress` / `sendFromName`.
+4. Replace `{key}` placeholders in subject and body from the `$args` variadic map
+   (`replaceTemplateVariables`), then `send()`.
+
+Both `sendEmail()` and `send()` are thin wrappers that forward to `dispatch()`, so the API
+and non-API paths run identical code — no behavioral drift between them.
+
+## Data model
+
+- `EmailTemplates` (client DB): `uuid`, `isActive`, `sendFromEmailAddress`, `sendFromName`,
+  `priority`, `subject`, `body`.
+- `EmailTemplateOutgoingEmailAddress` (client DB): `emailTemplateId`, `emailAddress`,
+  `toCcBcc` (`TO`/`CC`/`BCC`).
+
+## Client variations
+
+The model is shared; client-specific senders pass their own identifier. Workers use a class
+constant (e.g. `self::CLIENT_IDENTIFIER`); model/interceptor code that already has an `$api`
+can keep using `sendEmail($api, ...)`.
+
+## Gotchas / known issues
+
+- **Use `send()` from any non-API context (workers, cron, internal code).** Before
+  2026-06-15 the only entry point was `sendEmail(&$api, ...)`, so callers with no API
+  context faked one: `$api = (object)['client' => (object)['clientIdentifier' => …]]`.
+  That hack is obsolete — pass the identifier to `send()` instead.
+- **`sendEmail()`'s signature is load-bearing for scripted APIs** — the Record Script engine
+  (`api2/Component/Api/V2/V2.php`, ~line 3594) calls the method with `api` as a named
+  argument, so the first param must stay `&$api`. Do not "clean it up" by removing it.
+- `_Email::send()` throws if the client identifier is empty — `send('')` will fail at send
+  time, not at call time.
+
+## Change history
+
+- 2026-06-15 — Added non-API `send(clientIdentifier, …)` entry point + private `dispatch()`;
+  `sendEmail(&$api, …)` kept unchanged as a wrapper for backward compatibility. Migrated the
+  `worker2` Compass Report and AI-BDR NetSuite callers off the fake-`$api` hack. (jcardinal)
+
+## Related docs
+
+- `2.0/standards/backend-php.md` — *Record Scripts* (the `&$api` contract).
+- `2.0/apps/api2/architecture.md` — scripted-API dispatch in `V2.php`.

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

@@ -11,13 +11,14 @@ _Auto-generated by `knowledge.js index`. Do not hand-edit._
 
 ## 2.0 framework
 
-- **_underscore** (_Underscore) _(framework core)_ — 5 doc(s) → [2.0/apps/_underscore/INDEX.md](2.0/apps/_underscore/INDEX.md)
+- **_underscore** (_Underscore) _(framework core)_ — 6 doc(s) → [2.0/apps/_underscore/INDEX.md](2.0/apps/_underscore/INDEX.md)
 - **worker2** (Worker) — 6 doc(s) → [2.0/apps/worker2/INDEX.md](2.0/apps/worker2/INDEX.md)
 - **api2** (API) — 1 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)
 - **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.77",
+  "version": "1.0.79",
   "description": "TOGA Technology Team Claude Knowledge System — shared AI coding harness with skills, knowledge base CLI, and project installer for Claude Code.",
   "keywords": [
     "claude",

package/skills/kickoff/SKILL.md

@@ -5,16 +5,36 @@ description: Start-of-session context loader for TOGA Technology projects. Run t
 
 # Kickoff — prime a coding session from the team knowledge base
 
+> ## 🛑 STOP — THIS IS A BLOCKING GATE. READ BEFORE DOING ANYTHING ELSE.
+>
+> When `/kickoff` is invoked you **MUST** complete Steps 0–6 of this skill **before**
+> any other tool call — no `Read`, `Grep`, `Glob`, `Edit`, `Write`, `Bash`, no agent
+> spawn, no investigation, no answering the developer's question. Priming comes first,
+> **always**.
+>
+> **Trailing text after `/kickoff` is NEVER a reason to skip priming.** A long, detailed
+> paragraph describing a specific task (file paths, line numbers, a design question) is
+> *still just the Step 2 task description* — it is input to the interview, **not**
+> permission to start working. The more detailed and actionable the request looks, the
+> more tempting it is to dive in — **resist that.** If you find yourself about to open a
+> file the developer named before you have loaded the knowledge base, you are violating
+> this gate. Stop and run Steps 0–6 first.
+>
+> Only after Step 5's "primed and ready" summary (and Step 6's plan, for non-trivial work)
+> may you touch the task itself.
+
 ## Arguments — text passed after `/kickoff` never skips any step
 
-`/kickoff` may be invoked with trailing text (e.g. `/kickoff worker2 backend fix for Compass`).
-That text is the developer's description of today's work — it is **not** permission to
-shortcut the flow.
+`/kickoff` may be invoked with trailing text (e.g. `/kickoff worker2 backend fix for Compass`),
+including a long, specific paragraph naming exact files, line numbers, and a concrete
+change. That text is the developer's description of today's work — it is **not** permission
+to shortcut the flow, no matter how actionable it looks.
 
 - **Step 0 (auto-update check) ALWAYS runs first**, with or without arguments.
 - Use the argument text to **pre-fill answers** to the Step 2 interview (framework, layer,
   repo, client, task). Only ask about whatever is still missing or ambiguous.
-- Never treat the argument as an instruction to start coding before Steps 0–6 complete.
+- Never treat the argument as an instruction to start coding — or even to start *reading
+  the named files* — before Steps 0–6 complete. Investigation IS work; it waits for priming.
 
 ## Step 0 — Auto-update check (runs before anything else, even with arguments)