chore: clear up docs.

Author: l-monninger

README.md

@@ -32,7 +32,7 @@ The migration is organized into passes, which are categorized as follows:
 
 ## Organization
 
-There are five subdirectories which progressively build on one another for node logic.
+There are three subdirectories which progressively build on one another for node logic.
 
 1. [`util`](./util): contains utility logic mainly reused in [`migration`](./migration).
 2. [`migration`](./migration): contains the implementation of the migration.

checks/README.md

@@ -1,26 +1,20 @@
 # Checks
 
-- [`e2e`](./e2e/README.md) covers logic for end-to-end validation of the migration.
-- [`e2e`](./executor/README.md) covers logic for validating the 
+1. [`migrator`](./migration/README.md) covers logic for end-to-end validation of the migration.
+2. [`node`](./node/README.md) covers logic for validating the executor-only portions of the migration. 
 
-All tests rely on clearly stated criteria APIs which are pulled up under a `Criterion` type. Before evaluating each `Criterion` a `Scenario` is run. Hence tests are formed:
+All tests rely on clearly stated criteria APIs which are pulled up under a `Criterion` type. Before evaluating each `Criterion` a `Prelude` is run. Hence tests are formed:
 
 ```rust
-test(
-    Scenario,
-    [
-        CriterionA,
-        CriterionB,
-        CriterionC
-    ]
-)
+checked_migration(&mut movement_migrator, &prelude, &migration, vec![criterion_a, criterion_b, criterion_c])
+			.await?;
 ```
 
 The rigidity of this structure is to make it clear what the migration is accomplishing from the testing entrypoint. More standard and flexible assertions should be performed at lower levels in this repository. 
 
 ## `Criterion`
 Tests are split into separate subdirectories which use their own `Criterion` types:
 
-- `e2e` wherein a `Criterion` is evaluated against a `MovementRestClient` and a `MovementAptosRestClient` respectively. 
-- `executor` wherein a `Criterion` is evaluated against a `MovementExecutor` and a `MovementAptosExecutor` respectively. 
+- `migrator` wherein a `Criterion` is evaluated against a `MovementMigrator` and a `MovementAptosMigrator` respectively. 
+- `node` wherein a `Criterion` is evaluated against a `MovementNode` and a `MovementAptosNode` respectively. 
 

migration/README.md

@@ -0,0 +1,9 @@
+# `migration`
+Migration contains the logic for the migration itself. It is broken into three subdirectories:
+
+1. [`cli`](./cli): CLIs for running parts of the migration. These CLIs are also indexed from the projected root at [`docs/cli/README.md`](/docs/cli/README.md).
+2. [`core`](./core/): the core APIs used in migrations. CLIs are effectively the frontends, these are the underlying programmatic APIs. 
+3. [`util`](./util/): types and similar that are used across migration implementations and in [`checks`](../checks/).
+
+> [!NOTE]
+> Currently, migration CLIs containsparts of [`checks`](../checks/) because we run checked migrations. This may be refactored in forthcoming commits. 

util/README.md

@@ -0,0 +1,6 @@
+# `util`
+The `util` directory contains the following important subdirectories:
+
+1. [`movement`](./movement/): crate APIs for running and working with `movement` nodes.
+2. [`movement-aptos`](./movement-aptos/): crate APIs for running and working with `movement-aptos` nodes. 
+3. [`types`](./types/): universal types used when working throughout `movement-migration`.