galaxy-ops 开源运维交付工具，用于组织、配置、组合和交付运维能力，并将项目实施过程沉淀为可复用、可演进的交付资产。
在整体产品分工中：
galaxy-ops负责模块、系统和运维项目的组织与交付galaxy-flow提供基于 GXL 的工作流定义与执行能力
稳定版
curl -sSf https://get.warpparse.ai/inst-x.sh | bash -s -- gops测试版（beta 通道）
curl -sSf https://get.warpparse.ai/inst-x.sh | bash -s -- gops beta开发版（alpha 通道）
curl -sSf https://get.warpparse.ai/inst-x.sh | bash -s -- gops alpha默认安装到：$HOME/bin。如需自定义安装目录：
curl -sSf https://get.warpparse.ai/inst-x.sh | WP_INST_INSTALL_DIR=/usr/local/bin bash -s -- gops安装后验证：
# 需要 PATH 里有 $HOME/bin（galaxy-ops 调用 galaxy-flow 的 gx 来完成系统操作）
gops --version
gx --version如果提示命令不存在，请把安装目录加入 PATH（例如 $HOME/bin）。
安装后可用 gops self update 直接升级到最新版本，无需重新执行安装脚本：
gops self status # 当前版本与安装目录
gops self check -c alpha # 查询通道最新版本（-c 是 --channel 短写；--json 机器可读）
gops self update -c alpha --yes # 升级到最新版
gops self rollback # 回滚到上一版本gops 可直接把 gops-skills 装进 agent 的 skills 目录（无需 install.sh / python3 / ruby）：
gops self skill install # 整包（顶层路由 + skills/），自动探测已装平台
gops self skill list # 列出可安装的 skills- 默认源
galaxio-labs/gops-skills@main；--source接受owner/repo、git URL 或本地目录，--ref指定分支 / 标签。 --target codex|claude|zed|all（可重复）与--dir <path>（可重复）选择落地目录；都不给时自动探测~/.codex/skills、~/.claude/skills、~/.agents/skills。- 装前校验每个
SKILL.md的 YAML frontmatter，非法即中止；本地来源可用--symlink。
见下方 Quick Start。
很多自动化工具解决的是“命令怎么执行”，galaxy-ops 更关注“运维能力如何被组织、组合、配置、本地化和交付”。
它不是泛化的 CI/CD 平台，也不是单纯的部署脚手架，而是把模块、系统和项目这些交付对象沉淀为可复用资产的工具层。
galaxy-ops 围绕三类核心对象工作：
Module：最小可复用运维单元，包含规范、依赖、变量、模板和工作流。System：由多个模块组合形成的交付单元，用于表达完整系统的结构与操作方式。Ops Project：面向具体客户环境或部署现场的运维项目，用于导入系统、管理本地值和持续更新。
对应关系可以简化为：
Module -> System -> Ops Project
当前仓库中的 gops CLI 主要提供五组能力：
gops mod：创建模块、生成示例、更新引用、本地化模块配置、查看值变更。gops sys：系统定义与交付——创建系统、解析定义、本地化、打包、值变更。gops run：运行时运维——在目标环境下载/安装/卸载组件、启动/停止服务、查询状态、诊断。gops prj：创建运维工程、导入系统、更新本地项目引用。gops self：检查与升级gops自身（自升级），并安装 / 列出 agent skills（gops self skill）。
这意味着 galaxy-ops 负责交付组织层，而不是直接替代工作流执行引擎：
galaxy-ops管理模块、系统、项目与交付结构galaxy-flow管理 GXL 工作流的定义与执行
主命令：
gops <COMMAND>一级命令：
gops modgops sysgops rungops prjgops self
常用子命令：
gops mod new --name nginx # 创建模块
gops mod localize # 本地化模块配置
gops mod diff # 查看值变更（哪些值被覆盖、被哪一层覆盖）gops sys new --name web-stack # 创建系统
gops sys resolve # 解析系统定义（取模块 / 解析变量 → merged_vars.yml）
gops sys diff # 查看值变更（初始值 / 生效值 / 来源 / 可变性；--json 机器可读）
gops sys perms # 宿主 bind 挂载权限自检（--apply 幂等修复，--json 机器可读）
gops sys package # 打包为 .tar.gz（在系统目录内执行）gops sys perms 只对 kind: docker-compose 系统生效：它读 docker compose config --format json
（不需要拉镜像），按每个服务的 user:、bind source、read_only 派生宿主属主/权限，
默认只 stat 并列出待修项；--apply 才改磁盘。写挂载对齐为文件 660 / 目录 2770，
只读挂载只补属组读位（640 / 2750），容器自建的文件（属主 = 容器 uid）不动。
只在 Linux 上生效；详见 docs/design/sys-perms.md。
gops run download # 下载组件
gops run install # 安装组件
gops run start # 启动服务
gops run stop # 停止服务
gops run status # 查询状态
gops run diagnose # 诊断gops prj new --name customer-a # 创建运维工程
gops prj import --path /path/to/web-stack-0.1.0.tar.gz # 导入已打包的系统
gops prj sync # 同步内容到 addr 指向的版本；缺失系统按包导入（非破坏）
gops prj upgrade latest -c alpha --on-failure rollback-all # 一次可回滚的发布升级（按通道取最新）
gops prj upgrade web-stack patch --on-failure halt # 只升 web-stack 到下一个 patch
gops prj upgrade web-stack 0.10.0-alpha --on-failure rollback-all # 精确版本
gops prj upgrade --to /path/to/pkg.tar.gz --on-failure halt # 完整地址逃生口prj import 会自动把 pkg-1.0.0.tar.gz 里的版本改写成 {version} 模板并写入 version: 1.0.0，
后续可直接用 prj upgrade latest|patch|minor|major。目标版本与现场版本一致时默认 no-op
（不备份、不覆盖、不切换），--force 可强制重跑。--on-failure 默认 rollback-all，
需要停在现场排查时显式传 --on-failure halt。
普通 HTTP 源（COS / S3 / OSS / nginx 等）：
patch/minor/major会按版本规则生成候选 URL 并做 HEAD 探测（有界：patch 向前 20 个，minor 最多 5 个、每个最多 5 个 patch，major 最多 3 个、每个 major 最多 2 个 minor）； 候选按版本升序每 8 个一批并发探测，命中即取该批最小版本， 正常情况下只发 1 批请求（约 0.5s）；latest没有天然停止条件，仍需要版本清单：在addr版本段的父目录放一份versions.json/versions.txt：
https://.../wist-center-stack/versions.json # 或 versions.txt
{ "versions": ["0.1.9-alpha", "0.1.10-alpha"] }versions.txt 为每行一个版本，支持 # 注释。没有清单且无法探测时，仍可用精确版本或 --to。
「内容 / 版本」类命令的分工（避免 sync 与 upgrade 混淆）：
| 诉求 | 命令 |
|---|---|
| 给已交付系统换版本 / 补齐被删的系统，只覆盖包内内容、不动现场态、可安全重入 | gops prj sync（旧名 update 仍可用） |
要一次可回滚的发布升级：含备份、重渲值、拉镜像、切换、探活（仅 docker-compose） |
gops prj upgrade |
sync与upgrade的边界：sync是非事务的内容同步（无备份、无健康检查、无回滚，也不同步运行时）；upgrade是事务（有备份与回滚，含运行时切换与探活）。
gops self check --channel alpha # 检查通道最新版本
gops self update --channel alpha --yes # 升级到最新版
gops self skill install # 安装 agent skills
gops self skill list # 列出可安装的 skills查看完整帮助：
gops --help
gops mod --help
gops sys --help
gops run --help
gops prj --help
gops self --helpcargo build --release调试运行：
cargo run --bin gops -- --helpmkdir demo-work && cd demo-work
gops mod new --name nginx模块目录中通常会包含规范、变量、值文件和工作流等内容，用于表达一个可复用运维单元。
gops sys new --name web-stack系统用于组合多个模块，并形成一个更接近交付视角的系统定义。
默认是模块式（GXL）系统；也支持纯 docker-compose 系统：gops sys new --name web-stack --kind docker-compose。此时 gops run start/stop/status/... 自动映射到 docker compose，密钥用 ${SEC_xxx} 占位、运行时从 ~/.galaxy/sec_value.yml 注入（详见 example/README.md 与 src/system/README.md）。
cd web-stack
gops sys packagesys package 会先执行一次 update（解析模块变量、生成 merged_vars.yml），再把系统打包为父目录下的 <name>-<version>.tar.gz，作为可交付产物。
cd ..
gops prj new --name customer-a
cd customer-a
gops prj import --path ../web-stack-0.1.0.tar.gz
gops prj sync运维项目用于把系统导入到具体环境，并在本地持续维护配置和值文件。
galaxy-ops/
├── app/gops/ # gops CLI
├── src/module/ # 模块模型、引用与本地化
├── src/system/ # 系统模型、系统操作与设置
├── src/ops_prj/ # 运维项目创建、导入与更新
├── src/workflow/ # 与工作流相关的适配层
├── example/ # 示例项目
└── tests/ # 集成测试
- 模块化：先定义模块，再组合系统，最后落到具体运维项目。
- 本地化：通过变量和值文件生成特定环境下可执行的配置结果。
- 可交付：把项目里的临时脚本和配置沉淀为结构化资产。
- 与 GXL 协同：工作流执行能力由
galaxy-flow提供，galaxy-ops不重复发明执行器。
galaxy-ops 能支持“一个系统，多客户自动化部署”，核心不是复制脚本，而是把“可复用定义”和“客户差异化配置”分层管理。
它的设计可以概括为三层：
Module层：沉淀可复用的模块规范、依赖、模板、变量和工作流。System层：把多个模块组合成一个可交付系统，并维护系统级变量、模块列表和系统工作流。Ops Project层：每个客户或每个环境对应一个独立运维项目，负责导入同一个系统，并维护自己的本地值文件和交付结果。
这三层分离后，同一个系统可以被多个客户项目重复使用，而不会把客户差异直接写死在系统定义里。
系统本身负责表达：
- 系统包含哪些模块
- 模块之间如何组合
- 需要哪些系统变量和模块变量
- 默认工作流和交付结构是什么
客户差异则放在运维项目和值文件里表达，例如：
- 域名
- IP / 端口
- 证书路径
- 资源规格
- 环境开关
- 客户特有依赖地址
这意味着“系统定义”可以保持稳定，“客户配置”可以独立演进。
galaxy-ops 会为系统和模块初始化值文件，并在本地化阶段生成目标环境所需的配置结果。
可以把它理解为：
System / Module Spec
+ Customer Values
-> Localized Output
也就是说：
- 同一个
System可以导入到多个Ops Project - 每个
Ops Project使用不同的value.yml、模块值和系统值 - 本地化后得到各客户独立的最终配置和部署结果
gops prj import 用于把系统导入到客户运维项目中。
之后：
- 公共系统定义可以继续演进
- 客户项目可以通过
gops prj sync获取共享定义的更新 - 客户自己的值文件和本地配置仍保留在各自项目中
这样可以避免“每交付一个客户，就复制一份完全独立的系统代码”。
差异化不只发生在系统层，也可以发生在模块层：
- 系统级值：控制整个系统的公共行为
- 模块级值：控制具体模块在某个客户环境中的配置
这让同一个系统既能复用统一结构，也能在数据库、网关、采集、规则、路径等模块上做客户级差异。
1. 定义可复用 Module
2. 组合形成 System
3. 为客户 A 创建 Ops Project，导入同一个 System
4. 为客户 B 创建 Ops Project，导入同一个 System
5. 分别维护客户 A / B 的值文件
6. 分别执行本地化与部署动作
对应到命令上，大致是：
# 创建系统
gops sys new --name web-stack
# 解析变量并打包（生成 web-stack-0.1.0.tar.gz）
cd web-stack
gops sys package
cd ..
# 客户 A
gops prj new --name customer-a
cd customer-a
gops prj import --path ../web-stack-0.1.0.tar.gz
gops prj sync
# 客户 B
cd ..
gops prj new --name customer-b
cd customer-b
gops prj import --path ../web-stack-0.1.0.tar.gz
gops prj sync在这个模型里：
web-stack是共享系统定义customer-a和customer-b是两个独立交付项目- 两个项目共享同一套系统结构，但保留各自的本地值和交付结果
这正是 galaxy-ops 支持多客户自动化部署的基础设计。
如果用一句话概括：
galaxy-ops 是用于组织、配置、组合和交付运维能力的开源工具；galaxy-flow 是负责定义和执行这些工作流的开源引擎。