@powerhousedao/academy 5.0.0-staging.9 → 5.0.0

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.
Files changed (108) hide show
  1. package/.vscode/settings.json +1 -1
  2. package/CHANGELOG.md +17 -451
  3. package/README.md +3 -3
  4. package/babel.config.js +1 -1
  5. package/blog/BeyondCommunication-ABlueprintForDevelopment.md +25 -24
  6. package/blog/TheChallengeOfChange.md +21 -21
  7. package/docs/academy/01-GetStarted/00-ExploreDemoPackage.mdx +67 -30
  8. package/docs/academy/01-GetStarted/01-CreateNewPowerhouseProject.md +38 -21
  9. package/docs/academy/01-GetStarted/02-DefineToDoListDocumentModel.md +24 -19
  10. package/docs/academy/01-GetStarted/03-ImplementOperationReducers.md +44 -41
  11. package/docs/academy/01-GetStarted/04-BuildToDoListEditor.md +10 -10
  12. package/docs/academy/01-GetStarted/05-VetraStudio.md +164 -0
  13. package/docs/academy/01-GetStarted/06-ReactorMCP.md +58 -0
  14. package/docs/academy/01-GetStarted/home.mdx +185 -90
  15. package/docs/academy/01-GetStarted/images/Modules.png +0 -0
  16. package/docs/academy/01-GetStarted/images/VetraStudioDrive.png +0 -0
  17. package/docs/academy/01-GetStarted/styles.module.css +5 -5
  18. package/docs/academy/02-MasteryTrack/01-BuilderEnvironment/01-Prerequisites.md +46 -18
  19. package/docs/academy/02-MasteryTrack/01-BuilderEnvironment/02-StandardDocumentModelWorkflow.md +118 -68
  20. package/docs/academy/02-MasteryTrack/01-BuilderEnvironment/03-BuilderTools.md +75 -33
  21. package/docs/academy/02-MasteryTrack/01-BuilderEnvironment/_category_.json +6 -6
  22. package/docs/academy/02-MasteryTrack/02-DocumentModelCreation/01-WhatIsADocumentModel.md +30 -21
  23. package/docs/academy/02-MasteryTrack/02-DocumentModelCreation/02-SpecifyTheStateSchema.md +41 -37
  24. package/docs/academy/02-MasteryTrack/02-DocumentModelCreation/03-SpecifyDocumentOperations.md +29 -25
  25. package/docs/academy/02-MasteryTrack/02-DocumentModelCreation/04-UseTheDocumentModelGenerator.md +36 -37
  26. package/docs/academy/02-MasteryTrack/02-DocumentModelCreation/05-ImplementDocumentReducers.md +128 -109
  27. package/docs/academy/02-MasteryTrack/02-DocumentModelCreation/06-ImplementDocumentModelTests.md +95 -86
  28. package/docs/academy/02-MasteryTrack/02-DocumentModelCreation/07-ExampleToDoListRepository.md +7 -9
  29. package/docs/academy/02-MasteryTrack/02-DocumentModelCreation/_category_.json +6 -6
  30. package/docs/academy/02-MasteryTrack/03-BuildingUserExperiences/01-BuildingDocumentEditors.md +65 -47
  31. package/docs/academy/02-MasteryTrack/03-BuildingUserExperiences/02-ConfiguringDrives.md +77 -62
  32. package/docs/academy/02-MasteryTrack/03-BuildingUserExperiences/03-BuildingADriveExplorer.md +360 -349
  33. package/docs/academy/02-MasteryTrack/03-BuildingUserExperiences/06-DocumentTools/00-DocumentToolbar.mdx +16 -10
  34. package/docs/academy/02-MasteryTrack/03-BuildingUserExperiences/06-DocumentTools/01-OperationHistory.md +10 -7
  35. package/docs/academy/02-MasteryTrack/03-BuildingUserExperiences/06-DocumentTools/02-RevisionHistoryTimeline.md +25 -17
  36. package/docs/academy/02-MasteryTrack/03-BuildingUserExperiences/06-DocumentTools/_category_.json +6 -6
  37. package/docs/academy/02-MasteryTrack/03-BuildingUserExperiences/07-Authorization/01-RenownAuthenticationFlow.md +14 -7
  38. package/docs/academy/02-MasteryTrack/03-BuildingUserExperiences/07-Authorization/02-Authorization.md +0 -1
  39. package/docs/academy/02-MasteryTrack/03-BuildingUserExperiences/07-Authorization/_category_.json +5 -5
  40. package/docs/academy/02-MasteryTrack/03-BuildingUserExperiences/_category_.json +1 -1
  41. package/docs/academy/02-MasteryTrack/04-WorkWithData/01-GraphQLAtPowerhouse.md +45 -33
  42. package/docs/academy/02-MasteryTrack/04-WorkWithData/02-UsingTheAPI.mdx +61 -18
  43. package/docs/academy/02-MasteryTrack/04-WorkWithData/03-UsingSubgraphs.md +50 -54
  44. package/docs/academy/02-MasteryTrack/04-WorkWithData/04-analytics-processor.md +126 -110
  45. package/docs/academy/02-MasteryTrack/04-WorkWithData/05-RelationalDbProcessor.md +75 -45
  46. package/docs/academy/02-MasteryTrack/04-WorkWithData/06-Analytics Engine/GraphQL References/QueryingADocumentWithGraphQL.md +23 -21
  47. package/docs/academy/02-MasteryTrack/04-WorkWithData/06-Analytics Engine/best-practices.md +9 -9
  48. package/docs/academy/02-MasteryTrack/04-WorkWithData/06-Analytics Engine/graphql/index.md +11 -23
  49. package/docs/academy/02-MasteryTrack/04-WorkWithData/06-Analytics Engine/graphql/integration.md +25 -9
  50. package/docs/academy/02-MasteryTrack/04-WorkWithData/06-Analytics Engine/intro.md +10 -10
  51. package/docs/academy/02-MasteryTrack/04-WorkWithData/06-Analytics Engine/typescript/benchmarks.md +1 -1
  52. package/docs/academy/02-MasteryTrack/04-WorkWithData/06-Analytics Engine/typescript/index.md +16 -11
  53. package/docs/academy/02-MasteryTrack/04-WorkWithData/06-Analytics Engine/typescript/memory.md +6 -5
  54. package/docs/academy/02-MasteryTrack/04-WorkWithData/06-Analytics Engine/typescript/schema.md +2 -2
  55. package/docs/academy/02-MasteryTrack/04-WorkWithData/06-Analytics Engine/typescript/utilities.md +7 -5
  56. package/docs/academy/02-MasteryTrack/04-WorkWithData/06-Analytics Engine/use-cases/maker.md +32 -58
  57. package/docs/academy/02-MasteryTrack/04-WorkWithData/06-Analytics Engine/use-cases/processors.md +1 -1
  58. package/docs/academy/02-MasteryTrack/04-WorkWithData/07-drive-analytics.md +105 -71
  59. package/docs/academy/02-MasteryTrack/04-WorkWithData/_ARCHIVE-AnalyticsProcessorTutorial/_01-SetupBuilderEnvironment.md +22 -0
  60. package/docs/academy/02-MasteryTrack/04-WorkWithData/_ARCHIVE-AnalyticsProcessorTutorial/_02-CreateNewPowerhouseProject.md +9 -8
  61. package/docs/academy/02-MasteryTrack/04-WorkWithData/_ARCHIVE-AnalyticsProcessorTutorial/_03-GenerateAnAnalyticsProcessor.md +28 -32
  62. package/docs/academy/02-MasteryTrack/04-WorkWithData/_ARCHIVE-AnalyticsProcessorTutorial/_04-UpdateAnalyticsProcessor.md +25 -26
  63. package/docs/academy/02-MasteryTrack/04-WorkWithData/_ARCHIVE-AnalyticsProcessorTutorial/_category_.json +1 -1
  64. package/docs/academy/02-MasteryTrack/04-WorkWithData/_category_.json +7 -7
  65. package/docs/academy/02-MasteryTrack/05-Launch/01-IntroductionToPackages.md +3 -4
  66. package/docs/academy/02-MasteryTrack/05-Launch/02-PublishYourProject.md +69 -45
  67. package/docs/academy/02-MasteryTrack/05-Launch/03-SetupEnvironment.md +70 -40
  68. package/docs/academy/02-MasteryTrack/05-Launch/04-ConfigureEnvironment.md +1 -0
  69. package/docs/academy/02-MasteryTrack/05-Launch/_category_.json +7 -7
  70. package/docs/academy/02-MasteryTrack/_category_.json +6 -6
  71. package/docs/academy/03-ExampleUsecases/Chatroom/02-CreateNewPowerhouseProject.md +5 -3
  72. package/docs/academy/03-ExampleUsecases/Chatroom/03-DefineChatroomDocumentModel.md +38 -37
  73. package/docs/academy/03-ExampleUsecases/Chatroom/04-ImplementOperationReducers.md +45 -41
  74. package/docs/academy/03-ExampleUsecases/Chatroom/05-ImplementChatroomEditor.md +14 -14
  75. package/docs/academy/03-ExampleUsecases/Chatroom/06-LaunchALocalReactor.md +6 -6
  76. package/docs/academy/03-ExampleUsecases/Chatroom/_category_.json +1 -1
  77. package/docs/academy/04-APIReferences/00-PowerhouseCLI.md +104 -43
  78. package/docs/academy/04-APIReferences/01-ReactHooks.md +177 -129
  79. package/docs/academy/04-APIReferences/04-RelationalDatabase.md +121 -113
  80. package/docs/academy/04-APIReferences/05-PHDocumentMigrationGuide.md +48 -41
  81. package/docs/academy/04-APIReferences/_category_.json +6 -6
  82. package/docs/academy/05-Architecture/00-PowerhouseArchitecture.md +1 -2
  83. package/docs/academy/05-Architecture/01-WorkingWithTheReactor.md +11 -8
  84. package/docs/academy/05-Architecture/05-DocumentModelTheory/_category_.json +1 -1
  85. package/docs/academy/05-Architecture/_category_.json +6 -6
  86. package/docs/academy/06-ComponentLibrary/00-DocumentEngineering.md +25 -23
  87. package/docs/academy/06-ComponentLibrary/02-CreateCustomScalars.md +105 -93
  88. package/docs/academy/06-ComponentLibrary/03-IntegrateIntoAReactComponent.md +1 -0
  89. package/docs/academy/06-ComponentLibrary/_category_.json +7 -7
  90. package/docs/academy/07-Cookbook.md +268 -35
  91. package/docs/academy/08-Glossary.md +7 -1
  92. package/docs/bookofpowerhouse/01-Overview.md +2 -2
  93. package/docs/bookofpowerhouse/02-GeneralFrameworkAndPhilosophy.md +1 -7
  94. package/docs/bookofpowerhouse/03-PowerhouseSoftwareArchitecture.md +10 -7
  95. package/docs/bookofpowerhouse/04-DevelopmentApproaches.md +10 -4
  96. package/docs/bookofpowerhouse/05-SNOsandANewModelForOSSandPublicGoods.md +23 -30
  97. package/docs/bookofpowerhouse/06-SNOsInActionAndPlatformEconomies.md +0 -7
  98. package/docusaurus.config.ts +64 -66
  99. package/package.json +9 -7
  100. package/scripts/generate-combined-cli-docs.ts +43 -13
  101. package/sidebars.ts +2 -0
  102. package/src/components/HomepageFeatures/index.tsx +171 -78
  103. package/src/components/HomepageFeatures/styles.module.css +1 -2
  104. package/src/css/custom.css +89 -89
  105. package/src/pages/_archive-homepage.tsx +17 -16
  106. package/src/theme/DocCardList/index.tsx +9 -8
  107. package/static.json +6 -6
  108. package/tsconfig.tsbuildinfo +1 -0
@@ -1,6 +1,6 @@
1
1
  # Implement the document model
2
2
 
3
- In this section, we will implement and test the operation reducers for the **To-do List** document model. For this, you have to export the document model specification from the Connect application and import it into your Powerhouse project directory.
3
+ In this section, we will implement and test the operation reducers for the **To-do List** document model. For this, you have to export the document model specification from the Connect application and import it into your Powerhouse project directory.
4
4
 
5
5
  To export the document model specification, follow the steps in the [Define ToDoList Document Model](/academy/GetStarted/DefineToDoListDocumentModel) section.
6
6
 
@@ -9,11 +9,12 @@ To export the document model specification, follow the steps in the [Define ToDo
9
9
  Reducers are a core concept in Powerhouse document models. They implement the state transition logic for each operation defined in your schema.
10
10
 
11
11
  :::info
12
- **Connection to schema definition language (SDL)**: The reducers directly implement the operations you defined in your SDL. Remember how we defined `AddTodoItemInput`, `UpdateTodoItemInput`, and `DeleteTodoItemInput` in our schema?
12
+ **Connection to schema definition language (SDL)**: The reducers directly implement the operations you defined in your SDL. Remember how we defined `AddTodoItemInput`, `UpdateTodoItemInput`, and `DeleteTodoItemInput` in our schema?
13
13
  The reducers provide the actual implementation of what happens when those operations are performed.
14
14
  :::
15
15
 
16
- To import the document model specification into your Powerhouse project, you can either:
16
+ To import the document model specification into your Powerhouse project, you can either:
17
+
17
18
  - Copy and paste the file directly into the root of your Powerhouse project.
18
19
  - Or drag and drop the file into the Powerhouse project directory in the VSCode editor as seen in the image below:
19
20
 
@@ -23,8 +24,7 @@ Either step will import the document model specification into your Powerhouse pr
23
24
 
24
25
  ## In your project directory
25
26
 
26
- The next steps will take place in the VSCode editor. Make sure to have it open and the terminal window inside VSCode open as well.
27
-
27
+ The next steps will take place in the VSCode editor. Make sure to have it open and the terminal window inside VSCode open as well.
28
28
 
29
29
  To write the operation reducers of the **To-do List** document model, you need to generate the document model code from the document model specification file you have exported into the Powerhouse project directory.
30
30
 
@@ -45,7 +45,6 @@ Open the `to-do-list.ts` file and you should see the code that needs to be fille
45
45
  1. Copy and paste the code below into the `to-do-list.ts` file in the `reducers` folder.
46
46
  2. Save the file.
47
47
 
48
-
49
48
  <details>
50
49
  <summary>Operation Reducers</summary>
51
50
  ```typescript
@@ -54,31 +53,31 @@ import { ToDoListToDoListOperations } from '../../gen/to-do-list/operations.js';
54
53
  // REMARKS: This is our main reducer object that implements all operations defined in the schema.
55
54
  // The ToDoListToDoListOperations type is auto-generated from our SDL and ensures type safety.
56
55
  export const reducer: ToDoListToDoListOperations = {
57
- // REMARKS: The addTodoItemOperation adds a new item to our todolist.
58
- // - state: The current document state that we can modify
59
- // - action: Contains the operation type and input data from the client
60
- // - dispatch: Function to trigger additional operations (not used here)
61
- addTodoItemOperation(state, action, dispatch) {
62
- // REMARKS: While this looks like we're directly mutating state, Powerhouse
63
- // handles immutability behind the scenes, creating a new state object.
64
- state.items.push({
65
- id: action.input.id, // Using the client-provided ID
66
- text: action.input.text, // Setting the todo text from input
67
- checked: false, // New items always start unchecked
68
- });
69
- },
70
-
71
- // REMARKS: The updateTodoItemOperation modifies an existing todo item.
72
- // It handles partial updates, allowing only specific fields to be updated.
73
- updateTodoItemOperation(state, action, dispatch) {
74
- // REMARKS: First find the item we want to update by its ID
75
- const item = state.items.find(item => item.id === action.input.id);
76
-
56
+ // REMARKS: The addTodoItemOperation adds a new item to our todolist.
57
+ // - state: The current document state that we can modify
58
+ // - action: Contains the operation type and input data from the client
59
+ // - dispatch: Function to trigger additional operations (not used here)
60
+ addTodoItemOperation(state, action, dispatch) {
61
+ // REMARKS: While this looks like we're directly mutating state, Powerhouse
62
+ // handles immutability behind the scenes, creating a new state object.
63
+ state.items.push({
64
+ id: action.input.id, // Using the client-provided ID
65
+ text: action.input.text, // Setting the todo text from input
66
+ checked: false, // New items always start unchecked
67
+ });
68
+ },
69
+
70
+ // REMARKS: The updateTodoItemOperation modifies an existing todo item.
71
+ // It handles partial updates, allowing only specific fields to be updated.
72
+ updateTodoItemOperation(state, action, dispatch) {
73
+ // REMARKS: First find the item we want to update by its ID
74
+ const item = state.items.find(item => item.id === action.input.id);
75
+
77
76
  // REMARKS: Proper error handling if item doesn't exist
78
77
  if (!item) {
79
78
  throw new Error(`Item with id ${action.input.id} not found`);
80
79
  }
81
-
80
+
82
81
  // REMARKS: We only update fields that were included in the input
83
82
  // This allows for partial updates (only update what was provided)
84
83
  if (action.input.text) {
@@ -87,17 +86,19 @@ export const reducer: ToDoListToDoListOperations = {
87
86
  if (typeof action.input.checked === 'boolean') {
88
87
  item.checked = action.input.checked;
89
88
  }
90
- },
91
-
92
- // REMARKS: The deleteTodoItemOperation removes an item from the list.
93
- // This showcases functional programming with array filters for immutable updates.
94
- deleteTodoItemOperation(state, action, dispatch) {
95
- // REMARKS: Create a new array containing only items that don't match the ID
96
- // This is a common pattern for immutable array updates in JavaScript
97
- state.items = state.items.filter(item => item.id !== action.input.id);
98
- },
89
+
90
+ },
91
+
92
+ // REMARKS: The deleteTodoItemOperation removes an item from the list.
93
+ // This showcases functional programming with array filters for immutable updates.
94
+ deleteTodoItemOperation(state, action, dispatch) {
95
+ // REMARKS: Create a new array containing only items that don't match the ID
96
+ // This is a common pattern for immutable array updates in JavaScript
97
+ state.items = state.items.filter(item => item.id !== action.input.id);
98
+ },
99
99
  };
100
- ```
100
+
101
+ ````
101
102
  </details>
102
103
 
103
104
  ## Write the operation reducers tests
@@ -131,7 +132,7 @@ describe('Todolist Operations', () => {
131
132
  it('should handle addTodoItem operation', () => {
132
133
  // REMARKS: We create an input object matching our AddTodoItemInput schema
133
134
  const input = { id: '1', text: 'Buy milk' };
134
-
135
+
135
136
  // REMARKS: We apply the operation to get a new document state
136
137
  // Note how we use the creators to generate the operation action
137
138
  const updatedDocument = reducer(document, creators.addTodoItem(input));
@@ -174,7 +175,8 @@ describe('Todolist Operations', () => {
174
175
  expect(updatedDocument.state.global.items).toHaveLength(0);
175
176
  });
176
177
  });
177
- ```
178
+ ````
179
+
178
180
  </details>
179
181
 
180
182
  Now you can run the tests to make sure the operation reducers are working as expected.
@@ -192,7 +194,8 @@ Output should be as follows:
192
194
  Duration 417ms (transform 79ms, setup 0ms, collect 174ms, tests 12ms, environment 0ms, prepare 158ms)
193
195
  ```
194
196
 
195
- If you got the same output, you have successfully implemented the operation reducers and tests for the **To-do List** document model. Congratulations, you've successfully set up the backbone for a simple **To-do List** document.
197
+ If you got the same output, you have successfully implemented the operation reducers and tests for the **To-do List** document model. Congratulations, you've successfully set up the backbone for a simple **To-do List** document.
196
198
 
197
199
  ## Up next: To-do list editor
198
- In the next chapter of this introduction track you will learn how to implement an editor for your document model so you can see a simple user interface for the **To-do List** document model in action.
200
+
201
+ In the next chapter of this introduction track you will learn how to implement an editor for your document model so you can see a simple user interface for the **To-do List** document model in action.
@@ -4,7 +4,7 @@ In this chapter we will continue with the interface or editor implementation of
4
4
 
5
5
  ## Generate the editor template
6
6
 
7
- Run the command below to generate the editor template for the **To-do List** document model.
7
+ Run the command below to generate the editor template for the **To-do List** document model.
8
8
  This command reads the **To-do List** document model definition from the `document-models` folder and generates the editor template in the `editors/to-do-list` folder as `editor.tsx`.
9
9
 
10
10
  Notice the `--editor` flag which specifies the **To-do List** document model, and the `--document-types` flag defines the document type `powerhouse/todolist`.
@@ -15,16 +15,15 @@ ph generate --editor ToDoList --document-types powerhouse/todolist
15
15
 
16
16
  Once complete, navigate to the `editors/to-do-list/editor.tsx` file and open it in your editor.
17
17
 
18
-
19
18
  ### Editor implementation options
20
19
 
21
20
  When building your editor component within the Powerhouse ecosystem, you have several options for styling, allowing you to leverage your preferred methods:
22
21
 
23
- 1. **Default HTML Styling:** Standard HTML tags (`<h1>`, `<p>`, `<button>`, etc.) will render with default styles offered through the boilerplate.
22
+ 1. **Default HTML Styling:** Standard HTML tags (`<h1>`, `<p>`, `<button>`, etc.) will render with default styles offered through the boilerplate.
24
23
  2. **Tailwind CSS:** Connect Studio comes with Tailwind CSS integrated. You can directly use Tailwind utility classes for rapid, consistent styling without writing separate CSS files.
25
24
  3. **Custom CSS Files:** You can import traditional CSS files (`.css`) to apply custom styles or integrate existing style libraries.
26
25
 
27
- Connect Studio provides a dynamic local environment, by running `ph connect` to visualize your components instantly as you build them, regardless of the styling method you choose.
26
+ Connect Studio provides a dynamic local environment, by running `ph connect` to visualize your components instantly as you build them, regardless of the styling method you choose.
28
27
  Manual build steps are typically only needed when publishing packages.
29
28
 
30
29
  ## To-do List editor
@@ -189,6 +188,7 @@ export default function Editor(props: IProps) {
189
188
  );
190
189
  }
191
190
  ```
191
+
192
192
  </details>
193
193
 
194
194
  Now you can run the Connect app and see the **To-do List** editor in action.
@@ -197,22 +197,22 @@ Now you can run the Connect app and see the **To-do List** editor in action.
197
197
  ph connect
198
198
  ```
199
199
 
200
- In Connect, in the bottom right corner you'll find a new Document Model that you can create: **To-do List**.
200
+ In Connect, in the bottom right corner you'll find a new Document Model that you can create: **To-do List**.
201
201
  Click on it to create a new To-do List document.
202
202
 
203
203
  :::info
204
- The editor will update dynamically, so you can play around with your editor styling while seeing your results appear in Connect Studio.
204
+ The editor will update dynamically, so you can play around with your editor styling while seeing your results appear in Connect Studio.
205
205
  :::
206
206
 
207
207
  Congratulations!
208
- If you managed to follow this tutorial until this point, you have successfully implemented the **To-do List** document model with its reducer operations and editor.
208
+ If you managed to follow this tutorial until this point, you have successfully implemented the **To-do List** document model with its reducer operations and editor.
209
209
 
210
210
  ### Up next: Mastery Track
211
211
 
212
212
  In the [Mastery Track chapther: Document Model Creation](/academy/MasteryTrack/DocumentModelCreation/WhatIsADocumentModel) we guide you through the theoretics of the previous steps while created a more advanced version of the To-do List.
213
213
 
214
- You will learn:
214
+ You will learn:
215
+
215
216
  - The in's & out's of a document model.
216
217
  - How to use UI & Scalar components from the Document Engineering system.
217
- - How to build Custom Drive Apps or Drive Explorers.
218
-
218
+ - How to build Custom Drive Apps or Drive Explorers.
@@ -0,0 +1,164 @@
1
+ # Tool: Vetra Studio
2
+
3
+ This chapter introduces you to one of the most powerfull features of the Powerhouse development framework: Specification Driven AI-control. 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.
4
+
5
+ :::tip Important
6
+ 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**.
7
+ :::
8
+
9
+ ## Vision: Specification Driven AI
10
+
11
+ At Powerhouse we are embracing the progress of AI assisted coding while unlocking the next level of AI control through **specification driven AI control**.
12
+
13
+ - Communicate your solution and intent through a structured specification framework designed for AI collaboration.
14
+ - Specifications enable precise, iterative edits, since all our specification documents are machine-readable and executable.
15
+ - Specifications offer the ability to update exact parameters and properties as your specs evolve in lock-step with your agent.
16
+ - Specifications turn fragile sandcastles into solid, editable, and maintainable functionality with predictable results.
17
+
18
+ This approach allows for the creation of editable specifications, enabling business analysts to modify details and instruct the AI to generate code based on updated specifications.
19
+ It results in composable, maintainable, and scalable functionality.
20
+
21
+ ## Introducing Vetra Studio
22
+
23
+ **Vetra Studio** serves as a centralized hub for developers to access and manage specifications.
24
+ It allows developers to open packages (Git repositories with metadata) from a Vetra package library, providing access to a remote Vetra drive where all specifications are stored.
25
+
26
+ This setup ensures that all necessary documentation and project requirements are in one accessible location, streamlining communication and agreement on requirements and operations. Additionally, **Vetra Studio** functions as the orchestration hub where you as a builder assemble all the necessary specifications for your intended use-case, software solution or package. For each of the different **modules** that together form a package a specification document can be created in **Vetra Studio**.
27
+
28
+ 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.
29
+
30
+ <figure className="image-container">
31
+ <img
32
+ src={require("./images/Modules.png").default}
33
+ alt="Modules"
34
+ />
35
+ <figcaption>The list of available modules color coded according to the 3 categories.</figcaption>
36
+ </figure>
37
+
38
+ ### Module Categories
39
+
40
+ #### 1. Document Models
41
+ - **Document model specification**: Defines the structure and operations of a document model using GraphQL SDL, ensuring consistent data management and processing.
42
+
43
+ #### 2. User Experiences
44
+ - **Editor specification**: Outlines the interface and functionalities of a document model editor, allowing users to interact with and modify document data.
45
+ - **Drive-app specification**: Specifies the UI and interactions for managing documents within a Drive, providing tailored views and functionalities.
46
+
47
+ #### 3. Data integrations
48
+ - **Subgraph specification**: Details the connections and relationships within a subgraph, facilitating efficient data querying and manipulation.
49
+ - **Codegen Processor Specification**: Describes the process for automatically generating code from document model specifications, ensuring alignment with intended architecture.
50
+ - **RelationalDb Processor Specification**: Defines how relational databases are structured and queried, supporting efficient data management and retrieval.
51
+
52
+ <figure className="image-container">
53
+ <img
54
+ src={require("./images/VetraStudioDrive.png").default}
55
+ alt="Vetra Studio Drive"
56
+ />
57
+ <figcaption>The Vetra Studio Drive, a builder app that collects all of the specification of a package.</figcaption>
58
+ </figure>
59
+
60
+ ## Vetra Studio Workflow
61
+
62
+ ### 1. Launch Vetra Studio
63
+
64
+ You can launch Vetra Studio in two modes:
65
+
66
+ #### Interactive Mode (Recommended for Development)
67
+ ```bash
68
+ ph vetra --interactive
69
+ ```
70
+ In interactive mode:
71
+ - You'll receive confirmation prompts before any code generation
72
+ - Changes require explicit confirmation before being processed
73
+ - Provides better control and visibility over document changes
74
+
75
+ #### Standard Mode
76
+ ```bash
77
+ ph vetra
78
+ ```
79
+ In standard mode:
80
+ - Changes are processed automatically with 1-second debounce
81
+ - Multiple changes are batched and processed together
82
+ - Uses the latest document state for processing
83
+
84
+ ### 2. Launch Claude with Reactor-MCP
85
+
86
+ 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.
87
+
88
+ #### 1. Start the Reactor MCP:
89
+ ```bash
90
+ ph mcp
91
+ ```
92
+
93
+ #### 2. Verify MCP connection:
94
+ - Check that the Reactor MCP is available.
95
+ - Confirm Vetra Studio shows "Connected to Reactor MCP"
96
+
97
+ - To learn what is a [Reactor] itself read (apps/academy/docs/academy/Architecture/WorkingWithTheReactor)
98
+ - To learn more about the [Reactor MCP] read (apps/academy/docs/academy/GetStarted/ReactorMCP)
99
+
100
+ #### Key Reactor MCP Features:
101
+ - Automatic document model creation from natural language descriptions
102
+ - Smart editor generation based on document models
103
+ - Automatically triggers code generation when documents reach valid state
104
+
105
+ The powerhouse config includes a vetra URL for consistent project configuration across different environments.
106
+
107
+ :::tip
108
+ - Vetra supports integration with custom remote drives, allowing users to create, share and manage documents within these drives.
109
+ - The MCP server enables the agent to work with both existing and newly created document models.
110
+ :::
111
+
112
+ ### 3. Vetra Studio Package Creation Workflow
113
+
114
+ #### A. Set Package Description (Required)
115
+ 1. Provide a name for your package
116
+ 2. Add a meaningful description
117
+ 3. Add keywords to add search terms to your package
118
+ 4. Confirm changes when prompted in interactive mode
119
+
120
+ #### B. Define Document Model (Required)
121
+ You can create document models in two ways:
122
+
123
+ 1. **Using MCP (AI-Assisted)**
124
+ - Describe your document needs in natural language in great detail.
125
+ - Claude will:
126
+ - Generate an appropriate schema
127
+ - Create the necessary operations
128
+ - Implement the required reducers
129
+ - Place the document in the Vetra drive
130
+
131
+ 2. **Manual Creation**
132
+ - Define document schema with fields and types as in the **'Get Started'**
133
+ - Create the necessary operations
134
+ - Add the required modules to your package
135
+ - The document model creation chapter in the Mastery track provides in depth support [here](apps/academy/docs/academy/MasteryTrack/DocumentModelCreation/SpecifyTheStateSchema)
136
+
137
+ #### C. Add Document Editor (Required)
138
+ 1. **Using MCP (AI-Assisted)**
139
+ - 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
140
+ - Claude will:
141
+ - Generate editor components
142
+ - Implement necessary hooks
143
+ - Create required UI elements
144
+
145
+ 2. **Manual Creation**
146
+ - Select your target document model
147
+ - Configure the currently limited editor properties
148
+ - Add the editor specification to Vetra Studio drive
149
+ - The system will generate scaffolding code
150
+
151
+ #### D. Data Integrations (Coming Soon)
152
+ Support for:
153
+ - Subgraph integration
154
+ - Code generation processors
155
+ - Relational database processors
156
+
157
+ ### Best Practices
158
+
159
+ **Working with MCP and claude**
160
+ - Provide clear, specific instructions and ask for clarifying questions to be answered before code generation.
161
+ - Review generated schemas before confirmation and work in layers instead of 'one-shotting' your code.
162
+ - Verify implementation details in generated code before continuing.
163
+ - Always double-check proposed next actions
164
+
@@ -0,0 +1,58 @@
1
+ # Tool: Reactor MCP
2
+
3
+ **Reactor-mcp** is a Model Context Protocol (MCP) server for the Powerhouse ecosystem that provides AI agents and tools with structured access to document model operations.
4
+ It serves as a bridge between AI systems and the Powerhouse document management infrastructure.
5
+
6
+ ## Main Functions of the Reactor-mcp
7
+
8
+ **Document Operations**:
9
+ - createDocument - Create new documents
10
+ - getDocument - Retrieve documents by ID
11
+ - addActions - Add actions to modify document state
12
+ - deleteDocument - Remove documents
13
+
14
+ **Drive Operations**:
15
+ - getDrives - List all document drives
16
+ - addDrive - Create new drives
17
+ - getDrive - Retrieve specific drives
18
+ - addRemoteDrive - Connect to remote drives
19
+
20
+ **Document Model Operations**:
21
+ - getDocumentModels - List available document model types
22
+ - getDocumentModelSchema - Get schema for specific document models
23
+
24
+ <details>
25
+ <summary>Architecture Context</summary>
26
+
27
+ Within the broader Powerhouse ecosystem:
28
+
29
+ - Document Model: Defines structure and operations for document types
30
+ - Document Drive: Manages collections of documents with sync capabilities
31
+ - Reactor-MCP: Provides AI/tool access to document operations
32
+ - Connect/Switchboard: User interfaces and synchronization servers
33
+
34
+ The reactor-mcp essentially makes the sophisticated document model system accessible to AI agents and external tools through a standardized protocol, enabling programmatic document creation, modification, and management within the Powerhouse ecosystem.
35
+
36
+ </details>
37
+
38
+ ### Document Model Agent
39
+
40
+ Alongside the MCP is a **specialized AI agent** for document model creation:
41
+
42
+ - Purpose: Guide users through creating document models
43
+ - Workflow: Requirements gathering → Design confirmation → Implementation
44
+ - Tools: Comprehensive set of MCP tools for model management
45
+ - Capabilities:
46
+ - State schema definition
47
+ - Operation creation
48
+ - Module organization
49
+ - Code generation
50
+
51
+ :::tip Supports with:
52
+
53
+ 1. **AI-Assisted Document Model Creation**: AI agents can use the MCP tools to help users create and modify document models
54
+ 2. **Automated Document Management**: Programmatic creation and management of documents and drives
55
+ 3. **Integration with AI Tools**: Claude, GPT, or other AI systems can use this as an MCP server to interact with Powerhouse
56
+ 4. **Development Tooling**: CLI and development server for working with document models locally
57
+ :::
58
+