Projects

What projects do

A project is your unit of control. It groups what agents are allowed to work on: one or more codebases, business integrations, knowledge sources, tags, and guardrails. Every project belongs to exactly one tenant. A typical FixControl tenant has several projects — often one per customer codebase.

Incoming work (issues, workspaces, patches) is attached to a project. Agents only see what belongs to this project; you keep the overview across customers or products.

Operator surface

The Projects page is a DataTable with the standard primitives: saved views, column visibility, server-side sort + filter, multi-select with bulk actions, CSV export, and the same keyboard map as Issues. Row spacing matches Issues — same density, same keyboard habits.

Sticky chrome — page header, toolbar, and column header stay pinned while the list scrolls.
Detail pager — opening a project from the list captures the active filter+sort. Inside the project detail, [ / ] walk to the previous/next project under that filter without going back to the index.
Bulk actions — select rows (x, Shift+x, Cmd/Ctrl+A) and a sticky toolbar appears with the destructive actions gated by confirm.
Workflow continuity — actions invoked from the project list (e.g. switching mode, archiving) keep you on /projects with the row updated optimistically.

Keyboard map and command-palette commands: see Keyboard & command palette.

Primary goal and use cases

Every project has one primary goal — what you use it for — plus any number of additional use cases:

Support — handle customer questions with governed answers; escalation to engineering is an explicit human step.
Engineering — analyze issues with code context, verify patches in a sandbox, deliver as pull requests behind approval gates.
Deployment governance — observe deployment activity and organize approvals. Observing a provider never implies FixControl can act on it; the only controlled action today is promoting a paused Argo Rollout after an approved gate.
Security (beta) — run the shipped scanners against linked code and route risk into governed remediation.
Knowledge — connect knowledge sources and get source-grounded answers. Needs no codebase and no ticket integration.
Custom — compose your own combination.

The goal drives dashboard priority, readiness checks and recommended safe defaults. It never grants permissions, never bypasses approval rules, and never performs an external action — capabilities are always derived from what is actually connected and healthy. A project can combine goals (for example Engineering + Security, or Support + Knowledge); the primary one leads, the others add their sections and checks.

Creating a project

Go to Projects → New project.
Choose what you want to achieve (the primary goal, in plain language).
Select the connected organization sources that belong to this project — channels, mailboxes, codebases. Only sources you are allowed to see are offered.
Confirm the project context, optionally add extra use cases, and review the exact configuration before anything is applied. Cancelling applies nothing.

New projects start in Sandbox mode by default. Switch on the detail page:

Mode	What it allows
Read-only	Inspection only. Agents can read, never propose patches.
Sandbox (default)	Patches go through the full pipeline but apply is operator-confirmed.
Writable	Agents may write directly within the configured guardrails. Use sparingly.

What you can attach

On the project detail page you manage four kinds of context:

Codebases — repositories or folders agents operate on. One is marked default (star icon).
Business integrations — external systems agents may access in this project. Configure first under Settings → Integrations.
Knowledge sources — analyses, technical docs, procedures. They appear automatically once linked to one of the project's codebases.
Guardrails — free-text rules agents must follow inside this project. Short, explicit instructions work best.

Tags help you filter on the list page.

LLM-first chat understanding

Project settings has a per-project toggle LLM-first chat understanding (Automation group, off by default). When it is on, messages in the project's Slack and Teams channels are interpreted by the language model first — with thread context taken into account — instead of the deterministic pattern rules, so free-form phrasing is understood far more often. The rules stay in place as tie-break and fallback: if the AI provider is down, they take over.

The same toggle governs how a request to update a ticket is read. One message may ask for several things ("create a customer Acme Ltd and info@acme.com and send the answer"); that is understood as one plan and shown as a single confirmation card with numbered steps. When exactly one detail is missing, the bot asks a targeted question about it rather than asking you to rephrase.

This is understanding only. Any resulting action still goes through the same confirmation cards and approvals as before — a better-understood request never means execution, and one click on a plan card runs exactly the steps that card showed. The trade-off is a little extra latency and AI cost per message.

Sandbox database for migrations

Before a patch can be applied, FixControl verifies it in an isolated sandbox — building and testing it against a copy of your code. For codebases that use a migration toolkit (Prisma, Drizzle), those checks include applying database migrations, which needs a database. Each codebase chooses how that database is provided under Settings → Codebases → (edit) → Sandbox database:

Default — use the system-wide setting.
None — skip database migrations during verification.
URL — verify against a database you provide. Enter its connection string in the Database URL field; it is stored encrypted and used only for this codebase. Point it at an isolated throwaway database, never your production database — the sandbox runs the patch's code against it.
Docker — FixControl spins up a fresh, throwaway PostgreSQL just for the run and removes it afterwards (requires the Docker sandbox executor).

When no database is configured, migration steps are simply skipped so they don't block the patch.

Project patch history

Click Patch history to see every AI-generated change inside this project — filter by status (draft, approved, applied, rejected), reviewer (QA / CTO), agent, or workspace; group by issue; inspect the original prompt and tool calls captured for each patch.

Every patch shows confidence, risk, retry lineage, and the dry-run summary if any. Nothing applies without your approval.

Saved views

Default views: All, Mine, Sandbox, Writable, Read-only. Operators add their own; saved views capture the full filter state — filters, sort, page size, column visibility — so a colleague following the link sees the same slice.

FAQ

Can one issue belong to multiple projects? No. An issue is linked to a single project through its workspace.

What happens if I delete a project? Existing sessions that were linked to the project keep their already-resolved context, but the project itself is gone. Deletion is audited.

Why don't I see any knowledge sources? They only show up once attached to one of the project's codebases. Add the codebase first.

Can a project span tenants? No. Tenant isolation is strict — see Admin → Security & audit.