This is a bundled report covering 3 distinct issues discovered during the
same cross-platform audit that produced #687 (resolved) and the
ctx_batch_execute scope issue (opened separately). Each issue below has
its own reproducer prompt and was verified across 4 client/model
combinations on v1.0.146, v1.0.148, and v1.0.151 (current).

────────────────────────────────────────────────────────────────────────
ISSUE A — ctx_insight ignores the `query` parameter (dashboard launcher only)
────────────────────────────────────────────────────────────────────────

Prompt that triggered:
   ctx_insight(query: "What is the practical difference between skill A
                       and skill B in this codebase?")

────────────────────────────────────────────────────────────────────────
ISSUE B — ctx_stats omits cache hit rate, chunk count, last_indexed_at
────────────────────────────────────────────────────────────────────────

Prompt that triggered:
   ctx_stats()
   (run twice — once cold, once after ~6 ctx_search calls — to observe
    what the second call reports vs what's available to compute.)

────────────────────────────────────────────────────────────────────────
ISSUE C — ctx_search applies undocumented progressive throttling (3→2→1)
────────────────────────────────────────────────────────────────────────

Prompt that triggered:
   Issue ctx_search sequentially 5+ times within ~60 seconds, each call
   passing `limit: 3`. Observe the response `limit` shrinking after the
   2nd call.

═══════════════════════════════════════════════════════════════════════
CONTEXT: This bundles 3 issues from an audit that produced 5 findings.
#687 (ctx_index directory)        — RESOLVED in v1.0.149, thank you
#<bug2 number> (ctx_batch_execute) — opened separately yesterday
THIS issue                         — the 3 remaining items below

Bundling these instead of opening 3 separate issues to respect your
time as a solo maintainer. Happy to split into 3 if you prefer — just
say the word.
═══════════════════════════════════════════════════════════════════════

──────────────────────────────────────────────
ISSUE A — ctx_insight ignores `query` parameter
──────────────────────────────────────────────

Tool: ctx_insight
Input: { "query": "<any natural language question>" }
Output:
  - Copying source files...
  - Source files copied.
  - Installing dependencies (first run, ~30s)...
  - Dependencies installed.
  - Building dashboard...
  - Dashboard running at http://localhost:4747
  PID: <pid>

The `query` parameter is accepted by the JSON-Schema but completely
ignored at runtime. The tool only launches a React analytics dashboard
on port 4747. Naming + parameter shape strongly imply Q&A / RAG-style
synthesis over the indexed corpus — that expectation is wrong.

Cross-platform verification (4/4 ignored the parameter identically):
  Claude Code (Opus 4.7)         — dashboard launched, query ignored
  Codex CLI (GPT-5)              — dashboard launched, query ignored
  Antigravity (Gemini 3.5 Flash) — dashboard launched, query ignored
  Antigravity (Gemini 3.1 Pro)   — dashboard launched, query ignored

All 4 LLM agents reached for ctx_insight when asked to "synthesize
an answer about X from the indexed corpus". All 4 had to fall back
to ctx_search after seeing the dashboard URL.

──────────────────────────────────────────────
ISSUE B — ctx_stats observability gap
──────────────────────────────────────────────

Tool: ctx_stats
Input: {} (no args)
Output (current):
  - events count
  - sessions count
  - tokens saved (lifetime + session)
  - % reduction
  - $ saved estimate

What's NOT exposed:
  - cache_hit_rate (nominal hit ratio per query)
  - cache_hits_count / cache_miss_count breakdown
  - total_chunks_indexed (chunks, not MB)
  - last_indexed_at timestamp
  - per-query cache state on subsequent identical queries

Effect: optimizing usage is guesswork. We can only INFER cache
behavior by diffing `tokens saved` between two ctx_stats calls,
which is indirect and noisy. During our v1.0.151 verification of
#687, all 3 IDEs (Opus, GPT-5, Gemini) independently noted: when
calling ctx_index on the same path twice, the response does not
indicate whether the second call hit cache or re-indexed (Codex
measured a ~3% time delta, Opus and Gemini saw none).

Cross-platform verification — all 4 clients had to invent the same
workaround (subtract Fase 1 stats from Fase 6 stats to estimate
session savings, with no way to know hit rate per query).

──────────────────────────────────────────────
ISSUE C — ctx_search progressive throttling (undocumented)
──────────────────────────────────────────────

Tool: ctx_search
Pattern: 5+ sequential calls within a short window (~60s), each
with `limit: 3`.

Observed warning (literal, surfaces in response from call #3 onwards):
  ⚠ search call #N/8 in this window. Results limited to X/query.

Progression we measured:
  Call 1: returns up to 3 results (limit honored)
  Call 2: returns up to 3 results (limit honored)
  Call 3: returns up to 2 results (limit silently cut)
  Call 4: returns up to 1 result (limit silently cut)
  Call 5+: returns up to 1 result (limit silently cut)

This is reasonable rate-limiting behavior, but:
  1. It's nowhere in the tool's JSON-Schema description.
  2. Agents have no signal until the warning appears in a response
     (already too late — the truncated result already shipped).
  3. The exact window size (8 calls) and reset period are not
     documented anywhere we could find.
  4. Workaround (ctx_search(queries: [...])) is excellent but only
     discoverable by reading the warning text mid-session.

Cross-platform verification (3/4 hit the throttle on the same
test):
  Claude Code (Opus 4.7)         — throttle observed at call #3
  Antigravity (Gemini 3.1 Pro)   — throttle observed at call #3
  Codex CLI (GPT-5)              — did NOT hit throttle (suspected
                                   internal cache absorbed repeats)
  Antigravity (Gemini 3.5 Flash) — warning surfaced but reported
                                   less explicitly than the others

The v1.0.149 → v1.0.151 changelog confirms none of these 3 code
paths were touched, so all behaviors persist on current latest.