@powerhousedao/academy 5.0.0-staging.8 → 5.0.1-staging.2

package/docs/academy/02-MasteryTrack/03-BuildingUserExperiences/06-DocumentTools/00-DocumentToolbar.mdx

@@ -3,8 +3,13 @@
 The Document Toolbar is a central component in Powerhouse Connect, appearing at the top of every document view. It provides quick access to a variety of tools and functions designed to streamline your workflow and enhance document management.
 
 <figure className="image-container">
-  <img src={require("./images/DocumentToolbar.png").default} alt="Document Toolbar" />
-  <figcaption>The Document Toolbar can be found at the top of any generic document.</figcaption>
+  <img
+    src={require("./images/DocumentToolbar.png").default}
+    alt="Document Toolbar"
+  />
+  <figcaption>
+    The Document Toolbar can be found at the top of any generic document.
+  </figcaption>
 </figure>
 
 ## Overview
@@ -12,14 +17,15 @@ The Document Toolbar is a central component in Powerhouse Connect, appearing at
 The toolbar is designed to be intuitive and context-aware, offering relevant options based on the document type and your current task. Its capabilities range from basic actions to more advanced document control features.
 
 ### Key functionalities in the future will include:
-*   **Switchboard API Access:** Access the Switchboard API via its logo in the toolbar. This opens the Apollo Studio Sandbox, pre-populating the DocumentID for your current document model. This feature is unavailable for locally stored documents.
-*   **Navigation and Versioning:** Tools for managing [document versions](/academy/MasteryTrack/BuildingUserExperiences/DocumentTools/OperationHistory), such as undo/redo, and accessing the [revision history timeline](/academy/MasteryTrack/BuildingUserExperiences/DocumentTools/RevisionHistoryTimeline).
-*   **Document Actions:** Buttons for common operations like exporting or deleting documents.
-*   **Information Display:** Shows the document title and may include indicators for status (e.g., connectivity, errors) or active modes.
-*   **Search and Filtering:** Integrated search capabilities to find assets or attachments within the document context.
-*   **View Customization:** Options to switch between different views or display modes.
-*   **Contextual Tools:** Depending on the document, you might find toggles, dropdowns for specific actions (e.g., "Sync Schema", "Fixed Income Purchase"), or buttons for settings and configurations.
+
+- **Switchboard API Access:** Access the Switchboard API via its logo in the toolbar. This opens the Apollo Studio Sandbox, pre-populating the DocumentID for your current document model. This feature is unavailable for locally stored documents.
+- **Navigation and Versioning:** Tools for managing [document versions](/academy/MasteryTrack/BuildingUserExperiences/DocumentTools/OperationHistory), such as undo/redo, and accessing the [revision history timeline](/academy/MasteryTrack/BuildingUserExperiences/DocumentTools/RevisionHistoryTimeline).
+- **Document Actions:** Buttons for common operations like exporting or deleting documents.
+- **Information Display:** Shows the document title and may include indicators for status (e.g., connectivity, errors) or active modes.
+- **Search and Filtering:** Integrated search capabilities to find assets or attachments within the document context.
+- **View Customization:** Options to switch between different views or display modes.
+- **Contextual Tools:** Depending on the document, you might find toggles, dropdowns for specific actions (e.g., "Sync Schema", "Fixed Income Purchase"), or buttons for settings and configurations.
 
 The specific set of tools available on the toolbar can be configured and may evolve as new features are introduced. This section will detail the various components and options you may encounter.
 
-*(Detailed information on each toolbar feature, such as "Export Button", "Title Display", "Search Functionality", "Toggle Switches", "Icon Buttons", etc., will follow here.)*
+_(Detailed information on each toolbar feature, such as "Export Button", "Title Display", "Search Functionality", "Toggle Switches", "Icon Buttons", etc., will follow here.)_

package/docs/academy/02-MasteryTrack/03-BuildingUserExperiences/06-DocumentTools/01-OperationHistory.md

@@ -1,12 +1,14 @@
 # Operations history
 
 ## What is a document model?
+
 A **document model** in Powerhouse is the core unit for managing business data. Each document (such as an invoice, contributor agreement, or scope of work) is created from a specific document model, which defines:
 
 - **State schema:** What data the document contains
 - **Operations:** What actions can modify that document
 
 ## What is an operations history?
+
 Every time a user edits a document, they do so by submitting a document operation or a 'command' in CQRS (e.g., `ADD_LINE_ITEM`, `UPDATE_RECIPIENT`). These operations are:
 
 - **Appended** to the document's history
@@ -16,13 +18,14 @@ Every time a user edits a document, they do so by submitting a document operatio
 This design is based on **event sourcing** principles.
 
 ## Why use an operations history?
+
 - **Auditability:** Inspect every change ever made to a document.
 - **Transparency:** Contributors see what others have done.
 - **Versioning:** Revert to any prior state or resolve conflicts using branching and merging.
 - **Interoperability:** Operations are just data—they can be signed, stored on-chain, or synchronized across systems.
 
-
 ## Example: Invoice document
+
 Suppose you're editing a `powerhouse/invoice` document. Its operations history might look like this:
 
 ```plaintext
@@ -36,32 +39,32 @@ The document's state at any time is the result of running those operations in or
 ## Visualizing the operations history
 
 ### Revision list and details
+
 In Connect the Powerhouse UI displays a chronologic list of all applied modifications to the document, each with a unique event ID, state hash, and commit message. You can inspect each revision for signatures and errors.
 
 ![Revision History List](./images/revision-history-list.png)
 
-
 ### Viewing revision hashes and event IDs
+
 Hovering over a revision reveals its event ID and state hash, providing traceability for every change.
 
 ![Revision Hash Popup](./images/revision-hash-popup.png)
 
-
 ### Signature verification
+
 Clicking the signature badge shows signature details, including signer address, hash, and verification status. This ensures every operation is cryptographically auditable.
-Read more about how we are using [Renown](/academy/MasteryTrack/BuildingUserExperiences/Authorization/RenownAuthenticationFlow) for authentication & verification of signer data. 
+Read more about how we are using [Renown](/academy/MasteryTrack/BuildingUserExperiences/Authorization/RenownAuthenticationFlow) for authentication & verification of signer data.
 
 ![Signature Details Popup](./images/signature-details-popup.png)
 
-
 ### Viewing committer addresses
+
 You can also view the committer's address for each revision, supporting full transparency and accountability.
 
 ![Committer Address Popup](./images/committer-address-popup.png)
 
-
 ## Replay, branch, and merge (under development)
+
 - **Replay:** When you load a document, the system replays all operations to build its state.
 - **Branch:** Create a parallel version of the document to test changes or handle conflicts.
 - **Merge:** Combine branches intelligently based on operations, not just raw field values.
-

package/docs/academy/02-MasteryTrack/03-BuildingUserExperiences/06-DocumentTools/02-RevisionHistoryTimeline.md

@@ -9,23 +9,18 @@ To enable the timeline feature in your document editor, you need to set `timelin
 ```typescript
 // editors/to-do-list/index.ts
 export const module: EditorModule<ToDoDocument> = {
-  Component: Editor as unknown as FC<EditorProps<ToDoDocument> & Record<string, unknown>>,
+  Component: Editor as unknown as FC<
+    EditorProps<ToDoDocument> & Record<string, unknown>
+  >,
   documentTypes: ["powerhouse/todo"],
-  config: {
-    id: "editor-id",
-    disableExternalControls: true,
-    documentToolbarEnabled: true,
-    showSwitchboardLink: true,
-    timelineEnabled: true,  // Enable timeline feature
-  },
 };
 ```
 
 This setting enables the timeline button in the document toolbar.
 
-:::warning Heads Up! 
-The revision history timeline will only become visible once your document model has some operations or 'history'. 
-Add a few to-do's or some data in the model you are working on and the revision history timeline button in the Document Toolbar will be activated. 
+:::warning Heads Up!
+The revision history timeline will only become visible once your document model has some operations or 'history'.
+Add a few to-do's or some data in the model you are working on and the revision history timeline button in the Document Toolbar will be activated.
 Click the button to see the timeline expand and see the first history 'candle' appear.
 :::
 
@@ -64,7 +59,8 @@ const timelineItems = useTimelineItems(documentId);
 3. Track the selected timeline item in state:
 
 ```typescript
-const [selectedTimelineItem, setSelectedTimelineItem] = useState<TimelineItem | null>(null);
+const [selectedTimelineItem, setSelectedTimelineItem] =
+  useState<TimelineItem | null>(null);
 ```
 
 4. Pass the timeline items to the DocumentToolbar and handle item selection:
@@ -104,18 +100,30 @@ In your document editor (e.g., `editors/to-do-list/editor.tsx`), you need to han
 1. Extract timeline-related properties from the context:
 
 ```typescript
-const { readMode = false, selectedTimelineRevision, getDocumentRevision } = context;
+const {
+  readMode = false,
+  selectedTimelineRevision,
+  getDocumentRevision,
+} = context;
 ```
 
 2. Fetch the document at the selected revision when in read mode:
 
 ```typescript
-const [readModeDocument, setReadModeDocument] = useState<ToDoDocument | null>(null);
+const [readModeDocument, setReadModeDocument] = useState<ToDoDocument | null>(
+  null,
+);
 
 useEffect(() => {
   const getReadModeDocument = async () => {
-    if (getDocumentRevision && readMode && typeof selectedTimelineRevision === 'number') {
-      const document = await getDocumentRevision({ revisions: { global: selectedTimelineRevision } });
+    if (
+      getDocumentRevision &&
+      readMode &&
+      typeof selectedTimelineRevision === "number"
+    ) {
+      const document = await getDocumentRevision({
+        revisions: { global: selectedTimelineRevision },
+      });
       setReadModeDocument(document);
     } else if (!readMode) {
       setReadModeDocument(null);
@@ -140,4 +148,4 @@ const document = readModeDocument || writeModeDocument;
 )}
 ```
 
-This implementation allows users to navigate through document history while preventing edits to historical revisions.
+This implementation allows users to navigate through document history while preventing edits to historical revisions.

package/docs/academy/02-MasteryTrack/03-BuildingUserExperiences/06-DocumentTools/_category_.json

@@ -1,7 +1,7 @@
 {
-    "label": "Document Tools",
-    "link": {
-      "type": "generated-index",
-      "description": "All of the tools that you get for free with Powerhouse."
-    }
-  }
+  "label": "Document Tools",
+  "link": {
+    "type": "generated-index",
+    "description": "All of the tools that you get for free with Powerhouse."
+  }
+}

package/docs/academy/02-MasteryTrack/03-BuildingUserExperiences/07-Authorization/01-RenownAuthenticationFlow.md

@@ -3,43 +3,48 @@
 The Renown login flow leverages decentralized identity (DID) creation and the Ceramic network for credential storage and verification, ensuring secure and verifiable actions within decentralized organizations. Below is a detailed breakdown of the process, aimed at developers integrating the Renown, Connect, and Switchboard components.
 
 ### Renown in the decentralized workplace
+
 Renown provides a decentralized identity and reputation hub, where users connect their Ethereum address, creating a **Decentralized Identifier (DID)** tied to their wallet.
 
 #### Why an integrated identity solution?
+
 Renown is designed to address the challenge of trust within DAOs, where contributors often operate under pseudonyms. In traditional organizations, personal identity and reputation are key to establishing trust and accountability. Renown replicates this dynamic in the digital space, allowing contributors to earn experience and build reputation without revealing their real-world identities. Over time, contributors can share their pseudonymous profiles with other organizations as cryptographic resumes, helping to secure new opportunities while maintaining privacy.
 
 ### Detailed login flow
 
 #### 1. User login via wallet connection
+
 - The user starts by logging into Renown using their Ethereum address. This is done by signing a message with their wallet.
 - The Ethereum key is used to create a DID (Decentralized Identifier), which uniquely represents the user without exposing their personal identity.
 
-
 <figure className="image-container">
   <img src={require("./images/ConnectAddress.png").default} alt="Connect Address" />
   <figcaption>Connecting your Ethereum address to generate Decentralized Identifier with Renown.</figcaption>
 </figure>
 
 #### 2. DID creation
+
 - A Decentralized Identifier (DID) is created based on the user's Ethereum key. The DID follows a specific format:  
   `did:example:123456789abcdefghijk`
 - This DID acts as the user's digital identifier across decentralized systems.
 
 #### 3. Credential generation
+
 - A credential is generated, allowing the DID to sign operations on behalf of the user. This credential is stored on Ceramic, a decentralized data stream network.
 - Ceramic ensures that the credentials are securely stored and verifiable across the network. Credentials include the user's signing permissions and are linked to the DID.
 
 #### 4. Operation signing with Connect
+
 - Connect uses the newly created DID to sign operations performed by the user. For example, when a document or transaction is edited in Connect, the operation is signed with the user's DID.
 - This ensures that every action taken within the Connect system is linked to the user's decentralized identity, maintaining transparency and accountability.
 
-
 <figure className="image-container">
   <img src={require("./images/OperationsHistory.png").default} alt="Renown Login" />
   <figcaption>Your DID is used to sign operations performed by the user.</figcaption>
 </figure>
 
 #### 5. Switchboard verification
+
 - Once an operation is signed by the DID through Connect, it is sent to Switchboard for verification.
 - Switchboard verifies whether the DID has a valid credential stored on Ceramic and if the DID was indeed the one that signed the operation.
 - The request includes critical metadata such as the user's Ethereum address, the DID, the signed operation, and other parameters required for validation.
@@ -50,11 +55,12 @@ Renown is designed to address the challenge of trust within DAOs, where contribu
     "hash": "did:key:2be4x...",
     "signatureBytes": "Xmqy8FNz...",
     "isVerified": true
-  } 
+  }
   ```
 
 #### 6. Operation validation and execution
-- After Switchboard validates the operation, it ensures the operation context is accurate and the credentials match the signer. 
+
+- After Switchboard validates the operation, it ensures the operation context is accurate and the credentials match the signer.
 - The operation is then either approved or rejected based on the verification results.
 - Approved operations are processed, and changes made within the Connect system are synchronized across the relevant nodes.
 
@@ -63,10 +69,11 @@ Renown is designed to address the challenge of trust within DAOs, where contribu
 
 :::info
 **Key Components used during login-flow**
+
 - **Renown**: Manages user identities via DID creation and Ethereum wallet integration.
-- **Ceramic**: Decentralized data stream where user credentials are stored and verified. 
+- **Ceramic**: Decentralized data stream where user credentials are stored and verified.
 - **Connect**: The interface for users to perform operations. It uses the DID for signing operations.
 - **Switchboard**: Responsible for verifying credentials and operation signatures to ensure authenticity.
-:::
+  :::
 
-This flow ensures that all actions within the Powerhouse ecosystem are secure, transparent, and verifiable, promoting trust in a pseudonymous contributor environment.
+This flow ensures that all actions within the Powerhouse ecosystem are secure, transparent, and verifiable, promoting trust in a pseudonymous contributor environment.

package/docs/academy/02-MasteryTrack/03-BuildingUserExperiences/07-Authorization/02-Authorization.md

@@ -86,7 +86,6 @@ docker run -e AUTH_ENABLED=true \
 3. Review and update role assignments regularly
 4. Consider using AUTH_ENABLED=false only in development
 
-
 ## Troubleshooting
 
 If you encounter authorization issues:

package/docs/academy/02-MasteryTrack/03-BuildingUserExperiences/07-Authorization/_category_.json

@@ -1,6 +1,6 @@
 {
-    "label": "Authorization",
-    "link": {
-      "type": "generated-index"
-    }
-  }
+  "label": "Authorization",
+  "link": {
+    "type": "generated-index"
+  }
+}

package/docs/academy/02-MasteryTrack/03-BuildingUserExperiences/_category_.json

@@ -4,4 +4,4 @@
     "type": "doc",
     "id": "academy/MasteryTrack/BuildingUserExperiences/BuildingDocumentEditors"
   }
-}
+}

package/docs/academy/02-MasteryTrack/04-WorkWithData/01-GraphQLAtPowerhouse.md

@@ -3,6 +3,7 @@
 In this section, we will cover **the core concepts of GraphQL with examples applied to the Powerhouse ecosystem**. GraphQL plays a fundamental role in defining document model data schemas, handling data access patterns, and enabling event-driven workflows within the Powerhouse ecosystem.
 
 More specifically, GraphQL is used as:
+
 - The **schema definition language (SDL)** for defining our document models and thereby self-documenting the API to the data model. It allows developers to define the structure and relationships of data in a strongly-typed format.
 - As the **query language in subgraphs**, which allow different services to expose and query structured data dynamically.
 
@@ -15,21 +16,22 @@ More specifically, GraphQL is used as:
 ## GraphQL: Core concepts
 
 ### Schema
+
 The schema defines the structure of a GraphQL API. It acts as a contract between the client and server, detailing:
 
-- **Data Types**: The various types of data that can be queried.   
-For example the contributor type and the project type
-- **Fields**: The available fields on each type.   
-For example the contributor type has a field 'name' and the project type has a field 'title'
-- **Relationships**: How different types relate to each other.   
-For example the contributor type has a relationship with the project type
+- **Data Types**: The various types of data that can be queried.  
+  For example the contributor type and the project type
+- **Fields**: The available fields on each type.  
+  For example the contributor type has a field 'name' and the project type has a field 'title'
+- **Relationships**: How different types relate to each other.  
+  For example the contributor type has a relationship with the project type
 
   ```graphql title="Example of a Powerhouse Contributor schema in GraphQL"
   type Contributor {
     id: ID!
     name: String!
     reputationScore: Float
-    projects: [Project]   # The Contributor type has a field 'projects' that returns an array of Project objects
+    projects: [Project] # The Contributor type has a field 'projects' that returns an array of Project objects
   }
 
   type Project {
@@ -46,22 +48,23 @@ For example the contributor type has a relationship with the project type
 
   With the following query someone can request the contributor with the id 123
 
-    ```graphql title="Example of a query to get a contributor"
-    query {
-      getContributor(id: "123") {
-        name
-        reputationScore
-        projects {      # Accessing the related projects
-          title
-          status
+      ```graphql title="Example of a query to get a contributor"
+      query {
+        getContributor(id: "123") {
+          name
+          reputationScore
+          projects {      # Accessing the related projects
+            title
+            status
+          }
         }
       }
-    }
-    ```
+      ```
 
 ---
 
 ### Fields and arguments
+
 - **Field**: A specific piece of data you can request from an object. When you build a query, you select the fields you want to retrieve.
 - **Argument**: Key-value pairs that can be attached to fields to customize and refine the query. Some fields require arguments to work correctly, especially when dealing with mutations.
 
@@ -78,9 +81,11 @@ For example the contributor type has a relationship with the project type
     }
   }
   ```
-___
+
+---
 
 ### Introspection
+
 GraphQL APIs are self-documenting. Through introspection, you can query the API to retrieve details about its schema, including:
 
 - The list of **available types and fields**.
@@ -102,7 +107,9 @@ GraphQL APIs are self-documenting. Through introspection, you can query the API
   ```
 
 ---
+
 ### Connections, edges, and nodes
+
 When dealing with lists of data, GraphQL employs a pattern that includes:
 
 - **Connection**: A structure that represents a list of related objects.
@@ -136,21 +143,24 @@ When dealing with lists of data, GraphQL employs a pattern that includes:
 ---
 
 ### Mutations
+
 - While queries retrieve data, **mutations modify data**. In Powerhouse, a contributor might need to submit an invoice after completing a task. A GraphQL mutation for this could be:
 
-    ```graphql title="Submitting an Invoice"
-    mutation {
-      submitInvoice(input: {
+  ```graphql title="Submitting an Invoice"
+  mutation {
+    submitInvoice(
+      input: {
         contributorId: "123"
         amount: 500.00
         currency: "USD"
         dueDate: "2024-03-01"
-      }) {
-        id
-        status
       }
+    ) {
+      id
+      status
     }
-    ```
+  }
+  ```
 
 ---
 
@@ -192,14 +202,15 @@ Powerhouse uses **CQRS (Command Query Responsibility Segregation)** to separate
 
 Powerhouse's subgraphs act as the read layer, while processors handle write operations into operational data stores. This prevents conflicts between querying and modifying data.
 
-| Layer | Role | GraphQL Usage | Implementation |
-| --- | --- | --- | --- |
-| Write Model (Commands) | Handles state changes (adding, modifying, deleting) | GraphQL Mutations | Processor |
-| Read Model (Queries) | Optimized for fetching/reading/retrieving data | GraphQL Queries | Subgraph |
+| Layer                  | Role                                                | GraphQL Usage     | Implementation |
+| ---------------------- | --------------------------------------------------- | ----------------- | -------------- |
+| Write Model (Commands) | Handles state changes (adding, modifying, deleting) | GraphQL Mutations | Processor      |
+| Read Model (Queries)   | Optimized for fetching/reading/retrieving data      | GraphQL Queries   | Subgraph       |
 
-### Read and write separation  
+### Read and write separation
+
+**Read Model (Query)**
 
-**Read Model (Query)**  
 - Optimized for data retrieval
 - Structured using GraphQL Queries
 - Aggregates and exposes data via a subgraph
@@ -216,7 +227,8 @@ query {
 }
 ```
 
-**Write Model (Mutation)** 
+**Write Model (Mutation)**
+
 - Handles state changes (adding, modifying, deleting)
 - Structured using GraphQL Mutations
 - Writes data to Operational Data Stores
@@ -281,4 +293,4 @@ GraphQL offers a streamlined and efficient approach to data retrieval, particula
 
 By defining robust schemas, using precise fields and arguments, leveraging introspection, and implementing subgraphs with CQRS principles, GraphQL minimizes unnecessary data transfers while maximizing flexibility and scalability in the Powerhouse platform.
 
-For more information about GraphQL fundamentals, visit the [Introduction to GraphQL](https://graphql.org/learn/) documentation.
+For more information about GraphQL fundamentals, visit the [Introduction to GraphQL](https://graphql.org/learn/) documentation.

package/docs/academy/02-MasteryTrack/04-WorkWithData/02-UsingTheAPI.mdx

@@ -18,7 +18,7 @@ In this tutorial, we'll show how to use a **GraphQL** query to query a document
 To make our document model available in the Apollo Studio Sandbox, we'll need to store it on a remote [Reactor](/academy/Architecture/WorkingWithTheReactor).
 
 :::info What are reactors?
-**Powerhouse Reactors** are the nodes in the network that store documents, resolve conflicts, and rerun operations to verify document event histories. 
+**Powerhouse Reactors** are the nodes in the network that store documents, resolve conflicts, and rerun operations to verify document event histories.
 Reactors can be configured for local storage, centralized cloud storage, or a decentralized storage network.
 :::
 
@@ -29,11 +29,13 @@ ph reactor
 ```
 
 To start both Connect and a Reactor locally at the same time in a Powerhouse project, you can use the following command:
+
 ```bash
 ph dev
 ```
 
 This will return a URL to access the Reactor.
+
 ```bash
 [Reactor]:   ➜  Reactor:   http://localhost:4001/d/powerhouse
 ```
@@ -46,8 +48,13 @@ Get access to an **organization's drive** instances by adding their drive to you
 Click the (+) 'Create New Drive' to add a public drive. To add a new drive, you'll have to know the correct public URL of the drive. Read more about [configuring drives](/academy/Architecture/WorkingWithTheReactor).
 
 <figure className="image-container">
-  <img src={require("./images/AddNewDriveURL.png").default} alt="Add a drive through an URL" />
-  <figcaption>The 'Add Drive' button that allows you to enter a Drive URL.</figcaption>
+  <img
+    src={require("./images/AddNewDriveURL.png").default}
+    alt="Add a drive through an URL"
+  />
+  <figcaption>
+    The 'Add Drive' button that allows you to enter a Drive URL.
+  </figcaption>
 </figure>
 
 ## Query the state of a document
@@ -55,10 +62,10 @@ Click the (+) 'Create New Drive' to add a public drive. To add a new drive, you'
 Now that we have our remote reactor and/or drive running, we can store our document model on it.
 Let's quickly create a new to-do list document in Connect Studio to test the process. Let's call it **'Powerhouse-onboarding-tasks'**.
 
-
 Add the following to-dos to your list:
+
 - [ ] Sign up for Powerhouse
-- [ ] Do the work 
+- [ ] Do the work
 - [ ] Deliver the work
 - [ ] Send the invoice
 - [ ] Get paid
@@ -66,8 +73,13 @@ Add the following to-dos to your list:
 Below is the operation history of the to-do list document. As you can see, the operations are logged in the order they were executed.
 
 <figure className="image-container">
-  <img src={require("./images/OnboardingTasks.png").default} alt="Operation history in Connect" />
-  <figcaption>The operation history of the to-do list document, showing each change made.</figcaption>
+  <img
+    src={require("./images/OnboardingTasks.png").default}
+    alt="Operation history in Connect"
+  />
+  <figcaption>
+    The operation history of the to-do list document, showing each change made.
+  </figcaption>
 </figure>
 
 Now that we have some data in our document model, we can query it through the GraphQL API.
@@ -79,8 +91,14 @@ The Switchboard API button at the top of your document model will get you the co
 This will prepopulate the Apollo Studio Sandbox with the correct **DocumentID** for your document model.
 
 <figure className="image-container">
-  <img src={require("./images/SwitchboardButton.png").default} alt="Switchboard button in document editor" />
-  <figcaption>The Switchboard button provides a direct link to the GraphQL API for the document.</figcaption>
+  <img
+    src={require("./images/SwitchboardButton.png").default}
+    alt="Switchboard button in document editor"
+  />
+  <figcaption>
+    The Switchboard button provides a direct link to the GraphQL API for the
+    document.
+  </figcaption>
 </figure>
 
 ### Option 2: Query your document by document ID
@@ -89,16 +107,27 @@ In your Document Toolbar, you will find an icon to visit your operations history
 Copy this ID to use it in the Switchboard API.
 
 <figure className="image-container">
-  <img src={require("./images/DocumentID.png").default} alt="Copy the DocumentID" />
-  <figcaption>You can copy your Document ID from your operations history.</figcaption>
+  <img
+    src={require("./images/DocumentID.png").default}
+    alt="Copy the DocumentID"
+  />
+  <figcaption>
+    You can copy your Document ID from your operations history.
+  </figcaption>
 </figure>
 
 When you navigate to your Switchboard endpoint by adding **`/graphql/system`** to the end of your URL. (e.g., http://localhost:4001/graphql/system, https://switchboard.phd/graphql/system, or add it to a custom domain), you can use this document ID to query the state of your document.
 The documentation on the left-hand side of the Apollo Sandbox will show you all the different fields that are available to query.
 
 <figure className="image-container">
-  <img src={require("./images/QueryDocumentID.png").default} alt="Apollo Studio with document query" />
-  <figcaption>The Apollo Studio Sandbox showing the available fields for querying a document.</figcaption>
+  <img
+    src={require("./images/QueryDocumentID.png").default}
+    alt="Apollo Studio with document query"
+  />
+  <figcaption>
+    The Apollo Studio Sandbox showing the available fields for querying a
+    document.
+  </figcaption>
 </figure>
 
 ### Option 3: Search for your document ID via GraphQL
@@ -143,7 +172,16 @@ query getDocument($documentId: PHID!, $driveId: String) {
       name
       revision
       state {
-        items { id text checked } stats { total checked unchecked }
+        items {
+          id
+          text
+          checked
+        }
+        stats {
+          total
+          checked
+          unchecked
+        }
       }
     }
   }
@@ -160,11 +198,16 @@ query getDocument($documentId: PHID!, $driveId: String) {
 This query will return the current state of the document, including all to-do items and stats.
 
 <figure className="image-container">
-  <img src={require("./images/OperationsQuery.png").default} alt="Executing a mutation for a to-do item in Apollo Studio" />
-  <figcaption>The Apollo Studio Sandbox showing the <code>addTodoItem</code> mutation. You can see the variables passed in and the response from the server.</figcaption>
+  <img
+    src={require("./images/OperationsQuery.png").default}
+    alt="Executing a mutation for a to-do item in Apollo Studio"
+  />
+  <figcaption>
+    The Apollo Studio Sandbox showing the <code>addTodoItem</code> mutation. You
+    can see the variables passed in and the response from the server.
+  </figcaption>
 </figure>
 
-
 ## Mutate the state of a document
 
 Now that we know how to query the state of a document, we can start to write to it.
@@ -205,6 +248,7 @@ To delete an item, you'll need its unique identifier. When you query for the to-
 The document model provides a `DELETE_TODO_ITEM` operation, which corresponds to a `deleteTodoItem` mutation.
 
 Here's how you can use it:
+
 ```graphql title="example-delete-mutation"
 mutation Mutation($docId: PHID, $input: ToDoList_DeleteTodoItemInput) {
   ToDoList_deleteTodoItem(docId: $docId, input: $input)
@@ -231,7 +275,6 @@ After performing a write mutation, you can verify that the change was successful
 1.  **Query the document state again:** Rerun the `getDocument` query from earlier in this tutorial. You should see the new item in the list or the deleted item removed.
 2.  **Check the Operation History:** The operation history in Connect will show the new `ADD_TODO_ITEM` or `DELETE_TODO_ITEM` operation, along with who performed it and when. This provides a complete audit trail of all changes to the document.
 
-
 ### Summary
 
 This ability to programmatically read from and write to documents via the GraphQL API is a powerful feature of Powerhouse. It unlocks countless possibilities for integrating your structured data into other applications, building automated workflows, and creating rich, data-driven user experiences.