Codebases

What a codebase is

A codebase is one repository or source folder that FixControl's agents are allowed to operate on. It is the object that answers "where does this code live, and how do we reach it".

Two things are deliberately separate:

a connection answers how FixControl reaches your code. GitHub, GitLab and Bitbucket are connected under Settings → Channels → Code & patch delivery (see Git providers). An SSH server or a folder on a computer running the FixControl desktop app is connected under Settings → Infrastructure (see Infrastructure);
a codebase answers which repository, on which branch, and with which settings.

Registering a codebase does not give any agent a reason to touch it; work reaches a codebase only through a project.

You can ask for this instead of navigating to it. Command Center can search your connected providers for a repository you named loosely, resolve a reference, attach and detach one, sync the working copy, and analyse a codebase to regenerate its technical documentation — and it can tell you which repositories a project is bound to.

Connecting a repository to a project

The usual way in is from the project itself: Project → Connections → Connect repository. The wizard walks you through:

Where is the code? — GitHub, GitLab or Bitbucket; More options (technical) offers a server over SSH or a folder on a computer.
Sign in — use a connection your organization already has, or connect a new account. Only an organization admin can connect a new account.
Choose the organization — when the connection can see more than one.
Choose the repository (or, for a server or a folder, the folder).
Choose the branch — FixControl proposes changes against this branch and never pushes to it directly.
Check — Connect to {project} links the repository, and the wizard checks that FixControl can read it.

If a repository is already connected elsewhere in your organization, the wizard offers it under Already connected in your organization, so a second project reuses it instead of adding it twice. A non-admin can link a repository the organization already has, but cannot add a new one.

Settings → Codebases is the alternative, organization-wide view: every codebase your organization has registered, with Add codebase to register one directly. It is an admin page and is part of the engineering features of your plan. If no connection exists yet, the page says so and sends you to connect one first, instead of letting you fill in a form that cannot be saved.

The name is yours — it is what appears on issues, patches and runs. Use the name your team says out loud, not the slug.

Removing one

Removing a codebase removes the connection to the repository, not the history. The confirmation says it in full: "The connection to the repository is removed. Historical commit references, patch lineage and verification evidence are kept, and an admin can restore it."

This is the general rule across FixControl: operational objects are removed softly, and the evidence that something happened outlives the object it happened to. See Governance & policy.

Runtime versions

By default FixControl works out which runtime a repository needs by reading the repository — the manifest, the lockfile, the version file, the Dockerfile, the CI configuration. That is usually right, and it is always evidence-based.

Where it is not, a project can pin a runtime under Runtime versions for this project (Project → Environments → How changes are validated): a language, a version, and optionally a specific image. An empty list says what it means — "No runtime pinned — FixControl resolves this from the repository."

Pin one when:

your build needs a base image your registry provides and the public one does not;
the repository declares nothing and you do not want the default;
two projects in the same workspace need different versions of the same language — they can, and the pin is how you say so.

Changing a pin retires the project's verified environment. The next run is proven under the new pin rather than reusing an image the pin no longer names. That is the point: a pin you can set without re-proving would be a claim, not a configuration.

Database for verification runs

Database for verification runs decides whether a verification run applies this codebase's database migrations before it tests the change. The options on screen:

Option	What it does
Default (use system setting)	Follow the deployment-wide setting. Unless your FixControl operator changed it, that is no database.
None — skip database migrations	No database. Migration steps are dropped from the plan rather than failing.
URL — use a database URL for this codebase	Point at a database you supply. Stored encrypted, used for this codebase only.
A fresh throwaway database for every run	A new database per run, discarded afterwards.

Migration steps only run when a database is actually available to the run. With the default — no database — they are skipped, and a change that depends on a migration cannot be proven by that run.

With URL, point it at an isolated throwaway database. A verification run executes migrations; a migration is not a read-only operation, and a database you care about is not the place to prove one.

Sidecar database engine picks PostgreSQL or MySQL for the throwaway database. Pick MySQL for Laravel or Magento codebases whose migrations use MySQL-specific SQL. Left on Default, the codebase follows the workspace-wide choice, which is PostgreSQL unless your operator changed it.

Where this setting applies depends on where the run executes:

A run that uses your project's verified environment gets its database from the services that environment declares, and this setting is not used for it. The hosted cloud lane works this way: it starts approved database containers next to the run, based on what the verified environment needs.
A fresh throwaway database for every run is honoured where FixControl runs verification in its own container lane. Where a run lands on a lane that cannot provide one, the run gets no database and its migration steps are skipped rather than run against nothing.

WINDEV codebases

WINDEV projects are registered differently, because they are not a repository with a manifest: you give the project root, the .wdp project file, the source-control kind, any analysis files, and references to exported technical documentation for knowledge retrieval.

Be clear about what that buys today. A WINDEV codebase is detected, described and routed; it is not verified. There is no WINDEV runner in the product, so a verification stops with a refusal naming what is missing rather than producing a verdict. Change validation says which stacks reach a real verdict.

What agents may do with a codebase

Registering a codebase is not a grant. Across the whole product:

code delivery is pull or merge request only — there is no state in which FixControl pushes to your default or production branch;
an agent reads the repository under the project it is working in, and one project's context never reaches another;
what an agent may do is decided by governance, never by what is registered here.

FAQ

Can two projects share a codebase? Yes. The codebase is registered once; projects reference it. Settings that belong to the work — the validation strategy, environment settings, runtime pins — live on the project.

Does a private repository need anything special? It needs a connection that can see it. The repository list only shows what the connection can already reach; if a repository is missing, give FixControl access to it on the code host and come back.

I removed a codebase by mistake. An admin can restore it. The patch lineage and verification evidence were never deleted.