Wiki

​

Overview

Sourcebot generates and maintains architecture documentation for your repositories. A background, offline scan reads each opted-in repository with an LLM. It writes Markdown documents into a managed knowledge repository for that repository. The documents cite a repository and file together. This lets agents verify a claim with one read_file call. Sourcebot indexes the documents like any other repository. Agents discover them through the existing grep, read_file, and list_tree tools in Ask Sourcebot and MCP. Each knowledge repository is visible exactly when its owner repository is visible. A full scan organizes documentation around discovered systems:

1. Sourcebot carves the owner’s pinned tree into deterministic, weight-budgeted territories.
2. Territory scouts explore in parallel and identify a few load-bearing systems with code evidence.
3. A system reconciler fuses duplicates, folds satellite candidates into parent systems, and rejects low-value groupings.
4. Per-system surveyors prioritize architectural invariants, cross-cutting flows, tricky contracts, and why-decisions.
5. A taxonomist merge agent curates the final work list. Document agents write it, then the README fan-in builds the overview.

Your catalog is an engineer’s handbook, not an encyclopedia. The pipeline favors a few dense documents over exhaustive feature coverage. Three hard caps protect your scan budget. A scan accepts at most 24 systems, 6 proposed documents per system, and 120 create items in its final work list. These caps are backstops, not content targets. Existing documents can still be kept, merged, or deleted without counting toward the create cap. A document agent must call finish_doc successfully for its own path. If it stops without finishing, Sourcebot nudges it to submit before treating that item as failed. Other document items continue running when one item fails. A delta scan skips territory scouting and reconciliation. It groups affected documents by their existing system folder and runs only the relevant surveyors. Changed owner files that no document cites are sent to every active delta surveyor for adjudication.

​

How agents use it

Generated docs appear as a knowledge-base/ folder inside each repository across search, browse, and agent tools. The folder’s README.md gives you an overview and an index of the generated documents. Searches scoped to a repository include its generated docs. Citations use @file:{repo::path} syntax. When a search covers both knowledge documents and ordinary code, knowledge documents receive a large ranking boost so they appear first. This is a strong preference, not a strict guarantee. The streaming web search UI displays results as they arrive from the search backend, so a knowledge document from a slower shard can appear after earlier code results. Non-streaming search surfaces (such as agent tools and the API) sort all results before returning, so knowledge documents rank first reliably.

​

Enabling Wiki

Wiki requires all of the following:

• Your license includes the knowledge-base entitlement.
• Your config file’s top-level models array contains at least one entry.
• An owner turns on Enabled on Settings → Wiki.
• An owner then chooses repositories with Edit repositories on the same page.

Sourcebot does not scan any repository until Wiki is on and an owner chooses repositories. Turning Wiki off pauses all scans. Docs that Sourcebot already generated stay searchable. Use a repository’s Delete docs action to remove them. While Wiki is off, you can’t change repositories or select Generate now. If your license no longer includes the knowledge-base entitlement, generated docs stay searchable, but Sourcebot stops updating them.

​

Configuration

Owners tune generation on Settings → Wiki → Configuration. Sourcebot stores these settings in its database, so you don’t edit your config file to change them. Models and their credentials stay in your config file. The configuration page lists the entries in your top-level models array. The settings.maxKnowledgeScanJobConcurrency config setting controls how many repositories scan concurrently. Its default is 1. Increasing it multiplies your possible per-job spend by the number of concurrent jobs.

​

Per-stage models and reasoning effort

Knowledge generation runs in four stages. You can choose a model and reasoning effort for each one:

• Discovery runs territory scouts and the system reconciler.
• Survey surveys each canonical system and merges the work list.
• Document generation writes each knowledge document.
• Overview writes the README overview.

A stage without a chosen model uses the first entry in your models array, the same default that Ask Sourcebot uses. To change that default, reorder your models array. Discovery and Overview use the Survey model unless you choose a model for them. Document generation does not inherit a model from another stage. Each stage has its own reasoning effort. No stage inherits effort from another. A stage without a chosen effort works as follows:

• If its model supports reasoning effort, the stage uses high.
• If its model is OpenAI-compatible, the stage shows Model default and Sourcebot sends no effort. Some OpenAI-compatible servers reject an effort for models that do not reason. Choose an effort to send one, or choose Model default to stop sending it.
• If its model does not support reasoning effort, the stage shows Not supported.

Stage efforts replace the model’s own effort or thinking settings from your config file, such as reasoningEffort or thinkingBudget, during scans. Ask Sourcebot still uses those settings. Providers map effort values as follows: Sourcebot resolves all stage settings before it starts the scan. A missing model, unsupported provider, or model setup failure stops the whole scan before it spends tokens. Anthropic models without adaptive thinking log a warning and run without the effort. They keep their existing thinking behavior. Usage rows appear separately for each model. Each generated document records the model that wrote it. README.md records the readme model.

​

Document naming contract

Every newly planned document uses exactly system-slug/concept-slug.md. Both segments use lowercase kebab-case with at most 64 characters. The folder names the canonical system, and the file names a specific concept. The concept name cannot repeat its system folder. Sourcebot also refuses these generic concept names after ignoring case and punctuation: overview, readme, index, doc, docs, documentation, about, misc, general, summary, notes, info, main, other, todo, claude, and agents. Existing documents at legacy paths remain editable, finishable, and deletable. The stricter naming contract applies only when surveyors or the merge agent propose a new path.

​

Repository selection and the settings page

Open Settings → Wiki and choose one of these modes:

• All repos includes every standard repository. New repositories join automatically. Use a repository’s Delete docs action to remove its generated documentation and exclude it.
• Selected repos gives you a searchable picker for an explicit repository list.

Sourcebot scans a newly selected repository as soon as it is indexed. It does not wait for the first scheduled refresh. Select Generate now to scan every selected repository immediately. Each repository shows what is happening right now, with a detail line underneath: Expand a repository to see the current or latest run, its token usage by model, and how much of the Token budget per scan it used. If a repository already has a real root entry named knowledge-base, the settings page shows a conflict state. Generation pauses for that repository until you rename or remove the entry. The per-repository Delete docs action removes the repository’s knowledge repository, clone, and shards. In All repos mode, it also excludes the repository until you select Re-include.

​

Scan modes

The Delta mode is the default. It updates only documents whose cited files changed. It falls back to a full scan for a large diff, missing history, or a last full scan older than 7 days. The Full mode re-verifies every document during each scan cycle. A repository’s first scan is always a full scan. If a full scan fails after its retries, scheduled delta scans back off before they try a full scan again:

• The wait starts at 1 day and doubles with each further failed full scan, up to 7 days.
• During the wait, a scan that is only due for its periodic full scan runs as a delta scan instead, as long as the repository has a previous successful scan.
• A scan that needs a full scan for any other reason is skipped until the wait ends. The scan status keeps showing the last scan that ran.
• A successful full scan ends the backoff. Generate now and the Full mode always run as requested.

Repositories that cite busy shared dependencies re-scan whenever those dependencies change. The Delta mode keeps that work cheap.

​

Scheduling and cost

Scheduled scans refresh according to the Refresh interval setting. The default interval is 24 hours. Sourcebot uses the citation index to skip repositories with no relevant changes. Every job records input, output, cache-read, and cache-write tokens for each model. You can see this usage on Settings → Wiki. The Token budget per scan setting bounds the tokens that your job newly processes. Prompt-cache reads do not count against this budget. Sourcebot caches the agent conversation with supported providers so your long scans re-read context from cache. If your scan exhausts its budget, encounters a structural failure, or an agent’s response is cut off at the model’s output token limit, it fails immediately without a retry. Your scan model calls use a 45 minute transport timeout. Reconciliation and other single-step generations can legitimately exceed typical HTTP header timeouts.

​

Notes

• Sourcebot must index a repository before it can generate the repository’s wiki.
• Generated documents go live as soon as Sourcebot commits them. There is no review queue.
• Use the per-repository Delete docs action as your escape hatch.
• Cloud-licensed deployments receive the entitlement from the license service. Operators must ensure that the entitlement service knows knowledge-base before this release rolls out.