minor fixes

Signed-off-by: Arvind Thirumurugan <arvindth@microsoft.com>

Author: Arvind Thirumurugan

approval-controller-metric-collector/README.md

@@ -8,7 +8,7 @@ This directory contains two controllers:
 - **approval-request-controller**: Runs on the hub cluster to automate approval decisions for staged updates
 - **metric-collector**: Runs on member clusters to collect workload health metrics from Prometheus
 
-![Approval Controller and Metric Collector Architecture](./approval-controller-metric-collector.drawio.png)
+![Approval Controller and Metric Collector Architecture](./approval-controller-metric-collector.png)
 
 ## How It Works
 
@@ -75,28 +75,6 @@ This solution introduces three new CRDs that work together with KubeFleet's nati
    - Creates a new ApprovalRequest for the next stage (if any)
    - The cycle repeats for each stage
 
-### Key Design Decisions
-
-**Why ClusterResourceOverride?**
-- Each member cluster needs to report to a different namespace on the hub
-- The override injects the cluster-specific `reportNamespace` before deployment
-- This allows a single MetricCollector definition to work across all clusters
-
-**Why PickFixed Placement Policy?**
-- Stages may target different subsets of clusters
-- PickFixed ensures MetricCollector only deploys to clusters in the current stage
-- Avoids collecting metrics from clusters not involved in the stage
-
-**Why 15-second polling for approval?**
-- Balances responsiveness with control plane load
-- Gives clusters time to stabilize after rollout
-- Allows detection of workload health degradation
-
-**Why cluster-scoped MetricCollector?**
-- Simplifies propagation via CRP (no namespace matching issues)
-- Single resource definition covers all namespaces
-- Consistent with KubeFleet's placement model
-
 ## Prerequisites
 
 - Docker or Podman for building images