No documented relationship between this repo and grid's bundled operator/ (independent, non-integrated Praxis-config codepaths)

[jordigilh]

Summary

This repo and praxis-proxy/grid's bundled operator/ crate are two
independently-maintained codepaths that both turn "routing intent" into a
running Praxis Deployment + ConfigMap + Service
(src/resources/deployment.rs here vs. grid's
operator/src/resources/routing_overlay.rs / consumer_config.rs). Neither
repo's README mentions that the other exists, there's no shared code or
shared tests between the two Praxis-config-generation codepaths, and an
earlier planning artifact describing an integrated deployment appears to
describe something that was never realized.

This is filed as a design/documentation gap, not a bug: the divergence
itself may well be the right call (see below), but right now there's no
record of why, which makes it look like an oversight to anyone new
encountering both repos.

Evidence

• This repo's Gateway API -> Praxis config path:
  src/resources/deployment.rs (Kubernetes resource builders),
  AGENTS.md:58-63 (module structure: controller/, gateway_api/,
  config/, resources/).
• Grid's independent path: operator/src/resources/routing_overlay.rs,
  operator/src/resources/consumer_config.rs,
  operator/src/controller/grid_network.rs in praxis-proxy/grid.
• Neither README references the other project:
  README.md (this repo) has no mention of "grid"; praxis-proxy/grid's
  README.md mentions only its own grid-operator Helm chart and says
  "Install a compatible [Praxis] gateway separately" (README.md:101-116)
  -- no mention of this repo or the Gateway API path it implements.
• Grid's actual current install flow bypasses this repo entirely: helm install grid-operator oci://ghcr.io/praxis-proxy/charts/grid-operator
  plus a separately-installed Praxis gateway, not a Gateway/HTTPRoute
  reconciled by praxis-operator.
• An earlier planning artifact (internal AI Grid Project docs) describes
  "Deployment uses short helm commands to install Grid Operator and Praxis
  Operator... alongside the Praxis MVP deployment," and separately that
  "Praxis Operator will use an interim solution and be developed to manage
  proxy deployment, life-cycle, and integration points for Grid Operator as
  an MVP goal." Grid's current README/install flow does not reflect this;
  the two remain unconnected in practice.

Risk

Low near-term operational risk (each repo works standalone today), but:

• Two independent Praxis-config-generation codepaths can drift in behavior
  or in what a Deployment/ConfigMap/Service produced by either one is
  expected to look like, with no shared tests to catch divergence.
• Someone deploying both Grid and a Gateway API-managed Praxis instance has
  no documented guidance on whether/how the two are meant to coexist.
• Without a recorded decision, it's ambiguous whether the current
  separation is an intentional architecture choice (different problem
  domains: generic Gateway API lifecycle vs. AI-aware multi-site routing) or
  an abandoned integration that should eventually be revisited.

Suggested fix

At minimum: cross-reference the relationship (and current non-integration)
in both repos' READMEs, e.g. a short "Relationship to Grid" /
"Relationship to the standalone Gateway operator" section.

Ideally: an explicit decision record (ADR or similar, in docs/proposals.md
or equivalent) stating whether these should ever converge, share a
config-generation code path, or formally stay separate long-term.

Severity: High (architecture / documentation)