tianocore · Javagedes · Jul 29, 2024 · Jul 29, 2024
diff --git a/docs/user/features/environment_variables.md b/docs/user/features/environment_variables.md
@@ -17,7 +17,7 @@ This variable, if present, will enable the Stuart tools that clone or update Git
 to use the local Omnicache rather than having to fetch everything from the server. This can
 greatly improve the performance of CI processes that have to clone many dependencies.
 
-For more info, see [the Omnicache docs](/tools/using_omnicache_tool/).
+For more info, see [the Omnicache docs](/tools/using_omnicache_tool.md).
 
 ## STUART_EXTDEP_CACHE_PATH
 

diff --git a/docs/user/features/extdep.md b/docs/user/features/extdep.md
@@ -197,7 +197,7 @@ Ext_Dep Example json file
 ```
 
 If you wish to create a new ext_dep type other then those mentioned in
-[Supported Types](#supported-types), See [Creating an Extdep Type](features/creating_extdep)
+[Supported Types](#supported-types), See [Creating an Extdep Type](/features/creating_extdep.md)
 
 ## The base schema
 

diff --git a/docs/user/features/plugin_manager.md b/docs/user/features/plugin_manager.md
@@ -53,7 +53,7 @@ executed.
 
 ## Writing your own
 
-See [Creating a Plugin](/features/creating_plugins)
+See [Creating a Plugin](/features/creating_plugins.md)
 
 For IUefiBuildPlugin type the plugin will simply be called during the pre and
 post build steps after the platform builder object runs its step. The

diff --git a/docs/user/index.md b/docs/user/index.md
@@ -13,8 +13,8 @@ Firmware code tree.
 !!! note
     If stuart is already integrated into your platform and you're looking for a
     tutorial on how to install and use stuart, please see
-    [Installation](/using/install), [Building](/using/build), and
-    [Core CI](/using/ci) Instructions.
+    [Installation](/using/install.md), [Building](/using/build.md), and
+    [Core CI](/using/ci.md) Instructions.
 
 As UEFI developers, we found the process of building firmware to be extremely
 rigid and hard to customize without the use of disjointed scripts that would
@@ -53,7 +53,7 @@ be passed in. This way, the invocable script gets all the information it needs
 without needing to carry the overhead of command line parsing and loading the
 class.
 
-[Settings Manager documentation](features/settings_manager)
+[Settings Manager documentation](features/settings_manager.md)
 
 ### Scopes
 
@@ -76,7 +76,7 @@ be implemented.
 3. `UefiHelperPlugin` - Registers one or
    more functions that can called by any part of the build system.
 
-[Plugin Manager Documentation](features/plugin_manager)
+[Plugin Manager Documentation](features/plugin_manager.md)
 
 ### External Dependencies
 
@@ -87,7 +87,7 @@ the rest! When you call stuart_update, Stuart will collect, download, and store
 the ext_deps pertaining to your scope. Stuart will make sure these ext_deps are
 available to the rest of the environment.
 
-[External Dependency Documentation](features/extdep)
+[External Dependency Documentation](features/extdep.md)
 
 ### Environment Variables
 
@@ -97,7 +97,7 @@ and ensures a variable defined in one is available to all others. This means
 if a variable is set in the build script, it can then be used in your FDF, DSC,
 etc (and vise versa).
 
-[Environment Variable Documentation](features/environment_variables)
+[Environment Variable Documentation](features/environment_variables.md)
 
 ## What can I ask Stuart to do
 

diff --git a/docs/user/integrate/build.md b/docs/user/integrate/build.md
@@ -1,38 +1,38 @@
 # Building A Platform
 
 You have an EDK2 implementation, a platform DSC, and a platform FDF? Great! You
-are one [settings file](/features/settings_manager) away from a great
+are one [settings file](/features/settings_manager.md) away from a great
 platform building experience.
 
-The build process has three [stuart commands](/#what-can-i-ask-stuart-to-do)
+The build process has three [stuart commands](/index.md#what-can-i-ask-stuart-to-do)
 to take your firmware code tree from freshly cloned to fully built: `stuart_setup`, `stuart_update`, `stuart_build`
-(hereby known has the "command(s)"). Behind the scenes, each command is an [Invocable](/features/invocable)
-that has a corresponding [Settings Manager](/features/settings_manager) that the platform subclasses to provide
+(hereby known has the "command(s)"). Behind the scenes, each command is an [Invocable](/features/invocable.md)
+that has a corresponding [Settings Manager](/features/settings_manager.md) that the platform subclasses to provide
 platform specific information.
 
 In hopes of keeping this section as light as possible, the information provided will be broad and more conversational
 then tutorial. If you want a step by step example of porting a platform, we have one! Please see
-[Porting the Raspberry Pi 3](/integrate/porting).
+[Porting the Raspberry Pi 3](/integrate/porting.md).
 
 ## Getting Started
 
 Stuart needs a settings file to configure itself. This settings file must provide a settings manager subclasses for each
 command you plan on using. This settings manager is the interface that provides platform specific information to the
 platform agnostic invocable. This is done via subclassing the corresponding settings file and overriding the necessary
-methods described in the [Settings Manager](/features/settings_manager).
+methods described in the [Settings Manager](/features/settings_manager.md).
 
 In terms of building a platform, there are five classes that you need to be aware of. The first two are interfaces that
 provide functions used across all three commands and can be shared among the SettingsManagers by using
-[Multiple Inheritance](/features/settings_manager/#a-note-on-multi-inheritance).
+[Multiple Inheritance](/features/settings_manager.md#a-note-on-multi-inheritance).
 
-1. [Edk2InvocableSettingsInterface](/api/edk2_invocable/#edk2toolext.edk2_invocable.Edk2InvocableSettingsInterface)
-2. [MultiPkgAwareSettingsInterface](/api/invocables/edk2_multipkg_aware_invocable/#edk2toolext.invocables.edk2_multipkg_aware_invocable.MultiPkgAwareSettingsInterface)
-3. [SetupSettingsManager](/api/invocables/edk2_setup/#edk2toolext.invocables.edk2_setup.SetupSettingsManager)
-4. [UpdateSettingsManager](/api/invocables/edk2_update/#edk2toolext.invocables.edk2_update.UpdateSettingsManager)
-5. [BuildSettingsManager](/api/invocables/edk2_ci_build/#edk2toolext.invocables.edk2_ci_build.CiBuildSettingsManager)
+1. [Edk2InvocableSettingsInterface](/api/edk2_invocable.md#edk2toolext.edk2_invocable.Edk2InvocableSettingsInterface)
+2. [MultiPkgAwareSettingsInterface](/api/invocables/edk2_multipkg_aware_invocable.md#edk2toolext.invocables.edk2_multipkg_aware_invocable.MultiPkgAwareSettingsInterface)
+3. [SetupSettingsManager](/api/invocables/edk2_setup.md#edk2toolext.invocables.edk2_setup.SetupSettingsManager)
+4. [UpdateSettingsManager](/api/invocables/edk2_update.md#edk2toolext.invocables.edk2_update.UpdateSettingsManager)
+5. [BuildSettingsManager](/api/invocables/edk2_ci_build.md#edk2toolext.invocables.edk2_ci_build.CiBuildSettingsManager)
 
 The final class we inherit from in the settings file the
-[UefiBuilder](/api/environment/uefi_build/#edk2toolext.environment.uefi_build.UefiBuilder)
+[UefiBuilder](/api/environment/uefi_build.md#edk2toolext.environment.uefi_build.UefiBuilder)
 and is what provides the bulk of customization EDK2 Pytools affords you.
 This is also where you can utilize many of the features and functionality
 spread across Edk2-Pytools (Extensions and Library).
@@ -42,37 +42,37 @@ Lets take a look at each command!
 ## Stuart Setup
 
 `stuart_setup` is the first command and is responsible for setting up the code tree. Currently, this only involves
-preparing the git submodules necessary for build. If you've created an [Omnicache](/tools/using_omnicache_tool/), here
+preparing the git submodules necessary for build. If you've created an [Omnicache](/tools/using_omnicache_tool.md), here
 is where you would use it to save on network bandwidth, disk space, and time when cloning repos. As you might expect,
 `stuart_setup` does not automatically know what submodules are necessary for each platform; we must use the
-[SetupSettingsManager](/api/invocables/edk2_setup/#edk2toolext.invocables.edk2_setup.SetupSettingsManager)
+[SetupSettingsManager](/api/invocables/edk2_setup.md#edk2toolext.invocables.edk2_setup.SetupSettingsManager)
 to provide that information.
 
 !!! Note
-    The command specific [Settings Manager](/features/settings_manager) may not provide *ALL* platform data
+    The command specific [Settings Manager](/features/settings_manager.md) may not provide *ALL* platform data
     required by the command; it only provides the platform data specific to that command. You still need to override some
     methods from
-    [Edk2InvocableSettingsInterface](/api/edk2_invocable/#edk2toolext.edk2_invocable.Edk2InvocableSettingsInterface)
-    and [MultiPkgAwareSettingsInterface](/api/invocables/edk2_multipkg_aware_invocable/#edk2toolext.invocables.edk2_multipkg_aware_invocable.MultiPkgAwareSettingsInterface)
+    [Edk2InvocableSettingsInterface](/api/edk2_invocable.md#edk2toolext.edk2_invocable.Edk2InvocableSettingsInterface)
+    and [MultiPkgAwareSettingsInterface](/api/invocables/edk2_multipkg_aware_invocable.md#edk2toolext.invocables.edk2_multipkg_aware_invocable.MultiPkgAwareSettingsInterface)
     that multiple (or all) commands use, which is why they are in the parent class. Don't worry though! If you miss
     overriding a required method, you'll raise a `NotImplementedError`!
 
-**Review the `stuart_setup` specific settings manager [here](/api/invocables/edk2_setup/#edk2toolext.invocables.edk2_setup.SetupSettingsManager).**
+**Review the `stuart_setup` specific settings manager [here](/api/invocables/edk2_setup.md#edk2toolext.invocables.edk2_setup.SetupSettingsManager).**
 
 ## Stuart Update
 
 Next up is `stuart_update`, which is responsible for updating any external dependencies in the workspace. This includes
 downloading and performing miscellaneous tasks for external dependencies. You can find details on how external
-dependencies work and how to utilize them in the [ext_dep](/features/extdep) section.
+dependencies work and how to utilize them in the [ext_dep](/features/extdep.md) section.
 
 As you'll see in the API reference for `UpdateSettingsManager`, no additional methods need to be overwritten. At first
 glance, it may seem like `stuart_update` does not need any platform specific information, but it actually does. The key
 takeaway is that you'll still need to inherit from `UpdateSettingsManager`; it's just that the necessary platform data
 for this command comes from overriding methods in the parent class
-[Edk2InvocableSettingsInterface](/api/edk2_invocable/#edk2toolext.edk2_invocable.Edk2InvocableSettingsInterface)
-and/or [MultiPkgAwareSettingsInterface](/api/invocables/edk2_multipkg_aware_invocable/#edk2toolext.invocables.edk2_multipkg_aware_invocable.MultiPkgAwareSettingsInterface).
+[Edk2InvocableSettingsInterface](/api/edk2_invocable.md#edk2toolext.edk2_invocable.Edk2InvocableSettingsInterface)
+and/or [MultiPkgAwareSettingsInterface](/api/invocables/edk2_multipkg_aware_invocable.md#edk2toolext.invocables.edk2_multipkg_aware_invocable.MultiPkgAwareSettingsInterface).
 
-**Review the `stuart_update` specific settings manager [here](/api/invocables/edk2_update/#edk2toolext.invocables.edk2_update.UpdateSettingsManager).**
+**Review the `stuart_update` specific settings manager [here](/api/invocables/edk2_update.md#edk2toolext.invocables.edk2_update.UpdateSettingsManager).**
 
 ## Stuart Build
 
@@ -81,15 +81,15 @@ Lastly is the `stuart_build` command, which actually has two phases to it. The f
 will then invoke the `UefiBuilder`, signaling the start of the second phase which consists of most of the customization
 afforded to you by EDK2 Pytools.
 
-**Review the `stuart_build` specific settings manager [here](/api/invocables/edk2_ci_build/#edk2toolext.invocables.edk2_ci_build.CiBuildSettingsManager).**
+**Review the `stuart_build` specific settings manager [here](/api/invocables/edk2_ci_build.md#edk2toolext.invocables.edk2_ci_build.CiBuildSettingsManager).**
 
 ## UefiBuilder
 
 So what has all of these commands been culminating to? They've all been working to prepare a
-[Self Describing Environment](/features/sde) for the `UefiBuilder` to operate in. The purpose of the
+[Self Describing Environment](/features/sde.md) for the `UefiBuilder` to operate in. The purpose of the
 `UefiBuilder` is to allow the platform to perform various tasks using this environment. Custom made
-[UefiBuildPlugins](/features/plugin_manager/#types-of-plugins) will automatically be run Pre and Post build for
-all platforms while [UefiHelperPlugins](/features/plugin_manager/#types-of-plugins) will be available to the
+[UefiBuildPlugins](/features/plugin_manager.md#types-of-plugins) will automatically be run Pre and Post build for
+all platforms while [UefiHelperPlugins](/features/plugin_manager.md#types-of-plugins) will be available to the
 developer to help create Platform specific Pre and Post build functionality. The `UefiBuilder` class has a lot to it, so
 let's take a look at each part.
 
@@ -136,11 +136,11 @@ and should be checked for existence rather then value (i.e. `if env.GetValue(var
 While you can set and get variables anywhere in the `UefiBuilder` portion of the settings file, we provide the following
 three methods to set environment variables, ensuring they are available everywhere that you are allowed to customize:
 
-- [SetPlatformEnv](/api/environment/uefi_build/#edk2toolext.environment.uefi_build.UefiBuilder.SetPlatformEnv)
+- [SetPlatformEnv](/api/environment/uefi_build.md#edk2toolext.environment.uefi_build.UefiBuilder.SetPlatformEnv)
 
-- [SetPlatfromEnvAfterTarget](/api/environment/uefi_build/#edk2toolext.environment.uefi_build.UefiBuilder.SetPlatformEnvAfterTarget)
+- [SetPlatfromEnvAfterTarget](/api/environment/uefi_build.md#edk2toolext.environment.uefi_build.UefiBuilder.SetPlatformEnvAfterTarget)
 
-- [SetPlatformDefaultEnv](/api/environment/uefi_build/#edk2toolext.environment.uefi_build.UefiBuilder.SetPlatformDefaultEnv)
+- [SetPlatformDefaultEnv](/api/environment/uefi_build.md#edk2toolext.environment.uefi_build.UefiBuilder.SetPlatformDefaultEnv)
 
 !!! Warning
     `SetPlatformDefaultEnv` is not like the others. Rather then setting the environment variables directly, it should
@@ -194,13 +194,13 @@ FILE APPLICATION = PCD(gPcBdsPkgTokenSpaceGuid.PcdShellFile) {
 ### Pre / Post Build Customization
 
 Edk2 Pytools offer developers multiple ways to customize the build experience, both Pre and Post Build. The first way is
-through [UefiBuildPlugins](/features/plugin_manager/#types-of-plugins) (executed automatically for all platforms)
-which is discussed in [Create a Plugin](/features/creating_plugins) section, and through three methods to override in
+through [UefiBuildPlugins](/features/plugin_manager.md#types-of-plugins) (executed automatically for all platforms)
+which is discussed in [Create a Plugin](/features/creating_plugins.md) section, and through three methods to override in
 the `UefiBuilder` (specific to the platform) which will be the focus here.
 
-- [PlatformPreBuild](/api/environment/uefi_build/#edk2toolext.environment.uefi_build.UefiBuilder.PlatformPreBuild)
-- [PlatformPostBuild](/api/environment/uefi_build/#edk2toolext.environment.uefi_build.UefiBuilder.PlatformPostBuild)
-- [PlatformFlashImage](/api/environment/uefi_build/#edk2toolext.environment.uefi_build.UefiBuilder.PlatformFlashImage)
+- [PlatformPreBuild](/api/environment/uefi_build.md#edk2toolext.environment.uefi_build.UefiBuilder.PlatformPreBuild)
+- [PlatformPostBuild](/api/environment/uefi_build.md#edk2toolext.environment.uefi_build.UefiBuilder.PlatformPostBuild)
+- [PlatformFlashImage](/api/environment/uefi_build.md#edk2toolext.environment.uefi_build.UefiBuilder.PlatformFlashImage)
 
 All three of the callbacks that you can override have access to the same environment, but each happens at a different
 time in the build process as outlined below. You can choose to perform specific tasks both prebuild and postbuild such
@@ -220,7 +220,7 @@ callbacks mentioned above:
 
 #### Helper Plugins
 
-This is another type of plugin that is talked about in the [Create a Plugin](/features/creating_plugins)
+This is another type of plugin that is talked about in the [Create a Plugin](/features/creating_plugins.md)
 that allows the developers to add in extensions or helper methods to the build
 environment that are easy to access. You can easily access them through
 `self.Helper.<FunctionName>()`. As an example, if we made that helper called
@@ -230,7 +230,7 @@ environment that are easy to access. You can easily access them through
 
 As we alluded to in one of the previous sections, you'll have access to all of the environment variables set throughout
 the DSC, FDF, CLI, and anywhere else in the build. you'll be able to access the environment via `self.env`. To see the
-available methods to use, please review the [VarDict](/api/environment/var_dict/#edk2toolext.environment.var_dict.VarDict).
+available methods to use, please review the [VarDict](/api/environment/var_dict.md#edk2toolext.environment.var_dict.VarDict).
 
 #### Edk2 Pytool Library
 

diff --git a/docs/user/integrate/manage.md b/docs/user/integrate/manage.md
@@ -9,7 +9,7 @@ These use cases will fit into our 'CI' tools category.
 ## Getting Started
 
 Our CI tools simplify the process of creating and running
-[CiBuildPlugins](/features/plugin_manager) on packages within any
+[CiBuildPlugins](/features/plugin_manager.md) on packages within any
 repository, not just a platform repository. We even provide a simple means to
 filter which packages are tested based off which files have been changed
 through `edk2_pr_eval.py`/`stuart_pr_eval.exe`. These packages do not need to
@@ -22,7 +22,7 @@ required for this operation. `stuart_update` can be called to download all the
 tools the environment says it needs. From there, `stuart_ci_build` takes a list of
 packages to look at and runs all plugins on each package.
 
-Similar to [Build a Platform](/integrate/build), this process involves invocables.
+Similar to [Build a Platform](/integrate/build.md), this process involves invocables.
 Since we already explained the process of creating a settings file to provide
 platform information to the build invocables, we wont go into to much detail
 here. Just know that you have additional invocables that you will need override
@@ -33,9 +33,9 @@ to make the CI invocables work!
 
 Take a look all all the relevant invocables below:
 
-- [Edk2InvocableSettingsInterface](/api/edk2_invocable/#edk2toolext.edk2_invocable.Edk2InvocableSettingsInterface)
-- [MultiPkgAwareSettingsInterface](/api/invocables/edk2_multipkg_aware_invocable/#edk2toolext.invocables.edk2_multipkg_aware_invocable.MultiPkgAwareSettingsInterface)
-- [CiSetupSettingsManager](/api/invocables/edk2_ci_setup/#edk2toolext.invocables.edk2_ci_setup.CiSetupSettingsManager)
-- [UpdateSettingsManager](/api/invocables/edk2_update/#edk2toolext.invocables.edk2_update.UpdateSettingsManager)
-- [CiBuildSettingsManager](/api/invocables/edk2_ci_setup/#edk2toolext.invocables.edk2_ci_setup.CiSetupSettingsManager)
-- [PrEvalSettingsManager](/api/invocables/edk2_pr_eval/#edk2toolext.invocables.edk2_pr_eval.PrEvalSettingsManager)
+- [Edk2InvocableSettingsInterface](/api/edk2_invocable.md#edk2toolext.edk2_invocable.Edk2InvocableSettingsInterface)
+- [MultiPkgAwareSettingsInterface](/api/invocables/edk2_multipkg_aware_invocable.md#edk2toolext.invocables.edk2_multipkg_aware_invocable.MultiPkgAwareSettingsInterface)
+- [CiSetupSettingsManager](/api/invocables/edk2_ci_setup.md#edk2toolext.invocables.edk2_ci_setup.CiSetupSettingsManager)
+- [UpdateSettingsManager](/api/invocables/edk2_update.md#edk2toolext.invocables.edk2_update.UpdateSettingsManager)
+- [CiBuildSettingsManager](/api/invocables/edk2_ci_setup.md#edk2toolext.invocables.edk2_ci_setup.CiSetupSettingsManager)
+- [PrEvalSettingsManager](/api/invocables/edk2_pr_eval.md#edk2toolext.invocables.edk2_pr_eval.PrEvalSettingsManager)