omnigraph/crates/omnigraph-cli/src/planes.rs

261 lines
10 KiB
Rust
Raw Normal View History

feat(cli): RFC-010 Slice 1 — declared plane capability surface + honest addressing (#217) * feat(cli): declared plane capability surface + wrong-plane guard (RFC-010 Slice 1) New `planes.rs` is the single source of truth for which plane each subcommand belongs to (Data / Storage / Control / Session). `command_plane` is an exhaustive match — adding a `Command` variant is a compile error until its plane is declared, so the surface cannot silently drift from the command set. It descends into the nested enums where the plane differs per subcommand (`schema plan` is storage while `schema show/apply` are data; `queries validate` opens the graph while `queries list` reads only config). `guard_addressing` runs once in `main` before dispatch: the data-plane addressing flags `--server`/`--graph` on any non-data verb now fail with one declared, pinned error instead of being silently ignored (`optimize --server prod` previously dropped `--server`). `init`'s message drops the `--target` half since it takes only a positional URI today. Test: `cli_schema_config::schema_plan_with_server_flag_errors_wrong_plane` pins the per-subcommand label, proving the guard descends into the nested enum. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * feat(cli): storage-plane verbs fail loudly on a remote target (RFC-010 Slice 1) `optimize`/`repair`/`cleanup` switch from `resolve_uri` to `resolve_local_uri`, so a `--target` (or positional URI) that resolves to a remote server now fails with a declared storage-plane message instead of whatever `Omnigraph::open` said about an `http(s)://` URI. The `resolve_local_graph` bail is reworded to that storage-plane message, so every storage verb already on the local resolver (`schema plan`, `queries validate`, `lint`) speaks with one voice. Net: `optimize --target knowledge` resolves to the graph's storage URI and runs embedded; `optimize --target prod` (remote) fails loudly; `optimize --server` is caught earlier by the guard. Positional-URI invocations are unchanged. Tests (pinned strings, per RFC-010's test plan): optimize happy path on a local graph, `optimize --server` wrong-plane error, `optimize <https>` storage-plane error; the existing `query_lint_rejects_http_targets_without_schema` assertion is updated to the new shared message. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-13 22:45:58 +03:00
//! Declared CLI "planes" (RFC-010 Slice 1).
//!
//! Every subcommand belongs to exactly one plane. This classification is the
//! single source of truth the wrong-plane guard consumes — and that later
//! RFC-010 slices (the capability surface, plane-grouped help) will consume
//! too. The `command_plane` match is **exhaustive on purpose**: adding a
//! `Command` variant is a compile error until its plane is declared, so the
//! surface cannot silently drift from the command set.
//!
//! See [docs/dev/rfc-010-cli-planes-restructure.md].
use color_eyre::Result;
use color_eyre::eyre::bail;
use crate::cli::{Cli, Command, QueriesCommand, SchemaCommand};
#[derive(Debug, Clone, Copy, PartialEq, Eq)]
pub(crate) enum Plane {
/// Runs against a graph, embedded **or** via `--server` (the `GraphClient`
/// axis). The only plane on which the data-plane addressing flags
/// (`--server`/`--graph`) apply.
Data,
/// Direct storage access; no server. Maintenance + local-only inspection
/// that must work with the server down.
Storage,
/// Operates on a cluster directory, not a graph URI.
Control,
/// Touches no graph at all — session / config / local tooling.
Session,
}
impl std::fmt::Display for Plane {
fn fmt(&self, f: &mut std::fmt::Formatter<'_>) -> std::fmt::Result {
f.write_str(match self {
Plane::Data => "data",
Plane::Storage => "storage",
Plane::Control => "control",
Plane::Session => "session",
})
}
}
feat(cli): RFC-011 Slice B — capability vocabulary (any/served/direct/control/local) (#237) * feat(cli): RFC-011 Slice B — capability vocabulary (any/served/direct/control/local) User-facing CLI errors and --help now speak a single "capability" vocabulary — what a command needs — instead of the internal four-plane jargon. Behavior is unchanged: the --server/--graph allow set is identical (the served-graph capabilities `any` ∪ `served` = the old `Data` plane, since `graphs` was already allowed). Only error text and the --help legend change. - planes.rs: add `Capability { Any, Served, Direct, Control, Local }` derived from the existing exhaustive `command_plane` classifier (which stays as the drift guard) plus the one Data→Served refinement (`graphs`). `guard_addressing` now allows `--server`/`--graph` on `{Any, Served}` and rejects elsewhere with a capability-worded message. The mapping reflects *current* behavior (`queries list` → Local, `queries validate` → Direct); it converges to the RFC end-state table when later slices re-route those verbs. - scope.rs: `resolve_scope` takes `Capability` instead of `Plane`, so the whole addressing path speaks one vocabulary; call sites in client.rs (Any) and the 3 maintenance verbs in main.rs (Direct) updated. - helpers.rs: the storage-direct remote rejection reworded to "direct (storage-native) command". - cli.rs: the --help legend is now "COMMANDS BY CAPABILITY". - Tests: the 5 assertions pinning the old plane text updated; added planes.rs unit tests proving the allow set is exactly {Any, Served} (behavior-preservation), the per-verb mapping, and distinct capability phrases. Full omnigraph-cli suite: 225 green (222 + 3 new), zero behavior-test changes. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * docs(cli): capability vocabulary in the CLI reference + maintenance addressing Rename the reference's "Command planes" section to "Command capabilities" (any/served/direct/control/local), reword the error examples, and update the maintenance doc's addressing note + its section cross-link to match Slice B. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-15 03:02:07 +03:00
/// What a command *needs*, in the user-facing vocabulary (RFC-011). This is the
/// language CLI errors and `--help` speak; `Plane` stays the internal classifier
/// (`Capability` is derived from it, so the two cannot drift).
///
/// - `any` — graph-scoped data; served via a server scope, or direct against a
/// store scope. Accepts `--server`/`--graph`.
/// - `served` — requires a server. Accepts `--server`/`--graph`.
/// - `direct` — storage-native; opens storage directly, never through a server.
/// - `control` — operates on a cluster (control plane).
/// - `local` — addresses no graph at all.
#[derive(Debug, Clone, Copy, PartialEq, Eq)]
pub(crate) enum Capability {
Any,
Served,
Direct,
Control,
Local,
}
impl Capability {
/// A human phrase for error messages (`` `optimize` is a {…} command ``).
pub(crate) fn describe(self) -> &'static str {
match self {
Capability::Any => "data",
Capability::Served => "served",
Capability::Direct => "direct (storage-native)",
Capability::Control => "cluster control",
Capability::Local => "local",
}
}
/// `--server`/`--graph` are served-graph addressing: they apply only to the
/// capabilities that reach a graph through a server.
fn accepts_server_addressing(self) -> bool {
matches!(self, Capability::Any | Capability::Served)
}
}
/// The capability a subcommand needs, derived from its `Plane` (the exhaustive
/// classifier) plus the one Data→Served refinement: `graphs` is remote-only.
///
/// This reflects *current enforced behavior*, so messages stay truthful:
/// `queries list` is `Local` (reads config today) and `queries validate` is
/// `Direct` (opens a graph directly today). Both converge to the RFC end-state
/// (served / control) only when later slices re-route them.
pub(crate) fn command_capability(cmd: &Command) -> Capability {
if let Command::Graphs { .. } = cmd {
return Capability::Served;
}
match command_plane(cmd) {
Plane::Data => Capability::Any,
Plane::Storage => Capability::Direct,
Plane::Control => Capability::Control,
Plane::Session => Capability::Local,
}
}
feat(cli): RFC-010 Slice 1 — declared plane capability surface + honest addressing (#217) * feat(cli): declared plane capability surface + wrong-plane guard (RFC-010 Slice 1) New `planes.rs` is the single source of truth for which plane each subcommand belongs to (Data / Storage / Control / Session). `command_plane` is an exhaustive match — adding a `Command` variant is a compile error until its plane is declared, so the surface cannot silently drift from the command set. It descends into the nested enums where the plane differs per subcommand (`schema plan` is storage while `schema show/apply` are data; `queries validate` opens the graph while `queries list` reads only config). `guard_addressing` runs once in `main` before dispatch: the data-plane addressing flags `--server`/`--graph` on any non-data verb now fail with one declared, pinned error instead of being silently ignored (`optimize --server prod` previously dropped `--server`). `init`'s message drops the `--target` half since it takes only a positional URI today. Test: `cli_schema_config::schema_plan_with_server_flag_errors_wrong_plane` pins the per-subcommand label, proving the guard descends into the nested enum. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * feat(cli): storage-plane verbs fail loudly on a remote target (RFC-010 Slice 1) `optimize`/`repair`/`cleanup` switch from `resolve_uri` to `resolve_local_uri`, so a `--target` (or positional URI) that resolves to a remote server now fails with a declared storage-plane message instead of whatever `Omnigraph::open` said about an `http(s)://` URI. The `resolve_local_graph` bail is reworded to that storage-plane message, so every storage verb already on the local resolver (`schema plan`, `queries validate`, `lint`) speaks with one voice. Net: `optimize --target knowledge` resolves to the graph's storage URI and runs embedded; `optimize --target prod` (remote) fails loudly; `optimize --server` is caught earlier by the guard. Positional-URI invocations are unchanged. Tests (pinned strings, per RFC-010's test plan): optimize happy path on a local graph, `optimize --server` wrong-plane error, `optimize <https>` storage-plane error; the existing `query_lint_rejects_http_targets_without_schema` assertion is updated to the new shared message. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-13 22:45:58 +03:00
/// The plane a subcommand belongs to. Exhaustive — a new `Command` variant
/// will not compile until classified. Descends into the nested enums where
/// the plane differs per subcommand (`schema plan` is storage while `schema
/// show`/`apply` are data; `queries validate` opens the graph while `queries
/// list` only reads config).
pub(crate) fn command_plane(cmd: &Command) -> Plane {
match cmd {
Command::Query { .. }
| Command::Mutate { .. }
| Command::Load { .. }
| Command::Ingest { .. }
| Command::Branch { .. }
| Command::Snapshot { .. }
| Command::Export { .. }
| Command::Commit { .. }
| Command::Graphs { .. } => Plane::Data,
Command::Schema {
command: SchemaCommand::Show { .. } | SchemaCommand::Apply { .. },
} => Plane::Data,
Command::Schema {
command: SchemaCommand::Plan { .. },
} => Plane::Storage,
Command::Queries {
command: QueriesCommand::Validate { .. },
} => Plane::Storage,
Command::Queries {
command: QueriesCommand::List { .. },
} => Plane::Session,
Command::Init { .. }
| Command::Optimize { .. }
| Command::Repair { .. }
| Command::Cleanup { .. }
| Command::Lint { .. } => Plane::Storage,
Command::Cluster { .. } => Plane::Control,
Command::Policy { .. }
| Command::Embed(_)
| Command::Login { .. }
| Command::Logout { .. }
| Command::Config { .. }
| Command::Version => Plane::Session,
}
}
/// User-facing label for a subcommand (descends one level for the nested
/// families so messages read `schema plan`, `queries validate`, etc.).
pub(crate) fn command_label(cmd: &Command) -> &'static str {
match cmd {
Command::Version => "version",
Command::Login { .. } => "login",
Command::Logout { .. } => "logout",
Command::Config { .. } => "config",
Command::Embed(_) => "embed",
Command::Init { .. } => "init",
Command::Load { .. } => "load",
Command::Ingest { .. } => "ingest",
Command::Branch { .. } => "branch",
Command::Schema { command } => match command {
SchemaCommand::Plan { .. } => "schema plan",
SchemaCommand::Apply { .. } => "schema apply",
SchemaCommand::Show { .. } => "schema show",
},
Command::Lint { .. } => "lint",
Command::Queries { command } => match command {
QueriesCommand::Validate { .. } => "queries validate",
QueriesCommand::List { .. } => "queries list",
},
Command::Snapshot { .. } => "snapshot",
Command::Export { .. } => "export",
Command::Commit { .. } => "commit",
Command::Query { .. } => "query",
Command::Mutate { .. } => "mutate",
Command::Policy { .. } => "policy",
Command::Optimize { .. } => "optimize",
Command::Repair { .. } => "repair",
Command::Cleanup { .. } => "cleanup",
Command::Cluster { .. } => "cluster",
Command::Graphs { .. } => "graphs",
}
}
/// Reject the data-plane addressing flags (`--server`/`--graph`) on any verb
/// that does not live on the data plane. This replaces the old silent-ignore
/// — e.g. `optimize --server prod` previously dropped `--server` and tried to
/// resolve a default target, failing (if at all) with an unrelated message.
/// Now it fails with one honest, declared error. RFC-010 Slice 1.
pub(crate) fn guard_addressing(cli: &Cli) -> Result<()> {
if cli.server.is_none() && cli.graph.is_none() {
return Ok(());
}
feat(cli): RFC-011 Slice B — capability vocabulary (any/served/direct/control/local) (#237) * feat(cli): RFC-011 Slice B — capability vocabulary (any/served/direct/control/local) User-facing CLI errors and --help now speak a single "capability" vocabulary — what a command needs — instead of the internal four-plane jargon. Behavior is unchanged: the --server/--graph allow set is identical (the served-graph capabilities `any` ∪ `served` = the old `Data` plane, since `graphs` was already allowed). Only error text and the --help legend change. - planes.rs: add `Capability { Any, Served, Direct, Control, Local }` derived from the existing exhaustive `command_plane` classifier (which stays as the drift guard) plus the one Data→Served refinement (`graphs`). `guard_addressing` now allows `--server`/`--graph` on `{Any, Served}` and rejects elsewhere with a capability-worded message. The mapping reflects *current* behavior (`queries list` → Local, `queries validate` → Direct); it converges to the RFC end-state table when later slices re-route those verbs. - scope.rs: `resolve_scope` takes `Capability` instead of `Plane`, so the whole addressing path speaks one vocabulary; call sites in client.rs (Any) and the 3 maintenance verbs in main.rs (Direct) updated. - helpers.rs: the storage-direct remote rejection reworded to "direct (storage-native) command". - cli.rs: the --help legend is now "COMMANDS BY CAPABILITY". - Tests: the 5 assertions pinning the old plane text updated; added planes.rs unit tests proving the allow set is exactly {Any, Served} (behavior-preservation), the per-verb mapping, and distinct capability phrases. Full omnigraph-cli suite: 225 green (222 + 3 new), zero behavior-test changes. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * docs(cli): capability vocabulary in the CLI reference + maintenance addressing Rename the reference's "Command planes" section to "Command capabilities" (any/served/direct/control/local), reword the error examples, and update the maintenance doc's addressing note + its section cross-link to match Slice B. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-15 03:02:07 +03:00
let capability = command_capability(&cli.command);
if capability.accepts_server_addressing() {
feat(cli): RFC-010 Slice 1 — declared plane capability surface + honest addressing (#217) * feat(cli): declared plane capability surface + wrong-plane guard (RFC-010 Slice 1) New `planes.rs` is the single source of truth for which plane each subcommand belongs to (Data / Storage / Control / Session). `command_plane` is an exhaustive match — adding a `Command` variant is a compile error until its plane is declared, so the surface cannot silently drift from the command set. It descends into the nested enums where the plane differs per subcommand (`schema plan` is storage while `schema show/apply` are data; `queries validate` opens the graph while `queries list` reads only config). `guard_addressing` runs once in `main` before dispatch: the data-plane addressing flags `--server`/`--graph` on any non-data verb now fail with one declared, pinned error instead of being silently ignored (`optimize --server prod` previously dropped `--server`). `init`'s message drops the `--target` half since it takes only a positional URI today. Test: `cli_schema_config::schema_plan_with_server_flag_errors_wrong_plane` pins the per-subcommand label, proving the guard descends into the nested enum. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * feat(cli): storage-plane verbs fail loudly on a remote target (RFC-010 Slice 1) `optimize`/`repair`/`cleanup` switch from `resolve_uri` to `resolve_local_uri`, so a `--target` (or positional URI) that resolves to a remote server now fails with a declared storage-plane message instead of whatever `Omnigraph::open` said about an `http(s)://` URI. The `resolve_local_graph` bail is reworded to that storage-plane message, so every storage verb already on the local resolver (`schema plan`, `queries validate`, `lint`) speaks with one voice. Net: `optimize --target knowledge` resolves to the graph's storage URI and runs embedded; `optimize --target prod` (remote) fails loudly; `optimize --server` is caught earlier by the guard. Positional-URI invocations are unchanged. Tests (pinned strings, per RFC-010's test plan): optimize happy path on a local graph, `optimize --server` wrong-plane error, `optimize <https>` storage-plane error; the existing `query_lint_rejects_http_targets_without_schema` assertion is updated to the new shared message. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-13 22:45:58 +03:00
return Ok(());
}
let label = command_label(&cli.command);
feat(cli): RFC-011 Slice B — capability vocabulary (any/served/direct/control/local) (#237) * feat(cli): RFC-011 Slice B — capability vocabulary (any/served/direct/control/local) User-facing CLI errors and --help now speak a single "capability" vocabulary — what a command needs — instead of the internal four-plane jargon. Behavior is unchanged: the --server/--graph allow set is identical (the served-graph capabilities `any` ∪ `served` = the old `Data` plane, since `graphs` was already allowed). Only error text and the --help legend change. - planes.rs: add `Capability { Any, Served, Direct, Control, Local }` derived from the existing exhaustive `command_plane` classifier (which stays as the drift guard) plus the one Data→Served refinement (`graphs`). `guard_addressing` now allows `--server`/`--graph` on `{Any, Served}` and rejects elsewhere with a capability-worded message. The mapping reflects *current* behavior (`queries list` → Local, `queries validate` → Direct); it converges to the RFC end-state table when later slices re-route those verbs. - scope.rs: `resolve_scope` takes `Capability` instead of `Plane`, so the whole addressing path speaks one vocabulary; call sites in client.rs (Any) and the 3 maintenance verbs in main.rs (Direct) updated. - helpers.rs: the storage-direct remote rejection reworded to "direct (storage-native) command". - cli.rs: the --help legend is now "COMMANDS BY CAPABILITY". - Tests: the 5 assertions pinning the old plane text updated; added planes.rs unit tests proving the allow set is exactly {Any, Served} (behavior-preservation), the per-verb mapping, and distinct capability phrases. Full omnigraph-cli suite: 225 green (222 + 3 new), zero behavior-test changes. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * docs(cli): capability vocabulary in the CLI reference + maintenance addressing Rename the reference's "Command planes" section to "Command capabilities" (any/served/direct/control/local), reword the error examples, and update the maintenance doc's addressing note + its section cross-link to match Slice B. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-15 03:02:07 +03:00
let how = match capability {
// `init` is the one direct verb with no `--target` today (it takes a
feat(cli): RFC-010 Slice 1 — declared plane capability surface + honest addressing (#217) * feat(cli): declared plane capability surface + wrong-plane guard (RFC-010 Slice 1) New `planes.rs` is the single source of truth for which plane each subcommand belongs to (Data / Storage / Control / Session). `command_plane` is an exhaustive match — adding a `Command` variant is a compile error until its plane is declared, so the surface cannot silently drift from the command set. It descends into the nested enums where the plane differs per subcommand (`schema plan` is storage while `schema show/apply` are data; `queries validate` opens the graph while `queries list` reads only config). `guard_addressing` runs once in `main` before dispatch: the data-plane addressing flags `--server`/`--graph` on any non-data verb now fail with one declared, pinned error instead of being silently ignored (`optimize --server prod` previously dropped `--server`). `init`'s message drops the `--target` half since it takes only a positional URI today. Test: `cli_schema_config::schema_plan_with_server_flag_errors_wrong_plane` pins the per-subcommand label, proving the guard descends into the nested enum. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * feat(cli): storage-plane verbs fail loudly on a remote target (RFC-010 Slice 1) `optimize`/`repair`/`cleanup` switch from `resolve_uri` to `resolve_local_uri`, so a `--target` (or positional URI) that resolves to a remote server now fails with a declared storage-plane message instead of whatever `Omnigraph::open` said about an `http(s)://` URI. The `resolve_local_graph` bail is reworded to that storage-plane message, so every storage verb already on the local resolver (`schema plan`, `queries validate`, `lint`) speaks with one voice. Net: `optimize --target knowledge` resolves to the graph's storage URI and runs embedded; `optimize --target prod` (remote) fails loudly; `optimize --server` is caught earlier by the guard. Positional-URI invocations are unchanged. Tests (pinned strings, per RFC-010's test plan): optimize happy path on a local graph, `optimize --server` wrong-plane error, `optimize <https>` storage-plane error; the existing `query_lint_rejects_http_targets_without_schema` assertion is updated to the new shared message. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-13 22:45:58 +03:00
// required positional URI), so its remediation drops the `--target` half.
feat(cli): RFC-011 Slice B — capability vocabulary (any/served/direct/control/local) (#237) * feat(cli): RFC-011 Slice B — capability vocabulary (any/served/direct/control/local) User-facing CLI errors and --help now speak a single "capability" vocabulary — what a command needs — instead of the internal four-plane jargon. Behavior is unchanged: the --server/--graph allow set is identical (the served-graph capabilities `any` ∪ `served` = the old `Data` plane, since `graphs` was already allowed). Only error text and the --help legend change. - planes.rs: add `Capability { Any, Served, Direct, Control, Local }` derived from the existing exhaustive `command_plane` classifier (which stays as the drift guard) plus the one Data→Served refinement (`graphs`). `guard_addressing` now allows `--server`/`--graph` on `{Any, Served}` and rejects elsewhere with a capability-worded message. The mapping reflects *current* behavior (`queries list` → Local, `queries validate` → Direct); it converges to the RFC end-state table when later slices re-route those verbs. - scope.rs: `resolve_scope` takes `Capability` instead of `Plane`, so the whole addressing path speaks one vocabulary; call sites in client.rs (Any) and the 3 maintenance verbs in main.rs (Direct) updated. - helpers.rs: the storage-direct remote rejection reworded to "direct (storage-native) command". - cli.rs: the --help legend is now "COMMANDS BY CAPABILITY". - Tests: the 5 assertions pinning the old plane text updated; added planes.rs unit tests proving the allow set is exactly {Any, Served} (behavior-preservation), the per-verb mapping, and distinct capability phrases. Full omnigraph-cli suite: 225 green (222 + 3 new), zero behavior-test changes. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * docs(cli): capability vocabulary in the CLI reference + maintenance addressing Rename the reference's "Command planes" section to "Command capabilities" (any/served/direct/control/local), reword the error examples, and update the maintenance doc's addressing note + its section cross-link to match Slice B. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-15 03:02:07 +03:00
Capability::Direct => match cli.command {
feat(cli): RFC-010 Slice 1 — declared plane capability surface + honest addressing (#217) * feat(cli): declared plane capability surface + wrong-plane guard (RFC-010 Slice 1) New `planes.rs` is the single source of truth for which plane each subcommand belongs to (Data / Storage / Control / Session). `command_plane` is an exhaustive match — adding a `Command` variant is a compile error until its plane is declared, so the surface cannot silently drift from the command set. It descends into the nested enums where the plane differs per subcommand (`schema plan` is storage while `schema show/apply` are data; `queries validate` opens the graph while `queries list` reads only config). `guard_addressing` runs once in `main` before dispatch: the data-plane addressing flags `--server`/`--graph` on any non-data verb now fail with one declared, pinned error instead of being silently ignored (`optimize --server prod` previously dropped `--server`). `init`'s message drops the `--target` half since it takes only a positional URI today. Test: `cli_schema_config::schema_plan_with_server_flag_errors_wrong_plane` pins the per-subcommand label, proving the guard descends into the nested enum. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * feat(cli): storage-plane verbs fail loudly on a remote target (RFC-010 Slice 1) `optimize`/`repair`/`cleanup` switch from `resolve_uri` to `resolve_local_uri`, so a `--target` (or positional URI) that resolves to a remote server now fails with a declared storage-plane message instead of whatever `Omnigraph::open` said about an `http(s)://` URI. The `resolve_local_graph` bail is reworded to that storage-plane message, so every storage verb already on the local resolver (`schema plan`, `queries validate`, `lint`) speaks with one voice. Net: `optimize --target knowledge` resolves to the graph's storage URI and runs embedded; `optimize --target prod` (remote) fails loudly; `optimize --server` is caught earlier by the guard. Positional-URI invocations are unchanged. Tests (pinned strings, per RFC-010's test plan): optimize happy path on a local graph, `optimize --server` wrong-plane error, `optimize <https>` storage-plane error; the existing `query_lint_rejects_http_targets_without_schema` assertion is updated to the new shared message. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-13 22:45:58 +03:00
Command::Init { .. } => "Pass a storage URI.",
feat(cli): cluster-managed maintenance addressing + init signpost (RFC-010 Slice 3) (#221) * feat(cluster): cluster_root_for_graph_uri detection helper (RFC-010 Slice 3) Public helper the CLI uses to refuse `init` into a cluster-managed location: given a graph storage URI of the cluster layout (`<root>/graphs/<id>.omni`), return the cluster root if `<root>` holds `__cluster/state.json`, else None. Cheap by construction — a URI that doesn't match the `<root>/graphs/<id>.omni` shape returns None with zero I/O, so ordinary `init` targets never probe storage. Works for file:// and s3:// via the storage adapter. Adds two ClusterStore accessors (`display_root`, `has_state`). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * feat(cli): cluster-managed maintenance addressing + init signpost (RFC-010 Slice 3) Two cluster-graph-aware CLI behaviors, sharing the cluster-resolution path. Maintenance addressing. `optimize`/`repair`/`cleanup` gain `--cluster <dir|s3://…> --cluster-graph <id>`, which resolves the graph's storage URI from the served cluster snapshot (the same truth a `--cluster` server boots from — `read_serving_snapshot*`) and opens it embedded. The operator no longer hand-types `<storage>/graphs/<id>.omni`. A distinct flag is required because the global `--graph` is `requires = server` and means a remote multi-graph id. clap enforces both-or-neither and exclusion with the positional URI / `--target`; an unserved graph errors loudly, pointing at `cluster apply`. init signpost. `init` refuses a cluster-managed positional path (the `<root>/graphs/<id>.omni` layout where `<root>` holds `__cluster/state.json`, detected by `cluster_root_for_graph_uri`) and points at `cluster apply` — graphs in an established cluster are created with ledger/recovery/approvals, not by hand. The check is gated on the path shape, so ordinary `init` does no extra I/O and existing pre-apply cluster-graph inits are unaffected. planes guard remediation now also mentions `--cluster … --cluster-graph …` (the two Slice-1 guard-string tests track it). Docs updated (cli-reference Command planes, maintenance.md, cluster.md §7); the stale "no S3-hosted cluster directories" limitation is dropped (RFC-006 landed it). Tests (cli_cluster.rs, reusing the apply-a-cluster fixture): resolve by id, unknown-id error, `--cluster` requires `--cluster-graph`, init refusal + signpost, and ordinary init still works. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * fix(cli): resolve cluster graphs from the state ledger, not the serving snapshot Addresses the Greptile review on #221. `read_serving_snapshot*` does all-or-nothing serving validation — recovery-sidecar checks plus a digest verify of every catalog payload (query .gq, policy blobs). Using it to resolve a maintenance target coupled `optimize`/`repair`/`cleanup` to the readiness of unrelated resources: a single corrupt policy blob, or a pending recovery sweep, would block the command before it could touch the graph — worst for `repair`, the tool you reach for *when the cluster is degraded*. Add `omnigraph_cluster::resolve_graph_storage_uri(cluster, graph_id)`: read the state ledger, confirm the graph is in the applied revision, return `graph_root(id)` — the URI is deterministically derivable, no catalog validation. The CLI's cluster resolver now calls it. Test: `optimize --cluster … --cluster-graph …` still resolves after the catalog payloads (`__cluster/resources/`) are removed — the ledger-only path is not blocked by degraded/unrelated catalog state. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-14 02:52:21 +03:00
_ => "Use --target <name>, a storage URI, or --cluster <dir> --cluster-graph <id>.",
feat(cli): RFC-010 Slice 1 — declared plane capability surface + honest addressing (#217) * feat(cli): declared plane capability surface + wrong-plane guard (RFC-010 Slice 1) New `planes.rs` is the single source of truth for which plane each subcommand belongs to (Data / Storage / Control / Session). `command_plane` is an exhaustive match — adding a `Command` variant is a compile error until its plane is declared, so the surface cannot silently drift from the command set. It descends into the nested enums where the plane differs per subcommand (`schema plan` is storage while `schema show/apply` are data; `queries validate` opens the graph while `queries list` reads only config). `guard_addressing` runs once in `main` before dispatch: the data-plane addressing flags `--server`/`--graph` on any non-data verb now fail with one declared, pinned error instead of being silently ignored (`optimize --server prod` previously dropped `--server`). `init`'s message drops the `--target` half since it takes only a positional URI today. Test: `cli_schema_config::schema_plan_with_server_flag_errors_wrong_plane` pins the per-subcommand label, proving the guard descends into the nested enum. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * feat(cli): storage-plane verbs fail loudly on a remote target (RFC-010 Slice 1) `optimize`/`repair`/`cleanup` switch from `resolve_uri` to `resolve_local_uri`, so a `--target` (or positional URI) that resolves to a remote server now fails with a declared storage-plane message instead of whatever `Omnigraph::open` said about an `http(s)://` URI. The `resolve_local_graph` bail is reworded to that storage-plane message, so every storage verb already on the local resolver (`schema plan`, `queries validate`, `lint`) speaks with one voice. Net: `optimize --target knowledge` resolves to the graph's storage URI and runs embedded; `optimize --target prod` (remote) fails loudly; `optimize --server` is caught earlier by the guard. Positional-URI invocations are unchanged. Tests (pinned strings, per RFC-010's test plan): optimize happy path on a local graph, `optimize --server` wrong-plane error, `optimize <https>` storage-plane error; the existing `query_lint_rejects_http_targets_without_schema` assertion is updated to the new shared message. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-13 22:45:58 +03:00
},
feat(cli): RFC-011 Slice B — capability vocabulary (any/served/direct/control/local) (#237) * feat(cli): RFC-011 Slice B — capability vocabulary (any/served/direct/control/local) User-facing CLI errors and --help now speak a single "capability" vocabulary — what a command needs — instead of the internal four-plane jargon. Behavior is unchanged: the --server/--graph allow set is identical (the served-graph capabilities `any` ∪ `served` = the old `Data` plane, since `graphs` was already allowed). Only error text and the --help legend change. - planes.rs: add `Capability { Any, Served, Direct, Control, Local }` derived from the existing exhaustive `command_plane` classifier (which stays as the drift guard) plus the one Data→Served refinement (`graphs`). `guard_addressing` now allows `--server`/`--graph` on `{Any, Served}` and rejects elsewhere with a capability-worded message. The mapping reflects *current* behavior (`queries list` → Local, `queries validate` → Direct); it converges to the RFC end-state table when later slices re-route those verbs. - scope.rs: `resolve_scope` takes `Capability` instead of `Plane`, so the whole addressing path speaks one vocabulary; call sites in client.rs (Any) and the 3 maintenance verbs in main.rs (Direct) updated. - helpers.rs: the storage-direct remote rejection reworded to "direct (storage-native) command". - cli.rs: the --help legend is now "COMMANDS BY CAPABILITY". - Tests: the 5 assertions pinning the old plane text updated; added planes.rs unit tests proving the allow set is exactly {Any, Served} (behavior-preservation), the per-verb mapping, and distinct capability phrases. Full omnigraph-cli suite: 225 green (222 + 3 new), zero behavior-test changes. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * docs(cli): capability vocabulary in the CLI reference + maintenance addressing Rename the reference's "Command planes" section to "Command capabilities" (any/served/direct/control/local), reword the error examples, and update the maintenance doc's addressing note + its section cross-link to match Slice B. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-15 03:02:07 +03:00
Capability::Control => "It operates on a cluster (pass --config <dir>).",
Capability::Local => "It does not address a graph.",
Capability::Any | Capability::Served => {
unreachable!("served-addressing capabilities returned early")
}
feat(cli): RFC-010 Slice 1 — declared plane capability surface + honest addressing (#217) * feat(cli): declared plane capability surface + wrong-plane guard (RFC-010 Slice 1) New `planes.rs` is the single source of truth for which plane each subcommand belongs to (Data / Storage / Control / Session). `command_plane` is an exhaustive match — adding a `Command` variant is a compile error until its plane is declared, so the surface cannot silently drift from the command set. It descends into the nested enums where the plane differs per subcommand (`schema plan` is storage while `schema show/apply` are data; `queries validate` opens the graph while `queries list` reads only config). `guard_addressing` runs once in `main` before dispatch: the data-plane addressing flags `--server`/`--graph` on any non-data verb now fail with one declared, pinned error instead of being silently ignored (`optimize --server prod` previously dropped `--server`). `init`'s message drops the `--target` half since it takes only a positional URI today. Test: `cli_schema_config::schema_plan_with_server_flag_errors_wrong_plane` pins the per-subcommand label, proving the guard descends into the nested enum. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * feat(cli): storage-plane verbs fail loudly on a remote target (RFC-010 Slice 1) `optimize`/`repair`/`cleanup` switch from `resolve_uri` to `resolve_local_uri`, so a `--target` (or positional URI) that resolves to a remote server now fails with a declared storage-plane message instead of whatever `Omnigraph::open` said about an `http(s)://` URI. The `resolve_local_graph` bail is reworded to that storage-plane message, so every storage verb already on the local resolver (`schema plan`, `queries validate`, `lint`) speaks with one voice. Net: `optimize --target knowledge` resolves to the graph's storage URI and runs embedded; `optimize --target prod` (remote) fails loudly; `optimize --server` is caught earlier by the guard. Positional-URI invocations are unchanged. Tests (pinned strings, per RFC-010's test plan): optimize happy path on a local graph, `optimize --server` wrong-plane error, `optimize <https>` storage-plane error; the existing `query_lint_rejects_http_targets_without_schema` assertion is updated to the new shared message. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-13 22:45:58 +03:00
};
bail!(
feat(cli): RFC-011 Slice B — capability vocabulary (any/served/direct/control/local) (#237) * feat(cli): RFC-011 Slice B — capability vocabulary (any/served/direct/control/local) User-facing CLI errors and --help now speak a single "capability" vocabulary — what a command needs — instead of the internal four-plane jargon. Behavior is unchanged: the --server/--graph allow set is identical (the served-graph capabilities `any` ∪ `served` = the old `Data` plane, since `graphs` was already allowed). Only error text and the --help legend change. - planes.rs: add `Capability { Any, Served, Direct, Control, Local }` derived from the existing exhaustive `command_plane` classifier (which stays as the drift guard) plus the one Data→Served refinement (`graphs`). `guard_addressing` now allows `--server`/`--graph` on `{Any, Served}` and rejects elsewhere with a capability-worded message. The mapping reflects *current* behavior (`queries list` → Local, `queries validate` → Direct); it converges to the RFC end-state table when later slices re-route those verbs. - scope.rs: `resolve_scope` takes `Capability` instead of `Plane`, so the whole addressing path speaks one vocabulary; call sites in client.rs (Any) and the 3 maintenance verbs in main.rs (Direct) updated. - helpers.rs: the storage-direct remote rejection reworded to "direct (storage-native) command". - cli.rs: the --help legend is now "COMMANDS BY CAPABILITY". - Tests: the 5 assertions pinning the old plane text updated; added planes.rs unit tests proving the allow set is exactly {Any, Served} (behavior-preservation), the per-verb mapping, and distinct capability phrases. Full omnigraph-cli suite: 225 green (222 + 3 new), zero behavior-test changes. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * docs(cli): capability vocabulary in the CLI reference + maintenance addressing Rename the reference's "Command planes" section to "Command capabilities" (any/served/direct/control/local), reword the error examples, and update the maintenance doc's addressing note + its section cross-link to match Slice B. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-15 03:02:07 +03:00
"`{label}` is a {} command; --server/--graph address a served graph and do not apply. {how}",
capability.describe()
feat(cli): RFC-010 Slice 1 — declared plane capability surface + honest addressing (#217) * feat(cli): declared plane capability surface + wrong-plane guard (RFC-010 Slice 1) New `planes.rs` is the single source of truth for which plane each subcommand belongs to (Data / Storage / Control / Session). `command_plane` is an exhaustive match — adding a `Command` variant is a compile error until its plane is declared, so the surface cannot silently drift from the command set. It descends into the nested enums where the plane differs per subcommand (`schema plan` is storage while `schema show/apply` are data; `queries validate` opens the graph while `queries list` reads only config). `guard_addressing` runs once in `main` before dispatch: the data-plane addressing flags `--server`/`--graph` on any non-data verb now fail with one declared, pinned error instead of being silently ignored (`optimize --server prod` previously dropped `--server`). `init`'s message drops the `--target` half since it takes only a positional URI today. Test: `cli_schema_config::schema_plan_with_server_flag_errors_wrong_plane` pins the per-subcommand label, proving the guard descends into the nested enum. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * feat(cli): storage-plane verbs fail loudly on a remote target (RFC-010 Slice 1) `optimize`/`repair`/`cleanup` switch from `resolve_uri` to `resolve_local_uri`, so a `--target` (or positional URI) that resolves to a remote server now fails with a declared storage-plane message instead of whatever `Omnigraph::open` said about an `http(s)://` URI. The `resolve_local_graph` bail is reworded to that storage-plane message, so every storage verb already on the local resolver (`schema plan`, `queries validate`, `lint`) speaks with one voice. Net: `optimize --target knowledge` resolves to the graph's storage URI and runs embedded; `optimize --target prod` (remote) fails loudly; `optimize --server` is caught earlier by the guard. Positional-URI invocations are unchanged. Tests (pinned strings, per RFC-010's test plan): optimize happy path on a local graph, `optimize --server` wrong-plane error, `optimize <https>` storage-plane error; the existing `query_lint_rejects_http_targets_without_schema` assertion is updated to the new shared message. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-13 22:45:58 +03:00
);
}
feat(cli): RFC-011 Slice B — capability vocabulary (any/served/direct/control/local) (#237) * feat(cli): RFC-011 Slice B — capability vocabulary (any/served/direct/control/local) User-facing CLI errors and --help now speak a single "capability" vocabulary — what a command needs — instead of the internal four-plane jargon. Behavior is unchanged: the --server/--graph allow set is identical (the served-graph capabilities `any` ∪ `served` = the old `Data` plane, since `graphs` was already allowed). Only error text and the --help legend change. - planes.rs: add `Capability { Any, Served, Direct, Control, Local }` derived from the existing exhaustive `command_plane` classifier (which stays as the drift guard) plus the one Data→Served refinement (`graphs`). `guard_addressing` now allows `--server`/`--graph` on `{Any, Served}` and rejects elsewhere with a capability-worded message. The mapping reflects *current* behavior (`queries list` → Local, `queries validate` → Direct); it converges to the RFC end-state table when later slices re-route those verbs. - scope.rs: `resolve_scope` takes `Capability` instead of `Plane`, so the whole addressing path speaks one vocabulary; call sites in client.rs (Any) and the 3 maintenance verbs in main.rs (Direct) updated. - helpers.rs: the storage-direct remote rejection reworded to "direct (storage-native) command". - cli.rs: the --help legend is now "COMMANDS BY CAPABILITY". - Tests: the 5 assertions pinning the old plane text updated; added planes.rs unit tests proving the allow set is exactly {Any, Served} (behavior-preservation), the per-verb mapping, and distinct capability phrases. Full omnigraph-cli suite: 225 green (222 + 3 new), zero behavior-test changes. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * docs(cli): capability vocabulary in the CLI reference + maintenance addressing Rename the reference's "Command planes" section to "Command capabilities" (any/served/direct/control/local), reword the error examples, and update the maintenance doc's addressing note + its section cross-link to match Slice B. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-15 03:02:07 +03:00
#[cfg(test)]
mod tests {
use clap::Parser;
use super::*;
#[test]
fn server_addressing_allowed_exactly_on_any_and_served() {
// The behavior-preservation contract: `--server`/`--graph` apply to the
// served-graph capabilities (`any`, `served`) and nothing else. This is
// the old "Data plane only" allow set, re-expressed — graphs (the one
// Data→Served verb) was already allowed.
assert!(Capability::Any.accepts_server_addressing());
assert!(Capability::Served.accepts_server_addressing());
assert!(!Capability::Direct.accepts_server_addressing());
assert!(!Capability::Control.accepts_server_addressing());
assert!(!Capability::Local.accepts_server_addressing());
}
#[test]
fn command_capability_classifies_representative_verbs() {
let cap = |args: &[&str]| {
command_capability(&Cli::try_parse_from(args).unwrap().command)
};
assert_eq!(cap(&["omnigraph", "optimize", "graph.omni"]), Capability::Direct);
assert_eq!(cap(&["omnigraph", "schema", "plan", "--schema", "s.pg", "graph.omni"]), Capability::Direct);
assert_eq!(cap(&["omnigraph", "cluster", "status", "--config", "."]), Capability::Control);
assert_eq!(cap(&["omnigraph", "version"]), Capability::Local);
assert_eq!(cap(&["omnigraph", "queries", "list"]), Capability::Local);
}
#[test]
fn every_capability_describes_distinctly() {
let phrases = [
Capability::Any.describe(),
Capability::Served.describe(),
Capability::Direct.describe(),
Capability::Control.describe(),
Capability::Local.describe(),
];
for (i, a) in phrases.iter().enumerate() {
assert!(!a.is_empty());
for b in &phrases[i + 1..] {
assert_ne!(a, b);
}
}
}
}