fix(frontend): build embedded engine UI with /ui base

[NathanFlurry]

Summary

• add an embedded engine frontend build task that pins BASE_URL=/ui/
• update engine Docker publish/build paths to use the embedded build task instead of serving root /assets
• make favicon links honor the Vite base and document the rule in frontend/CLAUDE.md

Verification

• SKIP_NAPI_BUILD=1 SKIP_WASM_BUILD=1 npx turbo run build:engine -F @rivetkit/engine-frontend
• generated frontend/dist/index.html links /ui/assets/... and /ui/favicon...
• local engine curl: /ui/ -> 200 text/html
• local engine curl: /ui/assets/index-B53G-EjF.css -> 200 text/css
• local engine curl: /assets/index-B53G-EjF.css -> 404 application/json

Note: plain npx turbo run build:engine currently hits an unrelated @rivetkit/rivetkit-wasm compile error around ActorConfigInput.inspector_tabs when SKIP_WASM_BUILD is not set; the Docker-equivalent build path passes.

[railway-app]

🚅 Deployed to the rivet-pr-5238 environment in rivet-frontend

Service	Status	Web	Updated (UTC)
website	😴 Sleeping (View Logs)	Web	Jun 14, 2026 at 4:26 am
kitchen-sink	❌ Build Failed (View Logs)	Web	Jun 12, 2026 at 7:45 pm
frontend-cloud	❌ Build Failed (View Logs)	Web	Jun 12, 2026 at 7:38 pm
ladle	❌ Build Failed (View Logs)	Web	Jun 12, 2026 at 7:38 pm
mcp-hub	✅ Success (View Logs)	Web	Jun 12, 2026 at 7:38 pm
frontend-inspector	❌ Build Failed (View Logs)	Web	Jun 12, 2026 at 7:37 pm

[claude]

Code Review

Overview

This PR fixes the embedded engine UI build by introducing a dedicated build:engine turbo task that pins BASE_URL=/ui/. Previously all Dockerfiles called turbo build which produced assets rooted at /, causing the engine's /ui/ prefix to 404 on asset requests. The fix is minimal and targeted.

---

What's Good

• The approach is correct: adding a dedicated build script instead of patching the engine HTTP router is the right call, and the CLAUDE.md entry documents the rule clearly to prevent future regressions.
• BASE_URL is already declared in commonEnvSchema (z.string().optional()), so no schema changes were needed.
• The favigo path fix is necessary and correct. Without it, favicon links would resolve to /favicon.* instead of /ui/favicon.* even though Vite's base was already set properly.
• All 7 Dockerfiles are updated consistently.

---

Issues / Observations

turbo.json: build:engine is missing FAST_BUILD, SKIP_NAPI_BUILD, SKIP_WASM_BUILD in env

The existing build task lists these three env vars as cache inputs. The Dockerfiles set SKIP_NAPI_BUILD=1 SKIP_WASM_BUILD=1 before calling turbo build:engine. Since build:engine doesn't list them, Turbo won't vary its cache on them. For engine-frontend itself this is probably harmless (it's a JS build), but it is an inconsistency worth noting. Consider adding them for parity:

"env": ["BASE_URL", "FAST_BUILD", "SKIP_NAPI_BUILD", "SKIP_WASM_BUILD", "VITE_APP_*", "VITE_FEATURE_FLAGS"]

turbo.json: inputs list omits config files

build:engine omits *.config.* files (e.g. vite.config.ts, vite.base.config.ts) from inputs. The regular build task has the same omission, so this is pre-existing and not a regression introduced here.

package.json: BASE_URL is hard-coded in the npm script but also declared as a Turbo env cache key

When running via npx turbo build:engine, Turbo reads BASE_URL from the shell environment for cache keying, but the actual value is hard-coded in the npm script as BASE_URL=/ui/. This works correctly in practice (the npm script sets it before Vite reads it). Minor ergonomics note: a developer who has BASE_URL set to something else in their shell before invoking turbo directly would get a cache miss without an obvious reason.

Unrelated wasm compile error noted in PR description

plain npx turbo run build:engine currently hits an unrelated @rivetkit/rivetkit-wasm compile error around ActorConfigInput.inspector_tabs when SKIP_WASM_BUILD is not set

This is pre-existing but worth a follow-up. CI or local builds without the skip flags could fail the full turbo graph unexpectedly.

---

Summary

The fix is correct and well-scoped. The turbo.json env list omission of skip-build vars is a minor inconsistency worth addressing, but not blocking. LGTM with those notes addressed at the author's discretion.