{"owner":"openshift","repo":"origin","hasSkills":true,"totalSkillsCount":16,"totalTokensCount":13812,"categories":["root-instruction","command-prompt","claude-rule","mcp-config","gemini-rule","cursor-rule","anthropic-skill","plugin-manifest"],"hasMcp":true,"mcpConfig":{"mcpServers":{"atlassian":{"type":"http","url":"https://mcp.atlassian.com/v1/mcp"}}},"found":["AGENTS.md",".claude/commands/origin-dev-setup.md","CLAUDE.md",".claude/commands/update-all-operator-watch-request-limits.md",".cursor/mcp.json","GEMINI.md",".cursor/rules/testing.mdc",".claude/rules/general.md",".claude/rules/testing.md",".cursor/commands/origin-dev-setup.md",".opencode/commands/origin-dev-setup.md",".cursor/rules/general.mdc","tools/etcdhelper/README.md","tools/junitreport/README.md","vendor/github.com/google/gnostic-models/extensions/README.md","vendor/k8s.io/kubernetes/pkg/scheduler/framework/plugins/README.md"],"skills":{"AGENTS.md":"# AGENTS.md\n<!-- Generated by APM CLI from distributed .apm/ primitives -->\n<!-- Build ID: 3109b13c034b -->\n<!-- APM Version: 0.13.0 -->\n<!-- Source: local -->\n\n## Files matching `**`\n\n<!-- Source: local .apm/instructions/general.instructions.md -->\n### APM context generation\n\nSources under **`.apm/`** (instructions, prompts, `apm.yml`, etc.) drive generated agent context. After editing those files, run **`make apm`** to regenerate **AGENTS.md**, **CLAUDE.md**, **GEMINI.md**, and the integrated copies under **`.claude/`**, **`.cursor/`**, **`.gemini/`**, **`.github/instructions/`**, **`.github/prompts/`**, and **`.opencode/`**.\n\n**Slash / agent commands:** content under **`.apm/prompts/*.prompt.md`** is the single source of truth. **`apm install`** (part of **`make apm`**) copies each prompt into editor command targets (e.g. **`.claude/commands/`**, **`.opencode/commands/`**, **`.gemini/commands/`**). Do not add those generated paths by hand or installs will skip them as unmanaged duplicates.\n\n### Retry allowlist policy\n\n**`pkg/test/ginkgo/retry_allowed_tests.yaml`** is strictly shrink-only. Never add tests to it. Remove an entry only when its underlying flake is fixed. If a requested change conflicts with this policy, stop and ask for human direction.\n\n### Repository overview\n\n**openshift/origin** builds the `openshift-tests` binary — the orchestrator for all OpenShift end-to-end testing. It contains:\n* **Built-in e2e tests** (Ginkgo) that run against a live cluster.\n* **Monitor tests** that observe cluster health in the background during e2e runs.\n* **Disruption tests** (a category of monitor test) that measure endpoint availability.\n* **Extension orchestration** that discovers and runs tests contributed by other components via the OTE framework.\n\n### Key directories\n\n* **`cmd/openshift-tests/`** — main binary entry point with subcommands: `run`, `run-test`, `run-monitor`, `run-upgrade`, `disruption`, `list`, `info`, `extension-admission`, and more.\n* **`pkg/testsuites/`** — test suite definitions that compose built-in and extension tests.\n* **`test/extended/`** — Ginkgo-based e2e test packages organized by area (e.g. `networking/`, `storage/`, `etcd/`).\n* **`test/extended/include.go`** — blank imports that register all e2e test packages. New packages **must** be added here.\n* **`test/e2e/upgrade/`** — upgrade-specific e2e tests.\n* **`pkg/monitortestframework/`** — `MonitorTest` interface and registry.\n* **`pkg/defaultmonitortests/`** — registers default monitor tests for stable and disruptive scenarios.\n* **`pkg/monitortests/`** — individual monitor test implementations organized by component (e.g. `etcd/`, `kubeapiserver/`, `network/`, `node/`).\n* **`pkg/monitortestlibrary/`** — shared monitor utilities (allowed disruption baselines, alert allowlists, platform identification).\n* **`pkg/disruption/`** — disruption measurement framework (HTTP/gRPC sampling, transport hooks, shutdown detection).\n* **`pkg/test/extensions/`** — OTE extension binary extraction, execution, and admission control.\n* **`vendor/`** — vendored dependencies. Run `go mod tidy && go mod vendor` after changing `go.mod` to keep `go.sum` and `vendor/` in sync.\n\n### E2e tests\n\nGinkgo-based tests in `test/extended/<area>/` run against a live OpenShift cluster. Each package is registered via blank import in `test/extended/include.go`. These are the \"built-in\" tests that ship inside the `openshift-tests` binary. Tests are grouped into suites (e.g. `openshift/conformance/parallel`) defined in `pkg/testsuites/`.\n\n### Monitor tests\n\nMonitor tests run **in parallel** with the e2e suite to continuously observe cluster health. They follow a lifecycle:\n1. **`StartCollection()`** — begin watching resources, recording events.\n2. *(e2e tests execute)*\n3. **`CollectData()`** — final data collection pass.\n4. **`ConstructComputedIntervals()`** — analyze raw data into structured intervals.\n5. **`EvaluateTestsFromConstructedIntervals()`** — produce JUnit pass/fail results.\n\nMonitor tests are registered in `pkg/defaultmonitortests/types.go` with two stability levels: **Stable** (normal operation — runs all monitors including availability checks) and **Disruptive** (tests that intentionally cause outages like upgrades, node drains, etcd recovery, or cert rotation — availability monitors are excluded since measuring uptime during intentional disruption would produce false failures). Implementations live in `pkg/monitortests/` organized by component — examples include etcd log analysis, cluster operator state tracking, node readiness, API server availability, and alert evaluation.\n\n### Disruption tests\n\nDisruption tests are a category of monitor test that measure **endpoint availability** during test runs. They continuously poll services (API servers, ingress, image registry, pod network) and record availability intervals. Allowed disruption baselines in `pkg/monitortestlibrary/allowedbackenddisruption/` define acceptable unavailability thresholds. Key implementations live in `pkg/monitortests/kubeapiserver/`, `pkg/monitortests/network/`, and `pkg/monitortests/imageregistry/`.\n\n### Extensions (OTE — OpenShift Tests Extension)\n\nThe `openshift-tests` binary acts as an **orchestrator** for tests contributed by other components. The [openshift-tests-extension](https://github.com/openshift-eng/openshift-tests-extension) (OTE) framework defines a standardized interface that external binaries implement:\n* **`<binary> info`** — return extension metadata (component, suites, version).\n* **`<binary> list -o jsonl`** — list available tests, filtered by environment (platform, arch, network).\n* **`<binary> run-test -n <name>`** — execute a specific test and return JSONL results.\n\n**Payload extensions** are test binaries shipped inside release payload images. The registry in `pkg/test/extensions/binary.go` maps ~35 payload image tags to their test binary paths. At runtime, `openshift-tests` extracts these binaries, discovers their tests, and runs them alongside built-in tests.\n\n**Non-payload extensions** are discovered from ImageStreamTags in the cluster and require explicit approval via a `TestExtensionAdmission` CRD. The `extension-admission` subcommand manages these approval rules.\n\nOrigin also registers itself as an extension (`openshift:payload:origin`) so its own built-in Ginkgo tests appear in the unified extension registry alongside external tests.\n\n### Build and verify\n\n* **Build:** `make build` or `make openshift-tests` (produces `./openshift-tests`).\n* **Unit tests:** `go test ./pkg/...` (fast, no cluster required).\n* **Lint / verify:** `make verify` (runs `go vet`, jsonformat, generated-file checks, TLS ownership).\n* **Full check:** `make check` (verify + build + tests).\n\nFavor clarity and maintainability over cleverness. Comments should be minimal, helpful, and explain the \"why\" not the \"what\".\n\n## Files matching `**/*_test.go`\n\n<!-- Source: local .apm/instructions/testing.instructions.md -->\n* Use `go vet ./...` and `go test ./pkg/...` to validate changes before committing.\n* E2e tests in `test/extended/<area>/` are **platform-level tests for OpenShift** — they run against a live cluster to validate the product, not just this repo. They use the **Ginkgo** framework and are compiled into the `openshift-tests` binary that CI runs against every payload.\n* `test/extended/include.go` blank-imports every e2e test package — new packages **must** be added there or they won't be compiled into the binary.\n* Unit tests in `pkg/` use standard Go `testing` with **table-driven** patterns.\n* Build the test binary: `make openshift-tests` or `make build`.\n* For unit tests, prefer **table-driven tests** with descriptive case names. Search the same package for existing test patterns before writing new ones.\n\n---\n*This file was generated by APM CLI. Do not edit manually.*\n*To regenerate: `apm compile`*\n",".claude/commands/origin-dev-setup.md":"---\ndescription: Set up the Origin devcontainer (Podman, env, GCP auth)\n---\n\n# Origin dev — devcontainer setup\n\nInteractive setup for the Origin devcontainer. Automates what can be detected, prompts for what can't.\n\n## Workflow\n\n### 1. Detect OS\n\n```bash\nuname -s\n```\n\n- **Darwin** = macOS\n- **Linux** = Linux\n\n### 2. Check prerequisites\n\nVerify each tool is installed. Report any that are missing and stop.\n\n```bash\ncommand -v podman\ncommand -v devcontainer\n```\n\nIf `devcontainer` is missing, tell the user: `npm install -g @devcontainers/cli`\n\n### 3. macOS: Podman machine\n\nIf macOS, check if podman machine is running:\n\n```bash\npodman machine info\n```\n\nIf not initialized or not running, run:\n\n```bash\npodman machine init   # only if no machine exists\npodman machine start\n```\n\n### 4. Linux: Podman socket\n\nIf Linux, check if the socket is active:\n\n```bash\nsystemctl --user is-active podman.socket\n```\n\nIf not active, run:\n\n```bash\nsystemctl --user enable --now podman.socket\n```\n\nAlso check for `podman-docker`:\n\n```bash\ncommand -v docker\n```\n\nIf missing, suggest installing `podman-docker` (dnf or apt depending on `/etc/os-release`).\n\n### 5. Environment file\n\nCheck if `.devcontainer/.env` exists:\n\n```bash\ntest -f .devcontainer/.env\n```\n\nIf missing, copy from the example:\n\n```bash\ncp .devcontainer/.env.example .devcontainer/.env\n```\n\nThen read `.devcontainer/.env` and check for empty required values. If any are blank (e.g. `ANTHROPIC_VERTEX_PROJECT_ID`), tell the user which values need to be filled in and ask them to edit `.devcontainer/.env` and let you know when they're done. **Do not** ask for the values directly or write to the file yourself — the user should edit it. Wait for them to confirm before continuing.\n\n### 6. Start the container\n\nDetermine the right command based on OS:\n\n- **macOS**: `devcontainer up --workspace-folder . --docker-path podman`\n- **Linux** (with `podman-docker`): `devcontainer up --workspace-folder .`\n- **Linux** (without `podman-docker`): `devcontainer up --workspace-folder . --docker-path podman`\n\nRun it. This triggers `post-create.sh` (Go tools, Claude Code, `make build`).\n\n### 7. GCP authentication\n\nGCP credentials are mounted from the host's `~/.config/gcloud` directory. If the user hasn't authenticated on the host yet, tell them to run on the host (not inside the container):\n\n```bash\ngcloud auth application-default login\n```\n\nThe credentials will be available inside the container automatically after restart.\n\n### 8. Summary\n\nPrint a summary of what was set up:\n\n- Container status\n- Claude Code: available via Vertex AI\n- GCP auth status\n- To exec in: `podman exec -it -u vscode -w /workspace origin-dev bash`","CLAUDE.md":"# CLAUDE.md\n<!-- Generated by APM CLI -->\n<!-- Build ID: b79f3567f84e -->\n<!-- APM Version: 0.13.0 -->\n\n# Project Standards\n\n## Files matching `**`\n\n<!-- Source: local .apm/instructions/general.instructions.md -->\n### APM context generation\n\nSources under **`.apm/`** (instructions, prompts, `apm.yml`, etc.) drive generated agent context. After editing those files, run **`make apm`** to regenerate **AGENTS.md**, **CLAUDE.md**, **GEMINI.md**, and the integrated copies under **`.claude/`**, **`.cursor/`**, **`.gemini/`**, **`.github/instructions/`**, **`.github/prompts/`**, and **`.opencode/`**.\n\n**Slash / agent commands:** content under **`.apm/prompts/*.prompt.md`** is the single source of truth. **`apm install`** (part of **`make apm`**) copies each prompt into editor command targets (e.g. **`.claude/commands/`**, **`.opencode/commands/`**, **`.gemini/commands/`**). Do not add those generated paths by hand or installs will skip them as unmanaged duplicates.\n\n### Retry allowlist policy\n\n**`pkg/test/ginkgo/retry_allowed_tests.yaml`** is strictly shrink-only. Never add tests to it. Remove an entry only when its underlying flake is fixed. If a requested change conflicts with this policy, stop and ask for human direction.\n\n### Repository overview\n\n**openshift/origin** builds the `openshift-tests` binary — the orchestrator for all OpenShift end-to-end testing. It contains:\n* **Built-in e2e tests** (Ginkgo) that run against a live cluster.\n* **Monitor tests** that observe cluster health in the background during e2e runs.\n* **Disruption tests** (a category of monitor test) that measure endpoint availability.\n* **Extension orchestration** that discovers and runs tests contributed by other components via the OTE framework.\n\n### Key directories\n\n* **`cmd/openshift-tests/`** — main binary entry point with subcommands: `run`, `run-test`, `run-monitor`, `run-upgrade`, `disruption`, `list`, `info`, `extension-admission`, and more.\n* **`pkg/testsuites/`** — test suite definitions that compose built-in and extension tests.\n* **`test/extended/`** — Ginkgo-based e2e test packages organized by area (e.g. `networking/`, `storage/`, `etcd/`).\n* **`test/extended/include.go`** — blank imports that register all e2e test packages. New packages **must** be added here.\n* **`test/e2e/upgrade/`** — upgrade-specific e2e tests.\n* **`pkg/monitortestframework/`** — `MonitorTest` interface and registry.\n* **`pkg/defaultmonitortests/`** — registers default monitor tests for stable and disruptive scenarios.\n* **`pkg/monitortests/`** — individual monitor test implementations organized by component (e.g. `etcd/`, `kubeapiserver/`, `network/`, `node/`).\n* **`pkg/monitortestlibrary/`** — shared monitor utilities (allowed disruption baselines, alert allowlists, platform identification).\n* **`pkg/disruption/`** — disruption measurement framework (HTTP/gRPC sampling, transport hooks, shutdown detection).\n* **`pkg/test/extensions/`** — OTE extension binary extraction, execution, and admission control.\n* **`vendor/`** — vendored dependencies. Run `go mod tidy && go mod vendor` after changing `go.mod` to keep `go.sum` and `vendor/` in sync.\n\n### E2e tests\n\nGinkgo-based tests in `test/extended/<area>/` run against a live OpenShift cluster. Each package is registered via blank import in `test/extended/include.go`. These are the \"built-in\" tests that ship inside the `openshift-tests` binary. Tests are grouped into suites (e.g. `openshift/conformance/parallel`) defined in `pkg/testsuites/`.\n\n### Monitor tests\n\nMonitor tests run **in parallel** with the e2e suite to continuously observe cluster health. They follow a lifecycle:\n1. **`StartCollection()`** — begin watching resources, recording events.\n2. *(e2e tests execute)*\n3. **`CollectData()`** — final data collection pass.\n4. **`ConstructComputedIntervals()`** — analyze raw data into structured intervals.\n5. **`EvaluateTestsFromConstructedIntervals()`** — produce JUnit pass/fail results.\n\nMonitor tests are registered in `pkg/defaultmonitortests/types.go` with two stability levels: **Stable** (normal operation — runs all monitors including availability checks) and **Disruptive** (tests that intentionally cause outages like upgrades, node drains, etcd recovery, or cert rotation — availability monitors are excluded since measuring uptime during intentional disruption would produce false failures). Implementations live in `pkg/monitortests/` organized by component — examples include etcd log analysis, cluster operator state tracking, node readiness, API server availability, and alert evaluation.\n\n### Disruption tests\n\nDisruption tests are a category of monitor test that measure **endpoint availability** during test runs. They continuously poll services (API servers, ingress, image registry, pod network) and record availability intervals. Allowed disruption baselines in `pkg/monitortestlibrary/allowedbackenddisruption/` define acceptable unavailability thresholds. Key implementations live in `pkg/monitortests/kubeapiserver/`, `pkg/monitortests/network/`, and `pkg/monitortests/imageregistry/`.\n\n### Extensions (OTE — OpenShift Tests Extension)\n\nThe `openshift-tests` binary acts as an **orchestrator** for tests contributed by other components. The [openshift-tests-extension](https://github.com/openshift-eng/openshift-tests-extension) (OTE) framework defines a standardized interface that external binaries implement:\n* **`<binary> info`** — return extension metadata (component, suites, version).\n* **`<binary> list -o jsonl`** — list available tests, filtered by environment (platform, arch, network).\n* **`<binary> run-test -n <name>`** — execute a specific test and return JSONL results.\n\n**Payload extensions** are test binaries shipped inside release payload images. The registry in `pkg/test/extensions/binary.go` maps ~35 payload image tags to their test binary paths. At runtime, `openshift-tests` extracts these binaries, discovers their tests, and runs them alongside built-in tests.\n\n**Non-payload extensions** are discovered from ImageStreamTags in the cluster and require explicit approval via a `TestExtensionAdmission` CRD. The `extension-admission` subcommand manages these approval rules.\n\nOrigin also registers itself as an extension (`openshift:payload:origin`) so its own built-in Ginkgo tests appear in the unified extension registry alongside external tests.\n\n### Build and verify\n\n* **Build:** `make build` or `make openshift-tests` (produces `./openshift-tests`).\n* **Unit tests:** `go test ./pkg/...` (fast, no cluster required).\n* **Lint / verify:** `make verify` (runs `go vet`, jsonformat, generated-file checks, TLS ownership).\n* **Full check:** `make check` (verify + build + tests).\n\nFavor clarity and maintainability over cleverness. Comments should be minimal, helpful, and explain the \"why\" not the \"what\".\n\n## Files matching `**/*_test.go`\n\n<!-- Source: local .apm/instructions/testing.instructions.md -->\n* Use `go vet ./...` and `go test ./pkg/...` to validate changes before committing.\n* E2e tests in `test/extended/<area>/` are **platform-level tests for OpenShift** — they run against a live cluster to validate the product, not just this repo. They use the **Ginkgo** framework and are compiled into the `openshift-tests` binary that CI runs against every payload.\n* `test/extended/include.go` blank-imports every e2e test package — new packages **must** be added there or they won't be compiled into the binary.\n* Unit tests in `pkg/` use standard Go `testing` with **table-driven** patterns.\n* Build the test binary: `make openshift-tests` or `make build`.\n* For unit tests, prefer **table-driven tests** with descriptive case names. Search the same package for existing test patterns before writing new ones.\n\n---\n*This file was generated by APM CLI. Do not edit manually.*\n*To regenerate: `apm compile`*\n",".claude/commands/update-all-operator-watch-request-limits.md":"---\ndescription: Bulk update all operator watch request limits from BigQuery data\nargument-hint: <release>\n---\n\n## Name\n\nupdate-all-operator-watch-request-limits\n\n## Synopsis\n\n```\n/update-all-operator-watch-request-limits <release>\n```\n\n## Description\n\nThe `update-all-operator-watch-request-limits` command performs a bulk update of ALL operator watch request limits in the test by querying live data from BigQuery. This is used to refresh all limits at once based on recent CI data (last 30 days), rather than updating operators one at a time.\n\n**What this command does:**\n1. Runs `.claude/scripts/query_operator_watch_requests.py` to fetch BigQuery data for the specified release\n2. Pipes the JSON results to `.claude/scripts/update_operator_watch_limits.py` to update the JSON file\n3. Updates ALL existing limits in the JSON file for both topologies (HighlyAvailable and SingleReplica)\n4. Shows a categorized summary of all changes as they're applied:\n   - Critical increases (>10x) - likely bugs\n   - Warning increases (2x-10x) - need investigation\n   - Major decreases (<50%) - significant reductions\n   - Normal increases/decreases - expected changes\n\n**Important notes:**\n- Uses the P99 over the past 30 days. Note the test allows 2x this limit before it will complain allowing for natural growth.\n- Only updates operators that already exist in the JSON (doesn't add new ones automatically)\n- Updates `operator_watch_limits.json` directly \n- Preserves JSON formatting and structure\n- Highlights concerning increases for manual review before committing\n\n## Implementation\n\n### 1. Fetch BigQuery Data and Update Limits\n\nExecutes the query script and pipes output to the update script:\n\n```bash\n# Query BigQuery and pipe directly to update script\npython3 .claude/scripts/query_operator_watch_requests.py \"$RELEASE\" | \\\n  python3 .claude/scripts/update_operator_watch_limits.py\n```\n\nThe query script:\n- Invokes `bq query` via command line with `--max_rows=1000` to handle all results (up from default 100)\n- Queries the `openshift-ci-data-analysis.ci_data_autodl.operator_watch_requests` table\n- Uses the last 30 days of data for the specified release\n- Outputs JSON to stdout (piped to update script)\n\nThe update script:\n- Reads JSON from stdin\n- Updates operator_watch_limits.json with new values\n- Tracks all changes as it processes them\n- Categorizes changes by severity (critical, warning, decreases, normal)\n- Outputs a comprehensive summary at the end\n\n**Expected JSON results:**\n```json\n[{\n  \"Platform\": \"aws\",\n  \"Release\": \"4.22\",\n  \"Topology\": \"ha\",\n  \"Operator\": \"cluster-capi-operator\",\n  \"Average\": \"117.0\",\n  \"Max_WatchCount\": \"216\",\n  \"P99_WatchCount\": \"199\"\n}, ...]\n```\n\n### 2. Summarize Changes\n\nAfter updating the JSON file, summarize the changes using git diff:\n\n```bash\n# Show summary of what changed\npython3 .claude/scripts/summarize_operator_watch_changes.py\n```\n\nThe summarize script:\n- Parses `git diff` of operator_watch_limits.json\n- Categorizes changes: critical (>10x), warning (2x-10x), decreases (<50%), normal (<2x)\n- Provides a human-readable summary of all changes\n\nThe update script accepts JSON from stdin and:\n- Updates operator_watch_limits.json directly\n- Preserves JSON structure and formatting\n\n### 3. Parse and Map Data\n\n**Platform name mapping:**\n- `aws` → `AWS` (in JSON)\n- `azure` → `Azure` (in JSON)\n- `gcp` → `GCP` (in JSON)\n- `metal` → `BareMetal` (in JSON)\n- `vsphere` → `vSphere` (in JSON)\n- `openstack` → `OpenStack` (in JSON)\n\n**Topology mapping:**\n- `ha` → `HighlyAvailable` (in JSON)\n- `single` → `SingleReplica` (in JSON)\n\n**Operator name mapping:**\nThe BigQuery data may have operator names without `-operator` suffix. The command will:\n- Ensure the operator name ends with `-operator`\n- Match it against existing keys in the maps\n- Examples:\n  - `cluster-capi-operator` → `cluster-capi-operator` (already correct)\n  - `capi-operator` → Skip (not a known service account pattern, may be data issue)\n  - `cluster-monitoring` → `cluster-monitoring-operator`\n\n### 4. Update Limits in JSON\n\nFor each operator in the BigQuery results:\n\n1. Find the corresponding entry in the JSON file under the appropriate topology and platform\n2. Extract the P99 value and round to nearest integer\n3. Compare with old value and categorize the change\n4. Update the JSON entry with the new value\n5. Track the change for the summary report\n\nThe update script categorizes all changes as it processes them:\n- **Critical increases (>10x)** - likely bugs, need investigation\n- **Warning increases (2x-10x)** - need explanation\n- **Major decreases (<50%)** - significant reductions in watch usage\n- **Normal increases (<2x)** - expected growth\n- **Normal decreases (>50%)** - minor reductions\n- **Unchanged** - P99 matches current limit\n- **Skipped** - operators in BigQuery but not in JSON\n\nAfter processing all changes:\n- Outputs a comprehensive summary showing all categorized changes\n\n### 5. Validation\n\nAfter updating, validate the changes:\n- Review the comprehensive summary output for concerning changes\n- Pay special attention to critical (>10x) and warning (2x-10x) increases\n- If needed, run `git diff pkg/monitortests/kubeapiserver/auditloganalyzer/operator_watch_limits.json` to see raw changes\n- Ensure the code still compiles: `go build ./pkg/monitortests/kubeapiserver/auditloganalyzer/...`\n- Review and investigate critical/warning increases before committing\n\n## Return Value\n\n- **Claude agent text**: Detailed report of all updates with warnings and summary of changes\n- **Side effects**:\n  - Modified file: `pkg/monitortests/kubeapiserver/auditloganalyzer/operator_watch_limits.json`\n  - All operator limits updated from BigQuery data\n  - Git changes ready for review and commit\n\n## Example\n\n**Usage:**\n```\n/update-all-operator-watch-request-limits 4.22\n```\n\n**Output:**\n```\nQuerying BigQuery for release 4.22 (last 30 days)...\nProject: openshift-ci-data-analysis\nDataset: ci_data_autodl.operator_watch_requests\n✅ Query completed, retrieved 250 results\n\nReading BigQuery data from stdin...\nLoading: pkg/monitortests/kubeapiserver/auditloganalyzer/operator_watch_limits.json\nWriting: pkg/monitortests/kubeapiserver/auditloganalyzer/operator_watch_limits.json\n\n================================================================================\nOPERATOR WATCH LIMIT CHANGES SUMMARY\n================================================================================\n\n🚨 CRITICAL INCREASES (>10x) - 1 operators:\n  ❌ cluster-monitoring-operator (AWS/HighlyAvailable): 186 → 2100 (11.3x)\n\n⚠️  WARNING INCREASES (2x-10x) - 2 operators:\n  ⚠️  marketplace-operator (GCP/HighlyAvailable): 45 → 95 (2.1x)\n  ⚠️  ingress-operator (Azure/HighlyAvailable): 541 → 890 (1.6x)\n\n📉 MAJOR DECREASES (<50%) - 1 operators:\n  📉 dns-operator (vSphere/HighlyAvailable): 120 → 55 (-54%)\n\n✅ NORMAL INCREASES (<2x) - 115 operators:\n  ✅ cluster-capi-operator (AWS/HighlyAvailable): 205 → 220 (+7%)\n  ✅ authentication-operator (AWS/HighlyAvailable): 519 → 530 (+2%)\n  ✅ etcd-operator (AWS/HighlyAvailable): 245 → 252 (+3%)\n  ✅ console-operator (Azure/HighlyAvailable): 212 → 218 (+3%)\n  ✅ kube-apiserver-operator (GCP/HighlyAvailable): 260 → 275 (+6%)\n  ... and 110 more\n\n📊 NORMAL DECREASES (>50%) - 3 operators:\n  📊 prometheus-operator (OpenStack/HighlyAvailable): 125 → 118 (-6%)\n  📊 service-ca-operator (BareMetal/HighlyAvailable): 135 → 130 (-4%)\n  📊 cluster-samples-operator (Azure/SingleReplica): 40 → 38 (-5%)\n  ... and 0 more\n\n⏭️  SKIPPED - 2 operators not found in JSON:\n  ⏭️  new-test-operator (AWS/HighlyAvailable) - not in JSON\n  ⏭️  experimental-operator (GCP/HighlyAvailable) - not in JSON\n\n================================================================================\nTOTAL: 122 limits changed across 120 operators\n  Critical (>10x): 1\n  Warning (2x-10x): 2\n  Major decreases (<50%): 1\n  Normal increases (<2x): 115\n  Normal decreases (>50%): 3\n  Unchanged: 78\n  Skipped: 2\n================================================================================\n\n⚠️  1 CRITICAL changes detected - review before committing!\n```\n\n## Arguments\n\n- **$1** (required): OpenShift release version\n  - Format: `X.YY` (e.g., `4.22`, `4.23`, `4.21`)\n  - This will be used in the BigQuery query to filter data for that specific release\n  - The query will fetch the last 30 days of data for this release\n\n## BigQuery Query Details\n\nThe command uses the Python script `.claude/scripts/query_operator_watch_requests.py` to fetch data. \n\n## Notes\n\n- **Uses Python scripts**: Two scripts work together:\n  - `query_operator_watch_requests.py` - Queries BigQuery\n  - `update_operator_watch_limits.py` - Updates JSON file and provides comprehensive summary\n- **Requires `bq` CLI**: Google Cloud SDK must be installed and authenticated (`gcloud auth login`)\n- **BigQuery project**: Always queries `openshift-ci-data-analysis` project\n- **Dataset**: Uses `ci_data_autodl.operator_watch_requests` table\n- **Max rows**: Query limited to 1000 results (up from default 100) to handle all operator/platform/topology combinations\n- **Fixed time window**: Always uses 30 days of data (not configurable - ensures reliable averages)\n- **Release specific**: Only queries data for the specified OpenShift release version\n- **Review before commit**: Always review critical and warning increases before committing\n- **Operator names**: The BigQuery Operator field should match service account names (with or without `-operator` suffix)\n- **Platform names**: Must use lowercase names that match the BigQuery schema (aws, gcp, metal, azure, vsphere, openstack)\n- **Uses Average**: Intentionally uses Average instead of P99/Max because test allows 2x headroom\n- **Preserves unknowns**: Operators not in BigQuery results keep their current values\n- **JSON structure**: Updates `operator_watch_limits.json` directly, organized by topology → platform → operator\n- **Formatting**: Maintains JSON indentation and structure\n- **Re-runnable query**: You can re-run just the BigQuery query with `python3 .claude/scripts/query_operator_watch_requests.py 4.22`\n- **Comprehensive summary**: The update script tracks and categorizes all changes as it processes them, providing a detailed summary at the end\n\n## Error Handling\n\n- **Missing release parameter**: Prompts user to provide release version (e.g., `4.22`)\n- **Invalid release format**: Validates release matches pattern like `4.22` or `4.23`\n- **BigQuery query fails**: Shows error message and exits without modifying files\n- **bq CLI not available**: Checks for `bq` command and provides installation instructions\n- **Authentication required**: Prompts to run `gcloud auth login` if not authenticated\n- **Invalid JSON**: Reports parsing errors with line numbers\n- **Missing fields**: Warns about records missing Platform/Topology/Operator/Average\n- **Unknown platform**: Warns and skips operators on platforms not in the maps\n- **Operator not found**: Notes operators in BigQuery data that don't exist in maps (won't add them)\n- **Compilation fails**: Reverts changes and reports Go build errors\n- **No data**: If query returns empty results, exits without changes and suggests checking the release version\n\n## Warnings\n\n- ⚠️  **Critical increases (>10x)** almost always indicate bugs - investigate before committing\n- ⚠️  **Large increases (2x-10x)** need explanation - check recent code changes\n- ⚠️  **Review the diff** - ensure formatting is preserved and changes make sense\n- ⚠️  **Test compilation** - the command validates but always verify manually\n- ⚠️  **Single node data** - upperBoundsSingleNode only has AWS platform, query may return data for other platforms that can't be used\n\n## See Also\n\n- Python scripts:\n  - `.claude/scripts/query_operator_watch_requests.py` - Fetch BigQuery data for a release\n  - `.claude/scripts/update_operator_watch_limits.py` - Update limits in JSON file and provide summary\n- `/update-operator-watch-request-limits` - Update a single operator limit manually\n- Limits file: `pkg/monitortests/kubeapiserver/auditloganalyzer/operator_watch_limits.json`\n- Test implementation: `pkg/monitortests/kubeapiserver/auditloganalyzer/handle_operator_watch_count_tracking.go`\n- BigQuery dataset: `openshift-ci-data-analysis.ci_data_autodl.operator_watch_requests`\n- Grafana dashboard for exploring avg watch requests over time per operator/platform/etc: https://grafana-loki.ci.openshift.org/d/4RcxG4tSz/watch-counts\n",".cursor/mcp.json":"{\n  \"mcpServers\": {\n    \"atlassian\": {\n      \"type\": \"http\",\n      \"url\": \"https://mcp.atlassian.com/v1/mcp\"\n    }\n  }\n}","GEMINI.md":"# GEMINI.md\n<!-- Generated by APM CLI -->\n<!-- Build ID: 01de98569d95 -->\n<!-- APM Version: 0.13.0 -->\n\n@./AGENTS.md\n",".cursor/rules/testing.mdc":"---\ndescription: Testing guidelines and patterns for origin\nglobs: \"**/*_test.go\"\n---\n\n* Use `go vet ./...` and `go test ./pkg/...` to validate changes before committing.\n* E2e tests in `test/extended/<area>/` are **platform-level tests for OpenShift** — they run against a live cluster to validate the product, not just this repo. They use the **Ginkgo** framework and are compiled into the `openshift-tests` binary that CI runs against every payload.\n* `test/extended/include.go` blank-imports every e2e test package — new packages **must** be added there or they won't be compiled into the binary.\n* Unit tests in `pkg/` use standard Go `testing` with **table-driven** patterns.\n* Build the test binary: `make openshift-tests` or `make build`.\n* For unit tests, prefer **table-driven tests** with descriptive case names. Search the same package for existing test patterns before writing new ones.\n",".claude/rules/general.md":"---\npaths:\n  - \"**\"\n---\n\n### APM context generation\n\nSources under **`.apm/`** (instructions, prompts, `apm.yml`, etc.) drive generated agent context. After editing those files, run **`make apm`** to regenerate **AGENTS.md**, **CLAUDE.md**, **GEMINI.md**, and the integrated copies under **`.claude/`**, **`.cursor/`**, **`.gemini/`**, **`.github/instructions/`**, **`.github/prompts/`**, and **`.opencode/`**.\n\n**Slash / agent commands:** content under **`.apm/prompts/*.prompt.md`** is the single source of truth. **`apm install`** (part of **`make apm`**) copies each prompt into editor command targets (e.g. **`.claude/commands/`**, **`.opencode/commands/`**, **`.gemini/commands/`**). Do not add those generated paths by hand or installs will skip them as unmanaged duplicates.\n\n### Retry allowlist policy\n\n**`pkg/test/ginkgo/retry_allowed_tests.yaml`** is strictly shrink-only. Never add tests to it. Remove an entry only when its underlying flake is fixed. If a requested change conflicts with this policy, stop and ask for human direction.\n\n### Repository overview\n\n**openshift/origin** builds the `openshift-tests` binary — the orchestrator for all OpenShift end-to-end testing. It contains:\n* **Built-in e2e tests** (Ginkgo) that run against a live cluster.\n* **Monitor tests** that observe cluster health in the background during e2e runs.\n* **Disruption tests** (a category of monitor test) that measure endpoint availability.\n* **Extension orchestration** that discovers and runs tests contributed by other components via the OTE framework.\n\n### Key directories\n\n* **`cmd/openshift-tests/`** — main binary entry point with subcommands: `run`, `run-test`, `run-monitor`, `run-upgrade`, `disruption`, `list`, `info`, `extension-admission`, and more.\n* **`pkg/testsuites/`** — test suite definitions that compose built-in and extension tests.\n* **`test/extended/`** — Ginkgo-based e2e test packages organized by area (e.g. `networking/`, `storage/`, `etcd/`).\n* **`test/extended/include.go`** — blank imports that register all e2e test packages. New packages **must** be added here.\n* **`test/e2e/upgrade/`** — upgrade-specific e2e tests.\n* **`pkg/monitortestframework/`** — `MonitorTest` interface and registry.\n* **`pkg/defaultmonitortests/`** — registers default monitor tests for stable and disruptive scenarios.\n* **`pkg/monitortests/`** — individual monitor test implementations organized by component (e.g. `etcd/`, `kubeapiserver/`, `network/`, `node/`).\n* **`pkg/monitortestlibrary/`** — shared monitor utilities (allowed disruption baselines, alert allowlists, platform identification).\n* **`pkg/disruption/`** — disruption measurement framework (HTTP/gRPC sampling, transport hooks, shutdown detection).\n* **`pkg/test/extensions/`** — OTE extension binary extraction, execution, and admission control.\n* **`vendor/`** — vendored dependencies. Run `go mod tidy && go mod vendor` after changing `go.mod` to keep `go.sum` and `vendor/` in sync.\n\n### E2e tests\n\nGinkgo-based tests in `test/extended/<area>/` run against a live OpenShift cluster. Each package is registered via blank import in `test/extended/include.go`. These are the \"built-in\" tests that ship inside the `openshift-tests` binary. Tests are grouped into suites (e.g. `openshift/conformance/parallel`) defined in `pkg/testsuites/`.\n\n### Monitor tests\n\nMonitor tests run **in parallel** with the e2e suite to continuously observe cluster health. They follow a lifecycle:\n1. **`StartCollection()`** — begin watching resources, recording events.\n2. *(e2e tests execute)*\n3. **`CollectData()`** — final data collection pass.\n4. **`ConstructComputedIntervals()`** — analyze raw data into structured intervals.\n5. **`EvaluateTestsFromConstructedIntervals()`** — produce JUnit pass/fail results.\n\nMonitor tests are registered in `pkg/defaultmonitortests/types.go` with two stability levels: **Stable** (normal operation — runs all monitors including availability checks) and **Disruptive** (tests that intentionally cause outages like upgrades, node drains, etcd recovery, or cert rotation — availability monitors are excluded since measuring uptime during intentional disruption would produce false failures). Implementations live in `pkg/monitortests/` organized by component — examples include etcd log analysis, cluster operator state tracking, node readiness, API server availability, and alert evaluation.\n\n### Disruption tests\n\nDisruption tests are a category of monitor test that measure **endpoint availability** during test runs. They continuously poll services (API servers, ingress, image registry, pod network) and record availability intervals. Allowed disruption baselines in `pkg/monitortestlibrary/allowedbackenddisruption/` define acceptable unavailability thresholds. Key implementations live in `pkg/monitortests/kubeapiserver/`, `pkg/monitortests/network/`, and `pkg/monitortests/imageregistry/`.\n\n### Extensions (OTE — OpenShift Tests Extension)\n\nThe `openshift-tests` binary acts as an **orchestrator** for tests contributed by other components. The [openshift-tests-extension](https://github.com/openshift-eng/openshift-tests-extension) (OTE) framework defines a standardized interface that external binaries implement:\n* **`<binary> info`** — return extension metadata (component, suites, version).\n* **`<binary> list -o jsonl`** — list available tests, filtered by environment (platform, arch, network).\n* **`<binary> run-test -n <name>`** — execute a specific test and return JSONL results.\n\n**Payload extensions** are test binaries shipped inside release payload images. The registry in `pkg/test/extensions/binary.go` maps ~35 payload image tags to their test binary paths. At runtime, `openshift-tests` extracts these binaries, discovers their tests, and runs them alongside built-in tests.\n\n**Non-payload extensions** are discovered from ImageStreamTags in the cluster and require explicit approval via a `TestExtensionAdmission` CRD. The `extension-admission` subcommand manages these approval rules.\n\nOrigin also registers itself as an extension (`openshift:payload:origin`) so its own built-in Ginkgo tests appear in the unified extension registry alongside external tests.\n\n### Build and verify\n\n* **Build:** `make build` or `make openshift-tests` (produces `./openshift-tests`).\n* **Unit tests:** `go test ./pkg/...` (fast, no cluster required).\n* **Lint / verify:** `make verify` (runs `go vet`, jsonformat, generated-file checks, TLS ownership).\n* **Full check:** `make check` (verify + build + tests).\n\nFavor clarity and maintainability over cleverness. Comments should be minimal, helpful, and explain the \"why\" not the \"what\".\n",".claude/rules/testing.md":"---\npaths:\n  - \"**/*_test.go\"\n---\n\n* Use `go vet ./...` and `go test ./pkg/...` to validate changes before committing.\n* E2e tests in `test/extended/<area>/` are **platform-level tests for OpenShift** — they run against a live cluster to validate the product, not just this repo. They use the **Ginkgo** framework and are compiled into the `openshift-tests` binary that CI runs against every payload.\n* `test/extended/include.go` blank-imports every e2e test package — new packages **must** be added there or they won't be compiled into the binary.\n* Unit tests in `pkg/` use standard Go `testing` with **table-driven** patterns.\n* Build the test binary: `make openshift-tests` or `make build`.\n* For unit tests, prefer **table-driven tests** with descriptive case names. Search the same package for existing test patterns before writing new ones.\n",".cursor/commands/origin-dev-setup.md":"---\ndescription: Set up the Origin devcontainer (Podman, env, GCP auth)\n---\n\n# Origin dev — devcontainer setup\n\nInteractive setup for the Origin devcontainer. Automates what can be detected, prompts for what can't.\n\n## Workflow\n\n### 1. Detect OS\n\n```bash\nuname -s\n```\n\n- **Darwin** = macOS\n- **Linux** = Linux\n\n### 2. Check prerequisites\n\nVerify each tool is installed. Report any that are missing and stop.\n\n```bash\ncommand -v podman\ncommand -v devcontainer\n```\n\nIf `devcontainer` is missing, tell the user: `npm install -g @devcontainers/cli`\n\n### 3. macOS: Podman machine\n\nIf macOS, check if podman machine is running:\n\n```bash\npodman machine info\n```\n\nIf not initialized or not running, run:\n\n```bash\npodman machine init   # only if no machine exists\npodman machine start\n```\n\n### 4. Linux: Podman socket\n\nIf Linux, check if the socket is active:\n\n```bash\nsystemctl --user is-active podman.socket\n```\n\nIf not active, run:\n\n```bash\nsystemctl --user enable --now podman.socket\n```\n\nAlso check for `podman-docker`:\n\n```bash\ncommand -v docker\n```\n\nIf missing, suggest installing `podman-docker` (dnf or apt depending on `/etc/os-release`).\n\n### 5. Environment file\n\nCheck if `.devcontainer/.env` exists:\n\n```bash\ntest -f .devcontainer/.env\n```\n\nIf missing, copy from the example:\n\n```bash\ncp .devcontainer/.env.example .devcontainer/.env\n```\n\nThen read `.devcontainer/.env` and check for empty required values. If any are blank (e.g. `ANTHROPIC_VERTEX_PROJECT_ID`), tell the user which values need to be filled in and ask them to edit `.devcontainer/.env` and let you know when they're done. **Do not** ask for the values directly or write to the file yourself — the user should edit it. Wait for them to confirm before continuing.\n\n### 6. Start the container\n\nDetermine the right command based on OS:\n\n- **macOS**: `devcontainer up --workspace-folder . --docker-path podman`\n- **Linux** (with `podman-docker`): `devcontainer up --workspace-folder .`\n- **Linux** (without `podman-docker`): `devcontainer up --workspace-folder . --docker-path podman`\n\nRun it. This triggers `post-create.sh` (Go tools, Claude Code, `make build`).\n\n### 7. GCP authentication\n\nGCP credentials are mounted from the host's `~/.config/gcloud` directory. If the user hasn't authenticated on the host yet, tell them to run on the host (not inside the container):\n\n```bash\ngcloud auth application-default login\n```\n\nThe credentials will be available inside the container automatically after restart.\n\n### 8. Summary\n\nPrint a summary of what was set up:\n\n- Container status\n- Claude Code: available via Vertex AI\n- GCP auth status\n- To exec in: `podman exec -it -u vscode -w /workspace origin-dev bash`",".opencode/commands/origin-dev-setup.md":"---\ndescription: Set up the Origin devcontainer (Podman, env, GCP auth)\n---\n\n# Origin dev — devcontainer setup\n\nInteractive setup for the Origin devcontainer. Automates what can be detected, prompts for what can't.\n\n## Workflow\n\n### 1. Detect OS\n\n```bash\nuname -s\n```\n\n- **Darwin** = macOS\n- **Linux** = Linux\n\n### 2. Check prerequisites\n\nVerify each tool is installed. Report any that are missing and stop.\n\n```bash\ncommand -v podman\ncommand -v devcontainer\n```\n\nIf `devcontainer` is missing, tell the user: `npm install -g @devcontainers/cli`\n\n### 3. macOS: Podman machine\n\nIf macOS, check if podman machine is running:\n\n```bash\npodman machine info\n```\n\nIf not initialized or not running, run:\n\n```bash\npodman machine init   # only if no machine exists\npodman machine start\n```\n\n### 4. Linux: Podman socket\n\nIf Linux, check if the socket is active:\n\n```bash\nsystemctl --user is-active podman.socket\n```\n\nIf not active, run:\n\n```bash\nsystemctl --user enable --now podman.socket\n```\n\nAlso check for `podman-docker`:\n\n```bash\ncommand -v docker\n```\n\nIf missing, suggest installing `podman-docker` (dnf or apt depending on `/etc/os-release`).\n\n### 5. Environment file\n\nCheck if `.devcontainer/.env` exists:\n\n```bash\ntest -f .devcontainer/.env\n```\n\nIf missing, copy from the example:\n\n```bash\ncp .devcontainer/.env.example .devcontainer/.env\n```\n\nThen read `.devcontainer/.env` and check for empty required values. If any are blank (e.g. `ANTHROPIC_VERTEX_PROJECT_ID`), tell the user which values need to be filled in and ask them to edit `.devcontainer/.env` and let you know when they're done. **Do not** ask for the values directly or write to the file yourself — the user should edit it. Wait for them to confirm before continuing.\n\n### 6. Start the container\n\nDetermine the right command based on OS:\n\n- **macOS**: `devcontainer up --workspace-folder . --docker-path podman`\n- **Linux** (with `podman-docker`): `devcontainer up --workspace-folder .`\n- **Linux** (without `podman-docker`): `devcontainer up --workspace-folder . --docker-path podman`\n\nRun it. This triggers `post-create.sh` (Go tools, Claude Code, `make build`).\n\n### 7. GCP authentication\n\nGCP credentials are mounted from the host's `~/.config/gcloud` directory. If the user hasn't authenticated on the host yet, tell them to run on the host (not inside the container):\n\n```bash\ngcloud auth application-default login\n```\n\nThe credentials will be available inside the container automatically after restart.\n\n### 8. Summary\n\nPrint a summary of what was set up:\n\n- Container status\n- Claude Code: available via Vertex AI\n- GCP auth status\n- To exec in: `podman exec -it -u vscode -w /workspace origin-dev bash`",".cursor/rules/general.mdc":"---\ndescription: Origin repository overview, architecture, and coding guidelines\nglobs: \"**\"\n---\n\n### APM context generation\n\nSources under **`.apm/`** (instructions, prompts, `apm.yml`, etc.) drive generated agent context. After editing those files, run **`make apm`** to regenerate **AGENTS.md**, **CLAUDE.md**, **GEMINI.md**, and the integrated copies under **`.claude/`**, **`.cursor/`**, **`.gemini/`**, **`.github/instructions/`**, **`.github/prompts/`**, and **`.opencode/`**.\n\n**Slash / agent commands:** content under **`.apm/prompts/*.prompt.md`** is the single source of truth. **`apm install`** (part of **`make apm`**) copies each prompt into editor command targets (e.g. **`.claude/commands/`**, **`.opencode/commands/`**, **`.gemini/commands/`**). Do not add those generated paths by hand or installs will skip them as unmanaged duplicates.\n\n### Retry allowlist policy\n\n**`pkg/test/ginkgo/retry_allowed_tests.yaml`** is strictly shrink-only. Never add tests to it. Remove an entry only when its underlying flake is fixed. If a requested change conflicts with this policy, stop and ask for human direction.\n\n### Repository overview\n\n**openshift/origin** builds the `openshift-tests` binary — the orchestrator for all OpenShift end-to-end testing. It contains:\n* **Built-in e2e tests** (Ginkgo) that run against a live cluster.\n* **Monitor tests** that observe cluster health in the background during e2e runs.\n* **Disruption tests** (a category of monitor test) that measure endpoint availability.\n* **Extension orchestration** that discovers and runs tests contributed by other components via the OTE framework.\n\n### Key directories\n\n* **`cmd/openshift-tests/`** — main binary entry point with subcommands: `run`, `run-test`, `run-monitor`, `run-upgrade`, `disruption`, `list`, `info`, `extension-admission`, and more.\n* **`pkg/testsuites/`** — test suite definitions that compose built-in and extension tests.\n* **`test/extended/`** — Ginkgo-based e2e test packages organized by area (e.g. `networking/`, `storage/`, `etcd/`).\n* **`test/extended/include.go`** — blank imports that register all e2e test packages. New packages **must** be added here.\n* **`test/e2e/upgrade/`** — upgrade-specific e2e tests.\n* **`pkg/monitortestframework/`** — `MonitorTest` interface and registry.\n* **`pkg/defaultmonitortests/`** — registers default monitor tests for stable and disruptive scenarios.\n* **`pkg/monitortests/`** — individual monitor test implementations organized by component (e.g. `etcd/`, `kubeapiserver/`, `network/`, `node/`).\n* **`pkg/monitortestlibrary/`** — shared monitor utilities (allowed disruption baselines, alert allowlists, platform identification).\n* **`pkg/disruption/`** — disruption measurement framework (HTTP/gRPC sampling, transport hooks, shutdown detection).\n* **`pkg/test/extensions/`** — OTE extension binary extraction, execution, and admission control.\n* **`vendor/`** — vendored dependencies. Run `go mod tidy && go mod vendor` after changing `go.mod` to keep `go.sum` and `vendor/` in sync.\n\n### E2e tests\n\nGinkgo-based tests in `test/extended/<area>/` run against a live OpenShift cluster. Each package is registered via blank import in `test/extended/include.go`. These are the \"built-in\" tests that ship inside the `openshift-tests` binary. Tests are grouped into suites (e.g. `openshift/conformance/parallel`) defined in `pkg/testsuites/`.\n\n### Monitor tests\n\nMonitor tests run **in parallel** with the e2e suite to continuously observe cluster health. They follow a lifecycle:\n1. **`StartCollection()`** — begin watching resources, recording events.\n2. *(e2e tests execute)*\n3. **`CollectData()`** — final data collection pass.\n4. **`ConstructComputedIntervals()`** — analyze raw data into structured intervals.\n5. **`EvaluateTestsFromConstructedIntervals()`** — produce JUnit pass/fail results.\n\nMonitor tests are registered in `pkg/defaultmonitortests/types.go` with two stability levels: **Stable** (normal operation — runs all monitors including availability checks) and **Disruptive** (tests that intentionally cause outages like upgrades, node drains, etcd recovery, or cert rotation — availability monitors are excluded since measuring uptime during intentional disruption would produce false failures). Implementations live in `pkg/monitortests/` organized by component — examples include etcd log analysis, cluster operator state tracking, node readiness, API server availability, and alert evaluation.\n\n### Disruption tests\n\nDisruption tests are a category of monitor test that measure **endpoint availability** during test runs. They continuously poll services (API servers, ingress, image registry, pod network) and record availability intervals. Allowed disruption baselines in `pkg/monitortestlibrary/allowedbackenddisruption/` define acceptable unavailability thresholds. Key implementations live in `pkg/monitortests/kubeapiserver/`, `pkg/monitortests/network/`, and `pkg/monitortests/imageregistry/`.\n\n### Extensions (OTE — OpenShift Tests Extension)\n\nThe `openshift-tests` binary acts as an **orchestrator** for tests contributed by other components. The [openshift-tests-extension](https://github.com/openshift-eng/openshift-tests-extension) (OTE) framework defines a standardized interface that external binaries implement:\n* **`<binary> info`** — return extension metadata (component, suites, version).\n* **`<binary> list -o jsonl`** — list available tests, filtered by environment (platform, arch, network).\n* **`<binary> run-test -n <name>`** — execute a specific test and return JSONL results.\n\n**Payload extensions** are test binaries shipped inside release payload images. The registry in `pkg/test/extensions/binary.go` maps ~35 payload image tags to their test binary paths. At runtime, `openshift-tests` extracts these binaries, discovers their tests, and runs them alongside built-in tests.\n\n**Non-payload extensions** are discovered from ImageStreamTags in the cluster and require explicit approval via a `TestExtensionAdmission` CRD. The `extension-admission` subcommand manages these approval rules.\n\nOrigin also registers itself as an extension (`openshift:payload:origin`) so its own built-in Ginkgo tests appear in the unified extension registry alongside external tests.\n\n### Build and verify\n\n* **Build:** `make build` or `make openshift-tests` (produces `./openshift-tests`).\n* **Unit tests:** `go test ./pkg/...` (fast, no cluster required).\n* **Lint / verify:** `make verify` (runs `go vet`, jsonformat, generated-file checks, TLS ownership).\n* **Full check:** `make check` (verify + build + tests).\n\nFavor clarity and maintainability over cleverness. Comments should be minimal, helpful, and explain the \"why\" not the \"what\".\n","tools/etcdhelper/README.md":"# etcdhelper Documentation\n\nPath: `tools/etcdhelper/README.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/openshift/origin/HEAD/tools/etcdhelper/README.md)","tools/junitreport/README.md":"# junitreport Documentation\n\nPath: `tools/junitreport/README.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/openshift/origin/HEAD/tools/junitreport/README.md)","vendor/github.com/google/gnostic-models/extensions/README.md":"# extensions Documentation\n\nPath: `vendor/github.com/google/gnostic-models/extensions/README.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/openshift/origin/HEAD/vendor/github.com/google/gnostic-models/extensions/README.md)","vendor/k8s.io/kubernetes/pkg/scheduler/framework/plugins/README.md":"# plugins Documentation\n\nPath: `vendor/k8s.io/kubernetes/pkg/scheduler/framework/plugins/README.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/openshift/origin/HEAD/vendor/k8s.io/kubernetes/pkg/scheduler/framework/plugins/README.md)"},"files":{"AGENTS.md":"# AGENTS.md\n<!-- Generated by APM CLI from distributed .apm/ primitives -->\n<!-- Build ID: 3109b13c034b -->\n<!-- APM Version: 0.13.0 -->\n<!-- Source: local -->\n\n## Files matching `**`\n\n<!-- Source: local .apm/instructions/general.instructions.md -->\n### APM context generation\n\nSources under **`.apm/`** (instructions, prompts, `apm.yml`, etc.) drive generated agent context. After editing those files, run **`make apm`** to regenerate **AGENTS.md**, **CLAUDE.md**, **GEMINI.md**, and the integrated copies under **`.claude/`**, **`.cursor/`**, **`.gemini/`**, **`.github/instructions/`**, **`.github/prompts/`**, and **`.opencode/`**.\n\n**Slash / agent commands:** content under **`.apm/prompts/*.prompt.md`** is the single source of truth. **`apm install`** (part of **`make apm`**) copies each prompt into editor command targets (e.g. **`.claude/commands/`**, **`.opencode/commands/`**, **`.gemini/commands/`**). Do not add those generated paths by hand or installs will skip them as unmanaged duplicates.\n\n### Retry allowlist policy\n\n**`pkg/test/ginkgo/retry_allowed_tests.yaml`** is strictly shrink-only. Never add tests to it. Remove an entry only when its underlying flake is fixed. If a requested change conflicts with this policy, stop and ask for human direction.\n\n### Repository overview\n\n**openshift/origin** builds the `openshift-tests` binary — the orchestrator for all OpenShift end-to-end testing. It contains:\n* **Built-in e2e tests** (Ginkgo) that run against a live cluster.\n* **Monitor tests** that observe cluster health in the background during e2e runs.\n* **Disruption tests** (a category of monitor test) that measure endpoint availability.\n* **Extension orchestration** that discovers and runs tests contributed by other components via the OTE framework.\n\n### Key directories\n\n* **`cmd/openshift-tests/`** — main binary entry point with subcommands: `run`, `run-test`, `run-monitor`, `run-upgrade`, `disruption`, `list`, `info`, `extension-admission`, and more.\n* **`pkg/testsuites/`** — test suite definitions that compose built-in and extension tests.\n* **`test/extended/`** — Ginkgo-based e2e test packages organized by area (e.g. `networking/`, `storage/`, `etcd/`).\n* **`test/extended/include.go`** — blank imports that register all e2e test packages. New packages **must** be added here.\n* **`test/e2e/upgrade/`** — upgrade-specific e2e tests.\n* **`pkg/monitortestframework/`** — `MonitorTest` interface and registry.\n* **`pkg/defaultmonitortests/`** — registers default monitor tests for stable and disruptive scenarios.\n* **`pkg/monitortests/`** — individual monitor test implementations organized by component (e.g. `etcd/`, `kubeapiserver/`, `network/`, `node/`).\n* **`pkg/monitortestlibrary/`** — shared monitor utilities (allowed disruption baselines, alert allowlists, platform identification).\n* **`pkg/disruption/`** — disruption measurement framework (HTTP/gRPC sampling, transport hooks, shutdown detection).\n* **`pkg/test/extensions/`** — OTE extension binary extraction, execution, and admission control.\n* **`vendor/`** — vendored dependencies. Run `go mod tidy && go mod vendor` after changing `go.mod` to keep `go.sum` and `vendor/` in sync.\n\n### E2e tests\n\nGinkgo-based tests in `test/extended/<area>/` run against a live OpenShift cluster. Each package is registered via blank import in `test/extended/include.go`. These are the \"built-in\" tests that ship inside the `openshift-tests` binary. Tests are grouped into suites (e.g. `openshift/conformance/parallel`) defined in `pkg/testsuites/`.\n\n### Monitor tests\n\nMonitor tests run **in parallel** with the e2e suite to continuously observe cluster health. They follow a lifecycle:\n1. **`StartCollection()`** — begin watching resources, recording events.\n2. *(e2e tests execute)*\n3. **`CollectData()`** — final data collection pass.\n4. **`ConstructComputedIntervals()`** — analyze raw data into structured intervals.\n5. **`EvaluateTestsFromConstructedIntervals()`** — produce JUnit pass/fail results.\n\nMonitor tests are registered in `pkg/defaultmonitortests/types.go` with two stability levels: **Stable** (normal operation — runs all monitors including availability checks) and **Disruptive** (tests that intentionally cause outages like upgrades, node drains, etcd recovery, or cert rotation — availability monitors are excluded since measuring uptime during intentional disruption would produce false failures). Implementations live in `pkg/monitortests/` organized by component — examples include etcd log analysis, cluster operator state tracking, node readiness, API server availability, and alert evaluation.\n\n### Disruption tests\n\nDisruption tests are a category of monitor test that measure **endpoint availability** during test runs. They continuously poll services (API servers, ingress, image registry, pod network) and record availability intervals. Allowed disruption baselines in `pkg/monitortestlibrary/allowedbackenddisruption/` define acceptable unavailability thresholds. Key implementations live in `pkg/monitortests/kubeapiserver/`, `pkg/monitortests/network/`, and `pkg/monitortests/imageregistry/`.\n\n### Extensions (OTE — OpenShift Tests Extension)\n\nThe `openshift-tests` binary acts as an **orchestrator** for tests contributed by other components. The [openshift-tests-extension](https://github.com/openshift-eng/openshift-tests-extension) (OTE) framework defines a standardized interface that external binaries implement:\n* **`<binary> info`** — return extension metadata (component, suites, version).\n* **`<binary> list -o jsonl`** — list available tests, filtered by environment (platform, arch, network).\n* **`<binary> run-test -n <name>`** — execute a specific test and return JSONL results.\n\n**Payload extensions** are test binaries shipped inside release payload images. The registry in `pkg/test/extensions/binary.go` maps ~35 payload image tags to their test binary paths. At runtime, `openshift-tests` extracts these binaries, discovers their tests, and runs them alongside built-in tests.\n\n**Non-payload extensions** are discovered from ImageStreamTags in the cluster and require explicit approval via a `TestExtensionAdmission` CRD. The `extension-admission` subcommand manages these approval rules.\n\nOrigin also registers itself as an extension (`openshift:payload:origin`) so its own built-in Ginkgo tests appear in the unified extension registry alongside external tests.\n\n### Build and verify\n\n* **Build:** `make build` or `make openshift-tests` (produces `./openshift-tests`).\n* **Unit tests:** `go test ./pkg/...` (fast, no cluster required).\n* **Lint / verify:** `make verify` (runs `go vet`, jsonformat, generated-file checks, TLS ownership).\n* **Full check:** `make check` (verify + build + tests).\n\nFavor clarity and maintainability over cleverness. Comments should be minimal, helpful, and explain the \"why\" not the \"what\".\n\n## Files matching `**/*_test.go`\n\n<!-- Source: local .apm/instructions/testing.instructions.md -->\n* Use `go vet ./...` and `go test ./pkg/...` to validate changes before committing.\n* E2e tests in `test/extended/<area>/` are **platform-level tests for OpenShift** — they run against a live cluster to validate the product, not just this repo. They use the **Ginkgo** framework and are compiled into the `openshift-tests` binary that CI runs against every payload.\n* `test/extended/include.go` blank-imports every e2e test package — new packages **must** be added there or they won't be compiled into the binary.\n* Unit tests in `pkg/` use standard Go `testing` with **table-driven** patterns.\n* Build the test binary: `make openshift-tests` or `make build`.\n* For unit tests, prefer **table-driven tests** with descriptive case names. Search the same package for existing test patterns before writing new ones.\n\n---\n*This file was generated by APM CLI. Do not edit manually.*\n*To regenerate: `apm compile`*\n",".claude/commands/origin-dev-setup.md":"---\ndescription: Set up the Origin devcontainer (Podman, env, GCP auth)\n---\n\n# Origin dev — devcontainer setup\n\nInteractive setup for the Origin devcontainer. Automates what can be detected, prompts for what can't.\n\n## Workflow\n\n### 1. Detect OS\n\n```bash\nuname -s\n```\n\n- **Darwin** = macOS\n- **Linux** = Linux\n\n### 2. Check prerequisites\n\nVerify each tool is installed. Report any that are missing and stop.\n\n```bash\ncommand -v podman\ncommand -v devcontainer\n```\n\nIf `devcontainer` is missing, tell the user: `npm install -g @devcontainers/cli`\n\n### 3. macOS: Podman machine\n\nIf macOS, check if podman machine is running:\n\n```bash\npodman machine info\n```\n\nIf not initialized or not running, run:\n\n```bash\npodman machine init   # only if no machine exists\npodman machine start\n```\n\n### 4. Linux: Podman socket\n\nIf Linux, check if the socket is active:\n\n```bash\nsystemctl --user is-active podman.socket\n```\n\nIf not active, run:\n\n```bash\nsystemctl --user enable --now podman.socket\n```\n\nAlso check for `podman-docker`:\n\n```bash\ncommand -v docker\n```\n\nIf missing, suggest installing `podman-docker` (dnf or apt depending on `/etc/os-release`).\n\n### 5. Environment file\n\nCheck if `.devcontainer/.env` exists:\n\n```bash\ntest -f .devcontainer/.env\n```\n\nIf missing, copy from the example:\n\n```bash\ncp .devcontainer/.env.example .devcontainer/.env\n```\n\nThen read `.devcontainer/.env` and check for empty required values. If any are blank (e.g. `ANTHROPIC_VERTEX_PROJECT_ID`), tell the user which values need to be filled in and ask them to edit `.devcontainer/.env` and let you know when they're done. **Do not** ask for the values directly or write to the file yourself — the user should edit it. Wait for them to confirm before continuing.\n\n### 6. Start the container\n\nDetermine the right command based on OS:\n\n- **macOS**: `devcontainer up --workspace-folder . --docker-path podman`\n- **Linux** (with `podman-docker`): `devcontainer up --workspace-folder .`\n- **Linux** (without `podman-docker`): `devcontainer up --workspace-folder . --docker-path podman`\n\nRun it. This triggers `post-create.sh` (Go tools, Claude Code, `make build`).\n\n### 7. GCP authentication\n\nGCP credentials are mounted from the host's `~/.config/gcloud` directory. If the user hasn't authenticated on the host yet, tell them to run on the host (not inside the container):\n\n```bash\ngcloud auth application-default login\n```\n\nThe credentials will be available inside the container automatically after restart.\n\n### 8. Summary\n\nPrint a summary of what was set up:\n\n- Container status\n- Claude Code: available via Vertex AI\n- GCP auth status\n- To exec in: `podman exec -it -u vscode -w /workspace origin-dev bash`","CLAUDE.md":"# CLAUDE.md\n<!-- Generated by APM CLI -->\n<!-- Build ID: b79f3567f84e -->\n<!-- APM Version: 0.13.0 -->\n\n# Project Standards\n\n## Files matching `**`\n\n<!-- Source: local .apm/instructions/general.instructions.md -->\n### APM context generation\n\nSources under **`.apm/`** (instructions, prompts, `apm.yml`, etc.) drive generated agent context. After editing those files, run **`make apm`** to regenerate **AGENTS.md**, **CLAUDE.md**, **GEMINI.md**, and the integrated copies under **`.claude/`**, **`.cursor/`**, **`.gemini/`**, **`.github/instructions/`**, **`.github/prompts/`**, and **`.opencode/`**.\n\n**Slash / agent commands:** content under **`.apm/prompts/*.prompt.md`** is the single source of truth. **`apm install`** (part of **`make apm`**) copies each prompt into editor command targets (e.g. **`.claude/commands/`**, **`.opencode/commands/`**, **`.gemini/commands/`**). Do not add those generated paths by hand or installs will skip them as unmanaged duplicates.\n\n### Retry allowlist policy\n\n**`pkg/test/ginkgo/retry_allowed_tests.yaml`** is strictly shrink-only. Never add tests to it. Remove an entry only when its underlying flake is fixed. If a requested change conflicts with this policy, stop and ask for human direction.\n\n### Repository overview\n\n**openshift/origin** builds the `openshift-tests` binary — the orchestrator for all OpenShift end-to-end testing. It contains:\n* **Built-in e2e tests** (Ginkgo) that run against a live cluster.\n* **Monitor tests** that observe cluster health in the background during e2e runs.\n* **Disruption tests** (a category of monitor test) that measure endpoint availability.\n* **Extension orchestration** that discovers and runs tests contributed by other components via the OTE framework.\n\n### Key directories\n\n* **`cmd/openshift-tests/`** — main binary entry point with subcommands: `run`, `run-test`, `run-monitor`, `run-upgrade`, `disruption`, `list`, `info`, `extension-admission`, and more.\n* **`pkg/testsuites/`** — test suite definitions that compose built-in and extension tests.\n* **`test/extended/`** — Ginkgo-based e2e test packages organized by area (e.g. `networking/`, `storage/`, `etcd/`).\n* **`test/extended/include.go`** — blank imports that register all e2e test packages. New packages **must** be added here.\n* **`test/e2e/upgrade/`** — upgrade-specific e2e tests.\n* **`pkg/monitortestframework/`** — `MonitorTest` interface and registry.\n* **`pkg/defaultmonitortests/`** — registers default monitor tests for stable and disruptive scenarios.\n* **`pkg/monitortests/`** — individual monitor test implementations organized by component (e.g. `etcd/`, `kubeapiserver/`, `network/`, `node/`).\n* **`pkg/monitortestlibrary/`** — shared monitor utilities (allowed disruption baselines, alert allowlists, platform identification).\n* **`pkg/disruption/`** — disruption measurement framework (HTTP/gRPC sampling, transport hooks, shutdown detection).\n* **`pkg/test/extensions/`** — OTE extension binary extraction, execution, and admission control.\n* **`vendor/`** — vendored dependencies. Run `go mod tidy && go mod vendor` after changing `go.mod` to keep `go.sum` and `vendor/` in sync.\n\n### E2e tests\n\nGinkgo-based tests in `test/extended/<area>/` run against a live OpenShift cluster. Each package is registered via blank import in `test/extended/include.go`. These are the \"built-in\" tests that ship inside the `openshift-tests` binary. Tests are grouped into suites (e.g. `openshift/conformance/parallel`) defined in `pkg/testsuites/`.\n\n### Monitor tests\n\nMonitor tests run **in parallel** with the e2e suite to continuously observe cluster health. They follow a lifecycle:\n1. **`StartCollection()`** — begin watching resources, recording events.\n2. *(e2e tests execute)*\n3. **`CollectData()`** — final data collection pass.\n4. **`ConstructComputedIntervals()`** — analyze raw data into structured intervals.\n5. **`EvaluateTestsFromConstructedIntervals()`** — produce JUnit pass/fail results.\n\nMonitor tests are registered in `pkg/defaultmonitortests/types.go` with two stability levels: **Stable** (normal operation — runs all monitors including availability checks) and **Disruptive** (tests that intentionally cause outages like upgrades, node drains, etcd recovery, or cert rotation — availability monitors are excluded since measuring uptime during intentional disruption would produce false failures). Implementations live in `pkg/monitortests/` organized by component — examples include etcd log analysis, cluster operator state tracking, node readiness, API server availability, and alert evaluation.\n\n### Disruption tests\n\nDisruption tests are a category of monitor test that measure **endpoint availability** during test runs. They continuously poll services (API servers, ingress, image registry, pod network) and record availability intervals. Allowed disruption baselines in `pkg/monitortestlibrary/allowedbackenddisruption/` define acceptable unavailability thresholds. Key implementations live in `pkg/monitortests/kubeapiserver/`, `pkg/monitortests/network/`, and `pkg/monitortests/imageregistry/`.\n\n### Extensions (OTE — OpenShift Tests Extension)\n\nThe `openshift-tests` binary acts as an **orchestrator** for tests contributed by other components. The [openshift-tests-extension](https://github.com/openshift-eng/openshift-tests-extension) (OTE) framework defines a standardized interface that external binaries implement:\n* **`<binary> info`** — return extension metadata (component, suites, version).\n* **`<binary> list -o jsonl`** — list available tests, filtered by environment (platform, arch, network).\n* **`<binary> run-test -n <name>`** — execute a specific test and return JSONL results.\n\n**Payload extensions** are test binaries shipped inside release payload images. The registry in `pkg/test/extensions/binary.go` maps ~35 payload image tags to their test binary paths. At runtime, `openshift-tests` extracts these binaries, discovers their tests, and runs them alongside built-in tests.\n\n**Non-payload extensions** are discovered from ImageStreamTags in the cluster and require explicit approval via a `TestExtensionAdmission` CRD. The `extension-admission` subcommand manages these approval rules.\n\nOrigin also registers itself as an extension (`openshift:payload:origin`) so its own built-in Ginkgo tests appear in the unified extension registry alongside external tests.\n\n### Build and verify\n\n* **Build:** `make build` or `make openshift-tests` (produces `./openshift-tests`).\n* **Unit tests:** `go test ./pkg/...` (fast, no cluster required).\n* **Lint / verify:** `make verify` (runs `go vet`, jsonformat, generated-file checks, TLS ownership).\n* **Full check:** `make check` (verify + build + tests).\n\nFavor clarity and maintainability over cleverness. Comments should be minimal, helpful, and explain the \"why\" not the \"what\".\n\n## Files matching `**/*_test.go`\n\n<!-- Source: local .apm/instructions/testing.instructions.md -->\n* Use `go vet ./...` and `go test ./pkg/...` to validate changes before committing.\n* E2e tests in `test/extended/<area>/` are **platform-level tests for OpenShift** — they run against a live cluster to validate the product, not just this repo. They use the **Ginkgo** framework and are compiled into the `openshift-tests` binary that CI runs against every payload.\n* `test/extended/include.go` blank-imports every e2e test package — new packages **must** be added there or they won't be compiled into the binary.\n* Unit tests in `pkg/` use standard Go `testing` with **table-driven** patterns.\n* Build the test binary: `make openshift-tests` or `make build`.\n* For unit tests, prefer **table-driven tests** with descriptive case names. Search the same package for existing test patterns before writing new ones.\n\n---\n*This file was generated by APM CLI. Do not edit manually.*\n*To regenerate: `apm compile`*\n",".claude/commands/update-all-operator-watch-request-limits.md":"---\ndescription: Bulk update all operator watch request limits from BigQuery data\nargument-hint: <release>\n---\n\n## Name\n\nupdate-all-operator-watch-request-limits\n\n## Synopsis\n\n```\n/update-all-operator-watch-request-limits <release>\n```\n\n## Description\n\nThe `update-all-operator-watch-request-limits` command performs a bulk update of ALL operator watch request limits in the test by querying live data from BigQuery. This is used to refresh all limits at once based on recent CI data (last 30 days), rather than updating operators one at a time.\n\n**What this command does:**\n1. Runs `.claude/scripts/query_operator_watch_requests.py` to fetch BigQuery data for the specified release\n2. Pipes the JSON results to `.claude/scripts/update_operator_watch_limits.py` to update the JSON file\n3. Updates ALL existing limits in the JSON file for both topologies (HighlyAvailable and SingleReplica)\n4. Shows a categorized summary of all changes as they're applied:\n   - Critical increases (>10x) - likely bugs\n   - Warning increases (2x-10x) - need investigation\n   - Major decreases (<50%) - significant reductions\n   - Normal increases/decreases - expected changes\n\n**Important notes:**\n- Uses the P99 over the past 30 days. Note the test allows 2x this limit before it will complain allowing for natural growth.\n- Only updates operators that already exist in the JSON (doesn't add new ones automatically)\n- Updates `operator_watch_limits.json` directly \n- Preserves JSON formatting and structure\n- Highlights concerning increases for manual review before committing\n\n## Implementation\n\n### 1. Fetch BigQuery Data and Update Limits\n\nExecutes the query script and pipes output to the update script:\n\n```bash\n# Query BigQuery and pipe directly to update script\npython3 .claude/scripts/query_operator_watch_requests.py \"$RELEASE\" | \\\n  python3 .claude/scripts/update_operator_watch_limits.py\n```\n\nThe query script:\n- Invokes `bq query` via command line with `--max_rows=1000` to handle all results (up from default 100)\n- Queries the `openshift-ci-data-analysis.ci_data_autodl.operator_watch_requests` table\n- Uses the last 30 days of data for the specified release\n- Outputs JSON to stdout (piped to update script)\n\nThe update script:\n- Reads JSON from stdin\n- Updates operator_watch_limits.json with new values\n- Tracks all changes as it processes them\n- Categorizes changes by severity (critical, warning, decreases, normal)\n- Outputs a comprehensive summary at the end\n\n**Expected JSON results:**\n```json\n[{\n  \"Platform\": \"aws\",\n  \"Release\": \"4.22\",\n  \"Topology\": \"ha\",\n  \"Operator\": \"cluster-capi-operator\",\n  \"Average\": \"117.0\",\n  \"Max_WatchCount\": \"216\",\n  \"P99_WatchCount\": \"199\"\n}, ...]\n```\n\n### 2. Summarize Changes\n\nAfter updating the JSON file, summarize the changes using git diff:\n\n```bash\n# Show summary of what changed\npython3 .claude/scripts/summarize_operator_watch_changes.py\n```\n\nThe summarize script:\n- Parses `git diff` of operator_watch_limits.json\n- Categorizes changes: critical (>10x), warning (2x-10x), decreases (<50%), normal (<2x)\n- Provides a human-readable summary of all changes\n\nThe update script accepts JSON from stdin and:\n- Updates operator_watch_limits.json directly\n- Preserves JSON structure and formatting\n\n### 3. Parse and Map Data\n\n**Platform name mapping:**\n- `aws` → `AWS` (in JSON)\n- `azure` → `Azure` (in JSON)\n- `gcp` → `GCP` (in JSON)\n- `metal` → `BareMetal` (in JSON)\n- `vsphere` → `vSphere` (in JSON)\n- `openstack` → `OpenStack` (in JSON)\n\n**Topology mapping:**\n- `ha` → `HighlyAvailable` (in JSON)\n- `single` → `SingleReplica` (in JSON)\n\n**Operator name mapping:**\nThe BigQuery data may have operator names without `-operator` suffix. The command will:\n- Ensure the operator name ends with `-operator`\n- Match it against existing keys in the maps\n- Examples:\n  - `cluster-capi-operator` → `cluster-capi-operator` (already correct)\n  - `capi-operator` → Skip (not a known service account pattern, may be data issue)\n  - `cluster-monitoring` → `cluster-monitoring-operator`\n\n### 4. Update Limits in JSON\n\nFor each operator in the BigQuery results:\n\n1. Find the corresponding entry in the JSON file under the appropriate topology and platform\n2. Extract the P99 value and round to nearest integer\n3. Compare with old value and categorize the change\n4. Update the JSON entry with the new value\n5. Track the change for the summary report\n\nThe update script categorizes all changes as it processes them:\n- **Critical increases (>10x)** - likely bugs, need investigation\n- **Warning increases (2x-10x)** - need explanation\n- **Major decreases (<50%)** - significant reductions in watch usage\n- **Normal increases (<2x)** - expected growth\n- **Normal decreases (>50%)** - minor reductions\n- **Unchanged** - P99 matches current limit\n- **Skipped** - operators in BigQuery but not in JSON\n\nAfter processing all changes:\n- Outputs a comprehensive summary showing all categorized changes\n\n### 5. Validation\n\nAfter updating, validate the changes:\n- Review the comprehensive summary output for concerning changes\n- Pay special attention to critical (>10x) and warning (2x-10x) increases\n- If needed, run `git diff pkg/monitortests/kubeapiserver/auditloganalyzer/operator_watch_limits.json` to see raw changes\n- Ensure the code still compiles: `go build ./pkg/monitortests/kubeapiserver/auditloganalyzer/...`\n- Review and investigate critical/warning increases before committing\n\n## Return Value\n\n- **Claude agent text**: Detailed report of all updates with warnings and summary of changes\n- **Side effects**:\n  - Modified file: `pkg/monitortests/kubeapiserver/auditloganalyzer/operator_watch_limits.json`\n  - All operator limits updated from BigQuery data\n  - Git changes ready for review and commit\n\n## Example\n\n**Usage:**\n```\n/update-all-operator-watch-request-limits 4.22\n```\n\n**Output:**\n```\nQuerying BigQuery for release 4.22 (last 30 days)...\nProject: openshift-ci-data-analysis\nDataset: ci_data_autodl.operator_watch_requests\n✅ Query completed, retrieved 250 results\n\nReading BigQuery data from stdin...\nLoading: pkg/monitortests/kubeapiserver/auditloganalyzer/operator_watch_limits.json\nWriting: pkg/monitortests/kubeapiserver/auditloganalyzer/operator_watch_limits.json\n\n================================================================================\nOPERATOR WATCH LIMIT CHANGES SUMMARY\n================================================================================\n\n🚨 CRITICAL INCREASES (>10x) - 1 operators:\n  ❌ cluster-monitoring-operator (AWS/HighlyAvailable): 186 → 2100 (11.3x)\n\n⚠️  WARNING INCREASES (2x-10x) - 2 operators:\n  ⚠️  marketplace-operator (GCP/HighlyAvailable): 45 → 95 (2.1x)\n  ⚠️  ingress-operator (Azure/HighlyAvailable): 541 → 890 (1.6x)\n\n📉 MAJOR DECREASES (<50%) - 1 operators:\n  📉 dns-operator (vSphere/HighlyAvailable): 120 → 55 (-54%)\n\n✅ NORMAL INCREASES (<2x) - 115 operators:\n  ✅ cluster-capi-operator (AWS/HighlyAvailable): 205 → 220 (+7%)\n  ✅ authentication-operator (AWS/HighlyAvailable): 519 → 530 (+2%)\n  ✅ etcd-operator (AWS/HighlyAvailable): 245 → 252 (+3%)\n  ✅ console-operator (Azure/HighlyAvailable): 212 → 218 (+3%)\n  ✅ kube-apiserver-operator (GCP/HighlyAvailable): 260 → 275 (+6%)\n  ... and 110 more\n\n📊 NORMAL DECREASES (>50%) - 3 operators:\n  📊 prometheus-operator (OpenStack/HighlyAvailable): 125 → 118 (-6%)\n  📊 service-ca-operator (BareMetal/HighlyAvailable): 135 → 130 (-4%)\n  📊 cluster-samples-operator (Azure/SingleReplica): 40 → 38 (-5%)\n  ... and 0 more\n\n⏭️  SKIPPED - 2 operators not found in JSON:\n  ⏭️  new-test-operator (AWS/HighlyAvailable) - not in JSON\n  ⏭️  experimental-operator (GCP/HighlyAvailable) - not in JSON\n\n================================================================================\nTOTAL: 122 limits changed across 120 operators\n  Critical (>10x): 1\n  Warning (2x-10x): 2\n  Major decreases (<50%): 1\n  Normal increases (<2x): 115\n  Normal decreases (>50%): 3\n  Unchanged: 78\n  Skipped: 2\n================================================================================\n\n⚠️  1 CRITICAL changes detected - review before committing!\n```\n\n## Arguments\n\n- **$1** (required): OpenShift release version\n  - Format: `X.YY` (e.g., `4.22`, `4.23`, `4.21`)\n  - This will be used in the BigQuery query to filter data for that specific release\n  - The query will fetch the last 30 days of data for this release\n\n## BigQuery Query Details\n\nThe command uses the Python script `.claude/scripts/query_operator_watch_requests.py` to fetch data. \n\n## Notes\n\n- **Uses Python scripts**: Two scripts work together:\n  - `query_operator_watch_requests.py` - Queries BigQuery\n  - `update_operator_watch_limits.py` - Updates JSON file and provides comprehensive summary\n- **Requires `bq` CLI**: Google Cloud SDK must be installed and authenticated (`gcloud auth login`)\n- **BigQuery project**: Always queries `openshift-ci-data-analysis` project\n- **Dataset**: Uses `ci_data_autodl.operator_watch_requests` table\n- **Max rows**: Query limited to 1000 results (up from default 100) to handle all operator/platform/topology combinations\n- **Fixed time window**: Always uses 30 days of data (not configurable - ensures reliable averages)\n- **Release specific**: Only queries data for the specified OpenShift release version\n- **Review before commit**: Always review critical and warning increases before committing\n- **Operator names**: The BigQuery Operator field should match service account names (with or without `-operator` suffix)\n- **Platform names**: Must use lowercase names that match the BigQuery schema (aws, gcp, metal, azure, vsphere, openstack)\n- **Uses Average**: Intentionally uses Average instead of P99/Max because test allows 2x headroom\n- **Preserves unknowns**: Operators not in BigQuery results keep their current values\n- **JSON structure**: Updates `operator_watch_limits.json` directly, organized by topology → platform → operator\n- **Formatting**: Maintains JSON indentation and structure\n- **Re-runnable query**: You can re-run just the BigQuery query with `python3 .claude/scripts/query_operator_watch_requests.py 4.22`\n- **Comprehensive summary**: The update script tracks and categorizes all changes as it processes them, providing a detailed summary at the end\n\n## Error Handling\n\n- **Missing release parameter**: Prompts user to provide release version (e.g., `4.22`)\n- **Invalid release format**: Validates release matches pattern like `4.22` or `4.23`\n- **BigQuery query fails**: Shows error message and exits without modifying files\n- **bq CLI not available**: Checks for `bq` command and provides installation instructions\n- **Authentication required**: Prompts to run `gcloud auth login` if not authenticated\n- **Invalid JSON**: Reports parsing errors with line numbers\n- **Missing fields**: Warns about records missing Platform/Topology/Operator/Average\n- **Unknown platform**: Warns and skips operators on platforms not in the maps\n- **Operator not found**: Notes operators in BigQuery data that don't exist in maps (won't add them)\n- **Compilation fails**: Reverts changes and reports Go build errors\n- **No data**: If query returns empty results, exits without changes and suggests checking the release version\n\n## Warnings\n\n- ⚠️  **Critical increases (>10x)** almost always indicate bugs - investigate before committing\n- ⚠️  **Large increases (2x-10x)** need explanation - check recent code changes\n- ⚠️  **Review the diff** - ensure formatting is preserved and changes make sense\n- ⚠️  **Test compilation** - the command validates but always verify manually\n- ⚠️  **Single node data** - upperBoundsSingleNode only has AWS platform, query may return data for other platforms that can't be used\n\n## See Also\n\n- Python scripts:\n  - `.claude/scripts/query_operator_watch_requests.py` - Fetch BigQuery data for a release\n  - `.claude/scripts/update_operator_watch_limits.py` - Update limits in JSON file and provide summary\n- `/update-operator-watch-request-limits` - Update a single operator limit manually\n- Limits file: `pkg/monitortests/kubeapiserver/auditloganalyzer/operator_watch_limits.json`\n- Test implementation: `pkg/monitortests/kubeapiserver/auditloganalyzer/handle_operator_watch_count_tracking.go`\n- BigQuery dataset: `openshift-ci-data-analysis.ci_data_autodl.operator_watch_requests`\n- Grafana dashboard for exploring avg watch requests over time per operator/platform/etc: https://grafana-loki.ci.openshift.org/d/4RcxG4tSz/watch-counts\n",".cursor/mcp.json":"{\n  \"mcpServers\": {\n    \"atlassian\": {\n      \"type\": \"http\",\n      \"url\": \"https://mcp.atlassian.com/v1/mcp\"\n    }\n  }\n}","GEMINI.md":"# GEMINI.md\n<!-- Generated by APM CLI -->\n<!-- Build ID: 01de98569d95 -->\n<!-- APM Version: 0.13.0 -->\n\n@./AGENTS.md\n",".cursor/rules/testing.mdc":"---\ndescription: Testing guidelines and patterns for origin\nglobs: \"**/*_test.go\"\n---\n\n* Use `go vet ./...` and `go test ./pkg/...` to validate changes before committing.\n* E2e tests in `test/extended/<area>/` are **platform-level tests for OpenShift** — they run against a live cluster to validate the product, not just this repo. They use the **Ginkgo** framework and are compiled into the `openshift-tests` binary that CI runs against every payload.\n* `test/extended/include.go` blank-imports every e2e test package — new packages **must** be added there or they won't be compiled into the binary.\n* Unit tests in `pkg/` use standard Go `testing` with **table-driven** patterns.\n* Build the test binary: `make openshift-tests` or `make build`.\n* For unit tests, prefer **table-driven tests** with descriptive case names. Search the same package for existing test patterns before writing new ones.\n",".claude/rules/general.md":"---\npaths:\n  - \"**\"\n---\n\n### APM context generation\n\nSources under **`.apm/`** (instructions, prompts, `apm.yml`, etc.) drive generated agent context. After editing those files, run **`make apm`** to regenerate **AGENTS.md**, **CLAUDE.md**, **GEMINI.md**, and the integrated copies under **`.claude/`**, **`.cursor/`**, **`.gemini/`**, **`.github/instructions/`**, **`.github/prompts/`**, and **`.opencode/`**.\n\n**Slash / agent commands:** content under **`.apm/prompts/*.prompt.md`** is the single source of truth. **`apm install`** (part of **`make apm`**) copies each prompt into editor command targets (e.g. **`.claude/commands/`**, **`.opencode/commands/`**, **`.gemini/commands/`**). Do not add those generated paths by hand or installs will skip them as unmanaged duplicates.\n\n### Retry allowlist policy\n\n**`pkg/test/ginkgo/retry_allowed_tests.yaml`** is strictly shrink-only. Never add tests to it. Remove an entry only when its underlying flake is fixed. If a requested change conflicts with this policy, stop and ask for human direction.\n\n### Repository overview\n\n**openshift/origin** builds the `openshift-tests` binary — the orchestrator for all OpenShift end-to-end testing. It contains:\n* **Built-in e2e tests** (Ginkgo) that run against a live cluster.\n* **Monitor tests** that observe cluster health in the background during e2e runs.\n* **Disruption tests** (a category of monitor test) that measure endpoint availability.\n* **Extension orchestration** that discovers and runs tests contributed by other components via the OTE framework.\n\n### Key directories\n\n* **`cmd/openshift-tests/`** — main binary entry point with subcommands: `run`, `run-test`, `run-monitor`, `run-upgrade`, `disruption`, `list`, `info`, `extension-admission`, and more.\n* **`pkg/testsuites/`** — test suite definitions that compose built-in and extension tests.\n* **`test/extended/`** — Ginkgo-based e2e test packages organized by area (e.g. `networking/`, `storage/`, `etcd/`).\n* **`test/extended/include.go`** — blank imports that register all e2e test packages. New packages **must** be added here.\n* **`test/e2e/upgrade/`** — upgrade-specific e2e tests.\n* **`pkg/monitortestframework/`** — `MonitorTest` interface and registry.\n* **`pkg/defaultmonitortests/`** — registers default monitor tests for stable and disruptive scenarios.\n* **`pkg/monitortests/`** — individual monitor test implementations organized by component (e.g. `etcd/`, `kubeapiserver/`, `network/`, `node/`).\n* **`pkg/monitortestlibrary/`** — shared monitor utilities (allowed disruption baselines, alert allowlists, platform identification).\n* **`pkg/disruption/`** — disruption measurement framework (HTTP/gRPC sampling, transport hooks, shutdown detection).\n* **`pkg/test/extensions/`** — OTE extension binary extraction, execution, and admission control.\n* **`vendor/`** — vendored dependencies. Run `go mod tidy && go mod vendor` after changing `go.mod` to keep `go.sum` and `vendor/` in sync.\n\n### E2e tests\n\nGinkgo-based tests in `test/extended/<area>/` run against a live OpenShift cluster. Each package is registered via blank import in `test/extended/include.go`. These are the \"built-in\" tests that ship inside the `openshift-tests` binary. Tests are grouped into suites (e.g. `openshift/conformance/parallel`) defined in `pkg/testsuites/`.\n\n### Monitor tests\n\nMonitor tests run **in parallel** with the e2e suite to continuously observe cluster health. They follow a lifecycle:\n1. **`StartCollection()`** — begin watching resources, recording events.\n2. *(e2e tests execute)*\n3. **`CollectData()`** — final data collection pass.\n4. **`ConstructComputedIntervals()`** — analyze raw data into structured intervals.\n5. **`EvaluateTestsFromConstructedIntervals()`** — produce JUnit pass/fail results.\n\nMonitor tests are registered in `pkg/defaultmonitortests/types.go` with two stability levels: **Stable** (normal operation — runs all monitors including availability checks) and **Disruptive** (tests that intentionally cause outages like upgrades, node drains, etcd recovery, or cert rotation — availability monitors are excluded since measuring uptime during intentional disruption would produce false failures). Implementations live in `pkg/monitortests/` organized by component — examples include etcd log analysis, cluster operator state tracking, node readiness, API server availability, and alert evaluation.\n\n### Disruption tests\n\nDisruption tests are a category of monitor test that measure **endpoint availability** during test runs. They continuously poll services (API servers, ingress, image registry, pod network) and record availability intervals. Allowed disruption baselines in `pkg/monitortestlibrary/allowedbackenddisruption/` define acceptable unavailability thresholds. Key implementations live in `pkg/monitortests/kubeapiserver/`, `pkg/monitortests/network/`, and `pkg/monitortests/imageregistry/`.\n\n### Extensions (OTE — OpenShift Tests Extension)\n\nThe `openshift-tests` binary acts as an **orchestrator** for tests contributed by other components. The [openshift-tests-extension](https://github.com/openshift-eng/openshift-tests-extension) (OTE) framework defines a standardized interface that external binaries implement:\n* **`<binary> info`** — return extension metadata (component, suites, version).\n* **`<binary> list -o jsonl`** — list available tests, filtered by environment (platform, arch, network).\n* **`<binary> run-test -n <name>`** — execute a specific test and return JSONL results.\n\n**Payload extensions** are test binaries shipped inside release payload images. The registry in `pkg/test/extensions/binary.go` maps ~35 payload image tags to their test binary paths. At runtime, `openshift-tests` extracts these binaries, discovers their tests, and runs them alongside built-in tests.\n\n**Non-payload extensions** are discovered from ImageStreamTags in the cluster and require explicit approval via a `TestExtensionAdmission` CRD. The `extension-admission` subcommand manages these approval rules.\n\nOrigin also registers itself as an extension (`openshift:payload:origin`) so its own built-in Ginkgo tests appear in the unified extension registry alongside external tests.\n\n### Build and verify\n\n* **Build:** `make build` or `make openshift-tests` (produces `./openshift-tests`).\n* **Unit tests:** `go test ./pkg/...` (fast, no cluster required).\n* **Lint / verify:** `make verify` (runs `go vet`, jsonformat, generated-file checks, TLS ownership).\n* **Full check:** `make check` (verify + build + tests).\n\nFavor clarity and maintainability over cleverness. Comments should be minimal, helpful, and explain the \"why\" not the \"what\".\n",".claude/rules/testing.md":"---\npaths:\n  - \"**/*_test.go\"\n---\n\n* Use `go vet ./...` and `go test ./pkg/...` to validate changes before committing.\n* E2e tests in `test/extended/<area>/` are **platform-level tests for OpenShift** — they run against a live cluster to validate the product, not just this repo. They use the **Ginkgo** framework and are compiled into the `openshift-tests` binary that CI runs against every payload.\n* `test/extended/include.go` blank-imports every e2e test package — new packages **must** be added there or they won't be compiled into the binary.\n* Unit tests in `pkg/` use standard Go `testing` with **table-driven** patterns.\n* Build the test binary: `make openshift-tests` or `make build`.\n* For unit tests, prefer **table-driven tests** with descriptive case names. Search the same package for existing test patterns before writing new ones.\n",".cursor/commands/origin-dev-setup.md":"---\ndescription: Set up the Origin devcontainer (Podman, env, GCP auth)\n---\n\n# Origin dev — devcontainer setup\n\nInteractive setup for the Origin devcontainer. Automates what can be detected, prompts for what can't.\n\n## Workflow\n\n### 1. Detect OS\n\n```bash\nuname -s\n```\n\n- **Darwin** = macOS\n- **Linux** = Linux\n\n### 2. Check prerequisites\n\nVerify each tool is installed. Report any that are missing and stop.\n\n```bash\ncommand -v podman\ncommand -v devcontainer\n```\n\nIf `devcontainer` is missing, tell the user: `npm install -g @devcontainers/cli`\n\n### 3. macOS: Podman machine\n\nIf macOS, check if podman machine is running:\n\n```bash\npodman machine info\n```\n\nIf not initialized or not running, run:\n\n```bash\npodman machine init   # only if no machine exists\npodman machine start\n```\n\n### 4. Linux: Podman socket\n\nIf Linux, check if the socket is active:\n\n```bash\nsystemctl --user is-active podman.socket\n```\n\nIf not active, run:\n\n```bash\nsystemctl --user enable --now podman.socket\n```\n\nAlso check for `podman-docker`:\n\n```bash\ncommand -v docker\n```\n\nIf missing, suggest installing `podman-docker` (dnf or apt depending on `/etc/os-release`).\n\n### 5. Environment file\n\nCheck if `.devcontainer/.env` exists:\n\n```bash\ntest -f .devcontainer/.env\n```\n\nIf missing, copy from the example:\n\n```bash\ncp .devcontainer/.env.example .devcontainer/.env\n```\n\nThen read `.devcontainer/.env` and check for empty required values. If any are blank (e.g. `ANTHROPIC_VERTEX_PROJECT_ID`), tell the user which values need to be filled in and ask them to edit `.devcontainer/.env` and let you know when they're done. **Do not** ask for the values directly or write to the file yourself — the user should edit it. Wait for them to confirm before continuing.\n\n### 6. Start the container\n\nDetermine the right command based on OS:\n\n- **macOS**: `devcontainer up --workspace-folder . --docker-path podman`\n- **Linux** (with `podman-docker`): `devcontainer up --workspace-folder .`\n- **Linux** (without `podman-docker`): `devcontainer up --workspace-folder . --docker-path podman`\n\nRun it. This triggers `post-create.sh` (Go tools, Claude Code, `make build`).\n\n### 7. GCP authentication\n\nGCP credentials are mounted from the host's `~/.config/gcloud` directory. If the user hasn't authenticated on the host yet, tell them to run on the host (not inside the container):\n\n```bash\ngcloud auth application-default login\n```\n\nThe credentials will be available inside the container automatically after restart.\n\n### 8. Summary\n\nPrint a summary of what was set up:\n\n- Container status\n- Claude Code: available via Vertex AI\n- GCP auth status\n- To exec in: `podman exec -it -u vscode -w /workspace origin-dev bash`",".opencode/commands/origin-dev-setup.md":"---\ndescription: Set up the Origin devcontainer (Podman, env, GCP auth)\n---\n\n# Origin dev — devcontainer setup\n\nInteractive setup for the Origin devcontainer. Automates what can be detected, prompts for what can't.\n\n## Workflow\n\n### 1. Detect OS\n\n```bash\nuname -s\n```\n\n- **Darwin** = macOS\n- **Linux** = Linux\n\n### 2. Check prerequisites\n\nVerify each tool is installed. Report any that are missing and stop.\n\n```bash\ncommand -v podman\ncommand -v devcontainer\n```\n\nIf `devcontainer` is missing, tell the user: `npm install -g @devcontainers/cli`\n\n### 3. macOS: Podman machine\n\nIf macOS, check if podman machine is running:\n\n```bash\npodman machine info\n```\n\nIf not initialized or not running, run:\n\n```bash\npodman machine init   # only if no machine exists\npodman machine start\n```\n\n### 4. Linux: Podman socket\n\nIf Linux, check if the socket is active:\n\n```bash\nsystemctl --user is-active podman.socket\n```\n\nIf not active, run:\n\n```bash\nsystemctl --user enable --now podman.socket\n```\n\nAlso check for `podman-docker`:\n\n```bash\ncommand -v docker\n```\n\nIf missing, suggest installing `podman-docker` (dnf or apt depending on `/etc/os-release`).\n\n### 5. Environment file\n\nCheck if `.devcontainer/.env` exists:\n\n```bash\ntest -f .devcontainer/.env\n```\n\nIf missing, copy from the example:\n\n```bash\ncp .devcontainer/.env.example .devcontainer/.env\n```\n\nThen read `.devcontainer/.env` and check for empty required values. If any are blank (e.g. `ANTHROPIC_VERTEX_PROJECT_ID`), tell the user which values need to be filled in and ask them to edit `.devcontainer/.env` and let you know when they're done. **Do not** ask for the values directly or write to the file yourself — the user should edit it. Wait for them to confirm before continuing.\n\n### 6. Start the container\n\nDetermine the right command based on OS:\n\n- **macOS**: `devcontainer up --workspace-folder . --docker-path podman`\n- **Linux** (with `podman-docker`): `devcontainer up --workspace-folder .`\n- **Linux** (without `podman-docker`): `devcontainer up --workspace-folder . --docker-path podman`\n\nRun it. This triggers `post-create.sh` (Go tools, Claude Code, `make build`).\n\n### 7. GCP authentication\n\nGCP credentials are mounted from the host's `~/.config/gcloud` directory. If the user hasn't authenticated on the host yet, tell them to run on the host (not inside the container):\n\n```bash\ngcloud auth application-default login\n```\n\nThe credentials will be available inside the container automatically after restart.\n\n### 8. Summary\n\nPrint a summary of what was set up:\n\n- Container status\n- Claude Code: available via Vertex AI\n- GCP auth status\n- To exec in: `podman exec -it -u vscode -w /workspace origin-dev bash`",".cursor/rules/general.mdc":"---\ndescription: Origin repository overview, architecture, and coding guidelines\nglobs: \"**\"\n---\n\n### APM context generation\n\nSources under **`.apm/`** (instructions, prompts, `apm.yml`, etc.) drive generated agent context. After editing those files, run **`make apm`** to regenerate **AGENTS.md**, **CLAUDE.md**, **GEMINI.md**, and the integrated copies under **`.claude/`**, **`.cursor/`**, **`.gemini/`**, **`.github/instructions/`**, **`.github/prompts/`**, and **`.opencode/`**.\n\n**Slash / agent commands:** content under **`.apm/prompts/*.prompt.md`** is the single source of truth. **`apm install`** (part of **`make apm`**) copies each prompt into editor command targets (e.g. **`.claude/commands/`**, **`.opencode/commands/`**, **`.gemini/commands/`**). Do not add those generated paths by hand or installs will skip them as unmanaged duplicates.\n\n### Retry allowlist policy\n\n**`pkg/test/ginkgo/retry_allowed_tests.yaml`** is strictly shrink-only. Never add tests to it. Remove an entry only when its underlying flake is fixed. If a requested change conflicts with this policy, stop and ask for human direction.\n\n### Repository overview\n\n**openshift/origin** builds the `openshift-tests` binary — the orchestrator for all OpenShift end-to-end testing. It contains:\n* **Built-in e2e tests** (Ginkgo) that run against a live cluster.\n* **Monitor tests** that observe cluster health in the background during e2e runs.\n* **Disruption tests** (a category of monitor test) that measure endpoint availability.\n* **Extension orchestration** that discovers and runs tests contributed by other components via the OTE framework.\n\n### Key directories\n\n* **`cmd/openshift-tests/`** — main binary entry point with subcommands: `run`, `run-test`, `run-monitor`, `run-upgrade`, `disruption`, `list`, `info`, `extension-admission`, and more.\n* **`pkg/testsuites/`** — test suite definitions that compose built-in and extension tests.\n* **`test/extended/`** — Ginkgo-based e2e test packages organized by area (e.g. `networking/`, `storage/`, `etcd/`).\n* **`test/extended/include.go`** — blank imports that register all e2e test packages. New packages **must** be added here.\n* **`test/e2e/upgrade/`** — upgrade-specific e2e tests.\n* **`pkg/monitortestframework/`** — `MonitorTest` interface and registry.\n* **`pkg/defaultmonitortests/`** — registers default monitor tests for stable and disruptive scenarios.\n* **`pkg/monitortests/`** — individual monitor test implementations organized by component (e.g. `etcd/`, `kubeapiserver/`, `network/`, `node/`).\n* **`pkg/monitortestlibrary/`** — shared monitor utilities (allowed disruption baselines, alert allowlists, platform identification).\n* **`pkg/disruption/`** — disruption measurement framework (HTTP/gRPC sampling, transport hooks, shutdown detection).\n* **`pkg/test/extensions/`** — OTE extension binary extraction, execution, and admission control.\n* **`vendor/`** — vendored dependencies. Run `go mod tidy && go mod vendor` after changing `go.mod` to keep `go.sum` and `vendor/` in sync.\n\n### E2e tests\n\nGinkgo-based tests in `test/extended/<area>/` run against a live OpenShift cluster. Each package is registered via blank import in `test/extended/include.go`. These are the \"built-in\" tests that ship inside the `openshift-tests` binary. Tests are grouped into suites (e.g. `openshift/conformance/parallel`) defined in `pkg/testsuites/`.\n\n### Monitor tests\n\nMonitor tests run **in parallel** with the e2e suite to continuously observe cluster health. They follow a lifecycle:\n1. **`StartCollection()`** — begin watching resources, recording events.\n2. *(e2e tests execute)*\n3. **`CollectData()`** — final data collection pass.\n4. **`ConstructComputedIntervals()`** — analyze raw data into structured intervals.\n5. **`EvaluateTestsFromConstructedIntervals()`** — produce JUnit pass/fail results.\n\nMonitor tests are registered in `pkg/defaultmonitortests/types.go` with two stability levels: **Stable** (normal operation — runs all monitors including availability checks) and **Disruptive** (tests that intentionally cause outages like upgrades, node drains, etcd recovery, or cert rotation — availability monitors are excluded since measuring uptime during intentional disruption would produce false failures). Implementations live in `pkg/monitortests/` organized by component — examples include etcd log analysis, cluster operator state tracking, node readiness, API server availability, and alert evaluation.\n\n### Disruption tests\n\nDisruption tests are a category of monitor test that measure **endpoint availability** during test runs. They continuously poll services (API servers, ingress, image registry, pod network) and record availability intervals. Allowed disruption baselines in `pkg/monitortestlibrary/allowedbackenddisruption/` define acceptable unavailability thresholds. Key implementations live in `pkg/monitortests/kubeapiserver/`, `pkg/monitortests/network/`, and `pkg/monitortests/imageregistry/`.\n\n### Extensions (OTE — OpenShift Tests Extension)\n\nThe `openshift-tests` binary acts as an **orchestrator** for tests contributed by other components. The [openshift-tests-extension](https://github.com/openshift-eng/openshift-tests-extension) (OTE) framework defines a standardized interface that external binaries implement:\n* **`<binary> info`** — return extension metadata (component, suites, version).\n* **`<binary> list -o jsonl`** — list available tests, filtered by environment (platform, arch, network).\n* **`<binary> run-test -n <name>`** — execute a specific test and return JSONL results.\n\n**Payload extensions** are test binaries shipped inside release payload images. The registry in `pkg/test/extensions/binary.go` maps ~35 payload image tags to their test binary paths. At runtime, `openshift-tests` extracts these binaries, discovers their tests, and runs them alongside built-in tests.\n\n**Non-payload extensions** are discovered from ImageStreamTags in the cluster and require explicit approval via a `TestExtensionAdmission` CRD. The `extension-admission` subcommand manages these approval rules.\n\nOrigin also registers itself as an extension (`openshift:payload:origin`) so its own built-in Ginkgo tests appear in the unified extension registry alongside external tests.\n\n### Build and verify\n\n* **Build:** `make build` or `make openshift-tests` (produces `./openshift-tests`).\n* **Unit tests:** `go test ./pkg/...` (fast, no cluster required).\n* **Lint / verify:** `make verify` (runs `go vet`, jsonformat, generated-file checks, TLS ownership).\n* **Full check:** `make check` (verify + build + tests).\n\nFavor clarity and maintainability over cleverness. Comments should be minimal, helpful, and explain the \"why\" not the \"what\".\n","tools/etcdhelper/README.md":"# etcdhelper Documentation\n\nPath: `tools/etcdhelper/README.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/openshift/origin/HEAD/tools/etcdhelper/README.md)","tools/junitreport/README.md":"# junitreport Documentation\n\nPath: `tools/junitreport/README.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/openshift/origin/HEAD/tools/junitreport/README.md)","vendor/github.com/google/gnostic-models/extensions/README.md":"# extensions Documentation\n\nPath: `vendor/github.com/google/gnostic-models/extensions/README.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/openshift/origin/HEAD/vendor/github.com/google/gnostic-models/extensions/README.md)","vendor/k8s.io/kubernetes/pkg/scheduler/framework/plugins/README.md":"# plugins Documentation\n\nPath: `vendor/k8s.io/kubernetes/pkg/scheduler/framework/plugins/README.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/openshift/origin/HEAD/vendor/k8s.io/kubernetes/pkg/scheduler/framework/plugins/README.md)"},"items":[{"name":"AGENTS.md","path":"AGENTS.md","rawUrl":"https://raw.githubusercontent.com/openshift/origin/HEAD/AGENTS.md","title":"AI Agent Protocol & Instructions","category":"root-instruction","format":"markdown","content":"# AGENTS.md\n<!-- Generated by APM CLI from distributed .apm/ primitives -->\n<!-- Build ID: 3109b13c034b -->\n<!-- APM Version: 0.13.0 -->\n<!-- Source: local -->\n\n## Files matching `**`\n\n<!-- Source: local .apm/instructions/general.instructions.md -->\n### APM context generation\n\nSources under **`.apm/`** (instructions, prompts, `apm.yml`, etc.) drive generated agent context. After editing those files, run **`make apm`** to regenerate **AGENTS.md**, **CLAUDE.md**, **GEMINI.md**, and the integrated copies under **`.claude/`**, **`.cursor/`**, **`.gemini/`**, **`.github/instructions/`**, **`.github/prompts/`**, and **`.opencode/`**.\n\n**Slash / agent commands:** content under **`.apm/prompts/*.prompt.md`** is the single source of truth. **`apm install`** (part of **`make apm`**) copies each prompt into editor command targets (e.g. **`.claude/commands/`**, **`.opencode/commands/`**, **`.gemini/commands/`**). Do not add those generated paths by hand or installs will skip them as unmanaged duplicates.\n\n### Retry allowlist policy\n\n**`pkg/test/ginkgo/retry_allowed_tests.yaml`** is strictly shrink-only. Never add tests to it. Remove an entry only when its underlying flake is fixed. If a requested change conflicts with this policy, stop and ask for human direction.\n\n### Repository overview\n\n**openshift/origin** builds the `openshift-tests` binary — the orchestrator for all OpenShift end-to-end testing. It contains:\n* **Built-in e2e tests** (Ginkgo) that run against a live cluster.\n* **Monitor tests** that observe cluster health in the background during e2e runs.\n* **Disruption tests** (a category of monitor test) that measure endpoint availability.\n* **Extension orchestration** that discovers and runs tests contributed by other components via the OTE framework.\n\n### Key directories\n\n* **`cmd/openshift-tests/`** — main binary entry point with subcommands: `run`, `run-test`, `run-monitor`, `run-upgrade`, `disruption`, `list`, `info`, `extension-admission`, and more.\n* **`pkg/testsuites/`** — test suite definitions that compose built-in and extension tests.\n* **`test/extended/`** — Ginkgo-based e2e test packages organized by area (e.g. `networking/`, `storage/`, `etcd/`).\n* **`test/extended/include.go`** — blank imports that register all e2e test packages. New packages **must** be added here.\n* **`test/e2e/upgrade/`** — upgrade-specific e2e tests.\n* **`pkg/monitortestframework/`** — `MonitorTest` interface and registry.\n* **`pkg/defaultmonitortests/`** — registers default monitor tests for stable and disruptive scenarios.\n* **`pkg/monitortests/`** — individual monitor test implementations organized by component (e.g. `etcd/`, `kubeapiserver/`, `network/`, `node/`).\n* **`pkg/monitortestlibrary/`** — shared monitor utilities (allowed disruption baselines, alert allowlists, platform identification).\n* **`pkg/disruption/`** — disruption measurement framework (HTTP/gRPC sampling, transport hooks, shutdown detection).\n* **`pkg/test/extensions/`** — OTE extension binary extraction, execution, and admission control.\n* **`vendor/`** — vendored dependencies. Run `go mod tidy && go mod vendor` after changing `go.mod` to keep `go.sum` and `vendor/` in sync.\n\n### E2e tests\n\nGinkgo-based tests in `test/extended/<area>/` run against a live OpenShift cluster. Each package is registered via blank import in `test/extended/include.go`. These are the \"built-in\" tests that ship inside the `openshift-tests` binary. Tests are grouped into suites (e.g. `openshift/conformance/parallel`) defined in `pkg/testsuites/`.\n\n### Monitor tests\n\nMonitor tests run **in parallel** with the e2e suite to continuously observe cluster health. They follow a lifecycle:\n1. **`StartCollection()`** — begin watching resources, recording events.\n2. *(e2e tests execute)*\n3. **`CollectData()`** — final data collection pass.\n4. **`ConstructComputedIntervals()`** — analyze raw data into structured intervals.\n5. **`EvaluateTestsFromConstructedIntervals()`** — produce JUnit pass/fail results.\n\nMonitor tests are registered in `pkg/defaultmonitortests/types.go` with two stability levels: **Stable** (normal operation — runs all monitors including availability checks) and **Disruptive** (tests that intentionally cause outages like upgrades, node drains, etcd recovery, or cert rotation — availability monitors are excluded since measuring uptime during intentional disruption would produce false failures). Implementations live in `pkg/monitortests/` organized by component — examples include etcd log analysis, cluster operator state tracking, node readiness, API server availability, and alert evaluation.\n\n### Disruption tests\n\nDisruption tests are a category of monitor test that measure **endpoint availability** during test runs. They continuously poll services (API servers, ingress, image registry, pod network) and record availability intervals. Allowed disruption baselines in `pkg/monitortestlibrary/allowedbackenddisruption/` define acceptable unavailability thresholds. Key implementations live in `pkg/monitortests/kubeapiserver/`, `pkg/monitortests/network/`, and `pkg/monitortests/imageregistry/`.\n\n### Extensions (OTE — OpenShift Tests Extension)\n\nThe `openshift-tests` binary acts as an **orchestrator** for tests contributed by other components. The [openshift-tests-extension](https://github.com/openshift-eng/openshift-tests-extension) (OTE) framework defines a standardized interface that external binaries implement:\n* **`<binary> info`** — return extension metadata (component, suites, version).\n* **`<binary> list -o jsonl`** — list available tests, filtered by environment (platform, arch, network).\n* **`<binary> run-test -n <name>`** — execute a specific test and return JSONL results.\n\n**Payload extensions** are test binaries shipped inside release payload images. The registry in `pkg/test/extensions/binary.go` maps ~35 payload image tags to their test binary paths. At runtime, `openshift-tests` extracts these binaries, discovers their tests, and runs them alongside built-in tests.\n\n**Non-payload extensions** are discovered from ImageStreamTags in the cluster and require explicit approval via a `TestExtensionAdmission` CRD. The `extension-admission` subcommand manages these approval rules.\n\nOrigin also registers itself as an extension (`openshift:payload:origin`) so its own built-in Ginkgo tests appear in the unified extension registry alongside external tests.\n\n### Build and verify\n\n* **Build:** `make build` or `make openshift-tests` (produces `./openshift-tests`).\n* **Unit tests:** `go test ./pkg/...` (fast, no cluster required).\n* **Lint / verify:** `make verify` (runs `go vet`, jsonformat, generated-file checks, TLS ownership).\n* **Full check:** `make check` (verify + build + tests).\n\nFavor clarity and maintainability over cleverness. Comments should be minimal, helpful, and explain the \"why\" not the \"what\".\n\n## Files matching `**/*_test.go`\n\n<!-- Source: local .apm/instructions/testing.instructions.md -->\n* Use `go vet ./...` and `go test ./pkg/...` to validate changes before committing.\n* E2e tests in `test/extended/<area>/` are **platform-level tests for OpenShift** — they run against a live cluster to validate the product, not just this repo. They use the **Ginkgo** framework and are compiled into the `openshift-tests` binary that CI runs against every payload.\n* `test/extended/include.go` blank-imports every e2e test package — new packages **must** be added there or they won't be compiled into the binary.\n* Unit tests in `pkg/` use standard Go `testing` with **table-driven** patterns.\n* Build the test binary: `make openshift-tests` or `make build`.\n* For unit tests, prefer **table-driven tests** with descriptive case names. Search the same package for existing test patterns before writing new ones.\n\n---\n*This file was generated by APM CLI. Do not edit manually.*\n*To regenerate: `apm compile`*\n","isInternal":false,"tokens":1896,"sizeBytes":7931},{"name":"general.md","path":".claude/rules/general.md","rawUrl":"https://raw.githubusercontent.com/openshift/origin/HEAD/.claude/rules/general.md","title":"Rules Skill","category":"anthropic-skill","format":"markdown","content":"---\npaths:\n  - \"**\"\n---\n\n### APM context generation\n\nSources under **`.apm/`** (instructions, prompts, `apm.yml`, etc.) drive generated agent context. After editing those files, run **`make apm`** to regenerate **AGENTS.md**, **CLAUDE.md**, **GEMINI.md**, and the integrated copies under **`.claude/`**, **`.cursor/`**, **`.gemini/`**, **`.github/instructions/`**, **`.github/prompts/`**, and **`.opencode/`**.\n\n**Slash / agent commands:** content under **`.apm/prompts/*.prompt.md`** is the single source of truth. **`apm install`** (part of **`make apm`**) copies each prompt into editor command targets (e.g. **`.claude/commands/`**, **`.opencode/commands/`**, **`.gemini/commands/`**). Do not add those generated paths by hand or installs will skip them as unmanaged duplicates.\n\n### Retry allowlist policy\n\n**`pkg/test/ginkgo/retry_allowed_tests.yaml`** is strictly shrink-only. Never add tests to it. Remove an entry only when its underlying flake is fixed. If a requested change conflicts with this policy, stop and ask for human direction.\n\n### Repository overview\n\n**openshift/origin** builds the `openshift-tests` binary — the orchestrator for all OpenShift end-to-end testing. It contains:\n* **Built-in e2e tests** (Ginkgo) that run against a live cluster.\n* **Monitor tests** that observe cluster health in the background during e2e runs.\n* **Disruption tests** (a category of monitor test) that measure endpoint availability.\n* **Extension orchestration** that discovers and runs tests contributed by other components via the OTE framework.\n\n### Key directories\n\n* **`cmd/openshift-tests/`** — main binary entry point with subcommands: `run`, `run-test`, `run-monitor`, `run-upgrade`, `disruption`, `list`, `info`, `extension-admission`, and more.\n* **`pkg/testsuites/`** — test suite definitions that compose built-in and extension tests.\n* **`test/extended/`** — Ginkgo-based e2e test packages organized by area (e.g. `networking/`, `storage/`, `etcd/`).\n* **`test/extended/include.go`** — blank imports that register all e2e test packages. New packages **must** be added here.\n* **`test/e2e/upgrade/`** — upgrade-specific e2e tests.\n* **`pkg/monitortestframework/`** — `MonitorTest` interface and registry.\n* **`pkg/defaultmonitortests/`** — registers default monitor tests for stable and disruptive scenarios.\n* **`pkg/monitortests/`** — individual monitor test implementations organized by component (e.g. `etcd/`, `kubeapiserver/`, `network/`, `node/`).\n* **`pkg/monitortestlibrary/`** — shared monitor utilities (allowed disruption baselines, alert allowlists, platform identification).\n* **`pkg/disruption/`** — disruption measurement framework (HTTP/gRPC sampling, transport hooks, shutdown detection).\n* **`pkg/test/extensions/`** — OTE extension binary extraction, execution, and admission control.\n* **`vendor/`** — vendored dependencies. Run `go mod tidy && go mod vendor` after changing `go.mod` to keep `go.sum` and `vendor/` in sync.\n\n### E2e tests\n\nGinkgo-based tests in `test/extended/<area>/` run against a live OpenShift cluster. Each package is registered via blank import in `test/extended/include.go`. These are the \"built-in\" tests that ship inside the `openshift-tests` binary. Tests are grouped into suites (e.g. `openshift/conformance/parallel`) defined in `pkg/testsuites/`.\n\n### Monitor tests\n\nMonitor tests run **in parallel** with the e2e suite to continuously observe cluster health. They follow a lifecycle:\n1. **`StartCollection()`** — begin watching resources, recording events.\n2. *(e2e tests execute)*\n3. **`CollectData()`** — final data collection pass.\n4. **`ConstructComputedIntervals()`** — analyze raw data into structured intervals.\n5. **`EvaluateTestsFromConstructedIntervals()`** — produce JUnit pass/fail results.\n\nMonitor tests are registered in `pkg/defaultmonitortests/types.go` with two stability levels: **Stable** (normal operation — runs all monitors including availability checks) and **Disruptive** (tests that intentionally cause outages like upgrades, node drains, etcd recovery, or cert rotation — availability monitors are excluded since measuring uptime during intentional disruption would produce false failures). Implementations live in `pkg/monitortests/` organized by component — examples include etcd log analysis, cluster operator state tracking, node readiness, API server availability, and alert evaluation.\n\n### Disruption tests\n\nDisruption tests are a category of monitor test that measure **endpoint availability** during test runs. They continuously poll services (API servers, ingress, image registry, pod network) and record availability intervals. Allowed disruption baselines in `pkg/monitortestlibrary/allowedbackenddisruption/` define acceptable unavailability thresholds. Key implementations live in `pkg/monitortests/kubeapiserver/`, `pkg/monitortests/network/`, and `pkg/monitortests/imageregistry/`.\n\n### Extensions (OTE — OpenShift Tests Extension)\n\nThe `openshift-tests` binary acts as an **orchestrator** for tests contributed by other components. The [openshift-tests-extension](https://github.com/openshift-eng/openshift-tests-extension) (OTE) framework defines a standardized interface that external binaries implement:\n* **`<binary> info`** — return extension metadata (component, suites, version).\n* **`<binary> list -o jsonl`** — list available tests, filtered by environment (platform, arch, network).\n* **`<binary> run-test -n <name>`** — execute a specific test and return JSONL results.\n\n**Payload extensions** are test binaries shipped inside release payload images. The registry in `pkg/test/extensions/binary.go` maps ~35 payload image tags to their test binary paths. At runtime, `openshift-tests` extracts these binaries, discovers their tests, and runs them alongside built-in tests.\n\n**Non-payload extensions** are discovered from ImageStreamTags in the cluster and require explicit approval via a `TestExtensionAdmission` CRD. The `extension-admission` subcommand manages these approval rules.\n\nOrigin also registers itself as an extension (`openshift:payload:origin`) so its own built-in Ginkgo tests appear in the unified extension registry alongside external tests.\n\n### Build and verify\n\n* **Build:** `make build` or `make openshift-tests` (produces `./openshift-tests`).\n* **Unit tests:** `go test ./pkg/...` (fast, no cluster required).\n* **Lint / verify:** `make verify` (runs `go vet`, jsonformat, generated-file checks, TLS ownership).\n* **Full check:** `make check` (verify + build + tests).\n\nFavor clarity and maintainability over cleverness. Comments should be minimal, helpful, and explain the \"why\" not the \"what\".\n","frontmatter":{"paths":["**"]},"isInternal":false,"tokens":1594,"sizeBytes":6693},{"name":"testing.md","path":".claude/rules/testing.md","rawUrl":"https://raw.githubusercontent.com/openshift/origin/HEAD/.claude/rules/testing.md","title":"Rules Skill","category":"anthropic-skill","format":"markdown","content":"---\npaths:\n  - \"**/*_test.go\"\n---\n\n* Use `go vet ./...` and `go test ./pkg/...` to validate changes before committing.\n* E2e tests in `test/extended/<area>/` are **platform-level tests for OpenShift** — they run against a live cluster to validate the product, not just this repo. They use the **Ginkgo** framework and are compiled into the `openshift-tests` binary that CI runs against every payload.\n* `test/extended/include.go` blank-imports every e2e test package — new packages **must** be added there or they won't be compiled into the binary.\n* Unit tests in `pkg/` use standard Go `testing` with **table-driven** patterns.\n* Build the test binary: `make openshift-tests` or `make build`.\n* For unit tests, prefer **table-driven tests** with descriptive case names. Search the same package for existing test patterns before writing new ones.\n","frontmatter":{"paths":["**/*_test.go"]},"isInternal":false,"tokens":205,"sizeBytes":852},{"name":"general.mdc","path":".cursor/rules/general.mdc","rawUrl":"https://raw.githubusercontent.com/openshift/origin/HEAD/.cursor/rules/general.mdc","title":"Cursor Rule: general","category":"cursor-rule","format":"mdc","content":"---\ndescription: Origin repository overview, architecture, and coding guidelines\nglobs: \"**\"\n---\n\n### APM context generation\n\nSources under **`.apm/`** (instructions, prompts, `apm.yml`, etc.) drive generated agent context. After editing those files, run **`make apm`** to regenerate **AGENTS.md**, **CLAUDE.md**, **GEMINI.md**, and the integrated copies under **`.claude/`**, **`.cursor/`**, **`.gemini/`**, **`.github/instructions/`**, **`.github/prompts/`**, and **`.opencode/`**.\n\n**Slash / agent commands:** content under **`.apm/prompts/*.prompt.md`** is the single source of truth. **`apm install`** (part of **`make apm`**) copies each prompt into editor command targets (e.g. **`.claude/commands/`**, **`.opencode/commands/`**, **`.gemini/commands/`**). Do not add those generated paths by hand or installs will skip them as unmanaged duplicates.\n\n### Retry allowlist policy\n\n**`pkg/test/ginkgo/retry_allowed_tests.yaml`** is strictly shrink-only. Never add tests to it. Remove an entry only when its underlying flake is fixed. If a requested change conflicts with this policy, stop and ask for human direction.\n\n### Repository overview\n\n**openshift/origin** builds the `openshift-tests` binary — the orchestrator for all OpenShift end-to-end testing. It contains:\n* **Built-in e2e tests** (Ginkgo) that run against a live cluster.\n* **Monitor tests** that observe cluster health in the background during e2e runs.\n* **Disruption tests** (a category of monitor test) that measure endpoint availability.\n* **Extension orchestration** that discovers and runs tests contributed by other components via the OTE framework.\n\n### Key directories\n\n* **`cmd/openshift-tests/`** — main binary entry point with subcommands: `run`, `run-test`, `run-monitor`, `run-upgrade`, `disruption`, `list`, `info`, `extension-admission`, and more.\n* **`pkg/testsuites/`** — test suite definitions that compose built-in and extension tests.\n* **`test/extended/`** — Ginkgo-based e2e test packages organized by area (e.g. `networking/`, `storage/`, `etcd/`).\n* **`test/extended/include.go`** — blank imports that register all e2e test packages. New packages **must** be added here.\n* **`test/e2e/upgrade/`** — upgrade-specific e2e tests.\n* **`pkg/monitortestframework/`** — `MonitorTest` interface and registry.\n* **`pkg/defaultmonitortests/`** — registers default monitor tests for stable and disruptive scenarios.\n* **`pkg/monitortests/`** — individual monitor test implementations organized by component (e.g. `etcd/`, `kubeapiserver/`, `network/`, `node/`).\n* **`pkg/monitortestlibrary/`** — shared monitor utilities (allowed disruption baselines, alert allowlists, platform identification).\n* **`pkg/disruption/`** — disruption measurement framework (HTTP/gRPC sampling, transport hooks, shutdown detection).\n* **`pkg/test/extensions/`** — OTE extension binary extraction, execution, and admission control.\n* **`vendor/`** — vendored dependencies. Run `go mod tidy && go mod vendor` after changing `go.mod` to keep `go.sum` and `vendor/` in sync.\n\n### E2e tests\n\nGinkgo-based tests in `test/extended/<area>/` run against a live OpenShift cluster. Each package is registered via blank import in `test/extended/include.go`. These are the \"built-in\" tests that ship inside the `openshift-tests` binary. Tests are grouped into suites (e.g. `openshift/conformance/parallel`) defined in `pkg/testsuites/`.\n\n### Monitor tests\n\nMonitor tests run **in parallel** with the e2e suite to continuously observe cluster health. They follow a lifecycle:\n1. **`StartCollection()`** — begin watching resources, recording events.\n2. *(e2e tests execute)*\n3. **`CollectData()`** — final data collection pass.\n4. **`ConstructComputedIntervals()`** — analyze raw data into structured intervals.\n5. **`EvaluateTestsFromConstructedIntervals()`** — produce JUnit pass/fail results.\n\nMonitor tests are registered in `pkg/defaultmonitortests/types.go` with two stability levels: **Stable** (normal operation — runs all monitors including availability checks) and **Disruptive** (tests that intentionally cause outages like upgrades, node drains, etcd recovery, or cert rotation — availability monitors are excluded since measuring uptime during intentional disruption would produce false failures). Implementations live in `pkg/monitortests/` organized by component — examples include etcd log analysis, cluster operator state tracking, node readiness, API server availability, and alert evaluation.\n\n### Disruption tests\n\nDisruption tests are a category of monitor test that measure **endpoint availability** during test runs. They continuously poll services (API servers, ingress, image registry, pod network) and record availability intervals. Allowed disruption baselines in `pkg/monitortestlibrary/allowedbackenddisruption/` define acceptable unavailability thresholds. Key implementations live in `pkg/monitortests/kubeapiserver/`, `pkg/monitortests/network/`, and `pkg/monitortests/imageregistry/`.\n\n### Extensions (OTE — OpenShift Tests Extension)\n\nThe `openshift-tests` binary acts as an **orchestrator** for tests contributed by other components. The [openshift-tests-extension](https://github.com/openshift-eng/openshift-tests-extension) (OTE) framework defines a standardized interface that external binaries implement:\n* **`<binary> info`** — return extension metadata (component, suites, version).\n* **`<binary> list -o jsonl`** — list available tests, filtered by environment (platform, arch, network).\n* **`<binary> run-test -n <name>`** — execute a specific test and return JSONL results.\n\n**Payload extensions** are test binaries shipped inside release payload images. The registry in `pkg/test/extensions/binary.go` maps ~35 payload image tags to their test binary paths. At runtime, `openshift-tests` extracts these binaries, discovers their tests, and runs them alongside built-in tests.\n\n**Non-payload extensions** are discovered from ImageStreamTags in the cluster and require explicit approval via a `TestExtensionAdmission` CRD. The `extension-admission` subcommand manages these approval rules.\n\nOrigin also registers itself as an extension (`openshift:payload:origin`) so its own built-in Ginkgo tests appear in the unified extension registry alongside external tests.\n\n### Build and verify\n\n* **Build:** `make build` or `make openshift-tests` (produces `./openshift-tests`).\n* **Unit tests:** `go test ./pkg/...` (fast, no cluster required).\n* **Lint / verify:** `make verify` (runs `go vet`, jsonformat, generated-file checks, TLS ownership).\n* **Full check:** `make check` (verify + build + tests).\n\nFavor clarity and maintainability over cleverness. Comments should be minimal, helpful, and explain the \"why\" not the \"what\".\n","frontmatter":{"description":"Origin repository overview, architecture, and coding guidelines","globs":"**"},"isInternal":false,"tokens":1605,"sizeBytes":6766},{"name":"testing.mdc","path":".cursor/rules/testing.mdc","rawUrl":"https://raw.githubusercontent.com/openshift/origin/HEAD/.cursor/rules/testing.mdc","title":"Cursor Rule: testing","category":"cursor-rule","format":"mdc","content":"---\ndescription: Testing guidelines and patterns for origin\nglobs: \"**/*_test.go\"\n---\n\n* Use `go vet ./...` and `go test ./pkg/...` to validate changes before committing.\n* E2e tests in `test/extended/<area>/` are **platform-level tests for OpenShift** — they run against a live cluster to validate the product, not just this repo. They use the **Ginkgo** framework and are compiled into the `openshift-tests` binary that CI runs against every payload.\n* `test/extended/include.go` blank-imports every e2e test package — new packages **must** be added there or they won't be compiled into the binary.\n* Unit tests in `pkg/` use standard Go `testing` with **table-driven** patterns.\n* Build the test binary: `make openshift-tests` or `make build`.\n* For unit tests, prefer **table-driven tests** with descriptive case names. Search the same package for existing test patterns before writing new ones.\n","frontmatter":{"description":"Testing guidelines and patterns for origin","globs":"**/*_test.go"},"isInternal":false,"tokens":213,"sizeBytes":904},{"name":"CLAUDE.md","path":"CLAUDE.md","rawUrl":"https://raw.githubusercontent.com/openshift/origin/HEAD/CLAUDE.md","title":"Claude Agent Guidelines & System Prompt","category":"claude-rule","format":"markdown","content":"# CLAUDE.md\n<!-- Generated by APM CLI -->\n<!-- Build ID: b79f3567f84e -->\n<!-- APM Version: 0.13.0 -->\n\n# Project Standards\n\n## Files matching `**`\n\n<!-- Source: local .apm/instructions/general.instructions.md -->\n### APM context generation\n\nSources under **`.apm/`** (instructions, prompts, `apm.yml`, etc.) drive generated agent context. After editing those files, run **`make apm`** to regenerate **AGENTS.md**, **CLAUDE.md**, **GEMINI.md**, and the integrated copies under **`.claude/`**, **`.cursor/`**, **`.gemini/`**, **`.github/instructions/`**, **`.github/prompts/`**, and **`.opencode/`**.\n\n**Slash / agent commands:** content under **`.apm/prompts/*.prompt.md`** is the single source of truth. **`apm install`** (part of **`make apm`**) copies each prompt into editor command targets (e.g. **`.claude/commands/`**, **`.opencode/commands/`**, **`.gemini/commands/`**). Do not add those generated paths by hand or installs will skip them as unmanaged duplicates.\n\n### Retry allowlist policy\n\n**`pkg/test/ginkgo/retry_allowed_tests.yaml`** is strictly shrink-only. Never add tests to it. Remove an entry only when its underlying flake is fixed. If a requested change conflicts with this policy, stop and ask for human direction.\n\n### Repository overview\n\n**openshift/origin** builds the `openshift-tests` binary — the orchestrator for all OpenShift end-to-end testing. It contains:\n* **Built-in e2e tests** (Ginkgo) that run against a live cluster.\n* **Monitor tests** that observe cluster health in the background during e2e runs.\n* **Disruption tests** (a category of monitor test) that measure endpoint availability.\n* **Extension orchestration** that discovers and runs tests contributed by other components via the OTE framework.\n\n### Key directories\n\n* **`cmd/openshift-tests/`** — main binary entry point with subcommands: `run`, `run-test`, `run-monitor`, `run-upgrade`, `disruption`, `list`, `info`, `extension-admission`, and more.\n* **`pkg/testsuites/`** — test suite definitions that compose built-in and extension tests.\n* **`test/extended/`** — Ginkgo-based e2e test packages organized by area (e.g. `networking/`, `storage/`, `etcd/`).\n* **`test/extended/include.go`** — blank imports that register all e2e test packages. New packages **must** be added here.\n* **`test/e2e/upgrade/`** — upgrade-specific e2e tests.\n* **`pkg/monitortestframework/`** — `MonitorTest` interface and registry.\n* **`pkg/defaultmonitortests/`** — registers default monitor tests for stable and disruptive scenarios.\n* **`pkg/monitortests/`** — individual monitor test implementations organized by component (e.g. `etcd/`, `kubeapiserver/`, `network/`, `node/`).\n* **`pkg/monitortestlibrary/`** — shared monitor utilities (allowed disruption baselines, alert allowlists, platform identification).\n* **`pkg/disruption/`** — disruption measurement framework (HTTP/gRPC sampling, transport hooks, shutdown detection).\n* **`pkg/test/extensions/`** — OTE extension binary extraction, execution, and admission control.\n* **`vendor/`** — vendored dependencies. Run `go mod tidy && go mod vendor` after changing `go.mod` to keep `go.sum` and `vendor/` in sync.\n\n### E2e tests\n\nGinkgo-based tests in `test/extended/<area>/` run against a live OpenShift cluster. Each package is registered via blank import in `test/extended/include.go`. These are the \"built-in\" tests that ship inside the `openshift-tests` binary. Tests are grouped into suites (e.g. `openshift/conformance/parallel`) defined in `pkg/testsuites/`.\n\n### Monitor tests\n\nMonitor tests run **in parallel** with the e2e suite to continuously observe cluster health. They follow a lifecycle:\n1. **`StartCollection()`** — begin watching resources, recording events.\n2. *(e2e tests execute)*\n3. **`CollectData()`** — final data collection pass.\n4. **`ConstructComputedIntervals()`** — analyze raw data into structured intervals.\n5. **`EvaluateTestsFromConstructedIntervals()`** — produce JUnit pass/fail results.\n\nMonitor tests are registered in `pkg/defaultmonitortests/types.go` with two stability levels: **Stable** (normal operation — runs all monitors including availability checks) and **Disruptive** (tests that intentionally cause outages like upgrades, node drains, etcd recovery, or cert rotation — availability monitors are excluded since measuring uptime during intentional disruption would produce false failures). Implementations live in `pkg/monitortests/` organized by component — examples include etcd log analysis, cluster operator state tracking, node readiness, API server availability, and alert evaluation.\n\n### Disruption tests\n\nDisruption tests are a category of monitor test that measure **endpoint availability** during test runs. They continuously poll services (API servers, ingress, image registry, pod network) and record availability intervals. Allowed disruption baselines in `pkg/monitortestlibrary/allowedbackenddisruption/` define acceptable unavailability thresholds. Key implementations live in `pkg/monitortests/kubeapiserver/`, `pkg/monitortests/network/`, and `pkg/monitortests/imageregistry/`.\n\n### Extensions (OTE — OpenShift Tests Extension)\n\nThe `openshift-tests` binary acts as an **orchestrator** for tests contributed by other components. The [openshift-tests-extension](https://github.com/openshift-eng/openshift-tests-extension) (OTE) framework defines a standardized interface that external binaries implement:\n* **`<binary> info`** — return extension metadata (component, suites, version).\n* **`<binary> list -o jsonl`** — list available tests, filtered by environment (platform, arch, network).\n* **`<binary> run-test -n <name>`** — execute a specific test and return JSONL results.\n\n**Payload extensions** are test binaries shipped inside release payload images. The registry in `pkg/test/extensions/binary.go` maps ~35 payload image tags to their test binary paths. At runtime, `openshift-tests` extracts these binaries, discovers their tests, and runs them alongside built-in tests.\n\n**Non-payload extensions** are discovered from ImageStreamTags in the cluster and require explicit approval via a `TestExtensionAdmission` CRD. The `extension-admission` subcommand manages these approval rules.\n\nOrigin also registers itself as an extension (`openshift:payload:origin`) so its own built-in Ginkgo tests appear in the unified extension registry alongside external tests.\n\n### Build and verify\n\n* **Build:** `make build` or `make openshift-tests` (produces `./openshift-tests`).\n* **Unit tests:** `go test ./pkg/...` (fast, no cluster required).\n* **Lint / verify:** `make verify` (runs `go vet`, jsonformat, generated-file checks, TLS ownership).\n* **Full check:** `make check` (verify + build + tests).\n\nFavor clarity and maintainability over cleverness. Comments should be minimal, helpful, and explain the \"why\" not the \"what\".\n\n## Files matching `**/*_test.go`\n\n<!-- Source: local .apm/instructions/testing.instructions.md -->\n* Use `go vet ./...` and `go test ./pkg/...` to validate changes before committing.\n* E2e tests in `test/extended/<area>/` are **platform-level tests for OpenShift** — they run against a live cluster to validate the product, not just this repo. They use the **Ginkgo** framework and are compiled into the `openshift-tests` binary that CI runs against every payload.\n* `test/extended/include.go` blank-imports every e2e test package — new packages **must** be added there or they won't be compiled into the binary.\n* Unit tests in `pkg/` use standard Go `testing` with **table-driven** patterns.\n* Build the test binary: `make openshift-tests` or `make build`.\n* For unit tests, prefer **table-driven tests** with descriptive case names. Search the same package for existing test patterns before writing new ones.\n\n---\n*This file was generated by APM CLI. Do not edit manually.*\n*To regenerate: `apm compile`*\n","isInternal":false,"tokens":1889,"sizeBytes":7895},{"name":"GEMINI.md","path":"GEMINI.md","rawUrl":"https://raw.githubusercontent.com/openshift/origin/HEAD/GEMINI.md","title":"Gemini Agent & Antigravity Instructions","category":"gemini-rule","format":"markdown","content":"# GEMINI.md\n<!-- Generated by APM CLI -->\n<!-- Build ID: 01de98569d95 -->\n<!-- APM Version: 0.13.0 -->\n\n@./AGENTS.md\n","isInternal":false,"tokens":43,"sizeBytes":117},{"name":"README.md","path":"tools/etcdhelper/README.md","rawUrl":"https://raw.githubusercontent.com/openshift/origin/HEAD/tools/etcdhelper/README.md","title":"etcdhelper Documentation","category":"plugin-manifest","format":"markdown","content":"# etcdhelper Documentation\n\nPath: `tools/etcdhelper/README.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/openshift/origin/HEAD/tools/etcdhelper/README.md)","tokens":300,"sizeBytes":176},{"name":"README.md","path":"tools/junitreport/README.md","rawUrl":"https://raw.githubusercontent.com/openshift/origin/HEAD/tools/junitreport/README.md","title":"junitreport Documentation","category":"plugin-manifest","format":"markdown","content":"# junitreport Documentation\n\nPath: `tools/junitreport/README.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/openshift/origin/HEAD/tools/junitreport/README.md)","tokens":300,"sizeBytes":179},{"name":"README.md","path":"vendor/github.com/google/gnostic-models/extensions/README.md","rawUrl":"https://raw.githubusercontent.com/openshift/origin/HEAD/vendor/github.com/google/gnostic-models/extensions/README.md","title":"extensions Documentation","category":"plugin-manifest","format":"markdown","content":"# extensions Documentation\n\nPath: `vendor/github.com/google/gnostic-models/extensions/README.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/openshift/origin/HEAD/vendor/github.com/google/gnostic-models/extensions/README.md)","tokens":300,"sizeBytes":244},{"name":"README.md","path":"vendor/k8s.io/kubernetes/pkg/scheduler/framework/plugins/README.md","rawUrl":"https://raw.githubusercontent.com/openshift/origin/HEAD/vendor/k8s.io/kubernetes/pkg/scheduler/framework/plugins/README.md","title":"plugins Documentation","category":"plugin-manifest","format":"markdown","content":"# plugins Documentation\n\nPath: `vendor/k8s.io/kubernetes/pkg/scheduler/framework/plugins/README.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/openshift/origin/HEAD/vendor/k8s.io/kubernetes/pkg/scheduler/framework/plugins/README.md)","tokens":300,"sizeBytes":253},{"name":"mcp.json","path":".cursor/mcp.json","rawUrl":"https://raw.githubusercontent.com/openshift/origin/HEAD/.cursor/mcp.json","title":"Model Context Protocol (MCP) Configuration","category":"mcp-config","format":"json","content":"{\n  \"mcpServers\": {\n    \"atlassian\": {\n      \"type\": \"http\",\n      \"url\": \"https://mcp.atlassian.com/v1/mcp\"\n    }\n  }\n}","frontmatter":{"mcpServers":{"atlassian":{"type":"http","url":"https://mcp.atlassian.com/v1/mcp"}}},"isInternal":false,"tokens":43,"sizeBytes":120},{"name":"origin-dev-setup.md","path":".claude/commands/origin-dev-setup.md","rawUrl":"https://raw.githubusercontent.com/openshift/origin/HEAD/.claude/commands/origin-dev-setup.md","title":"Command: /origin-dev-setup","category":"command-prompt","format":"markdown","content":"---\ndescription: Set up the Origin devcontainer (Podman, env, GCP auth)\n---\n\n# Origin dev — devcontainer setup\n\nInteractive setup for the Origin devcontainer. Automates what can be detected, prompts for what can't.\n\n## Workflow\n\n### 1. Detect OS\n\n```bash\nuname -s\n```\n\n- **Darwin** = macOS\n- **Linux** = Linux\n\n### 2. Check prerequisites\n\nVerify each tool is installed. Report any that are missing and stop.\n\n```bash\ncommand -v podman\ncommand -v devcontainer\n```\n\nIf `devcontainer` is missing, tell the user: `npm install -g @devcontainers/cli`\n\n### 3. macOS: Podman machine\n\nIf macOS, check if podman machine is running:\n\n```bash\npodman machine info\n```\n\nIf not initialized or not running, run:\n\n```bash\npodman machine init   # only if no machine exists\npodman machine start\n```\n\n### 4. Linux: Podman socket\n\nIf Linux, check if the socket is active:\n\n```bash\nsystemctl --user is-active podman.socket\n```\n\nIf not active, run:\n\n```bash\nsystemctl --user enable --now podman.socket\n```\n\nAlso check for `podman-docker`:\n\n```bash\ncommand -v docker\n```\n\nIf missing, suggest installing `podman-docker` (dnf or apt depending on `/etc/os-release`).\n\n### 5. Environment file\n\nCheck if `.devcontainer/.env` exists:\n\n```bash\ntest -f .devcontainer/.env\n```\n\nIf missing, copy from the example:\n\n```bash\ncp .devcontainer/.env.example .devcontainer/.env\n```\n\nThen read `.devcontainer/.env` and check for empty required values. If any are blank (e.g. `ANTHROPIC_VERTEX_PROJECT_ID`), tell the user which values need to be filled in and ask them to edit `.devcontainer/.env` and let you know when they're done. **Do not** ask for the values directly or write to the file yourself — the user should edit it. Wait for them to confirm before continuing.\n\n### 6. Start the container\n\nDetermine the right command based on OS:\n\n- **macOS**: `devcontainer up --workspace-folder . --docker-path podman`\n- **Linux** (with `podman-docker`): `devcontainer up --workspace-folder .`\n- **Linux** (without `podman-docker`): `devcontainer up --workspace-folder . --docker-path podman`\n\nRun it. This triggers `post-create.sh` (Go tools, Claude Code, `make build`).\n\n### 7. GCP authentication\n\nGCP credentials are mounted from the host's `~/.config/gcloud` directory. If the user hasn't authenticated on the host yet, tell them to run on the host (not inside the container):\n\n```bash\ngcloud auth application-default login\n```\n\nThe credentials will be available inside the container automatically after restart.\n\n### 8. Summary\n\nPrint a summary of what was set up:\n\n- Container status\n- Claude Code: available via Vertex AI\n- GCP auth status\n- To exec in: `podman exec -it -u vscode -w /workspace origin-dev bash`","frontmatter":{"description":"Set up the Origin devcontainer (Podman, env, GCP auth)"},"isInternal":false,"tokens":693,"sizeBytes":2679},{"name":"update-all-operator-watch-request-limits.md","path":".claude/commands/update-all-operator-watch-request-limits.md","rawUrl":"https://raw.githubusercontent.com/openshift/origin/HEAD/.claude/commands/update-all-operator-watch-request-limits.md","title":"Command: /update-all-operator-watch-request-limits","category":"command-prompt","format":"markdown","content":"---\ndescription: Bulk update all operator watch request limits from BigQuery data\nargument-hint: <release>\n---\n\n## Name\n\nupdate-all-operator-watch-request-limits\n\n## Synopsis\n\n```\n/update-all-operator-watch-request-limits <release>\n```\n\n## Description\n\nThe `update-all-operator-watch-request-limits` command performs a bulk update of ALL operator watch request limits in the test by querying live data from BigQuery. This is used to refresh all limits at once based on recent CI data (last 30 days), rather than updating operators one at a time.\n\n**What this command does:**\n1. Runs `.claude/scripts/query_operator_watch_requests.py` to fetch BigQuery data for the specified release\n2. Pipes the JSON results to `.claude/scripts/update_operator_watch_limits.py` to update the JSON file\n3. Updates ALL existing limits in the JSON file for both topologies (HighlyAvailable and SingleReplica)\n4. Shows a categorized summary of all changes as they're applied:\n   - Critical increases (>10x) - likely bugs\n   - Warning increases (2x-10x) - need investigation\n   - Major decreases (<50%) - significant reductions\n   - Normal increases/decreases - expected changes\n\n**Important notes:**\n- Uses the P99 over the past 30 days. Note the test allows 2x this limit before it will complain allowing for natural growth.\n- Only updates operators that already exist in the JSON (doesn't add new ones automatically)\n- Updates `operator_watch_limits.json` directly \n- Preserves JSON formatting and structure\n- Highlights concerning increases for manual review before committing\n\n## Implementation\n\n### 1. Fetch BigQuery Data and Update Limits\n\nExecutes the query script and pipes output to the update script:\n\n```bash\n# Query BigQuery and pipe directly to update script\npython3 .claude/scripts/query_operator_watch_requests.py \"$RELEASE\" | \\\n  python3 .claude/scripts/update_operator_watch_limits.py\n```\n\nThe query script:\n- Invokes `bq query` via command line with `--max_rows=1000` to handle all results (up from default 100)\n- Queries the `openshift-ci-data-analysis.ci_data_autodl.operator_watch_requests` table\n- Uses the last 30 days of data for the specified release\n- Outputs JSON to stdout (piped to update script)\n\nThe update script:\n- Reads JSON from stdin\n- Updates operator_watch_limits.json with new values\n- Tracks all changes as it processes them\n- Categorizes changes by severity (critical, warning, decreases, normal)\n- Outputs a comprehensive summary at the end\n\n**Expected JSON results:**\n```json\n[{\n  \"Platform\": \"aws\",\n  \"Release\": \"4.22\",\n  \"Topology\": \"ha\",\n  \"Operator\": \"cluster-capi-operator\",\n  \"Average\": \"117.0\",\n  \"Max_WatchCount\": \"216\",\n  \"P99_WatchCount\": \"199\"\n}, ...]\n```\n\n### 2. Summarize Changes\n\nAfter updating the JSON file, summarize the changes using git diff:\n\n```bash\n# Show summary of what changed\npython3 .claude/scripts/summarize_operator_watch_changes.py\n```\n\nThe summarize script:\n- Parses `git diff` of operator_watch_limits.json\n- Categorizes changes: critical (>10x), warning (2x-10x), decreases (<50%), normal (<2x)\n- Provides a human-readable summary of all changes\n\nThe update script accepts JSON from stdin and:\n- Updates operator_watch_limits.json directly\n- Preserves JSON structure and formatting\n\n### 3. Parse and Map Data\n\n**Platform name mapping:**\n- `aws` → `AWS` (in JSON)\n- `azure` → `Azure` (in JSON)\n- `gcp` → `GCP` (in JSON)\n- `metal` → `BareMetal` (in JSON)\n- `vsphere` → `vSphere` (in JSON)\n- `openstack` → `OpenStack` (in JSON)\n\n**Topology mapping:**\n- `ha` → `HighlyAvailable` (in JSON)\n- `single` → `SingleReplica` (in JSON)\n\n**Operator name mapping:**\nThe BigQuery data may have operator names without `-operator` suffix. The command will:\n- Ensure the operator name ends with `-operator`\n- Match it against existing keys in the maps\n- Examples:\n  - `cluster-capi-operator` → `cluster-capi-operator` (already correct)\n  - `capi-operator` → Skip (not a known service account pattern, may be data issue)\n  - `cluster-monitoring` → `cluster-monitoring-operator`\n\n### 4. Update Limits in JSON\n\nFor each operator in the BigQuery results:\n\n1. Find the corresponding entry in the JSON file under the appropriate topology and platform\n2. Extract the P99 value and round to nearest integer\n3. Compare with old value and categorize the change\n4. Update the JSON entry with the new value\n5. Track the change for the summary report\n\nThe update script categorizes all changes as it processes them:\n- **Critical increases (>10x)** - likely bugs, need investigation\n- **Warning increases (2x-10x)** - need explanation\n- **Major decreases (<50%)** - significant reductions in watch usage\n- **Normal increases (<2x)** - expected growth\n- **Normal decreases (>50%)** - minor reductions\n- **Unchanged** - P99 matches current limit\n- **Skipped** - operators in BigQuery but not in JSON\n\nAfter processing all changes:\n- Outputs a comprehensive summary showing all categorized changes\n\n### 5. Validation\n\nAfter updating, validate the changes:\n- Review the comprehensive summary output for concerning changes\n- Pay special attention to critical (>10x) and warning (2x-10x) increases\n- If needed, run `git diff pkg/monitortests/kubeapiserver/auditloganalyzer/operator_watch_limits.json` to see raw changes\n- Ensure the code still compiles: `go build ./pkg/monitortests/kubeapiserver/auditloganalyzer/...`\n- Review and investigate critical/warning increases before committing\n\n## Return Value\n\n- **Claude agent text**: Detailed report of all updates with warnings and summary of changes\n- **Side effects**:\n  - Modified file: `pkg/monitortests/kubeapiserver/auditloganalyzer/operator_watch_limits.json`\n  - All operator limits updated from BigQuery data\n  - Git changes ready for review and commit\n\n## Example\n\n**Usage:**\n```\n/update-all-operator-watch-request-limits 4.22\n```\n\n**Output:**\n```\nQuerying BigQuery for release 4.22 (last 30 days)...\nProject: openshift-ci-data-analysis\nDataset: ci_data_autodl.operator_watch_requests\n✅ Query completed, retrieved 250 results\n\nReading BigQuery data from stdin...\nLoading: pkg/monitortests/kubeapiserver/auditloganalyzer/operator_watch_limits.json\nWriting: pkg/monitortests/kubeapiserver/auditloganalyzer/operator_watch_limits.json\n\n================================================================================\nOPERATOR WATCH LIMIT CHANGES SUMMARY\n================================================================================\n\n🚨 CRITICAL INCREASES (>10x) - 1 operators:\n  ❌ cluster-monitoring-operator (AWS/HighlyAvailable): 186 → 2100 (11.3x)\n\n⚠️  WARNING INCREASES (2x-10x) - 2 operators:\n  ⚠️  marketplace-operator (GCP/HighlyAvailable): 45 → 95 (2.1x)\n  ⚠️  ingress-operator (Azure/HighlyAvailable): 541 → 890 (1.6x)\n\n📉 MAJOR DECREASES (<50%) - 1 operators:\n  📉 dns-operator (vSphere/HighlyAvailable): 120 → 55 (-54%)\n\n✅ NORMAL INCREASES (<2x) - 115 operators:\n  ✅ cluster-capi-operator (AWS/HighlyAvailable): 205 → 220 (+7%)\n  ✅ authentication-operator (AWS/HighlyAvailable): 519 → 530 (+2%)\n  ✅ etcd-operator (AWS/HighlyAvailable): 245 → 252 (+3%)\n  ✅ console-operator (Azure/HighlyAvailable): 212 → 218 (+3%)\n  ✅ kube-apiserver-operator (GCP/HighlyAvailable): 260 → 275 (+6%)\n  ... and 110 more\n\n📊 NORMAL DECREASES (>50%) - 3 operators:\n  📊 prometheus-operator (OpenStack/HighlyAvailable): 125 → 118 (-6%)\n  📊 service-ca-operator (BareMetal/HighlyAvailable): 135 → 130 (-4%)\n  📊 cluster-samples-operator (Azure/SingleReplica): 40 → 38 (-5%)\n  ... and 0 more\n\n⏭️  SKIPPED - 2 operators not found in JSON:\n  ⏭️  new-test-operator (AWS/HighlyAvailable) - not in JSON\n  ⏭️  experimental-operator (GCP/HighlyAvailable) - not in JSON\n\n================================================================================\nTOTAL: 122 limits changed across 120 operators\n  Critical (>10x): 1\n  Warning (2x-10x): 2\n  Major decreases (<50%): 1\n  Normal increases (<2x): 115\n  Normal decreases (>50%): 3\n  Unchanged: 78\n  Skipped: 2\n================================================================================\n\n⚠️  1 CRITICAL changes detected - review before committing!\n```\n\n## Arguments\n\n- **$1** (required): OpenShift release version\n  - Format: `X.YY` (e.g., `4.22`, `4.23`, `4.21`)\n  - This will be used in the BigQuery query to filter data for that specific release\n  - The query will fetch the last 30 days of data for this release\n\n## BigQuery Query Details\n\nThe command uses the Python script `.claude/scripts/query_operator_watch_requests.py` to fetch data. \n\n## Notes\n\n- **Uses Python scripts**: Two scripts work together:\n  - `query_operator_watch_requests.py` - Queries BigQuery\n  - `update_operator_watch_limits.py` - Updates JSON file and provides comprehensive summary\n- **Requires `bq` CLI**: Google Cloud SDK must be installed and authenticated (`gcloud auth login`)\n- **BigQuery project**: Always queries `openshift-ci-data-analysis` project\n- **Dataset**: Uses `ci_data_autodl.operator_watch_requests` table\n- **Max rows**: Query limited to 1000 results (up from default 100) to handle all operator/platform/topology combinations\n- **Fixed time window**: Always uses 30 days of data (not configurable - ensures reliable averages)\n- **Release specific**: Only queries data for the specified OpenShift release version\n- **Review before commit**: Always review critical and warning increases before committing\n- **Operator names**: The BigQuery Operator field should match service account names (with or without `-operator` suffix)\n- **Platform names**: Must use lowercase names that match the BigQuery schema (aws, gcp, metal, azure, vsphere, openstack)\n- **Uses Average**: Intentionally uses Average instead of P99/Max because test allows 2x headroom\n- **Preserves unknowns**: Operators not in BigQuery results keep their current values\n- **JSON structure**: Updates `operator_watch_limits.json` directly, organized by topology → platform → operator\n- **Formatting**: Maintains JSON indentation and structure\n- **Re-runnable query**: You can re-run just the BigQuery query with `python3 .claude/scripts/query_operator_watch_requests.py 4.22`\n- **Comprehensive summary**: The update script tracks and categorizes all changes as it processes them, providing a detailed summary at the end\n\n## Error Handling\n\n- **Missing release parameter**: Prompts user to provide release version (e.g., `4.22`)\n- **Invalid release format**: Validates release matches pattern like `4.22` or `4.23`\n- **BigQuery query fails**: Shows error message and exits without modifying files\n- **bq CLI not available**: Checks for `bq` command and provides installation instructions\n- **Authentication required**: Prompts to run `gcloud auth login` if not authenticated\n- **Invalid JSON**: Reports parsing errors with line numbers\n- **Missing fields**: Warns about records missing Platform/Topology/Operator/Average\n- **Unknown platform**: Warns and skips operators on platforms not in the maps\n- **Operator not found**: Notes operators in BigQuery data that don't exist in maps (won't add them)\n- **Compilation fails**: Reverts changes and reports Go build errors\n- **No data**: If query returns empty results, exits without changes and suggests checking the release version\n\n## Warnings\n\n- ⚠️  **Critical increases (>10x)** almost always indicate bugs - investigate before committing\n- ⚠️  **Large increases (2x-10x)** need explanation - check recent code changes\n- ⚠️  **Review the diff** - ensure formatting is preserved and changes make sense\n- ⚠️  **Test compilation** - the command validates but always verify manually\n- ⚠️  **Single node data** - upperBoundsSingleNode only has AWS platform, query may return data for other platforms that can't be used\n\n## See Also\n\n- Python scripts:\n  - `.claude/scripts/query_operator_watch_requests.py` - Fetch BigQuery data for a release\n  - `.claude/scripts/update_operator_watch_limits.py` - Update limits in JSON file and provide summary\n- `/update-operator-watch-request-limits` - Update a single operator limit manually\n- Limits file: `pkg/monitortests/kubeapiserver/auditloganalyzer/operator_watch_limits.json`\n- Test implementation: `pkg/monitortests/kubeapiserver/auditloganalyzer/handle_operator_watch_count_tracking.go`\n- BigQuery dataset: `openshift-ci-data-analysis.ci_data_autodl.operator_watch_requests`\n- Grafana dashboard for exploring avg watch requests over time per operator/platform/etc: https://grafana-loki.ci.openshift.org/d/4RcxG4tSz/watch-counts\n","frontmatter":{"description":"Bulk update all operator watch request limits from BigQuery data","argument-hint":"<release>"},"isInternal":false,"tokens":3045,"sizeBytes":12517},{"name":"origin-dev-setup.md","path":".cursor/commands/origin-dev-setup.md","rawUrl":"https://raw.githubusercontent.com/openshift/origin/HEAD/.cursor/commands/origin-dev-setup.md","title":"Command: /origin-dev-setup","category":"command-prompt","format":"markdown","content":"---\ndescription: Set up the Origin devcontainer (Podman, env, GCP auth)\n---\n\n# Origin dev — devcontainer setup\n\nInteractive setup for the Origin devcontainer. Automates what can be detected, prompts for what can't.\n\n## Workflow\n\n### 1. Detect OS\n\n```bash\nuname -s\n```\n\n- **Darwin** = macOS\n- **Linux** = Linux\n\n### 2. Check prerequisites\n\nVerify each tool is installed. Report any that are missing and stop.\n\n```bash\ncommand -v podman\ncommand -v devcontainer\n```\n\nIf `devcontainer` is missing, tell the user: `npm install -g @devcontainers/cli`\n\n### 3. macOS: Podman machine\n\nIf macOS, check if podman machine is running:\n\n```bash\npodman machine info\n```\n\nIf not initialized or not running, run:\n\n```bash\npodman machine init   # only if no machine exists\npodman machine start\n```\n\n### 4. Linux: Podman socket\n\nIf Linux, check if the socket is active:\n\n```bash\nsystemctl --user is-active podman.socket\n```\n\nIf not active, run:\n\n```bash\nsystemctl --user enable --now podman.socket\n```\n\nAlso check for `podman-docker`:\n\n```bash\ncommand -v docker\n```\n\nIf missing, suggest installing `podman-docker` (dnf or apt depending on `/etc/os-release`).\n\n### 5. Environment file\n\nCheck if `.devcontainer/.env` exists:\n\n```bash\ntest -f .devcontainer/.env\n```\n\nIf missing, copy from the example:\n\n```bash\ncp .devcontainer/.env.example .devcontainer/.env\n```\n\nThen read `.devcontainer/.env` and check for empty required values. If any are blank (e.g. `ANTHROPIC_VERTEX_PROJECT_ID`), tell the user which values need to be filled in and ask them to edit `.devcontainer/.env` and let you know when they're done. **Do not** ask for the values directly or write to the file yourself — the user should edit it. Wait for them to confirm before continuing.\n\n### 6. Start the container\n\nDetermine the right command based on OS:\n\n- **macOS**: `devcontainer up --workspace-folder . --docker-path podman`\n- **Linux** (with `podman-docker`): `devcontainer up --workspace-folder .`\n- **Linux** (without `podman-docker`): `devcontainer up --workspace-folder . --docker-path podman`\n\nRun it. This triggers `post-create.sh` (Go tools, Claude Code, `make build`).\n\n### 7. GCP authentication\n\nGCP credentials are mounted from the host's `~/.config/gcloud` directory. If the user hasn't authenticated on the host yet, tell them to run on the host (not inside the container):\n\n```bash\ngcloud auth application-default login\n```\n\nThe credentials will be available inside the container automatically after restart.\n\n### 8. Summary\n\nPrint a summary of what was set up:\n\n- Container status\n- Claude Code: available via Vertex AI\n- GCP auth status\n- To exec in: `podman exec -it -u vscode -w /workspace origin-dev bash`","frontmatter":{"description":"Set up the Origin devcontainer (Podman, env, GCP auth)"},"isInternal":false,"tokens":693,"sizeBytes":2679},{"name":"origin-dev-setup.md","path":".opencode/commands/origin-dev-setup.md","rawUrl":"https://raw.githubusercontent.com/openshift/origin/HEAD/.opencode/commands/origin-dev-setup.md","title":"Command: /origin-dev-setup","category":"command-prompt","format":"markdown","content":"---\ndescription: Set up the Origin devcontainer (Podman, env, GCP auth)\n---\n\n# Origin dev — devcontainer setup\n\nInteractive setup for the Origin devcontainer. Automates what can be detected, prompts for what can't.\n\n## Workflow\n\n### 1. Detect OS\n\n```bash\nuname -s\n```\n\n- **Darwin** = macOS\n- **Linux** = Linux\n\n### 2. Check prerequisites\n\nVerify each tool is installed. Report any that are missing and stop.\n\n```bash\ncommand -v podman\ncommand -v devcontainer\n```\n\nIf `devcontainer` is missing, tell the user: `npm install -g @devcontainers/cli`\n\n### 3. macOS: Podman machine\n\nIf macOS, check if podman machine is running:\n\n```bash\npodman machine info\n```\n\nIf not initialized or not running, run:\n\n```bash\npodman machine init   # only if no machine exists\npodman machine start\n```\n\n### 4. Linux: Podman socket\n\nIf Linux, check if the socket is active:\n\n```bash\nsystemctl --user is-active podman.socket\n```\n\nIf not active, run:\n\n```bash\nsystemctl --user enable --now podman.socket\n```\n\nAlso check for `podman-docker`:\n\n```bash\ncommand -v docker\n```\n\nIf missing, suggest installing `podman-docker` (dnf or apt depending on `/etc/os-release`).\n\n### 5. Environment file\n\nCheck if `.devcontainer/.env` exists:\n\n```bash\ntest -f .devcontainer/.env\n```\n\nIf missing, copy from the example:\n\n```bash\ncp .devcontainer/.env.example .devcontainer/.env\n```\n\nThen read `.devcontainer/.env` and check for empty required values. If any are blank (e.g. `ANTHROPIC_VERTEX_PROJECT_ID`), tell the user which values need to be filled in and ask them to edit `.devcontainer/.env` and let you know when they're done. **Do not** ask for the values directly or write to the file yourself — the user should edit it. Wait for them to confirm before continuing.\n\n### 6. Start the container\n\nDetermine the right command based on OS:\n\n- **macOS**: `devcontainer up --workspace-folder . --docker-path podman`\n- **Linux** (with `podman-docker`): `devcontainer up --workspace-folder .`\n- **Linux** (without `podman-docker`): `devcontainer up --workspace-folder . --docker-path podman`\n\nRun it. This triggers `post-create.sh` (Go tools, Claude Code, `make build`).\n\n### 7. GCP authentication\n\nGCP credentials are mounted from the host's `~/.config/gcloud` directory. If the user hasn't authenticated on the host yet, tell them to run on the host (not inside the container):\n\n```bash\ngcloud auth application-default login\n```\n\nThe credentials will be available inside the container automatically after restart.\n\n### 8. Summary\n\nPrint a summary of what was set up:\n\n- Container status\n- Claude Code: available via Vertex AI\n- GCP auth status\n- To exec in: `podman exec -it -u vscode -w /workspace origin-dev bash`","frontmatter":{"description":"Set up the Origin devcontainer (Podman, env, GCP auth)"},"isInternal":false,"tokens":693,"sizeBytes":2679}],"systemPromptSnippet":"<yakaai_skills repo=\"openshift/origin\">\n<!-- File: AGENTS.md (Tokens: ~1896 | Category: root-instruction) -->\n# AGENTS.md\n<!-- Generated by APM CLI from distributed .apm/ primitives -->\n<!-- Build ID: 3109b13c034b -->\n<!-- APM Version: 0.13.0 -->\n<!-- Source: local -->\n\n## Files matching `**`\n\n<!-- Source: local .apm/instructions/general.instructions.md -->\n### APM context generation\n\nSources under **`.apm/`** (instructions, prompts, `apm.yml`, etc.) drive generated agent context. After editing those files, run **`make apm`** to regenerate **AGENTS.md**, **CLAUDE.md**, **GEMINI.md**, and the integrated copies under **`.claude/`**, **`.cursor/`**, **`.gemini/`**, **`.github/instructions/`**, **`.github/prompts/`**, and **`.opencode/`**.\n\n**Slash / agent commands:** content under **`.apm/prompts/*.prompt.md`** is the single source of truth. **`apm install`** (part of **`make apm`**) copies each prompt into editor command targets (e.g. **`.claude/commands/`**, **`.opencode/commands/`**, **`.gemini/commands/`**). Do not add those generated paths by hand or installs will skip them as unmanaged duplicates.\n\n### Retry allowlist policy\n\n**`pkg/test/ginkgo/retry_allowed_tests.yaml`** is strictly shrink-only. Never add tests to it. Remove an entry only when its underlying flake is fixed. If a requested change conflicts with this policy, stop and ask for human direction.\n\n### Repository overview\n\n**openshift/origin** builds the `openshift-tests` binary — the orchestrator for all OpenShift end-to-end testing. It contains:\n* **Built-in e2e tests** (Ginkgo) that run against a live cluster.\n* **Monitor tests** that observe cluster health in the background during e2e runs.\n* **Disruption tests** (a category of monitor test) that measure endpoint availability.\n* **Extension orchestration** that discovers and runs tests contributed by other components via the OTE framework.\n\n### Key directories\n\n* **`cmd/openshift-tests/`** — main binary entry point with subcommands: `run`, `run-test`, `run-monitor`, `run-upgrade`, `disruption`, `list`, `info`, `extension-admission`, and more.\n* **`pkg/testsuites/`** — test suite definitions that compose built-in and extension tests.\n* **`test/extended/`** — Ginkgo-based e2e test packages organized by area (e.g. `networking/`, `storage/`, `etcd/`).\n* **`test/extended/include.go`** — blank imports that register all e2e test packages. New packages **must** be added here.\n* **`test/e2e/upgrade/`** — upgrade-specific e2e tests.\n* **`pkg/monitortestframework/`** — `MonitorTest` interface and registry.\n* **`pkg/defaultmonitortests/`** — registers default monitor tests for stable and disruptive scenarios.\n* **`pkg/monitortests/`** — individual monitor test implementations organized by component (e.g. `etcd/`, `kubeapiserver/`, `network/`, `node/`).\n* **`pkg/monitortestlibrary/`** — shared monitor utilities (allowed disruption baselines, alert allowlists, platform identification).\n* **`pkg/disruption/`** — disruption measurement framework (HTTP/gRPC sampling, transport hooks, shutdown detection).\n* **`pkg/test/extensions/`** — OTE extension binary extraction, execution, and admission control.\n* **`vendor/`** — vendored dependencies. Run `go mod tidy && go mod vendor` after changing `go.mod` to keep `go.sum` and `vendor/` in sync.\n\n### E2e tests\n\nGinkgo-based tests in `test/extended/<area>/` run against a live OpenShift cluster. Each package is registered via blank import in `test/extended/include.go`. These are the \"built-in\" tests that ship inside the `openshift-tests` binary. Tests are grouped into suites (e.g. `openshift/conformance/parallel`) defined in `pkg/testsuites/`.\n\n### Monitor tests\n\nMonitor tests run **in parallel** with the e2e suite to continuously observe cluster health. They follow a lifecycle:\n1. **`StartCollection()`** — begin watching resources, recording events.\n2. *(e2e tests execute)*\n3. **`CollectData()`** — final data collection pass.\n4. **`ConstructComputedIntervals()`** — analyze raw data into structured intervals.\n5. **`EvaluateTestsFromConstructedIntervals()`** — produce JUnit pass/fail results.\n\nMonitor tests are registered in `pkg/defaultmonitortests/types.go` with two stability levels: **Stable** (normal operation — runs all monitors including availability checks) and **Disruptive** (tests that intentionally cause outages like upgrades, node drains, etcd recovery, or cert rotation — availability monitors are excluded since measuring uptime during intentional disruption would produce false failures). Implementations live in `pkg/monitortests/` organized by component — examples include etcd log analysis, cluster operator state tracking, node readiness, API server availability, and alert evaluation.\n\n### Disruption tests\n\nDisruption tests are a category of monitor test that measure **endpoint availability** during test runs. They continuously poll services (API servers, ingress, image registry, pod network) and record availability intervals. Allowed disruption baselines in `pkg/monitortestlibrary/allowedbackenddisruption/` define acceptable unavailability thresholds. Key implementations live in `pkg/monitortests/kubeapiserver/`, `pkg/monitortests/network/`, and `pkg/monitortests/imageregistry/`.\n\n### Extensions (OTE — OpenShift Tests Extension)\n\nThe `openshift-tests` binary acts as an **orchestrator** for tests contributed by other components. The [openshift-tests-extension](https://github.com/openshift-eng/openshift-tests-extension) (OTE) framework defines a standardized interface that external binaries implement:\n* **`<binary> info`** — return extension metadata (component, suites, version).\n* **`<binary> list -o jsonl`** — list available tests, filtered by environment (platform, arch, network).\n* **`<binary> run-test -n <name>`** — execute a specific test and return JSONL results.\n\n**Payload extensions** are test binaries shipped inside release payload images. The registry in `pkg/test/extensions/binary.go` maps ~35 payload image tags to their test binary paths. At runtime, `openshift-tests` extracts these binaries, discovers their tests, and runs them alongside built-in tests.\n\n**Non-payload extensions** are discovered from ImageStreamTags in the cluster and require explicit approval via a `TestExtensionAdmission` CRD. The `extension-admission` subcommand manages these approval rules.\n\nOrigin also registers itself as an extension (`openshift:payload:origin`) so its own built-in Ginkgo tests appear in the unified extension registry alongside external tests.\n\n### Build and verify\n\n* **Build:** `make build` or `make openshift-tests` (produces `./openshift-tests`).\n* **Unit tests:** `go test ./pkg/...` (fast, no cluster required).\n* **Lint / verify:** `make verify` (runs `go vet`, jsonformat, generated-file checks, TLS ownership).\n* **Full check:** `make check` (verify + build + tests).\n\nFavor clarity and maintainability over cleverness. Comments should be minimal, helpful, and explain the \"why\" not the \"what\".\n\n## Files matching `**/*_test.go`\n\n<!-- Source: local .apm/instructions/testing.instructions.md -->\n* Use `go vet ./...` and `go test ./pkg/...` to validate changes before committing.\n* E2e tests in `test/extended/<area>/` are **platform-level tests for OpenShift** — they run against a live cluster to validate the product, not just this repo. They use the **Ginkgo** framework and are compiled into the `openshift-tests` binary that CI runs against every payload.\n* `test/extended/include.go` blank-imports every e2e test package — new packages **must** be added there or they won't be compiled into the binary.\n* Unit tests in `pkg/` use standard Go `testing` with **table-driven** patterns.\n* Build the test binary: `make openshift-tests` or `make build`.\n* For unit tests, prefer **table-driven tests** with descriptive case names. Search the same package for existing test patterns before writing new ones.\n\n---\n*This file was generated by APM CLI. Do not edit manually.*\n*To regenerate: `apm compile`*\n\n<!-- File: .claude/rules/general.md (Tokens: ~1594 | Category: anthropic-skill) -->\n---\npaths:\n  - \"**\"\n---\n\n### APM context generation\n\nSources under **`.apm/`** (instructions, prompts, `apm.yml`, etc.) drive generated agent context. After editing those files, run **`make apm`** to regenerate **AGENTS.md**, **CLAUDE.md**, **GEMINI.md**, and the integrated copies under **`.claude/`**, **`.cursor/`**, **`.gemini/`**, **`.github/instructions/`**, **`.github/prompts/`**, and **`.opencode/`**.\n\n**Slash / agent commands:** content under **`.apm/prompts/*.prompt.md`** is the single source of truth. **`apm install`** (part of **`make apm`**) copies each prompt into editor command targets (e.g. **`.claude/commands/`**, **`.opencode/commands/`**, **`.gemini/commands/`**). Do not add those generated paths by hand or installs will skip them as unmanaged duplicates.\n\n### Retry allowlist policy\n\n**`pkg/test/ginkgo/retry_allowed_tests.yaml`** is strictly shrink-only. Never add tests to it. Remove an entry only when its underlying flake is fixed. If a requested change conflicts with this policy, stop and ask for human direction.\n\n### Repository overview\n\n**openshift/origin** builds the `openshift-tests` binary — the orchestrator for all OpenShift end-to-end testing. It contains:\n* **Built-in e2e tests** (Ginkgo) that run against a live cluster.\n* **Monitor tests** that observe cluster health in the background during e2e runs.\n* **Disruption tests** (a category of monitor test) that measure endpoint availability.\n* **Extension orchestration** that discovers and runs tests contributed by other components via the OTE framework.\n\n### Key directories\n\n* **`cmd/openshift-tests/`** — main binary entry point with subcommands: `run`, `run-test`, `run-monitor`, `run-upgrade`, `disruption`, `list`, `info`, `extension-admission`, and more.\n* **`pkg/testsuites/`** — test suite definitions that compose built-in and extension tests.\n* **`test/extended/`** — Ginkgo-based e2e test packages organized by area (e.g. `networking/`, `storage/`, `etcd/`).\n* **`test/extended/include.go`** — blank imports that register all e2e test packages. New packages **must** be added here.\n* **`test/e2e/upgrade/`** — upgrade-specific e2e tests.\n* **`pkg/monitortestframework/`** — `MonitorTest` interface and registry.\n* **`pkg/defaultmonitortests/`** — registers default monitor tests for stable and disruptive scenarios.\n* **`pkg/monitortests/`** — individual monitor test implementations organized by component (e.g. `etcd/`, `kubeapiserver/`, `network/`, `node/`).\n* **`pkg/monitortestlibrary/`** — shared monitor utilities (allowed disruption baselines, alert allowlists, platform identification).\n* **`pkg/disruption/`** — disruption measurement framework (HTTP/gRPC sampling, transport hooks, shutdown detection).\n* **`pkg/test/extensions/`** — OTE extension binary extraction, execution, and admission control.\n* **`vendor/`** — vendored dependencies. Run `go mod tidy && go mod vendor` after changing `go.mod` to keep `go.sum` and `vendor/` in sync.\n\n### E2e tests\n\nGinkgo-based tests in `test/extended/<area>/` run against a live OpenShift cluster. Each package is registered via blank import in `test/extended/include.go`. These are the \"built-in\" tests that ship inside the `openshift-tests` binary. Tests are grouped into suites (e.g. `openshift/conformance/parallel`) defined in `pkg/testsuites/`.\n\n### Monitor tests\n\nMonitor tests run **in parallel** with the e2e suite to continuously observe cluster health. They follow a lifecycle:\n1. **`StartCollection()`** — begin watching resources, recording events.\n2. *(e2e tests execute)*\n3. **`CollectData()`** — final data collection pass.\n4. **`ConstructComputedIntervals()`** — analyze raw data into structured intervals.\n5. **`EvaluateTestsFromConstructedIntervals()`** — produce JUnit pass/fail results.\n\nMonitor tests are registered in `pkg/defaultmonitortests/types.go` with two stability levels: **Stable** (normal operation — runs all monitors including availability checks) and **Disruptive** (tests that intentionally cause outages like upgrades, node drains, etcd recovery, or cert rotation — availability monitors are excluded since measuring uptime during intentional disruption would produce false failures). Implementations live in `pkg/monitortests/` organized by component — examples include etcd log analysis, cluster operator state tracking, node readiness, API server availability, and alert evaluation.\n\n### Disruption tests\n\nDisruption tests are a category of monitor test that measure **endpoint availability** during test runs. They continuously poll services (API servers, ingress, image registry, pod network) and record availability intervals. Allowed disruption baselines in `pkg/monitortestlibrary/allowedbackenddisruption/` define acceptable unavailability thresholds. Key implementations live in `pkg/monitortests/kubeapiserver/`, `pkg/monitortests/network/`, and `pkg/monitortests/imageregistry/`.\n\n### Extensions (OTE — OpenShift Tests Extension)\n\nThe `openshift-tests` binary acts as an **orchestrator** for tests contributed by other components. The [openshift-tests-extension](https://github.com/openshift-eng/openshift-tests-extension) (OTE) framework defines a standardized interface that external binaries implement:\n* **`<binary> info`** — return extension metadata (component, suites, version).\n* **`<binary> list -o jsonl`** — list available tests, filtered by environment (platform, arch, network).\n* **`<binary> run-test -n <name>`** — execute a specific test and return JSONL results.\n\n**Payload extensions** are test binaries shipped inside release payload images. The registry in `pkg/test/extensions/binary.go` maps ~35 payload image tags to their test binary paths. At runtime, `openshift-tests` extracts these binaries, discovers their tests, and runs them alongside built-in tests.\n\n**Non-payload extensions** are discovered from ImageStreamTags in the cluster and require explicit approval via a `TestExtensionAdmission` CRD. The `extension-admission` subcommand manages these approval rules.\n\nOrigin also registers itself as an extension (`openshift:payload:origin`) so its own built-in Ginkgo tests appear in the unified extension registry alongside external tests.\n\n### Build and verify\n\n* **Build:** `make build` or `make openshift-tests` (produces `./openshift-tests`).\n* **Unit tests:** `go test ./pkg/...` (fast, no cluster required).\n* **Lint / verify:** `make verify` (runs `go vet`, jsonformat, generated-file checks, TLS ownership).\n* **Full check:** `make check` (verify + build + tests).\n\nFavor clarity and maintainability over cleverness. Comments should be minimal, helpful, and explain the \"why\" not the \"what\".\n\n<!-- File: .claude/rules/testing.md (Tokens: ~205 | Category: anthropic-skill) -->\n---\npaths:\n  - \"**/*_test.go\"\n---\n\n* Use `go vet ./...` and `go test ./pkg/...` to validate changes before committing.\n* E2e tests in `test/extended/<area>/` are **platform-level tests for OpenShift** — they run against a live cluster to validate the product, not just this repo. They use the **Ginkgo** framework and are compiled into the `openshift-tests` binary that CI runs against every payload.\n* `test/extended/include.go` blank-imports every e2e test package — new packages **must** be added there or they won't be compiled into the binary.\n* Unit tests in `pkg/` use standard Go `testing` with **table-driven** patterns.\n* Build the test binary: `make openshift-tests` or `make build`.\n* For unit tests, prefer **table-driven tests** with descriptive case names. Search the same package for existing test patterns before writing new ones.\n\n<!-- File: .cursor/rules/general.mdc (Tokens: ~1605 | Category: cursor-rule) -->\n---\ndescription: Origin repository overview, architecture, and coding guidelines\nglobs: \"**\"\n---\n\n### APM context generation\n\nSources under **`.apm/`** (instructions, prompts, `apm.yml`, etc.) drive generated agent context. After editing those files, run **`make apm`** to regenerate **AGENTS.md**, **CLAUDE.md**, **GEMINI.md**, and the integrated copies under **`.claude/`**, **`.cursor/`**, **`.gemini/`**, **`.github/instructions/`**, **`.github/prompts/`**, and **`.opencode/`**.\n\n**Slash / agent commands:** content under **`.apm/prompts/*.prompt.md`** is the single source of truth. **`apm install`** (part of **`make apm`**) copies each prompt into editor command targets (e.g. **`.claude/commands/`**, **`.opencode/commands/`**, **`.gemini/commands/`**). Do not add those generated paths by hand or installs will skip them as unmanaged duplicates.\n\n### Retry allowlist policy\n\n**`pkg/test/ginkgo/retry_allowed_tests.yaml`** is strictly shrink-only. Never add tests to it. Remove an entry only when its underlying flake is fixed. If a requested change conflicts with this policy, stop and ask for human direction.\n\n### Repository overview\n\n**openshift/origin** builds the `openshift-tests` binary — the orchestrator for all OpenShift end-to-end testing. It contains:\n* **Built-in e2e tests** (Ginkgo) that run against a live cluster.\n* **Monitor tests** that observe cluster health in the background during e2e runs.\n* **Disruption tests** (a category of monitor test) that measure endpoint availability.\n* **Extension orchestration** that discovers and runs tests contributed by other components via the OTE framework.\n\n### Key directories\n\n* **`cmd/openshift-tests/`** — main binary entry point with subcommands: `run`, `run-test`, `run-monitor`, `run-upgrade`, `disruption`, `list`, `info`, `extension-admission`, and more.\n* **`pkg/testsuites/`** — test suite definitions that compose built-in and extension tests.\n* **`test/extended/`** — Ginkgo-based e2e test packages organized by area (e.g. `networking/`, `storage/`, `etcd/`).\n* **`test/extended/include.go`** — blank imports that register all e2e test packages. New packages **must** be added here.\n* **`test/e2e/upgrade/`** — upgrade-specific e2e tests.\n* **`pkg/monitortestframework/`** — `MonitorTest` interface and registry.\n* **`pkg/defaultmonitortests/`** — registers default monitor tests for stable and disruptive scenarios.\n* **`pkg/monitortests/`** — individual monitor test implementations organized by component (e.g. `etcd/`, `kubeapiserver/`, `network/`, `node/`).\n* **`pkg/monitortestlibrary/`** — shared monitor utilities (allowed disruption baselines, alert allowlists, platform identification).\n* **`pkg/disruption/`** — disruption measurement framework (HTTP/gRPC sampling, transport hooks, shutdown detection).\n* **`pkg/test/extensions/`** — OTE extension binary extraction, execution, and admission control.\n* **`vendor/`** — vendored dependencies. Run `go mod tidy && go mod vendor` after changing `go.mod` to keep `go.sum` and `vendor/` in sync.\n\n### E2e tests\n\nGinkgo-based tests in `test/extended/<area>/` run against a live OpenShift cluster. Each package is registered via blank import in `test/extended/include.go`. These are the \"built-in\" tests that ship inside the `openshift-tests` binary. Tests are grouped into suites (e.g. `openshift/conformance/parallel`) defined in `pkg/testsuites/`.\n\n### Monitor tests\n\nMonitor tests run **in parallel** with the e2e suite to continuously observe cluster health. They follow a lifecycle:\n1. **`StartCollection()`** — begin watching resources, recording events.\n2. *(e2e tests execute)*\n3. **`CollectData()`** — final data collection pass.\n4. **`ConstructComputedIntervals()`** — analyze raw data into structured intervals.\n5. **`EvaluateTestsFromConstructedIntervals()`** — produce JUnit pass/fail results.\n\nMonitor tests are registered in `pkg/defaultmonitortests/types.go` with two stability levels: **Stable** (normal operation — runs all monitors including availability checks) and **Disruptive** (tests that intentionally cause outages like upgrades, node drains, etcd recovery, or cert rotation — availability monitors are excluded since measuring uptime during intentional disruption would produce false failures). Implementations live in `pkg/monitortests/` organized by component — examples include etcd log analysis, cluster operator state tracking, node readiness, API server availability, and alert evaluation.\n\n### Disruption tests\n\nDisruption tests are a category of monitor test that measure **endpoint availability** during test runs. They continuously poll services (API servers, ingress, image registry, pod network) and record availability intervals. Allowed disruption baselines in `pkg/monitortestlibrary/allowedbackenddisruption/` define acceptable unavailability thresholds. Key implementations live in `pkg/monitortests/kubeapiserver/`, `pkg/monitortests/network/`, and `pkg/monitortests/imageregistry/`.\n\n### Extensions (OTE — OpenShift Tests Extension)\n\nThe `openshift-tests` binary acts as an **orchestrator** for tests contributed by other components. The [openshift-tests-extension](https://github.com/openshift-eng/openshift-tests-extension) (OTE) framework defines a standardized interface that external binaries implement:\n* **`<binary> info`** — return extension metadata (component, suites, version).\n* **`<binary> list -o jsonl`** — list available tests, filtered by environment (platform, arch, network).\n* **`<binary> run-test -n <name>`** — execute a specific test and return JSONL results.\n\n**Payload extensions** are test binaries shipped inside release payload images. The registry in `pkg/test/extensions/binary.go` maps ~35 payload image tags to their test binary paths. At runtime, `openshift-tests` extracts these binaries, discovers their tests, and runs them alongside built-in tests.\n\n**Non-payload extensions** are discovered from ImageStreamTags in the cluster and require explicit approval via a `TestExtensionAdmission` CRD. The `extension-admission` subcommand manages these approval rules.\n\nOrigin also registers itself as an extension (`openshift:payload:origin`) so its own built-in Ginkgo tests appear in the unified extension registry alongside external tests.\n\n### Build and verify\n\n* **Build:** `make build` or `make openshift-tests` (produces `./openshift-tests`).\n* **Unit tests:** `go test ./pkg/...` (fast, no cluster required).\n* **Lint / verify:** `make verify` (runs `go vet`, jsonformat, generated-file checks, TLS ownership).\n* **Full check:** `make check` (verify + build + tests).\n\nFavor clarity and maintainability over cleverness. Comments should be minimal, helpful, and explain the \"why\" not the \"what\".\n\n<!-- File: .cursor/rules/testing.mdc (Tokens: ~213 | Category: cursor-rule) -->\n---\ndescription: Testing guidelines and patterns for origin\nglobs: \"**/*_test.go\"\n---\n\n* Use `go vet ./...` and `go test ./pkg/...` to validate changes before committing.\n* E2e tests in `test/extended/<area>/` are **platform-level tests for OpenShift** — they run against a live cluster to validate the product, not just this repo. They use the **Ginkgo** framework and are compiled into the `openshift-tests` binary that CI runs against every payload.\n* `test/extended/include.go` blank-imports every e2e test package — new packages **must** be added there or they won't be compiled into the binary.\n* Unit tests in `pkg/` use standard Go `testing` with **table-driven** patterns.\n* Build the test binary: `make openshift-tests` or `make build`.\n* For unit tests, prefer **table-driven tests** with descriptive case names. Search the same package for existing test patterns before writing new ones.\n\n<!-- File: CLAUDE.md (Tokens: ~1889 | Category: claude-rule) -->\n# CLAUDE.md\n<!-- Generated by APM CLI -->\n<!-- Build ID: b79f3567f84e -->\n<!-- APM Version: 0.13.0 -->\n\n# Project Standards\n\n## Files matching `**`\n\n<!-- Source: local .apm/instructions/general.instructions.md -->\n### APM context generation\n\nSources under **`.apm/`** (instructions, prompts, `apm.yml`, etc.) drive generated agent context. After editing those files, run **`make apm`** to regenerate **AGENTS.md**, **CLAUDE.md**, **GEMINI.md**, and the integrated copies under **`.claude/`**, **`.cursor/`**, **`.gemini/`**, **`.github/instructions/`**, **`.github/prompts/`**, and **`.opencode/`**.\n\n**Slash / agent commands:** content under **`.apm/prompts/*.prompt.md`** is the single source of truth. **`apm install`** (part of **`make apm`**) copies each prompt into editor command targets (e.g. **`.claude/commands/`**, **`.opencode/commands/`**, **`.gemini/commands/`**). Do not add those generated paths by hand or installs will skip them as unmanaged duplicates.\n\n### Retry allowlist policy\n\n**`pkg/test/ginkgo/retry_allowed_tests.yaml`** is strictly shrink-only. Never add tests to it. Remove an entry only when its underlying flake is fixed. If a requested change conflicts with this policy, stop and ask for human direction.\n\n### Repository overview\n\n**openshift/origin** builds the `openshift-tests` binary — the orchestrator for all OpenShift end-to-end testing. It contains:\n* **Built-in e2e tests** (Ginkgo) that run against a live cluster.\n* **Monitor tests** that observe cluster health in the background during e2e runs.\n* **Disruption tests** (a category of monitor test) that measure endpoint availability.\n* **Extension orchestration** that discovers and runs tests contributed by other components via the OTE framework.\n\n### Key directories\n\n* **`cmd/openshift-tests/`** — main binary entry point with subcommands: `run`, `run-test`, `run-monitor`, `run-upgrade`, `disruption`, `list`, `info`, `extension-admission`, and more.\n* **`pkg/testsuites/`** — test suite definitions that compose built-in and extension tests.\n* **`test/extended/`** — Ginkgo-based e2e test packages organized by area (e.g. `networking/`, `storage/`, `etcd/`).\n* **`test/extended/include.go`** — blank imports that register all e2e test packages. New packages **must** be added here.\n* **`test/e2e/upgrade/`** — upgrade-specific e2e tests.\n* **`pkg/monitortestframework/`** — `MonitorTest` interface and registry.\n* **`pkg/defaultmonitortests/`** — registers default monitor tests for stable and disruptive scenarios.\n* **`pkg/monitortests/`** — individual monitor test implementations organized by component (e.g. `etcd/`, `kubeapiserver/`, `network/`, `node/`).\n* **`pkg/monitortestlibrary/`** — shared monitor utilities (allowed disruption baselines, alert allowlists, platform identification).\n* **`pkg/disruption/`** — disruption measurement framework (HTTP/gRPC sampling, transport hooks, shutdown detection).\n* **`pkg/test/extensions/`** — OTE extension binary extraction, execution, and admission control.\n* **`vendor/`** — vendored dependencies. Run `go mod tidy && go mod vendor` after changing `go.mod` to keep `go.sum` and `vendor/` in sync.\n\n### E2e tests\n\nGinkgo-based tests in `test/extended/<area>/` run against a live OpenShift cluster. Each package is registered via blank import in `test/extended/include.go`. These are the \"built-in\" tests that ship inside the `openshift-tests` binary. Tests are grouped into suites (e.g. `openshift/conformance/parallel`) defined in `pkg/testsuites/`.\n\n### Monitor tests\n\nMonitor tests run **in parallel** with the e2e suite to continuously observe cluster health. They follow a lifecycle:\n1. **`StartCollection()`** — begin watching resources, recording events.\n2. *(e2e tests execute)*\n3. **`CollectData()`** — final data collection pass.\n4. **`ConstructComputedIntervals()`** — analyze raw data into structured intervals.\n5. **`EvaluateTestsFromConstructedIntervals()`** — produce JUnit pass/fail results.\n\nMonitor tests are registered in `pkg/defaultmonitortests/types.go` with two stability levels: **Stable** (normal operation — runs all monitors including availability checks) and **Disruptive** (tests that intentionally cause outages like upgrades, node drains, etcd recovery, or cert rotation — availability monitors are excluded since measuring uptime during intentional disruption would produce false failures). Implementations live in `pkg/monitortests/` organized by component — examples include etcd log analysis, cluster operator state tracking, node readiness, API server availability, and alert evaluation.\n\n### Disruption tests\n\nDisruption tests are a category of monitor test that measure **endpoint availability** during test runs. They continuously poll services (API servers, ingress, image registry, pod network) and record availability intervals. Allowed disruption baselines in `pkg/monitortestlibrary/allowedbackenddisruption/` define acceptable unavailability thresholds. Key implementations live in `pkg/monitortests/kubeapiserver/`, `pkg/monitortests/network/`, and `pkg/monitortests/imageregistry/`.\n\n### Extensions (OTE — OpenShift Tests Extension)\n\nThe `openshift-tests` binary acts as an **orchestrator** for tests contributed by other components. The [openshift-tests-extension](https://github.com/openshift-eng/openshift-tests-extension) (OTE) framework defines a standardized interface that external binaries implement:\n* **`<binary> info`** — return extension metadata (component, suites, version).\n* **`<binary> list -o jsonl`** — list available tests, filtered by environment (platform, arch, network).\n* **`<binary> run-test -n <name>`** — execute a specific test and return JSONL results.\n\n**Payload extensions** are test binaries shipped inside release payload images. The registry in `pkg/test/extensions/binary.go` maps ~35 payload image tags to their test binary paths. At runtime, `openshift-tests` extracts these binaries, discovers their tests, and runs them alongside built-in tests.\n\n**Non-payload extensions** are discovered from ImageStreamTags in the cluster and require explicit approval via a `TestExtensionAdmission` CRD. The `extension-admission` subcommand manages these approval rules.\n\nOrigin also registers itself as an extension (`openshift:payload:origin`) so its own built-in Ginkgo tests appear in the unified extension registry alongside external tests.\n\n### Build and verify\n\n* **Build:** `make build` or `make openshift-tests` (produces `./openshift-tests`).\n* **Unit tests:** `go test ./pkg/...` (fast, no cluster required).\n* **Lint / verify:** `make verify` (runs `go vet`, jsonformat, generated-file checks, TLS ownership).\n* **Full check:** `make check` (verify + build + tests).\n\nFavor clarity and maintainability over cleverness. Comments should be minimal, helpful, and explain the \"why\" not the \"what\".\n\n## Files matching `**/*_test.go`\n\n<!-- Source: local .apm/instructions/testing.instructions.md -->\n* Use `go vet ./...` and `go test ./pkg/...` to validate changes before committing.\n* E2e tests in `test/extended/<area>/` are **platform-level tests for OpenShift** — they run against a live cluster to validate the product, not just this repo. They use the **Ginkgo** framework and are compiled into the `openshift-tests` binary that CI runs against every payload.\n* `test/extended/include.go` blank-imports every e2e test package — new packages **must** be added there or they won't be compiled into the binary.\n* Unit tests in `pkg/` use standard Go `testing` with **table-driven** patterns.\n* Build the test binary: `make openshift-tests` or `make build`.\n* For unit tests, prefer **table-driven tests** with descriptive case names. Search the same package for existing test patterns before writing new ones.\n\n---\n*This file was generated by APM CLI. Do not edit manually.*\n*To regenerate: `apm compile`*\n\n<!-- File: GEMINI.md (Tokens: ~43 | Category: gemini-rule) -->\n# GEMINI.md\n<!-- Generated by APM CLI -->\n<!-- Build ID: 01de98569d95 -->\n<!-- APM Version: 0.13.0 -->\n\n@./AGENTS.md\n\n<!-- File: tools/etcdhelper/README.md (Tokens: ~300 | Category: plugin-manifest) -->\n# etcdhelper Documentation\n\nPath: `tools/etcdhelper/README.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/openshift/origin/HEAD/tools/etcdhelper/README.md)\n\n<!-- File: tools/junitreport/README.md (Tokens: ~300 | Category: plugin-manifest) -->\n# junitreport Documentation\n\nPath: `tools/junitreport/README.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/openshift/origin/HEAD/tools/junitreport/README.md)\n\n<!-- File: vendor/github.com/google/gnostic-models/extensions/README.md (Tokens: ~300 | Category: plugin-manifest) -->\n# extensions Documentation\n\nPath: `vendor/github.com/google/gnostic-models/extensions/README.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/openshift/origin/HEAD/vendor/github.com/google/gnostic-models/extensions/README.md)\n\n<!-- File: vendor/k8s.io/kubernetes/pkg/scheduler/framework/plugins/README.md (Tokens: ~300 | Category: plugin-manifest) -->\n# plugins Documentation\n\nPath: `vendor/k8s.io/kubernetes/pkg/scheduler/framework/plugins/README.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/openshift/origin/HEAD/vendor/k8s.io/kubernetes/pkg/scheduler/framework/plugins/README.md)\n\n<!-- File: .cursor/mcp.json (Tokens: ~43 | Category: mcp-config) -->\n{\n  \"mcpServers\": {\n    \"atlassian\": {\n      \"type\": \"http\",\n      \"url\": \"https://mcp.atlassian.com/v1/mcp\"\n    }\n  }\n}\n\n<!-- File: .claude/commands/origin-dev-setup.md (Tokens: ~693 | Category: command-prompt) -->\n---\ndescription: Set up the Origin devcontainer (Podman, env, GCP auth)\n---\n\n# Origin dev — devcontainer setup\n\nInteractive setup for the Origin devcontainer. Automates what can be detected, prompts for what can't.\n\n## Workflow\n\n### 1. Detect OS\n\n```bash\nuname -s\n```\n\n- **Darwin** = macOS\n- **Linux** = Linux\n\n### 2. Check prerequisites\n\nVerify each tool is installed. Report any that are missing and stop.\n\n```bash\ncommand -v podman\ncommand -v devcontainer\n```\n\nIf `devcontainer` is missing, tell the user: `npm install -g @devcontainers/cli`\n\n### 3. macOS: Podman machine\n\nIf macOS, check if podman machine is running:\n\n```bash\npodman machine info\n```\n\nIf not initialized or not running, run:\n\n```bash\npodman machine init   # only if no machine exists\npodman machine start\n```\n\n### 4. Linux: Podman socket\n\nIf Linux, check if the socket is active:\n\n```bash\nsystemctl --user is-active podman.socket\n```\n\nIf not active, run:\n\n```bash\nsystemctl --user enable --now podman.socket\n```\n\nAlso check for `podman-docker`:\n\n```bash\ncommand -v docker\n```\n\nIf missing, suggest installing `podman-docker` (dnf or apt depending on `/etc/os-release`).\n\n### 5. Environment file\n\nCheck if `.devcontainer/.env` exists:\n\n```bash\ntest -f .devcontainer/.env\n```\n\nIf missing, copy from the example:\n\n```bash\ncp .devcontainer/.env.example .devcontainer/.env\n```\n\nThen read `.devcontainer/.env` and check for empty required values. If any are blank (e.g. `ANTHROPIC_VERTEX_PROJECT_ID`), tell the user which values need to be filled in and ask them to edit `.devcontainer/.env` and let you know when they're done. **Do not** ask for the values directly or write to the file yourself — the user should edit it. Wait for them to confirm before continuing.\n\n### 6. Start the container\n\nDetermine the right command based on OS:\n\n- **macOS**: `devcontainer up --workspace-folder . --docker-path podman`\n- **Linux** (with `podman-docker`): `devcontainer up --workspace-folder .`\n- **Linux** (without `podman-docker`): `devcontainer up --workspace-folder . --docker-path podman`\n\nRun it. This triggers `post-create.sh` (Go tools, Claude Code, `make build`).\n\n### 7. GCP authentication\n\nGCP credentials are mounted from the host's `~/.config/gcloud` directory. If the user hasn't authenticated on the host yet, tell them to run on the host (not inside the container):\n\n```bash\ngcloud auth application-default login\n```\n\nThe credentials will be available inside the container automatically after restart.\n\n### 8. Summary\n\nPrint a summary of what was set up:\n\n- Container status\n- Claude Code: available via Vertex AI\n- GCP auth status\n- To exec in: `podman exec -it -u vscode -w /workspace origin-dev bash`\n\n<!-- File: .claude/commands/update-all-operator-watch-request-limits.md (Tokens: ~3045 | Category: command-prompt) -->\n---\ndescription: Bulk update all operator watch request limits from BigQuery data\nargument-hint: <release>\n---\n\n## Name\n\nupdate-all-operator-watch-request-limits\n\n## Synopsis\n\n```\n/update-all-operator-watch-request-limits <release>\n```\n\n## Description\n\nThe `update-all-operator-watch-request-limits` command performs a bulk update of ALL operator watch request limits in the test by querying live data from BigQuery. This is used to refresh all limits at once based on recent CI data (last 30 days), rather than updating operators one at a time.\n\n**What this command does:**\n1. Runs `.claude/scripts/query_operator_watch_requests.py` to fetch BigQuery data for the specified release\n2. Pipes the JSON results to `.claude/scripts/update_operator_watch_limits.py` to update the JSON file\n3. Updates ALL existing limits in the JSON file for both topologies (HighlyAvailable and SingleReplica)\n4. Shows a categorized summary of all changes as they're applied:\n   - Critical increases (>10x) - likely bugs\n   - Warning increases (2x-10x) - need investigation\n   - Major decreases (<50%) - significant reductions\n   - Normal increases/decreases - expected changes\n\n**Important notes:**\n- Uses the P99 over the past 30 days. Note the test allows 2x this limit before it will complain allowing for natural growth.\n- Only updates operators that already exist in the JSON (doesn't add new ones automatically)\n- Updates `operator_watch_limits.json` directly \n- Preserves JSON formatting and structure\n- Highlights concerning increases for manual review before committing\n\n## Implementation\n\n### 1. Fetch BigQuery Data and Update Limits\n\nExecutes the query script and pipes output to the update script:\n\n```bash\n# Query BigQuery and pipe directly to update script\npython3 .claude/scripts/query_operator_watch_requests.py \"$RELEASE\" | \\\n  python3 .claude/scripts/update_operator_watch_limits.py\n```\n\nThe query script:\n- Invokes `bq query` via command line with `--max_rows=1000` to handle all results (up from default 100)\n- Queries the `openshift-ci-data-analysis.ci_data_autodl.operator_watch_requests` table\n- Uses the last 30 days of data for the specified release\n- Outputs JSON to stdout (piped to update script)\n\nThe update script:\n- Reads JSON from stdin\n- Updates operator_watch_limits.json with new values\n- Tracks all changes as it processes them\n- Categorizes changes by severity (critical, warning, decreases, normal)\n- Outputs a comprehensive summary at the end\n\n**Expected JSON results:**\n```json\n[{\n  \"Platform\": \"aws\",\n  \"Release\": \"4.22\",\n  \"Topology\": \"ha\",\n  \"Operator\": \"cluster-capi-operator\",\n  \"Average\": \"117.0\",\n  \"Max_WatchCount\": \"216\",\n  \"P99_WatchCount\": \"199\"\n}, ...]\n```\n\n### 2. Summarize Changes\n\nAfter updating the JSON file, summarize the changes using git diff:\n\n```bash\n# Show summary of what changed\npython3 .claude/scripts/summarize_operator_watch_changes.py\n```\n\nThe summarize script:\n- Parses `git diff` of operator_watch_limits.json\n- Categorizes changes: critical (>10x), warning (2x-10x), decreases (<50%), normal (<2x)\n- Provides a human-readable summary of all changes\n\nThe update script accepts JSON from stdin and:\n- Updates operator_watch_limits.json directly\n- Preserves JSON structure and formatting\n\n### 3. Parse and Map Data\n\n**Platform name mapping:**\n- `aws` → `AWS` (in JSON)\n- `azure` → `Azure` (in JSON)\n- `gcp` → `GCP` (in JSON)\n- `metal` → `BareMetal` (in JSON)\n- `vsphere` → `vSphere` (in JSON)\n- `openstack` → `OpenStack` (in JSON)\n\n**Topology mapping:**\n- `ha` → `HighlyAvailable` (in JSON)\n- `single` → `SingleReplica` (in JSON)\n\n**Operator name mapping:**\nThe BigQuery data may have operator names without `-operator` suffix. The command will:\n- Ensure the operator name ends with `-operator`\n- Match it against existing keys in the maps\n- Examples:\n  - `cluster-capi-operator` → `cluster-capi-operator` (already correct)\n  - `capi-operator` → Skip (not a known service account pattern, may be data issue)\n  - `cluster-monitoring` → `cluster-monitoring-operator`\n\n### 4. Update Limits in JSON\n\nFor each operator in the BigQuery results:\n\n1. Find the corresponding entry in the JSON file under the appropriate topology and platform\n2. Extract the P99 value and round to nearest integer\n3. Compare with old value and categorize the change\n4. Update the JSON entry with the new value\n5. Track the change for the summary report\n\nThe update script categorizes all changes as it processes them:\n- **Critical increases (>10x)** - likely bugs, need investigation\n- **Warning increases (2x-10x)** - need explanation\n- **Major decreases (<50%)** - significant reductions in watch usage\n- **Normal increases (<2x)** - expected growth\n- **Normal decreases (>50%)** - minor reductions\n- **Unchanged** - P99 matches current limit\n- **Skipped** - operators in BigQuery but not in JSON\n\nAfter processing all changes:\n- Outputs a comprehensive summary showing all categorized changes\n\n### 5. Validation\n\nAfter updating, validate the changes:\n- Review the comprehensive summary output for concerning changes\n- Pay special attention to critical (>10x) and warning (2x-10x) increases\n- If needed, run `git diff pkg/monitortests/kubeapiserver/auditloganalyzer/operator_watch_limits.json` to see raw changes\n- Ensure the code still compiles: `go build ./pkg/monitortests/kubeapiserver/auditloganalyzer/...`\n- Review and investigate critical/warning increases before committing\n\n## Return Value\n\n- **Claude agent text**: Detailed report of all updates with warnings and summary of changes\n- **Side effects**:\n  - Modified file: `pkg/monitortests/kubeapiserver/auditloganalyzer/operator_watch_limits.json`\n  - All operator limits updated from BigQuery data\n  - Git changes ready for review and commit\n\n## Example\n\n**Usage:**\n```\n/update-all-operator-watch-request-limits 4.22\n```\n\n**Output:**\n```\nQuerying BigQuery for release 4.22 (last 30 days)...\nProject: openshift-ci-data-analysis\nDataset: ci_data_autodl.operator_watch_requests\n✅ Query completed, retrieved 250 results\n\nReading BigQuery data from stdin...\nLoading: pkg/monitortests/kubeapiserver/auditloganalyzer/operator_watch_limits.json\nWriting: pkg/monitortests/kubeapiserver/auditloganalyzer/operator_watch_limits.json\n\n================================================================================\nOPERATOR WATCH LIMIT CHANGES SUMMARY\n================================================================================\n\n🚨 CRITICAL INCREASES (>10x) - 1 operators:\n  ❌ cluster-monitoring-operator (AWS/HighlyAvailable): 186 → 2100 (11.3x)\n\n⚠️  WARNING INCREASES (2x-10x) - 2 operators:\n  ⚠️  marketplace-operator (GCP/HighlyAvailable): 45 → 95 (2.1x)\n  ⚠️  ingress-operator (Azure/HighlyAvailable): 541 → 890 (1.6x)\n\n📉 MAJOR DECREASES (<50%) - 1 operators:\n  📉 dns-operator (vSphere/HighlyAvailable): 120 → 55 (-54%)\n\n✅ NORMAL INCREASES (<2x) - 115 operators:\n  ✅ cluster-capi-operator (AWS/HighlyAvailable): 205 → 220 (+7%)\n  ✅ authentication-operator (AWS/HighlyAvailable): 519 → 530 (+2%)\n  ✅ etcd-operator (AWS/HighlyAvailable): 245 → 252 (+3%)\n  ✅ console-operator (Azure/HighlyAvailable): 212 → 218 (+3%)\n  ✅ kube-apiserver-operator (GCP/HighlyAvailable): 260 → 275 (+6%)\n  ... and 110 more\n\n📊 NORMAL DECREASES (>50%) - 3 operators:\n  📊 prometheus-operator (OpenStack/HighlyAvailable): 125 → 118 (-6%)\n  📊 service-ca-operator (BareMetal/HighlyAvailable): 135 → 130 (-4%)\n  📊 cluster-samples-operator (Azure/SingleReplica): 40 → 38 (-5%)\n  ... and 0 more\n\n⏭️  SKIPPED - 2 operators not found in JSON:\n  ⏭️  new-test-operator (AWS/HighlyAvailable) - not in JSON\n  ⏭️  experimental-operator (GCP/HighlyAvailable) - not in JSON\n\n================================================================================\nTOTAL: 122 limits changed across 120 operators\n  Critical (>10x): 1\n  Warning (2x-10x): 2\n  Major decreases (<50%): 1\n  Normal increases (<2x): 115\n  Normal decreases (>50%): 3\n  Unchanged: 78\n  Skipped: 2\n================================================================================\n\n⚠️  1 CRITICAL changes detected - review before committing!\n```\n\n## Arguments\n\n- **$1** (required): OpenShift release version\n  - Format: `X.YY` (e.g., `4.22`, `4.23`, `4.21`)\n  - This will be used in the BigQuery query to filter data for that specific release\n  - The query will fetch the last 30 days of data for this release\n\n## BigQuery Query Details\n\nThe command uses the Python script `.claude/scripts/query_operator_watch_requests.py` to fetch data. \n\n## Notes\n\n- **Uses Python scripts**: Two scripts work together:\n  - `query_operator_watch_requests.py` - Queries BigQuery\n  - `update_operator_watch_limits.py` - Updates JSON file and provides comprehensive summary\n- **Requires `bq` CLI**: Google Cloud SDK must be installed and authenticated (`gcloud auth login`)\n- **BigQuery project**: Always queries `openshift-ci-data-analysis` project\n- **Dataset**: Uses `ci_data_autodl.operator_watch_requests` table\n- **Max rows**: Query limited to 1000 results (up from default 100) to handle all operator/platform/topology combinations\n- **Fixed time window**: Always uses 30 days of data (not configurable - ensures reliable averages)\n- **Release specific**: Only queries data for the specified OpenShift release version\n- **Review before commit**: Always review critical and warning increases before committing\n- **Operator names**: The BigQuery Operator field should match service account names (with or without `-operator` suffix)\n- **Platform names**: Must use lowercase names that match the BigQuery schema (aws, gcp, metal, azure, vsphere, openstack)\n- **Uses Average**: Intentionally uses Average instead of P99/Max because test allows 2x headroom\n- **Preserves unknowns**: Operators not in BigQuery results keep their current values\n- **JSON structure**: Updates `operator_watch_limits.json` directly, organized by topology → platform → operator\n- **Formatting**: Maintains JSON indentation and structure\n- **Re-runnable query**: You can re-run just the BigQuery query with `python3 .claude/scripts/query_operator_watch_requests.py 4.22`\n- **Comprehensive summary**: The update script tracks and categorizes all changes as it processes them, providing a detailed summary at the end\n\n## Error Handling\n\n- **Missing release parameter**: Prompts user to provide release version (e.g., `4.22`)\n- **Invalid release format**: Validates release matches pattern like `4.22` or `4.23`\n- **BigQuery query fails**: Shows error message and exits without modifying files\n- **bq CLI not available**: Checks for `bq` command and provides installation instructions\n- **Authentication required**: Prompts to run `gcloud auth login` if not authenticated\n- **Invalid JSON**: Reports parsing errors with line numbers\n- **Missing fields**: Warns about records missing Platform/Topology/Operator/Average\n- **Unknown platform**: Warns and skips operators on platforms not in the maps\n- **Operator not found**: Notes operators in BigQuery data that don't exist in maps (won't add them)\n- **Compilation fails**: Reverts changes and reports Go build errors\n- **No data**: If query returns empty results, exits without changes and suggests checking the release version\n\n## Warnings\n\n- ⚠️  **Critical increases (>10x)** almost always indicate bugs - investigate before committing\n- ⚠️  **Large increases (2x-10x)** need explanation - check recent code changes\n- ⚠️  **Review the diff** - ensure formatting is preserved and changes make sense\n- ⚠️  **Test compilation** - the command validates but always verify manually\n- ⚠️  **Single node data** - upperBoundsSingleNode only has AWS platform, query may return data for other platforms that can't be used\n\n## See Also\n\n- Python scripts:\n  - `.claude/scripts/query_operator_watch_requests.py` - Fetch BigQuery data for a release\n  - `.claude/scripts/update_operator_watch_limits.py` - Update limits in JSON file and provide summary\n- `/update-operator-watch-request-limits` - Update a single operator limit manually\n- Limits file: `pkg/monitortests/kubeapiserver/auditloganalyzer/operator_watch_limits.json`\n- Test implementation: `pkg/monitortests/kubeapiserver/auditloganalyzer/handle_operator_watch_count_tracking.go`\n- BigQuery dataset: `openshift-ci-data-analysis.ci_data_autodl.operator_watch_requests`\n- Grafana dashboard for exploring avg watch requests over time per operator/platform/etc: https://grafana-loki.ci.openshift.org/d/4RcxG4tSz/watch-counts\n\n<!-- File: .cursor/commands/origin-dev-setup.md (Tokens: ~693 | Category: command-prompt) -->\n---\ndescription: Set up the Origin devcontainer (Podman, env, GCP auth)\n---\n\n# Origin dev — devcontainer setup\n\nInteractive setup for the Origin devcontainer. Automates what can be detected, prompts for what can't.\n\n## Workflow\n\n### 1. Detect OS\n\n```bash\nuname -s\n```\n\n- **Darwin** = macOS\n- **Linux** = Linux\n\n### 2. Check prerequisites\n\nVerify each tool is installed. Report any that are missing and stop.\n\n```bash\ncommand -v podman\ncommand -v devcontainer\n```\n\nIf `devcontainer` is missing, tell the user: `npm install -g @devcontainers/cli`\n\n### 3. macOS: Podman machine\n\nIf macOS, check if podman machine is running:\n\n```bash\npodman machine info\n```\n\nIf not initialized or not running, run:\n\n```bash\npodman machine init   # only if no machine exists\npodman machine start\n```\n\n### 4. Linux: Podman socket\n\nIf Linux, check if the socket is active:\n\n```bash\nsystemctl --user is-active podman.socket\n```\n\nIf not active, run:\n\n```bash\nsystemctl --user enable --now podman.socket\n```\n\nAlso check for `podman-docker`:\n\n```bash\ncommand -v docker\n```\n\nIf missing, suggest installing `podman-docker` (dnf or apt depending on `/etc/os-release`).\n\n### 5. Environment file\n\nCheck if `.devcontainer/.env` exists:\n\n```bash\ntest -f .devcontainer/.env\n```\n\nIf missing, copy from the example:\n\n```bash\ncp .devcontainer/.env.example .devcontainer/.env\n```\n\nThen read `.devcontainer/.env` and check for empty required values. If any are blank (e.g. `ANTHROPIC_VERTEX_PROJECT_ID`), tell the user which values need to be filled in and ask them to edit `.devcontainer/.env` and let you know when they're done. **Do not** ask for the values directly or write to the file yourself — the user should edit it. Wait for them to confirm before continuing.\n\n### 6. Start the container\n\nDetermine the right command based on OS:\n\n- **macOS**: `devcontainer up --workspace-folder . --docker-path podman`\n- **Linux** (with `podman-docker`): `devcontainer up --workspace-folder .`\n- **Linux** (without `podman-docker`): `devcontainer up --workspace-folder . --docker-path podman`\n\nRun it. This triggers `post-create.sh` (Go tools, Claude Code, `make build`).\n\n### 7. GCP authentication\n\nGCP credentials are mounted from the host's `~/.config/gcloud` directory. If the user hasn't authenticated on the host yet, tell them to run on the host (not inside the container):\n\n```bash\ngcloud auth application-default login\n```\n\nThe credentials will be available inside the container automatically after restart.\n\n### 8. Summary\n\nPrint a summary of what was set up:\n\n- Container status\n- Claude Code: available via Vertex AI\n- GCP auth status\n- To exec in: `podman exec -it -u vscode -w /workspace origin-dev bash`\n\n<!-- File: .opencode/commands/origin-dev-setup.md (Tokens: ~693 | Category: command-prompt) -->\n---\ndescription: Set up the Origin devcontainer (Podman, env, GCP auth)\n---\n\n# Origin dev — devcontainer setup\n\nInteractive setup for the Origin devcontainer. Automates what can be detected, prompts for what can't.\n\n## Workflow\n\n### 1. Detect OS\n\n```bash\nuname -s\n```\n\n- **Darwin** = macOS\n- **Linux** = Linux\n\n### 2. Check prerequisites\n\nVerify each tool is installed. Report any that are missing and stop.\n\n```bash\ncommand -v podman\ncommand -v devcontainer\n```\n\nIf `devcontainer` is missing, tell the user: `npm install -g @devcontainers/cli`\n\n### 3. macOS: Podman machine\n\nIf macOS, check if podman machine is running:\n\n```bash\npodman machine info\n```\n\nIf not initialized or not running, run:\n\n```bash\npodman machine init   # only if no machine exists\npodman machine start\n```\n\n### 4. Linux: Podman socket\n\nIf Linux, check if the socket is active:\n\n```bash\nsystemctl --user is-active podman.socket\n```\n\nIf not active, run:\n\n```bash\nsystemctl --user enable --now podman.socket\n```\n\nAlso check for `podman-docker`:\n\n```bash\ncommand -v docker\n```\n\nIf missing, suggest installing `podman-docker` (dnf or apt depending on `/etc/os-release`).\n\n### 5. Environment file\n\nCheck if `.devcontainer/.env` exists:\n\n```bash\ntest -f .devcontainer/.env\n```\n\nIf missing, copy from the example:\n\n```bash\ncp .devcontainer/.env.example .devcontainer/.env\n```\n\nThen read `.devcontainer/.env` and check for empty required values. If any are blank (e.g. `ANTHROPIC_VERTEX_PROJECT_ID`), tell the user which values need to be filled in and ask them to edit `.devcontainer/.env` and let you know when they're done. **Do not** ask for the values directly or write to the file yourself — the user should edit it. Wait for them to confirm before continuing.\n\n### 6. Start the container\n\nDetermine the right command based on OS:\n\n- **macOS**: `devcontainer up --workspace-folder . --docker-path podman`\n- **Linux** (with `podman-docker`): `devcontainer up --workspace-folder .`\n- **Linux** (without `podman-docker`): `devcontainer up --workspace-folder . --docker-path podman`\n\nRun it. This triggers `post-create.sh` (Go tools, Claude Code, `make build`).\n\n### 7. GCP authentication\n\nGCP credentials are mounted from the host's `~/.config/gcloud` directory. If the user hasn't authenticated on the host yet, tell them to run on the host (not inside the container):\n\n```bash\ngcloud auth application-default login\n```\n\nThe credentials will be available inside the container automatically after restart.\n\n### 8. Summary\n\nPrint a summary of what was set up:\n\n- Container status\n- Claude Code: available via Vertex AI\n- GCP auth status\n- To exec in: `podman exec -it -u vscode -w /workspace origin-dev bash`\n</yakaai_skills>"}