toga-ai 1.0.703 → 1.0.705

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

@@ -663,6 +663,22 @@ Parameters are stored **per client DB** but accessed **through the TOGa2 API**,
   `/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 inventory-ADJUSTMENT unit path now has the SAME auto-create (fixed 2026-08-30) — it did not
+    before, which froze GroWrk.** `syncInventoryAdjustmentFromNetsuite`'s serialized-unit processing took
+    the unit's location from the inventory number's `custitemnumber_location` (the unit's own current
+    location, falling back to the adjustment line location), but — unlike `syncItemReceiptFromNetsuite` —
+    **never auto-created a missing warehouse**, so `POST /units` failed **EV-12** "unable to find a unique
+    match" on `location` (`searchCriteria c_netsuiteInternalLocationId=1596`; **0 rows** in
+    `Client_Growrk.Locations` for 1596), leaving `NETSUITE_EXECUTION_MODE_INVENTORY_ADJUSTMENTS` stuck at
+    `1-RUNNING`. **Fix:** capture the unit location's NAME (`$unitNetsuiteLocationName` from the
+    `custitemnumber_location` ref, carried in `$unitsToGet` as `netsuiteLocationName`) and, before **both**
+    unit-location reference points (the per-unit PUT-create path and the batch `POST /units` path),
+    `POST /locations` when the id is not already in `$lookupWarehouseByNetsuiteLocationInternalId` and a
+    name is present — same payload as the receipt sync (`name`, `c_netsuiteInternalLocationId`,
+    `locationType = WAREHOUSE_LOCATION_TYPE_UUID`, `isActive=true`, `allowReceiving`/`allowSending=false`),
+    then register it in the warehouse lookup. Guarded by `!isset(lookup[id]) && !empty(name)` so it fires
+    only for genuinely-missing locations and never duplicates. Shared 1.0 path — benefits all
+    serialized-adjustment clients.
 
 - **⚠ 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
@@ -742,6 +758,14 @@ Parameters are stored **per client DB** but accessed **through the TOGa2 API**,
 
 ## Change history
 
+- 2026-08-30 — **Inventory-adjustment serialized-unit path now auto-creates a missing unit warehouse
+  (`library`).** `syncInventoryAdjustmentFromNetsuite` took the unit's location from the inventory
+  number's `custitemnumber_location` but never created a missing warehouse (unlike
+  `syncItemReceiptFromNetsuite`), so `POST /units` failed EV-12 on `location` for GroWrk location **1596**
+  (0 rows in `Client_Growrk.Locations`), stuck `INVENTORY_ADJUSTMENTS` at `1-RUNNING`. Fix captures the
+  location NAME (`netsuiteLocationName`) and `POST /locations` before both the PUT-create and batch
+  `POST /units` paths — guarded `!isset(lookup[id]) && !empty(name)`, same payload as the receipt sync —
+  then registers it in the warehouse lookup. Shared path (all serialized-adjustment clients). (jcardinal)
 - 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

package/knowledge/standalone/standards/communication-clarity.md

@@ -21,6 +21,10 @@ answers. This applies to **all** developers, **both** frameworks, and **every**
 
 This is a team directive, not a style tip. Follow it by default.
 
+> **Now enforced always-on.** The short, hard version lives in `rules/common/communication.md`,
+> which loads in **every** session (not just kickoff). This doc is the fuller reference; the
+> rule file is what binds. Keep the two in sync.
+
 ## The rules
 
 1. **Be short.** Say the thing, then stop. Cut every sentence that does not help the reader
@@ -52,6 +56,9 @@ Long, wordy, jargon-heavy answers are hard and tiring to read, especially for no
 English speakers. The team moves faster when Claude is brief and plain. Clear beats clever.
 
 ## Change history
+- 2026-08-31 — Moved the hard, short version to always-on `rules/common/communication.md` so it
+  loads every session, not just some kickoffs. Team was still finding output too long and too
+  complex; the on-demand-only load was part of why. (jcardinal)
 - 2026-08-05 — Standard recorded: keep all communication short, clear, and plain; avoid
   obscure jargon (e.g. "sargability"); lead with the answer; stay technical but brief.
   Team-wide, both frameworks. (jcardinal)

package/package.json

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

package/rules/common/communication.md

@@ -0,0 +1,34 @@
+# Communication Rules
+
+You talk to the whole team. Many teammates read English as a second language, and long
+answers tire them out or lose them. So keep every message short, plain, and clear — in your
+thinking, your plans, and your final answers. This is a hard team rule, not a style tip.
+
+**Clear with more words beats clever with fewer. But short and clear is the goal.**
+
+## The rules
+
+1. **Cut words.** Say the point, then stop. Delete any sentence that does not help the reader
+   do something or decide something. One line is better than three.
+2. **Use common words.** Pick the everyday word over the fancy one. If a simpler word means
+   the same thing, use it.
+3. **Drop the jargon.** Do not use rare technical words (like "idempotent", "cardinality",
+   "sargable", "orthogonal", "canonical"). Say what they mean in plain words instead.
+   - Bad: "make the query sargable"
+   - Good: "let the query use the index — don't wrap the indexed column in a function"
+4. **Answer first.** Put the main point in the first line. Reasons come after, only if needed.
+   No long wind-up.
+5. **Use lists.** More than two parts? Use a numbered or bulleted list, not a paragraph.
+6. **Stay technical, stay exact.** Keep the real detail — file names, error text, exact steps.
+   Short does not mean vague. Be brief AND precise.
+
+## Check before you send
+
+- Can I cut half the words and keep the meaning? Cut them.
+- Is there a rare word a non-native reader might miss? Swap it.
+- Is my main point in the first line? If not, move it up.
+
+## Why
+
+Wordy, jargon-heavy output is hard and slow to read — worse for non-native English readers.
+The team moves faster when you are brief and plain. Clear beats clever.