pond

Trust: the README and design docs state plainly that pond does not authenticate, authorize, or model identity; tenant isolation relies on object-store IAM; encryption is an operational concern (bucket SSE / filesystem encryption); and pond holds no keys. That is a transparent boundary statement, but least_privilege scores only 1: the MCP server is registered at user scope by default (claude mcp add -s user) and exposes the read-only pond_sql query tool and the pond_ingest write tool, with no per-tool permission narrowing or confirmation gate. user_confirmation scores 1: pond init writes MCP config, installs skills, and optionally registers scheduled tasks, all side-effecting operations, yet the docs describe no interactive confirmation or dry-run preview (pond sync --dry-run exists, but init itself has no documented confirmation). data_flow_transparency scores 2: the README clearly states that data lands in a local directory or the user's own S3/GCS/Azure, that credentials are supplied via env/file/command, that embedding credentials in URLs and passing secrets on the CLI are explicitly forbidden, and that config show redacts. sensitive_data_handling scores 2: the design docs give concrete credential rules (no userinfo, no argv leakage, _command caching, name-based redaction of key/secret/token/password), but session content itself contains sensitive conversations and redaction is listed as a roadmap follow-up (#167) with no redaction today, hence the deduction. dependency_security scores 1: Cargo.toml shows only a workspace profile, with no dependency list or audit configuration; CI pins third-party actions to commit hashes (a plus), but there is no evidence of dependency vulnerability scanning or supply-chain auditing. external_effects scores 1: pond sync reads local session files, pond copy/migrate write to target storage, and schedule registers system scheduled tasks, all side-effecting; the docs note that copy does not delete the source and migrate is idempotent, but there is no unified confirmation/preview mechanism. rollback scores 1: the docs mention Lance versioning and time-travel, idempotent copy that does not delete the source, and re-runnable migrate, but pond erase is not yet implemented (roadmap item 10), so deletion and recovery paths are incomplete. source_attribution scores 2: the adapter table lists read paths and last verified dates item by item, and the design requires adapter-provenance-required and no-synthesis, giving structural traceability.

Reliability: the README's installation, configuration, adapter table, and design docs are mutually consistent (e.g., embeddings off by default, BM25 default, single-arm retrieval), with no obvious contradictions; however, the README roadmap says "Eleven harnesses" while the adapter table lists 14, a minor count inconsistency, hence 2 rather than 3. dependency_availability scores 1: install channels (Homebrew tap, Scoop bucket, Nix, crates.io, release zip) are described in detail but are all externally hosted resources whose availability static review cannot confirm; building from source requires protoc/NASM and other prerequisites, widening the dependency surface. failure_messages scores 2: the docs repeatedly stress that errors name the file, name the creds set, give migration rewrite recipes, and that config check has distinct exit codes, a well-grounded error design; but no actual error output samples corroborate it.

Adaptability: audience_and_scenarios scores 2, as the README clearly targets multi-client agent users with real usage prompts and a comparison table, making the scenario clear. capability_boundaries scores 2, clearly distinguishing pond from memory tools, noting ingest-only adapters, single-arm retrieval without fusion, and no hosted service, an honest boundary. trigger_precision scores 1: MCP tool triggering depends on the agent deciding when to call pond_search, and the README gives only example prompts, with no trigger conditions or precise tool-description spec. environment_fit scores 2: covers macOS/Linux/Windows and explains PowerShell vs POSIX differences, long paths, and CUDA/Metal/CPU fallback, an adequate environment fit.

Convention: information_architecture scores 2, with a clear README structure (install/usage/design/roadmap) and docs/spec.md as a contract. install_notes scores 3, with extremely detailed install instructions covering multiple platforms, multiple package managers, source-build prerequisites, and troubleshooting. naming_stability scores 1: the README states pre-v1, with schema, wire shape, and config keys all subject to breaking change, and the design docs record renames such as --data-dir→--storage-path, so stability is insufficient. examples_and_faq scores 2, with example commands and prompts but no formal FAQ. known_limitations scores 2: the token statistics doc lists limitations such as 11% underestimation and missing account attribution, and the roadmap flags unimplemented items, but the README body does not collect limitations in one place. license scores 3, with the full Apache-2.0 text present and consistent with the badge. versioning_changelog scores 1: there is a roadmap and release links, but no CHANGELOG file, and the versioning policy is only "pre-v1 may break". maintenance_responsibility scores 1: publisher identity is unverified, there are no SECURITY.md/CONTRIBUTING details, and maintenance ownership is unclear.

Effectiveness: output_usability scores 2: outputs are CLI text, JSON, SQL results, and MCP tool returns, and the docs give concrete queries and formats (--format ndjson), so usability is decent but there are no output samples. marginal_value scores 2: it addresses the real pain point of cross-client session retrieval and is distinguished from memory tools and session search tools, with a concrete value proposition; but similar tools (cass, ctx, deja-vu) already exist, so incremental value needs real-world verification. cost_benefit scores 1: the README cites token cost benchmarks (1.5-3k vs 90-255k), but those are self-reported by the project and were not reproduced in this review; the install footprint is large (about 223MB unzipped on Windows) and requires a Rust toolchain or package manager, so the cost is not low.

Verifiability: claim_traceability scores 1: the README's comparison table and token benchmarks point to docs/benchmarks and pond.locker, but only some docs are present in the repo, so most claims cannot be traced in the supplied files. cross_source_corroboration scores 1: the token statistics doc says it cross-validates against ccusage and Claude Code cost-state, which is self-reported, with no independent third-party evidence; CI config exists but test results are not shown. fact_inference_separation scores 2: the docs fairly clearly separate measured numbers, methods, and limitations (e.g., "transcript underestimates by about 11%", "account attribution only from 2026-08-10"), so facts and inferences are well separated.