@powerhousedao/academy 5.1.0-dev.14 → 5.1.0-dev.17
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 +29 -0
- package/docs/academy/01-GetStarted/00-ExploreDemoPackage.mdx +11 -11
- package/docs/academy/01-GetStarted/01-CreateNewPowerhouseProject.md +22 -5
- package/docs/academy/01-GetStarted/02-DefineToDoListDocumentModel.md +2 -20
- package/docs/academy/01-GetStarted/03-ImplementOperationReducers.md +2 -3
- package/docs/academy/01-GetStarted/05-BuildToDoListEditor.md +4 -4
- package/docs/academy/01-GetStarted/home.mdx +43 -104
- package/docs/academy/01-GetStarted/images/DocumentModelOperations.png +0 -0
- package/docs/academy/01-GetStarted/styles.module.css +30 -6
- package/docs/academy/02-MasteryTrack/01-BuilderEnvironment/02-VetraStudio.md +95 -0
- package/docs/academy/02-MasteryTrack/01-BuilderEnvironment/{02-StandardDocumentModelWorkflow.md → 03-CreateAPackageWithVetra.md} +202 -33
- package/docs/academy/02-MasteryTrack/01-BuilderEnvironment/{03-BuilderTools.md → BuilderTools} +1 -1
- package/docs/academy/02-MasteryTrack/03-BuildingUserExperiences/02-ConfiguringDrives.md +4 -4
- package/docs/academy/02-MasteryTrack/03-BuildingUserExperiences/03-BuildingADriveExplorer.md +34 -34
- package/docs/academy/02-MasteryTrack/03-BuildingUserExperiences/07-Authorization/03-DocumentPermissions.md +387 -0
- package/docs/academy/02-MasteryTrack/05-Launch/02-PublishYourProject.md +118 -184
- package/docs/academy/02-MasteryTrack/05-Launch/03-SetupEnvironment.md +1 -1
- package/docs/academy/02-MasteryTrack/05-Launch/05-DockerDeployment.md +1 -1
- package/docs/academy/02-MasteryTrack/_category_.json +1 -1
- package/docs/academy/03-ExampleUsecases/00-Overview.mdx +60 -0
- package/docs/academy/03-ExampleUsecases/Chatroom/02-CreateNewPowerhouseProject.md +38 -16
- package/docs/academy/03-ExampleUsecases/Chatroom/03-DefineChatroomDocumentModel.md +11 -14
- package/docs/academy/03-ExampleUsecases/Chatroom/04-ImplementOperationReducers.md +12 -95
- package/docs/academy/03-ExampleUsecases/Chatroom/05-ImplementChatroomEditor.md +30 -20
- package/docs/academy/03-ExampleUsecases/Chatroom/{06-LaunchALocalReactor.md → 06-LaunchALocalReactor} +13 -8
- package/docs/academy/03-ExampleUsecases/VetraPackageLibrary/VetraPackageLibrary.md +13 -0
- package/docs/academy/03-ExampleUsecases/_category_.json +9 -0
- package/docs/academy/04-APIReferences/00-PowerhouseCLI.md +168 -15
- package/docs/academy/04-APIReferences/01-ReactHooks.md +7 -0
- package/docs/academy/04-APIReferences/04-RelationalDatabase.md +6 -0
- package/docs/academy/04-APIReferences/renown-sdk/03-CLIIdentity.md +321 -0
- package/docs/academy/05-Architecture/00-PowerhouseArchitecture.md +46 -11
- package/docs/academy/07-Cookbook.md +598 -145
- package/docs/academy/08-Glossary.md +1 -1
- package/docusaurus.config.ts +13 -35
- package/package.json +1 -1
- package/sidebars.ts +11 -11
- package/src/css/custom.css +28 -30
- package/src/theme/DocSidebarItem/Category/index.tsx +47 -0
- package/tsconfig.tsbuildinfo +1 -1
- package/docs/academy/02-MasteryTrack/01-BuilderEnvironment/05-VetraStudio.md +0 -253
- package/docs/academy/02-MasteryTrack/05-Launch/01-IntroductionToPackages.md +0 -78
|
@@ -68,7 +68,7 @@
|
|
|
68
68
|
- **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.
|
|
69
69
|
- **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.
|
|
70
70
|
- **Drive** – A logical container in Powerhouse for storing, organizing, and managing collections of documents.
|
|
71
|
-
- **
|
|
71
|
+
- **drive-app (Custom Drive Explorer)** – A UI application, often custom, providing tailored views and interactions with documents in a Drive.
|
|
72
72
|
- **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).
|
|
73
73
|
- **Host Applications** – Applications that use the Powerhouse framework to create and manage documents and data.
|
|
74
74
|
- **Modules (in Document Model Editor)** – An organizational feature in Connect Studio's model editor for grouping related operations.
|
package/docusaurus.config.ts
CHANGED
|
@@ -86,12 +86,6 @@ const config: Config = {
|
|
|
86
86
|
href: "/",
|
|
87
87
|
},
|
|
88
88
|
items: [
|
|
89
|
-
{
|
|
90
|
-
type: "docSidebar",
|
|
91
|
-
sidebarId: "academySidebar",
|
|
92
|
-
position: "left",
|
|
93
|
-
label: "Academy",
|
|
94
|
-
},
|
|
95
89
|
{
|
|
96
90
|
href: "https://github.com/powerhouse-inc/powerhouse-docs",
|
|
97
91
|
label: "GitHub",
|
|
@@ -106,28 +100,12 @@ const config: Config = {
|
|
|
106
100
|
title: "Docs",
|
|
107
101
|
items: [
|
|
108
102
|
{
|
|
109
|
-
label: "
|
|
110
|
-
to: "academy/Architecture/PowerhouseArchitecture",
|
|
111
|
-
},
|
|
112
|
-
{
|
|
113
|
-
label: "Reactor",
|
|
114
|
-
to: "academy/Architecture/PowerhouseArchitecture",
|
|
115
|
-
},
|
|
116
|
-
{
|
|
117
|
-
label: "Switchboard",
|
|
118
|
-
to: "academy/Architecture/PowerhouseArchitecture",
|
|
119
|
-
},
|
|
120
|
-
{
|
|
121
|
-
label: "Renown",
|
|
122
|
-
to: "academy/Architecture/PowerhouseArchitecture",
|
|
123
|
-
},
|
|
124
|
-
{
|
|
125
|
-
label: "FAQ",
|
|
103
|
+
label: "Powerhouse Architecture",
|
|
126
104
|
to: "academy/Architecture/PowerhouseArchitecture",
|
|
127
105
|
},
|
|
128
106
|
{
|
|
129
|
-
label: "
|
|
130
|
-
to: "/
|
|
107
|
+
label: "Cookbook",
|
|
108
|
+
to: "academy/Cookbook",
|
|
131
109
|
},
|
|
132
110
|
],
|
|
133
111
|
},
|
|
@@ -136,7 +114,7 @@ const config: Config = {
|
|
|
136
114
|
items: [
|
|
137
115
|
{
|
|
138
116
|
label: "Discord",
|
|
139
|
-
href: "https://discord.gg/
|
|
117
|
+
href: "https://discord.gg/pwQJwgaQKd",
|
|
140
118
|
},
|
|
141
119
|
{
|
|
142
120
|
label: "X",
|
|
@@ -162,21 +140,21 @@ const config: Config = {
|
|
|
162
140
|
magicComments: [
|
|
163
141
|
// Default highlight
|
|
164
142
|
{
|
|
165
|
-
className:
|
|
166
|
-
line:
|
|
167
|
-
block: { start:
|
|
143
|
+
className: "theme-code-block-highlighted-line",
|
|
144
|
+
line: "highlight-next-line",
|
|
145
|
+
block: { start: "highlight-start", end: "highlight-end" },
|
|
168
146
|
},
|
|
169
147
|
// Green for additions
|
|
170
148
|
{
|
|
171
|
-
className:
|
|
172
|
-
line:
|
|
173
|
-
block: { start:
|
|
149
|
+
className: "code-block-added-line",
|
|
150
|
+
line: "added-line",
|
|
151
|
+
block: { start: "added-start", end: "added-end" },
|
|
174
152
|
},
|
|
175
153
|
// Red for deletions
|
|
176
154
|
{
|
|
177
|
-
className:
|
|
178
|
-
line:
|
|
179
|
-
block: { start:
|
|
155
|
+
className: "code-block-removed-line",
|
|
156
|
+
line: "removed-line",
|
|
157
|
+
block: { start: "removed-start", end: "removed-end" },
|
|
180
158
|
},
|
|
181
159
|
],
|
|
182
160
|
},
|
package/package.json
CHANGED
package/sidebars.ts
CHANGED
|
@@ -40,8 +40,8 @@ const sidebars = {
|
|
|
40
40
|
},
|
|
41
41
|
items: [
|
|
42
42
|
"academy/MasteryTrack/BuilderEnvironment/Prerequisites",
|
|
43
|
-
"academy/MasteryTrack/BuilderEnvironment/StandardDocumentModelWorkflow",
|
|
44
43
|
"academy/MasteryTrack/BuilderEnvironment/VetraStudio",
|
|
44
|
+
"academy/MasteryTrack/BuilderEnvironment/CreateAPackageWithVetra",
|
|
45
45
|
],
|
|
46
46
|
},
|
|
47
47
|
{
|
|
@@ -118,18 +118,9 @@ const sidebars = {
|
|
|
118
118
|
"academy/ExampleUsecases/Chatroom/DefineChatroomDocumentModel",
|
|
119
119
|
"academy/ExampleUsecases/Chatroom/ImplementOperationReducers",
|
|
120
120
|
"academy/ExampleUsecases/Chatroom/ImplementChatroomEditor",
|
|
121
|
-
"academy/ExampleUsecases/Chatroom/LaunchALocalReactor",
|
|
122
121
|
],
|
|
123
122
|
},
|
|
124
|
-
|
|
125
|
-
type: "category",
|
|
126
|
-
label: "Vetra Package Library",
|
|
127
|
-
link: {
|
|
128
|
-
type: "doc",
|
|
129
|
-
id: "academy/ExampleUsecases/VetraPackageLibrary/VetraPackageLibrary",
|
|
130
|
-
},
|
|
131
|
-
items: [],
|
|
132
|
-
},
|
|
123
|
+
|
|
133
124
|
{
|
|
134
125
|
type: "category",
|
|
135
126
|
label: "Todo List Tutorial",
|
|
@@ -149,6 +140,15 @@ const sidebars = {
|
|
|
149
140
|
"academy/ExampleUsecases/TodoList/AddSharedComponentForShowingTodoListStats",
|
|
150
141
|
],
|
|
151
142
|
},
|
|
143
|
+
{
|
|
144
|
+
type: "category",
|
|
145
|
+
label: "Vetra Package Library",
|
|
146
|
+
link: {
|
|
147
|
+
type: "doc",
|
|
148
|
+
id: "academy/ExampleUsecases/VetraPackageLibrary/VetraPackageLibrary",
|
|
149
|
+
},
|
|
150
|
+
items: [],
|
|
151
|
+
},
|
|
152
152
|
],
|
|
153
153
|
},
|
|
154
154
|
{
|
package/src/css/custom.css
CHANGED
|
@@ -303,41 +303,18 @@ article > a,
|
|
|
303
303
|
|
|
304
304
|
/* Dark mode adjustments */
|
|
305
305
|
[data-theme="dark"] .path-button {
|
|
306
|
-
background-color: #
|
|
307
|
-
border: none;
|
|
308
|
-
|
|
309
|
-
|
|
310
|
-
}
|
|
311
|
-
|
|
312
|
-
/* Gradient border effect - dark mode only */
|
|
313
|
-
[data-theme="dark"] .path-button::before {
|
|
314
|
-
content: "";
|
|
315
|
-
position: absolute;
|
|
316
|
-
top: 0;
|
|
317
|
-
right: 0;
|
|
318
|
-
bottom: 0;
|
|
319
|
-
left: 0;
|
|
320
|
-
border-radius: 8px;
|
|
321
|
-
padding: 1px; /* Border width */
|
|
322
|
-
background: linear-gradient(90deg, #4633eb, #7a5cff);
|
|
323
|
-
-webkit-mask:
|
|
324
|
-
linear-gradient(#fff 0 0) content-box,
|
|
325
|
-
linear-gradient(#fff 0 0);
|
|
326
|
-
mask:
|
|
327
|
-
linear-gradient(#fff 0 0) content-box,
|
|
328
|
-
linear-gradient(#fff 0 0);
|
|
329
|
-
-webkit-mask-composite: xor;
|
|
330
|
-
mask-composite: exclude;
|
|
331
|
-
pointer-events: none;
|
|
306
|
+
background-color: #374151;
|
|
307
|
+
border: none !important;
|
|
308
|
+
color: #ffffff !important;
|
|
309
|
+
text-decoration: none !important;
|
|
332
310
|
}
|
|
333
311
|
|
|
334
312
|
/* Hover effects - dark mode */
|
|
335
313
|
[data-theme="dark"] .path-button:hover {
|
|
314
|
+
background-color: #4b5563;
|
|
336
315
|
transform: translateY(-2px);
|
|
337
|
-
|
|
338
|
-
|
|
339
|
-
[data-theme="dark"] .path-button:hover::before {
|
|
340
|
-
box-shadow: 0 0 15px rgba(74, 51, 235, 0.3); /* Subtle blue glow */
|
|
316
|
+
color: #ffffff !important;
|
|
317
|
+
text-decoration: none !important;
|
|
341
318
|
}
|
|
342
319
|
|
|
343
320
|
.path-card {
|
|
@@ -553,3 +530,24 @@ html[data-theme="dark"] .DocSearch-Hits > *:empty {
|
|
|
553
530
|
background-color: rgba(248, 81, 73, 0.25);
|
|
554
531
|
}
|
|
555
532
|
|
|
533
|
+
/* Sidebar item count badge */
|
|
534
|
+
.sidebar-item-count {
|
|
535
|
+
display: inline-flex;
|
|
536
|
+
align-items: center;
|
|
537
|
+
justify-content: center;
|
|
538
|
+
margin-left: 8px;
|
|
539
|
+
padding: 0 6px;
|
|
540
|
+
min-width: 20px;
|
|
541
|
+
height: 18px;
|
|
542
|
+
font-size: 11px;
|
|
543
|
+
font-weight: 600;
|
|
544
|
+
color: var(--ifm-color-emphasis-700);
|
|
545
|
+
background-color: var(--ifm-color-emphasis-200);
|
|
546
|
+
border-radius: 10px;
|
|
547
|
+
}
|
|
548
|
+
|
|
549
|
+
[data-theme="dark"] .sidebar-item-count {
|
|
550
|
+
color: var(--ifm-color-emphasis-300);
|
|
551
|
+
background-color: var(--ifm-color-emphasis-700);
|
|
552
|
+
}
|
|
553
|
+
|
|
@@ -0,0 +1,47 @@
|
|
|
1
|
+
import type { PropSidebarItem } from "@docusaurus/plugin-content-docs";
|
|
2
|
+
import type { WrapperProps } from "@docusaurus/types";
|
|
3
|
+
import Category from "@theme-original/DocSidebarItem/Category";
|
|
4
|
+
import type CategoryType from "@theme/DocSidebarItem/Category";
|
|
5
|
+
import React from "react";
|
|
6
|
+
|
|
7
|
+
type Props = WrapperProps<typeof CategoryType>;
|
|
8
|
+
|
|
9
|
+
// Count only immediate children (docs, links, and categories)
|
|
10
|
+
function countItems(items: PropSidebarItem[]): number {
|
|
11
|
+
let count = 0;
|
|
12
|
+
for (const item of items) {
|
|
13
|
+
if (
|
|
14
|
+
// @ts-expect-error TODO: check this type
|
|
15
|
+
item.type === "doc" ||
|
|
16
|
+
item.type === "link" ||
|
|
17
|
+
item.type === "category"
|
|
18
|
+
) {
|
|
19
|
+
count += 1;
|
|
20
|
+
}
|
|
21
|
+
}
|
|
22
|
+
return count;
|
|
23
|
+
}
|
|
24
|
+
|
|
25
|
+
export default function CategoryWrapper(props: Props): React.JSX.Element {
|
|
26
|
+
const { item, level } = props;
|
|
27
|
+
|
|
28
|
+
// Only show count on top-level categories (level 1)
|
|
29
|
+
if (level !== 1) {
|
|
30
|
+
return <Category {...props} />;
|
|
31
|
+
}
|
|
32
|
+
|
|
33
|
+
const itemCount = countItems(item.items);
|
|
34
|
+
|
|
35
|
+
// Clone the item with a modified label that includes the count
|
|
36
|
+
const modifiedItem = {
|
|
37
|
+
...item,
|
|
38
|
+
label: (
|
|
39
|
+
<>
|
|
40
|
+
{item.label}
|
|
41
|
+
<span className="sidebar-item-count">{itemCount}</span>
|
|
42
|
+
</>
|
|
43
|
+
) as unknown as string,
|
|
44
|
+
};
|
|
45
|
+
|
|
46
|
+
return <Category {...props} item={modifiedItem} />;
|
|
47
|
+
}
|
package/tsconfig.tsbuildinfo
CHANGED
|
@@ -1 +1 @@
|
|
|
1
|
-
{"root":["./babel.config.js","./docusaurus.config.ts","./sidebars.ts","./scripts/generate-combined-cli-docs.ts","./src/components/HomepageFeatures/index.tsx","./src/pages/_archive-homepage.tsx","./src/theme/DocCardList/index.tsx"],"version":"5.9.3"}
|
|
1
|
+
{"root":["./babel.config.js","./docusaurus.config.ts","./sidebars.ts","./scripts/generate-combined-cli-docs.ts","./src/components/HomepageFeatures/index.tsx","./src/pages/_archive-homepage.tsx","./src/theme/DocCardList/index.tsx","./src/theme/DocSidebarItem/Category/index.tsx"],"version":"5.9.3"}
|
|
@@ -1,253 +0,0 @@
|
|
|
1
|
-
# Vetra Studio
|
|
2
|
-
|
|
3
|
-
## Introducing Vetra Studio
|
|
4
|
-
|
|
5
|
-
- **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
|
|
6
|
-
- **Vetra Package Library**: Store, publish and fork git repositories of packages in the Vetra Package Library.
|
|
7
|
-
Visit the [Vetra Package Library here](https://vetra.io/packages)
|
|
8
|
-
|
|
9
|
-
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.
|
|
10
|
-
For now the specification documents offer you a template for code generation.
|
|
11
|
-
|
|
12
|
-
<figure className="image-container">
|
|
13
|
-
<img
|
|
14
|
-
src={require("./images/Modules.png").default}
|
|
15
|
-
alt="Modules"
|
|
16
|
-
/>
|
|
17
|
-
<figcaption>The list of available modules color coded according to the 3 categories.</figcaption>
|
|
18
|
-
</figure>
|
|
19
|
-
|
|
20
|
-
### Module Categories
|
|
21
|
-
|
|
22
|
-
### 1. Document Models
|
|
23
|
-
- **Document model specification**: Defines the structure and operations of a document model using GraphQL SDL, ensuring consistent data management and processing.
|
|
24
|
-
|
|
25
|
-
### 2. User Experiences
|
|
26
|
-
- **Editor specification**: Outlines the interface and functionalities of a document model editor, allowing users to interact with and modify document data.
|
|
27
|
-
- **Drive-app specification**: Specifies the UI and interactions for managing documents within a Drive, providing tailored views and functionalities.
|
|
28
|
-
|
|
29
|
-
### 3. Data integrations
|
|
30
|
-
- **Subgraph specification**: Details the connections and relationships within a subgraph, facilitating efficient data querying and manipulation.
|
|
31
|
-
- **Codegen Processor Specification**: Describes the process for automatically generating code from document model specifications, ensuring alignment with intended architecture.
|
|
32
|
-
- **RelationalDb Processor Specification**: Defines how relational databases are structured and queried, supporting efficient data management and retrieval.
|
|
33
|
-
|
|
34
|
-
<figure className="image-container">
|
|
35
|
-
<img
|
|
36
|
-
src={require("./images/VetraStudioDrive.png").default}
|
|
37
|
-
alt="Vetra Studio Drive"
|
|
38
|
-
/>
|
|
39
|
-
<figcaption>The Vetra Studio Drive, a builder app that collects all of the specification of a package.</figcaption>
|
|
40
|
-
</figure>
|
|
41
|
-
|
|
42
|
-
### Configure a Vetra drive in your project
|
|
43
|
-
|
|
44
|
-
You can connect to a remote vetra drive instead of using the local one auto-generated when you run `ph vetra`
|
|
45
|
-
If you run Vetra without the `--remote-drive` option: Vetra will create a Vetra drive for you that is local and lives in your local environment / local browser storage.
|
|
46
|
-
If you provide the remote drive with `--remote-drive` argument: Vetra will use this drive instead of creating a local one. the remote drive can be hosted whatever you want.
|
|
47
|
-
The powerhouse config includes a Vetra URL for consistent project configuration across different environments.
|
|
48
|
-
|
|
49
|
-
```vetra: {
|
|
50
|
-
driveId: string;
|
|
51
|
-
driveUrl: string;
|
|
52
|
-
};
|
|
53
|
-
```
|
|
54
|
-
|
|
55
|
-
Imagine you are a builder and want to work on, or continue with a set of specifications from your team mates.
|
|
56
|
-
You could then add the specific remote Vetra drive to your powerhouse configuration in the `powerhouse.config.json`file to get going.
|
|
57
|
-
|
|
58
|
-
```
|
|
59
|
-
"vetra": {
|
|
60
|
-
"driveId": "bai-specifications",
|
|
61
|
-
"driveUrl": "https://switchboard.staging.vetra.io/d/bai-specifications"
|
|
62
|
-
}
|
|
63
|
-
```
|
|
64
|
-
|
|
65
|
-
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)
|
|
66
|
-
|
|
67
|
-
<details>
|
|
68
|
-
<summary>📦 Vetra Remote Drive Commands</summary>
|
|
69
|
-
|
|
70
|
-
Remote drives enable collaborative development by syncing specifications across team members.
|
|
71
|
-
|
|
72
|
-
**Key Commands:**
|
|
73
|
-
- `ph init --remote-drive <url>` - Create a NEW project connected to a remote drive
|
|
74
|
-
- `ph checkout --remote-drive <url>` - Clone an EXISTING project from a remote drive
|
|
75
|
-
- `ph vetra --watch` - Start development with a preview drive for testing local changes
|
|
76
|
-
|
|
77
|
-
**Workflows:**
|
|
78
|
-
- **Project Owner**: `ph init --remote-drive` → Create GitHub repo → Push → `ph vetra` to configure
|
|
79
|
-
- **Collaborator**: `ph checkout --remote-drive` → `ph vetra` to start developing
|
|
80
|
-
|
|
81
|
-
**Preview Drive (`--watch` mode):**
|
|
82
|
-
- Main "Vetra" drive syncs with remote and contains stable package configuration
|
|
83
|
-
- "Vetra Preview" drive is created locally for testing document models before syncing
|
|
84
|
-
|
|
85
|
-
→ [Full Vetra Remote Drive Reference](/academy/APIReferences/VetraRemoteDrive)
|
|
86
|
-
|
|
87
|
-
</details>
|
|
88
|
-
|
|
89
|
-
## Vetra Studio Workflow
|
|
90
|
-
|
|
91
|
-
### 1. Launch Vetra Studio
|
|
92
|
-
|
|
93
|
-
You can launch Vetra Studio in two modes:
|
|
94
|
-
|
|
95
|
-
#### Interactive Mode (Recommended for Development)
|
|
96
|
-
```bash
|
|
97
|
-
ph vetra --interactive
|
|
98
|
-
```
|
|
99
|
-
In interactive mode:
|
|
100
|
-
- You'll receive confirmation prompts before any code generation
|
|
101
|
-
- Changes require explicit confirmation before being processed
|
|
102
|
-
- Provides better control and visibility over document changes
|
|
103
|
-
|
|
104
|
-
#### Watch Mode
|
|
105
|
-
|
|
106
|
-
```bash
|
|
107
|
-
ph vetra --interactive --watch
|
|
108
|
-
```
|
|
109
|
-
In watch mode:
|
|
110
|
-
|
|
111
|
-
- Adding `--watch` to your command enables dynamic loading for document-models and editors in Vetra studio and switchboard.
|
|
112
|
-
- When enabled, the system will watch for changes in these directories and reload them dynamically.
|
|
113
|
-
|
|
114
|
-
:::warning Be Aware
|
|
115
|
-
When you are building your document model the code can break the Vetra Studio environment.
|
|
116
|
-
A full overview of the Vetra Studio commands can be found in the [Powerhouse CLI](/academy/APIReferences/PowerhouseCLI#vetra)
|
|
117
|
-
:::
|
|
118
|
-
|
|
119
|
-
#### Standard Mode
|
|
120
|
-
```bash
|
|
121
|
-
ph vetra
|
|
122
|
-
```
|
|
123
|
-
In standard mode:
|
|
124
|
-
- Changes are processed automatically with 1-second debounce
|
|
125
|
-
- Multiple changes are batched and processed together
|
|
126
|
-
- Uses the latest document state for processing
|
|
127
|
-
|
|
128
|
-
### 2. Launch Claude with Reactor-MCP
|
|
129
|
-
|
|
130
|
-
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.
|
|
131
|
-
|
|
132
|
-
<details>
|
|
133
|
-
<summary>**Specification Driven AI**</summary>
|
|
134
|
-
|
|
135
|
-
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.
|
|
136
|
-
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**.
|
|
137
|
-
|
|
138
|
-
- Communicate your solution and intent through a structured specification framework designed for AI collaboration.
|
|
139
|
-
- Specifications enable precise, iterative edits, since all our specification documents are machine-readable and executable.
|
|
140
|
-
|
|
141
|
-
</details>
|
|
142
|
-
|
|
143
|
-
#### 1. Start the Reactor MCP:
|
|
144
|
-
|
|
145
|
-
Make sure you are in the same directory as your project.
|
|
146
|
-
Claude will automatically recognize the necessary files and MCP tools.
|
|
147
|
-
|
|
148
|
-
```bash
|
|
149
|
-
claude
|
|
150
|
-
```
|
|
151
|
-
|
|
152
|
-
Since you're interacting with a llm it has a high capacit for interpretating your intentions.
|
|
153
|
-
Any commands in the same trend will do the job.
|
|
154
|
-
|
|
155
|
-
```bash
|
|
156
|
-
connect to the reactor mcp
|
|
157
|
-
```
|
|
158
|
-
|
|
159
|
-
#### 2. Verify MCP connection:
|
|
160
|
-
- Check that the Reactor MCP is available.
|
|
161
|
-
- Confirm Vetra Studio shows "Connected to Reactor MCP"
|
|
162
|
-
|
|
163
|
-
```bash
|
|
164
|
-
Connected to MCP successfully! I can see there's a
|
|
165
|
-
"vetra-4de7fa45" drive available. The reactor-mcp server is
|
|
166
|
-
running and ready for document model operations.
|
|
167
|
-
```
|
|
168
|
-
|
|
169
|
-
<details>
|
|
170
|
-
<summary>🤖 Reactor MCP Overview</summary>
|
|
171
|
-
|
|
172
|
-
### Key Reactor MCP Features
|
|
173
|
-
|
|
174
|
-
**Reactor-mcp** is a Model Context Protocol (MCP) server that bridges AI agents with Powerhouse document operations.
|
|
175
|
-
|
|
176
|
-
- It supports automatic document model creation from natural language descriptions
|
|
177
|
-
- It implements a smart editor based on the underlying document models
|
|
178
|
-
- It automatically triggers code generation when documents reach valid state
|
|
179
|
-
- The MCP server enables the agent to work with both existing and newly created document models
|
|
180
|
-
- Vetra supports integration with custom remote drives, allowing users to create, share and manage documents within these drives
|
|
181
|
-
|
|
182
|
-
**Document Operations:**
|
|
183
|
-
- `createDocument` / `getDocument` / `deleteDocument` - Manage documents
|
|
184
|
-
- `addActions` - Modify document state through operations
|
|
185
|
-
|
|
186
|
-
**Drive Operations:**
|
|
187
|
-
- `getDrives` / `addDrive` / `getDrive` - Manage document drives
|
|
188
|
-
- `addRemoteDrive` - Connect to remote drives
|
|
189
|
-
|
|
190
|
-
**Document Model Operations:**
|
|
191
|
-
- `getDocumentModels` - List available document model types
|
|
192
|
-
- `getDocumentModelSchema` - Get schema for specific models
|
|
193
|
-
|
|
194
|
-
**Document Model Agent:**
|
|
195
|
-
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.
|
|
196
|
-
|
|
197
|
-
</details>
|
|
198
|
-
|
|
199
|
-
|
|
200
|
-
### 3. Vetra Studio Package Creation Workflow
|
|
201
|
-
|
|
202
|
-
#### A. Set Package Description (Required)
|
|
203
|
-
1. Provide a name for your package
|
|
204
|
-
2. Add a meaningful description
|
|
205
|
-
3. Add keywords to add search terms to your package
|
|
206
|
-
4. Confirm changes when prompted in interactive mode
|
|
207
|
-
|
|
208
|
-
#### B. Define Document Model (Required)
|
|
209
|
-
You can create document models in two ways:
|
|
210
|
-
|
|
211
|
-
1. **Using MCP (AI-Assisted)**
|
|
212
|
-
- Describe your document needs in natural language in great detail.
|
|
213
|
-
- Claude will:
|
|
214
|
-
- Generate an appropriate schema
|
|
215
|
-
- Create the necessary operations
|
|
216
|
-
- Implement the required reducers
|
|
217
|
-
- Place the document in the Vetra drive
|
|
218
|
-
|
|
219
|
-
2. **Manual Creation**
|
|
220
|
-
- Define document schema with fields and types as in the **'Get Started'**
|
|
221
|
-
- Create the necessary operations
|
|
222
|
-
- Add the required modules to your package
|
|
223
|
-
- The document model creation chapter in the Mastery track provides in depth support [here](apps/academy/docs/academy/MasteryTrack/DocumentModelCreation/SpecifyTheStateSchema)
|
|
224
|
-
|
|
225
|
-
#### C. Add Document Editor (Required)
|
|
226
|
-
1. **Using MCP (AI-Assisted)**
|
|
227
|
-
- Request Claude to create an editor for your document. Do this with the help of a detailed description of the user interface, user experience and logic that you wish to generate. Make sure to reference operations from the document model to get the best results
|
|
228
|
-
- Claude will:
|
|
229
|
-
- Generate editor components
|
|
230
|
-
- Implement necessary hooks
|
|
231
|
-
- Create required UI elements
|
|
232
|
-
|
|
233
|
-
2. **Manual Creation**
|
|
234
|
-
- Select your target document model
|
|
235
|
-
- Configure the currently limited editor properties
|
|
236
|
-
- Add the editor specification to Vetra Studio drive
|
|
237
|
-
- The system will generate scaffolding code
|
|
238
|
-
|
|
239
|
-
#### D. Data Integrations (Coming Soon)
|
|
240
|
-
Support for:
|
|
241
|
-
- Subgraph integration
|
|
242
|
-
- Code generation processors
|
|
243
|
-
- Relational database processors
|
|
244
|
-
|
|
245
|
-
### Best Practices
|
|
246
|
-
|
|
247
|
-
**Working with MCP and claude**
|
|
248
|
-
- Provide clear, specific instructions and ask for clarifying questions to be answered before code generation.
|
|
249
|
-
- Review generated schemas before confirmation and work in layers instead of 'one-shotting' your code.
|
|
250
|
-
- Verify implementation details in generated code before continuing.
|
|
251
|
-
- Always double-check proposed next actions
|
|
252
|
-
|
|
253
|
-
|
|
@@ -1,78 +0,0 @@
|
|
|
1
|
-
# Introduction to packages
|
|
2
|
-
|
|
3
|
-
Packages of document models are a core structuring mechanism in the Powerhouse framework, allowing developers to group and manage related document models efficiently. These packages serve as modular collections of document definitions, ensuring consistency, scalability, and reusability across different applications.
|
|
4
|
-
|
|
5
|
-
By packaging document models together, developers can create well-organized, interoperable sets of data structures that capture the specific needs of various operational processes. Whether used for financial operations, governance, or contributor management, these packages streamline development and integration within Powerhouse's decentralized framework.
|
|
6
|
-
|
|
7
|
-
### Key features of packages
|
|
8
|
-
|
|
9
|
-
- **Modular Structure** – Packages encapsulate related document models, making it easier to manage and deploy them as a cohesive unit.
|
|
10
|
-
- **Standardized Definitions** – Each document model within a package follows Powerhouse's structured schema approach, ensuring consistency in data representation.
|
|
11
|
-
- **Reusability and Extensibility** – Packages can be shared across different projects or extended with additional models as needed.
|
|
12
|
-
- **Dependency Management** – Developers can define dependencies between document models, ensuring proper relationships and data flows between interconnected components.
|
|
13
|
-
- **Automated Schema Evolution** – Versioning mechanisms allow document models within a package to evolve over time without breaking existing functionality.
|
|
14
|
-
|
|
15
|
-
### Example use cases of packages
|
|
16
|
-
|
|
17
|
-
- **Finance Package** – A set of document models handling invoices, payments, budgets, and financial reporting. link
|
|
18
|
-
- **Contributor Billing Package** – Defines document models for tracking work, invoicing, and facilitating payments (in both fiat and crypto) for contributors in decentralized organizations. link
|
|
19
|
-
- **Governance Package** – Models for proposals, voting, contributor agreements, and decision-making processes. link
|
|
20
|
-
- **People Ops Package** – Documents managing contributor profiles, roles, task assignments, and reputation tracking. link
|
|
21
|
-
- **Project Management Package** – Models for task tracking, milestones, resource allocation, and deliverables. link
|
|
22
|
-
|
|
23
|
-
A **Powerhouse Package** is a **modular unit** that defines and automates **data structures and workflows** within the Powerhouse ecosystem. Each package includes several components that work together to ensure **seamless interaction, data processing, and automation** for different areas of decentralized operations.
|
|
24
|
-
|
|
25
|
-
Packages follow a **scoped naming convention** based on the organization that owns them or created the package:
|
|
26
|
-
|
|
27
|
-
- `@powerhousedao` The organization behind Powerhouse.
|
|
28
|
-
- `@sky-ph` The Sky / MakerDAO organization with a -ph suffix to indicate it concerns Powerhouse ecosystem packages.
|
|
29
|
-
- `@myorg-ph` Your organization with the -ph suffix included.
|
|
30
|
-
|
|
31
|
-
Within a package, you'll find **several key modules**, each serving a distinct role in structuring and processing data.
|
|
32
|
-
|
|
33
|
-
---
|
|
34
|
-
|
|
35
|
-
## Modules of a Powerhouse package
|
|
36
|
-
|
|
37
|
-
### 1. Document model
|
|
38
|
-
|
|
39
|
-
The **core component** of any package, defining how data is structured and manipulated.
|
|
40
|
-
|
|
41
|
-
- Specifies **schemas** (data structures) and **state transitions** (operations).
|
|
42
|
-
- Serves as the foundation for decentralized workflows.
|
|
43
|
-
- **Example:** An **Invoice** document model might define fields like `issuer`, `recipient`, `amount`, and operations like `ADD_LINE_ITEM` or `MARK_AS_PAID`.
|
|
44
|
-
|
|
45
|
-
### 2. Document model editor
|
|
46
|
-
|
|
47
|
-
A **UI component** that allows users to **interact with document models visually**.
|
|
48
|
-
|
|
49
|
-
- Enables users to **create, modify, and manage** documents without coding.
|
|
50
|
-
- Supports multiple editors for a single document model, offering different **UI experiences** tailored to specific roles.
|
|
51
|
-
|
|
52
|
-
### 3. Scripts
|
|
53
|
-
|
|
54
|
-
**Automated actions** that run on demand or on a schedule.
|
|
55
|
-
|
|
56
|
-
- Executes **one-time or recurring tasks** within a package.
|
|
57
|
-
- Not continuously running—activated manually or at predefined intervals.
|
|
58
|
-
- **Example:** A script that **generates a weekly financial report** from invoice data.
|
|
59
|
-
|
|
60
|
-
### 4. Processors
|
|
61
|
-
|
|
62
|
-
**Event-driven background tasks** that react to document changes.
|
|
63
|
-
|
|
64
|
-
- Subscribes to **document operations or system events** and processes data automatically.
|
|
65
|
-
- Supports real-time **data updates, analytics, and workflow automation**.
|
|
66
|
-
- **Example:** A processor that **monitors new invoices** and updates an **analytics dashboard** in real-time.
|
|
67
|
-
|
|
68
|
-
### 5. Drive-apps
|
|
69
|
-
|
|
70
|
-
**Custom interfaces** that provide enhanced ways to interact with a package's document models.
|
|
71
|
-
|
|
72
|
-
- Allows **visualization, sorting, and organization** of drive contents (e.g., **Kanban boards, list views**).
|
|
73
|
-
- Can aggregate data and display **key insights** from document models.
|
|
74
|
-
- **Example:** A Drive-App for **People Ops** might show a **dashboard of contributor profiles, role assignments, and activity logs**.
|
|
75
|
-
|
|
76
|
-
---
|
|
77
|
-
|
|
78
|
-
Each of these modules plays a crucial role in making **Powerhouse Packages extensible, reusable, and efficient**, allowing developers and organizations to **streamline operations and automate workflows** within decentralized environments.
|