DDVibes

Private, internal-only Salesforce development assistant for VS Code. This is the first functional scaffold, not a connected AI product.

What works now

• A DDVibes Activity Bar container and chat webview.
• A guided Salesforce-first chat experience with plain-language starter prompts for Apex, Flows, and safe change planning; workspace and privacy controls are disclosed only when needed.
• Clean local chat UX with reviewable, per-conversation workspace context controls. Workspace name and active editor can be included explicitly; workspace folder paths are off by default.
• Multi-session chat history, always on, stored only in VS Code workspace storage per project. Up to 50 past conversations are kept (oldest dropped first), browsable and resumable from a history menu in the panel header, each deletable individually.
• An opt-in voice-input control with local-first provider boundaries, listening/transcribing/error UI states, and a typed fallback. This build does not request microphone access, capture audio, retain audio, or send audio externally because the VS Code webview cannot guarantee on-device recognition.
• A review-only DDVibes: Open Voice Task Intake entry point that shows where future voice-directed development requests will appear. An approved voice provider and verified identity gateway will create a written draft, which the user must review before sending.
• Typed contracts for conversations, requests, workspace context, identity, and proposed actions.
• Provider abstraction plus a regex-based routing policy (src/modelRouting.ts); DDVibes now calls OpenRouter for real chat responses, choosing an efficient or economic model tier depending on the message (see ROADMAP.md, Fase A).
• Provider-aware routing controls: users choose Automatic, Eficiente, or Econômico. Chat requests go through the DDVibes gateway, so the extension holds no OpenRouter key: a user signs in with their DDGroup Google account through DDVibes: Entrar and signs out with DDVibes: Sair. Only the opaque gateway session id is stored, in VS Code SecretStorage. Centrally managed routing policy, budgets, and Codex/ChatGPT handoff remain reserved for a future verified administrator (see ROADMAP.md, Fase D).
• Explicit local action proposals (/run <command> and /write <path> followed by content) appear as review cards in chat and are logged to the DDVibes Output panel. They remain hard-blocked behind an approval dialog; nothing is executed or written by the extension.

Architecture

src/extension.ts owns VS Code integration and the webview bridge. src/contracts.ts defines the boundary types. src/providers.ts holds provider adapters, while src/routing.ts is the future policy boundary for complexity, cost, corporate gateway, and per-user budget decisions.

DDVibes makes live chat requests to OpenRouter through the DDVibes gateway, authenticated by a gateway session obtained with Google sign-in (see ROADMAP.md, Fase A). The OpenRouter key lives only in the gateway; the extension never sees it. Cloud transcription, voice capture, diarization, and billing integrations are still not included. Chat history is local VS Code workspace storage only (capped at 50 conversations); it is not a long-term memory system.

Future voice-directed work

DDVibes does not connect to this ChatGPT or Codex voice call, Claude voice, or any subscription as an API. The future boundary is provider-neutral: an approved external voice source sends only a structured task-handoff envelope through a verified identity-backed gateway to DDVibes Voice Task Intake. Approved sources may include ChatGPT and Claude, but each needs a separately authorized integration, provider terms, and credentials outside DDVibes. DDVibes will show the resulting written draft for review and editing. The user must choose to send it, and no voice instruction can dispatch work automatically.

Today, the intake view is informational only. It captures no audio, requests no microphone permission, stores no transcript, calls no external API, and sends no task.

Reviewable development-task lifecycle

Use DDVibes: Open Development Task to inspect the local demonstration lifecycle for a future request such as “create a demo”. It moves through Draft, Planned, Awaiting approval, Approved, and Blocked. DDVibes uses a deterministic local plan in this demonstration. Approval only records the user decision; it does not run a command, write a file, call a model, or change code. Starting approved work remains visibly blocked until a future separately approved execution system is available.

Provider routing and configuration

DDVibes routes chat requests to OpenRouter using either a manually selected tier (Eficiente/Econômico) or, in Automatic mode, a regex-based classifier that inspects the message (src/modelRouting.ts). Complexity-, cost-, and identity-aware corporate policy is a future milestone (see ROADMAP.md, Fase D); until then this routing is local and heuristic only.

There is no per-user provider configuration and no local API key. Point the ddVibes.gatewayBaseUrl setting at the deployed gateway, run DDVibes: Entrar to sign in with the approved DDGroup Google account, and the gateway hands the extension an opaque session id, kept only in VS Code SecretStorage and sent as a bearer token on each chat request. DDVibes: Sair discards it; the gateway also expires sessions server-side, after which DDVibes asks for a new sign-in. Approving users and assigning roles happens in the gateway's own data store, never from the extension (DDVibes: Manage Approved Users only explains this).

Codex/ChatGPT subscriptions are not treated as embedded APIs. They will require an explicit handoff or integration in a future milestone. The typed governance boundary models administrator roles, allowed providers, and per-request/monthly budget limits so these rules can be centrally enforced later (see ROADMAP.md, Fase D).

DDVibes gateway

The gateway/ folder is a standalone Cloudflare Worker: it provides Google Workspace-restricted sign-in for the extension and a session-gated proxy to OpenRouter's chat-completions API. It is a separate TypeScript project, is not bundled into the extension, and is not deployed yet.

Its routes are /healthz, /readyz, /oauth/google/start, /oauth/google/callback, and POST /v1/chat/completions. Sign-in uses PKCE, one-time state, a nonce, and hosted-domain validation, then looks the verified Google subject up in the approved-user table before issuing an opaque server-side session; the callback hands that session id back to VS Code through the vscode://ddgroup.ddvibes/auth-callback URI. The chat route requires that session id as a bearer token and forwards the request to OpenRouter with the gateway's own key, so the key never reaches a developer machine. Approved users, roles, provider policy, audit records, and recovery metadata live in Cloudflare D1; short-lived OAuth transactions and active sessions live in a Durable Object; the OpenRouter key and the Google OAuth client secret are Workers Secrets.

The gateway fails closed. Until the public base URL, OAuth client id, hosted domain, ENABLE_GOOGLE_OAUTH=true, and both secrets are all set, /readyz returns 503 and the sign-in routes report that setup is required. No code path creates the first approved user automatically; an operator must insert exactly one verified Google subject as administrator directly in D1. See gateway/README.md for the deployment and operator checklist, which is the single source of truth for those steps.

Every computer is a disposable client in this design: source code lives in Git, and verified identity, approved users and roles, provider policy, audit records, and secrets live only in the gateway's managed storage. A new machine regains access by signing in again. First-administrator recovery must use a designated corporate Google administrator group or a documented break-glass procedure, never a hard-coded personal email.

Future Google governance flow

1. A corporate Google identity gateway signs a user in and verifies their Google identity.
2. During initial production setup, that verified gateway designates one owner as the initial Administrator. Every other approved Google identity starts as a Member.
3. The initial administrator reviews authenticated users inside DDVibes Administration and promotes Members when appropriate. DDVibes does not identify the owner locally and no personal email is hard-coded.
4. Administrators manage approved users, providers, routing policies, budgets, and audit settings through the corporate service.
5. Members see only the approved DDVibes chat experience.

Use DDVibes: Open Administration to inspect the locked future-facing administration view. It intentionally contains no user data or role-changing controls today. Without a corporate identity backend, client-only extension settings cannot securely enforce roles.

First Administrator activation

The Administration view includes a safe onboarding guide for the owner. It explains the future sequence: connect corporate Google identity, verify the sign-in, designate the first Administrator, then load approved users. The current button does not open a login or collect information.

Before this can be activated for real, a Google Workspace or Google Cloud administrator must approve the corporate identity connection once and configure the corporate gateway with its OAuth client. The gateway, not the extension, will verify the owner and designate the first Administrator.

Develop

npm install
npm run check

Press F5 in VS Code to launch an Extension Development Host, then select the DDVibes icon in the Activity Bar.

An inspectable visual preview is available at outputs/ddvibes-chat-preview.html.

Next milestones

1. Corporate gateway adapter with authenticated per-user identity and budget enforcement.
2. Model routing based on task complexity, cost, and policy.
3. Approved, auditable command and file-edit execution flows that enforce corporate policy.
4. Approved local speech-recognition integration, followed by a policy-controlled corporate transcription gateway when required.