[bokelley]

Problem

The main Build Check for #7854 failed before deployment because static/compliance/published-versions.json still requested @adcp/sdk@beta. npm removed that dist-tag after the SDK GA release, so check:published-compliance exited with ETARGET. The PR check had passed before the tag was removed.

Change

Track the current stable release tags (adcp-3.0, adcp-3.1, adcp-3.2) plus latest and rc. This keeps the publication drift check covering each supported line without relying on the retired beta tag.

Verification

• npm view @adcp/sdk dist-tags --json shows exactly those five tags.
• npm run check:published-compliance passes against the live npm packages.
• node --test tests/published-compliance-versions.test.cjs passes (9/9).
• Changeset protocol scope check passes; this manifest update does not change a versioned schema or compliance bundle.

This hotfix unblocks the automated main Build Check and its dependent Fly deployment for #7854.

---

Open workspace in Conductor

3.2 release-branch bootstrap CI guard

After the 3.2.x branch was cut at the v3.2.1 tag, the GA docs snapshot landed on main. The existing docs-nav parity test then failed on every main PR while the release branch was still at the tag. This PR permits only that exact, immutable tag as a bootstrap state. Once 3.2.x advances, the test again requires its default routes to match main. Companion release PR #7860 carries the GA snapshot to 3.2.x.

• npm run test:docs-nav: 49/49 passing against the tag.
• STABLE_DOCS_REF=origin/3.2-docs-pr npm run test:docs-nav: 49/49 passing against chore(release): register 3.2.x and carry post-tag GA hygiene onto 3.2.x #7860's updated docs surface.
• Local precommit and prepush checks passed at e6bef1792a.

Mainline migration collision

While this PR was in CI, #7841 merged another 615_ migration to main. The compliance webhook receiver lease migration from #7854 is renumbered to 616_ in 8aa6c0a57e. Production was checked read-only and has applied migrations only through 614; its running image predates both 615 files. The repository's full precommit server unit hook and typecheck passed after the rename.

[aao-secretariat]

Ladon verdict: Approve

Approve — one-file operational hotfix to static/compliance/published-versions.json swapping the retired beta npm dist-tag for live adcp-3.1/adcp-3.2 tags, fixing the ETARGET that broke check:published-compliance and the main Build Check.

Checks performed:

• Out of changeset/protocol scope: no static/schemas/source/**, task definitions, normative docs/reference/**, or release scripts touched — no changeset required.
• No dist/** immutable artifact modified.
• Manifest passes validateManifest; synthetic tests unaffected.
• No high-risk paths, no gated paths, no author team gate.

Decision table: No critical/high/medium findings (rows 1, 4, 5, 6, 8 don't fire). gated_paths is false (row 2 N/A). high_risk false (rows 3, 5 N/A). No no-auto-approve team (row 7 N/A). Falls through to row 9 → approve.

Non-blocking follow-up noted by reviewer: re-add beta to npm_tags once the first 3.3 beta publishes.

[aao-secretariat]

Re-approval: no reviewable delta since the prior approval; re-submitting after stale-review dismissal.

[aao-secretariat]

Re-approval: no reviewable delta since the prior approval; re-submitting after stale-review dismissal.

[aao-secretariat]

Ladon verdict: Approve

Approve — clean subsequent pass.

The only delta since the prior clean approve is a pure rename of migration 615_compliance_webhook_receiver_leases.sql → 616_, resolving a mainline numbering collision from #7841. The reviewer verified against migrate.ts that migrations are tracked by integer version PK with fail-closed duplicate-version and filename-mismatch guards, that 616 is the next free number, and that production (applied through 614) applies both migrations cleanly — consistent with renumbering precedent #7678.

Decision table walkthrough:

• Row 1 (critical/high): no findings — skip.
• Row 2 (gated_paths unsatisfied): gated_paths: false — skip.
• Row 3 (high-risk deleted): high_risk is true but the reason is (renamed), treated as a modification, not a deletion — skip.
• Row 4 (medium data-loss/schema/infra): no findings — skip.
• Row 5 (high-risk modified + medium finding): no medium findings — skip.
• Row 6 (sticky escalate): prior decision was approve, not escalate — skip.
• Row 7 (no-auto-approve team): no team match — skip.
• Row 8 (≥3 medium): zero medium findings — skip.
• Row 9: approve.

The high_risk flag is a (renamed) migration change with no reviewer concerns; per the change-kind guidance a rename is treated as a modification and is presumed safe absent a medium-or-higher finding. No blocking or medium findings exist.