[LUM-1517] Widen VDropdown menu to match trigger width, auto-select auth type per provider#30408
Merged
Jasonnnz merged 3 commits intoMay 12, 2026
Merged
Conversation
…uth type per provider VDropdown menu now defaults to the trigger's rendered width instead of a fixed 180px, so labels like 'Platform (managed by Vellum)' are no longer truncated. Callers that pass an explicit menuWidth continue to work. In the New Connection form, selecting Ollama auto-sets auth to 'none' and hides other options. Fireworks and OpenRouter only show 'API Key' since they don't support managed keys. Anthropic, OpenAI, and Gemini show both 'API Key' and 'Platform'. Switching providers resets auth type when the current selection isn't valid for the new provider. Part of LUM-1517 Co-Authored-By: Jason Zhou <jasonczhou3@gmail.com>
Contributor
🤖 Devin AI EngineerI'll be helping with this pull request! Here's what you should know: ✅ I will automatically:
Note: I can only respond to comments from users who have write access to this repository. ⚙️ Control Options:
|
![devin-ai-integration[bot]](https://avatars.githubusercontent.com/in/811515?s=60&v=4){kind=small}
Comment on lines
+493
to
+505
| private var authTypeOptions: [(label: String, value: String)] { | ||
| let provider = editorDraft.provider | ||
| if provider == "ollama" { | ||
| return [(label: "None (no credentials)", value: "none")] | ||
| } | ||
| var options: [(label: String, value: String)] = [ | ||
| (label: "API Key", value: "api_key"), | ||
| ] | ||
| if store.isManagedCapable(provider) { | ||
| options.append((label: "Platform (managed by Vellum)", value: "platform")) | ||
| } | ||
| return options | ||
| } |
Contributor
There was a problem hiding this comment.
🟡 Auth type dropdown loses current selection for existing non-ollama connections with auth type "none"
The new authTypeOptions computed property only includes "none" for the "ollama" provider. Previously, all providers offered "None (no credentials)" in the dropdown. If a user previously created a non-ollama connection with auth type "none" (which was allowed by the old UI), opening that connection in the editor via beginEdit (ProvidersSheet.swift:797) sets editorDraft.authType = conn.auth.type (i.e., "none"), but the dropdown options won't contain "none". The VDropdown's selectedLabel (VDropdown.swift:110-111) returns nil because no option matches, causing the dropdown to display the placeholder "Select auth type…" instead of the current value. This is confusing: the user may think no auth type is configured and inadvertently switch to "api_key" (which then demands an API key they may not have). While saving without touching the dropdown preserves the correct "none" auth type, the misleading display risks accidental misconfiguration.
Prompt for agents
The authTypeOptions computed property (ProvidersSheet.swift:493-505) restricts the 'None' auth option to only the 'ollama' provider. However, existing non-ollama connections may already have auth type 'none' (since the old UI allowed it for all providers). When editing such a connection, the VDropdown selection won't match any option, showing a confusing placeholder instead of the current value.
Possible fixes:
1. When in edit mode (not create), include the connection's current auth type in the options even if it wouldn't normally be available for that provider. This ensures the dropdown displays the current value.
2. Add a migration or fixup that converts existing non-ollama 'none' auth connections to a valid auth type.
3. Add a 'None' option to the options list when editorDraft.authType is already 'none' regardless of provider, e.g.:
if editorDraft.authType == "none" { options.append((label: "None (no credentials)", value: "none")) }
The same concern applies to 'platform' auth type on non-managed-capable providers, though that scenario is less likely to occur in practice.
Was this helpful? React with 👍 or 👎 to provide feedback.
Contributor
There was a problem hiding this comment.
Good catch — fixed in 94459f6. When editing an existing connection, the dropdown now includes the current auth type even if it wouldn't normally be offered for that provider. This prevents the confusing placeholder display for legacy non-ollama connections with "none" auth (and similarly for "platform" on non-managed providers). Applied the same fix to the web PR as well.
When editing an existing connection whose auth type is no longer offered for new connections (e.g. a non-ollama connection with 'none' auth), include it in the dropdown so the user sees the saved value instead of a confusing placeholder. Co-Authored-By: Jason Zhou <jasonczhou3@gmail.com>
Uses VButton with iconOnly VIcon.x, matching the pattern in InferenceProfilesSheet and other panel headers. Co-Authored-By: Jason Zhou <jasonczhou3@gmail.com>
credence-the-bot Bot
pushed a commit
that referenced
this pull request
May 12, 2026
PR #30408 (Jason / LUM-1517) shipped the UX fix on macOS: hide the Platform auth-type option for providers without a managed proxy route. It does so via `store.isManagedCapable(provider)` which until now was a hardcoded `Set<String>("anthropic", "openai", "gemini")` on SettingsStore — with a docstring that explicitly calls out 'Mirrors the `MANAGED_PROVIDER_META` table in the backend.' That's a drift hazard: adding a managed provider in the proxy routing table doesn't propagate to the UI gate. This PR closes the loop by making the catalog the source of truth. Changes ------- * assistant/src/providers/model-catalog.ts — add `supportsManagedAuth?: boolean` to ProviderCatalogEntry, derived from `MANAGED_PROVIDER_META[entry.id]?.managed === true` at PROVIDER_CATALOG build time. The two can no longer drift. * assistant/scripts/sync-llm-catalog.ts — project the field through to the client-facing JSON. Re-generated both copies (meta/ + clients/shared/Resources/). * assistant/src/__tests__/llm-catalog-parity.test.ts — parity assertion + a focused invariant test guarding against future hand-edits drifting from MANAGED_PROVIDER_META. * clients/shared/Utilities/LLMProviderRegistry.swift — decode the field on `LLMProviderEntry` (optional, defaults to nil for forward-compat with older catalog versions). * clients/macos/.../SettingsStore.swift — refactor `isManagedCapable(_:)` and `managedCapableProviders` to read the flag from `LLMProviderRegistry` instead of the hardcoded set. The wire-protocol `ProviderCatalogEntry` doesn't carry capability flags, so we read from the static registry to keep the answer stable across daemon `model_info` refreshes. Behavior parity --------------- The existing 7 isManagedCapable tests + 2 managedCapableProviders tests in SettingsStoreManagedInferenceSelectionTests all continue to pass — anthropic/openai/gemini → true, ollama/fireworks/openrouter → false, unknown → false. Same truth table, different source. Not in this PR -------------- * macOS auth-type dropdown filtering — already shipped in #30408. * Web modal parity — separate vellum-assistant-platform PR. * Rename "managed" → "platform" terminology — Noa-tracked follow-up after this lands. Test ---- * `bun test src/__tests__/llm-catalog-parity.test.ts` — 14/14 pass. * Daemon lint clean (`bun run lint`).
noanflaherty
pushed a commit
that referenced
this pull request
May 12, 2026
PR #30408 (Jason / LUM-1517) shipped the UX fix on macOS: hide the Platform auth-type option for providers without a managed proxy route. It does so via `store.isManagedCapable(provider)` which until now was a hardcoded `Set<String>("anthropic", "openai", "gemini")` on SettingsStore — with a docstring that explicitly calls out 'Mirrors the `MANAGED_PROVIDER_META` table in the backend.' That's a drift hazard: adding a managed provider in the proxy routing table doesn't propagate to the UI gate. This PR closes the loop by making the catalog the source of truth. Changes ------- * assistant/src/providers/model-catalog.ts — add `supportsManagedAuth?: boolean` to ProviderCatalogEntry, derived from `MANAGED_PROVIDER_META[entry.id]?.managed === true` at PROVIDER_CATALOG build time. The two can no longer drift. * assistant/scripts/sync-llm-catalog.ts — project the field through to the client-facing JSON. Re-generated both copies (meta/ + clients/shared/Resources/). * assistant/src/__tests__/llm-catalog-parity.test.ts — parity assertion + a focused invariant test guarding against future hand-edits drifting from MANAGED_PROVIDER_META. * clients/shared/Utilities/LLMProviderRegistry.swift — decode the field on `LLMProviderEntry` (optional, defaults to nil for forward-compat with older catalog versions). * clients/macos/.../SettingsStore.swift — refactor `isManagedCapable(_:)` and `managedCapableProviders` to read the flag from `LLMProviderRegistry` instead of the hardcoded set. The wire-protocol `ProviderCatalogEntry` doesn't carry capability flags, so we read from the static registry to keep the answer stable across daemon `model_info` refreshes. Behavior parity --------------- The existing 7 isManagedCapable tests + 2 managedCapableProviders tests in SettingsStoreManagedInferenceSelectionTests all continue to pass — anthropic/openai/gemini → true, ollama/fireworks/openrouter → false, unknown → false. Same truth table, different source. Not in this PR -------------- * macOS auth-type dropdown filtering — already shipped in #30408. * Web modal parity — separate vellum-assistant-platform PR. * Rename "managed" → "platform" terminology — Noa-tracked follow-up after this lands. Test ---- * `bun test src/__tests__/llm-catalog-parity.test.ts` — 14/14 pass. * Daemon lint clean (`bun run lint`). Co-authored-by: credence-the-bot <credence-the-bot@users.noreply.github.com>
vellum-apollo-bot Bot
pushed a commit
that referenced
this pull request
May 12, 2026
…uth type per provider (#30408) * [LUM-1517] Widen VDropdown menu to match trigger width, auto-select auth type per provider VDropdown menu now defaults to the trigger's rendered width instead of a fixed 180px, so labels like 'Platform (managed by Vellum)' are no longer truncated. Callers that pass an explicit menuWidth continue to work. In the New Connection form, selecting Ollama auto-sets auth to 'none' and hides other options. Fireworks and OpenRouter only show 'API Key' since they don't support managed keys. Anthropic, OpenAI, and Gemini show both 'API Key' and 'Platform'. Switching providers resets auth type when the current selection isn't valid for the new provider. Part of LUM-1517 Co-Authored-By: Jason Zhou <jasonczhou3@gmail.com> * Preserve current auth type in edit-mode dropdown options When editing an existing connection whose auth type is no longer offered for new connections (e.g. a non-ollama connection with 'none' auth), include it in the dropdown so the user sees the saved value instead of a confusing placeholder. Co-Authored-By: Jason Zhou <jasonczhou3@gmail.com> * Replace Cancel text with ghost close icon in editor header Uses VButton with iconOnly VIcon.x, matching the pattern in InferenceProfilesSheet and other panel headers. Co-Authored-By: Jason Zhou <jasonczhou3@gmail.com> --------- Co-authored-by: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com>
vellum-apollo-bot Bot
pushed a commit
that referenced
this pull request
May 12, 2026
PR #30408 (Jason / LUM-1517) shipped the UX fix on macOS: hide the Platform auth-type option for providers without a managed proxy route. It does so via `store.isManagedCapable(provider)` which until now was a hardcoded `Set<String>("anthropic", "openai", "gemini")` on SettingsStore — with a docstring that explicitly calls out 'Mirrors the `MANAGED_PROVIDER_META` table in the backend.' That's a drift hazard: adding a managed provider in the proxy routing table doesn't propagate to the UI gate. This PR closes the loop by making the catalog the source of truth. Changes ------- * assistant/src/providers/model-catalog.ts — add `supportsManagedAuth?: boolean` to ProviderCatalogEntry, derived from `MANAGED_PROVIDER_META[entry.id]?.managed === true` at PROVIDER_CATALOG build time. The two can no longer drift. * assistant/scripts/sync-llm-catalog.ts — project the field through to the client-facing JSON. Re-generated both copies (meta/ + clients/shared/Resources/). * assistant/src/__tests__/llm-catalog-parity.test.ts — parity assertion + a focused invariant test guarding against future hand-edits drifting from MANAGED_PROVIDER_META. * clients/shared/Utilities/LLMProviderRegistry.swift — decode the field on `LLMProviderEntry` (optional, defaults to nil for forward-compat with older catalog versions). * clients/macos/.../SettingsStore.swift — refactor `isManagedCapable(_:)` and `managedCapableProviders` to read the flag from `LLMProviderRegistry` instead of the hardcoded set. The wire-protocol `ProviderCatalogEntry` doesn't carry capability flags, so we read from the static registry to keep the answer stable across daemon `model_info` refreshes. Behavior parity --------------- The existing 7 isManagedCapable tests + 2 managedCapableProviders tests in SettingsStoreManagedInferenceSelectionTests all continue to pass — anthropic/openai/gemini → true, ollama/fireworks/openrouter → false, unknown → false. Same truth table, different source. Not in this PR -------------- * macOS auth-type dropdown filtering — already shipped in #30408. * Web modal parity — separate vellum-assistant-platform PR. * Rename "managed" → "platform" terminology — Noa-tracked follow-up after this lands. Test ---- * `bun test src/__tests__/llm-catalog-parity.test.ts` — 14/14 pass. * Daemon lint clean (`bun run lint`). Co-authored-by: credence-the-bot <credence-the-bot@users.noreply.github.com>
dvargasfuertes
pushed a commit
that referenced
this pull request
May 12, 2026
* fix(macos): hide redundant default Provider picker on Language Model card (#30413) * fix(macos): hide redundant default Provider picker on Language Model card Profiles already carry the provider they dispatch against — surfacing a separate "default Provider" picker on the Language Model card lets users land in nonsensical states (e.g. Provider: Anthropic + Profile: Kimi K2.5 on Fireworks). v0.8.0 hid the picker behind the inference-mode toggle; when that toggle was dropped in #30231 the picker became unconditionally visible. Drop the picker, its draft/Save state, and the override-confirmation flow that fired on default-provider change. Profile selection (which auto-persists) is the only thing the card surfaces; provider connections and per-call-site overrides remain reachable via the secondary actions row. Reported by Marina against v0.8.1 (Desktop Cloud hosted). Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com> * ci: retrigger workflow dispatch --------- Co-authored-by: ApolloBot <apollo@vellum.ai> Co-authored-by: Claude Sonnet 4.5 <noreply@anthropic.com> * fix(warm-pool): gate LLM-touching background jobs on first user message (#30427) Warm-pool images run background services between daemon start and the moment a real user hatches the image. Provider credentials are not registered yet, so any LLM call fails and the failure is recorded as a 'Background job failed: <name>' conversation row that the inheriting user sees in their sidebar. Marina reported this in #releases (msg 1778610954.270769): 'Background job failed: update-bulletin. exception: Conversation: default provider anthropic is not registered'. This PR adds a single chokepoint gate so warm-pool images stay idle until they belong to a user. Changes: * New helper `runtime/pre-first-message-gate.ts` with `hasReceivedUserMessage()`: indexed `LIMIT 1` lookup against the messages/conversations tables, scoped to role='user' in conversation_type='standard'. Caches `true` (monotonic). Fails conservatively (returns false) on query error so background work stays paused. * `runtime/background-job-runner.ts` (the central chokepoint for every background producer — heartbeat, filing, scheduler, memory v2 consolidation, watcher, update-bulletin, sequence, subagent): early return with `{ ok: true, conversationId: '', skipReason: 'pre_first_user_message' }` when the gate is closed. No bootstrap, no processMessage, no `activity.failed` notification. Adds opt-out flag `allowPreFirstUserMessage` for any future job that legitimately needs to run pre-onboarding (none today). * `heartbeat/heartbeat-service.ts`: belt-and-suspenders skip inside `runOnce()`. Records `skipHeartbeatRun(runId, 'pre_first_user_message')` so the heartbeat_runs table shows why warm-pool beats were dropped. Forced runs (manual operator action) bypass the gate. The early-heartbeat counter is preserved because skipped beats never reach `completeHeartbeatRun`. * `prompts/update-bulletin-job.ts`: service-level guard at the top of `runUpdateBulletinJobIfNeeded()`. Checkpoint left unchanged so the job retries on the next daemon start or UPDATES.md change once the user has interacted — this is exactly the bug Marina hit. * `heartbeat/heartbeat-run-store.ts`: `HeartbeatSkipReason` union extended with `pre_first_user_message`. Tests: * New `pre-first-message-gate.test.ts` (5 tests): no-message → false, message exists → true, true result cached, false result re-queries (so gate opens when user interacts), rawGet throw → false. * `background-job-runner.test.ts` (+2): gate closed skips bootstrap; `allowPreFirstUserMessage` bypasses. * `heartbeat-service.test.ts` (+2): scheduled run skips with pre_first_user_message reason; forced runs bypass the gate. * `update-bulletin-job.test.ts` (+1): gate closed leaves checkpoint unchanged. Why gate inside `runBackgroundJob` and the heartbeat service? Defense-in-depth. The runner gate catches future producers automatically; the heartbeat service gate avoids the unnecessary heartbeat_runs CAS dance for skipped beats and keeps the early-heartbeat counter clean. Update-bulletin's checkpoint semantics similarly want service-level handling so a successful checkpoint write doesn't poison the retry path. Co-authored-by: ApolloBot <apollo@vellum.ai> * [LUM-1517] Widen VDropdown menu to match trigger width, auto-select auth type per provider (#30408) * [LUM-1517] Widen VDropdown menu to match trigger width, auto-select auth type per provider VDropdown menu now defaults to the trigger's rendered width instead of a fixed 180px, so labels like 'Platform (managed by Vellum)' are no longer truncated. Callers that pass an explicit menuWidth continue to work. In the New Connection form, selecting Ollama auto-sets auth to 'none' and hides other options. Fireworks and OpenRouter only show 'API Key' since they don't support managed keys. Anthropic, OpenAI, and Gemini show both 'API Key' and 'Platform'. Switching providers resets auth type when the current selection isn't valid for the new provider. Part of LUM-1517 Co-Authored-By: Jason Zhou <jasonczhou3@gmail.com> * Preserve current auth type in edit-mode dropdown options When editing an existing connection whose auth type is no longer offered for new connections (e.g. a non-ollama connection with 'none' auth), include it in the dropdown so the user sees the saved value instead of a confusing placeholder. Co-Authored-By: Jason Zhou <jasonczhou3@gmail.com> * Replace Cancel text with ghost close icon in editor header Uses VButton with iconOnly VIcon.x, matching the pattern in InferenceProfilesSheet and other panel headers. Co-Authored-By: Jason Zhou <jasonczhou3@gmail.com> --------- Co-authored-by: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com> * fix(macos): surface duplicate-name error on provider connection create (#30410) Marina QA flag (Slack 2026-05-12): creating a new provider connection with a duplicate name showed the generic "Couldn't create connection. Please try again." instead of telling the user the name is taken. Daemon returns a proper 409 ConflictError with a structured envelope, but the shared `createProviderConnection` returned `Optional<ProviderConnection>` so the status code (and the user-actionable reason) was being thrown away. This PR mirrors the existing `ProviderConnectionDeleteResult` pattern: * Introduce `ProviderConnectionCreateResult` with cases `.created/.duplicate/.invalid(message:)/.error`. * Switch on `response.statusCode` in `ProviderConnectionClient.create`: 200-299 → `.created`, 409 → `.duplicate`, 400 → `.invalid` (carrying the daemon's `error.message` from the standard envelope), otherwise `.error`. * Update `ProvidersSheet.commitEditor` to switch on the result and surface a precise message per branch — matches the web modal's existing wording (`A connection named "X" already exists.`) for cross-client parity. * Update the mock + happy-path / duplicate / invalid / error tests to the new enum surface. Web (`provider-editor-modal.tsx`) already handles 409 correctly; this is macOS-only catch-up. No daemon changes. Co-authored-by: credence-the-bot <credence-the-bot@users.noreply.github.com> * fix(providers): backfill missing label = name on existing connections (#30412) Migration 244 added the `label` column as nullable with no default, so every provider_connection that existed before 244 ran ended up with label = NULL. In 0.8.x the editor modal renders Display Name from `label` and shows the empty-state placeholder whenever it's null — users who created their connections pre-244 open Edit and see what looks like a wiped field, then conclude their data disappeared. Marina flagged this in QA against 0.8.1. The list view already falls back to `name` when label is empty (ProvidersSheet `connectionRow`), so this brings the editor into agreement with what's already on screen. New migration 246 backfills `label = name` once for any row where label is NULL or empty/whitespace, guarded by memory_checkpoints so a later user-cleared label isn't re-clobbered on subsequent boots. Belt-and-suspenders edge cases covered in tests: - provider_connections table absent (first-boot edge) → no-op, checkpoint set so we don't retry forever - label column absent (244 hasn't run yet) → no-op, NO checkpoint set so the backfill runs once the schema is provisioned - existing user-set labels never overwritten - second run after user clear → respects the clear Co-authored-by: credence-the-bot <credence-the-bot[bot]@users.noreply.github.com> * fix(profiles): backfill missing label on canonical managed profiles (#30419) Marina QA #5 (0.8.1 Desktop Cloud hosted): the profile picker on a freshly hatched assistant surfaces raw slugs — "balanced", "quality-optimized", "cost-optimized" — instead of the human labels "Balanced", "Quality", "Speed". Root cause: workspace migration 052 (`seed-default-inference-profiles`) seeds the canonical triplet with provider+model+maxTokens+effort+ thinking but no `label` field. The runtime profile seeder (`seedInferenceProfiles`) materializes labels on its second pass, but in platform mode (`IS_PLATFORM=true`) it defers to any existing on-disk entry to avoid clobbering platform-supplied overlay fragments. Net result: the labels never get written and `displayName: label ?? name` falls back to the slug. Fix: new workspace migration 082 backfills `label` on each of the three canonical names when (and only when) the key is absent on disk. Surgical — does not touch user-set strings or explicit nulls, does not touch non-canonical profile names, does not require relaxing the seeder's overlay-preserve invariant (which the existing "platform-provided profile fragments are not polluted by managed seeds" test guards). The seeder skip-path comment is updated to point at migration 082 so the next person to read it understands why it's safe to leave the on-platform defer in place. 10 new migration tests, all green. config-loader-backfill.test.ts (42 tests), workspace-migration-052 + managed-profile-guard (30 tests), config-loader-platform-defaults (19 tests), and migration-cross-version-compatibility (50 tests) all pass on the new branch. Co-authored-by: credence-the-bot[bot] <226614080+credence-the-bot[bot]@users.noreply.github.com> * feat(providers): make managed-auth capability catalog-driven (#30411) PR #30408 (Jason / LUM-1517) shipped the UX fix on macOS: hide the Platform auth-type option for providers without a managed proxy route. It does so via `store.isManagedCapable(provider)` which until now was a hardcoded `Set<String>("anthropic", "openai", "gemini")` on SettingsStore — with a docstring that explicitly calls out 'Mirrors the `MANAGED_PROVIDER_META` table in the backend.' That's a drift hazard: adding a managed provider in the proxy routing table doesn't propagate to the UI gate. This PR closes the loop by making the catalog the source of truth. Changes ------- * assistant/src/providers/model-catalog.ts — add `supportsManagedAuth?: boolean` to ProviderCatalogEntry, derived from `MANAGED_PROVIDER_META[entry.id]?.managed === true` at PROVIDER_CATALOG build time. The two can no longer drift. * assistant/scripts/sync-llm-catalog.ts — project the field through to the client-facing JSON. Re-generated both copies (meta/ + clients/shared/Resources/). * assistant/src/__tests__/llm-catalog-parity.test.ts — parity assertion + a focused invariant test guarding against future hand-edits drifting from MANAGED_PROVIDER_META. * clients/shared/Utilities/LLMProviderRegistry.swift — decode the field on `LLMProviderEntry` (optional, defaults to nil for forward-compat with older catalog versions). * clients/macos/.../SettingsStore.swift — refactor `isManagedCapable(_:)` and `managedCapableProviders` to read the flag from `LLMProviderRegistry` instead of the hardcoded set. The wire-protocol `ProviderCatalogEntry` doesn't carry capability flags, so we read from the static registry to keep the answer stable across daemon `model_info` refreshes. Behavior parity --------------- The existing 7 isManagedCapable tests + 2 managedCapableProviders tests in SettingsStoreManagedInferenceSelectionTests all continue to pass — anthropic/openai/gemini → true, ollama/fireworks/openrouter → false, unknown → false. Same truth table, different source. Not in this PR -------------- * macOS auth-type dropdown filtering — already shipped in #30408. * Web modal parity — separate vellum-assistant-platform PR. * Rename "managed" → "platform" terminology — Noa-tracked follow-up after this lands. Test ---- * `bun test src/__tests__/llm-catalog-parity.test.ts` — 14/14 pass. * Daemon lint clean (`bun run lint`). Co-authored-by: credence-the-bot <credence-the-bot@users.noreply.github.com> * ATL-539: Vercel credential injection hardening (#30401) * feat(security): escalate credentialed proxied bash to high risk classification (#30383) * Part of ATL-539: Restrict new Vercel token metadata to publish tools (#30381) * feat(security): restrict new Vercel token metadata to publish tools only * fix: explicitly clear injectionTemplates when storing Vercel metadata Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * Part of ATL-539: Enforce credential policy before proxied bash sessions (#30384) * feat(security): enforce credential allowedTools policy before proxied bash sessions * fix: add credential metadata mocks to shell-tool-proxy-mode tests Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * feat(security): workspace migration to repair existing Vercel credential metadata (#30389) * Part of ATL-539: Remove Vercel credential proxy guidance from skills (#30388) * docs(security): remove Vercel credential proxy guidance from deployment skills * chore: regenerate skills catalog.json Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * fix: reorder Vercel CLI install before login step Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * chore: regenerate skills catalog.json after step reorder Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * fix: add explicit allowedDomains: [] to credential store examples Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * chore: regenerate skills catalog.json Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * fix: backfill bash into allowedTools for credentials with injection templates (#30393) * fix: include bash in allowedTools for non-Vercel credential creation (#30396) * fix: add bash to allowedTools for all non-Vercel credential setup paths * chore: fix Prettier formatting and regenerate catalog * chore: regenerate catalog with correct updatedAt timestamp * fix: add bash to allowedTools for Slack credential setup (#30400) * chore: regenerate skills catalog.json from final feature branch state Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * chore: fix catalog.json updatedAt for stripe-app-setup Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * test(assistant): mock warm-pool gate open in pre-existing heartbeat/filing tests PR #30427 added the pre-first-message gate to runBackgroundJob and heartbeat-service.runOnce, then mocked hasReceivedUserMessage() to true in the test files it touched directly. The four pre-existing test files below also exercise those code paths but had no mock — their tests now short-circuit with 'pre_first_user_message' instead of running through the heartbeat / filing / disk-pressure logic they were written to check. Add the same mock.module("../runtime/pre-first-message-gate.js", ...) override at the top of each file so the gate defaults to OPEN for tests that predate it. Tests that specifically exercise the gate continue to live in pre-first-message-gate.test.ts and background-job-runner.test.ts. Verified locally: 79+19+3+4 = 105 tests previously red, now all green. Adjacent test files (scheduler, watcher, consolidation, workspace-*, commit-guarantee, heartbeat-routes) already pass without modification — they mock the surface higher up or don't reach runBackgroundJob. --------- Co-authored-by: vellum-apollo-bot[bot] <242025090+vellum-apollo-bot[bot]@users.noreply.github.com> Co-authored-by: ApolloBot <apollo@vellum.ai> Co-authored-by: Claude Sonnet 4.5 <noreply@anthropic.com> Co-authored-by: Jason Zhou <jason@vellum.ai> Co-authored-by: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com> Co-authored-by: credence-the-bot[bot] <277301654+credence-the-bot[bot]@users.noreply.github.com> Co-authored-by: credence-the-bot <credence-the-bot@users.noreply.github.com> Co-authored-by: Noa Flaherty <noa@vellum.ai> Co-authored-by: credence-the-bot <credence-the-bot[bot]@users.noreply.github.com> Co-authored-by: credence-the-bot[bot] <226614080+credence-the-bot[bot]@users.noreply.github.com> Co-authored-by: Alex Nork <48630278+alex-nork@users.noreply.github.com>
noanflaherty
added a commit
that referenced
this pull request
May 13, 2026
* Release v0.8.1 * test(cdp-inspect): de-flake ws-transport event fan-out (#30397) (#30398) The 'fans out events (frames with no id) to listeners' test relied on a 5ms server-side setTimeout to push an unsolicited event after the client's open callback. On a busy CI runner the test body's addEventListener could lose the race against that timer — the event arrived, found no listeners, and was dropped, leaving received empty and the assertion failing. Push the event in response to a client trigger send instead, emitting the event frame BEFORE the response ack. WebSocket message ordering then guarantees the listener observes the event before the trigger promise resolves — fully deterministic, no sleeps. Co-authored-by: vellum-apollo-bot[bot] <242025090+vellum-apollo-bot[bot]@users.noreply.github.com> Co-authored-by: ApolloBot <apollo@vellum.ai> * Cherry-picks for release/v0.8.1 (#30415) * fix(macos): hide redundant default Provider picker on Language Model card (#30413) * fix(macos): hide redundant default Provider picker on Language Model card Profiles already carry the provider they dispatch against — surfacing a separate "default Provider" picker on the Language Model card lets users land in nonsensical states (e.g. Provider: Anthropic + Profile: Kimi K2.5 on Fireworks). v0.8.0 hid the picker behind the inference-mode toggle; when that toggle was dropped in #30231 the picker became unconditionally visible. Drop the picker, its draft/Save state, and the override-confirmation flow that fired on default-provider change. Profile selection (which auto-persists) is the only thing the card surfaces; provider connections and per-call-site overrides remain reachable via the secondary actions row. Reported by Marina against v0.8.1 (Desktop Cloud hosted). Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com> * ci: retrigger workflow dispatch --------- Co-authored-by: ApolloBot <apollo@vellum.ai> Co-authored-by: Claude Sonnet 4.5 <noreply@anthropic.com> * fix(warm-pool): gate LLM-touching background jobs on first user message (#30427) Warm-pool images run background services between daemon start and the moment a real user hatches the image. Provider credentials are not registered yet, so any LLM call fails and the failure is recorded as a 'Background job failed: <name>' conversation row that the inheriting user sees in their sidebar. Marina reported this in #releases (msg 1778610954.270769): 'Background job failed: update-bulletin. exception: Conversation: default provider anthropic is not registered'. This PR adds a single chokepoint gate so warm-pool images stay idle until they belong to a user. Changes: * New helper `runtime/pre-first-message-gate.ts` with `hasReceivedUserMessage()`: indexed `LIMIT 1` lookup against the messages/conversations tables, scoped to role='user' in conversation_type='standard'. Caches `true` (monotonic). Fails conservatively (returns false) on query error so background work stays paused. * `runtime/background-job-runner.ts` (the central chokepoint for every background producer — heartbeat, filing, scheduler, memory v2 consolidation, watcher, update-bulletin, sequence, subagent): early return with `{ ok: true, conversationId: '', skipReason: 'pre_first_user_message' }` when the gate is closed. No bootstrap, no processMessage, no `activity.failed` notification. Adds opt-out flag `allowPreFirstUserMessage` for any future job that legitimately needs to run pre-onboarding (none today). * `heartbeat/heartbeat-service.ts`: belt-and-suspenders skip inside `runOnce()`. Records `skipHeartbeatRun(runId, 'pre_first_user_message')` so the heartbeat_runs table shows why warm-pool beats were dropped. Forced runs (manual operator action) bypass the gate. The early-heartbeat counter is preserved because skipped beats never reach `completeHeartbeatRun`. * `prompts/update-bulletin-job.ts`: service-level guard at the top of `runUpdateBulletinJobIfNeeded()`. Checkpoint left unchanged so the job retries on the next daemon start or UPDATES.md change once the user has interacted — this is exactly the bug Marina hit. * `heartbeat/heartbeat-run-store.ts`: `HeartbeatSkipReason` union extended with `pre_first_user_message`. Tests: * New `pre-first-message-gate.test.ts` (5 tests): no-message → false, message exists → true, true result cached, false result re-queries (so gate opens when user interacts), rawGet throw → false. * `background-job-runner.test.ts` (+2): gate closed skips bootstrap; `allowPreFirstUserMessage` bypasses. * `heartbeat-service.test.ts` (+2): scheduled run skips with pre_first_user_message reason; forced runs bypass the gate. * `update-bulletin-job.test.ts` (+1): gate closed leaves checkpoint unchanged. Why gate inside `runBackgroundJob` and the heartbeat service? Defense-in-depth. The runner gate catches future producers automatically; the heartbeat service gate avoids the unnecessary heartbeat_runs CAS dance for skipped beats and keeps the early-heartbeat counter clean. Update-bulletin's checkpoint semantics similarly want service-level handling so a successful checkpoint write doesn't poison the retry path. Co-authored-by: ApolloBot <apollo@vellum.ai> * [LUM-1517] Widen VDropdown menu to match trigger width, auto-select auth type per provider (#30408) * [LUM-1517] Widen VDropdown menu to match trigger width, auto-select auth type per provider VDropdown menu now defaults to the trigger's rendered width instead of a fixed 180px, so labels like 'Platform (managed by Vellum)' are no longer truncated. Callers that pass an explicit menuWidth continue to work. In the New Connection form, selecting Ollama auto-sets auth to 'none' and hides other options. Fireworks and OpenRouter only show 'API Key' since they don't support managed keys. Anthropic, OpenAI, and Gemini show both 'API Key' and 'Platform'. Switching providers resets auth type when the current selection isn't valid for the new provider. Part of LUM-1517 Co-Authored-By: Jason Zhou <jasonczhou3@gmail.com> * Preserve current auth type in edit-mode dropdown options When editing an existing connection whose auth type is no longer offered for new connections (e.g. a non-ollama connection with 'none' auth), include it in the dropdown so the user sees the saved value instead of a confusing placeholder. Co-Authored-By: Jason Zhou <jasonczhou3@gmail.com> * Replace Cancel text with ghost close icon in editor header Uses VButton with iconOnly VIcon.x, matching the pattern in InferenceProfilesSheet and other panel headers. Co-Authored-By: Jason Zhou <jasonczhou3@gmail.com> --------- Co-authored-by: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com> * fix(macos): surface duplicate-name error on provider connection create (#30410) Marina QA flag (Slack 2026-05-12): creating a new provider connection with a duplicate name showed the generic "Couldn't create connection. Please try again." instead of telling the user the name is taken. Daemon returns a proper 409 ConflictError with a structured envelope, but the shared `createProviderConnection` returned `Optional<ProviderConnection>` so the status code (and the user-actionable reason) was being thrown away. This PR mirrors the existing `ProviderConnectionDeleteResult` pattern: * Introduce `ProviderConnectionCreateResult` with cases `.created/.duplicate/.invalid(message:)/.error`. * Switch on `response.statusCode` in `ProviderConnectionClient.create`: 200-299 → `.created`, 409 → `.duplicate`, 400 → `.invalid` (carrying the daemon's `error.message` from the standard envelope), otherwise `.error`. * Update `ProvidersSheet.commitEditor` to switch on the result and surface a precise message per branch — matches the web modal's existing wording (`A connection named "X" already exists.`) for cross-client parity. * Update the mock + happy-path / duplicate / invalid / error tests to the new enum surface. Web (`provider-editor-modal.tsx`) already handles 409 correctly; this is macOS-only catch-up. No daemon changes. Co-authored-by: credence-the-bot <credence-the-bot@users.noreply.github.com> * fix(providers): backfill missing label = name on existing connections (#30412) Migration 244 added the `label` column as nullable with no default, so every provider_connection that existed before 244 ran ended up with label = NULL. In 0.8.x the editor modal renders Display Name from `label` and shows the empty-state placeholder whenever it's null — users who created their connections pre-244 open Edit and see what looks like a wiped field, then conclude their data disappeared. Marina flagged this in QA against 0.8.1. The list view already falls back to `name` when label is empty (ProvidersSheet `connectionRow`), so this brings the editor into agreement with what's already on screen. New migration 246 backfills `label = name` once for any row where label is NULL or empty/whitespace, guarded by memory_checkpoints so a later user-cleared label isn't re-clobbered on subsequent boots. Belt-and-suspenders edge cases covered in tests: - provider_connections table absent (first-boot edge) → no-op, checkpoint set so we don't retry forever - label column absent (244 hasn't run yet) → no-op, NO checkpoint set so the backfill runs once the schema is provisioned - existing user-set labels never overwritten - second run after user clear → respects the clear Co-authored-by: credence-the-bot <credence-the-bot[bot]@users.noreply.github.com> * fix(profiles): backfill missing label on canonical managed profiles (#30419) Marina QA #5 (0.8.1 Desktop Cloud hosted): the profile picker on a freshly hatched assistant surfaces raw slugs — "balanced", "quality-optimized", "cost-optimized" — instead of the human labels "Balanced", "Quality", "Speed". Root cause: workspace migration 052 (`seed-default-inference-profiles`) seeds the canonical triplet with provider+model+maxTokens+effort+ thinking but no `label` field. The runtime profile seeder (`seedInferenceProfiles`) materializes labels on its second pass, but in platform mode (`IS_PLATFORM=true`) it defers to any existing on-disk entry to avoid clobbering platform-supplied overlay fragments. Net result: the labels never get written and `displayName: label ?? name` falls back to the slug. Fix: new workspace migration 082 backfills `label` on each of the three canonical names when (and only when) the key is absent on disk. Surgical — does not touch user-set strings or explicit nulls, does not touch non-canonical profile names, does not require relaxing the seeder's overlay-preserve invariant (which the existing "platform-provided profile fragments are not polluted by managed seeds" test guards). The seeder skip-path comment is updated to point at migration 082 so the next person to read it understands why it's safe to leave the on-platform defer in place. 10 new migration tests, all green. config-loader-backfill.test.ts (42 tests), workspace-migration-052 + managed-profile-guard (30 tests), config-loader-platform-defaults (19 tests), and migration-cross-version-compatibility (50 tests) all pass on the new branch. Co-authored-by: credence-the-bot[bot] <226614080+credence-the-bot[bot]@users.noreply.github.com> * feat(providers): make managed-auth capability catalog-driven (#30411) PR #30408 (Jason / LUM-1517) shipped the UX fix on macOS: hide the Platform auth-type option for providers without a managed proxy route. It does so via `store.isManagedCapable(provider)` which until now was a hardcoded `Set<String>("anthropic", "openai", "gemini")` on SettingsStore — with a docstring that explicitly calls out 'Mirrors the `MANAGED_PROVIDER_META` table in the backend.' That's a drift hazard: adding a managed provider in the proxy routing table doesn't propagate to the UI gate. This PR closes the loop by making the catalog the source of truth. Changes ------- * assistant/src/providers/model-catalog.ts — add `supportsManagedAuth?: boolean` to ProviderCatalogEntry, derived from `MANAGED_PROVIDER_META[entry.id]?.managed === true` at PROVIDER_CATALOG build time. The two can no longer drift. * assistant/scripts/sync-llm-catalog.ts — project the field through to the client-facing JSON. Re-generated both copies (meta/ + clients/shared/Resources/). * assistant/src/__tests__/llm-catalog-parity.test.ts — parity assertion + a focused invariant test guarding against future hand-edits drifting from MANAGED_PROVIDER_META. * clients/shared/Utilities/LLMProviderRegistry.swift — decode the field on `LLMProviderEntry` (optional, defaults to nil for forward-compat with older catalog versions). * clients/macos/.../SettingsStore.swift — refactor `isManagedCapable(_:)` and `managedCapableProviders` to read the flag from `LLMProviderRegistry` instead of the hardcoded set. The wire-protocol `ProviderCatalogEntry` doesn't carry capability flags, so we read from the static registry to keep the answer stable across daemon `model_info` refreshes. Behavior parity --------------- The existing 7 isManagedCapable tests + 2 managedCapableProviders tests in SettingsStoreManagedInferenceSelectionTests all continue to pass — anthropic/openai/gemini → true, ollama/fireworks/openrouter → false, unknown → false. Same truth table, different source. Not in this PR -------------- * macOS auth-type dropdown filtering — already shipped in #30408. * Web modal parity — separate vellum-assistant-platform PR. * Rename "managed" → "platform" terminology — Noa-tracked follow-up after this lands. Test ---- * `bun test src/__tests__/llm-catalog-parity.test.ts` — 14/14 pass. * Daemon lint clean (`bun run lint`). Co-authored-by: credence-the-bot <credence-the-bot@users.noreply.github.com> * ATL-539: Vercel credential injection hardening (#30401) * feat(security): escalate credentialed proxied bash to high risk classification (#30383) * Part of ATL-539: Restrict new Vercel token metadata to publish tools (#30381) * feat(security): restrict new Vercel token metadata to publish tools only * fix: explicitly clear injectionTemplates when storing Vercel metadata Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * Part of ATL-539: Enforce credential policy before proxied bash sessions (#30384) * feat(security): enforce credential allowedTools policy before proxied bash sessions * fix: add credential metadata mocks to shell-tool-proxy-mode tests Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * feat(security): workspace migration to repair existing Vercel credential metadata (#30389) * Part of ATL-539: Remove Vercel credential proxy guidance from skills (#30388) * docs(security): remove Vercel credential proxy guidance from deployment skills * chore: regenerate skills catalog.json Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * fix: reorder Vercel CLI install before login step Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * chore: regenerate skills catalog.json after step reorder Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * fix: add explicit allowedDomains: [] to credential store examples Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * chore: regenerate skills catalog.json Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * fix: backfill bash into allowedTools for credentials with injection templates (#30393) * fix: include bash in allowedTools for non-Vercel credential creation (#30396) * fix: add bash to allowedTools for all non-Vercel credential setup paths * chore: fix Prettier formatting and regenerate catalog * chore: regenerate catalog with correct updatedAt timestamp * fix: add bash to allowedTools for Slack credential setup (#30400) * chore: regenerate skills catalog.json from final feature branch state Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * chore: fix catalog.json updatedAt for stripe-app-setup Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * test(assistant): mock warm-pool gate open in pre-existing heartbeat/filing tests PR #30427 added the pre-first-message gate to runBackgroundJob and heartbeat-service.runOnce, then mocked hasReceivedUserMessage() to true in the test files it touched directly. The four pre-existing test files below also exercise those code paths but had no mock — their tests now short-circuit with 'pre_first_user_message' instead of running through the heartbeat / filing / disk-pressure logic they were written to check. Add the same mock.module("../runtime/pre-first-message-gate.js", ...) override at the top of each file so the gate defaults to OPEN for tests that predate it. Tests that specifically exercise the gate continue to live in pre-first-message-gate.test.ts and background-job-runner.test.ts. Verified locally: 79+19+3+4 = 105 tests previously red, now all green. Adjacent test files (scheduler, watcher, consolidation, workspace-*, commit-guarantee, heartbeat-routes) already pass without modification — they mock the surface higher up or don't reach runBackgroundJob. --------- Co-authored-by: vellum-apollo-bot[bot] <242025090+vellum-apollo-bot[bot]@users.noreply.github.com> Co-authored-by: ApolloBot <apollo@vellum.ai> Co-authored-by: Claude Sonnet 4.5 <noreply@anthropic.com> Co-authored-by: Jason Zhou <jason@vellum.ai> Co-authored-by: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com> Co-authored-by: credence-the-bot[bot] <277301654+credence-the-bot[bot]@users.noreply.github.com> Co-authored-by: credence-the-bot <credence-the-bot@users.noreply.github.com> Co-authored-by: Noa Flaherty <noa@vellum.ai> Co-authored-by: credence-the-bot <credence-the-bot[bot]@users.noreply.github.com> Co-authored-by: credence-the-bot[bot] <226614080+credence-the-bot[bot]@users.noreply.github.com> Co-authored-by: Alex Nork <48630278+alex-nork@users.noreply.github.com> --------- Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com> Co-authored-by: vellum-automation[bot] <192048195+vellum-automation[bot]@users.noreply.github.com> Co-authored-by: vellum-apollo-bot[bot] <242025090+vellum-apollo-bot[bot]@users.noreply.github.com> Co-authored-by: ApolloBot <apollo@vellum.ai> Co-authored-by: Claude Sonnet 4.5 <noreply@anthropic.com> Co-authored-by: Jason Zhou <jason@vellum.ai> Co-authored-by: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com> Co-authored-by: credence-the-bot[bot] <277301654+credence-the-bot[bot]@users.noreply.github.com> Co-authored-by: credence-the-bot <credence-the-bot@users.noreply.github.com> Co-authored-by: Noa Flaherty <noa@vellum.ai> Co-authored-by: credence-the-bot <credence-the-bot[bot]@users.noreply.github.com> Co-authored-by: credence-the-bot[bot] <226614080+credence-the-bot[bot]@users.noreply.github.com> Co-authored-by: Alex Nork <48630278+alex-nork@users.noreply.github.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
VDropdown menu now defaults to the trigger's rendered width instead of a fixed 180px, so labels like "Platform (managed by Vellum)" are no longer truncated. Callers that pass an explicit
menuWidthcontinue to work unchanged. In the New Connection form, selecting Ollama auto-sets auth to "none" (only valid option); Fireworks and OpenRouter only show "API Key" (no managed key support); Anthropic, OpenAI, and Gemini show both "API Key" and "Platform". Existing connections with legacy auth types display their saved value in the dropdown. Also replaced the "Cancel" text button in the editor header with a ghost close (×) icon, matching the pattern used in InferenceProfilesSheet and other panel headers.Prompt / plan
Fix LUM-1517: dropdown too narrow in provider editor. Also add provider-aware auth type filtering so users only see valid options for their selected provider.
Test plan
bunx tsc --noEmit) passesLink to Devin session: https://app.devin.ai/sessions/f45302dc28654866b3d342cafebd3083
Requested by: @Jasonnnz