Wat is Seifer

Seifer is een keten van vier fases op een gedeelde fundering, die een idee omzet in een live product. Het is geen framework en geen product op zichzelf — het is de manier waarop de subsystemen op elkaar aansluiten, de skills die het werk uitvoeren, en de regels die dat aansluiten voorspelbaar houden.

Werknaam. De keten heette eerder roundtrip. Die term komt nog voor in oudere documenten en betekent hetzelfde: de héle tocht van idee tot levend product.

De ambitie, en waarom er gates zijn

De ambitie is om niet te stoppen bij "een mooi document" of "code die compileert". Een uitgewerkte businesscase die nooit gebouwd wordt is verspilling; een gescaffolde app die nooit draait ook. Seifer maakt de hele tocht.

Diezelfde ambitie is ook het risico. Een keten die vanzelf doorloopt, deployt uiteindelijk iets wat niemand wilde, op een host die geld kost, achter een domein dat iemand handmatig moet regelen. Daarom is de keten gegate: een agent stelt voor, een mens keurt goed. Geen volledige autonomie.

Dat is de spanning waar het hele ontwerp omheen staat: ambitie ↔ discipline.

Een roundtrip in vier fases

Wat elke fase doet

Fase	Vraag	Bezit	Levert op
1 · Ideation	Wat bouwen we, en waarom?	Het probleem, de markt, personas, MVP-scope, user stories + acceptatiecriteria, de technische richting, de wireframe	documentatie/ + solution-manifest.json
2 · Techniek & scaffold	Waarmee bouwen we het?	De technische beslissingen en de code-spine + plumbing	app/ + .scaffolder.json + manifest
3 · Ontwikkelen & personaliseren	Hoe wordt dit een product?	De businesslogica, de schermen, het merk, de kwaliteitspoorten	Een werkend, gemerkt, getest product
4 · Deployment	Draait het echt?	De live werking — waar het draait, TLS, secrets, status	Live product + registratie in platform.yaml

De foundation staat bewust naast die nummering. Het is geen fase maar de voorraad waaruit fase 2 en 3 putten. → Foundation

Vier fases, drie stages

SEIFER.md beschrijft de keten als drie stages met een artefact-eigenaar per stage. Deze site gebruikt vier fases, omdat het ontwikkel- en personalisatiewerk in de praktijk een eigen fase is met eigen skills en een eigen gate. De mapping staat in De keten.

Skills zijn de leidraad

Dit is het onderdeel dat het snelst over het hoofd wordt gezien. Skills voeren het werk uit. Ze weten wat er moet gebeuren, in welke volgorde, met welke output en waar de gates staan.

Fase	Kernskills
1 · Ideation	xplore (10 dimensies leegvragen) · ontdek-kansen (domein → opportunities) · kans-uitwerken (5 sporen, ~20 skills) · wireframing
2 · Techniek & scaffold	technische-haalbaarheid · architecture-pattern-selection · generate-scaffolder-config · integrate-<kit>-kit ×22 · apply-<module>-module
3 · Ontwikkelen	kanban-management · vue-development (TDD → QA → E2E uit Gherkin) · rebrand · theme-manager · software-quality-assessment · owasp-security-audit
4 · Deployment	onboard-solution

Erachter ligt een breder model: 40 disciplines van visie tot bouwklaar, elk met een agent, een vaste artefactlocatie en een plek in een dependency-graaf met dezelfde gates.

→ Skills — de leidraad · De 40 disciplines

Het kernprincipe

Grensregel: elke fase leest de output van de vorige als read-only bron van waarheid en schrijft alleen in zijn eigen laag. Geen enkele fase grijpt terug in de laag van een ander.

Concreet: de scaffolder verzint geen deploy-artefacten, en deployment schrijft geen app-code of productdefinitie. Dat maakt de keten herhaalbaar en veilig genoeg om een agent erop te zetten.

→ Verantwoordelijkheden

Wat Seifer níet is

• Geen npm-monorepo. Eén git-repo, ja. Eén npm-workspace, nadrukkelijk niet — zie Conventies.
• Geen autonome pipeline. Bij elke naad staat een gate. Kosten, productie, secrets, domein en DNS zijn menselijke beslissingen.
• Geen huis voor de producten. De negen live producten die platform.yaml beheert wonen buiten deze repo, in ~/Projects/seifer-projects/.
• Geen huis voor de exploratie-skills. Die leven in claude-code-plugins; solution-explorer is hun data- en outputmap.

Waar het vandaan komt

Elk onderdeel bestond al los. Wat ontbrak was de aansluiting: hoe komt de output van de ideation-fase schoon de scaffolder in, en hoe komt de gescaffolde code schoon de deploy in. Die twee overgangen heten hier naad A en naad B, en de frictie erin is geen theorie — hij is opgehaald uit één echte run door de hele keten.

→ Referentie-run family-choirs