feat(docs): Fixes from audit

docs/docs/aztec/concepts/accounts/index.md

@@ -72,7 +72,7 @@ def entryPoint(payload):
         enqueueCall(to, data, value, gasLimit);
 ```
 
-Read more about how to write an account contract [here](../../../tutorials/write_accounts_contract.md).
+Read more about how to write an account contract [here](../../../tutorials/contract_tutorials/write_accounts_contract.md).
 
 ### Account contracts and wallets
 

docs/docs/aztec/concepts/accounts/keys.md

@@ -116,7 +116,7 @@ This is a snippet of our Schnorr Account contract implementation, which uses Sch
 
 #include_code entrypoint /noir-projects/noir-contracts/contracts/schnorr_account_contract/src/main.nr rust
 
-Still, different accounts may use different signing schemes, may require multi-factor authentication, or _may not even use signing keys_ and instead rely on other authentication mechanisms. Read [how to write an account contract](../../../tutorials/write_accounts_contract.md) for a full example of how to manage authentication.
+Still, different accounts may use different signing schemes, may require multi-factor authentication, or _may not even use signing keys_ and instead rely on other authentication mechanisms. Read [how to write an account contract](../../../tutorials/contract_tutorials/write_accounts_contract.md) for a full example of how to manage authentication.
 
 Furthermore, and since signatures are fully abstracted, how the key is stored in the contract is abstracted as well and left to the developer of the account contract.
 In the following section we describe a few ways how an account contract could be architected to store signing keys.

docs/docs/aztec/concepts/wallets/index.md

@@ -6,7 +6,7 @@ tags: [accounts]
 
 In this page we will cover the main responsibilities of a wallet in the Aztec network.
 
-Refer to [writing an account contract](../../../tutorials/write_accounts_contract.md) for a tutorial on how to write a contract to back a user's account.
+Refer to [writing an account contract](../../../tutorials/contract_tutorials/write_accounts_contract.md) for a tutorial on how to write a contract to back a user's account.
 
 Go to [wallet architecture](./architecture.md) for an overview of its architecture and a reference on the interface a wallet must implement.
 
@@ -20,7 +20,7 @@ In addition to these usual responsibilities, wallets in Aztec also need to track
 
 The first step for any wallet is to let the user set up their [accounts](../accounts/index.md). An account in Aztec is represented on-chain by its corresponding account contract that the user must deploy to begin interacting with the network. This account contract dictates how transactions are authenticated and executed.
 
-A wallet must support at least one specific [account contract implementation](../../../tutorials/write_accounts_contract.md), which means being able to deploy such a contract, as well as interacting with it when sending transactions. Code-wise, this requires [implementing the `AccountContract` interface](https://github.com/AztecProtocol/aztec-packages/blob/master/yarn-project/aztec.js/src/account_contract/index.ts).
+A wallet must support at least one specific [account contract implementation](../../../tutorials/contract_tutorials/write_accounts_contract.md), which means being able to deploy such a contract, as well as interacting with it when sending transactions. Code-wise, this requires [implementing the `AccountContract` interface](https://github.com/AztecProtocol/aztec-packages/blob/master/yarn-project/aztec.js/src/account_contract/index.ts).
 
 Note that users must be able to receive funds in Aztec before deploying their account. A wallet should let a user generate a [deterministic complete address](../accounts/keys.md#complete-address) without having to interact with the network, so they can share it with others to receive funds. This requires that the wallet pins a specific contract implementation, its initialization arguments, a deployment salt, and a privacy key. These values yield a deterministic address, so when the account contract is actually deployed, it is available at the precalculated address. Once the account contract is deployed, the user can start sending transactions using it as the transaction origin.
 

docs/docs/getting_started/codespaces.md

@@ -4,11 +4,11 @@ sidebar_position: 0
 draft: true
 ---
 
-All machines are different, and you may not want to run the sandbox locally (for example when using Windows). We thought about you exactly ❤️ 
+If you do not want to run the sandbox locally, or if your machine is unsupported (eg Windows), it is possible to run it within a GitHub Codespace.
 
-[Codespaces](https://github.com/features/codespaces) are a quick way to develop: they provision a remote machine with all tooling you need for Aztec in just a few minutes. We're big fans, so we prepared some prebuilt images to make it easier and faster.
+[GitHub Codespaces](https://github.com/features/codespaces) are a quick way to develop: they provision a remote machine with all tooling you need for Aztec in just a few minutes. You can use some prebuilt images to make it easier and faster.
 
-Just choose a boilerplate and click "create new codespace":
+Choose a boilerplate and click "create new codespace":
 
 [![One-Click React Starter](/img/codespaces_badges/react_cta_badge.svg)](https://codespaces.new/AztecProtocol/aztec-packages?devcontainer_path=.devcontainer%2Freact%2Fdevcontainer.json) [![One-Click HTML/TS Starter](/img/codespaces_badges/vanilla_cta_badge.svg)](https://codespaces.new/AztecProtocol/aztec-packages?devcontainer_path=.devcontainer%2Fvanilla%2Fdevcontainer.json) [![One-Click Token Starter](/img/codespaces_badges/token_cta_badge.svg)](https://codespaces.new/AztecProtocol/aztec-packages?devcontainer_path=.devcontainer%2Ftoken%2Fdevcontainer.json)
 

docs/docs/guides/local_env/creating_schnorr_accounts.md

@@ -1,8 +1,11 @@
 ---
 title: Creating Schnorr Accounts
 sidebar_position: 1
+draft: true
 ---
 
+<!-- Taking this out of the docs for now because "Create account" guide is more concise -->
+
 ## Introduction
 
 This section shows how to create schnorr account wallets on the Aztec Sandbox.

docs/docs/guides/local_env/run_more_than_one_pxe_sandbox.md

@@ -3,6 +3,14 @@ title: Running Multiple PXEs in the Sandbox
 sidebar_position: 2
 ---
 
+:::warning
+
+Unfortunately, this is currently not working due to a bug when attempting to run an `aztec` command with the sandbox running. This will be fixed in a future version.
+
+:::
+
+--
+
 When you run the sandbox, the Aztec node and PXE have their own http server. This makes it possible to run two PXEs on your local machine, which can be useful for testing that notes are accurately stored and remaining private in their respective PXEs.
 
 We are working on a better solution for this so expect an update soon, but currently you can follow this guide.
@@ -12,20 +20,20 @@ We are working on a better solution for this so expect an update soon, but curre
 Rather than use the usual command, run:
 
 ```bash
-cd ~/.aztec && docker-compose up
+cd ~/.aztec && docker-compose -f ./docker-compose.sandbox.yml up
 ```
 
-This removes any other arguments, allowing you to ensure an isolated environment for the sandbox so it doesn't interfere with another PXE.
+This removes any other arguments, allowing you to ensure an isolated environment for the sandbox so it doesn't interfere with another PXE. By default, the sandbox will run on port `8080`.
 
 ## Run PXE mode in another terminal
 
 In another terminal, run:
 
 ```bash
-aztec start --pxe nodeUrl=http://localhost:8080/
+aztec start --port 8081 --pxe nodeUrl=http://host.docker.internal:8080/
 ```
 
-This command uses the default ports, so they might need to be changed depending on yuor configuration.
+This command uses the default ports, so they might need to be changed depending on yuor configuration. It will run the PXE on port `8081`.
 
 You should see something like this:
 

docs/docs/guides/local_env/versions-updating.md

@@ -3,9 +3,19 @@ title: Updating the Sandbox
 sidebar_position: 0
 ---
 
+- Current version: `#include_aztec_version`
+- Update with `aztec-up`
+
+On this page you will find
+
+- [Understanding versions](#versions)
+- [How to automatically update Aztec sandbox and aztec-nargo](#updating)
+- [How to update Aztec.nr packages](#updating-aztecnr-packages)
+- [How to update Aztec.js packages](#updating-aztecjs-packages)
+
 ## Versions
 
-Aztec tools (sandbox, nargo), dependencies (aztec-nr), and sample contracts are constantly being improved.
+Aztec tools (sandbox, nargo), dependencies (Aztec.nr), and sample contracts are constantly being improved.
 When developing and referring to example .nr files/snippets, it is helpful to verify the versions of different components (below), and if required keep them in lock-step by [updating](#updating).
 
 ### Checking tool versions
@@ -14,24 +24,18 @@ When developing and referring to example .nr files/snippets, it is helpful to ve
 The `aztec-nargo` versions follow `nargo` versions, which is different to the Aztec tool versions.
 :::
 
-The latest version of the Aztec tooling is currently `#include_aztec_version` , updating roughly every week.
-
 ### Dependency versions
 
 Dependency versions in a contract's `Nargo.toml` file correspond to the `aztec-packages` repository tag `aztec-packages` (filter tags by `aztec`...)
 
 If you get an error like: `Cannot read file ~/nargo/github.com/AztecProtocol/aztec-packages/...`
 Check the `git=` github url, tag, and directory.
 
-:::note
-The folder structure changed at **0.24.0** from `yarn-project/aztec-nr` to `noir-projects/aztec-nr`. More details [here](../../migration_notes.md#aztecnr-aztec-nr-contracts-location-change-in-nargotoml)
-:::
-
 ### Example contract versions
 
-Example contracts serve as a helpful reference between versions of the aztec-nr framework since they are strictly maintained with each release.
+Example contracts serve as a helpful reference between versions of the Aztec.nr framework since they are strictly maintained with each release.
 
-Code referenced in the documentation is sourced from contracts within [this directory](https://github.com/AztecProtocol/aztec-packages/tree/#include_aztec_version/noir-projects/noir-contracts/contracts).
+Code referenced in the documentation is sourced from contracts within [this directory (GitHub link)](https://github.com/AztecProtocol/aztec-packages/tree/#include_aztec_version/noir-projects/noir-contracts/contracts).
 
 As in the previous section, the location of the noir contracts moved at version `0.24.0`, from `yarn-project/noir-contracts` before, to `noir-projects/noir-contracts`.
 
@@ -80,7 +84,7 @@ To set `VERSION` for a particular git tag, eg for [aztec-package-v**0.35.0**](ht
 VERSION=0.35.0 aztec-up
 ```
 
-2. Update aztec-nr and individual @aztec dependencies:
+2. Update Aztec.nr and individual @aztec dependencies:
 
 Inside your project run:
 

docs/docs/guides/smart_contracts/writing_contracts/authwit.md

@@ -85,7 +85,7 @@ Both return the value `0xabf64ad4` (`IS_VALID` selector) for a successful authen
 
 As part of [Aztec.nr](https://aztec.nr), we are providing a library that can be used to implement authentication witness for your contracts.
 
-This library also provides a basis for account implementations such that these can more easily implement authentication witness. For more on the wallets, see [writing an account contract](../../../tutorials/write_accounts_contract.md).
+This library also provides a basis for account implementations such that these can more easily implement authentication witness. For more on the wallets, see [writing an account contract](../../../tutorials/contract_tutorials/write_accounts_contract.md).
 
 For our purposes here (not building a wallet), the most important part of the library is the `auth` utility which exposes a couple of helper methods for computing the action hash, retrieving witnesses, validating them and emitting the nullifier.
 
@@ -140,7 +140,7 @@ Then you will be able to import it into your contracts as follows.
 
 Based on the diagram earlier on this page let's take a look at how we can implement the `transfer` function such that it checks if the tokens are to be transferred `from` the caller or needs to be authenticated with an authentication witness.
 
-#include_code transfer /noir-projects/noir-contracts/contracts/token_contract/src/main.nr rust
+#include_code transfer_from /noir-projects/noir-contracts/contracts/token_contract/src/main.nr rust
 
 The first thing we see in the snippet above, is that if `from` is not the call we are calling the `assert_current_call_valid_authwit` function from [earlier](#private-functions). If the call is not throwing, we are all good and can continue with the transfer.
 

docs/docs/guides/smart_contracts/writing_contracts/call_functions.md

@@ -4,7 +4,13 @@ sidebar_position: 2
 ---
 
 
-A contract is a collection of persistent [state variables](../../../aztec/concepts/storage/index.md), and [functions](../../../aztec/concepts/smart_contracts/functions/index.md) which may manipulate these variables. Functions and state variables within a contract's scope are said to belong to that contract. A contract can only access and modify its own state. If a contract wishes to access or modify another contract's state, it must make a call to an external function of the other contract. For anything to happen on the Aztec network, an external function of a contract needs to be called.
+<!-- TODO finish this guide. i think we accidentally deleted it because this page makes no sense -->
+
+A contract is a collection of persistent [state variables](../../../aztec/concepts/storage/index.md), and [functions](../../../aztec/concepts/smart_contracts/functions/index.md) which may manipulate these variables. 
+
+Functions and state variables within a contract's scope are said to belong to that contract. A contract can only access and modify its own state.
+
+If a contract wishes to access or modify another contract's state, it must make a call to an external function of the other contract. For anything to happen on the Aztec network, an external function of a contract needs to be called.
 
 ### Contract
 
@@ -25,16 +31,4 @@ contract MyContract {
 There is no [`main()`](https://noir-lang.org/docs/getting_started/project_breakdown/#mainnr) function within a Noir `contract` scope. More than one function can be an entrypoint.
 :::
 
-### Directory structure
-
-Here's a common layout for a basic Aztec.nr Contract project:
-
-```title="layout of an aztec contract project"
-─── my_aztec_contract_project
-       ├── src
-       │     ├── main.nr       <-- your contract
-       └── Nargo.toml          <-- package and dependency management
-```
-
-- See the vanilla Noir docs for [more info on packages](https://noir-lang.org/docs/noir/modules_packages_crates/crates_and_packages).
-- You can review the structure of a complete contract in the token contract tutorial [here](../../../tutorials/contract_tutorials/token_contract.md).
+To understand how to call a function from another contract, follow the  [crowdfunding tutorial](../../../tutorials/contract_tutorials/crowdfunding_contract.md).

docs/docs/guides/smart_contracts/writing_contracts/how_to_emit_event.md

@@ -51,11 +51,6 @@ If the decryption fails, the specific log will be discarded.
 For the PXE to successfully process the decrypted note we need to compute the note's 'note hash' and 'nullifier'.
 Aztec.nr enables smart contract developers to design custom notes, meaning developers can also customize how a note's note hash and nullifier should be computed. Because of this customizability, and because there will be a potentially-unlimited number of smart contracts deployed to Aztec, an PXE needs to be 'taught' how to compute the custom note hashes and nullifiers for a particular contract. This is done by a function called `compute_note_hash_and_optionally_a_nullifier`, which is automatically injected into every contract when compiled.
 
-## Encrypted Events
-
-To emit generic event information as an encrypted log, call the context method `encrypt_and_emit_note`. Currently, only arrays of
-fields are supported, and the PXE will fail to decrypt, process and store this data, so it will not be queryable automatically.
-
 ## Unencrypted Events
 
 Unencrypted events are events which can be read by anyone.