toga-ai 1.0.795 → 1.0.797

package/knowledge/2.0/apps/_underscore/features/calculated-sql-fields.md

@@ -20,6 +20,8 @@ files:
   - api2/Component/Api/V2/V2.php
   - _underscore/Model/Quad/Item.php
   - _underscore/Model/Quad/VendorItem.php
+  - _underscore/Model/Nychh/Unit.php
+  - dbchanges2/Client_Nychh/2026-09-10a - UnitsForPoTableViewRebaseAndTransferLocationField.sql
   - dbchanges2/Client/2026-08-11b - SalesOrderPurchaseOrdersField.sql
   - dbchanges2/Client/2026-08-25 - SalesOrderPurchaseOrdersFieldAllClients.sql
 related:
@@ -253,6 +255,23 @@ characters — that is the standard of evidence for touching a field that runs o
   [save-cascade stored-field deadlocks](./model-save-parent-cascade-stored-field-deadlock.md).
 
 ## Change history
+- 2026-09-10 — Added two NYCHH-only calc fields on `_Model_Nychh_Unit`
+  (`_underscore/Model/Nychh/Unit.php`) for the rebuilt `units-for-items-for-purchase-orders` grid,
+  both plain `FIELD_SQL` (text — no `FIELDOPT_SQL_TYPE`): **(a)** an **override** of
+  `_unitDisposition()` — NYCHH does **not** use the `UnitDispositions` lookup; disposition is derived
+  purely from the transfer chain (`Deployed` if an `ItemFulfillmentItems` with
+  `transferOrderItemId IS NOT NULL` exists for the unit, else `Available`). The override **matches the
+  parent's untyped signature exactly** (the contravariance fatal above). **(b)** a **new**
+  `_transferLocation` field returning the transfer-order destination location name via
+  Units → ItemFulfillmentItemUnits → ItemFulfillmentItems → TransferOrderItems → TransferOrders →
+  destinationLocationId → Locations (`ORDER BY` fulfillment id `DESC LIMIT 1`), registered as a
+  `Client_Nychh.CustomRecordFields` row (record 31) + Base-role `AclCustomFieldPermissions` grant in
+  `Client_Nychh/2026-09-10a`. **Why a calc field and not a TableView join:** the location chain
+  re-uses `ItemFulfillmentItems`/`ItemFulfillmentItemUnits` a **second** time, and `TableViewJoins`'
+  `onB` renders the raw table name — so a chain off a duplicated table binds to the wrong copy (the
+  duplicate-join hazard in [tableview-joins](./tableview-joins.md)). A calc field sidesteps the alias
+  problem entirely. Column header labeled via a `ClientCustomRecordFieldSettings` `label-singular`
+  row ("Location"). (jcardinal)
 - 2026-09-10 — **Fixed `_Model_Client_Location::_addressState()` to return the state CODE, not
   `Addresses.stateId`** (addresses rendered as `Bronx, 33 10451-5504`). Added
   `LEFT JOIN States ON States.id = Addresses.stateId` inside the subquery and selected `States.code`

package/knowledge/2.0/apps/_underscore/features/page-meta-context-field-settings.md

@@ -6,8 +6,8 @@ project: _Underscore
 client: shared
 type: feature
 status: active
-updated: 2026-08-26
-owners: [tcox, bala]
+updated: 2026-09-10
+owners: [tcox, bala, jcardinal]
 files:
   - _underscore/Model/Core/Page.php
   - _underscore/Model/Client/TableView.php
@@ -64,6 +64,19 @@ record route resolved through `$lookupRecordIdFromCustomRecordFieldId` →
 metadata**, and no amount of adding/correcting those rows will move the header. (Measured
 2026-08-26: two hours lost adding label rows that could never be read.)
 
+> **⚠ SCOPE — this "dead metadata" is the legacy `Page.php` / `toga2-supply` path ONLY. On the
+> `toga25-supply` table path it WORKS.** `toga25-supply` reads its grid headers from
+> `/table-views/meta` (`_Model_Client_TableView::meta()`), which fetches
+> `ClientCustomRecordFieldSettings` directly — so a **base** custom-field column (both context
+> columns NULL) IS labeled by a `ClientCustomRecordFieldSettings` row with `settingId = 5`
+> (`Core.Settings.slug = 'label-singular'`), `isOverridable = 1`. Verified live 2026-09-10: this is
+> exactly how `Client_Elite` labels its custom unit columns (`c_grade` → "Grade", `c_chargingBrick`
+> → "Charging Brick", …), and it is how NYCHH's `_transferLocation` column on
+> `units-for-items-for-purchase-orders` gets its "Location" header
+> (`Client_Nychh/2026-09-10c - TransferLocationColumnLabel.sql`). Do **not** move a custom field to
+> a Core `RecordField` just to get a header on a `toga25-supply` grid — the client custom-field
+> settings row is enough. The dead-metadata trap above still holds for the old `Page.php` consumers.
+
 Where the label must come from instead, for such a column:
 
 - **`Core.DefaultRecordFieldSettings`** on the underlying **Core** `RecordField`, or
@@ -181,6 +194,14 @@ data change, is what makes it fatal.
   customization. The guard belongs in the framework.
 
 ## Change history
+- 2026-09-10 — Scoped the "custom record field's label row is dead metadata" finding to the **legacy
+  `Page.php` / `toga2-supply`** consumer only. On the **`toga25-supply`** grid (headers from
+  `/table-views/meta` via `_Model_Client_TableView::meta()`, which fetches
+  `ClientCustomRecordFieldSettings` directly) a **base** custom-field column IS labeled by a
+  `ClientCustomRecordFieldSettings` row (both context columns NULL, `settingId = 5` =
+  `label-singular`, `isOverridable = 1`) — so the field need NOT be promoted to a Core `RecordField`
+  for a header. Verified against `Client_Elite`'s custom unit columns and NYCHH's `_transferLocation`
+  ("Location") on the units-for-items-for-purchase-orders view. (jcardinal)
 - 2026-08-26 - Documented that a grid column's **type** and its **header label** come from two
   different endpoints: type/formatting (the currency icon) from `/table-views/meta`
   `table.fields[].type` via `generateDynamicConfig` → `formatTableData`, header text from

package/knowledge/2.0/apps/_underscore/features/tableview-joins.md

@@ -6,7 +6,7 @@ project: _Underscore
 client: shared
 type: feature
 status: active
-updated: 2026-09-03
+updated: 2026-09-10
 owners: [bala, apeterson, jcardinal]
 files:
   - _underscore/Model/Client/TableView.php
@@ -19,6 +19,8 @@ files:
   - dbchanges2/Client_Nychh/2026-08-28a - TransferOrdersTableView.sql
   - dbchanges2/Client_Nychh/2026-08-31a - PurchaseOrdersTableViewRebase.sql
   - dbchanges2/Client_Nychh/2026-09-02a - PurchaseOrderItemsTableViewRebase.sql
+  - dbchanges2/Client_Nychh/2026-09-10a - UnitsForPoTableViewRebaseAndTransferLocationField.sql
+  - dbchanges2/Client_Nychh/2026-09-10b - UnitsForPoBridgeBaseAclGrant.sql
 related:
   - ../../api2/features/tableview-field-metadata.md
   - ./page-meta-context-field-settings.md
@@ -232,6 +234,29 @@ So a role gap only 500s when a **visible column** hangs off the missing join —
 client tolerates ACL gaps on records another client cannot. A new joined table (here
 `Manufacturers`, record 20) needs its `AclRecordPermissions` grant in the same migration.
 
+#### A dropped BRIDGE join in the middle of a chain 1054s even with NO column on it
+
+The "harmless until a column hangs off it" rule has a sharp exception: a **bridge** join that sits
+**in the middle of a chain**. Nothing shows a column from the bridge, but a **later** join's `onB`
+names the bridge's raw table. When ACL drops the bridge, that later join emits an ON clause
+referencing a table that was never added → **MySQL 1054**, not the readable
+`AclRecordPermissions`-message from mode (b).
+
+Confirmed NYCHH 2026-09-10 on the rebuilt `units-for-items-for-purchase-orders` view. The bridge
+record **`PurchaseOrderItems_SalesOrderItems`** (Core record **290**) carried only an **API-role**
+read grant in `Client_Nychh`. Records 30/29/15/18 in the chain already had a **Base** grant, so a
+Base user's joins query dropped only the bridge — and the next join's ON referenced it:
+
+```
+Unknown column 'PurchaseOrderItems_SalesOrderItems.purchaseOrderItemId' in 'on clause'
+```
+
+Fix: add the **Base** read grant as the full 4-table ACL chain (`AclRecordPermissions` →
+`AclLogicGroups` → `AclLogicGroupExpressions`), reusing record 290's existing `all`
+`AclRecordExpression` (`Client_Nychh/2026-09-10b - UnitsForPoBridgeBaseAclGrant.sql`). Watch for
+**bridge records that ship with API-only grants** — a view that only ever ran for an API caller
+(or in an environment tested as API) hides this until a Base user opens it.
+
 ### The debugging signature: 500 + EMPTY body + NO row in `Logs_<client>.Api`
 
 Mode (a) throws *before* the response is assembled, so the caller gets a **500 with an empty
@@ -347,6 +372,14 @@ Core-level reference ids used (identical across all clients and environments): *
 
 ## Change history
 
+- 2026-09-10 — Added the **bridge-in-a-chain ACL-drop = 1054** exception to mode (b): a dropped
+  bridge join with **no column on it** still breaks, because the next join's `onB` names the bridge's
+  raw table. NYCHH's rebuilt `units-for-items-for-purchase-orders` view 1054'd for a **Base** user —
+  bridge record 290 (`PurchaseOrderItems_SalesOrderItems`) had only an **API-role** grant while the
+  rest of the chain (30/29/15/18) had Base; error *"Unknown column
+  'PurchaseOrderItems_SalesOrderItems.purchaseOrderItemId' in 'on clause'"*. Fixed with the full
+  4-table Base ACL chain reusing record 290's `all` expression (`Client_Nychh/2026-09-10b`). Watch
+  for bridge records that ship with API-only grants. (jcardinal)
 - 2026-09-03 — Added the **filter-only join counterpart** to the PO-items rebase: dropping a
   column-less join that only *filtered* rows (SalesOrders→bridge→PurchaseOrders, ids 123/124/141)
   breaks any row-filter still targeting that table. NYCHH's `items-for-purchase-orders`

package/knowledge/2.0/apps/_underscore/features/units-for-items-for-purchase-orders.md

@@ -6,12 +6,18 @@ project: _Underscore
 client: shared
 type: feature
 status: active
-updated: 2026-08-28
-owners: ["bala", "tcox"]
+updated: 2026-09-10
+owners: ["bala", "tcox", "jcardinal"]
 files:
   - _underscore/Model/Client/ServiceRequest.php
+  - _underscore/Model/Nychh/Unit.php
   - dbchanges2/Client/2026-08-11a - ServiceRequestsInventoryUnitsTableViews.sql
+  - dbchanges2/Client_Nychh/2026-09-10a - UnitsForPoTableViewRebaseAndTransferLocationField.sql
+  - dbchanges2/Client_Nychh/2026-09-10b - UnitsForPoBridgeBaseAclGrant.sql
+  - dbchanges2/Core/2026-09-10a - InventoryGroupingsUnitsLeafPoItemFilter.sql
 related:
+  - ./calculated-sql-fields.md
+  - ./tableview-joins.md
   - ./tracking-number-bridges.md
   - ../../../clients/elite/features/supply2-tableview-config-drift.md
   - ../../../clients/prudential/features/supply-orders-csv-export.md
@@ -74,6 +80,41 @@ a *different field per client*, so client custom columns (and their
 Elite's four columns at index 14-17 (`grade`, `chargingBrick`, `chargingCable`, `wipeStatus` via
 `c_deviceStatus`).
 
+## NYCHH rebuilt the view onto the FULFILLMENT chain (2026-09-10)
+
+This is the "resolver/view change that also walks the fulfillment path" the first gotcha below asks
+for — shipped for one tenant. `Client_Nychh`'s `units-for-items-for-purchase-orders` view (base
+record **Units 31**) was rebuilt to list the serialized units for a clicked **purchase-order item**,
+showing Serial #, Asset Tag, Disposition, Location. The old 25-join / 12-column config (inaccurate)
+was replaced with an **INNER** chain:
+
+```
+Units
+  -> ItemFulfillmentItemUnits (30)
+  -> ItemFulfillmentItems (29)
+  -> PurchaseOrderItems_SalesOrderItems bridge (290)
+  -> PurchaseOrderItems (18)
+```
+
+plus a **filter-only** `SalesOrderItems (15)` join kept so the `itemsByPOs` drill path (which filters
+by `SalesOrderItems.uuid`) still works. The grid is filtered at drill-down time by
+`(PurchaseOrderItems.uuid:eq:...)`. File:
+`dbchanges2/Client_Nychh/2026-09-10a - UnitsForPoTableViewRebaseAndTransferLocationField.sql`.
+
+Two column values come from **NYCHH-only calc fields** on `_Model_Nychh_Unit`, not joins —
+Disposition (`_unitDisposition`, overridden to derive from the transfer chain) and Location
+(`_transferLocation`, new). Location is a calc field precisely because its chain re-uses
+`ItemFulfillmentItems`/`ItemFulfillmentItemUnits` a **second** time, which the TableView alias model
+cannot express (see [calculated-sql-fields](./calculated-sql-fields.md) and the duplicate-join hazard
+in [tableview-joins](./tableview-joins.md)).
+
+Two failures surfaced during this rebuild, both documented on
+[tableview-joins](./tableview-joins.md): the mid-chain bridge record 290 shipped with an **API-only**
+ACL grant, so a Base user 1054'd on `PurchaseOrderItems_SalesOrderItems.purchaseOrderItemId` in the
+next join's ON clause (fixed by `Client_Nychh/2026-09-10b`); and the Inventory `posByItems` **leaf**
+`additionalDataSlug` had to be the bare table name `PurchaseOrderItems` (the FE appends `.uuid`, so a
+stored `PurchaseOrderItems.uuid` doubled to `.uuid.uuid` and 500'd — `Core/2026-09-10a`).
+
 ## Serial numbers for a Service Request - the bridge table is empty, use the fulfillment chain
 
 `_Model_Client_ServiceRequest::_serialNumbers` (a `FIELD_SQL` field, so every client inherits it)
@@ -143,7 +184,10 @@ None — uniform. The linkage structure is framework-level and identical across
 - **Missing item bridge → no units**, even when units were received. Without a
   `SalesOrderItems_PurchaseOrderItems` row, the receipt path has no starting link.
 - **A present bridge is not sufficient.** If the bridged PO line has no
-  `ItemReceiptItemUnits`, the receipt path still resolves to nothing.
+  `ItemReceiptItemUnits`, the receipt path still resolves to nothing. The **fulfillment-chain**
+  analog (NYCHH rebuild): a PO line with a bridge **and** a fulfillment but **zero
+  `ItemFulfillmentItemUnits`** (no serialized units captured) correctly shows an **empty grid** — that
+  is not a bug, just a line with no serials recorded.
 - **`inventoryType` determines unit existence**: `SERIALIZED` and `HYBRID` items can produce
   unit records; `NON_SERIALIZED` (bulk/consumable) never do. `HYBRID` items fulfilled as a
   plain quantity (no serial capture) also produce no units — legitimately blank.
@@ -172,6 +216,15 @@ None — uniform. The linkage structure is framework-level and identical across
   rather than reading the SQL.
 
 ## Change history
+- 2026-09-10 - `Client_Nychh` **rebuilt this view onto the fulfillment chain** (Units → 30 → 29 →
+  290 bridge → PurchaseOrderItems 18, filtered by `(PurchaseOrderItems.uuid:eq:...)`), the first
+  "resolver that walks the fulfillment path" — lists serialized units for a clicked PO item with
+  Serial #, Asset Tag, Disposition, Location. Disposition/Location come from NYCHH-only
+  `_Model_Nychh_Unit` calc fields (`_unitDisposition` override, new `_transferLocation`) because the
+  location chain re-uses `ItemFulfillmentItems` twice. Added the empty-grid gotcha (bridge +
+  fulfillment but zero `ItemFulfillmentItemUnits` = correctly blank). Cross-refs the bridge Base-ACL
+  1054 and the surface-leaf slug-doubling fixes on [tableview-joins](./tableview-joins.md). Files:
+  `Client_Nychh/2026-09-10a`, `Client_Nychh/2026-09-10b`, `Core/2026-09-10a`. (jcardinal)
 - 2026-08-28 - Corrected the `ServiceRequests_Units` "0 rows" note: that is an **Elite** measurement,
   not a schema fact - `Client_Prudential` has **30,268 rows** and the bridge is the only unit-to-order
   route there for never-shipped units (`SalesOrderItems_CommittedUnits` is the empty one on Prudential,

package/knowledge/2.0/apps/api2/features/v2-api-error-codes.md

@@ -6,7 +6,7 @@ project: API
 client: shared
 type: feature
 status: active
-updated: 2026-08-25
+updated: 2026-09-10
 owners: [mhammontree, tcox, jcardinal, ajean, bala, apeterson]
 files:
   - api2/Component/Api/V2/V2.php
@@ -140,6 +140,13 @@ migration instead of re-deriving it. All field/script ACL rows live in the **CLI
    `error.id` like `"8K-6"`. The part **before the dash** is `Logs.Issue.reference` —
    `SELECT * FROM Logs.Issue WHERE reference = '8K'` gives the full `errorMessage` and stack
    trace. The envelope itself tells you nothing useful; always go to `Logs.Issue`.
+   **A developer will often hand you this id verbally (e.g. "V7-6") to investigate — split on the
+   hyphen: the first part (`V7`) is `Logs.Issue.reference`, the second (`6`) is
+   `Logs.Event.eventNumber`. The two tables join on `Logs.Event.issueId = Logs.Issue.id`, so the
+   exact occurrence (and its `Logs.Event.clientId` tenant) is
+   `SELECT * FROM Logs.Event JOIN Logs.Issue ON Logs.Event.issueId = Logs.Issue.id WHERE
+   Logs.Issue.reference = 'V7' AND Logs.Event.eventNumber = 6`.** (`Logs.Issue` has no `dtUpdated`
+   column.)
    Corollary: if `transactionId`, `authority` and `audience` are **all NULL** in the error
    envelope, the request failed **before client context was established**.
 
@@ -292,6 +299,10 @@ Full mechanics:
 - The response-envelope shape and code families: see [api2 architecture](../architecture.md).
 
 ## Change history
+- 2026-09-10 — Made the developer-shorthand decode of an `error.id` explicit under diagnosis note 9:
+  a verbally-provided id like "V7-6" splits into `Logs.Issue.reference` (before the hyphen) +
+  `Logs.Event.eventNumber` (after), joined by `Logs.Event.issueId = Logs.Issue.id`; added the ready
+  `Logs.Event JOIN Logs.Issue` lookup and noted `Logs.Issue` has no `dtUpdated` column. (jcardinal)
 - 2026-08-27 — Added three codes/notes from the NYCHH transfer-order POST work: **EV-10** (a NOT NULL
   column received NULL — `originLocationId cannot be null`; resolve upstream or default in the ORM), a
   second **EV-12** flavor (`searchableIdentifierFields:[id]` — a nested FK resolved *through* a `c_`

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/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/clients/nychh/profile.md

@@ -33,6 +33,12 @@ files:
   - dbchanges2/Client/2026-09-01a - PurchaseOrderItemQtyFieldsApiRoleRead.sql
   - dbchanges2/Client_Nychh/2026-09-02a - TalosAssistantEnable.sql
   - dbchanges2/Client_Nychh/2026-09-09c - UpdateLocationShippingAddresses.sql
+  - _underscore/Model/Nychh/Unit.php
+  - dbchanges2/Client_Nychh/2026-09-10a - UnitsForPoTableViewRebaseAndTransferLocationField.sql
+  - dbchanges2/Client_Nychh/2026-09-10b - UnitsForPoBridgeBaseAclGrant.sql
+  - dbchanges2/Client_Nychh/2026-09-10c - TransferLocationColumnLabel.sql
+  - dbchanges2/Core/2026-09-10a - InventoryGroupingsUnitsLeafPoItemFilter.sql
+  - dbchanges2/Core/2026-09-10b - UnitDispositionColumnLabel.sql
 related:
   - ./features/location-shipping-addresses.md
   - ../../2.0/apps/dbchanges2/workflows/deleting-contacts-from-a-client-database.md
@@ -206,6 +212,51 @@ table views. Client-specific DB change-sets live in `dbchanges2/Client_Nychh/`.
      `PurchaseOrders.id` 81, onB `PurchaseOrderItems.purchaseOrderId` 90, sortOrder 7, no column). No
      new ACL — record 17 already has Base/Developer/API read. Mechanism:
      [tableview-joins](../../2.0/apps/_underscore/features/tableview-joins.md).
+- **`units-for-items-for-purchase-orders` view rebuilt to list serials for a clicked PO item
+  (2026-09-10).** Base record Units (31). The old 25-join / 12-column config (inaccurate) was replaced
+  with an INNER chain **Units → ItemFulfillmentItemUnits (30) → ItemFulfillmentItems (29) →
+  PurchaseOrderItems_SalesOrderItems bridge (290) → PurchaseOrderItems (18)**, plus a **filter-only**
+  `SalesOrderItems (15)` join kept so the `itemsByPOs` drill (filters by `SalesOrderItems.uuid`) still
+  works. Filtered at drill-down by `(PurchaseOrderItems.uuid:eq:...)`. Columns: Serial #, Asset Tag,
+  Disposition, Location. File `Client_Nychh/2026-09-10a -
+  UnitsForPoTableViewRebaseAndTransferLocationField.sql`. Four connected pieces:
+  1. **Two NYCHH-only calc fields on `_Model_Nychh_Unit`** (`_underscore/Model/Nychh/Unit.php`), both
+     plain `FIELD_SQL` text. **`_unitDisposition` is OVERRIDDEN** — NYCHH does **not** use the
+     `UnitDispositions` lookup; disposition is `Deployed` if an `ItemFulfillmentItems` with
+     `transferOrderItemId IS NOT NULL` exists for the unit, else `Available` (override matches the
+     parent's untyped signature exactly). **`_transferLocation` is NEW** — the transfer-order
+     destination location name via Units → ItemFulfillmentItemUnits → ItemFulfillmentItems →
+     TransferOrderItems → TransferOrders → destinationLocationId → Locations (`ORDER BY` fulfillment
+     id `DESC LIMIT 1`); registered as a `Client_Nychh.CustomRecordFields` row (record 31) + Base
+     `AclCustomFieldPermissions`. It is a calc field, **not** a join, because the chain re-uses
+     `ItemFulfillmentItems`/`ItemFulfillmentItemUnits` a second time and the TableView alias model
+     would bind to the wrong copy. See
+     [calculated-sql-fields](../../2.0/apps/_underscore/features/calculated-sql-fields.md).
+  2. **Bridge Base ACL grant** — record 290 (`PurchaseOrderItems_SalesOrderItems`) shipped with only
+     an **API-role** read grant, so a Base user's joins query dropped the bridge and the next join's
+     ON errored `Unknown column 'PurchaseOrderItems_SalesOrderItems.purchaseOrderItemId' in 'on
+     clause'` (MySQL 1054). Fixed with the full 4-table Base ACL chain reusing record 290's `all`
+     expression: `Client_Nychh/2026-09-10b - UnitsForPoBridgeBaseAclGrant.sql`. Records 30/29/15/18
+     already had Base. Mechanism: [tableview-joins](../../2.0/apps/_underscore/features/tableview-joins.md).
+  3. **Surface drill-down LEAF slug** — the `inventory-list-groupings` `posByItems` **leaf**
+     `additionalDataSlug` had to be the bare table name `PurchaseOrderItems` (NOT
+     `PurchaseOrderItems.uuid`); the FE appends `.uuid` itself, so a stored `.uuid` doubled to
+     `.uuid.uuid` and 500'd (1054). Same doubling rule as the swap level above, one level deeper. This
+     is `Core.SurfaceElements` (all-client, no NYCHH override); `Core/2026-09-10a -
+     InventoryGroupingsUnitsLeafPoItemFilter.sql` (guard covers both `SalesOrderItems.uuid` and the
+     interim `PurchaseOrderItems.uuid`). Confirmed in toga25-supply
+     `useInventoryPageViewModel.tsx` (getAdditionalData).
+  4. **Column labels (settings layer, `Core.Settings` id 5 = `label-singular`)** — Disposition via a
+     `Core.DefaultRecordFieldSettings` row on Core field 619 (`_unitDisposition`), value "Disposition"
+     (`Core/2026-09-10b - UnitDispositionColumnLabel.sql`); Location via a
+     `Client_Nychh.ClientCustomRecordFieldSettings` row on `_transferLocation` (context columns NULL,
+     settingId 5, `isOverridable 1`), value "Location" (`Client_Nychh/2026-09-10c -
+     TransferLocationColumnLabel.sql`). Without a label row the grid falls back to the raw
+     `TableViewFields.slug`.
+  - **Empty grid for a given PO item is correct** when that line has a bridge + fulfillment but zero
+    `ItemFulfillmentItemUnits` (no serialized units captured) — not a bug.
+  - **Deploy:** the `_underscore` model change must land on **`_production`** and **`_sandbox-client`**
+    (api2 pulls `_underscore` per environment by branch); the SQL files run on prod + client-sandbox.
 - **`inventory_units` table view carries item detail as of 2026-08-18** — Part Number, Manufacturer
   and Item Description sit directly after Asset Tag, reached through a **chained** Units → Items →
   Manufacturers join (`dbchanges2/Client_Nychh/2026-08-18 - InventoryUnitsItemColumns.sql`, identical

package/package.json

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