docs: fix typos

DOD.md

@@ -1,4 +1,4 @@
-# Defintion of Delivery
+# Definition of Delivery
 
 The Definition of Delivery or definition of done is provide to give developers
 on direction of what is required to deliver a issue. It also helps code
@@ -45,5 +45,5 @@ Does the code accomplish the issue?
 
 Is there automated tests that reliably verify any logic added to the delivery?
 
-Is there enough documentation to satify my future self (or someone else?) to
+Is there enough documentation to satisfy my future self (or someone else?) to
 maintain this issue?

README.md

@@ -22,9 +22,9 @@ it.
 The `ao` computer is a single, unified computing environment (a
 [Single System Image](https://en.wikipedia.org/wiki/Single_system_image)),
 hosted on a heterogenous set of nodes in a distributed network. `ao` is designed
-to offer an environment in which an arbitrary number of paralell processes can
+to offer an environment in which an arbitrary number of parallel processes can
 be resident, coordinating through an open message passing layer. This message
-passing standard connects the machine's indepedently operating processes
+passing standard connects the machine's independently operating processes
 together into a 'web' -- in the same way that websites operate on independent
 servers but are conjoined into a cohesive, unified experience via hyperlinks.
 
@@ -33,7 +33,7 @@ operation of computation without protocol-enforced limitations on size and form,
 while also maintaining the verifiability (and thus, trust minimization) of the
 network itself. Further, `ao`'s distributed and modular architecture allows
 existing smart contract platforms to easily 'plug in' to the network, acting as
-a single process which can send and recieve messages from any other process.
+a single process which can send and receive messages from any other process.
 
 Instead of enforcing one set of choices upon all users of the computing
 environment, `ao` is built in a modular form: Allowing users to choose which
@@ -54,7 +54,7 @@ Due to its scalability, the natural way for developers to use `ao` is to spawn
 their own command-line (`aos`) process inside the network, and to start issuing
 commands. This DevX is similar to how developers create a new server instance at
 a cloud host and connect to it via SSH, except that this command line process
-has the properties of a smart contracts. Their commandline process on `ao`
+has the properties of a smart contract. Their commandline process on `ao`
 doesn't live in any specific data center or at any one physical location, and
 its computation is completely trustless. Every user can message and interact
 with every other process and program. The result of this is a global 'Single
@@ -95,7 +95,7 @@ and cookbook - https://cookbook_ao.arweave.dev
 - [`ao` Compute Unit (`cu`)](./servers/cu): An implementation of the `ao`
   Compute Unit, aka a `cu` (pronounced "koo" 🦘)
 - [`ao` Messenger Unit (`mu`)](./servers/mu): An implementation of the `ao`
-  Messaenger Unit, aka a `mu` (pronounced "moo" 🐄)
+  Messenger Unit, aka a `mu` (pronounced "moo" 🐄)
 - [`ao` Scheduler Unit (`su`)](./servers/su): An implementation of the `ao`
   Scheduler Unit, aka a `su` (pronounced "soo" 👧)
 - [`ao` Unit Router (`ur`)](./servers/ur): A Simple Reverse Proxy whose API can

connect/README.md

@@ -5,7 +5,7 @@ interacting with `ao` Processes.
 
 This module will run in a browser or server environment.
 
-- Read the result of an `ao` Message evaluation from a `ao` Compute Unit `cu`
+- Read the result of an `ao` Message evaluation from an `ao` Compute Unit `cu`
 - Send a Message targeting an `ao` Process to an `ao` Message Unit `mu`
 - Spawn an `ao` Process, assigning it to an `ao` Scheduler Unit `su`
 
@@ -93,13 +93,13 @@ let results = await results({
 
 Parameters
 
-| Name    | Description                                                       | Optional? |
-| ------- | ----------------------------------------------------------------- | --------- |
-| process | the process identifier                                            | false     |
-| from    | cursor starting point                                             | true      |
-| to      | cursor ending point                                               | true      |
-| sort    | list results in decending or ascending order, default will be ASC | true      |
-| limit   | the number of results to return (default: 25)                     | true      |
+| Name    | Description                                                        | Optional? |
+| ------- | ------------------------------------------------------------------ | --------- |
+| process | the process identifier                                             | false     |
+| from    | cursor starting point                                              | true      |
+| to      | cursor ending point                                                | true      |
+| sort    | list results in descending or ascending order, default will be ASC | true      |
+| limit   | the number of results to return (default: 25)                      | true      |
 
 #### `message`
 
@@ -181,7 +181,7 @@ connect() == { spawn, message, result }
 
 #### `monitor`
 
-When using cron messages, ao users need a way to start injesting the messages,
+When using cron messages, ao users need a way to start injecting the messages,
 using this monitor method, ao users can initiate the subscription service for
 cron messages.
 
@@ -229,7 +229,7 @@ const processId = await assign({
 });
 ```
 
-Create a Assignment for an `ao` process with an L1 transaction
+Create an Assignment for an `ao` process with an L1 transaction
 
 ```js
 import { assign } from "@permaweb/aoconnect";
@@ -355,7 +355,7 @@ unit test.
 
 Because the contract wrapping is done by the business logic itself, it also
 ensures the stubs we use in our unit tests accurately implement the contract
-API. Thus our unit tests are simoultaneously contract tests.
+API. Thus our unit tests are simultaneously contract tests.
 
 `client` contains implementations, of the contracts in `dal.js`, for various
 platforms. The unit tests for the implementations in `client` also import

dev-cli/README.md

@@ -24,7 +24,7 @@ SmartWeaveContracts written in [Lua](https://www.lua.org/) and
 - [For Developers](#for-developers)
   - [Contributing](#contributing)
   - [Publish a new Version of the CLI](#publish-a-new-version-of-the-cli)
-    - [Need a to also Publish a new Docker Image version?](#need-a-to-also-publish-a-new-docker-image-version)
+    - [Need to also Publish a new Docker Image version?](#need-a-to-also-publish-a-new-docker-image-version)
 
 <!-- tocstop -->
 
@@ -89,7 +89,7 @@ This will create a new directory, if needed, named `{myproject}`
 
 ### Run a Lua Repl
 
-This gives you a Lua interpeter
+This gives you a Lua interpreter
 
 ```sh
 ao lua
@@ -179,7 +179,7 @@ Workflow Dispatch that will:
 > For now, if Turbo needs more funding, contact `@TillaTheHun0`. (Maybe
 > eventually we add a Workflow Dispatch script to automatically fund Turbo)
 
-#### Need a to also Publish a new Docker Image version?
+#### Need to also Publish a new Docker Image version?
 
 If you need to also publish a new Docker Image, you will currently need to do
 this manually.

loader/README.md

@@ -165,4 +165,4 @@ To publish a new version, go to the
 [`ao` Loader workflow](https://github.com/permaweb/ao/actions/workflows/loader.yml)
 and click the `Run Workflow` button. Provide the semver compatible version you
 would like to bump to, and then click `Run Workflow`. This will trigger a
-Workflow Dispatch that will bump the version is the manifest files, build the module, and finally publish it to NPM
+Workflow Dispatch that will bump the version of the manifest files, build the module, and finally publish it to NPM

scheduler-utils/README.md

@@ -58,7 +58,7 @@ import { locate } from "@permaweb/ao-scheduler-utils";
 let { url, address } = await locate('<process-id>', 'scheduler-owner-id');
 ```
 
-This will skip querying the gateway for the process, in order to obtain it's `Scheduler` tag, and instead will directly query for the `Scheduler-Location` record.
+This will skip querying the gateway for the process, in order to obtain its `Scheduler` tag, and instead will directly query for the `Scheduler-Location` record.
 
 > This is useful when a process has just been spawned, so might not be indexed by the gateway yet.
 
@@ -86,15 +86,15 @@ const { url } = raw('<wallet-address>')
 #### Internal Cache
 
 The library maintains an internal in-memory LRU cache of `Scheduler-Location` `Url`s, caching each for their
-specified `Time-To-Live`. If a `Scheduler-Location` exists in the cache, it's value will be returned, instead
+specified `Time-To-Live`. If a `Scheduler-Location` exists in the cache, its value will be returned, instead
 of fetching the record on chain.
 
 The default size of the cache is `100`. If you'd like a smaller or larger cache, you can set the size using `connect`
 
 #### `connect`
 
 If you would like to use config other than the defaults, you can
-specify those coonfigurations by providing their values `connect`. You can currently specify
+specify those configurations by providing their values `connect`. You can currently specify
 
 - The `GRAPHQL_URL`
 - The In-Memory `cacheSize`
@@ -136,9 +136,9 @@ connect() == { validate, locate, raw }
 
 This module's APIs will reject with certain `Error`s for certain sad-paths:
 
-- `TransactionNotFoundError` - the transaction id provided can not be found on the gateway. It's `name` property will be `TransactionNotFound`
-- `SchedulerTagNotFoundError` - a `Scheduler` tag was not found on the provided process transaction id. It's `name` property will be `SchedulerTagNotFound`
-- `InvalidSchedulerLocationError` - the `Scheduler-Location` record retrieved does not adhere to the `ao` `Scheduler-Location` specification. It's `name` property will be `InvalidSchedulerLocation`:
+- `TransactionNotFoundError` - the transaction id provided can not be found on the gateway. Its `name` property will be `TransactionNotFound`
+- `SchedulerTagNotFoundError` - a `Scheduler` tag was not found on the provided process transaction id. Its `name` property will be `SchedulerTagNotFound`
+- `InvalidSchedulerLocationError` - the `Scheduler-Location` record retrieved does not adhere to the `ao` `Scheduler-Location` specification. Its `name` property will be `InvalidSchedulerLocation`:
   - It does not have a `Url` tag
   - It does not have a `Time-To-Live` tag