chore: fixes from diff review (#24595)

docs/.gitignore

@@ -21,7 +21,6 @@ docs/docs/tooling/03-hubl.md
 docs/docs/core/17-autocli.md
 docs/docs/packages/01-depinject.md
 docs/docs/packages/02-collections.md
-docs/user/run-node/04-rosetta.md
 docs/build/migrations/02-upgrading.md
 docs/learn/advanced/17-autocli.md
 

docs/architecture/adr-057-app-wiring.md

@@ -306,13 +306,13 @@ change to a module should be handled as follows:
 - the semantic major version should be incremented, and
 - a new semantically versioned module config protobuf type should be created.
 
-For instance, if we have the SDK module for bank in the go module `cosmossdk.io/x/bank` with the module config type
+For instance, if we have the SDK module for bank in the go module `github.com/cosmos/cosmos-sdk/x/bank` with the module config type
 `cosmos.bank.module.v1.Module`, and we want to make a state machine breaking change to the module, we would:
-- create a new go module `cosmossdk.io/x/bank/v2`,
+- create a new go module `github.com/cosmos/cosmos-sdk/x/bank/v2`,
 - with the module config protobuf type `cosmos.bank.module.v2.Module`.
 
 This _does not_ mean that we need to increment the protobuf API version for bank. Both modules can support
-`cosmos.bank.v1`, but `cosmossdk.io/x/bank/v2` will be a separate go module with a separate module config type.
+`cosmos.bank.v1`, but `github.com/cosmos/cosmos-sdk/x/bank/v2` will be a separate go module with a separate module config type.
 
 This practice will eventually allow us to use appconfig to load new versions of a module via a configuration change.
 

docs/docs/build/building-modules/15-depinject.md

@@ -121,4 +121,4 @@ The module is now ready to be used with `depinject` by a chain developer.
 
 ## Integrate in an application
 
-The App Wiring is done in `app_config.go` / `app.yaml` and `app_v2.go` and is explained in detail in the [overview of `app_v2.go`](../building-apps/01-app-go-di.md).
+The App Wiring is done in `app_config.go` / `app.yaml` and `app_di.go` and is explained in detail in the [overview of `app_di.go`](../building-apps/01-app-go-di.md).

docs/docs/build/tooling/README.md

@@ -11,7 +11,6 @@ This includes tools for development, operating a node, and ease of use of a Cosm
 
 * [Cosmovisor](./01-cosmovisor.md)
 * [Confix](./02-confix.md)
-* [Rosetta](https://docs.cosmos.network/main/run-node/rosetta)
 
 ## Other Tools
 

docs/docs/learn/advanced/12-simulation.md

@@ -35,9 +35,7 @@ failure type:
   inconsistencies between the stores.
 * `AppSimulationAfterImport`: Queues two simulations together. The first one provides the app state (_i.e_ genesis) to the second. Useful to test software upgrades or hard-forks from a live chain.
 * `AppStateDeterminism`: Checks that all the nodes return the same values, in the same order.
-* `BenchmarkInvariants`: Analysis of the performance of running all modules' invariants (_i.e_ sequentially runs a [benchmark](https://pkg.go.dev/testing/#hdr-Benchmarks) test). An invariant checks for
-  differences between the values that are on the store and the passive tracker. Eg: total coins held by accounts vs total supply tracker.
-* `FullAppSimulation`: General simulation mode. Runs the chain and the specified operations for a given number of blocks. Tests that there're no `panics` on the simulation. It does also run invariant checks on every `Period` but they are not benchmarked.
+* `FullAppSimulation`: General simulation mode. Runs the chain and the specified operations for a given number of blocks. Tests that there're no `panics` on the simulation.
 
 Each simulation must receive a set of inputs (_i.e_ flags) such as the number of
 blocks that the simulation is run, seed, block size, etc.
@@ -80,15 +78,10 @@ Here are some suggestions when encountering a simulation failure:
   by passing the `-ExportStatePath` flag to the simulator.
 * Use `-Verbose` logs. They could give you a better hint on all the operations
   involved.
-* Reduce the simulation `-Period`. This will run the invariants checks more
-  frequently.
-* Print all the failed invariants at once with `-PrintAllInvariants`.
 * Try using another `-Seed`. If it can reproduce the same error and if it fails
   sooner, you will spend less time running the simulations.
 * Reduce the `-NumBlocks` . How's the app state at the height previous to the
   failure?
-* Run invariants on every operation with `-SimulateEveryOperation`. _Note_: this
-  will slow down your simulation **a lot**.
 * Try adding logs to operations that are not logged. You will have to define a
   [Logger](https://github.com/cosmos/cosmos-sdk/blob/v0.53.0-rc.2/x/staking/keeper/keeper.go#L77-L81) on your `Keeper`.
 

docs/post.sh

@@ -7,7 +7,6 @@ rm -rf docs/build/tooling/03-hubl.md
 rm -rf docs/build/packages/01-depinject.md
 rm -rf docs/build/packages/02-collections.md
 rm -rf docs/learn/advaced-concepts/17-autocli.md
-rm -rf docs/user/run-node/04-rosetta.md
 rm -rf docs/build/architecture
 rm -rf docs/build/spec
 rm -rf docs/build/rfc

docs/pre.sh

@@ -25,7 +25,6 @@ cat ../x/README.md | sed 's/\.\.\/docs\/build\/building-modules\/README\.md/\/bu
 ## Add tooling documentation
 cp ../tools/cosmovisor/README.md ./docs/build/tooling/01-cosmovisor.md
 cp ../tools/confix/README.md ./docs/build/tooling/02-confix.md
-wget -O docs/user/run-node/04-rosetta.md https://raw.githubusercontent.com/cosmos/rosetta/main/README.md
 
 ## Add package documentation
 cp ../client/v2/README.md ./docs/learn/advanced/17-autocli.md