Deploying To Production

Deploying to Production

Savecraft has independently versioned components. Each has its own tag prefix, deploy workflow, and relevant paths. Production deploys are triggered by pushing a semver tag.

Step 1: Run the proposal script

Always start by running the script. Do not attempt to find tags or diff history manually.

bash .claude/skills/deploying-to-production/scripts/propose-releases.sh

The script handles tag discovery, path filtering, and net-diff calculation. It only shows components with actual changes (not commits that touched-then-reverted a path).

Step 2: Interpret the output

For each component with changes, review the commits and diff stat. Present a summary table:

Version bump rules

• Minor (X.Y.0 → X.Y+1.0): New features, UI changes visible to users, new MCP tools, new sections, schema migrations, new plugin capabilities
• Patch (X.Y.Z → X.Y.Z+1): Bug fixes, lint fixes, formatting, dependency bumps, copy changes, test-only changes
• When in doubt, prefer minor

Step 3: Confirm and tag

After the user approves, provide the exact git commands:

git tag <tag> && git push origin <tag>

Each tag push triggers its deploy workflow automatically via GitHub Actions.

Component → Deploy Workflow Map

Critical: Reference Module Deploy Targets

Reference modules have split deploy targets depending on their type:

The script handles this automatically. When both cloud and plugin show changes for the same game, both need releases — the view HTML and the WASM binary are separate artifacts.

Datagen artifacts (game-dependabot pattern)

Committed codegen — plugins/magic/parser/data/arena_cards_gen.go and the plugins/{d2r,factorio,rimworld,stellaris}/reference/data/*_gen.{go,rs} files — is version-pinned code, not cadence data. It is regenerated through a reviewed, CI-gated Pull Request, never by the nightly data refresh and never by a direct push to main.

• Refresh command: just datagen-<game> (v1: just datagen-magic). It runs the game's datagen on the host where the game data lives, and only if the artifact changed opens/updates a PR on datagen/<game>-... using the host's existing gh auth (no bot account). A no-diff run is a no-op.
• The nightly just update-mtga populates D1 cadence data only and must never mutate a tracked file. (Cadence data — Scryfall/17lands/rules — lives in D1 and is out of git entirely.)
• Before tagging a plugin-{game}-v release that should carry new game-data coverage (e.g. a new MTGA set), run just datagen-<game>, merge the resulting PR, then cut the tag. The merged codegen is what the WASM/parser build embeds.
• Other games adopt the identical just datagen-<game> shape as their datagen is automated; the rule above is the same for each.

What the script does internally

1. Finds the latest semver tag per family using git tag --sort=-version:refname
2. For each tag, runs git diff --stat <tag>..HEAD -- <paths> to check for net changes
3. Only reports components where the net diff is non-empty (ignores touch-then-revert)
4. Plugin families are discovered dynamically from existing plugin-*-v* tags
5. Path mappings:
   • daemon: internal/ cmd/ go.mod go.sum
   • cloud: worker/ web/ site/ + native TS reference/ dirs + WASM reference/views/ dirs
   • install: install/
   • plugin-{game}: plugins/{game}/ excluding tools/, excluding reference/views/ (WASM) or reference/ (native TS)