Fase 2 · Technische benodigdheden & scaffold

Map: scaffolder/ + foundation/ · Vraag: waarmee bouwen we dit, en hoe zet ik het skelet neer?

Deze fase bestaat uit twee helften die vaak op één hoop gegooid worden, maar echt verschillend zijn:

1. In kaart brengen — welke technologie is nodig, hoe volwassen is die, welke architectuur past, welke kits en modules gaan mee?
2. Scaffolden — dat vertalen naar een scaffolder.config.yaml en er een runnende skeleton uit genereren.

Helft 1 · De technische benodigdheden in kaart

technische-haalbaarheid

De skill die de brug slaat tussen "dit willen we" en "dit is er technisch voor nodig". Hij doet zelf webresearch naar tech-maturity — hij vraagt de gebruiker niet om data die opzoekbaar is, alleen om beslissingen en bevestigingen.

Per kandidaat-oplossing (een HMW-statement) levert hij:

Uitkomst	Vorm
Benodigde technologieën	Concrete stack-onderdelen
Maturity	proven · emerging · experimental
Complexiteit	1–5
Blockers	Technisch én regulatory
Verdict	🟢 / 🟡 / 🔴 met een ruwe oplossingsrichting

Bronvoorkeur: NL voor regulatory en datatoegang (Rijksoverheid, RVO, NEN, Autoriteit Persoonsgegevens, RIVM, branche-organisaties), internationaal voor pure tech-maturity (Hugging Face, GitHub, vendor-docs, arXiv, Gartner). Bij gebrek aan webtoegang wordt maturity expliciet gelabeld als [Aanname — geen web-validatie].

De lens-tags uit fase 1 sturen de zoekrichting: L2 duwt naar een voice- en wearable-stack.

Tijdsbudget: ~2–4 minuten per HMW; boven de 10 wordt er gebatcht.

De architectuur- en ontwerpbeslissingen

Waar de haalbaarheidstoets breed kijkt, leggen deze skills de keuzes vast. Elk levert een expliciete afweging met "wanneer wel / wanneer niet".

Domein	Skills
Architectuurvorm	architecture-pattern-selection · architecture-tradeoff-analysis · system-decomposition · ddd-strategic-modeling
Data	database-technology-selection · conceptual-data-modeling · logical-data-modeling · physical-data-modeling · data-dictionary-definition
API & integratie	api-design · api-contract-specification · api-versioning-strategy · integration-pattern-selection · event-schema-design · webhook-design
Identiteit	authentication-strategy-design · authorization-modeling
Veiligheid	threat-modeling · attack-surface-analysis · security-requirements-classification · encryption-strategy · secrets-management-design
Operationeel	slo-sli-definition · observability-strategy · logging-tracing-design · performance-budgeting · scalability-modeling · rate-limiting-throttling-strategy
Vastleggen	technical-specifications · adr-writing · interface-specification

Niet alles hoeft

Dit is een menukaart, geen checklist. technische-haalbaarheid en architecture-pattern-selection zijn het kritieke pad; de rest zet je in waar de onzekerheid zit.

Welke bouwblokken gaan mee

De uitkomst bepaalt de compositie uit de foundation: welke van de 22 kits, welke van de 9 capability-modules, en het design system als styling-laag.

Dat is receptuur, geen vaste template. Hoe meer er kant-en-klaar in de compositie zit, hoe minder de scaffolder hoeft af te leiden — en hoe minder frictie in beide naden.

→ Foundation

Helft 2 · Scaffolden

De CLI

scaffolder generate scaffolder.config.yaml   # zet app/ neer
scaffolder add-module <naam>                 # één entiteit erbij
scaffolder propose                           # voorstel tonen
scaffolder sync                              # plumbing bijwerken

De gegenereerde stack: NestJS + Nuxt + Postgres, met Docker eromheen.

Verantwoordelijkheid

Bezit	De code-spine (config → persistence → mailer → auth → http-kernel), de plumbing (.scaffolder/manifest.json), de versie-pinning, en sync.
Doet NIET	Businesslogica of entiteitsvelden verzinnen. En het hoort geen productie-/ops-artefacten te bezitten — zie naad B; vandaag is dat een botsing.
Levert op	app/ + .scaffolder.json + manifest.

De seams

De scaffolder zet een skelet neer dat compileert en draait, maar leeg is. Twee plekken zijn expliciet bedoeld om te vullen — dat gebeurt in fase 3:

Seam	Wat erin komt
modules.ts	De domeinmodules — welke entiteiten bestaan er
domain-migrations.ts	De echte velden en relaties

Wat add-module neerzet is een stub: CRUD over id / createdAt / updatedAt.

De bouwblokken inwiren

Hier komen de foundation-skills in beeld. Elk kit-package draagt zijn eigen integratie-skill:

Skill	Aantal	Doet
integrate-<kit>-kit	22	Installeren, poorten injecteren, configureren, de valkuilen bewaken, verifiëren
apply-<module>-module	per module	De capability-module materialiseren in het project
create-capability-module	1	Een nieuwe module bouwen volgens de conventie

Drie aanroeppunten: vanuit de scaffolder, vanuit een solution ("integreer de storage kit"), en vanuit de kit zelf ("voeg deze kit toe aan die solution"). Dat werkt zonder registry omdat kits en solutions op dezelfde schijf staan.

→ Skills · Kits

De umbrella bestaat niet meer

@seifer-webapp-factory/kits — en daarmee de webappFactoryVersion die de scaffolder nog pint — is per 2026-08-17 opgeheven. De pin in scaffolder/src/convention/convention.ts moet daarop mee.

Gate 2

Voorwaarden om door te mogen: de code compileert, /health is groen, en de liveness is gehaald.

Draaien

cd scaffolder
npm install && npm run build
npm run dev            # tsx src/cli.ts
npm run docs:dev       # eigen VitePress-docs onder docs/

Of via het control panel op localhost:4700.

Volgende

→ Fase 3 · Ontwikkelen & personaliseren