ai-memory v0.8.0

ai-memory v0.8.0 — distributed-coordination (release notes)

Release procedure (operator-gated)

v0.8.0 inherits the v0.7.0 separation of CI verification from publish. ci.yml runs on every push + PR + tag (lint, check matrix, feature gates, dockerfile-validate, coverage). release.yml runs ONLY on explicit workflow_dispatch and handles the actual multi-channel fanout (binary builds + GitHub Release + crates.io + Homebrew tap + GHCR Docker + Fedora COPR).

To publish a tag:

# 1. Create the signed tag locally
git tag -s v0.8.0 -m "..."

# 2. Push the tag — fires ci.yml verification only
git push origin v0.8.0

# 3. Wait for ci.yml to land GREEN (Check matrix is the release gate)

# 4. Manually trigger publish — operator-gated, intentional
gh workflow run release.yml \
  --repo alphaonedev/ai-memory-mcp \
  -f tag=v0.8.0

Pre-release tags (SemVer - suffix, e.g. v0.8.0-rc.1) auto-skip the downstream stable channels (crates.io, Homebrew, Docker, COPR) so operator dry-runs are safe.

The act of releasing is a deliberate, named action — not a side effect of green tests.

Status: RELEASED — GA 2026-06-25. v0.8.0 (distributed-coordination, epic #1709) is generally available. The full CI matrix is GREEN on the release commit; the post-feature multi-agent security review and the v0.8.0 NHI validation findings are closed (see §”Security review + NHI validation” below). Published to every channel — GitHub Release, crates.io, Homebrew, Fedora COPR, GHCR, npm, and PyPI — with binaries for macOS / Linux / Windows / iOS / Android. The v0.8.0 tag is signed and promoted to main.

Headline

v0.8.0 turns ai-memory from a memory substrate into a coordination substrate. Multiple agents (NHIs) working the same namespace can carve work into a typed dependency DAG, take single-holder leases on it, exchange Ed25519-signed signals, gate on attested checkpoints, and replay parameterised routines — all persisted in the same SQLite/Postgres store as memories, under the same attestation posture. Ordinary memories gain a typed-cognition shape (Goal/Plan/Step kinds + a lifecycle + structural links) so a plan and its execution live in one substrate.

The release advances the schema v57 → v70 (all additive), hardens the federation boundary with secure-default flips and per-write/per-transition attestation, and adds Pillar-4 operational controls (HTTP admission control, deferred AGE projection, curator compaction, mandatory-hook presence enforcement). The Claude Code PreToolUse governance hook is reworked so a substrate Refuse actually BLOCKS the tool (see §”Claude Code integration”).

Surface at v0.8.0 (SSOT: src/lib.rs EXPECTED_* consts + src/profile.rs):

Surface v0.8.0
MCP tools (--profile full) 100 advertised (99 callable + the always-on memory_capabilities bootstrap)
MCP tools (--profile core) 7 (original 5 + memory_load_family + memory_smart_load) + the memory_capabilities bootstrap
HTTP routes 91 production .route(...) registrations / 77 unique URL paths
CLI subcommands 83 default build / 85 under --features sal (the gap is Migrate + SchemaInit)
Memory struct 27 fields (adds lifecycle_state)
Schema v70 (CURRENT_SCHEMA_VERSION, both adapters)

Pillar-1 — distributed coordination substrate (#1709)

The coordination machinery, all on both the sqlite and postgres SAL adapters. Full tool reference: docs/coordination.md.

Pillar-2 — typed cognition

Ordinary memories gain the shape of a plan so the coordination DAG has a cognitive counterpart in the memory store itself.

Federation hardening

Pillar-4 — operational controls

Governance + visibility (PE-/#1720 family)

Other notable changes

Claude Code integration

ai-memory ships two managed Claude Code integration surfaces. Full reference: docs/integrations/claude-code.md.

SessionStart boot hook + MCP server (--apply)

ai-memory install claude-code --apply

Installs, inside a clearly-marked managed block in ~/.claude/settings.json (with a timestamped .bak, idempotent):

PreToolUse governance hook (--hook pretool --apply)

ai-memory install claude-code --hook pretool --apply

Installs the PreToolUse governance hook (OPT-IN, scoped to matcher: "Bash|Edit|Write" — the agent-external action surface the rule engine models; the regex also covers MultiEdit / NotebookEdit). Every matched tool dispatch is routed through the substrate agent-action rules engine before it fires.

v0.8.0 change — the hook now actually BLOCKS (#1811)

At v0.8.0 the managed PreToolUse entry is a type:command wrapper running:

ai-memory governance check-action --from-pretool-stdin

The wrapper reads the PreToolUse event off stdin, maps the proposed tool to a substrate action (kind=bash/command for Bash; kind=filesystem_write/path for Edit / Write / MultiEdit / NotebookEdit), evaluates the rules engine, and emits the Claude Code decision contract hookSpecificOutput.permissionDecision so a substrate Refuse actually BLOCKS the tool:

decision Harness behaviour
allow Wrapper emits nothing (exit 0); tool dispatches normally.
warn permissionDecision:"ask" — harness asks the human; the warning lands in signed_events.
refuse / escalate permissionDecision:"deny" — tool dispatch is BLOCKED.

Why the change. The prior type:mcp_tool form could not enforce. Per the Claude Code hooks contract an mcp_tool hook whose tool returns isError:true “produces a non-blocking error and execution continues”, and a tool response that is not the harness decision JSON is “shown as plain text” — so the substrate {"decision":{"decision":"refuse"}} never blocked the tool. The --from-pretool-stdin wrapper owns the contract translation in-binary (it emits permissionDecision:"deny" on a Refuse), restoring real enforcement. The cost is a shell fork + a PATH dependence on ai-memory. Decision recorded via the 5-agent crossroads vote (4d3ea1c5).

Upgrade / migration note

Operators on an older install (where the managed entry is the prior non-enforcing type:mcp_tool form) re-run the installer with --force to migrate the managed entry to the enforcing command form:

ai-memory install claude-code --hook pretool --apply --force

The two install verbs are orthogonal — PreToolUse can be installed / uninstalled independently of SessionStart. Rule authoring + the operator keygen/sign/enable workflow are unchanged (ai-memory rules ...; mutation over MCP is explicitly disabled so a compromised agent cannot weaken its own constraints).

Security review + NHI validation

The post-feature work followed the v0.7.0 testing-loop discipline: a 2-round multi-agent security review of release/v0.8.0 plus a v0.8.0 NHI validation pass against the installed binary. The review surfaced findings #1804#1810 (all triaged legit and fixed — #1804 was the HIGH), and the validation pass surfaced #1811 (the PreToolUse enforcement bug, fixed as documented in §”Claude Code integration”) and #1812. Each was fixed, retested, and closed in-release per the prime directive (no deferrals).

The detailed per-issue write-ups for #1804–#1810 and #1812 are tracked in the GitHub issues + the campaign memory rather than this CHANGELOG; they are summarized here for completeness and to record that the review/validation loop closed green before the (operator-gated) tag cut.

Schema ladder v58 → v70

All additive (CLAUDE.md §Database is the SSOT). Both adapters mirror via src/store/postgres.rs::{migrate_v58 … migrate_v70}.

Schema Change
v58 recall_observations ledger identity binding (agent_id + namespace) (#1705)
v59 Pillar-1 actions / action_edges / leases (#1709)
v60 Pillar-1 signed signals
v61 Pillar-1 attested checkpoints
v62 Pillar-1 routines / routine_runs
v63 memory_links.relation CHECK 6 → 9 relations
v64 typed-cognition memories.lifecycle_state column
v65 memory_links signature-trigger restore (a full-table rebuild silently drops all triggers)
v66 governance_rules.severity CHECK +escalate (PE-5)
v67 memories.target_agent_id_idx visibility generated column (#1720 A)
v68 encrypted_envelope postgres + archive parity (#228 / #1728)
v69 kg_projection_outbox (deferred AGE cold-path, postgres-only) (#1735)
v70 archived_memory_links edge-preservation snapshot (#1771)