mirror of
https://github.com/ModernRelay/omnigraph.git
synced 2026-06-12 01:45:14 +02:00
docs(cluster): axiom 15 — single ownership, mode-switch migration, per-operator layer (#164)
Encode the omnigraph.yaml ↔ cluster.yaml coexistence rules that were implicit across the specs: - cluster-axioms.md: new axiom 15 — every fact has exactly one owner at a time; coexistence is a mode switch, never a merge; omnigraph.yaml's job description shrinks to the permanent per-operator layer. Added review-tension bullet. - cluster-config-specs.md: "Migration model" subsection (three coexistence windows: no-conflict, Phase-5 mode switch, bridges-with-sunsets) and a "per-operator layer" completeness table (connection, credential reference, active context, ergonomics, personal aliases) with its global-config-dir destination per the RFC-002 direction. - cluster-config-implementation-spec.md: Compatibility Stance #7–#9 (single ownership, shrinking role, bridges carry sunsets); Phase 5 boot is an exclusive XOR mode switch; fixed the duplicated recoveries/recovery dirs in the Phase-1 storage layout. - docs/user/cluster-config.md: "Relationship to omnigraph.yaml" section in current-reality terms (cluster catalog is inspectable, not live). Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
This commit is contained in:
parent
2c578a60b2
commit
cec65b8ef8
4 changed files with 100 additions and 4 deletions
|
|
@ -23,6 +23,19 @@ omnigraph cluster force-unlock <LOCK_ID> --config ./company-brain --json
|
|||
`--config` points at a directory, not a file. The directory must contain
|
||||
`cluster.yaml`. When omitted, it defaults to the current directory.
|
||||
|
||||
## Relationship to `omnigraph.yaml`
|
||||
|
||||
`cluster.yaml` does not replace `omnigraph.yaml`, and the two never describe
|
||||
the same fact. `omnigraph.yaml` remains how the CLI and server are configured
|
||||
today (graph targets, server bind, CLI defaults, credential env references) and
|
||||
is its long-term home for per-operator settings. `cluster.yaml` is the shared
|
||||
desired state of a whole deployment, read only by the `cluster` commands via
|
||||
`--config`. In the current stage, nothing recorded in the cluster state ledger
|
||||
affects what a server serves or what other CLI commands target — the cluster
|
||||
catalog is inspectable, not live. When server boot from cluster state ships in
|
||||
a later stage, it will be an explicit per-deployment mode switch, not a merge
|
||||
of the two files.
|
||||
|
||||
## Supported `cluster.yaml`
|
||||
|
||||
Stage 2C accepts only the read-only resource subset:
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue