Clarity, headings, tagged links, etc.

Author: Shaptic

.husky/pre-commit

@@ -1,5 +1,5 @@
-G='\033[0;32m'
-P='\033[0;35m'
-CLEAN='\033[0;0m'
-
-yarn run check:mdx || (echo -e "${G}Hint:${CLEAN} execute ${P}yarn run format:mdx${CLEAN} to format files" && exit 1)
+G='\033[0;32m'
+P='\033[0;35m'
+CLEAN='\033[0;0m'
+
+yarn run check:mdx || (echo -e "${G}Hint:${CLEAN} execute ${P}yarn run format:mdx${CLEAN} to format files" && exit 1)

docs/build/guides/testing/unit-tests.mdx

@@ -71,13 +71,4 @@ The `Env` created at the beginning of the test is not a simulation of the Soroba
 
 :::
 
-It's a simple test, but it's a complete test. There's a full environment setup, used, and torn down in the test, and it happens fast. The Rust test harness runs all the tests for a contract in parallel and each will have its own isolated contract environment.
-
-Most tests, even integration tests and fuzz tests, will look very similar to this unit test. They'll do four things:
-
-1. Create an environment, the `Env`.
-2. Register the contract(s) to be tested.
-3. Invoke functions using a client.
-4. Assert the outcome.
-
 [increment contract]: https://github.com/stellar/soroban-examples/blob/main/increment/src/lib.rs

docs/data/rpc/api-reference/methods/getLedgerEntries.mdx

@@ -11,13 +11,15 @@ import rpcSpec from "@site/static/stellar-rpc.openrpc.json";
   method={rpcSpec.methods.filter((meth) => meth.name === "getLedgerEntries")[0]}
 />
 
-The Stellar ledger is, on some level, essentially a key-value store. The keys are `LedgerKey`s and the values are `LedgerEntryData`s in the XDR. An interesting product of the store's internal design is that the key is a _subset_ of the entry: we'll see more of this later.
+# Building ledger keys
 
-The `getLedgerEntries` method returns the "values" (or "entries") for a given set of "keys". `LedgerKey`s come in a lot of forms, and we'll go over the valuable ones on this page alongside tutorials on how to build and use them.
+The Stellar ledger is, on some level, essentially a key-value store. The keys are `LedgerKey`s and the values are `LedgerEntry`s in the XDR. An interesting product of the store's internal design is that the key is a _subset_ of the entry: we'll see more of this later.
+
+The `getLedgerEntries` method returns the "values" (or "entries") for a given set of "keys". `LedgerKey`s come in a lot of forms, and we'll go over the commonly used ones on this page alongside tutorials on how to build and use them.
 
 ## Types of `LedgerKey`s
 
-The source of truth should always be the XDR defined in the protocol. `LedgerKey`s are a union type defined in [Stellar-ledger-entries.x](https://github.com/stellar/stellar-xdr/blob/529d5176f24c73eeccfa5eba481d4e89c19b1181/Stellar-ledger-entries.x#L600). There are 10 different forms a ledger key can take:
+The source of truth should always be the XDR defined in the protocol. `LedgerKey`s are a union type defined in [Stellar-ledger-entries.x](https://github.com/stellar/stellar-xdr/blob/v22.0/Stellar-ledger-entries.x#L600). There are 10 different forms a ledger key can take:
 
 1. **Account:** holistically defines a Stellar account, including its balance, signers, etc. (see [Accounts](https://developers.stellar.org/docs/learn/fundamentals/stellar-data-structures/accounts))
 2. **Trustline:** defines a balance line to a non-native asset issued on the network (see [`changeTrustOp`](https://developers.stellar.org/docs/learn/fundamentals/transactions/list-of-operations#change-trust))
@@ -119,7 +121,7 @@ console.log(
 
 ### Contract Data
 
-Suppose we've deployed the [`increment` example contract] and want to find out what value is stored in the `COUNTER` ledger key. To build the key,
+Suppose we've deployed the [`increment` example contract] and want to find out what value is stored in the `COUNTER` ledger key. To build the key:
 
 <CodeExample>
 
@@ -307,14 +309,14 @@ Now, finally we have a `LedgerKey` that correspond to the Wasm byte-code that ha
 }
 ```
 
-Then you can inspect them accordingly. Each of the above entries follows the XDR for that `LedgerEntryData` structure precisely. For example, the `AccountEntry` is in [`Stellar-ledger-entries.x#L191`](https://github.com/stellar/stellar-xdr/blob/529d5176f24c73eeccfa5eba481d4e89c19b1181/Stellar-ledger-entries.x#L191) and you can use `.seqNum()` to access its current sequence number, as we've shown. In JavaScript, you can see the appropriate methods in the [type definition](https://github.com/stellar/js-stellar-base/blob/6930a70d7fbde675514b5933baff605d97453ba7/types/curr.d.ts#L3034).
+Then you can inspect them accordingly. Each of the above entries follows the XDR for that `LedgerEntryData` structure precisely. For example, the `AccountEntry` is in [`Stellar-ledger-entries.x#L191`](https://github.com/stellar/stellar-xdr/blob/v22.0/Stellar-ledger-entries.x#L191) and you can use `.seqNum()` to access its current sequence number, as we've shown. In JavaScript, you can see the appropriate methods in the [type definition](https://github.com/stellar/js-stellar-base/blob/6930a70d7fbde675514b5933baff605d97453ba7/types/curr.d.ts#L3034).
 
 ## Viewing and understanding XDR
 
 If you don't want to parse the XDR out programmatically, you can also leverage both the [Stellar CLI](https://developers.stellar.org/docs/tools/developer-tools/cli/stellar-cli) and the [Stellar Lab](https://lab.stellar.org/xdr/view) to get a human-readable view of ledger keys and entries. For example,
 
 ```bash
-echo 'AAAAAAAAAAAL76GC5jcgEGfLG9+nptaB9m+R44oweeN3EcqhstdzhQ==' | stellar xdr decode --type LedgerKey | jq
+echo 'AAAAAAAAAAAL76GC5jcgEGfLG9+nptaB9m+R44oweeN3EcqhstdzhQ==' | stellar xdr decode --type LedgerKey --output json-formatted
 {
   "account": {
     "account_id": "GAF67IMC4Y3SAEDHZMN57J5G22A7M34R4OFDA6PDO4I4VINS25ZYLBZZ"