instructions/dev: publish-and-ci - Runner fährt derzeit keine parallelen Jobs; Wartezeiten neu messen, sobald er es tut; 10.1.0-beta.19

Files changed:
- CHANGES.md
- VERSION
- instructions/dev/publish-and-ci.md

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

CHANGES.md

@@ -14,7 +14,7 @@ place only: `instructions/dev/version-parts.md` § The candidate model.
 
 ---
 
-## 10.1.0-beta.18 - 2026-10-16 - publish-and-ci: CI-Wartezeiten auf gemessene Laufzeiten gesetzt - ein Runner, Jobs nacheinander, ca. 12 Min bis zum letzten grünen Lauf (Konverter ca. 22), Aufgeben nach 25 (35) statt 15 Min
+## 10.1.0-beta.19 - 2026-10-16 - publish-and-ci: hält fest, dass der Runner derzeit keine parallelen Jobs fährt, und dass die Wartezeiten neu zu messen sind, sobald er es tut
 
 **Author:** Torben Nehmer
 
@@ -40,6 +40,7 @@ place only: `instructions/dev/version-parts.md` § The candidate model.
 - gates.md/session-setup.md: die Regel für eine neue Session-Id steht nur noch in gates.md, mit dem ausdrücklich gewünschten weiteren Ingest-Lauf als zweiter Grenze neben plan.md (#219)
 - export run/upload collect: Fehlertexte im Kommandovertrag nennen die Backup-Ordner statt backup.target und die Laufzeit-Ablehnung von Backup- und Exportdaten (#216)
 - publish-and-ci: CI-Wartezeiten auf gemessene Laufzeiten gesetzt - ein Runner, Jobs nacheinander, ca. 12 Min bis zum letzten grünen Lauf (Konverter ca. 22), Aufgeben nach 25 (35) statt 15 Min
+- publish-and-ci: hält fest, dass der Runner derzeit keine parallelen Jobs fährt, und dass die Wartezeiten neu zu messen sind, sobald er es tut
 <!-- /wikitool:bumps -->
 
 ### Konverter-Tests gegen echte Dokumente im privaten Repository

VERSION

@@ -1 +1 @@
-10.1.0-beta.18
+10.1.0-beta.19

instructions/dev/publish-and-ci.md

@@ -38,13 +38,15 @@ formality after it - which is why waiting for it belongs to the phase that wrote
    **CI does the tagging** - a session never creates a tag, which is what keeps AGENTS.md
    invariant 5 intact.
 
-3. **Wait for CI on the published commit, this way.** One runner serves the repository, so the
+3. **Wait for CI on the published commit, this way.** One runner serves the repository and it
-   jobs of a push run **one after another**, never side by side: CI's `verify` job (about
+   currently runs **no jobs in parallel**, so the jobs of a push run **one after another**: CI's `verify` job (about
    **8 minutes**) and `pwsh` job (about **3 minutes**) first, then the second run a push to
    `main` starts - `release.yml`, preceded by the `Converters` check - which waits `queued`
    until CI is done and then takes about **1 minute**. From the push to the last green run that
    is about **12 minutes** (measured 10.5 to 13 minutes, October 2026); a second run still
-   `queued` while CI works is the runner's order, not a hang.
+   `queued` while CI works is the runner's order, not a hang. The times below rest on that
+   setup (`ENVIRONMENT.md` § CI records it); once the runner takes parallel jobs, measure them
+   again and rewrite them here.
 
    - Read the runs for the published commit's SHA through the authenticated Gitea connection
      `ENVIRONMENT.md` lists (the Gitea MCP's `actions_run_read`, `list_runs`), right after