@icebreakers/monorepo-templates 1.3.0 → 1.3.2

package/templates/vitepress/zh/{repoctl/workflows.md → tasks/ci.md}

@@ -1,4 +1,30 @@
-# 工作流与 CI
+# 把校验加入 CI
+
+## 适用场景
+
+当本地命令已经稳定，需要在每个 pull request 或分支上执行同一套仓库策略时，使用这个任务。
+
+## 前置条件
+
+- 已经生成通过检查的 `repo check --dry-run` 计划。
+- CI runner 具备 Node.js、pnpm 和仓库锁文件。
+- 发布或发版 job 使用非交互凭据。
+
+## 最小命令
+
+```bash
+repo check --full --json --out reports/check-plan.json
+```
+
+## 预期输出
+
+CI 会得到稳定的计划，并可以把 JSON 或 Markdown 报告作为 artifact 上传。同一条命令也可以在本地执行。
+
+## 常见分支
+
+- pull request 需要快速门禁：使用 `repo check --staged` 或仓库的 pre-commit 模式。
+- main 分支需要完整门禁：使用 `repo check --full`。
+- 发布 job 需要版本计划：发布前执行 `repo release --dry-run`。
 
 repoctl 的命令可以分成两类：给人用的日常入口，以及给 CI、脚本、编辑器用的可保存输出。
 
@@ -89,13 +115,13 @@ repo ws ls --json --out reports/workspaces.json
 
 ## 推荐流水线拆分
 
-| 阶段 | 命令                                                            | 失败后先看                           |
-| ---- | --------------------------------------------------------------- | ------------------------------------ |
-| 安装 | `pnpm install --frozen-lockfile`                                | lockfile、Node、pnpm 版本            |
-| 诊断 | `repo doctor --strict`                                          | [doctor 诊断](./doctor.md)           |
-| 计划 | `repo check --full --json --out reports/check-plan.json`        | [报告与自动化输出](./reports.md)     |
-| 执行 | `repo check --full`                                             | 失败的 root script 或 workspace 任务 |
-| 留证 | `repo env support --markdown --redact --out reports/support.md` | CI artifact                          |
+| 阶段 | 命令                                                            | 失败后先看                            |
+| ---- | --------------------------------------------------------------- | ------------------------------------- |
+| 安装 | `pnpm install --frozen-lockfile`                                | lockfile、Node、pnpm 版本             |
+| 诊断 | `repo doctor --strict`                                          | [doctor 诊断](/zh/start/diagnose)     |
+| 计划 | `repo check --full --json --out reports/check-plan.json`        | [报告与自动化输出](/zh/tasks/reports) |
+| 执行 | `repo check --full`                                             | 失败的 root script 或 workspace 任务  |
+| 留证 | `repo env support --markdown --redact --out reports/support.md` | CI artifact                           |
 
 早期项目可以把计划和执行合并。成熟项目建议保留 `reports/`，方便失败时复盘实际执行路径。
 
@@ -147,7 +173,7 @@ pnpm --filter @icebreakers/website exec wrangler rollback <VERSION_ID>
 
 ## 下一步
 
-- 查所有参数：[命令速查](./commands.md)
-- 理解校验链路：[校验链路](./checks.md)
-- 生成排障包：[报告与自动化输出](./reports.md)
-- 看短命令：[命令别名](./aliases.md)
+- 查所有参数：[命令速查](/zh/reference/commands)
+- 理解本地校验：[运行校验](/zh/tasks/checks)
+- 生成排障包：[报告与自动化输出](/zh/tasks/reports)
+- 看短命令：[命令别名](/zh/reference/aliases)

package/templates/vitepress/zh/tasks/create-project.md

@@ -0,0 +1,37 @@
+# 创建包或应用
+
+当 workspace 已经准备好，需要创建新的包、应用、服务、CLI 或文档站时，使用这个任务页。
+
+## 前置条件
+
+- 在 workspace 根目录运行过 `repo doctor`。
+- 确认包名和目标目录。
+- 使用 `repo templates` 查看可用模板键。
+
+## 最小命令
+
+```bash
+repo new <name> --template <template>
+```
+
+例如：
+
+```bash
+repo new shared-config --template package
+```
+
+只想查看文件计划时，加入 `--dry-run`，不会写入文件。
+
+## 预期结果
+
+repoctl 会输出选中的模板、目标目录和将要创建的文件。确认后，新项目加入 workspace，包元数据可以直接进入仓库校验。
+
+## 常见分支
+
+- 模板键不存在：先运行 `repo templates`，选择已安装的键。
+- 目标目录已存在：换一个名称，或检查现有项目后再决定是否覆盖。
+- 需要自定义共享文件：先创建项目，再通过[受管模板资产](/zh/reference/template-assets)同步公共文件。
+
+## 下一步
+
+运行[校验](/zh/tasks/checks)，再把新项目加入 [CI 工作流](/zh/tasks/ci)。

package/templates/vitepress/zh/{repoctl/scenarios.md → tasks/index.md}

@@ -1,4 +1,4 @@
-# 按场景选命令
+# 任务索引
 
 如果你不确定该用哪个 repoctl 命令，先从这一页开始。
 
@@ -17,7 +17,7 @@ pnpm exec repo init --yes
 pnpm exec repo doctor
 ```
 
-继续看：[快速开始](./getting-started.md)。
+继续看：[安装并初始化](/zh/start/install)。
 
 ## 我要把 repoctl 接入旧仓库
 
@@ -29,7 +29,7 @@ pnpm exec repo upgrade --no-overwrite
 pnpm exec repo doctor --markdown --redact --out reports/doctor-after.md
 ```
 
-继续看：[接入已有仓库](./adopt-existing.md)。
+继续看：[接入已有 workspace](/zh/tasks/adopt-existing)。
 
 ## 我要创建新包或应用
 
@@ -45,7 +45,7 @@ pnpm exec repo new docs --template vitepress --dry-run
 pnpm run repo:new -- sdk --template tsdown
 ```
 
-继续看：[模板与创建](./templates.md)。
+继续看：[模板与创建](/zh/reference/templates)。
 
 ## 我要提交前自查
 
@@ -62,7 +62,7 @@ pnpm exec repo check --json --out reports/check-plan.json
 pnpm exec repo check --markdown --redact --out reports/check-plan.md
 ```
 
-继续看：[工作流与 CI](./workflows.md)。
+继续看：[把校验加入 CI](/zh/tasks/ci)。
 
 ## 我要调试 CI 或同事机器问题
 
@@ -72,7 +72,7 @@ pnpm exec repo env support --markdown --redact --out reports/support.md
 pnpm exec repo env snapshot --json --out reports/snapshot.json
 ```
 
-继续看：[排障与报告](./troubleshooting.md)。
+继续看：[排障](/zh/tasks/troubleshooting)。
 
 ## 我要同步模板标准资产
 
@@ -105,7 +105,7 @@ pnpm exec repo config inspect
 pnpm exec repo cfg i --json --out reports/config.json
 ```
 
-继续看：[配置文件](./config.md)。
+继续看：[配置文件](/zh/reference/config)。
 
 ## 我要写更短的命令
 
@@ -116,4 +116,4 @@ repo e support --markdown --redact
 repo cfg i
 ```
 
-继续看：[命令别名](./aliases.md)。
+继续看：[命令别名](/zh/reference/aliases)。

package/templates/vitepress/zh/tasks/release.md

@@ -0,0 +1,31 @@
+# 发布包
+
+当改动准备好更新版本并发布时，使用这个任务页。任何写入 registry 的操作都应该先经过可审查的发布计划。
+
+## 前置条件
+
+- `repo doctor` 报告包管理器和发布配置有效。
+- 工作区除本次改动外保持干净。
+- 每个可发布改动都有 changeset 或仓库约定的 intent 文件。
+
+## 最小命令
+
+```bash
+repo release --dry-run
+```
+
+检查包组、版本、变更日志和发布命令。计划确认后，再去掉 `--dry-run` 执行发布。
+
+## 预期结果
+
+发布报告会列出将要变化的包、版本决策和每个子进程。发布成功后，还会执行配置好的 post-publish hooks。
+
+## 常见分支
+
+- 缺少 intent：添加 changeset 后重新生成计划。
+- 固定版本组不一致：先检查包之间的关系，再修改版本。
+- registry 认证失败：刷新本地 token 后重试，不要提交凭据。
+
+## 下一步
+
+阅读[发包与变更日志](/zh/learn/monorepo/publish)，再查看[报告与输出](/zh/tasks/reports)了解 CI 产物。

package/templates/vitepress/zh/{repoctl → tasks}/reports.md

@@ -4,6 +4,31 @@ description: 说明 repoctl 的 JSON、Markdown、out、redact、env info、env
 
 # 报告与自动化输出
 
+## 适用场景
+
+当成员、CI 或支持请求需要一份可保存的诊断或计划记录时，使用这个任务。
+
+## 前置条件
+
+- 选择一个被忽略或会作为 CI artifact 上传的 `reports/` 目录。
+- 分享环境信息前使用 `--redact`。
+
+## 最小命令
+
+```bash
+repo env support --markdown --redact --out reports/support.md
+```
+
+## 预期输出
+
+输出文件包含稳定的标题和命令结果，可以附在 pull request 或 issue 中。
+
+## 常见分支
+
+- 其他工具需要读取结果：使用带 `--json` 的 JSON 输出。
+- 只想查看计划：把 `--dry-run` 和目标格式一起使用。
+- 报告中出现本地路径或 token：加上 `--redact` 重新生成。
+
 repoctl 的报告能力用于把本地上下文变成可保存、可脱敏、可给脚本读取的文件。它适合 CI artifact、issue 模板、编辑器集成和跨机器排障。
 
 ## 1. 通用输出参数

package/templates/vitepress/zh/{repoctl → tasks}/troubleshooting.md

@@ -1,4 +1,30 @@
-# 排障与报告
+# 排障
+
+## 适用场景
+
+初始化、校验、模板或自动化出现意外结果时，使用这个任务。
+
+## 前置条件
+
+- 在仓库根目录执行命令。
+- 保留原始错误和仓库 revision。
+- 分享命令输出前移除敏感值。
+
+## 最小命令
+
+```bash
+repo doctor --markdown --redact --out reports/doctor.md
+```
+
+## 预期输出
+
+报告会指出仓库根目录、包管理器、workspace 配置、工具链和第一个失败的检查。
+
+## 常见分支
+
+- 命令从子目录执行：切换到 workspace 根目录。
+- 配置文件和受管资产冲突：先查看计划，再决定是否覆盖。
+- 模板键不存在：使用 `repo templates` 列出模板。
 
 repoctl 的排障重点不是让你猜错在哪里，而是尽量输出可以复现、可以保存、可以发给同事的报告。
 
@@ -51,13 +77,13 @@ repo env paths --markdown --redact --out reports/paths.md
 
 ## 先判断问题类型
 
-| 现象                           | 优先命令                                  | 继续阅读                             |
-| ------------------------------ | ----------------------------------------- | ------------------------------------ |
-| 不确定当前目录是不是仓库根目录 | `repo doctor`                             | [doctor 诊断](./doctor.md)           |
-| 不知道 `repo check` 会跑什么   | `repo check --dry-run`                    | [校验链路](./checks.md)              |
-| CI 失败但日志不完整            | `repo env support --markdown --redact`    | [报告与自动化输出](./reports.md)     |
-| 模板创建结果不符合预期         | `repo new <name> --template <key> --json` | [模板资产治理](./template-assets.md) |
-| 模板列表或元数据异常           | `repo templates --check`                  | [模板资产治理](./template-assets.md) |
+| 现象                           | 优先命令                                  | 继续阅读                                      |
+| ------------------------------ | ----------------------------------------- | --------------------------------------------- |
+| 不确定当前目录是不是仓库根目录 | `repo doctor`                             | [doctor 诊断](/zh/start/diagnose)             |
+| 不知道 `repo check` 会跑什么   | `repo check --dry-run`                    | [运行校验](/zh/tasks/checks)                  |
+| CI 失败但日志不完整            | `repo env support --markdown --redact`    | [报告与自动化输出](/zh/tasks/reports)         |
+| 模板创建结果不符合预期         | `repo new <name> --template <key> --json` | [模板资产治理](/zh/reference/template-assets) |
+| 模板列表或元数据异常           | `repo templates --check`                  | [模板资产治理](/zh/reference/template-assets) |
 
 ## 常见问题
 
@@ -103,8 +129,8 @@ repo check --json --out reports/check-plan.json
 
 ## 继续阅读
 
-- [工作流与 CI](./workflows.md)
-- [命令速查](./commands.md)
-- [doctor 诊断](./doctor.md)
-- [报告与自动化输出](./reports.md)
-- [命令别名](./aliases.md)
+- [把校验加入 CI](/zh/tasks/ci)
+- [命令速查](/zh/reference/commands)
+- [doctor 诊断](/zh/start/diagnose)
+- [报告与自动化输出](/zh/tasks/reports)
+- [命令别名](/zh/reference/aliases)

package/templates/vue-lib/package.json

@@ -57,12 +57,12 @@
   },
   "devDependencies": {
     "@vitejs/plugin-vue": "^6.0.8",
-    "@vue/test-utils": "^2.4.11",
+    "@vue/test-utils": "^2.5.0",
     "@vue/tsconfig": "^0.9.1",
     "jsdom": "^30.0.1",
-    "vite": "^8.2.1",
-    "vite-plugin-dts": "^5.0.3",
-    "vue": "^3.5.41",
-    "vue-tsc": "^3.3.10"
+    "vite": "^8.2.2",
+    "vite-plugin-dts": "^5.1.0",
+    "vue": "^3.5.42",
+    "vue-tsc": "^3.3.11"
   }
 }

package/templates/vitepress/getting-started.md

@@ -1,11 +0,0 @@
-# Getting Started
-
-The current setup guide is [repoctl Getting Started](./repoctl/getting-started.md).
-
-```bash
-pnpm add -D repoctl
-pnpm exec repo init
-pnpm exec repo doctor
-```
-
-Use [Adopt Existing Repositories](./repoctl/adopt-existing.md) when introducing repoctl to an established workspace.

package/templates/vitepress/knowledge/index.md

@@ -1,26 +0,0 @@
----
-outline: deep
----
-
-# Knowledge Base
-
-This section explains the engineering decisions behind repoctl rather than only listing commands.
-
-## Monorepo Topics
-
-- [Why Monorepo](../monorepo/index.md)
-- [Managing A Monorepo](../monorepo/manage.md)
-- [Publishing and Changelogs](../monorepo/publish.md)
-- [Command Reference](../monorepo/commands.md)
-- [Template Systems](../monorepo/templates.md)
-- [Troubleshooting](../monorepo/troubleshooting.md)
-
-## Modern Package Topics
-
-- [Reusing JavaScript Code](../why/how-to-reuse-js-code.md)
-- [JavaScript Module Extensions](../why/js-cjs-mjs.md)
-- [What Is An npm Package?](../why/what-is-npm-package.md)
-- [Publishing An npm Package](../why/publish-basic-npm-package.md)
-- [Modern Package Guide](../why/modern/index.md)
-
-Start with the repoctl guide when you need an action. Use this knowledge base when you need to understand the tradeoffs behind that action.

package/templates/vitepress/thinking.md

@@ -1,22 +0,0 @@
-# Project Evolution
-
-This repository began as a reusable monorepo template. It has since evolved into repoctl: a task-first CLI for initializing, diagnosing, creating, validating, upgrading, and releasing pnpm and Turborepo monorepos.
-
-Templates remain an important capability, but they are now private source workspaces packaged through `@icebreakers/monorepo-templates`, not the product identity or independent release units.
-
-See the [repoctl overview](./repoctl/index.md) for the current architecture and public entrypoints.
-
-## Documentation Deployment
-
-The documentation is a VitePress static site deployed as a Cloudflare Worker named `repoctl-docs`. Workers Static Assets serves the generated `.vitepress/dist` directory directly, including the custom 404 page and `_redirects` compatibility rules. There is no application Worker handler because the site has no dynamic request path.
-
-Cloudflare Workers Builds uses the repository root and runs these commands:
-
-```bash
-pnpm --filter @icebreakers/website build
-pnpm --filter @icebreakers/website run deploy
-```
-
-Non-production branches upload preview versions with `pnpm --filter @icebreakers/website run deploy:preview`. Before a production change, `pnpm --filter @icebreakers/website run deploy:dry-run` validates the asset manifest and Wrangler configuration. A production rollback uses `wrangler rollback <VERSION_ID>` after reviewing `wrangler versions list`.
-
-The canonical host is `https://repoctl.icebreaker.top`. The legacy `repo.icebreaker.top` and `monorepo.icebreaker.top` hosts are redirect-only entrypoints and preserve the original path and query string.

package/templates/vitepress/zh/getting-started.md

@@ -1,40 +0,0 @@
-# 新手使用指南
-
-这篇旧入口已经收敛到 repoctl 主线。新读者建议直接阅读：
-
-- [repoctl 快速开始](./repoctl/getting-started.md)
-- [repoctl 命令速查](./repoctl/commands.md)
-- [repoctl 配置文件](./repoctl/config.md)
-
-## 先这样用
-
-```bash
-pnpm add -D repoctl
-pnpm exec repo init
-pnpm exec repo doctor
-pnpm exec repo new
-pnpm exec repo check
-```
-
-模板生成仓库里可以使用更短的根脚本：
-
-```bash
-pnpm run repo:init
-pnpm doctor
-pnpm new
-pnpm check
-```
-
-## 知识点保留
-
-理解工具前，先理解这几个边界：
-
-| 命令           | 解决的问题                                            |
-| -------------- | ----------------------------------------------------- |
-| `repo init`    | 补齐仓库默认脚本、workspace patterns 和基础工具链入口 |
-| `repo doctor`  | 判断仓库当前是否可用，并输出可保存的诊断报告          |
-| `repo new`     | 从内置模板创建包、应用、服务、文档站或 CLI            |
-| `repo check`   | 预览或执行提交前推荐校验                              |
-| `repo upgrade` | 同步模板最新标准资产                                  |
-
-如果你是在学习 monorepo 的基础概念，可以继续看 [为什么往 monorepo 方向演进](./monorepo/index.md)。

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

@@ -1,50 +0,0 @@
----
-description: repoctl 文档站的知识库入口，汇总 monorepo 管理、现代 npm 包和 JavaScript 模块化基础。
----
-
-# 知识库
-
-知识库用于解释 repoctl 背后的工程背景。这里不放命令速查，而是回答为什么要这样组织仓库、包、构建和发布流程。
-
-## 1. monorepo 主题
-
-| 页面                                               | 适合解决的问题                     |
-| -------------------------------------------------- | ---------------------------------- |
-| [为什么往 monorepo 方向演进](../monorepo/index.md) | 判断多包仓库是否值得合并管理       |
-| [如何管理 monorepo](../monorepo/manage.md)         | 理解 workspace、任务编排和依赖边界 |
-| [发包与变更日志](../monorepo/publish.md)           | 设计 pnpm intent、版本和发布链路   |
-| [monorepo 命令参考](../monorepo/commands.md)       | 查看通用 monorepo 操作命令         |
-| [monorepo 模板体系](../monorepo/templates.md)      | 理解模板如何减少重复初始化         |
-| [monorepo 排障](../monorepo/troubleshooting.md)    | 排查依赖、构建、类型和发布问题     |
-
-## 2. 现代 npm 包主题
-
-| 页面                                                   | 适合解决的问题                     |
-| ------------------------------------------------------ | ---------------------------------- |
-| [如何复用 js 代码](../why/how-to-reuse-js-code.md)     | 从复制文件演进到发布包             |
-| [什么是 npm 包](../why/what-is-npm-package.md)         | 理解 package.json、入口和安装方式  |
-| [如何发布 npm 包](../why/publish-basic-npm-package.md) | 走通最小 npm 发布流程              |
-| [改进并发布现代 npm 包](../why/index.md)               | 把普通包升级成更规范的现代包       |
-| [现代包指南](../why/modern/index.md)                   | 汇总类型、入口、模块格式和构建工具 |
-
-## 3. 阅读顺序
-
-如果你第一次接触 monorepo，建议按下面顺序阅读：
-
-```txt
-为什么 monorepo
-  -> 如何管理 monorepo
-  -> 什么是 npm 包
-  -> 现代包指南
-  -> 发包与变更日志
-```
-
-如果你已经在维护仓库，可以直接从具体问题进入：
-
-| 你遇到的问题                  | 建议入口                                        |
-| ----------------------------- | ----------------------------------------------- |
-| workspace 包互相引用不清楚    | [如何管理 monorepo](../monorepo/manage.md)      |
-| 不确定 CJS、ESM、types 怎么配 | [现代包指南](../why/modern/index.md)            |
-| 发布后使用方拿不到类型        | [类型声明](../why/modern/dts.md)                |
-| 包入口太多、导入路径混乱      | [包入口](../why/modern/package-entry-points.md) |
-| CI 和发版流程容易漂移         | [发包与变更日志](../monorepo/publish.md)        |

package/templates/vitepress/zh/thinking.md

@@ -1,91 +0,0 @@
-# 我对 monorepo 的一些思考
-
-## 前言
-
-最近在自己的新项目中，我创建并使用了 [monorepo-template](https://github.com/sonofmagic/monorepo-template) 模板，并不断地做了不少改进。
-
-在此，我想借此机会分享一下这个模板的演变过程，以及我对 `monorepo` 的一些思考。
-
-## 它的由来
-
-为了应对越来越多的发包场景，我创建了 [npm-lib-template](https://github.com/sonofmagic/npm-lib-template) 模板
-
-这是一个 `git` 单仓单 `npm` 包模板，使用 `rollup` 进行打包，然后再发布到 `npm` 和 `github`
-
-然而，在后续开发中，我发现单仓库的模式在某些场景下难以应对。
-
-例如，当需要引用其他自己的包，进行单元测试并再次发包时，这时候往往要在多个项目之间进行来回的切换更改，管理复杂度会迅速上升。
-
-`git submodule` 也是另外一条路子，但是我对每次都要同步 `hash` 感到深恶痛绝，遂放弃 (不过某些极其特殊场景的实现，还是只能利用这个功能)。
-
-因此，我决定要创建一个 [monorepo 项目模板](https://github.com/sonofmagic/monorepo-template) ，以应对这些需求。
-
-## 技术选型
-
-### 管理工具
-
-在 `monorepo` 的管理上，我选择了 `pnpm` 和 `turborepo` 这对组合，原因很简单：它们都非常快。
-
-- `pnpm` 又可以节省磁盘空间，又能够链接自特定的内容寻址存储库，是为快也
-- `turborepo` 有构建缓存，是为快也 `too`.
-
-### 语言与打包
-
-我选择使用纯 `TypeScript` 来编写所有类库项目，并统一使用 `tsdown` 进行打包，默认输出格式为 `cjs` 和 `esm`，并利用 `package.json` 中的 `exports` 字段进行分发。
-
-### 直接调试
-
-在直接调试时，我抛弃了 `dist` + `sourcemap` 的调试方式，使用了 `tsx`，它非常适合调试 `TypeScript` 编写的 `CLI` 项目。
-
-### 测试框架
-
-测试方面，我选择了 `vitest`。
-
-它不仅速度快，还很好地支持 `cjs`、`esm` 和 `TypeScript`，同时也适合 `monorepo` 项目。你可以利用 `turbo` 来执行单个的 `vitest` 任务，也可以利用 `vitest.workspace` 来进行多任务测试。
-
-最初我使用的是 `jest` + `ts-jest`，但它对多格式的混合模块的支持不够理想，最终我选择了 `vitest`。
-
-### 代码规范与质量控制
-
-为了保持代码质量，我使用了 `eslint` 和 `stylelint`，并基于自己的配置包 `@icebreakers/eslint-config` 和 `@icebreakers/stylelint-config` 来进行代码格式化和规范化。
-
-我还为 `.vscode` 配置了一些推荐插件和编辑器选项。
-
-此外，通过 `husky` 添加了 `git hook`，配合 `lint-staged` 对提交的代码进行校验。与 `commitlint` 结合使用，以确保 `git` 提交信息符合规范。
-
-### 本地引用与发包替换
-
-利用 `publishConfig` 会在发包的时候替换 `package.json` 字段的方式，在本地包相互引用的时候，都使用 `Typescript` 源文件的方式导出，在 `publishConfig` 里定义的导出为，真正在不同环境中，指向 `dist` 中不同格式的产物地址。
-
-通过这种方式，可以大大加速整个 `monorepo` 的开发测试速度，避免反复通过 `watch` 来构建 `dist` 和 `sourcemap`，也避免一构建出产物，对应的 `Typescript` 文件，就报错的问题。
-
-### 发包流程
-
-现在使用 pnpm 原生 versioning：用 `pnpm change` 记录意图，用 `pnpm version -r` 生成版本和 changelog，再用 `pnpm publish -r` 发布。版本计划保留在 `.changeset/ledger.yaml`，预发布则由 pnpm lanes 管理。
-
-### Github 相关配置
-
-在 `.github` 目录下，我提供了默认的 `CI/CD` 流程配置，以及用户提交 `issue` 时的模板。经过少量配置后，就可以实现自动发布 `npm` 包、创建 `git tag` 以及生成 `GitHub release`。
-
-此外，模板里还有许多为 `GitHub` 显示优化的 `md` 文档。
-
-## 文档部署
-
-文档是一个 VitePress 静态站点，以名为 `repoctl-docs` 的 Cloudflare Worker 发布。Workers Static Assets 直接托管 `.vitepress/dist`，同时处理自定义 404 页面和 `_redirects` 兼容规则。站点没有动态请求逻辑，因此不额外编写 Worker handler，也不声明 `ASSETS` binding。
-
-Cloudflare Workers Builds 从仓库根目录执行：
-
-```bash
-pnpm --filter @icebreakers/website build
-pnpm --filter @icebreakers/website run deploy
-```
-
-非生产分支使用 `pnpm --filter @icebreakers/website run deploy:preview` 上传预览版本。生产发布前运行 `pnpm --filter @icebreakers/website run deploy:dry-run`，校验静态资产清单和 Wrangler 配置。需要回滚时，先用 `wrangler versions list` 确认版本，再执行 `wrangler rollback <VERSION_ID>`。
-
-唯一主域名是 `https://repoctl.icebreaker.top`。`repo.icebreaker.top` 和 `monorepo.icebreaker.top` 只作为兼容入口，由 Cloudflare 301 跳转到主域名，并保留原路径与查询参数。
-
-## 总结
-
-从单仓到 `monorepo` 的转变不仅仅是对工具的选择，更是对项目管理模式的优化。通过采用合适的工具链，能够更高效地管理多包项目的同时，利用 `CI/CD` 确保代码的质量和发布的顺畅。
-
-希望这些思考对你有所帮助，也欢迎大家提出各种建议和意见。