docs: fix typos across documentation and specs

documentation/Logging-behavior.md

@@ -34,7 +34,7 @@ Console logger refers to the logger that outputs to the console in VS or the ter
 
 The console logger is a 1:1 textual representation of the data that are emitted during the build. It attempts small amounts of formatting, but it writes received messages from all of the worker nodes in an unbuffered format so can be difficult to follow the chain of execution.
 
-The console logger defaults to normal verbosity, and can be overriden by passing the `-verbosity` attribute, or passing the `verbosity` property to the console logger `clp:verbosity={verbosity level}`.
+The console logger defaults to normal verbosity, and can be overridden by passing the `-verbosity` attribute, or passing the `verbosity` property to the console logger `clp:verbosity={verbosity level}`.
 
 | Verbosity                  | Quiet | Minimal | Normal | Detailed | Diagnostic |
 | ---------                  | ----- | ------- | ------ | -------- | ---------- |

documentation/Persistent-Problems.md

@@ -6,7 +6,7 @@ MSBuild-driven builds are no exception.
 
 ## Evaluation
 
-*Every* [batch build]() (absent a higher-order build system) must evaluate every project in the scope of the build. IDEs can cache evaluation and act as a higher-order builds sytem but important IDE scenarios like “first load after a repo clone” are dominated by evaluation.
+*Every* [batch build]() (absent a higher-order build system) must evaluate every project in the scope of the build. IDEs can cache evaluation and act as a higher-order builds system but important IDE scenarios like “first load after a repo clone” are dominated by evaluation.
 
 ## ResolveAssemblyReferences
 

documentation/specs/project-cache.md

@@ -165,9 +165,9 @@ In the very first build there will be no cache hits so the "cache add" scenario
 
 For a given project, `GetCacheResultAsync` will be invoked, but will end up returning a cache miss since the cache is empty.
 
-MSBuild will then build the project normally but under a detoured worker node. Because of this, the plugin will recieve `HandleFileAccess` and `HandleProcess` events. In this example implementation we will ignore `HandleProcess`. For `HandleFileAccess`, the plugin will simply store all `FileAccessData`s for a `FileAccessContext` to build up a list of all file accesses during the build. The plugin may decide to avoid storing the entire `FileAccessData` and instead just peel off the data it finds relevant (eg. paths, whether it was a read or write, etc).
+MSBuild will then build the project normally but under a detoured worker node. Because of this, the plugin will receive `HandleFileAccess` and `HandleProcess` events. In this example implementation we will ignore `HandleProcess`. For `HandleFileAccess`, the plugin will simply store all `FileAccessData`s for a `FileAccessContext` to build up a list of all file accesses during the build. The plugin may decide to avoid storing the entire `FileAccessData` and instead just peel off the data it finds relevant (eg. paths, whether it was a read or write, etc).
 
-Once MSBuild is done building the project, it will call the plugin's `HandleProjectFinishedAsync`. Now the plugin knows the project is done and can process the results and add them to a cache. In general it's only useful to cache successful results, so the plugin should filter out non-success results. The `FileAccessContext` provided can then be used to retrieve the list of `FileAccessData` the plugin recieved. These `FileAccessData` can be processed to understand which files were read and written as part of the build.
+Once MSBuild is done building the project, it will call the plugin's `HandleProjectFinishedAsync`. Now the plugin knows the project is done and can process the results and add them to a cache. In general it's only useful to cache successful results, so the plugin should filter out non-success results. The `FileAccessContext` provided can then be used to retrieve the list of `FileAccessData` the plugin received. These `FileAccessData` can be processed to understand which files were read and written as part of the build.
 
 In our example, we can use the read files to construct a fingerprint for the build request. We can then add the files written during the build ("outputs") to some cache implementation.
 

documentation/specs/proposed/evaluation-perf.md

@@ -2,7 +2,7 @@
 In the current effort to improve performance of MSBuild, we identified evaluation as one of the focus areas of this effort. Evaluation is the first step when loading or building, and it determines references, how projects are connected and what needs to be build. Because of this it runs in every MSBuild scenario, from solution load and design-time builds in Visual Studio, to up-to-date builds or full builds in VS or on the command line.
 
 ## Description
-Current performance state of evaluation is mostly unkown, we have a few measures but no easy way of accessing and assessing them. As such, we are unsure which specific areas can be improve. 
+Current performance state of evaluation is mostly unknown, we have a few measures but no easy way of accessing and assessing them. As such, we are unsure which specific areas can be improve. 
 
 ## Goals and Motivation
 We are trying to make evaluation phase of the build more performant, since it is almost always executed any performance gain becomes noticeable. A performant evaluation phase would decrease build times in general, in CI cases it frees up resources, and in individual cases it can increase dev-loop performance by making up-to-date and incremental builds go faster.

documentation/specs/proposed/interactive-package-references.md

@@ -6,7 +6,7 @@ It is inspired by the golang modules design - where a standalone dependency (mod
 
 # North Star / Longer-term vision
 
-We envision the 'packages sourcing' to be a first-class-citizen within nuget client (and hence [`dotnet restore`](https://learn.microsoft.com/en-us/dotnet/core/tools/dotnet-restore)). Via denoting specific metadata on `PackageReference` it would be possible to perform specific mode of restore operation for the particular package reference - by pointing to a local sources, or letting the command to figure out and fetch apropriate sources:
+We envision the 'packages sourcing' to be a first-class-citizen within nuget client (and hence [`dotnet restore`](https://learn.microsoft.com/en-us/dotnet/core/tools/dotnet-restore)). Via denoting specific metadata on `PackageReference` it would be possible to perform specific mode of restore operation for the particular package reference - by pointing to a local sources, or letting the command to figure out and fetch appropriate sources:
 
 ```xml
 <Project Sdk="Microsoft.NET.Sdk">

documentation/specs/proposed/security-metadata.md

@@ -118,7 +118,7 @@ An opt-out mechanism would allow usage of properly denoted tasks with plain stri
 There needs to be a way how user specifies which data should be redacted from logs. We have several options:
 
  * New data type - this is part of the [North Star vision](#north-star--longer-term-vision), but is out of scope for the initial iteration.
- * [Not recomended] Denoting those via some metadata on a definition of the data to be redacted - this has two main drawbacks - a) For some data types (properties, metadata) we'd need new constructs how to attach additional info (property metadata; item meta-metadata). b) some data can be defined implicitly or dynamicaly
+ * [Not recommended] Denoting those via some metadata on a definition of the data to be redacted - this has two main drawbacks - a) For some data types (properties, metadata) we'd need new constructs how to attach additional info (property metadata; item meta-metadata). b) some data can be defined implicitly or dynamicaly
  * Property with global scope - e.g. 
    ```xml
    <DataToRedactFromLogs>Foo;Bar;Baz->SomeMetadata;MyItem->*</DataToRedactFromLogs>

documentation/specs/test-target.md

@@ -67,7 +67,7 @@ See: [MSBuild Test Task](https://github.com/microsoft/MSBuildSdks/pull/473)
 
 ### MSBuild Task Functionality
 
-- The core of this implemenation is an MSBuild task that interfaces with `vstest.console.exe`.
+- The core of this implementation is an MSBuild task that interfaces with `vstest.console.exe`.
 - This task will accept arguments as properties and pass them directly into the command line test runner.
 
 ### Using The Default Implementation

documentation/wiki/Controlling-Dependencies-Behavior.md

@@ -281,7 +281,7 @@ Should we want to reference the netstandard version of the Repository Layer in o
 
 **Notes:** 
 
-`SetTargetFramework` is currently not honored by the NuGet client([nuget issue #12436](https://github.com/NuGet/Home/issues/12436)), so the output folder will contain binaries from nuget packages as if this metadata was not used. To workaround this the apropriate nuget needs to be directly referenced from the project enforcing reference framework via `SetTargetFramework`, or copied to output/publish folder via different means.
+`SetTargetFramework` is currently not honored by the NuGet client([nuget issue #12436](https://github.com/NuGet/Home/issues/12436)), so the output folder will contain binaries from nuget packages as if this metadata was not used. To workaround this the appropriate nuget needs to be directly referenced from the project enforcing reference framework via `SetTargetFramework`, or copied to output/publish folder via different means.
 
 
 `SetTargetFramework` will properly enforce the framework for the `ProjectReference` chain. Once the `TargetFramework` overriding is encountered it is passed down the reference chain and the `ProjectReference`s respect it during the `TargetFramework` resolution. Due to the nature of handling of [transitive references in .NET-SDK style projects](#net-sdk-projects-and-access-to-transitive-references) and the fact that NuGet client doesn't honor `SetTargetFramework`, the transitive references can get resolved and built for multiple `TargetFramework`s. This means the output folder will contain proper version of the direct dependency - Repository Layer. The transitive references might overbuild, and output folder of current project (Service Layer) might contain both versions of the transitive project dependency (Domain-net48.dll and Domain-netstd20.dll). This limitation can be workarounded by switching of the transitive project references via `DisableTransitiveProjectReferences` (same as shown in [Access to transitive project references](#access-to-transitive-project-references))