docs: fix the remaining broken links

content/en/documentation/for-adopters/extensions/_index.md

@@ -48,7 +48,7 @@ Finally, the EDC module system is not a framework like [Spring](https://spring.i
 
 ## Extension Basics
 
-If you are unfamiliar with bundling EDC runtimes, please read the chapter on [Distributions, Deployment, and Operations](distributions-deployment-operations.md). Let's assume we have already enabled a runtime build that packages all EDC classes into a single executable JAR deployed in a Docker container.
+If you are unfamiliar with bundling EDC runtimes, please read the chapter on [Distributions, Deployment, and Operations](../distributions-deployment-operations/_index.md). Let's assume we have already enabled a runtime build that packages all EDC classes into a single executable JAR deployed in a Docker container.
 
 An EDC extension can be created by implementing the `ServiceExtension` interface:
 

content/en/documentation/for-contributors/custom-validation.md

@@ -18,7 +18,7 @@ themselves.
 ## When to use it
 
 This feature is intended for use cases where the standard DTO validation, that ships with EDC's APIs is not sufficient.
-Please check out the [OpenAPI spec](../../resources/openapi/yaml) to find out more about the object schema.
+Please check out the [OpenAPI spec](https://eclipse-edc.github.io/Connector/openapi/management-api/) to find out more about the object schema.
 
 EDC features various data types that do not have a strict schema but are *extensible*, for example `Asset`/`AssetDto`,
 or a `DataRequest`/`DataRequestDto`. This was done by design, to allow for maximum flexibility and openness. However,
@@ -66,7 +66,7 @@ following ways:
    logging*
 
 Please check
-out [this test](../../extensions/common/http/jersey-core/src/test/java/org/eclipse/edc/web/jersey/validation/integrationtest/ValidationIntegrationTest.java)
+out [this test](https://github.com/eclipse-edc/Connector/blob/main/extensions/common/http/jersey-core/src/test/java/org/eclipse/edc/web/jersey/validation/integrationtest/ValidationIntegrationTest.java)
 for a comprehensive example how validation can be enabled. All functions are registered during the extension's
 initialization phase.
 

content/en/documentation/for-contributors/guidelines/pr-checklist/_index.md

@@ -15,7 +15,7 @@ requires a significant change or touches on critical code paths (e.g. security-r
 
 ### Coding Style
 
-All code contributions must strictly adhere to the [Style Guide](styleguide.md) and design principles outlined in the
+All code contributions must strictly adhere to the [Style Guide](../styleguide/_index.md) and design principles outlined in the
 Contributor Technical Documentation. **PRs that do not adhere to these rules will be rejected.**
 
 All artifacts must include the following copyright header, replacing the fields enclosed by curly brackets "{}" with

content/en/documentation/for-contributors/guidelines/pr-etiquette/_index.md

@@ -47,7 +47,7 @@ Sponsorship can be obtained through engagement on discussions or issues.
 
 PRs should adhere to the following rules.
 
-- Familiarize yourself with [coding style](./styleguide.md), [./architectural patterns](coding-principles.md),
+- Familiarize yourself with [coding style](../styleguide/_index.md), architectural patterns,
   and other contribution guidelines.
 - No surprise PRs. Before submitting a PR, open a discussion or an issue outlining the planned work and give
   people time to comment. Unsolicited PRs may get ignored or rejected.
@@ -58,15 +58,15 @@ PRs should adhere to the following rules.
   the `age` field changed from `long` to `String`".
 - If 3rd party dependencies are introduced, note them in the PR description and explain why they are necessary.
 - Stick to the established code style, please refer to
-  the [styleguide document](./styleguide.md).
+  the [styleguide document](../styleguide/_index.md).
 - All tests should be green, especially when your PR is in `"Ready for review"`
 - Mark PRs as `"Ready for review"` only when the PR is complete. No additional commits should be pushed other than to
   incorporate review comments.
 - Merge conflicts should be resolved by squashing all commits on the PR branch, rebasing onto `main,` and
   force-pushing. Do this when your PR is ready to review.
 - If you require a reviewer's input while it's still in draft, please contact the designated reviewer using
   the `@mention` feature and let them know what you'd like them to look at.
-- Request a review from one of the [technical committers](pr_etiquette.md#the-technical-committers). Requesting a review
+- Request a review from one of the [technical committers](#the-technical-committers). Requesting a review
   from anyone else is still possible, and sometimes may be advisable, but only committers can merge PRs, so be sure to
   include them early on.
 - Re-request reviews after all remarks have been adopted. This helps reviewers track their work in GitHub. Failing to do

content/en/documentation/for-contributors/runtime/extension-model.md

@@ -96,7 +96,7 @@ the extension, for example:
 
 To achieve this, the [EDC Runtime Metamodel](https://github.com/eclipse-edc/Runtime-Metamodel) defines several
 annotations. These are not required for compilation, but they should be added to the appropriate classes and fields with
-proper attributes to enable good documentation. For detailed information please read [this chapter](../contributor-handbook.md#62-autodoc).
+proper attributes to enable good documentation. For detailed information please read [this chapter](../developer-tools.md#3-autodoc).
 
 Note that `@Provider`, `@Inject`, `@Provides` and `@Requires` are used by Autodoc to resolve the dependency graph for
 documentation, but they are also used by the runtime to resolve service dependencies. Read more about that