@rigstate/mcp 0.4.2 → 0.4.4

package/.agent/skills/client-side-notification-logger/SKILL.md

@@ -0,0 +1,139 @@
+---
+name: client-side-notification-logger
+description: Provides a client-side logging utility that combines toast notifications with console logging for enhanced observability.
+version: "1.0.0"
+specialist: Sven
+governance: OPEN
+---
+
+# Client-Side Notification Logger
+
+This skill provides a reusable client-side logging utility that combines user-friendly toast notifications with detailed console logging. This approach enhances observability by providing immediate feedback to the user through toasts while retaining detailed logs for debugging.
+
+## How to Implement
+
+1.  **Install a Toast Notification Library:**
+
+    Install a library like `sonner` for displaying toast notifications.
+
+    ```bash
+    npm install sonner
+    # or
+    yarn add sonner
+    # or
+    pnpm add sonner
+    ```
+
+2.  **Create the Logging Utility:**
+
+    Create a client component (e.g., `use-notification-logger.tsx`) that exports a `useNotificationLogger` hook. This hook should:
+
+    *   Accept an optional `logLevel` parameter (e.g., 'info', 'warn', 'error', 'debug') and a `toastOptions` object for configuring the toast.
+    *   Return a `log` function that accepts a message string as input.
+    *   The `log` function should:
+        *   Display the message as a toast notification using the chosen library (e.g., `sonner`), configurable via `toastOptions`.
+        *   Log the message to the console using `console.log`, but only if the `logLevel` is appropriate (e.g., only log 'error' messages if `logLevel` is 'error' or more permissive).
+
+    ```typescript
+    'use client';
+
+    import { toast, ToastOptions } from 'sonner';
+    import { useCallback } from 'react';
+
+    type LogLevel = 'info' | 'warn' | 'error' | 'debug';
+
+    interface UseNotificationLoggerProps {
+      logLevel?: LogLevel;
+      toastOptions?: ToastOptions;
+    }
+
+    export function useNotificationLogger({ logLevel = 'info', toastOptions }: UseNotificationLoggerProps = {}) {
+      const log = useCallback((message: string, level: LogLevel = 'info') => {
+        if (shouldLog(level, logLevel)) {
+          if (process.env.NODE_ENV !== 'production') {
+            console.log(`[${level.toUpperCase()}]: ${message}`);
+          }
+
+          if (level === 'error') {
+            toast.error(message, toastOptions);
+          } else if (level === 'warn') {
+            toast.warning(message, toastOptions);
+          }
+          else {
+            toast(message, toastOptions);
+          }
+        }
+      }, [logLevel, toastOptions]);
+
+      return { log };
+    }
+
+    function shouldLog(messageLevel: LogLevel, configuredLevel: LogLevel): boolean {
+      const levels: { [key: string]: number } = {
+        'debug': 0,
+        'info': 1,
+        'warn': 2,
+        'error': 3,
+      };
+
+      return levels[messageLevel] >= levels[configuredLevel];
+    }
+    ```
+
+3.  **Usage:**
+
+    Import and use the `useNotificationLogger` hook in your client-side components.
+
+    ```typescript
+    'use client';
+
+    import { useNotificationLogger } from './use-notification-logger';
+    import { useState } from 'react';
+
+    function MyComponent() {
+      const { log } = useNotificationLogger({ logLevel: process.env.NEXT_PUBLIC_LOG_LEVEL as any || 'info', toastOptions: { duration: 5000 } });
+      const [count, setCount] = useState(0);
+
+      const handleClick = () => {
+        log(`Button clicked! Count: ${count}`, 'info');
+        setCount(count + 1);
+        // Perform other actions
+      };
+
+      const handleWarning = () => {
+        log('This is a warning message!', 'warn');
+      };
+
+       const handleError = () => {
+        log('This is an error message!', 'error');
+      };
+
+      return (
+        <>
+          <button onClick={handleClick}>Click Me</button>
+          <button onClick={handleWarning}>Show Warning</button>
+          <button onClick={handleError}>Show Error</button>
+        </>
+      );
+    }
+    ```
+
+## Benefits
+
+*   **Improved User Experience:** Provides immediate feedback to the user through toast notifications.
+*   **Enhanced Observability:** Combines toast notifications with console logging for detailed debugging information.
+*   **Reusability:** Can be easily integrated into any client-side component.
+*   **Configurable Logging Levels:** Control the verbosity of logging based on environment or application settings.
+*   **Customizable Toast Notifications:** Configure the appearance and behavior of toast notifications.
+
+## Considerations
+
+*   Choose a toast notification library that aligns with your project's design and accessibility requirements.
+*   Configure the `logLevel` based on the environment (e.g., more verbose logging in development, less verbose in production).  Use environment variables for configuration.
+*   Implement error handling to gracefully handle potential issues with the toast notification library.
+*   Be mindful of logging sensitive data.  Avoid logging any PII or secrets.
+*   The `NODE_ENV !== 'production'` check prevents console logs in production builds, further reducing performance impact.
+
+
+---
+*Provisioned by Rigstate CLI. Do not modify manually.*

package/.agent/skills/react-state-counter/SKILL.md

@@ -0,0 +1,73 @@
+---
+name: react-state-counter
+description: Creates a basic React component with state management for incrementing a counter.
+version: "1.0.0"
+specialist: Frank
+governance: OPEN
+---
+
+# React State Counter Component
+
+This skill provides a basic React component that uses the `useState` hook to manage and increment a numerical counter.
+
+## Implementation
+
+1.  **Import `useState`:**
+
+    ```javascript
+    import React, { useState } from 'react';
+    ```
+
+2.  **Define the Component:**
+
+    ```javascript
+    function Counter() {
+      // Initialize state with a default value of 0
+      const [count, setCount] = useState(0);
+
+      // Function to increment the counter
+      const increment = () => {
+        setCount(count + 1);
+      };
+
+      return (
+        <div>
+          <p>Count: {count}</p>
+          <button onClick={increment}>Increment</button>
+        </div>
+      );
+    }
+
+    export default Counter;
+    ```
+
+## Usage
+
+1.  **Import the Component:**
+
+    ```javascript
+    import Counter from './Counter'; // Adjust path as needed
+    ```
+
+2.  **Render the Component:**
+
+    ```javascript
+    function App() {
+      return (
+        <div>
+          <Counter />
+        </div>
+      );
+    }
+
+    export default App;
+    ```
+
+## Explanation
+
+*   `useState(0)`:  Initializes a state variable `count` to 0.  `useState` returns an array containing the current state value (`count`) and a function to update it (`setCount`).
+*   `increment()`:  This function is called when the button is clicked. It uses `setCount` to update the `count` state, triggering a re-render of the component.
+
+
+---
+*Provisioned by Rigstate CLI. Do not modify manually.*

package/.agent/skills/rigstate-evolutionary-refactor/SKILL.md

@@ -0,0 +1,40 @@
+---
+name: rigstate-evolutionary-refactor
+description: Blueprint for Quad-Pattern decomposition. Frank dictates, Antigravity executes.
+version: "1.0.0"
+specialist: Frank
+governance: SOFT_LOCK
+---
+
+# 🧬 Rigstate Evolutionary Refactor
+
+This is an authoritative architectural directive. When a file exceeds the line limit (or reaches the 80% proactive threshold), you must execute a structural decomposition using the **Quad-Pattern**.
+
+## 🛡️ The No-Code Protocol (Frank's Sovereignty)
+1. **Frank (Architect)** DICTATES the strategy. He identifies which code lines belong in which module.
+2. **Antigravity (Agent)** EXECUTES the physical split. He creates the files and updates imports.
+3. **Sentinal (Daemon)** VALIDATES the final integrity.
+
+## 🛠️ The Quad-Pattern Blueprint
+Decompose the monolith into these four distinct modules:
+
+| Module | Responsibility | Rule |
+| :--- | :--- | :--- |
+| **`types.ts`** | Interfaces, Enums, Type definitions | Zero logic. Shared by all. |
+| **`factory.ts`** | Initialization, Config parsing, Dependency injection | Returns a ready-to-use instance. |
+| **`telemetry.ts`** | Logging, Metrics, Cloud feedback, Errors | Handles all observability. |
+| **`core.ts`** | Business logic, Event orchestration | Max 200 lines. The primary entry point. |
+
+## 🕹️ Activation Logic
+- **Hard Trigger**: Triggered when `ARC-001` violation is detected by the Guardian.
+- **Proactive Trigger**: Triggered when a file reaches 80% of its defined line limit.
+
+## 📝 Execution Procedure:
+1. **Analyze (Frank)**: Scan the target file. Identify logical boundaries.
+2. **Design (Frank)**: Create a table mapping existing code blocks to the new modules.
+3. **Execute (Antigravity)**: Perform `write_to_file` for each new module.
+4. **Cleanup (Antigravity)**: Transform the original file into the new `core.ts` or replace it.
+5. **Verify (Sentinel)**: Run `rigstate check` to confirm compliance.
+
+---
+*Provisioned by Rigstate CLI. Do not modify manually.*

package/.agent/skills/rigstate-integrity-gate/SKILL.md

@@ -0,0 +1,55 @@
+---
+name: rigstate-integrity-gate
+description: Handles the Pre-Deployment Compliance Gate, automated quality audits (Security/Performance), and generation of the Strategic Release Manifest. Use this whenever you are finishing a task or moving code towards completion.
+version: "1.0.0"
+specialist: Frank (The Orchestrator)
+governance: SOFT_LOCK
+---
+
+---
+name: rigstate-integrity-gate
+description: Handles the Pre-Deployment Compliance Gate, automated quality audits (Security/Performance), and generation of the Strategic Release Manifest. Use this whenever you are finishing a task or moving code towards completion.
+version: "1.0.0"
+specialist: Frank (The Orchestrator)
+governance: SOFT_LOCK
+---
+
+# 🎖️ Rigstate Integrity Gate Skill (Fortress Enabled)
+
+This skill defines the high-level protocol for ensuring code quality and security before a task is marked as "COMPLETED". It orchestrates specialized agents (Sven, Sindre) and generates the audit trail known as the **Strategic Release Manifest**.
+
+## 🔄 The Protocol Workflow
+
+Whenever you are ready to complete a task, follow this mandatory 3-step sequence:
+
+### 1. Audit (The Scan)
+Run the `audit_integrity_gate` tool. This will trigger the **Fortress Matrix** checks:
+- **SEC-SQL-01 (Parameterized Only):** Blocking any string-interpolated SQL.
+- **SEC-RLS-01 (Mandatory RLS):** Validating RLS on all migration tables.
+- **SEC-KEY-01 (Secret Scanner):** Scanning for hardcoded keys and tokens.
+- **SEC-AUTH-04 (Identity Context):** Verifying ownership filters in API routes.
+
+### 2. Decision (The Gate)
+Evaluate the result from `audit_integrity_gate`:
+- **Mode: OPEN:** All critical checks passed. You can proceed to completion.
+- **Mode: SOFT_LOCK:** Warnings found (e.g. SEC-UI-01). Report to user.
+- **Mode: HARD_LOCK:** Critical violations (SEC-SQL/RLS/KEY) detected. Completion is strictly blocked.
+
+### 3. Manifest (The Release)
+Upon passing the gate, use the `complete_roadmap_task` tool.
+- Pass the **full JSON response** from the `audit_integrity_gate` into the `integrityGate` parameter.
+- This automatically generates the **Strategic Release Manifest** in the Mission Report.
+
+## 🛠️ Tools Used by this Skill
+
+- `audit_integrity_gate`: Orchestrates the security and performance scans.
+- `complete_roadmap_task`: Finalizes the task and attaches the quality certificate.
+
+## 📝 Best Practices
+
+- **Never skip the audit.** Even if you think the change is small, the Integrity Gate is our source of truth.
+- **Explain violations clearly.** If in `SOFT_LOCK`, list the specific tables lacking RLS or the specific files with N+1 issues.
+- **Summarize the Manifest.** After successful completion, tell the user: "Release Manifest generated with [X] security passes and [Y] performance checks."
+
+---
+*Provisioned by Rigstate CLI. Do not modify manually.*

package/.agent/skills/rigstate-legacy-renovator/SKILL.md

@@ -0,0 +1,12 @@
+---
+name: rigstate-legacy-renovator
+description: Handles the modernization of legacy Vibeline code to the Rigstate standard.
+version: "1.0.0"
+specialist: Brynjar
+governance: SOFT_LOCK
+---
+
+# 🏺 Rigstate Legacy Renovator Skill\n\nHandles branding renovation and archaeological history restoration.
+
+---
+*Provisioned by Rigstate CLI. Do not modify manually.*

package/.agent/skills/sec-auth-04/SKILL.md

@@ -0,0 +1,22 @@
+---
+name: sec-auth-04
+description: Ensures query isolation by validating user_id ownership.
+version: "1.0.0"
+specialist: Frank
+governance: HARD_LOCK
+---
+
+# 🛡️ SEC-AUTH-04: Identity Context (The Frank Protocol)
+This is a HARD_LOCK isolation directive.
+
+## 🚫 Forbidden
+Queries that fetch user-specific data without filtering by `user_id` or `owner_id`.
+
+## ✅ Mandated
+Every request in an API route must verify that the user is only accessing their own data.
+Example: `supabase.from('projects').select('*').eq('owner_id', userId)`
+
+Frank will verify that all database calls in the API layer include an appropriate ownership filter.
+
+---
+*Provisioned by Rigstate CLI. Do not modify manually.*

package/.agent/skills/sec-key-01/SKILL.md

@@ -0,0 +1,21 @@
+---
+name: sec-key-01
+description: Scans for hardcoded secrets and API keys.
+version: "1.0.0"
+specialist: Frank
+governance: HARD_LOCK
+---
+
+# 🛡️ SEC-KEY-01: Secret Scanner (The Sentinel Protocol)
+This is a FATAL integrity check.
+
+## 🚫 Forbidden
+Never hardcode API keys, service role keys, or JWT tokens in the codebase.
+
+## ✅ Mandated
+Always use environment variables (`process.env.VAR_NAME`) and keep them in `.env.local`.
+
+Frank will scan for high-entropy strings and known key prefixes (Stripe, Google, Supabase) and block the commit if any are found outside of .env files.
+
+---
+*Provisioned by Rigstate CLI. Do not modify manually.*

package/.agent/skills/sec-rls-01/SKILL.md

@@ -0,0 +1,22 @@
+---
+name: sec-rls-01
+description: Ensures Row Level Security is enabled on all new tables.
+version: "1.0.0"
+specialist: Sindre
+governance: HARD_LOCK
+---
+
+# 🛡️ SEC-RLS-01: Mandatory RLS (The Sindre Protocol)
+This is a HARD_LOCK protocol for database integrity.
+
+## 🚫 Forbidden
+Never push a migration that creates a table without enabling RLS.
+
+## ✅ Mandated
+Every `CREATE TABLE` statement must be followed by:
+`ALTER TABLE "public"."your_table" ENABLE ROW LEVEL SECURITY;`
+
+Frank/Sentinel will scan all migration files and block the release if this clause is missing for any table.
+
+---
+*Provisioned by Rigstate CLI. Do not modify manually.*

package/.agent/skills/sec-sql-01/SKILL.md

@@ -0,0 +1,23 @@
+---
+name: sec-sql-01
+description: Protects against SQL Injection by enforcing parameterized queries.
+version: "1.0.0"
+specialist: Sindre
+governance: HARD_LOCK
+---
+
+# 🛡️ SEC-SQL-01: Parameterized Only (The Sindre Protocol)
+This is a HARD_LOCK architectural directive.
+
+## 🚫 Forbidden 
+Never use string interpolation or concatenation to build SQL queries.
+Example of violation: `client.rpc('get_data', { query: `SELECT * FROM ${table}` })`
+
+## ✅ Mandated
+Use prepared statements or the built-in query builder.
+Example: `client.rpc('get_data', { table_id: 123 })`
+
+Frank will block the commit if any dynamic string building is detected in a database context.
+
+---
+*Provisioned by Rigstate CLI. Do not modify manually.*

package/.agent/skills/sec-ui-01/SKILL.md

@@ -0,0 +1,21 @@
+---
+name: sec-ui-01
+description: Prevents XSS by restricting dangerous React props.
+version: "1.0.0"
+specialist: Linus
+governance: SOFT_LOCK
+---
+
+# 🛡️ SEC-UI-01: XSS Defense (The Linus Protocol)
+This is a SOFT_LOCK quality directive.
+
+## 🚫 Forbidden
+Do not use `dangerouslySetInnerHTML` unless absolutely necessary and documented.
+
+## ✅ Mandated
+Use safe rendering or sanitize the content through a trusted library like `DOMPurify` before passing it to the component.
+
+Frank will nudge you and request a security audit if this pattern is detected.
+
+---
+*Provisioned by Rigstate CLI. Do not modify manually.*

package/.cursor/rules/rigstate-database.mdc

@@ -0,0 +1,89 @@
+---
+description: "Live database schema, RLS status, and table metadata"
+globs:
+  - "supabase/**/*"
+  - "**/*.sql"
+  - "**/lib/supabase/**"
+alwaysApply: true
+---
+## 🗄️ Database Context: 67 Tables
+> **Security Check:** 67 Secured | 0 Unsecured
+
+### ⚠️ Security Attention Required
+- ✅ All tables have Row Level Security enabled.
+
+### 📋 Schema Reference
+| Table | RLS | Policies | Cols | Key Features |
+| :--- | :---: | :---: | :---: | :--- |
+| `admin_audit_logs` | ✅ | 2 | 9 | Timestamps |
+| `agent_bridge` | ✅ | 4 | 10 | Timestamps |
+| `ai_activity_log` | ✅ | 2 | 9 | User-Scoped, Timestamps |
+| `ai_instructions` | ✅ | 3 | 11 | User-Scoped, Timestamps |
+| `ai_response_cache` | ✅ | 1 | 12 | Timestamps |
+| `api_keys` | ✅ | 6 | 11 | User-Scoped, Timestamps |
+| `architectural_dna` | ✅ | 5 | 5 | - |
+| `canvas_executions` | ✅ | 2 | 10 | - |
+| `canvas_flows` | ✅ | 1 | 12 | User-Scoped, Timestamps |
+| `canvas_recipients` | ✅ | 1 | 6 | Timestamps |
+| `cli_state` | ✅ | 5 | 3 | - |
+| `council_logs` | ✅ | 3 | 11 | Timestamps |
+| `council_sessions` | ✅ | 5 | 9 | Timestamps |
+| `daily_summaries` | ✅ | 2 | 5 | Timestamps |
+| `feature_flags` | ✅ | 2 | 8 | Timestamps |
+| `feedback_logs` | ✅ | 2 | 10 | User-Scoped, Timestamps |
+| `focus_sessions` | ✅ | 1 | 10 | Timestamps |
+| `git_events` | ✅ | 1 | 11 | Timestamps |
+| `global_architecture_rules` | ✅ | 2 | 9 | Timestamps |
+| `global_base_instructions` | ✅ | 2 | 9 | User-Scoped, Timestamps |
+| `global_intelligence_logs` | ✅ | 1 | 11 | Timestamps |
+| `guardian_violations` | ✅ | 4 | 15 | Timestamps |
+| `idea_feedback` | ✅ | 3 | 5 | Timestamps |
+| `intelligence_trends` | ✅ | 1 | 5 | - |
+| `lab_messages` | ✅ | 2 | 7 | Timestamps |
+| `lab_sessions` | ✅ | 6 | 8 | Timestamps |
+| `marketplace_purchases` | ✅ | 6 | 5 | - |
+| `memory_feedback` | ✅ | 3 | 6 | Timestamps |
+| `mission_reports` | ✅ | 1 | 9 | Timestamps |
+| `oauth_connections` | ✅ | 4 | 10 | User-Scoped, Timestamps |
+| `organization_members` | ✅ | 4 | 8 | User-Scoped, Timestamps |
+| `organization_subscriptions` | ✅ | 3 | 13 | Timestamps |
+| `organization_usage` | ✅ | 2 | 13 | Timestamps |
+| `organizations` | ✅ | 4 | 10 | User-Scoped, Timestamps |
+| `platform_analytics` | ✅ | 1 | 10 | - |
+| `profiles` | ✅ | 6 | 11 | - |
+| `project_architecture_rules` | ✅ | 1 | 7 | Timestamps |
+| `project_blueprints` | ✅ | 3 | 8 | Timestamps |
+| `project_docs` | ✅ | 5 | 8 | Timestamps |
+| `project_features` | ✅ | 5 | 25 | User-Scoped, Timestamps |
+| `project_memories` | ✅ | 1 | 17 | Timestamps |
+| `project_secrets` | ✅ | 4 | 9 | Timestamps |
+| `projects` | ✅ | 5 | 39 | User-Scoped, Timestamps |
+| `prompt_versions` | ✅ | 5 | 6 | Timestamps |
+| `provider_configs` | ✅ | 4 | 7 | - |
+| `pulse_blueprints` | ✅ | 1 | 11 | Timestamps |
+| `pulse_flows` | ✅ | 6 | 8 | Timestamps |
+| `pulse_history` | ✅ | 1 | 5 | - |
+| `qa_defects` | ✅ | 1 | 8 | Timestamps |
+| `qa_test_runs` | ✅ | 1 | 7 | Timestamps |
+| `qa_test_steps` | ✅ | 1 | 7 | Timestamps |
+| `roadmap_audit_logs` | ✅ | 1 | 8 | Timestamps |
+| `roadmap_chunks` | ✅ | 8 | 38 | Timestamps |
+| `saved_ideas` | ✅ | 3 | 19 | Timestamps |
+| `security_policies` | ✅ | 2 | 15 | User-Scoped, Timestamps |
+| `skills` | ✅ | 4 | 16 | User-Scoped, Timestamps |
+| `system_insights` | ✅ | 2 | 11 | Timestamps |
+| `system_prompt_versions` | ✅ | 1 | 6 | User-Scoped, Timestamps |
+| `system_prompts` | ✅ | 4 | 24 | User-Scoped, Timestamps |
+| `system_settings` | ✅ | 2 | 5 | - |
+| `user_credits` | ✅ | 1 | 3 | User-Scoped |
+| `user_integrations` | ✅ | 3 | 13 | User-Scoped, Timestamps |
+| `user_memories` | ✅ | 3 | 5 | User-Scoped, Timestamps |
+| `user_metadata` | ✅ | 2 | 6 | Timestamps |
+| `user_preferences` | ✅ | 4 | 8 | User-Scoped, Timestamps |
+| `vault_credentials` | ✅ | 1 | 12 | Timestamps |
+| `vision_log` | ✅ | 2 | 7 | User-Scoped, Timestamps |
+
+### 🛡️ Development Rules
+1.  **RLS is MANDATORY:** All tables containing user data must have RLS enabled.
+2.  **Use RPCs for Complex Logic:** Do not put complex business logic in client-side queries.
+3.  **Migrations:** Always use `supabase/migrations` for schema changes.

package/.cursor/rules/rigstate-guardian.mdc

@@ -0,0 +1,43 @@
+---
+description: "Governance rules, tech stack constraints, and file size limits"
+globs:
+  - "**/*.ts"
+  - "**/*.tsx"
+  - "**/*.js"
+  - "**/*.jsx"
+  - "**/*.sql"
+alwaysApply: true
+---
+## 🧬 STACK DNA
+
+### Tech Stack
+- Next.js
+- TypeScript
+- Supabase
+- Tailwind CSS
+
+### Project Configuration
+| Attribute | Value |
+|-----------|-------|
+| Tenancy | SINGLE |
+| Monetization | FREE |
+| Compliance | NONE |
+| Design Vibe | CORPORATE |
+
+
+### 🛡️ GUARDIAN RULES (Mandatory)
+🛡️ **THE 400-LINE RULE (STRICT):** No file may exceed 400 lines. If approaching this limit, you MUST propose a refactor into smaller modules.
+🛡️ **TSX LIMIT:** React components (.tsx) should not exceed 250 lines. Extract sub-components proactively.
+🛡️ **TYPE SAFETY:** Avoid "any". Use strict TypeScript types. Infer from Zod schemas when possible.
+👤 All queries are user-scoped (filter by user_id or RLS)
+⚡ Enable RLS on ALL new tables immediately
+⚡ Use @supabase/ssr patterns for server-side auth
+🚨 **IMPACT_GUARD:** Before deleting ANY file, you MUST:
+   1. Search codebase for all imports/references (use grep_search or equivalent)
+   2. Update or remove ALL references first
+   3. Only delete after confirming ZERO references remain
+   4. Commit changes atomically (references + deletion in same commit)
+✅ **BUILD_INTEGRITY:** After ANY structural change (new files, moved modules, refactors):
+   1. Run type-check (e.g., `tsc --noEmit` or framework equivalent)
+   2. Verify build success before declaring task complete
+   3. If errors detected, fix immediately—do NOT leave broken builds

package/.cursor/rules/rigstate-identity.mdc

@@ -0,0 +1,45 @@
+---
+description: "Project context and specialist personas"
+alwaysApply: true
+---
+## 🧠 PROJECT CONTEXT
+
+**Project:** Rigstate Core  
+**ID:** `bb9f8445-39fd-438c-8ab6-8057f5514395`  
+**Mission:** Build a MVP application.
+- **Target Users:** Lead Systems Architects, DevOps Compliance Engineers, and Platform Administrators responsible for hardening enterprise-grade infrastructure against architectural drift, security vulnerabilities, and unoptimized performance bottlenecks.
+- **Problem Being Solved:** The platform is facing critical architectural entropy and security exposure due to rapid scaling without enforced governance. High-value systems suffer from monolithic code bloat (violating L_max standards), unprotected public APIs, and a lack of granular observability (audit logs, error boundaries). This technical debt threatens system stability, compliance certification, and the ability to safely iterate on complex AI-driven features.
+
+---
+
+## 🤖 SPECIALIST PERSONAS
+
+The following personas represent areas of expertise. Reference their guidelines when working in their domain.
+
+- **Frank** (`orchestrator-lead`, Lvl 10): Orchestrate council meetings and synthesize feedback.
+- **Einar** (`lead-architect`, Lvl 9): Enforce high-level structural integrity and dependency-first planning.
+- **Hilde** (`compliance-guard`, Lvl 9): Ensure legal and regulatory safety (GDPR, etc.).
+- **Sven** (`security-ops`, Lvl 9): Validate code against security standards and RLS policies
+- **Sindre** (`scalability-expert`, Lvl 7): Design for massive scale and performance.
+- **Gunhild** (`agent-gunhild`, Lvl 7): Turn technical changes into human-readable documentation
+- **Astrid** (`research-specialist`, Lvl 6): Find the best libraries and architectural approaches.
+- **Maja** (`memory-manager`, Lvl 6): Persistent context and memory management.
+- **Kine** (`product-owner`, Lvl 5): Maximize user value and prevent scope creep.
+- **Linus** (`ux-designer`, Lvl 4): Create delightful and accessible user experiences.
+- **Rigstate Worker** (`rigstate-worker`, Lvl 3): To execute technical plans with surgical precision using native IDE tools while adhering to Rigstate security protocols.
+- **Norun** (`agent-secretary`, Lvl 1): Summarizes Focus Groups and extracting Memories
+
+### How to Use Specialists
+1. **Architecture & Governance** → Follow Frank's guidelines for code structure and security.
+2. **Documentation & Reports** → Use The Scribe's patterns for markdown and PDFs.
+3. **Historical Context** → Consult The Librarian for legacy feature discovery.
+
+> **Note:** These are informational contexts, not active agents. You (the IDE agent) execute all code.
+
+---
+
+## 🎯 CODING PRINCIPLES
+- **CONCISE:** No filler words. Get to the point.
+- **PRECISE:** Give specific answers with file paths and code.
+- **PRACTICAL:** Focus on what ships, not theory.
+- **GUARDIAN-AWARE:** Respect architectural constraints in the Guardian rules.

package/.cursor/rules/rigstate-roadmap.mdc

@@ -0,0 +1,9 @@
+---
+description: "Active sprint focus and current roadmap step details"
+alwaysApply: true
+---
+## 🎯 CURRENT FOCUS
+
+> **No active task.** The next step in the backlog is:
+> 
+> **Step 6: Refactor: Architectural Cleanup**