Merge staging into fix/router

Author: icecrasher321

.cursor/rules/sim-testing.mdc

@@ -1,60 +1,57 @@
 ---
-description: Testing patterns with Vitest
+description: Testing patterns with Vitest and @sim/testing
 globs: ["apps/sim/**/*.test.ts", "apps/sim/**/*.test.tsx"]
 ---
 
 # Testing Patterns
 
-Use Vitest. Test files live next to source: `feature.ts` → `feature.test.ts`
+Use Vitest. Test files: `feature.ts` → `feature.test.ts`
 
 ## Structure
 
 ```typescript
 /**
- * Tests for [feature name]
- *
  * @vitest-environment node
  */
+import { databaseMock, loggerMock } from '@sim/testing'
+import { describe, expect, it, vi } from 'vitest'
 
-// 1. Mocks BEFORE imports
-vi.mock('@sim/db', () => ({ db: { select: vi.fn() } }))
+vi.mock('@sim/db', () => databaseMock)
 vi.mock('@sim/logger', () => loggerMock)
 
-// 2. Imports AFTER mocks
-import { describe, expect, it, vi, beforeEach, afterEach } from 'vitest'
-import { createSession, loggerMock } from '@sim/testing'
 import { myFunction } from '@/lib/feature'
 
 describe('myFunction', () => {
   beforeEach(() => vi.clearAllMocks())
-
-  it('should do something', () => {
-    expect(myFunction()).toBe(expected)
-  })
-
-  it.concurrent('runs in parallel', () => { ... })
+  it.concurrent('isolated tests run in parallel', () => { ... })
 })
 ```
 
 ## @sim/testing Package
 
-```typescript
-// Factories - create test data
-import { createBlock, createWorkflow, createSession } from '@sim/testing'
+Always prefer over local mocks.
 
-// Mocks - pre-configured mocks
-import { loggerMock, databaseMock, fetchMock } from '@sim/testing'
-
-// Builders - fluent API for complex objects
-import { ExecutionBuilder, WorkflowBuilder } from '@sim/testing'
-```
+| Category | Utilities |
+|----------|-----------|
+| **Mocks** | `loggerMock`, `databaseMock`, `setupGlobalFetchMock()` |
+| **Factories** | `createSession()`, `createWorkflowRecord()`, `createBlock()`, `createExecutorContext()` |
+| **Builders** | `WorkflowBuilder`, `ExecutionContextBuilder` |
+| **Assertions** | `expectWorkflowAccessGranted()`, `expectBlockExecuted()` |
 
 ## Rules
 
 1. `@vitest-environment node` directive at file top
-2. **Mocks before imports** - `vi.mock()` calls must come first
-3. Use `@sim/testing` factories over manual test data
-4. `it.concurrent` for independent tests (faster)
+2. `vi.mock()` calls before importing mocked modules
+3. `@sim/testing` utilities over local mocks
+4. `it.concurrent` for isolated tests (no shared mutable state)
 5. `beforeEach(() => vi.clearAllMocks())` to reset state
-6. Group related tests with nested `describe` blocks
-7. Test file naming: `*.test.ts` (not `*.spec.ts`)
+
+## Hoisted Mocks
+
+For mutable mock references:
+
+```typescript
+const mockFn = vi.hoisted(() => vi.fn())
+vi.mock('@/lib/module', () => ({ myFunction: mockFn }))
+mockFn.mockResolvedValue({ data: 'test' })
+```

CLAUDE.md

@@ -173,21 +173,21 @@ Use Vitest. Test files: `feature.ts` → `feature.test.ts`
 /**
  * @vitest-environment node
  */
+import { databaseMock, loggerMock } from '@sim/testing'
+import { describe, expect, it, vi } from 'vitest'
 
-// Mocks BEFORE imports
-vi.mock('@sim/db', () => ({ db: { select: vi.fn() } }))
+vi.mock('@sim/db', () => databaseMock)
+vi.mock('@sim/logger', () => loggerMock)
 
-// Imports AFTER mocks
-import { describe, expect, it, vi } from 'vitest'
-import { createSession, loggerMock } from '@sim/testing'
+import { myFunction } from '@/lib/feature'
 
 describe('feature', () => {
   beforeEach(() => vi.clearAllMocks())
   it.concurrent('runs in parallel', () => { ... })
 })
 ```
 
-Use `@sim/testing` factories over manual test data.
+Use `@sim/testing` mocks/factories over local test data. See `.cursor/rules/sim-testing.mdc` for details.
 
 ## Utils Rules
 

apps/docs/content/docs/en/blocks/router.mdx

@@ -5,12 +5,12 @@ title: Router
 import { Tab, Tabs } from 'fumadocs-ui/components/tabs'
 import { Image } from '@/components/ui/image'
 
-The Router block uses AI to intelligently route workflows based on content analysis. Unlike Condition blocks that use simple rules, Routers understand context and intent.
+The Router block uses AI to intelligently route workflows based on content analysis. Unlike Condition blocks that use simple rules, Routers understand context and intent. Each route you define creates a separate output port, allowing you to connect different paths to different downstream blocks.
 
 <div className="flex justify-center">
   <Image
     src="/static/blocks/router.png"
-    alt="Router Block with Multiple Paths"
+    alt="Router Block with Multiple Route Ports"
     width={500}
     height={400}
     className="my-6"
@@ -31,21 +31,23 @@ The Router block uses AI to intelligently route workflows based on content analy
 
 ## Configuration Options
 
-### Content/Prompt
+### Context
 
-The content or prompt that the Router will analyze to make routing decisions. This can be:
+The context that the Router will analyze to make routing decisions. This is the input data that gets evaluated against your route descriptions. It can be:
 
 - A direct user query or input
 - Output from a previous block
 - A system-generated message
+- Any text content that needs intelligent routing
 
-### Target Blocks
+### Routes
 
-The possible destination blocks that the Router can select from. The Router will automatically detect connected blocks, but you can also:
+Define the possible paths that the Router can take. Each route consists of:
 
-- Customize the descriptions of target blocks to improve routing accuracy
-- Specify routing criteria for each target block
-- Exclude certain blocks from being considered as routing targets
+- **Route Title**: A name for the route (e.g., "Sales", "Support", "Technical")
+- **Route Description**: A clear description of when this route should be selected (e.g., "Route here when the query is about pricing, purchasing, or sales inquiries")
+
+Each route you add creates a **separate output port** on the Router block. Connect each port to the appropriate downstream block for that route.
 
 ### Model Selection
 
@@ -65,30 +67,40 @@ Your API key for the selected LLM provider. This is securely stored and used for
 
 ## Outputs
 
-- **`<router.prompt>`**: Summary of the routing prompt
-- **`<router.selected_path>`**: Chosen destination block
+- **`<router.context>`**: The context that was analyzed
+- **`<router.selectedRoute>`**: The ID of the selected route
+- **`<router.selected_path>`**: Details of the chosen destination block
 - **`<router.tokens>`**: Token usage statistics
 - **`<router.cost>`**: Estimated routing cost
 - **`<router.model>`**: Model used for decision-making
 
 ## Example Use Cases
 
 **Customer Support Triage** - Route tickets to specialized departments
+
 ```
-Input (Ticket) → Router → Agent (Engineering) or Agent (Finance)
+Input (Ticket) → Router
+                  ├── [Sales Route] → Agent (Sales Team)
+                  ├── [Technical Route] → Agent (Engineering)
+                  └── [Billing Route] → Agent (Finance)
 ```
 
 **Content Classification** - Classify and route user-generated content
+
 ```
-Input (Feedback) → Router → Workflow (Product) or Workflow (Technical)
+Input (Feedback) → Router
+                    ├── [Product Feedback] → Workflow (Product Team)
+                    └── [Bug Report] → Workflow (Technical Team)
 ```
 
 **Lead Qualification** - Route leads based on qualification criteria
+
 ```
-Input (Lead) → Router → Agent (Enterprise Sales) or Workflow (Self-serve)
+Input (Lead) → Router
+                ├── [Enterprise] → Agent (Enterprise Sales)
+                └── [Self-serve] → Workflow (Automated Onboarding)
 ```
 
-
 ## Error Handling
 
 When the Router cannot determine an appropriate route for the given context, it will route to the **error path** instead of arbitrarily selecting a route. This happens when:
@@ -98,9 +110,10 @@ When the Router cannot determine an appropriate route for the given context, it
 
 ## Best Practices
 
-- **Provide clear target descriptions**: Help the Router understand when to select each destination with specific, detailed descriptions
-- **Use specific routing criteria**: Define clear conditions and examples for each path to improve accuracy
-- **Connect an error path**: Handle cases where no route matches by connecting an error handler for graceful fallback behavior
-- **Test with diverse inputs**: Ensure the Router handles various input types, edge cases, and unexpected content
-- **Monitor routing performance**: Review routing decisions regularly and refine criteria based on actual usage patterns
-- **Choose appropriate models**: Use models with strong reasoning capabilities for complex routing decisions
+- **Write clear route descriptions**: Each route description should clearly explain when that route should be selected. Be specific about the criteria.
+- **Make routes mutually exclusive**: When possible, ensure route descriptions don't overlap to prevent ambiguous routing decisions.
+- **Connect an error path**: Handle cases where no route matches by connecting an error handler for graceful fallback behavior.
+- **Use descriptive route titles**: Route titles appear in the workflow canvas, so make them meaningful for readability.
+- **Test with diverse inputs**: Ensure the Router handles various input types, edge cases, and unexpected content.
+- **Monitor routing performance**: Review routing decisions regularly and refine route descriptions based on actual usage patterns.
+- **Choose appropriate models**: Use models with strong reasoning capabilities for complex routing decisions.

apps/docs/content/docs/en/enterprise/index.mdx

@@ -1,6 +1,6 @@
 ---
 title: Enterprise
-description: Enterprise features for organizations with advanced security and compliance requirements
+description: Enterprise features for business organizations
 ---
 
 import { Callout } from 'fumadocs-ui/components/callout'
@@ -9,6 +9,28 @@ Sim Studio Enterprise provides advanced features for organizations with enhanced
 
 ---
 
+## Access Control
+
+Define permission groups to control what features and integrations team members can use.
+
+### Features
+
+- **Allowed Model Providers** - Restrict which AI providers users can access (OpenAI, Anthropic, Google, etc.)
+- **Allowed Blocks** - Control which workflow blocks are available
+- **Platform Settings** - Hide Knowledge Base, disable MCP tools, or disable custom tools
+
+### Setup
+
+1. Navigate to **Settings** → **Access Control** in your workspace
+2. Create a permission group with your desired restrictions
+3. Add team members to the permission group
+
+<Callout type="info">
+  Users not assigned to any permission group have full access. Permission restrictions are enforced at both UI and execution time.
+</Callout>
+
+---
+
 ## Bring Your Own Key (BYOK)
 
 Use your own API keys for AI model providers instead of Sim Studio's hosted keys.
@@ -61,15 +83,38 @@ Enterprise authentication with SAML 2.0 and OIDC support for centralized identit
 
 ---
 
-## Self-Hosted
+## Self-Hosted Configuration
+
+For self-hosted deployments, enterprise features can be enabled via environment variables without requiring billing.
 
-For self-hosted deployments, enterprise features can be enabled via environment variables:
+### Environment Variables
 
 | Variable | Description |
 |----------|-------------|
+| `ORGANIZATIONS_ENABLED`, `NEXT_PUBLIC_ORGANIZATIONS_ENABLED` | Enable team/organization management |
+| `ACCESS_CONTROL_ENABLED`, `NEXT_PUBLIC_ACCESS_CONTROL_ENABLED` | Permission groups for access restrictions |
 | `SSO_ENABLED`, `NEXT_PUBLIC_SSO_ENABLED` | Single Sign-On with SAML/OIDC |
 | `CREDENTIAL_SETS_ENABLED`, `NEXT_PUBLIC_CREDENTIAL_SETS_ENABLED` | Polling Groups for email triggers |
 
-<Callout type="warn">
-  BYOK is only available on hosted Sim Studio. Self-hosted deployments configure AI provider keys directly via environment variables.
-</Callout>
+### Organization Management
+
+When billing is disabled, use the Admin API to manage organizations:
+
+```bash
+# Create an organization
+curl -X POST https://your-instance/api/v1/admin/organizations \
+  -H "x-admin-key: YOUR_ADMIN_API_KEY" \
+  -H "Content-Type: application/json" \
+  -d '{"name": "My Organization", "ownerId": "user-id-here"}'
+
+# Add a member
+curl -X POST https://your-instance/api/v1/admin/organizations/{orgId}/members \
+  -H "x-admin-key: YOUR_ADMIN_API_KEY" \
+  -H "Content-Type: application/json" \
+  -d '{"userId": "user-id-here", "role": "admin"}'
+```
+
+### Notes
+
+- Enabling `ACCESS_CONTROL_ENABLED` automatically enables organizations, as access control requires organization membership.
+- BYOK is only available on hosted Sim Studio. Self-hosted deployments configure AI provider keys directly via environment variables.