docs: update in sync with latest atlas changes (v0.5.0)

Related to #68

src/pages/getting-started/endpoints.mdx

@@ -26,7 +26,7 @@ As noted earlier, building transaction bodies require gathering suitable informa
 Currently Atlas supports the following providers (& it would be highly appreciated if community enriches this by contributing to [Atlas](https://github.com/geniusyield/atlas/tree/main)):
 
 * [Maestro](https://www.gomaestro.org/).
-* Locally ran node along with [Kupo](https://cardanosolutions.github.io/kupo/).
+* Locally ran node along with [Kupo](https://cardanosolutions.github.io/kupo/). We have tested with version 8.1.2 of `cardano-node` and 2.7.2 of Kupo.
 * [Blockfrost](https://blockfrost.io/).
 
 <Callout type="warning">
@@ -70,7 +70,7 @@ where `coreProvider` field can have one of following possible values:
   </Tab>
   <Tab>
     ```json
-    "coreProvider": { "socketPath": "path-to-node-socket", "kupoUrl": "http://localhost:1443" },
+    "coreProvider": { "socketPath": "path-to-node-socket", "kupoUrl": "http://localhost:1442" },
     ```
   </Tab>
   <Tab>
@@ -84,7 +84,7 @@ Here is the explanation for each of the JSON keys above:
 
 * **`coreProvider`**: This field is the differentiating factor between different providers.
   * For Maestro, `maestroToken` holds the api key and `turboSubmit` field dictates whether the transactions are to be submitted via their [turbo submit](https://docs.gomaestro.org/Cardano/Transaction-Manager/tx-manager-turbo-submit) endpoint.
-  * For Local Node with Kupo provider, `socketPath` is the path towards node socket (usually named `node.socket`) file and `kupoUrl` is the url where endpoints are made available by Kupo, it is usually `http://localhost:1443`.
+  * For Local Node with Kupo provider, `socketPath` is the path towards node socket (usually named `node.socket`) file and `kupoUrl` is the url where endpoints are made available by Kupo, it is usually `http://localhost:1442`.
   * For Blockfrost, `blockfrostKey` holds the required api key.
 * **`networkId`**: Specifies your network and must be one of `mainnet`, `preprod`, `preview`, `testnet` (for legacy testnet) & `privnet` (for local private network).
 * **`logging`**: It's a list of [scribes](https://hackage.haskell.org/package/katip-0.8.7.3/docs/Katip.html#t:Scribe) to register. Its parameters (like `severity`, `verbosity`) and its general usage can be understood by going over their official haddock documentation [here](https://hackage.haskell.org/package/katip-0.8.7.2/docs/Katip.html). Katip is also explained in [this](https://link.springer.com/book/10.1007/978-1-4842-3739-7) book on web development in Haskell. Please have a look at haddock for `FromJSON` and `ToJSON` instances of [`GYLogScriptType`](https://haddock.atlas-app.io/GeniusYield-Types-Logging.html#t:GYLogScribeType) to see sample usage.

src/pages/getting-started/integration-tests.mdx

@@ -9,12 +9,16 @@ We already saw how we can conveniently write tests for our smart contract using
 |--------------------------------------------------------------------|-------------------------------------------------------------------------------|
 | Runs against mock ledger                                           | Runs against real node                                                        |
 | Each unit test gets fresh set of wallets (having original balance) | Each subsequent unit test continues upon the effects caused by previous ones |
-| Fast, purer (no `IO`) & convenient                                                     | Slow as each slot is 0.1 second                                              |
+| Fast, purer (no `IO`) & convenient                                                     | Slow as each slot is configured to be 0.1 second                                              |
 
 Thus these tests are suitable for integration testing.
 
 ## Spinning up private network
 
+<Callout>
+  To access our private network in Atlas, we'll be using "Local node with Kupo" provider and so, `cardano-node` & Kupo version is expected to be 8.1.2 & 2.7.2 respectively.
+</Callout>
+
 Our private network is adapted from WoofPool's [`cardano-private-testnet-setup`](https://github.com/woofpool/cardano-private-testnet-setup) repository.
 
 To spin up it up:
@@ -23,9 +27,21 @@ To spin up it up:
 2. Enter it & checkout `geniusyield` branch.
 3. Enter the following in terminal: `./scripts/automate.sh` (you would need to have `cardano-node` & `cardano-cli` available in your `PATH`).
 
-Once it says, "_Congrats! Your network is ready for use!_" you can attempt to run the tests (in another terminal).
+Once it says, "_Congrats! Your network is ready for use!_" we are ready to move forward and setup Kupo.
+
+Assuming `TESTNET` environment variable points to the directory of clone private testnet repository, we can start Kupo with following command:
+
+```
+kupo \
+  --node-socket $TESTNET/private-testnet/node-spo1/node.sock \
+  --node-config $TESTNET/private-testnet/configuration.yaml \
+  --since origin \
+  --match "*" \
+  --prune-utxo \
+  --in-memory
+```
 
-First, let's say the path to `private-testnet-simple` is `X`, then being inside your example project folder, you can execute the tests by running `GENIUSYIELD_PRIVNET_DIR=$X/private-testnet cabal run betref-privnet-tests -- -j1`
+We are now complete with our setup. To run tests, execute `KUPO_URL=http://localhost:1442 GENIUSYIELD_PRIVNET_DIR=$TESTNET/private-testnet cabal run betref-privnet-tests -- -j1` inside our example project folder.
 
 The `-j1` is needed so that the tests run sequentially.
 
@@ -43,7 +59,7 @@ First user is called "_funder_" as it has far more ada (couple of 100 thousands)
 We'll also see how to create a new user soon, if required.
 
 <Callout type="warning">
-  Unless you kill & restart the private network, running your privnet tests again, would have them run in the modified network state. So in general, if you wish to reexecute the command mentioned before, viz. `ATLAS_PRIVNET_DIR=$(pwd)/private-testnet-simple/private-testnet cabal run privnet-tests -- -j1`, you should first restart the privnet[^1].
+  Unless you kill & restart the private network, running your privnet tests again, would have them run in the modified network state[^1].
 </Callout>
 
 ## Understanding our first test
@@ -52,15 +68,15 @@ We'll also see how to create a new user soon, if required.
 The tests are written in [this](https://github.com/geniusyield/atlas-examples/tree/main/bet-ref/tests-privnet/BetRef/Tests/Privnet/Tests.hs) file and are being called [here](https://github.com/geniusyield/atlas-examples/tree/main/bet-ref/tests-privnet/betref-privnet-tests.hs).
 </Callout>
 
-Here is the code (& explaination follows after it):
+Here is the code (& explanation follows after it):
 
 ```haskell
   testCaseSteps "Balance checks & taking pot by closest guesser should pass" $ \info -> withSetup setup info $ \ctx -> do
 
     -- First step: Construct the parameters and obtain validator from it.
     --
     -- Let's define a new User to represent Oracle (not necessary though)
-    oracleUser <- newTempUserCtx ctx (ctxUserF ctx) (valueFromLovelace 20_000_000) False
+    oracleUser <- newTempUserCtx ctx (ctxUserF ctx) (valueFromLovelace 20_000_000) def
     (currentSlot, slotConfig) <- getSlotAndConfig ctx
     let betUntilSlotDelta = 100
         betRevealSlotDelta = 200
@@ -118,16 +134,17 @@ We next see the use of `newTempUserCtx` utility function. As mentioned before, w
 
 ```haskell
 data User = User
-    { userSKey :: !GYPaymentSigningKey
-    , userAddr :: !GYAddress
+    { userPaymentSKey :: !GYPaymentSigningKey
+    , userStakeSKey   :: !(Maybe GYStakeSigningKey)
+    , userAddr        :: !GYAddress
     }
 ```
 
 But at rare times, we might need to create a new user. Such a user would not be part of the context and thus would be local to the test creating it[^2].
 
-We can do that with the help of `newTempUserCtx` function. It accepts the context parameter, the user which will fund this new user, the value to be given to this new user and a boolean denoting whether we want to create a 5-ada-only UTxO too for this new user.
+We can do that with the help of `newTempUserCtx` function. It accepts the context parameter, the user which will fund this new user, the value to be given to this new user and a value of type [`CreateUserConfig`](https://haddock.atlas-app.io/GeniusYield-Test-Privnet-Ctx.html#t:CreateUserConfig).
 
-Next we see the use of `getSlotAndConfig` function. Earlier when we wrote for PSM tests, we could work in absolute slots as we were always running each test from the beginning of ledger but this is not the case here. Thus, we would need to work with relative slots, i.e., we find the current slot and then add offset with respect to it. Function `getSlotAndConfig` has the folowing definition:
+Next we see the use of `getSlotAndConfig` function. Earlier when we wrote for PSM tests, we could work in absolute slots as we were always running each test from the beginning of ledger but this is not the case here. Thus, we would need to work with relative slots, i.e., we find the current slot and then add offset with respect to it. Function `getSlotAndConfig` has the following definition:
 
 ```haskell
 getSlotAndConfig :: Ctx -> IO (GYSlot, GYSlotConfig)
@@ -210,7 +227,7 @@ isTxBodyErrorAutoBalance _                               = False
 Thus our `assertThrown` function checks for two things:
 
 1. Whether our action indeed raises an exception.
-2. If an exception is raised, does it saitsfy our predicate? For instance, here our predicate was `isTxBodyErrorAutoBalance`.
+2. If an exception is raised, does it satisfy our predicate? For instance, here our predicate was `isTxBodyErrorAutoBalance`.
 
 <Callout>
 You can also catch for `IO` error like:
@@ -231,4 +248,4 @@ With this we conclude upon writing integration tests.
 
 [^4]: Therefore this function is intended to be used when we create only a single output for an external address.
 
-[^5]: https://unix.stackexchange.com/q/367008
+[^5]: https://unix.stackexchange.com/q/367008.

src/pages/getting-started/operations.mdx

@@ -18,6 +18,10 @@ Thus, we only specify at high-level what we want. This would become clear as we
 
 Entire code for these operations is available [here](https://github.com/geniusyield/atlas-examples/tree/main/bet-ref/server-lib/BetRef/Api/Operations.hs).
 
+<Callout type="info">
+  When working with Atlas inside your project, since Atlas isn't on Hackage, you'll need to [specify](https://cabal.readthedocs.io/en/stable/cabal-project.html#specifying-packages-from-remote-version-control-locations) it as a remote package inside your `cabal.project`. Moreover, since Atlas itself relies on dependencies which are outside Hackage, those would need to be specified too. To streamline this, it's best to use the [`cabal.project`](https://github.com/geniusyield/atlas-examples/blob/main/cabal.project) mentioned in `atlas-examples` repository where you would just need to modify `packages:` stanza depending upon your project. 
+</Callout>
+
 ## Operation _1_: Generating address for our Smart Contract
 
 ### Generating Validator for our Smart Contract

src/pages/getting-started/unit-tests.mdx

@@ -2,7 +2,7 @@ import { Callout } from 'nextra-theme-docs'
 
 # Unit Tests
 
-Writing smart contracts & writing tests go hand in hand. Tests are also an excellent way to conveniently check working of our smart contract instead of using `cardano-cli` and local node.
+Writing smart contracts & writing tests go hand in hand. Tests are also an excellent way to conveniently check working of our smart contract instead of building transactions using `cardano-cli` and submitting them to local node.
 
 Now that we have written our smart contract and defined the required operations over it, let's see whether its working as expected.