@powerhousedao/academy 4.1.0-dev.12 → 4.1.0-dev.120
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/.vscode/settings.json +1 -1
- package/CHANGELOG.md +887 -0
- package/README.md +3 -3
- package/babel.config.js +1 -1
- package/blog/BeyondCommunication-ABlueprintForDevelopment.md +25 -24
- package/blog/TheChallengeOfChange.md +21 -21
- package/docs/academy/00-EthereumArgentinaHackathon.md +208 -0
- package/docs/academy/01-GetStarted/00-ExploreDemoPackage.mdx +67 -30
- package/docs/academy/01-GetStarted/01-CreateNewPowerhouseProject.md +38 -21
- package/docs/academy/01-GetStarted/02-DefineToDoListDocumentModel.md +24 -19
- package/docs/academy/01-GetStarted/03-ImplementOperationReducers.md +44 -41
- package/docs/academy/01-GetStarted/04-BuildToDoListEditor.md +10 -10
- package/docs/academy/01-GetStarted/05-VetraStudio.md +213 -0
- package/docs/academy/01-GetStarted/06-ReactorMCP.md +58 -0
- package/docs/academy/01-GetStarted/home.mdx +185 -90
- package/docs/academy/01-GetStarted/images/Modules.png +0 -0
- package/docs/academy/01-GetStarted/images/VetraStudioDrive.png +0 -0
- package/docs/academy/01-GetStarted/styles.module.css +5 -5
- package/docs/academy/02-MasteryTrack/01-BuilderEnvironment/01-Prerequisites.md +46 -18
- package/docs/academy/02-MasteryTrack/01-BuilderEnvironment/02-StandardDocumentModelWorkflow.md +118 -68
- package/docs/academy/02-MasteryTrack/01-BuilderEnvironment/03-BuilderTools.md +75 -33
- package/docs/academy/02-MasteryTrack/01-BuilderEnvironment/_category_.json +6 -6
- package/docs/academy/02-MasteryTrack/02-DocumentModelCreation/01-WhatIsADocumentModel.md +30 -21
- package/docs/academy/02-MasteryTrack/02-DocumentModelCreation/02-SpecifyTheStateSchema.md +41 -37
- package/docs/academy/02-MasteryTrack/02-DocumentModelCreation/03-SpecifyDocumentOperations.md +29 -25
- package/docs/academy/02-MasteryTrack/02-DocumentModelCreation/04-UseTheDocumentModelGenerator.md +36 -37
- package/docs/academy/02-MasteryTrack/02-DocumentModelCreation/05-ImplementDocumentReducers.md +128 -109
- package/docs/academy/02-MasteryTrack/02-DocumentModelCreation/06-ImplementDocumentModelTests.md +95 -86
- package/docs/academy/02-MasteryTrack/02-DocumentModelCreation/07-ExampleToDoListRepository.md +7 -9
- package/docs/academy/02-MasteryTrack/02-DocumentModelCreation/_category_.json +6 -6
- package/docs/academy/02-MasteryTrack/03-BuildingUserExperiences/01-BuildingDocumentEditors.md +65 -47
- package/docs/academy/02-MasteryTrack/03-BuildingUserExperiences/02-ConfiguringDrives.md +77 -62
- package/docs/academy/02-MasteryTrack/03-BuildingUserExperiences/03-BuildingADriveExplorer.md +360 -349
- package/docs/academy/02-MasteryTrack/03-BuildingUserExperiences/06-DocumentTools/00-DocumentToolbar.mdx +16 -10
- package/docs/academy/02-MasteryTrack/03-BuildingUserExperiences/06-DocumentTools/01-OperationHistory.md +10 -7
- package/docs/academy/02-MasteryTrack/03-BuildingUserExperiences/06-DocumentTools/02-RevisionHistoryTimeline.md +25 -17
- package/docs/academy/02-MasteryTrack/03-BuildingUserExperiences/06-DocumentTools/_category_.json +6 -6
- package/docs/academy/02-MasteryTrack/03-BuildingUserExperiences/07-Authorization/01-RenownAuthenticationFlow.md +14 -7
- package/docs/academy/02-MasteryTrack/03-BuildingUserExperiences/07-Authorization/02-Authorization.md +0 -1
- package/docs/academy/02-MasteryTrack/03-BuildingUserExperiences/07-Authorization/_category_.json +5 -5
- package/docs/academy/02-MasteryTrack/03-BuildingUserExperiences/_category_.json +1 -1
- package/docs/academy/02-MasteryTrack/04-WorkWithData/01-GraphQLAtPowerhouse.md +45 -33
- package/docs/academy/02-MasteryTrack/04-WorkWithData/02-UsingTheAPI.mdx +61 -18
- package/docs/academy/02-MasteryTrack/04-WorkWithData/03-UsingSubgraphs.md +105 -456
- package/docs/academy/02-MasteryTrack/04-WorkWithData/04-analytics-processor.md +126 -110
- package/docs/academy/02-MasteryTrack/04-WorkWithData/05-RelationalDbProcessor.md +98 -65
- package/docs/academy/02-MasteryTrack/04-WorkWithData/06-Analytics Engine/GraphQL References/QueryingADocumentWithGraphQL.md +23 -21
- package/docs/academy/02-MasteryTrack/04-WorkWithData/06-Analytics Engine/best-practices.md +9 -9
- package/docs/academy/02-MasteryTrack/04-WorkWithData/06-Analytics Engine/graphql/index.md +11 -23
- package/docs/academy/02-MasteryTrack/04-WorkWithData/06-Analytics Engine/graphql/integration.md +25 -9
- package/docs/academy/02-MasteryTrack/04-WorkWithData/06-Analytics Engine/intro.md +10 -10
- package/docs/academy/02-MasteryTrack/04-WorkWithData/06-Analytics Engine/typescript/benchmarks.md +1 -1
- package/docs/academy/02-MasteryTrack/04-WorkWithData/06-Analytics Engine/typescript/index.md +16 -11
- package/docs/academy/02-MasteryTrack/04-WorkWithData/06-Analytics Engine/typescript/memory.md +6 -5
- package/docs/academy/02-MasteryTrack/04-WorkWithData/06-Analytics Engine/typescript/schema.md +2 -2
- package/docs/academy/02-MasteryTrack/04-WorkWithData/06-Analytics Engine/typescript/utilities.md +7 -5
- package/docs/academy/02-MasteryTrack/04-WorkWithData/06-Analytics Engine/use-cases/maker.md +32 -58
- package/docs/academy/02-MasteryTrack/04-WorkWithData/06-Analytics Engine/use-cases/processors.md +1 -1
- package/docs/academy/02-MasteryTrack/04-WorkWithData/07-drive-analytics.md +105 -71
- package/docs/academy/02-MasteryTrack/04-WorkWithData/_ARCHIVE-AnalyticsProcessorTutorial/_01-SetupBuilderEnvironment.md +22 -0
- package/docs/academy/02-MasteryTrack/04-WorkWithData/_ARCHIVE-AnalyticsProcessorTutorial/_02-CreateNewPowerhouseProject.md +9 -8
- package/docs/academy/02-MasteryTrack/04-WorkWithData/_ARCHIVE-AnalyticsProcessorTutorial/_03-GenerateAnAnalyticsProcessor.md +28 -32
- package/docs/academy/02-MasteryTrack/04-WorkWithData/_ARCHIVE-AnalyticsProcessorTutorial/_04-UpdateAnalyticsProcessor.md +25 -26
- package/docs/academy/02-MasteryTrack/04-WorkWithData/_ARCHIVE-AnalyticsProcessorTutorial/_category_.json +1 -1
- package/docs/academy/02-MasteryTrack/04-WorkWithData/_category_.json +7 -7
- package/docs/academy/02-MasteryTrack/05-Launch/01-IntroductionToPackages.md +3 -4
- package/docs/academy/02-MasteryTrack/05-Launch/02-PublishYourProject.md +69 -45
- package/docs/academy/02-MasteryTrack/05-Launch/03-SetupEnvironment.md +70 -40
- package/docs/academy/02-MasteryTrack/05-Launch/04-ConfigureEnvironment.md +1 -0
- package/docs/academy/02-MasteryTrack/05-Launch/_category_.json +7 -7
- package/docs/academy/02-MasteryTrack/_category_.json +6 -6
- package/docs/academy/03-ExampleUsecases/Chatroom/02-CreateNewPowerhouseProject.md +5 -3
- package/docs/academy/03-ExampleUsecases/Chatroom/03-DefineChatroomDocumentModel.md +38 -37
- package/docs/academy/03-ExampleUsecases/Chatroom/04-ImplementOperationReducers.md +45 -41
- package/docs/academy/03-ExampleUsecases/Chatroom/05-ImplementChatroomEditor.md +14 -14
- package/docs/academy/03-ExampleUsecases/Chatroom/06-LaunchALocalReactor.md +6 -6
- package/docs/academy/03-ExampleUsecases/Chatroom/_category_.json +1 -1
- package/docs/academy/04-APIReferences/00-PowerhouseCLI.md +179 -72
- package/docs/academy/04-APIReferences/01-ReactHooks.md +649 -141
- package/docs/academy/04-APIReferences/04-RelationalDatabase.md +121 -113
- package/docs/academy/04-APIReferences/05-PHDocumentMigrationGuide.md +48 -41
- package/docs/academy/04-APIReferences/_category_.json +6 -6
- package/docs/academy/05-Architecture/00-PowerhouseArchitecture.md +1 -2
- package/docs/academy/05-Architecture/01-WorkingWithTheReactor.md +11 -10
- package/docs/academy/05-Architecture/05-DocumentModelTheory/_category_.json +1 -1
- package/docs/academy/05-Architecture/_category_.json +6 -6
- package/docs/academy/06-ComponentLibrary/00-DocumentEngineering.md +25 -23
- package/docs/academy/06-ComponentLibrary/02-CreateCustomScalars.md +105 -93
- package/docs/academy/06-ComponentLibrary/03-IntegrateIntoAReactComponent.md +1 -0
- package/docs/academy/06-ComponentLibrary/_category_.json +7 -7
- package/docs/academy/07-Cookbook.md +268 -35
- package/docs/academy/08-Glossary.md +7 -1
- package/docs/bookofpowerhouse/01-Overview.md +2 -2
- package/docs/bookofpowerhouse/02-GeneralFrameworkAndPhilosophy.md +1 -7
- package/docs/bookofpowerhouse/03-PowerhouseSoftwareArchitecture.md +10 -7
- package/docs/bookofpowerhouse/04-DevelopmentApproaches.md +10 -4
- package/docs/bookofpowerhouse/05-SNOsandANewModelForOSSandPublicGoods.md +23 -30
- package/docs/bookofpowerhouse/06-SNOsInActionAndPlatformEconomies.md +0 -7
- package/docusaurus.config.ts +64 -66
- package/package.json +9 -7
- package/scripts/generate-combined-cli-docs.ts +43 -13
- package/sidebars.ts +10 -0
- package/src/components/HomepageFeatures/index.tsx +171 -78
- package/src/components/HomepageFeatures/styles.module.css +1 -2
- package/src/css/custom.css +109 -89
- package/src/pages/_archive-homepage.tsx +17 -16
- package/src/theme/DocCardList/index.tsx +9 -8
- package/static/img/ethereum-logo.jpeg +0 -0
- package/static.json +6 -6
- package/tsconfig.tsbuildinfo +1 -0
- package/docs/academy/09-AIResources +0 -131
- package/docs/academy/TUTORIAL_VERIFICATION_ARCHITECTURE +0 -325
|
@@ -1,25 +1,32 @@
|
|
|
1
1
|
# Create a new to-do list document
|
|
2
2
|
|
|
3
3
|
## Overview
|
|
4
|
-
|
|
5
|
-
|
|
6
|
-
|
|
4
|
+
|
|
5
|
+
This tutorial guides you through creating a simplified version of a 'Powerhouse project' for a **To-do List**.
|
|
6
|
+
A Powerhouse project primarily consists of a document model and its editor.
|
|
7
|
+
As your projects use-case expands you can add data-integrations or a specific drive-app as seen in the demo package.
|
|
8
|
+
|
|
9
|
+
For todays purpose, you'll be using Connect, our user-centric collaboration tool and Vetra Studio, the builder tooling through which developers can access and manage specifications of their project.
|
|
7
10
|
|
|
8
11
|
## Prerequisites
|
|
9
|
-
|
|
10
|
-
-
|
|
12
|
+
|
|
13
|
+
- Powerhouse CLI installed: `pnpm install -g ph-cmd` or `npm install -g ph-cmd --legacy-peer-deps`
|
|
14
|
+
- node.js 22 and a package manager (pnpm or npm) installed
|
|
11
15
|
- Visual Studio Code (or your preferred IDE)
|
|
12
16
|
- Terminal/Command Prompt access
|
|
13
17
|
|
|
14
18
|
If you need help with installing the prerequisites you can visit our page [prerequisites](/academy/MasteryTrack/BuilderEnvironment/Prerequisites)
|
|
15
19
|
|
|
16
20
|
## Quick start
|
|
21
|
+
|
|
17
22
|
Create a new Powerhouse project with a single command:
|
|
23
|
+
|
|
18
24
|
```bash
|
|
19
25
|
ph init
|
|
20
26
|
```
|
|
21
27
|
|
|
22
28
|
## Before you begin
|
|
29
|
+
|
|
23
30
|
1. Open your terminal (either your system terminal or IDE's integrated terminal)
|
|
24
31
|
2. Optionally, create a folder first to keep your Powerhouse projects:
|
|
25
32
|
|
|
@@ -27,32 +34,38 @@ ph init
|
|
|
27
34
|
mkdir ph-projects
|
|
28
35
|
cd ph-projects
|
|
29
36
|
```
|
|
37
|
+
|
|
30
38
|
3. Ensure you're in the correct directory before running the `ph init` command.
|
|
31
|
-
In the terminal, you will be asked to enter the project name. Fill in the project name and press Enter.
|
|
32
|
-
|
|
39
|
+
In the terminal, you will be asked to enter the project name. Fill in the project name and press Enter.
|
|
40
|
+
|
|
41
|
+
````bash
|
|
33
42
|
you@yourmachine:~/ph-projects % ph init
|
|
34
43
|
|
|
35
44
|
? What is the project name? ‣ getting-started
|
|
36
|
-
```
|
|
45
|
+
```
|
|
37
46
|
|
|
38
|
-
|
|
47
|
+
|
|
48
|
+
Once the project is created, you will see the following output:
|
|
39
49
|
```bash
|
|
40
50
|
Initialized empty Git repository in /Users/you/ph-projects/getting-started/.git/
|
|
41
|
-
The installation is done!
|
|
51
|
+
The installation is done!
|
|
42
52
|
```
|
|
43
53
|
|
|
44
|
-
|
|
54
|
+
Navigate to the newly created project directory:
|
|
45
55
|
```bash
|
|
46
56
|
cd getting-started
|
|
47
57
|
```
|
|
48
|
-
|
|
49
|
-
|
|
58
|
+
|
|
59
|
+
## Develop a single document model in Connect
|
|
60
|
+
|
|
61
|
+
Once in the project directory, run the `ph connect` command to start a local instance of the Connect application. This allows you to start your document model specification document.
|
|
62
|
+
Run the following command to start the Connect application:
|
|
50
63
|
|
|
51
64
|
```bash
|
|
52
65
|
ph connect
|
|
53
66
|
```
|
|
54
67
|
|
|
55
|
-
|
|
68
|
+
The Connect application will start and you will see the following output:
|
|
56
69
|
|
|
57
70
|
```bash
|
|
58
71
|
➜ Local: http://localhost:3000/
|
|
@@ -60,17 +73,21 @@ In the terminal, you will be asked to enter the project name. Fill in the projec
|
|
|
60
73
|
➜ press h + enter to show help
|
|
61
74
|
```
|
|
62
75
|
|
|
63
|
-
|
|
76
|
+
A new browser window will open and you will see the Connect application. If it doesn't open automatically, you can open it manually by navigating to `http://localhost:3000/` in your browser.
|
|
64
77
|
|
|
65
|
-
|
|
66
|
-
|
|
67
|
-
|
|
78
|
+
You will see your local drive and a button to create a new drive.
|
|
79
|
+
If you local drive is not present navigate into Settings in the bottom left corner. Settings > Danger Zone > Clear Storage.
|
|
80
|
+
Clear the storage of your localhost application as it might has an old session cached.
|
|
68
81
|
|
|
69
|
-
4. Move into your local drive.
|
|
70
|
-
Create a new document model by clicking the `DocumentModel` button, found in the 'New Document' section at the bottom of the page.
|
|
82
|
+
4. Move into your local drive.
|
|
83
|
+
Create a new document model by clicking the `DocumentModel` button, found in the 'New Document' section at the bottom of the page.
|
|
71
84
|
|
|
72
85
|
If you've followed the steps correctly, you'll have an empty document where you can define the **'Document Specifications'**.
|
|
73
86
|
|
|
87
|
+
## Develop a package in Vetra Studio
|
|
88
|
+
|
|
89
|
+
|
|
90
|
+
|
|
74
91
|
## Up next
|
|
75
92
|
|
|
76
|
-
In the next tutorials, you will learn how to specify, add code and build an editor for your document model and export it to be used in your Powerhouse package.
|
|
93
|
+
In the next tutorials, you will learn how to specify, add code and build an editor for your document model and export it to be used in your Powerhouse package.
|
|
@@ -1,12 +1,14 @@
|
|
|
1
|
-
# Write the document specification
|
|
1
|
+
# Write the document specification
|
|
2
2
|
|
|
3
3
|
In this tutorial, you will learn how to define the specifications for a **To-do List** document model within the Connect application using its GraphQL schema, and then export the resulting document model specification document for your Powerhouse project.
|
|
4
4
|
If you don't have a document specification file created yet, have a look at the previous step of this tutorial to create a new document specification.
|
|
5
5
|
|
|
6
6
|
Before you start, make sure you have the Connect application running locally with the command:
|
|
7
|
+
|
|
7
8
|
```bash
|
|
8
9
|
ph connect
|
|
9
10
|
```
|
|
11
|
+
|
|
10
12
|
The Connect application will start and you will see the following output:
|
|
11
13
|
|
|
12
14
|
```bash
|
|
@@ -17,11 +19,11 @@ The Connect application will start and you will see the following output:
|
|
|
17
19
|
|
|
18
20
|
## To-do list document specification
|
|
19
21
|
|
|
20
|
-
Likely you have called your project 'ToDoList'.
|
|
21
|
-
If you've used a different name, please create a new document specification named 'ToDoList'.
|
|
22
|
-
**Pay close attention to capitalization, as it influences our code.**
|
|
22
|
+
Likely you have called your project 'ToDoList'.
|
|
23
|
+
If you've used a different name, please create a new document specification named 'ToDoList'.
|
|
24
|
+
**Pay close attention to capitalization, as it influences our code.**
|
|
23
25
|
|
|
24
|
-
We'll continue with this project to teach you how to create a document model specification and later an editor for your document model. We use the **GraphQL Schema Definition Language** (SDL) to define the schema for the document model.
|
|
26
|
+
We'll continue with this project to teach you how to create a document model specification and later an editor for your document model. We use the **GraphQL Schema Definition Language** (SDL) to define the schema for the document model.
|
|
25
27
|
Below, you can see the SDL for the `To-do List` document model.
|
|
26
28
|
|
|
27
29
|
:::info
|
|
@@ -45,9 +47,8 @@ type ToDoItem {
|
|
|
45
47
|
checked: Boolean!
|
|
46
48
|
}
|
|
47
49
|
```
|
|
48
|
-
</details>
|
|
49
|
-
|
|
50
50
|
|
|
51
|
+
</details>
|
|
51
52
|
|
|
52
53
|
<details>
|
|
53
54
|
<summary>Operations schema of our simplified to-do list</summary>
|
|
@@ -59,34 +60,37 @@ input AddTodoItemInput {
|
|
|
59
60
|
}
|
|
60
61
|
|
|
61
62
|
# Defines a GraphQL input type for updating a to-do item
|
|
63
|
+
|
|
62
64
|
input UpdateTodoItemInput {
|
|
63
|
-
|
|
64
|
-
|
|
65
|
-
|
|
65
|
+
id: ID!
|
|
66
|
+
text: String
|
|
67
|
+
checked: Boolean
|
|
66
68
|
}
|
|
67
69
|
|
|
68
70
|
# Defines a GraphQL input type for deleting a to-do item
|
|
71
|
+
|
|
69
72
|
input DeleteTodoItemInput {
|
|
70
|
-
|
|
73
|
+
id: ID!
|
|
71
74
|
}
|
|
72
|
-
|
|
75
|
+
|
|
76
|
+
````
|
|
73
77
|
</details>
|
|
74
78
|
|
|
75
79
|
## Define the document model specification
|
|
76
80
|
|
|
77
|
-
To be able to define the document model, you need to open the document model editor in Connect.
|
|
81
|
+
To be able to define the document model, you need to open the document model editor in Connect.
|
|
78
82
|
|
|
79
83
|
### The steps below show you how to do this:
|
|
80
84
|
|
|
81
85
|
1. In the Connect application, click on **'document model'** to open the document model specification editor.
|
|
82
|
-
2. Name your document model '**ToDoList**' in the Connect application, paying close attention to capitalization.
|
|
83
|
-
3. You'll be presented with a form to fill in metadata about the document model. Fill in the details in the respective fields.
|
|
86
|
+
2. Name your document model '**ToDoList**' in the Connect application, paying close attention to capitalization.
|
|
87
|
+
3. You'll be presented with a form to fill in metadata about the document model. Fill in the details in the respective fields.
|
|
84
88
|
|
|
85
89
|
In the **Document Type** field, type `powerhouse/todolist`. This defines the new type of document that will be created with this document model specification.
|
|
86
|
-
|
|
90
|
+
|
|
87
91
|

|
|
88
92
|
|
|
89
|
-
4. In the code editor, you can see the SDL for the document model. Replace the existing SDL template with the SDL defined in the [State Schema](#state-schema) section. Only copy and paste the types, leaving the inputs for the next step. You can, however, already press the 'Sync with schema' button to set the initial state of your document model specification based on your Schema Definition Language.
|
|
93
|
+
4. In the code editor, you can see the SDL for the document model. Replace the existing SDL template with the SDL defined in the [State Schema](#state-schema) section. Only copy and paste the types, leaving the inputs for the next step. You can, however, already press the 'Sync with schema' button to set the initial state of your document model specification based on your Schema Definition Language.
|
|
90
94
|
5. Below the editor, find the input field `Add module`. You'll use this to create and name a module for organizing your input operations. In this case, we will name the module `to_do_list`. Press enter.
|
|
91
95
|
6. Now there is a new field, called `Add operation`. Here you will have to add each input operation to the module, one by one.
|
|
92
96
|
7. Inside the `Add operation` field, type `ADD_TODO_ITEM` and press enter. A small editor will appear underneath it, with an empty input type that you have to fill. Copy the first input type from the [Operations Schema](#operations-schema) section and paste it in the editor. The editor should look like this:
|
|
@@ -106,6 +110,7 @@ Check below screenshot for the complete implementation:
|
|
|
106
110
|
|
|
107
111
|

|
|
108
112
|
|
|
109
|
-
### Up next: reducers
|
|
113
|
+
### Up next: reducers
|
|
114
|
+
|
|
115
|
+
Up next, you'll learn how to implement the runtime logic and components that will use the `ToDoList` document model specification you've just created and exported.
|
|
110
116
|
|
|
111
|
-
Up next, you'll learn how to implement the runtime logic and components that will use the `ToDoList` document model specification you've just created and exported.
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
# Implement the document model
|
|
2
2
|
|
|
3
|
-
In this section, we will implement and test the operation reducers for the **To-do List** document model. For this, you have to export the document model specification from the Connect application and import it into your Powerhouse project directory.
|
|
3
|
+
In this section, we will implement and test the operation reducers for the **To-do List** document model. For this, you have to export the document model specification from the Connect application and import it into your Powerhouse project directory.
|
|
4
4
|
|
|
5
5
|
To export the document model specification, follow the steps in the [Define ToDoList Document Model](/academy/GetStarted/DefineToDoListDocumentModel) section.
|
|
6
6
|
|
|
@@ -9,11 +9,12 @@ To export the document model specification, follow the steps in the [Define ToDo
|
|
|
9
9
|
Reducers are a core concept in Powerhouse document models. They implement the state transition logic for each operation defined in your schema.
|
|
10
10
|
|
|
11
11
|
:::info
|
|
12
|
-
**Connection to schema definition language (SDL)**: The reducers directly implement the operations you defined in your SDL. Remember how we defined `AddTodoItemInput`, `UpdateTodoItemInput`, and `DeleteTodoItemInput` in our schema?
|
|
12
|
+
**Connection to schema definition language (SDL)**: The reducers directly implement the operations you defined in your SDL. Remember how we defined `AddTodoItemInput`, `UpdateTodoItemInput`, and `DeleteTodoItemInput` in our schema?
|
|
13
13
|
The reducers provide the actual implementation of what happens when those operations are performed.
|
|
14
14
|
:::
|
|
15
15
|
|
|
16
|
-
To import the document model specification into your Powerhouse project, you can either:
|
|
16
|
+
To import the document model specification into your Powerhouse project, you can either:
|
|
17
|
+
|
|
17
18
|
- Copy and paste the file directly into the root of your Powerhouse project.
|
|
18
19
|
- Or drag and drop the file into the Powerhouse project directory in the VSCode editor as seen in the image below:
|
|
19
20
|
|
|
@@ -23,8 +24,7 @@ Either step will import the document model specification into your Powerhouse pr
|
|
|
23
24
|
|
|
24
25
|
## In your project directory
|
|
25
26
|
|
|
26
|
-
The next steps will take place in the VSCode editor. Make sure to have it open and the terminal window inside VSCode open as well.
|
|
27
|
-
|
|
27
|
+
The next steps will take place in the VSCode editor. Make sure to have it open and the terminal window inside VSCode open as well.
|
|
28
28
|
|
|
29
29
|
To write the operation reducers of the **To-do List** document model, you need to generate the document model code from the document model specification file you have exported into the Powerhouse project directory.
|
|
30
30
|
|
|
@@ -45,7 +45,6 @@ Open the `to-do-list.ts` file and you should see the code that needs to be fille
|
|
|
45
45
|
1. Copy and paste the code below into the `to-do-list.ts` file in the `reducers` folder.
|
|
46
46
|
2. Save the file.
|
|
47
47
|
|
|
48
|
-
|
|
49
48
|
<details>
|
|
50
49
|
<summary>Operation Reducers</summary>
|
|
51
50
|
```typescript
|
|
@@ -54,31 +53,31 @@ import { ToDoListToDoListOperations } from '../../gen/to-do-list/operations.js';
|
|
|
54
53
|
// REMARKS: This is our main reducer object that implements all operations defined in the schema.
|
|
55
54
|
// The ToDoListToDoListOperations type is auto-generated from our SDL and ensures type safety.
|
|
56
55
|
export const reducer: ToDoListToDoListOperations = {
|
|
57
|
-
|
|
58
|
-
|
|
59
|
-
|
|
60
|
-
|
|
61
|
-
|
|
62
|
-
|
|
63
|
-
|
|
64
|
-
|
|
65
|
-
|
|
66
|
-
|
|
67
|
-
|
|
68
|
-
|
|
69
|
-
|
|
70
|
-
|
|
71
|
-
|
|
72
|
-
|
|
73
|
-
|
|
74
|
-
|
|
75
|
-
|
|
76
|
-
|
|
56
|
+
// REMARKS: The addTodoItemOperation adds a new item to our todolist.
|
|
57
|
+
// - state: The current document state that we can modify
|
|
58
|
+
// - action: Contains the operation type and input data from the client
|
|
59
|
+
// - dispatch: Function to trigger additional operations (not used here)
|
|
60
|
+
addTodoItemOperation(state, action, dispatch) {
|
|
61
|
+
// REMARKS: While this looks like we're directly mutating state, Powerhouse
|
|
62
|
+
// handles immutability behind the scenes, creating a new state object.
|
|
63
|
+
state.items.push({
|
|
64
|
+
id: action.input.id, // Using the client-provided ID
|
|
65
|
+
text: action.input.text, // Setting the todo text from input
|
|
66
|
+
checked: false, // New items always start unchecked
|
|
67
|
+
});
|
|
68
|
+
},
|
|
69
|
+
|
|
70
|
+
// REMARKS: The updateTodoItemOperation modifies an existing todo item.
|
|
71
|
+
// It handles partial updates, allowing only specific fields to be updated.
|
|
72
|
+
updateTodoItemOperation(state, action, dispatch) {
|
|
73
|
+
// REMARKS: First find the item we want to update by its ID
|
|
74
|
+
const item = state.items.find(item => item.id === action.input.id);
|
|
75
|
+
|
|
77
76
|
// REMARKS: Proper error handling if item doesn't exist
|
|
78
77
|
if (!item) {
|
|
79
78
|
throw new Error(`Item with id ${action.input.id} not found`);
|
|
80
79
|
}
|
|
81
|
-
|
|
80
|
+
|
|
82
81
|
// REMARKS: We only update fields that were included in the input
|
|
83
82
|
// This allows for partial updates (only update what was provided)
|
|
84
83
|
if (action.input.text) {
|
|
@@ -87,17 +86,19 @@ export const reducer: ToDoListToDoListOperations = {
|
|
|
87
86
|
if (typeof action.input.checked === 'boolean') {
|
|
88
87
|
item.checked = action.input.checked;
|
|
89
88
|
}
|
|
90
|
-
|
|
91
|
-
|
|
92
|
-
|
|
93
|
-
|
|
94
|
-
|
|
95
|
-
|
|
96
|
-
|
|
97
|
-
|
|
98
|
-
|
|
89
|
+
|
|
90
|
+
},
|
|
91
|
+
|
|
92
|
+
// REMARKS: The deleteTodoItemOperation removes an item from the list.
|
|
93
|
+
// This showcases functional programming with array filters for immutable updates.
|
|
94
|
+
deleteTodoItemOperation(state, action, dispatch) {
|
|
95
|
+
// REMARKS: Create a new array containing only items that don't match the ID
|
|
96
|
+
// This is a common pattern for immutable array updates in JavaScript
|
|
97
|
+
state.items = state.items.filter(item => item.id !== action.input.id);
|
|
98
|
+
},
|
|
99
99
|
};
|
|
100
|
-
|
|
100
|
+
|
|
101
|
+
````
|
|
101
102
|
</details>
|
|
102
103
|
|
|
103
104
|
## Write the operation reducers tests
|
|
@@ -131,7 +132,7 @@ describe('Todolist Operations', () => {
|
|
|
131
132
|
it('should handle addTodoItem operation', () => {
|
|
132
133
|
// REMARKS: We create an input object matching our AddTodoItemInput schema
|
|
133
134
|
const input = { id: '1', text: 'Buy milk' };
|
|
134
|
-
|
|
135
|
+
|
|
135
136
|
// REMARKS: We apply the operation to get a new document state
|
|
136
137
|
// Note how we use the creators to generate the operation action
|
|
137
138
|
const updatedDocument = reducer(document, creators.addTodoItem(input));
|
|
@@ -174,7 +175,8 @@ describe('Todolist Operations', () => {
|
|
|
174
175
|
expect(updatedDocument.state.global.items).toHaveLength(0);
|
|
175
176
|
});
|
|
176
177
|
});
|
|
177
|
-
|
|
178
|
+
````
|
|
179
|
+
|
|
178
180
|
</details>
|
|
179
181
|
|
|
180
182
|
Now you can run the tests to make sure the operation reducers are working as expected.
|
|
@@ -192,7 +194,8 @@ Output should be as follows:
|
|
|
192
194
|
Duration 417ms (transform 79ms, setup 0ms, collect 174ms, tests 12ms, environment 0ms, prepare 158ms)
|
|
193
195
|
```
|
|
194
196
|
|
|
195
|
-
If you got the same output, you have successfully implemented the operation reducers and tests for the **To-do List** document model. Congratulations, you've successfully set up the backbone for a simple **To-do List** document.
|
|
197
|
+
If you got the same output, you have successfully implemented the operation reducers and tests for the **To-do List** document model. Congratulations, you've successfully set up the backbone for a simple **To-do List** document.
|
|
196
198
|
|
|
197
199
|
## Up next: To-do list editor
|
|
198
|
-
|
|
200
|
+
|
|
201
|
+
In the next chapter of this introduction track you will learn how to implement an editor for your document model so you can see a simple user interface for the **To-do List** document model in action.
|
|
@@ -4,7 +4,7 @@ In this chapter we will continue with the interface or editor implementation of
|
|
|
4
4
|
|
|
5
5
|
## Generate the editor template
|
|
6
6
|
|
|
7
|
-
Run the command below to generate the editor template for the **To-do List** document model.
|
|
7
|
+
Run the command below to generate the editor template for the **To-do List** document model.
|
|
8
8
|
This command reads the **To-do List** document model definition from the `document-models` folder and generates the editor template in the `editors/to-do-list` folder as `editor.tsx`.
|
|
9
9
|
|
|
10
10
|
Notice the `--editor` flag which specifies the **To-do List** document model, and the `--document-types` flag defines the document type `powerhouse/todolist`.
|
|
@@ -15,16 +15,15 @@ ph generate --editor ToDoList --document-types powerhouse/todolist
|
|
|
15
15
|
|
|
16
16
|
Once complete, navigate to the `editors/to-do-list/editor.tsx` file and open it in your editor.
|
|
17
17
|
|
|
18
|
-
|
|
19
18
|
### Editor implementation options
|
|
20
19
|
|
|
21
20
|
When building your editor component within the Powerhouse ecosystem, you have several options for styling, allowing you to leverage your preferred methods:
|
|
22
21
|
|
|
23
|
-
1. **Default HTML Styling:** Standard HTML tags (`<h1>`, `<p>`, `<button>`, etc.) will render with default styles offered through the boilerplate.
|
|
22
|
+
1. **Default HTML Styling:** Standard HTML tags (`<h1>`, `<p>`, `<button>`, etc.) will render with default styles offered through the boilerplate.
|
|
24
23
|
2. **Tailwind CSS:** Connect Studio comes with Tailwind CSS integrated. You can directly use Tailwind utility classes for rapid, consistent styling without writing separate CSS files.
|
|
25
24
|
3. **Custom CSS Files:** You can import traditional CSS files (`.css`) to apply custom styles or integrate existing style libraries.
|
|
26
25
|
|
|
27
|
-
Connect Studio provides a dynamic local environment, by running `ph connect` to visualize your components instantly as you build them, regardless of the styling method you choose.
|
|
26
|
+
Connect Studio provides a dynamic local environment, by running `ph connect` to visualize your components instantly as you build them, regardless of the styling method you choose.
|
|
28
27
|
Manual build steps are typically only needed when publishing packages.
|
|
29
28
|
|
|
30
29
|
## To-do List editor
|
|
@@ -189,6 +188,7 @@ export default function Editor(props: IProps) {
|
|
|
189
188
|
);
|
|
190
189
|
}
|
|
191
190
|
```
|
|
191
|
+
|
|
192
192
|
</details>
|
|
193
193
|
|
|
194
194
|
Now you can run the Connect app and see the **To-do List** editor in action.
|
|
@@ -197,22 +197,22 @@ Now you can run the Connect app and see the **To-do List** editor in action.
|
|
|
197
197
|
ph connect
|
|
198
198
|
```
|
|
199
199
|
|
|
200
|
-
In Connect, in the bottom right corner you'll find a new Document Model that you can create: **To-do List**.
|
|
200
|
+
In Connect, in the bottom right corner you'll find a new Document Model that you can create: **To-do List**.
|
|
201
201
|
Click on it to create a new To-do List document.
|
|
202
202
|
|
|
203
203
|
:::info
|
|
204
|
-
The editor will update dynamically, so you can play around with your editor styling while seeing your results appear in Connect Studio.
|
|
204
|
+
The editor will update dynamically, so you can play around with your editor styling while seeing your results appear in Connect Studio.
|
|
205
205
|
:::
|
|
206
206
|
|
|
207
207
|
Congratulations!
|
|
208
|
-
If you managed to follow this tutorial until this point, you have successfully implemented the **To-do List** document model with its reducer operations and editor.
|
|
208
|
+
If you managed to follow this tutorial until this point, you have successfully implemented the **To-do List** document model with its reducer operations and editor.
|
|
209
209
|
|
|
210
210
|
### Up next: Mastery Track
|
|
211
211
|
|
|
212
212
|
In the [Mastery Track chapther: Document Model Creation](/academy/MasteryTrack/DocumentModelCreation/WhatIsADocumentModel) we guide you through the theoretics of the previous steps while created a more advanced version of the To-do List.
|
|
213
213
|
|
|
214
|
-
You will learn:
|
|
214
|
+
You will learn:
|
|
215
|
+
|
|
215
216
|
- The in's & out's of a document model.
|
|
216
217
|
- How to use UI & Scalar components from the Document Engineering system.
|
|
217
|
-
- How to build Custom Drive Apps or Drive Explorers.
|
|
218
|
-
|
|
218
|
+
- How to build Custom Drive Apps or Drive Explorers.
|
|
@@ -0,0 +1,213 @@
|
|
|
1
|
+
# Tool: Vetra Studio
|
|
2
|
+
|
|
3
|
+
:::tip Important
|
|
4
|
+
|
|
5
|
+
## Vision: Specification Driven AI
|
|
6
|
+
|
|
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**.
|
|
9
|
+
|
|
10
|
+
- Communicate your solution and intent through a structured specification framework designed for AI collaboration.
|
|
11
|
+
- Specifications enable precise, iterative edits, since all our specification documents are machine-readable and executable.
|
|
12
|
+
:::
|
|
13
|
+
|
|
14
|
+
## Introducing Vetra Studio
|
|
15
|
+
|
|
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)
|
|
19
|
+
|
|
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.
|
|
21
|
+
|
|
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.
|
|
24
|
+
|
|
25
|
+
<figure className="image-container">
|
|
26
|
+
<img
|
|
27
|
+
src={require("./images/Modules.png").default}
|
|
28
|
+
alt="Modules"
|
|
29
|
+
/>
|
|
30
|
+
<figcaption>The list of available modules color coded according to the 3 categories.</figcaption>
|
|
31
|
+
</figure>
|
|
32
|
+
|
|
33
|
+
### Module Categories
|
|
34
|
+
|
|
35
|
+
### 1. Document Models
|
|
36
|
+
- **Document model specification**: Defines the structure and operations of a document model using GraphQL SDL, ensuring consistent data management and processing.
|
|
37
|
+
|
|
38
|
+
### 2. User Experiences
|
|
39
|
+
- **Editor specification**: Outlines the interface and functionalities of a document model editor, allowing users to interact with and modify document data.
|
|
40
|
+
- **Drive-app specification**: Specifies the UI and interactions for managing documents within a Drive, providing tailored views and functionalities.
|
|
41
|
+
|
|
42
|
+
### 3. Data integrations
|
|
43
|
+
- **Subgraph specification**: Details the connections and relationships within a subgraph, facilitating efficient data querying and manipulation.
|
|
44
|
+
- **Codegen Processor Specification**: Describes the process for automatically generating code from document model specifications, ensuring alignment with intended architecture.
|
|
45
|
+
- **RelationalDb Processor Specification**: Defines how relational databases are structured and queried, supporting efficient data management and retrieval.
|
|
46
|
+
|
|
47
|
+
<figure className="image-container">
|
|
48
|
+
<img
|
|
49
|
+
src={require("./images/VetraStudioDrive.png").default}
|
|
50
|
+
alt="Vetra Studio Drive"
|
|
51
|
+
/>
|
|
52
|
+
<figcaption>The Vetra Studio Drive, a builder app that collects all of the specification of a package.</figcaption>
|
|
53
|
+
</figure>
|
|
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
|
+
|
|
80
|
+
## Vetra Studio Workflow
|
|
81
|
+
|
|
82
|
+
### 1. Launch Vetra Studio
|
|
83
|
+
|
|
84
|
+
You can launch Vetra Studio in two modes:
|
|
85
|
+
|
|
86
|
+
#### Interactive Mode (Recommended for Development)
|
|
87
|
+
```bash
|
|
88
|
+
ph vetra --interactive
|
|
89
|
+
```
|
|
90
|
+
In interactive mode:
|
|
91
|
+
- You'll receive confirmation prompts before any code generation
|
|
92
|
+
- Changes require explicit confirmation before being processed
|
|
93
|
+
- Provides better control and visibility over document changes
|
|
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
|
+
|
|
110
|
+
#### Standard Mode
|
|
111
|
+
```bash
|
|
112
|
+
ph vetra
|
|
113
|
+
```
|
|
114
|
+
In standard mode:
|
|
115
|
+
- Changes are processed automatically with 1-second debounce
|
|
116
|
+
- Multiple changes are batched and processed together
|
|
117
|
+
- Uses the latest document state for processing
|
|
118
|
+
|
|
119
|
+
### 2. Launch Claude with Reactor-MCP
|
|
120
|
+
|
|
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.
|
|
122
|
+
|
|
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
|
+
|
|
135
|
+
```bash
|
|
136
|
+
connect to the reactor mcp
|
|
137
|
+
```
|
|
138
|
+
|
|
139
|
+
#### 2. Verify MCP connection:
|
|
140
|
+
- Check that the Reactor MCP is available.
|
|
141
|
+
- Confirm Vetra Studio shows "Connected to Reactor MCP"
|
|
142
|
+
|
|
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
|
+
```
|
|
148
|
+
|
|
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
|
|
151
|
+
|
|
152
|
+
### Key Reactor MCP Features
|
|
153
|
+
|
|
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
|
|
157
|
+
- The MCP server enables the agent to work with both existing and newly created document models.
|
|
158
|
+
- Vetra supports integration with custom remote drives, allowing users to create, share and manage documents within these drives.
|
|
159
|
+
|
|
160
|
+
|
|
161
|
+
### 3. Vetra Studio Package Creation Workflow
|
|
162
|
+
|
|
163
|
+
#### A. Set Package Description (Required)
|
|
164
|
+
1. Provide a name for your package
|
|
165
|
+
2. Add a meaningful description
|
|
166
|
+
3. Add keywords to add search terms to your package
|
|
167
|
+
4. Confirm changes when prompted in interactive mode
|
|
168
|
+
|
|
169
|
+
#### B. Define Document Model (Required)
|
|
170
|
+
You can create document models in two ways:
|
|
171
|
+
|
|
172
|
+
1. **Using MCP (AI-Assisted)**
|
|
173
|
+
- Describe your document needs in natural language in great detail.
|
|
174
|
+
- Claude will:
|
|
175
|
+
- Generate an appropriate schema
|
|
176
|
+
- Create the necessary operations
|
|
177
|
+
- Implement the required reducers
|
|
178
|
+
- Place the document in the Vetra drive
|
|
179
|
+
|
|
180
|
+
2. **Manual Creation**
|
|
181
|
+
- Define document schema with fields and types as in the **'Get Started'**
|
|
182
|
+
- Create the necessary operations
|
|
183
|
+
- Add the required modules to your package
|
|
184
|
+
- The document model creation chapter in the Mastery track provides in depth support [here](apps/academy/docs/academy/MasteryTrack/DocumentModelCreation/SpecifyTheStateSchema)
|
|
185
|
+
|
|
186
|
+
#### C. Add Document Editor (Required)
|
|
187
|
+
1. **Using MCP (AI-Assisted)**
|
|
188
|
+
- Request Claude to create an editor for your document. Do this with the help of a detailed description of the user interface, user experience and logic that you wish to generate. Make sure to reference operations from the document model to get the best results
|
|
189
|
+
- Claude will:
|
|
190
|
+
- Generate editor components
|
|
191
|
+
- Implement necessary hooks
|
|
192
|
+
- Create required UI elements
|
|
193
|
+
|
|
194
|
+
2. **Manual Creation**
|
|
195
|
+
- Select your target document model
|
|
196
|
+
- Configure the currently limited editor properties
|
|
197
|
+
- Add the editor specification to Vetra Studio drive
|
|
198
|
+
- The system will generate scaffolding code
|
|
199
|
+
|
|
200
|
+
#### D. Data Integrations (Coming Soon)
|
|
201
|
+
Support for:
|
|
202
|
+
- Subgraph integration
|
|
203
|
+
- Code generation processors
|
|
204
|
+
- Relational database processors
|
|
205
|
+
|
|
206
|
+
### Best Practices
|
|
207
|
+
|
|
208
|
+
**Working with MCP and claude**
|
|
209
|
+
- Provide clear, specific instructions and ask for clarifying questions to be answered before code generation.
|
|
210
|
+
- Review generated schemas before confirmation and work in layers instead of 'one-shotting' your code.
|
|
211
|
+
- Verify implementation details in generated code before continuing.
|
|
212
|
+
- Always double-check proposed next actions
|
|
213
|
+
|