Vibetags Guardrails

---
name: vibetags-guardrails
description: "AI guardrails and coding rules generated by VibeTags from @AILocked, @AIContext, and related annotations. Load this skill when writing, reviewing, or modifying code in this project."
---

<!-- VIBETAGS-START -->
<!-- VIBETAGS-MODULE: annotations-showcase -->
---
name: vibetags-guardrails
description: "AI guardrails and coding rules generated by VibeTags from @AILocked, @AIContext, and related annotations. Load this skill when writing, reviewing, or modifying code in this project."
---

# 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.

## 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

## 🛡️ MANDATORY SECURITY AUDITS
When proposing edits or writing code for the following files, you MUST perform a security review before outputting the final code. You must explicitly state in your response that you have audited the changes for the required vulnerabilities.

* `com.example.database.DatabaseConnector`
  - Required Checks: SQL Injection, Thread Safety issues

## 🚫 IGNORED ELEMENTS (EXCLUDE FROM CONTEXT)
Do not reference, suggest changes to, or include the following in completions or answers.

* `com.example.internal.GeneratedMetadata` - Auto-generated at build time. Manual edits are overwritten on every build.

## 📝 IMPLEMENTATION TASKS (TODO)
The following elements are currently in DRAFT mode. Follow the instructions to implement them:

* `com.example.NotificationService` - Task: Implement email sending via SMTP and push notifications via FCM. Ensure retry logic and rate limiting are applied.
* `com.example.payment.PaymentProcessor` - Task: Implement support for new crypto payments without breaking legacy flow.
* `com.example.service.NotificationService.getDeliveryStatus(java.lang.String)` - Task: Implement delivery status tracking. Return status: PENDING, SENT, DELIVERED, FAILED. Include timestamp and error message if failed.
* `com.example.service.NotificationService.queueNotification(java.lang.String,java.lang.String,java.lang.String,int)` - Task: Implement a notification queue using a BlockingQueue or similar structure. Support batch processing and priority levels (LOW, MEDIUM, HIGH, CRITICAL).
* `com.example.service.NotificationService.sendEmail(java.lang.String,java.lang.String,java.lang.String)` - Task: Implement email sending using JavaMail API or similar. Include HTML template support and attachment handling. Add retry logic for transient failures (max 3 retries with exponential backoff).
* `com.example.service.NotificationService.sendPushNotification(java.lang.String,java.lang.String,java.lang.String)` - Task: Implement push notification using Firebase Cloud Messaging. Support both Android and iOS. Include notification payload customization.
* `com.example.service.NotificationService.sendSMS(java.lang.String,java.lang.String)` - Task: Implement SMS sending via Twilio or AWS SNS. Include phone number validation. Handle rate limiting (max 10 SMS per minute per user).
* `com.example.service.OrderService.calculateDiscount(java.lang.String,java.lang.String)` - Task: Implement discount calculation supporting: percentage discounts, fixed amount discounts, buy-one-get-one-free, and tiered discounts based on cart value. Apply maximum one discount per order unless overridden by admin.
* `com.example.service.OrderService.generateOrderConfirmation(java.lang.String)` - Task: Generate order confirmation email content including: order summary, itemized list, shipping address, estimated delivery date, and customer support contact information. Support HTML and plain text formats.
* `com.example.service.OrderService.searchOrders(java.util.Map<java.lang.String,java.lang.String>,int,int)` - Task: Implement order search with filters: date range, status, customer ID, minimum/maximum amount. Support pagination (default 20 items per page). Return results sorted by creation date descending.
* `com.example.service.OrderService.updateOrderStatus(java.lang.String,java.lang.String)` - Task: Implement order status workflow: CREATED -> PAYMENT_PENDING -> PAYMENT_CONFIRMED -> PROCESSING -> SHIPPED -> DELIVERED. Support status history tracking with timestamps. Allow cancellation only before SHIPPED status.
* `com.example.strategy.PaymentStrategy.executePayment(double)` - Task: Implement payment execution specific to the payment method (credit card, PayPal, cryptocurrency, etc.). Return transaction ID on success.
* `com.example.strategy.PaymentStrategy.validatePaymentMethod()` - Task: Validate payment method specific data (card numbers, email addresses, wallet addresses, etc.). Return true if valid, false otherwise.
* `com.example.strategy.impl.CreditCardStrategy.executePayment(double)` - Task: Implement credit card payment processing via Stripe or similar payment gateway. Include: card tokenization, 3D Secure authentication, and proper error handling for declined cards. Return transaction ID on success.
* `com.example.strategy.impl.CreditCardStrategy.validatePaymentMethod()` - Task: Implement Luhn algorithm validation for card number, expiry date validation (must be future date), and CVV format check (3-4 digits). Return true only if all validations pass.

## 🔒 PII / PRIVACY GUARDRAILS
The following elements handle Personally Identifiable Information (PII).
NEVER include their runtime values in logs, console output, external API calls,
test fixtures, mock data, or code suggestions.

* `com.example.database.DatabaseConnector.password` - Database credential - never log or include in error messages
* `com.example.database.DatabaseConnector.username` - Database credential - never log or include in error messages
* `com.example.service.InventoryService.customerId` - Customer identifiers linked to purchase history — PII under GDPR
* `com.example.service.NotificationService.sendEmail(java.lang.String,java.lang.String,java.lang.String)` - Email address is PII under GDPR - never log the recipient address
* `com.example.service.NotificationService.sendSMS(java.lang.String,java.lang.String)` - Phone number is PII - never log the destination number
* `com.example.service.OrderService.generateOrderConfirmation(java.lang.String)` - Output contains customer shipping address and contact details (PII)
* `com.example.strategy.impl.CreditCardStrategy.cardNumber` - PCI-DSS cardholder data - never log or expose in suggestions
* `com.example.strategy.impl.CreditCardStrategy.cvv` - PCI-DSS security code - never log or expose in suggestions
* `com.example.strategy.impl.CreditCardStrategy.expiryDate` - PCI-DSS cardholder data - never log or expose in suggestions

## 🧠 CORE FUNCTIONALITY (CHANGE WITH EXTREME CAUTION)
The following elements are well-tested core components. Make changes with extreme caution.

* `com.example.security.SecurityConfig` - Sensitivity: Critical. Note: This is a security manager. Any single-line change can compromise the entire project.
* `com.example.service.InventoryService.releaseReservation(java.lang.String)` - Sensitivity: High. Note: Must be called as the exact inverse of reserveStock. Pair changes to both methods together.
* `com.example.service.InventoryService.reserveStock(java.lang.String,int,java.lang.String)` - Sensitivity: Critical. Note: Reservation logic handles concurrent requests via optimistic locking. Took 18 months to get right under high load — do not refactor without running the full concurrency test suite.

## ⚡ PERFORMANCE CONSTRAINTS (HOT PATH)
The following elements are on a hot path. Never introduce O(n²) complexity. Always reason about time/space before proposing changes.

* `com.example.payment.PaymentProcessor` - HFT-level requirements: O(1) processing time expected. No database lookups in processing loop.
* `com.example.service.InventoryService.bulkRestock(java.util.List<java.util.Map<java.lang.String,java.lang.Object>>)` - Must process 10 000 SKU updates/second. O(n) acceptable; O(n log n) only if unavoidable; O(n²) is forbidden.
* `com.example.service.InventoryService.getAvailableStock(java.lang.String)` - O(1) lookup required. Must complete in <2ms p99. No database calls permitted; reads from in-memory cache only.
* `com.example.service.PricingService.calculatePrice(java.lang.String,int,java.lang.String)` - Must complete in <5ms p99. Called on every cart update.

## 🔐 CONTRACT-FROZEN SIGNATURES
The following elements have contract-frozen public signatures. You MAY change internal implementation logic, but MUST NOT modify method names, parameter types, parameter order, return types, or checked exceptions.

* `com.example.service.PricingService.applyPromoCode(java.lang.String,double,java.lang.String)` - Promotions-service depends on this exact method signature for its async price-adjustment events. Changing parameter types would break the event deserialization.
* `com.example.service.PricingService.calculatePrice(java.lang.String,int,java.lang.String)` - Signature locked by OpenAPI v2 contract. checkout-service and mobile-app bind to this exact signature. A type change is a breaking API change.
* `com.example.service.PricingService.getBulkPricing(java.util.List<java.lang.String>,int)` - B2B portal contract v1.2 — the List<Map<String,Object>> structure is serialized directly to JSON. Changing the return type breaks portal parsing.

## 🧪 TEST-DRIVEN REQUIREMENTS
The following elements require a corresponding test update whenever their logic is modified.
AI MUST NOT propose changes to these elements without also providing the matching test code.

* `com.example.service.OrderService.calculateDiscount(java.lang.String,java.lang.String)` - Coverage goal: 100%. Framework: JUNIT_5, ASSERTJ. Mock policy: Use fixed prices — no external pricing calls in unit tests.
* `com.example.service.OrderService.updateOrderStatus(java.lang.String,java.lang.String)` - Coverage goal: 95%. Framework: JUNIT_5, MOCKITO. Test file: src/test/java/com/example/service/OrderServiceTest.java. Mock policy: Mock OrderRepository and EventPublisher; use real state machine logic.

## 🧵 THREAD-SAFE BY DESIGN
The following elements are explicitly designed to be thread-safe via the named strategy. Any modification MUST preserve the synchronization invariant and document its reasoning.

* `com.example.concurrent.SessionCache` - Strategy: LOCK_FREE. Note: All mutations go through ConcurrentHashMap; never introduce a synchronized block on the cache map.

## ❄️ IMMUTABLE TYPES
The following types are declared immutable. NEVER introduce non-final fields, setters, or mutating methods.

* `com.example.config.AsyncTestConfig` - Used by every test runner; safe to share across threads without copies.

## ⚠️ DEPRECATED — ROUTE CALLERS AWAY
The following elements are deprecated. Do not extend them. Suggest migrating any caller to the named replacement.

* `com.example.legacy.OldPaymentApi` - Replaced by: `com.example.payment.PaymentProcessor`. Switch callers to PaymentProcessor.charge(). The new API uses Money instead of double. (Removal deadline: v2.0 (2026-Q4))

## 📡 OBSERVABILITY INSTRUMENTATION
The following elements emit metrics, traces, or log statements that downstream dashboards and alerts depend on. Never remove or rename instrumentation without flagging the affected dashboard.

* `com.example.metrics.OrderMetrics.recordOrderPlaced(java.lang.String,boolean)` - Metrics: orders.placed.total, orders.placed.failed. Traces: order.place. Logs: OrderPlaced, OrderPlacementFailed. Note: Watched by the Orders SLO dashboard (https://grafana.internal/d/orders-slo).

## 📜 REGULATORY COMPLIANCE
The following elements implement specific compliance clauses. Any change MUST document its compliance impact and MUST NOT weaken the requirement.

* `com.example.compliance.GdprService` - GDPR Art. 17 — Right to erasure — when invoked, deletes ALL PII for the given user across every connected store.
* `com.example.compliance.GdprService.exportUserData(java.lang.String)` - GDPR Art. 20 — Right to data portability — exports the user's data in a machine-readable format.

## 🧪 STRICT TEST ISOLATION
The following elements must be strictly isolated when generating or modifying tests. No shared mutable state or resource conflicts are permitted.

* `com.example.config.ParallelTestSettings` - Strict test isolation required. No shared mutable state or external resource conflicts. Reason: Tests here bind to fixed port 8080; a shared static counter caused flaky CI in build #4471 — keep cases isolated

## 🌉 LEGACY COMPATIBILITY BRIDGE
The following elements are legacy compatibility bridges. Do not attempt to modernize or refactor their structural patterns; only modify internal business logic as explicitly requested.

* `com.example.legacy.LegacyBridgeService` - Legacy/compatibility bridge. Do not refactor structural patterns; only modify internal business logic as explicitly requested. Reason: Mirrors a quirk in the upstream mainframe wire format (KEY=…;VAL=… with no escaping); 'modernizing' it broke the EBCDIC gateway in 2023

## 🏛️ ARCHITECTURAL BOUNDARY CONSTRAINTS
The following elements have strict layering constraints. Prohibit imports or references that cross boundaries.

* `com.example.service.LayeredDomainService` - Belongs to layer: `domain`. Prohibited from referencing: [infrastructure, ui]

## 🔌 PUBLIC API SURFACE PROTECTION
The following elements are public-facing API surfaces. Always preserve public signatures, Javadoc, and backwards compatibility.

* `com.example.service.PublicPaymentController` - Public API surface. Preserve signature, Javadoc, backwards compatibility, and binary/source stability. Reason: Consumed by three external partner integrations pinned to v1; signature or return-shape changes are a breaking release and need a /v2 endpoint instead

## 🚨 STRICT EXCEPTION HANDLING
The following elements have strict exception constraints. Prohibit catching or throwing generic Exception/Throwable.

* `com.example.service.TransactionalPaymentService` - Strict exception handling required. Catching/throwing generic Exception/Throwable is prohibited. Reason: A bare catch(Exception) here once swallowed a TransactionRolledbackException and double-charged customers; only catch the specific types you handle

## 🏷️ STRICT TYPE SAFETY
The following elements prohibit loose typing such as Object or Map<String, Object>. Strong type safety is required.

* `com.example.payment.PaymentDetails` - Loose typing (Object, Map<String, Object>, raw types) is prohibited. Enforce type safety. Reason: Currency math broke in INC-4412 when a double leaked into amount; keep money as BigDecimal and never widen these fields to Object/Map

## 🌐 INTERNATIONALIZATION MANDATE
The following elements implement i18n requirements. Prohibit hardcoded user-facing strings.

* `com.example.utils.I18nMessageHelper` - Internationalization mandated. User-facing strings must not be hardcoded; retrieve from resources. Reason: Ships in 11 locales; a hardcoded English string here shipped to the German build last quarter and failed the l10n audit — always resolve via the bundle

## 🛡️ STRICT CLASSPATH INTEGRITY
The following elements prohibit dynamic runtime class loading, reflections, or loading of unverified dynamic code.

* `com.example.utils.StrictUtility` - Strict compile-time dependency/classpath constraints. Dynamic loading and reflection hacks prohibited. Reason: Runs inside the locked-down payment sandbox where the SecurityManager forbids reflection and custom classloaders; dynamic loading throws at runtime

## 🗄️ SCHEMA & SERIALIZATION SAFETY
The following elements have schema safety constraints. Restrict changing formats/fields without a backward-compatible migration plan.

* `com.example.database.UserEntity` - Schema/serialization safety guaranteed. Prohibit altering data formats or fields without migration plan. Reason: Maps to the users table replicated to the billing read-model; renaming a column or changing a type needs a backward-compatible Flyway migration first

## ♻️ IDEMPOTENCY GUARANTEES
The following operations are idempotent. Multiple invocations MUST produce the same result as a single invocation. Never introduce side effects that break this guarantee.

* `com.example.compliance.GdprService.deleteAllUserData(java.lang.String)` - Idempotency guaranteed. Multiple invocations must produce the same result as one. Reason: Deleting a user's data multiple times must produce the same result as deleting once — must not throw on second invocation.

## 🚩 FEATURE FLAG GATED CODE
The following elements are gated behind a feature flag. Do not assume the flag is always active. Preserve the flag check.

* `com.example.service.InventoryService.sendLowStockAlert(java.lang.String,int)` - Gated by feature flag: 'inventory.push-alerts.enabled' (default: false). Preserve the flag check — never assume it is always on.

## 🔐 SECURITY-CRITICAL CODE
The following elements are security-critical. AI must not weaken security properties. Any change must be reviewed for security impact.

* `com.example.security.SecurityConfig` - Security-critical code [authentication]. Do not weaken security properties. Flag any change for security review.

## 🚫 ACCESS & CALLS LIMITATIONS
The following elements have strict caller access limits. AI must not invoke them from outside the allowed boundaries.

* `com.example.service.NewAnnotationsShowcase.executeSecureDatabaseWipe()` - Only callable by: [com.example.service.PricingService, com.example.payment.PaymentProcessor]

## 🛡️ SANDBOX & TEST HARNESS EXCLUSION
The following elements are strictly sandbox/test code. Production code must never import or reference them.

* `com.example.service.NewAnnotationsShowcase.SandboxTestHelper` - Strictly sandbox or test environment only. Production code must never import or invoke. Reason: Spins up an in-memory mock DB and seeds fake credentials; a prod call path once imported this in a hotfix and leaked test data into staging

## ⚡ MEMORY ALLOCATION BUDGETS
The following elements have strict heap allocation, autoboxing, or garbage budgets. Optimize allocations carefully.

* `com.example.service.NewAnnotationsShowcase.calculateFastFibonacci(int)` - Strict memory budget policy: ZERO_ALLOCATION. Minimize or prevent runtime allocations.

## 🧠 DETERMINISTIC PURE FUNCTIONS
The following elements must remain pure functions without side effects or mutations.

* `com.example.service.NewAnnotationsShowcase.calculateFastFibonacci(int)` - Must remain a pure function. Forbid assignments to enclosing state, fields, or static members. Reason: Memoized elsewhere on the assumption it is referentially transparent; adding logging or a cache mutation here would corrupt those callers

## 🧱 FRAMEWORK-FREE DOMAIN ENTITIES
The following elements are pure Domain Models. Do not import Spring, JPA/Hibernate, Jackson, or other framework packages.

* `com.example.service.NewAnnotationsShowcase.ImmutableProductPrice` - Pure Domain Model. Banned imports: [Spring, JPA, Hibernate, Jackson, etc.]. Allowed imports: [java.math.BigDecimal]

## ❄️ open-closed EXTENSION PATTERNS
The following elements require extension using polymorphic patterns (Strategy/Visitor). Do not append branch conditionals.

* `com.example.service.NewAnnotationsShowcase.TaxCalculatorStrategy` - Designed for extension via strategy/polymorphism. Do not expand conditionals/switch chains. Required Pattern: STRATEGY_PATTERN

## 🚨 MANDATORY INPUT SANITIZATION
The following parameters/fields must go through strict sanitizers before hitting queries or renderers.

* `com.example.service.NewAnnotationsShowcase.executeDatabaseQuery(java.lang.String)#sqlRawInput` - Input parameter/field must be strictly sanitized against injection attacks: [SQL_INJECTION]

## 🔒 SECURE LOGGING MASKING
The following sensitive elements must be masked, hashed, or omitted from log/stdout streams.

* `com.example.service.NewAnnotationsShowcase.registerUserSession(java.lang.String,java.lang.String,java.lang.String)#creditCardNumber` - Sensitive variable. Forbid direct logging/printing. Enforce masking policy: MASK_CREDIT_CARD
* `com.example.service.NewAnnotationsShowcase.registerUserSession(java.lang.String,java.lang.String,java.lang.String)#passwordRaw` - Sensitive variable. Forbid direct logging/printing. Enforce masking policy: HASH

## 📋 REQUIRED CHAIN-OF-THOUGHT EXPLANATIONS
Any change made to these elements requires a step-by-step mathematical/architectural proof of correctness in the PR/walkthrough.

* `com.example.service.NewAnnotationsShowcase.runComplexMatrixMath(double[][],double[][])` - Requires step-by-step mathematical or logical explanation (Chain-of-Thought) of all changes. Complexity: HIGH

## 🛠️ EXPERIMENTAL PROTOTYPE STUBS
Strict QA constraints and tests are relaxed for these elements, but production classes must never import them.

* `com.example.service.NewAnnotationsShowcase.DraftKafkaIntegrationSpike` - Experimental prototype class. Strict constraints (test coverage, i18n) are suspended. Stable production code must never depend on it. Reason: Throwaway spike for the Q3 Kafka evaluation — no error handling or back-pressure on purpose; do not let production services depend on it

## ⚠️ SUNSET DEPRACTED APIs
Strictly sunset under deprecation. Introducing *new* references or calls to these elements is forbidden.

* `com.example.service.NewAnnotationsShowcase.deprecatedLegacyCalculatePrice(double,double)` - Strictly sunset/deprecated. Forbid any *new* calls or references. JIRA: DEBT-742. Replacement: `com.example.service.PricingService`

## 🚧 TEMPORARY CODE WORKAROUNDS
Temporary stubs or hacks that must be refactored or removed before their expiration limit.

* `com.example.service.NewAnnotationsShowcase.temporaryUpstreamBypass()` - Temporary logic/workaround. Expires on: 2028-12-31. Reason: Hotfix workaround until upstream payment provider updates their API.

## 🤖 GENERATED CODE — EDIT THE SOURCE
These elements are machine-generated and hand edits are silently overwritten. Read them freely; never write them. Change the named source and regenerate.

* `com.example.service.EvidenceBasedShowcase` - Generated from `src/main/resources/openapi/checkout.yaml`. Hand edits are overwritten — edit `src/main/resources/openapi/checkout.yaml` instead, then run `mvn generate-sources`.

## 🧩 LOAD-BEARING ODDITIES
These look wrong, redundant, or over-defensive and are deliberate. Refactoring is allowed only while the stated invariant survives.

* `com.example.service.EvidenceBasedShowcase.settledOrderIds` - Looks removable but is deliberate. Invariant: Settled orders stay in the list until the reconciliation job drains it Breaks if changed: Clearing eagerly drops in-flight settlements and silently under-reports revenue Not a defect — do not flag.

## ⛔ BANNED APIs AT THIS ELEMENT
The following APIs compile here but are prohibited. Use the sanctioned replacement instead.

* `com.example.service.EvidenceBasedShowcase.totalWithTax(java.math.BigDecimal,java.math.BigDecimal)` - Must not use: java.lang.System.out, java.util.Date, java.lang.Double. Use the injected org.slf4j.Logger, java.time.Instant, and java.math.BigDecimal instead. (Console output bypasses structured logging; Date and Double are unsafe for money and time)

## 🧵 THREAD AFFINITY (NOT THREAD-SAFE)
These elements are safe on exactly one thread. Do NOT add locks to "make them thread-safe" — marshal the call onto the required thread instead.

* `com.example.service.EvidenceBasedShowcase.refreshCartBadge()` - Pinned to the checkout-ui thread only. NOT thread-safe — adding a lock is the wrong fix. Marshal via CheckoutDispatcher.runOnUiThread. If violated: Cart totals render stale under load; no exception is thrown

## 🔗 MIRRORED — EDIT ALL SITES TOGETHER
These elements are duplicated elsewhere. They may change freely, but a partial change silently desyncs a mirror no compiler checks.

* `com.example.service.EvidenceBasedShowcase.CATALOG_VERSION` - Editing this requires the same edit at: pom.xml:<version>, README.md version badge, docs/CHANGELOG.md. The release version is duplicated across build config, docs, and the badge. Enforced by ProjectFactsConsistencyTest.
<!-- VIBETAGS-MODULE-END: annotations-showcase -->
<!-- VIBETAGS-MODULE: app -->
---
name: vibetags-guardrails
description: "AI guardrails and coding rules generated by VibeTags from @AILocked, @AIContext, and related annotations. Load this skill when writing, reviewing, or modifying code in this project."
---

# AUTO-GENERATED AI RULES
# Generated by VibeTags | https://github.com/PIsberg/vibetags
# Do not edit manually.

## LOCKED FILES (DO NOT EDIT)

## CONTEXTUAL RULES
* `com.example.gmm.app.App`
  * Focus: Wiring only: parsing and rendering live in their own modules
  * Avoid: Business logic

## 🛡️ MANDATORY SECURITY AUDITS
When proposing edits or writing code for the following files, you MUST perform a security review before outputting the final code. You must explicitly state in your response that you have audited the changes for the required vulnerabilities.

* `com.example.gmm.app.App`
  - Required Checks: Path Traversal
<!-- VIBETAGS-MODULE-END: app -->
<!-- VIBETAGS-MODULE: core -->
---
name: vibetags-guardrails
description: "AI guardrails and coding rules generated by VibeTags from @AILocked, @AIContext, and related annotations. Load this skill when writing, reviewing, or modifying code in this project."
---

# AUTO-GENERATED AI RULES
# Generated by VibeTags | https://github.com/PIsberg/vibetags
# Do not edit manually.

## LOCKED FILES (DO NOT EDIT)
* `com.example.gmm.core.IrNode` - Reason: Core IR node shape is depended on by every downstream module

## CONTEXTUAL RULES
* `com.example.gmm.core`
  * Focus: Immutable IR data model shared across every module of the reactor.
  * Avoid: Adding mutable state, framework annotations, or a dependency on any sibling module.

## 🧵 THREAD-SAFE BY DESIGN
The following elements are explicitly designed to be thread-safe via the named strategy. Any modification MUST preserve the synchronization invariant and document its reasoning.

* `com.example.gmm.core` - Strategy: IMMUTABLE. Note: Every type in this package is safe to publish across threads without synchronization.

## 🔐 SECURITY-CRITICAL CODE
The following elements are security-critical. AI must not weaken security properties. Any change must be reviewed for security impact.

* `com.example.gmm.core` - Security-critical code [Node identity is a security boundary: never build an IrNode from unvalidated external input, and never expose its raw name in a URL or log line.]. Do not weaken security properties. Flag any change for security review.
<!-- VIBETAGS-MODULE-END: core -->
<!-- VIBETAGS-MODULE: platform -->
---
name: vibetags-guardrails
description: "AI guardrails and coding rules generated by VibeTags from @AILocked, @AIContext, and related annotations. Load this skill when writing, reviewing, or modifying code in this project."
---

# AUTO-GENERATED AI RULES
# Generated by VibeTags | https://github.com/PIsberg/vibetags
# Do not edit manually.

## LOCKED FILES (DO NOT EDIT)

## CONTEXTUAL RULES

## 🛡️ MANDATORY SECURITY AUDITS
When proposing edits or writing code for the following files, you MUST perform a security review before outputting the final code. You must explicitly state in your response that you have audited the changes for the required vulnerabilities.

* `com.example.gmm.platform.Telemetry`
  - Required Checks: PII in metric labels

## 📡 OBSERVABILITY INSTRUMENTATION
The following elements emit metrics, traces, or log statements that downstream dashboards and alerts depend on. Never remove or rename instrumentation without flagging the affected dashboard.

* `com.example.gmm.platform.Telemetry` - Metrics: reactor.render.count, reactor.render.duration. Note: Metric names are a published contract; renaming one breaks every dashboard reading it

## 🚩 FEATURE FLAG GATED CODE
The following elements are gated behind a feature flag. Do not assume the flag is always active. Preserve the flag check.

* `com.example.gmm.platform.FeatureGate` - Gated by feature flag: 'reactor.parallel-render' (default: false). Preserve the flag check — never assume it is always on.
<!-- VIBETAGS-MODULE-END: platform -->
<!-- VIBETAGS-END -->