instructions/dev: publish-and-ci - CI-Wartezeiten auf gemessene Laufzeiten (ein Runner, Jobs nacheinander, ca. 12 Min; Konverter ca. 22), Aufgeben nach 25/35 statt 15 Min; stack-build verweist auf die Grenze statt sie zu wiederholen; 10.1.0-beta.18

Files changed:
- CHANGES.md
- VERSION
- instructions/dev/publish-and-ci.md
- instructions/dev/stack-build/SKILL.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.17 - 2026-10-16 - export run/upload collect: Fehlertexte im Kommandovertrag nennen die Backup-Ordner statt backup.target und die Laufzeit-Ablehnung von Backup- und Exportdaten (#216)
+## 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
 
 **Author:** Torben Nehmer
 
@@ -39,6 +39,7 @@ place only: `instructions/dev/version-parts.md` § The candidate model.
 - wiki-ingest step 1 sends the session to read-page-images.md before the discussion, so up to the threshold the page images are no question for the user
 - 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
 <!-- /wikitool:bumps -->
 
 ### Konverter-Tests gegen echte Dokumente im privaten Repository

VERSION

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

instructions/dev/publish-and-ci.md

@@ -38,17 +38,21 @@ 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.** The push-triggered runs take about
+3. **Wait for CI on the published commit, this way.** One runner serves the repository, so the
-   **4 minutes**; a push that moved `VERSION` to a suffix-free release adds about **1 minute**
+   jobs of a push run **one after another**, never side by side: CI's `verify` job (about
-   for the release job.
+   **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.
 
    - 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
      `publish`, to get their ids. **Never anonymously via `curl`:** Gitea answers the Actions
      API with `401 token is required` even for this public repo.
-   - Check again after about 4 minutes (5 with a release job), then once a minute.
+   - Check again after about 11 minutes, then every 2 minutes.
-   - **Give up after 15 minutes** and hand the open runs to the user by id and link, rather than
+   - **Give up after 25 minutes** - twice the usual time, so a slow day is not mistaken for a
-     waiting on.
+     hang - and hand the open runs to the user by id and link, rather than waiting on.
    - Any shell loop that polls instead must **end on the first non-2xx status or missing field**
      and print the raw response. A loop that treats an error as "not finished yet" never ends;
      that happened in the #139 close-out.
@@ -59,9 +63,10 @@ formality after it - which is why waiting for it belongs to the phase that wrote
    surface - `tools/chemenu/filters/`, `tools/chemenu/commands/raw/derive.py` or `accept.py`,
    `tools/chemenu/tests/test_raw_derive*.py`, `tools/chemenu/tests/binary_formats.py`,
    `tools/requirements.txt` or `.gitea/workflows/converters.yml` - the `Converters` workflow
-   (`converters.yml`) starts by itself beside CI and derives the real documents of the private
+   (`converters.yml`) starts by itself with CI and derives the real documents of the private
-   test corpus. It takes longer than CI (allow **10 minutes**); wait for it the same way, with
+   test corpus. Deriving the corpus takes about **10 minutes** on top of CI, on the same
-   the same give-up time, and count a red run like a red CI run (step 4). Start it by hand
+   runner and after it, so the last run finishes about **22 minutes** after the push; give up
+   after **35 minutes** instead of 25, and count a red run like a red CI run (step 4). Start it by hand
    (`actions_run_write`, `dispatch_workflow` on `main`) when only the private repository changed
    or when the commit reaches the converters only indirectly. A release without suffix runs the
    same steps as the first job of `release.yml`, which the release waits for.

instructions/dev/stack-build/SKILL.md

@@ -112,7 +112,7 @@ session, or a fresh one after `/clear` - assume the second, and work from the bo
   answer as a design change (step 3's first fixed point).
 - **The package needs several build sessions?** Each one ends with the body current and its own
   changelog comment; the phase ends once, at the green run after the last publish.
-- **CI gave up after 15 minutes, or is red for a reason outside this change?** Hand the open or
+- **CI hit the give-up time in `instructions/dev/publish-and-ci.md` step 3, or is red for a reason outside this change?** Hand the open or
   failing runs to the operator by id and link. The phase is not over, and the closing line in
   step 7 is not given.