AINM

@rdworkx/components als gedeelde bouwlaag voor je AI delivery teamDeze pagina legt uit hoe het versiebeheerde @rdworkx/components pakket en de auto-gegenereerde catalogus binnen RD Workx gebruikt horen te worden: niet als technische build-uitleg, maar als vaste bibliotheek en beslislaag voor herbruikbare componenten die AINM per PBI raadpleegt en die AINM-gestuurde stories sneller, consistenter en slimmer laat opleveren via ALM.

Rol in deliveryHerbruikbare bouwlaag

@rdworkx/components is hier geen technische uitlegpagina, maar het versiebeheerde npm-pakket plus catalogus waar het AI delivery team gedeelde componenten, patronen en bouwblokken hoort te zoeken en te beheren.

Wanneer teamleden @rdworkx/components gebruikenBij elke nieuwe story

Voor development start, moet eerst de @rdworkx/components catalogus worden geraadpleegd of login, datumselectie, beheer-tabs, LLM-selectie of andere gevraagde UI al als standaard bouwblok bestaat.

Wie @rdworkx/components activeertAINM + AI executors

AINM beheert de stories en fases en raadpleegt de @rdworkx/components catalogus per PBI; het delivery team hoort het pakket als vaste bron voor hergebruik mee te nemen tijdens refinement, development en rollout.

DeploymentmodelALM levert apps uit

@rdworkx/components levert de gedeelde bouwstenen en afspraken; ALM blijft de plek waar concrete applicaties per repo worden gebouwd en gedeployed naar DEV/OTAP.

Wat @rdworkx/components binnen RD Workx betekent

Werkwijze

Binnen RD Workx is @rdworkx/components het versiebeheerde npm-pakket en de bijbehorende catalogus voor herbruikbare componenten, patronen en featureblokken die meerdere apps binnen de suite kunnen gebruiken. Denk aan authenticatie, datum pickers, beheer-tabs, LLM-selectie, formulieren, dashboards en andere vaste bouwstenen.

Wat AINM ermee moet doen

Werkwijze

AINM moet user stories niet behandelen alsof elke app vanaf nul begint. De ontwikkelstroom hoort per PBI eerst de @rdworkx/components catalogus te raadplegen of de gevraagde functionaliteit al bestaat, daarna pas nieuw werk te bouwen. Alleen wat echt nieuw is, wordt custom ontwikkeld.

Wat het oplevert voor je AI devteam

Werkwijze

Minder dubbel werk, consistente UX, snellere delivery en een duidelijker proces: eerst hergebruik, dan pas maatwerk. Daardoor kan je AI-team sneller stories afronden en houd je je suite consistenter terwijl ALM de uiteindelijke deploy verzorgt.

De gewenste werkelijkheid in AINM

Procesdoel

Deze pagina hoort het operating model van je AI-team uit te leggen: eerst de @rdworkx/components catalogus raadplegen, daarna pas bouwen.

AINM beheert vandaag al backlog-items, delivery-fases en uitrolrichtingen via ALM.
Deze pagina moet daarom niet vooral uitleggen hoe je buildt, maar hoe het delivery team het @rdworkx/components pakket en de catalogus in de dagelijkse flow hoort te gebruiken.
De gewenste werkwijze is: story komt binnen in AINM → team raadpleegt de @rdworkx/components catalogus op een bestaand component → dat component wordt als basis hergebruikt → alleen de ontbrekende delta wordt nieuw gebouwd → bewezen nieuwe componenten worden daarna teruggeoogst naar @rdworkx/components.
Hiermee wordt @rdworkx/components de gedeelde bron voor suite-brede UI en featurehergebruik, terwijl apps nog steeds zelfstandig per repo via ALM worden opgeleverd.

Wat je hiermee afdwingt

Waarde

@rdworkx/components moet de suite slimmer maken door standaardisatie actief onderdeel van delivery te maken.

Voorkom opnieuw bouwen

Een story voor een loginpagina, datumselectie of beheer-tab hoort eerst te starten met: staat dit al in de @rdworkx/components catalogus?

Geen nieuwe auth-flow bouwen als een standaard login-module al in @rdworkx/components beschikbaar is.
Geen losse datum-picker per app maken als dezelfde interactie al eerder is opgelost.
Geen aparte LLM-keuzepagina ontwerpen als er al een breed inzetbaar selectiepatroon bestaat.

Maak oogsten naar @rdworkx/components eenvoudig

Goede componenten uit afgeronde apps moeten terug het versiebeheerde @rdworkx/components pakket in kunnen stromen.

Als een app al een sterke LLM-selectiepagina heeft, moet die kunnen worden opgeschoond en geoogst tot een @rdworkx/components-standaardcomponent.
De businessregel is niet: laat het in de app staan. De regel is: als meerdere apps dit kunnen gebruiken, oogst het naar @rdworkx/components.
Zo groeit @rdworkx/components op basis van bewezen werk uit echte apps, niet op basis van theoretische abstrahering.

Hoe @rdworkx/components in de deliveryflow gebruikt hoort te worden

AINM → Team → ALM

Dit is de beoogde operationele flow voor stories die door AINM worden beheerd en door je AI delivery team worden uitgevoerd.

Stap 1

Refinement: herken hergebruik al in de story

Tijdens refinement moet het team expliciet markeren welke delen van de story mogelijk al in de @rdworkx/components catalogus staan. 'Maak een inlogpagina' is niet alleen een bouwvraag, maar eerst een reuse-vraag.

AINM hoort dus niet alleen acceptance criteria te beheren, maar ook de check: staat dit al in de @rdworkx/components catalogus of moet het nieuw worden toegevoegd?

Stap 2

Development: raadpleeg eerst de @rdworkx/components catalogus, bouw pas daarna

Wanneer development start, is de eerste stap niet direct coderen maar de @rdworkx/components catalogus raadplegen of het component, patroon of de feature al als gedeelde bouwsteen beschikbaar is.

Bestaat het al? Gebruik het als basis. Bestaat het deels? Breid het uit. Bestaat het niet? Bouw alleen de ontbrekende delta app-specifiek met zicht op later oogsten.

Stap 3

Oogsten: haal bewezen componenten uit apps terug naar @rdworkx/components

Als een app een sterk herbruikbare oplossing oplevert, zoals een LLM-selectiepagina of een beheer-tabstructuur, moet het team dat actief kunnen oogsten tot standaardcomponent in @rdworkx/components.

De vraag is dan: welke app-specifieke logica haal je eruit zodat er een nette, suite-brede bouwsteen overblijft die in de catalogus terechtkomt?

Stap 4

Delivery: lever de app per repo uit via ALM, niet @rdworkx/components zelf

@rdworkx/components is de bron van de herbruikbare bouwblokken. De uiteindelijke app wordt nog steeds via het normale RD Workx deliveryproces gebouwd, gevalideerd en per repo via ALM uitgerold.

Dus: @rdworkx/components standaardiseert wat gebouwd wordt; ALM levert het resultaat per repo uit naar de omgeving.

Stap 5

Lerend systeem: elke afgeronde story kan @rdworkx/components sterker maken

Na oplevering hoort het team te beoordelen of nieuw gemaakte UI of logica eigenlijk suite-breed waardevol is. Zo wordt de @rdworkx/components catalogus stap voor stap rijker en daalt de hoeveelheid maatwerk per volgende app.

Dit maakt van @rdworkx/components een actieve delivery-versneller in plaats van een passieve documentatielaag.

Als een story zegt: maak een loginpagina

Praktijk

De standaardreactie is niet direct bouwen, maar eerst hergebruik toetsen.

1. Raadpleeg de @rdworkx/components catalogus op bestaande auth/login bouwstenen

Kijk eerst of de functionaliteit al als standaard bestaat.

2. Bepaal of de story volledig, deels of niet kan leunen op @rdworkx/components

Gebruik bestaand werk waar mogelijk.

3. Bouw alleen de ontbrekende delta app-specifiek

Voorkom kopieën van al bestaande patronen.

4. Evalueer na oplevering of nieuwe varianten teruggeoogst moeten naar @rdworkx/components

Laat het pakket groeien op basis van bewezen usage.

Als een bestaande app al iets goeds heeft

Praktijk

Goede schermen of componenten mogen niet opgesloten blijven in één app.

1. Benoem het onderdeel als kandidaat om te oogsten

Bijv. LLM-selectie, datum-picker, beheer-tabs, wizard of auth-flow.

2. Haal app-specifieke aannames eruit

Maak props, configuratie en states generiek genoeg voor meerdere apps.

3. Leg vast wat het standaardcontract wordt

Welke inputs, outputs, states en extensiepunten gelden suite-breed?

4. Laat volgende stories dit nieuwe @rdworkx/components-bouwblok als eerste keuze gebruiken

Oogsten heeft pas waarde als hergebruik daarna verplicht wordt meegewogen.

Hoe het AI delivery team @rdworkx/components hoort te gebruiken

Gebruik

@rdworkx/components moet een vast beslispunt in de deliveryflow zijn.

Bij refinement: markeer reuse-kansen in de story.
Bij development: raadpleeg de @rdworkx/components catalogus vóórdat maatwerk wordt gebouwd.
Bij review: toets of een nieuw onderdeel suite-breed nuttig is.
Bij deployment: lever de app per repo uit via ALM, maar houd het gedeelde stuk in @rdworkx/components beheerd.
Bij volgende stories: hergebruik het standaardcomponent als voorkeursroute.

Welke type onderdelen hier thuishoren

Gebruik

Dit zijn typische kandidaten voor @rdworkx/components-standaardisatie binnen de RD Workx suite.

Authenticatieblokken: loginpagina's, provider-knoppen, sessiestatus, guards.
Form en invoercomponenten: datum pickers, selectors, filters, tabellen, statuschips.
Beheerpatronen: beheer-tabs, detailpanelen, CRUD-shells, feedbackmodals, sidebars.
AI/LLM-specifieke UI: providerkeuze, modelselectie, promptinstellingen, usage-overzichten.
Deliverypatronen: story-statuskaarten, GWR-indicatoren, deploymentbewijs, activitywidgets.

Hoe je een nieuw herbruikbaar component oogst naar @rdworkx/components

Oogstpad

Gebruik dit pad wanneer een bestaand onderdeel uit een app te waardevol is om app-specifiek te blijven.

1. Signaleer standaardisatiekansen vroeg

Niet wachten tot drie apps hetzelfde probleem opnieuw hebben opgelost.

Komt dezelfde behoefte terug in meerdere stories of apps? Dan is het een kandidaat om naar @rdworkx/components te oogsten.
Heeft een component een duidelijke businessbetekenis, zoals login, LLM-selectie of beheer-tabnavigatie? Dan hoort standaardisatie direct in beeld te komen.
Blijft het volledig uniek voor één scherm of één klantcase? Dan blijft het lokaal in de app.

2. Oogst vanuit bestaand werk, niet uit theorie

Gebruik bewezen app-implementaties als bron voor @rdworkx/components-standaardcomponenten.

Neem een werkend onderdeel uit een afgeronde app als startpunt.
Strip app-specifieke labels, API-koppelingen, permissies en layout-aannames weg.
Houd alleen het suite-brede contract over dat meerdere apps kunnen consumeren.

3. Definieer het herbruikbare contract en de useWhen-match

Een standaardcomponent moet duidelijk beschrijven wat vast is, wat configureerbaar is, en wanneer het past.

Leg props, staten, validaties en hooks vast op basis van businessbetekenis.
Ondersteun varianten via configuratie, niet via copy-paste forks.
Voorzie elk component van een useWhen-beschrijving zodat AINM het via de auto-gegenereerde catalogus (components.json) per PBI kan matchen op de juiste story.

4. Maak hergebruik onderdeel van delivery discipline

Het team moet niet vrijblijvend kiezen of het de @rdworkx/components catalogus raadpleegt.

Voeg in refinement/development expliciet de vraag toe: 'welke @rdworkx/components-bouwstenen gebruiken we hier?'.
Laat stories of uitvoeringsprompts verwijzen naar het relevante standaardcomponent zodra de catalogus een useWhen-match teruggeeft.
Behandel het overslaan van bestaande @rdworkx/components-bouwstenen als procesafwijking, niet als neutrale keuze.

5. Laat @rdworkx/components meegroeien met de suite

Elke goede generieke oplossing moet toekomstige stories versnellen.

Oogst nieuwe standaardonderdelen zodra hergebruik realistisch en waardevol is.
Werk de useWhen-beschrijving in de auto-gegenereerde catalogus bij zodat het AI-team weet wanneer dit de voorkeursroute is.
Bewaak dat @rdworkx/components een productief pakket blijft en geen dumpplaats van half-afgemaakte componenten wordt.

Bronnen van waarheid

Governance

Businessdoel van @rdworkx/componentsGedeelde componenten en featureblokken voor meerdere apps in de RD Workx suite

ProcestriggerElke nieuwe story moet eerst op mogelijk hergebruik worden beoordeeld

Story-orchestratieAINM beheert de stories, fasen en delivery-aansturing en raadpleegt de catalogus per PBI

GebruiksmomentRefinement en development moeten @rdworkx/components expliciet meenemen

CatalogusAuto-gegenereerde components.json met useWhen-matching die AINM per PBI consulteert

OogstrouteBewezen componenten uit afgeronde apps terugbrengen als @rdworkx/components-standaard

DeploymentConcrete apps blijven per repo via ALM gebouwd en uitgerold worden

VoorbeeldenAuth, datum pickers, beheer-tabs, LLM-selectie, gedeelde delivery-UI

Guardrails voor het team

Niet vergeten

Gebruik @rdworkx/components niet als technische etalage, maar als operationele reuse-laag voor het AI delivery team.
Bij nieuwe stories eerst de catalogus raadplegen of het bouwblok al bestaat; pas daarna nieuw maatwerk maken.
Oogst alleen onderdelen naar @rdworkx/components die echt meerdere apps kunnen bedienen.
Haal app-specifieke logica weg voordat iets als standaardcomponent wordt opgenomen.
@rdworkx/components standaardiseert bouwstenen; ALM blijft per repo verantwoordelijk voor de concrete app-deployments.