Skip to main content

ocm-operator

OCM/OpenClaw envs: create, clone, upgrade, runtimes, services, logs, cleanup.

Quellinformationen

Repository
openclaw/Kova
Letzte Quellaktivität
25. Mai 2026 um 14:22
Erkannte Sprache von SKILL.md
Englisch
Sterne
11
Forks
8

Installationsoptionen

Standardmäßig ist der Prompt ausgewählt, der zuerst die Quelle prüft. Sie können zu einem direkten Befehl wechseln oder eine lokale Kopie herunterladen.

Quelldateien prüfen

Lesen Sie SKILL.md und alle von SkillsMP angezeigten Begleitdateien, bevor Sie sich für eine Installation entscheiden.

Datei-Explorer
5 Dateien

SKILL.md wird angezeigt

SKILL.md
Quellanweisungen · Schreibgeschützte Vorschau
name
ocm-operator
description
OCM/OpenClaw envs: create, clone, upgrade, runtimes, services, logs, cleanup.
# OCM Operator ## Operating Model Use OCM as the control plane for OpenClaw. Treat an OCM environment as the isolation boundary: it owns `OPENCLAW_HOME`, state, config, workspace, gateway port, runtime/launcher binding, and service policy. Prefer OCM commands over raw OpenClaw commands whenever the task touches: - env creation, cloning, migration, export/import, snapshots, or cleanup - runtime install/build/verify/update/remove - upgrades or release testing - background gateway services - logs, status, TUI/dashboard, plugin checks, model checks Run OpenClaw inside an env with: ```sh ocm @<env> -- <openclaw args> ``` Use `ocm env exec <env> -- <command>` only when you need a non-OpenClaw command inside the env, such as `env`, `node`, or shell tooling. ## First Steps 1. Inspect current state before changing it: ```sh ocm env list ocm service status ocm runtime list ``` 2. Read help for the exact surface before using unfamiliar flags: ```sh ocm help start ocm help env ocm help runtime ocm help service ocm help logs ocm help upgrade ``` 3. For detailed command patterns, read `references/command-cookbook.md`. 4. For destructive operations, service boundaries, or real user state, read `references/safety-and-state.md` before acting. 5. For this machine's common paths and release-test defaults, read `references/local-paths.md`. ## Decision Guide - **Start a normal runtime-backed env**: use `ocm start <env> --runtime <runtime>` or `ocm start <env> --version <version>`. - **Start a fresh user env**: use `ocm start <env> --runtime <runtime>` first; use `--onboard` only when testing interactive onboarding specifically. - **Use source-backed OpenClaw development**: use `ocm dev <env> --repo <repo>`. Do not use this as proof of release packaging. - **Test release behavior from local OpenClaw source**: use `ocm runtime build-local <runtime> --repo <repo> --force`, then test envs against that runtime. - **Test existing-user upgrade behavior**: clone the existing env, upgrade the clone, and never mutate the source env directly. - **Run OpenClaw commands in an env**: use `ocm @<env> -- ...`. - **Read logs**: use `ocm logs <env>`. - **Manage background gateway state**: use `ocm service status/start/stop/restart`. - **Clean up**: use `ocm env destroy <env> --yes`; this removes env snapshots, OCM service policy, and OCM-created dev worktrees. ## Safety Rules - Treat important user envs such as `Violet` and `Shaks` as durable state. Clone first for testing unless the user explicitly asks to mutate them. - Remove envs with `ocm env destroy`. - Manage OCM env gateway lifecycle with `ocm service`. - Remember OCM injects `OPENCLAW_SERVICE_REPAIR_POLICY=external` for env-run OpenClaw processes, so `openclaw doctor --fix` should repair normal env state but skip OpenClaw-owned service lifecycle repair. - Do not treat `ocm dev`, `pnpm openclaw`, or a source worktree as release validation. For release behavior, build and use a package runtime. - Clean up temporary envs, services, worktrees, tarballs, and retained simulation envs. - If a command could change real user data, run read-only inspection or clone first, then report the exact command you plan to run if there is ambiguity. ## Verification Standard Finish by exercising the relevant command path. Prefer these checks: ```sh ocm env list ocm service status <env> ocm logs <env> --tail 100 ocm @<env> -- --version ocm @<env> -- status ocm @<env> -- doctor --fix ``` Add plugin/model/TUI checks when the task touches plugins, model auth/catalog, onboarding, or gateway connectivity: ```sh ocm @<env> -- plugins list ocm @<env> -- plugins update --all --dry-run ocm @<env> -- models list ocm @<env> -- tui ``` ## Reporting Keep reports quiet and useful: - lead with pass/fail/blocker status - include the exact command for failures - include concise evidence for passes - separate OCM issues from OpenClaw runtime/package issues - say which relevant checks were skipped - include cleanup performed Use this failure shape: ```md Failure: - Command: `<exact command>` - Expected: <expected state> - Actual: <observed state/output> - Impact: <why it matters> - Likely owner: OCM | OpenClaw | test setup | external dependency - Paste to fixer: <short actionable summary> ```
Auf GitHub ansehen