Merge pull request #97 from movementlabsxyz/l-monninger/cleanup-type-uses

chore: cleanup type uses

Author: l-monninger

README.md

@@ -240,7 +240,7 @@ Checks that both `movement` and `movement-aptos` balances for the native token a
 
 ## 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. 

migration/core/README.md

@@ -0,0 +1,6 @@
+# `core`
+`core` contains the `-core` APIs for which migration. It contains the following subdirectories. 
+
+1. [`node`](./node/): refers to the parts of the migration which run with privileged access to the node itself--including file-based state and 
+2. [`migrator`](./migrator/): refers to parts of the migration which run with all other units. Currently, `migrator` includes access to `node` via `.node()` methods on the migrators as well as access to REST clients via `.wait_for_rest_client()` methods on the migrators. Thus, `migrators` can also be where migrations are run which require transaction API usage.
+3. [`mtma`](./mtma/): refers to what is ultimately exported as the correct migration. Currently, this is basically empty. It is the end-target for `mtma` migration development.

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`.