Scope and exclusions
Deciding what a connector brings in — and what it should not.
Every connector lets you narrow what it ingests. Doing this well is the difference between a system that answers questions and one that returns noise.
Why it matters
A repository with a vendored dependency tree can be ninety percent third-party code. Indexed, it competes with your own code in every result — and it is content nobody will ever need to ask about.
The corpus is not improved by being larger. It is improved by being yours.
What to exclude
- Vendored dependencies and lock files
- Generated code, build output, minified assets
- Binary and media files
- Test fixtures, unless they document intended behaviour
- Anything auto-generated on a schedule
What to keep
- Source you wrote
- READMEs, architecture notes, runbooks
- Configuration that expresses a decision
- Migrations, since they record how the schema got here
How scoping is expressed
It depends on the connector — repositories and branches, file extensions, wiki spaces, projects, channels, folders. Each setup guide lists what that type supports.
Getting it wrong is recoverable
Narrow the scope and re-sync; excluded content stops being searchable. It is not destructive — you are changing what gets indexed, not deleting anything at the source.
Start narrower than feels right. Adding a directory later takes a minute. Working out why results are full of vendored JavaScript takes an afternoon.