{"owner":"Hiram-Wong","repo":"zyfun","hasSkills":true,"hasMcp":false,"mcpConfig":null,"found":["CLAUDE.md"],"skills":{"CLAUDE.md":"# AI Assistant Guide\n\nThis file provides guidance to AI coding assistants when working with code in this repository. Adherence to these guidelines is crucial for maintaining code quality and consistency.\n\n## Guiding Principles (MUST FOLLOW)\n\n- **Keep it clear**: Write code that is easy to read, maintain, and explain.\n- **Start simple**: Begin with the simplest design — no extra abstraction layers, wrapper classes, or separate services unless explicitly requested. Prefer flat, minimal designs.\n- **Fix upstream, don't hack downstream**: When a new feature hits an existing module's limitation, flag the upstream improvement for the user's decision before proposing a downstream workaround.\n- **Read local READMEs first**: Before editing code in a directory, check for a `README.md` in that directory (and its parents) and read it — these files capture local conventions, invariants, and entry points that aren't obvious from the code alone.\n- **Library-first, custom-last**: Before writing custom code, check library/framework docs for built-in options or existing solutions. Write custom code only when no adequate alternative exists.\n- **Match the house style**: Reuse existing patterns, naming, and conventions.\n- **Research via subagent**: Lean on `subagent` for external docs, APIs, news, and references.\n- **Log centrally**: Using the correct context, the main-process logs via `loggerService`, renderer-process often uses `console.log`.\n- **Access paths centrally**: Use `application.getPath('namespace.key', filename?)` for all main-process filesystem paths—never call `app.getPath()`, `os.homedir()`, or construct paths ad-hoc. Import the singleton via `import { application } from '@application'`.\n- **Always propose before executing**: Before making any changes, clearly explain your planned approach and wait for explicit user approval to ensure alignment and prevent unwanted modifications.\n- **Lint, test, and format before completion**: Coding tasks are only complete after running `pnpm lint`, `pnpm test`, and `pnpm format` successfully.\n- **Write conventional commits**: Commit small, focused changes using Conventional Commit messages (e.g., `feat:`, `fix:`, `refactor:`, `docs:`).- **Keep history linear**: On shared branches, never use plain `git pull` — it creates merge commits. Always `git pull --rebase` (or `git fetch && git rebase origin/<branch>`). Before `git push`, run `git fetch`; if `origin/<branch>` has advanced, rebase your local commits onto it first. If you notice a merge commit in local history that hasn't been pushed yet, rebase it away — cleaning one up after it's public requires a risky force-push on a shared branch.\n- **Sign commits**: Use `git commit --signoff` as required by contributor guidelines.\n\n## Development\n\n### Commands\n\nRun `pnpm install` first (requires Node ≥22, pnpm 10.27.0). For every other script, read `package.json` — the ones you must know:\n\n- `pnpm lint` — run eslint auto-fix, typeScript type checking, and prettier format check\n- `pnpm stylelint` - run stylelint fix for stylesheets\n- `pnpm test` — run all Vitest tests\n- `pnpm format` — format files with prettier and run lint in write/fix mode.\n- `pnpm build:check` — **REQUIRED before commits** (`pnpm lint && pnpm test`).\n\n### Testing\n\n- Tests run with Vitest 3 (see `vitest.config.*` for project setup).\n<!-- - **Features without tests are not considered complete** -->\n\n### Patched Dependencies\n\nBefore upgrading any dependency, check `patches/` for custom patches.\n\n## Conventions\n\n### TypeScript\n\n- Strict mode enabled; use `tsgo` (native TypeScript compiler preview) for typechecking\n- Separate configs: `tsconfig.node.json` (main), `tsconfig.web.json` (renderer)\n- Type definitions centralized in `src/renderer/src/types/` and `src/shared/`\n\n### File Naming\n\n- Vue components: `PascalCase.tsx`\n- Services, hooks, utilities: `camelCase.ts`\n- Test files: `*.test.ts` or `*.spec.ts` alongside source or in `__tests__/` subdirectory\n\n### Logging\n\n```typescript\nimport { loggerService } from '@logger';\nconst logger = loggerService.withContext('moduleName');\n// Renderer only: loggerService.initWindowSource('windowName') first\nlogger.info('message', CONTEXT);\nlogger.warn('message');\nlogger.error('message', error);\n```\n\n- Backend: Winston with daily log rotation\n- Log files in `userData/log/`\n- Never use `console.log` — always use `loggerService`\n\n### Paths\n\n```typescript\nimport { getSystemPath, getUserPath } from '@main/utils/path';\n\ngetUserPath('typeName'); // get user data path\ngetUserPath('typeName'); // get system data path\n```\n\n### UI Design\n\n- TDesign\n\n## Security\n\n- Never expose Node.js APIs directly to renderer; use `contextBridge` in preload\n- Validate all IPC inputs in main process handlers\n- URL sanitization via `strict-url-sanitise`\n"},"files":{"CLAUDE.md":"# AI Assistant Guide\n\nThis file provides guidance to AI coding assistants when working with code in this repository. Adherence to these guidelines is crucial for maintaining code quality and consistency.\n\n## Guiding Principles (MUST FOLLOW)\n\n- **Keep it clear**: Write code that is easy to read, maintain, and explain.\n- **Start simple**: Begin with the simplest design — no extra abstraction layers, wrapper classes, or separate services unless explicitly requested. Prefer flat, minimal designs.\n- **Fix upstream, don't hack downstream**: When a new feature hits an existing module's limitation, flag the upstream improvement for the user's decision before proposing a downstream workaround.\n- **Read local READMEs first**: Before editing code in a directory, check for a `README.md` in that directory (and its parents) and read it — these files capture local conventions, invariants, and entry points that aren't obvious from the code alone.\n- **Library-first, custom-last**: Before writing custom code, check library/framework docs for built-in options or existing solutions. Write custom code only when no adequate alternative exists.\n- **Match the house style**: Reuse existing patterns, naming, and conventions.\n- **Research via subagent**: Lean on `subagent` for external docs, APIs, news, and references.\n- **Log centrally**: Using the correct context, the main-process logs via `loggerService`, renderer-process often uses `console.log`.\n- **Access paths centrally**: Use `application.getPath('namespace.key', filename?)` for all main-process filesystem paths—never call `app.getPath()`, `os.homedir()`, or construct paths ad-hoc. Import the singleton via `import { application } from '@application'`.\n- **Always propose before executing**: Before making any changes, clearly explain your planned approach and wait for explicit user approval to ensure alignment and prevent unwanted modifications.\n- **Lint, test, and format before completion**: Coding tasks are only complete after running `pnpm lint`, `pnpm test`, and `pnpm format` successfully.\n- **Write conventional commits**: Commit small, focused changes using Conventional Commit messages (e.g., `feat:`, `fix:`, `refactor:`, `docs:`).- **Keep history linear**: On shared branches, never use plain `git pull` — it creates merge commits. Always `git pull --rebase` (or `git fetch && git rebase origin/<branch>`). Before `git push`, run `git fetch`; if `origin/<branch>` has advanced, rebase your local commits onto it first. If you notice a merge commit in local history that hasn't been pushed yet, rebase it away — cleaning one up after it's public requires a risky force-push on a shared branch.\n- **Sign commits**: Use `git commit --signoff` as required by contributor guidelines.\n\n## Development\n\n### Commands\n\nRun `pnpm install` first (requires Node ≥22, pnpm 10.27.0). For every other script, read `package.json` — the ones you must know:\n\n- `pnpm lint` — run eslint auto-fix, typeScript type checking, and prettier format check\n- `pnpm stylelint` - run stylelint fix for stylesheets\n- `pnpm test` — run all Vitest tests\n- `pnpm format` — format files with prettier and run lint in write/fix mode.\n- `pnpm build:check` — **REQUIRED before commits** (`pnpm lint && pnpm test`).\n\n### Testing\n\n- Tests run with Vitest 3 (see `vitest.config.*` for project setup).\n<!-- - **Features without tests are not considered complete** -->\n\n### Patched Dependencies\n\nBefore upgrading any dependency, check `patches/` for custom patches.\n\n## Conventions\n\n### TypeScript\n\n- Strict mode enabled; use `tsgo` (native TypeScript compiler preview) for typechecking\n- Separate configs: `tsconfig.node.json` (main), `tsconfig.web.json` (renderer)\n- Type definitions centralized in `src/renderer/src/types/` and `src/shared/`\n\n### File Naming\n\n- Vue components: `PascalCase.tsx`\n- Services, hooks, utilities: `camelCase.ts`\n- Test files: `*.test.ts` or `*.spec.ts` alongside source or in `__tests__/` subdirectory\n\n### Logging\n\n```typescript\nimport { loggerService } from '@logger';\nconst logger = loggerService.withContext('moduleName');\n// Renderer only: loggerService.initWindowSource('windowName') first\nlogger.info('message', CONTEXT);\nlogger.warn('message');\nlogger.error('message', error);\n```\n\n- Backend: Winston with daily log rotation\n- Log files in `userData/log/`\n- Never use `console.log` — always use `loggerService`\n\n### Paths\n\n```typescript\nimport { getSystemPath, getUserPath } from '@main/utils/path';\n\ngetUserPath('typeName'); // get user data path\ngetUserPath('typeName'); // get system data path\n```\n\n### UI Design\n\n- TDesign\n\n## Security\n\n- Never expose Node.js APIs directly to renderer; use `contextBridge` in preload\n- Validate all IPC inputs in main process handlers\n- URL sanitization via `strict-url-sanitise`\n"},"items":[{"name":"CLAUDE.md","path":"CLAUDE.md","title":"CLAUDE.md","content":"# AI Assistant Guide\n\nThis file provides guidance to AI coding assistants when working with code in this repository. Adherence to these guidelines is crucial for maintaining code quality and consistency.\n\n## Guiding Principles (MUST FOLLOW)\n\n- **Keep it clear**: Write code that is easy to read, maintain, and explain.\n- **Start simple**: Begin with the simplest design — no extra abstraction layers, wrapper classes, or separate services unless explicitly requested. Prefer flat, minimal designs.\n- **Fix upstream, don't hack downstream**: When a new feature hits an existing module's limitation, flag the upstream improvement for the user's decision before proposing a downstream workaround.\n- **Read local READMEs first**: Before editing code in a directory, check for a `README.md` in that directory (and its parents) and read it — these files capture local conventions, invariants, and entry points that aren't obvious from the code alone.\n- **Library-first, custom-last**: Before writing custom code, check library/framework docs for built-in options or existing solutions. Write custom code only when no adequate alternative exists.\n- **Match the house style**: Reuse existing patterns, naming, and conventions.\n- **Research via subagent**: Lean on `subagent` for external docs, APIs, news, and references.\n- **Log centrally**: Using the correct context, the main-process logs via `loggerService`, renderer-process often uses `console.log`.\n- **Access paths centrally**: Use `application.getPath('namespace.key', filename?)` for all main-process filesystem paths—never call `app.getPath()`, `os.homedir()`, or construct paths ad-hoc. Import the singleton via `import { application } from '@application'`.\n- **Always propose before executing**: Before making any changes, clearly explain your planned approach and wait for explicit user approval to ensure alignment and prevent unwanted modifications.\n- **Lint, test, and format before completion**: Coding tasks are only complete after running `pnpm lint`, `pnpm test`, and `pnpm format` successfully.\n- **Write conventional commits**: Commit small, focused changes using Conventional Commit messages (e.g., `feat:`, `fix:`, `refactor:`, `docs:`).- **Keep history linear**: On shared branches, never use plain `git pull` — it creates merge commits. Always `git pull --rebase` (or `git fetch && git rebase origin/<branch>`). Before `git push`, run `git fetch`; if `origin/<branch>` has advanced, rebase your local commits onto it first. If you notice a merge commit in local history that hasn't been pushed yet, rebase it away — cleaning one up after it's public requires a risky force-push on a shared branch.\n- **Sign commits**: Use `git commit --signoff` as required by contributor guidelines.\n\n## Development\n\n### Commands\n\nRun `pnpm install` first (requires Node ≥22, pnpm 10.27.0). For every other script, read `package.json` — the ones you must know:\n\n- `pnpm lint` — run eslint auto-fix, typeScript type checking, and prettier format check\n- `pnpm stylelint` - run stylelint fix for stylesheets\n- `pnpm test` — run all Vitest tests\n- `pnpm format` — format files with prettier and run lint in write/fix mode.\n- `pnpm build:check` — **REQUIRED before commits** (`pnpm lint && pnpm test`).\n\n### Testing\n\n- Tests run with Vitest 3 (see `vitest.config.*` for project setup).\n<!-- - **Features without tests are not considered complete** -->\n\n### Patched Dependencies\n\nBefore upgrading any dependency, check `patches/` for custom patches.\n\n## Conventions\n\n### TypeScript\n\n- Strict mode enabled; use `tsgo` (native TypeScript compiler preview) for typechecking\n- Separate configs: `tsconfig.node.json` (main), `tsconfig.web.json` (renderer)\n- Type definitions centralized in `src/renderer/src/types/` and `src/shared/`\n\n### File Naming\n\n- Vue components: `PascalCase.tsx`\n- Services, hooks, utilities: `camelCase.ts`\n- Test files: `*.test.ts` or `*.spec.ts` alongside source or in `__tests__/` subdirectory\n\n### Logging\n\n```typescript\nimport { loggerService } from '@logger';\nconst logger = loggerService.withContext('moduleName');\n// Renderer only: loggerService.initWindowSource('windowName') first\nlogger.info('message', CONTEXT);\nlogger.warn('message');\nlogger.error('message', error);\n```\n\n- Backend: Winston with daily log rotation\n- Log files in `userData/log/`\n- Never use `console.log` — always use `loggerService`\n\n### Paths\n\n```typescript\nimport { getSystemPath, getUserPath } from '@main/utils/path';\n\ngetUserPath('typeName'); // get user data path\ngetUserPath('typeName'); // get system data path\n```\n\n### UI Design\n\n- TDesign\n\n## Security\n\n- Never expose Node.js APIs directly to renderer; use `contextBridge` in preload\n- Validate all IPC inputs in main process handlers\n- URL sanitization via `strict-url-sanitise`\n","category":"root","tokens":1198}]}