feat: new docs structure

docs/.gitignore

@@ -22,7 +22,6 @@ npm-debug.log*
 yarn-debug.log*
 yarn-error.log*
 
-docs/developers/contracts/references/aztec-nr
-src/preprocess/developers
+docs/reference/reference/smart_contract_reference/aztec-nr
 
 /src/preprocess/AztecnrReferenceAutogenStructure.json

docs/docs/aztec/_category_.json

@@ -0,0 +1,6 @@
+{
+    "position": 0,
+    "collapsible": true,
+    "collapsed": true,
+    "label": "Aztec"
+}

docs/docs/aztec/aztec/_category_.json

@@ -0,0 +1,6 @@
+{
+    "label": "Aztec",
+    "position": 0,
+    "collapsible": true,
+    "collapsed": true
+}

docs/docs/aztec/aztec/concepts/_category_.json

@@ -0,0 +1,6 @@
+{
+    "position": 1,
+    "collapsible": true,
+    "collapsed": true,
+    "label": "Concepts"
+}

docs/docs/learn/concepts/accounts/authwit.md → docs/docs/aztec/aztec/concepts/accounts/authwit.md

@@ -54,9 +54,9 @@ All of these issues have been discussed in the community for a while, and there
 
 Adopting ERC20 for Aztec is not as simple as it might seem because of private state.
 
-If you recall from the [Hybrid State model](../hybrid_state/main.md), private state is generally only known by its owner and those they have shared it with. Because it relies on secrets, private state might be "owned" by a contract, but it needs someone with knowledge of these secrets to actually spend it. You might see where this is going.
+If you recall from the [Hybrid State model](/aztec/aztec/concepts/state_model/index.md), private state is generally only known by its owner and those they have shared it with. Because it relies on secrets, private state might be "owned" by a contract, but it needs someone with knowledge of these secrets to actually spend it. You might see where this is going.
 
-If we were to implement the `approve` with an allowance in private, you might know the allowance, but unless you also know about the individual notes that make up the user's balances, it would be of no use to you! It is private after all. To spend the user's funds you would need to know the decryption key, see [keys for more](../accounts/keys.md). 
+If we were to implement the `approve` with an allowance in private, you might know the allowance, but unless you also know about the individual notes that make up the user's balances, it would be of no use to you! It is private after all. To spend the user's funds you would need to know the decryption key, see [keys for more](/aztec/aztec/concepts/accounts/keys.md). 
 
 While this might sound limiting in what we can actually do, the main use of approvals have been for simplifying contract interactions that the user is doing. In the case of private transactions, this is executed on the user device, so it is not a blocker that the user need to tell the executor a secret - the user is the executor!
 ### So what can we do?
@@ -178,7 +178,7 @@ For the transfer, this could be done simply by appending a nonce to the argument
 action = H(defi, token, transfer_selector, H(alice_account, defi, 1000, nonce));
 ```
 
-Beware that the account contract will be unable to emit the nullifier since it is checked with a static call, so the calling contract must do it. This is similar to nonces in ERC20 tokens today. We provide a small library that handles this which we will see in the [developer documentation](./../../../developers/contracts/resources/common_patterns/authwit.md).
+Beware that the account contract will be unable to emit the nullifier since it is checked with a static call, so the calling contract must do it. This is similar to nonces in ERC20 tokens today. We provide a small library that handles this which we will see in the [developer documentation](guides/guides/smart_contracts/writing_contracts/common_patterns/authwit.md).
 
 ### Differences to approval
 
@@ -192,4 +192,4 @@ We don't need to limit ourselves to the `transfer` function, we can use the same
 
 ### Next Steps
 
-Check out the [developer documentation](./../../../developers/contracts/resources/common_patterns/authwit.md) to see how to implement this in your own contracts.
+Check out the [developer documentation](guides/guides/smart_contracts/writing_contracts/common_patterns/authwit.md) to see how to implement this in your own contracts.

docs/docs/learn/concepts/accounts/main.md → docs/docs/aztec/aztec/concepts/accounts/index.md

@@ -1,5 +1,6 @@
 ---
 title: Accounts
+sidebar_position: 0
 ---
 
 **Every account in Aztec is a smart contract** which defines the rules for whether a transaction is or is not valid. This allows implementing different schemes for transaction signing, nonce management, and fee payments. However, encryption and nullifying keys, which are specific to private blockchains, are still enshrined at the protocol level.
@@ -70,7 +71,7 @@ def entryPoint(payload):
         enqueueCall(to, data, value, gasLimit);
 ```
 
-Read more about how to write an account contract [here](../../../developers/contracts/writing_contracts/accounts/write_accounts_contract.md).
+Read more about how to write an account contract [here](/tutorials/tutorials/write_accounts_contract.md).
 
 ### Account contracts and wallets
 
@@ -133,7 +134,7 @@ These two patterns combined allow an account contract to answer whether an actio
 
 Aztec requires users to define [encryption and nullifying keys](./keys.md) that are needed for receiving and spending private notes. Unlike transaction signing, encryption and nullifying is enshrined at the protocol. This means that there is a single scheme used for encryption and nullifying. These keys are derived from a master public key. This master public key, in turn, is used when deterministically deriving the account's address.
 
-A side effect of committing to a master public key as part of the address is that _this key cannot be rotated_. While an account contract implementation could include methods for rotating the signing key, this is unfortunately not possible for encryption and nullifying keys (note that rotating nullifying keys also creates other challenges such as preventing double spends). We are exploring usage of [`SharedMutable`](../../../developers/contracts/references/storage/shared_state.md#sharedmutable) to enable rotating these keys.
+A side effect of committing to a master public key as part of the address is that _this key cannot be rotated_. While an account contract implementation could include methods for rotating the signing key, this is unfortunately not possible for encryption and nullifying keys (note that rotating nullifying keys also creates other challenges such as preventing double spends). We are exploring usage of [`SharedMutable`](/reference/reference/smart_contract_reference/storage/shared_state.md#sharedmutable) to enable rotating these keys.
 
 NOTE: While we entertained the idea of abstracting note encryption, where account contracts would define an `encrypt` method that would use a user-defined scheme, there are two main reasons we decided against this. First is that this entailed that, in order to receive funds, a user had to first deploy their account contract, which is a major UX issue. Second, users could define malicious `encrypt` methods that failed in certain circumstances, breaking application flows that required them to receive a private note. While this issue already exists in Ethereum when transferring ETH (see the [king of the hill](https://coinsbench.com/27-king-ethernaut-da5021cd4aa6)), its impact is made worse in Aztec since any execution failure in a private function makes the entire transaction unprovable (ie it is not possible to catch errors in calls to other private functions), and furthermore because encryption is required for any private state (not just for transferring ETH). Nevertheless, both of these problems are solvable. Initialization can be worked around by embedding a commitment to the bytecode in the address and removing the need for actually deploying contracts before interacting with them, and the king of the hill issue can be mitigated by introducing a full private VM that allows catching reverts. As such, we may be able to abstract encryption in the future as well.
 
@@ -143,4 +144,4 @@ In order to be considered valid, an account must prove that it has locked enough
 
 However, there is one major consideration around public execution reverts. In the current design, if one of the public function executions enqueued in a transaction fails, then the entire transaction is reverted. But reverting the whole transaction would also revert the fee payment, and leave the sequencer with their hands empty after running the public execution. This means we will need to enshrine an initial verification and fee payment phase that is _not_ reverted if public execution fails.
 
-You can read the latest information about fees in the [protocol specs](../../../protocol-specs/gas-and-fees/index.md).
+You can read the latest information about fees in the [protocol specs](/protocol-specs/gas-and-fees/index.md).

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

@@ -9,13 +9,13 @@ Typically, each account in Aztec is backed by two separate keys:
 
 Signing keys allow their holder to act as their corresponding account in Aztec, similarly to the keys used for an Ethereum account. If a signing key is leaked, the user can potentially lose all their funds.
 
-Since Aztec implements full [signature abstraction](./main.md), signing keys depend on the account contract implementation for each user. Usually, an account contract will validate a signature of the incoming payload against a known public key.
+Since Aztec implements full [signature abstraction](./index.md), signing keys depend on the account contract implementation for each user. Usually, an account contract will validate a signature of the incoming payload against a known public key.
 
 This is a snippet of our Schnorr Account contract implementation, which uses Schnorr signatures for authentication:
 
 #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](../../../developers/contracts/writing_contracts/accounts/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/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. Here are a few ideas on how to store them, each with their pros and cons.
 
@@ -29,7 +29,7 @@ Similar to using a private note, but using an immutable private note removes the
 
 ### Using shared state
 
-A compromise between the two solutions above is to use [shared state](../../../developers/contracts/references/storage/shared_state.md). This would not generate additional nullifiers and commitments for each transaction while allowing the user to rotate their key. However, this causes every transaction to now have a time-to-live determined by the frequency of the mutable shared state, as well as imposing restrictions on how fast keys can be rotated due to minimum delays.
+A compromise between the two solutions above is to use [shared state](/reference/reference/smart_contract_reference/storage/shared_state.md). This would not generate additional nullifiers and commitments for each transaction while allowing the user to rotate their key. However, this causes every transaction to now have a time-to-live determined by the frequency of the mutable shared state, as well as imposing restrictions on how fast keys can be rotated due to minimum delays.
 
 ### Reusing the privacy master key
 
@@ -61,7 +61,7 @@ This public key corresponds to the privacy master key of the account. In order t
 Contracts that are not meant to represent a user who handles private state, usually non-account contracts such as applications, do not need to provide a valid public key, and can instead just use zero to denote that they are not expected to receive private notes.
 
 :::info
-A side effect of enshrining and encoding privacy keys into the account address is that these keys cannot be rotated if they are leaked. Read more about this in the [account abstraction section](./main.md#encryption-and-nullifying-keys).
+A side effect of enshrining and encoding privacy keys into the account address is that these keys cannot be rotated if they are leaked. Read more about this in the [account abstraction section](./index.md#encryption-and-nullifying-keys).
 :::
 
 ### Encryption keys

docs/docs/learn/concepts/circuits/main.md → docs/docs/aztec/aztec/concepts/circuits/index.md

@@ -1,5 +1,6 @@
 ---
 title: Circuits
+sidebar_position: 7
 ---
 
 Central to Aztec's operations are 'circuits' derived both from the core protocol and the developer-written Aztec.nr contracts.
@@ -51,7 +52,7 @@ In other words, since neither the EVM nor other rollups have rules for how to pr
 
 What kind of extra rules / checks does a rollup need, to enforce notions of private states and private functions? Stuff like:
 
-- "Perform state reads and writes using new tree structures which prevent tx linkability" (see [trees](../storage/trees/main.md)).
+- "Perform state reads and writes using new tree structures which prevent tx linkability" (see [trees](/aztec/aztec/concepts/storage/trees/index.md)).
 - "Hide which function was just executed, by wrapping it in a zk-snark"
 - "Hide all functions which were executed as part of this tx's stack trace, by wrapping the whole tx in a zk-snark"
 
@@ -61,12 +62,12 @@ So what kinds of core protocol circuits does Aztec have?
 
 ### Kernel Circuits
 
-- [Private Kernel Circuit](./kernels/private_kernel)
-- [Public Kernel Circuit](./kernels/public_kernel)
+- [Private Kernel Circuit](/aztec/aztec/concepts/circuits/kernels/private_kernel)
+- [Public Kernel Circuit](/aztec/aztec/concepts/circuits/kernels/public_kernel)
 
 ### Rollup Circuits
 
-- [Rollup Circuits](./rollup_circuits/main)
+- [Rollup Circuits](/aztec/aztec/concepts/circuits/rollup_circuits)
 
 #### Squisher Circuits
 

docs/docs/learn/concepts/circuits/kernels/private_kernel.md → docs/docs/aztec/aztec/concepts/circuits/kernels/private_kernel.md

@@ -16,10 +16,10 @@ This circuit is executed by the user, on their own device. This is to ensure pri
   - public call stacks: hashes representing calls to other public functions;
   - events;
   - all data accumulated by all previous private kernel circuit recursions of this tx;
-- Hides which private function has been executed, by performing a zero-knowledge proof of membership against the [contract tree](../../storage/trees/main.md#contract-tree).
+- Hides which private function has been executed, by performing a zero-knowledge proof of membership against the [contract tree](/aztec/aztec/concepts/storage/trees/index.md#contract-tree).
 - Ensures the entire stack trace of private functions (for a particular tx) adheres to function execution rules.
 - Verifies a previous 'Private Kernel Proof', recursively, when verifying transactions which are composed of many private function calls.
-- Optionally can [deploy](../../smart_contracts/contract_creation.md) a new private contract.
+- Optionally can [deploy](/aztec/aztec/concepts/smart_contracts/contract_creation.md) a new private contract.
 
 > Note: **This is the only core protocol circuit which actually needs to be "zk" (zero-knowledge)!!!** That's because this is the only core protocol circuit which handles private data, and hence the only circuit for which proofs must not leak any information about witnesses! (The private data being handled includes: details of the Aztec.nr Contract function which has been executed; the address of the user who executed the function; the intelligible inputs and outputs of that function).
 > This is a really interesting point. Most so-called "zk-Rollups" do not make use of this "zero-knowledge" property. Their snarks are "snarks"; with no need for zero-knowledge, because they don't seek privacy; they only seek the 'succinct' computation-compression properties of snarks. Aztec's "zk-Rollup" actually makes use of "zero-knowledge" snarks. That's why we sometimes call it a "zk-zk-Rollup", or "_actual_ zk-Rollup".

docs/docs/learn/concepts/circuits/kernels/public_kernel.md → docs/docs/aztec/aztec/concepts/circuits/kernels/public_kernel.md

@@ -2,7 +2,7 @@
 title: Public Kernel Circuit
 ---
 
-This circuit is executed by a Sequencer, since only a Sequencer knows the current state of the [public data tree](../../storage/trees/main.md#public-state-tree) at any time. A Sequencer might choose to delegate proof generation to the Prover pool.
+This circuit is executed by a Sequencer, since only a Sequencer knows the current state of the [public data tree](/aztec/aztec/concepts/storage/trees/index.md#public-state-tree) at any time. A Sequencer might choose to delegate proof generation to the Prover pool.
 
 - Exposes (forwards) the following data to the next recursive circuit:
   - all data accumulated by all previous private kernel circuit recursions of this tx;

docs/docs/learn/concepts/circuits/rollup_circuits/main.md → docs/docs/aztec/aztec/concepts/circuits/rollup_circuits/index.md

@@ -23,7 +23,7 @@ For both transactions, it:
 
 - Performs public state read membership checks.
 - Updates the public data tree in line with the requested state transitions.
-- Checks that the nullifiers haven't previously been inserted into the [indexed nullifier tree](../../storage/trees/indexed_merkle_tree.md#primer-on-nullifier-trees).
+- Checks that the nullifiers haven't previously been inserted into the [indexed nullifier tree](/aztec/aztec/concepts/storage/trees/indexed_merkle_tree.mdx#primer-on-nullifier-trees).
 - Batch-inserts new nullifiers into the nullifier tree.
 - Batch-inserts new note hashes into the note hash tree
 - Batch-inserts any new contract deployments into the contract tree.