#45 · stacks/bench-review

Problem

Deploying what is in the repo today ships a dead site. The only deploy config publishes a directory that does not exist, no host-level wiring forwards /api traffic, dynamic judge/article pages 404, and the prebuilt dist/ is a month old. For a judge-review platform whose core value is /judges/{id}/profile pages and whose transactional emails link to /article/{id}, every one of these is launch-blocking regardless of which host is ultimately chosen. (The missing framework-side prod-serve story is tracked upstream in stacksjs/stacks; this issue covers the app-side wiring that is needed either way.)

Findings

Publish dir is wrong and the build command is the old pipeline. netlify.toml:4 publishes storage/framework/views/web/dist, which does not exist; netlify.toml:3 invokes ./buddy build views, while the real build (bun build.ts → buildApp()) writes root dist/.
No /api path works on a static host. All client API calls use relative /api/... URLs (~50 call sites in resources/stores/**; centralized _apiFetch at resources/stores/auth.ts:138, e.g. auth.ts:207). The only proxy is dev-only (storage/framework/core/actions/src/dev/views.ts:242-243). netlify.toml has zero [[redirects]] and no _redirects file exists, so every API call 404s in production.
Dynamic routes 404. dist/ holds ~28 HTML files with no dist/article/ or per-judge pages, and dist/404.html is a 607-byte static page with no router — yet /article/{id} is baked into emails (app/Actions/Reviews/SubmitReviewAction.ts:159, app/Helpers/notifyModerators.ts:55).
Start/dev scripts point at a missing file. package.json dev/start run bun serve.ts; serve.ts does not exist (only preview.ts, a static-only file server with no API proxy). cloud/Dockerfile's ENTRYPOINT targets a nonexistent dist/index.js; cloud/deploy-script.ts is a log-only no-op.
dist/ is a month stale with no rebuild trigger. Built 2026-05-12; missing article/, admin/, my-reviews, and the verify-email/[id]/[token] deep-link page added since. .github/workflows/ has only ci.yml (the README links a nonexistent release.yml). The stale dist/sitemap.xml is localhost-baked and would shadow the dynamic /api/sitemap.xml (app/Actions/SitemapAction.ts); public/robots.txt hardcodes Sitemap: http://localhost:4000/api/sitemap.xml.

Acceptance criteria

Deploy config builds via bun build.ts and publishes the actual output directory (root dist/)
/api/* works from the deployed site — [[redirects]] proxy to the API host (or an API base URL wired into _apiFetch) — verified by a login round-trip against the deployed artifact
/judges/{id}/profile and /article/{id} resolve on the static host (per-route fallback or SPA catch-all), including email-baked links
package.json dev/start point at existing entrypoints (./buddy dev / bun preview.ts); no reference to nonexistent serve.ts
A fresh build is produced at deploy time (CI job or host build) so post-May pages exist; no month-old dist/ ships
Stale dist/sitemap.xml no longer shadows /api/sitemap.xml; robots.txt Sitemap directive uses the production URL
Smoke test passes: /judges/1/profile, /article/1, and login succeed against the built artifact

From the 2026-06-10 production-readiness audit.

Upstream (framework root causes):

https://github.com/stacksjs/stacks/issues/1950 — production serve has no /api proxy

Triage — the repo-side half is done; the rest needs a deploy target and overlaps #85.

Done:

package.json scripts point at real entrypoints: dev: ./buddy dev, start: bun preview.ts, build: bun build.ts. No reference to the nonexistent serve.ts.
The build publishes root dist/, and it is not month-stale — it rebuilds on every bun run gate (today's artifact: 2,989 pages).
The stale sitemap no longer shadows anything — there is one sitemap at the origin now, and robots.txt's Sitemap directive is templated from APP_URL rather than hardcoded. Closed as #61.
/judges/{id}/profile and /article/{id} have build-time coverage: 2,743 judge pages built, tab URLs served by _shell rewrites, gate-enforced that every sitemap URL has a file. Closed as #46.

Blocked on there being somewhere to deploy to:

Host config that builds at deploy time
/api/* proxy, verified by a login round-trip against the deployed artifact
Per-route fallback / SPA catch-all on the real host
Smoke test against the deployed site

That residue is the same work as #85 (APP_URL unset, loopback URLs). These two are effectively one task now — worth closing one as a duplicate of the other when the deploy happens, rather than tracking the same blocker twice.