Merge branch 'main' into diskbbq_updates

Author: john-wagster

.github/PULL_REQUEST_TEMPLATE.md

@@ -0,0 +1,24 @@
+<!--
+Thank you for contributing to the Elastic Docs! 🎉
+Use this template to help us efficiently review your contribution.
+-->
+
+## Summary
+<!--
+Describe what your PR changes or improves.  
+If your PR fixes an issue, link it here. If your PR does not fix an issue, describe the reason you are making the change. 
+-->
+
+## Generative AI disclosure
+<!--
+To help us ensure compliance with the Elastic open source and documentation guidelines, please answer the following:
+-->
+1. Did you use a generative AI (GenAI) tool to assist in creating this contribution?
+- [ ] Yes  
+- [ ] No  
+<!--
+2. If you answered "Yes" to the previous question, please specify the tool(s) and model(s) used (e.g., Google Gemini, OpenAI ChatGPT-4, etc.).
+
+Tool(s) and model(s) used:
+-->
+

.github/workflows/vale-linting.yml

@@ -0,0 +1,22 @@
+name: Vale Documentation Linting
+
+on:
+  pull_request:
+    paths:
+      - '**.md'
+      - '**.adoc'
+
+permissions:
+  contents: read
+
+jobs:
+  vale:
+    runs-on: ubuntu-latest
+    steps:
+      - name: Checkout
+        uses: actions/checkout@v5
+        with:
+          fetch-depth: 0
+      
+      - name: Run Vale Linter
+        uses: elastic/vale-rules/lint@main

.github/workflows/vale-reporting.yml

@@ -0,0 +1,23 @@
+name: Vale Report
+
+on:
+  workflow_run:
+    workflows: ["Vale Documentation Linting"]
+    types:
+      - completed
+
+permissions:
+  pull-requests: read
+
+jobs:
+  report:
+    runs-on: ubuntu-latest
+    if: github.event.workflow_run.event == 'pull_request'
+    permissions:
+      pull-requests: write
+    
+    steps:
+      - name: Post Vale Results
+        uses: elastic/vale-rules/report@main
+        with:
+          github_token: ${{ secrets.GITHUB_TOKEN }}

.gitignore

@@ -12,4 +12,7 @@ AGENTS.md
 .github/instructions/**.instructions.md
 CLAUDE.md
 GEMINI.md
-.cursor
+.cursor
+
+# VS code settings
+.vscode

contribute-docs/api-docs/kibana-api-docs-quickstart.md

@@ -202,7 +202,7 @@ responses:
 :sync: code-generated
 
 :::{note}
-**This step is optional.** CI will automatically capture the snapshot when you push your `.ts` changes. Running this locally is useful for validating changes before pushing or debugging issues. See [`capture_oas_snapshot.sh`](https://github.com/elastic/kibana/blob/main/.buildkite/scripts/steps/checks/capture_oas_snapshot.sh) for the full list of paths captured in CI.
+**This step is optional.** CI will automatically capture the snapshot when you push your `.ts` changes. Running this locally is useful for validating changes before pushing or debugging issues.
 :::
 
 This step captures the OpenAPI specification that {{kib}} generates at runtime from your route definitions. It spins up a local {{es}} and {{kib}} cluster with your code changes. This generates the following output files in the `oas_docs` directory:
@@ -214,13 +214,27 @@ This step captures the OpenAPI specification that {{kib}} generates at runtime f
 - [Docker](https://docs.docker.com/get-docker/) must be running
 - If you're an Elastician, ensure you're logged into Docker with your Elastic account
 
-**Capture all API paths** (recommended):
+To capture all the documented API paths, copy the command from [`capture_oas_snapshot.sh`](https://github.com/elastic/kibana/blob/main/.buildkite/scripts/steps/checks/capture_oas_snapshot.sh). For example:
 
 ```bash
-node scripts/capture_oas_snapshot --update
+node scripts/capture_oas_snapshot \
+  --include-path /api/status \
+  --include-path /api/alerting/rule/ \
+  --include-path /api/alerting/rules \
+  --include-path /api/actions \
+  --include-path /api/security/role \
+  --include-path /api/spaces \
+  --include-path /api/streams \
+  --include-path /api/fleet \
+  --include-path /api/saved_objects/_import \
+  --include-path /api/saved_objects/_export \
+  --include-path /api/maintenance_window \
+  --include-path /api/agent_builder
+  --update
 ```
 
-**For faster iteration**, capture the specific paths you're working on:
+For faster iteration, you can capture the specific paths you're working on, though this minimized output should not be included in your pull request.
+For example:
 
 ```bash
 node scripts/capture_oas_snapshot --update --include-path /api/your/specific/path

deploy-manage/cloud-organization/billing/cloud-hosted-deployment-billing-dimensions.md

@@ -30,7 +30,7 @@ Deployment capacity typically constitutes the majority of your bill, and is the
 
 ### How can I control the deployment capacity cost? [ec_how_can_i_control_the_deployment_capacity_cost] 
 
-Deployment capacity is purely a function of your current deployment configuration and time.  To reduce this cost, you must [configure your deployment](../../deploy/elastic-cloud/configure.md) to use fewer resources.  To determine how much a particular deployment configuration will cost, try our [pricing calculator](https://cloud.elastic.co/pricing).
+Deployment capacity is purely a function of your current deployment configuration and time.  To reduce this cost, you must [configure your deployment](../../deploy/elastic-cloud/configure.md) to use fewer resources.  To determine how much a particular deployment configuration will cost, try our {{ech}} [pricing calculator](https://cloud.elastic.co/pricing).
 
 
 ## Data Transfer [data-transfer] 

deploy-manage/cloud-organization/billing/elasticsearch-billing-dimensions.md

@@ -33,7 +33,7 @@ For detailed {{es-serverless}} project rates, refer to the [{{es-serverless}} pr
 * **Indexing:** The VCUs used to index incoming documents. Indexing VCUs account for compute resources consumed for ingestion. This is based on ingestion rate and amount of data ingested at any given time. Transforms and ingest pipelines also contribute to ingest VCU consumption.
 * **Search:** The VCUs used to return search results with the latency and queries per second (QPS) you require. Search VCUs are calculated as a factor of the compute resources needed to run search queries, search throughput, and latency. Search VCUs are not charged per search request. Instead, they are a factor of the compute resources that scale up and down based on amount of searchable data, search load (QPS), and performance (latency and availability).
 * **Machine learning:** The VCUs used to perform inference, NLP tasks, and other ML activities. ML VCUs are a factor of the models deployed and number of ML operations such as inference for search and ingest. ML VCUs are typically consumed for generating embeddings during ingestion and during semantic search or reranking.
-* **Tokens:** The Elastic Managed LLM is charged per 1 million input and output tokens. The LLM powers all AI Search features such as Playground and AI Assistant for Search and is enabled by default.
+* **Tokens:** [The Elastic Inference Service](https://www.elastic.co/docs/explore-analyze/elastic-inference/eis) is charged based on tokens used with machine learning models. For embeddings and rerankers, usage is billed per million input tokens sent to the models. For LLMs, this is either per 1 million input or per 1 million output tokens. Elastic Managed LLMs can power all AI Search features (such as Playground and AI Assistant for Search), as well as features in the Security and Observability products, and are enabled by default.
 
 ## Data storage and billing [elasticsearch-billing-information-about-the-search-ai-lake-dimension-gb]
 

deploy-manage/cloud-organization/billing/serverless-project-billing-dimensions.md

@@ -15,7 +15,7 @@ products:
 * [Offerings](#offerings)
 * [Add-ons](#add-ons)
 
-Specific prices can be found in the [Cloud Pricing Table](https://cloud.elastic.co/cloud-pricing-table?productType=serverless).
+Specific prices can be found in the [Cloud Pricing Table](https://cloud.elastic.co/cloud-pricing-table?productType=serverless) or you can create an [Elastic Cloud Serverless Estimate](https://cloud.elastic.co/pricing/serverless).
 
 ## Offerings [offerings] 
 

deploy-manage/deploy/cloud-enterprise/resize-deployment.md

@@ -34,7 +34,7 @@ To resize a deployment:
         ::::
 
     RAM per instance
-    :   Node and instance capacity should be sufficient to sustain your search workload, even if you lose an availability zone. Currently, half of the memory is assigned to the JVM heap. For example, on an {{es}} cluster node with 32 GB RAM, 16 GB would be allotted to heap. Up to 64 GB RAM and 1 TB storage per node are supported.
+    :   Node and instance capacity should be sufficient to sustain your search workload, even if you lose an availability zone. For instances up to 64 GB of RAM, half the memory is assigned to the JVM heap. For instances larger than 64 GB, the heap size is capped at 32 GB. For example, on an {{es}} cluster node with 32 GB RAM, 16 GB would be allotted to heap, while on a 128 GB node, 32 GB would be allotted to heap. Up to 256 GB RAM and 1 TB storage per node are supported.
 
     Before finalizing your changes, you can review the **Architecture** summary, which shows the total number of instances per zone, with each circle color representing a different type of instance.
 

deploy-manage/deploy/cloud-on-k8s.md

@@ -77,7 +77,7 @@ ECK is compatible with the following Kubernetes distributions and related techno
 
 :::{tab-item} ECK 3.2
 * Kubernetes 1.30-1.34
-* OpenShift 4.15-4.19
+* OpenShift 4.15-4.20
 * Google Kubernetes Engine (GKE), Azure Kubernetes Service (AKS), and Amazon Elastic Kubernetes Service (EKS)
 * Helm: {{eck_helm_minimum_version}}+
 :::