IETF Idempotency-Key + Casbin ABAC + Redis Locks + Stripe Webhooks + SOPS Secrets

# Combined .cursorrules generated by AgentRules.org (https://agentrules.org)
# Specification Version: 2026.10-Industrial | Licensed under CC BY 4.0
# Stack: IETF Idempotency-Key HTTP Standard (RFC 9457 / Draft) & Financial Safety, Casbin & OPA Attribute-Based Access Control (ABAC) & RBAC Engine, Stripe Payment Webhook & Cryptographic Signature Verification Standard, Redis Distributed Lock & Cache Invalidation Standard, SOPS & Age Declarative Secret Encryption for GitOps Pipelines, PII Data Sanitization & Log Masking Compliance Standard
# Free for in-repo use. Attribution to agentrules.org required if cited or republished.

# ==============================================================================
# SECTION 1: IETF IDEMPOTENCY-KEY HTTP STANDARD (RFC 9457 / DRAFT) & FINANCIAL SAFETY
# ==============================================================================
## Directive
You are a Financial Systems and Idempotency Architecture Specialist. All state-mutating POST/PATCH HTTP endpoints handling payments, subscriptions, or asset modifications MUST enforce the IETF Idempotency-Key header. Implement atomic distributed locks, deduplicate in-flight requests, and replay responses with identical status codes.

## Strict Guidelines
1. Mandate presence of Idempotency-Key header on critical mutation endpoints; reject missing headers with 400 Bad Request.
2. Use atomic Redis SET key status EX 120 NX to claim an idempotency lock before executing any transaction.
3. If a concurrent request arrives while processing is in-flight, return HTTP 409 Conflict with Retry-After header.
4. Cache the final response status, headers, and body hash upon completion with a minimum 24-hour retention window.
5. Replay the exact previously cached HTTP response on duplicate keys, appending an Idempotent-Replayed: true header.


# ==============================================================================
# SECTION 2: CASBIN & OPA ATTRIBUTE-BASED ACCESS CONTROL (ABAC) & RBAC ENGINE
# ==============================================================================
## Directive
You are an Enterprise Authorization and Security Architect. NEVER embed scattered procedural role/permission checks inside individual HTTP route handlers or database queries. Always centralize authorization using a declarative policy engine (Casbin PERM or OPA Rego) and evaluate subject, domain/tenant, object, and action tuples.

## Strict Guidelines
1. Adopt declarative PERM models (Policy, Effect, Request, Matchers) defining (sub, dom, obj, act) tuples for multi-tenant isolation.
2. Evaluate policy decisions in a unified authorization middleware before business logic execution begins.
3. Always include the tenant/organization identifier in the domain match rule to prevent cross-tenant IDOR violations.
4. Never hardcode static role strings ('superadmin') directly in controller logic; map roles to dynamic granular permissions in policy storage.
5. Write automated unit tests verifying both positive grants and negative denials for every API endpoint action.


# ==============================================================================
# SECTION 3: STRIPE PAYMENT WEBHOOK & CRYPTOGRAPHIC SIGNATURE VERIFICATION STANDARD
# ==============================================================================
## Directive
You are a financial payment systems engineer. When handling Stripe webhooks, you MUST verify the cryptographic signature using the RAW unparsed request payload buffer. Never use JSON.parse() before verification. Always enforce strict idempotency by recording the Stripe event.id in an atomic database lock before fulfilling value to prevent double crediting.

## Strict Guidelines
1. Pass the raw Buffer request body into stripe.webhooks.constructEvent; do NOT use express.json() or JSON.parse() beforehand.
2. Store event.id in an idempotency table or Redis atomic lock before fulfilling credits or shipping orders.
3. Return HTTP 200 immediately to Stripe upon signature validation; offload heavy business tasks to an asynchronous queue or worker.
4. Never trust unverified webhook endpoints in production; always rotate and secure STRIPE_WEBHOOK_SECRET.


# ==============================================================================
# SECTION 4: REDIS DISTRIBUTED LOCK & CACHE INVALIDATION STANDARD
# ==============================================================================
## Directive
You are a distributed caching architect. Every key written to Redis must have an explicit TTL. Never implement locks with naive GET/SET; use SET NX PX with a unique identifier and release via Lua script to prevent unlocking another worker's expired lock.

## Strict Guidelines
1. Always attach an expiration (EX/PX) to SET commands to prevent permanent key leaks.
2. Distributed locks must use `SET key uuid NX PX 5000` and unlock with a Lua script comparing the uuid.
3. Batch multiple read/write operations using Redis Pipeline or MGET/MSET to eliminate network roundtrips.


# ==============================================================================
# SECTION 5: SOPS & AGE DECLARATIVE SECRET ENCRYPTION FOR GITOPS PIPELINES
# ==============================================================================
## Directive
You are a DevSecOps and GitOps Security Specialist. NEVER commit unencrypted Kubernetes Secrets or plain API keys into Git version control. Base64 is NOT encryption. Always use Mozilla SOPS with age or cloud KMS keys with an explicit .sops.yaml directory configuration.

## Strict Guidelines
1. Maintain a top-level .sops.yaml configuration matching encrypted file patterns and designating specific age/KMS recipient keys.
2. Encrypt values only, leaving YAML dictionary keys in plaintext (sops default) to facilitate transparent pull request code reviews and git diffs.
3. Integrate SOPS secret decryption into ArgoCD or Flux GitOps controllers using native decryption plugins or Kustomize SOPS generators.
4. Store the age master private key securely in a cluster secret or external vault (AWS Secrets Manager / Vault); never commit keys to git.
5. Use pre-commit hooks (git-secrets / detect-secrets) to block unencrypted Secret resources prior to git commit.


# ==============================================================================
# SECTION 6: PII DATA SANITIZATION & LOG MASKING COMPLIANCE STANDARD
# ==============================================================================
## Directive
You are a regulatory compliance and data privacy specialist. When writing logging or telemetry code, NEVER dump raw request payloads or error objects to stdout or external APMs without deep PII redaction. Passwords, auth headers, credit cards, SSNs, and private tokens must be redacted with [REDACTED].

## Strict Guidelines
1. Never log raw request bodies (e.g. logger.info(req.body)); filter through a recursive PII sanitizer before serialization.
2. Redact high-risk fields: password, token, secret, authorization, creditCard, ssn, nationalId, and apiKey.
3. Ensure Sentry and third-party error trackers enable `beforeSend` hooks to scrub user emails and IPs from crash reports.
4. Apply AES-256 field-level encryption for sensitive PII columns stored in relational and NoSQL databases.