Fix doc links

docs/features/builtin-types.mdx

@@ -4,14 +4,14 @@ title: Built-in types
 
 # Built-in types
 
-Whenever [callables](../callables) are declared, Knee compiler's task is being able to serialize and deserialize,
+Whenever [callables](callables) are declared, Knee compiler's task is being able to serialize and deserialize,
 both on the backend and on the frontend:
 
 - function arguments, or the property type for setters
 - the function return type, or the property type for getters
 
 By default, Knee provides built-in support for many commonly used types, and utilities to define others
-(for example, [enums](../enums), [classes](../classes), [interfaces](../interfaces)) and even import external declarations.
+(for example, [enums](enums), [classes](classes), [interfaces](interfaces)) and even import external declarations.
 
 ## Primitives
 

docs/features/callables.mdx

@@ -10,8 +10,8 @@ either side of the JNI interface (frontend or backend), execute your code on the
 ## Functions
 
 For a function to be available on the JVM side, it must be annotated with the `@Knee` annotation.
-We support top-level functions and functions nested in `@KneeClass` declarations, as you can learn in [classes](../classes).
-Upward functions (called from K/N, implemented on the JVM) are also available through [interfaces](../interfaces).
+We support top-level functions and functions nested in `@KneeClass` declarations, as you can learn in [classes](classes).
+Upward functions (called from K/N, implemented on the JVM) are also available through [interfaces](interfaces).
 
 ```kotlin
 // Kotlin/Native
@@ -26,8 +26,8 @@ check(topLevelFunction() == 42)
 ## Properties
 
 For a property to be available on the JVM side, it must be annotated with the `@Knee` annotation.
-We support top-level properties and properties nested in `@KneeClass` declarations, as you can learn in [classes](../classes).
-Upward properties (called from K/N, implemented on the JVM) are also available through [interfaces](../interfaces).
+We support top-level properties and properties nested in `@KneeClass` declarations, as you can learn in [classes](classes).
+Upward properties (called from K/N, implemented on the JVM) are also available through [interfaces](interfaces).
 
 Both `var` and `val` properties are supported.
 

docs/features/classes.mdx

@@ -64,7 +64,7 @@ In the example above, `Post` can't be instantiated from the JVM side, while `Use
 ## Annotating members
 
 All callable members (functions, properties, constructors) of a class can be made available to the JVM side, but
-they must be explicitly marked with the `@Knee` annotation as described in the [callables](../callables) documentation.
+they must be explicitly marked with the `@Knee` annotation as described in the [callables](callables) documentation.
 
 ```kotlin
 @KneeClass class Car {

docs/features/enums.mdx

@@ -10,7 +10,7 @@ Enums can be easily serialized through their ordinal value. You can use the `@Kn
 compiler that:
 
 - this native enum is expected to be serialized, so a JVM clone must be generated
-- the compiler must serialize and deserialize these types whenever they are part of a [callable](../callables) declaration, e.g. a function argument or return type
+- the compiler must serialize and deserialize these types whenever they are part of a [callable](callables) declaration, e.g. a function argument or return type
 
 In the following example:
 

docs/features/exceptions.mdx

@@ -4,7 +4,7 @@ title: Exceptions
 
 # Exceptions
 
-Whenever a `@Knee` [callable](../callables) throws, the exception is thrown on the other side of the bridge.
+Whenever a `@Knee` [callable](callables) throws, the exception is thrown on the other side of the bridge.
 
 ```kotlin
 // Kotlin/Native
@@ -62,7 +62,7 @@ checks and can only work when such mechanism is in place.
 
 ## Custom exceptions
 
-You may also use custom exceptions, as long as they were properly annotated as [classes](../classes).
+You may also use custom exceptions, as long as they were properly annotated as [classes](classes).
 
 ```kotlin
 @KneeClass

docs/features/interfaces.mdx

@@ -6,7 +6,7 @@ title: Interfaces
 
 ## Annotating interfaces
 
-> We recommend reading the [classes](../classes) documentation first.
+> We recommend reading the [classes](classes) documentation first.
 
 Whenever you declare an interface, you can use the `@KneeInterface` annotation to tell the
 compiler that it should be processed.
@@ -27,7 +27,7 @@ will be generated for the JVM sources.
 
 ## Two-way implementation
 
-Unlike [classes](../classes), where the implementation of members is done on the Kotlin Native side and the JVM instance
+Unlike [classes](classes), where the implementation of members is done on the Kotlin Native side and the JVM instance
 is just a wrapper around it, `@KneeInterface` interface allow implementation from both sides. This makes it a much more
 powerful tool! You can do either of the following:
 

docs/features/suspend-functions.mdx

@@ -6,7 +6,7 @@ title: Suspend functions
 
 ## Declaration
 
-All [functions](../callables#functions) that support the `@Knee` annotation can also be marked as `suspend`.
+All [functions](callables#functions) that support the `@Knee` annotation can also be marked as `suspend`.
 The developer UX is exactly the same:
 
 ```kotlin
@@ -31,7 +31,7 @@ In the example above:
 
 - If the JVM `scope` is cancelled, the native coroutines are also cancelled
 - If the native coroutines are cancelled, `computeNumber` throws a `CancellationException`
-- Errors are propagated up/down and the exception type, if possible, is [preserved](../exceptions)
+- Errors are propagated up/down and the exception type, if possible, is [preserved](exceptions)
 
 In short, calling a `@Knee` suspend function is no different than calling a local suspend function
 and you can expect the same level of support. In particular Knee preserves the hierarchy of coroutines