Preview on dev and promote to production

How the two environments map to branches

Branch	Site	Indexed by search engines
main	https://jenksguo.xyz	yes
dev	https://dev.jenksguo.xyz	no (noindex)

Each push to a branch runs CI: translate changed entries into all languages, build, deploy to that branch's site. Admin writes default to main; pass --branch dev (CLI) or "branch": "dev" (REST/MCP) to stage instead.

1. Make changes on dev

jenks admin put content/corpus/projects/smart-energy-meter.md smart-energy-meter.md \
  -m "Smart energy meter: add thesis link" --branch dev

Repeat for as many changes as you like. Each write is one commit on dev.

2. Wait for the deploy

jenks admin deploys --branch dev

Wait until the latest run for dev succeeds. Translation adds a little time when many entries changed.

3. Check the preview

Open the changed pages on https://dev.jenksguo.xyz and at least one translated version, for example https://dev.jenksguo.xyz/ja/projects/smart-energy-meter. Ask the dev assistant a question that touches the change to check the bot picked it up:

jenks ask "What was Jenks's final-year project?" --api https://dev.jenksguo.xyz

4. Promote

jenks admin promote

This merges dev into main and triggers the production deploy. Run jenks admin deploys again to watch it finish, then check https://jenksguo.xyz.

If something is wrong

• Before promoting: fix it on dev with another commit, or revert the change in git.
• After promoting: commit the fix to main directly, or fix on dev and promote again. Git keeps every version, so restoring an earlier file is always possible.
• Merge conflict on promote: someone changed the same file on main directly. Bring dev up to date with main in git, resolve, and promote again.