search-parity

Regression check for POST /api/metadata/search against a running meta-core. Since v2.0.0 it reads the merged view from the cache database (/meta-core/db-cache/cache.db), which keeps the v1 file:<rid>/<field> layout.

parity.py <cache.db> builds ~230 queries from real records (free text, short tokens, key-set and flat filters, exact/contains, multi-filter). It computes each query's expected result by brute force: one streaming pass over every record, using a port of the Go matchers. Then it diffs that against the live API. Any lost result means the SQL candidate superset dropped a real match.
timing.py [cache.db] times the same query set at limit 100 and 2000.

Run them inside the container. It has python3 and reads the database read-only:

docker cp tools/search-parity metacore-app:/tmp/sp
docker exec metacore-app python3 -u /tmp/sp/parity.py /meta-core/db-cache/cache.db
docker exec metacore-app python3 -u /tmp/sp/timing.py

The reference pass takes ~10 min at 169k records. Records written while it runs can show up as extra at a limit-2000 boundary; check their UUIDv7 time before treating a diff as real.

History: these tools gated the 2026-10 Redis → SQLite cut-over. Results: 0/217 diffs on v1.1.0, and 232/234 on v1.2.0, where the 2 diffs were writes made during the run. See docs/project-architecture/metacore-storage-engine.md in the meta-root.