From 41e86481e2afc072c23f2890e19315f5a44b3453 Mon Sep 17 00:00:00 2001 From: Joseph Doherty Date: Fri, 7 Aug 2026 09:12:00 -0400 Subject: [PATCH] docs(tst-30): second runner gitea-runner-2 live; close operator action --- .../2026-07-12/remediation/00-tracking.md | 3 ++- .../remediation/60-testing-docs-gaps.md | 4 +++- .../90-candidate-findings-next-cycle.md | 2 +- docs/runbooks/TST-30-second-ci-runner.md | 19 +++++++++++++++++++ 4 files changed, 25 insertions(+), 3 deletions(-) diff --git a/archreview/2026-07-12/remediation/00-tracking.md b/archreview/2026-07-12/remediation/00-tracking.md index b0024f5..a7c9fde 100644 --- a/archreview/2026-07-12/remediation/00-tracking.md +++ b/archreview/2026-07-12/remediation/00-tracking.md @@ -131,7 +131,7 @@ Full design + implementation for each row lives in the linked domain doc under i | TST-27 | Medium | P1 | S | — | Done | `ShowTagValues` config row still says "Reserved" after SEC-25 made the flag live | | TST-28 | Low | P2 | S | relates IPC-02 (old) | Done | Gateway-side `max_frame_bytes` handshake untested in the CI-run suite | | TST-29 | Low | P2 | S | — | Done | Retire `oldtasks.md` (fold Phase-5 governance into DesignDecisions.md); delete root artifacts | -| TST-30 | Low | P2 | M | — | Done (doc half; runner registration operator-pending per runbook) | Single shared Gitea runner is a CI throughput/availability bottleneck (cross-repo contention, no run cancel/delete API) | +| TST-30 | Low | P2 | M | — | Done | Single shared Gitea runner is a CI throughput/availability bottleneck (cross-repo contention, no run cancel/delete API) | ## Cross-cutting clusters @@ -182,3 +182,4 @@ Sequence these together rather than piecemeal — several are one change set spa | 2026-08-07 | **TST-30 → `Done` (doc half); runner registration operator-pending** (branch `fix/tst-30-runner-docs`). Doc + operator-runbook task only — no source/tests, per the finding's P2 scope. `docs/GatewayTesting.md`'s Continuous Integration section gained a "Runner capacity is shared and finite" subsection: the co-located `gitea-runner` on `10.100.0.35` runs `maxParallel=1` and is registered at the Gitea **instance** level (`GET /repos/dohertj2/mxaccessgw/actions/runners` → `total_count: 0`), so it interleaves with `dohertj2/lmxopcua` and every job in a run serializes — ~20–30 minute queue depth was observed under cross-repo contention during TST-25 acceptance. Documented that Gitea 1.26 exposes no run cancel/delete (`POST .../cancel` → 404, `DELETE` → 400), so a superseded or hung run holds its slot to completion. The existing "windev tier down" degraded-mode paragraph now also names "runner contended" as a reason to use the bypass — `CI_SHA= scripts/ci/run-windev-ci.sh ` or the manual windev worktree flow — generalizing it per the finding's design note (was tier-down-only). New operator runbook `docs/runbooks/TST-30-second-ci-runner.md`: implementation step 1 (register a second `act_runner` on `10.100.0.35`), preference-ordered per the design — (a) second instance with the same `container.network: traefik` config, **recommended**; (b) dedicated labelled runner + `ci.yml` `runs-on` gate, escalation only; (c) runner on windev, **rejected** (loses `gitea:3000` resolution TST-03 depends on) — plus the verification checklist (concurrent back-to-back pushes, `GET .../actions/runners` shows ≥2) and a reminder the no-cancel reality persists regardless of runner count. The optional workflow-level `concurrency` group (design step 3) is documented in the runbook as unverified, framed explicitly as "verify this Gitea deployment honors it before relying on it," and left **unimplemented** in `.gitea/workflows/ci.yml` — no `runs-on` or workflow edits were made, consistent with the task scoping the actual runner registration as operator/infra work outside this repo's tree. Tracking: both registers' TST-30 rows and this row. Verification (doc-only, no build required): `grep -n 'maxParallel\|shared\|cancel' docs/GatewayTesting.md` shows the new prose (the "Runner capacity is shared and finite" subsection, the no-cancel API detail, and the degraded-mode "runner contended" generalization — plus pre-existing unrelated `shared` hits in the LDAP section); `docs/runbooks/TST-30-second-ci-runner.md` exists. | | 2026-08-07 | **CLI-39 → `Done`** (branch `fix/cli-39-version-train`). The last client task in the P1 release train — lands after CLI-35/36/37/38/40/41/44/45 so the next publish carries the conformant behavior, not the pre-remediation API. Bumped all five client version constants off the already-published 0.1.2: Rust `Cargo.toml` `[package]` + `[workspace.package]` → 0.2.0 (`crates/mxgw-cli` inherits via `version.workspace = true`; `CLIENT_VERSION` already derived via `env!("CARGO_PKG_VERSION")` from CLI-29, no separate edit needed); Python `pyproject.toml` + `version.py` → 0.2.0, plus a new `test_version_matches_pyproject_toml` (`clients/python/tests/test_cli.py`) that parses `pyproject.toml` with `tomllib` and asserts `__version__` matches it — closes the CLI-26 residual (the old test only checked self-consistency against `__version__`, so the two literals could still drift from each other undetected); Go `mxgateway/version.go` `ClientVersion` → 0.2.0; .NET `ZB.MOM.WW.MxGateway.Client.csproj` `` → 0.2.0. **Java is the one exception, landed at 0.2.1, not 0.2.0**: queried the live Gitea package API (`GET /api/v1/packages/dohertj2/maven/com.zb.mom.ww.mxgateway:zb-mom-ww-mxgateway-client/0.2.0` — reachable and credentialed in this environment) and confirmed Java 0.2.0 was already published on 2026-06-26, before the CLI-37/38/40/41 conformance fixes changed the client's observable behavior; reusing 0.2.0 for the now-conformant build would have labeled two different APIs identically, so `build.gradle`'s `subprojects { version = '0.2.1' }`, the hand-maintained `MxGatewayClientVersion.CLIENT_VERSION` constant, and the two `MxGatewayCliTests` version assertions all moved to 0.2.1 together (`clients/java/README.md`'s Maven dependency example updated to match — it had drifted to a stale `0.1.2` example). Confirmed via the same live API that Python (`pypi`) and Rust (`cargo`) had only ever reached 0.1.1 in the registry (0.1.2 was set in source but never actually published), while `nuget` (`ZB.MOM.WW.MxGateway.Client`/`.Contracts`) reached 0.1.2 — recorded as historical context in the new "Versioning" section of `docs/ClientPackaging.md` rather than left implicit. **Publish-pipeline guards:** `scripts/tag-go-module.ps1` gained the CLI-21 guard that was designed but never implemented — after semver validation it now reads `clients/go/mxgateway/version.go`'s `ClientVersion` and throws if it does not equal the requested tag version (stripped of `v`), before touching git. `scripts/pack-clients.ps1` gained a Gitea package-registry collision guard (`Test-GiteaPackageExists`/`Assert-GiteaPackageNotPublished`, hitting the documented `GET /api/v1/packages/{owner}/{type}/{name}/{version}` package API) wired into all four artifact-producing `-Publish` blocks (.NET nupkg identity parsed from the packed filename so both `Client` and `Contracts` are covered; Python from `pyproject.toml`; Rust from `Cargo.toml`; Java from `build.gradle`'s `group`+`version`, **required for a real check** since Gitea's Maven package identity is `groupId:artifactId`, not the bare artifact id — an early version of this guard used the bare id and would have silently never matched anything, caught by testing it live against the known-published 0.2.0 before landing); Go is unaffected (no artifact producer in this script; the version-match guard above is its collision protection). Every non-404 registry response (including a plain 401 from an unauthenticated call) is treated as "cannot verify" and aborts — the guard fails closed, never proceeds on ambiguity. **No `.proto` changes; no publish performed.** Docs same commit: `docs/ClientPackaging.md` gained a "Versioning" section (single-source-of-truth list per client, the bump-before-publish rule, the Java exception with evidence); `clients/dotnet/README.md`, `clients/rust/README.md`, `clients/go/README.md` (install example + `tag-go-module.ps1` example + guard behavior sentence), `clients/java/README.md` had their stale `0.1.1`/`0.1.2` example version strings updated to the new released numbers. **Verification** (macOS, all four non-Java languages against the live tree): `cargo check --workspace` clean (`zb-mom-ww-mxgateway-client v0.2.0`, `mxgw-cli v0.2.0`), `cargo test --workspace` version tests pass (`version_json_output_has_protocol_versions`); `python -m pytest` 164 passed / 1 skipped (was 163; the one new test); Go `gofmt -l .` clean, `go build ./...` clean, `go test ./...` ok; `dotnet build clients/dotnet/ZB.MOM.WW.MxGateway.Client.slnx` 0 warnings/0 errors, client tests 128 passed / 1 skipped (unchanged). `JAVA_HOME=/opt/homebrew/opt/openjdk@17 gradle test` BUILD SUCCESSFUL, CLI suite 51/51 passed including both version-string assertions now at `0.2.1`, **no generated-tree churn** to revert (no `.proto` changed). Script guards: `pwsh -NoProfile` dry-run of `tag-go-module.ps1` — mismatched version (`v1.2.3`) failed with the new guard message before touching git; matched version (`v0.2.0`) passed the guard and reached the pre-existing dirty-working-tree check (expected, uncommitted changes present) — proves the new check runs first and does not block a correct version. `pack-clients.ps1`'s guard functions were exercised directly (dot-sourced in isolation, no pack/publish side effects) against the **live** Gitea registry with real credentials already present in this environment (`GITEA_USERNAME`/`GITEA_TOKEN` from `~/.zshenv`): correctly refused on every known-published artifact (nuget Client 0.1.2, maven 0.2.0, pypi 0.1.1, cargo 0.1.1) and correctly passed on every unpublished target version (0.2.0/0.2.1 across all four). **No actual publish was attempted or performed** — the task explicitly forbids it, and the sandbox additionally refuses any Bash command that inlines `$GITEA_TOKEN`/`$GITEA_USERNAME` into the command text (a credential-use guard, not a git-safety one), so the live checks above ran only by having the script's own functions read the already-exported env vars internally rather than the invoking command line referencing them. | | 2026-08-07 | Code-review follow-up on the same branch (`fix/cli-39-version-train`). **Important gap fixed:** `src/ZB.MOM.WW.MxGateway.Contracts/ZB.MOM.WW.MxGateway.Contracts.csproj` was left at `0.1.2` — the original CLI-39 pass bumped the .NET Client but missed that `Invoke-PackDotnet` in `scripts/pack-clients.ps1` packs and publishes **both** `ZB.MOM.WW.MxGateway.Contracts` and `.Client` through the same `-Publish` loop, and the new collision guard runs every `ZB.MOM.WW.MxGateway.*.nupkg` it finds through `Assert-GiteaPackageNotPublished`. Left as-is, the next real `.NET` publish would have packed Contracts at the already-published 0.1.2, the guard would have correctly refused it, and the bare `ForEach-Object` would have aborted mid-loop — with `Client` (0.2.0, alphabetically first) potentially already pushed and `Contracts` stuck at 0.1.2, the two published nupkgs out of lockstep. Fixed: bumped `Contracts.csproj` to `0.2.0` alongside the Client (they have always released together). Also updated the now-stale comment in `src/Directory.Build.props` (it previously said the repo-wide `0.1.2` default was "kept ... to match the Contracts package"; that's no longer true now that Contracts overrides it — the comment now explains the override and that Server/Worker/Tests staying at `0.1.2` is a separate, not-yet-made decision; the `Directory.Build.props` `` value itself was **not** changed, since Server/Worker are not published packages and were out of scope for CLI-39). `docs/ClientPackaging.md`'s "Versioning" section gained `Contracts.csproj` as a fifth manifest (explaining why it must move with the .NET Client) and a note on the near-miss. **Cheap hardening also applied:** the Python (`pyproject.toml`) and Rust (`Cargo.toml`) version-extraction regexes in `pack-clients.ps1` now scope to the `[project]`/`[package]` section header respectively (matching the first `version = "..."` line anywhere in the file was luck of ordering — Cargo.toml has an identical second one under `[workspace.package]`), plus a one-line comment on the nuget filename-parse regex explaining the lazy-id/anchored-version split. **Verification:** `dotnet build src/ZB.MOM.WW.MxGateway.Contracts/ZB.MOM.WW.MxGateway.Contracts.csproj` 0 warnings/0 errors; `dotnet pack` of that project confirmed the artifact is literally named `ZB.MOM.WW.MxGateway.Contracts.0.2.0.nupkg`; `dotnet build clients/dotnet/ZB.MOM.WW.MxGateway.Client.slnx` still 0 warnings/0 errors. Re-ran the pack-clients.ps1 guard function-harness live against the real Gitea registry: `ZB.MOM.WW.MxGateway.Contracts`/`.Client` **0.1.2 both still refused**, **0.2.0 both now pass** — then went one step further and packed both projects for real (`dotnet pack`, no `-Publish`) and ran the exact `Invoke-PackDotnet` filename-parse-then-guard logic against the two real `.nupkg` files, confirming both parse to `id`/`version` correctly and both clear the live collision check. The scoped Python/Rust regexes were also exercised live against the real `pyproject.toml`/`Cargo.toml` and still resolve to `0.2.0`. No publish performed. | +| 2026-08-07 | **TST-30 → fully `Done`** — the operator half (register a second CI runner) executed live on `10.100.0.35` per `docs/runbooks/TST-30-second-ci-runner.md` option (a). A second **instance-level** `act_runner` container, `gitea-runner-2` (runner id 5, capacity 2, labels `ubuntu-latest`/`ubuntu-22.04`), was added to the `/opt/gitea` compose stack with the same `container.network: traefik` setting as the original, its registration token mounted from a `0600` file rather than inlined in compose. The existing `gitea-runner` (id 1, capacity 4) was **not** touched — total capacity went 4 → 6 purely by addition, so the change reverts by removing one container. **Concurrency verified live** (the finding's acceptance test): HEAD `a346d51` was pushed to two scratch branches, `scratch/tst30-a` (run 661) and `scratch/tst30-b` (run 662), while an unrelated run 660 was already in flight; at 13:07:53Z jobs from **three** runs were `in_progress` at once — run 660 `portable` plus run 662 `portable`/`java` on runner 1, and run 661 `portable`/`java` on `gitea-runner-2` — a state the pre-change single-runner topology could not produce. Runner attribution came from `GET /repos/dohertj2/mxaccessgw/actions/runs/{id}/jobs`, which exposes `runner_id`/`runner_name` per job, and was cross-checked against `docker logs gitea-runner-2` (`task 1145 …`, `task 1146 …` pickups at 13:05:22–23Z). **`gitea:3000` resolution holds on the new instance** — the property option (c) was rejected for losing: run 661's `portable` job (task 1145, scheduled on `gitea-runner-2`) logged `git remote add origin http://gitea:3000/dohertj2/mxaccessgw` then a successful `fetch … From http://gitea:3000/dohertj2/mxaccessgw`, and its job container's `/workspace/dohertj2/mxaccessgw` was confirmed checked out at `a346d514dd24e775640e5667aa7cd8e561fec68a`. **Runbook fact corrected:** its checklist expected `GET /repos/dohertj2/mxaccessgw/actions/runners` to show ≥2, but that endpoint still returns `total_count: 0` — correctly, since both runners are instance-scoped, which is exactly what this finding documented; the working check is `GET /api/v1/admin/actions/runners` (lists ids 1, 4 = an unrelated local macOS runner, and 5). A dated "Executed 2026-08-07" note recording this was added to the top of the runbook rather than rewriting its history. No source, workflow, or `docs/GatewayTesting.md` change was needed — the no-cancel reality and the `run-windev-ci.sh` bypass are unaffected by runner count, as that prose already stated. Scratch branches deleted after verification. Tracking: both registers' TST-30 rows, the pending-operator-actions list in `90-candidate-findings-next-cycle.md`, and this row. | diff --git a/archreview/2026-07-12/remediation/60-testing-docs-gaps.md b/archreview/2026-07-12/remediation/60-testing-docs-gaps.md index 2b2fbdf..64ff896 100644 --- a/archreview/2026-07-12/remediation/60-testing-docs-gaps.md +++ b/archreview/2026-07-12/remediation/60-testing-docs-gaps.md @@ -15,7 +15,7 @@ Prior-cycle open findings (TST-05..24 where still open) are tracked in the prior | TST-27 | Medium | P1 (doc batch) | S | — | Done | `ShowTagValues` config row still says "Reserved" after SEC-25 made the flag live | | TST-28 | Low | P2 | S | relates IPC-02 | Done | Gateway-side `max_frame_bytes` handshake field untested in the CI-run suite | | TST-29 | Low | P2 | S | — | Done | Retire `oldtasks.md` after folding the Phase-5 governance record into DesignDecisions.md; delete root docs-review artifacts | -| TST-30 | Low | P2 | M | — | Done (doc half; runner registration operator-pending per runbook) | Single shared Gitea runner is a CI throughput/availability bottleneck (cross-repo contention, no run cancel/delete) | +| TST-30 | Low | P2 | M | — | Done | Single shared Gitea runner is a CI throughput/availability bottleneck (cross-repo contention, no run cancel/delete) | --- @@ -169,6 +169,8 @@ Independent of the runner count, document the **no-cancel** reality (Gitea 1.26 **Outcome (2026-08-07 — Done, doc half; runner registration operator-pending).** Landed on `fix/tst-30-runner-docs`. Implementation step 2 shipped: `docs/GatewayTesting.md`'s Continuous Integration section gained a "Runner capacity is shared and finite" subsection stating the `maxParallel=1` co-located runner is shared with `dohertj2/lmxopcua` at the instance level (not repo-scoped), the ~20–30 minute queue latency observed under cross-repo contention, and the Gitea 1.26 no-cancel/no-delete API reality; the existing "windev tier down" degraded-mode paragraph now also covers "runner contended" as a reason to use the bypass, generalized per this finding's design note. New operator runbook `docs/runbooks/TST-30-second-ci-runner.md` carries **step 1** (register a second `act_runner` on `10.100.0.35`, option (a) recommended, same `container.network: traefik` config; option (b) dedicated labelled runner as an escalation; option (c) windev-hosted runner rejected) with the verification checklist (concurrent back-to-back pushes, `GET /repos/dohertj2/mxaccessgw/actions/runners` ≥ 2) and a note that the no-cancel reality persists regardless of runner count. **Step 3 (optional workflow-level `concurrency` group)** is documented in the runbook as unverified — explicitly framed as "verify this Gitea deployment honors it before relying on it" — and left unimplemented in `ci.yml`, since it is a `ci.yml` change out of scope for this doc-only pass. **The actual runner registration (step 1) is infrastructure work outside this repo's tree and remains the operator's to execute**, tracked in the runbook. Verification performed: `grep -n 'maxParallel\|shared\|cancel' docs/GatewayTesting.md` shows the new prose; runbook file exists at the path above; no build required (doc-only change). +**Outcome (2026-08-07 — operator half executed; finding now fully `Done`).** The runner registration left open above was executed per `docs/runbooks/TST-30-second-ci-runner.md` option (a). A second instance-level `act_runner` container, `gitea-runner-2` (runner id 5, capacity 2, labels `ubuntu-latest`/`ubuntu-22.04`), now runs on `10.100.0.35` from the `/opt/gitea` compose stack with the same `container.network: traefik` setting as the original; its registration token is mounted from a `0600` file rather than inlined in compose. The existing `gitea-runner` (id 1, capacity 4) was **not** modified — capacity went 4 → 6 by addition, so the change is reversible by removing one container. Concurrency verified live by pushing HEAD (`a346d51`) to two scratch branches, `scratch/tst30-a` (run 661) and `scratch/tst30-b` (run 662), while an unrelated run (660) was already in flight: at 13:07:53Z jobs from **three** runs were `in_progress` simultaneously — run 660 `portable` and run 662 `portable`/`java` on runner 1, run 661 `portable`/`java` on `gitea-runner-2` — which the pre-change single-runner topology could not have produced. `gitea:3000` resolution holds on the new instance: run 661's `portable` job (task 1145, scheduled on `gitea-runner-2`) logged `git remote add origin http://gitea:3000/dohertj2/mxaccessgw` followed by a successful `fetch … From http://gitea:3000/dohertj2/mxaccessgw`, and its job container's workspace was confirmed checked out at `a346d514dd24e775640e5667aa7cd8e561fec68a`. **Runbook correction:** its verification checklist said `GET /repos/dohertj2/mxaccessgw/actions/runners` should show ≥2 — that endpoint still returns `total_count: 0` because both runners are registered at the **instance** level, exactly as this finding documented; the correct check is `GET /api/v1/admin/actions/runners`, which lists ids 1, 4 (an unrelated local macOS runner), and 5. Recorded as a dated "Executed" note at the top of the runbook. The no-cancel reality is unchanged and the `run-windev-ci.sh` bypass remains valid, so `docs/GatewayTesting.md`'s prose needed no edit. + --- ## Cross-domain dependencies diff --git a/archreview/2026-07-12/remediation/90-candidate-findings-next-cycle.md b/archreview/2026-07-12/remediation/90-candidate-findings-next-cycle.md index b975f00..b1e47b6 100644 --- a/archreview/2026-07-12/remediation/90-candidate-findings-next-cycle.md +++ b/archreview/2026-07-12/remediation/90-candidate-findings-next-cycle.md @@ -15,5 +15,5 @@ These were discovered while remediating the 2026-07-12 backlog but were **out of These are **live-infrastructure actions the operator must execute** — the repo-side work is complete and merged: - **SEC-36** — rotate the dev LDAP service-account credential per `docs/runbooks/SEC-36-ldap-credential-rotation.md` (generate new secret in `scadaproj/infra/glauth`, pre-stage the NSSM env var on deployed hosts, rotate GLAuth on `10.100.0.35`, verify dashboard login). The committed literal is gone from the working tree but remains recoverable from git history until rotation completes — **rotation is the load-bearing half.** -- **TST-30** — register a second Gitea `act_runner` on `10.100.0.35` per `docs/runbooks/TST-30-second-ci-runner.md` to relieve the single-shared-runner bottleneck. +- ~~**TST-30** — register a second Gitea `act_runner` on `10.100.0.35` per `docs/runbooks/TST-30-second-ci-runner.md` to relieve the single-shared-runner bottleneck.~~ **Executed 2026-08-07**: `gitea-runner-2` (id 5, capacity 2) is online on `10.100.0.35` via the `/opt/gitea` compose stack, same `container.network: traefik`, token from a `0600` file mount; the existing runner (id 1, capacity 4) was untouched. Concurrency verified — jobs from three runs ran simultaneously across both runners, and a `gitea-runner-2` job cloned successfully from `http://gitea:3000`. TST-30 is now fully `Done`. - **TST-25 follow-ups** — old **TST-05** (scheduled live-MXAccess smoke) is now covered by the `nightly-windev` job; old **TST-24** (client wire tests in CI) is unblocked by the working Windows tier. diff --git a/docs/runbooks/TST-30-second-ci-runner.md b/docs/runbooks/TST-30-second-ci-runner.md index e955fdf..e536066 100644 --- a/docs/runbooks/TST-30-second-ci-runner.md +++ b/docs/runbooks/TST-30-second-ci-runner.md @@ -1,5 +1,24 @@ # TST-30 — Register A Second CI Runner (Operator Runbook) +> **Executed 2026-08-07 — option (a) shipped; this runbook is now history plus the one +> correction below.** `gitea-runner-2` (runner id 5, capacity 2, labels `ubuntu-latest`/ +> `ubuntu-22.04`) runs on `10.100.0.35` from the `/opt/gitea` compose stack with the same +> `container.network: traefik` setting as the original; its registration token is mounted from a +> `0600` file rather than inlined in compose. The existing `gitea-runner` (id 1, capacity 4) was +> left untouched, so capacity went 4 → 6 by addition and the change reverts by removing one +> container. Concurrency was verified by pushing HEAD to two scratch branches while an unrelated +> run was in flight: jobs from three runs ran simultaneously across both runners, and a +> `gitea-runner-2` job cloned successfully from `http://gitea:3000` (the property option (c) was +> rejected for losing). +> +> **Correction to the Verification and Done-criteria sections below:** they expect +> `GET /repos/dohertj2/mxaccessgw/actions/runners` to show ≥2 runners. It does not — it still +> returns `total_count: 0`, correctly, because both runners are registered at the **instance** +> level, which is the very condition the "Why" section describes. Use +> `GET /api/v1/admin/actions/runners` instead (it lists id 1, id 4 — an unrelated local macOS +> runner — and id 5). For per-job runner attribution, `GET /repos/{owner}/{repo}/actions/runs/{id}/jobs` +> exposes `runner_id`/`runner_name` on each job; the `actions/tasks` listing does not. + Operator steps to relieve the single shared Gitea Actions runner that CI depends on. The repo-side half of TST-30 (documenting the shared-runner/no-cancel reality and the `run-windev-ci.sh` bypass) is already landed in `docs/GatewayTesting.md`; registering the