@powerhousedao/academy 5.1.0-staging.0 → 5.1.0

package/docs/academy/01-GetStarted/04-BuildToDoListEditor.md

@@ -0,0 +1,218 @@
+# Build a to-do list editor
+
+In this chapter we will continue with the interface or editor implementation of the **To-do List** document model. This means you will create a simple user interface for the **To-do List** document model which will be used inside the Connect app to create, update and delete your ToDoList items.
+
+## Generate the editor template
+
+Run the command below to generate the editor template for the **To-do List** document model.  
+This command reads the **To-do List** document model definition from the `document-models` folder and generates the editor template in the `editors/to-do-list` folder as `editor.tsx`.
+
+Notice the `--editor` flag which specifies the **To-do List** document model, and the `--document-types` flag defines the document type `powerhouse/todolist`.
+
+```bash
+ph generate --editor ToDoList --document-types powerhouse/todolist
+```
+
+Once complete, navigate to the `editors/to-do-list/editor.tsx` file and open it in your editor.
+
+### Editor implementation options
+
+When building your editor component within the Powerhouse ecosystem, you have several options for styling, allowing you to leverage your preferred methods:
+
+1.  **Default HTML Styling:** Standard HTML tags (`<h1>`, `<p>`, `<button>`, etc.) will render with default styles offered through the boilerplate.
+2.  **Tailwind CSS:** Connect Studio comes with Tailwind CSS integrated. You can directly use Tailwind utility classes for rapid, consistent styling without writing separate CSS files.
+3.  **Custom CSS Files:** You can import traditional CSS files (`.css`) to apply custom styles or integrate existing style libraries.
+
+Connect Studio provides a dynamic local environment, by running `ph connect` to visualize your components instantly as you build them, regardless of the styling method you choose.  
+Manual build steps are typically only needed when publishing packages.
+
+## To-do List editor
+
+Below is the complete code for the To-Do List editor. Paste this code in `editors/to-do-list/editor.tsx`.
+
+<details>
+<summary>Complete ToDoList Editor Example (using Tailwind CSS)</summary>
+
+```typescript
+import { EditorProps } from 'document-model';
+import {
+    ToDoListState,
+    ToDoListAction,
+    ToDoListLocalState,
+    ToDoItem,
+    actions,
+    ToDoListDocument,
+} from '../../document-models/to-do-list/index.js';
+import { useState } from 'react';
+
+// EditorProps is a generic type that provides the document and a dispatch function.
+// The dispatch function is used to send actions to the document's reducer to update the state.
+export type IProps = EditorProps<ToDoListDocument>;
+
+export default function Editor(props: IProps) {
+    // Destructure document and dispatch from props.
+    const { document, dispatch } = props;
+    // Get the global state from the document. This state is shared across all editors of this document.
+    const {
+        state: { global: state },
+    } = document;
+
+    // React's useState hook is used for local component state.
+    // This state is not shared with other components.
+    // `todoItem` stores the text of the new to-do item being added.
+    const [todoItem, setTodoItem] = useState('');
+    // `editingItemId` stores the ID of the item currently being edited.
+    const [editingItemId, setEditingItemId] = useState<string | null>(null);
+    // `editedText` stores the text of the item while it's being edited.
+    const [editedText, setEditedText] = useState('');
+
+    return (
+        <div className="p-4 font-sans max-w-lg mx-auto">
+            <h1 className="text-2xl font-bold mb-4 text-center">To-do List</h1>
+            <div className="w-96 mx-auto">
+                <div className="flex mb-4">
+                    <input
+                        className="border border-gray-300 p-2 rounded-l-md flex-grow"
+                        placeholder="Insert task here..."
+                        value={todoItem}
+                        onChange={e => setTodoItem(e.target.value)}
+                        onKeyDown={e => {
+                            if (e.key === 'Enter') {
+                                // Dispatch an action to add a new to-do item.
+                                // `actions.addTodoItem` is an action creator from our document model.
+                                dispatch(
+                                    actions.addTodoItem({
+                                        id: Math.random().toString(), // In a real app, use a more robust ID generation.
+                                        text: todoItem,
+                                    })
+                                );
+                                setTodoItem('');
+                            }
+                        }}
+                    />
+                    <button
+                        className="bg-blue-500 hover:bg-blue-600 text-white p-2 rounded-r-md"
+                        onClick={() => {
+                            // Also add item on button click.
+                            dispatch(
+                                actions.addTodoItem({
+                                    id: Math.random().toString(),
+                                    text: todoItem,
+                                })
+                            );
+                            setTodoItem('');
+                        }}
+                    >
+                        Add
+                    </button>
+                </div>
+                <ul className="list-none p-0">
+                    {/* Map over the items in the global state to render each to-do item. */}
+                    {state.items.map((item: ToDoItem) => (
+                        <li
+                            key={item.id}
+                            className="flex items-center p-2 relative border-b border-gray-200"
+                        >
+                            <input
+                                type="checkbox"
+                                checked={item.checked}
+                                className="mr-3"
+                                onChange={() => {
+                                    // Dispatch an action to update the checked status of an item.
+                                    dispatch(
+                                        actions.updateTodoItem({
+                                            id: item.id,
+                                            checked: !item.checked,
+                                        })
+                                    );
+                                }}
+                            />
+                            {/* Conditional rendering: show an input field if the item is being edited, otherwise show the text. */}
+                            {editingItemId === item.id ? (
+                                <input
+                                    value={editedText}
+                                    onChange={e =>
+                                        setEditedText(e.target.value)
+                                    }
+                                    onKeyDown={e => {
+                                        if (e.key === 'Enter') {
+                                            // Dispatch an action to update the item's text.
+                                            dispatch(
+                                                actions.updateTodoItem({
+                                                    id: item.id,
+                                                    text: editedText,
+                                                })
+                                            );
+                                            // Exit editing mode.
+                                            setEditingItemId(null);
+                                        }
+                                    }}
+                                    className="flex-grow"
+                                    autoFocus // Automatically focus the input when it appears.
+                                />
+                            ) : (
+                                <div className="flex items-center flex-grow gap-1">
+                                    <span
+                                        onClick={() => {
+                                            // Enter editing mode when the text is clicked.
+                                            setEditingItemId(item.id);
+                                            setEditedText(item.text);
+                                        }}
+                                        className={`cursor-pointer ${
+                                            item.checked
+                                                ? 'line-through text-gray-500'
+                                                : ''
+                                        }`}
+                                    >
+                                        {item.text}
+                                    </span>
+                                    <span
+                                        onClick={() =>
+                                            dispatch(
+                                                actions.deleteTodoItem({
+                                                    id: item.id,
+                                                })
+                                            )
+                                        }
+                                        className="text-gray-400 cursor-pointer opacity-40 transition-all duration-200 text-base font-bold inline-flex items-center pl-1 hover:opacity-100 hover:text-red-500"
+                                    >
+                                        ×
+                                    </span>
+                                </div>
+                            )}
+                        </li>
+                    ))}
+                </ul>
+            </div>
+        </div>
+    );
+}
+```
+
+</details>
+
+Now you can run the Connect app and see the **To-do List** editor in action.
+
+```bash
+ph connect
+```
+
+In Connect, in the bottom right corner you'll find a new Document Model that you can create: **To-do List**.  
+Click on it to create a new To-do List document.
+
+:::info
+The editor will update dynamically, so you can play around with your editor styling while seeing your results appear in Connect Studio.
+:::
+
+Congratulations!
+If you managed to follow this tutorial until this point, you have successfully implemented the **To-do List** document model with its reducer operations and editor.
+
+### Up next: Mastery Track
+
+In the [Mastery Track chapther: Document Model Creation](/academy/MasteryTrack/DocumentModelCreation/WhatIsADocumentModel) we guide you through the theoretics of the previous steps while created a more advanced version of the To-do List.
+
+You will learn:
+
+- The in's & out's of a document model.
+- How to use UI & Scalar components from the Document Engineering system.
+- How to build Custom Drive Apps or Drive Explorers.

package/docs/academy/{02-MasteryTrack/01-BuilderEnvironment → 01-GetStarted}/05-VetraStudio.md

@@ -1,13 +1,26 @@
-# Vetra Studio 
+# Tool: Vetra Studio 
+
+:::tip Important
+
+## Vision: Specification Driven AI
+
+In the **'Get Started'** chapter we've been making use of strict schema definition principles to communicate the intended use case of our reactive documents. 
+The **schema definition language**, is a not only a shared language that bridges the gap between developer, designer and analyst but also the gap between builder and AI-agent through **specification driven AI control**.
+
+- Communicate your solution and intent through a structured specification framework designed for AI collaboration.
+- Specifications enable precise, iterative edits, since all our specification documents are machine-readable and executable.
+:::
 
 ## Introducing Vetra Studio
 
-- **Vetra Studio Drive**: Serves as a hub for developers to access, manage & share specification through a remote Vetra drive. It functions as the orchestration hub where you as a builder assemble all the necessary specifications for your intended use-case, software solution or package. For each of the different **modules** that together form a package a  
-- **Vetra Package Library**: Store, publish and fork git repositories of packages in the Vetra Package Library.    
-Visit the [Vetra Package Library here](https://vetra.io/packages) 
+**Vetra Studio Drive**: Serves as a hub for developers to access, manage & share specification through a remote Vetra drive.   
+**Vetra Package Library**: Store, publish and fork git repositories of packages in the Vetra Package Library.    
+Visit the [Vetra Package Library here](https://vetra.io/packages)
+
+**Vetra Studio Drive** functions as the orchestration hub where you as a builder assemble all the necessary specifications for your intended use-case, software solution or package. For each of the different **modules** that together form a package a **specification document** can be created in Vetra Studio Drive. 
 
 As Vetra Studio matures each of these specification documents will offer an interface by which you as a builder get more control over the modules that make up your package. 
-For now the specification documents offer you a template for code generation. 
+For now they offer you a template for code generation. 
 
 <figure className="image-container">
   <img
@@ -64,28 +77,6 @@ You could then add the specific remote Vetra drive to your powerhouse configurat
 
 An example of a builder team building on the Powerhouse Vetra Ecosystem and it's complementary Vetra Studio Drive specifications for the different packages be found [here](https://vetra.io/builders/bai)
 
-<details>
-<summary>📦 Vetra Remote Drive Commands</summary>
-
-Remote drives enable collaborative development by syncing specifications across team members.
-
-**Key Commands:**
-- `ph init --remote-drive <url>` - Create a NEW project connected to a remote drive
-- `ph checkout --remote-drive <url>` - Clone an EXISTING project from a remote drive  
-- `ph vetra --watch` - Start development with a preview drive for testing local changes
-
-**Workflows:**
-- **Project Owner**: `ph init --remote-drive` → Create GitHub repo → Push → `ph vetra` to configure
-- **Collaborator**: `ph checkout --remote-drive` → `ph vetra` to start developing
-
-**Preview Drive (`--watch` mode):**
-- Main "Vetra" drive syncs with remote and contains stable package configuration
-- "Vetra Preview" drive is created locally for testing document models before syncing
-
-→ [Full Vetra Remote Drive Reference](/academy/APIReferences/VetraRemoteDrive)
-
-</details>
-
 ## Vetra Studio Workflow
 
 ### 1. Launch Vetra Studio
@@ -129,17 +120,6 @@ In standard mode:
 
 Vetra Studio integrates deeply with Claude through MCP (Model Control Protocol). This is where AI comes into the mix and you get the chance to have greater control and direction over what your llm is coding for you. 
 
-<details>
-<summary>**Specification Driven AI**</summary>
-
-In the **'Get Started'** chapter we've been making use of strict schema definition principles to communicate the intended use case of our reactive documents. 
-The **schema definition language**, is a not only a shared language that bridges the gap between developer, designer and analyst but also the gap between builder and AI-agent through **specification driven AI control**.
-
-- Communicate your solution and intent through a structured specification framework designed for AI collaboration.
-- Specifications enable precise, iterative edits, since all our specification documents are machine-readable and executable.
-
-</details>
-
 #### 1. Start the Reactor MCP:
 
 Make sure you are in the same directory as your project. 
@@ -166,35 +146,16 @@ Connected to MCP successfully! I can see there's a
   running and ready for document model operations.
 ```
 
-<details>
-<summary>🤖 Reactor MCP Overview</summary>
+-  To learn what is a [Reactor](apps/academy/docs/academy/Architecture/WorkingWithTheReactor) read the reactor article
+-  To learn more about the [Reactor MCP](apps/academy/docs/academy/GetStarted/ReactorMCP) read the reactor MCP article
 
 ### Key Reactor MCP Features
 
-**Reactor-mcp** is a Model Context Protocol (MCP) server that bridges AI agents with Powerhouse document operations.
-
 - It supports automatic document model creation from natural language descriptions
 - It implements a smart editor based on the underlying document models
 - It automatically triggers code generation when documents reach valid state
-- The MCP server enables the agent to work with both existing and newly created document models
-- Vetra supports integration with custom remote drives, allowing users to create, share and manage documents within these drives
-
-**Document Operations:**
-- `createDocument` / `getDocument` / `deleteDocument` - Manage documents
-- `addActions` - Modify document state through operations
-
-**Drive Operations:**
-- `getDrives` / `addDrive` / `getDrive` - Manage document drives
-- `addRemoteDrive` - Connect to remote drives
-
-**Document Model Operations:**
-- `getDocumentModels` - List available document model types
-- `getDocumentModelSchema` - Get schema for specific models
-
-**Document Model Agent:**
-A specialized AI agent that guides users through document model creation with requirements gathering, design confirmation, and implementation including state schema definition, operation creation, and code generation.
-
-</details>
+- The MCP server enables the agent to work with both existing and newly created document models.
+- Vetra supports integration with custom remote drives, allowing users to create, share and manage documents within these drives.
 
 
 ### 3. Vetra Studio Package Creation Workflow
@@ -250,4 +211,3 @@ Support for:
    - Verify implementation details in generated code before continuing. 
    - Always double-check proposed next actions
 
-

package/docs/academy/01-GetStarted/06-ReactorMCP.md

@@ -0,0 +1,58 @@
+# Tool: Reactor MCP
+
+**Reactor-mcp** is a Model Context Protocol (MCP) server for the Powerhouse ecosystem that provides AI agents and tools with structured access to document model operations. 
+It serves as a bridge between AI systems and the Powerhouse document management infrastructure.
+
+## Main Functions of the Reactor-mcp
+
+**Document Operations**:
+- createDocument - Create new documents
+- getDocument - Retrieve documents by ID
+- addActions - Add actions to modify document state
+- deleteDocument - Remove documents
+
+**Drive Operations**:
+- getDrives - List all document drives
+- addDrive - Create new drives
+- getDrive - Retrieve specific drives
+- addRemoteDrive - Connect to remote drives
+
+**Document Model Operations**:
+- getDocumentModels - List available document model types
+- getDocumentModelSchema - Get schema for specific document models
+
+<details>
+<summary>Architecture Context</summary>
+
+Within the broader Powerhouse ecosystem:
+
+- Document Model: Defines structure and operations for document types
+- Document Drive: Manages collections of documents with sync capabilities
+- Reactor-MCP: Provides AI/tool access to document operations
+- Connect/Switchboard: User interfaces and synchronization servers
+
+The reactor-mcp essentially makes the sophisticated document model system accessible to AI agents and external tools through a standardized protocol, enabling programmatic document creation, modification, and management within the Powerhouse ecosystem.
+
+</details>
+
+### Document Model Agent
+
+Alongside the MCP is a **specialized AI agent** for document model creation:
+
+- Purpose: Guide users through creating document models
+- Workflow: Requirements gathering → Design confirmation → Implementation
+- Tools: Comprehensive set of MCP tools for model management
+- Capabilities: 
+    - State schema definition
+    - Operation creation
+    - Module organization
+    - Code generation
+
+:::tip Supports with:
+
+1. **AI-Assisted Document Model Creation**: AI agents can use the MCP tools to help users create and modify document models
+2. **Automated Document Management**: Programmatic creation and management of documents and drives
+3. **Integration with AI Tools**: Claude, GPT, or other AI systems can use this as an MCP server to interact with Powerhouse
+4. **Development Tooling**: CLI and development server for working with document models locally
+:::
+

package/docs/academy/01-GetStarted/_04-BuildToDoListEditor

@@ -10,7 +10,7 @@ This command reads the **To-do List** document model definition from the `docume
 Notice the `--editor` flag which specifies the **To-do List** document model, and the `--document-types` flag defines the document type `powerhouse/todolist`.
 
 ```bash
-pnpm generate --editor Todo-List-editor --document-types powerhouse/todolist
+ph generate --editor ToDoList --document-types powerhouse/todolist
 ```
 
 Once complete, navigate to the `editors/to-do-list/editor.tsx` file and open it in your editor.

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

@@ -1,6 +1,6 @@
-# Vetra builder tooling
+# Powerhouse builder tooling
 
-This page provides an overview of all the builder tooling offered in the Vetra ecosystem by Powerhouse.  
+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

package/docs/academy/02-MasteryTrack/02-DocumentModelCreation/02-SpecifyTheStateSchema.md

@@ -1,19 +1,19 @@
 # Specify the state schema
 
-The state schema is the backbone of your document model. It defines the structure, data types, and relationships of the information your document will hold. In Powerhouse, we use the **GraphQL Schema Definition Language (SDL)** to define this schema. A well-defined state schema is crucial for ensuring data integrity, consistency, and for enabling powerful querying and manipulation capabilities.
+The state schema is the backbone of your document model. It defines the structure, data types, and relationships of the information your document will hold. In Powerhouse, we use the GraphQL Schema Definition Language (SDL) to define this schema. A well-defined state schema is crucial for ensuring data integrity, consistency, and for enabling powerful querying and manipulation capabilities.
 
 ## Core concepts
 
 ### Types
 
-At the heart of GraphQL SDL are **types**. Types define the shape of your data. You can define custom object types that represent the entities in your document. For example, in a `TodoList` document, you might have a `TodoListState` type and a `TodoItem` type.
+At the heart of GraphQL SDL are **types**. Types define the shape of your data. You can define custom object types that represent the entities in your document. For example, in a `ToDoList` document, you might have a `ToDoListState` type and a `ToDoItem` type.
 
-- **`TodoListState`**: This could be the root type representing the overall state of the to-do list. It might contain a list of `TodoItem` objects.
-- **`TodoItem`**: This type would represent an individual to-do item, with properties like an `id`, `text` (the task description), and `checked` (a boolean indicating if the task is completed).
+- **`ToDoListState`**: This could be the root type representing the overall state of the to-do list. It might contain a list of `ToDoItem` objects.
+- **`ToDoItem`**: This type would represent an individual to-do item, with properties like an `id`, `text` (the task description), and `checked` (a boolean indicating if the task is completed).
 
 ### Fields
 
-Each type has **fields**, which represent the properties of that type. Each field has a name and a type. For instance, the `TodoItem` type would have an `id` field of type `OID!`, a `text` field of type `String!`, and a `checked` field of type `Boolean!`.
+Each type has **fields**, which represent the properties of that type. Each field has a name and a type. For instance, the `ToDoItem` type would have an `id` field of type `ID!`, a `text` field of type `String!`, and a `checked` field of type `Boolean!`.
 
 ### Scalars
 
@@ -27,61 +27,32 @@ GraphQL has a set of built-in **scalar types**:
 
 In addition to these standard types, the Powerhouse Document-Engineering system introduces custom scalars that are linked to reusable front-end components. These scalars are tailored for the web3 ecosystem and will be explored in the Component Library section of the documentation.
 
-:::tip Custom Scalar: OID
-Powerhouse provides the `OID` (Object ID) scalar type, which is a custom scalar specifically designed for unique identifiers in document models. It provides automatic ID generation capabilities when used with the `generateId()` function from the document-model core library.
-:::
-
 ### Lists and non-null
 
 You can modify types using lists and non-null indicators:
 
-- **Lists**: To indicate that a field will return a list of a certain type, you wrap the type in square brackets, e.g., `[TodoItem!]!`. This means the field `items` in `TodoListState` will be a list of `TodoItem` objects.
-- **Non-Null**: To indicate that a field cannot be null, you add an exclamation mark `!` after the type name, e.g., `String!`. This means that the `text` field of a `TodoItem` must always have a value. The outer `!` in `[TodoItem!]!` means the list itself cannot be null (it must be at least an empty list), and the inner `!` on `TodoItem!` means that every item within that list must also be non-null.
-
-## Example: TodoList state schema
+- **Lists**: To indicate that a field will return a list of a certain type, you wrap the type in square brackets, e.g., `[ToDoItem!]!`. This means the field `items` in `ToDoListState` will be a list of `ToDoItem` objects.
+- **Non-Null**: To indicate that a field cannot be null, you add an exclamation mark `!` after the type name, e.g., `String!`. This means that the `text` field of a `ToDoItem` must always have a value. The outer `!` in `[ToDoItem!]!` means the list itself cannot be null (it must be at least an empty list), and the inner `!` on `ToDoItem!` means that every item within that list must also be non-null.
 
-Let's revisit the `TodoList` example from the "Define the TodoList document specification" tutorial in Get Started.
+## Example: ToDoList state schema
 
-### Basic schema (matching Get Started tutorial)
-
-This is the same schema you built in the Get Started tutorial:
+Let's revisit the `ToDoList` example from the "Define the ToDoList document specification" tutorial.
+Only this time, we'll also add a 'Stats' type. Since we want to keep track of the number of completed To-Do's.
 
 ```graphql
-# The state of our TodoList
-type TodoListState {
-  items: [TodoItem!]!
+# The state of our ToDoList
+type ToDoListState {
+  items: [ToDoItem!]!
 }
 
 # A single to-do item
-type TodoItem {
-  id: OID!
+type ToDoItem {
+  id: ID!
   text: String!
   checked: Boolean!
 }
-```
-
-### Advanced schema (with statistics tracking)
-
-:::info Advanced Feature
-In this Mastery Track, we'll extend the basic schema with a `stats` field to demonstrate how you can add computed statistics to your document model. This is an **optional enhancement** that builds on the foundation from Get Started.
-:::
-
-```graphql
-# The state of our TodoList (advanced version with stats)
-type TodoListState {
-  items: [TodoItem!]!
-  stats: TodoListStats!
-}
-
-# A single to-do item
-type TodoItem {
-  id: OID!
-  text: String!
-  checked: Boolean!
-}
-
-# The statistics on our to-do's (advanced feature)
-type TodoListStats {
+# The statistics on our to-do's
+type ToDoListStats {
   total: Int!
   checked: Int!
   unchecked: Int!
@@ -90,19 +61,18 @@ type TodoListStats {
 
 ### Breakdown:
 
-- **`TodoListState` type**:
-  - `items: [TodoItem!]!`: This field defines that our `TodoListState` contains a list called `items`.
-    - `[TodoItem!]`: This signifies that `items` is a list of `TodoItem` objects.
-    - `TodoItem!`: The `!` after `TodoItem` means that no item in the list can be null. Each entry must be a valid `TodoItem`.
-    - The final `!` after `[TodoItem!]` means that the `items` list itself cannot be null. It can be an empty list `[]`, but it cannot be absent.
-  - `stats: TodoListStats!` *(advanced)*: Holds aggregated statistics about the to-do items.
+- **`ToDoListState` type**:
+  - `items: [ToDoItem!]!`: This field defines that our `ToDoListState` contains a list called `items`.
+    - `[ToDoItem!]`: This signifies that `items` is a list of `ToDoItem` objects.
+    - `ToDoItem!`: The `!` after `ToDoItem` means that no item in the list can be null. Each entry must be a valid `ToDoItem`.
+    - The final `!` after `[ToDoItem!]` means that the `items` list itself cannot be null. It can be an empty list `[]`, but it cannot be absent.
 
-- **`TodoItem` type**:
-  - `id: OID!`: Each `TodoItem` has a unique identifier using Powerhouse's custom `OID` scalar. This is crucial for referencing specific items, for example, when updating or deleting them.
+- **`ToDoItem` type**:
+  - `id: ID!`: Each `ToDoItem` has a unique identifier that cannot be null. This is crucial for referencing specific items, for example, when updating or deleting them.
   - `text: String!`: The textual description of the to-do item. It cannot be null, ensuring every to-do has a description.
   - `checked: Boolean!`: Indicates whether the to-do item is completed. It defaults to a boolean value (true or false) and cannot be null.
 
-- **`TodoListStats` type** *(advanced)*: This type holds the summary statistics for the to-do list.
+- **`ToDoListStats` type**: This type holds the summary statistics for the to-do list.
   - `total: Int!`: The total count of all to-do items. This field must be an integer and cannot be null.
   - `checked: Int!`: The number of to-do items that are marked as completed. This must be an integer and cannot be null.
   - `unchecked: Int!`: The number of to-do items that are still pending. This also must be an integer and cannot be null.
@@ -113,17 +83,17 @@ type TodoListStats {
 2.  **Clarity and Explicitness**: Name your types and fields clearly and descriptively. This makes the schema easier to understand and maintain.
 3.  **Use Non-Null Wisely**: Enforce data integrity by using non-null (`!`) for fields that must always have a value. However, be mindful not to over-constrain if a field can genuinely be optional.
 4.  **Normalize vs. Denormalize**:
-    - **Normalization**: Similar to relational databases, you can normalize your data by having distinct types and linking them via IDs. This can reduce data redundancy. For example, if you had `User` and `TodoItem` and wanted to assign tasks, you might have an `assigneeId` field in `TodoItem` that links to a `User`'s `id`.
-    - **Denormalization**: Sometimes, for performance or simplicity, you might embed data directly. For instance, if user information associated with a to-do item was very simple and only used in that context, you might embed user fields directly in `TodoItem`.
+    - **Normalization**: Similar to relational databases, you can normalize your data by having distinct types and linking them via IDs. This can reduce data redundancy. For example, if you had `User` and `ToDoItem` and wanted to assign tasks, you might have an `assigneeId` field in `ToDoItem` that links to a `User`'s `id`.
+    - **Denormalization**: Sometimes, for performance or simplicity, you might embed data directly. For instance, if user information associated with a to-do item was very simple and only used in that context, you might embed user fields directly in `ToDoItem`.
     - The choice depends on your specific use case, query patterns, and how data is updated.
-5.  **Consider Future Needs**: While you shouldn't over-engineer, think a little about potential future enhancements. For example, adding a `createdAt: String` or `dueDate: String` field to `TodoItem` might be useful later.
-6.  **Root State Type**: It's a common pattern to have a single root type for your document state (e.g., `TodoListState`). This provides a clear entry point for accessing all document data.
+5.  **Consider Future Needs**: While you shouldn't over-engineer, think a little about potential future enhancements. For example, adding a `createdAt: String` or `dueDate: String` field to `ToDoItem` might be useful later.
+6.  **Root State Type**: It's a common pattern to have a single root type for your document state (e.g., `ToDoListState`). This provides a clear entry point for accessing all document data.
 
 By carefully defining your state schema, you lay a solid foundation for your Powerhouse document model, making it robust, maintainable, and easy to work with. The schema dictates not only how data is stored but also how it can be queried and mutated through operations, which will be covered in the next section.
 
 ## Practical implementation: defining the state schema in Connect
 
-Now that you understand the concepts behind the state schema, let's put it into practice. This section will guide you through creating a document model specification for the TodoList example discussed above.
+Now that you understand the concepts behind the state schema, let's put it into practice. This section will guide you through creating a document model specification for the advanced ToDoList example discussed above.
 
 <details>
 <summary>Tutorial: The state schema specification</summary>
@@ -140,29 +110,28 @@ Now that you understand the concepts behind the state schema, let's put it into
     - At the bottom of the page in the 'New Document' section, click the `DocumentModel` button to create a new document model specification.
 
 2.  **Define Document Metadata**:
-    - **Name**: Give your document model a descriptive name: `TodoList`. **Pay close attention to capitalization, as it influences our code generation.**
-    - **Document Type**: In the 'Document Type' field, enter a unique identifier for this document type: `powerhouse/todo-list`.
+    - **Name**: Give your document model a descriptive name, for example, `ToDoList`. **Pay close attention to capitalization, as it influences our code.**
+    - **Document Type**: In the 'Document Type' field, enter a unique identifier for this document type: `powerhouse/todolist`.
 
 3.  **Specify the State Schema**:
     - In the code editor provided, you'll see a template for a GraphQL schema.
-    - Replace the entire content of the editor with the advanced `TodoList` schema we've designed in this chapter:
+    - Replace the entire content of the editor with the advanced `ToDoList` schema we've designed in this chapter:
 
     ```graphql
-    # The state of our TodoList (advanced version with stats)
-    type TodoListState {
-      items: [TodoItem!]!
-      stats: TodoListStats!
+    # The state of our ToDoList
+    type ToDoListState {
+      items: [ToDoItem!]!
+      stats: ToDoListStats!
     }
 
     # A single to-do item
-    type TodoItem {
-      id: OID!
+    type ToDoItem {
+      id: ID!
       text: String!
       checked: Boolean!
     }
-    
-    # The statistics on our to-do's (advanced feature)
-    type TodoListStats {
+    # The statistics on our to-do's
+    type ToDoListStats {
       total: Int!
       checked: Int!
       unchecked: Int!
@@ -171,12 +140,12 @@ Now that you understand the concepts behind the state schema, let's put it into
 
 4.  **Sync Schema and View Initial State**:
     - After pasting the schema, click the **'Sync with schema'** button.
-    - This action processes your schema and generates an initial JSON state for your document model based on the `TodoListState` type. You can view this initial state, which helps you verify that your schema is structured correctly.
+    - This action processes your schema and generates an initial JSON state for your document model based on the `ToDoListState` type. You can view this initial state, which helps you verify that your schema is structured correctly.
 
     For now, you can ignore the "Modules & Operations" section. We will define and implement the operations that modify this state in the upcoming sections of this Mastery Track.
 
-By completing these steps, you have successfully specified the data structure for the advanced TodoList document model. The next step is to define the operations that will allow users to interact with and change this state.
+By completing these steps, you have successfully specified the data structure for the advanced ToDoList document model. The next step is to define the operations that will allow users to interact with and change this state.
 
 </details>
 
-For a complete, working example, you can always have a look at the [Example TodoList Repository](/academy/MasteryTrack/DocumentModelCreation/ExampleToDoListRepository) which contains the full implementation of the concepts discussed in this Mastery Track.
+For a complete, working example, you can always have a look at the [Example ToDoList Repository](/academy/MasteryTrack/DocumentModelCreation/ExampleToDoListRepository) which contains the full implementation of the concepts discussed in this Mastery Track.