docs: drop the last "OSS" references from the current docs

versioned_docs/version-4.0.0/quickstart/k8s-proxy-llm-workflow.md

@@ -428,7 +428,7 @@ Run report: https://app.keploy.io/tr/<test_run_id>?appId=<app_id>
 
 **Capture:**
 
-1. Run `keploy record -c "<dev run command>" --sync --disable-mapping=false` via Bash. The `-c` value must be the **foreground** form of the run command — if your pre-flight used the detached/background form (e.g. `docker compose up -d`), pass the foreground variant here (`docker compose up`, no `-d`). Detached commands return immediately on launch and keploy treats the early exit as "app stopped", capturing nothing. `--sync` records test cases synchronously so each curl is captured in order with no race against the next one; **`--disable-mapping=false` is MANDATORY** — without it, the host inherits `keploy.yml`'s `disableMapping: true` (the auto-generated default), the agent silently skips writing `mappings.yaml`, and the uploaded bundle lands in mongo with no `mapping_audits` doc → `getMockMapping` returns empty `mocks: []` for every test case → replay matcher falls back to fragile timestamp-windows. Cloud association happens in Phase B3's upload step, not here — `keploy record` itself is the local OSS command and doesn't take `--cloud-app-id`.
+1. Run `keploy record -c "<dev run command>" --sync --disable-mapping=false` via Bash. The `-c` value must be the **foreground** form of the run command — if your pre-flight used the detached/background form (e.g. `docker compose up -d`), pass the foreground variant here (`docker compose up`, no `-d`). Detached commands return immediately on launch and keploy treats the early exit as "app stopped", capturing nothing. `--sync` records test cases synchronously so each curl is captured in order with no race against the next one; **`--disable-mapping=false` is MANDATORY** — without it, the host inherits `keploy.yml`'s `disableMapping: true` (the auto-generated default), the agent silently skips writing `mappings.yaml`, and the uploaded bundle lands in mongo with no `mapping_audits` doc → `getMockMapping` returns empty `mocks: []` for every test case → replay matcher falls back to fragile timestamp-windows. Cloud association happens in Phase B3's upload step, not here — `keploy record` itself is the local command and doesn't take `--cloud-app-id`.
 2. For each new/changed endpoint, drive ONE realistic curl. Infer body shape from the OpenAPI spec if there is one, otherwise from the handler signature itself.
 3. Stop `keploy record` (kill the PID you captured at step 1, or send Ctrl-C equivalent).
 4. The recording lands at `keploy/test-set-N/` on disk.

versioned_docs/version-4.0.0/running-keploy/k8s-proxy-api.md

@@ -323,7 +323,7 @@ The proxy tears down the headless Service, unloads the agent on the next rollout
 
 ## Recording configuration
 
-The `record_config` block in `POST /record/start` is a UI-friendly subset of the OSS `config.Record` struct and is persisted alongside the session so the UI can prefill it and so the exact inputs are auditable.
+The `record_config` block in `POST /record/start` is a UI-friendly subset of Keploy's `config.Record` struct and is persisted alongside the session so the UI can prefill it and so the exact inputs are auditable.
 
 | Field                 | Type                    | Description                                                                                                                                     |
 | --------------------- | ----------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------- |

versioned_docs/version-4.0.0/running-keploy/k8s-proxy-daemonset-architecture.md

@@ -101,9 +101,9 @@ When a recording session ends—either because the cooldown window expires or be
 
 ### How dispatch works
 
-`/record/stop` runs the recording teardown synchronously and then enters a dispatch branch in `pkg/http/handlers.go`. The branch reads `cfg.AutoReplayMode` and routes to the matching handler, which stands up a replay environment from the captured test cases. Both modes eventually drive the OSS replayer (`go.keploy.io/server/v3/pkg/service/replay`)—what differs is **where the application under test actually runs** during replay.
+`/record/stop` runs the recording teardown synchronously and then enters a dispatch branch in `pkg/http/handlers.go`. The branch reads `cfg.AutoReplayMode` and routes to the matching handler, which stands up a replay environment from the captured test cases. Both modes eventually drive Keploy's replayer (`go.keploy.io/server/v3/pkg/service/replay`)—what differs is **where the application under test actually runs** during replay.
 
-The default replay-start delay is **10 seconds** in both modes. This gives the replayed application time to bind its port before the OSS replayer fires the first test case. Callers can override it via `auto_replay_config.delay` in the `/record/start` body.
+The default replay-start delay is **10 seconds** in both modes. This gives the replayed application time to bind its port before the replayer fires the first test case. Callers can override it via `auto_replay_config.delay` in the `/record/start` body.
 
 ---
 
@@ -131,7 +131,7 @@ keploy-replay-runner   ─poll──▶  k8s-proxy /replay-jobs/poll
       │
       │ keploy enterprise replay … --record-id=<id>
       │   downloads mocks + test cases from k8s-proxy via HTTP
-      │   runs the OSS replayer
+      │   runs the replayer
       ▼
    docker rm <both containers>
       │
@@ -206,10 +206,10 @@ This is the **recommended** production mode and is also the default. It keeps th
 1. k8s-proxy reads the source Deployment's `PodTemplateSpec` (read-only).
 2. It rehydrates every `envFrom` / `valueFrom` / volume `ConfigMap` and `Secret` referenced by the Pod template into the replay-cluster's namespace, using the mounted kubeconfig. ServiceAccount-token Secrets are intentionally skipped—they are cluster-bound.
 3. It creates a standalone Pod (`<app>-rpl-<random>`) plus a backing Service and a deny-all-egress NetworkPolicy in the replay cluster. The Pod runs the application image alongside the keploy-agent sidecar.
-4. It opens a SPDY port-forward through the replay cluster's API server to the agent port and the recorded application port. The OSS replayer drives test cases through that local forward—k8s-proxy never needs in-cluster network reachability into the replay cluster.
+4. It opens a SPDY port-forward through the replay cluster's API server to the agent port and the recorded application port. The replayer drives test cases through that local forward—k8s-proxy never needs in-cluster network reachability into the replay cluster.
 5. When replay ends, the proxy deletes the Pod, Service, and NetworkPolicy. ConfigMaps and Secrets are left in place; they're rehydrated again next run if the source spec changed.
 
-**What stays the same as `runner` mode:** the OSS replayer, the report shape, the Mongo collections (`testrunReports`, `testsetReports`, `testcaseReports`, `autoReplayMetrics`, `k8sSchemaCoverageReports`), and the Console UI.
+**What stays the same as `runner` mode:** the replayer, the report shape, the Mongo collections (`testrunReports`, `testsetReports`, `testcaseReports`, `autoReplayMetrics`, `k8sSchemaCoverageReports`), and the Console UI.
 
 **What's different:** every Pod / Service / NetworkPolicy write goes to the replay cluster. The source cluster never sees a write from Keploy.