v0.8.19: desktop app upgrade flow improvements, monday.com OAuth fix

Author: waleedlatif1

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

@@ -15,23 +15,9 @@ When the user asks you to create a block:
 2. Configure all subBlocks with proper types, conditions, and dependencies
 3. Wire up tools correctly
 
-## Hard Rule: No Guessed Tool Outputs
+## No guessed tool outputs
 
-Blocks depend on tool outputs. If the underlying tool response schema is not documented or live-verified, you MUST tell the user instead of guessing block outputs.
-
-When block work changes tool execution, same-process work must use a registered
-`InternalToolConfig.operation`. Never add a Sim `/api/...` self-hop or the retired
-`directExecution` property.
-
-- Do NOT invent block outputs for undocumented tool responses
-- Do NOT describe unknown JSON shapes as if they were confirmed
-- Do NOT wire fields into the block just because they seem likely to exist
-
-If the tool outputs are not known, do one of these instead:
-1. Ask the user for sample tool responses
-2. Ask the user for test credentials so the tool responses can be verified
-3. Limit the block to operations whose outputs are documented
-4. Leave uncertain outputs out and explicitly tell the user what remains unknown
+Block outputs mirror tool outputs. When a tool's response schema is neither documented nor live-verified, don't infer field names or JSON shapes — ask the user for sample responses or test credentials, limit the block to operations whose outputs are documented, or leave the uncertain outputs out and say exactly what remains unknown.
 
 ## Block Configuration Structure
 
@@ -323,12 +309,10 @@ When several fields are mutually exclusive alternatives, mark them all `required
 "exactly one" at execution — a conditionally-required canonical pair rejects the workflow before the
 other paths ever get a chance to supply the value.
 
-**Critical constraints:**
-- `canonicalParamId` must NOT match any subblock's `id` in the same block
-- A canonical group is **block-wide**, not per-operation: `buildCanonicalIndex` keys groups by
-  `canonicalParamId` across every subblock, and a group has exactly one `basicId`. Two operations
-  that each need a file pair need two distinct `canonicalParamId` values.
-- All members of a group must share the same `required` status
+**Constraints (block-wide):**
+- `canonicalParamId` must not equal any subblock `id` in the block.
+- One canonical id links exactly one basic/advanced pair for one logical parameter. Groups are keyed by canonical id across every subblock and hold one `basicId`, so two operations that each need a pair need two canonical ids.
+- All members of a group share the same `required` status.
 
 ### Normalizing File Input in tools.config
 
@@ -548,12 +532,6 @@ Maps multiple UI fields to a single serialized parameter:
 - In advanced mode: `channelId` input value → `params.channel`
 - The serializer consolidates based on current mode
 
-**Critical constraints:**
-- `canonicalParamId` must NOT match any other subblock's `id` in the same block (causes conflicts)
-- A `canonicalParamId` links exactly one basic/advanced pair for a single logical parameter. Do NOT reuse the same `canonicalParamId` for different parameters, even under mutually-exclusive conditions/operations
-- ONLY use `canonicalParamId` to link basic/advanced mode alternatives for the same logical parameter
-- Do NOT use it for any other purpose
-
 ## WandConfig Pattern
 
 Enables AI-assisted field generation.
@@ -581,9 +559,9 @@ Enables AI-assisted field generation.
 - `'sql-query'` - SQL statements
 - `'timestamp'` - Adds current date/time context
 
-## Tools Configuration
+Use `wandConfig` on fields that are hard to fill by hand — timestamps (`generationType: 'timestamp'` injects the current date), comma-separated ID lists, complex query strings. Keep the prompt specific about the return format (e.g. 'Return ONLY the ISO 8601 timestamp string').
 
-**Important:** `tools.config.tool` runs during serialization before variable resolution. Put `Number()` and other type coercions in `tools.config.params` instead, which runs at execution time after variables are resolved.
+## Tools Configuration
 
 **Preferred:** Use tool names directly as dropdown option IDs to avoid switch cases:
 ```typescript
@@ -654,19 +632,12 @@ outputs: {
   // Use type: 'json' for complex objects or arrays (NOT type: 'array' with items)
   items: { type: 'json', description: 'List of items' },
   metadata: { type: 'json', description: 'Response metadata' },
-
-  // Nested outputs (for structured data)
-  user: {
-    id: { type: 'string', description: 'User ID' },
-    name: { type: 'string', description: 'User name' },
-    email: { type: 'string', description: 'User email' },
-  },
 }
 ```
 
 ### Typed JSON Outputs
 
-When using `type: 'json'` and you know the object shape in advance, **describe the inner fields in the description** so downstream blocks know what properties are available. Block outputs have no nested `properties` form — always keep the output flat and put the shape in the `description`:
+When using `type: 'json'` and you know the object shape in advance, **describe the inner fields in the description** so downstream blocks know what properties are available. Keep the output flat and put the shape in the `description`:
 
 ```typescript
 outputs: {
@@ -681,10 +652,6 @@ outputs: {
 }
 ```
 
-Nested object outputs (`plan: { id: { type: 'string' }, ... }`) are a **tool-output** feature only — `OutputFieldDefinition` for blocks does not allow them and they fail TypeScript at build time.
-
-If the output shape is unknown because the underlying tool response is undocumented, you MUST tell the user and stop. Unknown is not the same as variable. Never guess block outputs.
-
 ## V2 Block Pattern
 
 When creating V2 blocks (alongside legacy V1):
@@ -727,7 +694,7 @@ export const ServiceV2Block: BlockConfig = {
 
 ## Registering Blocks
 
-After creating the block, remind the user to register it in `apps/sim/blocks/registry-maps.ts` (the data maps live here; `registry.ts` holds only the accessor functions). Add the import and an entry to each map alphabetically:
+Register the block in `apps/sim/blocks/registry-maps.ts` — add the import and an entry to each map alphabetically:
 
 ```typescript
 import { ServiceBlock, ServiceBlockMeta } from '@/blocks/blocks/service'
@@ -887,41 +854,6 @@ Optional fields that are rarely used should be set to `mode: 'advanced'` so they
 }
 ```
 
-## WandConfig for Complex Inputs
-
-Use `wandConfig` for fields that are hard to fill out manually, such as timestamps, comma-separated lists, and complex query strings. This gives users an AI-assisted input experience.
-
-```typescript
-// Timestamps - use generationType: 'timestamp' to inject current date context
-{
-  id: 'startTime',
-  title: 'Start Time',
-  type: 'short-input',
-  mode: 'advanced',
-  wandConfig: {
-    enabled: true,
-    prompt: 'Generate an ISO 8601 timestamp based on the user description. Return ONLY the timestamp string.',
-    generationType: 'timestamp',
-  },
-}
-
-// Comma-separated lists - simple prompt without generationType
-{
-  id: 'mediaIds',
-  title: 'Media IDs',
-  type: 'short-input',
-  mode: 'advanced',
-  wandConfig: {
-    enabled: true,
-    prompt: 'Generate a comma-separated list of media IDs. Return ONLY the comma-separated values.',
-  },
-}
-```
-
-## Naming Convention
-
-All tool IDs referenced in `tools.access` and returned by `tools.config.tool` MUST use `snake_case` (e.g., `x_create_tweet`, `slack_send_message`). Never use camelCase or PascalCase.
-
 ## BlockMeta (Required)
 
 Every block file must export a `{Service}BlockMeta` alongside the block — **minimum 7 templates**. Look at existing examples in `apps/sim/blocks/blocks/` (e.g. `browser_use.ts`, `google_sheets.ts`) for the pattern.
@@ -998,7 +930,7 @@ bun run apps/sim/scripts/check-canvas-sentences.ts --block={service}
 Adding a block on its own needs no **tool metadata** regeneration — a block references existing
 tool IDs through `tools.access` and does not change any tool's shape.
 
-But if the same change also adds, edits **or removes** a tool, run `bun run tool-metadata:generate` and commit the result, or CI fails on stale artifacts. That matters here because a block's `outputs` are authored to match its tools' outputs, and the UI now reads those from the generated metadata rather than the executable registry — an unregenerated tool change makes the block's outputs disagree with what the panel renders. See `.agents/skills/tool-registry-boundary/SKILL.md`.
+But if the same change also adds, edits **or removes** a tool, run `bun run tool-metadata:generate` and commit the result, or CI fails on stale artifacts. That matters here because a block's `outputs` are authored to match its tools' outputs, and the UI reads those from the generated metadata, not the executable registry — an unregenerated tool change makes the block's outputs disagree with what the panel renders. See `.agents/skills/tool-registry-boundary/SKILL.md`.
 
 A visible integration block does require the generated integration catalog and docs to be refreshed.
 After adding or changing one, run:
@@ -1052,9 +984,9 @@ changes.
 
 ## Final Validation (Required)
 
-After creating the block, you MUST validate it against every tool it references:
+Validate the block against every tool in `tools.access`:
 
-1. **Read every tool definition** that appears in `tools.access` — do not skip any
+1. **Read each tool definition** in `tools.access`
 2. **For each tool, verify the block has correct:**
    - SubBlock inputs that cover all required tool params (with correct `condition` to show for that operation)
    - SubBlock input types that match the tool param types (e.g., dropdown for enums, short-input for strings)
@@ -1063,11 +995,11 @@ After creating the block, you MUST validate it against every tool it references:
 3. **Verify block outputs** cover the key fields returned by all tools
 4. **Verify conditions** — each subBlock should only show for the operations that actually use it
 5. **Verify `{Service}BlockMeta` is exported** with at least 7 templates, each having `icon`, `title`, `prompt`, `modules`, `category`, and `tags`
-6. **If any tool outputs are still unknown**, explicitly tell the user instead of guessing block outputs
+6. **List any tool outputs still unknown** rather than guessing block outputs
 7. **Verify the tool execution boundary** — blocks never create or call API routes. Every referenced
    tool must already be either a registered `InternalToolConfig.operation` or an absolute external
-   HTTP(S) `ToolConfig.request`. If transport needs to change, use the `add-tools` skill; do not add a
-   same-origin `/api/...` hop from the block.
+   HTTP(S) `ToolConfig.request`. If transport needs to change, use the `add-tools` skill; never add a
+   same-origin `/api/...` hop or a `directExecution` property from the block.
 
 ## Option Lists: `selectorKey` or `options`, never a per-block fetcher
 
@@ -1103,7 +1035,7 @@ options: (params) => {
 }
 ```
 
-**Never fetch inside `options`, and never reach into the stores from a block definition.** A fetcher that resolves its credential with `readSubBlockValue(blockId, ...)` only works on the canvas — every surface that is not the editor gets an empty list. `fetchOptions`/`fetchOptionById` were removed for exactly this reason.
+**Never fetch inside `options`, and never reach into the stores from a block definition.** A fetcher that resolves its credential with `readSubBlockValue(blockId, ...)` only works on the canvas — every surface that is not the editor gets an empty list.
 
 Two rules the checks enforce:
 

.agents/skills/add-column-type/SKILL.md

@@ -8,7 +8,7 @@ argument-hint: <type-name>
 
 A column type is **one file** in `apps/sim/lib/table/column-types/` plus a registry entry. Everything that varies per type — label, icon, storage cast, coercion, validation, conversion compatibility, formatting, editor, filter operators — lives on that one object, so no consumer needs editing.
 
-This was not always true: adding `currency` originally took ~40 edits across 32 `switch` arms and 26 UI branches, each of which failed **silently** when missed. The registry exists to make that impossible, so the rule is absolute: **if you find yourself adding a `case 'yourtype':` anywhere outside `column-types/`, the registry is missing a field. Add the field instead.**
+A `case 'yourtype':` outside `column-types/` fails **silently** when missed (a wrong `jsonbCast` breaks every filter on the column). The registry exists to make that impossible, so the rule is absolute with one documented exception (`import.ts`'s `coerceValue`, see "Traps" below): **if you find yourself adding a `case 'yourtype':` anywhere else outside `column-types/`, the registry is missing a field. Add the field instead.**
 
 ## Hard Rule: the compiler tells you what to do
 
@@ -116,9 +116,9 @@ Prefer set-based SQL. When the transform genuinely needs JS (`currency`'s separa
 
 ## Watch out
 
-- **Import cycles.** `column-types/select.ts` imports `select-values.ts`, so `select-values.ts` must **not** import the registry — that closes a cycle and fails at module init. Inside a type's own helper module the string literal is the implementation, not a config leak.
+- **Import cycles.** `column-types/select.ts` imports `lib/table/select-values.ts`, so `select-values.ts` must **not** import the registry — that closes a cycle and fails at module init. Inside a type's own helper module the string literal is the implementation, not a config leak.
 - **The client-safe boundary.** `registry.ts` and everything it imports must stay free of `@sim/db`, `drizzle-orm`, and `next/server` — the tables grid imports it directly. A React icon is fine (it's a component *reference*, never called server-side). Only `registry.server.ts` may touch drizzle.
-- **Don't re-export the registry from `@/lib/table`.** 44 server modules import that barrel; routing this through it pulls `@sim/emcn/icons` into all of them. Deep-import `@/lib/table/column-types`.
+- **Don't re-export the registry from `@/lib/table`.** Dozens of server modules import that barrel; routing this through it pulls `@sim/emcn/icons` into all of them. Deep-import `@/lib/table/column-types`.
 - **`import.ts`'s `coerceValue` is a SECOND write path and is not opt-in.** Importing into a column of your type always hits it, and its `default` arm silently `String(value)`s — so a missing `case` stores text in a column whose `jsonbCast` is numeric, and then every filter and sort on that column errors in Postgres. Add a `case`, even though the switch compiles without one. (It is deliberately separate from the registry's `coerce`: an import wants an unparseable value to survive as its raw string so the row error can name it.)
 - **CSV inference** is an ordered heuristic in `import.ts`, deliberately not registry-driven. A new type is not inferred from a CSV unless you extend `inferColumnType` — usually you should not, since inference cannot supply configuration (an option set, a currency code).
 

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

@@ -469,7 +469,7 @@ The assigned mapping (`semantic id → slot`) is stored in `sourceConfig.tagSlot
 
 ## `@/connectors/utils` Helpers
 
-Reuse these instead of inlining the same logic (the validator enforces them):
+Reuse these instead of inlining the same logic:
 
 - `htmlToPlainText(html)` — strip HTML to plain text before indexing `ExternalDocument.content`. Never index raw HTML.
 - `computeContentHash(content)` — stable content hash for change detection.
@@ -538,7 +538,7 @@ If `ExternalDocument.sourceUrl` is set, the sync engine stores it on the documen
 
 If `listDocuments` can ever return **less than the full source set** on a non-incremental sync — a `maxItems`/`maxDocuments`-style cap, or a transient per-item error that drops a still-existing document from the listing — it MUST set `syncContext.listingCapped = true` when that happens.
 
-The sync engine reconciles deletions by comparing the full listing against stored documents: anything not seen is **hard-deleted** (sync-engine.ts, gated on `!syncContext?.listingCapped`). A truncated listing without this flag deletes every real document beyond the cap. This was the single most common bug found when auditing connectors — do not omit it.
+The sync engine reconciles deletions by comparing the full listing against stored documents (`shouldReconcileDeletions` in `lib/knowledge/connectors/sync-engine.ts`, gated on `!syncContext?.listingCapped`). Anything not seen is tombstoned on that sync and hard-deleted when the next sync still does not see it — so a truncated listing without this flag eventually removes every real document beyond the cap.
 
 ```typescript
 if (hitLimit && syncContext) {
@@ -565,7 +565,7 @@ You never need to modify the sync engine when adding a connector.
 
 ## Icon
 
-The `icon` field on `ConnectorConfig` is used throughout the UI — in the connector list, the add-connector modal, and as the document icon in the knowledge base table (replacing the generic file type icon for connector-sourced documents). The icon is read from `CONNECTOR_REGISTRY[connectorType].icon` at runtime — no separate icon map to maintain.
+The `icon` field on `ConnectorConfig` is used throughout the UI — in the connector list, the add-connector modal, and as the document icon in the knowledge base table (replacing the generic file type icon for connector-sourced documents). The icon is read from `CONNECTOR_META_REGISTRY[connectorType].icon` (the client-safe registry) at runtime — no separate icon map to maintain.
 
 If the service already has an icon in `apps/sim/components/icons.tsx` (from a tool integration), reuse it. Otherwise, ask the user to provide the SVG.
 
@@ -602,7 +602,8 @@ export const CONNECTOR_META_REGISTRY: ConnectorMetaRegistry = {
 - **OAuth + contentDeferred**: `apps/sim/connectors/google-drive/google-drive.ts` — file download with metadata-based hash, `orderBy` for deterministic pagination
 - **OAuth + contentDeferred (blocks API)**: `apps/sim/connectors/notion/notion.ts` — complex block content extraction deferred to `getDocument`
 - **OAuth + contentDeferred (git)**: `apps/sim/connectors/github/github.ts` — blob SHA hash, tree listing
-- **OAuth + inline content**: `apps/sim/connectors/confluence/confluence.ts` — multiple config field types, `mapTags`, label fetching
+- **OAuth + inline content**: `apps/sim/connectors/slack/slack.ts` — list API returns message content inline, metadata-derived `contentHash`
+- **OAuth + contentDeferred + config fields**: `apps/sim/connectors/confluence/confluence.ts` — multiple config field types, `mapTags`, label fetching
 - **API key**: `apps/sim/connectors/fireflies/fireflies.ts` — GraphQL API with Bearer token auth
 
 ## Checklist