docs: document mxcx host codex operations

docs/reference/deployment.md

@@ -32,6 +32,16 @@ Compose v2 安装后仍然必须遵守 UniDesk 的服务控制入口：全栈生
 
 版本化用户服务部署优先使用 `bun scripts/cli.ts deploy apply` 已支持的受控路径；D601 persistent dev apply 当前支持 `backend-core`/`frontend`/`baidu-netdisk`/`decision-center`/`mdtodo`/`claudeqq` artifact consumer、dev-only `code-queue` artifact consumer，以及 `project-manager`、`oa-event-flow`、`code-queue-mgr`、`todo-note`、`findjob`、`pipeline` 和 `met-nonlinear` 的 artifact consumer validation，dev desired-state smoke 使用 `ci run-dev-e2e`。`deploy.json` 只声明服务 `id`、`repo` 和 `commitId`；目标节点、Dockerfile、Compose、Kubernetes manifest、健康检查和代理路径继续来自 `config.json` 与现有 manifest。主 server 直管微服务和内部 sidecar，例如 `code-queue-mgr`，也必须支持这一路径：`deploy apply --service code-queue-mgr` 从 `deploy.json` 指定 commit 导出源码、构建镜像、替换固定 Compose service 并验证运行中镜像/健康信息的 commit，但 prod live apply 仍需 supervisor 确认。部署默认遵循 target-side build：服务部署到哪台 target，就在哪台 target 从 remote commit 导出源码、一次性代理构建镜像并部署；不得把中心构建镜像作为默认分发路径，也不得用 `docker commit` 或脏 worktree 作为部署输入。backend-core 是明确例外；`frontend` 是用户服务 UI / 前端镜像化样板，`baidu-netdisk` 是主 server 直管微服务的镜像化样板，`decision-center`、`mdtodo` 和 `claudeqq` 是 k3s-managed artifact consumer 样板，`findjob` 和 `pipeline` 是 D601 direct Docker/Compose pull-only 样板：D601 CI 构建并推送 commit-pinned 镜像到 D601 artifact registry，CD 只拉取、retag 或导入、recreate/rollout 和验证，不在 master server 或 runtime target 执行 Compose build。Dev backend-core consumes `127.0.0.1:5000/unidesk/backend-core:<commit>` into `unidesk-dev/backend-core-dev` and must not compile Rust during CD. `met-nonlinear` 当前只允许 dry-run/plan，`k3sctl-adapter` 只允许 plan/dry-run 且真实 prod 部署需要 supervisor 确认。`code-queue` 只允许 dev artifact consumer，prod artifact deploy/rollout/manifest mutation 必须 unsupported。完整规则见 `docs/reference/deploy.md`，D601 dev/Rust 边界见 `docs/reference/dev-environment.md`，artifact registry 见 `docs/reference/artifact-registry.md`。
 
+## Host Codex Profiles
+
+主 server 上的 `codex`、`mycx` 和 `mxcx` 都是人工/Codex 运维入口，不属于 UniDesk Compose 服务、Code Queue runner、AgentRun runtime 或发布流水线。`mxcx` 只用于快速以 MiniMax-M3 provider 启动同一套 Codex CLI；它必须复用系统 `codex` 二进制，不安装第二套 Codex，不替换 `/usr/bin/codex`，也不改变 `mycx` 指向的默认 Codex 启动方式。
+
+MiniMax-M3 配置必须保持 profile/provider 级隔离。当前 `mxcx` 的稳定上游形态应与 AgentRun `minimax-m3` profile 对齐：`model=MiniMax-M3`、`model_provider=minimax`、`base_url=https://api.minimaxi.com/v1`、`wire_api=responses`，并通过 `OPENAI_API_KEY`/`MINIMAX_API_KEY` 环境或本机只读配置文件注入凭据。密钥文件只能保存在 root 用户可读的本机路径，权限应为 `0600` 或更严；不得提交到 Git、写入 `AGENTS.md`/`docs/reference`、进入 Docker image、Compose env、GitOps manifest、issue/PR 评论、CLI 输出或任务 trace。
+
+`mxcx` 的验收以真实 Codex CLI 行为为准：`mxcx --version` 必须显示与 `codex --version` 相同的 binary 版本；`mxcx doctor --json` 或等价命令必须显示 `model=MiniMax-M3` 与 `model provider=minimax`；最小真实调用可使用 `mxcx exec 'Reply exactly: MXCX_OK'`，但该调用会消耗 MiniMax token，不应放入默认健康检查、CI/CD 或循环监控。MiniMax `/v1/models` 探测只能作为网络/凭据诊断，不能替代 Codex CLI profile 验收。
+
+如果 `mxcx` 需要本机转发服务，必须优先复用 AgentRun 已采用的 provider/profile 方案或同款转发组件；不得在 UniDesk master server 上临时自造一套长期维护的 MiniMax 协议转换服务。确需部署转发时只允许作为本机轻量 Docker 运维组件，固定绑定 loopback、固定端口、日志可见、密钥不进镜像，并记录启动/停止/健康检查入口；不得接入 UniDesk CI/CD、GitOps、provider-gateway 自动升级或生产 Compose 主服务生命周期，除非后续专门把它产品化为受控服务。
+
 ## Main Server Swap
 
 主 server 可能运行在约 2 GiB 内存的小规格机器上，短时 Docker build、Codex/control-plane 调查和日志读取会触发 global OOM。主 server 必须通过 `bun scripts/cli.ts server swap status` 暴露当前 memory/swap 状态，并在 `server status` 的 `swap` 字段中给出同一摘要。