@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 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
- At Powerhouse we are embracing the progress of AI assisted coding while unlocking the next level of AI control through **specification driven AI control**.
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
- - 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.
12
+ :::
20
13
 
21
14
  ## Introducing Vetra Studio
22
15
 
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.
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
- 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**.
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
- #### 1. Document Models
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
- #### 2. User Experiences
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
- #### 3. Data integrations
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
- ph mcp
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
- - 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)
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
- #### 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
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
- The powerhouse config includes a vetra URL for consistent project configuration across different environments.
152
+ ### Key Reactor MCP Features
106
153
 
107
- :::tip
108
- - Vetra supports integration with custom remote drives, allowing users to create, share and manage documents within these drives.
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
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@powerhousedao/academy",
3
- "version": "4.1.0-dev.117",
3
+ "version": "4.1.0-dev.118",
4
4
  "homepage": "https://powerhouse.academy",
5
5
  "repository": {
6
6
  "type": "git",
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",
@@ -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