desktop/is the main Electron + React + TypeScript app. UI lives indesktop/src/, while Electron main-process and core services live indesktop/electron/.desktop/dist-electron/contains generated build outputs; do not edit by hand.Plugin/holds the Chrome extension (manifest v3) for Xiaohongshu content capture and AI rewrite features.Docs/contains product notes, workflows, and design references.
npm install(run insidedesktop/) installs the desktop app dependencies.npm run dev(indesktop/) starts the Vite dev server for the renderer.npm run build(indesktop/) runstsc, builds the renderer, and packages withelectron-builder.npm run preview(indesktop/) serves a built renderer for smoke checks.
- TypeScript/TSX uses 4-space indentation, semicolons, and single quotes; follow the surrounding file’s formatting.
- React components live in
desktop/src/pages/and arePascalCase(e.g.,CreativeChat.tsx). - IPC channels are string names (e.g.,
chatrooms:send) defined/used indesktop/electron/anddesktop/src/. - TailwindCSS is used for styling; prefer existing utility patterns over custom CSS.
- There is no standard test runner configured at the root or in
desktop/yet. - If you add tests, document the command and keep test file names explicit (for example,
*.test.ts) near the code they cover.
- Commit messages are short and pragmatic, often in Chinese, with occasional
feat:prefixes. Match this tone. - PRs should include a clear description, the affected areas (e.g.,
desktop/electron/), and any UI screenshots for renderer changes.
- API keys and model settings are user-configured in the app settings; do not hardcode secrets.
- For new IPC or file system features, validate inputs and keep main-process changes in
desktop/electron/.
- This is an AI system. During AI interaction and orchestration flows, avoid hardcoded text/keyword heuristics for user-intent judgment whenever possible.
- Prefer this order of responsibility:
- skills and system prompts define capability boundaries and decision principles
- structured metadata / explicit mode flags carry routing intent
- tool/runtime layers only enforce input validation and safety constraints
- If a behavior must be constrained, prefer structured rules, typed state, and tool contracts over brittle string matching against user messages.
- Hardcoded message-text checks are a last resort only, and any exception should be narrow, explicit, and easy to remove later.