migrate-googleai
Rule: Migrate Google AI Studio prototype to Domo App Platform Custom App (static dist deploy)
You are converting a project that began in Google AI Studio (often Cloud Run / preview oriented) into a Domo App Platform Custom App deployed as static assets via the Domo CLI. The required deployment contract is:
npm run buildmust produce a self-containeddist/foldercd dist && domo publishmust work (Domo serves the app from a subpath, not from site root)- The app must load assets correctly and not break on refresh/navigation
Detect AI Studio origin
Treat the project as "AI Studio-origin" if you see any of:
- README mentions Google AI Studio / Gemini API / "Build" mode / Cloud Run
- cloudbuild.yaml, Dockerfile, or Cloud Run deploy instructions
- use of
process.env.GEMINI_API_KEYor placeholders described as "provided by AI Studio" - structure that runs via a server/container rather than static hosting
If detected, apply the steps below.
Primary objective
Make the project a conventional front-end that:
- runs locally with
npm run dev - produces production files with
npm run buildintodist/ - can be hosted from a non-root subpath (Domo App Platform)
- does NOT require any server runtime to render the UI
Step 1 — Ensure a standard build pipeline exists
Open package.json and ensure scripts exist and are correct for the chosen toolchain:
-
If it is Vite:
dev:vitebuild:vite buildpreview:vite preview- Confirm output is
dist/
-
If it is CRA:
buildoutputsbuild/by default (NOT acceptable for our contract)- Either: A) migrate to Vite (preferred for App Platform), OR B) update Domo publish docs/commands accordingly (only if user explicitly wants CRA)
Default to Vite if uncertain.
Acceptance criteria:
npm installsucceedsnpm run buildcreatesdist/withindex.htmlandassets/*
Step 2 — Fix base path so assets work in Domo (subpath hosting)
Domo App Platform does NOT host your app at /. It’s under a nested path.
Therefore asset paths MUST be relative or explicitly configured.
-
If Vite: set base to relative
- in
vite.config.*:base: './'
- in
-
If other bundler: ensure the equivalent "public path" is relative.
Acceptance criteria:
- Opening the built
dist/index.htmlfrom a nested path still loads JS/CSS assets (no 404s). - No hardcoded absolute asset paths like
/assets/...unless you know the host root.
Step 3 — Make routing robust for static hosting
If the app uses React Router (or any client router):
- Prefer HashRouter for App Platform unless you know the platform provides SPA rewrites.
- If switching to HashRouter is too invasive, document that refresh on deep routes will 404 unless Domo is configured with a rewrite rule.
Default action:
- If router is present and no rewrite control is known: switch to
HashRouter.
Acceptance criteria:
- Built app can navigate and refresh without server rewrites.
Step 4 — Environment variables and secrets: remove AI Studio-only assumptions
AI Studio can "magically" provide placeholders (e.g., Gemini API key) during its hosted run. In Domo App Platform, the browser cannot safely hold secrets.
Rules:
- Do NOT ship any raw API keys in client code.
- If the UI needs Gemini/LLM calls:
- Prefer Domo AI APIs via domo.js if available/allowed, OR
- Proxy through a backend (e.g., Domo Code Engine) that injects secrets server-side.
- Replace
process.env.*patterns with toolchain-native env usage:- Vite:
import.meta.env.VITE_*
- Vite:
- Add
.env.exampledocumenting required variables (non-secret only).
Acceptance criteria:
- No committed secrets.
- No runtime crashes from missing AI Studio env injection.
Step 5 — Domo deploy contract
Ensure the final developer workflow is:
npm run buildcd distdomo publish
If a Domo manifest/config file is required by the App Platform project (e.g., manifest.json), ensure it is located where Domo expects it OR copied into dist/ during build.
If the platform expects the manifest in the root but publishes dist/, implement one of:
- Copy required config/manifest into
dist/as part of build (postbuild script) - Or adjust publish strategy if the user’s established standard differs
Default:
- Add a
postbuildscript to copy required app platform files intodist/if they are missing there.
Acceptance criteria:
dist/contains everything needed to publish and run.domo publishfrom insidedist/works without manual file copying.
Output requirements (what you must deliver as the assistant)
After applying changes, provide:
- A short list of files changed
- The exact commands to run locally
- A "done checklist" confirming:
- build produces
dist/ - assets load under subpath
- routing works (hash router or documented rewrite need)
- no secrets in client
- build produces
Be decisive; implement changes rather than asking follow-up questions unless blocked by missing files.
More from stahura/domo-ai-vibe-rules
domo-js
Use ryuu.js (domo.js) APIs for env, events, navigation, and data calls.
55appdb
Toolkit-first AppDB document CRUD, query operators, and collection wiring.
54html-deck
Build a professional HTML slide deck from source content and convert it to a pixel-perfect PDF. Covers slide architecture, layout patterns, print-safe CSS, Puppeteer PDF conversion, and quality verification. Use when creating presentation decks, converting documents to slide format, or generating PDF decks from HTML.
54data-api
High-level entry skill for Domo data access. Routes detailed query work to dataset-query.
53jsapi-filters
Apply runtime filters to embedded Domo dashboards/cards from the host page via the JS API (MessagePort). Covers dynamic filtering, drill events, filter change listeners, iframe resize, pfilter URL params, overrideFilters, and App Studio appData. Use for any client-side Domo embed interaction. Not for server-side programmatic filters (use programmatic-filters).
53ai-service-layer
Toolkit-first AIClient patterns for generation, text-to-sql, and response parsing.
53