@@ -41,7 +41,7 @@ A revealed block that is not globally GA (`enabled !== true`, or env-revealed) r
    - GA via config (code cleanup pending): `{ "enabled": true }` — suffix disappears everywhere within ~30s (AppConfig TTL) + client refetch.
 
    Same runbook as `feature-flags`: edit the hosted document, `aws appconfig start-deployment` with the `sim-<env>-fast` strategy (see the infra README).
-5. **GA cleanup:** delete `preview: true` from the block (now visible to self-hosters on their next upgrade), add its `BlockMeta` + regen docs, and drop the AppConfig entry. For a v2 upgrade, this is also when v1 gets `hideFromToolbar: true` (the superseded-version paradigm).
+5. **GA cleanup:** delete `preview: true` from the block (now visible to self-hosters on their next upgrade), add its `BlockMeta` + regen docs, and drop the AppConfig entry. For a v2 upgrade, this is also when v1 gets `hideFromToolbar: true` **and** `sunset: { status: 'legacy', replacedBy: '<v2-type>' }` (the superseded-version paradigm). Both edits must land in the **same commit** as the `preview: true` removal — `check-block-registry` fails a sunset block whose `replacedBy` is still `preview`, so splitting them breaks the build in between. Also move the block's `BLOCK_DISPLAY_WORKFLOWS` entry (`apps/docs/components/workflow-preview/block-display-workflows.ts`) to the new type, or `BlockPreview` silently renders nothing on the docs page.
 
 ## Kill switch (shipped blocks)
 
 
@@ -19,6 +19,10 @@ When the user asks you to create a block:
 
 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
@@ -203,6 +207,7 @@ silently available.
   id: 'channel',
   title: 'Channel',
   type: 'channel-selector',
+  selectorKey: '{service}.channels',
   serviceId: '{service}',
   placeholder: 'Select channel',
   dependsOn: ['credential'],
@@ -213,6 +218,7 @@ silently available.
   id: 'project',
   title: 'Project',
   type: 'project-selector',
+  selectorKey: '{service}.projects',
   serviceId: '{service}',
   dependsOn: ['credential'],
 }
@@ -222,6 +228,7 @@ silently available.
   id: 'file',
   title: 'File',
   type: 'file-selector',
+  selectorKey: '{service}.files',
   serviceId: '{service}',
   mimeType: 'application/pdf',
   dependsOn: ['credential'],
@@ -232,6 +239,7 @@ silently available.
   id: 'user',
   title: 'User',
   type: 'user-selector',
+  selectorKey: '{service}.users',
   serviceId: '{service}',
   dependsOn: ['credential'],
 }
@@ -687,6 +695,10 @@ export const ServiceBlock: BlockConfig = {
   type: 'service',
   name: 'Service (Legacy)',
   hideFromToolbar: true,  // Hide from toolbar
+  // Required: drives the amber legacy badge and its click-to-upgrade action.
+  // `check-block-registry` fails a legacy block with no `replacedBy`, one whose
+  // target does not exist, or one whose target is itself sunset or still `preview`.
+  sunset: { status: 'legacy', replacedBy: 'service_v2' },
   // ... rest of config
 }
 
@@ -1052,12 +1064,20 @@ After creating the block, you MUST validate it against every tool it references:
 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
+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.
 
 ## Option Lists: `selectorKey` or `options`, never a per-block fetcher
 
 A sub-block gets its choices from exactly one of two places. There is no third.
 
-**`selectorKey` — every remote list.** Register the list in `hooks/selectors/providers/<service>/selectors.ts`, add its key to `SelectorKey`, and point the sub-block at it. A selector is parameterized by an explicit `SelectorContext`, so the same definition serves the canvas, the workspace-fork sync modal, and anything added later.
+**`selectorKey` — every remote list.** Use the `add-selector` skill to add browser-safe metadata in
+`apps/sim/lib/selectors/manifest.ts`. Attach `provider-server` selectors under
+`apps/sim/lib/selectors/server/providers/` and `internal-server` selectors in
+`apps/sim/lib/selectors/server/internal.ts`. Point the sub-block at that key. All remote selectors
+execute through `selectors.execute`; never add a client provider module or selector-only fetch route.
 
 ```ts
 { id: 'triggerCredentials', type: 'oauth-input', canonicalParamId: 'oauthCredential', mode: 'trigger' },
@@ -1066,7 +1086,13 @@ A sub-block gets its choices from exactly one of two places. There is no third.
 { id: 'manualLabelIds', type: 'short-input', mode: 'trigger-advanced' },
 ```
 
-`canonicalParamId: 'oauthCredential'` on the credential sub-block is the line people forget. `buildSelectorContextFromBlock` keys the context on a sub-block's CANONICAL id, so without it `context.oauthCredential` is never set and the picker looks unfixable without reading the store. (A credential field is also recognised by its `oauth-input` TYPE as a fallback, so a block whose shipped param is already named something else does not have to rename it.)
+`canonicalParamId: 'oauthCredential'` on the credential sub-block is the line people forget. The
+shared context builder projects only active `dependsOn` values and keys canonical pairs by their
+canonical id. Exact environment references such as `{{GMAIL_CREDENTIAL_ID}}` stay unresolved in the
+browser and are resolved only by the authorized server executor. The builder does not infer a
+nonstandard credential id from `type: 'oauth-input'`; give it
+`canonicalParamId: 'oauthCredential'`, or declare an explicit manifest `sourceFields` alias when a
+legacy source id must be retained.
 
 **`options` — everything else.** A static array, or a pure function of the block's own values for a list that narrows to a sibling's selection. No I/O.
 
@@ -1081,5 +1107,6 @@ options: (params) => {
 
 Two rules the checks enforce:
 
-- **A secret never enters a selector's `getQueryKey`.** A query key identifies a resource; a credential authorizes access to it. A credential *id* is fine; a typed password is not (see `imap.mailboxes`).
+- **Selector query keys contain no context values.** This includes credential IDs, raw secrets,
+  unresolved references, and hashes of those values; the shared facade uses an opaque local revision.
 - **A sub-block that `dependsOn` a credential / knowledge-base / table selector must be reconfigurable at fork-sync time** — a `selectorKey`, a canonical pair whose basic member is a selector, or a `short-input`/`long-input`. `bun run check:fork-dependent-coverage` fails otherwise, because a fork sync clears those fields on every push and an unofferable one can never be set anywhere that sticks.
@@ -149,7 +149,7 @@ Registering the *type* is compiler-enforced. Registering its *metadata* is not,
 - [ ] `migrateCellsTo` / `migrateCellsFrom` added if the stored bytes change
 - [ ] New metadata keys added to `TYPE_SPECIFIC_COLUMN_KEYS` + `FOREIGN_METADATA_VERB`
 - [ ] Unit tests for `coerce` / `isCompatibleWith` round-trips, verified to fail without the code
-- [ ] Docs row added to `apps/docs/content/docs/en/tables/index.mdx`
+- [ ] Docs row added to `apps/docs/content/docs/tables/index.mdx`
 
 ## Final Validation (Required)
 
 
@@ -197,7 +197,14 @@ Three field types are supported: `short-input`, `dropdown`, and `selector`.
 
 ## Dynamic Selectors (Canonical Pairs)
 
-Use `type: 'selector'` to fetch options dynamically from the existing selector registry (`hooks/selectors/registry.ts`). Selectors are always paired with a manual fallback input using the **canonical pair** pattern — a `selector` field (basic mode) and a `short-input` field (advanced mode) linked by `canonicalParamId`.
+Use `type: 'selector'` for a key declared in the browser-safe selector manifest at
+`apps/sim/lib/selectors/manifest.ts`. Remote selectors execute through the authorized
+`selectors.execute` server operation and a server attachment; connectors never call providers or
+resolve credentials in the browser. Apply the `add-selector` skill when the key does not exist.
+
+Selectors are paired with a manual fallback input using the **canonical pair** pattern — a
+`selector` field (basic mode) and a `short-input` field (advanced mode) linked by
+`canonicalParamId`.
 
 The user sees a toggle button (ArrowLeftRight) to switch between the selector dropdown and manual text input. On submit, the modal resolves each canonical pair to the active mode's value, keyed by `canonicalParamId`.
 
@@ -217,7 +224,7 @@ configFields: [
     id: 'baseSelector',
     title: 'Base',
     type: 'selector',
-    selectorKey: 'airtable.bases',     // Must exist in hooks/selectors/registry.ts
+    selectorKey: 'airtable.bases',     // Must exist in lib/selectors/manifest.ts
     canonicalParamId: 'baseId',
     mode: 'basic',
     placeholder: 'Select a base',
@@ -260,7 +267,9 @@ configFields: [
 
 ### Selector with domain dependency (Jira/Confluence pattern)
 
-When a selector depends on a plain `short-input` field (no canonical pair), `dependsOn` references that field's `id` directly. The `domain` field's value maps to `SelectorContext.domain` automatically via `SELECTOR_CONTEXT_FIELDS`.
+When a selector depends on a plain `short-input` field (no canonical pair), `dependsOn` references
+that field's `id` directly. Exact references such as `{{JIRA_DOMAIN}}` remain unresolved in the
+browser and are resolved only after workspace authorization on the server.
 
 ```typescript
 configFields: [
@@ -296,16 +305,16 @@ configFields: [
 
 ### How `dependsOn` maps to `SelectorContext`
 
-The connector selector field builds a `SelectorContext` from dependency values. For the mapping to work, each dependency's `canonicalParamId` (or field `id` for non-canonical fields) must exist in `SELECTOR_CONTEXT_FIELDS` (`lib/workflows/subblocks/context.ts`):
-
-```
-oauthCredential, domain, teamId, projectId, knowledgeBaseId, planId,
-siteId, collectionId, spreadsheetId, fileId, baseId, datasetId, serviceDeskId
-```
+The shared connector context builder projects only active dependencies. A canonical dependency uses
+its active basic or advanced value under `canonicalParamId`; a non-canonical dependency uses its
+field `id`. The resulting key must be a `SelectorContextKey` in
+`apps/sim/lib/selectors/types.ts` and must be explicitly allowed by that selector's manifest entry.
+The browser sends the connector's workspace scope, not the complete connector configuration.
 
 ### Available selector keys
 
-Check `hooks/selectors/types.ts` for the full `SelectorKey` union. Common ones for connectors:
+Check `apps/sim/lib/selectors/manifest.ts` for the exhaustive selector keys. Common ones for
+connectors:
 
 | SelectorKey | Context Deps | Returns |
 |-------------|-------------|---------|
@@ -607,9 +616,13 @@ export const CONNECTOR_META_REGISTRY: ConnectorMetaRegistry = {
 - [ ] **Selector fields configured correctly (if applicable):**
   - Every `type: 'selector'` field has a canonical pair (`short-input` or `dropdown` with same `canonicalParamId` and `mode: 'advanced'`)
   - `required` is identical on both fields in each canonical pair
-  - `selectorKey` exists in `hooks/selectors/registry.ts`
+  - `selectorKey` exists in `apps/sim/lib/selectors/manifest.ts`
   - `dependsOn` references selector field IDs (not `canonicalParamId`)
-  - Dependency `canonicalParamId` values exist in `SELECTOR_CONTEXT_FIELDS`
+  - Each projected dependency key is a `SelectorContextKey` allowed by the selector manifest
+  - Every remote key has one server attachment with credential provider binding and a reviewed
+    `fixed`, `credential-bound`, or `user-controlled` destination policy
+  - No connector selector adds a client provider module, browser token request, or selector-only
+    API route
 - [ ] `listDocuments` handles pagination with metadata-based content hashes
 - [ ] `syncContext.listingCapped = true` set whenever the listing is truncated (max-items cap or transient per-item error) — required to prevent the engine's deletion reconciliation from removing unseen documents
 - [ ] `contentDeferred: true` used if content requires per-doc API calls (file download, export, blocks fetch)