azcodr 1.2.2 → 1.4.0

package/docs/rules/api_versioning.md

@@ -1,113 +0,0 @@
-# API Versioning, SemVer Lifecycle & Swagger Multi-Version Architecture
-
-> **Core Mandate:** Enforce URI path major versioning (`/api/v1/`), SemVer 2.0.0 contract specifications, RFC 8594 Sunset/Deprecation headers, a 90-day retirement window, and multi-version Swagger UI exploration.
-
----
-
-## 1. Semantic Versioning (SemVer 2.0.0) in Web APIs
-
-Semantic Versioning maps to Web APIs according to contract stability and backward compatibility:
-
-$$\text{Version Format: } \mathbf{MAJOR.MINOR.PATCH}$$
-
-| SemVer Component | Scope & Impact | Exposure Channel | Example |
-|---|---|---|---|
-| **MAJOR** | Breaking, backwards-incompatible contract modifications. Requires client code/URL changes. | URI Path (`/api/v1/`, `/api/v2/`) & OpenAPI `info.version` | `2.0.0` |
-| **MINOR** | Backwards-compatible additive functionality, new endpoints, or optional attributes. | OpenAPI `info.version`, `API-Version` response header | `1.1.0` |
-| **PATCH** | Backwards-compatible bug fixes, performance optimizations, and documentation fixes. | OpenAPI `info.version`, release tags, telemetry metadata | `1.0.1` |
-
-> [!IMPORTANT]
-> **Why URI Path Exposes MAJOR Only:**
-> Exposing minor or patch versions in the URL path (e.g. `/api/v1.2.3/`) is a severe anti-pattern. Minor additions and bug fixes must not break client routing. Clients bind to the stable major version (`/api/v1/`) while consuming backward-compatible updates transparently.
-
----
-
-## 2. SemVer Trigger Matrix: What Triggers a Version Update?
-
-### A. MAJOR Bump (`1.x.x` ➔ `2.0.0`) — Breaking Changes
-A MAJOR version bump and a new URI prefix (`/api/v2/`) are triggered whenever existing clients would fail without code modifications:
-
-1. **Endpoint Alterations:**
-   - Deleting an existing endpoint or HTTP method.
-   - Renaming an existing URL path or subresource route.
-2. **Request Contract Breaking Changes:**
-   - Removing an existing request parameter (header, query, or body field).
-   - Renaming a request field.
-   - Changing the data type or format of a request field (e.g., string integer to number, date format change).
-   - Adding a new **mandatory / required** field to an existing request payload without a default value.
-   - Tightening input validation constraints (e.g., reducing max string length, narrowing allowed enum values).
-3. **Response Contract Breaking Changes:**
-   - Removing an existing field from a response payload.
-   - Changing the data type or structure of a response field (e.g., object converted to array, integer cents converted to float string).
-   - Changing the semantic business meaning of a field.
-4. **Behavioral & Protocol Breaking Changes:**
-   - Altering the standard HTTP status code for successful execution (e.g., changing `200 OK` to `204 No Content` or `201 Created`).
-   - Changing the error envelope schema away from RFC 7807 problem details.
-   - Changing authentication or authorization requirements (e.g. requiring a new OAuth scope or mTLS).
-
-### B. MINOR Bump (`1.0.x` ➔ `1.1.0`) — Additive, Backward-Compatible
-A MINOR version bump preserves the `/api/v1/` URI path and updates the contract specification:
-
-1. Adding completely new endpoints or resources (e.g., adding `POST /api/v1/documents/:id/signatures`).
-2. Adding new optional query parameters, headers, or request body fields.
-3. Adding new fields to response payloads (clients must follow Postel's Law / Tolerant Reader pattern).
-4. Adding new enum values to input requests if the service handles them gracefully without breaking old clients.
-5. Relaxing validation constraints (e.g., increasing maximum allowed file upload size or string length).
-6. Introducing deprecation notices on endpoints (via RFC 8594 headers) while maintaining functionality.
-
-### C. PATCH Bump (`1.0.0` ➔ `1.0.1`) — Bug Fixes & Non-Contractual Changes
-A PATCH version bump preserves contract schemas and updates release metadata:
-
-1. Internal bug fixes in domain logic that do not alter the contractual request/response schema or status codes.
-2. Performance enhancements, caching optimization, and database indexing.
-3. Security patches in dependencies and runtime frameworks.
-4. Clarifications, typo corrections, and formatting updates in OpenAPI descriptions.
-
----
-
-## 3. RFC 8594 Sunset & Deprecation Lifecycle
-
-When an older major version or endpoint is scheduled for retirement, inject standardized RFC 8594 headers:
-
-```http
-Deprecation: @1773619200
-Sunset: Wed, 16 Sep 2026 23:59:59 GMT
-Link: <https://api.domain.com/docs/migration/v2>; rel="sunset"
-```
-
-- **Mandatory 90-Day Migration Window:** Retain deprecated API versions for a minimum of 90 days following formal deprecation notification before decommissioning.
-- **Access Telemetry:** Track consumer traffic on deprecated routes via OpenTelemetry attributes (`api.deprecated=true`, `http.route`) to coordinate client migration.
-
----
-
-## 4. Swagger UI Multi-Version Selector Architecture
-
-Swagger UI must provide an interactive version dropdown selector enabling consumers and developers to inspect both active and upcoming API specifications.
-
-### Multi-Spec Configuration in Express / Swagger UI:
-```ts
-app.use(
-  '/docs',
-  swaggerUi.serve,
-  swaggerUi.setup(undefined, {
-    swaggerOptions: {
-      urls: [
-        { url: '/specs/v1/openapi.yaml', name: 'v1.0.0 (Current Stable)' },
-        { url: '/specs/v2/openapi.yaml', name: 'v2.0.0-draft (Next Major Preview)' }
-      ],
-      'urls.primaryName': 'v1.0.0 (Current Stable)'
-    }
-  })
-);
-```
-
-### Filesystem Specification Hierarchy:
-```
-specs/
-├── openapi/
-│   ├── v1/
-│   │   └── openapi.yaml
-│   └── v2/
-│       └── openapi.yaml
-```
-

package/docs/rules/application_security.md

@@ -1,23 +0,0 @@
-# Application Security & OWASP Top 10 Defenses
-
-> **Core Mandate:** Enforce proactive defenses against the OWASP Top 10 vulnerabilities, cryptographic rigor, and token-bucket rate limiting across all layers.
-
----
-
-## 1. OWASP Top 10 Defenses
-
-- **A01: Broken Access Control**: Verify permissions server-side on every request using Policy Enforcement Points (PEPs). Enforce immutable multi-tenancy data isolation (AST interceptors, database RLS, or schema namespaces).
-- **A02: Cryptographic Failures**: Passwords must be hashed using **Argon2id** with memory-hard parameters. Encrypt sensitive data at rest using authenticated ciphers (**AES-256-GCM** or **ChaCha20-Poly1305**).
-- **A03: Injection (SQL / NoSQL / Command)**: Strictly prohibit raw query string interpolation or dynamic execution. All database interactions must use parameterized prepared statements.
-- **A07: Identification and Authentication Failures**: Enforce rate limiting on auth endpoints, FIDO2/WebAuthn passkeys, and Refresh Token Rotation (RTR) with family invalidation on replay detection.
-- **A10: Server-Side Request Forgery (SSRF)**: Validate and restrict outbound network requests to an explicit allowlist of domains. Block requests targeting RFC 1918 private IP ranges, loopback addresses (`127.0.0.1`), and cloud metadata endpoints (`169.254.169.254`).
-
----
-
-## 2. Distributed API Rate Limiting
-
-- Utilize token-bucket or sliding-window rate limiters backed by a distributed in-memory cache port.
-- Enforce tiered rate limits:
-  - Authentication routes: Max 5 requests / minute per IP.
-  - Standard API routes: Max 100 requests / minute per tenant/user.
-- Return **`429 Too Many Requests`** with standard `Retry-After` and `RateLimit-*` IETF headers when limits are exceeded.

package/docs/rules/architecture_decision_records.md

@@ -1,42 +0,0 @@
-# Architecture Decision Records (ADR)
-
-> **Core Mandate:** Log all technical, architectural, and operational trade-offs in `memory.md` using the standardized Lightweight ADR format.
-
----
-
-## 1. When to Author an ADR
-
-An Architectural Decision Record must be authored whenever a team member or agent:
-- Introduces or removes an external dependency or library.
-- Modifies database schema architecture, transaction boundaries, or migration strategies.
-- Selects an architectural pattern (e.g. Server-Driven UI, Event-Driven Outbox, OpenFeature).
-- Defines security boundaries, cryptographic standards, or compliance exceptions.
-
----
-
-## 2. Lightweight ADR Format
-
-Log decisions in `memory.md` adhering to this structure:
-
-```markdown
-### ADR-[Number]: [Concise Title]
-
-- **Date:** [YYYY-MM-DD]
-- **Status:** [PROPOSED | ACCEPTED | SUPERSEDED]
-
-#### 1. Context & Problem Statement
-What business requirement, technical bottleneck, or security mandate necessitated this architectural decision?
-
-#### 2. Decision Drivers
-- [Driver 1: e.g. Zero-downtime database deployment]
-- [Driver 2: e.g. SOC 2 Type II tamper-evident logging compliance]
-
-#### 3. Considered Options
-- **Option A:** [Description and evaluation]
-- **Option B:** [Description and evaluation]
-
-#### 4. Decision Outcome & Consequences
-- **Chosen Option:** [Selected approach and core rationale]
-- **Positive Consequences:** [What improves]
-- **Negative Consequences / Trade-offs:** [What operational or code overhead is accepted]
-```

package/docs/rules/compliance.md

@@ -1,25 +0,0 @@
-# Regulatory Compliance: SOC 2, ISO 27001 & GDPR
-
-> **Core Mandate:** Enforce SOC 2 Type II Trust Services Criteria, ISO/IEC 27001 ISMS technical controls, and GDPR data subject privacy rights using open-source architectures.
-
----
-
-## 1. SOC 2 Type II Trust Services Criteria
-
-- **Access Controls (CC6.1)**: Enforce least-privilege RBAC/ABAC on all API endpoints. System-defined roles must be protected from unauthorized mutation.
-- **Tamper-Evident Audit Trails (CC7.2)**:
-  - All state mutations must create write-only, immutable audit log records:
-    `{ timestamp, actorId, tenantId, action, entityType, entityId, ipAddress, userAgent, changes: { before, after } }`.
-  - Audit logs must be retained for at least 365 days in append-only storage.
-
----
-
-## 2. ISO/IEC 27001 ISMS Technical Controls
-
-- **Annex A Cryptographic Controls (A.10.1)**: Enforce TLS 1.3 for data in transit and AES-256-GCM for sensitive data at rest. Passwords must be hashed using Argon2id or bcrypt.
-
----
-
-## 3. GDPR Data Subject Rights
-
-- **Right to Erasure (Article 17)**: Deleting a tenant or user must cascade delete or pseudonymize all associated personal identifiable information (PII) across active databases and backups.

package/docs/rules/container_infrastructure.md

@@ -1,32 +0,0 @@
-# Container Infrastructure & Local Parity
-
-> **Core Mandate:** Enforce production parity through containerized reverse proxy routing, explicit OCI service healthchecks, non-root security boundaries, and minimal distroless base images.
-
----
-
-## 1. Gateway Routing & Local Parity
-
-- **Unified Gateway Routing**: Route all local development and production services through an edge reverse proxy gateway (such as **Envoy** or **Nginx**) on standard HTTP ports to eliminate CORS discrepancies and simulate production multi-service topologies uniformly.
-- **Internal Network Isolation**: Isolate internal services and datastores on a private bridge or overlay network, exposing only the hardened gateway entrypoint to public interfaces.
-
----
-
-## 2. OCI Healthchecks & Deterministic Dependency Ordering
-
-- **Explicit Service Healthchecks**: Every database, cache, message broker, and application service in container configurations (`docker-compose.yml` or Kubernetes manifests) must define an explicit healthcheck command and interval.
-- **Strict Dependency Ordering**: Dependent application services must wait for upstream database and cache readiness, never launching before health verification:
-  ```yaml
-  depends_on:
-    database:
-      condition: service_healthy
-    cache:
-      condition: service_healthy
-  ```
-
----
-
-## 3. Container Security & Build Performance
-
-- **Non-Root Execution**: Run all application containers strictly as unprivileged users (UID >= 10001) with read-only root filesystems and dropped Linux capabilities (`cap_drop: ALL`).
-- **Minimal OCI Base Images**: Standardize on **Distroless** (Google Container Tools) or **Scratch** base images across all polyglot microservices, eliminating package managers, debug shells, and OS vulnerabilities.
-- **Multi-Stage Build Optimization**: Utilize multi-stage OCI builds with cache mounts across dependency steps to minimize image sizes and maximize layer cache reuse.

package/docs/rules/continuous_deployment.md

@@ -1,24 +0,0 @@
-# Continuous Deployment (CD) & Release Engineering
-
-> **Core Mandate:** Enforce zero-downtime deployment rollouts, cryptographic container signing with Cosign, and minimal attack surface container baselines.
-
----
-
-## 1. Zero-Downtime Deployment Strategies
-
-- **Blue-Green / Rolling Deployments**: Deploy new application versions alongside active instances, verify readiness healthchecks, and shift traffic seamlessly without dropping connections.
-- **Rollback Automation**: If error rates or latency spike beyond thresholds immediately post-deployment, automate an instant rollback to the previous stable release.
-
----
-
-## 2. Container Signing & Provenance (Cosign)
-
-- Utilize open-source **Cosign** (Sigstore) to cryptographically sign all release container images in the deployment pipeline.
-- Production Kubernetes / Docker hosts must verify Cosign image signatures and provenance attestations before pulling and launching containers.
-
----
-
-## 3. Container Minimization
-
-- Standardize on minimal container base images (`node:24-alpine` or distroless images).
-- Purge all devDependencies, compilers, and package managers from the final production container layer.

package/docs/rules/continuous_integration.md

@@ -1,20 +0,0 @@
-# Continuous Integration (CI) & Quality Gates
-
-> **Core Mandate:** Enforce shift-left automated quality gates, trunk-based development with short-lived branches, and mandatory green pipeline verification before merge.
-
----
-
-## 1. Shift-Left Automated Quality Gates
-
-Every pull request pipeline must execute automated checks in strict dependency stages:
-1. **Security & Secrets**: Open-source secret scanning (`secretlint`) and SAST analysis (`semgrep`).
-2. **Static Analysis**: ESLint (`npm run lint`) and TypeScript typecheck (`npm run typecheck`).
-3. **Full-Stack Test Coverage**: Unit and acceptance tests verifying **100.00%** coverage (`npm run coverage`).
-4. **Supply Chain Audit**: Vulnerability scan of dependencies and SBOM generation (`syft` + `grype`).
-
----
-
-## 2. Trunk-Based Development
-
-- **Short-Lived Branches**: Feature branches must live less than 24–48 hours before merging to the main trunk.
-- **Fast Build Times**: Docker build layers and npm packages must be cached in CI runners to maintain pipeline execution times under 5 minutes.

package/docs/rules/continuous_learning.md

@@ -1,29 +0,0 @@
-# Continuous Learning & Automated Rule Ingestion
-
-> **Core Mandate:** Automatically capture development defects, analyze root causes, and directly update domain rules or skills to permanently prevent recurrence without intermediate bloat.
-
----
-
-## 1. The Direct Rule Ingestion Loop
-
-Whenever an error, test failure, build friction, or architectural anti-pattern occurs during development, immediately execute the 4-step loop:
-
-```
-1. Capture Defect ──► 2. Root Cause Analysis ──► 3. Synthesize Invariant ──► 4. Update Rule / Skill
-```
-
-1. **Capture Defect**: Record the failure symptoms, stack trace, and failing test case.
-2. **Root Cause Analysis**: Identify the fundamental architectural or operational gap (not just the surface symptom).
-3. **Synthesize Invariant**: Formulate a concrete, positive architectural invariant and code example showing the correct implementation.
-4. **Update Rule / Skill**:
-   - Update the governing domain rule in `docs/rules/<domain>.md` or specialized skill in `.agents/skills/` directly.
-   - If the lesson introduces an architectural trade-off or paradigm shift, record a lightweight ADR in [`memory.md`](../../memory.md).
-   - If it unlocks a new domain, author a new atomic rule file and index it in [`AGENTS.md`](../../AGENTS.md).
-   - Run verification (`npm test && npm run validate`) to ensure 100% integrity.
-
----
-
-## 2. Institutional Memory Maintenance
-
-- **Lightweight ADR Ledger**: Major technical decisions and invariant shifts are logged in [`memory.md`](../../memory.md) linking directly to the governing rule or skill.
-- **Living Glossary**: Keep [`docs/knowledge/ubiquitous_language.md`](../knowledge/ubiquitous_language.md) updated with canonical domain terminology and forbidden synonyms.

package/docs/rules/database_integrity.md

@@ -1,80 +0,0 @@
-# Database Integrity, Constraints & Defensive Design
-
-> **Core Mandate:** Enforce data integrity via explicit foreign key delete semantics, domain CHECK constraints, interval exclusion constraints, partial unique indexes for soft deletes, and Universal Total Audit accountability.
-
----
-
-## 1. Foreign Key `ON DELETE` Semantics
-
-- **Default to `RESTRICT`**: For critical domain entities, tenant records, and financial ledgers to prevent accidental cascade destruction.
-- **Use `CASCADE` Strictly**: For direct, owned child records (e.g. `OrderItem` owned by `Order`).
-- **Use `SET NULL`**: When foreign relations are optional.
-
----
-
-## 2. Domain CHECK Constraints & Interval Exclusion
-
-- **Domain Invariants**:
-  ```sql
-  ALTER TABLE "Invoice" ADD CONSTRAINT chk_invoice_positive_amount CHECK (amount >= 0);
-  ALTER TABLE "Subscription" ADD CONSTRAINT chk_sub_dates CHECK (end_date >= start_date);
-  ```
-- **Prevent Overlapping Reservations**:
-  ```sql
-  CREATE EXTENSION IF NOT EXISTS btree_gist;
-  ALTER TABLE "RoomReservation" ADD CONSTRAINT no_overlapping_reservations
-    EXCLUDE USING gist (room_id WITH =, reservation_period WITH &&);
-  ```
-
----
-
-## 3. Soft Delete Unique Constraint Trap
-
-A standard `UNIQUE(email)` constraint fails when an active user signs up with the email of a soft-deleted record.
-- **Mandatory Standard**: Always use partial unique indexes for soft-deleted tables:
-  ```sql
-  CREATE UNIQUE INDEX idx_users_email_active ON "User"(email) WHERE deleted_at IS NULL;
-  ```
-
----
-
-## 4. Relational Foreign Key Invariants & UI Mapping
-
-- **Mandatory Existence Validation:** The application and domain layers must defensively assert foreign key target existence prior to child entity persistence. If a referenced parent entity does not exist, return an RFC 7807 problem detail (`400 Bad Request` or `404 Not Found`).
-- **No Raw Identifier Text Inputs:** User interfaces must never expose raw string or UUID input fields for foreign key references. Associations must be selected via accessible dropdown selectors (`shadcn/ui` `<Select>`) displaying human-readable contextual metadata (names, labels, numbers, pricing).
-- **Complete Lifecycle CRUD:** All relational entities must provide complete CRUD functionality (Create, Read/Detail, Update/Transition, Delete/Archive) before being considered feature-complete.
-
----
-
-## 5. Mandatory Universal Audit Columns
-
-Every stateful entity across all relational schemas, ORMs, and persistence layers must maintain strict audit accountability.
-
-### The Canonical 6 Total Audit Fields:
-All mutable database tables, domain entities, and models must define the total audit suite:
-1. **`createdAt` / `created_at`** (`TIMESTAMP WITH TIME ZONE NOT NULL DEFAULT CURRENT_TIMESTAMP`): Immutable timestamp when the record was initially created.
-2. **`createdBy` / `created_by`** (`VARCHAR/TEXT NOT NULL DEFAULT 'SYSTEM'`): The user ID (`User.id`) of the authenticated actor who created the record, or `'SYSTEM'` for automated background tasks, seeds, or system bootstrap.
-3. **`updatedAt` / `updated_at`** (`TIMESTAMP WITH TIME ZONE NOT NULL`): Timestamp automatically updated on every record mutation.
-4. **`updatedBy` / `updated_by`** (`VARCHAR/TEXT NOT NULL DEFAULT 'SYSTEM'`): The user ID (`User.id`) of the authenticated actor who performed the most recent mutation, or `'SYSTEM'` for automated workflows.
-5. **`deletedAt` / `deleted_at`** (`TIMESTAMP WITH TIME ZONE NULL`): Timestamp when the record was soft-deleted/archived. Null for active records.
-6. **`deletedBy` / `deleted_by`** (`VARCHAR/TEXT NULL`): The user ID (`User.id`) of the authenticated actor who performed or authorized deletion, or `'SYSTEM'`.
-
-All queries for active records MUST filter `WHERE deletedAt IS NULL` (or ORM equivalent). Paired with partial unique indexes `WHERE deleted_at IS NULL` where uniqueness constraints apply.
-
-### Append-Only Immutable Ledgers / Log Streams:
-Pure financial ledgers (e.g. `PaymentLedgerEntry`, `JournalEntry`) and event outbox streams are strictly immutable. They require:
-- **`createdAt` / `created_at`** (`NOT NULL DEFAULT CURRENT_TIMESTAMP`)
-- **`createdBy` / `created_by`** (`NOT NULL DEFAULT 'SYSTEM'`)
-- *Mutations and soft-deletes are prohibited*: `updatedAt`, `updatedBy`, `deletedAt`, and `deletedBy` are omitted because records are append-only. Financial adjustments must be recorded as offsetting ledger entries.
-
----
-
-## 6. Semi-Structured Evolution & Cryptographic Audit Trails
-
-- **Non-Destructive Schema Evolution via JSON**: For contractual covenants, dynamic conditions, or variable metadata subject to rapid domain iteration, employ semi-structured JSON fields (`termsJson`, `metadataJson`) validated against JSON Schema rather than premature table migrations.
-- **Cryptographic Electronic Signatures & Execution Auditing**: Legal agreements and execution records require defensible evidence beyond a boolean `isSigned` flag. All executed agreements must capture:
-  1. Typed signer legal name and designated role.
-  2. ISO 8601 UTC execution timestamp.
-  3. Authenticated actor ID (`userId`).
-  4. Client network IP address and User-Agent string.
-  5. Deterministic cryptographic checksum / hash of the executed terms.

package/docs/rules/database_migrations.md

@@ -1,41 +0,0 @@
-# Zero-Downtime Database Migrations (Expand-Contract)
-
-> **Core Mandate:** Enforce versioned declarative migrations, zero-downtime expand-contract schema evolutions, non-blocking concurrent index creation, and two-phase constraint validation.
-
----
-
-## 1. Universal Versioned & Declarative Migrations
-
-- **Strict Version Control**: All database modifications must occur via versioned migration engines (**Atlas**, **Flyway**, **Liquibase**, or **Goose**).
-- **Prohibited Actions**: Strictly forbid unversioned schema-push commands or raw manual DDL in staging or production environments.
-- **Automated CI Validation**: CI pipelines must lint migrations for breaking changes, lock timeouts, and full-table scans before merging schema PRs.
-
----
-
-## 2. Safe Column Additions & Deprecations (Expand-Contract)
-
-Never rename or drop a column in a single deployment step. Follow the 5-phase protocol:
-1. **Phase 1 (Expand):** Add the new column as nullable or with a non-locking default.
-2. **Phase 2 (Double-Write):** Deploy application version writing to both old and new columns; reads continue from the old column.
-3. **Phase 3 (Backfill):** Run batched background jobs backfilling historical rows from the old column to the new column in bounded batches (e.g. 500–1000 rows).
-4. **Phase 4 (Switch Read):** Deploy application reading and writing solely to the new column.
-5. **Phase 5 (Contract):** In the subsequent release, drop the old column and legacy constraints from the database.
-
----
-
-## 3. Concurrent Non-Blocking Indexing & Constraint Validation
-
-- **Concurrent Indexes**: Always construct indexes non-blockingly (`CREATE INDEX CONCURRENTLY` in PostgreSQL, `ALGORITHM=INPLACE, LOCK=NONE` in MySQL) to avoid locking read/write traffic:
-  ```sql
-  CREATE INDEX CONCURRENTLY idx_orders_customer_created 
-    ON orders (customer_id, created_at DESC);
-  ```
-- **Two-Phase Constraints**: Attach foreign keys and check constraints without scanning historical rows upfront, then validate asynchronously:
-  ```sql
-  -- Step 1: Attach foreign key without blocking writes
-  ALTER TABLE orders ADD CONSTRAINT fk_orders_tenant
-    FOREIGN KEY (tenant_id) REFERENCES tenants(id) NOT VALID;
-
-  -- Step 2: Validate constraint concurrently
-  ALTER TABLE orders VALIDATE CONSTRAINT fk_orders_tenant;
-  ```

package/docs/rules/database_performance.md

@@ -1,44 +0,0 @@
-# Database Performance & N+1 Prevention
-
-> **Core Mandate:** Eliminate N+1 query bottlenecks via explicit relation batching, enforce strict composite indexing, size connection pools scientifically, and terminate runaway queries with statement timeouts.
-
----
-
-## 1. N+1 Query Elimination
-
-- **Prohibit Iterative Queries in Loops**: Never query child collections inside iteration loops.
-  ```
-  ❌ FORBIDDEN:
-  parents = query("SELECT id FROM parent_table")
-  for p in parents:
-      children = query("SELECT * FROM child_table WHERE parent_id = :id", p.id)
-  ```
-- **Batching & Eager Fetching**: Always fetch related entities via single `JOIN` statements or batched `IN` clauses (`WHERE parent_id IN (...)`).
-  ```
-  ✅ CORRECT:
-  parents = query("SELECT id FROM parent_table")
-  children = query("SELECT * FROM child_table WHERE parent_id IN (:ids)", parents.map(id))
-  ```
-- **Universal DataLoader Pattern**: For decentralized domain resolvers or GraphQL pipelines, employ language-native DataLoader ports to batch and deduplicate entity lookups within an execution cycle.
-
----
-
-## 2. Multi-Tenant Indexing Strategy
-
-- **Tenant-Leading Composite Indexes**:
-  Every multi-tenant query pattern must be backed by a composite index where `tenant_id` is the primary leading column:
-  ```sql
-  CREATE INDEX idx_orders_tenant_created ON orders (tenant_id, created_at DESC);
-  CREATE UNIQUE INDEX uq_orders_tenant_number ON orders (tenant_id, order_number);
-  ```
-- **Covering Indexes**:
-  Include frequently projected columns in index definitions (`INCLUDE (status, total_amount)` in engines that support index-only scans) to avoid secondary table lookups.
-
----
-
-## 3. Connection Pooling & Statement Timeouts
-
-- **Scientific Pool Sizing Formula**:
-  $$\text{max\_connections} = (\text{CPU Cores} \times 2) + \text{Effective Disk / Spindle Count}$$
-- **Transaction-Scoped Pooling**: Use lightweight connection poolers (e.g. PgBouncer, ProxySQL, or HikariCP) in transaction pooling mode to support thousands of concurrent client connections without memory exhaustion.
-- **Defensive Statement Timeout**: Enforce strict statement timeouts (e.g. 5 seconds) at the connection pool or gateway layer to terminate unindexed runaway queries before they degrade the cluster.

package/docs/rules/database_transactions.md

@@ -1,81 +0,0 @@
-# Database Transactions, ACID Atomicity & Outbox Pattern
-
-> **Core Mandate:** Enforce full ACID transactional atomicity, appropriate isolation levels, defensive timeouts, deadlock prevention, and eliminate the dual-write problem via the Transactional Outbox pattern.
-
----
-
-## 1. ANSI SQL Transaction Isolation Levels
-
-1. **`Read Committed` (Default):** Guarantees statements see only committed data (eliminates dirty reads). Suitable for standard CRUD operations.
-2. **`Repeatable Read` (Snapshot Isolation):** All operations within the transaction see the exact same database snapshot taken at transaction start. Mandatory for multi-entity financial calculations, ledger balance transfers, and inventory decrement operations.
-3. **`Serializable`:** Strict serializability. Prevents phantom reads and write skew. Mandatory for complex booking and seat allocation operations. Requires application-level retry loops with jittered exponential backoff to handle serialization failures.
-
----
-
-## 2. Defensive Timeouts & Deadlock Prevention
-
-Prevent hung transactions or lock waits from starving database connection pools across any engine:
-
-```sql
-SET lock_timeout = '3s';                           -- Abort if lock cannot be acquired within 3s
-SET statement_timeout = '10s';                      -- Abort queries running longer than 10s
-SET idle_in_transaction_session_timeout = '30s';   -- Abort hung transactions idle for > 30s
-```
-
-### Deterministic Lock Ordering
-Always acquire locks on entities in a globally consistent order across application services (e.g. sort resource IDs lexicographically before issuing `SELECT ... FOR UPDATE`) to prevent circular wait deadlocks.
-
----
-
-## 3. Abstract Unit of Work & Transaction Boundaries
-
-Application services must control transaction boundaries via an abstract **Unit of Work** port, keeping domain logic decoupled from concrete ORMs:
-
-```
-┌────────────────────────────────────────────────────────┐
-│ Unit of Work Port Contract (Agnostic Specification)    │
-├────────────────────────────────────────────────────────┤
-│ executeTransaction(options, transactionCallback):       │
-│   options:                                             │
-│     isolationLevel: READ_COMMITTED | REPEATABLE_READ   │
-│     timeoutMs: integer (default 10000)                 │
-│     maxWaitMs: integer (default 5000)                  │
-│   behavior:                                            │
-│     1. Begin transaction on scoped connection          │
-│     2. Execute callback with transactional context     │
-│     3. On error: Rollback and propagate domain error   │
-│     4. On success: Commit atomically                   │
-└────────────────────────────────────────────────────────┘
-```
-
----
-
-## 4. Eliminating Dual-Writes: Transactional Outbox Pattern
-
-Never write to the database and publish to a message broker sequentially. Persist the domain mutation and the event record atomically within the same database transaction:
-
-```sql
-CREATE TABLE outbox_events (
-  id VARCHAR(64) PRIMARY KEY,
-  tenant_id VARCHAR(64) NOT NULL,
-  aggregate_type VARCHAR(64) NOT NULL,
-  aggregate_id VARCHAR(64) NOT NULL,
-  event_type VARCHAR(128) NOT NULL,
-  payload TEXT NOT NULL,
-  status VARCHAR(32) NOT NULL DEFAULT 'PENDING',
-  created_at TIMESTAMP WITH TIME ZONE NOT NULL DEFAULT CURRENT_TIMESTAMP
-);
-
-CREATE INDEX idx_outbox_pending ON outbox_events(status, created_at);
-```
-
-### Asynchronous Outbox Relaying
-- **Change Data Capture (CDC)**: Stream transaction logs directly to Kafka/NATS using tools like **Debezium**.
-- **Polling Worker**: Run background workers executing non-blocking polling:
-  ```sql
-  SELECT * FROM outbox_events 
-  WHERE status = 'PENDING' 
-  ORDER BY created_at ASC 
-  LIMIT 100 
-  FOR UPDATE SKIP LOCKED;
-  ```

package/docs/rules/devsecops.md

@@ -1,33 +0,0 @@
-# DevSecOps, Secret Scanning & SBOM Standards
-
-> **Core Mandate:** Enforce automated pre-commit secret gating, CycloneDX SBOM generation, polyglot SAST via Semgrep, and container/lockfile scanning with Trivy.
-
----
-
-## 1. Automated Pre-Commit Secret Gating
-
-- Run open-source secret scanning (**`gitleaks`** or **`secretlint`**) on every staged commit via pre-commit hooks.
-- Never bypass git commit hooks (`--no-verify`). Strictly forbid committing credentials, private keys, certificates, or API tokens to version control.
-
----
-
-## 2. Software Bill of Materials (SBOM) Generation
-
-- Generate reproducible **CycloneDX 1.6** or **SPDX** SBOMs for all build artifacts using open-source **`syft`**:
-  ```bash
-  syft dir:. -o cyclonedx-json=sbom.json
-  ```
-- Archive the generated `sbom.json` alongside release binaries and container registries.
-- Sign release artifacts and container images cryptographically using **Cosign** (Sigstore) with SLSA provenance attestation.
-
----
-
-## 3. Polyglot SAST & Vulnerability Scanning
-
-- **Static Analysis (SAST)**: Standardize on **Semgrep** for cross-language security and quality linting across Go, Rust, Python, Java, and TypeScript.
-- **Dependency & Container CVE Scanning**: Scan lockfiles (`go.mod`, `Cargo.lock`, `package-lock.json`, `poetry.lock`, `pom.xml`) and OCI container base images using open-source **`trivy`** and **`grype`**:
-  ```bash
-  trivy fs --severity HIGH,CRITICAL .
-  grype sbom:sbom.json
-  ```
-- Any unpatched `HIGH` or `CRITICAL` Common Vulnerabilities and Exposures (CVE) halts the continuous integration pipeline immediately.