Command Center

The Command Center is the chat surface where you can ask FixControl to do things, not just answer questions: create a project, attach a repository, link a Slack or Microsoft Teams channel, check whether a project is ready, find out why a release is held, or approve it.

It opens as a panel that slides in from the right, over whatever page you are on: click Command Center in the top bar, or press Ctrl+Shift+K (⌘⇧K on a Mac). The same shortcut closes it again, so you never lose the page you were working on.

One sentence governs the whole layer:

Command Center is a surface, never an authority.

Every action it runs calls the same application service the Settings screen calls, asserts the same permission the equivalent API route asserts, and is authorized again at the moment it executes. There is no second, softer path into your workspace.

You only have to know your own goal

You should not have to know what a "validation lane" is, which menu owns a setting, or what FixControl calls a thing internally. Ask for what you want:

"Maak dit project klaar" / "can you get this project working?"
"Why is this release blocked?"
"Check whether the screen still works"
"Who is waiting on me?"
"Can you remember this for next time?"

Two rules make that reliable rather than lucky. References are resolved for you: "the Symfony project", "the backend repo", "my other workspace", "the last patch" all resolve against what your account can actually see — you will never be asked for an id. And you will be asked at most one question: if a name matches two things, you get both, with one fact each to tell them apart, and nothing runs until you say which.

What you can ask for

The layer has a closed vocabulary. If a verb is not in the list below, the model cannot propose it — the same catalogue that is rendered into the prompt is also rendered into the validator that checks the proposal, so an action nobody registered is refused structurally, whatever the conversation or a repository's README says.

That refusal is strict on purpose, and it used to cost you answers you were entitled to: a question the layer could answer six times over was thrown away whole because the proposal had one bad step stapled to it. It now does three things instead. It corrects the proposal once, handing back exactly what the validator objected to. If that still does not validate and everything left standing is a read, it runs those reads and tells you plainly which part of your request it could not turn into an action — a shortened answer is never given silently. And if a write was among the parts that would have to be dropped, nothing runs at all: a card you confirmed is never partly executed.

Projects

List your projects — the ones your account can see.
Read a project — name, execution mode, linked codebases, active use cases.
Create a project — with a goal, an execution mode and a description.
Update a project — name, description, tags, execution mode.
Readiness — which readiness checks pass, which block, and what is still missing before a project can do what it was set up for.
Make a project ready — start environment discovery for a project that already exists, without going to its page. It queues the discovery; nothing external is written and the result still has to be proven by a run before it becomes a verified environment. It can also put a question to the planner: ask it to propose a start command when the verified environment has none, or carry your answer to the one question a stuck run asked.
Start fixing what blocks it — not just a list. FixControl runs the blockers it can clear from the project alone, and tells you, per remaining blocker, the ONE thing it still needs from you (which repository, which channel, which document) or the reason it lives on a screen. It never guesses which repository you meant, and the card says exactly how many things it will actually start.
Compound onboarding — see below.

Codebases

Search connected git providers for repositories matching a term, when you named a repository loosely ("our pos repo").
Resolve a repository reference (a URL, an ssh remote, owner/repo, an organisation) and report whether it is unique, ambiguous, unknown, or unreachable because nothing is connected.
Attach a repository to a project, and detach it again (the codebase itself is kept — only the project's link is removed).
Sync the working copy so FixControl can read the files.
Inspect — analyse a codebase and regenerate its technical documentation into the knowledge base.

Verification

How is this verified? — where a project's changes are tested, whether its environment has actually been proven, and what the last run said.
Why did it fail? — the failure in plain language, plus the thing that decides what to do about it: whether a change to the code could plausibly fix it, or whether nothing in the repository will because the environment could not do its job. When a dev agent already investigated the failure inside the container it happened in, you get its finding: what it concluded, why, and what it suggests.
Does it still start? — a green test suite is not a running application. If there is no proof, you are told which of the reasons applies — nothing tried, the lane cannot start applications at all, it was started and did not come up, or the verified environment never said how to start it. That last one is not a dead end: FixControl can ask its planner to propose a start command.
Why can't this be applied? — for a specific change, the same verdict the apply gate enforces, with its own actionable sentence.
Change how it is verified — turn verification on or off, choose whether changes are checked on FixControl's own infrastructure, inside your Kubernetes cluster, or locally first and then your cluster; and record what you know about starting the application: the start command, non-secret environment variables, extra system packages, and notes for the planner. Only what you name is changed; everything else keeps its value, and the card says so.
Run a verification — check a specific change, or bring the application up and leave it reachable so you (or a browser check) can look at it.

Decisions and releases

Why is this blocked? — what each open gate decides, its risk, which checks are green and which are red, and what CI said about the exact commit that would ship.
What is waiting on me? — every decision in this workspace that is waiting on a human.
Decide — approve, reject, or send the work back with feedback. See Deciding from chat.

Agents and skills

How are the agents configured? — which one does what, which model it uses, how much it may spend, how often it retries, how much context it reads, and which agent backs which stage of a mission.
Change an agent's configuration — through the same versioned write path the settings page uses, with the same gates. Which fields exist and what they may become is the platform's decision, and a field that cannot be written is refused with the reason before you are shown a card.
Which agents did this work? — per run, which agent carried it and which configuration was in force at the time, what context it actually read, and any gaps between what was configured and what happened.
What would you do with this? — a prediction of how a piece of work would be handled, and which human decisions it would need. Nothing is created, dispatched or written.
Skills — what the agents can actually do, whether a skill is switched on, which agents use it, and whether an agent it is assigned to can actually satisfy it (one that cannot is assigned and permanently inert). You can switch one on or off, give it to an agent or take it away, and simulate whether it would fire for a piece of work without running anything.

Knowledge and incoming work

What do you know about us? — the workspace's knowledge sources: what each is, what it belongs to, and whether it finished indexing. A source that is still processing or that failed is usually the answer to "why doesn't it know that?". Titles and metadata only — never the contents.
What would you read? — the exact passages retrieval would hand an agent if you asked something, in order, with why each one was reachable. When nothing comes back, the exclusions count: how many sources stayed out of reach, and under which rule. This runs the same retrieval an agent runs, so this is what they see.
Remember this — store a document you give it, or read one web page and store it. Importing a whole site stays on the knowledge page, where the page budget and the progress are visible.
Where does our work come in? — the inbox, the mailboxes behind it and whether they are still collecting, and which external systems a project takes work from. A mailbox that stopped collecting is usually the answer to "why are no tickets arriving?".

Integrations and channels

Integration status — which providers this workspace is connected to, and whether each is healthy. Health is per capability, never a blanket "Connected".
Search resources — turn a channel or project name into the provider id a project can be linked to.
Project links — inspect where a project sends things, bind a resource to a project per purpose, unbind one or more links, and test a link by posting a real message to it.
Start a connection — begin a provider consent flow (see Consent resume).
Google Cloud — whether the read-only connector is connected, which GCP project it reads from, which service account it acts as, and whether it is working right now (per capability: logs, error reporting, BigQuery). A connection with no allowed datasets is connected and can query nothing — that is usually the answer to "it sees nothing".
FC Agents — list the workspace's enrolled agents: cluster, advertised capabilities, enabled or revoked, last heartbeat, recent signed operations. Never secrets.

What your workspace can switch on for itself

Some things are off until you decide — letting FixControl investigate a failed run inside the environment it failed in, work out an environment for a repository its detection cannot plan, or offer a live preview of an application. Ask for the capability in your own words ("let it look into failed runs for us"); you never need the internal key name.

You are told what is on now, what it would fall back to if you undid your choice, and — before you confirm — the platform's own description of what the setting actually does, in full. A setting your workspace is not allowed to change is refused before any card, with what to do instead. It applies from the next run onwards; runs already in flight keep the setting they started with.

You can also hand a choice back: ask to use the default again, and your workspace stops deciding that one for itself — it follows the platform default now, and keeps following it if that default later changes. That is not the same as setting the old value back by hand, which would pin it here.

Workspaces

List your workspaces — the same answer the switcher shows, and the same code behind it: every workspace you may enter, with the role you hold in each and whether it is switchable.
Switch workspace — move your session to another workspace you are a member of. It is behind a confirmation card for a concrete reason: the session cookie is shared by every tab of that browser, so confirming means every one of them moves. The name you say is resolved against your own listing before the card is frozen, and a name that matches nothing is refused without revealing whether such a workspace exists elsewhere. Membership, workspace status, the revocation cutoff and the target workspace's two-factor policy are all decided by exactly the code the switcher calls, and asking here spends from the same per-account switch limit the API route spends from — chat is not a faster way to guess at workspace names.
Create a workspace — the narrow tenant-admin path: a name, nothing else. It requires workspace-admin rights where you are now and a two-factor-satisfied session, and it is subject to a per-user creation limit. Platform admins are deliberately refused here and pointed at the Companies page, because their path takes a plan, an environment and a domain — decisions that do not belong in a sentence.

Compound onboarding

"Set us up on this repository" is one decision, so it gets one card. Confirming it expands into five governed steps — create the project, attach the repository, sync it, generate its technical documentation, report readiness — and, where automatic environment discovery is enabled for your organisation, a discovery tail after those.

Because that work clones a repository and generates documentation, it does not run inside the request. The steps are written into the action's ledger immediately and a background job works through them, so you see progress per step as each one finishes. Every expanded step is authorized independently, at the moment it runs, against your current role — a permission lost between confirming and running refuses that step rather than being carried by the original check.

The confirmation card

Nothing that changes state runs on the strength of the conversation. Every non-read action is proposed as a card first, and the card is the decision.

The target is frozen, and it is literal. A card that links a channel carries the provider id that will be written, not just a name. Chaining an id from an earlier step into a write is refused: a card that showed a placeholder would mean approving a target you were never shown, with the real one chosen after the decision. So the flow is always: look it up (a read, which runs immediately) → you pick → the write is proposed with the real id.
The card carries the evidence, not just the verb. An approval card shows what the gate decides, its risk, which checks are green and which are red, the commit and what CI said about it. A configuration card shows the value it is changing from as well as to, and names anything else the change would move. A card you cannot check is not a decision.
The plan is re-read server-side. Confirming sends one thing: a single-use, time-limited token. Which plan, whose plan and for which workspace are read back from FixControl's own records; your browser's copy of the plan is never trusted. The plan is re-hashed and compared against the digest frozen when the card was shown — a changed plan needs a new decision.
A replay is not a second effect. The token is consumed once; presenting it again replays the first result instead of running anything twice.
Authorization and 2FA happen at execute time. Each step re-asserts its permission and, where the capability runs behind the two-factor wall, that wall is enforced against the live session at confirmation — the only moment a challenge can actually be proven. Which capabilities those are is decided by the platform's own list, not by the chat layer: a capability can only ever be stricter here than its equivalent screen, never looser.
The target is re-checked before the write. The id is re-resolved against your own workspace's listing, and if the card carried a name, the provider must still report that name for that id. A stale confirmation, an id from another workspace and an invented id all fail the same way.
Every non-read step is audited, and each step's outcome is recorded in the action's ledger as it finalises — so a request that dies halfway leaves a record of what actually ran.

Some actions have to be the last thing in a plan

Three of them, each for its own reason, and each refusal says which:

Switching workspace takes effect after the app reloads, so anything after it would run in the workspace you just left. "Do X in Acme" is two turns.
Starting a connection sends you to the provider's consent screen, so anything after it would run before you had approved anything.
Deciding a gate sets the mission moving again — the work resumes, a rollout may be released — so anything planned after it would be reasoning about a state that is already changing.

Deciding from chat

You can approve, reject or send work back from the Command Center, and it is the same decision as the one on the review screen: one server-side chokepoint records every gate verdict, whatever surface it arrived on, and freezes the same decided role, route, evidence, policy version and consequence onto the approval.

Three things are deliberately different here:

It is stricter. The review route requires your permission; this additionally requires a two-factor-satisfied session. A sentence is a lower-friction path to an irreversible production decision than a screen you navigated to on purpose.
The card carries the gate's own evidence — what it decides, its risk, the verification checks with their state, the commit, and what CI said about that commit. You are never asked to confirm a word.
The ledger says where it came from. A decision taken here is recorded as its own channel, not as an ordinary in-app one, so anyone reading the trail afterwards can tell that the evidence in front of the approver was a confirmation card rather than the review surface.

"Request changes" only exists for the gate types that have something to revise; proposing it on a deployment gate is refused before a card is shown rather than after you click. Always look at the gate first — a decision is never proposed on something you have not been shown.

If you ask for something that needs a provider FixControl is not connected to yet, the action does not simply fail.

Command Center freezes the read steps that rebuild your context, and the request you actually made, and hands you a link to the normal FixControl consent flow for that provider. When you come back, the context is rebuilt and your request is picked up — you do not type it twice.

The return URL carries an identifier, never a secret.
The parked row is claimed once, by the same workspace and the same user, before it expires.
A resume runs reads only. Approving provider access is not approving a change inside FixControl: your request is re-planned, so anything that changes something comes back as its own confirmation card, with the real target on it.
Every step is re-authorized against the session that returns, so a permission lost while you were away resumes into a refusal.
Your request is yours: it is stored on the parked row, returned only to your own account, expires with the row and is deleted with it.

Microsoft Teams has no consent flow to start: it is connected either by typing link to the bot and pasting the one-time code, or by entering an app id and password in Settings. Command Center refuses Teams with those instructions rather than inventing a flow.

What stays in the UI on purpose

These are decisions, not gaps.

Credentials. Database, HR and Google Cloud connectors carry credentials directly, and creating an outbound webhook shows a signing secret exactly once. A secret must never travel through a chat transcript. Consent-based providers are exposed precisely because consent keeps the credential out of FixControl's hands.
Destructive administration. Deleting and archiving happen on the screen that owns the record, where the confirmation can name what goes, what stays and whether it comes back. Disconnecting a provider is the same shape: it silently stops delivery for every project bound to it, and doing that safely needs an impact statement a one-line card can prove.
Cluster and CI/CD bindings. Argo, Kubernetes, Jenkins, GitHub Actions, GitLab CI, Azure DevOps, Vercel and Terraform Cloud carry config extras — namespace, rollout, label selector, deployment gate — that a one-line confirmation cannot capture honestly. Configuring them is a picker. Asking about them is not: "why is this release blocked?" reads their gate and the CI evidence frozen about the commit that would ship.
Billing. Plan changes go through Stripe's own hosted checkout and billing portal from Settings → Billing. The terms of a commercial commitment are shown on that page, not on a card FixControl renders.
Governance policy. Policy domains, postures, scope overrides and governance notification routing decide what every other action is allowed to do. A surface that is not an authority does not get to edit the authority. Configure them in Settings → AI & approvals — see Governance.
Who may do what. Users, project members and project roles, and workspace memberships. That is the authority every action is evaluated against.
Authoring a skill. A procedure — its triggers, what it requires, what it does — is not a sentence. Everything you do with a skill that already exists is available.
Mailbox lifecycle. Watches, subscriptions and ingest flags for Gmail and Office 365. Whether a mailbox is still collecting is answered here, because that is the part you actually ask about.

Two things worth knowing about links

A Teams channel bound for notifications is stored, but status notices are not delivered to it. The status-notice router currently matches Slack only. Teams does participate in approvals, which is routed. The confirmation card says so before you confirm, and inspecting the project's links says so afterwards.

A `status` binding is never delivered to, for any provider — no consumer reads one. Bindings are not useless when nothing is sent, though: every active binding helps attribute inbound events, so a link can identify which project an incoming ticket or message belongs to even when nothing outbound depends on it. That is why linking a chat channel defaults to notifications, and linking a tracker or service desk defaults to intake.

Admin onboarding — the four day-one steps, and asking for them in one request.
Governance — the policy layer Command Center operates under.
Users & identity — the roles the permissions above resolve against.