docs: address moar comments & re-add (modified) inspiration

docs/glossary.md

@@ -21,9 +21,9 @@ Here, encoding and decoding operations are designed to operate with interfaces
 nested any amount times (like an onion!). There is one public `TxMapper`
 in the basecoin root package, and all modules can register their own transaction
 types there. This allows us to deserialize the entire transaction in one location
-(even with types defined in other repos), to easily embed an arbitrary tx inside
-another without specifying the type, and provide an automatic json representation
-to provide to users (or apps) to inspect the chain.
+(even with types defined in other repos), to easily embed an arbitrary transaction
+inside another without specifying the type, and provide an automatic json
+representation allowing for users (or apps) to inspect the chain.
 
 Note how we can wrap any other transaction, add a fee level, and not worry
 about the encoding in our module any more?
@@ -163,7 +163,7 @@ then each transaction is handled by the appropriate module.
 ## Dispatcher
 
 We usually will want to have multiple modules working together, and need to
-make sure the correct transactions get to the correct module. So we have the
+make sure the correct transactions get to the correct module. So we have
 `coin` sending money, `roles` to create multi-sig accounts, and `ibc` for
 following other chains all working together without interference.
 

docs/guide/counter/cmd/countercli/main.go

@@ -12,6 +12,7 @@ import (
 	"github.com/cosmos/cosmos-sdk/client/commands/proxy"
 	"github.com/cosmos/cosmos-sdk/client/commands/query"
 	"github.com/cosmos/cosmos-sdk/client/commands/seeds"
+
 	txcmd "github.com/cosmos/cosmos-sdk/client/commands/txs"
 	bcount "github.com/cosmos/cosmos-sdk/docs/guide/counter/cmd/countercli/commands"
 	authcmd "github.com/cosmos/cosmos-sdk/modules/auth/commands"
@@ -21,15 +22,16 @@ import (
 	noncecmd "github.com/cosmos/cosmos-sdk/modules/nonce/commands"
 )
 
-// BaseCli represents the base command when called without any subcommands
-var BaseCli = &cobra.Command{
+// CounterCli represents the base command when called without any subcommands
+var CounterCli = &cobra.Command{
 	Use:   "countercli",
-	Short: "Light client for tendermint",
-	Long: `Basecli is an version of tmcli including custom logic to
-present a nice (not raw hex) interface to the basecoin blockchain structure.
+	Short: "Example app built using the Cosmos SDK",
+	Long: `Countercli is a demo app that includes custom logic to
+present a formatted interface to a custom blockchain structure.
+
+This is a useful tool and also serves to demonstrate how to configure
+the Cosmos SDK to work for any custom ABCI app, see:
 
-This is a useful tool, but also serves to demonstrate how one can configure
-tmcli to work for any custom abci app.
 `,
 }
 

docs/overview.md

@@ -34,7 +34,7 @@ the stack.
 
 Middleware components allow for code reusability and integrability. A standard
 set of middleware are provided and can be mix-and-matched with custom
-middleware. Some of the [standardlibrary](stdlib.md)
+middleware. Some of the [standard library](stdlib.md)
 middlewares provided in this package include:
  - Logging
  - Recovery
@@ -47,7 +47,7 @@ middlewares provided in this package include:
  
 As a part of stack execution the state space provided to each middleware is
 isolated (see [Data Store](overview.md#data-store)). When executing the stack,
-state-recovery check-points can be assigned for stack execution of `CheckTx` 
+state-recovery checkpoints can be assigned for stack execution of `CheckTx` 
 or `DeliverTx`. This means, that all state changes will be reverted to the 
 checkpoint state on failure when either being run as a part of `CheckTx`
 or `DeliverTx`. Example usage of the checkpoints is when we may want to deduct
@@ -75,7 +75,7 @@ Store](overview.md#data-store)).
 ### Permission
 
 Each application is run in a sandbox to isolate security risks. When
-interfacing between applications, if a one of those applications is compromised
+interfacing between applications, if one of those applications is compromised
 the entire network should still be secure. This is achieved through actor
 permissioning whereby each chain, account, or application can provided a
 designated permission for the transaction context to perform a specific action.