Skip to content

phpbotscout index

index is a command group rather than a command. On its own it prints help; the work is done by its four subcommands.

Usage

$ phpbotscout index
Manage the knowledge index

Usage:
  phpbotscout index [command]

Available Commands:
  build       Build the index from scratch
  refresh     Re-index only the sources that have changed
  sources     List discovered sources and why each was admitted or rejected
  status      Report what is indexed and how stale it is

Which subcommand to reach for

Subcommand Use it when Touches the forge
build First run, or after anything that changes how content is chunked or ranked yes
refresh Routine top-up — re-indexes only sources whose commit moved yes
sources Working out why a repository is or is not in the corpus yes
status Checking what is indexed and how stale it is no

status reads the local database only, which is what makes it the one to run when discovery is failing: it still answers while the forge is unreachable.

What they share

One database. All four read index.path, defaulting to phpbotscout.db in the working directory — so running them from different directories silently works on different indexes. The daemon's scheduled refresh reads the same key, which is what keeps serve and index status talking about the same database.

One forge credential. build, refresh and sources resolve a token from gitlab.auth, falling back to GITLAB_TOKEN. Cloning works without one because the corpus is public; discovery does not — see the token needs Maintainer.

No subcommand of its own flags. Every one of them defines only -h/--help and inherits the global flags.

What index cannot do

  • It cannot index something outside the corpus predicate, including a repository you name explicitly. There is no --source flag and no config key for one, deliberately — configuration is a request to index and never an authority on visibility.
  • It cannot remove one source from the index. There is no index drop; the way to stop indexing something is for the predicate to stop admitting it, after which the next run stops writing it. Existing rows for that source are not deleted by that alone.
  • It cannot run two writers at once safely. SQLite here is opened as a single connection with a 5-second busy timeout, in write-ahead-logging mode. Running index build by hand while the daemon's refresher is running is safe: readers never wait on the writer, but the two writers take turns, and each may block on the other for up to the busy timeout. Expect a -wal and a -shm file beside the database while any handle is open.