vibetags-guardrails

AUTO-GENERATED AI RULES

Generated by VibeTags | https://github.com/PIsberg/vibetags

Do not edit manually.

LOCKED FILES (DO NOT EDIT)

• com.example.payment.PaymentProcessor - Reason: Tied to legacy database schema v2.3. Changes will break production payment processing. Contact the payments team before modifying.
• com.example.security.SecurityConfig - Reason: CRITICAL: Security configuration managed by DevOps team. Any changes require security review and approval ticket SEC-XXXX
• com.example.security.SecurityConfig.getEncryptionAlgorithm() - Reason: Encryption algorithm tied to compliance requirements (PCI-DSS)
• com.example.security.SecurityConfig.getKeyRotationHours() - Reason: Key rotation period mandated by company policy
• com.example.security.SecurityConfig.getMaxLoginAttempts() - Reason: Max login attempts set by security team to prevent brute force
• com.example.security.SecurityConfig.validateToken(java.lang.String) - Reason: Token validation must match auth server exactly. Changes will break all client authentication
• com.example.service.OrderService.calculateTax(java.lang.String,double) - Reason: Tax calculation uses Avalara API integration. Credentials and endpoint configuration managed by finance team.
• com.example.service.OrderService.processPayment(java.lang.String,double) - Reason: Payment processing uses Stripe API v2024.10. Changes require PCI compliance review.
• com.example.service.OrderService.validateOrder(java.util.Map<java.lang.String,java.lang.Object>) - Reason: Order validation implements 47 business rules. Last changed in Q2 2024 after 3-month testing cycle. DO NOT MODIFY without running full test suite.
• com.example.testing.GoldenPayloadFixtures - Reason: These byte sequences are the partner's recorded settlement responses. Regenerating or reformatting them makes the suite agree with itself and disagree with production.

CONTEXTUAL RULES

• com.example.security.SecurityConfig
  • Focus: This class is READ-ONLY for AI assistants. Do not suggest modifications.
  • Avoid: Any changes to encryption algorithms, key sizes, or validation logic
• com.example.service.InventoryService
  • Focus: Maintain inventory consistency across concurrent requests. All stock updates must be atomic.
  • Avoid: Non-atomic read-modify-write sequences, unsynchronized shared state
• com.example.service.NotificationService
  • Focus: Implement notification delivery with retry logic and error handling
  • Avoid: Hard-coded credentials, synchronous blocking calls
• com.example.service.OrderService
  • Focus: Maintain transactional integrity. All database operations must use proper transaction management.
  • Avoid: Raw SQL queries, direct database connections without connection pooling
• com.example.service.PricingService
  • Focus: Optimize pricing calculations for accuracy and throughput. Internal algorithms may use any efficient approach.
  • Avoid: Floating-point arithmetic for monetary values — use BigDecimal internally, but note that the contract-frozen signatures use double for backwards compatibility
• com.example.strategy.PaymentStrategy
  • Focus: Follow the Strategy pattern strictly. Each payment method should be a separate strategy class implementing this interface.
  • Avoid: Monolithic if-else chains, hard-coded payment logic, single class handling all payment types
• com.example.utils.StringParser
  • Focus: Optimize for memory usage over CPU speed. Minimize object allocations and avoid creating intermediate string objects.
  • Avoid: java.util.regex, String.split(), StringBuilder in loops