omnigraph/docs/user/cli/index.md
Andrew Altshuler 4601e5f4bf
feat!: delete the legacy OmnigraphConfig + config migrate; finish the omnigraph.yaml docs sweep (#252)
* refactor(cli): own ReadOutputFormat/TableCellLayout in the CLI

The two output-presentation enums lived in `omnigraph-server::config` and were
re-exported for the CLI, even though the server never used them. Move both
definitions into `omnigraph-cli/src/read_format.rs` (where the renderer already
lives) and drop them from the server's public re-export. This is a step toward
deleting the legacy `omnigraph-server::config` module entirely — a CLI
presentation concern has no business in the server crate.

No behavior change. The server keeps private copies in `config.rs` only for the
soon-to-be-deleted legacy `CliDefaults`.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

* feat(cli)!: remove the `config migrate` command and migrate.rs

`config migrate` was the last CLI consumer of the legacy `omnigraph.yaml`
(`OmnigraphConfig` + `load_config`). With the excision complete there is no
legacy file to split, so the whole `omnigraph config` command group is removed
along with `migrate.rs`. The `OmnigraphConfig` type, `load_config`, and the
deprecation machinery are deleted next.

- Remove `Command::Config` / `ConfigCommand` from the clap surface and the
  dispatch arm; drop `mod migrate;` and the now-unused `load_config` import.
- Drop the `Command::Config` arms in `planes.rs`.
- Delete the `config_migrate_splits_legacy_config` integration test.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

* feat(server)!: delete the legacy OmnigraphConfig type and load_config

With `config migrate` gone, nothing loads `omnigraph.yaml` anymore. Delete the
entire `omnigraph-server::config` module: the `OmnigraphConfig` type and its
sub-structs (`ProjectConfig`, `TargetConfig`, `CliDefaults`, `ServerDefaults`,
`AuthDefaults`, `QueryDefaults`, `AliasConfig`, `AliasCommand`, `PolicySettings`,
`QueryEntry`, `McpSettings`), `load_config`, and the RFC-008 deprecation
machinery (`OMNIGRAPH_CONFIG`, `OMNIGRAPH_NO_LEGACY_CONFIG`,
`OMNIGRAPH_SUPPRESS_YAML_DEPRECATION`, the deprecation map + warner).

- `QueryRegistry::load` (the only `OmnigraphConfig`/`QueryEntry` consumer; its
  only caller was its own test) is removed — server boot and the CLI both build
  registries via `QueryRegistry::from_specs`.
- `graph_resource_id_for_selection` (CLI-only) moves into the CLI
  (`helpers.rs`), with its unit test; the server no longer exports it.
- Drop the already-dead `format_registry_load_errors` helper (config-adjacent).

No behavior change — every deleted item was unreachable after the excision.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

* docs: purge the legacy omnigraph.yaml surface from the docs

Finish the RFC-011 excision in the docs: the CLI no longer reads omnigraph.yaml
and the server boots cluster-only, so every doc that described the legacy file
as a live config is now wrong.

- AGENTS.md: rewrite the HTTP-server line to cluster-only boot (drop the
  single-graph/flat-route and omnigraph.yaml-boot framing); rewrite the CLI
  two-surface-config passage (drop `config migrate`, the deprecation env vars,
  and "Never extend omnigraph.yaml"); fix the topic table + capability rows.
- cli/reference.md: delete the entire "omnigraph.yaml schema (legacy combined
  file)" section and the `config migrate` row; re-home the `policy` row, the
  bearer-token chain, the actor/format/param-precedence references, and the
  `--config` mentions to the operator config + `--cluster`.
- cli/index.md: rewrite the multi-graph-server + add-graph paragraphs to
  cluster (`--cluster` + `cluster apply`); fix the policy examples to
  `--cluster`; replace the `## Config` omnigraph.yaml example with the
  operator/cluster two-surface model.
- operations/policy.md: rewrite per-graph-vs-server-level policy to the cluster
  `policies:`/`applies_to` model; re-home the actor + CLI tooling sections.
- clusters/config.md, clusters/index.md, deployment.md: server boots from the
  cluster only; per-operator facts come from ~/.omnigraph/config.yaml.
- architecture.md, testing.md: drop the stale omnigraph.yaml / deleted-test
  references.

RFCs, design specs, and prior release notes are left as historical records.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-15 22:31:29 +03:00

7.2 KiB

CLI Guide

Core Graph Flow

omnigraph init --schema schema.pg graph.omni
omnigraph load --data data.jsonl --mode overwrite graph.omni
omnigraph snapshot graph.omni --branch main --json
# Invoke a stored query BY NAME from the catalog (served — addressed by scope):
omnigraph query  get_person    --params '{"name":"Alice"}'
omnigraph mutate insert_person --params '{"name":"Mina","age":28}'

omnigraph query is the canonical read command (pairs with POST /query); omnigraph mutate is the canonical write command (pairs with POST /mutate). The positional argument is the stored-query name, invoked from the served catalog (RFC-011 D3) — the graph is addressed by scope (--server / --profile / defaults), and the verb asserts the query's kind (query rejects a stored mutation, and vice-versa). The previous names omnigraph read and omnigraph change keep working as visible aliases — invocations emit a one-line deprecation warning to stderr. See Deprecated names.

For ad-hoc reads and mutations (REPLs, AI agents, one-off scripts, local dev), pass the GQ source with -e / --query-string (inline) or --query <path> (a file), and address a graph's storage directly with --store. By-name catalog invocation is served-only — a bare --store has no catalog, so it's the ad-hoc lane:

omnigraph query --store graph.omni \
  -e 'query find($name: String) { match { $p: Person { name: $name } } return { $p.name, $p.age } }' \
  --params '{"name":"Alice"}'

omnigraph mutate --store graph.omni \
  -e 'query add($name: String, $age: I32) { insert Person { name: $name, age: $age } }' \
  --params '{"name":"Inline","age":42}'

# A multi-query file: the positional selects which query to run.
omnigraph query --store graph.omni --query queries.gq get_person --params '{"name":"Alice"}'

-e is mutually exclusive with --query <path>. With either, the positional name (optional) selects which query in the source to run. The inline source travels through the same parser, lint, params binding, and commit machinery as a file-based query — only the source loader changes.

Branching And Reviewable Data Flows

omnigraph branch create --uri graph.omni --from main feature-x
omnigraph branch list --uri graph.omni
omnigraph branch merge --uri graph.omni feature-x --into main

omnigraph load --data batch.jsonl --branch review/import-2026-04-09 --from main --mode merge graph.omni
omnigraph export graph.omni --branch main --type Person > people.jsonl
omnigraph commit list graph.omni --branch main --json
omnigraph commit show --uri graph.omni <commit-id> --json

Remote Server Mode

Serve a graph:

omnigraph-server graph.omni --bind 127.0.0.1:8080

Read through the HTTP API — invoke a stored query by name from the catalog:

omnigraph query get_person \
  --server http://127.0.0.1:8080 \
  --params '{"name":"Alice"}'

A server is addressed with --server (a name from ~/.omnigraph/config.yaml or a literal URL); a positional http(s):// URI is rejected. If the server requires auth, set its bearer token and omnigraph login <server> (or OMNIGRAPH_BEARER_TOKEN).

Multi-graph servers

A server boots from a cluster directory (omnigraph-server --cluster <dir>) and serves every graph the cluster declares. Use omnigraph graphs list to enumerate them. The cluster's server-level policy must allow graph_list; /graphs is closed by default even when the server runs with --unauthenticated.

OMNIGRAPH_BEARER_TOKEN=admin-token \
  omnigraph graphs list --server http://server.example.com --json

For an operator-defined server, store its token with omnigraph login <name> (or OMNIGRAPH_TOKEN_<NAME>); the actor must be authorized by the cluster's server-level policy.

list rejects local (--store) targets — it's for remote multi-graph servers only.

Runtime add/remove via API is not exposed. To add or remove a graph, edit the cluster's cluster.yaml, run omnigraph cluster apply, then restart the server.

Per-graph addressing: select a graph on a multi-graph server with --graph:

omnigraph query get_person --server http://server.example.com --graph beta --params '{"name":"Ada"}'

Runs, Policy, And Diagnostics

omnigraph lint  --query queries.gq --schema schema.pg --json
omnigraph check --query queries.gq graph.omni --json

omnigraph schema plan --schema next.pg graph.omni --json
omnigraph schema apply --schema next.pg graph.omni --json
omnigraph policy validate --cluster ./company-brain --graph knowledge
omnigraph policy test    --cluster ./company-brain --graph knowledge --tests policy.tests.yaml
omnigraph policy explain --cluster ./company-brain --graph knowledge --actor act-alice --action read --branch main

omnigraph commit list graph.omni --json
omnigraph commit show --uri graph.omni <commit-id> --json

(Mutations and loads publish atomically; the commit graph (omnigraph commit list) is the audit surface.)

query lint and query check are the same command surface. In v1, graph-backed lint uses local or s3:// graph URIs; HTTP targets are only supported when you also pass --schema.

Config

Configuration has two surfaces with single owners (see the CLI reference for the full schema):

  • ~/.omnigraph/config.yaml — your personal operator config: default actor (--as), named servers + credentials, clusters, profiles, aliases, and default scope (defaults.server / defaults.store / default_graph). It decides who you are and what you address by default.
  • cluster.yaml (a team-owned cluster directory) — declares what the system is: graphs, schemas, stored queries, policies, and storage. A server boots from it (--cluster <dir>); see the cluster guide.
# ~/.omnigraph/config.yaml
operator:
  actor: act-andrew
servers:
  dev:
    url: http://127.0.0.1:8080
defaults:
  server: dev
  default_graph: knowledge

When policy is enabled, schema apply is authorized through the schema_apply action and is typically limited to admins on protected main.

Deprecated names

The CLI was renamed to align with the HTTP server's canonical endpoint names (POST /query, POST /mutate) and the query keyword in the GQ language. The previous spellings keep working forever; invocations emit a one-line warning to stderr and otherwise behave identically.

Old (deprecated) New (canonical) Migration
omnigraph read omnigraph query Same flags and behavior. read is a visible clap alias.
omnigraph change omnigraph mutate Same flags and behavior. change is a visible clap alias.
omnigraph query lint omnigraph lint Same flags. The argv-level shim rewrites query lint to lint.
omnigraph query check omnigraph check check is a visible alias of omnigraph lint.

The command: field in aliases.<name> in ~/.omnigraph/config.yaml accepts both read / change (legacy) and query / mutate (canonical); the two spellings are interchangeable on the wire via serde aliases.