> ## Documentation Index
> Fetch the complete documentation index at: https://www.mill.fyi/llms.txt
> Use this file to discover all available pages before exploring further.

# Publishing checklist

# Release verification checklist

Use this checklist for the exact revision proposed for release. Record results in the release pull request and CI artifacts. Keep fixture credentials, private screenshots, database dumps, and local verification logs out of the published source and packages.

## Source and application checks

* Run `pnpm verify` against a disposable PostgreSQL database. Resolve formatting, lint, type, integration, dependency-audit, and build failures.
* Manually review desktop and phone routes in light and dark themes, including keyboard and touch controls, long content, loading, errors and retry behavior. Record the routes, states and results reviewed.
* Verify setup, invitations, sign-in, recovery, passkeys, sessions, profile preferences, and account settings. Check configured email delivery and private-link behavior against the documented capability.
* Verify Admin, Member, and Viewer permissions, current membership, last-administrator protection, invitation authority, and session or credential revocation during concurrent requests.
* Verify board and task creation, field updates, comments, notifications, deletion, search, filters, sorting, pagination, and URL restoration. Check concurrency, version conflicts, and idempotent retries without losing drafts or attribution.
* Exercise REST and MCP with actual clients. Check OAuth/PKCE, scopes, approved boards, expiry, and revocation. Preserve the distinction between browser sessions, personal REST keys, and human-owned MCP connections.
* Check shared component reuse, accessible names, focus restoration, reduced motion, bounded popovers, and readable light/dark contrast. Keep success and error feedback in toast alerts.

## Installation and data preservation

* Run `pnpm verify:production` from a clean checkout with the documented package-registry access. Confirm the installation does not require a sibling checkout or private runtime dependencies.
* Verify native `linux/amd64` and `linux/arm64` images, non-root runtime, readiness, persistent PostgreSQL, restart behavior, and the documented HTTPS/proxy configuration.
* Verify the UI and API as separate public HTTPS applications on the same site. Check the UI's no-store runtime API origin, credentialed browser reads and writes, host-only HttpOnly API session cookie, exact UI-origin CORS and CSRF rejection, API OAuth issuer/discovery and MCP resource, and the UI consent redirect.
* Verify a clean baseline installation and rejection of incompatible migration ledgers without changing their data. Before publication, rehearse guarded prelaunch conversion with a recoverable source snapshot and compare retained records. After publication, use forward migrations and keep applied files immutable.
* Create and restore a full database backup in an isolated installation. Verify retained work, account state, credentials, and recovery with the original `MILL_SECRET` and matching configuration.
* Review dependency and image vulnerabilities, licenses, third-party notices, bundled assets, and the distributable file manifest for secrets or private material.
* Check physical passkeys, configured mail delivery, public DNS, certificates, and proxy behavior in the intended deployment environment. Local fixtures do not establish those outcomes.

## Documentation and release artifacts

* Keep installation instructions, configuration, API/MCP contracts, security guidance, release notes, and screenshots aligned with the supported behavior.
* The full source gate includes the documentation link check. Review the rendered documentation at desktop and phone widths in both themes. Use current, crisp screenshots without private data; the manual documentation capture tool is optional.
* Require the `verify` and `production` CI gates for the reviewed commit. Review both architecture packages and validate `SHA256SUMS`, source revision, image architecture, and the packaged notices.
* Verify version/tag metadata, source and release manifests, download destinations, and beginner installation instructions before publishing.
* For the GHCR publisher, require a stable tag on the current `main` revision, the latest exact-commit Required CI result, native API and UI images for both platforms, registry labels, and the paired digest references in `mill-images.json`. Inspect both release installation evidence bundles: each must pull both registry images and pass installation, persistence, backup/restore, HTTPS proxy, and image security checks without rebuilding Mill.
* Confirm the GitHub repository is public and the `ghcr.io/avgeek-oss/mill-api` and `ghcr.io/avgeek-oss/mill-web` packages allow anonymous pulls by digest. Repository visibility does not automatically make an existing GHCR package public. The release workflow fails before publication if either condition is missing.
* Verify a fresh installation from the public release asset and the default image-only Compose file without GitHub or npm credentials. Confirm the Compose and example environment files come from that release tag, and record both image digests. The normal user installation must not require Git, Node, `jq`, or a helper script.
* Record publication and installation separately. Releasing the image does not deploy Mill to any server; a deployment needs its own reviewed image digest, database backup, configuration, and operational checks.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.