Lumina AI - Intelligent Workspace

A new tab AI workspace for chat, page summaries, notes, reminders, app ideas, and browser actions.

# Lumina AI Project Description Lumina AI is a Manifest V3 Chrome extension that turns the browser into a developer-focused AI workspace. It is built around a simple but powerful idea: the browser is where a large amount of modern thinking, building, researching, debugging, writing, and planning already happens, so an AI assistant should live directly inside that browser workflow instead of forcing the user to keep switching to a separate application. The project replaces the default Chrome new tab page with a calm assistant workspace, adds an in-page assistant that can summarize and answer questions about normal websites, and includes a dedicated voice-only room for hands-free interaction. Together, these surfaces create a lightweight browser-native command center for developers, students, product builders, founders, and other power users who spend much of their workday moving between tabs, documentation, search results, notes, and AI conversations. The extension is intentionally small in its technical footprint. It does not use a frontend framework, a build system, a package manager, remote JavaScript, or a project-owned backend server. The user interface is written directly in HTML, CSS, and JavaScript. The extension uses Chrome extension APIs for storage, tab control, page scripting, alarms, notifications, and toolbar behavior. AI completions are sent directly to Groq's OpenAI-compatible chat completions endpoint using an API key saved locally in the browser. Optional ElevenLabs support appears in the main new tab runtime as a legacy or experimental path for higher-fidelity spoken replies, but the current dedicated voice room primarily uses browser speech recognition and browser speech synthesis. This design keeps the project easy to inspect, easy to modify, and easy to package for Chrome Web Store release. At a product level, Lumina AI is not just a chat box. It is a collection of browser workflows organized around the new tab page, the current webpage, and the user's voice. The main workspace provides a text assistant with prompt shortcuts, conversation history, notes, settings, themes, and assistant modes such as web search, research brief, and think-it-through. The content script injects a compact assistant drawer into normal HTTP and HTTPS pages, letting users summarize selected text, summarize a whole page, or ask a custom question about page content. The voice page offers a separate room with an animated sphere, live state labels, transcript display, start and freeze controls, speech recognition, spoken answers, and simple voice browser commands such as opening websites or searching the web. The overall project identity is "Lumina AI - Intelligent Workspace." The manifest describes the extension as "A new tab AI workspace for chat, page summaries, notes, reminders, app ideas, and browser actions." That description captures the central purpose well: Lumina is meant to be a workspace, not only an AI wrapper. It is designed to help a user move from messy input to concrete next action. A user might open a new tab and ask for an implementation plan, paste a stack trace and ask for debugging help, summarize a technical article, save a short note, generate app ideas, search the web, open a site, close duplicate tabs, set a timer, change the visual theme, or switch to voice mode. The assistant is most valuable when those actions happen in the same place where the user's browser context already exists. The file structure reflects this product shape. `manifest.json` defines the Chrome extension, permissions, host permissions, background service worker, content script, new tab override, action icon, and icon assets. `newtab.html`, `newtab.css`, and `newtab.js` implement the main workspace. `content.js` implements the in-page assistant injected into websites. `background.js` handles toolbar clicks, fallback script injection, background Groq requests for content scripts, alarm events, notifications, and timer state. `voice.html`, `voice.css`, and `voice.js` implement the dedicated voice mode. `README.md`, `SALES_PITCH.md`, and `deployment_guide.md` document the project, its positioning, installation, privacy model, deployment process, and Chrome Web Store considerations. `build-release.ps1` packages the extension for release, while `gen-icons.ps1` and the icon files support the visual identity. `local-secrets.js` is a local-only configuration file and should not be included in production packages. The manifest is concise and clearly declares the extension's major capabilities. It uses `manifest_version` 3, names the extension "Lumina AI - Intelligent Workspace," and sets the version to `1.0.1`. The permissions include `storage`, `tabs`, `alarms`, `notifications`, and `scripting`. These map directly to the product's features: storing keys and user data, creating and managing tabs, supporting timers and reminders, displaying notifications, and extracting page text when the user asks for page-aware assistance. Host permissions include Groq, ElevenLabs, and `<all_urls>`. The Groq host permission supports AI requests. The ElevenLabs host permission supports the optional text-to-speech path. The broad `<all_urls>` permission supports page summarization and the in-page assistant across normal websites, but it is also the permission that requires the clearest privacy explanation when publishing to the Chrome Web Store. The main new tab page is the heart of the project. Its HTML defines a desktop-first workspace with a top bar, brand area, navigation pills, a collapsible prompt sidebar, a conversation column, assistant mode buttons, a text composer, history and scratchpad side panels, a settings panel, and a suggestion modal. The first impression is a focused developer workspace rather than a marketing landing page. The empty state invites the user to "Start from an idea, a tab, or a messy stack trace," which is a good summary of the intended use cases. The user can begin from direct chat input, from a prompt menu, from assistant modes, from saved notes, or from current browser context. The prompt sidebar is one of the main usability features. It is closed by default and opens through the burger button in the top bar. Inside it, prompts are grouped into practical categories: Explore, Build, and Use current tab. Explore includes app ideas and searching for developer context. Build includes coding prompts, implementation plans, and code explanations. Use current tab includes summarizing the active tab and writing help. The sidebar also includes an "Access voice mode" button that opens the dedicated voice page. This design prevents the main screen from being overwhelmed while still giving users fast entry points when they do not know exactly what to ask. The main workspace supports three assistant modes: web search, research brief, and think-it-through. These modes are exposed as chips above the composer. Web search helps steer the user's input toward search-oriented commands. Research brief mode treats the user's message as a topic and asks the model to return a concise basics-only explanation covering what the topic is, why it matters, core concepts, common use cases, and one practical next step. Think-it-through mode asks the model to return a practical reasoning scaffold with Goal, Assumptions, Options, Tradeoffs, Recommendation, and Next action. Importantly, the code explicitly instructs the model not to expose hidden chain-of-thought. Instead, it asks for a concise scaffold useful to developers and product builders. The main runtime in `newtab.js` is organized around several large objects and shared state variables. `AGENTS` currently defines the Lumina agent, including the system prompt that tells the assistant to be practical, specific, concise, and honest about browsing. `COMMAND_SUGGESTIONS` stores seed prompts for app ideas, coding prompts, and writing prompts. State variables store the active agent, chat history, API keys, local notes, assistant modes, and voice toggles. `CONTROL` manages abort controllers, pending timers, currently playing audio, and a freeze state. `UI` handles initialization, event listeners, rendering, settings, panels, themes, notes, history, suggestion modals, and message sending. `NEURAL_SYNC` sends chat requests to Groq. `SPEAKER` handles spoken replies. `VOICE` handles microphone-based input in the main page. `AGENTIC_ENGINE` intercepts natural language commands that can be executed locally by the extension without sending them to the model. This separation is useful even though the project uses plain JavaScript instead of modules or classes. The code still has conceptual modules: UI, AI sync, voice, speech output, control/freeze behavior, and command execution. Because the project has no bundler, all of that logic lives in one large script file, but the object-based structure gives the runtime a readable shape. A future refactor could split these objects into separate files, but the current approach fits the project's buildless philosophy. A developer can open the file, search for the object they need, and change behavior without learning a framework or build pipeline. The Groq integration is direct. In the main new tab page, `NEURAL_SYNC.complete`, `NEURAL_SYNC.chat`, and `NEURAL_SYNC.chatWithContext` send `fetch` requests to `https://api.groq.com/openai/v1/chat/completions`. They use the `llama-3.3-70b-versatile` model, include the saved Groq key as a bearer token, and pass system and user messages. Normal chat includes recent conversation history, while context-aware chat includes extracted page text. The mode settings affect maximum tokens and temperature, making research brief mode more compact and think-it-through mode more structured. Successful responses are saved into local chat history and rendered back into the chat area. The background service worker also includes a Groq completion bridge for content scripts. `content.js` cannot safely own all of the extension state by itself, so when the in-page assistant needs a completion, it sends a `luminaGroqComplete` message to `background.js`. The background script retrieves the Groq key from `chrome.storage.local`, sends the request to Groq, and returns either text or an error message. This keeps the in-page assistant relatively small and avoids duplicating the key lookup and network handling in every page context. The local storage model is central to the extension. Keys, history, notes, themes, voice settings, and reminder metadata are stored in `chrome.storage.local`. This means user data remains in the browser storage controlled by the user rather than being sent to a custom Lumina backend. The project does not include analytics, tracking pixels, ads, or a server owned by the extension. External transmission happens when the user invokes AI features, page summarization, search commands, Wikipedia lookups, or optional text-to-speech. In those cases, the relevant prompt, chat context, selected text, page text, search query, or spoken response request is sent to the third-party service needed for the feature. The privacy model is therefore straightforward but must be communicated clearly. Lumina stores sensitive configuration locally, including the Groq API key and optional ElevenLabs key. It also stores user-generated content such as chat history and scratchpad notes. It sends prompts and selected/page content to Groq only when the user asks the assistant to respond. It opens Google searches when the user asks to search. It queries Wikipedia APIs when the user invokes Wikipedia-specific flows. This is a good privacy posture for a lightweight extension, but the `<all_urls>` host permission means the Chrome Web Store listing should explain that broad access is used for user-triggered page summarization and in-page assistant support rather than background tracking. The in-page assistant in `content.js` is a self-contained injected drawer. It only runs in the top frame and prevents duplicate injection by checking for an existing root element. It creates a fixed root element with a very high z-index, attaches a shadow DOM, and defines its own CSS variables and layout. Using shadow DOM helps isolate the assistant's styles from the website's styles and reduces the chance that a page will accidentally break the assistant or that the assistant will disturb the page. The assistant starts as a small launcher button with an "L" label and expands into a right-side panel when opened. Inside the page assistant panel, the user sees the Lumina brand, a "Page assistant" label, close control, two action buttons, an output area, a textarea, an ask button, and a status label. The two main actions are "Summarize selection" and "Summarize page." If the user has selected text, the assistant can summarize that selection in concise technical bullets. If the user asks to summarize the page, the script gathers readable text from elements such as `main`, `article`, headings, paragraphs, list items, `pre`, and `code`, falling back to `document.body.innerText` if needed. It trims excessive line breaks and caps page context before sending it to the background Groq bridge. The custom question flow is similar. The user types a question, and the assistant answers using selected text if available, otherwise page text. The system prompt tells Lumina to answer from the supplied context and to say what is missing if the context is insufficient. This is important because the extension should not imply that it understands a page beyond the text it extracted. The content script uses concise loading and error messages such as "Thinking...", "Working on it...", "Reading the page context...", and clear fallback notices when no readable text is found. The extension toolbar button is handled by `background.js`. When the user clicks the toolbar action on a supported HTTP or HTTPS page, the background script first attempts to send a toggle message to `content.js`. If the content script is not present, it injects `content.js` using the `scripting` API and then sends the toggle message again. If the current tab is restricted, missing, or not a normal web page, the background script opens the extension's `newtab.html` instead. This behavior makes the toolbar action useful in both page-aware and restricted contexts. It also gives users a predictable fallback instead of silently failing. The dedicated voice mode is intentionally separate from the main workspace. `voice.html` defines a minimal page with a top bar, back link, live state, animated orb area, caption, transcript, and two controls: "Start voice mode" and "Freeze." `voice.css` supplies the visual experience, including the sphere and its state-dependent animation. `voice.js` implements the runtime as a `VoiceRoom` object. It initializes speech recognition if the browser supports `SpeechRecognition` or `webkitSpeechRecognition`, retrieves the Groq key from local storage, listens for speech, sends final utterances to Groq, speaks replies through `speechSynthesis`, and supports freezing or stopping the session. The voice room is described as voice-only because there is no chat composer in that page. This matters for user experience. Voice interaction can be messy if mixed directly into a text workspace, especially when microphones, spoken replies, browser commands, and ongoing transcripts are involved. By moving voice into its own page, the project keeps the main new tab workspace calm and predictable while giving voice a more immersive interface. The animated sphere creates a clear center of attention, and the state label helps the user understand whether Lumina is idle, listening, thinking, speaking, or unavailable. Voice mode includes browser-command handling before falling back to AI chat. It can detect commands such as opening a website, going to a domain, launching a site, or searching for a query. When it recognizes an open command, it normalizes phrases such as "dot com," append