Repository Catalog

The Repository Catalog is the main place where workspace admins decide which code repositories MergeLoom can use and how tickets route to them.

Open the customer controller, then go to Repositories.

What the Catalog Controls

Use the Repository Catalog to:

sync repositories from GitHub, GitLab, or Azure Repos
enable only the repositories MergeLoom should work on
set repository aliases
choose default branches
configure work and context repository roles
add setup and validation commands
set validation mode
configure repository context and related service context
apply bulk defaults across repositories
search or group repositories by owner, group, or project

Repository Aliases and Routing Labels

Each enabled work repository has an alias. MergeLoom converts that alias into a ticket routing label.

Repository alias	Ticket label
`api`	`repo-api`
`web`	`repo-web`
`server-source`	`repo-server-source`

Use repo-<alias>, not repository-<alias>.

If your workspace has exactly one enabled work repository, MergeLoom can often infer the target repository. If more than one work repository is enabled, add the correct repo-<alias> label, tag, or provider-specific routing value to the ticket, issue, work item, or board item.

Alternative forms such as repo=api and repo:api are accepted by the routing parser and canonicalized to repo-api, but repo-<alias> is the clearest customer-facing form.

Context Sources

Context sources help MergeLoom prepare the run without dumping an entire repository into a prompt.

Repository context is routing-file first. For repository or folder context, MergeLoom looks for guidance files in this order:

MERGELOOM.md
AGENTS.md
provider-specific fallbacks where relevant, such as CLAUDE.md or CODEX.md

Use context sources for:

architecture guidance
coding standards
test strategy
related service notes
selected files or folders
Confluence pages where configured

Keep context small and specific. A short MERGELOOM.md that points to the right files is usually more useful than a long generic instruction block.

Validation Commands

Repository validation commands run in the selected execution path before PR/MR handoff.

Configure:

setup commands
validation commands
validation mode
command timeouts where exposed
provider/model defaults where needed

For Self Hosted workers, the command must also be allowed by the worker runtime. If the repository uses npm, pnpm, dotnet, go, cargo, or make, confirm that command is included in the worker allowed-command list before expecting validation to pass.

Cloud Hosted

In Cloud Hosted mode, MergeLoom-managed workers use the repository catalog to choose the target repository, default branch, context, and validation commands. The controller issues the managed execution path the access it needs for the job.

Self Hosted

In Self Hosted mode, the controller still owns repository catalog settings. The Local Worker UI does not replace the catalog. The worker receives job-scoped repository details when it starts a job, then checks out, validates, and pushes from inside your environment.

Common Failure Modes

Symptom	Check
Ticket is not picked up	The managed label, ready state, assignee, and `repo-<alias>` routing label.
Wrong repository is selected	Repository alias changed after ticket labels were added. Update the ticket label.
Validation command is skipped or fails immediately	Command is not configured, not installed in the worker image, or not allowed by the Self Hosted worker.
PR/MR creation fails	Code host permissions, repository writability, branch existence, and default branch.