ssrajadh/sentrysearch

Problem The hardware table in README.md:218-225 is the maintainer's best guess — there's no field data validating which models actually load, run, and produce reasonable timings on which hardware. The maintainer doesn't have a Mac or NVIDIA GPU, so collecting this manually isn't an option. Goal: one command, zero effort The whole design of this feature is anchored on a single principle: a contributor with the right hardware should be able to type `sentrysearch benchmark`, walk away, and come back to a copy-pasteable report block. Nothing else. No supplying their own clip. No typing their own hardware specs. No choosing queries. No editing config. No running multiple commands or post-processing the output. Every other design choice below follows from this principle. If something on the list adds a step for the contributor, it's wrong. Suggested feature A new CLI command, sentrysearch benchmark, that runs the entire flow end-to-end: Auto-detect hardware — OS, CPU, Python version,

Problem sentrysearch/cli.py:1224-1249 calls detect_index() once and reports a single backend/model. A user who has indexed footage under both (for example) gemini and local/qwen8b only sees one of them — there's no way to know from stats that the other index exists. Suggested fix Iterate over all backend/model combinations that have non-zero chunks and print one section per populated index. sentrysearch/store.py already has the backend/model namespacing. If a "list all populated indexes" helper doesn't exist there, add one (e.g. list_populated_indexes() -> list[tuple[str, str | None]]). Then loop over it in stats: Backend: gemini Total chunks: 812 Source files: 20 ... Backend: local (qwen8b) Total chunks: 340 Source files: 10 ... If --json lands first (see #62), this should return a list of objects instead of a single one. Acceptance With two backends populated, sentrysearch stats shows both with separate chunk/file counts. With one backend populated, output is eff

Problem Users have no way to preview what sentrysearch index will do before paying for API calls or kicking off a long local-model run. The chunking math is already available — sentrysearch/chunker.py:118 expected_chunk_spans() returns the spans without splitting any files. Suggested fix Add a --dry-run flag to the index command. When set, scan the directory, compute spans per file, and print a per-file summary plus a total. No API calls, no local model loaded, no files written. Cost estimate math is already documented in the README "Cost" section (1 frame/sec billed for Gemini at $0.00079/frame). Use that to estimate for the Gemini backend. For local/qwen-cloud, just print chunk counts without a dollar estimate. Example output: front_2024-01-15_14-30.mp4 4 chunks (120s) left_2024-01-15_14-30.mp4 4 chunks (120s) --- 8 chunks total, ~240s of footage Estimated Gemini cost (upper bound): ~\$0.19 Note: still-frame skipping is on by default — real cost will be lower for parked/Sent

Problem sentrysearch/cli.py:1224-1249 only emits human-formatted text. Users wiring SentrySearch into shell scripts or other tools have no machine-readable output to parse, and the [missing] marker is mixed into the file string rather than being a separate field. Suggested fix Add --json to the stats command. When set, print a single JSON object: { "backend": "gemini", "model": null, "total_chunks": 1234, "unique_source_files": 42, "source_files": ["/abs/path/a.mp4", "/abs/path/b.mp4"], "missing_files": ["/abs/path/gone.mp4"] } Keep missing_files as its own key (rather than " [missing]" suffixes on source_files) so downstream tools can act on it cleanly. The human path stays exactly as it is today. Acceptance sentrysearch stats --json | jq .total_chunks returns the chunk count. sentrysearch stats (no flag) output is unchanged. Empty-index case still works (--json returns the same schema with total_chunks: 0). Scope Touches only stats in sentrysearch/cli.py plus a test in