@powerhousedao/academy 5.1.0-dev.0 → 5.1.0-dev.10

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 (75) hide show
  1. package/CHANGELOG.md +78 -0
  2. package/blog/BeyondCommunication-ABlueprintForDevelopment.md +2 -1
  3. package/blog/TheChallengeOfChange.md +1 -0
  4. package/docs/academy/01-GetStarted/00-ExploreDemoPackage.mdx +24 -27
  5. package/docs/academy/01-GetStarted/01-CreateNewPowerhouseProject.md +118 -9
  6. package/docs/academy/01-GetStarted/02-DefineToDoListDocumentModel.md +110 -28
  7. package/docs/academy/01-GetStarted/03-ImplementOperationReducers.md +191 -145
  8. package/docs/academy/01-GetStarted/04-WriteDocumentModelTests.md +378 -0
  9. package/docs/academy/01-GetStarted/05-BuildToDoListEditor.md +560 -0
  10. package/docs/academy/01-GetStarted/_04-BuildToDoListEditor +1 -1
  11. package/docs/academy/02-MasteryTrack/01-BuilderEnvironment/03-BuilderTools.md +2 -2
  12. package/docs/academy/{01-GetStarted → 02-MasteryTrack/01-BuilderEnvironment}/05-VetraStudio.md +48 -6
  13. package/docs/academy/02-MasteryTrack/02-DocumentModelCreation/02-SpecifyTheStateSchema.md +75 -44
  14. package/docs/academy/02-MasteryTrack/02-DocumentModelCreation/03-SpecifyDocumentOperations.md +28 -22
  15. package/docs/academy/02-MasteryTrack/02-DocumentModelCreation/04-UseTheDocumentModelGenerator.md +28 -31
  16. package/docs/academy/02-MasteryTrack/02-DocumentModelCreation/05-ImplementDocumentReducers.md +211 -206
  17. package/docs/academy/02-MasteryTrack/02-DocumentModelCreation/06-ImplementDocumentModelTests.md +176 -62
  18. package/docs/academy/02-MasteryTrack/02-DocumentModelCreation/07-ExampleToDoListRepository.md +21 -0
  19. package/docs/academy/02-MasteryTrack/03-BuildingUserExperiences/01-BuildingDocumentEditors.md +309 -319
  20. package/docs/academy/02-MasteryTrack/03-BuildingUserExperiences/06-DocumentTools/00-DocumentToolbar.mdx +4 -0
  21. package/docs/academy/02-MasteryTrack/03-BuildingUserExperiences/06-DocumentTools/01-OperationHistory.md +4 -0
  22. package/docs/academy/02-MasteryTrack/05-Launch/04-ConfigureEnvironment.md +1 -1
  23. package/docs/academy/03-ExampleUsecases/Chatroom/02-CreateNewPowerhouseProject.md +111 -35
  24. package/docs/academy/03-ExampleUsecases/Chatroom/03-DefineChatroomDocumentModel.md +255 -76
  25. package/docs/academy/03-ExampleUsecases/Chatroom/04-ImplementOperationReducers.md +281 -160
  26. package/docs/academy/03-ExampleUsecases/Chatroom/05-ImplementChatroomEditor.md +188 -35
  27. package/docs/academy/03-ExampleUsecases/Chatroom/06-LaunchALocalReactor.md +95 -7
  28. package/docs/academy/03-ExampleUsecases/Chatroom/_category_.json +1 -1
  29. package/docs/academy/03-ExampleUsecases/TodoList/00-GetTheStarterCode.md +24 -0
  30. package/docs/academy/03-ExampleUsecases/TodoList/01-GenerateTodoListDocumentModel.md +211 -0
  31. package/docs/academy/03-ExampleUsecases/TodoList/02-ImplementTodoListDocumentModelReducerOperationHandlers.md +171 -0
  32. package/docs/academy/03-ExampleUsecases/TodoList/03-AddTestsForTodoListActions.md +462 -0
  33. package/docs/academy/03-ExampleUsecases/TodoList/04-GenerateTodoListDocumentEditor.md +45 -0
  34. package/docs/academy/03-ExampleUsecases/TodoList/05-ImplementTodoListDocumentEditorUIComponents.md +422 -0
  35. package/docs/academy/03-ExampleUsecases/TodoList/06-GenerateTodoDriveExplorer.md +61 -0
  36. package/docs/academy/03-ExampleUsecases/TodoList/07-AddSharedComponentForShowingTodoListStats.md +384 -0
  37. package/docs/academy/03-ExampleUsecases/TodoList/_category_.json +8 -0
  38. package/docs/academy/03-ExampleUsecases/VetraPackageLibrary/VetraPackageLibrary.md +7 -0
  39. package/docs/academy/03-ExampleUsecases/VetraPackageLibrary/_category_.json +9 -0
  40. package/docs/academy/04-APIReferences/00-PowerhouseCLI.md +6 -2
  41. package/docs/academy/04-APIReferences/01-ReactHooks.md +2 -2
  42. package/docs/academy/04-APIReferences/06-VetraRemoteDrive.md +160 -0
  43. package/docs/academy/04-APIReferences/renown-sdk/00-Overview.md +316 -0
  44. package/docs/academy/04-APIReferences/renown-sdk/01-Authentication.md +672 -0
  45. package/docs/academy/04-APIReferences/renown-sdk/02-APIReference.md +957 -0
  46. package/docs/academy/04-APIReferences/renown-sdk/_category_.json +8 -0
  47. package/docs/academy/05-Architecture/00-PowerhouseArchitecture.md +7 -39
  48. package/docs/academy/06-ComponentLibrary/00-DocumentEngineering.md +72 -24
  49. package/docs/academy/08-Glossary.md +7 -0
  50. package/docs/academy/10-TodoListTutorial/02-ImplementTodoListDocumentModelReducerOperationHandlers.md +171 -0
  51. package/docs/academy/10-TodoListTutorial/03-AddTestsForTodoListActions.md +462 -0
  52. package/docs/academy/10-TodoListTutorial/05-ImplementTodoListDocumentEditorUIComponents.md +422 -0
  53. package/docs/academy/10-TodoListTutorial/07-AddSharedComponentForShowingTodoListStats.md +370 -0
  54. package/docusaurus.config.ts +28 -3
  55. package/package.json +1 -1
  56. package/sidebars.ts +49 -12
  57. package/src/css/custom.css +26 -18
  58. package/static/img/Vetra-logo-dark.svg +11 -0
  59. package/static/img/vetra-logo-light.svg +11 -0
  60. package/docs/academy/00-EthereumArgentinaHackathon.md +0 -207
  61. package/docs/academy/01-GetStarted/04-BuildToDoListEditor.md +0 -218
  62. package/docs/academy/01-GetStarted/06-ReactorMCP.md +0 -58
  63. package/docs/academy/05-Architecture/02-ReferencingMonorepoPackages +0 -65
  64. package/docs/academy/05-Architecture/04-MovingBeyondCRUD +0 -61
  65. /package/docs/academy/{01-GetStarted → 02-MasteryTrack/01-BuilderEnvironment}/images/Modules.png +0 -0
  66. /package/docs/academy/{01-GetStarted → 02-MasteryTrack/01-BuilderEnvironment}/images/VetraStudioDrive.png +0 -0
  67. /package/docs/academy/02-MasteryTrack/03-BuildingUserExperiences/06-DocumentTools/{02-RevisionHistoryTimeline → 02-RevisionHistoryTimeline/360/237/232/247"} +0 -0
  68. /package/docs/academy/05-Architecture/05-DocumentModelTheory/{01-WhatIsADocumentModel → 360/237/232/247 /01-WhatIsADocumentModel"} +0 -0
  69. /package/docs/academy/05-Architecture/05-DocumentModelTheory/{02-DAOandDocumentsModelsQ+A → 360/237/232/247 /02-DAOandDocumentsModelsQ+A"} +0 -0
  70. /package/docs/academy/05-Architecture/05-DocumentModelTheory/{02-domain-modeling → 360/237/232/247 /02-domain-modeling"} +0 -0
  71. /package/docs/academy/05-Architecture/05-DocumentModelTheory/{03-BenefitsOfDocumentModels → 360/237/232/247 /03-BenefitsOfDocumentModels"} +0 -0
  72. /package/docs/academy/05-Architecture/05-DocumentModelTheory/{04-UtilitiesAndTips → 360/237/232/247 /04-UtilitiesAndTips"} +0 -0
  73. /package/docs/academy/05-Architecture/05-DocumentModelTheory/{05-best-practices → 360/237/232/247 /05-best-practices"} +0 -0
  74. /package/docs/academy/05-Architecture/05-DocumentModelTheory/{_category_.json → 360/237/232/247 /_category_.json"} +0 -0
  75. /package/docs/academy/05-Architecture/05-DocumentModelTheory/{three-data-layers.png → 360/237/232/247 /three-data-layers.png"} +0 -0
@@ -1,207 +0,0 @@
1
- ---
2
- id: EthereumArgentinaHackathon
3
- title: Ethereum Argentina Hackathon
4
- ---
5
-
6
- # Ethereum Argentina Hackathon
7
-
8
- **November 19-20, 2024**
9
-
10
- Welcome to the Vetra hacker page for the Ethereum Argentina Hackathon! We're excited to support developers building with Powerhouse during this event.
11
-
12
- ## Overview
13
-
14
- Join us for two days of intensive development support as you build decentralized applications using the Vetra framework. Our team will be available online and at the mentor's table to help you navigate the builder platform, answer questions, and guide you through best practices.
15
-
16
- ## 📅 Event Details
17
-
18
- - **Dates**: November 19-20, 2024
19
- - **Format**: Online & IRL Developer Support
20
- - **Time Zone**: Argentina Time (ART)
21
- - **Support Hours at Mentor Table @ la Rural**: Please get in touch [on Discord to schedule](https://discord.gg/pwQJwgaQKd)
22
- - **Hackathon informations**: [Taiki Hackathon](https://taikai.network/ethargentina/hackathons/tierra-de-buidlers-2025/overview)
23
-
24
- ## 🚀 Getting Started
25
-
26
- <details>
27
- <summary> Vetra Introduction & Follow Along Demo </summary>
28
-
29
- Please Rewatch our Hackathon introduction & follow along tutorial.
30
-
31
- <iframe width="560" height="315" src="https://www.youtube.com/embed/R5MAaGaopJg" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen></iframe>
32
-
33
- Find a complete overview of how to use the Vetra Studio for you project [here](./01-GetStarted/05-VetraStudio.md)
34
-
35
- **Quick Start Summary**
36
-
37
- - Step 1: Install the powerhouse-CLI: `pnpm install -g ph-cmd`
38
- - Step 2: Initialize a project & directory `ph init my-project-name`
39
- - Step 3: CD into you project directory
40
- - Step 4: Launch Vetra Studio with the `ph vetra`command
41
- - Step 5: Add the necessary document models & editors for your intended solution in Vetra Studio
42
- - Step 6: If you're well versed in schema creation or graphql. Just talk with an agent about your imagined solution.
43
- - Step 7: Start your preferred agent to help you with the initial scaffolding of your schema, operations and reducers.
44
- - Step 8: Test your implementation in the "Vetra Preview Drive" with the `ph vetra --watch`command.
45
- - Step 9: Run pnpm build and push your project to a remote repository. Follow the package publishing [Tutorial](./02-MasteryTrack/05-Launch/02-PublishYourProject.md)
46
-
47
- **Basic tips**
48
- - 1️⃣ Write a detailed description of your intented functionality inside the document model specification manifest
49
- - 2️⃣ Ask your agent to ask for clarifying questions before starting any ideation process.
50
- - 3️⃣ For each document model you'll want to create an accompanying editor in vetra studio.
51
- - 4️⃣ An 'App' specifcation is an drive that can act as an app because of the specific interface you create for it.
52
-
53
- ### Before the Hackathon
54
-
55
- 1. **Set Up Your Environment**
56
- - Install the Powerhouse CLI
57
- - Set up your development environment
58
- - Review the [Get Started Guide](./01-GetStarted/home.mdx)
59
-
60
- 2. **Explore the Platform**
61
- - Check out the [Demo Package](./01-GetStarted/00-ExploreDemoPackage.mdx)
62
- - Familiarize yourself with [Document Models](./02-MasteryTrack/02-DocumentModelCreation/01-WhatIsADocumentModel.md)
63
-
64
- 3. **Join Our Community**
65
- - Discord: [Join our server](#)
66
-
67
-
68
- </details>
69
-
70
- :::tip Use your preferred AI agent
71
- Vetra studio is compatible with Cursor, Claude and Gemini. Find the dedicated markdown files to guide your agent with the correct instruction in your directory. Your agent should also have access to the MCP's available.
72
- :::
73
-
74
-
75
- ## **Hackathon Project Ideas**
76
-
77
- Powerhouse is perfect for building:
78
-
79
- - **Real World Use-cases**: Every document can act as a mini ledger/blockchain.
80
- - **Decentralized Applications**: Create apps with built-in version control and collaboration.
81
- - **Document-Based Systems**: Build structured data applications.
82
- - **Collaborative Tools**: Enable real-time multi-user editing.
83
- - **Data Management Platforms**: Create systems with queryable, structured data.
84
-
85
- ### Coordination & DAO Design
86
-
87
- - 🧩 **What if** DAOs weren't chaotic? What documents would you need to make them coordinate like space X and ship like stripe?
88
- - 🎯 **What if** making decisions as a group felt like playing a co-op strategy game. With a clearly aligned vision, instant dashboards and a way to capture hard won knowledge in expertise into custom software for the Dao?
89
-
90
- :::tip IDEA
91
- The ultimate DAO Template toolkit where vision & mission documents influence guidelines & onboarding for contributors.
92
- :::
93
-
94
- ---
95
-
96
- ### GovTech & Public Infrastructure
97
-
98
- - 🗳 **What if** local governments had to reach consensus with residents before making a decision? How would that look like?
99
- - 🚧 **What if** you could submit pothole fixes or transit complaints into a civic DAO, and track the response like GitHub issues?
100
- - 🧾 **What if** municipal budgets were editable public documents with community feedback loops?
101
-
102
- :::tip IDEA
103
- An Open Source Enterprise Resource Planning-suite for municipalities & governments
104
- :::
105
-
106
- ---
107
-
108
- ### Education & Group Work
109
-
110
- - 📝 **What if** your group project auto-divided work, tracked contributions, and paid out in real-time?
111
- - 👾 **What if** "homework" was a multiplayer quest, and grades came from the DAO?
112
- - 🏫 **What if** we DAO-ified a classroom and let the students vote on rules, roles, and rewards?
113
-
114
- :::tip IDEA
115
- The remote classroom SAAS back-end that fosters connection, gives purpose to bullies and empowers younger generation to dream big again.
116
- :::
117
-
118
- ---
119
-
120
- ### 💸 Grants, Crypto, and Incentive Design
121
-
122
- - 💰 **What if** grant tooling felt like bounty hunting across a galaxy of projects?
123
- - 📊 **What if** every grant had a live budget dashboard, contributor feed, and impact score?
124
- - 🎮 **What if** you could stake on coordination itself, betting that people will work together well?
125
-
126
- :::tip IDEA
127
- The future of grant platforms that dares to imagine grants in new ways. With follow up, tracking and impact visualisations of teams, time, risk & resources invested.
128
- :::
129
-
130
- ---
131
-
132
- ### 💸 Lawmaking, Legislation & Legal
133
-
134
- - 🧑‍⚖️ **What if** any government or DAO could fork a legal template, customize it, and track changes in a public, composable way?
135
- - 🎨 **What if** legislation could be transparently co-created by citizens, NGOs, and governments all with aligned incentives?
136
- - 💻 **What if** legislation, contracts & templates could exist on an open-source market place like software?
137
- - 🤖 **What if** a network agent could create a legal vehicle by simply inputing set of requirements and risk preferences (in non legalese)?
138
- - 🤝 **What if** 2 agents in a network could negotiate terms of an agreement according to predefined functions and risk parameters, without lawyers?
139
-
140
- :::tip IDEA
141
- Build a Decentralized Lawmaking Engine using Reactive Document Models
142
- :::
143
-
144
-
145
- ## 🛠️ Resources
146
-
147
- ### Documentation
148
-
149
- - [Quick Start Guide](./01-GetStarted/home.mdx)
150
- - [Create a New Project](./01-GetStarted/01-CreateNewPowerhouseProject.md)
151
- - [Define Document Models](./01-GetStarted/02-DefineToDoListDocumentModel.md)
152
- - [Build Editors](./01-GetStarted/04-BuildToDoListEditor.md)
153
- - [API References](./04-APIReferences/00-PowerhouseCLI.md)
154
-
155
- ### Tutorials
156
-
157
- - [To-Do List Example](./01-GetStarted/02-DefineToDoListDocumentModel.md)
158
- - [Chatroom Use Case](./03-ExampleUsecases/Chatroom/02-CreateNewPowerhouseProject.md)
159
-
160
- ## 🏆 Judging Criteria
161
-
162
- Projects will be evaluated based on:
163
-
164
- - **Usefulness & Impact**: How well does it solve a certain job or problem?
165
- - **Composability/Structure**: How are the different document models and / or drive apps collaborating?
166
- - **Clarity of the developer or user experience**: Did you unlock the secret sauce of UX & reactive documents?
167
- - **Alignment with Vetra/Powerhouse principles**: Local-first, auditable, usefull for common good.
168
-
169
- ## 📋 Submission Guidelines
170
-
171
- ### What to Submit
172
-
173
- - GitHub repository with your code
174
- - (Video) presentation (2-3 minutes)
175
- - README with:
176
- - Project description
177
- - Setup instructions
178
- - Screenshots/demos
179
- - Technologies used
180
-
181
- The Powerhouse team will add you as a builder on the Vetra platform and host your application and drive.
182
-
183
-
184
- ## Tips for Success
185
-
186
- ### Development Tips
187
-
188
- 1. **Start Simple**: Begin with a basic implementation and iterate
189
- 2. **Use Templates**: Leverage existing examples and templates
190
- 3. **Ask Questions**: Don't hesitate to reach out for help
191
- 4. **Test Early**: Test your application frequently during development
192
- 5. **Document**: Keep notes on your decisions and implementations
193
-
194
- ### Presentation Tips
195
-
196
- 1. **Show, Don't Tell**: Live demos are more impactful than slides
197
- 2. **Tell a Story**: Explain the problem you're solving
198
- 3. **Highlight Innovation**: Show what makes your solution unique
199
- 4. **Be Concise**: Respect the time limits for presentations
200
- 5. **Prepare Backup**: Have screenshots/video in case of technical issues
201
-
202
- ---
203
-
204
- **Good luck, and happy hacking! 🚀**
205
-
206
- *Last updated: November 17, 2025*
207
-
@@ -1,218 +0,0 @@
1
- # Build a to-do list editor
2
-
3
- In this chapter we will continue with the interface or editor implementation of the **To-do List** document model. This means you will create a simple user interface for the **To-do List** document model which will be used inside the Connect app to create, update and delete your ToDoList items.
4
-
5
- ## Generate the editor template
6
-
7
- Run the command below to generate the editor template for the **To-do List** document model.
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
-
10
- Notice the `--editor` flag which specifies the **To-do List** document model, and the `--document-types` flag defines the document type `powerhouse/todolist`.
11
-
12
- ```bash
13
- ph generate --editor ToDoList --document-types powerhouse/todolist
14
- ```
15
-
16
- Once complete, navigate to the `editors/to-do-list/editor.tsx` file and open it in your editor.
17
-
18
- ### Editor implementation options
19
-
20
- When building your editor component within the Powerhouse ecosystem, you have several options for styling, allowing you to leverage your preferred methods:
21
-
22
- 1. **Default HTML Styling:** Standard HTML tags (`<h1>`, `<p>`, `<button>`, etc.) will render with default styles offered through the boilerplate.
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.
24
- 3. **Custom CSS Files:** You can import traditional CSS files (`.css`) to apply custom styles or integrate existing style libraries.
25
-
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.
27
- Manual build steps are typically only needed when publishing packages.
28
-
29
- ## To-do List editor
30
-
31
- Below is the complete code for the To-Do List editor. Paste this code in `editors/to-do-list/editor.tsx`.
32
-
33
- <details>
34
- <summary>Complete ToDoList Editor Example (using Tailwind CSS)</summary>
35
-
36
- ```typescript
37
- import { EditorProps } from 'document-model';
38
- import {
39
- ToDoListState,
40
- ToDoListAction,
41
- ToDoListLocalState,
42
- ToDoItem,
43
- actions,
44
- ToDoListDocument,
45
- } from '../../document-models/to-do-list/index.js';
46
- import { useState } from 'react';
47
-
48
- // EditorProps is a generic type that provides the document and a dispatch function.
49
- // The dispatch function is used to send actions to the document's reducer to update the state.
50
- export type IProps = EditorProps<ToDoListDocument>;
51
-
52
- export default function Editor(props: IProps) {
53
- // Destructure document and dispatch from props.
54
- const { document, dispatch } = props;
55
- // Get the global state from the document. This state is shared across all editors of this document.
56
- const {
57
- state: { global: state },
58
- } = document;
59
-
60
- // React's useState hook is used for local component state.
61
- // This state is not shared with other components.
62
- // `todoItem` stores the text of the new to-do item being added.
63
- const [todoItem, setTodoItem] = useState('');
64
- // `editingItemId` stores the ID of the item currently being edited.
65
- const [editingItemId, setEditingItemId] = useState<string | null>(null);
66
- // `editedText` stores the text of the item while it's being edited.
67
- const [editedText, setEditedText] = useState('');
68
-
69
- return (
70
- <div className="p-4 font-sans max-w-lg mx-auto">
71
- <h1 className="text-2xl font-bold mb-4 text-center">To-do List</h1>
72
- <div className="w-96 mx-auto">
73
- <div className="flex mb-4">
74
- <input
75
- className="border border-gray-300 p-2 rounded-l-md flex-grow"
76
- placeholder="Insert task here..."
77
- value={todoItem}
78
- onChange={e => setTodoItem(e.target.value)}
79
- onKeyDown={e => {
80
- if (e.key === 'Enter') {
81
- // Dispatch an action to add a new to-do item.
82
- // `actions.addTodoItem` is an action creator from our document model.
83
- dispatch(
84
- actions.addTodoItem({
85
- id: Math.random().toString(), // In a real app, use a more robust ID generation.
86
- text: todoItem,
87
- })
88
- );
89
- setTodoItem('');
90
- }
91
- }}
92
- />
93
- <button
94
- className="bg-blue-500 hover:bg-blue-600 text-white p-2 rounded-r-md"
95
- onClick={() => {
96
- // Also add item on button click.
97
- dispatch(
98
- actions.addTodoItem({
99
- id: Math.random().toString(),
100
- text: todoItem,
101
- })
102
- );
103
- setTodoItem('');
104
- }}
105
- >
106
- Add
107
- </button>
108
- </div>
109
- <ul className="list-none p-0">
110
- {/* Map over the items in the global state to render each to-do item. */}
111
- {state.items.map((item: ToDoItem) => (
112
- <li
113
- key={item.id}
114
- className="flex items-center p-2 relative border-b border-gray-200"
115
- >
116
- <input
117
- type="checkbox"
118
- checked={item.checked}
119
- className="mr-3"
120
- onChange={() => {
121
- // Dispatch an action to update the checked status of an item.
122
- dispatch(
123
- actions.updateTodoItem({
124
- id: item.id,
125
- checked: !item.checked,
126
- })
127
- );
128
- }}
129
- />
130
- {/* Conditional rendering: show an input field if the item is being edited, otherwise show the text. */}
131
- {editingItemId === item.id ? (
132
- <input
133
- value={editedText}
134
- onChange={e =>
135
- setEditedText(e.target.value)
136
- }
137
- onKeyDown={e => {
138
- if (e.key === 'Enter') {
139
- // Dispatch an action to update the item's text.
140
- dispatch(
141
- actions.updateTodoItem({
142
- id: item.id,
143
- text: editedText,
144
- })
145
- );
146
- // Exit editing mode.
147
- setEditingItemId(null);
148
- }
149
- }}
150
- className="flex-grow"
151
- autoFocus // Automatically focus the input when it appears.
152
- />
153
- ) : (
154
- <div className="flex items-center flex-grow gap-1">
155
- <span
156
- onClick={() => {
157
- // Enter editing mode when the text is clicked.
158
- setEditingItemId(item.id);
159
- setEditedText(item.text);
160
- }}
161
- className={`cursor-pointer ${
162
- item.checked
163
- ? 'line-through text-gray-500'
164
- : ''
165
- }`}
166
- >
167
- {item.text}
168
- </span>
169
- <span
170
- onClick={() =>
171
- dispatch(
172
- actions.deleteTodoItem({
173
- id: item.id,
174
- })
175
- )
176
- }
177
- className="text-gray-400 cursor-pointer opacity-40 transition-all duration-200 text-base font-bold inline-flex items-center pl-1 hover:opacity-100 hover:text-red-500"
178
- >
179
- ×
180
- </span>
181
- </div>
182
- )}
183
- </li>
184
- ))}
185
- </ul>
186
- </div>
187
- </div>
188
- );
189
- }
190
- ```
191
-
192
- </details>
193
-
194
- Now you can run the Connect app and see the **To-do List** editor in action.
195
-
196
- ```bash
197
- ph connect
198
- ```
199
-
200
- In Connect, in the bottom right corner you'll find a new Document Model that you can create: **To-do List**.
201
- Click on it to create a new To-do List document.
202
-
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.
205
- :::
206
-
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.
209
-
210
- ### Up next: Mastery Track
211
-
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
-
214
- You will learn:
215
-
216
- - The in's & out's of a document model.
217
- - How to use UI & Scalar components from the Document Engineering system.
218
- - How to build Custom Drive Apps or Drive Explorers.
@@ -1,58 +0,0 @@
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
-
@@ -1,65 +0,0 @@
1
- # Referencing Monorepo Packages
2
-
3
- ## **Context**
4
-
5
- In scenarios where a project is not part of the monorepo but needs to reference monorepo packages (e.g., using `@powerhousedeao/ph-cli`), there's a streamlined approach that avoids duplicating dependencies and maintains consistency with monorepo versions.
6
-
7
- ---
8
-
9
- ## **Approach**
10
-
11
- ### **1. Using `link:` in `package.json`**
12
-
13
- Instead of manually copying dependencies or trying complex build setups, you can use the `link:` protocol to create a symlink to the monorepo package.
14
-
15
- ```json
16
- {
17
- "dependencies": {
18
- "@powerhousedeao/ph-cli": "link:../monorepo/clis/ph-cli"
19
- }
20
- }
21
- ```
22
-
23
- This approach creates a symlink under the node_modules directory, linking directly to the specified monorepo package.
24
-
25
- ### **2. Running the Linked CLI**
26
-
27
- After linking, you can run the CLI tool using pnpm:
28
-
29
- ```bash
30
- pnpm install
31
- pnpm run ../powerhouse/clis/ph-cli
32
- ```
33
-
34
- Alternatively, use the command through the linked CLI:
35
-
36
- ```bash
37
- ph connect
38
- ```
39
-
40
- This will invoke the connect package from the monorepo.
41
-
42
- ### **3. Building Dependencies**
43
-
44
- To ensure all dependencies are correctly built:
45
-
46
- ```bash
47
- nx run @powerhousedeao/ph-cli
48
- ```
49
-
50
- This command will build all necessary dependencies within the monorepo.
51
-
52
- ### **4. Key Insights**
53
-
54
- - **Symlink Simplicity:** The link: protocol is the least disruptive, as it avoids version conflicts and unnecessary duplication.
55
- - **Development Workflow:** Changes made to the connect code in the monorepo will be picked up automatically when using the linked CLI, as ph-cli defers calls to the respective packages.
56
-
57
- ### **5. Troubleshooting**
58
-
59
- If dependencies aren't picked up correctly: Ensure the symlink path is accurate relative to the project root.
60
-
61
- For isolated package builds: Use nx run to trigger specific package builds when needed.
62
-
63
- ### **6. Conclusion**
64
- Using link: is an effective, developer-friendly method to reference monorepo packages in external boilerplate projects. It supports efficient development workflows, reduces redundancy, and ensures consistency across environments.
65
-
@@ -1,61 +0,0 @@
1
- # Moving Beyond CRUD
2
-
3
- Powerhouse uses "single field operations" as granular actions that go beyond traditional CRUD (Create, Read, Update, Delete) operations.
4
- In a basic CRUD framework, the focus is on making entire objects or records editable as a whole, often leading to oversimplified data management that can't easily handle complex workflows or state transitions.
5
-
6
- ## What Are Single Field Operations?
7
- These are focused, granular updates to individual fields within a document rather than treating the document as a whole. This approach allows for precise control and tracking of changes. For example:
8
-
9
- - Setting a Document Number (simple string input)
10
- - Changing Master Status (an enum dropdown selection)
11
-
12
- Each of these operations targets only one field and has a corresponding form that collects and submits the new value.
13
-
14
- ## Why go beyond CRUD?
15
-
16
- ### Granular State Tracking:
17
- Powerhouse's system emphasizes understanding how documents transition from one state to another in fine detail. By breaking down actions into specific field-level operations, it allows for tracking the exact sequence of changes, which is crucial for things like auditing, version control, and complex workflows.
18
-
19
- ### Operational Focus:
20
- The system is designed around the idea of operations themselves—not just the data they manipulate. While traditional CRUD frameworks might treat each field as independently updatable without any logic or process attached, Powerhouse assigns specific operations that can enforce business rules and state transitions.
21
-
22
- ### Customization & Flexibility:
23
- CRUD frameworks are often too rigid for real-world applications that need more nuanced behaviors. Powerhouse offers both the simplicity of CRUD for standard operations and the ability to go deeper, defining more complex, field-specific operations when needed. This hybrid approach ensures flexibility without sacrificing systematic structure.
24
-
25
- ### Automation Potential:
26
- Even though creating these granular operations might seem tedious, the goal is to build a system where standard CRUD operations can eventually be auto-generated, leaving developers to focus only on defining the exceptional, non-standard behaviors.
27
-
28
- ### Improved Permissions and User Intent:
29
- By having specific operations tied to individual fields, it becomes easier to manage permissions (e.g., who can change the master status but not the content) and to capture user intent more precisely, which is valuable in complex collaborative environments.
30
-
31
-
32
- ## Understanding the Code Example
33
-
34
- ![Alt text for the image](./images/image.png)
35
-
36
- | `SetDocNumberForm.tsx` (StringField) | `SetMasterStatusForm.tsx` (EnumField) |
37
- |-------------------------------------|---------------------------------------|
38
- | **Purpose:** To update the document number (a string field).<br /><br />**How it works:**<br />- A form is rendered with a StringField input<br />- The defaultValue comes from the document model (props.defaultValue.docNo)<br />- On submit (or onBlur), the new document number is dispatched via the dispatch function<br />- It uses a generic onSubmit handler that processes the collected input and triggers the document update<br /><br />**Key takeaway:**<br />- This is a simple, single field form that maps a scalar string to a reusable component (StringField)<br />- The form structure is systematic: label, name, placeholder, and onBlur event handler | **Purpose:** To update the master status (an enum field).<br /><br />**How it works:**<br />- A form is rendered with an EnumField dropdown<br />- The dropdown options are enum values like "APPROVED", "DEFERRED", etc.<br />- The default value is pre-filled from props.defaultValue.masterStatus<br />- On change, the form dispatches the updated status<br /><br />**Key takeaway:**<br />- This form uses an EnumField component, showcasing how different scalar types (in this case, enums) map to different input components<br />- Options are provided systematically, meaning they could potentially be auto-generated from the document model |
39
-
40
-
41
-
42
- ## Why Is This Granular Approach Important?
43
- 1. **Systematic Yet Customizable:**
44
- Even we are manually building these forms now, the structure is simple and repeatable:
45
- - Identify the scalar type (string, enum, etc.).
46
- - Map it to a reusable component.
47
- - Use a standardized form structure with an onSubmit handler and a dispatch function.
48
- 2. **Auto-Generation Potential:**
49
- The systematic nature of these forms means they could be automatically generated in the future.
50
- - For example, if a field is identified as a string, the system could auto-generate a form using a StringField.
51
- - For enums, it could auto-generate the EnumField with all valid options.
52
-
53
-
54
- ## How to implement single field operations
55
-
56
- ### At the schema definition level
57
-
58
- ### At the frontend level
59
-
60
-
61
-