docs: the server runs Gitea 1.27.2, not 1.24.2; say what it actually honours

The CI documentation, the workflow header, the README, ADR 0047 and the
sweep's comment all said the server was Gitea 1.24.2, which ignores
`permissions`, `concurrency` and `timeout-minutes`. The server reports
1.27.2 (GET /api/v1/version).

Each claim is now stated from what is verified on this server:
- `concurrency` is honoured, observed: Ekklesia runs 133 and 135 were
  cancelled when a newer run started for the same pull request;
- `permissions` is supported by 1.27 with Gitea's own scopes, but the
  token's actual authority is not visible through the API and not yet
  proven, so nothing claims the job token is read-only;
- `timeout-minutes` is no longer listed as unsupported, but is not
  verified, and teardown still relies on the stack sweep and a reaper.

Requirement 1 for executing untrusted contributions (upgrade to the
1.26 line or later) is marked done; items 2 and 3, configuring and
proving token authority, remain. ADR 0047 (still Proposed) restates
its "docker run, not a reusable workflow" reasons for 1.27, where
private sources are supported. The reasons still hold without the 1.24
argument.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

docs/architecture/decisions/0047-module-ci-harness.md

@@ -163,27 +163,28 @@ It references no secret, needs no registry credential (the harness image is publ
 organization), and uses no `pull_request_target`. The trusted-code-only rule for self-hosted runners
 applies to module repositories exactly as it does to the platform (see `docs/development/security.md`).
 
-**Why `docker run`, and not a reusable workflow or a composite action.** The inventoried server is
-Gitea 1.24.2.
+**Why `docker run`, and not a reusable workflow or a composite action.** The server runs Gitea
+1.27.2. (This proposal first assumed 1.24.2; the reasons below hold on the actual version.)
 
-- Its runner does support calling a reusable workflow from another repository, by cloning that
-  repository. That support is thinly documented, and has known problems in practice.
-- Actions and reusable workflows from **private** repositories only arrive with Gitea 1.26
-  (go-gitea/gitea#32562).
+- Its runner can call a reusable workflow from another repository by cloning that repository, and
+  since 1.26 that includes private repositories (go-gitea/gitea#32562). That support is still thinly
+  documented, and has known problems in practice.
+- A reusable workflow would make the harness's behaviour depend on how this server and runner
+  version expand it. An image runs the same everywhere it runs.
 - Composite actions from another repository work through absolute `uses:` URLs. That would still
   wrap the same `docker run`, adding a second pinned reference and nothing else.
 
 An image digest is the one reference that is equally immutable, equally reviewable, and works
-unchanged on Gitea 1.24, Gitea 1.26, and GitHub Actions. A composite action can be added later as a
+unchanged on any Gitea release and on GitHub Actions. A composite action can be added later as a
 convenience over the same image, without changing what a module pins.
 
 ### Nothing the harness starts outlives the job that started it
 
 The harness starts Docker stacks on a shared runner, and a runner can kill a job outright: a
-cancelled job, or the runner's own time limit, since Gitea 1.24 ignores `timeout-minutes`. A script's
-own cleanup trap does not run then. The platform's CI leaked a whole migration stack that way, and it
-ran until someone removed it by hand. So the harness follows the platform's rule
-(`scripts/ci-sweep.sh`, `docs/development/security.md`):
+cancelled or superseded job (`concurrency` cancels superseded runs on this server), or the runner's
+own time limit. A script's own cleanup trap does not run then. The platform's CI leaked a whole
+migration stack that way, and it ran until someone removed it by hand. So the harness follows the
+platform's rule (`scripts/ci-sweep.sh`, `docs/development/security.md`):
 
 - everything it starts is named and labeled as a CI stack of its run, attempt, and job key;
 - it removes its own stacks in a trap;
@@ -233,9 +234,9 @@ The registry is reached exactly as the instance's publish job reaches it.
 
 - **Each module keeps its own copy of the smoke scripts.** Rejected. That is today's situation in
   embryo, and it drifts.
-- **A reusable workflow in the platform repository.** Rejected for now, for the Gitea 1.24 reasons
-  above. It would also give the harness's behaviour to whichever runner and server version happens
-  to expand it.
+- **A reusable workflow in the platform repository.** Rejected for now, for the reasons above: thin
+  support in practice, and a harness whose behaviour depends on whichever runner and server version
+  happens to expand it.
 - **Publish the harness as an npm package.** Rejected. The harness needs Docker, a browser, and the
   platform's deployment files anyway, so a package would ship a fraction of it and assume the rest.
 - **Test only the newest platform version.** Rejected. A module's range floor would go untested

docs/development/security.md

@@ -693,8 +693,10 @@ public Dashboard login must be assessed with the actual edge/proxy controls befo
 
 ## Continuous integration boundary
 
-CI runs on self-hosted Gitea Actions runners. The inventoried server is **Gitea 1.24.2**, and that
-version determines which parts of the workflow are real guarantees and which are not.
+CI runs on self-hosted Gitea Actions runners. The server reports **Gitea 1.27.2** (`GET
+/api/v1/version`, checked 2026-10-06; this document previously said 1.24.2, which was stale). The
+server's actual version, not the documentation of an earlier one, determines which parts of the
+workflow are real guarantees and which are not.
 
 ### The current operating rule: trusted code only
 
@@ -727,24 +729,26 @@ so a later step in the same job cannot read or reuse it from there.
 It does **not** remove the short-lived `GITEA_TOKEN` from the job environment, and it does **not**
 reduce that token's server-side authority. A step that wants the token can still read it.
 
-### What Gitea 1.24 ignores — so the branch cannot claim it
+### What this server honours, and what is not yet verified
 
-Per the official comparison for this version
-(<https://docs.gitea.com/1.24/usage/actions/comparison>), Gitea 1.24's unsupported workflow syntax
-includes `permissions` and `jobs.<job_id>.permissions`, `concurrency`, and
-`jobs.<job_id>.timeout-minutes`. On this server those declarations are inert. Therefore:
+Each item separates what Gitea documents for 1.27
+(<https://docs.gitea.com/1.27/usage/actions/comparison>) from what has been observed on this server:
 
-- **The workflow's `permissions: contents: read` does not restrict the job token.** This branch
-  cannot claim the `GITEA_TOKEN` is read-only, because nothing in workflow YAML makes it so on
-  1.24. Job-token permission controls, repository/owner defaults, and server-side
-  maximum-permission clamping arrive in the 1.26 feature line
-  (<https://docs.gitea.com/1.26/usage/actions/token-permissions>).
-- **`concurrency` and `timeout-minutes` are not bounded-execution guarantees here.** Cancellation,
-  timeout, and teardown must be enforced by a trusted provisioner and reaper outside the workflow.
+- **`concurrency` is honoured.** Gitea supports it since 1.26 (go-gitea/gitea#32751), and on this
+  server a newer push to a pull request cancels the run it supersedes. Observed: Ekklesia run 133 was
+  cancelled when run 134 started for the same pull request, and run 135 when run 137 did. A
+  superseded run's own cleanup is therefore never guaranteed to run, which is one reason for the
+  stack sweep below.
+- **`permissions` is supported by 1.27, with Gitea's own scopes, but is not verified here.** The
+  server-side token-permission settings are not visible through the API, and nothing has yet proven
+  what the job token can and cannot do on this server. Until that proof exists (requirement 3
+  below), this repository still does not claim the `GITEA_TOKEN` is read-only.
+- **`timeout-minutes` is no longer listed as unsupported for 1.27, but is not verified here.**
+  Teardown does not rely on it: the stack sweep and a trusted reaper do.
+- **Still ignored:** `jobs.<job_id>.environment`, and any `runs-on` other than a single label.
 
-The declarations are kept deliberately: they are already correct for a supported Gitea release and
-for GitHub Actions, and keeping them means the upgrade does not require re-deriving the intent. They
-are documented as ignored, not removed.
+The declarations stay in the workflow either way: they state the intent, and are correct on GitHub
+Actions as well.
 
 ### Disposable stacks never outlive their job
 
@@ -793,16 +797,17 @@ they are not conditions on merging trusted, reviewed work.
 None of them can be satisfied by editing this repository; each requires access to the Gitea server
 and runner hosts, and each must be proven there.
 
-1. Upgrade Gitea to a reviewed supported release with job-token permission controls — at least the
-   1.26 feature line. Select the actual release during infrastructure work, after backup and
-   compatibility review; do not pin a version from this document.
+1. ~~Upgrade Gitea to a reviewed supported release with job-token permission controls — at least
+   the 1.26 feature line.~~ **Done:** the server runs 1.27.2. Items 2 and 3 now configure and prove
+   what it makes possible.
 2. Configure repository and owner defaults, and the server-side maximum permission, so workflow
    code cannot request more than read-only repository access.
 3. Prove against the real server that the job's `GITEA_TOKEN` cannot push code, create or update
    releases, packages, issues, or pull requests, change Actions configuration, or reach another
    private repository.
-4. Enforce job timeout, cancellation, concurrency, and teardown in the trusted
-   provisioner/reaper rather than relying on the ignored workflow keys above.
+4. Enforce job timeout and teardown in the trusted provisioner/reaper. `concurrency` is honoured
+   by the server; `timeout-minutes` is not yet verified, and the in-workflow stack sweep only
+   complements a reaper.
 5. Complete a disposable-guest runner isolation proof: one throwaway guest per job, torn down by a
    trusted reaper outside workflow YAML, holding no deployment credential, registration token, or
    reusable key.