fix: the release lane tests the pull-request path at v7, not v7-next

.github/workflows/org-pull-request.yml

@@ -1,8 +1,14 @@
 name: Pull request (organisation)
 
-# The pull request pipeline of every DiluxOne repository, in one place. An
-# organisation ruleset requires this workflow on every repository's default
-# branch, so it runs on each pull request with no file in the repository:
+# The pull request pipeline of every DiluxOne repository, in one place. The
+# organisation ruleset "org: required workflow" requires this workflow, at
+# `v7`, on every adopted repository's default branch, so it runs on each pull
+# request with no file in the repository, in every one but the test
+# repository (org.yml `test-repo`, #748): there the same jobs run from its own
+# caller, workflow-templates/test-pull-request.yml, which the release lane
+# moves to `@v7-next`, since this workflow is read at `v7` with its calls
+# hard-wired to `@v7` and so could never try a candidate. Keep its `on:` and
+# jobs and that template's in step (tests/workflows/test_test_repo_pipeline.py):
 # the conventions with the accepted-issue gate, then the Claude review and
 # the auto-merge decision; beside them, the issues it closes go to its
 # author when a member of the organisation (pull-request-assignee.yml, #73);

.github/workflows/release-lane.yml

@@ -10,7 +10,13 @@ name: Release lane
 # through pull requests the bot opens there and queues itself once their
 # checks pass, after checking that they change nothing but the engine's ref:
 # the auto-merge decision never merges a change to .github/workflows; never
-# a write to its main) with the test identity's token (whose owner must be
+# a write to its main; its pull-request pipeline among them,
+# test-pull-request.yml, since the required workflow, org-pull-request.yml,
+# runs at `v7` with its calls hard-wired and leaves the test repository out,
+# so the scenarios' reviews, auto-merge decisions and fix rounds run the
+# candidate; `move` plays nothing while the test repository still requires
+# org-pull-request.yml or a caller there calls the engine off `@v7-next`,
+# #748) with the test identity's token (whose owner must be
 # the organisation variable DX_TEST_LOGIN, or the lane stops before the
 # callers move, naming the value to set and its URL, #739), in groups that play
 # at once, one job each (`move`, then `play`, a matrix on ubuntu-latest,

docs/adopting.md

@@ -101,7 +101,7 @@ Most of it is the organisation's already: a new repository gets the pull request
    its `repos.yml` entry's `pre-pr` says it has none by design).
 3. **What it is, then labels, settings and shared files.** First add it to `repos.yml` `repos:`, one entry with everything said of it (#562): its kinds, the paths each covers and their roles, its `project`, `design-system`, `repro`, `merge-queue`, `pre-pr`, `dependabot` and `callers` (`scripts/repos-config.py check` holds it; the daily drift check reports a repository missing there); the kind is read from there only. Then `python3 scripts/sync-repos.py all --repo <name>` from a checkout of this repository: the labels, the merge and security settings (Dependabot's security updates among them), `.github/CODEOWNERS`, and the opening block of `AGENTS.md` (a pull request with its issue); then `python3 scripts/sync-repos.py dependabot --repo <name>` for `.github/dependabot.yml` (a pull request of its own). `all` also turns its merge queue on where GitHub gives one (org.yml `merge-queue`, #451): a public repository, once every check its rules require comes from a workflow that runs on `merge_group` (#562; the drift check names a check and its workflow that do not; a required check no run of its five most recent pull requests produces keeps a new queue off but leaves an existing one as it is, since it could not tell). `python3 scripts/sync-repos.py adopt --repo <name>` does all of it at once. The `main` and tag rulesets are the organisation's; a plugin that publishes adds its environment `wordpress-org` (deployment policy: tag `*.*.*` plus `main` and the branches `security/*`, where dilux-bot alone pushes a security patch, #247; the SVN credentials and the release App's key as environment secrets; no required reviewer is needed, since a person accepting the release issue is the approval) and installs the `dilux-release` App.
 
-   The organisation's side: the three organisation rulesets (`org: main`, `org: release tag creation`, `org: release tags`) cover the repositories whose custom property `dx-adopted` is `true`, which `sync-repos.py rulesets` (and `adopt`) writes from `repos.yml` (#562); it moves a ruleset from its list of names to the property only when every repository that list covers today (`~ALL` and patterns included, archived ones not) is listed in `repos.yml` and not excluded, and otherwise names those and changes nothing, and secret scanning and push protection come from the code security configuration `repos.yml` `security: configuration` names for the repository's visibility (one name for every repository, or `public:` and `private:`, the latter covering internal ones, #603), which `sync-repos.py security` attaches and keeps the default for new repositories of that visibility, narrowing one already attached that is still the default for every visibility (the daily drift check names a default that differs); a private repository with no `private:` entry gets none, and one already attached stays until a maintainer detaches it in the organisation's settings; what GitHub holds only at the enterprise level the maintainer changes once there. Done by an administrator of the organisation (a maintainer, or the session working in this repository): for a private repository, also to the organisation variable `DX_RUNNER_HEAVY` and to the runner group `private-repos-vm`, so its jobs run on the organisation's VM and spend no minutes; and give it a Project in its `repos.yml` entry (`project:`; `sync-repos.py project` links it, and the drift check says when it has none) and, when it has screens, its design system (`design-system:`, [`design-systems/`](../design-systems/)). A repository that versions third-party code with Markdown of its own (a site's `wp-content/plugins/` and `themes/`) lists those paths in a `.lycheeignore` at its root, lychee's own file, so the docs check does not follow their links.
+   The organisation's side: the four organisation rulesets (`org: main`, `org: required workflow`, `org: release tag creation`, `org: release tags`) cover the repositories whose custom property `dx-adopted` is `true`, `org: required workflow` (the required workflow, `org-pull-request.yml` at `v7`, split out of `org: main` by `sync-repos.py rulesets`, #748) less the test repository (org.yml `test-repo`, whose custom property org.yml `test-property` is `true`), which runs the same pipeline from its own caller, `test-pull-request.yml`, so the release lane moves it to the candidate, which `sync-repos.py rulesets` (and `adopt`) writes from `repos.yml` (#562); it moves a ruleset from its list of names to the property only when every repository that list covers today (`~ALL` and patterns included, archived ones not) is listed in `repos.yml` and not excluded, and otherwise names those and changes nothing, and secret scanning and push protection come from the code security configuration `repos.yml` `security: configuration` names for the repository's visibility (one name for every repository, or `public:` and `private:`, the latter covering internal ones, #603), which `sync-repos.py security` attaches and keeps the default for new repositories of that visibility, narrowing one already attached that is still the default for every visibility (the daily drift check names a default that differs); a private repository with no `private:` entry gets none, and one already attached stays until a maintainer detaches it in the organisation's settings; what GitHub holds only at the enterprise level the maintainer changes once there. Done by an administrator of the organisation (a maintainer, or the session working in this repository): for a private repository, also to the organisation variable `DX_RUNNER_HEAVY` and to the runner group `private-repos-vm`, so its jobs run on the organisation's VM and spend no minutes; and give it a Project in its `repos.yml` entry (`project:`; `sync-repos.py project` links it, and the drift check says when it has none) and, when it has screens, its design system (`design-system:`, [`design-systems/`](../design-systems/)). A repository that versions third-party code with Markdown of its own (a site's `wp-content/plugins/` and `themes/`) lists those paths in a `.lycheeignore` at its root, lychee's own file, so the docs check does not follow their links.
 
    Then the readme: the newest entry under `== Changelog ==` is headed
    `= X.Y.Z =` (or `= Unreleased =`) and its first line is `Unreleased.`

docs/configuration.md

@@ -27,6 +27,7 @@ What a level may do: `any` value; `lower-only`; `stricter` (switch off, narrow,
 | `test-repo`: The test repository, where the release lane plays every scenario before `v7` moves. | the organisation's own, never the engine's | `any` | `never` | a repository of the organisation of kind `engine-test`, and no product | [`org.py`](../scripts/org.py) | #563 |
 | `core`: The engine's core files; while an open autopilot pull request touches one, no other issue whose Spec touches one starts. | `[]` | `any` | `never` | globs of the engine's files | [`org.py`](../scripts/org.py) | #563, #568 |
 | `adopted-property`: The custom property that says a repository is adopted, which the organisation's rulesets cover. | `"dx-adopted"` | `any` | `never` | a custom property of the organisation | [`sync-repos.py`](../scripts/sync-repos.py) | #562 |
+| `test-property`: The custom property, true on the test repository alone, that the required workflow's ruleset excludes, so the test repository runs the candidate's pipeline from its own caller. | `"dx-engine-test"` | `any` | `never` | a custom property of the organisation | [`org.py`](../scripts/org.py), [`sync-repos.py`](../scripts/sync-repos.py) | #748 |
 | `conventions-contradictions`: A repository's own commit rules that contradict the organisation's, which the daily drift check lists. | the patterns in org.yml | `any` | `never` | each pattern with the lines it must find and must not | [`sync-repos.py`](../scripts/sync-repos.py) | #562 |
 
 ## `repos.yml`