diff --git a/.github/workflows/ci.yml b/.github/workflows/ci.yml
index a79df8a2..23f9feaf 100644
--- a/.github/workflows/ci.yml
+++ b/.github/workflows/ci.yml
@@ -72,10 +72,11 @@ jobs:
   changes:
     # Path-based change detection for selective CI on pull requests. Emits the
     # reverse-dependency flags the heavy jobs gate on: `code` (any build input),
-    # `docs` (markdown the guard suites read and compile), `core` (the root
-    # graph-compose-core module — drives japicmp), `perf`
-    # (modules the smoke benchmark exercises), and `jvm` (published library modules
-    # + toolchain — drives the JDK matrix width). Pushes/dispatch bypass these gates.
+    # `docs` (markdown the guard suites read and compile), `core` and `templates`
+    # (the graph-compose-core / graph-compose-templates sources + pom — the two
+    # modules under the japicmp gate), `perf` (modules the smoke benchmark
+    # exercises), and `jvm` (published library modules + toolchain — drives the
+    # JDK matrix width). Pushes/dispatch bypass these gates.
     name: Detect changed paths
     if: github.event_name != 'schedule'
     runs-on: ubuntu-latest
@@ -83,6 +84,7 @@ jobs:
       code: ${{ steps.filter.outputs.code }}
       docs: ${{ steps.filter.outputs.docs }}
       core: ${{ steps.filter.outputs.core }}
+      templates: ${{ steps.filter.outputs.templates }}
       perf: ${{ steps.filter.outputs.perf }}
       jvm: ${{ steps.filter.outputs.jvm }}
     steps:
@@ -124,6 +126,9 @@ jobs:
             core:
               - 'core/src/**'
               - 'core/pom.xml'
+            templates:
+              - 'templates/src/**'
+              - 'templates/pom.xml'
             perf:
               - 'core/src/**'
               - 'render-pdf/**'
@@ -393,10 +398,13 @@ jobs:
           if-no-files-found: error
 
   binary-compat:
-    name: Binary Compatibility (japicmp vs pom baseline)
-    # japicmp diffs the graph-compose-core public surface, so it only matters
-    # when the core module (`core/src/**` or `core/pom.xml`) changed.
-    if: github.event_name == 'pull_request' && needs.changes.outputs.core == 'true'
+    name: Binary Compatibility (japicmp vs pom baselines)
+    # japicmp diffs the graph-compose-core and graph-compose-templates public
+    # surfaces (both carry a `japicmp` profile), so it only matters when one of
+    # those modules (`core/**` or `templates/**` sources / pom) changed. Both are
+    # always diffed together: templates resolves core from the same reactor build,
+    # and a core change can move the templates surface it re-exports.
+    if: github.event_name == 'pull_request' && (needs.changes.outputs.core == 'true' || needs.changes.outputs.templates == 'true')
     needs: [architecture-and-documentation-guards, changes]
     runs-on: ubuntu-latest
     env:
@@ -422,21 +430,27 @@ jobs:
       - name: Install graph-compose-emoji (resolved at test scope by core)
         run: ./mvnw -B -ntp -f emoji/pom.xml -DskipTests install
 
-      - name: Compare public API against baseline
-        # The `japicmp` profile resolves the baseline release pinned
-        # by the `japicmp.baseline` property in core/pom.xml (the
-        # published graph-compose-core on Maven Central) and diffs it
-        # against the freshly-built artifact. Fails the job on any binary-
-        # incompatible modification to the public surface. Source-
-        # incompatible changes are reported only (phased policy).
-        run: ./mvnw -B -ntp -DskipTests -P japicmp verify -pl :graph-compose-core
+      - name: Compare public API against baselines
+        # The `japicmp` profile in each module resolves TWO published baselines of
+        # that module (japicmp.baseline.floor — the major's first release, holding
+        # the GA surface; japicmp.baseline.previous — the latest release, holding
+        # everything added since) and diffs each against the freshly-built
+        # artifact. The floor alone would let a method introduced after it be
+        # deleted with the diff green. Fails the job on any
+        # binary-incompatible modification to the public surface. Source-
+        # incompatible changes are reported only (phased policy). Both modules
+        # sit in one reactor invocation: the reactor orders core before
+        # templates, so templates compiles against the freshly-built core.
+        run: ./mvnw -B -ntp -DskipTests -P japicmp verify -pl :graph-compose-core,:graph-compose-templates
 
       - name: Upload japicmp report
         if: always()
         uses: actions/upload-artifact@v7
         with:
           name: japicmp-report-${{ github.run_id }}
-          path: core/target/japicmp/**
+          path: |
+            core/target/japicmp/**
+            templates/target/japicmp/**
           if-no-files-found: ignore
 
   perf-smoke:
diff --git a/.github/workflows/publish.yml b/.github/workflows/publish.yml
index 8c2f1af0..29463417 100644
--- a/.github/workflows/publish.yml
+++ b/.github/workflows/publish.yml
@@ -130,18 +130,28 @@ jobs:
         # unpublished tests-jar no longer fails the deploy.
         run: ./mvnw -B -ntp clean install
 
-      - name: Verify binary compatibility against the published baseline
+      - name: Verify binary compatibility against the published baselines
         # Defence in depth: run the japicmp gate on the tagged commit before any
         # deploy, so an accidental binary-incompatible change to the public
         # surface aborts the publish even when the tag reached here by bypassing
         # branch protection (the CI japicmp job only gates pull requests). Compares
-        # the freshly built graph-compose-core against the japicmp.baseline release
-        # on Maven Central and fails the job on any Stable-surface break; the
-        # Internal packages (engine.**, document.layout.**) are excluded per
-        # docs/api-stability.md. Test build is skipped — the install step above
-        # already ran the full suite on this commit.
+        # the freshly built graph-compose-core against both baselines pinned in
+        # core/pom.xml — the major floor and the latest published release — and
+        # fails the job on any Stable-surface break; the Internal packages
+        # (engine.**, document.layout.**) are excluded per docs/api-stability.md.
+        # Test build is skipped — the install step above already ran the full
+        # suite on this commit.
         run: ./mvnw -B -ntp -f core/pom.xml -P japicmp -Dmaven.test.skip=true verify
 
+      - name: Verify templates binary compatibility against the published baselines
+        # Same defence for graph-compose-templates: its own `japicmp` profile
+        # diffs the freshly built jar against the two baselines pinned in
+        # templates/pom.xml. Every templates.* package is Stable per
+        # docs/api-stability.md, so only elements carrying the per-element
+        # @Internal marker are excluded (none today). Standalone pom — it
+        # resolves graph-compose-core from the local m2 the install step seeded.
+        run: ./mvnw -B -ntp -f templates/pom.xml -P japicmp -Dmaven.test.skip=true verify
+
       - name: Plan the deploy set (start_at resume)
         id: plan
         # A partial Central publication CANNOT be blindly re-dispatched: the deploys
diff --git a/.github/workflows/release-script-check.yml b/.github/workflows/release-script-check.yml
index b94c2ff2..b72dd866 100644
--- a/.github/workflows/release-script-check.yml
+++ b/.github/workflows/release-script-check.yml
@@ -351,3 +351,69 @@ jobs:
           if ((Get-Content $roadmap -Raw) -ne $after) { throw "a second promotion changed the file" }
 
           Write-Host "roadmap promotion: 3 refusals, 1 rewrite, idempotent on re-run."
+
+      - name: Unit-check the japicmp previous-release baseline move
+        shell: pwsh
+        run: |
+          # The binary-compatibility gate diffs against two published releases: the major
+          # floor, which never moves inside a major, and the previous release, which must
+          # move to the version just published at every cut. A pin left behind leaves
+          # everything added in that release freely removable with the gate green, so the
+          # move is code that has to be exercised, not a step someone remembers. Lifted by
+          # AST like the checks above, so the code under test is the code that ships.
+          $path = (Resolve-Path scripts/cut-release.ps1).Path
+          $ast = [System.Management.Automation.Language.Parser]::ParseFile($path, [ref]$null, [ref]$null)
+          $fn = $ast.FindAll({
+              param($n)
+              $n -is [System.Management.Automation.Language.FunctionDefinitionAst] -and $n.Name -eq 'Update-JapicmpPreviousBaseline'
+            }, $true)
+          if (-not $fn) { throw 'cut-release.ps1 no longer defines Update-JapicmpPreviousBaseline' }
+          Invoke-Expression $fn[0].Extent.Text
+          function Note($m) { Write-Host "    $m" }
+          $DryRun = $false
+
+          # A function nothing calls moves no pin. Assert the post-release path still
+          # invokes it — the failure this guards is the helper surviving a refactor that
+          # drops the call, which every content assertion below would still pass.
+          $calls = $ast.FindAll({
+              param($n)
+              $n -is [System.Management.Automation.Language.CommandAst] -and
+              $n.GetCommandName() -eq 'Update-JapicmpPreviousBaseline'
+            }, $true)
+          if (-not $calls) { throw 'nothing in cut-release.ps1 calls Update-JapicmpPreviousBaseline' }
+
+          function New-Pom($previous) {
+            $file = Join-Path ([IO.Path]::GetTempPath()) ("pom-" + [guid]::NewGuid().ToString() + ".xml")
+            Set-Content -Path $file -NoNewline -Value (@(
+              '<project>',
+              '  <version>2.3.1-SNAPSHOT</version>',
+              '  <properties>',
+              '    <japicmp.baseline.floor>2.0.0</japicmp.baseline.floor>',
+              "    <japicmp.baseline.previous>$previous</japicmp.baseline.previous>",
+              '  </properties>',
+              '</project>'
+            ) -join "`n")
+            return $file
+          }
+
+          $pom = New-Pom '2.2.0'
+          if (-not (Update-JapicmpPreviousBaseline $pom '2.3.0')) { throw 'moving the pin reported no change' }
+          $after = Get-Content $pom -Raw
+          if ($after -notmatch '<japicmp\.baseline\.previous>2\.3\.0</japicmp\.baseline\.previous>') {
+            throw "the previous-release pin did not move:`n$after"
+          }
+          if ($after -notmatch '<japicmp\.baseline\.floor>2\.0\.0</japicmp\.baseline\.floor>') {
+            throw "the major floor must not move at a cut:`n$after"
+          }
+          if ($after -notmatch '<version>2\.3\.1-SNAPSHOT</version>') { throw "the project version was rewritten:`n$after" }
+
+          if (Update-JapicmpPreviousBaseline $pom '2.3.0') { throw 'a second move reported a change' }
+
+          $bare = Join-Path ([IO.Path]::GetTempPath()) ("pom-" + [guid]::NewGuid().ToString() + ".xml")
+          Set-Content -Path $bare -NoNewline -Value "<project>`n  <version>2.3.1-SNAPSHOT</version>`n</project>"
+          if (Update-JapicmpPreviousBaseline $bare '2.3.0') { throw 'a pom without the pin reported a change' }
+          if (Update-JapicmpPreviousBaseline (Join-Path ([IO.Path]::GetTempPath()) 'no-such-pom.xml') '2.3.0') {
+            throw 'a missing pom reported a change'
+          }
+
+          Write-Host 'japicmp baseline: previous moves, floor stays, idempotent, and the cut calls it.'
diff --git a/CHANGELOG.md b/CHANGELOG.md
index a6680edb..eaeda76d 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -7,6 +7,37 @@ follow semantic versioning; release dates are ISO 8601.
 
 ### Build
 
+- **The templates module is under the binary-compatibility gate, and the gate now
+  protects what a release added.** `docs/api-stability.md` has listed every
+  `templates.*` package as Stable — no binary break outside a major — since the 2.0
+  module split, but japicmp only ever diffed `graph-compose-core`; a removed or
+  narrowed public method in a preset, a data record, or a shared widget would have
+  shipped in a 2.x minor with nothing looking at it. `templates/pom.xml` now carries
+  the same `japicmp` profile as the engine pom.
+
+  Both modules pin **two** baselines instead of one, each diffed in its own execution.
+  A floor pin alone protects only the surface the major shipped with: a method that
+  first ships in 2.2.0 is absent from both 2.0.0 and a 2.2.1 that deletes it, so the
+  floor diff stays green while an application compiled against 2.2.0 gets
+  `NoSuchMethodError` — and `MarkdownInline.appendTransformed` and `SectionAllocation`,
+  both added after 2.0.0, sat in exactly that gap. `japicmp.baseline.floor` keeps
+  holding the GA surface; `japicmp.baseline.previous` holds everything added since and
+  moves to the version just published in `cut-release.ps1 -PostReleaseOnly`. A pin left
+  behind is not a silent hole: `VersionConsistencyGuardTest` derives both rather than
+  trusting them — the floor from the module's own version, the previous pin from the
+  CHANGELOG — and asserts both executions are still in the pom, while the release-script
+  workflow drives the move itself. Both pins stay inside the working major, so opening
+  the next one leaves them naming a version nobody has published and the gate stands
+  down for that cycle rather than failing every break the major is for.
+
+  The PR-time `Binary Compatibility` job runs the gate whenever the core or templates
+  sources or pom changed, `cut-release.ps1` step 5b runs it before the tag is cut, and
+  the publish workflow runs it again on the tagged commit before anything is deployed.
+  The current surface is binary- and source-compatible with both baselines; removing
+  `MarkdownInline.appendTransformed` fails the build with `METHOD_REMOVED` against the
+  2.2.0 pin while the 2.0.0 diff stays green, which is the hole the second baseline
+  closes.
+
 - **The weekly benchmark run builds the modules it measures.** The JMH workflow
   installed the engine from source and then let Maven resolve the rest from Central,
   and one of them is not there to resolve: the benchmarks read their document fixtures
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index 2e2dea05..d7d7a3b7 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -70,11 +70,11 @@ Almost all work targets **`develop`**, the ongoing 2.x line. The `1.x` branch ta
    - `Architecture and Documentation Guards` &mdash; fast canonical / engine-boundary guard tests, fail-first gate (always runs)
    - `Build and run tests (JDK 17)`, `(JDK 21)`, `(JDK 25)` &mdash; full `mvnw verify` in parallel matrix across the supported JVMs
    - `Examples Generation Smoke Test` &mdash; regenerates every runnable example and uploads the PDFs as a CI artifact
-   - `Binary Compatibility` &mdash; PR-only japicmp diff of the `graph-compose-core` surface
+   - `Binary Compatibility` &mdash; PR-only japicmp diff of the `graph-compose-core` and `graph-compose-templates` surfaces
    - `Performance Smoke Check` &mdash; PR-only coarse benchmark to catch performance regressions
    - `CI Gate` &mdash; single aggregate status check that is green when every job that ran passed
 
-   **Selective on pull requests:** a `dorny/paths-filter` step skips the heavy jobs when a PR touches nothing that affects the build. Markdown counts as a build input, so a **docs-only PR still runs the reactor** &mdash; on the baseline JDK alone, and without example generation &mdash; because that is where the guards compiling the published snippets live. `Binary Compatibility` runs only when the core module changed, and the `Performance Smoke Check` only when core / render-pdf / templates changed. Pushes to `develop` / `main` (and manual dispatch) always run the full gate. Point branch protection at **`CI Gate`** + **`Architecture and Documentation Guards`** rather than the individual matrix legs, so a docs-only PR is not left waiting on a skipped check.
+   **Selective on pull requests:** a `dorny/paths-filter` step skips the heavy jobs when a PR touches nothing that affects the build. Markdown counts as a build input, so a **docs-only PR still runs the reactor** &mdash; on the baseline JDK alone, and without example generation &mdash; because that is where the guards compiling the published snippets live. `Binary Compatibility` runs only when the core or templates module changed, and the `Performance Smoke Check` only when core / render-pdf / templates changed. Pushes to `develop` / `main` (and manual dispatch) always run the full gate. Point branch protection at **`CI Gate`** + **`Architecture and Documentation Guards`** rather than the individual matrix legs, so a docs-only PR is not left waiting on a skipped check.
 
    The PR cannot merge into a protected branch until all required checks are green.
 7. **Address review comments**, then squash any fixup commits before merge. The maintainer merges through GitHub once review is complete.
diff --git a/ROADMAP.md b/ROADMAP.md
index 14d6ed2e..9b8f1bf9 100644
--- a/ROADMAP.md
+++ b/ROADMAP.md
@@ -49,7 +49,7 @@ The **v1.9.x** line receives critical fixes only.
 Committed internal direction for the post-2.0 line: refactors, scale work, and tooling that do **not** change the public authoring API. Tracked in [docs/roadmaps/post-2.0-engineering.md](docs/roadmaps/post-2.0-engineering.md).
 
 - **Decompose the layout hot files** &mdash; split `LayoutCompiler` and `TextFlowSupport` along their natural seams into individually-tested collaborators, with layout output unchanged.
-- **Per-module binary-compatibility baselines** &mdash; now that the 2.0 GA artifacts are published, switch `japicmp` from the single-artifact baseline to per-module baselines in break-on-incompatible mode.
+- **Per-module binary-compatibility baselines** &mdash; `japicmp` gates `graph-compose-core` and `graph-compose-templates` against their 2.0.0 floors in break-on-incompatible mode; the remaining published modules join once each has a documented Stable / Internal split.
 
 ## Later (directional)
 
diff --git a/core/pom.xml b/core/pom.xml
index 5e1d1bdd..2d53ee4c 100644
--- a/core/pom.xml
+++ b/core/pom.xml
@@ -89,16 +89,23 @@
         <enforcer.requireMavenVersion>3.8.0</enforcer.requireMavenVersion>
         <enforcer.requireJavaVersion>17</enforcer.requireJavaVersion>
 
-        <!-- Binary compatibility baseline (japicmp profile) -->
+        <!-- Binary compatibility baselines (japicmp profile). Keep japicmp.version in
+             lockstep with templates/pom.xml (VersionConsistencyGuardTest enforces). -->
         <japicmp.version>0.26.1</japicmp.version>
-        <!-- 2.x binary-compatibility baseline: the published graph-compose-core on
-             Maven Central. The 2.0 major transition is complete, so the gate now
-             enforces binary compatibility against 2.0.0 (see the japicmp profile).
-             The gate is a no-op while the working version equals the baseline
-             (2.0.0) and becomes active the moment the version bumps to the next
-             -SNAPSHOT — proven: 2.0.1-SNAPSHOT + a reduced-access public method
-             fails with METHOD_LESS_ACCESSIBLE. -->
-        <japicmp.baseline>2.0.0</japicmp.baseline>
+        <!-- Two published graph-compose-core baselines on Maven Central, diffed in two
+             executions of the japicmp profile:
+             * floor — the first release of the current major (2.0.0 for the whole 2.x
+               line), advancing only at the next major. Holds the GA surface.
+             * previous — the latest published release. Holds everything added since
+               the floor: a method that first shipped in 2.2.0 is absent from BOTH
+               2.0.0 and a 2.2.1 that removes it, so the floor diff alone stays green
+               while a caller compiled against 2.2.0 gets NoSuchMethodError. This pin
+               moves to the just-published version in `cut-release.ps1
+               -PostReleaseOnly`; VersionConsistencyGuardTest holds it to the newest
+               dated CHANGELOG release older than the working version, so a forgotten
+               move fails the guard job rather than silently widening the hole. -->
+        <japicmp.baseline.floor>2.0.0</japicmp.baseline.floor>
+        <japicmp.baseline.previous>2.2.0</japicmp.baseline.previous>
 
         <!--
             GPG signing — opted in via -Dgpg.skip=false (the publish
@@ -663,15 +670,17 @@
         </profile>
 
         <!--
-            Binary-compatibility gate. Activated with `-P japicmp`. Resolves the
-            baseline artifact (the published graph-compose-core pinned by the
-            japicmp.baseline property) from Maven Central — no extra repository, so
-            consumers inherit nothing. The baseline is the current major's floor
-            (2.0.0 for the whole 2.x line), advancing only at the next major, so the
-            gate holds every 2.x build binary-compatible with the 2.0.0 public
-            surface. Fails the build on any binary-incompatible modification to the
-            public surface; source-incompatible changes are reported but do not fail
-            (yet) so the policy can be phased in.
+            Binary-compatibility gate. Activated with `-P japicmp`. Resolves the two
+            baseline artifacts (the published graph-compose-core pinned by the
+            japicmp.baseline.floor / japicmp.baseline.previous properties) from Maven
+            Central — no extra repository, so consumers inherit nothing — and diffs
+            the freshly built jar against each in its own execution: the major floor
+            (2.0.0 for the whole 2.x line) holds the GA surface, the previous release
+            holds every public element added since. Together they hold every 2.x
+            build binary-compatible with every 2.x release before it. Fails the build
+            on any binary-incompatible modification to the public surface;
+            source-incompatible changes are reported but do not fail (yet) so the
+            policy can be phased in.
         -->
         <profile>
             <id>japicmp</id>
@@ -683,27 +692,59 @@
                         <version>${japicmp.version}</version>
                         <executions>
                             <execution>
-                                <id>japicmp-against-baseline</id>
+                                <id>japicmp-against-major-floor</id>
                                 <phase>verify</phase>
                                 <goals>
                                     <goal>cmp</goal>
                                 </goals>
+                                <configuration>
+                                    <oldVersion>
+                                        <dependency>
+                                            <groupId>io.github.demchaav</groupId>
+                                            <artifactId>graph-compose-core</artifactId>
+                                            <version>${japicmp.baseline.floor}</version>
+                                        </dependency>
+                                    </oldVersion>
+                                </configuration>
+                            </execution>
+                            <execution>
+                                <id>japicmp-against-previous-release</id>
+                                <phase>verify</phase>
+                                <goals>
+                                    <goal>cmp</goal>
+                                </goals>
+                                <configuration>
+                                    <oldVersion>
+                                        <dependency>
+                                            <groupId>io.github.demchaav</groupId>
+                                            <artifactId>graph-compose-core</artifactId>
+                                            <version>${japicmp.baseline.previous}</version>
+                                        </dependency>
+                                    </oldVersion>
+                                </configuration>
                             </execution>
                         </executions>
                         <configuration>
-                            <oldVersion>
-                                <dependency>
-                                    <groupId>io.github.demchaav</groupId>
-                                    <artifactId>graph-compose-core</artifactId>
-                                    <version>${japicmp.baseline}</version>
-                                </dependency>
-                            </oldVersion>
                             <newVersion>
                                 <file>
                                     <path>${project.build.directory}/${project.build.finalName}.jar</path>
                                 </file>
                             </newVersion>
                             <parameter>
+                                <!--
+                                    A baseline that is not on Central yet skips its
+                                    execution instead of failing the build. This is the
+                                    pre-GA window of a NEW major and nothing else: on
+                                    3.0.0-SNAPSHOT both pins name 3.0.0, which nobody has
+                                    published, and the major is allowed to break 2.x
+                                    anyway — the same report-only posture the 2.0 cycle
+                                    ran under, now automatic instead of hand-edited. It
+                                    cannot mask a typo: VersionConsistencyGuardTest pins
+                                    both properties to exact values derived from the pom
+                                    version and the CHANGELOG, so a baseline that names
+                                    something unintended fails the guard job.
+                                -->
+                                <ignoreMissingOldVersion>true</ignoreMissingOldVersion>
                                 <onlyModified>true</onlyModified>
                                 <!--
                                     2.x binary-compatibility gate. The 2.0 major transition is
diff --git a/core/src/test/java/com/demcha/documentation/ChangelogVersionParsingTest.java b/core/src/test/java/com/demcha/documentation/ChangelogVersionParsingTest.java
index 8338f922..e2580bd3 100644
--- a/core/src/test/java/com/demcha/documentation/ChangelogVersionParsingTest.java
+++ b/core/src/test/java/com/demcha/documentation/ChangelogVersionParsingTest.java
@@ -3,6 +3,7 @@
 import org.junit.jupiter.api.Test;
 
 import java.util.List;
+import java.util.Optional;
 
 import static org.assertj.core.api.Assertions.assertThat;
 
@@ -195,6 +196,102 @@ void aSnapshotAndAReleaseCandidateShareTheirReleaseLine() {
         assertThat(VersionConsistencyGuardTest.releaseLineOf("2.2.0")).isEqualTo("2.2.0");
     }
 
+    // ── Which release the japicmp previous-release pin must name ────
+
+    private static final String RELEASES = """
+            # Changelog
+
+            ## v2.3.0 — Planned
+
+            ## v2.2.0 — 2026-08-15
+
+            ## v2.2.0-rc.1 — 2026-08-12
+
+            ## v2.1.1 — 2026-08-05
+
+            ## v2.0.0 — 2026-07-01
+            """;
+
+    @Test
+    void duringASnapshotCycleThePreviousReleaseIsTheNewestDatedEntry() {
+        assertThat(previousReleaseFor("2.2.1-SNAPSHOT")).contains("2.2.0");
+        assertThat(previousReleaseFor("2.3.0-SNAPSHOT")).contains("2.2.0");
+    }
+
+    @Test
+    void onTheReleaseCommitThePreviousReleaseIsTheOneBeforeIt() {
+        // The cut dates the entry and sets the poms to the release in the same commit;
+        // the release itself is not yet on Central, so the gate must still diff it
+        // against the release before it — and 2.2.0 excludes itself.
+        assertThat(previousReleaseFor("2.2.0")).contains("2.1.1");
+        assertThat(previousReleaseFor("2.2.0-rc.2")).contains("2.1.1");
+    }
+
+    @Test
+    void openAndPreReleaseEntriesNeverBecomeThePreviousRelease() {
+        // A -rc entry is dated but never published to Central; a Planned entry is
+        // undated. Neither is an artifact the gate could resolve.
+        assertThat(previousReleaseFor("2.2.0-rc.2")).contains("2.1.1");
+        assertThat(previousReleaseFor("2.4.0-SNAPSHOT")).contains("2.2.0");
+    }
+
+    @Test
+    void aReleaseOfAnEarlierMajorIsNeverThePreviousRelease() {
+        // Opening 3.0 leaves the major with no release of its own. Reaching back to
+        // 2.2.0 would diff across the boundary and fail the build on every break the
+        // major is allowed to make; the caller falls back to the floor instead, which
+        // is unpublished during the cycle and so skips.
+        assertThat(previousReleaseFor("3.0.0-SNAPSHOT")).isEmpty();
+        assertThat(previousReleaseFor("3.0.0")).isEmpty();
+        // Once the major has shipped one, it is used — and only within the major.
+        assertThat(VersionConsistencyGuardTest.newestFinalReleaseInMajorBefore(
+                RELEASES + "\n## v3.0.0 — 2026-10-01\n", "3.0.1-SNAPSHOT")).contains("3.0.0");
+    }
+
+    @Test
+    void aLogWithNothingOlderYieldsNoPreviousRelease() {
+        assertThat(previousReleaseFor("2.0.0")).isEmpty();
+        assertThat(VersionConsistencyGuardTest.newestFinalReleaseInMajorBefore("## v2.0.0 — Planned\n", "2.0.0-SNAPSHOT"))
+                .isEmpty();
+    }
+
+    @Test
+    void thePreviousReleaseIsChosenNumericallyNotByFilePosition() {
+        // A patch entry filed above a newer minor (a hotfix line released after the
+        // minor opened) must not shadow it: 2.2.0 is newer than 2.1.2 whatever the order.
+        assertThat(VersionConsistencyGuardTest.newestFinalReleaseInMajorBefore("""
+                ## v2.1.2 — 2026-08-20
+                ## v2.2.0 — 2026-08-15
+                ## v2.1.1 — 2026-08-05
+                """, "2.2.1-SNAPSHOT")).contains("2.2.0");
+        assertThat(VersionConsistencyGuardTest.newestFinalReleaseInMajorBefore(
+                "## v2.10.0 — 2026-12-01\n## v2.9.0 — 2026-11-01\n", "2.10.1-SNAPSHOT")).contains("2.10.0");
+    }
+
+    @Test
+    void aVersionSegmentTooWideForAnIntIsOrderedNotRejected() {
+        // Segments are compared as digit strings, so a number no int could hold orders
+        // correctly instead of throwing NumberFormatException out of a guard — which
+        // would replace the assertion message naming the wrong pin with a stack trace.
+        assertThat(VersionConsistencyGuardTest.newestFinalReleaseInMajorBefore("""
+                ## v2.99999999999.0 — 2026-12-01
+                ## v2.2.0 — 2026-08-15
+                """, "2.99999999999.1-SNAPSHOT")).contains("2.99999999999.0");
+        assertThat(VersionConsistencyGuardTest.newestFinalReleaseInMajorBefore(
+                "## v2.99999999999.0 — 2026-12-01\n## v2.2.0 — 2026-08-15\n", "2.3.0-SNAPSHOT"))
+                .contains("2.2.0");
+    }
+
+    @Test
+    void leadingZerosDoNotChangeTheOrder() {
+        assertThat(VersionConsistencyGuardTest.newestFinalReleaseInMajorBefore(
+                "## v2.02.0 — 2026-08-15\n## v2.1.0 — 2026-07-01\n", "2.3.0-SNAPSHOT")).contains("2.02.0");
+    }
+
+    private static Optional<String> previousReleaseFor(String pomVersion) {
+        return VersionConsistencyGuardTest.newestFinalReleaseInMajorBefore(RELEASES, pomVersion);
+    }
+
     private static String problem(String changelog, String pomVersion) {
         return VersionConsistencyGuardTest.versionDriftProblem(changelog, pomVersion);
     }
diff --git a/core/src/test/java/com/demcha/documentation/VersionConsistencyGuardTest.java b/core/src/test/java/com/demcha/documentation/VersionConsistencyGuardTest.java
index 2bda9b46..26cb2c7c 100644
--- a/core/src/test/java/com/demcha/documentation/VersionConsistencyGuardTest.java
+++ b/core/src/test/java/com/demcha/documentation/VersionConsistencyGuardTest.java
@@ -17,6 +17,7 @@
 import java.util.LinkedHashSet;
 import java.util.List;
 import java.util.Map;
+import java.util.Optional;
 import java.util.Set;
 import java.util.regex.Matcher;
 import java.util.regex.Pattern;
@@ -201,6 +202,170 @@ void jacocoPluginVersionAgreesAcrossModules() throws Exception {
                 .isEqualTo(core);
     }
 
+    /**
+     * The binary-compatibility gate runs the same japicmp plugin in every module
+     * that carries a {@code japicmp} profile — a version pinned as a literal in each
+     * standalone pom. Two literals of one version drift apart silently, and a
+     * plugin skew here means the two modules are judged by different
+     * compatibility rules. Only the plugin version is held in lockstep: each
+     * module's baselines name its own published releases, which
+     * {@link #japicmpBaselinesTrackTheWorkingMajorAndTheLatestRelease} checks
+     * against that module's own version and the CHANGELOG.
+     */
+    @Test
+    void japicmpPluginVersionAgreesAcrossGatedModules() throws Exception {
+        String core = pinnedVersionProperty(PROJECT_ROOT.resolve("core/pom.xml"), "japicmp.version");
+
+        assertThat(pinnedVersionProperty(PROJECT_ROOT.resolve("templates/pom.xml"), "japicmp.version"))
+                .describedAs("templates japicmp.version must match the engine pom's (%s)", core)
+                .isEqualTo(core);
+    }
+
+    /** The modules whose pom carries a {@code japicmp} profile with the two baselines. */
+    private static final List<String> JAPICMP_GATED_POMS = List.of("core/pom.xml", "templates/pom.xml");
+
+    /**
+     * The binary-compatibility gate diffs each gated module against two published
+     * releases. The major floor ({@code japicmp.baseline.floor}) is the first release
+     * of the working major and holds the GA surface. It cannot hold anything added
+     * later: a method that first shipped in 2.2.0 is absent from both 2.0.0 and a
+     * 2.2.1 that removes it, so that diff stays green while a caller compiled against
+     * 2.2.0 gets {@code NoSuchMethodError}. The previous-release pin
+     * ({@code japicmp.baseline.previous}) closes that hole — but only while it names
+     * the latest release actually published, and it is a literal in a pom that
+     * {@code cut-release.ps1 -PostReleaseOnly} moves after each cut. A move that does
+     * not happen leaves every element added in the release just shipped unprotected,
+     * with the gate reporting green, so the pin is held to the CHANGELOG here: it
+     * must name the newest dated final release <em>of the working major</em> strictly
+     * older than the working version. That reading is right on both sides of a cut —
+     * on the release commit (pom {@code 2.3.0}, CHANGELOG {@code ## v2.3.0 — <date>})
+     * the newest release older than 2.3.0 is still 2.2.0, which is what the release
+     * must be diffed against; on the next {@code 2.3.1-SNAPSHOT} it is 2.3.0, so the
+     * bump commit that forgets the pin fails here.
+     *
+     * <p>Both pins stay inside the working major, and the major boundary is where that
+     * matters. On {@code 3.0.0-SNAPSHOT} the floor is {@code 3.0.0} and no 3.x release
+     * exists yet, so the previous pin falls back to the floor: both name a version
+     * nobody has published, both executions skip (the poms set
+     * {@code ignoreMissingOldVersion}), and the 3.0 cycle is free to break 2.x — the
+     * report-only posture the 2.0 transition ran under, without a hand-edited pom.
+     * Pinning across the boundary instead would fail the build on every intentional
+     * major break. The pins start enforcing again the moment {@code 3.0.0} is on
+     * Central, which is the first {@code -PostReleaseOnly} of the new major.</p>
+     */
+    @Test
+    void japicmpBaselinesTrackTheWorkingMajorAndTheLatestRelease() throws Exception {
+        String changelog = Files.readString(PROJECT_ROOT.resolve("CHANGELOG.md"));
+
+        for (String pom : JAPICMP_GATED_POMS) {
+            Path path = PROJECT_ROOT.resolve(pom);
+            String working = effectiveVersion(path);
+            String floor = releaseLineOf(working).split("\\.")[0] + ".0.0";
+
+            assertThat(pinnedVersionProperty(path, "japicmp.baseline.floor"))
+                    .describedAs("%s japicmp.baseline.floor must be the first release of the working "
+                            + "major (%s for working version %s)", pom, floor, working)
+                    .isEqualTo(floor);
+
+            String expected = newestFinalReleaseInMajorBefore(changelog, working).orElse(floor);
+            assertThat(pinnedVersionProperty(path, "japicmp.baseline.previous"))
+                    .describedAs("%s japicmp.baseline.previous must be the newest dated CHANGELOG release "
+                            + "of the working major older than the working version %s (the floor itself "
+                            + "while the major has none) — cut-release.ps1 -PostReleaseOnly moves it to "
+                            + "the version just published; a stale pin leaves everything added in that "
+                            + "release unprotected by the japicmp gate", pom, working)
+                    .isEqualTo(expected);
+        }
+    }
+
+    /**
+     * Every japicmp execution each gated pom must keep. Two properties with one
+     * execution reading them is the same hole with a tidier pom: the previous-release
+     * diff would simply stop running, and a guard that only reads properties would
+     * stay green through it.
+     */
+    @Test
+    void bothJapicmpBaselineExecutionsSurviveInEachGatedPom() throws Exception {
+        for (String pom : JAPICMP_GATED_POMS) {
+            String text = Files.readString(PROJECT_ROOT.resolve(pom));
+            for (String execution : List.of("japicmp-against-major-floor", "japicmp-against-previous-release")) {
+                assertThat(text)
+                        .describedAs("%s must keep the <execution> with id %s — the gate is two diffs, "
+                                + "and one of them silently not running is the hole the second baseline "
+                                + "exists to close", pom, execution)
+                        .contains("<id>" + execution + "</id>");
+            }
+            for (String property : List.of("japicmp.baseline.floor", "japicmp.baseline.previous")) {
+                assertThat(text)
+                        .describedAs("%s must reference ${%s} from an execution's <oldVersion>", pom, property)
+                        .contains("${" + property + "}");
+            }
+        }
+    }
+
+    /**
+     * The newest dated final release ({@code ## vX.Y.Z — YYYY-MM-DD}) in {@code changelog}
+     * that shares {@code version}'s major and is strictly older than its {@code X.Y.Z};
+     * empty when the major has none yet. Open ({@code — Planned}) and pre-release
+     * ({@code -rc.N}) entries never count: neither is a published Maven Central artifact
+     * a gate could resolve. Releases of an earlier major never count either — diffing
+     * across a major boundary would fail the build on breaks the major is allowed to make.
+     *
+     * <p>String-driven so {@code ChangelogVersionParsingTest} can hold the shapes: a
+     * snapshot cycle, the release commit (working version equal to the newest release),
+     * the opening of a new major, and a log with nothing older.</p>
+     */
+    static Optional<String> newestFinalReleaseInMajorBefore(String changelog, String version) {
+        String working = releaseLineOf(version);
+        Matcher released = Pattern.compile(
+                        "^## v(\\d+\\.\\d+\\.\\d+)\\s*[\\u2014\\-]\\s*\\d{4}-\\d{2}-\\d{2}", Pattern.MULTILINE)
+                .matcher(changelog);
+        String newest = null;
+        while (released.find()) {
+            String candidate = released.group(1);
+            if (segment(candidate, 0).equals(segment(working, 0))
+                    && compareReleases(candidate, working) < 0
+                    && (newest == null || compareReleases(candidate, newest) > 0)) {
+                newest = candidate;
+            }
+        }
+        return Optional.ofNullable(newest);
+    }
+
+    /**
+     * Orders two {@code X.Y.Z} release lines, comparing each segment as a number.
+     *
+     * <p>Compared as digit strings rather than parsed: {@code Integer.parseInt} throws
+     * {@link NumberFormatException} on a segment wider than an {@code int}, which in a
+     * guard would surface as a stack trace instead of the assertion message that says
+     * which pin is wrong. Nothing here needs the numeric value — only the order — and
+     * a longer digit string is the larger number once leading zeros are gone.</p>
+     */
+    private static int compareReleases(String left, String right) {
+        for (int i = 0; i < 3; i++) {
+            String a = segment(left, i);
+            String b = segment(right, i);
+            int order = a.length() != b.length()
+                    ? Integer.compare(a.length(), b.length())
+                    : a.compareTo(b);
+            if (order != 0) {
+                return order;
+            }
+        }
+        return 0;
+    }
+
+    /** Segment {@code index} of an {@code X.Y.Z} version, leading zeros stripped. */
+    private static String segment(String version, int index) {
+        String[] parts = version.split("\\.");
+        String part = index < parts.length ? parts[index] : "0";
+        int firstSignificant = 0;
+        while (firstSignificant < part.length() - 1 && part.charAt(firstSignificant) == '0') {
+            firstSignificant++;
+        }
+        return part.substring(firstSignificant);
+    }
+
     /**
      * The wrapper builds its javadoc jar from the engine's sources, which are
      * Lombok-annotated, so it feeds Lombok to the javadoc plugin as an additional
diff --git a/docs/api-stability.md b/docs/api-stability.md
index 605846e6..8bc7fec1 100644
--- a/docs/api-stability.md
+++ b/docs/api-stability.md
@@ -197,24 +197,55 @@ window starts, and its `Status` flips to `deprecated 1.x`.
 
 The Stable-tier promise (§ 1 — no binary breaks outside a major release) is enforced
 mechanically by [japicmp](https://siom79.github.io/japicmp/), run in a `japicmp` Maven
-profile on the engine module during `verify`.
-
-- **Baseline:** the published `graph-compose-core` on Maven Central, pinned by the
-  `japicmp.baseline` property in `core/pom.xml`. It is the current major's **floor** —
-  `2.0.0` for the whole 2.x line — and advances only at the next major. Holding it at
-  the floor (rather than the previous release) is what enforces the Stable promise:
-  every 2.x build must stay binary-compatible with the `2.0.0` public surface, not
-  merely with the last minor.
+profile during `verify` on the two modules whose packages the § 4 map lists as Stable
+authoring surface: the engine (`graph-compose-core`) and the templates
+(`graph-compose-templates`).
+
+- **Two baselines, both published artifacts of the same module on Maven Central,
+  pinned in that module's own pom** (`core/pom.xml`, `templates/pom.xml`) and diffed in
+  their own execution of the profile:
+  - `japicmp.baseline.floor` — the current major's **floor** (`2.0.0` for the whole 2.x
+    line), advancing only at the next major. It holds the surface the major shipped
+    with: every 2.x build stays binary-compatible with `2.0.0`.
+  - `japicmp.baseline.previous` — the **latest published release**, moved to the version
+    just cut by `scripts/cut-release.ps1 -PostReleaseOnly`. It holds everything added
+    *since* the floor.
+
+  Both are needed, and the floor alone is the weaker half of the promise, not the
+  whole of it. A method that first ships in `2.2.0` is absent from `2.0.0`, so a
+  `2.2.1` that deletes it diffs clean against the floor — while an application compiled
+  against `2.2.0` gets `NoSuchMethodError`. The floor catches a regression against the
+  GA surface; the previous-release pin catches a regression against everything added
+  after it. `VersionConsistencyGuardTest` derives both pins rather than trusting them —
+  the floor from the module's own version (`<major>.0.0`), the previous pin from the
+  CHANGELOG (the newest dated release of that major older than the working version) —
+  and also asserts both `<execution>`s are still in the pom, so neither a pin the cut
+  forgot to move nor a deleted execution can widen the gap while CI stays green.
 - **What fails the build:** any binary-incompatible change to the public surface
-  against the baseline — a removed or less-accessible public method/field/type, a
+  against either baseline — a removed or less-accessible public method/field/type, a
   changed signature, and so on. `@Internal` packages (`com.demcha.compose.engine.*`,
   `com.demcha.compose.document.layout.*` and its render-handoff payload records) are
-  excluded; they carry no compatibility promise (§ 1). Source-only incompatibilities
-  (e.g. adding a default method to an interface) are reported but do not fail, pending
-  a finalized 2.x source-compatibility policy.
-- **Activity window:** the gate compares the working version against the baseline, so
-  it is a no-op only when the two are equal — the `2.0.0` release commit itself — and
-  active for every `-SNAPSHOT` development cycle across the 2.x line that follows.
+  excluded; they carry no compatibility promise (§ 1). The templates module has no
+  Internal package tree — every `templates.*` package is Stable — so its gate excludes
+  only elements carrying the per-element `@Internal` marker. Source-only
+  incompatibilities (e.g. adding a default method to an interface) are reported but do
+  not fail, pending a finalized 2.x source-compatibility policy.
+- **Activity window:** both diffs run on every build of the line — the previous pin
+  names the release *before* the working version, so it never compares a jar with
+  itself, and the floor is a no-op only on the `2.0.0` release commit. The pin moves
+  in `-PostReleaseOnly`, after the cut, because that is when the release it names is
+  on Central.
+- **At a major boundary the gate stands down, by construction.** Both pins stay inside
+  the working major. Opening `3.0.0-SNAPSHOT` sets the floor to `3.0.0` and leaves the
+  previous pin with no 3.x release to name, so it falls back to the floor: neither
+  version is published, both executions skip (`ignoreMissingOldVersion`), and the 3.0
+  cycle is free to make the breaks a major is for. Pinning back to `2.x` instead would
+  fail the build on every intentional break. Enforcement resumes at the first
+  `-PostReleaseOnly` of the new major, once `3.0.0` is on Central. This is the
+  report-only posture the 2.0 transition ran under, without a hand-edited pom.
+- **Where it runs:** the PR-time `Binary Compatibility` CI job (when the core or
+  templates sources or pom changed), `scripts/cut-release.ps1` step 5b before the tag
+  is cut, and the publish workflow on the tagged commit.
 
 During the 2.0 major transition the gate ran report-only (the major intentionally
 broke 1.x binary compatibility); it enforces from the `2.0.0` baseline forward.
diff --git a/docs/contributing/release-process.md b/docs/contributing/release-process.md
index d67ac1d5..cea85269 100644
--- a/docs/contributing/release-process.md
+++ b/docs/contributing/release-process.md
@@ -94,7 +94,7 @@ Running `pwsh ./scripts/cut-release.ps1 -Version <X.Y.Z>` performs:
    The compatibility check itself runs in **Step 0**, before any file is written, so a cut that cannot describe itself refuses with a clean tree rather than after every pom has moved.
 4. **Switch ShowcaseMetadata GH_BASE** from `/blob/develop` to `/blob/v<X.Y.Z>` and regenerate `web/examples.json`.
 5. **`mvnw verify`** — full reactor sanity build (the script auto-detects the layout by the presence of `core/pom.xml`, scoping to `-pl .` on the 1.x line). Skip with `-SkipVerify` only if you just ran it.
-5b. **Binary-compatibility gate** — `mvnw -P japicmp verify -pl :graph-compose-core` against the published baseline (2.0 module layout only). Fails the cut if the tagged code breaks binary compatibility of the `graph-compose-core` public API (the japicmp profile lives only in `core/pom.xml`) with the baseline — a second line of defence independent of the PR-time CI japicmp job, which a direct-to-branch push could bypass. Skipped by `-SkipVerify`.
+5b. **Binary-compatibility gate** — `mvnw -P japicmp verify -pl :graph-compose-core,:graph-compose-templates` against the published baselines (2.0 module layout only). Fails the cut if the tagged code breaks binary compatibility of the `graph-compose-core` or `graph-compose-templates` public API with either baseline — each module's `japicmp` profile pins two in its own pom: `japicmp.baseline.floor` (the major's first release, holding the GA surface) and `japicmp.baseline.previous` (the latest release, holding everything added since). A second line of defence independent of the PR-time CI japicmp job, which a direct-to-branch push could bypass. Skipped by `-SkipVerify`.
 6. **Commit** as `Release v<X.Y.Z>`. Staging is an explicit allow-list, not `git add -A`. It covers the 13 train poms, `README.md`, `ROADMAP.md`, and the seven per-module READMEs (`core`, `render-pdf`, `render-docx`, `render-pptx`, `templates`, `testing`, `wrapper`, `bundle`), `CHANGELOG.md`, `ShowcaseMetadata.java`, `web/examples.json`, `web/index.html`, `web/showcase/`, and the regenerated `assets/readme/repository_showcase_render.png`. `examples/README.md` and every other doc are NOT touched by the script — fix those pre-release.
 7. **Annotated tag** `v<X.Y.Z>` (`git tag -a -m "Release v<X.Y.Z>"`).
 8. **Push** `develop` and the tag to `origin` (skip with `-SkipPush`).
@@ -127,7 +127,7 @@ Run within 1 hour of the tag push. Independent steps can run in parallel.
 5. **Smoke-test the install snippet** — minimal POM in `$env:TEMP`, `mvn dependency:resolve` against the snippet copy-pasted from README, expect 0 exit.
 6. **Re-run all examples against the published artifact** — `./mvnw -f examples/pom.xml clean package` followed by `exec:java -Dexec.mainClass=com.demcha.examples.GenerateAllExamples`. Expect one `Generated:` line per example.
 6b. **Run the external release-smoke suite** — once Central has indexed the train, dispatch the **Release Smoke** workflow ([`.github/workflows/release-smoke.yml`](../../.github/workflows/release-smoke.yml)) with `version=<target>`, or run `bash scripts/release-smoke/run.sh --version <target>`. This resolves every published coordinate from Maven Central in a clean, GraphCompose-evicted repository (no reactor / local install) and exercises the documented consumer scenarios — the wrapper renders PDF, `graph-compose-core` alone throws `MissingBackendException`, core+render-pdf renders, and templates/testing/bundle perform their roles. It is the authoritative "a real user can install and use this" check; the minimal step-5 snippet resolve is a faster subset. (Release smoke tests **published** artifacts, so it necessarily runs post-publish, not pre-tag.)
-7. **Open the next development line** — `pwsh ./scripts/cut-release.ps1 -PostReleaseOnly`. This bumps the train poms to the next patch `-SNAPSHOT` (so develop builds are distinguishable from the release and the japicmp gate compares against it) **and** restores linkable "View Code" buttons by flipping ShowcaseMetadata back to `/blob/develop`. The README/showcase install snippets stay on the just-published release.
+7. **Open the next development line** — `pwsh ./scripts/cut-release.ps1 -PostReleaseOnly`. This bumps the train poms to the next patch `-SNAPSHOT` (so develop builds are distinguishable from the release and the japicmp gate compares against it), **moves `japicmp.baseline.previous` in `core/pom.xml` and `templates/pom.xml` to the version just published** (the release is on Central by now, and until the pin moves, everything that release added can be removed with the gate green — `VersionConsistencyGuardTest` fails the build if it is left behind), **and** restores linkable "View Code" buttons by flipping ShowcaseMetadata back to `/blob/develop`. The README/showcase install snippets stay on the just-published release.
 8. **GitHub Release — automated.** Pushing the `v<target>` tag triggers [`.github/workflows/release.yml`](../../.github/workflows/release.yml): it re-runs `./mvnw clean verify` over the whole reactor against the tagged commit, then creates the Release with that version's CHANGELOG section as the body (hyphenated tags like `v1.7.0-rc.1` ship as pre-releases; the step is idempotent — it edits the notes if the Release already exists). The workflow titles it `GraphCompose v<target>`; for a **minor** release, edit the title to add the codename (`v1.4`=cinematic, `v1.5`=intuitive, `v1.6`=expressive; patches drop it). Create the Release by hand (`gh release create v<target> --notes-file <CHANGELOG section>`) only if the workflow is unavailable.
 9. **Maven Central publish — automated (from v1.6.6).** The same `v<target>` tag push triggers [`.github/workflows/publish.yml`](../../.github/workflows/publish.yml): it re-runs `mvnw verify` at the tagged commit, signs each module's artefacts (main / sources / javadoc / pom &mdash; the `graph-compose` wrapper has no sources of its own, so it publishes no sources jar) with the repo's GPG key, and uploads to Maven Central via the `central-publishing-maven-plugin`. Hyphenated tags (`-rc`, `-alpha`, `-beta`, `-snapshot`) are skipped — those go only to the GitHub Release pre-release surface. `autoPublish=false` in the plugin config means the artefact lands in the Central validation queue; the maintainer flips the switch on [central.sonatype.com](https://central.sonatype.com) for the first publish, then can opt into auto-release in a follow-up. Verify via `mvn dependency:get -DgroupId=io.github.demchaav -DartifactId=graph-compose -Dversion=<target>` once the artifact appears (usually 5–15 minutes after the workflow turns green).
 10. **Optional**: GitHub Discussions announcement (mirror the prior release's style; close with *"author intent, not coordinates"*), LinkedIn post, r/java post.
diff --git a/docs/roadmaps/post-2.0-engineering.md b/docs/roadmaps/post-2.0-engineering.md
index 24808c1e..e04ba099 100644
--- a/docs/roadmaps/post-2.0-engineering.md
+++ b/docs/roadmaps/post-2.0-engineering.md
@@ -108,8 +108,13 @@ exercise it. Report-only; thresholds can follow after a baseline read.
 
 ### Per-module binary-compatibility baselines
 
-`japicmp` runs report-only on the 2.0 line — the major intentionally breaks
-binary compatibility. Once the 2.0 GA artifacts are published, the gate should
-switch to per-module baselines pinned at the GA release and break-on-incompatible
-mode, so each published module's public surface is protected from that point on.
-**Status: Deferred (post-GA).**
+`japicmp` ran report-only through the 2.0 major — the major intentionally broke
+binary compatibility. With the 2.0.0 GA artifacts on Central the gate switched to
+per-module baselines pinned at the major's floor (2.0.0) in break-on-incompatible
+mode: `graph-compose-core` first, `graph-compose-templates` since 2.2.1 — each
+module's `japicmp` profile lives in its own pom and runs in the PR-time
+`Binary Compatibility` job, in `cut-release.ps1` step 5b, and in the publish
+workflow. The remaining published modules (`render-pdf` / `render-docx` /
+`render-pptx` / `testing` / `wrapper`) join once each has a documented
+Stable / Internal split to gate against.
+**Status: Done for core + templates; other modules open.**
diff --git a/scripts/cut-release.ps1 b/scripts/cut-release.ps1
index 6b5e55cc..4837f925 100644
--- a/scripts/cut-release.ps1
+++ b/scripts/cut-release.ps1
@@ -223,6 +223,44 @@ function Update-PomVersion($pomPath, $newVersion) {
     }
 }
 
+function Update-JapicmpPreviousBaseline($pomPath, $releasedVersion) {
+    # Moves <japicmp.baseline.previous> — the release the binary-compatibility gate
+    # diffs against alongside the major floor. The floor (<japicmp.baseline.floor>)
+    # holds the GA surface and only moves at a major; the previous pin holds every
+    # public element added SINCE the floor, and it does that only while it names the
+    # release actually published last. Left behind, the gate keeps comparing against
+    # an older release and everything added in the release just cut becomes freely
+    # removable with CI green — the exact NoSuchMethodError this pair exists to stop.
+    #
+    # Runs in -PostReleaseOnly, next to the SNAPSHOT bump: on the release commit
+    # itself the just-cut version is not on Central yet, so the pin must stay one
+    # release back until the publish workflow has uploaded it. Idempotent, and held
+    # to the CHANGELOG by VersionConsistencyGuardTest.
+    if (-not (Test-Path $pomPath)) {
+        Note "skip (no file): $pomPath"
+        return $false
+    }
+    $content = [System.IO.File]::ReadAllText($pomPath)
+    $previousRegex = [regex]'<japicmp\.baseline\.previous>[\w\.\-]+</japicmp\.baseline\.previous>'
+    $match = $previousRegex.Match($content)
+    if (-not $match.Success) {
+        Note "no <japicmp.baseline.previous> in $pomPath — nothing to move"
+        return $false
+    }
+    $new = "<japicmp.baseline.previous>$releasedVersion</japicmp.baseline.previous>"
+    if ($match.Value -eq $new) {
+        Note "japicmp previous baseline already $releasedVersion in $pomPath"
+        return $false
+    }
+    if ($DryRun) {
+        Write-Host "    [DRY RUN] japicmp previous baseline: $pomPath -> $releasedVersion" -ForegroundColor Yellow
+        return $true
+    }
+    [System.IO.File]::WriteAllText($pomPath, $previousRegex.Replace($content, $new, 1))
+    Note "japicmp previous baseline: $pomPath -> $releasedVersion"
+    return $true
+}
+
 function Update-AssetVersion($pomPath, $newVersion) {
     # Moves <graphcompose.examples.assetVersion> — the version the committed previews
     # under assets/readme were rendered at. CommittedAssetDriftTest renders at it to
@@ -1170,8 +1208,22 @@ if ($PostReleaseOnly) {
                     $bumpedPoms += $pom
                 }
             }
+
+            # The release just cut is now the newest published one, so it becomes the
+            # japicmp previous-release baseline for the cycle that opens here. Only the
+            # two gated modules carry the pin; a module without it is skipped.
+            Step "3a" "Move the japicmp previous-release baseline to $currentVersion"
+            foreach ($pom in @('core/pom.xml', 'templates/pom.xml')) {
+                if (Update-JapicmpPreviousBaseline (Join-Path $repoRoot $pom) $currentVersion) {
+                    if ($bumpedPoms -notcontains $pom) { $bumpedPoms += $pom }
+                }
+            }
         } else {
-            Step 3 "Skipped SNAPSHOT bump (no core/pom.xml, or the current version is not a final X.Y.Z release)"
+            # Same condition governs the japicmp previous-release pin: it may only be
+            # moved onto a final X.Y.Z, never onto a -SNAPSHOT or an -rc (neither is on
+            # Central for the gate to resolve). A re-run over already-bumped poms lands
+            # here, and VersionConsistencyGuardTest is what catches a pin that never moved.
+            Step 3 "Skipped SNAPSHOT bump + japicmp baseline move (no core/pom.xml, or the current version is not a final X.Y.Z release)"
         }
 
         # Validate the bump BEFORE committing or pushing: a reactor `validate` resolves
@@ -1209,7 +1261,7 @@ if ($PostReleaseOnly) {
         $filesToCommit += $bumpedPoms
         if ($filesToCommit.Count -gt 0) {
             $parts = @()
-            if ($bumpedPoms.Count -gt 0) { $parts += "open $nextSnapshot" }
+            if ($bumpedPoms.Count -gt 0) { $parts += "open $nextSnapshot + japicmp baseline $currentVersion" }
             if ($showcaseChanged -or $DryRun) { $parts += "restore /blob/$Branch showcase links" }
             $msg = "chore(release): " + ($parts -join ' + ')
             Step 4 "Commit"
@@ -1489,15 +1541,20 @@ try {
 
     if (-not $SkipVerify) {
         Step "5b" "Binary-compatibility gate (japicmp vs the published baseline)"
-        # Confirm the graph-compose-core public API stays binary-compatible with the
-        # japicmp baseline BEFORE the tag is cut — independent of the PR-time CI japicmp
-        # job, which a direct-to-branch push could bypass. 2.0 module layout only (core/
-        # present); the legacy 1.x single-artifact tree has no such gate. Precondition:
-        # the baseline (japicmp.baseline in core/pom.xml) must already be on Central — so
-        # this gate is meaningful from 2.0.1 onward (vs the published 2.0.0), not on the
-        # first-of-a-major cut that publishes the baseline itself.
+        # Confirm the graph-compose-core AND graph-compose-templates public APIs stay
+        # binary-compatible with their japicmp baselines BEFORE the tag is cut —
+        # independent of the PR-time CI japicmp job, which a direct-to-branch push could
+        # bypass. 2.0 module layout only (core/ present); the legacy 1.x single-artifact
+        # tree has no such gate. Precondition: both baselines of each module
+        # (japicmp.baseline.floor / .previous in core/pom.xml and templates/pom.xml)
+        # must already be on Central — so this gate is meaningful from 2.0.1 onward
+        # (vs the published 2.0.0), not on the first-of-a-major cut that publishes the
+        # floor itself. The previous pin still names the release before this one; Step
+        # 3a of -PostReleaseOnly moves it forward once this cut is published. One reactor
+        # invocation covers both: the reactor orders core before templates, so
+        # templates compiles against the freshly-built core.
         if (Test-Path (Join-Path $repoRoot 'core/pom.xml')) {
-            $japicmpArgs = @('-B', '-ntp', '-P', 'japicmp', '-Dmaven.test.skip=true', '-Djacoco.skip=true', 'verify', '-pl', ':graph-compose-core')
+            $japicmpArgs = @('-B', '-ntp', '-P', 'japicmp', '-Dmaven.test.skip=true', '-Djacoco.skip=true', 'verify', '-pl', ':graph-compose-core,:graph-compose-templates')
             if ($DryRun) {
                 Write-Host "    [DRY RUN] $mvnw $($japicmpArgs -join ' ')" -ForegroundColor Yellow
             } else {
diff --git a/templates/pom.xml b/templates/pom.xml
index 9fb51273..bb95bf1e 100644
--- a/templates/pom.xml
+++ b/templates/pom.xml
@@ -73,6 +73,21 @@
 
         <!-- See the engine pom: opted in via -Dgpg.skip=false on the publish workflow. -->
         <gpg.skip>true</gpg.skip>
+
+        <!-- Binary compatibility baselines (japicmp profile). Same plugin version as
+             the engine pom (VersionConsistencyGuardTest holds the two in lockstep).
+             Two published graph-compose-templates baselines, diffed in two executions:
+             the floor of the current major (2.0.0 — the first graph-compose-templates
+             on Central) holds the GA surface; the previous (latest published) release
+             holds everything added since — see the engine pom for why the floor alone
+             leaves post-GA additions unprotected. The previous pin moves to the
+             just-published version in `cut-release.ps1 -PostReleaseOnly` and is held
+             to the CHANGELOG by VersionConsistencyGuardTest. docs/api-stability.md
+             lists every templates.* package as Stable, so the gate holds each 2.x
+             build binary-compatible with every 2.x release before it. -->
+        <japicmp.version>0.26.1</japicmp.version>
+        <japicmp.baseline.floor>2.0.0</japicmp.baseline.floor>
+        <japicmp.baseline.previous>2.2.0</japicmp.baseline.previous>
     </properties>
 
     <dependencies>
@@ -262,5 +277,88 @@
                 </plugins>
             </build>
         </profile>
+
+        <!--
+            Binary-compatibility gate. Activated with `-P japicmp`. Mirrors the
+            engine pom's profile for this module: resolves the two baseline
+            graph-compose-templates artifacts pinned by japicmp.baseline.floor /
+            japicmp.baseline.previous from Maven Central and diffs the freshly-built
+            jar against each in its own execution (major floor holds the GA surface,
+            previous release holds everything added since). Fails the build on any
+            binary-incompatible modification to the public surface;
+            source-incompatible changes are reported but do not fail (same phased
+            policy as the engine). This module has no @Internal package tree —
+            every templates.* package is Stable per docs/api-stability.md — so
+            only the per-element @Internal marker is excluded.
+        -->
+        <profile>
+            <id>japicmp</id>
+            <build>
+                <plugins>
+                    <plugin>
+                        <groupId>com.github.siom79.japicmp</groupId>
+                        <artifactId>japicmp-maven-plugin</artifactId>
+                        <version>${japicmp.version}</version>
+                        <executions>
+                            <execution>
+                                <id>japicmp-against-major-floor</id>
+                                <phase>verify</phase>
+                                <goals>
+                                    <goal>cmp</goal>
+                                </goals>
+                                <configuration>
+                                    <oldVersion>
+                                        <dependency>
+                                            <groupId>io.github.demchaav</groupId>
+                                            <artifactId>graph-compose-templates</artifactId>
+                                            <version>${japicmp.baseline.floor}</version>
+                                        </dependency>
+                                    </oldVersion>
+                                </configuration>
+                            </execution>
+                            <execution>
+                                <id>japicmp-against-previous-release</id>
+                                <phase>verify</phase>
+                                <goals>
+                                    <goal>cmp</goal>
+                                </goals>
+                                <configuration>
+                                    <oldVersion>
+                                        <dependency>
+                                            <groupId>io.github.demchaav</groupId>
+                                            <artifactId>graph-compose-templates</artifactId>
+                                            <version>${japicmp.baseline.previous}</version>
+                                        </dependency>
+                                    </oldVersion>
+                                </configuration>
+                            </execution>
+                        </executions>
+                        <configuration>
+                            <newVersion>
+                                <file>
+                                    <path>${project.build.directory}/${project.build.finalName}.jar</path>
+                                </file>
+                            </newVersion>
+                            <parameter>
+                                <!-- See the engine pom: an unpublished baseline skips its
+                                     execution, which is the pre-GA window of a new major
+                                     and nothing else. The exact pin values are guarded by
+                                     VersionConsistencyGuardTest. -->
+                                <ignoreMissingOldVersion>true</ignoreMissingOldVersion>
+                                <onlyModified>true</onlyModified>
+                                <breakBuildOnBinaryIncompatibleModifications>true</breakBuildOnBinaryIncompatibleModifications>
+                                <breakBuildOnSourceIncompatibleModifications>false</breakBuildOnSourceIncompatibleModifications>
+                                <includeSynthetic>false</includeSynthetic>
+                                <reportOnlyFilename>true</reportOnlyFilename>
+                                <skipPomModules>true</skipPomModules>
+                                <excludes>
+                                    <exclude>@com.demcha.compose.document.api.Internal</exclude>
+                                </excludes>
+                            </parameter>
+                        </configuration>
+                    </plugin>
+                </plugins>
+            </build>
+        </profile>
     </profiles>
 </project>