v0.7.6: calendar scheduled tasks, new hubspot tools, virtualized chat, db perf improvements

.agents/skills/add-block/SKILL.md

@@ -640,6 +640,7 @@ import type { BlockConfig, BlockMeta } from '@/blocks/types'
 
 export const {Service}BlockMeta = {
   tags: ['messaging', 'automation'],   // Same tags as the block's tags field
+  url: 'https://{service}.com',         // Canonical homepage of the external service
   templates: [                          // Optional but strongly encouraged
     {
       icon: {Service}Icon,
@@ -666,6 +667,7 @@ export const {Service}BlockMeta = {
 
 - **Import `BlockMeta`** from `@/blocks/types` alongside `BlockConfig`
 - **`tags`** must match the `tags` array on the block config exactly
+- **`url`** is the canonical homepage of the external service the block integrates with (e.g. `'https://exa.ai'`, `'https://salesforce.com'`) — the catalog "link back to the tool". It is distinct from `BlockConfig.docsLink`, which points at Sim's own integration docs on `docs.sim.ai`. Use the service's real root domain over `https` (verify it actually resolves), no tracking params, no trailing slash. Omit `url` only for first-party/built-in blocks that have no external service (e.g. `agent`, `function`, `condition`, `api`, `response`)
 - **Templates are optional** but should be added for any integration that has a recognizable use case — aim for 2–4 templates per block
 - **Template `prompt`** should start with "Build a workflow that..." or "Create a workflow that..." and be concrete enough to generate a real workflow in Mothership
 - **Template `modules`** lists the Sim modules the template relies on: `'knowledge-base' | 'tables' | 'files' | 'workflows' | 'scheduled' | 'agent'`
@@ -906,6 +908,7 @@ All tool IDs referenced in `tools.access` and returned by `tools.config.tool` MU
 - [ ] Outputs match tool outputs
 - [ ] Block registered in `registry.ts` blocks object (alphabetically)
 - [ ] `{Service}BlockMeta` exported at bottom of block file with `tags` and `templates`
+- [ ] `url` set on `{Service}BlockMeta` to the external service's verified homepage (omit only for first-party blocks with no external service)
 - [ ] `skills` added to `{Service}BlockMeta`, each grounded in the block's `tools.access` and derived from a real online-sourced use case (not invented)
 - [ ] `BlockMeta` imported from `@/blocks/types` alongside `BlockConfig`
 - [ ] Block meta registered in `registry.ts` blocksMeta object (alphabetically)

.claude/commands/add-block.md

@@ -794,6 +794,7 @@ import type { BlockMeta } from '@/blocks/types'
 
 export const {Service}BlockMeta = {
   tags: ['tag1', 'tag2'],                  // IntegrationTag[]
+  url: 'https://{service}.com',            // external service homepage (verify it resolves) — NOT docs.sim.ai
   templates: [
     {
       icon: {Service}Icon,
@@ -845,6 +846,7 @@ Derive templates from the service's real use cases. Each prompt should name a co
 - [ ] Optional/rarely-used fields set to `mode: 'advanced'`
 - [ ] Timestamps and complex inputs have `wandConfig` enabled
 - [ ] Exported `{Service}BlockMeta` with at least 7 templates
+- [ ] `url` set on `{Service}BlockMeta` to the external service's verified homepage (omit only for first-party blocks with no external service)
 - [ ] `skills` added to `{Service}BlockMeta`, each grounded in `tools.access` and sourced from a real online use case (not invented)
 
 ## Final Validation (Required)

.claude/rules/constitution.md

@@ -23,7 +23,8 @@ Sim is the **AI workspace** where teams build and run AI agents. Not a workflow
 | The product | "AI workspace" | "workflow tool", "automation platform", "agent framework" |
 | Building | "build agents", "create agents" | "create workflows" (unless describing the workflow module specifically) |
 | Visual builder | "workflow builder" or "visual builder" | "canvas", "graph editor" |
-| Mothership | "Mothership" (capitalized) | "chat", "AI assistant", "copilot" |
+| The agent | "Sim" — you talk to Sim | "Mothership", "copilot", "AI assistant" |
+| The chat surface | "Chat" (capitalized, the module) | "Mothership", "copilot" |
 | Deployment | "deploy", "ship" | "publish", "activate" |
 | Audience | "teams", "builders" | "users", "customers" (in marketing copy) |
 | What agents do | "automate real work" | "automate tasks", "automate workflows" |
@@ -50,7 +51,7 @@ When describing Sim, always lead with the most differentiated claim:
 
 | Module | One-liner |
 |--------|-----------|
-| **Mothership** | Your AI command center. Build and manage everything in natural language. |
+| **Chat** | Your AI command center. Talk to Sim — build and manage everything in natural language. |
 | **Workflows** | The visual builder. Connect blocks, models, and integrations into agent logic. |
 | **Knowledge Base** | Your agents' memory. Upload docs, sync sources, build vector databases. |
 | **Tables** | A database, built in. Store, query, and wire structured data into agent runs. |
@@ -65,7 +66,8 @@ When describing Sim, always lead with the most differentiated claim:
 - Never promise unshipped features
 - Never use jargon ("RAG", "vector database", "MCP") without plain-English explanation on public pages
 - Avoid "agentic workforce" as a primary term — use "AI agents"
+- Never say "Mothership" or "copilot" — the agent is "Sim", the surface is "Chat" (in run logs the trigger reads "Sim agent")
 
 ## Vision
 
-Sim becomes the default environment where teams build AI agents — not a tool you visit for one task, but a workspace you live in. Workflows are one module; Mothership is another. The workspace is the constant; the interface adapts.
+Sim becomes the default environment where teams build AI agents — not a tool you visit for one task, but a workspace you live in. Workflows are one module; Chat is another. The workspace is the constant; the interface adapts.

.claude/rules/emcn-components.md

@@ -22,13 +22,15 @@ The menu surface intentionally diverges from the pill: `dropdown-menu.tsx` items
 
 - **`Chip` / `ChipLink`** — the pill button (`<button>` / Next `<Link>`). Variants: `ghost`, `filled`, `primary`, `destructive`, `border-shadow`. `leftIcon`/`rightIcon`, `active`, `fullWidth`, `flush`.
 - **`ChipInput`** — single-line text field. `icon`, `endAdornment`, `error`, `inputClassName` (inner `<input>`); `className` styles the chrome wrapper.
-- **`ChipTextarea`** — multi-line sibling. `error`, `resizable` (off by default).
+- **`ChipCopyInput`** — the canonical view-only field: a read-only `ChipInput` at full opacity with a trailing copy-to-clipboard button. View-only is a display mode, not a disabled state — reach for it (or `ChipModalField type='copy'`) over a `disabled` (greyed) input for values the user cannot edit.
+- **`ChipTextarea`** — multi-line sibling. `error`, `resizable` (off by default), `viewOnly` (read-only at full opacity with the default cursor — the multi-line counterpart of `ChipCopyInput`).
 - **`ChipDropdown`** — pill that opens a menu. Single OR multi-select via the discriminated `multiple` prop (one component, not two). Owns its trailing chevron — no `rightIcon`.
 - **`ChipSelect` / `ChipCombobox`** — `Combobox`-backed pickers with search, groups, multi-select; for richer lists than `ChipDropdown`.
-- **`ChipModal` + `ChipModalField`** — declarative compact modal. The field's `type` (`input` | `email` | `textarea` | `dropdown` | `file` | `emails` | `custom`) picks the control and **owns all chrome** — consumers describe intent, never pass `variant`/`className`/`id` to the inner control. `custom` is the escape hatch. **Every body field MUST be a `ChipModalField`** — never hand-roll a field row (raw `<div>` + hand-rolled `<p>`/`<label>` title + bare `ChipInput`/`ChipTextarea`). `ChipModalBody` applies `px-2` + `gap-4`; `ChipModalField` adds another `px-2`, so each field lands at effective `px-4`, exactly matching the `px-4` header/footer — a hand-rolled row skips that gutter and sits misaligned at `px-2`. For controls the field doesn't cover (`ChipCombobox`, `ChipSelect`, `DatePicker`, `TimePicker`, `ButtonGroup`, arbitrary JSX), use `type='custom'` with a `title` — it still applies the gutter and renders the canonical `Label`.
+- **`ChipModal` + `ChipModalField`** — declarative compact modal. The field's `type` (`input` | `email` | `textarea` | `dropdown` | `copy` | `file` | `emails` | `custom`) picks the control and **owns all chrome** — consumers describe intent, never pass `variant`/`className`/`id` to the inner control. `custom` is the escape hatch. **Every body field MUST be a `ChipModalField`** — never hand-roll a field row (raw `<div>` + hand-rolled `<p>`/`<label>` title + bare `ChipInput`/`ChipTextarea`). `ChipModalBody` applies `px-2` + `gap-4`; `ChipModalField` adds another `px-2`, so each field lands at effective `px-4`, exactly matching the `px-4` header/footer — a hand-rolled row skips that gutter and sits misaligned at `px-2`. For controls the field doesn't cover (`ChipCombobox`, `ChipSelect`, `DatePicker`, `TimePicker`, `ButtonGroup`, arbitrary JSX), use `type='custom'` with a `title` — it still applies the gutter and renders the canonical `Label`.
 - **`ChipSwitch`** — segmented pill control (built from `chipVariants`).
 - **`ChipTag`** — 20px inline tag/badge (`mono`/`gray`/`invite`), not a pill trigger.
 - **`ChipDatePicker`** — chip-styled date field.
+- **`ChipTimePicker`** — minute-granular time sibling of `ChipDatePicker`, a `ChipInput` that leniently parses typed input (`9:47`, `947`, `2:05pm`, `14:30`), commits on Enter/blur, and re-renders the canonical `9:47 AM` label.
 - **`DropdownMenu`** — the canonical context/action menu (Radix-backed). Not a chip, but the standard menu for command/action lists; reach for it instead of a hand-rolled popover. Its surface intentionally diverges from the chip pill (`text-small`, `gap-2`) — keep them distinct. For a pill that opens a value picker, use `ChipDropdown`/`ChipSelect` instead.
 
 ## Authoring principles

.claude/rules/sim-queries.md

@@ -137,3 +137,7 @@ const handler = useCallback(() => {
 - **Query hooks**: `useEntity`, `useEntityList`
 - **Mutation hooks**: `useCreateEntity`, `useUpdateEntity`, `useDeleteEntity`
 - **Fetch functions**: `fetchEntity`, `fetchEntities` (private)
+
+## Enforcement
+
+`scripts/check-react-query-patterns.ts` (`bun run check:react-query`, run in CI) statically enforces these conventions: every `useQuery`/`useInfiniteQuery`/`useSuspenseQuery` declares an explicit `staleTime`, inline `queryFn`s destructure `signal`, `queryKey`s reference a colocated factory rather than an inline literal, and every `*Keys` factory in `hooks/queries/**` exposes an `all` root key. `hooks/queries/**` is a zero-tolerance zone; the rest of `apps/sim/**` is ratcheted against `scripts/check-react-query-patterns.baseline.json`. For a genuine exception, put `// rq-lint-allow: <reason>` on the line directly above the flagged construct.

.github/workflows/test-build.yml

@@ -112,6 +112,9 @@ jobs:
       - name: Zustand v5 selector audit
         run: bun run check:zustand-v5
 
+      - name: React Query pattern audit
+        run: bun run check:react-query
+
       - name: Verify realtime prune graph
         run: bun run check:realtime-prune
 

README.md

@@ -21,18 +21,18 @@
   <a href="https://deepwiki.com/simstudioai/sim" target="_blank" rel="noopener noreferrer"><img src="https://deepwiki.com/badge.svg" alt="Ask DeepWiki"></a>  <a href="https://cursor.com/link/prompt?text=Help%20me%20set%20up%20Sim%20locally.%20Follow%20these%20steps%3A%0A%0A1.%20First%2C%20verify%20Docker%20is%20installed%20and%20running%3A%0A%20%20%20docker%20--version%0A%20%20%20docker%20info%0A%0A2.%20Clone%20the%20repository%3A%0A%20%20%20git%20clone%20https%3A%2F%2Fgithub.com%2Fsimstudioai%2Fsim.git%0A%20%20%20cd%20sim%0A%0A3.%20Start%20the%20services%20with%20Docker%20Compose%3A%0A%20%20%20docker%20compose%20-f%20docker-compose.prod.yml%20up%20-d%0A%0A4.%20Wait%20for%20all%20containers%20to%20be%20healthy%20(this%20may%20take%201-2%20minutes)%3A%0A%20%20%20docker%20compose%20-f%20docker-compose.prod.yml%20ps%0A%0A5.%20Verify%20the%20app%20is%20accessible%20at%20http%3A%2F%2Flocalhost%3A3000%0A%0AIf%20there%20are%20any%20errors%2C%20help%20me%20troubleshoot%20them.%20Common%20issues%3A%0A-%20Port%203000%2C%203002%2C%20or%205432%20already%20in%20use%0A-%20Docker%20not%20running%0A-%20Insufficient%20memory%20(needs%2012GB%2B%20RAM)%0A%0AFor%20local%20AI%20models%20with%20Ollama%2C%20use%20this%20instead%20of%20step%203%3A%0A%20%20%20docker%20compose%20-f%20docker-compose.ollama.yml%20--profile%20setup%20up%20-d"><img src="https://img.shields.io/badge/Set%20Up%20with-Cursor-000000?logo=cursor&logoColor=white" alt="Set Up with Cursor"></a>
 </p>
 
-### Build everything in Mothership
-Your AI command center. Describe what you want in plain language. Mothership knows your entire workspace and takes action: building agents, running them, querying data, and more.
+### Build everything in Chat
+Your AI command center. Describe what you want in plain language. Sim knows your entire workspace and takes action: building agents, running them, querying data, and more.
 
 <p align="center">
-  <img src="apps/sim/public/static/mothership.gif" alt="Mothership building and running an agent from chat" width="800"/>
+  <img src="apps/sim/public/static/mothership.gif" alt="Sim building and running an agent from chat" width="800"/>
 </p>
 
 ### Create files and documents
 Generate documents, reports, and presentations from a single prompt, grounded in your workspace data.
 
 <p align="center">
-  <img src="apps/sim/public/static/files.gif" alt="Mothership generating a document from a prompt" width="800"/>
+  <img src="apps/sim/public/static/files.gif" alt="Sim generating a document from a prompt" width="800"/>
 </p>
 
 ### Ground agents in your knowledge
@@ -50,7 +50,7 @@ A database, built in. Store, query, and wire structured data into agent runs.
 </p>
 
 ### Build visually with Workflows
-Prefer a canvas? Design agents block by block in the visual builder, and let Copilot generate blocks, wire variables, and fix errors from natural language.
+Prefer a canvas? Design agents block by block in the visual builder, and let Sim generate blocks, wire variables, and fix errors from natural language.
 
 <p align="center">
   <img src="apps/sim/public/static/workflow.gif" alt="Workflow builder demo" width="800"/>
@@ -138,11 +138,11 @@ bun run dev:full  # Starts Next.js app and realtime socket server
 
 Or run separately: `bun run dev` (Next.js) and `cd apps/sim && bun run dev:sockets` (realtime).
 
-## Copilot API Keys
+## Chat API Keys
 
-Copilot is a Sim-managed service. To use Copilot on a self-hosted instance:
+Chat is a Sim-managed service. To use Chat on a self-hosted instance:
 
-- Go to https://sim.ai → Settings → Copilot and generate a Copilot API key
+- Go to https://sim.ai → Settings → Chat keys and generate a Chat API key
 - Set `COPILOT_API_KEY` environment variable in your self-hosted apps/sim/.env file to that value
 
 ## Environment Variables