Capability-modules

Mechaniek + surface voor één samenhangend vermogen. Waar een kit weet hoe je iets doet, levert een capability-module een compleet vermogen inclusief het oppervlak waarmee een gebruiker het aanraakt.

Elke module is een eigen, privé npm-package @seifer-webapp-factory/capability-module-<slug> — restricted, net als de kits.

De negen modules

Slug	Vermogen
authentication	Inloggen, sessies, identiteit
authorization	Rechten en rollen
account	Accountbeheer
billing	Facturatie en afrekenen
media	Bestanden en media (componeert de storage-kit)
user-settings	Gebruikersvoorkeuren
organizations	Organisaties en lidmaatschap
contact	Contactformulieren en -stromen
analytics	Gebruiksgegevens

Templates, geen imports

Dit is het onderscheidende punt. Een module publiceert zijn NestJS/Vue-oppervlak als materialiseerbare templates — je kopieert het je project in en past het aan. Je importeert het niet.

Dat maakt het upgrade-pad wezenlijk anders dan bij een kit: bij een nieuwe versie doet scaffolder-core een three-way merge tussen de oude template, de nieuwe template en jouw gedivergeerde versie.

Nog niet end-to-end aangetoond

Materialiseren + three-way merge op een gedivergeerde surface is de kern van het hele model — en wordt nergens end-to-end bewezen. Zie hieronder.

Slug ≠ packagenaam

De slug is de module-identiteit: manifest.name, de directorynaam, requires.modules, en waar tabelprefixen en i18n-namespaces aan hangen. De packagenaam is puur distributie. Conventie: foundation/capability-modules/README.md.

Wat er nog niet bewezen is

Er is een testharnas — foundation/capability-modules/integration-app — dat 6 van de 9 modules assembleert (auth, account, authorization, billing, media, user-settings) en ze op één pool met één JWT boot. Waardevol, maar het is een harnas, geen oplossing.

Wat het niet bewijst:

Gat	Waarom het telt
Registry-installatie	Het trekt modules binnen via relatieve paden, niet via een geïnstalleerd package. Het zegt dus niets over wat er in de tarball zit.
De host-kits	Het bouwt een Nest-testing-module en omzeilt daarmee config en http volledig — juist de kits die het zwaarst gebruikt worden.
Drie modules	analytics, organizations en contact komen er nergens in voor. Geen enkele assemblagepoort.
De frontend	Er is geen assemblage-bewijs voor de frontend-kits.
Het upgrade-pad	De three-way merge op een gedivergeerde surface wordt nergens end-to-end aangetoond.

Dat is niet theoretisch: precies dit gat heeft in augustus 2026 drie echte fouten verborgen gehouden.

Wat een echte integratie-oplossing wél moet doen: installeren via npm ci uit de registry, echt opstarten met de config- en http-kit, alle negen modules naast elkaar op één identiteit, een frontend die de kits daadwerkelijk wiret, en een aangetoonde upgrade over een surface die de oplossing zelf heeft aangepast.

De assemblagepoort

showcase/ is de negen-module-assemblagepoort. Het consumeert de foundation als gepubliceerde tarball, nooit als zustermap — en dát is precies wat het bewijst.

cd showcase
npm install && npm run test:integration   # vereist Docker + draaiende registry

Waarom die poort niet in foundation woont

Vanuit foundation aanroepen zou testen wat er de vorige keer is gepubliceerd, niet wat er in je werkmap staat. De echte volgorde is bump → publish → install → vanuit showcase draaien.

Losse eindjes

• apply-*-skill-dekking. create-capability-module stap 12 eist per module een apply-<slug>-module-skill. Bij vier modules klopt dat niet: billing heeft alleen een spec, organizations alleen een SKILL.md, en media en contact geen van beide. media is de scherpste — dat is juist de module die de storage-kit componeert. Niemand ziet het, want de conformance-check stopt bij de 22 kits.
• Storage v1 → v2. Storage v2 is nu de kit; v1 is laten vallen. Sinds het debuut op 0.1.0 klopt de v1→v2-migratietekst in media/manifest.ts niet meer: er is nooit een 1.x gepubliceerd, dus die migratie kan geen enkele consument uitvoeren.