@cat-factory/app 0.277.1 → 0.278.0

package/app/stores/workspace.spec.ts

@@ -45,12 +45,17 @@ beforeEach(() => {
 
 // Regression for the live-push CLOBBER race: `board`-type stream events (and the on-connect
 // resync) each trigger a full-snapshot `refresh()`, and `hydrate` REPLACES the block list. Two
-// refreshes can be in flight at once (events >300ms apart, or a resync + a board event), and if a
-// slower/staler fetch resolves AFTER a newer one, its hydrate used to clobber the newer state —
-// dropping a just-spawned block whose only live delivery was the coarse board event, so its card
-// never reappeared (no further event to restore it). This surfaced as an intermittent e2e timeout
-// where a spawned task/document card never rendered. `refresh()` now stamps each call so only the
-// latest-issued one commits; this test pins that a stale out-of-order refresh can't win.
+// refreshes used to be in flight at once (events >300ms apart, or a resync + a board event), and a
+// slower/staler fetch resolving AFTER a newer one clobbered the newer state, dropping a
+// just-spawned block whose only live delivery was the coarse board event, so its card never
+// reappeared (no further event to restore it). That surfaced as an intermittent e2e timeout where a
+// spawned task/document card never rendered.
+//
+// `refresh()` now goes through the funnel, which SERIALIZES: a call arriving during a fetch waits
+// for a follow-up fetch issued after it rather than racing beside it. So the out-of-order clobber
+// is structurally unreachable rather than detected and discarded, and what this test pins is the
+// property that replaced the sequence stamp: overlapping refreshes never interleave, and the board
+// ends on the LAST snapshot fetched. `refreshFunnel.spec.ts` covers the coalescing rules directly.
 
 /** Minimal block — only the fields the board store's index getters read. */
 function block(id: string, over: Partial<Block> = {}): Block {
@@ -102,20 +107,19 @@ function snapshot(
 }
 
 describe('workspace store refresh ordering', () => {
-  it('a stale refresh resolving out of order does not clobber a newer one', async () => {
+  it('serializes overlapping refreshes so the board ends on the last snapshot fetched', async () => {
     const frame = block('f1')
     const spawned = block('spawned', { level: 'task', parentId: 'f1' })
-    let resolveStale!: (s: WorkspaceSnapshot) => void
-    let resolveFresh!: (s: WorkspaceSnapshot) => void
+    let resolveFirst!: (s: WorkspaceSnapshot) => void
 
     const getWorkspace = vi
       .fn()
       // 1) switchTo establishes the active board (no spawned block yet).
       .mockResolvedValueOnce(snapshot('ws1', [frame]))
-      // 2) the EARLIER-issued refresh (stale: still no spawned block) — resolved LAST below.
-      .mockReturnValueOnce(new Promise<WorkspaceSnapshot>((r) => (resolveStale = r)))
-      // 3) the LATER-issued refresh (fresh: the spawned block landed) — resolved FIRST below.
-      .mockReturnValueOnce(new Promise<WorkspaceSnapshot>((r) => (resolveFresh = r)))
+      // 2) the first refresh's fetch: still no spawned block, and held open below.
+      .mockReturnValueOnce(new Promise<WorkspaceSnapshot>((r) => (resolveFirst = r)))
+      // 3) the follow-up fetch, ISSUED ONLY AFTER (2) settles, which is why it sees the spawn.
+      .mockResolvedValueOnce(snapshot('ws1', [frame, spawned]))
     vi.stubGlobal('useApi', () => ({ getWorkspace }))
 
     const ws = useWorkspaceStore()
@@ -123,21 +127,23 @@ describe('workspace store refresh ordering', () => {
     await ws.switchTo('ws1')
     expect(board.getBlock('spawned')).toBeUndefined()
 
-    // Two overlapping refreshes: the later-issued one carries the fresher snapshot, but the
-    // earlier-issued (stale) one resolves last — the exact out-of-order clobber the guard blocks.
-    const stalePass = ws.refresh()
-    const freshPass = ws.refresh()
-    resolveFresh(snapshot('ws1', [frame, spawned]))
-    resolveStale(snapshot('ws1', [frame]))
-    await Promise.all([stalePass, freshPass])
+    // A second refresh arriving mid-fetch does NOT start a racing fetch: one is outstanding.
+    const first = ws.refresh()
+    const second = ws.refresh()
+    expect(getWorkspace).toHaveBeenCalledTimes(2)
 
-    // The fresh snapshot won and the stale one was discarded: the spawned card survives.
+    resolveFirst(snapshot('ws1', [frame]))
+    await Promise.all([first, second])
+
+    // The follow-up ran after the first settled and its snapshot is what the board holds, so a
+    // caller that refreshed after spawning the block sees it.
+    expect(getWorkspace).toHaveBeenCalledTimes(3)
     expect(board.getBlock('spawned')).toBeDefined()
   })
 
-  // Regression for the SECOND clobber axis: a refresh vs an interleaved live `upsert`. The
-  // `refreshSeq` guard above only orders refreshes against each OTHER — it does nothing when a
-  // single refresh's (slow) fetch overlaps a targeted live event. A run's status transitions
+  // Regression for the SECOND clobber axis: a refresh vs an interleaved live `upsert`. Serializing
+  // refreshes orders them against each OTHER and does nothing when a single refresh's (slow) fetch
+  // overlaps a targeted live event. A run's status transitions
   // (…→ in_progress → pr_ready/done) arrive as `execution`-event `board.upsert`s; a refresh whose
   // snapshot was FETCHED while the block was still `in_progress` must not, on resolving later,
   // replace that block back to the stale status. This was the reliable-under-CI-latency e2e

package/app/stores/workspace.ts

@@ -14,6 +14,7 @@ import type { LiveWriteBaselines } from '~/stores/workspace/hydrate'
 import { applySnapshotToStores, resetPerBoardCaches } from '~/stores/workspace/hydrate'
 import { createWorkspaceCommands } from '~/stores/workspace/commands'
 import { createInfraSetupState } from '~/stores/workspace/infraSetup'
+import { createRefreshFunnel } from '~/stores/workspace/refreshFunnel'
 import { markBoot } from '~/utils/bootMarks'
 import { retryWhileBackendUnreachable } from '~/utils/backendReady'
 
@@ -198,34 +199,22 @@ export const useWorkspaceStore = defineStore(
       resolveActiveBoard,
     })
 
-    // Monotonic guard for {@link refresh}: `board`-type stream events (and the on-connect resync)
-    // each fire a full-snapshot refresh, and {@link hydrate} REPLACES the block list. Without
-    // ordering, two in-flight fetches can resolve out of order, so a slower/staler snapshot's
-    // hydrate clobbers a newer one — dropping a just-spawned block whose ONLY live delivery was
-    // the coarse `board` event (there is no per-block push), so its card never reappears (no
-    // further event to restore it). Stamping each call lets only the latest-issued refresh commit.
-    let refreshSeq = 0
-
-    /** Re-fetch the snapshot and re-hydrate (after mutations and on stream (re)connect). */
-    async function refresh() {
-      const targetId = workspaceId.value
-      if (!targetId) return
-      const seq = ++refreshSeq
-      // Capture the live-write baselines BEFORE the fetch: anything a live event writes while
-      // this (potentially slow) snapshot is in flight is newer than the snapshot, so `hydrate`
-      // must NOT clobber it back. The `refreshSeq` guard below only orders refreshes against each
-      // OTHER — this guards a refresh against an interleaved live write (a run's terminal status
-      // landing mid-fetch, or the inbox card it raises), the coherence hazard under CI latency.
-      const baselines: LiveWriteBaselines = {
+    // The one door every full-snapshot refresh goes through: it coalesces the ~35 direct
+    // post-mutation call sites and the stream's coarse-event resync into at most one in-flight
+    // fetch plus one queued follow-up, and exposes the coverage mark the stream's debounce uses to
+    // drop a resync a mutation's own refresh already served. Ordering (a stale snapshot's hydrate
+    // clobbering a newer one, which would drop a just-spawned block whose ONLY live delivery was
+    // the coarse `board` event) falls out of there being one fetch at a time. Rules and the
+    // reasoning: `stores/workspace/refreshFunnel.ts`.
+    const { refresh, refreshMark, hydratedSince } = createRefreshFunnel({
+      currentWorkspaceId: () => workspaceId.value,
+      fetchSnapshot: (id, signal) => api.getWorkspace(id, signal),
+      captureBaselines: (): LiveWriteBaselines => ({
         board: useBoardStore().hydrateBaseline(),
         notifications: useNotificationsStore().hydrateBaseline(),
-      }
-      const snapshot = await api.getWorkspace(targetId)
-      // A newer refresh was issued (or the active board switched) while this fetch was in flight —
-      // discard this older/staler result so it can't clobber the newer hydrate.
-      if (seq !== refreshSeq || workspaceId.value !== targetId) return
-      hydrate(snapshot, baselines)
-    }
+      }),
+      apply: hydrate,
+    })
 
     /** The active workspace id, or throw if the app isn't bootstrapped yet. */
     function requireId(): string {
@@ -262,6 +251,8 @@ export const useWorkspaceStore = defineStore(
       rename,
       remove,
       refresh,
+      refreshMark,
+      hydratedSince,
       requireId,
       resumeSpend,
     }

package/app/utils/laneIdentity.spec.ts

@@ -0,0 +1,119 @@
+import { describe, it, expect } from 'vitest'
+import { createLaneMemo } from '~/utils/laneIdentity'
+import type { LaneGroup, LaneTaskEntry, RenderedLane } from '~/utils/laneSort'
+import type { Block } from '~/types/domain'
+
+const taskA = { id: 'a', title: 'A' } as unknown as Block
+const taskB = { id: 'b', title: 'B' } as unknown as Block
+
+function entry(task: Block, over: Partial<LaneTaskEntry> = {}): LaneTaskEntry {
+  return {
+    task,
+    reason: 'running',
+    order: 0,
+    activityAt: null,
+    waitingSince: null,
+    moduleName: null,
+    initiativeName: null,
+    epicName: null,
+    ...over,
+  } as LaneTaskEntry
+}
+
+function group(id: string | null, entries: LaneTaskEntry[]): LaneGroup {
+  return { id, label: id, entries }
+}
+
+function lanes(...groups: LaneGroup[][]): RenderedLane[] {
+  const names = ['not_started', 'in_progress', 'needs_you', 'done'] as const
+  return groups.map((g, i) => ({
+    lane: names[i]!,
+    groups: g,
+    total: g.reduce((n, x) => n + x.entries.length, 0),
+  }))
+}
+
+describe('lane structural sharing', () => {
+  it('returns the previous array when nothing changed', () => {
+    const share = createLaneMemo()
+    const first = share(lanes([group('g1', [entry(taskA)])]))
+    const second = share(lanes([group('g1', [entry(taskA)])]))
+    expect(second).toBe(first)
+    expect(second[0]).toBe(first[0])
+    expect(second[0]!.groups[0]).toBe(first[0]!.groups[0])
+    expect(second[0]!.groups[0]!.entries[0]).toBe(first[0]!.groups[0]!.entries[0])
+  })
+
+  it('keeps the untouched lane identical while replacing the one that changed', () => {
+    const share = createLaneMemo()
+    const first = share(lanes([group('g1', [entry(taskA)])], [group('g2', [entry(taskB)])]))
+    const second = share(
+      lanes([group('g1', [entry(taskA)])], [group('g2', [entry(taskB, { activityAt: 5 })])]),
+    )
+    expect(second).not.toBe(first)
+    expect(second[0]).toBe(first[0])
+    expect(second[1]).not.toBe(first[1])
+  })
+
+  // Half of the reference rule: a REPLACED block (what every `board.upsert` does) is a new object,
+  // so reuse cannot hand a renderer the pre-write one.
+  it('does not reuse an entry whose task object was replaced', () => {
+    const share = createLaneMemo()
+    const first = share(lanes([group('g1', [entry(taskA)])]))
+    const renamed = { id: 'a', title: 'A renamed' } as unknown as Block
+    const second = share(lanes([group('g1', [entry(renamed)])]))
+    expect(second).not.toBe(first)
+    expect(second[0]!.groups[0]!.entries[0]!.task).toBe(renamed)
+  })
+
+  /**
+   * The other half, and the case the comparison deliberately does NOT try to detect:
+   * `stores/board/placement.ts` patches a block IN PLACE for its optimistic writes, so both entries
+   * hold the same object and no comparison over it could see the difference. Reuse is still
+   * observationally identical, because the object a renderer reads through IS the patched one (and
+   * `board.blocks` is deeply reactive, so the patch invalidates whatever read it). What must not be
+   * reused is an entry whose DERIVED fields moved with the patch, which is the assertion below.
+   */
+  it('reuses an entry whose task was patched in place, but not its derived fields', () => {
+    const share = createLaneMemo()
+    const task = { id: 'a', title: 'A', moduleName: null } as unknown as Block
+    const first = share(lanes([group('g1', [entry(task)])]))
+    Object.assign(task, { title: 'A patched', moduleName: 'billing' })
+    // Same derived fields: the entry is reused, and it carries the patched object.
+    const unchanged = share(lanes([group('g1', [entry(task)])]))
+    expect(unchanged).toBe(first)
+    expect(unchanged[0]!.groups[0]!.entries[0]!.task.title).toBe('A patched')
+    // The assembly re-derived `moduleName` from the patch: that is a fresh entry.
+    const rederived = share(lanes([group('g1', [entry(task, { moduleName: 'billing' })])]))
+    expect(rederived).not.toBe(first)
+    expect(rederived[0]!.groups[0]!.entries[0]!.moduleName).toBe('billing')
+  })
+
+  it('treats reordering, additions and removals as changes', () => {
+    const share = createLaneMemo()
+    const first = share(lanes([group('g1', [entry(taskA), entry(taskB)])]))
+    expect(share(lanes([group('g1', [entry(taskB), entry(taskA)])]))).not.toBe(first)
+
+    const share2 = createLaneMemo()
+    const base = share2(lanes([group('g1', [entry(taskA)])]))
+    expect(share2(lanes([group('g1', [entry(taskA), entry(taskB)])]))).not.toBe(base)
+  })
+
+  it('reuses an unchanged group while the sibling group in the same lane changes', () => {
+    const share = createLaneMemo()
+    const first = share(lanes([group('g1', [entry(taskA)]), group('g2', [entry(taskB)])]))
+    const second = share(
+      lanes([group('g1', [entry(taskA)]), group('g2', [entry(taskB, { order: 3 })])]),
+    )
+    expect(second[0]!.groups[0]).toBe(first[0]!.groups[0])
+    expect(second[0]!.groups[1]).not.toBe(first[0]!.groups[1])
+  })
+
+  it('does not reuse a lane whose total changed even when its rendered groups match', () => {
+    const share = createLaneMemo()
+    const first = share(lanes([group('g1', [entry(taskA)])]))
+    const capped = lanes([group('g1', [entry(taskA)])])
+    capped[0] = { ...capped[0]!, total: 99 }
+    expect(share(capped)).not.toBe(first)
+  })
+})

package/app/utils/laneIdentity.ts

@@ -0,0 +1,102 @@
+import type { LaneGroup, LaneTaskEntry, RenderedLane } from '~/utils/laneSort'
+
+// ---------------------------------------------------------------------------
+// Structural sharing for the swimlane output.
+//
+// WHY. The lane assembly (`useFrameLanes`) is a chain of computeds over the board blocks, both
+// pending-gate indexes, the coarse agent-run summary and the open notifications. Any ONE execution
+// event invalidates the whole chain for EVERY mounted frame, and the chain rebuilds every entry,
+// every group and every lane as fresh objects. Vue then sees new identities all the way down, so
+// `TaskLane` / `LaneGroup` re-render and every card diff re-runs, even for the (common) case where
+// the event changed one run's progress and moved nothing.
+//
+// WHAT THIS DOES. Compare the freshly built value against the previous one field by field and hand
+// BACK the previous object wherever nothing changed, so `===` holds for the parts that did not
+// move. Reuse cascades: unchanged entries let a group be reused, unchanged groups let a lane be
+// reused, unchanged lanes let the whole array be reused.
+//
+// THE CORRECTNESS RULE. Reuse is only sound when the reused object is observationally identical to
+// the fresh one, so the comparison must cover every DERIVED field: a value this assembly computed
+// (`moduleName`, `initiativeName`, `epicName`, the activity/wait stamps) exists only on the entry,
+// so a reused entry carrying a stale one is a lie nothing else can correct. That is why
+// {@link sameEntry} destructures rather than looping over keys, and why a field added to
+// `LaneTaskEntry` must be added to it in the same change.
+//
+// `task` is compared by REFERENCE, and that is NOT because the board store always replaces the
+// object: `stores/board/placement.ts` patches a block IN PLACE for its optimistic drag, reparent and
+// field edits, so the previous entry and the fresh one hold the very same object. Reference equality
+// is still the right comparison, for a different reason on each side. A REPLACED block (every
+// `board.upsert`, i.e. every server-sourced write) is a new reference, so it is caught here. A block
+// patched IN PLACE is one object that both entries share, so a renderer reading through the reused
+// entry reads the new value, and `board.blocks` is deeply reactive, so the mutation itself
+// invalidates whatever read it. What the mutation cannot reach is a value DERIVED off it, which is
+// exactly what the field comparison above covers.
+// ---------------------------------------------------------------------------
+
+function sameEntry(a: LaneTaskEntry, b: LaneTaskEntry): boolean {
+  return (
+    a.task === b.task &&
+    a.reason === b.reason &&
+    a.order === b.order &&
+    a.activityAt === b.activityAt &&
+    a.waitingSince === b.waitingSince &&
+    a.moduleName === b.moduleName &&
+    a.initiativeName === b.initiativeName &&
+    a.epicName === b.epicName
+  )
+}
+
+/** Element-wise reuse: the previous array when every member matched, else the fresh one. */
+function shareList<T>(
+  previous: readonly T[] | undefined,
+  next: T[],
+  same: (a: T, b: T) => boolean,
+  reuse?: (previous: T, next: T) => T,
+): T[] {
+  if (!previous || previous.length !== next.length) return next
+  let changed = false
+  const shared = next.map((item, i) => {
+    const prior = previous[i]!
+    if (same(prior, item)) return prior
+    const merged = reuse ? reuse(prior, item) : item
+    if (merged !== prior) changed = true
+    return merged
+  })
+  return changed ? shared : (previous as T[])
+}
+
+function sameGroup(a: LaneGroup, b: LaneGroup): boolean {
+  return a.id === b.id && a.label === b.label && a.entries === b.entries
+}
+
+function reuseGroup(previous: LaneGroup, next: LaneGroup): LaneGroup {
+  if (previous.id !== next.id || previous.label !== next.label) return next
+  const entries = shareList(previous.entries, next.entries, sameEntry)
+  return entries === previous.entries ? previous : { ...next, entries }
+}
+
+function sameLane(a: RenderedLane, b: RenderedLane): boolean {
+  return a.lane === b.lane && a.total === b.total && a.groups === b.groups
+}
+
+function reuseLane(previous: RenderedLane, next: RenderedLane): RenderedLane {
+  if (previous.lane !== next.lane || previous.total !== next.total) return next
+  const groups = shareList(previous.groups, next.groups, sameGroup, reuseGroup)
+  return groups === previous.groups ? previous : { ...next, groups }
+}
+
+/**
+ * A per-frame memo that hands back the previously rendered lanes wherever the freshly assembled
+ * ones are identical.
+ *
+ * Holds ONE generation, not a cache: the previous result is the only thing a recompute can share
+ * with, so there is nothing to evict and nothing to bound. Created per `useFrameLanes` instance, so
+ * it lives and dies with the frame that owns it.
+ */
+export function createLaneMemo(): (next: RenderedLane[]) => RenderedLane[] {
+  let previous: RenderedLane[] | undefined
+  return (next) => {
+    previous = shareList(previous, next, sameLane, reuseLane)
+    return previous
+  }
+}

package/app/utils/laneSort.ts

@@ -179,8 +179,26 @@ const NEEDS_YOU_TIER: Partial<Record<LaneReason, number>> = {
 
 type Comparator = (a: LaneTaskEntry, b: LaneTaskEntry) => number
 
+/**
+ * One collator for every text comparison in this module, built lazily and reused.
+ *
+ * `String.prototype.localeCompare` constructs a fresh collator per CALL, and these comparators run
+ * O(n log n) times per lane per frame on every board event: the `task_type` comparator alone made
+ * two of those calls per comparison. Constructing the collator once turns the dominant cost of a
+ * text sort back into the comparison itself.
+ *
+ * Built with NO options, so it is the same collation `a.localeCompare(b)` performed: this is a
+ * caching change, and a lane whose order shifted under it would be a behaviour change nobody asked
+ * for wearing a performance change's clothes.
+ */
+let collator: Intl.Collator | undefined
+function compareText(a: string, b: string): number {
+  collator ??= new Intl.Collator()
+  return collator.compare(a, b)
+}
+
 const EXPLICIT_COMPARATORS: Record<Exclude<LaneSortKey, 'smart'>, Comparator> = {
-  title: (a, b) => a.task.title.localeCompare(b.task.title),
+  title: (a, b) => compareText(a.task.title, b.task.title),
   oldest_activity: (a, b) => nullsLast(a.activityAt, b.activityAt, ascending),
   newest_activity: (a, b) => nullsLast(a.activityAt, b.activityAt, descending),
   longest_wait: (a, b) => nullsLast(a.waitingSince, b.waitingSince, ascending),
@@ -188,8 +206,8 @@ const EXPLICIT_COMPARATORS: Record<Exclude<LaneSortKey, 'smart'>, Comparator> =
   impact_desc: (a, b) =>
     nullsLast(a.task.estimate?.impact ?? null, b.task.estimate?.impact ?? null, descending),
   task_type: (a, b) =>
-    (a.task.taskType ?? '').localeCompare(b.task.taskType ?? '') ||
-    a.task.title.localeCompare(b.task.title),
+    compareText(a.task.taskType ?? '', b.task.taskType ?? '') ||
+    compareText(a.task.title, b.task.title),
 }
 
 /**
@@ -242,6 +260,20 @@ export interface LaneGroup {
   readonly entries: LaneTaskEntry[]
 }
 
+/**
+ * One rendered lane: its identity, its groups, and the count its header states.
+ *
+ * Lives beside the shapes it composes rather than in `composables/useFrameLanes`, which assembles
+ * it: `utils/laneIdentity.ts` compares these, and a util reaching into a composable for its central
+ * type points the dependency the wrong way round.
+ */
+export interface RenderedLane {
+  readonly lane: TaskLane
+  readonly groups: LaneGroup[]
+  /** Every task classified into this lane, BEFORE the Done lane's caps. */
+  readonly total: number
+}
+
 /**
  * The value a task is grouped under, or null for the catch-all group.
  *

package/i18n/locales/de.json

@@ -3426,8 +3426,8 @@
       "proxyHeading": "Proxy-/Gateway-API-Schlüssel",
       "directAccountIntro": "Verbinden Sie einen Vendor-API-Schlüssel, der von jedem Workspace in diesem Account geteilt wird. Schlüssel werden verschlüsselt gespeichert, gepoolt und nach Nutzung rotiert. Account-Schlüssel werden vom Administrator verwaltet.",
       "directIntro": "Verbinden Sie einen Vendor-API-Schlüssel, damit Modelle direkt bei diesem Provider laufen. Schlüssel werden verschlüsselt gespeichert, gepoolt und nach Nutzung rotiert. Beschränken Sie einen Schlüssel auf diesen Workspace (mit dem Team geteilt) oder auf sich selbst (Ihr eigener Pool, überall nutzbar).",
-      "proxyAccountIntro": "Verbinden Sie einen Proxy-Schlüssel (OpenRouter, LiteLLM), der von jedem Workspace in diesem Account geteilt wird. Ein Proxy ist ein Vermittler, der viele Vendors hinter einem einzigen Schlüssel bündelt. Schlüssel werden verschlüsselt gespeichert, gepoolt und nach Nutzung rotiert.",
-      "proxyIntro": "Verbinden Sie einen Proxy-Schlüssel (OpenRouter, LiteLLM). Ein Proxy ist ein Vermittler, der die Modelle vieler Vendors über ein einziges Gateway erreicht, statt direkt bei einem Vendor. Schlüssel werden verschlüsselt gespeichert, gepoolt und nach Nutzung rotiert. Beschränken Sie einen Schlüssel auf diesen Workspace (mit dem Team geteilt) oder auf sich selbst (Ihr eigener Pool, überall nutzbar).",
+      "proxyAccountIntro": "Verbinden Sie einen Proxy-Schlüssel (OpenRouter, Bifrost, LiteLLM), der von jedem Workspace in diesem Account geteilt wird. Ein Proxy ist ein Vermittler, der viele Vendors hinter einem einzigen Schlüssel bündelt. Schlüssel werden verschlüsselt gespeichert, gepoolt und nach Nutzung rotiert.",
+      "proxyIntro": "Verbinden Sie einen Proxy-Schlüssel (OpenRouter, Bifrost, LiteLLM). Ein Proxy ist ein Vermittler, der die Modelle vieler Vendors über ein einziges Gateway erreicht, statt direkt bei einem Vendor. Schlüssel werden verschlüsselt gespeichert, gepoolt und nach Nutzung rotiert. Beschränken Sie einen Schlüssel auf diesen Workspace (mit dem Team geteilt) oder auf sich selbst (Ihr eigener Pool, überall nutzbar).",
       "scopeField": "Geltungsbereich",
       "scopeWorkspace": "Dieser Workspace",
       "scopeUser": "Meine Schlüssel (nur ich)",
@@ -3485,6 +3485,11 @@
           "step1": "Öffnen Sie openrouter.ai → Keys und erstellen Sie einen API-Schlüssel.",
           "step2": "Kopieren Sie den Schlüssel (beginnt mit sk-or-…); er erreicht über ein Gateway mehr als 300 Modelle."
         },
+        "bifrost": {
+          "label": "Bifrost (selbst gehostetes Gateway)",
+          "step1": "Erstellen Sie einen virtuellen Schlüssel in den Governance-Einstellungen Ihres Bifrost-Gateways (oder verwenden Sie dessen API-Schlüssel).",
+          "step2": "Die Basis-URL des Gateways wird von Ihrem Deployment-Betreiber festgelegt (BIFROST_BASE_URL), nicht hier."
+        },
         "litellm": {
           "label": "LiteLLM (selbst gehostetes Gateway)",
           "step1": "Erstellen Sie einen virtuellen Schlüssel auf Ihrem LiteLLM-Gateway (oder verwenden Sie dessen Master Key).",

package/i18n/locales/en.json

@@ -4334,8 +4334,8 @@
       "proxyHeading": "Proxy / gateway API keys",
       "directAccountIntro": "Connect a vendor API key shared by every workspace in this account. Keys are stored encrypted, pooled, and rotated by usage. Account keys are admin-managed.",
       "directIntro": "Connect a vendor API key so models run directly on that provider. Keys are stored encrypted, pooled, and rotated by usage. Scope a key to this workspace (shared with the team) or to you (your own pool, usable anywhere).",
-      "proxyAccountIntro": "Connect a proxy key (OpenRouter, LiteLLM) shared by every workspace in this account. A proxy is an intermediary that fronts many vendors behind a single key. Keys are stored encrypted, pooled, and rotated by usage.",
-      "proxyIntro": "Connect a proxy key (OpenRouter, LiteLLM). A proxy is an intermediary that reaches many vendors' models through a single gateway, rather than one vendor directly. Keys are stored encrypted, pooled, and rotated by usage. Scope a key to this workspace (shared with the team) or to you (your own pool, usable anywhere).",
+      "proxyAccountIntro": "Connect a proxy key (OpenRouter, Bifrost, LiteLLM) shared by every workspace in this account. A proxy is an intermediary that fronts many vendors behind a single key. Keys are stored encrypted, pooled, and rotated by usage.",
+      "proxyIntro": "Connect a proxy key (OpenRouter, Bifrost, LiteLLM). A proxy is an intermediary that reaches many vendors' models through a single gateway, rather than one vendor directly. Keys are stored encrypted, pooled, and rotated by usage. Scope a key to this workspace (shared with the team) or to you (your own pool, usable anywhere).",
       "scopeField": "Scope",
       "scopeWorkspace": "This workspace",
       "scopeUser": "My keys (only me)",
@@ -4396,6 +4396,11 @@
           "step1": "Open openrouter.ai → Keys and create an API key.",
           "step2": "Copy the key (starts with sk-or-…); it reaches 300+ models through one gateway."
         },
+        "bifrost": {
+          "label": "Bifrost (self-hosted gateway)",
+          "step1": "Create a virtual key in your Bifrost gateway's governance settings (or use its API key).",
+          "step2": "The gateway's base URL is set by your deployment operator (BIFROST_BASE_URL), not here."
+        },
         "litellm": {
           "label": "LiteLLM (self-hosted gateway)",
           "step1": "Generate a virtual key on your LiteLLM gateway (or use its master key).",

package/i18n/locales/es.json

@@ -4188,8 +4188,8 @@
       "proxyHeading": "Claves de API de proxy / pasarela",
       "directAccountIntro": "Conecta una clave de API de proveedor compartida por todos los espacios de trabajo de esta cuenta. Las claves se almacenan cifradas, se agrupan y se rotan según el uso. Las claves de cuenta las gestiona un administrador.",
       "directIntro": "Conecta una clave de API de proveedor para que los modelos se ejecuten directamente en ese proveedor. Las claves se almacenan cifradas, se agrupan y se rotan según el uso. Asigna el alcance de una clave a este espacio de trabajo (compartida con el equipo) o a ti (tu propio grupo, usable en cualquier sitio).",
-      "proxyAccountIntro": "Conecta una clave de proxy (OpenRouter, LiteLLM) compartida por todos los espacios de trabajo de esta cuenta. Un proxy es un intermediario que da acceso a muchos proveedores tras una sola clave. Las claves se almacenan cifradas, se agrupan y se rotan según el uso.",
-      "proxyIntro": "Conecta una clave de proxy (OpenRouter, LiteLLM). Un proxy es un intermediario que llega a los modelos de muchos proveedores a través de una sola pasarela, en lugar de un proveedor directo. Las claves se almacenan cifradas, se agrupan y se rotan según el uso. Asigna el alcance de una clave a este espacio de trabajo (compartida con el equipo) o a ti (tu propio grupo, usable en cualquier sitio).",
+      "proxyAccountIntro": "Conecta una clave de proxy (OpenRouter, Bifrost, LiteLLM) compartida por todos los espacios de trabajo de esta cuenta. Un proxy es un intermediario que da acceso a muchos proveedores tras una sola clave. Las claves se almacenan cifradas, se agrupan y se rotan según el uso.",
+      "proxyIntro": "Conecta una clave de proxy (OpenRouter, Bifrost, LiteLLM). Un proxy es un intermediario que llega a los modelos de muchos proveedores a través de una sola pasarela, en lugar de un proveedor directo. Las claves se almacenan cifradas, se agrupan y se rotan según el uso. Asigna el alcance de una clave a este espacio de trabajo (compartida con el equipo) o a ti (tu propio grupo, usable en cualquier sitio).",
       "scopeField": "Alcance",
       "scopeWorkspace": "Este espacio de trabajo",
       "scopeUser": "Mis claves (solo yo)",
@@ -4247,6 +4247,11 @@
           "step1": "Abre openrouter.ai → Keys y crea una clave de API.",
           "step2": "Copia la clave (empieza por sk-or-…); llega a más de 300 modelos a través de una sola pasarela."
         },
+        "bifrost": {
+          "label": "Bifrost (pasarela autoalojada)",
+          "step1": "Genera una clave virtual en los ajustes de gobernanza de tu pasarela Bifrost (o usa su clave de API).",
+          "step2": "La URL base de la pasarela la establece el operador de tu despliegue (BIFROST_BASE_URL), no aquí."
+        },
         "litellm": {
           "label": "LiteLLM (pasarela autoalojada)",
           "step1": "Genera una clave virtual en tu pasarela LiteLLM (o usa su clave maestra).",

package/i18n/locales/fr.json

@@ -4188,8 +4188,8 @@
       "proxyHeading": "Clés d'API de proxy / passerelle",
       "directAccountIntro": "Connectez une clé d'API de fournisseur partagée par tous les espaces de travail de ce compte. Les clés sont stockées chiffrées, mutualisées et alternées selon l'usage. Les clés de compte sont gérées par un administrateur.",
       "directIntro": "Connectez une clé d'API de fournisseur pour que les modèles s'exécutent directement chez ce fournisseur. Les clés sont stockées chiffrées, mutualisées et alternées selon l'usage. Définissez la portée d'une clé sur cet espace de travail (partagée avec l'équipe) ou sur vous (votre propre pool, utilisable partout).",
-      "proxyAccountIntro": "Connectez une clé de proxy (OpenRouter, LiteLLM) partagée par tous les espaces de travail de ce compte. Un proxy est un intermédiaire qui donne accès à de nombreux fournisseurs derrière une seule clé. Les clés sont stockées chiffrées, mutualisées et alternées selon l'usage.",
-      "proxyIntro": "Connectez une clé de proxy (OpenRouter, LiteLLM). Un proxy est un intermédiaire qui atteint les modèles de nombreux fournisseurs via une seule passerelle, plutôt qu'un fournisseur direct. Les clés sont stockées chiffrées, mutualisées et alternées selon l'usage. Définissez la portée d'une clé sur cet espace de travail (partagée avec l'équipe) ou sur vous (votre propre pool, utilisable partout).",
+      "proxyAccountIntro": "Connectez une clé de proxy (OpenRouter, Bifrost, LiteLLM) partagée par tous les espaces de travail de ce compte. Un proxy est un intermédiaire qui donne accès à de nombreux fournisseurs derrière une seule clé. Les clés sont stockées chiffrées, mutualisées et alternées selon l'usage.",
+      "proxyIntro": "Connectez une clé de proxy (OpenRouter, Bifrost, LiteLLM). Un proxy est un intermédiaire qui atteint les modèles de nombreux fournisseurs via une seule passerelle, plutôt qu'un fournisseur direct. Les clés sont stockées chiffrées, mutualisées et alternées selon l'usage. Définissez la portée d'une clé sur cet espace de travail (partagée avec l'équipe) ou sur vous (votre propre pool, utilisable partout).",
       "scopeField": "Portée",
       "scopeWorkspace": "Cet espace de travail",
       "scopeUser": "Mes clés (moi uniquement)",
@@ -4247,6 +4247,11 @@
           "step1": "Ouvrez openrouter.ai → Keys et créez une clé d'API.",
           "step2": "Copiez la clé (commence par sk-or-…) ; elle atteint plus de 300 modèles via une seule passerelle."
         },
+        "bifrost": {
+          "label": "Bifrost (passerelle auto-hébergée)",
+          "step1": "Générez une clé virtuelle dans les paramètres de gouvernance de votre passerelle Bifrost (ou utilisez sa clé d'API).",
+          "step2": "L'URL de base de la passerelle est définie par l'opérateur de votre déploiement (BIFROST_BASE_URL), pas ici."
+        },
         "litellm": {
           "label": "LiteLLM (passerelle auto-hébergée)",
           "step1": "Générez une clé virtuelle sur votre passerelle LiteLLM (ou utilisez sa clé maîtresse).",

package/i18n/locales/he.json

@@ -4188,8 +4188,8 @@
       "proxyHeading": "מפתחות API של פרוקסי / שער",
       "directAccountIntro": "חבר מפתח API של ספק המשותף לכל סביבות העבודה בחשבון זה. המפתחות נשמרים מוצפנים, מאוגדים ומסובבים לפי שימוש. מפתחות חשבון מנוהלים על ידי מנהל.",
       "directIntro": "חבר מפתח API של ספק כדי שמודלים ירוצו ישירות על אותו ספק. המפתחות נשמרים מוצפנים, מאוגדים ומסובבים לפי שימוש. הגדר היקף למפתח לסביבת עבודה זו (משותף עם הצוות) או לעצמך (המאגר שלך, שמיש בכל מקום).",
-      "proxyAccountIntro": "חבר מפתח פרוקסי (OpenRouter, LiteLLM) המשותף לכל סביבות העבודה בחשבון זה. פרוקסי הוא מתווך החזית בפני ספקים רבים מאחורי מפתח יחיד. המפתחות נשמרים מוצפנים, מאוגדים ומסובבים לפי שימוש.",
-      "proxyIntro": "חבר מפתח פרוקסי (OpenRouter, LiteLLM). פרוקסי הוא מתווך המגיע למודלים של ספקים רבים דרך שער יחיד, במקום אל ספק יחיד ישירות. המפתחות נשמרים מוצפנים, מאוגדים ומסובבים לפי שימוש. הגדר היקף למפתח לסביבת עבודה זו (משותף עם הצוות) או לעצמך (המאגר שלך, שמיש בכל מקום).",
+      "proxyAccountIntro": "חבר מפתח פרוקסי (OpenRouter, Bifrost, LiteLLM) המשותף לכל סביבות העבודה בחשבון זה. פרוקסי הוא מתווך החזית בפני ספקים רבים מאחורי מפתח יחיד. המפתחות נשמרים מוצפנים, מאוגדים ומסובבים לפי שימוש.",
+      "proxyIntro": "חבר מפתח פרוקסי (OpenRouter, Bifrost, LiteLLM). פרוקסי הוא מתווך המגיע למודלים של ספקים רבים דרך שער יחיד, במקום אל ספק יחיד ישירות. המפתחות נשמרים מוצפנים, מאוגדים ומסובבים לפי שימוש. הגדר היקף למפתח לסביבת עבודה זו (משותף עם הצוות) או לעצמך (המאגר שלך, שמיש בכל מקום).",
       "scopeField": "היקף",
       "scopeWorkspace": "סביבת עבודה זו",
       "scopeUser": "המפתחות שלי (רק אני)",
@@ -4247,6 +4247,11 @@
           "step1": "פתח את openrouter.ai → Keys וצור מפתח API.",
           "step2": "העתק את המפתח (מתחיל ב-sk-or-…); הוא מגיע ל-300+ מודלים דרך שער יחיד."
         },
+        "bifrost": {
+          "label": "Bifrost (שער באירוח עצמי)",
+          "step1": "צור מפתח וירטואלי בהגדרות הבקרה של שער Bifrost שלך (או השתמש במפתח ה-API שלו).",
+          "step2": "כתובת הבסיס של השער נקבעת על ידי מפעיל הפריסה שלך (BIFROST_BASE_URL), ולא כאן."
+        },
         "litellm": {
           "label": "LiteLLM (שער בארחה עצמית)",
           "step1": "צור מפתח וירטואלי בשער LiteLLM שלך (או השתמש במפתח המאסטר שלו).",

package/i18n/locales/it.json

@@ -3426,8 +3426,8 @@
       "proxyHeading": "Chiavi API proxy / gateway",
       "directAccountIntro": "Collega una chiave API di un vendor condivisa da ogni workspace di questo account. Le chiavi vengono memorizzate in forma cifrata, raggruppate e ruotate in base all'utilizzo. Le chiavi dell'account sono gestite dall'amministratore.",
       "directIntro": "Collega una chiave API di un vendor così i modelli vengono eseguiti direttamente su quel provider. Le chiavi vengono memorizzate in forma cifrata, raggruppate e ruotate in base all'utilizzo. Assegna l'ambito di una chiave a questo workspace (condivisa con il team) o a te (il tuo pool personale, utilizzabile ovunque).",
-      "proxyAccountIntro": "Collega una chiave proxy (OpenRouter, LiteLLM) condivisa da ogni workspace di questo account. Un proxy è un intermediario che fa da facciata a molti vendor dietro un'unica chiave. Le chiavi vengono memorizzate in forma cifrata, raggruppate e ruotate in base all'utilizzo.",
-      "proxyIntro": "Collega una chiave proxy (OpenRouter, LiteLLM). Un proxy è un intermediario che raggiunge i modelli di molti vendor attraverso un unico gateway, anziché un singolo vendor direttamente. Le chiavi vengono memorizzate in forma cifrata, raggruppate e ruotate in base all'utilizzo. Assegna l'ambito di una chiave a questo workspace (condivisa con il team) o a te (il tuo pool personale, utilizzabile ovunque).",
+      "proxyAccountIntro": "Collega una chiave proxy (OpenRouter, Bifrost, LiteLLM) condivisa da ogni workspace di questo account. Un proxy è un intermediario che fa da facciata a molti vendor dietro un'unica chiave. Le chiavi vengono memorizzate in forma cifrata, raggruppate e ruotate in base all'utilizzo.",
+      "proxyIntro": "Collega una chiave proxy (OpenRouter, Bifrost, LiteLLM). Un proxy è un intermediario che raggiunge i modelli di molti vendor attraverso un unico gateway, anziché un singolo vendor direttamente. Le chiavi vengono memorizzate in forma cifrata, raggruppate e ruotate in base all'utilizzo. Assegna l'ambito di una chiave a questo workspace (condivisa con il team) o a te (il tuo pool personale, utilizzabile ovunque).",
       "scopeField": "Ambito",
       "scopeWorkspace": "Questo workspace",
       "scopeUser": "Le mie chiavi (solo io)",
@@ -3485,6 +3485,11 @@
           "step1": "Apri openrouter.ai → Keys e crea una chiave API.",
           "step2": "Copia la chiave (inizia con sk-or-…); raggiunge oltre 300 modelli attraverso un unico gateway."
         },
+        "bifrost": {
+          "label": "Bifrost (gateway self-hosted)",
+          "step1": "Genera una chiave virtuale nelle impostazioni di governance del tuo gateway Bifrost (oppure usa la sua chiave API).",
+          "step2": "L'URL di base del gateway viene impostato dall'operatore del tuo deployment (BIFROST_BASE_URL), non qui."
+        },
         "litellm": {
           "label": "LiteLLM (gateway self-hosted)",
           "step1": "Genera una chiave virtuale sul tuo gateway LiteLLM (oppure usa la sua chiave master).",

package/i18n/locales/ja.json

@@ -4188,8 +4188,8 @@
       "proxyHeading": "プロキシ / ゲートウェイの API キー",
       "directAccountIntro": "このアカウントの全ワークスペースで共有するベンダー API キーを接続します。キーは暗号化して保存され、プールされて利用状況に応じてローテーションされます。アカウントキーは管理者が管理します。",
       "directIntro": "ベンダー API キーを接続すると、モデルがそのプロバイダー上で直接実行されます。キーは暗号化して保存され、プールされて利用状況に応じてローテーションされます。キーのスコープをこのワークスペース (チームで共有) または自分専用 (どこでも使える自分のプール) に設定できます。",
-      "proxyAccountIntro": "このアカウントの全ワークスペースで共有するプロキシキー (OpenRouter、LiteLLM) を接続します。プロキシは、単一のキーで多数のベンダーをまとめる仲介役です。キーは暗号化して保存され、プールされて利用状況に応じてローテーションされます。",
-      "proxyIntro": "プロキシキー (OpenRouter、LiteLLM) を接続します。プロキシは、各ベンダーに直接ではなく、単一のゲートウェイを通じて多数のベンダーのモデルに到達する仲介役です。キーは暗号化して保存され、プールされて利用状況に応じてローテーションされます。キーのスコープをこのワークスペース (チームで共有) または自分専用 (どこでも使える自分のプール) に設定できます。",
+      "proxyAccountIntro": "このアカウントの全ワークスペースで共有するプロキシキー (OpenRouter、Bifrost、LiteLLM) を接続します。プロキシは、単一のキーで多数のベンダーをまとめる仲介役です。キーは暗号化して保存され、プールされて利用状況に応じてローテーションされます。",
+      "proxyIntro": "プロキシキー (OpenRouter、Bifrost、LiteLLM) を接続します。プロキシは、各ベンダーに直接ではなく、単一のゲートウェイを通じて多数のベンダーのモデルに到達する仲介役です。キーは暗号化して保存され、プールされて利用状況に応じてローテーションされます。キーのスコープをこのワークスペース (チームで共有) または自分専用 (どこでも使える自分のプール) に設定できます。",
       "scopeField": "スコープ",
       "scopeWorkspace": "このワークスペース",
       "scopeUser": "自分のキー (自分のみ)",
@@ -4247,6 +4247,11 @@
           "step1": "openrouter.ai → Keys を開き、API キーを作成します。",
           "step2": "キー (sk-or-… で始まる) をコピーします。1 つのゲートウェイで 300 以上のモデルに到達します。"
         },
+        "bifrost": {
+          "label": "Bifrost (セルフホストゲートウェイ)",
+          "step1": "Bifrost ゲートウェイのガバナンス設定で仮想キーを生成します (または API キーを使用します)。",
+          "step2": "ゲートウェイのベース URL は、ここではなくデプロイ運用者が設定します (BIFROST_BASE_URL)。"
+        },
         "litellm": {
           "label": "LiteLLM (セルフホストゲートウェイ)",
           "step1": "LiteLLM ゲートウェイで仮想キーを生成します (またはマスターキーを使用します)。",