@jmruthers/pace-core 0.6.9 → 0.6.11

package/docs/standards/6-security-rbac-standards.md

@@ -2,12 +2,36 @@
 
 **🤖 Cursor Rule**: See [06-security-rbac.mdc](../../cursor-rules/06-security-rbac.mdc) for AI-optimized directives that automatically enforce RBAC contract compliance (ESLint-enforced).
 
+**🔧 ESLint Rules**: See [06-security-rbac.cjs](../../eslint-rules/rules/06-security-rbac.cjs) for mechanically checkable security and RBAC rules.
+
 ## Purpose
 
 Define standards for Row-Level Security (RLS) policies and Role-Based Access Control (RBAC) integration to ensure security, performance, and maintainability.
 
 **Note:** General performance optimization patterns (React, caching, bundle size) are covered in [Operations Standards](./9-operations-standards.md). This document focuses on RLS-specific performance requirements.
 
+---
+
+## How each layer enforces this standard
+
+- **Standards (this doc):** Source of truth; defines RLS policy patterns, helper function requirements (STABLE, SECURITY DEFINER, SET search_path), forbidden/required patterns, Edge Function RBAC (isPermitted/setupRBAC), and security baseline.
+- **Cursor rule:** `06-security-rbac.mdc` — AI guidance when editing `src/**/*.{ts,tsx,js,jsx}` and `supabase/migrations/**/*.sql`; points to this doc and RBAC contract.
+- **ESLint:** Rules in `06-security-rbac.cjs` (plugin prefix `pace-core-compliance/`): see ESLint Rules section below. Run via lint step in CI and locally.
+- **Audit tool:** Standard 6 audit runs as part of `npm run validate`; checks RLS policies in SQL migrations (naming, inline auth, subqueries, helper attributes, SECURITY DEFINER/search_path/schema-qualify/COMMENT), PagePermissionGuard coverage, and Edge Functions RBAC (setupRBAC before isPermitted). Report: `audit/<timestamp>-pace-core-audit.md`. For pace-core development, run `npm run validate` from the repository root.
+
+---
+
+## Audit issue types and where to read
+
+| Audit issue type | See section in this doc |
+|------------------|--------------------------|
+| rlsPolicy | RLS Policy Performance Requirements; Helper Function Requirements; Forbidden/Required Patterns; SECURITY DEFINER Requirements; Security Risks & Mitigations; Policy Naming Convention; RLS Policy Patterns |
+| rbacPageGuard | Security Baseline (page protection) |
+| organisationIdResolution | Organisation context resolution (consuming apps) |
+| edgeFunctionRBAC | Edge Functions and Serverless Functions |
+
+---
+
 ## Principles
 
 - **Performance First**: All RLS policies must use optimized helper functions
@@ -24,8 +48,8 @@ All helper functions used in RLS policies **MUST** have these attributes:
 | Requirement | Why | Example |
 |------------|-----|---------|
 | `STABLE` | Prevents re-evaluation for each row | `STABLE` |
-| `SECURITY DEFINER` | Bypass RLS to avoid recursion | `SECURITY DEFINER` |
-| `SET search_path TO 'public'` | Prevent search path injection | `SET search_path TO 'public'` |
+| `SECURITY DEFINER` | Bypass RLS to avoid circular dependencies when querying RLS-protected tables | `SECURITY DEFINER` |
+| `SET search_path TO 'public'` | **MANDATORY** - Prevents search path hijacking attacks | `SET search_path TO public` |
 | No inline `auth.uid()` | Causes InitPlan nodes, severe performance degradation | Use helper function instead |
 
 ### Helper Function Template
@@ -34,19 +58,31 @@ All helper functions used in RLS policies **MUST** have these attributes:
 CREATE OR REPLACE FUNCTION function_name(parameters)
 RETURNS return_type
 LANGUAGE plpgsql
-STABLE                    -- ✅ Required
-SECURITY DEFINER          -- ✅ Required
-SET search_path TO public -- ✅ Required
+STABLE                    -- ✅ Required for performance
+SECURITY DEFINER          -- ✅ Required if querying RLS-protected tables
+SET search_path TO public -- ✅ MANDATORY - Prevents search path hijacking
 AS $$
 DECLARE
   -- Declarations
 BEGIN
   -- Function body
+  -- Always schema-qualify table/function references (e.g., public.table_name)
   RETURN result;
 END;
 $$;
+
+-- ✅ Document why SECURITY DEFINER is needed
+COMMENT ON FUNCTION function_name(parameters) IS 
+  'Purpose description. SECURITY DEFINER required because this function queries rbac_organisation_roles which has RLS policies. STABLE for RLS policy performance.';
 ```
 
+**Security Checklist:**
+- [ ] `SET search_path TO public` is present (MANDATORY)
+- [ ] All table/function references are schema-qualified (e.g., `public.table_name`)
+- [ ] Function is marked `STABLE` or `IMMUTABLE` when possible
+- [ ] Function ownership uses least-privilege role (not superuser unless necessary)
+- [ ] COMMENT documents why SECURITY DEFINER is needed
+
 ### Forbidden Patterns
 
 **❌ NEVER use these patterns in RLS policies:**
@@ -99,6 +135,206 @@ FOR SELECT USING (
 );
 ```
 
+## SECURITY DEFINER Requirements & Security
+
+### When SECURITY DEFINER is Necessary
+
+**SECURITY DEFINER is REQUIRED when:**
+- Helper function queries tables with RLS policies (e.g., `rbac_organisation_roles`, `rbac_global_roles`)
+- Function needs to bypass RLS to avoid circular dependencies
+- Function performs administrative operations requiring elevated privileges
+
+**Why it's needed:**
+When an RLS policy calls a helper function that queries RLS-protected tables, without SECURITY DEFINER:
+1. RLS policy calls helper function
+2. Helper function queries RLS-protected table (e.g., `rbac_organisation_roles`)
+3. That query triggers RLS again → infinite recursion or circular dependency
+
+**Example:**
+```sql
+-- ✅ CORRECT: SECURITY DEFINER required because function queries rbac_organisation_roles
+CREATE OR REPLACE FUNCTION check_user_organisation_access(p_organisation_id UUID)
+RETURNS boolean
+LANGUAGE plpgsql
+STABLE
+SECURITY DEFINER          -- ✅ Required: queries rbac_organisation_roles (has RLS)
+SET search_path TO public -- ✅ MANDATORY: prevents search path hijacking
+AS $$
+BEGIN
+  -- This queries rbac_organisation_roles which has RLS policies
+  -- Without SECURITY DEFINER, this would trigger RLS again → circular dependency
+  RETURN EXISTS (
+    SELECT 1 FROM public.rbac_organisation_roles  -- ✅ Schema-qualified
+    WHERE user_id = auth.uid()
+    AND organisation_id = p_organisation_id
+  );
+END;
+$$;
+```
+
+**SECURITY DEFINER is NOT necessary when:**
+- Function only performs pure computation (no table queries)
+- Function only queries tables without RLS policies
+- Function doesn't need to bypass RLS
+
+**Example:**
+```sql
+-- ✅ CORRECT: No SECURITY DEFINER needed (pure computation, no RLS-protected queries)
+CREATE OR REPLACE FUNCTION calculate_total(p_amount NUMERIC, p_tax_rate NUMERIC)
+RETURNS NUMERIC
+LANGUAGE plpgsql
+STABLE  -- ✅ STABLE for performance, but no SECURITY DEFINER needed
+AS $$
+BEGIN
+  RETURN p_amount * (1 + p_tax_rate);
+END;
+$$;
+```
+
+### Security Risks & Mitigations
+
+**Security Risks:**
+1. **Search path hijacking** - If `search_path` includes untrusted schemas, malicious objects could be called
+2. **Privilege escalation** - Functions run with owner's privileges, not caller's
+3. **Unqualified object references** - Could resolve to objects in wrong schemas
+4. **Performance implications** - Can affect query optimization
+
+**Required Mitigations (MANDATORY):**
+
+| Mitigation | Requirement | Why |
+|------------|-------------|-----|
+| `SET search_path TO public` | **MANDATORY** | Prevents search path hijacking attacks |
+| Schema-qualify references | **MANDATORY** | Ensures objects resolve to correct schemas |
+| `STABLE` or `IMMUTABLE` | **REQUIRED** | Helps with query optimization and performance |
+| Least-privilege ownership | **RECOMMENDED** | Functions should be owned by appropriate roles (not superuser unless necessary) |
+| Document rationale | **REQUIRED** | COMMENT must explain why SECURITY DEFINER is needed |
+
+**Example with all mitigations:**
+```sql
+-- ✅ CORRECT: All security mitigations in place
+CREATE OR REPLACE FUNCTION check_user_organisation_access(p_organisation_id UUID)
+RETURNS boolean
+LANGUAGE plpgsql
+STABLE                    -- ✅ Performance optimization
+SECURITY DEFINER          -- ✅ Required: queries RLS-protected tables
+SET search_path TO public -- ✅ MANDATORY: prevents search path hijacking
+AS $$
+BEGIN
+  -- ✅ Schema-qualified references
+  RETURN EXISTS (
+    SELECT 1 FROM public.rbac_organisation_roles
+    WHERE user_id = auth.uid()
+    AND organisation_id = p_organisation_id
+  );
+END;
+$$;
+
+-- ✅ Document why SECURITY DEFINER is needed
+COMMENT ON FUNCTION check_user_organisation_access(UUID) IS 
+  'Checks if current user has access to organisation. SECURITY DEFINER required because function queries public.rbac_organisation_roles which has RLS policies. Without SECURITY DEFINER, this would create circular RLS dependency. STABLE for RLS policy performance. SET search_path TO public prevents search path hijacking.';
+```
+
+### Decision Tree: When to Use SECURITY DEFINER
+
+```
+1. Does this helper function query tables with RLS policies?
+   ├─ YES → SECURITY DEFINER required (to avoid circular RLS)
+   │         └─ Continue to step 3
+   └─ NO → Continue to step 2
+
+2. Does this function need elevated privileges for administrative operations?
+   ├─ YES → SECURITY DEFINER may be appropriate (document why)
+   │         └─ Continue to step 3
+   └─ NO → SECURITY DEFINER not needed
+            └─ Use STABLE or IMMUTABLE only
+
+3. If using SECURITY DEFINER, verify all security requirements:
+   ├─ SET search_path TO public (or specific schema list) ✅ MANDATORY
+   ├─ Schema-qualify all table/function references ✅ MANDATORY
+   ├─ Use STABLE/IMMUTABLE when possible ✅ REQUIRED
+   ├─ Owned by appropriate role (not superuser unless needed) ✅ RECOMMENDED
+   └─ Document why SECURITY DEFINER is needed in COMMENT ✅ REQUIRED
+```
+
+### Security Anti-Patterns
+
+**❌ NEVER use these patterns:**
+
+```sql
+-- ❌ BAD: Missing SET search_path (security risk)
+CREATE OR REPLACE FUNCTION bad_function()
+RETURNS boolean
+LANGUAGE plpgsql
+STABLE
+SECURITY DEFINER  -- Missing SET search_path TO public!
+AS $$
+BEGIN
+  RETURN EXISTS (SELECT 1 FROM rbac_organisation_roles);  -- Unqualified reference
+END;
+$$;
+
+-- ❌ BAD: Unqualified table reference (security risk)
+CREATE OR REPLACE FUNCTION bad_function()
+RETURNS boolean
+LANGUAGE plpgsql
+STABLE
+SECURITY DEFINER
+SET search_path TO public
+AS $$
+BEGIN
+  RETURN EXISTS (SELECT 1 FROM rbac_organisation_roles);  -- Should be public.rbac_organisation_roles
+END;
+$$;
+
+-- ❌ BAD: SECURITY DEFINER without justification
+CREATE OR REPLACE FUNCTION pure_computation(x NUMERIC)
+RETURNS NUMERIC
+LANGUAGE plpgsql
+STABLE
+SECURITY DEFINER  -- Not needed! Function doesn't query RLS-protected tables
+AS $$
+BEGIN
+  RETURN x * 2;  -- Pure computation, no table queries
+END;
+$$;
+```
+
+**✅ CORRECT patterns:**
+
+```sql
+-- ✅ GOOD: All security requirements met
+CREATE OR REPLACE FUNCTION check_user_organisation_access(p_organisation_id UUID)
+RETURNS boolean
+LANGUAGE plpgsql
+STABLE
+SECURITY DEFINER          -- ✅ Required: queries RLS-protected tables
+SET search_path TO public -- ✅ MANDATORY: prevents search path hijacking
+AS $$
+BEGIN
+  -- ✅ Schema-qualified reference
+  RETURN EXISTS (
+    SELECT 1 FROM public.rbac_organisation_roles
+    WHERE user_id = auth.uid()
+    AND organisation_id = p_organisation_id
+  );
+END;
+$$;
+
+COMMENT ON FUNCTION check_user_organisation_access(UUID) IS 
+  'SECURITY DEFINER required: queries public.rbac_organisation_roles (has RLS). Without it, circular RLS dependency would occur.';
+
+-- ✅ GOOD: No SECURITY DEFINER needed (pure computation)
+CREATE OR REPLACE FUNCTION calculate_total(p_amount NUMERIC, p_tax_rate NUMERIC)
+RETURNS NUMERIC
+LANGUAGE plpgsql
+STABLE  -- ✅ STABLE for performance, but no SECURITY DEFINER needed
+AS $$
+BEGIN
+  RETURN p_amount * (1 + p_tax_rate);  -- No table queries
+END;
+$$;
+```
+
 ## Helper Selection Quick Guide
 
 | Scenario | Helper(s) to use | Notes |
@@ -112,10 +348,11 @@ FOR SELECT USING (
 
 ## RLS Helper Requirements (enforced)
 
-- Helper functions **must** be `STABLE`, `SECURITY DEFINER`, and `SET search_path TO public`.
+- Helper functions **must** be `STABLE`, `SECURITY DEFINER` (when querying RLS-protected tables), and `SET search_path TO public` (MANDATORY for SECURITY DEFINER functions).
 - **Never** inline `auth.uid()`, `auth.role()`, or `current_setting()` inside policies.
 - Use `get_app_id()` for app UUIDs (do not hardcode UUIDs or call legacy getters).
 - Avoid subqueries inside policies; move lookups into helpers.
+- **Security**: All SECURITY DEFINER functions must schema-qualify table/function references and document why SECURITY DEFINER is needed.
 
 ## Standard Helper Functions
 
@@ -818,6 +1055,7 @@ export async function checkPermission(userId: string, permission: string) {
 - Use safe, user-friendly error messaging.
 - Prefer pace-core security helpers and secure clients (`useSecureSupabase`, RBAC helpers) over custom implementations.
 - Monitor RLS performance (avoid subqueries/InitPlan); keep helpers `STABLE SECURITY DEFINER` with `SET search_path TO public`.
+- **SECURITY DEFINER functions**: Must schema-qualify all references, use `SET search_path TO public`, and document why SECURITY DEFINER is needed.
 - **Edge Functions MUST use pace-core `isPermitted()` API - no exceptions allowed.**
 
 ### Common Pitfalls to Avoid
@@ -858,6 +1096,33 @@ USING (organisation_id = get_organisation_context())
 USING (is_public = true AND organisation_id IS NOT NULL)
 ```
 
+## Organisation context resolution (consuming apps)
+
+When a consuming app uses both **selectedOrganisation** (from `useOrganisations()`) and **selectedEvent** (from `useEvents()`), any code that passes organisation context to RPCs or payloads (**p_organisation_id**, **organisation_id**, **selectedOrganisationId**) **MUST** use a **derived organisation ID** that falls back to the event’s organisation when the context selector has no org selected.
+
+**Why:** If the user has selected an event but no organisation in the header, `selectedOrganisation` may be null while `selectedEvent.organisation_id` is set. Passing only `selectedOrganisation?.id` to RPCs then sends `undefined`, breaking data isolation or causing incorrect behaviour.
+
+**✅ CORRECT – derived organisationId:**
+```ts
+const organisationId = useMemo(
+  () =>
+    selectedOrganisation?.id ??
+    (selectedEvent as { organisation_id?: string | null } | undefined)?.organisation_id ??
+    undefined,
+  [selectedOrganisation?.id, selectedEvent]
+);
+// Use organisationId for all p_organisation_id, organisation_id, selectedOrganisationId
+```
+
+**❌ WRONG – using selectedOrganisation?.id when selectedEvent is in scope:**
+```ts
+p_organisation_id: selectedOrganisation?.id,  // undefined when event selected without org
+organisation_id: selectedOrganisation?.id || '',
+selectedOrganisationId: selectedOrganisation?.id,
+```
+
+**Enforcement:** The Standard 6 audit and the ESLint rule `require-derived-organisation-id` flag files that use both `selectedOrganisation` and `selectedEvent` but pass `selectedOrganisation?.id` (or `selectedOrganisation.id`) to organisation context parameters. Fix by deriving `organisationId` as above and using it consistently.
+
 ## App Ownership
 
 Tables are assigned to specific apps for RBAC permission checking:
@@ -902,7 +1167,8 @@ Tables are assigned to specific apps for RBAC permission checking:
 - [ ] Policy coverage: All tables (except mint_*) have RLS enabled and policies
 - [ ] Performance: Queries complete in < 1 second
 - [ ] Security: Cross-organisation access is blocked
-- [ ] Helper functions: All are STABLE SECURITY DEFINER
+- [ ] Helper functions: All are STABLE, SECURITY DEFINER (when needed), with `SET search_path TO public`
+- [ ] Security: All SECURITY DEFINER functions schema-qualify references and document rationale
 
 ## Maintenance
 
@@ -969,6 +1235,21 @@ date +"%Y%m%d%H%M%S"
 3. **Monitor performance** after deployment
 4. **Rollback plan** ready if issues occur
 
+## ESLint Rules
+
+Rule IDs use the plugin prefix **`pace-core-compliance/`**. The following rules enforce security and RBAC standards:
+
+- **`pace-core-compliance/no-direct-supabase-client`** — Require useSecureSupabase from pace-core/rbac; disallow direct createClient from @supabase/supabase-js.
+- **`pace-core-compliance/rbac-permission-loading`** — Enforce loading state handling when using RBAC permission hooks.
+- **`pace-core-compliance/no-direct-rbac-rpc`** — Disallow direct RPC calls to rbac_*; use pace-core RBAC hooks/APIs.
+- **`pace-core-compliance/no-direct-rbac-table`** — Disallow direct queries to RBAC tables; use pace-core APIs.
+- **`pace-core-compliance/no-hardcoded-role-checks`** — Disallow hardcoded role checks; use useAccessLevel/getRoleContext from pace-core/rbac.
+- **`pace-core-compliance/rbac-use-resource-names-constants`** — Require RESOURCE_NAMES constants instead of string literals in useResourcePermissions.
+- **`pace-core-compliance/no-rbac-wrapper-components`** — Disallow wrapper components around pace-core RBAC components.
+- **`pace-core-compliance/no-rbac-wrapper-functions`** — Disallow wrapper functions around pace-core RBAC hooks.
+
+These rules are part of the `pace-core-compliance` plugin and are enabled when extending `@jmruthers/pace-core/eslint-config`.
+
 ## Related Documentation
 
 - [Standards Overview](./0-standards-overview.md) - Standards system overview

package/docs/standards/7-api-tech-stack-standards.md

@@ -10,6 +10,25 @@ This standard defines the required technology stack, API design patterns, and RP
 
 ---
 
+## How each layer enforces this standard
+
+- **Standards (this doc):** Source of truth; defines required tech stack (React 19+, TypeScript, Vite, Tailwind v4, Supabase, TanStack Query, etc.), API/RPC naming (`data_*` / `app_*`), ApiResult shape, RPC rules, Vite/TypeScript config, and deprecation policy.
+- **Cursor rule:** `07-api-tech-stack.mdc` — AI guidance when editing `src/**`, config files, and `supabase/migrations/**/*.sql`; points to this doc.
+- **ESLint:** Rules in `07-api-tech-stack.cjs` (plugin prefix `pace-core-compliance/`): see ESLint Rules section below. Run via lint step in CI and locally.
+- **Audit tool:** Standard 7 audit runs as part of `npm run validate`; checks RPC naming in SQL migrations, tech stack versions (package.json), and Vite configuration (optimizeDeps.exclude, resolve.dedupe). Report: `audit/<timestamp>-pace-core-audit.md`. For pace-core development, run `npm run validate` from the repository root.
+
+---
+
+## Audit issue types and where to read
+
+| Audit issue type | See section in this doc |
+|------------------|--------------------------|
+| rpcNaming | API & RPC Naming Conventions; RPC Naming Pattern; Naming Rules |
+| techStack | Required Tech Stack; Version Requirements |
+| viteConfig | Tech Stack Configuration (Vite Configuration) |
+
+---
+
 ## Required Tech Stack
 
 ### Core Technologies
@@ -322,8 +341,8 @@ CREATE OR REPLACE FUNCTION data_events_list(p_organisation_id UUID)
 RETURNS TABLE (...)
 LANGUAGE plpgsql
 STABLE
-SECURITY DEFINER
-SET search_path TO public
+SECURITY DEFINER          -- ✅ Required: queries RLS-protected tables or needs elevated privileges
+SET search_path TO public -- ✅ MANDATORY: prevents search path hijacking
 AS $$
 BEGIN
   -- Check organisation access
@@ -331,11 +350,99 @@ BEGIN
     RAISE EXCEPTION 'Access denied';
   END IF;
   
+  -- ✅ Schema-qualified reference
   RETURN QUERY
-  SELECT * FROM events
+  SELECT * FROM public.events
   WHERE organisation_id = p_organisation_id;
 END;
 $$;
+
+-- ✅ Document why SECURITY DEFINER is needed
+COMMENT ON FUNCTION data_events_list(UUID) IS 
+  'Lists events for an organisation. SECURITY DEFINER required because function queries RLS-protected tables via check_user_organisation_access(). STABLE for read operation performance. SET search_path TO public prevents search path hijacking.';
+```
+
+### SECURITY DEFINER Security Requirements for RPC Functions
+
+**RPC functions that use SECURITY DEFINER MUST follow these security requirements:**
+
+| Requirement | Why | Example |
+|------------|-----|---------|
+| `SET search_path TO public` | **MANDATORY** - Prevents search path hijacking attacks | `SET search_path TO public` |
+| Schema-qualify references | **MANDATORY** - Ensures objects resolve to correct schemas | `public.events` not `events` |
+| `STABLE` for read operations | **REQUIRED** - Helps with query optimization | `STABLE` |
+| Document rationale | **REQUIRED** - COMMENT must explain why SECURITY DEFINER is needed | See COMMENT example above |
+| Least-privilege ownership | **RECOMMENDED** - Functions should be owned by appropriate roles | Not superuser unless necessary |
+
+**When SECURITY DEFINER is needed for RPC functions:**
+- Function queries RLS-protected tables (e.g., `rbac_organisation_roles`, `rbac_global_roles`)
+- Function needs to bypass RLS to avoid circular dependencies
+- Function performs administrative operations requiring elevated privileges
+
+**Security Checklist for RPC Functions with SECURITY DEFINER:**
+- [ ] `SET search_path TO public` is present (MANDATORY)
+- [ ] All table/function references are schema-qualified (e.g., `public.table_name`)
+- [ ] Function is marked `STABLE` for read operations
+- [ ] Function ownership uses least-privilege role (not superuser unless necessary)
+- [ ] COMMENT documents why SECURITY DEFINER is needed
+
+**Example with all security requirements:**
+
+```sql
+-- ✅ CORRECT: All security requirements met
+CREATE OR REPLACE FUNCTION data_events_list(p_organisation_id UUID)
+RETURNS TABLE (id UUID, name TEXT, date TIMESTAMPTZ)
+LANGUAGE plpgsql
+STABLE                    -- ✅ Performance optimization
+SECURITY DEFINER          -- ✅ Required: queries RLS-protected tables
+SET search_path TO public -- ✅ MANDATORY: prevents search path hijacking
+AS $$
+BEGIN
+  -- ✅ Schema-qualified reference
+  IF NOT public.check_user_organisation_access(p_organisation_id) THEN
+    RAISE EXCEPTION 'Access denied';
+  END IF;
+  
+  -- ✅ Schema-qualified reference
+  RETURN QUERY
+  SELECT e.id, e.name, e.date
+  FROM public.events e
+  WHERE e.organisation_id = p_organisation_id;
+END;
+$$;
+
+-- ✅ Document why SECURITY DEFINER is needed
+COMMENT ON FUNCTION data_events_list(UUID) IS 
+  'Lists events for an organisation. SECURITY DEFINER required because function queries public.rbac_organisation_roles (via check_user_organisation_access) which has RLS policies. Without SECURITY DEFINER, this would create circular RLS dependency. STABLE for read operation performance. SET search_path TO public prevents search path hijacking.';
+```
+
+**Security Anti-Patterns:**
+
+```sql
+-- ❌ BAD: Missing SET search_path (security risk)
+CREATE OR REPLACE FUNCTION bad_rpc()
+RETURNS TABLE (...)
+LANGUAGE plpgsql
+STABLE
+SECURITY DEFINER  -- Missing SET search_path TO public!
+AS $$
+BEGIN
+  RETURN QUERY SELECT * FROM events;
+END;
+$$;
+
+-- ❌ BAD: Unqualified reference (security risk)
+CREATE OR REPLACE FUNCTION bad_rpc()
+RETURNS TABLE (...)
+LANGUAGE plpgsql
+STABLE
+SECURITY DEFINER
+SET search_path TO public
+AS $$
+BEGIN
+  RETURN QUERY SELECT * FROM events;  -- Should be public.events
+END;
+$$;
 ```
 
 **Real-World Example: Complex RPC with Multiple Security Checks**
@@ -629,23 +736,15 @@ Before creating or updating an API/RPC, verify:
 
 ## ESLint Rules
 
-The following ESLint rules enforce API and tech stack standards:
-
-### RPC Naming
-
-- **`rpc-naming-pattern`** - Enforces `data_*` prefix for read operations and `app_*` prefix for write operations
-
-### React 19+ Patterns
-
-- **`no-class-components`** - Disallows React class components (functional components only)
-
-### Environment Variables
+Rule IDs use the plugin prefix **`pace-core-compliance/`**. The following rules enforce API and tech stack standards:
 
-- **`prefer-import-meta-env`** - Enforces `import.meta.env` (Vite) instead of `process.env` in client code
+- **`pace-core-compliance/rpc-naming-pattern`** — Enforces `data_*` prefix for read operations and `app_*` prefix for write operations.
+- **`pace-core-compliance/no-class-components`** — Disallows React class components (functional components only).
+- **`pace-core-compliance/prefer-import-meta-env`** — Enforces `import.meta.env` (Vite) instead of `process.env` in client code.
 
-These rules are part of the `pace-core-compliance` plugin and are automatically enabled when you extend `@jmruthers/pace-core/eslint-config`.
+These rules are part of the `pace-core-compliance` plugin and are enabled when extending `@jmruthers/pace-core/eslint-config`.
 
-**Setup**: Run `node node_modules/@jmruthers/pace-core/scripts/install-eslint-config.cjs` to configure ESLint in your consuming app.
+**Setup**: Run `npm run setup` to configure ESLint (and other pace-core tools) in your consuming app.
 
 ## Related Documentation
 

package/docs/standards/8-testing-documentation-standards.md

@@ -2,12 +2,33 @@
 
 **🤖 Cursor Rule**: See [08-testing-documentation.mdc](../../cursor-rules/08-testing-documentation.mdc) for AI-optimized directives that automatically enforce testing and documentation standards.
 
+**🔧 ESLint Rules**: See [08-testing.cjs](../../eslint-rules/rules/08-testing.cjs) for mechanically checkable testing rules.
+
 ## Purpose
 
 This standard defines testing strategies, documentation requirements, and issue reporting templates to ensure consistent quality, maintainability, and effective communication across pace-core and consuming apps.
 
 ---
 
+## How each layer enforces this standard
+
+- **Standards (this doc):** Source of truth; defines testing strategy (unit/integration/E2E), test structure and naming, testing tools (React Testing Library, userEvent, Vitest), test timeouts, coverage requirements, documentation requirements, and bug/feature request templates.
+- **Cursor rule:** `08-testing-documentation.mdc` — AI guidance when editing test files (`**/*.{test,spec}.{ts,tsx}`) and docs (`**/*.md`, `**/*.mdx`); points to this doc.
+- **ESLint:** Rules in `08-testing.cjs` (plugin prefix `pace-core-compliance/`): see ESLint Rules section below. Run via lint step in CI and locally.
+- **Audit tool:** Standard 8 audit runs as part of `npm run validate`; checks test timeout configuration (vitest.config, package.json scripts), required testing tools (vitest, @testing-library/react, @testing-library/user-event), and test file structure/naming (.test vs .spec). Report: `audit/<timestamp>-pace-core-audit.md`. For pace-core development, run `npm run validate` from the repository root.
+
+---
+
+## Audit issue types and where to read
+
+| Audit issue type | See section in this doc |
+|------------------|--------------------------|
+| testTimeout | Test Timeouts |
+| testingTools | Testing Tools |
+| testStructure | Test Structure; Test File Naming |
+
+---
+
 ## Testing Strategy
 
 ### Test Types
@@ -388,6 +409,16 @@ Before committing code with documentation, verify:
 
 ---
 
+## ESLint Rules
+
+Rule IDs use the plugin prefix **`pace-core-compliance/`**. The following rule enforces testing standards:
+
+- **`pace-core-compliance/test-file-naming`** — Enforce test file naming: `*.test.ts` or `*.test.tsx` (not `*.spec.ts`).
+
+This rule is part of the `pace-core-compliance` plugin and is enabled when extending `@jmruthers/pace-core/eslint-config`.
+
+---
+
 ## Related Documentation
 
 - [Standards Overview](./0-standards-overview.md) - Standards system overview

package/docs/standards/9-operations-standards.md

@@ -10,6 +10,25 @@ This standard defines error handling patterns, performance optimization strategi
 
 ---
 
+## How each layer enforces this standard
+
+- **Standards (this doc):** Source of truth; defines error handling patterns (ApiResult, type guards, user-facing vs logging messages), performance optimization (memoization, code splitting, caching), and CI/CD integration (pipeline stages, required checks, package.json scripts).
+- **Cursor rule:** `09-operations.mdc` — AI guidance when editing `src/**`, config files, and `.github/workflows/**`; points to this doc.
+- **ESLint:** No dedicated Standard 9 rules; error handling and performance patterns are encouraged via the Cursor rule and via overlapping [Code Quality](./4-code-quality-standards.md) / [API & Tech Stack](./7-api-tech-stack-standards.md) rules. Run `npm run lint` as part of CI.
+- **Audit tool:** Standard 9 audit runs as part of `npm run validate`; checks error handling patterns (ApiResult usage), CI/CD configuration (.github/workflows), and error boundary usage. Report: `audit/<timestamp>-pace-core-audit.md`. For pace-core development, run `npm run validate` from the repository root.
+
+---
+
+## Audit issue types and where to read
+
+| Audit issue type | See section in this doc |
+|------------------|--------------------------|
+| errorHandling | Error Handling Patterns; Result Types; API Errors |
+| cicd | CI/CD Integration; Required CI Checks |
+| errorBoundary | Error Handling Patterns (Pattern 3: Error Boundaries) |
+
+---
+
 ## Error Handling Patterns
 
 ### Principles