toga-ai 1.0.700 → 1.0.702

package/knowledge/1.0/apps/library/features/netsuite-suiteql-rest-shim.md

@@ -6,7 +6,7 @@ project: Library
 client: shared
 type: feature
 status: active
-updated: 2026-08-29
+updated: 2026-08-30
 owners: [dfranks, jcardinal, kyalamarthi]
 files:
   - library/app/api/netsuite/rest.php
@@ -135,7 +135,40 @@ Forecast2 tables already store.
   vendorless PO still throws. Same class as the `tl.location` regression below and the missing-entity
   guard was correct — the SELECT was the defect. **When adding a shim, every field the guard/consumer
   reads must actually be in the SELECT.**
-
+  - **The entity fix was only the first of a chain — the real fix completed the shim to MATCH
+    `listPurchaseOrders`' FULL shape (deploy/verify session, 2026-08-29).** `syncPurchaseOrderFromNetsuite`
+    (reached via the item-receipt path) reads a whole set of PO properties **unguarded**, so each one the
+    `fetchPurchaseOrderById` shim omitted threw a 1.0 warning → `App_Error` `exit()` → froze the section —
+    an "entity → createdFrom → shippingAddress → customForm → tranId → tranDate → line/description/rate"
+    whack-a-mole, one missing field surfacing the next. Fixed by making the per-id shim reproduce the
+    sibling **list** shape exactly: added `entity` + `trandate` to the header SuiteQL, `tl.rate` + `tl.memo`
+    to the line query, and populated `createdFrom` / `shippingAddress` / `customForm` from the per-id REST
+    GET. **Lesson (sharper than "a field the consumer reads must be in the SELECT"): a REST shim consumed
+    by a SHARED sync method must reproduce the FULL sibling-`list*` shape — every header field, every line
+    field, every nested object — not just the fields the one path you are testing happens to read.** This
+    cleared Canon(12)/Endeavor(11) ITEM_RECEIPTS to IDLE.
+
+- **`buildSalesOrderShims()` / `fetchSalesOrderByIdFull()` SO-item shims now carry `createdPo` + `poRate`
+  (2026-08-29).** `syncPurchaseOrderFromNetsuite`'s SO-reconciliation loop reads
+  `$nsSalesOrderItem->createdPo` ({internalId}|null) and `$nsSalesOrderItem->poRate` (float|null)
+  **unguarded** — an `Undefined property $createdPo` → `exit()`. This loop was **newly reached** by the
+  `createdFrom` completion above, which is exactly how the next-missing-field surfaced. Both are now read
+  defensively from the per-id REST `salesOrder` sublist already fetched, so the SO-item shim matches what
+  the loop consumes. Same "reproduce the full sibling shape" class as the PO-shim completion.
+
+- **⚠ `fetchPurchaseOrderById` must number PO lines by the NetSuite `line`, not `linesequencenumber` —
+  and the PO record sublist has NO `lineUniqueKey` to join on (fixed 2026-08-30).** Item receipts match
+  their PO line by the receipt's `orderLine` (the NetSuite **`line`** number). `fetchPurchaseOrderById`
+  numbered `PurchaseOrderItems.lineNumber` by physical `linesequencenumber` (1..N), so when a middle PO
+  line was deleted in NetSuite the real lines are e.g. 1,2,4 and a receipt for line 4 failed `EV-12`
+  "unable to find a unique match" (GroWrk item receipts, PO **168223**). `listPurchaseOrders` already did
+  this right via `lineUniqueKey`; the per-id path did not. **GOTCHA:** the REST `purchaseOrder` record
+  line sublist (`expandSubResources=true`) exposes **`line` but NO `lineUniqueKey`/`uniquekey`** to join
+  on (unlike `salesOrder`). **Fix:** fetch the record with `expandSubResources=true` and **ZIP the REST
+  sublist (physical line order) positionally against the SuiteQL rows (`ORDER BY linesequencenumber`)**,
+  cross-checking item id, then number each line by the NetSuite `line` (fall back to `linesequencenumber`
+  if the item ids disagree). Self-heals on the next receipt sync (it re-imports the PO). Same "join a
+  NetSuite line on `line`, not `linesequencenumber`" lesson as the `tl.id` semantics above.
 - **A shim must produce the SOAP object's SHAPE, not just its scalar fields — an absent nested list
   crashes 1.0 (2026-08-29).** `fetchCustomerById()`'s `addressbookList` was where the AIG lookup phase
   crashed: a REST customer with no/odd address made the shim omit the nested `addressbook` structure the
@@ -229,6 +262,23 @@ None — uniform across clients (NetSuite is a single shared account).
 
 ## Change history
 
+- 2026-08-30 — Recorded that **`fetchPurchaseOrderById` numbered PO lines by `linesequencenumber` instead
+  of the NetSuite `line`** — a receipt for a post-gap line (PO with a deleted middle line, real lines
+  1,2,4) failed `EV-12` "unable to find a unique match" (GroWrk PO 168223). The PO record line sublist
+  exposes `line` but **no `lineUniqueKey`** (unlike `salesOrder`), so the fix zips the REST sublist
+  positionally against the `ORDER BY linesequencenumber` SuiteQL rows (item-id cross-checked) and numbers
+  by `line`. `library`-only; self-heals on next receipt sync. (jcardinal)
+- 2026-08-29 — **Completed `fetchPurchaseOrderById` to the full `listPurchaseOrders` shape** and added
+  the SO-item `createdPo`/`poRate` shim fields (same deploy/verify session, after the entity fix). The
+  entity SELECT was only the first missing field: `syncPurchaseOrderFromNetsuite` reads `createdFrom`,
+  `shippingAddress`, `customForm`, `tranId`, `tranDate`, and line `rate`/`description` unguarded, so each
+  omission threw in turn (whack-a-mole). Fixed by matching the sibling **list** shape exactly (header:
+  `entity`+`trandate`; line: `tl.rate`+`tl.memo`; populated `createdFrom`/`shippingAddress`/`customForm`
+  from the per-id REST GET). Completing `createdFrom` newly reached the SO-reconciliation loop, exposing
+  the next unguarded reads `$nsSalesOrderItem->createdPo`/`poRate` — now carried on the
+  `buildSalesOrderShims`/`fetchSalesOrderByIdFull` SO-item shims (read from the per-id REST `salesOrder`
+  sublist). Lesson: a shim consumed by a shared sync method must reproduce the FULL sibling-list shape,
+  not the fields the tested path happens to read. (jcardinal)
 - 2026-08-29 — Recorded `fetchPurchaseOrderById()`'s **missing `entity` SELECT** (deploy/verify
   session): its header query omitted `entity`/`BUILTIN.DF(entity)` and the shim never set
   `$shim->entity` (unlike `listPurchaseOrders`), so the PO vendor was always null and the

package/knowledge/1.0/apps/worker/features/netsuite-togasupply-per-client-sync.md

@@ -6,7 +6,7 @@ project: Worker
 client: shared
 type: feature
 status: active
-updated: 2026-08-29
+updated: 2026-08-30
 owners: ["dfranks", "bala", "jcardinal", "mhammontree", "snaredla"]
 files:
   - worker/crons/toga2/netsuite/common_sync_togasupply.php
@@ -314,6 +314,16 @@ Parameters are stored **per client DB** but accessed **through the TOGa2 API**,
   checkbox `custbody_stocking_order`, read by `App_Api_Toga2::isTransferOrder()`/`isStockingOrder()`
   — **not** a dollar/hold heuristic. Full mechanics, PO bridges, and origin-location resolution:
   [NYCHH NetSuite → TransferOrders import](../../../clients/nychh/features/netsuite-transfer-order-import.md).
+- **Transfer-order integration clients (beyond NYCHH's stocking-flag routing).** GroWrk, Adyen, and Elite
+  run transfer-order integration (wrapper toggle reported as `IS_ENABLED_INTEGRATION_TRANSFER_ORDERS=true`)
+  and are the clients exercised by the shared `syncTransferOrderFromNetsuite` / `getTransferOrderItemsByUuid`
+  fixes (2026-08-30 above). These orders **masquerade as NetSuite sales orders** ($0, `holdInvoice` for
+  GroWrk) and are split into `TransferOrders` vs `SalesOrders` by `App_Api_Toga2::isTransferOrder()`.
+  The **routing SIGNAL is per-client**: NYCHH routes by the `custbody_stocking_order` stocking flag (above),
+  while GroWrk's own signal is `holdInvoice + total === 0` — do **not** assume one universal rule.
+  (⚠ Confirm the exact enable-flag name for GroWrk/Adyen/Elite against the wrappers: the stocking-flag const
+  `IS_ENABLED_TRANSFER_ORDER_STOCKING_FLAG_ROUTING` is documented as NYCHH-only, so
+  `IS_ENABLED_INTEGRATION_TRANSFER_ORDERS` is either a distinct toggle or a loose name for it.)
 - `isParentCustomer` — `true` walks NetSuite child customers (`listChildCustomers`); `false`
   syncs the single customer. Prudential-EDI and the live Quad wrapper use `false`.
 - The original combined-array entries used `App_Api_Toga2::CLIENT_UUID_*` consts for Quad and
@@ -640,8 +650,118 @@ Parameters are stored **per client DB** but accessed **through the TOGa2 API**,
     onboarding effort.
   Both are pre-existing and unrelated to this session's fixes.
 
+- **⚠ A serialized unit's OWN location can differ from its receipt line's — auto-create it before the
+  `/units` write or api2 400s EV-12 (fixed 2026-08-29, `library/app/api/toga2.php`
+  `syncItemReceiptFromNetsuite`).** The unit carries its own `custitemnumber_location` (referenced on the
+  `/units` write by `c_netsuiteInternalLocationId`); when that location differs from the receipt line's
+  and isn't provisioned in the client DB, api2 rejects the unit write **EV-12**. The fix now **POSTs
+  `/locations` for the unit's own location before the write**, mirroring the existing item-line location
+  create one level up. Shared/general fix (any client running serialized item receipts), surfaced by
+  **GroWrk** location **1569**. Deployed.
+
+- **⚠ The exact api2 rejection detail lives in `Logs_<Client>.Api`, not `Logs.Event` (which TRUNCATES
+  it).** When a section throws on an api2 non-success, `Logs.Event` records the error envelope but
+  **truncates** the useful detail (the `EV-9`/`EV-12` field/`searchCriteria` specifics). The full
+  request/response is in the **per-client** `Logs_<Client>.Api` table — **join on the `transactionId`
+  carried in the error envelope**; it has `method`, `route`, `responseCode`, `requestPayload`, and
+  `responsePayload`. So the diagnosis chain is: `Client_<X>.Parameters` (localize the stuck section) →
+  `Logs.Event` filtered by `clientId` (crash file:line + `transactionId`) → `Logs_<Client>.Api` on that
+  `transactionId` (the untruncated api2 rejection). (Distinct from the fatal-before-logging case where the
+  api2 request dies before the middleware and writes **no** `Logs_<Client>.Api` row — then read
+  `Logs.Issue` instead; see the 2026-08-18 poison-order diagnostic trap above.)
+
+- **⚠ The shared `syncTransferOrderFromNetsuite` item-sync WAS NON-IDEMPOTENT — created DUPLICATE
+  `TransferOrderItems` every run (found 2026-08-29; ROOT-CAUSED + FIXED 2026-08-30; affected stocking-SO
+  TOs too).** The shared
+  item loop does not reconcile against existing rows, so every sync appends the TO's items again: an
+  attempted real-TrnfrOrd import reached **22 duplicate items all `lineNumber` 1** on TO #15, and a
+  **pre-existing stocking-SO** transfer order (`Client_Nychh.TransferOrders` id **1** / number **62541**)
+  already carries **13 duplicates** — proving the bug is in the **shared** loop, not the real-TO path.
+  Because of this (plus an api2 `transferOrderItem`-reference gap and a receipt-line↔TO-line mapping
+  mismatch), the **real NetSuite Transfer Order (TrnfrOrd) item-receipt feature is INTENTIONALLY SKIPPED**
+  — a documented skip in `common_sync_togasupply.php`, exactly like the existing Return-Authorization
+  (`RtnAuth`) receipt skip — pending a proper rebuild. Full state, the inactive scaffolding left staged,
+  and the rebuild spec are on the
+  [NYCHH NetSuite → TransferOrders import](../../../clients/nychh/features/netsuite-transfer-order-import.md)
+  doc. **Do not re-enable real-TO receipts until the shared item loop is made idempotent (which also
+  fixes the stocking-SO dups and cleans the pre-existing TO 1).**
+
+  **ROOT CAUSE + FIX (2026-08-30).** The non-idempotency was NOT a bad reconcile loop — it was that
+  `syncTransferOrderFromNetsuite` read `$transferOrder->transferOrderItems` for its idempotency lookup,
+  and **api2 never inlines that child collection** (`transfer-orders` has no `Core.InherentRecordChildren`
+  row, unlike its sibling order types sales-orders/purchase-orders/item-fulfillments), so the lookup was
+  **always empty** and every line re-INSERTed each run (TransferOrder 26 grew to 84 duplicate items). New
+  private helper `App_Api_Toga2::getTransferOrderItemsByUuid` now fetches TO items via the **direct
+  `GET /transfer-order-items`** query (join `TransferOrders` by uuid, high `recordsPerPage`), used by both
+  `syncTransferOrderFromNetsuite` (idempotency) and `syncItemFulfillmentFromNetsuite` (TO-line linking);
+  **first-wins**, so pre-existing dups keep one canonical row and no new dups are created. Shared fix —
+  all TO clients (GroWrk, Adyen, Elite). The 2.0 root cause and the parity migration that also adds the
+  missing `InherentRecordChildren` row are on the
+  [V2 REST query contract](../../../2.0/apps/api2/features/v2-rest-query-contract.md). This closes
+  rebuild-spec **step 1** on the
+  [NYCHH TransferOrders import](../../../clients/nychh/features/netsuite-transfer-order-import.md); the
+  other real-TrnfrOrd-receipt blockers (api2 `transferOrderItem` reference metadata, receipt-line↔TO-line
+  mapping) remain.
+
+- **⚠ Inventory-adjustment sync skipped NULL-quantity NetSuite serial DETAIL sub-lines (fixed 2026-08-30).**
+  NetSuite serialized inventory-number DETAIL sub-lines **repeat the main item line** with a NULL
+  `transactionline.quantity`; `syncInventoryAdjustmentFromNetsuite` tried to write
+  `InventoryAdjustmentItems` with a null `quantityAdjustBy` → api2 `EV-10` / MySQL **1048**
+  "quantityAdjustBy cannot be null." Those sub-lines carry no adjustment (the real qty is on the summary
+  line). **Fix (`library`):** skip lines whose `adjustQtyBy` is null in **BOTH** passes over
+  `inventoryList->inventory` (the item-build pass and the serial/unit pass). Shared fix; unblocked NYCHH
+  inventory adjustments.
+- **⚠ Item-fulfillment stale-item prune must delete tracking-number children before the unit AND the item
+  (fixed 2026-08-30).** In `syncItemFulfillmentFromNetsuite`'s cleanup loop, deleting a stale
+  item-fulfillment-item-**unit** failed api2 `EV-11` / MySQL **1451** (FK
+  `ItemFulfillmentItemUnits_TrackingNumbers → ItemFulfillmentItemUnits`, RESTRICT) because the
+  tracking-number children were not removed first — freezing the fulfillment sync at `1-RUNNING`. **Fix:**
+  delete each unit's `itemFulfillmentItemUnitTrackingNumbers` (route
+  `/item-fulfillment-item-unit-tracking-numbers`) before the unit, and each item's
+  `itemFulfillmentItemTrackingNumbers` (`/item-fulfillment-item-tracking-numbers`) before the item; added
+  `itemFulfillmentItems.itemFulfillmentItemTrackingNumbers.uuid` to the GET `fields`. Shared fix (all
+  clients); resolved NYCHH ITEM_FULFILLMENTS. (Same delete-children-first rule as the 317/318/319 bridge
+  pruning above — extended to the item- and unit-level tracking children in the stale-item path.)
+- **⚠ Item-fulfillment `/units` lookup must be scoped by the line's product on the TRANSFER-ORDER path too
+  (fixed 2026-08-30).** A serialized unit failed `POST /units` with `EV-10` / MySQL **1062** "Duplicate
+  entry '<itemId>-<serial>' for key `Units.itemId_serialNumber`" because the `Units` lookup filtered by
+  item **only on the sales-order path** (`if ($uuidSalesOrderItem)`); a transfer-order line searched
+  `Units` by `serialNumber` alone, and with **duplicate `Items` sharing a partNumber** (GroWrk Items 3861
+  & 4086, both `21QT006VUS`, each with a unit for serial `SPF65LSAC`) the serial-only lookup returned 2 →
+  it did not reuse the existing unit and the create collided on `(itemId, serialNumber)`. **Fix:** resolve
+  the line's product uuid for **both** paths into a new `$uuidItemForLine` (SO: from the sales-order-item
+  lookup; TO: from `getTransferOrderItemsByUuid`'s `->item->uuid`, so that helper was bumped to **depth
+  2**) and scope the `Units` lookup by it (returns exactly 1 → reuse). Latent data problem behind it:
+  **duplicate `Items` with the same `partNumber`** should be reconciled later (the fix is robust to it).
+  GroWrk ITEM_FULFILLMENTS went from stuck `1-RUNNING` (since Aug 21) to green.
+
 ## Change history
 
+- 2026-08-30 — **Rebuilt GroWrk transfer-order integration + shared IF/inventory-adjustment fixes (all in
+  `library/app/api/toga2.php`).** Root-caused the shared `syncTransferOrderFromNetsuite` **non-idempotency**
+  to api2 never inlining `transferOrderItems` (`transfer-orders` has no `InherentRecordChildren` row) — the
+  idempotency lookup was always empty, so lines re-INSERTed every run (TransferOrder 26 → 84 dup items);
+  fixed with a new `getTransferOrderItemsByUuid` direct `GET /transfer-order-items` helper (first-wins),
+  used for both TO idempotency and IF→TO-line linking (all TO clients — GroWrk/Adyen/Elite). Fixed the IF
+  stale-item prune (delete unit/item tracking-number children before the unit/item — FK RESTRICT/1451/EV-11)
+  and the IF `/units` lookup (scope by the line's product on the TO path too via `$uuidItemForLine`, helper
+  bumped to depth 2 — a serial-only lookup hit two duplicate `Items` sharing a partNumber → 1062 dup-key),
+  and the inventory-adjustment sync (skip NULL-`adjustQtyBy` NetSuite serial DETAIL sub-lines in both passes
+  — 1048/EV-10). GroWrk IF unfroze (stuck since Aug 21); NYCHH IF + inventory adjustments resolved. Developer
+  also applied the 2.0 parity migration adding the `transfer-orders → transfer-order-items`
+  `InherentRecordChildren` row (dbchanges2) — see
+  [V2 REST query contract](../../../2.0/apps/api2/features/v2-rest-query-contract.md). (jcardinal)
+- 2026-08-29 — **Stabilize session, additional durable findings.** (a) `syncItemReceiptFromNetsuite`
+  now **auto-creates a serialized unit's OWN location** (`custitemnumber_location` → POST `/locations`)
+  before the `/units` write, mirroring the item-line location create — a general fix surfaced by GroWrk
+  location 1569 (unit location ≠ receipt-line location → EV-12). (b) Recorded the diagnostic that
+  `Logs.Event` **truncates** the api2 rejection detail — the untruncated `method`/`route`/`responseCode`/
+  `requestPayload`/`responsePayload` is in the per-client `Logs_<Client>.Api` table, joined on the
+  envelope's `transactionId`. (c) Recorded that the shared `syncTransferOrderFromNetsuite` item-sync is
+  **non-idempotent** (duplicate `TransferOrderItems` every run — TO #15 reached 22 dups, pre-existing
+  stocking-SO TO 1/62541 has 13), so it affects stocking-SO TOs too; the **real-TrnfrOrd item-receipt
+  feature was intentionally SKIPPED** in `common_sync_togasupply.php` (like the RtnAuth skip) pending a
+  rebuild — rebuild spec on the NYCHH TransferOrders-import doc. (jcardinal)
 - 2026-08-29 — **Deploy/verify/stabilize session for the SOAP→REST conversion.** Root-caused the
   **Canon + Endeavor Health ITEM_RECEIPTS** freeze: `fetchPurchaseOrderById` never populated the PO
   vendor (`entity` missing from its SuiteQL SELECT), so `syncPurchaseOrderFromNetsuite`'s fail-loud

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

@@ -4,7 +4,7 @@
 |-----|---------|-------|
 | [Proposed — git-sourced base+overlay JSON authoring for the Surface layer](architecture/surface-authoring-proposal.md) | A **proposal / handoff recommendation** (not implemented) that the Surface layer's *authoring* model move off hand-authored SQL against the `SurfaceOverrides` E | _underscore/Model/Core/Surface.php, _underscore/Model/Client/SurfaceOverride.php |
 | [_underscore Framework Architecture](architecture.md) | `_underscore` is the shared PHP backend framework for **all 2.0 applications**. | _underscore/_underscore.php, _underscore/Loader.php, _underscore/Framework.php, _underscore/Model.php, _underscore/Database.php, _underscore/Query.php, _underscore/Route.php, _underscore/Component.php |
-| [ACL Permission Chain (Record & Field Authorization)](features/acl-permission-chain.md) | Authorization in the 2.0 API is **metadata-driven**: whether a role may Create/Read/Update/Delete a record is decided by rows across **four linked tables**, not | api2/Component/Api/V2/V2.php, dbchanges2/Core/2026-08-27a - TransferOrderUuidSearchableIdentifier.sql, _underscore/Model/Core/Page.php, _underscore/Model/Core/Surface.php, _underscore/Model/Client/TrackingNumber.php, dbchanges2/Client/2026-06-03- BLANK_CLIENT_DATABASE.sql, dbchanges2/Client/2026-06-23b - ItemTranslationsAcl.sql, dbchanges2/Client/2026-07-02c - TrackingNumberNeedsReturnLabelFieldPermission.sql, dbchanges2/Client/2026-07-22c - TrackingNumberMeasureIdsFieldPermission.sql, dbchanges2/Client_Quad/2026-08-24 - Quad Multi Currency Item Pricing.sql |
+| [ACL Permission Chain (Record & Field Authorization)](features/acl-permission-chain.md) | Authorization in the 2.0 API is **metadata-driven**: whether a role may Create/Read/Update/Delete a record is decided by rows across **four linked tables**, not | api2/Component/Api/V2/V2.php, dbchanges2/Core/2026-08-27a - TransferOrderUuidSearchableIdentifier.sql, _underscore/Model/Core/Page.php, _underscore/Model/Core/Surface.php, _underscore/Model/Client/TrackingNumber.php, dbchanges2/Client/2026-06-03- BLANK_CLIENT_DATABASE.sql, dbchanges2/Client/2026-06-23b - ItemTranslationsAcl.sql, dbchanges2/Client/2026-07-02c - TrackingNumberNeedsReturnLabelFieldPermission.sql, dbchanges2/Client/2026-07-22c - TrackingNumberMeasureIdsFieldPermission.sql, dbchanges2/Client_Quad/2026-08-24 - Quad Multi Currency Item Pricing.sql, dbchanges2/Client/2026-08-29 - ItemReceiptTransferOrderIdFieldPermission.sql, dbchanges2/Client/2026-08-29b - ItemReceiptItemTransferOrderItemIdFieldPermission.sql |
 | [Address Uniqueness Normalization (unit identifier + 5-digit ZIP comparison)](features/address-uniqueness-normalization.md) | When a business rule says *"only one X per physical address"*, comparing address rows field-for-field does **not** work: the same dwelling is spelled many diffe | _underscore/Model/Rate/Entitlement.php |
 | [Address Validation (carrier waterfall + validateAddress scripted endpoint)](features/address-validation.md) | `_Model_Client_Address::validateAddress` verifies a US address against a **carrier waterfall (USPS → FedEx → UPS)** and returns a single canonical, carrier-norm | _underscore/Model/Client/Address.php, _underscore/Component/Library/Carriers/Usps/Usps.php |
 | [_ApiRequest — JSON encode/decode & api-logging behavior](features/apirequest-json-content-type.md) | `_ApiRequest` is the 2.0 outbound HTTP client. | _underscore/ApiRequest.php |

package/knowledge/2.0/apps/_underscore/features/acl-permission-chain.md

@@ -19,6 +19,8 @@ files:
   - dbchanges2/Client/2026-07-02c - TrackingNumberNeedsReturnLabelFieldPermission.sql
   - dbchanges2/Client/2026-07-22c - TrackingNumberMeasureIdsFieldPermission.sql
   - dbchanges2/Client_Quad/2026-08-24 - Quad Multi Currency Item Pricing.sql
+  - dbchanges2/Client/2026-08-29 - ItemReceiptTransferOrderIdFieldPermission.sql
+  - dbchanges2/Client/2026-08-29b - ItemReceiptItemTransferOrderItemIdFieldPermission.sql
 ---
 
 ## Summary
@@ -490,6 +492,15 @@ hardcoded `Core.RecordFields` id literals instead of a subselect.
       and every repo is on the **same branch** so the generated model matches the DB.
 
 ## Change history
+- **2026-08-29** — Two more worked examples of the **standard-field write grant via hardcoded
+  `Core.RecordFields` id literal** (the cross-cluster caveat — a `Client_*`→`Core` JOIN is refused on the
+  prod client cluster), each cloning a working sibling: `ItemReceipts.transferOrderId` (Core RF **2153**,
+  clone `purchaseOrderId` **85**) and `ItemReceiptItems.transferOrderItemId` (Core RF **2152**, clone
+  `purchaseOrderItemId` **471**). Correct + deployed but **dormant** — they only take effect once NYCHH's
+  real-`TrnfrOrd` item-receipt path is re-enabled (deferred; see
+  [NYCHH TransferOrders import](../../../clients/nychh/features/netsuite-transfer-order-import.md)). Note
+  for the team: this recipe was in this doc all along, yet the field-ACL model was reverse-engineered from
+  DB/code first this session before the doc was consulted — search the KB first. (jcardinal)
 - **2026-08-28** — Scoped the **third gate**: `Core.AclActions` + `AclActionPermissions` is
   `_Model_Core_Page::meta()` behavior only, and is **dead config in the surface-driven `toga25-supply`
   app** — `_Model_Core_Surface::resolve()` drops an element only when the element itself declares an

package/knowledge/2.0/apps/api2/features/v2-rest-query-contract.md

@@ -6,7 +6,7 @@ project: API
 client: shared
 type: feature
 status: active
-updated: 2026-08-29
+updated: 2026-08-30
 owners: [tcox, bala, apeterson, jcardinal]
 files:
   - api2/Component/Api/V2/V2.php
@@ -129,6 +129,13 @@ have **none** — `transfer-orders` (312) had **zero** as of 2026-08-28, so `tra
 appears in the record payload no matter what `fields`/`depth` ask for. The client must call the
 **nested route** instead:
 
+> **This exact missing row was the ROOT CAUSE of a 1.0 sync bug (2026-08-30).** The NetSuite importer's
+> `syncTransferOrderFromNetsuite` read `$transferOrder->transferOrderItems` for its idempotency lookup;
+> because api2 never inlined that collection, the lookup was **always empty** and every line re-INSERTed
+> each run (TransferOrder 26 grew to 84 duplicate items). The 1.0 fix was a direct
+> `GET /transfer-order-items` query — see
+> [per-client sync](../../../1.0/apps/worker/features/netsuite-togasupply-per-client-sync.md).
+
 ```
 GET /v2/transfer-orders/{uuid}/transfer-order-items
 ```
@@ -141,6 +148,12 @@ GET /v2/transfer-orders/{uuid}/transfer-order-items
   and NetSuite sync — so the blast radius has to be surveyed first. The transfer-order build
   deliberately declined to add one and named the child route in the consuming surface's config
   instead. See [Transfer Orders page](../../toga25-supply/features/transfer-orders-page.md).
+  **Reversed 2026-08-30:** a later dbchanges2 Core migration **did** add the
+  `transfer-orders (312) → transfer-order-items (313)` row (route-based lookup + `NOT EXISTS` guard), so
+  `GET /transfer-orders` now inlines `transferOrderItems` like its sibling order types — the parity
+  alternative to the 1.0 direct-query fix (the developer applied both). **Ordering caveat:** the
+  migration must run **after** the duplicate-`TransferOrderItems` cleanup, or the inline expansion
+  returns all the dup rows.
 
 ### ⚠ `join` / `ojoin` drive the WHERE/filter — NOT the response shape
 
@@ -302,6 +315,12 @@ where=(field:op:value,LOGIC,field:op:value,(nested,OR,nested))
   write against the DB / `Logs_<Client>.Api`, not the echo. See
   [NYCHH inventory-adjustment → item-fulfillment linking](../../../../clients/nychh/features/netsuite-inventory-adjustment-fulfillment-link.md).
   (jcardinal)
+- 2026-08-30 — Recorded that the missing `transfer-orders` `InherentRecordChildren` row was the **root
+  cause** of the 1.0 NetSuite sync duplicating `TransferOrderItems` every run (idempotency read
+  `$transferOrder->transferOrderItems`, always empty → re-INSERT; TransferOrder 26 → 84 dups), and that a
+  dbchanges2 Core migration **added** the `transfer-orders (312) → transfer-order-items (313)` row (route
+  lookup + `NOT EXISTS` guard) for parity — reversing the earlier decision to decline it. Ordering caveat:
+  run it **after** the duplicate-TO-item cleanup or the inline expansion returns the dups. (jcardinal)
 - 2026-08-28 — Documented two response-shape facts hit while building the Transfer Orders modal.
   **`calcDepth` defaults to 1**, so a `FIELD_SQL` calculated field on a record one FK hop out returns
   `null` with **no** message (Location's `_address*` fields needed `calcDepth: 2`) — raise it one per

package/knowledge/clients/nychh/INDEX.md

@@ -3,7 +3,7 @@
 | Doc | Framework | Summary | Files |
 |-----|-----------|---------|-------|
 | [NYCHH inventory-adjustment → item-fulfillment linking (direct FK columns, REST)](features/netsuite-inventory-adjustment-fulfillment-link.md) | 1.0 | For NYCHH stock adjustments, the NetSuite **inventory adjustment** carries a link to the **Item Fulfillment** it corrects, on the multi-select body custom field | library/app/api/toga2.php, library/app/api/netsuite/rest.php, worker/crons/toga2/netsuite/common_sync_togasupply.php, worker/crons/toga2/netsuite/sync_togasupply_hh.php, worker/crons/toga2/netsuite/diagnose_hh_import_inventory_adjustment.php |
-| [NYCHH NetSuite → TransferOrders import (stocking-flag routing, PO bridges, origin location)](features/netsuite-transfer-order-import.md) | 1.0 | NYCHH's NetSuite **transfer orders are represented as NetSuite sales orders** (same as the GroWrk pattern), so the shared NetSuite → TOGa Supply importer (`App_ | library/app/api/toga2.php, library/app/api/netsuite/rest.php, library/app/netsuite.php, worker/crons/toga2/netsuite/sync_togasupply_hh.php, worker/crons/toga2/netsuite/common_sync_togasupply.php, worker/crons/toga2/netsuite/diagnose_hh_stuck_transfer_order.php, dbchanges2/Core/2026-08-27a - TransferOrderUuidSearchableIdentifier.sql, dbchanges2/Client/2026-08-28a - TransferOrderItemsTimestampColumns.sql, dbchanges2/Client/2026-08-28b - TransferOrderItemsTimestampColumnsReposition.sql |
+| [NYCHH NetSuite → TransferOrders import (stocking-flag routing, PO bridges, origin location)](features/netsuite-transfer-order-import.md) | 1.0 | NYCHH's NetSuite **transfer orders are represented as NetSuite sales orders** (same as the GroWrk pattern), so the shared NetSuite → TOGa Supply importer (`App_ | library/app/api/toga2.php, library/app/api/netsuite/rest.php, library/app/netsuite.php, worker/crons/toga2/netsuite/sync_togasupply_hh.php, worker/crons/toga2/netsuite/common_sync_togasupply.php, worker/crons/toga2/netsuite/diagnose_hh_stuck_transfer_order.php, dbchanges2/Core/2026-08-27a - TransferOrderUuidSearchableIdentifier.sql, dbchanges2/Client/2026-08-28a - TransferOrderItemsTimestampColumns.sql, dbchanges2/Client/2026-08-28b - TransferOrderItemsTimestampColumnsReposition.sql, dbchanges2/Client/2026-08-29 - ItemReceiptTransferOrderIdFieldPermission.sql, dbchanges2/Client/2026-08-29b - ItemReceiptItemTransferOrderItemIdFieldPermission.sql |
 | [NYCHH PO links are UPSTREAM — the downstream SO→PO route returns empty](features/po-number-upstream-direction.md) | 2.0 | NYCHH's sales orders are created **from the customer's purchase order**, so their SO↔PO links live in the **upstream** table `PurchaseOrders_SalesOrders` (route | _underscore/Model/Client/SalesOrder.php, _underscore/Trait/Netsuite/SalesOrder.php, toga25-supply/src/pages/SalesOrders/view/SalesOrderRecordModalLayout/hooks/usePurchaseOrderDetails.ts, dbchanges2/Client/2026-08-11b - SalesOrderPurchaseOrdersField.sql, dbchanges2/Client/2026-08-25 - SalesOrderPurchaseOrdersFieldAllClients.sql |
 | [NYCHH transfer-order 2.0 model — inventory quantities + V2 field enablement](features/transfer-order-inventory-quantities.md) | 2.0 | The 2.0 (`_underscore`) side of NYCHH transfer-order support: a **two-branch inventory quantity model** on the NYCHH `Item` override, plus the **client-override | _underscore/Model/Nychh/Item.php, _underscore/Model/Nychh/TransferOrder.php, _underscore/Model/Nychh/TransferOrderStage.php, _underscore/Model/Client/TransferOrder.php, _underscore/Model/Client/TransferOrderItem.php, dbchanges2/Client_Nychh/2026-08-27a - TransferOrderCustomFieldWritePermission.sql, dbchanges2/Client_Nychh/2026-08-27b - TransferOrderStageStatusIdentifier.sql, dbchanges2/Client_Nychh/2026-08-28c - TransferOrderRecordAcl.sql, dbchanges2/Client/2026-08-28b - TransferOrderItemsTimestamps.sql |
 | [NYC Health & Hospitals](profile.md) | 2.0 | NYC Health & Hospitals (NYCHH) is a TOGA 2.0 client on the `_underscore` platform, prod schema `Client_Nychh`. | dbchanges2/Client_Nychh/2026-08-18 - InventoryUnitsItemColumns.sql, dbchanges2/Client_Nychh/2026-08-24 - FixInventoryGroupingsUnitsTopologyOverrideIds.sql, dbchanges2/Client_Nychh/2026-08-27a - TransferOrderCustomFieldWritePermission.sql, dbchanges2/Client_Nychh/2026-08-27b - TransferOrderStageStatusIdentifier.sql, dbchanges2/Client_Nychh/2026-08-28a - TransferOrdersTableView.sql, dbchanges2/Client_Nychh/2026-08-28b - TransferOrdersNavigationEnable.sql, dbchanges2/Client_Nychh/2026-08-28c - TransferOrderRecordAcl.sql, dbchanges2/Client/2026-08-28b - TransferOrderItemsTimestamps.sql |

package/knowledge/clients/nychh/features/netsuite-inventory-adjustment-fulfillment-link.md

@@ -6,7 +6,7 @@ project: Library
 client: nychh
 type: client-feature
 status: active
-updated: 2026-08-29
+updated: 2026-08-30
 owners: [jcardinal]
 files:
   - library/app/api/toga2.php
@@ -182,6 +182,14 @@ this feature on the scheduled cron.
 
 - **Older adjustments have no link.** `custbody_stock_adjustment` was added in NetSuite <1 year ago;
   adjustments predating it will never populate an FK — not a bug.
+- **A NULL `itemFulfillmentId`/`itemFulfillmentItemId` on a NYCHH adjustment is usually CORRECT, not a
+  bug.** Only records whose NetSuite multi-select body field `custbody_stock_adjustment` is populated get a
+  link — and **0 of 27** NYCHH adjustments carry a value there (only **~1 in 40** recent adjustments
+  account-wide do). So a null header/line FK almost always means NetSuite has **no** stock-adjustment link
+  on that record, not a code fault. The REST shim's read of `custbody_stock_adjustment` as a **scalar
+  SuiteQL column on `transaction`** works when the field IS populated (SuiteQL omits null columns from a
+  row, so an empty field just looks "absent"); the shim only builds the link ref when a value exists. (A
+  clarifying comment was added at the `customFieldList` build in `rest.php` `fetchInventoryAdjustmentById`.)
 - **Reading the product uuid at `depth=2` silently returns nothing** — the level-3 `item` object is
   omitted at max depth. Use `depth=3` + explicit nested `fields` (see above).
 - **A V2 PUT echo that omits `itemFulfillment` does NOT mean the write failed** — verify against the
@@ -192,6 +200,15 @@ this feature on the scheduled cron.
 
 ## Change history
 
+- 2026-08-30 — Verified that NYCHH adjustments with a NULL `itemFulfillmentId`/`itemFulfillmentItemId`
+  are **correct, not a bug**: 0 of 27 NYCHH adjustments populate NetSuite `custbody_stock_adjustment`
+  (~1 in 40 account-wide), so most carry no link. Confirmed the shim's scalar SuiteQL read of the field
+  works when populated (SuiteQL omits null columns, so an empty field reads as absent) and only builds the
+  link ref when a value exists; added a clarifying comment at the `customFieldList` build in `rest.php`
+  `fetchInventoryAdjustmentById`. Also: the shared inventory-adjustment sync now **skips NULL-`adjustQtyBy`
+  NetSuite serial DETAIL sub-lines** (they repeat the main line with null qty → previously 1048/EV-10) —
+  shared fix on the [per-client sync](../../../1.0/apps/worker/features/netsuite-togasupply-per-client-sync.md).
+  (jcardinal)
 - 2026-08-29 — **Migrated the feature to direct FK columns over REST, and made it fail loud.**
   Replaced the two bridge tables with direct FK columns
   (`InventoryAdjustments.itemFulfillmentId` reusing `RecordField` 2517/record 154;

package/knowledge/clients/nychh/features/netsuite-transfer-order-import.md

@@ -6,7 +6,7 @@ project: Library
 client: nychh
 type: client-feature
 status: active
-updated: 2026-08-28
+updated: 2026-08-30
 owners: [jcardinal]
 files:
   - library/app/api/toga2.php
@@ -18,6 +18,8 @@ files:
   - dbchanges2/Core/2026-08-27a - TransferOrderUuidSearchableIdentifier.sql
   - dbchanges2/Client/2026-08-28a - TransferOrderItemsTimestampColumns.sql
   - dbchanges2/Client/2026-08-28b - TransferOrderItemsTimestampColumnsReposition.sql
+  - dbchanges2/Client/2026-08-29 - ItemReceiptTransferOrderIdFieldPermission.sql
+  - dbchanges2/Client/2026-08-29b - ItemReceiptItemTransferOrderItemIdFieldPermission.sql
 related:
   - ../../../1.0/apps/worker/features/netsuite-togasupply-per-client-sync.md
   - ../../../1.0/apps/library/features/toga2-api-client-and-bridge.md
@@ -160,8 +162,73 @@ that rethrows warnings as a catchable `ErrorException` with exact `file:line`. T
 `transferOrderStage` crash after the stale `Logs.Issue` trace misdirected. **When a 1.0 cron freeze's
 `Logs.Issue` trace looks wrong, trust a single-record harness over the aggregated trace.**
 
+## Real NetSuite Transfer Order (TrnfrOrd) item receipts — DEFERRED / SKIPPED (2026-08-29)
+
+Everything above concerns transfer orders that arrive **as NetSuite sales orders** (the stocking-flag
+routing). A *separate* case is a NetSuite item receipt whose **`createdFrom` is a real
+`TrnfrOrd` record** ("Transfer Order #N"), not a stocking sales order presenting as `'Sales Order'`.
+Importing that path was **attempted this session and INTENTIONALLY DISABLED** — a documented skip in
+`common_sync_togasupply.php`, exactly like the existing Return-Authorization (`RtnAuth`) receipt skip —
+because the feature is **not production-ready**. Do not re-enable it without doing the rebuild below.
+
+**Why it was disabled (three blockers):**
+
+1. **The shared `syncTransferOrderFromNetsuite` item-sync is NON-IDEMPOTENT.** It appends the TO's items
+   every run instead of reconciling — the attempted TO #15 reached **22 duplicate items all `lineNumber`
+   1**, and a **pre-existing stocking-SO** transfer order (`Client_Nychh.TransferOrders` id **1** /
+   number **62541**) already carries **13 duplicates**. So the duplicate bug is in the **shared** item
+   loop and affects **stocking-SO TOs too**, not just the real-TO path (see the shared
+   [per-client-sync doc](../../../1.0/apps/worker/features/netsuite-togasupply-per-client-sync.md)).
+2. **api2 cannot resolve the receipt's `transferOrderItem` reference — `EV-12` "no searchable
+   identifiers."** `TransferOrderItems` is **not** set up to be referenced by `(transferOrder,
+   lineNumber)` the way `PurchaseOrderItems` is (which is how a receipt line normally links to its
+   order line). This needs api2 **reference metadata** making a `TransferOrderItems` identifier
+   searchable.
+3. **Receipt-line ↔ TO-line mapping is wrong.** The receipt line's `orderLine` did not match the TO
+   item's `lineNumber`, so even past the EV-12 the line link would be incorrect.
+
+**Cleanup done:** deleted the TO #15 duplicate artifact (`TransferOrder` 114 + its items).
+
+**Inactive scaffolding left STAGED for the rebuild (present but not wired live):**
+
+- `App_Api_Netsuite_Rest::fetchTransferOrderById` — real `TrnfrOrd` shim (`source` = location,
+  `dest` = `transferLocation`, `ordPicked`/`ordReceived` flags).
+- `syncTransferOrderFromNetsuite($isRealTransferOrderRecord = true)` — dest resolved from the
+  `transferLocation` warehouse; stage derived from the picked/received flags.
+- a location → client lookup in the cron.
+- the guarded `transferOrderItem` link in the receipt-item builder.
+
+**ACL grants written + deployed this session (correct, but DORMANT until real-TO receipts are
+re-enabled):** two standard-field write grants cloning a working sibling per the
+[ACL permission chain](../../../2.0/apps/_underscore/features/acl-permission-chain.md) recipe, using
+**hardcoded `Core.RecordFields` id literals** (the cross-cluster caveat — a `Client_*`→`Core` JOIN is
+refused on the prod client cluster):
+
+- `dbchanges2/Client/2026-08-29 - ItemReceiptTransferOrderIdFieldPermission.sql` —
+  `ItemReceipts.transferOrderId` (Core RecordField **2153**), cloning `purchaseOrderId` (**85**).
+- `dbchanges2/Client/2026-08-29b - ItemReceiptItemTransferOrderItemIdFieldPermission.sql` —
+  `ItemReceiptItems.transferOrderItemId` (Core RecordField **2152**), cloning `purchaseOrderItemId`
+  (**471**).
+
+**REBUILD SPEC (all four, in order, before re-enabling + removing the skip):**
+1. Make the shared `syncTransferOrderFromNetsuite` item-sync **idempotent** (reconcile against existing
+   `TransferOrderItems` by a stable key) — this also fixes the stocking-SO dups and must **clean the
+   pre-existing TO 1** (13 dups). **DONE 2026-08-30:** root cause was api2 never inlining
+   `transferOrderItems` (`transfer-orders` has no `InherentRecordChildren` row → idempotency read always
+   empty); fixed via the new `getTransferOrderItemsByUuid` direct `GET /transfer-order-items` helper
+   (first-wins) — see
+   [per-client sync](../../../1.0/apps/worker/features/netsuite-togasupply-per-client-sync.md). Steps 2–4
+   still remain, so real-TrnfrOrd receipts stay skipped.
+2. Add api2 **`TransferOrderItems` reference metadata** so a receipt line can resolve its TO item by a
+   searchable identifier (the analogue of the `PurchaseOrderItems` `(purchaseOrder, lineNumber)` setup).
+3. **Verify the receipt-line ↔ TO-line mapping** (the `orderLine` ↔ TO-item `lineNumber` correspondence).
+4. Re-enable the path, confirm the (now non-dormant) ACL grants take effect, and **remove the skip**.
+
 ## Gotchas / known issues
 
+- **Real-TrnfrOrd item receipts are disabled — see the DEFERRED section above.** A receipt whose
+  `createdFrom` is a real Transfer Order is skipped by design; do not read that as the importer being
+  broken.
 - **Order 128829 (no location anywhere) is unresolved** — see the origin-resolution section. Do not
   assume the importer is broken if this single order is stuck; every located order imports.
 - **Routing is gated by the wrapper constant.** If a future client should route transfer orders,
@@ -174,6 +241,26 @@ that rethrows warnings as a catchable `ErrorException` with exact `file:line`. T
 
 ## Change history
 
+- 2026-08-30 — Rebuild-spec **step 1 (make `syncTransferOrderFromNetsuite` idempotent) is DONE**: the
+  non-idempotency root cause was api2 never inlining `transferOrderItems` (`transfer-orders` has no
+  `InherentRecordChildren` row), so the idempotency read was always empty; fixed via the new
+  `getTransferOrderItemsByUuid` direct `GET /transfer-order-items` helper (first-wins). Steps 2–4 (api2
+  `TransferOrderItems` reference metadata, receipt-line↔TO-line mapping, re-enable) still remain, so
+  real-TrnfrOrd item receipts stay skipped. A dbchanges2 parity migration also added the
+  `transfer-orders → transfer-order-items` `InherentRecordChildren` row — see
+  [V2 REST query contract](../../../2.0/apps/api2/features/v2-rest-query-contract.md). (jcardinal)
+- 2026-08-29 — Recorded the **real NetSuite `TrnfrOrd` item-receipt feature as DEFERRED/SKIPPED**
+  (documented skip in `common_sync_togasupply.php`, like the `RtnAuth` skip) after attempting it and
+  hitting three blockers: the shared `syncTransferOrderFromNetsuite` item-sync is **non-idempotent**
+  (TO #15 got 22 dup items; pre-existing stocking-SO TO 1/62541 has 13 — shared-loop bug, affects
+  stocking-SO TOs too), api2 can't resolve the receipt's `transferOrderItem` reference (`EV-12`, no
+  searchable identifier on `TransferOrderItems`), and the receipt-line `orderLine` ≠ TO-item `lineNumber`.
+  Deleted the TO #15 dup artifact (TransferOrder 114). Left inactive scaffolding staged
+  (`fetchTransferOrderById`, `syncTransferOrderFromNetsuite($isRealTransferOrderRecord=true)`,
+  location→client lookup, guarded `transferOrderItem` link). Wrote + deployed (but **dormant**) two ACL
+  field-permission grants using hardcoded Core RecordFields literals: `ItemReceipts.transferOrderId`
+  (RF 2153, clone `purchaseOrderId` 85) and `ItemReceiptItems.transferOrderItemId` (RF 2152, clone
+  `purchaseOrderItemId` 471). Documented the four-step rebuild spec. (jcardinal)
 - 2026-08-28 — Unfroze the `SALES_ORDERS` section (NYCHH + GroWrk) by peeling **three** stacked faults
   on `syncTransferOrderFromNetsuite`: (1) `Undefined property $transferOrderStage` — api2 **omits a
   null FK object** from a depth-2 GET, guarded `transferOrderStage`/`originLocation`/`destinationLocation`

package/knowledge/standalone/standards/session-priming.md

@@ -40,6 +40,12 @@ This is a team directive. It applies to every session, both frameworks, every re
    write, or spawn agents.
 5. **Ordering is unchanged.** The team KB stays the **first** source, ahead of all other
    research — that part was already correct and stays.
+6. **Search the KB before reverse-engineering — mid-session, not just at kickoff.** Before
+   reverse-engineering any code, schema, or framework mechanism from the source or the live DB,
+   FIRST search the team KB (`node "<TEAM_REPO>/knowledge.js" search --q=…`). The KB is large and
+   usually already documents the mechanism — reaching for DB/code archaeology first is the mistake.
+   This extends rule 5 (KB is the first source) from kickoff to every point in a session where you
+   are about to derive how something works.
 
 ## How it is enforced
 
@@ -68,6 +74,12 @@ than the old subagent approach did. Mitigate by not re-reading absorbed docs and
 only the needed section of a large spec — but priming in the main session is the requirement.
 
 ## Change history
+- 2026-08-29 — Added rule 6: search the KB before reverse-engineering any code/schema/framework
+  mechanism, mid-session and not only at kickoff. Prompted by a NetSuite→TOGa Supply session that
+  reverse-engineered the entire 2.0 field-ACL model (AclFieldPermissions, Core.RecordFields,
+  EV-9/EV-12, the add-a-writable-field recipe, the cross-cluster hardcoded-literal caveat) from
+  DB/code before discovering it was fully documented in
+  `2.0/apps/_underscore/features/acl-permission-chain.md` all along. (jcardinal)
 - 2026-08-13 — Standard recorded. Kickoff priming must run in the main session, synchronously,
   and no subagent may start until priming is complete; released by the new
   `knowledge.js kickoff-primed` sentinel. Retired the `context-primer` subagent from the

package/package.json

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