2 commits

Author	SHA1	Message	Date
Andrew Altshuler	7eeced3e88	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
Andrew Altshuler	a4d08a4184	feat(cli): RFC-011 Slice A — additive scope/profile addressing (#235) ... * feat(cli): RFC-011 Slice A — operator-config scope structs (profiles/clusters/defaults) Additive operator-config surface for the RFC-011 scope model. No behavior change yet — these structs are parsed but not consumed until the scope resolver lands. - OperatorConfig gains `profiles:` (name → OperatorProfile) and `clusters:` (name → OperatorCluster { root }) — the latter the only place a storage root appears in operator config (RFC-011 storage-root rule). - OperatorDefaults gains `server` and `default_graph` (the flat-default scope). - OperatorProfile binds one of {server, cluster, store} + default_graph; `binding()` validates exactly-one on use and returns a ScopeBinding. - Accessors profile()/cluster_root()/default_server()/default_graph(); unknown-key warnings extended to the new blocks (forward-compat preserved — old configs still load, new keys are no longer "unknown"). Tests: parse profiles/clusters/scope-defaults, binding rejects zero/multiple entities, unknown keys in a profile warn. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * feat(cli): RFC-011 Slice A — scope resolver + --profile/--store, wired (additive) Translate the new scope inputs into the existing addressing tuple, in front of the unchanged resolvers. Purely additive: an explicit address (--uri/--target/--server/--store) passes straight through, so every existing invocation is byte-for-byte unchanged. - scope.rs: resolve_scope() with the RFC-011 precedence (explicit > --profile / OMNIGRAPH_PROFILE > flat defaults.server), producing the effective (server, graph, uri, target) for data verbs and (cluster, cluster_graph) for maintenance. Plane×scope capability check (server scope rejected on a maintenance verb; cluster scope rejected on a data verb; store rejects --graph) fires only on the new paths. 9 unit tests. - cli.rs: global --profile <NAME> and --store <URI>. (--graph keeps requires=server for now; profile/default graph comes from default_graph — profile+--graph override is deferred to the --cluster-graph rework.) - client.rs: the two GraphClient factories call resolve_scope (Plane::Data) up front; the explicit branch reproduces today's behavior exactly. - main.rs: the 15 data call sites forward --profile/--store; the 3 maintenance verbs consult the scope (Plane::Storage) only when no explicit per-command address is given, so cluster-binding profiles and --store reach optimize/repair/cleanup. Verified: the full omnigraph-cli suite (221 tests) stays green untouched. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * test+docs(cli): RFC-011 Slice A — end-to-end scope test + reference docs - cli_data.rs: prove --store and a --profile store binding drive a read identically to the legacy positional URI (the additive-coexistence contract), end to end against a local graph (no server needed). - cli/reference.md: document profiles/clusters/defaults.server/default_graph, the --profile/--store flags, and a "Scopes & profiles" section; note the model coexists with legacy addressing (nothing removed yet). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>	2026-06-15 02:37:55 +03:00