Projects

Wat doen projecten?

Een project is je controle-eenheid. Het bundelt waar agents aan mogen werken: één of meer codebases, business-integraties, kennisbronnen, tags en guardrails. Elk project hoort bij precies één tenant. Een typische FixControl-tenant heeft meerdere projecten — vaak één per klant-codebase.

Werk dat binnenkomt (issues, workspaces, patches) wordt gekoppeld aan een project. Zo blijft de scope helder: agents zien alleen wat bij dit project hoort, en jij houdt overzicht over wat er per klant of product loopt.

Operator-oppervlak

De Projects-pagina is een DataTable met de standaard primitives: saved views, kolomzichtbaarheid, server-side sort + filter, multi-select met bulk-acties, CSV-export, en dezelfde keymap als Issues. De rij-spacing matcht Issues — zelfde dichtheid, zelfde spiergeheugen.

• Sticky chrome — header, toolbar en kolomheader blijven vast tijdens scrollen.
• Detail-pager — open je een project vanuit de lijst, dan onthoudt de detailpagina filter+sort. Met [ / ] loop je naar het vorige/volgende project binnen die filter, zonder terug naar de index.
• Bulk-acties — selecteer rijen (x, Shift+x, Cmd/Ctrl+A) en een sticky toolbar verschijnt met de destructieve acties achter een confirm.
• Workflow-continuïteit — acties vanaf de lijst (mode wisselen, archiveren) houden je op /projects met de rij optimistisch bijgewerkt.

Keymap en command-palette: zie Toetsenbord & command palette.

Primair doel en use cases

Ieder project heeft één primair doel — waarvoor je het gebruikt — plus nul of meer aanvullende use cases:

• Support — klantvragen afhandelen met gecontroleerde antwoorden; escalatie naar engineering is een expliciete menselijke stap.
• Engineering — issues analyseren met codecontext, patches verifiëren in een sandbox, leveren als pull requests achter goedkeuringen.
• Deployment governance — deploymentactiviteit observeren en goedkeuringen organiseren. Een provider observeren betekent nooit dat FixControl erop kan ingrijpen; de enige gecontroleerde actie is vandaag het promoten van een gepauzeerde Argo Rollout na een goedgekeurde gate.
• Security (bèta) — de meegeleverde scanners draaien op gekoppelde code en risico's naar gecontroleerde remediation leiden.
• Knowledge — kennisbronnen verbinden en brongebonden antwoorden krijgen. Heeft geen codebase en geen ticketintegratie nodig.
• Custom — je eigen combinatie samenstellen.

Het doel bepaalt dashboardprioriteit, readiness-checks en aanbevolen veilige defaults. Het verleent nooit permissies, omzeilt nooit goedkeuringsregels en voert nooit een externe actie uit — capabilities worden altijd afgeleid uit wat werkelijk gekoppeld en gezond is. Een project kan doelen combineren (bijvoorbeeld Engineering + Security of Support + Knowledge); het primaire doel leidt, de andere voegen hun secties en checks toe.

Een project aanmaken

1. Ga naar Projects en klik New project.
2. Kies wat je wilt bereiken (het primaire doel, in gewone taal).
3. Selecteer de gekoppelde organisatiebronnen die bij dit project horen — kanalen, mailboxen, codebases. Alleen bronnen die jij mag zien worden aangeboden.
4. Bevestig de projectcontext, voeg eventueel extra use cases toe en controleer de exacte configuratie voordat er iets wordt toegepast. Annuleren past niets toe.

Nieuwe projecten starten standaard in Sandbox-modus. Pas dit aan op de detailpagina: Read-only voor alleen-lezen toegang, Sandbox voor veilig experimenteren, of Writable als agents direct mogen schrijven.

Wat je kunt koppelen

Op de projectdetailpagina beheer je vier soorten context:

• Codebases — repositories of mappen waarin agents werken. Eén ervan kun je markeren als default (ster-icoon). WINDEV-codebases krijgen een eigen WD-label.
• Business Integrations — externe systemen die agents in dit project mogen raadplegen. Configureer ze eerst in Settings → Integrations.
• Knowledge sources — kennisbronnen (analyses, technische documenten, procedures) die automatisch verschijnen zodra ze aan een gekoppelde codebase hangen.
• Guardrails — regels in vrije tekst die agents moeten volgen binnen dit project. Korte, expliciete instructies werken het beste.

Tags helpen bij filteren en zoeken op de overzichtspagina.

LLM-first chatbegrip

De projectinstellingen hebben een per-project toggle LLM-first chatbegrip (groep Automatisering, standaard uit). Staat hij aan, dan worden berichten in de Slack- en Teams-kanalen van dit project eerst door het taalmodel geïnterpreteerd — met threadcontext meegewogen — in plaats van door de deterministische patroonregels, waardoor vrije formuleringen veel vaker begrepen worden. De regels blijven bestaan als tie-break en vangnet: valt de AI-provider uit, dan nemen zij het over.

Dezelfde toggle bepaalt hoe een verzoek om een ticket bij te werken gelezen wordt. Eén bericht mag om meerdere dingen vragen ("maak een klant aan Acme B.V. en info@acme.nl en stuur het antwoord"); dat wordt als één plan begrepen en als één bevestigingskaart met genummerde stappen getoond. Ontbreekt er precies één gegeven, dan stelt de bot daar een gerichte vraag over in plaats van te vragen of je het anders wilt formuleren.

Dit is alleen begrip. Elke actie die eruit volgt loopt nog steeds door dezelfde bevestigingskaarten en goedkeuringen als voorheen — een beter begrepen verzoek betekent nooit uitvoering, en één klik op een plankaart voert precies de stappen uit die op die kaart stonden. De prijs is iets extra latency en AI-kosten per bericht.

Sandbox-database voor migraties

Voordat een patch toegepast kan worden, verifieert FixControl 'm in een geïsoleerde sandbox — bouwen en testen tegen een kopie van je code. Voor codebases met een migratie-toolkit (Prisma, Drizzle) horen daar databasemigraties bij, en die hebben een database nodig. Per codebase kies je hoe die database geleverd wordt via Settings → Codebases → (bewerken) → Sandbox database:

• Standaard — gebruik de systeembrede instelling.
• Geen — sla databasemigraties over tijdens de verificatie.
• URL — verifieer tegen een database die jij levert. Vul de connectiestring in bij Database-URL; die wordt versleuteld opgeslagen en alleen voor deze codebase gebruikt. Wijs naar een geïsoleerde wegwerp-database, nooit je productiedatabase — de sandbox draait de code van de patch ertegen.
• Docker — FixControl start per run een verse, wegwerp-PostgreSQL en verwijdert die daarna (vereist de Docker-sandbox-executor).

Is er geen database geconfigureerd, dan worden migratie-stappen simpelweg overgeslagen zodat ze de patch niet blokkeren.

Saved views

Standaard views: All, Mine, Sandbox, Writable, Read-only. Operators voegen hun eigen toe; saved views vangen de volledige filter-state — filters, sort, page size, kolomzichtbaarheid — zodat een collega die de link opent dezelfde slice ziet.

Projectgeschiedenis

Klik op Patch History rechtsboven om alle door agents gegenereerde codewijzigingen in dit project te zien. Filter op status (draft, approved, applied, rejected), agent of workspace, groepeer per issue, en bekijk het oorspronkelijke prompt en de gebruikte tool-calls per patch. Niets wordt zonder jouw goedkeuring toegepast.

Veelgestelde vragen

Kan een issue in meerdere projecten zitten? Nee. Een issue wordt aan één project gekoppeld via zijn workspace.

Wat gebeurt er als ik een project verwijder? Bestaande sessies die aan het project gekoppeld waren behouden hun reeds gerefereerde context — je verliest dus geen werk, maar het project zelf is weg.

Waarom zie ik geen kennisbronnen? Kennisbronnen verschijnen pas zodra ze aan één van de gekoppelde codebases hangen. Voeg eerst de codebase toe.