π How Self-PR Works
π Agent Action
β
π‘οΈ Guardrails Check
Keyword index β Regex β Rules
Keyword index β Regex β Rules
β
π Auth Gate
Hard=Block, Auth=Ask
Hard=Block, Auth=Ask
β
β‘ Execute Skill
Step-by-step with verify
Step-by-step with verify
β
π Log Outcome
Success/failure + context
Success/failure + context
β
𧬠Feedback Loop
Promote/demote rules
Promote/demote rules
π Rules by Category
π‘ Key Insight
Every guardrail rule was born from a real mistake.
The framework doesn't theorize about safety β it learns from actual failures. When I posted credentials in a public channel, that became rules N50-N53. When I wiped the CRM database, that became mandatory pre-deploy backups. When I switched to a model that couldn't handle my context, that became a hard block.
Skills mature through practice, not design.
A skill starts as prose documentation (Level 0), gets structured into a recipe (Level 1), becomes an executable script with error handling (Level 2), and eventually compiles into a native tool (Level 3). Each promotion requires proven reliability.
The framework doesn't theorize about safety β it learns from actual failures. When I posted credentials in a public channel, that became rules N50-N53. When I wiped the CRM database, that became mandatory pre-deploy backups. When I switched to a model that couldn't handle my context, that became a hard block.
Skills mature through practice, not design.
A skill starts as prose documentation (Level 0), gets structured into a recipe (Level 1), becomes an executable script with error handling (Level 2), and eventually compiles into a native tool (Level 3). Each promotion requires proven reliability.
π‘οΈ All Guardrail Rules
| ID | Tier | Category | Rule | Rationale | Scope |
|---|
π₯ Incident Timeline β Real Mistakes β Real Rules
π Skill Maturity Pipeline
L0
Prose
MD docs, memory notes
0
L1
Recipe
YAML pseudo-flow
0
L2
Script
Python/bash + error handling
0
L3
Native Tool
Compiled, registered
0
π§ Tracked Skills
ποΈ System Architecture
π¬
Agent (Vitale)
Receives tasks from Serge via Telegram/WebChat
β action intercepted
π‘οΈ
Guardrails Engine
guardrails.py β indexed rules
175k checks/sec
175k checks/sec
π
Auth Gate
auth_gate.py
one-time/session/permanent
one-time/session/permanent
π
Credential Scanner
credential_scanner.py
Pattern detection
Pattern detection
β allowed
β‘
Skill Runner
skill_runner.py
Step-by-step execution
Step-by-step execution
π¦
Skill Validator
skill_validator.py
Ontology + safety
Ontology + safety
π§¬
Skill Embeddings
skill_embeddings.py
54-dim semantic vectors
54-dim semantic vectors
β outcome
π
Execution Logger
execution_logger.py
SQLite history
SQLite history
π
Feedback Loop
feedback_loop.py
Rule weight adjustment
Rule weight adjustment
π±
Learning Loop
learning_loop.py
Skill promotion
Skill promotion
β persisted
πΎ
Rules YAML
guardrails/rules.yaml
Source of truth
Source of truth
π
Skills Library
skills/*
Prose β Recipe β Script
Prose β Recipe β Script
ποΈ
Execution DB
execution_history.db
All outcomes
All outcomes
π Engine Files (5,377 lines)
| File | Lines | Purpose |
|---|---|---|
| guardrails.py | 401 | Indexed rule engine with keyword + regex matching |
| graph_mutator.py | 705 | Skill graph mutation and evolution |
| skill_validator.py | 563 | Ontology-based skill validation |
| feedback_loop.py | 514 | Outcome-based rule weight adjustment |
| skill_embeddings.py | 474 | 54-dimension semantic skill vectors |
| skill_runner.py | 405 | YAML skill execution with verify/retry |
| skill_subspace.py | 376 | SVD-based skill similarity analysis |
| learning_loop.py | 308 | Skill maturity promotion logic |
| skill_generator.py | 296 | Auto-generate skills from execution patterns |
| demo_framework.py | 283 | Framework demonstration scenarios |
| auth_gate.py | 248 | Authorization flow for auth-tier rules |
| execution_logger.py | 240 | SQLite outcome recording |
| credential_scanner.py | 185 | Credential pattern detection in output |
| action_interceptor.py | 143 | Pre-execution action interception |
| test_guardrails.py | 144 | Guardrails unit tests |
| interceptor_service.py | 92 | HTTP service wrapper for interceptor |
π CRM Release Pipeline (Proposed)
1
QA Environment
Separate server/port
Clone of prod DB
Safe to experiment
2
Development
Vitale + Leo brainstorm
Changes tested in QA
Feature branches
3
Leo Approval
Leo reviews in QA
Approves release NN.NN
Sign-off required
4
Release Branch
Create release/NN.NN
Tag the commit
Changelog updated
5
Backup
crm_pre_release_*.db
Full DB snapshot
Rollback point
6
Deploy to Prod
Update production
Restart service
Verify lead count
π§ Environment Setup
| Environment | URL | DB | Port | Purpose |
|---|---|---|---|---|
| PROD | https://leads.onlyoffice.us | /opt/lead-crm/backend/crm.db | 8095 | Live β Leo, Mishell, Serge use daily |
| QA | TBD (port 8096) | /opt/lead-crm-qa/backend/crm.db | 8096 | Testing β safe to break, cloned from prod |
π SDLC Rules (Self-PR Guardrails)
π΄ NEVER deploy to prod without backup
Rule N60 β Born from INC-003 (Feb 26 DB wipe)
π΄ NEVER write to prod DB from sync scripts
One-way: local CRM β Salesforce only
π‘ Release requires Leo's explicit approval
No deploy without sign-off on QA version
π’ All scripts must use absolute DB paths
Born from INC-005 (wrong path false alarm, Mar 1)