Skip to content

goldenmatch v1.6.0 - Learning Memory completion

Choose a tag to compare

View all tags
@benzsevern benzsevern released this 05 May 15:10
v1.6.0
6747ad9
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Verified
Learn about vigilant mode.

Headline: Learning Memory loop is now wired end-to-end. Corrections persist across runs, survive row reordering, and surface applied/stale counts in postflight.

What is new

  • Pipeline integration - both _run_dedupe_pipeline and _run_match_pipeline apply learned threshold adjustments before scoring and pair-level corrections after scoring. Both result types carry a new memory_stats: CorrectionStats | None field.
  • Collision-safe vectorized re-anchor - corrections survive row reordering and refreshed inputs via record_hash. Ambiguous re-anchors (duplicate-row inputs) are reported as stale_ambiguous rather than silently misapplied. Vectorized polars hash path; one O(N) pass per apply_corrections.
  • Seven correction collection points - Review Queue, BoostTab y/n, unmerge_record, unmerge_cluster, LLM scorer, agent_approve_reject, and REST POST /reviews/decide all write to MemoryStore when wired with one.
  • Postflight surfaces counts - Memory: N corrections applied, M stale, K stale-ambiguous, J unanchorable.
  • Five new MCP tools - list_corrections, add_correction, learn_thresholds, memory_stats, memory_export. Total goldenmatch MCP tool count: 35 (up from 30).
  • CLI subgroup - goldenmatch memory stats|learn|export|import|show.
  • Python API - goldenmatch.get_memory(), add_correction(), learn(), memory_stats() for programmatic access.
  • Explainer - every review-queue item now carries a one-sentence why. Deterministic by default (zero cost); upgrades to LLM via llm_explain_pair when an API key is set.
  • StrEnum for source/decision - Correction.source and Correction.decision now have CorrectionSource and Decision enums; trust mapping centralized in HIGH_TRUST_SOURCES / trust_for_source().

Zero-config posture preserved

Memory is opt-in via config.memory.enabled (default False). When disabled, behavior is byte-identical to v1.5.0. No new required dependencies.

Test plan

  • ~115 memory tests (48 baseline + ~67 new)
  • 1382 total goldenmatch tests pass on CI (Linux, Python 3.12)
  • 8 end-to-end integration scenarios cover happy path, re-anchor on reorder, edit-on-matchkey staleness, trust conflict, threshold learning, no-API-key explainer fallback, postflight rendering, stale-ambiguous separation

Spec and plan

Both committed under docs/superpowers/specs/2026-05-04-learning-memory-completion.md and docs/superpowers/plans/2026-05-04-learning-memory-completion.md. Two review passes (one against shipped code, one cross-branch) folded in.

Known follow-ups (non-blocking)

  • TS port (goldenmatch-js) does NOT yet have parity for Learning Memory. Tracked as a separate effort.
  • MemoryStore.close() lifecycle could use with memory_store: instead of narrow try/finally.
  • Concurrent SQLite writes test added but skipped pending WAL-mode adoption.
  • Postgres-backend memory store accepted by config but only SQLite is fully exercised by integration tests.
Assets 2
Loading