docs(rfc): RFC-008 — deprecate omnigraph.yaml, one concern per config surface

The file is three unrelated concerns wearing one filename — server
deployment config, project/CLI conveniences, operator identity — and the
mixture is the root cause of a recurring problem class (per-operator
copies of project files, checkout-supplied credential redirection, init
scaffold pollution). End state: two single-owner surfaces — cluster
config (team, repo) and operator config (person, $HOME) — plus the
zero-config flags/env tier.

Complete key-by-key migration map over the verified OmnigraphConfig
surface; staged retirement per the repo's Hyrum rules (warn with per-key
guidance -> `config migrate` tool -> stop scaffolding -> opt-in strict ->
removal at the next major). RFC-007's project-layer framing is amended to
transitional accordingly.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This commit is contained in:
aaltshuler 2026-06-11 19:33:19 +03:00
parent d531f60999
commit 320311e759
3 changed files with 186 additions and 1 deletions

View file

@ -246,7 +246,17 @@ Three PRs, each independently useful, each landable without the next:
version) — slice 1 or slice 2? It materially helps debugging precedence,
which argues early.
## Relationship to RFC-002
## Relationship to RFC-002 and RFC-008
**RFC-008 supersedes this RFC's "project layer" framing**: with
`omnigraph.yaml` deprecated
([rfc-008-deprecate-omnigraph-yaml.md](rfc-008-deprecate-omnigraph-yaml.md)),
the project layer *is* the cluster checkout. References to project
`omnigraph.yaml` in §D3/§D5 describe the transitional window only; the
trust-boundary rules apply unchanged to whatever the project layer is at a
given stage. Sequencing couples them: RFC-007 PRs 12 must land before
RFC-008's migration stages can begin (the operator layer is what keys
migrate *to*).
RFC-002 remains the umbrella architecture. This RFC implements its §2
(layered config, global-first), §4 (file naming / one dir), and §5