@powerhousedao/academy 4.1.0-dev.117 โ 4.1.0-dev.118
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 +4 -0
- package/docs/academy/00-EthereumArgentinaHackathon.md +183 -0
- package/docs/academy/01-GetStarted/05-VetraStudio.md +76 -27
- package/package.json +1 -1
- package/sidebars.ts +8 -0
- package/src/css/custom.css +20 -0
- package/static/img/ethereum-logo.jpeg +0 -0
- package/docs/academy/09-AIResources +0 -131
- package/docs/academy/TUTORIAL_VERIFICATION_ARCHITECTURE +0 -325
package/CHANGELOG.md
CHANGED
|
@@ -1,3 +1,7 @@
|
|
|
1
|
+
## 4.1.0-dev.118 (2025-11-14)
|
|
2
|
+
|
|
3
|
+
This was a version bump only for @powerhousedao/academy to align it with other projects, there were no code changes.
|
|
4
|
+
|
|
1
5
|
## 4.1.0-dev.117 (2025-11-13)
|
|
2
6
|
|
|
3
7
|
This was a version bump only for @powerhousedao/academy to align it with other projects, there were no code changes.
|
|
@@ -0,0 +1,183 @@
|
|
|
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 Powerhouse framework. Our team will be available online and at the mentor's table to help you navigate the 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**: TBD
|
|
22
|
+
- **Hackathon informations**: https://taikai.network/ethargentina/hackathons/tierra-de-buidlers-2025/overview
|
|
23
|
+
- Discord: [Join our server](#)
|
|
24
|
+
|
|
25
|
+
## ๐ Getting Started
|
|
26
|
+
|
|
27
|
+
<details>
|
|
28
|
+
<summary> Vetra Introduction & Follow Along Demo </summary>
|
|
29
|
+
|
|
30
|
+
Here you will soon find our follow along introduction Demo Video
|
|
31
|
+
|
|
32
|
+
### Before the Hackathon
|
|
33
|
+
|
|
34
|
+
1. **Set Up Your Environment**
|
|
35
|
+
- Install the Powerhouse CLI
|
|
36
|
+
- Set up your development environment
|
|
37
|
+
- Review the [Get Started Guide](./01-GetStarted/home.mdx)
|
|
38
|
+
|
|
39
|
+
2. **Explore the Platform**
|
|
40
|
+
- Check out the [Demo Package](./01-GetStarted/00-ExploreDemoPackage.mdx)
|
|
41
|
+
- Familiarize yourself with [Document Models](./02-MasteryTrack/02-DocumentModelCreation/01-WhatIsADocumentModel.md)
|
|
42
|
+
|
|
43
|
+
3. **Join Our Community**
|
|
44
|
+
- Discord: [Join our server](#)
|
|
45
|
+
|
|
46
|
+
|
|
47
|
+
</details>
|
|
48
|
+
|
|
49
|
+
|
|
50
|
+
|
|
51
|
+
## **Example Project Ideas**
|
|
52
|
+
|
|
53
|
+
Powerhouse is perfect for building:
|
|
54
|
+
|
|
55
|
+
- **Real World Use-cases**: Every document can act as a mini ledger/blockchain.
|
|
56
|
+
- **Decentralized Applications**: Create apps with built-in version control and collaboration
|
|
57
|
+
- **Document-Based Systems**: Build structured data applications
|
|
58
|
+
- **Collaborative Tools**: Enable real-time multi-user editing
|
|
59
|
+
- **Data Management Platforms**: Create systems with queryable, structured data
|
|
60
|
+
|
|
61
|
+
### Coordination & DAO Design
|
|
62
|
+
|
|
63
|
+
- ๐งฉ **What if** DAOs weren't chaotic? What documents would you need to make them coordinate like space X and ship like stripe?
|
|
64
|
+
- ๐ฏ **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?
|
|
65
|
+
|
|
66
|
+
:::tip IDEA
|
|
67
|
+
The ultimate DAO Template toolkit where vision & mission documents influence guidelines & onboarding for contributors.
|
|
68
|
+
:::
|
|
69
|
+
|
|
70
|
+
---
|
|
71
|
+
|
|
72
|
+
### GovTech & Public Infrastructure
|
|
73
|
+
|
|
74
|
+
- ๐ณ **What if** local governments had to reach consensus with residents before making a decision? How would that look like?
|
|
75
|
+
- ๐ง **What if** you could submit pothole fixes or transit complaints into a civic DAO, and track the response like GitHub issues?
|
|
76
|
+
- ๐งพ **What if** municipal budgets were editable public documents with community feedback loops?
|
|
77
|
+
|
|
78
|
+
:::tip IDEA
|
|
79
|
+
An Open Source Enterprise Resource Planning-suite for municipalities & governments
|
|
80
|
+
:::
|
|
81
|
+
|
|
82
|
+
---
|
|
83
|
+
|
|
84
|
+
### Education & Group Work
|
|
85
|
+
|
|
86
|
+
- ๐ **What if** your group project auto-divided work, tracked contributions, and paid out in real-time?
|
|
87
|
+
- ๐พ **What if** "homework" was a multiplayer quest, and grades came from the DAO?
|
|
88
|
+
- ๐ซ **What if** we DAO-ified a classroom and let the students vote on rules, roles, and rewards?
|
|
89
|
+
|
|
90
|
+
:::tip IDEA
|
|
91
|
+
The remote classroom SAAS back-end that fosters connection, gives purpose to bullies and empowers younger generation to dream big again.
|
|
92
|
+
:::
|
|
93
|
+
|
|
94
|
+
---
|
|
95
|
+
|
|
96
|
+
### ๐ธ Grants, Crypto, and Incentive Design
|
|
97
|
+
|
|
98
|
+
- ๐ฐ **What if** grant tooling felt like bounty hunting across a galaxy of projects?
|
|
99
|
+
- ๐ **What if** every grant had a live budget dashboard, contributor feed, and impact score?
|
|
100
|
+
- ๐ฎ **What if** you could stake on coordination itself, betting that people will work together well?
|
|
101
|
+
|
|
102
|
+
:::tip IDEA
|
|
103
|
+
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.
|
|
104
|
+
:::
|
|
105
|
+
|
|
106
|
+
---
|
|
107
|
+
|
|
108
|
+
### ๐ธ Lawmaking, Legislation & Legal
|
|
109
|
+
|
|
110
|
+
- ๐งโโ๏ธ **What if** any government or DAO could fork a legal template, customize it, and track changes in a public, composable way?
|
|
111
|
+
- ๐จ **What if** legislation could be transparently co-created by citizens, NGOs, and governments all with aligned incentives?
|
|
112
|
+
- ๐ป **What if** legislation, contracts & templates could exist on an open-source market place like software?
|
|
113
|
+
- ๐ค **What if** a network agent could create a legal vehicle by simply inputing set of requirements and risk preferences (in non legalese)?
|
|
114
|
+
- ๐ค **What if** 2 agents in a network could negotiate terms of an agreement according to predefined functions and risk parameters, without lawyers?
|
|
115
|
+
|
|
116
|
+
:::tip IDEA
|
|
117
|
+
Build a Decentralized Lawmaking Engine using Reactive Document Models
|
|
118
|
+
:::
|
|
119
|
+
|
|
120
|
+
|
|
121
|
+
## ๐ ๏ธ Resources
|
|
122
|
+
|
|
123
|
+
### Documentation
|
|
124
|
+
|
|
125
|
+
- [Quick Start Guide](./01-GetStarted/home.mdx)
|
|
126
|
+
- [Create a New Project](./01-GetStarted/01-CreateNewPowerhouseProject.md)
|
|
127
|
+
- [Define Document Models](./01-GetStarted/02-DefineToDoListDocumentModel.md)
|
|
128
|
+
- [Build Editors](./01-GetStarted/04-BuildToDoListEditor.md)
|
|
129
|
+
- [API References](./04-APIReferences/00-PowerhouseCLI.md)
|
|
130
|
+
|
|
131
|
+
### Tutorials
|
|
132
|
+
|
|
133
|
+
- [To-Do List Example](./01-GetStarted/02-DefineToDoListDocumentModel.md)
|
|
134
|
+
- [Chatroom Use Case](./03-ExampleUsecases/Chatroom/02-CreateNewPowerhouseProject.md)
|
|
135
|
+
|
|
136
|
+
## ๐ Judging Criteria
|
|
137
|
+
|
|
138
|
+
Projects will be evaluated based on:
|
|
139
|
+
|
|
140
|
+
- **Usefulness & Impact**: How well does it solve a certain job or problem?
|
|
141
|
+
- **Composability/Structure**: How are the different document models and / or drive apps collaborating?
|
|
142
|
+
- **Clarity of the developer or user experience**: Did you unlock the secret sauce of UX & reactive documents?
|
|
143
|
+
- **Alignment with Vetra/Powerhouse principles**: Local-first, auditable, usefull for common good.
|
|
144
|
+
|
|
145
|
+
## ๐ Submission Guidelines
|
|
146
|
+
|
|
147
|
+
### What to Submit
|
|
148
|
+
|
|
149
|
+
- GitHub repository with your code
|
|
150
|
+
- (Video) presentation (2-3 minutes)
|
|
151
|
+
- README with:
|
|
152
|
+
- Project description
|
|
153
|
+
- Setup instructions
|
|
154
|
+
- Screenshots/demos
|
|
155
|
+
- Technologies used
|
|
156
|
+
|
|
157
|
+
The Powerhouse team will add you as a builder on the Vetra platform and host your application and drive.
|
|
158
|
+
|
|
159
|
+
|
|
160
|
+
## Tips for Success
|
|
161
|
+
|
|
162
|
+
### Development Tips
|
|
163
|
+
|
|
164
|
+
1. **Start Simple**: Begin with a basic implementation and iterate
|
|
165
|
+
2. **Use Templates**: Leverage existing examples and templates
|
|
166
|
+
3. **Ask Questions**: Don't hesitate to reach out for help
|
|
167
|
+
4. **Test Early**: Test your application frequently during development
|
|
168
|
+
5. **Document**: Keep notes on your decisions and implementations
|
|
169
|
+
|
|
170
|
+
### Presentation Tips
|
|
171
|
+
|
|
172
|
+
1. **Show, Don't Tell**: Live demos are more impactful than slides
|
|
173
|
+
2. **Tell a Story**: Explain the problem you're solving
|
|
174
|
+
3. **Highlight Innovation**: Show what makes your solution unique
|
|
175
|
+
4. **Be Concise**: Respect the time limits for presentations
|
|
176
|
+
5. **Prepare Backup**: Have screenshots/video in case of technical issues
|
|
177
|
+
|
|
178
|
+
---
|
|
179
|
+
|
|
180
|
+
**Good luck, and happy hacking! ๐**
|
|
181
|
+
|
|
182
|
+
*Last updated: November 13, 2024*
|
|
183
|
+
|
|
@@ -1,31 +1,26 @@
|
|
|
1
1
|
# Tool: Vetra Studio
|
|
2
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
3
|
:::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
4
|
|
|
9
5
|
## Vision: Specification Driven AI
|
|
10
6
|
|
|
11
|
-
|
|
7
|
+
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.
|
|
8
|
+
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**.
|
|
12
9
|
|
|
13
10
|
- Communicate your solution and intent through a structured specification framework designed for AI collaboration.
|
|
14
11
|
- Specifications enable precise, iterative edits, since all our specification documents are machine-readable and executable.
|
|
15
|
-
|
|
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.
|
|
12
|
+
:::
|
|
20
13
|
|
|
21
14
|
## Introducing Vetra Studio
|
|
22
15
|
|
|
23
|
-
**Vetra Studio
|
|
24
|
-
|
|
16
|
+
**Vetra Studio Drive**: Serves as a hub for developers to access, manage & share specification through a remote Vetra drive.
|
|
17
|
+
**Vetra Package Library**: Store, publish and fork git repositories of packages in the Vetra Package Library.
|
|
18
|
+
Visit the [Vetra Package Library here](https://vetra.io/packages)
|
|
25
19
|
|
|
26
|
-
|
|
20
|
+
**Vetra Studio Drive** 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 Drive.
|
|
27
21
|
|
|
28
22
|
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.
|
|
23
|
+
For now they offer you a template for code generation.
|
|
29
24
|
|
|
30
25
|
<figure className="image-container">
|
|
31
26
|
<img
|
|
@@ -37,14 +32,14 @@ As Vetra Studio matures each of these specification documents will offer an inte
|
|
|
37
32
|
|
|
38
33
|
### Module Categories
|
|
39
34
|
|
|
40
|
-
|
|
35
|
+
### 1. Document Models
|
|
41
36
|
- **Document model specification**: Defines the structure and operations of a document model using GraphQL SDL, ensuring consistent data management and processing.
|
|
42
37
|
|
|
43
|
-
|
|
38
|
+
### 2. User Experiences
|
|
44
39
|
- **Editor specification**: Outlines the interface and functionalities of a document model editor, allowing users to interact with and modify document data.
|
|
45
40
|
- **Drive-app specification**: Specifies the UI and interactions for managing documents within a Drive, providing tailored views and functionalities.
|
|
46
41
|
|
|
47
|
-
|
|
42
|
+
### 3. Data integrations
|
|
48
43
|
- **Subgraph specification**: Details the connections and relationships within a subgraph, facilitating efficient data querying and manipulation.
|
|
49
44
|
- **Codegen Processor Specification**: Describes the process for automatically generating code from document model specifications, ensuring alignment with intended architecture.
|
|
50
45
|
- **RelationalDb Processor Specification**: Defines how relational databases are structured and queried, supporting efficient data management and retrieval.
|
|
@@ -57,6 +52,31 @@ As Vetra Studio matures each of these specification documents will offer an inte
|
|
|
57
52
|
<figcaption>The Vetra Studio Drive, a builder app that collects all of the specification of a package.</figcaption>
|
|
58
53
|
</figure>
|
|
59
54
|
|
|
55
|
+
### Configure a Vetra drive in your project
|
|
56
|
+
|
|
57
|
+
You can connect to a remote vetra drive instead of using the local one auto-generated when you run `ph vetra`
|
|
58
|
+
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.
|
|
59
|
+
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.
|
|
60
|
+
The powerhouse config includes a Vetra URL for consistent project configuration across different environments.
|
|
61
|
+
|
|
62
|
+
```vetra: {
|
|
63
|
+
driveId: string;
|
|
64
|
+
driveUrl: string;
|
|
65
|
+
};
|
|
66
|
+
```
|
|
67
|
+
|
|
68
|
+
Imagine you are a builder and want to work on, or continue with a set of specifications from your team mates.
|
|
69
|
+
You could then add the specific remote Vetra drive to your powerhouse configuration in the `powerhouse.config.json`file to get going.
|
|
70
|
+
|
|
71
|
+
```
|
|
72
|
+
"vetra": {
|
|
73
|
+
"driveId": "bai-specifications",
|
|
74
|
+
"driveUrl": "https://switchboard.staging.vetra.io/d/bai-specifications"
|
|
75
|
+
}
|
|
76
|
+
```
|
|
77
|
+
|
|
78
|
+
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)
|
|
79
|
+
|
|
60
80
|
## Vetra Studio Workflow
|
|
61
81
|
|
|
62
82
|
### 1. Launch Vetra Studio
|
|
@@ -72,6 +92,21 @@ In interactive mode:
|
|
|
72
92
|
- Changes require explicit confirmation before being processed
|
|
73
93
|
- Provides better control and visibility over document changes
|
|
74
94
|
|
|
95
|
+
#### Watch Mode
|
|
96
|
+
|
|
97
|
+
```bash
|
|
98
|
+
ph vetra --interactive --watch
|
|
99
|
+
```
|
|
100
|
+
In watch mode:
|
|
101
|
+
|
|
102
|
+
- Adding `--watch` to your command enables dynamic loading for document-models and editors in Vetra studio and switchboard.
|
|
103
|
+
- When enabled, the system will watch for changes in these directories and reload them dynamically.
|
|
104
|
+
|
|
105
|
+
:::warning Be Aware
|
|
106
|
+
When you are building your document model the code can break the Vetra Studio environment.
|
|
107
|
+
A full overview of the Vetra Studio commands can be found in the [Powerhouse CLI](/academy/APIReferences/PowerhouseCLI#vetra)
|
|
108
|
+
:::
|
|
109
|
+
|
|
75
110
|
#### Standard Mode
|
|
76
111
|
```bash
|
|
77
112
|
ph vetra
|
|
@@ -86,28 +121,42 @@ In standard mode:
|
|
|
86
121
|
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
122
|
|
|
88
123
|
#### 1. Start the Reactor MCP:
|
|
124
|
+
|
|
125
|
+
Make sure you are in the same directory as your project.
|
|
126
|
+
Claude will automatically recognize the necessary files and MCP tools.
|
|
127
|
+
|
|
128
|
+
```bash
|
|
129
|
+
claude
|
|
130
|
+
```
|
|
131
|
+
|
|
132
|
+
Since you're interacting with a llm it has a high capacit for interpretating your intentions.
|
|
133
|
+
Any commands in the same trend will do the job.
|
|
134
|
+
|
|
89
135
|
```bash
|
|
90
|
-
|
|
136
|
+
connect to the reactor mcp
|
|
91
137
|
```
|
|
92
138
|
|
|
93
139
|
#### 2. Verify MCP connection:
|
|
94
140
|
- Check that the Reactor MCP is available.
|
|
95
141
|
- Confirm Vetra Studio shows "Connected to Reactor MCP"
|
|
96
142
|
|
|
97
|
-
|
|
98
|
-
|
|
143
|
+
```bash
|
|
144
|
+
Connected to MCP successfully! I can see there's a
|
|
145
|
+
"vetra-4de7fa45" drive available. The reactor-mcp server is
|
|
146
|
+
running and ready for document model operations.
|
|
147
|
+
```
|
|
99
148
|
|
|
100
|
-
|
|
101
|
-
-
|
|
102
|
-
- Smart editor generation based on document models
|
|
103
|
-
- Automatically triggers code generation when documents reach valid state
|
|
149
|
+
- To learn what is a [Reactor](apps/academy/docs/academy/Architecture/WorkingWithTheReactor) read the reactor article
|
|
150
|
+
- To learn more about the [Reactor MCP](apps/academy/docs/academy/GetStarted/ReactorMCP) read the reactor MCP article
|
|
104
151
|
|
|
105
|
-
|
|
152
|
+
### Key Reactor MCP Features
|
|
106
153
|
|
|
107
|
-
|
|
108
|
-
-
|
|
154
|
+
- It supports automatic document model creation from natural language descriptions
|
|
155
|
+
- It implements a smart editor based on the underlying document models
|
|
156
|
+
- It automatically triggers code generation when documents reach valid state
|
|
109
157
|
- The MCP server enables the agent to work with both existing and newly created document models.
|
|
110
|
-
|
|
158
|
+
- Vetra supports integration with custom remote drives, allowing users to create, share and manage documents within these drives.
|
|
159
|
+
|
|
111
160
|
|
|
112
161
|
### 3. Vetra Studio Package Creation Workflow
|
|
113
162
|
|
package/package.json
CHANGED
package/sidebars.ts
CHANGED
|
@@ -11,6 +11,14 @@
|
|
|
11
11
|
const sidebars = {
|
|
12
12
|
// By default, Docusaurus generates a sidebar from the docs folder structure
|
|
13
13
|
academySidebar: [
|
|
14
|
+
{
|
|
15
|
+
type: "doc",
|
|
16
|
+
id: "academy/EthereumArgentinaHackathon",
|
|
17
|
+
label: "ETH Argentina Hackathon",
|
|
18
|
+
customProps: {
|
|
19
|
+
icon: "/img/ethereum-logo.jpg",
|
|
20
|
+
},
|
|
21
|
+
},
|
|
14
22
|
{
|
|
15
23
|
type: "category",
|
|
16
24
|
label: "Get started",
|
package/src/css/custom.css
CHANGED
|
@@ -525,3 +525,23 @@ html[data-theme="dark"] .DocSearch-Hits > *:empty {
|
|
|
525
525
|
margin-top: 0.5rem;
|
|
526
526
|
font-style: italic;
|
|
527
527
|
}
|
|
528
|
+
|
|
529
|
+
/* Ethereum Argentina Hackathon sidebar icon */
|
|
530
|
+
.menu__link[href*="EthereumArgentinaHackathon"] {
|
|
531
|
+
display: flex !important;
|
|
532
|
+
align-items: center !important;
|
|
533
|
+
gap: 8px !important;
|
|
534
|
+
}
|
|
535
|
+
|
|
536
|
+
.menu__link[href*="EthereumArgentinaHackathon"]::before {
|
|
537
|
+
content: "" !important;
|
|
538
|
+
display: inline-block !important;
|
|
539
|
+
width: 24px !important;
|
|
540
|
+
height: 24px !important;
|
|
541
|
+
min-width: 24px !important;
|
|
542
|
+
background-image: url("/img/ethereum-logo.jpeg") !important;
|
|
543
|
+
background-size: cover !important;
|
|
544
|
+
background-position: center !important;
|
|
545
|
+
border-radius: 50% !important;
|
|
546
|
+
flex-shrink: 0 !important;
|
|
547
|
+
}
|
|
Binary file
|
|
@@ -1,131 +0,0 @@
|
|
|
1
|
-
# AI Resources
|
|
2
|
-
|
|
3
|
-
We have a couple of AI resources to help you with your daily work or exploring our ecosystem.
|
|
4
|
-
|
|
5
|
-
:::warning
|
|
6
|
-
- Be aware that AI tooling can make mistakes.
|
|
7
|
-
- Documentation can be out of date or code can be work in progress.
|
|
8
|
-
- Always verify your coding agent's suggestions.
|
|
9
|
-
:::
|
|
10
|
-
|
|
11
|
-
|
|
12
|
-
| Tool | Description |
|
|
13
|
-
|---|---|
|
|
14
|
-
| [**Deepwiki**](https://deepwiki.com/powerhouse-inc/powerhouse) | A searchable/queriable wiki to understand our growing Powerhouse **Monorepository** better. <br /> DeepWiki provides up-to-date documentation you can talk to, for every repo in the world. Think Deep Research for GitHub. |
|
|
15
|
-
| [**Context7**](https://context7.com/powerhouse-inc/powerhouse) | The Powerhouse **Academy Documentation** is also available as context through the context7 MCP Server. <br /> LLMs rely on outdated or generic information about the libraries you use. <br /> Context7 pulls up-to-date, version-specific documentation and code examples directly from the source. <br /> Paste accurate, relevant documentation directly into tools like Cursor, Claude, or any LLM. <br /> The official repository can be found [here](https://github.com/upstash/context7). |
|
|
16
|
-
|
|
17
|
-
|
|
18
|
-
### Context7 Installation
|
|
19
|
-
|
|
20
|
-
<details>
|
|
21
|
-
<summary><b>Install in Cursor</b></summary>
|
|
22
|
-
|
|
23
|
-
Go to: `Settings` -> `Cursor Settings` -> `MCP` -> `Add new global MCP server`
|
|
24
|
-
|
|
25
|
-
Pasting the following configuration into your Cursor `~/.cursor/mcp.json` file is the recommended approach. You may also install in a specific project by creating `.cursor/mcp.json` in your project folder.
|
|
26
|
-
|
|
27
|
-
**Cursor Local Server Connection**
|
|
28
|
-
|
|
29
|
-
```json
|
|
30
|
-
{
|
|
31
|
-
"mcpServers": {
|
|
32
|
-
"context7": {
|
|
33
|
-
"command": "npx",
|
|
34
|
-
"args": ["-y", "@upstash/context7-mcp"]
|
|
35
|
-
}
|
|
36
|
-
}
|
|
37
|
-
}
|
|
38
|
-
```
|
|
39
|
-
|
|
40
|
-
</details>
|
|
41
|
-
|
|
42
|
-
<details>
|
|
43
|
-
<summary><b>Install in VS Code</b></summary>
|
|
44
|
-
|
|
45
|
-
Add this to your VS Code MCP config file. See [VS Code MCP docs](https://code.visualstudio.com/docs/copilot/chat/mcp-servers) for more info.
|
|
46
|
-
|
|
47
|
-
**VS Code Local Server Connection**
|
|
48
|
-
|
|
49
|
-
```json
|
|
50
|
-
"mcp": {
|
|
51
|
-
"servers": {
|
|
52
|
-
"context7": {
|
|
53
|
-
"type": "stdio",
|
|
54
|
-
"command": "npx",
|
|
55
|
-
"args": ["-y", "@upstash/context7-mcp"]
|
|
56
|
-
}
|
|
57
|
-
}
|
|
58
|
-
}
|
|
59
|
-
```
|
|
60
|
-
</details>
|
|
61
|
-
|
|
62
|
-
For other editors, please refer to the [official documentation](https://github.com/upstash/context7#%-installation).
|
|
63
|
-
|
|
64
|
-
### Context7 Troubleshooting
|
|
65
|
-
|
|
66
|
-
<details>
|
|
67
|
-
<summary><b>MCP, Documentation or Module Not Found Errors</b></summary>
|
|
68
|
-
|
|
69
|
-
If you encounter `ERR_MODULE_NOT_FOUND`, try using `bunx` instead of `npx`:
|
|
70
|
-
|
|
71
|
-
```json
|
|
72
|
-
{
|
|
73
|
-
"mcpServers": {
|
|
74
|
-
"context7": {
|
|
75
|
-
"command": "bunx",
|
|
76
|
-
"args": ["-y", "@upstash/context7-mcp"]
|
|
77
|
-
}
|
|
78
|
-
}
|
|
79
|
-
}
|
|
80
|
-
```
|
|
81
|
-
|
|
82
|
-
This often resolves module resolution issues in environments where `npx` doesn't properly install or resolve packages.
|
|
83
|
-
|
|
84
|
-
</details>
|
|
85
|
-
|
|
86
|
-
<details>
|
|
87
|
-
<summary><b>ESM Resolution Issues</b></summary>
|
|
88
|
-
|
|
89
|
-
For errors like `Error: Cannot find module 'uriTemplate.js'`, try the `--experimental-vm-modules` flag:
|
|
90
|
-
|
|
91
|
-
```json
|
|
92
|
-
{
|
|
93
|
-
"mcpServers": {
|
|
94
|
-
"context7": {
|
|
95
|
-
"command": "npx",
|
|
96
|
-
"args": ["-y", "--node-options=--experimental-vm-modules", "@upstash/context7-mcp@1.0.6"]
|
|
97
|
-
}
|
|
98
|
-
}
|
|
99
|
-
}
|
|
100
|
-
```
|
|
101
|
-
|
|
102
|
-
</details>
|
|
103
|
-
|
|
104
|
-
<details>
|
|
105
|
-
<summary><b>TLS/Certificate Issues</b></summary>
|
|
106
|
-
|
|
107
|
-
Use the `--experimental-fetch` flag to bypass TLS-related problems:
|
|
108
|
-
|
|
109
|
-
```json
|
|
110
|
-
{
|
|
111
|
-
"mcpServers": {
|
|
112
|
-
"context7": {
|
|
113
|
-
"command": "npx",
|
|
114
|
-
"args": ["-y", "--node-options=--experimental-fetch", "@upstash/context7-mcp"]
|
|
115
|
-
}
|
|
116
|
-
}
|
|
117
|
-
}
|
|
118
|
-
```
|
|
119
|
-
|
|
120
|
-
</details>
|
|
121
|
-
|
|
122
|
-
<details>
|
|
123
|
-
<summary><b>General MCP Client Errors</b></summary>
|
|
124
|
-
|
|
125
|
-
1. Try adding `@latest` to the package name
|
|
126
|
-
2. Use `bunx` as an alternative to `npx`
|
|
127
|
-
3. Consider using `deno` as another alternative
|
|
128
|
-
4. Ensure you're using Node.js v18 or higher for native fetch support
|
|
129
|
-
|
|
130
|
-
</details>
|
|
131
|
-
|
|
@@ -1,325 +0,0 @@
|
|
|
1
|
-
# Tutorial Verification System - Technical Architecture
|
|
2
|
-
|
|
3
|
-
## Overview
|
|
4
|
-
|
|
5
|
-
This document outlines the technical architecture for an automated tutorial verification system that ensures the Powerhouse Academy tutorials remain accurate and functional as the codebase evolves.
|
|
6
|
-
|
|
7
|
-
## System Architecture
|
|
8
|
-
|
|
9
|
-
### 1. Test Execution Environment
|
|
10
|
-
|
|
11
|
-
```
|
|
12
|
-
โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
|
|
13
|
-
โ GitHub Actions Runner (Ubuntu) โ
|
|
14
|
-
โ โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ โ
|
|
15
|
-
โ โ Isolated Docker Container โ โ
|
|
16
|
-
โ โ โโโ Node.js 22 โ โ
|
|
17
|
-
โ โ โโโ pnpm โ โ
|
|
18
|
-
โ โ โโโ Powerhouse CLI (ph-cli) โ โ
|
|
19
|
-
โ โ โโโ Playwright browsers โ โ
|
|
20
|
-
โ โ โโโ Temporary filesystem โ โ
|
|
21
|
-
โ โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ โ
|
|
22
|
-
โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
|
|
23
|
-
```
|
|
24
|
-
|
|
25
|
-
**Execution Environments:**
|
|
26
|
-
- **Development**: Local machine (`pnpm test:e2e`)
|
|
27
|
-
- **CI/CD**: GitHub Actions runners (automatically on PRs)
|
|
28
|
-
- **Scheduled**: Nightly runs to catch regressions
|
|
29
|
-
|
|
30
|
-
### 2. Tutorial Agent Architecture
|
|
31
|
-
|
|
32
|
-
The "agent" is a test orchestrator that processes tutorials through a structured workflow:
|
|
33
|
-
|
|
34
|
-
```typescript
|
|
35
|
-
// packages/tutorial-verifier/src/tutorial-agent.ts
|
|
36
|
-
class TutorialAgent {
|
|
37
|
-
async verifyTutorial(tutorialPath: string) {
|
|
38
|
-
// 1. Parse tutorial markdown
|
|
39
|
-
const steps = await this.parseTutorialSteps(tutorialPath);
|
|
40
|
-
|
|
41
|
-
// 2. Create isolated environment
|
|
42
|
-
const sandbox = await this.createSandbox();
|
|
43
|
-
|
|
44
|
-
// 3. Execute each step sequentially
|
|
45
|
-
for (const step of steps) {
|
|
46
|
-
await this.executeStep(step, sandbox);
|
|
47
|
-
await this.verifyStepOutcome(step, sandbox);
|
|
48
|
-
}
|
|
49
|
-
|
|
50
|
-
// 4. Generate report
|
|
51
|
-
return this.generateReport();
|
|
52
|
-
}
|
|
53
|
-
}
|
|
54
|
-
```
|
|
55
|
-
|
|
56
|
-
## Component Integration
|
|
57
|
-
|
|
58
|
-
### 3. E2E Test Framework Integration
|
|
59
|
-
|
|
60
|
-
**Extends existing Playwright E2E infrastructure:**
|
|
61
|
-
|
|
62
|
-
```typescript
|
|
63
|
-
// test/connect-e2e/tests/tutorial-get-started.spec.ts
|
|
64
|
-
import { test, expect } from '@playwright/test';
|
|
65
|
-
|
|
66
|
-
test('Tutorial: Create new to-do list document', async ({ page }) => {
|
|
67
|
-
const agent = new TutorialAgent();
|
|
68
|
-
|
|
69
|
-
// Phase 1: CLI Commands (no browser needed)
|
|
70
|
-
await agent.executeCliStep('ph init my-todo-project');
|
|
71
|
-
await agent.verifyFileExists('my-todo-project/package.json');
|
|
72
|
-
|
|
73
|
-
// Phase 2: Browser Automation (uses Playwright)
|
|
74
|
-
await agent.startConnect(); // Starts ph connect in background
|
|
75
|
-
await page.goto('http://localhost:3000');
|
|
76
|
-
|
|
77
|
-
// Phase 3: UI Verification (Playwright E2E)
|
|
78
|
-
await page.click('text=Local Drive');
|
|
79
|
-
await page.click('button:has-text("DocumentModel")');
|
|
80
|
-
await expect(page.locator('text=Document Model Editor')).toBeVisible();
|
|
81
|
-
|
|
82
|
-
// Phase 4: Cleanup
|
|
83
|
-
await agent.cleanup();
|
|
84
|
-
});
|
|
85
|
-
```
|
|
86
|
-
|
|
87
|
-
### 4. Playwright Browser Automation
|
|
88
|
-
|
|
89
|
-
**UI automation for Connect Studio interactions:**
|
|
90
|
-
|
|
91
|
-
```typescript
|
|
92
|
-
// UI automation for Connect Studio
|
|
93
|
-
class ConnectUIAgent {
|
|
94
|
-
constructor(private page: Page) {}
|
|
95
|
-
|
|
96
|
-
async createDocumentModel(name: string) {
|
|
97
|
-
// Navigate to document creation
|
|
98
|
-
await this.page.click('button:has-text("DocumentModel")');
|
|
99
|
-
|
|
100
|
-
// Fill in model details
|
|
101
|
-
await this.page.fill('input[placeholder="Document Name"]', name);
|
|
102
|
-
await this.page.fill('input[placeholder="Document Type"]', `powerhouse/${name.toLowerCase()}`);
|
|
103
|
-
|
|
104
|
-
// Define schema in code editor
|
|
105
|
-
await this.page.click('.monaco-editor');
|
|
106
|
-
await this.page.keyboard.type(`
|
|
107
|
-
type ${name}State {
|
|
108
|
-
items: [TodoItem!]!
|
|
109
|
-
}
|
|
110
|
-
`);
|
|
111
|
-
|
|
112
|
-
// Save and verify
|
|
113
|
-
await this.page.click('button:has-text("Save")');
|
|
114
|
-
await expect(this.page.locator(`text=${name}.phdm.zip`)).toBeVisible();
|
|
115
|
-
}
|
|
116
|
-
}
|
|
117
|
-
```
|
|
118
|
-
|
|
119
|
-
## Execution Flow
|
|
120
|
-
|
|
121
|
-
### 5. Tutorial Processing Pipeline
|
|
122
|
-
|
|
123
|
-
```
|
|
124
|
-
Tutorial Markdown File
|
|
125
|
-
โ
|
|
126
|
-
[Tutorial Parser]
|
|
127
|
-
โ
|
|
128
|
-
โโโโโโโโโโโโโโโโโโโ
|
|
129
|
-
โ Execution Steps โ
|
|
130
|
-
โโโโโโโโโโโโโโโโโโโค
|
|
131
|
-
โ 1. CLI Commands โ โ Uses child_process.spawn()
|
|
132
|
-
โ 2. File Checks โ โ Uses fs.existsSync()
|
|
133
|
-
โ 3. UI Actions โ โ Uses Playwright page.click()
|
|
134
|
-
โ 4. Verificationsโ โ Custom assertion logic
|
|
135
|
-
โโโโโโโโโโโโโโโโโโโ
|
|
136
|
-
โ
|
|
137
|
-
[Report Generator]
|
|
138
|
-
โ
|
|
139
|
-
Test Results + Screenshots
|
|
140
|
-
```
|
|
141
|
-
|
|
142
|
-
### 6. Step-by-Step Processing Example
|
|
143
|
-
|
|
144
|
-
**Tutorial Markdown:**
|
|
145
|
-
```markdown
|
|
146
|
-
## Quick start
|
|
147
|
-
Create a new Powerhouse project with a single command:
|
|
148
|
-
```bash
|
|
149
|
-
ph init
|
|
150
|
-
```
|
|
151
|
-
|
|
152
|
-
Then start Connect:
|
|
153
|
-
```bash
|
|
154
|
-
ph connect
|
|
155
|
-
```
|
|
156
|
-
|
|
157
|
-
Navigate to http://localhost:3000 and click on "Local Drive".
|
|
158
|
-
```
|
|
159
|
-
|
|
160
|
-
**Agent Processing:**
|
|
161
|
-
|
|
162
|
-
```typescript
|
|
163
|
-
// 1. Tutorial Parser extracts executable steps
|
|
164
|
-
const steps = [
|
|
165
|
-
{ type: 'cli', command: 'ph init', expectedFiles: ['package.json'] },
|
|
166
|
-
{ type: 'cli', command: 'ph connect', background: true },
|
|
167
|
-
{ type: 'browser', action: 'navigate', url: 'http://localhost:3000' },
|
|
168
|
-
{ type: 'browser', action: 'click', selector: 'text=Local Drive' }
|
|
169
|
-
];
|
|
170
|
-
|
|
171
|
-
// 2. Agent executes each step
|
|
172
|
-
for (const step of steps) {
|
|
173
|
-
switch (step.type) {
|
|
174
|
-
case 'cli':
|
|
175
|
-
const result = execSync(step.command);
|
|
176
|
-
if (step.expectedFiles) {
|
|
177
|
-
for (const file of step.expectedFiles) {
|
|
178
|
-
assert(existsSync(file), `Expected file ${file} not found`);
|
|
179
|
-
}
|
|
180
|
-
}
|
|
181
|
-
break;
|
|
182
|
-
|
|
183
|
-
case 'browser':
|
|
184
|
-
if (step.action === 'navigate') {
|
|
185
|
-
await page.goto(step.url);
|
|
186
|
-
} else if (step.action === 'click') {
|
|
187
|
-
await page.click(step.selector);
|
|
188
|
-
}
|
|
189
|
-
break;
|
|
190
|
-
}
|
|
191
|
-
}
|
|
192
|
-
```
|
|
193
|
-
|
|
194
|
-
## Deployment Architecture
|
|
195
|
-
|
|
196
|
-
### 7. Runtime Environment Distribution
|
|
197
|
-
|
|
198
|
-
```
|
|
199
|
-
โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
|
|
200
|
-
โ GitHub Actions Runner โ
|
|
201
|
-
โ โ
|
|
202
|
-
โ โโโโโโโโโโโโโโโโโโโ โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ โ
|
|
203
|
-
โ โ Tutorial Agent โ โ Sandbox Environment โ โ
|
|
204
|
-
โ โ (Node.js) โ โ โ โ
|
|
205
|
-
โ โ โ โ โโโโโโโโโโโโโโโ โ โ
|
|
206
|
-
โ โ โข Parse MD โ โ โ ph connect โ :3000 โ โ
|
|
207
|
-
โ โ โข Execute CLI โ โ โโโโโโโโโโโโโโโ โ โ
|
|
208
|
-
โ โ โข Control tests โ โ โ โ
|
|
209
|
-
โ โโโโโโโโโโโโโโโโโโโ โ โโโโโโโโโโโโโโโ โ โ
|
|
210
|
-
โ โ โ Playwright โ โ โ
|
|
211
|
-
โ โโโโโโโโโโโโโโโโโโโ โ โ Browser โ โ โ
|
|
212
|
-
โ โ Report Gen โ โ โโโโโโโโโโโโโโโ โ โ
|
|
213
|
-
โ โ โข Screenshots โ โ โ โ
|
|
214
|
-
โ โ โข Error logs โ โ /tmp/tutorial-test-xyz/ โ โ
|
|
215
|
-
โ โ โข Success rates โ โ โโโ my-todo-project/ โ โ
|
|
216
|
-
โ โโโโโโโโโโโโโโโโโโโ โ โ โโโ package.json โ โ
|
|
217
|
-
โ โ โ โโโ ... โ โ
|
|
218
|
-
โ โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ โ
|
|
219
|
-
โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
|
|
220
|
-
```
|
|
221
|
-
|
|
222
|
-
### 8. Integration with Existing Test Suite
|
|
223
|
-
|
|
224
|
-
**File Structure Extension:**
|
|
225
|
-
|
|
226
|
-
```
|
|
227
|
-
Your Current E2E Tests:
|
|
228
|
-
test/connect-e2e/tests/
|
|
229
|
-
โโโ todo-document.spec.ts โ Existing
|
|
230
|
-
โโโ drive.spec.ts โ Existing
|
|
231
|
-
โโโ app.spec.ts โ Existing
|
|
232
|
-
|
|
233
|
-
Added Tutorial Tests:
|
|
234
|
-
test/connect-e2e/tests/tutorials/
|
|
235
|
-
โโโ get-started.spec.ts โ New: Tests "Get Started" tutorial
|
|
236
|
-
โโโ mastery-track.spec.ts โ New: Tests "Mastery Track" tutorials
|
|
237
|
-
โโโ cookbook.spec.ts โ New: Tests "Cookbook" recipes
|
|
238
|
-
```
|
|
239
|
-
|
|
240
|
-
**No changes to existing code** - just additional test files that run alongside current tests.
|
|
241
|
-
|
|
242
|
-
## Performance & Timing
|
|
243
|
-
|
|
244
|
-
### 9. Execution Timeline
|
|
245
|
-
|
|
246
|
-
```
|
|
247
|
-
0s โ Start test
|
|
248
|
-
2s โ โโโ Parse tutorial markdown
|
|
249
|
-
4s โ โโโ Create temp directory
|
|
250
|
-
6s โ โโโ Run 'ph init'
|
|
251
|
-
15s โ โโโ Verify project structure
|
|
252
|
-
20s โ โโโ Start 'ph connect' (background)
|
|
253
|
-
35s โ โโโ Wait for Connect to be ready
|
|
254
|
-
40s โ โโโ Launch Playwright browser
|
|
255
|
-
45s โ โโโ Navigate to localhost:3000
|
|
256
|
-
50s โ โโโ Perform UI interactions
|
|
257
|
-
55s โ โโโ Verify expected elements
|
|
258
|
-
60s โ โโโ Take screenshots
|
|
259
|
-
65s โ โโโ Cleanup (kill processes, delete files)
|
|
260
|
-
70s โ โโโ Generate report
|
|
261
|
-
```
|
|
262
|
-
|
|
263
|
-
## Implementation Phases
|
|
264
|
-
|
|
265
|
-
### Phase 1: Proof of Concept (1-2 days)
|
|
266
|
-
- Single tutorial verification (Get Started)
|
|
267
|
-
- Basic CLI command execution
|
|
268
|
-
- Simple file existence checks
|
|
269
|
-
- Integration with existing Playwright setup
|
|
270
|
-
|
|
271
|
-
### Phase 2: Core Features (1-2 weeks)
|
|
272
|
-
- Tutorial markdown parser
|
|
273
|
-
- Comprehensive step execution engine
|
|
274
|
-
- Browser automation for Connect Studio
|
|
275
|
-
- Error reporting and screenshots
|
|
276
|
-
|
|
277
|
-
### Phase 3: Advanced Features (2-3 weeks)
|
|
278
|
-
- Multiple tutorial support
|
|
279
|
-
- Parallel execution
|
|
280
|
-
- Detailed reporting dashboard
|
|
281
|
-
- Integration with CI/CD pipeline
|
|
282
|
-
|
|
283
|
-
### Phase 4: Intelligence Layer (2-3 weeks)
|
|
284
|
-
- Failure pattern analysis
|
|
285
|
-
- Automated suggestion generation
|
|
286
|
-
- Historical trend tracking
|
|
287
|
-
- LLM-powered issue diagnosis
|
|
288
|
-
|
|
289
|
-
## Key Technical Decisions
|
|
290
|
-
|
|
291
|
-
### Technology Stack
|
|
292
|
-
- **Test Framework**: Playwright (existing)
|
|
293
|
-
- **Runtime**: Node.js 22 + TypeScript
|
|
294
|
-
- **CLI Execution**: child_process.spawn()
|
|
295
|
-
- **File Operations**: Node.js fs module
|
|
296
|
-
- **Browser Automation**: Playwright
|
|
297
|
-
- **CI/CD**: GitHub Actions (existing)
|
|
298
|
-
|
|
299
|
-
### Design Principles
|
|
300
|
-
- **Isolation**: Each test runs in isolated environment
|
|
301
|
-
- **Repeatability**: Tests can run multiple times with same results
|
|
302
|
-
- **Extensibility**: Easy to add new tutorials
|
|
303
|
-
- **Integration**: Builds on existing infrastructure
|
|
304
|
-
- **Cleanup**: Automatic resource cleanup after tests
|
|
305
|
-
|
|
306
|
-
## Success Metrics
|
|
307
|
-
|
|
308
|
-
- **Tutorial Success Rate**: % of tutorials that pass verification
|
|
309
|
-
- **Time to Detection**: How quickly outdated tutorials are identified
|
|
310
|
-
- **False Positive Rate**: % of failures due to test issues vs actual problems
|
|
311
|
-
- **Coverage**: Number of tutorial steps automatically verified
|
|
312
|
-
- **Developer Confidence**: Reduced manual testing effort
|
|
313
|
-
|
|
314
|
-
## Risk Mitigation
|
|
315
|
-
|
|
316
|
-
### Technical Risks
|
|
317
|
-
- **Flaky Tests**: Use retry mechanisms and wait strategies
|
|
318
|
-
- **Environment Dependencies**: Containerized execution environments
|
|
319
|
-
- **Resource Cleanup**: Comprehensive cleanup in finally blocks
|
|
320
|
-
- **Process Management**: Proper process lifecycle management
|
|
321
|
-
|
|
322
|
-
### Operational Risks
|
|
323
|
-
- **Maintenance Overhead**: Gradual rollout with proven patterns
|
|
324
|
-
- **CI/CD Load**: Efficient test execution and parallel processing
|
|
325
|
-
- **Team Adoption**: Clear documentation and training materials
|