DesireCore Docs

docs.desirecore.com · DesireCore 官方文档站

---

About

This is the source repository for DesireCore documentation, built with Docusaurus 3.

DesireCore is a Agent OS — a cross-platform desktop app that gives you an AI companion capable of learning, executing, auditing, and rolling back.

Prerequisites

• Node.js >= 20
• pnpm

Getting Started

# Install dependencies
pnpm install

# Start local dev server
pnpm start

The dev server runs at http://localhost:3000 with hot reload.

Build

pnpm build

Static output is generated in the build/ directory.

Deployment

Merging a pull request into main or pushing to main automatically triggers deployment. Publish through Git and wait for the deployment result; no manual Vercel deployment command is needed.

Project Structure

docs/
├── docs/              # Markdown source (Chinese, default)
├── i18n/en/           # English translations
├── src/
│   ├── css/           # Custom styles (Liquid Glass design system)
│   └── theme/         # Theme overrides
├── static/img/        # Images & favicon
└── docusaurus.config.ts

Internationalization

The site supports Chinese (default) and English. To start the dev server in English:

pnpm start -- --locale en

To generate translation files:

pnpm write-translations -- --locale en

Contributing

Contributions are welcome! To contribute:

1. Fork this repository
2. Create a feature branch (git checkout -b feat/my-change)
3. Commit your changes (git commit -m 'feat: add something')
4. Push to the branch (git push origin feat/my-change)
5. Open a Pull Request

Please follow Conventional Commits for commit messages.

Feature effective versions（生效版本）

Follow the same convention as AGENTS.md when writing or revising effective-version notes:

• Normalize existing client-version constraints, including vague wording such as “newer versions” or “clients containing this change.” Add a note to new content only when its feature requires an explicit effective version. Do not force version requirements onto pages that never mentioned them or propagate requirements through related features or links.
• Use a Docusaurus info callout titled 生效版本 in Chinese or Effective version in English. Write the version as inline code in the form vX.Y.Z+; + includes the named version and all later versions.
• Keep a documented introduction version. When the effective version is uncertain, use v10.0.178+. Do not replace a known version with the default; standing instructions retain v10.0.179+.
• Place the callout near the beginning of the relevant page or section and name the affected feature. A constraint on one feature must not imply that every feature on the page requires that version. Keep the callout separate from prose paragraphs and other callouts.
• When both locales already state a constraint for the same feature, their version and feature scope must agree. Do not add a constraint to a translation that had none merely to match formatting.
• State the client version the user needs directly. Omit internal caveats such as “implemented on the development branch,” “availability depends on the installed package,” or “confirm that the package includes this capability.” Preserve platform, permission, and provider eligibility conditions that affect use, expressed as requirements users can understand or check. For a feature that is not available, say so directly.
• Release history, unimplemented plans, OS/runtime requirements, agreement revisions, configuration versions, and example content versions retain their own meaning and numbering.

Use the following format, replacing the example version and feature name as appropriate:

:::info 生效版本
`v10.0.178+`（功能名称）。
:::

:::info Effective version
`v10.0.178+` (feature name).
:::

Keep this convention and AGENTS.md consistent when updating either file.

Writing for end users

• Explain what a feature does, where to use it, what it requires, and how to resolve problems.
• Keep development branches, merge status, source configuration snapshots, internal release gates, and component migration plans out of user instructions. Never ask users to check these details.
• Replace implementation-status caveats with an effective version, current support scope, or visible steps. Keep component names and technical details when they help with configuration, troubleshooting, permissions, or licenses.
• Keep advice for documentation authors out of user-facing prose. Apply this approach in both languages while preserving actual limitations and authorization conditions.

License

• Source code, theme customizations, and project configuration in this repository are licensed under the MIT License.
• Documentation text and translations under docs/ and i18n/ are copyright © 2026 Yunnan Solar Corona Technology Co., Ltd. and are not licensed under MIT.
• Subject to the terms set out in LICENSE-docs, the documentation content may be copied, republished, distributed, translated, and publicly displayed, but modified versions and derivative works may not be distributed or created without prior written consent.

---

Website · Docs · Issues