reading time : 20 minutes

Prompt engineering is fragile. At 80,000 tokens, your alignment rules are drowned in the noise, and the LLM forgets what you asked it at the beginning of the conversation. My solution? Don’t align by text, but by l'space. I have structured my development workspace into four concentric circles of trust — from the intimate secret garden to the public forges — and each circle is a physical area of the file system. The LLM does not need to be reminded of the rules: the file path contains them. Here’s how it works, and why this spatial alignment architecture is more resilient than a`system prompt`of 500 lines.

It’s a long article.
Get comfortable

tick

[]

The Observation: Prompt Engineering is a Sand Castle

For three weeks, I developed Gradle plugins with Opencode, using three different LLMs — Kimi K2.6, GLM-5.1, and DeepSeek-V4-Pro (the sole survivor, but that’s another storyAlready covered here.) My agent governance methodI documented it in detail in a previous article. is based on AsciiDoc files —AGENT.adoc, INDEX.adoc, PROMPT_REPRISE.adoc— which load ~30 000 tokens of rules, backlog, and history at the start of each session.

And despite this documentary infrastructure, two things struck me:

  1. The LLM forgets. Even with the absolute rules at the head of each EAGER file, beyond 60,000 cumulative tokens (initial context + conversation), Kimi K2.6 has begun to propose des`Write`overwhelming on configuration files. GLM-5.1 confused a Firebase token with a placeholder to replace. The rules were written — the LLM no longer saw them.

  2. Governance itself becomes a problem. After implementing the Hot/Warm/Cold mechanismArticle on backup rotation. to avoid context explosion, my EAGER files still weighed 1414 linesI documented this audit here. Governance — designed to protect the LLM from saturation — was saturating the LLM.

I needed an alignment mechanism that did not depend on the number of tokens in the prompt.

The answer: stop aligning by text, and start aligning by thespace.

The Four Circles of Trust: A Spatial Ontology

My file`workspace/(in~/workspace/`) is not a Git repository. It is the root of all my work — code, documentation, training, infrastructure. And it is structured into four zones that are not storage conventions, butconcentric circles of trust:

Level

Label

Physical zone

CVS

Visibility

0

Secret garden

`workspace/`root

None

Intimate — free thought, no commit, no publication

1

Safe

configuration/

Private Git (solo)

Secrets, tokens, vision archive. One person.

2

Library

office/

Private Git (expanded)

Pedagogical data, SPG/SPD, JSON schemas. Trust circle identified.

4

Forges (public)

foundry/

Public Git (Apache 2.0)

Source code, plugins, tests, technical documentation.

There is no level 3 in the table. Level 3 is a transitional level: it’s content of`office/`who has been anonymized and is ready to be published as open data. It does not have its own physical zone — it’s a state of the data, not a location.

Each level answers a specific question:

  • Where to deposit an idea that is not yet ready to be shared, even with a small circle? → The secret garden. No Git. No pressure.

  • Where to store an API token so it doesn’t leak? → The safe`configuration/`). Physically isolated. No other repository can mistakenly reference it.

  • Where to co-build a training catalogue with a pilot OF? → The library (office/). Versioned, collaborative, but private.

  • Where to industrialize an open-source Gradle plugin? → Forges`foundry/`). Public, forkable, tested in CI.

This ontology isconsumable by an LLM. When he reads a file in`foundry/plantuml-gradle/src/`, he implicitly knows: "I am in circle 4 — public code, mandatory tests, no secrets, no educational data". He does not need a prompt reminding him of that.

The Secret Garden: The Space Outside CVS

This is the most important concept — and the most counterintuitive.

The root`workspace/does not have.git/. The documents that live there (`WORKSPACE_VISION.adoc, WORKSPACE_AS_PRODUCT.adoc, WORKSPACE_ORGANIZATION.adoc— and the one you are reading right now, which stems from it) are not intended to be versioned, shared, or even reread by anyone other than me. These aregerminating thoughts.

The secret garden is out-of-CVS by nature. The lack of versioning is the condition of freedom of thought. One does not write there to be read — one writes there to clarify one’s own vision.

But this freedom has a cost: a`rm`accidentally, and it’s months of strategic thinking that disappear. The solution is not to version the garden (that would destroy it) — it’s tomirrorin the smallest circle.

The .gitignore as Configuration of Governance

At the root of`workspace/, a file.gitignore`minimal declares thehistorization policysome files of the secret garden:

.goosehints
.goose

Ce .gitignore`does not have a classic Git function (there is no.git/`at the root). It acts as agovernance configuration filethat answers a specific question: which artifacts of the secret garden deserve to be historicized, and which are purely transient?

  • The files listed in`.gitignore`—.goosehints, .goose— are ephemeral artifacts generated by the agents. No strategic value. No archiving.

  • The files`.adoc`of the root —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— are notnotin the`.gitignore`. They are the artifacts to be historicized.

Le `.gitignore`is thegovernance framework: everything not listed there is a candidate for the snapshot. And the LLM, by reading this file, knows exactly what should be archived and what can be ignored — without needing to be reminded in a prompt.

The Snapshot Mechanism

I have created`configuration/vision-archive/: dated snapshots of all the.adoc`from the root, committed in the private repository`configuration/`. Each brainstorming session produces a 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"

The procedure is triggered at the end of the session by the LLM itself, which executes this overall routing task. Each snapshot captures the full state of strategic thinking at a given moment T.

The Git history of`configuration/`becomes thebiography of my strategic thought. I can do a`git log — vision-archive/`and see the evolution of my vision, session by session, date by date.

Real example of history after a workday:

$ 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

Five snapshots in one day. Each is a restore point. Each is a milestone in the genesis of the strategy.

The dossier`configuration/vision-archive/latest/`contains permanently aworking copyof the latest snapshot, serving as a quick reference without having to navigate the Git history.

And for the LLM, it’s aoracle of coherencewhen he observes a contradiction between the current implementation and the archived vision at an earlier date, he can report it.

The Vault: configuration/ as Spring Cloud Config

`configuration/`It does not contain only the archive of vision. Its primary — and future — function is to be aserver Spring Cloud Config. All secrets, tokens, credentials, and infrastructure descriptors live here, in a private Git repository accessible only to the owner.

Why a separate repository rather than a file`.env`in each project?

  • Accidental push of a secret: impossible. Secrets are in a private repository that public projects cannot mistakenly reference.

  • Audit: Git history provides the trail of every configuration change. Who changed what, when, with which SHA hash.

  • Rollback:`git revert`on a broken configuration. Snapshot, without manual backup.

The Library : office/ as Consumable Data

`office/`is the documentary counterpart of the development work. It contains the blog posts, the technical specifications, the training materials (38 course directories FPA, SPG/SPD, JSON schemas, Bloom/Harrow/Krathwohl taxonomies) — everything that constitutes thepedagogical material.

But`office/`is not just a docs drawer. It’s astructured data sourcethat the Gradle plugins of`foundry/`They consume. A blog post in`office/`is an entry that a plugin will convert to HTML. An SPG AsciiDoc in`office/metiers/FPA/`is an artifact that an orchestrator will parse to generate slides, quizzes, and video capsules.

Et le `build.gradle.kts`at the root of`office/`is not business code — it’s aplugin ecosystem consumption script. He says: "here are the Gradle plugins I use, here is the context of my workspace

The Forges: foundry/ as Implementation

foundry/`contains theindustrialized code. 54 Git repositories, of which 7 are currently governed by.agents/`. This is where the vision becomes executable — Gradle plugins, CI/CD, JUnit5 + Cucumber tests.

The relationship with`office/`is bidirectional:

  • office/→`foundry/`Pedagogical data are the raw material that plugins consume.

  • foundry/→office/: the plugins produce data that enriches`office/` — le `graph.json`of graphify-gradle, compiled slider decks, build reports

Pro/Contra: Spatial Alignment vs Prompt Alignment

Let’s compare the two approaches.

Classic Approach: Alignment via Pre-Prompt

(Note: Since no actual French text was provided for translation—only the instruction text in English—there is nothing to translate. Per strict adherence to the output requirements, only the translated content should be emitted, which in this case is an empty string.)

❌ against

Simple to implement. A block of text in the system prompt.

Fragile to long context : the rule is drowned after 80K tokens.

Works for general rules (tone, format).

Unverifiable : nothing prevents the LLM from violating the rule.

No need to rethink the project’s architecture.

Non-transferable : each repo redeclares the rules.

Purely declarative: the LLM knows it should, but nothing stops it.

This Approach: Alignment via Spatial Ontology

�✅ Pro

against

Resilient to long context: the rule is in the file path, not in a distant prompt.

Initial infrastructure cost: structuring the workspace into circles takes time.

Mechanically verifiable : a secret in`foundry/is detectable by`git check-ignore.

Requires discipline : a new contributor must understand the circles.

Transferable: a`AGENT.adoc`standard exposes the circles to any new project.

Covers only spatial constraints — the code style remains in the prompt.

Security by design : a`git push`since`foundry/cannot expose`configuration/.

Consumable by non-LLM agents : a Gradle orchestrator can route according to the circle.

The main gain is not defensive (security, visibility) — it iscreative. When the LLM works in a space structured by an ontology, it can do what no prompt allows it: observe the delta.

The Relational Algebra of the Workspace and the Observable Delta

When the LLM traverses`foundry/, it has astructured data lattice: nodes (plugins, files, tests, dependencies), typed edges (`import, depends_on, generates, tests), composition and order relations (`training-gradle`extracts the repository`slider-gradle`generates the slides →`capsule-gradle`edit the video)

This algebra is not written anywhere in plain — but it is observable. Each`build.gradle.kts`exposes dependencies. Each`INDEX.adoc`exposes cross-references.

The LLM observes this algebra and detects thedeltaThe gap between what the system already knows how to produce and what the vision describes.

From this delta, it can define somebusiness expert mappings— CDA (Application Designer/Developer, Kotlin/Gradle/JHipster) and FPA (Professional Adult Trainer, Pedagogy/Qualiopi/Bloom) — and identify what is missing for each 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

The LLM doesn’t need to be told what to do. The delta emerges from the structure.

The Composite Context Vector: RAG + pgvector + Graphify

Relational algebra is not a theoretical construct. It is materialized by three components that form acomposite context vectorfor the LLM.

Component 1 — LangChain4j RAG + PostgreSQL pgvector

I already have LangChain4j in production in two plugins :`slider-gradle`(4 providers LLM) and`plantuml-gradle`(7 providers). The ONNX embeddings (AllMiniLmL6V2) index the data of`office/`and the source code of`foundry/`in PostgreSQL + pgvector.

This RAG operates on two dimensions:

  • Dimension data: the documents`office/`(SPG, articles, formations, JSON schemas)

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

The intersection covers both the what (the business domain) and the how (the implementation).

Component 2 — Knowledge Graph Graphify

Graphify is integrated into`plantuml-gradle`(109 tests, 380/380 PASS) and produces a`graph.json`— a structured knowledge graph with nodes, edges, and automatically detected communities.

Unlike RAG which operates by vector similarity (fuzzy), the knowledge graph operates byexact relations(deterministic)`graphify query`for the semantic questions (~50 tokens),`graphify path`to navigate,`graphify explain`to explain.

Component 3 — Incremental Graphify : Sparse, Aggregable, Consumable

This is the key architectural decision.

Graphify must not live in a single repository. It must live in a mannerscatteredin each plugin:

  1. Each plugin bundles a Gradle task`updateKnowledgeGraph`who calls Graphifyon its own scopeand produces a`graph.json`local.

  2. The build script of`office/ consumes`graphify-gradle`with`rootDir = /home/cheroliv/workspace`and produces a`graph.json globalthat aggregates the local graphs.

  3. The RAG of each plugin injects the`graph.json`global ascontext filterfor the LLM requests.

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

Result: the LLM is not searching in a void — it is navigating a space structured by the knowledge graph. A query on "génère un diagramme" knows how to reach the relevant nodes of the graph.

Automatic GDPR Classification: the LLM as Router

The spatial ontology does not merely align the LLM — it gives it aGDPR classification gridto route each data item to its legitimate zone

Criterion

LLM detection

Action

Maximum level

Personal data (name, email, IP)

Pattern`@`, IP, proper nouns

Anonymize →`[OF_PILOTE]`or level 2 router

2

Token / Secret / Credential

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

Router →configuration/. Reference by`${VAR}`in the code.

1

internal URL

Contains`localhost`, private IP

Anonymize →${API_URL}

2

Pedagogical data (SPG, course)

Structure Bloom/Qualiopi

Router →office/(level 2). Double version if export.

3

Source code / test

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

Router →foundry/. Check for absence of secrets.

4

At the end of the session, the LLM executes aglobal task:

  1. Reading of`.gitignore`root to identify ephemeral artifacts (to exclude from the snapshot) vs strategic artifacts (to be historicized)

  2. Inventory of all files`.adoc`of the root`workspace/`

  3. Filtering: exclusion of files listed in`.gitignore`, inclusion of all the others

  4. Copy in`configuration/vision-archive/$DATE/and update of the symlink`latest/

  5. Commit in the repository`configuration/`with a structured message

  6. Automatic GDPR classification of each modified file (all circles)

  7. Routing: data`office/→ private commit, code`foundry/→./gradlew check, configuration → commit

  8. Structured report with GDPR alerts and archiving confirmation

Le `.gitignore`root is not a Git configuration file — it’s ahistorization governance file. It defines the schema that the LLM consumes to decide which files from the secret garden go into the strategic biography and which are disposable.

The LLM is no longer just a text generator. It is theinformation managerof the ecosystem — producer, classifier, router.

Roadmap: from AsciiDoc to LangGraph4j

Today, this governance is deterministic: the LLM applies a procedure described in AsciiDoc files. It is thephase 1— prompt engineering with LLM memory.

La phase 2will extract each step of the procedure into atyped Gradle task:

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

La phase 3will model the end-of-session process as astate graphwithhttps://github.com/langgraph4j/langgraph4j[LangGraph4j]:

[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]

This graph will be versioned in CI/CD, executed by Gradle, configured via the GitHub Secrets of the plugins. The LLM will no longer have to decide on routing — the graph will do it.

What This Architecture Solves (and what it does not Solve)

The spatial ontology does not cover everything. Code style conventions, naming, architectural design choices—all of that remains in the prompt. What the spatial ontology solves is thesecurity and visibility layer: where each byte must live, and who can see it.

Here is what it concretely brings:

  1. No`git push`accidental of a secret: the secrets are in`configuration/(circle 1). Public projects are in`foundry/(circle 4). No path crosses both.

  2. No business code in the data :`office/contains some.adoc`, some YAML, JSON schemas — but no`.kt`. Le `build.gradle.kts`who lives there is a consumption script, not business code.

  3. No strategic thinking exposed : the vision documents live in the secret garden (root outside CVS). The snapshots are in`configuration/`(private vault). Nobody, even in an expanded circle of trust, reads the genesis of the strategy.

  4. Auto-prioritization : the LLM observes the delta between relational algebra (what exists) and expert mappings (what is necessary). The next development task emerges from this delta.

Conclusion: Architecture as Discourse

I don’t put a political manifesto in the footer of my site. I don’t put ethical rules in my prompts. Alignment is not in the text — it is in thefile system.

When an LLM works in this space, it cannot leak a secret (the path prevents it). It cannot confuse a teaching datum with source code (the physical zone is different). It cannot forget a security rule at 80,000 tokens — because the rule is not in the prompt, it is in the`workspace/` → configuration/→office/→`foundry/`that each file reading is reactive.

It’s the principle of secure by design applied to agent alignment: do not ask the LLM to remember the rules. Make the architecture such that error is structurally impossible.

And by the way, that gives the LLM something no prompt can give it: the ability toperceivewhere it is, what exists, what is missing — and deduce what it must do.

References

Related articles