De Geheime Tuin van de Ontwikkelaar: Hoe Ruimtelijke Ontologie LLM's Aligneert Zonder Prompt Engineering

Gepubliceerd op 30 April 2026

leestijd : 20 minutes

Prompt engineering is fragiel. Bij 80 000 tokens zijn uw uitlijningsregels ondergedompeld in het lawaai, en het LLM vergeet wat je het aan het begin van het gesprek hebt gevraagd. Mijn oplossing? Niet uitlijnen aan de hand van de tekst, maar aan de hand van deruimte. Ik heb mijn ontwikkelwerkruimte gestructureerd in vier concentrische cirkels van vertrouwen — van de intieme geheime tuin tot de publieke smeden — en elke cirkel is een fysiek gebied van het bestandssysteem. De LLM hoeft niet eraan herinnerd te worden wat de regels zijn: het bestandspad bevat ze. Dit is hoe het werkt, en waarom deze uitlijningsarchitectuur op basis van ruimte meer veerkrachtig is dan een`system prompt`van 500 regels.

Het is een lang artikel.
Zit comfortabel.

De constatering: Prompt Engineering is een zandkasteel.

Gedurende drie weken heb ik Gradle-plugins ontwikkeld met Opencode, gebruikmakend van drie verschillende LLMs — Kimi K2.6, GLM-5.1 en DeepSeek-V4-Pro (de enige overlevende, maar dat is een ander verhaalAl behandeld hier.) Mijn agent-governancemethodeIk heb dit uitgebreid gedocumenteerd in een vorig artikel. is gebaseerd op AsciiDoc-bestanden —AGENT.adoc, INDEX.adoc, PROMPT_REPRISE.adoc— die ~30 000 tokens aan regels, backlog en geschiedenis laden bij het begin van elke sessie.

En ondanks deze documentaire infrastructuur zijn twee dingen mij opgevallen:

  1. De LLM vergeet. Zelfs met de absolute regels in gedachten in elk EAGER-bestand, boven de 60.000 cumulatieve tokens (begincontext + gesprek), Kimi K2.6 is begonnen met voorstellen van`Write`overweldigend op configuratiebestanden. GLM-5.1 heeft een Firebase-token verward met een te vervangen placeholder. De regels waren geschreven — de LLM zag ze niet meer.

  2. De governance zelf wordt een probleem. Na het implementeren van het Hot/Warm/ColdArticle sur la rotation de backup. om de contextexplosie te voorkomen, mijn EAGER-bestanden wogen nog steeds 1414 regelsJ’ai documenté cet audit ici.. De governance — ontworpen om de LLM te beschermen tegen verzadiging — verzadigde de LLM.

Ik had een uitlijningsmechanisme nodig dat niet afhankelijk is van het aantal tokens in de prompt.

Het antwoord: stop met uitlijnen op basis van de tekst, en beginnen met uitlijnen op basis van deruimte.

De Vier Cirkels van Vertrouwen : een Ruimtelijke Ontologie

Mijn dossier`workspace/(in~/workspace/`) is geen Git-repository. Het is de root van al mijn werk — code, documentatie, training, infrastructuur. En het is gestructureerd in vier zones die geen opbergconventies zijn, maarconcentrische vertrouwenskringenPlease provide the text you would like me to translate.

Niveau

etiket

Fysieke zone

CVS

Zichtbaarheid

0

Geheime tuin

`workspace/`wortel

geen

Intiem — vrij denken, geen commit, geen publicatie

1

kluis

configuration/

Git privé (solo)

Secrets, tokens, archief van visie. Één persoon.

2

Bibliotheek

office/

Privé Git (uitgebreid)

Pedagogische data, SPG/SPD, JSON-schema’s. Vertrouwenscirkel geïdentificeerd.

4

Openbare smidsen

foundry/

Git openbaar (Apache 2.0)

Broncode, plugins, tests, technische documentatie.

LET OP: Er is geen niveau 3 in de tabel. Niveau 3 is een tijdelijk niveau: dit is inhoud van`office/`die is geanonimiseerd en klaar is om als open data te worden gepubliceerd. Het heeft geen fysiek eigen gebied — het is een staat van de data, geen locatie.

Elk niveau beantwoordt een specifieke vraag:

  • Waar kun je een idee plaatsen dat nog niet klaar is om te delen, zelfs niet met een kleine kring? → De geheime tuin. Geen Git. Geen druk.

  • Waar een API-token bewaren zonder dat het lekt ? → De kluis (configuration/). Fysiek geïsoleerd. Geen ander depot kan per ongeluk naar het verwijzen.

  • Waar samen een opleidingscatalogus opstellen met een pilot-OF? → De bibliotheek`office/`Versiebeheerd, samenwerkend, maar privé.

  • Waar industrialiseer je een open source Gradle-plugin ? → Les forges`foundry/`). Public, forkable, getest in CI.

Deze ontologie isverbruikbaar door een LLM. Wanneer hij een bestand inleest in`foundry/plantuml-gradle/src/`, hij weet impliciet: "ik ben in cirkel 4 — openbare code, verplichte tests, geen geheimen, geen onderwijsgegevens". Hij heeft geen prompt nodig die hem dit herinnert.

De Geheime Tuin: de ruimte buiten CVS

Het is het belangrijkste concept — en het meest tegenintuïtige.

De wortel`workspace/heeft geen.git/. De documenten die daar leven (`WORKSPACE_VISION.adoc, WORKSPACE_AS_PRODUCT.adoc, WORKSPACE_ORGANIZATION.adoc— en degene die je nu leest, die hieruit voortkomt, zijn niet bedoeld om versiebeheerd te worden, gedeeld te worden, of zelfs opnieuw gelezen te worden door iemand anders dan ik. Dit zijnontkiemende gedachten.

Het geheime tuin is out-of-CVS van nature. Het ontbreken van versiebeheer is de voorwaarde voor de vrijheid van denken. Men schrijft daar niet om gelezen te worden — men schrijft daar om zijn eigen visie te verduidelijken.

Maar deze vrijheid heeft een prijs: een`rm`onvoorziene, en het zijn maanden strategische reflectie die verdwijnen. De oplossing is niet om de tuin te versioneren (dat zou het vernietigen) — het is om hetspiegelenin de meest beperkte kring.

Het .gitignore als configuratie van bestuur

wortel van`workspace/, een bestand.gitignore`minimal verklaart dehistoriseringsbeleidbestanden van de geheime tuin:

.goosehints
.goose

Ce .gitignore`heeft geen klassieke Git-functie (er is geen.git/`aan de wortel). Hij fungeert als eenconfiguratiebestand van governancedie antwoord geeft op een precieze vraag: welke artefacten van de geheime tuin verdienen het om gehistoriseerd te worden, en welke zijn puur tijdelijk?

  • De bestanden vermeld in`.gitignore`—.goosehints, .goose— zijn tijdelijke artefacten die door de agents zijn gegenereerd. Geen strategische waarde. Geen historisering.

  • De bestanden`.adoc`van de wortel —WORKSPACE_VISION.adoc, WORKSPACE_ORGANIZATION.adoc, WORKSPACE_AS_PRODUCT.adoc, WHAT_THE_GAMES_BEEN_MISSING.adoc, depots_implementes_strategie.adoc, synthese-LLMs-long-contexte.adoc— zijn nietnietin de`.gitignore`. Dit zijn de artefacten die historiseerd moeten worden.

Le `.gitignore`is degovernanceschema: alles wat er niet in vermeld staat, is een kandidaat voor een snapshot. En het LLM, door dit bestand te lezen, weet exact wat er moet worden gearchiveerd en wat kan worden genegeerd — zonder dat we het daarin een prompt hoeven te geven.

Het snapshot-mechanisme

Ik heb gecreëerd`configuration/vision-archive/gedateerde snapshots van alle.adoc`van de wortel, gecommitteerd in de privé repository`configuration/`. Elke brainstormsessie produceert een snapshot :

DATE=$(date +%Y-%m-%d)
mkdir -p /home/cheroliv/workspace/configuration/vision-archive/$DATE
cp /home/cheroliv/workspace/*.adoc /home/cheroliv/workspace/configuration/vision-archive/$DATE/
cd /home/cheroliv/workspace/configuration && git add vision-archive/ && \
  git commit -m "vision-archive: snapshot $DATE"

De procedure wordt geactiveerd aan het einde van de sessie door het LLM zelf, die deze globale routingtaak uitvoert. Elke snapshot legt de volledige staat van de strategische gedachte vast op een moment T.

De Git-geschiedenis van`configuration/`wordt debiografie van mijn strategisch denken. Ik kan een`git log — vision-archive/`en zie de ontwikkeling van mijn visie, sessie per sessie, datum per datum.

Voorbeeld van de werkelijke geschiedenis na een werkdag :

$ git -C configuration log --oneline -- vision-archive/
1089d1b vision-archive: fin de session finale 2026-05-03
6b21eaf vision-archive: fin de session 2026-05-03-1300
1690f82 vision-archive: post-article 2026-05-03
28e6593 vision-archive: post-migration 2026-05-03
3707b78 vision-archive: snapshot 2026-05-03 — jardin secret initial

Vijf snapshots in één dag. Elk is een herstelpunt. Elk is een mijlpaal in de genese van de strategie.

Het dossier`configuration/vision-archive/latest/`bevat altijd eenwerkkopievan de laatste snapshot, dienend als snelle referentie zonder dat je hoeft te navigeren in de Git-geschiedenis

En voor de LLM, is het eenoracle van coherentie: Als hij een tegenstrijdigheid observeert tussen de huidige implementatie en de opgeslagen visie van een eerdere datum, kan hij dit melden.

De kluis : configuration/ zoals Spring Cloud Config

`configuration/`Het bevat niet alleen het archief van de visie. De primaire — en toekomstige — functie ervan is om eenSpring Cloud Config server. Alle geheimen, tokens, credentials en infrastructuurdescriptoren zijn hier, in een privé Git-opslagplaats toegankelijk voor alleen de eigenaar.

Waarom een aparte repository in plaats van een bestand`.env`in elk project?

  • Onbedoelde push van een geheim: onmogelijk. De geheimen bevinden zich in een privérepository waar publieke projecten niet per ongeluk naar kunnen verwijzen.

  • Audit : de Git-geschiedenis geeft het spoor van elke configuratiewijziging. Wie wat gewijzigd heeft, wanneer, met welke SHA-hash.

  • Rollback :`git revert`op een defecte configuratie. Snapshot, zonder handmatige backup.

De Bibliotheek : office/ als verbruikbare data

`office/`is de documentaire tegenhanger van het ontwikkelingswerk. Het bevat de blogartikelen, de technische specificaties, de trainingsmaterialen (38 cursusmappen FPA, SPG/SPD, JSON‑schema’s, Bloom/Harrow/Krathwohl‑taxonomieën) — alles wat het vormtlesmateriaal.

Maar`office/`Het is niet alleen een docs-lade. Het is eenbron van gestructureerde datadat de Gradle-plugins van`foundry/`Ze consumeren. Een blogartikel in`office/`is een invoer die een plugin zal omzetten naar HTML. Een SPG AsciiDoc in`office/metiers/FPA/`is een artefact dat een orchestrator zal parseren om slides, quizzen en videocapsules te genereren.

Et le `build.gradle.kts`aan de wortel van`office/`het is geen zakelijke code — het is eenscript voor het verbruik van het pluginecosysteem. Hij zegt: "hier zijn de Gradle-plugins die ik gebruik, hier is de context van mijn werkruimte".

De smeden: foundry/ als Implementatie

foundry/`bevat hetgeïndustrialiseerde code. 54 Git-repositories, waarvan 7 momenteel bestuurd door.agents/`. Dit is waar de visie uitvoerbaar wordt — Gradle-plugins, CI/CD, JUnit5- en Cucumber-tests.

De relatie met`office/`is bidirectioneel :

  • office/→foundry/: de pedagogische gegevens zijn de grondstof die de plugins verbruiken.

  • foundry/→office/: de plugins produceren data die verrijkt`office/` — le `graph.json`de graphify-gradle, de gecompileerde slider decks, de buildrapporten.

Pro/Contra : Ruimtelijke uitlijning vs Prompt-uitlijning

Laten we de twee benaderingen vergelijken.

Klassieke benadering: Alineering via Pre-Prompt

✅ Pro

❌ tegen

Eenvoudig te implementeren. Een tekstblok in de systeemprompt.

Fragiel voor lange context : de regel wordt verzopen na 80K tokens.

Werkt voor algemene regels (toon, formaat).

Niet verifieerbaar : niets weerhoudt het LLM ervan de regel te overtreden.

Geen noodzaak om de architectuur van het project te herzien.

Niet overdraagbaar : elke repo herdefinieert de regels.

Zuiver declaratief : het LLM weet dat het zou moeten, maar er is niets dat het tegenhoudt.

Deze Aanpak: Alignering via Ruimtelijke Ontologie

✅ Pro

❌ tegen

Bestand tegen lange context: de regel staat in het bestandspad, niet in een verre prompt.

Initieel infrastructuurkosten : het werkruimte in cirkels structureren neemt tijd.

Mechanisch controleerbaar : een geheim in`foundry/is detecteerbaar door`git check-ignore.

Vereist discipline : een nieuwe bijdrager moet de cirkels begrijpen.

overdraagbaar : een`AGENT.adoc`De norm stelt de cirkels bloot aan elk nieuw project.

Bestrijkt alleen de ruimtelijke beperkingen — de code-stijl blijft in de prompt.

Beveiliging bij het ontwerp : een`git push`sinds`foundry/kan niet tentoonstellen`configuration/.

Verbruikbaar door niet-LLM agents : Een Gradle-orchestrator kan routeren volgens de cirkel.

Het belangrijkste voordeel is niet defensief (veiligheid, zichtbaarheid) — het iscreatief. Wanneer het LLM werkt in een ruimte die is gestructureerd door een ontologie, kan het doen wat geen prompt het toestaat: observeren van de delta

De relationele algebra van Workspace en de Delta Observable

Wanneer de LLM loopt`foundry/, hij heeft eenrooster van gestructureerde gegevens: knooppunten (plugins, bestanden, tests, afhankelijkheden), getypeerde randen (`import, depends_on, generates, tests), relaties van compositie en van orde (`training-gradle`haal de repository op →`slider-gradle`genereert de slides →`capsule-gradle`bewerk de video).

Deze algebra wordt nergens in het duidelijke geschreven — maar het is waarneembaar. Elk`build.gradle.kts`exposeert afhankelijkheden. Elke`INDEX.adoc`geeft kruisverwijzingen.

De LLM observeert deze algebra en detecteert hetdelta: het verschil tussen wat het systeem al kan produceren en wat de visie beschrijft.

Vanaf dit delta kan hij definiërencartografieën van vakexperten— CDA (Ontwerper-ontwikkelaar van applicaties, Kotlin/Gradle/JHipster) en FPA (Professioneel trainer voor volwassenen, Pedagogie/Qualiopi/Bloom) — en identificeer wat ontbreekt voor elke expert.

Expert CDA (Kotlin/Gradle/JHipster)
  ├── Plugins : jhipster-gradle-plugins, plantuml-gradle,
  │   codebase-gradle
  ├── Delta : pas encore de SPG CDA formalisé,
  │   pas de fine-tuning expert CDA

Expert FPA (Pédagogie/Qualiopi/Bloom)
  ├── Plugins : training-gradle, slider-gradle,
  │   school-backoffice/forms, capsule-gradle
  ├── Matériel : 38 modules cours, SPG/SPD, taxonomies
  └── Delta : parser AsciiDoc→JSON à créer,
      orchestrateur à coder

De LLM hoeft niet te weten wat hij moet doen. De delta ontstaat uit de structuur.

De samengestelde contextvector: RAG + pgvector + Graphify

Relationele algebra is geen theoretische constructie. Ze is materiaal gemaakt door drie componenten die eensamengestelde contextvectorvoor de LLM.

Component 1 — RAG LangChain4j + PostgreSQL pgvector

Ik heb LangChain4j al in productie in twee plugins :`slider-gradle`(4 LLM-providers) en`plantuml-gradle`(7 providers). De ONNX-embeddings (AllMiniLmL6V2) indexeren de gegevens van`office/`en de broncode van`foundry/`in PostgreSQL + pgvector.

Deze RAG werkt op twee dimensies:

  • Dimension data : de documenten`office/`(SPG, artikelen, opleidingen, JSON-schema’s)

  • Dimension code : de codebases`foundry/`(bronnen Kotlin, tests Cucumber, AGENT.adoc)

De doorsnede omvat zowel het wat (het bedrijfsdomein) als het hoe (de implementatie).

Onderdeel 2 — Knowledge Graph Graphify

Graphify is geïntegreerd in`plantuml-gradle`(109 tests, 380/380 PASS) en produceert een`graph.json`— een gestructureerde kennisgrafiek met knooppunten, randen en automatisch gedetecteerde gemeenschappen.

In tegenstelling tot RAG dat werkt op basis van vectoriële similariteit (onduidelijk), werkt de knowledge graph op basis vanexacte relaties(deterministisch) :`graphify query`voor de semantische vragen (~50 tokens)`graphify path`om te navigeren,`graphify explain`om uit te leggen

Component 3 — Incremental Graphify: Sparse, Aggregateerbaar, Consumabel

Dit is de cruciale architecturale beslissing.

Graphify moet niet in een enkele repository leven. Het moet op een manier leven.verspreidin elk plugin :

  1. Elke plugin bevat een Gradle-taak`updateKnowledgeGraph`die Graphify roeptop zijn eigen scopeen produceert een`graph.json`lokaal.

  2. Het build script van`office/ verbruikt`graphify-gradle`met`rootDir = /home/cheroliv/workspace`en produceert een`graph.json globaaldie de lokale grafieken samenvoegt.

  3. De RAG van elke plugin injecteert het`graph.json`globaal alscontextfiltervoor de LLM-aanvragen.

TÂCHE GRADLE (dans chaque plugin)
    ↓
graphify → graph.json (scope local)
    ↓
office/build.gradle.kts → graph.json (scope global)
    ↓
RAG pgvector (dans slider, plantuml, codebase...)
    ↓  ← injection du graph.json comme filtre
LLM (deepseek-v4-pro)
    ↓  ← observation algèbre relationnelle
    ↓  ← détection delta vs cartographies experts
PRIORISATION → prochaine tâche

Resultaat: de LLM zoekt niet in het lege — hij navigeert in een ruimte die is gestructureerd door de knowledge graph. Een query over "génère un diagramme" weet de relevante knooppunten van de graaf te bereiken.

Automatische GDPR-classificatie: de LLM als router

De ruimtelijke ontologie gaat niet alleen over het uitlijnen van de LLM — het geeft het eenclassificatiegrid RGPDom elke gegevens naar de legitieme zone te routeren.

criterium

LLM-detectie

Actie

Maximum niveau

Persoonlijke gegevens (naam, e‑mail, IP)

Patroon`@`, IP, eigennamen

Anonimiseren →`[OF_PILOTE]`of router niveau 2

2

Token / Geheim / Referentie

patroon`sk-…​, `ghp_…​, ya29…​

Router →configuration/. Verwijzen door`${VAR}`in de code.

1

interne URL

Bevat`localhost`, privé IP

anoniem maken →${API_URL}

2

Pedagogische gegevens (SPG, cursus)

Structuur Bloom/Qualiopi

Router →office/(niveau 2). Dubbele versie bij export.

3

broncode / test

Uitbreiding`.kt`, .kts`in`foundry/

Router →foundry/. Controleer afwezigheid van geheimen.

4

Aan het einde van de sessie voert de LLM eenglobale taakLe texte suivant est une traduction de l’original.

  1. Lezing van`.gitignore`wortel om de tijdelijke artefacten (uit te sluiten van de snapshot) versus de strategische artefacten (te historiseren)

  2. Inventaris van alle bestanden`.adoc`van de wortel`workspace/`

  3. Filteren: uitsluiting van de in de lijst vermelde bestanden`.gitignore`, inclusie van alle anderen

  4. Kopieer in`configuration/vision-archive/$DATE/en bijwerken van de symlink`latest/

  5. Commit in de repository`configuration/`met een gestructureerd bericht

  6. Automatische AVG-classificatie van elk gewijzigd bestand (alle cirkels)

  7. Routing : data`office/→ privé commit, code`foundry/→./gradlew check, configuratie → commit

  8. Gestructureerd rapport met AVG-waarschuwingen en archiefbevestiging

Le `.gitignore`De hoofddirectory is geen Git-configuratiebestand — het is eengovernancebestand van historisering. Het definieert het schema dat het LLM consumeert om te beslissen welke bestanden van de geheime tuin in de strategische biografie terechtkomen en welke weggooibaar zijn.

De LLM is niet langer een eenvoudige tekstgenerator. Het is deinformatiebeheerdervan het ecosysteem — producent, classificator, router

Roadmap: van AsciiDoc naar LangGraph4j

Vandaag is deze gouvernance deterministisch : de LLM past een procedure toe die beschreven staat in AsciiDoc-bestanden. Dit is defase 1— de prompt engineering met LLM-geheugen.

La fase 2zal elke stap van de procedure in eengetypte Gradle-taak:

./gradlew endSessionWorkspace    → snapshot vision-archive
./gradlew endSessionProject      → archive .agents/
./gradlew endSessionReport       → rapport multi-zones

La fase 3zal het proces van het beëindigen van de sessie modelleren als eentoestandsdiagrammethttps://github.com/langgraph4j/langgraph4j[LangGraph4j]Please provide the text you would like me to translate.

[Start] → [Inventaire fichiers modifiés]
       → [Classification RGPD] (nœud ONNX)
       → [Branchement par cercle]
            ├→ cercle 0 → snapshot → commit
            ├→ cercle 2 → anonymisation → commit
            ├→ cercle 4 → archive → commit
            └→ cercle 1 → commit configuration/
       → [Rapport] → [End]

Deze graaf wordt versiebeheerd in de CI/CD, uitgevoerd door Gradle, geconfigureerd via de GitHub Secrets van de plugins. Het LLM hoeft niet langer te beslissen over de routering — de graaf zal dat doen.

wat deze architectuur oplost (en wat ze niet oplost)

De ruimtelijke ontologie dekt niet alles. Code-stijlconventies, naamgeving, architecturale ontwerpkeuzes — dit alles blijft in de prompt. Wat de ruimtelijke ontologie oplost, islaag van beveiliging en zichtbaarheid: waar elke byte moet leven, en wie het kan zien.

Dit is wat ze concreet toevoegt:

  1. Geen`git push`toevallig van een geheim : de geheimen zitten in`configuration/(cirkel 1). De openbare projecten zijn in`foundry/(cirkel 4). Geen pad kruist beide.

  2. Geen bedrijfscode in de data :`office/bevat enkele.adoc`, YAML, JSON-schema’s — maar geen`.kt`. Le `build.gradle.kts`die daar leeft is een consumptiescript, geen bedrijfscode.

  3. Geen strategisch denken blootgesteld : de visiedocumenten bevinden zich in de geheime tuin (wortel buiten CVS). De snapshots zijn in`configuration/`(privé kluis). Niemand, zelfs niet in een uitgebreide cirkel van vertrouwen, leest de oorsprong van de strategie.

  4. Auto-prioritering : de LLM observeert het delta tussen de relationele algebra (wat bestaat) en de expertenkaarten (wat nodig is). De volgende ontwikkelstaak ontstaat uit dit delta.

Conclusie: de architectuur als discours

Ik zet geen politiek manifest in de footer van mijn site. Ik zet geen ethische regels in mijn prompts. De afstemming staat niet in de tekst — hij is in debestandssysteem.

Als een LLM in deze ruimte werkt, kan het geen geheim lekken (het pad verhindert het). Het kan geen onderwijsgegevens verwarren met broncode (het fysieke gebied is anders). Het kan geen veiligheidsregel van 80 000 tokens vergeten — omdat de regel niet in de prompt staat, maar het is in de`workspace/→`configuration/→office/→`foundry/`dat elke bestandsleesactie reactief is.

Dit is het principe van secure by design toegepast op agentalignement: vraag het LLM niet om de regels te onthouden. Zorg ervoor dat de architectuur ervoor zorgt dat een fout structureel onmogelijk is.

Terzijde, geeft het de LLM wat geen prompt kan geven: het vermogen omwaarnemenwaar het is, wat bestaat, wat ontbreekt — en daaruit afleiden wat het moet doen.

Referenties

Gerelateerde artikelen

HyperFrames-Gradle : AsciiDoc omzetten naar een MP4-video
31 May 2026
Audit van mijn LLM‑consumptie : SQLite, OpenCode, Ollama Cloud, en waarom mijn pro‑abonnement de wereldwijde markt opschudt
18 May 2026
De architectuur « Onafhankelijke plugin + consumentenroot »: Waarom worden mijn Gradle-builds geduplicerd?
14 May 2026
De Knowledge Graph als aanbevelingsmotor : hoe ik de chronologische gerelateerde artikelen heb doodgemaakt
12 May 2026