Agentic engineering · systeemanalyse

UGentic Marketplace — objectieve systeemanalyse

Analyse van de repository UGentic-marketplace (USoft, versie 0.27.0, 6 aug 2026): een Claude Code plugin-marketplace waarvan agentic-pipeline het hart is — een C4-gedreven intake-tot-merge pijplijn. Elke bevinding hieronder is herleidbaar tot een bestand in de repo. Beoordelingsmodel: twaalf vaste onderwerpen (T1–T12) voor agentic-ontwikkelsystemen.

Wat het systeem is

Eén voordeur (/intake) beheert een C4-model (workspace.dsl) en routeert elk verzoek naar precies één container en één van vier lanes (spike / patch / tweak / full). Daarna volgt een vaste keten: functionele spec (SBVR, R#) → scenariocatalogus (S#, Given/When/Then) → stackonderzoek → architectuur met versioneerde componenten → tests geschreven vóór de code → taakimplementatie in geïsoleerde worktrees → vijfvoudige review → commit per taak. Stories en taken leven uitsluitend in JIRA (idempotente, hervatbare upserts); beslissingen in een gedeeld decision-log en onveranderlijke ADR's.

De hoofdroute van /intake tot /commit-task. Een koperen stip is een fase-overgang waar een mens expliciet moet tekenen — acht van de elf stappen. Zijlanen (/spike, /tweak) en diagnose-skills (/check, /audit, /status, /gate) zijn omwille van leesbaarheid weggelaten.

Schaalfeiten

2 plugins in de marketplace (agentic-pipeline, documentation); 1 hoofdauteur.
23 pipeline-commando's + gedeelde kern; 13 subagents (incl. 5 adversarial-review-lenzen).
1.068 regels hook-TypeScript in 8 modules — de daadwerkelijke handhavingslaag.
±4.200 regels skill-instructies; ±13.200 regels / 112 bestanden totaal.

v0.27.0; minstens 6 releases in 3 dagen (0.22.0 → 0.27.0, 4–6 aug 2026) — hoog itereertempo.
1 MCP-server geregistreerd (JIRA); 0 CI-pipelines; 0 geautomatiseerde tests op de hooks.
2 host-adapters (Claude Code + oh-my-pi) op één gedeelde hook-kern — bewust agent-agnostisch.
8 van 11 hoofdroute-stappen eindigen in een menselijke harde stop.

Beoordeling per onderwerp — T1–T12

ID	Onderwerp	Systeem	Hoe het werkt	Handhaving	Volw.	Grootste gat
T1	Kernbeleid	POLICY.md (pipeline-core)	Acht bindende regels + eigenaarschapsmatrix per artefact, altijd in context; overtreding is een Major/Blocking-finding in /review.	hooks + gate	●●●●● 4	Geen drift-tests op het beleid zelf
T2	Fasen & skills	23 commando-skills + kern	Elke fase is een apart, expliciet aangeroepen commando; poorten ontstaan doordat skills elkaar nooit automatisch aanroepen.	structuur	●●●●● 4	Adoptie per doelrepo niet meetbaar
T3	Spec & architectuur	workspace.dsl · SBVR · ADR's	Eén C4-model als enige bron; spec (R#) en scenario's (S#) zijn de handles waar tests, taken en reviews op sleutelen.	docs + gate	●●●●● 4	Zwaar voor kleine wijzigingen (tweak-lane dekt deels)
T4	Verificatie	write-tests · /probe · /gate	Testschrijver is hook-blind voor src/; /probe herbouwt een component clean-room uit alleen de spec; /gate draait de definition-of-done.	hooks	●●●●● 4	Poorten draaien in de sessie, niet in CI
T5	CI/CD & shipping	—	Geen. Geen pipeline valideert de plugin of doelrepo's; /review en /gate zijn handmatig in-sessie; geen .github/ in de repo.	geen	●●●●● 1	Alles — het grootste gat van het systeem
T6	Werkverdeling	JIRA (MCP) · set_state.ts	Stories/taken/bugs uitsluitend in JIRA met idempotente, hervatbare upserts; één state-writer met .active-container-pointer.	API-gated	●●●●● 3	Eén actieve container/fase tegelijk
T7	Delegatie	12 subagents · isolation.ts	Deny-profielen per agent, afgedwongen op Read/Write/Grep/Bash; implementer werkt per taak in een eigen worktree.	hooks	●●●●● 4	Geen model-tiering of kostenbeleid
T8	Context & sessies	PHASE_CONTRACT · handoff-keys	Fasecontracten declareren inputs/outputs/isolatie; deterministische handoff-keys maken fasen hervatbaar en idempotent.	docs + scripts	●●●●● 3	Contracttemplate nog niet overal toegepast
T9	Toolroutering	.mcp.json-template	Eén MCP-server (JIRA via mcp-atlassian); scripts resolven via $CLAUDE_PLUGIN_ROOT zodat de plugin overal werkt.	docs-only	●●●●● 2	Geen inventaris of health-check van tools
T10	Secrets & auth	—	Geen systeem; alleen env-conventies in het MCP-template. Geen vault, geen beleid over wat agents mogen zien.	geen	●●●●● 1	Geen vault- of beleidslaag
T11	Machinediscipline	init-worktree.sh · sandbox-scripts	Worktree-bootstrap en sandbox status/cleanup-scripts bestaan; onboarding (WSL2, Bun, uv, Docker) is zwaar en handmatig.	scripts	●●●●● 2	Geen doctor-check op de installatie zelf
T12	Feedback & drift	/check · CHANGELOG · agnost. test	/check detecteert drift in doelrepo's (scenario's↔tests↔JIRA↔docs); voorbeeldige changelog-discipline; portabiliteit getest met mock-LLM.	docs + scripts	●●●●● 3	Geen geautomatiseerde bewaking van de plugin zelf

Volwassenheid: 1 = ad-hoc · 2 = opgeschreven, onafgedwongen · 3 = tooling bestaat, deels gebruikt · 4 = afgedwongen door automatisering · 5 = fleet-breed afgedwongen met drift-tests en zelfcorrectie. Geen enkel onderwerp haalt een 5 — daarvoor ontbreekt de bewakingslaag.

Handhaving in drie lagen — waarom dit ontwerp serieus is

Sterkste drie punten

Handhaving is echt (T4·T7): isolatiegrenzen zijn technische weigeringen in hooks, geen prompttekst die een agent kan negeren.
Eén eigenaar per artefact (T3·T6·T8): de faalmodus "een tool overschreef mijn document" is per ontwerp weggenomen; state heeft één writer.
Zelfkritische evolutie (T12): release 0.27 verwijdert een eigen skill met onderbouwde autopsie; het systeem test zijn eigen portabiliteit met een mock-LLM.

Zwakste drie punten

Nul CI (T5): correctheid hangt volledig op discipline in de sessie; zelfs de marketplace-catalogus bevat onopgemerkte encoderingsfouten en een los zip-bestand.
Seriële doorvoer (T6·T7): acht menselijke poorten en één actieve container maken de mens de vaste rem op elke wijziging.
Dunne operationele laag (T10·T11): geen secretsbeleid, geen installatie-verificatie, zware onboarding — en een bus-factor van één auteur.

Meest onderscheidende ontwerpkeuze — de build-from-spec probe. /probe laat een subagent die technisch verblind is voor zowel de broncode als de bestaande tests een component herbouwen uit uitsluitend zijn spec-slice, en rapporteert elke plek waar de spec hem tot gokken dwong. Spec-kwaliteit wordt hier dus gemeten in plaats van aangenomen — een discipline die in de meeste engineeringorganisaties, met of zonder agents, niet bestaat.

Waar de versnelling zit

De gemeten gaten liggen vrijwel allemaal in één categorie: de laag om de pipeline heen. Het poortontwerp is af; wat ontbreekt is de machinerie die poorten automatisch draait en meerdere sporen tegelijk toelaat. Elk gat hieronder is elders al eens volledig custom gebouwd en in productie bewezen — dit is bekende, overdraagbare techniek:

T5 — geen CI/CD Een op maat gebouwd build-and-ship-platform (recipe-gedreven CI, verplichte checks, auto-merge, deploy-verificatie, MCP-bediend) maakt /gate en de verificatiekant van /review een automatische vereiste in plaats van een sessie-handeling — doorlooptijd per merge zakt van "wanneer de sessie klaar is" naar minuten.

T6 — serieel werk Een coördinatielaag over MCP (gedeeld ticketbord waar agents lanes claimen, met deploy-signalen) laat meerdere containers en agents parallel lopen zonder dubbelwerk — de JIRA-fundering ligt er al.

T8/T12 — geen bewaking Context-capture plus drift-tests op de instructielaag zelf (regels als geteste artefacten) sluiten de loop die /check nu alleen voor doelrepo's draait — het systeem gaat dan ook zichzelf bewaken.

T7 — kosten & tempo Model-tiering en achtergrond-delegatie (zwaar model ontwerpt en reviewt, goedkopere modellen bouwen) verhogen parallelisme en verlagen kosten zonder één poort te verwijderen.

Belangrijk: geen van deze stappen vraagt om het versoepelen van het bestaande ontwerp. De autorisatiepoorten — de menselijke beslissingen — blijven exact waar ze zijn; alleen de verificatie en de doorvoer worden machinewerk.