toga-ai 1.0.127 → 1.0.129

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/2.0/apps/toga2-supply/INDEX.md

@@ -4,4 +4,4 @@
 |-----|---------|-------|
 | [TOGa Supply (toga2-supply) Architecture](architecture.md) | `toga2-supply` is the **React + Vite frontend** for TOGa Supply — warehouse fulfillment tooling (shipment selection, fulfill & ship against carrier APIs, NetSui | toga2-supply/src/api/toga.ts, toga2-supply/src/pages/ShipmentItems/view/ShipmentItemsPage.tsx, toga2-supply/src/pages/EditShipment/view/EditShipmentPage.tsx, toga2-supply/src/pages/EditShipment/api/UpdateShipmentApi.ts, toga2-supply/src/pages/Shipments/view/components/ShipmentsCardTableForm/ShipmentsCardTableForm.tsx |
 | [Fulfill & Ship](features/fulfill-and-ship.md) | Fulfill & Ship lets a warehouse user select sales-order line items, enter serials, pick a carrier/method, and in one action: create the Item Fulfillment records | toga2-supply/src/pages/ShipmentItems/view/ShipmentItemsPage.tsx, toga2-supply/src/pages/EditShipment/view/EditShipmentPage.tsx, toga2-supply/src/pages/EditShipment/view/components/forms/EditShipmentForm.tsx, toga2-supply/src/pages/EditShipment/api/UpdateShipmentApi.ts, toga2-supply/src/pages/Shipments/view/components/ShipmentsCardTableForm/ShipmentsCardTableForm.tsx, toga2-supply/src/pages/Shipments/api/ShipmentsApi.ts, _underscore/Model/Client/ItemFulfillment.php, _underscore/Trait/Netsuite/ItemFulfillment.php, _underscore/Component/Library/Carriers/Ups/Ups.php |
-| [AWS Amplify Build & Deploy (non-prod environments)](workflows/amplify-build-and-deploy.md) | How `toga2-supply` (React + Vite) builds and deploys on **AWS Amplify**. | toga2-supply/amplify.yml, toga2-supply/.github/workflows/sync-stage-environments.yml, toga2-supply/.env.qc-security |
+| [AWS Amplify Build & Deploy (non-prod environments)](workflows/amplify-build-and-deploy.md) | How `toga2-supply` (React + Vite) builds and deploys on **AWS Amplify**. | toga2-supply/amplify.yml, toga2-supply/.gitattributes, toga2-supply/.github/workflows/sync-stage-environments.yml, toga2-supply/.env.qc-security |

package/knowledge/2.0/apps/toga2-supply/workflows/amplify-build-and-deploy.md

@@ -10,6 +10,7 @@ updated: 2026-06-18
 owners: ["jcardinal"]
 files:
   - toga2-supply/amplify.yml
+  - toga2-supply/.gitattributes
   - toga2-supply/.github/workflows/sync-stage-environments.yml
   - toga2-supply/.env.qc-security
 related:
@@ -75,6 +76,23 @@ _stage ──▶ Amplify ──▶ build --mode stage
 
 ## Edge cases & escalation
 
+- **Console build spec silently overrides the repo `amplify.yml`.** A build spec saved in the
+  Amplify console (App settings → Build settings) **takes precedence over the repo-root
+  `amplify.yml`**. Symptom seen: the log ran the custom `preBuild` (`NODE_OPTIONS=8192`,
+  `npm ci --legacy-peer-deps`) but the `build` phase started and completed instantly with **zero
+  commands** (`# Starting phase: build` → `# Completed phase: build`, no `# Executing command:`
+  lines), producing no `dist/` → `CustomerError: Artifact directory doesn't exist: dist`. Cause:
+  the console spec had the custom `preBuild` but an **empty `build` phase**, and it won over the
+  repo file. Fix: either paste the full spec (with the build command) into the console editor, or
+  remove the console override so Amplify uses the repo `amplify.yml`. Diagnostic: if you don't see
+  the `Branch '...' -> Vite mode '...'` echo in the build log, the build phase isn't running.
+- **`amplify.yml` must be LF, not CRLF.** A CRLF-terminated `amplify.yml` (easy to produce on
+  Windows) can break Amplify's parsing of a multi-line `- |` block-scalar command — the simple
+  one-line `preBuild` entries survive but the block-scalar `build` command is dropped, giving the
+  same empty-build symptom as above. Mitigations applied: `.gitattributes` pins `*.yml`/`*.yaml`
+  to `eol=lf`, and the build step is written as a **single-line** command (no block scalar) to
+  remove the parsing fragility entirely. `core.autocrlf` is `false` in this repo, so bytes commit
+  as-is — keep the file LF.
 - **Silent wrong-endpoint trap (caused a production outage):** When Vite is given a `--mode`
   with no matching `.env.<mode>`, it **silently falls back to the base `.env`** (which points at
   beta) instead of erroring. An `amplify.yml` that built `--mode "$AWS_BRANCH"` therefore ran
@@ -96,6 +114,10 @@ _stage ──▶ Amplify ──▶ build --mode stage
 
 ## Change history
 
+- 2026-06-18 — Diagnosed empty-`build`-phase failure (`Artifact directory doesn't exist: dist`):
+  console build spec overrides the repo `amplify.yml`, and CRLF can drop the block-scalar build
+  command. Switched build step to a single-line command, added `.gitattributes` pinning `*.yml`
+  to LF. (jcardinal)
 - 2026-06-18 — Fixed production-breaking deploy: `amplify.yml` now strips the leading `_` from
   `$AWS_BRANCH` to get the Vite mode and **fails loudly** if `.env.$MODE` is missing (was
   silently falling back to beta); heap set to 8192; sync workflow targets underscore-prefixed

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/package.json

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