Release checklist

A dmbridge release is ready when all applicable checks below pass.

Automated checksCopy Anchor Link

npm ci
npm run check
npm test
npm run test:package
npm run package:npm
npm run package:executable

• Command and schema snapshots have no unexplained diff.
• The packed file list contains the compiled CLI, README, license, agent usage guide, connection scripts, and package metadata, with no source tests or local credentials.
• The isolated packed-package smoke test can invoke dmbridge help, dmbridge version, and JSON output.
• Offline tests cover every mutation path and unknown-outcome failure behavior.

Contract reviewCopy Anchor Link

• Help matches the intended public commands.
• JSON remains parseable and versioned.
• stdout/stderr separation and exit codes match the automation reference.
• Account-add input is an exact four-variant schema: Instagram credential, X OAuth client, X callback URL, or X code/state.
• External X credential import accepts secrets only through --request, never echoes token values, and disables dmbridge refresh for that credential.
• New timestamps are ISO 8601 and numeric units are explicit.
• New mutations support dry-run and expose --yes only for confirmation bypass.

Live read-only checksCopy Anchor Link

With explicit owner approval and configured noncritical default accounts, run:

npm run test:live

This suite may read real account metadata and messages. It must remain read-only, skip message-request inboxes with delivery side effects, and never be part of the default or CI test command.

ArtifactsCopy Anchor Link

Create the installable npm package:

npm run package:npm
npm install --global ./dmbridge-<version>.tgz
dmbridge version --pretty

The tarball installs dmbridge as an executable command and requires Node.js 22.12 or newer.

For a single self-contained executable with no runtime installation:

npm run package:executable
./artifacts/dmbridge-<version>-<platform>-<architecture> version --pretty

Deno is used only as the release compiler so the XChat and Juicebox WASM files remain available through the filesystem paths expected by their SDKs. The source, tests, and npm distribution remain Node-based.

GitHub releaseCopy Anchor Link

The tag-triggered .github/workflows/release.yml workflow verifies the package, then builds and smoke-tests native executables on GitHub-hosted macOS, Linux, and Windows runners for both x64 and ARM64. It publishes those six executables, SHA-256 files, a consolidated SHA256SUMS, and the npm tarball to one release.

Before tagging:

1. Set the intended semantic version in package.json and synchronize the root package-lock.json version.
2. Complete the automated, contract, and applicable live read-only checks.
3. Commit and push a clean release commit.
4. Create and push the exact tag derived from package.json.

VERSION=$(node -p "require('./package.json').version")
git tag -a "v$VERSION" -m "dmbridge v$VERSION"
git push origin "v$VERSION"

The workflow rejects a tag that does not exactly match v plus the version in package.json. Only the final publish job receives contents: write; verification remains read-only. Publishing uses the repository-scoped GITHUB_TOKEN, so no personal access token is required.

Generated macOS executables are ad-hoc signed by Deno. Public distribution without Gatekeeper warnings requires a future Developer ID signing and Apple notarization step with repository secrets. Never store signing credentials in the repository.