{"owner":"caorushizi","repo":"mediago","hasSkills":true,"hasMcp":false,"mcpConfig":null,"found":["CLAUDE.md","AGENTS.md",".github/copilot-instructions.md"],"skills":{"CLAUDE.md":"# CLAUDE.md\n\nThis file provides guidance to Claude Code (claude.ai/code) when working with code in this repository.\n\n## Project Overview\n\nMediaGo is a cross-platform video downloader supporting m3u8/HLS streams. The codebase is a pnpm monorepo with three products:\n\n1. **Desktop app** (`apps/electron` + `apps/ui`) — Electron wrapper that launches Go Core as a subprocess\n2. **Web server** (`apps/server` + `apps/ui`) — Node.js launcher that spawns Go Core as a subprocess\n3. **Video player** (`apps/core` + `apps/player-ui`) — Player UI embedded in Go Core for video playback\n\nAll three products share the Go Core backend (`apps/core`) for download orchestration.\n\n## Common Commands\n\n```bash\npnpm install                # Install all dependencies (run once per clone)\npnpm dev:electron           # Start Electron desktop dev environment (HMR)\npnpm dev:server             # Start server dev environment (HMR)\npnpm build:electron         # Production build for Electron\npnpm build:web              # Build UI only (server mode)\npnpm core:dev               # Start Go Core dev server (port 9900)\npnpm core:build             # Compile Go Core binary\npnpm player:dev             # Start Player dev (alias for core:dev)\npnpm player:build           # Build Player (alias for core:build)\npnpm deps:download          # Download third-party tools (ffmpeg, BBDown, etc.)\npnpm deps:download:all      # Download tools for all platforms\npnpm lint                   # Lint with oxlint\npnpm lint:fix               # Auto-fix lint issues\npnpm format                 # Format with oxfmt\npnpm format:check           # Check formatting without modifying\npnpm check                  # Full check: lint + format + type check\npnpm type:check             # TypeScript type checking via Turborepo\npnpm pack:electron          # Build + package Electron distributable\n```\n\nCommits use Conventional Commits format (e.g. `feat(electron): add queue UI`).\n\n## Architecture\n\n### Monorepo Layout\n\n**Apps:**\n\n- **`apps/core/`** — Go (Gin) REST API backend for download orchestration. Runs on port 9900. Uses SQLite (GORM), SSE for real-time events, PTY for capturing download tool output. Built with Gulp + Go cross-compilation.\n- **`apps/electron/`** — Electron main process (tsdown build, inversify DI). Launches Go Core via `@mediago/service-runner`.\n- **`apps/server/`** — Node.js launcher (tsdown build). Spawns Go Core via `@mediago/service-runner`.\n- **`apps/ui/`** — Shared React 19 frontend (Vite 8, Ant Design 6, Zustand, TailwindCSS 4, i18next). Used by both Electron and server targets.\n- **`apps/player-ui/`** — React 19 frontend for player (Vite 8, shadcn/ui, video.js, TailwindCSS 4). Built assets are embedded into Go Core via `//go:embed`.\n\n**Packages:**\n\n- **`packages/shared/common/`** — Platform-agnostic shared types, constants, and utilities\n- **`packages/core-sdk/`** — TypeScript SDK for Go Core REST API (Axios, SSE via eventsource)\n- **`packages/electron-preload/`** — Electron preload scripts for IPC bridge\n- **`packages/browser-extension/`** — Browser extension (Lit web components)\n- **`docs/`** — VitePress documentation (Chinese, English, Japanese)\n\n### Multi-Target Build\n\nThe `APP_TARGET` env var (`electron` | `server`) controls which backend the UI builds against. Both targets share the same React UI but connect via different transports:\n\n- **Electron**: IPC bridge (preload) + Go Core direct (via `@mediago/core-sdk`)\n- **Server/Web**: HTTP/WebSocket + Go Core direct (via `@mediago/core-sdk`)\n\nThe UI adapter layer (`apps/ui/src/hooks/adapters/`) abstracts this: `electron.ts` provides IPC bridge in desktop mode, `platform-stubs.ts` provides no-op stubs in web mode, and `index.ts` exports `platformApi` which selects the appropriate adapter.\n\n### Key Patterns\n\n- **Go Core as subprocess**: Both Electron and server apps launch Go Core via `@mediago/service-runner`, which manages the process lifecycle and port allocation\n- **Dependency Injection**: inversify with `@inversifyjs/binding-decorators` in Electron backend\n- **State Management**: Zustand in the UI\n- **Real-time events**: Go Core emits SSE events (`/api/events`); the UI's `api/events.ts` subscribes and dispatches to React via a listener pattern\n- **TypeScript**: Strict mode with experimental decorators and decorator metadata enabled\n- **Module format**: ES Modules everywhere\n\n## Tooling\n\n- **Package manager**: pnpm 10.15.0 (enforced via `packageManager` field)\n- **Build orchestration**: Turborepo\n- **App bundling**: tsdown for Node/Electron, Vite 8 for UI apps\n- **Go builds**: Gulp orchestrating `go build` / `go run` in `apps/core`\n- **Linter**: oxlint (config in `.oxlintrc.json`)\n- **Formatter**: oxfmt (config in `.oxfmtrc.json`)\n- **Pre-commit**: husky + lint-staged (runs oxlint --fix + oxfmt --write on staged files)\n- **Electron packaging**: electron-builder\n\n## Style Conventions\n\n- TypeScript, ES modules, 2-space indentation, UTF-8, LF endings\n- Components: PascalCase. Utilities: camelCase. Constants: SCREAMING_SNAKE_CASE\n- UI port: 8555 (strict). Go Core port: 9900. Player UI port: 8556\n","AGENTS.md":"# Repository Guidelines\n\n## Project Structure & Module Organization\n\nMediaGo is a pnpm/turborepo monorepo. Feature apps live in `apps/` (`frontend-main`, `frontend-mobile`, `backend-web`, `backend-electron`) for the user surfaces and API. Reusable logic stays in `packages/` (`shared` for cross-runtime helpers, `backend` for orchestration, `main` for Electron packaging). Long-form docs and assets sit in `docs/`, `images/`, and `docker/`. End-to-end checks live in `tests/`.\n\n## Build, Test, and Development Commands\n\nRun `pnpm install` once per clone. Use `pnpm dev` for the unified desktop + web experience, or scope to `pnpm dev:web` / `pnpm dev:electron`. `pnpm build` triggers the production Turborepo pipeline; `pnpm build:web-release` plus `pnpm build:docker` produce the deployable web bundle. Keep the codebase healthy with `pnpm lint`, `pnpm lint:fix`, `pnpm format`, and verify types through `pnpm types`.\n\n## Coding Style & Naming Conventions\n\nTarget modern TypeScript with ES modules, two-space indentation, UTF-8, and LF endings per `.editorconfig`. Components, hooks, and services adopt PascalCase (e.g. `UserPreferencesPanel.tsx`). Utilities and helpers stay camelCase, and constants use SCREAMING_SNAKE_CASE. Always run `pnpm format` before committing; reserve comments for clarifying complex logic.\n\n## UI Interaction and Cursor Semantics\n\nMouse cursors must communicate what an element will do. Define cursor behavior in shared UI primitives whenever possible so every consumer inherits it.\n\n| Interaction                                                                      | Cursor                                    |\n| -------------------------------------------------------------------------------- | ----------------------------------------- |\n| Enabled buttons, links, menu items, select options, toggles, and clickable cards | pointer                                   |\n| Disabled or unavailable controls                                                 | not-allowed                               |\n| Editable text                                                                    | text                                      |\n| Draggable content                                                                | grab, changing to grabbing while dragging |\n| Horizontal or vertical resize handles                                            | col-resize or row-resize                  |\n| Work continuing in the background                                                | progress                                  |\n| Blocking work where the UI cannot accept input                                   | wait                                      |\n| Non-interactive content                                                          | default                                   |\n\nDo not use cursor-default on an enabled interactive element. Avoid pointer-events: none on disabled controls when it prevents the not-allowed cursor from being shown; use native disabled, aria-disabled, or the component library's disabled state to block the action. Cursor styling does not replace semantic HTML, keyboard interaction, focus states, or accessible names.\n\n## Testing Guidelines\n\nIntegration suites live under `tests/*.test.ts` and execute via `pnpm test` using the Node `tsx` runner. Name files descriptively like `download.queue.integration.test.ts`. Mock external services, prefer shared fixtures in `tests/fixtures/`, and cover happy path, recovery, and edge behaviors when touching runtime code.\n\n## Commit & Pull Request Guidelines\n\nFollow Conventional Commits (e.g. `feat(frontend-main): add download queue UI`) and use `pnpm commit` (Commitizen) to stay compliant. Pull requests should summarize the change, link issues with `Closes #123`, note local test runs (`pnpm test`), and attach screenshots or recordings for UI updates. Call out new environment variables, migrations, or follow-up tasks so reviewers can reproduce the setup quickly.\n",".github/copilot-instructions.md":"# GitHub Copilot Instruction: Code Review and Optimization\n\n## Role and Objective\n\nYou are a **top-tier software architect and performance optimization expert**.  \nYour goal is to help me — a senior TypeScript full-stack engineer — elevate the quality of my code to a new level.  \nWhen reviewing my code, **do not explain basic concepts**. I need **precise, deep, and forward-thinking insights**.\n\nYour core mission is **optimization**, including but not limited to:\n\n- **Performance improvement**: Identify and optimize performance bottlenecks, reduce unnecessary computation and resource consumption.\n- **Code refactoring**: Suggest more elegant and efficient implementations to improve code structure.\n- **Design patterns**: Identify opportunities to apply or refine design patterns to enhance scalability and maintainability.\n- **Best practices**: Ensure the code adheres to the latest best practices for the TypeScript ecosystem (Node.js, React, API layers, build pipelines).\n- **Potential risks**: Anticipate and highlight deep issues such as concurrency problems, security vulnerabilities, or resource leaks.\n\n---\n\n## Review Perspective and Principles\n\n1. **High-Standard Review**  \n   Review the code as if it were going to **production for millions of users** and needs to be **maintained long-term**.\n\n2. **Deep Analysis, Not Surface Advice**  \n   Don’t focus on trivial issues like typos or syntax sugar.  \n   Instead, explain **why** a refactor or change matters — e.g.:\n\n   > “Switching from a synchronous file read to `fs.promises` can free the event loop, improving throughput under load.”\n\n3. **Performance First**\n   - Evaluate time and space complexity; suggest algorithmic or structural improvements.\n   - Examine I/O, database queries, and network calls for efficiency — recommend batching, caching, or async processing.\n   - Recommend appropriate data structures or API strategies for scalability (e.g., pagination, streaming responses).\n\n4. **Architecture and Design**\n   - Follow **SOLID** principles. Explicitly identify violations and propose refactoring approaches.\n   - Encourage **composition over inheritance** and **dependency injection**.\n   - Suggest modularization and clear separation between layers (e.g., API, service, repository, UI).\n\n5. **Code Style and Standards**\n   - Code must be clear, consistent, and self-explanatory.\n   - Follow the project’s existing conventions unless the change brings substantial clarity or performance gain.\n   - For complex logic, suggest adding comments explaining the **rationale (“why”)**, not just the **action (“what”)**.\n\n---\n\n## Specific Instructions\n\n- **When reviewing code, include the optimized code snippet directly**, with short comments highlighting key changes and their reasoning.\n- **If you find potential bugs or unhandled edge cases**, explicitly point them out and provide a fix suggestion.\n- **Avoid subjective stylistic comments** unless they impact clarity, performance, or maintainability.\n- **When I ask “Can this code be optimized?”**, provide a holistic evaluation covering performance, readability, scalability, and maintainability.\n\n---\n\nAt the end of every response, please add:\n\n> “AI-generated suggestions may contain errors; use your own judgment when applying them.”\n"},"files":{"CLAUDE.md":"# CLAUDE.md\n\nThis file provides guidance to Claude Code (claude.ai/code) when working with code in this repository.\n\n## Project Overview\n\nMediaGo is a cross-platform video downloader supporting m3u8/HLS streams. The codebase is a pnpm monorepo with three products:\n\n1. **Desktop app** (`apps/electron` + `apps/ui`) — Electron wrapper that launches Go Core as a subprocess\n2. **Web server** (`apps/server` + `apps/ui`) — Node.js launcher that spawns Go Core as a subprocess\n3. **Video player** (`apps/core` + `apps/player-ui`) — Player UI embedded in Go Core for video playback\n\nAll three products share the Go Core backend (`apps/core`) for download orchestration.\n\n## Common Commands\n\n```bash\npnpm install                # Install all dependencies (run once per clone)\npnpm dev:electron           # Start Electron desktop dev environment (HMR)\npnpm dev:server             # Start server dev environment (HMR)\npnpm build:electron         # Production build for Electron\npnpm build:web              # Build UI only (server mode)\npnpm core:dev               # Start Go Core dev server (port 9900)\npnpm core:build             # Compile Go Core binary\npnpm player:dev             # Start Player dev (alias for core:dev)\npnpm player:build           # Build Player (alias for core:build)\npnpm deps:download          # Download third-party tools (ffmpeg, BBDown, etc.)\npnpm deps:download:all      # Download tools for all platforms\npnpm lint                   # Lint with oxlint\npnpm lint:fix               # Auto-fix lint issues\npnpm format                 # Format with oxfmt\npnpm format:check           # Check formatting without modifying\npnpm check                  # Full check: lint + format + type check\npnpm type:check             # TypeScript type checking via Turborepo\npnpm pack:electron          # Build + package Electron distributable\n```\n\nCommits use Conventional Commits format (e.g. `feat(electron): add queue UI`).\n\n## Architecture\n\n### Monorepo Layout\n\n**Apps:**\n\n- **`apps/core/`** — Go (Gin) REST API backend for download orchestration. Runs on port 9900. Uses SQLite (GORM), SSE for real-time events, PTY for capturing download tool output. Built with Gulp + Go cross-compilation.\n- **`apps/electron/`** — Electron main process (tsdown build, inversify DI). Launches Go Core via `@mediago/service-runner`.\n- **`apps/server/`** — Node.js launcher (tsdown build). Spawns Go Core via `@mediago/service-runner`.\n- **`apps/ui/`** — Shared React 19 frontend (Vite 8, Ant Design 6, Zustand, TailwindCSS 4, i18next). Used by both Electron and server targets.\n- **`apps/player-ui/`** — React 19 frontend for player (Vite 8, shadcn/ui, video.js, TailwindCSS 4). Built assets are embedded into Go Core via `//go:embed`.\n\n**Packages:**\n\n- **`packages/shared/common/`** — Platform-agnostic shared types, constants, and utilities\n- **`packages/core-sdk/`** — TypeScript SDK for Go Core REST API (Axios, SSE via eventsource)\n- **`packages/electron-preload/`** — Electron preload scripts for IPC bridge\n- **`packages/browser-extension/`** — Browser extension (Lit web components)\n- **`docs/`** — VitePress documentation (Chinese, English, Japanese)\n\n### Multi-Target Build\n\nThe `APP_TARGET` env var (`electron` | `server`) controls which backend the UI builds against. Both targets share the same React UI but connect via different transports:\n\n- **Electron**: IPC bridge (preload) + Go Core direct (via `@mediago/core-sdk`)\n- **Server/Web**: HTTP/WebSocket + Go Core direct (via `@mediago/core-sdk`)\n\nThe UI adapter layer (`apps/ui/src/hooks/adapters/`) abstracts this: `electron.ts` provides IPC bridge in desktop mode, `platform-stubs.ts` provides no-op stubs in web mode, and `index.ts` exports `platformApi` which selects the appropriate adapter.\n\n### Key Patterns\n\n- **Go Core as subprocess**: Both Electron and server apps launch Go Core via `@mediago/service-runner`, which manages the process lifecycle and port allocation\n- **Dependency Injection**: inversify with `@inversifyjs/binding-decorators` in Electron backend\n- **State Management**: Zustand in the UI\n- **Real-time events**: Go Core emits SSE events (`/api/events`); the UI's `api/events.ts` subscribes and dispatches to React via a listener pattern\n- **TypeScript**: Strict mode with experimental decorators and decorator metadata enabled\n- **Module format**: ES Modules everywhere\n\n## Tooling\n\n- **Package manager**: pnpm 10.15.0 (enforced via `packageManager` field)\n- **Build orchestration**: Turborepo\n- **App bundling**: tsdown for Node/Electron, Vite 8 for UI apps\n- **Go builds**: Gulp orchestrating `go build` / `go run` in `apps/core`\n- **Linter**: oxlint (config in `.oxlintrc.json`)\n- **Formatter**: oxfmt (config in `.oxfmtrc.json`)\n- **Pre-commit**: husky + lint-staged (runs oxlint --fix + oxfmt --write on staged files)\n- **Electron packaging**: electron-builder\n\n## Style Conventions\n\n- TypeScript, ES modules, 2-space indentation, UTF-8, LF endings\n- Components: PascalCase. Utilities: camelCase. Constants: SCREAMING_SNAKE_CASE\n- UI port: 8555 (strict). Go Core port: 9900. Player UI port: 8556\n","AGENTS.md":"# Repository Guidelines\n\n## Project Structure & Module Organization\n\nMediaGo is a pnpm/turborepo monorepo. Feature apps live in `apps/` (`frontend-main`, `frontend-mobile`, `backend-web`, `backend-electron`) for the user surfaces and API. Reusable logic stays in `packages/` (`shared` for cross-runtime helpers, `backend` for orchestration, `main` for Electron packaging). Long-form docs and assets sit in `docs/`, `images/`, and `docker/`. End-to-end checks live in `tests/`.\n\n## Build, Test, and Development Commands\n\nRun `pnpm install` once per clone. Use `pnpm dev` for the unified desktop + web experience, or scope to `pnpm dev:web` / `pnpm dev:electron`. `pnpm build` triggers the production Turborepo pipeline; `pnpm build:web-release` plus `pnpm build:docker` produce the deployable web bundle. Keep the codebase healthy with `pnpm lint`, `pnpm lint:fix`, `pnpm format`, and verify types through `pnpm types`.\n\n## Coding Style & Naming Conventions\n\nTarget modern TypeScript with ES modules, two-space indentation, UTF-8, and LF endings per `.editorconfig`. Components, hooks, and services adopt PascalCase (e.g. `UserPreferencesPanel.tsx`). Utilities and helpers stay camelCase, and constants use SCREAMING_SNAKE_CASE. Always run `pnpm format` before committing; reserve comments for clarifying complex logic.\n\n## UI Interaction and Cursor Semantics\n\nMouse cursors must communicate what an element will do. Define cursor behavior in shared UI primitives whenever possible so every consumer inherits it.\n\n| Interaction                                                                      | Cursor                                    |\n| -------------------------------------------------------------------------------- | ----------------------------------------- |\n| Enabled buttons, links, menu items, select options, toggles, and clickable cards | pointer                                   |\n| Disabled or unavailable controls                                                 | not-allowed                               |\n| Editable text                                                                    | text                                      |\n| Draggable content                                                                | grab, changing to grabbing while dragging |\n| Horizontal or vertical resize handles                                            | col-resize or row-resize                  |\n| Work continuing in the background                                                | progress                                  |\n| Blocking work where the UI cannot accept input                                   | wait                                      |\n| Non-interactive content                                                          | default                                   |\n\nDo not use cursor-default on an enabled interactive element. Avoid pointer-events: none on disabled controls when it prevents the not-allowed cursor from being shown; use native disabled, aria-disabled, or the component library's disabled state to block the action. Cursor styling does not replace semantic HTML, keyboard interaction, focus states, or accessible names.\n\n## Testing Guidelines\n\nIntegration suites live under `tests/*.test.ts` and execute via `pnpm test` using the Node `tsx` runner. Name files descriptively like `download.queue.integration.test.ts`. Mock external services, prefer shared fixtures in `tests/fixtures/`, and cover happy path, recovery, and edge behaviors when touching runtime code.\n\n## Commit & Pull Request Guidelines\n\nFollow Conventional Commits (e.g. `feat(frontend-main): add download queue UI`) and use `pnpm commit` (Commitizen) to stay compliant. Pull requests should summarize the change, link issues with `Closes #123`, note local test runs (`pnpm test`), and attach screenshots or recordings for UI updates. Call out new environment variables, migrations, or follow-up tasks so reviewers can reproduce the setup quickly.\n",".github/copilot-instructions.md":"# GitHub Copilot Instruction: Code Review and Optimization\n\n## Role and Objective\n\nYou are a **top-tier software architect and performance optimization expert**.  \nYour goal is to help me — a senior TypeScript full-stack engineer — elevate the quality of my code to a new level.  \nWhen reviewing my code, **do not explain basic concepts**. I need **precise, deep, and forward-thinking insights**.\n\nYour core mission is **optimization**, including but not limited to:\n\n- **Performance improvement**: Identify and optimize performance bottlenecks, reduce unnecessary computation and resource consumption.\n- **Code refactoring**: Suggest more elegant and efficient implementations to improve code structure.\n- **Design patterns**: Identify opportunities to apply or refine design patterns to enhance scalability and maintainability.\n- **Best practices**: Ensure the code adheres to the latest best practices for the TypeScript ecosystem (Node.js, React, API layers, build pipelines).\n- **Potential risks**: Anticipate and highlight deep issues such as concurrency problems, security vulnerabilities, or resource leaks.\n\n---\n\n## Review Perspective and Principles\n\n1. **High-Standard Review**  \n   Review the code as if it were going to **production for millions of users** and needs to be **maintained long-term**.\n\n2. **Deep Analysis, Not Surface Advice**  \n   Don’t focus on trivial issues like typos or syntax sugar.  \n   Instead, explain **why** a refactor or change matters — e.g.:\n\n   > “Switching from a synchronous file read to `fs.promises` can free the event loop, improving throughput under load.”\n\n3. **Performance First**\n   - Evaluate time and space complexity; suggest algorithmic or structural improvements.\n   - Examine I/O, database queries, and network calls for efficiency — recommend batching, caching, or async processing.\n   - Recommend appropriate data structures or API strategies for scalability (e.g., pagination, streaming responses).\n\n4. **Architecture and Design**\n   - Follow **SOLID** principles. Explicitly identify violations and propose refactoring approaches.\n   - Encourage **composition over inheritance** and **dependency injection**.\n   - Suggest modularization and clear separation between layers (e.g., API, service, repository, UI).\n\n5. **Code Style and Standards**\n   - Code must be clear, consistent, and self-explanatory.\n   - Follow the project’s existing conventions unless the change brings substantial clarity or performance gain.\n   - For complex logic, suggest adding comments explaining the **rationale (“why”)**, not just the **action (“what”)**.\n\n---\n\n## Specific Instructions\n\n- **When reviewing code, include the optimized code snippet directly**, with short comments highlighting key changes and their reasoning.\n- **If you find potential bugs or unhandled edge cases**, explicitly point them out and provide a fix suggestion.\n- **Avoid subjective stylistic comments** unless they impact clarity, performance, or maintainability.\n- **When I ask “Can this code be optimized?”**, provide a holistic evaluation covering performance, readability, scalability, and maintainability.\n\n---\n\nAt the end of every response, please add:\n\n> “AI-generated suggestions may contain errors; use your own judgment when applying them.”\n"},"items":[{"name":"CLAUDE.md","path":"CLAUDE.md","title":"CLAUDE.md","content":"# CLAUDE.md\n\nThis file provides guidance to Claude Code (claude.ai/code) when working with code in this repository.\n\n## Project Overview\n\nMediaGo is a cross-platform video downloader supporting m3u8/HLS streams. The codebase is a pnpm monorepo with three products:\n\n1. **Desktop app** (`apps/electron` + `apps/ui`) — Electron wrapper that launches Go Core as a subprocess\n2. **Web server** (`apps/server` + `apps/ui`) — Node.js launcher that spawns Go Core as a subprocess\n3. **Video player** (`apps/core` + `apps/player-ui`) — Player UI embedded in Go Core for video playback\n\nAll three products share the Go Core backend (`apps/core`) for download orchestration.\n\n## Common Commands\n\n```bash\npnpm install                # Install all dependencies (run once per clone)\npnpm dev:electron           # Start Electron desktop dev environment (HMR)\npnpm dev:server             # Start server dev environment (HMR)\npnpm build:electron         # Production build for Electron\npnpm build:web              # Build UI only (server mode)\npnpm core:dev               # Start Go Core dev server (port 9900)\npnpm core:build             # Compile Go Core binary\npnpm player:dev             # Start Player dev (alias for core:dev)\npnpm player:build           # Build Player (alias for core:build)\npnpm deps:download          # Download third-party tools (ffmpeg, BBDown, etc.)\npnpm deps:download:all      # Download tools for all platforms\npnpm lint                   # Lint with oxlint\npnpm lint:fix               # Auto-fix lint issues\npnpm format                 # Format with oxfmt\npnpm format:check           # Check formatting without modifying\npnpm check                  # Full check: lint + format + type check\npnpm type:check             # TypeScript type checking via Turborepo\npnpm pack:electron          # Build + package Electron distributable\n```\n\nCommits use Conventional Commits format (e.g. `feat(electron): add queue UI`).\n\n## Architecture\n\n### Monorepo Layout\n\n**Apps:**\n\n- **`apps/core/`** — Go (Gin) REST API backend for download orchestration. Runs on port 9900. Uses SQLite (GORM), SSE for real-time events, PTY for capturing download tool output. Built with Gulp + Go cross-compilation.\n- **`apps/electron/`** — Electron main process (tsdown build, inversify DI). Launches Go Core via `@mediago/service-runner`.\n- **`apps/server/`** — Node.js launcher (tsdown build). Spawns Go Core via `@mediago/service-runner`.\n- **`apps/ui/`** — Shared React 19 frontend (Vite 8, Ant Design 6, Zustand, TailwindCSS 4, i18next). Used by both Electron and server targets.\n- **`apps/player-ui/`** — React 19 frontend for player (Vite 8, shadcn/ui, video.js, TailwindCSS 4). Built assets are embedded into Go Core via `//go:embed`.\n\n**Packages:**\n\n- **`packages/shared/common/`** — Platform-agnostic shared types, constants, and utilities\n- **`packages/core-sdk/`** — TypeScript SDK for Go Core REST API (Axios, SSE via eventsource)\n- **`packages/electron-preload/`** — Electron preload scripts for IPC bridge\n- **`packages/browser-extension/`** — Browser extension (Lit web components)\n- **`docs/`** — VitePress documentation (Chinese, English, Japanese)\n\n### Multi-Target Build\n\nThe `APP_TARGET` env var (`electron` | `server`) controls which backend the UI builds against. Both targets share the same React UI but connect via different transports:\n\n- **Electron**: IPC bridge (preload) + Go Core direct (via `@mediago/core-sdk`)\n- **Server/Web**: HTTP/WebSocket + Go Core direct (via `@mediago/core-sdk`)\n\nThe UI adapter layer (`apps/ui/src/hooks/adapters/`) abstracts this: `electron.ts` provides IPC bridge in desktop mode, `platform-stubs.ts` provides no-op stubs in web mode, and `index.ts` exports `platformApi` which selects the appropriate adapter.\n\n### Key Patterns\n\n- **Go Core as subprocess**: Both Electron and server apps launch Go Core via `@mediago/service-runner`, which manages the process lifecycle and port allocation\n- **Dependency Injection**: inversify with `@inversifyjs/binding-decorators` in Electron backend\n- **State Management**: Zustand in the UI\n- **Real-time events**: Go Core emits SSE events (`/api/events`); the UI's `api/events.ts` subscribes and dispatches to React via a listener pattern\n- **TypeScript**: Strict mode with experimental decorators and decorator metadata enabled\n- **Module format**: ES Modules everywhere\n\n## Tooling\n\n- **Package manager**: pnpm 10.15.0 (enforced via `packageManager` field)\n- **Build orchestration**: Turborepo\n- **App bundling**: tsdown for Node/Electron, Vite 8 for UI apps\n- **Go builds**: Gulp orchestrating `go build` / `go run` in `apps/core`\n- **Linter**: oxlint (config in `.oxlintrc.json`)\n- **Formatter**: oxfmt (config in `.oxfmtrc.json`)\n- **Pre-commit**: husky + lint-staged (runs oxlint --fix + oxfmt --write on staged files)\n- **Electron packaging**: electron-builder\n\n## Style Conventions\n\n- TypeScript, ES modules, 2-space indentation, UTF-8, LF endings\n- Components: PascalCase. Utilities: camelCase. Constants: SCREAMING_SNAKE_CASE\n- UI port: 8555 (strict). Go Core port: 9900. Player UI port: 8556\n","category":"root","tokens":1271},{"name":"AGENTS.md","path":"AGENTS.md","title":"AGENTS.md","content":"# Repository Guidelines\n\n## Project Structure & Module Organization\n\nMediaGo is a pnpm/turborepo monorepo. Feature apps live in `apps/` (`frontend-main`, `frontend-mobile`, `backend-web`, `backend-electron`) for the user surfaces and API. Reusable logic stays in `packages/` (`shared` for cross-runtime helpers, `backend` for orchestration, `main` for Electron packaging). Long-form docs and assets sit in `docs/`, `images/`, and `docker/`. End-to-end checks live in `tests/`.\n\n## Build, Test, and Development Commands\n\nRun `pnpm install` once per clone. Use `pnpm dev` for the unified desktop + web experience, or scope to `pnpm dev:web` / `pnpm dev:electron`. `pnpm build` triggers the production Turborepo pipeline; `pnpm build:web-release` plus `pnpm build:docker` produce the deployable web bundle. Keep the codebase healthy with `pnpm lint`, `pnpm lint:fix`, `pnpm format`, and verify types through `pnpm types`.\n\n## Coding Style & Naming Conventions\n\nTarget modern TypeScript with ES modules, two-space indentation, UTF-8, and LF endings per `.editorconfig`. Components, hooks, and services adopt PascalCase (e.g. `UserPreferencesPanel.tsx`). Utilities and helpers stay camelCase, and constants use SCREAMING_SNAKE_CASE. Always run `pnpm format` before committing; reserve comments for clarifying complex logic.\n\n## UI Interaction and Cursor Semantics\n\nMouse cursors must communicate what an element will do. Define cursor behavior in shared UI primitives whenever possible so every consumer inherits it.\n\n| Interaction                                                                      | Cursor                                    |\n| -------------------------------------------------------------------------------- | ----------------------------------------- |\n| Enabled buttons, links, menu items, select options, toggles, and clickable cards | pointer                                   |\n| Disabled or unavailable controls                                                 | not-allowed                               |\n| Editable text                                                                    | text                                      |\n| Draggable content                                                                | grab, changing to grabbing while dragging |\n| Horizontal or vertical resize handles                                            | col-resize or row-resize                  |\n| Work continuing in the background                                                | progress                                  |\n| Blocking work where the UI cannot accept input                                   | wait                                      |\n| Non-interactive content                                                          | default                                   |\n\nDo not use cursor-default on an enabled interactive element. Avoid pointer-events: none on disabled controls when it prevents the not-allowed cursor from being shown; use native disabled, aria-disabled, or the component library's disabled state to block the action. Cursor styling does not replace semantic HTML, keyboard interaction, focus states, or accessible names.\n\n## Testing Guidelines\n\nIntegration suites live under `tests/*.test.ts` and execute via `pnpm test` using the Node `tsx` runner. Name files descriptively like `download.queue.integration.test.ts`. Mock external services, prefer shared fixtures in `tests/fixtures/`, and cover happy path, recovery, and edge behaviors when touching runtime code.\n\n## Commit & Pull Request Guidelines\n\nFollow Conventional Commits (e.g. `feat(frontend-main): add download queue UI`) and use `pnpm commit` (Commitizen) to stay compliant. Pull requests should summarize the change, link issues with `Closes #123`, note local test runs (`pnpm test`), and attach screenshots or recordings for UI updates. Call out new environment variables, migrations, or follow-up tasks so reviewers can reproduce the setup quickly.\n","category":"root","tokens":992},{"name":"copilot-instructions.md","path":".github/copilot-instructions.md","title":"copilot-instructions.md","content":"# GitHub Copilot Instruction: Code Review and Optimization\n\n## Role and Objective\n\nYou are a **top-tier software architect and performance optimization expert**.  \nYour goal is to help me — a senior TypeScript full-stack engineer — elevate the quality of my code to a new level.  \nWhen reviewing my code, **do not explain basic concepts**. I need **precise, deep, and forward-thinking insights**.\n\nYour core mission is **optimization**, including but not limited to:\n\n- **Performance improvement**: Identify and optimize performance bottlenecks, reduce unnecessary computation and resource consumption.\n- **Code refactoring**: Suggest more elegant and efficient implementations to improve code structure.\n- **Design patterns**: Identify opportunities to apply or refine design patterns to enhance scalability and maintainability.\n- **Best practices**: Ensure the code adheres to the latest best practices for the TypeScript ecosystem (Node.js, React, API layers, build pipelines).\n- **Potential risks**: Anticipate and highlight deep issues such as concurrency problems, security vulnerabilities, or resource leaks.\n\n---\n\n## Review Perspective and Principles\n\n1. **High-Standard Review**  \n   Review the code as if it were going to **production for millions of users** and needs to be **maintained long-term**.\n\n2. **Deep Analysis, Not Surface Advice**  \n   Don’t focus on trivial issues like typos or syntax sugar.  \n   Instead, explain **why** a refactor or change matters — e.g.:\n\n   > “Switching from a synchronous file read to `fs.promises` can free the event loop, improving throughput under load.”\n\n3. **Performance First**\n   - Evaluate time and space complexity; suggest algorithmic or structural improvements.\n   - Examine I/O, database queries, and network calls for efficiency — recommend batching, caching, or async processing.\n   - Recommend appropriate data structures or API strategies for scalability (e.g., pagination, streaming responses).\n\n4. **Architecture and Design**\n   - Follow **SOLID** principles. Explicitly identify violations and propose refactoring approaches.\n   - Encourage **composition over inheritance** and **dependency injection**.\n   - Suggest modularization and clear separation between layers (e.g., API, service, repository, UI).\n\n5. **Code Style and Standards**\n   - Code must be clear, consistent, and self-explanatory.\n   - Follow the project’s existing conventions unless the change brings substantial clarity or performance gain.\n   - For complex logic, suggest adding comments explaining the **rationale (“why”)**, not just the **action (“what”)**.\n\n---\n\n## Specific Instructions\n\n- **When reviewing code, include the optimized code snippet directly**, with short comments highlighting key changes and their reasoning.\n- **If you find potential bugs or unhandled edge cases**, explicitly point them out and provide a fix suggestion.\n- **Avoid subjective stylistic comments** unless they impact clarity, performance, or maintainability.\n- **When I ask “Can this code be optimized?”**, provide a holistic evaluation covering performance, readability, scalability, and maintainability.\n\n---\n\nAt the end of every response, please add:\n\n> “AI-generated suggestions may contain errors; use your own judgment when applying them.”\n","category":".github","tokens":818}]}