Goedkeuringen

Wat is een goedkeuring?

Een goedkeuring is een pauzeknop. Op de belangrijke momenten houdt FixControl het werk stil en wacht het op een mens — jij — die ja of nee zegt. Zo'n pauzemoment heet een poort (gate). De AI bereidt het werk voor; jij keurt de betekenisvolle stappen goed.

Dit is de kern van FixControl: standaard wordt niets verstuurd, uitgevoerd of gemerged zonder een expliciete keuze van een mens, en de goedkeuring is waar die keuze wordt gemaakt en vastgelegd. De uitzonderingen zijn opt-in en begrensd: policy-gescopete auto-reply-verzending en per-project auto-delivery van goedgekeurde patches werken alleen binnen guardrails die een mens heeft ingesteld, en elke automatische actie wordt in de audittrail vastgelegd. Goedkeuringen zijn dus geen formaliteit — ze zijn de plek waar jij de controle houdt.

Welke poorten openen en wanneer, bepaal je organisatie-breed in Governance & beleid. Deze pagina gaat over hoe je een goedkeuring afhandelt als hij voor je neus staat.

De twee belangrijkste poorten

Bij het oplossen van een bug of feature kun je twee soorten goedkeuringen tegenkomen:

De plangoedkeuring is nieuw en het krachtigst: je stuurt de AI bij voordat er werk gedaan is, in plaats van achteraf een verkeerde patch af te keuren.

Plangoedkeuring — keur het plan goed vóór de uitvoering

Voordat de AI aan een bug of feature begint, kan ze eerst een uitvoeringsplan opstellen. Dat plan verschijnt als een kaart op de issue-pagina, met de kop "Wacht op plangoedkeuring" zolang jouw beslissing nog open staat.

Het plan is gestructureerd en in gewone taal — geen muur van code, maar de denkstappen:

• Probleeminterpretatie — wat de AI denkt dat het probleem is.
• Voorgestelde aanpak — hoe ze het wil oplossen.
• Betrokken systemen / bestanden — wat er geraakt wordt.
• Risiconiveau & risicoredenen — hoe gevaarlijk dit is, en waarom.
• Validatiestrategie — hoe ze gaat bewijzen dat het werkt.
• Terugrolplan — wat er gebeurt als het misgaat.
• Klantimpact, geschatte tijd & kosten, openstaande vragen.

Lege velden tonen "Niet beschikbaar" — FixControl verzint nooit een waarde. Een leeg terugrolplan is een echt signaal, geen weglating.

Jouw drie keuzes

Onderaan de plankaart staan drie knoppen:

• Plan goedkeuren — de AI mag beginnen volgens dit plan.
• Wijzigingen vragen — je bent het er nog niet mee eens. Je typt in een verplicht veld wat er anders moet, en de AI maakt een nieuwe versie van het plan met jouw feedback erin verwerkt. Je beoordeelt dan v2 (en zo verder). De feedback wordt vastgelegd in de audit trail.
• Plan afwijzen — je wilt dit niet. De missie stopt.

Elk plan heeft een versienummer (Plan v1, v2, …). Belangrijk: een nieuwe versie maakt een eerdere goedkeuring ongeldig — je keurt altijd de versie goed die je voor je hebt, nooit een oude. Zo kan een plan nooit ongemerkt veranderen ná jouw akkoord.

Zolang het plan niet is goedgekeurd, staat er "Implementatie is geblokkeerd door governancebeleid totdat dit plan is goedgekeurd." De AI begint dus echt niet eerder.

Patchgoedkeuring — keur de wijziging goed vóór hij landt

Heeft de AI (na een goedgekeurd plan, of direct, afhankelijk van je beleid) een patch gemaakt, dan komt die in het Patch-paneel op de issue- of workspace-pagina. Daar zie je de voorgestelde bestanden, de diff en een korte beoordeling:

• Vertrouwen (confidence) — hoe zeker de AI is van haar eigen werk.
• Risico (risk) — een losstaande inschatting van de gevolgen. Hoog vertrouwen én hoog risico is een normale combinatie — lees beide.
• Blast radius — hoeveel er geraakt wordt.
• Wat is er veranderd — een samenvatting in gewone taal.

Vroeg een reviewer (bijvoorbeeld de CTO-agent) om wijzigingen, dan zie je een poort met twee opties:

• Goedkeuren & reviseren — je gaat akkoord met de gevraagde wijziging; de AI maakt een herziene patch.
• Afwijzen — patch verwerpen — je wijst het af; de patch vervalt en de missie stopt.

Een patch landt nooit in je codebase zonder goedkeuring. Standaard markeert goedkeuren hem als geaccepteerd en is Apply een aparte klik die hem wegschrijft. Een project kan opt-in kiezen voor auto-delivery: dan past goedkeuring de patch automatisch toe en opent hij een pull request op de gekoppelde repository — het mergen van die pull request blijft mensenwerk in je git-provider. Zie Workspace en Issues voor de patch-flow per oppervlak.

Waar vind je openstaande goedkeuringen?

Een goedkeuring komt nooit alleen op de issue-pagina te staan — FixControl zorgt dat je hem niet mist:

• Op de issue- of AI-uitvoeringspagina — als kaart, precies bij het werk waar hij bij hoort.
• Het Goedkeuringscentrum — de blokkerende menselijke poorten van een missie bij elkaar, met per poort een samenvatting.
• Meldingen — de bel en de Action items-pagina tonen "wacht op jou"; openstaande goedkeuringen verschijnen in de actie-nodig-rail.
• E-mail — als je organisatie e-mailroutering aanzet, ontvangen bevoegde goedkeurders een mail met de knoppen Goedkeuren / Wijzigingen vragen / Details openen — zonder in te loggen (zie hieronder).

Wie mag goedkeuren?

Elke poort heeft een vereiste goedkeurder (een rol, bijvoorbeeld CTO of QA). Zie je het plan of de patch wel maar geen knoppen, dan staat erbij wie wél mag tekenen: "Alleen [rol] kan dit uitvoeringsplan goedkeuren." Je leest dan mee, maar de beslissing ligt bij iemand anders.

Goedkeuringen kunnen ook gefaseerd zijn — bijvoorbeeld eerst CTO, dan QA, dan Release Manager — elk met een eigen termijn. Dat stelt je beheerder in onder Governance.

Goedkeuren vanuit e-mail (zonder inloggen)

Heeft je organisatie uitgaande e-mail en e-mailroutering ingeschakeld, dan kun je een poort afhandelen direct vanuit je mailbox. De mail bevat het issue, het risico, een verificatiesamenvatting en een aanbeveling. Elke knop is een eenmalige, verlopende beveiligde link: bij het klikken opent een korte bevestigingspagina en wordt je beslissing in FixControl vastgelegd — via exact hetzelfde pad als in de app. Handig voor managers die niet de hele dag in FixControl zitten.

Inschakelen doet je beheerder; zie Governance & beleid → Goedkeuren vanuit e-mail.

Wat als niemand op tijd reageert?

Een poort kan een time-out hebben. Verstrijkt die, dan gebeurt wat je organisatie heeft ingesteld: pauzeren, escaleren naar een reserve-goedkeurder, of automatisch afwijzen. Dit valt onder het escalatiebeleid. Standaard wacht een poort gewoon op jou.

Veelgestelde vragen

Ik zie het plan, maar geen knoppen. Dan ben jij niet de vereiste goedkeurder voor deze poort. De kaart vermeldt wie wel mag tekenen.

Ik heb "Wijzigingen vragen" gekozen — wat nu? De AI maakt een nieuwe planversie met jouw opmerking erin verwerkt. Je beoordeelt dan die nieuwe versie. Je opmerking is verplicht en wordt vastgelegd in de audit trail.

Telt mijn goedkeuring nog als het plan daarna verandert? Nee. Een nieuwe versie maakt je eerdere goedkeuring ongeldig — je keurt altijd de versie goed die je voor je hebt.

Wat is het verschil tussen het plan afwijzen en een patch afwijzen? Een plan afwijzen stopt de missie vóór er werk gedaan is. Een patch afwijzen verwerpt een al gemaakte wijziging. Beide stoppen de missie; alleen het moment verschilt.

Komt een goedgekeurde patch automatisch in mijn codebase? Standaard niet — goedkeuren accepteert de patch en Apply schrijft hem pas weg. Heeft je project auto-delivery aangezet, dan past goedkeuring de patch automatisch toe en opent automatisch een pull request; het mergen blijft aan jou.

Zie ook: Issues · Workspace · Governance & beleid.