chore: Add uv/mdformat tooling and format all documentation

- Add pyproject.toml with docs and dev dependency groups
- Add uv.lock for reproducible environments
- Configure mdformat with mkdocs, tables, frontmatter, and config plugins
- Format all 73 markdown files with mdformat
- Update .gitignore for .venv/ and site/
- Update contributing docs to reference uv workflow

Author: TrentHouliston

.gitignore

@@ -29,3 +29,6 @@ docs/doxygen_sqlite3.db
 *.sublime-workspace
 .DS_Store
 site/
+.venv/
+
+site/

docs/contributing/code-style.md

@@ -9,13 +9,13 @@ Coding conventions for the NUClear codebase.
 
 ## Naming
 
-| Element | Convention | Example |
-|---------|-----------|---------|
-| Variables, functions | `snake_case` | `log_level`, `emit_data()` |
-| Types, classes, structs | `PascalCase` | `PowerPlant`, `ReactionTask` |
-| Template parameters | `PascalCase` | `typename T`, `typename DSLWords` |
-| Constants | `UPPER_SNAKE_CASE` or `constexpr` variable | `LogLevel::INFO` |
-| Namespaces | `snake_case` | `NUClear::dsl::word` |
+| Element                 | Convention                                 | Example                           |
+| ----------------------- | ------------------------------------------ | --------------------------------- |
+| Variables, functions    | `snake_case`                               | `log_level`, `emit_data()`        |
+| Types, classes, structs | `PascalCase`                               | `PowerPlant`, `ReactionTask`      |
+| Template parameters     | `PascalCase`                               | `typename T`, `typename DSLWords` |
+| Constants               | `UPPER_SNAKE_CASE` or `constexpr` variable | `LogLevel::INFO`                  |
+| Namespaces              | `snake_case`                               | `NUClear::dsl::word`              |
 
 ## Formatting
 

docs/contributing/development.md

@@ -23,40 +23,49 @@ Tests use [Catch2](https://github.com/catchorg/Catch2) and are automatically dow
 ## Build Documentation
 
 ```bash
-pip install -r docs/requirements.txt
-mkdocs serve
+uv sync --group docs
+uv run mkdocs serve
 ```
 
 The docs will be available at `http://127.0.0.1:8000`.
 
+## Format Documentation
+
+Markdown files are formatted with [mdformat](https://github.com/hukkin/mdformat):
+
+```bash
+uv sync --group dev
+uv run mdformat docs/
+```
+
 ## Project Structure
 
-| Directory | Contents |
-|-----------|----------|
-| `src/` | Core library — PowerPlant, Reactor, DSL words, threading, utilities |
-| `src/dsl/word/` | Individual DSL word implementations (one header per word) |
-| `src/extension/` | Built-in extensions (network, IO, etc.) |
-| `src/threading/` | Scheduler, reactions, and thread pool management |
-| `tests/` | Test suite organized by feature area |
-| `tests/test_util/` | Shared test utilities (TestBase, TimeUnit, etc.) |
-| `docs/` | MkDocs documentation source |
-| `cmake/` | CMake modules and configuration templates |
+| Directory          | Contents                                                            |
+| ------------------ | ------------------------------------------------------------------- |
+| `src/`             | Core library — PowerPlant, Reactor, DSL words, threading, utilities |
+| `src/dsl/word/`    | Individual DSL word implementations (one header per word)           |
+| `src/extension/`   | Built-in extensions (network, IO, etc.)                             |
+| `src/threading/`   | Scheduler, reactions, and thread pool management                    |
+| `tests/`           | Test suite organized by feature area                                |
+| `tests/test_util/` | Shared test utilities (TestBase, TimeUnit, etc.)                    |
+| `docs/`            | MkDocs documentation source                                         |
+| `cmake/`           | CMake modules and configuration templates                           |
 
 ## Adding a New DSL Word
 
 1. Create a header in `src/dsl/word/YourWord.hpp`
-2. Implement the required static methods (`bind`, `get`, `precondition`, etc.)
-3. Add it to the forward declarations in `src/Reactor.hpp`
-4. Add a `using` alias in the Reactor class
+1. Implement the required static methods (`bind`, `get`, `precondition`, etc.)
+1. Add it to the forward declarations in `src/Reactor.hpp`
+1. Add a `using` alias in the Reactor class
 
 See [Extending the DSL](../how-to/extending-dsl.md) for the full guide on DSL word interfaces.
 
 ## Adding a Test
 
 1. Create a `.cpp` file in the appropriate `tests/tests/` subdirectory
-2. Include `<catch2/catch_test_macros.hpp>` and `"nuclear"`
-3. Use `test_util::TestBase` as a base class for reactor-based tests
-4. Register the test in the corresponding `CMakeLists.txt`
+1. Include `<catch2/catch_test_macros.hpp>` and `"nuclear"`
+1. Use `test_util::TestBase` as a base class for reactor-based tests
+1. Register the test in the corresponding `CMakeLists.txt`
 
 Example structure:
 

docs/contributing/index.md

@@ -12,9 +12,9 @@ Welcome! We're glad you're interested in contributing to NUClear.
 ## Getting Started
 
 1. Read the [Development Setup](development.md) guide to build and test locally
-2. Review the [Code Style](code-style.md) conventions
-3. Pick an issue labeled `good first issue` or open a new one to discuss your idea
-4. Fork the repo, create a branch, and submit a PR
+1. Review the [Code Style](code-style.md) conventions
+1. Pick an issue labeled `good first issue` or open a new one to discuss your idea
+1. Fork the repo, create a branch, and submit a PR
 
 ## Pull Request Guidelines
 

docs/explanation/architecture.md

@@ -69,8 +69,8 @@ This means:
 A **Reactor** is a self-contained component that:
 
 1. **Declares its interests** — "When X happens, run this function"
-2. **Processes events** — the function runs with the relevant data
-3. **Produces outputs** — emits new messages for others to react to
+1. **Processes events** — the function runs with the relevant data
+1. **Produces outputs** — emits new messages for others to react to
 
 ```cpp
 class Vision : public NUClear::Reactor {
@@ -139,14 +139,14 @@ NUClear is built on the principle of **zero-cost abstractions**:
 
 ## How NUClear Compares
 
-| Aspect | NUClear | ROS 2 |
-|--------|---------|-------|
-| Language | C++14+ | C++/Python |
-| Message routing | Compile-time types | Runtime topic strings |
-| Threading | Built-in scheduler with pools | Executor model |
-| Overhead | Near-zero (templates) | Serialization + IPC |
-| Scope | In-process (+ network) | Distributed by default |
-| Real-time | Designed for it | Possible (DDS) |
+| Aspect          | NUClear                       | ROS 2                  |
+| --------------- | ----------------------------- | ---------------------- |
+| Language        | C++14+                        | C++/Python             |
+| Message routing | Compile-time types            | Runtime topic strings  |
+| Threading       | Built-in scheduler with pools | Executor model         |
+| Overhead        | Near-zero (templates)         | Serialization + IPC    |
+| Scope           | In-process (+ network)        | Distributed by default |
+| Real-time       | Designed for it               | Possible (DDS)         |
 
 NUClear is intentionally focused on **in-process concurrency** with optional networking, rather than being a distributed middleware. This keeps it lightweight and predictable — exactly what you want when reactions need to complete in microseconds.
 

docs/explanation/dsl-system.md

@@ -38,7 +38,7 @@ This single statement does a lot. Let's break it apart.
 
 ## Phase 2: Template Instantiation — `on<>()`
 
-When you call `on<`[`Trigger`](../reference/dsl/trigger.md)`<T>, `[`Sync`](../reference/dsl/sync.md)`<G>>()`, the Reactor base class constructs a `Binder`:
+When you call `on<Trigger<T>, Sync<G>>()`, the Reactor base class constructs a `Binder`:
 
 ```cpp
 template <typename... DSL, typename... Arguments>
@@ -56,9 +56,9 @@ The key type here is `dsl::Parse<Trigger<T>, Sync<G>>` — this is the "fused" D
 When `.then()` is called, several things happen in sequence:
 
 1. **CallbackGenerator created** — wraps your lambda with the DSL's get/precondition/scope logic
-2. **Reaction object created** — stores the generator, identifiers, and reactor reference
-3. **`DSL::bind(reaction)` called** — each word registers itself (e.g., Trigger adds to TypeCallbackStore)
-4. **ReactionHandle returned** — lets you enable/disable the reaction later
+1. **Reaction object created** — stores the generator, identifiers, and reactor reference
+1. **`DSL::bind(reaction)` called** — each word registers itself (e.g., Trigger adds to TypeCallbackStore)
+1. **ReactionHandle returned** — lets you enable/disable the reaction later
 
 ```cpp
 auto reaction = std::make_shared<threading::Reaction>(
@@ -103,9 +103,9 @@ emit(std::make_unique<SensorData>(...));
 This calls `Local::emit` which:
 
 1. Stores the data in the global `DataStore<SensorData>`
-2. Sets `ThreadStore<SensorData>` (thread-local pointer) to the new data
-3. Looks up `TypeCallbackStore<SensorData>` for all registered reactions
-4. For each reaction: calls `reaction->get_task()` to create a task
+1. Sets `ThreadStore<SensorData>` (thread-local pointer) to the new data
+1. Looks up `TypeCallbackStore<SensorData>` for all registered reactions
+1. For each reaction: calls `reaction->get_task()` to create a task
 
 ## Phase 6: Task Creation — CallbackGenerator
 
@@ -127,9 +127,9 @@ The `CallbackGenerator` does this in order:
 
 1. **Creates a ReactionTask** with priority, inline preference, pool, and group functions
 1. **Checks precondition** — if false, task is dropped (e.g., [`Single`](../reference/dsl/single.md) blocks if already running)
-3. **Calls `DSL::get()`** — reads the data from ThreadStore (freshest) or DataStore (latest)
-4. **Checks data validity** — if any required data is null, task is dropped
-5. **Captures the callback** — binds the data into a closure stored on the task
+1. **Calls `DSL::get()`** — reads the data from ThreadStore (freshest) or DataStore (latest)
+1. **Checks data validity** — if any required data is null, task is dropped
+1. **Captures the callback** — binds the data into a closure stored on the task
 
 ## Phase 7: Task Submitted
 
@@ -184,7 +184,7 @@ flowchart TD
 
 The DSL uses several layers of compile-time machinery:
 
-### Parse<Words...>
+### Parse\<Words...>
 
 `Parse` is the entry point. It creates `Fusion<Words...>` and delegates each operation (bind, get, group, pool, priority, etc.) to the fusion, falling back to a `NoOp` if no word implements that operation.
 

docs/explanation/index.md

@@ -6,12 +6,12 @@ If you've already followed the tutorials and know how to use NUClear, this is wh
 
 ## Pages
 
-| Page | What It Covers |
-|------|---------------|
-| [Architecture](architecture.md) | Why NUClear exists, the problems it solves, and the event-driven reactive pattern at its core |
-| [Threading Model](threading.md) | How tasks are scheduled across thread pools, priority queues, and group constraints |
-| [Lifecycle](lifecycle.md) | The three phases of a NUClear system: initialisation, execution, and shutdown |
-| [The DSL System](dsl-system.md) | How `on<>().then()` works from top to bottom — template metaprogramming in action |
-| [Message Flow](message-flow.md) | What happens when you emit data, from call site to reaction execution |
-| [NUClearNet](nuclear-net.md) | The peer-to-peer networking mesh that connects NUClear instances |
-| [Serialization](serialization.md) | How data is converted for network transmission |
+| Page                              | What It Covers                                                                                |
+| --------------------------------- | --------------------------------------------------------------------------------------------- |
+| [Architecture](architecture.md)   | Why NUClear exists, the problems it solves, and the event-driven reactive pattern at its core |
+| [Threading Model](threading.md)   | How tasks are scheduled across thread pools, priority queues, and group constraints           |
+| [Lifecycle](lifecycle.md)         | The three phases of a NUClear system: initialisation, execution, and shutdown                 |
+| [The DSL System](dsl-system.md)   | How `on<>().then()` works from top to bottom — template metaprogramming in action             |
+| [Message Flow](message-flow.md)   | What happens when you emit data, from call site to reaction execution                         |
+| [NUClearNet](nuclear-net.md)      | The peer-to-peer networking mesh that connects NUClear instances                              |
+| [Serialization](serialization.md) | How data is converted for network transmission                                                |