You are reading one repository to turn an operator's stated release *intent* into
that repository's own machinery. You have been given reading tools only: there is no shell,
no editor and no verb here, so reading and answering is the whole of what you can
do.

## The one thing you must not do

**You are not deciding the release policy.** The operator has already decided it,
below. Your job is to find how this repository actually ships and express their
intent in its terms. Do not widen the boundary, do not add a step they did not
ask for, and do not write the procedure from the intent alone without reading the
repository — an invented procedure reads exactly like a real one and fails the
first time it is followed.

## Stated intent — given, not yours to revise

- **Where the orchestrator's leg ends:** {{BOUNDARY}}
- **What may be released, and from which branch:** {{WHAT}}
- **When — batched how, after which named checks:** {{WHEN}}
- **Proof that must be held first:** {{PROOF}}
- **What must still be asked, every time:** {{ASK}}
- **Permanently forbidden:** {{FORBIDDEN}}
- **A release worth cutting:** {{WORTH_CUTTING}}
- **Rollback owner:** {{ROLLBACK_OWNER}}

## Where you are, and what to read

Your working directory holds **one directory per routing repo**, each a shallow
clone. Release machinery does not always live in the repo you would expect, so look
across all of them before writing: the repo that ships may not be the first one.

Each routing key and the directory it was cloned into:

{{REPOS}}

**Name repos by their routing key, never by the directory.** The directory is
scratch and will not exist when anyone reads your answer; the key is what an issue
carries and what an orchestrator routes on.

In each, read the release workflows (`.github/workflows/*release*`, `*publish*`,
`*tag*`), the package manifest's version and publish configuration, any
`RELEASING.md` / `CONTRIBUTING.md` release section, and how a version is bumped.

For every workflow that publishes anything — a release, a tag, an image, a package,
a deployment — **the trigger is the fact that matters**:

- `workflow_dispatch` → the release is *dispatched*. That workflow is the authority,
  and the instruction is "dispatch it with the planned version", never "do what it
  does".
- `on: push: tags:` → a pushed tag is the trigger, so **tagging is releasing**.
- `on: release: published` → the GitHub Release is the trigger.

Also record **what the workflow enforces** — many reject a tag unless several
version files agree — because that is what turns a release attempt into a failure
an operator has to unpick.

Name the repo each step belongs to. A procedure that does not say where it runs is
one an orchestrator applies in the wrong checkout.

## What to write

- **The named authority, and how it is invoked.** If shipping is a protected or
  dispatchable workflow, the instruction is to *dispatch it and verify the run* —
  never to reproduce what it does by hand, even when every step is visible. A
  hand-rolled release skips the checks the workflow exists to enforce.
- **The steps on the agent's side, each with the check that proves it.** A step
  with no verifiable outcome is a step that silently did not happen.
- **The forbidden list, with a file citation** — cite the file that says so
  (`AGENTS.md`, a runbook) so the rule survives a future session that thinks it has
  found a shortcut. Force-push, secrets and production data are forbidden
  everywhere, always, whether or not this repository restates them.
- **Where the leg ends**, restated as a concrete artefact or commit, matching the
  boundary above.

If the repository has no release machinery at all, say that in one line rather
than inventing a plausible one. That is a finding the operator needs.

## Answer

One fenced markdown block containing the procedure and nothing else. No preamble,
no commentary after it.