Domains

Domains are Scrubby’s foundational unit. Instead of thinking about individual files, domains let Scrubby (and you) think about capabilities: “Authentication”, “Billing”, “API Layer”, “Background Jobs”.

Scrubby discovers domains by analyzing your code’s structure, imports, naming patterns, and directory organization. These aren’t generic labels — they’re derived from your actual code.

Two types of domains

Global domains

Pre-defined domain templates that activate automatically based on your tech stack. When Scrubby detects Ruby in your Gemfile, it activates Ruby-specific domains. When it finds React in package.json, it activates frontend domains.

Global domains cover common architectural patterns:

• Programming languages — Ruby, Python, JavaScript/TypeScript, Go, Java, etc.
• Frameworks — Rails, React, Next.js, Django, etc.
• Architectural concerns — Testing, Database, CI/CD, Documentation, Security.

Global domains carry shared knowledge across many repositories. When the React global domain produces useful findings across many repos, its connections strengthen for everyone. This is why a fresh React app gets reasonable reviews on day one — it inherits global-domain knowledge before its repo-specific domains have been fully established.

Repository-scoped domains

Custom domains unique to your project, discovered during indexing. These capture the specific capabilities of your system — for example, a fintech app might have “Transaction Processing”, “Risk Assessment”, and “Regulatory Reporting” domains.

Repository-scoped domains are where Scrubby’s understanding of your codebase actually lives. They’re refined on every incremental index and on every review.

Domain connections

Domains are connected by weighted edges that represent how tightly coupled different areas are. These weights are learned from three signals:

• Co-change history — domains whose files frequently change together get stronger connections.
• Import relationships — code that imports across domain boundaries creates connections.
• Review findings — when an analysis produces useful findings that span domains, the connection is reinforced. When it runs and finds nothing, the connection weakens.

Higher weights mean changes in one domain are more likely to affect the other. This powers Scrubby’s blast-radius analysis — when you’re about to make a change, Scrubby can tell you which other areas of the codebase might need attention.

How weights evolve

The practical effect: after a few weeks of normal development, the connections you see in scrubby_get_network reflect the architecture of your codebase as your team actually uses it — not as it was a year ago, not as a static-analysis tool would draw it.

For the broader learning loop and how scrubby_report_findings ties in, see Findings & the Learning Loop.

Viewing domains

You can explore your repository’s domains through:

• MCP tools — scrubby_get_domains lists all domains with their patterns and file counts; scrubby_get_network shows the connection graph with weights.
• The dashboard — the repository detail view shows domains and their relationships visually.

In your AI editor, you can ask things like:

"What domains does Scrubby see in this repo?"
"What's connected to the auth domain?"
"What's the blast radius of changing this file?"

The agent will call the appropriate tool and return the answer grounded in Scrubby’s domain map.