Some checks failed
CI — Test & Build / Test & Build (push) Failing after 39s
- Added a new "Prompt Builder" tab in the Popup for generating AI prompts with customizable parameters. - Introduced new state variables for managing prompt styles, personas, formats, and models. - Enhanced the Options page to fetch and display models based on the provided API key. - Updated the actions and types to include the new 'prompt' action and its associated parameters. - Implemented migration logic for legacy plaintext API keys to encrypted storage. - Updated the getSystemPrompt function to incorporate prompt parameters for better instruction generation. - Added tests for the new functionality, including context menu entries and prompt generation logic.
3.3 KiB
3.3 KiB
Project brief — LexAI
Source of truth for what LexAI is and why. Keep it under two screens; link out for detail.
Outcome
- One-line product: A Grammarly-like Chrome extension (Manifest V3) that gives AI writing help — grammar fix, rephrase, shorten, expand, explain — on any webpage, using the user's own LLM API key.
- Measurable outcome: A user can select text on any page, pick an action from the floating toolbar (or right-click menu / popup), and replace or copy an AI-improved version — with no LexAI backend and no subscription.
- Primary user: Individuals who already hold an LLM API key (OpenAI / Anthropic / Groq / OpenRouter) and want inline writing assistance without paying a SaaS subscription or sending text through a third-party server.
- Why now: BYO-key removes the cost and privacy objections to hosted writing assistants; MV3 + WXT makes a lightweight, serverless extension practical.
Non-goals
- No LexAI backend, account system, or subscription. The extension talks directly to the user's chosen provider.
- Not a full document editor; it augments existing page inputs (textarea/input/contenteditable).
- No telemetry or transmission of user text anywhere except the user-selected provider endpoint.
- Not (yet) streaming, autocomplete, tone profiles, or custom style profiles — those are roadmap.
Acceptance tests
npm run typecheckandnpm test -- --runpass.npm run buildproduces a loadable.output/chrome-mv3/bundle (~166 KB baseline).- Loaded unpacked, selecting text on a page shows the toolbar; an action returns a result modal; Replace edits both textarea/input and contenteditable targets.
- API key is stored via the encrypted path (
apiKeyEnc+encKey) and never logged or sent anywhere but the provider endpoint.
Constraints
- Stack: WXT
^0.20(Vite), React 18 + TypeScript (Options/Popup only), tweetnacl for key encryption. Tailwind is installed but inactive — all UI is inline styles. - Runtime: Node 22 (CI pins
node:22-bookworm).npm installrequired before anynpm run *. - Security/compliance: Handles a user secret (LLM API key) and reads page-selected text. Manifest currently requests
<all_urls>— a Chrome Web Store review risk (seeattacksurface.md). - Release: CI is Gitea (
.gitea/workflows/), not GitHub Actions. Version must match inpackage.jsonandwxt.config.ts; av*.*.*tag deploys to the Chrome Web Store.
Stakeholders
| Role | Who | Decision authority |
|---|---|---|
| Owner / maintainer | John Kevin Asprec | scope, priorities, release |
| Project tracking | Plane (LEXAI project) | https://plane-pro.juankibin.space |
Unknowns
- Whether to narrow host permissions to
activeTab/allowlist before a serious Web Store push (see Decisions + attack surface). - Whether the current tweetnacl approach should be replaced given
encKeyis co-located with the ciphertext (it is obfuscation, not protection).
Source of truth
- Issue tracker: Plane — LEXAI project (link above).
- This repo: entrypoints in
entrypoints/, shared code insrc/, tests intests/.CLAUDE.mdis the working guide for architecture and conventions.
Related: ARCHITECTURE.md, DECISIONS.md, TASKS.md (from RECOMMENDATIONS), attacksurface.md, SELF_MODEL.md.