Kits

Mechaniek, domein-loos. Een kit weet hoe je iets doet — cachen, mailen, rate-limiten — maar weet niets van jouw domein. Elke kit is een eigen npm-package@seifer-webapp-factory/kit-<tier>-<naam>, met eigen semver.

Het bouwpatroon

Elke kit volgt dezelfde vorm:

• Ports & adapters — een pure core met poorten, en dunne adapters eromheen
• Config-injectie — de host levert de configuratie, de kit vraagt er niet om
• Pure core + dunne adapter — de NestJS- of Vue/Nuxt-laag is zo dun mogelijk
• Eigen semver — elke kit beweegt op zijn eigen lijn

De 15 backend-kits

Kit	Waarvoor
kit-backend-config	Configuratie inlezen en valideren
kit-backend-http	De HTTP-kernel
kit-backend-persistence	Database-toegang
kit-backend-cache	Caching
kit-backend-observability	Logging, metrics, tracing
kit-backend-rate-limit	Verkeersbegrenzing
kit-backend-jobs	Achtergrondtaken
kit-backend-mailer	Uitgaande mail
kit-backend-auth	Authenticatie-mechaniek
kit-backend-access-control	Autorisatie-mechaniek
kit-backend-audit	Audit-log
kit-backend-privacy	Privacy-mechaniek
kit-backend-i18n	Vertalingen
kit-backend-storage	Bestandsopslag
kit-backend-test-kit	Testgereedschap

Wat er in de praktijk het zwaarst gebruikt wordt

http (24×) en config (23×). Dat is precies andersom dan de eerste indruk gaf: binnen de monorepo leken ze ongebruikt, omdat de integratie-app een Nest-testing-module bouwt en ze daarmee omzeilt.

De 7 frontend-kits

Kit	Waarvoor
kit-frontend-http-client	HTTP-client
kit-frontend-auth	Authenticatie aan de clientkant
kit-frontend-access-control	Autorisatie aan de clientkant
kit-frontend-forms	Formulieren
kit-frontend-i18n	Vertalingen
kit-frontend-notifications	Meldingen
kit-frontend-analytics	Analytics

De frontend-tier is bewust teruggesnoeid van 16 naar 7 kits, getoetst tegen de échte oplossingen.

Documentatie per kit

Alle 22 kit-packages hebben een README.md, geschreven uit de daadwerkelijke API-surface (exports, poorten, adapters, foutentypes) en niet uit het plan. Per kit: wat het is, install + peers, subpath-tabel, quick start, de poorten die de host levert, adaptertabel, errors, en de NestJS- respectievelijk Vue/Nuxt-adapter.

files staat op ["dist", "README.md"], dus de README zit vanaf de eerste publicatie in de tarball.

Skills per kit

Elke kit levert naast de code een skill mee die beschrijft hoe je hem in een oplossing inbouwt: installeren, poorten injecteren, configureren, de valkuilen bewaken, verifiëren. Daarmee is "hoe gebruik ik deze kit" uitvoerbare kennis in plaats van iets dat je uit de broncode moet afleiden.

Alle 22 bestaan. Ze heten integrate-<kit>-kit en leven lokaal in het package:

foundation/kit-packages/<kit>/
└── .claude/skills/integrate-<kit>-kit/
    ├── SKILL.md     de uitvoerbare skill die een agent laadt
    └── SPEC.md      de volledige specificatie erachter

De conventie staat in foundation/kit-packages/KIT-SKILL-CONVENTION.md:

• Eén skill per kit-package, alle 22 zonder uitzondering — ook waar het wiren een enkele import is. Een agent die een skill vindt voor storage en geen voor cache, leert dat skills optioneel zijn — en stopt met zoeken.
• Niet meepubliceren. files blijft ["dist", "README.md"]; de skill bestaat voor wie de repo op schijf heeft, niet voor wie het package installeert.
• Geen lichte variant. Dezelfde opbouw voor elk: Inputs · Always · Preserve/may change · modi · Output · Failure · Self-check.

Drie aanroeppunten: vanuit de scaffolder, vanuit een solution ("integreer de storage kit"), en vanuit de kit zelf ("voeg deze kit toe aan die solution").

De conventie dekt alleen de kit-tier

De capability-modules hebben hun eigen apply-*-module-skills onder foundation/.claude/skills/. Of die ook naar hun packages verhuizen is een aparte, uitgestelde vraag.

→ Skills — de leidraad

Een valkuil die dit opleverde

De zeven Nuxt-modules emitten een plugin die importeerde uit de umbrella (@seifer-webapp-factory/kits/frontend/*) in plaats van uit het losse kit-package. Wie alleen kit-frontend-auth installeerde en het ./nuxt-subpath gebruikte, kreeg een onvindbare import.

Waarom dat de opsplitsing overleefde: het zijn strings in een template-literal, dus tsc resolvet ze nooit. De fan-out van typecheck — juist toegevoegd om dit soort drift te vangen — komt niet in stringinhoud. Opgelost vóór de publicatie, bewezen met een schone install uit de echte registry.

De umbrella bestaat niet meer

@seifer-webapp-factory/kits is per 2026-08-17 opgeheven. Elke kit is nu zelfstandig. Verwijzingen naar de umbrella (waaronder webappFactoryVersion in de scaffolder) zijn achterstallig werk, geen geldig pad.