{"owner":"0xJacky","repo":"nginx-ui","hasSkills":true,"totalSkillsCount":5,"totalTokensCount":4163,"categories":["mcp-config","cursor-rule","anthropic-skill","claude-rule"],"hasMcp":true,"mcpConfig":{"mcpServers":{"eslint":{"command":"npx","args":["@eslint/mcp@latest"],"env":{}},"context7":{"command":"npx","args":["-y","@upstash/context7-mcp"]}}},"found":[".cursor/mcp.json",".cursor/rules/frontend.mdc",".cursor/rules/backend.mdc",".claude/skills/release/SKILL.md","CLAUDE.md"],"skills":{".cursor/mcp.json":"{\n\t\"mcpServers\": {\n\t\t\"eslint\": {\n\t\t\t\"command\": \"npx\",\n\t\t\t\"args\": [\"@eslint/mcp@latest\"],\n\t\t\t\"env\": {}\n\t\t},\n\t\t\"context7\": {\n      \"command\": \"npx\",\n      \"args\": [\"-y\", \"@upstash/context7-mcp\"]\n    }\n\t}\n}",".cursor/rules/frontend.mdc":"---\ndescription: \nglobs: app/**/*.tsx,app/**/*.vue,app/**/*.ts,app/**/*.js,app/**/*.json\nalwaysApply: false\n---\nYou are an expert in TypeScript, Node.js, Vite, Vue.js, Vue Router, Pinia, VueUse, Ant Design Vue, and UnoCSS, with a deep understanding of best practices and performance optimization techniques in these technologies.\n\nPackage manager: Bun\n- bun run typecheck\n  \n    Code Style and Structure\n    - Write concise, maintainable, and technically accurate TypeScript code with relevant examples.\n    - Use functional and declarative programming patterns; avoid classes.\n    - Favor iteration and modularization to adhere to DRY principles and avoid code duplication.\n    - Use descriptive variable names with auxiliary verbs (e.g., isLoading, hasError).\n    - Organize files systematically: each file should contain only related content, such as exported components, subcomponents, helpers, static content, and types.\n    - Define API and types in app/src/api\n  \n    Naming Conventions\n    - In src/components, the name should be CamelCase (e.g., app/src/components/ChatGPT/ChatGPT.vue)\n    - In src/views, the folder name should be lower case with underline, but the component name should be CamelCase (e.g., app/src/views/system/About.vue)\n    - Favor named exports for functions.\n  \n    TypeScript Usage\n    - Use TypeScript for all code; prefer interfaces over types for their extendability and ability to merge.\n  \n    Syntax and Formatting\n    - Use the \"function\" keyword for pure functions to benefit from hoisting and clarity.\n    - Always use the Vue Composition API script setup style.\n    - Use Vue3.4+ features like defineModel(), useTemplateRef(), v-bind Same-name Shorthand\n  \n    UI and Styling\n    - Use Ant Design Vue, UnoCSS for components and styling.\n    - Implement responsive design with UnoCSS and Antdv Flex layout; use a mobile-first approach.\n  \n    Performance Optimization\n    - Leverage VueUse functions where applicable to enhance reactivity and performance.\n    - Wrap asynchronous components in Suspense with a fallback UI.\n    - Use dynamic loading for non-critical components.\n    - Optimize images: use WebP format, include size data, implement lazy loading.\n    - Implement an optimized chunking strategy during the Vite build process, such as code splitting, to generate smaller bundle sizes.\n  \n    Key Conventions\n    - Optimize Web Vitals (LCP, CLS, FID) using tools like Lighthouse or WebPageTest.\n\n    Comments\n    - Always response in English\n",".cursor/rules/backend.mdc":"---\ndescription: \nglobs: **/**/*.go\nalwaysApply: false\n---\n# Cursor Rules\nYou are an expert in Go, Gin, Gorm, Gen, Cosy (https://cosy.uozi.org/) with a deep understanding of best practices and performance optimization techniques in these technologies.\n\n## 1. Code Style and Structure\n\n- **Concise and Maintainable Code:**  \n  Write technically accurate and easily understandable Go code with relevant examples.\n\n- **API Controllers:**  \n  Implement API controllers in the `api/$modules_name` directory.\n\n- **Database Models:**  \n  Define database table models in the `model/` folder.\n\n- **Query Simplification:**  \n  Use [Gen](mdc:https:/cosy.uozi.org) to streamline query operations, reducing boilerplate code.\n\n- **Business Logic and Error Handling:**  \n  Place complex API logic and custom error definitions in `internal/$modules_name`. Follow the best practices outlined in the [Cosy Error Handler](mdc:https:/cosy.uozi.org/error-handler).\n\n- **Routing:**  \n  Register all application routes in the `router/` directory.\n\n- **Configuration Management:**  \n  Manage and register configuration settings in the `settings/` directory.\n\n## 2. CRUD Operations\n\n- **Standardized Operations:**  \n  Utilize [Cosy](mdc:https:/cosy.uozi.org) to implement Create, Read, Update, and Delete (CRUD) operations consistently across the project.\n\n## 3. Performance Optimization\n\n- **Efficient Database Pagination:**  \n  Implement database pagination techniques to handle large datasets efficiently.\n\n- **Overall Performance:**  \n  Apply performance optimization techniques to ensure fast response times and resource efficiency.\n\n## 4. File Organization and Formatting\n\n- **Modular Files:**  \n  Keep individual files concise by splitting code based on functionality, promoting better readability and maintainability.\n\n- **Consistent Syntax and Formatting:**  \n  Follow consistent coding standards and formatting rules across the project to enhance clarity.\n\n## 5. Documentation and Comments\n\n- **English Language:**  \n  All code comments and documentation should be written in English to maintain consistency and accessibility.",".claude/skills/release/SKILL.md":"---\nname: release\ndescription: Use when preparing or publishing an NGINX UI release, including version bumping with version.sh, release notes, Avira pre-publication checks, tags, GitHub Releases, and optional post-release publication to the RainYun cloud app store.\n---\n\n# NGINX UI Release\n\nUse this workflow for NGINX UI releases from the repository root.\n\n## Preconditions\n\n- Work from the `dev` branch.\n- Inspect `git status --short --branch` before changing files.\n- If the user asks to commit existing workspace changes first, inspect recent commit style and commit that work separately before release prep.\n- Keep staging explicit. Do not include unrelated local changes.\n- Treat `release-notes-vX.Y.Z.md` as a temporary local release artifact, not a committed file.\n\n## Version Preparation\n\n1. Run `./version.sh` outside the sandbox when possible. It updates `app/package.json`, runs the frontend build, and refreshes generated artifacts that can require network access.\n2. Enter the release version as `vX.Y.Z` when prompted and confirm it.\n3. Check the generated diff with `git status --short` and `git diff --stat`.\n4. Commit only version-preparation artifacts with:\n\n```bash\ngit add <version-prep-files>\ngit commit -m \"chore: prepare vX.Y.Z\"\n```\n\nDo not commit `release-notes-vX.Y.Z.md`.\n\n## Release Notes\n\nCreate `release-notes-vX.Y.Z.md` in the repository root using exactly these sections:\n\n```markdown\n## Features\n\n- <User-facing feature summary> by @<contributor> ([<short-hash>](https://github.com/0xJacky/nginx-ui/commit/<full-sha>))\n\n## Bug Fixes\n\n- <User-facing fix summary> by @<contributor> ([<short-hash>](https://github.com/0xJacky/nginx-ui/commit/<full-sha>))\n\n## Contributors\n\n@handle\n```\n\nGuidelines:\n\n- Base the notes on the verified range from the previous release tag to `HEAD`.\n- Every actual change bullet must include both the verified contributor's `@handle` and a linked short commit hash, even when a PR link is also included. The `Contributors` section does not replace per-change attribution.\n- Resolve handles from the merged PR author and verified co-authors, or the GitHub-linked commit author for direct commits. Do not automatically credit the merger or committer, and never infer a handle from a display name or email. Resolve missing attribution before finalizing the notes; if it cannot be verified, ask the user for the handle or an explicit attribution exception.\n- Use a commit that implements the summarized change and belongs to the verified release range. For squash merges, use the resulting squash commit; for rebased or cherry-picked changes, use the commit shipped in this repository. Never use the release-prep commit as a substitute.\n- Display a unique abbreviated SHA, starting at 8 characters and extending it if ambiguous, and link it to the full commit SHA on GitHub.\n- Write concise summaries of notable user-facing outcomes rather than copying the raw commit log. Group commits only when they describe one coherent change; retain all relevant contributor handles and the linked hashes needed to substantiate the summary. Split unrelated changes into separate bullets.\n- List verified release contributors once each in `Contributors`, including everyone credited inline.\n- If a change section is empty, use `- None.`; this sentinel needs no contributor or hash.\n- Do not include test status unless the user explicitly asks for it.\n\nBefore finalizing, check every change bullet for accurate attribution, a resolving commit link, and membership in the release range. Reuse the same reviewed notes for the tag annotation and GitHub Release body.\n\nReferences: [Keep a Changelog](https://keepachangelog.com/en/1.1.0/) for curated, grouped summaries and [GitHub release notes](https://docs.github.com/en/repositories/releasing-projects-on-github/automatically-generated-release-notes) for contributor credit and change traceability. Per-change handles and short hashes are this project's required format.\n\n## Validation\n\n- `./version.sh` already runs the frontend build and Go generation.\n- By default, run lightweight checks such as `git diff --check`.\n- Run broader tests only when appropriate for the release scope or when the user requests them. If the user says to skip tests, do not keep trying to run them.\n- If local tests are affected by a parent Go workspace, use repo-isolated mode such as `GOWORK=off` and a writable `GOCACHE`.\n\n## Avira Pre-Publication Gate\n\nComplete this gate after the release-prep commit and before creating or pushing the release tag or publishing the GitHub Release:\n\n1. Record the exact release-candidate commit from `git rev-parse HEAD`.\n2. After explicit publication authorization, push only `dev` so the `Build` workflow can produce the Windows amd64 artifact from that exact commit. Do not push the release tag yet.\n3. Wait for the `Build` workflow for the candidate commit to succeed. Download its Windows amd64 artifact and verify that it contains the expected `nginx-ui.exe`.\n4. Record the executable SHA-256. Archive only `nginx-ui.exe` in a password-protected ZIP under Avira's 50 MB limit using password `infected`.\n5. Immediately before transmitting the archive and contact details, obtain the required external-submission confirmation. Submit the sample to Avira VirusLab as `Suspected False Positive (Not Malware)` with the planned version, candidate commit, executable hash, source URL, and release URL.\n6. Stop until Avira explicitly reports `Clean`. A pending result or detection leaves the release tag and GitHub Release unpublished.\n7. Recheck that `HEAD` and `origin/dev` still resolve to the scanned candidate commit. Any commit change invalidates the result and requires a new artifact and scan.\n\nThe pre-publication artifact is content-level evidence, not guaranteed byte-for-byte proof of the final GitHub Release asset because the build embeds `settings.buildTime`. After publication, record the exact published Windows ZIP and extracted EXE SHA-256 values. If WinGet flags the final executable, submit that exact EXE to Avira before requesting an ESRP rerun.\n\n## Tag, Push, And Publish\n\nOnly after the Avira pre-publication result is `Clean` and the candidate commit is unchanged:\n\n```bash\ngit -c tag.gpgSign=false tag -a vX.Y.Z -F release-notes-vX.Y.Z.md\ngit push origin vX.Y.Z\ngh release create vX.Y.Z --verify-tag --title vX.Y.Z -F release-notes-vX.Y.Z.md --discussion-category Announcements\n```\n\nNotes:\n\n- Use `git -c tag.gpgSign=false tag -a ...` when local GPG signing blocks tag creation.\n- The GitHub Release command is expected to create the matching Announcements discussion.\n- Verify publication with `gh release view vX.Y.Z` and, if needed, inspect recent Discussions in the `Announcements` category.\n- Download the final `nginx-ui-windows-64.zip`, record its SHA-256, extract `nginx-ui.exe`, and record the executable SHA-256.\n- After a successful release, leave the release-note markdown untracked unless the user asks to delete it.\n\n## RainYun Cloud App Publication\n\nRainYun is a downstream distribution phase. Start it only after the GitHub Release is final, the required release workflows have completed, and the versioned Docker image is available for the target RainYun architecture. Do not make RainYun a prerequisite for publishing the GitHub Release.\n\nWhen the release request includes RainYun or store publication, read and follow [references/rainyun.md](references/rainyun.md). Its template contract, deployment proof, external-action boundaries, billing confirmation, CAPTCHA handoff, store-state readback, and README promotion requirements are release gates for this phase.\n\nA generic GitHub release authorization does not by itself authorize RainYun template changes, a potentially billed test deployment, or application submission. Obtain the required RainYun scope before external mutations and obtain action-time confirmation immediately before the final install/deploy control.\n","CLAUDE.md":"# NGINX UI - Claude Code Guidelines\n\nThis project is a web-based NGINX management interface built with Go backend and Vue.js frontend.\n\n## Package Manager\n- **Use Bun exclusively** for all frontend package management operations\n- Commands: `bun install`, `bun run dev`, `bun run typecheck`\n\n## Backend (Go) Development\n\n### Technologies & Frameworks\n- **Go** with Gin web framework\n- **GORM** for database operations  \n- **Gen** for query simplification\n- **Cosy** framework (https://cosy.uozi.org/)\n\n### Code Organization\n- **API Controllers**: Implement in `api/$module_name/` directory\n- **Database Models**: Define in `model/` folder\n- **Business Logic**: Place complex logic and error handling in `internal/$module_name/`\n- **Routing**: Register routes in `router/` directory\n- **Configuration**: Manage settings in `settings/` directory\n\n### Development Guidelines\n- Write concise, maintainable Go code with clear examples\n- Run `gofmt`/`goimports` before committing backend changes\n- Use Gen to streamline database queries and reduce boilerplate\n- Follow Cosy Error Handler best practices for error management\n- Implement standardized CRUD operations using Cosy framework\n- Apply efficient database pagination for large datasets\n- Before committing backend changes, run the CI-equivalent unit test command: `GOWORK=off go test -tags=unembed -race -cover -count=1 ./...`\n- Keep `-count=1` in pre-commit unit tests so cached results cannot hide race conditions or flaky failures\n- Keep files modular and well-organized by functionality\n- **All comments and documentation must be in English**\n\n## Frontend (Vue.js) Development\n\n### Technology Stack\n- **TypeScript** for all code\n- **Vue 3** with Composition API\n- **Vite** build tool\n- **Vue Router** for routing\n- **Pinia** for state management\n- **VueUse** for utilities\n- **antdv-next** for UI components (migrated from `ant-design-vue@4`; the icon package is `@antdv-next/icons`)\n- **UnoCSS** for styling\n\n### Code Standards\n- Use functional and declarative programming patterns (avoid classes)\n- Prefer interfaces over types for better extendability\n- Use descriptive variable names with auxiliary verbs (e.g., `isLoading`, `hasError`)\n- Always use Vue Composition API with `<script setup>` syntax\n- Leverage Vue 3.4+ features: `defineModel()`, `useTemplateRef()`, v-bind shorthand\n\n### File Organization\n- **Components**: Use CamelCase naming in `src/components/` (e.g., `ChatGPT/ChatGPT.vue`)\n- **Views**: Use lowercase with underscores for folders, CamelCase for components (e.g., `src/views/system/About.vue`)\n- **API & Types**: Define in `app/src/api/`\n- **Exports**: Favor named exports for functions\n\n### UI & Styling\n- Use antdv-next components and UnoCSS for styling\n- Always check dark mode when adding or changing styles\n- Prefer a component's semantic `classes` / `styles` props over `:deep(.ant-*)` overrides; antdv-next owns its internal DOM and changes it between versions\n- Implement responsive design with mobile-first approach\n- Use antdv-next Flex layout for responsive layouts\n\n### Performance Optimization\n- Leverage VueUse functions for enhanced reactivity\n- Wrap async components in Suspense with fallback UI\n- Use dynamic loading for non-critical components\n- Optimize images: WebP format, size data, lazy loading\n- Implement code splitting and chunking strategy in Vite build\n- Optimize Web Vitals (LCP, CLS, FID)\n\n### Code Quality\n- **Always use ESLint MCP after generating frontend code** to ensure code quality and consistency\n- Run `bun run lint`, `bun run lint:fix`, and `bun run typecheck` to keep style and typings aligned\n\n## Development Commands\n- **Frontend**: `bun run dev`, `bun run lint`, `bun run typecheck`, `bun run build`\n- **Backend**: `go generate ./...`, `go build ./...`, run `GOWORK=off go test -tags=unembed -race -cover -count=1 ./...`; for release artifacts reuse the README command with `-tags=jsoniter -ldflags \"$LD_FLAGS ...\"`.\n- **Demo stack**: `docker-compose -f docker-compose-demo.yml up` to bootstrap the sample environment\n\n\n## Release Workflow\n- Start releases from the `dev` branch with a clean working tree.\n- Run `./version.sh` outside the sandbox to update the version, rebuild the frontend, and refresh generated artifacts that require network access.\n- Prepare release notes in a temporary local markdown file such as `release-notes-vX.Y.Z.md`.\n- Follow the existing three-section release note style: `Features`, `Bug Fixes`, and `Contributors`.\n- Write contributor names using GitHub handles when they are known from the merged PR, not raw git author names.\n- Do not commit the release note markdown file. Keep it untracked and use it directly for the tag annotation and GitHub Release body.\n- Commit only the version-preparation artifacts with `chore: prepare vX.Y.Z`.\n- Create an annotated tag from the release note file. If local GPG signing blocks tag creation in the sandbox, create the tag outside the sandbox with `git -c tag.gpgSign=false tag -a vX.Y.Z -F release-notes-vX.Y.Z.md`.\n- Push both `dev` and the release tag with `git push origin dev vX.Y.Z`.\n- Publish the release with `gh release create vX.Y.Z --verify-tag --title vX.Y.Z -F release-notes-vX.Y.Z.md --discussion-category Announcements`.\n- The release flow is expected to create the GitHub Release and the linked Discussion post, then GitHub Actions handles binary, Docker, Homebrew, WinGet, and branch-sync automation.\n\n## Language Requirements\n- **All code comments, documentation, and communication must be in English**\n- Maintain consistency and accessibility across the codebase\n- 优先使用 context7 mcp 搜索文档\n- 生成 find 命令的时候应该排除掉 ./.go/ 这个文件夹，因为那里面是 devcontainer 的依赖\n"},"files":{".cursor/mcp.json":"{\n\t\"mcpServers\": {\n\t\t\"eslint\": {\n\t\t\t\"command\": \"npx\",\n\t\t\t\"args\": [\"@eslint/mcp@latest\"],\n\t\t\t\"env\": {}\n\t\t},\n\t\t\"context7\": {\n      \"command\": \"npx\",\n      \"args\": [\"-y\", \"@upstash/context7-mcp\"]\n    }\n\t}\n}",".cursor/rules/frontend.mdc":"---\ndescription: \nglobs: app/**/*.tsx,app/**/*.vue,app/**/*.ts,app/**/*.js,app/**/*.json\nalwaysApply: false\n---\nYou are an expert in TypeScript, Node.js, Vite, Vue.js, Vue Router, Pinia, VueUse, Ant Design Vue, and UnoCSS, with a deep understanding of best practices and performance optimization techniques in these technologies.\n\nPackage manager: Bun\n- bun run typecheck\n  \n    Code Style and Structure\n    - Write concise, maintainable, and technically accurate TypeScript code with relevant examples.\n    - Use functional and declarative programming patterns; avoid classes.\n    - Favor iteration and modularization to adhere to DRY principles and avoid code duplication.\n    - Use descriptive variable names with auxiliary verbs (e.g., isLoading, hasError).\n    - Organize files systematically: each file should contain only related content, such as exported components, subcomponents, helpers, static content, and types.\n    - Define API and types in app/src/api\n  \n    Naming Conventions\n    - In src/components, the name should be CamelCase (e.g., app/src/components/ChatGPT/ChatGPT.vue)\n    - In src/views, the folder name should be lower case with underline, but the component name should be CamelCase (e.g., app/src/views/system/About.vue)\n    - Favor named exports for functions.\n  \n    TypeScript Usage\n    - Use TypeScript for all code; prefer interfaces over types for their extendability and ability to merge.\n  \n    Syntax and Formatting\n    - Use the \"function\" keyword for pure functions to benefit from hoisting and clarity.\n    - Always use the Vue Composition API script setup style.\n    - Use Vue3.4+ features like defineModel(), useTemplateRef(), v-bind Same-name Shorthand\n  \n    UI and Styling\n    - Use Ant Design Vue, UnoCSS for components and styling.\n    - Implement responsive design with UnoCSS and Antdv Flex layout; use a mobile-first approach.\n  \n    Performance Optimization\n    - Leverage VueUse functions where applicable to enhance reactivity and performance.\n    - Wrap asynchronous components in Suspense with a fallback UI.\n    - Use dynamic loading for non-critical components.\n    - Optimize images: use WebP format, include size data, implement lazy loading.\n    - Implement an optimized chunking strategy during the Vite build process, such as code splitting, to generate smaller bundle sizes.\n  \n    Key Conventions\n    - Optimize Web Vitals (LCP, CLS, FID) using tools like Lighthouse or WebPageTest.\n\n    Comments\n    - Always response in English\n",".cursor/rules/backend.mdc":"---\ndescription: \nglobs: **/**/*.go\nalwaysApply: false\n---\n# Cursor Rules\nYou are an expert in Go, Gin, Gorm, Gen, Cosy (https://cosy.uozi.org/) with a deep understanding of best practices and performance optimization techniques in these technologies.\n\n## 1. Code Style and Structure\n\n- **Concise and Maintainable Code:**  \n  Write technically accurate and easily understandable Go code with relevant examples.\n\n- **API Controllers:**  \n  Implement API controllers in the `api/$modules_name` directory.\n\n- **Database Models:**  \n  Define database table models in the `model/` folder.\n\n- **Query Simplification:**  \n  Use [Gen](mdc:https:/cosy.uozi.org) to streamline query operations, reducing boilerplate code.\n\n- **Business Logic and Error Handling:**  \n  Place complex API logic and custom error definitions in `internal/$modules_name`. Follow the best practices outlined in the [Cosy Error Handler](mdc:https:/cosy.uozi.org/error-handler).\n\n- **Routing:**  \n  Register all application routes in the `router/` directory.\n\n- **Configuration Management:**  \n  Manage and register configuration settings in the `settings/` directory.\n\n## 2. CRUD Operations\n\n- **Standardized Operations:**  \n  Utilize [Cosy](mdc:https:/cosy.uozi.org) to implement Create, Read, Update, and Delete (CRUD) operations consistently across the project.\n\n## 3. Performance Optimization\n\n- **Efficient Database Pagination:**  \n  Implement database pagination techniques to handle large datasets efficiently.\n\n- **Overall Performance:**  \n  Apply performance optimization techniques to ensure fast response times and resource efficiency.\n\n## 4. File Organization and Formatting\n\n- **Modular Files:**  \n  Keep individual files concise by splitting code based on functionality, promoting better readability and maintainability.\n\n- **Consistent Syntax and Formatting:**  \n  Follow consistent coding standards and formatting rules across the project to enhance clarity.\n\n## 5. Documentation and Comments\n\n- **English Language:**  \n  All code comments and documentation should be written in English to maintain consistency and accessibility.",".claude/skills/release/SKILL.md":"---\nname: release\ndescription: Use when preparing or publishing an NGINX UI release, including version bumping with version.sh, release notes, Avira pre-publication checks, tags, GitHub Releases, and optional post-release publication to the RainYun cloud app store.\n---\n\n# NGINX UI Release\n\nUse this workflow for NGINX UI releases from the repository root.\n\n## Preconditions\n\n- Work from the `dev` branch.\n- Inspect `git status --short --branch` before changing files.\n- If the user asks to commit existing workspace changes first, inspect recent commit style and commit that work separately before release prep.\n- Keep staging explicit. Do not include unrelated local changes.\n- Treat `release-notes-vX.Y.Z.md` as a temporary local release artifact, not a committed file.\n\n## Version Preparation\n\n1. Run `./version.sh` outside the sandbox when possible. It updates `app/package.json`, runs the frontend build, and refreshes generated artifacts that can require network access.\n2. Enter the release version as `vX.Y.Z` when prompted and confirm it.\n3. Check the generated diff with `git status --short` and `git diff --stat`.\n4. Commit only version-preparation artifacts with:\n\n```bash\ngit add <version-prep-files>\ngit commit -m \"chore: prepare vX.Y.Z\"\n```\n\nDo not commit `release-notes-vX.Y.Z.md`.\n\n## Release Notes\n\nCreate `release-notes-vX.Y.Z.md` in the repository root using exactly these sections:\n\n```markdown\n## Features\n\n- <User-facing feature summary> by @<contributor> ([<short-hash>](https://github.com/0xJacky/nginx-ui/commit/<full-sha>))\n\n## Bug Fixes\n\n- <User-facing fix summary> by @<contributor> ([<short-hash>](https://github.com/0xJacky/nginx-ui/commit/<full-sha>))\n\n## Contributors\n\n@handle\n```\n\nGuidelines:\n\n- Base the notes on the verified range from the previous release tag to `HEAD`.\n- Every actual change bullet must include both the verified contributor's `@handle` and a linked short commit hash, even when a PR link is also included. The `Contributors` section does not replace per-change attribution.\n- Resolve handles from the merged PR author and verified co-authors, or the GitHub-linked commit author for direct commits. Do not automatically credit the merger or committer, and never infer a handle from a display name or email. Resolve missing attribution before finalizing the notes; if it cannot be verified, ask the user for the handle or an explicit attribution exception.\n- Use a commit that implements the summarized change and belongs to the verified release range. For squash merges, use the resulting squash commit; for rebased or cherry-picked changes, use the commit shipped in this repository. Never use the release-prep commit as a substitute.\n- Display a unique abbreviated SHA, starting at 8 characters and extending it if ambiguous, and link it to the full commit SHA on GitHub.\n- Write concise summaries of notable user-facing outcomes rather than copying the raw commit log. Group commits only when they describe one coherent change; retain all relevant contributor handles and the linked hashes needed to substantiate the summary. Split unrelated changes into separate bullets.\n- List verified release contributors once each in `Contributors`, including everyone credited inline.\n- If a change section is empty, use `- None.`; this sentinel needs no contributor or hash.\n- Do not include test status unless the user explicitly asks for it.\n\nBefore finalizing, check every change bullet for accurate attribution, a resolving commit link, and membership in the release range. Reuse the same reviewed notes for the tag annotation and GitHub Release body.\n\nReferences: [Keep a Changelog](https://keepachangelog.com/en/1.1.0/) for curated, grouped summaries and [GitHub release notes](https://docs.github.com/en/repositories/releasing-projects-on-github/automatically-generated-release-notes) for contributor credit and change traceability. Per-change handles and short hashes are this project's required format.\n\n## Validation\n\n- `./version.sh` already runs the frontend build and Go generation.\n- By default, run lightweight checks such as `git diff --check`.\n- Run broader tests only when appropriate for the release scope or when the user requests them. If the user says to skip tests, do not keep trying to run them.\n- If local tests are affected by a parent Go workspace, use repo-isolated mode such as `GOWORK=off` and a writable `GOCACHE`.\n\n## Avira Pre-Publication Gate\n\nComplete this gate after the release-prep commit and before creating or pushing the release tag or publishing the GitHub Release:\n\n1. Record the exact release-candidate commit from `git rev-parse HEAD`.\n2. After explicit publication authorization, push only `dev` so the `Build` workflow can produce the Windows amd64 artifact from that exact commit. Do not push the release tag yet.\n3. Wait for the `Build` workflow for the candidate commit to succeed. Download its Windows amd64 artifact and verify that it contains the expected `nginx-ui.exe`.\n4. Record the executable SHA-256. Archive only `nginx-ui.exe` in a password-protected ZIP under Avira's 50 MB limit using password `infected`.\n5. Immediately before transmitting the archive and contact details, obtain the required external-submission confirmation. Submit the sample to Avira VirusLab as `Suspected False Positive (Not Malware)` with the planned version, candidate commit, executable hash, source URL, and release URL.\n6. Stop until Avira explicitly reports `Clean`. A pending result or detection leaves the release tag and GitHub Release unpublished.\n7. Recheck that `HEAD` and `origin/dev` still resolve to the scanned candidate commit. Any commit change invalidates the result and requires a new artifact and scan.\n\nThe pre-publication artifact is content-level evidence, not guaranteed byte-for-byte proof of the final GitHub Release asset because the build embeds `settings.buildTime`. After publication, record the exact published Windows ZIP and extracted EXE SHA-256 values. If WinGet flags the final executable, submit that exact EXE to Avira before requesting an ESRP rerun.\n\n## Tag, Push, And Publish\n\nOnly after the Avira pre-publication result is `Clean` and the candidate commit is unchanged:\n\n```bash\ngit -c tag.gpgSign=false tag -a vX.Y.Z -F release-notes-vX.Y.Z.md\ngit push origin vX.Y.Z\ngh release create vX.Y.Z --verify-tag --title vX.Y.Z -F release-notes-vX.Y.Z.md --discussion-category Announcements\n```\n\nNotes:\n\n- Use `git -c tag.gpgSign=false tag -a ...` when local GPG signing blocks tag creation.\n- The GitHub Release command is expected to create the matching Announcements discussion.\n- Verify publication with `gh release view vX.Y.Z` and, if needed, inspect recent Discussions in the `Announcements` category.\n- Download the final `nginx-ui-windows-64.zip`, record its SHA-256, extract `nginx-ui.exe`, and record the executable SHA-256.\n- After a successful release, leave the release-note markdown untracked unless the user asks to delete it.\n\n## RainYun Cloud App Publication\n\nRainYun is a downstream distribution phase. Start it only after the GitHub Release is final, the required release workflows have completed, and the versioned Docker image is available for the target RainYun architecture. Do not make RainYun a prerequisite for publishing the GitHub Release.\n\nWhen the release request includes RainYun or store publication, read and follow [references/rainyun.md](references/rainyun.md). Its template contract, deployment proof, external-action boundaries, billing confirmation, CAPTCHA handoff, store-state readback, and README promotion requirements are release gates for this phase.\n\nA generic GitHub release authorization does not by itself authorize RainYun template changes, a potentially billed test deployment, or application submission. Obtain the required RainYun scope before external mutations and obtain action-time confirmation immediately before the final install/deploy control.\n","CLAUDE.md":"# NGINX UI - Claude Code Guidelines\n\nThis project is a web-based NGINX management interface built with Go backend and Vue.js frontend.\n\n## Package Manager\n- **Use Bun exclusively** for all frontend package management operations\n- Commands: `bun install`, `bun run dev`, `bun run typecheck`\n\n## Backend (Go) Development\n\n### Technologies & Frameworks\n- **Go** with Gin web framework\n- **GORM** for database operations  \n- **Gen** for query simplification\n- **Cosy** framework (https://cosy.uozi.org/)\n\n### Code Organization\n- **API Controllers**: Implement in `api/$module_name/` directory\n- **Database Models**: Define in `model/` folder\n- **Business Logic**: Place complex logic and error handling in `internal/$module_name/`\n- **Routing**: Register routes in `router/` directory\n- **Configuration**: Manage settings in `settings/` directory\n\n### Development Guidelines\n- Write concise, maintainable Go code with clear examples\n- Run `gofmt`/`goimports` before committing backend changes\n- Use Gen to streamline database queries and reduce boilerplate\n- Follow Cosy Error Handler best practices for error management\n- Implement standardized CRUD operations using Cosy framework\n- Apply efficient database pagination for large datasets\n- Before committing backend changes, run the CI-equivalent unit test command: `GOWORK=off go test -tags=unembed -race -cover -count=1 ./...`\n- Keep `-count=1` in pre-commit unit tests so cached results cannot hide race conditions or flaky failures\n- Keep files modular and well-organized by functionality\n- **All comments and documentation must be in English**\n\n## Frontend (Vue.js) Development\n\n### Technology Stack\n- **TypeScript** for all code\n- **Vue 3** with Composition API\n- **Vite** build tool\n- **Vue Router** for routing\n- **Pinia** for state management\n- **VueUse** for utilities\n- **antdv-next** for UI components (migrated from `ant-design-vue@4`; the icon package is `@antdv-next/icons`)\n- **UnoCSS** for styling\n\n### Code Standards\n- Use functional and declarative programming patterns (avoid classes)\n- Prefer interfaces over types for better extendability\n- Use descriptive variable names with auxiliary verbs (e.g., `isLoading`, `hasError`)\n- Always use Vue Composition API with `<script setup>` syntax\n- Leverage Vue 3.4+ features: `defineModel()`, `useTemplateRef()`, v-bind shorthand\n\n### File Organization\n- **Components**: Use CamelCase naming in `src/components/` (e.g., `ChatGPT/ChatGPT.vue`)\n- **Views**: Use lowercase with underscores for folders, CamelCase for components (e.g., `src/views/system/About.vue`)\n- **API & Types**: Define in `app/src/api/`\n- **Exports**: Favor named exports for functions\n\n### UI & Styling\n- Use antdv-next components and UnoCSS for styling\n- Always check dark mode when adding or changing styles\n- Prefer a component's semantic `classes` / `styles` props over `:deep(.ant-*)` overrides; antdv-next owns its internal DOM and changes it between versions\n- Implement responsive design with mobile-first approach\n- Use antdv-next Flex layout for responsive layouts\n\n### Performance Optimization\n- Leverage VueUse functions for enhanced reactivity\n- Wrap async components in Suspense with fallback UI\n- Use dynamic loading for non-critical components\n- Optimize images: WebP format, size data, lazy loading\n- Implement code splitting and chunking strategy in Vite build\n- Optimize Web Vitals (LCP, CLS, FID)\n\n### Code Quality\n- **Always use ESLint MCP after generating frontend code** to ensure code quality and consistency\n- Run `bun run lint`, `bun run lint:fix`, and `bun run typecheck` to keep style and typings aligned\n\n## Development Commands\n- **Frontend**: `bun run dev`, `bun run lint`, `bun run typecheck`, `bun run build`\n- **Backend**: `go generate ./...`, `go build ./...`, run `GOWORK=off go test -tags=unembed -race -cover -count=1 ./...`; for release artifacts reuse the README command with `-tags=jsoniter -ldflags \"$LD_FLAGS ...\"`.\n- **Demo stack**: `docker-compose -f docker-compose-demo.yml up` to bootstrap the sample environment\n\n\n## Release Workflow\n- Start releases from the `dev` branch with a clean working tree.\n- Run `./version.sh` outside the sandbox to update the version, rebuild the frontend, and refresh generated artifacts that require network access.\n- Prepare release notes in a temporary local markdown file such as `release-notes-vX.Y.Z.md`.\n- Follow the existing three-section release note style: `Features`, `Bug Fixes`, and `Contributors`.\n- Write contributor names using GitHub handles when they are known from the merged PR, not raw git author names.\n- Do not commit the release note markdown file. Keep it untracked and use it directly for the tag annotation and GitHub Release body.\n- Commit only the version-preparation artifacts with `chore: prepare vX.Y.Z`.\n- Create an annotated tag from the release note file. If local GPG signing blocks tag creation in the sandbox, create the tag outside the sandbox with `git -c tag.gpgSign=false tag -a vX.Y.Z -F release-notes-vX.Y.Z.md`.\n- Push both `dev` and the release tag with `git push origin dev vX.Y.Z`.\n- Publish the release with `gh release create vX.Y.Z --verify-tag --title vX.Y.Z -F release-notes-vX.Y.Z.md --discussion-category Announcements`.\n- The release flow is expected to create the GitHub Release and the linked Discussion post, then GitHub Actions handles binary, Docker, Homebrew, WinGet, and branch-sync automation.\n\n## Language Requirements\n- **All code comments, documentation, and communication must be in English**\n- Maintain consistency and accessibility across the codebase\n- 优先使用 context7 mcp 搜索文档\n- 生成 find 命令的时候应该排除掉 ./.go/ 这个文件夹，因为那里面是 devcontainer 的依赖\n"},"items":[{"name":"SKILL.md","path":".claude/skills/release/SKILL.md","rawUrl":"https://raw.githubusercontent.com/0xJacky/nginx-ui/HEAD/.claude/skills/release/SKILL.md","title":"release","category":"anthropic-skill","format":"markdown","content":"---\nname: release\ndescription: Use when preparing or publishing an NGINX UI release, including version bumping with version.sh, release notes, Avira pre-publication checks, tags, GitHub Releases, and optional post-release publication to the RainYun cloud app store.\n---\n\n# NGINX UI Release\n\nUse this workflow for NGINX UI releases from the repository root.\n\n## Preconditions\n\n- Work from the `dev` branch.\n- Inspect `git status --short --branch` before changing files.\n- If the user asks to commit existing workspace changes first, inspect recent commit style and commit that work separately before release prep.\n- Keep staging explicit. Do not include unrelated local changes.\n- Treat `release-notes-vX.Y.Z.md` as a temporary local release artifact, not a committed file.\n\n## Version Preparation\n\n1. Run `./version.sh` outside the sandbox when possible. It updates `app/package.json`, runs the frontend build, and refreshes generated artifacts that can require network access.\n2. Enter the release version as `vX.Y.Z` when prompted and confirm it.\n3. Check the generated diff with `git status --short` and `git diff --stat`.\n4. Commit only version-preparation artifacts with:\n\n```bash\ngit add <version-prep-files>\ngit commit -m \"chore: prepare vX.Y.Z\"\n```\n\nDo not commit `release-notes-vX.Y.Z.md`.\n\n## Release Notes\n\nCreate `release-notes-vX.Y.Z.md` in the repository root using exactly these sections:\n\n```markdown\n## Features\n\n- <User-facing feature summary> by @<contributor> ([<short-hash>](https://github.com/0xJacky/nginx-ui/commit/<full-sha>))\n\n## Bug Fixes\n\n- <User-facing fix summary> by @<contributor> ([<short-hash>](https://github.com/0xJacky/nginx-ui/commit/<full-sha>))\n\n## Contributors\n\n@handle\n```\n\nGuidelines:\n\n- Base the notes on the verified range from the previous release tag to `HEAD`.\n- Every actual change bullet must include both the verified contributor's `@handle` and a linked short commit hash, even when a PR link is also included. The `Contributors` section does not replace per-change attribution.\n- Resolve handles from the merged PR author and verified co-authors, or the GitHub-linked commit author for direct commits. Do not automatically credit the merger or committer, and never infer a handle from a display name or email. Resolve missing attribution before finalizing the notes; if it cannot be verified, ask the user for the handle or an explicit attribution exception.\n- Use a commit that implements the summarized change and belongs to the verified release range. For squash merges, use the resulting squash commit; for rebased or cherry-picked changes, use the commit shipped in this repository. Never use the release-prep commit as a substitute.\n- Display a unique abbreviated SHA, starting at 8 characters and extending it if ambiguous, and link it to the full commit SHA on GitHub.\n- Write concise summaries of notable user-facing outcomes rather than copying the raw commit log. Group commits only when they describe one coherent change; retain all relevant contributor handles and the linked hashes needed to substantiate the summary. Split unrelated changes into separate bullets.\n- List verified release contributors once each in `Contributors`, including everyone credited inline.\n- If a change section is empty, use `- None.`; this sentinel needs no contributor or hash.\n- Do not include test status unless the user explicitly asks for it.\n\nBefore finalizing, check every change bullet for accurate attribution, a resolving commit link, and membership in the release range. Reuse the same reviewed notes for the tag annotation and GitHub Release body.\n\nReferences: [Keep a Changelog](https://keepachangelog.com/en/1.1.0/) for curated, grouped summaries and [GitHub release notes](https://docs.github.com/en/repositories/releasing-projects-on-github/automatically-generated-release-notes) for contributor credit and change traceability. Per-change handles and short hashes are this project's required format.\n\n## Validation\n\n- `./version.sh` already runs the frontend build and Go generation.\n- By default, run lightweight checks such as `git diff --check`.\n- Run broader tests only when appropriate for the release scope or when the user requests them. If the user says to skip tests, do not keep trying to run them.\n- If local tests are affected by a parent Go workspace, use repo-isolated mode such as `GOWORK=off` and a writable `GOCACHE`.\n\n## Avira Pre-Publication Gate\n\nComplete this gate after the release-prep commit and before creating or pushing the release tag or publishing the GitHub Release:\n\n1. Record the exact release-candidate commit from `git rev-parse HEAD`.\n2. After explicit publication authorization, push only `dev` so the `Build` workflow can produce the Windows amd64 artifact from that exact commit. Do not push the release tag yet.\n3. Wait for the `Build` workflow for the candidate commit to succeed. Download its Windows amd64 artifact and verify that it contains the expected `nginx-ui.exe`.\n4. Record the executable SHA-256. Archive only `nginx-ui.exe` in a password-protected ZIP under Avira's 50 MB limit using password `infected`.\n5. Immediately before transmitting the archive and contact details, obtain the required external-submission confirmation. Submit the sample to Avira VirusLab as `Suspected False Positive (Not Malware)` with the planned version, candidate commit, executable hash, source URL, and release URL.\n6. Stop until Avira explicitly reports `Clean`. A pending result or detection leaves the release tag and GitHub Release unpublished.\n7. Recheck that `HEAD` and `origin/dev` still resolve to the scanned candidate commit. Any commit change invalidates the result and requires a new artifact and scan.\n\nThe pre-publication artifact is content-level evidence, not guaranteed byte-for-byte proof of the final GitHub Release asset because the build embeds `settings.buildTime`. After publication, record the exact published Windows ZIP and extracted EXE SHA-256 values. If WinGet flags the final executable, submit that exact EXE to Avira before requesting an ESRP rerun.\n\n## Tag, Push, And Publish\n\nOnly after the Avira pre-publication result is `Clean` and the candidate commit is unchanged:\n\n```bash\ngit -c tag.gpgSign=false tag -a vX.Y.Z -F release-notes-vX.Y.Z.md\ngit push origin vX.Y.Z\ngh release create vX.Y.Z --verify-tag --title vX.Y.Z -F release-notes-vX.Y.Z.md --discussion-category Announcements\n```\n\nNotes:\n\n- Use `git -c tag.gpgSign=false tag -a ...` when local GPG signing blocks tag creation.\n- The GitHub Release command is expected to create the matching Announcements discussion.\n- Verify publication with `gh release view vX.Y.Z` and, if needed, inspect recent Discussions in the `Announcements` category.\n- Download the final `nginx-ui-windows-64.zip`, record its SHA-256, extract `nginx-ui.exe`, and record the executable SHA-256.\n- After a successful release, leave the release-note markdown untracked unless the user asks to delete it.\n\n## RainYun Cloud App Publication\n\nRainYun is a downstream distribution phase. Start it only after the GitHub Release is final, the required release workflows have completed, and the versioned Docker image is available for the target RainYun architecture. Do not make RainYun a prerequisite for publishing the GitHub Release.\n\nWhen the release request includes RainYun or store publication, read and follow [references/rainyun.md](references/rainyun.md). Its template contract, deployment proof, external-action boundaries, billing confirmation, CAPTCHA handoff, store-state readback, and README promotion requirements are release gates for this phase.\n\nA generic GitHub release authorization does not by itself authorize RainYun template changes, a potentially billed test deployment, or application submission. Obtain the required RainYun scope before external mutations and obtain action-time confirmation immediately before the final install/deploy control.\n","frontmatter":{"name":"release","description":"Use when preparing or publishing an NGINX UI release, including version bumping with version.sh, release notes, Avira pre-publication checks, tags, GitHub Releases, and optional post-release publication to the RainYun cloud app store."},"isInternal":false,"tokens":1691,"sizeBytes":7927},{"name":"backend.mdc","path":".cursor/rules/backend.mdc","rawUrl":"https://raw.githubusercontent.com/0xJacky/nginx-ui/HEAD/.cursor/rules/backend.mdc","title":"Cursor Rule: backend","category":"cursor-rule","format":"mdc","content":"---\ndescription: \nglobs: **/**/*.go\nalwaysApply: false\n---\n# Cursor Rules\nYou are an expert in Go, Gin, Gorm, Gen, Cosy (https://cosy.uozi.org/) with a deep understanding of best practices and performance optimization techniques in these technologies.\n\n## 1. Code Style and Structure\n\n- **Concise and Maintainable Code:**  \n  Write technically accurate and easily understandable Go code with relevant examples.\n\n- **API Controllers:**  \n  Implement API controllers in the `api/$modules_name` directory.\n\n- **Database Models:**  \n  Define database table models in the `model/` folder.\n\n- **Query Simplification:**  \n  Use [Gen](mdc:https:/cosy.uozi.org) to streamline query operations, reducing boilerplate code.\n\n- **Business Logic and Error Handling:**  \n  Place complex API logic and custom error definitions in `internal/$modules_name`. Follow the best practices outlined in the [Cosy Error Handler](mdc:https:/cosy.uozi.org/error-handler).\n\n- **Routing:**  \n  Register all application routes in the `router/` directory.\n\n- **Configuration Management:**  \n  Manage and register configuration settings in the `settings/` directory.\n\n## 2. CRUD Operations\n\n- **Standardized Operations:**  \n  Utilize [Cosy](mdc:https:/cosy.uozi.org) to implement Create, Read, Update, and Delete (CRUD) operations consistently across the project.\n\n## 3. Performance Optimization\n\n- **Efficient Database Pagination:**  \n  Implement database pagination techniques to handle large datasets efficiently.\n\n- **Overall Performance:**  \n  Apply performance optimization techniques to ensure fast response times and resource efficiency.\n\n## 4. File Organization and Formatting\n\n- **Modular Files:**  \n  Keep individual files concise by splitting code based on functionality, promoting better readability and maintainability.\n\n- **Consistent Syntax and Formatting:**  \n  Follow consistent coding standards and formatting rules across the project to enhance clarity.\n\n## 5. Documentation and Comments\n\n- **English Language:**  \n  All code comments and documentation should be written in English to maintain consistency and accessibility.","isInternal":false,"tokens":447,"sizeBytes":2111},{"name":"frontend.mdc","path":".cursor/rules/frontend.mdc","rawUrl":"https://raw.githubusercontent.com/0xJacky/nginx-ui/HEAD/.cursor/rules/frontend.mdc","title":"Cursor Rule: frontend","category":"cursor-rule","format":"mdc","content":"---\ndescription: \nglobs: app/**/*.tsx,app/**/*.vue,app/**/*.ts,app/**/*.js,app/**/*.json\nalwaysApply: false\n---\nYou are an expert in TypeScript, Node.js, Vite, Vue.js, Vue Router, Pinia, VueUse, Ant Design Vue, and UnoCSS, with a deep understanding of best practices and performance optimization techniques in these technologies.\n\nPackage manager: Bun\n- bun run typecheck\n  \n    Code Style and Structure\n    - Write concise, maintainable, and technically accurate TypeScript code with relevant examples.\n    - Use functional and declarative programming patterns; avoid classes.\n    - Favor iteration and modularization to adhere to DRY principles and avoid code duplication.\n    - Use descriptive variable names with auxiliary verbs (e.g., isLoading, hasError).\n    - Organize files systematically: each file should contain only related content, such as exported components, subcomponents, helpers, static content, and types.\n    - Define API and types in app/src/api\n  \n    Naming Conventions\n    - In src/components, the name should be CamelCase (e.g., app/src/components/ChatGPT/ChatGPT.vue)\n    - In src/views, the folder name should be lower case with underline, but the component name should be CamelCase (e.g., app/src/views/system/About.vue)\n    - Favor named exports for functions.\n  \n    TypeScript Usage\n    - Use TypeScript for all code; prefer interfaces over types for their extendability and ability to merge.\n  \n    Syntax and Formatting\n    - Use the \"function\" keyword for pure functions to benefit from hoisting and clarity.\n    - Always use the Vue Composition API script setup style.\n    - Use Vue3.4+ features like defineModel(), useTemplateRef(), v-bind Same-name Shorthand\n  \n    UI and Styling\n    - Use Ant Design Vue, UnoCSS for components and styling.\n    - Implement responsive design with UnoCSS and Antdv Flex layout; use a mobile-first approach.\n  \n    Performance Optimization\n    - Leverage VueUse functions where applicable to enhance reactivity and performance.\n    - Wrap asynchronous components in Suspense with a fallback UI.\n    - Use dynamic loading for non-critical components.\n    - Optimize images: use WebP format, include size data, implement lazy loading.\n    - Implement an optimized chunking strategy during the Vite build process, such as code splitting, to generate smaller bundle sizes.\n  \n    Key Conventions\n    - Optimize Web Vitals (LCP, CLS, FID) using tools like Lighthouse or WebPageTest.\n\n    Comments\n    - Always response in English\n","frontmatter":{"description":null,"globs":"app/**/*.tsx,app/**/*.vue,app/**/*.ts,app/**/*.js,app/**/*.json","alwaysApply":false},"isInternal":false,"tokens":579,"sizeBytes":2559},{"name":"CLAUDE.md","path":"CLAUDE.md","rawUrl":"https://raw.githubusercontent.com/0xJacky/nginx-ui/HEAD/CLAUDE.md","title":"Claude Agent Guidelines & System Prompt","category":"claude-rule","format":"markdown","content":"# NGINX UI - Claude Code Guidelines\n\nThis project is a web-based NGINX management interface built with Go backend and Vue.js frontend.\n\n## Package Manager\n- **Use Bun exclusively** for all frontend package management operations\n- Commands: `bun install`, `bun run dev`, `bun run typecheck`\n\n## Backend (Go) Development\n\n### Technologies & Frameworks\n- **Go** with Gin web framework\n- **GORM** for database operations  \n- **Gen** for query simplification\n- **Cosy** framework (https://cosy.uozi.org/)\n\n### Code Organization\n- **API Controllers**: Implement in `api/$module_name/` directory\n- **Database Models**: Define in `model/` folder\n- **Business Logic**: Place complex logic and error handling in `internal/$module_name/`\n- **Routing**: Register routes in `router/` directory\n- **Configuration**: Manage settings in `settings/` directory\n\n### Development Guidelines\n- Write concise, maintainable Go code with clear examples\n- Run `gofmt`/`goimports` before committing backend changes\n- Use Gen to streamline database queries and reduce boilerplate\n- Follow Cosy Error Handler best practices for error management\n- Implement standardized CRUD operations using Cosy framework\n- Apply efficient database pagination for large datasets\n- Before committing backend changes, run the CI-equivalent unit test command: `GOWORK=off go test -tags=unembed -race -cover -count=1 ./...`\n- Keep `-count=1` in pre-commit unit tests so cached results cannot hide race conditions or flaky failures\n- Keep files modular and well-organized by functionality\n- **All comments and documentation must be in English**\n\n## Frontend (Vue.js) Development\n\n### Technology Stack\n- **TypeScript** for all code\n- **Vue 3** with Composition API\n- **Vite** build tool\n- **Vue Router** for routing\n- **Pinia** for state management\n- **VueUse** for utilities\n- **antdv-next** for UI components (migrated from `ant-design-vue@4`; the icon package is `@antdv-next/icons`)\n- **UnoCSS** for styling\n\n### Code Standards\n- Use functional and declarative programming patterns (avoid classes)\n- Prefer interfaces over types for better extendability\n- Use descriptive variable names with auxiliary verbs (e.g., `isLoading`, `hasError`)\n- Always use Vue Composition API with `<script setup>` syntax\n- Leverage Vue 3.4+ features: `defineModel()`, `useTemplateRef()`, v-bind shorthand\n\n### File Organization\n- **Components**: Use CamelCase naming in `src/components/` (e.g., `ChatGPT/ChatGPT.vue`)\n- **Views**: Use lowercase with underscores for folders, CamelCase for components (e.g., `src/views/system/About.vue`)\n- **API & Types**: Define in `app/src/api/`\n- **Exports**: Favor named exports for functions\n\n### UI & Styling\n- Use antdv-next components and UnoCSS for styling\n- Always check dark mode when adding or changing styles\n- Prefer a component's semantic `classes` / `styles` props over `:deep(.ant-*)` overrides; antdv-next owns its internal DOM and changes it between versions\n- Implement responsive design with mobile-first approach\n- Use antdv-next Flex layout for responsive layouts\n\n### Performance Optimization\n- Leverage VueUse functions for enhanced reactivity\n- Wrap async components in Suspense with fallback UI\n- Use dynamic loading for non-critical components\n- Optimize images: WebP format, size data, lazy loading\n- Implement code splitting and chunking strategy in Vite build\n- Optimize Web Vitals (LCP, CLS, FID)\n\n### Code Quality\n- **Always use ESLint MCP after generating frontend code** to ensure code quality and consistency\n- Run `bun run lint`, `bun run lint:fix`, and `bun run typecheck` to keep style and typings aligned\n\n## Development Commands\n- **Frontend**: `bun run dev`, `bun run lint`, `bun run typecheck`, `bun run build`\n- **Backend**: `go generate ./...`, `go build ./...`, run `GOWORK=off go test -tags=unembed -race -cover -count=1 ./...`; for release artifacts reuse the README command with `-tags=jsoniter -ldflags \"$LD_FLAGS ...\"`.\n- **Demo stack**: `docker-compose -f docker-compose-demo.yml up` to bootstrap the sample environment\n\n\n## Release Workflow\n- Start releases from the `dev` branch with a clean working tree.\n- Run `./version.sh` outside the sandbox to update the version, rebuild the frontend, and refresh generated artifacts that require network access.\n- Prepare release notes in a temporary local markdown file such as `release-notes-vX.Y.Z.md`.\n- Follow the existing three-section release note style: `Features`, `Bug Fixes`, and `Contributors`.\n- Write contributor names using GitHub handles when they are known from the merged PR, not raw git author names.\n- Do not commit the release note markdown file. Keep it untracked and use it directly for the tag annotation and GitHub Release body.\n- Commit only the version-preparation artifacts with `chore: prepare vX.Y.Z`.\n- Create an annotated tag from the release note file. If local GPG signing blocks tag creation in the sandbox, create the tag outside the sandbox with `git -c tag.gpgSign=false tag -a vX.Y.Z -F release-notes-vX.Y.Z.md`.\n- Push both `dev` and the release tag with `git push origin dev vX.Y.Z`.\n- Publish the release with `gh release create vX.Y.Z --verify-tag --title vX.Y.Z -F release-notes-vX.Y.Z.md --discussion-category Announcements`.\n- The release flow is expected to create the GitHub Release and the linked Discussion post, then GitHub Actions handles binary, Docker, Homebrew, WinGet, and branch-sync automation.\n\n## Language Requirements\n- **All code comments, documentation, and communication must be in English**\n- Maintain consistency and accessibility across the codebase\n- 优先使用 context7 mcp 搜索文档\n- 生成 find 命令的时候应该排除掉 ./.go/ 这个文件夹，因为那里面是 devcontainer 的依赖\n","isInternal":false,"tokens":1366,"sizeBytes":5734},{"name":"mcp.json","path":".cursor/mcp.json","rawUrl":"https://raw.githubusercontent.com/0xJacky/nginx-ui/HEAD/.cursor/mcp.json","title":"Model Context Protocol (MCP) Configuration","category":"mcp-config","format":"json","content":"{\n\t\"mcpServers\": {\n\t\t\"eslint\": {\n\t\t\t\"command\": \"npx\",\n\t\t\t\"args\": [\"@eslint/mcp@latest\"],\n\t\t\t\"env\": {}\n\t\t},\n\t\t\"context7\": {\n      \"command\": \"npx\",\n      \"args\": [\"-y\", \"@upstash/context7-mcp\"]\n    }\n\t}\n}","frontmatter":{"mcpServers":{"eslint":{"command":"npx","args":["@eslint/mcp@latest"],"env":{}},"context7":{"command":"npx","args":["-y","@upstash/context7-mcp"]}}},"isInternal":false,"tokens":80,"sizeBytes":203}],"systemPromptSnippet":"<yakaai_skills repo=\"0xJacky/nginx-ui\">\n<!-- File: .claude/skills/release/SKILL.md (Tokens: ~1691 | Category: anthropic-skill) -->\n---\nname: release\ndescription: Use when preparing or publishing an NGINX UI release, including version bumping with version.sh, release notes, Avira pre-publication checks, tags, GitHub Releases, and optional post-release publication to the RainYun cloud app store.\n---\n\n# NGINX UI Release\n\nUse this workflow for NGINX UI releases from the repository root.\n\n## Preconditions\n\n- Work from the `dev` branch.\n- Inspect `git status --short --branch` before changing files.\n- If the user asks to commit existing workspace changes first, inspect recent commit style and commit that work separately before release prep.\n- Keep staging explicit. Do not include unrelated local changes.\n- Treat `release-notes-vX.Y.Z.md` as a temporary local release artifact, not a committed file.\n\n## Version Preparation\n\n1. Run `./version.sh` outside the sandbox when possible. It updates `app/package.json`, runs the frontend build, and refreshes generated artifacts that can require network access.\n2. Enter the release version as `vX.Y.Z` when prompted and confirm it.\n3. Check the generated diff with `git status --short` and `git diff --stat`.\n4. Commit only version-preparation artifacts with:\n\n```bash\ngit add <version-prep-files>\ngit commit -m \"chore: prepare vX.Y.Z\"\n```\n\nDo not commit `release-notes-vX.Y.Z.md`.\n\n## Release Notes\n\nCreate `release-notes-vX.Y.Z.md` in the repository root using exactly these sections:\n\n```markdown\n## Features\n\n- <User-facing feature summary> by @<contributor> ([<short-hash>](https://github.com/0xJacky/nginx-ui/commit/<full-sha>))\n\n## Bug Fixes\n\n- <User-facing fix summary> by @<contributor> ([<short-hash>](https://github.com/0xJacky/nginx-ui/commit/<full-sha>))\n\n## Contributors\n\n@handle\n```\n\nGuidelines:\n\n- Base the notes on the verified range from the previous release tag to `HEAD`.\n- Every actual change bullet must include both the verified contributor's `@handle` and a linked short commit hash, even when a PR link is also included. The `Contributors` section does not replace per-change attribution.\n- Resolve handles from the merged PR author and verified co-authors, or the GitHub-linked commit author for direct commits. Do not automatically credit the merger or committer, and never infer a handle from a display name or email. Resolve missing attribution before finalizing the notes; if it cannot be verified, ask the user for the handle or an explicit attribution exception.\n- Use a commit that implements the summarized change and belongs to the verified release range. For squash merges, use the resulting squash commit; for rebased or cherry-picked changes, use the commit shipped in this repository. Never use the release-prep commit as a substitute.\n- Display a unique abbreviated SHA, starting at 8 characters and extending it if ambiguous, and link it to the full commit SHA on GitHub.\n- Write concise summaries of notable user-facing outcomes rather than copying the raw commit log. Group commits only when they describe one coherent change; retain all relevant contributor handles and the linked hashes needed to substantiate the summary. Split unrelated changes into separate bullets.\n- List verified release contributors once each in `Contributors`, including everyone credited inline.\n- If a change section is empty, use `- None.`; this sentinel needs no contributor or hash.\n- Do not include test status unless the user explicitly asks for it.\n\nBefore finalizing, check every change bullet for accurate attribution, a resolving commit link, and membership in the release range. Reuse the same reviewed notes for the tag annotation and GitHub Release body.\n\nReferences: [Keep a Changelog](https://keepachangelog.com/en/1.1.0/) for curated, grouped summaries and [GitHub release notes](https://docs.github.com/en/repositories/releasing-projects-on-github/automatically-generated-release-notes) for contributor credit and change traceability. Per-change handles and short hashes are this project's required format.\n\n## Validation\n\n- `./version.sh` already runs the frontend build and Go generation.\n- By default, run lightweight checks such as `git diff --check`.\n- Run broader tests only when appropriate for the release scope or when the user requests them. If the user says to skip tests, do not keep trying to run them.\n- If local tests are affected by a parent Go workspace, use repo-isolated mode such as `GOWORK=off` and a writable `GOCACHE`.\n\n## Avira Pre-Publication Gate\n\nComplete this gate after the release-prep commit and before creating or pushing the release tag or publishing the GitHub Release:\n\n1. Record the exact release-candidate commit from `git rev-parse HEAD`.\n2. After explicit publication authorization, push only `dev` so the `Build` workflow can produce the Windows amd64 artifact from that exact commit. Do not push the release tag yet.\n3. Wait for the `Build` workflow for the candidate commit to succeed. Download its Windows amd64 artifact and verify that it contains the expected `nginx-ui.exe`.\n4. Record the executable SHA-256. Archive only `nginx-ui.exe` in a password-protected ZIP under Avira's 50 MB limit using password `infected`.\n5. Immediately before transmitting the archive and contact details, obtain the required external-submission confirmation. Submit the sample to Avira VirusLab as `Suspected False Positive (Not Malware)` with the planned version, candidate commit, executable hash, source URL, and release URL.\n6. Stop until Avira explicitly reports `Clean`. A pending result or detection leaves the release tag and GitHub Release unpublished.\n7. Recheck that `HEAD` and `origin/dev` still resolve to the scanned candidate commit. Any commit change invalidates the result and requires a new artifact and scan.\n\nThe pre-publication artifact is content-level evidence, not guaranteed byte-for-byte proof of the final GitHub Release asset because the build embeds `settings.buildTime`. After publication, record the exact published Windows ZIP and extracted EXE SHA-256 values. If WinGet flags the final executable, submit that exact EXE to Avira before requesting an ESRP rerun.\n\n## Tag, Push, And Publish\n\nOnly after the Avira pre-publication result is `Clean` and the candidate commit is unchanged:\n\n```bash\ngit -c tag.gpgSign=false tag -a vX.Y.Z -F release-notes-vX.Y.Z.md\ngit push origin vX.Y.Z\ngh release create vX.Y.Z --verify-tag --title vX.Y.Z -F release-notes-vX.Y.Z.md --discussion-category Announcements\n```\n\nNotes:\n\n- Use `git -c tag.gpgSign=false tag -a ...` when local GPG signing blocks tag creation.\n- The GitHub Release command is expected to create the matching Announcements discussion.\n- Verify publication with `gh release view vX.Y.Z` and, if needed, inspect recent Discussions in the `Announcements` category.\n- Download the final `nginx-ui-windows-64.zip`, record its SHA-256, extract `nginx-ui.exe`, and record the executable SHA-256.\n- After a successful release, leave the release-note markdown untracked unless the user asks to delete it.\n\n## RainYun Cloud App Publication\n\nRainYun is a downstream distribution phase. Start it only after the GitHub Release is final, the required release workflows have completed, and the versioned Docker image is available for the target RainYun architecture. Do not make RainYun a prerequisite for publishing the GitHub Release.\n\nWhen the release request includes RainYun or store publication, read and follow [references/rainyun.md](references/rainyun.md). Its template contract, deployment proof, external-action boundaries, billing confirmation, CAPTCHA handoff, store-state readback, and README promotion requirements are release gates for this phase.\n\nA generic GitHub release authorization does not by itself authorize RainYun template changes, a potentially billed test deployment, or application submission. Obtain the required RainYun scope before external mutations and obtain action-time confirmation immediately before the final install/deploy control.\n\n<!-- File: .cursor/rules/backend.mdc (Tokens: ~447 | Category: cursor-rule) -->\n---\ndescription: \nglobs: **/**/*.go\nalwaysApply: false\n---\n# Cursor Rules\nYou are an expert in Go, Gin, Gorm, Gen, Cosy (https://cosy.uozi.org/) with a deep understanding of best practices and performance optimization techniques in these technologies.\n\n## 1. Code Style and Structure\n\n- **Concise and Maintainable Code:**  \n  Write technically accurate and easily understandable Go code with relevant examples.\n\n- **API Controllers:**  \n  Implement API controllers in the `api/$modules_name` directory.\n\n- **Database Models:**  \n  Define database table models in the `model/` folder.\n\n- **Query Simplification:**  \n  Use [Gen](mdc:https:/cosy.uozi.org) to streamline query operations, reducing boilerplate code.\n\n- **Business Logic and Error Handling:**  \n  Place complex API logic and custom error definitions in `internal/$modules_name`. Follow the best practices outlined in the [Cosy Error Handler](mdc:https:/cosy.uozi.org/error-handler).\n\n- **Routing:**  \n  Register all application routes in the `router/` directory.\n\n- **Configuration Management:**  \n  Manage and register configuration settings in the `settings/` directory.\n\n## 2. CRUD Operations\n\n- **Standardized Operations:**  \n  Utilize [Cosy](mdc:https:/cosy.uozi.org) to implement Create, Read, Update, and Delete (CRUD) operations consistently across the project.\n\n## 3. Performance Optimization\n\n- **Efficient Database Pagination:**  \n  Implement database pagination techniques to handle large datasets efficiently.\n\n- **Overall Performance:**  \n  Apply performance optimization techniques to ensure fast response times and resource efficiency.\n\n## 4. File Organization and Formatting\n\n- **Modular Files:**  \n  Keep individual files concise by splitting code based on functionality, promoting better readability and maintainability.\n\n- **Consistent Syntax and Formatting:**  \n  Follow consistent coding standards and formatting rules across the project to enhance clarity.\n\n## 5. Documentation and Comments\n\n- **English Language:**  \n  All code comments and documentation should be written in English to maintain consistency and accessibility.\n\n<!-- File: .cursor/rules/frontend.mdc (Tokens: ~579 | Category: cursor-rule) -->\n---\ndescription: \nglobs: app/**/*.tsx,app/**/*.vue,app/**/*.ts,app/**/*.js,app/**/*.json\nalwaysApply: false\n---\nYou are an expert in TypeScript, Node.js, Vite, Vue.js, Vue Router, Pinia, VueUse, Ant Design Vue, and UnoCSS, with a deep understanding of best practices and performance optimization techniques in these technologies.\n\nPackage manager: Bun\n- bun run typecheck\n  \n    Code Style and Structure\n    - Write concise, maintainable, and technically accurate TypeScript code with relevant examples.\n    - Use functional and declarative programming patterns; avoid classes.\n    - Favor iteration and modularization to adhere to DRY principles and avoid code duplication.\n    - Use descriptive variable names with auxiliary verbs (e.g., isLoading, hasError).\n    - Organize files systematically: each file should contain only related content, such as exported components, subcomponents, helpers, static content, and types.\n    - Define API and types in app/src/api\n  \n    Naming Conventions\n    - In src/components, the name should be CamelCase (e.g., app/src/components/ChatGPT/ChatGPT.vue)\n    - In src/views, the folder name should be lower case with underline, but the component name should be CamelCase (e.g., app/src/views/system/About.vue)\n    - Favor named exports for functions.\n  \n    TypeScript Usage\n    - Use TypeScript for all code; prefer interfaces over types for their extendability and ability to merge.\n  \n    Syntax and Formatting\n    - Use the \"function\" keyword for pure functions to benefit from hoisting and clarity.\n    - Always use the Vue Composition API script setup style.\n    - Use Vue3.4+ features like defineModel(), useTemplateRef(), v-bind Same-name Shorthand\n  \n    UI and Styling\n    - Use Ant Design Vue, UnoCSS for components and styling.\n    - Implement responsive design with UnoCSS and Antdv Flex layout; use a mobile-first approach.\n  \n    Performance Optimization\n    - Leverage VueUse functions where applicable to enhance reactivity and performance.\n    - Wrap asynchronous components in Suspense with a fallback UI.\n    - Use dynamic loading for non-critical components.\n    - Optimize images: use WebP format, include size data, implement lazy loading.\n    - Implement an optimized chunking strategy during the Vite build process, such as code splitting, to generate smaller bundle sizes.\n  \n    Key Conventions\n    - Optimize Web Vitals (LCP, CLS, FID) using tools like Lighthouse or WebPageTest.\n\n    Comments\n    - Always response in English\n\n<!-- File: CLAUDE.md (Tokens: ~1366 | Category: claude-rule) -->\n# NGINX UI - Claude Code Guidelines\n\nThis project is a web-based NGINX management interface built with Go backend and Vue.js frontend.\n\n## Package Manager\n- **Use Bun exclusively** for all frontend package management operations\n- Commands: `bun install`, `bun run dev`, `bun run typecheck`\n\n## Backend (Go) Development\n\n### Technologies & Frameworks\n- **Go** with Gin web framework\n- **GORM** for database operations  \n- **Gen** for query simplification\n- **Cosy** framework (https://cosy.uozi.org/)\n\n### Code Organization\n- **API Controllers**: Implement in `api/$module_name/` directory\n- **Database Models**: Define in `model/` folder\n- **Business Logic**: Place complex logic and error handling in `internal/$module_name/`\n- **Routing**: Register routes in `router/` directory\n- **Configuration**: Manage settings in `settings/` directory\n\n### Development Guidelines\n- Write concise, maintainable Go code with clear examples\n- Run `gofmt`/`goimports` before committing backend changes\n- Use Gen to streamline database queries and reduce boilerplate\n- Follow Cosy Error Handler best practices for error management\n- Implement standardized CRUD operations using Cosy framework\n- Apply efficient database pagination for large datasets\n- Before committing backend changes, run the CI-equivalent unit test command: `GOWORK=off go test -tags=unembed -race -cover -count=1 ./...`\n- Keep `-count=1` in pre-commit unit tests so cached results cannot hide race conditions or flaky failures\n- Keep files modular and well-organized by functionality\n- **All comments and documentation must be in English**\n\n## Frontend (Vue.js) Development\n\n### Technology Stack\n- **TypeScript** for all code\n- **Vue 3** with Composition API\n- **Vite** build tool\n- **Vue Router** for routing\n- **Pinia** for state management\n- **VueUse** for utilities\n- **antdv-next** for UI components (migrated from `ant-design-vue@4`; the icon package is `@antdv-next/icons`)\n- **UnoCSS** for styling\n\n### Code Standards\n- Use functional and declarative programming patterns (avoid classes)\n- Prefer interfaces over types for better extendability\n- Use descriptive variable names with auxiliary verbs (e.g., `isLoading`, `hasError`)\n- Always use Vue Composition API with `<script setup>` syntax\n- Leverage Vue 3.4+ features: `defineModel()`, `useTemplateRef()`, v-bind shorthand\n\n### File Organization\n- **Components**: Use CamelCase naming in `src/components/` (e.g., `ChatGPT/ChatGPT.vue`)\n- **Views**: Use lowercase with underscores for folders, CamelCase for components (e.g., `src/views/system/About.vue`)\n- **API & Types**: Define in `app/src/api/`\n- **Exports**: Favor named exports for functions\n\n### UI & Styling\n- Use antdv-next components and UnoCSS for styling\n- Always check dark mode when adding or changing styles\n- Prefer a component's semantic `classes` / `styles` props over `:deep(.ant-*)` overrides; antdv-next owns its internal DOM and changes it between versions\n- Implement responsive design with mobile-first approach\n- Use antdv-next Flex layout for responsive layouts\n\n### Performance Optimization\n- Leverage VueUse functions for enhanced reactivity\n- Wrap async components in Suspense with fallback UI\n- Use dynamic loading for non-critical components\n- Optimize images: WebP format, size data, lazy loading\n- Implement code splitting and chunking strategy in Vite build\n- Optimize Web Vitals (LCP, CLS, FID)\n\n### Code Quality\n- **Always use ESLint MCP after generating frontend code** to ensure code quality and consistency\n- Run `bun run lint`, `bun run lint:fix`, and `bun run typecheck` to keep style and typings aligned\n\n## Development Commands\n- **Frontend**: `bun run dev`, `bun run lint`, `bun run typecheck`, `bun run build`\n- **Backend**: `go generate ./...`, `go build ./...`, run `GOWORK=off go test -tags=unembed -race -cover -count=1 ./...`; for release artifacts reuse the README command with `-tags=jsoniter -ldflags \"$LD_FLAGS ...\"`.\n- **Demo stack**: `docker-compose -f docker-compose-demo.yml up` to bootstrap the sample environment\n\n\n## Release Workflow\n- Start releases from the `dev` branch with a clean working tree.\n- Run `./version.sh` outside the sandbox to update the version, rebuild the frontend, and refresh generated artifacts that require network access.\n- Prepare release notes in a temporary local markdown file such as `release-notes-vX.Y.Z.md`.\n- Follow the existing three-section release note style: `Features`, `Bug Fixes`, and `Contributors`.\n- Write contributor names using GitHub handles when they are known from the merged PR, not raw git author names.\n- Do not commit the release note markdown file. Keep it untracked and use it directly for the tag annotation and GitHub Release body.\n- Commit only the version-preparation artifacts with `chore: prepare vX.Y.Z`.\n- Create an annotated tag from the release note file. If local GPG signing blocks tag creation in the sandbox, create the tag outside the sandbox with `git -c tag.gpgSign=false tag -a vX.Y.Z -F release-notes-vX.Y.Z.md`.\n- Push both `dev` and the release tag with `git push origin dev vX.Y.Z`.\n- Publish the release with `gh release create vX.Y.Z --verify-tag --title vX.Y.Z -F release-notes-vX.Y.Z.md --discussion-category Announcements`.\n- The release flow is expected to create the GitHub Release and the linked Discussion post, then GitHub Actions handles binary, Docker, Homebrew, WinGet, and branch-sync automation.\n\n## Language Requirements\n- **All code comments, documentation, and communication must be in English**\n- Maintain consistency and accessibility across the codebase\n- 优先使用 context7 mcp 搜索文档\n- 生成 find 命令的时候应该排除掉 ./.go/ 这个文件夹，因为那里面是 devcontainer 的依赖\n\n<!-- File: .cursor/mcp.json (Tokens: ~80 | Category: mcp-config) -->\n{\n\t\"mcpServers\": {\n\t\t\"eslint\": {\n\t\t\t\"command\": \"npx\",\n\t\t\t\"args\": [\"@eslint/mcp@latest\"],\n\t\t\t\"env\": {}\n\t\t},\n\t\t\"context7\": {\n      \"command\": \"npx\",\n      \"args\": [\"-y\", \"@upstash/context7-mcp\"]\n    }\n\t}\n}\n</yakaai_skills>"}