docs: document the Maven reactor layout (llama/ module) in CLAUDE.md

- New "Repository layout — Maven reactor" section: the root is an aggregator/parent
  POM with llama/ (core) and llama-langchain4j/ modules; core sources + build files
  now live under llama/; build.sh/build.bat cd into llama/ themselves; core Maven
  builds use -f llama/pom.xml or -pl llama -am; version bumps happen in the root pom
  only (both modules inherit). Adds the caveat that existing root-relative build
  examples in this file now run in llama/.
- Rewrote the LangChain4j section: it is now a reactor module inheriting the parent
  version (no lockstep guard), releasing via one reactor deploy (inherited release
  profile), with the install step using -pl llama -am.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Rt1paYztGJ2AKUuBuAGDXE

Author: claude

CLAUDE.md

@@ -1225,51 +1225,76 @@ keeping it clear of the JPMS module-mode javadoc trap that bit BAF. **Before rai
 javadoc source level to ≥ 9, read**
 [`../workspace/policies/jpms-module-descriptor.md`](../workspace/policies/jpms-module-descriptor.md).
 
-## LangChain4j integration (`llama-langchain4j` sibling module)
+## Repository layout — Maven reactor (`llama/` + `llama-langchain4j/`)
+
+The repo root is a thin **aggregator/parent POM** (`net.ladenthin:llama-parent`,
+`packaging=pom`) with two modules:
+
+- **`llama/`** — the native JNI core (`net.ladenthin:llama`). *All the core sources and build
+  files live here now:* `llama/src/`, `llama/CMakeLists.txt`, `llama/cmake/`, `llama/patches/`,
+  `llama/pom.xml`, `llama/spotbugs-exclude.xml`, `llama/lombok.config`, `llama/.clang-format`.
+  Its published coordinates are unchanged (`net.ladenthin:llama`), so consumers are unaffected.
+- **`llama-langchain4j/`** — the LangChain4j adapters (see below).
+
+Both modules inherit the single `<version>` from the parent, so they **ship in lockstep by
+construction** (no CI guard needed). The parent also holds the shared `release` profile (GPG +
+Central Publishing), so one reactor `mvn -P release deploy` signs and publishes all three
+artifacts (`llama-parent` pom, `llama`, `llama-langchain4j`) at the same version.
+
+**Consequences for build commands:** the core's cmake/native build runs *in `llama/`*.
+`.github/build.sh` / `build.bat` `cd` into `llama/` themselves (relative to the script), so CI
+and the dockcross containers (whose workdir stays the repo root) are unaffected. Locally, run
+core cmake builds from `llama/` (e.g. `cd llama && cmake -B build && cmake --build build`), and
+target the core with Maven via `-f llama/pom.xml` (or `-pl llama -am` from the root). A plain
+`mvn` at the root builds the whole reactor. **When a build-command example elsewhere in this
+file shows `cmake -B build` / `src/main/...` / `mvn compile` at the root, read it as running in
+`llama/`** (the paths moved; the recipes are otherwise unchanged).
+
+**Version bump:** change the `<version>` in the **root** `pom.xml` only; `llama` and
+`llama-langchain4j` inherit it. (The SNAPSHOT/`-SNAPSHOT` line and the README badge still need
+the usual manual update.)
+
+## LangChain4j integration (`llama-langchain4j` reactor module)
 
 `llama-langchain4j/` adapts a `LlamaModel` to LangChain4j's `ChatModel`,
 `StreamingChatModel`, `EmbeddingModel` and `ScoringModel` interfaces **in-process over
-JNI** (no HTTP hop). It is a **standalone sibling module**, deliberately *not* in the root
-reactor, so the native build/release pipeline is untouched.
+JNI** (no HTTP hop). It is a **reactor module** alongside the core `llama` module (see
+"Repository layout" above), so it is built, versioned and released together with the core.
 
 Why it is a **separate artifact** and not a classifier of the core: langchain4j 1.x
 requires **Java 17** (the core stays Java 8), and classifiers share the core's single POM —
 adding `langchain4j-core` there would force it (and the Java 17 floor) on every plain
-`net.ladenthin:llama` consumer. A separate `artifactId` with its own POM is the only way to
+`net.ladenthin:llama` consumer. A separate `artifactId` (its own module POM) is the only way to
 keep that dependency (and Java floor) off the core. It is pure Java with **no per-classifier
 matrix**: it compiles against the core's Java API, which is identical across every native
 classifier; the backend (CPU/CUDA/OpenCL/Vulkan) is a runtime classpath choice for the
 consumer.
 
 Wiring:
 
-1. **`llama-langchain4j/pom.xml`** — `net.ladenthin:llama-langchain4j`, `release 17`,
-   depends on `net.ladenthin:llama:${project.version}` (so the core dep always matches the
-   module's own version) and `dev.langchain4j:langchain4j-core`. Carries its own
-   sources/javadoc/gpg + `release` profile (Central requires per-artifact signing; the module
-   has no parent to inherit them from — plugin versions are pinned in lockstep with the root
-   `pom.xml`). Java package stays `net.ladenthin.llama.langchain4j` (package name need not track
-   the artifactId).
-2. **`.github/workflows/publish.yml`** — the `test-java-llama-langchain4j` job installs the
-   core Java jar, runs a **version-lockstep guard** (module version must equal core version,
-   else the build fails — the standalone module can't inherit `${project.version}` from a
-   reactor), then `mvn -f llama-langchain4j/pom.xml verify` (7 model-free mapping unit tests
-   run; the 4 model-backed integration tests self-skip without a GGUF; `verify` also builds the
-   javadoc jar so a release-time javadoc break is caught in PR CI). The
-   `publish-snapshot`/`publish-release` jobs `needs:` this job and, after the core `deploy`
-   (which installs the core jar locally), run a second `deploy` of the module at the same
-   version. A separate **`test-java-llama-langchain4j-integration`** job runs the model-backed
-   tests (chat/streaming/embedding/scoring adapters) by **reusing** the shared GGUF cache
+1. **`llama-langchain4j/pom.xml`** — `net.ladenthin:llama-langchain4j`, `release 17`, a child of
+   `net.ladenthin:llama-parent` (so it **inherits `${project.version}`** — no hardcoded version,
+   no lockstep guard). Depends on `net.ladenthin:llama:${project.version}` and
+   `dev.langchain4j:langchain4j-core`. Builds its own sources/javadoc jars; the `release`
+   profile (GPG + Central Publishing) is **inherited from the parent**, not duplicated here.
+   Java package stays `net.ladenthin.llama.langchain4j` (package name need not track the artifactId).
+2. **`.github/workflows/publish.yml`** — the `test-java-llama-langchain4j` job installs
+   parent + core into the local repo (`mvn -pl llama -am -DskipTests install`), then
+   `mvn -f llama-langchain4j/pom.xml verify` (7 model-free mapping unit tests run; the 4
+   model-backed integration tests self-skip without a GGUF; `verify` also builds the javadoc
+   jar so a release-time javadoc break is caught in PR CI). The `publish-snapshot`/
+   `publish-release` jobs `needs:` this job; deployment is a **single reactor**
+   `mvn -P release deploy` (no separate module deploy step — the parent's inherited `release`
+   profile signs and publishes parent + llama + llama-langchain4j together at the same version).
+   A separate **`test-java-llama-langchain4j-integration`** job runs the model-backed tests
+   (chat/streaming/embedding/scoring adapters) by **reusing** the shared GGUF cache
    (`gguf-models-v1`, restore-only — no extra download) and the `Linux-x86_64-libraries` native
    artifact: it `needs: [crosscompile-linux-x86_64, download-models]` (so the cache is already
-   populated and it runs in parallel), installs the core jar with the downloaded native lib
-   bundled, and passes the already-cached chat
-   (`REASONING_MODEL_NAME`), nomic-embedding and jina-reranker model paths via the module's
+   populated and it runs in parallel), installs parent+core with the downloaded native lib
+   bundled, and passes the already-cached chat (`REASONING_MODEL_NAME`), nomic-embedding and
+   jina-reranker model paths via the module's
    `-Dnet.ladenthin.llama.langchain4j.{embedding,rerank}.model` / `net.ladenthin.llama.model.path`
    properties. It is validation-only (not a release gate); a cold cache degrades to a self-skip.
-3. **Version bumps** — when the root `pom.xml` `<version>` changes, bump
-   `llama-langchain4j/pom.xml` `<version>` to match in the same commit, or the lockstep guard
-   reds CI.
 
 **Open follow-ups** (documented in `llama-langchain4j/README.md`): tool calling
 (`ToolSpecification` ↔ jllama `ToolDefinition`), `response_format`/JSON mode, and multimodal