mirrors/pikasTech-HWLAB
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs: specify v02 git write mirror

Browse Source
This commit is contained in:
Codex
2026-05-30 08:04:36 +08:00
parent 046efa9ec1
commit 7012c08948
1 changed files with 35 additions and 21 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/reference/spec-v02-cicd.md
+35 -21
View File
@@ -6,11 +6,13 @@
## 在系统中的职责划分
`v0.2` CI/CD 是 G14 上的加法 lane：source branch、GitOps branch、runtime namespace、artifact catalog、Argo Application、Tekton Pipeline 和 FRP 入口均独立于 DEV/PROD。它共享 G14 k3s、Tekton controller、Argo CD controller、本地 registry 和构建工具，但不能复用 DEV/PROD runtime path、namespace、Application 或公网端口作为 v02 发布证据。code-only fast lane 可以消费独立 `devops-infra` 集群提供的只读 git mirror/cache；该 mirror/cache 是跨项目 DevOps 基础设施，不属于 `hwlab-v02` runtime namespace，也不改变当前 G14 registry 的部署位置或镜像引用真相。
`v0.2` CI/CD 是 G14 上的加法 lane：source branch、GitOps branch、runtime namespace、artifact catalog、Argo Application、Tekton Pipeline 和 FRP 入口均独立于 DEV/PROD。它共享 G14 k3s、Tekton controller、Argo CD controller、本地 registry 和构建工具，但不能复用 DEV/PROD runtime path、namespace、Application 或公网端口作为 v02 发布证据。code-only fast lane 必须消费独立 `devops-infra` 集群提供的 git mirror/relay；该 mirror/relay 是跨项目 DevOps 基础设施，不属于 `hwlab-v02` runtime namespace，也不改变当前 G14 registry 的部署位置或镜像引用真相。
## 内部架构
CI/CD 内部由 UniDesk 手动触发入口、PipelineRun、component planner、BuildKit publish、GitOps promotion、Argo sync 和公网验收构成。`v0.2` 不设置 branch poller、control-plane reconciler 或其他 CronJob；source branch 只保存源码和人写配置；`v0.2-gitops` branch 保存 catalog 和 rendered runtime desired state；live runtime 是最终通过证据。
CI/CD 内部由 UniDesk 手动触发入口、PipelineRun、component planner、BuildKit publish、GitOps promotion、Argo sync、GitHub flush 和公网验收构成。`v0.2` 不设置 branch poller、control-plane reconciler 或其他 CronJob；source branch 只保存源码和人写配置；`v0.2-gitops` branch 保存 catalog 和 rendered runtime desired state；live runtime 是最终通过证据。
`v0.2` 的 GitOps 写路径采用真正写 mirror：promotion 先把 `v0.2-gitops` 写入 `devops-infra` 本地 git mirror/relay，Argo CD 从本地 mirror/relay 读取该 revision 并 rollout，CI 关键路径不等待 GitHub push。GitHub `pikasTech/HWLAB` 仍是长期源码与归档上游，但对 `v0.2-gitops` 来说是由 mirror/relay 负责 flush 的异步上游，不再是 promotion task 的同步写入目标。
## API 接口说明
@@ -18,7 +20,8 @@ CI/CD 内部由 UniDesk 手动触发入口、PipelineRun、component planner、B
| --- | --- |
| `scripts/g14-gitops-render.mjs --lane v02` | v02 GitOps render 入口，负责 namespace、runtime path、catalog 和 endpoint 固定。 |
| Tekton `hwlab-v02-ci-image-publish` | 构建 affected images、复用 unchanged digest，并 promotion 到 `v0.2-gitops`。 |
| Argo `argocd/hwlab-g14-v02` | 从 `v0.2-gitops:deploy/gitops/g14/runtime-v02` 同步到 `hwlab-v02`。 |
| `devops-infra` git mirror/relay | 读写 `v0.2` allowlist refs；CI 读 source/catalog、写 `v0.2-gitops`，并通过手动 CLI flush 到 GitHub。 |
| Argo `argocd/hwlab-g14-v02` | 从 `devops-infra` 本地 mirror/relay 的 `v0.2-gitops:deploy/gitops/g14/runtime-v02` 同步到 `hwlab-v02`。 |
| `http://74.48.78.17:19666/` | v02 Cloud Web 公网入口。 |
| `http://74.48.78.17:19667/health/live` | v02 API/live 公网验收入口。 |
@@ -50,7 +53,7 @@ CI/CD 内部由 UniDesk 手动触发入口、PipelineRun、component planner、B
| FRP Deployment | `hwlab-v02/hwlab-v02-frpc` |
| Web entry | `http://74.48.78.17:19666/` |
| API/live entry | `http://74.48.78.17:19667/health/live` |
| Git mirror/cache | 独立 `devops-infra` 集群只读服务；不设 CronJob，按需由 UniDesk CLI 手动同步 |
| Git mirror/relay | 独立 `devops-infra` 集群读写服务；不设 CronJob；读 source/catalog，写 `v0.2-gitops`，按需由 UniDesk CLI 手动 sync/flush |
| Registry | 维持当前 G14 `hwlab-ci/hwlab-registry` |
`scripts/g14-gitops-render.mjs --lane v02` 是当前 `v0.2` GitOps render 入口。该 lane 必须把默认 source branch 改为 `v0.2`、GitOps branch 改为 `v0.2-gitops`、catalog 改为 `deploy/artifact-catalog.v02.json`、runtime endpoint 改为 `19667`、web endpoint 改为 `19666`，并使用完整 source commit 作为 image tag。
@@ -61,11 +64,12 @@ CI/CD 内部由 UniDesk 手动触发入口、PipelineRun、component planner、B
1. live runtime：`hwlab-v02` namespace 中 Deployment/StatefulSet template、Pod ready、事件、日志和 `19666/19667` 公网 health。
2. Argo desired state：`argocd/hwlab-g14-v02` 的 revision、sync、health、source branch 和 runtime path。
3. GitOps branch：`v0.2-gitops` 中的 `deploy/artifact-catalog.v02.json` 与 `deploy/gitops/g14/runtime-v02/**`。
3. devops-infra mirror/relay 中的 GitOps branch：`v0.2-gitops` 中的 `deploy/artifact-catalog.v02.json` 与 `deploy/gitops/g14/runtime-v02/**`。
4. Tekton 执行证据：UniDesk `trigger-current` 返回的 PipelineRun、TaskRun result、`gitops-promote` 终态。
5. 干净 source workspace：`origin/v0.2`、`deploy/deploy.json`、模板、render 脚本和 `--no-write` 输出。
5. GitHub 上游归档状态：mirror/relay flush 后的 `origin/v0.2-gitops` 与 `origin/v0.2`。
6. 干净 source workspace：`origin/v0.2`、`deploy/deploy.json`、模板、render 脚本和 `--no-write` 输出。
旧 commit 记忆、`G14`/`G14-gitops` DEV/PROD 产物、D601 legacy 路径、source branch 中历史 generated 文件和临时 worktree 只能作为线索，不能作为 `v0.2` 发布通过证据。
旧 commit 记忆、`G14`/`G14-gitops` DEV/PROD 产物、D601 legacy 路径、GitHub 上游尚未 flush 的短暂落后、source branch 中历史 generated 文件和临时 worktree 只能作为线索，不能作为 `v0.2` 发布通过证据。
## Source 与 GitOps 分层
@@ -95,19 +99,22 @@ CI/CD 内部由 UniDesk 手动触发入口、PipelineRun、component planner、B
标准链路如下：
1. UniDesk CLI `hwlab g14 control-plane trigger-current --lane v02 --confirm` 解析当前 `origin/v0.2` 完整 source commit SHA，直接创建 commit-pinned `hwlab-v02-ci-poll-<short12>` PipelineRun；默认 `--dry-run` 只返回将要创建的 manifest。
2. `prepare-source` checkout `v0.2` source，并从 `v0.2-gitops` 读取上一版 `deploy/artifact-catalog.v02.json`。
2. `prepare-source` 通过 `devops-infra` mirror checkout `v0.2` source，并从 mirror 中的 `v0.2-gitops` 读取上一版 `deploy/artifact-catalog.v02.json`。
3. 原语校验 task 只覆盖 repo 报告护栏、GitOps render 合同和必要的代码语法/单元检查；旧 DEV/D601/main gate 不进入 lane。
4. planner 根据 component input 判断 affected/reused services。
5. affected service 通过 BuildKit 发布到 G14 本地 registry；reused service 复用 catalog digest。
6. promotion 刷新 `deploy/artifact-catalog.v02.json`，render `deploy/gitops/g14/runtime-v02/**`，只推送到 `v0.2-gitops`。
7. `hwlab-g14-v02` 从 `v0.2-gitops:deploy/gitops/g14/runtime-v02` 同步到 `hwlab-v02`。
8. 验收只观察 `hwlab-v02` runtime 和 `19666/19667`。
6. promotion 刷新 `deploy/artifact-catalog.v02.json`，render `deploy/gitops/g14/runtime-v02/**`，只推送到 `devops-infra` mirror/relay 的 `v0.2-gitops`。
7. `hwlab-g14-v02` 从本地 mirror/relay 的 `v0.2-gitops:deploy/gitops/g14/runtime-v02` 同步到 `hwlab-v02`。
8. UniDesk CLI 或 mirror/relay flush 操作把本地 `v0.2-gitops` 推送到 GitHub canonical remote；flush 不在 CI runtime-ready 的关键路径内，但必须可查询 pending、lastFlushed 和 failure。
9. 验收只观察 `hwlab-v02` runtime 和 `19666/19667`。
`v0.2` 可以复用 G14 的 registry、proxy、BuildKit、工具镜像和脚本库；不得复用 `hwlab-g14-ci-image-publish`、`hwlab-g14-branch-poller`、`hwlab-g14-control-plane-reconciler`、`G14-gitops` runtime path 或 DEV/PROD Argo Application 作为 `v0.2` 发布入口。
`v0.2` 不设自动轮询发布。历史上若存在 `hwlab-v02-branch-poller`、`hwlab-v02-control-plane-reconciler` 或等价 CronJob，均视为迁移残留，应由 UniDesk control-plane apply 清理；后续发布、重跑、暂停和恢复都通过手动 CLI 触发或停止创建新的 PipelineRun 完成，不新增替代 CronJob。
`devops-infra` git mirror/cache 同样不设周期 CronJob。标准操作是先按需执行 `bun scripts/cli.ts hwlab g14 git-mirror sync --confirm`，再执行 `bun scripts/cli.ts hwlab g14 control-plane trigger-current --lane v02 --confirm`。`git-mirror apply` 只维护 mirror 的 PVC、只读 HTTP 服务、同步脚本和旧 CronJob 清理；`git-mirror sync` 创建一次性 Job，只同步 allowlist refs `v0.2`、`v0.2-gitops`、`G14` 和 `G14-gitops`，先 fetch 到隐藏 staging refs，校验 commit/tree/object closure，再用 `update-ref` 发布到公开 refs。这样 mirror read path 仍是本地磁盘速度，同时避免 CI 看到 ref 已更新但对象还不可 checkout 的半发布窗口。
`devops-infra` git mirror/relay 同样不设周期 CronJob。标准操作是先按需执行 `bun scripts/cli.ts hwlab g14 git-mirror sync --confirm` 把 GitHub allowlist refs 拉入本地 mirror，再执行 `bun scripts/cli.ts hwlab g14 control-plane trigger-current --lane v02 --confirm`。promotion 成功后可执行 `bun scripts/cli.ts hwlab g14 git-mirror flush --confirm` 把本地 `v0.2-gitops` 推送到 GitHub。`git-mirror apply` 维护 mirror 的 PVC、读服务、写服务、同步/flush 脚本和旧 CronJob 清理；`git-mirror sync` 创建一次性 Job，只同步 allowlist refs `v0.2`、`v0.2-gitops`、`G14` 和 `G14-gitops`，先 fetch 到隐藏 staging refs，校验 commit/tree/object closure，再用 `update-ref` 发布到公开 refs。这样 mirror read path 与 GitOps write path 都落在本地磁盘和集群网络，同时避免 CI 看到 ref 已更新但对象还不可 checkout 的半发布窗口。
写 mirror 的一致性模型是 local-first、manual-flush。promotion task 只能持有 mirror/relay 写凭证，不持有 GitHub deploy key；GitHub deploy key 只存在于 `devops-infra` mirror/relay sync/flush 边界。mirror/relay 必须在本地 receive 期间完成 object closure、目标 branch allowlist、non-fast-forward 拒绝和 changed-path 最小校验；receive 成功后本地 ref 即为 Argo 可消费事实。flush 失败不得回滚已经 rollout 的本地 GitOps revision，但必须保留 pending/outbox 状态，下一次手动 flush 可重试并输出 last error，不得静默丢弃。
## Env 容器复用与三变量启动
@@ -127,11 +134,11 @@ CI/CD 必须把三变量同时写入 `deploy/artifact-catalog.v02.json`、render
code-only 变更时，planner 必须输出 `envChanged=false`、`codeChanged=true`，跳过 BuildKit image publish，复用上一版 env image digest，只更新 catalog 和 workload Pod template 中的 `HWLAB_BOOT_COMMIT`、code identity annotation 与相关 health metadata。Kubernetes 原生 Deployment/StatefulSet rolling update 仍由 Pod template hash 变化触发；不需要在容器内长期驻留 watcher，也不把 `git pull` 结果作为运行真相。
`devops-infra` git mirror/cache 是只读、allowlisted、PVC-backed 或等价持久化服务，只缓存 GitHub 对象。只有 mirror controller 持有 GitHub 远端凭证；`hwlab-v02`、AgentRun 和其他业务 namespace 只能访问只读 mirror/cache endpoint，不持有 GitHub deploy key。runtime checkout 失败、mirror miss 超过明确等待窗口、commit ancestry 不满足 lane 约束或 boot script 校验失败时，Pod 必须启动失败或 NotReady，不得回退到 env image 内旧代码，也不得在业务 namespace 直连 GitHub 拉取。
`devops-infra` git mirror/relay 是 allowlisted、PVC-backed 或等价持久化服务，负责缓存 GitHub 对象并承接 `v0.2-gitops` 本地写入。只有 mirror/relay sync/flush 边界持有 GitHub 远端凭证；`hwlab-v02`、AgentRun 和其他业务 namespace 只能访问只读 mirror/cache endpoint，不持有 GitHub deploy key。runtime checkout 失败、mirror miss 超过明确等待窗口、commit ancestry 不满足 lane 约束或 boot script 校验失败时，Pod 必须启动失败或 NotReady，不得回退到 env image 内旧代码，也不得在业务 namespace 直连 GitHub 拉取。
git mirror/cache 接入方式遵循“写 GitHub、读自动加速”。GitOps 和 deploy spec 中的 repo 字段仍记录 canonical GitHub URL；launcher 或只读 runtime image 内的 resolver 负责读路径自动分流。任何需要 push `v0.2-gitops` 的 promotion task 必须继续 push GitHub canonical remote，不能被 mirror rewrite 劫持。
git mirror/relay 接入方式遵循“CI 写本地、GitHub 异步归档、读自动加速”。GitOps 和 deploy spec 中的 repo 字段仍记录 canonical GitHub URL 作为身份字段；launcher 或只读 runtime image 内的 resolver 负责读路径自动分流。需要 push `v0.2-gitops` 的 promotion task 必须 push devops-infra 本地 mirror/relay，不得在 CI 关键路径直接 push GitHub canonical remote。
registry 与 git mirror/cache 分属不同基础设施边界。registry 保持当前 G14 `hwlab-ci/hwlab-registry`，继续通过 repository prefix 服务 HWLAB、AgentRun 和后续 lane；新增 `devops-infra` git mirror/cache 不触发 registry 迁移，也不要求在 `devops-infra` 复制 registry。
registry 与 git mirror/relay 分属不同基础设施边界。registry 保持当前 G14 `hwlab-ci/hwlab-registry`，继续通过 repository prefix 服务 HWLAB、AgentRun 和后续 lane；新增 `devops-infra` git mirror/relay 不触发 registry 迁移，也不要求在 `devops-infra` 复制 registry。
## Artifact 与镜像身份
@@ -145,7 +152,7 @@ registry 与 git mirror/cache 分属不同基础设施边界。registry 保持
- `hwlab-v02` namespace 只能由 `v0.2` GitOps lane 管理。
- `argocd/hwlab-v02` AppProject destination 只能包含 `hwlab-v02`。
- `argocd/hwlab-g14-v02` source 必须指向 `v0.2-gitops:deploy/gitops/g14/runtime-v02`，destination 必须是 `hwlab-v02`。
- `argocd/hwlab-g14-v02` source 必须指向 `devops-infra` 本地 mirror/relay 中的 `v0.2-gitops:deploy/gitops/g14/runtime-v02`，destination 必须是 `hwlab-v02`。
- `hwlab-v02-frpc` 只能暴露 `19666/19667`，不能复用 `17666/17667` 或 `18666/18667`。
- `v0.2` Secret、DB 凭据、PVC、ServiceAccount 和 runtime config 必须独立命名或独立 namespace scope；文档、issue、trace 和 report 只记录 SecretRef 名称与 key，不记录值。
- `v0.2` 初期不新增自动 registry GC；后续如启用清理，selector 必须带 lane/profile 标签，registry digest 保护集必须同时覆盖 `G14-gitops` 与 `v0.2-gitops`。
@@ -166,7 +173,9 @@ registry 与 git mirror/cache 分属不同基础设施边界。registry 保持
- `v0.2` 不得创建或依赖 CronJob；`hwlab-v02-branch-poller`、`hwlab-v02-control-plane-reconciler` 或同类调度器出现时应清理，而不是接入发布链路。
- 旧 DEV/D601/main gate、fallback、legacy mode 和双路径兼容不得进入 `v0.2` 调用链。
- env 容器复用 fast lane 中，`HWLAB_BOOT_REPO`、`HWLAB_BOOT_COMMIT` 和 `HWLAB_BOOT_SH` 必须由 CI/CD 自动推导并写入 GitOps desired state，不得作为人工发布参数或 runtime 临时 patch。
- git mirror/cache 必须来自独立 `devops-infra` 只读服务；`hwlab-v02` runtime namespace 不部署 mirror、不持有 GitHub deploy key、不在 mirror miss 时直连 GitHub fallback。
- git mirror/relay 必须来自独立 `devops-infra` 服务；`hwlab-v02` runtime namespace 不部署 mirror、不持有 GitHub deploy key、不在 mirror miss 时直连 GitHub fallback。
- GitOps promotion 必须写入 `devops-infra` 本地 mirror/relay 的 `v0.2-gitops`；除 mirror/relay flush 外，不得在 CI 关键路径直接 push GitHub canonical remote。
- mirror/relay write 必须只允许 allowlist refs，拒绝 non-fast-forward，拒绝越界 changed paths，并在 receive 成功前完成 object closure 校验。
这些硬边界优先在自然写入点做最小内联断言：render 断言 namespace/runtime path，promotion 断言 GitOps branch/changed paths，Argo spec 断言 destination，验收断言端口和 runtime identity。不要为每条设计约定再新增独立 preflight、guard、gate 或报告生成器。
@@ -190,9 +199,10 @@ registry 与 git mirror/cache 分属不同基础设施边界。registry 保持
- `hwlab-ci` 中存在 `hwlab-v02-ci-image-publish` 和 `hwlab-v02-tekton-runner`；不存在 v02 CronJob。`hwlab-v02-branch-poller` 与 `hwlab-v02-control-plane-reconciler` 不再作为 v02 标准对象，若历史残留应由 UniDesk control-plane apply 清理。
- 最新 `v0.2` source commit 对应的 PipelineRun 完成，且 promotion 写入 `v0.2-gitops`。
- `v0.2-gitops` 中存在 `deploy/artifact-catalog.v02.json` 与 `deploy/gitops/g14/runtime-v02/**`。
- `argocd/hwlab-g14-v02` 指向 `v0.2-gitops:deploy/gitops/g14/runtime-v02`，sync revision 与目标 GitOps revision 对齐。
- `argocd/hwlab-g14-v02` 指向 `devops-infra` 本地 mirror/relay 的 `v0.2-gitops:deploy/gitops/g14/runtime-v02`，sync revision 与目标 GitOps revision 对齐。
- `hwlab-v02` 中长驻 workload ready，没有把 DEV/PROD namespace 当成 `v0.2` 通过证据。
- `gitops-promote` 推送 `v0.2-gitops` 后应触发 `argocd/hwlab-g14-v02` hard refresh，减少 GitOps push 与 Argo 仓库发现之间的漂移窗口；refresh 触发失败只作为低噪声事件输出，最终通过仍由 `runtime-ready` 判定。
- `gitops-promote` 推送本地 mirror/relay 的 `v0.2-gitops` 后应触发 `argocd/hwlab-g14-v02` hard refresh，减少 GitOps push 与 Argo 仓库发现之间的漂移窗口；refresh 触发失败只作为低噪声事件输出，最终通过仍由 `runtime-ready` 判定。
- mirror/relay status 必须能显示本地 `v0.2-gitops` revision、GitHub 已 flush revision、pending flush revision 和最近一次 flush 错误；CI 通过不要求 GitHub flush 已完成，但运维观察必须能看到上游是否落后。
- `runtime-ready` 必须以 workload Pod template 的 source commit 判断 Argo 刷新，并在 Argo 刷新超时、observer RBAC 不足或 workload 未就绪时失败；不得把 CrashLoop、未刷新或公网不可用的 runtime 标成绿色。
- 启用 env 容器复用的服务必须在 catalog、Pod template annotation/env 和 `/health/live` 或等价 runtime identity 中同时暴露 env image digest 与 `HWLAB_BOOT_REPO`/`HWLAB_BOOT_COMMIT`/`HWLAB_BOOT_SH`；只暴露镜像 digest 不能证明 code-only rollout 已生效。
- code-only rollout 的 PipelineRun 必须能证明没有发布新 env image、复用了上一版 env digest、只更新 boot commit/code identity，并由 Kubernetes Pod template hash 触发滚动。
@@ -210,7 +220,7 @@ GitOps branch 已更新、source branch render 通过、PipelineRun 名称存在
## T2
阅读 docs/reference/spec-v02-cicd.md，然后用 cli 手动测试以下内容：查询 Argo `hwlab-g14-v02`，确认 source branch/path 为 `v0.2-gitops:deploy/gitops/g14/runtime-v02`，destination namespace 为 `hwlab-v02`，sync revision 与目标 GitOps revision 对齐。
阅读 docs/reference/spec-v02-cicd.md，然后用 cli 手动测试以下内容：查询 Argo `hwlab-g14-v02`，确认 source repo 为 `devops-infra` 本地 mirror/relay，branch/path 为 `v0.2-gitops:deploy/gitops/g14/runtime-v02`，destination namespace 为 `hwlab-v02`，sync revision 与目标 GitOps revision 对齐。
## T3
@@ -228,6 +238,10 @@ GitOps branch 已更新、source branch render 通过、PipelineRun 名称存在
阅读 docs/reference/spec-v02-cicd.md，然后用 cli 手动测试以下内容：在不打印任何 GitHub 凭证的前提下确认 runtime checkout 读路径命中 `devops-infra` git mirror/cache，业务 namespace 没有 GitHub deploy key；模拟 mirror miss 或非法 commit 时 rollout fail closed，不回退到 GitHub 直连或 env image 内旧代码。
## T7
阅读 docs/reference/spec-v02-cicd.md，然后用 cli 手动测试以下内容：触发一次 `v0.2` code-only promotion，确认 `gitops-promote` 只 push 到 `devops-infra` 本地 mirror/relay，Argo 从本地 mirror/relay rollout；再执行 `git-mirror flush --confirm`，确认 GitHub `origin/v0.2-gitops` 快进到同一 revision，status 中 pending 清空。
## 规格的实现情况
| 规格项 | 状态 | 说明 |
@@ -240,7 +254,7 @@ GitOps branch 已更新、source branch render 通过、PipelineRun 名称存在
| FRP `19666/19667` 入口 | 已实现 | 由 `hwlab-v02-frpc` 与 master frps allowlist 共同提供。 |
| SecretRef 独立与 provider 验收 | 已实现/持续约束 | SecretRef 已独立；验收必须做真实短连接聊天。 |
| env 容器复用三变量启动 | 已实现/持续约束 | device-pod fast lane 已由 CI/CD 自动推导 `HWLAB_BOOT_REPO`、`HWLAB_BOOT_COMMIT`、`HWLAB_BOOT_SH`；code-only rollout 复用 env image digest，只更新代码身份。 |
| `devops-infra` git mirror/cache 加速 | 已实现/持续约束 | runtime checkout 读路径使用独立基础设施集群只读 mirror/cache；runtime namespace 不持有 GitHub deploy key，registry 保持 G14 `hwlab-ci/hwlab-registry`；mirror 同步由 UniDesk CLI 手动触发，不设置 CronJob。 |
| `devops-infra` git mirror/relay 加速 | 部分实现/待迁移写路径 | source/catalog/runtime checkout 读路径已使用独立基础设施集群 mirror/cache；下一步必须把 GitOps promotion、Argo source 和 GitHub flush 收敛到真正写 mirror。runtime namespace 不持有 GitHub deploy key，registry 保持 G14 `hwlab-ci/hwlab-registry`；mirror 同步和 flush 由 UniDesk CLI 手动触发，不设置 CronJob。 |
| 自动 registry GC | 未实现 | 初期不启用自动 GC，后续需 lane/profile 保护集。 |
## 平行 lane 运维边界