v0.6.26: ui improvements, multiple response blocks, docx previews, ollama fix

Author: waleedlatif1

.claude/rules/global.md

@@ -9,5 +9,26 @@ Use TSDoc for documentation. No `====` separators. No non-TSDoc comments.
 ## Styling
 Never update global styles. Keep all styling local to components.
 
+## ID Generation
+Never use `crypto.randomUUID()`, `nanoid`, or the `uuid` package directly. Use the utilities from `@/lib/core/utils/uuid`:
+
+- `generateId()` — UUID v4, use by default
+- `generateShortId(size?)` — short URL-safe ID (default 21 chars), for compact identifiers
+
+Both use `crypto.getRandomValues()` under the hood and work in all contexts including non-secure (HTTP) browsers.
+
+```typescript
+// ✗ Bad
+import { nanoid } from 'nanoid'
+import { v4 as uuidv4 } from 'uuid'
+const id = crypto.randomUUID()
+
+// ✓ Good
+import { generateId, generateShortId } from '@/lib/core/utils/uuid'
+const uuid = generateId()
+const shortId = generateShortId()
+const tiny = generateShortId(8)
+```
+
 ## Package Manager
 Use `bun` and `bunx`, not `npm` and `npx`.

.cursor/rules/global.mdc

@@ -16,5 +16,26 @@ Use TSDoc for documentation. No `====` separators. No non-TSDoc comments.
 ## Styling
 Never update global styles. Keep all styling local to components.
 
+## ID Generation
+Never use `crypto.randomUUID()`, `nanoid`, or the `uuid` package directly. Use the utilities from `@/lib/core/utils/uuid`:
+
+- `generateId()` — UUID v4, use by default
+- `generateShortId(size?)` — short URL-safe ID (default 21 chars), for compact identifiers
+
+Both use `crypto.getRandomValues()` under the hood and work in all contexts including non-secure (HTTP) browsers.
+
+```typescript
+// ✗ Bad
+import { nanoid } from 'nanoid'
+import { v4 as uuidv4 } from 'uuid'
+const id = crypto.randomUUID()
+
+// ✓ Good
+import { generateId, generateShortId } from '@/lib/core/utils/uuid'
+const uuid = generateId()
+const shortId = generateShortId()
+const tiny = generateShortId(8)
+```
+
 ## Package Manager
 Use `bun` and `bunx`, not `npm` and `npx`.

AGENTS.md

@@ -7,6 +7,7 @@ You are a professional software engineer. All code must follow best practices: a
 - **Logging**: Import `createLogger` from `@sim/logger`. Use `logger.info`, `logger.warn`, `logger.error` instead of `console.log`
 - **Comments**: Use TSDoc for documentation. No `====` separators. No non-TSDoc comments
 - **Styling**: Never update global styles. Keep all styling local to components
+- **ID Generation**: Never use `crypto.randomUUID()`, `nanoid`, or `uuid` package. Use `generateId()` (UUID v4) or `generateShortId()` (compact) from `@/lib/core/utils/uuid`
 - **Package Manager**: Use `bun` and `bunx`, not `npm` and `npx`
 
 ## Architecture

CLAUDE.md

@@ -7,6 +7,7 @@ You are a professional software engineer. All code must follow best practices: a
 - **Logging**: Import `createLogger` from `@sim/logger`. Use `logger.info`, `logger.warn`, `logger.error` instead of `console.log`
 - **Comments**: Use TSDoc for documentation. No `====` separators. No non-TSDoc comments
 - **Styling**: Never update global styles. Keep all styling local to components
+- **ID Generation**: Never use `crypto.randomUUID()`, `nanoid`, or `uuid` package. Use `generateId()` (UUID v4) or `generateShortId()` (compact) from `@/lib/core/utils/uuid`
 - **Package Manager**: Use `bun` and `bunx`, not `npm` and `npx`
 
 ## Architecture

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

@@ -20,7 +20,7 @@ The Response block formats and sends structured HTTP responses back to API calle
 </div>
 
 <Callout type="info">
-  Response blocks are terminal blocks - they end workflow execution and cannot connect to other blocks.
+  Response blocks are exit points — when a Response block executes, it ends the workflow and sends the HTTP response immediately. Multiple Response blocks can be placed on different branches (e.g. after a Router or Condition), but only the first one to execute determines the API response.
 </Callout>
 
 ## Configuration Options
@@ -77,7 +77,11 @@ Condition (Error Detected) → Router → Response (400/500, Error Details)
 
 ## Outputs
 
-Response blocks are terminal — no downstream blocks execute after them. However, the block does define outputs (`data`, `status`, `headers`) which are used to construct the HTTP response sent back to the API caller.
+Response blocks are exit points — when one executes, no further blocks run. The block defines outputs (`data`, `status`, `headers`) which are used to construct the HTTP response sent back to the API caller.
+
+<Callout type="warning">
+  If a Response block is placed on a parallel branch, there are no guarantees about whether other parallel blocks will run or not. Execution order across parallel branches is non-deterministic, so a parallel block may execute before or after the Response block on any given run. Avoid placing Response blocks in parallel with blocks that have important side effects.
+</Callout>
 
 ## Variable References
 
@@ -110,10 +114,10 @@ Use the `<variable.name>` syntax to dynamically insert workflow variables into y
 - **Validate variable references**: Ensure all referenced variables exist and contain the expected data types before the Response block executes
 
 <FAQ items={[
-  { question: "Can I have multiple Response blocks in a workflow?", answer: "No. The Response block is a single-instance block — only one is allowed per workflow. If you need different responses for different conditions, use a Condition or Router block upstream to determine what data reaches the single Response block." },
+  { question: "Can I have multiple Response blocks in a workflow?", answer: "Yes. You can place multiple Response blocks on different branches (e.g. after a Router or Condition block). The first Response block to execute determines the API response and ends the workflow. This is useful for returning different responses based on conditions — for example, a 200 on the success branch and a 500 on the error branch." },
   { question: "What triggers require a Response block?", answer: "The Response block is designed for use with the API Trigger. When your workflow is invoked via the API, the Response block sends the structured HTTP response back to the caller. Other trigger types (like webhooks or schedules) do not require a Response block." },
   { question: "What is the difference between Builder and Editor mode?", answer: "Builder mode provides a visual interface for constructing your response structure with fields and types. Editor mode gives you a raw JSON code editor where you can write the response body directly. Builder mode is recommended for most use cases." },
   { question: "What is the default status code?", answer: "If you do not specify a status code, the Response block defaults to 200 (OK). You can set any valid HTTP status code including error codes like 400, 404, or 500." },
-  { question: "Can the Response block connect to downstream blocks?", answer: "No. Response blocks are terminal — they end workflow execution and send the HTTP response. No further blocks can be connected after a Response block." },
+  { question: "Can the Response block connect to downstream blocks?", answer: "No. Response blocks are exit points — they end workflow execution and send the HTTP response. No further blocks can execute after a Response block." },
 ]} />
 

apps/docs/content/docs/en/execution/basics.mdx

@@ -96,8 +96,9 @@ Understanding these core principles will help you build better workflows:
 2. **Automatic Parallelization**: Independent blocks run concurrently without configuration
 3. **Smart Data Flow**: Outputs flow automatically to connected blocks
 4. **Error Handling**: Failed blocks stop their execution path but don't affect independent paths
-5. **State Persistence**: All block outputs and execution details are preserved for debugging
-6. **Cycle Protection**: Workflows that call other workflows (via Workflow blocks, MCP tools, or API blocks) are tracked with a call chain. If the chain exceeds 25 hops, execution is stopped to prevent infinite loops
+5. **Response Blocks as Exit Points**: When a Response block executes, the entire workflow stops and the API response is sent immediately. Multiple Response blocks can exist on different branches — the first one to execute wins
+6. **State Persistence**: All block outputs and execution details are preserved for debugging
+7. **Cycle Protection**: Workflows that call other workflows (via Workflow blocks, MCP tools, or API blocks) are tracked with a call chain. If the chain exceeds 25 hops, execution is stopped to prevent infinite loops
 
 ## Next Steps
 

apps/docs/content/docs/en/tools/cursor.mdx

@@ -45,6 +45,7 @@ List all cloud agents for the authenticated user with optional pagination. Retur
 | `apiKey` | string | Yes | Cursor API key |
 | `limit` | number | No | Number of agents to return \(default: 20, max: 100\) |
 | `cursor` | string | No | Pagination cursor from previous response |
+| `prUrl` | string | No | Filter agents by pull request URL |
 
 #### Output
 
@@ -173,4 +174,41 @@ Permanently delete a cloud agent. Returns API-aligned fields only.
 | --------- | ---- | ----------- |
 | `id` | string | Agent ID |
 
+### `cursor_list_artifacts`
+
+List generated artifact files for a cloud agent. Returns API-aligned fields only.
+
+#### Input
+
+| Parameter | Type | Required | Description |
+| --------- | ---- | -------- | ----------- |
+| `apiKey` | string | Yes | Cursor API key |
+| `agentId` | string | Yes | Unique identifier for the cloud agent \(e.g., bc_abc123\) |
+
+#### Output
+
+| Parameter | Type | Description |
+| --------- | ---- | ----------- |
+| `artifacts` | array | List of artifact files |
+|   ↳ `path` | string | Artifact file path |
+|   ↳ `size` | number | File size in bytes |
+
+### `cursor_download_artifact`
+
+Download a generated artifact file from a cloud agent. Returns the file for execution storage.
+
+#### Input
+
+| Parameter | Type | Required | Description |
+| --------- | ---- | -------- | ----------- |
+| `apiKey` | string | Yes | Cursor API key |
+| `agentId` | string | Yes | Unique identifier for the cloud agent \(e.g., bc_abc123\) |
+| `path` | string | Yes | Absolute path of the artifact to download \(e.g., /src/index.ts\) |
+
+#### Output
+
+| Parameter | Type | Description |
+| --------- | ---- | ----------- |
+| `file` | file | Downloaded artifact file stored in execution files |
+
 

apps/sim/app/(auth)/auth-layout-client.tsx

@@ -2,7 +2,7 @@
 
 import { useEffect } from 'react'
 import AuthBackground from '@/app/(auth)/components/auth-background'
-import Navbar from '@/app/(home)/components/navbar/navbar'
+import Navbar from '@/app/(landing)/components/navbar/navbar'
 
 export default function AuthLayoutClient({ children }: { children: React.ReactNode }) {
   useEffect(() => {

apps/sim/app/(auth)/components/social-login-buttons.tsx

@@ -81,7 +81,7 @@ export function SocialLoginButtons({
   const githubButton = (
     <Button
       variant='outline'
-      className='w-full rounded-[10px]'
+      className='w-full rounded-sm border-[var(--landing-border-strong)] py-1.5 text-sm'
       disabled={!githubAvailable || isGithubLoading}
       onClick={signInWithGithub}
     >
@@ -93,7 +93,7 @@ export function SocialLoginButtons({
   const googleButton = (
     <Button
       variant='outline'
-      className='w-full rounded-[10px]'
+      className='w-full rounded-sm border-[var(--landing-border-strong)] py-1.5 text-sm'
       disabled={!googleAvailable || isGoogleLoading}
       onClick={signInWithGoogle}
     >

apps/sim/app/(auth)/components/sso-login-button.tsx

@@ -28,7 +28,9 @@ export function SSOLoginButton({
     router.push(ssoUrl)
   }
 
-  const outlineBtnClasses = cn('w-full rounded-[10px]')
+  const outlineBtnClasses = cn(
+    'w-full rounded-sm border-[var(--landing-border-strong)] py-1.5 text-sm'
+  )
 
   return (
     <Button