Mercury host v0.2.0

Mercury host 0.2.0

Minor release. Two headline additions: dispatcher bots — the host schedules agent Runs from a
versioned JSON config, with a cron evaluator, derived idempotency keys, single-flight and a hard
notAfter deadline — and the knowledge system completed, with Atlas 0.1.0 as a second product
on npm. This release also carries Crew role presets, the full mercury host installer/lifecycle
suite, the operator goal surface, and the nightly self-development loop running on its own bot
config.

Install

npm install -g @aywengo/mercury        # 0.2.0

Or:

git clone https://github.com/aywengo/mercury.git
cd mercury
npm ci

Or from Homebrew (formula mercury-ai; homebrew-core owns mercury, the Mercury language
compiler):

brew tap aywengo/mercury https://github.com/aywengo/mercury
brew install mercury-ai

Requires Node.js >= 22.18 and git.

mercury --version prints mercury-host 0.2.0. GET /healthz reports "product": "host" and
"version": "0.2.0".

The CLI

mercuryctl, the operator client, ships inside this same package — there is no separate CLI
artifact, no cli-vX.Y.Z tag and no CLI-only channel. Both binaries arrive with any install
above:

mercury --version        # mercury-host 0.2.0
mercuryctl --version     # mercuryctl 0.2.0

There is deliberately no --token flag on mercuryctl; credentials come from
MERCURY_CLIENT_TOKEN or from the credentials file, which must be mode 0600. New in this
release: mercuryctl create --goal, mercuryctl runs goal, mercuryctl runs goal-cancel, and
tool observability in mercuryctl agents.

Dispatcher bots

A bot is one JSON file at ${XDG_CONFIG_HOME:-~/.config}/mercury/bots/<alias>.json. Every task
has a cron (in tz — UTC, local, or a fixed offset), a task template, singleFlight
(default true: skip if any non-terminal Run of the same bot task exists), onMiss
(skip/collapse/run), and constraints. Dispatch idempotency is derived from
bot-<alias>:<task>:<scheduled wall minute>, so a crash between dispatch and state-write replays
to the original Run.

mercury host bot validate --alias nightly
mercury host bot run --alias nightly          # the scheduler process
mercury host bot dispatch --alias nightly --task <t> [--dry-run] [--yes]
mercury host bot status  --alias nightly
mercury host bot service install --alias nightly

constraints.notAfter (#731) is an absolute deadline that counts queued time: a Run past it is
never started, a running Run is stopped at it. Bot templates set it with notAfterAt: "06:00",
resolved on the fire's local date. A template without constraints.maxDurationMs gets 1 h and
without maxRetries gets 0.

A complete worked example ships at deploy/nightly-bot.json.example (three tasks, DST-aware,
with the pre-first-night checklist in docs/operations.md, section "Running the nightly bot").
Unknown config keys are refused with a did-you-mean hint; triggers and brain are reserved and
refused until B2/B3.

Knowledge system and Atlas 0.1.0

The knowledge system is complete end to end: the agent harvests what it learned before the
workspace is gone, operator notes and decision records in docs/decisions/ enter the pipeline,
a replica pulls from Atlas with provenance, and each Run receives a materialized knowledge pack
(PrimeAgent and Claude Code as skills, Hermes via AGENTS.md). Atlas itself is a separate npm
package (@aywengo/mercury-atlas, 0.1.0) with its own release stream (atlas-v*), systemd unit,
backups and a containerized two-host e2e. See docs/knowledge-base.md and docs/atlas/.

Crew role presets

Runs can carry a role preset: a versioned, registry-backed bundle of agent selection, skill
picks and capability ceilings. Built-ins include implementer, reviewer and planner; a
preset's ceilings can only narrow, resolution is snapshotted onto the Run, the API exposes
GET /api/presets, and the dashboard has a Roles page. The §8 capability vocabulary is enforced
at Run creation.

The operator goal surface

mercuryctl create --goal, mercuryctl runs goal, mercuryctl runs goal-cancel: an operator
can set the objective a Run serves, read back the contract, and cancel an abandoned goal. Goal
status is surfaced beside Run status on every surface, and "never attempted" is distinguishable
from "stopped short".

mercury host installer and lifecycle

The bootstrap-to-operations path is complete: install.sh / mercury host install (CI matrix
over Debian/Fedora containers and macOS), mercury host setup (probe-first wizard, muted token
prompts, safe env charset, unknown-key refusal in answers files, hand-set variables preserved on
re-run), mercury host probe --json, mercury host service, mercury host doctor (dials the
LAN address behind a 0.0.0.0 bind), mercury host status/upgrade/uninstall with a re-run guard
that shows the redacted proposed diff. Every prompt reads /dev/tty or refuses loudly.

The nightly self-development loop

Mercury now maintains itself overnight on a dedicated machine identity: the ladder selector
picks the next issue from GitHub metadata only (never issue text), the e2e skill files deduped
defects, nightly-next drives the ladder with finish/blocked exits, nightly-report files
one digest issue per morning, and the whole schedule runs from the shipped bot config. The
identity cannot merge its own PRs — main-protection requires an approving review. See
docs/nightly-self-development.md.

Fixed in this release

• Skills execute from the Run's stored snapshot, not the live registry (#506). A registry
  change between create and execute no longer alters a queued Run.
• Workspace and git hardening (#509, #621, #705, #567). Every git call is bounded and cannot
  prompt; generated paths are excluded on every Run; the workspace base resolves to an absolute
  path; scp-form repository identities collapse dot segments.
• Capability honesty (#519, #594, #599, #612). A harness that cannot be observed at tool
  level says so instead of staying silent; the claude adapter writes .mercury-context.json like
  the other adapters.
• Atlas fixes (#559, #560, #564). An admin retry no longer replays its own idempotency key;
  note provenance is carried into the replica; a retired note no longer swallows later copies of
  its claim.

The full list is in CHANGELOG.md.

Upgrading

No migration beyond what mercury migrate reports. Restart the API and the worker after
upgrading. Fleet users: the API schema version is unchanged (1) — no Fleet bump is needed.

If you use dispatcher bots, copy deploy/nightly-bot.json.example as a starting point and walk
the checklist in docs/operations.md before enabling the service.

How this was published

Tag host-v0.2.0, built by .github/workflows/release.yml with SLSA provenance via npm trusted
publishing — no publishing credential is stored in the repository. The job submits with
npm stage publish and a maintainer approves with npm stage approve <stage-id> (or sets
NPM_DIRECT_PUBLISH per the runbook). See docs/releasing.md.

npm package awaiting maintainer approval

This run staged the package on the npm registry. Staged publishing defers
proof-of-presence to a maintainer, so npm install will not resolve this version
until it is approved.

npm stage approve 1a453b5d-adb5-4baf-b4b6-8bd9daed4a1d     # needs a 2FA code; run it locally

Or on npmjs.com under Published packages -> Staged packages.

The assets attached to this release and the Homebrew formula are already live and
need no npm approval.

Installer checksum

install.sh sha256: 2e0e7c31d7db9be41431c966b20cac84434817f9a686448e7b9d1b6efc5acdb5

Mercury Atlas v0.1.0

Mercury Atlas 0.1.0

Not published yet. 0.1.0 is not on the npm registry. This file ships in the release PR
so the atlas-v0.1.0 job finds its release body here, and the release notes gain the install
command only when the version is actually on the registry — §15 of
the design forbids advertising an install that does not exist, and
test/releaseDocs.test.ts holds these notes to that rule against the live registry.

Like Fleet's first release, the first @aywengo/mercury-atlas publish cannot come from a tag:
trusted publishing is configured on the package page, which cannot exist before the package
does. releasing.md documents the bootstrap step, which needs an npm
credential and interactive 2FA — a human step — after which the tag path needs no secret.

Atlas is the project knowledge base for Mercury: one service that holds curated project
knowledge and serves it to Mercury hosts, plus a replica per host. It speaks its own /v1
HTTP surface and nothing else: it imports nothing from Mercury or Fleet, and neither of them
imports from it (the coupling rule of §11.6).

What this is

The note store and the curation workflow around it:

• Notes with kinds, scopes and tiers (candidate → promoted → retired), deduplicated by
  claim_hash, with corroboration counted from note_sources on every read rather than cached.
• A gapless per-project seq allocated inside BEGIN IMMEDIATE, so a cursor is a complete
  description of "everything since I last asked". Transitions out of promoted consume a seq
  too, which is how a replica learns to drop a retired note; deletion is a sequence-bearing
  tombstone (#590).
• Two token classes. Contributor tokens are stored only as SHA-256; a note's hostId comes from
  the token binding, never the request body. Operator notes are an admin act.
• Redaction on write and again on every read, so adding a value to ATLAS_SECRETS takes effect
  immediately rather than requiring a backfill.
• Curation by hand (promote/retire/delete with a recorded reason, operator override for
  tier-1 rejections, #644) and by corroboration: a project's promotion policy auto-promotes a
  claim once it has been seen enough across hosts or harnesses, with one-live-note-per-claim
  backed by a partial UNIQUE index (#571).
• A retention sweep for stale candidates and retired tombstones (#570), and a project summary a
  reader can hold (#613).
• /healthz in the shape Fleet already probes, /metrics in Prometheus text format.
• The atlas CLI: serve, migrate, project, contributor, metrics, version.
• Refusal to start on a non-loopback bind without TLS: reader bearer tokens would cross the
  network in plaintext, and Atlas holds every project's curated knowledge.

Install

Not yet: this version is not on the registry. When it ships, the install command appears here
and in distribution.md — and not before (§15). From a checkout of
this repository:

npm ci                                   # at the repository root: installs typescript
npm run build:atlas                      # compiles atlas/dist
node atlas/dist/cli.js --help            # or: npm pack atlas/ and install the tarball

Requires Node.js >= 22.18.0. Operator guide: atlas/README.md.

How this version ships

The tag path is atlas-v0.1.0: the workflow verifies the notes file and the package version
before anything irreversible, packs atlas/, installs the packed tarball into a throwaway
prefix and runs the installed atlas --version — the artifact a user would get, not the
workspace — and only then submits to npm. bin is compiled dist/cli.js, never a .ts file:
the failure that lesson comes from is recorded in the comments of tsconfig.fleet.json.

Because Atlas attaches no bundle and has no Homebrew formula, npm is its only installable
artifact. See distribution.md for the channel table and
atlas/CHANGELOG.md for the full notes.

What a Mercury host does with it

Set MERCURY_ATLAS_URL (plus MERCURY_ATLAS_PROJECT, a contributor
MERCURY_ATLAS_TOKEN and MERCURY_ATLAS_HOST_ID) on a Mercury host and it gains the knowledge
transport: an outbox of notes its Runs learned, a pusher that delivers them, a puller that
keeps a local replica, and per-Run knowledge packs materialized into
.mercury/knowledge/NOTES.md. Unset, and the feature does not exist — that is the one
disabled state. The containerized two-host journey is proven by e2e/knowledge.test.ts
(#701).

npm package awaiting maintainer approval

This run staged the package on the npm registry. Staged publishing defers
proof-of-presence to a maintainer, so npm install will not resolve this version
until it is approved.

npm stage approve 03efcea6-ef36-4544-aca1-05fa05467b67     # needs a 2FA code; run it locally

Or on npmjs.com under Published packages -> Staged packages.

Nothing else is attached to this release and there is no Homebrew formula for
Atlas, so approval on npmjs.com is the only way this version becomes installable.

Mercury host v0.1.1

Mercury host 0.1.1

Patch release. This is the first release in which the hermes adapter can execute a Run.
0.1.0 advertised Hermes on GET /api/agents and then failed every Run it was given, so if
you configured Hermes and it never worked, this release is why.

Install

git clone https://github.com/aywengo/mercury.git
cd mercury
npm ci

Or:

npm install -g @aywengo/mercury        # 0.1.1

Or from Homebrew. The formula is mercury-ai, because homebrew-core already owns mercury --
that is the Mercury language compiler:

brew tap aywengo/mercury https://github.com/aywengo/mercury
brew install mercury-ai

Requires Node.js >= 22.18 and git.

mercury --version prints mercury-host 0.1.1. GET /healthz reports "product": "host"
and "version": "0.1.1".

The CLI

mercuryctl, the operator client, ships inside this same package -- there is no separate CLI
artifact, no cli-vX.Y.Z tag and no CLI-only channel. Both binaries arrive with any install
above:

mercury --version        # mercury-host 0.1.1
mercuryctl --version     # mercuryctl 0.1.1

There is deliberately no --token flag on mercuryctl; credentials come from
MERCURY_CLIENT_TOKEN or from the credentials file, which must be mode 0600.

Fixed in this release

A Run can carry zero skills, which is what lets a second harness run at all (#459)

RunService.create() treated an explicitly empty skills array as "unspecified" and fell
through to automatic selection. Automatic selection never returns nothing: its fallback set
guarantees at least one skill. Every Run therefore carried skill ids resolved from Mercury's
own registry.

That is invisible with PrimeAgent, which receives --skill <workspace path>. It is fatal with
Hermes, which receives -s <name> and resolves that name in its own installed-skill store.
None of the fallback names exist there, and Hermes treats an unknown name as a fatal error. The
result on 0.1.0:

run_192792858413439c   FAILED   agent=hermes   488 ms
agent.message: "Error: Unknown skill(s): debugging"

Now an omitted skills still auto-selects, null still means omitted, and an explicitly empty
array means no skills. Existing callers are unaffected.

The tradeoff is deliberate and worth knowing before you use it. Zero skills is currently the
only way to hand a Run to Hermes, which means a Hermes Run receives no skill guidance at all.
Per-harness skill namespaces are designed in
docs/crew/agent-templates.md and
docs/crew/harness-capabilities.md; until those land,
Hermes works and does so unassisted. Hermes is also not the default -- MERCURY_DEFAULT_AGENT
still selects primeagent.

Also in this release

The dashboard has a favicon and brand marks (#429). ui/favicon.svg and ui/favicon.ico,
linked from both dashboard pages. Cosmetic, no behaviour change.

Test-only fixes

• client/test/cli.test.ts no longer reads the operator's real mercuryctl profile (#458).
• client/test/completion.test.ts now enforces its own "no endpoint, no credential" premise
  (#463).

Neither changes runtime behaviour.

Upgrading

No migration. mercury migrate is a no-op against an existing 0.1.0 database; the schema is
unchanged. Restart the API and the worker after upgrading.

How this was published

Tag host-v0.1.1, built by .github/workflows/release.yml with SLSA provenance via npm
trusted publishing -- no publishing credential is stored in the repository. A green run is not
yet an installable version: the job submits with npm stage publish, and a maintainer approves
it with npm stage approve <stage-id>. See
docs/releasing.md.

npm package awaiting maintainer approval

This run staged the package on the npm registry. Staged publishing defers
proof-of-presence to a maintainer, so npm install will not resolve this version
until it is approved.

npm stage approve 9d892b90-b457-496b-ae12-0f4f7cee115c     # needs a 2FA code; run it locally

Or on npmjs.com under Published packages -> Staged packages.

The assets attached to this release and the Homebrew formula are already live and
need no npm approval.

Mercury Fleet v0.1.0

Mercury Fleet 0.1.0

Published. 0.1.0 is on the npm registry and the latest dist-tag points at it:

npm install -g @aywengo/mercury-fleet@0.1.0

It was published by pushing the fleet-v0.1.0 tag through GitHub Actions trusted publishing --
no repository secret -- and carries SLSA v1 provenance bound to that tag and commit.

One caveat about the older 0.0.1-bootstrap: it was a throwaway publish whose only job was to
create the package page that trusted publishing requires before any tag can publish. It is still
on the registry under the bootstrap tag and is not a release. Because fleet --version prints
a compiled constant instead of reading package.json, it reports mercury-fleet 0.1.0 even when
that placeholder is what got installed, so confirm with npm ls -g @aywengo/mercury-fleet
rather than --version if it matters which one you have.

Fleet manages several independent Mercury instances from one place. It speaks each host's public
HTTP API only: it never opens a Mercury database and never imports Mercury code.

What this is

The host registry and probe, plus dispatch, routing, reconciliation, event mirroring, input and
cancellation forwarding, and a Prometheus rollup that merges hosts into one exposition.

Install

npm install -g @aywengo/mercury-fleet
fleet --version      # mercury-fleet 0.1.0

Pin the version if you want to be certain you are not resolving the older 0.0.1-bootstrap
placeholder: npm install -g @aywengo/mercury-fleet@0.1.0.

From a checkout of this repository, with nothing installed:

npm run fleet -- hosts list
npm run fleet -- --help

Requires Node.js >= 22.18.0. Operator guide: fleet/README.md.

What changed since 0.1.0-rc1

0.1.0-rc1 was recorded in the changelog but never published, and it could not have been installed
if it had been. Its package.json pointed bin at cli.ts and shipped TypeScript sources, and
Node refuses to strip types from a file under node_modules on every version that can strip types
at all. npm install would have succeeded and fleet --version would have failed.

0.1.0 ships compiled JavaScript in dist/ with bin at dist/cli.js, which is what the host has
always done. A test now packs the package, installs it into a throwaway prefix, and runs the binary
a user would run, because 187 source-level tests passed against an artifact that could not start.

How this version was published

The package page had to exist before any tag could publish, so 0.0.1-bootstrap was published once
by hand to create it. That was the only Fleet publish that ever needed an npm credential.

0.1.0 was published by pushing the fleet-v0.1.0 tag. The workflow exchanged the Actions OIDC
token for a publish credential, submitted the package through npm staged publishing, and a
maintainer approved the stage with a 2FA code -- so the release records both that it was built from
this repository and that a human was present when it shipped.

The first attempt failed, and the reason is worth recording. npm accepted the OIDC credential,
signed a provenance statement and pushed it to the sigstore transparency log, and only then the
registry rejected the submission with 422 ... Failed to validate repository info, because
fleet/package.json declared no repository for the bundle to be checked against. No rehearsal
could have caught it: npm publish --dry-run performs no registry write, so the check that would
have caught it structurally cannot run before a tag is spent. The fix and its regression test are
in #453.

Full notes: fleet/CHANGELOG.md.

npm package published

This release was staged first, as required by trusted publishing with staged mode: the
workflow submitted the package with an Actions OIDC credential, and a maintainer then approved the
stage with a 2FA code, so the record shows both that the artifact was built from this repository
and that a human was present when it shipped.

npm stage approve 7b835c83-eb8c-4723-a65c-3d3789230a0f   # approved 2026-09-10

@aywengo/mercury-fleet@0.1.0 is now installable and is what the latest dist-tag resolves to.
The version carries two npm attestations, including SLSA v1 provenance bound to
refs/tags/fleet-v0.1.0, commit 11be84eb8b6938d11caaad90e2ee6ca67916af7c, event push, and
build run 34441987472.

Verify independently:

npm view @aywengo/mercury-fleet@0.1.0 dist-tags version
curl -s https://registry.npmjs.org/-/npm/v1/attestations/@aywengo%2fmercury-fleet@0.1.0 | head -c 400

Mercury host v0.1.0

Mercury host 0.1.0

First stable release. Published to the npm dist-tag latest, so a plain install resolves to it:

npm install -g @aywengo/mercury        # 0.1.0
npm install -g @aywengo/mercury@rc     # 0.1.0-rc1, the release candidate it was cut from

The source is identical to 0.1.0-rc1; nothing was merged between them. This version exists to move
latest off a prerelease: 0.1.0-rc1 was published by hand without --tag, and npm applies latest to
any version published without one, prerelease included. npm will not delete latest (400 Bad Request), so
publishing a real release is the only way to correct it. See issue #368.

First public release of the single-host control plane.

Install

git clone https://github.com/aywengo/mercury.git
cd mercury
npm ci

Or:

npm install -g @aywengo/mercury

Or from Homebrew. The formula is mercury-ai, because homebrew-core already owns
mercury -- that is the Mercury language compiler:

brew tap aywengo/mercury https://github.com/aywengo/mercury
brew install mercury-ai

Requires Node.js ≥ 22.18 and git. First Run: QUICKSTART.md.

mercury --version prints mercury-host 0.1.0.
GET /healthz includes "product": "host" and "version": "0.1.0".

What this is

API, worker, SQLite queue, git-worktree workspaces, optional container sandbox,
structured events, dashboard, and adapters (fake, PrimeAgent RPC, Hermes,
Claude Code, declarative local/RPC/remote).

The CLI: mercuryctl

The CLI ships inside this release. mercuryctl has no tag and no package of its own, so there is no
cli-v0.1.0 and nothing to install separately -- installing the host installs the client.
mercuryctl --version prints mercuryctl 0.1.0.

mercuryctl is in this package, so installing the host installs the client. It has
no release of its own and no version of its own; it is versioned and shipped here.

npm install -g @aywengo/mercury
mercuryctl --version

A remote client for Mercury Runs over the public HTTP API: agents list; runs list,
show, create, events, watch, input, cancel, retry; config profiles,
config current; completion bash|zsh|fish; --version. It reads no server, worker,
database or workspace configuration, and none is needed to run it.

Stable surfaces: JSON field names and exit codes. Human output may change without
notice. Credentials never appear in argv, in output, or in a config file's
credential field. Plain HTTP is accepted only for loopback. There is no
certificate-verification escape hatch; use a profile caFile.

Operator guide: docs/client.md. Design and per-milestone status:
docs/cli-tui-design.md.

Not in this release

Crew, OIDC, Fleet (a separate package, see Fleet 0.1.0-rc1), skill-snapshot execution,
production daemon mode, token/cost budget enforcement. For the CLI: the terminal UI
(Milestone 5) is designed but not built, and stays gated on demonstrated need.

mercuryctl was listed here until this release notes file was corrected. It is in
the package -- package.json bin carries it -- so the exclusion was false.

Known limitations: docs/status.md.
Full notes: CHANGELOG.md.

npm package awaiting maintainer approval

This run staged the package on the npm registry. Staged publishing defers
proof-of-presence to a maintainer, so npm install will not resolve this version
until it is approved.

npm stage approve 3e95eada-9c5d-4ba5-a397-3c634785dcc1     # needs a 2FA code; run it locally

Or on npmjs.com under Published packages -> Staged packages.

The assets attached to this release and the Homebrew formula are already live and
need no npm approval.

Mercury host v0.1.0-rc2

Mercury host 0.1.0-rc2

Release candidate, and a test of the release path itself. The source is identical to
0.1.0-rc1 -- [Unreleased] in the changelog was empty when this was cut, so there are
no user-visible changes and none are claimed here.

What is new is the release, not the software. Every submission to npm before this one was either done by
hand or failed before submitting, so the tag-triggered workflow had never completed one. This release
exercises it.

It is submitted to the npm dist-tag rc, so latest is untouched -- and it is staged, not
installable, until a human approves it (see the next section):

npm install -g @aywengo/mercury@rc     # 0.1.0-rc2
npm install -g @aywengo/mercury        # unchanged by this release

Not installable until a human approves the stage

The workflow submits with npm stage publish, which defers proof-of-presence. The version is staged,
not published, and is not installable until approved on npmjs.com under
Published packages -> Staged packages. A green workflow run means "staged", not "installable". That
approval step is one of the things this release is testing.

Install

From a git checkout:

git clone https://github.com/aywengo/mercury.git
cd mercury
npm ci

Or, once the stage above is approved:

npm install -g @aywengo/mercury@rc

Or from Homebrew, which needs nothing from npm. The formula is mercury-ai, because homebrew-core already
owns mercury -- that is the Mercury language compiler:

brew tap aywengo/mercury https://github.com/aywengo/mercury
brew install mercury-ai

Requires Node.js >= 22.18.0 (matching engines.node in package.json) and git. First Run: QUICKSTART.md.

mercury --version prints mercury-host 0.1.0-rc2.
GET /healthz includes "product": "host" and "version": "0.1.0-rc2".

What this is

API, worker, SQLite queue, git-worktree workspaces, optional container sandbox, structured events,
dashboard, and adapters (fake, PrimeAgent RPC, Hermes, Claude Code, declarative local/RPC/remote).

The CLI: mercuryctl

The CLI release candidate is this release candidate. mercuryctl has no tag, no version of its own, no
notes file of its own, and no package of its own -- installing the host RC installs the RC client.
mercuryctl --version prints mercuryctl 0.1.0-rc2.

npm install -g @aywengo/mercury@rc
mercuryctl --version

A remote client for Mercury Runs over the public HTTP API: agents list; runs list, show, create,
events, watch, input, cancel, retry; config profiles, config current;
completion bash|zsh|fish; --version. It reads no server, worker, database or workspace configuration.

Stable surfaces: JSON field names and exit codes. Human output may change without notice. Credentials never
appear in argv, in output, or in a config file's credential field. Plain HTTP is accepted only for
loopback.

Not in this release

Nothing changed relative to 0.1.0-rc1. Declaring 0.1.0 stable is a separate decision tracked separately;
this release deliberately does not make it, because a prerelease leaves latest where it is.

npm package awaiting maintainer approval

This run staged the package on the npm registry. Staged publishing defers
proof-of-presence to a maintainer, so npm install will not resolve this version
until it is approved.

npm stage approve f74d9532-c304-4f4b-b11c-67847dd831ed     # needs a 2FA code; run it locally

Or on npmjs.com under Published packages -> Staged packages.

The assets attached to this release and the Homebrew formula are already live and
need no npm approval.

Mercury host v0.1.0-rc1

Mercury host 0.1.0-rc1

Release candidate. This is the first RC for the 0.1.0 host release. It is published to the
npm dist-tag rc, not latest, so npm install @aywengo/mercury still refuses to pick it up:

npm install -g @aywengo/mercury@rc     # the release candidate
npm install -g @aywengo/mercury        # still 404 until 0.1.0 is tagged

Nothing has been published to npm yet, so latest does not exist for this package either. The
dist-tag matters because npm applies latest to any version published without --tag, prerelease
included -- without it this RC would become what a plain install resolves to.

First public release of the single-host control plane.

Install

git clone https://github.com/aywengo/mercury.git
cd mercury
npm ci

Or:

npm install -g @aywengo/mercury

Or from Homebrew. The formula is mercury-ai, because homebrew-core already owns
mercury -- that is the Mercury language compiler:

brew tap aywengo/mercury https://github.com/aywengo/mercury
brew install mercury-ai

Requires Node.js ≥ 22.18 and git. First Run: QUICKSTART.md.

mercury --version prints mercury-host 0.1.0-rc1.
GET /healthz includes "product": "host" and "version": "0.1.0-rc1".

What this is

API, worker, SQLite queue, git-worktree workspaces, optional container sandbox,
structured events, dashboard, and adapters (fake, PrimeAgent RPC, Hermes,
Claude Code, declarative local/RPC/remote).

The CLI: mercuryctl

The CLI release candidate is this release candidate. mercuryctl has no tag and no package of
its own, so there is no cli-v0.1.0-rc1 and nothing to install separately -- installing the host RC
installs the RC client. mercuryctl --version prints mercuryctl 0.1.0-rc1.

mercuryctl is in this package, so installing the host installs the client. It has
no release of its own and no version of its own; it is versioned and shipped here.

npm install -g @aywengo/mercury
mercuryctl --version

A remote client for Mercury Runs over the public HTTP API: agents list; runs list,
show, create, events, watch, input, cancel, retry; config profiles,
config current; completion bash|zsh|fish; --version. It reads no server, worker,
database or workspace configuration, and none is needed to run it.

Stable surfaces: JSON field names and exit codes. Human output may change without
notice. Credentials never appear in argv, in output, or in a config file's
credential field. Plain HTTP is accepted only for loopback. There is no
certificate-verification escape hatch; use a profile caFile.

Operator guide: docs/client.md. Design and per-milestone status:
docs/cli-tui-design.md.

Not in this release

Crew, OIDC, Fleet (a separate package, see Fleet 0.1.0-rc1), skill-snapshot execution,
production daemon mode, token/cost budget enforcement. For the CLI: the terminal UI
(Milestone 5) is designed but not built, and stays gated on demonstrated need.

mercuryctl was listed here until this release notes file was corrected. It is in
the package -- package.json bin carries it -- so the exclusion was false.

Known limitations: docs/status.md.
Full notes: CHANGELOG.md.

npm package not available for this release

The npm stage publish step failed, so this version is not on the npm registry.
Do not follow any npm install instruction below for this version.

Install this release without npm:

• Homebrew: brew install aywengo/mercury/mercury-ai
• The asset attached to this release: download and unpack the bundle.

The job that produced this release is marked failed so the npm gap stays visible.