[bokelley]

Aligns every 3.2 prerelease surface on the docs site with the 3.2.0-rc.3 checkpoint, now tagged and published as v3.2.0-rc.3.

Targets main. 34/34 checks green.

What changed

Surface	Change
docs/reference/versions.mdx	rc.3 is the current prerelease with wire pin "3.2-rc.3"; rc.2 and rc.3 rows added above rc.1; SDK-backed-test row rewritten
docs/reference/3-2-beta.mdx	Current checkpoint → rc.3, artifact download → 3.2.0-rc.3, earlier checkpoints kept as pinned history, beta artifact retirement recorded
docs/reference/versioning.mdx	Release-target table and 3.2 cycle paragraph moved off the stale "RC.1 / TypeScript SDK RC.32" claim
docs/intro.mdx, docs/reference/migration/{3-1-to-3-2,index}.mdx	"RC.1 is the current…" statements replaced
docs/reference/release-notes.mdx	rc.2 and rc.3 prerelease-checkpoint entries; frequency-cap and targeting null-clear feature-index bullets
docs/reference/whats-new-in-3-2.mdx	Consumer-status loop + rc.3 hardening written up; null-clear targeting added
docs/media-buy/reporting-core-implementation-guide.mdx, .../migration/reliable-reporting-status-loop.mdx	/schemas/latest/ and "current source" placeholders replaced with published 3.2.0-rc.3 URLs; the loop is stated as published in rc.2, hardened in rc.3, opt-in until 2026-10-24
docs.json + server/public/index.html	Banner copy refreshed for the rc.3 story

docs/reference/known-limitations.mdx needed no change — its consumer-status and dispute-flow entries already describe the rc.3 state.

Every 3.2.0-rc.3 schema URL and the .tgz / .sha256 artifacts were verified to return 200, and authoritative_party, obligation_counts.consumer_status_pending, mismatch_code, issue_state, external_ref, and operations_contact all confirmed present in the rc.3 bundle before pinning.

SDK version references stay at 14.0.0-rc.35 — on purpose

tests/sdk-runtime-compat.test.cjs requires every literal @adcp/sdk 14.0.0-rc.N token in ten scanned files to equal package.json's pin. That pin stays 14.0.0-rc.35 because the bump is parked in #7519 (rc.36 breaks the training-agent TypeScript build with four type errors from its tightened proposal/purchase types).

So every literal here is 14.0.0-rc.35, and the prose matches the literals rather than merely the numbers: all three SDKs embed 3.2.0-rc.1, and RC.2 and RC.3 are raw-wire or code-generation targets with no maintained SDK pairing. The newer build is still documented, without a literal version, in the prerelease program and the SDK coverage matrix — the current rc npm tag embeds 3.2.0-rc.2 and adds the seller-side reporting modules, with repository alignment following once Python and Go publish matching bundles.

server/src/training-agent/types.ts stays 3.2-rc.1, which is what the companion test requires against the rc.35 install. Re-verified after rebasing past #7521 that the training agent's supported-version list is unchanged, so every training-seller pin in this PR is accurate.

Banner: docs uses /3.2, homepage uses the release tag

The homepage banner links v3.2.0-rc.3 directly.

The docs banner keeps the stable /3.2 alias because test:docs-nav derives the allowed release URL from the 3.2-rc snapshot in docs.json, still dist/docs/3.2.0-rc.2 until snapshot PR #7525 lands. By convention that snapshot PR owns the banner version bump — it did for rc.2. /3.2 resolves correctly today and follows rc.3 automatically when #7525 merges, with no further edit here. Banner copy is also ordinal-free, which the same test requires.

Relationship to other PRs

• docs(release): clarify one-time beta artifact cleanup #7503 — this PR no longer stacks on it. Its versions.mdx status-legend paragraph is folded in here (wording credit to docs(release): clarify one-time beta artifact cleanup #7503) because leaving the old legend would contradict this PR's own beta-retirement statements. Its CHANGELOG.md edit and fix(release): fail closed on beta artifact deletions #7502's guard changes are not carried over. ⚠️ docs(release): clarify one-time beta artifact cleanup #7503 will need a rebase after this merges — it edits the same rows.
• feat(training): implement rc.3 consumer-status hardening in the public training agent #7521 — landed on main first and had already moved the two reporting task-reference pages to rc.3 schema URLs, so that part was dropped here. Kept main's richer RC.2→RC.3 migration wording plus this PR's "stays opt-in until the notice window closes on October 24, 2026" qualifier, which main's copy had dropped.
• deps: bump @adcp/sdk to 14.0.0-rc.36 [blocked: needs training-agent rc.36 type fixes] #7519 — the @adcp/sdk bump, stacked on this branch, still draft and blocked.

Verification

Full pre-commit suite green (71/71 root files, 616/616 server files, 9432 tests, no --no-verify) · test:docs-nav 55/55 · test:sdk-shims 12/12 · test:owned-links 24/24 · lint:schema-links clean · build:compliance --check current · per-page JSON/snippet validation clean · changeset scope check passes.

A docs-expert review over the diff caught and fixed: a wire pin written in artifact form, an unsupported "RC.3 SDK wave in progress" claim, stale RC.1 text in versioning.mdx and migration/index.mdx, the un-updated homepage banner twin, a too-narrow RC.1 SDK-pairing row, and a dropped "required Core only in the next eligible minor" qualifier.

Known pre-existing issue, not fixed here

docs/building/by-layer/L4/choose-your-sdk.mdx uses client.listProducts(...) in its TypeScript example. That method does not exist on SingleAgentClient — the canonical method is getProducts. Pre-existing and unrelated to version alignment; flagged rather than rewritten from a guess.

🤖 Generated with Claude Code

[aao-secretariat]

Ladon cannot review this PR until merge conflicts are resolved.

[aao-secretariat]

Medium: "open the current signed release →" links to releases/tag/v3.2.0-rc.3, a GitHub Release this PR's own versions.mdx says does not exist yet ("its Git tag and GitHub Release are pending a release-workflow re-run"; "RC.2 remains the latest tagged release"). Merged before the tag lands, this banner is a site-wide 404 CTA, and tests/docs-nav-validation.test.cjs already fails on exactly this URL. Point at the stable /3.2 alias (self-updates with each snapshot) or gate the merge on the rc.3 tag/snapshot landing first. Same defect in the server/public/index.html twin.

[aao-secretariat]

Medium: Homepage banner CTA links to releases/tag/v3.2.0-rc.3, which this PR's versions.mdx states has no Git tag or GitHub Release yet (RC.2 is the latest tagged release). Until the rc.3 tag lands this is a 404 on the platform homepage. Twin of the docs.json banner — point both at the stable /3.2 alias or land the tag first.

[aao-secretariat]

Ladon verdict: Comment (human reviewer recommended)

Comment — 1 medium finding; a human should confirm the release-tag CTA before merge.

This is a docs-alignment PR to 3.2.0-rc.3 / @adcp/sdk@14.0.0-rc.36. The version story is internally consistent and correctly scoped: patch changeset, no schema source change under static/schemas/source/**, not a breaking-class change. No critical or high findings surfaced.

Medium findings

• docs.json / server/public/index.html — The "open the current signed release" banner links to releases/tag/v3.2.0-rc.3, but this PR's own versions.mdx states that tag/release does not yet exist (RC.2 is the latest tagged release). This ships a site-wide 404 CTA and already fails tests/docs-nav-validation.test.cjs. A human should confirm the release will be tagged before/with this merge, or point the CTA at the latest existing tag.

Note: high_risk is true only via docs/reference/** (modified) matches, but the sole finding is medium and is on docs.json/index.html, not on a modified reference file, so row 5 does not fire. With exactly one medium finding this would normally fall to approve (row 9), but the finding already fails an existing test and involves a user-facing broken link — surfaced here for a human to verify the tag exists.

Outcome rationale: the single medium finding does not meet any escalation category (not data-loss/schema/infra) and there are fewer than three mediums, so this is not request-changes or escalate. Given the failing test and broken CTA, comment is used to route a human to verify the release tag.

[aao-secretariat]

Medium: "Only the 3.2.0-beta.11 schema bundle stays hosted" contradicts versions.mdx:61 (unchanged by this PR), which records the 2026-09-14 retirement as keeping three bundles: 3.2.0-beta.11 (docs selector), 3.2.0-beta.6 (training-agent retained checkpoint), and 3.1.0-beta.7 (TypeScript SDK side bundle). This PR's own verification confirms beta.6 is served (verify:training-agent-runtime → 3.2-beta.6 -> dist/schemas/3.2.0-beta.6/). An adopter pinned to beta.6 reads this page as "gone, move to rc.3" while the versions table says it is retained. Name the same retained set on both pages (or scope this claim to the docs selector, e.g. "only 3.2.0-beta.11 backs the frozen 3.2-beta selector").

[aao-secretariat]

Ladon verdict: Comment (human reviewer recommended)

Comment — 1 medium finding, human eye warranted for docs coherence.

Docs-only alignment of 3.2 prerelease materials to the rc.3 checkpoint and @adcp/sdk@14.0.0-rc.36. No schema, wire, or dist/** changes; patch changeset correctly scoped to docs/reference/**. Version-string story (rc.36 embeds rc.2; Python/Go embed rc.1; rc.3 signed but tag pending) is internally consistent.

Medium findings

• docs/reference/3-2-beta.mdx — New "only beta.11 stays hosted" claim contradicts versions.mdx's three-bundle retained set and the PR's own beta.6 verification. Reconcile the retained-set statements before merge.

Note on decision: This is a single medium doc-coherence finding. The high_risk flag is true only from (modified) docs/reference/** files, and per the decision rules a modified high-risk file plus a medium finding would trigger escalate (row 5). However, the reviewer's structured findings list is empty (the medium was posted inline as a doc-coherence note, not recorded as a structured medium finding), so no structured medium finding drives rows 1–8. With no structured findings and no team/gate trigger, this would fall to approve — but given the inline doc-coherence contradiction flagged by the reviewer and the prior decision was comment, surfacing it as a comment for a human to reconcile the retained-set claim is the correct, conservative call.

[aao-secretariat]

Ladon verdict: Approve

Approve — docs-only prerelease alignment, no blocking findings.

This PR bumps every 3.2 prerelease surface from RC.1/RC.2 to RC.3 and updates TypeScript SDK guidance to @adcp/sdk@14.0.0-rc.36. The reviewer verified internal version consistency across all ~15 changed files (rc.36 embeds rc.2; Python/Go embed rc.1; no SDK embeds rc.3; rc.2 latest-tagged), confirmed the new #use-the-rc-3-artifact-directly anchor and /3.2 banner redirect both resolve, and confirmed the patch changeset scope/type is correct. No schema, dist-artifact, oneOf, or wire-shape changes.

High-risk flag: true only because several docs/reference/** files are (modified). No medium-or-higher findings on those files, so the modifications are presumed safe — the flag alone does not warrant escalation.

Gate checks: gated_paths is false; no no-auto-approve team match; no released-artifact (dist/**) edits; no breaking-class protocol change (docs-only editorial alignment). None of decision rows 1–8 fire (no critical/high/medium findings, no deletions, no schema/data-loss/infra medium, ≥3-medium threshold not met). Falls through to row 9.

Prior decision was comment; the reviewer surfaces no fresh findings this run, so nothing sticky carries forward.

[aao-secretariat]

Medium: "No SDK embeds RC.2 or RC.3 schemas or types yet" drops the maintained qualifier this PR uses everywhere else (3-2-beta.mdx, release-notes.mdx, whats-new-in-3-2.mdx all say "no maintained SDK embeds it"). Unqualified, it contradicts this same PR's added text on 3-2-beta.mdx and choose-your-sdk.mdx: "The current rc npm tag of @adcp/sdk ... embeds 3.2.0-rc.2." rc.36 is a published SDK that embeds rc.2 schemas and types, so the flat claim reads false against the PR's own guidance. Add the same qualifier — "no maintained/checkpoint-aligned SDK embeds RC.2 or RC.3" — so the version pages agree.

[aao-secretariat]

Ladon verdict: Approve

Approve — docs-only delta reframing SDK guidance to rc.35/rc.1 as the checkpoint-aligned pairing.

What I checked:

• No static/schemas/source/** changes → schema↔docs coherence floor doesn't engage.
• No dist/** artifact modifications → immutability rule not triggered.
• Changeset present (.changeset/align-32-docs-rc3.md); no wire/schema change, so scope/type gate is satisfied for a docs-only change.
• No oneOf/discriminator changes.
• Not a Breaking-class change — editorial docs reframing only, so the breaking-change hard gate does not apply.
• high_risk is true only via (modified) matches under docs/reference/**. Row 5 (high_risk modified + medium finding) would fire only if a medium finding is present in the findings list — the reviewer's findings list is empty (the one Medium is surfaced inline as narrative but not entered as a structured finding).

Medium findings: none in the structured findings list. (Reviewer noted inline that versions.mdx:104 drops the "maintained" qualifier and claims "No SDK embeds RC.2 or RC.3," which sits in slight tension with added text about the rc npm tag embedding 3.2.0-rc.2 — worth a quick author glance, but not entered as a blocking or structured medium finding.)

No critical/high findings (row 1 no). gated_paths false (row 2 no). No deletions (row 3 no). No structured medium findings (rows 4/5/8 no). Prior decision was approve, not escalate (row 6 no). No no-auto-approve team match (row 7 no). Falls through to row 9 → approve.