VIBECHAT-DESIGN-PROPOSAL.md

VibeChat / AskUnit + Toast pull-into-standalones — Design Investigation

Author: Mavis (operator panel session 412100071272671)

Date: 2026-07-15

Status: Investigation complete. Awaiting operator decisions before design lock.

What I read (so the proposal is grounded, not guessed)

Oscar source (avidtech6/oscar-platform, private repo)

FVS Studio source (avidtech6/freshvibestudio, private repo)

The 3 standalones (private repos)

All 3 have @mantine/notifications already in deps. The Notifications provider IS a toast system, but it's a different shape from ResultToast (no input bar, no AI state, no thread bundle).

FVS pact

What the operator asked for (paraphrased)

  1. Pull AskUnit + Toast into each of the 3 standalones — they need a chat story. The standalones are apps; users expect an AI assistant in them.
  2. Move away from the VibePanel as it is today — it was a desktop-only chat panel. Oscar's AskUnit pattern (input bar at the bottom, present on EVERY page, in both desktop and mobile) is the better shape.
  3. VibeChat is crucial for VibeCoder and VibeScope — it's how the user controls the app. The assistant IS the access to the entire app.
  4. Standalones should have a credential store — their own LLM keys, local to the app. When plugged into FVS, the credential store can be shared.
  5. Standalones should be aware of each other — but not share chat threads. If someone is talking in VibeCoder about FreshCards, and then switches to FreshCards, the chat should know it's a different workspace.
  6. VibeChat should be its own thing — not the same conversation across workspaces.

The fundamental design tension

> "I want vibe chat in each standalone, but I don't want it shared across workspaces. And I want standalones to be aware of each other but not share threads."

Reading the code, the actual question is:

Architecture proposal (read this carefully)

Tier 1: The portable module shape

What I propose: create a new constitutional module that lives at avidtech6/ai-shell (a NEW repo — a portable AI shell). Both Oscar and the 3 standalones depend on it. FVS Studio optionally depends on it too (drop-in replacement for the existing chat + credential modules).

ai-shell exports:

Shape (per-workspace / per-app):

aiShell.configure({
  workspaceId: 'freshcards',           // or 'vibecoder' / 'vibescope' / 'oscar' / 'origin'
  appId: 'freshcards-standalone',      // identifies the standalone
  mode: 'standalone' | 'studio',       // decides which credential backend to use
  crossWorkspaceAwareness: true,       // show "other apps exist" hint, don't share threads
  providers: [...],                    // injected from the provider registry
  indexedDB: {                         // optional persistence
    name: 'freshcards-ai',
    stores: ['threads', 'credentials']
  }
})

Cross-app awareness (operator's ask): a small "Workspaces" chip in the top bar of each standalone that shows the OTHER apps (FreshCards, VibeCoder, VibeScope, Oscar, my.freshvibeapps.com, panel) with a one-click link. Threads are never shared. When you click a chip, you navigate to the other app; the chat there is independent. The chip also shows "currently active" if you're in FVS Studio.

Tier 2: Cross-app "plug-in" mode (when the standalone is back in FVS)

The operator said: "when it's no longer stand alone they need to have a shared awareness of each other and a shared workspace I guess."

I read this as: when you put a standalone BACK into FVS Studio, the credential store and thread store should sync from the standalone's local IndexedDB to the FVS PocketBase backend. Not the other way around.

Tier 3: The Toast pattern (universal)

Both Oscar's ResultToast and FVS's notifications serve the same purpose. The ai-shell module should ship:

The 3 standalones should drop their @mantine/notifications import and use ai-shell's toast. (Keeps the toast UI consistent across all 4 apps.)

What needs to happen in the standalones (concrete)

FreshCards standalone

  1. Add ai-shell dep
  2. Wrap FreshCardsApp in
  3. Add mounted in the shell footer (always visible, mobile + desktop)
  4. Add to the root
  5. Add the "Workspaces" cross-app chip in the top bar

VibeCoder standalone

  1. Add ai-shell dep
  2. Wrap VibeCoderApp in
  3. The AskUnit's "context" (the agent's systemPromptBuilder) needs to know which file is open, which cursor position, etc. — plug the CoderStrip from FVS into the AgentContainer slot
  4. Add to the root
  5. Add the "Workspaces" cross-app chip

VibeScope standalone

  1. Add ai-shell dep
  2. Wrap in
  3. The AskUnit's systemPromptBuilder needs to know the active layer, the cinema/dev layout, the engine — same AgentContainer slot pattern
  4. Add to the root
  5. Add the "Workspaces" cross-app chip

What needs to happen in Oscar

  1. Rename oscar-ask-unit → ai-shell (or extract into shared). The Oscar copy is the most mature reference. Lift it verbatim, with the workspaceId/single-tenant adaptations in the same file.
  2. Replace oscar-credential-surface with the shared ai-shell/useCredentials. Same single-tenant in-memory store, with the 'fvs:credential-removed' event preserved.
  3. Replace assistant/ResultToast with ai-shell/ToastHost. Same shape, same pushToast() API.
  4. Add the "Workspaces" cross-app chip at the top of OscarShell.

What needs to happen in FVS Studio (optional, not blocking)

  1. The VibePanel (in chrome/vibe-panel/) gets refactored to use the ai-shell AskUnit as the visual, with the panel's chrome around it. The existing ChatFrame is retired.
  2. The chat/, credential-surface/, providers/, coder-chat/, vibechat-signals/ modules are deprecated in favour of the single ai-shell import.
  3. The AgentContainer slot in FVS's ChatFrame becomes the AskUnit's built-in extension point (no separate module).

Decisions needed from operator before design lock

  1. Should ai-shell be a new repo or a module in avidtech6/freshvibestudio?
  2. New repo: cleaner separation, 4 apps depend on it directly, but adds a 5th repo to maintain.
  3. Module in freshvibestudio: 3 standalones + Oscar import from a public path (raw.githubusercontent or pinned version).
  1. Where do the standalones get the ai-shell code from?
  2. npm package (private registry?)
  3. Vite alias to a sibling ai-shell/ directory
  4. Direct git submodule
  1. Thread persistence in standalone mode:
  2. IndexedDB always (operator's likely choice — local-first)
  3. localStorage (simpler, smaller, no schema)
  4. File system export (operators can sync via dropbox etc.)
  1. Credential persistence in standalone mode:
  2. IndexedDB encrypted with a passphrase the user sets in the credential surface
  3. Plain IndexedDB (matches Oscar v0.1)
  4. localStorage with a warning ("keys are visible to anyone on this device")
  1. Cross-app "Workspaces" chip:
  2. Just a static list of links to the other apps
  3. Smart — shows "you have 3 unread threads in FreshCards" (requires cross-app sync)
  4. Hidden by default, toggled via the user chip menu
  1. VibeCoder's "systemPromptBuilder" context:
  2. Reads the active file, cursor, diagnostics, recent edit history
  3. Just reads the active file
  4. No context — the user pastes code in the AskUnit themselves
  1. VibeScope's "systemPromptBuilder" context:
  2. Reads the active layer + properties (selected layer's type, position, fill, etc.)
  3. Just reads the active layer
  4. No context
  1. Toast migration for the 3 standalones:
  2. Drop @mantine/notifications entirely, use ai-shell/ToastHost only
  3. Keep @mantine/notifications for now, add ai-shell/ToastHost alongside
  4. The 3 standalones don't actually use @mantine/notifications much today (just Notifications provider mounted) — verify before refactoring

My recommendation (operator wants a real answer, not a menu)

1. New repo avidtech6/ai-shell. Oscar moves its oscar-ask-unit + oscar-credential-surface + assistant/ResultToast INTO it. The 3 standalones depend on it via Vite alias (sibling ../ai-shell/src).

2. IndexedDB for both threads and credentials in standalone mode. The IndexedDB schema is the same as PB's ai_threads schema, so the migrate() flush from local → PB on first integrated-mode launch is a straight INSERT loop.

3. The Workspaces chip is static (no unread counts) in v1. Smart in v2.

4. VibeCoder + VibeScope each ship with a single systemPromptBuilder that reads the active file / active layer. No cross-app context — the user types what they need.

5. Toast: drop @mantine/notifications from the 3 standalones entirely, use ai-shell/ToastHost only. The shape is a strict superset of what @mantine/notifications does.

What's NOT in this proposal (operator should flag if wanted)

Copied to clipboard