Release Docs

Review every release. Inherit scope and session authorization from Release a New Version. Own documentation and changelog publication through completion, not just the source file or PR. For mobile-only distribution, prepare Mobile notes and review affected mobile and shared documentation. Use the Mobile publication steps below; desktop release/tag checks are not applicable.

Before candidate freeze

1. Read docs/AGENTS.md and New Changelog. Compare all user-facing changes since the previous published release in that stream (previous stable for stable notes) with packages/changelog/content/<stream>/<version>.md, docs/, docs/docs.json, and apps/web/public/llms.txt. Cover guides, installation/upgrade instructions, CLI/MCP/API examples, screenshots, troubleshooting, and platform availability. Preserve external-contributor credits and describe shipped behavior only.
2. Prepare the changelog with its date and plain-text summary. Run changed-file formatting, pnpm -F @anlg/changelog typecheck, and affected web checks from web_ci.yaml/root AGENTS.md. For docs, use the Mintlify version pinned in cli_ci.yaml to run validate and broken-links --check-anchors --check-redirects from docs/; preview affected pages and navigation. Coordinate public skill changes with Agent packages.
3. Merge required content before freezing the candidate. Keep unreleased notes hidden: desktop entries require published, non-draft, non-prerelease GitHub desktop_v<version> releases; mobile entries require verified adjacent publication records as specified in packages/changelog/content/mobile/AGENTS.md. Verify the production index omits the candidate and its direct URL returns 404 before publication. A local production build can test this; vite dev intentionally previews drafts.

Publish with the app

These steps are part of the authorized stable release, without another user prompt. Read desktop_publish.yaml, web_cd.yaml, and apps/web/changelog-build.ts before selecting the deployment; do not assume merging the notes publishes them.

1. Wait for the exact GitHub/CrabNebula app version to be published. A website build made before that event deliberately excludes its notes, even when its source contains the Markdown. Do not weaken that gate or move the desktop tag.
2. Complete the website publication in the same release operation. The desktop workflow currently calls web_cd.yaml through linux-apt-deploy after merging Linux metadata. Follow an existing matching deploy to completion and reuse it if its build began after app publication and its source includes the notes.
3. If no such deployment exists, including when Linux is excluded, verify the approved main source contains the notes and dispatch web_cd.yaml --ref main with gh workflow run. Verify the returned run's headSha against that source and follow it to completion. Avoid duplicate deployments and preserve newer APT metadata; never deploy the old desktop candidate over newer website/package content. If main contains unrelated unapproved web changes, resolve that source scope before deploying and report the concrete publication blocker.
4. Fetch https://anarlog.so/changelog/desktop/<version>/ and https://anarlog.so/changelog/ from the live site. Verify the expected version, summary and release-note sections/body, plus the index link. For the latest desktop release, verify it is marked Latest within the Desktop stream. Verify the legacy /changelog/<version>/ URL redirects to its Desktop page. HTTP 200, a generic page, a source file, a search-engine snapshot, or a green build alone is insufficient. If content is stale, inspect the actual deployment revision and cache response and resolve it within this release operation. Do not report completion with missing notes.
5. Verify GitHub release notes link to the working page and check public download and update routes for the published version. In-app bundled notes, updater payload notes, GitHub release text, and the website are separate surfaces; do not use one as proof of another or promise inline notes where only a link exists.

Mobile publication

1. Prepare packages/changelog/content/mobile/<version>.md before candidate freeze, with the requested audience and platform-specific sections.
2. Follow the coordinator's mobile distribution reference. Verify the exact candidate build is available to the intended testers or public store users; upload/submission success alone is insufficient.
3. Create the adjacent <version>.json using the contract in packages/changelog/content/mobile/AGENTS.md. Include candidate SHA, channel, exact build numbers, per-platform availability timestamps, and evidence links. Record only available platforms; do not infer simultaneous iOS and Android approval. Run the affected web checks.
4. Merge the verified record, then reuse or dispatch the website deployment from approved main within the existing mobile release authorization. A build made before the record was merged deliberately excludes the notes.
5. Verify /changelog/mobile/<version>/, /changelog/?stream=mobile, and the combined index, including full notes, channel, and actual destinations. Add later platform availability to the same record and publish that update. Do not report stable public availability for a beta-only release.

Other documentation and completion

Publish changed Mintlify content through its configured connected deployment and verify the actual changed content at https://docs.anarlog.so, including skill.md, llms.txt, and llms-full.txt when affected. Mintlify and Vercel are separate publication paths; inspect current configuration rather than assuming that a website deployment also updates docs. Reuse unchanged surfaces with evidence.

Return content revisions, validation, website run URL/SHA, live changelog page and index evidence, other published docs, and any blocker or explicit deferral to the coordinator. Do not send announcements or newsletters unless separately requested.