# Release and rollback

## Official delivery format

The official browser release is delivered from `dist/release/asuka-designer-<version>/`.
It contains the ten browser runtime files plus `manifest.json`, `SHA256SUMS`, an
initialization example and server configuration notes. npm publication remains
disabled while `private: true` is present in `package.json`.

## Create a candidate

```bash
npm ci
npm run check:release
```

The release gate rebuilds the product, verifies all checks, and creates the
versioned artifact. Never edit files inside `dist/release` manually.

## Tag and publish

1. Update `package.json` and `CHANGELOG.md`.
2. Run `npm run check:release` locally.
3. Commit the exact tested source state.
4. Create a matching tag such as `v1.0.0`.
5. Push the commit and tag. The Release workflow verifies the tag/version pair,
   rebuilds the candidate, creates zip/tar archives and publishes a GitHub release.

## Deployment

Deploy releases into immutable versioned directories. Switch the customer-facing
loader or server alias only after smoke tests pass. Keep at least the previous two
release directories online so rollback does not require rebuilding old source.

## Rollback

1. Point the loader/server alias back to the previous versioned directory.
2. Purge only the mutable HTML or alias cache; immutable release files stay cached.
3. Confirm license activation, one Fabric view, one Babylon view and one Premium
   module on the restored version.
4. Record the failed version and reason in `CHANGELOG.md` before preparing a fix.
5. Do not reuse or move the failed tag. Publish a new patch or prerelease version.

Database or licensing migrations must have their own backward-compatible rollback
plan before deployment. A browser bundle rollback must never require restoring a
private signing key or license database snapshot.