Remove upstream/consumer repo references (#489)

- Simplify clusters config to single clusters.yaml source of truth
- Remove consumer override/fallback logic from logging pipeline docs
- Drop "upstream/" path prefixes in loki, mimir, and observability docs
- Consolidate B200 runner note without upstream/consumer distinction

The docs previously described a two-repo model (upstream vs consumer)
with override semantics. This cleanup aligns documentation with the
current single-repo structure.

Signed-off-by: Jean Schmidt <contato@jschmidt.me>

Author: jeanschmidt

osdc/CLAUDE.md

@@ -8,16 +8,9 @@ Modular Kubernetes infrastructure platform on AWS EKS. A shared `base/` provides
 
 Working directory: `osdc/`. Run all commands from here.
 
-## Clusters Configuration (IMPORTANT)
+## Clusters Configuration
 
-**All paths below are relative to this CLAUDE.md file.**
-
-Two `clusters.yaml` files exist — always check both when investigating module deployment:
-
-- **`./clusters.yaml`** — upstream cluster definitions (the platform's own clusters)
-- **`../../clusters.yaml`** — consumer repo cluster definitions (consumer-specific clusters)
-
-Modules may be deployed in upstream clusters but not consumer clusters, or vice versa. Never conclude a module is "not deployed" without checking both files.
+All clusters are defined in `./clusters.yaml`. This is the single source of truth for cluster definitions, module deployment, and per-cluster configuration.
 
 ## NEVER USE TERRAFORM — USE TOFU ONLY
 

osdc/docs/loki_query.md

@@ -177,4 +177,4 @@ To include timestamps:
 
 ## Source
 
-Upstream reference: `upstream/osdc/CLAUDE.md`, section "Querying Logs in Grafana Cloud Loki". Verified via live queries against `pytorch-arc-cbr-production` on 2026-03-20.
+Reference: `CLAUDE.md`, section "Querying Logs in Grafana Cloud Loki". Verified via live queries against `pytorch-arc-cbr-production` on 2026-03-20.

osdc/docs/mimir_query.md

@@ -252,9 +252,9 @@ curl -s -u "$MIMIR_USER:$MIMIR_PASS" \
 
 ## Source
 
-Upstream references:
-- `upstream/osdc/CLAUDE.md` — general architecture
-- `upstream/osdc/modules/monitoring/CLAUDE.md` — monitoring module docs, credential setup
+References:
+- `CLAUDE.md` — general architecture
+- `modules/monitoring/CLAUDE.md` — monitoring module docs, credential setup
 - `clusters.yaml` — Mimir read/write URLs
 - `upstream/osdc/modules/monitoring/helm/alloy-values.yaml` — Alloy remote_write config
 

osdc/docs/node-utilization-optimization.md

@@ -8,7 +8,7 @@ OSDC uses Kubernetes Guaranteed QoS pods (requests == limits) for all runner wor
 
 **Original state** (before Phase 2): 36 of 39 runner types had homogeneous utilization below 90%. Several had worst-case utilization under 20%. After Phase 2 (ratio-matched nodepools), x86 CPU worst-case improved from 12.6% to ~74% and ARM64 from 37.9% to 75.3%.
 
-> **Note**: This analysis covers both upstream runners (35 in `modules/arc-runners/defs/`) and consumer B200 runners (4 in the consumer repo's `modules/arc-runners-b200/defs/`). B200 nodepool and runner defs are not in the upstream repo.
+> **Note**: This analysis covers all runners including B200 runners in `modules/arc-runners-b200/defs/`.
 
 ## How Packing Works
 

osdc/docs/observability.md

@@ -195,12 +195,9 @@ Each module can contribute log parsing rules by placing a `logging/pipeline.allo
 During deploy, `assemble_config.py`:
 
 1. Reads `clusters.yaml` to get the cluster's enabled modules
-2. For each module, checks `$OSDC_ROOT/modules/<name>/logging/pipeline.alloy` (consumer override first)
-3. Falls back to `$OSDC_UPSTREAM/modules/<name>/logging/pipeline.alloy`
-4. Inserts all discovered blocks at the `// MODULE_PIPELINES` marker in `base.alloy`
-5. Outputs the assembled config as a ConfigMap YAML (`alloy-logging-config`)
-
-**Consumer opt-out**: an empty (whitespace-only) `pipeline.alloy` in the consumer's modules directory suppresses the upstream pipeline for that module entirely. The upstream file is NOT checked as fallback. This lets consumers disable a module's log parsing without deleting the upstream file.
+2. For each module, checks `modules/<name>/logging/pipeline.alloy`
+3. Inserts all discovered blocks at the `// MODULE_PIPELINES` marker in `base.alloy`
+4. Outputs the assembled config as a ConfigMap YAML (`alloy-logging-config`)
 
 **Example module pipeline** (`modules/karpenter/logging/pipeline.alloy`):