test(client): note future ceiling coverage

Author: Coding-Professional

.config/dotnet-tools.json

@@ -3,7 +3,7 @@
   "isRoot": true,
   "tools": {
     "docfx": {
-      "version": "2.78.5",
+      "version": "2.81.0",
       "commands": [
         "docfx"
       ],

.github/agents/release-manager.agent.md

@@ -138,6 +138,31 @@ Stage 5  Verify                                      [verify-release skill, orch
 
 ## Operating rules
 
+- **Separate package and docs provenance.** Packages remain pinned to the exact approved release
+  tag/SHA. Release events and default manual docs runs use each major's discovered release tag.
+  Manual `docs_source=latest-branches` instead selects `origin/release/{MAJOR}.x` for every
+  published major, enabling post-release docs updates without a new product release/tag.
+  Resolve each selected content ref once, validate its major, and log its immutable SHA separately
+  from orchestration; missing refs/mismatches fail without fallback. Servicing follows the latest
+  shipped MINOR, preserving ancestry on promotion. Docs orchestration/scripts/tests/picker assets
+  always come from current `main`, regardless of the triggering ref. Keep shared AI release skills/instructions on
+  `main`, which supports ongoing next-version feature development rather than a fixed next-MAJOR
+  plan. Requiring AI release instructions from trusted `main` prevents an unprotected or untrusted
+  invoking/work branch from overriding the release process. Runtime docs orchestration also uses
+  current `main`, independently of the selected tag/branch content. Follow the shared release branch reference.
+- **PR-only servicing changes.** Initial release-branch establishment starts at an explicitly
+  approved baseline and may require separate creation/push authorization. Every later `release/*` change, including docs,
+  infrastructure, versions, and promotion, must use a reviewed work-branch PR. Never commit/push
+  changes directly to servicing branches or reset/force-push for promotion. Give servicing children
+  the current main-based instructions/reference SHA, not stale forked skills; do not copy shared
+  process files into release content. See [delegation](release-manager/references/delegation.md).
+- **Coordinated releases are opt-in.** When requested, keep per-line targets, versions, PRs,
+  audits, approved SHAs, and CI evidence separate. All approved SHA-pinned drafts must exist before
+  any human publication; publication is not atomic. Agree on the publication order and GitHub Latest
+  designation separately from the docs publication-date default.
+  Require a successful deployed combined run covering all intended labels/content SHAs,
+  not merely a cancelled earlier run. Follow the
+  [shared guidance](../skills/shared-resources/release-branches.md#coordinated-releases-opt-in).
 - **Human-gated and sequential.** Complete stages strictly in order. Never start a stage whose
   predecessor's gate has not been satisfied. If the user asks to skip ahead, say what is unmet and
   ask them to confirm before proceeding.

.github/agents/release-manager/references/delegation.md

@@ -4,15 +4,30 @@ The release-manager session is an **orchestrator**. It stays on whatever branch
 never checks out or mutates a release branch. Work that creates commits happens in a **child session
 on its own worktree**, based on the target release branch.
 
-This mirrors how [`docs.yml`](../../../workflows/docs.yml) already works: the orchestration scripts run
-from a single fixed checkout, while each version's content is built from its own tag in a separate
-worktree.
+In [`docs.yml`](../../../workflows/docs.yml), orchestration/scripts/tests/picker assets come
+from current `main`. Content is built in separate worktrees at immutable full SHAs resolved once
+from each discovered published tag by default, or from `origin/release/{MAJOR}.x` for every major
+when a manual `latest-branches` refresh is selected. Missing refs and major mismatches fail without
+silently substituting another source or `main` content.
+
+Shared AI release instructions also remain on trusted `main`; the child handoff below must not
+substitute stale or untrusted skills from a servicing fork. Do not copy AI process files into
+servicing content merely to propagate runtime infrastructure.
+
+`main` supports ongoing next-version development as well as shared AI release instructions, not a permanent
+next-MAJOR-only plan. Initial release-branch establishment starts at an explicitly approved baseline
+and may require separate creation/push authorization. Every subsequent servicing change, including
+docs/infrastructure and promotion, must use a reviewed work-branch PR into `release/*`; never commit
+or push changes directly there. Promotion preserves ancestry, never reset/force-push. See the
+[shared branch policy](../../../skills/shared-resources/release-branches.md#servicing-branch-changes).
 
 ## Why
 
-- **Current orchestration.** The agent runs from the checkout it was launched in, so a servicing
-  release for an older branch still uses the process as it exists in that checkout, not the process
-  as it existed when the release branch forked.
+- **Trusted, current instructions.** AI release skills/instructions come from trusted `main`,
+  including the version handed to servicing children, not from an unprotected/untrusted work
+  branch or stale servicing fork. This prevents those branches from overriding the release
+  process. Runtime docs infrastructure also uses current `main`. Selecting release-branch content
+  for a manual refresh allows docs updates after publication without a new product release or tag.
 - **A clean working tree.** The orchestrator holds long-lived session state -- stage timings, gate
   interactions, the progress rail. Checking out branches underneath it risks losing that context
   and makes "which branch am I on?" a source of error at exactly the moment precision matters.
@@ -89,6 +104,18 @@ The child's kickoff prompt must carry everything it needs, because it does not s
    the previous release tag is not an ancestor of the target.
 7. The requirement to **stop at the skill's Step 10b gate** and bring the categorization table and
    acknowledgements roster back to you, so the user reviews notes content before a PR exists.
+8. The current **main-based release instructions and reference version**: record the full
+   orchestration SHA and provide the relevant skill/reference content or read-only paths from that
+   main checkout. Require the child to follow that version, not blindly invoke stale skills in its
+   servicing fork. If main references are inaccessible, report the blocker instead of substituting
+   old instructions. Do not copy shared process files into servicing content.
+
+For user-requested coordinated releases, apply the
+[opt-in coordination guidance](../../../skills/shared-resources/release-branches.md#coordinated-releases-opt-in).
+Keep each child's target/version/PR/audit/CI evidence separate; all approved SHA-pinned drafts
+must exist before any human publication. Agree on the order and intended GitHub Latest designation
+separately from the docs publication-date default. Publication is not atomic, and a superseding
+combined docs deployment must prove coverage of all intended releases.
 
 If app-native child sessions are not available in the current environment, fall back to a git
 worktree created from the source/base branch and run the skill there, keeping the orchestrator's

.github/agents/release-manager/references/monitoring.md

@@ -161,6 +161,13 @@ If the user says they published but the API still reports a draft, trust the API
 
 ### Stage 4 handoff
 
+Before inviting publication, confirm the planned tag's content major matches. Release-triggered
+docs use discovered tags for all published majors; manual runs can select `latest-branches` instead.
+Missing selected refs and major mismatches fail without fallback. A missing branch blocks branch-mode
+refreshes, not tag-mode publication; obtain separate approval for any branch creation/push.
+Runtime scripts/tests/picker assets and trusted AI release instructions come from current `main`,
+independent of the triggering tag or manual ref.
+
 Hand off with the action and the watch, so the user knows they do not need to come back and report:
 
 > The draft release for **v2.1.0** is ready. Review the notes line by line, set the prerelease flag

.github/agents/release-manager/references/summary-template.md

@@ -1,8 +1,8 @@
 # Release Wrap-Up Summary
 
 Present this summary when the release is complete: the GitHub release is published, both the release
-and docs workflows have succeeded, the packages are listed on NuGet.org, and the docs site reflects
-the release.
+and docs workflows have succeeded, the exact released package version is listed on NuGet.org, and
+the docs site reflects the release.
 
 The tone is short and celebratory. It is a chat message to the user -- **do not commit it, do not
 post it to GitHub, and do not write it to a file** unless the user explicitly asks.
@@ -27,6 +27,7 @@ Build the timing sections from the `release_stages`, `release_interactions`, `re
 | Release | {release URL} |
 | Release workflow | {run URL} — {conclusion} |
 | Docs workflow | {run URL} — {conclusion} |
+| Docs provenance | Orchestration: `main` at `{HEAD-SHA}`; selected source: `{release-tags or latest-branches}`; content: `{ref}` at `{SHA}` for each published major |
 | NuGet | {listed package versions, or the package listing URL} |
 | Docs | https://csharp.sdk.modelcontextprotocol.io/{version-slug}/ — live |
 

.github/release-process.md

@@ -30,13 +30,25 @@ Review the draft release on GitHub, check 'Set as a pre-release' if appropriate,
 
 ## Branching
 
-The `main` branch is the next-MAJOR preview and development line; currently, it produces the `2.0.0-preview.*` series. Nightly `cron` CI on `main` publishes CI-suffixed packages to GitHub Packages.
-Long-lived `release/{MAJOR}.x` branches are created on demand when a shipped MAJOR needs servicing releases. Every push to a `release/*` branch publishes a CI-suffixed package to GitHub Packages, so servicing CI packages are commit-driven rather than clock-driven.
+The `main` branch supports ongoing next-version feature development and owns shared AI release-process instructions; this does not prescribe a next-MAJOR version plan. Nightly `cron` CI on `main` publishes CI-suffixed packages to GitHub Packages.
+Long-lived `release/{MAJOR}.x` branches track the latest shipped MINOR within each MAJOR and supply documentation content when a branch refresh is selected. Every push to a `release/*` branch publishes a CI-suffixed package to GitHub Packages, so servicing CI packages are commit-driven rather than clock-driven.
+Initial release-branch establishment starts at an explicitly approved baseline and may require separate creation/push authorization. Every subsequent change to `release/*` — fixes, docs, infrastructure, versions, or promotions — goes through a reviewed work-branch PR, never direct commits/pushes to the servicing branch. Promotion to an approved newer MINOR preserves servicing ancestry through that PR, not reset/recreation or force-push.
+Keep shared AI release automation skills and instructions on trusted `main`; servicing children follow the current main-based instructions, not stale or untrusted forked skills. Do not copy shared process files into release content. Runtime docs scripts, fixture tests, and picker assets also come from current `main`, independent of the triggering workflow ref.
 Short-lived `release-{version}` branches are local prepare-release work branches that become pull requests, such as `release-2.0.0-preview.1` or `release-1.3.1`.
 Official NuGet.org publishes occur only when a GitHub Release is created from a branch's tag.
 The prepare-release skill asks for the source/base branch first so the release PR targets the same line it assessed.
 For the agent-facing, structured version of these rules, see [release-branches.md](skills/shared-resources/release-branches.md).
 
+### Coordinated releases (opt-in)
+
+When the user requests multiple lines ship together, keep each line's targets, versions, approved
+SHAs, PRs, audits, and CI evidence separate, and prepare all approved SHA-pinned drafts before
+any human publication. Publication is not atomic; agree on the publication order and intended
+GitHub Latest designation. A newer combined docs deployment must demonstrably
+cover all intended labels and recorded selected-content SHAs; a cancelled earlier run alone is not
+success. Package checks remain exact-tag checks, and GitHub Latest is distinct from the docs default
+by publication date. See the [shared coordinated-release guidance](skills/shared-resources/release-branches.md#coordinated-releases-opt-in).
+
 ## 4. Verify the release
 
 Publishing the release triggers two workflows in parallel. Invoke the `verify-release` skill to
@@ -45,11 +57,15 @@ monitor both and confirm their published outputs:
 - **Release** — produces build artifacts and publishes the NuGet packages to NuGet.org. If the job
   fails, troubleshoot and re-run the workflow as needed. Verify the package version becomes listed
   at [nuget.org/packages/ModelContextProtocol](https://www.nuget.org/packages/ModelContextProtocol).
-- **[Publish Docs](workflows/docs.yml)** — rebuilds the versioned documentation site from the
-  published release tags and deploys it to
+- **[Publish Docs](workflows/docs.yml)** — discovers published majors, labels, and default ordering
+  from GitHub releases, then rebuilds every major's selected content and deploys it to
   [csharp.sdk.modelcontextprotocol.io](https://csharp.sdk.modelcontextprotocol.io). Verify the new
-  version appears in the version picker and that its major-version path serves the updated content.
-  A content-only docs refresh can be run later via manual dispatch. Its `docs_source` input defaults
-  to `release-tags` to mirror a release deployment; select `latest-branches` to refresh every
-  published major from its current `release/{MAJOR}.x` branch, using `main` for its
-  matching major.
+  version appears in the picker and its path reflects the selected source. Orchestration/scripts/
+  tests/picker assets always come from current `main`, with its HEAD SHA logged separately from
+  content SHAs. Release events and default manual runs use `release-tags`; a manual
+  `docs_source=latest-branches` refresh uses `origin/release/{MAJOR}.x` for every published major.
+  All selected refs resolve once to full SHAs and their `VersionPrefix` majors must match; missing
+  refs or mismatches fail without fallback. After explicit approval, refresh with
+  `gh workflow run docs.yml --ref main --field docs_source=latest-branches`, or select `release-tags`
+  to rebuild published tag content. Branch mode permits post-release docs updates without a new
+  release/tag. Package verification remains against the exact released tag/SHA.

.github/skills/prepare-release/SKILL.md

@@ -169,6 +169,15 @@ Generate a human-readable diff of the public API surface between the previous re
 
 ### Step 9: Review and Update Documentation
 
+Published docs use discovered release tags by default; a manual `latest-branches` selection uses
+`origin/release/{MAJOR}.x` for every published major. Scripts/tests/picker assets always come from
+current `main`, as do trusted AI release instructions. Review selected content and orchestration
+separately. Selected content refs are pinned once and their `VersionPrefix` majors validated, with
+no fallback for missing refs or mismatches. Servicing tracks the latest
+shipped MINOR and promotes to an approved newer MINOR through a reviewed, ancestry-preserving PR.
+Shared release automation skills remain on `main`. See
+[release-branches.md](../shared-resources/release-branches.md#documentation-content-and-orchestration).
+
 Review repository documentation for changes needed to compensate for or adapt to this release:
 
 1. **NuGet package READMEs** -- Run the README content checklist from [references/readme-content.md](references/readme-content.md) and validate code samples: