dotnet · MihaZupan · Jan 13, 2026 · Jan 13, 2026 · Jan 13, 2026
diff --git a/docs/DailyBuilds.md b/docs/DailyBuilds.md
@@ -28,9 +28,10 @@ Then follow the [Getting Started](https://learn.microsoft.com/aspnet/core/fundam
 Some features, such as new target frameworks, may require prerelease tooling builds for Visual Studio.
 These are available in the [Visual Studio Preview](https://www.visualstudio.com/vs/preview/).
 
-#### To debug daily builds using Visual Studio
+To debug daily builds using Visual Studio
+------------------------------------------
 
-* *Enable Source Link support* in Visual Studio should be enabled.
-* *Enable source server support* in Visual should be enabled.
-* *Enable Just My Code* should be disabled
-* Under Symbols enable the *Microsoft Symbol Servers* setting.
+- *Enable Source Link support* in Visual Studio should be enabled.
+- *Enable source server support* in Visual should be enabled.
+- *Enable Just My Code* should be disabled
+- Under Symbols enable the *Microsoft Symbol Servers* setting.
diff --git a/docs/designs/config.md b/docs/designs/config.md
@@ -28,7 +28,7 @@ Proposals:
 ## Route config:
 
 The proxy has a [config mechanism](https://github.com/dotnet/yarp/blob/b2cf5bdddf7962a720672a75f2e93913d16dfee7/samples/IslandGateway.Sample/appsettings.json#L26-L32) to define routes and map those to back end groups.
-```
+```json
       "Routes": [
         {
           "RouteId": "backend1/route1",
@@ -44,7 +44,7 @@ This basic structure is useful though the "Rule" [system](https://github.com/dot
 The ProxyRoute.Metadata dictionary may be able to be replaced or supplemented by giving direct access to the config node for that route. Compare to Kestrel's [EndpointConfig.ConfigSection](https://github.com/dotnet/aspnetcore/blob/f4d81e3af2b969744a57d76d4d622036ac514a6a/src/Servers/Kestrel/Core/src/Internal/ConfigurationReader.cs#L168-L175) property. That would allow for augmenting an endpoint with additional complex custom entries that the app code can reference for additional config actions.
 
 Update: The custom rule system was modified by [#24](https://github.com/dotnet/yarp/pull/24) so that the config now looks like this:
-```
+```json
        "Routes": [
          {
            "RouteId": "backend1/route1",
@@ -69,7 +69,7 @@ A Backend is a collection of one or more BackendEndpoints and a set of policies
 Question: Why are the backends and the endpoints listed separately in config rather than nested? Object model links endpoints 1:1 with backends, so there doesn't seem to be a reason to list them separately.
 
 Existing:
-```
+```json
       "Backends": [
         {
           "BackendId": "backend1"
@@ -94,7 +94,7 @@ Existing:
       },
 ```
 Nested:
-```
+```json
       "Backends": [
         {
           "BackendId": "backend1",
@@ -117,7 +117,7 @@ Nested:
       ],
 ```
 Additional feedback: Why is it using arrays instead of objects? These items are not order sensitive, and they already have id properties anyways.
-```
+```json
       "Backends": {
         "backend1" : {
           "Endpoints": [
@@ -137,7 +137,7 @@ Additional feedback: Why is it using arrays instead of objects? These items are
 ```
 
 Update: The backend and endpoint layout has been modified to the following:
-```
+```json
 
     "Backends": {
       "backend1": {
@@ -161,7 +161,7 @@ Update: The backend and endpoint layout has been modified to the following:
 
 Config reloading is not yet a blocking requirement but we do expect to need it in the future. This design needs to factor in how reloading might work when it does get added.
 
-** NOTE ** The proxy code has a concept of Signals that is used to convey config change. We need to see how this integrates with change notifications from our config sources and flows through the system.
+**NOTE** The proxy code has a concept of Signals that is used to convey config change. We need to see how this integrates with change notifications from our config sources and flows through the system.
 
 The Extensions config and options systems have support for change detection and reloading but very few components take advantage of it. Logging is the primary consumer today.
 
@@ -188,7 +188,7 @@ The config reload code has been moved from the sample into the product assemblie
 ## Augmenting config via code
 
 Some things are easier to do in code and we want to be able to support that while still pulling more transient data from config. [Kestrel](https://github.com/dotnet/aspnetcore/blob/aff01ebd7f82d641a4cfbd4a34954300311d9c2b/src/Servers/Kestrel/samples/SampleApp/Startup.cs#L138-L147) has a model where endpoints are named in config and then can be reference by name in code for additional configuration.
-```
+```json
 {
   "Kestrel": {
     "Endpoints": {
@@ -200,7 +200,7 @@ Some things are easier to do in code and we want to be able to support that whil
   }
 }
 ```
-```
+```csharp
     options.Endpoint("NamedEndpoint", opt =>
     {
 

diff --git a/docs/designs/route-extensibility.md b/docs/designs/route-extensibility.md
@@ -102,16 +102,16 @@ static IReverseProxyBuilder AddRouteExtension(this IReverseProxyBuilder builder,
   * The IConfigurationSection for the extension
   * The route object that is being extended
   * The existing extension instance in the case of configuration updates
-
-  > When the configuration is parsed, the factory is called based on the configuration key name, and the resultant object is added to the route/cluster objects.
-
-  > Regular YARP config will do a diff merge to handle config changes, and create new objects if applicable. The same mechanism needs to be used for extensions. If the configuration is updated, and an existing instance of the extension exists, then it will be passed to the factory. The factory can compare the current instance and re-use it, or copy its data across to a new instance based on the changes. Instances must stable, so existing instances shouldn't be modified if it would affect existing in-flight requests. YARP can't really enforce rules on how the objects are changed as we want the types to be user defined. 
+>
+> When the configuration is parsed, the factory is called based on the configuration key name, and the resultant object is added to the route/cluster objects.
+>
+> Regular YARP config will do a diff merge to handle config changes, and create new objects if applicable. The same mechanism needs to be used for extensions. If the configuration is updated, and an existing instance of the extension exists, then it will be passed to the factory. The factory can compare the current instance and re-use it, or copy its data across to a new instance based on the changes. Instances must stable, so existing instances shouldn't be modified if it would affect existing in-flight requests. YARP can't really enforce rules on how the objects are changed as we want the types to be user defined. 
 
 * When using a custom config provider, the Extensions collection can be populated by the custom provider directly, or the provider can expose an `IConfigurationSection` implementation and use the factory as described below.
 
 * When YARP is integrated with 3rd party config systems, such as K8s or ServiceFabric, those systems typically have a way of expressing custom properties, some of which will be used by YARP for the definition of routes/ clusters etc. To facilitate the ability for route and cluster extensions to be expressed within those systems, the integration provider should expose an `IConfigurationSection` implementation that maps between the integrated persistence format and YARP. 
   `IConfigurationSection` is essentially a name/value lookup API, it should map pretty reasonably to the YAML or JSON formats used by the configuration systems, and not be an undue burden to implement on these integrations.
 
-* Integration with 3rd party config systems can involve a remote process that YARP can pull its configuration from. I am [proposing another feature](#1710), that we formalize this pattern and have the ability to create a central YARP config provider, to which multiple YARP proxies can bind. This enables scalability in terms of being able to push config to multiple instances of YARP at once.
+* Integration with 3rd party config systems can involve a remote process that YARP can pull its configuration from. I am [proposing another feature](https://github.com/dotnet/yarp/issues/1710), that we formalize this pattern and have the ability to create a central YARP config provider, to which multiple YARP proxies can bind. This enables scalability in terms of being able to push config to multiple instances of YARP at once.
 
 * To support this scenario, we should serialize the IConfiguration data and pass that across to the proxy instances.
diff --git a/docs/designs/yarp-tunneling.md b/docs/designs/yarp-tunneling.md
@@ -26,7 +26,7 @@ If the tunnel connection is broken, the back-end will attempt to reconnect to th
 - If the connection is refused with a 400 series error then further connections for that tunnel will not be made.
 
 > Issue: Do we need an API for the tunnel? As its created from code on the back-end, the app could have additional logic for control over the duration. Does it have API for status, clean shutdown, etc.
-
+>
 > Issue: Will additional connections be created for scalability - H2 perf becomes limited after 100 simultaneous requests. How does the front-end know to pair a second back-end connection?
 
 The Front End should keep the WSS connection alive by sending pings every 30s if there is no other traffic. This should be done at the WSS layer.
@@ -198,9 +198,9 @@ Samples should be created that show best practices using a secure mechanism such
 
 The purpose of the tunnel is to simplify service exposure by creating a tunnel through the firewall that enables external requests to be made to destination servers on the back-end network. There are a number of mitigations that reduces the risk of this feature:
 
-* No endpoints are exposed via the firewall - it does not expose any new endpoints that could act as attack vectors. The tunnel is an outbound connection made between the back-end and the front-end.
-* Traffic directed via the tunnel will need to have corresponding routes in the Back End configuration. Traffic will only be routed if there is a respective route and cluster configuration. Tunnel traffic can't specify arbitrary URLs that would be directed to a hostname not included in the back-end route table configuration.
-* Tunnel connections should only be over HTTPs
+- No endpoints are exposed via the firewall - it does not expose any new endpoints that could act as attack vectors. The tunnel is an outbound connection made between the back-end and the front-end.
+- Traffic directed via the tunnel will need to have corresponding routes in the Back End configuration. Traffic will only be routed if there is a respective route and cluster configuration. Tunnel traffic can't specify arbitrary URLs that would be directed to a hostname not included in the back-end route table configuration.
+- Tunnel connections should only be over HTTPs
 
 ## Metrics
 
@@ -210,10 +210,8 @@ The purpose of the tunnel is to simplify service exposure by creating a tunnel t
 
 | Condition | Description |
 | --- | --- |
-| No tunnel has connected | If the front end receives a request for a route that is backed by a tunnel and no tunnels have been created, then it should respond to those requests with a 502 "Bad Gateway" error|
+| No tunnel has connected | If the front end receives a request for a route that is backed by a tunnel and no tunnels have been created, then it should respond to those requests with a 502 "Bad Gateway" error |
 
 ## Web Transport
 
 Web Transport is an interesting future protocol choice for the tunnel.
-
-
diff --git a/docs/operations/BackportingToPreview.md b/docs/operations/BackportingToPreview.md
@@ -19,7 +19,7 @@ Backporting changes is very similar to a regular release. Changes are made on th
   - `git push upstream --tags`
 - Create a new [release](https://github.com/dotnet/yarp/releases).
 
-# Internal fixes
+## Internal fixes
 
 Issues with significant security or disclosure concerns need to be fixed privately first. All of this work will happen on the internal Azdo repo and be merged to the public github repo at the time of disclosure.
 

diff --git a/docs/operations/Branching.md b/docs/operations/Branching.md
@@ -18,6 +18,6 @@ Update branding in `main`:
 
 Update the runtimes and SDKs in `global.json` in `main`:
 
-Check that the global.json includes the latest 8.0 runtime versions from [here](https://dotnet.microsoft.com/download/dotnet/8.0), and 9.0 from [here](https://dotnet.microsoft.com/download/dotnet/9.0).
+Check that the global.json includes the latest 8.0 runtime versions from [the .NET 8.0 download page](https://dotnet.microsoft.com/download/dotnet/8.0), and 9.0 from [the .NET 9.0 download page](https://dotnet.microsoft.com/download/dotnet/9.0).
 
 [`eng/Versions.props`]: ../../eng/Versions.props
diff --git a/docs/operations/DependencyFlow.md b/docs/operations/DependencyFlow.md
@@ -51,7 +51,7 @@ https://github.com/dotnet/arcade (.NET Eng - Latest) ==> 'https://github.com/dot
 
 To add a new subscription, run `darc add-subscription` with no arguments. An editor window will open with a TODO script like this:
 
-```
+```yaml
 Channel: <required>
 Source Repository URL: <required>
 Target Repository URL: <required>
@@ -63,7 +63,7 @@ Merge Policies: []
 
 A number of comments will also be present, describing available values and what they do. Fill these fields in, for example:
 
-```
+```yaml
 Channel: .NET Eng - Latest
 Source Repository URL: https://github.com/dotnet/arcade
 Target Repository URL: https://github.com/dotnet/yarp
@@ -97,7 +97,7 @@ Set up dependency flow for the new branch:
     * `Target Branch` = `release/X` (where `X` is the YARP release version)
     * `Update Frequency` = `EveryWeek`
     * `Merge Policies` is a multiline value, it should look like this:
-      ```
+      ```yaml
       Merge Policies:
       - Name: Standard
         Properties: {}

diff --git a/docs/operations/Release.md b/docs/operations/Release.md
@@ -71,7 +71,7 @@ Enter a comment such as "release for preview X" approve finalize the release.
 
 The packages will be pushed and when the "NuGet.org" stage turns green, the packages are published!
 
-*Note: NuGet publishing is quick, but there is a background indexing process that can mean it will take up to several hours for packages to become available*
+**Note:** NuGet publishing is quick, but there is a background indexing process that can mean it will take up to several hours for packages to become available
 
 ## Tag the commit
 
@@ -121,6 +121,7 @@ There should only be one [preview branch on the repo](https://github.com/dotnet/
 11. [Offline] Wait for the archival completion report to arrive. Check that the size and number of archived files match the YARP repo.
 
 ### Recommended fields' values for archival request form
+
 | Field | Value |
 | --- | --- |
 | Team Alias | dotnetrp |

diff --git a/docs/roadmap.md b/docs/roadmap.md
@@ -1,33 +1,33 @@
 # YARP Roadmap
 
-### Supported YARP versions
+## Supported YARP versions
 
 [Latest releases](https://github.com/dotnet/yarp/releases)
 
 | Version | Release Date | Latest Patch Version | End of Support |
 | -- | -- | -- | -- |
-| [YARP 2.3](https://github.com/dotnet/yarp/releases/tag/v2.3.0) | February 27, 2025 | [2.3.0](https://github.com/dotnet/yarp/releases/tag/v2.3.0) |                  |
+| [YARP 2.3](https://github.com/dotnet/yarp/releases/tag/v2.3.0) | February 27, 2025 | [2.3.0](https://github.com/dotnet/yarp/releases/tag/v2.3.0) | |
 
 ### End-of-life YARP versions
 
 | Version | Released date | Final Patch Version | End of support |
 | -- | -- | -- | -- |
-| [YARP 2.2](https://github.com/dotnet/yarp/releases/tag/v2.2.0) | September 3, 2024 | [2.2.0](https://github.com/dotnet/yarp/releases/tag/v2.2.0) | August 27, 2025  |
-| [YARP 2.1](https://github.com/dotnet/yarp/releases/tag/v2.1.0) | November 17, 2023 | [2.1.0](https://github.com/dotnet/yarp/releases/tag/v2.1.0) | March 3, 2025    |
-| [YARP 2.0](https://github.com/dotnet/yarp/releases/tag/v2.0.0) | February 14, 2023 | [2.0.1](https://github.com/dotnet/yarp/releases/tag/v2.0.1) | May 17, 2024     |
-| [YARP 1.1](https://github.com/dotnet/yarp/releases/tag/v1.1.0) | May 2, 2022       | [1.1.2](https://github.com/dotnet/yarp/releases/tag/v1.1.2) | August 14, 2023  |
-| [YARP 1.0](https://github.com/dotnet/yarp/releases/tag/v1.0.0) | November 9, 2021  | [1.0.1](https://github.com/dotnet/yarp/releases/tag/v1.0.1) | November 2, 2022 |
+| [YARP 2.2](https://github.com/dotnet/yarp/releases/tag/v2.2.0) | September 3, 2024 | [2.2.0](https://github.com/dotnet/yarp/releases/tag/v2.2.0) | August 27, 2025 |
+| [YARP 2.1](https://github.com/dotnet/yarp/releases/tag/v2.1.0) | November 17, 2023 | [2.1.0](https://github.com/dotnet/yarp/releases/tag/v2.1.0) | March 3, 2025 |
+| [YARP 2.0](https://github.com/dotnet/yarp/releases/tag/v2.0.0) | February 14, 2023 | [2.0.1](https://github.com/dotnet/yarp/releases/tag/v2.0.1) | May 17, 2024 |
+| [YARP 1.1](https://github.com/dotnet/yarp/releases/tag/v1.1.0) | May 2, 2022 | [1.1.2](https://github.com/dotnet/yarp/releases/tag/v1.1.2) | August 14, 2023 |
+| [YARP 1.0](https://github.com/dotnet/yarp/releases/tag/v1.0.0) | November 9, 2021 | [1.0.1](https://github.com/dotnet/yarp/releases/tag/v1.0.1) | November 2, 2022 |
 
 ## Support
 
 YARP support is provided by the product team - the engineers working on YARP - which is a combination of members from ASP.NET and the .NET library teams. We do not provide 24/7 support or 'carry pagers', but we generally have good coverage. Bugs should be reported in GitHub using the issue templates, and will typically be responded to within 24hrs. If you find a security issue we ask you to [report it via the Microsoft Security Response Center (MSRC)](https://github.com/dotnet/yarp/blob/main/SECURITY.md).
 
 The support period for YARP releases is as follows:
 
-| Release	| Issue Type | Support period |
-| --- | ---| --- |
-| Major or minor version | Security Bugs, Major behavior defects	| Until next GA + 6 Months |
-| Patch version | Minor behavior defects	| Until next GA |
+| Release | Issue Type | Support period |
+| --- | --- | --- |
+| Major or minor version | Security Bugs, Major behavior defects | Until next GA + 6 Months |
+| Patch version | Minor behavior defects | Until next GA |
 | Preview | Security Bugs, Major behavior defects | Until next preview |
 | | All other | None - may be addressed by next preview |
 

diff --git a/eng/common/template-guidance.md b/eng/common/template-guidance.md
@@ -12,7 +12,7 @@ Basic guidance is:
 
 See [azure-pipelines.yml](../../azure-pipelines.yml) (templates-official example) or [azure-pipelines-pr.yml](../../azure-pipelines-pr.yml) (templates example) for examples.
 
-#### The `templateIs1ESManaged` parameter
+### The `templateIs1ESManaged` parameter
 
 The `templateIs1ESManaged` is available on most templates and affects which of the variants is used for nested templates. See [Development Notes](#development-notes) below for more information on the `templateIs1ESManaged1 parameter.
 
@@ -59,7 +59,7 @@ Note: Multiple outputs are ONLY applicable to 1ES PT publishing (only usable whe
 
 ## Development notes
 
-**Folder / file structure**
+### Folder / file structure
 
 ``` text
 eng\common\