toga-ai 1.0.128 → 1.0.130

package/knowledge/1.0/apps/togaview/INDEX.md

@@ -7,3 +7,4 @@
 | [MSP Dashboard & Ticket Visibility Rules](features/msp-dashboard.md) | Why tickets "disappear" in the TOGa View client portal: different pages scope tickets **differently**, and the MSP pages depend on `tickets.customerid` and `SMB | common/togaview/msp_dashboard.php, mvc/msp_client_dashboard, mvc/enterprise_dashboard, mvc/support/support.php |
 | [Retail Commerce Lifecycle (winback, purchase, claims, activation)](features/retail-commerce-lifecycle.md) | Beyond support, TOGa View hosts the **retail tech-support commerce flows**: subscription purchase/renewal (with payment), service activation, and insurance-styl | mvc/winback_landing/get.php, mvc/winback_payment/get.php, mvc/winback_payment/post.php, mvc/purchase/get.php, mvc/service_activation/get.php, mvc/claims/get.php, mvc/techsupport_app/get.php |
 | [Ticket Detail Page Security (common/togaview/ticket.php)](features/ticket-detail-page.md) | `common/togaview/ticket.php` is the ticket detail page for nearly ALL hosts — only towfoundation/newcenturyholdingsllc have their own variants; every other clie | common/togaview/ticket.php |
+| [Route 53 Hosted Zone Migration Between AWS Accounts](workflows/route53-cross-account-zone-migration.md) | How to move a domain's DNS records (a Route 53 hosted zone) from one AWS account to another. |  |

package/knowledge/1.0/apps/togaview/workflows/route53-cross-account-zone-migration.md

@@ -0,0 +1,97 @@
+---
+title: Route 53 Hosted Zone Migration Between AWS Accounts
+framework: "1.0"
+repo: togaview
+project: TOGa View
+client: shared
+type: workflow
+status: active
+updated: 2026-06-18
+owners: ["jcardinal"]
+files: []
+related: []
+---
+
+## Summary
+How to move a domain's DNS records (a Route 53 hosted zone) from one AWS account to
+another. This is the playbook used to migrate `togaview.com`. The trigger is any time a
+domain's DNS needs to live in a different AWS account (account consolidation, client
+hand-off, separating environments).
+
+**Key fact that drives the whole process:** a Route 53 hosted zone **cannot be moved or
+transferred between accounts** — there is no transfer API. You must **export the records,
+create a new zone in the target account, re-import the records, and repoint the domain's
+name servers.** This is a DNS-records move only; it is separate from moving a *domain
+registration* (Route 53 Domains), which is its own transfer process.
+
+## Steps
+
+CloudShell is per-account, so you run the export in the **source** account's CloudShell and
+the import in the **target** account's CloudShell, transferring one small file between them.
+
+1. **SOURCE CloudShell — export records.**
+   ```bash
+   ZONE_ID=$(aws route53 list-hosted-zones-by-name --dns-name togaview.com. \
+     --query "HostedZones[?Name=='togaview.com.'].Id | [0]" --output text)
+   aws route53 list-resource-record-sets --hosted-zone-id "$ZONE_ID" \
+     --output json > togaview-records.json
+   ```
+   (If the zone has more than ~300 records, `list-resource-record-sets` paginates — add
+   pagination handling.)
+
+2. **SOURCE CloudShell — build the import batch.** Strip the apex `SOA` and apex `NS`
+   records; the new zone generates its own. Delegated-subdomain NS records are preserved.
+   ```bash
+   jq --arg z "togaview.com." '{
+     Changes: [ .ResourceRecordSets[]
+       | select( ((.Type=="SOA") or (.Type=="NS" and .Name==$z)) | not )
+       | {Action:"UPSERT", ResourceRecordSet:.} ]
+   }' togaview-records.json > change-batch.json
+   ```
+
+3. **Move `change-batch.json` to the target account.** CloudShell can't see across
+   accounts — use **Actions → Download file** in the source shell, then **Actions → Upload
+   file** in the target shell (or copy/paste the contents).
+
+4. **TARGET CloudShell — create zone and import.**
+   ```bash
+   NEW_ZONE_ID=$(aws route53 create-hosted-zone --name togaview.com \
+     --caller-reference "togaview-migration-$(date +%s)" \
+     --query 'HostedZone.Id' --output text)
+   aws route53 change-resource-record-sets --hosted-zone-id "$NEW_ZONE_ID" \
+     --change-batch file://change-batch.json
+   aws route53 get-hosted-zone --id "$NEW_ZONE_ID" \
+     --query 'DelegationSet.NameServers' --output table
+   ```
+
+5. **Verify before cutover** by querying the new zone's name servers directly — this tests
+   the new zone without touching live traffic, since the registrar still points at the old
+   one. Compare against the live records:
+   ```bash
+   dig @ns-xxx.awsdns-xx.com togaview.com SOA +short
+   dig @ns-xxx.awsdns-xx.com www.togaview.com +short
+   ```
+
+6. **Cutover** — at the domain's registrar, replace the NS records with the 4 from step 4.
+   Propagation is bounded by the NS record TTL at the registrar.
+
+7. **Cleanup (after propagation confirmed)** — leave the old zone as a fallback for a day or
+   two. Once public resolvers (`dig NS togaview.com +short`) return the new name servers,
+   empty the old zone of custom records and delete it.
+
+## Systems involved
+AWS Route 53 (hosted zones), AWS CloudShell (per-account CLI), the domain registrar (where
+NS records are set — external for `togaview.com`).
+
+## Edge cases & escalation
+- **Alias / ACM-validation records** that point to AWS resources (CloudFront, ELB/ALB, S3,
+  API Gateway) in the **source** account reference account-specific resources that may not
+  exist in the target account. Inspect the record dump first; these need special handling or
+  recreation. (`togaview.com` had none — plain records only.)
+- **`UPSERT` is idempotent** — if a step fails midway, just re-run it; no duplicates.
+- **Nothing in steps 1–5 touches live DNS.** The only user-visible change is the NS switch in
+  step 6.
+- **Domain registration** moving (Route 53 Domains) is a separate transfer, not covered here.
+
+## Change history
+- 2026-06-18 — Initial playbook from the togaview.com hosted-zone migration (jcardinal)

package/knowledge/INDEX.md

@@ -7,7 +7,7 @@ _Auto-generated by `knowledge.js index`. Do not hand-edit._
 - **library** (Library) _(framework core)_ — 4 doc(s) → [1.0/apps/library/INDEX.md](1.0/apps/library/INDEX.md)
 - **worker** (Worker) — 9 doc(s) → [1.0/apps/worker/INDEX.md](1.0/apps/worker/INDEX.md)
 - **togadesk** (TOGa Desk) — 7 doc(s) → [1.0/apps/togadesk/INDEX.md](1.0/apps/togadesk/INDEX.md)
-- **togaview** (TOGa View) — 5 doc(s) → [1.0/apps/togaview/INDEX.md](1.0/apps/togaview/INDEX.md)
+- **togaview** (TOGa View) — 6 doc(s) → [1.0/apps/togaview/INDEX.md](1.0/apps/togaview/INDEX.md)
 - **webhook** (Webhook) — 1 doc(s) → [1.0/apps/webhook/INDEX.md](1.0/apps/webhook/INDEX.md)
 - **walmarttechservices** (Walmart Tech Services) — 1 doc(s) → [1.0/apps/walmarttechservices/INDEX.md](1.0/apps/walmarttechservices/INDEX.md)
 - **test** (Test) — 10 doc(s) → [1.0/apps/test/INDEX.md](1.0/apps/test/INDEX.md)

package/knowledge/clients/compass-usa/INDEX.md

@@ -2,7 +2,7 @@
 
 | Doc | Framework | Summary | Files |
 |-----|-----------|---------|-------|
-| [Compass ASN → ItemFulfillment Auto-Creation](features/asn-to-item-fulfillment.md) | 2.0 | For Compass USA, posting an AdvanceShippingNotice (ASN) auto-creates the ItemFulfillment (IF) on the upstream SalesOrder. | _underscore/Model/Compass/AdvanceShippingNotice.php, _underscore/Model/Compass/PurchaseOrder.php, api2/Component/Api/Cxml/Cxml.php, dbchanges2/Client_Compass/2026-06-11 - AsnItemTrackingNumberAcl.sql, dbchanges2/Client_Compass/2026-06-15b - BackfillSA132781ItemFulfillmentTracking.sql, dbchanges2/Client_Compass/2026-06-16 - CleanupSA132763CrossLineTracking.sql, dbchanges2/Client_Compass/2026-06-16b - CleanupSA132743CrossLineTracking.sql, dbchanges2/Client_Compass/2026-06-16c - BackfillSA132763C40QYUCTracking.sql |
+| [Compass ASN → ItemFulfillment Auto-Creation](features/asn-to-item-fulfillment.md) | 2.0 | For Compass USA, posting an AdvanceShippingNotice (ASN) auto-creates the ItemFulfillment (IF) on the upstream SalesOrder. | _underscore/Model/Compass/AdvanceShippingNotice.php, _underscore/Model/Compass/PurchaseOrder.php, api2/Component/Api/Cxml/Cxml.php, dbchanges2/Client_Compass/2026-06-11 - AsnItemTrackingNumberAcl.sql, dbchanges2/Client_Compass/2026-06-15b - BackfillSA132781ItemFulfillmentTracking.sql, dbchanges2/Client_Compass/2026-06-16 - CleanupSA132763CrossLineTracking.sql, dbchanges2/Client_Compass/2026-06-16b - CleanupSA132743CrossLineTracking.sql, dbchanges2/Client_Compass/2026-06-16c - BackfillSA132763C40QYUCTracking.sql, dbchanges2/Client_Compass/2026-06-18a - CleanupSA132898DuplicateTracking.sql |
 | [Compass: Item-Fulfillment TableViews (for-sales-order-items & for-sales-orders, tracking via bridge)](features/item-fulfillment-tracking-tableview.md) | 2.0 | Two sibling Compass TableViews in `Client_Compass` display fulfilled items in toga2-supply, both driven by `TableViews` / `TableViewJoins` / `TableViewFields` c | dbchanges2/Client_Compass/2026-06-10 - ItemFulfillmentsForSalesOrderItemsTableView.sql, dbchanges2/Client_Compass/2026-06-11 - ItemFulfillmentsForSalesOrdersTableView.sql, dbchanges2/Client_Compass/2026-06-15a - FixItemFulfillmentTrackingNumberJoins.sql |
 | [Compass MITS PO → SO Item Linking](features/mits-po-to-so-item-linking.md) | 2.0 | MITS sends Compass inbound Purchase Orders (`POST /v2/purchase-orders`) against a Sales Order (`mitsSalesOrder`). | _underscore/Model/Compass/PurchaseOrder.php, worker/crons/toga2/compass/workflow/3a_import_office_depot_purchase_orders.php |
 | [Compass USA](profile.md) | 2.0 | Compass USA is a TOGA client running a multi-tier supply-chain commerce operation. |  |

package/knowledge/clients/compass-usa/features/asn-to-item-fulfillment.md

@@ -5,7 +5,7 @@ project: _Underscore
 client: compass-usa
 type: client-feature
 status: active
-updated: 2026-06-16
+updated: 2026-06-18
 owners: [jcardinal]
 files:
   - _underscore/Model/Compass/AdvanceShippingNotice.php
@@ -16,6 +16,7 @@ files:
   - dbchanges2/Client_Compass/2026-06-16 - CleanupSA132763CrossLineTracking.sql
   - dbchanges2/Client_Compass/2026-06-16b - CleanupSA132743CrossLineTracking.sql
   - dbchanges2/Client_Compass/2026-06-16c - BackfillSA132763C40QYUCTracking.sql
+  - dbchanges2/Client_Compass/2026-06-18a - CleanupSA132898DuplicateTracking.sql
 related:
   - ../../../2.0/apps/_underscore/features/recursive-item-fulfillments.md
 ---
@@ -54,6 +55,11 @@ the gotcha about already-fulfilled orders). Flow:
    - **`remaining <= 0`** (reconcile path, new): the tracking targets are the **existing IFIs**
      for that SOI (resolved via `ItemFulfillmentItems.salesOrderItemId` → their `itemFulfillmentId`),
      **not** an SO-number lookup — NetSuite/toga2-supply IFs are `F`-numbered, not SO-numbered.
+     As of **2026-06-18** an existing IFI that **already carries item-level tracking is skipped**
+     here (`itemFulfillmentItemHasTracking()`): reconcile only attaches onto untracked
+     out-of-band IFIs. An already-tracked, fully-fulfilled line revisited by a later ASN is a
+     vendor re-transmission and must not gain a second tracking number (see the duplicate-tracking
+     gotcha).
 4. Copy the ASN item's tracking (`AdvanceShippingNoticeItems_TrackingNumbers`) onto each target
    IFI via `POST /item-fulfillment-item-tracking-numbers` → `ItemFulfillmentItems_TrackingNumbers`
    — **idempotent** (skipped if the bridge row already exists; ASNs get re-POSTed).
@@ -176,8 +182,29 @@ Compass Canada (`Model/Compass/Canada/`) is a separate sub-client. The Compass c
   `NOT EXISTS`. ~116 PO items across other Compass orders share the off-by-one fingerprint and
   are not yet repaired — a broader reviewed backfill is still outstanding.
 
+- **Duplicate tracking from vendor ASN re-transmission (root cause, fixed forward 2026-06-18)
+  — DISTINCT from the cross-line contamination above.** Compass vendors (Office Depot, Strategic
+  Systems) re-send the **same** shipment ASN file for several days; one PO can receive many ASNs
+  (e.g. SA132898 / PO `50305272-1` got 6). The first ASN takes the create path and attaches its
+  tracking; a later ASN re-listing the same, now fully-fulfilled line takes the **reconcile path**
+  and — pre-fix — attached its *different* tracking number onto the existing IFI. On a qty-1 line
+  this yields two item-level tracking rows (plus a propagated package row). Unlike the cross-line
+  bug, **both** tracking numbers here map cleanly to the correct line via their own valid ASN
+  items, so the `NOT EXISTS (ASN item with matching VendorItems.itemId)` cleanup guard does **not**
+  catch it — diagnose instead by an IFI carrying more item-level tracking numbers than its
+  fulfilled quantity. Fix: the reconcile path now skips any IFI that already has item-level
+  tracking (`itemFulfillmentItemHasTracking()`), so only untracked out-of-band IFIs receive ASN
+  tracking. The legitimate out-of-band case (IFI has no tracking, one ASN arrives) is preserved.
+  Forward-only; SA132898 repaired by `2026-06-18a` (delete the later tracking + orphaned package
+  row, keep the original; no backfill needed since the correct number is already present).
+
 ## Change history
 Dated one-liners, newest first.
+- 2026-06-18 — Reconcile path now skips IFIs that already carry item-level tracking
+  (`itemFulfillmentItemHasTracking()`), stopping duplicate/different tracking numbers from
+  vendor ASN re-transmissions piling onto fully-fulfilled lines (qty-1 SA132898 / USB31CC1 had
+  2). Distinct root cause from the 2026-06-16 cross-line contamination. SA132898 repaired by
+  `2026-06-18a` (cleanup-only; original tracking already correct). (jcardinal)
 - 2026-06-16 — Identified cross-line tracking contamination root cause: bad
   `SalesOrderItems_PurchaseOrderItems` rows (PO-local lineNumber collision in
   `_Model_Compass_PurchaseOrder`, fixed forward 2026-06-11 `ec935478`; and the worker ODP-PO

package/package.json

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