Migrate spelling-0.0.21 changes from main

Migrate spelling-0.0.19 changes from main
Cancel the preview of nested commands when moving back on the stack. (#10392 )
2026-04-06 22:29:43 +00:00 · 2021-06-14 19:20:30 +02:00 · 2021-06-14 19:20:30 +02:00 · 2021-07-07 13:12:45 -05:00 · 2021-07-07 13:11:22 -05:00 · 2021-07-07 13:08:03 -05:00
1339 changed files with 35840 additions and 90323 deletions
--- a/.editorconfig
+++ b/.editorconfig
@@ -1,7 +1,6 @@
 root = true

 [*]
-charset = utf-8
 trim_trailing_whitespace = true
 insert_final_newline = true

--- a/.gitattributes
+++ b/.gitattributes
@@ -3,8 +3,6 @@
 ###############################################################################
 * -text

-*.inc linguist-language=cpp
-
 ###############################################################################
 # Set default behavior for command prompt diff.
 #
--- a/.github/ISSUE_TEMPLATE/Bug_Report.yml
+++ b/.github/ISSUE_TEMPLATE/Bug_Report.yml
@@ -1,31 +1,27 @@
 name: "Bug report 🐛"
 description: Report errors or unexpected behavior
-labels: [Issue-Bug]
+title: ''
+labels: ''
+assignees: ''
+issue_body: true
 body:
 - type: markdown
  attributes:
    value: |
-      Please make sure to [search for existing issues](https://github.com/microsoft/terminal/issues) and [check the FAQ](https://github.com/microsoft/terminal/wiki/Frequently-Asked-Questions-(FAQ)) before filing a new one!
+      Please make sure to [search for existing issues](https://github.com/microsoft/terminal/issues) before filing a new one!

      If this is an application crash, please also provide a [Feedback Hub](https://aka.ms/terminal-feedback-hub) submission link so we can find your diagnostic data on the backend. Use the category "Apps > Windows Terminal" and choose "Share My Feedback" after submission to get the link.

 - type: input
  attributes:
-    label: Windows Terminal version
-    placeholder: "1.7.3651.0"
+    label: Windows Terminal version (or Windows build number)
+    placeholder: "10.0.19042.0, 1.7.3651.0"
    description: |
-      You can find the version in the about dialog, or by running `wt -v` at the commandline.
+      If you are reporting an issue in Windows Terminal, you can find the version in the about dialog.
+
+      If you are reporting an issue with the Windows Console, please run `ver` or `[Environment]::OSVersion`.
  validations:
-    required: false
-    
- type: input
-  attributes:
-    label: Windows build number
-    placeholder: "10.0.19042.0"
-    description: |
-      Please run `ver` or `[Environment]::OSVersion`.
-  validations:
-    required: false
+    required: true

 - type: textarea
  attributes:
@@ -48,7 +44,7 @@ body:
 - type: textarea
  attributes:
    label: Expected Behavior
-    description: If you want to include screenshots, paste them into the markdown editor below.
+    description: If you want to include screenshots, paste them into the markdown editor below the form or follow up with a separate comment.
    placeholder: What were you expecting?
  validations:
    required: false
--- a/.vscode/settings.json
+++ b/.vscode/settings.json
@@ -21,89 +21,12 @@
        "xloctime": "cpp",
        "multi_span": "cpp",
        "pointers": "cpp",
-        "vector": "cpp",
-        "bitset": "cpp",
-        "deque": "cpp",
-        "initializer_list": "cpp",
-        "list": "cpp",
-        "queue": "cpp",
-        "random": "cpp",
-        "regex": "cpp",
-        "stack": "cpp",
-        "xhash": "cpp",
-        "xtree": "cpp",
-        "xutility": "cpp",
-        "span": "cpp",
-        "string_span": "cpp",
-        "algorithm": "cpp",
-        "atomic": "cpp",
-        "bit": "cpp",
-        "cctype": "cpp",
-        "charconv": "cpp",
-        "chrono": "cpp",
-        "clocale": "cpp",
-        "cmath": "cpp",
-        "compare": "cpp",
-        "complex": "cpp",
-        "concepts": "cpp",
-        "condition_variable": "cpp",
-        "cstdarg": "cpp",
-        "cstddef": "cpp",
-        "cstdint": "cpp",
-        "cstdio": "cpp",
-        "cstdlib": "cpp",
-        "cstring": "cpp",
-        "ctime": "cpp",
-        "cwchar": "cpp",
-        "cwctype": "cpp",
-        "exception": "cpp",
-        "filesystem": "cpp",
-        "fstream": "cpp",
-        "functional": "cpp",
-        "iomanip": "cpp",
-        "ios": "cpp",
-        "iosfwd": "cpp",
-        "iostream": "cpp",
-        "iterator": "cpp",
-        "limits": "cpp",
-        "locale": "cpp",
-        "map": "cpp",
-        "memory_resource": "cpp",
-        "mutex": "cpp",
-        "new": "cpp",
-        "numeric": "cpp",
-        "optional": "cpp",
-        "ostream": "cpp",
-        "ratio": "cpp",
-        "set": "cpp",
-        "shared_mutex": "cpp",
-        "sstream": "cpp",
-        "stdexcept": "cpp",
-        "stop_token": "cpp",
-        "streambuf": "cpp",
-        "string": "cpp",
-        "system_error": "cpp",
-        "thread": "cpp",
-        "typeinfo": "cpp",
-        "unordered_map": "cpp",
-        "unordered_set": "cpp",
-        "xfacet": "cpp",
-        "xiosbase": "cpp",
-        "xlocale": "cpp",
-        "xlocbuf": "cpp",
-        "xlocinfo": "cpp",
-        "xmemory": "cpp",
-        "xstddef": "cpp",
-        "xtr1common": "cpp",
-        "coroutine": "cpp",
-        "format": "cpp",
-        "forward_list": "cpp",
-        "latch": "cpp"
+        "vector": "cpp"
    },
    "files.exclude": {
        "**/bin/**": true,
        "**/obj/**": true,
        "**/packages/**": true,
-        "**/Generated Files/**": true
+        "**/generated files/**": true
    }
 }
--- a/.vscode/tasks.json
+++ b/.vscode/tasks.json
@@ -9,7 +9,7 @@
              "-Command",
              "Import-Module ${workspaceFolder}\\tools\\OpenConsole.psm1;",
              "Set-MsBuildDevEnvironment;",
-              "$project = switch(\"${input:buildProjectChoice}\"){OpenConsole{\"Conhost\\Host_EXE\"} Terminal{\"Terminal\\CascadiaPackage\"}  TermControl{\"Terminal\\TerminalControl\"}};",
+              "$project = switch(\"${input:buildProjectChoice}\"){OpenConsole{\"Conhost\\Host_EXE\"} Terminal{\"Terminal\\CascadiaPackage\"}};",
              "$target = switch(\"${input:buildModeChoice}\"){Build{\"\"} Rebuild{\":Rebuild\"} Clean{\":Clean\"}};",
              "$target = $project + $target;",
              "msbuild",
@@ -111,11 +111,10 @@
            "description": "OpenConsole or Terminal?",
            "options":[
                "OpenConsole",
-                "Terminal",
-                "TermControl"
+                "Terminal"
            ],
            "default": "Terminal"
        }

    ]
-}
+}
--- a/.vsconfig
+++ b/.vsconfig
@@ -17,7 +17,7 @@
    "Microsoft.Net.Component.4.5.TargetingPack",
    "Microsoft.VisualStudio.Component.DiagnosticTools",
    "Microsoft.VisualStudio.Component.Debugger.JustInTime",
-    "Microsoft.VisualStudio.Component.Windows11SDK.22000",
+    "Microsoft.VisualStudio.Component.Windows10SDK.18362",
    "Microsoft.VisualStudio.ComponentGroup.UWP.Support",
    "Microsoft.VisualStudio.Component.VC.CoreIde",
    "Microsoft.VisualStudio.ComponentGroup.NativeDesktop.Core",
@@ -25,7 +25,6 @@
    "Microsoft.VisualStudio.Component.VC.Redist.14.Latest",
    "Microsoft.VisualStudio.Component.VC.Tools.x86.x64",
    "Microsoft.VisualStudio.Component.VC.Tools.ARM64",
-    "Microsoft.VisualStudio.Component.VC.ASAN",
    "Microsoft.VisualStudio.Component.VC.v142.x86.x64",
    "Microsoft.VisualStudio.Component.VC.v142.ARM64",
    "Microsoft.VisualStudio.ComponentGroup.UWP.VC",
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -43,7 +43,7 @@ If no existing item describes your issue/feature, great - please file a new issu
 * Have a question that you don't see answered in docs, videos, etc.? File an issue
 * Want to know if we're planning on building a particular feature? File an issue
 * Got a great idea for a new feature? File an issue/request/idea
-* Don't understand how to do something? File an issue
+* Don't understand how to do something? File an issue/Community Guidance Request
 * Found an existing issue that describes yours? Great - upvote and add additional commentary / info / repro-steps / etc.

 When you hit "New Issue", select the type of issue closest to what you want to report/ask/request:
@@ -99,39 +99,25 @@ If you don't have any additional info/context to add but would like to indicate

 ## Contributing fixes / features

-If you're able & willing to help fix issues and/or implement features, we'd love your contribution!
-
-The best place to start is the list of ["Easy Starter"](https://github.com/microsoft/terminal/issues?q=is%3Aopen+is%3Aissue+label%3A%22Help+Wanted%22+label%3A%22Easy+Starter%22+) issues. These are bugs or tasks that we on the team believe would be easier to implement for someone without any prior experience in the codebase. Once you're feeling more comfortable in the codebase, feel free to just use the ["Help Wanted"](https://github.com/microsoft/terminal/issues?q=is%3Aopen+is%3Aissue+label%3A%22Help+Wanted%22+) label, or just find an issue your interested in and hop in!
-
-Generally, we categorize issues in the following way, which is largely derived from our old internal work tracking system:
-* ["Bugs"](https://github.com/microsoft/terminal/issues?q=is%3Aopen+is%3Aissue+label%3A%22Issue-Bug%22+) are parts of the Terminal & Console that are not quite working the right way. There's code to already support some scenario, but it's not quite working right. Fixing these is generally a matter of debugging the broken functionality and fixing the wrong code.
-* ["Tasks"](https://github.com/microsoft/terminal/issues?q=is%3Aopen+is%3Aissue+label%3A%22Issue-Task%22+) are usually new pieces of functionality that aren't yet implemented for the Terminal/Console. These are usually smaller features, which we believe
-  - could be a single, atomic PR
-  - Don't require much design consideration, or we've already written the spec for the larger feature they belong to.
-* ["Features"](https://github.com/microsoft/terminal/issues?q=is%3Aopen+is%3Aissue+label%3A%22Issue-Feature%22+) are larger pieces of new functionality. These are usually things we believe would require larger discussion of how they should be implemented, or they'll require some complicated new settings. They might just be features that are composed of many individual tasks. Often times, with features, we like to have a spec written before development work is started, to make sure we're all on the same page (see below).
-
-Bugs and tasks are obviously the easiest to get started with, but don't feel afraid of features either! We've had some community members contribute some amazing "feature"-level work to the Terminal (albeit, with lots of discussion 😄).
-
-
-Often, we like to assign issues that generally belong to somebody's area of expertise to the team member that owns that area. This doesn't mean the community can't jump in -- they should reach out and have a chat with the assignee to see if it'd okay to take. If an issue's been assigned more than a month ago, there's a good chance it's fair game to try yourself.
+For those able & willing to help fix issues and/or implement features ...

 ### To Spec or not to Spec

 Some issues/features may be quick and simple to describe and understand. For such scenarios, once a team member has agreed with your approach, skip ahead to the section headed "Fork, Branch, and Create your PR", below.

-Small issues that do not require a spec will be labelled `Issue-Bug` or `Issue-Task`.
+Small issues that do not require a spec will be labelled Issue-Bug or Issue-Task.

-However, some issues/features will require careful thought & formal design before implementation. For these scenarios, we'll request that a spec is written and the associated issue will be labeled `Issue-Feature`. More often than not, we'll add such features to the ["Specification Tracker" project](https://github.com/microsoft/terminal/projects/1).
+However, some issues/features will require careful thought & formal design before implementation. For these scenarios, we'll request that a spec is written and the associated issue will be labeled Issue-Feature.

 Specs help collaborators discuss different approaches to solve a problem, describe how the feature will behave, how the feature will impact the user, what happens if something goes wrong, etc. Driving towards agreement in a spec, before any code is written, often results in simpler code, and less wasted effort in the long run.

-Specs will be managed in a very similar manner as code contributions so please follow the "[Fork, Branch and Create your PR](CONTRIBUTING.md#fork-clone-branch-and-create-your-pr)" section below.
+Specs will be managed in a very similar manner as code contributions so please follow the "Fork, Branch and Create your PR" below.

 ### Writing / Contributing-to a Spec

 To write/contribute to a spec: fork, branch and commit via PRs, as you would with any code changes.

-Specs are written in markdown, stored under the [`\doc\specs`](./doc/specs) folder and named `[issue id] - [spec description].md`.
+Specs are written in markdown, stored under the `\doc\spec` folder and named `[issue id] - [spec description].md`.

 👉 **It is important to follow the spec templates and complete the requested information**. The available spec templates will help ensure that specs contain the minimum information & decisions necessary to permit development to begin. In particular, specs require you to confirm that you've already discussed the issue/idea with the team in an issue and that you provide the issue ID for reference.

@@ -139,7 +125,7 @@ Team members will be happy to help review specs and guide them to completion.

 ### Help Wanted

-Once the team has approved an issue/spec, development can proceed. If no developers are immediately available, the spec can be parked ready for a developer to get started. Parked specs' issues will be labeled "Help Wanted". To find a list of development opportunities waiting for developer involvement, visit the Issues and filter on [the Help-Wanted label](https://github.com/microsoft/terminal/labels/Help%20Wanted).
+Once the team have approved an issue/spec, development can proceed. If no developers are immediately available, the spec can be parked ready for a developer to get started. Parked specs' issues will be labeled "Help Wanted". To find a list of development opportunities waiting for developer involvement, visit the Issues and filter on [the Help-Wanted label](https://github.com/microsoft/terminal/labels/Help%20Wanted).

 ---

--- a/NOTICE.md
+++ b/NOTICE.md
@@ -117,6 +117,7 @@ LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
 ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
 (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
 SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+
 ```

 ## dynamic_bitset
@@ -147,6 +148,7 @@ AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
 LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
 OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
 SOFTWARE.
+
 ```

 ## \{fmt\}
@@ -213,6 +215,7 @@ AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
 LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
 OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
 SOFTWARE.
+
 ```


@@ -246,115 +249,5 @@ SHALL THE COPYRIGHT HOLDERS OR ANYONE DISTRIBUTING THE SOFTWARE BE LIABLE
 FOR ANY DAMAGES OR OTHER LIABILITY, WHETHER IN CONTRACT, TORT OR OTHERWISE,
 ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
 DEALINGS IN THE SOFTWARE.
-```
-
-## PCG Random Number Generation
-
-**Source**: [https://github.com/imneme/pcg-cpp](https://github.com/imneme/pcg-cpp)
-
-### License

 ```
-Copyright (c) 2014-2017 Melissa O'Neill and PCG Project contributors
-
-Permission is hereby granted, free of charge, to any person obtaining a copy
-of this software and associated documentation files (the "Software"), to deal
-in the Software without restriction, including without limitation the rights
-to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
-copies of the Software, and to permit persons to whom the Software is
-furnished to do so, subject to the following conditions:
-
-The above copyright notice and this permission notice shall be included in all
-copies or substantial portions of the Software.
-
-THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
-IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
-FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
-AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
-LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
-OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
-SOFTWARE.
-```
-
-## ConEmu
-**Source**: [https://github.com/Maximus5/ConEmu](https://github.com/Maximus5/ConEmu)
-
-### License
-
-```
-BSD 3-Clause License
-
-Copyright (c) 2009-2017, Maximus5 <ConEmu.Maximus5@gmail.com>
-All rights reserved.
-
-Redistribution and use in source and binary forms, with or without
-modification, are permitted provided that the following conditions are met:
-
-* Redistributions of source code must retain the above copyright notice, this
-  list of conditions and the following disclaimer.
-
-* Redistributions in binary form must reproduce the above copyright notice,
-  this list of conditions and the following disclaimer in the documentation
-  and/or other materials provided with the distribution.
-
-* Neither the name of the copyright holder nor the names of its
-  contributors may be used to endorse or promote products derived from
-  this software without specific prior written permission.
-
-THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
-AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
-IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
-DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE
-FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
-DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
-SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
-CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
-OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
-OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
-```
-
-# Microsoft Open Source
-
-This product also incorporates source code from other Microsoft open source projects, all licensed under the MIT license.
-
-## `GSL`
-
-**Source**: [https://github.com/microsoft/GSL](https://github.com/microsoft/GSL)
-
-## `Microsoft-UI-XAML`
-
-**Source**: [https://github.com/microsoft/Microsoft-UI-XAML](https://github.com/microsoft/Microsoft-UI-XAML)
-
-## `VirtualDesktopUtils`
-
-**Source**: [https://github.com/microsoft/PowerToys](https://github.com/microsoft/PowerToys)
-
-## `wil`
-
-**Source**: [https://github.com/microsoft/wil](https://github.com/microsoft/wil)
-
-### License
-
-```
-The MIT License
-
-Copyright (c) Microsoft Corporation. All rights reserved.
-
-Permission is hereby granted, free of charge, to any person obtaining a copy
-of this software and associated documentation files (the "Software"), to deal
-in the Software without restriction, including without limitation the rights
-to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
-copies of the Software, and to permit persons to whom the Software is
-furnished to do so, subject to the following conditions:
-
-The above copyright notice and this permission notice shall be included in
-all copies or substantial portions of the Software.
-
-THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
-IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
-FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
-AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
-LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
-OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
-THE SOFTWARE.
-```
--- a/NuGet.Config
+++ b/NuGet.Config
@@ -10,8 +10,6 @@
        <clear />
    </disabledPackageSources>
    <config>
-        <!-- TODO: TEMPORARY UNTIL PGO-Helpers is updated to search both. We shouldn't need to keep the globals path here. -->
-        <add key="globalPackagesFolder" value=".\packages" />
        <add key="repositorypath" value=".\packages" />
    </config>
 </configuration>
--- a/OpenConsole.sln
+++ b/OpenConsole.sln
@@ -1,3 +1,4 @@
+
 Microsoft Visual Studio Solution File, Format Version 12.00
 # Visual Studio Version 16
 VisualStudioVersion = 16.0.29001.49
@@ -72,7 +73,6 @@ EndProject
 Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "Host.unittest", "src\host\ut_lib\host.unittest.vcxproj", "{06EC74CB-9A12-429C-B551-8562EC954747}"
 	ProjectSection(ProjectDependencies) = postProject
 		{18D09A24-8240-42D6-8CB6-236EEE820263} = {18D09A24-8240-42D6-8CB6-236EEE820263}
-		{71CC9D78-BA29-4D93-946F-BEF5D9A3A6EF} = {71CC9D78-BA29-4D93-946F-BEF5D9A3A6EF}
 	EndProjectSection
 EndProject
 Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "Host.Tests.Unit", "src\host\ut_host\Host.UnitTests.vcxproj", "{531C23E7-4B76-4C08-8AAD-04164CB628C9}"
@@ -175,9 +175,7 @@ Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "Microsoft.Terminal.Control.
 		{CA5CAD1A-C46D-4588-B1C0-40F31AE9100B} = {CA5CAD1A-C46D-4588-B1C0-40F31AE9100B}
 		{CA5CAD1A-ABCD-429C-B551-8562EC954746} = {CA5CAD1A-ABCD-429C-B551-8562EC954746}
 		{1CF55140-EF6A-4736-A403-957E4F7430BB} = {1CF55140-EF6A-4736-A403-957E4F7430BB}
-		{48D21369-3D7B-4431-9967-24E81292CF62} = {48D21369-3D7B-4431-9967-24E81292CF62}
 		{48D21369-3D7B-4431-9967-24E81292CF63} = {48D21369-3D7B-4431-9967-24E81292CF63}
-		{AF0A096A-8B3A-4949-81EF-7DF8F0FEE91F} = {AF0A096A-8B3A-4949-81EF-7DF8F0FEE91F}
 	EndProjectSection
 EndProject
 Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "Microsoft.Terminal.Control", "src\cascadia\TerminalControl\dll\TerminalControl.vcxproj", "{CA5CAD1A-F542-4635-A069-7CAEFB930070}"
@@ -267,6 +265,8 @@ Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "RendererUia", "src\renderer
 EndProject
 Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "WinRTUtils", "src\cascadia\WinRTUtils\WinRTUtils.vcxproj", "{CA5CAD1A-039A-4929-BA2A-8BEB2E4106FE}"
 EndProject
+Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "WindowsTerminalUniversal", "src\cascadia\WindowsTerminalUniversal\WindowsTerminalUniversal.vcxproj", "{B0AC39D6-7B40-49A9-8202-58549BAE1FB1}"
+EndProject
 Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "winconpty.LIB", "src\winconpty\lib\winconptylib.vcxproj", "{58A03BB2-DF5A-4B66-91A0-7EF3BA01269A}"
 EndProject
 Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "winconpty.DLL", "src\winconpty\dll\winconptydll.vcxproj", "{A22EC5F6-7851-4B88-AC52-47249D437A52}"
@@ -289,12 +289,9 @@ Project("{2150E333-8FDC-42A3-9474-1A3956D46DE8}") = "Common Props", "Common Prop
 		src\common.build.post.props = src\common.build.post.props
 		src\common.build.pre.props = src\common.build.pre.props
 		src\common.build.tests.props = src\common.build.tests.props
-		src\common.nugetversions.props = src\common.nugetversions.props
-		src\common.nugetversions.targets = src\common.nugetversions.targets
 		common.openconsole.props = common.openconsole.props
 		src\cppwinrt.build.post.props = src\cppwinrt.build.post.props
 		src\cppwinrt.build.pre.props = src\cppwinrt.build.pre.props
-		dep\nuget\packages.config = dep\nuget\packages.config
 		src\wap-common.build.post.props = src\wap-common.build.post.props
 		src\wap-common.build.pre.props = src\wap-common.build.pre.props
 	EndProjectSection
@@ -336,8 +333,6 @@ Project("{9A19103F-16F7-4668-BE54-9A1E7A4F7556}") = "WpfTerminalTestNetCore", "s
 EndProject
 Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "wt", "src\cascadia\wt\wt.vcxproj", "{506FD703-BAA7-4F6E-9361-64F550EC8FCA}"
 EndProject
-Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "elevate-shim", "src\cascadia\ElevateShim\elevate-shim.vcxproj", "{416FD703-BAA7-4F6E-9361-64F550EC8FCA}"
-EndProject
 Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "Microsoft.Terminal.Settings.Editor", "src\cascadia\TerminalSettingsEditor\Microsoft.Terminal.Settings.Editor.vcxproj", "{CA5CAD1A-0B5E-45C3-96A8-BB496BFE4E32}"
 	ProjectSection(ProjectDependencies) = postProject
 		{CA5CAD1A-082C-4476-9F33-94B339494076} = {CA5CAD1A-082C-4476-9F33-94B339494076}
@@ -398,14 +393,6 @@ Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "UnitTests_Control", "src\ca
 		{CA5CAD1A-44BD-4AC7-AC72-6CA5B3AB89ED} = {CA5CAD1A-44BD-4AC7-AC72-6CA5B3AB89ED}
 	EndProjectSection
 EndProject
-Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "WindowsTerminal.UIA.Tests", "src\cascadia\WindowsTerminal_UIATests\WindowsTerminal.UIA.Tests.csproj", "{F19DACD5-0C6E-40DC-B6E4-767A3200542C}"
-EndProject
-Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "api-ms-win-core-synch-l1-2-0", "src\api-ms-win-core-synch-l1-2-0\api-ms-win-core-synch-l1-2-0.vcxproj", "{9CF74355-F018-4C19-81AD-9DC6B7F2C6F5}"
-EndProject
-Project("{2150E333-8FDC-42A3-9474-1A3956D46DE8}") = "Utils", "Utils", "{61901E80-E97D-4D61-A9BB-E8F2FDA8B40C}"
-EndProject
-Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "RendererAtlas", "src\renderer\atlas\atlas.vcxproj", "{8222900C-8B6C-452A-91AC-BE95DB04B95F}"
-EndProject
 Global
 	GlobalSection(SolutionConfigurationPlatforms) = preSolution
 		AuditMode|Any CPU = AuditMode|Any CPU
@@ -1202,11 +1189,11 @@ Global
 		{099193A0-1E43-4BBC-BA7F-7B351E1342DF}.Debug|x86.Build.0 = Debug|Win32
 		{099193A0-1E43-4BBC-BA7F-7B351E1342DF}.Fuzzing|Any CPU.ActiveCfg = Debug|Win32
 		{099193A0-1E43-4BBC-BA7F-7B351E1342DF}.Fuzzing|ARM.ActiveCfg = Debug|Win32
-		{099193A0-1E43-4BBC-BA7F-7B351E1342DF}.Fuzzing|ARM64.ActiveCfg = Debug|ARM64
-		{099193A0-1E43-4BBC-BA7F-7B351E1342DF}.Fuzzing|DotNet_x64Test.ActiveCfg = Debug|Win32
+		{099193A0-1E43-4BBC-BA7F-7B351E1342DF}.Fuzzing|ARM64.ActiveCfg = Fuzzing|ARM64
+		{099193A0-1E43-4BBC-BA7F-7B351E1342DF}.Fuzzing|DotNet_x64Test.ActiveCfg = Fuzzing|Win32
 		{099193A0-1E43-4BBC-BA7F-7B351E1342DF}.Fuzzing|DotNet_x86Test.ActiveCfg = Debug|Win32
 		{099193A0-1E43-4BBC-BA7F-7B351E1342DF}.Fuzzing|x64.ActiveCfg = Debug|x64
-		{099193A0-1E43-4BBC-BA7F-7B351E1342DF}.Fuzzing|x86.ActiveCfg = Debug|Win32
+		{099193A0-1E43-4BBC-BA7F-7B351E1342DF}.Fuzzing|x86.ActiveCfg = Fuzzing|Win32
 		{099193A0-1E43-4BBC-BA7F-7B351E1342DF}.Release|Any CPU.ActiveCfg = Release|Win32
 		{099193A0-1E43-4BBC-BA7F-7B351E1342DF}.Release|ARM.ActiveCfg = Release|Win32
 		{099193A0-1E43-4BBC-BA7F-7B351E1342DF}.Release|ARM64.ActiveCfg = Release|ARM64
@@ -1273,6 +1260,7 @@ Global
 		{919544AC-D39B-463F-8414-3C3C67CF727C}.Fuzzing|DotNet_x64Test.ActiveCfg = Fuzzing|Win32
 		{919544AC-D39B-463F-8414-3C3C67CF727C}.Fuzzing|DotNet_x86Test.ActiveCfg = Fuzzing|Win32
 		{919544AC-D39B-463F-8414-3C3C67CF727C}.Fuzzing|x64.ActiveCfg = Fuzzing|x64
+		{919544AC-D39B-463F-8414-3C3C67CF727C}.Fuzzing|x64.Build.0 = Fuzzing|x64
 		{919544AC-D39B-463F-8414-3C3C67CF727C}.Fuzzing|x86.ActiveCfg = Fuzzing|Win32
 		{919544AC-D39B-463F-8414-3C3C67CF727C}.Release|Any CPU.ActiveCfg = Release|Win32
 		{919544AC-D39B-463F-8414-3C3C67CF727C}.Release|ARM.ActiveCfg = Release|Win32
@@ -2117,7 +2105,6 @@ Global
 		{84848BFA-931D-42CE-9ADF-01EE54DE7890}.Debug|Any CPU.ActiveCfg = Debug|Win32
 		{84848BFA-931D-42CE-9ADF-01EE54DE7890}.Debug|ARM.ActiveCfg = Debug|Win32
 		{84848BFA-931D-42CE-9ADF-01EE54DE7890}.Debug|ARM64.ActiveCfg = Debug|ARM64
-		{84848BFA-931D-42CE-9ADF-01EE54DE7890}.Debug|ARM64.Build.0 = Debug|ARM64
 		{84848BFA-931D-42CE-9ADF-01EE54DE7890}.Debug|DotNet_x64Test.ActiveCfg = Debug|x64
 		{84848BFA-931D-42CE-9ADF-01EE54DE7890}.Debug|DotNet_x64Test.Build.0 = Debug|x64
 		{84848BFA-931D-42CE-9ADF-01EE54DE7890}.Debug|DotNet_x86Test.ActiveCfg = Debug|Win32
@@ -2136,7 +2123,6 @@ Global
 		{84848BFA-931D-42CE-9ADF-01EE54DE7890}.Release|Any CPU.ActiveCfg = Release|Win32
 		{84848BFA-931D-42CE-9ADF-01EE54DE7890}.Release|ARM.ActiveCfg = Release|Win32
 		{84848BFA-931D-42CE-9ADF-01EE54DE7890}.Release|ARM64.ActiveCfg = Release|ARM64
-		{84848BFA-931D-42CE-9ADF-01EE54DE7890}.Release|ARM64.Build.0 = Release|ARM64
 		{84848BFA-931D-42CE-9ADF-01EE54DE7890}.Release|DotNet_x64Test.ActiveCfg = Release|x64
 		{84848BFA-931D-42CE-9ADF-01EE54DE7890}.Release|DotNet_x64Test.Build.0 = Release|x64
 		{84848BFA-931D-42CE-9ADF-01EE54DE7890}.Release|DotNet_x86Test.ActiveCfg = Release|Win32
@@ -2359,6 +2345,50 @@ Global
 		{CA5CAD1A-039A-4929-BA2A-8BEB2E4106FE}.Release|x64.Build.0 = Release|x64
 		{CA5CAD1A-039A-4929-BA2A-8BEB2E4106FE}.Release|x86.ActiveCfg = Release|Win32
 		{CA5CAD1A-039A-4929-BA2A-8BEB2E4106FE}.Release|x86.Build.0 = Release|Win32
+		{B0AC39D6-7B40-49A9-8202-58549BAE1FB1}.AuditMode|Any CPU.ActiveCfg = Release|x64
+		{B0AC39D6-7B40-49A9-8202-58549BAE1FB1}.AuditMode|Any CPU.Build.0 = Release|x64
+		{B0AC39D6-7B40-49A9-8202-58549BAE1FB1}.AuditMode|Any CPU.Deploy.0 = Release|x64
+		{B0AC39D6-7B40-49A9-8202-58549BAE1FB1}.AuditMode|ARM.ActiveCfg = AuditMode|Win32
+		{B0AC39D6-7B40-49A9-8202-58549BAE1FB1}.AuditMode|ARM64.ActiveCfg = Release|x64
+		{B0AC39D6-7B40-49A9-8202-58549BAE1FB1}.AuditMode|ARM64.Build.0 = Release|x64
+		{B0AC39D6-7B40-49A9-8202-58549BAE1FB1}.AuditMode|ARM64.Deploy.0 = Release|x64
+		{B0AC39D6-7B40-49A9-8202-58549BAE1FB1}.AuditMode|DotNet_x64Test.ActiveCfg = Release|x64
+		{B0AC39D6-7B40-49A9-8202-58549BAE1FB1}.AuditMode|DotNet_x86Test.ActiveCfg = Release|x64
+		{B0AC39D6-7B40-49A9-8202-58549BAE1FB1}.AuditMode|x64.ActiveCfg = Release|x64
+		{B0AC39D6-7B40-49A9-8202-58549BAE1FB1}.AuditMode|x86.ActiveCfg = Release|Win32
+		{B0AC39D6-7B40-49A9-8202-58549BAE1FB1}.AuditMode|x86.Build.0 = Release|Win32
+		{B0AC39D6-7B40-49A9-8202-58549BAE1FB1}.AuditMode|x86.Deploy.0 = Release|Win32
+		{B0AC39D6-7B40-49A9-8202-58549BAE1FB1}.Debug|Any CPU.ActiveCfg = Debug|Win32
+		{B0AC39D6-7B40-49A9-8202-58549BAE1FB1}.Debug|ARM.ActiveCfg = Debug|Win32
+		{B0AC39D6-7B40-49A9-8202-58549BAE1FB1}.Debug|ARM64.ActiveCfg = Debug|Win32
+		{B0AC39D6-7B40-49A9-8202-58549BAE1FB1}.Debug|DotNet_x64Test.ActiveCfg = Debug|Win32
+		{B0AC39D6-7B40-49A9-8202-58549BAE1FB1}.Debug|DotNet_x86Test.ActiveCfg = Debug|Win32
+		{B0AC39D6-7B40-49A9-8202-58549BAE1FB1}.Debug|x64.ActiveCfg = Debug|x64
+		{B0AC39D6-7B40-49A9-8202-58549BAE1FB1}.Debug|x64.Build.0 = Debug|x64
+		{B0AC39D6-7B40-49A9-8202-58549BAE1FB1}.Debug|x64.Deploy.0 = Debug|x64
+		{B0AC39D6-7B40-49A9-8202-58549BAE1FB1}.Debug|x86.ActiveCfg = Debug|Win32
+		{B0AC39D6-7B40-49A9-8202-58549BAE1FB1}.Debug|x86.Build.0 = Debug|Win32
+		{B0AC39D6-7B40-49A9-8202-58549BAE1FB1}.Debug|x86.Deploy.0 = Debug|Win32
+		{B0AC39D6-7B40-49A9-8202-58549BAE1FB1}.Fuzzing|Any CPU.ActiveCfg = Fuzzing|Win32
+		{B0AC39D6-7B40-49A9-8202-58549BAE1FB1}.Fuzzing|ARM.ActiveCfg = Fuzzing|Win32
+		{B0AC39D6-7B40-49A9-8202-58549BAE1FB1}.Fuzzing|ARM64.ActiveCfg = Fuzzing|ARM64
+		{B0AC39D6-7B40-49A9-8202-58549BAE1FB1}.Fuzzing|DotNet_x64Test.ActiveCfg = Fuzzing|Win32
+		{B0AC39D6-7B40-49A9-8202-58549BAE1FB1}.Fuzzing|DotNet_x86Test.ActiveCfg = Fuzzing|Win32
+		{B0AC39D6-7B40-49A9-8202-58549BAE1FB1}.Fuzzing|x64.ActiveCfg = Fuzzing|x64
+		{B0AC39D6-7B40-49A9-8202-58549BAE1FB1}.Fuzzing|x86.ActiveCfg = Fuzzing|Win32
+		{B0AC39D6-7B40-49A9-8202-58549BAE1FB1}.Release|Any CPU.ActiveCfg = Release|Win32
+		{B0AC39D6-7B40-49A9-8202-58549BAE1FB1}.Release|ARM.ActiveCfg = Release|Win32
+		{B0AC39D6-7B40-49A9-8202-58549BAE1FB1}.Release|ARM64.ActiveCfg = Release|ARM64
+		{B0AC39D6-7B40-49A9-8202-58549BAE1FB1}.Release|ARM64.Build.0 = Release|ARM64
+		{B0AC39D6-7B40-49A9-8202-58549BAE1FB1}.Release|ARM64.Deploy.0 = Release|ARM64
+		{B0AC39D6-7B40-49A9-8202-58549BAE1FB1}.Release|DotNet_x64Test.ActiveCfg = Release|Win32
+		{B0AC39D6-7B40-49A9-8202-58549BAE1FB1}.Release|DotNet_x86Test.ActiveCfg = Release|Win32
+		{B0AC39D6-7B40-49A9-8202-58549BAE1FB1}.Release|x64.ActiveCfg = Release|x64
+		{B0AC39D6-7B40-49A9-8202-58549BAE1FB1}.Release|x64.Build.0 = Release|x64
+		{B0AC39D6-7B40-49A9-8202-58549BAE1FB1}.Release|x64.Deploy.0 = Release|x64
+		{B0AC39D6-7B40-49A9-8202-58549BAE1FB1}.Release|x86.ActiveCfg = Release|Win32
+		{B0AC39D6-7B40-49A9-8202-58549BAE1FB1}.Release|x86.Build.0 = Release|Win32
+		{B0AC39D6-7B40-49A9-8202-58549BAE1FB1}.Release|x86.Deploy.0 = Release|Win32
 		{58A03BB2-DF5A-4B66-91A0-7EF3BA01269A}.AuditMode|Any CPU.ActiveCfg = AuditMode|Win32
 		{58A03BB2-DF5A-4B66-91A0-7EF3BA01269A}.AuditMode|ARM.ActiveCfg = AuditMode|Win32
 		{58A03BB2-DF5A-4B66-91A0-7EF3BA01269A}.AuditMode|ARM64.ActiveCfg = AuditMode|ARM64
@@ -2766,43 +2796,6 @@ Global
 		{506FD703-BAA7-4F6E-9361-64F550EC8FCA}.Release|x64.Build.0 = Release|x64
 		{506FD703-BAA7-4F6E-9361-64F550EC8FCA}.Release|x86.ActiveCfg = Release|Win32
 		{506FD703-BAA7-4F6E-9361-64F550EC8FCA}.Release|x86.Build.0 = Release|Win32
-		{416FD703-BAA7-4F6E-9361-64F550EC8FCA}.AuditMode|Any CPU.ActiveCfg = AuditMode|Win32
-		{416FD703-BAA7-4F6E-9361-64F550EC8FCA}.AuditMode|ARM.ActiveCfg = AuditMode|Win32
-		{416FD703-BAA7-4F6E-9361-64F550EC8FCA}.AuditMode|ARM64.ActiveCfg = AuditMode|ARM64
-		{416FD703-BAA7-4F6E-9361-64F550EC8FCA}.AuditMode|ARM64.Build.0 = AuditMode|ARM64
-		{416FD703-BAA7-4F6E-9361-64F550EC8FCA}.AuditMode|DotNet_x64Test.ActiveCfg = AuditMode|Win32
-		{416FD703-BAA7-4F6E-9361-64F550EC8FCA}.AuditMode|DotNet_x86Test.ActiveCfg = AuditMode|Win32
-		{416FD703-BAA7-4F6E-9361-64F550EC8FCA}.AuditMode|x64.ActiveCfg = AuditMode|x64
-		{416FD703-BAA7-4F6E-9361-64F550EC8FCA}.AuditMode|x64.Build.0 = AuditMode|x64
-		{416FD703-BAA7-4F6E-9361-64F550EC8FCA}.AuditMode|x86.ActiveCfg = AuditMode|Win32
-		{416FD703-BAA7-4F6E-9361-64F550EC8FCA}.AuditMode|x86.Build.0 = AuditMode|Win32
-		{416FD703-BAA7-4F6E-9361-64F550EC8FCA}.Debug|Any CPU.ActiveCfg = Debug|Win32
-		{416FD703-BAA7-4F6E-9361-64F550EC8FCA}.Debug|ARM.ActiveCfg = Debug|Win32
-		{416FD703-BAA7-4F6E-9361-64F550EC8FCA}.Debug|ARM64.ActiveCfg = Debug|ARM64
-		{416FD703-BAA7-4F6E-9361-64F550EC8FCA}.Debug|ARM64.Build.0 = Debug|ARM64
-		{416FD703-BAA7-4F6E-9361-64F550EC8FCA}.Debug|DotNet_x64Test.ActiveCfg = Debug|Win32
-		{416FD703-BAA7-4F6E-9361-64F550EC8FCA}.Debug|DotNet_x86Test.ActiveCfg = Debug|Win32
-		{416FD703-BAA7-4F6E-9361-64F550EC8FCA}.Debug|x64.ActiveCfg = Debug|x64
-		{416FD703-BAA7-4F6E-9361-64F550EC8FCA}.Debug|x64.Build.0 = Debug|x64
-		{416FD703-BAA7-4F6E-9361-64F550EC8FCA}.Debug|x86.ActiveCfg = Debug|Win32
-		{416FD703-BAA7-4F6E-9361-64F550EC8FCA}.Debug|x86.Build.0 = Debug|Win32
-		{416FD703-BAA7-4F6E-9361-64F550EC8FCA}.Fuzzing|Any CPU.ActiveCfg = Fuzzing|Win32
-		{416FD703-BAA7-4F6E-9361-64F550EC8FCA}.Fuzzing|ARM.ActiveCfg = Fuzzing|Win32
-		{416FD703-BAA7-4F6E-9361-64F550EC8FCA}.Fuzzing|ARM64.ActiveCfg = Fuzzing|ARM64
-		{416FD703-BAA7-4F6E-9361-64F550EC8FCA}.Fuzzing|DotNet_x64Test.ActiveCfg = Fuzzing|Win32
-		{416FD703-BAA7-4F6E-9361-64F550EC8FCA}.Fuzzing|DotNet_x86Test.ActiveCfg = Fuzzing|Win32
-		{416FD703-BAA7-4F6E-9361-64F550EC8FCA}.Fuzzing|x64.ActiveCfg = Fuzzing|x64
-		{416FD703-BAA7-4F6E-9361-64F550EC8FCA}.Fuzzing|x86.ActiveCfg = Fuzzing|Win32
-		{416FD703-BAA7-4F6E-9361-64F550EC8FCA}.Release|Any CPU.ActiveCfg = Release|Win32
-		{416FD703-BAA7-4F6E-9361-64F550EC8FCA}.Release|ARM.ActiveCfg = Release|Win32
-		{416FD703-BAA7-4F6E-9361-64F550EC8FCA}.Release|ARM64.ActiveCfg = Release|ARM64
-		{416FD703-BAA7-4F6E-9361-64F550EC8FCA}.Release|ARM64.Build.0 = Release|ARM64
-		{416FD703-BAA7-4F6E-9361-64F550EC8FCA}.Release|DotNet_x64Test.ActiveCfg = Release|Win32
-		{416FD703-BAA7-4F6E-9361-64F550EC8FCA}.Release|DotNet_x86Test.ActiveCfg = Release|Win32
-		{416FD703-BAA7-4F6E-9361-64F550EC8FCA}.Release|x64.ActiveCfg = Release|x64
-		{416FD703-BAA7-4F6E-9361-64F550EC8FCA}.Release|x64.Build.0 = Release|x64
-		{416FD703-BAA7-4F6E-9361-64F550EC8FCA}.Release|x86.ActiveCfg = Release|Win32
-		{416FD703-BAA7-4F6E-9361-64F550EC8FCA}.Release|x86.Build.0 = Release|Win32
 		{CA5CAD1A-0B5E-45C3-96A8-BB496BFE4E32}.AuditMode|Any CPU.ActiveCfg = Release|x64
 		{CA5CAD1A-0B5E-45C3-96A8-BB496BFE4E32}.AuditMode|Any CPU.Build.0 = Release|x64
 		{CA5CAD1A-0B5E-45C3-96A8-BB496BFE4E32}.AuditMode|Any CPU.Deploy.0 = Release|x64
@@ -3244,10 +3237,13 @@ Global
 		{C323DAEE-B307-4C7B-ACE5-7293CBEFCB5B}.Fuzzing|Any CPU.ActiveCfg = Fuzzing|Win32
 		{C323DAEE-B307-4C7B-ACE5-7293CBEFCB5B}.Fuzzing|ARM.ActiveCfg = Fuzzing|Win32
 		{C323DAEE-B307-4C7B-ACE5-7293CBEFCB5B}.Fuzzing|ARM64.ActiveCfg = Fuzzing|ARM64
+		{C323DAEE-B307-4C7B-ACE5-7293CBEFCB5B}.Fuzzing|ARM64.Build.0 = Fuzzing|ARM64
 		{C323DAEE-B307-4C7B-ACE5-7293CBEFCB5B}.Fuzzing|DotNet_x64Test.ActiveCfg = Fuzzing|Win32
 		{C323DAEE-B307-4C7B-ACE5-7293CBEFCB5B}.Fuzzing|DotNet_x86Test.ActiveCfg = Fuzzing|Win32
 		{C323DAEE-B307-4C7B-ACE5-7293CBEFCB5B}.Fuzzing|x64.ActiveCfg = Fuzzing|x64
+		{C323DAEE-B307-4C7B-ACE5-7293CBEFCB5B}.Fuzzing|x64.Build.0 = Fuzzing|x64
 		{C323DAEE-B307-4C7B-ACE5-7293CBEFCB5B}.Fuzzing|x86.ActiveCfg = Fuzzing|Win32
+		{C323DAEE-B307-4C7B-ACE5-7293CBEFCB5B}.Fuzzing|x86.Build.0 = Fuzzing|Win32
 		{C323DAEE-B307-4C7B-ACE5-7293CBEFCB5B}.Release|Any CPU.ActiveCfg = Release|Win32
 		{C323DAEE-B307-4C7B-ACE5-7293CBEFCB5B}.Release|ARM.ActiveCfg = Release|Win32
 		{C323DAEE-B307-4C7B-ACE5-7293CBEFCB5B}.Release|ARM64.ActiveCfg = Release|ARM64
@@ -3258,123 +3254,6 @@ Global
 		{C323DAEE-B307-4C7B-ACE5-7293CBEFCB5B}.Release|x64.Build.0 = Release|x64
 		{C323DAEE-B307-4C7B-ACE5-7293CBEFCB5B}.Release|x86.ActiveCfg = Release|Win32
 		{C323DAEE-B307-4C7B-ACE5-7293CBEFCB5B}.Release|x86.Build.0 = Release|Win32
-		{F19DACD5-0C6E-40DC-B6E4-767A3200542C}.AuditMode|Any CPU.ActiveCfg = Debug|Win32
-		{F19DACD5-0C6E-40DC-B6E4-767A3200542C}.AuditMode|ARM.ActiveCfg = Debug|Win32
-		{F19DACD5-0C6E-40DC-B6E4-767A3200542C}.AuditMode|ARM64.ActiveCfg = Debug|ARM64
-		{F19DACD5-0C6E-40DC-B6E4-767A3200542C}.AuditMode|DotNet_x64Test.ActiveCfg = Debug|x64
-		{F19DACD5-0C6E-40DC-B6E4-767A3200542C}.AuditMode|DotNet_x86Test.ActiveCfg = Debug|Win32
-		{F19DACD5-0C6E-40DC-B6E4-767A3200542C}.AuditMode|x64.ActiveCfg = Debug|x64
-		{F19DACD5-0C6E-40DC-B6E4-767A3200542C}.AuditMode|x86.ActiveCfg = Debug|Win32
-		{F19DACD5-0C6E-40DC-B6E4-767A3200542C}.Debug|Any CPU.ActiveCfg = Debug|Win32
-		{F19DACD5-0C6E-40DC-B6E4-767A3200542C}.Debug|ARM.ActiveCfg = Debug|Win32
-		{F19DACD5-0C6E-40DC-B6E4-767A3200542C}.Debug|ARM64.ActiveCfg = Debug|ARM64
-		{F19DACD5-0C6E-40DC-B6E4-767A3200542C}.Debug|ARM64.Build.0 = Debug|ARM64
-		{F19DACD5-0C6E-40DC-B6E4-767A3200542C}.Debug|DotNet_x64Test.ActiveCfg = Debug|x64
-		{F19DACD5-0C6E-40DC-B6E4-767A3200542C}.Debug|DotNet_x86Test.ActiveCfg = Debug|Win32
-		{F19DACD5-0C6E-40DC-B6E4-767A3200542C}.Debug|x64.ActiveCfg = Debug|x64
-		{F19DACD5-0C6E-40DC-B6E4-767A3200542C}.Debug|x64.Build.0 = Debug|x64
-		{F19DACD5-0C6E-40DC-B6E4-767A3200542C}.Debug|x86.ActiveCfg = Debug|Win32
-		{F19DACD5-0C6E-40DC-B6E4-767A3200542C}.Debug|x86.Build.0 = Debug|Win32
-		{F19DACD5-0C6E-40DC-B6E4-767A3200542C}.Fuzzing|Any CPU.ActiveCfg = Debug|Win32
-		{F19DACD5-0C6E-40DC-B6E4-767A3200542C}.Fuzzing|ARM.ActiveCfg = Debug|Win32
-		{F19DACD5-0C6E-40DC-B6E4-767A3200542C}.Fuzzing|ARM64.ActiveCfg = Debug|ARM64
-		{F19DACD5-0C6E-40DC-B6E4-767A3200542C}.Fuzzing|DotNet_x64Test.ActiveCfg = Debug|x64
-		{F19DACD5-0C6E-40DC-B6E4-767A3200542C}.Fuzzing|DotNet_x86Test.ActiveCfg = Debug|Win32
-		{F19DACD5-0C6E-40DC-B6E4-767A3200542C}.Fuzzing|x64.ActiveCfg = Debug|x64
-		{F19DACD5-0C6E-40DC-B6E4-767A3200542C}.Fuzzing|x86.ActiveCfg = Debug|Win32
-		{F19DACD5-0C6E-40DC-B6E4-767A3200542C}.Release|Any CPU.ActiveCfg = Release|Win32
-		{F19DACD5-0C6E-40DC-B6E4-767A3200542C}.Release|ARM.ActiveCfg = Release|Win32
-		{F19DACD5-0C6E-40DC-B6E4-767A3200542C}.Release|ARM64.ActiveCfg = Release|ARM64
-		{F19DACD5-0C6E-40DC-B6E4-767A3200542C}.Release|ARM64.Build.0 = Release|ARM64
-		{F19DACD5-0C6E-40DC-B6E4-767A3200542C}.Release|DotNet_x64Test.ActiveCfg = Release|x64
-		{F19DACD5-0C6E-40DC-B6E4-767A3200542C}.Release|DotNet_x86Test.ActiveCfg = Release|Win32
-		{F19DACD5-0C6E-40DC-B6E4-767A3200542C}.Release|x64.ActiveCfg = Release|x64
-		{F19DACD5-0C6E-40DC-B6E4-767A3200542C}.Release|x64.Build.0 = Release|x64
-		{F19DACD5-0C6E-40DC-B6E4-767A3200542C}.Release|x86.ActiveCfg = Release|Win32
-		{F19DACD5-0C6E-40DC-B6E4-767A3200542C}.Release|x86.Build.0 = Release|Win32
-		{9CF74355-F018-4C19-81AD-9DC6B7F2C6F5}.AuditMode|Any CPU.ActiveCfg = AuditMode|Win32
-		{9CF74355-F018-4C19-81AD-9DC6B7F2C6F5}.AuditMode|ARM.ActiveCfg = AuditMode|Win32
-		{9CF74355-F018-4C19-81AD-9DC6B7F2C6F5}.AuditMode|ARM64.ActiveCfg = AuditMode|ARM64
-		{9CF74355-F018-4C19-81AD-9DC6B7F2C6F5}.AuditMode|ARM64.Build.0 = AuditMode|ARM64
-		{9CF74355-F018-4C19-81AD-9DC6B7F2C6F5}.AuditMode|DotNet_x64Test.ActiveCfg = AuditMode|Win32
-		{9CF74355-F018-4C19-81AD-9DC6B7F2C6F5}.AuditMode|DotNet_x86Test.ActiveCfg = AuditMode|Win32
-		{9CF74355-F018-4C19-81AD-9DC6B7F2C6F5}.AuditMode|x64.ActiveCfg = AuditMode|x64
-		{9CF74355-F018-4C19-81AD-9DC6B7F2C6F5}.AuditMode|x64.Build.0 = AuditMode|x64
-		{9CF74355-F018-4C19-81AD-9DC6B7F2C6F5}.AuditMode|x86.ActiveCfg = AuditMode|Win32
-		{9CF74355-F018-4C19-81AD-9DC6B7F2C6F5}.AuditMode|x86.Build.0 = AuditMode|Win32
-		{9CF74355-F018-4C19-81AD-9DC6B7F2C6F5}.Debug|Any CPU.ActiveCfg = Debug|Win32
-		{9CF74355-F018-4C19-81AD-9DC6B7F2C6F5}.Debug|ARM.ActiveCfg = Debug|Win32
-		{9CF74355-F018-4C19-81AD-9DC6B7F2C6F5}.Debug|ARM64.ActiveCfg = Debug|ARM64
-		{9CF74355-F018-4C19-81AD-9DC6B7F2C6F5}.Debug|ARM64.Build.0 = Debug|ARM64
-		{9CF74355-F018-4C19-81AD-9DC6B7F2C6F5}.Debug|DotNet_x64Test.ActiveCfg = Debug|x64
-		{9CF74355-F018-4C19-81AD-9DC6B7F2C6F5}.Debug|DotNet_x64Test.Build.0 = Debug|x64
-		{9CF74355-F018-4C19-81AD-9DC6B7F2C6F5}.Debug|DotNet_x86Test.ActiveCfg = Debug|Win32
-		{9CF74355-F018-4C19-81AD-9DC6B7F2C6F5}.Debug|DotNet_x86Test.Build.0 = Debug|Win32
-		{9CF74355-F018-4C19-81AD-9DC6B7F2C6F5}.Debug|x64.ActiveCfg = Debug|x64
-		{9CF74355-F018-4C19-81AD-9DC6B7F2C6F5}.Debug|x64.Build.0 = Debug|x64
-		{9CF74355-F018-4C19-81AD-9DC6B7F2C6F5}.Debug|x86.ActiveCfg = Debug|Win32
-		{9CF74355-F018-4C19-81AD-9DC6B7F2C6F5}.Debug|x86.Build.0 = Debug|Win32
-		{9CF74355-F018-4C19-81AD-9DC6B7F2C6F5}.Fuzzing|Any CPU.ActiveCfg = Fuzzing|Win32
-		{9CF74355-F018-4C19-81AD-9DC6B7F2C6F5}.Fuzzing|ARM.ActiveCfg = Fuzzing|Win32
-		{9CF74355-F018-4C19-81AD-9DC6B7F2C6F5}.Fuzzing|ARM64.ActiveCfg = Fuzzing|ARM64
-		{9CF74355-F018-4C19-81AD-9DC6B7F2C6F5}.Fuzzing|ARM64.Build.0 = Fuzzing|ARM64
-		{9CF74355-F018-4C19-81AD-9DC6B7F2C6F5}.Fuzzing|DotNet_x64Test.ActiveCfg = Fuzzing|Win32
-		{9CF74355-F018-4C19-81AD-9DC6B7F2C6F5}.Fuzzing|DotNet_x86Test.ActiveCfg = Fuzzing|Win32
-		{9CF74355-F018-4C19-81AD-9DC6B7F2C6F5}.Fuzzing|x64.ActiveCfg = Fuzzing|x64
-		{9CF74355-F018-4C19-81AD-9DC6B7F2C6F5}.Fuzzing|x86.ActiveCfg = Fuzzing|Win32
-		{9CF74355-F018-4C19-81AD-9DC6B7F2C6F5}.Fuzzing|x86.Build.0 = Fuzzing|Win32
-		{9CF74355-F018-4C19-81AD-9DC6B7F2C6F5}.Release|Any CPU.ActiveCfg = Release|Win32
-		{9CF74355-F018-4C19-81AD-9DC6B7F2C6F5}.Release|ARM.ActiveCfg = Release|Win32
-		{9CF74355-F018-4C19-81AD-9DC6B7F2C6F5}.Release|ARM64.ActiveCfg = Release|ARM64
-		{9CF74355-F018-4C19-81AD-9DC6B7F2C6F5}.Release|ARM64.Build.0 = Release|ARM64
-		{9CF74355-F018-4C19-81AD-9DC6B7F2C6F5}.Release|DotNet_x64Test.ActiveCfg = Release|x64
-		{9CF74355-F018-4C19-81AD-9DC6B7F2C6F5}.Release|DotNet_x64Test.Build.0 = Release|x64
-		{9CF74355-F018-4C19-81AD-9DC6B7F2C6F5}.Release|DotNet_x86Test.ActiveCfg = Release|Win32
-		{9CF74355-F018-4C19-81AD-9DC6B7F2C6F5}.Release|DotNet_x86Test.Build.0 = Release|Win32
-		{9CF74355-F018-4C19-81AD-9DC6B7F2C6F5}.Release|x64.ActiveCfg = Release|x64
-		{9CF74355-F018-4C19-81AD-9DC6B7F2C6F5}.Release|x64.Build.0 = Release|x64
-		{9CF74355-F018-4C19-81AD-9DC6B7F2C6F5}.Release|x86.ActiveCfg = Release|Win32
-		{9CF74355-F018-4C19-81AD-9DC6B7F2C6F5}.Release|x86.Build.0 = Release|Win32
-		{8222900C-8B6C-452A-91AC-BE95DB04B95F}.AuditMode|Any CPU.ActiveCfg = AuditMode|Win32
-		{8222900C-8B6C-452A-91AC-BE95DB04B95F}.AuditMode|ARM.ActiveCfg = AuditMode|Win32
-		{8222900C-8B6C-452A-91AC-BE95DB04B95F}.AuditMode|ARM64.ActiveCfg = AuditMode|ARM64
-		{8222900C-8B6C-452A-91AC-BE95DB04B95F}.AuditMode|ARM64.Build.0 = AuditMode|ARM64
-		{8222900C-8B6C-452A-91AC-BE95DB04B95F}.AuditMode|DotNet_x64Test.ActiveCfg = AuditMode|Win32
-		{8222900C-8B6C-452A-91AC-BE95DB04B95F}.AuditMode|DotNet_x86Test.ActiveCfg = AuditMode|Win32
-		{8222900C-8B6C-452A-91AC-BE95DB04B95F}.AuditMode|x64.ActiveCfg = AuditMode|x64
-		{8222900C-8B6C-452A-91AC-BE95DB04B95F}.AuditMode|x64.Build.0 = AuditMode|x64
-		{8222900C-8B6C-452A-91AC-BE95DB04B95F}.AuditMode|x86.ActiveCfg = AuditMode|Win32
-		{8222900C-8B6C-452A-91AC-BE95DB04B95F}.AuditMode|x86.Build.0 = AuditMode|Win32
-		{8222900C-8B6C-452A-91AC-BE95DB04B95F}.Debug|Any CPU.ActiveCfg = Debug|Win32
-		{8222900C-8B6C-452A-91AC-BE95DB04B95F}.Debug|ARM.ActiveCfg = Debug|Win32
-		{8222900C-8B6C-452A-91AC-BE95DB04B95F}.Debug|ARM64.ActiveCfg = Debug|ARM64
-		{8222900C-8B6C-452A-91AC-BE95DB04B95F}.Debug|ARM64.Build.0 = Debug|ARM64
-		{8222900C-8B6C-452A-91AC-BE95DB04B95F}.Debug|DotNet_x64Test.ActiveCfg = Debug|Win32
-		{8222900C-8B6C-452A-91AC-BE95DB04B95F}.Debug|DotNet_x86Test.ActiveCfg = Debug|Win32
-		{8222900C-8B6C-452A-91AC-BE95DB04B95F}.Debug|x64.ActiveCfg = Debug|x64
-		{8222900C-8B6C-452A-91AC-BE95DB04B95F}.Debug|x64.Build.0 = Debug|x64
-		{8222900C-8B6C-452A-91AC-BE95DB04B95F}.Debug|x86.ActiveCfg = Debug|Win32
-		{8222900C-8B6C-452A-91AC-BE95DB04B95F}.Debug|x86.Build.0 = Debug|Win32
-		{8222900C-8B6C-452A-91AC-BE95DB04B95F}.Fuzzing|Any CPU.ActiveCfg = Fuzzing|Win32
-		{8222900C-8B6C-452A-91AC-BE95DB04B95F}.Fuzzing|ARM.ActiveCfg = Fuzzing|Win32
-		{8222900C-8B6C-452A-91AC-BE95DB04B95F}.Fuzzing|ARM64.ActiveCfg = Fuzzing|ARM64
-		{8222900C-8B6C-452A-91AC-BE95DB04B95F}.Fuzzing|ARM64.Build.0 = Fuzzing|ARM64
-		{8222900C-8B6C-452A-91AC-BE95DB04B95F}.Fuzzing|DotNet_x64Test.ActiveCfg = Fuzzing|Win32
-		{8222900C-8B6C-452A-91AC-BE95DB04B95F}.Fuzzing|DotNet_x86Test.ActiveCfg = Fuzzing|Win32
-		{8222900C-8B6C-452A-91AC-BE95DB04B95F}.Fuzzing|x64.ActiveCfg = Fuzzing|x64
-		{8222900C-8B6C-452A-91AC-BE95DB04B95F}.Fuzzing|x64.Build.0 = Fuzzing|x64
-		{8222900C-8B6C-452A-91AC-BE95DB04B95F}.Fuzzing|x86.ActiveCfg = Fuzzing|Win32
-		{8222900C-8B6C-452A-91AC-BE95DB04B95F}.Fuzzing|x86.Build.0 = Fuzzing|Win32
-		{8222900C-8B6C-452A-91AC-BE95DB04B95F}.Release|Any CPU.ActiveCfg = Release|Win32
-		{8222900C-8B6C-452A-91AC-BE95DB04B95F}.Release|ARM.ActiveCfg = Release|Win32
-		{8222900C-8B6C-452A-91AC-BE95DB04B95F}.Release|ARM64.ActiveCfg = Release|ARM64
-		{8222900C-8B6C-452A-91AC-BE95DB04B95F}.Release|ARM64.Build.0 = Release|ARM64
-		{8222900C-8B6C-452A-91AC-BE95DB04B95F}.Release|DotNet_x64Test.ActiveCfg = Release|Win32
-		{8222900C-8B6C-452A-91AC-BE95DB04B95F}.Release|DotNet_x86Test.ActiveCfg = Release|Win32
-		{8222900C-8B6C-452A-91AC-BE95DB04B95F}.Release|x64.ActiveCfg = Release|x64
-		{8222900C-8B6C-452A-91AC-BE95DB04B95F}.Release|x64.Build.0 = Release|x64
-		{8222900C-8B6C-452A-91AC-BE95DB04B95F}.Release|x86.ActiveCfg = Release|Win32
-		{8222900C-8B6C-452A-91AC-BE95DB04B95F}.Release|x86.Build.0 = Release|Win32
 	EndGlobalSection
 	GlobalSection(SolutionProperties) = preSolution
 		HideSolutionNode = FALSE
@@ -3439,7 +3318,8 @@ Global
 		{CA5CAD1A-9A12-429C-B551-8562EC954746} = {59840756-302F-44DF-AA47-441A9D673202}
 		{CA5CAD1A-B11C-4DDB-A4FE-C3AFAE9B5506} = {BDB237B6-1D1D-400F-84CC-40A58FA59C8E}
 		{48D21369-3D7B-4431-9967-24E81292CF63} = {05500DEF-2294-41E3-AF9A-24E580B82836}
-		{CA5CAD1A-039A-4929-BA2A-8BEB2E4106FE} = {61901E80-E97D-4D61-A9BB-E8F2FDA8B40C}
+		{CA5CAD1A-039A-4929-BA2A-8BEB2E4106FE} = {59840756-302F-44DF-AA47-441A9D673202}
+		{B0AC39D6-7B40-49A9-8202-58549BAE1FB1} = {59840756-302F-44DF-AA47-441A9D673202}
 		{58A03BB2-DF5A-4B66-91A0-7EF3BA01269A} = {E8F24881-5E37-4362-B191-A3BA0ED7F4EB}
 		{A22EC5F6-7851-4B88-AC52-47249D437A52} = {E8F24881-5E37-4362-B191-A3BA0ED7F4EB}
 		{A021EDFF-45C8-4DC2-BEF7-36E1B3B8CFE8} = {BDB237B6-1D1D-400F-84CC-40A58FA59C8E}
@@ -3451,11 +3331,10 @@ Global
 		{D3EF7B96-CD5E-47C9-B9A9-136259563033} = {04170EEF-983A-4195-BFEF-2321E5E38A1E}
 		{95B136F9-B238-490C-A7C5-5843C1FECAC4} = {05500DEF-2294-41E3-AF9A-24E580B82836}
 		{024052DE-83FB-4653-AEA4-90790D29D5BD} = {E8F24881-5E37-4362-B191-A3BA0ED7F4EB}
-		{067F0A06-FCB7-472C-96E9-B03B54E8E18D} = {61901E80-E97D-4D61-A9BB-E8F2FDA8B40C}
+		{067F0A06-FCB7-472C-96E9-B03B54E8E18D} = {59840756-302F-44DF-AA47-441A9D673202}
 		{6BAE5851-50D5-4934-8D5E-30361A8A40F3} = {81C352DB-1818-45B7-A284-18E259F1CC87}
 		{1588FD7C-241E-4E7D-9113-43735F3E6BAD} = {4DAF0299-495E-4CD1-A982-9BAC16A45932}
-		{506FD703-BAA7-4F6E-9361-64F550EC8FCA} = {61901E80-E97D-4D61-A9BB-E8F2FDA8B40C}
-		{416FD703-BAA7-4F6E-9361-64F550EC8FCA} = {61901E80-E97D-4D61-A9BB-E8F2FDA8B40C}
+		{506FD703-BAA7-4F6E-9361-64F550EC8FCA} = {59840756-302F-44DF-AA47-441A9D673202}
 		{CA5CAD1A-0B5E-45C3-96A8-BB496BFE4E32} = {77875138-BB08-49F9-8BB1-409C2150E0E1}
 		{CA5CAD1A-D7EC-4107-B7C6-79CB77AE2907} = {77875138-BB08-49F9-8BB1-409C2150E0E1}
 		{CA5CAD1A-082C-4476-9F33-94B339494076} = {77875138-BB08-49F9-8BB1-409C2150E0E1}
@@ -3472,10 +3351,6 @@ Global
 		{9921CA0A-320C-4460-8623-3A3196E7F4CB} = {59840756-302F-44DF-AA47-441A9D673202}
 		{05D9052F-D78F-478F-968A-2DE38A6DB996} = {E8F24881-5E37-4362-B191-A3BA0ED7F4EB}
 		{C323DAEE-B307-4C7B-ACE5-7293CBEFCB5B} = {BDB237B6-1D1D-400F-84CC-40A58FA59C8E}
-		{F19DACD5-0C6E-40DC-B6E4-767A3200542C} = {BDB237B6-1D1D-400F-84CC-40A58FA59C8E}
-		{9CF74355-F018-4C19-81AD-9DC6B7F2C6F5} = {89CDCC5C-9F53-4054-97A4-639D99F169CD}
-		{61901E80-E97D-4D61-A9BB-E8F2FDA8B40C} = {59840756-302F-44DF-AA47-441A9D673202}
-		{8222900C-8B6C-452A-91AC-BE95DB04B95F} = {05500DEF-2294-41E3-AF9A-24E580B82836}
 	EndGlobalSection
 	GlobalSection(ExtensibilityGlobals) = postSolution
 		SolutionGuid = {3140B1B7-C8EE-43D1-A772-D82A7061A271}
--- a/README.md
+++ b/README.md
@@ -1,5 +1,3 @@
-![terminal-logos](https://user-images.githubusercontent.com/48369326/115790869-4c852b00-a37c-11eb-97f1-f61972c7800c.png)
-
 # Welcome to the Windows Terminal, Console and Command-Line repo

 This repository contains the source code for:
@@ -21,7 +19,7 @@ Related repositories include:

 ## Installing and running Windows Terminal

-> 🔴 Note: Windows Terminal requires Windows 10 2004 (build 19041) or later
+> 🔴 Note: Windows Terminal requires Windows 10 1903 (build 18362) or later

 ### Microsoft Store [Recommended]

@@ -214,7 +212,7 @@ resources useful and interesting:
 * Windows Terminal Launch: [Build 2019
  Session](https://www.youtube.com/watch?v=KMudkRcwjCw)
 * Run As Radio: [Show 645 - Windows Terminal with Richard
-  Turner](https://www.runasradio.com/Shows/Show/645)
+  Turner](http://www.runasradio.com/Shows/Show/645)
 * Azure Devops Podcast: [Episode 54 - Kayla Cinnamon and Rich Turner on DevOps
  on the Windows
  Terminal](http://azuredevopspodcast.clear-measure.com/kayla-cinnamon-and-rich-turner-on-devops-on-the-windows-terminal-team-episode-54)
@@ -243,7 +241,7 @@ Visual Studio.

 ## Documentation

-All project documentation is located at [aka.ms/terminal-docs](https://aka.ms/terminal-docs). If you would like
+All project documentation is located at aka.ms/terminal-docs. If you would like
 to contribute to the documentation, please submit a pull request on the [Windows
 Terminal Documentation repo](https://github.com/MicrosoftDocs/terminal).

@@ -272,23 +270,24 @@ If you would like to ask a question that you feel doesn't warrant an issue
 * Kayla Cinnamon, Program Manager:
  [@cinnamon\_msft](https://twitter.com/cinnamon_msft)
 * Dustin Howett, Engineering Lead: [@dhowett](https://twitter.com/DHowett)
-* Mike Griese, Senior Developer: [@zadjii](https://twitter.com/zadjii)
+* Michael Niksa, Senior Developer:
+  [@michaelniksa](https://twitter.com/MichaelNiksa)
+* Mike Griese, Developer: [@zadjii](https://twitter.com/zadjii)
 * Carlos Zamora, Developer: [@cazamor_msft](https://twitter.com/cazamor_msft)
+* Leon Liang, Developer: [@leonmsft](https://twitter.com/leonmsft)
 * Pankaj Bhojwani, Developer
-* Leonard Hecker, Developer: [@LeonardHecker](https://twitter.com/LeonardHecker)

 ## Developer Guidance

 ## Prerequisites

-* You must be running Windows 10 2004 (build >= 10.0.19041.0) or later to run
+* You must be running Windows 1903 (build >= 10.0.18362.0) or later to run
  Windows Terminal
 * You must [enable Developer Mode in the Windows Settings
  app](https://docs.microsoft.com/en-us/windows/uwp/get-started/enable-your-device-for-development)
  to locally install and run Windows Terminal
-* You must have [PowerShell 7 or later](https://github.com/PowerShell/PowerShell/releases/latest) installed
-* You must have the [Windows 11 (10.0.22000.0)
-  SDK](https://developer.microsoft.com/en-us/windows/downloads/windows-sdk/)
+* You must have the [Windows 10 1903
+  SDK](https://developer.microsoft.com/en-us/windows/downloads/windows-10-sdk)
  installed
 * You must have at least [VS
  2019](https://visualstudio.microsoft.com/downloads/) installed
@@ -336,9 +335,7 @@ Solution Explorer) and go to properties. In the Debug menu, change "Application
 process" and "Background task process" to "Native Only".

 You should then be able to build & debug the Terminal project by hitting
-<kbd>F5</kbd>. Make sure to select either the "x64" or the "x86" platform - the
-Terminal doesn't build for "Any Cpu" (because the Terminal is a C++ application,
-not a C# one).
+<kbd>F5</kbd>.

 > 👉 You will _not_ be able to launch the Terminal directly by running the
 > WindowsTerminal.exe. For more details on why, see
--- a/Scratch.sln
+++ b/Scratch.sln
@@ -1,221 +0,0 @@
-
-Microsoft Visual Studio Solution File, Format Version 12.00
-# Visual Studio Version 16
-VisualStudioVersion = 16.0.31205.134
-MinimumVisualStudioVersion = 10.0.40219.1
-Project("{C7167F0D-BC9F-4E6E-AFE1-012C56B48DB5}") = "Package", "scratch\ScratchIslandApp\Package\Package.wapproj", "{CF31505E-3BAE-4C0A-81D7-F1EB279F40BB}"
-EndProject
-Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "SampleAppLib", "scratch\ScratchIslandApp\SampleApp\SampleAppLib.vcxproj", "{A4394404-37F7-41C1-802B-49788D3720E3}"
-EndProject
-Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "SampleApp", "scratch\ScratchIslandApp\SampleApp\dll\SampleApp.vcxproj", "{26C51792-41A3-4FE0-AB5E-8B69D557BF91}"
-	ProjectSection(ProjectDependencies) = postProject
-		{A4394404-37F7-41C1-802B-49788D3720E3} = {A4394404-37F7-41C1-802B-49788D3720E3}
-	EndProjectSection
-EndProject
-Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "WindowExe", "scratch\ScratchIslandApp\WindowExe\WindowExe.vcxproj", "{B4427499-9FDE-4208-B456-5BC580637633}"
-	ProjectSection(ProjectDependencies) = postProject
-		{26C51792-41A3-4FE0-AB5E-8B69D557BF91} = {26C51792-41A3-4FE0-AB5E-8B69D557BF91}
-	EndProjectSection
-EndProject
-Project("{2150E333-8FDC-42A3-9474-1A3956D46DE8}") = "Common Props", "Common Props", "{53DD5520-E64C-4C06-B472-7CE62CA539C9}"
-	ProjectSection(SolutionItems) = preProject
-		src\common.build.post.props = src\common.build.post.props
-		src\common.build.pre.props = src\common.build.pre.props
-		src\common.build.tests.props = src\common.build.tests.props
-		common.openconsole.props = common.openconsole.props
-		src\cppwinrt.build.post.props = src\cppwinrt.build.post.props
-		src\cppwinrt.build.pre.props = src\cppwinrt.build.pre.props
-		src\wap-common.build.post.props = src\wap-common.build.post.props
-		src\wap-common.build.pre.props = src\wap-common.build.pre.props
-	EndProjectSection
-EndProject
-Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "fmt", "src\dep\fmt\fmt.vcxproj", "{6BAE5851-50D5-4934-8D5E-30361A8A40F3}"
-EndProject
-Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "Types", "src\types\lib\types.vcxproj", "{18D09A24-8240-42D6-8CB6-236EEE820263}"
-EndProject
-Project("{2150E333-8FDC-42A3-9474-1A3956D46DE8}") = "dependencies", "dependencies", "{75AC9360-76FD-4ABC-AFEC-EF342BD2B3E9}"
-EndProject
-Global
-	GlobalSection(SolutionConfigurationPlatforms) = preSolution
-		AuditMode|ARM64 = AuditMode|ARM64
-		AuditMode|x64 = AuditMode|x64
-		AuditMode|x86 = AuditMode|x86
-		Debug|ARM64 = Debug|ARM64
-		Debug|x64 = Debug|x64
-		Debug|x86 = Debug|x86
-		Fuzzing|ARM64 = Fuzzing|ARM64
-		Fuzzing|x64 = Fuzzing|x64
-		Fuzzing|x86 = Fuzzing|x86
-		Release|ARM64 = Release|ARM64
-		Release|x64 = Release|x64
-		Release|x86 = Release|x86
-	EndGlobalSection
-	GlobalSection(ProjectConfigurationPlatforms) = postSolution
-		{CF31505E-3BAE-4C0A-81D7-F1EB279F40BB}.AuditMode|ARM64.ActiveCfg = Debug|ARM64
-		{CF31505E-3BAE-4C0A-81D7-F1EB279F40BB}.AuditMode|ARM64.Build.0 = Debug|ARM64
-		{CF31505E-3BAE-4C0A-81D7-F1EB279F40BB}.AuditMode|ARM64.Deploy.0 = Debug|ARM64
-		{CF31505E-3BAE-4C0A-81D7-F1EB279F40BB}.AuditMode|x64.ActiveCfg = Debug|x64
-		{CF31505E-3BAE-4C0A-81D7-F1EB279F40BB}.AuditMode|x64.Build.0 = Debug|x64
-		{CF31505E-3BAE-4C0A-81D7-F1EB279F40BB}.AuditMode|x64.Deploy.0 = Debug|x64
-		{CF31505E-3BAE-4C0A-81D7-F1EB279F40BB}.AuditMode|x86.ActiveCfg = Debug|x86
-		{CF31505E-3BAE-4C0A-81D7-F1EB279F40BB}.AuditMode|x86.Build.0 = Debug|x86
-		{CF31505E-3BAE-4C0A-81D7-F1EB279F40BB}.AuditMode|x86.Deploy.0 = Debug|x86
-		{CF31505E-3BAE-4C0A-81D7-F1EB279F40BB}.Debug|ARM64.ActiveCfg = Debug|ARM64
-		{CF31505E-3BAE-4C0A-81D7-F1EB279F40BB}.Debug|ARM64.Build.0 = Debug|ARM64
-		{CF31505E-3BAE-4C0A-81D7-F1EB279F40BB}.Debug|ARM64.Deploy.0 = Debug|ARM64
-		{CF31505E-3BAE-4C0A-81D7-F1EB279F40BB}.Debug|x64.ActiveCfg = Debug|x64
-		{CF31505E-3BAE-4C0A-81D7-F1EB279F40BB}.Debug|x64.Build.0 = Debug|x64
-		{CF31505E-3BAE-4C0A-81D7-F1EB279F40BB}.Debug|x64.Deploy.0 = Debug|x64
-		{CF31505E-3BAE-4C0A-81D7-F1EB279F40BB}.Debug|x86.ActiveCfg = Debug|x86
-		{CF31505E-3BAE-4C0A-81D7-F1EB279F40BB}.Debug|x86.Build.0 = Debug|x86
-		{CF31505E-3BAE-4C0A-81D7-F1EB279F40BB}.Debug|x86.Deploy.0 = Debug|x86
-		{CF31505E-3BAE-4C0A-81D7-F1EB279F40BB}.Fuzzing|ARM64.ActiveCfg = Debug|ARM64
-		{CF31505E-3BAE-4C0A-81D7-F1EB279F40BB}.Fuzzing|ARM64.Build.0 = Debug|ARM64
-		{CF31505E-3BAE-4C0A-81D7-F1EB279F40BB}.Fuzzing|ARM64.Deploy.0 = Debug|ARM64
-		{CF31505E-3BAE-4C0A-81D7-F1EB279F40BB}.Fuzzing|x64.ActiveCfg = Debug|x64
-		{CF31505E-3BAE-4C0A-81D7-F1EB279F40BB}.Fuzzing|x64.Build.0 = Debug|x64
-		{CF31505E-3BAE-4C0A-81D7-F1EB279F40BB}.Fuzzing|x64.Deploy.0 = Debug|x64
-		{CF31505E-3BAE-4C0A-81D7-F1EB279F40BB}.Fuzzing|x86.ActiveCfg = Debug|x86
-		{CF31505E-3BAE-4C0A-81D7-F1EB279F40BB}.Fuzzing|x86.Build.0 = Debug|x86
-		{CF31505E-3BAE-4C0A-81D7-F1EB279F40BB}.Fuzzing|x86.Deploy.0 = Debug|x86
-		{CF31505E-3BAE-4C0A-81D7-F1EB279F40BB}.Release|ARM64.ActiveCfg = Release|ARM64
-		{CF31505E-3BAE-4C0A-81D7-F1EB279F40BB}.Release|ARM64.Build.0 = Release|ARM64
-		{CF31505E-3BAE-4C0A-81D7-F1EB279F40BB}.Release|ARM64.Deploy.0 = Release|ARM64
-		{CF31505E-3BAE-4C0A-81D7-F1EB279F40BB}.Release|x64.ActiveCfg = Release|x64
-		{CF31505E-3BAE-4C0A-81D7-F1EB279F40BB}.Release|x64.Build.0 = Release|x64
-		{CF31505E-3BAE-4C0A-81D7-F1EB279F40BB}.Release|x64.Deploy.0 = Release|x64
-		{CF31505E-3BAE-4C0A-81D7-F1EB279F40BB}.Release|x86.ActiveCfg = Release|x86
-		{CF31505E-3BAE-4C0A-81D7-F1EB279F40BB}.Release|x86.Build.0 = Release|x86
-		{CF31505E-3BAE-4C0A-81D7-F1EB279F40BB}.Release|x86.Deploy.0 = Release|x86
-		{A4394404-37F7-41C1-802B-49788D3720E3}.AuditMode|ARM64.ActiveCfg = AuditMode|ARM64
-		{A4394404-37F7-41C1-802B-49788D3720E3}.AuditMode|ARM64.Build.0 = AuditMode|ARM64
-		{A4394404-37F7-41C1-802B-49788D3720E3}.AuditMode|x64.ActiveCfg = AuditMode|x64
-		{A4394404-37F7-41C1-802B-49788D3720E3}.AuditMode|x64.Build.0 = AuditMode|x64
-		{A4394404-37F7-41C1-802B-49788D3720E3}.AuditMode|x86.ActiveCfg = AuditMode|Win32
-		{A4394404-37F7-41C1-802B-49788D3720E3}.AuditMode|x86.Build.0 = AuditMode|Win32
-		{A4394404-37F7-41C1-802B-49788D3720E3}.Debug|ARM64.ActiveCfg = Debug|ARM64
-		{A4394404-37F7-41C1-802B-49788D3720E3}.Debug|ARM64.Build.0 = Debug|ARM64
-		{A4394404-37F7-41C1-802B-49788D3720E3}.Debug|x64.ActiveCfg = Debug|x64
-		{A4394404-37F7-41C1-802B-49788D3720E3}.Debug|x64.Build.0 = Debug|x64
-		{A4394404-37F7-41C1-802B-49788D3720E3}.Debug|x86.ActiveCfg = Debug|Win32
-		{A4394404-37F7-41C1-802B-49788D3720E3}.Debug|x86.Build.0 = Debug|Win32
-		{A4394404-37F7-41C1-802B-49788D3720E3}.Fuzzing|ARM64.ActiveCfg = Fuzzing|ARM64
-		{A4394404-37F7-41C1-802B-49788D3720E3}.Fuzzing|ARM64.Build.0 = Fuzzing|ARM64
-		{A4394404-37F7-41C1-802B-49788D3720E3}.Fuzzing|x64.ActiveCfg = Fuzzing|x64
-		{A4394404-37F7-41C1-802B-49788D3720E3}.Fuzzing|x64.Build.0 = Fuzzing|x64
-		{A4394404-37F7-41C1-802B-49788D3720E3}.Fuzzing|x86.ActiveCfg = Fuzzing|Win32
-		{A4394404-37F7-41C1-802B-49788D3720E3}.Fuzzing|x86.Build.0 = Fuzzing|Win32
-		{A4394404-37F7-41C1-802B-49788D3720E3}.Release|ARM64.ActiveCfg = Release|ARM64
-		{A4394404-37F7-41C1-802B-49788D3720E3}.Release|ARM64.Build.0 = Release|ARM64
-		{A4394404-37F7-41C1-802B-49788D3720E3}.Release|x64.ActiveCfg = Release|x64
-		{A4394404-37F7-41C1-802B-49788D3720E3}.Release|x64.Build.0 = Release|x64
-		{A4394404-37F7-41C1-802B-49788D3720E3}.Release|x86.ActiveCfg = Release|Win32
-		{A4394404-37F7-41C1-802B-49788D3720E3}.Release|x86.Build.0 = Release|Win32
-		{26C51792-41A3-4FE0-AB5E-8B69D557BF91}.AuditMode|ARM64.ActiveCfg = AuditMode|ARM64
-		{26C51792-41A3-4FE0-AB5E-8B69D557BF91}.AuditMode|ARM64.Build.0 = AuditMode|ARM64
-		{26C51792-41A3-4FE0-AB5E-8B69D557BF91}.AuditMode|x64.ActiveCfg = AuditMode|x64
-		{26C51792-41A3-4FE0-AB5E-8B69D557BF91}.AuditMode|x64.Build.0 = AuditMode|x64
-		{26C51792-41A3-4FE0-AB5E-8B69D557BF91}.AuditMode|x86.ActiveCfg = AuditMode|Win32
-		{26C51792-41A3-4FE0-AB5E-8B69D557BF91}.AuditMode|x86.Build.0 = AuditMode|Win32
-		{26C51792-41A3-4FE0-AB5E-8B69D557BF91}.Debug|ARM64.ActiveCfg = Debug|ARM64
-		{26C51792-41A3-4FE0-AB5E-8B69D557BF91}.Debug|ARM64.Build.0 = Debug|ARM64
-		{26C51792-41A3-4FE0-AB5E-8B69D557BF91}.Debug|x64.ActiveCfg = Debug|x64
-		{26C51792-41A3-4FE0-AB5E-8B69D557BF91}.Debug|x64.Build.0 = Debug|x64
-		{26C51792-41A3-4FE0-AB5E-8B69D557BF91}.Debug|x86.ActiveCfg = Debug|Win32
-		{26C51792-41A3-4FE0-AB5E-8B69D557BF91}.Debug|x86.Build.0 = Debug|Win32
-		{26C51792-41A3-4FE0-AB5E-8B69D557BF91}.Fuzzing|ARM64.ActiveCfg = Fuzzing|ARM64
-		{26C51792-41A3-4FE0-AB5E-8B69D557BF91}.Fuzzing|ARM64.Build.0 = Fuzzing|ARM64
-		{26C51792-41A3-4FE0-AB5E-8B69D557BF91}.Fuzzing|x64.ActiveCfg = Fuzzing|x64
-		{26C51792-41A3-4FE0-AB5E-8B69D557BF91}.Fuzzing|x64.Build.0 = Fuzzing|x64
-		{26C51792-41A3-4FE0-AB5E-8B69D557BF91}.Fuzzing|x86.ActiveCfg = Fuzzing|Win32
-		{26C51792-41A3-4FE0-AB5E-8B69D557BF91}.Fuzzing|x86.Build.0 = Fuzzing|Win32
-		{26C51792-41A3-4FE0-AB5E-8B69D557BF91}.Release|ARM64.ActiveCfg = Release|ARM64
-		{26C51792-41A3-4FE0-AB5E-8B69D557BF91}.Release|ARM64.Build.0 = Release|ARM64
-		{26C51792-41A3-4FE0-AB5E-8B69D557BF91}.Release|x64.ActiveCfg = Release|x64
-		{26C51792-41A3-4FE0-AB5E-8B69D557BF91}.Release|x64.Build.0 = Release|x64
-		{26C51792-41A3-4FE0-AB5E-8B69D557BF91}.Release|x86.ActiveCfg = Release|Win32
-		{26C51792-41A3-4FE0-AB5E-8B69D557BF91}.Release|x86.Build.0 = Release|Win32
-		{B4427499-9FDE-4208-B456-5BC580637633}.AuditMode|ARM64.ActiveCfg = AuditMode|ARM64
-		{B4427499-9FDE-4208-B456-5BC580637633}.AuditMode|ARM64.Build.0 = AuditMode|ARM64
-		{B4427499-9FDE-4208-B456-5BC580637633}.AuditMode|x64.ActiveCfg = AuditMode|x64
-		{B4427499-9FDE-4208-B456-5BC580637633}.AuditMode|x64.Build.0 = AuditMode|x64
-		{B4427499-9FDE-4208-B456-5BC580637633}.AuditMode|x86.ActiveCfg = AuditMode|Win32
-		{B4427499-9FDE-4208-B456-5BC580637633}.AuditMode|x86.Build.0 = AuditMode|Win32
-		{B4427499-9FDE-4208-B456-5BC580637633}.Debug|ARM64.ActiveCfg = Debug|ARM64
-		{B4427499-9FDE-4208-B456-5BC580637633}.Debug|ARM64.Build.0 = Debug|ARM64
-		{B4427499-9FDE-4208-B456-5BC580637633}.Debug|x64.ActiveCfg = Debug|x64
-		{B4427499-9FDE-4208-B456-5BC580637633}.Debug|x64.Build.0 = Debug|x64
-		{B4427499-9FDE-4208-B456-5BC580637633}.Debug|x86.ActiveCfg = Debug|Win32
-		{B4427499-9FDE-4208-B456-5BC580637633}.Debug|x86.Build.0 = Debug|Win32
-		{B4427499-9FDE-4208-B456-5BC580637633}.Fuzzing|ARM64.ActiveCfg = Fuzzing|ARM64
-		{B4427499-9FDE-4208-B456-5BC580637633}.Fuzzing|ARM64.Build.0 = Fuzzing|ARM64
-		{B4427499-9FDE-4208-B456-5BC580637633}.Fuzzing|x64.ActiveCfg = Fuzzing|x64
-		{B4427499-9FDE-4208-B456-5BC580637633}.Fuzzing|x64.Build.0 = Fuzzing|x64
-		{B4427499-9FDE-4208-B456-5BC580637633}.Fuzzing|x86.ActiveCfg = Fuzzing|Win32
-		{B4427499-9FDE-4208-B456-5BC580637633}.Fuzzing|x86.Build.0 = Fuzzing|Win32
-		{B4427499-9FDE-4208-B456-5BC580637633}.Release|ARM64.ActiveCfg = Release|ARM64
-		{B4427499-9FDE-4208-B456-5BC580637633}.Release|ARM64.Build.0 = Release|ARM64
-		{B4427499-9FDE-4208-B456-5BC580637633}.Release|x64.ActiveCfg = Release|x64
-		{B4427499-9FDE-4208-B456-5BC580637633}.Release|x64.Build.0 = Release|x64
-		{B4427499-9FDE-4208-B456-5BC580637633}.Release|x86.ActiveCfg = Release|Win32
-		{B4427499-9FDE-4208-B456-5BC580637633}.Release|x86.Build.0 = Release|Win32
-		{6BAE5851-50D5-4934-8D5E-30361A8A40F3}.AuditMode|ARM64.ActiveCfg = AuditMode|ARM64
-		{6BAE5851-50D5-4934-8D5E-30361A8A40F3}.AuditMode|ARM64.Build.0 = AuditMode|ARM64
-		{6BAE5851-50D5-4934-8D5E-30361A8A40F3}.AuditMode|x64.ActiveCfg = AuditMode|x64
-		{6BAE5851-50D5-4934-8D5E-30361A8A40F3}.AuditMode|x64.Build.0 = AuditMode|x64
-		{6BAE5851-50D5-4934-8D5E-30361A8A40F3}.AuditMode|x86.ActiveCfg = AuditMode|Win32
-		{6BAE5851-50D5-4934-8D5E-30361A8A40F3}.AuditMode|x86.Build.0 = AuditMode|Win32
-		{6BAE5851-50D5-4934-8D5E-30361A8A40F3}.Debug|ARM64.ActiveCfg = Debug|ARM64
-		{6BAE5851-50D5-4934-8D5E-30361A8A40F3}.Debug|ARM64.Build.0 = Debug|ARM64
-		{6BAE5851-50D5-4934-8D5E-30361A8A40F3}.Debug|x64.ActiveCfg = Debug|x64
-		{6BAE5851-50D5-4934-8D5E-30361A8A40F3}.Debug|x64.Build.0 = Debug|x64
-		{6BAE5851-50D5-4934-8D5E-30361A8A40F3}.Debug|x86.ActiveCfg = Debug|Win32
-		{6BAE5851-50D5-4934-8D5E-30361A8A40F3}.Debug|x86.Build.0 = Debug|Win32
-		{6BAE5851-50D5-4934-8D5E-30361A8A40F3}.Fuzzing|ARM64.ActiveCfg = Fuzzing|ARM64
-		{6BAE5851-50D5-4934-8D5E-30361A8A40F3}.Fuzzing|ARM64.Build.0 = Fuzzing|ARM64
-		{6BAE5851-50D5-4934-8D5E-30361A8A40F3}.Fuzzing|x64.ActiveCfg = Fuzzing|x64
-		{6BAE5851-50D5-4934-8D5E-30361A8A40F3}.Fuzzing|x64.Build.0 = Fuzzing|x64
-		{6BAE5851-50D5-4934-8D5E-30361A8A40F3}.Fuzzing|x86.ActiveCfg = Fuzzing|Win32
-		{6BAE5851-50D5-4934-8D5E-30361A8A40F3}.Fuzzing|x86.Build.0 = Fuzzing|Win32
-		{6BAE5851-50D5-4934-8D5E-30361A8A40F3}.Release|ARM64.ActiveCfg = Release|ARM64
-		{6BAE5851-50D5-4934-8D5E-30361A8A40F3}.Release|ARM64.Build.0 = Release|ARM64
-		{6BAE5851-50D5-4934-8D5E-30361A8A40F3}.Release|x64.ActiveCfg = Release|x64
-		{6BAE5851-50D5-4934-8D5E-30361A8A40F3}.Release|x64.Build.0 = Release|x64
-		{6BAE5851-50D5-4934-8D5E-30361A8A40F3}.Release|x86.ActiveCfg = Release|Win32
-		{6BAE5851-50D5-4934-8D5E-30361A8A40F3}.Release|x86.Build.0 = Release|Win32
-		{18D09A24-8240-42D6-8CB6-236EEE820263}.AuditMode|ARM64.ActiveCfg = AuditMode|ARM64
-		{18D09A24-8240-42D6-8CB6-236EEE820263}.AuditMode|ARM64.Build.0 = AuditMode|ARM64
-		{18D09A24-8240-42D6-8CB6-236EEE820263}.AuditMode|x64.ActiveCfg = AuditMode|x64
-		{18D09A24-8240-42D6-8CB6-236EEE820263}.AuditMode|x64.Build.0 = AuditMode|x64
-		{18D09A24-8240-42D6-8CB6-236EEE820263}.AuditMode|x86.ActiveCfg = AuditMode|Win32
-		{18D09A24-8240-42D6-8CB6-236EEE820263}.AuditMode|x86.Build.0 = AuditMode|Win32
-		{18D09A24-8240-42D6-8CB6-236EEE820263}.Debug|ARM64.ActiveCfg = Debug|ARM64
-		{18D09A24-8240-42D6-8CB6-236EEE820263}.Debug|ARM64.Build.0 = Debug|ARM64
-		{18D09A24-8240-42D6-8CB6-236EEE820263}.Debug|x64.ActiveCfg = Debug|x64
-		{18D09A24-8240-42D6-8CB6-236EEE820263}.Debug|x64.Build.0 = Debug|x64
-		{18D09A24-8240-42D6-8CB6-236EEE820263}.Debug|x86.ActiveCfg = Debug|Win32
-		{18D09A24-8240-42D6-8CB6-236EEE820263}.Debug|x86.Build.0 = Debug|Win32
-		{18D09A24-8240-42D6-8CB6-236EEE820263}.Fuzzing|ARM64.ActiveCfg = Fuzzing|ARM64
-		{18D09A24-8240-42D6-8CB6-236EEE820263}.Fuzzing|ARM64.Build.0 = Fuzzing|ARM64
-		{18D09A24-8240-42D6-8CB6-236EEE820263}.Fuzzing|x64.ActiveCfg = Fuzzing|x64
-		{18D09A24-8240-42D6-8CB6-236EEE820263}.Fuzzing|x64.Build.0 = Fuzzing|x64
-		{18D09A24-8240-42D6-8CB6-236EEE820263}.Fuzzing|x86.ActiveCfg = Fuzzing|Win32
-		{18D09A24-8240-42D6-8CB6-236EEE820263}.Fuzzing|x86.Build.0 = Fuzzing|Win32
-		{18D09A24-8240-42D6-8CB6-236EEE820263}.Release|ARM64.ActiveCfg = Release|ARM64
-		{18D09A24-8240-42D6-8CB6-236EEE820263}.Release|ARM64.Build.0 = Release|ARM64
-		{18D09A24-8240-42D6-8CB6-236EEE820263}.Release|x64.ActiveCfg = Release|x64
-		{18D09A24-8240-42D6-8CB6-236EEE820263}.Release|x64.Build.0 = Release|x64
-		{18D09A24-8240-42D6-8CB6-236EEE820263}.Release|x86.ActiveCfg = Release|Win32
-		{18D09A24-8240-42D6-8CB6-236EEE820263}.Release|x86.Build.0 = Release|Win32
-	EndGlobalSection
-	GlobalSection(SolutionProperties) = preSolution
-		HideSolutionNode = FALSE
-	EndGlobalSection
-	GlobalSection(NestedProjects) = preSolution
-		{6BAE5851-50D5-4934-8D5E-30361A8A40F3} = {75AC9360-76FD-4ABC-AFEC-EF342BD2B3E9}
-		{18D09A24-8240-42D6-8CB6-236EEE820263} = {75AC9360-76FD-4ABC-AFEC-EF342BD2B3E9}
-	EndGlobalSection
-	GlobalSection(ExtensibilityGlobals) = postSolution
-		SolutionGuid = {05EAE315-9188-4D7B-B889-7D5F480A8915}
-	EndGlobalSection
-EndGlobal
--- a/build/Fuzz/notifications-ado.json
+++ b/build/Fuzz/notifications-ado.json
@@ -1,34 +0,0 @@
-{
-  "config": {
-    "base_url": "https://dev.azure.com/microsoft/os",
-    "auth_token": "INSERT_PAT_HERE",
-    "project": "OpenConsole",
-    "type": "Bug",
-    "unique_fields": [
-      "Microsoft.VSTS.Common.CustomString03"
-    ],
-    "comment": "<a href='{{ input_url }}'>This input</a> caused the <a href='{{ target_url }}'>fuzz target</a> {{ report.executable }} to crash. The faulting input SHA256 hash is {{ report.input_sha256 }} <br>",
-    "ado_fields": {
-      "System.AssignedTo": "INSERT_ASSIGNED_HERE",
-      "System.Tags": "OneFuzz",
-      "System.AreaPath": "OS\\WDX\\DXP\\WinDev\\Terminal",
-      "OSG.Watson.Telemetry14DaysInMarketHits": "1",
-      "System.IterationPath": "OS\\Future",
-      "Microsoft.VSTS.Common.CustomString01": "{{ job.project }}",
-      "Microsoft.VSTS.Common.CustomString02": "{{ job.name }}",
-      "Microsoft.VSTS.Common.CustomString03": "{{ report.minimized_stack_function_lines_sha256}}",
-      "System.Title": "[Fuzzing] - {{ report.crash_site }}",
-      "Microsoft.VSTS.CMMI.HowFound": "Security: Fuzzing",
-      "OSG.SecurityImpact": "Security Triage Requested",
-      "OSG.SDLSeverity": "Moderate",
-      "Microsoft.VSTS.TCM.ReproSteps": "The fuzzing target ({{ job.project }} {{ job.name }} {{ job.build }}) reported a crash. <br> {%if report.asan_log %} AddressSanitizer reported the following details: <br> <pre> {{ report.asan_log }} </pre> {% else %} Faulting call stack: <ul> {% for item in report.call_stack %} <li> {{ item }} </li> {% endfor %} </ul> <br> {% endif %} You can reproduce the issue remotely in OneFuzz by running the following command: <pre> {{ repro_cmd }} </pre>"
-    },
-    "on_duplicate": {
-      "set_state": {"Resolved": "Active", "Closed": "Active"},
-      "ado_fields": {
-        "System.IterationPath": "OS\\Future"
-      },
-      "increment": ["OSG.Watson.Telemetry14DaysInMarketHits"]
-    }
-  }
-}
--- a/build/Helix/AzurePipelinesHelperScripts.ps1
+++ b/build/Helix/AzurePipelinesHelperScripts.ps1
@@ -29,147 +29,4 @@ function GetQueryTestRunsUri
    $baseUri = GetAzureDevOpsBaseUri -CollectionUri $CollectionUri -TeamProject $TeamProject
    $queryUri = "$baseUri/_apis/test/runs?buildUri=$BuildUri$includeRunDetailsParameter&api-version=5.0"
    return $queryUri
-}
-
-function Get-HelixJobTypeFromTestRun
-{
-    Param ($testRun)
-
-    $testRunSingleResultUri = "$($testRun.url)/results?`$top=1&`$skip=0&api-version=5.1"
-    $singleTestResult = Invoke-RestMethod -Uri $testRunSingleResultUri -Method Get -Headers $azureDevOpsRestApiHeaders
-    $count = $singleTestResult.value.Length
-    if($count -eq 0)
-    {
-        # If the count is 0, then results have not yet been reported for this run.
-        # We only care about completed runs with results, so it is ok to just return 'UNKNOWN' for this run.
-        return "UNKNOWN"
-    }
-    else
-    {
-        $info = ConvertFrom-Json $singleTestResult.value.comment
-        $helixJobId = $info.HelixJobId
-        $job = Invoke-RestMethodWithRetries "https://helix.dot.net/api/2019-06-17/jobs/${helixJobId}?access_token=${HelixAccessToken}"
-        return $job.Type
-    }
-}
-
-function Append-HelixAccessTokenToUrl
-{
-    Param ([string]$url, [string]$token)
-    if($url.Contains("?"))
-    {
-        $url = "$($url)&access_token=$($token)"
-    }
-    else
-    {
-        $url = "$($url)?access_token=$($token)"
-    }
-    return $url
-}
-
-
-# The Helix Rest api is sometimes unreliable. So we call these apis with retry logic. 
-# Note: The Azure DevOps apis are stable and do not need to be called with this retry logic.
-$helixApiRetries = 0
-$helixApiRetriesMax = 10 
-
-function Download-StringWithRetries
-{
-    Param ([string]$fileName, [string]$url)
-
-    $result = ""
-    $done = $false
-
-    while(!($done))
-    {
-        try
-        {
-            Write-Host "Downloading $fileName"
-            $result = (New-Object System.Net.WebClient).DownloadString($url)
-            $done = $true
-        }
-        catch
-        {
-            Write-Host "Failed to download $fileName $($PSItem.Exception)"
-
-            $helixApiRetries = $helixApiRetries + 1
-            if($helixApiRetries -lt $helixApiRetriesMax)
-            {
-                Write-Host "Sleep and retry download of $fileName"
-                Start-Sleep 60
-            }
-            else
-            {
-                throw "Failed to download $fileName"
-            }
-        }
-    }
-
-    return $result
-}
-
-function Invoke-RestMethodWithRetries
-{
-    Param ([string]$url,$Headers)
-
-    $result = @()
-    $done = $false
-
-    while(!($done))
-    {
-        try
-        {
-            $result = Invoke-RestMethod -Uri $url -Method Get -Headers $Headers
-            $done = $true
-        }
-        catch
-        {
-            Write-Host "Failed to invoke Rest method $($PSItem.Exception)"
-
-            $helixApiRetries = $helixApiRetries + 1
-            if($helixApiRetries -lt $helixApiRetriesMax)
-            {
-                Write-Host "Sleep and retry invoke"
-                Start-Sleep 60
-            }
-            else
-            {
-                throw "Failed to invoke Rest method"
-            }
-        }
-    }
-
-    return $result
-}
-
-function Download-FileWithRetries
-{
-    Param ([string]$fileurl, [string]$destination)
-
-    $done = $false
-
-    while(!($done))
-    {
-        try
-        {
-            Write-Host "Downloading $destination"
-            $webClient.DownloadFile($fileurl, $destination)
-            $done = $true
-        }
-        catch
-        {
-            Write-Host "Failed to download $destination $($PSItem.Exception)"
-
-            $helixApiRetries = $helixApiRetries + 1
-            if($helixApiRetries -lt $helixApiRetriesMax)
-            {
-                Write-Host "Sleep and retry download of $destination"
-                Start-Sleep 60
-            }
-            else
-            {
-                throw "Failed to download $destination"
-            }
-        }
-    }
 }
--- a/build/Helix/EnsureMachineState.ps1
+++ b/build/Helix/EnsureMachineState.ps1
@@ -1,4 +1,4 @@
-$scriptDirectory = $script:MyInvocation.MyCommand.Path | Split-Path -Parent
+$scriptDirectory = $script:MyInvocation.MyCommand.Path | Split-Path -Parent

 # List all processes to aid debugging:
 Write-Host "All processes running:"
--- a/build/Helix/HelixTestHelpers.cs
+++ b/build/Helix/HelixTestHelpers.cs
@@ -1,4 +1,4 @@
-using System;
+using System;
 using System.Collections.Generic;
 using System.IO;
 using System.Linq;
--- a/build/Helix/OutputTestResults.ps1
+++ b/build/Helix/OutputTestResults.ps1
@@ -21,7 +21,7 @@ Write-Host "Checking test results..."
 $queryUri = GetQueryTestRunsUri -CollectionUri $CollectionUri -TeamProject $TeamProject -BuildUri $BuildUri -IncludeRunDetails
 Write-Host "queryUri = $queryUri"

-$testRuns = Invoke-RestMethodWithRetries $queryUri -Headers $azureDevOpsRestApiHeaders
+$testRuns = Invoke-RestMethod -Uri $queryUri -Method Get -Headers $azureDevOpsRestApiHeaders
 [System.Collections.Generic.List[string]]$failingTests = @()
 [System.Collections.Generic.List[string]]$unreliableTests = @()
 [System.Collections.Generic.List[string]]$unexpectedResultTest = @()
@@ -31,7 +31,7 @@ $totalTestsExecutedCount = 0

 # We assume that we only have one testRun with a given name that we care about
 # We only process the last testRun with a given name (based on completedDate)
-# The name of a testRun is set to the Helix queue that it was run on (e.g. windows.10.amd64.client21h1.xaml)
+# The name of a testRun is set to the Helix queue that it was run on (e.g. windows.10.amd64.client19h1.xaml)
 # If we have multiple test runs on the same queue that we care about, we will need to re-visit this logic
 foreach ($testRun in ($testRuns.value | Sort-Object -Property "completedDate" -Descending))
 {
@@ -50,7 +50,7 @@ foreach ($testRun in ($testRuns.value | Sort-Object -Property "completedDate" -D
    $totalTestsExecutedCount += $testRun.totalTests

    $testRunResultsUri = "$($testRun.url)/results?api-version=5.0"
-    $testResults = Invoke-RestMethodWithRetries "$($testRun.url)/results?api-version=5.0" -Headers $azureDevOpsRestApiHeaders
+    $testResults = Invoke-RestMethod -Uri "$($testRun.url)/results?api-version=5.0" -Method Get -Headers $azureDevOpsRestApiHeaders
        
    foreach ($testResult in $testResults.value)
    {
--- a/build/Helix/PrepareHelixPayload.ps1
+++ b/build/Helix/PrepareHelixPayload.ps1
@@ -9,7 +9,7 @@ $payloadDir = "HelixPayload\$Configuration\$Platform"

 $repoDirectory = Join-Path (Split-Path -Parent $script:MyInvocation.MyCommand.Path) "..\..\"
 $nugetPackagesDir = Join-Path (Split-Path -Parent $script:MyInvocation.MyCommand.Path) "packages"
-
+ 
 # Create the payload directory. Remove it if it already exists.
 If(test-path $payloadDir)
 {
@@ -19,13 +19,11 @@ New-Item -ItemType Directory -Force -Path $payloadDir

 # Copy files from nuget packages
 Copy-Item "$nugetPackagesDir\microsoft.windows.apps.test.1.0.181203002\lib\netcoreapp2.1\*.dll" $payloadDir
-Copy-Item "$nugetPackagesDir\Microsoft.Taef.10.60.210621002\build\Binaries\$Platform\*" $payloadDir
-Copy-Item "$nugetPackagesDir\Microsoft.Taef.10.60.210621002\build\Binaries\$Platform\NetFx4.5\*" $payloadDir
+Copy-Item "$nugetPackagesDir\Microsoft.Taef.10.58.210305002\build\Binaries\$Platform\*" $payloadDir
+Copy-Item "$nugetPackagesDir\Microsoft.Taef.10.58.210305002\build\Binaries\$Platform\CoreClr\*" $payloadDir
 New-Item -ItemType Directory -Force -Path "$payloadDir\.NETCoreApp2.1\"
 Copy-Item "$nugetPackagesDir\runtime.win-$Platform.microsoft.netcore.app.2.1.0\runtimes\win-$Platform\lib\netcoreapp2.1\*" "$payloadDir\.NETCoreApp2.1\"
 Copy-Item "$nugetPackagesDir\runtime.win-$Platform.microsoft.netcore.app.2.1.0\runtimes\win-$Platform\native\*" "$payloadDir\.NETCoreApp2.1\"
-New-Item -ItemType Directory -Force -Path "$payloadDir\content\"
-Copy-Item "$nugetPackagesDir\Microsoft.Internal.Windows.Terminal.TestContent.1.0.1\content\*" "$payloadDir\content\"

 function Copy-If-Exists
 {
@@ -54,13 +52,3 @@ Copy-Item "build\helix\HelixTestHelpers.cs" "$payloadDir"
 Copy-Item "build\helix\runtests.cmd" $payloadDir
 Copy-Item "build\helix\InstallTestAppDependencies.ps1" "$payloadDir"
 Copy-Item "build\Helix\EnsureMachineState.ps1" "$payloadDir"
-
-# Copy the APPX package from the 'drop' artifact dir
-Copy-Item "$repoDirectory\Artifacts\$ArtifactName\appx\CascadiaPackage_0.0.1.0_$Platform.msix" $payloadDir\CascadiaPackage.zip
-
-# Rename it to extension of ZIP because Expand-Archive is real sassy on the build machines
-# and refuses to unzip it because of its file extension while on a desktop, it just
-# does the job without complaining.
-
-# Extract the APPX package
-Expand-Archive -LiteralPath $payloadDir\CascadiaPackage.zip -DestinationPath $payloadDir\appx
--- a/build/Helix/ProcessHelixFiles.ps1
+++ b/build/Helix/ProcessHelixFiles.ps1
@@ -9,6 +9,11 @@ Param(

 $helixLinkFile = "$OutputFolder\LinksToHelixTestFiles.html"

+$accessTokenParam = ""
+if($HelixAccessToken)
+{
+    $accessTokenParam = "?access_token=$HelixAccessToken"
+}

 function Generate-File-Links
 {
@@ -20,31 +25,13 @@ function Generate-File-Links
        Out-File -FilePath $helixLinkFile -Append -InputObject "<ul>"
        foreach($file in $files)
        {
-            $url = Append-HelixAccessTokenToUrl $file.Link "{Your-Helix-Access-Token-Here}"
-            Out-File -FilePath $helixLinkFile -Append -InputObject "<li>$($url)</li>"
+            Out-File -FilePath $helixLinkFile -Append -InputObject "<li><a href=$($file.Link)>$($file.Name)</a></li>"
        }
        Out-File -FilePath $helixLinkFile -Append -InputObject "</ul>"
        Out-File -FilePath $helixLinkFile -Append -InputObject "</div>"
    }
 }

-function Append-HelixAccessTokenToUrl
-{
-    Param ([string]$url, [string]$token)
-    if($token)
-    {
-        if($url.Contains("?"))
-        {
-            $url = "$($url)&access_token=$($token)"
-        }
-        else
-        {
-            $url = "$($url)?access_token=$($token)"
-        }
-    }
-    return $url
-}
-
 #Create output directory
 New-Item $OutputFolder -ItemType Directory

@@ -58,71 +45,66 @@ $azureDevOpsRestApiHeaders = @{
 $queryUri = GetQueryTestRunsUri -CollectionUri $CollectionUri -TeamProject $TeamProject -BuildUri $BuildUri -IncludeRunDetails
 Write-Host "queryUri = $queryUri"

-$testRuns = Invoke-RestMethodWithRetries $queryUri -Headers $azureDevOpsRestApiHeaders
+$testRuns = Invoke-RestMethod -Uri $queryUri -Method Get -Headers $azureDevOpsRestApiHeaders
 $webClient = New-Object System.Net.WebClient
 [System.Collections.Generic.List[string]]$workItems = @()

 foreach ($testRun in $testRuns.value)
 {
-    Write-Host "testRunUri = $testRun.url"
-    $testResults = Invoke-RestMethodWithRetries "$($testRun.url)/results?api-version=5.0" -Headers $azureDevOpsRestApiHeaders
+    $testResults = Invoke-RestMethod -Uri "$($testRun.url)/results?api-version=5.0" -Method Get -Headers $azureDevOpsRestApiHeaders
    $isTestRunNameShown = $false

    foreach ($testResult in $testResults.value)
    {
-        $info = ConvertFrom-Json $testResult.comment
-        $helixJobId = $info.HelixJobId
-        $helixWorkItemName = $info.HelixWorkItemName
-
-        $workItem = "$helixJobId-$helixWorkItemName"
-
-        Write-Host "Helix Work Item = $workItem"
-
-        if (-not $workItems.Contains($workItem))
+        if ("comment" -in $testResult)
        {
-            $workItems.Add($workItem)
-            $filesQueryUri = "https://helix.dot.net/api/2019-06-17/jobs/$helixJobId/workitems/$helixWorkItemName/files"
-            $filesQueryUri = Append-HelixAccessTokenToUrl $filesQueryUri $helixAccessToken
-            $files = Invoke-RestMethodWithRetries $filesQueryUri
+            $info = ConvertFrom-Json $testResult.comment
+            $helixJobId = $info.HelixJobId
+            $helixWorkItemName = $info.HelixWorkItemName

-            $screenShots = $files | where { $_.Name.EndsWith(".jpg") }
-            $dumps = $files | where { $_.Name.EndsWith(".dmp") }
-            $pgcFiles = $files | where { $_.Name.EndsWith(".pgc") }
-            if ($screenShots.Count + $dumps.Count + $pgcFiles.Count -gt 0)
+            $workItem = "$helixJobId-$helixWorkItemName"
+
+            if (-not $workItems.Contains($workItem))
            {
-                if(-Not $isTestRunNameShown)
+                $workItems.Add($workItem)
+                $filesQueryUri = "https://helix.dot.net/api/2019-06-17/jobs/$helixJobId/workitems/$helixWorkItemName/files$accessTokenParam"
+                $files = Invoke-RestMethod -Uri $filesQueryUri -Method Get
+
+                $screenShots = $files | where { $_.Name.EndsWith(".jpg") }
+                $dumps = $files | where { $_.Name.EndsWith(".dmp") }
+                $pgcFiles = $files | where { $_.Name.EndsWith(".pgc") }
+                if ($screenShots.Count + $dumps.Count + $pgcFiles.Count -gt 0)
                {
-                    Out-File -FilePath $helixLinkFile -Append -InputObject "<h2>$($testRun.name)</h2>"
-                    $isTestRunNameShown = $true
-                }
-                Out-File -FilePath $helixLinkFile -Append -InputObject "<h3>$helixWorkItemName</h3>"
-                Generate-File-Links $screenShots "Screenshots"
-                Generate-File-Links $dumps "CrashDumps"
-                Generate-File-Links $pgcFiles "PGC files"
-                $misc = $files | where { ($screenShots -NotContains $_) -And ($dumps -NotContains $_) -And ($visualTreeVerificationFiles -NotContains $_) -And ($pgcFiles -NotContains $_) }
-                Generate-File-Links $misc "Misc"
-
-                foreach($pgcFile in $pgcFiles)
-                {
-                    $flavorPath = $testResult.automatedTestName.Split('.')[0]
-                    $archPath = $testResult.automatedTestName.Split('.')[1]
-                    $fileName = $pgcFile.Name
-                    $fullPath = "$OutputFolder\PGO\$flavorPath\$archPath"
-                    $destination = "$fullPath\$fileName"
-
-                    Write-Host "Copying $($pgcFile.Name) to $destination"
-
-                    if (-Not (Test-Path $fullPath))
+                    if(-Not $isTestRunNameShown)
                    {
-                        New-Item $fullPath -ItemType Directory
+                        Out-File -FilePath $helixLinkFile -Append -InputObject "<h2>$($testRun.name)</h2>"
+                        $isTestRunNameShown = $true
                    }
+                    Out-File -FilePath $helixLinkFile -Append -InputObject "<h3>$helixWorkItemName</h3>"
+                    Generate-File-Links $screenShots "Screenshots"
+                    Generate-File-Links $dumps "CrashDumps"
+                    Generate-File-Links $pgcFiles "PGC files"
+                    $misc = $files | where { ($screenShots -NotContains $_) -And ($dumps -NotContains $_) -And ($visualTreeVerificationFiles -NotContains $_) -And ($pgcFiles -NotContains $_) }
+                    Generate-File-Links $misc "Misc"

-                    $link = $pgcFile.Link
+                    foreach($pgcFile in $pgcFiles)
+                    {
+                        $flavorPath = $pgcFile.Name.Split('.')[0]
+                        $archPath = $pgcFile.Name.Split('.')[1]
+                        $fileName = $pgcFile.Name.Remove(0, $flavorPath.length + $archPath.length + 2)
+                        $fullPath = "$OutputFolder\PGO\$flavorPath\$archPath"
+                        $destination = "$fullPath\$fileName"

-                    Write-Host "Downloading $link to $destination"
+                        Write-Host "Copying $($pgcFile.Name) to $destination"

-                    $link = Append-HelixAccessTokenToUrl $link $HelixAccessToken
-                    Download-FileWithRetries $link $destination
+                        if (-Not (Test-Path $fullPath))
+                        {
+                            New-Item $fullPath -ItemType Directory
+                        }
+
+                        $link = "$($pgcFile.Link)$accessTokenParam"
+                        $webClient.DownloadFile($link, $destination)
+                    }
                }
            }
        }
--- a/build/Helix/RunTestsInHelix.proj
+++ b/build/Helix/RunTestsInHelix.proj
@@ -13,8 +13,6 @@
  </ItemGroup>
  
  <!-- These .proj files are generated by the build machine prior to running tests via GenerateTestProjFile.ps1. -->
-  <Import Project="$(ProjFilesPath)\$(Configuration)\$(Platform)\RunTestsInHelix-TerminalAppLocalTests.proj" Condition=" '$(TestSuite)'=='DevTestSuite' " />
-  <Import Project="$(ProjFilesPath)\$(Configuration)\$(Platform)\RunTestsInHelix-SettingsModelLocalTests.proj" Condition=" '$(TestSuite)'=='DevTestSuite' " />
-  <Import Project="$(ProjFilesPath)\$(Configuration)\$(Platform)\RunTestsInHelix-HostTestsUIA.proj" Condition=" '$(TestSuite)'=='DevTestSuite' " />
-  <Import Project="$(ProjFilesPath)\$(Configuration)\$(Platform)\RunTestsInHelix-WindowsTerminalUIATests.proj" Condition=" '$(TestSuite)'=='PgoInstrumentationSuite' " />
+  <Import Project="$(ProjFilesPath)\RunTestsInHelix-TerminalAppLocalTests.proj" Condition=" '$(TestSuite)'=='DevTestSuite' " />
+  <Import Project="$(ProjFilesPath)\RunTestsInHelix-HostTestsUIA.proj" Condition=" '$(TestSuite)'=='DevTestSuite' " />
 </Project>
--- a/build/Helix/UpdateUnreliableTests.ps1
+++ b/build/Helix/UpdateUnreliableTests.ps1
@@ -23,7 +23,7 @@ Write-Host "queryUri = $queryUri"
 # To account for unreliable tests, we'll iterate through all of the tests associated with this build, check to see any tests that were unreliable
 # (denoted by being marked as "skipped"), and if so, we'll instead mark those tests with a warning and enumerate all of the attempted runs
 # with their pass/fail states as well as any relevant error messages for failed attempts.
-$testRuns = Invoke-RestMethodWithRetries $queryUri -Headers $azureDevOpsRestApiHeaders
+$testRuns = Invoke-RestMethod -Uri $queryUri -Method Get -Headers $azureDevOpsRestApiHeaders

 $timesSeenByRunName = @{}
      
@@ -32,10 +32,10 @@ foreach ($testRun in $testRuns.value)
    $testRunResultsUri = "$($testRun.url)/results?api-version=5.0"
        
    Write-Host "Marking test run `"$($testRun.name)`" as in progress so we can change its results to account for unreliable tests."
-    Invoke-RestMethod "$($testRun.url)?api-version=5.0" -Method Patch -Body (ConvertTo-Json @{ "state" = "InProgress" }) -Headers $azureDevOpsRestApiHeaders -ContentType "application/json" | Out-Null
+    Invoke-RestMethod -Uri "$($testRun.url)?api-version=5.0" -Method Patch -Body (ConvertTo-Json @{ "state" = "InProgress" }) -Headers $azureDevOpsRestApiHeaders -ContentType "application/json" | Out-Null

    Write-Host "Retrieving test results..."
-    $testResults = Invoke-RestMethodWithRetries $testRunResultsUri -Headers $azureDevOpsRestApiHeaders
+    $testResults = Invoke-RestMethod -Uri $testRunResultsUri -Method Get -Headers $azureDevOpsRestApiHeaders
        
    foreach ($testResult in $testResults.value)
    {
@@ -54,8 +54,7 @@ foreach ($testRun in $testRuns.value)
            Write-Host "  Test $($testResult.testCaseTitle) was detected as unreliable. Updating..."
            
            # The errorMessage field contains a link to the JSON-encoded rerun result data.
-            $resultsJson = Download-StringWithRetries "Error results" $testResult.errorMessage
-            $rerunResults = ConvertFrom-Json $resultsJson
+            $rerunResults = ConvertFrom-Json (New-Object System.Net.WebClient).DownloadString($testResult.errorMessage)
            [System.Collections.Generic.List[System.Collections.Hashtable]]$rerunDataList = @()
            $attemptCount = 0
            $passCount = 0
--- a/build/Helix/packages.config
+++ b/build/Helix/packages.config
@@ -1,8 +1,7 @@
 <?xml version="1.0" encoding="utf-8"?>
 <packages>
  <package id="MUXCustomBuildTasks" version="1.0.48" targetFramework="native" />
-  <package id="Microsoft.Internal.Windows.Terminal.TestContent" version="1.0.1" />
-  <package id="Microsoft.Taef" version="10.60.210621002" targetFramework="native" />
+  <package id="Microsoft.Taef" version="10.58.210305002" targetFramework="native" />
  <package id="microsoft.windows.apps.test" version="1.0.181203002" targetFramework="native" />
  <package id="runtime.win-x86.microsoft.netcore.app" version="2.1.0" targetFramework="native" />
  <package id="runtime.win-x64.microsoft.netcore.app" version="2.1.0" targetFramework="native" />
--- a/build/Helix/runtests.cmd
+++ b/build/Helix/runtests.cmd
@@ -28,7 +28,7 @@ echo %TIME%
 powershell -ExecutionPolicy Bypass .\InstallTestAppDependencies.ps1
 echo %TIME%

-set testBinaryCandidates=TerminalApp.LocalTests.dll SettingsModel.LocalTests.dll Conhost.UIA.Tests.dll WindowsTerminal.UIA.Tests.dll
+set testBinaryCandidates=TerminalApp.LocalTests.dll SettingsModel.LocalTests.dll Conhost.UIA.Tests.dll
 set testBinaries=
 for %%B in (%testBinaryCandidates%) do (
    if exist %%B (
@@ -46,6 +46,7 @@ move te.wtl te_original.wtl

 copy /y te_original.wtl %HELIX_WORKITEM_UPLOAD_ROOT%
 copy /y WexLogFileOutput\*.jpg %HELIX_WORKITEM_UPLOAD_ROOT%
+for /f "tokens=* delims=" %%a in ('dir /b *.pgc') do ren "%%a" "%testnameprefix%.%%~na.pgc"
 copy /y *.pgc %HELIX_WORKITEM_UPLOAD_ROOT%

 set FailedTestQuery=
--- a/build/config/GitCheckin.json
+++ b/build/config/GitCheckin.json
@@ -1,24 +0,0 @@
-{
-    "Branch": [
-      {
-        "collection": "microsoft",
-        "project": "OS",
-        "repo": "os.2020",
-        "name": "official/rs_wdx_dxp_windev",
-        "workitem": "38106206",
-        "CheckinFiles": [
-          {
-            "source": "WindowsTerminal.app.man",
-            "path": "/redist/mspartners/ipa/WindowsTerminal",
-            "type": "File"
-          }
-        ]
-      }
-    ],
-    "Email": [
-      {
-        "sendTo": "condev",
-        "sendOnErrorOnly": "False"
-      }
-    ]
-  }
--- a/build/config/PolicheckExclusions.xml
+++ b/build/config/PolicheckExclusions.xml
@@ -1,11 +0,0 @@
-<PoliCheckExclusions>
-  <!-- All strings must be UPPER CASE -->
-  <!--Each of these exclusions is a folder name -if \[name]\exists in the file path, it will be skipped -->
-  <Exclusion Type="FolderPathFull">winrt|.git|oss|packages</Exclusion>
-  <!--Each of these exclusions is a folder name -if any folder or file starts with "\[name]", it will be skipped -->
-  <!--<Exclusion Type="FolderPathStart">ABC|XYZ</Exclusion>-->
-  <!--Each of these file types will be completely skipped for the entire scan -->
-  <Exclusion Type="FileType">.PNG|.SVG|.BMP|.ICO</Exclusion>
-  <!--The specified file names will be skipped during the scan regardless which folder they are in -->
-  <!--<Exclusion Type="FileName">ABC.TXT|XYZ.CS</Exclusion>-->
-</PoliCheckExclusions>
--- a/build/config/tsaoptions.json
+++ b/build/config/tsaoptions.json
@@ -1,8 +0,0 @@
-{
-    "instanceUrl": "https://microsoft.visualstudio.com",
-    "projectName": "os",
-    "areaPath": "OS\\WDX\\DXP\\WinDev\\Terminal",
-    "iterationPath": "OS\\Future",
-    "notificationAliases": [ "condev@microsoft.com;" ],
-    "ignoreBranchName": true
-  }
--- a/build/packages.config
+++ b/build/packages.config
@@ -1,8 +1,5 @@
 <?xml version="1.0" encoding="utf-8"?>
 <packages>
  <package id="MUXCustomBuildTasks" version="1.0.48" targetFramework="native" />
-  <package id="Microsoft.Taef" version="10.60.210621002" targetFramework="native" />
-  <package id="Microsoft.Internal.PGO-Helpers.Cpp" version="0.2.34" targetFramework="native" />
-  <!-- This cannot be included in another project that depends on XAML (as it would be a duplicate package ID) -->
-  <package id="Microsoft.UI.Xaml" version="2.7.0" targetFramework="native" />
+  <package id="Microsoft.Taef" version="10.58.210305002" targetFramework="native" />
 </packages>
--- a/build/pgo/PGO.DB.proj
+++ b/build/pgo/PGO.DB.proj
@@ -1,4 +0,0 @@
-<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
-  <Import Project="Terminal.PGO.props" />
-  <Import Project="$(PkgMicrosoft_PGO_Helpers_Cpp)\build\Microsoft.PGO-Helpers.Cpp.targets" />
-</Project>
--- a/build/pgo/Terminal.PGO.DB.nuspec
+++ b/build/pgo/Terminal.PGO.DB.nuspec
@@ -1,16 +0,0 @@
-<?xml version="1.0"?>
-<package xmlns="http://schemas.microsoft.com/packaging/2010/07/nuspec.xsd">
-  <metadata>
-    <id>Microsoft.Internal.Windows.Terminal.PGODatabase</id>
-    <version>0</version>
-    <title>Windows Terminal PGO Database</title>
-    <authors>Microsoft</authors>
-    <owners>Microsoft</owners>
-    <requireLicenseAcceptance>false</requireLicenseAcceptance>
-    <description>Windows Terminal PGO Database</description>
-  </metadata>
-  <files>
-    <!-- The target directories for pgd files need to remain as is.  PGO optimization pass will rely on this exact directory layout. -->
-    <file src="x64\*.pgd" target="tools\x64"/>
-  </files>
-</package>
--- a/build/pgo/Terminal.PGO.props
+++ b/build/pgo/Terminal.PGO.props
@@ -1,51 +0,0 @@
-<Project>
-  <PropertyGroup>
-    <NuGetPackageDirectory>$(MSBuildThisFileDirectory)..\..\packages</NuGetPackageDirectory>
-    <PkgMicrosoft_PGO_Helpers_Cpp>$(NuGetPackageDirectory)\Microsoft.Internal.PGO-Helpers.Cpp.0.2.34</PkgMicrosoft_PGO_Helpers_Cpp>
-  </PropertyGroup>
-
-  <!-- Get version information -->
-  <Import Project="$(MSBuildThisFileDirectory)..\..\custom.props" />
-
-  <PropertyGroup>
-    <!-- Optional, defaults to main.  Name of the branch which will be used for calculating branch point. -->
-    <PGOBranch>main</PGOBranch>
-
-    <!-- Mandatory.  Name of the NuGet package which will contain PGO databases for consumption by build system. -->
-    <PGOPackageName>Microsoft.Internal.Windows.Terminal.PGODatabase</PGOPackageName>
-
-    <!-- Mandatory.  Major version number of the PGO database which should match the version of the product.  This can be hardcoded or obtained from other sources in build system. -->
-    <PGOPackageVersionMajor>$(VersionMajor)</PGOPackageVersionMajor>
-
-    <!-- Mandatory.  Minor version number of the PGO database which should match the version of the product.  This can be hardcoded or obtained from other sources in build system. -->
-    <PGOPackageVersionMinor>$(VersionMinor)</PGOPackageVersionMinor>
-
-    <!-- Mandatory, defaults to 0.  Patch version number of the PGO database which should match the version of the product.  This can be hardcoded or obtained from other sources in build system. -->
-    <PGOPackageVersionPatch>0</PGOPackageVersionPatch>
-    
-    <!-- Optional, defaults to empty.  Prerelease version number of the PGO database which should match the version of the product.  This can be hardcoded or obtained from other sources in build system. -->
-    <PGOPackageVersionPrerelease></PGOPackageVersionPrerelease>
-
-    <!-- Mandatory.  Path to nuget.config file for the project.  Path is relative to where the props file will be. -->
-    <PGONuGetConfigPath>$(MSBuildThisFileDirectory)..\..\nuget.config</PGONuGetConfigPath>
-
-    <!-- Mandatory.  Path to PGO database NuSpec, see section below. -->
-    <PGONuspecPath>$(MSBuildThisFileDirectory)Terminal.PGO.DB.nuspec</PGONuspecPath>
-
-    <!-- Optional, defaults to true.  Should verification result in build failure or error? -->
-    <PGOVerifyFailureTreatedAsError>true</PGOVerifyFailureTreatedAsError>
-
-    <!-- Optional, defaults to $(IntDir)\Nuspec.  Temporary path where PGD files are copied to. -->
-    <PGONuspecBasePath>$(PGDPathForAllArch)</PGONuspecBasePath>
-
-    <!-- Optional, defaults to true.  Specifies whether to use default information for PGD files. -->
-    <PGOUseDefaultPGDFileInfo>true</PGOUseDefaultPGDFileInfo>
-
-    <!-- Copying the PGO runtime brings along a CRT. If we do that under normal circumstances, WAPPROJ will get its grubby hands on it and mess up all the CRT shenanigans we have to pull to make MSIX packages happy. So only pull it in for Instrument builds.-->
-    <PGOCopyRuntime>false</PGOCopyRuntime>
-    <PGOCopyRuntime Condition="'$(PGOBuildMode)' == 'Instrument'">true</PGOCopyRuntime>
-  </PropertyGroup>
-
-  <!-- Import PGO-Helpers -->
-  <Import Project="$(PkgMicrosoft_PGO_Helpers_Cpp)\build\Microsoft.PGO-Helpers.Cpp.props" />
-</Project>
--- a/build/pipelines/ci.yml
+++ b/build/pipelines/ci.yml
@@ -38,7 +38,6 @@ stages:
      - template: ./templates/build-console-audit-job.yml
        parameters:
          platform: x64
-
  - stage: Build_x64
    displayName: Build x64
    dependsOn: []
@@ -62,32 +61,6 @@ stages:
      - template: ./templates/build-console-ci.yml
        parameters:
          platform: ARM64
-
-  - stage: Test_x64
-    displayName: Test x64
-    dependsOn: [Build_x64]
-    condition: succeeded()
-    jobs:
-      - template: ./templates/test-console-ci.yml
-        parameters:
-          platform: x64
-  - stage: Test_x86
-    displayName: Test x86
-    dependsOn: [Build_x86]
-    jobs:
-      - template: ./templates/test-console-ci.yml
-        parameters:
-          platform: x86
-
-  - stage: Helix_x64
-    displayName: Helix x64
-    dependsOn: [Build_x64]
-    condition: and(succeeded(), not(eq(variables['Build.Reason'], 'PullRequest')))
-    jobs:
-      - template: ./templates/console-ci-helix-job.yml
-        parameters:
-          platform: x64
-
  - stage: Scripts
    displayName: Code Health Scripts
    dependsOn: []
--- a/build/pipelines/feature-flag-ci.yml
+++ b/build/pipelines/feature-flag-ci.yml
@@ -1,29 +0,0 @@
-trigger: none
-
-pr:
-  branches:
-    include:
-      - main
-  paths:
-    include:
-      - src/features.xml
-
-variables:
-  - name: runCodesignValidationInjectionBG
-    value: false
-
-parameters:
-  - name: buildBrandings
-    type: object
-    default:
-      - Release
-      - Preview
-      # Dev is built automatically
-      # WindowsInbox does not typically build with VS.
-
-jobs:
-  - ${{ each branding in parameters.buildBrandings }}:
-    - template: ./templates/build-console-ci.yml
-      parameters:
-        platform: x64
-        branding: ${{ branding }}
--- a/build/pipelines/fuzz.yml
+++ b/build/pipelines/fuzz.yml
@@ -1,59 +0,0 @@
-trigger:
-  batch: true
-  branches:
-    include:
-      - main
-  paths:
-    exclude:
-      - docs/*
-      - samples/*
-      - tools/*
-
-pr: none
-
-#     0.0.yyMM.dd##
-#     0.0.1904.0900
-name: 0.0.$(Date:yyMM).$(Date:dd)$(Rev:rr)
-
-stages:
-  - stage: Build_Fuzz_Config
-    displayName: Build Fuzzers
-    dependsOn: []
-    condition: succeeded()
-    jobs:
-    - template: ./templates/build-console-fuzzing.yml
-      parameters:
-        platform: x64
-  - stage: OneFuzz
-    displayName: Submit OneFuzz Job
-    dependsOn: ['Build_Fuzz_Config']
-    condition: succeeded()
-    pool:
-      vmImage: 'ubuntu-latest'
-    variables:
-      artifactName: fuzzingBuildOutput
-    jobs:
-    - job:
-      steps:
-      - task: DownloadBuildArtifacts@0
-        inputs:
-          artifactName: $(artifactName)
-          downloadPath: $(Build.ArtifactStagingDirectory)
-      - task: UsePythonVersion@0
-        inputs:
-          versionSpec: '3.x'
-          addToPath: true
-          architecture: 'x64'
-      - bash: |
-          set -ex
-          pip -q install onefuzz
-          onefuzz config --endpoint $(endpoint) --client_id $(client_id) --authority $(authority) --tenant_domain $(tenant_domain) --client_secret $(client_secret)
-          sed -i s/INSERT_PAT_HERE/$(ado_pat)/ build/Fuzz/notifications-ado.json
-          sed -i s/INSERT_ASSIGNED_HERE/$(ado_assigned_to)/ build/Fuzz/notifications-ado.json
-        displayName: Configure OneFuzz
-      - bash: |
-          onefuzz template libfuzzer basic --colocate_all_tasks --vm_count 1 --target_exe $target_exe_path --notification_config @./build/Fuzz/notifications-ado.json OpenConsole $test_name $(Build.SourceVersion) default
-        displayName: Submit OneFuzz Job
-        env:
-          target_exe_path: $(Build.ArtifactStagingDirectory)/$(artifactName)/Fuzzing/x64/test/OpenConsoleFuzzer.exe
-          test_name: WriteCharsLegacy
--- a/build/pipelines/pgo.yml
+++ b/build/pipelines/pgo.yml
@@ -1,27 +0,0 @@
-trigger: none
-pr: none
-
-variables:
-  - name: runCodesignValidationInjectionBG
-    value: false
-
-#     0.0.yyMM.dd##
-#     0.0.1904.0900
-name: 0.0.$(Date:yyMM).$(Date:dd)$(Rev:rr)
-
-stages:
-  - stage: Build_x64
-    displayName: Build x64
-    dependsOn: []
-    condition: succeeded()
-    jobs:
-      - template: ./templates/build-console-pgo.yml
-        parameters:
-          platform: x64
-  - stage: Publish_PGO_Databases
-    displayName: Publish PGO databases
-    dependsOn: ['Build_x64']
-    jobs:
-      - template: ./templates/pgo-build-and-publish-nuget-job.yml
-        parameters:
-          pgoArtifact: 'PGO'
--- a/build/pipelines/release.yml
+++ b/build/pipelines/release.yml
@@ -1,574 +1,48 @@
-# This build should never run as CI or against a pull request.
 trigger: none
 pr: none

-pool: 
-  name: WinDevPool-L
-  demands: ImageOverride -equals WinDevVS16-latest
-
-parameters:
-  - name: branding
-    displayName: "Branding (Build Type)"
-    type: string
-    default: Release
-    values:
-      - Release
-      - Preview
-  - name: buildTerminal
-    displayName: "Build Windows Terminal MSIX"
-    type: boolean
-    default: true
-  - name: runCompliance
-    displayName: "Run Compliance and Security Build"
-    type: boolean
-    default: true
-  - name: publishSymbolsToPublic
-    displayName: "Publish Symbols to MSDL"
-    type: boolean
-    default: true
-  - name: buildTerminalVPack
-    displayName: "Build Windows Terminal VPack"
-    type: boolean
-    default: false
-  - name: buildWPF
-    displayName: "Build Terminal WPF Control"
-    type: boolean
-    default: false
-  - name: pgoBuildMode
-    displayName: "PGO Build Mode"
-    type: string
-    default: Optimize
-    values:
-      - Optimize
-      - Instrument
-      - None
-  - name: buildConfigurations
-    type: object
-    default:
-      - Release
-  - name: buildPlatforms
-    type: object
-    default:
-      - x64
-      - x86
-      - arm64
-  - name: buildWindowsVersions
-    type: object
-    default:
-      - Win10
-      - Win11
-
 variables:
-  TerminalInternalPackageVersion: "0.0.7"
+  baseYearForVersioning: 2019 # Used by build-console-int
+  versionMajor: 0
+  versionMinor: 1

-name: $(BuildDefinitionName)_$(date:yyMM).$(date:dd)$(rev:rrr)
-resources:
-  repositories:
-  - repository: self
-    path: 's' # Now that there are two checkouts, specify 's' to ensure this one still sits at the $(Build.SourcesDirectory) root so other things don't break with the implicit subdirectory normally created for >1 checkout.
-    type: git
-    ref: main
-  - repository: templates_onebranch
-    type: git
-    name: OneBranch.Pipelines/GovernedTemplates
-    ref: refs/heads/main
+# When we move off PackageES for Versioning, we'll need to switch
+# name to this format. For now, though, we need to use DayOfYear.Rev
+# to unique our builds, as mandated by PackageES's Setup task.
+# name: '$(versionMajor).$(versionMinor).$(DayOfYear)$(Rev:r).0'
+#
+# Build name/version number above must end with .0 to make the
+# store publication machinery happy.
+name: 'Terminal_$(date:yyMM).$(date:dd)$(rev:rrr)'
+
+# Build Arguments:
+#   WindowsTerminalOfficialBuild=[true,false]
+#     true - this is running on our build agent
+#     false - running locally
+#   WindowsTerminalBranding=[Dev,Preview,Release]
+#     <none>  - Development build resources (default)
+#     Preview - Preview build resources
+#     Release - regular build resources
 jobs:
- job: Build
-  strategy:
-    matrix:
-      ${{ each config in parameters.buildConfigurations }}:
-        ${{ each platform in parameters.buildPlatforms }}:
-          ${{ each windowsVersion in parameters.buildWindowsVersions }}:
-            ${{ config }}_${{ platform }}_${{ windowsVersion }}:
-              BuildConfiguration: ${{ config }}
-              BuildPlatform: ${{ platform }}
-              TerminalTargetWindowsVersion: ${{ windowsVersion }}
-  displayName: Build
-  timeoutInMinutes: 240
-  cancelTimeoutInMinutes: 1
-  steps:
-  - checkout: self
-    clean: true
-    submodules: true
-    persistCredentials: True
-  - task: PkgESSetupBuild@12
-    displayName: Package ES - Setup Build
-    inputs:
-      disableOutputRedirect: true
-  - task: PowerShell@2
-    displayName: Rationalize Build Platform
-    inputs:
-      targetType: inline
-      script: >-
-        $Arch = "$(BuildPlatform)"
+  - template: ./templates/build-console-audit-job.yml
+    parameters:
+      platform: x64

-        If ($Arch -Eq "x86") { $Arch = "Win32" }
+  - template: ./templates/build-console-int.yml
+    parameters:
+      platform: x64
+      additionalBuildArguments: /p:WindowsTerminalOfficialBuild=true;WindowsTerminalBranding=Preview

-        Write-Host "##vso[task.setvariable variable=RationalizedBuildPlatform]${Arch}"
-  - template: .\templates\restore-nuget-steps.yml
-  # Pull the Windows SDK for the developer tools like the debuggers so we can index sources later
-  - template: .\templates\install-winsdk-steps.yml
-  - task: UniversalPackages@0
-    displayName: Download terminal-internal Universal Package
-    inputs:
-      feedListDownload: 2b3f8893-a6e8-411f-b197-a9e05576da48
-      packageListDownload: e82d490c-af86-4733-9dc4-07b772033204
-      versionListDownload: $(TerminalInternalPackageVersion)
-  - task: TouchdownBuildTask@1
-    displayName: Download Localization Files
-    inputs:
-      teamId: 7105
-      authId: $(TouchdownAppId)
-      authKey: $(TouchdownAppKey)
-      resourceFilePath: >-
-        src\cascadia\TerminalApp\Resources\en-US\Resources.resw
+  - template: ./templates/build-console-int.yml
+    parameters:
+      platform: x86
+      additionalBuildArguments: /p:WindowsTerminalOfficialBuild=true;WindowsTerminalBranding=Preview

-        src\cascadia\TerminalApp\Resources\en-US\ContextMenu.resw
+  - template: ./templates/build-console-int.yml
+    parameters:
+      platform: arm64
+      additionalBuildArguments: /p:WindowsTerminalOfficialBuild=true;WindowsTerminalBranding=Preview

-        src\cascadia\TerminalControl\Resources\en-US\Resources.resw
+  - template: ./templates/check-formatting.yml

-        src\cascadia\TerminalConnection\Resources\en-US\Resources.resw
-
-        src\cascadia\TerminalSettingsModel\Resources\en-US\Resources.resw
-
-        src\cascadia\TerminalSettingsEditor\Resources\en-US\Resources.resw
-
-        src\cascadia\CascadiaPackage\Resources\en-US\Resources.resw
-      appendRelativeDir: true
-      localizationTarget: false
-      pseudoSetting: Included
-  - task: PowerShell@2
-    displayName: Move Loc files one level up
-    inputs:
-      targetType: inline
-      script: >-
-        $Files = Get-ChildItem . -R -Filter 'Resources.resw' | ? FullName -Like '*en-US\*\Resources.resw'
-
-        $Files | % { Move-Item -Verbose $_.Directory $_.Directory.Parent.Parent -EA:Ignore }
-      pwsh: true
-  - task: PowerShell@2
-    displayName: Copy the Context Menu Loc Resources to CascadiaPackage
-    inputs:
-      filePath: ./build/scripts/Copy-ContextMenuResourcesToCascadiaPackage.ps1
-      pwsh: true
-  - task: PowerShell@2
-    displayName: Generate NOTICE.html from NOTICE.md
-    inputs:
-      filePath: .\build\scripts\Generate-ThirdPartyNotices.ps1
-      arguments: -MarkdownNoticePath .\NOTICE.md -OutputPath .\src\cascadia\CascadiaPackage\NOTICE.html
-      pwsh: true
-  - ${{ if eq(parameters.buildTerminal, true) }}:
-    - pwsh: |-
-        ./build/scripts/Patch-ManifestsToWindowsVersion.ps1 -NewWindowsVersion "10.0.22000.0"
-      displayName: Update manifest target version to Win11 (if necessary)
-      condition: and(succeeded(), eq(variables['TerminalTargetWindowsVersion'], 'Win11'))
-    - task: VSBuild@1
-      displayName: Build solution **\OpenConsole.sln
-      condition: true
-      inputs:
-        solution: '**\OpenConsole.sln'
-        vsVersion: 16.0
-        msbuildArgs: /p:WindowsTerminalOfficialBuild=true /p:WindowsTerminalBranding=${{ parameters.branding }};PGOBuildMode=${{ parameters.pgoBuildMode }} /t:Terminal\CascadiaPackage /p:WindowsTerminalReleaseBuild=true /bl:$(Build.SourcesDirectory)\msbuild.binlog
-        platform: $(BuildPlatform)
-        configuration: $(BuildConfiguration)
-        clean: true
-        maximumCpuCount: true
-    - task: PublishBuildArtifacts@1
-      displayName: 'Publish Artifact: binlog'
-      condition: failed()
-      continueOnError: True
-      inputs:
-        PathtoPublish: $(Build.SourcesDirectory)\msbuild.binlog
-        ArtifactName: binlog-$(BuildPlatform)-$(TerminalTargetWindowsVersion)
-    - task: PowerShell@2
-      displayName: Check MSIX for common regressions
-      inputs:
-        targetType: inline
-        script: >-
-          $Package = Get-ChildItem -Recurse -Filter "CascadiaPackage_*.msix"
-
-          .\build\scripts\Test-WindowsTerminalPackage.ps1 -Verbose -Path $Package.FullName
-        pwsh: true
-  - ${{ if eq(parameters.buildWPF, true) }}:
-    - task: VSBuild@1
-      displayName: Build solution **\OpenConsole.sln for PublicTerminalCore
-      inputs:
-        solution: '**\OpenConsole.sln'
-        vsVersion: 16.0
-        msbuildArgs: /p:WindowsTerminalOfficialBuild=true /p:WindowsTerminalBranding=${{ parameters.branding }};PGOBuildMode=${{ parameters.pgoBuildMode }} /p:WindowsTerminalReleaseBuild=true /t:Terminal\wpf\PublicTerminalCore
-        platform: $(BuildPlatform)
-        configuration: $(BuildConfiguration)
-  - task: PowerShell@2
-    displayName: Source Index PDBs
-    inputs:
-      filePath: build\scripts\Index-Pdbs.ps1
-      arguments: -SearchDir '$(Build.SourcesDirectory)' -SourceRoot '$(Build.SourcesDirectory)' -recursive -Verbose -CommitId $(Build.SourceVersion)
-      errorActionPreference: silentlyContinue
-  - task: PowerShell@2
-    displayName: Run Unit Tests
-    condition: and(succeeded(), or(eq(variables['BuildPlatform'], 'x64'), eq(variables['BuildPlatform'], 'x86')))
-    enabled: False
-    inputs:
-      filePath: build\scripts\Run-Tests.ps1
-      arguments: -MatchPattern '*unit.test*.dll' -Platform '$(RationalizedBuildPlatform)' -Configuration '$(BuildConfiguration)'
-  - task: PowerShell@2
-    displayName: Run Feature Tests
-    condition: and(succeeded(), eq(variables['BuildPlatform'], 'x64'))
-    enabled: False
-    inputs:
-      filePath: build\scripts\Run-Tests.ps1
-      arguments: -MatchPattern '*feature.test*.dll' -Platform '$(RationalizedBuildPlatform)' -Configuration '$(BuildConfiguration)'
-  - ${{ if eq(parameters.buildTerminal, true) }}:
-    - task: CopyFiles@2
-      displayName: Copy *.appx/*.msix to Artifacts
-      inputs:
-        Contents: >-
-          **/*.appx
-
-          **/*.msix
-
-          **/*.appxsym
-
-          !**/Microsoft.VCLibs*.appx
-        TargetFolder: $(Build.ArtifactStagingDirectory)/appx
-        OverWrite: true
-        flattenFolders: true
-    - task: AzureArtifacts.manifest-generator-task.manifest-generator-task.ManifestGeneratorTask@0
-      displayName: 'Generate SBOM manifest'
-      inputs:
-       BuildDropPath: '$(System.ArtifactsDirectory)/appx'
-    - task: PublishBuildArtifacts@1
-      displayName: Publish Artifact (appx)
-      inputs:
-        PathtoPublish: $(Build.ArtifactStagingDirectory)/appx
-        ArtifactName: appx-$(BuildPlatform)-$(BuildConfiguration)-$(TerminalTargetWindowsVersion)
-  - ${{ if eq(parameters.buildWPF, true) }}:
-    - task: CopyFiles@2
-      displayName: Copy PublicTerminalCore.dll to Artifacts
-      inputs:
-        Contents: >-
-          **/PublicTerminalCore.dll
-
-          **/api-ms-win-core-synch-l1-2-0.dll
-        TargetFolder: $(Build.ArtifactStagingDirectory)/wpf
-        OverWrite: true
-        flattenFolders: true
-    - task: PublishBuildArtifacts@1
-      displayName: Publish Artifact (PublicTerminalCore)
-      inputs:
-        PathtoPublish: $(Build.ArtifactStagingDirectory)/wpf
-        ArtifactName: wpf-dll-$(BuildPlatform)-$(BuildConfiguration)-$(TerminalTargetWindowsVersion)
-
-  - task: PublishSymbols@2
-    displayName: Publish symbols path
-    continueOnError: True
-    inputs:
-      SearchPattern: |
-        $(Build.SourcesDirectory)/bin/**/*.pdb
-        $(Build.SourcesDirectory)/bin/**/*.exe
-        $(Build.SourcesDirectory)/bin/**/*.dll
-      IndexSources: false
-      SymbolServerType: TeamServices
-
- ${{ if eq(parameters.runCompliance, true) }}:
-  - template: ./templates/build-console-compliance-job.yml
-  
- ${{ if eq(parameters.buildTerminal, true) }}:
-  - job: BundleAndSign
-    strategy:
-      matrix:
-        ${{ each windowsVersion in parameters.buildWindowsVersions }}:
-          ${{ windowsVersion }}:
-            TerminalTargetWindowsVersion: ${{ windowsVersion }}
-    displayName: Create and sign AppX/MSIX bundles
-    dependsOn: Build
-    steps:
-    - checkout: self
-      clean: true
-      fetchDepth: 1
-      submodules: true
-      persistCredentials: True
-    - task: PkgESSetupBuild@12
-      displayName: Package ES - Setup Build
-      inputs:
-        disableOutputRedirect: true
-    - ${{ each platform in parameters.buildPlatforms }}:
-      - task: DownloadBuildArtifacts@0
-        displayName: Download Artifacts ${{ platform }} $(TerminalTargetWindowsVersion)
-        inputs:
-          artifactName: appx-${{ platform }}-Release-$(TerminalTargetWindowsVersion)
-    # Add 3000 to the major version component, but only for the bundle.
-    # This is to ensure that it is newer than "2022.xx.yy.zz" or whatever the original bundle versions were before
-    # we switched to uniform naming.
-    - pwsh: |-
-        $VersionEpoch = 3000
-        $Components = "$(XES_APPXMANIFESTVERSION)" -Split "\."
-        $Components[0] = ([int]$Components[0] + $VersionEpoch)
-        $BundleVersion = $Components -Join "."
-        .\build\scripts\Create-AppxBundle.ps1 -InputPath "$(System.ArtifactsDirectory)" -ProjectName CascadiaPackage -BundleVersion $BundleVersion -OutputPath "$(System.ArtifactsDirectory)\Microsoft.WindowsTerminal_$(TerminalTargetWindowsVersion)_$(XES_APPXMANIFESTVERSION)_8wekyb3d8bbwe.msixbundle"
-      displayName: Create WindowsTerminal*.msixbundle
-    - task: EsrpCodeSigning@1
-      displayName: Submit *.msixbundle to ESRP for code signing
-      inputs:
-        ConnectedServiceName: 9d6d2960-0793-4d59-943e-78dcb434840a
-        FolderPath: $(System.ArtifactsDirectory)
-        Pattern: Microsoft.WindowsTerminal*.msixbundle
-        UseMinimatch: true
-        signConfigType: inlineSignParams
-        inlineOperation: >-
-          [
-              {
-                  "KeyCode": "Dynamic",
-                  "CertTemplateName": "WINMSAPP1ST",
-                  "CertSubjectName": "CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US",
-                  "OperationCode": "SigntoolSign",
-                  "Parameters": {
-                      "OpusName": "Microsoft",
-                      "OpusInfo": "http://www.microsoft.com",
-                      "FileDigest": "/fd \"SHA256\"",
-                      "TimeStamp": "/tr \"http://rfc3161.gtm.corp.microsoft.com/TSS/HttpTspServer\" /td sha256"
-                  },
-                  "ToolName": "sign",
-                  "ToolVersion": "1.0"
-              },
-              {
-                  "KeyCode": "Dynamic",
-                  "CertTemplateName": "WINMSAPP1ST",
-                  "CertSubjectName": "CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US",
-                  "OperationCode": "SigntoolVerify",
-                  "Parameters": {},
-                  "ToolName": "sign",
-                  "ToolVersion": "1.0"
-              }
-          ]
-
-    - task: PublishBuildArtifacts@1
-      displayName: 'Publish Artifact: appxbundle-signed'
-      inputs:
-        PathtoPublish: $(System.ArtifactsDirectory)
-        ArtifactName: appxbundle-signed-$(TerminalTargetWindowsVersion)
-
- ${{ if eq(parameters.buildWPF, true) }}:
-  - job: PackageAndSignWPF
-    strategy:
-      matrix:
-        ${{ each config in parameters.buildConfigurations }}:
-          ${{ config }}:
-            BuildConfiguration: ${{ config }}
-    displayName: Create NuGet Package (WPF Terminal Control)
-    dependsOn: Build
-    steps:
-    - checkout: self
-      clean: true
-      fetchDepth: 1
-      submodules: true
-      persistCredentials: True
-    - task: PkgESSetupBuild@12
-      displayName: Package ES - Setup Build
-      inputs:
-        disableOutputRedirect: true
-    - ${{ each platform in parameters.buildPlatforms }}:
-      - task: DownloadBuildArtifacts@0
-        displayName: Download ${{ platform }} PublicTerminalCore
-        inputs:
-          artifactName: wpf-dll-${{ platform }}-$(BuildConfiguration)-Win10
-          itemPattern: '**/*.dll'
-          downloadPath: bin\${{ platform }}\$(BuildConfiguration)\
-          extractTars: false
-    - task: PowerShell@2
-      displayName: Move downloaded artifacts around
-      inputs:
-        targetType: inline
-        # Find all artifact files and move them up a directory. Ugh.
-        script: |-
-          Get-ChildItem bin -Recurse -Directory -Filter wpf-dll-* | % {
-            $_ | Get-ChildItem -Recurse -File | % {
-              Move-Item -Verbose $_.FullName $_.Directory.Parent.FullName
-            }
-          }
-          Move-Item bin\x86 bin\Win32
-    - task: NuGetToolInstaller@1
-      displayName: Use NuGet 5.10.0
-      inputs:
-        versionSpec: 5.10.0
-    - task: NuGetCommand@2
-      displayName: NuGet restore copy
-      inputs:
-        selectOrConfig: config
-        nugetConfigPath: NuGet.Config
-    - task: VSBuild@1
-      displayName: Build solution **\OpenConsole.sln for WPF Control
-      inputs:
-        solution: '**\OpenConsole.sln'
-        vsVersion: 16.0
-        msbuildArgs: /p:WindowsTerminalReleaseBuild=$(UseReleaseBranding);Version=$(XES_PACKAGEVERSIONNUMBER) /t:Pack
-        platform: Any CPU
-        configuration: $(BuildConfiguration)
-        maximumCpuCount: true
-    - task: PublishSymbols@2
-      displayName: Publish symbols path
-      continueOnError: True
-      inputs:
-        SearchPattern: |
-          $(Build.SourcesDirectory)/bin/**/*.pdb
-          $(Build.SourcesDirectory)/bin/**/*.exe
-          $(Build.SourcesDirectory)/bin/**/*.dll
-        IndexSources: false
-        SymbolServerType: TeamServices
-        SymbolsArtifactName: Symbols_WPF_$(BuildConfiguration)
-    - task: CopyFiles@2
-      displayName: Copy *.nupkg to Artifacts
-      inputs:
-        Contents: '**/*Wpf*.nupkg'
-        TargetFolder: $(Build.ArtifactStagingDirectory)/nupkg
-        OverWrite: true
-        flattenFolders: true
-    - task: EsrpCodeSigning@1
-      displayName: Submit *.nupkg to ESRP for code signing
-      inputs:
-        ConnectedServiceName: 9d6d2960-0793-4d59-943e-78dcb434840a
-        FolderPath: $(Build.ArtifactStagingDirectory)/nupkg
-        Pattern: '*.nupkg'
-        UseMinimatch: true
-        signConfigType: inlineSignParams
-        inlineOperation: >-
-          [
-              {
-                  "KeyCode": "CP-401405",
-                  "OperationCode": "NuGetSign",
-                  "Parameters": {},
-                  "ToolName": "sign",
-                  "ToolVersion": "1.0"
-              },
-              {
-                  "KeyCode": "CP-401405",
-                  "OperationCode": "NuGetVerify",
-                  "Parameters": {},
-                  "ToolName": "sign",
-                  "ToolVersion": "1.0"
-              }
-          ]
-    - task: PublishBuildArtifacts@1
-      displayName: Publish Artifact (nupkg)
-      inputs:
-        PathtoPublish: $(Build.ArtifactStagingDirectory)\nupkg
-        ArtifactName: wpf-nupkg-$(BuildConfiguration)
-
- ${{ if eq(parameters.publishSymbolsToPublic, true) }}:
-  - job: PublishSymbols
-    displayName: Publish Symbols
-    dependsOn: BundleAndSign
-    steps:
-    - checkout: self
-      clean: true
-      fetchDepth: 1
-      submodules: true
-    - task: PkgESSetupBuild@12
-      displayName: Package ES - Setup Build
-
-    # Download the appx-PLATFORM-CONFIG-VERSION artifact for every platform/version combo
-    - ${{ each platform in parameters.buildPlatforms }}:
-      - ${{ each windowsVersion in parameters.buildWindowsVersions }}:
-        - task: DownloadBuildArtifacts@0
-          displayName: Download Symbols ${{ platform }} ${{ windowsVersion }}
-          inputs:
-            artifactName: appx-${{ platform }}-Release-${{ windowsVersion }}
-
-    # It seems easier to do this -- download every appxsym -- then enumerate all the PDBs in the build directory for the
-    # public symbol push. Otherwise, we would have to list all of the PDB files one by one.
-    - pwsh: |-
-        mkdir $(Build.SourcesDirectory)/appxsym-temp
-        Get-ChildItem "$(System.ArtifactsDirectory)" -Filter *.appxsym -Recurse | % {
-          $src = $_.FullName
-          $dest = Join-Path "$(Build.SourcesDirectory)/appxsym-temp/" $_.Name
-
-          mkdir $dest
-          Write-Host "Extracting $src to $dest..."
-          tar -x -v -f $src -C $dest
-        }
-      displayName: Extract symbols for public consumption
-
-    # Pull the Windows SDK for the developer tools like the debuggers so we can index sources later
-    - template: .\templates\install-winsdk-steps.yml
-    - task: PowerShell@2
-      displayName: Source Index PDBs (the public ones)
-      inputs:
-        filePath: build\scripts\Index-Pdbs.ps1
-        arguments: -SearchDir '$(Build.SourcesDirectory)/appxsym-temp' -SourceRoot '$(Build.SourcesDirectory)' -recursive -Verbose -CommitId $(Build.SourceVersion)
-
-    # Publish the app symbols to the public MSDL symbol server
-    # accessible via https://msdl.microsoft.com/download/symbols
-    - task: PublishSymbols@2
-      displayName: 'Publish app symbols to MSDL'
-      inputs:
-        symbolsFolder: '$(Build.SourcesDirectory)/appxsym-temp'
-        searchPattern: '**/*.pdb'
-        SymbolsMaximumWaitTime: 30
-        SymbolServerType: 'TeamServices'
-        SymbolsProduct: 'Windows Terminal Application Binaries'
-        SymbolsVersion: '$(XES_APPXMANIFESTVERSION)'
-        # The ADO task does not support indexing of GitHub sources.
-        indexSources: false
-        detailedLog: true
-      # There is a bug which causes this task to fail if LIB includes an inaccessible path (even though it does not depend on it).
-      # To work around this issue, we just force LIB to be any dir that we know exists.
-      # Copied from https://github.com/microsoft/icu/blob/f869c214adc87415dfe751d81f42f1bca55dcf5f/build/azure-nuget.yml#L564-L583
-      env:
-        LIB: $(Build.SourcesDirectory)
-        ArtifactServices_Symbol_AccountName: microsoftpublicsymbols
-        ArtifactServices_Symbol_PAT: $(ADO_microsoftpublicsymbols_PAT)
-
-
- ${{ if eq(parameters.buildTerminalVPack, true) }}:
-  - job: VPack
-    displayName: Create Windows vPack
-    dependsOn: BundleAndSign
-    steps:
-    - checkout: self
-      clean: true
-      fetchDepth: 1
-      submodules: true
-    - task: PkgESSetupBuild@12
-      displayName: Package ES - Setup Build
-    - task: DownloadBuildArtifacts@0
-      displayName: Download Build Artifacts
-      inputs:
-        artifactName: appxbundle-signed-Win11
-        extractTars: false
-    - task: PowerShell@2
-      displayName: Rename and stage packages for vpack
-      inputs:
-        targetType: inline
-        script: >-
-          # Rename to known/fixed name for Windows build system
-
-          Get-ChildItem Microsoft.WindowsTerminal_Win11_*.msixbundle | Rename-Item -NewName { 'Microsoft.WindowsTerminal_8wekyb3d8bbwe.msixbundle' }
-
-
-          # Create vpack directory and place item inside
-
-          mkdir WindowsTerminal.app
-
-          mv Microsoft.WindowsTerminal_8wekyb3d8bbwe.msixbundle .\WindowsTerminal.app\
-        workingDirectory: $(System.ArtifactsDirectory)\appxbundle-signed-Win11
-    - task: PkgESVPack@12
-      displayName: 'Package ES - VPack'
-      env:
-        SYSTEM_ACCESSTOKEN: $(System.AccessToken)
-      inputs:
-        sourceDirectory: $(System.ArtifactsDirectory)\appxbundle-signed-Win11\WindowsTerminal.app
-        description: VPack for the Windows Terminal Application
-        pushPkgName: WindowsTerminal.app
-        owner: conhost
-    - task: PublishPipelineArtifact@1
-      displayName: 'Copy VPack Manifest to Drop'
-      inputs:
-        targetPath: $(XES_VPACKMANIFESTDIRECTORY)
-        artifactName: VPackManifest
-    - task: PkgESFCIBGit@12
-      displayName: 'Submit VPack Manifest to Windows'
-      inputs:
-        configPath: '$(Build.SourcesDirectory)\build\config\GitCheckin.json'
-        artifactsDirectory: $(XES_VPACKMANIFESTDIRECTORY)
-        prTimeOut: 5
-...
+  - template: ./templates/release-sign-and-bundle.yml
--- a/build/pipelines/templates/build-console-audit-job.yml
+++ b/build/pipelines/templates/build-console-audit-job.yml
@@ -8,20 +8,30 @@ jobs:
  variables:
    BuildConfiguration: AuditMode
    BuildPlatform: ${{ parameters.platform }}
-  pool:
-    ${{ if eq(variables['System.CollectionUri'], 'https://dev.azure.com/ms/') }}:
-      name: WinDevPoolOSS-L
-    ${{ if ne(variables['System.CollectionUri'], 'https://dev.azure.com/ms/') }}:
-      name: WinDevPool-L
-    demands: ImageOverride -equals WinDevVS16-latest
+  pool: "windevbuildagents"
+  # The public pool is also an option!
+  # pool: { vmImage: windows-2019 }

  steps:
  - checkout: self
    submodules: true
    clean: true
-    fetchDepth: 1

-  - template: restore-nuget-steps.yml
+  - task: NuGetToolInstaller@0
+    displayName: Ensure NuGet 4.8.1
+    inputs:
+      versionSpec: 4.8.1
+
+  # In the Microsoft Azure DevOps tenant, NuGetCommand is ambiguous.
+  # This should be `task: NuGetCommand@2`
+  - task: 333b11bd-d341-40d9-afcf-b32d5ce6f23b@2
+    displayName: Restore NuGet packages
+    inputs:
+      command: restore
+      feedsToUse: config
+      configPath: NuGet.config
+      restoreSolution: OpenConsole.sln
+      restoreDirectory: '$(Build.SourcesDirectory)\packages'

  - task: VSBuild@1
    displayName: 'Build solution **\OpenConsole.sln'
--- a/build/pipelines/templates/build-console-ci.yml
+++ b/build/pipelines/templates/build-console-ci.yml
@@ -1,30 +1,37 @@
 parameters:
  configuration: 'Release'
-  branding: 'Dev'
  platform: ''
  additionalBuildArguments: ''
+  minimumExpectedTestsExecutedCount: 10  # Sanity check for minimum expected tests to be reported
+  rerunPassesRequiredToAvoidFailure: 5

 jobs:
- job: Build${{ parameters.platform }}${{ parameters.configuration }}${{ parameters.branding }}
-  displayName: Build ${{ parameters.platform }} ${{ parameters.configuration }} ${{ parameters.branding }}
+- job: Build${{ parameters.platform }}${{ parameters.configuration }}
+  displayName: Build ${{ parameters.platform }} ${{ parameters.configuration }}
  variables:
    BuildConfiguration: ${{ parameters.configuration }}
    BuildPlatform: ${{ parameters.platform }}
-    WindowsTerminalBranding: ${{ parameters.branding }}
-  pool: 
-    ${{ if eq(variables['System.CollectionUri'], 'https://dev.azure.com/ms/') }}:
-      name: WinDevPoolOSS-L
-    ${{ if ne(variables['System.CollectionUri'], 'https://dev.azure.com/ms/') }}:
-      name: WinDevPool-L
-    demands: ImageOverride -equals WinDevVS16-latest
+  pool: "windevbuildagents"
+  # The public pool is also an option!
+  # pool: { vmImage: windows-2019 }

  steps:
  - template: build-console-steps.yml
    parameters:
      additionalBuildArguments: ${{ parameters.additionalBuildArguments }}

-  # It appears that the Component Governance build task that gets automatically injected stopped working
-  # when we renamed our main branch.
-  - task: ms.vss-governance-buildtask.governance-build-task-component-detection.ComponentGovernanceComponentDetection@0
-    displayName: 'Component Detection'
-    condition: and(succeededOrFailed(), not(eq(variables['Build.Reason'], 'PullRequest')))
+- template: helix-runtests-job.yml
+  parameters:
+    name: 'RunTestsInHelix'
+    dependsOn: Build${{ parameters.platform }}${{ parameters.configuration }}
+    condition: and(succeeded(), and(eq('${{ parameters.platform }}', 'x64'), not(eq(variables['Build.Reason'], 'PullRequest')))) 
+    testSuite: 'DevTestSuite'
+    rerunPassesRequiredToAvoidFailure: ${{ parameters.rerunPassesRequiredToAvoidFailure }}
+    
+- template: helix-processtestresults-job.yml
+  parameters:
+    dependsOn:
+    - RunTestsInHelix
+    condition: and(succeededOrFailed(), and(eq('${{ parameters.platform }}', 'x64'), not(eq(variables['Build.Reason'], 'PullRequest')))) 
+    rerunPassesRequiredToAvoidFailure: ${{ parameters.rerunPassesRequiredToAvoidFailure }}
+    minimumExpectedTestsExecutedCount: ${{ parameters.minimumExpectedTestsExecutedCount }}
--- a/build/pipelines/templates/build-console-compliance-job.yml
+++ b/build/pipelines/templates/build-console-compliance-job.yml
@@ -1,266 +0,0 @@
-jobs:
- job: Compliance
-  # We don't *need* a matrix but there's no other way to set parameters on a "job"
-  # in the AzDO YAML syntax. It would have to be a "stage" or a "template".
-  # Doesn't matter. We're going to do compliance on Release x64 because
-  # that's the one all the tooling works against for sure.
-  strategy:
-    matrix:
-      Release_x64:
-        BuildConfiguration: Release
-        BuildPlatform: x64
-  displayName: Validate Security and Compliance
-  timeoutInMinutes: 240
-  steps:
-  - checkout: self
-    path: 's' # Now that there are two checkouts, specify 's' to ensure this one still sits at the $(Build.SourcesDirectory) root so other things don't break with the implicit subdirectory normally created for >1 checkout.
-    clean: true
-    submodules: true
-    persistCredentials: True
-  - task: PkgESSetupBuild@12
-    displayName: Package ES - Setup Build
-    inputs:
-      disableOutputRedirect: true
-  - task: PowerShell@2
-    displayName: Rationalize Build Platform
-    inputs:
-      targetType: inline
-      script: >-
-        $Arch = "$(BuildPlatform)"
-
-        If ($Arch -Eq "x86") { $Arch = "Win32" }
-
-        Write-Host "##vso[task.setvariable variable=RationalizedBuildPlatform]${Arch}"
-  - template: restore-nuget-steps.yml
-  - task: UniversalPackages@0
-    displayName: Download terminal-internal Universal Package
-    inputs:
-      feedListDownload: 2b3f8893-a6e8-411f-b197-a9e05576da48
-      packageListDownload: e82d490c-af86-4733-9dc4-07b772033204
-      versionListDownload: $(TerminalInternalPackageVersion)
-  - task: TouchdownBuildTask@1
-    displayName: Download Localization Files
-    inputs:
-      teamId: 7105
-      authId: $(TouchdownAppId)
-      authKey: $(TouchdownAppKey)
-      resourceFilePath: >-
-        src\cascadia\TerminalApp\Resources\en-US\Resources.resw
-
-        src\cascadia\TerminalControl\Resources\en-US\Resources.resw
-
-        src\cascadia\TerminalConnection\Resources\en-US\Resources.resw
-
-        src\cascadia\TerminalSettingsModel\Resources\en-US\Resources.resw
-
-        src\cascadia\TerminalSettingsEditor\Resources\en-US\Resources.resw
-
-        src\cascadia\CascadiaPackage\Resources\en-US\Resources.resw
-      appendRelativeDir: true
-      localizationTarget: false
-      pseudoSetting: Included
-  - task: PowerShell@2
-    displayName: Move Loc files one level up
-    inputs:
-      targetType: inline
-      script: >-
-        $Files = Get-ChildItem . -R -Filter 'Resources.resw' | ? FullName -Like '*en-US\*\Resources.resw'
-
-        $Files | % { Move-Item -Verbose $_.Directory $_.Directory.Parent.Parent -EA:Ignore }
-      pwsh: true
-
-  # Run compliance activities. 
-  # These are specified at https://www.osgwiki.com/wiki/Package_ES_SDL_Templates
-  # We use Option 3.
-  # Option 1 isn't feasible because we don't run in Stages and it hides many/most of the override options we need.
-  # Option 2 isn't feasible because we don't use OneBranch and it doesn't make sense to migrate to it since this isn't an Azure product.
-
-  ### PREfast and PoliCheck need Node. Install that first.
-  - task: NodeTool@0
-    inputs:
-      versionSpec: '>=8.10.0'
-  
-  # This is the Package ES simplified SDL sources template. 
-  # To figure out which parameters to use, go read the source: https://microsoft.visualstudio.com/OneBranch.Pipelines/_git/GovernedTemplates?path=/v2/Steps/PackageES/Windows.SDL.Sources.Analysis.OS.Undocked.yml
-  - template: v2/Steps/PackageES/Windows.SDL.Sources.Analysis.OS.Undocked.yml@templates_onebranch
-    parameters:
-      globalSdl:
-          codeql:
-            eslint:
-              enabled: true
-            tsandjs:
-              enabled: true
-            python:
-              enabled: false
-            psscriptanalyzer:
-              enable: true
-          policheck:
-            exclusionsFile: $(Build.SourcesDirectory)\build\config\PolicheckExclusions.xml
-          tsa:
-            enabled: false
-            configFile: $(Build.SourcesDirectory)\build\config\tsaoptions.json
-    
-  # We need to run the v3 version of PREfast to be able to have the x64 toolset and specify the correct paths to avoid the WAPPROJ.
-  # Also, we run this prior to the rest of the binary analysis rules because PREfast will build all our binaries as a part of its checks.
-  # https://www.1eswiki.com/wiki/PREfast_Build_Task
-  # Builds the project with C/C++ static analysis tools to find coding flaws and vulnerabilities
-  # !!! WARNING !!! It doesn't work with WAPPROJ packaging projects. Build the sub-projects instead.
-  - task: securedevelopmentteam.vss-secure-development-tools.build-task-prefast.SDLNativeRules@3
-    displayName: 'Run the PREfast SDL Native Rules for MSBuild'
-    condition: succeededOrFailed()
-    inputs:
-      msBuildCommandline: msbuild.exe /nologo /m /p:WindowsTerminalOfficialBuild=true /p:WindowsTerminalBranding=${{ parameters.branding }} /p:WindowsTerminalReleaseBuild=true /p:platform=$(BuildPlatform) /p:configuration=$(BuildConfiguration) /t:Terminal\Window\WindowsTerminal /p:VisualStudioVersion=16.0 $(Build.SourcesDirectory)\OpenConsole.sln
-
-  # Copies output from PREfast SDL Native Rules task to expected location for consumption by PkgESSecComp
-  - task: CopyFiles@1
-    displayName: 'Copy PREfast xml files to SDLNativeRulesDir'
-    inputs:
-      SourceFolder: '$(Agent.BuildDirectory)'
-      Contents: |
-        **\*.nativecodeanalysis.xml
-      TargetFolder: '$(Agent.BuildDirectory)\_sdt\logs\SDLNativeRules'
-
-  # This is the Package ES simplified SDL binary template. 
-  # To figure out which parameters to use, go read the source: https://microsoft.visualstudio.com/OneBranch.Pipelines/_git/GovernedTemplates?path=/v2/Steps/PackageES/Windows.SDL.Binary.Analysis.OS.Undocked.yml
-  - template: v2/Steps/PackageES/Windows.SDL.Binary.Analysis.OS.Undocked.yml@templates_onebranch
-    parameters:
-      globalSdl:
-        binskim:
-          analyzeTargetGlob: $(Build.SourcesDirectory)\bin\**\*.dll;$(Build.SourcesDirectory)\bin\**\*.exe;-:file|**\Microsoft.UI.Xaml.dll;-:file|**\Microsoft.Toolkit.Win32.UI.XamlHost.dll;-:file|**\vcruntime*.dll;-:file|**\vcomp*.dll;-:file|**\vccorlib*.dll;-:file|**\vcamp*.dll;-:file|**\msvcp*.dll;-:file|**\concrt*.dll;-:file|**\TerminalThemeHelpers*.dll;-:file|**\cpprest*.dll
-        prefast:
-          enabled: false # See above, we run the v3 variant of this task.
-        tsa:
-          enabled: false
-          configFile: $(Build.SourcesDirectory)\build\config\tsaoptions.json
-      variables:
-          ob_outputDirectory: $(Build.SourcesDirectory)\bin\
-
-  # # 1ES Component Governance onboarding (Detects open source components). See https://docs.opensource.microsoft.com/tools/cg.html
-  # - task: ms.vss-governance-buildtask.governance-build-task-component-detection.ComponentGovernanceComponentDetection@0
-  #   displayName: Component Detection
-    
-
-  # !!! NOTE !!! Run PREfast first. Some of the other tasks are going to run on a completed build.
-  # PREfast is going to build the code as a part of its analysis and the generated sources
-  # and output binaries will be sufficient for the rest of the analysis.
-  # If you disable this, the other tasks won't likely work. You would have to add a build
-  # step instead that builds the code normally before calling them.
-  # Also... PREfast will rebuild anyway so that's why we're not running a normal build first.
-  # Waste of time to build twice.
-  # PREfast. See https://www.1eswiki.com/wiki/SDL_Native_Rules_Build_Task 
-
-  # The following 1ES tasks all operate completely differently and have a different syntax for usage.
-  # Most notable is every one of them has a different way of excluding things.
-  # Go see their 1eswiki.com pages to figure out how to exclude things.
-  # When writing exclusions, try to make them narrow so when new projects/binaries are added, they
-  # cause an error here and have to be explicitly pulled out. Don't write an exclusion so broad
-  # that it will catch other new stuff.
-
-  # https://www.1eswiki.com/wiki/PREfast_Build_Task
-  # Builds the project with C/C++ static analysis tools to find coding flaws and vulnerabilities
-  # !!! WARNING !!! It doesn't work with WAPPROJ packaging projects. Build the sub-projects instead.
-  # - task: securedevelopmentteam.vss-secure-development-tools.build-task-prefast.SDLNativeRules@3
-  #   displayName: 'Run the PREfast SDL Native Rules for MSBuild'
-  #   condition: succeededOrFailed()
-  #   inputs:
-  #     msBuildCommandline: msbuild.exe /nologo /m /p:WindowsTerminalOfficialBuild=true /p:WindowsTerminalBranding=${{ parameters.branding }} /p:WindowsTerminalReleaseBuild=true /p:platform=$(BuildPlatform) /p:configuration=$(BuildConfiguration) /t:Terminal\Window\WindowsTerminal /p:VisualStudioVersion=16.0 $(Build.SourcesDirectory)\OpenConsole.sln
-
-  # # Copies output from PREfast SDL Native Rules task to expected location for consumption by PkgESSecComp
-  # - task: CopyFiles@1
-  #   displayName: 'Copy PREfast xml files to SDLNativeRulesDir'
-  #   inputs:
-  #     SourceFolder: '$(Agent.BuildDirectory)'
-  #     Contents: |
-  #       **\*.nativecodeanalysis.xml
-  #     TargetFolder: '$(Agent.BuildDirectory)\_sdt\logs\SDLNativeRules'
-
-  # # https://www.1eswiki.com/index.php?title=PoliCheck_Build_Task
-  # # Scans the text of source code, comments, and content for terminology that could be sensitive for legal, cultural, or geopolitical reasons.
-  # # (Also finds vulgarities... takes all the fun out of everything.)
-  # - task: securedevelopmentteam.vss-secure-development-tools.build-task-policheck.PoliCheck@2
-  #   displayName: 'Run PoliCheck'
-  #   inputs:
-  #     targetType: F
-  #     targetArgument: $(Build.SourcesDirectory)
-  #     result: PoliCheck.xml
-  #     optionsFC: 1
-  #     optionsXS: 1
-  #     optionsUEPath: $(Build.SourcesDirectory)\build\config\PolicheckExclusions.xml
-  #     optionsHMENABLE: 0
-  #   continueOnError: true
-
-  # # https://www.1eswiki.com/wiki/CredScan_Azure_DevOps_Build_Task
-  # # Searches through source code and build outputs for a credential left behind in the open
-  # - task: securedevelopmentteam.vss-secure-development-tools.build-task-credscan.CredScan@3
-  #   displayName: 'Run CredScan'
-  #   inputs:
-  #     outputFormat: pre
-  #     # suppressionsFile: LocalSuppressions.json
-  #     batchSize: 20
-  #     debugMode: false
-  #   continueOnError: true
-
-  # # https://www.1eswiki.com/wiki/BinSkim_Build_Task
-  # # Searches managed and unmanaged binaries for known security vulnerabilities.
-  # - task: securedevelopmentteam.vss-secure-development-tools.build-task-binskim.BinSkim@4
-  #   displayName: 'Run BinSkim'
-  #   inputs:
-  #     TargetPattern: guardianGlob
-  #     # See https://aka.ms/gdn-globs for how to do match patterns
-  #     AnalyzeTargetGlob: $(Build.SourcesDirectory)\bin\**\*.dll;$(Build.SourcesDirectory)\bin\**\*.exe;-:file|**\Microsoft.UI.Xaml.dll;-:file|**\Microsoft.Toolkit.Win32.UI.XamlHost.dll;-:file|**\vcruntime*.dll;-:file|**\vcomp*.dll;-:file|**\vccorlib*.dll;-:file|**\vcamp*.dll;-:file|**\msvcp*.dll;-:file|**\concrt*.dll;-:file|**\TerminalThemeHelpers*.dll;-:file|**\cpprest*.dll
-  #   continueOnError: true
-
-  # # Set XES_SERIALPOSTBUILDREADY to run Security and Compliance task once per build
-  # - powershell: Write-Host “##vso[task.setvariable variable=XES_SERIALPOSTBUILDREADY;]true”  
-  #   displayName: 'Set XES_SERIALPOSTBUILDREADY Vars'
-
-  # # https://www.osgwiki.com/wiki/Package_ES_Security_and_Compliance
-  # # Does a few things:
-  # # - Ensures that Windows-required compliance tasks are run either inside this task
-  # #   or were run as a previous step prior to this one
-  # #   (PREfast, PoliCheck, Credscan)
-  # # - Runs Windows-specific compliance tasks inside the task
-  # #   + CheckCFlags - ensures that compiler and linker flags meet Windows standards
-  # #   + CFGCheck/XFGCheck - ensures that Control Flow Guard (CFG) or 
-  # #                         eXtended Flow Guard (XFG) are enabled on binaries
-  # #                         NOTE: CFG is deprecated and XFG isn't fully ready yet.
-  # #                         NOTE2: CFG fails on an XFG'd binary
-  # # - Brokers all security/compliance task logs to "Trust Services Automation (TSA)" (https://aka.ms/tsa)
-  # #   which is a system that maps all errors into the appropriate bug database 
-  # #   template for each organization since they all vary. It should also suppress
-  # #   new bugs when one already exists for the product.
-  # #   This one is set up to go to the OS repository and use the given parameters
-  # #   to file bugs to our AzDO product path.
-  # #   If we don't use PkgESSecComp to do this for us, we need to install the TSA task
-  # #   ourselves in this pipeline to finalize data upload and bug creation.
-  # # !!! NOTE !!! This task goes *LAST* after any other compliance tasks so it catches their logs
-  # - task: PkgESSecComp@10
-  #   displayName: 'Security and Compliance tasks'
-  #   inputs:
-  #     fileNewBugs: false
-  #     areaPath: 'OS\WDX\DXP\WinDev\Terminal'
-  #     teamProject: 'OS'
-  #     iterationPath: 'OS\Future'
-  #     bugTags: 'TerminalReleaseCompliance'
-  #     scanAll: true
-  #     errOnBugs: false
-  #     failOnStdErr: true
-  #     taskLogVerbosity: Diagnostic
-  #     secCompConfigFromTask: |
-  #       # Overrides default build sources directory
-  #       sourceTargetOverrideAll: $(Build.SourcesDirectory)
-  #       # Overrides default build binaries directory when "Scan all" option is specified
-  #       binariesTargetOverrideAll: $(Build.SourcesDirectory)\bin
-
-  #       # Set the tools to false if they should not run in the build
-  #       tools:
-  #           - toolName: CheckCFlags
-  #             enable: true
-  #           - toolName: CFGCheck
-  #             enable: true
-  #           - toolName: Policheck
-  #             enable: false
-  #           - toolName: CredScan
-  #             enable: false
-  #           - toolName: XFGCheck
-  #             enable: false
--- a/build/pipelines/templates/build-console-fuzzing.yml
+++ b/build/pipelines/templates/build-console-fuzzing.yml
@@ -1,91 +0,0 @@
-parameters:
-  configuration: 'Fuzzing'
-  platform: ''
-  additionalBuildArguments: ''
-
-jobs:
- job: Build${{ parameters.platform }}${{ parameters.configuration }}
-  displayName: Build ${{ parameters.platform }} ${{ parameters.configuration }}
-  variables:
-    BuildConfiguration: ${{ parameters.configuration }}
-    BuildPlatform: ${{ parameters.platform }}
-  pool: 
-    ${{ if eq(variables['System.CollectionUri'], 'https://dev.azure.com/ms/') }}:
-      name: WinDevPoolOSS-L
-    ${{ if ne(variables['System.CollectionUri'], 'https://dev.azure.com/ms/') }}:
-      name: WinDevPool-L
-    demands: ImageOverride -equals WinDevVS16-latest
-
-  steps:
-  - checkout: self
-    submodules: true
-    clean: true
-
-  - template: restore-nuget-steps.yml
-
-  # The environment variable VCToolsInstallDir isn't defined on lab machines, so we need to retrieve it ourselves.
-  - script: |
-      "%ProgramFiles(x86)%\Microsoft Visual Studio\Installer\vswhere.exe" -Latest -requires Microsoft.Component.MSBuild -property InstallationPath > %TEMP%\vsinstalldir.txt
-      set /p _VSINSTALLDIR15=<%TEMP%\vsinstalldir.txt
-      del %TEMP%\vsinstalldir.txt
-      call "%_VSINSTALLDIR15%\Common7\Tools\VsDevCmd.bat"
-      echo VCToolsInstallDir = %VCToolsInstallDir%
-      echo ##vso[task.setvariable variable=VCToolsInstallDir]%VCToolsInstallDir%
-    displayName: 'Retrieve VC tools directory'
-  
-  - task: VSBuild@1
-    displayName: 'Build solution **\OpenConsole.sln'
-    inputs:
-      solution: '**\OpenConsole.sln'
-      vsVersion: 16.0
-      platform: '$(BuildPlatform)'
-      configuration: '$(BuildConfiguration)'
-      msbuildArgs: "${{ parameters.additionalBuildArguments }}"
-      clean: true
-      maximumCpuCount: true
-
-  - task: PowerShell@2
-    displayName: 'Rationalize build platform'
-    inputs:
-      targetType: inline
-      script: |
-        $Arch = "$(BuildPlatform)"
-        If ($Arch -Eq "x86") { $Arch = "Win32" }
-        Write-Host "##vso[task.setvariable variable=RationalizedBuildPlatform]${Arch}"
-
-  - task: CopyFiles@2
-    displayName: 'Copy result logs to Artifacts'
-    inputs:
-      Contents: |
-       **/*.wtl
-       **/*onBuildMachineResults.xml
-       ${{ parameters.testLogPath }}
-      TargetFolder: '$(Build.ArtifactStagingDirectory)/$(BuildConfiguration)/$(BuildPlatform)/test'
-      OverWrite: true
-      flattenFolders: true
-
-  - task: CopyFiles@2
-    displayName: 'Copy outputs needed for test runs to Artifacts'
-    inputs:
-      Contents: |
-       $(Build.SourcesDirectory)/bin/$(RationalizedBuildPlatform)/$(BuildConfiguration)/*.exe
-       $(Build.SourcesDirectory)/bin/$(RationalizedBuildPlatform)/$(BuildConfiguration)/*.dll
-       $(Build.SourcesDirectory)/bin/$(RationalizedBuildPlatform)/$(BuildConfiguration)/*.xml
-       **/Microsoft.VCLibs.*.appx
-       **/TestHostApp/*.exe
-       **/TestHostApp/*.dll
-       **/TestHostApp/*.xml
-       !**/*.pdb
-       !**/*.ipdb
-       !**/*.obj
-       !**/*.pch
-      TargetFolder: '$(Build.ArtifactStagingDirectory)/$(BuildConfiguration)/$(BuildPlatform)/test'
-      OverWrite: true
-      flattenFolders: true
-    condition: succeeded()
-
-  - task: PublishBuildArtifacts@1
-    displayName: 'Publish All Build Artifacts'
-    inputs:
-      PathtoPublish: '$(Build.ArtifactStagingDirectory)'
-      ArtifactName: 'fuzzingBuildOutput'
--- a/build/pipelines/templates/build-console-int.yml
+++ b/build/pipelines/templates/build-console-int.yml
@@ -0,0 +1,30 @@
+parameters:
+  configuration: 'Release'
+  platform: ''
+  additionalBuildArguments: ''
+
+jobs:
+- job: Build${{ parameters.platform }}${{ parameters.configuration }}
+  displayName: Build ${{ parameters.platform }} ${{ parameters.configuration }}
+  variables:
+    BuildConfiguration: ${{ parameters.configuration }}
+    BuildPlatform: ${{ parameters.platform }}
+
+  pool:
+    name: Package ES Lab E
+    demands:
+    - msbuild
+    - visualstudio
+    - vstest
+
+  steps:
+  - task: PkgESSetupBuild@10
+    displayName: 'Package ES - Setup Build'
+    inputs:
+      useDfs: false
+      productName: WindowsTerminal
+      disableOutputRedirect: true
+
+  - template: build-console-steps.yml
+    parameters:
+      additionalBuildArguments: "/p:XesUseOneStoreVersioning=true;XesBaseYearForStoreVersion=$(baseYearForVersioning) ${{ parameters.additionalBuildArguments }}"
--- a/build/pipelines/templates/build-console-pgo.yml
+++ b/build/pipelines/templates/build-console-pgo.yml
@@ -1,55 +0,0 @@
-parameters:
-  configuration: 'Release'
-  platform: ''
-  additionalBuildArguments: ''
-  minimumExpectedTestsExecutedCount: 1  # Sanity check for minimum expected tests to be reported
-  rerunPassesRequiredToAvoidFailure: 5
-
-jobs:
- job: Build${{ parameters.platform }}${{ parameters.configuration }}
-  displayName: Build ${{ parameters.platform }} ${{ parameters.configuration }}
-  variables:
-    BuildConfiguration: ${{ parameters.configuration }}
-    BuildPlatform: ${{ parameters.platform }}
-    PGOBuildMode: 'Instrument'
-  pool: 
-    ${{ if eq(variables['System.CollectionUri'], 'https://dev.azure.com/ms/') }}:
-      name: WinDevPoolOSS-L
-    ${{ if ne(variables['System.CollectionUri'], 'https://dev.azure.com/ms/') }}:
-      name: WinDevPool-L
-    demands: ImageOverride -equals WinDevVS16-latest
-
-  steps:
-  - template: build-console-steps.yml
-    parameters:
-      additionalBuildArguments: '${{ parameters.additionalBuildArguments }}'
-
- template: helix-runtests-job.yml
-  parameters:
-    name: 'RunTestsInHelix'
-    dependsOn: Build${{ parameters.platform }}${{ parameters.configuration }}
-    condition: succeeded()
-    testSuite: 'PgoInstrumentationSuite'
-    taefQuery: '@IsPgo=true'
-    configuration: ${{ parameters.configuration }}
-    platform: ${{ parameters.platform }}
-    rerunPassesRequiredToAvoidFailure: ${{ parameters.rerunPassesRequiredToAvoidFailure }}
-    
- template: helix-processtestresults-job.yml
-  parameters:
-    name: 'ProcessTestResults'
-    pgoArtifact: 'PGO'
-    dependsOn:
-    - RunTestsInHelix
-    condition: succeededOrFailed()
-    rerunPassesRequiredToAvoidFailure: ${{ parameters.rerunPassesRequiredToAvoidFailure }}
-    minimumExpectedTestsExecutedCount: ${{ parameters.minimumExpectedTestsExecutedCount }}
-
- template: pgo-merge-pgd-job.yml
-  parameters:
-    name: 'MergePGD'
-    dependsOn:
-    - ProcessTestResults
-    pgoArtifact: 'PGO'
-    platform: ${{ parameters.platform }}
-    configuration: ${{ parameters.configuration }}
--- a/build/pipelines/templates/build-console-steps.yml
+++ b/build/pipelines/templates/build-console-steps.yml
@@ -1,28 +1,36 @@
 parameters:
  additionalBuildArguments: ''
+  testLogPath: '$(Build.BinariesDirectory)\$(BuildPlatform)\$(BuildConfiguration)\testsOnBuildMachine.wtl'

 steps:
 - checkout: self
  submodules: true
  clean: true
-  fetchDepth: 1

- template: restore-nuget-steps.yml
-
-# The environment variable VCToolsInstallDir isn't defined on lab machines, so we need to retrieve it ourselves.
- script: |
-    "%ProgramFiles(x86)%\Microsoft Visual Studio\Installer\vswhere.exe" -Latest -requires Microsoft.Component.MSBuild -property InstallationPath > %TEMP%\vsinstalldir.txt
-    set /p _VSINSTALLDIR15=<%TEMP%\vsinstalldir.txt
-    del %TEMP%\vsinstalldir.txt
-    call "%_VSINSTALLDIR15%\Common7\Tools\VsDevCmd.bat"
-    echo VCToolsInstallDir = %VCToolsInstallDir%
-    echo ##vso[task.setvariable variable=VCToolsInstallDir]%VCToolsInstallDir%
-  displayName: 'Retrieve VC tools directory'
-
- task: CmdLine@1
-  displayName: 'Display build machine environment variables'
+- task: NuGetToolInstaller@0
+  displayName: 'Use NuGet 5.2.0'
  inputs:
-    filename: 'set'
+    versionSpec: 5.2.0
+
+# In the Microsoft Azure DevOps tenant, NuGetCommand is ambiguous.
+# This should be `task: NuGetCommand@2`
+- task: 333b11bd-d341-40d9-afcf-b32d5ce6f23b@2
+  displayName: Restore NuGet packages for solution
+  inputs:
+    command: restore
+    feedsToUse: config
+    configPath: NuGet.config
+    restoreSolution: OpenConsole.sln
+    restoreDirectory: '$(Build.SourcesDirectory)\packages'
+    
+- task: 333b11bd-d341-40d9-afcf-b32d5ce6f23b@2
+  displayName: Restore NuGet packages for extraneous build actions
+  inputs:
+    command: restore
+    feedsToUse: config
+    configPath: NuGet.config
+    restoreSolution: build/packages.config
+    restoreDirectory: '$(Build.SourcesDirectory)\packages'

 - task: VSBuild@1
  displayName: 'Build solution **\OpenConsole.sln'
@@ -31,15 +39,12 @@ steps:
    vsVersion: 16.0
    platform: '$(BuildPlatform)'
    configuration: '$(BuildConfiguration)'
-    msbuildArgs: "${{ parameters.additionalBuildArguments }} /p:PGOBuildMode=$(PGOBuildMode) /bl:$(Build.SourcesDirectory)\\msbuild.binlog"
+    msbuildArgs: "${{ parameters.additionalBuildArguments }}"
    clean: true
    maximumCpuCount: true

 - task: PowerShell@2
  displayName: 'Check MSIX for common regressions'
-  # PGO runtime needs its own CRT and it's in the package for convenience.
-  # That will make this script mad so skip since we're not shipping the PGO Instrumentation one anyway.
-  condition: ne(variables['PGOBuildMode'], 'Instrument')
  inputs:
    targetType: inline
    script: |
@@ -48,7 +53,6 @@ steps:

 - task: powershell@2
  displayName: 'Source Index PDBs'
-  condition: ne(variables['PGOBuildMode'], 'Instrument')
  inputs:
    targetType: filePath
    filePath: build\scripts\Index-Pdbs.ps1
@@ -64,6 +68,54 @@ steps:
      If ($Arch -Eq "x86") { $Arch = "Win32" }
      Write-Host "##vso[task.setvariable variable=RationalizedBuildPlatform]${Arch}"

+- task: PowerShell@2
+  displayName: 'Run Unit Tests'
+  inputs:
+    targetType: filePath
+    filePath: build\scripts\Run-Tests.ps1
+    arguments: -MatchPattern '*unit.test*.dll' -Platform '$(RationalizedBuildPlatform)' -Configuration '$(BuildConfiguration)' -LogPath '${{ parameters.testLogPath }}'
+  condition: and(succeeded(), or(eq(variables['BuildPlatform'], 'x64'), eq(variables['BuildPlatform'], 'x86')))
+
+- task: PowerShell@2
+  displayName: 'Run Feature Tests (x64 only)'
+  inputs:
+    targetType: filePath
+    filePath: build\scripts\Run-Tests.ps1
+    arguments: -MatchPattern '*feature.test*.dll' -Platform '$(RationalizedBuildPlatform)' -Configuration '$(BuildConfiguration)' -LogPath '${{ parameters.testLogPath }}'
+  condition: and(succeeded(), eq(variables['BuildPlatform'], 'x64'))
+
+- task: PowerShell@2
+  displayName: 'Convert Test Logs from WTL to xUnit format'
+  inputs:
+    targetType: filePath
+    filePath: build\Helix\ConvertWttLogToXUnit.ps1
+    arguments: -WttInputPath '${{ parameters.testLogPath }}' -WttSingleRerunInputPath 'unused.wtl' -WttMultipleRerunInputPath 'unused2.wtl' -XUnitOutputPath 'onBuildMachineResults.xml' -TestNamePrefix '$(BuildConfiguration).$(BuildPlatform)'
+  condition: or(eq(variables['BuildPlatform'], 'x64'), eq(variables['BuildPlatform'], 'x86'))
+
+- task: PublishTestResults@2
+  displayName: 'Upload converted test logs'
+  inputs:
+    testResultsFormat: 'xUnit' # Options: JUnit, NUnit, VSTest, xUnit, cTest
+    testResultsFiles: '**/onBuildMachineResults.xml' 
+    #searchFolder: '$(System.DefaultWorkingDirectory)' # Optional
+    #mergeTestResults: false # Optional
+    #failTaskOnFailedTests: false # Optional
+    testRunTitle: 'On Build Machine Tests' # Optional
+    buildPlatform: $(BuildPlatform) # Optional
+    buildConfiguration: $(BuildConfiguration) # Optional
+    #publishRunAttachments: true # Optional
+
+- task: CopyFiles@2
+  displayName: 'Copy result logs to Artifacts'
+  inputs:
+    Contents: |
+     **/*.wtl
+     **/*onBuildMachineResults.xml
+     ${{ parameters.testLogPath }}
+    TargetFolder: '$(Build.ArtifactStagingDirectory)/$(BuildConfiguration)/$(BuildPlatform)/test'
+    OverWrite: true
+    flattenFolders: true
+
 - task: CopyFiles@2
  displayName: 'Copy *.appx/*.msix to Artifacts (Non-PR builds only)'
  inputs:
@@ -75,57 +127,24 @@ steps:
    TargetFolder: '$(Build.ArtifactStagingDirectory)/appx'
    OverWrite: true
    flattenFolders: true
-  condition: succeeded()
+  condition: and(succeeded(), ne(variables['Build.Reason'], 'PullRequest'))

 - task: CopyFiles@2
  displayName: 'Copy outputs needed for test runs to Artifacts'
  inputs:
    Contents: |
-     $(Build.SourcesDirectory)/bin/$(RationalizedBuildPlatform)/$(BuildConfiguration)/*.exe
-     $(Build.SourcesDirectory)/bin/$(RationalizedBuildPlatform)/$(BuildConfiguration)/*.dll
-     $(Build.SourcesDirectory)/bin/$(RationalizedBuildPlatform)/$(BuildConfiguration)/*.xml
+     $(Build.SourcesDirectory)/bin/$(BuildPlatform)/$(BuildConfiguration)/*.exe
+     $(Build.SourcesDirectory)/bin/$(BuildPlatform)/$(BuildConfiguration)/*.dll
+     $(Build.SourcesDirectory)/bin/$(BuildPlatform)/$(BuildConfiguration)/*.xml
     **/Microsoft.VCLibs.*.appx
-     **/*unit.test*.dll
-     **/*unit.test*.manifest
-     **/TestHostApp/*.exe
-     **/TestHostApp/*.dll
-     **/TestHostApp/*.xml
-     !**/*.pdb
-     !**/*.ipdb
-     !**/*.obj
-     !**/*.pch
+     **/TestHostApp/*
    TargetFolder: '$(Build.ArtifactStagingDirectory)/$(BuildConfiguration)/$(BuildPlatform)/test'
    OverWrite: true
    flattenFolders: true
-  condition: succeeded()
+  condition: and(and(succeeded(), eq(variables['BuildPlatform'], 'x64')), ne(variables['Build.Reason'], 'PullRequest'))

 - task: PublishBuildArtifacts@1
  displayName: 'Publish All Build Artifacts'
  inputs:
    PathtoPublish: '$(Build.ArtifactStagingDirectory)'
-    ArtifactName: 'drop'
-
- task: CopyFiles@2
-  displayName: 'Copy PGO databases needed for PGO instrumentation run'
-  inputs:
-    Contents: |
-     **/*.pgd
-    TargetFolder: '$(Build.ArtifactStagingDirectory)/$(BuildConfiguration)/PGO/$(BuildPlatform)'
-    OverWrite: true
-    flattenFolders: true
-  condition: and(succeeded(), eq(variables['PGOBuildMode'], 'Instrument'))
-
- task: PublishBuildArtifacts@1
-  displayName: 'Publish All PGO Artifacts'
-  inputs:
-    PathtoPublish: '$(Build.ArtifactStagingDirectory)/$(BuildConfiguration)/PGO'
-    ArtifactName: 'PGO'
-  condition: and(succeeded(), eq(variables['PGOBuildMode'], 'Instrument'))
-
- task: PublishBuildArtifacts@1
-  displayName: 'Publish Artifact: binlog'
-  condition: always()
-  continueOnError: True
-  inputs:
-    PathtoPublish: $(Build.SourcesDirectory)\msbuild.binlog
-    ArtifactName: binlog-$(BuildPlatform)
+    ArtifactName: 'drop'
--- a/build/pipelines/templates/check-formatting.yml
+++ b/build/pipelines/templates/check-formatting.yml
@@ -11,7 +11,7 @@ jobs:
    clean: true

  - task: PowerShell@2
-    displayName: 'Code Formatting Check'
+    displayName: 'Code Formattting Check'
    inputs:
      targetType: filePath
      filePath: '.\build\scripts\Invoke-FormattingCheck.ps1'
--- a/build/pipelines/templates/console-ci-helix-job.yml
+++ b/build/pipelines/templates/console-ci-helix-job.yml
@@ -1,25 +0,0 @@
-parameters:
-  configuration: 'Release'
-  platform: ''
-  minimumExpectedTestsExecutedCount: 10  # Sanity check for minimum expected tests to be reported
-  rerunPassesRequiredToAvoidFailure: 5
-
-jobs:
- template: helix-runtests-job.yml
-  parameters:
-    name: 'RunTestsInHelix'
-    # We're not setting dependsOn as we want to rely on the "stage" dependency above us
-    testSuite: 'DevTestSuite'
-    platform: ${{ parameters.platform }}
-    configuration: ${{ parameters.configuration }}
-    rerunPassesRequiredToAvoidFailure: ${{ parameters.rerunPassesRequiredToAvoidFailure }}
-    
- template: helix-processtestresults-job.yml
-  parameters:
-    dependsOn:
-    - RunTestsInHelix
-    # the default condition is succeededOrFailed(), and the "stage" condition ensures we only run as needed
-    platform: ${{ parameters.platform }}
-    configuration: ${{ parameters.configuration }}
-    rerunPassesRequiredToAvoidFailure: ${{ parameters.rerunPassesRequiredToAvoidFailure }}
-    minimumExpectedTestsExecutedCount: ${{ parameters.minimumExpectedTestsExecutedCount }}
--- a/build/pipelines/templates/helix-createprojfile-steps.yml
+++ b/build/pipelines/templates/helix-createprojfile-steps.yml
@@ -12,4 +12,4 @@ steps:
    inputs:
      targetType: filePath
      filePath: build\Helix\GenerateTestProjFile.ps1
-      arguments: -TestFile '${{ parameters.testFilePath }}' -OutputProjFile '$(Build.ArtifactStagingDirectory)\$(BuildConfiguration)\$(BuildPlatform)\${{ parameters.outputProjFileName }}' -JobTestSuiteName '${{ parameters.testSuite }}' -TaefPath '$(Build.SourcesDirectory)\build\Helix\packages\Microsoft.Taef.10.60.210621002\build\Binaries\x86' -TaefQuery '${{ parameters.taefQuery }}'
+      arguments: -TestFile '${{ parameters.testFilePath }}' -OutputProjFile '$(Build.ArtifactStagingDirectory)\${{ parameters.outputProjFileName }}' -JobTestSuiteName '${{ parameters.testSuite }}' -TaefPath '$(Build.SourcesDirectory)\build\Helix\packages\Microsoft.Taef.10.58.210305002\build\Binaries\x86' -TaefQuery '${{ parameters.taefQuery }}'
--- a/build/pipelines/templates/helix-processtestresults-job.yml
+++ b/build/pipelines/templates/helix-processtestresults-job.yml
@@ -8,7 +8,6 @@ parameters:

 jobs:
 - job: ProcessTestResults
-  displayName: Process Helix Results ${{ parameters.platform }} ${{ parameters.configuration }}
  condition: ${{ parameters.condition }}
  dependsOn: ${{ parameters.dependsOn }}
  pool:
@@ -23,7 +22,6 @@ jobs:
    condition: succeededOrFailed()
    env:
      SYSTEM_ACCESSTOKEN: $(System.AccessToken)
-      HelixAccessToken: $(HelixApiAccessToken)
    inputs:
      targetType: filePath
      filePath: build\Helix\UpdateUnreliableTests.ps1
@@ -34,7 +32,6 @@ jobs:
    condition: succeededOrFailed()
    env:
      SYSTEM_ACCESSTOKEN: $(System.AccessToken)
-      HelixAccessToken: $(HelixApiAccessToken)
    inputs:
      targetType: filePath
      filePath: build\Helix\OutputTestResults.ps1
--- a/build/pipelines/templates/helix-runtests-job.yml
+++ b/build/pipelines/templates/helix-runtests-job.yml
@@ -10,16 +10,22 @@ parameters:
  maxParallel: 4
  rerunPassesRequiredToAvoidFailure: 5
  taefQuery: ''
-  configuration: ''
-  platform: ''
  # if 'useBuildOutputFromBuildId' is set, we will default to using a build from this pipeline:
  useBuildOutputFromPipeline: $(System.DefinitionId)
-  openHelixTargetQueues: 'windows.10.amd64.client21h1.open.xaml'
-  closedHelixTargetQueues: 'windows.10.amd64.client21h1.xaml'
+  matrix:
+    # Release_x86:
+    #   buildPlatform: 'x86'
+    #   buildConfiguration: 'release'
+    #   openHelixTargetQueues: 'windows.10.amd64.client19h1.open.xaml'
+    #   closedHelixTargetQueues: 'windows.10.amd64.client19h1.xaml'
+    Release_x64:
+      buildPlatform: 'x64'
+      buildConfiguration: 'release'
+      openHelixTargetQueues: 'windows.10.amd64.client19h1.open.xaml'
+      closedHelixTargetQueues: 'windows.10.amd64.client19h1.xaml'

 jobs:
 - job: ${{ parameters.name }}
-  displayName: Submit Helix ${{ parameters.platform }} ${{ parameters.configuration }}
  dependsOn: ${{ parameters.dependsOn }}
  condition: ${{ parameters.condition }}
  pool:
@@ -27,15 +33,13 @@ jobs:
  timeoutInMinutes: 120
  strategy:
    maxParallel: ${{ parameters.maxParallel }}
+    matrix: ${{ parameters.matrix }}
  variables:
-    buildConfiguration: ${{ parameters.configuration }}
-    buildPlatform: ${{ parameters.platform }}
-    openHelixTargetQueues: ${{ parameters.openHelixTargetQueues }}
-    closedHelixTargetQueues: ${{ parameters.closedHelixTargetQueues }}
    artifactsDir: $(Build.SourcesDirectory)\Artifacts
-    taefPath: $(Build.SourcesDirectory)\build\Helix\packages\Microsoft.Taef.10.60.210621002\build\Binaries\$(buildPlatform)
+    taefPath: $(Build.SourcesDirectory)\build\Helix\packages\Microsoft.Taef.10.58.210305002\build\Binaries\$(buildPlatform)
    helixCommonArgs: '/binaryLogger:$(Build.SourcesDirectory)/${{parameters.name}}.$(buildPlatform).$(buildConfiguration).binlog /p:HelixBuild=$(Build.BuildId).$(buildPlatform).$(buildConfiguration) /p:Platform=$(buildPlatform) /p:Configuration=$(buildConfiguration) /p:HelixType=${{parameters.helixType}} /p:TestSuite=${{parameters.testSuite}} /p:ProjFilesPath=$(Build.ArtifactStagingDirectory) /p:rerunPassesRequiredToAvoidFailure=${{parameters.rerunPassesRequiredToAvoidFailure}}'

+
  steps:
  - task: CmdLine@1
    displayName: 'Display build machine environment variables'
@@ -93,17 +97,9 @@ jobs:
      filename: 'dir'
      arguments: '/s $(Build.SourcesDirectory)\HelixPayload'

-  - task: PowerShell@2
-    displayName: 'Make artifact directories'
-    inputs:
-      targetType: inline
-      script: |
-        New-Item -ItemType Directory -Force -Path "$(Build.ArtifactStagingDirectory)\$(BuildConfiguration)\"
-        New-Item -ItemType Directory -Force -Path "$(Build.ArtifactStagingDirectory)\$(BuildConfiguration)\$(BuildPlatform)\"
-
  - template: helix-createprojfile-steps.yml
    parameters:
-      condition: and(succeeded(),eq('${{ parameters.testSuite }}','DevTestSuite'))
+      condition: and(succeeded(),ne('${{ parameters.testSuite }}','NugetTestSuite'))
      testFilePath: '$(artifactsDir)\${{ parameters.artifactName }}\$(buildConfiguration)\$(buildPlatform)\Test\TerminalApp.LocalTests.dll'
      outputProjFileName: 'RunTestsInHelix-TerminalAppLocalTests.proj'
      testSuite: '${{ parameters.testSuite }}'
@@ -111,7 +107,7 @@ jobs:

  - template: helix-createprojfile-steps.yml
    parameters:
-      condition: and(succeeded(),eq('${{ parameters.testSuite }}','DevTestSuite'))
+      condition: and(succeeded(),ne('${{ parameters.testSuite }}','NugetTestSuite'))
      testFilePath: '$(artifactsDir)\${{ parameters.artifactName }}\$(buildConfiguration)\$(buildPlatform)\Test\SettingsModel.LocalTests.dll'
      outputProjFileName: 'RunTestsInHelix-SettingsModelLocalTests.proj'
      testSuite: '${{ parameters.testSuite }}'
@@ -120,20 +116,12 @@ jobs:

  - template: helix-createprojfile-steps.yml
    parameters:
-      condition: and(succeeded(),eq('${{ parameters.testSuite }}','DevTestSuite'))
+      condition: and(succeeded(),ne('${{ parameters.testSuite }}','NugetTestSuite'))
      testFilePath: '$(artifactsDir)\${{ parameters.artifactName }}\$(buildConfiguration)\$(buildPlatform)\Test\Conhost.UIA.Tests.dll'
      outputProjFileName: 'RunTestsInHelix-HostTestsUIA.proj'
      testSuite: '${{ parameters.testSuite }}'
      taefQuery: ${{ parameters.taefQuery }}

-  - template: helix-createprojfile-steps.yml
-    parameters:
-      condition: and(succeeded(),or(eq('${{ parameters.testSuite }}','PgoInstrumentationSuite'),eq('${{ parameters.testSuite }}','DevTestSuite')))
-      testFilePath: '$(artifactsDir)\${{ parameters.artifactName }}\$(buildConfiguration)\$(buildPlatform)\Test\WindowsTerminal.UIA.Tests.dll'
-      outputProjFileName: 'RunTestsInHelix-WindowsTerminalUIATests.proj'
-      testSuite: '${{ parameters.testSuite }}'
-      taefQuery: ${{ parameters.taefQuery }}
-
  - task: PublishBuildArtifacts@1
    displayName: 'Publish generated .proj files'
    inputs:
@@ -142,7 +130,6 @@ jobs:

  - task: DotNetCoreCLI@2
    displayName: 'Run tests in Helix (open queues)'
-    condition: and(succeeded(),eq(variables['System.CollectionUri'],'https://dev.azure.com/ms/'))
    env:
      SYSTEM_ACCESSTOKEN: $(System.AccessToken)
    inputs:
@@ -151,14 +138,3 @@ jobs:
      custom: msbuild
      arguments: '$(helixCommonArgs) /p:IsExternal=true /p:Creator=Terminal /p:HelixTargetQueues=$(openHelixTargetQueues)'

-  - task: DotNetCoreCLI@2
-    displayName: 'Run tests in Helix (closed queues)'
-    condition: and(succeeded(),ne(variables['System.CollectionUri'],'https://dev.azure.com/ms/'))
-    env:
-      SYSTEM_ACCESSTOKEN: $(System.AccessToken)
-      HelixAccessToken: $(HelixApiAccessToken)
-    inputs:
-      command: custom
-      projects: build\Helix\RunTestsInHelix.proj
-      custom: msbuild
-      arguments: '$(helixCommonArgs) /p:HelixTargetQueues=$(closedHelixTargetQueues)'
--- a/build/pipelines/templates/install-winsdk-steps.yml
+++ b/build/pipelines/templates/install-winsdk-steps.yml
@@ -1,9 +0,0 @@
-parameters:
-  sdkVersion: 18362
-steps:
-  - task: powershell@2
-    inputs:
-      targetType: filePath
-      filePath: build\scripts\Install-WindowsSdkISO.ps1
-      arguments: ${{ parameters.sdkVersion }}
-    displayName: 'Install Windows SDK (${{ parameters.sdkVersion }})'
--- a/build/pipelines/templates/pgo-build-and-publish-nuget-job.yml
+++ b/build/pipelines/templates/pgo-build-and-publish-nuget-job.yml
@@ -1,66 +0,0 @@
-# From our friends at MUX: https://github.com/microsoft/microsoft-ui-xaml/blob/main/build/AzurePipelinesTemplates/MUX-BuildAndPublishPGONuGet-Job.yml
-
-parameters:
-  dependsOn: ''
-  pgoArtifact: PGO
-
-jobs:
- job: BuildAndPublishPGONuGet
-  dependsOn: ${{ parameters.dependsOn }}
-  pool:
-    vmImage: 'windows-2019'
-  variables:
-    artifactsPath: $(Build.SourcesDirectory)\Artifacts
-    pgoToolsPath: $(Build.SourcesDirectory)\build\PGO
-    nuspecPath: $(pgoToolsPath)\NuSpecs
-    nuspecFilename: PGO.nuspec
-
-  steps:
-  - task: DownloadBuildArtifacts@0
-    inputs:
-      artifactName: ${{ parameters.pgoArtifact }}
-      downloadPath: $(artifactsPath)
-
-  - task: NuGetAuthenticate@0
-    inputs:
-      nuGetServiceConnections: 'Terminal Public Artifact Feed'
-
-  - task: NuGetToolInstaller@0
-    displayName: 'Use NuGet 5.8.0'
-    inputs:
-      versionSpec: 5.8.0
-
-  # In the Microsoft Azure DevOps tenant, NuGetCommand is ambiguous.
-  # This should be `task: NuGetCommand@2`
-  - task: 333b11bd-d341-40d9-afcf-b32d5ce6f23b@2
-    displayName: Restore NuGet packages for extraneous build actions
-    inputs:
-      command: restore
-      feedsToUse: config
-      configPath: NuGet.config
-      restoreSolution: build/packages.config
-      restoreDirectory: '$(Build.SourcesDirectory)\packages'
-
-  - task: MSBuild@1
-    displayName: 'Create PGO Nuget'
-    inputs:
-      solution: $(pgoToolsPath)\PGO.DB.proj
-      msbuildArguments: '/t:CreatePGONuGet /p:PGOBuildMode=Instrument /p:PGDPathForAllArch=$(artifactsPath)\${{ parameters.pgoArtifact }} /p:PGOOutputPath=$(Build.ArtifactStagingDirectory)'
-
-  - task: PublishBuildArtifacts@1
-    inputs:
-      pathToPublish: $(Build.ArtifactStagingDirectory)
-      artifactName: ${{ parameters.pgoArtifact }}
-
-  - task: 333b11bd-d341-40d9-afcf-b32d5ce6f23b@2
-    displayName: 'NuGet push'
-    inputs:
-      command: push
-      nuGetFeedType: external
-      packagesToPush: $(Build.ArtifactStagingDirectory)/*.nupkg
-      # The actual URL and PAT for this feed is configured at
-      # https://microsoft.visualstudio.com/Dart/_settings/adminservices
-      # This is the name of that connection
-      publishFeedCredentials: 'Terminal Public Artifact Feed'
-      feedsToUse: config
-      nugetConfigPath: '$(Build.SourcesDirectory)/NuGet.config'
--- a/build/pipelines/templates/pgo-merge-pgd-job.yml
+++ b/build/pipelines/templates/pgo-merge-pgd-job.yml
@@ -1,70 +0,0 @@
-parameters:
-  dependsOn: ''
-  pgoArtifact: PGO
-  platform: ''
-  configuration: ''
-
-jobs:
- job: MergePGD
-  dependsOn: ${{ parameters.dependsOn }}
-  pool:
-    vmImage: 'windows-2019'
-  variables:
-    artifactsPath: $(Build.SourcesDirectory)\Artifacts
-    pgoArtifactsPath: $(artifactsPath)\${{ parameters.pgoArtifact }}
-    buildPlatform: ${{ parameters.platform }}
-    buildConfiguration: ${{ parameters.configuration }}
-
-  steps:
-  # The environment variable VCToolsInstallDir isn't defined on lab machines, so we need to retrieve it ourselves.
-  - script: |
-      "%ProgramFiles(x86)%\Microsoft Visual Studio\Installer\vswhere.exe" -Latest -requires Microsoft.Component.MSBuild -property InstallationPath > %TEMP%\vsinstalldir.txt
-      set /p _VSINSTALLDIR15=<%TEMP%\vsinstalldir.txt
-      del %TEMP%\vsinstalldir.txt
-      call "%_VSINSTALLDIR15%\Common7\Tools\VsDevCmd.bat"
-      echo VCToolsInstallDir = %VCToolsInstallDir%
-      echo ##vso[task.setvariable variable=VCToolsInstallDir]%VCToolsInstallDir%
-    displayName: 'Retrieve VC tools directory'
-
-  - task: NuGetToolInstaller@0
-    displayName: 'Use NuGet 5.2.0'
-    inputs:
-      versionSpec: 5.2.0
-
-  - task: NuGetAuthenticate@0
-
-  # In the Microsoft Azure DevOps tenant, NuGetCommand is ambiguous.
-  # This should be `task: NuGetCommand@2`
-  - task: 333b11bd-d341-40d9-afcf-b32d5ce6f23b@2
-    displayName: Restore NuGet packages for extraneous build actions
-    inputs:
-      command: restore
-      feedsToUse: config
-      configPath: NuGet.config
-      restoreSolution: build/packages.config
-      restoreDirectory: '$(Build.SourcesDirectory)\packages'
-
-  - task: DownloadBuildArtifacts@0
-    inputs:
-      artifactName: ${{ parameters.pgoArtifact }}
-      downloadPath: $(artifactsPath)
-
-  - task: MSBuild@1
-    displayName: Merge counts into PGD
-    inputs:
-      solution: $(Build.SourcesDirectory)\OpenConsole.sln
-      platform: $(buildPlatform)
-      configuration: $(buildConfiguration)
-      msbuildArguments: '/t:MergePGOCounts /p:PGOBuildMode=Instrument /p:PGDPath=$(pgoArtifactsPath)\$(buildPlatform) /p:PGCRootPath=$(pgoArtifactsPath)\$(buildPlatform)'
-
-  - task: CopyFiles@2
-    displayName: 'Copy merged pgd to artifact staging'
-    inputs:
-      sourceFolder: $(pgoArtifactsPath)
-      contents: '**\$(buildPlatform)\*.pgd'
-      targetFolder: $(Build.ArtifactStagingDirectory)
-
-  - task: PublishBuildArtifacts@1
-    inputs:
-      pathToPublish: $(Build.ArtifactStagingDirectory)
-      artifactName: ${{ parameters.pgoArtifact }}
--- a/build/pipelines/templates/release-sign-and-bundle.yml
+++ b/build/pipelines/templates/release-sign-and-bundle.yml
@@ -0,0 +1,74 @@
+parameters:
+  configuration: 'Release'
+
+jobs:
+- job: SignDeploy${{ parameters.configuration }}
+  displayName: Sign and Deploy for ${{ parameters.configuration }}
+
+  dependsOn:
+    - Buildx64AuditMode
+    - Buildx64Release
+    - Buildx86Release
+    - Buildarm64Release
+    - CodeFormatCheck
+  condition: |
+    and
+    (
+      in(dependencies.Buildx64AuditMode.result, 'Succeeded', 'SucceededWithIssues', 'Skipped'),
+      in(dependencies.Buildx64Release.result,   'Succeeded', 'SucceededWithIssues', 'Skipped'),
+      in(dependencies.Buildx86Release.result,   'Succeeded', 'SucceededWithIssues', 'Skipped'),
+      in(dependencies.Buildarm64Release.result, 'Succeeded', 'SucceededWithIssues', 'Skipped'),
+      in(dependencies.CodeFormatCheck.result,   'Succeeded', 'SucceededWithIssues', 'Skipped')
+    )
+
+  variables:
+    BuildConfiguration: ${{ parameters.configuration }}
+    AppxProjectName: CascadiaPackage
+    AppxBundleName: Microsoft.WindowsTerminal_8wekyb3d8bbwe.msixbundle
+
+  pool:
+    name: Package ES Lab E
+
+  steps:
+  - checkout: self
+    clean: true
+
+  - task: PkgESSetupBuild@10
+    displayName: 'Package ES - Setup Build'
+    inputs:
+      useDfs: false
+      productName: WindowsTerminal
+      disableOutputRedirect: true
+
+  - task: ms.vss-governance-buildtask.governance-build-task-component-detection.ComponentGovernanceComponentDetection@0
+    displayName: 'Component Detection'
+
+  - task: DownloadBuildArtifacts@0
+    displayName: Download AppX artifacts
+    inputs:
+      artifactName: 'appx-$(BuildConfiguration)'
+      itemPattern: |
+        **/*.appx
+        **/*.msix
+      downloadPath: '$(Build.ArtifactStagingDirectory)\appx'
+
+  - task: PowerShell@2
+    displayName: 'Create $(AppxBundleName)'
+    inputs:
+      targetType: filePath
+      filePath: '.\build\scripts\Create-AppxBundle.ps1'
+      arguments: |
+        -InputPath "$(Build.ArtifactStagingDirectory)\appx" -ProjectName $(AppxProjectName) -BundleVersion 0.0.0.0 -OutputPath "$(Build.ArtifactStagingDirectory)\$(AppxBundleName)"
+
+  - task: PkgESCodeSign@10
+    displayName: 'Package ES - SignConfig.WindowsTerminal.xml'
+    inputs:
+      signConfigXml: 'build\config\SignConfig.WindowsTerminal.xml'
+      inPathRoot: '$(Build.ArtifactStagingDirectory)'
+      outPathRoot: '$(Build.ArtifactStagingDirectory)\signed'
+
+  - task: PublishBuildArtifacts@1
+    displayName: 'Publish Signed AppX'
+    inputs:
+      PathtoPublish: '$(Build.ArtifactStagingDirectory)\signed'
+      ArtifactName: 'appxbundle-signed-$(BuildConfiguration)'
--- a/build/pipelines/templates/restore-nuget-steps.yml
+++ b/build/pipelines/templates/restore-nuget-steps.yml
@@ -1,36 +0,0 @@
-steps:
- task: NuGetToolInstaller@0
-  displayName: 'Use NuGet 5.2.0'
-  inputs:
-    versionSpec: 5.2.0
-
- task: NuGetAuthenticate@0
-
-# In the Microsoft Azure DevOps tenant, NuGetCommand is ambiguous.
-# This should be `task: NuGetCommand@2`
- task: 333b11bd-d341-40d9-afcf-b32d5ce6f23b@2
-  displayName: Restore NuGet packages for extraneous build actions
-  inputs:
-    command: restore
-    feedsToUse: config
-    configPath: NuGet.config
-    restoreSolution: build/packages.config
-    restoreDirectory: '$(Build.SourcesDirectory)\packages'
-
- task: 333b11bd-d341-40d9-afcf-b32d5ce6f23b@2
-  displayName: Restore NuGet packages for solution
-  inputs:
-    command: restore
-    feedsToUse: config
-    configPath: NuGet.config
-    restoreSolution: OpenConsole.sln
-    restoreDirectory: '$(Build.SourcesDirectory)\packages'
-
- task: 333b11bd-d341-40d9-afcf-b32d5ce6f23b@2
-  displayName: Restore NuGet packages for global nuget
-  inputs:
-    command: restore
-    feedsToUse: config
-    configPath: NuGet.config
-    restoreSolution: dep/nuget/packages.config
-    restoreDirectory: '$(Build.SourcesDirectory)\packages'
--- a/build/pipelines/templates/test-console-ci.yml
+++ b/build/pipelines/templates/test-console-ci.yml
@@ -1,90 +0,0 @@
-parameters:
-  configuration: 'Release'
-  platform: ''
-  additionalBuildArguments: ''
-  artifactName: 'drop'
-  testLogPath: '$(Build.BinariesDirectory)\$(BuildPlatform)\$(BuildConfiguration)\testsOnBuildMachine.wtl'
-
-jobs:
- job: Test${{ parameters.platform }}${{ parameters.configuration }}
-  displayName: Test ${{ parameters.platform }} ${{ parameters.configuration }}
-  variables:
-    BuildConfiguration: ${{ parameters.configuration }}
-    BuildPlatform: ${{ parameters.platform }}
-  pool: 
-    ${{ if eq(variables['System.CollectionUri'], 'https://dev.azure.com/ms/') }}:
-      name: WinDevPoolOSS-L
-    ${{ if ne(variables['System.CollectionUri'], 'https://dev.azure.com/ms/') }}:
-      name: WinDevPool-L
-    demands: ImageOverride -equals WinDevVS16-latest
-
-  steps:
-  - checkout: self
-    submodules: true
-    clean: true
-    fetchDepth: 1
-
-  - task: DownloadBuildArtifacts@0
-    inputs:
-      artifactName: ${{ parameters.artifactName }}
-
-  - task: PowerShell@2
-    displayName: 'Rationalize build platform'
-    inputs:
-      targetType: inline
-      script: |
-        $Arch = "$(BuildPlatform)"
-        If ($Arch -Eq "x86") { $Arch = "Win32" }
-        Write-Host "##vso[task.setvariable variable=RationalizedBuildPlatform]${Arch}"
-
-  - task: PowerShell@2
-    displayName: 'Run Unit Tests'
-    inputs:
-      targetType: filePath
-      filePath: build\scripts\Run-Tests.ps1
-      arguments: -MatchPattern '*unit.test*.dll' -Platform '$(RationalizedBuildPlatform)' -Configuration '$(BuildConfiguration)' -LogPath '${{ parameters.testLogPath }}' -Root "$(System.ArtifactsDirectory)\\${{ parameters.artifactName }}\\$(BuildConfiguration)\\$(BuildPlatform)\\test"
-    condition: and(and(succeeded(), ne(variables['PGOBuildMode'], 'Instrument')), or(eq(variables['BuildPlatform'], 'x64'), eq(variables['BuildPlatform'], 'x86')))
-
-  - task: PowerShell@2
-    displayName: 'Run Feature Tests (x64 only)'
-    inputs:
-      targetType: filePath
-      filePath: build\scripts\Run-Tests.ps1
-      arguments: -MatchPattern '*feature.test*.dll' -Platform '$(RationalizedBuildPlatform)' -Configuration '$(BuildConfiguration)' -LogPath '${{ parameters.testLogPath }}' -Root "$(System.ArtifactsDirectory)\\${{ parameters.artifactName }}\\$(BuildConfiguration)\\$(BuildPlatform)\\test"
-    condition: and(and(succeeded(), ne(variables['PGOBuildMode'], 'Instrument')), eq(variables['BuildPlatform'], 'x64'))
-
-  - task: PowerShell@2
-    displayName: 'Convert Test Logs from WTL to xUnit format'
-    inputs:
-      targetType: filePath
-      filePath: build\Helix\ConvertWttLogToXUnit.ps1
-      arguments: -WttInputPath '${{ parameters.testLogPath }}' -WttSingleRerunInputPath 'unused.wtl' -WttMultipleRerunInputPath 'unused2.wtl' -XUnitOutputPath 'onBuildMachineResults.xml' -TestNamePrefix '$(BuildConfiguration).$(BuildPlatform)'
-    condition: and(ne(variables['PGOBuildMode'], 'Instrument'),or(eq(variables['BuildPlatform'], 'x64'), eq(variables['BuildPlatform'], 'x86')))
-
-  - task: PublishTestResults@2
-    displayName: 'Upload converted test logs'
-    condition: ne(variables['PGOBuildMode'], 'Instrument')
-    inputs:
-      testResultsFormat: 'xUnit' # Options: JUnit, NUnit, VSTest, xUnit, cTest
-      testResultsFiles: '**/onBuildMachineResults.xml'
-      #searchFolder: '$(System.DefaultWorkingDirectory)' # Optional
-      #mergeTestResults: false # Optional
-      #failTaskOnFailedTests: false # Optional
-      testRunTitle: 'On Build Machine Tests' # Optional
-      buildPlatform: $(BuildPlatform) # Optional
-      buildConfiguration: $(BuildConfiguration) # Optional
-      #publishRunAttachments: true # Optional
-
-  - task: CopyFiles@2
-    displayName: 'Copy result logs to Artifacts'
-    inputs:
-      Contents: |
-       **/*.wtl
-       **/*onBuildMachineResults.xml
-       ${{ parameters.testLogPath }}
-      TargetFolder: '$(Build.ArtifactStagingDirectory)/$(BuildConfiguration)/$(BuildPlatform)/test-logs'
-      OverWrite: true
-      flattenFolders: true
-
-  - publish: '$(Build.ArtifactStagingDirectory)/$(BuildConfiguration)/$(BuildPlatform)/test-logs'
-    artifact: TestLogs$(BuildPlatform)$(BuildConfiguration)
--- a/build/rules/GenerateFeatureFlags.proj
+++ b/build/rules/GenerateFeatureFlags.proj
@@ -63,14 +63,8 @@
    Outputs="$(OpenConsoleCommonOutDir)\inc\TilFeatureStaging.h"
    DependsOnTargets="_GenerateBranchAndBrandingCache">
    <MakeDir Directories="$(OpenConsoleCommonOutDir)\inc" />
-    <!-- This commandline is escaped like:
-
-    powershell -Command "&'$(SolutionDir)\tools\Generate-FeatureStagingHeader.ps1' -Path '%(FeatureFlagFile.FullPath)'' -Branding $(_WTBrandingName)"
-
-    which was the only way I could find to get it to obey spaces in the SolutionDir
-    -->
    <Exec
-      Command="powershell -NoLogo -NoProfile -NonInteractive -ExecutionPolicy ByPass -Command &quot;&amp;&apos;$(SolutionDir)\tools\Generate-FeatureStagingHeader.ps1&apos; -Path &apos;%(FeatureFlagFile.FullPath)&apos; -Branding $(_WTBrandingName)&quot;"
+      Command="powershell -NoLogo -NoProfile -NonInteractive -ExecutionPolicy ByPass -Command &quot;$(SolutionDir)\tools\Generate-FeatureStagingHeader.ps1&quot; -Path &quot;%(FeatureFlagFile.FullPath)&quot; -Branding $(_WTBrandingName)"
      ConsoleToMsBuild="true"
      StandardOutputImportance="low">
      <Output TaskParameter="ConsoleOutput" ItemName="_FeatureFlagFileLines" />
--- a/build/scripts/Copy-ContextMenuResourcesToCascadiaPackage.ps1
+++ b/build/scripts/Copy-ContextMenuResourcesToCascadiaPackage.ps1
@@ -1,34 +0,0 @@
-# Copyright (c) Microsoft Corporation.
-# Licensed under the MIT license.
-
-$LocalizationsFromContextMenu = Get-ChildItem ./src/cascadia/TerminalApp/Resources -Recurse -Filter ContextMenu.resw
-$Languages = [System.Collections.HashTable]::New()
-$LocalizationsFromContextMenu | ForEach-Object {
-	$Languages[$_.Directory.Name] = $_
-}
-
-ForEach ($pair in $Languages.GetEnumerator()) {
-	$LanguageDir = "./src/cascadia/CascadiaPackage/Resources/$($pair.Key)"
-	$ResPath = "$LanguageDir/Resources.resw"
-	$PreexistingResw = Get-Item $ResPath -EA:Ignore
-	If ($null -eq $PreexistingResw) {
-		Write-Host "Copying $($pair.Value.FullName) to $ResPath"
-		New-Item -type Directory $LanguageDir -EA:Ignore
-		Copy-Item $pair.Value.FullName $ResPath
-	} Else {
-		# Merge Them!
-		Write-Host "Merging $($pair.Value.FullName) into $ResPath"
-		$existingXml = [xml](Get-Content $PreexistingResw.FullName)
-		$newXml = [xml](Get-Content $pair.Value.FullName)
-		$newDataKeys = $newXml.root.data.name
-		$existingXml.root.data | % {
-			If ($_.name -in $newDataKeys) {
-				$null = $existingXml.root.RemoveChild($_)
-			}
-		}
-		$newXml.root.data | % {
-			$null = $existingXml.root.AppendChild($existingXml.ImportNode($_, $true))
-		}
-		$existingXml.Save($PreexistingResw.FullName)
-	}
-}
--- a/build/scripts/Create-AppxBundle.ps1
+++ b/build/scripts/Create-AppxBundle.ps1
@@ -22,7 +22,7 @@ Param(
    [Parameter(HelpMessage="Path to makeappx.exe")]
    [ValidateScript({Test-Path $_ -Type Leaf})]
    [string]
-    $MakeAppxPath = "C:\Program Files (x86)\Windows Kits\10\bin\10.0.22000.0\x86\MakeAppx.exe"
+    $MakeAppxPath = "C:\Program Files (x86)\Windows Kits\10\bin\10.0.17763.0\x86\MakeAppx.exe"
 )

 If ($null -Eq (Get-Item $MakeAppxPath -EA:SilentlyContinue)) {
--- a/build/scripts/Index-Pdbs.ps1
+++ b/build/scripts/Index-Pdbs.ps1
@@ -23,7 +23,6 @@ $mappedFiles = New-Object System.Collections.ArrayList

 foreach ($file in (Get-ChildItem -r:$recursive "$SearchDir\*.pdb"))
 {
-    $mappedFiles = New-Object System.Collections.ArrayList
    Write-Verbose "Found $file"

    $ErrorActionPreference = "Continue" # Azure Pipelines defaults to "Stop", continue past errors in this script.
@@ -51,7 +50,7 @@ foreach ($file in (Get-ChildItem -r:$recursive "$SearchDir\*.pdb"))
            if ($relative)
            {
                $mapping = $allFiles[$i] + "*$relative"
-                $ignore = $mappedFiles.Add($mapping)
+                $mappedFiles.Add($mapping)

                Write-Verbose "Mapped path $($i): $mapping"
            }
@@ -79,26 +78,7 @@ $($mappedFiles -join "`r`n")
 SRCSRV: end ------------------------------------------------
 "@ | Set-Content $pdbstrFile

-    Write-Host
-    Write-Host
-    Write-Host (Get-Content $pdbstrFile)
-    Write-Host
-    Write-Host
-
-    Write-Host "$pdbstrExe -p:""$file"" -w -s:srcsrv -i:$pdbstrFile"
    & $pdbstrExe -p:"$file" -w -s:srcsrv -i:$pdbstrFile
-    Write-Host
-    Write-Host
-
-    Write-Host "$pdbstrExe -p:""$file"" -r -s:srcsrv"
-    & $pdbstrExe -p:"$file" -r -s:srcsrv
-    Write-Host
-    Write-Host
-
-    Write-Host "$srctoolExe $file"
-    & $srctoolExe "$file"
-    Write-Host
-    Write-Host
 }

 # Return with exit 0 to override any weird error code from other tools
--- a/build/scripts/Install-WindowsSdkISO.ps1
+++ b/build/scripts/Install-WindowsSdkISO.ps1
@@ -1,346 +0,0 @@
-[CmdletBinding()]
-param([Parameter(Mandatory=$true, Position=0)]
-      [string]$buildNumber)
-
-# Ensure the error action preference is set to the default for PowerShell3, 'Stop'
-$ErrorActionPreference = 'Stop'
-
-# Constants
-$WindowsSDKOptions = @("OptionId.UWPCpp", "OptionId.DesktopCPPx64", "OptionId.DesktopCPPx86", "OptionId.DesktopCPPARM64", "OptionId.DesktopCPPARM", "OptionId.WindowsDesktopDebuggers")
-$WindowsSDKRegPath = "HKLM:\Software\WOW6432Node\Microsoft\Windows Kits\Installed Roots"
-$WindowsSDKRegRootKey = "KitsRoot10"
-$WindowsSDKVersion = "10.0.$buildNumber.0"
-$WindowsSDKInstalledRegPath = "$WindowsSDKRegPath\$WindowsSDKVersion\Installed Options"
-$StrongNameRegPath = "HKLM:\SOFTWARE\Microsoft\StrongName\Verification"
-$PublicKeyTokens = @("31bf3856ad364e35")
-
-if ($buildNumber -notmatch "^\d{5,}$")
-{
-    Write-Host "ERROR: '$buildNumber' doesn't look like a windows build number"
-    Write-Host
-    Exit 1
-}
-
-function Download-File
-{
-    param ([string] $outDir,
-           [string] $downloadUrl,
-           [string] $downloadName)
-
-    $downloadPath = Join-Path $outDir "$downloadName.download"
-    $downloadDest = Join-Path $outDir $downloadName
-    $downloadDestTemp = Join-Path $outDir "$downloadName.tmp"
-
-    Write-Host -NoNewline "Downloading $downloadName..."
-
-    $retries = 10
-    $downloaded = $false
-    while (-not $downloaded)
-    {
-        try
-        {
-            $webclient = new-object System.Net.WebClient
-            $webclient.DownloadFile($downloadUrl, $downloadPath)
-            $downloaded = $true
-        }
-        catch [System.Net.WebException]
-        {
-            Write-Host
-            Write-Warning "Failed to fetch updated file from $downloadUrl : $($error[0])"
-            if (!(Test-Path $downloadDest))
-            {
-                if ($retries -gt 0)
-                {
-                    Write-Host "$retries retries left, trying download again"
-                    $retries--
-                    start-sleep -Seconds 10
-                }
-                else
-                {
-                    throw "$downloadName was not found at $downloadDest"
-                }
-            }
-            else
-            {
-                Write-Warning "$downloadName may be out of date"
-            }
-        }
-    }
-
-    Unblock-File $downloadPath
-
-    $downloadDestTemp = $downloadPath;
-
-    # Delete and rename to final dest
-    Write-Host "testing $downloadDest"
-    if (Test-Path $downloadDest)
-    {
-        Write-Host "Deleting: $downloadDest"
-        Remove-Item $downloadDest -Force
-    }
-
-    Move-Item -Force $downloadDestTemp $downloadDest
-    Write-Host "Done"
-
-    return $downloadDest
-}
-
-function Get-ISODriveLetter
-{
-    param ([string] $isoPath)
-
-    $diskImage = Get-DiskImage -ImagePath $isoPath
-    if ($diskImage)
-    {
-        $volume = Get-Volume -DiskImage $diskImage
-
-        if ($volume)
-        {
-            $driveLetter = $volume.DriveLetter
-            if ($driveLetter)
-            {
-                $driveLetter += ":"
-                return $driveLetter
-            }
-        }
-    }
-
-    return $null
-}
-
-function Mount-ISO
-{
-    param ([string] $isoPath)
-
-    # Check if image is already mounted
-    $isoDrive = Get-ISODriveLetter $isoPath
-
-    if (!$isoDrive)
-    {
-        Mount-DiskImage -ImagePath $isoPath -StorageType ISO | Out-Null
-    }
-
-    $isoDrive = Get-ISODriveLetter $isoPath
-    Write-Verbose "$isoPath mounted to ${isoDrive}:"
-}
-
-function Dismount-ISO
-{
-    param ([string] $isoPath)
-
-    $isoDrive = (Get-DiskImage -ImagePath $isoPath | Get-Volume).DriveLetter
-
-    if ($isoDrive)
-    {
-        Write-Verbose "$isoPath dismounted"
-        Dismount-DiskImage -ImagePath $isoPath | Out-Null
-    }
-}
-
-function Disable-StrongName
-{
-    param ([string] $publicKeyToken = "*")
-
-    reg ADD "HKLM\SOFTWARE\Microsoft\StrongName\Verification\*,$publicKeyToken" /f | Out-Null
-    if ($env:PROCESSOR_ARCHITECTURE -eq "AMD64")
-    {
-        reg ADD "HKLM\SOFTWARE\Wow6432Node\Microsoft\StrongName\Verification\*,$publicKeyToken" /f | Out-Null
-    }
-}
-
-function Test-Admin
-{
-    $identity = [Security.Principal.WindowsIdentity]::GetCurrent()
-    $principal = New-Object Security.Principal.WindowsPrincipal $identity
-    $principal.IsInRole([Security.Principal.WindowsBuiltInRole]::Administrator)
-}
-
-function Test-RegistryPathAndValue
-{
-    param (
-        [parameter(Mandatory=$true)]
-        [ValidateNotNullOrEmpty()]
-        [string] $path,
-        [parameter(Mandatory=$true)]
-        [ValidateNotNullOrEmpty()]
-        [string] $value)
-
-    try
-    {
-        if (Test-Path $path)
-        {
-            Get-ItemProperty -Path $path | Select-Object -ExpandProperty $value -ErrorAction Stop | Out-Null
-            return $true
-        }
-    }
-    catch
-    {
-    }
-
-    return $false
-}
-
-function Test-InstallWindowsSDK
-{
-    $retval = $true
-
-    if (Test-RegistryPathAndValue -Path $WindowsSDKRegPath -Value $WindowsSDKRegRootKey)
-    {
-        # A Windows SDK is installed
-        # Is an SDK of our version installed with the options we need?
-        $allRequiredSdkOptionsInstalled = $true
-        foreach($sdkOption in $WindowsSDKOptions)
-        {
-            if (!(Test-RegistryPathAndValue -Path $WindowsSDKInstalledRegPath -Value $sdkOption))
-            {
-                $allRequiredSdkOptionsInstalled = $false
-            }
-        }
-
-        if($allRequiredSdkOptionsInstalled)
-        {
-            # It appears we have what we need. Double check the disk
-            $sdkRoot = Get-ItemProperty -Path $WindowsSDKRegPath | Select-Object -ExpandProperty $WindowsSDKRegRootKey
-            if ($sdkRoot)
-            {
-                if (Test-Path $sdkRoot)
-                {
-                    $refPath = Join-Path $sdkRoot "References\$WindowsSDKVersion"
-                    if (Test-Path $refPath)
-                    {
-                        $umdPath = Join-Path $sdkRoot "UnionMetadata\$WindowsSDKVersion"
-                        if (Test-Path $umdPath)
-                        {
-                            # Pretty sure we have what we need
-                            $retval = $false
-                        }
-                    }
-                }
-            }
-        }
-    }
-
-    return $retval
-}
-
-function Test-InstallStrongNameHijack
-{
-    foreach($publicKeyToken in $PublicKeyTokens)
-    {
-        $key = "$StrongNameRegPath\*,$publicKeyToken"
-        if (!(Test-Path $key))
-        {
-            return $true
-        }
-    }
-
-    return $false
-}
-
-Write-Host -NoNewline "Checking for installed Windows SDK $WindowsSDKVersion..."
-$InstallWindowsSDK = Test-InstallWindowsSDK
-if ($InstallWindowsSDK)
-{
-    Write-Host "Installation required"
-}
-else
-{
-    Write-Host "INSTALLED"
-}
-
-$StrongNameHijack = Test-InstallStrongNameHijack
-Write-Host -NoNewline "Checking if StrongName bypass required..."
-
-if ($StrongNameHijack)
-{
-    Write-Host "REQUIRED"
-}
-else
-{
-    Write-Host "Done"
-}
-
-if ($StrongNameHijack -or $InstallWindowsSDK)
-{
-    if (!(Test-Admin))
-    {
-        Write-Host
-        throw "ERROR: Elevation required"
-    }
-}
-
-if ($InstallWindowsSDK)
-{
-    # Static(ish) link for Windows SDK
-    # Note: there is a delay from Windows SDK announcements to availability via the static link
-    $uri = "https://software-download.microsoft.com/download/sg/Windows_InsiderPreview_SDK_en-us_$($buildNumber)_1.iso";
-
-    if ($env:TEMP -eq $null)
-    {
-        $env:TEMP = Join-Path $env:SystemDrive 'temp'
-    }
-
-    $winsdkTempDir = Join-Path (Join-Path $env:TEMP ([System.IO.Path]::GetRandomFileName())) "WindowsSDK"
-
-    if (![System.IO.Directory]::Exists($winsdkTempDir))
-    {
-        [void][System.IO.Directory]::CreateDirectory($winsdkTempDir)
-    }
-
-    $file = "winsdk_$buildNumber.iso"
-
-    Write-Verbose "Getting WinSDK from $uri"
-    $downloadFile = Download-File $winsdkTempDir $uri $file
-    Write-Verbose "File is at $downloadFile"
-    $downloadFileItem = Get-Item $downloadFile
-    
-    # Check to make sure the file is at least 10 MB.
-    if ($downloadFileItem.Length -lt 10*1024*1024)
-    {
-        Write-Host
-        Write-Host "ERROR: Downloaded file doesn't look large enough to be an ISO. The requested version may not be on microsoft.com yet."
-        Write-Host
-        Exit 1
-    }
-
-    # TODO Check if zip, exe, iso, etc.
-    try
-    {
-        Write-Host -NoNewline "Mounting ISO $file..."
-        Mount-ISO $downloadFile
-        Write-Host "Done"
-
-        $isoDrive = Get-ISODriveLetter $downloadFile
-
-        if (Test-Path $isoDrive)
-        {
-            Write-Host -NoNewLine "Installing WinSDK..."
-
-            $setupPath = Join-Path "$isoDrive" "WinSDKSetup.exe"
-            Start-Process -Wait $setupPath "/features $WindowsSDKOptions /q"
-            Write-Host "Done"
-        }
-        else
-        {
-            throw "Could not find mounted ISO at ${isoDrive}"
-        }
-    }
-    finally
-    {
-        Write-Host -NoNewline "Dismounting ISO $file..."
-        Dismount-ISO $downloadFile
-        Write-Host "Done"
-    }
-}
-
-if ($StrongNameHijack)
-{
-    Write-Host -NoNewline "Disabling StrongName for Windows SDK..."
-
-    foreach($key in $PublicKeyTokens)
-    {
-        Disable-StrongName $key
-    }
-
-    Write-Host "Done"
-}
--- a/build/scripts/Invoke-FormattingCheck.ps1
+++ b/build/scripts/Invoke-FormattingCheck.ps1
@@ -19,7 +19,7 @@ function Invoke-CheckBadCodeFormatting() {
    }

    # Manually check the formatting of our .xaml files, without touching them.
-    Test-XamlFormat
+    Verify-XamlFormat

 }

--- a/build/scripts/Patch-ManifestsToWindowsVersion.ps1
+++ b/build/scripts/Patch-ManifestsToWindowsVersion.ps1
@@ -1,14 +0,0 @@
-# Copyright (c) Microsoft Corporation.
-# Licensed under the MIT license.
-
-Param(
-	[string]$NewWindowsVersion = "10.0.22000.0"
-)
-
-Get-ChildItem src/cascadia/CascadiaPackage -Recurse -Filter *.appxmanifest | ForEach-Object {
-	$xml = [xml](Get-Content $_.FullName)
-	$xml.Package.Dependencies.TargetDeviceFamily | Where-Object Name -Like "Windows*" | ForEach-Object {
-		$_.MinVersion = $NewWindowsVersion
-	}
-	$xml.Save($_.FullName)
-}
--- a/build/scripts/Run-Tests.ps1
+++ b/build/scripts/Run-Tests.ps1
@@ -3,11 +3,10 @@ Param(
    [Parameter(Mandatory=$true, Position=0)][string]$MatchPattern,
    [Parameter(Mandatory=$true, Position=1)][string]$Platform,
    [Parameter(Mandatory=$true, Position=2)][string]$Configuration,
-    [Parameter(Mandatory=$false, Position=3)][string]$LogPath,
-    [Parameter(Mandatory=$false)][string]$Root = ".\bin\$Platform\$Configuration"
+    [Parameter(Mandatory=$false, Position=3)][string]$LogPath
 )

-$testdlls = Get-ChildItem -Path "$Root" -Recurse -Filter $MatchPattern
+$testdlls = Get-ChildItem -Path ".\bin\$Platform\$Configuration" -Recurse -Filter $MatchPattern


 $args = @();
@@ -20,7 +19,7 @@ if ($LogPath)
    Write-Host "Wtt Logging Enabled";
 }

-&"$Root\te.exe" $args $testdlls.FullName
+&".\bin\$Platform\$Configuration\te.exe" $args $testdlls.FullName

 if ($lastexitcode -Ne 0) { Exit $lastexitcode }

--- a/build/scripts/Test-WindowsTerminalPackage.ps1
+++ b/build/scripts/Test-WindowsTerminalPackage.ps1
@@ -8,7 +8,7 @@ Param(
    [Parameter(HelpMessage="Path to Windows Kit")]
    [ValidateScript({Test-Path $_ -Type Leaf})]
    [string]
-    $WindowsKitPath = "C:\Program Files (x86)\Windows Kits\10\bin\10.0.22000.0"
+    $WindowsKitPath = "C:\Program Files (x86)\Windows Kits\10\bin\10.0.18362.0"
 )

 $ErrorActionPreference = "Stop"
--- a/common.openconsole.props
+++ b/common.openconsole.props
@@ -10,22 +10,4 @@
    <OpenConsoleDir>$(MSBuildThisFileDirectory)</OpenConsoleDir>
  </PropertyGroup>

-  <PropertyGroup>
-    <!--
-    For the Windows 10 build, we're targeting the prerelease version of Microsoft.UI.Xaml.
-    This version emits every XAML DLL directly into our package.
-    This is a workaround for us not having deliverable MSFT-21242953 on this version of Windows.
-
-    This version should be tracked in all project packages.config files for projects that depend on Xaml.
-    -->
-    <TerminalMUXVersion>2.7.0-prerelease.210913003</TerminalMUXVersion>
-    <!--
-    For the Windows 11-specific build, we're targeting the public version of Microsoft.UI.Xaml.
-    This version emits a package dependency instead of embedding the dependency in our own package.
-
-    This version should be tracked in build/packages.config.
-    -->
-    <TerminalMUXVersion Condition="'$(TerminalTargetWindowsVersion)'=='Win11'">2.7.0</TerminalMUXVersion>
-  </PropertyGroup>
-
 </Project>
--- a/consolegit2gitfilters.json
+++ b/consolegit2gitfilters.json
@@ -24,8 +24,6 @@
    "/doc/cascadia/",
    "/doc/user-docs/",
    "/src/tools/MonarchPeasantSample/",
-    "/scratch/",
-    "Scratch.sln",
  ],
  "SuffixFilters": [
    ".dbb",
--- a/custom.props
+++ b/custom.props
@@ -2,22 +2,10 @@
 <Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <!-- This file is read by XES, which we use in our Release builds. -->
  <PropertyGroup Label="Version">
-    <!--
-      The Windows 11 build is going to have the same package name, so it *must* have a different version.
-      The easiest way for us to do this is to add 1 to the revision field.
-      In short, for a given Terminal build 1.11, we will emit two different versions (assume this is build
-      4 on day 23 of the year):
-        - 1.11.234.0 for Windows 10
-        - 1.11.235.0 for Windows 11
-      This presents a potential for conflicts if we want to ship two builds produced back to back on the
-      same day... which is terribly unlikely.
-    -->
-    <VersionBuildRevision Condition="'$(TerminalTargetWindowsVersion)'=='Win11' and '$(VersionBuildRevision)'!=''">$([MSBuild]::Add($(VersionBuildRevision), 1))</VersionBuildRevision>
-
    <XesUseOneStoreVersioning>true</XesUseOneStoreVersioning>
-    <XesBaseYearForStoreVersion>2022</XesBaseYearForStoreVersion>
+    <XesBaseYearForStoreVersion>2021</XesBaseYearForStoreVersion>
    <VersionMajor>1</VersionMajor>
-    <VersionMinor>14</VersionMinor>
+    <VersionMinor>8</VersionMinor>
    <VersionInfoProductName>Windows Terminal</VersionInfoProductName>
  </PropertyGroup>
 </Project>
--- a/dep/CLI11/CLI11.hpp
+++ b/dep/CLI11/CLI11.hpp
@@ -1,11 +1,11 @@
 #pragma once

-// CLI11: Version 1.9.1
+// CLI11: Version 1.9.0
 // Originally designed by Henry Schreiner
 // https://github.com/CLIUtils/CLI11
 //
 // This is a standalone header file generated by MakeSingleHeader.py in CLI11/scripts
-// from: v1.9.1
+// from: v1.9.0
 //
 // From LICENSE:
 //
@@ -60,14 +60,14 @@
 #include <utility>
 #include <vector>

-// Verbatim copy from Version.hpp:
+// Verbatim copy from CLI/Version.hpp:

 #define CLI11_VERSION_MAJOR 1
 #define CLI11_VERSION_MINOR 9
-#define CLI11_VERSION_PATCH 1
-#define CLI11_VERSION "1.9.1"
+#define CLI11_VERSION_PATCH 0
+#define CLI11_VERSION "1.9.0"

-// Verbatim copy from Macros.hpp:
+// Verbatim copy from CLI/Macros.hpp:

 // The following version macro is very similar to the one in PyBind11
 #if !(defined(_MSC_VER) && __cplusplus == 199711L) && !defined(__INTEL_COMPILER)
@@ -102,7 +102,7 @@
 #define CLI11_DEPRECATED(reason) __attribute__((deprecated(reason)))
 #endif

-// Verbatim copy from Validators.hpp:
+// Verbatim copy from CLI/Validators.hpp:

 // C standard library
 // Only needed for existence checking
@@ -114,14 +114,7 @@
 #else
 #include <filesystem>
 #if defined __cpp_lib_filesystem && __cpp_lib_filesystem >= 201703
-#if defined _GLIBCXX_RELEASE && _GLIBCXX_RELEASE >= 9
 #define CLI11_HAS_FILESYSTEM 1
-#elif defined(__GLIBCXX__)
-// if we are using gcc and Version <9 default to no filesystem
-#define CLI11_HAS_FILESYSTEM 0
-#else
-#define CLI11_HAS_FILESYSTEM 1
-#endif
 #else
 #define CLI11_HAS_FILESYSTEM 0
 #endif
@@ -136,11 +129,11 @@
 #include <sys/types.h>
 #endif

-// From Version.hpp:
+// From CLI/Version.hpp:

-// From Macros.hpp:
+// From CLI/Macros.hpp:

-// From StringTools.hpp:
+// From CLI/StringTools.hpp:

 namespace CLI
 {
@@ -577,7 +570,7 @@ namespace CLI

 } // namespace CLI

-// From Error.hpp:
+// From CLI/Error.hpp:

 namespace CLI
 {
@@ -851,11 +844,11 @@ public:
    {
        CLI11_ERROR_DEF(ParseError, ArgumentMismatch)
        CLI11_ERROR_SIMPLE(ArgumentMismatch)
-        ArgumentMismatch(std::string name, int expected, std::size_t received) :
+        ArgumentMismatch(std::string name, int expected, std::size_t recieved) :
            ArgumentMismatch(expected > 0 ? ("Expected exactly " + std::to_string(expected) + " arguments to " + name +
-                                             ", got " + std::to_string(received)) :
+                                             ", got " + std::to_string(recieved)) :
                                            ("Expected at least " + std::to_string(-expected) + " arguments to " + name +
-                                             ", got " + std::to_string(received)),
+                                             ", got " + std::to_string(recieved)),
                             ExitCodes::ArgumentMismatch) {}

        static ArgumentMismatch AtLeast(std::string name, int num, std::size_t received)
@@ -956,7 +949,7 @@ public:

 } // namespace CLI

-// From TypeTools.hpp:
+// From CLI/TypeTools.hpp:

 namespace CLI
 {
@@ -1244,26 +1237,16 @@ namespace CLI
        };

        /// Convert an object to a string (directly forward if this can become a string)
-        template<typename T, enable_if_t<std::is_convertible<T, std::string>::value, detail::enabler> = detail::dummy>
+        template<typename T, enable_if_t<std::is_constructible<std::string, T>::value, detail::enabler> = detail::dummy>
        auto to_string(T&& value) -> decltype(std::forward<T>(value))
        {
            return std::forward<T>(value);
        }

-        /// Construct a string from the object
-        template<typename T,
-                 enable_if_t<std::is_constructible<std::string, T>::value && !std::is_convertible<T, std::string>::value,
-                             detail::enabler> = detail::dummy>
-        std::string to_string(const T& value)
-        {
-            return std::string(value);
-        }
-
        /// Convert an object to a string (streaming must be supported for that type)
        template<typename T,
-                 enable_if_t<!std::is_convertible<std::string, T>::value && !std::is_constructible<std::string, T>::value &&
-                                 is_ostreamable<T>::value,
-                             detail::enabler> = detail::dummy>
+                 enable_if_t<!std::is_constructible<std::string, T>::value && is_ostreamable<T>::value, detail::enabler> =
+                     detail::dummy>
        std::string to_string(T&& value)
        {
            std::stringstream stream;
@@ -1641,7 +1624,7 @@ namespace CLI
        // Lexical cast

        /// Convert a flag into an integer value  typically binary flags
-        inline std::int64_t to_flag_value(std::string val)
+        inline int64_t to_flag_value(std::string val)
        {
            static const std::string trueString("true");
            static const std::string falseString("false");
@@ -1654,12 +1637,12 @@ namespace CLI
                return -1;
            }
            val = detail::to_lower(val);
-            std::int64_t ret;
+            int64_t ret;
            if (val.size() == 1)
            {
                if (val[0] >= '1' && val[0] <= '9')
                {
-                    return (static_cast<std::int64_t>(val[0]) - '0');
+                    return (static_cast<int64_t>(val[0]) - '0');
                }
                switch (val[0])
                {
@@ -2144,7 +2127,7 @@ namespace CLI
                 enable_if_t<std::is_integral<T>::value && std::is_unsigned<T>::value, detail::enabler> = detail::dummy>
        void sum_flag_vector(const std::vector<std::string>& flags, T& output)
        {
-            std::int64_t count{ 0 };
+            int64_t count{ 0 };
            for (auto& flag : flags)
            {
                count += detail::to_flag_value(flag);
@@ -2161,7 +2144,7 @@ namespace CLI
                 enable_if_t<std::is_integral<T>::value && std::is_signed<T>::value, detail::enabler> = detail::dummy>
        void sum_flag_vector(const std::vector<std::string>& flags, T& output)
        {
-            std::int64_t count{ 0 };
+            int64_t count{ 0 };
            for (auto& flag : flags)
            {
                count += detail::to_flag_value(flag);
@@ -2172,7 +2155,7 @@ namespace CLI
    } // namespace detail
 } // namespace CLI

-// From Split.hpp:
+// From CLI/Split.hpp:

 namespace CLI
 {
@@ -2324,7 +2307,7 @@ namespace CLI
    } // namespace detail
 } // namespace CLI

-// From ConfigFwd.hpp:
+// From CLI/ConfigFwd.hpp:

 namespace CLI
 {
@@ -2453,7 +2436,7 @@ namespace CLI
    };
 } // namespace CLI

-// From Validators.hpp:
+// From CLI/Validators.hpp:

 namespace CLI
 {
@@ -2521,7 +2504,7 @@ namespace CLI
                }
            }
            return retstring;
-        }
+        };

        /// This is the required operator for a Validator - provided to help
        /// users (CLI11 uses the member `func` directly)
@@ -2529,7 +2512,7 @@ namespace CLI
        {
            std::string value = str;
            return (active_) ? func_(value) : std::string{};
-        }
+        };

        /// Specify the type string
        Validator& description(std::string validator_desc)
@@ -2593,14 +2576,14 @@ namespace CLI
        {
            application_index_ = app_index;
            return *this;
-        }
+        };
        /// Specify the application index of a validator
        Validator application_index(int app_index) const
        {
            Validator newval(*this);
            newval.application_index_ = app_index;
            return newval;
-        }
+        };
        /// Get the current value of the application index
        int get_application_index() const { return application_index_; }
        /// Get a boolean if the validator is active
@@ -2716,7 +2699,7 @@ namespace CLI
        /// CLI enumeration of different file types
        enum class path_type
        {
-            nonexistent,
+            nonexistant,
            file,
            directory
        };
@@ -2729,13 +2712,13 @@ namespace CLI
            auto stat = std::filesystem::status(file, ec);
            if (ec)
            {
-                return path_type::nonexistent;
+                return path_type::nonexistant;
            }
            switch (stat.type())
            {
            case std::filesystem::file_type::none:
            case std::filesystem::file_type::not_found:
-                return path_type::nonexistent;
+                return path_type::nonexistant;
            case std::filesystem::file_type::directory:
                return path_type::directory;
            case std::filesystem::file_type::symlink:
@@ -2766,7 +2749,7 @@ namespace CLI
                return ((buffer.st_mode & S_IFDIR) != 0) ? path_type::directory : path_type::file;
            }
 #endif
-            return path_type::nonexistent;
+            return path_type::nonexistant;
        }
 #endif
        /// Check for an existing file (returns error message if check fails)
@@ -2778,7 +2761,7 @@ namespace CLI
            {
                func_ = [](std::string& filename) {
                    auto path_result = check_path(filename.c_str());
-                    if (path_result == path_type::nonexistent)
+                    if (path_result == path_type::nonexistant)
                    {
                        return "File does not exist: " + filename;
                    }
@@ -2800,7 +2783,7 @@ namespace CLI
            {
                func_ = [](std::string& filename) {
                    auto path_result = check_path(filename.c_str());
-                    if (path_result == path_type::nonexistent)
+                    if (path_result == path_type::nonexistant)
                    {
                        return "Directory does not exist: " + filename;
                    }
@@ -2822,7 +2805,7 @@ namespace CLI
            {
                func_ = [](std::string& filename) {
                    auto path_result = check_path(filename.c_str());
-                    if (path_result == path_type::nonexistent)
+                    if (path_result == path_type::nonexistant)
                    {
                        return "Path does not exist: " + filename;
                    }
@@ -2840,7 +2823,7 @@ namespace CLI
            {
                func_ = [](std::string& filename) {
                    auto path_result = check_path(filename.c_str());
-                    if (path_result != path_type::nonexistent)
+                    if (path_result != path_type::nonexistant)
                    {
                        return "Path already exists: " + filename;
                    }
@@ -3327,7 +3310,7 @@ namespace CLI
            // if the type does not have first_type and second_type, these are both value_type
            using element_t = typename detail::element_type<T>::type; // Removes (smart) pointers if needed
            using item_t = typename detail::pair_adaptor<element_t>::first_type; // Is value_type if not a map
-            using local_item_t = typename IsMemberType<item_t>::type; // Will convert bad types to good ones
+            using local_item_t = typename IsMemberType<item_t>::type; // This will convert bad types to good ones
                // (const char * to std::string)

            // Make a local copy of the filter function, using a std::function if not one already
@@ -3398,9 +3381,10 @@ namespace CLI
            // if the type does not have first_type and second_type, these are both value_type
            using element_t = typename detail::element_type<T>::type; // Removes (smart) pointers if needed
            using item_t = typename detail::pair_adaptor<element_t>::first_type; // Is value_type if not a map
-            using local_item_t = typename IsMemberType<item_t>::type; // Will convert bad types to good ones
+            using local_item_t = typename IsMemberType<item_t>::type; // This will convert bad types to good ones
                // (const char * to std::string)
-            using iteration_type_t = typename detail::pair_adaptor<element_t>::value_type; // the type of the object pair
+            using iteration_type_t = typename detail::pair_adaptor<element_t>::value_type; // the type of the object pair //
+                // the type of the object pair

            // Make a local copy of the filter function, using a std::function if not one already
            std::function<local_item_t(local_item_t)> filter_fn = filter_function;
@@ -3641,7 +3625,7 @@ namespace CLI
    class AsSizeValue : public AsNumberWithUnit
    {
    public:
-        using result_t = std::uint64_t;
+        using result_t = uint64_t;

        /// If kb_is_1000 is true,
        /// interpret 'kb', 'k' as 1000 and 'kib', 'ki' as 1024
@@ -3737,7 +3721,7 @@ namespace CLI

 } // namespace CLI

-// From FormatterFwd.hpp:
+// From CLI/FormatterFwd.hpp:

 namespace CLI
 {
@@ -3751,9 +3735,9 @@ namespace CLI

    enum class AppFormatMode
    {
-        Normal, ///< The normal, detailed help
-        All, ///< A fully expanded help
-        Sub, ///< Used when printed as part of expanded subcommand
+        Normal, //< The normal, detailed help
+        All, //< A fully expanded help
+        Sub, //< Used when printed as part of expanded subcommand
    };

    /// This is the minimum requirements to run a formatter.
@@ -3913,7 +3897,7 @@ namespace CLI

 } // namespace CLI

-// From Option.hpp:
+// From CLI/Option.hpp:

 namespace CLI
 {
@@ -4457,7 +4441,7 @@ namespace CLI
        template<typename T = App>
        Option* needs(std::string opt_name)
        {
-            auto opt = static_cast<T*>(parent_)->get_option_no_throw(opt_name);
+            auto opt = dynamic_cast<T*>(parent_)->get_option_no_throw(opt_name);
            if (opt == nullptr)
            {
                throw IncorrectConstruction::MissingOption(opt_name);
@@ -4508,7 +4492,7 @@ namespace CLI
        template<typename T = App>
        Option* excludes(std::string opt_name)
        {
-            auto opt = static_cast<T*>(parent_)->get_option_no_throw(opt_name);
+            auto opt = dynamic_cast<T*>(parent_)->get_option_no_throw(opt_name);
            if (opt == nullptr)
            {
                throw IncorrectConstruction::MissingOption(opt_name);
@@ -4554,7 +4538,7 @@ namespace CLI
            if (!ignore_case_ && value)
            {
                ignore_case_ = value;
-                auto* parent = static_cast<T*>(parent_);
+                auto* parent = dynamic_cast<T*>(parent_);
                for (const Option_p& opt : parent->options_)
                {
                    if (opt.get() == this)
@@ -4586,7 +4570,7 @@ namespace CLI
            if (!ignore_underscore_ && value)
            {
                ignore_underscore_ = value;
-                auto* parent = static_cast<T*>(parent_);
+                auto* parent = dynamic_cast<T*>(parent_);
                for (const Option_p& opt : parent->options_)
                {
                    if (opt.get() == this)
@@ -4714,9 +4698,9 @@ namespace CLI
        /// Will include / prefer the positional name if positional is true.
        /// If all_options is false, pick just the most descriptive name to show.
        /// Use `get_name(true)` to get the positional name (replaces `get_pname`)
-        std::string get_name(bool positional = false, ///< Show the positional name
-                             bool all_options = false ///< Show every option
-        ) const
+        std::string get_name(bool positional = false, //<[input] Show the positional name
+                             bool all_options = false //<[input] Show every option
+                             ) const
        {
            if (get_group().empty())
                return {}; // Hidden
@@ -5016,7 +5000,7 @@ namespace CLI
                {
                    if (!default_str_.empty())
                    {
-                        // _add_results takes an rvalue only
+                        //_add_results takes an rvalue only
                        _add_result(std::string(default_str_), res);
                        _validate_results(res);
                        results_t extra;
@@ -5395,7 +5379,7 @@ namespace CLI

 } // namespace CLI

-// From App.hpp:
+// From CLI/App.hpp:

 namespace CLI
 {
@@ -6237,9 +6221,8 @@ namespace CLI
        }

        /// Vector version to capture multiple flags.
-        template<
-            typename T,
-            enable_if_t<!std::is_assignable<std::function<void(std::int64_t)>, T>::value, detail::enabler> = detail::dummy>
+        template<typename T,
+                 enable_if_t<!std::is_assignable<std::function<void(int64_t)>, T>::value, detail::enabler> = detail::dummy>
        Option* add_flag(std::string flag_name,
                         std::vector<T>& flag_results, ///< A vector of values with the flag results
                         std::string flag_description = "")
@@ -6277,11 +6260,11 @@ namespace CLI

        /// Add option for callback with an integer value
        Option* add_flag_function(std::string flag_name,
-                                  std::function<void(std::int64_t)> function, ///< A function to call, void(int)
+                                  std::function<void(int64_t)> function, ///< A function to call, void(int)
                                  std::string flag_description = "")
        {
            CLI::callback_t fun = [function](const CLI::results_t& res) {
-                std::int64_t flag_count = 0;
+                int64_t flag_count = 0;
                detail::sum_flag_vector(res, flag_count);
                function(flag_count);
                return true;
@@ -6293,7 +6276,7 @@ namespace CLI
 #ifdef CLI11_CPP14
        /// Add option for callback (C++14 or better only)
        Option* add_flag(std::string flag_name,
-                         std::function<void(std::int64_t)> function, ///< A function to call, void(std::int64_t)
+                         std::function<void(int64_t)> function, ///< A function to call, void(int64_t)
                         std::string flag_description = "")
        {
            return add_flag_function(std::move(flag_name), std::move(function), std::move(flag_description));
@@ -6469,7 +6452,7 @@ namespace CLI
        template<typename T = Option_group>
        T* add_option_group(std::string group_name, std::string group_description = "")
        {
-            auto option_group = std::make_shared<T>(std::move(group_description), group_name, this);
+            auto option_group = std::make_shared<T>(std::move(group_description), group_name, nullptr);
            auto ptr = option_group.get();
            // move to App_p for overload resolution on older gcc versions
            App_p app_ptr = std::dynamic_pointer_cast<App>(option_group);
@@ -6478,7 +6461,7 @@ namespace CLI
        }

        ///@}
-        /// @name Subcommands
+        /// @name Subcommmands
        ///@{

        /// Add a subcommand. Inherits INHERITABLE and OptionDefaults, and help flag
@@ -6854,16 +6837,16 @@ namespace CLI
        int exit(const Error& e, std::ostream& out = std::cout, std::ostream& err = std::cerr) const
        {
            /// Avoid printing anything if this is a CLI::RuntimeError
-            if (e.get_name() == "RuntimeError")
+            if (dynamic_cast<const CLI::RuntimeError*>(&e) != nullptr)
                return e.get_exit_code();

-            if (e.get_name() == "CallForHelp")
+            if (dynamic_cast<const CLI::CallForHelp*>(&e) != nullptr)
            {
                out << help();
                return e.get_exit_code();
            }

-            if (e.get_name() == "CallForAllHelp")
+            if (dynamic_cast<const CLI::CallForAllHelp*>(&e) != nullptr)
            {
                out << help("", AppFormatMode::All);
                return e.get_exit_code();
@@ -7097,12 +7080,7 @@ namespace CLI
        /// Access the config formatter as a configBase pointer
        std::shared_ptr<ConfigBase> get_config_formatter_base() const
        {
-            // This is safer as a dynamic_cast if we have RTTI, as Config -> ConfigBase
-#if defined(__cpp_rtti) || (defined(__GXX_RTTI) && __GXX_RTTI) || (defined(_HAS_STATIC_RTTI) && (_HAS_STATIC_RTTI == 0))
            return std::dynamic_pointer_cast<ConfigBase>(config_formatter_);
-#else
-            return std::static_pointer_cast<ConfigBase>(config_formatter_);
-#endif
        }

        /// Get the app or subcommand description
@@ -8930,21 +8908,6 @@ namespace CLI
        /// This class is simply to allow tests access to App's protected functions
        struct AppFriend
        {
-#ifdef CLI11_CPP14
-            /// Wrap _parse_short, perfectly forward arguments and return
-            template<typename... Args>
-            static decltype(auto) parse_arg(App* app, Args&&... args)
-            {
-                return app->_parse_arg(std::forward<Args>(args)...);
-            }
-
-            /// Wrap _parse_subcommand, perfectly forward arguments and return
-            template<typename... Args>
-            static decltype(auto) parse_subcommand(App* app, Args&&... args)
-            {
-                return app->_parse_subcommand(std::forward<Args>(args)...);
-            }
-#else
            /// Wrap _parse_short, perfectly forward arguments and return
            template<typename... Args>
            static auto parse_arg(App* app, Args&&... args) ->
@@ -8960,7 +8923,6 @@ namespace CLI
            {
                return app->_parse_subcommand(std::forward<Args>(args)...);
            }
-#endif
            /// Wrap the fallthrough parent function to make sure that is working correctly
            static App* get_fallthrough_parent(App* app) { return app->_get_fallthrough_parent(); }
        };
@@ -8968,7 +8930,7 @@ namespace CLI

 } // namespace CLI

-// From Config.hpp:
+// From CLI/Config.hpp:

 namespace CLI
 {
@@ -9398,7 +9360,7 @@ namespace CLI

 } // namespace CLI

-// From Formatter.hpp:
+// From CLI/Formatter.hpp:

 namespace CLI
 {
--- a/dep/CLI11/README.md
+++ b/dep/CLI11/README.md
@@ -1,4 +1,5 @@
 # CLI11

-Taken from [release v1.9.1](https://github.com/CLIUtils/CLI11/releases/tag/v1.9.1), source commit
-[5cb3efa](https://github.com/CLIUtils/CLI11/commit/5cb3efabce007c3a0230e4cc2e27da491c646b6c)
+Taken from [release v1.9.0](https://github.com/CLIUtils/CLI11/releases/tag/v1.9.0), source commit
+[dd0d8e4](https://github.com/CLIUtils/CLI11/commit/dd0d8e4fe729e5b1110232c7a5c9566dad884686)
+
--- a/dep/Console/conapi.h
+++ b/dep/Console/conapi.h
@@ -1,6 +1,5 @@
 /*++
-Copyright (c) Microsoft Corporation.
-Licensed under the MIT license.
+Copyright (c) Microsoft Corporation

 Module Name:
 - conapi.h
--- a/dep/Console/condrv.h
+++ b/dep/Console/condrv.h
@@ -1,7 +1,6 @@
 /*++

 Copyright (c) Microsoft Corporation. All rights reserved.
-Licensed under the MIT license.

 Module Name:

--- a/dep/Console/conmsgl1.h
+++ b/dep/Console/conmsgl1.h
@@ -1,7 +1,6 @@
 /*++

 Copyright (c) Microsoft Corporation. All rights reserved.
-Licensed under the MIT license.

 Module Name:

--- a/dep/Console/conmsgl2.h
+++ b/dep/Console/conmsgl2.h
@@ -1,7 +1,6 @@
 /*++

 Copyright (c) Microsoft Corporation. All rights reserved.
-Licensed under the MIT license.

 Module Name:

--- a/dep/Console/conmsgl3.h
+++ b/dep/Console/conmsgl3.h
@@ -1,7 +1,6 @@
 /*++

-Copyright (c) 1985 - 1999, Microsoft Corporation.
-Licensed under the MIT license.
+Copyright (c) 1985 - 1999, Microsoft Corporation

 Module Name:

--- a/dep/Console/ntcon.h
+++ b/dep/Console/ntcon.h
@@ -1,6 +1,5 @@
 //
 //    Copyright (C) Microsoft.  All rights reserved.
-//    Licensed under the MIT license.
 //
 #ifndef _NTCON_
 #define _NTCON_
--- a/dep/Console/winconp.h
+++ b/dep/Console/winconp.h
@@ -1,7 +1,3 @@
-/*++
-Copyright (c) Microsoft Corporation.
-Licensed under the MIT license.
--*/

 #ifndef _WINCONP_
 #define _WINCONP_
--- a/dep/NT/ntioapi_x.h
+++ b/dep/NT/ntioapi_x.h
@@ -1,8 +1,3 @@
-/*++
-Copyright (c) Microsoft Corporation.
-Licensed under the MIT license.
--*/
-
 #pragma once

 #define FILE_SYNCHRONOUS_IO_NONALERT            0x00000020
--- a/dep/Win32K/winuserp.h
+++ b/dep/Win32K/winuserp.h
@@ -1,7 +1,4 @@
 /*
- * Copyright (c) Microsoft Corporation.
- * Licensed under the MIT license.
- *
 * Reserved console space.
 *
 * This was moved from the console code so that we can localize it
--- a/dep/nuget/packages.config
+++ b/dep/nuget/packages.config
@@ -1,22 +0,0 @@
-<?xml version="1.0" encoding="utf-8"?>
-<!-- The packages.config acts as the global version for all of the NuGet packages contained within. -->
-<packages>
-  <!-- Native packages -->
-  <package id="Microsoft.Toolkit.Win32.UI.XamlApplication" version="6.1.3" targetFramework="native" />
-  <package id="Microsoft.Internal.PGO-Helpers.Cpp" version="0.2.34" targetFramework="native" />
-  <package id="Microsoft.Taef" version="10.60.210621002" targetFramework="native" />
-  <package id="Microsoft.Windows.CppWinRT" version="2.0.210825.3" targetFramework="native" />
-  <package id="vcpkg-cpprestsdk" version="2.10.14" targetFramework="native" />
-  <package id="Microsoft.VCRTForwarders.140" version="1.0.4" targetFramework="native" />
-  <package id="Microsoft.Internal.Windows.Terminal.ThemeHelpers" version="0.6.220404001" targetFramework="native" />
-  <package id="Microsoft.VisualStudio.Setup.Configuration.Native" version="2.3.2262" targetFramework="native" developmentDependency="true" />
-  <package id="Microsoft.UI.Xaml" version="2.7.0-prerelease.210913003" targetFramework="native" />
-  <package id="Microsoft.Windows.ImplementationLibrary" version="1.0.220201.1" targetFramework="native" developmentDependency="true" />
-
-  <!-- Managed packages -->
-  <package id="Appium.WebDriver" version="3.0.0.2" targetFramework="net45" />
-  <package id="Castle.Core" version="4.1.1" targetFramework="net45" />
-  <package id="Newtonsoft.Json" version="12.0.3" targetFramework="net45" />
-  <package id="Selenium.Support" version="3.5.0" targetFramework="net45" />
-  <package id="Selenium.WebDriver" version="3.5.0" targetFramework="net45" />
-</packages>
--- a/dep/wil
+++ b/dep/wil
--- a/doc/EXCEPTIONS.md
+++ b/doc/EXCEPTIONS.md
@@ -4,7 +4,7 @@
 Introducing exceptions to an existing non-exception-based codebase can be perilous. The console was originally written
 in C at a time when C++ was relatively unused in the Windows operating system. As part of our project to modernize the
 Windows console, we converted to use C++, but still had an aversion to using exception-based error handling in
-our code for fear that it might introduce unexpected failures. However, the STL and other libraries like it are so useful that
+our code for fear that it introduce unexpected failures. However, the STL and other libraries like it are so useful that
 sometimes it's significantly simpler to use them. Given that, we have a set of rules that we follow when considering
 exception use.

--- a/doc/Niksa.md
+++ b/doc/Niksa.md
@@ -163,7 +163,7 @@ Given that we're using Xaml islands to host a modern UI and stitching a DirectX

 Now, the obvious followup question is _"why can't you have one elevated connection in a tab next to a non-elevated connection?"_ This is where @sba923 should pick up reading (:smile:). I'm probably going to cover some things that you (@robomac) know already.

-[2] When you have two windows on the same desktop in the same window station, they can communicate with each other. I can use `SendKeys` easily through `WScript.Shell` to send keyboard input to any window that the shell can see.
+[2] When you have two windows on the same desktop in the same window station, they can communicate with eachother. I can use `SendKeys` easily through `WScript.Shell` to send keyboard input to any window that the shell can see.

 Running a process elevated _severs_ that connection. The shell can't see the elevated window. No other program at the same integrity level as the shell can see the elevated window. Even if it has its window handle, it can't really interact with it. This is also why you can't drag/drop from explorer into notepad if notepad is running elevated. Only another elevated process can interact with another elevated window.

@@ -189,7 +189,7 @@ I think there might be a bit of a misunderstanding here - there are two differen
 * shell applications, like `cmd.exe`, `powershell`, `zsh`, etc. These are text-only applications that emit streams of characters. They don't care at all about how they're eventually rendered to the user. These are also sometimes referred to as "commandline client" applications.
 * terminal applications, like the Windows Terminal, gnome-terminal, xterm, iterm2, hyper. These are graphical applications that can be used to render the output of commandline clients. 

-On Windows, if you just run `cmd.exe` directly, the OS will create an instance of `conhost.exe` as the _terminal_ for `cmd.exe`. The same thing happens for `powershell.exe`, the system will create a new conhost window for any client that's not already connected to a terminal of some sort. This has lead to an enormous amount of confusion for people thinking that a conhost window is actually a "`cmd` window". `cmd` can't have a window, it's just a commandline application. Its window is always some other terminal.
+On Windows, if you just run `cmd.exe` directly, the OS will create an instance of `conhost.exe` as the _terminal_ for `cmd.exe`. The same thing happens for `powershell.exe`, the system will creates a new conhost window for any client that's not already connected to a terminal of some sort. This has lead to an enormous amount of confusion for people thinking that a conhost window is actually a "`cmd` window". `cmd` can't have a window, it's just a commandline application. Its window is always some other terminal.

 Any terminal can run any commandline client application. So you can use the Windows Terminal to run whatever shell you want. I use mine for both `cmd` and `powershell`, and also WSL:

--- a/doc/TAEF.md
+++ b/doc/TAEF.md
@@ -16,7 +16,7 @@ If you have Visual Studio and related C++ components installed, and you have suc

 > Note that you cannot easily run TAEF tests directly through Visual Studio. The `Microsoft.Taef` NuGet package comes with an adapter that will let you browse and execute TAEF tests inside of Visual Studio, but its performance and reliability prevent us from recommending it here.

-In a "normal" CMD environment, `te.exe` may not be directly available. Try the following command to set up the development environment first:
+In a "normal" CMD environment, `te.exe` may not be directly available. Try the following command to set up the development enviroment first:

 ```shell
 .\tools\razzle.cmd
--- a/doc/bot.md
+++ b/doc/bot.md
@@ -127,4 +127,4 @@ When a release is created, if the PR ID number is linked inside the release desc
 - Issue message: 🎉This issue was addressed in #{pull request ID}, which has now been successfully released as {release name} {release version}.🎉"

 ## Admin Panel
-[Here](https://portal.fabricbot.ms/bot/?repo=microsoft/terminal)
+[Here](https://fabric-cp.azurewebsites.net/bot/)
--- a/doc/building.md
+++ b/doc/building.md
@@ -9,13 +9,7 @@ git submodule update --init --recursive

 OpenConsole.sln may be built from within Visual Studio or from the command-line using a set of convenience scripts & tools in the **/tools** directory:

-When using Visual Studio, be sure to set up the path for code formatting. To download the required clang-format.exe file, follow one of the building instructions below and run:
-```powershell
-Import-Module .\tools\OpenConsole.psm1
-Set-MsBuildDevEnvironment
-Get-Format
-```
-After, go to Tools > Options > Text Editor > C++ > Formatting and check "Use custom clang-format.exe file" in Visual Studio and choose the clang-format.exe in the repository at /packages/clang-format.win-x86.10.0.0/tools/clang-format.exe by clicking "browse" right under the check box.
+When using Visual Studio, be sure to set up the path for code formatting. This can be done in Visual Studio by going to Tools > Options > Text Editor > C++ > Formatting and checking "Use custom clang-format.exe file" and choosing the clang-format.exe in the repository at /dep/llvm/clang-format.exe by clicking "browse" right under the check box.

 ### Building in PowerShell

@@ -64,16 +58,7 @@ Openconsole has three configuration types:

 AuditMode is an experimental mode that enables some additional static analysis from CppCoreCheck.

-## Updating Nuget package references - Globally versioned
-Most Nuget package references in this project are centralized in a single configuration so that there is a single canonical version for everything.  This canonical version is restored before builds by the build pipeline, environment initialization scripts, or Visual Studio (as appropriate).
-
-The canonical version numbers are defined in dep/nuget/packages.config.  That defines what will be downloaded by nuget.exe.  Most Nuget packages also have a .props and/or .targets file that must be imported by every project that consumes it.  Those import statements are consolidated in:
- src/common.nugetversions.props
- src/common.nugetversions.targets
-
-When a globally managed version changes all three of those files must be changed in unison.
-
-## Updating Nuget package references - Locally versioned
+## Updating Nuget package references
 Certain Nuget package references in this project, like `Microsoft.UI.Xaml`, must be updated outside of the Visual Studio NuGet package manager. This can be done using the snippet below.
 > Note that to run this snippet, you need to use WSL as the command uses `sed`.
 To update the version of a given package, use the following snippet
@@ -96,46 +81,3 @@ If you want to use .nupkg files instead of the downloaded Nuget package, you can
 2. Create the folder /dep/packages
 3. Put your .nupkg files in /dep/packages
 4. If you are using different versions than those already being used, you need to update the references as well. How to do that is explained under "Updating Nuget package references".
-
-
-## Building the Terminal package from the commandline
-
-The Terminal is bundled as an `.msix`, which is produced by the `CascadiaPackage.wapproj` project. To build that project from the commandline, you can run the following (from a window you've already run `tools\razzle.cmd` in):
-
-```cmd
-"%msbuild%" "%OPENCON%\OpenConsole.sln" /p:Configuration=%_LAST_BUILD_CONF% /p:Platform=%ARCH% /p:AppxSymbolPackageEnabled=false /t:Terminal\CascadiaPackage /m
-```
-
-This takes quite some time, and only generates an `msix`. It does not install the msix. To deploy the package:
-
-```powershell
-# If you haven't already:
-Import-Module tools\OpenConsole.psm1;
-Set-MsBuildDevEnvironment;
-
-# The Set-MsBuildDevEnvironment call is needed for finding the path to
-# makeappx. It also takes a little longer to run. If you're sticking in powershell, best to do that.
-
-Set-Location -Path src\cascadia\CascadiaPackage\AppPackages\CascadiaPackage_0.0.1.0_x64_Debug_Test;
-if ((Get-AppxPackage -Name 'WindowsTerminalDev*') -ne $null) {
-Remove-AppxPackage 'WindowsTerminalDev_0.0.1.0_x64__8wekyb3d8bbwe'
-};
-New-Item ..\loose -Type Directory -Force;
-makeappx unpack /v /o /p .\CascadiaPackage_0.0.1.0_x64_Debug.msix /d ..\Loose\;
-Add-AppxPackage -Path ..\loose\AppxManifest.xml -Register -ForceUpdateFromAnyVersion -ForceApplicationShutdown
-```
-
-Or the cmd.exe version:
-```cmd
-@rem razzle.cmd doesn't set:
-@rem set WindowsSdkDir=C:\Program Files (x86)\Windows Kits\10\
-@rem vsdevcmd.bat does a lot of logic to find that.
-@rem
-@rem I'm gonna hard code it below:
-
-powershell -Command Set-Location -Path %OPENCON%\src\cascadia\CascadiaPackage\AppPackages\CascadiaPackage_0.0.1.0_x64_Debug_Test;if ((Get-AppxPackage -Name 'WindowsTerminalDev*') -ne $null) { Remove-AppxPackage 'WindowsTerminalDev_0.0.1.0_x64__8wekyb3d8bbwe'};New-Item ..\loose -Type Directory -Force;C:\'Program Files (x86)'\'Windows Kits'\10\bin\10.0.19041.0\x64\makeappx unpack /v /o /p .\CascadiaPackage_0.0.1.0_x64_Debug.msix /d ..\Loose\;Add-AppxPackage -Path ..\loose\AppxManifest.xml -Register -ForceUpdateFromAnyVersion -ForceApplicationShutdown
-```
-
-(yes, the cmd version is just calling powershell to do the powershell version. Too lazy to convert the rest by hand, I'm already copying from `.vscode\tasks.json`)
-
-Building the package from VS generates the loose layout to begin with, and then registers the loose manifest, skipping the msix stop. It's a lot faster than the commandline inner loop here, unfortunately.
--- a/doc/cascadia/AddASetting.md
+++ b/doc/cascadia/AddASetting.md
@@ -6,9 +6,9 @@ Adding a setting to Windows Terminal is fairly straightforward. This guide serve

 The Terminal Settings Model (`Microsoft.Terminal.Settings.Model`) is responsible for (de)serializing and exposing settings.

-### `INHERITABLE_SETTING` macro
+### `GETSET_SETTING` macro

-The `INHERITABLE_SETTING` macro can be used to implement inheritance for your new setting and store the setting in the settings model. It takes three parameters:
+The `GETSET_SETTING` macro can be used to implement inheritance for your new setting and store the setting in the settings model. It takes three parameters:
 - `type`: the type that the setting will be stored as
 - `name`: the name of the variable for storage
 - `defaultValue`: the value to use if the user does not define the setting anywhere
@@ -20,7 +20,7 @@ This tutorial will add `CloseOnExitMode CloseOnExit` as a profile setting.
 1. In `Profile.h`, declare/define the setting:

 ```c++
-INHERITABLE_SETTING(CloseOnExitMode, CloseOnExit, CloseOnExitMode::Graceful)
+GETSET_SETTING(CloseOnExitMode, CloseOnExit, CloseOnExitMode::Graceful)
 ```

 2. In `Profile.idl`, expose the setting via WinRT:
@@ -141,7 +141,7 @@ struct OpenSettingsArgs : public OpenSettingsArgsT<OpenSettingsArgs>
    OpenSettingsArgs() = default;

    // adds a getter/setter for your argument, and defines the json key
-    WINRT_PROPERTY(SettingsTarget, Target, SettingsTarget::SettingsFile);
+    GETSET_PROPERTY(SettingsTarget, Target, SettingsTarget::SettingsFile);
    static constexpr std::string_view TargetKey{ "target" };

    public:
@@ -213,9 +213,9 @@ Terminal-level settings are settings that affect a shell session. Generally, the
 - Declare the setting in `IControlSettings.idl` or `ICoreSettings.idl` (whichever is relevant to your setting). If your setting is an enum setting, declare the enum here instead of in the `TerminalSettingsModel` project.
 - In `TerminalSettings.h`, declare/define the setting...
 ```c++
-// The WINRT_PROPERTY macro declares/defines a getter setter for the setting.
-// Like INHERITABLE_SETTING, it takes in a type, name, and defaultValue.
-WINRT_PROPERTY(bool, UseAcrylic, false);
+// The GETSET_PROPERTY macro declares/defines a getter setter for the setting.
+// Like GETSET_SETTING, it takes in a type, name, and defaultValue.
+GETSET_PROPERTY(bool, UseAcrylic, false);
 ```
 - In `TerminalSettings.cpp`...
  - update `_ApplyProfileSettings` for profile settings
--- a/doc/cascadia/Unittesting-CppWinRT-Xaml.md
+++ b/doc/cascadia/Unittesting-CppWinRT-Xaml.md
@@ -268,7 +268,7 @@ this:
  </ItemDefinitionGroup>
 ```

-Again, verify the correct paths to your dependent C++/WinRT dlls, as they may be
+Again, verify the correct paths to your dependant C++/WinRT dlls, as they may be
 different than the above

 #### Activating the manifest from TAEF
@@ -380,7 +380,7 @@ Here's the AppxManifest we're using:
  </Properties>

  <Dependencies>
-    <TargetDeviceFamily Name="Windows.Universal" MinVersion="10.0.18362.0" MaxVersionTested="10.0.22000.0" />
+    <TargetDeviceFamily Name="Windows.Universal" MinVersion="10.0.18362.0" MaxVersionTested="10.0.18362.0" />
    <PackageDependency Name="Microsoft.VCLibs.140.00.Debug" MinVersion="14.0.27023.1" Publisher="CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US" />
    <PackageDependency Name="Microsoft.VCLibs.140.00.Debug.UWPDesktop" MinVersion="14.0.27027.1" Publisher="CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US" />
  </Dependencies>
@@ -517,7 +517,7 @@ This is because of a few key lines we already put in the appxmanifest:

 ```xml
  <Dependencies>
-    <TargetDeviceFamily Name="Windows.Universal" MinVersion="10.0.18362.0" MaxVersionTested="10.0.22000.0" />
+    <TargetDeviceFamily Name="Windows.Universal" MinVersion="10.0.18362.0" MaxVersionTested="10.0.18362.0" />
    <PackageDependency Name="Microsoft.VCLibs.140.00.Debug" MinVersion="14.0.27023.1" Publisher="CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US" />
    <PackageDependency Name="Microsoft.VCLibs.140.00.Debug.UWPDesktop" MinVersion="14.0.27027.1" Publisher="CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US" />
  </Dependencies>
--- a/doc/cascadia/profiles.schema.json
+++ b/doc/cascadia/profiles.schema.json
--- a/doc/fuzzing.md
+++ b/doc/fuzzing.md
@@ -1,60 +0,0 @@
-# Fuzzing
-
-## Setting up a fuzzer locally
-
-OpenConsole can be built with a `Fuzzing` configuration. To set up a fuzzer, you'll need an `LLVMFuzzerTestOneInput` function. This serves as a way for the fuzzer to attach itself and inject tests into your fuzz target.
-
-To build the fuzzer locally, build the OpenConsole solution in the `Fuzzing` configuration. This should output an executable that runs the fuzzer on the provided test case. In the case of PR #9604, the desired executable is located at `bin\x64\Fuzzing\OpenConsoleFuzzer.exe`.
-
-### Resources
- [LibFuzzer Docs](https://www.llvm.org/docs/LibFuzzer.html)
- [#9604](https://github.com/microsoft/terminal/pull/9604)
-
-## Setting up OneFuzz
-
-OneFuzz allows us to run our fuzzers in CI and be alerted of new bugs found in this endeavor.
-
-### Installing OneFuzz
-
-You can download the latest OneFuzz CLI on their [releases page](https://github.com/microsoft/onefuzz/releases).
-
-### Configuring OneFuzz
-
-To run OneFuzz locally, you'll need to configure its endpoint, client ID, and client secret. Windows has a preset configuration available; this can be found at [this tutorial](https://www.osgwiki.com/wiki/Fuzzing_Service_-_Azure_Edge_and_Platform#Configure_OneFuzz_CLI) on osgwiki. 
-
-
-
-`onefuzz config --endpoint $(endpoint) --client_id $(client_id) --authority $(authority) --tenant_domain $(tenant_domain)`
-
-**NOTE**: Our pipeline is already set up with these variables, so you don't need to worry about this when running this on Azure DevOps.
-
-### Running a job on OneFuzz
-
-You should now be able to run a job using the following command:
-
-`onefuzz template libfuzzer basic <project> <name> <build> <pool> --target_exe <exe_path>`
-
- `project`: the name of the project
- `name`: the name of the test
- `build`: the identifier for the build (i.e. commit SHA1)
- `pool`: the VM pool to run this on
- `exe_path`: the fuzzer executable output from building your project
-
-This should also output more information (i.e. job ID) about the newly created job in a JSON format.
-
-### Enabling notifications
-
-**NOTE**: Our pipeline is already set up with this functionality. However, here is a quick guide on how to get it set up and modify it to our liking.
-
-OneFuzz supports multiple notification systems at once including MS Teams and Azure DevOps. See the resources below to learn more about setting these up.
-
-Our pipeline has been set up to create Azure DevOps work items.
-
-### Resources
- [OneFuzz GitHub](https://github.com/microsoft/onefuzz)
-    - [Getting started using OneFuzz](https://github.com/microsoft/onefuzz/blob/main/docs/getting-started.md)
-    - [Releases Page](https://github.com/microsoft/onefuzz/releases)
- [Notifications](https://github.com/microsoft/onefuzz/blob/main/docs/notifications.md)
-    - [MS Teams](https://github.com/microsoft/onefuzz/blob/main/docs/notifications/teams.md)
-    - [Azure DevOps](https://github.com/microsoft/onefuzz/blob/main/docs/notifications/ado.md)
- [OSG Wiki - OneFuzz](https://www.osgwiki.com/wiki/Fuzzing_Service_-_Azure_Edge_and_Platform)
--- a/doc/roadmap-2022.md
+++ b/doc/roadmap-2022.md
@@ -1,72 +0,0 @@
-# Terminal 2022 Roadmap
-
-## Overview 
-
-This document outlines the roadmap of features we're planning for the Windows Terminal during 2022. This serves as a successor to the [Terminal v2 Roadmap], to reflect changes to our planning going forward.
-
-Initially we had planned on a discrete "Terminal v2" goal, but over the last 18 months it's become clear to the team that we don't need a strict "2.0" release. We can continue serving the community effectively with continual, incremental updates. Should a future release warrant a substantial change to the Terminal worthy of the "2.0" moniker, we can re-evaluate then.
-
-In 2022, we're going to try tracking our overall work with two "semester" milestones, "[22H1]" and "[22H2]", which roughly align with internal deadlines. Although the Windows Terminal ships updates out-of-band from the rest of the OS, we still have commitments to fixing bugs in the broader console ecosystem. Those changes need to be made in sync with the rest of the OS. Aligning our external milestones with those deadlines should help make sure we get bugs resolved in a timely fashion and checked into the OS.
-
-These have additionally inherited the remainder of the work that was originally targeting the Terminal v2 milestone. As we burn down the features and bugs in these milestones, we'll draw new features into them from the "[Up Next]" milestone, which is itself populated from the highest-priority elements of the [Backlog].
-
-## Milestones
-
-Windows Terminal is engineered and delivered as a set of 6-week milestones. New features will go into [Windows Terminal Preview](https://aka.ms/terminal-preview) first, then a month after they've been in Preview, those features will move into [Windows Terminal](https://aka.ms/terminal). These timelines are rough estimates, not strict rules.
-
-## Terminal Roadmap / Timeline
-
-Below is the schedule for when milestones will be included in release builds of Windows Terminal and Windows Terminal Preview. The dates are rough estimates and are subject to change.
-
-
-| Milestone End Date | Milestone Name | Preview Release Blog Post |
-| ------------------ | -------------- | ------------------------- |
-| 2020-06-18 | [1.1] in Windows Terminal Preview | [Windows Terminal Preview 1.1 Release](https://devblogs.microsoft.com/commandline/windows-terminal-preview-1-1-release/) |
-| 2020-07-31 | [1.2] in Windows Terminal Preview<br>[1.1] in Windows Terminal | [Windows Terminal Preview 1.2 Release](https://devblogs.microsoft.com/commandline/windows-terminal-preview-1-2-release/) |
-| 2020-08-31 | [1.3] in Windows Terminal Preview<br>[1.2] in Windows Terminal | [Windows Terminal Preview 1.3 Release](https://devblogs.microsoft.com/commandline/windows-terminal-preview-1-3-release/) |
-| 2020-09-30 | [1.4] in Windows Terminal Preview<br>[1.3] in Windows Terminal | [Windows Terminal Preview 1.4 Release](https://devblogs.microsoft.com/commandline/windows-terminal-preview-1-4-release/) |
-| 2020-11-30 | [1.5] in Windows Terminal Preview<br>[1.4] in Windows Terminal | [Windows Terminal Preview 1.5 Release](https://devblogs.microsoft.com/commandline/windows-terminal-preview-1-5-release/) |
-| 2021-01-31 | [1.6] in Windows Terminal Preview<br>[1.5] in Windows Terminal | [Windows Terminal Preview 1.6 Release](https://devblogs.microsoft.com/commandline/windows-terminal-preview-1-6-release/) |
-| 2021-03-01 | [1.7] in Windows Terminal Preview<br>[1.6] in Windows Terminal | [Windows Terminal Preview 1.7 Release](https://devblogs.microsoft.com/commandline/windows-terminal-preview-1-7-release/) |
-| 2021-04-14 | [1.8] in Windows Terminal Preview<br>[1.7] in Windows Terminal | [Windows Terminal Preview 1.8 Release](https://devblogs.microsoft.com/commandline/windows-terminal-preview-1-8-release/) |
-| 2021-05-31 | [1.9] in Windows Terminal Preview<br>[1.8] in Windows Terminal | [Windows Terminal Preview 1.9 Release](https://devblogs.microsoft.com/commandline/windows-terminal-preview-1-9-release/) |
-| 2021-07-14 | [1.10] in Windows Terminal Preview<br>[1.9] in Windows Terminal | [Windows Terminal Preview 1.10 Release](https://devblogs.microsoft.com/commandline/windows-terminal-preview-1-10-release/) |
-| 2021-08-31 | [1.11] in Windows Terminal Preview<br>[1.10] in Windows Terminal | [Windows Terminal Preview 1.11 Release](https://devblogs.microsoft.com/commandline/windows-terminal-preview-1-11-release/) |
-| 2021-10-20 | [1.12] in Windows Terminal Preview<br>[1.11] in Windows Terminal | [Windows Terminal Preview 1.12 Release](https://devblogs.microsoft.com/commandline/windows-terminal-preview-1-12-release/) |
-|  | [1.13] in Windows Terminal Preview<br>[1.12] in Windows Terminal |  |
-|  | [1.14] in Windows Terminal Preview<br>[1.13] in Windows Terminal |  |
-
-
-## Issue Triage & Prioritization
-
-Incoming issues/asks/etc. are triaged several times a week, labeled appropriately, and assigned to a milestone in priority order:
-
-* P0 (serious crashes, data loss, etc.) issues are scheduled to be dealt with ASAP. These go in the current release milestone (e.g. at time of writing, these would go into 1.13).
-* P1 issues/features/asks are typically assigned to the current or the following release milestone.
-* P2 & P3 issues will typically go in the second semester for the year.
-* Accessibility and Console issues that need to go into the Windows OS typically go into the current semester.
-* Issues/features/asks not related to existing features in the 22H1/22H2 semesters are assigned to the [Backlog] for subsequent triage, prioritization & scheduling.
-
-
-[1.1]: https://github.com/microsoft/terminal/milestone/24
-[1.2]: https://github.com/microsoft/terminal/milestone/25
-[1.3]: https://github.com/microsoft/terminal/milestone/26
-[1.4]: https://github.com/microsoft/terminal/milestone/28
-[1.5]: https://github.com/microsoft/terminal/milestone/30
-[1.6]: https://github.com/microsoft/terminal/milestone/31
-[1.7]: https://github.com/microsoft/terminal/milestone/32
-[1.8]: https://github.com/microsoft/terminal/milestone/33
-[1.9]: https://github.com/microsoft/terminal/milestone/34
-[1.10]: https://github.com/microsoft/terminal/milestone/35
-[1.11]: https://github.com/microsoft/terminal/milestone/36
-[1.12]: https://github.com/microsoft/terminal/milestone/38
-[1.13]: https://github.com/microsoft/terminal/milestone/39
-[1.14]: https://github.com/microsoft/terminal/milestone/41
-
-
-[22H1]: https://github.com/microsoft/terminal/milestone/43
-[22H2]: https://github.com/microsoft/terminal/milestone/44
-[Up Next]: https://github.com/microsoft/terminal/milestone/37
-[Backlog]: https://github.com/microsoft/terminal/milestone/45
-
-[Terminal v2 Roadmap]: https://github.com/microsoft/terminal/tree/main/doc/terminal-v2-roadmap.md
--- a/Terminal/spec.md
+++ b/Terminal/spec.md
@@ -9,7 +9,7 @@ issue id: #1043

 ## Abstract

-This spec is for task #1043 “Be able to set an initial position for the terminal”. It goes over the details of a new feature that allows users to set the initial position and size of the terminal. Expected behavior and design of this feature is included. Besides, future possible follow-up works are also addressed.
+This spec is for task #1043 “Be able to set an initial position for the terminal”. It goes over the details of a new feature that allows users to set the initial position and size of the terminal. Expected behavior and design of this feature is included. Besides, future possible follow-up works are also addressed.

 ## Inspiration

@@ -17,7 +17,7 @@ The idea is to allow users to set the initial position of the Terminal when they

 ## Solution Design

-For now, the Terminal window is put on a default initial position. The program uses CW_USEDEFAULT in the screen coordinates for top-left corner. We have two different types of window – client window and non-client window. However, code path for window creation (WM_CREATE message is shared by the two types of windows) are almost the same for the two types of windows, except that there are some differences in calculation of the width and height of the window.
+For now, the Terminal window is put on a default initial position. The program uses CW_USEDEFAULT in the screen coordinates for top-left corner. We have two different types of window – client window and non-client window. However, code path for window creation (WM_CREATE message is shared by the two types of windows) are almost the same for the two types of windows, except that there are some differences in calculation of the width and height of the window.

 Two new properties should be added in the json settings file:

@@ -92,9 +92,9 @@ For now, this feature only allows the user to set initial position and choose wh

 3. We may also consider more launch modes. Like full screen mode and minimized mode. 

-GitHub issue for future follow-ups: https://github.com/microsoft/terminal/issues/766
+Github issue for future follow-ups: https://github.com/microsoft/terminal/issues/766

 ## Resources

-GitHub issue:
+Github issue:
 https://github.com/microsoft/terminal/issues/1043
--- a/doc/specs/#1790
+++ b/doc/specs/#1790
@@ -1,105 +0,0 @@
---
-author: Pankaj Bhojwani, pabhojwa@microsoft.com
-created on: 2021-6-17
-last updated: 2021-6-23
-issue id: #1790
---
-
-# Font features and axes of variation
-
-## Abstract
-
-This spec outlines how we can allow users to specify font features and axes of variation for fonts in Windows Terminal. Font features include things like being able to specify whether ligatures should be used as well as the specific stylistic set used for a font. Axes of variation commonly include things like weight and slant but can also include fancier things like shadow distance, depending on the font.
-
-## Inspiration
-
-Reference: [#1790](https://github.com/microsoft/terminal/issues/1790)
-
-Currently, if a font has ligatures, we offer no way for a user to disable them. Many users would like the option to do so, and would also like the ability to choose stylistic sets for fonts - for example, at the time of this writing, Cascadia Code offers 4 stylistic sets but we offer no way for users to specify any of them.
-
-In a similar vein, many fonts allow for setting variations on the font along certain attributes, commonly referred to as 'axes of variation'. We can offer users more font customization options by allowing them to configure these font variations.
-
-## Solution Design
-
-### Font features
-
-It is already possible to pass in a list of [font feature structs](https://docs.microsoft.com/en-us/windows/win32/api/dwrite/ns-dwrite-dwrite_font_feature) to DWrite for it to handle. A font feature struct contains only 2 things: 
-
-1. A font feature tag
-2. A parameter value
-
-A font feature tag is constructed using a 4-character feature tag and the parameter value defines how the feature is applied. For most features, the parameter value is simply treated as a binary value - a value of 0 means the feature is not applied and a non-zero value means the feature is applied. For example, a font feature struct like {'ss03', 1} enables stylistic set 3 for the font and a font feature struct like {'liga', 0} disables ligatures. (Technically, the feature tag is _constructed_ with the 4-character tag and is not the 4-character tag itself, but they are treated the same in the example here for brevity's sake).
-
-Currently, we pass in to DWrite a null value for the list of features to apply to the font. This causes DWrite to automatically apply a ['standard' list](https://github.com/fdwr/TextLayoutSampler/blob/master/DrawableObject.ixx#L802) of font features to the font. Naturally, passing in our own list of font features to DWrite means DWrite will _only_ apply the features we defined, and no longer apply the standard list. Since the standard list contains 11 features, we need to consider how we can allow users to specify 1 additional feature or delete 1 of the standard features without needing to redefine all the others.
-
-We will do this by allowing users to define a dictionary in their settings.json file, where the keys are the 4-character feature tags and the values are the parameter values. This dictionary will then get applied to our internal dictionary (which will contain the standard list of 11 features with their parameter values), meaning that any new key-value pairs will get added to our dictionary and any existing key-value pairs will get updated. Finally, this 'merged' dictionary will be what we use to construct the list of features to pass into DWrite.
-
-### Axes of variation
-
-Specifying axes of variation is done in an extremely similar manner to the way font features are specified - a 4-character tag is used to specify which font axis is being modified and a numerical value is provided to specify the value the axis should be set to. For example, {'slnt', 20} specifies that the 'slant' axis should be set to 20.
-
-There is also a standard list of axes of variation, and each axis has its own default. We will approach this the same way we approached font features, by allowing users to specify additional features or omit features without needing to redefine the defaults.
-
-## UI/UX Design
-
-Users will be able to add a new setting to their font objects (added in [#10433](https://github.com/microsoft/terminal/pull/10433)). The resultant font object may look something like this
-
-```json
-"font": {
-    "face": "Cascadia Code",
-    "size": 12,
-    "features": {
-        "ss03": 1,
-        "liga": 0
-    },
-    "axes": {
-        "slnt": 20.5
-    }
-}
-```
-There is one point to note here about clashing. For example, if a user has the old "weight" setting defined _as well as_ a "wght" axis defined, we will only use the "wght" axis value. We prioritize that value for a few reasons:
-
-1. It is the more recent addition to our settings model. Thus, it is likely that a user that has defined both values probably just forgot to remove the old value.
-2. It is the more precise value, it is a specific float value whereas the the old "weight" setting is an enum (that eventually gets mapped to a float value).
-
-## Capabilities
-
-### Accessibility
-
-Should not affect accessibility.
-
-### Security
-
-Should not affect security.
-
-### Reliability
-
-Aside from additional parsing required for the settings file (which inherently offers more locations for parsing to fail), we need to be careful about badly formed/non-existent feature tags or axes specified in the user-defined dictionaries. We must make sure to ignore such declarations (perhaps alongside emitting a warning to the user) and only apply those that are correctly formed and exist.
-
-### Compatibility
-
-Older versions of Windows may not have the DWrite updates that allow for defining font features and axes of variation. We must make sure to fallback to the current implementation in these cases.
-
-### Performance, Power, and Efficiency
-
-Currently when rendering a run of text, if we detect that the given run is simple we will use a shortcut to obtain the glyphs needed, skipping over an expensive `GetGlyphs` call to DWrite. However, when the default feature list is changed in any way (either by adding a new feature or removing one of the defaults), there is no way for us to detect beforehand how the font glyphs would change.
-
-This means that as long as the user requests a change to the default font feature list, we will _always_ skip the shortcut and call the expensive `GetGlyphs` function for every run of text.
-
-This will naturally cause a performance cost that we will have to bear for this feature. However, it is worth noting that there are a fair number of glyphs that will cause a run of text to be deemed "not simple" (and thus cause us to call `GetGlyphs` anyway), for example when using Cascadia Code, any run of text that has the letters 'i', 'j', 'l', 'n', 'w' or 'x' is not considered simple (because those glyphs have localized variants).
-
-## Potential Issues
-
-See performance issues above.
-
-## Future considerations
-
-DWrite additionally offers the ability to vary the font features across runs of text. However, for our initial implementation of this feature, we will only apply font features to the entire buffer. If/when we decide to allow specifying font features for particular runs of text, we can lean into our existing mechanisms of splitting up runs of text to implement that.
-
-We will also need to consider how we want to represent this in the settings UI. This is slightly more complex than other settings since users should be allowed to manually input 4-character tags.
-
-## Resources
-
-[DWRITE_FONT_FEATURE structure](https://docs.microsoft.com/en-us/windows/win32/api/dwrite/ns-dwrite-dwrite_font_feature)
-
-[DWRITE_FONT_AXIS_VALUE structure](https://docs.microsoft.com/en-us/windows/win32/api/dwrite_3/ns-dwrite_3-dwrite_font_axis_value)
--- a/Navigation/#2871
+++ b/Navigation/#2871
@@ -241,7 +241,7 @@ So `focusPane(target=1, direction=up)` will attempt to focus the pane above pane

 > 👉 **NOTE**: At this point, the author considered "Do we even want a separate
 > action to engage the tab switcher with panes expanded?" Perhaps panes being
-> visible in the tab switcher is just part of the tab switcher's behavior. Maybe
+> visible in the tab switcher is just part fo the tab switcher's behavior. Maybe
 > there shouldn't be a separate "open the tab switcher with the panes expanded
 > to the pane I'm currently on, and the panes listed in MRU order" action.

--- a/Terminal/spec.md
+++ b/Terminal/spec.md
@@ -1,270 +0,0 @@
---
-author: Michael Niksa @miniksa
-created on: 2020-08-14
-last updated: 2022-01-13
-issue id: #492
---
-
-# Default Terminal Choice in Windows OS
-
-## Abstract
-
-Since the beginning, Windows has offered a single choice in default terminal hosting behavior. Specifically, the default terminal is defined as the one that the operating system will start on your behalf when a command-line application is started without a terminal attached. This specification intends to detail how we will offer customers the ultimate in choice among first and third party replacements for their default terminal experience.
-
-## Inspiration
-
-We've had a lot of success in the past several years on our terminal team journey. We updated the old console host user interface with long-desired features. We updated the console environment to bring Windows closer to Linux and Mac by implementing the client (receiving) end of Virtual Terminal sequences to unlock WSL, Docker, and other cross-platform command-line application compatibility. We then created the ConPTY to expose the server end of the console environment to first and third party applications to enable the hosting of any of those command-line clients within their own user interfaces by implementing the server (sending) end of Virtual Terminal sequences. And then we built Windows Terminal as our flagship implementation of the development environment on this model.
-
-Through all of this, the entrypoint for alternatives to the console host UX continued to be "Start your alternative terminal implementation first, then start the command-line application inside." For those familiar with Linux and Mac or for those using the broad ecosystem of alternative Windows Terminals like ConEmu, Cmder, Console2, and the like... that was natural. But Windows did it differently a long time ago allowing the starting of a command-line application directly from the shell or kernel without a terminal specified. On noticing the missing terminal, the system would just-in-time start and attach the one terminal it could count on as always present, `conhost.exe`.
-
-And so the inspiration of this is simple: We want to allow our customers to choose whichever terminal they want as the just-in-time terminal attached to an application without one present/specified on launch. This final move completes our journey to allow the ultimate in choice AND decouple the terminal experience from the operating system release schedule.
-
-## Solution Design
-
-There are three components to the proposed design:
-
-1. **Inbox console**: This is the `conhost.exe` that is resident inside every Windows installation.
-1. **Updated console**: This is the `openconsole.exe` that we ship with the Windows Terminal to provide a more up-to-date console server experience.
-1. **Terminal UX**: This is `WindowsTerminal.exe`, the new Terminal user interface that runs on VT sequences.
-
-And there are a few scenarios here to consider:
-
-1. Replacement console API server and replacement terminal UX.
-    1. This is the Windows Terminal scenario today. `OpenConsole.exe` is packed in the package to be the console API server and ConPTY environment for `WindowsTerminal.exe`.
-1. Replacement console API server and legacy terminal UX.
-    1. We don't explicitly distribute this today, but it's technically possible to just run `OpenConsole.exe` to accomplish this.
-1. Inbox console API server and replacement terminal UX.
-    1. The WSL environment does this when doing Windows interop and I believe VS Code does this too when told to use the ConPTY environment. (And since VS Code does it, anything using node-pty also does it, covering some 3rd party terminals as well).
-1. Inbox console API server and inbox terminal UX.
-    1. This is what we have today in `conhost.exe` running as the default application.
-
-The goal is to offer the ultimate in choice here where any of the components can be replaced as necessary for a 1st or 3rd party scenario.
-
-### Overview
-
-#### Inbox console
-
-The inbox console will be updated to support delegation of the incoming console client application connection to another console API server if one is registered and available.
-
-We leave the inbox console in-place and always available on the operating system for these reasons:
-
-1. A last chance fall-back should any of the delegation operations fail
-1. An ongoing host for applications that aren't going to need a window at all
-1. Continued support of our legacy `conhostv1.dll` environment, if chosen
-
-The general operation is as follows:
-
- A command-line client application is started (from the start menu, run box, or any other `CreateProcess` or `ShellExecute` route) without an existing console server attached
- The inbox console is launched from `C:\windows\system32\conhost.exe` as always by the initialization routines inside `kernelbase.dll`.
- The inbox console accepts the incoming initial connection and looks for the `ShowWindow` information on the connection packet, as received from the kernel's process creation routines based on the parameters given to the `CreateProcess` call. (See [CREATE_NO_WINDOW](https://docs.microsoft.com/en-us/windows/win32/procthread/process-creation-flags) flag for details.)
- If the session is about to create a window, check for registration of a delegated/updated console and hand-off to it if it exists.
- Otherwise, start normally.
-
-This workflow affords us several benefits:
-
- The only inbox component we have to change is `conhost.exe`, the one we already regularly update from open source on a regular basis. There is no change to the `kernelbase.dll` console initialization routines, `conclnt.lib` communication protocol, nor the `condrv.sys` driver.
- We should be able to make this change quickly, relatively easily, and the code delta should be relatively small
-    - This makes it easy to squeeze in early in the development of the solution and get it into the Windows OS product as soon as possible for self-hosting, validation, and potentially shipping in the OS before the remainder of the solution has shaken out
-    - This also makes it potentially possible to backport this portion of the code change to popular in-market versions of Windows 10. For instance, WSL2 has just backported to 1903 and 1909. The less churn and risk, the easier it is to sell a backport.
-
-*Potential future:*
- ~~If no updated console exists, potentially check for registration of a terminal UX that is willing to use the inbox ConPTY bits, start it, and transition to being a PTY instead.~~ 
- **CUT FROM v1**: To simplify the story for end-users, we're offering this as a package deal in the first revision. Explaining the difference between consoles and terminals to end users is very difficult.
-
-The registration would operate as follows:
- A registry key in `HKCU\Console\%%Startup` (format `REG_SZ`, name `DelegationConsole`) would specify ~~the path to ~~the replacement console that would be used to service the remainder of the connection process.
-    - Alternatively or additionally, this same `REG_SZ` could list a COM server ID that could be looked up in the classes root and invoked. **V1 NOTE:** This was what was done.
-        - Packaged applications and classic applications can easily register a COM server
-        - WinRT libraries should be able to be easily registered as the COM server as well (given WinRT is COM underneath)
-            - WinRT cannot be exposed outside of the package context itself, so the `conhost.exe` that is in the OS and is naturally outside the package cannot find it.
-    - **V1 NOTE:** The subkey `%%Startup` was chosen to separate these keys (this one and the `DelegationTerminal` one below) in case we needed to ACL them or protect them in some way. We want a per-user choice of which Terminal/Console are used, but we might need to take action to prevent these keys from being slammed at some point in the future. Why `%%`? The subkeys are traditionally used to resolve paths to client binaries that have their own console preferences set. The `%%` should never be resolvable as it won't lead to a valid path or expanded path variable.
-
-The delegation process would operate as follows:
- A method contract is established between the existing inbox console and any updated console (an interface). 
-    - `HRESULT ConsoleEstablishHandoff(HANDLE server, HANDLE driverInputEvent, const PortableConnectMessage* const msg, HANDLE signalPipe, HANDLE inboxProcess, HANDLE* process)`
-        - `HANDLE server`: This is the server side handle to the console driver, used with `DeviceIoControl` to receive/send messages with the client command-line application
-        - `HANDLE driverInputEvent`: The input event is created and assigned to the driver immediately on first connection, before any messages are read from the driver, to ensure that it can track a blocking state should first message be an input request that we do not yet have data to fill. As such, the inbox console will have created this and assigned it to the driver before pulling off the connection packet and determining that it wants to delegate. Therefore, we will transfer ownership of this event to the updated console.
-        - ~~`const PortableArguments* const args`: This contains the startup argument information that was passed in when the process was started including the original command line and the in/out handles.~~
-            - ~~The `ConsoleArguments` structure could technically change between versions, so we will make a version agnostic portable structure that just carries the communication from the old one to the new one.~~
-            - **CUT FROM V1**: The only arguments coming in from a default light-up are the server handle. Pretty much all the other arguments are related to the operation of the PTY. Since this feature is about "default application" launches where no arguments are specified, this was cut from the initial revision.
-        - `const PortableConnectMessage* const msg`:
-            - The `CONSOLE_API_MSG` structure contains both the actual packet data from the driver as well as some overhead/administration data related to the packet state, ordering, completion, errors, and buffers. It's a broad scope structure for every type of message we process and it can change over time as we improve the way the `conserver.lib` handles packets.
-            - This represents a version agnostic variant for ONLY the connect message that can pass along the initial connect information structure, the packet sequencing information, and other relevant payload only to that one message type. It will purposefully discard references to things like a specific set of API servicing routines because the point of handing off is to get updated routines, if necessary.
-            - **V1 NOTE:** This was named `CONSOLE_PORTABLE_ATTACH_MSG`
-        - `HANDLE signalPipe`: During authoring, it was identified that <kbd>Ctrl+C</kbd> and other similar signals need to make it back to the original `conhost.exe` application as the Operating System grants it special privilege over the originally attached client application. This privilege cannot be transferred to the delegated console. So this channel remains for the delegated one to send its signals back through the original one for commanding the underlying client. (This also implies the original `conhost.exe` inbox cannot close and must remain a part of the process tree for the life of the session to maintain this control.)
-        - `HANDLE inboxProcess`: Since we have to keep the inbox `conhost.exe` running for signal/ownership reasons, we also need to track its lifetime. If it disappears for whatever reason, we need to tear down the entire chain as part of our operation has been compromised.
-        - `HANDLE* process`: On the contrary to `inboxProcess`, we need to give our process handle back so it can also be tracked. After the inbox console delegates, it remains in a very limited capacity. If the delegation one disappears, the session will no longer function and needs to be torn down (and the client closed).
-        - *Return* `HRESULT`: This is one of the older style methods in the initialization. We moved them from mostly `NTSTATUS` to mostly `HRESULT` a while ago to take advantage of `wil`. This one will continue to follow the pattern and not move to exceptions. A return of `S_OK` will symbolize that the handoff worked and the inbox console can clean itself up and stop handling the session.
- When the connection packet is parsed for visibility information (see `srvinit.cpp`), we will attempt to resolve the registered handoff and call it.
-    - ~~In the initial revision here, I have this as a `LoadLibrary`/`GetProcAddress` to the above exported contract method from the updated console. This maintains the server session in the same process space and avoids:~~
-        1. ~~The issue of passing the server, event, and other handles into another process space. We're not entirely sure if the console driver will happily accept these things moving to a different process. It probably should, but unconfirmed.~~
-        1. ~~Some command-line client applications rely on spelunking the process tree to figure out who is their servicing application. Maintaining the delegated/updated console inside the same process space maintains some level of continuity for these sorts of applications.~~
-    - **Alternative:** We may make this just be a COM server/client contract. ~~An in-proc COM server should operate in much the same fashion here (loading the DLL into the process and running particular method) while being significantly more formal and customizable (version revisions, moving to out-of-proc, not really needing to know the binary path because the catalog knows).~~
-        - **V1 NOTE:** We landed on an out-of-proc COM server/client here. This maintains the isolation of the newly running code from the old code. Since we're maintaining the original `conhost.exe` for signaling purposes, we're no longer worried about the spelunking the process tree and not having the relationship for clients to find.
-    - **Not considering:** ~~WinRT. `conhost.exe` has no WinRT. Adding WinRT to it would significantly increase the complexity of compilation in the inbox and out of box code base. It would also significantly increase the compilation time, binary size, library link list, etc... unless we use just the ABI to access it. But I don't see an advantage to that over just using classic COM at that point. This is only one handoff method and a rather simplistic one at that. Every benefit WinRT provides is outweighed by the extra effort that would be required over just a classic COM server in this case.~~
- After delegation is complete, the inbox console will have to clean up any threads, handles, and state related to the session. We do a fairly good job with this normally, but some portions of the `conhost.exe` codebase are reliant on the process exiting for final cleanup. There may be a bit of extra effort to do some explicit cleanup here.
-    - **V1 NOTE:** The inbox one cleans up everything it can and sits in a state waiting for the child/delegated process handle to exit. It also maintains a thread listening for the signals to come through in case it needs to send a command to the client application using the privilege granted to it by the driver.
-
-#### Updated console
-
-The updated replacement console will have the same console API server capabilities as the inbox console, but will be a later, updated, or customized-to-the-scenario version of the API server generally revolving around improving ConPTY support for a Terminal application.
-
-On receiving the handoff from the method signature listed above, the updated console will:
- Establish its own set of IO threading, device communication infrastructure, and API messaging routines while storing the handles given
- ~~Re-parse the command line arguments, if necessary, and store them for guiding the remainder of launch~~
- Dispatch the attach message as if it were received normally
- Continue execution from there
-
-There will then either be a registration for a Terminal UX to take over the session by using ConPTY, ~~or the updated console will choose to launch its potentially updated version of the `conhost` UX~~.
-
-For registration, we repeat the dance above with another key:
- A registry key in `HKCU\Console\%%Startup` (format `REG_SZ`, name `DelegationTerminal`).
-
-The delegation repeats the same dance as above as well:
- A contract (interface) is established between the updated console and the terminal
-    - `HRESULT EstablishPtyHandoff(HANDLE in, HANDLE out, HANDLE signal, HANDLE ref, HANDLE server, HANDLE client)`
-        - `HANDLE in`: The handle to read client application output from the ConPTY and display on the Terminal
-        - `HANDLE out`: The handle to write user input from the Terminal to the ConPTY
-        - `HANDLE signal`: The signal handle for the ConPTY for out-of-band communication between PTY server and Terminal application
-        - ~~`COORD size`: The initial window size from the starting application, as it can be a preference in the connection structure. (A resize message may get sent back downward almost immediately from the Terminal as its dimensions could be different.)~~ **V1 NOTE:** This proved unnecessary as the resize operations sorted themselves out naturally.
-        - `HANDLE ref`: This is a "client reference handle" to the console driver and session. We hold onto a copy of this in the Terminal so the session will stay alive until we let go. (The other console hosts in the chain also hold one of these, as should the client.)
-        - `HANDLE server`: This is a process handle to the PTY we're attached to. We monitor this to know when the PTY is still alive from the Terminal side.
-        - `HANDLE client`: This is a process handle to the underlying client application. The terminal tracks this for exit handling.
-    - **Alternative:** This should likely just be a COM server/client contract as well. This would be consistent with the above and wouldn't require argument parsing or wink/nudge understanding of standard handle passing. It also conveys the same COM flexibility as described in the inbox console section. **V1 NOTE:** We used this alternative. We used COM, not a well-known exported function from the prototype.
- The contract is called and on success, responsibility of the UX is given over to the Terminal. The console sits in PTY mode.
-    - On failure, the console launches interactive.
-
-#### Terminal UX
-
-The terminal will be its own complete presentation and input solution on top of a ConPTY connection, separating the concerns between API servicing and the user experience.
-
-Today the Terminal knows how to start and then launches a ConPTY under it. The Terminal will need to be updated to accept a pre-existing ConPTY connection on launch (or when the multi-process model arrives, as an inbound connection), and connect that to a new tab/pane instead of using the `winconpty.lib` libraries to make its own.
-
-For now, I'm considering only the fresh-start scenario.
- The Terminal will have to detect the inbound connection through ~~its argument parsing (or through~~ a new entrypoint in the COM alternative ~~)~~ and store the PTY in/out/signal handles for that connection in the startup arguments information
- When the control is instantiated on a new tab, that initial creation where normally the "default profile" is launched will instead have to place the PTY in/out/signal handles already received into the `ConPtyConnection` object and use that as if it was already created.
- The Terminal can then let things run normally and the connection will come through and be hosted inside the session.
-
-There are several issues/concerns:
- Which profile/settings get loaded? We don't really know anything about the client that is coming in already-established. That makes it difficult to know what user preferences to apply to the inbound tab. We could:
-    - Use only the defaults for the incoming connection. Do not apply any profile-specific settings.
-    - Use the profile information from the default profile to some degree. This could cause some weird scenarios/mismatches if that profile has a particular icon or a color scheme that makes it recognizable to the user.
-    - Create some sort of "inbound profile" profile that is used for incoming connections
-    - Add a heuristic that attempts to match the name/path of the connecting client binary to a profile that exists and use those settings, falling back if one is not found.
-    - **Proposal:** Do the first one immediately for bootstrapping, then investigate the others as a revision going forward.
- The handles that are coming in are "raw" and "unpacked", not in the nice opaque `HPCON` structure that is usually provided to the `ConPtyConnection` object by the `winconpty.lib`.
-    - Add methods to `winconpty.lib` that allow for the packing of incoming raw handles into the `HPCON` structure so the rest of the lifetime can be treated the same
-    - Put the entrypoint for the COM server (or delegate the entrypoint for an argument) directly into this library so it can pack them up right away and hand of a ready-made `HPCON`.
-
-## UI/UX Design
-
-The user experience for this feature overall should be:
-
-1. The user launches a command-line client application through the Start Menu, Win+X menu, the Windows Explorer, the Run Dialog box (WinKey+R), or through another existing Windows application.
-1. Using the established settings, the console system transparently starts, delegates itself to the updated console, switches itself into ConPTY mode, and a copy of Windows Terminal launches with the first tab open to host the command-line client application.
-    - **NOTE:** I'm not precluding 3rd party registrations of either the delegation updated console nor the delegation terminal. It is our intention to allow either or both of these pieces to be replaced to the user's desires. The example is for brevity of our golden path and motivation for this scenario.
-1. The user is able to interact with the command-line client application as they would with the original console host.
-    - The user receives the additional benefit that short-running executions of a command-line application may not "blink in and disappear" as they do today when a user runs something like `ipconfig` from the run dialog. The Terminal's default states tend to leave the tab open and say that the client has exited. This would allow a Run Dialog `ipconfig` user an improved experience over the default console host state of disappearing quickly.
-1. If any portion of the delegation fails, we will progressively degrade back to a `conhost` style Win32+GDI UX and nothing will be different from before.
-
-The settings experience includes:
- Configuration of the delegation operations:
-    - Locations:
-        - With the registry
-            - This is what's going to be available first and will remain available. We will progress to some or all of the below after.
-            - We will need to potentially add specifications to this to both the default profile (for new installations of Windows) or to upgrade/migration profiles (for users coming from previous editions of Windows) to enable the delegation process, especially if we put a copy of Windows Terminal directly into the box.
-            - **V1 NOTE:** we didn't add additional migration logic here as `HKCU\Console*` and subkeys were already in the migration logic, so adding another should just carry along.
-        - Inside Windows Terminal
-            - Inside the new Settings UI, we will likely need a page that configures the delegation keys in `HKCU\Console\%%Startup` ~~or a link out to the Windows Settings panel, should we manage to get the settings configurable there~~.
-        - Inside the console property sheet
-            - Same as for Terminal but with `comctl` controls over XAML +/- a link to the Windows Settings panel
-        - Inside the Settings panel for Windows (probably on the developer settings page)
-            - The ultimate location for this is likely a panel directly inside Windows. This is the hardest one to accomplish because of the timelines of the Windows product. We may not get this in an initial revision, but it should likely be our ultimate goal. **V1 NOTE:** We did it!
-    - Operation:
-        - Specify paths/server IDs - This is the initial revision
-        - Offer a list of registered servers or discovered manifests from the app catalog - This is the ideal scenario where we search the installed app catalog +/- the COM catalog and offer a list of apps that conform to the contract in a drop-down.
-            - The final process was to use [App Extensions](https://docs.microsoft.com/windows/uwp/launch-resume/how-to-create-an-extension) inside the Terminal APPX package to declare the COM GUIDs that were available for the `DelegationConsole` and `DelegationTerminal` fields respectively. A configuration class `DelegationConfig` was added to `propslib.lib` that enables the lookup of these from the application state catalog and presents a list of them to choose from. It also manages reading and writing the registry keys.
-            - **V1 NOTE:** Our configuration options currently allow pairings of replacement consoles and terminals to be adjusted in lock-step from the UI. That's not to say further combinations are not possible or even necessarily inhibited by the code. We just went for minimal confusion in our first round.
-    
- Configuration of the legacy console state:
-    - ~~Since we could end up in an experience where the default launch experience gets you directly into Windows Terminal, we believe that the Terminal will likely need an additional setting or settings in the new Settings UI that will allow the toggling of some of the `HKCU\Console` values to do things like set/remove the legacy console state.~~ **V1 NOTE:** Cut as low priority. Switch back to console and configure it that way or use the existing property sheet or tamper with registry keys.
-    - We have left the per-launch debugging and advanced access hole of calling something like `conhost.exe cmd.exe` which will use the inbox conhost to launch `cmd.exe` even if there is a default specified.
-
-Concerns:
- State separation policy for Windows. I believe `HKCU\Console` is already specified as a part of the "user state" that should be mutable and carried forward on OS Swap, especially as we have been improving the OS swap experience.
- Ability for installers/elevated scripts to stomp the Delegation keys
-    - This was a long time problem for default app registrations and was limited in our OS. Are we about to run down the same path?
-    - What is the alternative here? To use a protocol handler? To store this configuration state data with other protected state in a registry area that is mutable, but only ACL'd to the `SYSTEM` user like some other things in the Settings control panel?
-        - **V1 NOTE:** We set ourselves up for some future ACL thing with the subkey, but we otherwise haven't enforced anything at this time.
-
-## Capabilities
-
-### Accessibility
-
-Accessibility applications are the most likely to resort to a method of spelunking the process tree or window handles to attempt to find content to read out. Presuming they have hardcoded rules for console-type applications, these algorithms could be surprised by the substitution of another terminal environment.
-
-The major players here that I am considering are NVDA, JAWS, and Narrator. As far as I am aware, all of these applications attempt to drive their interactivity through UI Automation where possible. And we have worked with all of these applications in the past in improving their support for both `conhost.exe` and the Windows Terminal product. I have relatively high confidence that we will be able to work with them again to help update these assistive products to understand the new UI delegation, if necessary.
-
-### Security
-
-Let's hit the elephant in the room. "You plan on pulling a completely different binary inside the `conhost.exe` process and just... delegating all activity to it?" Yes.
-
-(**V1 NOTE:** Well, it's out of proc now. But it is at the same privilege level as the original one thanks to the mechanics of COM.) 
-
-As far as I'm concerned, the `conhost.exe` that is started to host the command-line client application is running at the same integrity level as the client binary that is partially started and waiting for its server to be ready. This is the long-standing existing protection that we have from the Windows operating system. Anything running in the same integrity level is already expected to be able to tamper with anything else at the same integrity level. The delegated binary that we would be loading into our process space will also be at the same integrity level. Nothing really stops a malicious actor from launching that binary in any other way in the same integrity level as a part of the command-line client application's startup. 
-
-The mitigation here, if necessary, would be to use `WinVerifyTrust` to validate the certification path of the `OpenConsole.exe` binary to ensure that only one that is signed by Microsoft can be the substitute server host for the application. This doesn't stop third parties from redistributing our `OpenConsole.exe` off of GitHub if necessary with their products, but it would stop someone from introducing any random binary that met the signature interface of the delegation methods into `conhost.exe`. The only value I see this providing is stopping someone from being "tricked" into delegating their `conhost.exe` to another binary through the configuration methods we provide. It doesn't really stop someone (or an attacker) from taking ownership of the `conhost.exe` in System32 and replacing it directly. So this point might be moot. (It is expected that replacement of the System32 one is already protected, to some degree, by being owned by the SYSTEM account and requiring some measure of authority to replace.)
-
-### Reliability
-
-The change on its own may honestly improve reliability of the hosting system. The existing just-in-time startup of the console host application only had a single chance at initializing a user experience before it would give up and return that the command-line application could not be started.
-
-However, there are now several phases in the startup process that will have the opportunity to make multiple attempts at multiple versions or applications to find a suitable host for the starting application before giving up.
-
-One layer of this is where the `conhost.exe` baked into the operating system will be on the lookout for an `OpenConsole.exe` that will replace its server activities. The delegation binary loses a bit of reliability, theoretically, by the fact that loading another process during launch could have versioning/resolution/path/dependency issues, but it simultaneously offers us the opportunity for improved reliability by being able to service that binary quickly outside the Windows OS release cycle. Fixes can arrive in days instead of months to years.
-
-Another layer of this is where either `conhost.exe` or the delegated `OpenConsole.exe` server will search for a terminal user experience host, like `WindowsTerminal.exe` or another registered first or third party host, and split the responsibility of hosting the session with that binary. Again, there's a theoretical reliability loss with the additional process launch/load, but there's much to be gained by reducing the scope of what each binary must accomplish. Removing the need to handle user interaction from `conhost.exe` or `OpenConsole.exe` and delegating those activities means there is less surface area running and less chance for a UX interaction to interfere with API call servicing and vice versa. And again, having the delegation to external components means that they can be fixed on a timeline of days instead of months or years as when baked into the operating system.
-
-### Compatibility
-
-One particular scenario that this could break is an application that makes use of spelunking the process tree when a command-line application starts to identify the hosting terminal application window by HWND to inject input, extract output, or otherwise hook and bind to hosting services. As the default application UI that will launch may not have the `conhost.exe` name (for spelunking via searching processes) and the HWND located may either be the ConPTY fake HWND or an HWND belonging to a completely different UI, these applications might not work.
-
-Two considerations here:
-
-1. At a minimum, we must offer an opt-out of the delegation to another terminal for the default application.
-1. We may also want to offer a process-name, policy, manifest, or other per client application opt-out mechanism.
-
-**V1 NOTE:** There is no per-client specific way of doing this. The toggle is per-user and can be adjusted in 3 different places.
-
-### Performance, Power, and Efficiency
-
-I expect to take some degree of performance, power, and efficiency hit by implementing this replacement default app scenario just by it's nature. We will be loading multiple processes, performing tests and branches during startup, and we will likely need to load COM/WinRT and packaging data that was not loaded prior to resolve the final state of default application load. I would expect this to accrue to some failures in the performance and power gates inside the Windows product. Additionally, the efficiency of running pretty much everything through the ConPTY is lower than just rendering it directly to `conhost.exe`'s embedded GDI-powered UI itself thanks to the multiple levels of translation and parsing that occur in this scenario.
-
-The mitigations to these losses are as follows:
-
-1. We will delay load any of the interface load and packaging data lookup libraries to only be pulled into process space should we determine that the application is non-interactive. 
-    1. That should save us some of the commit and power costs for the sorts of non-interactive scripts and applications that typically run early in OS startup (and leverage `conhost.exe` as their host environment). 
-    1. We will still likely get hit with the on-disk commit cost for the additional export libraries linked as well as additional code. That would be a by-design change.
-
-1. We plan to begin Profile Guided Optimization across our `OpenConsole.exe` and `WindowsTerminal.exe` binaries. This should allow us to optimize the startup paths for this scenario and bias the `OpenConsole.exe` binary that we redistribute to focus its efforts and efficiency on the ConPTY role specifically, ignoring all of the interactive Win32/GDI portions that aren't typically used.
-    1. We may need to add a PGO scenario inside Windows to tune the optimization of `conhost.exe` especially if we're going to go full on Windows Terminal in the box default application. The existing PGO that occurs in the optimization branches is running on several `conhost.exe` interactive scenarios, none of which will be relevant here. We would probably want to update it to focus on the default app delegation routine AND on the non-interactive scenario for hosted applications (where delegation will not occur but Win32/GDI will still not be involved).
-
-## Potential Issues
-
-### Passing Handles with COM
-COM doesn't inherently expose a way for us to pass handles directly between processes with the existing contracts. We know this is possible because Windows does it all the time, but it doesn't appear to be public. We believe the mission forward is to expose this functionality to the public as if it's good enough for us internally and it is a requirement to build complex functionality like this... then it should be good enough for the public.
-
-**V1 NOTE:** We gained approval to open this up and documented it. [`system_handle` attribute](https://docs.microsoft.com/windows/win32/midl/system-handle). It didn't require any code changes because the public IDL compiler already recognized the existence of this attribute and did the correct thing. It just wasn't documented for use.
-
-## Future considerations
-
-* We additionally would like to leave the door open to distributing updated `OpenConsole.exe`s in their own app package as a dependency that others could rely on.
-    * This was one of the original management requests when we were opening the source of the console product as well as the Terminal back in spring of 2019. For the sake of ongoing servicing and maintainability, it was requested that we reach a point where our dependencies could be serviced potentially independently of the product as a whole static unit. We didn't achieve that goal initially, but this design would enable us to do something like this.
-    * One negative to this scenario is that dependency resolution and the installation of dependent packages through APPX is currently lacking in several ways. It's difficult/impossible to do in environments where the store or the internet is unavailable. And it's a problem often enough that the Windows Terminal package embeds the VC runtimes inside itself instead of relying on the dependency resolution of the app platform.
-
-## Resources
-
- [Windows Terminal Process Model 2.0 spec](https://github.com/microsoft/terminal/pull/7240)
- [Windows Terminal 2.0 Process Model Improvements](https://github.com/microsoft/terminal/issues/5000)
- [Console allocation policy specifications](https://github.com/microsoft/terminal/pull/7337)
- [Fine-grained console allocation policy feature](https://github.com/microsoft/terminal/issues/7335)
--- a/Improvements.md
+++ b/Improvements.md
@@ -1,619 +0,0 @@
---
-author: Mike Griese @zadjii-msft
-created on: 2020-11-20
-last updated: 2021-08-17
-issue id: #1032
---
-
-# Elevation Quality of Life Improvements
-
-## Abstract
-
-For a long time, we've been researching adding support to the Windows Terminal
-for running both unelevated and elevated (admin) tabs side-by-side, in the same
-window. However, after much research, we've determined that there isn't a safe
-way to do this without opening the Terminal up as a potential
-escalation-of-privilege vector.
-
-Instead, we'll be adding a number of features to the Terminal to improve the
-user experience of working in elevated scenarios. These improvements include:
-
-* A visible indicator that the Terminal window is elevated ([#1939])
-* Configuring the Terminal to always run elevated ([#632])
-* Configuring a specific profile to always open elevated ([#632])
-* Allowing new tabs, panes to be opened elevated directly from an unelevated
-  window
-* Dynamic profile appearance that changes depending on if the Terminal is
-  elevated or not. ([#1939], [#8311])
-
-## Background
-
-_This section was originally authored in the [Process Model 2.0 Spec]. Please
-refer to it there for its original context._
-
-Let's presume that you're a user who wants to be able to open an elevated tab
-within an otherwise unelevated Terminal window. We call this scenario "mixed
-elevation" - the tabs within the Terminal can be running either unelevated _or_
-elevated client applications.
-
-It wouldn't be terribly difficult for the unelevated Terminal to request the
-permission of the user to spawn an elevated client application. The user would
-see a UAC prompt, they'd accept, and then they'd be able to have an elevated
-shell alongside their unelevated tabs.
-
-However, this creates an escalation of privilege vector. Now, there's an
-unelevated window which is connected directly to an elevated process. At this
-point, **any other unelevated application could send input to the Terminal's
-`HWND`**. This would make it possible for another unelevated process to "drive"
-the Terminal window, and send commands to the elevated client application.
-
-It was initially theorized that the window/content model architecture would also
-help enable "mixed elevation". With mixed elevation, tabs could run at different
-integrity levels within the same terminal window. However, after investigation
-and research, it has become apparent that this scenario is not possible to do
-safely after all. There are numerous technical difficulties involved, and each
-with their own security risks. At the end of the day, the team wouldn't be
-comfortable shipping a mixed-elevation solution, because there's simply no way
-for us to be confident that we haven't introduced an escalation-of-privilege
-vector utilizing the Terminal. No matter how small the attack surface might be,
-we wouldn't be confident that there are _no_ vectors for an attack.
-
-Some things we considered during this investigation:
-
-* If a user requests a new elevated tab from an otherwise unelevated window, we
-  could use UAC to create a new, elevated window process, and "move" all the
-  current tabs to that window process, as well as the new elevated client. Now,
-  the window process would be elevated, preventing it from input injection, and
-  it would still contains all the previously existing tabs. The original window
-  process could now be discarded, as the new elevated window process will
-  pretend to be the original window.
-  - However, it is unfortunately not possible with COM to have an elevated
-    client attach to an unelevated server that's registered at runtime. Even in
-    a packaged environment, the OS will reject the attempt to `CoCreateInstance`
-    the content process object. this will prevent elevated windows from
-    re-connecting to unelevated client processes.
-  - We could theoretically build an RPC tunnel between content and window
-    processes, and use the RPC connection to marshal the content process to the
-    elevated window. However, then _we_ would need to be responsible for
-    securing access the the RPC endpoint, and we feel even less confident doing
-    that.
-  - Attempts were also made to use a window-broker-content architecture, with
-    the broker process having a static CLSID in the registry, and having the
-    window and content processes at mixed elevation levels `CoCreateInstance`
-    that broker. This however _also_ did not work across elevation levels. This
-    may be due to a lack of Packaged COM support for mixed elevation levels.
-
-    It's also possible that the author forgot that packaged WinRT doesn't play
-    nicely with creating objects in an elevated context. The Terminal has
-    previously needed to manually manifest all its classes in a SxS manifest for
-    Unpackaged WinRT to allow the classes to be activated, rather than relying
-    on the packaged catalog. It's theoretically possible that doing that would
-    have allowed the broker to be activated across integrity levels.
-
-    Even if this approach did end up working, we would still need to be
-    responsible for securing the elevated windows so that an unelevated attacker
-    couldn't hijack a content process and trigger unexpected code in the window
-    process. We didn't feel confident that we could properly secure this channel
-    either.
-
-We also considered allowing mixed content in windows that were _originally_
-elevated. If the window is already elevated, then it can launch new unelevated
-processes. We could allow elevated windows to still create unelevated
-connections. However, we'd want to indicate per-pane what the elevation state
-of each connection is. The user would then need to keep track themselves of
-which terminal instances are elevated, and which are not.
-
-This also marks a departure from the current behavior, where everything in an
-elevated window would be elevated by default. The user would need to specify for
-each thing in the elevated window that they'd want to create it elevated. Or the
-Terminal would need to provide some setting like
-`"autoElevateEverythingInAnElevatedWindow"`.
-
-We cannot support mixed elevation when starting in a unelevated window.
-Therefore, it doesn't make a lot of UX sense to support it in the other
-direction. It's a cleaner UX story to just have everything in a single window at
-the same elevation level.
-
-## Solution Design
-
-Instead of supporting mixed elevation in the same window, we'll introduce the
-following features to the Terminal. These are meant as a way of improving the
-quality of life for users who work in mixed-elevation (or even just elevated)
-environments.
-
-### Visible indicator for elevated windows
-
-As requested in [#1939], it would be nice if it was easy to visibly identify if
-a Terminal window was elevated or not.
-
-One easy way of doing this is by adding a simple UAC shield to the left of the
-tabs for elevated windows. This shield could be configured by the theme (see
-[#3327]). We could provide the following states:
-* Colored (the default)
-* Monochrome
-* Hidden, to hide the shield even on elevated windows. This is the current
-  behavior.
-
-![UAC-shield-in-titlebar](UAC-shield-in-titlebar.png)
-_figure 1: a monochrome UAC shield in the titlebar of the window, courtesy of @mdtauk_
-
-We could also simplify this to only allow a boolean true/false for displaying
-the shield. As we do often with other enums, we could define `true` to be the
-same as the default appearance, and `false` to be the hidden option. As always,
-the development of the Terminal is an iterative process, where we can
-incrementally improve from no setting, to a boolean setting, to a enum-backed
-one.
-
-### Configuring a profile to always run elevated
-
-Oftentimes, users might have a particular tool chain that only works when
-running elevated. In these scenarios, it would be convenient for the user to be
-able to identify that the profile should _always_ run elevated. That way, they
-could open the profile from the dropdown menu of an otherwise unelevated window
-and have the elevated window open with the profile automatically.
-
-We'll be adding the `"elevate": true|false` setting as a per-profile setting,
-with a default value of `false`. When set to `true`, we'll try to auto-elevate
-the profile whenever it's launched. We'll check to see if this window is
-elevated before creating the connection for this profile. If the window is not
-elevated, then we'll create a new window with the requested elevation level to
-handle the new connection.
-
-`"elevate": false` will do nothing. If the window is already elevated, then the
-profile won't open an un-elevated window.
-
-If the user tries to open an `"elevate": true` profile in a window that's
-already elevated, then a new tab/split will open in the existing window, rather
-than spawning an additional elevated window.
-
-There are three situations where we're creating new terminal instances: new
-tabs, new splits, and new windows. Currently, these are all actions that are
-also exposed in the `wt` commandline as subcommands. We can convert from the
-commandline arguments into these actions already. Therefore, it shouldn't be too
-challenging to convert these actions back into the equal commandline arguments.
-
-For the following examples, let's assume the user is currently in an unelevated
-Terminal window.
-
-When the user tries to create a new elevated **tab**, we'll need to create a new
-process, elevated, with the following commandline:
-
-```
-wt new-tab [args...]
-```
-
-When we create this new `wt` instance, it will obey the glomming rules as
-specified in [Session Management Spec]. It might end up glomming to another
-existing window at that elevation level, or possibly create its own window.
-
-Similarly, for a new elevated **window**, we can make sure to pass the `-w new`
-arguments to `wt`. These parameters indicate that we definitely want this
-command to run in a new window, regardless of the current glomming settings.
-
-```
-wt -w new new-tab [args...]
-```
-
-However, creating a new **pane** is a little trickier. Invoking the `wt
-split-pane [args...]` is straightforward enough.
-
-<!-- Discussion notes follow:
-If the current window doesn't have the same elevation level as the
-requested profile, do we always want to just create a new split? If the command
-ends up glomming to an existing window, does that even make sense? That invoking
-an elevated split in an unelevated window would end up splitting the elevated
-window? It's very possible that the user wanted a split in the tab they're
-currently in, in the unelevated window, but they don't want a split in the
-elevated window.
-
-What if there's not space in the elevated window to create the split (but there
-would be in the current window)? That would sure make it seem like nothing
-happened, silently.
-
-We could alternatively have cross-elevation splits default to always opening a
-new tab. That might mitigate some of the odd behaviors. Until we actually have
-support for running commands in existing windows, we'll always need to make a
-new window when running elevated. We'll need to make the new window for new tabs
-and splits, because there's no way to invoke another existing window.
-
-A third proposal is to pop a warning dialog at the user when they try to open an
-elevated split from and unelevated window. This dialog could be something like
-
-> What you requested couldn't be completed. Do you want to:
-> A. Make me a new tab instead.
-> B. Forget it and cancel. I'll go fix my config.
-
-I'm certainly leaning towards proposal 2 - always create a new tab. This is how
-it's implemented in [#8514]. In that PR, this seems to work sensibly.
-->
-
-After discussing with the team, we have decided that the most sensible approach
-for handling a cross-elevation `split-pane` is to just create a new tab in the
-elevated window. The user can always re-attach the pane as a split with the
-`move-pane` command once the new pane in the elevated window.
-
-#### Configure the Terminal to _always_ run elevated
-
-`elevate` is a per-profile property, not a global property. If a user
-wants to always have all instances of the Terminal run elevated, they
-could set `"elevate": true` in their profile defaults. That would cause _all_
-profiles they launch to always spawn as elevated windows.
-
-#### `elevate` in Actions
-
-Additionally, we'll add the `elevate` property to the `NewTerminalArgs` used in
-the `newTab`, `splitPane`, and `newWindow` actions. This is similar to how other
-properties of profiles can be overridden at launch time. This will allow
-windows, tabs and panes to all be created specifically as elevated windows.
-
-In the `NewTerminalArgs`, `elevate` will be an optional boolean, with the
-following behavior:
-* `null` (_default_): Don't modify the `elevate` property for this profile
-* `true`: This launch should act like the profile had `"elevate": true` in its
-  properties.
-* `false`: This launch should act like the profile had `"elevate": false` in its
-  properties.
-
-We'll also add an iterable command for opening a profile in an
-elevated tab, with the following json:
-
-```jsonc
-{
-    // New elevated tab...
-    "name": { "key": "NewElevatedTabParentCommandName", "icon": "UAC-Shield.png" },
-    "commands": [
-        {
-            "iterateOn": "profiles",
-            "icon": "${profile.icon}",
-            "name": "${profile.name}",
-            "command": { "action": "newTab", "profile": "${profile.name}", "elevated": true }
-        }
-    ]
-},
-```
-
-#### Elevation from the dropdown
-
-Currently, the new tab dropdown supports opening a new pane by
-<kbd>Alt+click</kbd>ing on a profile. We could similarly add support to open a
-tab elevated with <kbd>Ctrl+click</kbd>. This is similar to the behavior of the
-Windows taskbar. It supports creating an elevated instance of a program by
-<kbd>Ctrl+click</kbd>ing on entries as well.
-
-## Implementation Details
-
-### Starting an elevated process from an unelevated process
-
-It seems that we're able to create an elevated process by passing the `"runas"`
-verb to
-[`ShellExecute`](https://docs.microsoft.com/en-us/windows/win32/api/shellapi/nf-shellapi-shellexecutea).
-So we could use something like
-
-```c++
-ShellExecute(nullptr,
-             L"runas",
-             L"wt.exe",
-             L"-w new new-tab [args...]",
-             nullptr,
-             SW_SHOWNORMAL);
-```
-
-This will ask the shell to perform a UAC prompt before spawning `wt.exe` as an
-elevated process.
-
-> 👉 NOTE: This mechanism won't always work on non-Desktop SKUs of Windows. For
-> more discussion, see [Elevation on OneCore SKUs](#Elevation-on-OneCore-SKUs).
-
-## Potential Issues
-
-<table>
-<tr>
-<td><strong>Accessibility</strong></td>
-<td>
-
-The set of changes proposed here are not expected to introduce any new
-accessibility issues. Users can already create elevated Terminal windows. Making
-it easier to create these windows doesn't really change our accessibility story.
-
-</td>
-</tr>
-<tr>
-<td><strong>Security</strong></td>
-<td>
-
-We won't be doing anything especially unique, so there aren't expected to be any
-substantial security risks associated with these changes. Users can already
-create elevated Terminal windows, so we're not really introducing any new
-functionality, from a security perspective.
-
-We're relying on the inherent security of the `runas` verb of `ShellExecute` to
-prevent any sort of unexpected escalation-of-privilege.
-
-<hr>
-
-One security concern is the fact that the `settings.json` file is currently a
-totally unsecured file. It's completely writable by any medium-IL process. That
-means it's totally possible for a malicious program to change the file. The
-malicious program could find a user's "Elevated PowerShell" profile, and change
-the commandline to `malicious.exe`. The user might then think that their
-"Elevated PowerShell" will run `powershell.exe` elevated, but will actually
-auto-elevate this attacker.
-
-If all we expose to the user is the name of the profile in the UAC dialog, then
-there's no way for the user to be sure that the program that's about to be
-launched is actually what they expect.
-
-To help mitigate this, we should _always_ pass the evaluated `commandline` as a
-part of the call to `ShellExecute`. the arguments that are passed to
-`ShellExecute` are visible to the user, though they need to click the "More
-Details" dropdown to reveal them.
-
-We will need to mitigate this vulnerability regardless of adding support for the
-auto-elevation of individual terminal tabs/panes. If a user is launching the
-Terminal elevated (i.e. from the Win+X menu in Windows 11), then it's possible
-for a malicious program to overwrite the `commandline` of their default profile.
-The user may now unknowingly invoke this malicious program while thinking they
-are simply launching the Terminal.
-
-To deal with this more broadly, we will display a dialog within the Terminal
-window before creating **any** elevated terminal instance. In that dialog, we'll
-display the commandline that will be executed, so the user can very easily
-confirm the commandline.
-
-This will need to happen for all elevated terminal instances. For an elevated
-Windows Terminal window, this means _all_ connections made by the Terminal.
-Every time the user opens a new profile or a new commandline in a pane, we'll
-need to prompt them first to confirm the commandline. This dialog within the
-elevated window will also prevent an attacker from editing the `settings.json`
-file while the user already has an elevated Terminal window open and hijacking a
-profile.
-
-The dialog options will certainly be annoying to users who don't want to be
-taken out of their flow to confirm the commandline that they wish to launch.
-There's precedent for a similar warning being implemented by VSCode, with their
-[Workspace Trust] feature. They too faced a similar backlash when the feature
-first shipped. However, in light of recent global cybersecurity attacks, this is
-seen as an acceptable UX degradation in the name of application trust. We don't
-want to provide an avenue that's too easy to abuse.
-
-When the user confirms the commandline of this profile as something safe to run,
-we'll add it to an elevated-only version of `state.json`. (see [#7972] for more
-details). This elevated version of the file will only be accessible by the
-elevated Terminal, so an attacker cannot hijack the contents of the file. This
-will help mitigate the UX discomfort caused by prompting on every commandline
-launched. This should mean that the discomfort is only limited to the first
-elevated launch of a particular profile. Subsequent launches (without modifying
-the `commandline`) will work as they always have.
-
-The dialog for confirming these commandlines should have a link to the docs for
-"Learn more...". Transparency in the face of this dialog should
-mitigate some dissatisfaction.
-
-The dialog will _not_ appear if the user does not have a split token - if the
-user's PC does not have UAC enabled, then they're _already_ running as an
-Administrator. Everything they do is elevated, so they shouldn't be prompted in
-this way.
-
-The Settings UI should also expose a way of viewing and removing these cached
-entries. This page should only be populated in the elevated version of the
-Terminal.
-
-</td>
-</tr>
-<tr>
-<td><strong>Reliability</strong></td>
-<td>
-
-No changes to our reliability are expected as a part of this change.
-
-</td>
-</tr>
-<tr>
-<td><strong>Compatibility</strong></td>
-<td>
-
-There are no serious compatibility concerns expected with this changelist. The
-new `elevate` property will be unset by default, so users will heed to opt-in
-to the new auto-elevating behavior.
-
-There is one minor concern regarding introducing the UAC shield on the window.
-We're planning on using themes to configure the appearance of the shield. That
-means we'll need to ship themes before the user will be able to hide the shield
-again.
-
-</td>
-</tr>
-<tr>
-<td><strong>Performance, Power, and Efficiency</strong></td>
-<td>
-
-No changes to our performance are expected as a part of this change.
-
-</td>
-</tr>
-</table>
-
-### Centennial Applications
-
-In the past, we've had a notoriously rough time with the Centennial app
-infrastructure and running the Terminal elevated. Notably, we've had to list all
-our WinRT classes in our SxS manifest so they could be activated using
-unpackaged WinRT while running elevated. Additionally, there are plenty of
-issues running the Terminal in an "over the shoulder" elevation (OTS) scenario.
-
-Specifically, we're concerned with the following scenario:
-  * the current user account has the Terminal installed,
-  * but they aren't an Administrator,
-  * the Administrator account doesn't have the Terminal installed.
-
-In that scenario, the user can run into issues launching the Terminal in an
-elevated context (even after entering the Admin's credentials in the UAC
-prompt).
-
-This spec proposes no new mitigations for dealing with these issues. It may in
-fact make them more prevalent, by making elevated contexts more easily
-accessible.
-
-Unfortunately, these issues are OS bugs that are largely out of our own control.
-We will continue to apply pressure to the centennial app team internally as we
-encounter these issues. They are are team best equipped to resolve these issues.
-
-### Default Terminal & auto-elevation
-
-In the future, when we support setting the Terminal as the "default terminal
-emulator" on Windows. When that lands, we will use the `profiles.defaults`
-settings to create the tab where we'll be hosting the commandline client. If the user has
-`"elevate": true` in their `profiles.defaults`, we'd usually try to
-auto-elevate the profile. In this scenario, however, we can't do that. The
-Terminal is being invoked on behalf of the client app launching, instead of the
-Terminal invoking the client application.
-
-**2021-08-17 edit**: Now that "defterm" has shipped, we're a little more aware
-of some of the limitations with packaged COM and elevation boundaries. Defterm
-cannot be used with elevated processes _at all_ currently (see [#10276]). When
-an elevated commandline application is launched, it will always just appear in
-`conhost.exe`. Furthermore, An unelevated peasant can't communicate with an
-elevated monarch so we can't toss the connection to the elevated monarch and
-have them handle it.
-
-The simplest solution here is to just _always_ ignore the `elevate` property for
-incoming defterm connections. This is not an ideal solution, and one that we're
-willing to revisit if/when [#10276] is ever fixed.
-
-### Elevation on OneCore SKUs
-
-This spec proposes using `ShellExecute` to elevate the Terminal window. However,
-not all Windows SKUs have support for `ShellExecute`. Notably, the non-Desktop
-SKUs, which are often referred to as "OneCore" SKUs. On these platforms, we
-won't be able to use `ShellExecute` to elevate the Terminal. There might not
-even be the concept of multiple elevation levels, or different users, depending
-on the SKU.
-
-Fortunately, this is a mostly hypothetical concern for the moment. Desktop is
-the only publicly supported SKU for the Terminal currently. If the Terminal ever
-does become available on those SKUs, we can use these proposals as mitigations.
-
-* If elevation is supported, there must be some other way of elevating a
-  process. We could always use that mechanism instead.
-* If elevation isn't supported (I'm thinking 10X is one of these), then we could
-  instead display a warning dialog whenever a user tries to open an elevated
-  profile.
-  - We could take the warning a step further. We could add another settings
-    validation step. This would warn the user if they try to mark any profiles
-    or actions as `"elevate":true`
-
-## Future considerations
-
-* If we wanted to go even further down the visual differentiation route, we
-  could consider allowing the user to set an entirely different theme ([#3327])
-  based on the elevation state. Something like `elevatedTheme`, to pick another
-  theme from the set of themes. This would allow them to force elevated windows
-  to have a red titlebar, for example.
-* Over the course of discussion concerning appearance objects ([#8345]), it
-  became clear that having separate "elevated" appearances defined for
-  `profile`s was overly complicated. This is left as a consideration for a
-  possible future extension that could handle this scenario in a cleaner way.
-* Similarly, we're going to leave [#3637] "different profiles when elevated vs
-  unelevated" for the future. This also plays into the design of "configure the
-  new tab dropdown" ([#1571]), and reconciling those two designs is out-of-scope
-  for this particular release.
-* Tangentially, we may want to have a separate Terminal icon we ship with the
-  UAC shield present on it. This would be especially useful for the tray icon.
-  Since there will be different tray icon instances for elevated and unelevated
-  windows, having unique icons may help users identify which is which.
-
-### De-elevating a Terminal
-
-the original version of this spec proposed that `"elevated":false` from an
-elevated Terminal window should create a new unelevated Terminal instance. The
-mechanism for doing this is described in [The Old New Thing: How can I launch an
-unelevated process from my elevated process, redux].
-
-This works well when the Terminal is running unpackaged. However, de-elevating a
-process does not play well with packaged centennial applications. When asking
-the OS to run the packaged application from an elevated context, the system will
-still create the child process _elevated_. This means the packaged version of
-the Terminal won't be able to create a new unelevated Terminal instance.
-
-From an internal mail thread:
-
-> App model intercepts the `CreateProcess` call and redirects it to a COM
-> service. The parent of a packaged app is not the launching app, it’s some COM
-> service. So none of the parent process nonsense will work because the
-> parameters you passed to `CreateProcess` aren’t being used to create the
-> process.
-
-If this is fixed in the future, we could theoretically re-introduce de-elevating
-a profile. The original spec proposed a `"elevated": bool?` setting, with the
-following behaviors:
-* `null` (_default_): Don't modify the elevation level when running this profile
-* `true`: If the current window is unelevated, try to create a new elevated
-  window to host this connection.
-* `false`: If the current window is elevated, try to create a new unelevated
-  window to host this connection.
-
-We could always re-introduce this setting, to supersede `elevate`.
-
-### Change profile appearance for elevated windows
-
-In [#3062] and [#8345], we're planning on allowing users to set different
-appearances for a profile whether it's focused or not. We could do similar thing
-to enable a profile to have a different appearance when elevated. In the
-simplest case, this could allow the user to set `"background": "#ff0000"`. This
-would make a profile always appear to have a red background when in an elevated
-window.
-
-The more specific details of this implementation are left to the spec
-[Configuration object for profiles].
-
-In discussion of that spec, we decided that it would be far too complicated to
-try and overload the `unfocusedAppearance` machinery for differentiating between
-elevated and unelevated versions of the same profile. Already, that would lead
-to 4 states: [`appearance`, `unfocusedAppearance`, `elevatedAppearance`,
-`elevatedUnfocusedAppearance`]. This would lead to a combinatorial explosion if
-we decided in the future that there should also be other states for a profile.
-
-This particular QoL improvement is currently being left as a future
-consideration, should someone come up with a clever way of defining
-elevated-specific settings.
-
-<!--
-Brainstorming notes for future readers:
-
-You could have a profile that layers on an existing profile, with elevated-specific settings:
-
-{
-  "name": "foo",
-  "background": "#0000ff",
-  "commandline": "cmd.exe /k echo I am unelevated"
-},
-{
-  "inheritsFrom": "foo",
-  "background": "#ff0000",
-  "elevate": true,
-  "commandline": "cmd.exe /k echo I am ELEVATED"
-}
-->
-
-<!-- Footnotes -->
-
-[#632]: https://github.com/microsoft/terminal/issues/632
-[#1032]: https://github.com/microsoft/terminal/issues/1032
-[#1571]: https://github.com/microsoft/terminal/issues/1571
-[#1939]: https://github.com/microsoft/terminal/issues/1939
-[#3062]: https://github.com/microsoft/terminal/issues/3062
-[#3327]: https://github.com/microsoft/terminal/issues/3327
-[#3637]: https://github.com/microsoft/terminal/issues/3637
-[#4472]: https://github.com/microsoft/terminal/issues/4472
-[#5000]: https://github.com/microsoft/terminal/issues/5000
-[#7972]: https://github.com/microsoft/terminal/pull/7972
-[#8311]: https://github.com/microsoft/terminal/issues/8311
-[#8345]: https://github.com/microsoft/terminal/issues/8345
-[#8514]: https://github.com/microsoft/terminal/issues/8514
-[#10276]: https://github.com/microsoft/terminal/issues/10276
-
-[Process Model 2.0 Spec]: https://github.com/microsoft/terminal/blob/main/doc/specs/%235000%20-%20Process%20Model%202.0.md
-[Configuration object for profiles]: https://github.com/microsoft/terminal/blob/main/doc/specs/Configuration%20object%20for%20profiles.md
-[Session Management Spec]: https://github.com/microsoft/terminal/blob/main/doc/specs/%234472%20-%20Windows%20Terminal%20Session%20Management.md
-[The Old New Thing: How can I launch an unelevated process from my elevated process, redux]: https://devblogs.microsoft.com/oldnewthing/20190425-00/?p=102443
-[Workspace Trust]: https://code.visualstudio.com/docs/editor/workspace-trust
--- a/doc/specs/#5000
+++ b/doc/specs/#5000
@@ -1123,7 +1123,7 @@ elevated windows, when they trust the extension. We could have an additional set
 of settings the user could use to enable certain extensions in elevated windows.
 However, this setting cannot live in the normal `settings.json` or even
 `state.json` (see [#7972], since those files are writable by any medium-IL
-process. Instead, this setting would need to live in a separate file that's
+process. Instead, this setting would ned to live in a separate file that's
 protected to only be writable by elevated processes. This would ensure that an
 attacker could not just add their extension to the list of white-listed
 extensions. When the settings UI wants to modify that setting, it'll need to
--- a/2.0/UAC-shield-in-titlebar.png
+++ b/2.0/UAC-shield-in-titlebar.png
--- a/Search/spec.md
+++ b/Search/spec.md
@@ -123,4 +123,4 @@ This open issue tracks the phase features of Search: https://github.com/microsof

 ## Resources

-GitHub Issue: https://github.com/microsoft/terminal/issues/605
+Github Issue: https://github.com/microsoft/terminal/issues/605
--- a/doc/specs/#653
+++ b/doc/specs/#653
@@ -1,736 +0,0 @@
---
-author: Mike Griese @zadjii-msft
-created on: 2021-02-23
-last updated: 2021-05-13
-issue id: #653
---
-
-# Quake Mode
-
-## Abstract
-
-Many existing terminals support a feature whereby a user can press a keybinding
-anywhere in the OS, and summon their terminal application. Oftentimes the act of
-summoning this window is accompanied by a "dropdown" animation, where the window
-slides in to view from the top of the screen. This global summon action is often
-referred to as "quake mode", a reference to the video game Quake, who's console
-slid in from the top.
-
-This spec addresses both of the following two issues:
-* "Quake Mode" ([#653])
-* "Minimize to tray" ([#5727])
-
-Readers should make sure to have read the [Process Model 2.0 Spec], for
-background on Monarch and Peasant processes.
-
-## Background
-
-### Inspiration
-
-For an example of the original Quake console in action, take a look at the
-following video (noisy video warning): [Quake 3 sample]. Additionally, plenty of
-existing terminal emulators support similar functionality:
-
-* **Tilda** allows the user to specify different keys to summon the window on
-  different monitors.
-* **Guake** alternatively allows the user to either summon the terminal window to
-  a specific monitor, or whichever monitor the mouse is on. Guake only allows
-  one single instance, so pressing the global hotkey always summons the same
-  instance.
-
-### User Stories
-
-The original quake mode thread (#653) is absolutely _filled_ with variations on
-how users want to be able to summon their terminal windows. These include, but
-are not limited to:
-
-* **Story A** Press a hotkey anywhere to activate the single Terminal window
-  wherever it was
-* **Story B** Press a hotkey anywhere to activate the single Terminal window _on
-  the current monitor_. If it wasn't previously on that monitor, move it there.
-* **Story C** When the Terminal is summoned using the hotkey, have it "slide in"
-  from the top. Similarly, slide out on deactivate.
-* **Story D** <kbd>Ctrl+1</kbd> to activate the terminal on monitor 1,
-  <kbd>Ctrl+2</kbd> to activate the terminal on monitor 2.
-* **Story E** Variable dropdown speed
-* **Story F** Minimize to tray, press a hotkey to activate the terminal window
-  (#5727)
-* **Story G** Terminal doesn't appear in alt+tab view, press a hotkey to
-  activate the single terminal window / the nearest terminal window (I'm not
-  sure this is distinct from the above)
-
-## Solution Design
-
-To implement this feature, we'll add the following settings:
-* a new action, named `globalSummon`.
-* a new global, app setting named `minimizeToTray`
-* a new global, app setting named `alwaysShowTrayIcon`
-* a new action, named `quakeMode`, and a specially named `_quake` window.
-
-### `globalSummon` Action
-
-The `globalSummon` action will be a keybinding the user can use to summon a
-Terminal window from anywhere in the OS. Various arguments to the action will
-specify which window is summoned, to where, and how the window should behave on
-summon.
-
-From a technical perspective, the action will work by using the
-[`RegisterHotKey`] function. This API allows us to bind a particular hotkey with
-the OS. Whenever that hotkey is pressed, our window message loop will receive a
-`WM_HOTKEY`. We'll use the payload of that window message to lookup the action
-arguments for that hotkey. Then we'll use those arguments to control which
-window is invoked, where, and how the window behaves.
-
-Since `RegisterHotKey` can only be used to register a hotkey _once_ with the OS,
-we'll need to make sure it's only ever set up by the Monarch process. We know
-that there will only ever be one Monarch for the Terminal at a time, so it's the
-perfect process to have the responsibility of managing the global hotkey.
-
-The Monarch will be responsible for calling `RegisterHotKey`, and processing the
-`WM_HOTKEY` messages. It will then dispatch method calls to the appropriate
-window to summon it. When a Monarch dies and a new process becomes the Monarch,
-the new Monarch will re-register for the hotkeys.
-
-#### Where in the settings?
-
-Since users may want to bind multiple keys to summon different windows, we'll
-need to allow the user to specify multiple keybindings simultaneously, each with
-their own set of args.
-
-We stick all the `globalSummon`s in the actions array, like they're any other
-keybinding.
-
-However, these are not keys that are handled by the TerminalApp layer itself.
-These are keys that need to be registered with the OS. So while they will be in
-the normal `KeyMap`, they will need to be retrieved from that object and
-manually passed to the window layer.
-
-> A previous iteration of this spec considered placing the `globalSummon`
-> actions in their own top-level array of the settings file, separate from the
-> keybindings. This is no longer being considered, because it would not work for
-> the case where the user has something like:
-> ```json
-> { "keys": "ctrl+c", "command": { "action": "globalSummon", "monitor": 1 } },
-> { "keys": "ctrl+v", "command": { "action": "copy" } },
-> ```
-
-#### Which window, and where?
-
-When looking at the list of requested scenarios, there are lots of different
-ways people would like to use the global summon action. Some want the most
-recent window activated, always. Others want to have one window _per monitor_.
-Some would like to move the window to where the user is currently interacting
-with the PC, and others want to activate the window where it already exists.
-Trying to properly express all these possible configurations is complex. The
-settings should be unambiguous as to what will happen when you press the
-keybinding.
-
-I believe that in order to accurately support all the variations that people
-might want, we'll need two properties in the `globalSummon` action. These
-properties will specify _which_ window we're summoning, and _where_ to summon
-the window. To try and satisfy all these scenarios, I'm proposing the following
-two arguments to the `globalSummon` action:
-
-```json
-"monitor": "any"|"toCurrent"|"toMouse"|"onCurrent"|int,
-"desktop": "any"|"toCurrent"|"onCurrent"
-```
-
-The way these settings can be combined is in a table below. As an overview:
-
-* `monitor`: This controls the monitor that the window will be summoned from/to
-  - `"any"`: Summon the MRU window, regardless of which monitor it's currently
-    on.
-  - `"toCurrent"`/omitted: (_default_): Summon the MRU window **TO** the monitor
-    with the current **foreground** window.
-  - `"toMouse"`: Summon the MRU window **TO** the monitor where the **mouse**
-    cursor is.
-  - `"onCurrent"`: Summon the MRU window **ALREADY ON** the current monitor.
-  - `int`: Summon the MRU window for the given monitor (as identified by the
-    "Identify" displays feature in the OS settings)
-
-* `desktop`: This controls how the terminal should interact with virtual desktops.
-  - `"any"`: Leave the window on whatever desktop it's already on - we'll switch
-    to that desktop as we activate the window.
-    - > NOTE: A previous version of this spec had this enum value as `null`.
-      This was changed to `"any"` for parity with the `monitor` property.
-  - `"toCurrent"`/omitted: (_default_): Move the window **to** the current
-    virtual desktop
-  - `"onCurrent"`: Only summon the window if it's **already on** the current
-    virtual desktop
-
-Neither `desktop` nor `monitor` is a required parameter - if either is omitted,
-the omitted property will default to `toCurrent`.
-
-Together, these settings interact in the following ways:
-
-<!-- This table is formatted for viewing as rendered HTML. It's too complicated
-for pure markdown, sorry. -->
-<table>
-<tr>
-<td></td>
-<th colspan=3><code>"desktop"</code></th>
-</tr>
-<!-- ----------------------------------------------------------------------- -->
-<tr>
-<th><code>"monitor"</code></th>
-<td><code>any</code><br><strong>Leave where it is</strong></td>
-<td><code>"toCurrent"</code><br><strong>Move to current desktop</strong></td>
-<td><code>"onCurrent"</code><br><strong>On current desktop only</strong></td>
-</tr>
-<!-- ----------------------------------------------------------------------- -->
-<tr>
-<td><code>"any"</code><br> Summon the MRU window</td>
-
-<td>Go to the desktop the window is on  (leave position alone)</td>
-<td>Move the window to this desktop (leave position alone)</td>
-<td>
-
-If there isn't one on this desktop:
-* create a new one (default position)
-
-Else:
-* activate the one on this desktop (don't move it)
-</td>
-</tr>
-<!-- ----------------------------------------------------------------------- -->
-<tr>
-<td><code>"toCurrent"</code><br> Summon the MRU window TO the monitor with the foreground window</td>
-<td>Go to the desktop the window is on, move to the monitor with the foreground window</td>
-<td>Move the window to this desktop, move to the monitor with the foreground window</td>
-<td>
-
-If there isn't one on this desktop:
-* create a new one (on the monitor with the foreground window)
-
-Else:
-* activate the one on this desktop, move to the monitor with the foreground window
-</td>
-</tr>
-<!-- ----------------------------------------------------------------------- -->
-<tr>
-<td>
-  <code>"toMouse"</code>
-  <sup><a href="#footnote-2">[2]</a></sup> <br>
-  Summon the MRU window TO the monitor with the mouse</td>
-<td>Go to the desktop the window is on, move to the monitor with the mouse</td>
-<td>Move the window to this desktop, move to the monitor with the mouse</td>
-<td>
-
-If there isn't one on this desktop:
-* create a new one (on the monitor with the mouse)
-
-Else:
-* activate the one on this desktop, move to the monitor with the mouse
-</td>
-</tr>
-<!-- ----------------------------------------------------------------------- -->
-<tr>
-<td><code>"onCurrent"</code><br> Summon the MRU window for the current monitor</td>
-<td>
-
-If there is a window on this monitor on any desktop,
-* Go to the desktop the window is on (leave position alone)
-
-else
-* Create a new window on this monitor  & desktop
-</td>
-<td>
-
-If there is a window on this monitor on any desktop,
-* Move the window to this desktop (leave position alone)
-
-else
-* Create a new window on this monitor  & desktop
-</td>
-<td>
-
-If there isn't one on this desktop, (even if there is one on this monitor on
-another desktop),
-* create a new one on this monitor
-
-Else if ( there is one on this desktop, not this monitor)
-* create a new one on this monitor
-
-Else (one on this desktop & monitor)
-* Activate the one on this desktop (don't move)
-</td>
-</tr>
-<!-- ----------------------------------------------------------------------- -->
-<tr>
-<td><code>int</code><br> Summon the MRU window for monitor N</td>
-<td>
-
-If there is a window on monitor N on any desktop,
-* Go to the desktop the window is on (leave position alone)
-
-else
-* Create a new window on this monitor  & desktop
-</td>
-<td>
-
-If there is a window on monitor N on any desktop,
-* Move the window to this desktop (leave position alone)
-
-else
-* Create a new window on this monitor & desktop
-</td>
-<td>
-
-If there isn't one on this desktop, (even if there is one on monitor N on
-another desktop),
-* create a new one on monitor N
-
-Else if ( there is one on this desktop, not monitor N)
-* create a new one on monitor N
-
-Else (one on this desktop & monitor N)
-* Activate the one on this desktop (don't move)
-</td>
-</tr>
-</table>
-
-
-##### Stories, revisited
-
-With the above settings, let's re-examine the original user stories, and see how
-they fit into the above settings. (_Stories that are omitted aren't relevant to
-the discussion of these settings_)
-
-> When the `desktop` param is omitted below, that can be interpreted as "any
-> `desktop` value will make sense here"
-
-* **Story A** Press a hotkey anywhere to activate the single Terminal window
-  wherever it was
-  - This is `{ "monitor": "any", "desktop": "any" }`
-* **Story B** Press a hotkey anywhere to activate the single Terminal window _on
-  the current monitor_. If it wasn't previously on that monitor, move it there.
-  - This is `{ "monitor": "toCurrent" }`
-* **Story D** <kbd>Ctrl+1</kbd> to activate the terminal on monitor 1,
-  <kbd>Ctrl+2</kbd> to activate the terminal on monitor 2.
-  - This is `[ { "keys": "ctrl+1", monitor": 1 }, { "keys": "ctrl+2", monitor": 2 } ]`
-
-As some additional examples:
-
-```json
-// Go to the MRU window, wherever it is
-{ "keys": "win+1", "command":{ "action":"globalSummon", "monitor":"any", "desktop": "any" } },
-
-// activate the MRU window, and move it to this desktop & this monitor
-{ "keys": "win+2", "command":{ "action":"globalSummon", "monitor":"toCurrent", "desktop": "toCurrent" } },
-// Since "toCurrent" & "toCurrent" are the default values, just placing a single
-// entry here will bind the same behavior:
-{ "keys": "win+2", "command": "globalSummon" },
-
-// activate the MRU window on this desktop
-{ "keys": "win+3", "command":{ "action":"globalSummon", "monitor":"any", "desktop": "onCurrent" } },
-
-// Activate the MRU window on monitor 2 (from any desktop), and place it on the
-// current desktop. If there isn't one on monitor 2, make a new one.
-{ "keys": "win+4", "command":{ "action":"globalSummon", "monitor": 2, "desktop": "toCurrent" } },
-
-// Activate the MRU window on monitor 3 (ONLY THIS desktop), or make a new one.
-{ "keys": "win+5", "command":{ "action":"globalSummon", "monitor": 3, "desktop": "onCurrent" } },
-
-// Activate the MRU window on this monitor (from any desktop), and place it on
-// the current desktop. If there isn't one on this monitor, make a new one.
-{ "keys": "win+6", "command":{ "action":"globalSummon", "monitor": "onCurrent", "desktop": "toCurrent" } },
-```
-
-#### Summoning a specific window
-
-What if you want to press a keybinding to always summon a specific, named
-window? This window might not be the most recent terminal window, nor one that
-would be selected by the `monitor` and `desktop` selectors. You could name a
-window "Epona", and press `win+e` to always summon the "Epona" window.
-
-We'll add the following property to address this scenario
-
-* `"window": string|int`
-  - When omitted (_default_): Use monitor and desktop to find the appropriate
-    MRU window to summon.
-  - When provided: Always summon the window who's name or ID matches the given
-    `window` value. If no such window exists, then create a new window with that
-    name/id.
-
-When provided _with_ `monitor` and `desktop`, `window` behaves in the following
-ways:
-* `desktop`
-  - `"any"`: Go to the desktop the given window is already on.
-  - `"toCurrent"`: If the window is on another virtual desktop, then move it to
-    the currently active one.
-  - `"onCurrent"`: If the window is on another virtual desktop, then move it to
-    the currently active one.
-* `monitor`
-  - `"any"`: Leave the window on the monitor it is already on.
-  - `"toCurrent"`: If the window is on another monitor, then move it to the
-    currently active one.
-  - `"onCurrent"`: If the window is on another monitor, then move it to the
-    currently active one.
-  - `<int>`: If the window is on another monitor, then move it to the specified
-    monitor.
-
-> NOTE: You read that right, `onCurrent` and `toCurrent` both do the same thing
-> when `window` is provided. They both already know which window to select, the
-> context of moving to the "current" monitor is all that those parameters add.
-
-#### Other properties
-
-Some users would like the terminal to just appear when the global hotkey is
-pressed. Others would like the true quake-like experience, where the terminal
-window "slides-in" from the top of the monitor. Furthermore, some users would
-like to configure the speed at which that dropdown happens. To support this
-functionality, the `globalSummon` action will support the following property:
-
-* `"dropdownDuration": float`
-  - When omitted, `0`, or a negative number: No animation is used
-    when summoning the window. The summoned window is focused immediately where
-    it is.
-  - When a positive number is provided, the terminal will use that value as a
-    duration (in seconds) to slide the terminal into position when activated.
-  - The default would be some sensible value. The pane animation is .2s, so
-    `0.2` might be a reasonable default here.
-
-We could have alternatively provided a `"dropdownSpeed"` setting, that provided
-a number of pixels per second. In my opinion, that would be harder for users to
-use correctly. I believe that it's easier for users to mentally picture "I'd
-like the dropdown to last 100ms" vs "My monitor is 1504px tall, so I need to set
-this to 15040 to make the window traverse the entire display in .1s"
-
-> NOTE: `dropdownDuration` will be ignored when the user has animations disabled
-> in the OS. In that case, the terminal will just appear, as if it was set to 0.
-
-Some users might want to be able to use the global hotkey to hide the window
-when the window is already visible. This would let the hotkey act as a sort of
-global toggle for the Terminal window. Others might not like that behavior, and
-just want the action to always bring the Terminal into focus, and do nothing if
-the terminal is already focused. To facilitate both these use cases, we'll add
-the following property:
-
-* `"toggleVisibility": bool`
-  - When `true`: (_default_) When this hotkey is pressed, and the terminal
-    window is currently active, minimize the window.
-      - When `dropdownDuration` is not `0`, then the window will slide back off
-        the top at the same speed as it would come down.
-  - When `false`: When this hotkey is pressed, and the terminal window is
-    currently active, do nothing.
-
-### Quake Mode
-
-In addition to just summoning the window from anywhere, some terminals also
-support a special "quake mode" buffer or window. This window is one that closely
-emulates the console from quake:
-* It's docked to the top of the screen
-* It takes the full width of the monitor, and only the bottom can be resized
-* It often doesn't have any other UI elements, like tabs
-
-For fun, we'll also be adding a special `"_quake"` window with the same
-behavior. If the user names a window `_quake`, then it will behave in the
-following special ways:
-
-* On launch, it will ignore the `initialPosition` and
-  `initialRows`/`initialCols` setting, and instead resize to the top half of the
-  monitor.
-* On launch, it will ignore the `launchMode` setting, and always launch in focus
-  mode.
-  - Users can disable focus mode on the `_quake` window if they do want tabs.
-* It will not be resizable from any side except the bottom of the window, nor
-  will it be drag-able.
-* It will not be a valid target for the "most recent window" for window
-  glomming. If it's the only open window, with `"windowingBehavior":
-  "useExisting*"`, then a new window will be created instead.
-  - It _is_ still a valid target for something like `wt -w _quake new-tab`
-
-A window at runtime can be renamed to become the `_quake` window (if no other
-`_quake` window exists). When it does, it will resize to the position of the
-quake window, and enter focus mode.
-
-We'll also be adding a special action `quakeMode`. This action is a special case
-of the `globalSummon` action, to specifically invoke the quake window in the
-current place. It is basically the same thing as the more elaborate:
-
-```json
-{
-    "monitor": "toCurrent",
-    "desktop": "toCurrent",
-    "window": "_quake",
-    "toggleVisibility": true,
-    "dropdownDuration": 0.5
-},
-```
-
-### Minimize to Tray
-
-Many users have requested that the terminal additionally supports minimizing the
-window "to the tray icon". This is a bit like when you close the Teams window,
-but Teams is actually still running in the system tray, or the "notification
-area".
-
-![The Teams tray icon](tray-icon-000.png)
-
-_fig 1: an example of the Teams tray icon in the notification area_.
-
-When users want to be able to "minimize to the tray", they want:
-* The window to no longer appear on the taskbar
-* The window to no longer appear in the alt-tab order
-
-When minimized to the tray, it's almost as if there's no window for the Terminal
-at all. This can be combined with the global hotkey (or the tray icon's context
-menu) to quickly restore the window.
-
-The tray icon could be used for a variety of purposes. As a simple start, we
-could include the following three options:
-
-```
-Focus Terminal
---
-Windows > Window 1 - <un-named window>
-          Window 2 - "This-window-does-have-a-name"
---
-Quit
-```
-
-Just clicking on the icon would summon the recent terminal window. Right
-clicking would show the menu with "Focus Terminal", "Windows" and "Quit" in it, and
-"Windows" would have nested entries for each Terminal window.
-
-* "Focus Terminal" would do just that - summon the most recent terminal window,
-  wherever it is.
-* "Windows" would have nested popups for each open Terminal window. Each of
-  these nested entries would display the name and ID of the window. Clicking
-  them would summon that window (wherever it may be)
-* "Quit" would be akin to quit in browsers - close all open windows
-  <sup>[[1]](#footnote-1)</sup>.
-
-The tray notification would be visible always when the user has
-`"minimizeToTray": true` set in their settings. If the user has that set to
-false, but would still like the tray, they can specify `"alwaysShowTrayIcon":
-true`. That will cause the tray icon to always be added to the system tray.
-
-There's not a combination of settings where the Terminal is "minimized to the
-tray", and there's _no tray icon visible_. We don't want to let users get into a
-state where the Terminal is running, but is totally hidden from their control.
-
-From a technical standpoint, the tray icon is managed similar to the global
-hotkey. The Monarch process is responsible for setting it up, and processing the
-messages. When a Monarch dies and a new process becomes the Monarch, then it
-will re-create the tray icon.
-
-## UI/UX Design
-
-To summarize, we're proposing the following set of settings:
-
-```jsonc
-{
-    "minimizeToTray": bool,
-    "alwaysShowTrayIcon": bool,
-    "actions": [
-        {
-            "keys": KeyChord,
-            "command": {
-                "action": "globalSummon",
-                "dropdownDuration": float,
-                "toggleVisibility": bool,
-                "monitor": "any"|"toCurrent"|"onCurrent"|int,
-                "desktop": "any"|"toCurrent"|"onCurrent"
-            }
-        },
-        {
-            "keys": KeyChord,
-            "command": {
-                "action": "quakeMode"
-            }
-        }
-    ]
-}
-```
-
-## Potential Issues
-
-<table>
-
-<tr>
-<td><strong>Compatibility</strong></td>
-<td>
-
-As part of this set of changes, we'll also be allowing the <kbd>Win</kbd> key in
-keybindings. Generally, the OS reserves the Windows key for its own shortcuts.
-For example, <kbd>Win+R</kbd> for the run dialog, <kbd>Win+A</kbd> for the
-Action Center, <kbd>Win+V</kbd> for the cloud clipboard, etc. Users will now be
-able to use the win key themselves, but they should be aware that the OS has
-"first dibs" on any hotkeys involving the Windows key.
-
-</td>
-</tr>
-<tr>
-<td><strong>Mixed elevation</strong></td>
-<td>
-
-Only one app at a time gets to register for global hotkeys. However, from the
-Terminal's perspective, unelevated and elevated windows will act like different
-apps. Each privilege level has its own Monarch. The two are unable to
-communicate across the elevation boundary.
-
-This means that if the user often runs terminals in both contexts, then only one
-will have the global hotkeys bound. The naive implementation would have the
-first elevation level "win" the keybindings.
-
-A different option would be to have elevated windows not register global hotkeys
-_at all_. I don't believe that there's any sort of security implication for
-having a global hotkey for an elevated window.
-
-A third option would be to have some sort of `"whenElevated": bool?` property
-for global hotkeys. This would explicitly enable a given hotkey for unelevated
-vs elevated windows.
-* `"whenElevated": null`: behave as normal - the first context level to run wins
-* `"whenElevated": true`: only register the hotkey when running elevated
-* `"whenElevated": false`: only register the hotkey when running unelevated
-
-</td>
-</tr>
-<tr>
-<td><strong>OneCore / Windows 10X</strong></td>
-<td>
-
-I'm fairly certain that none of these APIs would work on Windows 10X at all.
-These features would have to initially be disabled in a pure UWP version of the
-Terminal, until we could find workarounds. Since the window layer is the one
-responsible for the management of the hotkeys and the tray icon, we're not too
-worried about this.
-
-</td>
-</tr>
-</table>
-
-* If there are any other applications running that have already registered
-  hotkeys with `RegisterHotKey`, then it's possible that the Terminal's attempt
-  to register that hotkey will fail. If that should happen, then we should
-  display a warning dialog to the user indicating which hotkey will not work
-  (because it's already used for something else).
-
-* Which is the "current" monitor? The one with the mouse or the one with the
-  active window? This isn't something that has an obvious answer. Guake
-  implements this feature where the "current monitor" is the one with the mouse
-  on it. At least for the first iterations of this action, that's what we'll
-  use.
-  `monitor: onCurrent|onCurrentWindow|toCurrent|<int>`
-
-* Currently, running both the Release and Preview versions of the Terminal at
-  the same time side-by-side is not generally supported. (For example, `wt.exe`
-  can only ever point at one of two.) If a user binds the same key to a
-  `globalSummon` or `quakeMode` action, then only one of the apps will actually
-  be able to successfully claim the global hotkey.
-
-## Implementation plan
-
-Currently, in [`dev/migrie/f/653-QUAKE-MODE`], I have some sample rudimentary
-code to implement quake mode support. It allows for only a single global hotkey
-that summons the MRU window, without dropdown. That would be a good place for
-anyone starting to work on this feature. From there, I imagine the following
-work would be needed:
-
-* [ ] Add a `globalSummon` action. `AppHost` would need to be able to get _all_
-  of these actions, and register all of them. Each one would need to be assigned
-  a unique ID, so `WM_HOTKEY` can identify which hotkey was pressed.
-    - This could be committed without any other args to the `globalHotkeys`. In
-      this initial version, the behavior would be summoning the MRU window,
-      where it is, no dropdown, to start with. From there, we'd add the
-      remaining properties:
-    * [ ] Add support for the `toggleVisibility` property
-    * [ ] Add support for the `desktop` property to control how window summoning
-      interacts with virtual desktops
-    * [ ] Add support for the `monitor` which monitor the window appears on.
-    * [ ] Add support for the `dropdownDuration` property
-* [ ] Add the `minimizeToTray` setting, and implement it without any sort of flyout
-    * [ ] Add a list of windows to the right-click flyout on the tray icon
-    * [ ] Add support for the `alwaysShowTrayIcon` setting
-* [ ] When the user creates a window named `_quake`, ignore the initial size,
-  position, and launch mode, and create the window in quake mode instead.
-    * [ ] Exempt the `_quake` window from window glomming
-    * [ ] Add the `quakeMode` action, which `globalSummon`'s the `_quake` window.
-    * [ ] Prevent the `_quake` window from being dragged or resized on the
-      top/left/right.
-
-
-### Future Considerations
-
-I don't believe there are any other tracked requests that are planned that
-aren't already included in this spec.
-
-* Should the tray icon's list of windows include window titles? Both the name
-  and title? Maybe something like `({name}|{id}): {title}`? I'd bet that most
-  people don't end up naming their windows.
-* Dropdown duration could be a `float|bool`, with `true`->(whatever the default
-  is), `false`->0.
-  - We could have the setting appear as a pair of radio buttons, with the first
-    disabling dropdown, and the second enabling a text box for inputting an
-    animation duration.
-* It might be an interesting idea to have the ability to dock the quake window
-  to a specific side of the monitor, not just the top. We could probably do that
-  with a global setting `"quakeModeDockSide": "top"|"left"|"bottom"|"right"` or
-  something like that.
-* We might want to pre-load the quake window into the tray icon as an entry for
-  "Quake Mode", and otherwise exclude it from the list of windows in that menu.
-* We might think of other things for the Quake Mode window in the future - this
-  spec is by no means comprehensive. For example, it might make sense for the
-  quake mode window to automatically open in "always on top" mode.
-* It was suggested that the quake mode window could auto-hide when it loses
-  focus. That's a really neat idea, but we're a little worried about the
-  implementation. What happens when the IME window gets focus? Or the Start
-  Menu? Would those end up causing the quake window to prematurely minimize
-  itself? For that reason, we're leaving this as a future consideration.
-* Perhaps there could be a top-level object in the settings like
-  ```json
-  {
-    "quakeMode": {
-        "hideOnFocusLost": true,
-        "useFocusMode": false,
-        "profile": "my quake mode profile" ,
-        "quakeModeDockSide": "bottom"
-    }
-  }
-  ```
-  That would allow the user some further customizations on the quake mode
-  behaviors.
-  - This was later converted to the idea in [#9992] - Add per-window-name global
-    settings
-* Another proposed idea was a simplification of some of the summoning modes. `{
-  "monitor": "any", "desktop": "any" }` is a little long, and maybe not the most
-  apparent naming. Perhaps we could add another property like `summonMode` that
-  would act like an alias for a `monitor`, `desktop` combo.
-  - `"summonMode": "activateInMyFace"`: `{ "monitor": "toCurrent", "desktop": "toCurrent" }`
-  - `"summonMode": "activateWherever"`: `{ "monitor": "any", "desktop": "any" }`
-
-
-## Resources
-
-Docs on adding a system tray item:
-* https://docs.microsoft.com/en-us/windows/win32/shell/notification-area
-* https://www.codeproject.com/Articles/18783/Example-of-a-SysTray-App-in-Win32
-
-Docs regarding hiding a window from the taskbar:
-* https://docs.microsoft.com/en-us/previous-versions//bb776822(v=vs.85)#managing-taskbar-buttons
-
-### Footnotes
-
-<a name="footnote-1"><a>[1]: Quitting the terminal is different than closing the
-windows one-by-one. Quitting implies an atomic action, for closing all the
-windows. Once [#766] lands, this will give us a chance to persist the state of
-_all_ open windows. This will allow us to re-open with all the user's windows,
-not just the one that happened to be closed last.
-
-<a name="footnote-2"><a>[2]: **Addenda, May 2021**: In the course of
-implementation, it became apparent that there's an important UX difference
-between summoning _to the monitor with the cursor_ vs _to the monitor with the
-foreground window_. `"monitor": "toMouse"` was added as an option, to allow the
-user to differentiate between the two behaviors.
-
-[#653]: https://github.com/microsoft/terminal/issues/653
-[#766]: https://github.com/microsoft/terminal/issues/766
-[#5727]: https://github.com/microsoft/terminal/issues/5727
-[#9992]: https://github.com/microsoft/terminal/issues/9992
-
-[Process Model 2.0 Spec]: https://github.com/microsoft/terminal/blob/main/doc/specs/%235000%20-%20Process%20Model%202.0/%235000%20-%20Process%20Model%202.0.md
-[Quake 3 sample]: https://youtu.be/ZmR6HQbuHPA?t=27
-[`RegisterHotKey`]: https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-registerhotkey
-[`dev/migrie/f/653-QUAKE-MODE`]: https://github.com/microsoft/terminal/tree/dev/migrie/f/653-QUAKE-MODE
--- a/Mode/tray-icon-000.png
+++ b/Mode/tray-icon-000.png
--- a/doc/specs/#6899
+++ b/doc/specs/#6899
@@ -26,7 +26,7 @@ This spec was largely inspired by the following diagram from @DHowett:
 ![figure 1](data-mockup.png)

 The goal is to introduce an `id` parameter by which actions could be uniquely
-referred to. If we'd ever like to use an action outside the list of `actions`, we
+refered to. If we'd ever like to use an action outside the list of `actions`, we
 can simply refer to the action's ID, allowing the user to only define the action
 _once_.

--- a/Page/add-click.png
+++ b/Page/add-click.png
--- a/Show More
+++ b/Show More