A review on a real repository indexed 113,768 code units and began an embed
that would have run for about eight hours. Two independent causes, both mine:
1. Nothing excluded anything. Slopo does NOT read .gitignore, so a repo with
node_modules in its ignore file still had all 21,104 files under it parsed -
13,091 of them source. The generated config carried no source_dir_exclude at
all, so the tool reviewed the dependencies instead of the code.
2. Nothing bounded the work. Slopo's own >1000 guard is useless here: it
measures the PRE-EXISTING backlog before indexing, and a fresh database has
no units at all. The guard that exists to protect an agent's latency is
silent in the one case that most needs it.
Measured on that repository:
no excludes 113,768 units ~7.9 h
default excludes 8,607 units ~36 min
default + a server-only scope 1,519 units ~6 min
So: default excludes for vendored and generated directories, ADDED to the
user's own list rather than chosen between (a settings patch replaces a whole
value, so a single sourceDirExclude pattern would otherwise re-enable the 13x
blow-up). And every action now indexes first, checks the backlog against
maxIndexUnits (default 5,000), and refuses with the count, the estimate and the
lever rather than starting the work.
The count comes from slopo's own database via node:sqlite - no new dependency,
and it degrades to the summary line on an older runtime or a locked file. That
matters because `Indexed N` reports only what was NEWLY indexed: on a warm
database it reads zero while the backlog is still full, which is exactly the
state a refusal leaves behind. Caught that hole by running the thing against the
real repository rather than trusting the first version.
Also fixes `status` reporting when the endpoint probe succeeded - the fix from
the previous commit is what made this run reachable at all.
