agent-skills/gitops-app-onboarding/SKILL.md

name	description
gitops-app-onboarding	面向当前 Baizhi GitOps 平台的项目接入工作流，只适用于 `deploy.baizhi.cloud`、`registry.baizhi.cloud`、GitLab + Argo CD 这套固定交付模型。只要用户提到“给当前平台接入新项目”“恢复 .gitlab-ci.yml / deploy 目录”“补齐当前平台的 Helm chart / release bundle”“修当前平台的发版链路”“让应用仓库在发版时推送自己的 release 结果”，就应优先使用这个 skill；如果只是通用 CI、通用 Helm 或通用 GitOps 任务而未指向当前平台，不应触发。

GitOps 项目接入 Skill

目标

让 agent 能独立完成下面四件事：

• 生成或修复 .gitlab-ci.yml
• 生成或修复 deploy/helm/<app>/
• 生成或修复 deploy/release/
• 让发版链路把当前应用的发布结果同步到固定 GitOps 仓库

平台固定常量

除非用户明确要求修改，否则固定使用：

• GitOps 主机：deploy.baizhi.cloud
• Registry 主机：registry.baizhi.cloud
• Helm OCI 仓库：oci://registry.baizhi.cloud/helm
• GitOps 仓库地址：https://deploy.baizhi.cloud/gitops-admin/argodeploy.git
• Registry 用户名：registry-ci
• 共享 pull secret：registry-pull-secret
• GitOps 控制器：Argo CD
• 代码托管：GitLab

GitLab CI 默认依赖这些变量：

• GITEA_USER
• GITEA_TOKEN
• REGISTRY_PASSWORD

开始前先做什么

先按这个顺序读仓库：

1. README.md
2. Dockerfile、包管理文件、构建脚本、已有 deploy 文件
3. 用户提供的额外设计文档

在动手前先确定：

• 组件列表
• 每个组件的构建上下文与入口
• 对外暴露方式
• 运行时配置结构
• 平台共享依赖与应用私有依赖
• 是否检测到私有 Git 依赖（例如 git.in.chaitin.net/ai/baizhiyun/opensdk）

应用仓库自己的 README.md 是应用运行架构的真相来源；本 skill 只定义平台接入规则。

边界

• 只处理应用仓库侧接入
• 不修改与当前应用无关的 GitOps 清单
• 对 GitOps 的唯一动作，是在应用仓库 CI 中同步当前应用自己的 release 结果与版本引用
• 如果当前应用的 Application 已存在，只允许更新 apps/<app>/application.yaml 中当前应用 chart source 的 targetRevision
• 不修改 AppProject、bootstrap、其他应用的 Application

应用仓库必须产出哪些文件

CI

• .gitlab-ci.yml

Chart

• deploy/helm/<app>/Chart.yaml
• deploy/helm/<app>/values.yaml
• deploy/helm/<app>/templates/*

release 作者源

• deploy/release/metadata.yaml
• deploy/release/values.yaml
• deploy/release/secret.yaml

GitOps 仓库里最终应该有哪些文件

CI 导出结果固定为：

• deploy/release/metadata.yaml -> releases/<app>/metadata.yaml
• deploy/release/values.yaml -> releases/<app>/values.yaml
• deploy/release/secret.yaml -> releases/<app>/manifests/secret.yaml
• apps/<app>/application.yaml -> 只更新 chart source 的 targetRevision

固定规则：

• 不导出 releases/<app>/secret.yaml
• 不生成或覆盖 db-secret.yaml、 kustomization.yaml 这类 GitOps 仓库里已有的文件

GitLab CI 规则

私有 Git 依赖判定口径

下文中的“检测到私有 Git 依赖”统一指：仓库在 go.mod、go.sum、源码 import、构建脚本或 Dockerfile 构建流程中，实际引用了需要认证访问的私有 Git 仓库（例如 git.in.chaitin.net/ai/baizhiyun/opensdk）。

只有在检测到这类依赖时，才启用 .netrc、私有仓库认证，以及 GOPRIVATE、GONOSUMDB、GONOPROXY、GOINSECURE、GIT_SSL_NO_VERIFY 这一组私有 Go 变量；否则不要添加这些配置。

stages

固定使用：

• test
• build
• release

runner tags

只要 job 使用 Docker、DinD 或 docker buildx，就必须带：

• docker
• network

test job

用途：只做测试，不改 GitOps，不推镜像。

要求：

• 运行在分支和 MR 上
• 安装当前语言栈的最小依赖
• 只有检测到私有 Git 依赖时才补齐认证；否则不要引入 .netrc
• 使用项目原生测试入口

Go 项目默认变量写在 .gitlab-ci.yml 的 variables:：

• GOPROXY=https://goproxy.cn,direct
• GOSUMDB=sum.golang.google.cn

只有检测到私有 Git 依赖时，才额外设置这些变量：

• GOPRIVATE=git.in.chaitin.net
• GONOSUMDB=git.in.chaitin.net
• GONOPROXY=git.in.chaitin.net
• GOINSECURE=git.in.chaitin.net
• GIT_SSL_NO_VERIFY="true"

release 触发条件

只在 vX.Y.Z tag 上触发发布链路。

image build jobs

输入：源码、Dockerfile、单组件构建上下文。

输出：分别推送到 registry.baizhi.cloud/<app>/<component>:<version> 的运行时镜像。

设计原则：不同服务的镜像必须独立构建，避免一个组件改动或失败拖慢所有组件发布。

要求：

• 不要生成一个串行构建所有镜像的单体 build-images job；每个需要构建镜像的服务使用独立 job，例如 build-backend-image、build-frontend-image、build-nginx-image
• 如果多个组件构建脚本完全一致，可以使用 parallel:matrix，但矩阵中的每个组件仍必须是 GitLab 可独立调度、独立失败、独立重试的构建单元
• 每个镜像构建 job 只负责一个组件的 Dockerfile、构建上下文、tag 与 push
• release 链路必须等待所有应用自建镜像构建成功；优先用 needs: 精确声明，而不是只依赖 stage 顺序
• 登录 registry.baizhi.cloud
• 优先使用 docker buildx
• 只有检测到私有 Git 依赖时，才通过 .netrc 和 build secret 传入；否则不要生成 .netrc 相关步骤
• 如需额外 CA，也通过 build secret 传入
• 如果 Dockerfile 中使用 Docker Hub 源作为 FROM 基础镜像或其他拉取来源，需改写为 registry-mirrors.dev.in.chaitin.net 对应镜像源；不要保留对 Docker Hub 的直接拉取
• 如果 Dockerfile 中使用 apk，需要将 apk 软件源切换为中科大源后再安装依赖
• 如果 Dockerfile 内会执行 go mod download、go build 等 Go 构建命令，必须通过 --build-arg 透传 Go 构建变量，不要只写在 .gitlab-ci.yml 的 variables: 里
• 无论是否检测到私有 Git 依赖，至少透传：GOPROXY、GOSUMDB
• 只有检测到私有 Git 依赖时，才额外透传：GOPRIVATE、GONOSUMDB、GONOPROXY、GOINSECURE
• Dockerfile 中对应变量必须有 ARG，并让构建命令实际使用传入值，而不是退回默认值

禁止：

• http://registry...
• --plain-http
• --insecure-skip-tls-verify
• 不要假设 .gitlab-ci.yml 中的环境变量会自动进入 docker build / docker buildx build

GitLab CI YAML 与脚本合法性

生成或修复 .gitlab-ci.yml 时要优先保证 GitLab CI 配置本身可解析、可执行、可维护。

要求：

• 不要在 CI 脚本里用 Python 临时解析或改写 YAML；优先使用 yq、helm、git、install、mkdir、cp、rsync 这类明确的 CLI
• 修改 Chart.yaml 的 version / appVersion 使用 yq -i，不要用 Python heredoc 或内联脚本
• 修改 Argo CD Application 的 targetRevision 使用 yq -i 定位字段，避免用脆弱的 sed 跨行替换
• 对 CI 文件做合法性自检时，至少能用 yq e '.' .gitlab-ci.yml 验证 YAML 语法；如果环境有 GitLab CI lint 工具或 API，再补充 GitLab 语义校验
• .gitlab-ci.yml 中的多行 shell 逻辑保持最小化；复杂到需要编程语言脚本时，优先把脚本提交到仓库中的可审查文件，而不是在 CI YAML 里塞内联程序

禁止：

• 在 .gitlab-ci.yml 中嵌入 python - <<'PY'、python -c 或临时 Python 脚本来改 YAML
• 用字符串替换方式盲改 application.yaml 中所有 targetRevision

package-chart job

输入：deploy/helm/<app>/Chart.yaml、deploy/helm/<app>/values.yaml、deploy/helm/<app>/templates/*

输出：推送到 oci://registry.baizhi.cloud/helm 的 Chart 包。

要求：

• helm registry login registry.baizhi.cloud
• 在临时目录复制 deploy/helm/<app>/
• 用 yq -i 把复制品中的 version 和 appVersion 改成 tag 版本
• 业务镜像的默认 tag 必须跟随 appVersion，不要依赖 release values 覆盖业务镜像 tag
• helm package
• helm push
• 如果应用包含自建镜像，package-chart 必须通过 needs: 等待所有镜像构建 job 成功

update-gitops-repo job

输入：deploy/release/*、当前 tag 版本、GitOps 仓库中的 apps/<app>/application.yaml

输出：

• releases/<app>/metadata.yaml
• releases/<app>/values.yaml
• releases/<app>/manifests/ 下的发布结果
• apps/<app>/application.yaml 中当前应用 chart source 的 targetRevision

依赖关系：

• update-gitops-repo 必须显式依赖 package-chart 成功，优先写 needs: ["package-chart"]
• 不要让 update-gitops-repo 和 package-chart 仅靠同 stage 顺序或隐式执行顺序关联
• 如果 release stage 中还有其他准备 job，也必须保证 GitOps 仓库更新发生在 Chart 包成功推送之后

处理顺序固定为：

1. 克隆 https://${GITEA_USER}:${GITEA_TOKEN}@deploy.baizhi.cloud/gitops-admin/argodeploy.git
2. 确保 releases/<app>/ 与 releases/<app>/manifests/ 存在，不要整体清空目录
3. 将应用仓库中的 deploy/release/metadata.yaml 和 deploy/release/values.yaml 复制到 GitOps 仓库的 releases/<app>/metadata.yaml 与 releases/<app>/values.yaml，覆盖已有内容
4. 保留已有的 releases/<app>/manifests/kustomization.yaml 与 releases/<app>/manifests/db-secret.yaml
5. 将 deploy/release/secret.yaml 物化为 releases/<app>/manifests/secret.yaml
6. 替换 releases/<app>/metadata.yaml 中的 __VERSION__；只有第三方镜像、非业务版本字段或明确需要的环境配置才允许替换 releases/<app>/values.yaml 中的 __VERSION__
7. 用 yq -i 更新 apps/<app>/application.yaml 中当前应用 chart source 的 targetRevision，只改当前应用的 chart source
8. 只有存在 diff 时才提交并推送 main

禁止：

• 在 CI 中调用 kubectl
• 在 CI 中调用 argocd app sync
• 把 hard refresh 当常规发布步骤
• 在 Chart 包推送成功前更新 GitOps 仓库

Helm Chart 规则

Chart 必须反映应用的真实运行架构。

固定要求：

• 按职责拆文件，不堆一个大模板
• 模板中不硬编码生产 tag
• 所有镜像名从 values 读取
• 应用自己构建的业务镜像 tag 默认必须来自 .Chart.AppVersion，values 中的 tag 只能作为显式覆盖项
• Deployment 模板必须使用类似 {{ default .Chart.AppVersion .Values.<component>.image.tag }} 的逻辑渲染业务镜像 tag
• deploy/helm/<app>/values.yaml 中业务镜像 tag 默认写空字符串或不写，不要写生产版本号
• 所有 Service 暴露方式从 values 读取
• nginx 对外 Service 固定使用 NodePort
• 后端 Service 只做集群内访问
• 不生成 Ingress 模板，也不保留 Ingress values
• NodePort 必须来自用户或平台已分配值，不能猜
• 设置 enableServiceLinks: false
• 支持 imagePullSecrets
• 如果应用包含需要持久化数据的服务，PVC / volumeClaimTemplates 必须显式使用 storageClassName: longhorn
• 环境变量注入保持可读
• 如果镜像内带 nginx / 反向代理配置，upstream service 名必须与 Chart 渲染出的 Service 名一致
• 生成 chart 时要确认应用是否包含需要经 nginx 转发的静态文件；如果有，必须明确静态资源目录、挂载方式和 nginx 路由，不要只配后端 upstream
• 不要依赖 Kubernetes 不支持的 $(OTHER_ENV) 展开
• 对 Neo4j 这类镜像，不要注入不存在的 NEO4J_* 配置名，例如 NEO4J_PASSWORD

Argo CD sync-wave

当 Chart 或 release manifests 中存在资源依赖顺序时，使用 Argo CD sync wave 明确表达顺序，避免依赖文件名、模板渲染顺序或 Kubernetes 最终一致性碰运气。

固定规则：

• annotation 键必须写成 argocd.argoproj.io/sync-wave，不要写成 rgocd.argoproj.io/sync-wave 或其他拼写
• wave 值使用字符串，例如 "-20"、"0"、"10"
• 低 wave 先同步，高 wave 后同步；不要把依赖方和被依赖方放在同一个 wave
• releases/<app>/manifests/ 下的资源也必须参与 wave 设计；不要只给 Helm Chart 模板里的资源排序
• 被 Job、Deployment、StatefulSet 或 Pod 通过 envFrom、secretKeyRef、configMapKeyRef、volume、imagePullSecrets 消费的 Secret / ConfigMap，wave 必须早于消费它们的 workload
• registry-pull-secret、platform-shared-secrets 等平台托管共享资源的 wave 已固定为 "-1"；不要修改它们，应用资源应围绕这个锚点排序
• manifests/db-secret.yaml 如果存在，必须早于所有读取 databaseSecret / <app>-db 的 migrate Job 和业务 workload；推荐使用 "0"
• 应用私有 Secret、应用私有 ConfigMap 必须早于所有会消费它们的 workload；推荐使用 "0"
• 只有确实存在跨资源启动顺序要求时才加 sync-wave，不要给所有资源机械添加 annotation

推荐顺序：

• -1：平台托管共享资源，例如 registry-pull-secret、platform-shared-secrets、平台共享 ConfigMap
• 0：应用自有前置资源，例如 ServiceAccount、RBAC、manifests/db-secret.yaml、应用私有 Secret、应用私有 ConfigMap、PVC / volumeClaimTemplates 所依赖的存储前置资源
• 10：migrate Job、应用自带的私有基础设施，例如 Neo4j、向量库、内部依赖服务的 StatefulSet / Deployment
• 15：内部依赖的 Service，尤其是会被后续 nginx upstream 或应用启动配置引用的服务名
• 20：后端、worker、API 等核心业务 Deployment / StatefulSet
• 25：核心业务 Service
• 30：nginx / frontend 入口 Deployment，以及对外 NodePort Service

如果 nginx 配置在容器启动时解析 upstream，必须保证 upstream 对应 Service 的 wave 早于 nginx Deployment；如果应用启动依赖 Secret / ConfigMap / PVC / imagePullSecret，必须保证这些资源的 wave 早于消费它们的 workload。尤其注意平台共享资源已经在 "-1"，应用自有 secret/config 应从 "0" 开始，migrate Job 这类消费者必须排在它们之后，例如 "10"，不能把消费者放到 "-10" 或同一个 wave 里。

生成或修复 release manifests 时，逐项核对：

• releases/<app>/manifests/db-secret.yaml 的 wave 早于 Chart 中所有引用该 secret 的 Job / Deployment / StatefulSet
• releases/<app>/manifests/secret.yaml 的 wave 早于 Chart 中所有引用该 secret 的 workload
• registry-pull-secret 在目标 namespace 存在，且 wave 早于所有使用私有镜像的 workload
• 共享 secret / config 如果由 release manifests 或 shared manifests 同步，也早于所有消费者

如果应用依赖平台 shared 之外的私有服务，必须明确表达依赖来源：

• 要么由 Chart 生成应用自带资源
• 要么明确引用用户提供的外部地址

不能只留一个指向不存在服务的 host。

如果应用自带依赖同时需要业务连接口令和依赖自身启动口令，Secret key 要同时表达两种消费方式，例如：

• neo4j_password
• neo4j_auth

对外暴露模型

固定使用：

• nginx 作为统一入口
• 对外只暴露一个 nginx NodePort
• 后端服务只在集群内通信
• 不生成 Ingress

NodePort 处理规则：

• 用户或文档已提供时直接使用
• 没提供时，在生成到这一项时立即索取
• 不要写示例端口或默认端口

Release Bundle 规则

metadata.yaml

至少包含：

• 应用名
• release 名
• namespace
• chart 名
• chart 版本
• chart 仓库
• 镜像 tag
• 源码仓库地址

values.yaml

必须是可部署默认值，不是示例值。

至少满足：

• 应用自建镜像使用 registry.baizhi.cloud/<app>/...
• 应用自建镜像不要在 release values 中写业务版本 tag；业务镜像 tag 默认由 Chart appVersion 决定，以便 Argo CD UI 回滚 Chart 版本时镜像版本同步回滚
• 第三方镜像保持真实来源
• 第三方镜像 tag 必须继续显式写在 values 中，不要跟随 Chart appVersion
• Secret 名与 Chart 约定一致
• PostgreSQL 连接读取应用自己的 databaseSecret
• 私有镜像包含 imagePullSecrets
• 与 Chart schema 一致
• 不要包含 backend.image.tag、server.image.tag、frontend.image.tag、nginx.image.tag 等应用自建业务镜像版本覆盖，除非用户明确要求做一次性特殊覆盖
• nginx 对外入口使用 NodePort
• NodePort 值来自用户或平台分配结果
• 不包含 Ingress 配置项

manifests/db-secret.yaml

这是 deploy 仓库注册应用阶段生成的数据库源，secret 名称格式为 <app>-db 不是应用仓库侧要生成的文件。至少包含：

• host
• port
• database
• username
• password

固定规则：

• chart 如果依赖 Postgres 则必须消费这个 secret

secret.yaml

只放应用私有 Secret，key 名必须与 Chart 读取的 key 对齐。

规则：

• 不伪造生产值
• 外部集成凭据在生成到对应配置时逐项索取
• 应用自带私有依赖的内部口令优先自动生成
• 组合型鉴权字段优先直接写成完整 key 值
• 缺值时停在当前项继续问，不要留看似可部署的假配置

平台共享配置契约

shared/ 只放平台级共享配置。

共享资源：

• platform-runtime-config
• platform-shared-secrets
• registry-pull-secret

platform-runtime-config 提供：

• LLM_BASE_URL
• EMBEDDER_BASE_URL
• OSS_BUCKET

platform-shared-secrets 提供：

• REDIS_PASSWORD
• QDRANT_API_KEY
• OSS_ACCESS_KEY
• OSS_SECRET_KEY

平台共享基础设施固定为：

• PostgreSQL
• Redis
• Qdrant
• OSS

固定 FQDN 与对象存储约定：

• redis.infra.svc.cluster.local
• qdrant.infra.svc.cluster.local

固定规则：

• 不要写成当前应用 namespace 下的裸服务名
• 不默认为 Redis、Qdrant、OSS 生成应用私有实例
• 如果应用当前使用的是 MinIO / S3 兼容配置，优先沿用现有对象存储配置结构接入平台对象存储；但不要默认假设 MinIO 客户端可直接连接平台 OSS，需根据仓库实际使用的 SDK 与平台提供的协议兼容性确认
• Neo4j 不属于 shared；如应用需要，由应用自己部署
• 不要把应用私有鉴权材料放进 shared/
• 如果 Chart 依赖的运行时资源不是由 Chart 直接创建，就必须确保 releases/<app>/manifests/ 仍会把这些资源 apply 到目标 namespace

百智云用户鉴权接入

只有在检测到私有 Git 依赖，且该依赖就是 git.in.chaitin.net/ai/baizhiyun/opensdk 时才需要接入。

识别规则：

• 先按上文“私有 Git 依赖判定口径”检查仓库，再确认私有依赖中是否实际包含 git.in.chaitin.net/ai/baizhiyun/opensdk
• 只有确认包含这个依赖或导入时，才进入本节并索取百智云相关材料
• 如果仓库里没有这个包，就跳过整段，不要要求接入百智云，也不要生成对应配置

固定规则：

• 不要把鉴权材料放进 shared/
• 不要伪造生产值
• 按固定顺序逐项索取：app_id -> app.crt -> app.key -> ca.crt -> public.key
• 缺少哪一项，就停在那一项继续问

挂载规则：

• 固定挂载目录：/app/ssl
• 固定文件路径：/app/ssl/app.crt、/app/ssl/app.key、/app/ssl/ca.crt
• 不要改成其他自定义目录
• public.key 如果保留，应明确其用途，不要混同为 mTLS 必需文件

提问方式

• 只问当前步骤真正阻塞的值
• 逐项问，不要一次性要一大串
• 对外部集成字段，在写到对应配置时就问
• 对应用自带私有依赖内部口令，优先自动生成
• 如果当前正在等补值，回复重点只放当前这一项

执行顺序

按下面顺序推进：

1. 读 README 与构建文件
2. 梳理组件、依赖、暴露模型
3. 生成或修复 .gitlab-ci.yml
4. 生成或修复 Chart
5. 缺少必填值时停在当前项索取
6. 生成或修复 deploy/release/
7. 自检并汇报风险点

自检

完成后尽量执行：

• git status --short
• git diff --check
• yq e '.' .gitlab-ci.yml
• helm template（前提是 Chart 与 values 已能渲染）

至少确认：

• 接入文件齐全
• .gitlab-ci.yml YAML 语法合法，不包含用于改 YAML 的内联 Python
• .gitlab-ci.yml 包含 test、组件级独立镜像构建、Chart 发布、GitOps 同步
• 多服务应用的业务镜像不是由一个串行 build-images job 统一构建；每个自建镜像可被 GitLab 独立调度和重试
• package-chart 通过 needs: 等待所有必要镜像构建成功
• update-gitops-repo 通过 needs: 依赖 package-chart 成功
• release values 指向 registry.baizhi.cloud
• release values 不覆盖应用自建业务镜像 tag；业务镜像 tag 由 Chart appVersion 默认决定
• 第三方镜像没有被错误改写到平台 registry
• 第三方镜像仍显式固定 repository 和 tag，且没有错误跟随 Chart appVersion
• 如果 Dockerfile 原本使用 Docker Hub 源，已切换到 registry-mirrors.dev.in.chaitin.net，且未误改其他非 Docker Hub 镜像源
• 如果 Dockerfile 中使用 apk，已切换到中科大源
• GitOps update job 指向 https://deploy.baizhi.cloud/gitops-admin/argodeploy.git
• GitOps update job 用 yq 精确更新当前应用 chart source 的 targetRevision
• CI 中没有直接调用 Argo
• 只使用 deploy.baizhi.cloud 与 registry.baizhi.cloud
• 没有使用不安全的 registry 访问方式
• 如果 Application 仍引用 releases/<app>/manifests/，该 path 在发布结果中实际存在
• 如果镜像内包含固定 upstream 配置，upstream service 名与 Chart 渲染结果一致
• Neo4j 一类自带依赖的启动环境变量不依赖 $(OTHER_ENV) 展开
• 如果应用包含需要持久化数据的服务，对应 PVC / volumeClaimTemplates 已显式设置 storageClassName: longhorn
• 如果资源存在启动顺序依赖，argocd.argoproj.io/sync-wave 拼写正确，wave 顺序符合依赖方向
• releases/<app>/manifests/db-secret.yaml、secret.yaml、pull secret、shared secret/config 的 wave 早于所有引用它们的 migrate Job 和业务 workload
• registry-pull-secret、platform-shared-secrets 等平台托管资源保持平台约定的 "-1"，应用自有前置资源围绕它排序，不要改平台资源 wave
• migrate Job 不要设置成负 wave；它依赖的应用自有 Secret / ConfigMap / DB secret 通常在 "0"，migrate Job 应排在更高 wave，例如 "10"
• 如果检测到的私有 Git 依赖中包含 git.in.chaitin.net/ai/baizhiyun/opensdk，缺少必填百智云私有配置时交互停在当前项继续索取

最终输出

默认按这个顺序汇报：

1. 修改了哪些文件
2. 关键决定
3. 最值得人工复核的点

常见错误

• 把应用私有鉴权材料放进 shared/
• 在 CI 里直接刷新 Argo
• 重新引入旧域名
• 使用 insecure registry 参数
• Chart 与应用真实组件不匹配
• 在生产 release values 中写示例地址
• 在 release values 中写应用自建业务镜像 tag，导致 Argo CD UI rollback 只回滚 Chart 但镜像仍被 main 上的 values 固定到新版本
• 擅自发明新的公网 host
• 在未检测到私有 Git 依赖中的 git.in.chaitin.net/ai/baizhiyun/opensdk 时仍强行接入百智云
• Dockerfile 明明使用了 Docker Hub / apk 默认源，却没有切到 registry-mirrors.dev.in.chaitin.net / 中科大源，或误改了原本不在 Docker Hub 的镜像源
• 用户未提供必填值时伪造占位内容
• 多个服务镜像塞进一个串行 build job，导致无法并行构建、无法单独重试、失败定位困难
• update-gitops-repo 没有依赖 package-chart，GitOps 仓库先于 Chart 推送被更新
• 在 .gitlab-ci.yml 中用 Python heredoc 临时改 Chart.yaml、release values 或 application.yaml
• argocd.argoproj.io/sync-wave 拼错为 rgocd.argoproj.io/sync-wave，或把依赖方放在被依赖资源之前
• 只给 Chart 模板资源设计 wave，却遗漏 releases/<app>/manifests/db-secret.yaml、secret.yaml、pull secret 等 release manifests，导致 migrate Job 先于 Secret 执行
• 不顾平台约定把 registry-pull-secret、platform-shared-secrets 等平台托管资源改成其他 wave；正确做法是保持它们在 "-1"，应用资源围绕 "-1" 排序