docs(sdk): Fix anchor references to review-ci

Update playbook links to match new section IDs after spec rewrite.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

Author: stephanie-anderson

develop-docs/sdk/getting-started/playbooks/development/handling-a-regression.mdx

@@ -72,7 +72,7 @@ This helps identify gaps in testing, review processes, or monitoring that can be
 
 - [Post-release monitoring](/sdk/getting-started/standards/coordination-maintenance#post-release-monitoring) — monitoring that detects regressions
 - [Rollback procedures](/sdk/getting-started/standards/coordination-maintenance#rollback-procedures) — emergency rollback process
-- [Release Gating Criteria](/sdk/getting-started/standards/review-ci#release-gating-criteria) — gates that may be expedited for critical patches
+- [Release Gating Criteria](/sdk/getting-started/standards/review-ci#release-gating) — gates that may be expedited for critical patches
 
 ---
 

develop-docs/sdk/getting-started/playbooks/development/handling-external-contributor-pr.mdx

@@ -35,7 +35,7 @@ Related resources:
 
 #### 1. Triage within 2 business days
 
-([Review SLAs](/sdk/getting-started/standards/review-ci#review-slas)). Every external PR **REQUIRES** a timely, substantive response.
+([Review SLAs](/sdk/getting-started/standards/review-ci#code-review)). Every external PR **REQUIRES** a timely, substantive response.
 
 #### 2. Check for a linked issue
 
@@ -55,16 +55,16 @@ Review it using the standard process ([Reviewing a PR](/sdk/getting-started/play
 
 #### 6. When requesting changes
 
-You **MUST** be specific, use LOGAF prefixes ([Review feedback conventions](/sdk/getting-started/standards/review-ci#review-feedback-conventions)), and explain *why* — so the contributor (or their AI tool) can address the feedback effectively.
+You **MUST** be specific, use LOGAF prefixes ([Review feedback conventions](/sdk/getting-started/standards/review-ci#code-review)), and explain *why* — so the contributor (or their AI tool) can address the feedback effectively.
 
 #### 7. Closing fast is kind
 
 A 30-second close with a clear, respectful reason is better than a PR that sits open for weeks with no response. That respects everyone's time.
 
 ## Referenced Standards
 
-- [Review SLAs](/sdk/getting-started/standards/review-ci#review-slas) — timely response requirements
-- [Review feedback conventions](/sdk/getting-started/standards/review-ci#review-feedback-conventions) — LOGAF scale for feedback
+- [Review SLAs](/sdk/getting-started/standards/review-ci#code-review) — timely response requirements
+- [Review feedback conventions](/sdk/getting-started/standards/review-ci#code-review) — LOGAF scale for feedback
 - [PR description quality](/sdk/getting-started/standards/code-submission#pr-description-quality) — linked issue requirement
 
 ---

develop-docs/sdk/getting-started/playbooks/development/opening-a-pr.mdx

@@ -75,7 +75,7 @@ When green, mark the PR as ready for review.
 
 #### 9. Assign 1–2 reviewers
 
-If the PR touches public API, dependencies, or security-sensitive areas, you **MUST** assign an @sdk-seniors reviewer ([Required reviewers](/sdk/getting-started/standards/review-ci#required-reviewers)).
+If the PR touches public API, dependencies, or security-sensitive areas, you **MUST** assign an @sdk-seniors reviewer ([Required reviewers](/sdk/getting-started/standards/review-ci#code-review)).
 
 ## Referenced Standards
 
@@ -87,7 +87,7 @@ If the PR touches public API, dependencies, or security-sensitive areas, you **M
 - [Changelog entry](/sdk/getting-started/standards/code-submission#changelog-entry) — user-facing change documentation
 - [One logical change per PR](/sdk/getting-started/standards/code-submission#one-logical-change-per-pr) — focused PR scope
 - [Documentation-with-code](/sdk/getting-started/standards/repository-docs#documentation-with-code) — docs PR requirements
-- [Required reviewers](/sdk/getting-started/standards/review-ci#required-reviewers) — @sdk-seniors review triggers
+- [Required reviewers](/sdk/getting-started/standards/review-ci#code-review) — @sdk-seniors review triggers
 - [Test requirements by change type](/sdk/getting-started/standards/code-quality#test-requirements-by-change-type) — test coverage requirements
 
 ---

develop-docs/sdk/getting-started/playbooks/development/reviewing-a-pr.mdx

@@ -63,11 +63,11 @@ You **SHOULD** use the [`sentry-skills:code-review`](https://github.com/getsentr
 
 #### 4. Check for @sdk-seniors review triggers
 
-([Required reviewers](/sdk/getting-started/standards/review-ci#required-reviewers)): public API changes, new dependencies, schema changes, security-sensitive code, new frameworks. If any apply and no @sdk-seniors reviewer is assigned, flag it.
+([Required reviewers](/sdk/getting-started/standards/review-ci#code-review)): public API changes, new dependencies, schema changes, security-sensitive code, new frameworks. If any apply and no @sdk-seniors reviewer is assigned, flag it.
 
 #### 5. Use LOGAF prefixes on all feedback
 
-You **MUST** use LOGAF prefixes on all feedback ([Review feedback conventions](/sdk/getting-started/standards/review-ci#review-feedback-conventions)):
+You **MUST** use LOGAF prefixes on all feedback ([Review feedback conventions](/sdk/getting-started/standards/review-ci#code-review)):
 - `h:` (high) — must fix before merge. Bugs, security issues, breakage, data loss.
 - `m:` (medium) — should fix. Design concerns, missing tests, unclear code.
 - `l:` (low) — optional nit. Style preferences, minor suggestions.
@@ -78,9 +78,9 @@ You **MUST NOT** block for style preferences. The goal is risk reduction, not pe
 
 ## Referenced Standards
 
-- [Review feedback conventions](/sdk/getting-started/standards/review-ci#review-feedback-conventions) — LOGAF scale and blocking criteria
-- [Required reviewers](/sdk/getting-started/standards/review-ci#required-reviewers) — @sdk-seniors review triggers
-- [Required CI checks baseline](/sdk/getting-started/standards/review-ci#required-ci-checks-baseline) — minimum CI requirements
+- [Review feedback conventions](/sdk/getting-started/standards/review-ci#code-review) — LOGAF scale and blocking criteria
+- [Required reviewers](/sdk/getting-started/standards/review-ci#code-review) — @sdk-seniors review triggers
+- [Required CI checks baseline](/sdk/getting-started/standards/review-ci#required-ci-checks) — minimum CI requirements
 - [Test requirements by change type](/sdk/getting-started/standards/code-quality#test-requirements-by-change-type) — test coverage expectations
 - [Test quality](/sdk/getting-started/standards/code-quality#test-quality) — meaningful assertion requirements
 - [PR description quality](/sdk/getting-started/standards/code-submission#pr-description-quality) — description content requirements

develop-docs/sdk/getting-started/playbooks/development/reviewing-ai-generated-code.mdx

@@ -53,7 +53,7 @@ Public API, dependencies, schema changes, security-sensitive code, frameworks.
 
 #### 5. Use LOGAF prefixes on feedback
 
-([Review feedback conventions](/sdk/getting-started/standards/review-ci#review-feedback-conventions))
+([Review feedback conventions](/sdk/getting-started/standards/review-ci#code-review))
 
 #### 6. Approve when only `l:` items remain
 
@@ -91,7 +91,7 @@ You **SHOULD** use the [`sentry-skills:find-bugs`](https://github.com/getsentry/
 
 ## Referenced Standards
 
-- [Review feedback conventions](/sdk/getting-started/standards/review-ci#review-feedback-conventions) — LOGAF scale and blocking criteria
+- [Review feedback conventions](/sdk/getting-started/standards/review-ci#code-review) — LOGAF scale and blocking criteria
 - [Test requirements by change type](/sdk/getting-started/standards/code-quality#test-requirements-by-change-type) — test coverage expectations
 - [Test quality](/sdk/getting-started/standards/code-quality#test-quality) — meaningful assertion requirements
 - [AI attribution](/sdk/getting-started/standards/code-submission#ai-attribution) — Co-Authored-By footer requirement

develop-docs/sdk/getting-started/playbooks/sdk-lifecycle/cutting-a-release.mdx

@@ -39,7 +39,7 @@ Related resources:
 
 #### 1. Verify release gating criteria
 
-You **MUST** verify all criteria pass ([Release gating criteria](/sdk/getting-started/standards/review-ci#release-gating-criteria)):
+You **MUST** verify all criteria pass ([Release gating criteria](/sdk/getting-started/standards/review-ci#release-gating)):
 - All required CI checks pass on the default branch
 - No unresolved `h:` (high) review comments on merged PRs since last release
 - Changelog is substantive (not empty or internal-only for a release with user-facing changes)
@@ -111,7 +111,7 @@ Common SDK-specific variations include:
 
 ## Referenced Standards
 
-- [Release gating criteria](/sdk/getting-started/standards/review-ci#release-gating-criteria) — pre-release quality gates
+- [Release gating criteria](/sdk/getting-started/standards/review-ci#release-gating) — pre-release quality gates
 - [Post-release monitoring](/sdk/getting-started/standards/coordination-maintenance#post-release-monitoring) — monitoring requirements and timeline
 - [Rollback procedures](/sdk/getting-started/standards/coordination-maintenance#rollback-procedures) — emergency rollback process
 

develop-docs/sdk/getting-started/playbooks/setup/setting-up-new-sdk-repo.mdx

@@ -41,7 +41,7 @@ Related resources:
 
 Create the repository in the `getsentry` organization. You **MUST** configure branch protection rules:
 - Require CI checks to pass ([Required CI checks baseline](/sdk/getting-started/standards/review-ci#required-ci-checks))
-- Require at least one approving review ([Required reviewers](/sdk/getting-started/standards/review-ci#required-reviewers))
+- Require at least one approving review ([Required reviewers](/sdk/getting-started/standards/review-ci#code-review))
 
 You **MUST** set up a `CODEOWNERS` file with team members to automatically request reviews.
 
@@ -109,7 +109,7 @@ If the tool cannot do this, the documentation needs work.
 - [CONTRIBUTING.md](/sdk/getting-started/standards/repository-docs#contributing-md) — contributor guidelines
 - [PR template](/sdk/getting-started/standards/repository-docs#pr-template) — pull request template structure
 - [AI context file maintenance](/sdk/getting-started/standards/repository-docs#ai-context-maintenance) — maintaining AI-readable documentation
-- [Required reviewers](/sdk/getting-started/standards/review-ci#required-reviewers) — review approval requirements
+- [Required reviewers](/sdk/getting-started/standards/review-ci#code-review) — review approval requirements
 - [Required CI checks baseline](/sdk/getting-started/standards/review-ci#required-ci-checks) — minimum CI pipeline requirements
 - [Commit message format](/sdk/getting-started/standards/code-submission#commit-message-format) — conventional commit format
 - [Linting and formatting in CI](/sdk/getting-started/standards/code-quality#linting-formatting-ci) — automated code style checks

develop-docs/sdk/getting-started/playbooks/setup/setting-up-release-infrastructure.mdx

@@ -129,7 +129,7 @@ For the ongoing release process after setup, see "Cutting a release" (wip).
 
 - [Version format](/sdk/getting-started/standards/release-versioning#version-format) — SemVer requirements
 - [Release tooling](/sdk/getting-started/standards/release-versioning#release-tooling) — Craft and publish setup
-- [Release gating criteria](/sdk/getting-started/standards/review-ci#release-gating-criteria) — Pre-release validation requirements
+- [Release gating criteria](/sdk/getting-started/standards/review-ci#release-gating) — Pre-release validation requirements
 - [Rollback procedures](/sdk/getting-started/standards/coordination-maintenance#rollback-procedures) — Emergency release rollback process
 
 ---