MahmoudEmad/herolib
1
0
Fork 0
Code Issues 55 Pull Requests 1 Actions Packages Projects Releases 26 Wiki Activity

...

Browse Source
This commit is contained in:
despiegk
2025-11-15 06:15:02 +02:00
parent e97e0d77be
commit d267c1131f
7 changed files with 376 additions and 104 deletions
Download Patch File Download Diff File Expand all files Collapse all files

5
lib/hero/db/ai_instructions_hero_models.md → aiprompts/ai_instructions_hero_models.md
View File

@@ -2,11 +2,12 @@
## Overview
This document provides clear instructions for AI agents to create new HeroDB models similar to `message.v`. These models are used to store structured data in Redis using the HeroDB system.
This document provides clear instructions for AI agents to create new HeroDB models similar to `message.v`.
These models are used to store structured data in Redis using the HeroDB system.
The message.v can be found in `lib/hero/heromodels/message.v`.s
## Key Concepts
- Each model represents a data type stored in Redis hash sets
- Models must implement serialization/deserialization using the `encoder` module
- Models inherit from the `Base` struct which provides common fields
- The database uses a factory pattern for model access

2
lib/core/playcmds/play_all.v
View File

@@ -41,7 +41,6 @@ import incubaid.herolib.installers.virt.docker
import incubaid.herolib.installers.virt.herorunner
import incubaid.herolib.installers.virt.kubernetes_installer
import incubaid.herolib.installers.virt.lima
import incubaid.herolib.installers.virt.myhypervisor
import incubaid.herolib.installers.virt.pacman
import incubaid.herolib.installers.virt.podman
import incubaid.herolib.installers.virt.youki
@@ -100,7 +99,6 @@ pub fn run_all(args_ PlayArgs) ! {
herorunner.play(mut plbook)!
kubernetes_installer.play(mut plbook)!
lima.play(mut plbook)!
myhypervisor.play(mut plbook)!
pacman.play(mut plbook)!
podman.play(mut plbook)!
youki.play(mut plbook)!

94
lib/hero/db/ai_instructions_hero_models_old.md
View File

@@ -1,94 +0,0 @@
the main data is in key value stor:
- each object has u32 id
- each object has u16 version (version of same data)
- each object has u16 schemaid (if schema changes)
- each object has tags u32 (to tag table)
- each object has a created_at timestamp
- each object has a updated_at timestamp
- each object has binary content (the data)
- each object has link to who can read/write/delete (lists of u32 per read/write/delete to group or user), link to security policy u32
- each object has a signature of the data by the user who created/updated it
- there are users & groups
- groups can have other groups and users inside
- users & groups are unique u32 as well in the DB, so no collision
this database does not know what the data is about, its agnostic to schema
now make the 4 structs which represent above
- data
- user
- group ([]u32) each links to user or group, name, description
- tags ([]string which gets a unique id, so its shorter to link to data object)
- securitypolicy (see below)
and encoding scheme using lib/data/encoder, we need encode/decode on the structs, so we have densest possible encoding
now we need the implementation details for each struct, including the fields and their types, as well as the encoding/decoding logic.
the outside is a server over openrpc which has
- set (userid:u32, id:u32, data: Data, signature: string, tags:[]string) -> u32. (id can be 0 then its new, if existing we need to check if user can do it), tags will be recalculated based on []string (lower case, sorted list then md5 -> u32)
- get (userid:u32, id: u32, signedid: string) -> Data,Tags as []string
- exist (userid:u32, id: u32) -> bool //this we allow without signature
- delete (userid:u32, id: u32, signedid: string) -> bool
- list (userid:u32, signature: string, based on tags, schemaid, from creation/update and to creation/update), returns max 200 items -> u32
the interface is stateless, no previous connection known, based on signature the server can verify the user is allowed to perform the action
the backend database is redis (hsets and sets)
## signing implementation
the signing is in the same redis implemented, so no need to use vlang for that
```bash
# Generate an ephemeral signing keypair
redis-cli -p $PORT AGE GENSIGN
# Example output:
# 1) "<verify_pub_b64>"
# 2) "<sign_secret_b64>"
# Sign a message with the secret
redis-cli -p $PORT AGE SIGN "<sign_secret_b64>" "msg"
# → returns "<signature_b64>"
# Verify with the public key
redis-cli -p $PORT AGE VERIFY "<verify_pub_b64>" "msg" "<signature_b64>"
# → 1 (valid) or 0 (invalid)
```
versioning: when stored we don't have to worry about version the database will check if it exists, newest version and then update
## some of the base objects
```v
@[heap]
pub struct SecurityPolicy {
pub mut:
id u32
read []u32 //links to users & groups
write []u32 //links to users & groups
delete []u32 //links to users & groups
public bool
}
@[heap]
pub struct Tags {
pub mut:
id u32
names []string //unique per id
md5 string //of sorted names, to make easy to find unique id
}
```

1
lib/hero/heromodels/message.v
View File

@@ -239,6 +239,7 @@ pub fn (mut self DBMessages) list(args MessageListArg) ![]Message {
return filtered_messages
}
// is how we implement the openrpc calls
pub fn message_handle(mut f ModelsFactory, rpcid int, servercontext map[string]string, userref UserRef, method string, params string) !Response {
match method {
'get' {

6
lib/hero/heromodels/planning.md
View File

@@ -1,6 +0,0 @@
## notes around how to do a calendly feature
- make an agenda for the planning and call it as such, this has the timeboxes available for planning
- create template for calendar_event
- create planning item and link to this template
- select the rules which work for recurrence

275
lib/hero/heromodels/prd.md Normal file
View File

@@ -0,0 +1,275 @@
# 📘 **PRD Manual
# 1. **Product Overview**
### **What to Write**
A 2–4 sentence summary describing **what the product is**, **what problem it solves**, and **who it is for**.
### **Fields**
* `product_name`
* `version`
* `overview`
* `vision`
### **Example**
```
product_name: "Lumina PRD Builder"
version: "v1.0"
overview: "Lumina PRD Builder allows teams to generate structured, validated Product Requirements Documents using templates and AI guidance."
vision: "Enable any team to create clear requirements in minutes, improving alignment and execution speed."
```
---
# 2. **Goals**
### **What to Write**
A list of measurable outcomes that define success.
### **Fields**
* `id`
* `title`
* `description`
* `gtype` → product / business / operational
### **Example**
```
{
id: "G1"
title: "Faster Requirements Creation"
description: "Reduce PRD creation time from 2 weeks to under 1 day for all teams."
gtype: .product
},
{
id: "G2"
title: "Increase Adoption"
description: "Achieve 500 monthly active users within 90 days of launch."
gtype: .business
}
```
---
# 3. **Use Cases**
### **What to Write**
Realistic user interactions showing how the product will be used.
### **UseCase Fields**
* id
* title
* actor
* goal
* steps
* success
* failure
### **Example**
```
{
id: "UC1"
title: "Generate a PRD from Template"
actor: "Product Manager"
goal: "Create a validated PRD quickly"
steps: [
"User selects 'New PRD'",
"User chooses template type",
"User fills fields or uses AI suggestions",
"User exports PRD to Markdown"
]
success: "A complete PRD is generated without missing required fields."
failure: "Validation fails due to missing required data."
}
```
---
# 4. **Requirements**
### **What to Write**
Describe *what the system must do*, in clear, testable language.
### **Requirement Fields**
* id
* category
* title
* rtype
* description
* priority
* criteria
* dependencies
---
### **Example Requirement**
```
{
id: "R1"
category: "PRD Editor"
title: "Template Selection"
rtype: .functional
description: "The system must allow users to select from a list of predefined PRD templates."
priority: .high
criteria: [
{
id: "AC1"
description: "UI displays at least 5 templates"
condition: "List contains >= 5 template entries"
}
]
dependencies: []
}
```
---
### **Example Requirement with Dependency**
```
{
id: "R3"
category: "Export"
title: "Export PRD to Markdown"
rtype: .functional
description: "Users must be able to export the completed PRD to a Markdown file."
priority: .medium
criteria: [
{
id: "AC4"
description: "File saved in .md format"
condition: "Output file ends with '.md'"
}
]
dependencies: ["R1", "R2"]
}
```
---
# 5. **Constraints**
### **What to Write**
Non-negotiable boundaries the solution must respect.
### **Constraint Fields**
* id
* title
* description
* ctype
### **Example**
```
{
id: "C1"
title: "ARM64 Only"
description: "The system must run on ARM64 servers to match company infrastructure."
ctype: .technica
},
{
id: "C2"
title: "Q1 Deadline"
description: "The first release must be launched before March 31."
ctype: .business
},
{
id: "C3"
title: "GDPR Requirement"
description: "All user data must be deletable within 24 hours of a user request."
ctype: .compliance
}
```
---
# 6. **Risks**
### **What to Write**
Potential problems + mitigation strategies.
### **Example**
```
risks: {
"RISK1": "Template library may be too small → Mitigate by allowing community contributions"
"RISK2": "AI suggestions may be inaccurate → Add review/approve workflow"
"RISK3": "Export format inconsistencies → Create automated format tests"
}
```
---
# 🔧 7. **Minimum PRD Example (Compact)**
Here is a minimal but valid PRD instance:
```
ProductRequirementsDoc{
product_name: "Lumina PRD Builder"
version: "v1.0"
overview: "Tool to create structured PRDs."
vision: "Fast, accurate requirements for all teams."
goals: [
Goal{
id: "G1"
title: "Speed"
description: "Generate PRDs in under 10 minutes."
gtype: .product
}
]
use_cases: [
UseCase{
id: "UC1"
title: "Create PRD"
actor: "PM"
goal: "Produce PRD quickly"
steps: ["Click new", "Fill data", "Export"]
success: "Valid PRD generated"
failure: "Missing fields"
}
]
requirements: [
Requirement{
id: "R1"
category: "Editor"
title: "Input Fields"
rtype: .functional
description: "User can fill out PRD fields"
priority: .high
criteria: []
dependencies: []
}
]
constraints: [
constraint{
id: "C1"
title: "Must Support Markdown"
description: "Export only in .md format"
ctype: .technica
}
]
risks: {
"R1": "User confusion → Add tooltips"
}
}
```

97
lib/hero/heromodels/prd.v Normal file
View File

@@ -0,0 +1,97 @@
module prd
// Basic enums for clarity
// Core PRD type, this is the root object
pub struct ProductRequirementsDoc {
pub:
product_name string
version string
overview string
vision string
goals []Goal
use_cases []UseCase
requirements []Requirement
constraints []Constraint
risks map[string]string // risk_id -> mitigation
}
pub enum PRDPriority {
low
medium
high
critical
}
pub enum RequirementType {
functional
non_functional
performance
reliability
}
// A reusable acceptance criterion type
pub struct AcceptanceCriterion {
pub:
id string
description string
condition string // testable condition
}
// A generic requirement type (functional or NFR)
pub struct Requirement {
pub:
id string
category string // to group requirements
title string
rtype RequirementType
description string
priority PRDPriority
criteria []AcceptanceCriterion
dependencies []string // list of requirement IDs this one depends on
}
// A use case type
pub struct UseCase {
pub:
id string
title string
actor string
goal string
steps []string
success string
failure string
}
pub enum GoalType {
product
business
operational
}
pub struct Goal {
pub:
id string
title string
description string
gtype GoalType
}
pub enum ConstraintType {
technica
business
operational
scale
compliance
design
}
pub struct constraint {
pub:
id string
title string
description string
ctype ConstraintType
}