Command Center

Het Command Center is het chatoppervlak waar je FixControl niet alleen iets kunt vrágen, maar ook iets kunt laten doen: een project aanmaken, een repository koppelen, een Slack- of Microsoft Teams-kanaal aanhaken, controleren of een project klaar is, uitzoeken waarom een release vastzit — of hem goedkeuren.

Hij opent als een paneel dat van rechts over de pagina schuift waar je op dat moment bent: klik op Command Center in de bovenbalk, of druk op Ctrl+Shift+K (⌘⇧K op een Mac). Dezelfde sneltoets sluit hem weer, zodat je nooit de pagina kwijtraakt waar je mee bezig was.

Eén zin bepaalt de hele laag:

Command Center is een oppervlak, nooit een autoriteit.

Elke actie roept dezelfde applicatieservice aan als het Settings-scherm, controleert dezelfde permissie als de bijbehorende API-route, en wordt op het moment van uitvoeren opnieuw geautoriseerd. Er is geen tweede, soepelere weg je workspace in.

Je hoeft alleen je eigen doel te kennen

Je hoeft niet te weten wat een "validatielane" is, welk menu een instelling beheert, of hoe FixControl iets intern noemt. Vraag gewoon wat je wilt:

"Maak dit project klaar"
"Waarom is deze release geblokkeerd?"
"Controleer of de UI nog werkt"
"Wat wacht er op mij?"
"Onthoud dit voor de volgende keer"

Twee regels maken dat betrouwbaar in plaats van toevallig. Verwijzingen worden voor je opgezocht: "het Symfony-project", "de backend-repo", "mijn andere werkruimte", "de laatste patch" worden opgelost tegen wat jouw account daadwerkelijk kan zien — er wordt nooit om een id gevraagd. En je krijgt hoogstens één vraag: matcht een naam op twee dingen, dan krijg je ze allebei met één onderscheidend feit erbij, en er gebeurt niets tot jij zegt welke.

Wat je kunt vragen

De laag heeft een gesloten vocabulaire. Staat een werkwoord er niet bij, dan kan het model het niet voorstellen — dezelfde catalogus die in de prompt wordt gezet, wordt ook in de validator gezet die het voorstel controleert. Een actie die niemand heeft geregistreerd, wordt structureel geweigerd, wat het gesprek of een README in een repository ook beweert.

Die weigering is met opzet streng, en kostte je tot nu toe antwoorden waar je recht op had: een vraag die de laag zes keer kon beantwoorden ging in zijn geheel verloren omdat er één foute stap aan het voorstel vastzat. Nu gebeuren er drie dingen. Het voorstel wordt één keer gecorrigeerd, met precies de bezwaren van de validator eraan teruggegeven. Lukt dat nog niet en is alles wat overeind blijft een leesactie, dan draaien die leesacties en hoor je onomwonden welk deel van je vraag niet in een actie om te zetten was — een ingekort antwoord krijg je nooit stilzwijgend. En zit er een schrijfactie tussen de delen die zouden moeten afvallen, dan gebeurt er niets: een kaart die jij bevestigt wordt nooit half uitgevoerd.

Projecten

Je projecten opsommen — degene die jouw account kan zien.
Een project lezen — naam, uitvoeringsmodus, gekoppelde codebases, actieve use cases.
Een project aanmaken — met een doel, een uitvoeringsmodus en een omschrijving.
Een project bijwerken — naam, omschrijving, tags, uitvoeringsmodus.
Gereedheid — welke controles slagen, welke blokkeren, en wat er nog ontbreekt voordat een project kan doen waarvoor het is opgezet.
Een project klaarmaken — omgevingsonderzoek starten voor een project dat al bestaat, zonder naar zijn pagina te gaan. Het onderzoek wordt in de wachtrij gezet; er wordt niets extern geschreven en het resultaat moet nog door een run bewezen worden voordat het een geverifieerde omgeving is. Het kan ook een vraag aan de planner stellen: laat hem een startcommando voorstellen als de geverifieerde omgeving er geen heeft, of geef jouw antwoord door op de ene vraag die een vastgelopen run stelde.
Beginnen met wat het blokkeert — niet alleen een lijstje. FixControl start de blokkades die het zelfstandig kan opheffen, en zegt per overgebleven blokkade het ENE dat het nog van je nodig heeft (welke repository, welk kanaal, welk document) of waarom die op een scherm thuishoort. Er wordt nooit geraden welke repository je bedoelde, en de kaart zegt precies hoeveel er echt gestart wordt.
Samengestelde onboarding — zie hieronder.

Codebases

Zoeken in gekoppelde git-providers naar repositories die op een term lijken, als je een repository losjes benoemde ("onze pos-repo").
Oplossen van een repositoryverwijzing (een URL, een ssh-remote, owner/repo, een organisatie) en melden of die uniek, dubbelzinnig of onbekend is — of onbereikbaar omdat er niets gekoppeld is.
Koppelen van een repository aan een project, en weer ontkoppelen (de codebase zelf blijft — alleen de koppeling met het project verdwijnt).
Synchroniseren van de werkkopie, zodat FixControl de bestanden kan lezen.
Inspecteren — een codebase analyseren en de technische documentatie ervan opnieuw in de kennisbank genereren.

Verificatie

Hoe wordt dit geverifieerd? — waar de wijzigingen van een project getest worden, of de omgeving daadwerkelijk bewezen is, en wat de laatste run zei.
Waarom ging het mis? — de fout in gewone taal, plus het ene gegeven dat bepaalt wat je eraan doet: kan een wijziging in de code dit plausibel oplossen, of lost niets in de repository het op omdat de omgeving haar werk niet kon doen. Heeft een dev-agent de fout al onderzocht in de container waarin hij optrad, dan krijg je zijn bevinding: wat hij concludeerde, waarom, en wat hij voorstelt.
Start hij nog? — een groene testsuite is geen draaiende applicatie. Is er geen bewijs, dan hoor je welke van de redenen geldt: er is niets geprobeerd, deze manier van verifiëren kan geen applicatie starten, hij is gestart en kwam niet omhoog, of de geverifieerde omgeving heeft nooit gezegd hoe je hem start. Dat laatste is geen doodlopende weg: FixControl kan zijn planner om een startcommando vragen.
Waarom kan dit niet toegepast worden? — voor een concrete wijziging hetzelfde oordeel dat de toepas-poort afdwingt, met zijn eigen bruikbare zin.
Veranderen hoe er geverifieerd wordt — verificatie aan- of uitzetten, kiezen of wijzigingen op FixControls eigen infrastructuur gecontroleerd worden, in jullie eigen Kubernetes-cluster, of eerst lokaal en dan in jullie cluster; en vastleggen wat jij weet over het starten van de applicatie: het startcommando, niet-geheime omgevingsvariabelen, extra systeempakketten, en aanwijzingen voor de planner. Alleen wat je benoemt verandert; de rest houdt zijn waarde, en dat staat op de kaart.
Een verificatie starten — een concrete wijziging controleren, of de applicatie opstarten en bereikbaar laten zodat jij (of een browsercontrole) ernaar kan kijken.

Beslissingen en releases

Waarom zit dit vast? — waar elke openstaande poort over beslist, hoe risicovol die is, welke controles groen en welke rood zijn, en wat CI zei over precies de commit die zou uitgaan.
Wat wacht er op mij? — elke beslissing in deze werkruimte die op een mens wacht.
Beslissen — goedkeuren, afwijzen, of het werk terugsturen met commentaar. Zie Beslissen vanuit de chat.

Agents en vaardigheden

Hoe zijn de agents ingesteld? — wie wat doet, welk model hij gebruikt, hoeveel hij mag uitgeven, hoe vaak hij het opnieuw probeert, hoeveel context hij leest, en welke agent welke fase van een missie draagt.
De instelling van een agent wijzigen — via hetzelfde geversioneerde schrijfpad als de instellingenpagina, met dezelfde poorten. Welke velden bestaan en wat ze mogen worden is een beslissing van het platform, en een veld dat niet geschreven kan worden wordt geweigerd mét de reden, voordat je een kaart ziet.
Welke agents hebben hieraan gewerkt? — per run: welke agent hem droeg en welke instelling er op dat moment gold, welke context hij daadwerkelijk las, en waar die twee uiteenliepen.
Wat zou je hiermee doen? — een voorspelling van hoe een stuk werk aangepakt zou worden en welke menselijke beslissingen het zou vragen. Er wordt niets aangemaakt, verstuurd of geschreven.
Vaardigheden — wat de agents eigenlijk kunnen, of een vaardigheid aanstaat, welke agents hem gebruiken, en of een agent waaraan hij is toegewezen er wel aan kan voldoen (een die dat niet kan, is toegewezen én blijvend inert). Je kunt er een aan- of uitzetten, aan een agent geven of afnemen, en simuleren of hij voor een stuk werk zou afgaan zonder dat er iets draait.

Kennis en binnenkomend werk

Wat weet je van ons? — de kennisbronnen van de werkruimte: wat elke bron is, waar hij bij hoort, en of hij klaar is met indexeren. Een bron die nog verwerkt wordt of is mislukt, is meestal het antwoord op "waarom weet hij dat niet?". Alleen titels en kenmerken — nooit de inhoud.
Wat zou je lezen? — precies de passages die de agents zouden krijgen als je iets vraagt, op volgorde, met waarom elke bereikbaar was. Komt er niets uit, dan tellen de uitsluitingen: hoeveel bronnen buiten bereik bleven, en onder welke regel. Dit draait dezelfde zoekgang als een agent, dus dit ís wat zij zien.
Onthoud dit — een document opslaan dat je geeft, of één webpagina inlezen en bewaren. Een hele site importeren blijft op de kennispagina, waar het paginabudget en de voortgang zichtbaar zijn.
Waar komt ons werk binnen? — de inbox, de postbussen erachter en of die nog ophalen, en uit welke externe systemen een project werk aanneemt. Een postbus die gestopt is met ophalen is meestal het antwoord op "waarom komt er niets binnen?".

Koppelingen en kanalen

Koppelingsstatus — met welke providers deze werkruimte verbonden is, en of elk gezond is. Gezondheid is per capability, nooit een algemeen "Verbonden".
Bronnen zoeken — een kanaal- of projectnaam omzetten naar het provider-id waaraan een project gekoppeld kan worden.
Projectkoppelingen — bekijken waar een project dingen naartoe stuurt, een bron koppelen per doel, koppelingen losmaken, en een koppeling testen door er een echt bericht naartoe te sturen.
Een verbinding starten — een toestemmingsflow van een provider beginnen (zie Hervatten na toestemming).
Google Cloud — of de read-only connector verbonden is, uit welk GCP-project hij leest, als welk serviceaccount hij optreedt, en of hij nu werkt (per capability: logs, foutrapportage, BigQuery). Een koppeling zonder toegestane datasets is verbonden en kan niets bevragen — dat is meestal het antwoord op "hij ziet niets".
FC Agents — de ingeschreven agents van de werkruimte: cluster, aangeboden capabilities, ingeschakeld of ingetrokken, laatste hartslag, recente ondertekende operaties. Nooit geheimen.

Wat je werkruimte zelf kan aanzetten

Sommige dingen staan uit tot jij beslist — FixControl een mislukte run laten onderzoeken in de omgeving waarin hij misging, een omgeving laten uitzoeken voor een repository die de detectie niet kan plannen, of een live preview van een applicatie aanbieden. Vraag om wat je wilt in je eigen woorden ("laat hem mislukte runs onderzoeken"); je hebt de interne sleutelnaam nooit nodig.

Je hoort wat er nu aanstaat, waar het op terugvalt als je je keuze ongedaan maakt, en — vóór je bevestigt — de beschrijving van het platform zelf over wat de instelling precies doet, volledig. Een instelling die jouw werkruimte niet mag wijzigen wordt geweigerd vóór er een kaart komt, mét wat je dan wél doet. Het geldt vanaf de eerstvolgende run; runs die al lopen houden de instelling waarmee ze begonnen.

Je kunt een keuze ook teruggeven: vraag om weer de standaard te gebruiken, en je werkruimte bepaalt die niet langer zelf — hij volgt de standaard van het platform, en blijft die volgen als die later verandert. Dat is iets anders dan de oude waarde met de hand terugzetten, want dan zit hij hier vast.

Werkruimtes

Je werkruimtes opsommen — hetzelfde antwoord als de wisselaar, en dezelfde code eronder: elke werkruimte waar je in mag, met de rol die je er hebt en of je er naartoe kunt wisselen.
Van werkruimte wisselen — je sessie naar een andere werkruimte verplaatsen waar je lid van bent. Dit zit achter een bevestigingskaart om een concrete reden: de sessiecookie wordt gedeeld door elk tabblad van die browser, dus bevestigen betekent dat ze allemáál meeverhuizen. De naam die je noemt wordt opgelost tegen je eigen lijst voordat de kaart bevroren wordt, en een naam die nergens op slaat wordt geweigerd zonder prijs te geven of zo'n werkruimte elders bestaat. Lidmaatschap, status, de intrekkingsgrens en het tweefactorbeleid van de doelwerkruimte worden allemaal beslist door precies de code die de wisselaar aanroept, en vragen kost uit dezelfde limiet per account als de API-route — de chat is geen snellere manier om naar werkruimtenamen te raden.
Een werkruimte aanmaken — het smalle pad voor een workspace-beheerder: een naam, verder niets. Het vereist beheerdersrechten op de werkruimte waar je nu bent en een sessie waarin tweefactor is voldaan, en er geldt een limiet per gebruiker. Platformbeheerders worden hier bewust geweigerd en naar de Companies-pagina gestuurd, want hun pad vraagt om een plan, een omgeving en een domein — beslissingen die niet in één zin thuishoren.

Samengestelde onboarding

"Zet ons op deze repository" is één beslissing, dus krijgt het één kaart. Bevestigen ontvouwt zich in vijf bestuurde stappen — project aanmaken, repository koppelen, synchroniseren, technische documentatie genereren, gereedheid melden — en, waar automatisch omgevingsonderzoek aanstaat voor je organisatie, een onderzoeksstaart daarna.

Omdat dat werk een repository kloont en documentatie genereert, draait het niet binnen het verzoek. De stappen worden meteen in het logboek van de actie gezet en een achtergrondtaak werkt ze af, zodat je per stap voortgang ziet. Elke ontvouwde stap wordt zelfstandig geautoriseerd, op het moment dat hij draait, tegen je huidige rol — een permissie die je tussen bevestigen en uitvoeren kwijtraakt, weigert die stap in plaats van meegedragen te worden door de oorspronkelijke controle.

De bevestigingskaart

Niets dat iets verandert draait op gezag van het gesprek. Elke niet-lezende actie wordt eerst als kaart voorgesteld, en de kaart ís de beslissing.

Het doelwit staat vast, en het is letterlijk. Een kaart die een kanaal koppelt draagt het provider-id dat geschreven zal worden, niet alleen een naam. Een id uit een eerdere stap doorschuiven naar een schrijfactie wordt geweigerd: een kaart met een placeholder zou betekenen dat je een doelwit goedkeurt dat je nooit zag, terwijl het echte na de beslissing gekozen wordt. De volgorde is dus altijd: opzoeken (een leesactie, die meteen draait) → jij kiest → de schrijfactie wordt voorgesteld met het echte id.
De kaart draagt het bewijs, niet alleen het werkwoord. Een goedkeuringskaart laat zien waar de poort over beslist, hoe risicovol die is, welke controles groen en rood zijn, welke commit het betreft en wat CI daarover zei. Een instellingenkaart laat zien waar de waarde vandaan komt en waar hij naartoe gaat, en benoemt wat de wijziging nog meer verschuift. Een kaart die je niet kunt controleren is geen beslissing.
Het plan wordt serverkant opnieuw gelezen. Bevestigen stuurt één ding: een eenmalig, aflopend token. Welk plan, wiens plan en voor welke werkruimte worden teruggelezen uit FixControls eigen administratie; de kopie in je browser wordt nooit vertrouwd. Het plan wordt opnieuw gehasht en vergeleken met de vingerafdruk die bevroren werd toen je de kaart zag — een gewijzigd plan vraagt een nieuwe beslissing.
Nog eens bevestigen is geen tweede effect. Het token wordt één keer verbruikt; het nogmaals aanbieden herhaalt het eerste resultaat in plaats van iets twee keer uit te voeren.
Autorisatie en tweefactor gebeuren bij het uitvoeren. Elke stap controleert zijn permissie opnieuw, en waar een capability achter de tweefactormuur draait, wordt die muur afgedwongen tegen de levende sessie bij bevestiging — het enige moment waarop een challenge echt bewezen kan worden. Welke capabilities dat zijn, bepaalt de eigen lijst van het platform, niet de chatlaag: een capability kan hier alleen maar strenger zijn dan zijn scherm, nooit soepeler.
Het doelwit wordt vóór het schrijven opnieuw gecontroleerd. Het id wordt opnieuw opgezocht in je eigen werkruimte, en droeg de kaart een naam, dan moet de provider die naam nog steeds bij dat id melden. Een verlopen bevestiging, een id uit een andere werkruimte en een verzonnen id falen allemaal op dezelfde manier.
Elke niet-lezende stap wordt vastgelegd, en het resultaat van elke stap gaat in het logboek zodra die stap afrondt — zodat een verzoek dat halverwege sneuvelt een spoor achterlaat van wat er écht draaide.

Sommige acties moeten het laatste in een plan zijn

Drie stuks, elk om zijn eigen reden, en elke weigering zegt welke:

Van werkruimte wisselen werkt pas na het herladen van de app, dus alles erna zou draaien in de werkruimte die je net verliet. "Doe X in Acme" zijn twee beurten.
Een verbinding starten stuurt je naar het toestemmingsscherm van de provider, dus alles erna zou draaien voordat je iets had goedgekeurd.
Een poort beslissen zet de missie weer in beweging — het werk hervat, een uitrol kan vrijgegeven worden — dus alles wat erna gepland is, zou redeneren over een toestand die al aan het veranderen is.

Beslissen vanuit de chat

Je kunt vanuit het Command Center goedkeuren, afwijzen of werk terugsturen, en het is dezelfde beslissing als die op het reviewscherm: één serverkant knooppunt legt elk poortoordeel vast, van welk oppervlak het ook komt, en bevriest dezelfde rol, route, bewijsvoering, beleidsversie en consequentie op de goedkeuring.

Drie dingen zijn hier bewust anders:

Het is strenger. De reviewroute vraagt je permissie; dit vraagt daarbovenop een sessie waarin tweefactor voldaan is. Eén zin is een lagere drempel naar een onomkeerbare productiebeslissing dan een scherm waar je bewust naartoe navigeerde.
De kaart draagt het bewijs van de poort zelf — waar hij over beslist, hoe risicovol, de verificatiecontroles met hun stand, de commit, en wat CI over die commit zei. Je wordt nooit gevraagd een woord te bevestigen.
Het logboek zegt waar het vandaan kwam. Een beslissing die hier genomen is, wordt als eigen kanaal vastgelegd en niet als een gewone in-app-beslissing, zodat wie het spoor later leest kan zien dat het bewijs vóór de goedkeurder een bevestigingskaart was en niet het reviewscherm.

"Wijzigingen vragen" bestaat alleen voor de poorttypes die iets te herzien hebben; het voorstellen bij een uitrolpoort wordt geweigerd voordat je een kaart ziet, niet erna. Kijk altijd eerst naar de poort — er wordt nooit een beslissing voorgesteld over iets dat je niet getoond is.

Hervatten na toestemming

Vraag je iets waarvoor een provider nodig is waarmee FixControl nog niet verbonden is, dan faalt de actie niet zomaar.

Het Command Center bevriest de leesstappen die je context herbouwen én het verzoek dat je daadwerkelijk deed, en geeft je een link naar de normale toestemmingsflow voor die provider. Kom je terug, dan wordt de context herbouwd en je verzoek opgepakt — je typt het geen tweede keer.

De terugkeer-URL draagt een identificatie, nooit een geheim.
De geparkeerde regel wordt één keer geclaimd, door dezelfde werkruimte en dezelfde gebruiker, voordat hij verloopt.
Een hervatting draait alleen leesacties. Toegang tot een provider goedkeuren is niet hetzelfde als een wijziging in FixControl goedkeuren: je verzoek wordt opnieuw gepland, dus alles wat iets verandert komt terug als eigen bevestigingskaart, met het echte doelwit erop.
Elke stap wordt opnieuw geautoriseerd tegen de sessie die terugkomt, dus een permissie die je onderweg kwijtraakte hervat in een weigering.
Je verzoek is van jou: het staat op de geparkeerde regel, komt alleen terug bij je eigen account, verloopt met de regel en wordt ermee verwijderd.

Microsoft Teams heeft geen toestemmingsflow om te starten: je koppelt het door link naar de bot te typen en de eenmalige code te plakken, of door een app-id en wachtwoord in Settings te zetten. Het Command Center weigert Teams met die instructie in plaats van een flow te verzinnen die niet bestaat.

Wat bewust in de UI blijft

Dit zijn beslissingen, geen gaten.

Inloggegevens. Database-, HR- en Google Cloud-connectors dragen inloggegevens rechtstreeks, en het aanmaken van een uitgaande webhook toont één keer een ondertekeningsgeheim. Een geheim mag nooit door een chattranscript reizen. Providers met toestemmingsflow zijn juist wél beschikbaar omdat toestemming de inloggegevens buiten FixControls handen houdt.
Destructief beheer. Verwijderen en archiveren gebeurt op het scherm dat de registratie beheert, waar de bevestiging kan benoemen wat weggaat, wat blijft en of het terugkomt. Een provider ontkoppelen heeft dezelfde vorm: het stopt stilletjes de aflevering voor élk project dat eraan gekoppeld is, en dat veilig doen vraagt een impactoverzicht dat een kaart van één regel niet kan bewijzen.
Cluster- en CI/CD-koppelingen. Argo, Kubernetes, Jenkins, GitHub Actions, GitLab CI, Azure DevOps, Vercel en Terraform Cloud dragen extra configuratie — namespace, rollout, labelselector, uitrolpoort — die een bevestiging van één regel niet eerlijk kan samenvatten. Ze instellen is een keuzescherm. Ernaar vrágen niet: "waarom is deze release geblokkeerd?" leest hun poort en het CI-bewijs dat bevroren is over de commit die zou uitgaan.
Facturatie. Planwijzigingen lopen via Stripes eigen checkout en klantportaal vanuit Instellingen → Facturatie. De voorwaarden van een commerciële verbintenis staan op die pagina, niet op een kaart die FixControl tekent.
Governancebeleid. Beleidsdomeinen, postures, scope-uitzonderingen en de routering van governance-meldingen bepalen wat elke andere actie mag veroorzaken. Een oppervlak dat geen autoriteit is, past de autoriteit niet aan. Stel ze in onder Instellingen → AI & goedkeuringen — zie Governance.
Wie wat mag. Gebruikers, projectleden en projectrollen, en lidmaatschappen van werkruimtes. Dat is de autoriteit waartegen elke actie beoordeeld wordt.
Een vaardigheid schrijven. Een procedure — waar hij op afgaat, wat hij nodig heeft, wat hij doet — is geen zin. Alles wat je met een bestaande vaardigheid doet, kan wel.
Postbusbeheer. Watches, abonnementen en ingest-vlaggen voor Gmail en Office 365. Óf een postbus nog ophaalt wordt hier wel beantwoord, want dat is het deel waar je echt naar vraagt.

Twee dingen om te weten over koppelingen

Een Teams-kanaal dat voor notificaties gekoppeld is, wordt opgeslagen, maar er gaan geen statusmeldingen naartoe. De statusrouter kijkt op dit moment alleen naar Slack. Teams doet wél mee aan goedkeuringen, en die worden gerouteerd. De bevestigingskaart zegt dat vóór je bevestigt, en het bekijken van de projectkoppelingen zegt het daarna.

Naar een `status`-koppeling wordt nooit iets afgeleverd, bij geen enkele provider — geen consument leest er een. Toch zijn koppelingen niet nutteloos als er niets verstuurd wordt: elke actieve koppeling helpt binnenkomende gebeurtenissen toe te wijzen, dus een koppeling kan bepalen bij welk project een binnenkomend ticket of bericht hoort, ook als er niets uitgaands van afhangt. Daarom staat een chatkanaal standaard op notifications en een tracker of servicedesk standaard op intake.

Verwant

Beheerder-onboarding — de vier stappen van dag één, en ze in één verzoek vragen.
Governance — de beleidslaag waaronder het Command Center opereert.
Gebruikers & identiteit — de rollen waartegen de permissies hierboven beoordeeld worden.