Losse projecten, één engineeringstandaard

Er draaien inmiddels vier repo's op de vloot. Twee daarvan hebben een compleet andere vorm dan het project waarvoor ze ooit gebouwd is — andere taal, andere stack, geen eigen server, alleen door GitHub geleverde machines. Voor geen van beide is één regel gedeelde logica gekopieerd. Dat is de echte toets: niet of een contract denkbaar generiek is, maar of een project dat er niet op ontworpen is er zonder uitzonderingen in past.

Soms heb ik alleen een zin en nog geen plek. Daar is één poort voor, die er een bestemming bij zoekt en het issue daarnaartoe verplaatst — en weet hij het niet zeker, dan kiest hij niet maar vraagt hij het. Het meeste werk gaat daar niet langs: dat begint gewoon in de repo waar het thuishoort.

Lukt het niet om bij elke bestemming het genoemde pad op te halen, dan wegen paden niet mee en gedraagt de poort zich exact als voorheen. Een scherpere afstelling die stilletjes half werkt, is erger dan de botte versie.

achtergrondintake.yml is workflow_call-only, net als alle zestien workflows; een guard-script bewijst dat bij elke PR, zodat de poort nooit vanzelf kan starten. intake-decide.sh telt hele woorden uit routing.yml per consument, en weegt een genoemd bestandspad vijf keer zo zwaar als een trefwoord — een pad zegt iets over de plááts, een woord alleen over het onderwerp. Strikt de meeste punten wint; de winnaar krijgt het issue via een transfer, niet via een kopie.

als het misgaatGelijkspel of nul punten → label needs-routing en het issue blijft staan met een vraag. Die grensgevallen liggen vast in de golden-set: 08-grensgeval-domein-wint, 09-grensgeval-infra-wint, 10-gelijkspel-blijft-routing.

epic-orchestrator.yml houdt de reeks vast: fase-issues met een vaste volgorde, en alleen de eerste staat open. plan-critic.sh heeft het plan al mechanisch getoetst op concrete stappen en op een genoemde verificatie.

De bouwstap draait op de kant-en-klare Claude-Action — daar valt weinig aan te verbeteren. Wat het verschil maakt is alles eromheen, en dat is hier allemaal met de hand gezet: een turn-budget van 80 in plaats van ruim, een modelkeuze die uit het issuetype volgt, een concurrency-groep op het issue in plaats van op de run, en een allowlist die per commando is opgeschreven.

Die allowlist is de grootste knop. Ontbreekt er één commando, dan probeert de agent een omweg, krijgt weer een weigering, probeert iets anders — tot het budget op is. Eerder liep er zo een issue twee keer vast op 151 turns met 22 weigeringen en niets bruikbaars. Daarom telt de pijplijn die weigeringen nu achteraf: boven de drempel komt er vanzelf een melding dat er een regel ontbreekt, in plaats van dat het pas bij de derde dure run opvalt.

Bouwen gaat nu uitsluitend autonoom. Zelf meebouwen in een interactieve sessie werkt merkbaar prettiger dan diezelfde stap op een runner, dus er ligt een ontwerp om die bouwstap ook vanuit een chatsessie te kunnen oppakken. Additief, niet vervangend: de autonome route blijft de standaard voor achtergrondwerk, de tweede ingang is er alleen voor de gevallen waarin ik zelf meedoe. Allebei door dezelfde poort, dezelfde claim en dezelfde bot-identiteit — geen van beide krijgt een kortere weg.

Die claim bestaat trouwens al wél: vlak voor de agent begint leest de workflow de labels opnieuw, en draagt het issue er één dat zegt dat een sessie het al opgepakt heeft, dan stopt hij. Het label uit de gebeurtenis zelf is een momentopname; die her-check krimpt het venster waarin ze elkaar in de weg kunnen zitten tot vrijwel nul.

Naast constitution.md en doelen.md brengt een project vaak ook zijn eigen retrieval mee: RAG die antwoorden ophaalt uit de eigen documentatie of logs, en een eigen MCP-server die de agent gestructureerde toegang geeft tot de tools en data van dat project. deSchouwVloot zelf blijft daarbuiten — het bevat geen domeinlogica, dus die kennis hoort bij het project, niet bij de machinerie eromheen.

Bij één van die projecten staat dat inmiddels ook echt te draaien: vóórdat de agent aan een plan of build begint, doet een los leesscript één zoekopdracht per kennistabel — bekende faalpatronen plus de relevante documentatie — en injecteert alleen de beste treffers, in plaats van hele documenten opnieuw in te lezen bij elke sessie zonder geheugen. Faalt die zoekopdracht, dan bouwt de agent gewoon door zonder die context: de kennisbron mag nooit een harde afhankelijkheid worden.

Elke feature-PR draagt een klein codeblok: db=geen, net=bestaand, risico=laag — twaalf velden, elk met een gesloten antwoordlijst. Dat verving een checklist van tien vinkjes die alleen toetste of ze waren aangevinkt, niet of ze ook klopten. Nu haalt de check de daadwerkelijke bestandenlijst van de PR op en houdt elk antwoord ertegen: claim je db=geen terwijl er een migratie in de diff zit, dan is dat aantoonbaar onwaar — en gaat de PR rood, zonder dat ik ernaar hoef te kijken.