MemoryGuard v0.7.2

MemoryGuard v0.7.2

This release publishes the complete V2/runtime repair set accumulated after v0.7.1.

• Fixes governed memory write/read identity, deduplication, scope authorization, and body-only MCP writes.
• Repairs context bootstrap, native retrieval, projection, governance, upgrade, and cross-agent control-plane paths.
• Adds the verified Codex Hook trust and lifecycle transport safeguards, including conservative leak cleanup and stdio protocol handling.
• Aligns package metadata and runtime version reporting at 0.7.2.

Validation: the existing full regression suite passed before release packaging; the 0.7.2 wheel and sdist both passed twine check and were published to PyPI.

MemoryGuard v0.7.1

MemoryGuard v0.7.1

Date: 2026-08-14

Status: release-ready; full local regression and package acceptance passed

v0.7.1 is the V2 migration and desktop lifecycle completion release. It keeps
the v0.7.0 V2-only and CodeGraph boundaries while making the normal upgrade,
Agent/Group recovery, projection build, cancellation, and context-governance
paths coherent end to end. The final patch also restores the product-facing History,
Governance, Knowledge, and neuron-graph flows that were still broken behind green
service-level tests.

User-visible changes

• memoryguard upgrade alone selects the canonical user data home, prepares
  and verifies V2, migrates Agent/Group control and data, activates V2, and
  removes the successful migration backup batch. --preview is read-only.
• Bare governance commands and the desktop GUI use the same canonical data
  home from every current directory. Explicit workspace overrides remain
  available for isolated operator workflows.
• Migrated shared/personal groups and bindings remain manageable. Registered
  but unbound Agents can enable a personal memory layer even when no native
  memory file exists.
• File/folder and External MCP dialogs use valid native filters. Discovery
  returns registered product/Profile surfaces, safe source tokens, and stable
  names without exposing candidate paths or reading source bodies.
• Reconstructed projection builds offer only real executable Agent CLIs or the
  explicit deterministic path. A selected engine runs the governed extraction,
  pending-enrichment, apply, canonical-reconciliation, and projection sequence
  in one durable background task. Engine metadata records actual LLM use.
• Build start is scope-exclusive; status survives reload. Cancellation is
  visible, bounded, stops owned CLI children, recovers stale task owners, and
  restores the neuron page on every terminal or error path.
• Rule reconciliation, retrieval, compaction, Knowledge references, and context
  bootstrap use one canonical scope/evidence model. Raw Knowledge or History
  bodies are not copied into automatic context or projection metadata.
• Conversation History cards now keep readable titles/summaries and raw-session
  reads use exactly one business selector all the way through SafeBridge and the
  native V2 boundary. The native identity scrubber no longer deletes the History
  session_id selector, and Windows project-path comparisons are case-normalized.
• Governance recent-write records expose their real Agent/group/provider fields.
  The GUI resolves a friendly Agent name when available and otherwise falls back
  to the stable Agent ID, actor, or provider instead of rendering rows of
  Unknown Agent.
• The Knowledge Library is a product UI again rather than a JSON debug page. The
  restored V2-only bookshelf supports book cards, search, add/reingest, TaskRun
  status, candidate review, deleted-book restore/purge, book detail, document and
  occurrence browsing, settings, and smart-index rebuild without reconnecting the
  retired KnowledgeStore.
• Automatic governance decisions are grouped/collapsible instead of rendering a
  delete log wall. The neuron graph uses compact level-aware layout and root-outward
  soft signal bands with node halos/terminal flashes instead of random projectile-like
  edge particles.
• Graphify is embedded as memoryguard.graphify_core with explicit grammar imports,
  body-free provenance, and package license/notice files. V2 runtime modules keep the
  host-hook implementation behind HostHookExecutor rather than importing the host
  integration layer directly.

Safety properties

• The browser can select an allowlisted engine ID only; executable paths are
  freshly resolved server-side.
• CLI failure fails the build. Deterministic mode never claims llm_used=true.
• Duplicate same-scope starts cannot create two workers.
• Timed out or cancelled processes are terminated, then killed only after a
  bounded grace period; cleanup joins the owned reader and process.
• A stale durable run is cancelled as task_owner_exited; a run owned by a
  different live process is not stolen.
• Successful migration cleanup is batch-scoped. Failed migration evidence is
  retained and never represented as an active runtime.
• Canonical-readiness and History-schema SQLite probes explicitly close their
  read-only handles; repeated bootstrap/history checks no longer pin rules.db
  or content.db on Windows.

Acceptance evidence

• Final local collection: 1884 passed / 0 failed across 205 test files.
  The suite includes a real History user-flow regression:
  SafeBridge.dispatch_api(history_read) ? native V2 History ? Content V2 ? raw turn.
• Final GUI/History/Governance/Knowledge/native cross-check: 422 passed.
• The restored Knowledge bookshelf/detail JavaScript passes node --check; Python
  package compilation and git diff --check pass.
• scripts/accept_v3_1.py passes every V2 binding, source, extraction, projection,
  source-map, export, and precise-delete check.
• Package acceptance: the v0.7.1 wheel has 214 files and the sdist 452 entries;
  both pass metadata checks and contain no bytecode cache or scratch-patch artifacts.
• Isolated Windows installation reports 0.7.1 from package metadata, module
  metadata, and CLI; MCP, GUI, embedded Graphify imports, and CLI help smoke pass.
• Real user-level V1 data migration reached V2_ACTIVE generation 3 with four
  bindings, the shared group, memories, rules, and history verified. The
  successful backup batch was removed; doctor, mcp-status, bare upgrade,
  and Claude Hook status passed afterward.
• Windows machine-readable acceptance scripts pass with a non-ASCII user path.

Graphify remains an optional metadata extraction provider behind MemoryGuard's
trusted CodeGraph adapter/projection. It is not a second runtime or a separate
MemoryGuard PyPI artifact.

Historical release notes: v0.7.0,
v0.6.2, v0.6.1, and v0.6.0.

MemoryGuard v0.7.0

MemoryGuard v0.7.0

This is the V2-only release line.

• V1 production runtime/store modules are physically retired; legacy input is migration-only and non-V2 state fails closed.
• Native Memory, Evidence, History, Source, Binding, Group, GUI, Knowledge, TaskRun, canonical governance, dedup/merge, rollback, and CodeGraph paths are included.
• Graphify metadata-only export/projection is integrated with source role, provenance, source maps, revisions, tombstones, outbox, and bounded graph operations.
• README, Chinese README, CHANGELOG, implementation status, and release notes document the migration and governance boundary.

Validation

• Full local regression: 1761 passed, 0 failed, no skip/xfail.
• V2 retirement + CodeGraph: 15/15.
• Focused release smoke: 22/22.
• Canonical reconciliation: ACCEPTED.
• RuleMerge: 46/46.
• v3.2 acceptance: 27/27.
• Final clean package checks passed; agent-memguard 0.7.0 uploaded to PyPI.

MemoryGuard v0.6.2

MemoryGuard v0.6.2

SQLite compatibility correction for the V2 fail-closed boundary.

Fixed

• Memory, Evidence, and Content schema preflights now inspect a private copy of the SQLite main file plus any -wal/-shm companions.
• Older SQLite builds may checkpoint the temporary connection while it closes, but the live database is never the connection being closed.
• Post-failure no-write assertions establish their physical baseline after reading the expected marker, preventing an older SQLite observer from contaminating the no-write check.

Unchanged

• V2 production cutover semantics remain unchanged.
• Existing V2_ACTIVE workspaces remain active and do not need to re-run prepare or activation.
• Frozen-source migration, readiness evidence, live-source drift verification, native routing, and rollback evidence are unchanged.

Verification

• Full local test suite: 1678 passed / 0 failed.
• GitHub Linux/Python 3.10 is the release gate for this correction.

MemoryGuard v0.6.1

MemoryGuard v0.6.1

Python 3.10 compatibility hotfix for the V2 SQLite fail-closed boundary.

Fixed

• Memory and Evidence stores now preflight existing base schema metadata through SQLite mode=ro before opening any write-capable WAL connection.
• Future or unknown base schema markers therefore fail without changing the physical database image on older SQLite builds.
• V2 migration tests now use genuinely read-only SQLite handles for post-failure observations, avoiding test-induced WAL checkpoints on Python 3.10.

Unchanged

• V2 production cutover semantics remain unchanged.
• Existing V2_ACTIVE workspaces remain active and do not need to re-run prepare or activation.
• Frozen-source migration, readiness evidence, live-source drift verification, native routing, and rollback evidence are unchanged from v0.6.0.

Verification

Local release-candidate verification:

• targeted V2 schema/migration/storage regressions: 81 passed;
• V2 test suite: 591 passed;
• non-V2 test suite: 1087 passed;
• split total: 1678 passed / 0 failed.

This release specifically closes the Linux / Python 3.10 CI failures observed on v0.6.0 before it is considered fully green across the declared Python support matrix.

MemoryGuard v0.6.0

MemoryGuard v0.6.0

MemoryGuard v0.6.0 ships the production V2 cutover path and native V2 data plane.

Highlights

• Separate authoritative V2 SQLite domains for Memory, Rules, Evidence, Content, Runtime, Projection, Assets, CodeGraph, Skills, and System state.
• Four-state cutover manifest with explicit V1_ACTIVE → V2_BUILDING → V2_READY → V2_ACTIVE transitions.
• Packaged memoryguard-v2 operator CLI for zero-write status, frozen-source preparation, and explicit activation.
• Coherent SQLite online-backup migration, immutable source snapshots, source/target digest validation, and repeated live-source drift gates.
• Two-epoch Reference Audit, maintenance/integrity checks, outbox drain proof, and native coverage readiness.
• All 233 registered MCP/CLI/GUI/Hook surfaces explicitly closed: 138 implemented, 95 retired, 0 neutral, 0 blocker.
• V2-native Rule lifecycle, RuleMerge, extraction/enrichment, External MCP, provider control-plane, history, Knowledge reference, and GUI governance paths.
• doctor and mcp-status now work safely in unbound terminals after V2 activation without exposing tenant memory counts.

Upgrading an existing v0.5.x workspace

Package upgrade alone does not activate V2. After upgrading:

memoryguard-v2 status -w .
memoryguard-v2 prepare -w . --apply
memoryguard-v2 activate -w . --confirm V2_ACTIVE

The prepare step preserves legacy V1 data and .memoryguard/migration-backups. Activation performs a fresh live-source drift check before changing the manifest. Do not delete V1 data or migration backups during cutover.

Release verification

• V2 suite: 589 passed
• Non-V2 suite: 1087 passed
• Split full-suite total: 1676 passed / 0 failed
• Production ACTIVE readiness: READY, blockers []
• Reference Audit: 12 domains, PASS, blockers []
• All 12 authoritative SQLite reports: integrity_check=ok, foreign_key_errors=0
• Wheel and sdist: twine check PASS
• Wheel isolated-install smoke: memoryguard 0.6.0, memoryguard-v2 entrypoint PASS

The repository CI additionally validates Python 3.10/3.12 on Linux and Windows runtime-lease behavior before release publication.

MemoryGuard v0.5.2

v0.5.2

Canonical Rule Reconciliation

• Durable rule-intelligence jobs, source links, evidence anchors, projection parity, and safe legacy fallback until readiness is proven.
• Physically read-only diagnostics: canonical status, rule reads, and governance diagnostics never enter a write transaction.
• Live WAL readers observe concurrent committed writes without immutable mode.

Runtime Safety

• Multi-process runtime lease rejects writes from a different build sharing one workspace, preventing split-brain state changes.

Desktop and Neuron Graph

• Fixed workspace launch and detached native window on Windows.
• Folder-style rule habits, subtree drag, denser outward pulses, and connected category links.

History and Knowledge Library

• History mojibake repair and dual-write reconciliation.
• Knowledge deletion trusts scan results; partial or failed scans no longer protect stale indexes.

Release Readme

• Updated English and Chinese README with v0.5.2 highlights and current GUI startup behavior.

Full suite: 1067 passed.

MemoryGuard v0.5.1

v0.5.1

Knowledge Library

• Knowledge ingestion, chunking, distillation, graph, retriever, MCP, GUI modules
• Deletion truth uses scan.files; policy-skipped paths (symlink/oversized/containment) no longer protect stale index
• Unreadable scans fail closed (complete=False) to protect old index

Repo Hygiene

• .gitignore: sqlite run files, tool caches, coverage, temp/logs, env, agent runtime dirs
• .learnings/ migrated to docs/dev-history/
• Removed empty tests/test_projection.py
• gui_quick.py -> scripts/open_gui.py
• Added .github/workflows/repo-hygiene.yml forbidden-artifact gate

Python 3.10 compat

• toml_compat module (stdlib tomllib on 3.11+, tomli backport on 3.10)
• Conditional tomli dependency

Full suite: 928 passed.

MemoryGuard v0.5.0

What's Changed

• fix(merge): close P3 governance gaps by @irisxc4 in #1

New Contributors

• @irisxc4 made their first contribution in #1

Full Changelog: v0.4.0...v0.5.0

MemoryGuard v0.4.0

Highlights

• Scoped mandatory rules with Agent, project, provider, and role targeting.
• Governed local conversation-history archive, import, progressive retrieval, and shared-group authorization.
• Neuron-graph governance controls in the desktop console.
• Hardened Windows Hook UTF-8 handling and runtime write receipts.

Validation

• 508 automated tests passed.
• Source distribution and wheel built successfully; twine validation passed.