toga-ai 1.0.472 → 1.0.473

package/knowledge/1.0/apps/library/features/startech-pcmaticb2b-sync.md

@@ -6,7 +6,7 @@ project: Library
 client: pcmaticb2b
 type: client-feature
 status: active
-updated: 2026-07-09
+updated: 2026-07-29
 owners: [snaredla]
 files:
   - library/app/api/toga2.php
@@ -84,3 +84,25 @@ Imports Startech (Easeedesk V3) config into TOGA 2.0 — users, groups, devices,
 - 2026-06-23: Initial doc — ticket type maps (both directions), NULL sync behavior, TOGADESK_PCS type added
 - 2026-07-06: Added syncWithToga V1 leg (cross-ref gating, cron-abort ordering, debugging findings) and supporting-records import notes (groups via groups_dispatching, getCategories ticket-type filter)
 - 2026-07-09: Corrected the groups note — groups come from `dynamic_field_options->data->groups` (16 groups); the empty result was a credentials bug (`agilant.api`), not the endpoint. Confirmed `getCategories` `ticket_type` filter works (`50,54` → 15 categories).
+- 2026-07-29: Added two per-ticket-type stage helpers to `App_Api_Toga2` (see
+  `clients/pcmaticb2b/features/startech-per-ticket-type-stages.md`):
+  `getStartechSelectableTicketStageNames($togadeskClientId, $togadeskDepartmentId)` resolves the
+  agent-selectable stage names for TOGaDesk's status dropdown (department → ticket type via
+  `TicketTypes.c_togadeskTicketDepartmentId`, filtered by `c_isSelectable = 1`), and
+  `getStartechTicketStageUuid($ticketTypeName, $ticketStageName)` resolves a stage within a type for
+  the 1.0 → 2.0 payload. Both reference the client's 2.0 schema **by name** (from
+  `App_Model_Client::getClientDatabaseNames()`) so the JOIN stays inside one client schema — do not use
+  `qqJoinClientsTable(…, true)` here, its UNION-across-all-clients form would cross-match ids between
+  clients. StarTech clients are identified by `App_Api_Toga2::STARTECH_TOGADESK_CLIENTS`
+  (TOGaDesk client id => TOGA 2.0 client id); non-StarTech clients short-circuit with no DB hit.
+- 2026-07-29: Added two per-ticket-type stage helpers to `App_Api_Toga2` (see
+  `clients/pcmaticb2b/features/startech-per-ticket-type-stages.md`):
+  `getStartechSelectableTicketStageNames($togadeskClientId, $togadeskDepartmentId)` resolves the
+  agent-selectable stage names for TOGaDesk's status dropdown (department → ticket type via
+  `TicketTypes.c_togadeskTicketDepartmentId`, filtered by `c_isSelectable = 1`), and
+  `getStartechTicketStageUuid($ticketTypeName, $ticketStageName)` resolves a stage within a type for
+  the 1.0 → 2.0 payload. Both reference the client's 2.0 schema **by name** (from
+  `App_Model_Client::getClientDatabaseNames()`) so the JOIN stays inside one client schema — do not use
+  `qqJoinClientsTable(…, true)` here, its UNION-across-all-clients form would cross-match ids between
+  clients. StarTech clients are identified by `App_Api_Toga2::STARTECH_TOGADESK_CLIENTS`
+  (TOGaDesk client id => TOGA 2.0 client id); non-StarTech clients short-circuit with no DB hit.

package/knowledge/2.0/apps/worker2/features/startech-webhook-handler.md

@@ -6,12 +6,13 @@ project: Worker
 client: pcmaticb2b
 type: feature
 status: active
-updated: 2026-06-23
+updated: 2026-07-29
 owners: [snaredla]
 files:
   - worker2/Worker/Startech.php
 related:
   - clients/pcmaticb2b/features/startech-ticket-sync.md
+  - clients/pcmaticb2b/features/startech-per-ticket-type-stages.md
   - clients/pcmaticb2b/profile.md
 ---
 
@@ -53,6 +54,26 @@ Conditional additions: `ticketStage` (from `ticket_status`), `contact` (from `cr
 - `c_escalateToStartech: 0` must be in the payload. If omitted, the interceptor still skips Startech (null is also falsy), but the field stays NULL in TOGA 2.0 — making webhook tickets indistinguishable from TOGaDesk-created ones.
 - `ticketType` is resolved via `c_startechTicketTypeId` on `TicketTypes` — not a hardcoded string. Startech type IDs: SR=6, PCS=54, API=201.
 
+## Ticket type and stage lookups (per-ticket-type stages)
+
+Since ticket stages became scoped to a ticket type, matching a nested child by a single Startech id is
+ambiguous, so `Webhook()` resolves both explicitly and sends `['uuid' => …]`:
+
+- **Ticket type** — `GET /ticket-types` filtered on `c_startechTicketTypeId` **plus** `code`, mapped by
+  `_Worker_Startech::TOGA_TICKET_TYPE_CODE_BY_STARTECH_TICKET_TYPE_ID` (`50 => 'SUPPORT REQUEST'`,
+  `54 => 'PCS'`). **Startech type 54 maps to three TOGA types** for PC Matic B2B — 1 PCS, 3 API and
+  4 Togadesk PCS — so `c_startechTicketTypeId` alone cannot identify a type. API and Togadesk PCS are
+  TOGA-side origins (tickets created via the API or in TOGaDesk), never what Startech sends inbound.
+- **Ticket stage** — `GET /ticket-stages` filtered on `c_startechStageId` **plus** the resolved
+  `ticketTypeId`. Startech status ids repeat across types (New = `1` for every type), so a stage is only
+  unique per type. If the type cannot be resolved, the stage is **omitted** rather than risking a stage
+  from another type; the type itself falls back to the old `c_startechTicketTypeId` match.
+
+Both filters use `fields` to request only `id`/`uuid`. Filtering on `ticketTypeId` requires the
+`Core.RecordFields` registration (id 2479) — see the per-ticket-type-stages doc for deploy order.
+
 ## Change history
 
+- 2026-07-29: Explicit ticket-type (id + code) and ticket-stage (id + ticketTypeId) lookups for
+  per-ticket-type stages; documented the Startech type 54 → three TOGA types ambiguity
 - 2026-06-23: Initial doc — webhook handler, c_escalateToStartech=0 payload field, POST vs PUT logic

package/knowledge/clients/pcmaticb2b/INDEX.md

@@ -3,5 +3,6 @@
 | Doc | Framework | Summary | Files |
 |-----|-----------|---------|-------|
 | [PC Matic B2B — Startech Entitlement Provisioning (customer + SKU)](features/startech-entitlement-provisioning.md) | 2.0 | When a PC Matic B2B entitlement is created in TOGA 2.0 (`POST /entitlements`), the client registers the customer on StarTech's OptimumDesk platform and assigns | _underscore/Trait/Startech/Entitlement.php, _underscore/Model/Pcmaticb2b/Entitlement.php, _underscore/Config.php, api2/Config/production.ini, api2/Config/beta.ini, api2/Config/sandbox-client.ini, test/@srija/Startech Testing/PC Matic B2B/test_e2e_pcmaticb2b.sh |
+| [PC Matic B2B — Startech Per-Ticket-Type Ticket Stages](features/startech-per-ticket-type-stages.md) | 2.0 | Startech (OptimumDesk) exposes a **different status set per ticket type** — Support Request (workflow 56) has 15 statuses, Phone Call Support (workflow 59) has | dbchanges2/Client/2026-07-22a - TicketStageTicketTypeId.sql, dbchanges2/Core/2026-07-28 - TicketStageTicketTypeIdRecordField.sql, dbchanges2/_modules/startech/2026-07-28 - TicketStageIsSelectable.sql, dbchanges2/Client_Pcmaticb2b/2026-07-28 - pcmaticb2b ticketstages.sql, _underscore/Model/Client/TicketStage.php, _underscore/Trait/Startech/TicketStage.php, _underscore/Model/Pcmaticb2b/TicketStage.php, _underscore/Trait/Startech/Ticket.php, worker2/Worker/Startech.php, library/app/api/toga2.php, library/app/model/togadesk/ticket.php, togadesk/desk/includes/functions.php, togadesk/desk/includes/controllers/data/tickets/manage.php, togadesk/desk/template/pages/tickets/manage.php |
 | [PC Matic B2B — Startech Ticket Sync](features/startech-ticket-sync.md) | 1.0 | Bidirectional ticket sync between TOGaDesk 1.0 (client 177), TOGA 2.0 (client 21), and Startech (Easeedesk). | worker/crons/toga2/startech/sync_togadesk_startech_pcmaticb2b.php, worker/crons/toga2/startech/common_import_supporting_records.php, library/app/api/toga2.php, library/app/api/startechticket.php, togadesk/desk/includes/controllers/quickactions.php, togadesk/desk/template/pages/tickets/manage.php, togadesk/desk/includes/functions.php, worker2/Worker/Startech.php, _underscore/Trait/Startech/Ticket.php, dbchanges2/Client_Pcmaticb2b/2026-06-22-pcmaticb2b-enhancements.sql |
 | [PC Matic B2B Client Profile](profile.md) | 1.0 | PC Matic B2B is a client using TOGaDesk 1.0 for ticket management, with TOGA 2.0 as the data layer and Startech (Easeedesk) as an external ticketing system for | worker/crons/toga2/startech/sync_togadesk_startech_pcmaticb2b.php, togadesk/desk/includes/functions.php |

package/knowledge/clients/pcmaticb2b/features/startech-per-ticket-type-stages.md

@@ -0,0 +1,186 @@
+---
+title: PC Matic B2B — Startech Per-Ticket-Type Ticket Stages
+framework: "2.0"
+project: TOGa
+client: pcmaticb2b
+type: client-feature
+status: active
+updated: 2026-07-29
+owners: [snaredla]
+files:
+  - dbchanges2/Client/2026-07-22a - TicketStageTicketTypeId.sql
+  - dbchanges2/Core/2026-07-28 - TicketStageTicketTypeIdRecordField.sql
+  - dbchanges2/_modules/startech/2026-07-28 - TicketStageIsSelectable.sql
+  - dbchanges2/Client_Pcmaticb2b/2026-07-28 - pcmaticb2b ticketstages.sql
+  - _underscore/Model/Client/TicketStage.php
+  - _underscore/Trait/Startech/TicketStage.php
+  - _underscore/Model/Pcmaticb2b/TicketStage.php
+  - _underscore/Trait/Startech/Ticket.php
+  - worker2/Worker/Startech.php
+  - library/app/api/toga2.php
+  - library/app/model/togadesk/ticket.php
+  - togadesk/desk/includes/functions.php
+  - togadesk/desk/includes/controllers/data/tickets/manage.php
+  - togadesk/desk/template/pages/tickets/manage.php
+related:
+  - clients/pcmaticb2b/features/startech-ticket-sync.md
+  - 2.0/apps/worker2/features/startech-webhook-handler.md
+  - 1.0/apps/library/features/startech-pcmaticb2b-sync.md
+---
+
+## Summary
+
+Startech (OptimumDesk) exposes a **different status set per ticket type** — Support Request
+(workflow 56) has 15 statuses, Phone Call Support (workflow 59) has 10. Previously TOGA stored a
+single flat set of 8 generic stages, so Startech statuses like Connected or Dispatched could not be
+represented and agents could pick statuses Startech would reject.
+
+This feature scopes ticket stages to a ticket type via a nullable `TicketStages.ticketTypeId`, and
+marks which stages an agent may actually select via a `c_isSelectable` custom field. TOGaDesk shows
+**every** synced status (full visibility for reporting) but only offers the selectable subset in the
+status dropdown.
+
+A bridge table was deliberately rejected in favour of the nullable FK to avoid duplicating stage rows.
+
+## Key files / entry points
+
+| Concern | File |
+|---|---|
+| `ticketTypeId` column (all client DBs) | `dbchanges2/Client/2026-07-22a - TicketStageTicketTypeId.sql` |
+| `ticketTypeId` API registration + ACL | `dbchanges2/Core/2026-07-28 - TicketStageTicketTypeIdRecordField.sql` |
+| `c_isSelectable` column + registration | `dbchanges2/_modules/startech/2026-07-28 - TicketStageIsSelectable.sql` |
+| Per-type stage seed | `dbchanges2/Client_Pcmaticb2b/2026-07-28 - pcmaticb2b ticketstages.sql` |
+| Model fields | `_underscore/Model/Client/TicketStage.php`, `_underscore/Trait/Startech/TicketStage.php` |
+| Inbound webhook lookups | `worker2/Worker/Startech.php` (`_Worker_Startech::Webhook`) |
+| Outbound to Startech | `_underscore/Trait/Startech/Ticket.php` (`postPost` / `postPut`) |
+| 1.0 ↔ 2.0 sync mapping | `library/app/api/toga2.php` |
+| Desk dropdown + badges | `togadesk/desk/includes/controllers/data/tickets/manage.php`, `.../includes/functions.php` |
+
+## Data model
+
+`TicketStages` gained two fields:
+
+- **`ticketTypeId`** — nullable `INT UNSIGNED` FK to `Client.TicketTypes`, `AFTER ticketStatusId`.
+  NULL = applies to all types. Registered as `Core.RecordFields` **id 2479**
+  (`type = 'NUMBER'`, `precision = 0`, **`isIdentifier = 1`**) so it can be filtered over the V2 API
+  and participate in MATCH keys. Record 88 (`Ticket stages`) is `aclDatabase = CLIENT`, so its native
+  fields need a grant in **both** `Core.AclFieldPermissions` (roleId 3) **and** each client's
+  `AclFieldPermissions` (roleId 1) — mirroring the sibling `ticketStatusId`.
+- **`c_isSelectable`** — nullable `TINYINT UNSIGNED` custom field (`1` = agent-selectable,
+  `0` = display-only). Registered in the client's `CustomRecordFields` (recordId 88, `BOOLEAN`) with
+  `AclCustomFieldPermissions` for roles 1 and 3. Declared on `_Trait_Startech_TicketStage` alongside
+  `c_startechStageId`, so every Startech client's TicketStage model gets both by `use`-ing the trait.
+
+### Seeded stages (PC Matic B2B) — 35 rows across 4 types
+
+| Dept | TicketTypes.id | Type | Startech type / workflow | Stage ids | Count |
+|---|---|---|---|---|---|
+| 336 | 2 | Support Request | 50 / 56 | 1-15 | 15 |
+| 337 | 1 | Phone Call Support | 54 / 59 | 16-25 | 10 |
+| 338 | 3 | API | 54 | 26-30 | 5 |
+| 338 | 4 | Togadesk PCS | 54 | 31-35 | 5 |
+
+Selectable in **every** set: New Ticket, In Progress, Resolved, Reopened, Closed. Everything else
+(Connected 76, Transferred 141, User Offline 155, Cancelled 177, Remote Control 178, Customer
+Confirmation 179, Lost 180, Dispatched 181, Automate Check 183, Live 186, Rework 74) is display-only.
+
+API and Togadesk PCS get **only the 5 mutual TOGaDesk/Startech statuses** — those tickets originate on
+the TOGA/Desk side, so Startech automation statuses would never legitimately apply. Awaiting User
+(210), Open (72) and On Hold (209) were dropped: they appear in neither workflow.
+
+## How it works
+
+### Desk visibility + selectability (1.0)
+
+1. `manage.php` calls `App_Api_Toga2::getStartechSelectableTicketStageNames($clientId, $departmentId)`.
+2. The resolver maps the TOGaDesk client id to a TOGA 2.0 client id via
+   `App_Api_Toga2::STARTECH_TOGADESK_CLIENTS` (also the "is this a Startech client?" test), resolves
+   the 2.0 schema **by name** from `App_Model_Client::getClientDatabaseNames()`, and queries
+   `TicketStages ⋈ TicketTypes WHERE c_togadeskTicketDepartmentId = ? AND c_isSelectable = 1`.
+3. Non-Startech clients get `[]` back with **no DB hit** and fall through to the default dropdown.
+4. Display is unrestricted: `ticketStatusBadge()` renders any status. Its third parameter
+   (`$showStartechStatusColors`) enables dark inline hex + white text, passed only from the pcmatic
+   ticket-details templates — so lists/dashboard/search show the same statuses in neutral gray.
+
+### Inbound Startech webhook (2.0)
+
+`_Worker_Startech::Webhook` resolves type and stage **explicitly** instead of relying on child MATCH:
+
+1. `GET /ticket-types` filtered on `c_startechTicketTypeId` **+** `code` (via
+   `TOGA_TICKET_TYPE_CODE_BY_STARTECH_TICKET_TYPE_ID`: `50 => SUPPORT REQUEST`, `54 => PCS`).
+2. `GET /ticket-stages` filtered on `c_startechStageId` **+** the resolved `ticketTypeId`.
+3. Both passed as `['uuid' => …]`. If the type cannot be resolved the stage is **omitted** rather than
+   risking another type's stage; the type itself falls back to the old `c_startechTicketTypeId` match.
+
+### 1.0 ↔ 2.0 sync (`library/app/api/toga2.php`)
+
+- **2.0 → 1.0:** use `ticketStage->name` directly. 2.0 stage names match TOGaDesk status strings for
+  every type, and the name is inherently type-correct because the stage belongs to the ticket's type.
+- **1.0 → 2.0:** `getStartechTicketStageUuid($ticketTypeName, $ticketStageName)` resolves the type by
+  name then the stage by name within that type, and the payload sends `ticketStage.uuid`. Results are
+  cached per run in `$_startechTicketStageUuids`. Applied at both write sites (ticket create and
+  note/reply status change). Non-pcmatic clients keep the existing `status → code` map untouched.
+
+### Outbound to OptimumDesk (interceptor)
+
+`_Trait_Startech_Ticket::getStartechTicketStatusForTicketType($payload)` compares
+`ticketStage->ticketTypeId` with `ticketType->id` and returns `0` on mismatch, so the status is omitted
+instead of sent. Startech validates a status against the type's workflow and returns **400** for a
+status that workflow lacks (e.g. Transferred on a Phone Call Support ticket). Used by both `postPost`
+(create) and `postPut` (update).
+
+## Client variations
+
+Only PC Matic B2B is seeded today. Selectability generalises to any Startech client by adding one row
+to `STARTECH_TOGADESK_CLIENTS`; the **coloured** badges are pcmatic-only by product decision
+(`TOGADESK_CLIENT_ID__PCMATICB2B`).
+
+## Gotchas / known issues
+
+- **Deploy order matters.** Migrations must run before the library/worker2/_underscore deploy:
+  `Client/2026-07-22a` → `Core/2026-07-28` → `_modules/startech/2026-07-28` → pcmatic seed. Until
+  `ticketTypeId` is registered and stages are seeded, the new lookups resolve nothing and the code
+  falls back to the old paths.
+- **The old `ticketStage->code` switch was a live mis-mapping.** Codes used to mean statuses (1-8);
+  after the seed they are row ids (1-35), so code 4 (`Reopened`) would have set the ticket to
+  `Closed`. Never map a pcmatic stage by code — use the name or the uuid.
+- **`c_startechStageId` is no longer unique.** New = `1` for all four types. Always scope a stage
+  lookup by `ticketTypeId`.
+- **Startech type `54` maps to three TOGA types** (1 PCS, 3 API, 4 Togadesk PCS), so
+  `c_startechTicketTypeId` alone cannot identify a type — pair it with `code`.
+- **Interceptors receive `$outData`**, the resolved response record with expanded relations (depth
+  bumped to the interceptor's `minDepth`) — not the raw request. That is why sending
+  `ticketStage.uuid` still yields a populated `c_startechStageId` / `ticketTypeId` downstream.
+- **`c_isSelectable` is registered with `isIdentifier = 0` — deliberately.** `isIdentifier = 1` would
+  put a mutable flag in the child-match lookup key (`api2/Component/Api/V2/V2.php:7053-7128` searches
+  only on identifier fields), so flipping a stage's selectability would stop a MATCH payload finding the
+  row and the API would insert a **duplicate stage** instead of updating. `ticketTypeId` by contrast
+  *must* be `isIdentifier = 1` — it is what makes `{c_startechStageId, ticketTypeId}` resolve to the one
+  correct per-type stage. Note: when a record has **no** identifier fields at all, the API falls back to
+  treating every field as an identifier.
+- **The seed opens with `DELETE FROM TicketStages` / `TicketStatuses`.** Clean for a fresh onboard, but
+  it will fail or orphan rows if live tickets already reference the old stage ids — a migrate-in-place
+  is needed for an already-populated schema.
+- **`c_isSelectable` exists only in 2.0.** TOGaDesk 1.0 has no statuses table (`tickets.status` is a
+  free string), so 1.0 reads the flag live from the client's 2.0 schema on each ticket-details render.
+  Flipping it in 2.0 changes the dropdown immediately, with no sync step.
+- **Dept 338 maps to two types** (3 and 4) with identical status names; the resolver's
+  `GROUP BY ticketStages.name` collapses them to one clean list. That ambiguity still matters for any
+  department → type lookup elsewhere.
+
+## Related docs
+
+- `clients/pcmaticb2b/features/startech-ticket-sync.md`
+- `2.0/apps/worker2/features/startech-webhook-handler.md`
+- `1.0/apps/library/features/startech-pcmaticb2b-sync.md`
+
+## Change history
+
+- 2026-07-29: Initial doc — delivers the per-ticket-type statuses enhancement flagged as pending on
+  2026-07-10 in `startech-ticket-sync.md`. Covers `TicketStages.ticketTypeId` (Core.RecordFields 2479,
+  `isIdentifier = 1`) and the `c_isSelectable` custom field, the 35-stage seed across 4 ticket types,
+  TOGaDesk visibility vs selectability (`getStartechSelectableTicketStageNames()`, badge colour scoping),
+  explicit type + stage lookups in the worker2 webhook, per-type stage mapping in both sync directions,
+  and the outbound interceptor's ticket-type/stage consistency guard. Records two bugs fixed (the
+  2.0 → 1.0 `ticketStage->code` mis-mapping; non-unique `c_startechStageId` and Startech type 54) and
+  the migration-before-deploy ordering.

package/knowledge/clients/pcmaticb2b/features/startech-ticket-sync.md

@@ -5,7 +5,7 @@ project: TOGa
 client: pcmaticb2b
 type: client-feature
 status: active
-updated: 2026-07-10
+updated: 2026-07-29
 owners: [snaredla]
 files:
   - worker/crons/toga2/startech/sync_togadesk_startech_pcmaticb2b.php
@@ -19,6 +19,7 @@ files:
   - _underscore/Trait/Startech/Ticket.php
   - dbchanges2/Client_Pcmaticb2b/2026-06-22-pcmaticb2b-enhancements.sql
 related:
+  - clients/pcmaticb2b/features/startech-per-ticket-type-stages.md
   - clients/pcmaticb2b/profile.md
   - 2.0/apps/worker2/features/startech-webhook-handler.md
   - 1.0/apps/library/features/startech-pcmaticb2b-sync.md
@@ -228,3 +229,13 @@ not yet resolved:
 - 2026-07-06: Added sync prerequisites/gotchas (entitlement gate, staff-email collision) and clarified the escalate button's actual behavior (desk changes always; 2.0 PUT only when linked)
 - 2026-07-09: Corrected Startech ticket-type IDs (50 Support Request, 54 Phone Call Support for company 24412); added Sync Risks (escalate flag never reset, webhook 1→0 silencing, interceptor DB-gating) and Verification (OUT-log + E2E test); cross-linked entitlement provisioning.
 - 2026-07-10: Added Ticket Statuses & Workflows section — workflow IDs 56 (Support Request) / 59 (Phone Call Support), statuses queried by workflow_id (not type id); TicketStages.c_startechStageId check (Awaiting User 210 / On Hold 209 disabled, Open 72 absent → invalid); flagged per-ticket-type statuses as a pending enhancement (sync + TOGaDesk).
+- 2026-07-29: Per-ticket-type stages delivered (the 2026-07-10 pending enhancement) — see
+  `clients/pcmaticb2b/features/startech-per-ticket-type-stages.md`. Sync-relevant changes:
+  **2.0 → 1.0** no longer switches on `ticketStage->code` (codes became per-type row ids 1-35, so the
+  old 1-8 switch mis-mapped — code 4 `Reopened` set the ticket to `Closed`); it now uses
+  `ticketStage->name`, which is type-correct by construction. **1.0 → 2.0** no longer uses the shared
+  `status → code` map for pcmatic (it would attach another type's stage); `App_Api_Toga2::getStartechTicketStageUuid($ticketTypeName, $ticketStageName)`
+  resolves the stage within the ticket's type and the payload sends `ticketStage.uuid` (applied to both
+  ticket create and note/reply status changes, cached per run). The outbound interceptor now drops a
+  status whose stage belongs to a different ticket type, since Startech 400s on a status outside the
+  type's workflow.

package/package.json

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