LaconicNetwork/cosmos-sdk
10
0
Fork 0
Code Issues Pull Requests Packages Projects Releases 2 Wiki Activity

docs: fix misspelled issues (#25080)

Browse Source 
Co-authored-by: Alex | Interchain Labs <alex@interchainlabs.io>
This commit is contained in:
David Klank 2025-08-04 18:11:06 +03:00 committed by GitHub
parent d458d9eae5
commit 3e0433eee7
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
10 changed files with 12 additions and 12 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
docs/architecture/adr-046-module-params.md
View File

@ -162,7 +162,7 @@ module may be removed entirely in a future release.
### Negative
* Module parameters becomes slightly more burdensome for module developers:
* Module parameters become slightly more burdensome for module developers:
* Modules are now responsible for persisting and retrieving parameter state
* Modules are now required to have unique message handlers to handle parameter
changes per unique parameter data structure.

4
docs/architecture/adr-047-extend-upgrade-plan.md
View File

@ -59,7 +59,7 @@ The current upgrade process has this timeline:
We will update the `x/upgrade.Plan` message for providing upgrade instructions.
The upgrade instructions will contain a list of artifacts available for each platform.
It allows for the definition of a pre-run and post-run commands.
These commands are not consensus guaranteed; they will be executed by Cosmosvisor (or other) during its upgrade handling.
These commands are not consensus guaranteed; they will be executed by Cosmovisor (or other) during its upgrade handling.
```protobuf
message Plan {
@ -88,7 +88,7 @@ All fields in the `UpgradeInstructions` are optional.
This command MUST behave the same as the current [pre-upgrade](https://github.com/cosmos/cosmos-sdk/blob/v0.44.5/docs/migrations/pre-upgrade.md) command.
It does not take in any command-line arguments and is expected to terminate with the following exit codes:
| Exit status code | How it is handled in Cosmosvisor |
| Exit status code | How it is handled in Cosmovisor |
|------------------|---------------------------------------------------------------------------------------------------------------------|
| `0` | Assumes `pre-upgrade` command executed successfully and continues the upgrade. |
| `1` | Default exit code when `pre-upgrade` command has not been implemented. |

2
docs/architecture/adr-050-sign-mode-textual.md
View File

@ -226,7 +226,7 @@ Tipper: <string>
Transaction Body is the `Tx.TxBody.Messages` field, which is an array of `Any`s, where each `Any` packs a `sdk.Msg`. Since `sdk.Msg`s are widely used, they have a slightly different encoding than usual array of `Any`s (Protobuf: `repeated google.protobuf.Any`) described in Annex 1.
```
This transaction has <int> message: // Optional 's' for "message" if there's is >1 sdk.Msgs.
This transaction has <int> message: // Optional 's' for "message" if there's >1 sdk.Msgs.
// For each Msg, print the following 2 lines:
Msg (<int>/<int>): <string> // E.g. Msg (1/2): bank v1beta1 send coins
<value rendering of Msg struct>

2
docs/architecture/adr-054-semver-compatible-modules.md
View File

@ -471,7 +471,7 @@ to `cosmossdk.io/core/intermodule.Client`:
ServiceRevision(ctx context.Context, serviceName string) uint64
```
Modules could all this using the service name statically generated by the go grpc code generator:
Modules could call this using the service name statically generated by the go grpc code generator:
```go
intermoduleClient.ServiceRevision(ctx, bankv1beta1.Msg_ServiceDesc.ServiceName)

2
docs/architecture/adr-058-auto-generated-cli.md
View File

@ -81,7 +81,7 @@ We would like to be able to customize:
* which fields are positional parameters rather than flags
It is an [open discussion](https://github.com/cosmos/cosmos-sdk/pull/11725#issuecomment-1108676129)
as to whether these customizations options should line in:
as to whether these customizations options should lie in:
* the .proto files themselves,
* separate config files (ex. YAML), or

2
docs/architecture/adr-059-test-scopes.md
View File

@ -153,7 +153,7 @@ The SDK uses an application will only the required modules for the tests. The ap
#### Limitations
In general the limitations of end to end tests are orchestration and compute cost.
Scaffolding is required to start up and run a prod-like environment and the this
Scaffolding is required to start up and run a prod-like environment and this
process takes much longer to start and run than unit or integration tests.
Global locks present in Tendermint code cause stateful starting/stopping to sometimes hang

2
docs/architecture/adr-060-abci-1.0.md
View File

@ -84,7 +84,7 @@ type Mempool interface {
// Select returns an Iterator over the app-side mempool. If txs are specified,
// then they shall be incorporated into the Iterator. The Iterator must
// closed by the caller.
// be closed by the caller.
Select(sdk.Context, [][]byte) Iterator
// CountTx returns the number of transactions currently in the mempool.

2
docs/architecture/adr-063-core-module-api.md
View File

@ -282,7 +282,7 @@ type HasGenesis interface {
#### Pre Blockers
Modules that have functionality that runs before BeginBlock and should implement the has `HasPreBlocker` interfaces:
Modules that have functionality that runs before BeginBlock and should implement the `HasPreBlocker` interfaces:
```go
type HasPreBlocker interface {

4
docs/architecture/adr-065-store-v2.md
View File

@ -35,7 +35,7 @@ application state. This data structure is the base layer `KVStore`.
In addition, the SDK provides abstractions on top of this Merkle data structure.
Namely, a root multi-store (RMS) is a collection of each module's `KVStore`.
Through the RMS, the application can serve queries and provide proofs to clients
in addition to provide a module access to its own unique `KVStore` though the use
in addition to provide a module access to its own unique `KVStore` through the use
of `StoreKey`, which is an OCAP primitive.
There are further layers of abstraction that sit between the RMS and the underlying
@ -65,7 +65,7 @@ See the [Storage Discussion](https://github.com/cosmos/cosmos-sdk/discussions/13
## Alternatives
There was a previous attempt to refactor the storage layer described in [ADR-040](./adr-040-storage-and-smt-state-commitments.md).
However, this approach mainly stems on the short comings of IAVL and various performance
However, this approach mainly stems on the shortcomings of IAVL and various performance
issues around it. While there was a (partial) implementation of [ADR-040](./adr-040-storage-and-smt-state-commitments.md),
it was never adopted for a variety of reasons, such as the reliance on using an
SMT, which was more in a research phase, and some design choices that couldn't

2
docs/architecture/adr-076-tx-malleability.md
View File

@ -128,7 +128,7 @@ Unfortunately, the vast majority of unaddressed malleability risks affect `SIGN_
sign mode is still commonly used.
It is recommended that the following improvements be made to Amino JSON signing:
* hashes of `TxBody` and `AuthInfo` should be added to `AminoSignDoc` so that encoding-level malleablity is addressed
* hashes of `TxBody` and `AuthInfo` should be added to `AminoSignDoc` so that encoding-level malleability is addressed
* when constructing `AminoSignDoc`, [protoreflect](https://pkg.go.dev/google.golang.org/protobuf/reflect/protoreflect) API should be used to ensure that there no fields in `TxBody` or `AuthInfo` which do not have a mapping in `AminoSignDoc` have been set
* fields present in `TxBody` or `AuthInfo` that are not present in `AminoSignDoc` (such as extension options) should
be added to `AminoSignDoc` if possible