Changelog
Release history for pond. Sourced from GitHub Releases.
Full Changelog: https://github.com/tenequm/pond/compare/v0.14.1...v0.14.2
Full Changelog: https://github.com/tenequm/pond/compare/v0.14.0...v0.14.1
Routes the MCP tool surface by intent, adds first-class OpenClaw ingestion, and makes local Lance stores crash-consistent (fsync on write + self-heal on open).
pond_sql_query is now pond_sql, and the single pond_get splits into pond_get_session (reads a whole session) and pond_get_message (expands one message), so each tool routes on caller intent instead of guessing what an id means.serve --with-sync mode that keeps the store fresh while the MCP server runs, and the openclaw-pond plugin to wire it up._versions/ head-down, scan-verifies each manifest by draining a full-column scan, quarantines any crash-poisoned manifest by atomic rename to *.manifest.corrupt (never deletes), then retries the open once. Scan-verify projects every column because a column-update commit (embed's vector write) puts new columns in their own per-fragment data files a narrow scan would skip; file+uring:// stores are healed too.count_rows confirm when that signal says work may be pending, avoiding a full count on every gate.Full Changelog: https://github.com/tenequm/pond/compare/v0.13.2...v0.14.0
Fixes cargo install pond-db, broken for every release since v0.10.0: pond skill embeds SKILL.md via include_str!, but the file was excluded from the published crate, so the .crate on crates.io could not compile. Installs via brew, nix, and cargo-binstall were unaffected (they ship prebuilt binaries). CI now gates packaging so this class of breakage cannot recur.
Cargo.toml's exclude list and adds a check-package CI gate: cargo package --list must contain every include_str!/include_bytes! target, since publishing skips the verify build (publish_no_verify)Full Changelog: https://github.com/tenequm/pond/compare/v0.13.0...v0.13.1
Tool analytics stop paying the JSON tax: the common query shapes now run on three narrow derived columns instead of the multi-GB variant_data blob, turning remote S3 tool GROUP BYs from hard >30s timeouts into ~9s answers (local: 1,693ms -> 48ms, ~35x). Existing stores upgrade themselves in place on first open - no re-ingest, no manual step - but once migrated they are unreadable by older pond binaries, so upgrade every machine that shares a store together.
parts table gains three derived nullable columns - tool_name, call_id, is_failure - plus a BTree scalar index on tool_name. pond <= 0.12.2 enforces strict schema equality, so a store first opened by 0.13.0 becomes unreadable by older binaries, and there is no downgrade path once migrated. variant_data stays the verbatim source of truth; the new columns are derived from it at write time.variant_data (seconds on a local store; one add_columns commit on a remote/S3 store), announced by a single stderr notice. If multiple machines sync into one shared store, upgrade all of them before the first 0.13.0 open - any host still on <= 0.12.2 loses access the moment the store migrates..pond archives keep restoring unchanged: the columns are derived at the read boundary and the archive file is never modified.timeout_seconds on pond_sql_query, --timeout on pond sql (default 30s, clamp 1..600); the timeout error names the knob and steers toward the native columns.tool_name = 'Bash' point filter 4.7-8.0s. Ingest and read benchmarks unchanged within noise.Full Changelog: https://github.com/tenequm/pond/compare/v0.12.2...v0.13.0
Full Changelog: https://github.com/tenequm/pond/compare/v0.12.1...v0.12.2
Sync status now reports genuine work only, and forked subagent transcripts are no longer silently dropped. Verified end to end against the full real corpus (11k+ sessions / 1.8M messages) on both a local store and the S3 backend: ingestion is byte-identical to v0.12.0 except for the recovered data.
/fork subagent transcript (Claude Code >= 2.1.117) opens with a fork-context-ref header row that carries no sessionId, which the adapter rejected as "line 1 missing sessionId" - silently dropping the entire forked conversation. The id is now taken from the first row that carries one (subagents derive it from the path regardless), recovering the full transcript with lossless native restore. Real corpus: 1 of 7,843 subagent transcripts affected, recovered as 16 messages, every other row byte-identical.Full Changelog: https://github.com/tenequm/pond/compare/v0.12.0...v0.12.1
Onboarding and multi-machine sync: a first run no longer looks like it hangs, the scheduled sync no longer races a manual one, and pond status finally reports this host's own relationship to the store. Verified end to end on a fresh install (macOS and Linux) plus cold-context first-run testing.
pond status --format json output shape changed - the adapters field is renamed to source_agents (count of distinct source agents in the store), and schedule changes from a string to an object {active, backend, every}. A new top-level pond_version field carries the producing binary's version so consumers can pin the format going forward. Scripts parsing status JSON must update these keys. (5e56aad)--no-wait skips cleanly (exit 0) and is what the scheduled job passes so ticks never queue. Adds --dry-run (per-adapter freshness preview, writes nothing) and --format json (one summary document on stdout for every outcome, progress on stderr). Every long phase now has a live face - rowmap-build spinner, model-download stage line, per-adapter bar with a recent-rate ETA, inline-embed counter - plus a ~30s heartbeat off-TTY. pond status gains a local section (per-adapter sources + pending-sync counts, last sync outcome incl. a surfaced scheduled failure, next scheduled run) and --hosts fleet view; pond init runs the first sync in the foreground and registers the schedule only after it completes, so a fresh timer never races it. (26a7c7a)pond status no longer fuses long adapter names with their counts and reads "semantic ready (brute-force; index builds at scale)" instead of the alarming "below activation threshold"; empty-store search points at pond init rather than blaming filters that were never set; no-adapters states name pond adapters discover; message deltas are labelled "searchable" so the searchable-vs-total gap stops reading as data loss. (43d53f5)pond status --format json emits a JSON error document on the store-open failure path instead of empty stdout (matching sync --format json); vector search reads "N nearest messages" with a --mode fts caveat so a gibberish query no longer looks like confident relevance; and pond sql/pond search/pond get error text renders CLI verbs instead of the shared module's MCP tool/resource names. (9423535)init schedule registration, reject un-embeddable XDG_STATE_HOME paths, and DRY the shared status/heartbeat helpers (29a4b3a)Full Changelog: https://github.com/tenequm/pond/compare/v0.11.2...v0.12.0
Full Changelog: https://github.com/tenequm/pond/compare/v0.11.1...v0.11.2
Full Changelog: https://github.com/tenequm/pond/compare/v0.11.0...v0.11.1
The write path becomes append-only - incremental index folds, inline embed at ingest, and delta-only copy - and remote pond_search drops from ~8s to sub-second.
pond sync now embeds each message inline in its ingest commit, and both sync and copy fold the scalar indexes incrementally (optimize_indices(append)) instead of a full create_index(replace=true) rebuild - so the whole-source-column index rebuild that dominated each sync/copy tail (~520s on the real corpus) is gone. pond copy carries only absent-or-grown sessions and appends a grown session's delta rows through the shared ingest write path (append, not merge-insert), keeping remote copies bandwidth-bound rather than commit-latency-bound.pond_search drops from ~7.9s to sub-second (best 224ms) on the full S3 corpus (11,788 sessions / 2.14M messages). Two stages did work the query never needed. has_embeddings answered "does this store have embeddings?" with an IsNotNull(vector) scan of the entire vector column (6.8-11.7s per query); it now reads the manifest (index presence, ~0ms) and only falls back to a LIMIT 1 probe when no index exists. Per-hit part summaries fetched file blobs from S3 and scanned parts once per session sequentially; they now skip the blob (the label rides variant_data metadata) and run concurrently. The real retrieval - embed + IVF probe + hydrate - is ~0.1s.from_date/to_date returned empty on remote stores because the messages_timestamp_zonemap mis-prunes the tz-aware timestamp column (ScalarValue::partial_cmp across the tz mismatch prunes every zone). The index is dropped and date bounds run as a refine over the candidate set. Stores that already built it: run pond optimize --drop-index messages_timestamp_zonemap once, or date filters stay empty there.Full Changelog: https://github.com/tenequm/pond/compare/v0.10.2...v0.11.0
A follow-up to the 0.10.1 sync work: the embed stage stops scanning wide columns to find its backlog.
LIMIT 1 read and the backlog gate is a manifest-only count (idle embed-only 2.24s -> 0.67s).embedding_model column instead of decoding the 1.2 GB Float16 vector column to locate unembedded rows (a whole-table vector decode -> 149 KB).Full Changelog: https://github.com/tenequm/pond/compare/v0.10.1...v0.10.2
A sync performance and correctness release: incremental pond sync no longer re-reads the whole corpus on every run.
pond sync is dramatically faster. Two compounding fixes to the freshness path:
last-prompt, permission-mode, bridge-session, ...) with no timestamp, so the watermark peek returned None and ~2,000 of ~9,800 sessions never fresh-skipped - re-decoding ~1.18M already-stored rows every sync. The peek now walks back to the last timestamped row. Measured on the real corpus: claude-code import 20.1s -> 1.76s, rows re-decoded 1.18M -> 10.5k, fresh-skips 7,863 -> 9,823.RLIMIT_NOFILE bump to Unix so the Windows cross-build compiles.ScheduleEvery::secs/from_secs to Unix (dead-code on the Windows target).pnpm/action-setup at docs/site/package.json so the docs site deploys.Full Changelog: https://github.com/tenequm/pond/compare/v0.10.0...v0.10.1
This release rebuilds the admin CLI, the retrieval model, and the sync/copy write path - and makes remote-S3 operation dramatically faster.
[sources.*]/pond sources -> [adapters.*]/pond adapters; config auto-migrates on pond initpond storage use is switch-only (a pure pointer flip, copies nothing); data copy moves to the new top-level pond copy; bare pond storage removed (use pond status)pond export / pond import - snapshot to a .pond archive or .jsonl stream and restore from one is now pond copy --to <file> / pond copy --from <file>pond sync runs import+embed+index by default; the new pond optimize verb runs embed+index on demand, and sync --no-optimize defers to itpond sync no longer discovers or auto-enables adapters - enabling is the explicit job of pond adapters/pond init, so a scheduled sync can never grow the adapter set--config->--config-file, init --schedule->--every, sync --source-dir->--path, sync stage update-indexes->index, --format pretty->text; --storage-path/--config-file are now root-global selectorspond copy requires explicit endpoints, adds the @ (configured store) and local keywords; self-verifying with an id-set completeness check (exit 0 SYNCED / exit 6 missing rows)pond creds {add,list,delete} for URL-scoped credential sets; pond init captures remote creds inline (masked prompt, never argv)mode=vector (default) or mode=fts, plus --sort-by recencysimple tokenizer with English stemmingsync --verify; resident per-session max_ts watermark replaces the version-resolution oraclepond_get/pond_sql_query and unify the transcript rendererpond skill prints the bundled agent-onboarding SKILL.md, in lockstep with the binarypond storage verifyMeasured on the real ~2M-message S3 corpus (Hetzner nbg1); baseline = pre-optimization on this branch.
Sync & status:
versions() per-manifest fetch storm)status -v: 130s -> ~14s; the stale-embedding count that runs in every default sync: 59.5s -> ~7sCopy:
Search:
sql cold 18s -> 5.9ssession-movement-complete completeness rule, the session-erasure exception, and micro-batch live-writeRLIMIT_NOFILE bump to Unix so the x86_64-pc-windows-gnu release binary buildsFull Changelog: https://github.com/tenequm/pond/compare/v0.9.0...v0.10.0
Full Changelog: https://github.com/tenequm/pond/compare/v0.8.1...v0.9.0
Full Changelog: https://github.com/tenequm/pond/compare/v0.8.0...v0.8.1
Full Changelog: https://github.com/tenequm/pond/compare/v0.7.0...v0.8.0
Full Changelog: https://github.com/tenequm/pond/compare/v0.6.0...v0.7.0
Full Changelog: https://github.com/tenequm/pond/compare/v0.5.2...v0.6.0
cargo binstall pond-db