hotfix: fix links

src/api_reference.md

@@ -4,4 +4,4 @@ The APIs documented in this section refer to Kinode runtime modules.
 Specifically, they are the patterns of Requests and Responses that an app can use to interact with these modules.
 
 **Note: App developers usually should not use these APIs directly.
-Most standard use-cases are better served by using functions in the [Process Standard Library](../process_stdlib/overview.md).**
+Most standard use-cases are better served by using functions in the [Process Standard Library](./process_stdlib/overview.md).**

src/apis/http_client.md

@@ -52,7 +52,7 @@ pub struct OutgoingHttpRequest {
 
 All requests to the HTTP client will receive a response of `Result<HttpClientResponse, HttpClientError>` serialized to JSON.
 The process can await or ignore this response, although the desired information will be in the `HttpClientResponse` if the request was successful.
-An HTTP request will have an `HttpResponse` defined in the [`http_server`](./apis/http_server.md) module.
+An HTTP request will have an `HttpResponse` defined in the [`http_server`](./http_server.md) module.
 A websocket request (open, push, close) will simply respond with a `HttpClientResponse::WebSocketAck`.
 
 ```rust

src/apis/http_server.md

@@ -2,7 +2,7 @@
 
 See also: [docs.rs for HTTP Server part of `process_lib`](https://docs.rs/kinode_process_lib/latest/kinode_process_lib/http/index.html).
 
-**Note: Most processes will not use this API directly. Instead, they will use the [`process_lib`](./process_stdlib/overview.md) library, which papers over this API and provides a set of types and functions which are much easier to natively use. This is mostly useful for re-implementing this module in a different client or performing niche actions unsupported by the library.**
+**Note: Most processes will not use this API directly. Instead, they will use the [`process_lib`](../process_stdlib/overview.md) library, which papers over this API and provides a set of types and functions which are much easier to natively use. This is mostly useful for re-implementing this module in a different client or performing niche actions unsupported by the library.**
 
 The HTTP server is used by sending and receiving requests and responses.
 From a process, you may send an `HttpServerAction` to the `http_server:distro:sys` process.

src/apis/kernel.md

@@ -74,7 +74,7 @@ Sent by the kernel, to the kernel, to indicate that all persisted processes have
 
 The first command used to start a new process.
 Generally available to apps via the `spawn()` function in the WIT interface.
-The `wasm_bytes_handle` is a pointer generated by the [filesystem](filesystem.md) API — it should be a valid `.wasm` file compiled using the [Kinode tooling](../kit/kit.md).
+The `wasm_bytes_handle` is a pointer generated by the [filesystem](../files.md) API — it should be a valid `.wasm` file compiled using the [Kinode tooling](../kit-dev-toolkit.md).
 The `on_panic` field is an enum that specifies what to do if the process panics.
 The `initial_capabilities` field is a set of capabilities that the process will have access to — note that the capabilities are signed by this kernel.
 The `public` field specifies whether the process should be visible to other processes *without* needing to grant a messaging capability.

src/apis/kinode_wit.md

@@ -15,7 +15,7 @@ To see exactly how to use WIT to write Kinode processes, see the [My First App](
 
 To see `kinode.wit` for itself, see the [file in the GitHub repo](https://github.com/kinode-dao/kinode-wit/blob/master/kinode.wit).
 Since this interface applies to all processes, it's one of the places in the OS where breaking changes are most likely to make an impact.
-To that end, the version of the WIT file that a process uses must be compatible with the version of Kinode OS on which it runs. 
+To that end, the version of the WIT file that a process uses must be compatible with the version of Kinode OS on which it runs.
 We intend to achieve perfect backwards compatibility upon first major release (1.0.0) of the OS and the WIT file.
 After that point, since processes signal the version of the WIT file they use, subsequent updates can be made without breaking existing processes or needing to change the version they use.
 
@@ -40,7 +40,7 @@ This category is also responsible for functions that give processes the ability
 
 Capabilities management functions relate to the capabilities-based security system imposed by the kernel on processes.
 Processes must acquire and manage capabilities in order to perform tasks external to themselves, such as messaging another process or writing to a file.
-See the [capabilities overview](../process/process-capabilities.md) for more details.
+See the [capabilities overview](../process/capabilities.md) for more details.
 
 Lastly, message I/O functions are used to send and receive messages between processes.
 Message-passing is the primary means by which processes communicate not only with themselves, but also with runtime modules which expose all kinds of I/O abilities.

src/apis/kv.md

@@ -1,7 +1,7 @@
 ### KV API
 
 Useful helper functions can be found in the [`kinode_process_lib`](../process_stdlib/overview.md).
-More discussion of databases in Kinode can be found [here](./databases).
+More discussion of databases in Kinode can be found [here](../databases.md).
 
 #### Creating/Opening a database
 

src/apis/sqlite.md

@@ -1,7 +1,7 @@
 ### SQLite API
 
 Useful helper functions can be found in the [`kinode_process_lib`](../process_stdlib/overview.md).
-More discussion of databases in Kinode can be found [here](./databases).
+More discussion of databases in Kinode can be found [here](../databases.md).
 
 #### Creating/Opening a database
 

src/apis/vfs.md

@@ -13,7 +13,7 @@ A drive is just a directory within your VFS, consisting of 2 parts: `package_id/
 
 For example: `your_package:publisher.os/pkg/`.
 This directory is usually filled with files put into the `pkg/` directory when installing with `app_store`.
-[Capabilities](../process/process-capabilities.md) are checked on the drive part of the path.
+[Capabilities](../process/capabilities.md) are checked on the drive part of the path.
 When calling `create_drive()` you'll be given "read" and "write" caps that you can share with other processes.
 
 Other processes within your package will have access by default.

src/chess_app/chat.md

@@ -2,7 +2,7 @@
 
 So, at this point you've got a working chess game with a frontend.
 There are a number of obvious improvements to the program to be made, as listed at the end of the [last chapter](./putting_everything_together.md).
-The best way to understand those improvements is to start exploring other areas of the docs, such as the chapters on [capabilities-based security](../process/process-capabilities.md) and the [networking protocol](../networking_protocol.md), for error handling.
+The best way to understand those improvements is to start exploring other areas of the docs, such as the chapters on [capabilities-based security](../process/capabilities.md) and the [networking protocol](../networking_protocol.md), for error handling.
 
 This chapter will instead focus on how to *extend* an existing program with new functionality.
 Chat is a basic feature for a chess program, but will touch the existing code in many places.

src/chess_app/frontend.md

@@ -14,7 +14,7 @@ When files found in the `ui/` directory, if a `package.json` file is found with
 The `build:copy` in that file builds the UI and then places the resulting files into the `pkg/ui/` directory where they will be installed by `kit start-package`.
 This allows your process to fetch them from the virtual filesystem, as all files in `pkg/` are mounted.
 See the [VFS API overview](../apis/vfs.md) to see how to use files mounted in `pkg/`.
-Additional UI dev info can be found [here](./apis/frontend_development.md).
+Additional UI dev info can be found [here](../apis/frontend_development.md).
 
 Get the chess UI files and place them in the proper place (next to `pkg/`):
 ```bash

src/cookbook/file_transfer.md

@@ -3,7 +3,7 @@
 This entry will teach you to build a simple file transfer app, allowing nodes to download files from a public directory.
 It will use the [VFS](../apis/vfs.md) to read and write files, and will spin up worker processes for the transfer.
 
-This guide assumes a basic understanding of Kinode process building, some familiarity with [`kit`](../kit/kit.md), requests and responses, and some knowledge of rust syntax.
+This guide assumes a basic understanding of Kinode process building, some familiarity with [`kit`](../kit-dev-toolkit.md), requests and responses, and some knowledge of rust syntax.
 
 ## Contents
 

src/cookbook/file_transfer_ui.md

@@ -1,8 +1,8 @@
 # Kino Files (File Transfer + UI)
 
-This entry will teach you to add a simple UI to the [file transfer app](./file_transfer.md), using [`kit`](../kit/kit.md)'s built-in UI template.
+This entry will teach you to add a simple UI to the [file transfer app](./file_transfer.md), using [`kit`](../kit-dev-toolkit.md)'s built-in UI template.
 
-This guide assumes a basic understanding of Kinode process building, some familiarity with [`kit`](../kit/kit.md), requests and responses, and some knowledge of Rust syntax.
+This guide assumes a basic understanding of Kinode process building, some familiarity with [`kit`](../kit-dev-toolkit.md), requests and responses, and some knowledge of Rust syntax.
 It's also strongly recommended that you read and understand the [file transfer app](./file_transfer.md) before continuing.
 
 ## Contents
@@ -669,7 +669,7 @@ The UI will be served from `http://localhost:8080/file_transfer:file_transfer:te
 ## Next Steps
 
 Now that you've built a simple UI, you can try building your own app!
-Check out the [APIs](../apis/overview.md) to see what's possible.
+Check out the [APIs](../api_reference.md) to see what's possible.
 
 ## Github Repo
 

src/http_server_and_client.md

@@ -7,7 +7,7 @@ The HTTP server is how most processes in the Kinode OS present their interface t
 
 The specification for the [server](./apis/http_server.md) and [client](./apis/http_client.md) APIs are available in the API reference.
 These APIs are accessible via messaging the `http_server:distro:sys` and `http_client:distro:sys` runtime extensions, respectively.
-The only [capability](./process/process-capabilities.md) required to use either process is the one to message it, granted by the kernel.
+The only [capability](./process/capabilities.md) required to use either process is the one to message it, granted by the kernel.
 
 WebSocket server/client functionality is presented alongside HTTP.
 

src/kit-dev-toolkit.md

@@ -12,4 +12,5 @@
 * [`kit remove-package`](./kit/start-package.md)
 * [`kit dev-ui`](./kit/dev-ui.md)
 * [`kit inject-message`](./kit/inject-message.md)
+* [`kit run-tests`](./kit/run-tests.md)
 * [`kit reset-cache`](./kit/reset-cache.md)

src/kit/build.md

@@ -34,7 +34,7 @@ There must exist a `ui/package.json` file with `scripts` defined like:
 "build:copy": "npm run build && npm run copy",
 ```
 
-Additional UI dev info can be found [here](./apis/frontend_development.md).
+Additional UI dev info can be found [here](../apis/frontend_development.md).
 To both `build` and `start-package` in one command, use `kit build-start-package`.
 
 ## Arguments

src/my_first_app/chapter_1.md

@@ -19,7 +19,7 @@ cargo install --git https://github.com/kinode-dao/kit
 
 ## Creating a New Kinode Package Template
 
-The `kit` toolkit has a [variety of features](../kit/kit.md).
+The `kit` toolkit has a [variety of features](../kit-dev-toolkit.md).
 One of those tools is `new`, which creates a template for a Kinode package.
 The `new` tool takes two arguments: a path to create the template directory and a name for the package:
 

src/my_first_app/chapter_4.md

@@ -346,7 +346,7 @@ Create a new file in `ui/index.html` with the following contents.
 ```
 
 This is a super barebones `index.html` that provides a form to make requests to the `/api` endpoint.
-Additional UI dev info can be found [here](./apis/frontend_development.md).
+Additional UI dev info can be found [here](../apis/frontend_development.md).
 
 Finally, add one more entry to `manifest.json`: messaging capabilities to the VFS which is required to store and access the UI `index.html`:
 ```json

src/process/processes.md

@@ -47,7 +47,8 @@ Instead, processes elect to persist data, and what data to persist, when desired
 Data might be persisted after every message ingested, after every X minutes, after a certain specific event, or never.
 When data is persisted, the kernel saves it to our abstracted filesystem, which not only persists data on disk, but also across arbitrarily many encrypted remote backups as configured at the user-system-level.
 
-This design allows for ephemeral state that lives in-memory, or truly permanent state, encrypted across many remote backups, synchronized and safe. [Read more about filesystem persistence here](./files.md).
+This design allows for ephemeral state that lives in-memory, or truly permanent state, encrypted across many remote backups, synchronized and safe.
+[Read more about filesystem persistence here](../files.md).
 
 ### Requests and Responses
 
@@ -100,7 +101,7 @@ In contrast, if a file-transfer process can transfer more than one file at a tim
 The constraint on awaiting is a primary reason why it is desirable to [spawn child processes](#spawning-child-processes).
 Continuing the file-transfer example, by spawning one child "worker" process per file to be transferred, each worker can use the await mechanic to simplify the code, while not limiting performance.
 
-There is more discussion of child processes [here](cookbook/manage_child_processes.md), and an example of them in action in the [`file_transfer` cookbook](cookbook/file_transfer.md).
+There is more discussion of child processes [here](../cookbook/manage_child_processes.md), and an example of them in action in the [`file_transfer` cookbook](../cookbook/file_transfer.md).
 
 #### Message Structure
 
@@ -155,7 +156,7 @@ The kernel gives out capabilities that allow a process to message another *local
 It also gives a capability allowing processes to send and receive messages over the network.
 A process can optionally mark itself as `public`, meaning that it can be messaged by any *local* process regardless of capabilities.
 
-[See the capabilities chapter for more details.](./process/process-capabilities.md)
+[See the capabilities chapter for more details.](./capabilities.md)
 
 ### Spawning child processes
 
@@ -168,7 +169,7 @@ Child processes can be used to:
 3. Run IO-heavy code without blocking the parent
 4. Break out code that is more easily written with awaits to avoid blocking the parent
 
-There is more discussion of child processes [here](cookbook/manage_child_processes.md), and an example of them in action in the [`file_transfer` cookbook](cookbook/file_transfer.md).
+There is more discussion of child processes [here](../cookbook/manage_child_processes.md), and an example of them in action in the [`file_transfer` cookbook](../cookbook/file_transfer.md).
 
 ### Conclusion
 

src/process/startup.md

@@ -1,7 +1,8 @@
 # Startup, Spindown, and Crashes
 
 Along with learning how processes communicate, understanding the lifecycle paradigm of Kinode processes is essential to developing useful p2p applications.
-Recall that a 'package' is a userspace construction that contains one or more processes. The Kinode kernel is only aware of processes.
+Recall that a 'package' is a userspace construction that contains one or more processes.
+The Kinode kernel is only aware of processes.
 When a process is first initialized, its compiled Wasm code is loaded into memory and, if the code is valid, the process is added to the kernel's process table.
 Then, the `init` function common to all processes is called.
 
@@ -13,7 +14,7 @@ There are two ways: either the process can use the built-in `set_state` and `get
 
 The first option is a maximally-simple way to write some bytes to disk (where they'll be backed up, if the node owner has configured that behavior).
 The second option is vastly more general, because runtime modules that have direct messaging availability from userspace offer any number of APIs.
-So far, there are three modules built into Kinode OS that are designed for persisted data: a [filesystem](./files.md), a [key-value store, and a SQLite database](./databases.md).
+So far, there are three modules built into Kinode OS that are designed for persisted data: a [filesystem](../files.md), a [key-value store, and a SQLite database](../databases.md).
 
 Each of these modules offer APIs accessed via message-passing and write data to disk.
 Between instantiations of a process, this data remains saved, even backed up.

src/quick-start.md

@@ -48,6 +48,6 @@ m our@my_chat_app:my_chat_app:template.os '{"Send": {"target": "fake.os", "messa
 ## Next steps
 
 The first chapter of the [My First Kinode Application](./my_first_app/chapter_1.md) tutorial is a more detailed version of this Quick Start.
-Alternatively, you can learn more about `kit` in the [`kit` documentation](./kit/kit.md).
+Alternatively, you can learn more about `kit` in the [`kit` documentation](./kit-dev-toolkit.md).
 
 If instead, you want to learn more about high-level concepts, start with the [Introduction](./intro.md) and work your way through the book in-order.