From e25ebaa0bf825bc5b279b1b4653db100b293bde8 Mon Sep 17 00:00:00 2001
From: mhoennig <michael@hoennig.de>
Date: Sat, 29 Aug 2026 11:21:41 +0200
Subject: [PATCH] Release v0.9.19

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
---
 build.gradle.kts                           |  2 +-
 src/main/resources/templates/releases.html | 27 ++++++++++++++++++++++
 2 files changed, 28 insertions(+), 1 deletion(-)

diff --git a/build.gradle.kts b/build.gradle.kts
index b0cf80e..725bedc 100644
--- a/build.gradle.kts
+++ b/build.gradle.kts
@@ -12,7 +12,7 @@ group = "de.hoennig"
 // bump at least the patch version for every deployment — and only then, not per commit —
 // so the UI footer (BuildProperties), --version and the release notes identify what is
 // actually running; a deployment bundles whatever was committed since the last one
-version = "0.9.18"
+version = "0.9.19"
 
 java {
     toolchain {
diff --git a/src/main/resources/templates/releases.html b/src/main/resources/templates/releases.html
index 6ec2c1e..35d42da 100644
--- a/src/main/resources/templates/releases.html
+++ b/src/main/resources/templates/releases.html
@@ -7,6 +7,33 @@
     <div th:replace="~{fragments :: nav(${view})}"></div>
     <div class="panel release-notes">
 
+        <h2>v0.9.19 <span class="muted">— 2026-08-29</span></h2>
+        <ul>
+            <li>A build definition now describes its build completely: <code>requirePullRequest</code>
+                and the whole <code>docker</code> section, the sandbox policy included, live in
+                <code>builds.&lt;name&gt;</code>. <code>builds.default</code> is the base every other
+                definition inherits its settings from — never its trigger, because
+                <code>onPush</code>, <code>atTimes</code>, <code>branches</code>, and
+                <code>activeWithin</code> say when and where that one build runs.</li>
+            <li>The per-branch <code>branches</code> section is thereby superseded and will be
+                removed. It is still read, but only while nothing defines a build at all: as soon as
+                one real definition exists — a leftover <code>builds.maxConcurrent</code> is not one
+                — <code>branches</code> is ignored completely and a warning names it. Either or,
+                never both: two half-answers to what a build runs would pull against each other.</li>
+            <li><code>requirePullRequest</code>, <code>docker.enabled</code>, and
+                <code>docker.network</code> stay pinned to the host, wherever a branch writes them.
+                Since the inheritance is applied after all configuration layers are merged, a build
+                a branch invents and the host has never heard of still inherits the host's
+                <code>builds.default</code> — it cannot reach a native build by defining a new
+                job.</li>
+            <li><strong>Fixed:</strong> the archived artifact directories came from the plain branch
+                settings, so a build definition adding its own <code>artifactDirs</code> — a
+                release job storing <code>build/libs</code>, say — never had them stored.</li>
+            <li><strong>Fixed:</strong> the build definitions of a branch were cached by its head
+                commit alone, so an edited machine or project configuration only took effect once
+                that branch moved. On a quiet branch, a new scheduled job never started at all.</li>
+        </ul>
+
         <h2>v0.9.18 <span class="muted">— 2026-08-29</span></h2>
         <ul>
             <li>A configuration file can declare which GitTally it is written for, so a version