@icebreakers/monorepo-templates 1.2.1 → 1.3.0

package/templates/vitepress/why/examples/2.npm-basic-package/README.md

@@ -1 +1 @@
-https://repo.icebreaker.top/
+https://repoctl.icebreaker.top/

package/templates/vitepress/why/examples/3.npm-basic-package/README.md

@@ -1 +1 @@
-https://repo.icebreaker.top/
+https://repoctl.icebreaker.top/

package/templates/vitepress/why/how-to-reuse-js-code.md

@@ -1,9 +1,39 @@
-# Reusing JavaScript Code
+# Reusing JavaScript
 
-JavaScript code can be shared through source modules, workspace packages, or published npm packages. The right boundary depends on ownership and consumers.
+Reuse source code through an explicit package boundary. Copying files between applications is fast once and expensive every time the shared behavior changes; a local workspace package makes ownership, versioning, and tests visible.
 
-- Use a local module for code owned by one package.
-- Use a workspace package when multiple projects in the same repository share versioned behavior.
-- Publish an npm package when external repositories need a stable public API.
+## Start with a workspace package
 
-In a pnpm workspace, declare internal dependencies with the `workspace:` protocol and let the package build produce explicit runtime and type entrypoints.
+```json
+{
+  "dependencies": {
+    "@example/shared": "workspace:*"
+  }
+}
+```
+
+The workspace protocol uses the local package during development and protects the repository from accidentally resolving an unrelated registry version.
+
+## Export a narrow API
+
+```ts
+export function normalizeName(value: string) {
+  return value.trim().toLowerCase()
+}
+```
+
+Keep the public entry point small. A shared package should expose behavior that has a real consumer, not a collection of unrelated helpers that happen to be nearby.
+
+## Choose the right reuse level
+
+| Need                         | Better boundary                        |
+| ---------------------------- | -------------------------------------- |
+| Shared runtime behavior      | A versioned package                    |
+| Shared build and lint policy | A preset package or managed asset      |
+| Shared application feature   | A feature package with clear ownership |
+| One-off project setup        | A template, not a dependency           |
+
+## Keep Reading
+
+- [What Is An npm Package?](./what-is-npm-package.md)
+- [Template Systems](../monorepo/templates.md)

package/templates/vitepress/why/js-cjs-mjs.md

@@ -1,12 +1,34 @@
-# JavaScript Module Extensions
+# JavaScript, CommonJS, and ESM Files
 
-Node.js uses file extensions and the nearest `package.json` `type` field to determine module format.
+File extensions tell Node which module loader should read a file. Use them deliberately when a package publishes both module formats or when a script must work independently of the nearest `package.json`.
 
-| Extension       | Meaning                                       |
-| --------------- | --------------------------------------------- |
-| `.mjs`          | Always ES module                              |
-| `.cjs`          | Always CommonJS                               |
-| `.js`           | Depends on `package.json` `type`              |
-| `.mts` / `.cts` | TypeScript source with explicit module intent |
+## Extension rules
 
-For published libraries, make the package `exports` map explicit and test both import and require paths when both formats are supported.
+| Extension | Module format                                         |
+| --------- | ----------------------------------------------------- |
+| `.mjs`    | ESM in every package                                  |
+| `.cjs`    | CommonJS in every package                             |
+| `.js`     | Determined by the nearest `package.json` `type` field |
+
+```json
+{
+  "type": "module"
+}
+```
+
+With this declaration, `.js` files are ESM. Use `.cjs` for CommonJS output such as a compatibility build or an older tooling configuration file.
+
+## Avoid ambiguous output
+
+```text
+dist/index.js     ESM output
+dist/index.cjs    CommonJS output
+dist/index.d.ts   Type declarations
+```
+
+Connect these files through `exports`; do not ask consumers to infer a `dist` layout. A clear output layout also makes package tarball checks easier.
+
+## Keep Reading
+
+- [ESM vs CommonJS](./modern/esm-vs-cjs.md)
+- [Package Entry Points](./modern/package-entry-points.md)

package/templates/vitepress/why/js-keywords.md

@@ -1,7 +1,36 @@
-# ESM and CommonJS Runtime Globals
+# JavaScript Runtime Keywords
 
-CommonJS provides `require`, `module`, `exports`, `__filename`, and `__dirname`. ES modules use `import`, `export`, `import.meta.url`, and `createRequire` when interoperability is required.
+Modern JavaScript modules have different runtime globals depending on whether Node loads them as CommonJS or ESM. Know the boundary before copying code between build tools, scripts, and package entry points.
 
-Avoid assuming CommonJS globals exist inside ESM. Resolve file paths with `fileURLToPath(import.meta.url)` and prefer static imports so bundlers and type checkers can understand dependencies.
+## CommonJS values
 
-See [ESM vs CommonJS](./modern/esm-vs-cjs.md) for package-level guidance.
+```js
+console.log(__filename)
+console.log(__dirname)
+console.log(require.main)
+```
+
+These values are available in CommonJS modules. They are not automatically present in ESM files.
+
+## ESM equivalents
+
+```js
+import path from 'node:path'
+import { fileURLToPath } from 'node:url'
+
+const filename = fileURLToPath(import.meta.url)
+const dirname = path.dirname(filename)
+```
+
+Use `import.meta.url` as the starting point for resolving files relative to an ESM module. Prefer explicit Node built-in imports such as `node:path` so bundlers and readers can identify runtime-only dependencies.
+
+## Keep code portable
+
+- Keep filesystem access behind a small module when browser builds share source code.
+- Do not use CommonJS globals in a package that declares `type: module`.
+- Test generated ESM and CommonJS outputs independently when both are published.
+
+## Keep Reading
+
+- [JavaScript, CommonJS, and ESM Files](./js-cjs-mjs.md)
+- [Reusing JavaScript](./how-to-reuse-js-code.md)

package/templates/vitepress/why/modern/bundlers.md

@@ -1,5 +1,40 @@
 # Bundlers
 
-Library bundlers turn source modules into publishable runtime and declaration artifacts. The repository's TypeScript library asset uses [tsdown](https://github.com/sonofmagic/repoctl/tree/main/templates/tsdown), while the Vue library asset adds Vue-specific build and type checking.
+Choose a bundler by the package boundary you need to ship. A library build needs reliable entry points and declarations; a component library also needs framework and CSS handling; an application build needs an optimized browser bundle.
 
-Configure entrypoints, external dependencies, output formats, source maps, and declarations according to the package contract. Applications and libraries have different goals: application builds optimize deployment; library builds preserve reusable public boundaries.
+## Current choices
+
+| Tool       | Good fit                                        | Notes                                             |
+| ---------- | ----------------------------------------------- | ------------------------------------------------- |
+| `tsdown`   | TypeScript libraries and tooling                | Produces modern library output with declarations  |
+| `vite`     | Applications and component libraries            | Strong development server and library mode        |
+| `rolldown` | Toolchains that need Rollup-compatible behavior | Evaluate ecosystem compatibility before migration |
+
+The repoctl generic library template uses `tsdown`. Vue component libraries continue to use Vite library mode.
+
+## tsdown library configuration
+
+:::code-group
+
+```ts [tsdown.config.ts]
+import { defineConfig } from 'tsdown'
+
+export default defineConfig({
+  entry: ['./src/index.ts'],
+  format: ['cjs', 'esm'],
+  dts: true,
+  clean: true,
+  target: 'node18',
+})
+```
+
+:::
+
+## Retired defaults
+
+`tsup` and `unbuild` are not recommended for new repoctl templates. Existing projects can migrate when their build behavior and published artifacts are covered by tests. Do not rewrite a working package merely to follow a tooling trend.
+
+## Keep Reading
+
+- [TypeScript](./typescript.md)
+- [Package Entry Points](./package-entry-points.md)

package/templates/vitepress/why/modern/dts.md

@@ -1,7 +1,48 @@
 # Type Declarations
 
-Type declarations are part of a TypeScript package's public API.
+Type declarations describe the public TypeScript contract of a JavaScript package. They must be generated from the same source and exported through the same public entry points as the runtime code.
 
-Generate `.d.ts` files from the same source revision as runtime output, point `types` and export conditions at files included in the tarball, and use `tsd` tests for important inference and error behavior.
+## Emit declarations
 
-Declaration bundling can simplify public output, but it must preserve module augmentation, generics, and referenced types. Always inspect the packed artifact rather than testing source imports alone.
+```json
+{
+  "compilerOptions": {
+    "declaration": true,
+    "declarationMap": true,
+    "emitDeclarationOnly": false,
+    "outDir": "./dist"
+  }
+}
+```
+
+Bundlers such as tsdown can emit declaration files alongside runtime output. The important rule is that declaration paths are stable and match the package exports map.
+
+## Link types to exports
+
+```json
+{
+  "exports": {
+    ".": {
+      "types": "./dist/index.d.ts",
+      "import": "./dist/index.js",
+      "require": "./dist/index.cjs"
+    }
+  }
+}
+```
+
+The top-level `types` field is useful for simple packages. Per-entry `types` declarations are necessary when a package exposes subpaths or format-specific output.
+
+## Test the public contract
+
+```bash
+pnpm tsd
+pnpm pack --dry-run
+```
+
+Type tests should import from the package name, not a source file. That proves the declarations consumers receive are compatible with the documented API.
+
+## Keep Reading
+
+- [Package Entry Points](./package-entry-points.md)
+- [TypeScript](./typescript.md)

package/templates/vitepress/why/modern/esm-vs-cjs.md

@@ -1,7 +1,42 @@
 # ESM vs CommonJS
 
-ES modules are the preferred format for new packages. CommonJS remains relevant when consumers or toolchains still require `require()`.
+Node supports two JavaScript module systems. ESM uses `import` and `export`; CommonJS uses `require` and `module.exports`. A package can support both, but it must state how each consumer reaches the correct file.
 
-Choose ESM-only when your supported runtime matrix allows it. Publish dual formats only when the compatibility benefit justifies duplicate builds and interop testing.
+## Identify the format
 
-For dual packages, map `import`, `require`, and `types` conditions explicitly and test each consumer path. Avoid exporting different logical module instances from the two formats.
+| Signal                          | Meaning             |
+| ------------------------------- | ------------------- |
+| `.mjs`                          | Always ESM          |
+| `.cjs`                          | Always CommonJS     |
+| `.js` with `"type": "module"`   | ESM                 |
+| `.js` without that package type | CommonJS by default |
+
+Avoid guessing from syntax alone. Node resolves a `.js` file from its extension and the nearest package boundary.
+
+## Publish both formats
+
+```json
+{
+  "type": "module",
+  "exports": {
+    ".": {
+      "import": "./dist/index.js",
+      "require": "./dist/index.cjs"
+    }
+  }
+}
+```
+
+Use an exports map rather than asking consumers to reach into `dist`. It gives each module system an intentional entry point and prevents accidental private imports becoming a public API.
+
+## Interoperability rules
+
+- Keep the package API identical across formats where possible.
+- Test both `import` and `require` from a consumer fixture.
+- Do not publish TypeScript source as the runtime entry point.
+- Use `.cjs` for CommonJS output when the package itself declares `type: module`.
+
+## Keep Reading
+
+- [Package Entry Points](./package-entry-points.md)
+- [Type Declarations](./dts.md)

package/templates/vitepress/why/modern/index.md

@@ -1,14 +1,38 @@
 # Modern Package Guide
 
-Modern packages should expose a small, explicit API and generate artifacts that match their declared contract.
+A publishable package is more than a source folder. Consumers depend on its runtime format, type declarations, entry points, files list, and compatibility policy. This guide explains the decisions that keep those contracts explicit.
 
-## Checklist
+## Start with the consumer
 
-- Choose ESM-only or intentional dual-package support.
-- Declare every public subpath in `exports`.
-- Emit and test type declarations.
-- Keep development-only files out of the package tarball.
-- Validate the supported Node and bundler matrix.
-- Record public changes through repository versioning.
+Before choosing a bundler or module format, answer these questions:
 
-Start with [ESM vs CommonJS](./esm-vs-cjs.md), then review [entry points](./package-entry-points.md) and [declarations](./dts.md).
+- Will consumers load the package through ESM, CommonJS, or both?
+- Does the package ship runtime code, types, a CLI, or generated assets?
+- Which Node versions must work?
+- Should consumers import one public entry point or several intentional subpaths?
+
+The answers define the package boundary. Tooling should implement that boundary, not invent it.
+
+## Recommended shape
+
+```text
+src/          source code
+dist/         generated ESM, CommonJS, and declaration files
+package.json  public metadata and exports map
+README.md     installation and usage contract
+```
+
+Use `files` to publish only the built output and deliberately included documentation. Run `npm pack --dry-run` before publishing to inspect the actual package tarball.
+
+## Topics
+
+- [ESM vs CommonJS](./esm-vs-cjs.md)
+- [Type Declarations](./dts.md)
+- [Package Entry Points](./package-entry-points.md)
+- [Bundlers](./bundlers.md)
+- [TypeScript](./typescript.md)
+
+## Keep Reading
+
+- [What Is An npm Package?](../what-is-npm-package.md)
+- [Publishing A Package](../publish-basic-npm-package.md)

package/templates/vitepress/why/modern/package-entry-points.md

@@ -1,17 +1,46 @@
 # Package Entry Points
 
-Use the `exports` field to define the package's supported public paths.
+The `exports` field is the public map of a package. It selects files for ESM, CommonJS, types, and intentional subpath imports while preventing consumers from coupling to internal folders.
+
+## Define one primary entry
 
 ```json
 {
+  "name": "example-package",
   "exports": {
     ".": {
       "types": "./dist/index.d.ts",
-      "import": "./dist/index.js"
-    },
+      "import": "./dist/index.js",
+      "require": "./dist/index.cjs"
+    }
+  }
+}
+```
+
+Consumers can now use `import { feature } from 'example-package'` or `require('example-package')` without knowing your output layout.
+
+## Add a deliberate subpath
+
+```json
+{
+  "exports": {
+    ".": "./dist/index.js",
+    "./cli": "./dist/cli.js",
     "./package.json": "./package.json"
   }
 }
 ```
 
-Do not rely on consumers reaching into undeclared internal files. Every exported path should have runtime output, types where applicable, and a compatibility test.
+Each subpath is a public promise. Add one only when it has a stable purpose, documentation, and tests. Do not expose `./dist/*` as a shortcut around API design.
+
+## Verify consumers
+
+- Test the root import and every documented subpath.
+- Verify both ESM and CommonJS branches when both are published.
+- Check `npm pack --dry-run` includes every exported file.
+- Treat removing or changing a public subpath as a breaking change.
+
+## Keep Reading
+
+- [ESM vs CommonJS](./esm-vs-cjs.md)
+- [Type Declarations](./dts.md)

package/templates/vitepress/why/modern/typescript.md

@@ -1,7 +1,43 @@
-# TypeScript Packages
+# TypeScript
 
-Use TypeScript to validate source and to publish a precise consumer contract.
+TypeScript gives a package one source language for implementation and public types. Build output should remain JavaScript plus declarations so consumers do not need your development compiler configuration.
 
-Keep the source typecheck separate from artifact generation, enable strict settings appropriate for libraries, and avoid path aliases that cannot be resolved by consumers. Vue packages should run `vue-tsc`; non-Vue TypeScript packages should run `tsc`.
+## Start with a strict package config
 
-Public type behavior belongs in `tsd` tests. Runtime tests should import built output so module resolution matches delivery.
+```jsonc
+{
+  "compilerOptions": {
+    "target": "ES2020",
+    "module": "ESNext",
+    "moduleResolution": "bundler",
+    "strict": true,
+    "declaration": true,
+    "declarationMap": true,
+    "outDir": "./dist",
+    "skipLibCheck": true
+  },
+  "include": ["src"]
+}
+```
+
+Use a separate configuration only when an output format genuinely needs different compiler behavior. Prefer a bundler configuration for output strategy and keep the TypeScript configuration focused on source checking and declaration generation.
+
+## Build and test from artifacts
+
+```bash
+pnpm build
+pnpm typecheck
+pnpm tsd
+```
+
+Run type tests against the generated package contract. A source-only test can pass while the published declaration path or exports map is broken.
+
+## Runtime execution
+
+For local scripts, `tsx` can run TypeScript without creating a development `dist` directory. That is convenient for tooling, but it is not a replacement for building libraries before testing the package that consumers install.
+
+## Keep Reading
+
+- [Type Declarations](./dts.md)
+- [Bundlers](./bundlers.md)
+- [Publishing A Package](../publish-basic-npm-package.md)

package/templates/vitepress/why/publish-basic-npm-package.md

@@ -1,19 +1,43 @@
-# Publishing An npm Package
+# Publishing A Package
 
-1. Define explicit runtime and type entrypoints.
-2. Build the package and run tests against built artifacts.
-3. Inspect `pnpm pack` output.
-4. Record a change intent and verify the version plan.
-5. Publish with provenance and the intended access level.
+Publishing is the point where the repository's package contract becomes public. Build first, test the built artifacts, inspect the tarball, and publish only after the version intent and changelog describe the consumer-visible change.
+
+## Prepare the package
+
+```bash
+pnpm --filter example-package build
+pnpm --filter example-package typecheck
+pnpm --filter example-package test
+pnpm --filter example-package tsd
+pnpm --filter example-package pack --pack-destination ../../artifacts
+```
+
+Run the package commands against generated output where possible. A source-only test does not prove that `exports`, files, or declarations will resolve after installation.
+
+## Verify package metadata
+
+```json
+{
+  "name": "example-package",
+  "version": "1.0.0",
+  "files": ["dist", "README.md", "LICENSE"],
+  "publishConfig": { "access": "public" }
+}
+```
+
+Use `npm pack --dry-run` to see what users receive. Confirm the runtime entry point, declaration files, README, and license are present.
+
+## Release through the repository workflow
 
 ```bash
-pnpm build
-pnpm lint
-pnpm typecheck
-pnpm tsd
-pnpm test
-pnpm pack
 pnpm change
+pnpm version -r
+pnpm publish -r
 ```
 
-Never publish template source workspaces that are intentionally marked `private: true`.
+The version ledger preserves why the release exists. Do not manually edit a package version to bypass fixed-group or changelog rules.
+
+## Keep Reading
+
+- [pnpm Versioning](../tools/changeset.md)
+- [Modern Package Guide](./modern/)

package/templates/vitepress/why/what-is-npm-package.md

@@ -1,7 +1,36 @@
 # What Is An npm Package?
 
-An npm package is a directory described by `package.json`. It can expose runtime code, types, command-line bins, assets, or configuration.
+An npm package is a versioned archive with a `package.json` contract. It may provide runtime JavaScript, type declarations, a command-line binary, configuration presets, or assets. Publishing a folder is easy; maintaining that contract is the real work.
 
-The public contract includes the package name, version, `exports`, `types`, `bin`, supported runtimes, files included in the tarball, and semantic versioning behavior. Treat these fields as API design, not publishing metadata afterthoughts.
+## The package boundary
 
-Use `pnpm pack` to inspect the exact artifact before publishing.
+```text
+package.json  name, version, exports, files, engines
+README.md     install and supported usage
+dist/         built runtime and type declarations
+LICENSE       license terms for consumers
+```
+
+Only files named by `files`, exports, and package metadata should be treated as public. Internal source layout is free to change until it appears in the published contract.
+
+## Inspect what ships
+
+```bash
+npm pack --dry-run
+pnpm pack --pack-destination ./artifacts
+```
+
+Review the archive after every material packaging change. This catches missing declarations, accidental source publication, and files referenced by `exports` that were not included.
+
+## Version with intent
+
+- Patch: compatible fix or metadata correction.
+- Minor: compatible capability, such as a new public command or template.
+- Major: incompatible API, behavior, or supported runtime change.
+
+Repository versioning tools record that decision, but they cannot determine whether a consumer will be broken. Write the release note from the consumer's point of view.
+
+## Keep Reading
+
+- [Publishing A Package](./publish-basic-npm-package.md)
+- [Modern Package Guide](./modern/)

package/templates/vitepress/wrangler.jsonc

@@ -1,5 +1,22 @@
 {
-  "$schema": "https://unpkg.com/wrangler/config-schema.json",
-  "name": "monorepo-template",
-  "pages_build_output_dir": ".vitepress/dist"
+  "$schema": "./node_modules/wrangler/config-schema.json",
+  "name": "repoctl-docs",
+  "compatibility_date": "2026-08-16",
+  "compatibility_flags": ["nodejs_compat"],
+  "workers_dev": false,
+  "preview_urls": true,
+  "assets": {
+    "directory": ".vitepress/dist",
+    "not_found_handling": "404-page"
+  },
+  "routes": [
+    {
+      "pattern": "repoctl.icebreaker.top",
+      "custom_domain": true
+    }
+  ],
+  "observability": {
+    "enabled": true,
+    "head_sampling_rate": 1
+  }
 }

package/templates/vitepress/zh/ai/index.md

@@ -16,7 +16,7 @@ AI 文档入口用于给 Cursor、Claude Code、Codex 和其他 AI 编程工具
 
 ## 2. 在 AI 工具里怎么用
 
-优先把 `https://repo.icebreaker.top/llms.txt` 作为入口提供给 AI 工具。只有当工具不能继续抓取链接，或者你需要离线提供完整上下文时，再使用 `https://repo.icebreaker.top/llms-full.txt`。
+优先把 `https://repoctl.icebreaker.top/llms.txt` 作为入口提供给 AI 工具。只有当工具不能继续抓取链接，或者你需要离线提供完整上下文时，再使用 `https://repoctl.icebreaker.top/llms-full.txt`。
 
 ```txt
 先给 llms.txt

package/templates/vitepress/zh/ai/llms-txt.md

@@ -16,7 +16,7 @@ description: 使用 llms.txt 为大语言模型提供更易读取的 repoctl 文
 
 ## 1. 使用方式
 
-访问 `https://repo.icebreaker.top/llms.txt` 可以获取当前文档的 LLM 索引。如果需要一次性提供完整上下文，可以使用 `https://repo.icebreaker.top/llms-full.txt`。
+访问 `https://repoctl.icebreaker.top/llms.txt` 可以获取当前文档的 LLM 索引。如果需要一次性提供完整上下文，可以使用 `https://repoctl.icebreaker.top/llms-full.txt`。
 
 当你在 Cursor、Claude Code、Codex 或其他 AI 编程工具里引用 repoctl 文档时，优先提供 `llms.txt`，再按需要补充具体页面链接。
 

package/templates/vitepress/zh/index.md

@@ -1,66 +1,9 @@
 ---
-layout: home
-
-hero:
-  name: repoctl
-  text: 让 pnpm monorepo 的日常操作更短、更稳
-  tagline: 用一套 CLI 管理初始化、诊断、创建模板、提交前校验和模板资产同步。
-  image:
-    src: /logo.jpg
-    alt: repoctl logo
-  actions:
-    - theme: brand
-      text: 快速开始
-      link: /zh/repoctl/getting-started
-    - theme: alt
-      text: 命令速查
-      link: /zh/repoctl/commands
-    - theme: alt
-      text: AI 文档入口
-      link: /zh/ai/
-
-features:
-  - title: 从已有仓库开始
-    details: 安装 repoctl 后运行 setup 和 doctor，先把 workspace、根脚本、配置冲突和提交链路检查清楚。
-  - title: 用模板创建包和应用
-    details: repo new 支持交互式创建、指定模板、dry-run、JSON 输出和创建计划落盘。
-  - title: 把质量门禁变成日常命令
-    details: repo check 统一预览和执行 lint、typecheck、build、test、tsd 等推荐校验。
-  - title: 给 AI 工具的文档入口
-    details: 构建时自动生成 llms.txt、llms-full.txt 和页面 Markdown，让 AI 编程工具更容易读取 repoctl 文档。
+layout: page
+aside: false
+pageClass: repoctl-home-page
+title: repoctl
+description: 面向 pnpm 与 Turborepo monorepo 的任务型 CLI。
 ---
 
-## 最短路径
-
-```bash
-pnpm add -D repoctl
-pnpm exec repo init
-pnpm exec repo doctor
-pnpm exec repo new
-pnpm exec repo check
-```
-
-在由 repoctl 创建或初始化的仓库里，同一套工作流会暴露成更短的根脚本：
-
-```bash
-pnpm run repo:init
-pnpm run repo:doctor
-pnpm run repo:new
-pnpm run repo:check
-```
-
-## 你可以继续阅读
-
-- [repoctl 概览](./repoctl/index.md)
-- [快速开始](./repoctl/getting-started.md)
-- [接入已有仓库](./repoctl/adopt-existing.md)
-- [按场景选命令](./repoctl/scenarios.md)
-- [执行模型](./repoctl/execution-model.md)
-- [命令速查](./repoctl/commands.md)
-- [校验链路](./repoctl/checks.md)
-- [doctor 诊断](./repoctl/doctor.md)
-- [配置文件](./repoctl/config.md)
-- [模板与创建](./repoctl/templates.md)
-- [模板资产治理](./repoctl/template-assets.md)
-- [工作流与 CI](./repoctl/workflows.md)
-- [报告与自动化输出](./repoctl/reports.md)
+<HomePage locale="zh" />