@pleri/olam-cli 0.1.160 → 0.1.162

package/host-cp/peripheral-services/helm-values/grafana-values.yaml

@@ -0,0 +1,159 @@
+# Grafana Helm values — k3s-ingress-observability Phase B Task B2
+#
+# STANDALONE grafana/grafana chart per OQ-p3-4 + Decision 16.
+#   - This is NOT the Grafana bundled with kube-prometheus-stack.
+#   - Phase C kube-prometheus-stack MUST set `grafana.enabled: false`
+#     explicitly to prevent a second Grafana Deployment from landing.
+#   - Port-forward only — NEVER expose via Traefik IngressRoute.
+#     See T7 in DESIGN.md: secret exfil mitigated by no ingress surface.
+#
+# Chart: grafana/grafana; pinned to 8.5.2 (latest stable as of 2026-05-20).
+# Upgrade discipline: chart version is embedded in the e2e script comment.
+
+# -------------------------------------------------------------------------
+# Admin credentials — loaded from a pre-existing Secret, NOT from chart
+# values. Secret is created by scripts/e2e/grafana-port-forward.sh before
+# helm install, or by the operator following the procedure in
+# packages/peripheral-services/manifests/README.md (§ "Grafana admin secret").
+# The placeholder manifest (70-grafana-secret.yaml) was removed 2026-05-21
+# (dogfood finding #4) because `kubectl apply` would overwrite the operator's
+# pre-created Secret with the placeholder value.
+# -------------------------------------------------------------------------
+admin:
+  existingSecret: olam-grafana-admin
+  userKey: admin-user
+  passwordKey: admin-password
+
+# -------------------------------------------------------------------------
+# Service: ClusterIP only.
+# Decision 16: port-forward only; never ingress-routed.
+# Access: `kubectl port-forward -n monitoring svc/olam-grafana 3000:80`
+# -------------------------------------------------------------------------
+service:
+  type: ClusterIP
+  port: 80
+
+# -------------------------------------------------------------------------
+# Ingress: disabled.
+# Decision 16 + OQ-p3-4: Grafana is never exposed via Traefik IngressRoute.
+# Port-forward is the sole operator access path. Enabling ingress here would
+# silently violate the access-control intent even if no IngressRoute manifest
+# is committed.
+# -------------------------------------------------------------------------
+ingress:
+  enabled: false   # Decision 16: port-forward only; never ingress-routed
+
+# -------------------------------------------------------------------------
+# Datasources: Loki (default) + Prometheus (added in Phase C Task C1).
+#
+# Dual-chart pattern:
+#   - kube-prometheus-stack (C1) provides Prometheus. Its bundled Grafana
+#     sub-chart is disabled (grafana.enabled: false in kube-prom-stack-values.yaml).
+#   - This standalone grafana/grafana chart (Phase B) is the only Grafana.
+#   - The Prometheus datasource URL points at `prometheus-operated`, which is
+#     the in-cluster Service that kube-prometheus-stack's Prometheus Operator
+#     creates for the managed Prometheus StatefulSet.
+#   - timeInterval: 15s matches the scrape interval in kube-prom-stack-values.yaml
+#     so Grafana's step calculation aligns with actual data granularity.
+#   - exemplarTraceIdDestinations.datasourceUid: tempo is harmless until Phase D
+#     adds Tempo; Grafana silently ignores unknown datasource UIDs.
+#
+# editable: false prevents accidental operator drift across sessions.
+# -------------------------------------------------------------------------
+datasources:
+  datasources.yaml:
+    apiVersion: 1
+    datasources:
+      - name: Loki
+        type: loki
+        access: proxy
+        url: http://olam-loki.monitoring.svc.cluster.local:3100
+        isDefault: true
+        editable: false
+      - name: Prometheus
+        type: prometheus
+        access: proxy
+        url: http://prometheus-operated.monitoring.svc.cluster.local:9090
+        isDefault: false
+        editable: false
+        jsonData:
+          timeInterval: 15s         # matches scrape interval in kube-prom-stack-values.yaml
+          exemplarTraceIdDestinations:
+            - name: trace_id
+              datasourceUid: tempo  # Phase D may add Tempo; harmless until then
+
+# -------------------------------------------------------------------------
+# Dashboard provisioner: file-based ConfigMap mount.
+# B3 lands the olam-dashboards ConfigMap and the actual JSON files.
+# B2 wires the loader so B3's ConfigMap is picked up automatically.
+# -------------------------------------------------------------------------
+dashboardProviders:
+  dashboardproviders.yaml:
+    apiVersion: 1
+    providers:
+      - name: olam-default
+        orgId: 1
+        folder: 'Olam'
+        type: file
+        disableDeletion: true
+        updateIntervalSeconds: 30
+        allowUiUpdates: false
+        options:
+          path: /var/lib/grafana/dashboards/olam-default
+
+# Wire the volume mount — B3 creates this ConfigMap with the actual JSON.
+# Grafana will warn "ConfigMap olam-dashboards not found" until B3 lands;
+# this is benign and does not block Grafana startup.
+dashboardsConfigMaps:
+  olam-default: olam-dashboards   # B3 creates this ConfigMap
+
+# -------------------------------------------------------------------------
+# Resources: tuned for single-operator k3s (<256Mi idle typical).
+# P2 acceptance criterion: <500MB idle / <1GB typical across full LGTM stack.
+# -------------------------------------------------------------------------
+resources:
+  requests:
+    cpu: 50m
+    memory: 128Mi
+  limits:
+    cpu: 200m
+    memory: 256Mi   # P2: keeps Grafana within its share of the LGTM RAM budget
+
+# -------------------------------------------------------------------------
+# Persistence: disabled for Phase B.
+# Grafana state (dashboards, users) lives in ConfigMaps / values files.
+# Phase C may enable a PV if fine-grained alert state or annotations
+# accumulate. For now, stateless Grafana is simpler and matches S2.
+# -------------------------------------------------------------------------
+persistence:
+  enabled: false   # S2: ConfigMap-mounted dashboards; no PV needed in Phase B
+
+# -------------------------------------------------------------------------
+# ServiceMonitor: Phase C Prometheus scrapes Grafana's /metrics endpoint.
+# Disabled in Phase B: the ServiceMonitor CRD (monitoring.coreos.com/v1) is
+# shipped by kube-prometheus-stack in Phase C. The earlier "enable now to
+# avoid a Phase C helm upgrade" rationale was wrong — Phase C will need a
+# helm upgrade anyway to wire Prometheus scrape targets. Flipping this on
+# pre-CRD breaks the install on chart versions that hard-validate.
+# -------------------------------------------------------------------------
+serviceMonitor:
+  # Disabled in the source-of-truth values file so a standalone Phase B install
+  # (without kube-prometheus-stack) does not hard-fail when the CRD is absent.
+  # The C1 e2e script flips this on at RUNTIME via
+  #   helm upgrade ... --reuse-values --set serviceMonitor.enabled=true
+  # AFTER kube-prom-stack has installed the ServiceMonitor CRD.
+  enabled: false
+
+# -------------------------------------------------------------------------
+# Grafana.ini overrides: anonymous access disabled (default); only
+# setting the server root_url so port-forward URLs render correctly
+# in email / share links (cosmetic; not a security seam).
+# -------------------------------------------------------------------------
+grafana.ini:
+  server:
+    root_url: "%(protocol)s://%(domain)s:%(http_port)s/"
+  analytics:
+    reporting_enabled: false   # no telemetry to grafana.com
+    check_for_updates: false
+  security:
+    allow_embedding: false

package/host-cp/peripheral-services/helm-values/kube-prom-stack-values.yaml

@@ -0,0 +1,229 @@
+# kube-prometheus-stack Helm values — k3s-ingress-observability Phase C Task C1
+#
+# Chart: prometheus-community/kube-prometheus-stack; pinned to 85.2.0
+# (latest stable as of 2026-05-21).
+# Upgrade discipline: pin in this file + e2e script comment must stay in sync.
+#
+# CRITICAL: grafana.enabled MUST stay false.
+#   Phase B ships a standalone grafana/grafana chart (olam-grafana release).
+#   kube-prometheus-stack's bundled Grafana sub-chart is disabled to prevent
+#   a second Grafana Deployment from landing in the cluster.
+#   Decision 16 + OQ-p3-4: Phase B's standalone Grafana is canonical.
+#   Enabling the sub-chart here would violate that decision and create two
+#   Grafana instances — caught by prom-no-double-grafana.sh's single-Grafana
+#   assertion.
+#
+# Resource budget summary (Phase C contribution to P2 target <500MB idle / <1GB typical):
+#   prometheus-operator:  128Mi req / 512Mi limit
+#   prometheus:           512Mi req / 2Gi limit
+#   node-exporter:        64Mi req  / 128Mi limit
+#   kube-state-metrics:   128Mi req / 256Mi limit
+#   Total C1 addition:    ~832Mi req / ~3Gi limit (spread across nodes)
+#
+# Retention policy (Decision 14): scrape 15s / retention 15d / size cap 10GiB.
+# The size cap (T10 TSDB corruption mitigation) is the hard guard; retention 15d
+# is advisory — the size cap enforces first.
+#
+# Alertmanager: disabled for C1. C2 lands the first alert rule (cardinality 80k).
+# When C2 ships, flip alertmanager.enabled: true and configure receivers.
+# Comment: "C1 ships without alertmanager; C2 enables when first alert rule lands."
+
+# -------------------------------------------------------------------------
+# CARDINALITY ENFORCEMENT — Task C2 (T1 cardinality bomb / P4 <100k active series)
+#
+# Goal: strip high-cardinality labels (world_id, trace_id, user_id,
+# request_id, operator_id) from every scraped series BEFORE TSDB ingest.
+#
+# Architecture finding (helm template verified, 2026-05-21):
+#   The prometheus-operator Prometheus CR has NO global metricRelabelConfigs
+#   field. The Prometheus CR spec exposes only per-ServiceMonitor endpoint
+#   metricRelabelings. There is no chart-level "apply to all scrapes" slot.
+#
+# Enforcement strategy (two-layer):
+#   Layer 1 — chart-managed ServiceMonitors: set metricRelabelings on every
+#     ServiceMonitor the chart controls (coreDns, prometheusOperator,
+#     prometheus self-scrape, node-exporter). Belt-and-suspenders; these
+#     services don't emit world_id etc. in practice, but the rule is free.
+#     Note: kube-state-metrics sub-chart has no metricRelabelings slot in
+#     its prometheus.monitor section at chart version 85.2.0 — omitted.
+#   Layer 2 — user-deployed ServiceMonitors: the cardinality-drop.sh e2e
+#     script's synthetic violator ServiceMonitor carries the same labeldrop
+#     rule (release: olam-prom label + metricRelabelings). New services
+#     MUST include the same block — enforced by docs + code review.
+#
+# Why labeldrop is the right action:
+#   action: labeldrop removes the matched labels from ALL series that carry
+#   them, regardless of metric name. This is the same semantic as Promtail's
+#   pipeline drop stages (promtail-values.yaml) — both layers stay in sync.
+#   world_id surfaces in dashboards via EXEMPLARS (Decision 9), not labels.
+#
+# Regex covers all five taxonomy labels from observability-label-taxonomy:
+#   world_id, trace_id, user_id, request_id, operator_id
+# -------------------------------------------------------------------------
+_cardinalityLabeldrop: &cardinality-labeldrop
+  - action: labeldrop
+    regex: 'world_id|trace_id|user_id|request_id|operator_id'
+
+# -------------------------------------------------------------------------
+# HARD REQUIREMENT: grafana sub-chart is off.
+# See top-of-file comment for rationale.
+# -------------------------------------------------------------------------
+grafana:
+  enabled: false   # HARD: Decision 16 + OQ-p3-4 — standalone Grafana (olam-grafana) is canonical
+
+# -------------------------------------------------------------------------
+# Alertmanager: off until C2 lands the first alert rule.
+# C2 comment: "C1 ships without alertmanager; C2 enables when first alert rule lands."
+# -------------------------------------------------------------------------
+alertmanager:
+  enabled: true   # C2: first alert rule (OlamActiveSeriesHigh) lands; alertmanager enabled
+  serviceMonitor:
+    metricRelabelings: *cardinality-labeldrop
+
+# -------------------------------------------------------------------------
+# Default kube-controller-manager / scheduler / proxy / etcd monitors.
+# These ServiceMonitors don't work on k3d/k3s because the endpoints are not
+# exposed via the usual ports. Disabling avoids noisy "endpoint not found"
+# warnings and scrape failures on every Prometheus eval cycle.
+# -------------------------------------------------------------------------
+kubeControllerManager:
+  enabled: false
+
+kubeScheduler:
+  enabled: false
+
+kubeProxy:
+  enabled: false
+
+kubeEtcd:
+  enabled: false
+
+# kube-apiserver and kubelet DO work on k3d but generate high-cardinality
+# label combinations. Disable for now; re-evaluate when per-service /metrics
+# (C3) and cardinality enforcement (C2) are in place.
+kubeApiServer:
+  enabled: false
+
+kubelet:
+  enabled: false
+
+# -------------------------------------------------------------------------
+# Default alerting rules: off.
+# The bundled default rules generate Alertmanager receivers and PrometheusRule
+# objects for kubelet, etcd, apiserver, etc. — most don't fire on k3d anyway
+# and add noise before C2's focused cardinality rule lands.
+# C2 will add targeted PrometheusRule objects separately.
+# -------------------------------------------------------------------------
+defaultRules:
+  create: false
+
+# -------------------------------------------------------------------------
+# coreDns — ServiceMonitor with labeldrop (Layer 1 cardinality enforcement)
+# -------------------------------------------------------------------------
+coreDns:
+  serviceMonitor:
+    metricRelabelings: *cardinality-labeldrop
+
+# -------------------------------------------------------------------------
+# CRDs: install via chart (default: true, explicit for clarity).
+# These CRDs (ServiceMonitor, PodMonitor, PrometheusRule, etc.) are required
+# before Phase B's loki/promtail/grafana charts can have serviceMonitor.enabled:true.
+# Phase C's e2e script waits for servicemonitors.monitoring.coreos.com to be
+# Established before helm-upgrading the Phase B charts.
+# -------------------------------------------------------------------------
+crds:
+  enabled: true
+
+# -------------------------------------------------------------------------
+# Prometheus Operator
+# -------------------------------------------------------------------------
+prometheusOperator:
+  enabled: true
+  serviceMonitor:
+    metricRelabelings: *cardinality-labeldrop
+  resources:
+    requests:
+      cpu: 100m
+      memory: 128Mi
+    limits:
+      cpu: 500m
+      memory: 512Mi
+
+# -------------------------------------------------------------------------
+# Prometheus core — Decision 14: scrape 15s / retention 15d / 10GiB cap
+# -------------------------------------------------------------------------
+prometheus:
+  serviceMonitor:
+    metricRelabelings: *cardinality-labeldrop
+  prometheusSpec:
+    scrapeInterval: 15s              # Decision 14
+    evaluationInterval: 15s
+    retention: 15d                   # Decision 14 — advisory; size cap enforces first
+    retentionSize: 10GiB             # Decision 14 — T10 TSDB corruption prevention
+    walCompression: true
+    enableAdminAPI: false            # security: admin API allows snapshot deletion + series deletion
+    enableRemoteWriteReceiver: false # not a remote-write target; no inbound writes
+    logLevel: warn                   # info is noisy at 15s scrape cycle
+
+    resources:
+      requests:
+        cpu: 200m
+        memory: 512Mi
+      limits:
+        cpu: 1000m
+        memory: 2Gi
+
+    # PersistentVolume for TSDB. 12Gi = 10GiB retention cap + ~20% headroom.
+    # local-path provisioner is used on k3d; cloud providers use their default SC.
+    storageSpec:
+      volumeClaimTemplate:
+        spec:
+          accessModes:
+            - ReadWriteOnce
+          resources:
+            requests:
+              storage: 12Gi   # 10GiB retention + 20% headroom for in-flight segments
+
+# -------------------------------------------------------------------------
+# Node exporter — keep enabled (host-level metrics: CPU, memory, disk, net).
+# -------------------------------------------------------------------------
+nodeExporter:
+  enabled: true
+
+prometheus-node-exporter:
+  prometheus:
+    monitor:
+      metricRelabelings: *cardinality-labeldrop
+  resources:
+    requests:
+      cpu: 30m
+      memory: 64Mi
+    limits:
+      cpu: 100m
+      memory: 128Mi
+
+# -------------------------------------------------------------------------
+# kube-state-metrics — keep enabled (k8s-level metrics: pod phases, deployments).
+# -------------------------------------------------------------------------
+kubeStateMetrics:
+  enabled: true
+
+kube-state-metrics:
+  resources:
+    requests:
+      cpu: 50m
+      memory: 128Mi
+    limits:
+      cpu: 200m
+      memory: 256Mi
+
+# -------------------------------------------------------------------------
+# Datasource auto-discovery note:
+#   kube-prometheus-stack's grafana.sidecar.datasources is N/A (grafana sub-chart
+#   is off). Phase B's standalone Grafana (grafana-values.yaml) has been updated
+#   in this same C1 PR to include a Prometheus datasource entry pointing at:
+#     http://prometheus-operated.monitoring.svc.cluster.local:9090
+#   This is the in-cluster Service that kube-prometheus-stack creates for the
+#   Prometheus StatefulSet (created by the Prometheus Operator from the
+#   Prometheus CR above).
+# -------------------------------------------------------------------------

package/host-cp/peripheral-services/helm-values/kyverno-values.yaml

@@ -0,0 +1,85 @@
+# Kyverno Helm values — k3s-ingress-observability Phase C C8 follow-up.
+#
+# Kyverno is the policy-as-code layer for cluster-wide cardinality
+# enforcement (closes codex's C2 concern on PR #783). The companion
+# ClusterPolicy in
+# `packages/peripheral-services/manifests/96-kyverno-cardinality-mutate.yaml`
+# mutates every incoming ServiceMonitor and PodMonitor to inject the
+# labeldrop rule before the object is persisted — so a third-party
+# chart (or hand-rolled object) cannot bypass the layer-2
+# per-ServiceMonitor enforcement landed in C2.
+#
+# Chart: kyverno/kyverno; pinned to 3.8.1 (app v1.18.1, 2026-05-21 latest stable).
+# Upgrade discipline: this pin AND the helm-install line in
+# `scripts/e2e/kyverno-cardinality-mutate.sh` must stay in sync.
+#
+# Footprint posture (single-operator k3s scale):
+#   We only run admission-time mutation. The ClusterPolicy uses
+#   `spec.background: false`, so the background-scan controller is
+#   unused. Cleanup + reports controllers are also dead weight for
+#   a single ClusterPolicy with no PolicyExceptions — they're disabled
+#   so Kyverno's pod count stays minimal (1 pod, not 4).
+#
+#   Footprint (Phase C C8 contribution to P2 target <500MB idle / <1GB typical):
+#     admissionController:    128Mi req / 384Mi limit (chart default 128Mi/384Mi)
+#     Total addition:         ~128Mi req / ~384Mi limit
+#
+#   If/when we want policy reports populated for observability dashboards,
+#   flip `reportsController.enabled: true` and the `features.policyReports`
+#   block below. Same for cleanup.
+#
+# Resource limits — tuned upward from chart default for admission webhook
+# stability under burst churn (kube-prom-stack ships ~10 ServiceMonitors at
+# once during `helm upgrade`, which arrives as a burst of AdmissionReviews).
+
+# -------------------------------------------------------------------------
+# Disable controllers we don't need
+# -------------------------------------------------------------------------
+backgroundController:
+  enabled: false   # ClusterPolicy is admission-only (background: false)
+
+cleanupController:
+  enabled: false   # no CleanupPolicy objects in this repo
+
+reportsController:
+  enabled: false   # no policy-reports surface wired into Grafana yet
+
+# -------------------------------------------------------------------------
+# Features — admissionReports + policyReports remain ON inside the
+# admission controller itself even when the standalone reports controller
+# is disabled. This keeps `kubectl get clusterpolicyreport` queryable
+# during dogfood; the reports controller would only AGGREGATE them
+# cluster-wide, which we don't need yet.
+# -------------------------------------------------------------------------
+features:
+  admissionReports:
+    enabled: true
+  policyReports:
+    enabled: true
+  # Background scan is N/A — the policy uses background: false. Explicit
+  # off avoids the controller scheduling unnecessary scan workers even
+  # when the controller pod is disabled above.
+  backgroundScan:
+    enabled: false
+  # Logging volume defaults are fine; level 2 = info-ish.
+  logging:
+    format: text
+    verbosity: 2
+
+# -------------------------------------------------------------------------
+# Admission controller — the only pod we run.
+# -------------------------------------------------------------------------
+admissionController:
+  replicas: 1   # single-operator k3s scale; HA is N/A for dogfood
+
+  rbac:
+    create: true   # ClusterPolicy needs cluster-wide watch on ServiceMonitor + PodMonitor
+
+  container:
+    resources:
+      requests:
+        cpu: 100m
+        memory: 256Mi
+      limits:
+        cpu: 500m
+        memory: 512Mi

package/host-cp/peripheral-services/helm-values/loki-values.yaml

@@ -0,0 +1,166 @@
+# Loki Helm values — k3s-ingress-observability Phase B Task B1
+#
+# Single-binary mode (Decision-16 + Phase B scope):
+#   Distributed mode (microservices) adds 5+ independent Deployments + a Minio
+#   or S3 backend for object storage — pure overhead for a single-operator
+#   k3s install where Loki's write throughput is bounded by one Promtail
+#   DaemonSet and a handful of containers. SingleBinary collapses all roles
+#   (ingester, querier, compactor) into one Pod, fits within the <500MB idle
+#   LGTM RAM target (P2), and is trivially replaceable if scale demands change.
+#
+# See: docs/plans/k3s-ingress-observability/DESIGN.md (P2, S2)
+#
+# Chart: grafana/loki; pinned to 6.7.4 (latest stable as of 2026-05-20).
+# Upgrade discipline: chart version is embedded in the e2e script comment.
+
+deploymentMode: SingleBinary
+
+loki:
+  auth_enabled: false   # single-tenant; multi-tenancy adds header overhead with no benefit here
+
+  commonConfig:
+    replication_factor: 1   # single-binary; no replicas = no cross-replica consistency needed
+
+  # -------------------------------------------------------------------------
+  # Storage backend: filesystem (boltdb-shipper + tsdb index; local PV).
+  # Object storage (S3/GCS/MinIO) deferred to fatbox multi-org Phase F+.
+  # For single-operator k3s, local PV is simpler and sufficient.
+  # -------------------------------------------------------------------------
+  storage:
+    type: filesystem
+
+  schemaConfig:
+    configs:
+      - from: "2024-01-01"
+        store: tsdb
+        object_store: filesystem
+        schema: v13
+        index:
+          prefix: loki_index_
+          period: 24h
+
+  # -------------------------------------------------------------------------
+  # Retention: 7 days (168h) per Performance budget acceptance criterion #6.
+  # compactor.retention_enabled enables deletion; ring config required for
+  # single-binary mode.
+  # -------------------------------------------------------------------------
+  limits_config:
+    retention_period: 168h           # 7 days
+    ingestion_rate_mb: 4             # per-tenant ingestion cap (single tenant)
+    ingestion_burst_size_mb: 8
+    max_query_series: 5000           # cap log-derived queries from going wide (P3 <3s p95)
+    max_entries_limit_per_query: 5000
+
+  compactor:
+    retention_enabled: true
+    delete_request_store: filesystem
+    compaction_interval: 10m
+    working_directory: /var/loki/compactor
+
+  ingester:
+    chunk_idle_period: 30m   # flush to storage; appropriate for low write rate
+    chunk_retain_period: 1m
+    max_chunk_age: 2h
+
+  # Self-metrics endpoint — Phase C Prometheus scrapes this.
+  # Server block exposed on port 3100 (default); /metrics is always available.
+
+singleBinary:
+  replicas: 1
+
+  # -------------------------------------------------------------------------
+  # Persistence: 10Gi PV.
+  #
+  # Rationale: 7-day retention at olam scale (<500 containers, access logs
+  # estimated 1–2MB/day compressed) → ~100MB typical stored. 10Gi gives 10x
+  # headroom for burst (failed deploy loops, chatty containers) and is well
+  # within the <1GB typical acceptance criterion #6. Cloud provider default SC
+  # is fine; on bare-metal k3s the local-path provisioner is used.
+  # -------------------------------------------------------------------------
+  persistence:
+    enabled: true
+    size: 10Gi   # 10× headroom over 7-day typical (~100MB); <1GB usage target per AC#6
+
+  # -------------------------------------------------------------------------
+  # Resources: memory limit 512Mi per task spec.
+  # Typical usage at olam scale: <200MB idle (boltdb index + block cache).
+  # 512Mi limit prevents compaction spikes from triggering OOM on the node.
+  # -------------------------------------------------------------------------
+  resources:
+    requests:
+      cpu: 100m
+      memory: 128Mi
+    limits:
+      cpu: 500m
+      memory: 512Mi   # P2: <500MB idle / <1GB typical; limit prevents spike OOM
+
+# -------------------------------------------------------------------------
+# Self-metrics for Phase C Prometheus scrape.
+# ServiceMonitor is created here; Prometheus picks it up in Phase C.
+# -------------------------------------------------------------------------
+monitoring:
+  selfMonitoring:
+    enabled: false   # disables the bundled GrafanaAgent sub-chart dependency
+    grafanaAgent:
+      installOperator: false
+  serviceMonitor:
+    # Disabled in the source-of-truth values file so a standalone Phase B install
+    # (without kube-prometheus-stack) does not hard-fail when the CRD is absent.
+    # The C1 e2e script flips this on at RUNTIME via
+    #   helm upgrade ... --reuse-values --set monitoring.serviceMonitor.enabled=true
+    # AFTER kube-prom-stack has installed the ServiceMonitor CRD.
+    # NOTE: Loki 6.7.4 uses monitoring.serviceMonitor (not top-level serviceMonitor).
+    enabled: false
+
+# -------------------------------------------------------------------------
+# Backend and read/write gateway: disabled for SingleBinary mode.
+# These are microservices-mode components and must be off or the chart
+# emits validation errors when deploymentMode=SingleBinary.
+# -------------------------------------------------------------------------
+backend:
+  replicas: 0
+read:
+  replicas: 0
+write:
+  replicas: 0
+
+# Grafana agent / canary: not needed; disable to keep resource footprint minimal.
+lokiCanary:
+  enabled: false
+
+test:
+  enabled: false
+
+# -------------------------------------------------------------------------
+# Sub-component slimming — chart 6.7.4 defaults include nginx gateway +
+# two Memcached clusters + minio + sidecar watchers that single-binary
+# mode doesn't need. Each adds image-pull and Ready-wait time. Disabling
+# all of them brings the install Ready-time within the harness budget.
+# If a future scenario needs query-result caching, re-evaluate
+# resultsCache specifically.
+# -------------------------------------------------------------------------
+
+# nginx routing front; Promtail writes direct to single-binary :3100
+gateway:
+  enabled: false
+
+# Memcached cluster — overhead for single-binary
+chunksCache:
+  enabled: false
+
+# second Memcached cluster — overhead for single-binary
+resultsCache:
+  enabled: false
+
+# minio is off because storage.type=filesystem, but be explicit
+minio:
+  enabled: false
+
+# Sidecar that watches ConfigMaps for runtime config reloads — we don't ship one.
+sidecar:
+  rules:
+    enabled: false
+  datasources:
+    enabled: false
+  configs:
+    enabled: false