Release v2.3.0: merge v2/main into main

.claude/skills/board-ops/SKILL.md

@@ -299,8 +299,10 @@ fi
 # Then the two chained item-edit calls from "Add a card and set its fields".
 ```
 
-**Convert** it to an issue only after the advisory is **published**. The web UI
-has "Convert to issue" on the card; the API equivalent is:
+**Convert** it to an issue when its fix is ready to merge, keeping its opaque
+title; a follow-up card converts only after the advisory is **published**. When
+each happens, and what the issue gets, is the `/security-advisory` flow. The web
+UI has "Convert to issue" on the card; the API equivalent is:
 
 ```sh
 REPO_ID=$(gh api repos/modelcontextprotocol/servers --jq .node_id) || REPO_ID=

.claude/skills/release/SKILL.md

@@ -256,11 +256,25 @@ gh workflow run prepare-python-release.yml --repo modelcontextprotocol/servers \
 It opens a PR that starts with `Closes #N`, on a branch named
 `v2/chore/<N>-python-calver-<date>`, labeled `v2`, and dispatches the
 TypeScript, Python and DCO workflows on that branch, as the Version Packages
-workflow does (not the Everything diff, whose paths it never touches). Wait
-for its three `(dispatched)` statuses to pass, check that each stamped package really
-changed, and a maintainer merges it.
+workflow does (not the Everything diff, whose paths it never touches).
 No PR means no Python server has a shipped change since its last stamp.
 
+Then, on the PR:
+
+1. **Link it to the release issue.** Its `Closes #N` is only a
+   cross-reference on `v2/main`, and the workflow makes no API call, so link
+   it with the `addCloseIssueReferences` mutation from `/pr-flow` (step 6)
+   and read it back: `closingIssuesReferences` must list `#N`. On `v2/main`
+   it closes nothing at merge. Find the PR by its branch:
+
+   ```sh
+   gh pr list --repo modelcontextprotocol/servers --base v2/main \
+     --json number,headRefName,url \
+     | jq --arg p "v2/chore/$N-python-calver-" '.[] | select(.headRefName | startswith($p))'
+   ```
+2. **Wait for its three `(dispatched)` statuses to pass**, check that each
+   stamped package really changed, and a maintainer merges it.
+
 ⚠️ GitHub only dispatches a workflow that exists on the default branch. Until
 the first milestone merge carries this one to `main`, do it by hand, which is
 the same script:
@@ -274,7 +288,9 @@ node scripts/prepare-python-release.mjs     # prints "name: old -> new" per stam
 git commit -s -am "chore: stamp Python CalVer versions for $(date -u +%Y.%-m.%-d)"
 ```
 
-then open the PR through `/pr-flow`, body starting `Closes #N`.
+then open the PR through `/pr-flow`, body starting `Closes #N`. Its step 6
+links the PR to the release issue and reads the link back, as step 1 above
+does for the workflow's PR: do not skip it.
 
 ## 3. The merge PR: `v2/main` → `main`
 
@@ -453,12 +469,35 @@ gh issue list --repo modelcontextprotocol/servers --milestone "$MILESTONE" \
   before and after.
 
 **4d. The ledger.** Write the results up as a published artifact (a private
-page, shared with the maintainers) and link it from the merge PR's body. It
-holds:
+page, shared with the maintainers) and link it from the merge PR's body.
+
+**Title it `Servers vX.Y.Z Release Ledger`**, the milestone's version, in both
+the page's `<title>` and its `<h1>`.
+
+**Start from the previous release's ledger**, so every ledger reads as one
+series. It is linked from the latest published Release's notes, on the
+`Release ledger:` line (5a):
+
+```sh
+gh release view --repo modelcontextprotocol/servers --json tagName,body \
+  --jq '.tagName, (.body | split("\n")[] | select(startswith("Release ledger:")))'
+```
+
+Read that page (the artifact tool's read action), and build the new one on its
+stylesheet and section structure, changing the content only. This skill
+deliberately names no ledger URL: the latest Release always points at the
+current one, and a URL written here would go stale with the next release.
+
+It holds, in this order:
 
 - **Masthead**: repository, the merge PR and its commit, the milestone, the
   date, and a line saying what tree was tested and that its hash matches
-  `origin/v2/main`.
+  `origin/v2/main`. Two more lines:
+  - **SDKs**: the MCP SDK versions the lockfiles hold (each
+    `@modelcontextprotocol/*` SDK package, and Python `mcp`).
+  - **Toolchain**: the versions used to verify: Node (with OS and
+    architecture), uv, the Inspector CLI and web UI, Playwright, Docker and
+    Claude Code.
 - **Verdict**: `local:gate` and `pack:verify` results, milestone issues
   verified as `N / N`, findings.
 - **The gate**: one cell per stage, with its numbers.
@@ -469,13 +508,34 @@ holds:
   (`node scripts/npm-publish-guard.mjs src/<server>` for npm; for PyPI,
   `curl -s -o /dev/null -w '%{http_code}' https://pypi.org/pypi/<name>/<version>/json`,
   where 404 means it will publish).
-- **One table per theme**: *Issue · What was driven · Observed · Status*. One
-  row per closed issue, linked, with the actual output in the Observed cell.
+- **One table per theme** (a server, a group of servers, or the tooling),
+  with the columns *Issue · Title · What was driven · Observed · Status*. One
+  row per closed issue. The Issue cell links it and is tagged with how it was
+  exercised: `client` (the Inspector CLI or an SDK client), `web UI` (the
+  Inspector web UI through Playwright) or `probe`. The Observed cell holds the
+  actual output. Status is a pill: `PASS`, or a named exception.
+- **Preparation PRs**: the audit PR (or, when the audit forced no fix, its
+  report), Version Packages and Prepare Python Release, each with what was
+  checked on it.
+- **Tool schemas against the previous release**: each TypeScript server's
+  `tools/list` (input and output schemas, annotations and descriptions)
+  compared with the version the previous release published, in both eras.
+- **LLM client**: one headless Claude Code run (`--strict-mcp-config`)
+  calling one tool on each of the seven release-candidate builds, with what
+  each returned (`/client-smoke`).
+- **Also shipping: advisory fixes**: each fix that shipped through a security
+  advisory rather than a milestone issue.
 - **Findings**: anything that is a caveat rather than a pass, stated on its
   own.
 
 A row that says "verified" without saying what was run is not a ledger entry.
 
+**A second merge PR.** When a fix lands after the first merge PR merged (4e;
+in v2.2.0, #5342 followed #5338 for a `certifi` lockfile bump), the masthead
+names both merge PRs with their heads, and the page says which checks ran on
+which head and what differs between the two trees
+(`git diff --stat <first head> <second head>`).
+
 **4e. When verification finds something, the fix goes on `v2/main`, never on
 the merge branch.** File the issue (`/issue-create`), fix it through an
 ordinary PR, then fast-forward the merge branch to the new `origin/v2/main`,
@@ -539,8 +599,8 @@ added to the draft by hand:
 
 - **Every advisory this release fixes**, as `--advisory GHSA-xxxx-yyyy-zzzz`,
   once each: the `[GHSA-…]` cards on the board for the milestone's work
-  (`security-advisory`). Its fix shipped from a private fork with no public
-  issue, so its reporters are no issue's author. A draft advisory works.
+  (`security-advisory`). Its issue is converted from the card by a
+  maintainer, so its reporters are no issue's author. A draft advisory works.
 - **Every outside contributor credited on one of the milestone's issues**, as
   `--thank "@login (#PR), <what it prototyped>, for #ISSUE"`, once per line
   of the prototype paragraph. The preview lists each candidate (below).