fix typos in dev docs (#7860)

* typo fixes and styling

* fix typos

developer-docs/architecture/resource-registration.md

@@ -18,7 +18,7 @@ of these components is a participant in the response to a `RegisterResourceReque
 
 ## The Resource Monitor
 
-The _resource monitor_ provides serves the `ResourceMonitor` gRPC interface, and provides a shim between language SDKs
+The _resource monitor_ provider serves the `ResourceMonitor` gRPC interface, and provides a shim between language SDKs
 and the rest of the engine. There is a single resource monitor per deployment. As the engine's feature set has grown,
 the resource monitor has taken on responsibilities beyond its original use as a simple marshaling/unmarshaling layer.
 It is now responsible for handling default providers (providers for resource registrations that do not reference a
@@ -62,7 +62,7 @@ RegisterResourceRequest{
 }
 ```
 
-Becuase this request does not contain a value for the `provider` field, it will use the default provider for the
+Because this request does not contain a value for the `provider` field, it will use the default provider for the
 `aws` package at version 4.16.0. The resource monitor ensures that only a single default provider instance exists
 for each particular package version, and only creates default provider instances if they are needed. Default provider
 instances are registered by synthesizing an appropriate `RegisterResourceEvent` with input properties sourced from the
@@ -116,31 +116,31 @@ When the step generator receives a `RegisterResourceEvent`, it does the followin
    states.
 3. Pre-process input properties for ignored changes by setting any properties mentioned in the event's ignore changes
    list to their old value (if any)
-4. If the event indicates that the resource should be imported, issue an `ImportStep` to the [step exectuor] and return.
+4. If the event indicates that the resource should be imported, issue an `ImportStep` to the [step executor] and return.
 5. Call the resource's provider's `Check` method with the event's input properties and the resource's existing inputs,
    if any. The existing inputs may be used by the provider to repopulate default values for input properties that are
    automatically generated when the resource is created but should not be changed with subsequent updates (e.g.
    automatically generated names). `Check` returns a pre-processed bag of input values to be used with later calls to
    `Diff`, `Create`, and `Update`.
 6. Invoke any analyzers for the stack to perform additional validation of the resource's input properties.
-7. If the resource has no existing state, it is being created. Issue a `CreateStep` to the [step exectuor] and return.
+7. If the resource has no existing state, it is being created. Issue a `CreateStep` to the [step executor] and return.
 8. Diff the resource in order to determine whether it must be updated, replaced, delete-before-replaced, or has no
    changes. Diffing is covered in detail later on, but typically consists of calling the reosource's provider's
    `Diff` method with the checked inputs from step 5.
-9. If the resource has no changes, issue a `SameStep` to the [step exectuor] and return.
-10. If the resource is not being replaced, issue an `UpdateStep` to the [step exectuor] and return.
+9. If the resource has no changes, issue a `SameStep` to the [step executor] and return.
+10. If the resource is not being replaced, issue an `UpdateStep` to the [step executor] and return.
 11. If the resource is being replaced, call the resource's provider's `Check` method again, but with no existing
     inputs. This call ensures that the input properties used to create the replacement resource do not reuse
     generated defaults from the existing resource.
 12. If the replacement resource is being created before the original is deleted (a normal replacement), issue a
-    `CreateStep` and a `DeleteStep` to the [step exectuor] and return.
+    `CreateStep` and a `DeleteStep` to the [step executor] and return.
 13. At this point, the resource must be deleted before its replacement is created (this is the "delete-before-replace"
     case). Calculate the set of dependent resources that must be deleted prior to deleting the resource being replaced.
     The details of this calculation are covered in a later section. Once the set of deletions has been calculated,
-    issue a sequence of `DeleteStep`s followed by a single `CreateStep` to the [step exectuor].
+    issue a sequence of `DeleteStep`s followed by a single `CreateStep` to the [step executor].
 
 Note that all steps that are issued to the step generator are fire-and-forget. Once steps have been issues, the step
-generator moves on to process the next `RegisterResourceEvent`. It is the responsibility of the [step exectuor] to
+generator moves on to process the next `RegisterResourceEvent`. It is the responsibility of the [step executor] to
 communicate the results of each step back to the [resource monitor].
 
 Once the Pulumi program has exited, the step generator determines which existing resources must be deleted by taking
@@ -149,28 +149,28 @@ for deletion by first sorting the list of resources to delete using the topologi
 grapth, then decomposing the list into a list of lists where each list can be executed in parallel but a previous list
 must be executed to completion before advancing to the next list.
 
-In lieu of tracking per-step dependencies and orienting the [step exectuor] around these dependencies, this approach
-provides a conservative approximation of what deletions can safely occur in parallel. The insight here is that the
+In lieu of tracking per-step dependencies and orienting the [step executor] around these dependencies, this approach
+provides a conservative approximation of which deletions can safely occur in parallel. The insight here is that the
 resource dependency graph is a partially-ordered set and all partially-ordered sets can be easily decomposed into
 antichains--subsets of the set that are all not comparable to one another (in this definition, "not comparable"
 means "do not depend on one another").
 
 The algorithm for decomposing a poset into antichains is:
 
-1. While there exist elements in the poset,
-	a. There must exist at least one "maximal" element of the poset. Let `E_max` be those elements.
-	b. Remove all elements E_max from the poset. `E_max` is an antichain.
+1. While there exist elements in the poset, \
+	a. There must exist at least one "maximal" element of the poset. Let `E_max` be those elements. \
+	b. Remove all elements E_max from the poset. `E_max` is an antichain. \
 	c. Goto 1.
 
 Translated to a resource dependency graph:
 
-1. While the set of condemned resources is not empty:
-	a. Remove all resources with no outgoing edges from the graph and add them to the current antichain.
+1. While the set of condemned resources is not empty: \
+	a. Remove all resources with no outgoing edges from the graph and add them to the current antichain. \
 	b. Goto 1.
 
 The resulting list of antichains is a list of list of delete steps that can be safely executed in parallel. Since
 deletes must be processed in reverse order (so that resources are not deleted prior to their dependents), the step
-generator reverses the list and then issues each sublist to the [step exectuor].
+generator reverses the list and then issues each sublist to the [step executor].
 
 ### Resource Diffing
 
@@ -205,7 +205,7 @@ This is perhaps clearer when described by example. Consider the following depend
 
 ![Delete-before-replace example graph](./delete-before-replace-graph.svg)
 
-In this graph, all of B, C, D, E, and F transitively depend on A. It may be the case,however, that changes to the
+In this graph, all of B, C, D, E, and F transitively depend on A. It may be the case, however, that changes to the
 specific properties of any of those resources R that would occur if a resource on the path to A were deleted and
 recreated may not cause R to be replaced. For example, the edge from B to A may be a simple `dependsOn` edge such that
 a change to B does not actually influence any of B's input properties.  More commonly, the edge from B to A may be due

developer-docs/providers/implementers-guide.md

@@ -110,7 +110,7 @@ resource must be inspected, the reference must be resolved by invoking the `getR
 function of the engine's builtin provider. Note that this is only possible if there is a 
 connection to the engine's resource monitor, e.g. within the scope of a call to `Construct`.
 This implies that resource references may not be resolved within calls to other 
-provider methods. Therefore, configuration vales, custom resources and provider functions
+provider methods. Therefore, configuration values, custom resources and provider functions
 should not rely on the ability to resolve resource references, and should instead treat
 resource references  as either their ID (if present) or URN. If the ID is present and
 empty, it should be treated as an [`Unknown`](#unknowns).
@@ -126,7 +126,7 @@ that cannot be determined until the resource is actually created or updated.
 
 A `Secret` represents a value whose contents are sensitive. Values of this type are 
 merely wrappers around the sensitive value. A provider should take care not to leak a
-secret value. and should wrap any resource output values that are always sensitive in a
+secret value, and should wrap any resource output values that are always sensitive in a
 `Secret`. [Functions](#functions) must not accept or return secret values.
 
 #### Property Paths
@@ -411,7 +411,7 @@ clients:
                 top-level output properties that are guaranteed not to change.
 - `changedKeys`: the list of top-level input property names that changed.
 
-If a provider is unble to compute a diff because its configuration contained
+If a provider is unable to compute a diff because its configuration contained
 [`Unknown`s](#unknowns), it can return an error that indicates as such. The client should
 conservatively assume that the resource must be updated and warn the user.