Projects, repositories, and websites

Guard models three related scopes: a project groups product ownership, repositories provide versioned code evidence, and websites identify exact live surfaces. Keeping those scopes distinct makes audits, permissions, and automation easier to interpret.

The project is the operating boundary

A project represents one product or system whose health should be understood together. It owns the project name, members, repository ordering, connected websites, activity, summaries, and project-level automation controls.

The project does not collapse all repositories into one score or one revision. It gives owners a common place to see which part of the product is healthy, which part needs attention, and which work is currently running.

Create separate projects when systems have different owners, customers, authorization boundaries, or operational goals. A development agency should not combine unrelated client repositories in one project simply because the same team can access them.

Repository scope

A repository is the primary unit for code evidence. Guard records its provider identity, provider path, current revision, base diagnostics, audit history, findings, and improvement activity.

Every completed audit describes the revision it inspected. Two repositories in the same project can therefore have results from different commits and completion times. A project view is an overview, not evidence that all cards are synchronized to one moment.

Provider connection state also belongs to the repository. Losing GitHub App access or a GitLab credential can stop new evidence collection without deleting older Guard reports.

When a repository moves to another Guard project, its reports, linked websites, and active schedules move with it. This preserves history and automation ownership. Transferring the repository does not move it between GitHub or GitLab namespaces; it changes only the Guard project boundary.

Website scope

A website records an exact live URL and links it to one or more repositories that power it. Those links let reports and later work interpret the site as part of the product rather than as an isolated domain.

Website linking does not prove that every route is implemented by every linked repository. Choose the smallest truthful set of repository links and update it when architecture changes.

Connecting the URL is also separate from authorizing active requests. Auto-pentest can send traffic to the target and therefore requires explicit consent, exact scope, and an owner who understands possible side effects. Read Active testing consent before enabling it.

Choose project boundaries

Repositories generally belong together when at least one of these statements is true:

• they ship one user-facing product;
• they share a release or incident owner;
• a website depends on them together;
• their health decisions need one prioritized backlog;
• moving one without the others would make project reporting misleading.

Keep repositories separate when they belong to different customers, permission domains, or independent products. If the boundary changes later, transfer the repository rather than recreating it and losing continuity.

Removal and transfer boundaries

Disconnecting a repository from Guard does not delete it from GitHub or GitLab. Guard cancels in-flight work for that repository and turns off its automatic audit, Autofix, and Auto-pentest schedules. Existing external issues or review requests remain provider artifacts and must be handled through the provider.

Deleting a whole Guard project removes its Guard-side organization; it is not a provider deletion operation. Confirm ownership and active work before removing either scope.

Use Add repositories and websites to expand a healthy boundary and Repository access and credentials to understand how provider access relates to it.