Misc edits #bruce #time 30m

Chapters/03_Superpowers.md

@@ -477,7 +477,7 @@ val run = effect8
 Having 2 versions of `run` seems confusing, but they serve different purposes:
 - Attaching `.run` to Effects in a `defer` establishes the order of execution for that Effect.
   This can happen many times throughout your program.
-- Assigning an Effect to `def run` executes that effect as the program.
+- Assigning an Effect to `def run` executes that Effect as the program.
   This typically happens only once in your code.
 
 ### The `.run` Method

Chapters/04_Initialization.md

@@ -82,7 +82,7 @@ The `succeed` method produces such an Effect; it is available for both regular Z
 So `purchased` creates a `BreadStoreBought` object and turns it into a successful `ZLayer` Effect.
 
 You can think of a `ZLayer` as a more-powerful constructor.
-Like `ZIO` effects, they are deferred, so merely referencing `BreadStoreBought.purchased` will not construct anything.
+Like `ZIO` Effects, they are deferred, so merely referencing `BreadStoreBought.purchased` will not construct anything.
 This `ZLayer` provides the `BreadStoreBought` instance as a dependency to any other Effect that needs it.
 
 Now we incorporate the `BreadStoreBought` dependency into a program:

Chapters/06_Failure.md

@@ -10,12 +10,12 @@ Exceptions were a big step forward:
 
 - They provide unified error reporting--there's only one way to do it.
 - Errors cannot be ignored--they flow upward until caught or displayed on the console with program termination.
-- They are a standardized way to correct problems, so an operation can recover and retry.
+- Exceptions are a standardized way to correct problems, so an operation can recover and retry.
 - Errors can be handled close to the origin, or generalized by catching them "further out" so that multiple error sources can be managed with a single handler.
 - Exception hierarchies allow more general exception handlers to handle multiple exception subtypes.
 
 Exceptions were certainly an improvement over previous attempts to solve the error reporting problem. 
-Eventually, however, programmers began encountering pain points. 
+Eventually, however, programmers encountered pain points. 
 As is often the case, this happened as we tried to scale up to create larger and more complex systems. 
 The underlying issue was _composability_, which takes smaller parts and assembles them into larger parts.
 
@@ -418,7 +418,7 @@ The compiler reports that we included unusable code.
 
 ## Mixed Failure Types
 
-An Effect can produce different types of failures, so we must manage all of them. 
+If an Effect produces different types of failures, we must manage all of them. 
 
 Consider a `check` Effect (implementation hidden) that fails with a custom type `ClimateFailure`:
 
@@ -466,7 +466,7 @@ val weatherReportFaulty =
     check(result).run
 ```
 
-`getTemperature` can produce `ZIO.fail` effects containing `NetworkException` or `GpsException`, while `check` can produce a `ZIO.fail` containing `ClimateFailure`.
+`getTemperature` can produce `ZIO.fail` Effects containing `NetworkException` or `GpsException`, while `check` can produce a `ZIO.fail` containing `ClimateFailure`.
 To handle all failures for `weatherReportFaulty`, we provide cases for both `Exception` and `ClimateFailure`:
 
 ```scala 3 mdoc:silent