mindforge-cc 8.2.0 → 9.0.0

package/.mindforge/mirrors/mirror-sre-776a1cf9/.mindforge/remediation-queue.json

@@ -1,47 +0,0 @@
-[
-  {
-    "span_id": "span_drift",
-    "strategy": "GOLDEN_TRACE_INJECTION",
-    "remediation_id": "rem_fuk65p",
-    "timestamp": "2026-04-11T14:32:03.707Z",
-    "effectiveness_prediction": 0.85,
-    "enqueued_at": "2026-04-11T14:32:03.707Z",
-    "status": "PENDING"
-  },
-  {
-    "span_id": "span_drift",
-    "strategy": "GOLDEN_TRACE_INJECTION",
-    "remediation_id": "rem_1y8xnj",
-    "timestamp": "2026-04-11T14:32:20.190Z",
-    "effectiveness_prediction": 0.85,
-    "enqueued_at": "2026-04-11T14:32:20.190Z",
-    "status": "PENDING"
-  },
-  {
-    "span_id": "span_drift",
-    "strategy": "GOLDEN_TRACE_INJECTION",
-    "remediation_id": "rem_9ztj8g",
-    "timestamp": "2026-04-11T14:32:52.217Z",
-    "effectiveness_prediction": 0.85,
-    "enqueued_at": "2026-04-11T14:32:52.217Z",
-    "status": "PENDING"
-  },
-  {
-    "span_id": "span_drift",
-    "strategy": "GOLDEN_TRACE_INJECTION",
-    "remediation_id": "rem_904til",
-    "timestamp": "2026-04-11T14:33:08.281Z",
-    "effectiveness_prediction": 0.85,
-    "enqueued_at": "2026-04-11T14:33:08.281Z",
-    "status": "PENDING"
-  },
-  {
-    "span_id": "span_drift",
-    "strategy": "GOLDEN_TRACE_INJECTION",
-    "remediation_id": "rem_cv5ovc",
-    "timestamp": "2026-04-11T14:33:24.811Z",
-    "effectiveness_prediction": 0.85,
-    "enqueued_at": "2026-04-11T14:33:24.811Z",
-    "status": "PENDING"
-  }
-]

package/.mindforge/mirrors/mirror-sre-776a1cf9/.mindforge/skills/accessibility/SKILL.md

@@ -1,106 +0,0 @@
----
-name: accessibility
-version: 1.0.0
-min_mindforge_version: 0.3.0
-status: stable
-triggers: accessibility, a11y, aria, ARIA, wcag, WCAG, screen reader, keyboard, focus, tab order, colour contrast, color contrast, alt text, semantic HTML, form label, button, interactive, disabled, skip link, heading hierarchy, landmark, live region, modal, dialog, tooltip, dropdown, combobox
----
-
-# Skill — Accessibility Engineering
-
-## When this skill activates
-Any task involving UI components, forms, interactive elements, or user-facing HTML.
-Load this skill for ALL frontend work — accessibility is not optional.
-
-## Mandatory standard
-WCAG 2.2 Level AA is the minimum. This is the legal requirement in most jurisdictions.
-Level AAA elements (where achievable without design compromise) are recommended.
-
-## Mandatory actions when this skill is active
-
-### Before writing any UI component
-1. Identify the semantic HTML element that best represents the component.
-   Use native HTML before ARIA. A `<button>` is always better than a `<div role="button">`.
-2. Map all interactive states: default, hover, focus, active, disabled, error, loading.
-3. Confirm colour contrast meets WCAG AA:
-   - Normal text: contrast ratio ≥ 4.5:1
-   - Large text (≥ 18pt or ≥ 14pt bold): contrast ratio ≥ 3:1
-   - UI components and graphics: contrast ratio ≥ 3:1
-
-### HTML semantics checklist (apply to every component)
-
-**Structure:**
-- [ ] One `<h1>` per page. Heading hierarchy is sequential (h1 → h2 → h3, never skip levels)
-- [ ] Landmark roles present: `<main>`, `<nav>`, `<header>`, `<footer>`, `<aside>`
-- [ ] Skip navigation link as the first focusable element on every page
-- [ ] Focus order follows DOM order (do not rely on visual layout to imply order)
-
-**Forms:**
-- [ ] Every input has a visible `<label>` (not just placeholder text)
-- [ ] Label is programmatically associated: `<label for="id">` or `aria-labelledby`
-- [ ] Required fields marked: `required` attribute + visual indicator + aria description
-- [ ] Error messages: `role="alert"` or `aria-live="polite"`, associated with field via `aria-describedby`
-- [ ] Validation errors describe the problem AND the fix, not just "Invalid input"
-
-**Interactive components:**
-- [ ] All interactive elements reachable by Tab key
-- [ ] Focus visible: never `outline: none` without a custom visible focus style
-- [ ] Keyboard shortcuts documented and not conflicting with browser/OS shortcuts
-- [ ] Custom widgets implement the correct ARIA pattern (see ARIA Authoring Practices Guide)
-- [ ] Required ARIA props present when using roles (examples below)
-
-**Images and media:**
-- [ ] Decorative images: `alt=""` (empty string, not omitted)
-- [ ] Informative images: `alt` describes the information conveyed
-- [ ] Complex images (charts, diagrams): `aria-describedby` pointing to a full text description
-- [ ] Videos: captions required. Audio descriptions for visual-only information.
-
-**Dynamic content:**
-- [ ] Content that updates dynamically: `aria-live="polite"` (non-critical) or `aria-live="assertive"` (critical)
-- [ ] Modals/dialogs: focus moves to modal on open, returns to trigger on close, `aria-modal="true"`
-- [ ] Loading states: `aria-busy="true"` on the container being updated
-- [ ] Reduced motion respected: `prefers-reduced-motion` disables non-essential animation
-
-### ARIA usage rules
-- Use ARIA only when no native HTML element conveys the role
-- ARIA roles override native semantics — applying a role to `<button>` changes it
-- Required ARIA properties: never use a role without its required properties
-  (e.g., `role="checkbox"` requires `aria-checked`)
-- Never use `aria-hidden="true"` on focusable elements
-
-### ARIA required properties examples
-- `role="checkbox"` → `aria-checked`
-- `role="switch"` → `aria-checked`
-- `role="textbox"` (non-input element) → `aria-multiline` (if multiline)
-- `role="combobox"` → `aria-expanded`, `aria-controls`, `aria-haspopup`
-- `role="dialog"` → `aria-modal`, `aria-labelledby` (and `aria-describedby` when needed)
-
-### Testing protocol
-```bash
-# Automated testing (catches ~30-40% of issues)
-npx axe-cli https://localhost:3000
-
-# Keyboard testing (manual — must be done for every interactive component)
-# 1. Tab through every interactive element — order must be logical
-# 2. Activate every control with Enter/Space — must work
-# 3. Navigate dropdowns/menus with arrow keys
-# 4. Escape dismisses modals and dropdowns
-
-# Screen reader testing (minimum: test with NVDA + Chrome on Windows OR
-#                                     VoiceOver + Safari on macOS)
-# Key checks:
-# - Every interactive element announced with role, name, and state
-# - Dynamic updates announced appropriately
-# - Images described correctly
-
-# Contrast checking
-# Install: axe DevTools browser extension or Colour Contrast Analyser
-```
-
-## Self-check before task completion
-- [ ] Ran `axe-cli` — zero violations
-- [ ] Keyboard navigation tested manually
-- [ ] All interactive elements have accessible names
-- [ ] Colour contrast meets 4.5:1 for text
-- [ ] Focus management correct for modals and dynamic content
-- [ ] No `aria-hidden` on focusable elements

package/.mindforge/mirrors/mirror-sre-776a1cf9/.mindforge/skills/api-design/SKILL.md

@@ -1,98 +0,0 @@
----
-name: api-design
-version: 1.0.0
-min_mindforge_version: 0.1.0
-status: stable
-triggers: API, endpoint, REST, GraphQL, route, controller, handler, request, response, HTTP, POST, GET, PUT, PATCH, DELETE, contract, versioning, OpenAPI
----
-
-# Skill — API Design
-
-## When this skill activates
-Any task involving creating or modifying API endpoints, request/response schemas,
-or API contracts.
-
-## Mandatory actions when this skill is active
-
-### Before writing any code
-1. Define the endpoint contract: method, path, auth requirement.
-2. Define request and response schemas (including error shape).
-
-### During implementation
-- Validate input at the boundary.
-- Use consistent status codes.
-- Add security headers to responses.
-
-### After implementation
-- Document the endpoint in ARCHITECTURE.md.
-- Add or update tests for the new contract.
-
-## REST API standards
-
-### URL conventions
-- Lowercase, hyphen-separated: `/user-profiles` not `/userProfiles`
-- Nouns for resources: `/orders` not `/getOrders`
-- Hierarchy shows relationships: `/users/{id}/orders`
-- Version in path: `/v1/users`
-
-### HTTP method semantics
-- GET: read only, idempotent, no body
-- POST: create, non-idempotent, returns 201 + Location header
-- PUT: full replace, idempotent
-- PATCH: partial update, idempotent
-- DELETE: remove, idempotent, returns 204
-
-### Status codes (use precisely)
-- 200 OK: successful GET, PUT, PATCH
-- 201 Created: successful POST (include Location header)
-- 204 No Content: successful DELETE
-- 400 Bad Request: client validation error (include error details in body)
-- 401 Unauthorized: missing or invalid authentication
-- 403 Forbidden: authenticated but not authorised
-- 404 Not Found: resource does not exist
-- 409 Conflict: state conflict (duplicate, version mismatch)
-- 422 Unprocessable Entity: semantic validation error
-- 429 Too Many Requests: rate limit exceeded (include Retry-After header)
-- 500 Internal Server Error: unexpected server error (never expose internals)
-
-### Error response format (always consistent)
-```json
-{
-  "error": {
-    "code": "VALIDATION_ERROR",
-    "message": "Human-readable description",
-    "details": [
-      { "field": "email", "issue": "must be a valid email address" }
-    ],
-    "requestId": "req_abc123"
-  }
-}
-```
-
-### Request validation
-- Validate at the route handler boundary, not deep in business logic
-- Return all validation errors at once (not one at a time)
-- Validate: type, format, length, range, required fields
-
-### Security headers (add to every response)
-```
-X-Content-Type-Options: nosniff
-X-Frame-Options: DENY
-Strict-Transport-Security: max-age=31536000; includeSubDomains
-Content-Security-Policy: default-src 'self'
-```
-
-## Output
-New endpoints must be documented in ARCHITECTURE.md under the API section
-with: method, path, auth requirement, request schema, response schema, errors.
-
-## Self-check before task completion
-
-Before marking a task done when this skill was active:
-
-- [ ] Did I read the full SKILL.md before starting? (Not just the triggers)
-- [ ] Did I activate the corresponding persona file?
-- [ ] Did I apply every mandatory action in this skill, not just the ones
-  I remembered off the top of my head?
-- [ ] If this skill produced an output file (review, security report, etc.),
-  has that file been written to the correct path?

package/.mindforge/mirrors/mirror-sre-776a1cf9/.mindforge/skills/code-quality/SKILL.md

@@ -1,88 +0,0 @@
----
-name: code-quality
-version: 1.0.0
-min_mindforge_version: 0.1.0
-status: stable
-triggers: refactor, code review, review, quality, tech debt, complexity, clean up, cleanup, lint, linting, code smell, duplication, naming, readability
----
-
-# Skill — Code Quality
-
-## When this skill activates
-Any code review, refactoring task, or implementation where maintaining
-quality standards is the primary goal.
-
-## Mandatory actions when this skill is active
-
-### Before writing any code
-1. Read CONVENTIONS.md and apply all rules.
-2. Identify complexity risks (hot paths, long functions, nested logic).
-3. Decide up front where tests will be added or updated.
-
-### During implementation or review
-- Enforce function length and complexity limits.
-- Remove unused code and dead imports.
-- Replace magic numbers with named constants.
-
-### After implementation or review
-- Run linters and type checks for the project.
-- Record findings or fixes in SUMMARY.md or the review report.
-
-## Quality dimensions to evaluate
-
-### Readability
-- Can a new engineer understand this function in under 2 minutes?
-- Are names precise and unambiguous? (Not `data`, `info`, `temp`, `flag`)
-- Is every non-obvious decision explained with a comment?
-- Are there magic numbers? (Replace with named constants)
-
-### Complexity limits
-- Functions: ≤ 40 lines. If longer, extract sub-functions.
-- Cyclomatic complexity: ≤ 10 per function.
-- Nesting depth: ≤ 3 levels. Extract to separate function if deeper.
-- Parameters: ≤ 4 per function. If more, use an options object.
-
-### Duplication
-- DRY (Don't Repeat Yourself): extract any logic appearing 3+ times.
-- Exception: duplication in tests is acceptable for clarity.
-
-### Error handling
-- Every async operation must have explicit error handling.
-- No empty catch blocks (`catch(e) {}`).
-- No swallowed errors (`catch(e) { return null }`).
-- Errors must be logged with enough context to diagnose.
-
-### Dependencies
-- Before adding any new dependency: check bundle size, CVEs, last commit date,
-  weekly downloads, and licence compatibility.
-- Prefer native platform APIs over dependencies for simple tasks.
-
-## Metrics to check before marking a task done
-Run these and fix any failures:
-```bash
-# TypeScript projects
-npx tsc --noEmit
-npx eslint . --ext .ts,.tsx
-
-# Python projects
-ruff check .
-mypy .
-
-# All projects
-[project test command]
-```
-
-## Output
-If performing a code review: write findings to `.planning/phases/phase-N/CODE-REVIEW-N.md`
-with file, line, severity (blocking / suggestion), and recommended fix.
-
-## Self-check before task completion
-
-Before marking a task done when this skill was active:
-
-- [ ] Did I read the full SKILL.md before starting? (Not just the triggers)
-- [ ] Did I activate the corresponding persona file?
-- [ ] Did I apply every mandatory action in this skill, not just the ones
-  I remembered off the top of my head?
-- [ ] If this skill produced an output file (review, security report, etc.),
-  has that file been written to the correct path?

package/.mindforge/mirrors/mirror-sre-776a1cf9/.mindforge/skills/data-privacy/SKILL.md

@@ -1,126 +0,0 @@
----
-name: data-privacy
-version: 1.0.0
-min_mindforge_version: 0.3.0
-status: stable
-triggers: GDPR, CCPA, privacy, PII, personal data, personal information, consent, data retention, right to erasure, right to access, data portability, data subject, anonymise, anonymize, pseudonymise, pseudonymize, data minimisation, data minimization, lawful basis, cookie, tracking, analytics, marketing, third party, data transfer, cross-border
----
-
-# Skill — Data Privacy Engineering
-
-## When this skill activates
-Any task touching personal data collection, storage, processing, or transfer.
-Also activates for consent management, analytics, cookie handling, and any
-feature where user data flows to third parties.
-These rules are language-agnostic — apply them regardless of framework or stack.
-
-## Regulatory coverage
-This skill covers: GDPR (EU/UK), CCPA/CPRA (California), PIPEDA (Canada),
-PDPA (Thailand/Singapore variants), LGPD (Brazil). Requirements often overlap —
-implementing GDPR correctly satisfies most other frameworks.
-
-## Mandatory actions when this skill is active
-
-### Data audit — before touching any data feature
-Answer these questions before writing code:
-1. **What personal data is collected?** (Name, email, IP, device ID, location, behaviour)
-2. **What is the lawful basis for processing?** (Consent / Contract / Legitimate interest / Legal obligation)
-3. **How long is it retained?** (Must have a defined retention period — not "indefinitely")
-4. **Who does it flow to?** (Internal systems only / third-party processors / international transfer)
-5. **Can users access, export, and delete their data?**
-
-If you cannot answer all 5: stop. Write the answers in ARCHITECTURE.md under
-"Data Privacy" before implementing anything.
-
-### PII handling standards
-
-**Collection:**
-- Collect the minimum data required for the stated purpose (data minimisation)
-- Obtain consent before collecting non-essential data (analytics, marketing)
-- Consent must be: specific, informed, freely given, unambiguous, and withdrawable
-- Withdrawing consent must be as easy as giving it (no dark patterns, no extra steps)
-- Never pre-tick consent checkboxes. Never bundle consent for different purposes.
-
-**Storage:**
-- PII fields in the database must be identified (document in ARCHITECTURE.md)
-- Encrypt sensitive PII at rest: financial data, health data, government IDs
-- Pseudonymisation: where possible, store a user ID reference rather than PII inline
-- Never store PII in: logs, AUDIT.jsonl, git commits, error messages, URL parameters
-
-**Transfer:**
-- Third-party processors: must have a Data Processing Agreement (DPA)
-- International transfer (out of EU): requires Standard Contractual Clauses or adequacy decision
-- Document all third-party data flows in ARCHITECTURE.md
-
-**Retention and deletion:**
-- Define retention period for every PII field in the data model
-- Implement automated deletion or anonymisation when retention period expires
-- Implement "right to erasure": a complete user delete must remove or anonymise ALL their PII
-- Implement "right to access": export of all user data in a portable format (JSON/CSV)
-- Test deletion: verify that deleted user data does not appear in any API response
-
-**Retention examples (defaults, adjust to policy/legal requirements):**
-- Authentication logs: 30–90 days
-- Security/audit logs: 90–365 days
-- Billing records: 6–7 years (jurisdiction dependent)
-- Analytics events: 12–24 months
-Always confirm with legal/compliance for your jurisdiction.
-
-**Erasure vs anonymisation:**
-- Erasure: delete or irreversibly remove identifiers from all systems
-- Anonymisation: permanently remove identifying attributes so data cannot be re-linked
-If anonymisation is used, document the method and verify re-identification risk.
-
-### Cookie and tracking standards
-```javascript
-// Required: granular consent per category
-const consentCategories = {
-  necessary: true,      // Always true — no consent needed
-  functional: false,    // Requires consent
-  analytics: false,     // Requires consent
-  marketing: false,     // Requires consent — highest bar
-};
-
-// Required: record consent with timestamp and version
-await recordConsent({
-  userId: user.id,
-  categories: consentCategories,
-  timestamp: new Date().toISOString(),
-  policyVersion: '2026-01',
-  ipHash: hash(userIp), // Store hash not raw IP for GDPR compliance
-});
-
-// Required: honour opt-out immediately
-// If analytics: false — stop sending analytics events NOW, not on next page load
-```
-
-### Code patterns that are FORBIDDEN under data privacy
-```
-// ❌ NEVER: Log PII
-console.log(`User ${user.email} logged in`) // email in logs = GDPR violation
-logger.info({ user }) // entire user object = PII in logs
-
-// ✅ ALWAYS: Log identifiers, never PII
-logger.info({ userId: user.id, event: 'login' })
-
-// ❌ NEVER: PII in error messages
-throw new Error(`Could not find user ${user.email}`) // exposed in stack traces
-
-// ✅ ALWAYS: identifiers in errors
-throw new Error(`Could not find user [id:${user.id}]`)
-
-// ❌ NEVER: PII in URL parameters
-GET /api/users?email=john@example.com // logged by web servers, CDNs, browsers
-
-// ✅ ALWAYS: POST body or path parameter by ID
-GET /api/users/{id}
-```
-
-## Privacy review checklist
-Before marking any data-related task done:
-- [ ] Lawful basis identified for every data point collected
-- [ ] PII never appears in logs, error messages, or URL parameters
-- [ ] Retention period defined for every new PII field
-- [ ] Third-party data flows documented in ARCHITECTURE.md
-- [ ] User delete removes or anonymises ALL PII ✅ / not yet implemented ⚠️
-- [ ] Consent UI does not use dark patterns (pre-ticked, bundled, misleading)

package/.mindforge/mirrors/mirror-sre-776a1cf9/.mindforge/skills/database-patterns/SKILL.md

@@ -1,192 +0,0 @@
----
-name: database-patterns
-version: 1.0.0
-min_mindforge_version: 0.3.0
-status: stable
-triggers: database, DB, SQL, query, migration, schema, index, indexing, N+1, transaction, ACID, foreign key, join, aggregate, pagination, cursor, connection pool, ORM, Prisma, SQLAlchemy, Drizzle, Sequelize, PostgreSQL, MySQL, SQLite, MongoDB, Redis, Elasticsearch
----
-
-# Skill — Database Patterns
-
-## When this skill activates
-Any task involving database schema design, query writing, migrations, or
-ORM configuration.
-
-## Mandatory actions when this skill is active
-
-### Schema design standards
-
-**Naming conventions (PostgreSQL default):**
-```sql
--- Tables: snake_case, plural
-CREATE TABLE user_profiles (...);
-CREATE TABLE order_items (...);
-
--- Columns: snake_case
-user_id, created_at, updated_at, deleted_at
-
--- Primary keys: always id (UUID preferred over auto-increment)
-id UUID PRIMARY KEY DEFAULT gen_random_uuid()
-
--- Foreign keys: {referenced_table_singular}_id
-user_id UUID REFERENCES users(id) ON DELETE CASCADE
-order_id UUID REFERENCES orders(id) ON DELETE SET NULL
-
--- Indexes: idx_{table}_{column(s)}
-CREATE INDEX idx_users_email ON users(email);
-CREATE INDEX idx_orders_user_id_created_at ON orders(user_id, created_at DESC);
-```
-
-**Standard columns every table should have:**
-```sql
-id          UUID PRIMARY KEY DEFAULT gen_random_uuid(),
-created_at  TIMESTAMPTZ NOT NULL DEFAULT NOW(),
-updated_at  TIMESTAMPTZ NOT NULL DEFAULT NOW(),
--- For soft delete (preferred over hard delete):
-deleted_at  TIMESTAMPTZ  -- NULL = active, timestamp = deleted
-```
-
-**UUID strategy:**
-- Prefer UUIDv7 or ULID for time-ordered inserts (better index locality)
-- Use random UUIDv4 for high-entropy IDs when ordering is not important
-- Document the choice in ARCHITECTURE.md and keep it consistent across tables
-
-**Soft delete implementation:**
-Use soft delete (setting `deleted_at`) instead of hard delete for:
-- User records (GDPR right to erasure exception: anonymise, don't delete)
-- Financial records (audit requirements)
-- Any record that might be referenced by other records
-
-For hard delete: cascade must be configured. Document the cascade in ARCHITECTURE.md.
-
-### Query standards
-
-**N+1 query detection and prevention:**
-```typescript
-// ❌ N+1 pattern: 1 query for users + N queries for their orders
-const users = await db.users.findMany()
-for (const user of users) {
-  user.orders = await db.orders.findMany({ where: { userId: user.id } })
-}
-
-// ✅ Single query with JOIN or include
-const users = await db.users.findMany({
-  include: { orders: true }  // Prisma generates a single JOIN query
-})
-
-// ✅ Or batch load with WHERE IN
-const userIds = users.map(u => u.id)
-const orders = await db.orders.findMany({ where: { userId: { in: userIds } } })
-const ordersByUser = groupBy(orders, 'userId')
-```
-
-**Framework-agnostic SQL example (N+1):**
-```sql
--- ❌ N+1 pattern (application loops)
--- SELECT * FROM users LIMIT 50;
--- then for each user:
--- SELECT * FROM orders WHERE user_id = ?;
-
--- ✅ Single query with JOIN
-SELECT u.*, o.*
-FROM users u
-LEFT JOIN orders o ON o.user_id = u.id
-WHERE u.id IN (:user_ids);
-```
-
-**Pagination patterns:**
-```typescript
-// ❌ OFFSET pagination (slow on large datasets — scans all previous rows)
-SELECT * FROM posts ORDER BY created_at DESC LIMIT 20 OFFSET 10000;
-
-// ✅ Compound cursor — handles duplicate timestamps correctly
-// Application layer: encode (created_at, id) as the cursor
-SELECT * FROM posts
-WHERE (created_at, id) < (:cursor_time::timestamptz, :cursor_id::uuid)
-ORDER BY created_at DESC, id DESC
-LIMIT 20;
-
-// Cursor encoding (application layer):
-// encode: btoa(JSON.stringify({ t: row.created_at, id: row.id }))
-// decode: JSON.parse(atob(cursor))
-// Return:
-{
-  "data": [...],
-  "nextCursor": "[base64 of {t, id} pair]",
-  "hasMore": true
-}
-```
-
-### Why compound cursors matter
-Single-field cursors (created_at only) produce incorrect pagination when
-multiple records share the same timestamp — common in batch imports and
-high-write systems. Always use at least (timestamp, id) as a compound cursor.
-
-For simple cases where records are created sequentially and timestamps are
-guaranteed unique (e.g., a single-writer queue): a single-field cursor is acceptable.
-Document this assumption in the code.
-
-**Transaction usage:**
-```typescript
-// Use transactions whenever multiple writes must succeed or fail together
-await db.$transaction(async (tx) => {
-  const order = await tx.orders.create({ data: orderData })
-  await tx.orderItems.createMany({ data: items.map(i => ({...i, orderId: order.id})) })
-  await tx.inventory.updateMany({ /* deduct stock */ })
-  // All three succeed or all three roll back
-})
-```
-For financial operations or ledger updates, use `SERIALIZABLE` isolation or
-explicit row-level locks to prevent lost updates and double-spend conditions.
-
-### Index strategy
-
-**Always index:**
-- All foreign key columns (ORM does not always do this automatically)
-- Columns used in WHERE clauses on large tables
-- Columns used in ORDER BY on large tables
-- Columns used in JOIN conditions
-
-**Composite indexes:**
-- Order columns from most selective (highest cardinality) to least
-- A composite index on (a, b) is used for queries filtering on a alone,
-  or on both a and b. Not for b alone.
-- Example: index on (user_id, created_at DESC) for "get user's recent items"
-
-**Never index:**
-- Boolean columns on large tables (index selectivity too low to help)
-- Columns that change very frequently (index maintenance overhead)
-- Tables with fewer than 10,000 rows (full scan is faster)
-
-### Migration standards
-
-```bash
-# Every schema change must have a migration file
-# Naming: [timestamp]_[descriptive-name].sql or per ORM convention
-
-# Migration must be:
-# 1. Idempotent: safe to run multiple times
-# 2. Reversible: has both UP and DOWN migration
-# 3. Non-blocking: avoid full table locks in production migrations
-
-# Non-blocking pattern for adding a column (PostgreSQL):
-# Step 1: Add column with default as NULL (instant)
-ALTER TABLE users ADD COLUMN phone_verified BOOLEAN;
-
-# Step 2: Backfill in batches (separate deployment)
-UPDATE users SET phone_verified = false
-WHERE id IN (SELECT id FROM users WHERE phone_verified IS NULL LIMIT 1000);
-
-# Step 3: Add NOT NULL constraint + default (after backfill completes)
-ALTER TABLE users ALTER COLUMN phone_verified SET NOT NULL;
-ALTER TABLE users ALTER COLUMN phone_verified SET DEFAULT false;
-```
-
-## Query performance checklist
-Before committing any query-writing task:
-- [ ] Ran EXPLAIN ANALYZE on all non-trivial queries
-- [ ] All WHERE/JOIN/ORDER BY columns have indexes
-- [ ] No N+1 queries in list-fetching code
-- [ ] Large queries paginated (cursor-based for > 1K rows)
-- [ ] Transactions used for multi-write operations
-- [ ] Connection pooling configured (not creating connections per request)