Skip to content

Gates & orchestratie

De keten loopt niet vanzelf door. Op vaste punten stopt hij en beslist een mens.

Waarom gates

Een agent die de hele keten autonoom draait, deployt uiteindelijk iets wat niemand wilde, op een host die geld kost, achter een domein dat iemand handmatig moet regelen. Het model is daarom consequent: een agent stelt voor, een mens keurt goed.

De gates

GateWaarVraagWie
Spoor-gates ×5binnen kans-uitwerkenScherp genoeg om door te gaan naar het volgende spoor?mens
Gate 1na fase 1Bouwen we dit? (Go/No-Go)mens
Gate 2na fase 2Compileert het, is /health groen, is liveness gehaald?mens/agent
Gate 3na fase 3AC groen, kwaliteit, security, toegankelijkheid?mens
Kostenhost applyMag deze host aan?mens
ProductieupMag dit live?mens
SecretsdoorlopendDe waarden zelfmens
Domein + DNSvoor verifyRegistratie en recordsmens

De vijf spoor-gates zitten vóór gate 1 en zijn de goedkoopste van allemaal: ze stoppen een kansloze richting na spoor 1 in plaats van na het scaffolden.

Gates zitten in de skills, niet ernaast

kans-uitwerken stopt zelf bij elke spoor-gate en vraagt om een Go via AskUserQuestion. onboard-solution begeleidt de gebruiker expliciet door de stappen die alleen die kan zetten. De gate is dus geen procedure die je ernaast moet onthouden — hij is ingebakken in de uitvoering.

De orchestrator

Het doel is één dunne orchestrator die per fase het bestaande commando of de bestaande skill aanroept en bij elke naad stopt op een gate:

seifer <idee|opportunity-ref>
  0. pick     → lees solutions/candidates.json → toon buildReady[]      [mens kiest]
               (geen proza-parsing; kandidaat = verdict build-now & sporen 5)
  1. explore  → kans-uitwerken            → GATE 1 (Go/No-Go)          [mens]
               (indien nog niet buildReady: eerst sporen afmaken)
  2. bridge   → generate-scaffolder-config → toon config, bevestig      [mens/agent]
  3. scaffold → scaffolder generate (+ add-module per entiteit)         [agent]
              → GATE 2 (compileert, /health groen)                     [mens/agent]
  4. repo     → gh repo create --push (indien nodig)                    [auto, token]
  5. deploy   → onboard-solution                                        [de bestaande gates]

Fase 3 ontbreekt in dit schema

Deze schets uit SEIFER.md gaat van scaffold direct naar deploy. Het ontwikkel- en personalisatiewerk — kanban, TDD, rebrand, de kwaliteitspoorten — zit er niet in, terwijl daar het meeste werk gebeurt. Een volledige orchestrator moet ook stap 3b. develop kennen, met gate 3 erachter.

Het kernpunt

De orchestrator bezit geen logica van de fases. Hij sequenceert, toont diffs en dwingt de goedkeuringsstappen af. Elke fase blijft los bruikbaar.

Dit is gap G9 — er is nog geen top-level orchestratie over de keten, en zonder die laag is er geen "één roundtrip".

Het control panel

Er is wel al een lokaal bedieningspaneel: control-panel/. Een webinterface plus een dunne orchestrator-kern die zijn paden afleidt van zijn eigen locatie.

bash
cd control-panel
npm install && npm start     # → http://localhost:4700

Links kies je een project (gegroepeerd per domein), rechts stroomt scaffolder generate live in een terminal. Onder de projecten staan de build-kandidaten uit solution-explorer/solutions/candidates.json, read-only.

Dezelfde kern is ook een CLI:

bash
node bin/seifer.mjs list
node bin/seifer.mjs scaffold sandbox/demo

v1 dekt alleen scaffold

Het paneel wiret op dit moment alleen de scaffold-stage — een pure CLI zonder gates. De agent-stages explore, bridge en deploy hebben menselijke Go/No-Go-gates en draaien straks in een interactieve terminal in ditzelfde paneel.

Servers opruimen

Start je het paneel om iets te controleren, stop het daarna weer. Hetzelfde geldt voor Verdaccio en elke dev-server.

Seifer — interne documentatie. Bron van waarheid blijft de repo zelf.