docs: Add trailing slashes to internal links in develop-docs

.lycheeignore

@@ -66,3 +66,4 @@ https?://empowerplant\.io.*
 
 # Private GitHub repos
 https?://github\.com/getsentry/sdk-skills.*
+https?://github\.com/getsentry/security-as-code.*

develop-docs/getting-started/index.mdx

@@ -4,7 +4,7 @@ description: This documentation serves as reference points for developing agains
 sidebar_order: 1
 ---
 
-We recommend going through the [engineering practices](/engineering-practices) and our [development philosophy](/getting-started/philosophy/) before contributing a change to Sentry.
+We recommend going through the [engineering practices](/engineering-practices/) and our [development philosophy](/getting-started/philosophy/) before contributing a change to Sentry.
 
 
 <DevDocsCardGrid />

develop-docs/sdk/foundations/client/index.mdx

@@ -51,7 +51,7 @@ Related specs:
 - [Scopes](/sdk/foundations/state-management/scopes/) — scope chain and client resolution
 - [Transport](/sdk/foundations/transport/) — envelope delivery
 - [Envelopes](/sdk/foundations/envelopes/) — wire format
-- [Attributes](/sdk/foundations/state-management/scopes/attributes) — attribute type system
+- [Attributes](/sdk/foundations/state-management/scopes/attributes/) — attribute type system
 
 ---
 

develop-docs/sdk/foundations/client/integrations/graphql.mdx

@@ -20,7 +20,7 @@ sidebar_order: 2
 
 ## Overview
 
-GraphQL client integrations should match the guidelines for [HTTP Client Integrations](/sdk/foundations/client/integrations/http-client) with differences described below.
+GraphQL client integrations should match the guidelines for [HTTP Client Integrations](/sdk/foundations/client/integrations/http-client/) with differences described below.
 
 ---
 

develop-docs/sdk/foundations/client/integrations/index.mdx

@@ -26,10 +26,10 @@ Users configure integrations via the `integrations` option in `Sentry.init()`.
 
 Related specs:
 - [Client](/sdk/foundations/client/) — client lifecycle and event pipeline
-- [HTTP Client Integration](/sdk/foundations/client/integrations/http-client) — HTTP client instrumentation guidelines
-- [GraphQL Integration](/sdk/foundations/client/integrations/graphql) — GraphQL client instrumentation guidelines
-- [Feature Flags Integration](/sdk/foundations/client/integrations/feature-flags) — feature flag tracking guidelines
-- [Modules Integration](/sdk/foundations/client/integrations/modules) — loaded library and version reporting
+- [HTTP Client Integration](/sdk/foundations/client/integrations/http-client/) — HTTP client instrumentation guidelines
+- [GraphQL Integration](/sdk/foundations/client/integrations/graphql/) — GraphQL client instrumentation guidelines
+- [Feature Flags Integration](/sdk/foundations/client/integrations/feature-flags/) — feature flag tracking guidelines
+- [Modules Integration](/sdk/foundations/client/integrations/modules/) — loaded library and version reporting
 
 ---
 

develop-docs/sdk/foundations/client/integrations/mcp/index.mdx

@@ -6,5 +6,5 @@ The MCP Server module instruments Anthropic's Model Context Protocol (MCP) SDKs.
 
 ## Features
 
-- [Tracing](./tracing)
-- [Errors](./errors)
+- [Tracing](./tracing/)
+- [Errors](./errors/)

develop-docs/sdk/foundations/processing/batch-processor.mdx

@@ -38,7 +38,7 @@ The BatchProcessor **MUST** forward all spans and logs in memory to the transpor
 2. When the user calls  `SentrySDK.close()`, the BatchProcessor **MUST** forward all data in memory to the transport. SDKs **SHOULD** keep their existing closing behavior.
 3. When the application shuts down gracefully, the BatchProcessor **SHOULD** forward all data in memory to the transport. The transport **SHOULD** keep its existing behavior, which usually stores the data to disk as an envelope. It is not required to call a transport `flush`. This is mostly relevant for mobile SDKs already subscribed to these hooks, such as [applicationWillTerminate](https://developer.apple.com/documentation/uikit/uiapplicationdelegate/applicationwillterminate(_:)) on iOS.
 4. When the application moves to the background, the BatchProcessor **SHOULD** forward all the data in memory to the transport and stop the timer. The transport **SHOULD** keep its existing behavior, which usually stores the data to disk as an envelope. It is not required to call the transport `flush`. This is mostly relevant for mobile SDKs.
-5. Mobile SDKs **MUST** minimize data loss when sudden process terminations occur. Refer to the [Mobile Telemetry Processor](/sdk/foundations/processing/telemetry-processor/mobile-telemetry-processor) section for more details.
+5. Mobile SDKs **MUST** minimize data loss when sudden process terminations occur. Refer to the [Mobile Telemetry Processor](/sdk/foundations/processing/telemetry-processor/mobile-telemetry-processor/) section for more details.
 
 The detailed specification is written in the [Gherkin syntax](https://cucumber.io/docs/gherkin/reference/). The specification uses spans as an example, but the same applies to logs or any other future telemetry data.
 

develop-docs/sdk/foundations/state-management/hub-and-scope/index.mdx

@@ -61,7 +61,7 @@ The decision to remove the Hub from all Sentry SDKs was confirmed on 2024-05-03
 
 - **Disabled SDK**: The SDK is considered disabled when the client has no transport. In this state, callbacks like `configure_scope` and event processors **SHOULD NOT** be invoked, and breadcrumbs **SHOULD NOT** be recorded.
 
-- **Automatic Context Data**: SDKs and their integrations automatically populate scopes with useful contextual data such as tags, contexts, and extras. This typically happens by hooking into a framework (e.g., a web framework middleware setting request-related context on the scope). See [Data Scrubbing](/sdk/foundations/data-scrubbing) for considerations around sensitive data.
+- **Automatic Context Data**: SDKs and their integrations automatically populate scopes with useful contextual data such as tags, contexts, and extras. This typically happens by hooking into a framework (e.g., a web framework middleware setting request-related context on the scope). See [Data Scrubbing](/sdk/foundations/data-scrubbing/) for considerations around sensitive data.
 
 ---
 

develop-docs/sdk/foundations/state-management/scopes/index.mdx

@@ -72,7 +72,7 @@ Scopes are the mechanism by which Sentry SDKs propagate contextual data (tags, b
 This model replaces the [Hub & Scope](/sdk/foundations/state-management/hub-and-scope/) model. The Hub is removed; its functionality is absorbed into the three scope types. The design aligns with [OpenTelemetry's Context](https://opentelemetry.io/docs/specs/otel/context/) propagation — an immutable, fork-on-write mechanism that carries execution-scoped values across API boundaries. See [RFC 0122](https://github.com/getsentry/rfcs/pull/122) for the original design.
 
 Related specs:
-- [Attributes](/sdk/foundations/state-management/scopes/attributes) — attribute type system for scope data
+- [Attributes](/sdk/foundations/state-management/scopes/attributes/) — attribute type system for scope data
 - [Breadcrumbs](/sdk/foundations/state-management/scopes/breadcrumbs/) — structured event trail on scopes
 - [Hub & Scope](/sdk/foundations/state-management/hub-and-scope/) — deprecated predecessor
 
@@ -96,7 +96,7 @@ This replaces the manual hub-cloning pattern from the old model. Users no longer
 
 ### Automatic Context Data
 
-SDKs and their integrations automatically populate scopes with useful contextual data such as tags, contexts, and attributes. This typically happens by hooking into a framework (e.g., a web framework middleware setting request-related context on the isolation scope). This automatic enrichment is a key benefit of scopes — users get useful data on events without manual instrumentation. See [Data Scrubbing](/sdk/foundations/data-scrubbing) for considerations around sensitive data.
+SDKs and their integrations automatically populate scopes with useful contextual data such as tags, contexts, and attributes. This typically happens by hooking into a framework (e.g., a web framework middleware setting request-related context on the isolation scope). This automatic enrichment is a key benefit of scopes — users get useful data on events without manual instrumentation. See [Data Scrubbing](/sdk/foundations/data-scrubbing/) for considerations around sensitive data.
 
 ### Scope Chain
 

develop-docs/sdk/getting-started/ai-tools/index.mdx

@@ -20,4 +20,4 @@ This section covers the AI tools available to SDK engineers, how they layer toge
 | **[Sentry CLI](https://docs.sentry.io/ai/sentry-cli/)** | Natural-language issue management | List, inspect, and triage issues from the terminal or an agent |
 | Rules files | Workflow-specific instructions | Fixed conventions that vary by task or directory |
 
-Requirement levels (MUST/SHOULD) are defined in [Repository and Documentation Standards](/sdk/getting-started/standards/repository-docs) and [Review and CI Standards](/sdk/getting-started/standards/review-ci).
+Requirement levels (MUST/SHOULD) are defined in [Repository and Documentation Standards](/sdk/getting-started/standards/repository-docs/) and [Review and CI Standards](/sdk/getting-started/standards/review-ci/).

develop-docs/sdk/getting-started/philosophy/index.mdx

@@ -55,7 +55,7 @@ While we generally should try to keep the API surfaces of SDKs reasonable small.
 Some types of errors cannot be resolved without the data that was given to the program.
 But make sure that auto instrumentations doesn't attach PII without an explicit opt-in from the user.
 The server must be aware of parts of the protocol that include PII to scrub them by default.
-Please check <Link to="/sdk/foundations/data-scrubbing">Data Handling</Link> for more detail.
+Please check <Link to="/sdk/foundations/data-scrubbing/">Data Handling</Link> for more detail.
 
 ## Don't forget the big picture
 

develop-docs/sdk/getting-started/playbooks/coordination/aligning-cross-sdk-changes.mdx

@@ -24,12 +24,12 @@ This playbook guides SDK teams through coordinating changes that affect multiple
 
 Related resources:
 
-- [Cross-SDK Coordination standard](/sdk/getting-started/standards/coordination-maintenance#cross-sdk-coordination) — coordination requirements and process
-- [Managing Linear Projects](/sdk/getting-started/playbooks/coordination/managing-linear-projects) — how to set up and run each per-SDK project created in step 5
-- [Planning and Scoping standard](/sdk/getting-started/standards/planning-scoping) — design-first gate, risk identification, and project naming requirements
-- [Semantic conventions process](/sdk/getting-started/standards/api-architecture#semantic-conventions-process) — process for new attributes
-- [Deprecating an API](/sdk/getting-started/playbooks/sdk-lifecycle/deprecating-an-api) — related playbook for API changes
-- [Deprecating an SDK](/sdk/getting-started/playbooks/sdk-lifecycle/deprecating-an-sdk) — related playbook for full SDK deprecation
+- [Cross-SDK Coordination standard](/sdk/getting-started/standards/coordination-maintenance/#cross-sdk-coordination) — coordination requirements and process
+- [Managing Linear Projects](/sdk/getting-started/playbooks/coordination/managing-linear-projects/) — how to set up and run each per-SDK project created in step 5
+- [Planning and Scoping standard](/sdk/getting-started/standards/planning-scoping/) — design-first gate, risk identification, and project naming requirements
+- [Semantic conventions process](/sdk/getting-started/standards/api-architecture/#semantic-conventions-process) — process for new attributes
+- [Deprecating an API](/sdk/getting-started/playbooks/sdk-lifecycle/deprecating-an-api/) — related playbook for API changes
+- [Deprecating an SDK](/sdk/getting-started/playbooks/sdk-lifecycle/deprecating-an-sdk/) — related playbook for full SDK deprecation
 
 ---
 
@@ -45,7 +45,7 @@ You **MUST** create an RFC or Linear initiative describing:
 - Timeline
 - Open questions
 
-An RFC or initiative proposal is a design document and triggers the [Design-First Gate](/sdk/getting-started/standards/planning-scoping#design-first-gate) standard. It **MUST** also include a risk section per the [Risk Identification](/sdk/getting-started/standards/planning-scoping#risk-identification) standard.
+An RFC or initiative proposal is a design document and triggers the [Design-First Gate](/sdk/getting-started/standards/planning-scoping/#design-first-gate) standard. It **MUST** also include a risk section per the [Risk Identification](/sdk/getting-started/standards/planning-scoping/#risk-identification) standard.
 
 #### 2. Allow cross-SDK review period
 
@@ -57,7 +57,7 @@ You **MUST** allow a minimum of 1 week for all affected SDK teams to review and
 
 #### 3. Land semantic conventions first (if needed)
 
-If the change involves new attributes, you **MUST** land the sentry-conventions PR first ([Semantic conventions process](/sdk/getting-started/standards/api-architecture#semantic-conventions-process)).
+If the change involves new attributes, you **MUST** land the sentry-conventions PR first ([Semantic conventions process](/sdk/getting-started/standards/api-architecture/#semantic-conventions-process)).
 
 After the conventions PR is approved, you **MUST** wait 3 business days before implementing in any SDK. This grace period allows teams to review the final conventions and raise concerns.
 
@@ -89,7 +89,7 @@ You **SHOULD** use the [`sentry-sdk-skills:linear-initiative`](https://github.co
 If not using the skill, you **MUST** manually:
 
 - Create a sub-initiative under the appropriate parent initiative in Linear
-- For each SDK team involved, create a separate **project** under this sub-initiative, named per the [Project Naming](/sdk/getting-started/standards/planning-scoping#project-naming) standard (`[Effort name] [SDK name]`)
+- For each SDK team involved, create a separate **project** under this sub-initiative, named per the [Project Naming](/sdk/getting-started/standards/planning-scoping/#project-naming) standard (`[Effort name] [SDK name]`)
 - You **MUST NOT** use a single project with multiple issues, as the project is only completed once **all** SDK teams finish their work
 - Each project **MUST** contain at least one issue with the **same title and description** as the project
 - Additional issues **MAY** be added as needed but **SHOULD** remain within the scope of the alignment effort
@@ -108,7 +108,7 @@ This public issue **MAY** be omitted for changes that are:
 
 #### 6. Implement in each SDK independently
 
-Each team **MUST** follow their own PR process ([Opening a PR](/sdk/getting-started/playbooks/development/opening-a-pr), [Reviewing a PR](/sdk/getting-started/playbooks/development/reviewing-a-pr)). The Linear projects provide visibility, but each SDK maintains its own standards and timeline.
+Each team **MUST** follow their own PR process ([Opening a PR](/sdk/getting-started/playbooks/development/opening-a-pr/), [Reviewing a PR](/sdk/getting-started/playbooks/development/reviewing-a-pr/)). The Linear projects provide visibility, but each SDK maintains its own standards and timeline.
 
 You **SHOULD** use the [`sentry-sdk-skills:sdk-feature-implementation`](https://github.com/getsentry/sdk-skills?tab=readme-ov-file#available-skills) skill to spawn parallel agents that create draft PRs across all target SDK repos. The skill uses the Linear context gathered in step 5 and handles CI monitoring across repos.
 
@@ -137,12 +137,12 @@ This helps improve future cross-SDK coordination.
 
 ## Referenced Standards
 
-- [Cross-SDK Coordination standard](/sdk/getting-started/standards/coordination-maintenance#cross-sdk-coordination) — coordination process and requirements
-- [Design-First Gate](/sdk/getting-started/standards/planning-scoping#design-first-gate) — RFC/proposal triggers this gate; must be complete before implementation
-- [Risk Identification](/sdk/getting-started/standards/planning-scoping#risk-identification) — risk section required in the proposal; high risks block implementation start
-- [Project Naming](/sdk/getting-started/standards/planning-scoping#project-naming) — `[Effort name] [SDK name]` format required for per-SDK projects
-- [Managing Linear Projects](/sdk/getting-started/playbooks/coordination/managing-linear-projects) — how to set up and run each per-SDK project
-- [Semantic conventions process](/sdk/getting-started/standards/api-architecture#semantic-conventions-process) — process for landing new attribute conventions
+- [Cross-SDK Coordination standard](/sdk/getting-started/standards/coordination-maintenance/#cross-sdk-coordination) — coordination process and requirements
+- [Design-First Gate](/sdk/getting-started/standards/planning-scoping/#design-first-gate) — RFC/proposal triggers this gate; must be complete before implementation
+- [Risk Identification](/sdk/getting-started/standards/planning-scoping/#risk-identification) — risk section required in the proposal; high risks block implementation start
+- [Project Naming](/sdk/getting-started/standards/planning-scoping/#project-naming) — `[Effort name] [SDK name]` format required for per-SDK projects
+- [Managing Linear Projects](/sdk/getting-started/playbooks/coordination/managing-linear-projects/) — how to set up and run each per-SDK project
+- [Semantic conventions process](/sdk/getting-started/standards/api-architecture/#semantic-conventions-process) — process for landing new attribute conventions
 
 ---