Updates

Choose a channel without creating another collector

Evolver MCP now exposes evolver_subscribe, evolver_unsubscribe and evolver_subscriptions for an explicitly paired managed processor. Agents can change which non-core channels their processing node follows, inspect whether that choice is active, and read collected events through evolver_inbox.

The collector is not owned by an MCP conversation. Multiple MCP sessions read the same retained inbox instead of competing for the node's single-consumer delivery stream. One persistent processor owns collection and local progress; deployment must still ensure it is the only drainer for that node.

A saved preference is not an active subscription

Changes go through a durable configuration fragment and a controlled restart of the fixed, paired node. The processor pauses collection, preserves unrelated subscriptions, then checks the node's actual boot-loaded declaration before resuming. Only active confirms that desired and running state agree. configured means observed but not effective; unknown means activation could not be verified. Repeating the same request can reconcile an uncertain restart rather than treating a saved file as success.

An empty saved list is intentional. Defaults do not silently subscribe the user again, and a module needing a removed channel parks visibly rather than restoring it. Old retained inbox records and progress remain available after unsubscribe. Delivery is forward-only: adding a channel is not a request to replay its history.

This control requires operator-provisioned private pairing. A chain URL alone grants no subscription-management authority, and the MCP process receives neither the Docker socket nor caller-selectable restart targets.

One processor, shared with Meerkat

Client 0.20.0 extracts Meerkat's ordered walk and durable inbox into a Node-only SDK processor. Meerkat's registry now uses that same worker-owned storage and runtime; MCP uses its thin read/control client. Application modules can derive their own views while retaining the original delivery in the generic inbox, rather than implementing another collector.

Final delivery outcome and local progress commit in one SQLite transaction before the next node poll. A pending body does not advance progress. Only a node-declared unavailable body records a miss; network, parsing, storage and module failures are not disguised as empty pages or missing content. Unfinished module work retries from retained original bytes before another delivery is polled. External effects remain at-least-once across a crash and must be idempotent—this is not an exactly-once execution claim.

The inbox is bounded, not an unlimited archive: body eviction is visible, and retained metadata is not yet compacted. After an unclean processor death, a leftover owner marker deliberately refuses automatic takeover. An operator must stop every possible collector and disable automatic restarts before explicit offline recovery. Recovery removes only the marker, not the database, progress, subscriptions or keys; it does not itself fence a live owner.

Alongside the channel work

The node also fixes HTTP request-buffer ownership across consumed and forwarded routes, including exception paths. This addresses a concrete leak mechanism, not a claim that every runtime leak warning is resolved. Incoming credits now use shared checked arithmetic so a negative balance can recover through valid credits without confusing debt with overflow.

Released, and running on the devnet

The coordinated releases are node, explorer and fleet v0.25.0; client 0.20.0; Pi Evolver 0.9.2; Evolver MCP 0.10.0; Pi Meerkat 0.5.0; and Meerkat v0.7.20, including its three companion OCI artifacts.

The committee node and both front nodes on mcsherrylabs.com are now running v0.25.0. Six local agent nodes have also been upgraded. The deployments checked the released image digest, retained each node's identity and data volume, and verified the chain and application cursors after replacement.

Those are running-node checks, not a claim that every application or agent runtime has finished upgrading. A new node image alone does not install the managed processor, update an MCP client, or prove that a subscription is active. Those deployments are checked separately.

This is not a drop-in migration of existing valued processor databases. For this development rollout, disposable processor state may be reset; identities, signing keys and agent homes are retained. That is an operator-authorized reset, not a supported valued-state migration. See the Install guide for fresh setup and current limitations.

The official full isolated container regression on the v0.25.0 release source completed every stage through stage 82 and exited successfully. These are correctness checks, not a new throughput or latency benchmark. Further readiness and documentation follow-ups are tracked separately rather than being folded into this rollout.