more fixes

Author: chcomley

release-notes/2024/includes/ghazdo/sprint-245-update.md

@@ -23,7 +23,7 @@ Additionally, the Security Overview updates to reflect default branch changes, a
 
 You can now upload results from your third-party scanning tool to show in the Advanced Security code scanning tab. 
 
-Using a scanning tool that publishes a SARIF file to the `$(Agent.TempDirectory)/.advsec` directory, conforms to the SARIF 2.1 standard, and runs the [AdvancedSecurity-Publish@1](/azure/devops/pipelines/tasks/reference/advanced-security-publish-v1.md) after the task will upload results to the code scanning tab.
+Using a scanning tool that publishes a SARIF file to the `$(Agent.TempDirectory)/.advsec` directory, conforms to the SARIF 2.1 standard, and runs the AdvancedSecurity-Publish@1 after the task will upload results to the code scanning tab.
 
 > [!NOTE]
 > The file path associated with a result in the SARIF file must be accessible to the `AdvancedSecurity-Publish@1` task running in the build agent.

release-notes/2025/includes/repos/sprint-248-update.md

@@ -8,7 +8,7 @@ ms.topic: include
 
 ### Sparse checkout for Azure Repos
 
-The [git sparse-checkout](https://github.blog/open-source/git/bring-your-monorepo-down-to-size-with-sparse-checkout/) command is now supported in the YAML checkout task, alongside the [partial clone filter](/azure/devops/pipelines/yaml-schema/steps-checkout.md), to improve repository checkout performance. You can use the properties `sparseCheckoutDirectories` and `sparseCheckoutPatterns`.
+The [git sparse-checkout](https://github.blog/open-source/git/bring-your-monorepo-down-to-size-with-sparse-checkout/) command is now supported in the YAML checkout task, alongside the partial clone filter, to improve repository checkout performance. You can use the properties `sparseCheckoutDirectories` and `sparseCheckoutPatterns`.
 
 Setting `sparseCheckoutDirectories` enables cone mode, where the checkout process uses directory matching. Alternatively, you can set `sparseCheckoutPatterns` which triggers non-cone mode, allowing more complex pattern matching. 
 

release-notes/2025/includes/testplans/sprint-258-update.md

@@ -12,4 +12,4 @@ Introducing the ability to associate automated tests written in Java/JUnit (Mave
 > [!div class="mx-imgBorder"]
 > [![Screenshot of test case associated to test.](../../media/258-testplans-01.png "Screenshot of test case associated to test")](../../media/258-testplans-01.png#lightbox)
 
-Upon completion of the association, you can run your tests within your pipelines using the new [Azure Test Plan](/azure/devops/pipelines/tasks/reference/azure-test-plan-v0?view=azure-pipelines) task. Additionally, you have the option to run your tests on an ad-hoc basis through the [Test Plans](/azure/devops/test/run-automated-tests-from-test-hub.md) experience.
+Upon completion of the association, you can run your tests within your pipelines using the new Azure Test Plan task. Additionally, you can run your tests on an ad-hoc basis through the [Test Plans](../../../../docs/test/run-automated-tests-from-test-hub.md) experience.

release-notes/roadmap/2025/new-service-connection.md

@@ -12,7 +12,7 @@ hide_comments: true
 
 # PAT-less authentication from pipeline tasks to Azure DevOps APIs
 
-Tasks in a pipeline use either a [job access token](/azure/devops/pipelines/process/access-tokens?view=azure-devops&tabs=yaml), available via the built-in variable [System.AccessToken](/azure/devops/pipelines/build/variables.md#systemaccesstoken), or a PAT to access Azure DevOps resources. For instance, a “checkout” task uses this token to authenticate to the repository. Similarly, a PowerShell script can use this token to access Azure DevOps REST APIs. However, the permissions of this token are based on the Project Build Service identity, meaning all job access tokens in a project have identical permissions. This grants excessive access across all pipelines within the project.
+Tasks in a pipeline use either a [job access token](../../../docs/pipelines/process/access-tokens.md), available via the built-in variable [System.AccessToken](../../../docs/pipelines/process/variables.md#system-variables), or a PAT to access Azure DevOps resources. For instance, a “checkout” task uses this token to authenticate to the repository. Similarly, a PowerShell script can use this token to access Azure DevOps REST APIs. However, the permissions of this token are based on the Project Build Service identity, meaning all job access tokens in a project have identical permissions. This grants excessive access across all pipelines within the project.
 
 Using PATs to access Azure DevOps resources is common, particularly when a task needs to access those resources across organization boundaries. For instance, a Nuget Authenticate task uses a PAT token to authenticate to a feed in another organization. PATs are an anti-pattern for security as they tend to be created with broad permissions and are held for a long time thereby increasing the risk of exfiltration.