Changelog
Release history for pond. Sourced from GitHub Releases.
Full Changelog: https://github.com/tenequm/pond/compare/v0.17.2...v0.17.3
agy) sessions, including those its ACP server writes. Both lanes under ~/.gemini are picked up automatically; run pond adapters enable agy if you synced before this release. Restore into agy is not supported, so resume these sessions in another client.systemPromptReport and
skillsSnapshot into each stored session. Both describe the host rather
than the session and carry no conversational content, and together they
were 87-94% of the stored entry. Model, token, cost, timestamp and
lineage fields are unchanged.pond sync report every source up to date and import nothing. If a sync ever silently stored nothing after you moved or restored a store, it will now re-import normally.Full Changelog: https://github.com/tenequm/pond/compare/v0.17.1...v0.17.2
Full Changelog: https://github.com/tenequm/pond/compare/v0.17.0...v0.17.1
pond optimize (~10 min on a remote store) and pond status
shows stemmer outdated until then. Upgrade every host sharing a store
first.pond serve now stops when a supervisor asks it to. It handles SIGTERM
as well
as ctrl-c, and shutdown no longer hangs when an agent is connected: live
MCP
sessions are closed and the drain is bounded, so restarts finish instead
of
waiting for the process to be killed.pond serve reached by a hostname other than localhost now answers MCP
once
you name that host with --allowed-host (or POND_ALLOWED_HOSTS);
without it
the /mcp route refuses every request with 403 while /v1/* keeps
working.
Local use is unchanged.scoop bucket add and the core.longpaths and --target steps a source build needs. Installed via cargo binstall? You have pond.exe only - use Scoop or the zip for scheduled sync.Full Changelog: https://github.com/tenequm/pond/compare/v0.16.3...v0.17.0
pond --help and pond init now show Windows users real Windows
paths (%APPDATA%\pond\config.toml, %LOCALAPPDATA%\pond\data), init
renders cleanly for agents and ssh sessions, creates the store dir it
announces, and reminds you to restart your client after MCP/skill
changes.Full Changelog: https://github.com/tenequm/pond/compare/v0.16.2...v0.16.3
A Windows schedule that can never fire is now diagnosed instead of silently reported healthy. Both failure modes in this release were found live on a real Windows machine after a winget-to-Scoop migration: the scheduled task's action still pointed at the uninstalled binaries (every 5-minute tick died with 0x80070002 FILE_NOT_FOUND while pond schedule status said active), and the task itself had been registered from an elevated shell, so pond schedule start/stop from a normal shell failed with a bare Access is denied. Alongside the fix, Scoop becomes the working Windows install channel: the bucket now genuinely self-updates from each release (its checkver had been broken since creation), each release pings it so new versions land within minutes, and winget leaves the docs until winget-pkgs#419055 merges.
schedule broken (task-scheduler, every 5m) - the registered launcher no longer exists (...); run pond schedule start to re-register, in pond status text and as schedule.problem in --format json. The next-run estimate, the (pond schedule logs) pointer, and the "scheduled sync hasn't completed yet" hint are suppressed for it - that launcher never runs, so the log it points at stays empty. Gated once at derivation so text and JSON agree; exit codes unchanged (broken still exits 0, documented).schtasks /Create//Delete failures over an existing task now explain the trap and name the recovery - pond schedule stop from an elevated shell - checked on task existence, not stderr text, because schtasks messages are localized. pond schedule start warns before registering from an elevated shell, after the already-scheduled no-op return, so only a run that actually registers sets off the note.pondw_bin documents why the current_exe fallback is the designed Scoop path - the shim spawns the real exe as a child and GetModuleFileNameW preserves the stable current junction (measured on a real box 2026-08-26) - and must never canonicalize, which would pin the task to a versioned dir scoop cleanup deletes.Ready / 0).winget install tenequm.pond led the Windows install docs while resolving to "No package found" - the manifest is still in review upstream. Scoop is now the documented channel; the winget install Google.Protobuf / NASM.NASM build prerequisites stay, since those packages resolve fine. winget returns to the docs when the review merges (the CI publish job self-activates the moment the package exists upstream).checkver pointed at the homepage instead of the GitHub repo, so its 4-hourly autoupdate had 404ed on every run since creation, pinning the bucket at 0.14.10 - the pre-NTFS-durability Windows build. Fixed and bumped to 0.16.1 in tenequm/scoop-bucket, and each pond release now dispatches the bucket's updater directly (e623cc8), cutting Scoop lag from up to 4h to minutes.Full Changelog: https://github.com/tenequm/pond/compare/v0.16.1...v0.16.2
Date-filtered search stays correct across compaction. 0.16.0's timestamp zonemap indexes rows by address (fragment id plus offset), and Lance never remaps those addresses when compaction rewrites a fragment - it refreshes the index's fragment list while the index body keeps pointing at fragments that no longer exist. Every pond version's compaction does this, 0.16.0's own included. The result was a date-filtered search that either failed outright (storage_unavailable, naming a missing fragment) or, once a later index fold cleaned up the dangling references, silently dropped the rewritten rows from its results. Ordinary search, pond get-session, pond get-message, and pond sql were never affected, and no data was ever at risk - the index went stale, the store did not.
pond now checks the index against the store's live fragments at the end of every maintenance run and rebuilds it when they disagree. Because the check runs immediately after compaction, a machine repairs its own damage within the same pond sync or pond optimize, and picks up another machine's on the next one. The rebuild only fires when compaction actually rewrote indexed fragments.
Upgrading: just upgrade - a store that is already broken is repaired by the first pond sync or pond optimize a 0.16.1 binary runs, with no manual step (pond optimize --rebuild still works if you want it now). This is the version that ends the cycle: until every machine writing to a shared store is on 0.16.1, any older binary's compaction can break date filters again, so upgrade the writers, not just the readers.
Full Changelog: https://github.com/tenequm/pond/compare/v0.16.0...v0.16.1
Date-scoped search stops full-scanning. The storage engine moves to Lance 10.0.0, and messages gains a timestamp zonemap that prunes date-bounded queries at the index instead of the table: on a 2.9M-row remote store a served --from-date search went from ~2 minutes to 5-6 s (~20x), and the date filter now costs nothing over an unfiltered search instead of +25 s. COUNT pushdown fires under stable row ids too (pond sql count 2.1 s -> 1.3 s). Writes are unchanged: a matched-store A/B measured sync at parity on both cold and warm runs.
Upgrading: nothing manual, but this one is a fleet decision. The zonemap is created on the first pond sync or pond optimize a 0.16.0 binary runs, and pond 0.15.1 and earlier consume that index in the wrong id domain - so an older binary reading the same store returns zero results for date-filtered searches, with no error and no warning (--from-date / --to-date on the CLI, from_date / to_date over MCP). Unfiltered search, pond get-session, pond get-message, and pond sql are unaffected, and the store's data is never damaged: an old reader that upgrades is immediately correct again. Writers are the dangerous case (correction post-release): compaction orphans the zonemap whenever it rewrites fragments the index covers - every version's compaction does this, 0.16.0's own included - after which date-filtered searches on 0.16.0 fail with a storage_unavailable error until pond optimize --rebuild recreates the index. 0.16.1 adds the repair: every pond sync/pond optimize detects the stale index right after compaction and recreates it in the same run. If several machines share one store, upgrade every machine that reads it, not just the ones that write it, and stop the schedule on machines you cannot upgrade yet.
Full Changelog: https://github.com/tenequm/pond/compare/v0.15.1...v0.16.0
Two new harnesses, and the machinery that made them cheap to add. pond now ingests letta-code and grok-build (xAI's grok CLI) sessions, bringing the registry to twelve harnesses, eleven of them auto-discovered. Both adapters were requested by Kyle Little (#170, #171), who runs letta as the orchestrator over codex, pi, claude-code, omp and grok workers, and were the first picked by the roadmap's reaction ordering. Both were built end to end from a new add-adapter playbook and a shared conformance harness - the second one needed zero edits to either, which was the bar the playbook had to meet. Every adapter now carries a docs/adapters/<name>.md spec with an 11-row decision table and a Last verified date against a named upstream version, so "does pond still read this format?" has a written answer instead of a guess.
Upgrading: the new adapters are registered but not enabled on an existing install - pond sync never enables anything as a side effect. Run pond adapters discover (or re-run pond init) once; it finds ~/.letta/transcripts and ~/.grok/sessions and adds them to your config. A relocated LETTA_TRANSCRIPT_ROOT or GROK_HOME is configured as an explicit path.
~/.grok/sessions/<encoded-cwd>/<session-uuid>/updates.jsonl (GROK_HOME honored). Project resolves from summary.json's recorded cwd, then the bucket's .cwd sidecar, then the decoded bucket name - the three places grok writes it, in the order they are trustworthy. Tool calls become an assistant call plus a tool result under one call_id, with both failure modes and an interrupted call covered by the fixture; plans, hook events, image blocks and every x.ai/* extension ride the lossless carrier rather than being dropped.subagents/<child>/meta.json), so the adapter builds the map once and stores each child's meta in its own session - a child restored on its own re-emits the sidecar, which is what makes the per-session round trip exact. Forks, /rewind and compaction are all appends in 1.0.x (measured: the pre-rewind file is a byte prefix of the post-rewind file), so freshness is a bounded tail peek.grok-4.6, swept clean. Verified against grok-build 1.0.5 and the xai-org/grok-build v1.0.6 source snapshot.letta CLI's client-side transcripts at ~/.letta/transcripts/<agent>/<conversation>/transcript.jsonl (LETTA_TRANSCRIPT_ROOT honored). Session identity is the path and the project is the agent id; message ids are position-derived because letta's own letta-msg-<n> ids are process-scoped and repeat inside one conversation. A tool_call row that carries result fields yields both the call and its result under the same call_id./add-adapter (.agents/skills/add-adapter/SKILL.md) is a two-phase playbook: spec the format from the upstream writer code and capture a sandboxed self-capture fixture, then implement from the spec. Its centerpiece is an 11-row decision table (identity, project, ordering, tool correlation, provenance, lineage, non-capture, restore face, freshness oracle, Windows) with each row tied to the spec rule that makes it binding.Foreign for v4/SQLite-origin sessions no released pi can read; that is now a declared downgrade rather than a silent pass.src/adapter/ import-isolated from the store's write path, commit discipline and query plans, which is why "fmt, clippy --all-targets, cargo test green" is the whole bar for an adapter PR. CONTRIBUTING.md, the README's Supported harnesses table with Last verified dates, and spec 6.9 (format archaeology lives in docs/adapters/) round out the contributor flow.lance unit that used to time out kache's 3 s demand ceiling and recompile on every run is restored instead. The remote lives in committed .github/kache/*.toml files selected by KACHE_CONFIG and asserted at bootstrap, which is what let both legs move to kache 0.15.0 and its under-keying fix. Windows release builds go from ~64 min cold to ~20 min warm. The plan with every measurement is docs/plans/2608-24-ci-caching-architecture.md.Full Changelog: https://github.com/tenequm/pond/compare/v0.15.0...v0.15.1
Embeddings are opt-in. Full-text search (BM25) is now the default arm everywhere, and a fresh install no longer downloads a 466 MB embedding model or embeds anything at sync - first import of an 11k-session corpus dropped from 113m56s to 39m22s (2.89x) in the release A/B against a real S3 store. A 63-day usage-trace evaluation (1,126 real searches, docs/researches/) found fts matches or beats vector quality on this workload, which is why the default flipped rather than just the cost.
Upgrading: if you used semantic search and want to keep it, set [embeddings].enabled = true in config (or POND_EMBEDDINGS_ENABLED=1; boolean-ish 1/0/yes/no/true/false all parse). Without it, searches run fts - degraded for meaning-style queries, never broken, and your existing embeddings and semantic index stay untouched on the store for the moment you opt back in. Then re-run pond init - it now detects your existing sync schedule and offers to re-register it, refreshing the unit after the upgrade (or run pond schedule start).
[embeddings].enabled (a5b2779)
mode now resolves to fts on every surface: CLI (pond search), MCP (pond_search), HTTP wire, and the openclaw/pi/hermes plugins. mode=vector on a disabled instance returns a typed refusal naming embeddings.enabled (retryable: false) instead of failing obscurely; the HTTP min_score parameter of an old client is silently ignored, not rejected.pond status -v 79.1s -> 21.6s (3.67x) on the real 2.87M-message S3 store (embedding scans replaced by index-resident reads), status 1.18x, search --mode fts at parity (1.04 +/- 0.16). Baselines in docs/benchmarks/results.md.mode resolves to without reading config. (This commit also carries the release's breaking marker: the squash subject above used the malformed feat!(scope): form the conventional-commit parser ignores.)pond init detects an active sync schedule and offers to re-register it, rewriting the unit with the current template (config-file pin, absolutized paths). The prompt defaults to yes with the current cadence preselected; declining leaves the unit byte-identical. Interactive only, so sandboxed --yes runs can never repoint a real unit. (a5b2779)Full Changelog: https://github.com/tenequm/pond/compare/v0.14.11...v0.15.0
Finishes the Windows port 0.14.10 opened. Local-store durability now behaves the same on NTFS as it does on APFS and ext4, the background sync task no longer flashes a console window or hides its own failures, and pond installs from Scoop today.
Upgrading on Windows: run pond schedule start once. An existing scheduled task keeps its old .cmd + .vbs action chain until it is re-registered - nothing breaks if you skip this, but the console flash and the swallowed exit code stay.
cfg(unix) gate, so a Windows local store had none of it. NTFS journals metadata but not file data, and a local store commits by hard-link-and-rename, so a hard host stop could persist a manifest's name while dropping its bytes. The wrapper is now attached per backend (local vs remote) rather than per platform, and a unit test pins it there - a re-added cfg(unix) would silently un-enforce the rule, which is how the gap survived this long.sync_file_and_parent skips only the directory half on Windows: FlushFileBuffers on a directory handle fails, and object_store, RocksDB, and SQLite all skip it for the same reason. The published file's bytes still go through File::sync_all. Ordering is unchanged, and the residual window no directory fsync can close on Windows stays covered by local-store-self-heal.docs/benchmarks/results.md)..cmd launching a .vbs to hide the console window, and the chain swallowed the sync's exit code - a failing sync reported success in Task Scheduler. It is now a single pondw.exe, a windowless launcher that propagates the real exit code.--state-dir, the argument form of XDG_STATE_HOME, because an Exec action carries no environment block. Gated behind a windows-launcher feature so unix cargo binstall is unaffected.scoop bucket add tenequm https://github.com/tenequm/scoop-bucket then scoop install pond. The winget manifest is generated and submitted by CI, but winget install does not resolve until microsoft/winget-pkgs accepts the first submission - use Scoop until then. PowerShell completions and the Windows install docs ship here too.windows-verify swung between 17m54s and 51m02s on an unchanged dependency tree, with lance and the datafusion set flipping between hit and miss run to run. kache's 2 GiB prefetch cap sits far below a ~790-crate graph where lance alone is 287 MB, so what it dropped was biased toward the largest artifacts; the cap and deadline are now unlimited. The cache store also moves off the network-attached C: onto D:, the fast local volume that already holds target/.Full Changelog: https://github.com/tenequm/pond/compare/v0.14.10...v0.14.11
Windows is a supported platform. This release ships the first Windows binary pond has ever natively built and tested - an x86_64-pc-windows-msvc zip produced and smoke-tested on a real Windows runner, replacing the cross-compiled windows-gnu artifact that no CI had ever executed - alongside adapters that find sessions where Windows actually puts them and unattended sync through Task Scheduler.
The port opened as a community contribution from @BadAd84 in #147. It landed the runtime core, arrived with an end-to-end verification across 331 real sessions, and caught a main-thread stack overflow that an independent clean-room design of the same work missed entirely. Everything else here builds on that foundation.
claude installed from npm is a claude.cmd shim, which CreateProcess never finds because it only appends .exe. PATH resolution is now PATHEXT-aware, and pond init spawns the resolved path through %COMSPEC% /C.StorageUrl::parse with a message naming the alternatives, instead of failing deep inside Lance after object_store has silently dropped the host.~\pond in config now expands like ~/pond. lance expands both and shellexpand only the latter, so the two disagreed and one of them created a literal ~ directory.validate_path_id rejects Windows device names, trailing dots and spaces, and : on every platform - archives are portable, and each of these fails silently on Windows rather than loudly.windows-verify runs the full test suite on a windows-2025 runner for every pull request; windows-dist builds the shipped msvc zip with +crt-static and a Windows application manifest. The never-executed windows-gnu artifact is dropped, and a release cannot be cut without both jobs green.flock belongs to the open file description, so a subprocess spawned while a SyncLockGuard was alive inherited a duplicate and held the lock past drop, making a later acquire report Busy with no holder.[adapters.<name>].path now takes a single directory or an array; an array fans out into one single-path pass per directory, so every configured location rides the same sync while the adapters and the seam stay untouched. A malformed array fails before any store write and pond status names it.pond adapters discover overwriting customized entries, enable leaving a pathless entry that failed every later sync, and openclaw reconciliation across several roots.%LOCALAPPDATA%\pond, config at %APPDATA%\pond\config.toml, with explicit XDG_* overrides still honored on every platform.--version.raw_arg for cmd /C secret commands (MSVCRT escaping is not how cmd parses), a sibling lock-holder file, and protoc vendoring scoped to non-MSVC targets so the existing release build kept working.pond schedule, since verified end to end on Windows 11: registration, cadence round-trip, a tick that runs and logs, and a clean stop.cwd-less subagent transcript derives its project by decoding the project directory rather than reading its own parent directory, which named the subagent folder instead of the project.%APPDATA% before the MSIX package family, the order a real Windows install actually uses; the pi adapter keeps the second separator of a UNC prefix.project is an immutable field, so a stored session whose project now derives differently is refused on re-ingest with immutable_project and reported as a partial sync rather than rewritten. Nothing already stored is lost or changed, and only a fresh store picks up the corrected value.Full Changelog: https://github.com/tenequm/pond/compare/v0.14.9...v0.14.10
Full Changelog: https://github.com/tenequm/pond/compare/v0.14.8...v0.14.9
The get family stops paying S3 for data it already holds resident: message-id resolution and session pages are now served from the mmap'd rowmap, cutting a cold get-session <message-id> from 166s to ~61s and a warm get's S3 round-trips by 63%.
messages.id column - the scan cost ~93s of every by-message-id get and is eliminated on a map hit, which is definitive at any map version because the store is append-only and message ids are immutable. Session pages are likewise served from the map when its version matches the store, with fallback to the scan path on any staleness, corruption, or decode anomaly - staleness can never drop a newly synced message from a page.pond get-session, pond get-message, and pond sql now open with the disk index cache and load the published rowmap chain, giving one-shot CLI reads the same warm path as the MCP server.Full Changelog: https://github.com/tenequm/pond/compare/v0.14.7...v0.14.8
pi gets a memory that outlives the session, and pond gets a way to hand a session back: pond resume restores stored sessions into a client's own files, the pi adapter learns harness-v2 (v4 JSONL and SQLite), and the new pi-pond extension wires recall and resume into pi itself.
pond resume <id> --to <adapter> writes a stored session back out as the target client's own files, whole child lineage or nothing. It never overwrites: every destination is pre-checked and created with O_EXCL, a collision fails the batch before the first byte and names every existing path (exit 3), and a mid-batch write failure unwinds everything it created so no restored file is left behind (exit 4). Fidelity is the system's decision and is reported per session - same-origin replays are native, everything else an honest foreign reconstruction - and pi resume always emits v3, the one format every shipped pi loads (verified against a real pi 0.84.1 install).pi-coding-agent adapter now ingests harness-v2 sessions - v4 JSONL and the SQLite backend - detected per file and per database alongside v3. v4 headers give pi sessions a real parent_session_id and a cwd-derived project. The SQLite freshness watermark runs as four index seeks instead of a UNION ALL over the full mutation history (measured ~59x faster on a 300-session / 300k-row database).pi-pond, the pi extension: one managed pond serve --transport stdio --with-sync child serves the four read-only recall tools and keeps the store synced; /pond <query> searches, then enter resumes a past session in place or i pastes a reference to it. Install with pi install npm:pi-pond.ops/examples/pi-fleet/): dockerized pi workers pushing sessions to one shared S3 store, plus the deployment reference to go with it.pond resume --out-dir ~/.pi/agent would have deleted the user's entire pi state. It now refuses to overwrite anything, ever.pi install npm:pi-pond (pi-pond@0.2.0) and openclaw plugins install openclaw-pond (openclaw-pond@0.1.0) resolve from the registry - no checkout needed.Full Changelog: https://github.com/tenequm/pond/compare/v0.14.6...v0.14.7
Full Changelog: https://github.com/tenequm/pond/compare/v0.14.5...v0.14.6
Full Changelog: https://github.com/tenequm/pond/compare/v0.14.4...v0.14.5
Full Changelog: https://github.com/tenequm/pond/compare/v0.14.3...v0.14.4
Automatic compaction now provably converges: a task filter built on a shrinkability guarantee replaces the fixed row floor that could rewrite wide-row tables forever.
missing_sizes, cannot_shrink, row_target_unattainable, absorb_veto, invalid_byte_budget), and the contract is now a named spec rule, lance-compaction-filter (section 3.4). Verified to reach a fixpoint: the reporter's live canary went 14 -> 6 fragments in one pass and the second pass changed zero files.nix profile add github:tenequm/pond#pond, no quoting and no ?dir=ops/nix leaking the repo layout into the command.Full Changelog: https://github.com/tenequm/pond/compare/v0.14.2...v0.14.3
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