git:20261016.b4fca1e to git:20261016.e44b44a

- measured_tokens: 10022

- `git archive` reads `export-ignore` from the tree it archives, so the first-release review of what ships (`release-prepare prep` Step 2f) must have landed *before* the RC tag exists.

- - **Prep PR merged** — the version-bump + changelog PR opened by `release-prepare prep` must be merged into the release branch.

- The skill checks that the prep-PR label (`prep-pr-open`) is absent or that the PR is in `merged` state.

- - **RC tag must not exist** — the tag `<version>-<rcN>` must not already exist on the remote;

- if it does, the skill blocks and the RM decides whether to bump the RC or delete the existing tag.

- - **`<project-config>/release-build.md` readable** — `build_command`, `expected_artefacts`, `digest_set`, optional `binary_exclude_list`;

- `§ Source archive` (`source_archive_method`, `source_archive_format`, `source_archive_prefix`, `export_ignore_reviewed`) and

- `§ Reproducibility checks` (`reproducibility_source`, `reproducibility_binaries`, `binary_rebuild_command`).

- - **`<project-config>/release-management-config.md` readable** — `release_dist_backend`, `release_dist_url_template`, optional `release_publish_command_template`;

- `§ Signing › automated_release_signing` (🪶 ASF-specific; read only when the project's organization offers automated signing —

- the organization manifest key `release_process.automated_signing`, resolved `project.md` → organization manifest → framework default).

- - **`.gitattributes` reviewed** — when `source_archive_method` is `git-archive`, `export_ignore_reviewed` is set

- (the first-release review in `release-prepare prep` Step 2f has landed and is in the tree the tag will point at).

- `uv run --project ~/.claude/magpie/vetted-ops vetted-op-read --caller release-rc-cut tags <version>-<rcN>`.

- It prints one ref per line for every tag starting with that prefix, so `rc1` also lists `rc10`:

- the tag exists only when a line is exactly `refs/tags/<version>-<rcN>`. If it does, block and report

- `rc_tag_exists: true`.

- "rc_tag_exists": true | false,

- Load the configuration with the same tool:

- --skill rc-cut <version> <rcN> [--release-branch <branch>] [--remote <name>]

- When `vote_backend` is `atr`, Step 3 also emits an `atr upload` block.

- "backend": "svnpubsub" | "github-releases" | "s3" | "self-hosted",

- ## Step 2 — Emit RC tag, build, sign, and checksum commands

-

- Compose four paste-ready command sections using the loaded build configuration.

-

- **Section 1 — Tag command.**

-

- ```text

- git tag -s <version>-<rcN> \

- -m "Release <version> RC<N>" \

- HEAD

- git push <git-upstream-remote> <version>-<rcN>

- ```

-

- `<git-upstream-remote>` resolves from `git_upstream_remote` in `release-management-config.md`:

- the upstream repo's git remote name (typical `origin`/`upstream`/`apache`; default `origin`; `--remote` overrides).

- Emit the concrete name.

-

- **Section 2 — Build command.**

-

- First **gitignore the RC artefacts** (`<artefact>` + `.asc`/`.sha512`, e.g. a committed glob like `*-source.zip*`) so a stray `git add` never commits an RC build.

- Then, depending on `source_archive_method`:

-

- *`git-archive` (default).* The source artefact is exported from the tag with the framework's

- [`reproducible-archive`](../../../../tools/reproducible-archive/README.md)

- tool (`<framework>` is `.apache-magpie` in an adopting project, `.` in the framework checkout;

- `python3 <framework>/tools/reproducible-archive/src/reproducible_archive/__init__.py` is the no-`uv` equivalent).

- It packs only tracked files at the tag, honours `.gitattributes` `export-ignore`, and applies every reproducible-builds.org archive rule, so the bytes are a function of the tag alone.

- It prints the **record** the RM pastes back for the Step 4 comment:

- the commit, the `SOURCE_DATE_EPOCH` it used (the tag's committer timestamp), the sha512,

- and the [Software Heritage identifiers](https://swhid.org/) —

- `swh:1:rev:` of the commit and `swh:1:dir:` of the archive's expanded content, both qualified with the repository URL (`--origin`, rendered from `<upstream>`) —

- plus a note saying whether the content SWHID equals the repository tree at the commit (nothing `export-ignore`d) or not.

- `build_command` (if any) follows, for convenience binaries only, with the same `SOURCE_DATE_EPOCH` exported so embedded timestamps are fixed:

-

- ```text

- # Run at the release tag <version>-<rcN>

- uv run --project <framework>/tools/reproducible-archive repro-archive build \

- --ref "<version>-<rcN>" --format <source_archive_format> \

- --prefix "<source_archive_prefix>" \

- --origin "https://github.com/<upstream>" \

- -o "<source-artefact-filename>"

- # → prints: commit <sha>, SOURCE_DATE_EPOCH <epoch>, sha512 <digest>,

- # swhid_rev swh:1:rev:<sha>;origin=…, swhid_dir swh:1:dir:<tree>;origin=…;anchor=…,

- # swhid_dir_note <identical to | differs from> the repository tree

-

- # Convenience binaries (only when build_command is set):

- export SOURCE_DATE_EPOCH="$(uv run --project <framework>/tools/reproducible-archive repro-archive epoch --ref "<version>-<rcN>")"

- <build_command>

- ```

-

- `<source-artefact-filename>` is the canonical source artefact from `expected_artefacts`; its extension must match `source_archive_format`.

-

- *`custom`.* The exact `build_command` from `release-build.md`, emitted verbatim (run at the tag), with `SOURCE_DATE_EPOCH` exported first:

-

- ```text

- # Run at the release tag <version>-<rcN>

- export SOURCE_DATE_EPOCH="$(git log -1 --format=%ct "<version>-<rcN>")"

- <build_command>

- ```

-

- Under either method, never emit `zip -r`, `tar czf <directory>` or any other command that packs a working directory (Golden rule 6).

-

- *Convenience artefacts (optional, project-specific).* When `convenience_artefacts` is non-empty, follow the source archive with one block per entry:

- the entry's own `build_command` verbatim, under the same `SOURCE_DATE_EPOCH`,

- so the artefact is a function of the tag and a voter can rebuild it in `release-verify-rc` Step 9 (the check that decides whether a binary is good).

- The framework does not know how a project builds its wheels, jars or images; the config does:

-

- ```text

- # Convenience artefact: <artefact.name> (<artefact.kind>) — built from the tagged source

- export SOURCE_DATE_EPOCH="$(uv run --project <framework>/tools/reproducible-archive repro-archive epoch --ref "<version>-<rcN>")"

- <artefact.build_command>

- ```

-

- For a source-only project say *"no convenience artefacts declared"* rather than emitting a build block.

-

- **Section 3 — Sign commands.**

-

- For each artefact in `expected_artefacts`:

- ```text

- gpg --detach-sign --armor <artefact>

- # produces <artefact>.asc

- No passphrase argument, no key-file reference.

-

- **Section 4 — Checksum commands.**

-

- For each artefact in `expected_artefacts`, for each digest in `digest_set`

- (never `md5`, never `sha1`):

-

- ```text

- sha512sum <artefact> > <artefact>.sha512

- sha256sum <artefact> > <artefact>.sha256 # only when sha256 in digest_set

- ```

- Present all four sections to the RM, who runs them sequentially on their own machine.

- Ask for confirmation that the commands look correct before proceeding to Step 3.

- Return ONLY valid JSON with this structure:

- ```json

- {

- "section_1_tag_commands": "<multi-line string: git tag + push>",

- "section_2_build_command": "<string>",

- "section_3_sign_commands": ["<gpg command for artefact 1>", "<gpg command for artefact 2>"],

- "section_4_checksum_commands": ["<sha512sum for artefact 1>", "<sha256sum for artefact 1 if configured>"],

- "prohibited_digests_omitted": true,

- "proposed": true

- }

- ```

- `prohibited_digests_omitted` is always `true`; it confirms that no `md5` or `sha1` digest command was emitted.

- `proposed` is always `true` at the point this JSON is returned — the RM has not yet confirmed execution.

- When `signing_mode` is `ci-automated`, Sections 3 and 4 are **not** emitted (CI signs and checksums);

- return them as empty lists and continue with Step 2c instead of Step 3.

- Otherwise compose the backend-shaped staging command sequence based on `release_dist_backend`.

-

- **`svnpubsub` (ASF default):**

-

- ```text

- # Import the signed + checksummed artefacts into dist/dev

- svn import <local-artefact-dir>/ \

- https://dist.apache.org/repos/dist/dev/<project>/<version>-<rcN>/ \ # release_dist_backend=svnpubsub

- --username <asf-id> \

- -m "Release <project> <version> <rcN>"

- ```

-

- Note: the target URL **must** be `dist/dev/` (when `release_dist_backend = svnpubsub`), never `dist/release/`.

- Any path containing `dist/release/` is refused by the skill (see `release_dist_backend` — Golden rule 5).

-

- **`github-releases`:**

-

- ```text

- gh release create <version>-<rcN> \

- --repo <upstream> \

- --title "Release <version> RC<N>" \

- --prerelease \

- --draft

- gh release upload <version>-<rcN> \

- <artefact1> <artefact1>.asc <artefact1>.sha512 \

- ... (one entry per artefact + its .asc and digest files)

- ```

-

- **`s3`:**

-

- ```text

- aws s3 cp --recursive <local-artefact-dir>/ \

- s3://<bucket>/<version>-<rcN>/

- ```

-

- **`self-hosted`:**

-

- The `release_publish_command_template` from `release-management-config.md` rendered with `<version>` and `<rcN>` substituted.

-

- **Additionally, when `release_vote_backend = atr`**

- (the hybrid flow — `release_dist_backend = svnpubsub` hosts + promotes, ATR runs the checks and drives the vote),

- emit an ATR-upload block **after** the dist-backend staging block.

- The signed artefacts must reach ATR so its Compose checks run and there is a candidate revision to vote on.

- The artefacts land in **both** the dist backend (above) and ATR (here);

- ATR's Finish/publish is **not** emitted (promotion stays with `release_dist_backend`).

-

- ```text

- # Upload the SAME signed + checksummed artefacts to ATR (Compose) so it

- # runs signature/checksum/licence/source-header checks and can drive the

- # [VOTE]. Verb/flag names may shift between ATR releases; confirm the

- # current shape with `atr <cmd> --help`.

- atr upload <project> <version> <artefact> <artefact>

- atr upload <project> <version> <artefact>.asc <artefact>.asc

- atr upload <project> <version> <artefact>.sha512 <artefact>.sha512

- atr check status <project> <version> --verbose # confirm checks pass

- atr check concerns <project> <version> # list any concern-group keys to ack at vote time

- ```

-

- The uploaded candidate is the one `release-vote-draft` votes on;

- `atr vote start` targets the latest uploaded revision by default (its `--revision` flag is optional),

- so there is no separate revision id to capture here.

-

- This block is a proposal like the rest; the RM runs it on their machine under their own ATR credentials.

- `atr_platform_url` from `release-management-config.md` is the target platform.

- **Convenience artefacts with `staging: registry-staging`** (optional, project-specific) get one more block after the dist-backend staging:

- the entry's `stage_command` verbatim (for example `twine upload -r testpypi …`, `mvn nexus-staging:deploy`, `docker push <registry>/<image>:<version>-<rcN>`).

- Entries staged as `dist-dev` or `atr` travel with the source in the blocks above and need nothing extra; say so.

- Never emit a command that publishes to the artefact's final `publish_channel` here —

- publication is `release-promote`'s step, after the vote.

- Present the staging command block to the RM and ask for confirmation before proceeding to Step 4.

- Return ONLY valid JSON with this structure:

- "backend": "svnpubsub" | "github-releases" | "s3" | "self-hosted",

- `atr_upload_commands` is populated only when `vote_backend = atr` (empty list otherwise);

- it never contains an `atr release finish` / publish command while `release_dist_backend = svnpubsub`.

-

- `dist_dev_only` is always `true` for `svnpubsub`; it confirms that no `dist/release/` path (`release_dist_backend = svnpubsub`) was emitted.

- For non-`svnpubsub` backends it is `false` (the field is not meaningful but must be present).

- `proposed` is always `true` at this point.

- Compose a planning-issue comment that records the RC artefact list, the RC tag, and the staging URL for downstream skills (`release-verify-rc`, `release-vote-draft`).

- The comment must include:

- - The RC identifier (`<version>-<rcN>`).

- - The RC tag URL on `<upstream>`.

- - The staging URL (where verifiers can download artefacts).

- - The expected artefact list with filenames (not yet public checksums — those are confirmed once the RM has run the commands).

- - **Reproducibility record** — everything `repro-archive build` printed:

- the source commit hash, the repository URL (`https://github.com/<upstream>`),

- the SWHIDs (`swh:1:rev:` of the commit and `swh:1:dir:` of the archive content, with their `origin` and `anchor` qualifiers)

- and the note on whether the content SWHID equals the repository tree,

- the `SOURCE_DATE_EPOCH`, the sha512, the `source_archive_format` and `source_archive_prefix`,

- and the outcome of Step 2b (or `skipped`).

- A voter needs the commit and epoch to rebuild in `release-verify-rc` Step 9, the sha512 to compare bytes,

- and the `swh:1:dir:` to compare trees — with their own recomputation and with the value ATR computes for the candidate.

- Under `ci-automated` also the workflow run URL.

- - **Convenience artefacts** (when declared) — one line each:

- name, kind, where it is staged, its `reproducibility` mode and Step 2b outcome, whether it is `vote_included`, and the source `swh:1:dir:` it was built from.

- - If `--allow-unreviewed-archive` was used: a line saying the source archive contents were **not** reviewed and why.

- - The proposed next label: `rc-staging`.

- Present the proposed comment to the RM and ask for confirmation before posting (Golden rule 4).

- If the RM confirms, write the approved comment to `<scratch>/rc-cut-comment.md` and post it with

- Return ONLY valid JSON with this structure:

-

- ```json

- {

- "proposed_comment_summary": "<one-sentence summary of what the comment records>",

- "includes_rc_tag": true,

- "includes_staging_url": true,

- "includes_artefact_list": true,

- "proposed_label": "rc-staging",

- "proposed": true

- }

- ```

-

- `proposed` is always `true` at the point this JSON is returned.

- The AI-driven part ends with a hand-back artefact containing:

- - **RC identifier** — `<version>-<rcN>`.

- - **Tag command** — the `git tag -s` + `git push` sequence to copy and run.

- - **Build command** — `repro-archive build` for the source artefact (or `build_command` under `custom`), plus `build_command` for any convenience binaries under `SOURCE_DATE_EPOCH`.

- - **Reproducibility self-check** — Step 2b's `check` / rebuild / `compare` block, or the explicit reason it was skipped.

- - **Sign commands** — one `gpg --detach-sign --armor` per expected artefact (omitted under `ci-automated`, where Step 2c's tag push replaces them).

- - **Checksum commands** — sha512 (and sha256 where configured) per artefact.

- - **Staging commands** — backend-shaped `svn import` / `gh release` / `aws s3 cp`.

- - **Planning-issue comment** — the proposed comment body (pending RM confirmation), including the reproducibility record.

- - **Next step** — run `release-verify-rc <version>-<rcN>` against the staging URL to verify signatures, checksums, license headers, artefact completeness and reproducibility before opening the `[VOTE]` thread.

- Under `ci-automated` that run is the policy-required validation on trusted hardware and must report `identical`.

- | Symptom | Likely cause | Remediation |

- |---|---|---|

- | Pre-flight blocked — prep PR not merged | The prep PR is still open or closed without merge | Merge the prep PR or supply `--planning-issue` pointing at a planning issue where prep is confirmed |

- | Pre-flight blocked — RC tag exists | `<version>-<rcN>` already exists on the remote | Decide whether to delete the tag (rare) or bump the RC number; rerun with the new RC number |

- | Pre-flight blocked — prohibited digest | `release-build.md` lists `md5` or `sha1` | Remove the prohibited digest from `release-build.md`; only `sha512` (required) and `sha256` (optional) are accepted |

- | Staging command uses `dist/release/` (`release_dist_backend = svnpubsub`) | Config error in `release_dist_url_template` | Correct the template; staging target must be `dist/dev/` |

- | `release-build.md` missing or incomplete | Adopter has not filled out the template | Complete `<project-config>/release-build.md` before running this skill |

- | `signing_key_fingerprint` empty | `rm_key_fingerprint` not set in user.md or config | Add `rm_key_fingerprint` to user.md (preferred) or `release-management-config.md` |

- | Pre-flight blocked — `archive_reviewed: false` | `export_ignore_reviewed` unset in `release-build.md § Source archive` | Run `release-prepare prep <version>`; its Step 2f reviews what ships and lands `.gitattributes` in the prep PR. `--allow-unreviewed-archive` is the logged override |

- | Pre-flight blocked — signing mode inconsistent | `automated_release_signing: enabled` (where the organization offers automated signing) without `reproducibility_source: on` / `reproducibility_binaries: byte-identical`; where it does not, the setting is ignored and `signing_mode` stays `rm-key` | Set `automated_release_signing: off` (or `requested`) until the conditions hold; see `release-prepare automated-signing` |

- | Step 2b `compare` → `content-identical` | Source artefact built with a plain `git archive` or another tool version, not `repro-archive build` | Rebuild with `repro-archive build` (or `repro-archive recipe`); under `ci-automated` this is a stop |

- | Step 2b `compare` → `differs` | The artefact is not the tagged tree (built from a dirty checkout, wrong ref, or a non-deterministic `custom` build) | Rebuild at the tag from a clean checkout; fix the build; do not sign |

- | Step 2b binary `DIFFERS` | Build embeds timestamps, paths or a non-pinned toolchain | Honour `SOURCE_DATE_EPOCH`, pin the toolchain, `ARFLAGS=Dcvr`; or switch to `documented-divergence` and list the divergence in `release-build.md` |

- - [`docs/release-management/process.md`](../../../../docs/release-management/process.md) —

- Steps 4–5 context.

- - [`docs/release-management/spec.md`](../../../../docs/release-management/spec.md) —

- `release-rc-cut` per-skill specification.

- - [`<project-config>/release-build.md`](../../../magpie-setup/templates/release-build.md) —

- adopter keys this skill reads (`build_command`, `expected_artefacts`,

- `digest_set`, `binary_exclude_list`, `source_archive_*`,

- `export_ignore_reviewed`, `reproducibility_*`).

- - [`docs/release-management/reproducibility.md`](../../../../docs/release-management/reproducibility.md) —

- the source-archive contract, the reproducible-builds.org rule mapping,

- the reproducibility checks, and the ASF automated-signing option.

- - [`tools/reproducible-archive`](../../../../tools/reproducible-archive/README.md) —

- `repro-archive build` / `check` / `compare` / `recipe` / `epoch`.

- - [reproducible-builds.org § Archive metadata](https://reproducible-builds.org/docs/archives/) —

- the archive rules the source artefact satisfies.

- - [Infra § Automated release signing](https://infra.apache.org/release-signing.html#automated-release-signing) —

- 🪶 ASF-specific policy behind Step 2c.

- - [`<project-config>/release-management-config.md`](../../../magpie-setup/templates/release-management-config.md) —

- adopter keys this skill reads (`release_dist_backend`,

- `release_dist_url_template`, `release_publish_command_template`,

- `rm_key_fingerprint`, `release_branch_base`, `git_upstream_remote`).

- - `release-keys-sync` — upstream step; the RM's public key must be in

- `KEYS` before the RC is tagged.

- - `release-prepare` — upstream step; the prep PR it creates must be merged.

- - `release-verify-rc` — downstream step; verifies the staged RC before

- the `[VOTE]` thread opens.

- - `release-vote-draft` — downstream step; reads the planning-issue comment

- this skill posts to construct the `[VOTE]` email.

- - [ASF release policy](https://www.apache.org/legal/release-policy.html) —

- governance on release tagging, signing, and distribution.

- - [ASF release distribution § sigs-and-sums](https://infra.apache.org/release-distribution.html#sigs-and-sums) —

- MD5 / SHA-1 prohibition; SHA-512 baseline.

- - [ASF release signing](https://infra.apache.org/release-signing.html) —

- key-management and signing-command guidance.