[Task] Release ADAMANT IPFS Node v0.1.0 from master

[al-onyxprotocol]

Summary

Release ADAMANT IPFS Node v0.1.0 from master: merge dev into master, re-cut the v0.1.0 tag and GitHub Release from master, confirm the container publication, and announce the first public release.

v0.1.0 is already tagged and published, but from dev. This task moves the released commit onto master, so that master is the branch a release is cut from, and re-runs the release pipeline against it.

Current state

• master holds only the initial commit 64c9672, with LICENSE and a two-line README.md; the whole product lives on dev
• The v0.1.0 tag points at 262464c on dev, published on 2026-09-12 with targetCommitish: dev, not a prerelease and not immutable
• dev is six commits ahead of that tag, through f4d17e0. They touch the workflows, README.md, AGENTS.md, the contributing page, tsconfig.json, and scripts/docker-smoke-test.sh. No src/, no Dockerfile, no package.json, and dist was compared before and after the tsconfig.json change and is byte-identical, so the service runtime and the image contents do not change
• package.json is at 0.1.0, which publish-docker.yml compares against the release tag before building
• ghcr.io/adamant-im/ipfs-node carries 0.1.0 and latest from the dev-based release. That build predates the label fix in 3e4f827, so its org.opencontainers.image.title is the bare repository name rather than ADAMANT IPFS Node
• Publication is now gated on master: publish-docker.yml refuses a tag that is not an ancestor of master, so the existing v0.1.0 tag on dev can no longer publish and must be moved
• CI, Security Audit, Docs, and Container all pass on dev

Publications

• Prepare release notes
• Merge dev into master
• Re-cut the v0.1.0 tag and GitHub Release from master
• Container published to GHCR
• Documentation site serves the released content
• Prepare news article
• Prepare screenshots/video
• GitHub Forum
• News blog
• X post

Additional actions

• Verify that the released tag includes every change merged into dev
• Verify that the tag matches the package.json version 0.1.0
• Verify that CI and Security Audit pass on master
• Verify that Publish container succeeded and that the runtime smoke test passed on linux/amd64 and linux/arm64
• Verify that ghcr.io/adamant-im/ipfs-node:0.1.0 and :latest resolve, run unprivileged, and carry the ADAMANT OCI labels, the SBOM, and the provenance attestation
• Verify that the documentation is updated
• Verify that the API schema is updated
• Verify the README and documentation quick starts against the published image
• Verify the repository presentation: description, topics, website, and the release marked as latest

Notes

The publication gate now points at master

.github/workflows/publish-docker.yml used to require the release tag to be an ancestor of dev, which meant a merge commit on master could not be tagged and published. It now requires the tag to be an ancestor of master, so:

• Chore: Merge dev into master for the v0.1.0 release #38 can be merged with any method, including the GitHub merge button
• a tag left on dev or on a feature branch is refused before anything is built, which is the point: a release comes from master only
• the existing v0.1.0 tag, which sits on dev at 262464c, would now be refused if its release were re-published as is. It has to be moved to the master commit

The Container workflow also runs on master now, so the image publication will build is smoke-tested on both architectures before the tag exists. The branch model is written down in AGENTS.md and on the contributing page.

Re-publishing over the existing tag

The release is not immutable, so v0.1.0 can be deleted and re-created. Re-publishing triggers publish-docker.yml again and overwrites 0.1.0 and latest in GHCR. Re-using the same version number is defensible here because the three commits added since the tag do not touch the runtime, and the rebuild fixes the OCI labels on the published image. If the version number must stay pinned to exactly one artifact, bump to 0.1.1 in the same change instead.

Out of scope

• npm publication: package.json keeps private: true, so this release distributes a container image and a source checkout, not an npm package
• App Store, Google Play, and YouTube steps from the organization release template do not apply to a server-side product
• The documentation site deploys from dev only and deliberately has no release trigger (Chore: Drop the unreachable docs release trigger and keep the image title #36), so merging into master does not redeploy it

[al-onyxprotocol]

Merge step opened: #38 — Chore: Merge dev into master for the v0.1.0 release.

It carries dev at e6ee408 into master, summarizes the whole diff, and records the local validation run. It is not merged yet: the merge method has to be agreed first, because publish-docker.yml gates on the release tag being an ancestor of dev, as described in the notes above.

[al-onyxprotocol]

Releases now come from master, committed straight to dev:

• f5cc5b9 points the publication gate in publish-docker.yml at master instead of dev, extends the Container workflow to master, corrects the stale claim in the Docs workflow comment, and records the branch model in AGENTS.md and on the contributing page
• f4d17e0 fixes a log-flush race in scripts/docker-smoke-test.sh that made the graceful-shutdown check fail intermittently once the workflow started running on master targets as well

Two consequences for this task:

• the merge method for Chore: Merge dev into master for the v0.1.0 release #38 no longer matters; the earlier note about needing a fast-forward is obsolete and the issue body has been updated
• the current v0.1.0 tag sits on dev at 262464c, which the gate now refuses. The tag has to be moved to the master commit before the release is re-published

All checks pass on dev and on #38, including the container smoke test for linux/amd64 and linux/arm64. The gate itself is only exercised when a release is published, so it stays unverified until this release runs.