Aether Agent 0.3.0 went from GitHub release to npm in under five minutes
Aether Agent's August 22 release notes included an unusually direct availability warning. Version 0.3.0 was absent from npm, no GitHub release existed, and installing aether-agents would still fetch 0.1.0. The only route to the new code was a source build.
That warning was accurate when the maintainers wrote it. The state has since changed. The Aether Agent v0.3.0 GitHub release appeared on August 28 at 12:34:51 UTC. The npm registry record for 0.3.0 followed at 12:39:29 UTC, about 4 minutes and 39 seconds later. npm's latest tag now resolves to 0.3.0.
This short transition exposes a documentation problem common to fast-moving developer tools. Release notes describe what was true at a particular moment. Installers query live distribution state. The two can disagree even when both systems are working as designed.
One version, several observable states
A release is rarely one switch. A tool usually passes through a sequence of states:
- Code and release notes exist on a branch.
- A version tag points to a commit.
- A GitHub release wraps that tag with notes and artifacts.
- A registry accepts the package.
- A distribution tag such as
latestselects that version. - A clean install returns the expected executable and version.
Aether 0.3.0 crossed those boundaries in public. Its repository release notes still record the earlier source-only state and say neither 0.2.0 nor 0.3.0 had been published. The GitHub release now gives an install command for 0.3.0, and npm exposes 0.3.0 as a concrete version and as latest.
The older sentence remains useful historical evidence. Trouble starts when a reader mistakes it for a live installation check.
Automation should store these states separately instead of reducing them to released: true. A small deployment record can keep the version tag, GitHub release status, registry version, selected distribution tag, installed version, and check time. A dashboard can then report “published on GitHub, waiting for npm” instead of turning a normal propagation gap into a mysterious installation failure. The record also explains what happened if latest moves later.
Ask the channel that serves the bytes
Before installing or announcing a tool version, query the same channel the installer will use:
npm view aether-agents dist-tags versions time --json
npm view [email protected] version engines dist.integrity --json
gh release view v0.3.0 --repo AetherAI3/aether-agent
The npm view documentation says the command displays registry data and selects latest when no version is specified. That requires two checks. A named version may exist while latest still points elsewhere. Later, latest may move while an installation command pinned to 0.3.0 remains unchanged.
The current Aether registry record says 0.3.0 requires Node.js 24 or newer. It provides a SHA-512 integrity value, a tarball URL, registry signatures, and an attestation URL with the predicate type SLSA provenance v1. Those fields belong to the package that npm will serve. They are stronger evidence of registry state than prose written before publication.
Provenance has a narrow job
The GitHub release says the npm workflow rebuilds from the tag, creates a CycloneDX SBOM, attests the package, and publishes with provenance. The registry record confirms that version 0.3.0 has an npm provenance attestation.
npm's provenance documentation explains that provenance links a package to source code and build instructions through signed attestations and a public transparency log. It also states that provenance does not prove a package contains no malicious code.
That limit matters for an AI coding agent because installation puts executable code on a development machine. Provenance helps answer where the package came from. It does not establish that every behavior is safe for a particular repository. A team must still examine permissions, release changes, dependencies, and runtime boundaries.
GitHub offers a separate integrity check for immutable releases. Its release verification guide documents gh release verify RELEASE-TAG and gh release verify-asset RELEASE-TAG ARTIFACT-PATH. The guide also notes that the asset command cannot verify GitHub's automatically generated source archives.
Make the install check executable
A release page can say “latest” before a package mirror, cache, or registry tag agrees. A package can be available while a README badge still shows the old version. Documentation should expose that gap by giving readers a command that resolves current state.
For Aether 0.3.0, a cautious check is:
npm view [email protected] version engines dist.integrity
npm install -g [email protected] --ignore-scripts
aether --version
Pinning @0.3.0 prevents a later movement of latest from changing the selected package. Check the engine requirement first so a Node.js mismatch does not masquerade as a tool failure. Running aether --version then compares the registry metadata with the executable found on the current PATH.
The same distinction applies to model IDs, API versions, container tags, and agent plugins. Documentation records an intended or observed state; the distribution endpoint reports current availability. Our guide to durable receipts for completed AI edits separates an operation's recorded outcome from whether a client observed it. Release tooling also benefits from keeping its states separate.
Read past the install command
Aether's release lists durable handoffs, review-to-pull-request commands, six built-in skills, headless JSONL execution, and a local Ollama workflow. It also says production Agent DevSessions are disabled. Hosted coding and the Cloud aether exec driver fail closed, while local Ollama and model-free self-tests remain available.
That limitation changes what a successful installation proves. Version 0.3.0 can be present and correctly verified without every execution path being reachable. Package availability, local capability, service availability, and account entitlement require separate checks.
The gap between GitHub and npm lasted less than five minutes. During that interval, the correct answer to “can I install 0.3.0?” changed. Release automation should treat that answer as live data, attach a timestamp, and verify the exact channel users are about to trust.
