Replace the full build+publish flow with a tiny inline shell step that
emits two static HTML pages (out/index.html and out/master/index.html).
Each one carries:
<meta http-equiv="refresh" content="0; url=https://loto.miti99.com/">
<script>location.replace("https://loto.miti99.com" + ...)</script>
The script preserves path / query / hash, so
/loto/ → loto.miti99.com/
/loto/master → loto.miti99.com/master
/loto/?x=1 → loto.miti99.com/?x=1
Cloudflare Pages stays canonical; this change just stops GH Pages from
serving a stale duplicate of the app and points old links at the live
domain instead.
The build:gh npm script is kept as a manual escape hatch for the rare
case where someone wants to deploy a real GH Pages copy by hand.
.github/workflows/deploy-github-pages.yml runs `npm run build:gh` on push
to main and uploads build/ via actions/upload-pages-artifact@v3 +
actions/deploy-pages@v4.
The build:gh script sets BUILD_PROFILE=gh, which switches svelte.config.js
basePath to /loto so assets resolve under tiennm99.github.io/loto.
Cloudflare Pages keeps deploying in parallel via the CF dashboard
(npm run build, root basePath, loto.miti99.com). Two URLs, no conflict.
- Default `npm run build` now produces a root-relative build (CF Pages
custom domain at loto.miti99.com). The /loto basePath is opt-in via
`npm run build:gh` for the rare manual GH Pages export.
- Removed both GitHub Actions deploy workflows (.github/workflows/) and
the dangling `build:cf` script (it was identical to `build` after the
default flip).
- next.config.mjs: simplified basePath logic — only `BUILD_PROFILE=gh`
toggles a non-empty path; everything else (CF, local dev) is root.
Two named build scripts replace the prior CF_PAGES auto-detect:
npm run build:gh → BUILD_PROFILE=gh, basePath /loto
target: https://tiennm99.github.io/loto
npm run build:cf → BUILD_PROFILE=cf, basePath ""
target: https://loto.miti99.com (CF Pages custom domain)
Both deploy workflows now use the matching profile script. The legacy
`npm run build` keeps its prior behaviour (defaults to /loto basePath) so
nothing else in the toolchain breaks. NEXT_BASE_PATH still wins for any
one-off custom-domain build.
CF_PAGES auto-detection removed — explicit profiles are clearer than
relying on the host injecting a magic env var, and dashboard users should
just set the build command to `npm run build:cf`.
next.config.mjs now detects CF_PAGES=1 (auto-injected by Cloudflare during
build) and switches basePath from /loto to "" — assets resolve at the
project root on loto.pages.dev. GH Pages keeps /loto unchanged.
New workflow .github/workflows/deploy-cloudflare-pages.yml mirrors the GH
Pages flow but publishes via cloudflare/wrangler-action@v3. Requires repo
secrets CLOUDFLARE_API_TOKEN and CLOUDFLARE_ACCOUNT_ID; project name "loto"
is hardcoded — adjust --project-name= in the workflow if your CF Pages
project uses a different name.
Dashboard-based deploys also work without code changes thanks to the
CF_PAGES detection. See docs/deployment-guide.md for both paths.
Adds the standard ./docs/ structure (overview, codebase summary,
architecture, code standards, design guidelines, deployment guide,
roadmap) and the code-review report under ./plans/reports/.
README now points at the docs and covers the codeserver dev profile.