Dev -> Stage Timing Framework Browser Relative Link Fix

.cursor/rules/manifest.json

@@ -0,0 +1,90 @@
+{
+  "version": "mjdyprbm",
+  "releaseTag": "rules-2025.12.20.1766214843475",
+  "generated": "2025-12-20T07:14:03.538Z",
+  "lastUpdated": "2026-02-02T17:05:36.800Z",
+  "lastUpdateReleaseTag": "rules-2025.12.20.1766214843475",
+  "installedDomains": [
+    "security-global",
+    "security-lang"
+  ],
+  "files": {
+    "security-global/security-global-api.mdc": {
+      "sha256": "bc5510baa27b5aaa9998ed22a5cb35c8636eb20951eb1f4adca9fb2bd3b7cb9f",
+      "domain": "security-global"
+    },
+    "security-global/security-global-auth.mdc": {
+      "sha256": "46d4e0b6a5c0ac5693a6346b0df52a81066d9b4d6af93b1caffacde1cff65575",
+      "domain": "security-global"
+    },
+    "security-global/security-global-base.mdc": {
+      "sha256": "caa12169275a156517e6602213d54871c250d90e3ed56edb429d44ac63796936",
+      "domain": "security-global"
+    },
+    "security-global/security-global-data-protection.mdc": {
+      "sha256": "cd996de2e9bd366128ab45f04d96755340aa3949114734e0fb57d7f88b71d9fc",
+      "domain": "security-global"
+    },
+    "security-global/security-global-dangerous-flows.mdc": {
+      "sha256": "c1d5ef612881bd724362caba1d0295ffeee00ebf61f190cbd9399fcbd6683e35",
+      "domain": "security-global"
+    },
+    "security-global/security-global-dependency-mgmt.mdc": {
+      "sha256": "c7941d14cc884098112a6fa709c0cb7bd1bdd1e6bd4d81320aa86597885ea0c4",
+      "domain": "security-global"
+    },
+    "security-global/security-global-error-handling.mdc": {
+      "sha256": "41bff2ae7a4dce1eebd89b11a801a4a0d5f133568aeff117541b4eef932d5a57",
+      "domain": "security-global"
+    },
+    "security-global/security-global-injection-prevention.mdc": {
+      "sha256": "f375934ea9923e7951e4796acbe42676f7db783bb326adaaec3b996ad706211f",
+      "domain": "security-global"
+    },
+    "security-global/security-global-input-validation.mdc": {
+      "sha256": "b5eb90ff796e9d6eccbe4fb568e82e6b05d1e81df309426eaa6a7e6799c664e1",
+      "domain": "security-global"
+    },
+    "security-global/security-global-mcp-usage.mdc": {
+      "sha256": "9eea0468b8179d3e98bfc65dd246e1f77740d0500842e6ccce5bd11ab3d19ab2",
+      "domain": "security-global"
+    },
+    "security-global/security-global-output-encoding.mdc": {
+      "sha256": "c8e418e38ebb547675a0e9b731b42b5ee79312f91cee4267e9227613d5628748",
+      "domain": "security-global"
+    },
+    "security-global/security-global-pathtraversal-prevention.mdc": {
+      "sha256": "801cdea14c4b81a4fc3cf60883a4f28ab24d8e077a871f66e86590ed2dba455b",
+      "domain": "security-global"
+    },
+    "security-global/security-global-secure-configuration.mdc": {
+      "sha256": "1b6078fada5d8f435e57c14d936830b699f58b203fb1c4040e6703397a175c5d",
+      "domain": "security-global"
+    },
+    "security-global/security-global-snyk.mdc": {
+      "sha256": "a2bcdb8edff4855335709a93900fc4ec2af015dc774ddaec0d8945b9f207b12e",
+      "domain": "security-global"
+    },
+    "security-global/security-global-sql-usage.mdc": {
+      "sha256": "15ec05dfd5e77947fdebfa18a77fe4834c317d5cc05fee6878c1ef10e7c1b2ca",
+      "domain": "security-global"
+    },
+    "security-global/security-global-ssrf-prevention.mdc": {
+      "sha256": "0aa1c358b7e89864b5b0e6f5e1ae28934dcc48a85039d470f1d25b116e96ea54",
+      "domain": "security-global"
+    },
+    "security-global/security-global-xxe-prevention.mdc": {
+      "sha256": "602001540bf52109be10a76e9626c98781aa532d3b12896b797258c4b0f49ee4",
+      "domain": "security-global"
+    },
+    "security-lang/security-lang-node.mdc": {
+      "sha256": "9019cc2470bbfc6d01c5c34aff42498a91b59ca9766a34a79de1ebe93cc6c587",
+      "domain": "security-lang"
+    }
+  },
+  "stats": {
+    "totalFiles": 18,
+    "missingFiles": 0,
+    "domains": 2
+  }
+}

.cursor/rules/security-global/security-global-api.mdc

@@ -0,0 +1,50 @@
+---
+description: USE WHEN designing, implementing, or reviewing API security (versioning, auth, rate limits, testing)
+alwaysApply: false
+---
+# API Security
+
+These rules apply to Secure API design and implementation and it is critical for protecting data and services.
+
+### Secure API design
+- Version endpoints using semantic versioning (`/v1/`, `/v2/`,`/v3/`,`/v4/`)
+- Grant only the minimum permissions needed for each endpoint
+- Document required authentication method and specific permission scopes in OpenAPI/Swagger
+- Re-use security patterns across endpoints for consistency
+- Return consistent HTTP status codes and error messages following RFC 7807
+
+
+### Auth & access
+- Require OAuth 2.0 / JWT for user authentication
+- Validate tokens on every request with proper signature verification
+- Enforce Role-Based Access Control (RBAC) or Attribute-Based Access Control (ABAC)
+- Issue API keys with specific scopes for service-to-service calls
+- Implement token refresh with secure rotation
+
+### Request protection
+- Apply rate‑limit & throttle
+- Validate request schema using JSON Schema or similar validation
+- Configure CORS to allow only specific origins, methods, and headers
+- Check content-type headers and validate request structure
+- Block parameter pollution attacks by validating parameter names
+
+## Security Headers
+- Set `X-Content-Type-Options: nosniff`
+- Set `X-Frame-Options: DENY` or `X-Frame-Options: SAMEORIGIN`
+- Set `X-XSS-Protection: 1; mode=block`
+- Implement Content Security Policy (CSP) headers
+- Use `Strict-Transport-Security` for HTTPS enforcement
+
+
+### Test & monitor
+- Run API‑focused security tests
+- Log security findings and fix critical issues 
+- Track & fix findings
+
+## Anti-Patterns to Avoid
+- Leaking sensitive data in API responses (PII, tokens, internal errors)
+- Allowing insecure direct object references without access checks
+- Serving APIs over HTTP (always use HTTPS)
+- Skipping input validation on any endpoint
+- Revealing stack traces or internal system details in error responses
+- Using weak authentication methods (Basic Auth, API keys without scopes)

.cursor/rules/security-global/security-global-auth.mdc

@@ -0,0 +1,58 @@
+---
+description: USE WHEN implementing user authentication, login systems, session management, or access control
+alwaysApply: false
+---
+# Authentication & Authorization
+
+Secure authentication and authorization are essential for protecting user data and system resources.
+
+## Authentication Best Practices
+
+### Password Management
+
+- Implement strong password requirements (minimum 12 characters, must include uppercase, lowercase, numbers, and special characters)
+- Store passwords using strong, slow hashing algorithms (bcrypt with 12+ rounds, Argon2)
+- Never store plaintext passwords in any form
+- Implement account lockout after 5 failed attempts with 30-minute lockout period
+
+### Multi-Factor Authentication
+
+- Implement MFA for all user accounts, especially admin users and users with financial access
+- Support multiple second-factor options (TOTP, SMS, email, hardware tokens)
+- Apply MFA to critical operations (password resets, financial transactions, admin actions, data exports)
+- Verify MFA on the server side, never trust client-side validation
+
+### Session Management
+
+- Generate strong, random session identifiers (32+ characters using cryptographically secure random)
+- Implement secure cookie attributes (Secure, HttpOnly, SameSite=Strict)
+- Apply appropriate session timeouts (15 minutes for sensitive operations, 2 hours for regular sessions)
+- Invalidate sessions on logout and password change
+- Regenerate session IDs after authentication
+- Implement mechanisms to revoke sessions remotely
+
+## Authorization Best Practices
+
+### Access Control Models
+
+- Implement Role-Based Access Control (RBAC) with resource-level permissions (read, write, delete)
+- Apply the principle of least privilege for all users
+- Use attribute-based access control for fine-grained permissions
+- Centralize authorization logic in dedicated services
+
+### Implementation Patterns
+
+- Verify authorization on every request, including API calls
+- Implement authorization checks at multiple layers (frontend UI, API middleware, database row-level security)
+- Apply consistent authorization across all interfaces (API, UI, CLI)
+- Never rely on client-side authorization alone
+
+## Anti-Patterns to Avoid
+
+- Implementing custom authentication schemes without security review
+- Relying on security through obscurity
+- Hardcoding credentials in source code
+- Using direct object references without access checks
+- Implementing client-side authorization only
+- Storing session tokens in localStorage
+- Using weak password requirements (under 12 characters, no complexity requirements, or common passwords)

.cursor/rules/security-global/security-global-base.mdc

@@ -0,0 +1,76 @@
+---
+alwaysApply: true
+---
+These rules define essential practices for writing and generating secure code.  
+They apply universally — to manual development, automated tooling, and AI-generated code.
+Our codebase follows a **security‑first** mindset: security is built in from day one.
+
+All violations must include a clear explanation of which rule was triggered and why, to help developers understand and fix the issue effectively.
+
+## Core Security Principles
+
+### 1. Defense in Depth
+- Implement multiple layers of security controls
+- Apply security at every level (UI, API, database, infrastructure)
+- Never rely on a single security measure
+
+### 2. Principle of Least Privilege
+- Grant minimal access required for functionality
+- Use role-based access control (RBAC)
+- Limit permissions to the smallest scope necessary
+
+### 3. Fail Securely
+- Default to secure state when errors occur
+- Implement graceful degradation
+- Never expose sensitive information in error messages
+
+### 4. Secure by Default
+- Ship secure configurations without extra setup
+- Enable security features automatically
+- Require explicit opt-out for insecure options
+
+### 5. Keep It Simple
+- Reduce complexity to minimize attack surface
+- Avoid over-engineering security solutions
+- Use proven, well-tested security patterns
+
+## Critical Security Rules
+
+### 1. Do Not Use Raw User Input in Sensitive Operations
+- **Rule:** Untrusted input must never be used directly in file access, command execution, database queries, or similar sensitive operations.
+
+### 2. Do Not Expose Secrets in Public Code
+- **Rule:** Secrets such as API keys, credentials, private keys, or tokens must not appear in frontend code, public repositories, or client-distributed files.
+
+### 3. Enforce Secure Communication Protocols
+- **Rule:** Only secure protocols (e.g., HTTPS, TLS) must be used for all external communications.
+
+### 4. Avoid Executing Dynamic Code
+- **Rule:** Dynamically constructed code or expressions must not be executed at runtime.
+
+### 5. Validate All External Input
+- **Rule:** Inputs from users, external APIs, or third-party systems must be validated before use.
+
+### 6. Do Not Log Sensitive Information
+- **Rule:** Logs must not contain credentials, tokens, personal identifiers, or other sensitive data.
+
+### 7. Prevent Disabling of Security Controls
+- **Rule:** Security checks must not be disabled, bypassed, or suppressed without documented and reviewed justification.
+
+### 8. Limit Trust in Client-Side Logic
+- **Rule:** Critical logic related to permissions, authentication, or validation must not rely solely on client-side code.
+
+### 9. Detect and Eliminate Hardcoded Credentials
+- **Rule:** Credentials must not be hardcoded in source files, configuration or scripts.
+
+### Security review – apply every PR
+- Identify potential vulnerabilities introduced
+- Verify correct implementation of controls
+- Ensure secure coding patterns are followed
+
+### Key principles
+- Enforce defense in depth
+- Grant least privilege
+- Fail securely on error
+- Ship secure‑by‑default configs
+- Keep designs simple to reduce attack surface