Fix typos in documentation

docs/src/advanced.md

@@ -2,7 +2,7 @@
 
 Stateful fuzzing is an incredibly powerful feature because it allows medusa to test your system **end-to-end**. Let's
 take, for example, a staking system where you have the ability to `deposit`, `stake`, `unstake`, and `withdraw`. Because
-medusa can execute an array of transactions, medusa can call [`deposit`, `stake`, `unstake`, `withdraw`] inorder and test the
+medusa can execute an array of transactions, medusa can call [`deposit`, `stake`, `unstake`, `withdraw`] in order and test the
 whole system in one fell swoop. It is very important to note that medusa was not _forced_ to call those functions in
 sequence. Medusa, over time, will identify that calling deposit allows it to stake tokens and having a staked balance
 allows it to unstake, and so on.

docs/src/api/api_overview.md

@@ -1,6 +1,6 @@
 # API Overview (WIP)
 
-`medusa` offers a lower level API to hook into various parts of the fuzzer, its workers, and underlying chains. Although assertion and property testing are two built-in testing providers, they are implementing using events and hooks offered throughout the `Fuzzer`, `FuzzerWorker`(s), and underlying `TestChain`. These same hooks can be used by external developers wishing to implement their own customing testing methodology. In the sections below, we explore some of the relevant components throughout `medusa`, their events/hooks, an example of creating custom testing methodology with it.
+`medusa` offers a lower level API to hook into various parts of the fuzzer, its workers, and underlying chains. Although assertion and property testing are two built-in testing providers, they are implemented using events and hooks offered throughout the `Fuzzer`, `FuzzerWorker`(s), and underlying `TestChain`. These same hooks can be used by external developers wishing to implement their own custom testing methodology. In the sections below, we explore some of the relevant components throughout `medusa`, their events/hooks, an example of creating custom testing methodology with it.
 
 ## Component overview
 
@@ -28,7 +28,7 @@ A rudimentary description of the objects/providers and their roles are explained
 
   - Maintaining state of the chain (blocks, transactions in them, results/receipts)
   - Providing methods to create blocks, add transactions to them, commit them to chain, revert to previous block numbers.
-  - Allowing spoofing of block number and timestamp (commiting block number 1, then 50, jumping 49 blocks ahead), while simulating the existence of intermediate blocks.
+  - Allowing spoofing of block number and timestamp (committing block number 1, then 50, jumping 49 blocks ahead), while simulating the existence of intermediate blocks.
   - Provides methods to add tracers such as `evm.Logger` (standard go-ethereum tracers) or extend them with an additional interface (`TestChainTracer`) to also store any captured traced information in the execution results. This allows you to trace EVM execution for certain conditions, store results, and query them at a later time for testing.
 
 - `Fuzzer`: This is the main provider for the fuzzing process. It takes a `ProjectConfig` and is responsible for:
@@ -104,7 +104,7 @@ After you have created a `ProjectConfig`, you can create a new `Fuzzer` with it,
 
 Now it may be the case that you wish to hook the `Fuzzer`, `FuzzerWorker`, or `TestChain` to provide your own functionality. You can add your own testing methodology, and even power it with your own low-level EVM execution tracers to store and query results about each call.
 
-There are a few events/hooks that may be useful of the bat:
+There are a few events/hooks that may be useful off the bat:
 
 The `Fuzzer` maintains event emitters for the following events under `Fuzzer.Events.*`:
 

docs/src/cli/fuzz.md

@@ -16,7 +16,7 @@ current working directory.
 
 ```shell
 # Set config file path
-medusa fuzz --out myConfig.json
+medusa fuzz --config myConfig.json
 ```
 
 ### `--compilation-target`
@@ -26,7 +26,7 @@ warning [here](../project_configuration/compilation_config.md#target) about chan
 
 ```shell
 # Set compilation target
-medusa fuzz --target TestMyContract.sol
+medusa fuzz --compilation-target TestMyContract.sol
 ```
 
 ### `--workers`

docs/src/project_configuration/chain_config.md

@@ -48,8 +48,7 @@ The chain configuration defines the parameters for setting up `medusa`'s underly
 ### `rpcBlock`
 
 - **Type**: Integer
-- **Description**: Determines the block height that fork state will be queried for. Block tags like `LATEST` are not supported
-- yet.
+- **Description**: Determines the block height that fork state will be queried for. Block tags like `LATEST` are not supported yet.
 - **Default**: `1`
 
 ### `poolSize`

docs/src/project_configuration/fuzzing_config.md

@@ -38,7 +38,6 @@ The fuzzing configuration defines the parameters for the fuzzing campaign.
 - **Type**: Integer
 - **Description**: The number of iterations that shrinking will run for before returning the shrunken call sequence.
 - **Default**: 5000 iterations
--
 
 ### `callSequenceLength`
 

docs/src/project_configuration/testing_config.md

@@ -54,7 +54,6 @@ contract MyContract {
 - **Type**: Boolean
 - **Description**: Whether `pure` / `view` functions should be called and tested.
 - **Default**: `true`
--
 
 ### `testAllContracts`