@powerhousedao/academy 4.1.0-staging.1 → 5.0.0-staging.10

package/docs/academy/02-MasteryTrack/01-BuilderEnvironment/02-StandardDocumentModelWorkflow.md

@@ -1,8 +1,8 @@
 # Create Powerhouse packages
 
 :::warning
-**This tutorial is a summary for builders that are already familiar with building document models**.    
-It provides a summary from initial setup up to publishing a distributable package.    
+**This tutorial is a summary for builders that are already familiar with building document models**.  
+It provides a summary from initial setup up to publishing a distributable package.
 
 Please start with the '**Get Started**' Chapter or '**Document Model Creation**' section if you are unfamiliar with building a document model.
 :::
@@ -10,35 +10,41 @@ Please start with the '**Get Started**' Chapter or '**Document Model Creation**'
 <details>
 <summary>Key commands that you'll use in this flow</summary>
 
--   `pnpm install -g ph-cmd`: Installs the Powerhouse CLI globally.
--   `ph init`: Initializes a new Powerhouse project or sets up the local environment.
--   `ph connect`: Runs Connect in Studio Mode for local development and testing.
--   `ph generate <YourModelName.phdm.zip>`: Generates scaffolding code from an exported document model specification.
--   `ph generate --editor YourModelName --document-types powerhouse/YourModelName`: Generates an editor template for a document model.
--   `pnpm build`: Builds the project for production.
--   `pnpm run test`: Runs unit tests.
--   `npm login`: Logs into your NPM account.
--   `npm publish`: Publishes your package to NPM.
--   `ph install @your-org-ph/your-package-name`: Installs a published package into a local Powerhouse environment.
+- `pnpm install -g ph-cmd`: Installs the Powerhouse CLI globally.
+- `ph init`: Initializes a new Powerhouse project or sets up the local environment.
+- `ph connect`: Runs Connect in Studio Mode for local development and testing.
+- `ph generate <YourModelName.phdm.zip>`: Generates scaffolding code from an exported document model specification.
+- `ph generate --editor YourModelName --document-types powerhouse/YourModelName`: Generates an editor template for a document model.
+- `pnpm build`: Builds the project for production.
+- `pnpm run test`: Runs unit tests.
+- `npm login`: Logs into your NPM account.
+- `npm publish`: Publishes your package to NPM.
+- `ph install @your-org-ph/your-package-name`: Installs a published package into a local Powerhouse environment.
 
 </details>
 
 ## Phase 1: Setup and initialization
 
 ### 1.1. Install Powerhouse CLI
+
 Ensure you have the Powerhouse Command Line Interface (`ph-cmd`) installed. This tool is crucial for managing your Powerhouse projects.
+
 ```bash
 pnpm install -g ph-cmd
 ```
+
 :::info **Prerequisites**
 The [Prerequisites](/academy/MasteryTrack/BuilderEnvironment/Prerequisites) guide for detailed installation instructions for Node.js, pnpm, and Git if you haven't set them up yet.
 :::
 
 ### 1.2. Initialize your project environment
+
 Before creating a specific project, or if you're setting up your environment for the first time to use Connect Studio Mode, initialize the Powerhouse environment. This command prepares your local setup, including a local Reactor configuration.
+
 ```bash
 ph init
 ```
+
 If you are starting a new project to be packaged, this command will also prompt you for a project name. This name will be used for your package.
 
 <details>
@@ -46,26 +52,30 @@ If you are starting a new project to be packaged, this command will also prompt
 
 When installing or using the Powerhouse CLI commands you are able to make use of the dev & staging branches. These branches contain more experimental features then the latest stable release the PH CLI uses by default. They can be used to get access to a bugfix or features under development.
 
-| Command | Description |
-|---------|-------------|
-| **pnpm install -g ph-cmd** | Install latest stable version |
-| **pnpm install -g ph-cmd@dev** | Install development version |
-| **pnpm install -g ph-cmd@staging** | Install staging version |
-| **ph init** | Use latest stable version of the boilerplate |
-| **ph init --dev** | Use development version of the boilerplate |
-| **ph init --staging** | Use staging version of the boilerplate |
-| **ph use** | Switch all dependencies to latest production versions |
-| **ph use dev** | Switch all dependencies to development versions |
-| **ph use prod** | Switch all dependencies to production versions |
+| Command                            | Description                                           |
+| ---------------------------------- | ----------------------------------------------------- |
+| **pnpm install -g ph-cmd**         | Install latest stable version                         |
+| **pnpm install -g ph-cmd@dev**     | Install development version                           |
+| **pnpm install -g ph-cmd@staging** | Install staging version                               |
+| **ph init**                        | Use latest stable version of the boilerplate          |
+| **ph init --dev**                  | Use development version of the boilerplate            |
+| **ph init --staging**              | Use staging version of the boilerplate                |
+| **ph use**                         | Switch all dependencies to latest production versions |
+| **ph use dev**                     | Switch all dependencies to development versions       |
+| **ph use prod**                    | Switch all dependencies to production versions        |
 
 Please be aware that these versions can contain bugs and experimental features that aren't fully tested.
+
 </details>
 
 ### 1.3. Launch Connect in studio mode
+
 Connect is your local development hub. Running it in Studio Mode spins up a local instance with a local Reactor, allowing you to define, build, and test document models.
+
 ```bash
 ph connect
 ```
+
 This command typically opens Connect in your browser at `http://localhost:3000/`.
 
 :::info
@@ -75,69 +85,89 @@ This command typically opens Connect in your browser at `http://localhost:3000/`
 ## Phase 2: Document model specification
 
 ### 2.1. Define the document model schema
+
 Within Connect Studio Mode, navigate to the Document Model Editor. Here, you'll specify the structure of your document model using GraphQL Schema Definition Language (SDL).
--   **State Schema:** Describes the data fields and types within your document (e.g., `ToDoItem` with `id`, `text`, `checked` fields).
--   This schema is the blueprint for your document model's data.
+
+- **State Schema:** Describes the data fields and types within your document (e.g., `ToDoItem` with `id`, `text`, `checked` fields).
+- This schema is the blueprint for your document model's data.
 
 ### 2.2. Define document model operations
+
 In the same editor, specify the operations (state transitions) for your document model. These are also defined using GraphQL, specifically input types.
--   **Operations Schema:** Specifies the actions that can be performed on the document (e.g., `AddTodoItemInput`, `UpdateTodoItemInput`, `DeleteTodoItemInput`).
--   Each input type details the parameters required for an operation.
--   **Best Practices:**
-    *   Clearly define operations (often aligning with CRUD principles).
-    *   Use GraphQL input types for operation parameters.
-    *   Ensure operations reflect user intent for a clean API.
+
+- **Operations Schema:** Specifies the actions that can be performed on the document (e.g., `AddTodoItemInput`, `UpdateTodoItemInput`, `DeleteTodoItemInput`).
+- Each input type details the parameters required for an operation.
+- **Best Practices:**
+  - Clearly define operations (often aligning with CRUD principles).
+  - Use GraphQL input types for operation parameters.
+  - Ensure operations reflect user intent for a clean API.
 
 ### 2.3. Export document model specification
+
 Once your schema and operations are defined in Connect, export the specification. This will download a `.phdm.zip` file (e.g., `YourModelName.phdm.zip`). Save this file in the root of your Powerhouse project directory.
 
 ## Phase 3: Implementation and testing
 
 ### 3.1. Generate scaffolding code
+
 Use the Powerhouse CLI to process the exported `.phdm.zip` file and generate the necessary boilerplate code for your document model.
+
 ```bash
 ph generate YourModelName.phdm.zip
 ```
+
 This command creates a new directory under `document-models/YourModelName/` containing:
--   A JSON file with the document model specification.
--   A GraphQL file with the state and operation schemas.
--   A `gen/` folder with autogenerated TypeScript types, action creators, and utility functions based on your schema.
--   A `src/` folder where you'll implement your custom logic (reducers, utils).
+
+- A JSON file with the document model specification.
+- A GraphQL file with the state and operation schemas.
+- A `gen/` folder with autogenerated TypeScript types, action creators, and utility functions based on your schema.
+- A `src/` folder where you'll implement your custom logic (reducers, utils).
 
 ### 3.2. Implement reducer logic
+
 Reducers are pure functions that implement the state transition logic for each operation defined in your schema. Navigate to `document-models/YourModelName/src/reducers/to-do-list.ts` (or similar, based on your model name).
--   Implement the functions for each operation (e.g., `addTodoItemOperation`, `updateTodoItemOperation`).
--   These functions take the current state and an action (containing input data) and return the new state.
--   Powerhouse handles immutability behind the scenes.
+
+- Implement the functions for each operation (e.g., `addTodoItemOperation`, `updateTodoItemOperation`).
+- These functions take the current state and an action (containing input data) and return the new state.
+- Powerhouse handles immutability behind the scenes.
 
 ### 3.3. Write unit tests for reducers
+
 It's crucial to test your reducer logic. Write unit tests in the `document-models/YourModelName/src/reducers/tests/` directory.
--   Verify that each operation correctly transforms the document state.
--   Use the auto-generated action creators from the `gen/` folder to create operation actions for your tests.
-Run tests using:
+
+- Verify that each operation correctly transforms the document state.
+- Use the auto-generated action creators from the `gen/` folder to create operation actions for your tests.
+  Run tests using:
+
 ```bash
 pnpm run test
 ```
 
 ### 3.4. Implement the document editor
+
 A document editor provides the user interface for interacting with your document model in Connect. Generate an editor template:
+
 ```bash
 ph generate --editor YourModelName --document-types powerhouse/YourModelName
 ```
--   The `--editor YourModelName` flag specifies the document model this editor is for.
--   The `--document-types powerhouse/YourModelName` flag links the editor to the specific document type defined in your model specification (ensure this matches what you set in Connect).
+
+- The `--editor YourModelName` flag specifies the document model this editor is for.
+- The `--document-types powerhouse/YourModelName` flag links the editor to the specific document type defined in your model specification (ensure this matches what you set in Connect).
 
 This creates a template file, typically at `editors/your-model-name/editor.tsx`.
--   Customize this React component to build your UI.
--   You can use standard HTML, Tailwind CSS (available in Connect), or import custom CSS.
--   Utilize components from `@powerhousedao/document-engineering` for consistency and rapid development. Learn more at [Document-Engineering](/academy/ComponentLibrary/DocumentEngineering)
 
+- Customize this React component to build your UI.
+- You can use standard HTML, Tailwind CSS (available in Connect), or import custom CSS.
+- Utilize components from `@powerhousedao/document-engineering` for consistency and rapid development. Learn more at [Document-Engineering](/academy/ComponentLibrary/DocumentEngineering)
 
 ### 3.5. Test the editor
+
 Run Connect locally to see your editor in action:
+
 ```bash
 ph connect
 ```
+
 Create a new document of your defined type. Interact with your editor, test all functionalities, and ensure it correctly dispatches actions to the reducers and reflects state changes.
 
 ## Phase 4: Packaging and publishing
@@ -145,27 +175,32 @@ Create a new document of your defined type. Interact with your editor, test all
 Once your document model and editor are implemented and tested, you can package them for distribution. A Powerhouse Package is a modular unit that can group document models, editors, scripts, and processors.
 
 ### 4.1. Prepare project for packaging
+
 If you didn't initialize your project with `ph init` intending it as a package, ensure your project structure is set up correctly. The `ph init` command is designed to create this structure.
--   `document-models/`: Contains your document models.
--   `editors/`: Contains your editor components.
--   `src/`: Often used for shared utilities or can be part of the model/editor structure.
--   (Optional) `processors/`, `scripts/` for advanced functionalities.
+
+- `document-models/`: Contains your document models.
+- `editors/`: Contains your editor components.
+- `src/`: Often used for shared utilities or can be part of the model/editor structure.
+- (Optional) `processors/`, `scripts/` for advanced functionalities.
 
 ### 4.2. Specify package details in `package.json`
+
 Navigate to the `package.json` file in your project root. This file is crucial for NPM publishing.
--   **`name`**: Follow a scoped naming convention, e.g., `@your-org-ph/your-package-name`. The `-ph` suffix helps identify Powerhouse ecosystem packages.
--   **`version`**: Use semantic versioning (e.g., `1.0.0`).
--   **`author`**: Your name or organization.
--   **`license`**: e.g., `AGPL-3.0-only`.
--   **`main`**: The entry point of your package (e.g., `index.js` or `dist/index.js`).
--   **`publishConfig`**: For scoped packages intended to be public, add:
-    ```json
-    "publishConfig": {
-      "access": "public"
-    }
-    ```
+
+- **`name`**: Follow a scoped naming convention, e.g., `@your-org-ph/your-package-name`. The `-ph` suffix helps identify Powerhouse ecosystem packages.
+- **`version`**: Use semantic versioning (e.g., `1.0.0`).
+- **`author`**: Your name or organization.
+- **`license`**: e.g., `AGPL-3.0-only`.
+- **`main`**: The entry point of your package (e.g., `index.js` or `dist/index.js`).
+- **`publishConfig`**: For scoped packages intended to be public, add:
+  ```json
+  "publishConfig": {
+    "access": "public"
+  }
+  ```
 
 Example `package.json` snippet:
+
 ```json
 {
   "name": "@your-org-ph/your-package-name",
@@ -173,9 +208,10 @@ Example `package.json` snippet:
   "author": "Your Name",
   "license": "AGPL-3.0-only",
   "main": "index.js",
-  "files": [ // Ensure your build output and necessary files are included
+  "files": [
+    // Ensure your build output and necessary files are included
     "dist",
-    "manifest.json", 
+    "manifest.json",
     "document-models",
     "editors"
   ],
@@ -186,9 +222,11 @@ Example `package.json` snippet:
 ```
 
 ### 4.3. Add a manifest file (`manifest.json`)
+
 Create a `manifest.json` file in your project root. This file describes your package's contents (document models, editors) and helps host applications like Connect understand and integrate your package.
 
 Example `manifest.json`:
+
 ```json
 {
   "name": "@yourorg-ph/your-package-name", // it's recommended to use an organization-specific NPM account (e.g., `yourorg-ph`).
@@ -196,34 +234,40 @@ Example `manifest.json`:
   "category": "your-category", // e.g., "Finance", "People Ops", "Legal"
   "publisher": {
     "name": "your-publisher-name", // Your organization or name
-    "url": "your-publisher-url"   // Link to your website or repository
+    "url": "your-publisher-url" // Link to your website or repository
   },
   "documentModels": [
     {
       "id": "powerhouse/YourModelName", // Document type string as defined in Connect
-      "name": "YourModelName"          // Human-readable name
+      "name": "YourModelName" // Human-readable name
     }
   ],
   "editors": [
     {
-      "id": "your-editor-id",          // A unique ID for the editor component
-      "name": "YourModelName Editor",  // Human-readable name
+      "id": "your-editor-id", // A unique ID for the editor component
+      "name": "YourModelName Editor", // Human-readable name
       "documentTypes": ["powerhouse/YourModelName"] // Links editor to document type(s)
     }
   ]
 }
 ```
+
 Update your project's main `index.js` or entry point to export your document models and editors so they can be discovered by Powerhouse applications.
 
 ### 4.4. Build your project
+
 Compile and optimize your project for production:
+
 ```bash
 pnpm build
 ```
+
 This command typically creates a `dist/` or `build/` directory with the compiled assets. Ensure your `package.json`'s `files` array includes this directory and other necessary assets like `manifest.json`, `document-models`, and `editors` if they are not part of the build output but need to be in the package.
 
 ### 4.5. Version control
+
 Store your project in a Git repository for versioning and collaboration.
+
 ```bash
 git init
 git add .
@@ -233,13 +277,16 @@ git commit -m "Initial commit of document model package"
 ```
 
 ### 4.6. Publish to NPM
+
 To share your package with others or deploy it to different environments, publish it to the NPM registry.
 
 1.  **Login to NPM:**
     If you haven't already, log into your NPM account. It's recommended to use an organization-specific NPM account (e.g., `yourorg-ph`).
+
     ```bash
     npm login
     ```
+
     Follow the prompts in your terminal or browser.
 
 2.  **Publish the package:**
@@ -249,10 +296,13 @@ To share your package with others or deploy it to different environments, publis
     If your package is scoped and public, NPM will use the `publishConfig` from your `package.json`. If not set there, you might need `npm publish --access public`.
 
 ### 4.7. Using your published package
+
 Once published, your package can be installed and used in any Powerhouse environment (like another local Connect instance or a deployed Reactor setup).
+
 ```bash
 ph install @your-org-ph/your-package-name
 ```
+
 This command makes the document models and editors defined in your package available within that Powerhouse instance.
 
-Congratulations! You've successfully created, packaged, and published a Powerhouse Document Model. This enables modularity, reusability, and collaboration within the Powerhouse ecosystem.
+Congratulations! You've successfully created, packaged, and published a Powerhouse Document Model. This enables modularity, reusability, and collaboration within the Powerhouse ecosystem.

package/docs/academy/02-MasteryTrack/01-BuilderEnvironment/03-BuilderTools.md

@@ -1,23 +1,27 @@
 # Powerhouse builder tooling
 
-This page provides an overview of all the builder tooling offered by the Powerhouse ecosystem.   
+This page provides an overview of all the builder tooling offered by the Powerhouse ecosystem.  
 This list will be maintained and updated as our toolkit grows.
 
 ## Powerhouse command line interface
-___
 
-### Installing the Powerhouse CLI 
+---
+
+### Installing the Powerhouse CLI
+
 :::tip
-The Powerhouse CLI tool is the only essential tool to install on this page.   
+The Powerhouse CLI tool is the only essential tool to install on this page.  
 Once you've installed it with the command below you can continue to the next steps.
 :::
 
 The Powerhouse CLI (`ph-cmd`) is a command-line interface tool that provides essential commands for managing Powerhouse projects. You can get access to the Powerhouse ecosystem tools by installing them globally using:
+
 ```bash
 pnpm install -g ph-cmd
-``` 
+```
 
 Key commands include:
+
 - `ph connect` for running the Connect application locally
 - `ph switchboard` or `ph reactor` for starting the API service
 - `ph init` to start a new project and build a Document Model
@@ -30,19 +34,20 @@ This tool will be fundamental on your journey when creating, building, and runni
 
 When installing or using the Powerhouse CLI commands you are able to make use of the dev & staging branches. These branches contain more experimental features then the latest stable release the PH CLI uses by default. They can be used to get access to a bugfix or features under development.
 
-| Command | Description |
-|---------|-------------|
-| **pnpm install -g ph-cmd** | Install latest stable version |
-| **pnpm install -g ph-cmd@dev** | Install development version |
-| **pnpm install -g ph-cmd@staging** | Install staging version |
-| **ph init** | Use latest stable version of the boilerplate |
-| **ph init --dev** | Use development version of the boilerplate |
-| **ph init --staging** | Use staging version of the boilerplate |
-| **ph use** | Switch all dependencies to latest production versions |
-| **ph use dev** | Switch all dependencies to development versions |
-| **ph use prod** | Switch all dependencies to production versions |
+| Command                            | Description                                           |
+| ---------------------------------- | ----------------------------------------------------- |
+| **pnpm install -g ph-cmd**         | Install latest stable version                         |
+| **pnpm install -g ph-cmd@dev**     | Install development version                           |
+| **pnpm install -g ph-cmd@staging** | Install staging version                               |
+| **ph init**                        | Use latest stable version of the boilerplate          |
+| **ph init --dev**                  | Use development version of the boilerplate            |
+| **ph init --staging**              | Use staging version of the boilerplate                |
+| **ph use**                         | Switch all dependencies to latest production versions |
+| **ph use dev**                     | Switch all dependencies to development versions       |
+| **ph use prod**                    | Switch all dependencies to production versions        |
 
 Please be aware that these versions can contain bugs and experimental features that aren't fully tested.
+
 </details>
 
 <details>
@@ -54,16 +59,19 @@ Please be aware that these versions can contain bugs and experimental features t
 If you need to perform a clean reinstallation of the Powerhouse CLI (`ph-cmd`), follow these steps:
 
 1. First, uninstall the global ph-cmd package:
+
 ```bash
 pnpm uninstall -g ph-cmd
 ```
 
 2. Remove the Powerhouse configuration directory:
+
 ```bash
 rm -rf ~/.ph
 ```
 
 3. Reinstall the CLI tool (choose one):
+
 ```bash
 # For the latest stable version
 pnpm install -g ph-cmd
@@ -76,20 +84,24 @@ pnpm install -g ph-cmd@<version>
 ```
 
 This process ensures a clean slate by removing both the CLI tool and its configuration files before installing the desired version. It's particularly useful when:
+
 - Troubleshooting CLI issues
 - Upgrading to a new version
 - Switching between stable and staging versions
-- Resolving configuration conflicts 			
+- Resolving configuration conflicts
 
 </details>
 
 ### The use command
+
 The use command allows you to switch between different environments for your Powerhouse project dependencies.
 
 ```bash
 ph use <environment> [localPath]
-``` 
+```
+
 **Available Environments**
+
 - latest - Uses the latest stable version of all Powerhouse packages.
 - dev - Uses development versions of the packages.
 - prod - Uses production versions of the packages.
@@ -98,26 +110,31 @@ ph use <environment> [localPath]
 **Examples**
 
 #### Switch to latest stable versions
+
 ```bash
 ph use latest
-``` 
+```
 
 #### Switch to development versions
+
 ```bash
 ph use dev
-``` 
+```
 
 #### Use local versions from a specific path
+
 ```bash
 ph use local /path/to/local/packages
-``` 
+```
 
 #### Use a specific package manager
+
 ```bash
 ph use latest --package-manager pnpm
-``` 
+```
 
 ### The update command
+
 The update command allows you to update your Powerhouse dependencies to their latest versions based on the version ranges specified in your package.json.
 
 ```bash
@@ -125,22 +142,27 @@ ph update [options]
 ```
 
 **Examples**
+
 #### Update dependencies based on package.json ranges
+
 ```bash
 ph update
 ```
 
 #### Force update to latest dev versions
+
 ```bash
 ph update --force dev
 ```
 
 #### Force update to latest stable versions
+
 ```bash
 ph update --force prod
 ```
 
 #### Use a specific package manager
+
 ```bash
 ph update --package-manager pnpm
 ```
@@ -148,11 +170,13 @@ ph update --package-manager pnpm
 ## **Key differences**
 
 ### **Use command**
+
 - For switching between different **environments**.
 - Requires you to specify an environment.
 - Can work with **local packages**.
 
 ### **Update command**
+
 - Updating **dependencies** within your current environment.
 - Optional with its parameters.
 - Focused on updating **remote package** versions.
@@ -160,12 +184,15 @@ ph update --package-manager pnpm
 Both commands support multiple package managers (npm, yarn, pnpm, and bun) and will automatically detect your project's package manager based on the lockfile present in your project directory.
 
 ## Boilerplate
-___
-The Document Model Boilerplate is a foundational template that is used for code generation when scaffolding your editors and models. It ensures compatibility with host applications like Connect and Switchboard for seamless Document Model and editor integration. 
 
-After installing `ph-cmd`, you will run `ph init` to initialize a project directory and structure. This initialization command makes use of the boilerplate. 
+---
+
+The Document Model Boilerplate is a foundational template that is used for code generation when scaffolding your editors and models. It ensures compatibility with host applications like Connect and Switchboard for seamless Document Model and editor integration.
+
+After installing `ph-cmd`, you will run `ph init` to initialize a project directory and structure. This initialization command makes use of the boilerplate.
 
 The boilerplate includes essential commands with NPM/PNPM scripts for:
+
 - Generating code
 - Linting
 - Formatting
@@ -173,8 +200,11 @@ The boilerplate includes essential commands with NPM/PNPM scripts for:
 - Testing
 
 ## Design system
-___
+
+---
+
 The Powerhouse Design System is a collection of reusable front-end components based on GraphQL scalars, including custom scalars specific to the web3 ecosystem. It provides:
+
 - Consistent UI components across Powerhouse applications
 - Automatic inclusion as a dependency in new Document Model projects
 - Customization options using CSS variables
@@ -182,29 +212,37 @@ The Powerhouse Design System is a collection of reusable front-end components ba
 We cover some of these topics in our design system documentation. Read more about the [design system here](/academy/ComponentLibrary/DocumentEngineering)
 
 ## Reactor libraries
-___
-Reactors are the nodes in the Powerhouse network that handle document storage, conflict resolution, and operation verification. 
+
+---
+
+Reactors are the nodes in the Powerhouse network that handle document storage, conflict resolution, and operation verification.
 The Reactor Libraries include:
 
 ### API
+
 - **Subgraphs**: Modular GraphQL services that connect to the Reactor for structured data access
 - **Processors**: Event-driven components that react to document changes and process data
 
 ### Browser
+
 Handles client-side interactions
 
 ### Local
+
 Manages local storage and offline functionality
 
 ### Drive app
-Handles document organization and storage management, but can also be customized to offer specific functionality, categorization, or tailored interfaces for your documents. 
+
+Handles document organization and storage management, but can also be customized to offer specific functionality, categorization, or tailored interfaces for your documents.
 
 ## Code generators
-___
+
+---
+
 Powerhouse provides several code generation tools to streamline development:
 
     ### Document model scaffolding
-    Generates the basic structure for new Document Models with the command `ph init` based on the boilerplate. 
+    Generates the basic structure for new Document Models with the command `ph init` based on the boilerplate.
 
     ### Editor generator
     Creates template code for Document Model editors with the command `ph generate --editor <name> --document-types <documenttype>`
@@ -222,14 +260,18 @@ Powerhouse provides several code generation tools to streamline development:
     Creates specialized processors for analytics tracking
 
 ## Analytics engine
-___
+
+---
+
 The Analytics Engine is a system that allows tracking and analyzing operations and state changes on Document Models. Features include:
+
 - Custom dashboard and report generation
 - Document Model-specific analytics
 - Metric and dimension tracking
 - Data combination from multiple Document Models
 
 Generate an analytics processor using:
+
 ```bash
 ph generate --processor-type analytics
-```
+```

package/docs/academy/02-MasteryTrack/01-BuilderEnvironment/_category_.json

@@ -1,7 +1,7 @@
 {
-    "label": "Builder environment",
-    "link": {
-      "type": "doc",
-      "id": "academy/MasteryTrack/BuilderEnvironment/Prerequisites"
-    }
-  }
+  "label": "Builder environment",
+  "link": {
+    "type": "doc",
+    "id": "academy/MasteryTrack/BuilderEnvironment/Prerequisites"
+  }
+}