Development workflow · 2026-09-06

Current development workflow

The goal is not to force every site onto one vendor. Each layer has one job: GitHub keeps source, cloud CI performs acceptance, Preview spends resources only when needed, Production stays simple, and the MacBook remains available for Remote Desktop, SSH and daily work.

Four shared rules

GitHub = source SSOT

Code, configuration, pull requests and auditable history start from GitHub.

CI ≠ deployment

A green test run does not mean the website is live, and a successful deployment does not replace testing.

Cloud first, Mac quiet

Ordinary CI does not treat the MacBook as an always-on compute server and never falls back to research GPUs.

Exact head + post-merge

Validate the current candidate before merge, then validate the version that actually landed on main.

Responsibilities by site

BaseModel

Heavy browser acceptance runs in CircleCI

GitHub: mykcs/basemodel. CircleCI runs deterministic validation plus two independent Playwright shards with skip / focused / full planning; Vercel owns Preview / Production. Mac/OrbStack is manual recovery only.

Open Production →

fuhuo

Keep the static work entrypoint lightweight

GitHub: mykcs/fuhuo_20260419. Repository contracts plus the Astro build own correctness; Vercel Preview is exact-head opt-in and main spends Production build compute only for real site inputs. Cloudflare is non-canonical.

Open Production →

mykcs.github.io

GitHub as stable gateway, Cloudflare as current homepage

Source now lives in the private mykcs/personal-homepage repository. mykcs.github.io is a separate public compatibility gateway for old links; wangrui92.pages.dev currently serves the real site and owns canonical identity. Ordinary Previews still use Wrangler Direct Upload and remain noindex.

Back to home →

Flow for an ordinary change

  1. Classify the layer first. Source, CI, Preview, Production and monitoring are separate failure domains.
  2. Finish one coherent branch / PR. Prefer one atomic update instead of provider-triggering micro-commits.
  3. Run the cheapest deterministic gate first. Structure, unit tests and build checks come before the full browser suite.
  4. Escalate browser acceptance by impact. Local changes test locally; shared/global/CI-planner changes fail closed to full.
  5. Create Preview only when a real page must be inspected.
  6. Verify Production after merge. Main CI, provider deployment status and the public URL are separate evidence.

What this workflow deliberately avoids

  • No 24×7 MacBook CI farm.
  • No generic CI fallback onto research GPU servers.
  • No forcing all three websites onto one provider merely for symmetry.
  • Do not mix deployment quotas with CI compute quotas.
  • Do not weaken final acceptance semantics merely for speed.

This is a human-readable projection of the development workflow. Volatile facts such as required checks, provider triggers, Build Watch settings and quotas are owned by current repository configuration and live provider state.