Repository rules, context, and validation

Repository rules make MergeLoom predictable. They tell the worker how to understand the repo, what context to apply, what commands it can run, and what must pass before a PR or MR reaches review.

This is configured in the customer controller

Set repository context, run rules, validation commands, and review controls in https://controller.mergeloom.ai. The worker uses those rules when it runs the job on your infrastructure.

Customer controller: context rules give every run the same repository guidance instead of relying on memory or fragile one-off context.

What to configure first

For each work repository, configure:

• repository alias
• default branch
• context rules
• setup commands
• validation commands
• allowed commands
• provider/model defaults if needed
• review rules and diff guard

Customer controller: start in the repository catalog, where each work repo gets the alias, branch, and execution rules used by ticket routing.

Context rules

Context rules should include the information a good engineer would want before changing the repo:

• architecture notes
• coding standards
• test strategy
• module ownership
• migration rules
• API compatibility rules
• files or folders that should be read first

Keep context direct. Good context reduces bad AI output more than long generic instructions.

Validation commands

Start with the commands your team already trusts.

Examples:

pytest
npm test
npm run lint
npm run typecheck
dotnet test

MergeLoom can run setup, unit, integration, regression, or custom validation commands depending on the repository.

In the repository catalog, configure:

• validation mode: Off, Advisory, or Required
• setup commands, one command per line
• validation commands, one command per line

MergeLoom currently runs exactly the commands configured for the repository. Environment strategy is internal and defaults to the custom command path.

Customer controller: define the validation commands. The local worker runs them during execution before the PR or MR reaches review.

Allowed commands

The worker has an allowed command list. Repository validation commands only work when the command name is allowed by the worker runtime.

Current default:

JCA_WORKER_ALLOWED_COMMANDS=git,rg,pytest,python,python3

For Docker Compose installs, this value lives in the worker .env file next to docker-compose.yml. Edit .env, then recreate the containers so the worker loads the new environment value:

docker compose up -d --remove-orphans --force-recreate

For Helm installs, set worker.allowedCommands in your Helm values or with --set, then upgrade the release so Kubernetes rolls the gateway and executor pods:

helm upgrade mergeloom-worker oci://registry-1.docker.io/mergeloom/mergeloom-worker \
  --namespace mergeloom \
  --set worker.allowedCommands="git,rg,pytest,python,python3,npm,pnpm"

Update the allowed commands before expecting the worker to run commands such as:

• npm
• pnpm
• yarn
• uv
• dotnet
• go
• cargo
• make

Keep the list narrow enough to be defensible, but broad enough for real validation. If a validation command uses npm, pnpm, uv, make, or another tool, that tool must be present in JCA_WORKER_ALLOWED_COMMANDS and available inside the worker container.

Review controls

Use review controls to reduce weak AI output before a human reviewer spends time.

Recommended controls:

• agent review pass
• diff guard
• max line-count warning
• validation before review
• clear run trail

The goal is not to remove human review. The goal is to make the PR or MR easier to review.

Preventing vibe coding

Inconsistent AI coding is a real organizational risk when every developer uses different instructions, different context, and a different validation bar.

MergeLoom reduces that risk by applying:

• the same organization rules
• the same repository rules
• the same validation commands
• the same review controls
• the same workflow path

That makes AI coding more repeatable, testable, and auditable.