fix links in documentation

docs/design-patterns.mdx

@@ -391,7 +391,7 @@ transaction {
 
 ### Problem
 
-An account must be given a [capability](/cadence/language/capability-based-access-control)
+An account must be given a [capability](language/capability-based-access-control)
 to a resource or contract in another account. To create, i.e. link the capability,
 the transaction must be signed by a key which has access to the target account.
 
@@ -404,7 +404,7 @@ from one account and delivering it to the other.
 
 ### Solution
 
-The solution to the bootstrapping problem in Cadence is provided by the [Inbox API](/cadence/language/accounts#account-inbox)
+The solution to the bootstrapping problem in Cadence is provided by the [Inbox API](language/accounts#account-inbox)
 
 Account A (which we will call the provider) creates the capability they wish to send to B (which we will call the recipient),
 and stores this capability on their account in a place where the recipient can access it using the `Inbox.publish` function on their account. 

docs/language/imports.mdx

@@ -11,7 +11,7 @@ or it can be followed by the names of the declarations that should be imported,
 followed by the `from` keyword, and then followed by the location.
 
 If importing a local file, the location is a string literal, and the path to the file.
-Deployment of code with file imports requires the usage for the [Flow CLI](/flow-cli).
+Deployment of code with file imports requires the usage for the [Flow CLI](https://developers.flow.com/flow-cli).
 
 If importing an external type in a different account,
 the location is an address literal, and the address

docs/measuring-time.mdx

@@ -25,7 +25,7 @@ and further optimizations are needed to achieve that.
 As of Feb 2021, the rate of block finalization on Mainnet is more than 0.5 blocks/s; with a standard deviation of ±0.1 blocks/s.
 Hence, a new block is finalized on average every 2 seconds.
 Note that block height only has a loose correlation with time,
-as [the block rate naturally fluctuates](/faq/operators#does-the-blockheight-go-up-1-every-second).
+as [the block rate naturally fluctuates](https://developers.flow.com/flow/faq/operators#does-the-blockheight-go-up-1-every-second).
 
 In addition to the natural variation described above,
 there are several theoretical block production attacks that could skew this relationship even further.

docs/security-best-practices.mdx

@@ -4,11 +4,11 @@ title: Security Best Practices
 
 This is an opinionated list of best practices Cadence developers should follow to write more secure Cadence code.
 
-Some practices listed below might overlap with advice in the [Cadence Anti-Patterns](/cadence/design-patterns) section, which is a recommended read as well.
+Some practices listed below might overlap with advice in the [Cadence Anti-Patterns](design-patterns) section, which is a recommended read as well.
 
 ## References
 
-[References](/cadence/language/references) are ephemeral values and cannot be stored. If persistence is required, store a capability and borrow it when needed.
+[References](language/references) are ephemeral values and cannot be stored. If persistence is required, store a capability and borrow it when needed.
 
 Authorized references (references with the `auth` keyword) allow downcasting, e.g. a restricted type to its unrestricted type and should only be used in some specific cases.
 
@@ -18,9 +18,9 @@ Be aware that the subtype or unrestricted type could expose functionality that w
 
 ## Account Storage
 
-Don't trust a users’ [account storage](/cadence/language/accounts#account-storage). Users have full control over their data and may reorganize it as they see fit. Users may store values in any path, so paths may store values of “unexpected” types. These values may be instances of types in contracts that the user deployed.
+Don't trust a users’ [account storage](language/accounts#account-storage). Users have full control over their data and may reorganize it as they see fit. Users may store values in any path, so paths may store values of “unexpected” types. These values may be instances of types in contracts that the user deployed.
 
-Always [borrow](/cadence/language/capability-based-access-control) with the specific type that is expected. Or, check if the value is an instance of the expected type.
+Always [borrow](language/capability-based-access-control) with the specific type that is expected. Or, check if the value is an instance of the expected type.
 
 ## Auth Accounts
 
@@ -30,7 +30,7 @@ It is preferable to use capabilities over direct `AuthAccount` storage when expo
 
 ## Capabilities
 
-Don’t store anything under the [public capability storage](/cadence/language/capability-based-access-control) unless strictly required. Anyone can access your public capability using `AuthAccount.getCapability`. If something needs to be stored under `/public/`, make sure only read functionality is provided by restricting its type using either a resource interface or struct interface.
+Don’t store anything under the [public capability storage](language/capability-based-access-control) unless strictly required. Anyone can access your public capability using `AuthAccount.getCapability`. If something needs to be stored under `/public/`, make sure only read functionality is provided by restricting its type using either a resource interface or struct interface.
 
 When linking a capability, the link might already be present. In that case, Cadence will not panic with a runtime error but the link function will return `nil`.
 
@@ -42,21 +42,21 @@ Ensure capabilities cannot be accessed by unauthorized parties. For example, cap
 
 ## Transactions
 
-Audits of Cadence code should also include [transactions](/cadence/language/transactions), as they may contain arbitrary code, just, like in contracts. In addition, they are given full access to the accounts of the transaction’s signers, i.e. the transaction is allowed to manipulate the signers’ account storage, contracts, and keys.
+Audits of Cadence code should also include [transactions](language/transactions), as they may contain arbitrary code, just, like in contracts. In addition, they are given full access to the accounts of the transaction’s signers, i.e. the transaction is allowed to manipulate the signers’ account storage, contracts, and keys.
 
 Signing a transaction gives access to the `AuthAccount`, i.e. full access to the account’s storage, keys, and contracts.
 
 Do not blindly sign a transaction. The transaction could for example change deployed contracts by upgrading them with malicious statements, revoking or adding keys, transferring resources from storage, etc.
 
 ## Types
 
-Use [restricted types and interfaces](/cadence/language/restricted-types). Always use the most specific type possible, following the principle of least privilege. Types should always be as restrictive as possible, especially for resource types.
+Use [restricted types and interfaces](language/restricted-types). Always use the most specific type possible, following the principle of least privilege. Types should always be as restrictive as possible, especially for resource types.
 
 If given a less-specific type, cast to the more specific type that is expected. For example, when implementing the fungible token standard, a user may deposit any fungible token, so the implementation should cast to the expected concrete fungible token type.
 
 ## Access Control
 
-Declaring a field as [`pub/access(all)`](/cadence/language/access-control) only protects from replacing the field’s value, but the value itself can still be mutated if it is mutable. Remember that containers, like dictionaries, and arrays, are mutable.
+Declaring a field as [`pub/access(all)`](language/access-control) only protects from replacing the field’s value, but the value itself can still be mutated if it is mutable. Remember that containers, like dictionaries, and arrays, are mutable.
 
 Prefer non-public access to a mutable state. That state may also be nested. For example, a child may still be mutated even if its parent exposes it through a field with non-settable access.
 

docs/tutorial/01-first-steps.mdx

@@ -14,11 +14,11 @@ Cadence introduces new features to smart contract programming that help develope
 - Type safety and a strong static type system
 - Resource-oriented programming, a new paradigm that pairs linear types with object capabilities to create a secure and declarative model for digital ownership
   by ensuring that resources (and their associated assets) can only exist in one location at a time, cannot be copied, and cannot be accidentally lost or deleted
-- Built-in pre-conditions and post-conditions for functions and [transactions](/cadence/language/transactions)
+- Built-in pre-conditions and post-conditions for functions and [transactions](../language/transactions)
 - The utilization of capability-based security, which enforces access control by requiring that access to objects
   is restricted to only the owner and those who have a valid reference to the object
 
-Please see the [Cadence introduction](/cadence) for more information about the high level design of the language.
+Please see the [Cadence introduction](..) for more information about the high level design of the language.
 
 ## What is the Flow Developer Playground?
 

docs/tutorial/02-hello-world.mdx

@@ -51,7 +51,7 @@ without the need for any trusted third party anywhere in the process, because th
 Programs that run on blockchains are commonly referred to as smart contracts
 because they mediate important functionality (such as currency) without having to rely on a central authority (like a bank).
 
-[Cadence is the resource-oriented programming language](/cadence)
+[Cadence is the resource-oriented programming language](..)
 for developing smart contracts on the Flow Blockchain.
 
 This tutorial will walk you through an example of a smart contract that implements basic Cadence features,
@@ -89,11 +89,11 @@ For this tutorial, you'll be working with only the first account `0x01`
 You will start by writing a smart contract that contains a public function that returns `"Hello World!"`.
 
 Like most other blockchains, the programming model in Flow is centered around accounts and transactions.
-All state that persists permanently is stored in [accounts](/cadence/language/accounts)
+All state that persists permanently is stored in [accounts](../language/accounts)
 and all accounts have the same core functionality. (users, smart contracts, data storage)
 
 The interfaces to this state (the ways to interact with it, otherwise known as methods or functions) are also stored in accounts.
-All code execution takes place within [transactions](/cadence/language/transactions),
+All code execution takes place within [transactions](../language/transactions),
 which are blocks of code that are authorized and submitted by external users
 to interact with the persistent state, which includes directly modifying account storage.
 
@@ -156,10 +156,10 @@ You would have used `var` to declare a variable, which that the value can be cha
 
 You can use `access(all)` and the `pub` keyword interchangeably.
 They are both examples of an access control specification that means an interface can be accessed in all scopes, but not written to in all scopes.
-For more information about the different levels of access control permitted in Cadence, refer to the [Access Control section of the language reference](/cadence/language/access-control).
+For more information about the different levels of access control permitted in Cadence, refer to the [Access Control section of the language reference](../language/access-control).
 
 The `init()` section is called the initializer. It is a special function that only runs when the contract is first created.
-Objects similar to contracts, such as other [composite types like structs or resources](/cadence/language/composite-types),
+Objects similar to contracts, such as other [composite types like structs or resources](../language/composite-types),
 require that the `init()` function initialize any fields that are declared in a composite type.
 In the above example, the initializer sets the `greeting` field to `"Hello, World!"` when the contract is initialized.
 
@@ -181,7 +181,7 @@ is built into the protocol by default.
 
 An account is divided into two main areas:
 
-1. The first area is the [contract area](/cadence/language/accounts).
+1. The first area is the [contract area](../language/accounts).
    This is the area that stores smart contracts containing type definitions, fields, and functions that relate to common functionality.
    There is no limit to the number of smart contracts an account can store.
    This area cannot be directly accessed in a transaction unless the transaction is just returning (reading) a copy of the code deployed to an account.
@@ -223,7 +223,7 @@ In the Flow Playground environment there can only be one contract for each accou
 ### Creating a Transaction
 ---
 
-A [Transaction](/cadence/language/transactions) in Flow is defined as an arbitrary-sized block of Cadence code that is authorized by one or more accounts.
+A [Transaction](../language/transactions) in Flow is defined as an arbitrary-sized block of Cadence code that is authorized by one or more accounts.
 When an account authorizes a transaction, the code in that transaction has access to the authorizers' private storage.
 An account authorizes a transaction by performing a cryptographic signature on the transaction with the account's private key,
 which should only be accessible to the account owner. Therefore, authorizers are also known as signers.
@@ -305,5 +305,5 @@ Now that you have completed the tutorial, you have the basic knowledge to write
 - Sign the transaction with one or multiple signers
 
 Feel free to modify the smart contract to implement different functions,
-experiment with the available [Cadence types](/cadence/language/values-and-types),
+experiment with the available [Cadence types](../language/values-and-types),
 and write new transactions that execute multiple functions from your `HelloWorld` smart contract.