@powerhousedao/academy 2.5.0-dev.23 → 2.5.0-dev.25
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/CHANGELOG.md +26 -0
- package/docs/academy/02-MasteryTrack/02-DocumentModelCreation/01-WhatIsADocumentModel.md +15 -7
- package/docs/academy/02-MasteryTrack/02-DocumentModelCreation/03-SpecifyDocumentOperations.md +1 -1
- package/docs/academy/02-MasteryTrack/02-DocumentModelCreation/07-ExampleToDoListRepository.md +41 -1
- package/docs/academy/05-Architecture/00-PowerhouseArchitecture.md +3 -0
- package/docs/academy/05-Architecture/images/PowerhouseArchitecture.png +0 -0
- package/docs/academy/06-ComponentLibrary/04-ScalarVsUIComponents.md +11 -35
- package/docs/academy/07-Cookbook.md +209 -0
- package/docs/academy/08-Glossary.md +19 -20
- package/docs/academy/09-AIResources.md +124 -2
- package/package.json +1 -1
package/CHANGELOG.md
CHANGED
|
@@ -1,3 +1,29 @@
|
|
|
1
|
+
## 2.5.0-dev.25 (2025-06-13)
|
|
2
|
+
|
|
3
|
+
### 🚀 Features
|
|
4
|
+
|
|
5
|
+
- start dependent services with switchboard ([188c82c6a](https://github.com/powerhouse-inc/powerhouse/commit/188c82c6a))
|
|
6
|
+
|
|
7
|
+
### 🩹 Fixes
|
|
8
|
+
|
|
9
|
+
- **docker:** request write permissions ([29d4d3fd7](https://github.com/powerhouse-inc/powerhouse/commit/29d4d3fd7))
|
|
10
|
+
|
|
11
|
+
### ❤️ Thank You
|
|
12
|
+
|
|
13
|
+
- Frank
|
|
14
|
+
|
|
15
|
+
## 2.5.0-dev.24 (2025-06-13)
|
|
16
|
+
|
|
17
|
+
### 🚀 Features
|
|
18
|
+
|
|
19
|
+
- added hostnames in docker compose ([a590eea17](https://github.com/powerhouse-inc/powerhouse/commit/a590eea17))
|
|
20
|
+
- **docker-compose:** work with published images ([9f31b70fb](https://github.com/powerhouse-inc/powerhouse/commit/9f31b70fb))
|
|
21
|
+
- **ci:** build and publish docker images on newly created tags ([ee930c4a4](https://github.com/powerhouse-inc/powerhouse/commit/ee930c4a4))
|
|
22
|
+
|
|
23
|
+
### ❤️ Thank You
|
|
24
|
+
|
|
25
|
+
- Frank
|
|
26
|
+
|
|
1
27
|
## 2.5.0-dev.23 (2025-06-13)
|
|
2
28
|
|
|
3
29
|
This was a version bump only for @powerhousedao/academy to align it with other projects, there were no code changes.
|
|
@@ -5,7 +5,13 @@ This chapter on **Document Model Creation** will help you with an in depth pract
|
|
|
5
5
|
If you have completed the Get Started tutorial you will revisit familiar topics.
|
|
6
6
|
:::
|
|
7
7
|
|
|
8
|
-
|
|
8
|
+
:::info **Definition: What is a Document Model?**
|
|
9
|
+
A Document Model is a programmable document structure that defines how data is stored, changed, and interpreted in a decentralized system. It acts like a living blueprint—capturing state, tracking changes, and enabling interaction through defined operations.
|
|
10
|
+
:::
|
|
11
|
+
|
|
12
|
+
For instance, an invoice document model might define fields like issuer, lineItems, and status, with operations such as AddLineItem and MarkAsPaid.
|
|
13
|
+
|
|
14
|
+
A Document Model can be understood as:
|
|
9
15
|
- A structured software framework that represents and **manages business logic** within a digital environment.
|
|
10
16
|
- A sophisticated template that **encapsulates the essential aspects of a digital process or a set of data**.
|
|
11
17
|
- A blueprints that define how data is **captured, manipulated, and visualised** within a system.
|
|
@@ -184,14 +190,16 @@ This removes the need for **complex database joins** and allows for **fast, stru
|
|
|
184
190
|
|
|
185
191
|
Document Models offer a range of features that can be leveraged to create sophisticated, automated, and data-driven solutions:
|
|
186
192
|
|
|
187
|
-
- **
|
|
188
|
-
|
|
189
|
-
- **
|
|
190
|
-
|
|
191
|
-
- **Version Control**:
|
|
193
|
+
- **Automation**: Automate workflows using consistent, structured document logic.
|
|
194
|
+
- **Auditability**: Maintain a full history of changes for compliance and transparency.
|
|
195
|
+
- **API Integration**: Seamlessly connect with Switchboard or external APIs for data exchange.
|
|
196
|
+
- **Data Analysis**: Enable real-time and historical insights through structured read models.
|
|
197
|
+
- **Version Control**: Track and compare document states over time, similar to Git.
|
|
198
|
+
- **Collaboration**: Empower decentralized teams to build, modify, and share documents asynchronously.
|
|
199
|
+
- **Extensibility**: Add new fields, operations, and integrations over time without rewriting logic.
|
|
192
200
|
|
|
193
201
|
Document Models are a powerful primitive within the Powerhouse vision, offering a flexible, structured, and efficient way to manage business logic and data.
|
|
194
202
|
|
|
195
203
|
### Up Next: How to build a Document Model
|
|
196
204
|
|
|
197
|
-
In the next chapters, we'll teach you how to build a ToDoList document model while explaining all of the theory that is involved.
|
|
205
|
+
In the next chapters, we'll teach you how to build a ToDoList document model while explaining all of the theory that is involved. d
|
package/docs/academy/02-MasteryTrack/02-DocumentModelCreation/03-SpecifyDocumentOperations.md
CHANGED
|
@@ -114,6 +114,6 @@ export const reducer: ToDoListToDoListOperations = {
|
|
|
114
114
|
|
|
115
115
|
## Conclusion
|
|
116
116
|
|
|
117
|
-
Specifying document operations is a foundational step in building robust and predictable document models in Powerhouse. By clearly defining the "what" (the operation and its input) before implementing the "how" (the reducer logic)
|
|
117
|
+
Specifying document operations is a foundational step in building robust and predictable document models in Powerhouse. By clearly defining the **"what" (the operation and its input)** before implementing the **"how" (the reducer logic)**, you create a clear contract for state transitions. This approach enhances type safety, testability, and the overall maintainability of your document model.
|
|
118
118
|
|
|
119
119
|
In the next section, we will dive deeper into the implementation of the reducer functions for these specified operations.
|
package/docs/academy/02-MasteryTrack/02-DocumentModelCreation/07-ExampleToDoListRepository.md
CHANGED
|
@@ -1 +1,41 @@
|
|
|
1
|
-
# Example:
|
|
1
|
+
# Example: ToDo Demo Package
|
|
2
|
+
|
|
3
|
+
:::info
|
|
4
|
+
|
|
5
|
+
The ToDo Demo package is maintained by the Powerhouse Team and serves as a reference for testing and introducing new features. It will be continuously updated alongside the accompanying documentation.
|
|
6
|
+
|
|
7
|
+
https://github.com/powerhouse-inc/todo-demo-package
|
|
8
|
+
:::
|
|
9
|
+
|
|
10
|
+
There are several ways to explore this package:
|
|
11
|
+
|
|
12
|
+
### Option 1: Rebuild the ToDo Demo Package
|
|
13
|
+
|
|
14
|
+
The ToDo Demo package and repository are your main reference points during the Mastery Track.
|
|
15
|
+
Follow the steps in the "Mastery Track – Document Model Creation" chapters to build along with the examples.
|
|
16
|
+
|
|
17
|
+
### Option 2: Clone and Run the Code Locally
|
|
18
|
+
|
|
19
|
+
The package includes:
|
|
20
|
+
- The Document Model
|
|
21
|
+
- Reducer Code
|
|
22
|
+
- Reducer Tests
|
|
23
|
+
- Editor Code
|
|
24
|
+
- Drive Explorer Code
|
|
25
|
+
|
|
26
|
+
You can clone the repository and run Connect Studio to see all the code in action:
|
|
27
|
+
|
|
28
|
+
```bash
|
|
29
|
+
ph connect
|
|
30
|
+
```
|
|
31
|
+
|
|
32
|
+
### Option 3: Install the ToDo Demo Package in a (Local) Host App
|
|
33
|
+
|
|
34
|
+
Alternatively, you can install this package in a Powerhouse project or in your deployed host apps:
|
|
35
|
+
|
|
36
|
+
```bash
|
|
37
|
+
ph install @powerhousedao/todo-demo-package
|
|
38
|
+
```
|
|
39
|
+
|
|
40
|
+
|
|
41
|
+
|
|
@@ -12,6 +12,9 @@ These five applications are:
|
|
|
12
12
|
|
|
13
13
|
Each application is designed to be modular yet complementary, ensuring smooth data flows, structured collaboration, and scalable automation. The functionality of the four host apps offers an integrated experience for running decentralized operations.
|
|
14
14
|
|
|
15
|
+

|
|
16
|
+
|
|
17
|
+
|
|
15
18
|
## How the Five Applications Work Together
|
|
16
19
|
|
|
17
20
|
The Powerhouse ecosystem functions as a decentralized operating system, where each of the four core applications works in synergy to ensure seamless collaboration, structured data management, and automated workflows. Each application has a distinct purpose, yet their interconnectivity is what makes the system powerful.
|
|
Binary file
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
import { Tabs, TabItem } from '@theme/Tabs';
|
|
2
2
|
|
|
3
|
-
# Scalar
|
|
3
|
+
# Scalar vs. UI component
|
|
4
4
|
|
|
5
5
|
Scalars are here to help you define custom fields in your document model schema and speed up the development process.
|
|
6
6
|
There are two applications of scalar components in the document model workflow:
|
|
@@ -8,45 +8,21 @@ There are two applications of scalar components in the document model workflow:
|
|
|
8
8
|
1. At the **schema definition** level where you build your schema and write your GraphQL state schema.
|
|
9
9
|
2. At the **frontend / react** level where you import it and place it in your UI to represent the scalar field
|
|
10
10
|
|
|
11
|
-
##
|
|
11
|
+
## Overview
|
|
12
|
+
The Document Engineering library provides two main categories of components.
|
|
12
13
|
|
|
13
|
-
|
|
14
|
+
https://github.com/powerhouse-inc/document-engineering
|
|
14
15
|
|
|
15
|
-
|
|
16
|
+
### Scalar Components
|
|
16
17
|
|
|
17
|
-
|
|
18
|
+
These are specialized form components, each corresponding to a GraphQL scalar type (e.g., String, Number, Boolean, Currency, PHID). They are built on top of react-hook-form, offering out-of-the-box validation but must be wrapped with a Form component in order to work properly.
|
|
18
19
|
|
|
19
|
-
|
|
20
|
+
Location: @powerhousedao/document-engineering/scalars
|
|
20
21
|
|
|
21
|
-
|
|
22
|
-
This package comes as a dependency in your project when creating a new document model project.
|
|
23
|
-
````
|
|
24
|
-
import PHIDField from 'document-engineering'
|
|
25
|
-
const reactComponent = () => {
|
|
22
|
+
**Key Feature**: Must be used within a Form component provided by this library.
|
|
26
23
|
|
|
27
|
-
|
|
28
|
-
<div>
|
|
29
|
-
<PHIDField
|
|
30
|
-
fetchOptionsCallback={function Js(){}}
|
|
31
|
-
fetchSelectedOptionCallback={function Js(){}}
|
|
32
|
-
label="PHID field"
|
|
33
|
-
name="phid-field"
|
|
34
|
-
placeholder="phd:"
|
|
35
|
-
/>
|
|
24
|
+
### General-Purpose UI Components
|
|
36
25
|
|
|
37
|
-
|
|
38
|
-
|
|
39
|
-
)
|
|
40
|
-
|
|
41
|
-
}
|
|
42
|
-
````
|
|
43
|
-
|
|
44
|
-
## Scalars & Reusable Components
|
|
45
|
-
|
|
46
|
-
To make your life easier, Powerhouse has defined all useful scalars with a set of reusable code and UI components.
|
|
47
|
-
The reusable components are essentially a set of front-end components based on GraphQL scalars. Powerhouse also has a set of custom scalars that are not part of the GraphQL standard but are specific to the web3 ecosystem.
|
|
48
|
-
|
|
49
|
-
Read the next chapter to get familiar with our reusable components.
|
|
50
|
-
|
|
51
|
-
# PHID Field Implementation Example
|
|
26
|
+
This category includes a broader range of UI elements such as simplified versions of the Scalar components (which don't require a Form wrapper but lack built-in validation), as well as other versatile components like Dropdown, Tooltip, Sidebar, ObjectSetTable and more. These are designed for crafting diverse and complex user interfaces.
|
|
52
27
|
|
|
28
|
+
Location: @powerhousedao/document-engineering/ui
|
|
@@ -337,6 +337,75 @@ ph init --package-manager pnpm
|
|
|
337
337
|
- [Bun Installation Guide](https://bun.sh/docs/installation#how-to-add-your-path)
|
|
338
338
|
</details>
|
|
339
339
|
|
|
340
|
+
## Powerhouse Environment Recipes
|
|
341
|
+
This section covers recipes for setting up and managing Powerhouse environments, from local development to production servers.
|
|
342
|
+
|
|
343
|
+
<details id="setting-up-a-production-environment">
|
|
344
|
+
<summary>Setting up a Production Environment</summary>
|
|
345
|
+
|
|
346
|
+
## How to Set Up a Production Powerhouse Environment
|
|
347
|
+
---
|
|
348
|
+
|
|
349
|
+
## Problem Statement
|
|
350
|
+
You need to set up a new production-ready server to host and run your Powerhouse services (Connect and Switchboard).
|
|
351
|
+
|
|
352
|
+
## Prerequisites
|
|
353
|
+
- A Linux-based server (Ubuntu or Debian recommended) with `sudo` privileges.
|
|
354
|
+
- A registered domain name.
|
|
355
|
+
- DNS `A` records for your `connect` and `switchboard` subdomains pointing to your server's public IP address.
|
|
356
|
+
|
|
357
|
+
## Solution
|
|
358
|
+
|
|
359
|
+
### Step 1: Install Powerhouse Services
|
|
360
|
+
SSH into your server and run the universal installation script. This will install Node.js, pnpm, and prepare the system for Powerhouse services.
|
|
361
|
+
```bash
|
|
362
|
+
curl -fsSL https://apps.powerhouse.io/install | bash
|
|
363
|
+
```
|
|
364
|
+
|
|
365
|
+
### Step 2: Reload Your Shell
|
|
366
|
+
After the installation, reload your shell's configuration to recognize the new commands.
|
|
367
|
+
```bash
|
|
368
|
+
source ~/.bashrc # Or source ~/.zshrc if using zsh
|
|
369
|
+
```
|
|
370
|
+
|
|
371
|
+
### Step 3: Initialize a Project
|
|
372
|
+
Create a project directory for your services. The `ph-init` command sets up the basic structure. Move into the directory after creation.
|
|
373
|
+
```bash
|
|
374
|
+
ph-init my-powerhouse-services
|
|
375
|
+
cd my-powerhouse-services
|
|
376
|
+
```
|
|
377
|
+
|
|
378
|
+
### Step 4: Configure Services
|
|
379
|
+
Run the interactive setup command. This will guide you through configuring Nginx, PM2, databases, and SSL.
|
|
380
|
+
```bash
|
|
381
|
+
ph service setup
|
|
382
|
+
```
|
|
383
|
+
During the setup, you will be prompted for:
|
|
384
|
+
- **Packages to install:** You can pre-install any Powerhouse packages you need. (Optional)
|
|
385
|
+
- **Database:** Choose between a local PostgreSQL setup or connecting to a remote database.
|
|
386
|
+
- **SSL Certificate:** Select Let's Encrypt for a production setup. You will need to provide your domain and subdomains.
|
|
387
|
+
|
|
388
|
+
## Expected Outcome
|
|
389
|
+
- Powerhouse Connect and Switchboard services are installed, configured, and running on your server.
|
|
390
|
+
- Nginx is set up as a reverse proxy with SSL certificates from Let's Encrypt.
|
|
391
|
+
- Services are managed by PM2 and will restart automatically on boot or if they crash.
|
|
392
|
+
- You can access your services securely at `https://connect.yourdomain.com` and `https://switchboard.yourdomain.com`.
|
|
393
|
+
|
|
394
|
+
## Common Issues and Solutions
|
|
395
|
+
- **Issue:** `ph: command not found`
|
|
396
|
+
- **Solution:** Ensure you have reloaded your shell with `source ~/.bashrc` or have restarted your terminal session.
|
|
397
|
+
- **Issue:** Let's Encrypt SSL certificate creation fails.
|
|
398
|
+
- **Solution:** Verify that your domain's DNS records have fully propagated and are pointing to the correct server IP. This can take some time.
|
|
399
|
+
- **Issue:** Services fail to start.
|
|
400
|
+
- **Solution:** Check the service logs for errors using `ph service logs` or `pm2 logs`.
|
|
401
|
+
|
|
402
|
+
## Related Recipes
|
|
403
|
+
- [Installing a Custom Powerhouse Package](#installing-a-custom-powerhouse-package)
|
|
404
|
+
|
|
405
|
+
## Further Reading
|
|
406
|
+
- [Full Setup Guide](/academy/MasteryTrack/Launch/SetupEnvironment)
|
|
407
|
+
</details>
|
|
408
|
+
|
|
340
409
|
## Powerhouse Project Recipes
|
|
341
410
|
This section focuses on creating, configuring, and managing Powerhouse projects, which are collections of document models, editors, and other resources.
|
|
342
411
|
|
|
@@ -923,6 +992,80 @@ You need to understand and manage different types of dependencies in your Powerh
|
|
|
923
992
|
|
|
924
993
|
</details>
|
|
925
994
|
|
|
995
|
+
<details id="packaging-and-publishing-a-powerhouse-project">
|
|
996
|
+
<summary>Packaging and Publishing a Powerhouse Project</summary>
|
|
997
|
+
|
|
998
|
+
## How to Package and Publish a Powerhouse Project
|
|
999
|
+
---
|
|
1000
|
+
|
|
1001
|
+
## Problem Statement
|
|
1002
|
+
You have created a collection of document models, editors, or other components and want to share it as a reusable package on a public or private npm registry. Publishing a package allows other projects to install and use your creations easily.
|
|
1003
|
+
|
|
1004
|
+
## Prerequisites
|
|
1005
|
+
- A completed Powerhouse project that you are ready to share.
|
|
1006
|
+
- An account on [npmjs.com](https://www.npmjs.com/) (or a private registry).
|
|
1007
|
+
- Your project's `package.json` should have a unique name and correct version.
|
|
1008
|
+
- You must be logged into your npm account via the command line.
|
|
1009
|
+
|
|
1010
|
+
## Solution
|
|
1011
|
+
|
|
1012
|
+
### Step 1: Build the Project
|
|
1013
|
+
First, compile your project to create a production-ready build in the `dist/` or `build/` directory.
|
|
1014
|
+
|
|
1015
|
+
```bash
|
|
1016
|
+
pnpm build
|
|
1017
|
+
```
|
|
1018
|
+
|
|
1019
|
+
### Step 2: Log In to npm
|
|
1020
|
+
If you aren't already, log in to your npm account. You will be prompted for your username, password, and one-time password.
|
|
1021
|
+
|
|
1022
|
+
```bash
|
|
1023
|
+
npm login
|
|
1024
|
+
```
|
|
1025
|
+
|
|
1026
|
+
### Step 3: Version Your Package
|
|
1027
|
+
Update the package version according to semantic versioning. This command updates `package.json` and creates a new Git tag.
|
|
1028
|
+
|
|
1029
|
+
```bash
|
|
1030
|
+
# Choose one depending on the significance of your changes
|
|
1031
|
+
pnpm version patch # For bug fixes (e.g., 1.0.0 -> 1.0.1)
|
|
1032
|
+
pnpm version minor # For new features (e.g., 1.0.1 -> 1.1.0)
|
|
1033
|
+
pnpm version major # For breaking changes (e.g., 1.1.0 -> 2.0.0)
|
|
1034
|
+
```
|
|
1035
|
+
|
|
1036
|
+
### Step 4: Publish the Package
|
|
1037
|
+
Publish your package to the npm registry. If it's your first time publishing a scoped package (e.g., `@your-org/your-package`), you may need to add the `--access public` flag.
|
|
1038
|
+
|
|
1039
|
+
```bash
|
|
1040
|
+
npm publish --access public
|
|
1041
|
+
```
|
|
1042
|
+
|
|
1043
|
+
### Step 5: Push Git Commits and Tags
|
|
1044
|
+
Push your new version commit and tag to your remote repository to keep it in sync.
|
|
1045
|
+
|
|
1046
|
+
```bash
|
|
1047
|
+
# Push your current branch
|
|
1048
|
+
git push
|
|
1049
|
+
|
|
1050
|
+
# Push the newly created version tag
|
|
1051
|
+
git push --tags
|
|
1052
|
+
```
|
|
1053
|
+
|
|
1054
|
+
## Expected Outcome
|
|
1055
|
+
- Your Powerhouse project is successfully published to the npm registry.
|
|
1056
|
+
- Other developers can now install your package into their projects using `ph install @your-org/your-package-name`.
|
|
1057
|
+
- Your Git repository is updated with the new version information.
|
|
1058
|
+
|
|
1059
|
+
## Common Issues and Solutions
|
|
1060
|
+
- **Issue**: "403 Forbidden" or "You do not have permission" error on publish.
|
|
1061
|
+
- **Solution**: Ensure your package name is unique and not already taken on npm. If it's a scoped package (`@scope/name`), make sure the organization exists and you have permission to publish to it. For public scoped packages, you must include `--access public`.
|
|
1062
|
+
|
|
1063
|
+
## Related Recipes
|
|
1064
|
+
- [Installing a Custom Powerhouse Package](#installing-a-custom-powerhouse-package)
|
|
1065
|
+
- [Managing Powerhouse Dependencies and Versions](#managing-powerhouse-dependencies-and-versions)
|
|
1066
|
+
|
|
1067
|
+
</details>
|
|
1068
|
+
|
|
926
1069
|
## Data Synchronisation Recipes
|
|
927
1070
|
This section helps troubleshoot and understand data synchronization within the Powerhouse ecosystem, including interactions between different services and components.
|
|
928
1071
|
|
|
@@ -988,3 +1131,69 @@ Understanding the different GraphQL endpoints in Powerhouse is crucial for effec
|
|
|
988
1131
|
- **Solution:** Consider cleaning the global Powerhouse setup by removing `~/.ph`
|
|
989
1132
|
|
|
990
1133
|
</details>
|
|
1134
|
+
|
|
1135
|
+
<details id="clearing-package-manager-caches">
|
|
1136
|
+
<summary>Clearing Package Manager Caches</summary>
|
|
1137
|
+
|
|
1138
|
+
## How to Clear Package Manager Caches
|
|
1139
|
+
---
|
|
1140
|
+
|
|
1141
|
+
## Problem Statement
|
|
1142
|
+
You are encountering unexpected issues with dependencies, `ph-cmd` installation, or package resolution. Corrupted or outdated caches for your package manager (pnpm, npm, yarn) can often be the cause. Clearing the cache forces the package manager to refetch packages, which can resolve these problems.
|
|
1143
|
+
|
|
1144
|
+
## Prerequisites
|
|
1145
|
+
- Terminal or command prompt access
|
|
1146
|
+
- A package manager (pnpm, npm, or yarn) installed
|
|
1147
|
+
|
|
1148
|
+
## Solution
|
|
1149
|
+
|
|
1150
|
+
Choose the commands corresponding to the package manager you are using.
|
|
1151
|
+
|
|
1152
|
+
### For pnpm
|
|
1153
|
+
`pnpm` has a robust set of commands to manage its content-addressable store.
|
|
1154
|
+
|
|
1155
|
+
```bash
|
|
1156
|
+
# Verify the integrity of the cache
|
|
1157
|
+
pnpm cache verify
|
|
1158
|
+
|
|
1159
|
+
# Remove orphaned packages from the store
|
|
1160
|
+
pnpm store prune
|
|
1161
|
+
```
|
|
1162
|
+
|
|
1163
|
+
### For npm
|
|
1164
|
+
`npm` provides commands to clean and verify its cache.
|
|
1165
|
+
|
|
1166
|
+
```bash
|
|
1167
|
+
# Verify the contents of the cache folder, which can fix some issues
|
|
1168
|
+
npm cache verify
|
|
1169
|
+
|
|
1170
|
+
# If verification doesn't solve the issue, force clean the cache
|
|
1171
|
+
npm cache clean --force
|
|
1172
|
+
```
|
|
1173
|
+
|
|
1174
|
+
### For Yarn (v1 Classic)
|
|
1175
|
+
Yarn Classic allows you to list and clean the cache.
|
|
1176
|
+
|
|
1177
|
+
```bash
|
|
1178
|
+
# List the contents of the cache
|
|
1179
|
+
yarn cache list
|
|
1180
|
+
|
|
1181
|
+
# Clean the cache
|
|
1182
|
+
yarn cache clean --force
|
|
1183
|
+
```
|
|
1184
|
+
|
|
1185
|
+
## Expected Outcome
|
|
1186
|
+
- The package manager's cache is cleared or verified.
|
|
1187
|
+
- Subsequent installations will fetch fresh versions of packages, potentially resolving dependency-related errors.
|
|
1188
|
+
- Your system is in a cleaner state for managing Powerhouse project dependencies.
|
|
1189
|
+
|
|
1190
|
+
## Common Issues and Solutions
|
|
1191
|
+
- **Issue**: Problems persist after clearing the cache.
|
|
1192
|
+
- **Solution**: The issue might not be cache-related. Consider completely removing `node_modules` and lockfiles (`pnpm-lock.yaml`, `package-lock.json`, `yarn.lock`) and running `pnpm install` (or equivalent) again.
|
|
1193
|
+
|
|
1194
|
+
## Related Recipes
|
|
1195
|
+
- [Installing 'ph-cmd'](#installing-ph-cmd)
|
|
1196
|
+
- [Uninstalling 'ph-cmd'](#uninstalling-ph-cmd)
|
|
1197
|
+
- [Managing Powerhouse Dependencies and Versions](#managing-powerhouse-dependencies-and-versions)
|
|
1198
|
+
|
|
1199
|
+
</details>
|
|
@@ -25,61 +25,60 @@
|
|
|
25
25
|
- **Renown (Login Flow)** – The Powerhouse decentralized login process using an Ethereum wallet signature to generate/retrieve a user's DID for secure, pseudonymous actions.
|
|
26
26
|
- **Powerhouse Switchboard (Verifier Role)** – A function of Powerhouse Switchboard that validates DIDs and credentials for operations submitted via Connect, ensuring they are authorized.
|
|
27
27
|
|
|
28
|
-
##
|
|
28
|
+
## Document Modeling
|
|
29
29
|
- **Action Creators (for Document Operations)** – Auto-generated helper functions creating structured "action" objects for dispatching operations to a document model's reducer.
|
|
30
30
|
- **Actions (Document Actions)** – Typed objects representing an intent to change a document's state, dispatched to reducers, containing an operation type and input data.
|
|
31
31
|
- **API Integration (for Document Models)** – The capability of Document Models to connect with Switchboard API or external APIs, facilitating data exchange between Powerhouse applications and other systems.
|
|
32
|
-
- **Boilerplate (Powerhouse Project)** – The `ph init` command's initial project structure, providing a standard starting point for new Powerhouse packages.
|
|
33
|
-
- **Connect Build** – The output of the `ph connect build` command, which packages a Connect project into a distributable format. This build includes all necessary local/external packages, assets, and styles, and can be previewed locally with `ph connect preview` or deployed.
|
|
34
32
|
- **Data Analysis (with Document Models)** – Leveraging the structured data within Document Models, often via read models, to extract insights, generate reports, and perform analytics on operational and historical data.
|
|
35
|
-
- **Development Environment (Powerhouse)** – A local setup for developing Powerhouse applications, typically initiated with the `ph dev` command. It runs essential backend services like the Powerhouse Switchboard to enable real-time document model processing, code generation, and live updates, separate from the front-end Connect Studio.
|
|
36
33
|
- **Dispatch (in Document Models)** – The act of sending an action (representing an operation) to a document model's reducer to trigger a state update.
|
|
37
|
-
- **Document Model Editors** – An interface or UI to a document model that allows users to create and modify the data captured by the document models.
|
|
38
34
|
- **Document Model Specification** – The formal definition of a document model (state, operations), created in Connect Studio (using GraphQL SDL) and exported (e.g., `.phdm.zip`) for code generation.
|
|
39
35
|
- **Document Models** – Structured data models that define how Powerhouse documents store and process information.
|
|
40
36
|
- **Document State** – The current data held by a document instance, structured according to its Document Model.
|
|
41
37
|
- **Document Type** – A unique string identifier (e.g., `powerhouse/todolist`) for a Document Model, used by host apps to select the correct editor/logic.
|
|
42
|
-
- **Drive** – A logical container in Powerhouse for storing, organizing, and managing collections of documents.
|
|
43
|
-
- **Drive App (Custom Drive Explorer)** – A UI application, often custom, providing tailored views and interactions with documents in a Drive.
|
|
44
|
-
- **Environments (Powerhouse Environments)** – Pre-defined configurations for a project's Powerhouse dependencies, such as `dev` (development), `prod` (production/latest), and `local`. The Powerhouse CLI (`ph use` command) allows developers to easily switch between these environments to use different versions of packages (e.g., bleeding-edge, stable, or from a local monorepo).
|
|
45
38
|
- **Event History (Append-Only Log)** – An immutable, append-only log where every operation applied to a Powerhouse document is stored as an event. It provides a transparent audit trail and enables features like time travel debugging and state reconstruction.
|
|
46
39
|
- **GraphQL Scalars** – Data types used in Powerhouse document modeling (e.g., `String`, `Int`, `Currency`, `OID` for unique object IDs).
|
|
47
40
|
- **GraphQL Schema Definition Language (SDL) (for Document Models)** – Language used in Connect Studio to define a Document Model's data structure (state) and operations.
|
|
48
|
-
- **
|
|
41
|
+
- **Immutable Updates** – A principle where data is never altered in place; operations create new data versions, vital for Powerhouse's event sourcing.
|
|
49
42
|
- **Input Types (GraphQL for Document Operations)** – Custom data structures in SDL detailing parameters for document operations (e.g., `AddTodoItemInput`).
|
|
50
43
|
- **Model-Driven Development (MDD)** – A software approach that uses high-level models to generate system logic and configurations.
|
|
51
|
-
- **Modules (in Document Model Editor)** – An organizational feature in Connect Studio's model editor for grouping related operations.
|
|
52
44
|
- **Operations (Document Operations)** – Named commands (e.g., `ADD_TODO_ITEM`) in a Document Model representing all ways to change its state, forming its event log.
|
|
53
45
|
- **Powerhouse Document (`.phd` file)** – Standard file extension for an exported Powerhouse document instance, containing its data and history.
|
|
54
|
-
- **Powerhouse Package** – A collection of document models, document model editors, and other resources that are published as a package and can be used in any of the host applications.
|
|
55
|
-
- **Powerhouse Project** – A collection of document models, document model editors, and other resources being build in Connect Studio.
|
|
56
46
|
- **Pure Functions (for Reducers)** – Principle that document model reducers must be pure (output depends only on input, no side effects) for predictable state transitions.
|
|
57
47
|
- **Reducers (Document Model Reducers)** – Functions implementing a Document Model's logic; for each operation, a reducer takes current state and an action, returning new state.
|
|
58
48
|
- **Replay Events** – The process of re-applying recorded events from a document's Event History to reconstruct or restore its state, a core capability of Event Sourcing.
|
|
59
|
-
- **Scalars (Design System Components)** – Reusable UI building blocks (e.g., `Checkbox`, `InputField`) from `@powerhousedao/document-engineering/scalars`, used in editors (distinct from GraphQL scalars).
|
|
60
49
|
- **State (Global State in Document Model)** – The primary, persisted, shared data of a document instance, managed by its reducers.
|
|
61
|
-
- **State (Local State in Editor)** – Temporary, UI-specific data within an editor (e.g., form inputs), not persisted in the global document state.
|
|
62
50
|
- **State Schema** – The component of a Document Model that defines the structure of the document, including its fields, data types, and validation rules, typically using a GraphQL-like syntax. It serves as a blueprint for how data is stored and validated.
|
|
63
|
-
- **Storybook (for Powerhouse Design System)** – Interactive environment for browsing and testing Powerhouse Design System UI components.
|
|
64
51
|
- **Strands** – A single synchronization channel that connects exactly one unit of synchronization to another, with all four parameters (drive_url, doc_id, scope, branch) set to fixed values. This allows synchronization between two distinct points of instances of a document or document drive.
|
|
65
|
-
- **Tailwind CSS (in Connect Studio)** – Utility CSS framework integrated into Connect Studio for styling document editors.
|
|
66
52
|
- **Time Travel Debugging** – A debugging technique, enabled by a document's Event History, that allows developers to reconstruct and inspect past states of the document by replaying events up to a specific point in time.
|
|
67
53
|
- **Type Safety (in Document Modeling)** – Powerhouse's use of auto-generated TypeScript definitions from a model's schema (SDL) to prevent data type errors in development.
|
|
68
54
|
- **Version Control (for Document Models)** – A planned feature for Document Models in Connect that will allow tracking of changes, comparison of different versions, and maintenance of data integrity over time, similar to version control systems for source code.
|
|
69
55
|
|
|
56
|
+
## Development & Tooling
|
|
57
|
+
- **Boilerplate (Powerhouse Project)** – The `ph init` command's initial project structure, providing a standard starting point for new Powerhouse packages.
|
|
58
|
+
- **Connect Build** – The output of the `ph connect build` command, which packages a Connect project into a distributable format. This build includes all necessary local/external packages, assets, and styles, and can be previewed locally with `ph connect preview` or deployed.
|
|
59
|
+
- **Development Environment (Powerhouse)** – A local setup for developing Powerhouse applications, typically initiated with the `ph dev` command. It runs essential backend services like the Powerhouse Switchboard to enable real-time document model processing, code generation, and live updates, separate from the front-end Connect Studio.
|
|
60
|
+
- **Document Model Editors** – An interface or UI to a document model that allows users to create and modify the data captured by the document models.
|
|
61
|
+
- **Drive** – A logical container in Powerhouse for storing, organizing, and managing collections of documents.
|
|
62
|
+
- **Drive App (Custom Drive Explorer)** – A UI application, often custom, providing tailored views and interactions with documents in a Drive.
|
|
63
|
+
- **Environments (Powerhouse Environments)** – Pre-defined configurations for a project's Powerhouse dependencies, such as `dev` (development), `prod` (production/latest), and `local`. The Powerhouse CLI (`ph use` command) allows developers to easily switch between these environments to use different versions of packages (e.g., bleeding-edge, stable, or from a local monorepo).
|
|
64
|
+
- **Host Applications** – Applications that use the Powerhouse framework to create and manage documents and data.
|
|
65
|
+
- **Modules (in Document Model Editor)** – An organizational feature in Connect Studio's model editor for grouping related operations.
|
|
66
|
+
- **Powerhouse Package** – A collection of document models, document model editors, and other resources that are published as a package and can be used in any of the host applications.
|
|
67
|
+
- **Powerhouse Project** – A collection of document models, document model editors, and other resources being build in Connect Studio.
|
|
68
|
+
- **Scalars (Design System Components)** – Reusable UI building blocks (e.g., `Checkbox`, `InputField`) from `@powerhousedao/document-engineering/scalars`, used in editors (distinct from GraphQL scalars).
|
|
69
|
+
- **State (Local State in Editor)** – Temporary, UI-specific data within an editor (e.g., form inputs), not persisted in the global document state.
|
|
70
|
+
- **Storybook (for Powerhouse Design System)** – Interactive environment for browsing and testing Powerhouse Design System UI components.
|
|
71
|
+
- **Tailwind CSS (in Connect Studio)** – Utility CSS framework integrated into Connect Studio for styling document editors.
|
|
72
|
+
|
|
70
73
|
## AI & Automation
|
|
71
74
|
- **AI Assistants** – AI-powered contributors paired with human contributors to automate tasks and improve productivity.
|
|
72
75
|
- **AI Contributor Modes** – Configurable states that determine the AI assistant's behavior, permissions, and task focus.
|
|
73
76
|
- **Task Automation & Scaling** – The use of AI to streamline repetitive tasks, improve communications, and enhance decision-making.
|
|
74
77
|
- **Decentralized Identifier (DID)** – A user-controlled, globally unique ID, used in Renown to link a user's blockchain key to actions pseudonymously.
|
|
75
|
-
- **Immutable Updates** – A principle where data is never altered in place; operations create new data versions, vital for Powerhouse's event sourcing.
|
|
76
|
-
- **Type Safety (in Document Modeling)** – Powerhouse's use of auto-generated TypeScript definitions from a model's schema (SDL) to prevent data type errors in development.
|
|
77
78
|
|
|
78
79
|
## Organizational Concepts
|
|
79
80
|
- **Ceramic** – A decentralized network for storing verifiable data, used by Powerhouse Renown for secure credential management.
|
|
80
81
|
- **Decentralized Identifier (DID)** – A user-controlled, globally unique ID, used in Renown to link a user's blockchain key to actions pseudonymously.
|
|
81
|
-
- **Event History (Append-Only Log)** – An immutable, append-only log where every operation applied to a Powerhouse document is stored as an event. It provides a transparent audit trail and enables features like time travel debugging and state reconstruction.
|
|
82
82
|
- **Event-Driven Architecture (EDA)** – A software design approach where system flows are determined by events that trigger actions asynchronously.
|
|
83
|
-
- **Immutable Updates** – A principle where data is never altered in place; operations create new data versions, vital for Powerhouse's event sourcing.
|
|
84
83
|
- **Network Organization** – A group of independent contributors and teams working together towards a common purpose, relying on decentralization and resource sharing.
|
|
85
84
|
|
|
@@ -2,8 +2,130 @@
|
|
|
2
2
|
|
|
3
3
|
We have a couple of AI resources to help you with your daily work or exploring our ecosystem.
|
|
4
4
|
|
|
5
|
+
:::warning
|
|
6
|
+
- Be aware that AI tooling can make mistakes.
|
|
7
|
+
- Documentation can be out of date or code can be work in progress.
|
|
8
|
+
- Always verify your coding agent's suggestions.
|
|
9
|
+
:::
|
|
10
|
+
|
|
11
|
+
|
|
5
12
|
| Tool | Description |
|
|
6
13
|
|---|---|
|
|
7
|
-
| [**Deepwiki**](https://deepwiki.com/powerhouse-inc/powerhouse) | A searchable/queriable wiki to understand our growing
|
|
8
|
-
| [**Context7**](https://context7.com/powerhouse-inc/powerhouse) | The Powerhouse Academy is also available as context through the context7 MCP Server. <br /> LLMs rely on outdated or generic information about the libraries you use. <br /> Context7 pulls up-to-date, version-specific documentation and code examples directly from the source. <br /> Paste accurate, relevant documentation directly into tools like Cursor, Claude, or any LLM. |
|
|
14
|
+
| [**Deepwiki**](https://deepwiki.com/powerhouse-inc/powerhouse) | A searchable/queriable wiki to understand our growing Powerhouse **Monorepository** better. <br /> DeepWiki provides up-to-date documentation you can talk to, for every repo in the world. Think Deep Research for GitHub. |
|
|
15
|
+
| [**Context7**](https://context7.com/powerhouse-inc/powerhouse) | The Powerhouse **Academy Documentation** is also available as context through the context7 MCP Server. <br /> LLMs rely on outdated or generic information about the libraries you use. <br /> Context7 pulls up-to-date, version-specific documentation and code examples directly from the source. <br /> Paste accurate, relevant documentation directly into tools like Cursor, Claude, or any LLM. <br /> The official repository can be found [here](https://github.com/upstash/context7). |
|
|
16
|
+
|
|
17
|
+
|
|
18
|
+
### Context7 Installation
|
|
19
|
+
|
|
20
|
+
<details>
|
|
21
|
+
<summary><b>Install in Cursor</b></summary>
|
|
22
|
+
|
|
23
|
+
Go to: `Settings` -> `Cursor Settings` -> `MCP` -> `Add new global MCP server`
|
|
24
|
+
|
|
25
|
+
Pasting the following configuration into your Cursor `~/.cursor/mcp.json` file is the recommended approach. You may also install in a specific project by creating `.cursor/mcp.json` in your project folder.
|
|
26
|
+
|
|
27
|
+
**Cursor Local Server Connection**
|
|
28
|
+
|
|
29
|
+
```json
|
|
30
|
+
{
|
|
31
|
+
"mcpServers": {
|
|
32
|
+
"context7": {
|
|
33
|
+
"command": "npx",
|
|
34
|
+
"args": ["-y", "@upstash/context7-mcp"]
|
|
35
|
+
}
|
|
36
|
+
}
|
|
37
|
+
}
|
|
38
|
+
```
|
|
39
|
+
|
|
40
|
+
</details>
|
|
41
|
+
|
|
42
|
+
<details>
|
|
43
|
+
<summary><b>Install in VS Code</b></summary>
|
|
44
|
+
|
|
45
|
+
Add this to your VS Code MCP config file. See [VS Code MCP docs](https://code.visualstudio.com/docs/copilot/chat/mcp-servers) for more info.
|
|
46
|
+
|
|
47
|
+
**VS Code Local Server Connection**
|
|
48
|
+
|
|
49
|
+
```json
|
|
50
|
+
"mcp": {
|
|
51
|
+
"servers": {
|
|
52
|
+
"context7": {
|
|
53
|
+
"type": "stdio",
|
|
54
|
+
"command": "npx",
|
|
55
|
+
"args": ["-y", "@upstash/context7-mcp"]
|
|
56
|
+
}
|
|
57
|
+
}
|
|
58
|
+
}
|
|
59
|
+
```
|
|
60
|
+
</details>
|
|
61
|
+
|
|
62
|
+
For other editors, please refer to the [official documentation](https://github.com/upstash/context7#%-installation).
|
|
63
|
+
|
|
64
|
+
### Context7 Troubleshooting
|
|
65
|
+
|
|
66
|
+
<details>
|
|
67
|
+
<summary><b>MCP, Documentation or Module Not Found Errors</b></summary>
|
|
68
|
+
|
|
69
|
+
If you encounter `ERR_MODULE_NOT_FOUND`, try using `bunx` instead of `npx`:
|
|
70
|
+
|
|
71
|
+
```json
|
|
72
|
+
{
|
|
73
|
+
"mcpServers": {
|
|
74
|
+
"context7": {
|
|
75
|
+
"command": "bunx",
|
|
76
|
+
"args": ["-y", "@upstash/context7-mcp"]
|
|
77
|
+
}
|
|
78
|
+
}
|
|
79
|
+
}
|
|
80
|
+
```
|
|
81
|
+
|
|
82
|
+
This often resolves module resolution issues in environments where `npx` doesn't properly install or resolve packages.
|
|
83
|
+
|
|
84
|
+
</details>
|
|
85
|
+
|
|
86
|
+
<details>
|
|
87
|
+
<summary><b>ESM Resolution Issues</b></summary>
|
|
88
|
+
|
|
89
|
+
For errors like `Error: Cannot find module 'uriTemplate.js'`, try the `--experimental-vm-modules` flag:
|
|
90
|
+
|
|
91
|
+
```json
|
|
92
|
+
{
|
|
93
|
+
"mcpServers": {
|
|
94
|
+
"context7": {
|
|
95
|
+
"command": "npx",
|
|
96
|
+
"args": ["-y", "--node-options=--experimental-vm-modules", "@upstash/context7-mcp@1.0.6"]
|
|
97
|
+
}
|
|
98
|
+
}
|
|
99
|
+
}
|
|
100
|
+
```
|
|
101
|
+
|
|
102
|
+
</details>
|
|
103
|
+
|
|
104
|
+
<details>
|
|
105
|
+
<summary><b>TLS/Certificate Issues</b></summary>
|
|
106
|
+
|
|
107
|
+
Use the `--experimental-fetch` flag to bypass TLS-related problems:
|
|
108
|
+
|
|
109
|
+
```json
|
|
110
|
+
{
|
|
111
|
+
"mcpServers": {
|
|
112
|
+
"context7": {
|
|
113
|
+
"command": "npx",
|
|
114
|
+
"args": ["-y", "--node-options=--experimental-fetch", "@upstash/context7-mcp"]
|
|
115
|
+
}
|
|
116
|
+
}
|
|
117
|
+
}
|
|
118
|
+
```
|
|
119
|
+
|
|
120
|
+
</details>
|
|
121
|
+
|
|
122
|
+
<details>
|
|
123
|
+
<summary><b>General MCP Client Errors</b></summary>
|
|
124
|
+
|
|
125
|
+
1. Try adding `@latest` to the package name
|
|
126
|
+
2. Use `bunx` as an alternative to `npx`
|
|
127
|
+
3. Consider using `deno` as another alternative
|
|
128
|
+
4. Ensure you're using Node.js v18 or higher for native fetch support
|
|
129
|
+
|
|
130
|
+
</details>
|
|
9
131
|
|