Protection Workflow - johnpeterman72/CursorRIPER.sigma GitHub Wiki
🛡️ Protection Workflow Guide
Master the art of protecting critical code sections throughout your development process, ensuring business logic and security implementations remain safe from unintended modifications.
🎯 Protection Strategy Overview
A good protection strategy:
- 🛡️ Identifies critical code early
- 🔒 Applies appropriate levels
- 📝 Documents protection reasons
- 🔄 Reviews coverage regularly
- 📊 Tracks modifications
Without protection strategy:
- 🚫 Critical code modified
- 🚫 Security vulnerabilities
- 🚫 Business logic corrupted
- 🚫 Compliance violations
🔄 Protection Workflow Phases
Phase 1: Identification (RESEARCH/PLAN)
Identify what needs protection:
## Protection Planning
### Critical Areas Identified
- Authentication logic
- Payment processing
- Encryption algorithms
- API keys and secrets
- Compliance code
- Database schemas
Phase 2: Classification (PLAN)
Determine protection levels:
Code Type | Protection Level | Symbol |
---|---|---|
Security keys | PROTECTED | Ψ₁ |
Core algorithms | CRITICAL | Ψ₆ |
Validated logic | GUARDED | Ψ₂ |
Config explanations | INFO | Ψ₃ |
Temporary code | DEBUG | Ψ₄ |
Test fixtures | TEST | Ψ₅ |
Phase 3: Implementation (EXECUTE)
Apply protection during coding:
// !cp PROTECTED - API Configuration
const API_CONFIG = {
key: process.env.API_KEY,
secret: process.env.API_SECRET,
endpoint: process.env.API_ENDPOINT
};
// !cp END-P
// !cc CRITICAL - Payment Processing Logic
async function processPayment(order, payment) {
// Validated payment logic - DO NOT MODIFY
// Changes require compliance review
const validation = await validatePayment(payment);
if (!validation.success) {
throw new PaymentError(validation.errors);
}
const result = await paymentGateway.charge({
amount: order.total,
currency: order.currency,
source: payment.token
});
await logTransaction(result);
return result;
}
// !cc END-C
Phase 4: Documentation (EXECUTE/REVIEW)
Update protection registry:
## 🛡️ Protection Registry Update
### New Protections Added
- `src/config/api.js:1-5` [Ψ₁] - API configuration
- `src/payments/process.js:10-25` [Ψ₆] - Payment logic
- Added: 2024-01-15
- Reason: Compliance requirement
- Approved by: Security team
Phase 5: Verification (REVIEW)
Verify protection coverage:
Protection Coverage Report:
- Total files: 127
- Protected sections: 34
- Coverage: 27%
- Critical paths: 100% protected ✅
- Security items: 100% protected ✅
- Business logic: 85% protected ⚠️
🎨 Protection Patterns
1. Configuration Protection Pattern
Protect sensitive configuration:
// !cp PROTECTED - Environment Configuration
// These values are validated for production
// Modification requires security review
const CONFIG = {
// Database
DB_HOST: process.env.DB_HOST,
DB_PORT: process.env.DB_PORT,
DB_NAME: process.env.DB_NAME,
// Security
JWT_SECRET: process.env.JWT_SECRET,
ENCRYPTION_KEY: process.env.ENCRYPTION_KEY,
// API Keys
STRIPE_KEY: process.env.STRIPE_KEY,
AWS_ACCESS_KEY: process.env.AWS_ACCESS_KEY
};
// !cp END-P
// !ci INFO - Configuration Usage
// Use CONFIG object throughout application
// Never hardcode these values
// Update .env.example when adding new keys
// !ci END-I
2. Algorithm Protection Pattern
Protect validated algorithms:
// !cc CRITICAL - Proprietary Ranking Algorithm
// This algorithm is core business value
// Modifications require C-level approval
// Patent pending: US-2024-123456
function calculateRanking(items, userPreferences) {
// !cg GUARDED - Weighting factors
// These weights are ML-optimized
// Do not modify without data science review
const weights = {
relevance: 0.35,
quality: 0.25,
recency: 0.20,
userMatch: 0.20
};
// !cg END-G
return items.map(item => {
const score =
item.relevance * weights.relevance +
item.quality * weights.quality +
item.recency * weights.recency +
matchScore(item, userPreferences) * weights.userMatch;
return { ...item, rankScore: score };
}).sort((a, b) => b.rankScore - a.rankScore);
}
// !cc END-C
3. Security Protection Pattern
Protect security implementations:
// !cp PROTECTED - Authentication Flow
// Security-critical: Do not modify without security audit
class AuthenticationService {
// !cc CRITICAL - Password Hashing
// OWASP recommended implementation
// Bcrypt with cost factor 12
async hashPassword(password) {
const saltRounds = 12;
return bcrypt.hash(password, saltRounds);
}
// !cc END-C
// !cc CRITICAL - Token Generation
// JWT with RS256 algorithm
// Tokens expire in 15 minutes
generateAccessToken(user) {
return jwt.sign(
{ id: user.id, role: user.role },
this.privateKey,
{
algorithm: 'RS256',
expiresIn: '15m',
issuer: 'auth-service'
}
);
}
// !cc END-C
}
// !cp END-P
4. Compliance Protection Pattern
Protect compliance-required code:
// !cp PROTECTED - GDPR Compliance
// Required by EU regulation
// Modifications require legal review
class DataProtectionService {
// !cc CRITICAL - Data Deletion
// GDPR Article 17: Right to erasure
async deleteUserData(userId) {
// Must delete from all systems
await this.deleteFromDatabase(userId);
await this.deleteFromCache(userId);
await this.deleteFromBackups(userId);
await this.deleteFromAnalytics(userId);
// Audit log required
await this.logDeletion(userId, {
timestamp: new Date(),
reason: 'User request',
completeness: 'full'
});
}
// !cc END-C
}
// !cp END-P
5. Business Logic Protection Pattern
Protect core business rules:
// !cc CRITICAL - Pricing Engine
// Core business logic - Do not modify
// Changes require business approval
class PricingEngine {
// !cg GUARDED - Base Pricing Rules
calculatePrice(product, quantity, customer) {
let basePrice = product.basePrice * quantity;
// Bulk discounts (validated by finance)
if (quantity >= 100) basePrice *= 0.85;
else if (quantity >= 50) basePrice *= 0.90;
else if (quantity >= 20) basePrice *= 0.95;
// Customer tier discounts
const tierDiscount = this.getTierDiscount(customer.tier);
basePrice *= (1 - tierDiscount);
// Never go below cost
const minimumPrice = product.cost * quantity * 1.15;
return Math.max(basePrice, minimumPrice);
}
// !cg END-G
}
// !cc END-C
🔍 Protection Level Selection
Decision Tree
Is it a security key/secret?
Yes → Ψ₁ PROTECTED
No ↓
Is it business-critical logic?
Yes → Ψ₆ CRITICAL
No ↓
Does it require approval to change?
Yes → Ψ₂ GUARDED
No ↓
Is it configuration/documentation?
Yes → Ψ₃ INFO
No ↓
Is it temporary?
Yes → Ψ₄ DEBUG (if debugging) or Ψ₅ TEST (if testing)
No → Consider if protection needed
Protection Level Guidelines
Level | Use When | Review Frequency |
---|---|---|
PROTECTED | Never change | Quarterly |
CRITICAL | Business impact | Monthly |
GUARDED | Needs approval | Bi-weekly |
INFO | Context important | As needed |
DEBUG | Temporary only | Daily |
TEST | Test code | Per release |
📋 Protection Workflow Checklist
Before Coding (PLAN Mode)
- Identify security-sensitive areas
- List business-critical logic
- Note compliance requirements
- Plan protection levels
- Document protection strategy
During Coding (EXECUTE Mode)
- Add protection as you code
- Use clear descriptions
- Include end markers
- Group related protections
- Update protection registry
After Coding (REVIEW Mode)
- Verify all critical code protected
- Check protection levels appropriate
- Ensure descriptions clear
- Update documentation
- Run protection coverage report
Maintenance Phase
- Regular protection audits
- Remove obsolete protections
- Update protection reasons
- Review approved changes
- Train team on protection
💡 Protection Best Practices
1. Protect at Creation
Don't wait to add protection:
// Write and protect together
function criticalFunction() {
// !cc CRITICAL - Business Logic
// Implementation
// !cc END-C
}
2. Clear Descriptions
Explain why protected:
// ❌ Bad
// !cp PROTECTED - Don't change
// ✅ Good
// !cp PROTECTED - PCI Compliance Required
// Credit card processing per PCI-DSS v3.2.1
3. Group Related Code
Protect logical units:
// !cg GUARDED - User Validation Module
class UserValidator {
validateEmail() { /* ... */ }
validatePassword() { /* ... */ }
validateProfile() { /* ... */ }
}
// !cg END-G
4. Version Protection Changes
Track protection evolution:
## Protection History
- v1.0: Initial protection added
- v1.1: Enhanced security section
- v1.2: Added compliance markers
- v2.0: Restructured protection zones
5. Regular Reviews
Schedule protection audits:
## Monthly Protection Review
- [ ] All secrets protected?
- [ ] New critical code marked?
- [ ] Obsolete protections removed?
- [ ] Documentation updated?
- [ ] Team aware of changes?
🚨 Common Protection Mistakes
1. Over-Protection
Problem: Everything marked as protected Solution: Reserve for truly critical code
2. Under-Protection
Problem: Critical code unprotected Solution: Protection planning in PLAN mode
3. Vague Descriptions
Problem: "Don't change this" Solution: Specific reasons and requirements
4. Missing End Markers
Problem: Unclear protection boundaries Solution: Always include END markers
5. Outdated Protection
Problem: Protecting removed code Solution: Regular protection audits
📊 Protection Metrics
Coverage Metrics
Track protection coverage:
## Protection Coverage
- Security code: 100% ✅
- Business logic: 95% ✅
- Configuration: 90% ✅
- Integration: 80% ⚠️
- Overall: 91% ✅
Violation Metrics
Monitor protection violations:
## Violation Report (Monthly)
- Total violations: 3
- CRITICAL violations: 0 ✅
- PROTECTED violations: 1
- GUARDED violations: 2
- All resolved: Yes ✅
Modification Metrics
Track approved changes:
## Approved Modifications
- Total requests: 12
- Approved: 8
- Denied: 4
- Average review time: 2 days
🛠️ Protection Tools
Quick Protection
!cp - Add PROTECTED
!cg - Add GUARDED
!ci - Add INFO
!cd - Add DEBUG
!ct - Add TEST
!cc - Add CRITICAL
Protection Reports
"Show protection coverage"
"List unprotected critical files"
"Check protection violations"
"Generate protection audit"
Protection Management
"Add protection to payment.js"
"Update protection registry"
"Review protection history"
"Export protection map"