toga-ai 1.0.796 → 1.0.798

package/knowledge/1.0/apps/worker/workflows/tracing-a-worker-cron-run-in-production.md

@@ -6,8 +6,8 @@ project: Worker
 client: shared
 type: workflow
 status: active
-updated: 2026-09-04
-owners: ["bala", "kyalamarthi"]
+updated: 2026-09-11
+owners: ["bala", "kyalamarthi", "rgirish"]
 files:
   - worker/ebs/cron.worker.php
   - worker/schedules/cron.worker.sync.json
@@ -23,6 +23,7 @@ related:
   - ../../library/features/cron-execution-monitoring.md
   - ../../library/features/email-test-mode-and-write-free-sends.md
   - ../../../1.0/standards/backend-php.md
+  - ../../../clients/prudential/features/itemclasses-device-tier-data.md
 ---
 
 ## Summary
@@ -47,6 +48,27 @@ frequency makes you read a normal gap as an outage.
 Also check whether the job is registered in the env you are testing in at all: this one is **not**
 in `cron.beta.json`, so beta never runs it on a schedule. Nothing on beta is evidence about it.
 
+### Is the job switched OFF? — read the `active` flag carefully
+
+Each schedule entry is `{active, name, schedule, cron}`, and `ebs/cron.worker.php:39` gates it:
+
+```php
+if (!property_exists($cron, 'active') || $cron->active) {
+```
+
+- **`"active": 0` genuinely stops the job** — it is never written into the crontab, so it leaves
+  no `CronJobExecutions` row and no trace anywhere. Indistinguishable from "never fired" unless
+  you read the JSON.
+- **⚠ A MISSING `active` property means the job RUNS.** The default is on, not off. Do not read
+  the absence of `active` as "disabled".
+
+When a job is off, `git log` the schedule file to find out who turned it off and why — the commit
+message usually carries the reason. Worked example (2026-09-11): "Transmissions to Netsuite"
+(`cron.worker.sync.json:441`) is `"active": 0`, disabled 2026-07-17 in commit `14570def`
+("Add careOf & skip Apple; disable Netsuite cron") on `_production`. That single flag is what made
+Prudential's `ItemClasses` data dead — see
+[Prudential ItemClasses device-tier data](../../../clients/prudential/features/itemclasses-device-tier-data.md).
+
 ### Which of the 7 boxes runs it — and in which timezone
 
 Two facts you need before you go looking for evidence, both easy to get wrong:
@@ -188,6 +210,11 @@ real script **never executes**, on every tick, with no error anywhere. It looks
 contain anything; only the `cron` path is shell-parsed.
 
 ## Change history
+- 2026-09-11 — Added **"is the job switched OFF?"** to Step 1: `ebs/cron.worker.php:39` gates on
+  `!property_exists($cron, 'active') || $cron->active`, so `"active": 0` genuinely stops the job
+  and leaves no trace, but a **missing `active` property means it RUNS** (default is on). Also:
+  `git log` the schedule file to find who disabled it and why. Found while proving Prudential's
+  `ItemClasses` data was dead. (rgirish)
 - 2026-09-04 — Added the **`&`-in-a-cron-filename trap**: `ebs/cron.worker.php:41` concatenates the
   path into the crontab line unquoted, so a shell metacharacter splits the command and the script
   never runs while leaving no trace. Found via the renamed Compass Canada

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

@@ -27,6 +27,7 @@
 | [FIELD_STORAGE fields — per-row lazy hydration and the platform-wide missing-column 500](features/field-storage-row-hydration.md) | `FIELD_STORAGE` is the 2.0 field type for blob-backed columns (S3 or local folder). |
 | [Forecast.Sales NetSuite import engine (real-time webhook)](features/forecast-sale-import.md) | Real-time importer that takes a NetSuite **sale** record and writes its lines into `Forecast.Sales` (the Forecast2 revenue table). |
 | [isFulfillable Propagation Up the SO↔PO Chain](features/fulfillable-item-propagation.md) | `Items.isFulfillable` is a boolean that gates whether a storefront line's **Qty Fulfilled** cell is actionable. |
+| [ItemClasses / _Model_Client_ItemClass — who actually uses it (and why it is not free)](features/item-classification-itemclasses.md) | `ItemClasses` is an empty-looking, almost-unused lookup table that ships in **every** 2.0 client database. |
 | [Item-Fulfillment Stage Lifecycle (picked/packed/shipped) & Order Status](features/item-fulfillment-stage-lifecycle-and-order-status.md) | Every ItemFulfillment (IF) now carries an explicit **stage** — picked → packed → shipped — resolved through `ItemFulfillmentStages → ItemFulfillmentStatuses` (m |
 | [DB-free unit testing for _underscore model interceptors](features/model-interceptor-unit-testing.md) | `_underscore` shipped with **no** PHPUnit setup (no `composer.json`/`phpunit`; only vendored PhpOffice tests existed). |
 | [_Model magic-field access (__get without __isset)](features/model-magic-field-access.md) | `_Model` exposes DB columns as "magic" properties via `__get()`, but it defines **no** `__isset()`. |

package/knowledge/2.0/apps/_underscore/features/cloud-s3-helpers.md

@@ -6,8 +6,8 @@ project: _Underscore
 client: shared
 type: feature
 status: active
-updated: 2026-07-14
-owners: ["jcardinal", "bala"]
+updated: 2026-09-10
+owners: ["jcardinal", "bala", "rgirish"]
 files:
   - _underscore/Cloud.php
 related:
@@ -59,6 +59,13 @@ None — shared core helper.
   do not add your own `ContinuationToken` loop on top.
 - A bucket outside the config-default us-east-1 (e.g. `agilant-as2` in us-west-2) throws
   `AuthorizationHeaderMalformed` unless you pass `$awsRegion`.
+- **⚠ `copyFileToS3` is a single `putObject` — it CANNOT upload a file larger than 5 GB.**
+  Verified 2026-09-10 at `_underscore/Cloud.php:49`: the method issues one `putObject` call, and
+  S3 caps a single PUT at **5 GB**. There is **no `MultipartUploader` anywhere in `_underscore`
+  or `worker2`**. Anything that could produce a large artifact — a database dump above all — will
+  fail on this helper once it crosses the limit. If you need large-object upload, add
+  `MultipartUploader` explicitly; do not assume this helper scales.
+
 - **`getFileFromS3` (the GET method) is single-region.** It builds the `S3Client` with region
   `_Config::cloud('aws_region')` (the worker's own region) and only swallows HTTP 404. Reading
   an object from a bucket in a **different** region raises a `301 PermanentRedirect`, which it
@@ -67,6 +74,10 @@ None — shared core helper.
   has no region-override parameter.)
 
 ## Change history
+- 2026-09-10 — Recorded that **`copyFileToS3` (`Cloud.php:49`) is a single `putObject`**, so it
+  cannot upload an object larger than S3's 5 GB single-PUT cap, and that **no `MultipartUploader`
+  exists anywhere in `_underscore` or `worker2`**. Matters for any large-artifact upload, database
+  dumps first. (rgirish)
 - 2026-07-15 — Documented that `getFileFromS3` is single-region (client built with the worker's
   own `aws_region`, only swallows 404, re-throws `301 PermanentRedirect` for cross-region reads);
   use a direct HTTPS download for cross-region/public objects. (bala)

package/knowledge/2.0/apps/_underscore/features/item-classification-itemclasses.md

@@ -0,0 +1,127 @@
+---
+title: "ItemClasses / _Model_Client_ItemClass — who actually uses it (and why it is not free)"
+framework: "2.0"
+repo: _underscore
+project: _Underscore
+client: shared
+type: feature
+status: active
+updated: 2026-09-11
+owners: ["rgirish"]
+files:
+  - _underscore/Model/Client/ItemClass.php
+  - _underscore/Model/Client/Item.php
+  - worker/crons/toga2/prudential/transmissions_to_netsuite.php
+  - toga2-supply/src/pages/Inventory/api/InventoryApi.tsx
+related:
+  - ./netsuite-rest-client.md
+  - ./record-change-audit-log.md
+  - ../../../../clients/prudential/features/itemclasses-device-tier-data.md
+  - ../../dbchanges2/workflows/client-schema-drift-audit.md
+---
+
+## Summary
+
+`ItemClasses` is an empty-looking, almost-unused lookup table that ships in **every** 2.0 client
+database. It looks like free real estate for a new item-classification feature. It is not:
+**2 of 36 production clients already have rows in it, and they use it for two different things,
+neither of which is NetSuite's `class` field.**
+
+Read this before you plan to reuse, extend, or repurpose `ItemClasses` for any client.
+
+Audit done 2026-09-11 across all TOGA codebases and all 36 production client schemas.
+
+## Key files / entry points
+
+- **`_underscore/Model/Client/ItemClass.php`** — `_Model_Client_ItemClass`,
+  `DATABASE = _underscore::DB_CLIENT`, `TABLE = 'ItemClasses'`. Four fields only:
+  `id`, `uuid`, `code`, `name`.
+- **`_underscore/Model/Client/Item.php:23`** — the only foreign key:
+  `public $itemClassId = [self::FIELD_FOREIGNKEY, ... => '\_Model_Client_ItemClass'];`
+- **`worker/crons/toga2/prudential/transmissions_to_netsuite.php:171-178`** — the **only** code
+  anywhere that reads it (see below).
+
+## How it works
+
+### The table ships blank to everyone
+
+`ItemClasses` is part of the blank client DB, so every 2.0 tenant has the table. Having the
+table says nothing about whether the client uses it. **Check row counts, not schema.**
+
+### Who has data (prod, verified 2026-09-11)
+
+| Client | Rows in `ItemClasses` | Items tagged | What the rows actually mean |
+|---|---|---|---|
+| **Northwell** | 27 | 245 of 247 | ServiceNow **service categories** — "Print", "Computer", "Service Desk" |
+| **Prudential** | 7 | 9 of 765 | Dell/Apple **device tiers** — "LATITUDE 73XX", "MACBOOK PRO" |
+| all other 34 clients | 0 | 0 | unused |
+
+Two clients, two unrelated meanings. Neither is an "item class" in the NetSuite sense.
+
+**Canon is a false positive.** `dbchanges2/Client_Canon/2024-01-01.sql` contains `ItemClasses`
+schema changes, but production `Client_Canon` has **0 rows**. Schema history is not usage.
+
+### There is exactly one reader in the whole platform
+
+`worker/crons/toga2/prudential/transmissions_to_netsuite.php:171-178` pulls
+`ItemClasses.name` as `deviceTier` for the line-1 item of a sales order and sends it to NetSuite:
+
+```sql
+SELECT ItemClasses.name
+FROM SalesOrderItems
+INNER JOIN Items ON Items.id = SalesOrderItems.itemId
+INNER JOIN ItemClasses ON ItemClasses.id = Items.itemClassId
+WHERE SalesOrderItems.salesOrderId = SalesOrders.id AND SalesOrderItems.lineNumber = 1
+LIMIT 1
+```
+
+That cron is **disabled** — see the
+[Prudential ItemClasses data doc](../../../../clients/prudential/features/itemclasses-device-tier-data.md).
+
+**Nothing writes `itemClassId`.** No writer exists in `api2`, `worker2`, or `_underscore`.
+
+### Frontend: one real reference, and a grep trap
+
+`grep itemClass` in the frontend is misleading — most hits in `toga2-supply` are CSS
+variables like `menuItemClassNames`, not this table. The one genuine reference is
+`toga2-supply/src/pages/Inventory/api/InventoryApi.tsx:815`, requesting the column
+`item.itemClass.name`.
+
+## NetSuite `classification` — the shape you would have to map from
+
+Queried live via SuiteQL (2026-09-11): **311 classifications**, columns
+`id`, `name`, `fullname`, `isinactive`, `parent`.
+
+- **It is a tree, not a flat list.** Each row has a `parent` and a colon-separated `fullname`,
+  e.g. name `Laptop` / fullname `Technology Sales : Hardware : End User Devices : Laptop` /
+  parent `405`.
+- **⚠ `name` is NOT globally unique** — only unique within its parent. Repeats seen:
+  "Managed Services" 3x (ids 75, 395, 379), "Software" 2x (ids 3, 419), "AI & Data Sciences" 2x,
+  "Data Services" 2x.
+
+## Gotchas
+
+- **⚠ `ItemClasses.name` has a UNIQUE index (index literally named `name`).** NetSuite
+  classification names repeat, so **any attempt to load NetSuite classes into this table fails
+  until that UNIQUE is dropped.** This is the first blocker on any NetSuite-classification work.
+- **A hierarchy path column must be `TEXT`, not `varchar(512)`.** NetSuite `fullname` values are
+  long, and the 2.0 standard caps varchar at 255.
+- **The table is already `utf8mb4_0900_ai_ci`**, so new columns need no explicit `COLLATE`.
+- **`c_` custom fields are NOT declared as properties on the 2.0 Model class.** The framework
+  reads them from `CustomRecordFields` (`ItemClasses` is `Core.Records` id **105**). Confirmed:
+  no `public $c_netsuite*` property exists on any `Model/Client` class. Copy the pattern in
+  `dbchanges2/_modules/netsuite/2026-08-18 - TransferOrdersNetsuiteStatus.sql`.
+- **Check whether the client has an `ItemClassCustomFields` table before adding `c_` columns.**
+  `Client_Prudential` does not, so its `c_` columns would go directly on `ItemClasses`.
+- **"Every client has the table" ≠ "the table is free."** Repurposing `ItemClasses` org-wide
+  would break Northwell's 245 tagged items, which hold ServiceNow service categories.
+
+## Change history
+- 2026-09-11 — Documented from a full usage audit of `ItemClasses` across every TOGA codebase and
+  all 36 prod client schemas: the table ships blank to all clients but **only Northwell (27 rows,
+  ServiceNow service categories) and Prudential (7 rows, Dell device tiers) have data**, for two
+  different meanings; there is exactly **one reader** (`transmissions_to_netsuite.php:171-178`,
+  currently disabled) and **zero writers**; Canon has schema but no rows. Recorded the live
+  NetSuite `classification` shape (311 rows, a tree with repeating `name`) and the resulting
+  blocker: `ItemClasses.name` is UNIQUE and must be dropped before NetSuite classes can be
+  mapped in. (rgirish)

package/knowledge/2.0/apps/ai-bdr/features/web-funnel-app.md

@@ -6,8 +6,8 @@ project: AI-BDR
 client: shared
 type: feature
 status: active
-updated: 2026-08-26
-owners: [tcox]
+updated: 2026-09-10
+owners: [tcox, rgirish]
 files:
   - bdr/PLAN.md
   - bdr/next.config.ts
@@ -32,6 +32,9 @@ files:
   - bdr/test/fastDial.test.ts
   - bdr/eslint.config.mjs
   - bdr/amplify.yml
+  - bdr/package.json
+  - bdr/.npmrc
+  - bdr/src/components/TalosDrawer.tsx
   - bdr/src/app
   - bdr/src/app/layout.tsx
   - bdr/src/app/page.tsx
@@ -619,6 +622,28 @@ would be cached by browsers and crawlers and become painful to undo.
 
 ## Gotchas
 
+- **⚠ An `import` added without the matching `package.json` dependency only fails in Amplify —
+  never locally.** Root cause of the 2026-09-10 build break: PR #5 (`blox-talos-bdr-update`,
+  TRUE-81447) added
+  `import { TalosPanel } from "@agilant/toga-blox/dist/components/Talos/index.js"` to
+  `src/components/TalosDrawer.tsx` but **never added `@agilant/toga-blox` to `package.json`**.
+  The author's `node_modules` already had it (linked or left over from an earlier install), so
+  local `next build` was green; Amplify installs from the lockfile into a clean tree and failed
+  with `Module not found`. **Before merging any PR that adds a new bare import, grep the new
+  import specifiers against `package.json`** — a green local build proves nothing about a clean
+  install. The `local-link` workflow states the same trap from the blox side: "a link masks
+  missing dependency + peer declarations."
+- **BDR's blox dependency set (as fixed 2026-09-10):** `@agilant/toga-blox@1.1.2-production.144`
+  (pinned exactly, from the `production` dist-tag), plus
+  `@fortawesome/fontawesome-svg-core@^7.3.1` and `@fortawesome/react-fontawesome@^3.5.0`, plus a
+  new `bdr/.npmrc`. Verified: clean install exit 0, `next build` compiled, **385/385 tests pass**.
+  The `.npmrc` needs the **FontAwesome Pro** registry line and `legacy-peer-deps=true` — blox is a
+  **public** package needing no token, and blox peers still cap React at `^18` while BDR runs
+  React 19. Full detail:
+  [dynamic-publish-pipeline.md](../../toga-blox/workflows/dynamic-publish-pipeline.md#consuming-blox-which-registry-actually-needs-a-token).
+  **Never commit the token value** — a live one was pushed in `bdr` commit `88809c3`; treat it as
+  compromised and rotate.
+
 - **"The funnel is gone / a CRM link doesn't prefill" — check the redirect FIRST.** Since
   2026-08-24 `/` 307s to `/landing`, so every symptom that used to mean "missing env" or
   "rate-limit soft-degrade" can now simply mean the request never reached `page.tsx`. Probe
@@ -754,6 +779,14 @@ would be cached by browsers and crawlers and become painful to undo.
   harness; pull it with `npx toga-ai`.
 
 ## Change history
+- 2026-09-10 — **Fixed the Amplify `Module not found` build break** and recorded its durable
+  lesson: PR #5 added a `@agilant/toga-blox` import to `TalosDrawer.tsx` without adding the
+  package to `package.json`, so it built locally (stale `node_modules`) and failed only on
+  Amplify's clean install. Added `@agilant/toga-blox@1.1.2-production.144` +
+  `@fortawesome/fontawesome-svg-core@^7.3.1` + `@fortawesome/react-fontawesome@^3.5.0` and a
+  `bdr/.npmrc` (FontAwesome Pro registry + `legacy-peer-deps=true` for the React 19 host; blox
+  itself is public and needs no token). Verified clean install, compiled build, 385/385 tests.
+  (rgirish)
 - 2026-08-26 — Env-var accounting only: recorded an **optional 8th deploy var**,
   `TOGA_SECURITY_CAMPAIGN_UUID`, declared in `.env.example` and deliberately **left unset**.
   It gates `/landing`'s new real callback route (`POST /api/landing-call`), which 503s and

package/knowledge/2.0/apps/toga-blox/workflows/dynamic-publish-pipeline.md

@@ -6,12 +6,14 @@ project: TOGa Blox
 client: shared
 type: workflow
 status: active
-updated: 2026-09-02
-owners: [jcardinal, apeterson, tcox]
+updated: 2026-09-10
+owners: [jcardinal, apeterson, tcox, rgirish]
 files:
   - toga-blox/.github/workflows/publish.yml
   - toga-blox/package.json
   - toga-blox/src/utils/getFontAwesomeIcon.tsx
+  - bdr/.npmrc
+  - toga25-supply/.npmrc
 related:
   - ../architecture.md
   - ./landing-a-large-feature-branch.md
@@ -83,6 +85,50 @@ blox channel. A channel exists **only** when this repo (`toga-blox-npm`) publish
 This publish-before-build ordering is the ongoing cost of the strict 1:1 model: every
 environment needs its own maintained `_<mode>` branch in `toga-blox-npm`.
 
+## Consuming blox: which registry actually needs a token
+
+**`@agilant/toga-blox` is a PUBLIC npm package. It needs NO auth.** Verified 2026-09-10 by an
+unauthenticated request:
+
+```
+curl -s -o /dev/null -w '%{http_code}' https://registry.npmjs.org/@agilant%2Ftoga-blox
+# 200
+```
+
+The team had been copying an `.npmrc` carrying **two** tokens into each consumer, believing the
+`@agilant` scope was private. It is not. Only **one** credential is real:
+
+| Registry | Auth needed? | Why |
+|---|---|---|
+| `registry.npmjs.org` (`@agilant/toga-blox`) | **No** | Public package, HTTP 200 unauthenticated |
+| `npm.fontawesome.com` (`@fortawesome/pro-*`) | **Yes** | Paid/private packages |
+
+**FontAwesome Pro is the only thing the token is for.** blox's `src/utils/getFontAwesomeIcon.tsx`
+hard-imports `@fortawesome/pro-solid-svg-icons`, `pro-regular-svg-icons` and
+`pro-light-svg-icons`, so any consumer of blox pulls the Pro registry transitively. Proven by
+isolating `HOME` to an empty dir and installing: the failure is **E401 on `npm.fontawesome.com`
+tarballs only** — never on the `@agilant` scope.
+
+Practical consequence: a consumer's `.npmrc` needs the FontAwesome registry line + token and
+`legacy-peer-deps=true`. It does **not** need an `@agilant:registry` line or an npmjs token.
+
+### `legacy-peer-deps=true` is required on a React 19 host
+
+blox `peerDependencies` still declare React `^18`. A React 19 consumer (e.g. the `bdr` Next.js
+app) cannot resolve the install without `legacy-peer-deps=true` in `.npmrc`. The peer range is a
+declaration, not a runtime wall — blox runs fine on React 19 (see
+[local-link-into-a-consumer-app.md](./local-link-into-a-consumer-app.md) §2).
+
+### ⚠ Never commit a token VALUE in `.npmrc`
+
+Live FontAwesome tokens have been found **committed** in `toga25-supply/.npmrc` and
+`info/.npmrc`, and one was pushed in `bdr` commit `88809c3`. Treat every token found this way as
+compromised and rotate it. The correct shape is an env-var placeholder resolved at build time —
+which is exactly what blox's own `publish.yml` already does (see the "Secret hygiene done right"
+gotcha below). This is the same violation already recorded in
+[`../../../standards/frontend.md`](../../../standards/frontend.md); what is **new here is that
+only the FontAwesome token was ever needed** — the npmjs token in those files bought nothing.
+
 ## Gotchas
 
 - **⚠ There is a STALE UNDERSCORED dist-tag on the registry — `_sandbox-client` (with the
@@ -212,6 +258,15 @@ environment needs its own maintained `_<mode>` branch in `toga-blox-npm`.
   you push to a release branch.
 
 ## Change history
+- 2026-09-10 — **Corrected a long-standing team assumption: `@agilant/toga-blox` is a PUBLIC npm
+  package and needs no auth** (verified by unauthenticated `curl` → HTTP 200). The only registry
+  that requires a token is **FontAwesome Pro** (`npm.fontawesome.com`), pulled in transitively
+  because `getFontAwesomeIcon.tsx` hard-imports the `@fortawesome/pro-*` packages — proven by
+  isolating `HOME` and observing E401 on FontAwesome tarballs only. Consumers had been copying an
+  `.npmrc` with both tokens; the npmjs one was never needed. Also recorded that
+  `legacy-peer-deps=true` is required on a React 19 host (blox peers still cap at `^18`), and that
+  live tokens were found committed in `toga25-supply/.npmrc`, `info/.npmrc` and pushed in `bdr`
+  `88809c3` — rotate and replace with a build-time env-var placeholder. (rgirish)
 - 2026-09-02 — Released `1.1.2-sandbox-client.142` (base `1.1.0` → `1.1.1` on `_sandbox-client`,
   commit `543a7186`) and rolled it into `toga25-supply` (pin `1.1.1-sandbox-client.140` →
   `1.1.2-sandbox-client.142`, clean `npm install`, `tsc --noEmit` zero errors). The documented

package/knowledge/2.0/apps/worker2/features/clickup-task-fluffer-talos.md

@@ -6,8 +6,8 @@ project: Worker
 client: shared
 type: feature
 status: active
-updated: 2026-07-20
-owners: [rgirish]
+updated: 2026-09-10
+owners: [rgirish, jcardinal]
 files:
   - worker2/Worker/Clickup/Fluffer.php
   - worker2/Worker/Clickup.php
@@ -121,6 +121,14 @@ never by value.
 
 ## Gotchas / known issues
 
+- **⚠ OPEN (found 2026-09-10, NOT fixed): the Talos agent call is failing in prod with HTTP 403.**
+  `Clickup/Fluffer/Process` failed **168 times over 7 days** with `Talos agent returned HTTP 403` — an
+  auth/permission failure on the `POST /api/ai/agent` call (`callTalosAgent()`,
+  `worker2/Worker/Clickup/Fluffer.php` ~L230, from `Process()` ~L94). 403 points at a bad/expired
+  `[talos] agent_api_key` (the `dev-core`-scoped key sent as `X-API-Key`) or the agent bridge revoking
+  it — **not** a ClickUp problem. Left unfixed by the developer for now; recorded so the next triage
+  starts from "check the `agent_api_key` / agent-bridge auth", not from the code. Surfaced by the
+  `Core.WorkerJobs` action+outcome census (group by action, isSuccess over 7 days).
 - **Watchdog race.** The fluffer is an **ACTION** job; its watchdog is the Lambda env
   `MAX_EXECUTION_TIME_WORKER_ACTION` (default 300s). The Talos timeout is set to **280** (just
   under 300) so the job doesn't lose the race against its own watchdog out of the box.
@@ -144,6 +152,11 @@ never by value.
 
 ## Change history
 
+- 2026-09-10 — **Discovered (NOT fixed): the fluffer is down in prod on a Talos-agent HTTP 403.**
+  `Clickup/Fluffer/Process` failed 168x over 7 days with `Talos agent returned HTTP 403` — an
+  auth/permission failure on the `/api/ai/agent` call, most likely an expired/wrong `[talos]
+  agent_api_key`. Deferred by the developer; logged as an open known issue for the next triage. Found
+  via the `Core.WorkerJobs` action+outcome census (toga-db MCP, no ClickUp/Talos access). (jcardinal)
 - 2026-07-20 — Built the ClickUp task description fluffer: new `_Worker_Clickup_Fluffer`
   (action `Clickup/Fluffer/Process`, `taskCreated` webhook auto-trigger, `force` regenerate)
   calling the Talos `dev-core` KB-investigation agent at `/api/ai/agent` via `_ApiRequest`

package/knowledge/2.0/apps/worker2/features/creating-worker-actions.md

@@ -6,13 +6,15 @@ project: Worker
 client: shared
 type: feature
 status: active
-updated: 2026-09-02
-owners: [jcardinal, dfranks, mhammontree, tcox, bala, ajean]
+updated: 2026-09-10
+owners: [jcardinal, dfranks, mhammontree, tcox, bala, ajean, rgirish]
 files:
   - worker2/Worker/
   - worker2/Controller/Index.php
   - worker2/LambdaFunctions/JobScheduler/lambda_function.py
   - _underscore/Worker.php
+  - worker2/Worker/Infrastructure/Database.php
+  - worker2/.platform/hooks/prebuild/020-install-mysql-client.sh
 related:
   - ../architecture.md
   - ./netsuite-opportunity-client-labels.md
@@ -190,6 +192,40 @@ The EB worker dispatcher (`Controller/Index.php::worker()`) wraps your action ca
 > It now captures **both** success results and failure text. See
 > [architecture.md](../architecture.md) for the multi-producer rename gotcha.
 
+### ⚠ A `null` return is logged as SUCCESS — "it ran green" is not evidence it did anything
+
+`Controller/Index.php:378` records `isSuccess = 1` for **any** normal return, including `null`.
+The framework has no notion of "the action did no work": an action that silently does nothing —
+or is an unfinished stub — produces a clean `WorkerJobs` row indistinguishable from a real run.
+
+Live example: **`_Worker_Infrastructure_Database::Backup()`
+(`worker2/Worker/Infrastructure/Database.php:5-15`) is a stub.** It sends a test email to a
+hardcoded address and returns `null`. Every invocation is logged as a **successful database
+backup**. Nothing is backed up.
+
+Two rules follow:
+
+1. **When you write an action, return something that proves the work happened** — a count, an
+   id list, a summary string. `return null;` on a work-performing action throws away the only
+   signal the dispatcher records.
+2. **When you audit an action, never accept a green `WorkerJobs` row as proof.** Read the
+   `output` column, and read the method. This applies to anything safety-critical (backups,
+   reconciliations, syncs) where "it's been green for months" is the expected — and worthless —
+   observation.
+
+Two related defects found in the same audit, both worth knowing before you build on this
+infrastructure:
+
+- **`_underscore/Cloud.php:49` `copyFileToS3` is a single `putObject`**, so it cannot upload
+  anything over S3's **5 GB** single-PUT cap, and there is no `MultipartUploader` anywhere in
+  `_underscore` or `worker2` — see
+  [_Cloud S3 helpers](../../_underscore/features/cloud-s3-helpers.md).
+- **`worker2/.platform/hooks/prebuild/020-install-mysql-client.sh` installs the WRONG client for
+  Aurora MySQL 3.** It installs **`mariadb105`**, whose `mysqldump` has no `--set-gtid-purged`
+  flag and emits MariaDB-versioned `/*!100xxx*/` conditional comments — comments that MySQL
+  silently **ignores on reload**, so parts of the dump vanish without any error. Any dump-based
+  work on this host needs the **MySQL** client (`mysql-community-client`), not the MariaDB one.
+
 Crucially, the worker **always returns HTTP 200, even on a throw**, so SQS deletes the message
 immediately. **There is no DLQ and no automatic retry.** A throw makes the failure *visible* (a
 failed `WorkerJobs` row to alert on) — it does **not** re-run the job.
@@ -464,6 +500,18 @@ Rules: rename **both sides in one PR and one deploy**; grep every repo for the o
   commit-before-SQS transaction pattern that the worker relies on.
 
 ## Change history
+- 2026-09-10 — Recorded that **a `null` return is stamped `isSuccess = 1`**
+  (`Controller/Index.php:378`), so an action that does nothing is logged as a successful run —
+  with the live proof that `_Worker_Infrastructure_Database::Backup()`
+  (`Worker/Infrastructure/Database.php:5-15`) is a stub that emails a hardcoded address, returns
+  `null`, and has therefore been reporting successful database backups while backing up nothing.
+  Added the two rules: return a proof-of-work value from every action, and never treat a green
+  `WorkerJobs` row as evidence for a safety-critical job. Also recorded two neighbouring defects
+  found in the same audit: `_Cloud::copyFileToS3` is a single `putObject` (5 GB ceiling, no
+  `MultipartUploader` in the codebase), and the EB prebuild hook
+  `020-install-mysql-client.sh` installs **`mariadb105`**, whose `mysqldump` lacks
+  `--set-gtid-purged` and writes `/*!100xxx*/` comments that MySQL silently drops on reload —
+  the wrong client for Aurora MySQL 3. (rgirish)
 - 2026-09-02 — Added the corollary that an action must **never sleep-wait for a third-party API
   rate budget** (it burns the 300s cap and the failure is unrecoverable — no retry, no DLQ); bulk
   work yields and re-enqueues, event-driven work proceeds over budget counted and alarmed. (ajean)

package/knowledge/2.0/apps/worker2/features/netsuite-opportunity-sync.md

@@ -6,8 +6,8 @@ project: Worker
 client: shared
 type: feature
 status: active
-updated: 2026-09-04
-owners: ["dfranks", "kyalamarthi", "ajean"]
+updated: 2026-09-10
+owners: ["dfranks", "kyalamarthi", "ajean", "jcardinal"]
 files:
   - worker2/Worker/Netsuite.php
   - worker2/Worker/Netsuite/Opportunity.php
@@ -387,6 +387,22 @@ the legacy cron's OPPORTUNITIES section:
   (`hasEndCustomerColumn()`), since the migration is applied by hand and an unknown column would fail
   the whole query and break every opportunity webhook. See
   [the labels doc](./netsuite-opportunity-client-labels.md).
+  - **⚠ `hasEndCustomerColumn()` guards the DB COLUMN, NOT the ORM MODEL field — and that gap took the
+    whole opportunity sync down for 8 days (2026-09-02 → 2026-09-10).** The guard does a `SHOW COLUMNS`
+    on `Forecast.Opportunities`, so once the migration was applied it passed and the handler ran
+    `$opportunity->endCustomerName = …`. But the 2.0 model `_Model_Forecast_Opportunity`
+    (`_underscore/Model/Forecast/Opportunity.php`) never **declared** the field, so `_Model.__set`
+    (`_underscore/Model.php`) threw *"There is no field called 'endCustomerName' in the
+    '_Model_Forecast_Opportunity' model."* on **every** `Netsuite/Opportunity/post|put` — 100% failure,
+    every opportunity import dead. `Core.WorkerJobs` census: Sep 1 = 115 ok / 60 fail (last good day),
+    Sep 2 → Sep 10 = 0 ok / 100% fail (61 fails on Sep 10 alone). This was a **half-deploy**: the
+    migration + the handler write shipped, the model field declaration did not.
+    **Durable rule: a new column that the handler writes must ship THREE things together — the
+    `dbchanges2` migration, the handler write, AND the `_Model` field declaration.** A column-existence
+    guard (`SHOW COLUMNS`) proves nothing about the ORM; both ORMs enumerate *declared* properties, so an
+    undeclared field is a hard `__set` throw, not a silent skip. Fixed 2026-09-10 by declaring
+    `public $endCustomerName = self::FIELD_CHAR;` (matching sibling char fields clickupTaskId/title/memo
+    over the varchar column); deployed to worker2 `_production`, sync recovered.
 - Writes use raw `_Query` against `_underscore::DB_FORECAST` and **must**
   `_Database::transactionCommit(DB_FORECAST)` (lazy-transaction gotcha).
 
@@ -759,6 +775,19 @@ deprecated** for production opportunity code.
   blocked on the Aaron stakeholder decision noted above.
 
 ## Change history
+- 2026-09-10 — **Fixed an 8-day total opportunity-sync outage caused by a half-deploy: a missing ORM
+  model field.** `Forecast.Opportunities.endCustomerName` (column added ~Sep 1) and the worker2 handler
+  write shipped, but `_Model_Forecast_Opportunity` (`_underscore/Model/Forecast/Opportunity.php`) never
+  **declared** the field. `hasEndCustomerColumn()` guards the DB column (`SHOW COLUMNS`), not the ORM
+  model, so the guard passed and `_Model.__set` then threw *"There is no field called 'endCustomerName'
+  in the '_Model_Forecast_Opportunity' model."* on **every** `Netsuite/Opportunity/post|put` —
+  `Core.WorkerJobs` shows Sep 1 = 115 ok / 60 fail (last good day), Sep 2 → Sep 10 = 0 ok / 100% fail.
+  Fix: declared `public $endCustomerName = self::FIELD_CHAR;` (php-reviewer clean); deployed to worker2
+  `_production`, sync recovered. Durable lesson added to the `endCustomerName` data-model bullet: a
+  handler-written column must ship its migration, its handler write, AND its `_Model` field declaration
+  together — a `SHOW COLUMNS` guard does not protect against a missing ORM field. Diagnosed with only the
+  `Core.WorkerJobs` action+outcome census (group by action, isSuccess over 7 days) via the toga-db MCP —
+  no NetSuite/ClickUp access. (jcardinal)
 - 2026-09-04 — **Investigation + design session; no code shipped (two prototype fixes were written and
   deliberately reverted).** Four corrections and four new facts. **Corrected:** the `STAGE_MAP`
   section described a constant that does not exist — the shipped map is **`SALES_STAGE_MAP`** on

package/knowledge/INDEX.md

@@ -18,10 +18,10 @@ _Auto-generated by `knowledge.js index`. Do not hand-edit._
 
 ## 2.0 framework
 
-- **_underscore** (_Underscore) _(framework core)_ — 82 doc(s) → [2.0/apps/_underscore/INDEX.md](2.0/apps/_underscore/INDEX.md)
+- **_underscore** (_Underscore) _(framework core)_ — 83 doc(s) → [2.0/apps/_underscore/INDEX.md](2.0/apps/_underscore/INDEX.md)
 - **worker2** (Worker) — 68 doc(s) → [2.0/apps/worker2/INDEX.md](2.0/apps/worker2/INDEX.md)
 - **api2** (API) — 25 doc(s) → [2.0/apps/api2/INDEX.md](2.0/apps/api2/INDEX.md)
-- **dbchanges2** (Database Changes) _(framework core)_ — 17 doc(s) → [2.0/apps/dbchanges2/INDEX.md](2.0/apps/dbchanges2/INDEX.md)
+- **dbchanges2** (Database Changes) _(framework core)_ — 18 doc(s) → [2.0/apps/dbchanges2/INDEX.md](2.0/apps/dbchanges2/INDEX.md)
 - **toga2-supply** (TOGa Supply) — 9 doc(s) → [2.0/apps/toga2-supply/INDEX.md](2.0/apps/toga2-supply/INDEX.md)
 - **saml** (SAML SSO Gateway) — 6 doc(s) → [2.0/apps/saml/INDEX.md](2.0/apps/saml/INDEX.md)
 - **toga2-view** (TOGa View Frontend) — 12 doc(s) → [2.0/apps/toga2-view/INDEX.md](2.0/apps/toga2-view/INDEX.md)

package/knowledge/clients/prudential/INDEX.md

@@ -5,6 +5,7 @@
 | [Prudential: Dell ASN units PRE/POST interceptor (legacy key + flat tracking)](features/dell-asn-units-interceptor.md) | 2.0 | After the tracking-number bridge migration, the ASN unit route was renamed (`advance-shipping-notice-units` → `advance-shipping-notice-item-units`), so the inhe |
 | [Prudential: Dell LCH IOP transmissions (LCHRequestV2)](features/dell-lch-iop-transmissions.md) | 1.0 | Outbound order transmissions from the 1.0 worker tier to Dell's Lifecycle Hub (LCH) ITSM integration. |
 | [Prudential: Device information import + unit→contact linking (import_device_information.php)](features/device-information-import-and-contact-linking.md) | 1.0 | Prudential's **device-sync** cron (`worker/crons/toga2/prudential/import_device_information.php`) pulls device/asset records (from ServiceNow / the Dell CMDB fe |
+| [Prudential: ItemClasses device-tier data is dead (and how that was proved)](features/itemclasses-device-tier-data.md) | 2.0 | `Client_Prudential.ItemClasses` held 7 hand-seeded Dell/Apple **device tiers** ("LATITUDE 73xx", "MACBOOK PRO", …) tagged onto **9 of 765** items. |
 | [Prudential: OneUptime order-pipeline backlog monitors (Monitor/Prudential/*)](features/oneuptime-order-pipeline-monitors.md) | 2.0 | Three worker2 OneUptime push monitors (TRUE-80587) that watch the Prudential/Dell order pipeline for **stalls**, which were previously invisible — a stuck pipel |
 | [Prudential: order email PDF attachments (which guide goes on which email)](features/order-email-pdf-attachments.md) | 1.0 | Every customer-facing Prudential order email carries S3-hosted PDF guides, and **which** guide is attached is decided by the service request type. |
 | [Prudential: Service Request Regional Address Validation](features/service-request-address-validation.md) | 2.0 | The `prePost` interceptor on `_Model_Prudential_ServiceRequest` validates `deliverToAddress` fields differently depending on which Prudential regional customer |

package/knowledge/clients/prudential/features/itemclasses-device-tier-data.md

@@ -0,0 +1,108 @@
+---
+title: "Prudential: ItemClasses device-tier data is dead (and how that was proved)"
+framework: "2.0"
+repo: dbchanges2
+project: Database Changes
+client: prudential
+type: client-feature
+status: active
+updated: 2026-09-11
+owners: ["rgirish"]
+files:
+  - dbchanges2/Client_Prudential/2024-01-01.sql
+  - dbchanges2/Client_Prudential/2026-09-11 - ClearItemClasses.sql
+  - worker/crons/toga2/prudential/transmissions_to_netsuite.php
+  - worker/schedules/cron.worker.sync.json
+related:
+  - ../profile.md
+  - ../../../2.0/apps/_underscore/features/item-classification-itemclasses.md
+  - ../../../2.0/apps/_underscore/features/record-change-audit-log.md
+  - ../../../1.0/apps/worker/workflows/tracing-a-worker-cron-run-in-production.md
+---
+
+## Summary
+
+`Client_Prudential.ItemClasses` held 7 hand-seeded Dell/Apple **device tiers**
+("LATITUDE 73xx", "MACBOOK PRO", …) tagged onto **9 of 765** items. The data was seeded once by
+SQL in 2023, never maintained, is partly wrong, and **nothing reads or writes it today**. It was
+cleared on 2026-09-11 to free the table for real NetSuite item classification later.
+
+The second half of this doc is the **4-source method used to prove "this field is dead"** —
+reusable for any field on any client.
+
+## How it works (what the data was)
+
+Source is a hardcoded seed block in `dbchanges2/Client_Prudential/2024-01-01.sql:435-449`:
+7 `INSERT INTO ItemClasses`, then a per-`partNumber` `UPDATE` stamping `Items.itemClassId`.
+**No API, no external feed, no sync.** That is the entire origin.
+
+The one consumer was `worker/crons/toga2/prudential/transmissions_to_netsuite.php:171-178`,
+which sent `ItemClasses.name` to NetSuite as `deviceTier`.
+
+## Proving a field is dead — the 4-source method
+
+Run all four. Any one alone is weak; together they are conclusive.
+
+**1. Grep for readers and writers in every repo.**
+One reader (`transmissions_to_netsuite.php`), zero writers in `api2`, `worker2`, `_underscore`.
+Watch for frontend grep noise — `itemClass` matches CSS variable names like `menuItemClassNames`.
+
+**2. Check the field-change audit log — absence is evidence.**
+Resolve the field id first (`Logs_*` and `Core` are on different clusters, so this is two
+queries — see [Record Change Audit Log](../../../2.0/apps/_underscore/features/record-change-audit-log.md)):
+
+- `Core.RecordFields` id **605** = `Items.itemClassId`; `Core.Records` id **21** = `Items`,
+  id **105** = `ItemClasses`.
+- `Logs_Prudential.RecordField` has **zero rows** for field 605, ever. Zero log rows on record 105.
+
+**Prove the logging itself works, or "no rows" means nothing.** Item logging is demonstrably
+live: 1,963 log rows across 353 items, current through today, tracking `partNumber`,
+`description`, `isFulfillable`, `catalogId`. So `itemClassId` simply never changes.
+
+**3. Scan the inbound API payloads.**
+Zero of **3,808** `/v2/items` calls in September carried an `itemClass` key. Items arrive from a
+NetSuite sync cron — `POST /v2/items` from `34.214.204.95` (`apiId` 5) — with payload shape
+`{partNumber, description, inventoryType, catalog:{name}, c_netsuiteInternalItemId, isFulfillable}`.
+**No `itemClass` field.** That is why new items never get a class, and why only 9 of 765 are tagged.
+
+**4. Check the consumer cron's `active` flag, then `git log` it.**
+`worker/schedules/cron.worker.sync.json:441` — `"active": 0` on "Transmissions to Netsuite".
+Disabled **2026-07-17** by Jeff Cardinal, commit `14570def` ("Add careOf & skip Apple; disable
+Netsuite cron"), branch `_production`. See
+[tracing a worker cron run](../../../1.0/apps/worker/workflows/tracing-a-worker-cron-run-in-production.md)
+for the `active`-flag semantics.
+
+## Gotchas
+
+- **⚠ The surviving tags were partly wrong.** 2 of the 9: item 3512 (`MRW23XX/A`,
+  "MacBook Pro 16 M3") was tagged **MACBOOK AIR**; item 3513 (`920-008219`, a Logitech keyboard)
+  was tagged **MACBOOK PRO**. Stale hand-seeded lookup data degrades silently — do not trust it
+  because it exists.
+- **Clear the FK before the parent rows.** `Items_itemClassId` is the only FK referencing
+  `ItemClasses` (verified via `information_schema.KEY_COLUMN_USAGE` on `Client_Prudential`), so
+  the null-out of `Items.itemClassId` must run **before** the parent rows are removed.
+- **Northwell was NOT touched.** Its 27 ServiceNow service categories and 245 tagged items are
+  still live. Open question, not yet decided: whether to move Northwell's rows to a separate
+  table if `ItemClasses` gets repurposed org-wide.
+
+## The migration
+
+`dbchanges2/Client_Prudential/2026-09-11 - ClearItemClasses.sql` — data removal only, re-runnable,
+table and columns untouched. Two statements: null out every non-null `Items.itemClassId`, then
+empty `ItemClasses`. Order matters (see the FK gotcha above).
+
+**Deliberately scoped small.** Adding the NetSuite classification columns
+(`c_netsuiteInternalClassificationId`, `c_netsuiteFullName`, `c_netsuiteParentId`), dropping the
+UNIQUE on `name`, and registering the `CustomRecordFields` rows for `recordId` 105 is a
+**separate later task**. The traps already found for it are recorded in
+[ItemClasses / _Model_Client_ItemClass](../../../2.0/apps/_underscore/features/item-classification-itemclasses.md).
+
+## Change history
+- 2026-09-11 — Cleared the 7 stale device-tier rows and the 9 item tags via
+  `2026-09-11 - ClearItemClasses.sql` (null the FK first — `Items_itemClassId` is the only FK).
+  Documented the 4-source proof that the data was dead: one reader / zero writers,
+  zero `Logs_Prudential.RecordField` rows for `Core.RecordFields` id 605 against 1,963 live rows
+  on other Item fields, zero of 3,808 September `/v2/items` payloads carrying `itemClass`, and the
+  sole consumer cron `"active": 0` since 2026-07-17 (commit `14570def`). Also recorded that 2 of
+  the 9 surviving tags were plainly wrong. Column additions deliberately deferred to a later task.
+  (rgirish)

package/knowledge/clients/prudential/features/transmit-ordershipped-email.md

@@ -6,7 +6,7 @@ project: Worker
 client: prudential
 type: client-feature
 status: active
-updated: 2026-08-31
+updated: 2026-09-11
 owners: ["rgirish", "bala"]
 files:
   - worker/crons/toga2/prudential/transmit_ordershipped_updates_prudential.php
@@ -86,20 +86,26 @@ TrackingNumbers WHERE purchaseOrderId = PurchaseOrders.id AND TrackingNumbers.st
 orders that genuinely qualified for a delivery email. Over 2026-07-01..07-09 this dropped 6 false
 positives (25 → 19 flagged) while retaining all 19 genuine discrepancies.
 
-## A second cron sends the same shipped email
+## A second cron sends the same shipped email — but it is DISABLED (corrected 2026-09-11)
 
-`transmissions_to_netsuite.php` (also `active: 1`) builds and sends the **same** shipped email —
-same subjects, same branch shape — and also stamps `c_dtTransmittedOrderShippedUpdateToPrudential`.
-It is easy to miss: it is not named like the other `transmit_*` crons. Any change to the shipped
-email's content or attachments must be applied to **both** files or the two senders drift.
+`transmissions_to_netsuite.php` builds and sends the **same** shipped email — same subjects, same
+branch shape — and also stamps `c_dtTransmittedOrderShippedUpdateToPrudential`. It is easy to
+miss: it is not named like the other `transmit_*` crons. Any change to the shipped email's content
+or attachments must be applied to **both** files or the two senders drift.
+
+> **⚠ It is `"active": 0`, not `active: 1` as this page said until 2026-09-11.**
+> `worker/schedules/cron.worker.sync.json:441` — disabled **2026-07-17** by Jeff Cardinal, commit
+> `14570def` ("Add careOf & skip Apple; disable Netsuite cron") on `_production`. So **it has not
+> been sending anything since then**, and it is not currently a live duplicate sender. Keep the
+> two files in sync anyway — it can be switched back on with one flag.
 
 **And it does not stop at the shipped email — it also sends the two *delivered* emails.**
 `transmissions_to_netsuite.php` carries "Prudential: New hire equipment has been delivered"
 (~L1765) and "Prudential: Your equipment has been delivered" (~L2149), the **same two subjects**
 that `transmit_closecomplete_updates_prudential.php` sends — except the `transmissions_to_netsuite`
-versions make **no `addAttachment()` calls at all**. Whether both crons fire for the same order was
-not established (2026-08-31); if they do, the customer receives a duplicate delivered email, one
-copy of which is missing the guides. Establish this before touching either delivered path.
+versions make **no `addAttachment()` calls at all**. The open question from 2026-08-31 — whether
+both crons fire for the same order and send a duplicate delivered email — is **moot while this
+cron is off** (see the box above). It becomes live again the moment anyone sets `"active": 1`.
 
 It was also the last Prudential cron still calling `file_get_contents()` directly for its PDFs and
 calling `addAttachment()` unconditionally — so a failed S3 pull threw and killed the batch, and a
@@ -201,6 +207,10 @@ stamp (crash hits the next iteration). With multiple New-type POs, a crash on PO
 all subsequent POs in the same run.
 
 ## Change history
+- 2026-09-11 — **Correction: `transmissions_to_netsuite.php` is `"active": 0`, not `active: 1`.**
+  Disabled 2026-07-17 (commit `14570def`) in `cron.worker.sync.json:441`, so the "second shipped
+  sender" and the suspected duplicate *delivered* email are dormant, not live. Found while
+  auditing that cron as the only reader of `ItemClasses`. (rgirish)
 - 2026-08-31 — TRUE-81393 / PR #1707 (merged to `_production`): the shipped email's
   `$attachmentText` paragraph was unconditional while each attach was guarded, so a failed S3 pull
   produced copy promising guides that were not attached — and it said "guides" even for a single

package/knowledge/clients/prudential/profile.md

@@ -15,7 +15,7 @@ project: _Underscore
 client: prudential
 type: profile
 status: active
-updated: 2026-09-10
+updated: 2026-09-11
 owners: ["jcardinal", "rgirish", "bala", "mhammontree"]
 files: []
 related:
@@ -31,6 +31,7 @@ related:
   where each code is logged, and how to tell "we refused it" from "they never sent it".
 - features/supply-orders-csv-export.md
   - features/order-email-pdf-attachments.md
+  - features/itemclasses-device-tier-data.md
 ---
 
 ## Summary

package/package.json

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